I've spent the last six weeks watching AI agents try to do KYB and corporate due-diligence work over MCP. The agents themselves are mostly fine. The data layer underneath them is the part that breaks. Three failure modes show up in almost every workflow, and most teams don't notice until a real review surfaces a bad result.
1. The aggregator-snapshot lag
The default architecture for a "company data API" is: a vendor (OpenCorporates, Sayari, Bureau van Dijk / Moody's Orbis, Kyckr, Refinitiv, Middesk) ingests the upstream registry on a refresh cycle, normalises everything into their schema, and resells the snapshot. Most snapshots refresh every 6–24 hours.
For a static dossier, that's fine. For an agent making a real-time decision, it's a hidden time bomb. UK Companies House publishes administration filings the same day they're submitted. A counterparty that filed Notice of Appointment of Administrators yesterday afternoon will not appear as dissolved in BvD's snapshot until tomorrow morning at the earliest, and often longer. If your agent's KYB step looks "active" because it's reading a snapshot that was correct twelve hours ago, the audit trail will record an active counterparty even though the counterparty was insolvent at the time of the call.
The fix isn't faster snapshots. It's calling the upstream registry directly. The trade-off is real: upstream APIs are slower, less normalised, sometimes flaky. But for any decision the agent might be cited on later, the upstream call is the only defensible source.
2. Schema normalisation that hides jurisdictional truth
Every registry has its own concept of who controls a company. UK Companies House publishes Persons of Significant Control (PSC), a binary "yes / no" flag with statutory thresholds. Germany's Handelsregister lists Geschäftsführer (managing directors) and shareholders separately, with shareholding written in the deed of incorporation. Korea's OpenDART exposes major shareholders with quarterly disclosure cadence. Cayman's CIMA and Companies Registry expose controlling parties only via TCSP-mediated requests for licensed entities.
Aggregators flatten all of this into a single "Beneficial Owners" table. The flattening is what kills you. A 25.1% shareholder in a German GmbH is not a PSC under UK rules but is reportable under German rules; if your agent receives a normalised "is_beneficial_owner = false" because the aggregator picked one jurisdiction's threshold, you've lost the actual answer. Worse, aggregators rarely flag which registry they decided not to surface.
The pattern that works: keep the upstream field names, return the upstream values unchanged, and let the agent reason about jurisdiction. If your tool exposes psc_data for UK and gesellschafter_data for DE, the agent figures out the difference. If you exposed beneficial_owner and lost the qualifier, the agent can't recover it.
3. Cross-border fan-out that doesn't fan out
The hardest problem in real KYB is following an ownership chain across registries. Iceland Foods Ltd is owned by WD FF MIDCO LIMITED is owned by ICELAND VLNCO LIMITED is owned by LANNIS LIMITED, which finally lists eight named individuals as PSCs. Three of those layers are UK Companies House, but the same shape appears with German GmbH owners of UK Ltd subsidiaries, Cayman holdcos owning Hong Kong opcos, Polish KRS spółka z o.o. owners of Czech ARES s.r.o.
If your data layer is one country at a time, the agent has to do registry routing itself. That means it has to know that "WD FF MIDCO LIMITED" is a UK company name, parse the company number into a jurisdiction code, switch which API to call, and stitch results across calls. Every one of those steps is a place where the LLM hallucinates a jurisdiction or fabricates a company number.
The solution is to expose a single tool surface that takes (jurisdiction, company_id) as parameters, and to make the agent's job purely sequential: read PSC, find a corporate PSC, recurse. The cross-border step then becomes "swap the jurisdiction parameter," not "change the entire vendor API."
What this points to
If you're building anything that uses live company data through an LLM, the data layer questions to ask are:
- Are tool responses byte-identical to the upstream registry, or is your vendor normalising fields you can't recover?
- Is the freshness real-time, or is your tool reading an N-hour-old snapshot?
- Can the same tool handle a UK PSC walk and a German Handelsregister walk and a Korean DART walk without rewriting the agent prompt?
We've been building OpenRegistry as a Streamable-HTTP MCP server that makes all three default behaviours: live calls to 27 government registries, raw upstream field names, single tool surface for cross-border fan-out. The free anonymous tier works in Claude Desktop, Cursor, Cline, Goose, Zed and the Gemini CLI with one config line. But the underlying point isn't the tool. It's that aggregator-shaped APIs are the wrong architecture for agentic workflows on regulated data, and the failure modes show up in production, not in benchmarks.
Top comments (0)