From 1,200 Alerts to 60 Cases: A Financial-Crime Triage & Case-Assembly Build
From 1,200 Alerts to 60 Cases: A Financial-Crime Triage & Case-Assembly Build
It is 8:40 on a Tuesday and the queue says 1,200. An investigator opens the first alert, then a second tab for the customer’s KYC profile, a third for ninety days of transaction history, a fourth for the prior alerts on the same account. Twenty minutes later they clear it — a recurring payroll deposit that trips a velocity rule every two weeks. The next alert is the same customer, the same rule, a different pay cycle. By lunch they have touched forty alerts and filed nothing. Roughly nineteen in twenty of those 1,200 will clear with no action, and each one costs the same manual KYC pull, the same history scrape, the same context rebuild from zero.
This playbook is for the platform lead or investigations manager who has to make that queue survivable. The build does not retune the transaction monitor and it does not touch the core. It sits between them and the investigator, and its job is narrow and concrete: turn 1,200 raw alerts into about 60 assembled cases — each one a single screen with the evidence already pulled, the duplicates already folded in, a drafted suspicious-activity narrative, and a proposed disposition — so the analyst spends the day deciding, not gathering.
Where this layer sits — and what it is not allowed to touch
The core banking system, the ledger, and the KYC store hold the truth, and this build reads from them without ever writing back. Upstream, the transaction monitoring system — rules engine, sanctions and PEP screens, behavioral models — keeps firing alerts exactly as it does today. That is deliberate: the monitor is your detection coverage, and replacing it restarts your model-validation clock and your examiner’s trust. The triage layer is not a new detector. It is a consolidation and assembly layer that consumes the monitor’s output and hands investigators a smaller, richer worklist.
Drawing that line up front is what keeps the build governable. The detection logic an examiner has already blessed stays where it is. Everything new — scoring, consolidation, narrative drafting, the disposition proposal — lives in a layer you can version, replay, and turn off without disturbing the monitor underneath it. If a consolidation rule misbehaves, you have changed how alerts are grouped and presented, not whether they were raised. That is a contained blast radius, and the difference between an upgrade and a re-platforming.
The pipeline: signal, score, consolidate, assemble
Four stages turn the raw alert stream into a worklist. Each stage narrows the volume and adds context, so by the time a case reaches a human it is already most of the way to a decision.
- 01Signalingest monitor alerts + entity context
- 02Scorerank by suspicion × materiality
- 03Consolidatefold correlated alerts into one entity-case
- 04Assemblepull evidence, draft narrative, propose disposition
Signal ingests every alert the monitor emits and resolves it to an entity — a customer, an account, a beneficiary network — so the layer reasons about who generated the alert, not just which rule fired.
Score ranks each alert on two axes the monitor usually conflates: how unusual the behavior is, and how much money is at stake. A $40 velocity trip and a $400,000 round-trip through three new beneficiaries are not the same priority, and the queue should not pretend they are. The score pushes genuinely material activity to the top and lets low-value noise sink.
Consolidate is where the queue collapses. Forty alerts on one payroll account, six alerts that are really one structuring pattern across linked accounts, the same beneficiary lighting up three customers — these fold into a single entity-case. This is the step that turns 1,200 line items into roughly 60 things worth a human’s attention, and the step that quietly prevents the most expensive failure mode in financial crime: forty analysts each looking at one slice of the same network and none seeing the network.
Assemble does the gathering the investigator used to do by hand: for each consolidated case it pulls the KYC profile, the relevant transaction window, the prior alert and SAR history, and the linked entities — then drafts the narrative and proposes a disposition. The output is a case file, not an alert.
The auto-narrative, and the citations that keep it honest
This is where the AI earns its place, and where the discipline has to be strictest. For each assembled case, a generation step drafts the suspicious-activity narrative in the form an investigator actually files: who, what, when, the pattern, and why it is suspicious — in prose, with the structuring or layering or rapid-movement typology named explicitly.
The non-negotiable is that every factual claim in the narrative cites the evidence it came from. “Funds moved through three beneficiaries opened within the prior fourteen days” is not a sentence the model may assert freely; it is anchored to specific transaction IDs and account-open dates in the evidence packet. The drafting model cannot introduce a fact that is not in the pulled evidence, and the investigator reviewing the draft can click any clause back to its source. A narrative the model cannot ground in a cited transaction does not get written — it becomes a flag that the case needs more evidence, not a confident sentence with nothing behind it.
{
"caseId": "AML-2026-018847",
"entityId": "C-771902",
"consolidatedAlerts": ["ALRT-44102", "ALRT-44119", "ALRT-44230"],
"typology": "rapid_movement_new_beneficiaries",
"narrativeDraft": "Between 2026-02-09 and 2026-02-23, customer received $412,000 across two inbound wires and disbursed $398,500 to three beneficiaries each opened within the prior 14 days...",
"citations": [
{"claim": "three beneficiaries opened within 14 days", "evidence": ["ACCT-OPEN-9921", "ACCT-OPEN-9934", "ACCT-OPEN-9940"]},
{"claim": "$398,500 disbursed", "evidence": ["TXN-5510027", "TXN-5510044"]}
],
"proposedDisposition": "escalate_sar_candidate",
"modelVersion": "narrative-gen-2.3.1",
"correlationId": "bnk-c018847"
}The citations array is the part an examiner cares about and the part an investigator trusts. It is what separates an assembled case from an LLM that confidently summarizes a transaction history it may have misread.
The disposition gate: auto-clear, escalate, SAR-candidate
The pipeline proposes; the gate decides what happens without a human and what does not. Three outcomes, and the rules behind them are versioned, executable, and replayable — not a wiki page the team interprets differently each quarter.
RULE TriageDisposition
WHEN case.materiality < material_floor[product]
AND case.typology in auto_clearable_typologies
AND case.prior_sar_count == 0
THEN disposition = "AutoClear"
AND reason_code = "LOW_VALUE_KNOWN_BENIGN_PATTERN"
AND retain_evidence = true -- cleared, never deleted
WHEN case.suspicion_score BETWEEN escalate_low AND escalate_high
THEN disposition = "Escalate"
AND queue = "L1_INVESTIGATIONS"
AND reason_code = case.top_typology
WHEN case.suspicion_score >= sar_candidate_threshold[product]
OR case.typology in mandatory_review_typologies
THEN disposition = "SARCandidate"
AND queue = "L2_SAR_REVIEW"
AND require_human_confirmation = true -- the system never files
WHEN case.evidence_completeness < min_completeness
THEN disposition = "Escalate"
AND reason_code = "INSUFFICIENT_EVIDENCE_FOR_AUTO_DECISION"Two things are load-bearing here. First, auto-clear is the only fully automated outcome, and it is deliberately conservative — it fires only on low-materiality cases matching a typology the team has explicitly approved as routinely benign, with no SAR history on the entity, and the full case file is archived anyway, never deleted, so an examiner can later replay exactly why it cleared. Second, the system never files a SAR. It can mark a case a SAR-candidate, assemble the packet, and draft the narrative, but a human confirms the filing. The gate optimizes one thing — investigator hours spent on cases that matter — subject to one hard constraint: it must not increase the rate of genuinely suspicious activity that escapes review.
The evidence store: built to be replayed
Every case the pipeline produces — cleared, escalated, or filed — lands in one governed store that exists to answer a single question on demand: show me exactly what this system knew, decided, and presented, at the moment it acted. That is the artifact an investigator pulls to defend a disposition and an examiner pulls to test whether the model is deciding alone.
CREATE TABLE case_event (
case_id TEXT PRIMARY KEY,
entity_id TEXT NOT NULL,
consolidated_from JSONB NOT NULL, -- the raw alerts folded in
suspicion_score NUMERIC(4,3) NOT NULL,
materiality_usd NUMERIC(14,2) NOT NULL,
typology TEXT NOT NULL,
narrative_draft TEXT, -- model-drafted, human-editable
citations JSONB NOT NULL, -- every claim -> evidence ids
proposed_disp TEXT NOT NULL, -- AutoClear | Escalate | SARCandidate
final_disp TEXT, -- investigator's call, null until worked
filed_sar BOOLEAN DEFAULT FALSE, -- only ever set by a human
model_version TEXT NOT NULL,
policy_version TEXT NOT NULL,
evaluated_at TIMESTAMPTZ NOT NULL,
correlation_id TEXT NOT NULL
);
CREATE INDEX idx_review ON case_event(proposed_disp, final_disp);
CREATE INDEX idx_replay ON case_event(entity_id, evaluated_at DESC);The fields that matter most are the cheap ones to overlook. consolidated_from lets anyone reconstruct which raw alerts became this case, so a missed alert is never silently swallowed by a merge. citations makes every narrative claim traceable. proposed_disp alongside final_disp records where the human agreed and where they overrode — the override rate is the single best early warning that a threshold has drifted. And because everything is versioned and retained on its mandated schedule (case records and supporting evidence carry the multi-year retention the BSA recordkeeping rules expect), the store is the audit trail; there is no parallel reconstruction to assemble under exam pressure.
The investigator’s day, and the loop back into the scorer
From the analyst’s seat the change is concrete. Instead of 1,200 line items they open a worklist of ~60 cases, each one already a brief: the evidence is pulled, the duplicates are folded, the narrative is drafted with its citations, and a disposition is proposed. Their work is to confirm, edit, or override — and on the SAR-candidates, to make the filing call that is theirs alone.
Every one of those actions feeds back. When an investigator overrides a proposed auto-clear, that is a labeled example that the auto-clear rule was too loose for that pattern. When they confirm a SAR-candidate and file, that is a confirmed-suspicious label. When they downgrade an escalation to nothing, that is a false positive the scorer should learn to rank lower.
The disposition store and the scorer’s training set are the same data viewed two ways. That is what makes the queue improve instead of just persist: yesterday’s investigator decisions are the supervision signal for next month’s scoring model, and the override rate tells you when to retrain before the queue quality slips.
Runbook: tuning thresholds without raising the miss rate
The dangerous knob is the auto-clear threshold, because turning it up is the fastest way to shrink the queue — and the fastest way to start clearing things that should have been seen. Throughput pressure always pushes that knob in the direction that hides misses. The runbook exists to make that impossible to do quietly.
- Alerts the analyst touches1,200/day raw~60 cases/dayCapacity
- Minutes to first decision per case15–25 min3–8 minInvestigator hours
- Duplicate / correlated alerts worked separately30–60%<5%Consolidation
- Case age at disposition5–45 days1–10 daysBacklog / CX
- Auto-cleared cases sampled for QAad hocfixed % every cycleMiss-rate control
The control that keeps capacity gains honest has three parts. First, shadow before you clear: any change to an auto-clear rule runs in shadow for a sampling window, marking what it would have cleared while a human still works those cases, so you measure the miss before you ship it. Second, a held-out sample of auto-cleared cases is always re-reviewed — a fixed percentage of everything the gate clears goes to a human anyway, and a confirmed-suspicious case found in that sample is a hard stop that reverts the threshold. Third, the override rate is the alarm: when investigators start overriding the gate’s proposals more often, the thresholds have drifted relative to reality and the scorer needs retraining — and that signal arrives well before a missed SAR surfaces as a regulatory finding.
Because this runs at high volume on the bank’s most sensitive transaction data, keep scoring and consolidation inside your boundary, close to the data — only the open-ended narrative drafting needs a larger model, and even that operates strictly on evidence the pipeline already pulled, with the same retention rules the customer record carries. The high-frequency decisions never leave your control, and you pay no per-call tax on the thousands of routine alerts the gate clears every day.
What we covered
The point was never to make the queue empty. It is to hand every investigator a day spent on the sixty cases that might be a crime, with the evidence already on the screen and the noise already gone — and a case file that holds up the day an examiner asks why this one was cleared and that one was filed.
References: FFIEC BSA/AML Examination Manual · FinCEN SAR filing instructions & narrative guidance · 31 CFR 1020 (BSA recordkeeping & retention) · SR 11-7 model risk management · NIST AI RMF · NIST Privacy Framework · NIST CSF 2.0 · CISA Secure by Design.