Companies House processed over 6 million filings during 2024. Many reach the public register minutes after submission. That speed is routine for a statutory register. Aggregator databases work differently. They pull periodic snapshots and refresh on their own timetable.
KYB teams feel the gap during onboarding. A merchant signs up and states the company formed last week. Your system queries an aggregator cache and returns nothing because the last bulk import ran months earlier. The record exists already. The vendor has simply not collected it.
On paper the delay looks minor. In operations it produces false negatives, manual review queues, and audit trails that do not line up with the public record.
The registry of record behaves differently
National registers publish the fields the law requires. In the United Kingdom that means Companies House exposes the official company number, incorporation date, registered office address, officer appointments, and the filing log. Each identifier originates inside the registrar’s own system.
Query the register directly and you see those upstream attributes without reinterpretation. A typical company profile response contains fields such as:
company_numbercompany_namecompany_statusdate_of_creationregistered_office_address
Officer data appears through a separate endpoint. Those entries carry attributes like officer_role, appointed_on, and resigned_on. Filings follow the same pattern. When a company submits accounts or a confirmation statement, the register lists the event with fields including category, date, and transaction_id, which points to the original submission record.
These are register facts. Not derived fields. That distinction matters the moment compliance asks where a value originated.
Where aggregator caching causes KYB failures
Cached datasets drift away from the source over time. A register entry might change this morning. The mirrored dataset could sit unchanged for weeks. If onboarding checks read the mirror rather than the register, the system evaluates stale information.
Three patterns show up again and again in KYB queues.
A newly incorporated company applies for an account. The registrar already issued the company number. Your provider still shows no match, so the onboarding flow marks the applicant as unverifiable.
A director resigns after enforcement action. The update appears at the register the same day. The cached dataset still lists the officer as active. Internal review assumes the person retains control.
A dissolved company restores its status through court order. The registrar updates the company_status field soon after restoration. Mirror datasets sometimes keep the dissolved flag until the next import cycle.
Each case creates the same problem. The register says one thing. Your dataset says another.
What direct registry queries look like
The practical option is simple: query the register when the KYB check runs. An MCP client using OpenRegistry sends a tool call and receives the fields returned by the jurisdiction.
Searching Companies House by name might look like this:
search_companies({
"jurisdiction": "GB",
"query": "ACME PAYMENTS LTD"
})
Once you have the company number, the profile request is straightforward:
get_company_profile({
"jurisdiction": "GB",
"company_number": "12345678"
})
The response includes a jurisdiction_data block that mirrors the payload supplied by Companies House. No reinterpretation. No enrichment layer. Only the minimal schema fields needed so cross‑country queries stay consistent.
That detail becomes useful during regulatory review. An auditor can trace the field directly to the upstream register entry.
Officers and filing history come through separate calls. The structure follows the source register closely. Little abstraction.
What you will not get from the registry
Direct register queries do not answer every KYB question. Some ownership information in Europe moved behind AML access gates after the CJEU ruling in case C‑601/20. Germany’s Transparenzregister is a well‑known example. Public company registers still expose directors and filings. Beneficial ownership often requires authorised access.
Registers also do not provide sanctions checks, credit assessments, or risk scoring. Those sit in separate systems layered on top of the base company record.
Treat the register as the reference point for legal existence and current status. Additional analysis happens afterwards.
Why auditors favour the registry path
Audit reviews usually circle back to a simple question: where did this company record originate?
If the answer is an aggregator dataset, the next conversation covers refresh frequency, reconciliation routines, and how the system handles conflicts between the dataset and the official register. That explanation can grow complicated, especially when values diverge.
If the answer is the register itself, the chain of evidence stays short. The onboarding system queried the official register at a specific timestamp. The returned fields match the state of the register at that moment.
Clear provenance matters. Compliance teams increasingly query national registers during onboarding rather than relying on cached mirrors. The register remains the authoritative source for company existence and legal status.
OpenRegistry exposes 27 national company registers through a single MCP endpoint so an AI assistant or internal agent can query the register of incorporation during KYB checks. Details and connection instructions are at https://openregistry.sophymarine.com
Top comments (0)