3 Traps to avoid when choosing
your AML/CFT solution

Incomplete coverage of regulatory requirements and software usability issues

Anti-money laundering technologies increasingly involve players with a wide variety of offers.
In order to ensure that you’re safe from the risks of money laundering and terrorist financing, it’s not enough to believe the solution provider when it argues for the solution’s completeness. Instead, you should make sure you dispose of the complete list of features required in such a solution.

After using an AML/CFT compliance software during some months or even less, we can realize very serious limitations. On one hand, there are regulatory limitations that expose users to non-compliance risks. On another hand, there are ergonomic limitations meaning repetitive processes or outright manual and off-system operations. These operations cause a big waste of time and thus a break in the chain which makes it more difficult to track such a critical process.

In what follows, we will summarize in two tables, firstly the regulatory features essential to meet the requirements to which financial institutions are subject to, and secondly the features helping you achieve operational efficiency within the AML/CFT compliance process.

Essential regulatory features

	Component	Requirements
1	Name screening as part of customer onboarding	Search in sanction lists Search in PEP lists Possibility to add connectors to lists according to your jurisdiction. Search in internal lists (very useful when updating names lists communicated by your regulator or your Financial Intelligence Unit (FIU); as these names rarely appear in international lists and in several countries, they are still provided in an unstructured format).
2	Name screening as part of ongoing customer due diligence	Scheduled regular name screening (Automatic trigger) at the specified frequency by your jurisdiction Unscheduled name screening (Manual trigger)
3	Know Your Customer (KYC)	Possibility of customizing the KYC forms in the solution (in order to match it to your jurisdiction’s requirements and to the repositories used in your IS). A module for identifying and managing the beneficial owners of each business relationship A relationship management module. A module for identifying customers subject to the FATCA law. Possibility of managing the regulatory file of each customer (for example: piece of identification and proof of residency for natural persons; legal file for legal persons).
4	Risk-based approach	Possibility of calculating the risk associated with each business relationship and assigning a risk class (generally on three levels: low risk, medium risk and high risk) Possibility of defining a risks matrix associated with each type of business relationship (natural persons, legal persons and non-profit organizations). Possibility of associating risk factors with KYC form data in order to automate risk calculation. Possibility of easily customizing a workflow for high-risk level approval to support the evolution of your institution’s organization. Possibility of updating the risk level based on alerts and suspicious activities brought up about this client (integration with other modules).
5	Transaction filtering	Possibility of real time filtering of domestic or regional transactions against watch lists. Possibility of real-time filtering of international transactions (SWIFT) against watch lists. Possibility of transactions filtering (domestic and international) based on specific rules. Possibility of transactions filtering (domestic and international) based on the risk level associated with the client.
6	Transaction monitoring	Possibility to detect suspicious, unusual and typical ML/ FT behaviors. Mechanisms to help define and validate indicators and thresholds based on Machine Learning or, failing that, on Inferential Statistics. Alerts generation in user-friendly dashboards. Handling all customer KYC data (type, activity, nationality, residency, risk score, etc.) in scenarios. Handling scenarios of monetary and non-monetary transactions. Possibility of aggregating transaction data (sums, averages, peaks, period of inactivity, averages on periods, etc.). Possibility of setting the trigger periodicity per scenario. Possibility for internal teams to work independently on scenarios maintenance and evolution.
7	Suspicious Activity Reporting	Possibility of automatically generating a suspicious activity report and integrating it with your own Financial Intelligence Unit (FIU), handling configurable statuses (sent, decision in progress, regulatory time exceeded, etc.). Possibility of generating suspicious activity reports based on a set of alerts.
8	Confidentiality of exchanges and private data protection	Centralization and securing of data exchanges and confidential probative documents Accesses tracking

User-friendly features and operational efficiency

	Component	Requirements
1	Know Your Customer (KYC)	Possibility of using Automatic Document Reading technologies (ADR, OCR, IRC, etc.) for a fast and efficient feeding of KYC forms.
2	Alerts management	Availability of an investigation center for the supply of all information relating to alert triggering (scenario details and triggering data, customer information, etc.). Integration of the final risk level into the alert management tool (prioritization in alerts processing). Sending emails for specific scenarios (notification on all alerts is useless). Possibility of associating a different, and even better configurable, processing circuit for each type of trigger alert/event.
3	Audit	Allow the logging and traceability of the various actions carried out. Possibility to export the audit report. Possibility to choose the fields to export. Possibility to choose the audit period (start date and end date).
4	Reporting & dashboards	Integration of dynamic dashboards customizable by end users. Possibility of creating decision-making reports based on the processing time of alerts.
5	Collaborative work & workflows	Possibility of associating an approval workflow with different circuits depending on the risk of the relationship, its type, etc. Availability of a workflow engine to model the processing circuit associated with decision-making. Quick creation, deletion and update of processes. Availability of system tasks to execute Runtime operations (sending notification mail, joining documents, etc.). Dynamic assignment of speakers (person/groups). Management of processing forms that are displayed to users when processing a task. Handling single and multiple transitions.
6	Documents management	Possibility of documentary filing per client, per alert and per makingdecision circuit. Control on the parts of Customer Regulatory File.
7	Integration	Possibility of integrating the solution with your ERP to efficiently manage the freezing of funds as for sanctioned customers

Examples of typical technical specifications drawn up by our AML/CFT experts can be provided by your Account Manager. You just need to fill out this contact form or send an email to [email protected].

Name screening software not adapted to search queries

We call a name screening software not adapted to search queries, a software based on an algorithm with non-optimized search results. It either returns a big number of name matchings to be handled, thus slows down the onboarding process or the ongoing vigilance on customers portfolios, or in the worst case, fails in identifying sanctioned and/or PEP persons.

Almost all specialist software providers use now fuzzy search algorithms, which is already a good first step. Any solution based on algorithms for an exact name matching is simply to be discarded given the major risk to which it exposes your organization.

An exact search algorithm will only display a search result, also called a hit, or a match, if the displayed name is typed EXACTLY the same way it was spelled in the sanction/PEP list, which drastically reduces the chance to find the most risky people for your organization. There are always regional differences in typing first and last names. This is also almost the case when it comes to non- Latin names transcription. Example: in the case of Arabic names transliteration, Chinese names transliteration and so on.

Unlike this rudimentary approach, fuzzy search algorithms are able to identify matches even if the typed name’s spelling is different from the one’s shown in the sanction/PEP lists.

This is how it works: the system will use a fuzzy search algorithm (there are several ones!) which will calculate a match rate between the searched name and each one present in the list. If this rate exceeds a certain threshold with one entry in the list it’s searching in, this entry/name will be displayed in the search results.

The issue with these algorithms is that they can sometimes return a lot of false alerts, commonly referred to as false positives. This can be misleading and require a very high processing time, which is undoubtedly disturbing for your organization.

Quite simply, reducing false positives involves two elements:

1- The fuzzy search algorithm used by the software: end users have not commonly access to this part of the software, unless this option is offered by advanced systems to administration roles.

2- The match threshold: this is the match rate at which the system will display an entry in the list as a search result. This threshold is often a parameter that can be specified by the solution’s administrator in order to refine the search results.

In the following, we will introduce the impact of an algorithm not adapted to your daily search queries, trying not to clutter up the content with technical details.

One of the most widely used algorithms is the Levenshtein algorithm whose match rate is measured by the notion of distance between two names relatively to the name length: the minimal number of characters needed to be replaced to switch from a name A to a name B. Here are some examples:

Name A	Name B	Rate	Details
PETER	CHRIS	0%	A gap of five characters
MARK	MARK	100%	A gap of zero characters, so a difference of 0%, consequently a match rate of 100%
AHMED	AHMAD	80%	A gap of one character, so a difference of 20% (one character of five), consequently a match rate of 80%
SELENA	SERENA	83,33%	A gap of one character, so a difference of 16,66% (one character of six), consequently a match rate of 83,33%

You can already note a first inconsistency: how is it that the match rate of two different transcriptions belonging to the same name which are
pronounced almost in the same way (AHMED and AHMAD), is lower than the match rate of two different names (SELENA and SERENA)?

Precision-recall dilemma

Therefore, if your system is configured to show results with a match rate higher than 80%, the false positive result SELENA/SERENA will be displayed, but not the true positive AHMED/AHMAD. Obviously, lowering the threshold to 75% in this case will display AHMED/AHMAD, but pollute the search results with a lot of false positives.

The previous examples show that a strict threshold will lead to greater precision (while discarding possible positive cases). A more lax threshold will lead to a higher recall (while displaying many false alerts). Trying to find an optimal threshold in this case is a waste of time because there is an IRREDUCIBLE ERROR whatever the chosen value.

The point here does not mean that Levenshtein’s algorithm is useless for name screening when fighting against money laundering and financing terrorism. It’s rather not adapted to all contexts and parts of the world (such as Asia, Africa, the Arab world or nationals of these countries living in the West). It is indeed more efficient for searching in Latin languages and it is less efficient outside this sphere since it attributes the same weight to all changes when it may just be a difference in transliteration. It is therefore an inappropriate choice if your client’s name has a non-Latin origin.

Hybrid approach: the best of both worlds

As we have seen previously, classical search algorithms can reach their limits quite quickly, even if we choose the optimal discrimination threshold.
The hybrid approach makes it possible to apply a first iteration which uses one or a combination of algorithms (Levenshtein, common key – phonetics, lists, etc.) with a high recall, and in a second iteration, we refine the results obtained using a very high precision algorithm to obtain matches scores.

In conclusion, we recommend one of the following two approaches:

1. Choosing a software adopting a hybrid search algorithm to adapt to different regions and international clients. This becomes the standard in the market by combining several algorithms (Levenshtein, common key – phonetics, statistical matching, lists, etc.) by weighting their results for a better match rate.

2. Failing the first approach, choosing a software for which you have meticulously validated the false positive rate through a representative sample of your clients and especially its effectiveness in finding right matchings without polluting the search results.

Failure to control the sanction/PEP data used

The management of sanctions and PEP data lists is a subject in its own right. In this section, we’ll only focus on the main choices to make when integrating these lists into your (new) AML/CFT software.

No software is meant to contain the sanctions and PEP lists! But let’s start from the beginning.

Several deficiencies were identified in conjunction with the lists of sanctioned and politically exposed persons, including for example:

1. The quality of the search results is not optimal
2. I cannot find any recently added true positives
3. My screening software is returning to me a lot of false positives
4. The same sanctioned person is displayed multiple times in search results

These can be caused by the ineffectiveness of the name search algorithms used by the screening software as mentioned in the dedicated
section above, but it is generally due to the quality of the data in which your search engine is running, and this is what we will detail in this section.

Let’s first make a difference between data providers and software providers. Compliance data providers, also known as list providers, offer only data and minimal tools to assess the quality of that data. The reverse is particularly true if no AML/CFT solution provider is at the same time a data provider of sanctioned and/or politically exposed persons lists.

Relying on a data provider for a complete compliance solution will not provide the optimal solution you are looking for, neither in terms of regulatory functional coverage, nor in terms of integration with your IS, and even less in terms of cost.

Only for sanction data (and not for PEPs), there is an alternative of official resources, also known as public sources as opposed to private data provided by specialized companies, which are accessible free of charge and updated regularly by the authorities providing them (United Nations – UN, European Union – EU, Office of Foreign Assets Control – OFAC, etc.).

For this official data, it must be collected individually by your software, but no consolidation is possible, since each authority uses its own categories and indexing keys. Concretely, the same person appearing in four lists of sanctions, will be displayed by the software as four possible matches to be processed.

Similarly, no AML/CFT software provider is also a data provider. Eventually, offering compliance data is a profession in its own right, which requires means, organizations and resources completely different from a software provider’s.

Given the above, we recommend using, separately, a recognized software provider for the complete AML/CFT solution and a wellknown data provider for sanction/PEP lists. As for this case, choose the datafile option where your AML/CFT software will automatically download a datafile from sanction/PEP lists, providing then more flexibility when using these data.

This approach does not pose any risk of integration and interoperability since all AML/CFT compliance software dispose of connectors to the main data providers systems being much less numerous, among which we mention: Refinitiv, Dow Jones and Lexis Nexis.

Benign alliances have been built between data providers and software providers in order to make you not only benefit from the different commercial coverage from both sides, but also to guarantee the perfect compliance data integration into the screening modules of these software.

Although we do not recommend it for lack of interest to the client financial institution, the software and content can be ordered as a package from a data provider or an AML/CFT software provider, but three points of vigilance are necessary in this situation:

1- Knowing which data is integrated by your software provider (provider and lists included)

Disregard public data.
Ask for a top-tier data provider.

2- Having visibility into the precise costs of the annual subscription for screening data and into the evolution of prices.

It will allow you to compare like with like when it comes to evaluate offers from several data providers at the same time.
It will allow you to know the real cost of data and software if you ever need to change the provider in one or two years.

3- Do not accept any sort of forcing decision concerning data or software and make sure you are still able to replace any one of them.

Vneuron’s Risk & Compliance solution protects you against all these risks. Contact one of our experts to get answers for your specific concerns. You can join us via your Account Manager, on our contact form or directly on [email protected]

3 Traps to avoid when choosing your AML/CFT solution