A Top Down Understanding of Transaction Monitoring Software - Part One

As an AML (anti-money laundering) professional it is often hard to fully understand AML transaction monitoring software, including the terms, functionality, data dependencies, and limitations. These challenges can make it difficult in creating and maintaining an effective AML governance program. Often we see when AML governance programs are built upon their AML software, they have gaps or limitations as a result of the AML software implementation or in some cases the limitation of the AML software itself. The intention of this two-part article is to give a top down perspective of AML transaction monitoring software, including the commonalties and the differences between terms, functionality, data dependencies and limitations of AML software; however, no software will be named specifically. In part one of this article, we will discuss AML software as whole, a hosted versus licensed version, the interface, level setting some terminology among profiling/behavior/patterns and the considerations when reviewing software features.

AML Software

In general, most AML transaction monitoring software functions in a similar fashion, but what tends to vary is the depth and flexibility of each feature. For example, with case management you may have a basic alert or case that is created by the system that gives very limited choices on what decision can be made or what supporting information can be associated to the case. So let’s discuss to what depth we can take each main component.

Hosted vs. Licensed

So let’s start with the differences between hosted and licensed AML software environments. A hosted environment is mainly a cost savings benefit, but can have several limitations such as no access to a server for the bank staff or outsourced consulting staff to access a test environment that is a clone of production to test rule changes, false positive tuning, or conduct model validations. Other differences include that fact that the hosted systems interface is already completed assuming you have their core banking system, this is both an advantage and a disadvantage. The advantage is the interfaces are already completed, tested, managed for changes and updated by the vendor. The disadvantage is that you have little chance for customization to provide the best quality data to your AML system.

A licensed environment is often more expensive either in the total cost of ownership, but has far less limitations as long as the license with your AML vendor allows for additional test systems and backup/DR (Disaster Recovery) systems. Financial Institutions (FI’s) can be very similar, but no two are exactly alike. These differences may require additional customization, which a hosted system may not be able to accommodate. Licensed system will allow for the greatest capability to match future changing AML compliance requirements do to the custom/flexible nature of a licensed environment, but also require upgrades, additional maintenance and a greater IT knowledge base to support.

Interfaces

Importing data into your AML software has a tremendous impact on the success of your AML program. Data quality is often not prioritized or given a thorough review during the initial implementation of the software. Data quality issues are resolved over years of tuning, model validations and remediation efforts. When the AML interfaces have reached a state of maturity they will process and improve the data through logical data enhancements like parsing, concatenation, normalization and transformation with the end product being enhanced data loaded daily into your AML software. In many cases this data is processed in a staging or a data hub in a batch process nightly just before it is loaded in the AML database. In some cases data correction or improvement can even remove duplicates, process a refund or even add country data to a missing country field in a wire. A similar process can take place for customer and account information in regards to creating a single customer record from multiple customer/account source systems. If this merge is done correctly the customer record would end up in the AML software with a consistent and unique customer/account number with the most complete customer/account fields for KYC (Know Your Customer) purposes.

Profiling/Behavior/Patterns

Nearly all AML transaction monitoring software has the capability to baseline a customer’s normal and expected activity so that as transactions come in to the bank (or system) each day, if a pre-determined threshold is exceeded a case or alert will be generated in some fashion. A typical baseline is measured on transactional activity monthly for the past 13 months. The intention of profiling is to identify activity that is abnormal. Abnormal is defined by the bank and restricted to the capabilities of the software. Often data that is measured is based on dollar amounts, or the number of transactions in and out of an account. Some of the higher costs systems offer more data elements to measure those patterns against. I have seen this referred to as ‘Profiling, Behavior and Patterns’, which I will refer to as profiling for the remainder of this article. I have also see this same functionality on a group level called ‘Peer Profiling’, which is an alternative to baselining a customer against themselves for 13 months, but instead is based on a grouping of similar customers (customer type, location, and so on.) for 13 months.

So when determining thresholds there are various methods to do so. Often risk based thresholds are used to create a more specific scale to apply to each profile. By having a scale your AML program will have 2 key benefits, the first is you will have a greater ability to manage false positives and your AML program will be more risk based.

Conclusion

In conclusion, there are a number of considerations when selecting a AML transaction monitoring software system for your FI. While this is just some of them including AML software as whole, a hosted versus licensed version, the interface, level setting some terminology among profiling/behavior/patterns and the considerations when reviewing software features, there are more. In part two, we will level set some terminology around rules/scenarios, alert/case management, dashboards and reporting, and selecting your AML transaction monitoring software.