AML · Alert triage
MixedRetail and commercial bankingAML alert triage that keeps the analyst in charge
Most of an AML analyst’s day goes on collecting context, not judging it. Here is a triage setup where a workflow gathers the evidence, a Relay drafts the case and the analyst makes the call.
Valnora & Elric team5 min read
- WorkflowsThe visual builder: blocks, models and integrations wired into agent logic.
- RelaysAI coworkers with a role, a schedule and approvals before external actions.
- TablesA database, built in, for cases, queues and decisions.
- RulesPlain-language checks that pass, fail or flag a record.
- DashboardsCharts, tables and KPI tiles over governed metrics.
- MonitorsWatch a metric and alert the right people when it moves.
- Knowledge BasePolicies and procedures agents search before they answer.
Transaction monitoring systems are good at raising alerts and poor at explaining them. An analyst who opens an alert usually spends the first half hour in five other systems: the customer profile, the account history, previous alerts, the onboarding file and the procedure manual. Only then does the actual judgement start.
That split is where AI agents help. Gathering and laying out context is repetitive, rule-bound and easy to check. Deciding whether activity is suspicious is not, and in most regimes it is a judgement your institution has to own. This post shows a triage setup in Agent Serve that takes the first job and leaves the second one with the analyst.
What the setup does and does not do
The goal is a better first draft, not an automated decision. Every alert still gets a disposition from a named analyst. What changes is what that analyst sees when they open it.
- It does collect the customer, account and transaction context for every alert, run the screening rules your policy names, and draft a case summary with a suggested next step.
- It does keep the backlog visible on one dashboard and alert team leads when items age past your limits.
- It does not close, escalate or file anything on its own. The Relay drafts; people decide.
- It does not contact the customer. Tipping-off rules make that a hard line, and the Relay’s instructions say so explicitly.
How the parts fit
From monitoring alert to analyst decision
Workflow · Alert intake
- 01New alertA webhook or schedule picks up alerts from the monitoring system.
- 02Gather contextAPI and database blocks pull the customer profile, accounts and recent activity.
- 03Screening rulesRules flag patterns your policy names, such as rapid in-and-out movement.
- 04Alert queueOne row per alert with context, rule results and status.
Relay · AML case drafter
- 05Watch the queueThe Relay watches the alert table for rows marked ready.
- 06Check proceduresIt searches the AML procedures in the Knowledge Base for the matching typology.
- 07Draft case summaryA case note with evidence, open questions and a suggested next step.
- 08Analyst decidesThe analyst closes, escalates or asks for more. The Relay never closes an alert.
Dashboard · Backlog and quality
- 09Backlog dashboardAgeing, volume by scenario and disposition mix per team.
- 10Ageing monitorAlerts when items pass the age your procedures allow.
The solution uses three pieces that hand work to each other through a table.
The intake workflow runs on a webhook from your monitoring system, or on a schedule if your system only exports files. It is built in the workflow builder from ordinary blocks: an API or database block for each source, a Rules step for the screening checks, and a Table block that writes one row per alert. Because it is a workflow, every run is traced block by block in Logs, so you can show exactly which data an alert was enriched with.
The case drafter is a Relay, an AI coworker with its own instructions and access. It watches the alert table for rows the workflow has marked ready, searches your AML procedures in the Knowledge Base for the matching typology, and sends a case summary to the assigned analyst as a task result. Set it to the Assist autonomy level: it reads and drafts freely, while saving files, sending email and booking meetings each wait for an approval.
The backlog dashboard sits on the same table. Monitors watch two numbers: alerts older than your ageing limit, and the share of alerts waiting on a draft. When either crosses its threshold, the team lead gets an alert in the app or by email.
What the analyst sees
What the solution produces
Draft case summary (illustrative)
Record- Alert
- Rapid movement of funds · personal current account
- What happened
- 14 inbound transfers from 9 new payers over 6 days, each moved out within 24 hours to one external account.
- Profile check
- Declared income and expected activity at onboarding do not cover this volume.
- Prior alerts
- One closed alert 11 months ago, different scenario, no escalation.
- Procedure reference
- Money mule typology, section 4.2 of the internal AML procedures.
- Suggested next step
- Escalate to investigation. Open questions listed for the investigator.
The draft is structured the same way every time, which matters more than it sounds. Reviewers can scan for the field they care about, quality checkers can compare cases side by side, and the evidence the draft relied on is listed rather than implied.
The analyst then does one of three things: accepts the suggested step, overrides it with a reason, or asks for more information. Overrides are the most useful signal in the system. A weekly review of them tells you which typologies the procedures describe poorly and which rules fire too often.
Watching the backlog
AML alert backlog
The dashboard answers the questions a financial crime lead asks on Monday morning: how many alerts are open, how old they are, how many became investigations, and whether the team is closing more than it opens. Row-level access policies can limit each team lead to their own queue while the head of financial crime sees all of it.
How to measure it
35 → 12 min
Handling time per alert
Context gathering moves to the workflow.
100%
Alerts with a written rationale
Every decision has a case note behind it.
−40%
Alerts older than 30 days
The monitor surfaces ageing items early.
Illustrative example. Figures show how the workflow is measured; they are not customer results.
What the change could be worth
A financial crime operations team triaging 3,000 transaction monitoring alerts a month.
| Assumption | Value |
|---|---|
| Alerts triaged per month | 3,000 alerts / month |
| Analyst minutes per alert today | 35 min |
| Analyst minutes per alert with a drafted case | 12 min |
| Share of alerts where analysts work from the draft | 70% |
| Loaded cost of an analyst hour | 55 USD |
- faster first review per drafted alert: Analyst minutes per alert today ÷ Analyst minutes per alert with a drafted case
- analyst hours freed a month: Alerts triaged per month × Share of alerts where analysts work from the draft × (Analyst minutes per alert today − Analyst minutes per alert with a drafted case) ÷ 60
- analyst time redirected a year: Alerts triaged per month × Share of alerts where analysts work from the draft × (Analyst minutes per alert today − Analyst minutes per alert with a drafted case) ÷ 60 × Loaded cost of an analyst hour × 12
Modelled from the assumptions above to show how the outcome is calculated; not a customer result. Your results depend on your volumes and process.
Controls a second line will ask about
Controls and governance
Approvals before action
Relays never send email or book meetings without an approval, under any autonomy setting. An approval covers the exact payload the reviewer saw and expires if nobody decides.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
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.
Zero data retention
Zero data retention with supported model providers, backed by your own provider keys and agreements or self-hosted models. Some provider features keep data by design, such as Gemini Deep Research, so they are outside zero data retention.
SOC 2 ready
The controls SOC 2 looks for are in place. Agent Serve does not claim a SOC 2 report or certification.
More on how Agent Serve handles access, data and audit on the security page.
Two design choices carry most of the weight. First, the Relay can draft but not decide, and anything that would leave the workspace, such as an email asking a relationship manager for context, waits for an approval tied to the exact message the reviewer saw. Second, every step leaves a record: workflow runs in Logs, Relay proposals and approvals in the audit log, and the final disposition in the alert table with the analyst’s name against it.
If customer data cannot leave your environment, run Agent Serve self-hosted next to your monitoring system, and use your own model keys or a self-hosted model.
Where to start
Pick one alert scenario with high volume and a clear procedure. Build the intake workflow for that scenario only, run it alongside your current process for two weeks, and compare the drafts with what analysts actually decided. Expand to the next scenario once the drafts are reliably useful.
What you need
- A feed or export of alerts from your transaction monitoring system
- Read access to customer, account and transaction data through an API or database
- Your AML procedures and typology guides, uploaded to a Knowledge Base
- A short list of screening rules your policy already names
- Named analysts and a team lead to own dispositions and approvals
- Agreed ageing limits for the backlog monitor