Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Representing changing beneficial ownership over time #392

Closed
kd-ods opened this issue Jan 6, 2022 · 10 comments
Closed

Feature: Representing changing beneficial ownership over time #392

kd-ods opened this issue Jan 6, 2022 · 10 comments

Comments

@kd-ods
Copy link
Collaborator

kd-ods commented Jan 6, 2022

[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:

  • Accurate representation of changes to declared beneficial ownership over time;
  • Clear interpretation of beneficial ownership data about an entity, from multiple sources, released over time.

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:
  • Update of existing ownership-or-control information in a previous declaration;
  • Correction (by declarer) of existing entity or existing person information in previous declaration;
  • An end to an ownership-or-control interest.
  1. A change to the details of the natural persons or entities within an ownership structure. For example:
  • Update of existing entity or existing person name in previous declaration;
  • Update: addition of a beneficial owner;
  • Update: new intermediate entity.
  1. A change to the disclosure regime or disclosure conditions. For example:
  • The threshold level of control to be considered a beneficial owner is updated to include all board members.
  1. A change to the status of the declaring entity. For example:
  • A newly dissolved company is no longer expected to provide statements.
  1. A change (update) of declaration date. For example:
  • Confirmation of accuracy of previous declaration (confirmation statement).

What impact would not meeting these needs have?

  • Publishers may publish data in BODS format which is ambiguous.
  • Publishers may publish unambiguous BODS data in non-standard ways (for example, by clearly documenting their approach to handling change over time and using annotations).
  • Publishers may not adequately consider the importance of maintaining accurate, unambiguous historical records of beneficial ownership declarations.
  • Publishers may opt not to publish beneficial ownership data in BODS format.

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:

  • The information being repeated in (or emptied from*) another statement, the end date being the statement date, and replacesStatements used to link statements.
  • Its irrelevance being implied by:
    • A deathDate for person statements
    • A dissolutionDate for an entity statements
    • An endDate for an interest within an ownership-or-control statement

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:

  • Risk of data bloat.
  • Using clear, understandable language around the implemented feature.
  • Full auditability of beneficial ownership data.

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

  • The declared information has changed.
  • The declared information is no longer required to be disclosed.
  • The declared information was wrong and has been corrected.
  • The declared information was incorrectly represented and has been corrected.
  • The declared information should not have been published.

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
Copy link
Collaborator Author

kd-ods commented Jan 6, 2022

@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
Copy link

cosmin-marginean commented Feb 15, 2022

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
Copy link
Collaborator Author

kd-ods commented Mar 1, 2022

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
Copy link
Member

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
Copy link
Member

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
Copy link
Collaborator Author

kd-ods commented Nov 18, 2022

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
Copy link
Member

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
Copy link
Collaborator Author

kd-ods commented Mar 6, 2023

See #475 for an implementation proposal

@kd-ods
Copy link
Collaborator Author

kd-ods commented Jan 5, 2024

Implementation of this feature (along with two other features) is being tracked via this ticket #487.

@StephenAbbott StephenAbbott moved this from Implement (schema) to Implement (documentation) in BODS Feature Tracker Mar 12, 2024
@StephenAbbott StephenAbbott moved this from Implement (documentation) to Done in BODS Feature Tracker Apr 23, 2024
@kathryn-ods
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

5 participants