How Compliance Teams, Investigators, and Journalists Use OpenSanctions

OpenSanctions is an open database that aggregates sanctions lists, watchlists, and politically exposed person (PEP) data from hundreds of sources, and it is used by compliance teams, investigators, and journalists to screen people and companies against those lists. You can use it in three main ways: browse collections and datasets directly, pull structured data via JSON endpoints, or run screening through the yente matching engine and its yente-client toolkit (SDK, CLI, and MCP server). The right entry point depends on whether you need to look something up, build a data pipeline, or automate screening inside an agent workflow.

What OpenSanctions actually contains

The site describes itself as "the open database of sanctions, watchlists, and politically exposed persons," aggregating hundreds of sources. That aggregation is the core value: instead of tracking each sanctions regime or watchlist separately, you query one dataset that consolidates them.

Two structural concepts matter for finding your way around:

• Collections — curated groupings of related data (for example, a set of sanctions programs or a category of PEP data).
• Datasets — the underlying data files you can retrieve and process yourself.

The site exposes these through a "Collections & datasets JSON" interface, which is the practical route for anyone who wants the data rather than a web lookup.

Choosing the right access method

The distinction between the last three is the layer you operate at: SDK for code, CLI for scripts and one-off runs, MCP server for agentic workflows. All three sit on top of the same open matching engine.

Screening for business risk

For compliance teams, the stated use case is managing business risk — checking customers, counterparties, and beneficial owners against sanctions and watchlist data. The workflow is: take an entity name (and whatever identifying details you have), run it through the matching engine, and review the candidate matches it returns.

The matching engine is described as "open," which matters because it means you can inspect how a match was produced rather than treating the result as a black box.

Why provenance matters more in agentic workflows

The site makes a pointed argument: "If an LLM agent is going to run your sanctions screening, you need to know exactly what it's checking — and be able to prove it." As compliance workflows move toward agentic automation, data provenance becomes more important, not less.

This is the practical reason to care about the aggregation model. When a screening result appears, you need to trace it back to the specific source list it came from. OpenSanctions' aggregation of hundreds of sources is designed to support that traceability, and the yente-client toolkit is positioned as the way to keep the matching engine and its data provenance visible even when an agent is driving the process.

For investigators and journalists

The same data supports investigative work: cross-referencing individuals and companies against sanctions and PEP lists, and following the source of each record. Because the data is open and retrievable as datasets, you can download it, join it with your own records, and document where each claim originates — which is the difference between a lead and a publishable finding.

Practical starting points

1. Identify your use case — manual lookup, data pipeline, or automated screening.
2. For data work, go to the Collections & datasets JSON section and pull the datasets relevant to your jurisdiction or list type.
3. For screening, use yente-client in the form that fits: SDK in application code, CLI for scripts, MCP server for agent workflows.
4. Always capture provenance — record which source list produced a match, so the result is defensible.

A common pitfall is treating a match as a conclusion. Screening returns candidates; confirming identity against the underlying source record is still your step, and that is exactly what the provenance data is for.