Yes, if the reasons were captured at the moment of the flag. An AI agent can state which rule fired, which values crossed it and which facts it weighed, and cite the records behind each. An explanation written afterwards is a reconstruction, not a reason. What the flag means, and what anyone tells the customer, stays with a person.
Who actually flagged the transaction?
Start with this question, because the answer changes what a good explanation looks like.
In most firms a transaction monitoring system raises the flag. A rule or model scored the activity and crossed a threshold. The agent's job is to read that flag and explain it in plain words: "Rule 14 fired because four cash deposits in seven days totalled more than the threshold for this customer segment." That explanation is reliable because the rule is deterministic and its inputs are logged.
In some firms the agent itself raises a flag during review, for example noticing that a counterparty appears in another case. Here the explanation is the agent's own reasoning, and it is only trustworthy if the agent recorded the facts it relied on at the time. Asking it a week later "why did you flag this?" invites a plausible answer that may not match what drove the original output.
What should the explanation contain?
A useful explanation has the same parts every time:
- The trigger: the rule, model score or observation that raised the flag.
- The values: the actual amounts, counts, dates and thresholds.
- The comparison: what was expected for this customer, from the profile and history.
- The facts weighed, each with the record it came from and how reliable that record is.
- What was checked and found nothing, such as no prior alerts or no adverse media.
- What would change the view: the information that would explain the activity innocently.
The last two items separate an explanation from a justification. An agent that only lists reasons for suspicion has written a case for the prosecution. A reviewer needs the reasons against too. If the agent is producing these summaries inside your monitoring system, how to let an AI agent summarise alerts in your transaction monitoring system covers the set-up.
Who uses the explanation, and what do they decide?
| Reader | Uses the explanation to | Decision they keep |
|---|---|---|
| Analyst | Decide quickly whether the alert is explained | Close or escalate |
| Investigator | Pick up the case without re-gathering evidence | Whether there is suspicion |
| Reporting officer | See the grounds behind an escalation | Whether to report |
| Auditor or supervisor | Test whether flags and closures were sound | Their finding |
| Customer | Usually does not see it | Not applicable |
The customer is the hard case. A customer whose payment was held will ask why. Where the hold relates to suspected money laundering, telling them the reason can tip them off, so the explanation stays internal. What the customer hears is decided by a person, using approved wording. For decisions where the customer is owed reasons, such as a declined application, see how do you explain an AI agent's decision to a customer?
What does a good explanation look like?
Take an e-money firm. A rule flags a customer who received twenty small transfers from different senders in two days and sent the total abroad within hours.
The agent's explanation reads, in substance: the rapid in-and-out rule fired on these thirty-one transfers; the customer's profile records a student with expected monthly credits of around 500; inbound total was 6,000 from twenty senders with no prior link to the customer; outbound was a single transfer to a new beneficiary abroad; there are no prior alerts; the pattern matches the firm's money mule typology. It adds that a shared rent collection or a group purchase could explain multiple small inbound transfers, though the immediate outbound transfer abroad fits neither.
The analyst escalates. The investigator, reading the same explanation, does not need to rebuild the file.
What controls make explanations trustworthy?
- Reasons logged at the time. The facts and rule behind every flag are filed when the flag is raised, not regenerated later.
- Every fact cited. Each statement links to a record, so a reviewer can check it.
- Both directions. The agent records what it found against suspicion as well as for it.
- Stable access. The agent reads alerts through defined actions; see how to connect an AI agent to your transaction monitoring system.
- No customer-facing reasons by default. Anything said to the customer about a hold is approved by a person.
For the wider question of whether an agent should do the monitoring at all, see can an AI agent do transaction monitoring? and our guide to AI compliance agents.
Questions people ask
Can a model provider's output be explained this way?
The rule-based parts can. The model's internal weighting cannot be fully shown, which is why the record must hold the facts it was given and what it produced, so a person can judge the output against them.
Is a longer explanation a better one?
No. An analyst should be able to read it in under a minute. Supporting detail belongs in linked records, not the summary.
What if the explanation does not match the evidence?
Treat it as an incident. A mismatch means the agent asserted something its sources did not support, which should drop its depth until it is re-certified.