Purpose. This model examines how Trade Register data can support historical accuracy, globally unambiguous identification, PKI, electronic identity wallets and alternate handling.
Trade Register Structure Modeling - Trade Register Task Allocation - Supplier Alternate Handling Modeling - From June 11, 2026 - Insight at janwillemstegink.nl - Latest change: October 8, 2026.
IBAN, RDAP and eIDAS work very differently. IBAN incorporates issuing country identification and check digits into the identifier itself. RDAP provides an international protocol, while important data semantics depend on registry, registrar and policy context and are represented through complex JSON structures. JSON can be formally constrained, but is often used with less structural discipline than XML schemas. eIDAS provides a common framework while its data structures remain heavily rooted in Member State systems. Domain identity must start with the registry, not with DNS.
Which information should be made globally unambiguous in the data itself, rather than relying on external context or additional interoperability layers? First, a globally unique identifier.
A Global Subject Identifier identifies a registered subject. The subject_identifier begins with the ISO 3166-1 alpha-2 issuing country code, may include a state code, and contains two check digits. The issuing jurisdiction is inherent in the identifier; the internal subject_id remains the primary identifier within the Trade Register. The identifier does not imply that its subject is a natural person, business, legal entity or particular legal form: these characteristics come from registration data and may change over time.
Trade Register data should be stored as time-bound facts, not reconstructed from logs. Names, legal status and optional attributes belong in relational structures with explicit UTC from/to date-times. The primary trade name designation is a separate historical fact, not merely an instruction to put a name first in the user interface. Field names should be globally distinguishable wherever practical, reducing ambiguity and facilitating exchange and development.
Legal names should have a standardized legalized name, such as BV and NV rather than B.V. and N.V., for reliable matching. Trade name searches start with the legally recorded spelling.
legalized_name serves as the primary trade name.Personal privacy considerations should not impede continuity or transfer of a business domain and its services; the domain and the type of registrant should therefore be identifiable in RDAP.
Private individuals should be able to use an electronic identity wallet on their own devices, including Linux-based phones, although these are currently not ready to provide the required PKI functionality. Wallet functionality may temporarily depend on a commercial mobile operating system, but this should not become a permanent requirement or depend on registration in a Trade Register.
Where an authoritative register serves a public function, public access to its data may be publicly funded rather than charged per retrieval. Public funding should support a proportionate organization, introducing specialized functions only where responsibilities cannot reasonably be combined. Different institutional, funding and public-access models already exist in individual countries and provide useful reference points.
The technical, organisational and governance responsibilities for digital identity are separately mapped in Trade Register Task Allocation.
Preparing on GitHub: EU Digital Identity Wallet — Android reference implementation