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.