AML Transaction Monitoring: Building a System That Can Defend Its Thresholds to an Examiner

Why monitoring programs fail the exam and not the criminals

An examiner rarely asks whether your system caught a launderer. They ask why your structuring scenario fires at a particular aggregate over a particular number of days, who approved that, what analysis supported it, what the alert and case outcomes were at that setting, and what happened when you tested just below the line. That is four questions about evidence and one about detection.

In most institutions the answers live in three places. The threshold is in a vendor console. The justification is in a slide deck from a consultant engagement two years ago. The outcomes are in a case system that does not share keys with the alert system. Nobody can assemble those into one document without a project, which is why the finding is so often written about governance rather than detection.

The second failure is quieter. Alerts pile up, the queue grows, and the response is to raise thresholds because the team cannot cope. That is a capacity decision being made as a risk decision, and it is undocumented by definition. Everyone in financial crime knows this happens. Almost no monitoring system is built to make it visible.

Problem one: the data layer is the actual weakness

Scenario logic is comparatively simple. Aggregate cash activity by customer across a rolling window. Compare wire activity to expected activity captured at onboarding. Flag rapid movement through an account. The reason these produce noise is almost never the logic. It is that the customer is three customer records because the core, the card processor and the digital channel each created one. It is that expected activity was collected once at account opening in a free text field. It is that a counterparty name arrives differently from each channel, so two hundred transfers to the same beneficiary look like two hundred beneficiaries.

NICE Actimize and Oracle Financial Crime and Compliance Management ship deep scenario libraries and are the conservative, examiner familiar choice, and that matters. The honest limitation is that tuning is slow and costly through a vendor cycle, and explaining behaviour you cannot inspect is harder in a room with an examiner. Verafin is genuinely strong for community banks and credit unions and brings cross institution context most single institutions cannot build, provided your profile matches the one it was designed around. Feedzai and Hawk bring modern detection with better false positive characteristics, and the burden then shifts to explainability and validation under model risk expectations, which is real work rather than a reason to avoid them.

None of them can fix your entity resolution. That is your data, your channels and your history, and it is where the first fifty thousand dollars of a monitoring project should go, whatever engine you keep.

Problem two: thresholds without lineage are indefensible

What a defensible build looks like: every scenario has a version, every parameter change has an author, a date, a rationale and an approval, and the system can reconstruct exactly which scenario version and parameter set produced any historical alert. When an examiner asks why the threshold moved in March, you produce the change record, the analysis that supported it, the approver, and the alert and case outcomes for the ninety days either side.

Add above the line and below the line testing as a native function rather than a consulting exercise. Below the line sampling means taking activity that fell just under the threshold, sampling it, and having investigators review it to demonstrate you are not missing productive alerts. Above the line means testing whether raising a threshold would have lost real cases. Both are standard practice, both are usually done manually once a year by an outside firm, and both become routine when the system can replay historical transactions through a candidate parameter set. That replay capability is the single feature that changes the character of a monitoring program, because it turns tuning from an argument into a measurement.

Problem three: your products are not in the scenario library

Vendor scenarios encode conventional banking. If you are a conventional bank, that is a strength. If you run a money services business portfolio, a payments company with sub merchants, a digital asset on ramp, trade finance, a banking as a service programme with fintech partners, or a cannabis related banking program, the typologies that matter to you are not in the box, and the vendor customisation to add them costs more than building them.

The FFIEC examination manual expects your monitoring to reflect your risk assessment. If your risk assessment names a typology your monitoring cannot express, that gap is written down in your own documents, which is the worst possible place for it to be. This is the strongest genuine case for custom scenario work: not replacing an engine, but adding the detection your specific products require, with the same parameter versioning and testing discipline as everything else.

Problem four: alerts, cases and customer risk do not share a spine

An investigator opens an alert, then opens the core to see the customer, then opens the KYC system to see the risk rating and the expected activity, then searches the case system for prior alerts on the same customer, then checks a negative news tool. Five systems, no shared identifier, twenty minutes before any thinking starts.

What a custom build does: one customer spine that every alert, case, transaction and risk rating hangs from. The alert opens with the customer's profile, the expected activity captured at onboarding and at last review, prior alerts and their dispositions, related parties, and the specific transactions that triggered the scenario with the aggregate shown. Disposition capture is structured, not free text, because the pattern of dispositions is the raw material of tuning. Two hundred alerts closed with the reason recorded as expected business activity for a customer segment is a tuning insight. The same two hundred closed with a free text note is nothing.

Where AI genuinely helps and where it does not

Two places earn their keep. Entity resolution across channels and counterparty name normalisation, which is a matching problem that machine learning is well suited to and that no rule set solves. And alert triage scoring, used to order the queue rather than to close alerts, so investigators spend their first hours on the alerts most likely to be productive. Scoring the queue is defensible because nothing is suppressed.

Where we advise caution: using an opaque model to close alerts automatically. Under model risk expectations you will be asked to validate and explain it, and a model that cannot be explained becomes an examination finding rather than an efficiency. If you go there, budget for independent validation and full documentation from the start, and keep a rules based safety net for the typologies your risk assessment names explicitly.

What it costs and how long it takes

A first release, meaning the customer and transaction data layer with entity resolution, scenario execution with parameter versioning, and alert triage with structured dispositions, runs $100,000 to $240,000 and ships in 14 to 20 weeks. A full platform adding customer segmentation, historical replay for above and below the line testing, tuning evidence packs, model documentation and integration with case management and filing runs $280,000 to $700,000 across 9 to 18 months.

What pushes cost up specifically: the number of source systems feeding transactions, since each channel is a separate mapping and a separate data quality argument. Historical depth, because replay testing needs several years of transactions in a queryable shape. Product complexity, particularly correspondent banking, trade finance and partner banking programmes where the customer of your customer matters. Real time requirements, if some scenarios must decision inside a payment path rather than overnight. And the state of your KYC data, which is usually worse than the compliance team believes and always takes longer to remediate than the plan says.

Build versus wrap versus buy

Buy the engine if you are a community bank or credit union with conventional retail and commercial products. Verafin and its peers cover your typologies and your examiner has seen them before. Your money goes into data quality and tuning evidence, not into rewriting scenarios someone else has already validated.

Wrap the engine, which is the answer we give most often, when the engine is adequate but the surrounding evidence is not. Keep the vendor detection, build the data layer, the parameter governance, the replay testing and the tuning documentation around it. This is typically a third of the cost of a replacement and addresses what the finding actually said.

Build detection yourself when your products are genuinely outside the library: payments companies with sub merchant flows, digital asset businesses, banking as a service programmes, money services businesses with corridor specific typologies. In those cases the vendor scenarios are approximations of somebody else's business, and you will pay for customisation that is worse than the thing you could have owned.

How to choose a developer for financial crime work

Ask how they will reconstruct which scenario version and parameter set produced an alert from eighteen months ago. If the design does not version parameters and store the executing version against the alert, the system cannot be defended and should not be built.

Ask how they intend to handle entity resolution across your channels, and listen for whether they ask about your core, card processor and digital channel identifiers in the same breath. A team that treats the customer as a given has not worked on monitoring.

Ask what they will do about below the line testing. If it is not a function of the product, you will be paying a consultant to do it manually every year forever.

Ask who owns the code, the scenario definitions and the tuning history, and put it in the contract before kickoff. Your tuning history is your regulatory defence and it compounds. At Digital Heroes the client owns all of it from the first commit, and we would tell you to walk away from anyone whose contract makes your threshold justifications their property.