Instability of PSC entry identifiers ('self' link) after updates have been made

We have encountered a potential issue / instability with the self link identifier in the PSC snapshots – it seems this identifier stays the same even if a PSC record has been updated with a completely different PSC entity.

Example

Note: certain fields have been omitted for brevity.

Before (in the 2017-09-12 snapshot):

{
  "company_number":"05138754",
  "data":{
    "etag":"3f0d4ac33cdc74453858078a186217b406ef7361",
    "identification":{
      "registration_number":"722401"
    },
    "kind":"corporate-entity-person-with-significant-control",
    "links":{
      "self":"/company/05138754/persons-with-significant-control/corporate-entity/CDqU8cEeFe73mA97RMYv3RD5muM"
    },
    "name":"Six Continents Hotels International Limited",
    "notified_on":"2016-04-06"
  }
}

After (in the 2018-02-20 snapshot):

{
  "company_number":"05138754",
  "data":{
    "etag":"3fd1582324e0a9aa6a30298d8934971073e066e2",
    "identification":{
      "registration_number":"6724223"
    },
    "kind":"corporate-entity-person-with-significant-control",
    "links":{
      "self":"/company/05138754/persons-with-significant-control/corporate-entity/CDqU8cEeFe73mA97RMYv3RD5muM"
    },
    "name":"Intercontinental (Pb) 1",
    "notified_on":"2016-04-06"
  }
}

… as evident: the self link is the same (and thus the record is considered the same between the two snapshots). However, the registration_number differs, which suggests these are completely different PSC registrations and should be provided with different identifiers?

It’s possible we’ve misunderstood the nature of this self link as an identifier, so clarifications on this behaviour would be greatly appreciated.

Good spot. Did the the etag change between the two dates for this record? In theory (as per documentation) this should change when there’s been a change to a record.

It seems that you can’t depend on IDs other than as an ID limited to a given company and a given type of PSC. For example there’s no endpoint to return details for a PSC-ID without specifying both the company number and the type of PSC. More info in this post:

http://forum.aws.chdev.org/t/people-with-significant-control-psc-snapshot/1594

Thanks @voracityemail.

Yes, it did. I’ve updated the original post to include this.

We don’t currently use the etag field to determine changes, but it sounds like something we should consider using (though not as an identifier).

Thanks for the info and link – that does indeed seem to be the case, which makes it very difficult to reliably update / synchronise known PSC subjects.

Any official word on this?

@jits

Thanks for bringing this issue to our attention. The self link returned in the call relates to that specific PSC registered against that company. The link will always remain the same for the same PSC.

Unfortunately what has happened in this case is the company has filed a change form for the PSC rather than resigning the existing PSC and appointing a new one.

We are investigating the reasons why this is occurring and will be looking to change the validation and customer behaviours to rectify the issue

Thanks

@mfairhurst

Thanks for the response @mfairhurst – good to understand the context behind this scenario.

For what it’s worth, when updating from a Sep 2017 snapshot this seems to be occurring for a fair few entries – at least in the order of 10s, possibly 100s or more. I can provide a more accurate number once we’ve completed a full import on our end and inspected the logs.

Please do keep us posted on any updates on this front.

Thanks

@jits

@mfairhurst

Thanks for your previous response about this issue. Could I check if you have any new information about what is causing the instability of the self links or information about what kind of situations this occurs in?

Do you have any plans for changing the way the self links work, or providing any other reliable identifiers for PSC entities?

Many thanks for your help,
Aleksi

@MArkWilliams @mfairhurst would you have any updates on this issue?