What the two layers do
Short answer
One deterministic pass over consolidated sanctions data, and one entity-disambiguated pass over public sources. They fail differently, which is why both are there.
The sanctions layer is a name-matching problem against a fixed list. It is deterministic: the same query against the same index returns the same candidates, with the same scores, every time. That matters for an audit trail — a result you cannot reproduce is a result you cannot defend.
The adverse-media layer is a search problem. It looks for public coverage associating the subject with categories that matter to a compliance decision — financial crime, enforcement action, and so on — and it has to solve a harder question first: is this article about the person you asked about, or about someone with the same name?
Neither layer is sufficient alone. A person can be sanctioned with no press coverage, and can be the subject of serious reporting while appearing on no list. Running one and calling it screening is the most common way this goes wrong.
Why a name alone is never strong
Short answer
Because a name is not an identity. A match on name alone is reported as `possible`; `strong` requires something else to agree — a date of birth, a country, an identifier.
The matching runs on a score with a floor at 0.70 — below that a candidate is not surfaced at all, because near-misses on common names generate noise that buries the real hits. Above 0.90 a match is a strong candidate, but only if something corroborates it.
Corroboration is the gate. If the only thing that agrees is the name, the candidate comes back marked `possible` with its corroboration recorded as name-only, no matter how high the string similarity is. A perfect name match is still a perfect match on a string, and there are a great many people called Ahmed Hassan.
When several uncorroborated candidates score above the strong threshold, the result raises a common-name flag rather than presenting 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.
A practical consequence for anyone wiring this in: pass the disambiguators you have. A date of birth or a country moves a result from `possible` to `strong` or clears it entirely, and the difference between those two outcomes is usually the difference between a five-minute review and an hour.
The same-name problem
Short answer
Articles about a different person with the same name are returned under `excluded`, with the reason — not silently dropped.
Entity disambiguation decides whether a piece of coverage is about your subject. Sometimes the answer is clearly no: the article is about a footballer, and your subject is a company director in another country. A naive screen returns that article as a hit and someone spends an afternoon on it.
So the excluded hits are returned rather than filtered away. You can see what was set aside and the reason it was set aside. That is more useful than a shorter list, for two reasons: a reviewer can spot a wrong exclusion, and a defensible file shows what was considered rather than only what survived.
It also keeps the tool honest about its own confidence. A screen that returns three hits and hides nine exclusions is presenting a judgement as if it were a search result.
How fresh the lists are
Short answer
Every list reports its own date. Two of those dates are the issuer’s publication date, not ours — a list can read months old because that is genuinely when it last changed.
The index holds 78,293 names from four primary sources: the US Treasury’s OFAC list, the EU consolidated list, the UK list and Australia’s. They are taken from the issuing authorities directly rather than through an aggregator, which is what makes them usable without a licence that restricts commercial use.
A refresh runs weekly, because OFAC in particular changes most days and a designation invisible for a fortnight is the failure that matters. But freshness is reported per list, and the numbers need reading carefully: OFAC and the Australian list carry the date we fetched them, while the EU and UK lists carry the date the issuer last published. A UK list showing a date months back is not a stale download — it is a list that has not changed since then.
That distinction is easy to get wrong in both directions, and getting it wrong in the alarming direction is how a compliance tool loses trust. The dates travel with the result so a reviewer can judge for themselves rather than taking a freshness claim on faith.
What this data does not cover
Short answer
No PEP data. The API reports `pep: false` and states that PEP screening was not performed — because no government publishes a consolidated PEP list.
This is the limitation most likely to matter to you, so it is stated rather than left to be inferred. Politically-exposed-person screening is a real regulatory obligation in many regimes, and the primary sanctions lists do not contain PEP data. No government publishes a consolidated one; assembling it is exactly the value a commercial aggregator adds, and their data carries licence terms that restrict commercial use.
So the response says `pep: false` and carries a note that PEP screening was not performed. It does not report "no PEP hits", which would be true in the same way that a locked filing cabinet contains no evidence. A user must never read "no sanctions hit" as "no PEP exposure", and the shape of the response is designed to make that misreading hard.
The other boundary is the obvious one for any screening tool: "nothing found" means these sources, on this day, held no match above the threshold. It is not a clean record, it is not a background check, and it is not a statement about a person. Screening produces COVERAGE — what was searched, and what came back — and coverage is what a file should record.
Wiring it in
Short answer
Send what you know, read `strength` before `candidates`, keep the excluded list, and store the coverage rather than the verdict.
SEND THE DISAMBIGUATORS. Name, and then date of birth, country, aliases, employer, role — whatever the file actually holds. Each one is a chance to promote a real match or clear a false one, and the endpoint accepts them alongside the name or reads them from an identity document you pass in.
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 corroboration, not on the score.
KEEP THE EXCLUSIONS. When somebody 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.
STORE COVERAGE, NOT A VERDICT. What was searched, which lists, on what date, at what threshold, with what corroboration. A stored "clear" ages into a claim nobody can support; a stored coverage record stays true.
AND ROUTE HITS TO A PERSON. A screening result is an input to a decision made by somebody accountable for it. A hit means review. It does not mean guilty, and the response says so in its own limitations field rather than leaving it to your integration to remember.
Frequently asked questions
What is the difference between a possible and a strong match?
Corroboration. A `possible` match agrees on name alone, however high the similarity. A `strong` match has something else agreeing — a date of birth, a country, an identifier. Millions of people share a name, so name-only is never promoted to strong regardless of score.
Which sanctions lists are covered?
Four primary sources taken directly from the issuing authorities: OFAC, the EU consolidated list, the UK list and Australia’s — 78,293 names in total. Taking them from the issuers rather than an aggregator is what keeps them usable without a licence restricting commercial use.
Does this include PEP screening?
No, and the response says so explicitly rather than staying quiet. It reports `pep: false` with a note that PEP screening was not performed. No government publishes a consolidated PEP list, and the commercial aggregations carry licence terms that restrict commercial use. Never read "no sanctions hit" as "no PEP exposure".
How often are the lists refreshed?
Weekly, because OFAC changes most days and a designation invisible for a fortnight is the failure that matters. Each list also reports its own date — and for two of the four that date is the issuer’s publication date, so a list showing an older date has genuinely not changed rather than failing to download.
What happens with a very common name?
If several candidates score above the strong threshold without corroboration, the result raises a common-name flag rather than presenting the top one as an answer. That is precisely the situation where looking decisive is most likely to name the wrong person.
Does “nothing found” mean the person is clear?
No. It means these sources, on this day, held no match above the threshold. Screening reports coverage — what was searched and what came back — and coverage is what belongs in a file. A stored “clear” becomes a claim nobody can support; a stored coverage record stays true.
Sources and further reading
- 01Developer playbook — the 100-point identity check screening pairs with
- 02API reference — /v1/adverse-media
- 03Screening inside an onboarding pack
- 04How document fraud detection works — the other half of an onboarding check
Educational guidance, not a forensic certification. Detection technologies and standards change; review material decisions against current evidence.