Financial crime · Case narratives
Multi-workflowFinancial crimeSuspicious activity narratives start with evidence, not prose
A suspicious activity narrative is an argument built on facts. Get the facts in order first, and a model can help with the writing without ever deciding what gets reported.
Valnora & Elric team6 min read
Ask an investigator which part of a case takes longest and the answer is rarely the analysis. It is the write-up. A suspicious activity narrative has to tell a reader who has never seen the account what happened, in order, with amounts and dates that tie back to records. Then a second person checks it, and often sends it back.
It is tempting to hand that job to a language model. Done naively, it goes badly. Done in the right order, it removes most of the typing and none of the judgement. The difference is whether the model writes from evidence or from memory.
Why the obvious approach fails
The obvious approach is a prompt: here is the case, write the narrative. Three things go wrong.
- The model fills gaps. If the case data does not say where a counterparty is based, a fluent model may still produce a plausible country. In a report that goes to a financial intelligence unit, a confident wrong fact is worse than a missing one.
- Nobody can check it quickly. A reviewer reading free prose has to re-open every source system to confirm each number. That is the same work the draft was meant to save.
- It hides the judgement. The reason for suspicion is the part a regulator cares about most. A generic draft tends to state it vaguely, because the model was never told what your institution actually concluded.
None of these is a model problem. They are process problems. A narrative is only as good as the evidence assembled before anyone writes a word.
Separate evidence, drafting and review
The setup in Agent Serve uses three workflows built in the workflow builder, each with one job. They pass work along through Tables, so every step can be inspected on its own.
Three workflows from escalated case to reviewed narrative
Workflow 1 · Evidence pack
- 01Case escalatedA webhook from the case management system starts the run when an alert becomes an investigation.
- 02Pull case factsAPI and database blocks fetch parties, accounts, transactions in scope and prior alerts.
- 03Completeness rulesRules flag missing fields, such as a counterparty with no country or a date range with gaps.
- 04Evidence tableOne row per fact, each with its source system and record ID.
Workflow 2 · Narrative draft
- 05Narrative standardThe Knowledge Base holds your house style for narratives and the typology guides.
- 06Draft from the packAn Agent block writes who, what, when, where, why and how, citing evidence row IDs only.
- 07Check the draftAn Evaluator scores coverage; a Guardrails hallucination check looks for claims the pack does not support.
Workflow 3 · Investigator review
- 08Human reviewA Human block pauses the run until the investigator approves, edits or rejects the draft.
- 09Narrative registerFinal text, reviewer, decision and timestamps are written to a register table.
- 10Filing stays manualThe investigator files through your existing reporting channel. No workflow submits a report.
The evidence workflow runs when a case is escalated. It pulls the facts in scope and writes each one to an evidence table as its own row, with the source system and record ID. Completeness Rules flag gaps before drafting starts. If a required fact is missing, the case goes back to the investigator with a list, not forward to a draft.
The drafting workflow reads only that evidence table. An Agent block writes the narrative in the order FinCEN’s guidance and most house styles ask for: who, what, when, where, why and how. Every sentence that states a fact cites evidence row IDs. Your narrative standard sits in the Knowledge Base, so the draft follows your structure rather than a generic one.
The review workflow pauses at a Human block until a named investigator acts. They can approve, edit or reject the draft, and the final text, the reviewer and the decision are written to a narrative register table.
Make the draft prove itself
Before a draft reaches a person, the drafting workflow checks it twice. An Evaluator block scores it against your required elements: subject identified, period stated, amounts traceable, reason for suspicion stated plainly. A Guardrails block runs a hallucination check that looks for claims the source material does not support. A draft that fails either check is sent back for one more attempt, then flagged for the investigator with the failures listed.
What the solution produces
Draft narrative with evidence citations (illustrative)
MemoSubject: Personal current account, customer since 2019. Activity reviewed: 3 June to 28 June.
Who: The account holder and four counterparties, three of which first appear in this period [E-02, E-07].
What: 22 cash deposits at four branches, each below the branch reporting level, followed by transfers to one overseas beneficiary [E-11 to E-33].
When and where: Deposits on 14 separate days; transfers made through mobile banking within 48 hours of each deposit cluster [E-34].
Why it was escalated: Volume is roughly six times the declared monthly income and does not match the stated occupation [E-01, E-04].
Open point for the investigator: No information yet on the relationship with the overseas beneficiary.
Coverage check result (illustrative)
Checklist- Subject and accounts identified: pass
- Date range stated and matches evidence: pass
- Every amount traceable to an evidence row: pass
- Reason for suspicion stated in plain words: pass
- Unsupported claims found: none
The citations change how review feels. Instead of re-reading five systems, the investigator looks up the evidence row each sentence cites. The time goes on the part that needs a person: is the reason for suspicion right, and is it stated the way your institution wants it stated.
The “open point” line in the example matters too. The drafting prompt tells the model to list what the evidence does not establish rather than guess. Gaps become questions for the investigator, not invented facts.
Keep the decision where it belongs
Whether to file is not a drafting question. In most regimes, including those built on the FATF Recommendations, the decision to report sits with the institution and its nominated officer. The design reflects that in three ways.
- No workflow files anything. The register holds approved text; the investigator submits it through your existing channel.
- Nothing reaches the customer. No step sends a message outside the team, which keeps tipping-off risk out of the design.
- Every run leaves a trace. Logs record each block’s inputs and outputs, so you can show exactly which evidence a draft was built from and which version of the workflow built it.
Personal data stays under control as well. A Guardrails PII detection step can mask identifiers before text reaches a model, and if case data cannot leave your environment, Agent Serve can run self-hosted with your own model keys.
Controls and governance
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
Self-hosting
Run Agent Serve in your own cloud or data centre, next to the systems it reads.
Bring your own keys
Use your organisation’s own model provider keys at organisation or workspace level.
More on how Agent Serve handles access, data and audit on the security page.
What changes for the team
The first change is consistency. Every draft has the same structure, so quality checkers compare like with like and second-line reviewers stop sending narratives back for missing dates.
The second is a better signal about the cases themselves. When investigators edit drafts, the edits show where the evidence workflow is thin. If reviewers keep adding the same fact by hand, add it to the evidence pack. If the Evaluator keeps failing on the reason for suspicion, the problem is usually that the case notes never stated one.
The third is time. For example, a team might find that a narrative which took an afternoon to write now takes under an hour to review. Treat any figure like that as something to measure in your own pilot, not a promise.
Where to start
Start with one typology that produces many similar cases, such as structured cash deposits. Build the evidence workflow first and run it on closed cases, comparing its packs with what investigators actually used. Only then add drafting, and keep every draft in review for as long as your MLRO wants. If you already triage alerts with agents, the AML alert triage setup feeds this one directly: its case notes become part of the evidence.
What you need
- An event or export from your case management system when a case is escalated
- Read access to party, account and transaction data for the case period
- Your narrative writing standard and typology guides, uploaded to a Knowledge Base
- A short list of required facts, written as completeness rules
- Named investigators to review every draft, with a backup reviewer
- Agreement from your MLRO or equivalent on what the drafts may and may not contain