Automating AML alert triage with a human in the loop

Automated AML alert triage puts the assistant on the assembly work. It gathers the evidence, enriches each alert, drafts a first write-up, and ranks the queue by likely risk. The analyst still reads the case, dispositions it, and signs. Every automated step is logged so an examiner can reconstruct what happened months later.

Start with the honest problem. A transaction monitoring system fires far more alerts than a team can meaningfully investigate, and a large majority close as no further action. Analysts spend most of a shift on the parts that are not investigation at all: pulling the customer profile, chasing the counterparty, checking prior alerts and SARs, screening names against sanctions and PEP lists, and copying it all into a case note. The judgement takes minutes. The assembly takes the day. That imbalance is where automation belongs, and it is also where a careless build does real damage, because a confident enrichment carrying a stale or wrong fact reads exactly like a correct one.

What the assistant assembles

Triage is a retrieval and reconciliation job before it is a reasoning job. For each alert the assistant collects the pieces an analyst would otherwise gather by hand:

• The customer and account profile, expected activity, and KYC risk rating as they stood when the alert fired.
• Counterparty details, including any resolved entity behind the raw string on the payment.
• Prior alerts, prior SAR filings, and the disposition history on the same customer and network.
• Sanctions, PEP and adverse-media screening hits, with the match logic that produced them.
• The transactions that actually tripped the rule, with the threshold and typology that fired.

Calling these systems is the easy part. The hard part is entity resolution across feeds that disagree, and point-in-time correctness. If the assistant enriches a three-week-old alert using today’s customer record, it can attach a risk rating or a relationship that did not exist when the transaction cleared. That is lookahead, the same leakage problem you fight when building models, and in triage it corrupts both your eval set and your audit trail. Every fact the assistant surfaces should carry lineage: which system, which field, as of when. An analyst reading the case needs to see the source, not just the claim.

Prioritisation, and how not to build it

The queue is the second target. Not all alerts deserve equal attention, and working them in arrival order wastes the scarcest resource in the building. A prioritisation model that ranks alerts by likely risk lets the team spend its hours where they matter.

Be deliberate here. A ranking model that reorders investigative work is a model under your model risk framework, and in the US that means the expectations of SR 11-7 apply: documented development, independent validation, and monitoring once it is live. It needs a labelled eval set built from historical dispositions, and it carries an obvious trap. Train only on alerts analysts closed and you never learn from the cases they never had time to open. That sampling bias makes the model look sharper than it is.

A few things we hold to:

• Rank, do not auto-close, unless a specific low-risk band has been evaluated well enough to justify straight-through processing. Even then, keep a named owner and a sampled review of the auto-closed population.
• Set an explicit false-positive budget and measure against it, so “we reduced alerts” is a number the second line can check rather than a claim.
• Monitor for drift. Typologies move, thresholds get retuned upstream, and a model calibrated on last year’s mix quietly decays. Write down the recalibration cadence instead of improvising it at quarter-end.

Drafting the disposition without owning it

The last piece is the write-up. The assistant drafts the disposition narrative: what fired, what the enrichment found, and why it points toward closing or escalating. This is genuinely useful. A blank case note is where analysts lose time and where inconsistency creeps in across a team.

It is also where the human-in-the-loop line has to be sharp. The draft is a proposal. The analyst reads it, checks it against the evidence, edits it, and makes the call. The system must record what the assistant proposed, what the analyst changed, and the final decision with the analyst’s identity attached. When a draft recommends escalation and the analyst closes instead, that disagreement is worth keeping. It matters for the individual case, and as a label it tells you where the assistant and your investigators diverge.

Guardrails that matter in practice:

• The assistant never fabricates a fact to complete a narrative. If enrichment failed, the draft says the field is missing rather than guessing. A wrong number that reads right is the failure mode that ends up in front of a regulator.
• Escalation to a SAR filing stays a human decision. The assistant can pre-populate a narrative, but the filing judgement and the sign-off belong to a person.
• Every automated step is logged with inputs, sources and timestamps, so the case is reconstructable long after the analyst has moved on.

None of this shrinks the team or hands the decision to a machine. Analysts open a case that is already assembled, with the evidence gathered, the queue ordered by risk, and a draft they can accept or tear up. Accountability stays where a supervisor and an examiner expect to find it: on the named person who signed the disposition.