DEV Community: OpenRegistry

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

Corporations Canada filings via MCP: issuer checks in real time

OpenRegistry — Thu, 09 Jul 2026 15:01:03 +0000

Federal corporations in Canada use an eight-digit corporation number, though the fields that matter in diligence work sit much deeper in the registry payload. Corporations Canada exposes status history, annual filing state, registered office details, director appointments, and continuance events that often appear later in cached commercial datasets.

That gap shows up fast when you are tracing a financing vehicle across provinces or checking whether a reporting issuer still exists before settlement. We have seen dissolved CBCA entities remain marked active in internal systems for weeks after the federal register changed state.

What the federal register returns

Corporations Canada covers entities incorporated under the Canada Business Corporations Act. Through OpenRegistry MCP, the usual flow starts with search_companies and then moves into get_company_profile.

A basic search call looks like this:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "CA",
    "query": "Maple Leaf Holdings"
  }
}

The response includes the federal corporation number together with the legal name recorded by Corporations Canada. That number becomes the stable reference for later checks.

get_company_profile returns the current federal profile and keeps upstream registry fields inside jurisdiction_data. For Canadian diligence work, these are usually the fields people care about:

corporationNumber
businessNumber
governingLegislation
status
statusDate
annualFilings
registeredOfficeAddress
directorMinimum
directorMaximum
continuanceDate

The corporation number and CRA business number get mixed up constantly in onboarding documents. They are not interchangeable. The corporation number identifies the entity on the CBCA register. The business number belongs to the CRA tax system.

Director data is often more detailed than people expect from a public register. get_officers exposes director names, appointment dates, and service addresses where the registry publishes them.

Example:

{
  "tool": "get_officers",
  "arguments": {
    "jurisdiction": "CA",
    "company_number": "1234567-8"
  }
}

Continuance history is easy to miss during M&A screening. Canadian entities move between provincial and federal regimes more often than internal entity-resolution systems expect. We ran into this while tracing an Ontario corporation that later continued under the CBCA. Same legal name. Older internal records still treated the federal registration as a separate entity.

Annual filing state is another useful signal. An overdue annual return does not mean immediate dissolution, though it often tells you where the file is drifting. Treasury and credit teams usually care more about whether the legal shell can still execute agreements than whichever industry description appears in the profile.

Where the register stops

Corporations Canada is not a beneficial ownership register.

Canada has expanded transparency obligations in recent years, including the federal Individuals with Significant Control regime under the CBCA. Public disclosure still remains narrower than many compliance teams expect. The federal register should not be treated as a complete UBO source comparable to internal KYC records held by financial institutions.

OpenRegistry also does not layer interpretation onto the registry response. The MCP server returns upstream data exactly as provided by the source authority. No ownership graphing is attached to the output. No sanctions enrichment either.

Historical state has limits as well. Requests hit the live register directly. If a director resigns today and the filing is processed, the current response reflects that latest state instead of a stored historical snapshot.

Document availability varies. Some filings expose retrievable source documents through fetch_document. Others return little beyond filing metadata.

Working with filings and documents

Federal filing history becomes useful during IPO preparation or debt issuance reviews because you can compare amendments against disclosure drafts and board materials.

A filing query looks like this:

{
  "tool": "list_filings",
  "arguments": {
    "jurisdiction": "CA",
    "company_number": "1234567-8"
  }
}

Depending on the entity, the register may return annual returns, articles of amendment, continuance filings, dissolution notices, or director changes.

If a filing exposes a retrievable source document, fetch_document can pull it directly.

{
  "tool": "fetch_document",
  "arguments": {
    "jurisdiction": "CA",
    "document_id": "filing-2024-09-18-001"
  }
}

That direct registry path matters during audit disputes. A reviewer can trace the exact filing used in a diligence decision instead of relying on copied summaries from the legacy paid databases.

Cross-border checks get messy quickly

Canadian corporate structures regularly split operations across federal and provincial registrations. A CBCA corporation may still maintain extra-provincial registrations in British Columbia or elsewhere.

That creates matching problems during counterparty screening.

OpenRegistry currently covers federal Canada alongside British Columbia and Northwest Territories registries. The MCP interface stays consistent even though the underlying registries behave differently.

A typical compliance workflow looks something like this:

Search the federal CBCA entity.
Pull current directors and filing state.
Search provincial registries for matching legal names.
Compare addresses against incorporation dates.

The workflow sounds straightforward. It still catches real problems. One recurring lending issue is a dissolved federal corporation remaining marked active inside internal CRM systems because a provincial registration stayed open.

Issuer verification work is usually blocked by stale data rather than missing data. Overnight exports from aggregator platforms can lag behind the official register when director appointments or dissolution filings change during the day.

The OpenRegistry MCP server gives AI assistants direct access to the live registry response instead of a warehouse copy normalised weeks earlier. Teams building KYB tooling around CBCA entities can inspect the raw filing state directly at openregistry.sophymarine.com/mcp

New Zealand Companies Office: officer data quirks in practice

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

New Zealand company records still expose director residential addresses in situations where many UK practitioners now expect redaction. The Companies Act 1993 preserved disclosure routes that disappeared across parts of Europe after C-37/20 and C-601/20 reshaped access to beneficial-ownership records.

That catches people during APAC KYB work. The New Zealand Companies Office is not a beneficial ownership register in the EU sense, yet it remains one of the cleaner public datasets for checking directors, filings, and company status changes. For sanctions ownership analysis or statutory notice work, that distinction matters.

What the Companies Office returns

The Companies Register under Part 4 of the Companies Act 1993 exposes a fairly direct operational dataset. Through OpenRegistry MCP, the New Zealand endpoint returns upstream registry fields inside jurisdiction_data with only light schema alignment.

A standard get_company_profile response usually includes:

NZBN identifiers
company number
incorporation date
registered office address
address for service
company status
annual return filing month
entity subtype
director records

Director data is usually the useful bit. Depending on the entity type and the current disclosure settings, the upstream payload may include appointment dates, service addresses, or residency indicators.

For filing work, list_filings exposes registry events tied to annual returns, constitutions, director changes, amalgamations, and liquidation actions. Some registers collapse years of activity into one status field. New Zealand usually does not. You get a readable event trail instead of a derived summary.

Officer lookups sit separately from the company profile. get_officers returns appointment data linked to the entity record, which matters during insolvency tracing or deposition prep because historical officer movement is often clearer in raw registry events than in the legacy paid databases that overwrite prior states.

New Zealand also keeps a fairly hard separation between registration data and beneficial ownership concepts. The public Companies Office interface does not expose a UBO register equivalent. There is no direct analogue to the UK PSC disclosure model under Companies Act 2006 s.790E.

What you will not get

The first limitation is simple: there is no public beneficial ownership register.

New Zealand’s AML/CFT regime imposes customer due diligence obligations under the Anti-Money Laundering and Countering Financing of Terrorism Act 2009, but those obligations do not create a public dataset comparable to the EU access model that existed before C-601/20.

If your sanctions workflow depends on tracing natural persons through layered structures, the Companies Office alone will not cover it. You still need supporting material such as trust analysis, shareholder agreements, offshore register records, or regulated-source KYC documents.

You also should not treat the register as an archive. OpenRegistry does not store snapshots. Every request hits the live registry directly.

That affects evidence handling. If a director resigns today, tomorrow’s query reflects the updated state. Litigation hold work or transaction chronology still requires your own preservation process.

Document availability shifts by filing type. Some events expose downloadable documents. Others expose metadata only.

Querying the registry through MCP

The OpenRegistry server exposes the New Zealand register through the same MCP tool surface used for the other 26 jurisdictions. Upstream data quality varies between registers, though the tool interface stays consistent.

Searching by company name:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "NZ",
    "query": "Fisher & Paykel Healthcare"
  }
}

Retrieving a company profile after identifying the company number:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "NZ",
    "company_number": "110508"
  }
}

Reviewing officer history:

{
  "tool": "get_officers",
  "arguments": {
    "jurisdiction": "NZ",
    "company_number": "110508"
  }
}

Reviewing filing chronology:

{
  "tool": "list_filings",
  "arguments": {
    "jurisdiction": "NZ",
    "company_number": "110508"
  }
}

That consistency matters operationally. A compliance team reviewing NZ entities alongside GB, AU, HK, or IE records can keep the same MCP integration and switch only the jurisdiction code.

Statutory notice work versus commercial datasets

New Zealand is a good reminder that official registers and commercial KYB products solve different problems.

For statutory notice questions, the Companies Register is the source that matters. Courts care about what was filed with the registrar. Cached vendor copies carry less weight once dates, service addresses, or appointment timing become disputed.

That shows up regularly in insolvency matters and director liability disputes. If someone challenges service of notice or the timing of a resignation, the official filing trail is usually where the argument turns.

The legacy paid databases also tend to smooth over registry inconsistencies that investigators actually need to inspect. New Zealand filings include spelling variations, formatting quirks, plus occasional address inconsistencies. Raw registry output is not always tidy. The messy parts often contain the useful facts.

The jurisdiction is also useful during sanctions and export-control reviews because New Zealand entities appear regularly in trans-Tasman structures involving Australian parents, Pacific subsidiaries, or UK-linked trusts. Direct access to filing events makes director overlap analysis much easier across those structures.

For APAC diligence work, the practical point is straightforward: the New Zealand register is unusually accessible by international standards, though it remains a company register rather than a verified beneficial ownership system.

OpenRegistry exposes the live Companies Office data through MCP at https://openregistry.sophymarine.com/mcp so assistants and internal tooling can query the registry directly instead of relying on cached aggregator exports.

ABR lookups from code: what Australia exposes live

OpenRegistry — Tue, 07 Jul 2026 15:01:10 +0000

Australia’s ABN register exposes GST status changes with effective dates attached. That gets interesting when a procurement vehicle appears four days before a tender closes, or when a shelf company that sat dormant for years suddenly starts filing again.

The Australian Business Register occupies an awkward middle ground for investigations. Public enough for basic verification. Fragmented enough that you still bounce between ABR records, ASIC extracts, court filings, archived tenders, and procurement PDFs. Anyone tracing Australian mining entities or trust structures has probably run into this already.

OpenRegistry exposes the ABR through MCP. Responses come directly from the live register source, not a cached profile stitched together from aggregator feeds.

What the ABR actually returns

The ABR revolves around the Australian Business Number. Search by entity name and you usually get fields such as:

abn
entity_name
entity_status
entity_type
gst_status
state_code
postcode
registration_date

The more interesting details tend to live inside jurisdiction_data, where the original field names remain untouched. Australian entity records get messy fast because trusts, sole traders, incorporated associations, and Pty Ltd companies all follow different naming conventions. Preserving the upstream structure helps during verification work.

Historical business names appear where available. GST registration transitions do too. That matters when an entity quietly rebrands after litigation, media scrutiny, or procurement attention.

For reporters, timing usually matters more than existence. When did the ABN become active? Did GST registration begin months later? Was the business name updated shortly before a political donation or property transfer?

ABR data will not answer beneficial ownership questions by itself. Australia still scatters corporate control information across ASIC systems, procurement disclosures, court records, and sector-specific filings.

ABR is not ASIC

People often assume the ABR is Australia’s full company register. It is not.

The ABR covers tax-facing registration data. ASIC remains the statutory corporate regulator. Director histories, insolvency notices, lodged filings, and formal extracts still sit on the ASIC side.

That distinction matters in cross-border investigations. Entity tracing often depends on linking a tax-facing identity to a formal company record, then walking directors or shareholders across multiple jurisdictions.

ASIC extracts remain part of that process. OpenRegistry does not bypass ASIC paywalls or AML-gated systems.

Australia also lacks a public beneficial ownership register comparable to the short-lived access journalists had in parts of the EU before CJEU C-601/20 changed disclosure rules. Control can still be inferred through directors, shareholder filings, procurement disclosures, or trust relationships. There is no single public UBO database sitting behind an API call.

Querying the ABR through MCP

The MCP calls are simple enough to drop into an existing newsroom workflow.

Search by entity name:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "AU",
    "query": "Pilbara Minerals"
  }
}

That returns candidate entities with ABNs attached alongside registry status fields. Once you have the identifier, pull the full profile:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "AU",
    "company_number": "25112277230"
  }
}

The useful bit is reproducibility. A fact-checker can rerun the same query later and compare the live registry response against publication notes or archived drafts.

That starts to matter during long investigations. One recurring issue during the Pandora Papers reporting cycle involved reconstructing exactly when an entity changed status or registration state. Commercial datasets often flattened the timeline into a single “current” profile once updates arrived.

OpenRegistry does not keep historical snapshots. Every request hits the live registry source. If the register changes next week, the response changes as well.

Australian register quirks

Australian entity names are noisier than UK Companies House records. Trusts often trade under names that barely resemble the underlying legal entity. Indigenous corporations can appear under separate frameworks. Universities and charities may expose ABNs even though they do not behave like ordinary commercial companies.

GST status causes confusion too.

An active GST registration does not prove meaningful operations. Plenty of dormant entities leave GST registration active far longer than expected. A newly activated GST status, though, can signal that a procurement vehicle or contractor network has started operating.

Address data is another weak spot. The ABR often exposes suburb, state, and postcode without a structured service address. Matching entities against leaks, donor records, or shipping manifests usually requires fuzzy joins instead of exact matching.

Australian investigations also overlap heavily with New Zealand structures. Directors and service providers appear on both sides of the Tasman all the time. OpenRegistry exposes AU and NZ through the same MCP endpoint, which cuts down some of the registry switching during research.

Most investigations do not begin with enterprise subscriptions to the legacy paid databases. They begin with a name in a leaked spreadsheet, a procurement notice, or a shipping record.

You check whether the ABN existed at the claimed date. You compare GST activation dates against transaction records. Then the trail branches into court filings, archived websites, offshore structures, or procurement disclosures.

That workflow gets repetitive quickly. MCP helps because the assistant can make the registry calls directly while preserving the raw source fields needed for verification.

OpenRegistry’s Australian endpoint is live at https://openregistry.sophymarine.com/mcp and currently covers AU alongside 29 other jurisdictions including NZ, KY, RU, GB, and PL.

Ireland CRO filings: what shows up before diligence calls

OpenRegistry — Mon, 06 Jul 2026 15:01:03 +0000

Irish targets often look cleaner in aggregator datasets than they do in the CRO feed. During a Dublin software acquisition last quarter, the paid database still showed the previous registered office six weeks after the CRO filing changed it. The CRO entry had already shifted the company into a shared-services address used by four unrelated entities.

That sort of drift matters during pre-LOI screening. Ireland’s Companies Registration Office publishes filings fairly quickly, yet downstream datasets can sit behind for days or longer. Querying the register directly usually exposes the filing sequence the same day it appears.

What the CRO actually returns

The Irish dataset is useful because it exposes filing-level records instead of a heavily normalised company profile. Through OpenRegistry MCP, the Irish tools return raw upstream fields inside jurisdiction_data alongside a unified schema.

For a standard Irish LTD company, get_company_profile usually returns:

company number
legal status
incorporation date
registered office
company type
last annual return date
next annual return due date
filing status indicators from the CRO source

The filing metadata tends to matter most during diligence. Irish records often carry CRO-specific labels and references that the legacy paid databases flatten into generic categories.

list_filings is where patterns start showing up. You can walk annual returns, director appointments, office moves, constitution amendments, charge registrations, and capital filings from the same stream.

On distressed targets or companies moving quickly, filing cadence matters more than the summary page. I ran into one case where a burst of B10 director appointments was followed by address changes and charge filings over nine days. Management still described the entity as operationally unchanged during the first diligence call.

Officer data helps with cross-border matching as well. get_officers exposes appointment dates, resignation dates, officer roles, and names exactly as filed upstream. Irish officer formatting is less standardised than GB Companies House records, so direct register access helps when matching directors across Ireland, the UK, or offshore entities.

The CRO does not expose everything.

There is no unrestricted beneficial ownership dataset equivalent to what some diligence teams still expect from older European UBO workflows. Ireland tightened RBO access after the CJEU C-601/20 ruling on public beneficial ownership registers. OpenRegistry does not bypass those restrictions.

Financial statements are uneven too. Filing depth depends on company type and exemptions. Small-company abridged accounts can leave large gaps if you are trying to model operational exposure from registry filings alone.

Filing sequences beat snapshots

A cross-border subsidiary review last month involved an Irish holding company tied to a Dutch financing structure. The aggregator snapshot looked stable. The CRO filings showed a reorganisation already in motion.

Three filings landed within eleven days: a director resignation, a new charge registration, then a constitution amendment. The sell-side materials still described the structure as unchanged.

That sequence changed the risk picture immediately. The financing layer was already shifting before the transaction process formally acknowledged it.

Irish records are useful for spotting these timing gaps because the filing stream is comparatively accessible next to several continental registries.

Charge information is another signal worth watching. If a lender registers a charge shortly before a process starts, it can indicate refinancing pressure or covenant restructuring. You still need the underlying documents to interpret the exposure correctly. Timing alone can change diligence priorities.

Querying the CRO through OpenRegistry MCP

The MCP endpoint connects directly to the registry source. OpenRegistry does not maintain a scoring layer or historical warehouse.

A typical company search looks like this:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "IE",
    "query": "Stripe Payments Europe"
  }
}

Once you identify the company number, pull the profile:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "IE",
    "company_number": "513174"
  }
}

For diligence work, filings are usually the next call:

{
  "tool": "list_filings",
  "arguments": {
    "jurisdiction": "IE",
    "company_number": "513174"
  }
}

Officer tracing is straightforward:

{
  "tool": "get_officers",
  "arguments": {
    "jurisdiction": "IE",
    "company_number": "513174"
  }
}

The key detail is field preservation. OpenRegistry keeps the original CRO terminology instead of rewriting everything into a simplified corporate schema. That matters when diligence notes need to match source filing language exactly.

Where the Irish registry still falls short

The CRO works well for operational corporate status checks. Ownership transparency is weaker than many deal teams expect.

You will not get a clean beneficial ownership graph for every Irish-linked structure. AML-gated registers remain restricted. Complex fund structures, nominee arrangements, and layered offshore ownership still require legal work outside registry data.

Historical depth is another limitation. OpenRegistry queries the live register directly and does not store historical snapshots. If you need a point-in-time reconstruction from eighteen months ago, you still need your own archive process or a specialist historical dataset.

Irish filings can also be sparse for smaller private companies. An entity may remain technically compliant while disclosing very little operational detail.

Direct CRO access still catches stale assumptions quickly. Most Irish diligence failures I have seen were timing failures rather than missing-data failures. Someone relied on a downstream cache while the registry had already moved.

OpenRegistry exposes the CRO through MCP at https://openregistry.sophymarine.com/mcp for live registry calls inside diligence tooling or AI workflows.