Where OpenSanctions gets its sanctions and PEP data, and how to verify provenance

OpenSanctions aggregates sanctions, watchlist, and politically exposed person (PEP) data from hundreds of public sources into a single open database, and it exposes the underlying collections and datasets as JSON so users can trace where a given record came from. That provenance layer matters most if you are running screening inside an automated or agent-driven compliance workflow, where you need to show exactly what was checked and why a name matched.

What data OpenSanctions covers

The database is described as covering three broad categories:

• Sanctions — individuals and entities designated under government sanctions programs.
• Watchlists — other risk-relevant lists beyond formal sanctions.
• Politically exposed persons (PEPs) — people in public roles that carry heightened corruption or bribery risk.

Rather than maintaining one proprietary list, OpenSanctions is an aggregator: it pulls from hundreds of sources and consolidates them. The site positions the result as a resource relied on by compliance teams, investigators, and journalists.

How the aggregation model works

The key mechanism is consolidation across sources rather than a single authoritative feed. Because many sanctions and PEP lists overlap — the same person may appear on several national lists under slightly different spellings — an aggregator has to merge and reconcile records while keeping the link back to each original source.

That link back to the source is what "provenance" means here: for any statement the database makes about a person or company, you can identify which collection or dataset it originated from.

Verifying provenance: the collections and datasets JSON

OpenSanctions publishes its Collections & datasets as JSON. This is the practical entry point for checking where data comes from:

1. Open the collections/datasets JSON listing on the site.
2. Identify the collection relevant to your screening (for example, a specific sanctions program or PEP source).
3. Use the dataset metadata to confirm the source, scope, and coverage of that collection.
4. Cross-reference the collection against the specific record or match you are reviewing.

The expected result is that any match can be tied back to a named, inspectable source rather than an opaque score.

Why provenance matters more as screening goes agentic

The site's own framing is that if an LLM agent is going to run your sanctions screening, you need to know exactly what it is checking — and be able to prove it. As compliance workflows move toward agent-driven automation, the ability to demonstrate data lineage becomes a requirement, not a nice-to-have.

To support that, OpenSanctions describes yente-client as an SDK, CLI, and MCP server combined into one toolkit, running on top of its open matching engine. In practical terms, the layers break down as:

The point of naming these layers is that each one sits on top of the same open matching engine and the same sourced data — so the provenance chain is preserved whether a human or an agent runs the check.

What you can and cannot conclude from this

You can verify that OpenSanctions is an aggregator of hundreds of public sources, that it exposes collections and datasets as JSON for inspection, and that it provides tooling (yente-client) aimed at making automated screening auditable.

The source material does not state pricing, licensing terms for commercial use, or login requirements, so treat those as unconfirmed and check the site directly before relying on the database in a production compliance process.