The 3 Biggest Challenges of Integrating Directly to Company Registries

Building your own company registry integrations is harder, slower, and riskier than most compliance teams expect. Kyckr has been doing it since 2007. Developer Team Lead Eddie Barron and Product Manager Laura O'Mahony have seen every failure mode. Here is what they told us. 

Challenge 1: Registry data is not standardised, and the gap between registries is large

"It's difficult when you're building your own KYB in-house," said Eddie. "You want one API to deliver the same data fields every time. It allows the API to be coded comfortably into your frontend. Annoyingly, it is rarely this simple.” 

Some registry APIs return clean, structured data. Connect to the UK's Companies House, and you get well-formed JSON, named fields, and a logical data structure. That integration is tractable, even if it still requires multiple calls to build a complete entity profile. 

Others are a different matter. Legacy registries – some built fifteen years ago – use SOAP-based architecture that returns raw XML. Before that data is usable in any modern compliance workflow, it must be parsed, converted to JSON, and mapped to the fields your system expects. There is no "Registration Date" handed to you. No "Director" object. There are filings, and your developers must decode them every time, for every query. 

The gap between these two experiences is not trivial. Based on Kyckr's experience, a clean RESTful integration might take days. A legacy SOAP integration, with its normalisation logic, edge case handling, and testing, can take weeks. And once it's built, it needs watching. Registries change their data formats. If a new filing type appears and your parser doesn't recognise it, your workflow can return an incomplete entity profile without flagging an error. 

That's not a technical inconvenience. If your entity profile is missing a director because your parser didn't handle a format change, your risk assessment is wrong. Under FCA Principle 3, the obligation to maintain adequate systems and controls sits with you, not with the registry. If a parser failure produces incomplete CDD data and that data informs a flawed risk assessment, the control weakness is yours to answer for. 

Challenge 2: A single entity profile often requires multiple API calls, each one a failure point

Here's something developers learn quickly and compliance teams discover slowly: asking a registry for a full entity profile is often not a single API call. 

Laura explained that some registries return everything in one data block. "All that these APIs take is just one call, one response, all the data you need. Others require multiple calls.”  

To build a full Enhanced Profile, a KYB integration must make separate synchronous calls for basic company data, officers, shareholders, and persons with significant control. Each call must succeed. Each response must be stitched together. If any one of them times out or returns an error, your profile is incomplete. 

Some registries require half a dozen API calls for a single Enhanced Profile. Each call is a potential failure point. Each response must be normalised and combined with the others before your system can do anything useful with it. 

For a compliance team with a 5-second SLA on business verification, that architecture creates a problem before your internal processing time is even counted. You either accept the breach as a feature of doing business in certain jurisdictions, or you build a caching and pre-fetching layer sophisticated enough to hide it. Neither option was in the original plan.

Challenge 3: No two registries are the same, and they change without warning

There's a tendency, when planning a multi-jurisdiction KYB integration, to treat the second registry as faster than the first because you've already done the hard work. You've built the integration framework. You understand the pattern. 

"No two APIs are the same," said Eddie. 

He meant it as a warning. 

Some are RESTful, well-documented, and relatively clean. Others are SOAP-based, return un-normalised data, and require as many individual calls as the entity has filings. For a company with an extensive filing history, that can mean dozens of sequential requests. Some route these through intermediary systems that add authentication layers and, when those intermediary systems are retired, force you to rebuild the connection entirely. 

Then there are outages. Planned maintenance windows and unplanned failures are a feature of government registry infrastructure everywhere. A direct integration goes dark when its underlying data source does. There is no SLA. There is no obligation on the registry to warn you before it changes. 

Under Regulation 30 of the Money Laundering Regulations 2017, verification must occur before a business relationship is established. The "as soon as practicable" exception is narrow, requires documented justification, and does not apply where ML/TF risk is elevated. A multi-day registry outage is not a documented exception. It is a gap in your systems and controls. 

The FCA doesn't need to demonstrate that money has been laundered. It needs to show that your systems created the conditions for it. An integration that fails every time its data source does, with no fallback and no notification, is not an adequate system.

The cost that never appears in the original plan

Based on Kyckr's experience integrating and maintaining live connections to registries across more than 100 countries, initial development across ten registries – each with its own architecture, authentication requirements, data format, and quirks – runs to several hundred hours of engineering time. That's before testing, before edge cases, before the first production query returns something unexpected. 

Maintenance compounds it. Registries change their APIs. Fields are added, deprecated, or renamed. Authentication mechanisms are updated. Each change requires review, impact assessment, updated normalisation logic, and retesting. For active registries, that is not a once-a-year exercise. It is continuous. 

The cost that never appears in the original business case is what your developers are not building while they maintain registry parsers. Every hour spent debugging an XML conversion is an hour not spent on risk scoring, ongoing monitoring, or customer experience. Regulators do not accept "we were rebuilding our registry connection" as mitigation for a CDD failure. The obligation is yours regardless of where the infrastructure problem sits. 

The comparison your technology team will make is build cost versus subscription cost. That is the wrong comparison. The right one is subscription cost versus build cost per registry, ongoing maintenance as architectures change, engineering capacity diverted from your core compliance workflow, and operational risk from connections that carry no SLA and no obligation to notify you when they change. At ten jurisdictions, that calculation looks very different from what it does at two. Most global obliged entities are not working in two jurisdictions. 

One integration. Every registry.

Kyckr maintains live API connections to more than 300 company registries across 120 countries. The data is retrieved from the primary source at the point of request, normalised into a single schema, and returned through one integration. 

Kyckr builds and maintains access to company registries, so compliance teams can do their job. 

One authentication layer. One data schema. One team responsible for the connections.