How to connect an AI agent to your sanctions screening tool

Grant read access to hits and list data, and a draft right for disposition notes, and stop there. The agent must not clear a hit, change thresholds, edit lists or whitelist a customer; those stay with analysts and the sanctions officer. Run it under its own identity, and log every hit it reads and every note it drafts.

What kind of tool is this, and who owns the connection?

A sanctions screening tool compares customer records and payment messages against sanctions lists and returns potential matches, or hits, each with a score and the matched fields. Analysts review each hit and decide whether it is a true match, a false positive or needs more information. The tool's configuration, its thresholds, fuzzy matching rules, list subscriptions and good-guy lists, decides how many hits are produced and which true matches might be missed. What sanctions screening is covers the basics.

The financial crime function owns the tool, usually through a sanctions officer, with the MLRO or equivalent accountable. Technology runs it. An agent connection changes who touches the hits, so both the sanctions officer and information security approve it.

Which permissions should you grant, and at what depth?

1. Person, tool owner: creates a service identity for the agent. Separate from analysts and from the screening engine's own system accounts.
2. Person, sanctions officer: lists the capabilities. Read hits and their matched fields; read list entries; read the customer or payment record; search prior dispositions; write a draft disposition note; propose escalation.
3. Person, sanctions officer: sets the agent's depth. Reads at depth 1. Draft notes and proposed escalations at depth 2. Dispositions, clearing a hit, adding to the good-guy list, changing thresholds or list settings: outside the agent's role.
4. Person, tool owner: separates customer screening from payment screening. Payment hits block money in flight; read access to them may be granted, but any action on them follows a separate, stricter route.
5. Agent, depth 1: runs against historical, already-decided hits in a test copy, so you can compare its draft notes with analysts' decisions.
6. Person, sanctions officer: approves go-live and the sample review that will follow it.

Which controls apply, and what is recorded?

No disposition capability exists for the agent. The connector simply does not expose it. This is stronger than an instruction not to clear hits. Evidence: the connector's capability list.

Notes explain the match, not the verdict. The agent sets out which fields matched, which differ, what secondary identifiers say, and what is missing. Analysts decide. Evidence: draft notes stored beside the analyst's final disposition.

Configuration out of reach. Thresholds and good-guy lists are the tool's most sensitive settings, because changing them can make true matches disappear. Evidence: the agent's identity has no rights on configuration, confirmed in each access review.

List data provenance. List entries come from the sanctions authorities through the tool's list provider; the agent records which list version it read. Evidence: list version on each note.

Full read log. Which hits, customers and payments the agent read. Evidence: needed if a decision is questioned.

What should you measure?

• Agreement between the agent's draft and the analyst's disposition, separately for true and false matches.
• Analyst time per hit, before and after.
• True matches where the agent's draft leaned towards false positive. Any of these needs root-cause review.
• Attempts outside scope, which should be refused and rare.

Where does it usually go wrong?

Asking the agent to "reduce false positives". The right place to reduce false positives is tuning, under change control and with testing. An agent asked to reduce them will tend to argue hits away. Its job is to make each review faster and better evidenced.

Prior decisions treated as precedent. A customer cleared against one list entry may not be clear against a new entry with a similar name, or against the same entry after its identifiers are updated. The agent should cite prior decisions as context, never as a reason, and should say when the list entry has changed since the earlier decision.

Transliteration ignored. Names from non-Latin scripts appear in several spellings across lists and customer records. A draft note that compares only the spelling in front of it can understate a match. The agent should show the variants it considered, and analysts should be able to see them at a glance.

Payment screening latency. If the agent's note is slower than the analyst's own review, held payments sit longer. Measure it.

Losing the human reason. If analysts start accepting the agent's draft unedited, the disposition record stops reflecting their reasoning. Sample for this.

The questions in whether an AI agent can do sanctions screening set the boundary, and the daily work is covered in triaging sanctions screening alerts and letting an agent read sanctions screening matches. Many tools screen for politically exposed persons too; whether an agent can do PEP screening covers the differences. The overall stance is in AI compliance agents.