-
Notifications
You must be signed in to change notification settings - Fork 13
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
Comments
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: 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. The specific guidance I suggest is:
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:
The guidance we want here is something along the lines of: Publishing the details of an indirect chain of ownership may result in
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. Note that in this example:
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:
But I think this can perhaps be simplified further with just a renamed |
@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:
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."
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:
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. |
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:
And a couple of specific ones:
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? |
@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. |
Having reviewed the current technical guidance on indirect ownership I think there is still more to be done on documentation and guidance, including:
|
Closing, as progress on documenting this feature is now being made in #368 |
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:
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.The text was updated successfully, but these errors were encountered: