Separate three things before you connect anything: the alerts, the transaction data behind them, and the rules that generate them. Give the agent read access to the first two and a draft right for alert narratives. Keep closure and rule changes with people, and run the agent under its own revocable, logged identity.
What kind of system is this, and who owns the connection?
A transaction monitoring system applies rules or models to account activity and raises alerts when activity matches a pattern of concern: rapid movement of funds, structuring below thresholds, unexpected counterparties, activity out of line with the customer's profile. Analysts review the alerts, close them with a reason or escalate them to an investigation. What transaction monitoring is covers the basics.
The financial crime function owns the system's rules and outcomes, usually through a transaction monitoring lead accountable to the MLRO. A technology team runs it. Data protection has an interest, because the agent will read customer transactions at scale. All three approve the connection.
What are the steps, capability by capability?
- Person, system owner: creates the agent's own identity, distinct from analysts and from batch processes.
- Person, monitoring lead: defines the capabilities as separate scopes. Read alerts. Read transactions and customer profile for the alerted account. Read linked accounts. Write a draft narrative on an alert. Propose escalation. Read rule definitions. Run rule analysis in a test copy.
- Person, monitoring lead: sets depth. Reads at depth 1. Narratives and proposed escalations at depth 2. Closing alerts, opening investigations directly and any change to production rules: outside the agent's role.
- Person, data protection: bounds the data. The alerted account, its linked accounts and a defined look-back period. Not the whole customer base on request.
- Agent, depth 1: runs on closed alerts in a test copy. Its narratives are compared with analysts' decisions before it sees live alerts.
- Person, monitoring lead: approves go-live and sets the sampling plan.
- Person, system owner: tests revocation and adds the identity to periodic access reviews.
| Capability | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read alert and transactions | Reads within the alerted scope | 1 | Setting look-back and links |
| Draft narrative | Summarises the activity and the pattern | 2 | Accepting into the record |
| Propose escalation | Flags with reasons | 2 | Escalating or closing |
| Close alert | Nothing | None | Analyst |
| Read rule definitions | Explains why an alert fired | 1 | None |
| Rule analysis | Runs in a test copy only | 1 | Any production change |
Which controls apply, and what is recorded?
Scope tied to the alert. The agent reads data because an alert gives it a reason to. A request for transactions on an account with no alert is refused. Evidence: each read in the log references an alert.
No closure capability. Closing an alert is a judgement that the activity is explained, and it is the decision supervisors test most. Whether an agent may ever take it is discussed in whether an AI agent can do transaction monitoring; at connection time, the capability is simply not exposed.
Production rules untouchable. Rule changes go through the firm's change control, with testing and sign-off. The agent may analyse rules and propose changes using a test copy, as in reviewing rule performance. Evidence: the agent's identity has no write rights to production configuration.
Narratives marked as drafts. Agent text is labelled until an analyst accepts it. Evidence: the alert history shows which text the agent wrote and who accepted it.
Revocation and logs. One switch disables the agent. Every call is logged with the alert it relates to.
What should you measure?
- Draft narratives accepted unedited, edited or rejected.
- Escalations the agent proposed that analysts rejected, and the reverse. Analysts escalating alerts the agent did not flag is the more important direction.
- Analyst time per alert.
- Out-of-scope reads attempted.
- Backlog age, which is usually the reason the connection was wanted.
Where does it usually go wrong?
Unbounded look-back. The agent reads years of history for every alert. It is slow, costly and harder to justify under data minimisation. Set a default and let analysts extend it case by case.
Narratives that restate the alert. A useful narrative explains the activity against the customer's profile and what would explain it. A narrative that just lists transactions saves no time. Test for this before go-live.
Model-based alerts treated like rule-based ones. Where alerts come from a statistical model rather than a written rule, the agent cannot explain why the alert fired by reading a rule definition. It should say so, and describe only what the activity shows, rather than inventing a reason the model never used.
Batch accounts reused. Connecting the agent through the system's batch account is quick and destroys attribution. Insist on a separate identity.
Confusing two kinds of monitoring. Transaction monitoring is distinct from the compliance function's own testing of controls. The agent connected here should not be the same agent that tests whether monitoring works; see what compliance monitoring is for the distinction.
The day-to-day work after connection is covered in letting an agent summarise alerts. The broader position is in AI compliance agents.
Where Pryme fits
In Pryme, transaction data reaches the agent from the core ledger as sealed facts, while notes from the customer remain declared, so a narrative can show which statements are backed by records. Closing an alert is not in the agent's role scope; an attempt is refused, and the verdict names role scope as the bound that decided.
Questions people ask
Can the agent read data from outside the monitoring system?
Only through separate, approved connections, such as the customer file or the case management system. Each is scoped and logged on its own.
Should one agent handle all alert types?
Start with one well-understood alert type and certify the agent on it. Different rules produce different patterns, and an agent that is reliable on one may not be on another.
What happens to the agent's drafts if it is disconnected?
They remain in the alert history as drafts, labelled with their author. Analysts continue the work without them.