Community
Last week, the US Department of Treasury published its 2020 Strategy document that "employs a whole-of-government approach to guide the public and private sectors in addressing 21st century illicit finance challenges." The report highlights the risk-based approach as central to the 2020 Strategy.
The report classifies vulnerabilities as
FATF Recommendations from June 2019 stated, "By adopting a risk-based approach, competent authorities, financial institutions and DNFBPs should be able to ensure that measures to prevent or mitigate money laundering and terrorist financing are commensurate with the risks identified, and would enable them to make decisions on how to allocate their own resources in the most effective way.”
A risk-based approach is about allocation of resources based on risk.
This is more easily said than done.
The Biases of Rules Engines
A risk-based approach is commonly used by banks in building an AML process. However, the assessment of risk often comes out of a box of shrink-wrapped software in the form of a rules engine. The rule-makers have imperfect and often generalized information about AML/BSA vulnerabilities and have ascribed risks to them based on their best judgement.
Daniel Kahneman, who won the Nobel prize for research on decision making in uncertainty posited that human beings make complex decisions using simple rules. These rules often lead to wrong decisions because they incorporate their biases. These biases eventually find themselves into policies and procedures.
In the months following 9/11 an airline passenger got on a plane with an explosive device in his shoe and was quickly apprehended. A rule was soon created for airport security to check the shoes of all passengers boarding a plane. 20 years later, this is standard operating procedure. What is the safety risk of ignoring the shoe rule? Probably not commensurate with the cost.
Rules may have a basis in anecdotal information and are often hard-wired into a rules engine. A risk-based processes based on bad rules is still a bad process.
Machine learning cannot eliminate risk but it can be used to minimize cognitive biases in implementing a risk-based approach. A judicious combination of human intelligence and machine intelligence is key to implementing an effective and efficient risk-based process.
Headcount and Process Debt: Effectiveness at the cost of Efficiency
Process Debt is a financial metaphor used in the context of BPM (Business Process Management). It can be loosely defined as making short term fixes in the business process at the cost of long-term gains. In the context of AML processing, gratuitous checks and balances lead to more effective processes that are highly inefficient and expensive to maintain.
The AML officer of a large bank recently told us that their process was very effective and also very inefficient. This meant they were confident that no bad actors were slipping through the cracks but that confidence came at a very steep cost. Effectiveness was achieved by adding headcount. This lament is very common across banks who are doing well by their regulators but not so well for their shareholders.
One measure of efficiency in an AML process is the number of "doers" who perform the laborious task of collecting information compared to the "deciders" who synthesize the information to make a decision. It is not unusual to have an 80:20 ratio of doers to deciders. A recent study by Lexis-Nexis found that small banks in North America spent $8B on labor costs on compliance which is 60% of their budget.
Ironically, we have a history of measuring the effectiveness of our AML process by headcount. Compliance staff have increased tenfold at some major banks in the US during the last decade. This is a quick fix way of demonstrating that large number of people are solving a problem. Historically, banks have used an increase in headcount as a measure of their commitment to the AML process. Budget increases for headcount are also easy to get approved if they can fix an immediate problem.
Automation and Technical Debt: Efficiency at the cost of Effectiveness
Technical debt is an extension of the debt metaphor to technology. Some very effective short-term point solutions in technology can lead to long-term costs in the system.
As an example, it is very easy to deploy technologies like RPA in isolation and run up a technical debt. A report by Derek Miers from the Gartner Group gives the example of a bank with 2,000 RPA bots. According to the report, “They wish they could roll back the clock and never have done that. Because they don’t know which part of the bank is going to stop working on Monday morning, if they change an application.”
By contrast, agile compliance based on the best practices of business process management can use a combination of RPAs, workflow tools and AI tools to create an effective and efficient process. It can do this while minimizing technical debt.
An important question to ask a technology vendor in implementing a risk-based process – will the technology drive process, or will the process drive technology? If the process drives technology, will it let the bank change its business process when its requirements change?
Designing for Agility: Effective and Efficient
Dave Thomas, one of the original proponents of agile software development, summarizes agility in one sentence, "When faced with two of more alternatives that deliver roughly the same value, take the path that makes further change easier". The premise of this design principle is that flexibility to change is a fundamental requirement.
An Agile Compliance process is based on an iterative software development methodology that values human communication and feedback, adapting to changes, and producing working results. BCG has estimated that using the agile approach could cut banks’ IT spending by 20% to 30% and could significantly improve their ability to deliver regulatory projects on time.
Here are a few considerations for making a risk-based process effective and efficient.
1) A judicious combination of human intelligence and machine intelligence.
2) Process drives technology and not vice versa.
3) The best process design decision is one you can change later as requirements change.
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.
Ben Parker CEO at eflow uk ltd
23 December
Pratheepan Raju Advisory Enterprise Architect at TCS
Kuldeep Shrimali Consulting Partner at Tata Consultancy Services
Jitender Balhara Manager at TCS
22 December
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.