Describing interests: Research note

Modelling implications

Current modelling

Interests are currently modelled using a number of fields:

• type – using the Interest Type codelist; [7]
• directOrIndirect – a string indicating whether the relationship between interestedParty and Subject is known to be direct or indirect, or whether this is unknown;
• beneficialOwnershipOrControl – a boolean (Yes/No) value for whether this interest has been declared as being part of a beneficial ownership relationship;
• details – currently defined as “The local name given to this kind of interest, or further information (semi-structured or unstructured) to clarify the nature of the interest”;
• startDate – the date from which the interest has been active;
• endDate – the date from which the interest ceased to exist;
• share – the proportion of this type of interest held by the interested party, where an interest is countable.

Modelling considerations: Statement expansion and reduction

Imagine two disclosure regimes. Each requires disclosure of cases when a beneficial ownership interest is held through an arrangement. In one, JA, the data collection forms require specification of the details of the arrangement. In the other, JB, there is a simple drop-down list box to choose “Control via arrangement”.

In the BODS data model, these can both ultimately be represented accurately as indirect ownership chains via an arrangement.

In JA, the registration system can create records for the intermediary arrangement and its relationships using the disclosed information. BODS statements can then be generated concerning the intermediary and its role in the chain.

However, for JB, the arrangement details are unknown. This means that publishing BODS data that accurately represents the chain would involve creating a set of BODS statements (concerning the unknown arrangement) which may not be directly generated from records in the system. This can be conceptually and technically difficult to achieve.

Similarly, types of beneficial ownership interests described in legislation, such as ownership “Jointly with family”, may be modelled in BODS through an intermediary arrangement with additional unknown family member parties, although this modelling may lose information about the family relationships between particular parties.

This leads us to consider having interest type codelist entries that can capture concepts such as “By arrangement” or “Jointly with family”. However, this would introduce or expand the number of cases where there could be multiple ways of modelling the same thing in BODS, which creates issues for data users.

One approach to dealing with this would be specifying a set of expansion and reduction rules for data use, such that:

• complex modelling can be reduced into a single indirect interest statement; and/or
• indirect interest statements can be expanded out into complex modelling with known or unknown intermediary components.

This could be a contribution to simplifying BODS. [8]

Modelling options

We have considered a range of modelling options, and from these we have identified a preferred option.

Discounted options

The options we have discounted are briefly described below.

Modelling option 1: Exhaustive codelist

An exhaustive codelist would seek to cover all possible variations of interest type. This is, essentially, building on the status quo. We identified two main variations of this approach, and three implementation approaches:

1. Codelist by jurisdiction: local nomenclature. Every distinct interest type included on an official form (or in legislation) would be entered into the codelist in its source language and with a jurisdiction code. This would mirror the approach taken by the Global Legal Entity Identifier Foundation (GLEIF) and ISO to the Entity Legal Forms Code List, which provides a lookup of established nomenclature in each jurisdiction. [9] This supports in-country interoperability (i.e. two disclosures from the same jurisdiction should not use different codes), but does not promote cross-jurisdictional interoperability – as, for example, there might be as many distinct codelist entries for “shareholding” as there are jurisdictions covered by the codelist.
2. Codelist with cross-jurisdictional mapping: common nomenclature. In this approach, an effort is made to provide an exhaustive list of concepts but not to duplicate concepts where jurisdictions refer to exactly the same kind of interest, even if using different names. For example, “shareholding” in the United Kingdom’s People with Significant Control register, and “participation au capital” in a French disclosure would both map to the same codelist entry. However, the codelist would be expanded to also include composite complex concepts even if used in only one jurisdiction, creating a long-tail of lesser used codes.

Based on the supply side research, we consider maintaining codelists of this form is likely to be a complex task, and so briefly examined three possible approaches:

1. Closed codelist: codes are checked against an authority list during data validation. A central authority considers proposals for each new code entry, and adds them to the list. This would be a relatively minimal task in the case of a codelist by jurisdiction, but in the case of cross-jurisdictional mapping, it could require considerable research in order to identify conceptual and semantic overlap between interest types from different jurisdictions.
2. Open codelist: a codelist is provided as guidance, but data creators are free to add codes to this. Data creators are encouraged to consult local sources of authority (e.g. national guidance) in order to maximise domestic interoperability of data, but BODS validation tools do not provide pass/fail checks against an authority list. Tools could warn where new codes are seen in order to encourage data creators to check for minor errors in code formatting.
3. Self-service registry: codes are checked against a register of codes in use. Anyone can add entries to this codelist, and a light automated process is provided to minimise code duplication.

If adopting the exhaustive codelist approach, then we believe a self-service registry approach would be likely to help nudge data towards interoperability without requiring a significant overhead. However, on balance, we are not convinced that an exhaustive codelist suitably meets the needs of users.

Our preferred approach, outlined below, includes a free-text interest title field, and there may be value in providing a small service which harvests all known values of this field and generates a regular report of these by publishing jurisdiction. This would encourage harmonisation of terminology without making this into a formal exhaustive codelist.

Modelling option 2: Hierarchical codelist

A hierarchical codelist would identify a number of top-level categories of interest, with variations in interest nested below. This could enable users to select the level of detail they are interested in: for example, deciding whether to filter data by a top-level category such as “Control via Role”, or to filter by more detailed codelist entries such as “Company Director” or “Senior Manager”.

While this approach has some intuitive appeal, in practice, the data we encountered in our supply side review does not support a simple hierarchical approach. This approach is also vulnerable to becoming a more complex version of the exhaustive codelist where not only do many subtle variations need to be accounted for, but they are also located within a hierarchical taxonomy.

Modelling option 3: Classification tags

A tag-based approach would provide a codelist of basic concepts that can be combined to represent more complex interest types.

For example, where the Colombian disclosure regime requires beneficial ownership disclosure from:

• A natural person who directly and together with a family member (up to a second degree of consanguinity):
  • (1a) holds 5%+ of the share capital;
  • (1b) holds 5%+ of the voting rights;
  • (1c) benefits from 5%+ of the assets;
  • (1d) receives 5%+ of the profits or earnings.

And separately:

• A natural person who indirectly and together with a family member (up to a second degree of consanguinity):
  • (2a) holds 5%+ of the share capital;
  • (2b) holds 5%+ of the voting rights;
  • (2c) benefits from 5%+ of the assets;
  • (2d) receives 5%+ of the profits or earnings.

These eight variations could be captured by seven tags representing the concepts of:

• Shareholding, Voting, Right to Assets, Right to Profits, Jointly with Family, Direct and Indirect

This would map (1a) above to tags for [Shareholding, Direct, Jointly with Family], and (2b) to tags for [Voting, Indirect, Jointly with Family].

This approach has some value for allowing structured representation of diverse interest types through a relatively limited set of codelist entries. However, in testing against real-world disclosure categories and forms we found that:

1. Forms often do not capture adequate information to know which tags should apply. For example, a form might not adequately distinguish (1a) and (1d) above. This could lead to either false positive or false negative application of tags in real-world data.
2. Capturing all the various concepts found in real-world disclosure still requires the tagging codelist to grow quite extensive to cater for edge cases. For example, we quickly found we needed to add codes to cater for executors, rights in case of death of a party to a contract, etc.

Preferred option

Our preferred option is that the current type codelist would be replaced with an object consisting of:

• title – the name of the interest as described at the point of disclosure (i.e. the name given to this interest type in the jurisdiction);
• class (enum, 1..n) - a high-level required codelist consisting of a small set of categories such as [control, economic benefit, other benefit];
• mechanism (enum, 1..n) - a high-level optional codelist consisting of a small number of mechanisms such as [shareholding, role, contract, arrangement, family, other];
• description (string) - either additional standardised descriptions of this interest type, and/or specific descriptions provided for this disclosure.

If this approach is taken forward, further work will be required to confirm the exact contents of the class and mechanism codelists.

Note that the inclusion of “other benefit” is intentional, with an assumption that in some cases, “other” will be quite widely used, and there will be a high bar to the inclusion of additional entries in either codelist.

There are a number of implications and options that follow from this proposal:

• Publishers would be expected to list out the title of all the interest types that are disclosed or published in their jurisdiction, and to document the interest type data objects (including class and mechanism tags) that data users can expect to see in the published data.
• Guidance could be provided by BODS on common interest type objects. For example, voting shares with a right to profit would have a class of both “control” and “economic benefit”, and a mechanism of “shareholding”.
• This approach could be applied through full replacement of the type field with an object (major version upgrade required), or deprecation of type and introduction of a classification object (technically possible within a minor version upgrade).
• Consideration will need to be given to the other properties in the current Interest object (e.g. share and beneficialOwnershipOrControl) and where they ought to be situated.

This preferred approach is based on a number of key reflections:

Many use cases can be met with standardisation, at a high level of abstraction, of interest types. For example, showing a distinction between “economic benefit”, “control”, and “other benefit” may satisfy many applications integrating data from different sources (and many use cases rely simply on finding the presence of any interest to establish a connection between two subjects). We can leave the problem of understanding more detailed variations between interest types to particular applications and use cases. They will have diverse needs related to how granular a distinction is drawn between different interest types.

Some formal interest types are fairly common across jurisdictions and could be standardised with a low level of abstraction. For example, holding shares in a company, or being a beneficiary of a trust-like arrangement confer legally recognised rights in many jurisdictions. There is little difference from place to place in the form of these interests.

Disclosure forms and processes often do not capture the full variation in interest types provided for in law and regulation. Legislation may set out the different criteria which make someone a beneficial owner of a firm or other entity. However, the way that a disclosure is provided via a form may not involve stating which criteria have been met. (For example, it is possible that disclosing the name of a person and checking a box to declare that they are a beneficial owner is the extent of information collected.) If BODS requires that precise information is conveyed about the criteria that (may) have been met, this risks either putting undue pressure on data collection, or giving a false impression to users about the precision of data that may be available.

The wide variation in definitions of beneficial ownership, and how these break down into categories of beneficial owner and then to interests, is a policy issue. It is not possible to perfectly align the semantic meaning of interest disclosures between dierent jurisdictions through a common codelist alone. The precise meaning of an interest rests not only upon the term used for it, but also the legal system it is embedded within, and many wider contextual factors. There has been a policy choice to encourage jurisdictions to tailor beneficial ownership rules to local contexts, and any efforts to harmonise definitions (if sought) will require policy eorts and legislative change at the national level.

Footnotes

[7] Open Ownership, “Schema reference – Beneficial Ownership Data Standard v0.4 – Interest Type”, https://standard.openownership.org/en/0.4.0/standard/reference.html#interest-type.

[8] See: GitHub, “Feature: BODS simplification #737”, https://github.com/openownership/data-standard/issues/737.

[9] See: GLEIF, “ISO 20275: Entity Legal Forms Code List”, https://github.com/openownership/data-standard/issues/737.