Skip to content

Implementation report: BODS v0.4 adopted as a design foundation of the European Business Wallet (WE BUILD) Ownership and UBO attestations #763

Description

@StephenAbbott

Summary

The WE BUILD Consortium — the EU large-scale pilot designing the European Business Wallet (EBW) under eIDAS 2, led by the Dutch Ministry of Economic Affairs, KVK (Netherlands) and Bolagsverket (Sweden), with the KYC use case led by Bundesanzeiger and developed with Deutsche Bank Corporate Bank — published v1.0 of its Ownership and UBO attestation rulebooks on 23 July 2026. These define the verifiable credentials (SD-JWT VC) that companies will hold in their business wallets to prove who owns and controls them during KYC/KYB checks.

Both rulebooks explicitly list "Beneficial Ownership Data Standard (BODS) version 0.4" as a design foundation, and the Ownership attestation's interest-type codelist is drawn directly from the BODS v0.4 interestType codelist (13 of its 15 codes are verbatim BODS codes). I'm opening this issue to (a) flag a significant adoption of BODS in EU digital identity infrastructure, (b) record where the implementation diverges from BODS, and (c) surface a few items the BODS team may want to consider for the feature tracker.

First public demos are at the Global Digital Collaboration Conference in Geneva on 3 September 2026.

Evidence of adoption

  • Design Decisions (§1.1) of both rulebooks list seven foundational inputs: AMLR (EU) 2024/1624, the draft RTS under AMLR Art. 28(1), the Beneficial Ownership Submission Implementing Regulation, the EUDI Wallet / eIDAS 2 framework, SD-JWT VC (draft-ietf-oauth-sd-jwt-vc-09) — and BODS v0.4, the only non-EU, non-protocol standard on the list.
  • Version history records two BODS alignment rounds: v0.7 (24.06.2026) "Updates of content based on the submission regulation and AMLR/RTS and BODS vocabulary" and v0.8 (29.06.2026) "Updates of BODS vocabulary".
  • Interest-type codelist (§2.8.5): 15 codes, of which 13 are verbatim BODS v0.4 interestType values, in BODS camelCase (v0.3 used hyphenated codes), including two codes that only exist as of v0.4 (controlViaCompanyRulesOrArticles, controlByLegalFramework) — so this is unambiguously current BODS: shareholding, votingRights, appointmentOfBoard, otherInfluenceOrControl, seniorManagingOfficial, settlor, trustee, protector, beneficiaryOfLegalArrangement, rightsGrantedByContract, conditionalRightsGrantedByContract, controlViaCompanyRulesOrArticles, controlByLegalFramework
  • Other aligned structures: an ownership level enum of direct/indirect/unknown (plus a WE BUILD addition, joint); person/entity owner split with legal arrangements (trusts, foundations) as an entity subtype; and UBO-rulebook legal-arrangement role codes (arrangement_settlor, arrangement_trustee, arrangement_protector, arrangement_beneficiary, …) that mirror the BODS arrangement interest types.

Where the implementation diverges from BODS

For anyone mapping between EBW attestations and BODS data, the notable differences:

Area WE BUILD Ownership attestation BODS v0.4
Nominees nomineeShareholding (single code) nominee / nominator interest types
Economic benefit economicBeneficiary (single code) rightsToProfitOrIncome, enjoymentAndUseOfAssets, rightToProfitOrIncomeFromAssets
Codes not adopted boardMember, boardChair, unknownInterest, unpublishedInterest, rightsToSurplusAssetsOnDissolution, nominee, nominator and others
Share values Single mandatory decimal percentage (0–100) + mandatory quantity per interest share optional per interest; exact plus minimum/maximum/exclusive bounds for ranges and banded regimes
Unknowns No way to express unknown/withheld interests unknownInterest, unpublishedInterest
Structure Flat array of owners inside one credential; indirect chains flattened (a "Legal Entity Identifier Chain" concept exists in terminology only) Relationship statements as first-class objects; chains modelled link by link
History Attestation revocation + re-issuance (wallet-native) Append-only statements with recordId/recordStatus lifecycle
Semantic references BODS named as design foundation, but no machine-readable references to the BODS RDF vocabulary (vocab.openownership.org) IRIs

Two of these (mandatory percentage/quantity for non-share interests like trustees, and the loss of unknownInterest/unpublishedInterest) are data-quality risks I'm feeding back to the WE BUILD team directly.

Items the BODS team may want to consider

  1. Candidate feature material flowing the other way. The EBW attestation includes structures BODS lacks and that implementers evidently wanted: a structured evidence typology (officialRegister, selfDeclaration, thirdPartyVerification, trustDeed, shareholderAgreement, articlesOfAssociation, governanceChart), a joint ownership level, share classes (ordinary/preferred/dual-class) and economic rights (dividend_rights, liquidation_rights). These could be framed as problem statements for the feature tracker when development resumes.
  2. The two renamed codes suggest naming friction. WE BUILD coined nomineeShareholding and economicBeneficiary rather than using the BODS codes covering the same ground — possibly a discoverability/granularity issue with nominee/nominator and the three profit/enjoyment codes worth noting for future codelist review.
  3. Guidance opportunity: BODS in verifiable credentials. This is (to my knowledge) the first major adoption of BODS codelists inside a W3C-style verifiable credential / SD-JWT ecosystem. Short non-normative guidance on profiling BODS for credential/wallet contexts (what to keep mandatory, how revocation maps to recordStatus, how selective disclosure interacts with statement integrity) would help this and future implementers — the EU Business Wallet will put these semantics in front of every company in the EU.
  4. RDF vocabulary citation. The adoption is at codelist level; the rulebooks do not yet cite vocab.openownership.org IRIs machine-readably. I have an open proposal and PR with WE BUILD's semantics group to add these (links below) — support or co-signature from Open Ownership would strengthen it.

Links

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions