DEV Community: OpenRegistry

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.

Belgium KBO lookups: what audit teams actually need

OpenRegistry — Sun, 05 Jul 2026 15:00:57 +0000

Belgium’s KBO/CBE uses a single enterprise number across incorporation, VAT, and establishment records. The neatness stops there. Matching onboarding documents against multilingual filings or older trade names gets messy fast.

KYB teams usually trust the KBO because it stays close to the register of record instead of reshaping data into a commercial dataset. You can rerun the same lookup later, inspect the filing source yourself, and avoid the stale “cached extract” issue that still turns up in onboarding stacks.

OpenRegistry serves Belgium live through its MCP endpoint. Responses preserve upstream jurisdiction_data fields from the KBO/CBE rather than squeezing everything into a guessed common schema. That matters when a reviewer needs to compare the exact registry value against a submitted incorporation extract.

The fields that tend to matter in Belgian KYB

Belgian company searches usually begin with either an enterprise number or a multilingual name search. KBO records may contain Dutch, French, or German variants depending on the filing history attached to the entity.

A get_company_profile call for Belgium often returns:

Enterprise number
Legal form
Registered address
Company status
Start date
NACE activity codes
VAT status references
Establishment unit data inside jurisdiction_data

The upstream payload is often more practical than a heavily normalised abstraction. Belgian entities regularly operate under shortened names or translated variants, which can trigger false mismatches during onboarding review.

We saw this in a payments onboarding flow. The merchant submitted a French-language extract, while the existing customer record stored the Dutch variant from an earlier filing. A matching layer that stripped accents and legal suffixes treated them as separate entities, so the case went straight to manual review.

Officer data creates similar problems. Belgian filings can distinguish statutory directors from delegated management roles, and those distinctions affect signing authority. A get_officers call returns the register representation directly.

Typical fields include:

Officer name
Appointment date
Function title
Representation powers
Active or ceased mandate status

Representation powers are easy to miss. Some Belgian entities require joint signatures under their articles. If your onboarding logic assumes any listed director can bind the company alone, you add operational risk for no reason.

list_filings becomes useful when tracing governance changes or status updates. Belgian filings often include publication references tied to the Belgian Official Gazette process. Compliance teams use those references to confirm whether a liquidation, merger, or amendment was formally registered before approving higher-risk activity.

What the registry does not provide

Belgium does not sidestep EU AML restrictions around beneficial ownership access.

After CJEU C-601/20, broad public access to beneficial ownership registers across the EU became legally constrained. Older AMLD 5 assumptions about unrestricted public UBO access no longer apply.

OpenRegistry does not bypass those restrictions. If beneficial ownership data is blocked upstream, it stays unavailable here.

The KBO is also not a sanctions list, credit bureau, or adverse media source. Separate OFAC, UK, and EU sanctions screening is still required against the resolved ownership structure.

Historical snapshots cause confusion too. Every OpenRegistry request queries the live register directly. There is no internal archive of Belgian records.

That tradeoff cuts both ways. You get current registry-of-record data instead of stale cache exports, though you also inherit upstream instability when the register slows down or changes payload formats.

Querying Belgium through the MCP server

Belgium is active on the current OpenRegistry server matrix.

A basic company search starts with search_companies:

{
  "jurisdiction": "BE",
  "query": "Colruyt Group"
}

If the enterprise number already appears in onboarding documents, direct retrieval is cleaner:

{
  "jurisdiction": "BE",
  "company_number": "0400378185"
}

That request uses get_company_profile.

Governance review often follows during enhanced due diligence:

{
  "jurisdiction": "BE",
  "company_number": "0400378185"
}

That request uses get_officers.

One operational detail matters. OpenRegistry does not reinterpret Belgian registry payloads before returning them. Your MCP client receives the upstream structure plus unified wrapper fields.

For compliance engineering teams, that removes a recurring audit headache: proving field provenance.

When a regulator asks why a merchant was approved, you can point to the exact registry response returned during onboarding rather than relying on a vendor-normalised derivative.

Belgian quirks that trigger false positives

Belgian onboarding failures are often structural, not fraudulent.

Three patterns appear repeatedly:

Multilingual company names
Enterprise units versus establishment units
Legal form abbreviations changing over time

A supplier may submit “SRL” while older records still reference “SPRL” after reforms under the Belgian Companies and Associations Code. Systems that treat those as unrelated legal forms reduce match confidence without adding any useful signal.

Address handling creates similar trouble. Dutch and French municipality variants can appear across separate filings for the same entity.

Raw upstream fields help because analysts can inspect the original KBO representation directly instead of trying to reverse-engineer a matching score from the legacy paid databases.

Belgian filings also expose detailed NACE activity codes. Those codes help with risk segmentation, though they should not be treated as proof of current activity. We use them as one signal during onboarding review, especially for marketplaces and payments flows where merchant category drift shows up regularly.

Most KYB failures come down to provenance rather than missing enrichment data. Internal audit teams want to know which register was queried, when the lookup happened, and whether the returned data can be reproduced later. Belgian KBO checks fit that workflow well because the enterprise number stays stable across operational and filing records.

OpenRegistry exposes the Belgian KBO/CBE through MCP with live registry queries and preserved upstream fields. Current jurisdiction coverage is listed at https://openregistry.sophymarine.com

Swiss Zefix records: what you can pull live in 2026

OpenRegistry — Sat, 04 Jul 2026 15:01:22 +0000

A Swiss UID can survive multiple commercial register changes without breaking legal continuity. That trips people up during cross-border diligence, especially after a canton migration or a GmbH-to-AG conversion ahead of a financing round.

Zefix, Switzerland’s central business index, exposes more than a company search page. The register ties cantonal Handelsregister records together through a federal UID structure, which makes entity tracing less fractured than many finance teams assume.

For IPO diligence or AML reviews, the useful bit sits in the metadata attached to each entity record.

Fields that matter during Swiss entity checks

A standard get_company_profile call for Switzerland returns core identifiers plus canton-level Handelsregister data.

The unified schema includes:

company name
legal form
registry status
registered address
incorporation date
canton code
UID number
commercial register number

The upstream jurisdiction_data payload from Zefix also carries fields that become useful during reconciliation work:

uid
ehraid
registryOfCommerceCanton
legalSeat
purpose
status
deletionDate

purpose turns out to be unusually valuable during counterparty reviews. Swiss entities often describe operating activity in much more detail than equivalent UK SIC filings. A commodities subsidiary may spell out treasury activity, shipping operations, or financing mandates directly in the corporate purpose text.

Canton linkage matters too. Zug, Geneva, Zurich, and Ticino attract noticeably different mixes of holding companies and treasury vehicles. During ownership-chain mapping, the canton often gives quicker context than the company name itself.

OpenRegistry does not reinterpret any of these fields. The MCP server returns the upstream register structure directly, so extraction logic and classification stay inside the client application or assistant.

What Swiss registry data does not include

Switzerland still separates several high-value compliance datasets from the public commercial register.

You will not get beneficial ownership data comparable to AMLD5 public UBO systems because Zefix does not expose a broad public beneficial-owner register. Nominee arrangements, indirect control structures, and trust relationships still need document review outside the registry.

OpenRegistry also does not provide sanctions screening, PEP matching, or credit scoring.

Historical snapshots are another gap. Every request hits the live upstream source. If a director resigns today, the current state updates immediately. OpenRegistry does not maintain archived registry states.

Filing depth varies by canton as well. Some cantonal registers expose richer filing histories and publication references than others. During M&A diligence, material events still need cross-checking against SHAB publications and audited accounts.

Querying Swiss companies through MCP

The Swiss register is available through the OpenRegistry MCP endpoint.

A basic entity search looks like this:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "CH",
    "query": "Glencore"
  }
}

Once the target entity is identified, you can request the full profile:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "CH",
    "company_number": "CH-170.3.027.129-9"
  }
}

Swiss commercial register numbers are canton-specific, so formatting matters. Removing punctuation can break reconciliation against legal opinions, LEI records, or banking onboarding systems.

If filing metadata is exposed, recent registry activity can be queried directly:

{
  "tool": "list_filings",
  "arguments": {
    "jurisdiction": "CH",
    "company_number": "CH-170.3.027.129-9"
  }
}

That becomes useful during financing events where authorised signatory changes or board rotations need tying back to a specific filing window.

Swiss registry quirks that show up in diligence

Swiss entities often sit inside layered holding structures spanning Zug, Luxembourg, the Caymans, plus Dutch financing vehicles. Zefix gives you the Swiss node of the structure, not the full ownership graph.

The interesting details usually sit inside status changes or legal-form transitions.

We ran into this during a review of a debt issuer that converted from GmbH to AG shortly before issuance. The operating business stayed the same. Governance mechanics changed materially because of the legal-form conversion. Registry status fields also expose dormant entities that still appear in active financing arrangements.

Language creates another operational problem. Registry entries may contain German, French, or Italian terminology depending on the canton. Pipelines built around English-only officer titles tend to misclassify Swiss signatories.

Returning the raw upstream structure helps. Finance teams can apply their own translation rules and internal classifications instead of depending on pre-processed labels pulled from stale aggregator exports.

Where this fits in KYB workflows

Swiss onboarding failures often happen at entity resolution rather than sanctions screening.

Treasury teams need to verify that the issuer named in loan documentation matches the entity recorded in the canton register. M&A analysts need to separate an active operating subsidiary from a dissolved holdco carrying a similar trading name. Compliance teams need registry pulls tied to filing dates, then stored as part of the audit trail.

Direct MCP access changes that workflow. Instead of copying records manually from cantonal portals into spreadsheets, the register query becomes part of internal tooling or assistant workflows.

OpenRegistry currently serves Switzerland alongside jurisdictions including GB, FR, NL, KY, HK, and RU through the same MCP interface. Current coverage and live jurisdiction status are listed at https://openregistry.sophymarine.com/mcp

PRH in practice: what Finland's registry exposes in 2026

OpenRegistry — Fri, 03 Jul 2026 15:01:11 +0000

Finnish Trade Register extracts still keep the Business ID (y-tunnus) separate from the diary references tied to the filing that created the entry. That split matters when you are checking statutory notice timing under the Finnish Trade Register Act (Kaupparekisterilaki 564/2023), since the filing timestamp and registration timestamp can drift apart by several days.

PRH is one of the tidier Nordic registers to query programmatically. The Patentti- ja rekisterihallitus data model is filing-oriented and stays fairly consistent across private companies (Oy) and listed public companies (Oyj). It is not a beneficial ownership register. Finnish beneficial ownership disclosures sit under a separate AML framework with statutory access controls.

OpenRegistry exposes the live PRH register through MCP. FI currently sits alongside jurisdictions including GB, NO, FR, IE, IT, NL and RU. Queries go straight to the upstream source. We do not remap Finnish field names into inferred ownership structures or internal risk scores.

The fields that actually matter

A standard get_company_profile request against Finland returns the expected identifiers first:

business_id
company_name
company_form
registration_date
registered_office
company_status

Most of the interesting material sits under jurisdiction_data. PRH often exposes filing references, upstream registration metadata and line-of-business classifications that the legacy paid databases tend to compress into a short company summary.

Finnish entities commonly surface structures connected to:

trade register entries
parallel business names
board composition
procuration rights
liquidation or restructuring status

That distinction becomes important when you are checking signatory authority or sanctions exposure. A company can show an active board registration while keeping representation rights restricted in a separate filing entry.

Officer data follows the same pattern. get_officers can expose registered board members, managing directors or authorised signatories. Formal governance status is usually reliable. De facto control analysis is another matter.

A typical MCP search looks like this:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "FI",
    "query": "Nokia Oyj"
  }
}

Once you have the Business ID, profile retrieval is straightforward:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "FI",
    "company_number": "0112038-9"
  }
}

The operational detail worth watching is the raw payload shape. OpenRegistry returns the upstream PRH structure under jurisdiction_data, including Finnish terminology and filing references exactly as supplied by the source register.

Beneficial ownership after C-601/20

Finland implemented beneficial ownership disclosure obligations through the AML regime and 5AMLD. Public access narrowed across the EU after the CJEU rulings in Joined Cases C-37/20 and C-601/20.

A fair amount of vendor marketing around “real-time UBO access” skips over that legal distinction.

PRH maintains beneficial ownership information for reporting entities, but access is not equivalent to ordinary trade register access. OpenRegistry does not bypass AML-gated datasets and does not expose restricted beneficial ownership records where statutory controls apply.

For enhanced due diligence work, the Finnish Trade Register mainly serves as a source of corporate existence and authority evidence. It is useful for checking:

legal existence
board authority
merger status
bankruptcy proceedings
registered representation rights

On its own, though, it is not enough for ownership-chain analysis under the OFAC 50 Percent Rule or comparable EU restrictive measures regimes.

The limitation comes from statute. Not product design.

Filing access and evidentiary use

In practice, Finnish filing records are often more useful than summary company profiles. list_filings can identify board changes, amendments to articles of association or restructuring events.

Example:

{
  "tool": "list_filings",
  "arguments": {
    "jurisdiction": "FI",
    "company_number": "0112038-9"
  }
}

Where the upstream register exposes documents publicly, fetch_document retrieves the underlying filing itself rather than a generated summary.

That difference shows up quickly in cross-border disputes and M&A diligence work.

The question is rarely whether a filing exists. More often, the issue is whether the filing language actually authorises the transaction under review. Finnish signatory rules can become surprisingly granular. A requirement for two authorised signatories acting jointly is operationally very different from sole managing-director authority.

PRH records also help when reconciling Finnish entities against LEI datasets or securities disclosures. Listed issuers in Finland often reuse the same registration references across annual reports, trade register filings and EDINET-linked disclosure material.

What PRH does not provide

There are limits to the registry surface.

Finland does not expose unrestricted beneficial ownership datasets through the ordinary trade register interface. OpenRegistry also does not keep historical snapshots. If a board member changed yesterday, the query reflects the current upstream state.

There is no sanctions screening layer. No PEP matching either.

OpenRegistry also does not infer ownership percentages from officer appointments or filing language. From a legal perspective that sounds obvious. A surprising number of compliance products still do exactly that.

Keeping registry evidence separate from analytical conclusions produces a cleaner audit trail. A PRH extract is source evidence. An inferred ownership graph generated from filing text is something different.

Finland remains one of the steadier European registers for live corporate status checks because the filing metadata is structured and fairly consistent. For KYB workflows that need direct register provenance rather than aggregator summaries, OpenRegistry exposes the live PRH register through MCP at openregistry.sophymarine.com/mcp

Norway’s Brønnøysundregistrene through MCP

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

Norway assigns every registered entity a nine-digit organisasjonsnummer. The checksum catches most transcription mistakes before you even touch the register. Useful when you are reconciling offshore subsidiaries from an OCR-damaged invoice dump at 2am.

Brønnøysundregistrene is also one of the tidier European registers to query programmatically. Public records expose stable identifiers, filing metadata, address blocks, officer data. You are not forced through scanned PDFs for every lookup. After dealing with Polish KRS extracts or Russian выписка records from the FNS, the Norwegian system feels oddly practical.

OpenRegistry exposes live Brønnøysundregistrene data through MCP. Calls hit the official register directly rather than a scraped mirror or delayed export.

For newsroom investigations, the company name is usually the least interesting field. Structure matters more. Norwegian records often expose values such as:

organization_number
name
organization_form
registration_date
business_address
postal_address
status
industry_code
industry_description

The raw jurisdiction_data payload keeps upstream Norwegian field names where possible. That helps during fact-checking. When another reporter asks where a value originated, you can point straight at the registry response instead of arguing over a vendor-normalised schema.

Officer records are where cross-border tracing starts to get useful. A typical get_officers call exposes directors and management roles tied to the organisasjonsnummer. Norwegian filings separate board structures from executive functions more clearly than several southern European systems. Role mapping becomes less fuzzy.

A basic MCP query looks like this:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "NO",
    "query": "AKER ASA"
  }
}

That returns candidate entities with organisation numbers. Once you have the identifier, you can request the full company profile:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "NO",
    "company_number": "886581432"
  }
}

For procurement investigations or sanctions reporting, the next move is often officer mapping:

{
  "tool": "get_officers",
  "arguments": {
    "jurisdiction": "NO",
    "company_number": "886581432"
  }
}

This is where MCP starts fitting investigative workflows rather than basic compliance lookups. You can pivot from a Norwegian holding company into other jurisdictions exposed through the same server. OpenRegistry currently covers 27 registers, including Norway, Finland, Poland, the Cayman Islands, Russia, the UK, New Zealand. That cuts down the usual browser juggling and messy export handling.

The limits still matter.

Norway is comparatively open, though beneficial ownership visibility across Europe became uneven after the CJEU C-601/20 ruling. Several UBO registers moved behind AML-gated access or reduced public visibility altogether. OpenRegistry does not bypass those restrictions. If the upstream register blocks public access, the MCP layer cannot return the data.

Filing access has its own quirks. Some records are fully structured. Others point toward attached filing artefacts that still require manual reading. Teams accustomed to Companies House bulk JSON exports sometimes expect every register to behave identically. Brønnøysundregistrene is cleaner than most systems. Document interpretation still falls on the reporter.

Another operational detail matters during sensitive investigations: OpenRegistry returns raw upstream values instead of inferring ownership chains automatically. Less convenient at first glance. Then legal review starts.

Anyone who worked on Panama Papers reporting or OCCRP corporate tracing has seen bad entity resolution contaminate an entire graph. Two directors with similar transliterated names get merged together, then the mistake spreads through downstream analysis. Registry provenance takes longer to work with, though it is safer.

Norwegian records become more useful when combined with procurement disclosures or shipping data. I have seen reporters trace vessel-management structures by pivoting from AIS ownership hints into Norwegian entities, then checking board appointments against leaked correspondence. The register does not tell the whole story by itself. It gives you authoritative anchor points.

OpenRegistry does not store historical snapshots. Every request reflects the current state of Brønnøysundregistrene when the query runs. That helps during live reporting where directors resign mid-investigation or entities dissolve before publication. It also means you should archive your own evidence trail. Save response payloads. Keep filing references. Timestamp the records you rely on.

One operational detail is easy to miss: the anonymous OpenRegistry tier works without sign-up and allows 20 requests per minute per IP. For small newsroom projects or quick subsidiary checks, that is usually enough to validate a lead before wiring the register into internal tooling.

The MCP endpoint is available at openregistry.sophymarine.com/mcp for direct calls against the Norwegian register and the other supported jurisdictions.

Poland's KRS registry: fields worth checking before LOI

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

Four filing dates appeared within a two-week span on a Warsaw acquisition target last quarter. The legacy paid databases still listed the old board half a year later. KRS had already published the management change, revised share capital, plus a new supervisory board appointment.

That delay becomes obvious during diligence.

Poland’s Krajowy Rejestr Sądowy (KRS) is one of the registers where direct access matters more than tidy summaries. Court-record updates usually hit the register before commercial datasets catch up, especially during restructurings, distressed sales, or internal group transfers.

For transaction teams, the useful material is often the filing sequence itself and the officer records attached to the court registration.

What KRS returns through OpenRegistry

OpenRegistry exposes live KRS data through MCP tool calls. Upstream fields arrive under jurisdiction_data without being mapped into a separate schema.

A standard get_company_profile lookup for a Polish entity will usually include:

krs_number
regon
nip
legal_form
registration_date
status
share_capital
registered address fields from the KRS entry

Those numbers carry more weight than they first appear to.

Earlier this year we reviewed a carve-out where the seller circulated a spreadsheet listing two subsidiaries with near-identical names. Their REGON numbers differed. KRS also showed one company had already entered liquidation proceedings. The spreadsheet skipped that detail entirely.

Officer records matter for another reason. KRS separates management board roles from supervisory board appointments. get_officers can return:

officer names
appointment dates
representation rules
role titles
resignation or dismissal references where published

The representation clauses need close reading. Polish companies often require two board members acting jointly, or one board member together with a proxy. During signing-authority checks, that line tends to matter more than the deal presentation.

list_filings exposes the filing chronology attached to the company record. Depending on the entity type and publication status, you may see:

annual financial statements
board changes
capital amendments
articles of association updates
merger documentation
liquidation notices

Filing timing can reveal transaction activity before it surfaces elsewhere. Capital increases, governance reshuffles, ownership-related changes: those often appear in KRS first.

What you will not get

Poland does not expose every ownership dataset openly.

The Central Register of Beneficial Owners (CRBR) sits outside KRS, and some AML-related access routes carry legal restrictions. OpenRegistry does not bypass gated ownership systems or expose restricted AML records.

Historical snapshots are not included either.

Each OpenRegistry request hits the live register source. If a filing changes status, disappears, or gets corrected upstream, the response changes as well. That works for live diligence. Less so when reconstructing historical states across several years.

Document structure is another limitation.

Some KRS filings still arrive as documents rather than structured fields. Older records frequently appear as scanned PDFs with uneven formatting. In practice, you still end up reading attachments manually.

The awkward cases are usually transliteration inconsistencies, merged historical records, or filing attachments published in different formats depending on the year.

Querying KRS through OpenRegistry MCP

A basic company search starts with the entity name or identifier.

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "PL",
    "query": "CD Projekt"
  }
}

Once you have the company number, pull the live profile.

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "PL",
    "company_number": "0000066865"
  }
}

For diligence work, the next call is usually filings or officers.

{
  "tool": "list_filings",
  "arguments": {
    "jurisdiction": "PL",
    "company_number": "0000066865"
  }
}

{
  "tool": "get_officers",
  "arguments": {
    "jurisdiction": "PL",
    "company_number": "0000066865"
  }
}

If a filing includes an attached source document, fetch_document retrieves the registry artefact directly.

That matters during disputed diligence reviews. I saw one vendor data room summarise a board appointment date nearly a month earlier than the actual KRS filing. Pulling the underlying document settled the argument immediately.

Where KRS helps in cross-border diligence

Polish subsidiaries often sit inside larger holding chains involving Dutch, Cypriot, or Luxembourg entities. Timing drift between registers creates problems quickly.

The pattern is usually simple. A commercial data provider crawls KRS periodically, maps the fields into its own structure, then republishes the result later. Meanwhile, the underlying register may already show a management turnover, restructuring filing, or capital reduction.

For pre-LOI screening, the workflow is normally straightforward:

search the Polish entity directly
compare officer names across connected jurisdictions
inspect recent filings for capital movement
verify representation rules before signing

That final step gets missed surprisingly often.

On a mid-market acquisition involving a manufacturing group near Katowice, the SPA signature block listed a single board member as authorised signatory. KRS showed the company required two joint management signatures after a governance amendment filed three weeks earlier. External counsel spotted the mismatch late because the commercial database had not refreshed.

OpenRegistry does not replace the financial modelling layers provided by the large data vendors. Most teams still rely on those systems for projections and broader corporate-family mapping. The difference here is direct access to the registry of record through MCP, with upstream fields preserved exactly as published.

If your diligence tooling already uses AI agents or internal workflows, the live KRS connection is available at https://openregistry.sophymarine.com/mcp