The Other Elephant in the Room: Defeating False Negatives in AML Systems

Editor's Note: This article originally appeared on the DataVisor blog on March 5, 2017.

False positives have a terrible reputation among anti-money laundering (AML) circles. As mentioned in my previous article on ending the false positive alerts plague, approximately 90-95 percent of alerts generated by Transaction Monitoring Systems (TMS) are false positives. So, why don’t we tighten our rule thresholds to let fewer alerts through?

Unfortunately, tightening thresholds typically increases false negative alerts, which are real money laundering activities that the TMS didn’t catch. Though false positive alerts lead to high operational overhead, false negative alerts can cost you both in reputation and in major fines and penalties. As AML teams know, regulators have no qualms handing over hefty fines, which have risen considerably in the last decade.

Source: https://www.wsj.com/articles/no-more-regulatory-nice-guy-for-banks-1419957394

The fight against producing false negative alerts while trying to manage false positive alerts is like playing the world’s worst game of AML whack-a-mole. Just when you think that you’re fixing one of the problems, the other pops up with a vengeance. This begs the question: is it possible to reduce false negative alerts without increasing false positive alerts?

Is it a snake or an elephant? Seeing the whole picture

To answer this question, we first need to understand the root cause of false negative alerts. Think about the three general steps for a money laundering scheme: placement, layering, and integration. The big reason for false negative alerts is that most TMS only look at the symptoms of money laundering rather than the whole picture.

For example, an existing TMS might implement a rule that triggers if an account has multiple transactions close to, but less than, $10,000. A sophisticated money launderer knows about these rules, so they get around them by using stolen identities, multiple accounts, different transaction types, and low transaction amounts. Ideally, the TMS would not hard-code a cut-off threshold. Rather, a more sophisticated TMS would find the suspicious patterns to conclude that one person is behind the 100 accounts that are transferring money to each other.

Trying to catch money laundering with the current rudimentary rules systems we’re used to is similar to the parable of the blind men trying to identify an elephant. One blind man feels the trunk and thinks it’s a snake. Another feels a leg and thinks it’s a tree, and so on. Without a global picture of what’s going on, it’s impossible to spot the real money launderers (the “elephants”). The TMS is blind to many of the suspicious signals that money launderers unknowingly broadcast.

The Solution: global network detection with unsupervised machine learning (UML)

The solution to the false negative alerts problem is using unsupervised machine learning (UML) for global network detection. UML can view all of the activity at once, and in the context of all other accounts and activity. This is accomplished by linking accounts and activity together, which makes sense to humans but cannot be accomplished efficiently and comprehensively by existing TMS. By linking accounts, UML can detect hidden global networks of money laundering activity.

To understand what global network detection is, consider this example. Say Client A sends a payment to Client B, who then sends a payment to Client C. In current TMS, Client C’s demographic profile and other payment activity would not influence the rules contributing to an alert for Client A.

However, UML can uncover this undetected hidden link. Not only is Client B associated with Client C, but Client A is as well. Of course, this is an oversimplified example. Hidden links can be created with some combination of thousands of data fields to connect seemingly unrelated accounts and customers. The below image, which you may recognize from my first post, depicts customers which are linked based on shared demographic information such as an email address, physical address, phone number, internet protocol (IP) address and a common beneficiary.

The manual alerts queue will also change. Rather than looking at the account level, items in the review queue may contain multiple accounts, each with their own set of events. These accounts will be suspiciously linked in several ways. Ultimately, a human investigator will review what abnormal patterns were presented to them, but this approach saves the investigator time by not needing to manually comb through data and discover new patterns. Imagine the time savings if, instead of reviewing 100 alerts individually, you can review one hidden network with 100 linked accounts at once. Further, with all of the information presented upfront, there’s a much lower chance of accidentally missing something.

Ultimately, the major benefits of UML and global network detection make the decision clear. AML teams need to push themselves to embrace this new technology. By doing so, AML teams will:

1. Have the sophistication required to see the bigger picture, taking hundreds to thousands of attributes at once
2. Automatically adapt to new suspicious activity patterns and products launched
3. Have more information about each account is given, reducing the time required to consolidate information for a case
4. Triage many accounts and their coordinated activity at once, reducing the items in their queue

Existing TMS are too rudimentary to effectively catch money launderers, who are very good at quickly adapting and blending in. Money launderers have no choice but to be very careful and effective; the stakes are very high if they get caught. It’s up to the AML community to raise these stakes even more, and deter these money launderers from using our financial systems to funnel illicit funds.