- Money laundering evolves using multiple layers of trade, multi trading methods and uses multiple components in order to evade detection and prevention techniques. Consequently, detecting money laundering requires an analytical framework that can handle large amounts of unstructured, semistructured and transactional data that stream at transactional speeds to detect business-complexities, and discover deliberately concealed relationships. Based on our prior work and a static risk model proposed in the Bank Security Act, we propose a dynamic risk model that assigns a risk score for every transaction being a potential component of a larger money-laundering scheme. We use social networks to connect missing links in such potential transaction sequences. Taken together we can provide a financial sector independent risk assessment to submitted transactions. The proposed risk model is validated using data from realistic scenarios and our already developed money laundering evolution detection framework (MLEDF) that we developed earlier using sequence matching, case-based analysis, social networks, and complex event processing to link fraudulent transaction trails. MLEDF has components to collect data, run them against business rules and evolution models, run detection algorithms and use social network analysis to connect potential participants.
Money laundering (ML) is a major issue for the Department of Homeland Security (DHS) and US Treasury. 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’ to social and business relationships to help complete missing links in potential money laundering chains.
The Financial Action Task Force (FATF) provides a static risk assessment of ML [4] strategies to examine ML related predicate crimes and known weaknesses of anti-money laundering (AML) systems. The Wolfsberg Group, made up of eleven leading international banks established standards, guidelines and a discretionary risk model [5] to counter money laundering. Both FATF and Wolfsberg Group say that monitoring customers is an essential part of countering money laundering and suggest that risks can be measured using metrics such as “Country risk”, “Customer risk”, and “Services risk”, and leave weights assigned to each of these categories at the discretion of the evaluating organization. Based on these guidelines, banks use a quantitative model to evaluate transactional risk using attributes such as “Customer profile”, “Product/service profile”, and “Geographic profile”.
The static risk model developed by Scor [6] accepts ML to be determined by “Agility” of adopting new rules per customer, “Complexity” of transactions and the “Secrecy” of transactional information and customer account” [6], but fails to assess other factors such as relationship networks, and dynamically changing factors. Kount [7] developed a dynamic scoring service to continuously monitor indicators of fraudulent credit card activity, and alert merchants of approved transactions that are linked to suspicious purchasing activities, that usually occur after identity theft. These suspicious purchases refer are transactions patterns that have never been witnessed before, such as the purchase of video games by senior citizen.
The rest of the paper is organized as follows. Section 2 describes the Money Laundering Evolution Detection Framework (MLEDF). Section 3 describes the SNA algorithm. Section 4 describes the dynamic risk model. Section 5 evaluates the performance of the MLEDF and dynamic risk model using real-life cases. Section 6 concludes the paper.
II.
Fig. 1. Money Laundering Evolution Detection Framework
First we briefly describe how MLEDF works [8]. Obtaining data streams from multiple sources listed in the left hand column of Fig.1, using a complex event processing system. MLEDF uses four phases where output from one phase is used by the following phase and shown in the columns of Figure1.
(
(
(
(
III.
SOCIAL NETWORK ANALYSIS IN MLEDF
In many cases money launderers intentionally obfuscate the money trail either by hiding it (for example by increasing the number of transactions and reducing the transacted amount), or using an unreported method such as a Hawala [15] (an honor based exchange system without records). As a solution, we use a social network among money launderers to link MLS trails when evidence of linkage is missing among transactions.
The critical question of ML experts is “How fast and how well can we relate the different events in this universe of detected MLS?” Using the Complex Event Processing (CEP) system StreamBase, we developed an algorithm to create chains of related MLSs where social or professional relations are used to transfer a fund to the next MLS until it reaches the final destination where the End Boss withdraws the money. If we modeled all of the chains as a separately and link them we run into a scalability issue in associating the multitude of different events of various MLSs. As a solution, we model each detected MLS as an event, and have various patterns of events categorized under six different types of MLS. For example, Full-Trail algorithm outputs a trail by using the functionality of CEP of perceiving the MLSs as a set of events. Without the CEP the MLS should dissolve into the constituent transactions to be analyzed and linked with other transactions from another MLS, consumes processing time and resources. The CEP can link MLSs, perceived as events, using various criterions without the need to add more complex sub-algorithms for each criterion. That is, the Full-Trail connects the dots that exist, but it is harder and slower to connect them without CEP capabilities. Full-Trail captures the trail in cases where all evidence are available, whereas the Suspicious-Trail attempts to construct the path where some edges along the path is missing.
The “Suspicious-Trail” module is used to detect components of an actual “Full-Trail” even if there is a missing piece of evidence. This module investigates all available trails (Full-Trail and Missing-Trail) by using our SNA DB that contains the weights of relationships among MLS participants in order to determine if two trails are related by considering some attributes such as the amount of funds involved, location, affinity of participants, time, and methods used for laundering. Hence, the “Suspicious-Trail” module uses the “SNA” module to produce a new trail containing two or more trails that are related based on SNA even when we have not captured a transaction joining them or any other evidence. The new trail is created after making a calculation based on (SNA) results of a possible relationship between two or more Full-Trails and Missing-Trails. The generated evolution patterns and strategies are collected into the “Suspicious-Trail” Database.
The architecture of the social network algorithm is shown
in Figure 2. The SNA module generates and continuously
updates two databases as outputs. The “SuspectWeight”
database contains the weight of all relations detected in the
MLEDF and the “Relations” database containing the time and
the record of all detected relations among pairs in MLEDF as
shown in the bottom of Figure 2. The relations we capture are:
(
Other strong relationships are also counted where “Family” ties will add 250 to the couple, and each “Business” relationship will add 250 to the couple. We chose the weights and, verified them in a limited engagement with a trusted third party (see Section V), but can be changed in Algorithm 1.
In the SNA Algorithm given in Table II, steps 1 and 2 define the hash function, and input and DBs constants associated with the different weights and the hash functions. Steps 3 and 4 create hashes for “Boss-Boss”, “Boss-Associate”, and “Associate-Associate” of MLSs. Steps 5 and 6 create the same hashes for Full-Trails. Steps 7 and 8 create hashes for Missing-Trails and special relations (of family and business). Step 9 computes the WeightOutput of a hash HRel. Sample Suspect Weights obtained from Algorithm 1 is shown in Table IV. This corresponds to Relationships given in Table III.
Existing AML systems do not relate different products types, entities, and business lines involved in different combinations of complicated ML schemes. Industry specific AML systems use industry specific static risk models and therefore do not capture known dynamics of MLS evolutions. Countering ML and other forms of fraud requires industrywide risk analysis method to where the risk score is updated dynamically and include transactional behavior related to the ML, such as the social relations and past associations with money laundering. Therefore, we create a dynamic risk model that incorporates the static attributes used by others, such as the senders and recipient’s static profiles and dynamic social connection attributes of the transactions that we capture in our MLEDF system.
The Currency and Financial Transactions Reporting Act (CFTRA) of 1970 later amended to counter money laundering and financial crimes [11, 12, 13] and again amended by Title III of the PATRIOT Act of 2001 and other legislations, and is now commonly referred to as the "Bank Security Act" (BSA) mandates banks to monitor transactions and maintain records of initial and periodic risk scores for customers. Their risk model identify and analyze specific “products and services”, “customers and entities”, and “geographical locations” and categorize them as “high", "medium", and "low", and add the risk rating of all categories to obtain the overall accumulative risk score. We enhanced the BSA inspired static risk with aggregated static risk to reflect changing dynamics of ML and its consequences on the static risk calculation shown in Figure 3. The risk rates assigned in Figure 3 are obtained from [9], with suggested enhancements in the upper right hand box. Definition 1 captures these attributes and scores.
Definition 1 [Local Static Risk Score (LSRS) and Risk Categories]: The Local Static Risk Score is the sum of the following attributes and their assignable integer values; Account Risk Range:[-5,+10], Location Risk Range: [-1,+10] Business Risk Range: [-15,+20], Product Risk Range: [0,+5]
Here Account Risk is the sum of Customer Risk [-5, +10] and Tax ID Risk [+5]. The Location Risk is the Sum of Primary Location Risk [+2]. The sum of the Risks of Non Primary Locations, where each Non Primary Risk is a value in the Range [-1,+10]. The Business Risk is defined as the sum of Business Primary Risk [-3, +20] and Business Nature Risk [-15, +20]. The Product Risk is the sum of Debit Activity Risk [0, +5] and Credit Activity Risk: [0, +5].
The BSA risk score is the sum of the component risk scores of Account Risk, Location Risk, Business Risk and Product Risk. Each of these components risks are also sums of further sub components as specified in Definition 1. Possible computed value for a customer is an integer value for between 23 and +20. The details of risks used in Definition1 are as follows. The Account Risk is the Risk due to customer’s reputation and a risk assigned due to providing / not providing a TAX ID. The Locations Risk is the sum of having multiple business Locations, and the risk associated with the Primary business Location. The Business risk is the sum of the risk due to the Principal Owner and the risk associated with the Nature of the Business. The financial product risk is associated with 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 calculated score: Low [-23, 4], Moderate [+5, +14], High [+15, +30], Extreme Risk [+31, +153].
To compute the risk of transacting customers, in addition to Static Local Risk Score (LSRS), risk of recent transactions need to be taken into account. We propose a simplified mechanism of exchanging aggregate risk scores assigned to customer transactions, because a running average may not expose all the data of all transactions and therefore may not violate privacy. Formally, let TRN(O,R), be a transaction with originator O and recipient R, and let TRNA ≡ <TRNA1(x1,y1), TRNA2(x2,y2),, …… , TRNAn(xn,yn)>, listed in newest to oldest transaction order represent the last n transactions of A. Let Partneri(A,TRNAi(xi,yi)) represent the entity other than A and <LSRS(Partner1(A,TRNAi(xi,yi)))>be the LSRS values of partners of A in the last n transactions. Then recursively define the Exponential Moving Average (EMA) risk as: EMA(i) = LSRS(Partneri(A,TRNAi(xi,yi)))* k + EMA(i-1) * (1 – k) where k = 2/(n+1) .
Definition 3 [Receiver’s/Originator’s Average Risk and Variance]: These averages are calculated by the bank that holds the account of entity A, it is done by calculating the exponential moving average of the LSRS of the last n transacting partners of A, Let EMAi be LSRS(Partner1(A,TRNA1(xi,yi)))* k + EMA(i-1) * (1 – k) where k = 2/(n+1), and where A=xi for all i<n. Let VarA be LSRSA– Average(LSRS(Partner1(A,TRNA1(x1,y1)))), …, LSRS(Partnern(A,TRNAin(xn,yn))).
As with the Average, VARAi computes the receiver’s and originators risk based on the value of Partneri(A,TRANAi(xi,yi)). When Partneri(A,TRANAi(xi,yi)) = A= Receiver for all i<n. Then EMAi computes the receiver’s risk and When Partneri(A,TRANAi(xi,yi)) = A= Originator for all i<n. Then EMAi computes the originator’s risk. The RA/OA parameters assess the risks associated with the participation/involvement of an entity in the ML, by analyzing the affinity/role in the money-flow of a laundering process. The RA and OA used to calculate/keep a record of the historical activity and the divergence in pattern of receiving or sending funds. The pattern are used as an indicator for assessing a risk penalty, comparing the current RA/OA value with the value of 90 days and 180 days ago (RA/OA) indicate the transactional tendency of the entity.
We assign a penalty and reward system for entities so that an entity that continuously transacts in high and increasingly risky pattern is subject to penalties for having an increased LSRS, and vice versa. Thus our penalty and rewards system self-adjusts and the leverage provided by this self-adjustment avoid maintaining the risk value of an entity at a static level. The penalty can be set upon the needs of the financial institution and the regulations of the country, although optimal levels are shown in the formula below. The optimum penalty/reward are produced to allow entities to retain their old static risk levels in between one and n transactions. The criteria defined below indicate that if the aggregate risk sores is higher than 90 days ago which is higher than the same value 180 days ago this entity’s transacting risk is on the increase.
Definition 4 [Penalties and Rewards]: We define RA0M, RA3M, RA6M, OA0M, OA3M, and OA6M to be respectively the current, three months, and six months old values of RA and OA value, for any entity. Let RA-Inc, RA-Dec, OA-Inc and OA-Dec be defined as (RA6M<RA3M<RA0M), (RA6M>RA3M>RA0M), (OA6M<OA3M<OA0M), and (OA6M>OA3M>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 (RA-Dec)/\(OA-Dec)/\(RA>LSRS)/\(LSRS>35)/\(RV<5)/\(OV<5)=> SRPR=-2 (RA-Dec)/\(OA-Dec)/\(RA<LSRS)/\(LSRS>35)/\(RV>5)/\(OV>5)=> SRPR=-3 ((RA-Any)/\/(OA-Any))/\ (RA<LSRS) =>SRPR=0
A detailed rationale for this definition is described in
[14]. The LSRS will be calculated every time the transaction
occurs. For example, the first line of Definition 4 says that if
conditions (
Definition 5 [Accumulative Static Risk Score (ASRS)]: of an entity is the sum of the local static risk score and static risk penalty and reward. Thus, ASRS =LSRS + SRPR.
C. Accumulative Dynamic Risk Score
The dynamics of none-static risk scoring was designed
considering the following criteria: (
We have developed an algorithm to assigning weights to
relations, the so-called Dynamic Relation Extract Algorithm
(DREA) [14] that searches the SNA DB “SuspectWeight” for
the detected past n ML activities of the entity A. The algorithm
is similar to the algorithm used in the “SNA” module of
MLEDF as explained in Section 2. Using this algorithm, we
assign a risk weight for entity A, for each detected ML activity
in the SNA DB “SuspectWeight” by adding parameters for
each of the corresponding events resulting in the accumulative
risk weight as follows: (
Definition 6 [Receivers’ / Originators’ Dynamic Risk Score (RDRS/ODRS)]: Calculates the aggregate risk weight, based on the relations history of the last n entities (R1,...,Rn) funds receiving from, and the last n entities (O1,...,On) funds originating to the entity A. The average weight of receiving /originating entities is obtained by calculating the average of DREA(R1), .. ,DREA(Rn ) and DREA(O1), .. ,DREA(On ). We produce ODRS and RDRS.
Definition 7 [Accumulative Dynamic Risk Score (ADRS)]: Of an entity is the sum of SDRS, RDRS and ODRS. That is ADRS = SDR+ RDR+ODR.
D. Accumlative Transaction Scoring Based on Dyanmic Risk
Static and dynamic risks are correlated to the analytics of transaction scoring, in order to identify transactions with highrisk score pertaining to ML, and to prevent transaction sequences from being executed. The correlations used in the dynamic risk scoring can be used to detect and track transactions belong of ML schemes.
Definition 8 [Accumulative Transaction Score (ATS)]: The ATS is calculated as the average risk of (ADRS, ASRS, LSRS) of the two transacting entities.
Receiver-ATS=∑Receiver(ADRS,ASRS), Originator-ATS = ∑ Originator (ADRS, ASRS).
ATS = AVG (Receiver-ATS , Originator-ATS). Definition 9: Comprehensive Transaction Data (CTD): The triple (LSRS, ASRS, ADRS) is said to be the comprehensive transaction data (CTD).
Thus, our comprehensive dynamic risk model consists of two parts, computing the static risk, as by amending the BSA risk model [9] and computing the dynamic risk per every transaction. Figure 4 summarizes the two aspects of our risk model and the data used compute the individual components. As the figure shows, the static risk score is summarized in the accumulative static risk score (an enhancement of the BSA model) and the Dynamic risk score that takes the originators and recipients running averages of static risk scores and other properties of the transactions and SNA information to compute a dynamic risk value per each transaction. As stated, this value is fed back to the running averages and variances of this static risk scores. This latter step requires the financial institutions to share such risk estimates along with transactions.
V.
VALIDATION
We used sanitized real-life cases to test and validate the dynamic risk model with MLEDF and transaction scoring. Our case studies are based on data provided from an organization we refer as Trusted Third Party (TTP), which is authorized to collect information and track records of financial exchanges. A. Experimental Evaluation and Valiation of MLEDF
We introduced a three phase testing prototype to examine MLEDF and detection algorithms. All three phases focused on testing and validating the components of MLS, Full-Trails, and Suspicious-Trails. The first phase focused on testing all components and the other tests focus on Full-Trail and Suspicious-Trail components.
Test without noise: This test is designed to test every module of MLEDF, including detection algorithms and trail analysis modules. These tests evaluate the false positive rates (FPR) and false negative rates (FNR) by comparing the results of the test with the data feed that contains the patterns of single MLS, pair of MLSs, and Full-Trails. The desired result was to have a list of the validation result identical to the list in the data feed. We tested the efficiency to keep up with the speed of the data feed by using the time window feature in the StreamBase [10]. By setting the time window to glide over only one event at a time tick in the StreamBase system, we made the detection algorithms to run at the normal speed of one event at one time tick. By design, an algorithm that cannot attain the speed of event production will not be able to capture MLS events or the Full-Trail, thereby generating false negatives.
Each of the six detection algorithms were tested with their own data feeds in order to verify that we were able to detect a single event MLS without false positives and false negatives. The algorithm-specific dataset feed was generated using the built in feed generator working with our pattern specific event generator. Afterwards, we tested the “Missing-Trail” by feeding linked pairs of MLSs into the MLEDF. The linked/related pairs are randomly selected from the set of six types of MLS. As mentioned, any pair of linked MLS will make it to “Missing-Trail” and not into “Full-Trail”, due to the required depth. Finally, we tested the detection and evolution of “Full-Trail”s by feeding trails generated from various laundering strategies used in our sample real-life cases.
The process of creating the “Full-Trail” started with creating an MLS type out of the six MLS types of Smurfing, Trading, DirtyEFT, Stock, Derivative, E-Money. Once the selection of first MLS is made, we create ta series of linked MLS based on conditions such as geography, amount of money, time, complexity of the schema and difficulty of tracking. The trails were created using different criteria and randomizing them using a normal distribution. We created the Full-Trail feeds using the generator to not exceed 10 levels of depth of linked MLSs. These trails were either a variant or a subsection of one of the real-life cases that were similar in terms of complexity and participants.
At the normal speed of one event at one time tick of the CEP system, the test result in zero false positive rates and false negative rates. It is highly improbable to get a false positive trail due to the business rules that define them, and due to the accuracy and granular level of linking transactions. We did not get any false positive rate (FPR) or false negative rate (FNR) in the MLS tests due to the synthetic nature of the data. When we increased the speed of the data generated to 10 times and 100 times the normal speed, we observed a FPR and FNR in the objects detected in the Full-Trail algorithms. Increasing the speed of processing did not produce FPR and NFR for a single MLS, but it produced FPR and FNR for MLS pairs at speeds that were multiples of 100s. The term “object” in this graph refers to the three different patterns of single MLS, pair MLS, and Full-Trail in the proprietary test of the specific object (Object in the first pattern tests to the first pattern single MLS, in the second to MLS pair, in the third to Full-Trail). The values of FRP and FNR reflect the number of falsely detected objects.
Test with subtle noise: This is the most relevant accuracy test of our detection algorithms. The goal of this test was to mislead the detection algorithms by generating false positives and false negatives synthetic data. The test had three separate phases: injecting the scheme participants, injecting subtle transactions, and inserting similar MLSs. A subtle transaction is a transaction with ±5% of an actual transaction amount in a MLS. A similar MLS is identical to a real-life MLS with the same set of participants but with the MLS value is ±10% of the laundered amount of the actual MLS. The injection speed was set to normal processing speed, 10 times faster, and 100 times faster. The test of injecting transactions and MLSs is setup considering each MLS type. For example, in the test of smurfing, we created only smurfing MLS and smurfing transactions that can extend vertically up to 20 levels of depth and horizontally to 30 levels of depth. When we were generating the MLSs our measures did vary based upon the MLS. We did not use artificially created none-real life cases. For example, we did not use a smurfing MLS with 100 levels deep, as that is uncommon and impractical to launder money. We also did not inject other types of MLSs into the injection test of a specific MLS. However, in the Full-Trail test, we injected all types of MLS because by design, a Full-Trail is required to have different types of MLS under the same FullTrail.
The test produced low FNR and low FPR for transaction and MLS injection when the phases were executed at normal processing speed. Those rates increased in the phases when tests were executed at faster processing speed. One way to imitate the data rate of real production environment is to run the CEP tests at a faster rate, thereby overloading the system with processing and analytics while attempting to keep pace with the data stream. The goal was to evaluate the effectiveness of “Full-Trail” detection when the system absorbs data at a higher rate while performing the analysis. Due to the design methodology of detection algorithms and the complexity of the business rules of MLS detection, their false detection rates stayed at low levels (less than 5%) even with injection similar transactions and MLSs, at a higher data-feed speed (1000% and 10000% speed).
Meeting the design principles, the “Full-Trail” and
“Suspicious-Trail” results remained at low rates for both false
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.
Some reasons for this success in trail analysis and avoiding any
negative impact are (
Test with longer synthetic full-trails: This was the hardest
level of performance testing of the system and accuracy-testing
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
MLS to generate deep vertical levels of “Full-Trail”s and
“Suspicious-Trail”s. The randomization followed the same
principles used in Test II’s injection testing. The test was
designed to assess the performance of MLEDF in capturing
real-life data and analyzing them on the fly. The desired test
result was to generate low FPR and FNR. The test module
generated all synthetic data from real-life cases and tests were
similar to real-life scenarios, considering that there are limited
ways to manipulate a MLS. The test program functions as
follows: (
Our data was generated for worst-case scenarios to ensure that they are more complex and the performance was evaluated only in most resource consuming cases. Displayed results represent the performance of data generated without any repetitive bosses or associates. Hence, the dataset consumes a significant number of resources.
1.0%$ 0.0%$ 10&Depth$ 20&Depth$ 30&Depth$
Test Methodology: We introduced a four phase risk model
testing prototype to examine the three different versions of
static risk model, and the dynamic risk model: (
Injected Data Phases: Four different types of transactions
were injected in each of test phases with LSRS value of (
Test Goals: (
Results: The dynamic risk model (T4) produces FP for transactions of none-MLEDF entities. The rate was less than 5% and that was satisfactory considering the large amount of transactions. This is advantageous compared with risk models that do not assess the risk of being involved in MLS, considering the factors of increasing risk scores of MLEDF entities.
Validation Statement: We used the StreamBase Studio [10] platform in each test of (T1, T2, T3, T4) and with each of the four data injection phases (by only injecting entities did not exist in MLEDF). The false negative rate was below 1% in phase 1 of all tests, and 0% in remaining three phases of data injection for all tests. The false positive rate was below 5% for T4, and lesser for other the three static tests (T1, T2, T3). In test T4 and with each of the four data injection phases by injecting entities did exist in MLEDF. The false negative rate for T4 (When only injecting entities that are already detected by MLEDF) is the highest at 11% when entities with high static risk (of LSRS 30) are injected in phase 4, then at 9% in phase 1 when high static risk score (of LSRS 25) are injected, then at 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 phases of test T4. Table V summarizes our findings. Figure 9 shows the false positive and false negative rates for injecting MLS’s with 10, 20, 25 and 30 LSRS values.
We implemented a multiphase, multilevel, and multicomponent methodology to detect evolving money-laundering schemes using known methods, influenced by economic factors. We have created a framework to detect the evolution of MLS and implemented a system to include SNA for detecting and linking related ML networks. This linkage will function properly even when all evidence is unavailable. We defined the choreographies that could be used to detect the evolution of the sophisticated MLS. We have shown how to detect and capture the evolving and complex trails of MLS using SB.
We enhanced the BSA inspired static risk with aggregated static risk, to reflect the changing dynamics of the ML and its consequences on the risk calculation. Our risk model factors in the initial account-opening risk as well as subsequent transactional risks, and it presents a risk score that is valid within and outside the boundaries of a single financial institution. We extended the static risk model to develop a MLEDF-dependent risk modeling, in order to produce a comprehensive ML risk modeling in combination with the aggregated static risk model. The aggregated static risk will be completed with integration of the MLEDF-dependent risk modeling, which captures the hidden, and dynamic, relations among none-transacted entities. Such a risk model is used to create a valid and accurate transaction scoring system to be used in a ML prevention system.