Are individuals ever moved from 'Officer' to 'Person w/ Significant Control'?

I am reviewing/testing some queries originally requested from the API back in Dec. and I can see several companies for which the officer JSON file is now blank. It appears that the individual in question has been moved to a ‘Person with Significant Control (PSC)’.

I didn’t run the original code but I’ve checked it and I can see that it doesn’t make a request to PSC API, so this is the only conclusion that I can come to. Is this possible?

If this is the case, how can I get the same information from the PSC API? I don’t understand where I obtain the PSC ID from.

You say “the JSON is blank” and that’s odd since officers shouldn’t disappear from the list, they should get a resigned_on field and increase the inactive_count total. Apologies if you already checked the following but if not and you don’t get a JSON body at all I’d check that your code is working:

  • Are other calls to the API working in your code (to check the API key and your call functionality)?
  • Are you getting an http error?
  • Are the call parameters correct? E.g. you code isn’t restricting the register_type of officers etc. (endpoint documentation)?
  • Maybe check the your example company numbers in CH Beta to ensure that CH haven’t lost them etc. You’d be able to see the officers there including status e.g. active / ceased and the PSCs.

If you are getting some JSON back:

  • What numbers do you have in the active_count and inactive_count members in the main JSON object? If officers “moved to a PSC” I’d have thought a) they’d appear in the inactive_count total and b) the officer entry in the list should have a resigned_on field with the date they resigned.
  • Again you should be able to see the officers and their status in Beta and check also the PSCs there.

Obviously officers may or may not be PSCs (and vice versa) and someone could cease being an officer but still be a PSC (or become one) but I’d expect there still to be an entry in the officers list as explained above. You said you were rechecking ones you’d last seen “back in Dec” so I’m guessing that they shouldn’t have disappeared under the CH “old data” rule (see footnote 1).

Short answer - just request the PSC list to get all PSCs (and their IDs). Then it’s up to you to look through the data and match an officer and a PSC. Yes - the PSC ID and officer ID are unrelated as far as I know.

When checking data it is possible that names / address / DOB information will not correspond for what you know to be the same person. Of course, someone could legitimately have multiple addresses and supply these for their different roles, or supply different versions of their name. See the CH service info / disclaimer - essentially “we supply exactly the data we’re given (unless there’s e.g. nefarious intent) and indeed we are required to do so”.

Further, (as far as I know) neither Officer ID nor PSC ID (for the same person) have any relation between companies.
For officer ID see:

For PSC IDs see:

Footnote 1:
I don’t know about any limits for the officers list but in e.g. the officer appointments list entries do disappear so corporate officers could be affected. However that should only be if it’s over six years from when a company closes / is dissolved. So unless the officers you saw first time were corporate officers and those companies had already closed almost 6 years ago data should still be around.

Thanks for the detailed response, I will try to clarify.

I can retrieve officer and company JSON files for almost every company except a select few that return no officer JSON file. The response I get is ‘[ ]’ - so nothing at all, not a ‘blank JSON’ like I said incorrectly before. I looked up some of these companies using CH Beta before my original post and I can see that there are no officers - “There are no officer details available for this company”.

When I tab across to PSC on CH Beta, I can see that the person in my original ‘officer list’ (to which I am comparing) is actually listed as a PSC. I don’t understand this because the code I am using doesn’t call the PSC API, so how was this information retrieved originally?

The only 2 explanations I can see are either I haven’t been sent the complete code (seems unlikely) or that these people were originally listed incorrectly as officers (directors) and have now been moved to PSCs, leaving ‘[ ]’ in their wake.

Thanks for the information about PSC IDs, I will investigate this.

[quote=“neil_whitfield, post:3, topic:1590”]
The response I get is ‘[ ]’
[/quote]]

Hmm odd - I’d have expected ‘{}’ as CH normally return objects not arrays even for blank “returns” if I recall correctly. So definitely no active_count and inactive_count then?

As far as I’m aware companies can be incorporated by another concern who then pass the new company to its “real” officers. Offhand can’t remember whether there’s allowed to be a period where the “opening” officers resign and the company has no officers before adding new ones. This still wouldn’t match your case however as the “opening” officers should still be recorded but with ceased_on member fields.

Before saying “sounds like there is a data issue here at CH end, shout out to them with examples” I’d just check the main company profile resource for your examples:

  • Is there a partial_data_available member? Companies House has only limited data for some types of company. The constants that appear in this member point to the registry holding more info.
    Not the place for the full detail here but the list includes some kinds of financial institution, Royal Charter corporations etc. A hint is the company number. If it starts with IP, SP, RC, SC, NP, RS, AC, SI, NO, SR, SA, IC (and some others?) or has letters at the other end (as in SP0001WS) then CH may not have data.
  • Check the type member - as stated above some more “obscure” types may not fit the usual pattern.
  • Is there a branch_company_details member e.g. is this a UK branch office for foreign company? (Also company number should start “BR”). These have two CH entries - the parent foreign company and the UK branch, and if I recall correcly the officers are only recorded on one. I think they’re on the parent. Not sure about PSCs in this case… See also the next item:
  • Check the links member - is there an officers member within this? If not, probably no response should be expected from the officers endpoint! That might be for reasons above / below.
  • Some very old companies may have unexpected data or be lacking expected things.

(I’m speculating now as I don’t remember seeing anything quite like you reported).

  • Is the company long closed / been dissolved etc? Or were some of the officers long-defunct companies? Data may disappear as I mentioned previously.
  • If not, was it closed a long time ago but more recently re-opened or restored (you can check this in filing history, if it exists - if not try looking up on WebCHeck)? Sometimes this happens, normally as part of court proceedings and odd data may result - search this forum for more info.

My mistake, {} is returned, so an empty object. An 404 error code is sent back too, which I also get using CH Beta.

There doesn’t appear to be anything special about these companies and the examples I am looking at were registered in December 2017. In the Links member of the company profile resource (of the two I have just checked), there are no officer members, so it looks like everything is consistent (now, at least) on CH’s end.

My original question was about officers being moved to PSCs but are you saying that it is unusual for the officer response to be {}?

I can message you a company number example, if you want.

Sorry, long response again. Summary (4 points!):

  1. From the original post:

I don’t know. All the rest of my waffle was saying “something seems to be inconsistent e.g. as per your 2nd post - no officer details returned and yet there’s PSC information - that’s strange”.

Answered, 1st reply.

No. As I’d asked about http errors and you’d not mentioned one, and also said you got an array “[ ]” back, I was saying that that combination was one I hadn’t seen before!

Are you sure you’ve got the correct company numbers when you’re using the API (and e.g. the code isn’t clipping / scrambling them) and that they’re the same as you tried in CH Beta?
Reason: I can replicate most of what you describe with a bogus company number.
Also you’ve sown the seed of doubt with “I didn’t run the original …”!
That CH Beta says ‘no officers’ but shows PSCs (for anything) - that’s still odd. I don’t say it’s impossible…

Full detail:

Ah, the missing information (some of it):

Well 404 = “not found” and in most cases IIRC if you ask Companies House for something they don’t have you’ll get exactly that: http status 404 and an empty JSON object (*1).

As you say, CH response is consistent: e.g. they don’t advertise any officers in the links section and then give you a normal (for CH) “nothing to see here” response when you ask for the officers. ( *2)

I can get a 404 + { } - if I provide a non-existent company number e.g. /company/BG932839/officers"

For others where CH doesn’t hold the information I get the company list, but with nothing in it e.g.
“/company/SP0001WS/officers”:

Response:

{
“active_count” : 0, “kind” : “officer-list”, “start_index” : 0, “items”: [ ], “total_results” : 0, “etag” : “”, “links” : {}, “items_per_page” : 35, “resigned_count” : 0
}

In the last part of that do you mean:

  • “if I paste my company number into the CH Beta URL I get ‘this page cannot be found’ e.g. if I go to https://beta.companieshouse.gov.uk/company/BG038273/persons-with-significant-control” (I’ve used an example non-existent company number). That sounds normal and consistent with above.
  • "if browse I go to CH Beta site, search for the company number, then click on ‘People’, then ‘Persons with significant control’ I get a 404 error / ‘this page cannot be found’ ". That would look like CH have a problem with their data for these companies (and their code)!

(Summary)

No need to message me, just post 'em up on the forum. An example is a thousand words at cross-purposes.

Digressions:
*1
This is general but not universal across CH API e.g.:

  • If no such company exists when requesting company profile, you get an error 404 and an error object. E.g. “/company/BG932839”
  • Filing history may give you http 200 success and a filing history object but a member within it stating there isn’t any. E.g. “/company/SP0001WS/filing-history”

*2
I wouldn’t treat something being missing from the links section as a guarantee it doesn’t exist. Sorry, can’t remember any examples offhand.

Sorry about the 404 error business - I didn’t realise it was being sent back at first.

In the interests of getting this wrapped up and not taking up any more of your time, CH Beta showing the company exists, there are no officers and there is a PSC:

Then either paste the company number in here or use your code, and you should get {} back and a 404 error code.

This company clearly has a data issue, I will get it looked at immediately.

data sorted now. sorry for the inconvenience.

Hi Mark, thanks for sorting that one. There are quite a few with the same behaviour, close to that company number:

110938*

16-26
29-31
34
36
38-39
42-43
45

I believe I have seen others before but can’t confirm - I didn’t realise it was an issue until I looked more closely. They tend to come in clusters, like above.

I will get these looked at.
Thanks for taking the time to post your findings here.

My bad, I should have suggested posting examples first.

Thanks for the help last time, it was really appreciated. I think I have found a few more examples of the same issue:

11064639
11064731
11064734
11064709
11064716
11064712
11064715
11064733
11064735
11064736
11064739
11064742
11064747
11064748
11064749
11064757
11064758
11064760
11064762
11064764
11064765
11064768
11064773
11064775
11064783
11065432
11065487
11078536
11079891
11079895
11079897
11079954
11079984
11079991
11080004
11080017
11080038
11080045
11080046
11080049
11080067
11080076
11080082
11080188
11080216
11084376
11084385
11084405
11085965
11086564
11086566
11086568
11087872
11093854
11093856
11093884
NI649537
SC581573
SC581576
SC581574
SC581617
SC582325
SC582334
SC582653
SC582655
SC582658

I will get these refreshed/corrected ASAP.

I have just been told that these should all now be fixed.
I have checked a handful and they do look ok.
i will be running a check in the database for any others that are missing officers so we can determine why this has happened and put measures in place to prevent it happening in the future.
Again, thanks for taking the time to let us know about this issue.