Cross-registry checks

Some entity IDs can be verified by more than one registry. In other cases, verifying one ID reveals additional IDs, such as VAT numbers or LEIs, that can be resolved separately when expansion is enabled.

Whenever more than one registry contributes information, the engine merges all responses into a single, coherent result. This page explains how registry precedence is determined, how fields are merged, and how normalisation ensures consistent outcomes when data originates from multiple sources. These rules apply to the verification process described in Verify an ID.

When cross-registry checks occur

Cross-registry checks occur in two situations.

First, multiple registries may support the same ID type. When this happens, all relevant registries are queried and their responses are merged. This can occur, for example, when overlapping datasets exist for the same national ID or when both national and supranational registries expose information about the same scheme.

Second, cross-registry checks occur when expansion is enabled using expand: true. Expansion allows the engine to resolve additional IDs linked to the primary one and to query the registries backing those IDs.

For example, a Norwegian organisation number (no_orgnr) may expose a linked VAT number (no_vat) and LEI (ww_lei). When expansion is enabled, the engine will attempt to resolve those IDs and query their respective registries, resulting in a richer profile of the entity.

Registry precedence: closest registry wins

When multiple registries participate in a verification, precedence is determined by which ID is being verified.

When verifying a national ID, such as no_orgnr or it_vat:

• the national registry for that ID type is authoritative,
• registries associated with linked IDs participate next,
• international registries, such as LEI, participate last.

When verifying an international ID, such as ww_lei:

• the GLEIF (ww-gleif) registry is authoritative,
• national registries may contribute complementary information,
• national data never overrides information originating from the LEI root.

This rule ensures consistent behaviour across jurisdictions. The registry closest to the ID being verified defines the core profile, while other registries enrich it without reshaping it.

Field-level merging rules

Once registry precedence is established, data is merged using a simple and deterministic rule.

Registries are processed in precedence order. For each field, the first registry that provides a value becomes authoritative for that field. Subsequent registries may fill missing information, but they never overwrite values that were already set by a higher-precedence source.

This rule applies uniformly, including when expansion introduces additional IDs such as VAT numbers or LEIs. Even in those cases, secondary registries can only contribute complementary data.

All participating registries are recorded in process.sources[], in the exact order they were applied. This information is exposed through the shared Response envelope and provides a complete audit trail without introducing per-field attribution or inflating the payload with source metadata for every value.

Normalisation and inferred components

Normalisation plays a central role in cross-registry merging.

Registries often represent the same information using different formats. To avoid false conflicts, the engine normalises key elements before attempting to merge values. This includes ID strings, names, dates, addresses, and casing or formatting variations. Normalisation allows the engine to recognise that two registries are referring to the same underlying information even when their raw representations differ.

Normalisation also enables the engine to infer structured components, particularly for addresses. These inferred components include best-effort identification of street and house number, PO boxes, ISO subdivision codes, and locality or district boundaries.

Inferred components are helpers rather than authoritative facts. Raw registry values are always preserved internally and remain the ultimate reference for audits and compliance. The underlying normalisation and parsing model is described in more detail in Data normalisation.

Real-world example

The example below shows a fully merged result for ORGNR914 778 271 with expansion enabled, including normalised addresses, lifecycle information, related IDs, and registry metadata.

In this scenario:

• the Norwegian organisation registry establishes the core identity of the entity;
• the LEI registry participates later, enriching the profile;
• global IDs and metadata are added without overriding nationally sourced fields.

The final response reflects the precedence and merging rules described above, with all contributing registries listed under process.sources[].