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:

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 our statementIDs 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 and company 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 on ownershipOrControlStatements, not entityStatements or personStatements. 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 or deathDate for people, nor alternateNames 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 

1
2
3
4
5

{
  "scheme": "GB-COH",
  "schemeName": "Companies House",
  "id": "0123456"
}

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 

1
2
3
4

{
  "schemeName": "GB Persons Of Significant Control Register",
  "id": "0123456"
}
 
1
2
3
4

{
  "schemeName": "GB Persons Of Significant Control Register",
  "id": "/company/0123456/persons-with-significant-control/individual/hijklmn12343"
}
 
1
2
3
4

{
  "schemeName": "UA Edinyy Derzhavnyj Reestr",
  "id": "12345-Test Person"
}

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 

1
2
3
4
5

{
  "schemeName": "OpenCorporates",
  "id": "https://opencorporates.com/companies/gb/0123456",
  "uri": "https://opencorporates.com/companies/gb/0123456"
}

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 

1
2
3
4
5

{
  "schemeName": "OpenOwnership Register",
  "id": "https://register.openownership.org/entities/abcdefg12345",
  "uri": "https://register.openownership.org/entities/abcdefg12345"
}

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.


Latest data

Exported: 2023-04-29

Download  

Changelog

For more information on our iterative improvements to this data, see our changelog of major changes.