DEV Community: OpenRegistry

Monaco’s RCI registry: what you actually get from the data

OpenRegistry — Sun, 21 Jun 2026 15:01:52 +0000

Monaco lists roughly 14,000 active entities in the Registre du Commerce et de l’Industrie (RCI). The register is small. That scale changes how you read it during diligence. Larger European registries carry dense corporate histories; Monaco does not. The dataset stays thin, yet updates often surface quickly because the RCI itself is the primary record.

I ran into this during a small‑cap hospitality acquisition. The target group held a Monaco distribution subsidiary. Our diligence folder included an export from an aggregator that still listed the previous gérant. The RCI entry had already switched to the new one. The filing was only a few weeks old. Once paperwork reaches the registry, the change usually appears without much lag.

What the RCI actually returns

RCI entries stay concise. Long historical trails are rare. The register concentrates on the entity as it currently stands in law.

Through OpenRegistry the get_company_profile tool returns fields taken from the RCI extract itself. Typical fields include the company name and its RCI number. You also receive the legal form, registered address, incorporation date, declared activity, plus the stated share capital.

The raw jurisdiction_data payload often keeps the registry’s own wording. Monaco entries frequently retain French field names exactly as written in the extract. You will see labels such as forme_juridique, capital_social, or date_immatriculation. Leaving them untouched helps when you compare the response with the official PDF extract or a court filing.

Officer information comes from a separate request. The get_officers tool returns the individuals or corporate managers recorded against the entity. Monaco companies often show titles such as gerant or administrateur. Some legal forms list a president. The record normally gives the person’s name together with the role. Appointment dates appear if the filing included them.

Filings exist, though the stream stays light. Large registries might show decades of documents for a single company. Monaco entities often surface only a handful. When filings are present, list_filings returns references to items such as amended statutes or registry extracts. The files themselves are usually PDFs of the submitted paperwork. Structured filing metadata is uncommon.

That changes the emphasis during diligence. The current legal snapshot matters more than the document trail.

Fields you will not see

Monaco restricts access to ownership data.

The beneficial ownership register sits behind AML controls and does not appear in the public RCI interface. Because the source registry does not publish that material openly, get_persons_with_significant_control returns nothing for this jurisdiction.

Shareholder disclosure is also narrow. Many Monaco companies do not publish shareholder lists in the public register. Even where the profile shows the total share capital, the distribution of those shares rarely appears.

Financial statements form another gap. The RCI is not a financial disclosure platform in the way the UK system operates. Revenue figures will not appear in the registry response. Balance sheet data will not either.

The result is a register that confirms legal existence and governance. The economic picture mostly sits elsewhere.

Querying Monaco via the MCP tools

The RCI can be queried through the OpenRegistry MCP server using the same pattern used for other jurisdictions. Start with a name search.

Example tool call:

search_companies({
  "jurisdiction": "MC",
  "query": "SOCIETE DES BAINS DE MER"
})

This returns matching entities together with their RCI numbers. Once you have the registration number, request the company profile.

get_company_profile({
  "jurisdiction": "MC",
  "company_number": "56S00523"
})

Officer records come from another call.

get_officers({
  "jurisdiction": "MC",
  "company_number": "56S00523"
})

If the registry lists documents for the entity, the filing index exposes them and provides document identifiers.

list_filings({
  "jurisdiction": "MC",
  "company_number": "56S00523"
})

A document can then be retrieved with fetch_document.

Practical use in cross‑border diligence

Monaco rarely appears on its own in transaction work. Most often it sits inside a wider European structure. I usually encounter it as a holding or distribution vehicle connected to French or Italian operating subsidiaries.

Officer matching helps here.

Pull the Monaco directors from the RCI record. Then check the same names across other national registries. The MCP endpoint already exposes several European ones. When the same person appears across two subsidiaries, the overlap often hints at where the group’s operational centre actually sits. Ownership disclosure may remain opaque; the management pattern still tells a story.

Capital adjustments also surface quickly in Monaco records. Filings that change the capital_social figure tend to appear soon after the corporate action. A capital increase during a live transaction window can signal restructuring within the group.

RCI updates sometimes reveal dormant companies returning to use. A new gérant can be the first clue. A fresh registered address can signal the same thing. Shelf entities occasionally reappear this way when a group needs a local vehicle.

None of this replaces deeper ownership work. Monaco’s framework limits what the public register shows. The registry still answers the early diligence questions. Does the entity exist? Who manages it today? Has anything changed recently?

Direct queries to the register avoid the lag that appears in aggregator datasets. The Monaco RCI endpoint is available through the OpenRegistry MCP server at https://openregistry.sophymarine.com.

Iceland company registry: querying Skatturinn in code

OpenRegistry — Sat, 20 Jun 2026 15:01:58 +0000

More than 55,000 legal entities appear in Iceland’s national register maintained by Skatturinn, the Directorate of Internal Revenue. For KYB teams that number matters. The dataset is small. A direct register lookup often finishes faster than a query against one of the legacy paid databases during onboarding.

Iceland never built a large commercial disclosure portal. The tax authority keeps the core company register and attaches each entity to a national identification number called the kennitala. Every company receives one at incorporation.

That single number changes how a compliance check works. When the onboarding form collects the kennitala, matching becomes deterministic. Many jurisdictions push teams toward fuzzy name searches spread across several registers. Iceland usually starts with one identifier and a single lookup.

The first verification step is plain enough. Confirm the submitted kennitala resolves to an active entity. Then compare the registry name with the onboarding record. If those match, the remaining review scope shrinks quickly.

Data returned by Skatturinn

The Skatturinn register publishes core identity details for the company along with basic management information. OpenRegistry returns the upstream response inside jurisdiction_data. Nothing gets rewritten. The fields arrive exactly as the registry publishes them.

A get_company_profile request usually returns attributes such as:

kennitala – Icelandic company identification number
heiti – legal entity name
heimilisfang – registered address
postnumer – postal code
skraningardagur – registration date
rekstrarform – legal structure such as ehf. (private limited company)

Officer data comes from the same register. Call get_officers and the payload often includes:

nafn – officer name
kennitala – personal or corporate identifier
hlutverk – role in the entity
skipunardagur – appointment date

Those fields stay in Icelandic. OpenRegistry does not translate registry terminology or reshape the schema. Auditors usually prefer that. The wording matches the official source, which helps when someone reviews a historical compliance file months later.

The kennitala itself tends to stay stable across the life of the company. Many compliance systems store it as the primary reference and reuse the same number for periodic refresh checks. Simple. Reliable.

What the register does not expose

Skatturinn publishes less ownership information than some European registers. Shareholder lists rarely appear through the same interface. Beneficial ownership data sits outside the standard company dataset.

That arrangement mirrors the wider European position after the Court of Justice ruling in case C‑601/20. Several beneficial ownership registers moved behind controlled AML access following that judgment. Iceland follows roughly the same pattern. Core corporate identity remains public. Ownership disclosure typically lives in regulated compliance channels.

For KYB engineers the split is manageable. Treat Skatturinn as the source of record for incorporation status and officer roles. Ownership checks normally pull from a different dataset maintained under AML access controls.

Querying the register through OpenRegistry MCP

OpenRegistry exposes the Icelandic register through the same MCP interface used for the other jurisdictions on the platform. The client sends the jurisdiction code IS with either a name fragment or an identifier.

Most workflows begin with a search call.

search_companies({
  "jurisdiction": "IS",
  "query": "Eimskip"
})

Production systems rarely rely on names alone. They usually send the kennitala directly. Identification numbers remove ambiguity and shorten the audit trail when a compliance analyst reviews the lookup later.

Once the entity is confirmed, request the full register record.

get_company_profile({
  "jurisdiction": "IS",
  "company_number": "kennitala-from-search"
})

Officer information comes from the same source.

get_officers({
  "jurisdiction": "IS",
  "company_number": "kennitala-from-search"
})

Each call queries the register in real time. The response includes OpenRegistry’s structured wrapper plus the raw jurisdiction_data payload returned by Skatturinn.

How this fits into a KYB pipeline

Onboarding Icelandic companies is usually short compared with many EU jurisdictions. A typical compliance workflow inside a payments or fintech stack often looks like this:

Merchant submits legal name together with the kennitala.
search_companies verifies the entity exists in the register.
get_company_profile confirms legal name and registration data.
get_officers returns the current management roles.

Every step stores the registry response as evidence. Later, if internal audit revisits the file, the same identifier can reproduce the lookup exactly.

The size of the register also changes how batch checks behave. Iceland holds far fewer entities than jurisdictions with tens of millions of companies. Refresh jobs therefore run quickly. The identifier space stays small, and the register queries remain lightweight even under steady load.

For engineers building KYB infrastructure, Iceland shows the advantage of identifier‑first verification. The register structure removes much of the name‑matching guesswork. The modest dataset keeps real‑time queries predictable as traffic grows.

OpenRegistry exposes the Skatturinn register through the MCP server at https://openregistry.sophymarine.com.

Cayman Islands company register — what the public record shows

OpenRegistry — Fri, 19 Jun 2026 15:01:55 +0000

More than 120,000 active companies sit on the Cayman Islands register. The territory itself has under 80,000 residents. That imbalance explains why Cayman appears so often in fund structures, SPV stacks, and cross‑border acquisition diagrams.

The registry does not behave like most European ones. Public corporate data lives on two different surfaces. The Registrar of Companies holds the legal entity record. The Cayman Islands Monetary Authority (CIMA) maintains a separate register for regulated bodies such as funds or insurers. A proper check usually means querying both.

Start with the Registrar. A company profile returned through OpenRegistry contains the basic identifiers most people expect. The response includes fields like company_number and name. Status appears as its own field. The incorporation date arrives separately as well.

The registry payload also includes a block called jurisdiction_data. That section carries values straight from the Cayman register. Entity classification appears there. So does the registered office provider. Cayman distinguishes clearly between forms such as Exempted Company or Limited Liability Company, and the registry keeps that wording intact.

That classification carries real meaning. International listings routed through Cayman almost always sit inside an Exempted Company. The structure exists for business conducted outside the islands. It is designed for capital moving across borders.

Look at a typical ownership chain. The Cayman entity often acts as the legal issuer. Operational subsidiaries sit somewhere else entirely. Hong Kong appears often. Singapore does as well. Delaware turns up frequently in US‑linked structures.

A lookup through the MCP server begins with a search.

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "KY",
    "query": "Example Holdings Ltd"
  }
}

The response returns candidate entities with their registry numbers. That number matters far more than the name. Cayman structures reuse naming patterns constantly. Many funds contain “Holdings”, “Capital”, or “Investment” in the title. The registry number becomes the stable reference.

Once the number is known, request the company profile.

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "KY",
    "company_number": "123456"
  }
}

The response keeps the registry structure intact inside jurisdiction_data. You receive the official name exactly as recorded. The incorporation date appears in the same format used by the register. Legal status is passed through unchanged. The registered office address arrives the same way.

OpenRegistry does not reinterpret the record. No risk scoring. No derived labels. The MCP client receives the raw registry fields and decides how to process them.

In finance work, the registered office line often carries more signal than people expect. Cayman companies must maintain a licensed corporate service provider on the islands. A single provider may appear across thousands of entities. Patterns start to show up quickly. Several SPVs sharing the same office provider often belong to the same financing structure.

Director information forms another layer. Visibility depends on the company. Some entities file director registers that appear in the public interface. Others restrict access through their service provider.

When the register exposes officers, OpenRegistry returns them through get_officers. Field names follow the registry’s own structure. Nothing is renamed.

Filings look sparse compared with many European systems. You will not find the long trail of annual accounts common in the UK. France exposes far more filings as well. Cayman records tend to focus on structural events. Incorporation documents appear. Name changes show up. Status updates appear when they occur.

If the register exposes a document reference, the MCP server can retrieve the file using fetch_document. The request uses the identifier returned in the filings list.

The second surface sits with CIMA. Regulated funds appear there. Investment advisers and insurers do too. Entries contain licence status and the supervisory category assigned by the authority. A regulatory registration number appears as well.

Analysts usually cross‑check both sources. The legal issuer might be an Exempted Company listed by the Registrar. The regulated investment fund may appear only in the CIMA database.

Some data remains outside public reach. Cayman operates a beneficial ownership regime under the Beneficial Ownership Transparency framework. The register itself is not public. Access is limited to competent authorities and law‑enforcement bodies. When AML work requires beneficial owners, investigators normally rely on disclosures further along the ownership chain.

Freshness is another detail worth keeping in mind. Many Cayman companies exist purely as transaction vehicles. They are incorporated for a listing or financing deal. Then they sit unchanged for years. Updates arrive rarely. A strike‑off notice can become the first signal that anything has changed.

This split model explains why programmatic access helps. IPO preparation often requires confirming the Cayman issuer while tracing subsidiaries elsewhere. The same review may involve UK companies. Hong Kong entities appear frequently in the same structures. Querying each register manually slows everything down.

OpenRegistry exposes the Cayman Islands register together with 26 other national company registries through one MCP endpoint. Connection details and documentation sit at https://openregistry.sophymarine.com.

Querying Russia’s EGRUL registry: what the FNS actually exposes

OpenRegistry — Thu, 18 Jun 2026 15:02:07 +0000

Every Russian legal entity receives a 13‑digit OGRN at the moment it enters the Единный государственный реестр юридических лиц (EGRUL). The number does real work. Federal Law No. 129‑FZ “On State Registration of Legal Entities and Individual Entrepreneurs” treats the EGRUL entry as the authoritative corporate record for most statutory purposes. When a dispute reaches an arbitration court, lawyers usually place the EGRUL extract near the front of the evidence bundle.

Russian corporate disclosure sits across two public systems run by the Federal Tax Service (ФНС). EGRUL stores registration data for companies. A separate platform, ГИР БО (GIR BO), publishes accounting statements. Each operates under its own legal framework.

EGRUL exists under Federal Law No. 129‑FZ together with several Ministry of Finance orders that describe how a registry entry must be structured. GIR BO appeared later through Federal Law No. 402‑FZ “On Accounting”. Companies submit their annual financial statements to the tax authority. GIR BO publishes those filings once processed.

On paper the split looks tidy. Actual registry queries tell a slightly messier story. Small quirks surface as soon as you start pulling the data through an API.

Registry fields that actually appear in upstream records

Most EGRUL entries revolve around three identifiers: OGRN, INN, KPP. OGRN is the state registration number issued at incorporation. INN identifies the taxpayer in the Russian tax system. KPP shows the reason for registration at a specific tax office. Those numbers appear on invoices, contracts, disclosure forms. They anchor the company to the tax infrastructure.

A registry lookup also returns the canonical name fields recorded by the tax authority. The field full_name normally carries the statutory Russian name written in the charter. short_name appears when the charter defines one. The dataset also includes registration_date together with a status flag that indicates whether the entity remains active or has been liquidated.

Director data sits directly in the EGRUL entry. The register records the individual authorised to act on behalf of the company without a power of attorney. Registry datasets usually describe that position as the head of the executive body. In day‑to‑day terms it maps fairly closely to a managing director entry in several European registers.

Ownership disclosure is narrower than many compliance teams expect. EGRUL lists the founders or participants who contributed to the charter capital. In raw registry output the section usually appears as founders. Share percentages sometimes appear when the capital structure is simple.

That field does not represent beneficial ownership. Russian companies must identify their beneficial owners internally under Federal Law No. 115‑FZ covering AML and counter‑terrorist financing duties. The public registry never publishes that information.

Operational activity appears through OKVED classification codes. These sector codes matter during sanctions screening or export‑control analysis. Even when a company description says very little, the OKVED list often reveals what the firm actually does.

What the registers do not provide

EGRUL is not a beneficial ownership register. Teams familiar with the UK PSC framework under Companies Act 2006 s.790E will not find an equivalent dataset here. Russian AML law requires companies to maintain beneficial owner records and disclose them to banks or regulators when asked. Public access never became part of the model.

GIR BO comes with its own constraints. The system publishes accounting statements filed with the tax authority, though the dataset updates only once per reporting year. Filings normally contain the balance sheet and the profit statement required under Russian accounting standards. Supporting schedules appear irregularly. Some entities submit abbreviated accounts.

Another detail concerns extracts. The official “выписка из ЕГРЮЛ” still carries weight in litigation and due diligence. Machine‑readable registry responses mirror the same entry stored by the tax authority. Lawyers nevertheless attach the PDF extract to court filings or transaction disclosure bundles because judges recognise the format immediately.

Querying the registry through OpenRegistry MCP

OpenRegistry exposes Russian registry data through the same MCP interface used for other jurisdictions on the server such as GB, FR, NL and RU. The service queries Federal Tax Service sources and returns the raw upstream fields under jurisdiction_data.

Most sessions start with a search by company name or identifier.

Tool call example:

search_companies({
  "jurisdiction": "RU",
  "query": "Газпром"
})

The response lists candidate entities with their OGRN and INN numbers. Once you have the registration number you can pull the full registry entry.

get_company_profile({
  "jurisdiction": "RU",
  "company_number": "1027700070518"
})

That response includes identifiers, the registration date, the legal address, director information, and the founder section exactly as published by the tax authority.

Financial statements from GIR BO appear through the filings endpoint when the tax service has released them.

list_filings({
  "jurisdiction": "RU",
  "company_number": "1027700070518"
})

If the register exposes an official extract or another statement document, the file can be retrieved directly.

fetch_document({
  "jurisdiction": "RU",
  "document_id": "<registry-document-id>"
})

The returned PDF uses the same выписка format that often appears in diligence memoranda.

Russian corporate disclosure often feels opaque to teams used to the European BRIS datasets. The structure is simpler once you trace the legal boundaries. The operative corporate record lives in EGRUL. Accounting statements sit in GIR BO. Beneficial ownership information sits outside the public register under AML obligations.

For sanctions analysis the director entry and the founder list still provide useful signals. Ownership chains frequently pass through domestic holding companies whose own EGRUL entries reveal the next layer of shareholders. Walk those entries step by step and a corporate structure begins to appear, even without a public UBO register.

That detail matters when applying ownership thresholds such as the OFAC 50 percent rule or similar limits used in EU and UK sanctions regimes. The legal analysis depends on shareholdings recorded in the register rather than declared beneficial owners.

Live access to the underlying registries is available through the MCP endpoint at https://openregistry.sophymarine.com.

Reading India’s MCA registry via data.gov.in: field quirks

OpenRegistry — Wed, 17 Jun 2026 10:04:38 +0000

India assigns every registered company a 21‑character Corporate Identification Number (CIN). Each position carries a signal: listing status, industry classification, state code, year of incorporation, then a six‑digit sequence. Anyone tracing ownership chains across borders notices quickly that the Ministry of Corporate Affairs dataset behaves unlike most European registers.

The MCA registry acts as the statutory record for Indian companies and LLPs. Most people reach it through the MCA portal. Another entry point sits in the government’s open data catalogue at data.gov.in, where parts of the register appear as downloadable datasets. OpenRegistry queries that catalogue directly. The response mirrors the upstream fields. No scoring layer. No attempt to interpret the values. If the register publishes a column, the API returns the same column.

Fields you actually get back

The MCA dataset mixes routine administrative attributes with identifiers investigators rely on when following ownership trails. A standard company profile response includes entries such as:

CIN
company_name
company_status such as Active, Strike Off, or Under Liquidation
class_of_company
company_category
date_of_incorporation
registered_office_address
roc_code, which identifies the relevant Registrar of Companies office

OpenRegistry keeps the MCA column names intact inside jurisdiction_data. That detail matters. Court filings, insolvency orders, and regulatory notices often cite those exact labels, so matching them becomes straightforward.

Officer data arrives through a separate query. Director listings typically include:

director_name
din (Director Identification Number)
designation
appointment_date

The DIN is the stable anchor. One individual may sit on dozens of boards across unrelated entities. The identifier lets you pivot cleanly from one company to another without guessing whether two similar names refer to the same person. Anyone who has tried mapping common surnames in Mumbai incorporations will recognise the problem.

Filings appear as well. When present, list_filings returns entries attached to the company’s CIN. Each item usually carries a description, the filing date, plus a document identifier. That identifier can then be passed to fetch_document if the underlying dataset exposes the file.

Gaps in the public dataset

The MCA register does not operate as a beneficial ownership database in the sense many investigators expect. India introduced Significant Beneficial Owner rules through amendments to the Companies Act. Public datasets released through data.gov.in still fall short of a full beneficial ownership register.

That gap becomes visible in cross‑border work. A CIN places an entity inside the administrative structure of the register. It does not reveal the natural person controlling the shareholding chain behind the company.

Historical data presents another constraint. The upstream dataset generally reflects the present state of the record. If a director resigned years ago and the current listing no longer shows them, the API output will not reconstruct that earlier timeline. The past disappears unless you captured it when it was still listed.

Document access varies too. Some filings referenced in the dataset link to documents that remain gated behind the MCA portal. Reporters often end up retrieving certain PDFs by hand.

Querying the MCA dataset through MCP

OpenRegistry exposes the Indian register through the same MCP tools used for the other 27 jurisdictions available through the server. The request pattern stays consistent across countries. That consistency helps once an investigation moves from one jurisdiction to another.

Searching by company name:

search_companies({
  "jurisdiction": "IN",
  "query": "Adani Enterprises"
})

Fetching the company profile using the CIN:

get_company_profile({
  "jurisdiction": "IN",
  "company_number": "L17120GJ1993PLC019067"
})

Retrieving the current directors:

get_officers({
  "jurisdiction": "IN",
  "company_number": "L17120GJ1993PLC019067"
})

Listing filings tied to the company:

list_filings({
  "jurisdiction": "IN",
  "company_number": "L17120GJ1993PLC019067"
})

Each request queries the MCA‑derived dataset rather than a rewritten aggregation layer. The raw fields appear under jurisdiction_data. That structure preserves the original schema so the response can be checked against the source register.

Practical use in cross‑border reporting

Indian entities show up frequently in ownership chains tied to commodities trading, infrastructure development, and political finance reporting. Large investigative collaborations encounter them again and again.

The CIN structure gives an early geographic hint. Characters six and seven encode the state associated with the Registrar of Companies. Gujarat incorporations use GJ. Maharashtra entries usually carry MH. A small clue, but it narrows the administrative trail before any document search begins.

DIN numbers help once directors surface across several registers. A person listed on an Indian board may appear as an officer in another jurisdiction. When building a network graph of related companies, that single identifier removes a lot of guesswork.

OpenRegistry exposes the MCA dataset through the same MCP interface used for the UK Companies House register, the Polish KRS, and Russia’s EGRUL extracts. Anyone who has spent time navigating CAPTCHA‑heavy registry sites will recognise the change in workflow.

Connection details and usage examples sit at https://openregistry.sophymarine.com.

Indonesia AHU registry: what a PT lookup actually returns

OpenRegistry — Fri, 12 Jun 2026 15:01:28 +0000

Indonesia’s company register assigns an AHU number to every incorporated entity. The Ministry of Law and Human Rights issues it. The same identifier repeats across incorporation records, shareholder filings, and beneficial ownership disclosures. When you follow ownership through Indonesian paperwork, that number ties the trail together.

Teams outside the country usually encounter AHU data through an export from one of the legacy paid databases. The issue is age. Their snapshot can trail the ministry system by months. I ran into this during a Jakarta diligence review. The data room showed two founders holding equal stakes. The ministry record disagreed. A capital restructuring had been filed three weeks earlier and one founder had already exited via a share transfer.

The AHU register tracks two main company forms. Standard limited companies appear as PT entities. The Omnibus Law reforms introduced PT Perorangan, a simplified vehicle for a single owner. Both sit inside the same ministry system. Beneficial ownership disclosures live there too when a company files them.

Query the registry through OpenRegistry and the response mirrors the upstream payload returned by the ministry. Field names stay in Indonesian. The MCP server places them inside jurisdiction_data rather than translating them into a synthetic schema.

A typical company profile includes fields such as:

nama_perseroan for the registered company name in Indonesian
nomor_ahu for the AHU registration number
status_badan_hukum for the entity’s legal status
tanggal_pendirian for the incorporation date
alamat for the registered address
modal_dasar and modal_disetor for authorised and paid‑up capital

Governance records appear in separate structures depending on the filings a company has submitted. Director and supervisory roles usually retain their Indonesian titles. Direksi refers to the management board. Dewan komisaris denotes the supervisory board. Indonesia uses a two‑tier model. Those labels matter when you map who actually holds authority inside the firm.

Beneficial ownership disclosures appear where the company has submitted them to the ministry. The upstream dataset exposes fields such as nama_pemilik_manfaat and kewarganegaraan. Coverage is uneven. Reporting depends on company submissions rather than an automated reconciliation across filings.

The registry surface is narrower than the UK system many investigators expect. Companies House publishes long filing histories with attached documents. AHU behaves differently. The interface usually returns the current state of the register plus a small set of related records. The underlying Indonesian platform does store notarial deeds and other paperwork. Access often sits behind a separate paid request inside the ministry portal.

That gap shows up during diligence work. Imagine the paid‑up capital figure changes between two registry pulls. The AHU entry confirms that the update took effect. The notarial deed that authorised the change might not appear in the response. Indonesian corporate law requires a notary to record many structural actions. Those deeds remain outside the core registry interface.

The query pattern through the OpenRegistry MCP server matches the structure used for other jurisdictions. Start with a search call to locate the entity.

search_companies({
  "jurisdiction": "ID",
  "query": "PT Tokopedia"
})

The response lists matching entities together with their AHU numbers. Once the identifier is known, the company profile call retrieves the full register snapshot.

get_company_profile({
  "jurisdiction": "ID",
  "company_number": "AHU-0058743.AH.01.01"
})

Governance and ownership records sit behind separate endpoints.

get_officers({
  "jurisdiction": "ID",
  "company_number": "AHU-0058743.AH.01.01"
})

If the company has filed beneficial ownership disclosures, they appear here:

get_persons_with_significant_control({
  "jurisdiction": "ID",
  "company_number": "AHU-0058743.AH.01.01"
})

Each response comes straight from the ministry register. The server does not reinterpret Indonesian field names. If the AHU record changes tomorrow, the query output changes too. No cached translation layer in between.

Indonesia becomes more interesting once the target sits inside a regional holding structure. A common arrangement places the parent company in Singapore or the Cayman Islands while Indonesian operating subsidiaries register through AHU. Mapping that structure means querying each jurisdiction directly. Subscription databases try to assemble corporate trees in advance. Over time they drift. Officer names remain outdated. Share allocations linger long after a transfer.

PT Perorangan entities introduce another wrinkle. A single individual forms them. The shareholder and director often end up being the same person. A quick screening pass can misread that pattern as a nominee setup if the legal form is not recognised.

For teams building automated diligence pipelines, the useful part is consistency. The same MCP interface that queries Indonesia also queries registries such as GB, NL, or HK. Each jurisdiction still returns its own upstream schema. The legal detail stays intact.

The Indonesian registry endpoint is available through OpenRegistry at openregistry.sophymarine.com.

Malaysia’s SSM e-Info — what a KYB query actually returns

OpenRegistry — Wed, 10 Jun 2026 15:01:35 +0000

More than 1.6 million entities sit in Malaysia’s Suruhanjaya Syarikat Malaysia (SSM) register. Every Sdn. Bhd., Bhd., or LLP incorporated in the country begins life with a record there.

For KYB checks, that register is the primary source. When a merchant claims Malaysian incorporation, auditors usually expect the trail to lead back to SSM itself, not to a cached dataset copied somewhere else. The practical question then becomes straightforward: what actually comes back from the registry when you query it?

What SSM e‑Info actually returns

SSM e‑Info exposes the core company profile maintained by the registrar. Through OpenRegistry’s MCP server, those upstream fields appear intact inside jurisdiction_data. They are not renamed. They are not flattened.

A typical profile response contains the identifiers used during onboarding checks. Common fields include:

companyNo – the SSM registration number
companyName – the registered legal name
companyStatus – values such as EXISTING, DISSOLVED, or WINDING UP
companyType – the entity form, for example PRIVATE LIMITED or PUBLIC LIMITED
incorporationDate – the official incorporation date

Address information usually appears in the same payload. Many SSM profiles include a registeredAddress value. Business activity descriptions often appear as well, commonly aligned with Malaysian Standard Industrial Classification (MSIC) codes.

Officer data tends to follow next in a KYB workflow. Director records are returned through the officers endpoint. The registry output normally contains the director’s name, an identification reference, and the appointment date. Those values also remain inside jurisdiction_data. The original registry structure stays visible.

Shareholding data exists in SSM filings. Access is uneven. A profile response does not always return a full shareholder table as structured data. Malaysian company law requires disclosure of share capital and shareholders through statutory filings. In practice the registry output may instead point to filings where that information sits.

That distinction matters during an audit. Each field originates from the registry of incorporation. OpenRegistry passes through the values returned by SSM rather than rewriting them.

What you will not get from SSM

SSM e‑Info is not a beneficial ownership register. Malaysia introduced beneficial ownership reporting through amendments to the Companies Act 2016, followed by the later BO framework. Access to those records is limited to competent authorities.

A public query will not return UBO information. If a KYB workflow requires beneficial ownership, teams usually reconstruct it from shareholder filings, director relationships, or documents provided during onboarding.

Historical coverage varies too. Some filings can be downloaded directly through SSM services. Others appear only as references inside the company profile. Compliance teams often begin with the profile. After that, they decide whether a document retrieval step is necessary.

Sanctions screening sits outside the registry entirely. SSM confirms legal existence and corporate structure. It does not report sanctions exposure or watchlist matches. Those checks remain part of the screening layer in a compliance pipeline.

Querying SSM through OpenRegistry MCP

OpenRegistry exposes the Malaysian register through the same MCP interface used for other supported jurisdictions. The server currently connects to 27 national company registries.

Most KYB flows begin with a search. The assistant calls search_companies using either the company name or a known registration number.

Example tool call:

search_companies({
  "jurisdiction": "MY",
  "query": "Grab Holdings"
})

The response returns candidate matches together with registry identifiers. In Malaysian records, the SSM registration number should be treated as the canonical key.

With that number, the company profile endpoint returns the registry record.

get_company_profile({
  "jurisdiction": "MY",
  "company_number": "201401032123"
})

The response contains the incorporation date, registry status, registered address, and related fields placed inside jurisdiction_data. Many compliance systems store those raw values directly in the KYB audit log. Later, a regulator can reproduce the exact lookup.

Officer verification often follows.

get_officers({
  "jurisdiction": "MY",
  "company_number": "201401032123"
})

The call returns the individuals listed as directors or officers. Compliance tools usually pass those names into sanctions and adverse‑media screening.

If filings are required, the workflow can list them first.

list_filings({
  "jurisdiction": "MY",
  "company_number": "201401032123"
})

Where documents are available, fetch_document retrieves the file referenced by the registry.

Why Malaysian registry access matters in KYB

Malaysia appears regularly in onboarding pipelines for marketplaces and payment platforms operating across ASEAN. A merchant might incorporate locally while selling into several neighbouring markets.

The first control is registry verification. Systems need to confirm the company exists. They also check the registered legal name and identify the directors authorised to act for it.

Direct registry access removes a common audit problem. Aggregated databases often trail the SSM register by weeks. Sometimes months. During a regulatory review the question becomes simple: what did the registry show at the moment you approved the merchant?

A direct query answers that immediately. The onboarding system can store the SSM response payload alongside the timestamp of the check.

The Malaysian register also becomes useful when investigators trace corporate chains. A holding company in Malaysia may sit above subsidiaries in Singapore or Hong Kong. Following that trail means pulling records from each jurisdiction’s own register.

OpenRegistry exposes SSM e‑Info through MCP so assistants and compliance systems can run those checks against the live source. Connection details and documentation are available at https://openregistry.sophymarine.com.

Hong Kong Companies Registry: what the record actually shows

OpenRegistry — Tue, 09 Jun 2026 15:02:45 +0000

Hong Kong assigns every incorporated company a CR No. The number comes from the Companies Registry (公司註冊處) and it stays with the entity for life. Change the name, the identifier remains. The register holds the statutory record for more than a million local companies plus registered non‑Hong Kong entities.

Finance teams see this register often. Hong Kong sits inside many Asian holding structures. Listings pass through it. Bond vehicles do as well. Acquisition SPVs turn up here too. Most entries are private companies limited by shares. When someone needs to confirm which legal entity actually filed a document, the registry record settles the question.

OpenRegistry exposes this register through its MCP server. A request triggers a live Companies Registry search. The response returns upstream fields as they appear in the official source. No reinterpretation layer. Just the record.

What the registry actually returns

A get_company_profile call exposes the same fields visible through the official search interface.

Typical responses include:

company_name, sometimes with a Chinese name variant
company_number (the CR No.)
company_type, frequently “Private company limited by shares”
date_of_incorporation
company_status, for example “Live” or “Dissolved”
registered_address

Those are the basics. The registry’s internal structure also appears in the raw payload.

OpenRegistry keeps that inside jurisdiction_data. The block mirrors the structure used by the registry itself. Sometimes the wording comes straight from the incorporation filing. Sometimes it references the statutory form submitted at registration. Either way, the text reflects the original source.

Officer information lives behind a separate request. Call get_officers and the response lists directors plus the company secretary currently recorded.

That secretary role is rarely missing. Hong Kong law requires every company to appoint one, even when the board itself contains only a single director. Small holding companies still show the role.

Filings form another useful surface. A list_filings call typically returns entries such as:

NAR1 annual return
NNC1 incorporation form
ND2A notice of director appointment or resignation
NR1 change of registered office

Spend a little time reviewing Hong Kong company files and these codes start to look familiar. They come straight from the statutory forms defined under the Companies Ordinance.

What you will not see

The public search does not show shareholder registers. Ownership details usually appear only inside filing documents. The annual return (NAR1) contains one version. The incorporation form (NNC1) may contain another, depending on how the company was set up.

Hong Kong introduced the Significant Controllers Register (SCR) requirement in 2018. Each company must maintain this register internally to record beneficial owners. Access is restricted. Law‑enforcement bodies and certain regulators can request it.

The Companies Registry search itself does not expose SCR data.

For AML tracing, that gap matters. The registry confirms directors. It confirms company status. Filing history appears as well. Ultimate ownership does not.

Documents introduce another practical wrinkle. Retrieving a filing often requires a paid request through the official portal. When available, OpenRegistry returns the filing metadata: form code, filing date, sometimes the document reference. The underlying PDFs still originate from the Companies Registry.

Querying the registry through OpenRegistry MCP

Most workflows start with a name search. Hong Kong company names can include punctuation, spacing quirks, or both English and Chinese versions. Exact matches are not always reliable. Partial searches tend to work better.

Example tool call:

search_companies({
  "jurisdiction_code": "HK",
  "query": "Pacific Holdings"
})

The response returns candidate entities with their CR numbers. That number matters. It anchors the rest of the lookup.

Once known, retrieving the company profile becomes straightforward.

get_company_profile({
  "jurisdiction_code": "HK",
  "company_number": "1234567"
})

Officer information sits behind another call.

get_officers({
  "jurisdiction_code": "HK",
  "company_number": "1234567"
})

Then the filing history.

list_filings({
  "jurisdiction_code": "HK",
  "company_number": "1234567"
})

This sequence mirrors how a human analyst uses the registry site. Search for the name. Confirm the CR number. Then read the filings to understand how the entity changed over time.

Why finance teams pay attention to these fields

Hong Kong companies show up constantly inside acquisition structures and bond vehicles. A Cayman parent might sit above a Hong Kong intermediate holding company that signs operating contracts. The registry record confirms which entity occupies that layer.

The CR No. becomes the stable reference. Analysts drop it into diligence notes. Audit trails rely on it. Internal compliance systems often store it as the primary identifier.

Director listings help answer a different question: who actually holds board authority. If the filings show an ND2A, a director appointment or resignation probably occurred recently. That change may affect signing authority on financing documents.

Annual returns provide another signal. Each company must submit the NAR1 on a fixed cycle after incorporation. Miss the filing window and the absence becomes visible during diligence reviews. Lenders tend to notice.

Engineers building KYB pipelines run into a separate issue. The legacy paid databases often serve cached company records. Updates can lag behind the official filing register. A recent director resignation may take time to propagate.

Querying the register of record removes that lag. The response reflects the latest filing accepted by the Companies Registry.

Hong Kong remains a common node in Asia‑Pacific corporate structures. Direct access to the registry makes those structures easier to verify during underwriting, counterparty checks, or acquisition screening.

The MCP endpoint for the registry sits at https://openregistry.sophymarine.com/mcp.

Mexico’s PSM registry: what corporate filings actually expose

OpenRegistry — Mon, 08 Jun 2026 15:01:31 +0000

Mexico requires many corporate notices to appear in Publicaciones de Sociedades Mercantiles (PSM), an online publication system run by the Secretaría de Economía. The portal functions as the federal publication layer for companies recorded in the Registro Público de Comercio (RPC). When reviewing a Mexican company, this feed often surfaces structural changes before secondary datasets reflect them.

The requirement comes from legal procedure rather than software design. The General Law of Commercial Companies (Ley General de Sociedades Mercantiles) obliges commercial entities to publish certain shareholder resolutions, capital adjustments, merger notices, and liquidation announcements. PSM is the channel used for those disclosures. Once a notice is posted there, courts treat it as constructive notice. Several European jurisdictions follow a similar model through statutory gazettes.

Registry responses stay close to the underlying filing. The service does not reinterpret the submission or translate it into a simplified schema. What appears in the response is usually what the filing party sent.

A typical company profile query returns fields such as:

• denominacion_social — the legal name recorded in the filing

• folio_mercantil — the electronic identifier for the commercial registry entry

• fecha_constitucion — the incorporation date held by the RPC

• entidad_registro — the Mexican state responsible for that registry record

• estatus — filing status, often active or liquidation

Publication entries carry their own metadata. Each notice usually contains fields inside a jurisdiction_data block. Examples include tipo_publicacion, fecha_publicacion, and acto_reportado, along with references to the shareholder or board resolution behind the disclosure. When mergers or capital increases appear, the narrative text normally sits exactly as submitted.

That text matters. The legal substance often lives in the body of the notice rather than the structured fields, which complicates automated processing.

The registry does not maintain structured tables for officers or shareholders. A publication might describe the appointment of an administrador único or record a board change. The names sit inside the document text. No separate dataset holds them. Anyone trying to extract officer data has to parse the filing itself.

Some omissions are deliberate.

Mexico introduced a beneficial ownership reporting regime in 2022 through amendments to the Federal Fiscal Code (Código Fiscal de la Federación, article 32‑B Ter). Companies must keep records identifying their beneficiario controlador and provide that information to the tax authority, the Servicio de Administración Tributaria (SAT), when requested. This material is not public. It does not appear in the PSM publication stream and cannot be retrieved through the commercial registry interface.

For AML or sanctions analysis, that gap matters. The public registry layer signals structural events but rarely identifies the natural persons behind them. Ownership tracing still requires work outside the registry.

Mexico’s federal structure adds another wrinkle. The Registro Público de Comercio operates through state registries, each maintaining the underlying company records. PSM acts as the national publication platform that references those filings. In practice the folio mercantil identifier points back to a state RPC entry even though the notice itself appears in a central portal.

Programmatic access through OpenRegistry follows the same approach used for other jurisdictions.

Searching by company name might look like this:

search_companies({ "jurisdiction": "MX", "query": "GRUPO BIMBO" })

The result set returns candidate entities with a company_number mapped to the folio mercantil. That number feeds into the company profile call:

get_company_profile({ "jurisdiction": "MX", "company_number": "<folio_mercantil>" })

If publication notices exist, they can be listed directly.

list_filings({ "jurisdiction": "MX", "company_number": "<folio_mercantil>" })

Each item corresponds to a PSM publication event. The jurisdiction_data block keeps the fields returned by the Secretaría de Economía endpoint. When the upstream service includes a document reference, the source file can be retrieved with fetch_document.

Anyone familiar with the legacy paid databases usually notices the difference quickly. These responses come from the upstream registry service. OpenRegistry does not rewrite the schema or infer ownership links. Identifiers, timestamps, and filing metadata match the government endpoint.

That distinction matters in evidence‑driven work. Preparing a diligence memo or assessing sanctions exposure often turns into a question about legal weight. In Mexico the publication notice itself can function as the operative disclosure under the Ley General de Sociedades Mercantiles. A summarised dataset from a commercial provider may not carry the same evidentiary standing.

Compliance engineers often use the feed for event monitoring. Capital increases, mergers, and liquidation steps tend to appear in PSM before downstream datasets refresh. Pulling those notices into an internal monitoring pipeline can reveal structural changes early.

OpenRegistry exposes these registry endpoints through MCP and returns the raw PSM records issued by the Secretaría de Economía. Connection details and documentation sit at https://openregistry.sophymarine.com.

Taiwan's GCIS company registry — what queries actually return

OpenRegistry — Sun, 07 Jun 2026 15:01:42 +0000

Every Taiwanese company receives an eight‑digit Unified Business Number. Local reporters shorten it to UBN. Inside the Ministry of Economic Affairs’ GCIS system, most of the corporate trail attaches to that number.

Anyone used to UK or Panama filings spots the contrast fast. GCIS grew out of a domestic administrative system and it shows. Field labels follow ministry terminology. Some entries appear only in Mandarin even when the company trades overseas. Tracing supply chains often begins with a dull routine: copy a UBN, paste it into another government portal, confirm the same company again.

OpenRegistry exposes GCIS through MCP. An assistant can query the register directly. The reply preserves the original registry structure under jurisdiction_data. That detail matters during verification work. Aggregated datasets sometimes reshape fields or smooth awkward translations. Here you see the ministry’s wording exactly as stored.

A typical GCIS company profile carries several fields reporters return to again and again.

Business_Accounting_NO is the UBN itself. Eight digits. This number links tax records, customs registrations, and procurement disclosures across Taiwan’s public datasets. Once the company identity is confirmed, investigators usually pivot through this identifier rather than the name.

Company_Name stores the legal Chinese name. Some profiles also include Company_Name_English, though the register does not require it. Export‑focused manufacturers often circulate several Romanised spellings in trade catalogues or distributor listings. The Chinese legal name stays consistent, so matching records usually starts there.

Responsible_Person_Name identifies the legal representative. Taiwan’s company law concentrates responsibility in this role rather than publishing a detailed board structure. Patterns appear quickly. The same responsible person turning up across several entities can point to a family business group, or occasionally a nominee acting on behalf of others.

Capital_Stock_Amount records the registered capital. The figure can look oddly small beside revenue estimates reported elsewhere. Taiwanese firms often keep statutory capital low while financing operations through affiliated entities. That structure shows up regularly in manufacturing groups.

Company_Location lists the registered address. Industrial districts around Taichung, Hsinchu, and New Taipei appear repeatedly when mapping electronics suppliers. Sometimes dozens of exporters share the same building. Not unusual.

Company_Status indicates whether the entity is active, dissolved, or suspended. GCIS updates tend to appear quickly because the information flows straight from Ministry of Economic Affairs filings rather than a secondary database.

The raw payload may also contain approval dates and business scope descriptions written entirely in Chinese. OpenRegistry passes these fields through untouched within jurisdiction_data. For fact‑checking, that matters. When editors want the exact phrasing from the government system, the raw text avoids translation drift.

Some details investigators expect simply are not public. Taiwan does not operate an open beneficial ownership register. Shareholder disclosure varies by company type and often stops at corporate entities rather than natural persons. Finding the individual behind a shareholder normally means checking separate filings or court material. That gap becomes relevant in sanctions work or cross‑border asset tracing.

Language adds another constraint. GCIS responses frequently contain Mandarin strings even if the search query used Latin characters. Any workflow that processes the registry needs proper UTF‑8 handling. Systems expecting English field values can treat perfectly valid responses as incomplete.

A basic search through OpenRegistry looks like this:

search_companies

{
"jurisdiction": "TW",
"query": "TSMC"
}

This call queries the GCIS name index. Results usually return the Chinese legal name together with the UBN. That number becomes the next step.

get_company_profile

{
"jurisdiction": "TW",
"company_number": "22099131"
}

The response includes structured fields plus the untouched GCIS payload inside jurisdiction_data. From there an assistant can call other tools where the registry exposes additional endpoints. An officer lookup, for instance:

get_officers

{
"jurisdiction": "TW",
"company_number": "22099131"
}

Coverage follows the upstream registry. If GCIS does not publish a document or shareholder list, the MCP layer does not invent one.

For newsroom work the practical gain is reproducibility. Another reporter can run the same query and retrieve the same fields because the request hits the live GCIS service rather than a mirrored dataset. Editors tend to ask where a fact came from. Showing the registry response answers that question quickly.

Cross‑border reporting is where this approach earns its keep. Taiwanese companies appear throughout semiconductor supply chains and export‑control investigations. They also surface inside networks linked to mainland manufacturing groups. When a Hong Kong trading firm references a Taiwanese subsidiary, a GCIS lookup often confirms the responsible person and the registered address within seconds.

The same MCP interface reaches other jurisdictions too. A workflow that begins with Taiwan can pivot to Hong Kong, the UK, or the Cayman Islands without rewriting the query layer. Reporters mapping corporate links across borders usually care about that consistency.

The public MCP endpoint for OpenRegistry sits at https://openregistry.sophymarine.com/mcp if you want to run GCIS queries yourself and inspect the registry payload.

South Korea’s OpenDART: what filings show during diligence

OpenRegistry — Sat, 06 Jun 2026 15:01:22 +0000

South Korea’s OpenDART assigns every reporting company an eight‑digit corp_code. Each disclosure sent to the Financial Supervisory Service carries that number. In diligence work, the identifier usually proves steadier than the company name.

OpenDART is not the incorporation register. The formal legal record sits with the Korean Supreme Court’s corporate registry. OpenDART instead publishes regulatory filings submitted to the Financial Supervisory Service (FSS). Listed issuers appear there, along with a large set of sizeable private firms. For deal teams, those filings often contain the information that actually matters.

Speed is the main difference. When an issuer submits a material report, OpenDART tends to publish it within minutes. Director changes surface quickly. So do capital adjustments or shareholder disclosures. Secondary databases may still show the old picture while negotiations are already under way.

A handful of fields recur in the raw payload returned by OpenDART:

corp_code: the stable identifier used across filings
corp_name: the entity name recorded with the FSS
stock_code: the exchange ticker for listed companies
ceo_nm: the chief executive named in disclosures
adres: the address reported in filings

The response also carries filing metadata inside a jurisdiction_data object. Two fields usually matter first when locating the source document. rcept_no is the receipt number assigned when the filing lands with the regulator. report_nm holds the filing title. Those two together point straight to the report.

Annual reports show why that matters. One filing commonly bundles several disclosures: major shareholders, board composition, related‑party dealings, and changes to share capital. The shareholder section is the part diligence teams read first. Korean reporting rules require disclosure once holdings cross certain thresholds, often 5 percent for public issuers. Strategic investors show up there. So do affiliated entities within large corporate groups. Many lighter datasets omit them.

Still, OpenDART is not a beneficial ownership register. South Korea does not publish an open database comparable to the UK’s PSC register. Filings identify declared large shareholders and certain related parties. They rarely trace the full ownership chain behind nominee structures. Anyone analysing control will still want extracts from the corporate registry. Local counsel sometimes fills the gaps.

Language adds friction. A large share of reports appear mainly in Korean. Bigger issuers sometimes attach English summaries. Annexes and supporting documents remain Korean in most cases. Systems that ingest these filings must handle mixed encodings and bulky attachments. Some submissions run past 50 MB once scanned appendices are included.

Corporate structure complicates things further. Many Korean business groups operate through dense affiliate webs shaped by the chaebol system. Filings refer to related entities in narrative sections buried deep inside the document. Metadata alone rarely captures those links. The connections sit in the text.

Querying through OpenRegistry keeps the plumbing simple. The MCP server returns the upstream fields largely unchanged.

Searching by company name:

search_companies({
  "jurisdiction": "KR",
  "query": "Samsung Electronics"
})

The results include candidate entities plus their corp_code. With that number in hand, request the company profile.

get_company_profile({
  "jurisdiction": "KR",
  "company_number": "00126380"
})

The profile response returns the core entity record and a jurisdiction_data block. Inside it sit OpenDART fields such as corp_name, stock_code, ceo_nm, and est_dt.

Next comes the filing stream.

list_filings({
  "jurisdiction": "KR",
  "company_number": "00126380"
})

Each entry contains the filing title (report_nm) and the submission receipt (rcept_no). When a relevant report appears, fetch the underlying document.

fetch_document({
  "jurisdiction": "KR",
  "filing_number": "20240516001234"
})

The value becomes obvious during live diligence. In one cross‑border supplier review last year, a subscription database still listed the founder as the largest shareholder. OpenDART showed something else entirely. A filing lodged three weeks earlier disclosed that a private equity vehicle had crossed the 5 percent reporting threshold through a block trade. The fund already held stakes in two competitors. That detail altered the conflict analysis immediately.

The gap came from crawl lag. Aggregators ingest filings on their own schedules. OpenDART publishes them when the regulator receives the submission. Sometimes the delay is small. Sometimes it stretches into weeks.

Deal teams watch those filings for early signals. Director appointments appear there first. Treasury share transactions too. Capital increases often show up in OpenDART days before any secondary database reflects the change.

OpenRegistry exposes the OpenDART interface through MCP so an AI assistant can run these queries inside a workflow. The server connects to 27 national registries, including Korea, the UK, Germany, the Netherlands, and Hong Kong. Documentation and entry point: https://openregistry.sophymarine.com.

Czech ARES registry: what the official data actually returns

OpenRegistry — Fri, 05 Jun 2026 15:02:15 +0000

Eight digits identify almost every Czech company you will encounter in a registry search. The number is the IČO. It is assigned at incorporation and almost never changes during the entity’s lifetime. Many KYB systems treat it as the primary lookup key.

The public index built around that identifier is ARES, the Administrative Register of Economic Subjects. ARES links IČO numbers to several state datasets and exposes them through a government API.

The incorporation authority sits elsewhere. The legally binding record lives in the Czech Commercial Register maintained by regional courts. ARES republishes information drawn from that system together with a handful of other government sources. In practice it behaves less like a single register and more like an access point that routes queries across several state databases.

OpenRegistry MCP exposes those upstream ARES fields directly for the Czech jurisdiction. The response carries the OpenRegistry schema plus the raw jurisdiction_data object returned by the government service. No field rewriting. No reshaping of names.

Typical company profile responses include fields such as:

ico – the eight‑digit company identifier
obchodniJmeno – the registered company name
pravniForma – the legal form, for example "společnost s ručením omezeným" (s.r.o.)
sidlo – the registered address
datumVzniku – incorporation date
stavSubjektu – the entity’s current status

The interesting pieces often sit deeper in the payload. Inside jurisdiction_data you usually find attributes that KYB pipelines rely on but aggregators sometimes flatten or drop. Two examples appear frequently: spisovaZnacka, the court file reference, and soud, the court responsible for the record. Activity classifications show up under cz_nace.

Those details carry weight during compliance checks. Sector restrictions are often tied to NACE codes. Auditors also ask for the exact court reference pointing back to the Commercial Register entry.

ARES structures addresses as components rather than a single formatted line. Municipality identifiers appear. Postal codes appear too. District references from the Czech Statistical Office are also present. Keeping those elements intact helps when screening datasets spell a place slightly differently. Matching improves when each part of the address can be compared separately.

What ARES does not give you

ARES does not publish beneficial ownership data. Czech UBO records sit in a different system called “Evidence skutečných majitelů”. Access tightened after the CJEU C‑601/20 ruling, which limited public visibility for many European ownership registers. Querying ARES alone will not reconstruct an ownership chain.

Corporate filings form another gap. Court documents appear through the Justice.cz platform rather than through the ARES API. ARES might show the court file number tied to the company record. The documents themselves remain outside the interface. Articles of association. Annual accounts. Similar filings stay in the court system.

That split affects automation. A KYB workflow can confirm incorporation status and legal form through ARES with little friction. Document review still requires a second lookup against the court platform.

Some of the legacy paid databases maintain their own document copies. Convenient, yes. There is a trade‑off. Cached material becomes harder to date precisely, and regulators increasingly ask where a document originally came from during an audit.

Querying ARES through OpenRegistry MCP

OpenRegistry sends queries to the Czech registry of record and returns the payload without reinterpretation. MCP allows an AI client to call the registry as a tool instead of scraping a web page.

A simple name search might look like this:

search_companies({
  "jurisdiction": "CZ",
  "query": "rohlik"
})

The response returns candidate entities together with their ico numbers. Once the correct one is identified, the system can request the full record.

get_company_profile({
  "jurisdiction": "CZ",
  "company_number": "24790221"
})

The reply contains both the normalised OpenRegistry fields and the untouched ARES payload under jurisdiction_data. That distinction matters during audits. Investigators can point to the exact upstream values rather than a transformed dataset produced downstream.

Officer information may appear as well when the upstream register publishes it. For Czech companies those details usually originate from the Commercial Register entry referenced by the spisovaZnacka file number. The follow‑up request is straightforward:

get_officers({
  "jurisdiction": "CZ",
  "company_number": "24790221"
})

Field names remain aligned with the registry source. Logs reflect the official wording used by the court register. That makes later verification simpler.

Practical implications for KYB pipelines

ARES works well for the baseline checks most onboarding systems perform. You can confirm that a Czech entity exists. You can see its incorporation date. You can identify the court responsible for the official record.

Ownership verification takes a different route because the beneficial ownership register cannot be queried in the same open manner. Teams often combine ARES verification with documents provided by the customer. The resulting ownership chain supports sanctions screening under rules such as the OFAC 50 percent rule or similar UK and EU frameworks.

Name matching needs a small adjustment. Czech companies often include legal form abbreviations such as “s.r.o.” or “a.s.” inside the registered name. ARES stores them directly in the obchodniJmeno field. Search logic should account for that. If the application omits the legal form, a simple equality check may fail.

Direct registry queries also help months later when a decision is reviewed. The auditor can repeat the lookup using the same IČO. Same identifier, same record.

OpenRegistry exposes the Czech ARES register through MCP alongside 27 national company registries. Teams building onboarding or investigation tooling can query the registry of record directly at https://openregistry.sophymarine.com.