Conducting  a Validation of Your BSA/AML software- A two part Series     

Since the beginning of crime, there has been a need to hide the ill-gotten gains of criminal activity.  Early bad guys held their loot in caves.  Later, treasure chest provided a means of hiding criminal wealth.   However, despite the form that ancient loot took, the goal was and has always been to reduce assets to currency so that it can be used in exchange for other goods and services.   The need to take illicit assets or money and hide its source is known commonly as “money laundering”.  Criminals of all sorts engage in money laundering and have become exceedingly sophisticated in their pursuit of hiding the sources and uses of their money.  

Because the “bad guys’ continue to evolve, the history of the Bank Secrecy Act (“BSA”) and Anti-Money Laundering laws (“AML”)   is one of ongoing change.  The laws that make money laundering illegal can be traced back to the Bank Secrecy Act of 1970.   Since the time the BSA was passed, there have been seven major legislative changes to the overall legislative scheme that covers this area.  These changes are;

·         Money Laundering Control Act (1986)

·         Anti-Drug Abuse Act of 1988

·         Annunzio-Wylie Anti-Money Laundering Act (1992)

·         Money Laundering Suppression Act (1994)

·         Money Laundering and Financial Crimes Strategy Act (1998)

·         Uniting and Strengthening America by Providing Appropriate Tools to Restrict, Intercept   and  Obstruct Terrorism Act of 2001 (USA PATRIOT Act)

·         Intelligence Reform & Terrorism Prevention Act of 2004

As technology has changed, so have the goals of many of the criminals that want to launder money.  In addition to drug dealers,  there are terrorists and persons that engage in human trafficking. All of whom are developing ways to hide their cash. 

Each of the changes in BSA/AML laws were designed to improve the overall monitoring of cash and cash equivalent transactions.  Although  these changes were not addressed entirely at banks, each change increased the requirements for compliance at banks.  For community banks, the changes have been ongoing and significant.  As the regulations changed, the expectations of the regulatory bodies evolved.  Today, no self-respecting banker would consider operating without a full BSA/AML compliance program.   Moreover, very few banks can get away with a manual system for tracking and aggregating the transactions of their customers.   Today, a sound BSA/AML program includes software that helps bank staff aggregate and monitor transactions of its customers.  

The expectation of what a full BSA program should include continues to change and evolve.  One of the most recent changes has been the expectation that all banks, including community banks will:

a)      Obtain AML/BSA monitoring software and;

b)      Perform a data and model validation on an annual basis.  

 The Source of the Data Validation Requirement 

The OCC and the Federal Reserve issued guidance in 2011 that was called Supervisory Guidance on Model Risk Management”[1] .  This guidance was first thought to deal with only the financial models such as those that that are used for projecting interest rate risk or the allocation of the allowance for loan losses.   However, a more complete review of the information included in the guidance has produced increased expectations in the area of BSA/AML. 

In relevant part, the guidance states that a model is defined as follows: 

“For the purposes of this document, the term model refers to a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates. Models meeting this definition might be used for analyzing business strategies, informing business decisions, identifying and measuring risks, valuing exposures, instruments or positions, conducting stress testing, assessing adequacy of capital, managing client assets, measuring compliance with internal limits, maintaining the formal control apparatus of the bank, or meeting financial or regulatory reporting requirements and issuing public disclosures. The definition of model also covers quantitative approaches whose inputs are partially or wholly qualitative or based on expert judgment, provided that the output is quantitative in nature”[2]

When one reads this definition of a model, it is clear that BSA/AML monitoring software is included.  The guidance is directed toward the idea that modeling software cannot be a panacea when it comes to compliance.  Models can only be effective when they are part of a complete compliance program in any area.  In the area of BSA/AML compliance, this is especially true.  

The model guidance points out that there are several areas of risk that  are associated with the use of models at a financial institution.  Many of these risks apply to BSA/AML monitoring software.   When the areas of risk are simplified, the two main concerns for BSA software are:

1.       The data that is being collected and loaded into the monitoring software is inaccurate: and

2.       The data that is being collected is insufficient to properly mitigate risk.  

 

Data Validation

To address the first of the above enumerated risks, all banks should perform a data validation. [3]    This process is basically exactly how it sounds.  The data validation is the process of making sure that the information in your monitoring software is being accurately and completely loaded from  your core system.   While this portion of the guidance may be the most straight forward there are few points to remember when preparing to perform an appropriate data validation.  

Know Thy Software

It is important to know the type of software that you are using.  Generally, there about five types of monitoring software that are currently popular and on the market.  It is important to know which type of software  your bank is using so that you can determine whether the appropriate data is being pulled.  The five types of software are:

·       Risk based- These are systems that incorporates various factors such as NAICIS codes, zip       codes, volume and frequency to predict higher risk customers

·      Rule based- system that compares transactions to scenarios that mimic suspicious activity

·      Behavior based- These systems establish a base line for a customer and track activity that exceeds the baseline

·       Intelligent systems- This software is based on decision trees that follow data that has indicated suspicious activity

·       Combination- These systems incorporate two or more of the above into the software.  

Regardless of the type of system that you are using, it is important to recognize how your system works so that you know the data points that  should be  recognized.   For example, if you are using behavior based software, it is important to recognize what information the software needs to know to establish the baseline for a particular customer. 

Software-Know thy User

It is critical that all of the transaction codes that your bank uses are being properly loaded into, and recognized by the software that you are using.   Each bank has its own unique set of transaction codes that have been established to identify transactions that are conducted.  The software vendor cannot know all of the idiosyncrasies of your bank and it is therefore incumbent on your compliance staff to ensure that the transaction codes are being properly loaded and recognized by your monitoring software. 

Compare to the Core

Many banks we have worked with use the data validation information that is provided by the vendor.  However, it is important to remember that this validation will simply tell you what happen to the information that you gave to the vendor.  If there are other errors in logic or misunderstandings about what information should be captured, this will not appear in the vendors’ validation.  We recommend that the data validation should be completed by comparing the software information to core data information.  

 Ongoing Validation

Many banks and vendors believe that once a data validation has been done, there is little need to do another one.  If everything checks out and all data is being loaded properly, what is the problem/ have you ever logged onto your computer and found that everything had changed, even though you did not do anything different?  BSA software is the same.  Even though you may not have consciously made changes to the software or to the processes, things  change for various reasons.  Because change is constant, it is a best practice to test data validity on a regular basis.    Consider this; if you do find a problem, it will be necessary to go back to the last data validation to determine the extent of the problem.  The longer you have waited, the bigger the problem!

The Known Knowns

Finally, a data validation would not be complete without considering what the data actually does and does not display.  For example, one weakness of many software monitoring programs is the inability to closely monitor transfer transactions.  Suppose a customer cashes a check and gives the proceeds to another customer.  It is important to be able to determine how this information would be captured by the software.  In the alternative, if the information is not captured by the software, what provisions have been made to monitor such a transaction?

 

In part two, we will address the model validation which has proven to be the most difficult part of this process. 

---

[1] See OCC 2011-12;  Federal Reserve SR 11-7

[2] Ibid 

[3] The guidance clearly applies to ALL banks.