Separate reasons for unspecified ownershipOrControlStatements into different codelists

[stevenday]

In #96, we changed the codelist for the reason field in unspecified ownershipOrControlStatements to include more reasons. It went from:

• unknown,
• noBeneficialOwners
• noNotifiableOwners

to:

• no-beneficial-owners
• subject-unable-to-confirm-or-identify-beneficial-owner
• interested-party-has-not-provided-information
• subject-exempt-from-disclosure
• interested-party-exempt-from-disclosure
• unknown

However, we also have guidance that states:

Where there is a natural person with ownership or control, but their name or details are not known, or cannot be disclosed for some reason, unspecified should not be used, but instead a reference to a personStatement should be provided but identifying details of the person left blank.

To me, that seems to make interested-party-has-not-provided-information, subject-exempt-from-disclosure and interested-party-exempt-from-disclosure completely defunct? They all indicate there is a person, so there should be an unknownPerson personStatement?

It also potentially contradicts with the confirm part of subject-unable-to-confirm-or-identify-beneficial-owner. In the PSC register, reasons like this mean that someone has been identified, but the details haven't been confirmed. e.g. for psc-details-not-confirmed

The company has identified a registrable person in relation to the company but all the required particulars of that person have not been confirmed"

Would just subject-unable-to-identify-beneficial-owner be clearer?

I've been trying to update the register's export process, in particular matching up PSC's reasons to this and found it quite confusing. Are there other cases I'm missing where they're necessary?

[stevenday]

A related but more specific, question. How would you map something like PSC's super secure exemption? Reading the ownershipOrControlStatement guidance, I went for interested-party-exempt-from-disclosure. However, looking a personStatement, I could just as easily map them as a anonymousPerson (which I've now switched to).

If we recommend something like this super-secure system in our wider guidance (I think we do in the privacy report) it seems worth having an explicit mention of when exemption differs from anonymity in the BODS guidance?

[ScatteredInk]

Thanks @stevenday. Yes - this is not very clear at the moment as missing info can appear in multiple places (in a person, entity or ownership-or-control statement but draws from a single codelist).

I think it makes sense to split that codelist into separate ones but that brings its own complications and I couldn't work out how to do it without a big overhaul to the documentation, which we didn't have time for before the 0.2 release. There will be a bigger pool of example data to draw on when I merge in the Ukraine ones, so hopefully that will help with the ambiguous documentation around this in the short term.

Would just subject-unable-to-identify-beneficial-owner be clearer?

That's a good idea - will make that change in 0.3.

For a super secure person, I would model as an anonymousPerson with:

"unspecifiedPersonDetails": {
      "reason": "interested-party-exempt-from-disclosure",
      "description": "set phrase from companies house enumerations describing SSP status" 
    }

[ScatteredInk]

Updated title to reflect the task of aligning codelists and docs with the structure of the standard.

[kd-ods]

Just noting here that 'subject-exempt-from-disclosure' should be re-worded to sthg like 'subject-exempt-from-disclosing-beneficial-owners' for clarity. This brings the code in line with its described meaning. Otherwise it can be interpreted to mean that the subject is exempt from disclosing its own identity (esp since the equivalent exists at the other end of the relation as interested-party-exempt-from-disclosure).