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 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.
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.