As financial institutions must find ways to fight financial crime, Anti-Money Laundering (AML) compliance remains a critical priority. One of the key elements of AML programs is transaction monitoring, whose goal is to detect and report suspicious activities based on customer behavior and transaction patterns.
It all starts with online transaction monitoring meant to detect any suspicious activities related to money laundering, terrorist financing, or other financial crimes. However, sometimes these monitoring engines can miss certain suspicious patterns because they only focus on one transaction at a time. To tackle this issue, financial institutions use something called retro transaction monitoring. This is a more advanced technique that looks at historical transaction data and uses complex rule sets (scenarios) to catch unusual customer behavior and transaction patterns. In this article, we focus on ways how to ensure proper maintenance and improvements to your retrospective transaction monitoring engine.
Customer behavior and banking services have a tendency to change over time, therefore it is not a one-off setup that will ensure protection over a long period of time. As money laundering activities are constantly evolving, financial institutions need to review their existing retro transaction monitoring setup on a periodical basis. Not only to comply with regulations but to grow the effectiveness of AML.
Now, it is not only the logic of the scenarios to be reviewed but the overall correct functioning of the system must be verified as well – things tend to fail over time. After a number of software version updates, bug fixes, small development here and there, and changes among personnel who maintain the whole ecosystem – are you still sure your monitoring system works as you would expect it to?
To validate the outcomes of your retro-monitoring system, we recommend evaluating it from two perspectives:
- Conduct back-testing based on historical transaction data. Whether you are using your own or 3rd party solution, you need periodically change the oil in your engine:
Extract the raw transaction data from the core system.
Make a sanity check – ensure that the transaction data is accurate and complete.
Simulate the results of your working scenarios using third-party alternatives – MS Excel may come in very handy for this purpose.
Compare the simulated results to the historical ones to check for any kind of discrepancies or differences between the two.
Investigate the findings, make your conclusions, and document the results.
Comparing two outcomes usually brings good insights into what needs to be fixed or adjusted. You may as well find out that some types of accounts, transactions, or even products somehow got skipped and were not included in the scope of retro monitoring – though you may be wondering how did it happen in the first place, you are now back in control of the situation.
- Understand and challenge scenario logic. Doing this periodically sounds like a waste of time, but it brings a lot of value to the retro transaction monitoring engine outcomes:
Test and check scenarios - sometimes different perceptions and knowledge of IT and AML people on insufficient change management process can lead to a situation where strictly defined and simple scenarios may end up producing inaccurate or false results. You may discover that some of the settings or even possibly the whole scenarios are obsolete or there is an overlap between the two scenarios and thus – duplicate alerts – this is what you are looking for.
Calibrate scenarios based on historical transaction data. This process involves setting parameters such as transaction value thresholds, frequency thresholds, and possibly other parameters in a way that minimizes the number of false positive alerts while still ensuring sufficient system sensitivity level.
Upgrade parameters periodically – customer behavior changes over time, so scenario calibration needs to be done to improve the accuracy of alerts. This could help identify new scenarios or variations of existing ones based on historical data, which can be used to update and enrich the scenario library and improve the risk assessment process.
Get fresh input from outside organizations - financial institutions can gain extra value by using external partners’ expertise and solutions to complement their in-house capabilities and stay up-to-date with evolving AML risks, regulations, and fresh experiences from the market.
To implement retro transaction monitoring right, banks need to have access to comprehensive and quality data (the right raw data helps a lot for model periodical audit), advanced analytical tools and models, and skilled AML professionals who can interpret and act on the alerts generated by the system.
Retro monitoring periodical review is not a silver bullet, but it can be a valuable addition to a comprehensive AML program that combines human expertise, process automation, and technology innovation.