Sanctions and adverse-media checks from an AI agent: what comes back, and why PEP is not screened

The question, and what to give the tool

The tool is `screen_adverse_media`. Over MCP an assistant calls it when you ask something like “Is there anything on Jane Example, born 1978, Australian, director of Example Pty Ltd?” Over REST it is `POST /v1/adverse-media` with the same fields: `name`, then optionally `dob`, `country`, `aliases`, `employer`, `role`. You can pass an identity document instead — a public URL or the bytes — and a reader pulls the subject’s name, date of birth and nationality from it before the screen runs.

Send the disambiguators. For a candidate that already scores high, a date of birth or a country that agrees is what moves it from `possible` to `strong`; a role and an employer are what let the adverse-media pass tell your subject from a footballer with the same name. An agent that asks its user for a date of birth before screening is doing the single most useful thing it can do for the quality of the result.

What you get back is one JSON reply with a `subject` block (what was screened, and where the details came from), a `sanctions` block, an `adverse_media` block, a `risk_flag`, a one-line `headline`, and a `limitations` field written for a human. Everything below is about reading those.

The sanctions layer: candidates and strength

As deployed, the sanctions layer matches the subject against consolidated designations taken directly from the issuing authorities — the US Treasury’s OFAC list including its alternate names, the EU consolidated list, the UK list and Australia’s. (The code also carries an optional path to a licensed aggregator; it is not enabled on stipple.sh.) The match is deterministic: the same name against the same index returns the same candidates with the same scores every time, which is what makes it defensible later.

Each candidate carries a similarity score and a `strength`. Below 0.70 nothing surfaces. At 0.90 or above a candidate is strong only if a date of birth or a country corroborates it. If the only thing agreeing is the name — or the date of birth or country you gave does not agree — it comes back `possible` with the corroboration recorded, however high the score, because a perfect match on a string is still a match on a string.

When several uncorroborated candidates all score above the strong threshold, the reply sets `common_name_ambiguity` instead of promoting the top one. That is the case where a screening tool most wants to look decisive and where being decisive is most likely to name the wrong person. The summary counts — `strong_matches`, `possible_matches` — are there so an agent can branch on strength rather than on a number.

Each list also reports its own date in the reply. Two of the four carry the issuer’s publication date rather than the fetch date, so an older date means the list has not changed since then, not that the download failed. The companion guide covers the sourcing in detail.

The adverse-media layer: hits, evidence, exclusions

The media layer runs one search: the subject’s name together with a fixed set of adverse terms — fraud, convicted, charged, arrested, indicted, bribery, corruption, money laundering, sanctions, embezzlement, terrorism, trafficking, investigation. The top results are read — the provider’s own excerpt where it supplies one, the page itself otherwise — and a single batched judgement then does the hard part for each article: is this about the subject, or about a different person who shares the name; and if it is the subject, what category of adverse content, at what severity.

A hit comes back with the article’s URL, title, source and date; a `match` of `match` or `possible`; a `category` from a fixed list (financial crime, money laundering, bribery and corruption, sanctions, terrorism, trafficking, tax evasion, regulatory enforcement, cybercrime, violent crime, other); a `severity` of convicted, charged, alleged or mention; and a quoted `evidence` line of at most 160 characters from the text. That quote is the part a reviewer reads first.

Articles judged to be about a different person come back under `excluded`, with “different person (same name)” as the reason, rather than being dropped. A screen that returns three hits and hides nine exclusions is presenting a judgement as a search result; returning the exclusions lets a reviewer see what was considered and catch a wrong exclusion.

The reply also names which search provider answered and whether a failover happened, and the caps are deliberate and stated: up to three usable articles, with the news-index path English-language and recency-weighted. That is why “no adverse media found” is a statement about coverage — these sources, this query, this day — and not about the person.

PEP: what “not screened” means

Politically-exposed-person screening is a real obligation in many regimes, and this tool does not perform it. No government publishes a consolidated PEP list; assembling one is the value the commercial aggregators add, and their data carries licence terms that restrict commercial use. So rather than screen against a list it does not have, the tool says so in the reply.

For an agent this is the line to relay verbatim. A user who asks “is this supplier a PEP?” should hear “this check did not screen for PEP status” — not “no PEP exposure found”, which would be true in the way a locked filing cabinet contains no evidence. The response shape is designed to make the wrong reading hard: the flag is `false` and the note says why, rather than an empty list that reads as a clean result.

If PEP coverage is a requirement, this tool is the sanctions and adverse-media half of a screen, and a PEP source has to sit beside it. Saying that plainly is more useful than a marketing page that lists “PEP” in a feature grid.

Reading the whole reply

READ STRENGTH FIRST. A `possible` at 0.94 and a `strong` at 0.91 are different findings, and the number is the less important half. Branch on `strength` and the corroboration behind it.

READ THE EVIDENCE LINE. For a media hit, the quoted line and the severity are what a reviewer needs; the category is a filing label. “Charged” and “mention” are not the same finding.

KEEP THE EXCLUSIONS. When someone asks in six months why a subject was cleared, the excluded list is the part of the record that shows the question was actually considered.

RELAY THE LIMITATIONS. The reply’s `limitations` field is written for a human and says, in one paragraph, that this is coverage rather than a determination, that a name-only sanctions hit is possible rather than confirmed, and that nothing found is not a clean record. An assistant that passes that paragraph on is doing its job; one that summarises it away is not.

AND ROUTE HITS TO A PERSON. `risk_flag` and `headline` are there for triage. A hit means somebody accountable looks at it. It does not mean guilty, and it does not mean sanctioned — it means the sources connected the name to something worth reading.

Where it fits, and what it costs

Screening is a metered call: it needs a signed-in account (a free 7-day trial with 200 credits, no card), and the account’s key travels as a header. Claude Code, Cursor and config-file clients pass it; the claude.ai and ChatGPT connector dialogs cannot yet, so from those the tool answers with a sign-in message — the connection guide explains which tools work where.

Nothing is retained. The subject you submit is screened and not stored; the reply is the record, and the useful thing to store on your side is the coverage — what was searched, on what date, with what corroboration — rather than a verdict that ages into a claim nobody can support.

In an onboarding flow it sits beside the identity check (is this person who they say they are) and document verification (are the documents they sent genuine). Screening answers a third question — is there anything on this name — and only that one. For a supplier or a tender bidder, the five questions together form an evidence gate an agent can run in one conversation; that gate, tool by tool, is its own guide.