For many Bank Secrecy Act officers and their boards of directors, the thing that haunts their dreams most is their examiners finding some suspicious transactions that should have been investigated, but weren’t. If such transactions are found, what typically follows are two questions along the lines of:

• Why weren’t these transactions identified by the institution for investigation?
• How many other transactions of a similar nature weren’t identified for investigation?

Depending on how the answers to the above questions go, the next step could be an order to look back at all transactions over period of months or years to determine whether there were other transactions that should have alerted but didn’t. That can be a very costly undertaking in terms of labor, fines, and reputation.

Of course, the best preventative course of action is a validation of the institution’s anti-money laundering system. Frequently, however, such validations are limited to confirming that the alerts that the AML system generated were confirmed by a review of the underlying transactions. Such an analysis may be called a “back-to-front” analysis, where the “back” is the alert generated by the AML system, and the “front” are the transactions from the various core systems that feed into the AML system.

A “back-to-front” analysis is a fundamental part of an AML validation. However, when it comes to transactions that should have alerted, but didn’t, the back-to-front has nothing to analyze, because “phantom alerts” (alerts that should have been generated, but weren’t) are invisible. To detect the presence or absence of phantom alerts, another piece of analysis – the more difficult part – is required. We call it the “front-to-back” analysis. More about that soon. First, a bit of background.

Looking Under the Bed

The point of a validation is to make sure that your AML monitoring system is working as designed. In other words, you want to have a reasonable assurance that your system is triggering alerts aimed at detecting illegal and/or terrorist activity when it should. No more, no less. It is about thoroughly looking under the bed during the light of day to make sure the coast is clear before darkness falls.

At a fundamental level, an AML system works like this. All transactions at the financial institution flow through various core systems and are fed through the AML system, which applies the various rule parameters to the transactions, and when it sees a certain threshold has been crossed, either directly or through a combination of transactions, it creates an alert for those transactions.

For example, a system may have a structuring alert that looks for transactions that are greater than $3,000 but less than the CTR threshold of $10,000. The system would then look for multiple transactions of this nature across a specific time frame, typically around a week. Customers who have aggregated activity over a certain amount, say $10,000 or $15,000, during that time period would trigger an alert for someone in the BSA department to review. That investigator might then discover either that there was a legitimate reason for the cash transactions or that the transactions warrant further investigation.

Back to the Back-to-Front

The problem with stopping after a back-to-front analysis is it doesn’t answer the question of whether all transactions that should have triggered an alert actually triggered an alert. It is good to confirm that an alert is valid, but how do you confirm that the “non-presence” of an alert is valid? Were there actually no transactions that should’ve triggered a given alert, or is there a problem with the configuration of the system that resulted in transactions that should’ve triggered an alert being missed?

Front-to-Back Analysis

To figure this out, it is necessary to conduct what we call a “front-to-back” analysis. In other words, we want to provide a reasonable assurance that the transactions from the core systems – or “the front” – that should’ve triggered an alert actually did trigger an alert in the AML system – or “the back.”

Many AML validation efforts omit the front-to-back validation because it is – frankly – a lot of work. In order to conduct such a cross check, it is necessary to take a sample of the core transactions for a given period of time – say a month of data – and run those transactions through – in essence – a secondary AML system to see if there are any discrepancies between the two systems.

Of course, you spent a lot of money on your AML system, so you may not be excited to spend money on a secondary system, but how else will you be able to cross check your core data? A month of transactional data can mean hundreds of thousands or even millions of rows of data, so a manual check can likewise be cost-prohibitive.

Hence, one workable solution is to re-create the primary rule parameters in a secondary system, such as SQL analysis, to identify those transactions that fall within the identified parameters and should have generated an alert. It’s a sizable project to recreate the rule parameters, but it allows us then to compare a list of what our secondary system generated to what actually was generated by the AML system. We then work with the BSA team, which then sometimes in turn works with its AML system vendor, to determine the cause of the discrepancies. Frequently it turns out that there are exemptions for certain customers or other valid reasons why the discrepancies are justified.

But there are other occasions where key issues may be identified. Examples that we’ve seen are cases where transactions were not properly imported due to some change in the system, or a transaction code had been inputted incorrectly so that certain cash transactions were coded as ACH transactions, or that somebody jumped the gun on a parameter change without going through the full approval channels. There are many possible reasons, some valid, some not, but the point is that if the front-to-back isn’t conducted, it is impossible to know whether something that should have alerted didn’t.

Moreover, “checking under the bed” via a front-to-back as well as a back-to-front analysis isn’t a one-and-done deal. Ghosts can sneak under the bed from time to time, such as when one of the core systems change or when thresholds are adjusted. As such, solid nightmare management involves conducting under-the-bed checks on a periodic basis. Industry best practices typically suggest conducting validations about every 12 to 24 months.

If it has been awhile since you’ve had one conducted for your institution, let AdvisX’s AML validation services help you get a better night’s sleep. Our approach allows us to conduct both front-to-back and back-to-front analyses completely off-site, saving you money and the nightmare of having your secondary conference room invaded for a week. Here is more info.