AML transaction monitoring: alerts, thresholds and analyst cost
Short answer: AML transaction monitoring watches payment flows for behaviour that does not fit the customer profile, and raises an alert when it finds some. The engineering is straightforward. The problem is volume: monitoring systems generate far more alerts than are worth investigating, and the number of analysts you need to clear them is the real cost of the system. Tune for alert quality, not for coverage.
For the wider programme this sits inside, see AML compliance software, which covers screening, case management and reporting alongside it.
What transaction monitoring is looking for
A handful of patterns, most of them decades old and none of them subtle once described.
Structuring. Breaking an amount into pieces below a reporting threshold. The classic detection is trivial and the classic evasion is to use a different threshold.
Velocity. Money arriving and leaving quickly, especially through an account with no other activity. A pass-through account looks like a pass-through account.
Profile mismatch. Activity inconsistent with what the customer said at onboarding. This is the pattern that makes onboarding data load-bearing months later, and the reason a weak KYC process produces a weak monitoring system.
Geography. Counterparties or corridors inconsistent with the stated business, or in jurisdictions carrying additional scrutiny.
Network structure. Groups of accounts transacting in patterns that make no sense individually and considerable sense collectively. The hardest to detect and the most valuable, because it is where organised activity actually shows.
A transaction monitoring system encodes some subset of these as rules, evaluates them against your flows, and raises alerts. Every anti money laundering software product on the market implements roughly this list; they differ in how the rules are expressed and in what happens to the alerts afterwards.
The alert volume problem
This is the whole of it, and everything else is commentary.
Transaction monitoring software is tuned conservatively by default, so nothing is missed, and conservative rules fire constantly. The overwhelming majority of alerts from a typical AML transaction monitoring system close with no action, and that is normal rather than a defect of your particular configuration.
Two consequences follow. The first is cost: each alert consumes analyst minutes, and analyst salaries exceed the software licence at most volumes within a year. The second is worse: reviewers working through a queue that is almost entirely noise become progressively less attentive, which defeats the caution the conservative tuning was meant to buy.
So the figure to model before signing any AML transaction monitoring software contract is not licence cost. It is expected monthly alerts, multiplied by average minutes to disposition, divided by analyst capacity. If that requires a team you do not intend to hire, you have an alert-quality problem and no procurement process will solve it.
Thresholds decay
A rule calibrated on last year’s customer base misfires on this year’s. Your product changes, your customer mix shifts, average transaction sizes move with inflation, and a threshold that was sensibly placed drifts into either noise or blindness.
This is why transaction monitoring solutions are bought once and tuned forever. Recalibration has to be scheduled work with an owner, a method and a sign-off, rather than something done when somebody notices. The practical cadence is quarterly review of alert volumes by rule, with anything that moved materially investigated for cause.
Two failure modes to watch. A rule whose alert volume collapsed is usually broken rather than successful. A rule that has never produced a case in two years is either wrong or redundant, and retiring it is a legitimate outcome that needs documenting rather than avoiding.
Where machine learning helps, and where it must not
The useful application is triage rather than detection.
Ranking existing alerts by likelihood, so analysts see the ones most likely to become cases first, changes nothing about what gets flagged. Your rule set, your coverage and your regulatory position are identical. What changes is the order of the queue, and the effect on disposition time is substantial. It is also defensible to an examiner precisely because the detection logic is untouched.
Assembling evidence is the second. Pulling counterparty history, related accounts, prior alerts and the onboarding profile into a case file before an analyst opens it removes real minutes from every disposition, and it is ordinary data engineering rather than modelling.
Entity resolution is the third. Deciding whether two records describe the same person or business across spelling variants, transliterations and address changes is a well-shaped problem with a measurable answer, and getting it right improves every rule that operates on a customer rather than on an account.
What machine learning must not do is replace your rules with a model that cannot explain itself. An analyst has to write a narrative and an examiner has to follow the reasoning. Anything touching a filing decision needs a trail a person can read, and that is an architectural constraint rather than a preference.
Buy the platform, build the layer above it
Across every anti money laundering transaction monitoring product we have seen evaluated, the rules engine, the case workflow and the filing connectors are commodity. Several vendors do them competently and there is no advantage in reproducing that work.
What is worth building is the layer that makes your particular alert volume survivable: triage ranking against your own historical dispositions, evidence assembly from your own systems, entity resolution across your own data, and the dashboards that tell you which rules are decaying.
That split keeps you out of the two common traps. Building a monitoring platform from scratch is a multi-year project with no differentiation at the end of it. Accepting a platform’s default tuning is how programmes end up with a backlog and a dashboard.
We build that middle layer as part of KYC and KYB automation, alongside the business process automation services that handle case routing.
What to measure
Four numbers, monthly, by rule rather than in aggregate.
Alert volume per thousand transactions. Transaction monitoring alerts are a trend rather than a level. Sudden movement means a rule is misfiring or your customer base shifted.
Alert-to-case conversion. How many alerts survive first review. Low conversion is a threshold problem and it is fixable.
Time to disposition, split by alert type. Your analyst cost expressed in one figure.
Case-to-filing conversion. How many investigations become reports. Trending toward zero suggests the rules have drifted away from real risk.
Aggregate versions of these tell you nothing actionable. The per-rule breakdown is what identifies the two rules generating forty percent of your noise.
Questions for a vendor
- What is alert-to-case conversion at an institution of our size and product mix?
- Can we express our three most important risk patterns in your rule language? Show us during the evaluation, on our data.
- How is tuning done, by whom, and is a threshold change configuration or a support ticket? Ask specifically whether your own team can adjust an AML transaction monitoring system without vendor involvement.
- Which transaction monitoring tools ship with the platform for rule testing and back-testing against historical flows?
- What does an analyst see when an alert opens, and how much evidence is assembled automatically?
- What does the audit trail record, and can it reconstruct a decision made three years ago after two staff changes?
The second question sorts the field. A platform that cannot express your actual risk patterns during evaluation will not learn to afterwards.
The takeaway
AML transaction monitoring is not hard to build and is hard to run, because every rule you add is a claim on analyst time. Model alert volume before licence cost, tune per rule on a schedule with an owner, use models to rank and assemble rather than to decide, and keep the reasoning trail readable by a person. The programme that works is the one whose queue its team can actually clear.
EpochC builds the decision layer behind AML programmes: triage ranking, entity resolution, evidence assembly and audit trails, as part of KYC and KYB automation. See the KYC OCR automation case study, or start a project.