Structured and interoperable beneficial ownership data

  • Publication date: 12 August 2022
  • Authors: Jack Lord, Tymon Kiepe

Operationalising structured beneficial ownership data

In order to operationalise structured BO data, implementers should consider:

  • creating an enabling environment;
  • establishing principles for collecting and storing BO information; and
  • realising potential and resolving uncertainty at the publication stage.

Creating an enabling environment

The potential of structured data is ultimately limited by the legal, regulatory, and political environment. No amount of technical work can overcome the limits established in these areas. Therefore, the most important task for policy makers is to establish and progressively enhance the legal, regulatory, and political framework to achieve technical goals relating to BOT.

User-centred and iterative approach

Implementers should follow a user-centred design approach to technology. This will ensure stakeholder buy-in and create a system that is fit for purpose.[51] Implementation should be considered as an iterative process, rather than as a one-off project. The success of some of the early registers has been due to their iterative approach (see, for example, Box 3). By engaging data users as part of and after implementation, and making iterative improvements to their systems, early adopters have converged on elements now considered cornerstones of effective BOT reforms.

The legislation should support an iterative approach. If the legislative is too prescriptive, then any small change to the administration of the register will require legislative amendments. This can make iteration less likely because legislative amendments take time and effort, and every time it is debated in a legislative body, it opens itself up to a potential political backlash. In contrast, if the registrar is given more flexibility, it can be easier to make these iterations. An example of this is when jurisdictions include BO declaration forms within secondary legislation or regulations. This prevents the registrar from being able to make iterative improvements to the collection forms to address any teething problems (see, for example, Box 3).

Legal and policy environment

In addition to facilitating an iterative approach, it is fundamental to ensure that the legal foundations exist to collect sufficient data to achieve BOT policy goals. The usefulness of structured data is limited by how accurate and reliable, detailed, up-to-date, comprehensive in coverage, and auditable the underlying BO information is. The OO Principles provide a framework for building information quality into these crucial stages of the implementation process.[52] Data collection, verification, and data sharing may require agreements between multiple institutions to, for example, verify documents against an identity register or check declarations against data held by financial institutions. These types of agreements take time to agree and operationalise, and should be initiated early on. Whilst the specific details for making BO data structured are rarely included in legislation, the following features are all part of a solid legal foundation:

  • robustly defining beneficial ownership;
  • ensuring comprehensive coverage and the collection of sufficient details;
  • creating the legal obligation to disclose and the appropriate triggers to make BO declarations;
  • establishing the right legal basis for the processing and publication of information in conformance with privacy and data protection legislation;
  • ensuring the right data agreements are in place for verification; and
  • designing sanctions and enforcement regimes that drive up compliance and data quality.[53]

Technology can be used to make privacy and security a cornerstone of implementation. Not all BO information should be made public, and structured data provides the easiest and safest way to control and audit access by those who have the right permissions to the full or partial dataset, for example, by making a smaller subset available to the public than to domestic authorities and omitting data fields that are particularly sensitive, known as layered access. It is also important to establish a protection regime in order to allow exemptions to normal disclosure procedures and the retraction or redaction of already published data.[54] Structured data lowers the costs and risks associated with using or republishing data that might later be redacted data. Structured data also makes cross-jurisdictional coordination on privacy and security measures possible, reducing the risk of accidental disclosures in the case of a genuine exemption.

Resourcing

Policymakers should ensure that the success of BOT policy goals is not held back by technical resourcing issues. BOT is a complex policy intervention with expected benefits that are widespread and long term in nature, and implementation often involves both cross-government coordination and significant changes to systems and processes. Funding a technical system that can achieve these ambitions can be challenging. Any technical business case should be framed around identifying the full spectrum of expected policy benefits rather than minimising implementation costs for a single government agency. As these benefits usually accrue outside the implementing agency, a holistic approach to budgeting is required.[55] Beyond technical resourcing, BO disclosure regimes also require sufficient resourcing to ensure compliance, enforce sanctions, and query and verify data to ensure the integrity of the information.

Establishing principles for collecting and storing beneficial ownership information

In establishing principles for collecting and storing BO information, implementers should consider the minimum key elements of structured BO data and embedding these and other elements into systems design.

Key elements of structured beneficial ownership data

BO data describes ownership or control relationships between natural persons and legal entities. Depending on the disclosure regime, these relationships may be simple or more elaborate when described as data, but the three principle functions that BO data should perform remain constant. Beneficial ownership as structured data should:

  1. identify the people, companies, and other relevant parties disclosed in a BO declaration;
  2. describe the nature of the interests and relationships between parties (e.g. nominees) disclosed in a BO declaration; and
  3. ensure that BOT disclosures are auditable and interoperable.

Identifying the people, companies, and other relevant parties

BO data should be able to describe all entities declaring under a given BOT regime, and it should be sufficiently flexible to incorporate all legal entities and arrangements that may be disclosed as part of a declaration. BO data must define and structure the fields needed to describe and identify the natural persons, legal entities, and arrangements involved in BOT disclosures. There are two complementary approaches to this:

  1. Requiring the use of unique, permanent, and resolvable identifiers to allow the unambiguous identification of human and non-human entities involved in BOT processes.[56] Identifiers should have meaningful value to users of the data, including, for example, authorities from other jurisdictions.

    Examples of identifiers include a company number issued by a known corporate register, a national identity number from a specific jurisdiction, or an internally generated identifier for a beneficial owner.[57] Identifiers allow for the efficient and confident use of datasets, reducing the need for data cleaning and freeing up resources for high-value analysis. However, a relevant identifier must be available and, where available, collection, storage, and publication must be appropriate. Therefore, the collection of identifiers should be a priority and considered in context, for example, by prioritising the collection of identifiers associated with domestic beneficial owners or choosing to only publish internally generated identifiers to support deduplication.

    It can be difficult to find unique identifiers for non-domestic individuals or companies. For example, Canada has the Social Insurance Number (SIN), but foreigners who are not working in the country do not have SINs. The Province of British Columbia’s register for the beneficial ownership of land therefore does not ask foreign citizens for a different identifier from their home country because they have no way of validating it.

    An approach could be to include some process by which a foreign individual is assigned a new identifier through compulsory registration (e.g. at the point of incorporating a company or buying real estate), or is required to acquire an existing identifier – for example, in the case of Canada, by registering with the tax authority for a Social Insurance Number. Another approach is the creation of a new internally generated identifier, as proposed in the US.[58] ​​Internally generated identifiers would lend themselves better to sharing internationally, though they would have less inherent meaningful value without accompanying information.

    Implementers should also be mindful that existing unique identifiers may not always be permanent for individuals or companies, for example, in the event that two companies merge.

  2. Requiring the use of descriptive data fields that allow the probabilistic identification of human and non-human entities involved in BOT processes. Examples of descriptive data fields include: names, date of birth, nationalities, and contact details for natural persons; and name, jurisdiction of incorporation, entity type, addresses, and phone numbers for registered entities. Descriptive data fields are useful in the absence of identifiers and when datasets from two sources need to be linked but have no shared identifiers. In both cases, entities can be reconciled using probabilistic approaches.[59] Wherever possible, descriptive data fields should be seen as an addition to, not a replacement for, unique identifiers in data, and should conform to standardised formats.

Whilst these approaches relate to data collection and storage, it should be noted that for the purpose of limiting the risks that may arise from the publication of information, publishers are often unable to publish unique identity documents (IDs) for natural persons that constitute sensitive data, such as personal ID, tax identification, or social security numbers, which increase the risk of identity theft when published. Therefore, jurisdictions often implement a system of layered access, where a smaller subset of the data is made available to the public.[60] In order to publish the minimum but sufficient number of details for the public to use the data, descriptive data fields are often made available, meaning both complementary approaches are required.

Establishing what needs to be disclosed based on a particular declaration regime can be complex from a technical point of view, and it can also be limited by privacy and data protection legislation (see, for example, Box 7).[61]

Box 7. Collecting information on gender and sex as part of beneficial ownership disclosures

Gender and sex data constitutes sensitive personal data in some data protection regimes, meaning there is a higher legal threshold for processing it. In line with data protection principles, governments should not collect more information than is necessary to meet a specific purpose. The purpose of collecting personal data as part of BO disclosures is to unambiguously identify individuals. In most cases, data about gender and sex is not necessarily required to do this.

However, OO research found that collecting this data as part of BO disclosures may be particularly relevant where women have reduced access to official IDs.[62] If BO disclosure regimes rely on collecting copies of IDs to unambiguously identify beneficial owners, for example, this may present a barrier to women becoming beneficial owners, especially if this information must be disclosed at the point of incorporating a company.

Where an individual does not have access to an official, individual ID, the collection of sex data can support identification of the actual owner of a company. This can also be relevant in contexts where gender-neutral names are common. Implementers should define a purpose and establish a legal basis for the collection of all personal data in law.

Describing the relationships between parties

BO data must define the fields and structures needed to describe relationships between natural persons, legal entities, and legal arrangements involved in BOT declarations. At a minimum, the data must establish a link between a beneficial owner and the declaring entity associated with a particular disclosure. The details of the data disclosed about a relationship between parties will then depend on the declaration regime.

There are two main areas where data must be defined:

  1. The level of detail required on the chain of ownership between the declaring company and the beneficial owner. This can range from disclosing only the beneficial owner to disclosing the entire ownership chain as structured data.[f]
  2. The level of detail required on interests through which ownership or control is exerted. This includes describing the types of interests held (e.g. voting rights through shares or ownership through a nominee); the level of interests (e.g. in the case of shareholdings); details on specific types of ownership and ways individuals can derive economic benefits; control required by a disclosure regime (e.g. structured disclosure of interests held in state-owned enterprises); and when the ownership and control relationship begins and ends. Information about the details should also be structured to be useful and usable, and ownership and control should not be structured at a high level of abstraction which obfuscates these details (see Box 8).

Box 8. Example of a data structure publishing insufficient detail on ownership and control relationships

In the following hypothetical example, a fictional jurisdiction has divided beneficial ownership into categories. For each beneficial owner declaration, the reporting person is required to select a single category of ownership from the list.

Category Description

  • A: Owning directly or indirectly at least 25% of the voting rights, voting shares, or capital of the reporting entity.
  • B: Exercising control over the reporting entity, alone or together with others, through any contract, understanding, relationship, or arrangement.
  • C: Having the ability to elect a majority of the board of directors of the entity.
  • D: Having the ability to exert a dominant influence over the management or policies of the entity.
  • E: Having the ability to influence the majority of the members of the board of directors of the entity de jure or de facto.
  • F: Exercising stewardship over the assets of the entity.
  • G: Owning or controlling the reporting entity through nominee shareholders or nominee directors.
  • H: Owning or controlling the entity through other means.

When, for example, BO data about John Smith exercising beneficial ownership over an entity through a nominee shareholder is exported from the system as structured data, it appears in the following way:

{
[...]
"beneficialOwnerFullName": "John Smith";
"beneficialOwnerCategory": "G"
[...]
}

Whilst at face value this may appear to be the publication of structured data, this is an example where the level of abstraction is too high. A number of important details to understand ownership and control are obscured by each category. This information needs to be cached out and published as structured data. For example, for category G, the form does not capture information on who the nominee is. Information should be collected about the nominee as an additional node through which the beneficial owner exercises control. Sufficient details should be published about the beneficial owner, the nominee, and the ownership control relationship between them. In addition, the categories of ownership and control are not mutually exclusive. An individual may fall into multiple categories, or use a nominee arrangement (category G) to exert a dominant influence over the management or policies of the entity (category D).

Ensuring that beneficial ownership disclosures are auditable

For BO data to be useful, it should be functionally auditable. Auditability can be thought of on three levels:[63]

  1. Storing a full historical record of all BO information,[64] including a ledger of all changes, reduces the risk of manipulation and increases the integrity of the system overall. This means collecting, storing, and publishing time-related and administrative information. Examples of such data include: the date on which a declaration was submitted; the dates that relationships begin and end; and the publication of annual statements confirming existing data. It is important to consider temporal data early on. The need for it may have to be inferred from laws and regulations.
  2. Providing transparency about when and why data is missing, unknown, or redacted so that BO data can be understood unambiguously. This includes, for example, information on whether and where an application has been granted for the individual’s data to be protected from public disclosure as part of a protection regime;[65] information on whether a public company is eligible for an exemption to disclosure because its exchange meets certain transparency and disclosure requirements;[66] or situations in which no beneficial ownership is reported, either because no individual meets the definition or because no beneficial ownership could be found.[67]
  3. Reducing practical barriers to access and analyse BO data through decisions over data publication formats, access rules, and standardisation.

Designing systems to collect, store, and share beneficial ownership data

Digital systems and administrative processes need to fit together smoothly to enable BO information to be collected, stored, maintained, exchanged, and published. Implementers should make sure when designing systems and business processes that these underpin and support the aims of reforms on a technical level. Practically, implementers should consider:

  • Making sure BOT policy needs are central to decisions over system architectures and database design, and that both take into account the particular characteristics of BO data as outlined above. It is essential that implementers ensure at this stage that the design of the database can meet the querying and data access expected at publication stage.[68] For example, will the database design allow users to query all companies owned or controlled by a natural person? Inadequate design at this stage will restrict potential use cases further down the line.
  • Taking a digital-first approach to systems design and taking advantage of digital techniques, for instance, to improve data quality and reliability by validating information at the point of making a declaration.
  • Ensuring that approaches to data collection, storage, and sharing conform to the intent of BOT regulations. Creating structured data requires resolving the ambiguity that can exist in untested regulation and guidance. This is best done at the design (e.g. forms) and specification stage, and through collaboration with the appropriate agencies.[69]
  • Ensuring that any necessary business process information is generated, collected, and retained. Collecting, storing, and analysing such information can provide valuable insight into the integrity of a BOT disclosure system. Examples of information that implementers may find valuable to collect include: details of authorised intermediaries involved in submission of data, such as company formation agents; key dates associated with the submission, verification, and publication process; internal identifiers for processes and individuals; and internal access logs where this may be required by internal policies.[g]

Realising potential and resolving uncertainty at the publication stage

Making BO data available to the public as open data expands the group of potential data users, which may contribute to various BOT policy aims by making the data available to them in a way that removes potential barriers to use and access by resolving uncertainty.[70] In order to make the data accessible, comprehensible, and usable for others, implementers should consider:

  • using open standards for publishing and structuring BO data; and
  • ensuring auditability of published data by providing access to the data in different formats, including historical data, with an appropriate licence, accompanying documentation, and publication policy.

Open standards

Open standards are standards that are freely available for adoption, implementation, and updates. Open standards can apply to how data should be produced as well as the format in which the data is published. A machine-readable, open, and industry-standard format is recommended. Comma-separated values (CSV) is a good choice for tabular data, although most BO data is hierarchical in nature. If there is nesting to the data structure, CSV can be challenging to represent the information in a way that does not lead people to mistakenly connect information, or in a way that is larger than needed due to duplication. JavaScript Object Notation (JSON) is an open standard file format that has established itself as a good choice for hierarchical data. It has become the de facto standard for communicating over the internet. However, it is harder to work with for analysts. Therefore, ideally, users should be provided with a choice of formats.

Open standards can also apply to the way that BO data is structured as a whole. BODS allows users to publish information about BO in a particular template (see Box 9). Using an open standard provides a high degree of interoperability with other datasets and allows users to integrate data with existing systems, tools, and workflows.[71]

Finally, open standards can apply to individual fields in the data and can also apply to choices of how particular data fields are formatted. For example, dates should be formatted according to an agreed and documented standard, such as ISO 8601.[72] Company identifiers can also be disambiguated using a standard. There are several ways to do this. For example, org-id.guide prefixes local company numbers with a registry identifier.[73] LEI is a global identifier provided in addition to a local company number.[74]

Box 9. The Beneficial Ownership Data Standard [75]

BODS provides a structured data format, along with guidance for collecting, sharing, and using data on beneficial ownership. It is developed by OO in partnership with Open Data Services.[76]

The data schema describes how data about the beneficial owners of a legal entity can be organised and shared. The schema is defined in JSON-structured data format.[77] ​​Using this format facilitates computerised access and analysis of the data, whilst also providing human-readable data. The schema can also be used to inform the design of data collection and management systems, whilst the accompanying technical guidance provides support for publishers and users of the data.

BODS is well defined, yet flexible. National registers of beneficial ownership can use it, as can people researching or describing corporate structures. Data from different jurisdictions published in BODS can be readily joined together to visualise transnational ownership structures.

At the time of writing, BODS is in version 0.3 and being implemented by Armenia, Latvia, and Nigeria.[78] The UK’s Data Standards Authority has endorsed BODS to be used for the collection, exchange, use, and distribution of BO data by the government.[79] In addition, private sector register software providers have begun to build BODS directly into their products, and they are deploying this in jurisdictions.[80]

Ensuring auditability of published data

Implementers can ensure published data is auditable – ensuring it is easy to access, interpret, and use – by providing multiple ways to access the data.[h] Different users need to access the same data in different ways, and different use cases require access to the data in different ways. Data should be made available in formats that cater to both non-technical users as well as technical users and systems at scale. This means that publishers should provide multiple ways into the data. This should include:

  • Per-record search via a web interface. Search is the most powerful way to access BO data. Since company data is rarely known perfectly in advance, searches should be as flexible and forgiving as possible and accessibility for the average user should be considered. An example of this is the UK’s CH search, which allows for partial matching in search queries. Data should be searchable by both company and beneficial owner.[81]
  • Browsing records via a web interface. Structured data allows the links between people and companies to be surfaced, which are otherwise not immediately apparent. For example, on the OO Register, an interface will show the beneficial owners of a company. When clicking on an individual beneficial owner, it will also show all other legal entities with which they have BO relationships.
  • Bulk format. Analysis of a whole dataset requires access to all of the records via bulk record download. This can be provided as a regular export from a source system.[i] For example, Ukraine’s Unified State Register of Legal Entities, Individual Entrepreneurs and Public Formations has data publicly and freely available as bulk download, via a file made available daily.[82]
  • API access. An API is an interface that allows two software applications to talk to each other. Any programmatic analysis or machine-to-machine usage of BO data is likely to rely on web APIs, a way of making structured requests for information over the internet. Consideration should be given to how heavy use of APIs will be managed, including through the use of commercial agreements. In a post-implementation review of the UK’s BO register, access by API and bulk access were noted as generating the greatest user value.[83]

For each of these ways to access data, registers should also ensure auditability by providing access to a historical record of changes to beneficial ownership in the data.

For data to be used with confidence, it needs to have a licence. Using a licence that meets the Open Definition can facilitate the greatest use of data, but decisions around licensing need to be attuned to each local context.[84] Domestic data protection and privacy legislation may need to be considered, and they may have a bearing on licensing decisions. Many countries with disclosure regimes do not make information about their licensing available, undermining confidence in data use. A number of countries publish BO information as open data, including Denmark, Latvia, Nigeria, the UK, and Ukraine.[85]

Finally, data should be accompanied by the necessary context and documentation in order to be useful. A publication policy – or data use guide – allows users to contextualise, make sense of, and plan for the reuse of BO data. A publication policy may include details of licensing; links to relevant legislation and regulation; policies on timeliness of data publications; and a log of substantive changes to the data (technical or in response to changes in legislation and regulation) so that users can understand discontinuities in historical data series. A data user guide should provide users with the information needed to access, analyse, and make use of BO data. This may include both formal documentation and less formal guides and tutorials.

Foot notes

[f] OO’s sufficient detail principle states that sufficient information should be collected to understand full ownership chains. Visibility of full ownership chains might rely on collating information from declarations of partial ownership chains made by different, related entities. In order to understand and determine what level of detail is required, OO has published a BO disclosure workbook: Kadie Armstrong, “Beneficial ownership disclosure workbook”, Open Ownership, June 2021, https://www.openownership.org/en/publications/beneficial-ownership-disclosure-workbook.

[g] Whilst there has been no comprehensive review on the utility of internal access logs, some domestic legislation, as in the US, may require this: Adam Smith, “William M. (Mac) Thornberry National Defense Authorization Act for Fiscal Year 2021”, 116th United States Congress, 1 January 2021, 1241, https://www.congress.gov/116/bills/hr6395/BILLS-116hr6395enr.pdf.

[h] The ways to access data outlined here also apply to internal government users, even if the data is not made publicly available in all formats. For example, although a number of countries have done so without documented issues, some governments may not make bulk data available to the public out of privacy concerns. In this case, bulk data should still be available to law enforcement for proactive investigations.

[i] An alternative approach is to provide users with access to a streaming API that allows the current (or any) state of the dataset to be constructed by users from the stream of changes pushed to the API by the publisher. This is more flexible and powerful, and it may be more suitable for large BO datasets in the long run, but it is also more complex to use and implement.

End notes

[51] Thom Townsend, “Effective consultation processes for beneficial ownership transparency reform”, Open Ownership, 20 June 2020, 12, https://www.openownership.org/en/publications/effective-consultation-processes-for-beneficial-ownership-transparency-reform.

[52] “Open Ownership Principles”, Open Ownership.

[53] For more information, see: Ramandeep Kaur Chhina and Tymon Kiepe, “Designing sanctions and their enforcement for beneficial ownership disclosure”, Open Ownership, 28 April 2022, https://www.openownership.org/en/publications/designing-sanctions-and-their-enforcement-for-beneficial-ownership-disclosure.

[54] For more details on implementing layered access and protection regimes, see: Kiepe, “Making central beneficial ownership registers public”, 17-19.

[55] See: “How to make a business case for open data”, Open Data Institute, 20 October 2013, https://theodi.org/article/how-to-make-a-business-case-for-open-data; “Research: The economic value of open versus paid data”, Open Data Institute, 20 April 2016, https://theodi.org/article/research-the-economic-value-of-open-versus-paid-data; Kiepe, “Making central beneficial ownership registers public”, 4. For methodologies on measuring the economic benefits of BOT reforms, see: “Measuring the economic impact of beneficial ownership transparency”, Lateral Economics et al.

[56] “Why do open organisational identifiers matter?”, Open Data Services, Medium, 13 April 2022, https://medium.com/opendatacoop/why-do-open-organisational-identifiers-matter-46af05ab30a; Deborah Yates, “Sustainable stewardship of open identifiers”, Open Data Institute, 7 September 2021, https://theodi.org/article/sustainable-stewardship-of-open-identifiers.

[57] “Real world identifiers”, Open Ownership, n.d., https://standard.openownership.org/en/latest/schema/guidance/identifiers.html.

[58] “Fact Sheet: Beneficial Ownership Information Reporting Notice of Proposed Rulemaking (NPRM)”, Financial Crimes Enforcement Network, US Treasury, 7 December 2021, https://www.fincen.gov/news/news-releases/fact-sheet-beneficial-ownership-information-reporting-notice-proposed-rulemaking.

[59] See, for example, the UK Ministry of Justice’s data repository using probabilistic record linkage and deduplication at scale: “moj-analytical-services/splink: Fast, accurate and scalable probabilistic data linkage using your choice of SQL backend”, GitHub, n.d., https://github.com/moj-analytical-services/splink. This was used by the UK Competition and Market Authority to link records and assign unique identifiers to UK BO data; see: Open Ownership, “Open Ownership technology showcase #4”.

[60] For more information on layered access, see: Kiepe, “Making central beneficial ownership registers public”, 17.

[61] See: “Open Ownership Principles – Sufficient detail”, Open Ownership, updated July 2021, https://www.openownership.org/en/principles/sufficient-detail; “​​Beneficial ownership declaration forms: Guide for regulators and designers”, Open Ownership, 17 March 2021, https://www.openownership.org/en/publications/beneficial-ownership-declaration-forms-guide-for-regulators-and-designers.

[62] Lubumbe Van de Velde, “Gender and beneficial ownership transparency”, Open Ownership, 28 April 2022, https://www.openownership.org/en/publications/gender-and-beneficial-ownership-transparency.

[63] For more information, see: Kadie Armstrong, “Building an auditable record of beneficial ownership”, Open Ownership, forthcoming.

[64] See: “Open Ownership Principles – Up to date and auditable”, Open Ownership, updated July 2021, https://www.openownership.org/en/principles/up-to-date-and-auditable.

[65] See: Kiepe, “Making central beneficial ownership registers public”, 19.

[66] Kadie Armstrong and Jack Lord, “Beneficial ownership transparency and listed companies”, Open Ownership, 17 September 2020, https://www.openownership.org/en/publications/beneficial-ownership-transparency-and-listed-companies; “Open Ownership Principles – Comprehensive coverage”, Open Ownership, updated July 2021, https://www.openownership.org/en/principles/comprehensive-coverage.

[67] For more information, see: “​​Beneficial ownership declaration forms”, Open Ownership.

[68] For more information and detailed technical guidance, see: “Relational database design considerations for beneficial ownership information”, Extractive Industries Transparency Initiative and Open Ownership.

[69] For technical guidance on disclosure scope and reviewing forms, and more detail on resolving these issues, see: “​​Beneficial ownership declaration forms”, Open Ownership.

[70] Kiepe, “Making central beneficial ownership registers public”.

[71] “Beneficial Ownership Data Standard (v0.3)”, Open Ownership.

[72] “ISO 8601 – Date and time format”, International Organization for Standardization.

[73] “org-id.guide - list locator (Alpha)”, org-id.guide.

[74] “Global LEI Index”, Global Legal Entity Identifier Foundation.

[75] “Beneficial Ownership Data Standard (v0.3)”, Open Ownership.

[76] “We help people publish and use open data”, Open Data Services, n.d., https://opendataservices.coop.

[77] “Beneficial Ownership Data Standard – Schema browser”, Open Ownership, n.d., https://standard.openownership.org/en/0.3.0/schema/schema-browser.html.

[78] Stephen Abbott Pugh, “Launch of version 0.3 of the Beneficial Ownership Data Standard”, Open Ownership, 20 June 2022, https://www.openownership.org/en/news/launch-of-version-03-of-the-beneficial-ownership-data-standard.

[79] “Collect, use and exchange beneficial ownership information”, UK Cabinet Office, updated 16 March 2022, https://www.gov.uk/government/publications/open-standards-for-government/collect-use-and-exchange-beneficial-ownership-information.

[80] See, for example: “Beneficial Ownership Register”, Foster Moore, n.d., https://www.fostermoore.com/verne/beneficial-ownership-register.

[81] See: “Open Ownership Principles – Public access”, Open Ownership, updated July 2021, https://www.openownership.org/en/principles/public-access.

[82] “Ukraine Consolidated State Registry (Edinyy Derzhavnyj Reestr [EDR])”, Open Ownership, n.d., https://register.openownership.org/data_sources/ua-edr-register. Since the Russian invasion of Ukraine in February 2022, the Ukrainian BO register has been offline.

[83] “Valuing the user benefits of Companies House data – Report 2: Direct Users”, BEIS, 24. For more information, see: “Measuring the economic impact of beneficial ownership transparency”, Lateral Economics et al.

[84] “The Open Definition”, Open Knowledge Foundation, n.d., https://opendefinition.org. See: Kiepe, “Making central beneficial ownership registers public”.

[85] See indicator A.COMPANY.BOT.e.e3.LICENSE in “GDB full dataset”, Global Data Barometer, 2021, https://storage.googleapis.com/gdb-files/modules/gdb-2021-company-information-module-data.csv. For example, “Vilkår for brug af danske offentlige data”, Erhvervsstyrelsen, 10 March 2015, https://hjaelp.virk.dk/sites/default/files/vilkaar_for_brug_af_danske_offentlige_data_v4.pdf;

Next page: Conclusion