Data Analytics to Detect Evolving Money Laundering Murad Mehmet, Duminda Wijesekera George Mason University mmehmet@gmu.edu , dwijesek@gmu.edu Abstract— Money laundering evolves using multiple layers of laundering and suggest that risks can be measured using trade, multi trading methods and uses multiple components in metrics such as “Country risk”, “Customer risk”, and “Services order to evade detection and prevention techniques. risk”, and leave weights assigned to each of these categories at Consequently, detecting money laundering requires an analytical the discretion of the evaluating organization. Based on these framework that can handle large amounts of unstructured, semi- guidelines, banks use a quantitative model to evaluate structured and transactional data that stream at transactional transactional risk using attributes such as “Customer profile”, speeds to detect business-complexities, and discover deliberately “Product/service profile”, and “Geographic profile”. concealed relationships. Based on our prior work and a static risk model proposed in the Bank Security Act, we propose a dynamic The static risk model developed by Scor [6] accepts ML to risk model that assigns a risk score for every transaction being a be determined by “Agility” of adopting new rules per potential component of a larger money-laundering scheme. We customer, “Complexity” of transactions and the “Secrecy” of use social networks to connect missing links in such potential transactional information and customer account” [6], but fails transaction sequences. Taken together we can provide a financial to assess other factors such as relationship networks, and sector independent risk assessment to submitted transactions. dynamically changing factors. Kount [7] developed a dynamic The proposed risk model is validated using data from realistic scoring service to continuously monitor indicators of fraudulent scenarios and our already developed money laundering evolution credit card activity, and alert merchants of approved detection framework (MLEDF) that we developed earlier using transactions that are linked to suspicious purchasing activities, sequence matching, case-based analysis, social networks, and that usually occur after identity theft. These suspicious complex event processing to link fraudulent transaction trails. purchases refer are transactions patterns that have never been MLEDF has components to collect data, run them against witnessed before, such as the purchase of video games by business rules and evolution models, run detection algorithms senior citizen. and use social network analysis to connect potential participants. The rest of the paper is organized as follows. Section 2 Keyword: Data Analytics; Social network analysis; Anti Money describes the Money Laundering Evolution Detection Laundering; Dynamic Risk Model ; Money laundering Risk . Framework (MLEDF). Section 3 describes the SNA algorithm. Section 4 describes the dynamic risk model. Section 5 I. INTRODUCTION evaluates the performance of the MLEDF and dynamic risk Money laundering (ML) is a major issue for the model using real-life cases. Section 6 concludes the paper. Department of Homeland Security (DHS) and US Treasury. II. ML EVOLUTION DETECTION FRAMEWORK (MLEDF) Powered by modern tools, money launderers use complex schemes to avoid being detected by anti-money laundering (AML) systems. They dynamically evolve, expand and contract over fraudster networks in different countries. Social Network Analysis (SNA) techniques [1] are used by government agencies to track terrorist activities and networks. Because terrorist financing heavily depends on ML [2], any AML system must incorporate SNA to obtain reliable results. Schwartz [3] proposes a model to find criminal networks using social network analysis, building upon Borgatti’s SNA-based key player approach [3]. One drawback of Borgatti's model is the failure to assign weights to actors and actor-actor relationships. In the recent past, we have developed algorithms incorporates Borgatti’s SNA techniques with different weights’ Fig. 1. Money Laundering Evolution Detection Framework to social and business relationships to help complete missing First we briefly describe how MLEDF works [8]. Obtaining links in potential money laundering chains. data streams from multiple sources listed in the left hand The Financial Action Task Force (FATF) provides a static column of Fig.1, using a complex event processing system. risk assessment of ML [4] strategies to examine ML related MLEDF uses four phases where output from one phase is used predicate crimes and known weaknesses of anti-money by the following phase and shown in the columns of Figure1. laundering (AML) systems. The Wolfsberg Group, made up of (1) Collecting Transactional Data: Transaction processors eleven leading international banks established standards, or data collectors from Automated Clearing House such as guidelines and a discretionary risk model [5] to counter money EPN, FEDWIRE, and CHIPS send their data belonging to trade laundering. Both FATF and Wolfsberg Group say that sectors such as Banking, Stock market, Derivative market, Web monitoring customers is an essential part of countering money STIDS 2013 Proceedings Page 71 based Services, Trading, Electronic Money, and Money number of transactions and reducing the transacted amount), or Brokering. Relevant information is extracted form this data and using an unreported method such as a Hawala [15] (an honor used with transaction-independent data such as the economic based exchange system without records). As a solution, we use status of the country, stock sales trends and the stock values a social network among money launderers to link MLS trails during the day. when evidence of linkage is missing among transactions. (2) Data Processing: Well-known MLS are identified and A. Using Complex Event Processing in the SNA Module relevant attributes are collected from input data streams and The critical question of ML experts is “How fast and how submitted to our detection algorithms. The extracted data well can we relate the different events in this universe of associated with each MLS pattern assigned to a specific MLS detected MLS?” Using the Complex Event Processing (CEP) type using the following: (I) Business Rules: MLS business system StreamBase, we developed an algorithm to create rules and red flags associated with each pattern, the rules chains of related MLSs where social or professional relations associated with specific sector are used by the MLS detection are used to transfer a fund to the next MLS until it reaches the algorithms to identify the MLS patterns. (II) MLS Template: final destination where the End Boss withdraws the money. If Well-known MLS templates will be used during this phase. we modeled all of the chains as a separately and link them we Currently, the templates have seven major pattern types with run into a scalability issue in associating the multitude of their different subtype combinations. This acts as a repository different events of various MLSs. As a solution, we model each of known MLS. If a new form of MLS is discovered, then it detected MLS as an event, and have various patterns of events will be added to this Database. (III) ML Evolution Model: categorized under six different types of MLS. For example, Determines if the evolution of MLS is within the accepted Full-Trail algorithm outputs a trail by using the functionality of trend of our model [8]. CEP of perceiving the MLSs as a set of events. Without the (3) Detecting MLS Networks: We use six algorithm (one for CEP the MLS should dissolve into the constituent transactions each) to detect Smurfing, Trade, Stock, Derivative, E-Money, to be analyzed and linked with other transactions from another and Dirty Electronic Funds Transfer (Dirty-EFT) schemes. MLS, consumes processing time and resources. The CEP can Each algorithm uses a different method to capture the network link MLSs, perceived as events, using various criterions associated with the specific type of MLS and in real-time without the need to add more complex sub-algorithms for each output the discovered networks associated with the specific criterion. That is, the Full-Trail connects the dots that exist, but MLS pattern into a different database. Then, the discovered it is harder and slower to connect them without CEP networks are reformatted and saved in a single database capabilities. Full-Trail captures the trail in cases where all referred to as the “Network” Database to facilitate efficient evidence are available, whereas the Suspicious-Trail attempts analysis of the links among MLS networks. to construct the path where some edges along the path is (4) ML Trail Analysis and Evolution Detection: Four missing. separate algorithms are run to find the “Full-Trails” [8], B. Integrating the “SNA” Module into MLEDF “Missing-Trails”, and “Suspicious-Trails” of MLS networks. The “Suspicious-Trail” module is used to detect “Full-Trail” is a concatenated sequence of related schemes components of an actual “Full-Trail” even if there is a missing (MLS) act by itself to transfer money from one MLS to another piece of evidence. This module investigates all available trails until it reaches the final MLS, of which the orchestrator (i.e. the (Full-Trail and Missing-Trail) by using our SNA DB that money launderer) is referred to as the “EndBoss”. Similarly the contains the weights of relationships among MLS participants orchestrator of the first scheme is referred to as the in order to determine if two trails are related by considering “StartBoss”. “Associates” are other people involved in the some attributes such as the amount of funds involved, location, sequence of fraud. “Missing-Trail” is a short Full-Trail that affinity of participants, time, and methods used for laundering. does not exceed have more than three related MLSs. A sample Hence, the “Suspicious-Trail” module uses the “SNA” module output from the Full Train Algorithm is given in Table 1, to produce a new trail containing two or more trails that are where a network ID (assigned by our detection algorithm), the related based on SNA even when we have not captured a duration of the laundering activity, if the money was withdrawn transaction joining them or any other evidence. The new trail is after the third transaction, the amount of money and the created after making a calculation based on (SNA) results of a detected Start Boss and the detected End Boss are provided. possible relationship between two or more Full-Trails and We assume that the Missing-Trail is a premature Full-Trail Missing-Trails. The generated evolution patterns and strategies with broken parts and missing links or evidence. A are collected into the “Suspicious-Trail” Database. “Suspicious-Trail” is a combination of discovered Full-Trails TABLE I. SAMPLE OUTPUT OF THE FULL-TRAIL (MIN 4 MLS) and/or Missing-Trails constructed using algorithms that incorporate SNA and numerical analysis techniques. The Networks TrailID Duration Withdraw Amount StartBoss EndBoss algorithm “Detection Analysis” determines the evolution of the 4, 91, 98 ,.. 1232 76 Days No 723,234 Boss956 Boss 153 “Full-Trail”s such as the change to the number of involved 24, 315, .. 1208 89 Days No 890,165 Boss 103 Boss 827 associates, the changes to the cost of laundering, and changes 405,783, .. 9724 19 Days No 200,230 Boss 284 Boss 725 to the laundering locations. C. The Components and Output of the “SNA” Module III. SOCIAL NETWORK ANALYSIS IN MLEDF The architecture of the social network algorithm is shown In many cases money launderers intentionally obfuscate the in Figure 2. The SNA module generates and continuously money trail either by hiding it (for example by increasing the updates two databases as outputs. The “SuspectWeight” database contains the weight of all relations detected in the STIDS 2013 Proceedings Page 72 MLEDF and the “Relations” database containing the time and Step 9 computes the WeightOutput of a hash HRel. Sample the record of all detected relations among pairs in MLEDF as Suspect Weights obtained from Algorithm 1 is shown in Table shown in the bottom of Figure 2. The relations we capture are: IV. This corresponds to Relationships given in Table III. (1) UniqueFullTrailBosses creating “StartBoss”–“EndBoss” TABLE II. SOCIAL NETWORK ANALYSIS ALGORITHM pairs of “Full-Trail”s. (2) UniqueFullTrailAssociates creating 1 FUNCTION HASH (String1,String2){return concatenate(sort(En1,En2))}; “Asscoiate”-“Asscoiate” pairs of “Full-Trail”s. (3) 2 INPUT MLS DetectedMLS; Relnship; MT MissingTrail; FT FullTrail; DB UniqueMissingTrailAssociates createing “Asscoiate”- HRel ( Hash, #"Time", Type, Person1, Person2) KEY (Hash, #"Time", “Asscoiate” pairs of “Missing-Trail”s. (4) SchemaBosses Type); DB SuspectWeightOutput ( hash, weight) KEY (hash); 3 UPDATE HRel SET MLSBoss++, MLSAssocBoss++, creating Hashes for “StartBoss”-“EndBoss” relations. (5) MLSAssocBoss++ WHERE HRel.hash == HASH(MLS.sBoss, SchemaAssociateBoss creating Hashes for all detected “Boss- MLS.eBoss) , HASH(MLS.Assoc, MLS.eBoss) , HASH(MLS.Assoc, Associate” relations. (6) SchemaAssociate creates Hashes for MLS.sBoss) and TypeMatch all detected “Associate-Associate” relationships. This hash 4 FOR EACH (MLS.Assoc as Assoc1, MLS.Assoc as Assoc2) UPDATE represents the combinations of relationships among the HRel SET MLSAssoc++ WHERE HRel.hash == HASH(MLS.Assoc1, associates of the same MLS, even if they do not MLS.Assoc2); 5 FOR EACH (FT.Assoc as Assoc1, FT.Assoc as Assoc2) UPDATE HRel interact/transact with each other directly. (7) Family creating SET FTAssoc = FTAssoc++ WHERE H.hash ==HASH(Assoc1,Assoc2); “Family” relation between lineage-wise related pairs. (8) 6 UPDATE HRel SET FTBoss++ WHERE HRel.hash == Business creating business-wise related pairs. Each such HASH(FT.sBoss, FT.eBoss); relationship is shown in Figure 2. We compute these 7 FOR EACH (MTrail.Assoc as Assoc1, MTrail.Assoc as Assoc2) relationships and assign weights to them as shown in UPDATE HRel SET MTAssoc++ WHERE HRel.hash == HASH(Assoc1, Assoc2) and TM; Algorithm 1 describe in Table II. 8 UPDATE HRel SET Business++, Family++ WHERE HRel.hash == HASH (Relnship.person1, Relnship.person2) AND Relnship.type == "BUSINESS","FAMILY"; 9 SELECT HRel.hash, (25*HRel.FTBoss +20*HRel.FTAssoc +15*HRel.MTAssoc + 1*HRel.MLSAssoc + 5*HRel.MLSAssocBoss +10*HRel.MLSBoss + 250*H.Business +250*H. Family) as SuspectWeightOutput ; TABLE III. SAMPLE SELECTION FROM OUTPUT OF “RELATIONS” DetectTime Hash Type Entity1 Entity2 2012121915 Comp10Comp8 FullTrailAssociates Comp10 Comp8 2012121923 Comp10Comp5 SchemaBossAssociate Comp10 Comp5 2012122005 Comp10Assoc7 MissingTrailAssociates Comp10 Assoc7 2012122112 Assoc7Assoc5 SchemaAssociates Assoc7 Assoc5 2012122214 Comp10EndBoss SchemaBosses Comp10 EndBoss Figure 2: The Social Network Analysis Module 2012122220 StartBossEndBoss FullTrailBosses StartBoss EndBoss TABLE IV. SAMPLE SELECTION FROM OUTPUT OF “SUSPECTWEIGHT” The relationship weights as assigned so that higher weight indicates more possible hidden interactions. Weights are Weight Hash Weight Hash Weight Hash calculated by adding parameters for each of the corresponding 30 Comp10Comp8 10 Comp11Comp2 10 Assoc1Comp1 events as follows: 30 Comp10Comp7 10 Comp11EndBoss 30 Assoc1Comp4 15 Comp10Comp5 10 Comp1Comp2 35 Comp4Comp6 1. Each detected “MLS” weights of 10 will be added to 30 Comp10EndBoss 20 Comp6EndBoss 20 Assoc1Assoc5 start/end boss couple, 5 for each boss/associate 10 StartBossEndBoss 20 Comp7Comp8 0 Assoc1Assoc9 combination, and 1 for each non-repeating associate/associate combination. IV. THE DYNAMIC RISK MODEL 2. Each detected “Missing-Trail”, 15 will be added to each Existing AML systems do not relate different products associate non-repeating combination. types, entities, and business lines involved in different 3. Each detected “Full-Trail” add 20 to each associate combinations of complicated ML schemes. Industry specific combination and 25 to the start and end boss. AML systems use industry specific static risk models and Other strong relationships are also counted where “Family” therefore do not capture known dynamics of MLS evolutions. ties will add 250 to the couple, and each “Business” Countering ML and other forms of fraud requires industry- relationship will add 250 to the couple. We chose the weights wide risk analysis method to where the risk score is updated and, verified them in a limited engagement with a trusted third dynamically and include transactional behavior related to the party (see Section V), but can be changed in Algorithm 1. ML, such as the social relations and past associations with In the SNA Algorithm given in Table II, steps 1 and 2 money laundering. Therefore, we create a dynamic risk model that incorporates the static attributes used by others, such as the define the hash function, and input and DBs constants associated with the different weights and the hash functions. senders and recipient’s static profiles and dynamic social connection attributes of the transactions that we capture in our Steps 3 and 4 create hashes for “Boss-Boss”, “Boss-Associate”, and “Associate-Associate” of MLSs. Steps 5 and 6 create the MLEDF system. same hashes for Full-Trails. Steps 7 and 8 create hashes for Missing-Trails and special relations (of family and business). STIDS 2013 Proceedings Page 73 A. The Static Risk Model of Bnak Secrecy Act the debit and credit activities. We amended the factors of “product risk” in the BSA model to include a risk factor of the derivative market activity. We also reduced the risk weight of three factors in the “business risk” of BSA model from the original value of “+30” to the new value of “+20”, as the total risk score of “30” is the cut-off for an alert to the management of the financial institution. The reduction of the weight of the three factors to “+20” is necessary to lower the aggressiveness of the risk model. Definition 2 categorize these risks as Low, Medium, High and Extreme and are again an extension of the values in [9]. Definition 2 [Categorizing Local Static Risk Scores]: Local Static Risk Scores (LSRS) are categorized as low, medium, high and extremely high based on range of the totally Figure 3. The enhanced BSA Static Risk Modeling [9] calculated score: Low [-23, 4], Moderate [+5, +14], High [+15, +30], Extreme Risk [+31, +153]. The Currency and Financial Transactions Reporting Act B. Accumative Static Risk Score (CFTRA) of 1970 later amended to counter money laundering and financial crimes [11, 12, 13] and again amended by Title To compute the risk of transacting customers, in addition to III of the PATRIOT Act of 2001 and other legislations, and is Static Local Risk Score (LSRS), risk of recent transactions now commonly referred to as the "Bank Security Act" (BSA) need to be taken into account. We propose a simplified mandates banks to monitor transactions and maintain records mechanism of exchanging aggregate risk scores assigned to of initial and periodic risk scores for customers. Their risk customer transactions, because a running average may not model identify and analyze specific “products and services”, expose all the data of all transactions and therefore may not “customers and entities”, and “geographical locations” and violate privacy. Formally, let TRN(O,R), be a transaction with categorize them as “high", "medium", and "low", and add the originator O and recipient R, and let TRNA ≡ , listed in newest to oldest risk score. We enhanced the BSA inspired static risk with transaction order represent the last n transactions of A. Let aggregated static risk to reflect changing dynamics of ML and Partneri(A,TRNAi(xi,yi)) represent the entity other than A and its consequences on the static risk calculation shown in Figure be the LSRS values of 3. The risk rates assigned in Figure 3 are obtained from [9], partners of A in the last n transactions. Then recursively define with suggested enhancements in the upper right hand box. the Exponential Moving Average (EMA) risk as: EMA(i) = Definition 1 captures these attributes and scores. LSRS(Partneri(A,TRNAi(xi,yi)))* k + EMA(i-1) * (1 – k) where k = 2/(n+1) . Definition 1 [Local Static Risk Score (LSRS) and Risk Categories]: The Local Static Risk Score is the sum of the Definition 3 [Receiver’s/Originator’s Average Risk and following attributes and their assignable integer values; Variance]: These averages are calculated by the bank that holds the account of entity A, it is done by calculating the Account Risk Range:[-5,+10], Location Risk Range: [-1,+10] exponential moving average of the LSRS of the last n Business Risk Range: [-15,+20], Product Risk Range: [0,+5] transacting partners of A, Here Account Risk is the sum of Customer Risk [-5, +10] Let EMAi be LSRS(Partner1(A,TRNA1(xi,yi)))* k + EMA(i-1) * and Tax ID Risk [+5]. The Location Risk is the Sum of Primary (1 – k) where k = 2/(n+1), and where A=xi for all iRA3M>RA0M), (OA6MOA3M>OA0M) and Static Risk Penalty and Reward (SRPR) as: (RA-Inc)/\(OA-Inc)/\(RA>LSRS)/\(LSRS>35)/\(RV>5)/\(OV>5)=> SRPR=+5 (RA-Inc)/\(OA-Dec)/\(RA>LSRS)/\(LSRS>35)/\(RV>5)/\(OV>5)=> SRPR=+3 (RA-Dec)/\(OA-Inc)/\(RA>LSRS)/\(LSRS>35)/\(RV>5)/\(OV>5)=> SRPR=+3 (RA-Dec)/\(OA-Dec)/\(RA>LSRS)/\(LSRS>35)/\(RV>5)/\(OV>5)=> SRPR=+2 Figure 4. The Two Componenets of ML Dynamic Risk Model (RA-Dec)/\(OA-Dec)/\(RA>LSRS)/\(LSRS>35)/\(RV<5)/\(OV<5)=> SRPR=-2 (RA-Dec)/\(OA-Dec)/\(RA35)/\(RV>5)/\(OV>5)=> SRPR=-3 We also compute a risk score named the Self Adjusting ((RA-Any)/\/(OA-Any))/\ (RASRPR=0 Dynamic Risk Score (SDRS) that assigns a risk weight to the transactional history of transacting entity (say) A in the A detailed rationale for this definition is described in database “Suspect-Weight” in the DREA algorithm that we [14]. The LSRS will be calculated every time the transaction refer to as DREA(Entity A)]. occurs. For example, the first line of Definition 4 says that if conditions (1) “RA6OV>0 are met, the SRP of “+5” will be (RDRS/ODRS)]: Calculates the aggregate risk weight, based imposed. The RA is the primary factor that LSRS depends on the relations history of the last n entities (R1,...,Rn) funds upon on to determine the penalty value due to the fact that receiving from, and the last n entities (O1,...,On) funds receiving the funds is where the money laundering fraud starts. originating to the entity A. The average weight of receiving The penalty and reward point system will have the upper and /originating entities is obtained by calculating the average of lower bounds, in order to maintain the LSRS within its DREA(R1), .. ,DREA(Rn ) and DREA(O1), .. ,DREA(On ). We boundaries so that their accumulation will have a fix point (risk produce ODRS and RDRS. saturation point) in its decreasing or increasing trend. There is Definition 7 [Accumulative Dynamic Risk Score (ADRS)]: no need to apply the penalty on an entity that is in maximum Of an entity is the sum of SDRS, RDRS and ODRS. That is risk levels of LSRS, as the purpose is to provide the transacting ADRS = SDR+ RDR+ODR. entity with the ability to reduce the risk. D. Accumlative Transaction Scoring Based on Dyanmic Risk Definition 5 [Accumulative Static Risk Score (ASRS)]: of an entity is the sum of the local static risk score and static risk Static and dynamic risks are correlated to the analytics of penalty and reward. Thus, ASRS =LSRS + SRPR. transaction scoring, in order to identify transactions with high- risk score pertaining to ML, and to prevent transaction C. Accumulative Dynamic Risk Score sequences from being executed. The correlations used in the The dynamics of none-static risk scoring was designed dynamic risk scoring can be used to detect and track considering the following criteria: (1) Continuous scoring: The transactions belong of ML schemes. score is calculated per every transaction. (2) Automatic scoring: Definition 8 [Accumulative Transaction Score (ATS)]: Risk computation does not require the involvement of an The ATS is calculated as the average risk of (ADRS, ASRS, expert. (3) Correlation of past transactions: Risk score LSRS) of the two transacting entities. correlate transactions with current one. Receiver-ATS=∑Receiver(ADRS,ASRS), We have developed an algorithm to assigning weights to Originator-ATS = ∑ Originator (ADRS, ASRS). relations, the so-called Dynamic Relation Extract Algorithm ATS = AVG (Receiver-ATS , Originator-ATS). (DREA) [14] that searches the SNA DB “SuspectWeight” for the detected past n ML activities of the entity A. The algorithm STIDS 2013 Proceedings Page 75 Definition 9: Comprehensive Transaction Data (CTD): The required depth. Finally, we tested the detection and evolution triple (LSRS, ASRS, ADRS) is said to be the comprehensive of “Full-Trail”s by feeding trails generated from various transaction data (CTD). laundering strategies used in our sample real-life cases. Thus, our comprehensive dynamic risk model consists of two The process of creating the “Full-Trail” started with parts, computing the static risk, as by amending the BSA risk creating an MLS type out of the six MLS types of Smurfing, model [9] and computing the dynamic risk per every Trading, DirtyEFT, Stock, Derivative, E-Money. Once the transaction. Figure 4 summarizes the two aspects of our risk selection of first MLS is made, we create ta series of linked model and the data used compute the individual components. MLS based on conditions such as geography, amount of As the figure shows, the static risk score is summarized in the money, time, complexity of the schema and difficulty of accumulative static risk score (an enhancement of the BSA tracking. The trails were created using different criteria and model) and the Dynamic risk score that takes the originators randomizing them using a normal distribution. We created the and recipients running averages of static risk scores and other Full-Trail feeds using the generator to not exceed 10 levels of properties of the transactions and SNA information to compute depth of linked MLSs. These trails were either a variant or a a dynamic risk value per each transaction. As stated, this value subsection of one of the real-life cases that were similar in is fed back to the running averages and variances of this static terms of complexity and participants. risk scores. This latter step requires the financial institutions to At the normal speed of one event at one time tick of the share such risk estimates along with transactions. CEP system, the test result in zero false positive rates and false negative rates. It is highly improbable to get a false positive V. VALIDATION trail due to the business rules that define them, and due to the We used sanitized real-life cases to test and validate the accuracy and granular level of linking transactions. We did not dynamic risk model with MLEDF and transaction scoring. Our get any false positive rate (FPR) or false negative rate (FNR) in case studies are based on data provided from an organization the MLS tests due to the synthetic nature of the data. When we we refer as Trusted Third Party (TTP), which is authorized to increased the speed of the data generated to 10 times and 100 collect information and track records of financial exchanges. times the normal speed, we observed a FPR and FNR in the objects detected in the Full-Trail algorithms. Increasing the A. Experimental Evaluation and Valiation of MLEDF speed of processing did not produce FPR and NFR for a single We introduced a three phase testing prototype to examine MLS, but it produced FPR and FNR for MLS pairs at speeds MLEDF and detection algorithms. All three phases focused on that were multiples of 100s. The term “object” in this graph testing and validating the components of MLS, Full-Trails, and refers to the three different patterns of single MLS, pair MLS, Suspicious-Trails. The first phase focused on testing all and Full-Trail in the proprietary test of the specific object components and the other tests focus on Full-Trail and (Object in the first pattern tests to the first pattern single MLS, Suspicious-Trail components. in the second to MLS pair, in the third to Full-Trail). The Test without noise: This test is designed to test every values of FRP and FNR reflect the number of falsely detected module of MLEDF, including detection algorithms and trail objects. analysis modules. These tests evaluate the false positive rates Test with subtle noise: This is the most relevant accuracy (FPR) and false negative rates (FNR) by comparing the results test of our detection algorithms. The goal of this test was to of the test with the data feed that contains the patterns of mislead the detection algorithms by generating false positives single MLS, pair of MLSs, and Full-Trails. The desired result and false negatives synthetic data. The test had three separate was to have a list of the validation result identical to the list in phases: injecting the scheme participants, injecting subtle transactions, and inserting similar MLSs. A subtle transaction the data feed. We tested the efficiency to keep up with the is a transaction with ±5% of an actual transaction amount in a speed of the data feed by using the time window feature in the MLS. A similar MLS is identical to a real-life MLS with the StreamBase [10]. By setting the time window to glide over same set of participants but with the MLS value is ±10% of the only one event at a time tick in the StreamBase system, we laundered amount of the actual MLS. The injection speed was made the detection algorithms to run at the normal speed of set to normal processing speed, 10 times faster, and 100 times one event at one time tick. By design, an algorithm that cannot faster. The test of injecting transactions and MLSs is setup attain the speed of event production will not be able to capture considering each MLS type. For example, in the test of MLS events or the Full-Trail, thereby generating false smurfing, we created only smurfing MLS and smurfing negatives. transactions that can extend vertically up to 20 levels of depth Each of the six detection algorithms were tested with their and horizontally to 30 levels of depth. When we were own data feeds in order to verify that we were able to detect a generating the MLSs our measures did vary based upon the single event MLS without false positives and false negatives. MLS. We did not use artificially created none-real life cases. The algorithm-specific dataset feed was generated using the For example, we did not use a smurfing MLS with 100 levels built in feed generator working with our pattern specific event deep, as that is uncommon and impractical to launder money. generator. Afterwards, we tested the “Missing-Trail” by We also did not inject other types of MLSs into the injection feeding linked pairs of MLSs into the MLEDF. The test of a specific MLS. However, in the Full-Trail test, we linked/related pairs are randomly selected from the set of six injected all types of MLS because by design, a Full-Trail is types of MLS. As mentioned, any pair of linked MLS will required to have different types of MLS under the same Full- make it to “Missing-Trail” and not into “Full-Trail”, due to the Trail. STIDS 2013 Proceedings Page 76 The test produced low FNR and low FPR for transaction The test were repeated the process of trail generation forever at and MLS injection when the phases were executed at normal the maximum possible speed. (5) The testing module saved the processing speed. Those rates increased in the phases when arrival time of the last DirtyEFT and subtracted that from the tests were executed at faster processing speed. One way to build times of the trail, thereby obtaining Milliseconds imitate the data rate of real production environment is to run difference in trail processing times. the CEP tests at a faster rate, thereby overloading the system Our data was generated for worst-case scenarios to ensure with processing and analytics while attempting to keep pace that they are more complex and the performance was evaluated with the data stream. The goal was to evaluate the effectiveness only in most resource consuming cases. Displayed results of “Full-Trail” detection when the system absorbs data at a represent the performance of data generated without any higher rate while performing the analysis. Due to the design repetitive bosses or associates. Hence, the dataset consumes a methodology of detection algorithms and the complexity of the significant number of resources. business rules of MLS detection, their false detection rates stayed at low levels (less than 5%) even with injection similar 1.0%$ transactions and MLSs, at a higher data-feed speed (1000% and FPR$ 10000% speed). 0.0%$ FNR$ Meeting the design principles, the “Full-Trail” and 10&Depth$ 20&Depth$ 30&Depth$ “Suspicious-Trail” results remained at low rates for both false Figure 5. False Positive and False Negative Percentages of Test III positive and false negative. Therefore, all the subtle single MLS created with injected data ended in the “Missing-Trail”, where they did not exceed the depth of 3 consecutive MLSs. 800000.0$ Some reasons for this success in trail analysis and avoiding any 0.0$ negative impact are (1) MLEDF is designed in a strict and Average$ granular method, especially for matching MLSs within trails, processin Objects$ Objects$ Trails$ (2) SNA is used in the trail analysis algorithms, (3) Adopted g$time$ Sent$ received$ detected$ (milis)$ the criterion to follow the direction of the flow of the laundered-money. MLS is not expected to terminate with funds 10&Depth$ 48.9$ 230000$ 228635$ 23000$ remaining in the account. The money must flow in some 20&Depth$ 47.8$ 360000$ 358726$ 18000$ direction in order to be laundered, or must be withdrawn by the 30&Depth$ 40.7$ 720000$ 718266$ 24000$ launderer. The Figures 5, 6 and 7 show the results of the number (quantity) of the transactions resulted in false positive Figure 6. Number of Detected Trails in Test III for Faster Data Rates and false negative, as explained in the previous paragraph. The figures show the number of FP and FN patterns of each phase from the three injection phases of the Test II, along with the MLS/second$ Objects/second$ results from running the test at different speed (1000% and 10000% speed). 11.54$ 30&Depth$ 626.90$ Test with longer synthetic full-trails: This was the hardest 20&Depth$ 20.79$ 765.01$ level of performance testing of the system and accuracy-testing 10&Depth$ 30.86$ 598.66$ of the detection algorithms we carried out. In this test, the dataset was permutated over a repository of different real-life cases. Afterwards, the dataset was combined with randomized Figure 7. Pattern Generation Speed for Test III MLS to generate deep vertical levels of “Full-Trail”s and B. Experimental Evaluation and Validation of Money “Suspicious-Trail”s. The randomization followed the same Laundering Dynamic Risk Model principles used in Test II’s injection testing. The test was designed to assess the performance of MLEDF in capturing Test Methodology: We introduced a four phase risk model real-life data and analyzing them on the fly. The desired test testing prototype to examine the three different versions of result was to generate low FPR and FNR. The test module static risk model, and the dynamic risk model: (1) T1: Using generated all synthetic data from real-life cases and tests were standard average instead of the exponential average in similar to real-life scenarios, considering that there are limited calculating static risk. (2) T2: Using exponential average, but ways to manipulate a MLS. The test program functions as applying only penalty and no reward in calculating static risk. follows: (1) Set a trail depth. The program enters a loop and (3) T3: Using exponential average, apply both penalty and builds a trail by choosing a first scheme from of each MLS reward in calculating static risk. (4) T4: Using detected type at random, as it was described in Test I in building the schemes, from the output of MLEDF, to produce dynamic risk Full-Trails. (2) The loop continues by creating an MLS that can scores. be linked by funds, time, location and complexity to the current Injected Data Phases: Four different types of transactions MLS. We repeated the step above with the exception of not were injected in each of test phases with LSRS value of (10, creating any Smurfing MLS for the rest of the levels. (3) The 20, 30, 40) in the transactions of each test. permutation continues until the system reached the last level, Test Goals: (1) Produce risk levels above certain threshold where we always choose an MLS of type DirtyEFT with a for continuously riskily transacting entities. (2) Effectiveness withdrawal in order to generate the trail termination point, as when certain patterns (all high risk or all low risk) were by definition a trail will end with the withdrawal of money. (4) injected, (A) Does the ADRS/ASRS saturates at some fixed- STIDS 2013 Proceedings Page 77 point level? (B) False Positive (FP): ADRS/ASRS continue to VI. CONCLUSIONS grow towards the high risk level of the continuously injected We implemented a multiphase, multilevel, and multi- data (C) False Negative (FN): ADRS/ASRS deviates towards component methodology to detect evolving money-laundering the low risk level of the continuously injected data (D) schemes using known methods, influenced by economic Maintain a desired risk level for bad entities even if they factors. We have created a framework to detect the evolution of deliberately transact with good entities, in order to lower their MLS and implemented a system to include SNA for detecting risk profile. and linking related ML networks. This linkage will function Results: The dynamic risk model (T4) produces FP for properly even when all evidence is unavailable. We defined the transactions of none-MLEDF entities. The rate was less than choreographies that could be used to detect the evolution of the 5% and that was satisfactory considering the large amount of sophisticated MLS. We have shown how to detect and capture transactions. This is advantageous compared with risk models the evolving and complex trails of MLS using SB. that do not assess the risk of being involved in MLS, We enhanced the BSA inspired static risk with aggregated considering the factors of increasing risk scores of MLEDF static risk, to reflect the changing dynamics of the ML and its entities. consequences on the risk calculation. Our risk model factors in Validation Statement: We used the StreamBase Studio [10] the initial account-opening risk as well as subsequent platform in each test of (T1, T2, T3, T4) and with each of the transactional risks, and it presents a risk score that is valid four data injection phases (by only injecting entities did not within and outside the boundaries of a single financial exist in MLEDF). The false negative rate was below 1% in institution. We extended the static risk model to develop a phase 1 of all tests, and 0% in remaining three phases of data MLEDF-dependent risk modeling, in order to produce a injection for all tests. The false positive rate was below 5% for comprehensive ML risk modeling in combination with the T4, and lesser for other the three static tests (T1, T2, T3). In aggregated static risk model. The aggregated static risk will be test T4 and with each of the four data injection phases by completed with integration of the MLEDF-dependent risk injecting entities did exist in MLEDF. The false negative rate modeling, which captures the hidden, and dynamic, relations for T4 (When only injecting entities that are already detected among none-transacted entities. Such a risk model is used to by MLEDF) is the highest at 11% when entities with high static create a valid and accurate transaction scoring system to be risk (of LSRS 30) are injected in phase 4, then at 9% in phase 1 used in a ML prevention system. when high static risk score (of LSRS 25) are injected, then at REFERENCES 8% in phase 3, and finally at 3% in phase2 when low risk score (of LSRS 10) is injected. The false negative rate is 0% in all [1] C. Weinstein, W. Campbell, B. Delaney, G. O'Leary, “Modeling and detection techniques for Counter-Terror Social Network Analysis and phases of test T4. Table V summarizes our findings. Figure 9 Intent Recognition,” Aerospace conference, IEEE, 2009. shows the false positive and false negative rates for injecting [2] Financial Action Task Force, “Global Money Laundering & Terrorist MLS’s with 10, 20, 25 and 30 LSRS values. Financing Threat Assessment Annual Report,” February 2013. TABLE V. NUMBER OF TRANSACTIONS WITH FN AND FP RISK [3] D. Schwartz and T. Rouselle, “Using social network analysis to target Transaction Injection/Test Type T1 T2 T3 T4 criminal networks,” Trends in Organized Crime, 2008. Total Generated Transactions 240387 240387 240387 240387 [4] Financial Action Task Force, “Money Laundering & Terrorist Financing Originators not from MLEDF 227 227 227 227 Risk Assessment Strategies,” June 2008. Originators from MLEDF 59 59 59 59 [5] Wolfsberg Group, “Guidance on a Risk Based Approach - Wolfsberg Unique Receivers 936 936 936 936 Principles”, 2006. Injected MLEDF Transactions 9851 9851 9851 9851 [6] Scor Inc, “The risk of money laundering: Prevention, challenges, FP- Phase1- Growing Risk 9 17 14 26 outlook”, 2008. FN- Phase1- Declining Risk 0 0 2 0 [7] Kount Inc, “Dynamic Scoring and Rescoring”, 2011. FP- Phase2- Growing Risk 2 8 3 12 FN- Phase2- Declining Risk 6 1 2 0 [8] M. Mehmet and D. Wijesekera, “Detecting the Evolution of Money FP- Phase3- Growing Risk 7 14 10 21 Laundering Schemes,” IFIP WG 11.9 Conf. on Digital Forensics, 2013. FN- Phase3- Declining Risk 0 0 0 0 [9] BankersOnline, “Risk Rating - Commercial Risk Rating Spread-sheet”, FP- Phase4- Growing Risk 14 28 20 44 http://www.bankersonline.com/tools/bc_commercialriskrating.xls FN -Phase4- Declining Risk 0 0 0 0 [10] StreamBase, ‘Powerful Real-Time Architecture for Today’s High Performance Modern Intelligence Systems’, Federal Government, Defense, and Intelligence Applications, 2012. 5.00%$ FPR&$Phase1$(Inject$LSRS$ [11] FinCEN (2013), Answers to Frequently Asked Bank Secrecy Act 4.00%$ 25)$ Questions, accessible via FPR&Phase2&$(Inject$LSRS$ http://www.fincen.gov/statutes_regs/guidance/html/reg_faqs.html . 3.00%$ 10)$ [12] FinCEN (2013), Bank Secrecy Act Requirements - A Quick Reference 2.00%$ FPR&Phase3&$(Inject$LSRS$ Guide for MSB, 20)$ 1.00%$ FPR&Phase4&$(Inject$LSRS$ http://www.fincen.gov/financial_institutions/msb/materials/en/bank_enc 30)$ e.html . 0.00%$ T1$ T2$ T3$ T4$ [13] Office of Foreign Assets Control (OFAC) (2013), Designated Nationals List (SDN), http://www.treasury.gov/ofac/downloads/ctrylst.txt and Figure 8. False Positive Rate for each risk models after data injection http://www.treasury.gov/ofac/downloads/t11sdn.pdf . (none-MLEDF Entities) [14] M. Mehmet, Money Laundering volution Detection, Prevention and Transaction Scoring, PhD Dissertation, George Mason University, 2013. [15] Hawala, http://en.wikipedia.org/wiki/Hawala, refereed on 10/13/13. STIDS 2013 Proceedings Page 78