DEV Community: OpenRegistry

Reading Belgium's KBO/CBE registry: what the live API returns

OpenRegistry — Sun, 31 May 2026 15:02:17 +0000

Belgium's Crossroads Bank for Enterprises registers exactly ten digits for every active corporate entity. It formats these as a leading zero followed by nine numbers. This is the enterprise number. Every compliance check on a Belgian vendor must resolve to this unique key. Relying on legacy paid databases is risky because their records are frequently months out of date. We need live data from the official KBO/CBE registry of record to satisfy our auditors.

The raw registry data returned through the OpenRegistry MCP server preserves the exact structure of the Belgian public search. A profile fetch returns the active legal status. This is typically marked as a normal situation or actief in Dutch. It lists the legal form, which will be an SRL or an SA for most merchants. You also get the registered address alongside the NACEBEL industry activity codes. NACEBEL codes are Belgium's specific extension of the European NACE system. Compliance engines can parse these codes directly. This categorisation helps flag businesses operating in high-risk sectors.

The Belgian Ultimate Beneficial Owner registry is managed separately by the Federal Public Service Finance. Accessing this register is no longer straightforward. Following the CJEU ruling in cases C-37/20 and C-601/20 on 22 November 2022, public access was shut down [1]. Belgium codified this restriction via the Royal Decree of 8 February 2023. Now, you must prove a legitimate AML interest to query their UBO database. No open MCP tool can bypass this legal lock. We must design our onboarding workflows around this limitation. Our systems retrieve the public KBO record automatically to verify entity status. We then request signed ownership certificates directly from the corporate officers during onboarding.

Querying the Belgian registry using the OpenRegistry MCP server is highly efficient for developers. You call the server with the standard tools. For basic company lookups, use the company number as the key. This number is universally formatted across Belgian business registries. Here is how a standard tool call is constructed when requesting a profile from the live database:

{
  "name": "get_company_profile",
  "arguments": {
    "jurisdiction": "BE",
    "company_number": "0860136460"
  }
}

You can also query the names of registered directors and legal representatives. The KBO lists these individuals with their appointment dates. Use the get_officers tool on the same enterprise number. The response provides the names of individuals who hold signing authority for the company. This is critical for corporate resolution audits. Here is the schema for the directory query:

{
  "name": "get_officers",
  "arguments": {
    "jurisdiction": "BE",
    "company_number": "0860136460"
  }
}

Our compliance audits require a verifiable link back to the registry of record. We do not use aggregated credit risk reports for identity verification. Regulators expect to see the raw data retrieved directly from KBO/CBE on the exact day of onboarding. Every single lookup is logged with its timestamp. If a merchant is later found to be operating in an unapproved sector, we have the original NACEBEL codes on file. This proof protects our business during annual financial audits.

Belgian companies often register different name variants in multiple languages. This includes official French and Dutch translations. The KBO stores all of these official translations. A company might register as a Société de Responsabilité Limitée in Wallonia but use Besloten Vennootschap in Flanders. Our systems must capture both name variants to prevent duplicate records in our database. The MCP server returns these multilingual names in the raw profile response. We match them against the merchant's bank account details to reduce false positive alerts.

The profile response also includes direct links to Moniteur Belge publications. The Moniteur Belge is the official state gazette where Belgian companies publish corporate changes. If we see a mismatch in our automated directors check, our compliance analyst can click the gazette link. This allows them to manually review the scanned PDF of the original deed. This hybrid flow saves hours of research time. It combines automated retrieval with direct access to official sources.

For KYC engineers looking to integrate live Belgian registry data into their tool chains, the OpenRegistry server provides a reliable route. You can begin querying the KBO/CBE registry and sibling European databases by visiting the documentation at openregistry.sophymarine.com. The anonymous tier allows you to test queries without an upfront signin. This is the fastest way to verify if your compliance systems can handle raw Belgian corporate records.

Analysing Zefix data: tracking Swiss entities via raw registry access

OpenRegistry — Sat, 30 May 2026 15:01:47 +0000

Switzerland's Federal Office of Justice manages Zefix. This is the central company index pointing to twenty-eight distinct cantonal registries. Each Swiss enterprise receives a twelve-character Corporate Identification Number (UID) styled as CHE-123.456.789. This system became mandatory in 2011 to replace fragmented regional numbers. For M&A analysts, mapping these entities means navigating a system that sits completely outside the European Union's regulatory framework.

Because Switzerland is not an EU member state, its corporate data does not flow through standard European Business Register channels. Financial analysts tracking cross-border subsidiaries often hit stale aggregator caches that fail to capture sudden changes in signatory powers or insolvency proceedings [1]. This lag represents a significant risk during high-value debt restructuring or diligence cycles.

The Swiss cantonal split

The central Zefix index collects high-level metadata, but the legal reality of a Swiss corporation lives at the cantonal level. When you query a Swiss business, the primary record resides with regional registries like Zurich, Geneva, or Zug. Zug is particularly critical for commodity trading firms and investment vehicles due to its historical tax advantages.

A raw data pull from a Swiss entity contains several specific identifiers. The payload includes the UID, the older cantonal registration number, the legal form, and the registered address. The legal form field distinguishes between an Aktiengesellschaft (AG) and a Gesellschaft mit beschränkter Haftung (GmbH). It also includes the active corporate purpose and the current status of the firm.

Unlike some European neighbours, Switzerland does not maintain a public central register of beneficial owners. The Federal Council continues to debate a centralised transparency register, but beneficial ownership data remains mostly private. This leaves corporate officers with joint or individual signatory authority as the primary indicators of control. These signatory authorities are recorded in the cantonal commercial register, making officer data queries essential for corporate compliance checks.

Current integration status

In the OpenRegistry architecture, the direct Swiss registry integration is currently inactive. The /healthz matrix confirms that direct Zefix lookups via the code CH are offline. This occurs because Swiss cantonal endpoints update their security schemas and query interfaces independently, which requires periodic maintenance on programmatic connectors.

For finance professionals mapping international entities, this does not stop corporate tracing. Active neighbouring registries on the OpenRegistry platform, such as Germany, France, Italy, and Liechtenstein, provide clear audit trails for Swiss corporate networks. Many Swiss parent companies operate through French or German subsidiaries. These foreign entities must file public records of their parent holdings and branch offices in their local corporate registers.

Querying the active German registry often reveals the precise Swiss holding structure through foreign entity disclosures. For example, a search for a German subsidiary reveals the parent's CHE identification number and cantonal seat.

Querying Swiss-linked entities through active sibling registries

To perform an asset-tracing or compliance query, developers use the active tool suite to scan neighbouring European jurisdictions. Here is an example of querying a German branch of a Swiss entity using the OpenRegistry MCP server:

{
  "name": "search_companies",
  "arguments": {
    "jurisdiction": "DE",
    "query": "Swiss Holding GmbH"
  }
}

When the target profile is retrieved, you request the full officer list to verify who holds signing authority over the European operations:

{
  "name": "get_officers",
  "arguments": {
    "jurisdiction": "DE",
    "company_id": "DE_HRB_123456"
  }
}

This returns the unmodified data fields exactly as they exist in the German registry database. The response lists the managing directors, their residency details, and any Swiss parent entities registered as sole shareholders. Once Swiss direct access is reactivated in a future release, identical tool calls targeting the CH jurisdiction code will pull the raw records directly from the Zefix index.

Why raw data beats caches

Relying on the legacy paid databases for Swiss corporate data introduces compliance risks. Private aggregators scrape cantonal registers at long intervals, often missing temporary corporate suspensions or sudden changes in signatory powers. During an M&A transaction, a single day of lag in discovering a bankruptcy filing can invalidate a contract.

Using direct registry calls ensures your analysis rests on the official record of the jurisdiction. For developers building KYC tools or automated compliance pipelines, accessing raw, real-time corporate registries across European borders provides a reliable foundation. You can monitor the current live status of the Swiss integration and browse sibling registries on openregistry.sophymarine.com.

Finland's YTJ Registry — what the official API actually returns

OpenRegistry — Wed, 27 May 2026 15:00:35 +0000

Finland's Patentti- ja rekisterihallitus (PRH) operates a dual-layer registration architecture that directly affects corporate diligence and KYC integrations. The Finnish Business Information System (YTJ) serves as the main portal. The data retrieved programmatically depends on whether you hit the public trade register or the AML-gated beneficial ownership database. Understanding this boundary is critical for compliance teams designing automated client onboarding workflows.

PRH maintains a relatively accessible digital infrastructure. However, the legal boundaries of what can be queried without an authenticated, legitimate interest under the EU Anti-Money Laundering Directives (AMLD) remain strict.

Structure of the Finnish YTJ payload

When querying a Finnish entity via the OpenRegistry MCP server, you interface with the public YTJ database. This registry indexes limited liability companies (Osakeyhtiö, or Oy), partnerships, and sole traders.

A successful query to the Finnish registry returns a structured payload where the raw jurisdiction_data block preserves the upstream Finnish and Swedish field names. Key fields you will parse from a standard profile lookup include:

businessId (Y-tunnus): The standard Finnish nine-character format (e.g., 1234567-8). This is the primary key for all entity matching.
name: The current registered legal name of the entity.
companyForm: The legal structure, typically returned as Code OY for standard limited companies.
registrationDate: The date of incorporation.
liquidations: An array containing insolvency, liquidation, or bankruptcy proceedings, which serves as a primary flag for credit and legal risk.
addresses: Historical and current postal and street addresses registered with the PRH.

The raw payload exposes the registeredOffices and postalAddresses arrays. YTJ tracks the exact source of each address field—whether it originates from the Tax Administration (Verohallinto) or the PRH itself. This distinction is vital for service-of-process validation, as only the PRH-registered address carries statutory weight for constructive notice.

Statutory boundaries of Finnish beneficial ownership data

Finland transposed the Fifth Anti-Money Laundering Directive (5AMLD) by requiring Finnish companies to file beneficial ownership details (Edunsaajatiedot) directly with the PRH. Following the Court of Justice of the European Union (CJEU) ruling in joined cases C-37/20 and C-601/20, public access to these registers was constrained.

In Finland, beneficial ownership information is not public record. Under the Finnish Act on Preventing Money Laundering and Terrorist Financing (444/2017), access to the UBO register is restricted to financial institutions, legal professionals under AML obligations, and those who can prove a specific legal interest.

Consequently, standard programmatic tool calls targeting the PRH via an unauthenticated gateway will not return the get_persons_with_significant_control dataset. To build an ownership chain, compliance developers must use the public officer registry to map the board of directors (Hallitus) and then run secondary verifications. The board members are publicly listed and accessible, providing a starting point for identifying the natural persons exercising control over the legal entity.

Querying Finland via OpenRegistry MCP

To fetch a Finnish company profile using the OpenRegistry MCP server, your AI agent or compliance tool issues a direct query using the ISO country code FI. There is no need to pre-parse or clean the inputs.

Here is how to structure the search tool call inside an agentic workflow:

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

Once you obtain the correct Y-tunnus (business ID) from the search results, you can retrieve the full profile, including historical addresses, active trade names, and registration status, using the profile tool:

{
  "name": "get_company_profile",
  "arguments": {
    "jurisdiction": "FI",
    "registration_number": "0111691-0"
  }
}

The returned payload contains the unified OpenRegistry schema fields along with the raw jurisdiction_data block. This allows your downstream parsers to inspect the exact Finnish taxonomic labels if your compliance logic requires matching local registration codes.

Designing resilient compliance flows

For engineers building automated KYB and M&A diligence platforms, relying on stale database dumps is a regulatory liability. The legacy paid databases often serve outdated information. The Finnish trade register changes daily as entities update their representation rights, register auxiliary trade names (Aputoiminimi), or file for restructuring.

By leveraging the OpenRegistry MCP server, your systems query the live PRH database at the moment of onboarding. This setup eliminates the discrepancy between cached aggregator data and the official register of record. Because the anonymous tier requires no API key or complex OAuth setup, you can deploy and test this live integration within minutes. For high-volume production compliance pipelines, the paid tiers increase the rate limits and support concurrent queries across multiple European jurisdictions.

To integrate live Finnish registry checks directly into your tooling, visit the server documentation at openregistry.sophymarine.com.

Trace Norwegian shell companies directly via Brønnøysundregistrene API

OpenRegistry — Tue, 26 May 2026 15:00:52 +0000

Norway issues every legal entity a nine-digit organisation number starting with 8 or 9. The agency in charge is Brønnøysundregistrene, located in the Arctic Circle town of Brønnøysund. Unlike the opaque registries of the English Channel or the Caribbean, Norway publishes this data under an open licence. Pulling it programmatically without getting lost in nested XML arrays or state-run endpoint quirks requires knowing exactly where the boundaries of public data lie.

When tracing assets or verifying a corporate entity in Norway, you deal with two overlapping databases. The first is Enhetsregisteret, the Central Coordinating Register for Legal Entities, which registers every organisation from an AS (limited company) to a local chess club. The second is Foretaksregisteret, the Register of Business Enterprises, which records liability, capital, and signatories for commercial entities.

Through OpenRegistry's MCP server, querying these registers bypasses the stale aggregator caches of legacy paid databases. The raw upstream fields are preserved inside the jurisdiction_data block, giving you the direct statutory truth.

When you call get_company_profile for a Norwegian entity, the response exposes critical forensic fields straight from Brønnøysundregistrene. Look at the jurisdiction_data payload. You will find:

registreringsdatoForetaksregisteret: The date the entity became a commercial enterprise.
konkursdato: The date bankruptcy proceedings were initiated, if applicable.
vedtektsfestetFormaal: The formal statutory purpose of the company as defined in its articles of association.
organisasjonsform: The legal structure, such as "AS" (Aksjeselskap) or "NUF" (Norwegian branch of a foreign company).

Norway has a specific corporate form called the NUF (Norskregistrert utenlandsk foretak). This is a Norwegian branch of a foreign enterprise, which is a common structure used by offshore entities to operate in the North Sea oil sector. When querying a NUF via get_company_profile, the jurisdiction_data block contains the field registreringsnummerIHjemland (registration number in the home country). This single field allows investigators to link the Norwegian branch directly back to its origin jurisdiction, whether that is Delaware, the United Kingdom, or Cyprus.

Unlike jurisdictions that hide historic officer changes behind paywalls, Norway's register makes board compositions accessible. When you execute the get_officers tool, you receive structural roles mapped directly to their actual titles: styretsleder (board chair), daglig leder (general manager), and revisor (auditor).

Norway is transparent, but it is not entirely open. You must navigate three distinct legal and technical boundaries.

First, national identity numbers are strictly redacted from public APIs. You can see names and birth years of directors, but never the full unique personal identifier unless you have a statutory right to log in via domestic authentication systems. Second, beneficial ownership tracking has changed. Following the Court of Justice of the European Union (CJEU) ruling on UBO registers, public access to the Register of Beneficial Owners (Registeret for reelle rettighetshavere) has become restricted. While OpenRegistry can retrieve public officer lists via get_officers, the deep AML-gated beneficial owner registers require specific legal credentials. Third, physical copies of filings must be ordered via the registry's webshop for a fee. The raw API endpoints provide metadata and filing dates, but not the physical PDFs of vintage filings.

To trace a suspected Norwegian holding structure, you begin with a search. The search_companies tool accepts either the nine-digit organisation number or a name string:

{
  "name": "search_companies",
  "arguments": {
    "jurisdiction": "NO",
    "query": "Equinor"
  }
}

Once you have the precise organisation number, you can query the full profile. The get_company_profile tool retrieves the active registration details:

{
  "name": "get_company_profile",
  "arguments": {
    "jurisdiction": "NO",
    "registration_number": "923609016"
  }
}

To reconstruct the corporate hierarchy and identify who is signing off on transactions, you pull the officer registry. This list maps out the executive and non-executive board:

{
  "name": "get_officers",
  "arguments": {
    "jurisdiction": "NO",
    "registration_number": "923609016"
  }
}

While the raw PDFs of annual accounts (årsregnskap) are stored in a separate registry, you can still trace the list of filings using list_filings. This tool returns the date and type of each submission, allowing you to see when the company last updated its articles or changed its auditor. A sudden change of an auditor (revisor) or a prolonged delay in submitting the accounts is a classic warning sign.

This direct access changes how cross-border investigations are structured. Instead of waiting for third-party compliance platforms to normalise and upload data weeks after a filing occurs, you can trigger these tools directly inside your terminal or investigative assistant. If a corporate shell points to a Norwegian AS, you can confirm its active status and current board members in less than three seconds. To test these queries without credentials or configuration delays, query the endpoint directly at openregistry.sophymarine.com.

Mapping Polish company structures: querying KRS direct via API

OpenRegistry — Mon, 25 May 2026 15:00:36 +0000

Cross-border subsidiary tracing on a Polish logistics target highlighted the systemic delay built into global corporate data aggregators. The legacy paid databases listed the Warsaw parent company as active but showed zero ownership modifications for over eighteen months. In reality, the Krajowy Rejestr Sądowy (KRS) had recorded a significant capital increase and registered a pledge on outstanding shares in mid-March. Relying on cached aggregator datasets almost mispriced our M&A diligence window because we missed the newly introduced collateral.

Poland’s KRS operates on a strict, transactional legal basis. Unlike jurisdictions where updates filter through slowly, Polish corporate events are only legally binding once they are entered into the court register. Relying on scraped data dumps is a substantial risk during pre-acquisition checks. Using a direct, live link to the KRS is the only way to avoid acting on stale disclosures.

KRS API Data Models

When you pull a profile using the Krajowy Rejestr Sądowy, the JSON structure reflects the precise legal anatomy of Polish entities. The raw jurisdiction_data block is divided into explicit sections reflecting the official court record. The standard registry payload exposes several critical details:

NIP and REGON identifiers: These are the national tax identification and statistical numbers. Polish entities cannot operate without them, and they serve as absolute anchors for cross-checking tax history.
Capital structure details: The registry outputs exact nominal values, including wysokoscKapitaluZakladowego (the share capital amount) and its currency. It also tracks the total number of issued shares.
The division registry type: Polish entities fall under either Register "P" (przedsiębiorcy for commercial businesses) or Register "S" (stowarzyszenia for associations, foundations, and public health entities).
Direct and proxy representation: The reprezentacja section lists the board members alongside their official roles and their specific representation rules (sposob_reprezentacji), which dictate exactly who must sign to bind the company.
Historical court identifiers: The wydzial fields indicate which district court holds the physical files. This is invaluable if you need to dispatch a local agent to retrieve paper records.

Polish Registry Boundaries

While the commercial registry is highly transparent about board members and historical company changes, it does not function as an all-encompassing compliance database. Poland has strict operational boundaries:

UBO Gating: Ultimate Beneficial Owner (UBO) information is housed in the Centralny Rejestr Beneficjentów Rzeczywistych (CRBR). Following the CJEU C-601/20 ruling on privacy, this data is kept separate from the open-access KRS company profile APIs. You will not find direct beneficial ownership charts embedded within the standard company profile.
Financial Filings PDFs: While the registry tracks whether financial statements have been submitted, the raw XML or PDF copies of these statements reside in the separate Repozytorium Dokumentów Finansowych (RDF). The commercial registry provides metadata about the filing, but accessing the documents themselves requires target-specific paths.
Sanctions list status: The KRS does not offer domestic sanctions checks. You will need to query the Ministry of Interior and Administration (MSWiA) list separately to screen for designated entities.

Querying KRS Programmatically Using MCP

To bypass stale aggregator tables, you can issue real-time tool calls directly to the court register. This raw, live access runs without intermediate caching, delivering the exact records held by the Ministry of Justice.

To locate a Polish target, run a localized search command using the official identifier format:

{
  "name": "search_companies",
  "arguments": {
    "q": "Zabka Polska",
    "jurisdiction": "PL"
  }
}

Once you have the ten-digit KRS number, you can query the direct court file. This step extracts the active administrative structure, board of directors, and official legal address:

{
  "name": "get_company_profile",
  "arguments": {
    "company_id": "0000414000",
    "jurisdiction": "PL"
  }
}

This tool call hits Poland's live court register database. The response returns the original nested Polish registry attributes inside the jurisdiction_data key, giving your automated agents the raw, unparsed material required to verify signing authorities and actual share values.

Corporate Status Verification

In-house corporate development demands direct-from-source precision. When constructing a cross-border corporate structure, discovering a silent partner or an undisclosed court-appointed administrator too late can scuttle a transaction entirely. Incorporating the live Polish register into your automation helps clear regulatory hurdles before drafting the term sheet. Integrating the open-source registry server into your workflow ensures your compliance engine works with the exact legal state registered in Warsaw, rather than a weeks-old copy.

To run zero-signup testing across any of the 27 supported jurisdictions, configure your AI development client with the open registry server endpoint at openregistry.sophymarine.com.

Programmatic KYB in the Netherlands: What the KVK API actually reveals

OpenRegistry — Sun, 24 May 2026 15:01:00 +0000

A Dutch company registration number (KVK nummer) contains exactly eight digits, issued by the Kamer van Koophandel. For automated merchant onboarding, this number is the single source of truth. Relying on stale database aggregators to verify Dutch BVs often leads to false negatives. The Dutch corporate registry changes daily. Legal restructurings and address changes happen constantly. Stale records will fail audits.

Retrieving live registry data directly from the official source is the only defensible verification method. When your system queries the KVK registry programmatically, you receive raw data structures that demand precise parsing.

Structuring raw Dutch registry payloads

The standard payload returned from a live KVK query contains specific administrative fields that compliance workflows must handle. Unlike other jurisdictions that abstract these values, retrieving the raw jurisdiction_data preserves the original Dutch legal taxonomy. This preservation is critical for accurate risk scoring.

The core fields returned during a lookup include:

kvkNummer: The definitive eight-digit identifier.
rsin: The Rechtspersonen en Samenwerkingsverbanden Informatie Nummer, used for tax and legal identification.
statutaireNaam: The formal name registered in the articles of incorporation.
handelsnamen: An array of trade names under which the entity operates.
rechtsvorm: The legal structure, such as a Besloten Vennootschap (BV).

When performing a search, your system will use the search_companies tool. A typical payload contains both the active trade names and the historical legal names. This helps compliance teams resolve discrepancies where a merchant operates under a brand different from their legal entity name.

Different legal structures in the Netherlands dictate different reporting requirements. A Besloten Vennootschap (BV) has strict registration rules. By contrast, a Vennootschap onder firma (VOF) operates under a partnership model. When parsing the rechtsvorm field, your compliance engine must route the onboarding flow down different risk paths. A partnership might not register directors in the same format as a BV, requiring you to adapt your parsing logic.

Navigating the post-CJEU UBO landscape

A European Court of Justice ruling in 2022 dismantled public access to Ultimate Beneficial Owner (UBO) registers across the European Union. In response, the KVK immediately restricted public access to the Dutch UBO register. Today, compliance teams cannot programmatically extract the complete ownership chain of a Dutch entity using public tools.

This limitation forces a trade-off. While you can verify that an entity is active and retrieve its legal representatives via the registry, resolving the exact ownership percentages of shareholders holding over 25 percent requires alternative verification steps. Compliance officers must collect self-attested corporate charts from the customer during onboarding. You then cross-reference the active directors found in the registry to confirm authorization.

The standard officer tools, such as get_officers, return the registered board members and legal representatives where the KVK public registry exposes them. This lookup confirms whether the individual signing a contract actually holds the legal authority to bind the company.

Implementing KVK lookup tools

Integrating these checks into an automated compliance flow requires standardisation. The OpenRegistry MCP server provides direct, real-time access to the KVK without intermediary parsing, delivering the raw upstream fields directly to your internal decision engines.

To initiate a search for a Dutch company by name, the assistant executes the search_companies tool with the appropriate country filter:

{
  "name": "Acme Netherlands",
  "jurisdiction": "NL"
}

Once you identify the correct entity, you can pull the registry profile using the unique registration identifier. Call the get_company_profile tool:

{
  "company_id": "12345678",
  "jurisdiction": "NL"
}

This call hits the live registry of record in real time. It bypasses the stale caches typical of legacy paid databases. This ensures that your compliance logs reflect the exact state of the KVK database at the millisecond of onboarding.

Ensuring an audit trail for regulators

Internal auditors and external regulators expect a clear provenance for every corporate check. Screenshots of registry web portals are no longer sufficient for automated high-volume onboarding environments. Your system must store the raw JSON payload alongside a timestamp. This proves that the company was active and registered at the time of transaction approval.

By maintaining direct lookups, compliance teams can confidently defend their Know Your Business (KYB) decisions during regulatory reviews. To integrate live Dutch registry access into your own automated compliance workflows without signing up for complex contracts, you can get started directly by using openregistry.sophymarine.com today.

Querying Spain's Registro Mercantil: how to parse BORME data via MCP

OpenRegistry — Sat, 23 May 2026 15:00:37 +0000

Spain's corporate registry network distributes company filings across local provincial databases. The central Registro Mercantil Central in Madrid acts as an oversight body, but the records reside locally. Every registered Spanish company carries a unique nine-character Número de Identificación Fiscal (NIF). The leading character of this tax number indicates the corporate form. A "B" denotes a limited liability company (Sociedad de Responsabilidad Limitada). An "A" signals a public limited company (Sociedad Anónima). By law, any corporate filing or change only becomes opposable to third parties once published in the Boletín Oficial del Registro Mercantil (BORME).

For analysts and compliance officers conducting M&A diligence, querying these provincial databases directly is the only way to guarantee data integrity. Relying on cached data from the legacy paid databases risks missing recent management changes or insolvency filings. The OpenRegistry Model Context Protocol (MCP) server connects directly to these official sources. This connection enables AI assistants and programmatic workflows to query live Spanish registry records.

Raw registry payload structure

When you query a Spanish entity, the registry returns provincial filings alongside basic company identifiers. The OpenRegistry MCP server delivers this raw payload inside the jurisdiction_data object. It leaves the schema intact.

The JSON payload contains several key fields:

nif: The registered tax identification number.
denominacion: The official registered name of the corporation.
provincia: The provincial registry office holding the company’s books.
estado: The legal status of the company.
actos_inscritos: The chronological ledger of gazetted acts published in the BORME.

The actos_inscritos array provides crucial compliance data. Each item includes a publication date, a section code, and a description of the corporate action. These events include capital modifications, director appointments, or dissolution proceedings. Capital markets teams use this array to build a verified timeline of corporate changes directly from the primary source.

The CJEU ruling and beneficial ownership

Following the Court of Justice of the European Union (CJEU) ruling in joined cases C-37/20 and C-601/20, access to ultimate beneficial ownership (UBO) databases changed across Europe. Spain codifies these restrictions strictly. Access to the Registro de Titularidades Reales is legally gated. Only entities demonstrating a statutory legitimate interest can query it. This includes financial institutions, notary publics, and law enforcement executing anti-money laundering (AML) tasks.

Because of these rules, no public API can return automated Spanish UBO data. OpenRegistry operates within these regulatory boundaries. The tools return public officers, administrators, and historical gazette filings. They do not bypass statutory AML gates. If a data vendor claims to offer instant, ungated Spanish UBO data, they are serving stale, scraped databases. Or they are using probabilistic estimates instead of live registry records.

Querying the registry via MCP

To find a Spanish entity, invoke the search_companies tool with the ES jurisdiction code. Searching by NIF provides the most direct match. Name queries are also supported.

{
  "name": "search_companies",
  "arguments": {
    "query": "B88123456",
    "jurisdiction": "ES"
  }
}

Once you have the registration identifier from the search results, query the profile details using the get_company_profile tool to retrieve the current state of the company.

{
  "name": "get_company_profile",
  "arguments": {
    "company_id": "ES-B88123456",
    "jurisdiction": "ES"
  }
}

This request connects directly to the provincial registry system to fetch the company's standing, registered address, and gazetted BORME filings. The integration bypasses middle-tier databases, keeping your compliance trail clean and verifiable.

Verification workflows for finance teams

For analysts checking acquisition targets or compliance officers assessing counterparties, live data prevents transaction errors. When a Spanish counterparty changes its sole administrator or reduces its share capital, global corporate aggregators often take weeks to reflect the update.

Integrating the BORME gazette timeline into your analytical platform lets your team verify active signers before executing agreements. This approach mitigates risk and aligns with European diligence standards. To query the Spanish registry alongside 26 other national jurisdictions without API key barriers, point your client to openregistry.sophymarine.com and start the server.

Italy’s Registro delle Imprese via BRIS: fields returned

OpenRegistry — Thu, 21 May 2026 15:03:55 +0000

Italian company filings sit in a distributed register run by the chambers of commerce. Unioncamere coordinates the network. The EU Business Registers Interconnection System (BRIS) then publishes the cross‑border slice. Each company record carries two numbers: a provincial REA identifier and a national fiscal code. Query an Italian company through software and both usually appear immediately.

A register run through the chambers of commerce

The Registro delle imprese is set out in the Italian Civil Code and administered by the Camere di Commercio. Every chamber maintains the legal record for companies within its province. Those provincial databases feed the national system.

BRIS republishes a restricted EU dataset required by Directive (EU) 2017/1132. Restricted is the key word. The BRIS layer does not expose the entire chamber archive. Only the statutory fields intended for cross‑border disclosure leave Italy through that channel.

That separation carries legal weight. Statutory notice attaches to filings accepted by the chamber register itself. BRIS distributes the information across the Union but it is not the place where registration legally occurs. Software that queries BRIS therefore reads the harmonised disclosure layer used for European company lookups.

Fields that come back through BRIS

A typical Italian company profile returned through the MCP interface exposes several identifiers that compliance teams recognise straight away.

Near the top sits the REA number (Repertorio Economico Amministrativo). This identifier links the entity to its provincial chamber entry. Investigations often begin there. The number anchors the company to a specific chamber office and its filings.

Another field is the codice fiscale. For companies it usually matches the VAT number. Across datasets it behaves as the most stable reference because the same code appears in tax records as well as corporate filings.

The registered office appears as a structured address within the BRIS payload. The upstream Italian entry normally includes municipality and province codes embedded in the jurisdiction fields. When OpenRegistry returns the raw jurisdiction_data, those source values remain visible. No translation layer sits in between.

Legal form is another useful signal. Italian entries use abbreviations such as S.r.l. or S.p.A.. Each abbreviation maps to a company type defined in the Civil Code. Registries tend to store the value exactly as filed rather than converting it into another language.

Officer data arrives through the filings record. Directors and legal representatives appear as officers linked to the company entry. Titles usually remain in Italian. Small detail, real impact. The legal meaning of a role often depends on the precise wording recorded in the registry.

Gaps and legally gated data

Beneficial ownership is the largest gap right now. Legislative Decree 55/2022 created the central titolare effettivo register to meet EU transparency rules. Public access did not last long. The Court of Justice of the European Union ruled on the issue in Joined Cases C‑37/20 and C‑601/20.

Following that judgment, access rules tightened across several member states. Italy followed the same path. Orders from the Consiglio di Stato late in 2024 kept the public portal restricted while a new legitimate‑interest regime is prepared.

The result is simple. Programmatic access to UBO filings is not available through BRIS. OpenRegistry cannot surface what the upstream system does not publish.

Practitioners often fall back on chamber extracts known as a visura camerale. These documents come directly from the chamber record. They may include shareholder details or historical governance data that never travels through the EU interoperability layer.

Document access has similar limits. Some filings exist only as chamber PDFs. BRIS may publish a filing reference yet omit the document file itself. The metadata appears. The scan does not.

Querying it through the MCP server

OpenRegistry exposes the Italian register through the same MCP interface used for the other jurisdictions on the server. The pattern is straightforward. Run a search. Then request the profile using the company number returned.

Example search:

search_companies({
  "jurisdiction": "IT",
  "query": "ENI S.P.A."
})

The response includes the identifier assigned by the chamber record. That value feeds directly into the next call.

get_company_profile({
  "jurisdiction": "IT",
  "company_number": "00905811006"
})

Officer data can be requested separately when BRIS publishes it.

get_officers({
  "jurisdiction": "IT",
  "company_number": "00905811006"
})

Filings metadata follows the same structure.

list_filings({
  "jurisdiction": "IT",
  "company_number": "00905811006"
})

Each response contains the harmonised EU fields together with the original Italian payload stored inside jurisdiction_data. That raw block often includes chamber identifiers or classification codes that receive little attention in the official BRIS notes.

Practical use in diligence

Cross‑border M&A work often begins with a basic question: which Italian entity actually signed the agreement. The chamber record answers that quickly. It confirms legal existence, the registered office, and the individuals listed as legal representatives.

Sanctions and AML teams start from the same entry when mapping control. Even without public UBO access, the officer list and filing trail can hint at influence. Repeated directors across related firms. Representatives appearing in nominee roles. Patterns emerge.

Journalists use the identifiers differently. The REA number and fiscal code act as bridges when linking Italian companies to foreign subsidiaries disclosed through BRIS. One number opens the door to another dataset.

Developers building compliance tooling usually focus on a smaller detail. OpenRegistry preserves the raw Italian registry fields instead of rewriting them into a simplified schema. That choice avoids the data loss common in the legacy paid databases and leaves interpretation to the client.

OpenRegistry exposes the Italian BRIS dataset alongside 27 other national company registers through one MCP endpoint. Documentation and connection details sit at https://openregistry.sophymarine.com.

Germany’s Handelsregister via API: what the record actually shows

OpenRegistry — Wed, 20 May 2026 15:03:19 +0000

Every German company receives a court file number. A Berlin GmbH may appear as HRB 123456 B. Those letters indicate the register type and the local court, the Registergericht, that keeps the file. Germany has no single nationwide companies database. Each regional court maintains its own section of the Handelsregister and republishes notices through federal portals.

This layout shapes investigative work. A shell chain touching Hamburg and Bavaria means reading entries written by different courts, each with its own formatting habits. The legal framework stays standard. The presentation does not.

OpenRegistry queries the register endpoints used by those courts and returns the raw entry they publish. No aggregation layer sits in between. The response carries a jurisdiction_data block that reflects the court output line for line.

What the Handelsregister record actually contains

The core company profile exposes fields reporters often rely on when tracing control or mapping a corporate chain.

• register_number — the HRB or HRA number issued by the court. HRB denotes corporations such as GmbH or AG. HRA denotes partnerships such as KG.

• register_court — the court responsible for the entry, for instance Amtsgericht München.

• company_name — the legal name exactly as filed.

• legal_form — GmbH, AG, UG (haftungsbeschränkt), KG, along with other legal forms recognised by German company law.

• registered_address and city — the statutory seat, known as the Sitz.

Within jurisdiction_data you often see the original German labels carried over from the register. Sitz marks the legal seat. Gegenstand des Unternehmens describes the declared business activity. Vertretungsbefugnis explains how directors may represent the company in legal acts. Some entries specify that two managing directors must act together. That detail matters when verifying contracts or signatures.

Officer data comes from the same court record. A get_officers query usually returns managing directors for a GmbH or the Vorstand for an AG. The raw strings often include role titles such as Geschäftsführer or Vorstand. Anyone who needs structured role categories can extract them from those fragments in code.

Filings surface through the publication stream attached to the register entry. These notices include amendments to articles of association, director appointments, or changes to share capital. Many reference supporting documents such as the Gesellschafterliste. That shareholder list is often the only direct signal of ownership inside the Handelsregister itself.

What the registry does not give you

Corporate transparency in Germany sits across several registries rather than one system. The Handelsregister records formal corporate facts. Beneficial ownership belongs to the Transparenzregister. Access changed after the Court of Justice of the European Union ruling in case C‑601/20. Public access closed in 2022. Journalists can still request extracts in certain cases, though the process now requires identity checks and a declared interest.

Because of that split, the Handelsregister does not expose UBO data in its public entries. A dataset similar to get_persons_with_significant_control does not exist in this register.

Another limitation involves shareholder structure. The Gesellschafterliste normally arrives as a PDF attached to the filing record. The court logs that the document was submitted. It does not convert each shareholder row into machine‑readable fields. Anyone who needs ownership percentages has to retrieve the document and read it directly or run their own parser.

Historical coverage also differs between courts. Some began digitising older files early. Others only publish modern filings through their online interfaces. Activity before 2007 often appears as scanned paperwork rather than structured entries.

Querying the German register through MCP

An assistant connected to the OpenRegistry MCP server can query the German register directly. Start with a company search.

Example tool call:

search_companies({
  "jurisdiction": "DE",
  "query": "Wirecard AG"
})

The result returns candidate matches with their HR numbers and the relevant court. Once you have the register number, request the full profile.

get_company_profile({
  "jurisdiction": "DE",
  "company_number": "HRB 195317"
})

Officer data comes from the same file.

get_officers({
  "jurisdiction": "DE",
  "company_number": "HRB 195317"
})

Corporate changes appear through the filing history.

list_filings({
  "jurisdiction": "DE",
  "company_number": "HRB 195317"
})

If a filing references a document such as a Gesellschafterliste, fetch it with fetch_document using the identifier returned in the filings list.

Field notes from the German system

German corporate records reward slow reading. A director resignation may appear as a dense block of legal prose instead of a clean event record. Courts often publish the change notice in the register first. The same wording later shows up in the Unternehmensregister announcement feed.

This pattern matters in cross‑border reporting. Investigations touching Austria, Liechtenstein, or Cyprus often rely on German entries for the local picture. The Handelsregister typically lists the managing directors and the statutory seat. Ownership sometimes sits one jurisdiction higher.

Another detail involves timing around the shareholder list. A GmbH must submit a revised Gesellschafterliste when ownership changes. Delays still happen. During the Wirecard collapse, reporters compared several versions of those lists to see which investors appeared shortly before insolvency.

Why reporters still query it directly

A sanctions or corruption investigation often produces a large corporate graph. Editors and lawyers will ask where each fact originated. A court register entry answers that question. Anyone reviewing the work can repeat the same lookup and reach the same record.

OpenRegistry exposes Handelsregister entries through MCP using the same fields published by the court. The audit trail stays intact and the usual CAPTCHA loops on public portals disappear. Documentation and access details sit at https://openregistry.sophymarine.com.

France's Recherche d’entreprises: what the registry returns

OpenRegistry — Tue, 19 May 2026 07:43:09 +0000

France assigns every company a nine‑digit SIREN number. It follows the legal entity for its entire life. Change the address. Close a branch. The SIREN stays.

That detail surfaces quickly in cross‑border diligence. During a review of French logistics targets last quarter, a legacy paid database listed two operators as separate companies. The official register told a different story. Both records pointed to one SIREN, with several establishments attached through SIRET numbers. One entity. Several operating sites.

The public interface is called Recherche d’entreprises. It sits above the Registre national des entreprises, with data distributed through the INPI pipeline. Most users see a search page in their browser. Beneath that page sits a structured register keyed by SIREN. Ask for the identifier and the response comes from the official record, not a vendor’s interpretation.

Fields that appear in a registry record

A French company profile carries a dense set of fields. Several appear consistently when queried through OpenRegistry.

company_name stores the legal name recorded with the relevant authority, often the Registre du commerce et des sociétés. French firms often keep both a trading name and a legal denomination. The register keeps them as separate entries.

company_number corresponds to the SIREN identifier. Individual establishments appear upstream with their own SIRET numbers, each linked back to that parent number.

jurisdiction_data.forme_juridique records the legal structure. This is where the record states whether the entity is an SAS, SARL, SA, or another form. Guessing from a suffix in the name often fails.

jurisdiction_data.date_immatriculation shows the date the company first entered the trade register.

jurisdiction_data.code_ape holds the activity code under the NAF classification system.

Officer information usually sits in registry sections such as dirigeants within jurisdiction_data. Titles matter here. A président in an SAS holds a role that differs from a gérant in an SARL. The register keeps the wording exactly as filed. That wording becomes useful when tracing individuals across multiple entities, where a small title change can indicate a different legal position.

Filings also appear in the company record. Typical entries include capital increases, director appointments, and registered address updates. Filing metadata often links to the underlying document when the register publishes it.

Areas where the record is incomplete

France keeps beneficial ownership filings in the Registre des bénéficiaires effectifs (RBE). Access rules shifted after the Court of Justice of the European Union decision in case C‑601/20. Several EU countries limited open public access to those registers. France kept partial access for authorised users, though the data is not broadly open.

Run a standard registry query and you usually see company form and officers. Beneficial owners may not appear unless the legal framework allows that information to be shown publicly.

Financial statements follow a similar pattern. Many French companies file annual accounts with the registry. Smaller entities can request confidentiality for certain sections. When that happens the filing still appears in the register. The document itself may remain restricted.

These gaps often slip past cached datasets. Officer lists in subscription databases sometimes lag months behind the official record. A filing lands in the registry. The cached profile stays unchanged.

Querying the French registry through MCP

OpenRegistry connects an AI client directly to the registry query layer. The MCP server passes through the raw fields as they appear upstream. Your software decides what to do with them.

A search by company name or SIREN might look like this:

search_companies({
  "jurisdiction": "FR",
  "query": "BLADE SAS"
})

The response returns matching entities and their SIREN numbers. Once the identifier is known, the full company record can be requested.

get_company_profile({
  "jurisdiction": "FR",
  "company_number": "552100554"
})

Officer data comes through a separate call.

get_officers({
  "jurisdiction": "FR",
  "company_number": "552100554"
})

To inspect the filing history:

list_filings({
  "jurisdiction": "FR",
  "company_number": "552100554"
})

One field deserves close attention: jurisdiction_data. OpenRegistry leaves these labels unchanged from the upstream register. If the French record calls a field date_immatriculation, that exact label remains in the response. Downstream systems can parse the field or store it unchanged. No intermediary renaming step sits in the middle.

Why diligence teams start with the registry

A French operating company rarely sits alone. Structures often stretch across borders. A holding entity might sit in Luxembourg. The operating subsidiary sits in France. Sales branches appear elsewhere in Europe.

The first lookup matters.

If the starting record is stale, every ownership trace that follows may begin from the wrong assumption. A mistaken officer list. A missing filing. Small errors propagate quickly.

Direct register queries reduce that risk. SIREN numbers remain constant even when establishments change. Officer titles match the wording used in the filing. Filing timestamps line up with the official publication.

A recent screening of mid‑market software firms showed how quickly the picture can shift. One French SAS appeared dormant in an export from a paid database. The official register showed a capital increase filed two weeks earlier. That single filing changed the view of the shareholder structure before the management meeting even began.

OpenRegistry exposes that same registry surface to AI assistants through MCP. Instead of copying records from web portals or relying on cached exports, software can request the French company record directly from the source. Connection details for MCP clients are at https://openregistry.sophymarine.com.

Hit OpenCorporates' 200/month limit? Here's a free passthrough to UK/EU registries

OpenRegistry — Sun, 17 May 2026 06:22:41 +0000

Hit OpenCorporates' 200/month limit? Here's a free passthrough to UK/EU registries

OpenCorporates' free key allows 50 calls a day. OpenRegistry's anonymous tier allows 20 calls a minute, across 16 UK/EU/EEA company registries.

If you've been rationing OC quota all month, paste this and you have data:

curl "https://openregistry.sophymarine.com/api/v1/companies?q=monzo&jurisdiction=GB"

The rest of this post is the comparison numbers, what you actually get in the response, two concrete use cases, and the three ways to call the API (HTTP REST, HTTP RPC, or MCP for AI agents).

The free-tier numbers, side by side

OpenCorporates' published pricing:

Tier	Monthly cap	Daily cap	Annual price	Commercial use
Free	200 calls	50 calls	£0	Open-data / public-benefit only
Essentials	500 calls	200 calls	£2,250	Yes
Starter	2,500 calls	500 calls	£6,600	Yes
Basic	5,000 calls	1,000 calls	£12,000	Yes

OpenRegistry's published pricing:

Tier	Rate limit	Monthly price	Commercial use
Anonymous	20 req/min/IP	$0	Yes
Free (signed in)	30 req/min/user	$0	Yes
Pro	higher per-country fan-out, higher rate	$9	Yes
Max	enterprise rates	$29	Yes

The headline: 20 calls/min sustained is roughly 28,800/day. OC's free tier is 50/day. Same direction, about 576× the daily headroom, no licence clause attached. When you do outgrow free, $9/mo is the next step instead of a £2,250 annual contract.

How the free tier works

There is no ingested snapshot. Each tool call is a real-time HTTP request from the worker out to the upstream government registry. Your response carries a unified envelope plus the registry's own JSON payload preserved under jurisdiction_data, so an audit reviewer can trace any field back to the statutory source.

A real response from /api/v1/companies/GB/09446231, trimmed:

{
  "queried_at": "2026-05-17T06:02:24+01:00 (Europe/London)",
  "jurisdiction": "GB",
  "company_id": "09446231",
  "company_name": "MONZO BANK LIMITED",
  "status": "active",
  "incorporation_date": "2015-02-18",
  "registered_address": "Broadwalk House, 5 Appold Street, London, EC2A 2AG, England",
  "jurisdiction_data": {
    "company_number": "09446231",
    "company_status": "active",
    "type": "ltd",
    "date_of_creation": "2015-02-18",
    "sic_codes": ["64191", "64999"],
    "has_charges": false,
    "has_insolvency_history": false,
    "accounts": { /* full Companies House accounts block */ }
  }
}

A 3-country per-minute cross-border fan-out cap applies on the anonymous tier (raised on Pro/Max). Cayman Islands is paid-tier only because the upstream CIMA register charges per query; everywhere else is free anonymous.

UK, EU and EEA coverage today

The 16 registries with first-party government APIs already wired for search and profile:

UK & Crown dependencies

UK Companies House (GB)
Isle of Man Companies Registry (IM)

EU member states

France Recherche d'entreprises (Sirene + RNE + RNA, open API) (FR)
Ireland CRO (IE)
Belgium Crossroads Bank for Enterprises (CBE / KBO / BCE) (BE)
Italy InfoCamere via the EU BRIS e-Justice gateway (IT)
Spain BORME (ES)
Poland KRS (PL)
Czechia ARES (CZ)
Finland PRH avoindata (FI)
Cyprus DRCOR (CY)

EEA + EFTA + microstates

Norway Brreg / Enhetsregisteret (NO)
Switzerland Zefix (CH)
Iceland Skatturinn / Fyrirtækjaskrá (IS)
Liechtenstein Handelsregister (LI)
Monaco RCI (MC)

Three ways to call it

Same handlers, same auth, same rate-limit pipeline behind all three. Pick by client.

Option A — HTTP REST (`/api/v1/...`)

For backend code that already speaks resource-oriented HTTP. Routes:

GET /api/v1/jurisdictions[/{cc}]
GET /api/v1/companies?q=&jurisdiction=
GET /api/v1/companies/{jur}/{id}
GET /api/v1/companies/{jur}/{id}/officers
GET /api/v1/companies/{jur}/{id}/shareholders
GET /api/v1/companies/{jur}/{id}/filings
GET /api/v1/officers?q=&jurisdiction=
GET /api/v1/documents/{jur}/{id}
GET /api/v1/documents/{jur}/{id}/content       (raw bytes)
GET /api/v1/documents/{jur}/{id}/navigation

Two lines of Python:

import requests

r = requests.get(
    "https://openregistry.sophymarine.com/api/v1/companies",
    params={"q": "monzo bank", "jurisdiction": "GB"},
)
print(r.json()["results"])

A profile per country, using the registry's own company ID:

# UK Companies House (Monzo Bank)
curl "https://openregistry.sophymarine.com/api/v1/companies/GB/09446231"

# France Sirene/RNE (Danone, SIREN)
curl "https://openregistry.sophymarine.com/api/v1/companies/FR/552032534"

# Poland KRS (Polskie Koleje Państwowe / PKP)
curl "https://openregistry.sophymarine.com/api/v1/companies/PL/0000019193"

# Norway Brreg (Equinor ASA, org.nr)
curl "https://openregistry.sophymarine.com/api/v1/companies/NO/923609016"

# Italy InfoCamere via BRIS (Candy Hoover Group)
curl "https://openregistry.sophymarine.com/api/v1/companies/IT/04666310158"

Officers, beneficial owners and the share register sit on separate sub-paths because in most EU registries they correspond to separate filings and collapsing them loses information.

Option B — HTTP RPC (`/api/v1/rpc/{tool_name}`)

For code that already thinks in tool names, or for tools whose input is awkward to encode as a REST path. URL is always /api/v1/rpc/{tool_name}; args go in the query string on GET or a JSON body on POST:

# Same call as the REST search, RPC style:
curl "https://openregistry.sophymarine.com/api/v1/rpc/search_companies?q=monzo&jurisdiction=GB"

# Profile via POST + JSON body:
curl -X POST https://openregistry.sophymarine.com/api/v1/rpc/get_company_profile \
  -H "Content-Type: application/json" \
  -d '{"jurisdiction":"GB","company_id":"09446231"}'

Easiest path if you already have working MCP-tool code and want to drop it onto a plain HTTPS client without rewriting argument plumbing.

Option C — MCP transport (`/mcp`)

For AI agents. Works in Claude Desktop, Cursor, Cline, Goose, Zed, Claude Code:

// claude_desktop_config.json
{
  "mcpServers": {
    "openregistry": {
      "url": "https://openregistry.sophymarine.com/mcp",
      "transport": "http"
    }
  }
}

For Claude Code:

claude mcp add --transport http OpenRegistry https://openregistry.sophymarine.com/mcp

Visible tools: search_companies, search_officers, get_company_profile, get_officers, get_shareholders, list_filings, get_document_metadata, get_document_navigation, fetch_document, list_jurisdictions. Each comes with an MCP input + output schema, so the agent gets static validation without you writing a wrapper.

Which to pick

Your client	Best shape
Backend service / cron / notebook	HTTP REST
Existing code that already speaks MCP tools	HTTP RPC
LLM agent	MCP at `/mcp`

Auth, redaction, rate limiting and the per-country fan-out cap are identical across all three.

Try it

Three things you can do right now:

Run the search: curl "https://openregistry.sophymarine.com/api/v1/companies?q=apple&jurisdiction=GB"
Wire the MCP endpoint into your Claude Desktop / Cursor / Cline config and ask it "look up Monzo Bank on Companies House and summarise its latest filing".
Read the full comparison against Sayari, BvD/Orbis, D&B and GLEIF: OpenCorporates alternatives compared.

Docs and the live capability matrix are at openregistry.sophymarine.com.

OpenRegistry is a platform by Sophymarine.

OpenCorporates vs. official registries: when caching breaks KYB

OpenRegistry — Sun, 17 May 2026 02:33:13 +0000

Companies House processed over 6 million filings during 2024. Many reach the public register minutes after submission. That speed is routine for a statutory register. Aggregator databases work differently. They pull periodic snapshots and refresh on their own timetable.

KYB teams feel the gap during onboarding. A merchant signs up and states the company formed last week. Your system queries an aggregator cache and returns nothing because the last bulk import ran months earlier. The record exists already. The vendor has simply not collected it.

On paper the delay looks minor. In operations it produces false negatives, manual review queues, and audit trails that do not line up with the public record.

The registry of record behaves differently

National registers publish the fields the law requires. In the United Kingdom that means Companies House exposes the official company number, incorporation date, registered office address, officer appointments, and the filing log. Each identifier originates inside the registrar’s own system.

Query the register directly and you see those upstream attributes without reinterpretation. A typical company profile response contains fields such as:

company_number
company_name
company_status
date_of_creation
registered_office_address

Officer data appears through a separate endpoint. Those entries carry attributes like officer_role, appointed_on, and resigned_on. Filings follow the same pattern. When a company submits accounts or a confirmation statement, the register lists the event with fields including category, date, and transaction_id, which points to the original submission record.

These are register facts. Not derived fields. That distinction matters the moment compliance asks where a value originated.

Where aggregator caching causes KYB failures

Cached datasets drift away from the source over time. A register entry might change this morning. The mirrored dataset could sit unchanged for weeks. If onboarding checks read the mirror rather than the register, the system evaluates stale information.

Three patterns show up again and again in KYB queues.

A newly incorporated company applies for an account. The registrar already issued the company number. Your provider still shows no match, so the onboarding flow marks the applicant as unverifiable.

A director resigns after enforcement action. The update appears at the register the same day. The cached dataset still lists the officer as active. Internal review assumes the person retains control.

A dissolved company restores its status through court order. The registrar updates the company_status field soon after restoration. Mirror datasets sometimes keep the dissolved flag until the next import cycle.

Each case creates the same problem. The register says one thing. Your dataset says another.

What direct registry queries look like

The practical option is simple: query the register when the KYB check runs. An MCP client using OpenRegistry sends a tool call and receives the fields returned by the jurisdiction.

Searching Companies House by name might look like this:

search_companies({
  "jurisdiction": "GB",
  "query": "ACME PAYMENTS LTD"
})

Once you have the company number, the profile request is straightforward:

get_company_profile({
  "jurisdiction": "GB",
  "company_number": "12345678"
})

The response includes a jurisdiction_data block that mirrors the payload supplied by Companies House. No reinterpretation. No enrichment layer. Only the minimal schema fields needed so cross‑country queries stay consistent.

That detail becomes useful during regulatory review. An auditor can trace the field directly to the upstream register entry.

Officers and filing history come through separate calls. The structure follows the source register closely. Little abstraction.

What you will not get from the registry

Direct register queries do not answer every KYB question. Some ownership information in Europe moved behind AML access gates after the CJEU ruling in case C‑601/20. Germany’s Transparenzregister is a well‑known example. Public company registers still expose directors and filings. Beneficial ownership often requires authorised access.

Registers also do not provide sanctions checks, credit assessments, or risk scoring. Those sit in separate systems layered on top of the base company record.

Treat the register as the reference point for legal existence and current status. Additional analysis happens afterwards.

Why auditors favour the registry path

Audit reviews usually circle back to a simple question: where did this company record originate?

If the answer is an aggregator dataset, the next conversation covers refresh frequency, reconciliation routines, and how the system handles conflicts between the dataset and the official register. That explanation can grow complicated, especially when values diverge.

If the answer is the register itself, the chain of evidence stays short. The onboarding system queried the official register at a specific timestamp. The returned fields match the state of the register at that moment.

Clear provenance matters. Compliance teams increasingly query national registers during onboarding rather than relying on cached mirrors. The register remains the authoritative source for company existence and legal status.

OpenRegistry exposes 27 national company registers through a single MCP endpoint so an AI assistant or internal agent can query the register of incorporation during KYB checks. Details and connection instructions are at https://openregistry.sophymarine.com

DEV Community: OpenRegistry

Reading Belgium's KBO/CBE registry: what the live API returns

Analysing Zefix data: tracking Swiss entities via raw registry access

The Swiss cantonal split

Current integration status

Querying Swiss-linked entities through active sibling registries

Why raw data beats caches

Finland's YTJ Registry — what the official API actually returns

Structure of the Finnish YTJ payload

Statutory boundaries of Finnish beneficial ownership data

Querying Finland via OpenRegistry MCP

Designing resilient compliance flows

Trace Norwegian shell companies directly via Brønnøysundregistrene API

Mapping Polish company structures: querying KRS direct via API

KRS API Data Models

Polish Registry Boundaries

Querying KRS Programmatically Using MCP

Corporate Status Verification

Programmatic KYB in the Netherlands: What the KVK API actually reveals

Structuring raw Dutch registry payloads

Navigating the post-CJEU UBO landscape

Implementing KVK lookup tools

Ensuring an audit trail for regulators

Querying Spain's Registro Mercantil: how to parse BORME data via MCP

Raw registry payload structure

The CJEU ruling and beneficial ownership

Querying the registry via MCP

Verification workflows for finance teams

Italy’s Registro delle Imprese via BRIS: fields returned

A register run through the chambers of commerce

Fields that come back through BRIS

Gaps and legally gated data

Querying it through the MCP server

Practical use in diligence

Germany’s Handelsregister via API: what the record actually shows

What the Handelsregister record actually contains

What the registry does not give you

Querying the German register through MCP

Field notes from the German system

Why reporters still query it directly

France's Recherche d’entreprises: what the registry returns

Fields that appear in a registry record

Areas where the record is incomplete

Querying the French registry through MCP

Why diligence teams start with the registry

Hit OpenCorporates' 200/month limit? Here's a free passthrough to UK/EU registries

Hit OpenCorporates' 200/month limit? Here's a free passthrough to UK/EU registries

The free-tier numbers, side by side

How the free tier works

UK, EU and EEA coverage today

Three ways to call it

Option A — HTTP REST (/api/v1/...)

Option B — HTTP RPC (/api/v1/rpc/{tool_name})

Option C — MCP transport (/mcp)

Which to pick

Try it

OpenCorporates vs. official registries: when caching breaks KYB

The registry of record behaves differently

Where aggregator caching causes KYB failures

What direct registry queries look like

What you will not get from the registry

Why auditors favour the registry path

Option A — HTTP REST (`/api/v1/...`)

Option B — HTTP RPC (`/api/v1/rpc/{tool_name}`)

Option C — MCP transport (`/mcp`)