Anti-Money Laundering and Countering the Financing of Terrorism (AML/CFT) supervision scenarios for financial institutions: immediate actions and preparation for the future

1. The effectiveness of the mechanisms and tools deployed remains insufficient 

An AML/CFT detection system is active both upstream and downstream of operations. We are dealing here only with the detection of atypical transactions a posteriori (another article on a priori detection is forthcoming).

A posteriori detection is now largely automated, given the volume of transactions to be monitored. However, the effectiveness of the detection tools and systems deployed is still insufficient. There are several reasons for this: the frequent lack of visibility of Compliance Officers on the technical functioning of these tools; dated, badly designed or poorly calibrated scenarios resulting in too many alerts to be processed and too little relevance with regard to the enhanced examinations and suspicious transaction/activity reports (STRs/SARs) that actually result; and lastly, the processing of alerts is not sufficiently agile and responsive.

2. Five immediate actions to improve automated detection and move from a deterministic to a controlled process

• Re-appropriate the monitoring tools

• Challenge the detection scenarios

• Optimise the "alert - SARs" transformation rate

• Ensure traceability and productivity of alert processing

• Use dashboards for a better monitoring

Taking ownership of monitoring tools

The functioning and configuration of the monitoring tools often appear to be a "black box" for the Compliance teams. Their technical configuration is not well known and insufficiently understood by the users (Compliance Officers, AML/CFT analysts, internal control teams, etc.). For example, in the absence of precise functional documentation concerning the specifications of the scenarios, the Compliance teams may stay on the side of the set-up if they did not initially participate in its design and/or are not involved in its regular review.

Thus, it is good practice for Compliance teams to carry out full functional testing in close coordination with the technical teams in order to approve the tools. This allows for malfunctions to be identified in the various stages of the detection chain (see diagram below). Corrective actions can therefore be taken by the Compliance/operational teams or by the technical teams (IT, editor...) and the functional documentation updated.

Example of dysfunctions in the detection chain

Challenging detection scenarios

Financial institutions have been equipping themselves with specialised AML/CFT monitoring tools for over a decade. Failing to upgrade their tools to take advantage of new functionalities or new scenarios, they too often choose to keep the old versions of the tools as a result of arbitration on priorities or issues linked to the technical infrastructures of the tools.

The detection scenarios set up on the basis of the money laundering typologies known at the time of the deployment of a tool can quickly become obsolete, while the scope of AML/CFT controls is constantly evolving (regulatory changes, changes in risk exposure, new illicit channels).

Regular review of the scenarios is therefore an imperative.
The first step is to integrate new types of money laundering, through an internal analysis of atypical operations observed, or through external monitoring (guidelines, reports from the supervisory authorities, sanction reports, best practices in the market, etc.).

A second step consists of regularly, and at least annually, analysing the SARs. This analysis makes it possible to identify opportunities to automate the detection of certain typologies that have been the subject of several SARs. New typologies can be evaluated regularly, and at least annually, in order to study the relevance of their integration into the monitoring tools (evolution of existing scenarios or creation of new scenarios), and to carry out "Proof of Concept" on the monitoring of these new typologies in order to anticipate and prepare for a transition into production.

Example of a scenario review approach

Optimising the "alert - SARs" transformation rate

This is not new but it is still not solved. The "alert - SARs" transformation rates are very low, around 1% to 5%, and more often close to 2%. When analysing all SARs and their reporting channels, it is generally observed that the cases identified by the scenarios represent only a fraction of all SARs reported by the organisations. Reducing the number of "false positives" by making alerts more relevant is a priority for Compliance Officers.

These difficulties often stem from detection rules that do not specifically target atypical behaviour but may, by simplification, generate alerts based on the simple amount of transactions (for example, in life insurance, a single threshold for the cumulative amount of free payments for all customers does not make it possible to identify atypical behaviour with regard to the customer's profile; similarly, the amount alone to identify a suspicious opting out of a life insurance is not sufficient).

The first step in improving the system is to combine several detection rules (incoming and outgoing transactions, frequency, etc.) in order to target truly atypical behaviour: for example, by integrating the frequency of capital rotations, or a change of bank account number followed by one or more buyouts on a life insurance policy, or in the bank, early repayment of a loan shortly after it has been granted... Secondly, and this is the most important element, the specific characteristics of the customer (his profile) should be integrated into the detection rule. This can be done by enriching and making better use of Know Your Customer (KYC) data. For example, income or assets for money laundering or tax fraud risks, geographical information for terrorist financing or tax fraud risks (see French FIU – Tracfin - 2019 and 2020 activity reports and analysis reports), or other types of non-financial transactions such as change of address/bank details, change of beneficiary for abuse of weakness or external fraud.

Data analytics method and tools allow Compliance teams to visualise the overall behaviour of all its customers and to identify the position of the behaviours resulting from the SARs (with the customer profiles) among all the operations carried out.

Take the insurance example shown below: all exceptional payments made over a year are shown in the graph with a dot. Applying the other detection rules (capital turnover ratio) and the currently defined thresholds, only the red points represent alerts generated by the scenario. On the other side, we visualise all SARs cases identified during the period (in black). The graphical interpretation of the transactions gives Compliance Officers a better visibility on the behaviour of the clients of their institution, and the possibility to confirm the relevance of the scenarios or to adjust the settings to optimise detection.

Illustration of a scenario simulation with Data Analytics and the objective of optimizing the transformation rate

Ensuring traceability and productivity of alert processing

The traceability of all stages of alert processing is essential for Compliance. This may be required by a supervisory authority, but it is above all necessary to measure the effectiveness of the scenarios. Faced with a large volume of alerts to be processed, AML/CFT analysts often do not have the time required to correctly retrace the analyses and reasons for closure in the tools. Upstream, the workflow (processing scheme) must be correctly configured: for example, the possibility of assigning intermediate statuses to distinguish complex cases awaiting additional information from unprocessed cases may sometimes be missing; case management does not always allow for homogeneous processing of alerts on the same client or the grouping of several people linked to the same client. These processing patterns can be improved or corrected by categorising the reasons for closure and predefining in the tool those most often used.

Compliance teams can also take advantage of new technologies that are relatively easy to implement for alert processing. For example, Machine Learning, while not allowing alerts to be closed in place of the analysts, can be used to prioritise alerts according to different levels of complexity, therefore increasing productivity and security of analyses. Alerts similar to those that have historically generated enhanced reviews or SARs are prioritised and proposed for processing by experienced analysts, while alerts similar to those closed without action can be processed by more junior profiles.

Example of prioritization of alert processing by Machine Learning  
 

Dashboards for better monitoring

Showing that the Compliance function regularly ensures the effectiveness of the scenarios is more difficult in the absence of dedicated dashboards. A series of indicators seem essential (with regular production, for example twice a month). For example:

•  Rate of transformation of alerts - enhanced reviews - SARs by scenario (number of alerts / Enhanced Review (ER) / Suspicious Activity Reports (SARs) by scenario)

• Processing time for alerts by stage (suspicious transaction - detection - ER - SARs)

• Follow-up of the processing (analysis of status changes and stocks by status...) and stock evolution

• Reporting of high-risk alerts/typologies requiring prioritisation

• Reporting of technical incidents in the tools

• Date of update of detection criteria used in the scenarios (per scenario)

• ...

All of these actions on existing systems, which can be implemented immediately, enable financial institutions to gain rapidly in terms of efficiency in detecting atypical transactions, and to demonstrate that the AML/CFT monitoring system is managed in a logic of continuous improvement.

3. And how to prepare for tomorrow?

Making the data centric architecture work

Moving detection systems towards a data-centric architecture (an architecture that decompartmentalises all information systems) is not a new idea, but is beginning to be deployed by a growing number of institutions. This evolution requires the identification and pooling of all available data, internal and external, from the moment a relationship is created to the monitoring of transactions during their life cycle, beyond the data currently used for market tools. The consolidated data in a central database is more complete and robust for a 360 view of customer behaviour and a better identification of the entire chain of suspicious transactions.

By moving away from legacy solutions, a data-centric architecture provides opportunities to quickly add AML/CFT scenarios to the detection system. It allows the organisation to rely on new technologies such as Artificial Intelligence or Robotic Process Automation. Without the constraint of technology compatibility imposed by vendors, compliance teams can define and implement detection algorithms in an agile manner and customise functionality as required. A data-centric architecture also allows players to integrate external information into their devices to enrich scenarios. When Compliance teams are actively involved in data projects, they increase their understanding of the data and their control of the overall monitoring system.

This architecture also allows for enhanced detection, in addition to the scenarios, by directly analysing the data "for atypicality" or detecting weak signals. The results of these analyses can, in turn, feed future detection scenarios.

Making customer and operational data more reliable

As mentioned above, the integration of new data is essential to improve the effectiveness of detection. However, the quality of this data must be ensured. The example of income/asset data is very telling. For the same customer, the income may not appear in the customer file or several incomes may appear corresponding to information collected during the subscription of different products via different networks... If this information is integrated as a factor in a scenario, its reliability must be ensured. Retrieving data from external and reliable sources may also be an option for institutions to complete the knowledge of their customers.

Implementing multi-activity and multi-objective detection

For example, in a bank-insurer or insurer-bank group (which combines banking and insurance operations) or in multi-activity players (retail and corporate banking, leasing, consumer credit; a multi-branch life and non-life insurer or mutual), detection should no longer be organised in silos by activity. For example, in life insurance it is necessary to be able to detect a buyout followed by cash withdrawals (risk of terrorist financing) or transfers to a third party with no link to the insured (risk of abuse of weakness) and these operations, when they are in small amounts, can only be detected if the banking and insurance operations are analysed together. The same applies to the detection of one or more small payments in a life insurance policy combined with multiple indemnities on non-life insurance policies, which may indicate fraud and money laundering. This multi-activity detection also relies on the quality and speed of information exchanges between different activities or teams.

Concerning multi-objective detection, there is a tendency to bring AML-CFT detection closer to tax fraud, external fraud (particularly for non-life insurance) and even cybersecurity (dark web analysis allows for better knowledge of certain frauds and to anticipate/discover money laundering typologies for example). In the insurance sector where, according to latest FIUs annual reports, the number of "non-life" SARs is now equivalent to the number of "life" SARs, the system must take into account the fact that customers can enter into a relationship with a simple non-life insurance contract and then switch to massive investments in savings.

Be agile and proactive

It is necessary to detect (and handle) more quickly and to adapt detection systems more rapidly to the evolution of money laundering typologies and other atypical situations. Regular analysis of the quality of detection, combined with the work of internal control, must make it possible to identify weaknesses and to develop remediation actions. The new types of risk generated by the environment (e.g. fraud in the context of the health crisis or emerging risks in the field of terrorism) require an almost immediate reaction from the different stakeholders. The tools must allow for rapid updating (the creation of a scenario must take a matter of days and the number of alerts must be able to be tested and simulated on the basis of production data).

The limitations currently observed in the area of monitoring and detection of suspicious transactions can be overcome by moving from a deterministic model to an agile and proactive approach based on all available data, internal and external. The systems must be result-oriented on this mission entrusted by civil society to financial institutions: to participate in the fight against crime! The recent evolution of data-centric tools and technologies offers opportunities within reach of all banks and insurance organisations.