RSSChangelog

The default collection is focused on datasets representing risk, and includes entities within those sources as well as the enrichment of those and related entities. iso9362_bic was initially added to default because it's relatively small, but since it's purely reference data, we've decided to give it the same treatment as other larger reference datasets.

To that end, we're planning to remove the full Business Identifier Code (BIC) Reference Data (iso9362_bic) from the default collection on June 15th, 2026. It will be replaced by a new enrichment dataset named ext_iso9362_bic containing the risk-related entities from this source.

iso9362_bic will still be available in full in KYB Reference Data catalog. Read more about data enrichment.

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.

tl;dr: Replace all use of gb_hmt_sanctions with gb_fcdo_sanctions (in the API and in bulk data scenarios) by January 28. gb_hmt_sanction will stop receiving new entities and eventually be removed from the database entirely.

Policy Change#

The UK government is consolidating its sanctions designation lists into a single source. Starting January 28, 2026, at 09:00 GMT, the UK Sanctions List (UKSL) will become the sole official list for all UK sanctions designations. The OFSI Consolidated List of Asset Freeze Targets and its associated search tool will cease updates from this date.

This consolidation follows the Cross-government review of sanctions implementation and enforcement, responding to industry feedback that a single list will remove duplication and simplify compliance checks.

Impact on OpenSanctions Data#

OpenSanctions currently maintains two separate UK datasets:

• UK HMT/OFSI Consolidated List of Targets (derived from the OFSI Consolidated List)
• UK FCDO Sanctions List (derived from the UK Sanctions List)

Following the UK government's consolidation, we will transition to maintaining a single aggregated UK sanctions dataset sourced from the unified UK Sanctions List. We expect this to be a smooth transition:

• The consolidated UK Sanctions List is already covered by our existing UK FCDO Sanctions List dataset and will be expanded by the UK government on January 28, 2026 to include all sanctions designations
• The UK government has confirmed that the existing data format and structure of the UK Sanctions List will remain unchanged, so we do not anticipate any processing errors or disruptions
• By the end of 2025, we will update our data ingestion process to consume both the XML and CSV formats of the UK Sanctions List. This dual-format approach provides redundancy in case one format is published with delays or technical issues
• The UK HMT Financial Sanctions dataset will not receive updates after January 28, 2026, as the underlying OFSI Consolidated List will no longer be published. These datasets will be formally deprecated on that date, and entities exclusively designated on that list will stop being tagged with the sanction topic.
• Historic OFSI Group IDs will be preserved in our data for entities designated before January 28, 2026 for another six months for reconciliation purposes. New designations from January 28, 2026 onwards will use the UK Sanctions List's Unique ID as the primary identifier.

For more information, see the UK government's guidance on moving to a single list.

For designated entries, the EU Financial Sanctions Files (FSF) sanctions list includes names translated to one or more of the official languages of the European Union.

Currently, all of these names are included in the name field, marking them as primary names. Once this change becomes effective, they will be listed in the alias field. The primary (English) name of the entry will still be listed in the name field.

This change is part of a broader effort to ensure that the name field only contains the highest-quality names available, and that names that can be considered less relevant are listed in alias and weakAlias fields instead.

Users of our hosted API and yente are not affected by this change, as the built-in scoring algorithms consider both the alias and the name fields for matching of names.

After the introduction of sanction program identifiers, we're now migrating a number of smaller national sanctions lists to use the same mechanism. Until now, we annotated hard-coded program names in these datasets (as values for the Sanction:program property).

As these program names are not authoritative, we are now replacing them with Sanction:programId references. This creates a clearer separation between the data provided from source, and analytical annotations stemming from our data pipeline.

Read more about using sanctions programs.

Affected datasets:

• au_listed_terrorist_orgs
• br_ceis
• ca_named_research_orgs
• cz_terrorists
• eu_esma_saris
• interpol_api
• ir_sanctions
• kz_afmrk_sanctions
• li_posting_sanctions
• lt_fiu_freezes
• nz_russia_sanctions
• Pending:
• pk_proscribed_persons
• pl_finanse_sanctions
• ru_mfa_sanctions
• sg_terrorists
• ua_nsdc_sanctions
• un_1718_vessels
• us_bis_denied
• us_cuba_sanctions
• us_ddtc_debarred
• us_ddtc_enforcements
• us_dod_chinese_milcorps
• us_fcc_covered_list
• us_fed_enforcements
• us_hhs_exclusions
• us_state_terrorist_orgs

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 will begin to indicate the level and status of political influence in PEP profiles where possible. This will be described with values like National government (current) or State government (past) in the Person:classification property. This replaces the use of the Person:keywords property that was previous included in the wd_peps dataset.

This data will only be available in the default dataset. Read more on why that is most appropriate even if you only need PEPs.

We're planning to remove the Syrian Observatory of Political and Economic Networks (sy_obsalytics_opensyr) from the regular updates of the default collection on June 9th, 2025. The dataset, created by research group Obsalytics is a one-off import of a small subset of the live database, and the export into OpenSanctions was last updated in February 2023.

Given the increasing rate of change in the sanctions landscape surrounding Syria - with the EU and US both revoking parts of their existing regimes - we've decided to avoid the presence of outdated information on our website by removing this dataset. We recommend interested parties use the available search function for the OpenSyr database for additional research.

We're working on a new major release of FollowTheMoney, the data model underlying OpenSanctions. This major release cleans up some aspects of the domain model. The changes mostly affect schemata not used by OpenSanctions. However, we want to list the relevant upcoming changes here:

• The CryptoWallet:mangingExchange property will be renamed to CryptoWallet:managingExchange. This property is used by the il_mod_crypto dataset. Please update any client/import code reliant on this property to use the new name.
• The Sanction:duration property will change its datatype from string to number. The property values remain strings in the JSON export format, and may still contain a unit specification (eg. 2 years). It is very likely that no action needs to be taken by data consumers.

Non-relevant schema changes:

• The Post and Assessment schemata will be deleted. Both are unused by OpenSanctions.
• Several other properties - not used in OS - will change: License:area (string to number), and the UserAccount:number property will be renamed to UserAccount:phone. The Company:ibcRuc property is to be deleted.

We will provide a more detailed change log when the release is published. This announcement merely serves as an early advisory regarding schema changes.

• FollowTheMoney PR #1749.

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).

In the us_sam_exclusions dataset based off the SAM.gov exclusion and debarment list, the designated entity's UEI is currently stored in the registrationNumber field. Going forward, a new property, called uniqueEntityId is available and will contain these identifiers. Starting Feb 1, 2025, we will then remove the UEI mapping to registrationNumber.

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

The dataset Liechtenstein Posted Workers Act (EntsG) Sanctions was previously running of a static, outdated version of the data which had been published in HTML format. It will now be updated from a regularly-published PDF file. As part of this update, the IDs of the listed entities are changed, and the topic applied to first-time penalised entities ("Übertretungen" i.S.v Art 9) is changed from debarment to reg.warn.

The sanctions regime under Section 353 of the Corrupt and Undemocratic Actors Report has expired in December 2023. To reflect this, we've removed the topic sanction from all entities in the dataset. We will remove the relevant dataset entirely after November 1, 2024, and move the formerly-designated entities for reference to the US Special Legislative Exclusions dataset

Section 353 concerns foreign individuals who have been reported for knowingly engaging in activities that undermine democratic processes or institutions, participating in significant corruption, or obstructing investigations into such acts in El Salvador, Guatemala, Honduras, and Nicaragua.

A soft length limit in Unicode codepoints has been added for all properties. These can be seen in the data dictionary. The goal of this is to make it easier for data consumers to import our data into systems with fixed-length column types.

Property values are not yet guaranteed to be limited to this value, but our tooling now alerts us when values are longer than this, so that we can identify sources which don’t adhere to sensible limits and eventually enforce hard limits.

Imposing a length limit has also identified many instances where the data required further cleaning, which we've implemented as needed.

The permId property for LSEG/Refinitiv company codes has been moved up from the Company to the Organization schema to enable reflecting government entities (using the PublicBody schema) also receiving these identifiers.

The followthemoney data model currently stores the citizenship of individuals in the nationality property. After being advised the the two concepts are not identical in some jurisdictions, we've now also introduced a citizenship property. From the effective date we will begin moving country affiliations for individuals in the citizenship property if that nomenclature is used in the data source (e.g. the UK sanctions list).

Data consumers should check both properties in the future. To get a complete picture of the countries linked to an individual you may also want to check the birthCountry and country field. The latter serves as a catch-all field for affiliations that may not involve citizenship or holding a passport - simple residence might be enough.

See: Person schema.