.svg)
Large banks are no strangers to the pain of rip and replace on legacy technology. So, it is understandable why so many have previously looked for the path of least resistance and layered in new technologies to complement those existing investments. This made sense particularly in the early days of the shift to the cloud. But when it comes to anti money-laundering (AML) compliance tech stacks, there is simply no good argument for hanging onto those antiquated systems. Join me in a filibuster where I bust the most common misconceptions around augmented analytics for AML and outargue any argument for sanctions screening overlays.
Argument No.1: Deeply Embedded
The foundations of your house are deeply embedded, but if they were failing you would surely dig them out and fix them properly. It is the same with sanctions. Name and payment screening form the foundation of any good financial crime compliance programme, and a basic paint job is not going to mitigate the underlying risk of non-compliance. Sanctions screening is only getting more challenging against the global backdrop of rapid regulatory change and trade wars.
Legacy systems cannot be augmented to achieve the level of accuracy necessary to meet the requirements for a risk-based approach to AML, for this you need multi-configuration screening that can be easily tuned in the User Interface to stay tightly aligned to the risk-based assessment. Maintaining compliance with a legacy system across business lines, jurisdictions, and everything else demands a purpose-built NextGen solution.
Argument No. 2: Cost Controls
Most banks drastically underestimate the true total cost of ownership for their AML systems. Duplicate systems mean duplicate costs, it’s as simple as that. Just because you only want to use part of the overlay system’s full functionality doesn’t mean you are only licensing that functionality. And add to that the duplicate API calls and data subscriptions required to feed the overlayed system; the business case just doesn’t add up.
In times gone by it was thought that there was no cost saving to be made in large scale software replacements, but modern AML systems are lightweight footprints that go in quickly and shorten the time to value. They consume far less cloud capacity than legacy systems, and with multiple screening configurations reducing over-screening you save on the API calls, data subscriptions, and alert reviews.
Argument No.3: Sandbox Set-Up
Legacy systems don’t have a sandbox and the drive to implement one is the right thought track, but implementing a standalone sandbox is the wrong approach. Many banks believe they can compensate for their lack of testing environment with a sandbox stuck onto their tech stack like a sidecar. But if the legacy system can’t support a sandbox, how is it going to consume the outputs into production? A nextgen solution with an integrated sandbox tests on live data for certainty of client impact before pushing to production.
Teams can test at the earliest possible point of anticipated regulatory landscape changes and be sure how any changes to rules and configurations will impact alert volumes, then promote that blueprint of the optimal screening configuration into live production seamlessly. Attempting to achieve this test and launch approach with disparate systems will be unsuccessful due to the lag between testing and hard-coded implementation creating risk exposure to changing regulation, as well as the disparity between testing data and live data creating unanticipated alert volumes and client impact.
No matter the challenges of your current implementation, the best solution will be to rip and replace from legacy to NextGen. Discover the risks and inefficiencies that are holding your organisation back and find out how to turn the tables on compliance, making it your greatest strategic advantage.
No matter the challenges of your current implementation, the best solution will be to rip and replace from legacy to NextGen.
Learn how to calculate the true TCO for screening.
Photo by Shubham Dhage on Unsplash
