AML Transaction Monitoring Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why do monitoring projects turn into replacing the scenario library?

Because the finding said monitoring, and monitoring sounds like detection. So the programme becomes a search for a new engine, and the institution spends heavily to replace a scenario library that was never the problem. This is the single most expensive mistake in the category and it is common enough that we open most conversations by asking what the finding actually said.

Read it again carefully. Findings in this area are usually about governance, tuning evidence, data quality or documentation, not about a typology the system failed to express. NICE Actimize and Oracle Financial Crime and Compliance Management ship deep, examiner familiar scenario libraries. Verafin is genuinely strong for community banks and credit unions. Feedzai and Hawk bring modern detection with better false positive characteristics. Replacing any of them does not by itself produce a threshold justification, a change log or an entity resolution fix, which are the things that were missing.

The fix is to scope from the finding backwards. If the gap is evidence, build the evidence layer around the engine you already own. If the gap is data, spend the first tranche on entity resolution and expected activity capture, which reduce alert volume without reducing coverage. Replace detection only when your products genuinely sit outside the library, which is a narrower set of institutions than the ones who attempt it. Wrapping is typically a fraction of the cost of replacement and addresses what the examiner wrote down.

What goes wrong with your customer and transaction data?

The data layer is where monitoring programmes actually fail, and it is nobody's project. The same customer exists as three records because the core, the card processor and the digital channel each created one. Expected activity was collected once at account opening in a free text field and never revisited. Counterparty names arrive differently from each channel, so two hundred transfers to one beneficiary look like two hundred beneficiaries. None of that is a scenario problem, and no threshold change fixes any of it.

Historical depth is the second data problem and it bites later. Replay testing, which is what makes tuning defensible, needs several years of transactions in a queryable shape with the customer and account relationships as they stood at the time. Institutions that archived transactions without the surrounding context can run scenarios over history but cannot reconstruct who the customer was then, which makes the results unusable as evidence.

The fix is to spend the first meaningful tranche of the budget on entity resolution across channels, on structured expected activity captured at onboarding and refreshed at review, and on counterparty name normalisation. This is also the one place where machine learning earns its keep without controversy, because matching is exactly what it is good at and nothing is being suppressed. Then build the historical store deliberately, with point in time customer and account attributes, rather than assuming your data warehouse already supports the question.

Why do core, case management and screening integrations break after launch?

Monitoring sits downstream of everything. The core banking system, the card processor, the digital channel, the wire platform, the case management system, sanctions and watchlist screening, and eventually the filing route. Each is maintained by a different team or vendor on a different release schedule, and each breaks in a way that leaves the monitoring system looking healthy.

The specific failures are worth naming. A core upgrade adds a transaction code that maps to nothing, so a category of activity stops being aggregated and no scenario fires on it. A new product launches and its transactions land under a channel identifier the monitoring feed does not recognise, which means the product is effectively unmonitored while everyone assumes otherwise. A case management integration drifts because the two systems key on different customer identifiers, so prior alert history stops resolving and investigators start closing repeat behaviour as first occurrences. A screening provider changes its response format and matches silently stop attaching.

The fix is completeness reconciliation as a standing control. Every day, compare transaction counts and values by product and channel between source systems and the monitoring store, and raise an exception on any difference, including a difference of zero where activity was expected. Maintain an unmapped transaction code queue that a human clears, rather than defaulting unknown codes to a catch all. And test the customer identifier join between alerts, cases and the core on a schedule, because a broken join produces plausible looking output rather than an error.

What happens when threshold changes have no lineage?

This is the gap that produces findings. An examiner asks why a structuring scenario fires at a particular aggregate over a particular number of days, who approved it, what analysis supported it, what the alert and case outcomes were at that setting, and what happened when you tested just below the line. In most institutions the threshold is in a vendor console, the justification is in a consultant's slide deck from two years ago, and 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.

The related failure is that alerts cannot be reproduced. If a scenario has been edited in place, an alert from eighteen months ago cannot be explained, because the logic that produced it no longer exists anywhere.

The fix has three parts and none of them are exotic. Version every scenario and every parameter change with an author, a date, a rationale and an approval, and store the executing version identifier against every alert so any historical alert can be reproduced exactly. Make above the line and below the line testing native functions rather than an annual consulting exercise, by replaying historical transactions through candidate parameter sets. And record the reason for every change honestly, including when the reason is capacity. A documented capacity decision with a compensating control is defensible. An undocumented one is the finding.

Should you build custom or configure what you already own?

Configure, and stay configured, 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, which has real value. Your money belongs in data quality and tuning evidence, not in rewriting scenarios somebody else has already validated across many institutions.

Before building anything, exhaust the incumbent. Many institutions run a capable engine on default segmentation, with expected activity never populated, with alert dispositions captured as free text, and with reporting nobody has configured. Fixing those is faster and cheaper than any project, and it removes the most common causes of alert volume.

Build detection yourself when your products are genuinely outside the library. Money services businesses with corridor specific typologies, payments companies with sub merchant flows, digital asset on ramps, trade finance and banking as a service programmes where the customer of your customer matters are the clear cases. The FFIEC examination manual expects monitoring to reflect your risk assessment, so a typology named in your own risk assessment that your system cannot express is a gap documented in your own files, which is the worst place for it to sit. Build those scenarios with the same versioning and testing discipline as everything else.

How do hidden costs get into the quote?

Source system count is the first driver. Each channel feeding transactions is a separate mapping, a separate data quality argument and a separate reconciliation control. A quote written against a core and delivered against a core, a card processor, a wire platform and two fintech partner programmes is a different project.

The state of your know your customer data is the second, and it is almost always worse than the compliance team believes. Expected activity in free text, missing occupation and business type, stale beneficial ownership records: remediating these takes longer than any plan allows because it requires customer outreach, not engineering.

Historical depth is the third. Replay testing needs years of transactions with point in time context, and building that store is frequently a bigger piece of work than the scenario engine itself.

Real time requirements are the fourth. If any scenario must decision inside a payment path rather than overnight, you have moved from a batch analytics problem to a latency sensitive one, and that changes the architecture and the cost. Say so during scoping rather than discovering it in month four. Fifth is model validation, if you introduce any model based detection, because independent validation and documentation is a real line item and should be budgeted from the start rather than met with surprise.

What separates a build that works from one that fails here?

The working build can answer the examiner's question without a project. Which scenario version and parameter set produced this alert, who approved that setting, what analysis supported it, and what the outcomes were on either side of the change. 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.

The second difference is one customer spine that every alert, case, transaction and risk rating hangs from. An investigator should open an alert and see the customer 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. Five systems and no shared identifier is twenty minutes before any thinking starts, on every alert, forever.

The third is structured dispositions rather than free text. The pattern of dispositions is the raw material of tuning. Two hundred alerts closed with a recorded reason of expected business activity for a named customer segment is a tuning insight. The same two hundred closed with a note is nothing at all.

The fourth is ownership, written into the contract before kickoff: the repository, the scenario definitions, the parameter history and the cloud accounts. Your tuning history is your regulatory defence and it compounds in value every year as outcomes accumulate against it. At Digital Heroes the client owns all of it from the first commit, and we would tell you to walk away from any arrangement that makes your threshold justifications somebody else's property.