Companies House provided OAuth for KYC

Apologies if this has been covered elsewhere; I’ve searched but can’t find any similar topics.

It might be useful if Companies House could provide some sort of OAuth-like functionality that would allow third parties to confirm that an individual owns or is responsible for a business.

Ideally (I think), there would be an OAuth style flow where a user is directed to Companies House, logs in with their “WebFiling” credentials and a token is sent back to the requesting site that can be exchanged for the company number of the company the individual “owns”.

1 Like

We’re adding the finishing touches to our OAuth2 API, which will make it suitable for general use. If you pass in the correct scope during the authorisation_code request, the user will also be prompted to provide the appropriate authentication for the requested company. The returned access_token will be authorised for filing against that company.

To make this work for you, you would have the user search for their company, and then request authorisation for it using the necessary scope. If you get a successful authorisation result, you know that identity is authorised to file for the company.

Companies House does have any knowledge between an identity (email registration) and a company, so cannot provide that kind of feedback. The concept of “ownership” of a company is a weak one. The only true way to determine this is to match against company officers, which is rather difficult.

We are currently consulting on a piece of work to establish a chain of responsibility for a company, which may provide the information you are looking for in the future.

I’ve been searching the forums for information relating to this kind of functionality. Can anyone shed light on whether this is the accepted approach for connecting an individual to a company officer?

We’ve implemented this flow using the registered-office-address.update scope with the cono, and this works just about ok for testing. Albeit it requires requesting a permission that we will not use, which creates uncertainty with users. However, the problem with this approach is that in the event that the user enter a cono for which they do not have authority, the OAuth flow crashes with a 500 error.

Currently the user profile provides no way to connect the authenticated user to an appointed officer (the ID of the user is unrelated and the first and last names are null).

It would be good to understand if this behaviour is intentionally obfuscated.