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

Indirect ownership: improvements to guidance and schema #156

Closed
ScatteredInk opened this issue Mar 25, 2019 · 6 comments
Closed

Indirect ownership: improvements to guidance and schema #156

ScatteredInk opened this issue Mar 25, 2019 · 6 comments

Comments

@ScatteredInk
Copy link
Collaborator

ScatteredInk commented Mar 25, 2019

For future versions, we'd like to have clearer guidance on publication of indirect ownership structures.

This may involve a change to the provenance model to cover cases where secondary statements are generated as part of making an ownership-or-control statement.

For example:

  • Person A controls Company 1 indirectly through Company 2.
  • In some disclosure regimes, making an ownership-or-control statement between Company 1 and Person A would also generate a ownership-or-control statement between:
    • Company 2 and Company 1; and
    • Person A and Company 2.

In this circumstance, we would want to know that when the original ownership-or-control statement was replaced, the other generated statements should also be replaced.

This could perhaps be done by adding a statementID field to the current source object. Update from @timgdavies: updates should be handled through separate work.

@ScatteredInk ScatteredInk added this to the 0.2-rc milestone Mar 25, 2019
@ScatteredInk
Copy link
Collaborator Author

ScatteredInk commented May 21, 2019

The changes I would suggest to the schema here are fairly minor. The complexity is around publication guidance and implementation.

The publication guidance that I think we need is:

1. Publish a primary ownership-or-control statement that links the declaring entity and the interested party via an indirect ownership interest

This is to maximise the information we have about the ownership structure and the ownership relationship between the two parties, in conditions of uncertainty. For example, in the structure below, Person 1 has a 30% indirect interest in Company A:

indirect-relationships-2

To keep both the known structure and the interest itself, we can publish a separate statement and link the beneficial owner to the last known entity in the chain with an unknown interest type statement. This is shown below for an example disclosure regime where a disclosing entity must disclose the legal owners through which an interest is held.

os-07-dr-04-company-a

The specific guidance I suggest is:

Where a natural person is declared as having an indirect ownership-or-control interest in a declaring entity, a primary indirect ownership-or-control statement with the natural person as the interested party and the declaring entity as the subject SHOULD be published. This statement MUST have at least one interest with an indirect interest level. It MAY have additional interests with a direct interest level. This statement MUST be a complete representation of the relationship between the declaring entity and the beneficial owner.

2. Link secondary statements about ownership structure to the primary ownership-or-control statement between the declaring entity and the interested party

We want this feature so that:

  1. We know which other statements to replace when an indirect ownership statement is replaced;
  2. We can distinguish between canonical representations of relationships between subjects and interested parties, and representations that may only partially describe a relationship.

The guidance we want here is something along the lines of:

Publishing the details of an indirect chain of ownership may result in secondary statements, which describe, in full or in part, the chain of ownership between a subject and an interested party in a primary statement. Secondary statements:

  • MUST be linked to a primary statement;
  • MUST be replaced when the linked primary statement is replaced;
  • MAY NOT be a complete or sole representation of the entity, person or control relationship concerned;
  • for secondary ownership-or-control statements, a secondary statement MAY be a partial representation of ownership-or-control between the subject and interested party and SHOULD represent only the parts of that interest relevant to the primary statement.

For example, in the ownership structure below OOC-1 is a primary ownership-or-control statement. Statements about Company B and ownership-or-control statements OOC-2 and OOC-3 are secondary statements because they are generated as part of the disclosure process, rather than having an independent existence.

Copy of os-07-dr-04-company-a

Note that in this example:

  • OOC-2 is a complete representation of the ownership-or-control relationship between Company B and Company A - but there is no way to know this for sure from the disclosure process so a marker is helpful.
  • In some circumstances, OOC-2 could have an independent existence (if, say, share registers were released as open data under a different disclosure regime) and would not need to be marked as a secondary statement.

Implementation

I have been working on this in this branch and have a directory of examples to look at.

The initial approach I have gone for is a boolean at statement level to describe if a statement is generated (I think I now prefer 'secondary' though) and, if it is, a field to link to the statement that generated it:

    "generatedStatement": {
      "title": "description",
      "description": "Is this statement generated by another statement? A statement where this field is absent is assumed to be the primary ownership-or-control declaration, to be a complete representation of the declarable ownership relationship between the subject and interested parties. A generated statement MUST be associated with a primary ownership-or-control statement. A generated statement MAY be a partial representation of ownership between two parties, representing the portion relevant to the generating statement.",
      "type": "boolean",
      "enum": [ true ]
    },
    "generatedByStatementID": {
      "title": "title",
      "description": "For generated statemenets only, the identifier of the statement that generated this statement.",
      "$ref": "components.json#/definitions/ID"
    }

But I think this can perhaps be simplified further with just a renamed generatedByStatementID?

@kd-ods
Copy link
Collaborator

kd-ods commented May 21, 2019

@ScatteredInk - This looks like it will work. Will be interesting to hear what @stevenday and the Data Standard Working Group think. A couple of minor points:

This statement MUST be a complete representation of the relationship between the declaring entity and the beneficial owner.

For clarity, do we need to rephrase this as:

"This statement MUST be a complete representation of the aggregated interests between the declaring entity and the beneficial owner."

MUST be linked to a primary statement;

A thought on terminology. I think 'associated' is better than 'linked' in this context, since we talk about 'chains of ownership' and conceptually links belong within a chain. These primary and secondary statements are (partial-)representations of the same chain so I think it could be confusing to say they are 'linked'.

This thought also impacts on a choice of terminology for 'generatedByStatementID'. I think 'generated by' suggests that the secondary statements can be derived from the primary statement which isn't the case. Some alternatives might be:

  • 'componentOfStatement'
  • 'associatedWithStatement'
  • 'detailOfIndirectOocStatement'

I think some of the choices around terminology (and publishing and handling advice) will also turn on whether we think this new field will only ever be used in this context: i.e. to associate primary and secondary ownership-or-control statements to describe detail in an indirect BO relationship.

@stevenday
Copy link

Thanks for the write up and example diagrams @ScatteredInk - they're super clear!

I have a few almost rhetorical questions where I think I know the answer, but I'm asking anyway just to make sure I'm not missing a nuance:

  1. Why is the indirect ownership the primary piece of data, not a secondary derivation from the primary facts of legal ownership? In your diagrams it's a dashed line, whereas the 'secondary' stuff is solid, which is similar to how I initially thought about visualising it too, but that implies the opposite to what the data model says. I'm not sure if this is a nitpick or a profound realisation about the relative importance of the data we currently have in the register :)
  2. This creates another ordering dependency, where the primary statement has to be published before the secondaries (and thus another complication for processors to consider if they're out of order). Did you consider nesting them to avoid that?
  3. Did you consider implementing the linking the other way round, so the primary has a list of secondary statements? It implies publishing in the opposite order: secondaries -> primary but means that when you replace a primary, you can get to the secondaries you need to replace more logically. This is a pretty moot point for us because all the statements will be in a database so we can just index the new field and find them easily, but I don't know if that's the only situation to consider.
  4. The point about how secondary statements might have an independent existence is interesting from the Register's P.O.V. I'm assuming that means you could have two statements about exactly the same relationship, with the same interest details, being published by the same over-arching authority. We'd obviously want to de-dupe those. Is it beyond the scope of BODS to allow the publisher to do that?

And a couple of specific ones:

  1. Why the need for a boolean field, is the presence of a generatedByStatementID not enough evidence that a it's a secondary statement?
  2. Should MAY NOT be a complete or sole representation of the entity, person or control relationship concerned be MUST NOT? I though that the point this is making is that if it's complete, it's a primary statement, so a secondary cannot be complete? MAY NOT reads to me as more optional than that.
  3. I agree with @kd-ods about This statement MUST be a complete representation of the relationship between the declaring entity and the beneficial owner being confusing and I was just going to suggest MUST be a complete representation of the _interests_ between...

On terminology, I think it would be good to align what we're calling the different statements in docs (e.g. primary, secondary) with what the fields are named. I.e. have a 'primaryStatementID' field?

Primary/secondary is nice and concise, but it's quite generic, so I worry it might get overloaded in the future?

@kd-ods
Copy link
Collaborator

kd-ods commented Jul 24, 2019

@ScatteredInk - I know you're planning on wrapping up this thread and pointing to the implementation of this feature in BODS v0.2 (in the form of isComponent fields on all statement types and a componentStatementIDs field on Ownership-or-control Statements). One further question/thought that occurred to me (and apols it's only occurred to me recently).

Is the componentStatementIDs field best placed at the 'top' level in Ownership-or-control statements? It's possible that a BO has multiple interests in the same company (and the schema allows that to be represented by an O-o-c Statement containing an array of Interests). So shouldn't we map from an interest to its components, not from an O-o-c Statement to its components?

I'd do a nice diagram if I had time. In lieu of that - the diagram in this slide provides an example. Under a disclosure regime that required indirect ownership-or-control to be declared along with the first legal owner in the chain, Mitchell Courteney would have three interests to declare. Each of those interests would need to map to a different legal owner of Fowler Schocken (i.e. components in different ownership/control chains).

Of course, we could just require publishers who are publishing indirect BO components to only include one interest per Ownership-or-control Statement.

@timgdavies timgdavies modified the milestones: 0.2-rc, 0.3-rc Mar 23, 2020
@timgdavies
Copy link
Contributor

Having reviewed the current technical guidance on indirect ownership I think there is still more to be done on documentation and guidance, including:

  • Updated guidance copy
  • More detailed examples

@timgdavies timgdavies changed the title Indirect ownership: updates to guidance and schema Indirect ownership: improvements to guidance and schema Mar 23, 2020
@kd-ods
Copy link
Collaborator

kd-ods commented Oct 14, 2021

Closing, as progress on documenting this feature is now being made in #368

@kd-ods kd-ods closed this as completed Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants