A good alert summary answers one question: does this activity fit what we know about the customer? Let the agent read the alert, the triggering transactions, the customer profile and recent history, and draft a summary that sets the activity against the profile. Analysts accept or edit it and decide the alert. The agent cannot close anything.
What is an alert summary for, and who owns it?
Analysts reviewing transaction monitoring alerts spend much of their time assembling context: opening the customer file, scrolling through months of transactions, checking prior alerts, reading notes. Only then can they judge. A summary that does the assembly well lets the analyst spend their time on the judgement. A summary that does it badly, or leans towards a conclusion, is worse than none.
The monitoring lead owns the standard for alert narratives; analysts own each disposition. The connection to the system, including the data scope and what the agent cannot do, is covered in connecting an agent to your transaction monitoring system.
Which permissions does the agent need, and at what depth?
- Person, monitoring lead: sets the summary standard. What every summary must contain, how long it may be, and what it must never say.
- Agent, depth 1: reads the alert. The rule or scenario that fired, the transactions that triggered it, and the threshold crossed.
- Agent, depth 1: reads the customer's profile and history. Expected activity, occupation or business type, risk rating, prior alerts and their outcomes, a set look-back of transactions.
- Agent, depth 1: reads linked parties within its scope: counterparties, linked accounts, related customers.
- Agent, depth 2: writes the summary as a labelled draft. What happened, how it compares with expected and past activity, possible legitimate explanations visible in the data, indicators of concern, and what is not known.
- Agent, depth 2: proposes escalation where indicators meet criteria in the standard. Held for the analyst.
- Person, analyst: reviews, edits and decides the alert.
- Person, QA: samples dispositions where the agent's summary was used.
| Capability | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read alert | Reads rule and triggering activity | 1 | None |
| Read profile and history | Reads within look-back | 1 | Extending the look-back |
| Read linked parties | Reads within scope | 1 | Setting the scope |
| Summarise | Writes labelled draft | 2 | Accepting or editing |
| Propose escalation | Flags with reasons, held | 2 | Escalating or closing |
| Close | Nothing | None | Analyst |
What is recorded, and which controls apply?
Drafts labelled until accepted. The alert history shows the agent's text, the analyst's edits and the final narrative. Evidence: a supervisor can see whose reasoning closed the alert.
Balanced by design. The standard requires both possible explanations and indicators of concern. A summary that only argues one way fails the standard. Evidence: QA sampling against the standard.
No disposition capability. Whether an agent can close AML alerts is a question worth asking for each alert type in time; the connection described here does not allow it. Evidence: the connector's capability list.
Reads tied to the alert. Every data access references the alert being summarised. Evidence: the read log.
Facts sourced. Every figure in the summary links to the transaction or record it comes from. Evidence: an analyst can click through to check.
What should you measure?
- Summaries accepted unedited, lightly edited or rewritten. Unedited acceptance above a certain level should prompt QA to look closer, not celebrate.
- Analyst time per alert.
- Escalations by analysts that the summary did not suggest, the most important error direction.
- Factual errors found in summaries, especially amounts and dates.
- QA findings on alerts summarised by the agent compared with others.
Where does it usually go wrong?
Summaries that conclude. "This activity appears consistent with the customer's business" is a conclusion. The analyst should reach it. The summary should say what the business is, what the activity was, and how they compare.
Prior alerts used as clearance. "Similar activity was closed as not suspicious last quarter" is context, not a reason. Repeated similar alerts may themselves be the concern.
Profiles out of date. The summary compares activity with a profile set at onboarding years ago. The agent should say when the profile was last updated.
Look-back too short or too long. Too short hides patterns; too long buries the analyst. The standard should set a default and let analysts extend it.
Summaries hiding rule problems. If many alerts from one rule are explained the same way, the rule may need tuning. Feed that pattern into reviewing rule performance rather than summarising the same false positive forever.
Customer explanations given equal weight to records. A note on file saying the customer expected a large inheritance is the customer's word; the ledger entries are records. The summary should show which is which, so the analyst knows how much of the picture is evidenced and how much is assertion.
The boundary for the whole activity is discussed in whether an AI agent can do transaction monitoring, and the overall stance in AI compliance agents.
Where Pryme fits
In Pryme, the summarising agent reads ledger transactions as sealed facts and customer statements as declared, and the summary keeps that distinction visible. Writing the draft is a depth 2 capability; closing an alert is outside the agent's role scope, so an attempt is refused and the verdict filed.
Questions people ask
How long should a summary be?
Short enough to read in under a minute: a few sentences on the activity, a few on the profile, the explanations and indicators as short lists. Detail stays one click away in the evidence.
Should the agent summarise every alert or only some?
Start with the alert types where the context is hardest to assemble, certify the agent on those, and extend from there. A summary nobody needs is just more to read.
Can the agent group related alerts?
Yes, it can propose that alerts on linked accounts or the same pattern be reviewed together. Grouping changes how the alerts are decided, so the analyst confirms it.