How to evaluate AML transaction monitoring and SAR software

What this software does

Anti-money laundering (AML) monitoring software reviews account activity for patterns that may point to money laundering, fraud or other financial crime, such as structuring cash deposits to stay under reporting thresholds or moving funds quickly through several accounts. When a pattern matches a detection scenario, it raises an alert. Analysts close or escalate alerts, investigators work escalated cases, and a case that meets your institution’s standard leads to a Suspicious Activity Report (SAR) filed with FinCEN.

Products differ most in scope: sanctions screening, Currency Transaction Reports, customer risk rating and onboarding checks may or may not be included. Decide early which of these you are buying.

The rules that shape the work

The Bank Secrecy Act (31 U.S.C. 5311 and following sections) is the main US anti-money laundering law, and FinCEN issues the rules that carry it out. A few of those rules set what monitoring software has to support:

• The AML program. 31 CFR 1020.210 requires a bank’s program to include internal controls, independent testing, a designated person responsible for day-to-day compliance, training, and risk-based customer due diligence that includes ongoing monitoring to identify and report suspicious transactions. Software supports the controls and the monitoring, not the rest.
• When a SAR is required. Under 31 CFR 1020.320, a bank reports a transaction that involves or aggregates at least $5,000 when it knows, suspects or has reason to suspect one of the listed conditions, such as funds derived from illegal activity or a transaction designed to evade Bank Secrecy Act requirements. Other kinds of financial institution have their own SAR rules elsewhere in 31 CFR Chapter X.
• Deadlines. The same rule requires filing no later than 30 calendar days after the initial detection of facts that may constitute a basis for filing. If no suspect has been identified, filing may be delayed by up to 30 more days to identify one, but never beyond 60 calendar days after initial detection.
• Records and confidentiality. A bank keeps a copy of each SAR and its supporting documentation for five years from filing. A SAR, and any information that would reveal that one exists, is confidential.

SARs are filed electronically through FinCEN’s BSA E-Filing System. Examiners review monitoring and reporting using the FFIEC BSA/AML Examination Manual.

Who should be on the evaluation team

• The BSA/AML officer, who answers for the program and approves filing decisions.
• Analysts and investigators, who will work alerts and cases every day and know where the current process loses time.
• Model risk or analytics staff, who will tune scenarios and thresholds and need to evidence each change.
• Data and IT owners for the core banking system, cards, wires and ACH, because every feed has to be mapped.
• Information security, to review access control and where SAR data will be held.
• Internal audit, as an observer.

Questions to ask and things to test

Insist on testing with your own data: a demonstration on sample data shows the screens, not how the product behaves with your customers.

• Run a sample of your own anonymized transactions and compare the alerts with those from your current system. Ask the vendor to explain each difference, both the alerts it missed and the new ones it raised.
• Have one of your analysts work an alert from the queue to closure, and count how many other systems they still need to open.
• Read the explanation attached to an alert. Can you see which scenario fired, on which transactions, against which threshold? Would that satisfy your examiners?
• Take a case through to a draft SAR. Review the narrative, the attached evidence, and how the result reaches BSA E-Filing.
• Ask how filing deadlines are tracked, starting from the detection date your procedures define, including the 60-day maximum when no suspect is identified.
• Change a threshold in testing and check the record: who, why, what testing, who approved.
• Check role separation. Who can draft a SAR, who can approve it, who can export it, and who can change detection logic? Can any one person do all four?
• Ask how you would leave. Can every alert, case, decision and supporting document be exported in a usable form, so you can meet the five-year retention requirement after the contract ends?

Common limits to probe

None of these is a flaw in itself, but each needs an answer before you sign.

• Who files? Some tools prepare a SAR for a person to review and submit; check exactly what is automated and what remains a human decision.
• Data dependence. Detection can only be as complete as the transaction and customer data you supply. Ask what happens when a feed is late or incomplete, and whether the product tells you.
• Sanctions screening. Is it included, or does the product consume results from your existing screening system?
• Other reports. Currency Transaction Reports and other Bank Secrecy Act filings may not be covered.
• Jurisdiction. A product built for US rules may not cover reporting elsewhere.
• Timing. Most monitoring works after transactions are recorded. If you need payments stopped before they complete, confirm that is in scope.
• Decisions. Thresholds, scenario changes and filing decisions belong to your institution. The software should record and test them, not approve them.

Implementation risks

• Incomplete data mapping. A product type or transaction code that is not mapped is simply not monitored. Reconcile record counts with the source systems.
• Alert volume. Untuned scenarios can produce far more alerts than your team can work. Set initial thresholds from tests on your own data, and plan staffing for the first months.
• The cutover. Run old and new systems in parallel long enough to compare results, and decide where open alerts and cases will be finished, so that no filing deadline falls between two systems.
• Historical records. Cases and SAR documentation from the old system still fall under the five-year retention requirement.
• Independent testing. Plan for the new system’s scenarios, data feeds and thresholds to be covered by your program’s independent testing, and by your model risk process if your institution treats them as models.
• Ownership after go-live. Name who reviews thresholds, how often, and who approves changes. Also decide who at the vendor may see your data, since SAR information is confidential.

Related reading on this site

Requirement pages: Bank Secrecy Act and anti-money laundering rules, OFAC sanctions regulations.

In the glossary: AML and BSA, KYC and CIP, OFAC.

This guide describes the category, not any one product. It is general information, not legal advice: for what a rule requires of your organization, read the rule itself or ask your counsel.