5 Key Challenges When Tuning AML Transaction Monitoring Software

More and more, regulators are examining anti-money laundering (AML) and terrorist financing monitoring software solutions to see if they are tuned correctly; and citing financial institutions who fail to meet the regulatory standards. One issue for both regulators and these institutions is the creation of excessive volumes of “false positive” activity alerts, or alerts on activity that after evaluation, is not determined to be suspicious. These can undermine the efficiency and efficacy of a compliance program, costing both time and resources to the financial institution. Regulators are also concerned that high volumes of false positives can create a situation where the volume of alerts classified as false positives can erroneously disguise actual illegitimate activity.

On the other hand, financial institutions that perform extensive tuning of AML transaction monitoring solutions to reduce excessive false positives, can also reduce the effectiveness of their monitoring system, potentially subjecting them to regulatory scrutiny, fines, and penalties.

Aligning Models and Data

Effective model tuning starts with an understanding of the model objectives (i.e., the risk to be mitigated or suspicious activity they are trying to detect) and the model function. There are two fundamental aspects of transaction monitoring technology that institutions should take into consideration when tuning their transaction monitoring software:

• Model configuration – Institutions should consider whether the software’s model aligns with their needs as an organization based on levels of risk as well as the products and services it offers. It’s important for the institution to have a clear understanding regarding the risk mitigation objectives and ensure the software model supports these goals
   
• Data feed – Often discussions about AML transaction monitoring solutions stop at the software, but the data feed is equally as important. The data feed must support the model requirements and objectives – i.e., there is no point implementing a model to monitor cash activity if there is no ability to identify cash activity from the data feed. The software needs to be configured with the nature of the data feeds in mind

It’s important for institutions that are looking to invest in new AML software and data feeds to first consider the nature of the institution’s business, the products and services it offers, and its regulatory jurisdiction and customer base.

Finding Errors in the Tuning

Once a financial institution has their AML software and data feeds in place, getting the tuning right can be challenging. Without the appropriate configuration, solutions can either generate too many false positives, or they can be “turned down” so far as to not produce an alert when there is genuine suspicious activity. Five common areas where mistakes can be made include:

1. Conflict between the data and the model – When an element of the data feed conflicts with the way the model utilizes the data errors can occur. For example, if a source system populates an otherwise empty field with a default value, such as an empty country data field defaulting to “NA.” If the target system receiving the data misinterprets the value as “Namibia” the software may think all “no country” transactions originated in Namibia, generating a number of false positive alerts.
    
2. Structuring patterns – The objective of the structuring rule is to identify attempts by a bad actor to avoid regulatory reporting of a large cash transaction by breaking or “structuring” the transaction into smaller amounts below the reporting threshold. However, a businessperson may, as part of their normal operations, coincidentally make a series of deposits in amounts that appear similar to a structuring pattern. In this case, the model needs to be tuned to trigger an alert based on a combination of the pattern of the transactions and the profile of the customer.
    
3. Velocity patterns – The objective of a velocity rule is to identify suspicious activity based on the rapid movement of funds into and out of an account. However, it is not uncommon for a customer to have a normal pattern of receiving a paycheck each month and then immediately paying a high volume of bills. This could trigger an alert because of the velocity of the transactions, when the actual behavior is perfectly legitimate. The software needs to be tuned to take behavior patterns into account to reduce false positives.
    
4. Exclusion lists – Financial institutions will often make lists of customers/entities who they consider to be excluded from transaction monitoring scenarios/rules based on their historical alerts which are ultimately flagged as false positives and mark those individuals as “safe” or as part of a “white list” within their AML software to reduce the number of false positives. While this approach certainly does have its place in reducing false positives, institutions need to be sure they regularly revisit these “exclusion lists” to review the clients and transactions for a potential change in their behavior of transactions. Also, the institution needs to ensure the software’s functionality or handling capabilities when the entry (Customer) is removed from the list. Failure to do regular reviews and re-tuning could result in illegitimate transactions getting through unimpeded, and therefore leaving the institution open to significant operational, compliance and reputational risks.
    
5. Suppression logic – Also called “behavior-based logic,” this is used to prohibit the generation of alerts based on logic or an algorithm. In this case, a suppression might be placed at the AML rule level, or at the level of a group of rules, to reduce the volume of false positives. Suppression logic must be carefully structured to prevent the potential unintended consequence of ignoring genuinely illegitimate behavior. For example, an alert could be generated on the basis of suspicious activity, but suppression logic would suppress future alerts to prevent a flurry of similar alerts. While this would reduce the overall number of alerts, an analyst examining the initial alert would have no knowledge of the subsequent behavior of the client. As a result, there is high possibility that the analyst might mark the non-suppressed alert as a false positive considering the underlying transactions of the current alert, when in-fact the suppressed alerts are part of a pattern of genuinely suspicious activity.

Instead of using exclude lists or suppressing the additional alerts resulting from various AML scenarios, the institution should consider “grouping” the alerts at Customer, Account, Originator, Beneficiary, or Originator-Beneficiary pair level so that the analyst will have full visibility of the suspicious behavior. This approach also helps the financial institutions to review all the suspicious alerts across different AML scenarios at one time thereby saving case analysts time. For example, if a customer received an alert for structuring, velocity and high-risk country rules; with the above said logic of grouping alerts at Customer level, analyst will have to review only one consolidated alert where the complete picture of all suspicious transactions related to the three AML scenarios are captured.

In short, it’s important for institutions to make sure they have AML transaction monitoring solutions that are expertly tuned, to prevent excessive false positives as well and missed alerts. Regulators today expect compliance teams to have AML software tuning expertise in-house, or to be able to access such expertise from outside the organization.