AML Investigation AI Agents: From Alert Triage to the SAR Decision

Key takeaways

• In most AML teams, much of an investigation’s time goes to collecting evidence across systems before anyone judges it. That is the work an agent can do.
• AML investigation AI agents, as described here, assemble the evidence file, link related alerts and draft a narrative. They do not decide whether activity is suspicious and they do not file SARs.
• The investigator decides. The SAR decision stays human, and the record shows who made it and why.
• Agentic AI sits outside SR 26-2, so the bank designs the agent’s governance: what it may read, what it may do, and what gets recorded.
• Measure your own baseline before claiming any time saved.

An alert lands in the queue. Before an investigator can say anything useful about it, they open the core banking system for the transaction history, the onboarding file for KYC records, the screening tool for sanctions and PEP results, and the case system for prior alerts on the same customer. Then they look for related accounts and counterparties, and start writing.

Very little of that is judgment. It is collection. The judgment comes after, when the investigator reads it all and decides whether the activity is suspicious. That split is what makes an agent useful here, and it is also where the boundary sits.

What the rules already fix

Two things are not up for redesign.

First, the timeline. Under 31 CFR 1020.320, a bank generally files a SAR no later than 30 calendar days after initial detection of facts that may constitute a basis for filing. If no suspect is identified, the period can extend up to 60 days. Time spent gathering evidence comes out of that window.

Second, the decision. Your BSA/AML program defines who decides whether activity is suspicious and who approves a filing. The FFIEC BSA/AML Examination Manual describes how examiners look at monitoring, investigation and SAR decisions. An agent does not change who owns those decisions.

There is a third point that is new. SR 26-2, issued April 17, 2026, superseded SR 11-7 and placed generative and agentic AI outside its scope. Your transaction-monitoring models may still be assessed as models. An investigation agent working on their output is not covered by that guidance, so its governance is yours to design. We set out how that applies to banking workflows on our AML investigation workflow governance page.

Where the agent fits, step by step

Triage

When an alert arrives, the agent checks it against open cases and prior alerts on the same customer, accounts and counterparties. It proposes links: “this alert involves the same counterparty as two alerts closed last quarter.” The investigator accepts or rejects each link. Linking is a suggestion, not a merge.

Evidence assembly

For the alert, the agent pulls:

• The transaction history for the period your procedure defines, including the pattern that triggered the alert.
• KYC and customer due diligence records: stated business, expected activity, beneficial owners, risk rating.
• Sanctions and PEP screening results, including hits that were cleared and the reason recorded at the time.
• Prior alerts and their outcomes.
• Related accounts and counterparties, where your data allows it.

It lays these out in the order your investigators read them, with the source and retrieval time on each item.

Narrative draft

From the assembled file, the agent drafts a narrative: who, what, when, where, and how the activity compares with what the customer said they would do. The draft is marked as a draft. The investigator edits it, corrects it or throws it away.

The decision

The investigator decides whether the activity is suspicious. If the answer is yes, the filing goes through your normal approval path. If no, the reason for closing is recorded. Either way, the person who decided is named in the record.

In this design, “file SAR” and “close alert” are not actions the agent has. It prepares; people decide.

What the agent should not touch

A few lines are worth drawing in advance.

• No customer contact. The agent does not message the customer or reach out to anyone outside the bank.
• No account actions. It cannot freeze, restrict or close an account. Those decisions follow your own procedures, made by people.
• No reading beyond the case. It reads what the investigation needs, set by the use case approval. Broad access “in case it helps” makes the record harder to defend.
• SAR confidentiality. Drafts and case files that touch a SAR need the same confidentiality handling as the SAR itself. Your legal team should confirm where agent outputs are stored and who can see them.

The record that makes it defensible

An examiner reviewing a case wants to understand how the decision was reached. For an agent-assisted case, the record should connect:

1. The alert and the case identifier.
2. Every source the agent read, with retrieval times.
3. The links it proposed, and which the investigator accepted.
4. The narrative it drafted, and the investigator’s final version.
5. Any action the agent tried and was refused.
6. The investigator’s decision, their reasoning, and any approval above them.

That last item is the one that matters most. For more on building this kind of record, see our post on AI agent audit trails.

How the controls work in practice

These are the platform controls that make the boundary real rather than a line in a prompt.

Approval before anything runs. The investigation use case is registered with its data class and models, then goes through four gates in order (commercial, security, technical and tiering), each with its own owner. Restricted data is allowed only at the top tier.

Certification before production. The agent’s manifest maps its prompts, models, tools and skills at one commit. A person decides each certification gate. A certificate names exactly what would go to production, and only named production approvers can promote it.

Limited reach at run time. The agent’s key reaches only the models it was granted, set to the promoted version. Tool servers are reached through a gateway with per-server guardrails such as PII redaction, rate limits and human approval. If the agent is called by a user, its token is capped to that user’s rights, so it cannot see cases the investigator cannot.

A full record. Every model call is recorded with user, team, model, tokens, cost, latency and guardrail verdict, and every run and stop is kept per agent.

A stop button. Stopping the agent blocks its key and the gateway refuses every call. Who stopped it, when and why are recorded.

An illustrative case

The following is illustrative, not a measured result.

An alert fires on a small business account for a run of cash deposits just under the reporting threshold. The agent links it to an earlier alert on the same account that was closed with a note about seasonal sales. It pulls twelve months of transactions, the KYC file stating expected monthly cash volume, and a clean sanctions screening. It drafts a narrative noting that deposits now run well above the stated expected volume and outside the seasonal window in the earlier note.

The investigator reads it, checks two deposits against the branch records, and rewrites part of the narrative. They decide the activity is suspicious and send it for approval. The approver agrees and the SAR is filed by people, inside the window.

The record shows what the agent gathered, what the investigator changed, and who decided.

Questions to settle before launch

Bring your BSA officer, model risk, compliance and technology owners into one room and agree on the answers in writing:

• Which alert types first? Start with one, ideally high in volume, where evidence gathering takes most of the effort.
• Which sources may the agent read? List them by system and field, and tie each to the investigation step that needs it.
• Which models may it call, and where do they run? Keep customer data inside approved models and your own environment.
• Who reviews agent drafts, and how is quality checked? Use your existing quality review, and sample agent-assisted cases more heavily at first.
• What happens when the agent is wrong? Decide how investigators flag a bad link or a wrong fact, and who looks at those flags.
• Who can stop it? Name the person, and test the stop before go-live.

Written answers become part of the use case approval, and they are what you show a reviewer who asks how the agent was allowed to run.

What to measure first

Before you change the workflow, measure it. Useful baselines include:

• Time from alert to a complete evidence file.
• Time from complete file to decision.
• Share of alerts linked to prior alerts or open cases.
• Rework rate after quality review.

Then run the agent on one alert type and measure again. Until you have both numbers from your own queues, any improvement is a projection.

The point is not fewer investigators. It is investigators spending more of the window on judgment, with a record showing that the judgment was theirs. For how that record and the approval behind it are enforced, see the AI agent governance framework and the alert triage and investigation patterns it applies to in financial crime operations.

Frequently asked questions

Sources

About the author

Arya SharanProduct Marketing & GTM, Moring AIChennai

Owns product marketing and go-to-market at Moring AI across positioning, demand and enablement. Works with regulated buyers on how governed AI agents are scoped, evaluated and bought. Writes about the operating questions that decide whether an agent reaches production.

LinkedIn profile →