Why Company Registry APIs Fail (And What Compliance Teams Can Do About It)

Compliance teams aren’t used to live registry connections. I know because I head Kyckr’s Customer Delivery team.

I spend my days managing customer service, working with the engineering team to resolve problems, and workshopping our API with compliance teams at global obliged entities that integrate our API into their built-in-house KYB workflows.

Two things strike me about the compliance teams I speak to. First, they’re smart – sometimes incredibly so. Second, they don’t initially understand the realities of a live registry network. Which isn’t their fault.

Compliance teams aren't used to live registry connections

Up until very recently, most compliance teams either enjoyed the instant gratification of retrieving data from third-party databases or they manually verified business customers using a company register’s online portal.

The teams that are used to registry portals might have only used 3-5 in their careers. They know how those work very well, but no more. 

Others are moving from a stored data provider with full control over the data returned in the search. They’re used to a consistent experience, and don't consider that the API of each country’s registry is different, and not always as optimised or well-funded as the registries that they’re used to. 

They assume that, if a country is in the EU or in a well-funded jurisdiction, its API will work as well as Companies House’s API. They don’t anticipate that all registries behave differently, and that is about the most consistent thing about them.

Each registry has its quirks, so master them

This reality hits home when you connect with their APIs, which is what Kyckr does – connecting directly to over 300 registries, all of which play by slightly different rules. This causes some initial confusion for compliance and engineering teams at banks, law firms, and other obliged entities that I speak to.

When they begin building their Kyckr integration, their developer tests our API, usually checking a list of their top jurisdictions. Naturally, they test the API with a common name search.

I'll use a recent example. A developer searched Italy’s Infocamere using “Peroni”. Instead of displaying thousands of results, as they expected, the search broke. The developer claimed this was proof that our API didn’t work. After all, “Peroni” is a household name with multiple subsidiaries throughout Italy. It should have, like Companies House’s API, returned thousands of results cleanly.

Company registries don’t behave the same

The Companies House API has good fuzzy logic, handling generic name searches without falling over, so if you type in something as generic as “hotel”, it will bring back hundreds of thousands of results without breaking. Italy’s API, meanwhile, can’t. 

In this case, I advised the developer to search Italy’s registry using the entity’s full name. It worked. The result was clean and quick.

So, what works for Italy doesn’t necessarily work for, say, Australia. By way of example, the ASIC API sometimes returns an entity profile so laden with data that it breaks.

Registries don’t play by the same rules. Each one has its quirks. The point is to master them. 

This brings me to the second breaking point for live registry connections.

Your workflow is connected to multiple breaking points

If your workflow directly connects to multiple registries, it is a product built on infrastructure that you don’t control.

This is the trade-off of retrieving live data from registries: it is better for the audit trail, but it’s vulnerable because each live connection can and does experience disruption.

In my experience, there are three ways this manifests itself most often: either the registry updates its API, you need to update yours, or a ‘black swan’ event causes unforeseen disruption.

All three failure nodes require a backup plan.

The first failure node – when the registry updates its API (which happens all the time) – is predictable because the registries are usually kind enough to tell you in advance of scheduled maintenance. 

But when a registry changes its API, it means that you must change yours too. And this gets us into the weeds of the second failure node.

If your KYB workflow is built on hundreds of direct registry connections, making one change risks breaking everything. In my experience, this usually happens when a registry changes its API without warning, often a registry in one of the least-used jurisdictions.

It might introduce a slash to its company registration numbers, leading to an API search breaking. Your engineering team makes a small fix to the API, but this breaks something else, causing a knock-on effect impacting as much as ten other integrations.

Compliance teams need a backup plan 

A failed registry search doesn’t mean that the registry is broken, the integrations are bad, or the company doesn’t exist. 

Perhaps, as is the case with Italy, the search returned too many results. The registry’s API might have changed, or the registry could be experiencing too much traffic. However, disruptions slow onboarding workflows, leading to potential customers dropping off, frustrating analysts in the meantime. 

There isn’t one perfect fix. No two registries are the same. In this spirit, compliance teams should implement fallback options that address each registry’s quirks – step-by-step procedures that can be automated. Circling back to Italy, a first step could be to simply search using the entity’s full name. For the other steps, Kyckr can help.

Without planning for such eventualities, you run the risk of enabling compliance teams to disrupt onboarding and burden engineering with unnecessary tickets. 

Most of the time, the registry is working fine. Your team just doesn’t speak its language yet.