Rules or detection scenarios are at the heart of an anti-money laundering (AML) software solution. It is through rules and profiling that a compliance group is alerted to suspicious activity. Yet many systems rely on rules that were developed over 10 years ago. These first generation rules present a number of significant challenges to the chief compliance officer (CCO). At the same time, regulators are increasingly focused on the appropriateness and effectiveness of the rules employed together with the CCO's ability to justify the way in which rules have been implemented.
Clearly a better approach must be followed. Fortunately, most systems allow for the creation of new and customized rules. With this flexibility a financial institution can overcome the limitations of the first generation. The following are some of the key challenges. Addressing these challenges will significantly improve the effectiveness of the compliance function.
Challenges
AML detection rules present a number of challenges to the CCO. These challenges can be broadly classified into five major areas:
- Fundamentals
- Logic Issues
- Control Issues
- Case Management Issues
- Poor Supporting Information
Fundamentals
Rules-based detection systems are fundamentally flawed if they are not driven by a risk-based approach. Rules should be chosen by and thresholds adjusted based on a systemic risk assessment inherent in the AML software. Further, both rules and the risk assessment should be dynamically and continuously adjusted based on the prior actions, behavior, and transactional patterns encountered. It is only through a true feedback loop between detection and risk assessment that a system can stay relevant through ongoing business change.
Logic Issues
This is the most significant challenge facing CCOs. Is the logic used by each rule sufficiently robust to detect true suspicious activity? From our engagements with a wide range of clients, it is clear that the answer to this question is often negative.
More troubling is the fact that many CCOs do not have a way to assess the validly of their rules. Vendors often provide rules as a "black box." The logic and details are not exposed or explained. The CCO is faced with the problem of "not being able to check what has not been found." This leaves the financial institution at significant risk. Rules designed a decade ago are used for many years without any reasonable way to assess their competence. Consequently, true suspicious activity is often undetected.
Three of the most common logic issues are:
- Weak Logic: The algorithms used in many first generation systems are very basic and do not adequately detect suspicious activity, especially new or emerging patterns. Often these algorithms use a simple query rather than employing other approaches such as statistical, pattern detection, and trending. To help determine the adequacy of rule logic, the CCO should ask their vendors to explain the approach used for key detection scenarios and provide a justification for their approach.
- Excessive False Positives: A corollary of the weak logic used in many detection scenarios is an excessive number of false positives. Generic rules often cast a wide net creating unnecessary alerts and cases. The substantial effort and cost of resolving these cases is troubling enough. Yet, one must wonder, how many valid cases are not properly researched because the finite resources available to the CCO are diverted toward useless alerts. It is not satisfactory to say that large numbers of false positives are a byproduct of AML compliance. They can be reduced while maintaining adequate safeguards.
- Number of Rules: AML vendors will often create a large number of rules to demonstrate the competency of their software products. On the surface, this may seem like a good approach. However, it is often problematic. The logic for detecting suspicious activity should take into account all relevant behavior for a particular typology. Designing rules for very specific situations often prevents the rule from using all of the relevant information available in transactions and other data.
Control Issues
Detection scenarios must be adapted to the transactional patterns, clients, products, and most importantly the risk of a financial institution. They should not be used as-is from the software vendor. All too often, the only control offered is through a limited number of inconsistent rule parameters and thresholds. For a financial institution to gain better control of their suspicious activity detection, they should have:
- A comprehensive set of parameters and thresholds that are applied to most if not all rules.
- Good guy lists and other exclusions that are rule specific and that can be applied conditionally based on the needs of the financial institution and its specific products and lines of business.
- Comprehensive analytics that provide a deep understanding of transaction patterns and the reason alerts are, and more importantly are not, generated.
- Control over the creation of alerts and cases to properly represent the nature of the finding.
Case Management Issues
A comprehensive case management and research facility is essential to efficiently and effectively handle suspicious activity alerts. At the rule level, case management is hindered by the following scenarios:
- Alert Overlap: The large number of rules offered by AML system vendors often overlap in the type of activity they are monitoring. As a consequence, multiple cases are created with each providing only partial transactional details. This creates extra work for the compliance group and hampers the ability to view all suspicious behavior holistically.
- Cases by Rule Instead of Party: Related to alert overlap is the segregation of cases by rule instead of by the suspicious party. Suspicious activity is inherently party centric and should be viewed as such. Complete supporting information, analytics, and past cases should support the review of all suspicious activity for each party.
- Creation of Cases Instead of Alerts: Here I will be specific with terminology. An alert is simply an indication that some transactional pattern should be looked at. A case is the promotion of an alert based on an initial evaluation that suggests that detailed and further research is warranted. The challenge with some of today's systems is that rules such as profiling will automatically create a case instead of an alert. This substantially increases the burden and risk for the CCO since regulators will look for cases to have more due diligence applied even though many may represent false matches.
- Dynamic Learning Unavailable: Today's systems must employ dynamic learning to meet the needs of compliance. A static model that is programmed once is not sufficient. Systems must capture all of the information inherent in research and case management. This information must in turn be saved and influence the actions followed by subsequent and similar situations.
- Weak Scoring: An important tool to help prioritize alerts is a proper scoring methodology. While some systems have implemented scoring, it is often a trivial calculation that does not properly reflect the level of risk inherent in an alert. Scoring methods should be model driven affording the ability to adapt it to the risk profile of the financial institution.
Poor Supporting Information
It is often said that the results are only as good as the data available. While this is true, it leaves out another important truism. That is the results are only as good as the analysis of the data available. Successful AML systems must now provide true analytics to support the research of cases and to uncover new suspicious activity that may not be found by the existing rule set. However, most systems are limited by basic database queries that are frustrating at best.
To support rules, a fully functional business intelligence capability must be provided. This capability must offer:
- OLAP (online analytical processing, that rapidly provides results of detailed data relationships).
- Statistical modeling to help identify facts and patterns in vast amounts of transactions.
- Visualization tools aimed at simplifying the relationship in data.
- Information capture that provides the ability to save and reuse prior analytics.
- Knowledge consolidation that allows the combining relational, public, corporate, and commercial data.
Conclusion
These challenges are significant and have gone unaddressed for a substantial period of time. This should not continue. Examiners are asking for detailed analyses of what rules have been chosen and why. They are asking the CCO to explain why parameters were specified in the way that they have and how this is supported by existing data and the risk assessment of the organization. Further, they are looking for strong statistical support rather than a simple narrative. The time has come to reassess your rules.
