We're making available the following software components for anyone's use under MIT license terms:
- yente — an entity matching API that can be used to run queries against the data produced by OpenSanctions. It is used to run self-hosted screening applications.
- yente-client — a Python SDK and command-line client for the hosted OpenSanctions API and self-hosted yente instances, including an MCP server that lets LLM agents run screening queries.
- followthemoney — entity and relationship data model used by OpenSanctions, which includes a wide range of tooling for generating custom datasets, and converting data to other formats, including graph databases.
- rigour — data cleaning and normalization tools for a wide range of semantic field types (names, territories, etc).
- zavod — the toolkit used to run the OpenSanctions data pipeline, which manages how we ingest, normalize, and publish data repeatably from many varied sources.
- nomenklatura — the data integration system used to store entity data with full lineage and to integrate entity profiles across multiple sources.
- We also make available the code for all of our data crawlers in our main GitHub repository.
We publish the source code for the data processing stack used to build the OpenSanctions data. This means that anyone can build their own versions of the data. However, a lot of the value added to OpenSanctions comes from how we use these tools, rather than the tools themselves. For example:
- You will need to build your own resolver data for entity deduplication between source datasets. We manually approve deduplication decisions to build out the dataset published here. This data constitutes a proprietary asset not included with the source code. When you conduct your own deduplication, different identifiers will be generated and you will not be able to generate links to
opensanctions.org using the data. - We use an enrichment process based around loading company registries into the yente service to build out the graph-adjacent context of sanctioned entities. Replicating that process on your own infrastructure is a fairly complex exercise.
- Certain data sources (e.g.
wd_peps, ru_rupep, sy_obsalytics) use non-open data to be built, and you will need to contact their publishers before including the data in your distribution, or exclude these sources.
When you're building your own version of the data instead of contributing to the project via a data license, please act as an open source contributor instead of a customer. Don't request real-time support. Contribute your own GitHub issues and patches if you notice any issues with the code base, and contribute documentation if you notice holes in it.