An OpenSanctions Investigation Workflow for Analysts
A practical, reproducible workflow for screening entities and persons against consolidated designation lists with OpenSanctions — from a single name check to bulk reconciliation and ownership-graph traversal.
One name is rarely one entity
Designation screening looks simple — type a name, get a hit or a miss — until transliteration variants, aliases, weak entity resolution, and indirect ownership turn a clean check into a research problem. OpenSanctions consolidates dozens of official lists into a single graph, which makes it a strong starting point for analysts who need defensible, repeatable screening.
This guide is a method, not a dossier. It describes how to run the workflow and how to record results honestly. It makes no claim that any specific entity is or is not designated — that determination always belongs to the live list at the moment you check it.
A screening result is only as current as the moment you ran it. Always record the check date and the exact query. A network error is not a clean result — never record “no match” on the basis of a failed or blocked request.
The screening workflow
From single-name lookup to ownership-aware screening, with the artefact to capture at each step.
- Normalise the query Decide what you are screening: a legal entity, a natural person, or a vessel. Capture all known name variants and transliterations before you search — matching quality depends on it.
- Run a name lookup Search the consolidated dataset for the normalised name. Read the matched record's topics (sanctioned, PEP, crime) and its source lists rather than trusting the headline match alone.
- Disambiguate the match Confirm you have the right entity using secondary identifiers — date of birth, registration number, country — not the name string alone. Record why you accepted or rejected each candidate.
- Traverse ownership and control A clean direct hit can still hide indirect exposure. Follow ownership and control edges in the entity graph to test whether a non-designated entity is owned or controlled by a designated one.
- Reconcile in bulk for lists For a portfolio of counterparties, use the matching/reconciliation interface to screen the whole set, then triage matches by score and by source-list authority.
- Record provenance and date For each result, store the entity ID, the source lists, the screening date, and the query. This is what makes the check defensible later.
- Tag the outcome honestly A direct list hit you confirmed is CONFIRMED; an indirect ownership inference is ESTIMATE; a name match you could not disambiguate is REPORTED pending confirmation.
Interfaces and what each is for
OpenSanctions exposes several access paths. Pick by task, not by habit.
| Task | Interface | Notes |
|---|---|---|
| Ad-hoc single check | Web search UI | Fastest for one name; shows topics and source lists |
| Programmatic lookup | Match / search API | Requires an API key; rate-limited; good for automation |
| Portfolio screening | Reconciliation / bulk match | Screen a whole counterparty list and triage by score |
| Offline / full graph | Bulk data exports | Entity-graph downloads for ownership traversal at scale |
Method limitation: consolidated lists lag official publication by hours to days, and entity resolution is probabilistic. Treat OpenSanctions as a high-recall first pass, then confirm any positive against the issuing authority's own list before acting on it.
Common questions
Does a match in OpenSanctions mean an entity is sanctioned?
Not by itself. A match flags that the name resembles a record in a source list. You must disambiguate using secondary identifiers and confirm against the issuing authority before treating it as a designation.
How do I screen for indirect ownership exposure?
Traverse the ownership and control edges in the entity graph from your counterparty outward, testing whether any owner or controller above a control threshold is itself designated. This catches exposure that a direct name check misses.
Why should I record the screening date and query?
Designation lists change constantly. A defensible screening result captures exactly what was checked and when, so the result can be reproduced and audited later. A failed network request is never recorded as a clean result.