DEV Community: OpenRegistry

How stale is company registry data? Measuring lag against the Companies House API

OpenRegistry — Fri, 11 Sep 2026 03:15:44 +0000

We build OpenRegistry, a live registry API. This post was written with AI assistance.

Every company-data product is either a live query or a copy. Copies are fine until the thing you care about changes after the copy was taken. This post shows how to measure that gap for UK companies yourself, using the free Companies House API, and what we saw when we tried it on four companies.

Why freshness matters

Know-your-business (KYB) checks ask simple questions: does this company exist, is it active, and who runs it? The answers change.

Picture a supplier-onboarding check on a Thursday. The director who signed your contract resigned on Monday, and the company filed the resignation on Wednesday. If your data source last synced on Tuesday, your check says she is still a director, and your file records that you verified her authority to sign. Nothing in the data is invented. It is just two days old.

So the useful question is not whether a source is "right", but how old it is at the moment you look.

How registry changes happen

A UK company tells Companies House about changes by filing forms. These are the ones that matter most for KYB:

Form	What it records
AP01	Director appointed
AP03	Secretary appointed
TM01	Director's appointment ended (resigned or removed)
TM02	Secretary's appointment ended
DS01	Company applies to be struck off voluntarily
GAZ1 / GAZ1(A)	Gazette notice of proposed strike-off (compulsory / voluntary)
NEWINC	Company incorporated

Two details make lag harder to measure than it looks:

Every change has two dates. The effective date is when the director actually resigned. The filing date is when Companies House registered the form. Companies have 14 days to report officer changes, so the register itself can trail reality. In the filing-history API these are action_date and date.
Some notices are dated in the future. A GAZ1(A) can show up in filing history dated for its scheduled Gazette publication. Only count filings dated on or before the day you are measuring, or you will get negative lag.

Volume matters too. Replaying the Companies House officers stream, we counted 100,000 officer events in 24.1 hours (7 to 8 September 2026). Most are updates to existing officer records rather than new appointments or resignations, but any copy of the register has to keep up with all of them.

How to measure lag yourself

You need a free API key from the Companies House developer hub. It is sent as the username in HTTP Basic auth, with an empty password.

The method:

Look up some companies on the source you want to test. Record what it shows and the date you looked.
Pull each company's filing history from Companies House.
For each relevant filing registered on or before the day you looked: lag ≥ day you looked − filing date.

This gives a lower bound. You know the copy was still behind when you looked, not when it caught up. Re-check daily if you want the upper bound too.

Python, standard library only:

import base64, json, os, urllib.request
from datetime import date

API = "https://api.company-information.service.gov.uk"
AUTH = "Basic " + base64.b64encode((os.environ["CH_API_KEY"] + ":").encode()).decode()

# Filing types that change what a KYB check would see
WATCH = {
    "AP01": "director appointed",
    "AP03": "secretary appointed",
    "TM01": "director resigned",
    "TM02": "secretary resigned",
    "DS01": "strike-off application",
    "GAZ1": "strike-off notice",
    "GAZ1(A)": "strike-off notice",
    "NEWINC": "incorporated",
}

def ch(path):
    req = urllib.request.Request(API + path, headers={"Authorization": AUTH})
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.load(r)

def changes(number, since, until):
    """Watched filings registered between `since` and `until` (inclusive)."""
    for f in ch(f"/company/{number}/filing-history?items_per_page=25")["items"]:
        if f["type"] in WATCH and since <= f["date"] <= until:
            yield f["type"], f.get("action_date") or f["date"], f["date"]

# What the third-party source showed, and the day you looked
OBSERVED = {
    "SC190660": ("2026-09-10", "status: Active"),
    "15150296": ("2026-09-10", "1 officer listed"),
    "12782688": ("2026-09-10", "resigned director shown as current"),
    "17450921": ("2026-09-10", "company not found"),
}

for number, (seen_on, shown) in OBSERVED.items():
    p = ch(f"/company/{number}")
    status = p.get("company_status_detail") or p["company_status"]
    print(f"{number}  register now: {status}")
    for ftype, effective, filed in changes(number, since="2026-09-01", until=seen_on):
        lag = (date.fromisoformat(seen_on) - date.fromisoformat(filed)).days
        print(f"  {ftype:<7} {WATCH[ftype]:<22} effective {effective}  filed {filed}"
              f"  | third party on {seen_on}: {shown}  -> lag >= {lag}d")

Output:

SC190660  register now: active-proposal-to-strike-off
  DS01    strike-off application effective 2026-09-08  filed 2026-09-08  | third party on 2026-09-10: status: Active  -> lag >= 2d
15150296  register now: active
  AP03    secretary appointed    effective 2026-09-09  filed 2026-09-09  | third party on 2026-09-10: 1 officer listed  -> lag >= 1d
12782688  register now: active
  TM01    director resigned      effective 2026-09-07  filed 2026-09-09  | third party on 2026-09-10: resigned director shown as current  -> lag >= 1d
17450921  register now: active
  NEWINC  incorporated           effective 2026-09-10  filed 2026-09-10  | third party on 2026-09-10: company not found  -> lag >= 0d

Exact timestamps with the streaming API

Filing history gives you dates. For timestamps, the Companies House streaming API pushes each change as it is published, with a published_at time and a timepoint cursor. It uses a separate stream key. You can replay from an earlier timepoint, which is how we measured the daily volume above:

import base64, json, os, urllib.request
from datetime import datetime

STREAM = "https://stream.companieshouse.gov.uk/officers"
AUTH = "Basic " + base64.b64encode((os.environ["CH_STREAM_KEY"] + ":").encode()).decode()

def event_at(timepoint):
    """Replay the stream from a timepoint and return the first event."""
    req = urllib.request.Request(f"{STREAM}?timepoint={timepoint}", headers={"Authorization": AUTH})
    with urllib.request.urlopen(req, timeout=60) as r:
        for line in r:
            if line.strip():                      # blank lines are heartbeats
                return json.loads(line)["event"]

a, b = event_at(61_100_000), event_at(61_200_000)
t = lambda e: datetime.fromisoformat(e["published_at"])
hours = (t(b) - t(a)).total_seconds() / 3600
print(f"{a['published_at']} -> {b['published_at']}")
print(f"{b['timepoint'] - a['timepoint']:,} officer events in {hours:.1f} hours")

Output:

2026-09-07T17:35:03 -> 2026-09-08T17:44:02
100,000 officer events in 24.1 hours

What we found

On the morning of 10 September 2026 we looked up four companies with recent changes on OpenCorporates, a widely used company-data aggregator, and compared them with Companies House.

Company number	Change on the register	Effective	Filed	Third party on 10 Sep	Lag (at least)
SC190660	Voluntary strike-off application (DS01). Register status: active, proposal to strike off	8 Sep	8 Sep	Active, no strike-off flag	2 days
15150296	Secretary appointed (AP03): Teresa D* S****	9 Sep	9 Sep	1 officer; secretary not listed	1 day
12782688	Director resigned (TM01): Esther R* F***	7 Sep	9 Sep	Still listed as a current director	1 day (3 from the resignation)
17450921	Incorporated (NEWINC)	10 Sep	10 Sep	Company not found	Same day

What stands out:

All four lags are short. One to two days from filing is what you would expect from a pipeline that refreshes about daily. That is the normal trade-off of any copy, not a scandal.
"Updated today" is not "includes today's filings". The page for 15150296 said it last updated from source on 9 September, the same day the AP03 was filed. The likeliest explanation is timing: the sync ran before that filing was published.
12782688 shows why the two dates matter. The resignation took effect on 7 September but only reached the register on 9 September. Against reality, the third-party record was three days behind, and two of those days happened before the aggregator could have known.
17450921 was incorporated that morning. Almost any copy misses a same-day incorporation. It is only useful as a test of how quickly a source picks up new companies.

Limits

A tiny, non-random sample. Four companies, all chosen because they had just changed, which is the worst case for any copy. This says nothing about the average freshness of any source.
One country, one day. OpenCorporates covers far more countries than the UK, and far more than we do. Freshness elsewhere may be better or worse.
Lag is not the same as wrong data. Each third-party record was presumably accurate when it was copied. The risk is treating a copy as if it were live.
Lower bounds only. We looked once and did not measure when each record caught up.

Ways to get live data

If the lag matters for your use case, ask the source at the moment you need the answer:

The Companies House REST API. Free, and the code above is most of what you need. The standard rate limit is 600 requests per five minutes.
The Companies House streaming API. Push-based: subscribe to officers, company profiles, filing history and more, and update your own records as changes are published. The right choice if you keep a local copy and need it current.
A live multi-registry API. If you need the same live lookups across several countries' registries through one interface, that is what we build at OpenRegistry. It queries the official registries at request time instead of serving a copy.

We Found 4 Common Errors on Companies on OpenCorporates in Minutes

OpenRegistry — Thu, 10 Sep 2026 08:22:11 +0000

We checked them against the official Companies House register. OpenCorporates got all four wrong.

Claude estimates roughly 100,000 changes a day and ~700,000 a week, and that is officer records alone. Accounts, addresses, PSC filings and charges come on top. On UK companies alone, that leaves a huge population of potentially wrong records on OpenCorporates at any given moment.

Every claim below is attached with evidence. Company numbers are included so you can check them yourself.

Four examples

Company	Companies House (official, checked 10 Sep 2026)	OpenRegistry	OpenCorporates
BRUCE & COMPANY LIMITED `SC190660`	Active, proposal to strike off	✅ Active, proposal to strike off	Active ❌ Error: strike-off warning missing
G.R.I.T HP UK LTD `15150296`	2 officers, incl. Teresa Dawn Swinton, Secretary (appointed 9 Sep 2026)	✅ 2 officers, including Swinton	1 officer ❌ Error: a serving officer is missing
BRIDGEHAVEN SPECIALTY UK LTD `12782688`	Esther Ruth Felton, RESIGNED 7 Sep 2026	✅ Felton under Resigned officers	Esther Ruth Felton, director, 1 May 2023– (i.e. current) ❌ Error: a resigned director shown as active
LEXORA LAW CHAMBERS LTD `17450921`	Active, incorporated 10 Sep 2026	✅ Active, officer Ilyas Mohammed	"Found 0 companies" ❌ Error: company missing entirely

The evidence

Each company below shows the same record twice: what OpenCorporates reports, next to what the official Companies House register says at the same moment.

1. BRUCE & COMPANY LIMITED `SC190660`

**OpenCorporates* — status "Active". No mention of strike-off. The page claims "Last Update From Source: 9 September 2026", "Next Update: Daily".*

**Companies House* — "Active — Active proposal to strike off".*

A company on its way to being dissolved. One of the strongest risk signals the register carries, and it is absent from OpenCorporates.

2. G.R.I.T HP UK LTD `15150296`

**OpenCorporates* — one officer only: Kelly Jayne Pudner.*

**Companies House* — "2 officers / 0 resignations". Teresa Dawn Swinton, Secretary, appointed 9 September 2026, ACTIVE.*

The secretary is missing. The same OpenCorporates page also contradicts itself: it claims "Last Update From Source: 9 September 2026", the very day the secretary was appointed, while also stating "Last Change Recorded: 3 June 2026." It says it checked the source, and it says nothing has changed in three months.

3. BRIDGEHAVEN SPECIALTY UK LTD `12782688`

**OpenCorporates* — "ESTHER RUTH FELTON, director, 1 May 2023–". The open-ended dash means currently serving.*

**Companies House* — Role: Director. Status: RESIGNED. Resigned on: 7 September 2026.*

A resigned director shown as active. Look at the OpenCorporates screenshot again and a second defect appears. The beneficial owners include both "David Emil Paulson" and "David Emil Paulsson". "Erik William Matson" is listed twice. The director list carries "ARTUR NIEMCZEWSKI" and "ARTUR PAWEL NIEMCZEWSKI", the same man, counted twice.

Duplicated beneficial owners are not cosmetic. They inflate the UBO count and corrupt the screening step AML rules exist to enforce.

4. LEXORA LAW CHAMBERS LTD `17450921`

**OpenCorporates* — "Found 0 companies". "Your search did not match any companies."*

**Companies House* — LEXORA LAW CHAMBERS LTD, 17450921, Active, incorporated 10 September 2026.*

This one is not stale, it is absent. The company was incorporated on the morning of 10 September 2026 and appears on the official register immediately. OpenCorporates returns nothing, because a cached index cannot contain a company it has not ingested yet. Around 2,000 companies are incorporated in the UK on a normal working day, and every one of them is invisible to a scraper until its next pass.

5. OpenRegistry, queried live, gets all four right

The same three companies, pulled live through OpenRegistry inside Claude. Source: Companies House via OpenRegistry, 10 September 2026, 04:58 and 08:44 (BST).

✅ BRUCE & COMPANY — "Active, proposal to strike off"
✅ G.R.I.T HP UK — 2 officers, including Teresa Dawn Swinton
✅ BRIDGEHAVEN — Esther Ruth Felton correctly under "Resigned officers"
✅ LEXORA LAW CHAMBERS — present, Active, officer Ilyas Mohammed

Four for four, with no cache to go stale.

Why this keeps happening

OpenCorporates scrapes and caches. A cache is a snapshot of a moving target. When the target moves 100,000 times a day, the snapshot is wrong somewhere, constantly. A faster cron job does not fix that. Not caching does.

The more reliable solution: OpenRegistry

OpenRegistry queries the government registry at the moment you ask. There is no cache layer to go stale, and no scrape to silently drop a record.

Live — every call hits the official registry in real time
Unmodified — the registry's own field names and values, with the source traceable back to the government record
Cross-border — national registries well beyond the UK, through one interface
MCP-native — plugs directly into Claude and other AI agents, which is Evidence 7 above
Cheaper API — OpenRegistry API is much cheaper than OpenCorporates.

If you are doing KYB, AML screening, supplier onboarding, or investigative work, "probably right" is not a standard you can defend.

All Companies House data on this page was verified live on 10 September 2026 via the official Companies House API. Company numbers are included throughout so every claim can be independently checked.

About this page. OpenRegistry is published by Sophymarine, so this comparison is written by a party with a commercial interest in one of the tools on it. Figures and product claims for the other vendors come from each vendor's own public material, linked inline where applicable. Reviewed 2026-09-10.

Source-of-truth for this page is the public docs repo README. Connect any MCP client to https://openregistry.sophymarine.com/mcp.

All Companies House data verified live on 10 September 2026 via the official Companies House API. Full version with side-by-side evidence: openregistry.sophymarine.com/docs/opencorporates-errors

openregistry.sophymarine.com

Live company-registry data for AI agents, from one endpoint

OpenRegistry — Wed, 09 Sep 2026 03:56:27 +0000

Company data straight from the official source, for AI assistants and developers.

OpenRegistry gives you live, source-linked access to national company registries — search a company, then pull its officers, shareholders, filings, and raw filing documents, exactly as the government registry holds them.

Live, direct-from-registry (no stale cache)
MCP-native, so it plugs straight into AI agents
Free for anonymous use, no API key to start

Try it: https://openregistry.sophymarine.com

OpenRegistry — New Version Available

OpenRegistry — Mon, 07 Sep 2026 07:11:35 +0000

A new version of OpenRegistry is now available, with strengthened infrastructure.

Live, source-linked access to official company registries for AI assistants and developers — https://openregistry.sophymarine.com

India's MCA feed still carries the Y2K date bug

OpenRegistry — Fri, 17 Jul 2026 15:01:13 +0000

Two-digit incorporation years still turn up in parts of the MCA bulk feeds. Last month I hit a CIN record where an upstream parser treated 01-01-00 as 1900 during a sanctions-linked subsidiary trace. Small bug. Big consequences. One bad date can push a company earlier than the existence of its own parent when you are rebuilding ownership timelines across four jurisdictions.

India’s Ministry of Corporate Affairs exposes company data through MCA services and downstream data.gov.in datasets, though the structure swings wildly between sources. Some records arrive properly typed. Others still carry formatting decisions inherited from filing systems built long before anybody expected API consumers to parse them automatically. You can pull useful registry intelligence out of the data, though it helps to treat filings as statutory records rather than reference data cleaned for analysts.

OpenRegistry does not currently serve the IN jurisdiction. The live matrix marks India as inactive, so there is no MCP passthrough for MCA queries right now. Registry behaviour shifts often around filing access, session handling, or CAPTCHA enforcement. Better to mark coverage offline than pretend an old integration still works.

The structure still matters because Indian entities show up constantly in cross-border reporting chains. Offshore structures involving Mauritius, Cayman, Singapore, or Dubai often terminate in an Indian operating company. During one ownership reconstruction tied to procurement records, I ended up matching DIN numbers against director names from leaked spreadsheets because the register itself handled transliteration inconsistently across filings.

The identifiers are fairly readable once you know the layout. The Corporate Identity Number, or CIN, encodes listing status, industry classification, state registration, incorporation year, plus registrar office. Director records use DIN identifiers. LLP entities carry LLPIN values instead.

When MCA responses are available programmatically, the payloads usually expose fields like:

cin
company_name
company_status
date_of_incorporation
registered_office_address
authorised_capital
paid_up_capital
director_din
director_name
filing_date

Normalisation causes most of the pain. Addresses arrive as free-text blocks with inconsistent state abbreviations. Historical filings contain OCR artefacts. Director names drift between annual returns through spacing changes or shifting initials. Exact string matching falls apart quickly if you are tracing politically exposed persons or procurement beneficiaries.

Public access and paid retrieval are split awkwardly as well. Basic company profiles are accessible through MCA-facing services. Full filings follow another route entirely. Annual returns, balance sheets, charge documents, incorporation PDFs: many sit behind fee workflows or session-bound requests that break automated collection.

India also handles beneficial ownership differently from some European registers that briefly exposed broader public UBO access before the CJEU C-601/20 ruling shifted the position across the EU. Significant beneficial ownership obligations exist under Indian company law, though public machine-readable access remains narrow.

The filings still matter because they create timelines that can be checked later. Director appointments, registered office changes, strike-off notices, charge creation dates: each becomes an anchor point during reporting work. Newsrooms working from leaked datasets usually care less about whether a register feels modern and more about whether another team can reproduce the same trail six months later.

If India coverage returns inside OpenRegistry, the MCP flow would probably begin with a company search:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "IN",
    "query": "Adani Enterprises"
  }
}

After that, a profile pull against the CIN returned from search:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "IN",
    "company_number": "L51100GJ1988PLC010856"
  }
}

For reporting work, the next step is usually filing enumeration rather than stopping at the profile layer:

{
  "tool": "list_filings",
  "arguments": {
    "jurisdiction": "IN",
    "company_number": "L51100GJ1988PLC010856"
  }
}

Chronology matters here. Charge satisfaction records can expose lender relationships that never appear in company websites or investor material. Director resignations often line up with enforcement actions or media scrutiny. Some entities look dormant until you inspect annual returns directly and notice the same address reused repeatedly across related companies.

Language handling creates another awkward corner case. MCA records are mostly English-language, though supporting documents can include transliterated names from Hindi or regional languages. Matching against court filings, customs data, or leaked procurement spreadsheets gets fuzzy fast. I have seen the same surname rendered three different ways across registry extracts tied back to a single DIN.

Compared with the legacy paid databases, direct registry access gives you provenance. You can cite the statutory filing itself rather than relying on a reshaped ownership graph. Aggregators often flatten Indian entities into simplified structures while discarding registrar metadata that later matters during fact-checking or libel review.

India also sits in an uncomfortable middle ground for compliance engineering. The register is broad enough to support KYB work, though not clean enough to trust without review. Edge cases keep surfacing: struck-off restorations, duplicated director names, recycled addresses, historical filing corrections that overwrite earlier assumptions.

OpenRegistry currently serves 30 active jurisdictions including GB, KY, RU, HK, and IT. India remains inactive in the live matrix today. When IN returns, the MCP endpoint will expose upstream MCA fields directly instead of reinterpreting them. Current jurisdiction availability is listed at openregistry.sophymarine.com/mcp

Indonesia UBO checks after the AML clampdown

OpenRegistry — Thu, 16 Jul 2026 15:01:23 +0000

Two Indonesian shareholders with the same name appeared in one acquisition structure. The legacy paid database collapsed them into a single beneficial owner because both addresses had been cut down to district level. AHU filings showed different NIK-linked records and different appointment dates. The control analysis for a Singapore-linked vehicle changed after that.

Indonesia’s Ministry of Law and Human Rights operates the AHU system for company administration, including PT Perorangan records and parts of the beneficial ownership disclosure process. During diligence, the interesting detail is rarely the headline company status. Filing cadence matters more. Officer rotations matter too, especially when shareholder declarations stop matching the offshore structure wrapped around them.

Older filings are where things usually get awkward. Indonesian entities often appear under several transliterations, particularly where nominee arrangements exist or historic spelling changes carried forward into later paperwork. One director can surface under slightly different names across separate filings. Aggregators tend to flatten those distinctions. Sometimes that is exactly the detail you needed before signing.

The raw fields worth checking first are usually:

company_name
registration_number
entity_type
company_status
date_of_establishment
share_capital
jurisdiction_data.pengurus
jurisdiction_data.pemegang_saham
jurisdiction_data.pemilik_manfaat

pengurus usually contains directors and commissioners. pemegang_saham stores shareholder declarations where available. pemilik_manfaat maps to beneficial ownership disclosures under Indonesia’s AML regime.

Those structures matter because Indonesian corporate control is often layered through nominee holdings or Singapore family office vehicles. A cleaned entity summary can bury filing-order inconsistencies that point to a recent restructuring.

One Jakarta manufacturing target looked stable in the subscription databases last year. The AHU filing sequence showed three commissioner changes inside four months, followed by a capital amendment shortly before debt refinancing. That raised immediate questions around lender consent and side agreements. Nothing had been concealed. The aggregator copy was stale.

PT Perorangan entities add another wrinkle. Some records are sparse compared with larger PT structures, and historical depth varies depending on formation date or filing path. Older entities can have uneven metadata coverage. It happens.

Public data also has limits.

Indonesia does not expose every ownership layer required for a full UBO reconstruction, especially when offshore entities sit above the local operating company. Some AML-sensitive material stays gated or absent from public retrieval flows. OpenRegistry does not bypass those restrictions. It also does not infer missing ownership chains from partial filings.

Document handling can slow diligence down. Certain filings appear only as references or metadata pointers rather than machine-readable documents. If you are tracing a director replacement during exclusivity, local counsel may still need to pull notarised paperwork directly.

OpenRegistry does not currently serve Indonesia in the public MCP matrix. ID returns active: false from list_jurisdictions. Pipelines should check jurisdiction availability at runtime instead of assuming static coverage.

A typical capability check looks like this:

{
  "tool": "list_jurisdictions",
  "arguments": {
    "jurisdiction": "ID"
  }
}

If Indonesia becomes active again, the MCP flow follows the same pattern used for Companies House or KVK lookups through OpenRegistry.

Searching for an entity:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "ID",
    "query": "PT Alam Sutera Realty Tbk"
  }
}

Pulling the company profile:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "ID",
    "company_number": "example-registration-number"
  }
}

Officer retrieval during diligence would usually look like this:

{
  "tool": "get_officers",
  "arguments": {
    "jurisdiction": "ID",
    "company_number": "example-registration-number"
  }
}

Shareholder retrieval follows the same structure:

{
  "tool": "get_shareholders",
  "arguments": {
    "jurisdiction": "ID",
    "company_number": "example-registration-number"
  }
}

Where beneficial ownership data is legally exposed through the registry flow, get_persons_with_significant_control returns the upstream fields directly. There is no confidence-scored ownership graph layered on top.

That distinction matters in M&A work. An AI layer should not decide that two similarly named directors are the same person because their birth years roughly line up. You need the raw payloads, filing timestamps, and source-specific identifiers. Otherwise small mismatches disappear into a merged profile.

Indonesia is also one of the places where chronology matters more than polished summaries. Capital amendments, commissioner rotations, and shareholder declarations can move quickly around financing events. A six-month lag from an aggregator crawl is enough to miss a control shift.

Cross-border structures add another complication. Indonesian operating companies are often paired with Singapore holding entities, Hong Kong intermediaries, or Cayman financing vehicles. OpenRegistry currently serves HK and KY in the live matrix, which makes side-by-side registry verification useful when tracing outbound ownership chains. Naming inconsistencies still need manual review.

For compliance engineering, the useful pattern is direct registry retrieval with minimal interpretation. Pull the upstream fields. Preserve filing timestamps. Compare appointments across jurisdictions, then decide where human review is required.

OpenRegistry exposes live company registry access over MCP without intermediary parsing layers. Jurisdiction availability changes over time, so production systems should always query the runtime matrix first: https://openregistry.sophymarine.com/mcp

Malaysia SSM e-Info: live KYB checks without aggregator lag

OpenRegistry — Wed, 15 Jul 2026 15:01:17 +0000

SSM company records change faster than most KYB pipelines

Malaysia’s SSM e-Info register updates quickly enough that stale commercial datasets stand out during onboarding reviews. We hit this with a merchant whose registered address had already changed in SSM while a paid database still carried the previous location weeks later.

That gap causes trouble in ASEAN onboarding work. Malaysian entities often appear inside ownership chains linked to Singapore, Hong Kong, or Cayman structures. When audit reviews the file later, “the vendor had not refreshed yet” does not carry much weight if the register-of-record already showed different information.

OpenRegistry connects directly to SSM e-Info through MCP and returns the upstream fields live. We do not reshape the register response into an internal schema before returning it. Your workflow or assistant consumes the payload as SSM supplied it.

What SSM e-Info actually returns

The useful part of Malaysian register data is rarely the company name by itself. Status changes matter. Officer appointments matter. Filing history usually matters more than branding details during KYB review.

A standard get_company_profile call returns fields such as:

company_number
company_name
company_status
incorporation_date
registered_address
entity_type
jurisdiction_data

jurisdiction_data preserves SSM wording and values exactly as supplied upstream. Audit teams tend to care about this because evidence packs can cite the original register language instead of a vendor interpretation layered over the top.

Officer records become useful once ownership checks or sanctions review starts. get_officers returns director names, appointment dates, resignation dates where available, plus officer roles supplied by SSM.

Filing data is where Malaysian KYB work stops being cosmetic. list_filings exposes filing names, filing dates, document references, and availability metadata. For higher-risk counterparties, recent filing activity can matter more than the entity’s mere existence. A dormant shell with no current filings usually triggers another look.

Entity names create their own mess. Malaysian companies frequently include punctuation, abbreviations, or legal suffix variations that break simple fuzzy matching logic. Direct register lookup cuts down false positives because you are querying the current source rather than consuming pre-normalised exports.

What you will not get from SSM

SSM is a company register. It is not a sanctions source or beneficial ownership service.

OpenRegistry does not return sanctions screening, PEP data, or credit scoring because those datasets do not exist in the upstream register. You still need a separate sanctions process against OFAC, UK, EU, or local lists.

Beneficial ownership visibility also varies by jurisdiction. Malaysia does not expose unrestricted UBO access in the same way some compliance teams became accustomed to under earlier European AML workflows. Access rules differ by country. Legal regimes differ too.

That distinction matters more now because broad public UBO access has narrowed across several jurisdictions following decisions such as CJEU C-601/20. Compliance systems need to separate register checks from ownership analysis and sanctions review rather than treating them as one combined lookup.

Document availability can also be uneven. Some filings expose metadata without exposing downloadable source documents through the public interface. Workflows should expect partial retrieval. Plenty do.

Querying Malaysia through OpenRegistry MCP

The Malaysia endpoint is active in the current OpenRegistry jurisdiction matrix.

Most onboarding flows start with a direct company search:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "MY",
    "query": "Grab Holdings"
  }
}

That returns candidate entities from SSM with the original register identifiers preserved.

Once you have the company number, pull the profile directly:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "MY",
    "company_number": "980177-W"
  }
}

Enhanced due diligence usually continues with officer and filing retrieval:

{
  "tool": "get_officers",
  "arguments": {
    "jurisdiction": "MY",
    "company_number": "980177-W"
  }
}

{
  "tool": "list_filings",
  "arguments": {
    "jurisdiction": "MY",
    "company_number": "980177-W"
  }
}

OpenRegistry does not maintain historical snapshots of Malaysian register data. Every request hits the live upstream source. For onboarding controls, we generally prefer that tradeoff because decisions reference the current register state rather than a cached export from several weeks earlier.

The operational effect is straightforward. If SSM updates an officer appointment today, the next query sees the revised record immediately. No downstream refresh cycle exists in the middle.

Audit evidence and regulator expectations

During KYB reviews, internal audit teams increasingly ask the same thing: what was the source-of-record when the onboarding decision was made?

Commercial database exports often struggle here because they cannot prove the exact upstream register state at decision time. We moved several onboarding checks back to direct register retrieval after running into that issue repeatedly.

Malaysia is a good example because cross-border merchant structures often span several registers at once. One review may involve an SSM operating entity, a Hong Kong holding company, plus a Cayman parent vehicle.

OpenRegistry currently covers MY alongside jurisdictions including HK, KY, GB, NL, and NZ through the same MCP interface. Teams can keep jurisdiction-specific review logic while standardising transport and authentication across registers.

That removes a common engineering problem inside compliance systems. Registry integrations often turn into brittle scrapers with inconsistent authentication flows and uneven refresh cycles.

For higher-risk onboarding queues, we still pair register retrieval with sanctions resolution and manual document review. Register data alone is not sufficient for AML controls. Direct SSM access does improve traceability because investigators can point to the register response itself rather than a transformed intermediary record.

OpenRegistry’s Malaysia endpoint is available at https://openregistry.sophymarine.com/mcp

Hong Kong Companies Registry: live filings without cache lag

OpenRegistry — Tue, 14 Jul 2026 15:01:13 +0000

Hong Kong company numbers survive renames. During IPO diligence, that identifier is often more dependable than the trading-name history copied across bank files and legacy paid databases.

The Hong Kong Companies Registry (公司註冊處) exposes enough structured data to trace entities across borders without spending afternoons walking PDFs by hand. We kept hitting this in Cayman-HK-China structures where the Hong Kong company became the only stable anchor across financing rounds, director reshuffles, and offshore reorganisations.

OpenRegistry connects to the live register through MCP. Registry-specific fields remain inside jurisdiction_data, which means the response still carries upstream values instead of flattening everything into one normalised schema.

What the Hong Kong register returns

A standard Hong Kong company profile usually contains the company number, current legal name, previous names, incorporation date, entity status, registered office, directors, company secretary details, plus filing metadata.

The bilingual name fields end up mattering more than expected. Some entities appear under slightly different English transliterations across loan agreements or exchange filings. The Chinese name tends to stay stable. Matching on company number sidesteps most of the confusion.

Filing history matters more.

Director appointments, cessations, share allotments, and office-address changes often land quickly in the register. We have seen debt issuance reviews stall because a director rotation appeared less than two weeks before signing.

The MCP calls are simple:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "HK",
    "query": "Pacific Century"
  }
}

That returns the registry number used for the profile lookup:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "HK",
    "company_number": "1234567"
  }
}

Most finance teams then jump straight into filing history:

{
  "tool": "list_filings",
  "arguments": {
    "jurisdiction": "HK",
    "company_number": "1234567"
  }
}

Freshness is the part that matters here. OpenRegistry does not run nightly sync jobs or serve delayed mirrors. Each request goes upstream live.

PSC access after the 2018 changes

Hong Kong introduced the Significant Controllers Register regime in 2018 through amendments to the Companies Ordinance. At a distance it resembles UK PSC reporting, though the access model is tighter.

You should not expect full public retrieval of beneficial ownership records through OpenRegistry because the underlying register does not broadly expose them. The restriction comes from the source itself.

That leaves holes in AML and onboarding flows. A Hong Kong filing can confirm directors, company secretaries, incorporation status, and certain control relationships. It usually cannot complete the entire UBO chain when Cayman or BVI entities sit above the operating company.

The same pattern now shows up across several jurisdictions that tightened public-register access after privacy rulings and AML-related restrictions.

Filing quirks that appear during diligence

The bilingual naming issue catches teams constantly. A Traditional Chinese company name may map to several English transliterations depending on the filing year or whichever intermediary prepared the documents. Bank records are rarely consistent.

Offshore layering creates another headache. Many Hong Kong entities sit between a Cayman holding structure and mainland operating companies. The register can verify the Hong Kong legal entity cleanly. It does not rebuild the broader ownership chain for you.

Timing matters too.

Metadata for a filing can appear before the underlying document becomes accessible. Some records stay metadata-only. Others require additional access conditions before retrieval works.

When a document is available, you can fetch it directly from the filing identifier:

{
  "tool": "fetch_document",
  "arguments": {
    "jurisdiction": "HK",
    "document_id": "abcd1234"
  }
}

Coverage varies by filing type. Certain records expose only filing references with timestamps attached.

Using multiple registries in one workflow

Cross-border diligence rarely ends in Hong Kong. A typical review might begin with a Cayman exempted company, move through Hong Kong subsidiaries, then finish at a UK financing vehicle tied to the same group.

OpenRegistry currently covers 27 jurisdictions. The useful part is not normalisation by itself. It is having one MCP interface that moves between registers without maintaining separate scraper logic for every source system.

For lender onboarding or IPO preparation, reproducibility matters more than convenience. Teams need the actual register entry that supported a director check or entity verification step.

Keeping upstream fields intact helps there. If the Hong Kong register returns a bilingual address variant or filing code exactly as submitted, the audit trail remains visible instead of disappearing behind vendor-side enrichment.

There is a trade-off. OpenRegistry does not infer ownership structures or generate corporate family trees automatically. You still need to interpret the registry data yourself.

You can connect an MCP client directly to the Hong Kong register through OpenRegistry at openregistry.sophymarine.com/mcp

Mexico’s PSM registry after CTA: what filings still matter

OpenRegistry — Mon, 13 Jul 2026 15:01:39 +0000

Mexico’s Public Registry of Commerce still runs through state-level implementation. Look up the same company twice and historical coverage can shift depending on which Registro Público de Comercio office actually digitised its books.

That causes friction in cross-border diligence work. Mexican entities turn up constantly in North American ownership structures, though plenty of compliance teams still rely on stale aggregator exports instead of checking Secretaría de Economía source records.

The distinction that matters for legal and AML analysis sits between what the PSM exposes under commercial registration law and what lives elsewhere under tax, banking, or beneficial-ownership regimes. Mexico does not maintain a public UBO register comparable to the EU access model that existed before C-601/20. If you are testing ownership under OFAC’s 50% rule or UK sanctions guidance, the Registro Público de Comercio rarely settles the question by itself.

OpenRegistry exposes the Mexican register through MCP, which means queries run against the registry flow directly. No browser automation needed. The MX jurisdiction is active on the server.

A typical search_companies request looks like this:

{
  "jurisdiction": "MX",
  "query": "GRUPO BIMBO"
}

For existence checks, merger history, or authority review, get_company_profile tends to matter more:

{
  "jurisdiction": "MX",
  "company_number": "N-2023045678"
}

Response structure changes depending on the upstream office, though several fields appear regularly under jurisdiction_data. You will usually see razon_social, folio_mercantil, estado, fecha_constitucion, capital_social, objeto_social. administradores appears often too.

That last field gets misread all the time. Appointment as administrador único or board member establishes registered authority. It does not establish beneficial ownership under FATF-style control analysis. In deposition work and transactional disputes, that distinction carries weight.

Mexican filings also come with quirks around notarial intervention. Constitutive acts and amendments are commonly tied to protocolo numbers and notary references rather than the tidier filing identifiers seen in UK or Nordic registers. When tracing authority through mergers or capital increases, preserving the original notarial metadata matters.

list_filings helps reconstruct the sequence:

{
  "jurisdiction": "MX",
  "company_number": "N-2023045678"
}

Depending on the office, filing descriptions may expose constitutive deeds, merger registrations, bylaw amendments, liquidation entries. Some are sparse. Others contain surprisingly detailed references pulled from older index systems.

A few filings expose both inscription dates and protocol execution dates. Those dates are not interchangeable. Under Mexican commercial practice, the execution date before the notary and the later registration date can change priority analysis.

The register also does not solve beneficial-ownership diligence on its own. Mexico’s AML framework under the Ley Federal para la Prevención e Identificación de Operaciones con Recursos de Procedencia Ilícita imposes separate reporting duties for vulnerable activities, though those records are not publicly exposed through PSM queries.

That limitation shows up fast when foreign counsel try mapping Mexican entities into Corporate Transparency Act workflows. FinCEN BOI reporting under 31 CFR 1010.380 is a US federal obligation. It does not create reciprocal public access to Mexican ownership records. Teams still combine registry material with shareholder registers, notarised corporate books, sometimes local counsel certifications.

OpenRegistry does not infer ownership or rebuild hidden control chains. The MX integration returns upstream registry fields exposed by the source office. Nothing more.

For officer review, get_officers can help establish who held registered authority at a particular point in time:

{
  "jurisdiction": "MX",
  "company_number": "N-2023045678"
}

Results vary sharply by state office and filing depth. Some entities expose detailed officer names with appointment dates attached. Others expose little beyond current management references pulled from the latest inscription.

Historical coverage stays uneven. Older filings sometimes survive only as scanned ledger pages or partial index entries. Some registries digitised aggressively during the 2010s. Others still expose fragmented archives with obvious gaps. If a matter depends on pre-digital amendments, expect missing pieces.

Direct registry access helps more than polished aggregator summaries in those cases. For sanctions analysis or acquisition diligence, counsel often need the exact wording attached to a filing. A translated summary can miss whether a capital increase was authorised, merely proposed, or recorded subject to conditions.

fetch_document retrieves source material where the registry office exposes it:

{
  "jurisdiction": "MX",
  "document_id": "DOC-884421"
}

Document availability is inconsistent. Some offices expose PDFs directly. Others return only metadata or filing references. A few still point back to manual retrieval workflows.

The evidentiary distinction matters here. The Mexican commercial register establishes notice and registration status for corporate acts. It is not a complete AML transparency system. After C-601/20, many lawyers became more careful about conflating commercial registration with beneficial-ownership disclosure. Mexican registry work demands the same discipline.

For KYB tooling, the useful part of the MCP model is that an assistant can query the register live during a workflow instead of relying on cached exports from the legacy paid databases. The source remains the registry office of record.

OpenRegistry’s MX endpoint is available through the remote MCP server at https://openregistry.sophymarine.com/mcp

Taiwan GCIS records: fields you only notice mid-investigation

OpenRegistry — Sun, 12 Jul 2026 15:01:02 +0000

Taiwan’s GCIS register will often show a company’s status history in Chinese long before English-language databases settle on one transliteration. That turns into a real problem when you are tracing a supplier linked to export controls, chip procurement, or an intermediary that has renamed itself three times in five years.

GCIS has never been pleasant to work with from outside Taiwan. The records are public. Getting them cleanly is another matter. Browser flows break unexpectedly, character encoding goes sideways, and Romanisation shifts between datasets. Anyone who has matched a director from an OCCRP spreadsheet against a Taiwan filing has probably seen the same individual written three different ways: Wade-Giles once, Hanyu Pinyin elsewhere, then only the Chinese legal name in local coverage.

OpenRegistry exposes live GCIS data through MCP without rewriting the upstream payloads. Small detail. Important one. The jurisdiction block stays intact instead of being flattened into a generic company card.

For Taiwan entities, get_company_profile will usually return fields like:

company_name
company_status
capital_amount
responsible_person
registered_address
approved_establishment_date
registration_authority
change_approved_date
jurisdiction_data

jurisdiction_data is usually where the interesting work starts. GCIS often carries the original Chinese-language values beside translated variants. If you are trying to determine whether “Formosa Technologies Ltd” from an offshore leak maps back to 台灣某某股份有限公司 in the statutory filing, those source-language values matter more than whatever English alias ended up circulating later.

Taiwan records also separate establishment approvals from later amendment approvals. The legacy paid databases tend to compress all of this into one “incorporation date” field. You lose chronology. During procurement investigations or sanctions reporting, that missing timing can matter quite a bit.

I ran into this while tracing a hardware exporter that appeared in customs data under two English names that looked unrelated at first glance. GCIS preserved the amendment timeline and registration authority metadata clearly enough to line the entity history up against shipping manifests. The registry trail held together. The aliases did not.

The filings side helps too, though there are limits. list_filings can surface registry events tied to an entity, but this is not a full litigation database or a beneficial ownership system. Taiwan does not publicly expose every ownership layer investigators may want to inspect.

After CJEU C-601/20, many reporters got used to beneficial ownership access disappearing across parts of Europe. Taiwan sits under a different legal framework, though practical access limits still exist depending on entity type and filing surface. OpenRegistry does not bypass AML-gated systems or private shareholder registers.

Historical document retrieval still has rough edges. Some GCIS material only exists as scanned originals with uneven OCR quality. If your workflow depends on machine-reading PDFs at scale, you will still need downstream parsing and cleanup passes. No way around that yet.

A typical MCP search flow looks like this:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "TW",
    "query": "台積電"
  }
}

Searching the native-language company name works far better than starting with English transliterations. Pull the Chinese legal name from source material first. Then branch outward into aliases, directors, and related entities.

Once you have the registry number, fetch the profile directly:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "TW",
    "company_number": "22099131"
  }
}

For reporting work, the flow is usually fairly direct:

Query the Chinese entity name from source documents.
Pull the GCIS profile.
Compare amendment dates against customs or procurement records.
Cross-reference officers against Hong Kong or Cayman entities.

Taiwan becomes far more useful when paired with nearby registers. OpenRegistry currently serves TW alongside HK, KY, KR, JP, MY, NZ, AU, RU, plus several European jurisdictions. That makes it practical to follow a supply-chain entity from Taipei into a Hong Kong holding company, then onward into a Cayman registration without swapping tools halfway through an investigation.

That continuity matters for reproducibility. After the Pandora Papers period, one recurring problem was that reporters could describe an ownership trail but could not reproduce the exact registry pull months later. Aggregator datasets changed quietly. Cached snapshots drifted over time. Shared-folder screenshots vanished.

With GCIS queried live, another reporter can rerun the same MCP calls and inspect the upstream registry fields directly. During libel review, provenance is often more useful than an enrichment layer that rewrites or normalises source material.

There are still operational annoyances. Taiwan company names sometimes contain punctuation or spacing variants that break naive matching logic. Certain filings appear in Chinese before translated metadata catches up. Historical officer changes are not always exposed in the structure investigators expect.

Even with those limits, the MCP workflow is cleaner than the old mix of browser automation and manual copy-paste from registry pages. The register stays the source of record. The client decides how to interpret the data.

If you are building investigative workflows around East Asian corporate records, live GCIS access is available at openregistry.sophymarine.com/mcp

OpenDART filings in Korea: fields worth checking twice

OpenRegistry — Sat, 11 Jul 2026 15:01:06 +0000

South Korea’s OpenDART feed timestamps filings to the minute, and those timestamps can change a live diligence call. On a Seoul industrials target last quarter, one of the legacy paid databases still showed the previous statutory auditor hours after the replacement filing appeared in the Financial Supervisory Service feed.

That lag shows up in Korea more often than many cross-border teams expect. The register leans heavily toward disclosures and behaves closer to a securities reporting system than a conventional European companies register. When you are tracking officer changes, treasury share activity, affiliate transactions, or a capital raise close to signing, the raw filings tend to move first.

OpenRegistry exposes OpenDART through MCP at the registry layer. The response stays close to the upstream shape. You get source fields inside jurisdiction_data, not a derived ownership graph or scoring layer built later.

What the Korean registry actually returns

The first split that matters is company profile data versus disclosure history. OpenDART is strongest on filings tied to listed entities and reporting issuers.

A standard get_company_profile response for a Korean company can include:

corp_code
corp_name
stock_code
ceo_nm
adres
hm_url
est_dt
corp_cls

corp_cls matters more than some foreign diligence teams realise. KOSPI, KOSDAQ, KONEX, plus related classifications affect filing cadence and disclosure expectations. During a carve-out review earlier this year, a subsidiary looked inactive in one vendor export because its stock number changed after a market transfer. OpenDART still linked the filing history correctly through the corporate code.

The filing layer is where the register becomes genuinely useful for transaction screening. list_filings can surface periodic reports, shareholder disclosures, convertible bond issuances, treasury share acquisitions, mergers, spin-offs, or related-party transactions.

Upstream payloads usually include receipt timestamps, filing identifiers, amendment indicators, filer names, and report titles. Amendment flags deserve manual review. Korean issuers regularly correct disclosures after publication. Sometimes the correction materially changes debt figures or share counts.

Officer data behaves differently from many European registers. get_officers may expose board and executive information tied to disclosed filings rather than a continuously maintained commercial register snapshot. Dates matter during cross-border director matching. A director can vanish for one filing cycle, then reappear after a governance restructure.

The gaps that catch diligence teams

OpenDART is not a beneficial ownership register in the European sense.

You will not get AML-gated UBO data comparable to some historical transparency registers. Korea’s disclosure regime centres on listed-company reporting obligations, securities compliance, and material ownership disclosures.

Private-company coverage is uneven too. If the target is a small unlisted manufacturing subsidiary sitting outside reporting thresholds, the disclosure surface may be thin. Korean court register extracts and local counsel still matter.

Document retrieval gets messy fast. Some filings expose structured metadata with attached HTML sections. Others depend heavily on embedded documents that do not parse cleanly. Tables inside Korean-language disclosures remain awkward to extract even when the filing itself is public.

That distinction matters during acquisition financing reviews. A recent debt package I checked referenced guarantees inside an attachment that several aggregator exports skipped because their parser failed on the embedded section layout.

OpenRegistry does not reinterpret those attachments. It returns the registry material as supplied upstream.

Querying OpenDART through MCP

The workflow is usually search first, then pivot into filings.

A basic company lookup:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "KR",
    "query": "Samsung Electronics"
  }
}

Once you have the identifier, pull the profile directly:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "KR",
    "company_number": "005930"
  }
}

For live diligence work, filings are often more useful than the static profile.

{
  "tool": "list_filings",
  "arguments": {
    "jurisdiction": "KR",
    "company_number": "005930"
  }
}

If a filing references a material transaction, governance event, or amendment, retrieve the underlying document:

{
  "tool": "fetch_document",
  "arguments": {
    "jurisdiction": "KR",
    "document_id": "RCP20260318001234"
  }
}

One practical point for automation teams: keep the original Korean text somewhere in the pipeline. Translating too early tends to flatten legal distinctions inside securities disclosures and board resolutions. I have seen machine translation collapse standing auditor and outside director roles into the same English label.

Filing cadence during cross-border deals

Korean targets often sit inside broader Asia-Pacific supply chains with holding entities elsewhere. During diligence on a battery-sector supplier, the Japanese parent looked operationally quiet in outside datasets. OpenDART filings on the Korean subsidiary showed recent capital activity plus a related-party transaction that had not yet propagated through vendor feeds.

That timing gap affects valuation work. It also affects sanctions reviews when ownership percentages or affiliate guarantees move shortly before close.

For M&A teams, the practical pattern is not replacing existing datasets outright. We still keep subscription products for modelling layers and broad screening. Registry-direct access is where you verify filing chronology, disclosure corrections, or officer changes against the upstream source.

OpenRegistry currently serves 27 jurisdictions including KR, GB, IT, JP, NL, and RU through a single MCP endpoint. Runtime coverage differs by registry. The live jurisdiction matrix and MCP documentation are at https://openregistry.sophymarine.com/mcp

ARES company data: fields KYB teams actually use

OpenRegistry — Fri, 10 Jul 2026 15:01:13 +0000

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"
  }
}

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

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "CZ",
    "company_number": "27864651"
  }
}

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