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_code` is proposed to identify the registered subject.

The internal `subject_id` remains the primary key of 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 - Issues on GitHub - 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_subject	subject_id	PK	Yes	Internal Trade Register subject identifier.
	subject_code	IDX	Yes	Jurisdiction-specific subject code identifying the registered subject.
	jurisdiction_code		Yes	Legal jurisdiction code.
	registration_authority		Yes	Register authority.
	registration_number	IDX	Yes	Local Trade Register number.
	valid_from		Yes	UTC date-time from which this subject record applies.
	valid_to		No	UTC date-time until which this subject record applied; empty means current.
subject_legal_status	legal_status_id	PK	Yes	Legal status record identifier.
	subject_id	FK	Yes	Registered subject.
	legal_status		Yes	Recorded legal status.
	legal_status_code		No	Standardized abbreviation of the legal status.
	valid_from		Yes	UTC date-time from which this legal status applies.
	valid_to		No	UTC date-time until which this legal status applied; empty means current.
subject_name	name_id	PK	Yes	Name record identifier.
	subject_id	FK	Yes	Registered subject.
	name_type		Yes	legal, legalized, trade.
	name_value		Yes	Recorded name value.
	is_case_sensitive		Yes	Uppercase/lowercase distinction applies.
	valid_from		Yes	UTC date-time from which this name applies.
	valid_to		No	UTC date-time until which this name applied; empty means current.
primary_trade_name	primary_name_id	PK	Yes	Primary trade name designation record.
	subject_id	FK	Yes	Registered subject.
	name_id	FK	Yes	Name designated as primary trade name.
	primary_from		Yes	UTC date-time from which this name is primary.
	primary_to		No	UTC date-time until which this name was primary; empty means current.
optional_subject_attribute	attribute_id	PK	Yes	Optional attribute record.
	subject_id	FK	Yes	Registered subject.
	attribute_name		Yes	iban, bic, account_holder_name, website_url, contact_email.
	attribute_value		No	Provided value; empty means not provided.
	consent_required		Yes	Explicit consent required before disclosure.
	valid_from		Yes	UTC date-time from which this attribute applies.
	valid_to		No	UTC date-time until which this attribute applied; empty means current.
subject_responsible	responsible_id	PK	Yes	Responsible party record identifier.
	subject_id	FK	Yes	Registered subject.
	responsible_subject_code	IDX	Yes	Subject code identifying the responsible natural person.
	responsible_name		Yes	Recorded name of the responsible party.
	responsible_role		Yes	Role of the responsible party.
	authority_to_represent		No	Indicates authority to represent the subject.
	valid_from		Yes	UTC date-time from which this responsibility applies.
	valid_to		No	UTC date-time until which this responsibility applied; empty means current.

Rules

Logging is not sufficient; values must be stored with valid_from and valid_to.
If only one trade name exists, it is automatically primary.
Where multiple trade names exist, exactly one must be primary at any given time.
For an eenmanszaak, at least one trade name must exist and exactly one must be primary.
For a BV or NV without a registered trade name, legalized_name serves as the trade name and is primary.
Optional attributes such as IBAN must be clearly optional and may require explicit consent.