False Positive Reduction Mechanisms: Put an End to the Nightmare

Compliance functions build robust compliance programmes that enable them to answer the board of directors’ basic question: how do I know I am in compliance with applicable laws and regulations?

As part of such laws and regulations, anti-money laundering (AML) and combating terrorist financing (CTF) are positioned as a core responsibility for compliance functions. Mitigation of AML/CTF risk implies adopting a risk-based approach aiming at identifying, monitoring, and when necessary reporting suspicious activities.

With huge volumes of transactions, continuous changes in regulatory requirements, including scanning against enormous number of sanctioned entities and politically exposed person (PEP) lists, in addition to the complicated nature of money laundering activities, AML/CTF technology becomes a basic need for every compliance function as a human approach is deemed ineffective and inefficient.

Consequently, and as any other function in a financial institution (FI) that seeks process optimisation, the compliance function needs an effective and efficient solution to mitigate AML/CTF risk. Systems can be either proactive such as sanction list screening (SLS) on a real-time basis, intending to stop suspicious transactions prior to being executed, or reactive such as the offline profiling solutions that analyse customer profiles to identify money laundering schemes. The efficiency and effectiveness of these systems are interpreted through the rate of false positives and false negatives.

A false positive is basically a false alarm. It is an alert or a detection generated by the system that requires investigation by a compliance specialist, while in reality the scanned name is not the same blacklisted entity (in the case of SLS), or the client is not carrying out a money laundering activity (in case of profiling). The false positive rate reflects the efficiency of the system and its increase results in extra unnecessary human intervention that is extremely costly for institutions. A 2% false positive rate out of one million transactions would result in 20,000 false positive detections, including all the human resources time spent on investigation, as well as the time in which a transaction has been blocked.

Even worse, a 2% false positive rate is just a compliance specialist’s pipedream; in reality the rate could rise up to 60%- 80%. This is the reason behind the statement indicating that the price of the software is negligible when human intervention cost is considered.

A false negative is the exact opposite. It is the case where a real violation is taking place – the transaction is related to a sanctioned entity, or a money laundering activity is taking place – but is not being detected. The false negative rate reflects the effectiveness of the system and is definitely the most risky factor and requires utmost attention. It is false negatives, or even the gaps that may lead to false negatives, that result in enormous fines and penalties with all the consequences on the reputation of institutions.

An ideal situation would be to reach the least false positives rate possible and at the same time avoiding any false negatives. Although not as simple as it may appear, this is still doable through the appropriate use of several mechanisms and techniques embedded in AML/CTF solutions. In the following paragraphs, some techniques and mechanisms are outlined.

False Positive Reduction in SLS

In SLS solutions, false positive reduction efforts can be divided into two axes: appropriate configuration of the solutions and appropriate contextualisation of the scanning process. Appropriate configuration includes limiting scanning to the required lists and using an appropriate scanning rank. Appropriate contextualisation means introducing a context to the scanning process, whether on list entity level (white-listing) or on a transaction flow level (business rules).

Appropriate Configuration

Scanning against required lists only means avoiding unnecessary hits on lists that are not applicable within the regulatory environment in which the solution is running. In a multinational and multi-functional environment, the solution must be multi-dimensional to reflect the organisational structure of the institution, and provide the ability to choose the set of lists to scan against in each specific area (geographical or functional).

Figure 1: Multi-level SLS Solutions


Source: EastNets

The scanning process consists of comparing a scanned text with the blacklisted entities. This is accomplished through a matching engine that ideally includes highly sophisticated algorithms to overcome the issues of spelling mistakes, glued or split words, different methods of writing words, soundex, etc. For each difference encountered between the scanned text and the blacklisted entity, a penalty is granted by the engine to the match rank. When scanning, a user can define a rank which represents the minimum match score of a hit to be returned to the investigator. Any score below such rank will be dropped by the engine.

Setting an appropriate rank threshold is fundamental. Going too high would minimise false positives but increase the risk of false negatives; going too low would help avoid false negatives but drowns the compliance team in the sprawling ocean of false positives.

In reality, there is no magic potion or one-size-fits-all solution when it comes to defining such rank. This rank should be set per list, but also should take into consideration certain customer-based factors such as the scanned text, the lists used and, most importantly, the size of human resources in the compliance function and risk tolerance of the institution. Therefore, a methodological approach should be adopted, in which a representative sample is scanned with several different ranks and the results are analysed to identify the optimum score.

Appropriate Contextualisation
If the algorithms of the matching engine are capable of recognising different ways of writing a name, then a probable side effect would be that the engine mistakenly matches a name (scanned text) to an entity in the blacklist. If this scanned name is a customer that carries out frequent transactions, it is reasonable after the first investigation to exempt your customer by white-listing them in future scanning processes. It is worth mentioning here that the exemption should be precise to a specific entity in a specific list and contextualised, i.e. the customer is considered a ‘good guy’ in the context of a specific address, date of birth, country of residency, etc.

The objective of linking the good guy to a specific entity in the list is to avoid a false negative when this same good guy turns bad and is blacklisted. This way, if the customer is considered a good guy for the first entity, this won’t be the case for the second one.

Another way of contextualising the scanning in order to minimise false positives is the addition of specific business rules on some transaction flows. These rules could tackle the currency of a transaction, the country of origin or that of destination, a threshold, a minimum amount of money or another applicable business rule.

False Positive Reduction in Profiling
In profiling solutions, there are also certain methods that could be implemented to minimise false positives. Below is a quick description of how to do so:

  • Quality of data: The output of the solution is a result of introducing your data into the system to apply the embedded rules, scenarios, risk scoring, etc. Therefore, always start with your own data and ensure it is appropriate.
  • Scenario selection: Select only the scenarios adequate to your business. Start with the most important scenarios, tune them properly, and then build new ones. Having lots of scenarios does not necessarily minimise your risk. If not well chosen, the scenarios will unjustifiably increase the false positive rate.
  • Customer risk classification: Classify your customers according to their risk level and use this classification as a parameter within your scenarios where applicable. For instance, customers with low risk rating need a significant activity to compose a threat that justifies generating a detection.
  • Customer segmentation: Segment your customers based on their size, nature of business, age of relation, transaction type, etc. You can then link specific scenarios to applicable segments only, avoiding consequently meaningless detections. Furthermore, the scenarios should be dedicated either to accounts or to global customer behaviour checks in order to avoid any duplication.
  • Parametric manipulation: After linking scenarios to the appropriate customer segments, the scenario parameters should also be tuned according to the segments chosen; the parameters of the same scenario that is used with several segments should be customised according to the nature of the segment.
  • Multi-scenario model: Introducing the results of a specific scenario into another one would refine the initial results. Consequently, building an adequate multi-scenario model helps drastically minimise false positives.
  • Exemption management: Specific customers within certain segments should not be subjected to the scenario of their segments. This is when they can be exempted. This tool should be carefully used, and only after appropriate due diligence, as it increases the risk of false negatives.
  • Scenarios management: Periodically, it is essential to review the scenarios implemented. By time scenarios might become irrelevant and should consequently be dropped.


Minimising false positives of AML/CTF solutions has become a fundamental activity for compliance functions due to the cost of human intervention. Although not a simple task due to the risk of increasing false negatives, it is still doable. With the appropriate mechanisms implemented, an optimisation can be achieved while remaining within the risk appetite.



Related reading