Transaction-monitoring systems produce alerts, and each alert needs a person to establish what happened. A large share of an analyst's time goes to gathering: pulling the customer profile, reading know-your-customer documents, scanning transaction history, checking counterparties, searching for adverse news, and reading earlier alerts on the same customer. The judgment comes after, and it is the smaller part of the work.
That split makes this a strong first use case. The gathering is repetitive, spread across systems, and checkable. The judgment is accountable and stays with a person. Anthropic lists KYC screening and credit memos among the agent templates for financial services, which fits: the pattern of assembling evidence from many sources and presenting it for review is common across the sector.
The design
This is the orchestrator-workers pattern from the architecture article. The investigation path depends on the alert, so a fixed chain does not fit. A bounded orchestrator breaks the alert into questions and sends them to workers.
- Alertfrom monitoring
- Triagesmall model: type, duplicates
- Orchestratorplans questions
- Workersprofile, transactions, counterparties, news
- Assemblepacket, every claim cited
- Checksecond model tests the packet
- Analystdecides and records
- Case filepacket, edits, decision
- Triage classifies the alert type and checks for duplicates and known patterns. A small, cheap model is enough.
- Workers run in parallel, each with a narrow objective and its own context. Anthropic's multi-agent work found that vague delegation caused duplicated effort, so each worker gets an objective, an output format, the tools it may use, and a boundary.
- Tools are read-only. The customer system, the transaction warehouse, and the case system are queried through a small set of consolidated tools that return names and summaries, not raw tables. Writes go through a separate path that requires a person.
- Every claim cites a record. The packet states that a customer received a series of transfers and links the transaction IDs. The Citations feature handles source-linked answers over documents. For database facts, the tool returns the record ID and the packet carries it forward.
- Calculations run in code. Totals, velocity, and date arithmetic are computed by tools, not estimated by the model.
- A checker reads the packet against the underlying records and flags unsupported statements before the analyst sees it.
What the model does not do
It does not close an alert, decide that activity is suspicious, or file anything. Those are the analyst's. A useful early choice is to ship evidence-only first, with no recommended disposition. A system that tells a tired analyst "likely benign" invites rubber-stamping. Add a recommendation later, only if the evaluation shows it improves outcomes and the analyst's own reasoning still gets recorded.
How to evaluate it
Replay a set of closed alerts with known outcomes. Measure three things, each with its own grader:
- Evidence recall. Did the packet contain the facts the analyst actually relied on? Grade this with code against the analyst's recorded notes, and a person on disputes.
- Citation accuracy. Does each cited record support the sentence it is attached to? A model judge works here, with spot checks.
- Time to decision and rework. Compare against the current process, per alert type.
Report these by alert type. An average hides the types where the system is weak, and those are where to keep the analyst's manual path.
Controls your reviewers will ask about
- Model risk management. At a US bank, supervisory guidance on model risk (SR 11-7) will apply to this system in practice. Bring the model risk function in early, with the evaluation plan.
- Data location. Run it in the cloud account where the data already lives. The same Claude models are offered through Amazon Bedrock, Google Cloud, and Microsoft Foundry, so you can keep processing inside your existing environment.
- Audit trail. Store the inputs, tool calls, outputs, and the analyst's edits for every alert. The log is how you answer the question "why did the packet say that" a year later.
- Autonomy limit. Cap steps per alert and tokens per alert. Anthropic's guidance on agents includes stopping conditions for the same reason.
Where to start
Pick one alert type with high volume and a clear investigation recipe. Build the evidence packet for it, measure it on a replay set, and run it beside the analysts before it replaces any step. The value is analyst time moved from gathering to deciding, plus a consistent record. Measure both, and report what you find.
This is a reference design. It describes how we would build the system and cites Anthropic's documentation for platform facts. It is not a client case study, and the figures it uses are list prices or worked examples, not results.
Have a process like this?
Bring it to a 45-minute working session.