Trade Register Data Structure for PKI and Subject Verification

Trade Register data should be stored as time-bound facts, not reconstructed from logs.

A jurisdiction-specific `subject_identifier` is proposed to identify the registered subject.

The internal subject_id remains the primary identifier within the Trade Register.

Names, legal status and optional subject attributes should be modelled using relational structures with explicit UTC date-times.

The primary trade name designation is a separate historical fact and should be maintained in its own table.

Optional attributes, such as IBAN, should be clearly identified and may require explicit consent before disclosure.

Field reference - From June 11, 2026 - Insight at janwillemstegink.nl

Naming Standardization in the Trade Register

Abbreviations such as B.V. and N.V. should be standardized as BV and NV by introducing a legalized_name name type. Trade names must be retrievable in their original letter case for precise matching.

Table Field Key Req. Meaning
registered_subjectsubject_idPKYesInternal Trade Register subject identifier.
subject_identifierIDXYesUnique reference assigned to a registered subject and prefixed by the issuing jurisdiction.
local_codeIDXYesUnique local Trade Register number assigned by the registration authority.
jurisdiction_codeYesIssuing jurisdiction code.
registration_authorityYesRegister authority.
subject_fromYesUTC date-time from which this subject record applies.
subject_toNoUTC date-time until which this subject record applied; empty means current.
subject_legal_statuslegal_status_idPKYesLegal status record identifier.
sls_subject_idFKYesRegistered subject.
legal_statusYesRecorded legal status.
legal_status_codeNoStandardized abbreviation of the legal status.
status_fromYesUTC date-time from which this legal status applies.
status_toNoUTC date-time until which this legal status applied; empty means current.
subject_namename_idPKYesName record identifier.
sn_subject_idFKYesRegistered subject.
name_typeYeslegal, legalized, trade.
name_valueYesRecorded name value.
is_case_sensitiveYesUppercase/lowercase distinction applies.
name_fromYesUTC date-time from which this name applies.
name_toNoUTC date-time until which this name applied; empty means current.
primary_trade_nameprimary_name_idPKYesPrimary trade name designation record.
ptn_subject_idFKYesRegistered subject.
ptn_name_idFKYesName designated as primary trade name.
primary_fromYesUTC date-time from which this name is primary.
primary_toNoUTC date-time until which this name was primary; empty means current.
subject_locationlocation_idPKYesSubject location record.
sl_subject_idFKYesRegistered subject.
sl_name_idFKNoTrade name associated with this location.
street_address1NoPrimary street address line.
street_address2NoAdditional street address line.
postal_codeNoPostal or ZIP code.
cityNoCity or locality.
state_regionNoState, province, or region.
country_codeNoISO 3166-1 alpha-2 country code.
location_fromYesUTC date-time from which this location applies.
location_toNoUTC date-time until which this location applied; empty means current.
optional_subject_attributeattribute_idPKYesOptional attribute record.
osa_subject_idFKYesRegistered subject.
attribute_nameYesiban, bic, account_holder_name, website_url, contact_email.
attribute_valueNoProvided value; empty means not provided.
consent_requiredYesExplicit consent required before disclosure.
attribute_fromYesUTC date-time from which this attribute applies.
attribute_toNoUTC date-time until which this attribute applied; empty means current.
subject_responsibleresponsible_idPKYesResponsible party record identifier.
sr_subject_idFKYesRegistered subject.
responsible_subject_codeIDXYesSubject code identifying the responsible natural person.
responsible_nameYesRecorded name of the responsible party.
responsible_roleYesRole of the responsible party.
authority_to_representNoIndicates authority to represent the subject.
responsible_fromYesUTC date-time from which this responsibility applies.
responsible_toNoUTC date-time until which this responsibility applied; empty means current.
subject_relationshiprelationship_idPKYesSubject relationship record identifier.
from_subject_idFKYesSubject from which the relationship is defined.
to_subject_idFKYesSubject to which the relationship applies.
relationship_typeYesType of relationship between the registered subjects.
relationship_fromYesUTC date-time from which this relationship applies.
relationship_toNoUTC date-time until which this relationship applied; empty means current.
subject_relationship_attributerelationship_attribute_idPKYesRelationship attribute record identifier.
sra_relationship_idFKYesSubject relationship.
relationship_attribute_typeYesType of attribute describing the relationship.
relationship_attribute_valueYesValue of the relationship attribute, interpreted according to its type.
relationship_attribute_fromYesUTC date-time from which this attribute value applies.
relationship_attribute_toNoUTC date-time until which this attribute value applied; empty means current.

Rules

Private individuals should be able to use an electronic identity wallet on their own devices. This includes Linux-based phones.

Wallet functionality should therefore not depend on the use of a particular commercial mobile operating system or on registration as a Trade Register subject.

Where an authoritative register serves a public function, public access to its data may be funded from public resources rather than through charges for individual data access or retrieval.

Public funding of an authoritative register should support a proportionate organizational structure, with specialized functions introduced only where their responsibilities cannot reasonably be shared or combined with other functions.

Parts of this governance evolution have been addressed in individual countries. Different institutional, funding, and public-access models are in use. These provide practical reference points for developing authoritative public registers.

Preparing on GitHub: EU Digital Identity Wallet — Android reference implementation

Digital Identity: Technical, Organisational and Governance Responsibilities (Working Version 0)

Towards decision-ready information for both simple and complex implementations, beyond things already understood.

Responsibility Generic role Scope Dutch implementation Description
Business registration Business Register National KVK / Handelsregister Maintains authoritative business registration data.
Person identification Identity Provider EU / National DigiD / EUDI? Establishes trusted evidence of a natural person's identity.
Organisation identification Authoritative Register EU / National KVK / Handelsregister Establishes the registered identity of an organisation.
Relationship registration Authoritative Register National KVK / Handelsregister Records relationships between registered subjects.
Representation authority Authoritative Source EU / National KVK / Handelsregister? Establishes who may act for an organisation.
Attribute definition Attribute Scheme Authority EU / National To be determined Defines trusted attributes and their meaning.
Attribute issuance Attribute Issuer EU / National To be determined Issues trusted attributes from authoritative data.
Trust framework Trust Framework Authority EU / National To be determined Defines how trusted parties and credentials are recognised.
Trust services Trust Service Provider (TSP / QTSP) EU / National TSPs / QTSPs Provides regulated electronic trust services.
Public key infrastructure Public Key Infrastructure (PKI) Global / EU / National PKIoverheid Provides cryptographic trust infrastructure.
Trust lists Trusted List Provider EU / National Dutch Trusted List Publishes trusted service providers and their status.
Wallet provision Wallet Provider EU / National NL Wallet / private wallet providers? Provides digital identity wallets.
Wallet interoperability Standards and Conformance Framework Global / EU EUDI / national implementation? Enables wallets, issuers and relying parties to interoperate.
User platform Platform Provider Global / EU Android / iOS / Linux-based platforms? Provides the operating environment for a wallet.
Secure key storage Secure Cryptographic Environment Global / EU To be determined Protects cryptographic keys and operations.
Service verification Relying Party Global / EU / National Public and private service providers Requests and verifies trusted information.
Technical conformance Conformance Authority / Test Facility Global / EU / National To be determined Tests implementations against applicable requirements.
Issue handling Issue Resolution Function EU / National To be determined Routes technical and data issues to the responsible party.
Remediation Remediation Function EU / National To be determined Ensures identified problems can be corrected.
Escalation Escalation Authority EU / National To be determined Handles unresolved cross-party issues.
Supervision Supervisory Authority EU / National RDI / other competent authorities? Provides independent regulatory oversight.
Cross-domain coordination Coordinator EU / National To be determined Maintains alignment across all responsibilities.
Governance Governance Authority EU / National To be determined Assigns ownership, decisions and accountability.