RSSChangelog

The statement-level API available at the /statements endpoint currently includes metadata statements, identified by the id property name. These statements are not part of the data payload but rather entity checksums used internally by OpenSanctions for change detection. As they have caused some confusion, we have recently removed them from the statements.csv data export, and will now do the same for the API.

The statement-level data export we publish for the default dataset currently includes metadata statements, identified by the id property name (which is not part of the FollowTheMoney data model). These statements are not part of the data payload but rather entity checksums used internally by OpenSanctions for change detection. As they have caused some confusion, we are planning to remove them from the statements.csv export in May 2026.

We're introducing a new property, abbreviation , to be more precise in our representation of organisation names. The new property will store shortened entity names such as ANC, AO OUK YKU, or IKEA. Abbreviations and acronyms are often a source of false positive matches in screening systems because they contain limited distinguishing detail. By separating them into a custom field, we're creating the possibility to treat abbreviations differently from full names. For example, we want to make it possible to use precise instead of fuzzy matching on abbreviations, as is already the case with weak aliases (IKEA and IAEA are two very different things).

For backward compatibility, we're currently copying all abbreviation values to the older weakAlias property in order to ensure that existing matching systems and integrations have access to its content. This backstop will be removed in September 2026. Data users are advised to integrate the new property before then.

Other notes:

• Support for abbreviation was added in yente 5.1.0. The property is now considered by the weak alias matching feature.
• Only a small set of abbreviated names have been moved to the new field so far. The distinction will be implemented incrementally over the coming months.

In Q4 2025, stretching into Q1 2026, we will be migrating our billing system for both API and bulk data customers from Chargebee to Stripe. This will reduce the number of moving parts in our service, as we already use Stripe to collect all credit card payments.

We hope that this change will pass unnoticed for our customers. Please bear with us if you do notice any minor hiccups during this time. In particular, customers may receive a partial service invoice for SaaS usage. Our highest priority during this migration is to never overcharge any of our customers. As always, if something doesn't look or feel right, please get in touch with our support team.

After releasing the new logic-v2 result scoring algorithm in September, we're planning to make it the default used by the OpenSanctions API service when no other algorithm is specified (or the best algorithm is selected). API users can prepare for this change in two ways:

• Adopt logic-v2. The new system significantly reduces false positive alert rates and improves match quality. We also plan to make this new algorithm the focus of future feature enhancements and precision improvements.
• Specify algorithm=logic-v1 as part of your query string to opt out of this change. This will freeze the use of logic-v1, the current best/default algorithm. This option is recommended for API users where scoring changes may require a regulatory approval/notification. We may choose to fully retire logic-v1 within the next 24 months.

Please feel free to reach out to the support team with any questions regarding the new scoring algorithm.

Suspended: After receiving feedback from our customers, we have decided to reverse this decision. The cutoff parameter has been marked as deprecated, but will remain in place indefinitely. The announcement below is only retained for reference. It will not be implemented.

In an effort to simplify our Matching API, we are removing the cutoff parameter. Once this change becomes effective, only matches, i.e. those results scoring higher than threshold will be returned. If you care about low-scoring results being returned, please adjust the threshold parameter instead. The match property on the returned results will remain and function as before, and match will be set to true for all results once this change becomes effective.

We are planning an upgrade to the technology stack powering the OpenSanctions API in the coming days. While new functionality will be described in a separate announcement, users of the system might notice small changes in matching results. They can be a result of:

• Improved company type suffix/prefix matching (LLC, OAO, OJSC, etc.).
• More precise retrieval of matching candidates with very generic names (A B C Limited), and of names across different scripts (Putin and بوتين).
• Fix of a bug in logic-v1 in which certain match scores for organizations could vary between requests.
• Implicit support for a broader range of jurisdictions (eg. Alberta is recognized as Canada).

Of course, it is our goal to keep matching results stable over time. The result of rolling out these improvements to some of the existing matching systems, however, should strictly improve precision and reduce false positive burden for existing users.

Effective December 31, 2025, the secondary KYB data API at api.graph.opensanctions.org will be shut down and no longer supported.

We’ve made this decision to focus on improving and expanding the core OpenSanctions dataset and API. If you are using the KYB/Graph API, please plan to transition before the end of the year. We encourage you to reach out if the impact of this change is severe for your business.

We have begun a two-step migration in the /match API response format that affects users relying on the features and matcher fields.

1. The matcher field in /match responses will be removed after February 27, 2026. Equivalent information is available via the /algorithms route (free to use).

2. A new explanations field has been added that is a strict superset of features. In addition to the partial scores produced by each component of the matching system, it includes textual descriptions of the matching decisions from each of these subsystems. These descriptions are designed for display in analyst workbenches or can be passed to generative AI tools to help interpret screening alerts. The features field will be removed after February 27, 2026. Users should update their applications to consume explanations before this date.

The targets.simple.csv bulk data format now contains a new program_ids column that contains a list of program IDs that an entity is sanctioned under. This is part of our broader effort to link entities to sanctions policy programs under which they’ve been designated. More information on what sanctions programs are and how we represent them in our data model can be found in our FAQ. For more context, see our recently-published blog post.

Starting October 15, 2025, we are planning to remove out-of-use entity identifiers from the referents list after a grace period. At present, the referents associated with entities include all IDs of source entities that have been used to describe the entity in the past, including those no longer present in our dataset. This has lead to over 100,000 entity IDs mentioned in referents which are no longer associated with any source data. In the future, we plan to remove ("garbage collect") unused referents after ca. 6 months.

Users of the data may need to update monitoring systems in which referents is used to suppress repeat alarms for a matched entity in a screening system. When an entity ID is changed and moved to referents, consumer systems should update their internal reference to the main (canonical) entity ID when drift is observed.

All LegalEntities in the data model now have a uscCode property, which is designed to store Unified Social Credit Identifiers for Chinese companies and individuals. In order to ease adoption of this new property, we are currently emitting USCI in both the new uscCode property, and in the more generic registrationNumber property that has been available previously. As of December 1, 2025, we will stop including USCI in registrationNumber, and make the identifiers available in the more specific field only.

We are starting deduplicate name variants that differ only in letter-case. If an entity lists several names whose only variation is capitalization (e.g. VLADIMIR PUTIN, Vladimir Putin, vladimir putin), we will keep just the variant closest to title-case (Vladimir Putin) and omit the others.

Why? Reduces noise and file size, and makes downstream matching more intuitive. Scope affected: all exports (CSV, JSON, Senzing) and API responses; you will see fewer aliases. Compatibility: no schema changes, only redundant values are removed. If you relied on the presence of case-only variants, review your unit tests.

We are also removing some invalid name values from the dataset, including names that consist of single-character, non-letter names.

We'd like to strongly advise all customers that are using the all dataset to use default instead.

The all dataset is an internal artifact of our data infrastructure. Other than having a pleasing name, it is a strictly inferior data product. As of February 2025, we've reduced the update frequency of all to monthly updates - meaning that users of the all scope will use outdated data in their systems.

all also includes data meant for internal verification/testing purposes which should not be included in production systems (unless you have a regulatory requirement to screen for 1990 "Die Hard" movie villain, John Gruber).

A new version of the API will remove the regression-v2 scoring algorithm, but leave regression-v1 in place for now. regression-v2 is a historic scoring method that is discouraged for screening use (it's intended use is internal de-duplication of entities in our database).

A new regression-v3 scoring mechanism is now being developed and will be released, but not recommended for screening use. Any requests that are sent to the API using regression-v2 will be re-written to use regression-v3 in the future.

This release updates various dependencies, introducing new fields in the followthemoney schema and bringing in security patches for the web stack dependencies.

We're also implementing the Reconciliation API's Data Extension protocol for the first time, allowing users to enrich OpenRefine tables with new columns using the API.

See more: https://github.com/opensanctions/yente/releases/tag/v4.2.0

We're phasing out the use of the target flag throughout the system, and switching the export formats that are based on target to use a defined list of topics as their source of truth.

A binary flag (target) is an insufficient method to describe what entities are associated with risk. For the past few months, we've been recommending the use of topics to decide if a match is relevant (e.g. as a PEP, sanctioned entity). However, some export formats - such as targets.nested.json and targets.simple.csv are still using targets to decide which entities to include.

On January 15, we will switch these two export formats (targets.nested.json and targets.simple.csv) to include any entities tagged with one the topics listed below. This is guaranteed to include all current targets, but will bring in additional entities that have topics assigned, but are not marked as targets. In short: the new exports will be more correct, and a bit larger.

This will result in the targets.nested.json export of the default dataset becoming equivalent to the topics.nested.json export of the same collection. This export can be used for testing until the change becomes effective on January 15, 2025. We will eventually remove the topics.nested.json export format on February 15, 2025, and only generated the file named targets.nested.json going forward.

Topics included in new target definition:

• corp.disqual
• crime.boss
• crime.fin
• crime.fraud
• crime.terror
• crime.theft
• crime.traffick
• crime.war
• crime
• debarment
• export.control
• export.risk
• poi
• reg.action
• reg.warn
• role.oligarch
• role.pep
• role.rca
• sanction.counter
• sanction.linked
• sanction
• wanted