How level-1 AML alert triage works step by step, why rules-based monitoring floods analysts with false positives, and where an AI employee saves time.
Most of an AML analyst's day is spent on alerts that go nowhere. Each one still has to be opened, checked against the customer, and closed with a reason a reviewer can follow. This guide walks through level-1 (L1) alert triage step by step, explains why rules-based monitoring produces so many closed-no-action alerts, and shows where an AI employee takes on the repetitive work. It also states plainly what stays with your people: rule tuning and model risk, L2 investigations and SAR decisions.
Triage is a sorting step. It does not decide whether to file a suspicious activity report. That decision belongs to the investigation and the BSA officer, covered below.
Most banks run the same five steps, even where the tooling differs.
Where a SAR is later filed, the bank must keep a copy and the supporting documentation for five years from the filing date under 31 CFR 1020.320(d).
Rules-based monitoring fires when a transaction crosses a fixed condition, such as cash deposits above a threshold, a burst of wires, or a sudden change in volume. Rules are simple and easy to explain to examiners, but they see one condition at a time. They do not know that a customer's business is seasonal, that a large wire repeats every quarter, or that two accounts belong to the same legitimate group.
Three features of the setup drive volume:
We could not find a primary-source industry-wide false-positive rate to cite, and vendor and trade articles quote a range of unsourced numbers. We have left those out. The figure that matters is your own: the share of alerts your analysts close with no action, by scenario, over the last 12 months. Your model validation or MIS team can produce it, and it is the baseline for any improvement claim.
Your bank does, through its model governance. An AI employee that triages alerts does not change monitoring rules, thresholds or scenarios, and it should not.
US supervisors addressed this in an April 2021 interagency statement, which explained that some BSA/AML systems may be models while others, such as simple tools that flag transactions on a single factor, may not. On April 17, 2026 the agencies replaced that statement and SR 11-7 with revised model risk guidance (Federal Reserve SR 26-2, OCC Bulletin 2026-13). The new guidance places generative and agentic AI models outside its scope, so how an AI employee is classified and validated is a decision for your own model governance.
The same principle applies to the AI employee itself. Where it supports a BSA/AML process, your model risk team decides how it is classified, validated and monitored, and that includes sampling its dispositions against human reviewers.
The regulators have also said they will not penalize banks that choose not to use new technology, and that a pilot of an AI-based monitoring tool that finds activity the existing process missed does not mean the existing process is automatically deficient. That is in the December 2018 joint statement from the Federal Reserve, FDIC, FinCEN, NCUA and OCC. Management is still expected to evaluate when an innovative approach is ready to replace or augment an existing process, and to discuss that evaluation with its regulators.
The AI employee works on the triage steps, not on the detection rules. It takes alerts from the queue and does the legwork an L1 analyst does, under limits the bank defines.
Triage step | What the AI employee does | What stays with people |
|---|---|---|
Intake | Groups related alerts on the same customer and period; attaches scenario and trigger transactions | Defining which alert types it may handle |
Evidence gathering | Pulls transaction history from core banking and the KYC file, prior alerts and screening results into one case view | Access rights and data-source approval |
Profile comparison | Compares activity with stated business, expected volumes and the customer's own history; notes where it fits or does not | Judgment on ambiguous cases |
Disposition | Drafts a close-with-rationale or an escalation with evidence cited | Approving closures within agreed rules; QA sampling |
Escalation | Packages the case for L2 with a chronology | The investigation itself |
The time saved sits in steps two and three. Analysts routinely open four or five systems per alert and re-type the same context into a case note. An AI employee does that assembly in one pass and writes the rationale in the form your policy requires. Analysts then spend their time on the cases that need judgment, and reviewers read a consistent write-up instead of a different format from each analyst.
We do not publish a time-saved figure for this workflow, because the result depends on your alert mix, your data access and your closure rules. Measure it on a pilot against your own baseline.
See how AML workflows run end to end.
Your policy decides. Interagency FAQs issued in October 2025 say the BSA and its regulations do not require a bank to document a decision not to file a SAR, though FinCEN had previously encouraged it. The FAQs add that if a bank does document, the detail need not exceed what its own risk-based policies and controls require, and that in most cases a short, concise statement will likely suffice. More documentation may be appropriate in complex investigations. The text is in FinCEN's SAR FAQs (Question 4).
Most banks still record a rationale for every closure. It supports quality review and shows examiners how decisions were made. Writing that rationale is a good fit for an AI employee, because the structure is consistent and the evidence is already in the case view.
Three things stay with your team.
Past activity that was never reviewed is a separate problem, handled in a lookback review.
Triage is where the temptation to auto-close is strongest, so the AOP does the restraining. We would not hand the agent a closure power on day one. We would write down which alert types it handles, which closure reasons it may use, and what always goes to L2.
Start by sending most alerts to a person. In a biopharma procurement deployment, the agent sent 64% of requests to manual review in week one. That was the safety mechanism, not a failure. After every disagreement with a reviewer was folded back into its procedure, its decision rate rose from 36% to 85% and manual review fell to 15%. The same shape is the sane path here: a high review rate while the agent learns your scenarios, then a falling one as corrections accumulate. See the full case study. We have no AML alert numbers of our own to quote.
What the agent's identity cannot do. It reads monitoring alerts, core banking and the KYC file. It cannot edit rules, thresholds or scenarios, cannot decide a SAR, and cannot close outside the closure reasons its AOP lists.
What triggers Needs Attention. An alert type not in scope, a customer profile with no expected-activity data, activity that fits no prior pattern, or evidence in the core and KYC file that disagrees. These go to Needs Attention with the case view built.
What validate checks. Before a closure is proposed, the agent confirms the rationale names the customer pattern it relied on, cites the transactions, and matches a permitted closure reason. The rationale is written into your monitoring or case system, where your QA sampler already looks.
How tuning stays with you. Your QA reviewer disagrees with a closure, the correction becomes a branch of the AOP, evals run against a golden set of closures QA has already agreed with, a person reviews, and it merges. That is the self-learning loop applied to triage, and only the procedure changes, not the model, as explained in Inside Zamp's Self-Learning System. Alert data and customer files mostly push banks toward BYOC or on-premises.
Pick four measures and record them before the pilot starts:
Report these as actuals from your own data. Compare the AI employee's closures with human closures on the same alerts before you widen its scope, and have model risk review the results.
