Method and system for anti-money laundering surveillance

A method for anti-money laundering surveillance may include analyzing transaction data based on a group that may include at least one of peer comparison, expected level of activity and debit/credit flow through. The method may also include generating an alert in response to one or more predetermined results from the analyzing.

BACKGROUND OF THE INVENTION

The present invention relates to financial systems, financial transactions and the like, and more particularly to a method and system for anti-money laundering surveillance or to detect other anomalies related to financial transactions or use of financial systems.

With the use of financial systems, products, transactions and the like by politically violent individuals and other dishonest individuals to finance and support their activities, monitoring financial transactions and detecting any anomalies has become an important aspect of identifying such activities and their participants. Additionally, governments have promulgated guidelines and regulations to detect and monitor such transactions and use of financial systems and products.

BRIEF SUMMARY OF THE INVENTION

In accordance with an embodiment of the present invention, a method for anti-money laundering surveillance may include analyzing transaction data based on a group that may include at least one of peer comparison, expected level of activity and debit/credit flow through. The method may also include generating an alert in response to one or more predetermined results from the analyzing.

In accordance with another embodiment of the present invention, a method for anti-money laundering surveillance may include converting raw transaction data to daily summary transaction data. The method may also include converting daily transaction data to a group that may include peer comparison of average transaction volume and structuring activity data, exception from expected historical level of activity data, and volume and velocity of transactions or debit/credit flow through activity data. The method may also include applying an outlier-shooting algorithm to the activity data to identify any outliers and to assign a risk score. The method may further include generating any alerts based on a selected threshold.

In accordance with another embodiment of the present invention, a system for anti-money laundering surveillance may include a processor and at least one of a peer comparison module, an expected level of activity module, and a debit/credit flow through module.

In accordance with another embodiment of the present invention, a computer program product for anti-money laundering surveillance may include a computer usable medium having computer usable program code embodied therewith. The computer usable medium may include computer usable program code configured to analyze transaction data based on a group that may include at least one of peer comparison, expected level of activity, and debit/credit flow through. The computer usable medium may also include computer usable program code configured to generate an alert in response to one or more predetermined results from the analyzing.

Other aspects and features of the present invention, as defined solely by the claims, will become apparent to those ordinarily skilled in the art upon review of the following non-limited detailed description of the invention in conjunction with the accompanying figures.

DETAILED DESCRIPTION OF THE INVENTION

The following detailed description of embodiments refers to the accompanying drawings, which illustrate specific embodiments of the invention. Other embodiments having different structures and operations do not depart from the scope of the present invention.

FIG. 1is a flow chart of an example of a method100for anti-money laundering (AML) monitoring or surveillance in accordance with an embodiment of the present invention. In block102, raw transaction data104may be converted to predetermined time segments. For example, the raw data may be converted to daily statistical transaction data (converted statistical data106), or data based on some other convenient time frame to reduce the amount of data or to facilitate analysis and identifying any anomalies. The raw data may be collected by entity.

The data may also be filtered. Only transactions above a certain monetary amount, for example $30 or some other amount, may be considered. Debits and credits may be accumulated for each predetermined time segment or daily. Examples of the converted statistical data106for a daily time period may include information such as identification (ID) of each entity of interest; a reference ID associated with each transaction of interest; a transaction date; number of credit transactions in the day associated with each entity, ID, reference ID, customer, business name or other identifying information; sum of credit transactions (monetary value) during the time period or day associated with each entity; number of debit transactions in the time period or day associated with each entity; sum of debit transactions (monetary value) in the day for each entity; sum of number of credit transactions within a predetermined range (for example between about $8,000 and $10,000) in the day; sum of number of debit transactions within the predetermined range in the day; accumulated sum of credit transactions within the predetermined range in the day; accumulated sum of debit transactions within the predetermined range in the day; customer name; business name; or similar information. Each of these types of data may correspond to a column in a database or spreadsheet.

The AML surveillance method100or tool may then process the converted statistical data to generate at least three different sets of statistical data and to perform analysis related to each of the sets of data to generate any alerts or alarms based on any anomalies, changes in transaction patterns, exceeding preset scores or parameters as described in more detail herein. The three sets of data and analysis may include peer comparison data and analysis, expected activity and analysis and volume and velocity of transactions data and analysis, which may also be referred to as debit/credit flow through. The present invention is not intended to be limited to these particular sets of data and analysis. Other data and analysis may also be performed that may facilitate AML surveillance and identification of entities that may be involved in such activities. As used herein an entity may be a customer of a financial institution or the like, an account or any label that may be used to identify participants, whether they are individuals, organizations or other entities.

In block108, peer comparison data110may be generated from the converted statistical data106. Generating the peer comparison statistical data110may involve a process including accumulating all credits (monetary value) for a given date; accumulating the number of all credits for the given date; accumulating all debits (monetary value) for the given date; accumulating the number of debits for the given date; accumulating the monetary amount of all transactions (debit+credit) between a predetermined range (for example $8K-$10K) for the given date; and accumulate the number of transactions (debit and credit) for the predetermined range for the given date. This process may be repeated for each transaction date of interest and may be done only for transactions above a minimum threshold, such as about $30 or some other threshold.

In block112, peer comparison data110may be analyzed and an alert114may be generated in response to an outlier or significant deviation in behavior from a peer comparison of the peer data110. The analysis in block112may involve comparing the peer comparison data110to analyze patterns of behavior among similar types of entities. Different rules, such as business rules or particular parameters of an institution based on past experience of identifying entities that may be involved in money laundering or similar activities may be applied. An “Outlier-Shooting Algorithm” or module may be used to identify outliers or deviations in behavior for generating an alert for closer observation or other action. An example of an Outlier-Shooting algorithm is described in more detail below. Briefly described, outliers may be determined using distance measured from a reference point. The reference point may be the “median” statistics of customers or entities in the peer group. The distance calculation may be performed using the Outlier-Shooting Algorithm. The Outlier-Shooting Algorithm may include parameter optimization using “Sequential Quadratic Programming.” The optimization process may include repetitively finding a weighted distance that is as far as possible from a reference point. The weighted distance found by optimization technique is employed to make sure that any outlier behavior from any variable or input feature statistics, such as peer comparison data110produced in block108, will be amplified and detected as an outlier.

There may be an adjustable parameter called a Peer Outlier Threshold, TcH. The Peer Outlier Threshold may be used to determine an outlier in a principal component distance calculation. The threshold may typically be set to 3 standard deviations.

In block116, expected activity data118for a preset time period may be generated from the converted statistical data106. The preset time period may be a week; although, any time period that may be convenient for performing the particular analysis may be used. The process of generating the expected activity data118from daily statistical data106using a preset time period of a week may involve determining a sum of the number of transactions; sum of monetary amount of the transactions; sum of number of transactions within a predetermined range; sum of number of credits; sum of monetary amount of credits; or similar calculations depending upon the type activities being monitored and analyzed.

Ratio statistics may also be determined in block116which may include value of monetary transactions to number of transaction days; number of credits to number of transactions; monetary amount of credits per monetary amount of transactions. These ratios may be determined for all weeks for which expected activity is being evaluated.

In block120, expected alert data122for preset time periods may be generated. The process may involve converting the expected activity data118into predetermined alert statistics that may summarize a deviation or distance from an expected level of activity. The statistics may involve determining Kurtosis of distance, a sum of monetary outlier transactions, an average money value of outlier transactions (sum amount/number of transactions), and average amount of transactions per week of outlier transactions (sum amount/number of weeks). This statistical data is intended to capture historical anomalies such as spikes, surges or shifts in an entities transactional behavior. An exemplary method to generate expected activity alert data will be described in more detail with reference toFIG. 3.

In block124, expected activity alert data122may be analyzed and an alert114may be generated in response to any anomalies, such as a spike, shift, surge or other significant departure from historical patterns for an entity. Rules, such as business rules or other parameters may be applied in analyzing the expected activity alert data124. The process in block124may involve calculating an alert score using an empirical cumulative density function (CDF). Monetary sums of outlier transactions for each of the preset time periods may be sorted over the entire time period of the analysis. The empirical CDF may be applied to rank order the sums of outlier transactions. An alert may be generated in response to a probability of a sum of outlier transactions being larger than a specified threshold value. An exemplary method to analyze expected activity alert statistical data and generate any alert will be described in more detail with reference toFIG. 5.

In block126, debit/credit flow through data128may be generated for a chosen time period from the converted statistical data106that may be daily summary transaction data. The chosen time period may be a 31-day time period or other time period that facilitates detecting money laundering or other illicit activity. The debit/credit flow through data may be calculated using the following criteria: (1) a debit/credit (D/C) Flow Through Threshold which may be a minimum monetary amount transaction (the sum of credits and debits). Only those transactions that are larger than this threshold may be counted. And (2) a D/C Similarity Ratio which may be defined as the ratio between the difference of credit and debit amount divided by the total transactions (credit+debit). In other words, only those transactions smaller than the ratio (|$ credit−$ debit|/|$ credit+$ debit|) are counted. The purpose of these criteria is to isolate bulk or transactions involving significant amounts of money in-and-out that are almost equal. An example of a method200for determining flow through data for a chosen time period will be described in more detail with reference toFIG. 2.

In block130, debit/credit flow through alert data132may be generated from the debit/credit flow through data128. The debit/credit flow through data128may be daily flow through data and may be converted into weekly summary statistical data132that may be used by an alert generation module in block134. Four similar statistics may be generated in block130involving 2 elements: sum of flow through transaction money and number of transaction days. The differences between the four statistics may be the periods in which the summations are performed. For example one statistic may be for a 1-7 day period, the second for 8-14 day period, a third for 15-21 day period and the fourth for 22-31 day period. Accordingly, the 31-day summary statistics may be separated into alert data for a given time period which in this example may be seven days each over a 31-day period.

In block134, an alert114may be generated in response to debit/credit flow through analysis exceeding a preset score or limit. The volume, speed and frequency of transactions may be analyzed to determine any entities with transactions exceeding the preset score to generate the alert114. As with peer comparison analysis and expected activity analysis, business rules or other criteria may be applied in analyzing the flow through data.

The analysis and alert generation process in block134may involve calculating an alert score using an empirical cumulative density function (CDF). The CDF may include sorting a monetary Sum of outlier transactions and assigning a probability value empirically to rank order the outlier transactions. An alert114may be generated if the probability value is larger than a specified threshold. An exemplary method for analyzing debit/credit flow through alert data and generating an alert in response thereto will be described with reference toFIG. 6.

The alerts from each of the peer comparison analysis and alert generation in block112, expected activity analysis and alert generation in block124, and flow through analysis and alert generation in block134may be used to generate an overall alert in block136. In block136, overall alerts may be generated based on three high level statistics: (1) peer distance summary statistic, (2) expected level of activity summary statistic, and (3) debit/credit flow through summary statistic. Alerts may be generated based on relative comparisons among the customers or entities within a surveillance group. Multivariate statistical comparisons to relatively rank customers may be conducted using the Outlier-Shooting Algorithm.

One of the main tenets of customer or entity transaction activity surveillance is to identify unusual, inconsistent, or unexpected patterns in comparison with those of similar entities. This may be done using the Outlier-Shooting Algorithm. In statistical terms, the Outlier-Shooting Algorithm may involve identifying transaction patterns that significantly deviate from the “median” of a population. These deviations can be considered as “outliers” or can be referred to as “outliers.” Mathematically, this relationship can be formulated as an optimization function similar to that expressed in equation (1).

A set of “optimal” weighting factors, w, can be found that maximizes the distance between the most extreme customer or entity to the median where ximay be the three main feature statistics (peer comparison, expected level of activities, and flow through described herein) of the ithcustomer or entity. The {.}+sign is to maximize only in the direction of xithat are larger than median. Note that the larger the feature statistics xi, the riskier the customer or entity may be. The overall risk statistics for the ithcustomer is yi=wTxi−median(wTxi). The customer with the highest value of yiis the riskiest. When xiis normally distributed then y is also normally distributed. An outlier is identified if yi>μy+3σy, where μyand σyare the mean and the standard deviation of y, respectively. Once the ithcustomer is identified as an outlier, it may be flagged and excluded from the analysis, and the optimization process may be repeated until no further outlier is found. Once no more outliers are found, the “weighted-distance” risk statistics, yi=wTxi−median(wTxi) may be applied to the remaining data. An exemplary implementation of the Outlier-Shooting process or algorithm is illustrated in the following code listing:function s=find_score(xorg)% Outlier-shooting algorithm[m,n]=size(xorg);global z;% initialize variablesw0=ones(n,1); % initial weighting factorsflagY=zeros(m,1); % initialize outlier flagsidxY=(1:m)′;s=zeros(m,1);% iterate to find outlierswhile 1noflag=find (flagY==0);x=xorg(noflag,:); % use sample data that are notflaggedidx=idxY(noflag);[mx,nx]=size(x);meanx=mean(x);stdx=std(x);stdx=(stdx>0).*stdx+(stdx<=0).*ones(1,nx);z=(x−ones(mx,1)*meanx)./(ones(mx,1)*stdx); %normalized statisticsoptions=optimset(‘LargeScale’,‘off’,‘Display’,‘off’);w=fmincon(@dist,w0,[ ],[ ],[ ],[ ],[ ],[ ],@confun,options);% call optimization routine to optimize weighting factorsmedz=median(z);omedz=ones(mx,1)*medz;zpos=z−omedz; % calculate coordinate distance to themediany=zpos*w; % calculate weighted distancew0=w;iy=find (y>mean(y)+3*std(y)); % find outliers using 3sigma thresholdif length(iy>0)[ym,iy]=max(y); % select maximum distance asoutliersidout=idx(iy);s(idout)=y(iy);ss=s(idout);flagY (idout)=ones(length(idout),1); % flaggedoulierselses(idx)=y;break;endend;% routine to calculate maximum distancefunction f=dist(w)global z;medz=median(z);[mz,nz]=size(z);distz=z−ones(mz,1)*medz; % calculate distance to medianzpos=distz>0; % consider only those larger than mediany=(distz.*zpos)*w; % calculated weighted distance scorey=max(y); % calculate maximum distancef=−y; % negate because the function is a minimization function% function to constraint w so that w′w=1function [c, ceq]=confun(w)c=[ ];ceq.w*w−1;

FIGS. 2A and 2B(collectivelyFIG. 2) are a flow chart of an example of a method200for debit/credit flow through data for a chosen time period in accordance with an embodiment of the present invention. The method200may be used to generate the debit/credit flow through data for a chosen time period in block126ofFIG. 1.

In block202, summary statistics data, such as daily summary statistics data204may be read. The summary statistics data may be for any time period that is convenient for the transaction data available, the analysis to be performed and the time frame of interest. In block206, a credit+debit (C/D) threshold value (T) may be set for the entity which may be a group, type of customer, business or the like. The threshold value (T) may be different for different entities or types of entities. In block208, a similarity ratio (R) threshold may be set between a difference of credits and debits and a sum of credits and debits. As an example, the similarity ratio (R) threshold may be about 0.15 and is a measure of the similarity of the different transactions between different entities. A similarity threshold (R) greater than the threshold may be an indication that the transactions may be somewhat dissimilar. The similarity ration may be different for different entities, businesses, types of customers or the like.

In block210, a sum of credits for each selected time period (for example a daily sum) may be calculated over a chosen time period, such as a 31-day period or other convenient time period. In block212, a sum of debits for each selected time period over the chosen time period may be calculated.

In block214, a sum of debits and a sum of credits may be calculated to provide a sum of transactions (TRANS=SUM CREDITS+SUM DEBITS). In block216, a determination may be made if the sum of transactions monetary amount is greater than the C/D threshold value (TRANS≧T). If not, the method200may end at termination218. If TRANS is greater than or equal to the C/D threshold T, the method200may advance to block220. In block220, a difference between the sum of credits and the sum of debits (DELTA) may be calculated.

In block222, a ratio of DELTA to TRANS (RATIO=DELTA/TRANS) may be calculated. A determination may be made in block224if the ratio is less than the similarity ratio (R). If not, the method200may advance to block226and the method200may end at termination226. If the ratio determined in block222is less than the similarity ratio R is block224, the method200may advance to block228. In block228, a total value of transactions (monetary value of credits+monetary value of debits) for the selected time period (may be daily) may be accumulated.

In block230, a total number of transactions for the selected time period may be accumulated. In block232, transactions used in the calculations may be flagged to avoid double counting in other calculations.

In block234, a determination may be made if there are more selected time periods within the chosen time period of interest. If so, the method200may return to block210to generate flow through statistical data for the next selected time period. If accumulated totals have been determined for all selected time periods within the chosen time period of interest, the method200may output the flow through data236for the chosen time period which may be similar to the debit/credit flow through data128ofFIG. 1and may include the accumulated total value of transactions and accumulated number of transactions for each selected period.

FIG. 3is a flow chart of an example of a method300to generate expected activity alert statistical data in accordance with an embodiment of the present invention. The method300may be used to generate the expected activity alert data122from block120of the method100inFIG. 1. Expected activities302for all customers304or entities of interest may be read or inputted in the system in block306. The expected activities302may be financial transactions.

In block308, variables with all zero entries may be removed. In block310-316, outlier weeks (or other convenient time frame) may be iteratively removed using multivariate hypothesis test. In block310, the data may be normalized. In block312, principal components may be calculated. Block312may include a principal component function or the like. The principal component routine may return two outputs which may include Eigenvectors and Eigenvalues. Principal components where the Eigenvalues are greater than or equal to 1 may be retained. Hoteling-T2statistics may be calculated for the retained principal components in block312. In block314, outliers may be removed using a Chi-square test. In block316, only week data (or other selected time frame data) from samples that are not outliers are keep.

In block318, distance or deviation from expected activity for an entire week or other selected time frame may be calculated. In block322, all major principal components (PC) may be calculated for Eigenvalues greater than or equal to 1 from block320. In block324summary statistics or expected activity alert data may be calculated and saved to a file (expected activity alert data122inFIG. 1). The method300may return to block304and may proceed as previously discussed for all customers or entities of interest. The method300may end at termination326.

FIG. 4is a flow chart of an example of a method400to generate an alert in response to a peer comparison outlier or anomaly in accordance with an embodiment of the present invention. The method400may be used to analyze peer comparison data and generate a peer comparison outlier alert in block112ofFIG. 1. In block402, peer comparison feature statistics data404may read or inputted into a system for AML surveillance. In block406, the data may be normalized. The data may be normalized using a standard normal (z) score or similar process.

In block408, a reference point may be established for distance calculation. In block410, outliers may be iteratively identified and a distance from the reference point may be calculated using the outlier-shooting algorithm previously described. In block412, a record, customer, account or the like may be flagged in response to being identified as an outlier. The record may be removed from subsequent iterations.

In block414, an alert score may be calculated using an empirical cumulative density function (CDF) to rank the records from smallest to largest distance from the reference point. In block416, an alert threshold may be established to alert for a predetermined top percentile of highest ranking records or entities.

FIG. 5is a flow chart of an example of a method500to generate an alert in response to an anomaly in expected activity in accordance with an embodiment of the present invention. The method500may be used to analyze data and generate an expected activity alert in block124ofFIG. 1. In block502, an alert score may be calculated using an empirical cumulative density function (CDF) applied to the expected activity statistical data504. The expected activity statistical data504may be the same as the data122ofFIG. 1.

In block506, a sum of monetary value of outlier transactions may be sorted. In block508, an empirical CDF rank may be assigned to sum of outlier transactions. In block510, an alert may be generated in response to a probability value being larger than a specified threshold.

FIG. 6is a flow chart of an example of a method600to generate an alert in response to debit/credit flow through exceeding a predetermined score in accordance with an embodiment of the present invention. The method600may be used for the analyze data and generate a flow through alert function of block134inFIG. 1. In block602, an alert score may be calculated using an empirical cumulative density function (CDF) based on the debit/credit flow through data604. The debit/credit flow through data may be the same as the alert data132ofFIG. 1.

In block606, sums of monetary values of outlier transactions may be sorted. In block608, an empirical CDF rank order may be assigned to the sums. In block610, an alert may be generated in response to a probability value being larger than a specified threshold.

FIG. 7is block diagram of an example of a system700for anti-money laundering (AML) surveillance in accordance with an embodiment of the present invention. The methods100,200,300,400,500and600ofFIGS. 1-6respectively may be embodied in the system700. The system700may include a server702. The server702may be an application server or similar server and may include a processor. An AML surveillance tool704or application may be operable on the server702or processor. The server702may be accessed by one or more clients706via a network708. The network708may be the Internet, an intranet or other private network. The AML surveillance tool704may acquire transaction data from a transaction database710or other data store for performing AML analysis and generating alerts similar to that previously described.

The AML surveillance tool704may include a peer comparison module712, an expected level of activity module714, a debit/credit flow through module716or other modules that may facilitate AML surveillance. The peer comparison module712may embody blocks108and112of method100ofFIG. 1and method400ofFIG. 4. Accordingly, the peer comparison module712may analyze transaction data related to peer comparison and generate a peer comparison alert in response to an outlier based on analysis of transaction patterns compared to similar entities as previously described.

The expected level of activity module714may embody blocks116,120, and124of method100ofFIG. 1, method300ofFIG. 3, and method500ofFIG. 5. The expected activity module714may perform analysis on transaction data related to expected activity statistical data and may generate an expected activity alert in response to a predetermined change in historical transaction patterns for a particular entity.

The debit/credit flow through module716may embody blocks126,130, and134of the method100, and method200ofFIG. 2, and method600ofFIG. 6. The debit/credit flow through module716may analyze transaction data related to volume, speed and frequency of transactions and may generate a flow through alert in response to the debit/credit flow through exceeding a preset score or limit.

The AML surveillance tool704may also include an alert generation module to generate a respective, predetermined alert in response to certain conditions or results from each respective module712,714, and716. In another embodiment of the present invention, the alert generation module718or appropriate portions of the alert generation module718may be incorporated in the respective modules712,714, and716.

The AML surveillance tool704may also include an outlier-shooting algorithm or module720. As previously described, the outlier-shooting algorithm may be applied to the transaction data to identify any outliers or statistical data associated with an entity which significantly deviates from a reference point or expected level of activity. In another embodiment of the present invention the outlier-shooting algorithm720or appropriate portions of the algorithm720may be incorporated in the respective modules712,714and716.