openownership / data-standard

The Beneficial Ownership Data Standard (BODS) is an open standard providing a specification for modelling and publishing information on the beneficial ownership and control of corporate vehicles
http://standard.openownership.org
Other
60 stars 13 forks source link

Feature: Representing changing beneficial ownership over time #392

Closed kd-ods closed 5 months ago

kd-ods commented 2 years ago

[This ticket helps track progress towards developing a particular feature in BODS where changes or revisions to the standard may be required. It should be placed on the BODS Feature Tracker, under the relevant status column.

_See Feature development in BODS in the Handbook._

The title of this GitHub ticket should be 'Feature: XXXXX' where XXXXX is the feature name below. The information in this first post on the thread should be updated as necessary so that it holds up-to-date information. Comments on this ticket can be used to help track high-level work towards this feature or to refine this set of information.]

Feature name: Representing changing beneficial ownership over time

Feature background

What user needs are met by introducing or developing this feature in BODS?

A core requirement of BODS is that it enables:

In particular, BODS should allow the representation and tracking of information updates through the following state changes:

1) A change to the ownership-or-control relationships within an ownership structure. For example:

2) A change to the details of the natural persons or entities within an ownership structure. For example:

3) A change to the disclosure regime or disclosure conditions. For example:

4) A change to the status of the declaring entity. For example:

5) A change (update) of declaration date. For example:

What impact would not meeting these needs have?

How important is it to meet the above needs?

It is very important that version 1 of BODS meets these needs, and that it does so with consideration of the related challenges and issues noted below.

Currently (as of BODS 0.2) the aspects of the data standard related to change over time are the immutability of statements and the replacesStatements array. These are under-documented and insufficient to meet the above needs. In particular the following problems remain:

1) No Statement End Date

Currently there is no way to end a statement’s relevance at a certain date without either:

So there is no current consistent way to express a statement's applicability ending. And yet there are numerous reasons why a statement's applicability does end: control or ownership interests dip below a set threshold; a threshold is changed by law; an entity is no longer an intermediary; an entity no longer meets the criteria for making beneficial ownership declarations; and so on.

* 'Voiding’ a statement (as of BODS 0.2) can be achieved by publishing a new statement with empty fields and using replacesStatements to link to the old statement. However this is inelegant and the intention of doing this may not be clear.

2) Small changes require large changes

Any change to a statement requires a new statementID to be created.

This means that even if something small has changed, a lot of related statements may have to be amended. For example, a name correction for a person statement will require every ownership-or-control statement with that person as an interestedParty to be changed to include the new statementID.

3) Difficult to tell if a statement supersedes another one

As replacesStatements can replace multiple statements, we cannot tell how a new statement is related to the statement it supersedes.

4) Difficult to produce replacesStatements IDs

Publishers find it difficult to make the connection between new statements and old ones. Normally they have an internal ID in the system (that relates to a particular level but they are also not likely to have a coherent full version history in the database).

How urgent is it to meet the above needs?

Given that publishers have some facility (in replacesStatements) to address change over time in BODS 0.2, and that improvements/changes to this facility are crucial to get right for a version 1 release, the urgency is somewhat mitigated.

Are there any obvious problems, dependencies or challenges that any proposal to develop this feature would need to address?

Related challenges and issues are:

More on point 3 above: auditability. A data point in a BODS dataset might change, or be updated, for a number of reasons, including:

It might be prudent within a beneficial ownership tracking system to maintain a record of all such changes and others, for full internal auditability. However, the data standard’s core requirement is to represent change in declared beneficial ownership over time. Although issues of redaction and data correction do relate to change over time, they should be considered as orthogonal; and the interaction of these issues should be examined carefully as part of any proposal to develop this feature.

Feature work tracking

kd-ods commented 2 years ago

@ScatteredInk @kindly @siwhitehouse - this is my attempt at representing the challenge of change-over-time in BODS. (i.e. no solutionising... just the problem we're trying to address.) If there's any crucial element that I've missed or misrepresented, let me know.

cosmin-marginean commented 2 years ago

I'm looking at this purely from BODS consumer, product & use case perspectives, and just wanted to make a couple of points.

Firstly, I completely agree that replacesStatements is inelegant and the rationale for the replacement isn't always clear. I would add that there is significant complexity in dealing with them in practice at data ingestion time. While that's not in the current (0.1) dataset, we haven't yet conceived a reasonable way to handle this in the future.

Further, there is the endDate of an interest which, when missing has to be treated as a current interest. I believe this modelling exercise has to account for the semantic complexity incurred here when, for example, a statement is voided (by something other than replacesStatements) while there are interests there that don't have an endDate. Is that even possible, and if so, what are the mechanisms for reasoning about those interests?

And so, is there a semantic connection between a statement's invalidation (date) and the interests' endDate that we should consider and make this connection explicit (or documented)?

And as a last point, I would argue that (again, from a register consumer perspective) handling the current ownership should be algorithmically much simpler than reasoning about historical snapshots. Any semantic complexity that is added by supporting historical data (whose importance I'm not contesting, just arguing that is secondary) should be tested, IMO, against this principle.

kd-ods commented 2 years ago

And as a last point, I would argue that (again, from a register consumer perspective) handling the current ownership should be algorithmically much simpler than reasoning about historical snapshots. Any semantic complexity that is added by supporting historical data (whose importance I'm not contesting, just arguing that is secondary) should be tested, IMO, against this principle.

Yes, this is a really good point, @cosmin-marginean. Having the data standard handle historical data well means being able to generate historical, 'time-slice', snapshots in a reliable way, as well as being able to handle those or current snapshots relatively easily.

It's crucial that the way that BODS represents historical, current and changing information is both robust and relatively easy to communicate. Which is a challenge.

StephenAbbott commented 2 years ago

Since we first published this BODS feature development ticket in early 2022, the team at Open Ownership and Open Data Services have been doing more thinking about change over time.

Today, we have published new technical guidance - written by @kd-ods - on the importance of building an auditable record of beneficial ownership.

This guidance sets out five features that support auditability:

  1. Reliable and comprehensive dates and times
  2. Reliable identifiers for people and entities
  3. Traceable source information
  4. Visible information gaps
  5. Publication policy

Some of these features are already supported in BODS but some - especially the traceable source information feature - will require significant changes to future versions of BODS.

We will share more about our plans in this area here on the BODS feature tracker as this work progresses.

StephenAbbott commented 2 years ago

Noting here that the European Union's draft sixth anti-money laundering directive aims to set "a minimum duration for which information must be maintained in the [beneficial ownership] registers of five years" which makes it important to be able to show how that data has changed over time

kd-ods commented 1 year ago

Noting for future reference:

Info on bitemporality in Denmark's public data.

I haven't had time to look in depth at this yet.

StephenAbbott commented 1 year ago

An interesting case study from the UK where the Economic Crime and Corporate Transparency Bill is currently being debated in Parliament.

This bill is aimed at giving greater powers to the company registrar, Companies House, to fight economic crime, prevent the misuse of UK companies and improve the quality of information published in its registers.

Plans include proposals to introduce new measures to prevent the abuse of personal information held on these register by widening the ability of people to apply to suppress certain types of personal information.

These provide good examples of scenarios where the UK may want to remove information from its public registry records without flagging this heavily in their datasets.

Below is a copy of the plans shared in a Companies House blog post published on 10th January 2023:

Suppression of personal information Currently, individuals can apply to suppress their residential address if it’s shown as their service address. Under the new measures, individuals will also be able to apply to suppress the following information from historical documents once secondary legislation is made:

  • residential addresses in most instances when shown elsewhere on the register (for example, when used as a registered office address)
  • day of birth for documents registered before 10 October 2015 (only the month and year of birth have been publicly displayed since 10 October 2015)
  • signatures
  • business occupation
  • Suppression will be automatic on application. You will not need to supply any evidence.

Protection of personal information because of risk of harm We’re also improving the protection regime so that individuals at personal risk of physical harm or violence as a result of their personal information being on our public registers (for example, domestic abuse survivors) can apply to have their information protected from public view. The application process will be set out in secondary legislation, but we expect that people will need to provide evidence before their information is protected – such as supporting correspondence from the police or a charity caseworker.

The information that can be protected from public view includes:

  • name (or previous names)
  • sensitive addresses where public disclosure puts its residents at risk (for example, a women’s domestic abuse refuge)
  • in the most serious cases, all other details, for example, service address and partial date of birth

As noted by the author, "these measures will all need secondary legislation and system development before they’re implemented".

kd-ods commented 1 year ago

See #475 for an implementation proposal

kd-ods commented 8 months ago

Implementation of this feature (along with two other features) is being tracked via this ticket https://github.com/openownership/data-standard/issues/487.

kathryn-ods commented 2 months ago

Noting that this feature is complete as of BODS 0.4 see - https://standard.openownership.org/en/0.4.0/standard/index.html