DEV Community

Cover image for ARES company data: fields KYB teams actually use
OpenRegistry
OpenRegistry

Posted on

ARES company data: fields KYB teams actually use

#programming #kyb #compliance #mcp

ARES exposes more cross-register detail than most teams realise

A Czech company lookup can return Commercial Register data, Trade Register data and VAT references in the same response. Teams often notice the overlap only after two upstream records drift out of sync for a few hours following a filing.

ARES is run by the Czech Ministry of Finance. It fronts several public registers instead of acting as one canonical database in the style of Companies House in Great Britain. That changes onboarding logic.

We use ARES as the registry-of-record source during Czech incorporation reviews, then compare discrepancies against filing timestamps and source references. OpenRegistry keeps the upstream jurisdiction_data payload intact rather than flattening everything into a simplified schema. Audit teams care about that distinction later.

The fields that usually matter during onboarding

A standard get_company_profile call for a Czech entity can return:

  • ico as the Czech company identifier
  • obchodniJmeno for the registered business name
  • pravniForma describing the legal form
  • sidlo for the registered address
  • datumVzniku showing incorporation date
  • stavSubjektu for current operating status
  • references to source registers inside the ARES payload

The upstream response also exposes register-specific fragments through jurisdiction_data. We lean on those fields when a merchant describes one activity during onboarding while the Trade Register records something narrower or older.

Name matching causes regular friction. Czech legal names often contain punctuation or legal suffixes that vanish from onboarding forms copied in by hand. ARES search results usually preserve the exact register representation. Fewer false mismatches end up in manual review queues.

Raw registry preservation matters more than convenience formatting. Internal audit teams eventually ask where a status originated, especially when onboarding happened close to an insolvency filing or licence suspension. Screenshots are rarely enough.

What ARES does not give you

ARES has clear limits.

It is not a beneficial ownership register. Czech UBO access changed after AMLD 5 litigation across Europe and the CJEU C-601/20 decision. Public access is narrower now than in earlier European register models.

OpenRegistry also does not add sanctions screening, PEP checks or credit scoring to Czech entities. Those checks belong elsewhere.

Historical snapshots are another common misunderstanding. OpenRegistry queries the live register each time. We do not keep a private archive of earlier Czech registry states.

Some filing documents and court records still sit inside separate Czech judicial systems rather than appearing directly through ARES. Workflows that depend on deeds or historical constitutional documents may still need direct court-register retrieval. We ran into this with older insolvency-linked filings.

Querying Czech entities through MCP

ARES is available through the OpenRegistry MCP server for live lookups from AI clients and internal tooling.

A basic company search by IÄŒO or partial name:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "CZ",
    "query": "27864651"
  }
}
Enter fullscreen mode Exit fullscreen mode

For onboarding flows, we usually follow that with a direct profile fetch:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "CZ",
    "company_number": "27864651"
  }
}
Enter fullscreen mode Exit fullscreen mode

The operational pattern that tends to hold up best is storing both the normalised fields and the raw jurisdiction_data object. During a regulator review, that gives evidence tied directly to the Czech registry response rather than an internal interpretation layer.

The same MCP interface also works across the other registers currently exposed by OpenRegistry, including Companies House in Great Britain, the Finnish Trade Register and the Dutch Handelsregister.

The Czech registry quirks worth planning for

ARES is fairly stable. Edge cases still matter.

Status propagation between Czech systems is not always simultaneous. A company can appear active in one source while another still shows a pending update. We treat those mismatches as manual-review triggers instead of automatic failures. Saves pointless escalations.

Address formatting creates another category of false positives. Czech addresses often include district references, municipal subdivisions and orientation numbers that merchants abbreviate aggressively. Exact string matching fails a lot.

Legal form handling deserves attention too. Czech entities such as s.r.o. and a.s. carry different governance expectations during KYB reviews. Keeping the original pravniForma value from ARES avoids downstream mapping errors that are surprisingly tedious to unwind later.

ARES is also not a sanctions system. Ownership chains still need separate resolution before running OFAC 50% analysis or UK sanctions checks.

Direct registry access and audit trails

Teams using aggregator datasets eventually hit the same problem: stale records with weak provenance. A regulator asks where a company status came from, then someone discovers the provider updated its Czech mirror days after the filing itself.

Direct registry retrieval removes that ambiguity. The onboarding decision stays tied to the registry response available at review time. That matters during investigations.

It also cuts reconciliation work caused by third-party normalisation layers.

OpenRegistry exposes ARES through a free MCP endpoint with raw upstream fields preserved. Current jurisdiction coverage and connection details are listed at https://openregistry.sophymarine.com/mcp

Top comments (0)