AI can help an AML investigator assemble records, trace activity, and prepare a case summary. It must not turn an incomplete set of retrieved records into an apparently complete conclusion.
That distinction matters as AI-assisted investigation products move into U.S. bank workflows. In October 2026, Amalgamated Bank said the FIS AML Investigations Agent was commercially available to U.S. banks and described investigator accountability for the final determination. The announcement is useful evidence of a live deployment direction, not independent proof of a time-saving or detection-quality claim.
This guide is for a post-alert review workflow: an alert already exists, a human investigator owns the case, and an AI system may gather permitted information or draft a summary. It offers an Evidence-Completeness Review Bundle: a compact case-file artefact that makes sources, gaps, conflicts, and reviewer decisions visible before a narrative is used downstream.
It is not legal advice, a BSA/AML program, a SAR-filing procedure, or a recommendation to close, escalate, or file any case. Keep SAR decisions and filings with authorized personnel under your institution’s approved process.
The search intent: investigate one alert, not automate the decision
Searches for an AI AML investigation agent often lead to product claims about faster alert handling. The operational question is more specific: can a reviewer tell what evidence the agent saw, what it did not see, and where the summary conflicts with the record?
FinCEN’s SAR narrative guidance emphasizes complete and sufficient narratives. Its common-error guidance says that a narrative should accurately explain the nature and circumstances of activity, rather than merely restating form fields. That makes completeness a review problem, not a model-confidence score.
This is distinct from Know Your Agent (KYA), which establishes who an agent is and what it is allowed to do. It is also distinct from a general finance AI control checklist. Here, the unit of control is one post-alert investigation case and its evidence trail.
Build the bundle before accepting a drafted narrative
Treat every AI-produced sentence as a claim with a reviewable relationship to source evidence. A bundle can begin as a case-management form, a controlled spreadsheet, or a versioned record in an internal tool. The storage choice matters less than keeping these fields linked.
1. Case and scope record
Capture the alert or case ID, case owner, review date, alert type, and the approved purpose of the AI assist. Record the systems searched, the query parameters, the requested time range, and any exclusions. If a system was unavailable, a consent boundary prevented access, or the agent did not search a source, record that fact explicitly.
Do not label a case “complete” because all connected systems returned a response. A completed query is not proof that the relevant records were in scope.
2. Claim-to-source matrix
For each factual statement intended for the summary, create one row:
| Field | What to record |
|---|---|
| Claim ID | A stable identifier, such as C-014 |
| Proposed statement | The precise fact or bounded observation |
| Source locator | System, record ID, field or page, and permitted deep link |
| Retrieval details | Query, time range, retrieval timestamp, and access status |
| Evidence type | Direct record, calculated result, analyst note, or model inference |
| Support status | Supported, partially supported, unsupported, or conflicting |
| Reviewer action | Accept, revise, investigate further, or exclude |
The key separation is between a fact in a source and an inference drawn from it. A model can summarize an approved record; it should not silently convert a pattern into an assertion of intent. If it proposes an interpretation, mark it as an interpretation and require a human decision.
3. Contradiction and missing-data register
Evidence bundles fail when they only preserve confirmations. Add a record for each material conflict or blind spot:
- an expected account, customer, counterparty, or time period was absent from the search;
- two permitted records describe the same event differently;
- a transaction detail is present but the expected customer context is not;
- the agent used an outdated or unverified reference;
- an input could not be retrieved, parsed, or attributed.
Give each item an owner and a disposition state: open, resolved with source, not obtainable, or outside approved scope. None of those states is a suspicious-activity conclusion. They are review facts that prevent a polished narrative from hiding uncertainty.
4. Human decision boundary and run record
Retain the reviewer identity, the exact version of the draft reviewed, the action they took, and why. Separately preserve the model or workflow version, prompt template version, permitted tools, and run timestamp. The aim is reconstruction: a later reviewer should be able to distinguish the records the system retrieved from the words it generated.
For system-level safeguards, pair this case bundle with an AI red-teaming test harness for banking agents. Red-team tests establish whether a workflow behaves safely; the evidence bundle establishes what happened in one real case.
A bounded prompt for evidence-completeness review
Use a prompt only after your access controls, retention policy, and case-management procedure allow the data to be processed. Do not place customer or SAR-related information in a public model or an unapproved environment.
Role: You are an evidence-completeness reviewer for one AML investigation case.
Allowed task: Review only the supplied case records and the claim-to-source matrix.
Do not make a disposition recommendation, assess criminal intent, recommend a SAR filing,
or add facts not present in the supplied material.
For each proposed claim:
1. classify it as supported, partially supported, unsupported, or conflicting;
2. list the exact source locator(s) and retrieval time range that support the classification;
3. separate source facts from interpretations;
4. identify missing expected sources, periods, or context;
5. identify conflicting records without deciding which is correct.
Return JSON only:
{
"claims": [{"claim_id":"", "status":"", "source_locators":[],
"facts":[], "interpretations":[], "gaps":[], "conflicts":[]}],
"case_level_gaps": [],
"requires_human_review": true
}The prompt’s most important output is often a gap, not a summary. A correct requires_human_review: true is safer than a fabricated sense of closure.
Test the bundle with three failure cases
Run these tests with synthetic or properly authorized test data before connecting the workflow to production cases.
Missing-period test
Provide an alert period that spans 90 days, but supply retrieved transactions for only 30 days. The reviewer should identify the missing interval and must not describe the activity as a complete history.
Conflicting-identity test
Provide two records with similar names but different account identifiers. The reviewer should preserve both records as a conflict; it must not merge the parties or infer a relationship.
Unsupported-narrative test
Add a draft sentence that asserts a motive while the supplied sources show only transaction facts. The reviewer should classify the statement as unsupported or interpretation, retain the source facts, and request human review.
Fail the test if the system produces a disposition, recommends filing, invents a source locator, or silently resolves a conflict. These failures are quality defects, not optional caveats.
Measure review quality, not promised speed
Vendor or institution announcements can describe efficiency ambitions, but a local control should measure what the reviewer can verify. Start with a small, sampled KPI set:
- Claim traceability rate: accepted factual claims with a usable source locator divided by accepted factual claims.
- Open-gap visibility: material gaps shown in the bundle before review completion divided by gaps later discovered in quality review.
- Conflict preservation rate: seeded conflicting records retained as conflicts during the test set.
- Unsupported-claim catch rate: seeded unsupported statements flagged by the workflow or reviewer.
- Reconstruction success: sampled cases for which an authorized reviewer can reproduce the source scope, draft version, and human action.
Do not use these metrics to infer compliance, detection performance, or filing quality. They are workflow-quality signals and should be interpreted by the responsible compliance, risk, and legal teams.
Keep the case file useful without making it a decision engine
An AI AML investigation workflow is more defensible when it makes its uncertainty legible. Ask the system to organize evidence, preserve source boundaries, expose missing context, and flag contradictions. Ask a qualified human to evaluate the case and own the decision.
That boundary supports the current use case without turning a general-purpose model into an unaccountable investigator. It also creates a practical record for later quality review: not a claim that the AI was right, but evidence of what it was permitted to inspect, what it produced, and what a human did next.
Sources
- Amalgamated Bank: AI-powered financial crime investigations, October 15, 2026
- FinCEN: SAR Narrative Guidance Package
- FinCEN: Suggestions for Addressing Common Errors Noted in Suspicious Activity Reporting
- FFIEC BSA/AML Examination Manual: Suspicious Activity Reporting overview
About Enis
AI Engineer specializing in Machine Learning and LLMs. Combining Computer Engineering and Economics to build data-driven financial tools.