AI agent · Compliance & risk · Sort & route
AML alert triage
The software gathers what an analyst needs for each monitoring alert, groups alerts on linked parties, drafts a rationale that cites its sources and routes each case by risk. Analysts decide; reporting to the authorities stays entirely with people.
Typical volumes for this process, not a client figure.
Alerts wait in a queue; analysts rebuild the same customer picture for each one.
Each alert assembled with its context; explained ones proposed for closure, the rest ranked by risk.
Where the time goes today
Transaction monitoring produces alerts from scenarios: cash deposits above a level, money moving in and out quickly, transfers to higher-risk locations, amounts kept just under a reporting threshold. Many alerts turn out to have an ordinary explanation, but each needs a documented review. The analyst opens the alert, then the customer's profile and expected activity, the risk rating, the transaction history, previous alerts and their outcomes, screening results and the counterparties involved. That is often five or six systems.
Much of the time goes on assembling that picture, not on the decision. The same customer triggers the same scenario every month, and each time someone rebuilds the context and writes the rationale from scratch. Rationales vary from analyst to analyst, and some would not survive a quality review. The queue ages, and senior investigators spend part of their day on alerts that a junior analyst could have closed with the right facts in front of them.
Other errors come from fragmentation. Alerts on two accounts held by the same person, or by members of one household, land with different analysts. Each looks explainable on its own; the pattern only shows when they are read together.
How the agent works
- Assemble the contextFor each alert the agent pulls the customer profile, expected activity, risk rating, transactions over the look-back period your procedure sets, prior alerts and outcomes, screening results and linked parties. It lays them out in the order your procedure reviews them.
- Group related alertsAlerts on the same customer, the same household or linked parties are merged into one case, so they are reviewed together by one analyst.
- Test the explanationThe triggering activity is compared with the customer's expected activity and history: the same employer paying the same amount monthly, a documented seasonal business pattern. Each fact that supports or contradicts an explanation is recorded with its source.
- Assign a laneWhere documented facts explain the activity and no risk indicator is present, the agent proposes closure with a drafted rationale. Anything unexplained, or carrying an indicator on your list, goes to the investigator queue ranked by risk.
- Write the recordThe rationale cites each fact and where it came from, so a quality reviewer or an examiner can follow it without repeating the research.
What stays with a person
Every disposition is a person's decision unless your policy, agreed with your compliance function, explicitly allows rule-based closure for a defined scenario. The decision to file a suspicious activity report, and what it says, always stays with a person, whatever your jurisdiction calls that report. So do decisions to exit a customer or restrict an account.
The agent never contacts the customer. A request for information from the customer is a judgement about tipping-off risk and belongs to an investigator. Changes to the monitoring scenarios themselves are a matter for your model governance, not something the agent adjusts to reduce its own workload.
What it reads, what it produces
| It reads | It produces |
|---|---|
| Transaction monitoring alerts and scenario details | A case file per alert or group, with the context assembled |
| The customer profile and expected activity | A drafted rationale citing each source |
| Core banking transactions over the look-back period | A lane assignment with the reason |
| Prior alerts, cases and their outcomes | An investigator queue ranked by risk |
| Sanctions, politically exposed person and adverse media screening results | A sample list for quality assurance |
| Linked accounts and related parties |
Controls that come with it
- The agent does not file reports, contact customers or restrict accounts.
- Closure proposals need an analyst's confirmation unless your policy allows rule-based closure for that scenario, in which case a sample is reviewed.
- Any indicator on your forced-escalation list sends the case to an investigator, whatever else the data shows.
- Each case records what was retrieved, when, from which system, and who confirmed the outcome.
- A reference set of past alerts with known outcomes is re-run on every change to the agent or the procedure.
How you know it works
- Alert age at disposition, against the deadline in your procedure
- Quality assurance failures on closed alerts
- Share of escalated cases that investigators pursue
- Analyst time per alert
- Consistency of rationales across analysts, as scored in quality review
Is your process ready?
- Written rules: an alert-handling procedure with documented disposition reasons per scenario.
- Systems: monitoring, customer and transaction data are available through interfaces or a data warehouse, and your licences permit automated read access.
- Cheap check: a quality reviewer can verify a rationale against its cited sources in minutes.
- Volume: hundreds of alerts a day, each handled by a person repeating the same research.
- Same description: analysts and quality reviewers agree on what 'explained' means for each scenario.
The five candidacy checks are explained, with an exam, in the free Module 01.
What goes wrong
- Expected activity in customer profiles is blank or years old, so nothing can be compared and everything escalates.
- Drafted rationales become boilerplate that reviewers approve without reading.
- Customer data that may not leave a given location; the agent must run where the data is allowed to be.
- Incomplete linked-party data, so the grouping misses the pattern it was meant to find.
Questions we get
Will our regulator accept this?
That is a question for your compliance function and your regulator, and it should be asked before go-live, not after. What the agent gives you to show them: the written rule behind each lane, results on a reference set of past alerts, the quality assurance sample, and a record for every alert of what was read, which rule applied and who made the decision.
Does the agent file suspicious activity reports?
No. It can assemble the facts an investigator needs to write one, with sources cited, which saves time on the drafting. The decision to report, the wording of the report and its submission remain with the people your procedure names. The agent also records nothing in customer-facing systems that could reveal an investigation.
How do you know it is not closing alerts it should escalate?
Three ways. Before go-live, it is run on past alerts whose outcomes are known, including ones that led to reports, and every miss is examined. In production, quality assurance samples proposed and confirmed closures. And a list of risk indicators, set by you, forces escalation regardless of any explanation the data offers.
Can it tune our monitoring scenarios?
No. It can show which scenarios generate alerts that are routinely explained by the same facts, which is useful evidence for a tuning review. Changing thresholds or scenarios is a governed decision with its own testing and approval, and it should stay separate from the software that handles the alerts those scenarios produce.
Want this agent on your process?
Tell us about your version of this process — volumes, systems, what goes wrong. A person answers with an approach and a price, usually within two working days, or tells you it is the wrong project.