Originally published at Trida AI.
The clock starts before anyone reads the alert. Under the Bank Secrecy Act, a suspicious activity report is due thirty days after initial detection — sixty at the outside when no subject has been identified — and detection is when the monitoring system fired, not when an analyst got back from leave and opened the queue. Every AML team knows the arithmetic and feels it anyway: the first week of a case is usually spent assembling the file. Pulling the customer's history. Re-running screening. Gathering the transactions into something an analyst can reason over. The deciding is the skilled part, and it gets whatever time the gathering leaves behind.
This open blueprint, the AML Investigation Agent, is built to hand that week back. It takes the alert the monitoring system already produced and does the assembly itself: screening, pattern analysis, an investigation record in which every finding cites the evidence it rests on, a drafted disposition, and — where the case goes that way — a drafted SAR narrative. Then it stops. A named analyst decides the case, a second person approves any narrative, and nothing in the system files anything.
The alert arrives with its clock already running
Intake is unglamorous and strict. An alert enters once — a repeat submission lands on the same case rather than opening a second one — and the verbatim alert becomes the case file's first piece of evidence, stamped with the detection date. That date anchors everything: the filing clock is computed from it in code, thirty days when a subject is identified, the sixty-day outer limit when none is, derived from what the record holds rather than asserted by whoever is holding the case.
Evidence in this design is not a folder. Every item is hashed, and each hash chains to the item before it on the same case, so a file that has been altered anywhere shows it everywhere downstream. There is no edit and no delete on the evidence store; a correction is a new item, chained like the rest. Clocks, screening, findings, decisions — all of it sits on that chain, because a case file's whole value at examination time is that it can prove what it knew and when it knew it.
Screening against lists that stand still
Screening has a quiet reproducibility problem. Lists change daily, so "the customer was screened" is incomplete unless the file can say against which version of which list. Here, sanctions, PEP and adverse-media lists are ingested as fixed snapshots, each content-hashed, and a case's screening runs against a named set of snapshot versions — never against whatever the list happens to be today. When a new version lands, open cases that ran on older pins are re-screened and flagged stale until they are.
The matching keeps the discipline a good screening analyst keeps. A shared identifier or a matching date of birth makes a hit strong; a name match contradicted by the date of birth is treated as what it usually is — a namesake — and cleared with the reason recorded. And the posture binds the ending: a case with an unresolved sanctions hit cannot be closed at the disposition gate. Escalation is the only way out.
One case, from alert to sealed file — each lane is one actor; the agent assembles and drafts, people decide.
The patterns are arithmetic, not opinion
What the monitoring system flagged is a suspicion, not an analysis. The analysis here is a set of deterministic checks run over the case's transactions: cash activity clustered just under the reporting threshold, in same-day and multi-day shapes; velocity measured against the account's own baseline rather than a generic one; an account dormant for months that suddenly bursts; round amounts dominating the flow; money that arrives and leaves quickly, keeping only a small retention on the way through.
Two properties matter more than the list. The checks are computed in code, to the cent, from the stored records — the language model never computes a money figure anywhere in this system. And they run from versioned rule packs, so a finding records which version of which rule produced it, and re-running the same pack over the same evidence produces the same finding. When the rules change, the change is a new pack version, and old findings still say what judged them.
Every finding carries its evidence
The investigation itself is a structured pass over the assembled file — assemble, draft, search for the counter-evidence, compose, verify — run on LangGraph. Its output is an investigation record with a discipline most case files only aspire to: facts, a working hypothesis, and open questions are kept in separate sections, and every finding is a statement plus citations that must resolve to a specific element of a specific evidence item. A finding whose citations do not resolve is refused when the record is written. Not flagged for later. Refused.
The counter-evidence search is a named step, not a hope. It looks for the innocent explanation in the data — a regular cadence that predates the flagged cluster, a documented expectation the burst matches, an established counterparty, a cleared namesake — and records what it found either way, so the hypothesis section names its supporting and its opposing findings side by side. The open questions each name the evidence that would resolve them, which is what turns "we need more information" from a shrug into a work list.
A case file as the analyst opens it: findings with their citations, and one draft statement the verifier cannot ground.
Two people stand between a draft and a filing
A disposition in this system is a recorded act, not a dropdown. It names the analyst, one of five coded outcomes — close, close under monitoring with a review period, escalate to SAR drafting, escalate to the second line, or send back naming the missing evidence — and a coded rationale from a maintained vocabulary, which free text may supplement but never replace. It must cite the current version of the investigation record; if newer evidence has superseded that version, the case is flagged as carrying a stale disposition until a fresh one answers it.
Adverse closures take two people. Closing a case whose hypothesis is adverse parks it until a second-line reviewer — never the analyst who dispositioned it — confirms. SAR narratives take two people as well, and the second pair of eyes is mechanical about its job: before a narrative can be approved, a verifier re-resolves every statement in it against the cited evidence, and a narrative with any statement that cannot be verified cannot stand. The approver, in turn, may be neither the analyst who escalated the case nor the actor who drafted the text. At the end, a named officer can seal the file: the seal re-verifies the evidence chain, certifies a manifest of everything in the file, and makes the case read-only. What the system never does, at any point, is file the SAR. The draft is where its authority ends.
One more habit is worth naming, because the threat is current: text that arrives from outside the bank — transaction memos, counterparty names, alert summaries, articles — is treated as untrusted, because some of it will eventually be written by someone who knows an agent reads the file. A scanner checks that text as it enters; a planted instruction does not block the evidence, it becomes a recorded event on the case's chain, and the passages it touched are fenced wherever the text is later used, so a figure quoted inside an instruction can ground nothing.
What it will not do
It will not file, decide, or clear a sanctions hit on its own, and it will not pretend the data it ships with is a bank's data: the screening lists are stand-ins for the licensed lists a real program runs, and the adverse-media source is a reference corpus standing in for a licensed news database. The drafting can run through a hosted model where a bank's policy allows one, and the same figure checks apply to that text — but the judgement calls, the disposition, the approval, stay with named people. What a deployment adds is the institution's own substance: its lists, its rule-pack thresholds tuned to its risk appetite, its filing process on the far side of the approved draft.
Work with us
If your financial-crime team is spending its first week on every case assembling files instead of deciding them, that assembly is buildable — with the clocks, the citations and the dual control kept in code where an examiner can see them. Bring the problem through Trida AI's intake and we will scope what an investigation agent inside your BSA/AML program should, and should not, be allowed to do.
Get the Code on GitHub: github.com/tridaai/blueprint-aml-investigations
Top comments (0)