Download our data
Contents
Downloads
Links to the most recent files we've exported:
What is this data?
Each file contains a complete snapshot of all of the data in this register. That includes data from:
- UK PSC Register (regularly updated)
- Denmark Central Business Register (CVR) (regularly updated)
- Slovakia Public Sector Partners Register (regularly updated)
- Ukraine Unified States Register (EDR) (regularly updated until September 2020, now paused)
- EITI pilot data (data collected 2013-15)
- User submitted data
The raw data from each of these sources has been imported, the companies reconciled with OpenCorporates and - where possible - de-duplicated based on OpenCorporates results and our own de-duplication algorithms. It has also been periodically refreshed with reconciliations with OpenCorporates database to collect company name changes, dissolutions, etc.
The data is formatted in version 0.1 of Open Ownership's Beneficial Ownership Data Standard. All source data has been standardised on export, attempting to keep as much source-specific information as possible, but prioritising consistency across sources.
We are in the process of updating the Open Ownership Register to export data in line with . Data from individual source registries mapped to v0.2 so far can be found and reused in a variety of formats via our BODS data analysis tools.
We have extensive documentation on the standard, in particular we recommend understanding the key concepts in the data model and then referring to the specifics using the interactive schema browser.
The file is in JSONLines format,
meaning each BODS statement
is a JSON object on a
single line of the file. It has been compressed with
Gzip, which is
usually already available on MacOS and Linux systems, and is easily
readable with a variety of compression programs on Windows.
Our regular data updates occur every three weeks, and we will endeavour to make a new export after each update. This page will be updated as soon as that happens, but you can also rely on the "latest" link at the top of the page to always point to the most recent data.
What is this data not?
100% accurate, up-to-date, or lawful for every use case. As per our terms and conditions we cannot guarantee the accuracy of the data, nor that your use of it is lawful. Due to the nature of our periodic update and refresh process, we also can't guarantee the freshness of the data. Refer to the information quality section of our terms for more details.
A comprehensive dataset of companies in the jurisdictions we have data for. It only contains those people and companies who've declared beneficial ownership information. For example, the UK PSC and DK CVR registers are broadly intended to cover all companies in their respective countries, but there will always be companies who don't comply. In addition, some jurisdictions (e.g. Slovakia) only require declarations from specific sectors or types of companies.
Data on company directors, officials or shareholders. Whilst individuals in these roles may also be beneficial owners, the inverse is not always true. The people in our data are only those who meet the definition of a beneficial owner in their respective jurisdiction. There are often thresholds of share-holding (for example) which must be exceeded to qualify. Conversely, share-holding is not the only way one becomes a beneficial owner.
A complete BODS representation of the Register's dataset. As you'll see from the documentation, BODS' schema provides fields for lots of data. We try to map the Register's data to this model as fully as possible, but there is data we don't have because it's not provided in our sources and data we haven't mapped fully yet.
In particular, we're aware of the following omissions and issues:
- The data is in v0.1 of the data standard, not the most recent v0.2. We're working on updating this.
-
We're not making incremental updates and marking old statements
via
replacesStatements
fields. Each update is a standalone snapshot of the entire data set, although ourstatementIDs
should be consistent where data doesn't change. See our documentation on identifiers for more information on the ways you can link data across releases. -
Because we try to reconcile every company with OpenCorporates, the
data you see may not have actually come from the source. If we can
match a company to OpenCorporates we prefer their data because it
is normalised, cleaned and derived from more sources than ours. In
particular this affects the
company name
,address
,jurisdiction
,company number
,incorporation date
,dissolution date
andcompany type
. We're aware of some issues where this causes a loss of data from the source and are working on plans to make the process more granular and transparent. -
We're not marking what type of
address
a person's address is, as this information is not available in our sources. -
We're not marking which specific
Interests
constitute beneficial ownership and which don't. We need to do more analysis on our sources to understand when it's possible to determine this. -
We only set
source
fields to report provenance onownershipOrControlStatements
, notentityStatements
orpersonStatements
. This is because of how, historically, the register has stored provenance information, but we're working on it. -
We don't set
statementDate
, because we don't have dates available across our sources that is consistent with BODS' meaning of this field. We need to do more work to understand when we can report this accurately. -
We currently report all entities as
registeredEntity
even when they're obviously not, such as the state which owns state-owned entities. -
We don't have any data to be able to report
placeOfBirth
,placeOfResidence
,pepStatus
ordeathDate
for people, noralternateNames
for companies.
How do I use it?
While we suggest you read the Beneficial Ownership Data Standard documentation, here's a very brief overview of how the data is structured and how we suggest you can use it:
Format & Structure
As mentioned above, the file is a single JSONLines format file,
with one JSON statement
per line. Lines are
separated by Unix line endings (\n
). The file has been
compressed with Gzip, so expect the uncompressed version to be
roughly 10x bigger than the compressed one.
Each statement concerns a person, entity or relationship between them. They are in order such that, if you process the file sequentially from first line to last, you will see the people or entities involved in any relationships before you see the relationships. Note that this means if you process the file in a parallel or distributed fashion, you will need a means of revisiting statements which you see out of order.
Example data
An entity statement for an example company, registered with the UK's Companies House register:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
{ "statementID": "openownership-register-123456789", "statementType": "entityStatement", "entityType": "registeredEntity", "name": "EXAMPLE LTD", "foundingDate": "2019-10-01", "identifiers": [ { "scheme": "GB-COH", "schemeName": "Companies House", "id": "0123456" }, { "schemeName": "GB Persons Of Significant Control Register", "id": "0123456" }, { "schemeName": "OpenOwnership Register", "id": "https://register.openownership.org/entities/abcdefg12345", "uri": "https://register.openownership.org/entities/abcdefg12345" }, { "schemeName": "OpenCorporates", "id": "https://opencorporates.com/companies/gb/0123456", "uri": "https://opencorporates.com/companies/gb/0123456" } ], "incorporatedInJurisdiction": { "code": "GB", "name": "United Kingdom" }, "addresses": [ { "type": "registered", "address": "Example street, London, SW1A 1AA", "country": "GB" } ] } |
An example person who will own the example company:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
{ "statementID": "0openownership-register-91011121314", "statementType": "personStatement", "statementDate": "2019-10-01", "personType": "knownPerson", "identifiers": [ { "schemeName": "GB Persons Of Significant Control Register", "id": "/company/0123456/persons-with-significant-control/individual/hijklmn12343" }, { "schemeName": "OpenOwnership Register", "id": "https://register.openownership.org/entities/abcdefg678910", "uri": "https://register.openownership.org/entities/abcdefg678910" } ], "nationalities": [ { "code": "GB", "name": "United Kingdom" } ], "names": [ { "type": "individual", "fullName": "Jane Smith" } ], "birthDate": "1973-01", "addresses": [ { "address": "Example street, London, SW1A 1AA", "country": "GB" } ] } |
Their relationship (Jane owns all the shares in Example Ltd):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
{ "statementID": "openownership-register-1516171819", "statementType": "ownershipOrControlStatement", "statementDate": "2019-10-01", "subject": { "describedByEntityStatement": "openownership-register-123456789" }, "interestedParty": { "describedByPersonStatement": "openownership-register-91011121314" }, "interests": [ { "type": "shareholding", "startDate": "2019-10-01", "share": { "exact": 100 } } ] } |
Identifying and linking entities
The primary identifier in BODS is the statementID
. This uniquely
identifies a particular statement about a person, legal entity or
relationship between them. Every time details about one of those
things changes, a new statement is needed, which has a new id.
With our current data, we are only providing a 'snapshot', i.e.
the most recent set of statements, but you may want to link these
statements to older releases to see what changes. You may also want
to link our data to other datasets that have company numbers or
other identifiers in them. You may even want to link your project
back to us (which would be very nice, thank you!).
The identifiers
field is the way you can do all of these
things.
The BODS schema allows for an array of identifiers to help users of the data link people and companies to other data sources. We make use of this feature to provide several of our own identifiers as well as transferring as much information from the original source data as we can, so that you can link the records back to their original data.
Here are some examples of identifiers you might see and an explanation of how to interpret them:
An official identifier using an Org-Id scheme
We will give these identifiers when we're sure that the id we have is
from the Org-Id.guide
scheme
given. For example, we'll give
company numbers under the GB-COH
scheme for
companies declaring their beneficial owners in the Companies House
Persons of Significant Control register. However, we won't use it for
companies listed as beneficial owners in the same dataset, because
the company numbers given in that case aren't verified by Companies
House. Likewise, we won't give identifiers under that scheme for UK
companies from other countries' registers, as we assume they haven't
been validated or verified.
If entities have identifiers from a register that we matched in Org-Id, you should be able to uniquely identify them and connect them to other data sources. For example, you can match companies to a national register or match them to other datasets like Open Contracting which uses the same identifiers.
All of the identifiers we currently match to Org-Id schemes are for company numbers. Org-Id has many other identifier schemes available, such as for charities or educational institutions, however none of our data sources have verified data which we can link to them, so we do not use them. Similarly, BODS allows for schemes to declare official identifiers for people, such as tax ids or passport numbers, but none of our data sources report these either.
Unofficial identifiers
In cases where we can't give an official Org-Id scheme
,
we'll give an identifier with just a schemeName
.
These names will always start with the ISO-3166-1 alpha2
country code for the country the register is in, followed by the
original language name for the register. For example: GB Persons
Of Significant Control Register or UA Edinyy Derzhavnyj
Reestr.
The intention is that these identifiers can be used to uniquely identify a person/company record within that data source, though not necessarily outside of it. Likewise, they will identify the record but may not uniquely identify the entity. For example, for beneficial owners from the GB Persons Of Significant Control Register we give the value of the 'self link', a path-like string which uniquely identifies a beneficial owner record, but doesn't identify a specific person or company across records.
The values in the id
field will vary depending on the
source. As shown above, we use whatever field(s) in the source can
uniquely identify the record. In some cases this means combining
multiple fields (with a hyphen -
). Currently, the fields are:
- DK Centrale Virksomhedsregister:
enhedsNummer
- SK Register Partnerov Verejného Sektora:
KonecniUzivateliaVyhod.Id
- GB Persons Of Significant Control Register: beneficial owner "self links"
- GB Persons Of Significant Control Register - Registration numbers: beneficial owner "registration numbers". i.e. unverified company registration numbers.
- UA Edinyy Derzhavnyj Reestr: company number and beneficial owner name
- EITI 2013-2015 beneficial ownership pilots: beneficial owner name
An OpenCorporates identifier
For companies we've successfully matched to OpenCorporates, we
include the url to that company on opencorporates.com. Note that in
some rare occasions we will have matched a company to more than one
OpenCorporates record. For completeness, we're including the same
value in both the id
and the uri
fields.
A register identifier
Every single known person and company will have an identifier that
gives their url on the register. Unknown companies are declared
explicitly in BODS, but don't have a corresponding page in the
register so we cannot give a url for them. Again the value is in
both the id
and uri
.
License
Please see our terms and conditions.
Further information
Contact us if you have questions about using this data which aren't answered here.
Changelog
For more information on our iterative improvements to this data, see our changelog of major changes.