Anti-money laundering regulations require financial institutions to prevent their customers from conducting illegal business activities through their services. AML transaction monitoring software uses artificial intelligence to sift through thousands of transactions to identify deviations from usual and customary activity, as defined by the rules and parameters programmed into the software.

Not all alerts indicate wrongdoing, though. In fact, monitoring systems can often generate far too many alerts that are often “false positives” and are of little or no value. Ideally, institutions should find a way to reduce the excessive number of false positives by optimizing or “tuning” current systems to better detect suspicious activity and to reduce the number of low value alerts.  Tuning can be driven by the need to improve quality of alerts voluntarily or it can be mandated by regulators. Regardless the reason, it is very important that tuning be done periodically and correctly. The benefits of tuning can reduce workload, allowing more time to be spent on meaningful alerts, thereby improving overall program performance. However, if the tuning process is not conducted correctly, greater risk can result because important alerts are missed.

AML transaction monitoring software applications use “rules,” “models,” or “scenarios” that seek to flag potentially suspicious transactions while ignoring ordinary or expected activity. Unfortunately, the majority of transactions flagged are in fact ordinary, creating a significant amount of work for AML departments that can hamper compliance.  Tuning strives to optimize these rules and scenarios to better identify suspicious activity and to focus less on false positive alerts.  Tuning combines statistical analysis, knowledge of how money is laundered, and sound judgment to craft better detection scenarios. Some keys to ADI’s approach when tuning AML monitoring systems include:

  • Realize Software Limitations: Not every type of transaction needs to be or can be monitored through a software application.
  • Validate Data Completeness: No matter how well a system detects suspicious cash activity, missing ACH transactions or wire transactions means you won’t pass an exam.
  • Align Systems Logic with Risk: The goal of this process is to be sure that your AML system is appropriately designed to capture high risk customer transactions, high risk transaction types and unusual transactions with respect for customer base and geography. As an institution’s risk profile changes, especially as it relates to the customer base and high risk industries served by the entity, the system’s logic should change as well to ensure a continual alignment of logic and risk.
  • Focus on SARs: The purpose of AML compliance is to detect suspicious activity and, when detected, to file SARs. If scenarios programmed into transaction monitoring software never yield a SAR, modify or retire them.
  • Examine Non-Transactional Variables: Transaction volumes and values are obvious variables to alter when tuning. However, they may not always be the best at identifying suspicious activity. Analyzing cases that were escalated from alerts and SARs filed from the scenario being tuned can often reveal what is most meaningful.
  • Micro-Target Scenarios: Seeing the same customer alert every month for normal or expected activity is frustrating; however, suppressing, or “white-listing” customers may be considered too risky, for fear of missing a significant alert. Applying a subset of more narrow thresholds to these repeat customers can aid in identifying their truly suspicious activity but not alter the rules and scenarios applied to the general population of customers.
  • Change the Time Line: Instead of a scenario looking at monthly activity, extend monitoring to quarterly or semi-annual intervals, which can often better detect true alerts. Different products lend themselves to longer review periods.