Should AML Technology Drive Business Process or Vice Versa?

This is a vexing question and it is at the heart of myriad problems with the current approach to AML/BSA processing. Last year, in conversation with a banking regulator, he observed, that "when a bank buys AML software they also buy an AML business process".

This is not unusual in the world of enterprise software.

However it led to more questions. 
• What if the process does not match the bank's needs?
• What if they want to change the process?

These rhetorical questions stemmed from a sense of frustration on the inefficiencies and ineffectiveness of AML software. However, the last question was much more pointed

• How about, for a change, the business process drive the technology instead of the technology dictating the business process?

To answer this question, we need to look at the context of BSA compliance regulation. One of the most important guidelines in the FFIEC manual on BSA/AML states, “The first step of the AML risk assessment process is to identify the specific products, services, customers, entities, and geographic locations unique to the bank.  

BSA cover edited

Traditional AML software systems, like most enterprise software, are based on a one-size-fits-all  approach with a small provision for customization. Does this design feature of enterprise process automation directly contradict FFIEC guidelines? If so, bankers and regulators alike are justified in their frustration.

Traditional Approaches to AML processing

Traditional process automation approaches to AML have been used by banks for more than two decades. This process automation is based on how human beings onboard clients, analyze their transactions and report suspicious activity with supporting documents. Technology vendors over the years have done a great job in studying these processes and codifying them into software.

While process automation solutions are designed for efficiency, they are not flexible. When a bank buys AML software, they are bound by the default business process defined by that software. Any change in the business process can make the legacy system ineffective or worse, counterproductive. 

Responding to Regulatory Pressure

In response to increasing regulatory demands for vigilance on financial crimes, banks have had no option but to add people who could work within the constraints of the software system. While adding people is expensive, it does solve the burning need to get compliance work done. 

Nearly half of the $70B spent on AML compliance by banks in 2018 was for people-cost. These people are invariably working with a default AML process automation system, which is not designed for the unique needs of the bank and not flexible to adapt to changing risks.

Regulatory staff have increased tenfold in banks over the past 5-years to ensure no bad actors slip through the cracks. This entails staff members wading through high-volumes of alerts generated by legacy systems that typically produce 90+% false positives. It is not unrealistic to expect human errors to the extent of 5-10%. These can be minimized by adding more people to manually review these errors.

Meanwhile, smart crooks are becoming more adept at using modern technology for financial crimes. Process automation systems designed to catch bad actors from the 20th century are no match for them. 

Learn More About Agile AML Compliance

$2+Trillion is laundered through the banking system every year and less than 1% is intercepted. This is a good indication of a system and regulatory process that requires rethinking and a more modern approach that improves AML outcomes and return on the massive investments in AML each year.

What is an alternative approach to AML processing, where the technology serves a modern business process, instead of the other way around?

Stay tuned for our for answer.