Specification

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.

Conceptual Model

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

Share

Field Name Description Format
exact Exact share: The exact share of this interest held (where available). number
maximum Maximum share: The upper bound of the share of this interest known to be held. number
minimum Minimum share: The lower bound of the share of this interest known to be held. number
exclusiveMinimum Exclusive minimum: If exclusiveMinimum is true, then the share is at least greater than the minimum value given. E.g. if minimum is 25, the share is at least 25.1, and not simply 25. boolean
exclusiveMaximum Exclusive maximum: If exclusiveMaximum is true, then the share is at least less than the maximum value given. E.g. if maximum is 50, the share is less than 49.999, and not simply 50. boolean

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.