Beneficial Ownership Data Standard (beta)¶
Warning
This is an old version of the data standard. See latest version.
This site contains documentation site for the beta version of the Beneficial Ownership Data Standard, developed as part of the OpenOwnership project.
This work is taking place under the auspices of the Open Ownership project. More details on the project are avaiable at http://www.openownership.org
The beta schema is documented on the specification pages.
Contents¶
Overview¶
Warning
This is an old version of the data standard. See latest version.
The beneficial ownership data standard will be made up of two parts:
- A data schema that sets out how beneficial ownership data MUST or SHOULD be formatted for interoperability, and that describes the fields of data that systems MUST or SHOULD provide.
- A set of implementation recommendations that describe the way in which beneficial ownership data SHOULD be collected and published.
MUST and SHOULD are used as defined by RFC2119.
This documentation currently contains a draft of the schema, with some initial (though non-exhaustive) implementation recommendations.
Scope¶
The standard is concerned with relationships of ownership and control
The schema will describe relationships between a legal entity such as a company, trust, partnership, or person acting as a nominee, and a natural person. These may be direct relationships, or may be indirect through intermediate legal entities.
Ownership is understood as “the right to receive profits, income, interest, etc. from a property or investment” (NOTE: Definition of “beneficial ownership” from the Cambridge Business English Dictionary) and may operate through a range of mechanisms, including share ownership and contractual rights.
The standard does not set any threshold on levels of shareholding or rights required in order to beneficial ownership to be present, leaving this decision to individual implementers. i.e. it will be possible to represent shareholdings of 0.1% or less using the standard, but individual implementers may choose to set thresholds for the levels of ownership they will require before they collect, produce or consume such data.
Control is understood as the ability to direct or influence the actions of a legal entity, and may operate through a range of mechanisms, including, but not limited to, ownership of shares with voting rights, or contractual agreements.
As with ownership, the standard does not set any threshold on levels of control that can be represented.
We use the concept of beneficial ownership to cover both ownership (economic benefit) and control.
Relationships of ownership and control may be direct, indirect, operating through intermediate entities, or may be declared as ultimate beneficial ownership, without information on whether the relationship is direct or indirect.
In cases of indirect relationships, the schema will support inclusion of the intermediate relationships between legal entities. E.g. information on company ownership structures will be captured within the scope of the standard. The implementation guidance will recommend that this information is collected and published wherever possible.
In order to allow clear identification of beneficial owners the schema will provide means of describing attributes of natural persons, including, but not limited to, their name, nationality, country of residence, date of birth, and any public identification numbers.
Where particular information cannot be published for legal or privacy reasons, the implementation guidance will recommend placeholder entries are published, with reasons for non-publication or redaction clearly explained using the schema.
The schema does not seek to provide globally unique identifiers to natural persons or legal entities, though it will allow reuse of existing identifiers. Consuming applications will be required to perform their own matching and deduplication on both legal entity and natural person components where their use-cases require this.
In order allow clear identification of the entities owned or controlled, or involved in indirect ownership and control chains, the schema will provide means of describing the attributes of legal entities, including the nature of the entity, names, addresses and registration details.
Complex arrangements, such as trusts, consortia, and individuals acting as a nominee for another, will be included within the definition of a legal entity.
The schema will incorporate provenance information for ownership and control statements, and for descriptions of legal entities and natural persons. This will include links to documents that provide evidence for statements made. Such documents will need to be stored externally.
The schema is intended for exchange of open data. Data publishers and consumers will need to independently consider the legal regime around the publication or use of any personally identifying information covered by the standard.
The implementation guidance will describe how to provide bulk data and API access to aggregated beneficial ownership information. It will not describe advanced API patterns such as querying, or retrieval of a sub-set of all records (with the exception of fetching all records changed since a given date).
Using the standard¶
The standard is currently in draft form.
It can be used to:
- Guide the design of beneficial ownership data collection;
- Guide the publication of structured data on beneficial ownership.
Supporting resources¶
ToDo
Use cases¶
Warning
This is an old version of the data standard. See latest version.
The Beneficial Ownership Data Standard beta has been designed with reference to the requirements of eight use-cases:
- Data supply
- Public Registers of Beneficial Ownership
- Self-submitted data
- Third-party submitted data
- Self-published data
- Data use
- Procurement & onboarding screening and audit
- General investigations
- Data-led investigations
- Data validation
These use cases are described below.
Note
A full analysis of how far the needs of these use cases are met will take place as part of progress towards a 1.0 Release Candidate of the standard.
This page builds on the use case consultation document published in December 2016.
Data supply¶
The following cases sketch out ways in which open beneficial ownership data might be published.
S1: Public Registers of Beneficial Ownership¶
A government or other body creating a public register of beneficial ownership may want to publish that information as open data that others can draw on and re-use. This may include publishing bulk data, or providing an API on the data.
The data that the register should contain is likely to be determined by national legislation, and there may be existing national guidance on how to develop open data services or APIs.
Organisations building a register may also be interested in using the standard to help design their internal data models and data collection processes.
Possible examples of this case may include the UK Register of Persons of Significant Control, the Ukraine Beneficial Ownership Register, the planned register of beneficial ownership in France, and sector-specific registers from the Extractives Industry Transparency Initiative.
S2: Self-submitted data¶
An individual or an organisation may make use of online tools to self-report beneficial ownership information.
For example, Who Controls It was a proof-of-concept Beneficial Ownership platform (a precursor to OpenOwnership.org), designed to test some of the UI issues in the submission of beneficial ownership data, allowing users to declare their own ownership of a company, or to report on the ownership structure of a company.
There are many complex cases a comprehensive system should be able to deal with, including:
- Recording economics interests, but without control (e.g. 1% of a mining company, which may be valuable, but give little shareholder power);
- Mutual funds, that separate control (the fund manager) from the economic interest (the entities that put the money in);
- Bonds, preference shares and other investments that don’t give control, but do give economic interests. Note that sometimes they may have some control, such as veto rights, e.g. over mergers or asset sales;
- Control via nominees, particularly when a nominee may act for a number of different parties in control of the same company;
- Contractual control limited to a particular set of circumstances.
The designers of systems capturing self-submitted data may want to use the standard to express the data they have already collected, and to plan the collection of other data in future.
S3: Third-party submitted data¶
Researchers, journalists or corporate information services may use filings, reports and other materials to build up structured data about beneficial ownership.
They may wish to share this data for others to re-use, but with suitable caveats about the sourcing of the data.
S4: Self-published data¶
Companies may wish to publish structured data about their own beneficial ownership on their own websites. This data could be manually curated, or might come from internal information systems. They may be interested in doing this to avoid having to manually enter the information into different systems, so would want the data to be able to be read directly into platforms like OpenOwnership.
The data may be periodically updated at a single URL, or have regular releases of data published as part of an annual reporting process, each time at a new URL.
Data use¶
The following cases look at different ways in which stakeholders may wish to make use of beneficial ownership data.
U1: Procurement & onboarding screening and audit¶
There are a variety of cases related to onboarding, by which we mean the process of establishing relationships with new partners: typically new clients or suppliers (but also joint venture partners, licensees, Mergers & Acquisitions etc). Each of these new relationships exposes the onboarding entity (e.g. government, bank, multinational corporation, etc) to risk (e.g. financial risk, reputational risk, FCPA/Bribery Act risk, sanctions breaches, etc.), and so they need to understand about the entity being onboarded.
Information of ownership and control is typically collected by onboarding entities who then assess the validity of information provided by cross checking with supplementary data available in open sources. In high value / high risk transactions, third parties are often employed to support due diligence processes. Onboarding entities are looking for red flags (e.g. whether the company is connected with Politically Exposed Persons or has earned negative media), and for confidence that there are no red flags they are missing (e.g. that a Beneficial Owner is connected with a company on a sanctions list). Following an assessment of risks, an informed judgement call typically determines whether new partnerships or transactions meet the policy requirements of the business.
As part of an onboarding process, beneficial ownership information might be integrated alongside other ‘Know Your Customer/Client’ information and systems. In some cases, having access to documentary evidence to back up each piece of information given from a beneficial ownership dataset will be important.
Example user story: A procurement officer at a multilateral development bank has to approve the application of a new supplier. They need to ensure that the company is not on sanctions lists, that the ‘beneficial owners’ are not PEPs, and that they are not on debarment lists.
U2: General investigations¶
There are a number of parties that need to investigate specific companies or individuals (as opposed to doing data-led investigations/mappings).
These include:
- Journalists - researching stories on a particular company, individual or group of companies
- NGO anti-corruption investigation - finding leads, following them
- Law enforcement - looking to establish a clear evidence base, and seeking to establish proof of intent
- Asset recovery - recovering money/assets that are due to a client, for example Stolen Assets, proceeds of fraud, or assets hidden in divorce settlements
In many ways the processes around such investigations are very similar, and are less dependent on on who is doing the investigation, and more about the resources that they have. For example some professional investigative journalists and even NGOs will have access to proprietary datasets, whereas many law enforcement officers won’t; some lawyers performing asset recovery will be able to ask the courts to expose otherwise hidden data (e.g. dollar transactions). Nevertheless, all are looking for leads they can follow, and in particular public leads (in the case of journalists, or NGOs this is possibly all they have access to or can afford; in the case of law enforcement, lying in public proves intent).
Tax and accounting investigations are similar, but may be more focused on corporate structures and direct relationships rather than indirect and ultimate relationships
Example user story: A journalist is investigating a politician including looking at known associates and companies, in both the home country and other jurisdictions.
U3: Data-led investigations¶
As well as targeted and general purpose investigations, where there is a specific target for the investigation or a lead that is being pursued, there are also data-led investigations, which work by analysis or mining the data as a whole, or combining the data with other datasets. Examples would be mapping beneficial ownership data to procurement data (for conflict of interest mapping), as well as mapping to similar data such as shareholder data from company registers.
To give an example user story: Data journalists wish to find anomalies between beneficial ownership disclosures and other public records, to identify lies
U4: Data validation¶
Systems collecting beneficial ownership data can benefit from checking the data they receive against data from other systems. In existing work, there have been cases where reports under the EITI templates have not matched with reports to the UK Register of Persons with Significant Control.
To give an example user story: *National EITI groups may wish to check reported information against data from national beneficial ownership registers where those exist, and to be able to address inaccuracies with the reporting parties. *
Specification¶
Warning
This is an old version of the data standard. See latest version.
The beneficial ownership standard is made up of two parts:
- A data schema that sets out how beneficial ownership data MUST or SHOULD be formatted for interoperability, and that describes the fields of data that systems MUST or SHOULD provide.
- A set of implementation recommendations that describe the way in which beneficial ownership data SHOULD be collected and published.
Attention
This is the beta of the schema. This version is ready for test implementations.
Implementers should be aware that future changes are anticipated, before a version 1.0 release. However, from this beta release onwards, any structural changes, or major definitional changes will only take place following consultation, with a clear changelog provided, and with the documentation of previous versions maintained in archive form.
The schema contains a draft structure and fields but does not yet specify substantial constraints or explicit required fields.
Conceptual model¶
The conceptual model for the standard was developed in late 2016/early 2017 and is documented here.
We model information on beneficial ownership in terms of a collection of statements. Each statement represents the assertions made by a particular agent at a particular point in time.
It is up to data consumers to decide which statements to trust, and to reconcile the identity of the entities and persons described in those statements based on the identifying information contained within each statement.
This abstraction is important to represent the reality of how data is provided, to support integration of data from different systems and bi-temporal modelling, and to recognise that any dataset may contain overlapping or conflicting claims about ownership and control that need to be resolved in application specific ways.
Schema browser¶
The draft Beneficial Ownership Data Standard is defined using JSON Schema 0.4. The structured schema can be accessed here or explored using the viewer below.
Serializations¶
We have currently modelled the schema with the option for:
- (1) Entity, person and provenance statements to be nested inside a beneficial ownership statement;
- (2) Each kind of statement to be provided at the same level of heiarchy, with a cross-reference between them;
This second option is sketched out with a view of serialisations that may make use of the JSON Lines format for sharing or streaming large quantities of statements, rather than enclosing all statements ot be exchanged in a single object.
Sections¶
The following tables are generated from the schema, and outline the different components of the data model.
Statement Groups¶
At the top level of any structured file is always an array of statementGroups.
| Field Name | Description | Format |
|---|---|---|
| statementGroups | Statement group: A statement group is used to collect together statements relating to a particular disclosure, company or individual. Statement groups are a logical grouping designed to limit duplication of provenance information, and bring together statements that contain cross references. Where statements in a statementGroup cross-references to other statements, those statements MUST also be contained within the group. | Array |
Each statementGroup MUST include an array of one or more beneficialOwnershipStatements and, where a cross-reference publication pattern is followed, may include arrays of other statements.
BeneficialOwnershipStatement¶
A beneficial ownership statement is made up of statements about an entity, an interestedParty (either an entity, a person or null party), and details of the interest. Additionally, annotations on the interest, provenance and versioning information can be provided.
| Field Name | Description | Format |
|---|---|---|
| id | See ID | Object |
| statementDate | See StatementDate | Object |
| entity | Entity: This entity is the subject of a beneficial ownership relationship. One of EntityStatementReference or EntityStatement | |
| interestedParty | Interested party: The interested party has some level of ownership or control over the entity referenced in this beneficial ownership statement. One of EntityStatement or PersonStatement or NullParty or EntityStatementReference or PersonStatementReference | |
| interests | Interests: A description of the interests held by the interestedParty covered by this statement in the entity covered by this statement. See Interest section for further details. | Object Array |
| source | Source: The source of the information that links the entity and the interested party, or that supports a null statement. See Source | Object |
| replacesStatement | See ReplacesStatement | Object |
Interest¶
| Field Name | Description | Format |
|---|---|---|
| type | Type of interest: A codelist value indicating the nature of the interest. Codelist options: [shareholding, voting-rights, appointment-of-board, influence-or-control] |
string enum (codelist) |
| interestLevel | Interest level: Is this interest held directly or indirectly? Codelist options: [direct, indirect, unknown] |
string enum (codelist) |
| details | Details: This field may be used to provide the local name given to this kind of interest, or any further semi-structured or unstructured information to clarify the nature of the interest held. | string |
| annotations | Annotations: Any further details to qualify this interest. See Annotation section for further details. | Object Array |
| share | Percentage share: Where an exact percentage is available, this should be given, and maximum and minimum values set to the same as the exact percentage. Otherwise, maximum and minimum can be used to record the range into which the share of this kind of interest falls. See share | Object |
| startDate | State date: When did this interest first occur. Please provide as precise a date as possible in ISO 8601 format. When only the year or year and month is known, these can be given as YYYY or YYYY-MM. | string |
| endDate | End date: When did this interest cease. Please provide as precise a date as possible in ISO 8601 format. When only the year or year and month is known, these can be given as YYYY or YYYY-MM. | string |
Annotation¶
The annotation property currently allows for an array of simple annotation objects. This is a placeholder which could be extended in future to include structured information qualifying the nature of the interest held.
| Field Name | Description | Format |
|---|---|---|
| description | Description: A free-text description to annotate this interest. | string |
EntityStatement¶
| Field Name | Description | Format |
|---|---|---|
| id | See ID | Object |
| statementDate | See StatementDate | Object |
| type | Type: What kind of entity is this? The ‘registeredEntity’ code covers any legal entity created through an act of official registration, usually resulting in an identifier being assigned to the entity. The ‘legalEntity’ code covers other bodies with distinct legal personality (government departments, international institutions etc.). The ‘arrangement’ code covers artificial entities, described in the data model for the purpose of associating one or more natural or legal persons together in an ownership or control relationship, but without implying that the parties to this arrangement have any other form of collective legal identity. Codelist options: [registeredEntity, legalEntity, arrangement, anonymousEntity, unknownEntity] |
string enum (codelist) |
| missingInfoReason | Missing information reason(s): For EntityStatements with the type ‘anonymousEntity’ or ‘unknownEntity’ this field should contain an explanation of the reason that detailed information on the entity is not provided. This may be a standard descriptive phrase from the source system, or a free-text justification. | string |
| name | Name: The declared name of this entity. | string |
| jurisdiction | Jurisdiction: The jurisdiction in which this entity is registered, expressed using an ISO ISO_3166-2 2-Digit country code, or ISO_3166-2 sub-division code, where the sub-division in question (e.g. a sub-national state or region) has relevant jurisdiction over the registration of operation of this entity. | string |
| identifiers | Identifiers: One or more official identifiers for this entity. Where available, official registration numbers should be provided. See Identifier section for further details. | Object Array |
| foundingDate | Created date: When was this entity founded, created or registered. Please provide as precise a date as possible in ISO 8601 format. When only the year or year and month is known, these can be given as YYYY or YYYY-MM. | string |
| dissolutionDate | End date: If this entity is no longer active, provide the date on which it was disolved or ceased. Please provide as precise a date as possible in ISO 8601 format. When only the year or year and month is known, these can be given as YYYY or YYYY-MM. | string |
| addresses | Addresses: One or more addresses for this entity. See Address section for further details. | Object Array |
| uri | URI: Where a persistent URI is available for this entity this should be included. | uri string |
| source | Source: The source of information about this entity. See Source | Object |
| replacesStatement | See ReplacesStatement | Object |
PersonStatement¶
| Field Name | Description | Format |
|---|---|---|
| id | See ID | Object |
| statementDate | See StatementDate | Object |
| type | Type: The ultimate beneficial owner of a legal entity is always a natural person. Where the beneficial owner has been identified, by information about them cannot be disclosed, use ‘anonymousPerson’. Where the beneficial owner has not been clearly identified, use ‘unknownPerson’. Codelist options: [naturalPerson, anonymousPerson, unknownPerson] |
string enum (codelist) |
| missingInfoReason | Missing information reason(s): For PersonStatements with the type ‘anonymousPerson’ or ‘unknownPerson’ this field should contain an explanation of the reason that detailed information on the person is not provided. This may be a standard descriptive phrase from the source system, or a free-text justification. | string |
| name | Name: The full name of this person. | string |
| alternateNames | Alternate names: Other known names for this individual. See AlternateName section for further details. | Object Array |
| identifiers | Identifiers: One or more official identifiers for this perrson. Where available, official registration numbers should be provided. See Identifier section for further details. | Object Array |
| nationalities | Nationality: An array of ISO 2-Digit country codes representing nationalities held by this individual. | Array |
| placeOfResidence | See Address | Object |
| placeOfBirth | See Address | Object |
| birthDate | Created date: The date of birth for this individual. Please provide as precise a date as possible in ISO 8601 format. When only the year or year and month is known, these can be given as YYYY or YYYY-MM. | string |
| deathDate | End date: If this individual is no longer alive, provide their date of death. Please provide as precise a date as possible in ISO 8601 format. When only the year or year and month is known, these can be given as YYYY or YYYY-MM. | string |
| addresses | Addresses: One or more addresses for this entity. See Address section for further details. | Object Array |
| source | Source: The source of information about this person. See Source | Object |
| replacesStatement | See ReplacesStatement | Object |
AlternateName¶
| Field Name | Description | Format |
|---|---|---|
| type | Type: What kind of alternative name is this? Codelist options: [detailed, translation, former, alias, birth] |
string enum (codelist) |
| fullName | Full name: The full name contains the complete name of a person as one string. | string |
| familyName | Family name: A family name is usually shared by members of a family. This attribute also carries prefixes or suffixes which are part of the Family Name, e.g. ‘de Boer’, ‘van de Putte’, ‘von und zu Orlow’. Multiple family names, such as are commonly found in Hispanic countries, are recorded in the single Family Name field so that, for example, Miguel de Cervantes Saavedra’s Family Name would be recorded as ‘Cervantes Saavedra.’ | string |
| givenName | Given names: A given name, or multiple given names, are the denominator(s) that identify an individual within a family. These are given to a person by his or her parents at birth or may be legally recognised as ‘given names’ through a formal process. All given names are ordered in one field so that, for example, the given name for Johann Sebastian Bach is ‘Johann Sebastian.’ | string |
| patronymicName | Patronymic Name: Patronymic names are important in some countries. Iceland does not have a concept of family name in the way that many other European countries do, for example. In Bulgaria and Russia, patronymic names are in every day usage, for example, the ‘Sergeyevich’ in ‘Mikhail Sergeyevich Gorbachev’ | string |
NullParty¶
| Field Name | Description | Format |
|---|---|---|
| type | Reason: The reason for this null statement. Codelist options: [unknown, noBeneficialOwners, noNotifiableOwners] |
string enum (codelist) |
| description | Description: Any supporting information about the absence of a confirmed beneficial owner. This field may be used to provide set phrases from a source system, or for a free-text explanation. | string |
Source¶
See the provenance pages for a discussion of provenance modelling.
| Field Name | Description | Format |
|---|---|---|
| type | Source type: What type of source is this? Multiple tags can be combined. Codelist options: [selfDeclaration, officialRegister, thirdParty, primaryResearch, verified] |
array enum (codelist) |
| description | Description: Where required, additional free-text information about the source of this statement can be provided here. | string |
| url | Source URL: If this information was fetched from an external URL, or a machine or human readable web page is available that provides addition information on how this statement was sourced, provide the URL. | string |
| retrievedAt | Retrieved at: If this statement was imported from some external system, include a timestamp indicating when this took place. The statement’s own date should be set based on the source information. | datetime string |
| assertedBy | Asserted by: Who is making this statement? This may be the name of the person or organisation making a self-declaration (in which case, please make sure the name field matches the organisation or person name field), or the name or description of some other party. If this statment has been verified, this may also include the name of the organisation providing verification. See AssertingParty section for further details. | Object Array |
AssertingParty¶
| Field Name | Description | Format |
|---|---|---|
| name | Name: The name of the asserting party | string |
| uri | URI: An optional URI to identify the asserting party. | uri string |
EntityStatementReference¶
| Field Name | Description | Format |
|---|---|---|
| type | Type: What type of statement is being referred to? Codelist options: [entityStatement] |
string enum (codelist) |
| id | ID: The identifier of the statement being referenced. | string |
| uri | URI: A persistent URI for the statement being referenced. | uri string |
PersonStatementReference¶
| Field Name | Description | Format |
|---|---|---|
| type | Type: What type of statement is being referred to? Codelist options: [personStatement] |
string enum (codelist) |
| id | ID: The identifier of the statement being referenced. | string |
| uri | URI: A persistent URI for the statement being referenced. | uri string |
Common components¶
The following components are used at a number of points in the schema
Address¶
Due to the diversity of address formats used across systems, and the extent to which data is inconsistently entered across these data fields in source systems and legacy datasets, the schema uses a very simple address format for data exchange - relying upon consuming systems to parse addresses before carrying out any structured comparison. However, designers of new data collection systems are encouraged to choose an appropriate structured format, with reference to established standards, and awareness of the need to accomodate addresses from across the world. See issue 18 for more details.
| Field Name | Description | Format |
|---|---|---|
| type | Type: What type of address is this? Codelist options: [placeOfBirth, home, residence, registered, service, alternative] |
string enum (codelist) |
| address | Address: The address, with each line or component of the address separated by a line-break or comma. This field may also include the postal code. | string |
| postCode | Postcode: The postal code for this address. | string |
| country | Country: The ISO 2-Digit county code for this address. | string |
Identifier¶
The identifier component is used to connect a statement to the person or entity that it refers to, using one or more existing known identifiers.
| Field Name | Description | Format |
|---|---|---|
| id | ID: The identifier for this entity as provided in the declared scheme. | string |
| scheme | Scheme: For entity statements, the scheme should be a entry from the org-id.guide codelist. For person statements, recognised values include ‘passport’, ‘internal’ and ‘id-card’. | string |
| uri | URI: Where this identifier has a canonical URI this may be included | uri string |
Date¶
See https://github.com/openownership/data-standard/issues/12 for a discussion of handling fuzzy dates.
Our current schema uses a regular expression to allow YYYY, YYYY-MM, YYYY-MM-DD or full datetimes.
ID¶
Publishers MUST generate globally unique and persisent identifiers for each statement.
These SHOULD start with a uuid to avoid any clash between identifiers from different publishers, and MAY be suffixed with additional characters to distinguish versions of a statement as required by local implementations.
In many implementation scenarios, it will be appropriate to simply generate a distinct uuid for each statement.
Publication and use considerations¶
This section outlines considerations for publishers and consumers of the data
Immutability of statements¶
Statements are considered immutable. If a field is updated, this should be considered to create a new statement, with a new identifier.
Updating statements¶
Where a statementGroup or statement replaces a previous statement this should be explicitly declared using a replacesStatementGroup or replacesStatement property.
Identifiers¶
Warning
This is an old version of the data standard. See latest version.
Statement ids¶
Each statement must have a unique id. This id must be globally unique: such that no two statements from the same organisation, or from different organisations, could ever have the same identifier.
Once published, statements must be immutable. This means any time the underlying record changes, a new statement id should be generated.
Suggested strategies for assigning ids to statements include:
- Generating a UUID for each statement, storing this in internal systems, and updating it whenever the relevant record(s) that make up a statement are updated;
- Generating a UUID as a prefix, and appending a local record identifier, and version identifier to it;
- Assigning a URI in a domain controlled by the publisher to each statement.
Whilst the schema is agnostic as to the exact strategy that data publishers use to generate statement ids, it enforces a minimum length of 32 characters (the length of a hexidecimal UUID) in order to avoid use of ids that are likely to fail a uniqueness test.
Identifying people, companies and other entities¶
To create a link between statements, and the real-world organisations and people they relate to, statements may include a range of identifying information. We use a common identifier object, with two required properties, and one optional property.
- scheme must be a value from a codelist of known identifier sources. Separate codelists exist for entities and persons.
- id must be the value assigned to the relevant entity or person in that scheme; ** uri may be used to provide a canonical URI from this scheme.
For example, if a source system holds:
- A registered company number; and
- A VAT number;
for a company, two entries could be created in the entities.identifiers array, as in the example below:
[
{
"scheme":"GB-COH",
"id":"012345678"
},
{
"scheme":"GB-VAT",
"id":"65251235"
}
]
Entity Identifiers¶
The values for scheme within an entity statement identifier should be drawn from the http://org-id.guide codelist.
Where the publisher is providing an internal identifier, the publisher should either:
- Publish their full list of internal identifiers, and register this list with the http://org-id.guide codelist; or
- Use MISC-{Publisher_Name} as the scheme
Person Identifiers¶
The values for scheme within a person statement should be based on the following pattern:
{JURISDICTION}-{TYPE}
Where jurisdiction is expressed using thee extended ISO 3-digit country codes list proposed by in ICAO Document 9303 §5 (pages 22-29).
For example, a passport number from Afghanistan would have the scheme:
AFG-PASSPORT-{NUMBER}
Where the publisher is providing an internal identifier, these should use ‘MISC-{Publisher_Name}’ as the scheme.
Warning
When using BODS to provide open data, it is important to ensure any person identifiers are suitable for publication under national laws and data protection frameworks.
Most of the identifier types listed below are not suitable for publication as part of an open dataset.
The following identification types are currently documented. Suggestions for new types should be made through the issue tracker.
PASSPORT¶
Passport numbers should follow the format of the identifier (second) line in a machine-readable passport (see Appendix B to Part 4 of ICAO Doc 9303) including at least the document number.
Parsers should be able to extract the document number from the first 9 characters, and to access any subsequent information supplied according to the ICAO format.
IDCARD¶
Country ID card systems vary. Where specific guidance on including numbers from a particular jurisdiction is required, this may be included here.
Examples¶
Warning
This is an old version of the data standard. See latest version.
In the tools folder of the schema repository a script is available to generate dummy data, or blank example data files.
The following manually constructed examples highlight key elements of how beneficial ownership statements can be constructed.
A single direct owner¶
The example below represents a single statement, based on a UK PSC disclosure tha asserts 100% ownership of Chrinon Ltd by Chris Taggart.
{
"statementGroups": [
{
"id": "9b57a603-ffdb-413c-ab8d-50a8325820c8",
"beneficialOwnershipStatements": [
{
"id": "c4bbe7a6-ec59-43dd-8ef8-b6ec954a11b0",
"statementDate": "2017-03-25",
"entity": {
"id": "3af298b8-a8db-48a6-b95c-f60bc8473dae",
"statementDate": "2017-03-25",
"type": "registeredEntity",
"name": "CHRINON LTD",
"foundingDate": "2010-11-18",
"identifiers": [
{
"scheme": "GB-COH",
"id": "07444723"
}
],
"addresses": [
{
"type": "registered",
"address": "Aston House, Cornwall Avenue, London, N3 1LF",
"country": "GB",
"postCode": "N3 1LF"
}
],
"jurisdiction": "GB",
"uri": "https://beta.companieshouse.gov.uk/company/07444723"
},
"interestedParty": {
"id": "7d70e955-facf-40fa-a35f-5c6fa9c6bd15",
"statementDate":"2017-03-25",
"type": "naturalPerson",
"name": "Chris Taggart",
"identifiers": [
{
"scheme": "MISC-etag",
"id": "f6b02c26-317b-4840-b116-8b9f91bb393b"
}
],
"nationalities": [
"GB"
],
"alternateNames": [
{
"type": "detailed",
"fullName": "Christopher Taggart",
"patronymicName": "",
"givenName": "Christopher",
"familyName": "Taggart"
}
],
"birthDate": "1964-04",
"addresses": [
{
"type": "service",
"address": "Aston House, Cornwall Avenue, London, N3 1LF",
"country": "GB",
"postCode": "N3 1LF"
}
]
},
"interests": [
{
"type": "shareholding",
"interestLevel": "direct",
"startDate": "2016-04-06",
"share": {
"exact": 100
}
}
]
}
]
}
]
}
Updating ownership¶
To update a previous statement, a new beneficial ownership statement, with a replacesStatement property is required.
In the (fictional) example below, the previous statement that Chris Taggart has 100% ownership of Chrinon Ltd is replaced by a new statement showing 50% ownership. A separate statement in the statementGroup declares a new owner of the other 50%, although notes that this owner has not yet been identified such that their information can be disclosed.
Note that only changed statements need to new statement identifiers (assuming that the same orignal submissions of data are being used).
{
"statementGroups": [
{
"id": "8ad354c4-59b7-4a05-9792-8584dd8ea8bc",
"beneficialOwnershipStatements": [
{
"id": "499d1950-49b4-42c4-9076-30254f4314f7",
"replacesStatement":"c4bbe7a6-ec59-43dd-8ef8-b6ec954a11b0",
"statementDate": "2017-03-30",
"entity": {
"id": "3af298b8-a8db-48a6-b95c-f60bc8473dae",
"statementDate": "2017-03-25",
"type": "registeredEntity",
"name": "CHRINON LTD",
"foundingDate": "2010-11-18",
"identifiers": [
{
"scheme": "GB-COH",
"id": "07444723"
}
],
"addresses": [
{
"type": "registered",
"address": "Aston House, Cornwall Avenue, London, N3 1LF",
"country": "GB",
"postCode": "N3 1LF"
}
],
"jurisdiction": "GB",
"uri": "https://beta.companieshouse.gov.uk/company/07444723"
},
"interestedParty": {
"id": "7d70e955-facf-40fa-a35f-5c6fa9c6bd15",
"statementDate":"2017-03-25",
"type": "naturalPerson",
"name": "Chris Taggart",
"identifiers": [
{
"scheme": "MISC-etag",
"id": "f6b02c26-317b-4840-b116-8b9f91bb393b"
}
],
"nationalities": [
"GB"
],
"alternateNames": [
{
"type": "detailed",
"fullName": "Christopher Taggart",
"patronymicName": "",
"givenName": "Christopher",
"familyName": "Taggart"
}
],
"birthDate": "1964-04",
"addresses": [
{
"type": "service",
"address": "Aston House, Cornwall Avenue, London, N3 1LF",
"country": "GB",
"postCode": "N3 1LF"
}
]
},
"interests": [
{
"type": "shareholding",
"interestLevel": "direct",
"startDate": "2016-03-30",
"share": {
"exact": 50
}
}
]
},
{
"id": "499d1950-49b4-42c4-9076-30254f4314f7",
"statementDate": "2017-03-30",
"entity": {
"id": "3af298b8-a8db-48a6-b95c-f60bc8473dae",
"statementDate": "2017-03-25",
"type": "registeredEntity",
"name": "CHRINON LTD",
"foundingDate": "2010-11-18",
"identifiers": [
{
"scheme": "GB-COH",
"id": "07444723"
}
],
"addresses": [
{
"type": "registered",
"address": "Aston House, Cornwall Avenue, London, N3 1LF",
"country": "GB",
"postCode": "N3 1LF"
}
],
"jurisdiction": "GB",
"uri": "https://beta.companieshouse.gov.uk/company/07444723"
},
"interestedParty": {
"id": "c1e42267-680f-48c4-b5bf-6bb2a343b58f",
"statementDate":"2017-03-30",
"type": "unknownPerson",
"missingInfoReason":"Owner identified, but details have not yet been confirmed."
},
"interests": [
{
"type": "shareholding",
"interestLevel": "direct",
"startDate": "2017-03-30",
"share": {
"exact": 50
}
}
]
}
]
}
]
}
Joint ownership¶
To model joint ownership, an artificial ‘arrangement’, owned by the two parties responsible for it, should be included within a chain of ownership.
{
"statementGroups": [
{
"id": "2d129b31-7d00-4b40-97d9-311848115f28",
"beneficialOwnershipStatements": [
{
"#summary":"This statement shows an entity 100% owned by an arrangement",
"id": "39d83fed-a5c4-47ef-a477-72a32860584a",
"statementDate": "2017-03-25",
"entity": {
"id": "8549d14e-3864-44c2-a1f8-d5f397c4069e",
"statementDate": "2017-03-25",
"type": "registeredEntity",
"name": "CHRINON LTD",
"foundingDate": "2010-11-18",
"identifiers": [
{
"scheme": "GB-COH",
"id": "07444723"
}
],
"addresses": [
{
"type": "registered",
"address": "Aston House, Cornwall Avenue, London, N3 1LF",
"country": "GB",
"postCode": "N3 1LF"
}
],
"jurisdiction": "GB",
"uri": "https://beta.companieshouse.gov.uk/company/07444723"
},
"interestedParty": {
"id": "4cfc6d0c-8de4-4a62-803b-c0485fd61f68",
"statementDate":"2017-03-25",
"type": "arrangement",
"name": "Joint shareholding",
"identifiers": [
{
"scheme": "MISC-etag",
"id": "ee4d04b1-48d5-48c2-a77b-2054a0fc8203"
}
]
},
"interests": [
{
"type": "shareholding",
"interestLevel": "direct",
"startDate": "2016-04-06",
"share": {
"exact": 100
}
}
]
},
{
"#summary":"This statement shows Person A owns 50% of the arrangement.",
"id": "acdc0c13-43ea-4c5d-9bf9-4ee625dcfdd1",
"statementDate": "2017-03-25",
"entity": {
"id": "d51e90c1-0f75-46de-92e4-8a9096c13128",
"statementDate": "2017-03-25",
"type": "arrangement",
"name": "Joint shareholding",
"foundingDate": "2015-01-01",
"identifiers": [
{
"scheme": "MISC-etag",
"id": "ee4d04b1-48d5-48c2-a77b-2054a0fc8203"
}
],
"jurisdiction": "GB"
},
"interestedParty": {
"id": "ec6a9066-15e0-42a7-947e-6ae044c3c80a",
"statementDate":"2017-03-25",
"type": "naturalPerson",
"name": "Person A",
"identifiers": [
{
"scheme": "MISC-etag",
"id": "7d779eaa-d4c8-4d0f-b21f-b19025525903"
}
],
"nationalities": [
"GB"
],
"birthDate": "1970-04"
},
"interests": [
{
"type": "shareholding",
"interestLevel": "direct",
"startDate": "2016-04-06",
"share": {
"exact": 50
}
}
]
},
{
"#summary":"This statement shows Person B owns 50% of the arrangement.",
"id": "afe5ad43-6367-41da-bec1-1c5f923d5ffe",
"statementDate": "2017-03-25",
"entity": {
"id": "932a934e-03a9-4430-8a74-38672ce568ec",
"statementDate": "2017-03-25",
"type": "arrangement",
"name": "Joint shareholding",
"foundingDate": "2015-01-01",
"identifiers": [
{
"scheme": "MISC-etag",
"id": "ee4d04b1-48d5-48c2-a77b-2054a0fc8203"
}
],
"jurisdiction": "GB"
},
"interestedParty": {
"id": "18db873b-c645-4f3c-8e9b-4db7d0e26d7d",
"statementDate":"2017-03-25",
"type": "naturalPerson",
"name": "Person B",
"identifiers": [
{
"scheme": "MISC-etag",
"id": "90885848-bbab-4f97-b84d-ca50f6ec68f2"
}
],
"nationalities": [
"GB"
],
"birthDate": "1970-04"
},
"interests": [
{
"type": "shareholding",
"interestLevel": "direct",
"startDate": "2016-04-06",
"share": {
"exact": 50
}
}
]
}
]
}
]
}
Ownership via trust¶
To model ownership via a trust:
{
"statementGroups": [
{
"beneficialOwnershipStatements": [
{
"id": "1f5681e7-fd16-418c-885e-3d7edf151186",
"#summary": "This statement shows a registered entity 100% controlled by a legal entity (a trust).",
"statementDate": "2017-03-25",
"entity": {
"id": "9092e13f-798a-441e-99bd-2db993a1c72e",
"statementDate": "2017-03-25",
"type": "registeredEntity",
"name": "HANSEN GROUP",
"foundingDate": "1999-05-09",
"identifiers": [
{
"scheme": "GB-COH",
"id": "12345678"
}
],
"addresses": [
{
"address": "33 Ila Bridge, London, SE8 1TB",
"type": "registered",
"postCode": "SE8 1TB",
"country": "GB"
}
],
"jurisdiction": "GB",
"uri": "https://beta.companieshouse.gov.uk/company/12345678"
},
"interestedParty": {
"id": "9a4d4a09-6d8d-43dc-881e-52a1fe74a120",
"statementDate": "2017-03-25",
"jurisdiction": "GB",
"type": "legalEntity",
"name": "Hansen Family Trust",
"foundingDate": "1999-05-09",
"addresses": [
{
"postCode": "SE1 4TS",
"address": "432 Feil Knoll, London, SE1 4TS",
"country": "GB",
"type": "service"
}
],
"identifiers": []
},
"interests": [
{
"details": "A trust that owns 100% of the shares in an entity",
"share": {
"exact": 100
},
"interestLevel": "direct",
"type": "shareholding"
}
],
"source": {
"#summary": "A legal entity self-declaring a direct beneficial ownership interest.",
"type": [
"selfDeclaration"
],
"assertedBy": [
{
"name": "Hansen Family Trust"
}
]
}
},
{
"id": "ea875c67-95bc-4c80-b69d-15b8279ea117",
"#summary": "This statement shows a legal entity 100% controlled by a natural person.",
"statementDate": "2017-03-25",
"entity": {
"id": "29fe10b5-ad9e-48db-94a2-eb3b61f75688",
"statementDate": "2017-03-25",
"jurisdiction": "GB",
"type": "legalEntity",
"name": "Hansen Family Trust",
"foundingDate": "1999-05-09",
"addresses": [
{
"postCode": "SE1 4TS",
"address": "432 Feil Knoll, London, SE1 4TS",
"country": "GB",
"type": "service"
}
],
"identifiers": []
},
"interestedParty": {
"id": "f6b33181-1ef4-495f-aca1-e3b4d1e50917",
"jurisdiction": "GB",
"type": "naturalPerson",
"name": "Dennis Hansen",
"addresses": [
{
"postCode": "N1 9FT",
"address": "705 Granville Locks, London, N1 9FT",
"country": "GB",
"type": "home"
}
],
"nationalities": [
"GB"
]
},
"interests": [
{
"details": "A natural person who owns 100% of a trust that owns 100% an entity",
"share": {
"exact": 100
},
"interestLevel": "direct",
"type": "shareholding"
}
],
"source": {
"description": "A natural person self-declaring an direct beneficial ownership interest.",
"type": [
"selfDeclaration"
],
"assertedBy": [
{
"name": "Dennis Hansen"
}
]
}
},
{
"id": "45cf01ce-f9cd-4910-a6b9-4f8ec620285a",
"#summary": "This statement shows a registered company 100% indirectly-controlled by a natural person",
"statementDate": "2017-03-25",
"entity": {
"id": "9092e13f-798a-441e-99bd-2db993a1c72e",
"statementDate": "2017-03-25",
"type": "registeredEntity",
"name": "HANSEN GROUP",
"foundingDate": "1999-05-09",
"identifiers": [
{
"scheme": "GB-COH",
"id": "12345678"
}
],
"addresses": [
{
"address": "33 Ila Bridge, London, SE8 1TB",
"type": "service",
"postCode": "SE8 1TB",
"country": "GB"
}
],
"jurisdiction": "GB",
"uri": "https://beta.companieshouse.gov.uk/company/12345678"
},
"interests": [
{
"details": "A natural person that has an indirect shareholding in an entity through 100% ownership of a legal entity",
"share": {
"exact": 100
},
"interestLevel": "indirect",
"type": "shareholding"
}
],
"interestedParty": {
"id": "f6b33181-1ef4-495f-aca1-e3b4d1e50917",
"jurisdiction": "GB",
"type": "naturalPerson",
"name": "Dennis Hansen",
"addresses": [
{
"postCode": "N1 9FT",
"address": "705 Granville Locks, London, N1 9FT",
"country": "GB",
"type": "home"
}
],
"nationalities": [
"GB"
]
},
"source": {
"description": "A natural person self-declaring an indirect beneficial ownership interest.",
"type": [
"selfDeclaration"
],
"assertedBy": [
{
"name": "Dennis Hansen"
}
]
}
}
],
"id": "11ecc5a9-9e1c-46d7-bfc5-afff589eab48"
}
]
}
Blank data¶
If the beneficial owner of Chrinon Ltd had not been identified, a null statement as follows could be used:
{
"statementGroups": [
{
"id": "9b57a603-ffdb-413c-ab8d-50a8325820c8",
"beneficialOwnershipStatements": [
{
"id": "c4bbe7a6-ec59-43dd-8ef8-b6ec954a11b0",
"date": "2017-03-25",
"entity": {
"id": "3af298b8-a8db-48a6-b95c-f60bc8473dae",
"statementDate": "2017-03-25",
"type": "registeredEntity",
"name": "CHRINON LTD",
"foundingDate": "2010-11-18",
"identifiers": [
{
"scheme": "GB-COH",
"id": "07444723"
}
],
"addresses": [
{
"type": "registered",
"address": "Aston House, Cornwall Avenue, London, N3 1LF",
"country": "GB",
"postCode": "N3 1LF"
}
],
"jurisdiction": "GB",
"uri": "https://beta.companieshouse.gov.uk/company/07444723"
},
"interestedParty": {
"type": "unknown",
"description":"No beneficial owner has been located. A search is ongoing."
},
"interests": [
]
}
]
}
]
}
Provenance Information¶
Warning
This is an old version of the data standard. See latest version.
Provenance information can be attached through use of the Source object on a StatementGroup, a BeneficialOwnershipStatement, an EntityStatement or a PersonStatement.
These can be thought of in a hierarchy:
- Level 1:
StatementGroup- Level 2:
BeneficialOwnershipStatement- Level 3:
EntityStatementorPersonStatement
- Level 3:
- Level 2:
Each level adds further provenance information. So, for example, an EntityStatement.source record would indicate that the details of the entity have been obtained from a officialRegister, whilst the BeneficialOwnershipStatement.source record would indicate that the relationship between the identified entity, and a person, was asserted through self-declaration, and the StatementGroup.source would indicate that all this information was brought together by importing from another open dataset.
Source object¶
The Source object provides the following fields:
| Field Name | Description | Format |
|---|---|---|
| type | Source type: What type of source is this? Multiple tags can be combined. Codelist options: [selfDeclaration, officialRegister, thirdParty, primaryResearch, verified] |
array enum (codelist) |
| description | Description: Where required, additional free-text information about the source of this statement can be provided here. | string |
| url | Source URL: If this information was fetched from an external URL, or a machine or human readable web page is available that provides addition information on how this statement was sourced, provide the URL. | string |
| retrievedAt | Retrieved at: If this statement was imported from some external system, include a timestamp indicating when this took place. The statement’s own date should be set based on the source information. | datetime string |
| assertedBy | Asserted by: Who is making this statement? This may be the name of the person or organisation making a self-declaration (in which case, please make sure the name field matches the organisation or person name field), or the name or description of some other party. If this statment has been verified, this may also include the name of the organisation providing verification. See AssertingParty section for further details. | Object Array |
Source type codelist¶
ToDo: Provide formal definitions of each source type
Serialization¶
Warning
This is an old version of the data standard. See latest version.
The beta specification does not contain detailed information on serialization.
However, the specification, defined by a JSON Schema, is designed to support:
- Nested JSON documents;
- Individual statements expressed using JSON lines;
- XML representation
- Flattened representations in CSV or Excel;
- JSON-LD;
Conformance and validation¶
Warning
This is an old version of the data standard. See latest version.
Conformance statement¶
- A conforming implementation may use only a subset of this specification’s terms.
- It must not use terms from outside this specification’s terms where this specification’s terms would suffice.
- It may use terms from outside this specification’s terms where this specification’s terms are insufficient.
- Its usage of this specification’s terms must be consistent with the semantics of those terms.
- If an implementation serializes to JSON, its serializations must validate against this specification’s JSON Schema.
(Statement adapted from Popolo Project specification)
Extending the schema¶
Publishers providing additional properties in their implementations are encouraged to document these in the project issue tracker with the ‘extensions’ tag, and to re-use other publisher’s extensions where possible.
Validation¶
No public validator available for the beta release is currently available.
The current schema includes minimal validation requirements, and should be treated as a guide to data structure, rather than a full validation schema.
Credits¶
Warning
This is an old version of the data standard. See latest version.
The beta version of the Beneficial Ownership Data Standard was written by Tim Davies (Open Data Services Co-operative) with Ben Symonds (OpenCorporates), Chris Taggart (OpenCorporates) and Jack Lord (Knowcale) and supported by the data standard working group.
The initial development of the Beneficial Ownership Data Standard is funded through support for the Open Ownership project from the UK Department for International Development. OpenOwnership is a project of Transparency International, OpenCorporates, One, the Open Contracting Partnership, the World Wide Web Foundation, Global Witness and The B Team
Governance¶
Warning
This is an old version of the data standard. See latest version.
Get involved¶
All changes to the standard draft, documentation and specification take place via GitHub at https://github.com/openownership/data-standard/.
Suggestions for changes can be made via the project issue tracker.
License and contributor agreement¶
Schema contents of the Open Ownership Register are Copyright 2016 World Wide Web Foundation on behalf of the Open Ownership Register Steering Group.
The schema is licensed under the Apache License, Version 2.0
Contributors are required to accept the contributor agreement.
Data Standard Working Group Terms of Reference¶
Note
These are the ‘Bootstrap Terms of Reference’ of the Data Standard Working Group, used between December 2016 and March 2017.
The Beneficial Ownership Data Standard Working Group (DSWG) will drive the initial creation of a free and open data standard for Beneficial Ownership designed to reduce the technical barriers to the collection and re-use of beneficial ownership data, including (but not limited to) by the OpenOwnership Register being created by civil society around the world. OpenOwnership is also creating private sector, public sector and civil society working groups.
This working group will include stakeholders from a range of backgrounds with an interest and expertise in data relating to corporate control or beneficial ownership, and to the use of such data in the public interest. While the development of the standard will take place through an open process, to which anyone can contribute, working group members take on a special responsibility for guiding development of the standard, and ensuring that relevant requirements, user needs and technical considerations are taken into account.
The output will be the first, draft version of the data standard, to be published by March 31, 2017.
Values¶
All working group members must commit to support the following shared values.
Open
We will:
- share our views and plans, and share knowledge as widely as possible;
- solicit and listen to views from end users and stakeholders;
- make our outputs available under an open licence and abide by the project contributor agreement;
Expert
We will:
- bring our expertise to the discussion as individuals;
- use our expertise to synthesise the views of others in constructive and forward-thinking proposals;
- use good judgement to respect privacy and confidentiality.
Collaborative
We will
- support each other in discussion, in decisions, and in delivery;
- operate on the basis of consensus decision making;
- constructively hold each other to account on our commitments;
- ensure all voices are heard and considered carefully.
Membership, term and role:¶
Membership of the working group is a voluntary responsibility. Members should be prepared to commit up to 5 hours a month over the period December 2016 to March 2017 to review drafts, join group calls and respond to issues.
Initial group membership will be formed at the invitation of the Co-chairs. Co-chairs are appointed by the Open Ownership Project Steering Group, with their term subject to review at the end of March 2017.
In collaboration with the Open Ownership Project Steering Group the DSWG will develop a revised Terms of Reference, and process for group membership, to be in operation from April 2017 onwards.
Co-chairs:
- Chris Taggart, OpenCorporates
- Tim Davies, Open Data Services Co-operative
Members (as of 20th March 2017)
The following individuals were accepted into the working group, and were part of the decision making process on the design and release of the beta standard.
- Anders Pedersen - Natural Resource Governance Institute
- Christoffer Claussen - Extractives Industry Trnapsarency Initiative
- Colin Maudry - Independant consultant
- Eduard Martín-Borregón - PODER
- Friedrich Lindenberg - Organized Crime and Corruption Reporting Project
- Gert Berthold - Precipitate Solutions, LLC
- James McKinney - Government of Ontario
- Jay Daley - NZRS Ltd
- Jonathan Stray - Columbia Journalism School
- Jonathan Gray - University of Bath
- Josema Alonso - World Wide Web Foundation
- Josh Powell - Development Gateway
- Karim Lourimi - Moore Stephens
- Kevin Brown - PODER
- Mara Mendes - Open Knowledge Foundation Germany
- Michalis Vafopoulos - Software and Knowledge Engineering Laboratory National Center for Scientific Research “DEMOKRITOS”
- Mihai Postelnicu - Development Gateway
- Mikhail Kashkin - Papir
- Myroslav Opyr - Quinta Group
- Paul May - Arachnys
- Seb Bacon - EBM Data Lab, Oxford University
- Victor Nițu - Open Knowledge International
- Yasodara Cordova - Berkman Klein Center at Harvard
Partners and funders¶
The initial development of the Beneficial Ownership Data Standard is funded through support for the Open Ownership project from the UK Department for International Development. OpenOwnership is a project of Transparency International, OpenCorporates, One, the Open Contracting Partnership, the World Wide Web Foundation, Global Witness and The B Team
This draft has been developed by Open Data Services Co-operative and OpenCorporates
Contact¶
For more details about the OpenOwnership project, please contact the project coordinator, Zosia Sztykowski