Reading a match and clearing it are different capabilities, and only the first belongs to the agent. Give it read access to each hit, the matched list entry and the customer or payment record, and let it draft a side-by-side comparison of identifiers. The analyst decides whether it is a true match. Reads are scoped, logged and revocable.
What is a sanctions match, and who owns the review?
A sanctions screening tool compares names and other details against sanctions lists and returns potential matches with a score. Most are false positives: a common name, a partial overlap, a different date of birth. A few are true matches, and those trigger obligations such as freezing assets and reporting to the authorities. The review of each match is where the work and the risk sit.
Screening analysts review matches, under a sanctions officer who sets the standards and handles true matches. The analyst's main task is comparison: does the customer's date of birth, nationality, address, identification number or company registration match the list entry? That comparison is what the agent prepares. The wider connection to the tool, including which permissions are not granted at all, is set out in connecting an agent to your sanctions screening tool.
Which capabilities does the agent get, and at what depth?
- Person, sanctions officer: defines the read scope. Hits assigned to the agent's queue; the list entries they match; the customer or payment record; prior decisions on the same customer.
- Agent, depth 1: reads the hit. Score, matched fields, list name and entry.
- Agent, depth 1: reads the full list entry. All aliases, dates of birth, nationalities, addresses, identifiers and the listing reasons.
- Agent, depth 1: reads the customer record. The identifiers held, with their provenance: verified document, registry or customer declaration.
- Agent, depth 2: drafts the comparison. A table of each identifier on both sides, marked as matching, differing, or missing on one side, and a plain-language note of what the comparison shows.
- Agent, depth 2: proposes more information where a decisive identifier is missing, such as a date of birth. A person decides whether to request it.
- Person, analyst: decides true match, false positive or more information needed.
- Person, sanctions officer: handles true matches, including any freezing and reporting.
| Capability | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read hit | Reads score and matched fields | 1 | None |
| Read list entry | Reads all aliases and identifiers | 1 | None |
| Read customer | Reads identifiers with provenance | 1 | Setting the scope |
| Compare | Drafts identifier table and note | 2 | The disposition |
| Propose request | Suggests what would decide it | 2 | Requesting from the customer |
| Clear or confirm | Nothing | None | Analyst and sanctions officer |
What is recorded, and which controls apply?
Read-only on the tool. The agent's identity cannot change a hit's status. Evidence: the connector exposes only read and draft-note capabilities.
Comparison, not conclusion. The draft says what matches and what differs. It does not say "false positive". The reasoning is set out in our view on whether an AI agent can do sanctions screening. Evidence: draft notes beside analysts' dispositions.
Provenance of identifiers. A date of birth from a verified passport is stronger than one the customer typed into a form. Evidence: the comparison table shows the source of each customer identifier.
Assigned hits only. The agent reads hits in its queue, not the whole screening history. Evidence: each read references an assigned hit.
Revocation. Disabling the agent's identity stops all reads immediately. Evidence: tested before go-live.
What should you measure?
- Analyst time per hit, with and without the agent's comparison.
- True matches where the comparison was misleading, for example by missing an alias. Each needs a root-cause review.
- Comparisons the analyst corrected.
- Hits waiting for more information, and how long they wait.
Where does it usually go wrong?
Aliases ignored. List entries often carry many aliases and spellings. A comparison against the primary name only can make a true match look weak. The agent must compare against every alias.
Missing identifiers treated as differences. If the customer record has no date of birth, that is not evidence the dates differ. The table must show "missing" distinctly.
Entity matches handled like individuals. For companies, the identifiers are registration numbers, addresses, ownership and directors. The comparison template should differ.
List updates mid-review. A list entry can gain new aliases or identifiers while a hit is under review. A comparison drafted against the old entry may then be wrong. The agent should record the list version it read and re-read the entry if a newer version arrives before the analyst decides.
Ownership-based exposure missed. Some sanctions regimes extend restrictions to entities owned or controlled by listed persons, even when the entity itself is not on a list. A name comparison will not find these. Where your policy covers ownership, the agent should read the customer's ownership chart alongside the hit and say whether any listed person appears in it.
PEP and sanctions confused. Many tools screen for both. A PEP match is a risk indicator, not a prohibition; the review follows reviewing PEP screening matches, and what PEP screening is explains the difference.
The overall stance is in AI compliance agents.
Questions people ask
Can the agent read matches on payments as well as customers?
Yes, with a separate read permission. Payment matches hold money in flight, so the agent's comparison must be quick, and the release decision follows its own stricter route.
Should the agent see the reason someone was listed?
Yes. The listing reasons often contain identifiers and context, such as associated companies, that help the comparison.
Does reading matches require the agent to hold personal data?
It reads the customer's identifiers for the duration of the review and records them in the draft comparison. Those drafts sit in the screening tool under its retention rules, not in the agent's own memory, so nothing persists outside the system of record.
What if the agent's comparison and the score disagree?
Show both. A high score with differing identifiers, or a low score with a matching identification number, is exactly the case an analyst needs to look at closely.