Your Financial Institution’s AML Software May Not Be Reducing Risk
You may have heard a lot of talk recently about anti-money laundering (AML) software validation, or AML software independent testing. These phrases are the current buzzwords in industry newsletters, discussion boards, conferences, and exams. But you might not be sure what all this talk is really about.
Although there is testing done for both BSA/AML and AML software, the testing process is different. Simply put, AML software testing helps validate a financial institution’s AML software — both how it is working together with the financial institution’s core system and whether the software is set appropriately to identify potentially suspicious transactions as part of the financial institution’s anti-money laundering program. To properly test your software, both your system and your institution’s operations as a whole should be inspected.
Testing required by two main sources
Depending on the type of financial institution and its regulator, there are at least two main sources requiring software validation.
The Federal Financial Institutions Examination Council (FFIEC) Bank Secrecy Act (BSA)/AML Examination Manual discusses automated suspicious activity monitoring, stating that “… the monitoring system’s programming methodology and effectiveness should be independently validated to ensure that the models are detecting potentially suspicious activity. The independent validation should also verify the policies in place and that management is complying with those policies.” The manual goes on to direct examiners to “determine whether the programming of the methodology has been independently validated.”
The second source requiring AML software validation only applies to certain financial institutions. The Federal Reserve and OCC published the joint bulletin Supervisory Guidance on Model Risk Management on April 4, 2011. This document not only covers AML software, but all models used by institutions in everyday business. Among other things, this bulletin describes the need for model validation, as well as the elements and timing of validation.
Software validation should include a background review
A thorough testing of AML software should begin by conducting a background review. A validator should pay particular interest to how the model was developed and implemented — whether the design was configured for the financial institution’s size, environment, and customer or member base, and whether the model was tested prior to and after implementation. A validator should also take note of how the financial institution uses the AML software in connection with any other manual transaction monitoring within its AML program.
Testing isn’t complete until team operations are inspected
Your software isn’t the only part of your institution that should be inspected during testing. Access controls and change management are vulnerable areas that can potentially compromise the effectiveness of your software. A validator should want to know who is using the software, who is changing the software, and who is reviewing or supervising it. By inspecting how management has incorporated any additions of new products or services into the AML software, your can see a well-rounded view of how well your software is functioning as a whole.
Core system testing vital to your software’s success
Your institution’s core system and AML software need to work as a team. To make sure this is happening, a validator should test the completeness of the population of transactions flowing into the AML software, as well as the accuracy of the data. This would include back-testing, using core system data, to ascertain whether the financial institution’s AML software is reasonably configured to catch potentially suspicious transactions.
How we can help
CLA’s financial institution professionals are well-versed in AML software testing. Our approached is designed to meet both the requirements of the FFIEC BSA/AML Examination Manual and the Federal Reserve and OCC joint bulletin. We can help pinpoint weak or ineffective parameters in your software to help limit risk and improve efficiency. Upon completion of our testing, we provide you with a report you can take back to your vendor so you can make any necessary changes.