From 92e7c2a91d3b4255563a722c6fab8724bf5ed64e Mon Sep 17 00:00:00 2001 From: Stephen Abbott Pugh Date: Wed, 17 Jun 2026 10:19:25 +0200 Subject: [PATCH 1/2] Add semantic intake submission for Ownership/Control/UBO use case (BODS-aligned) --- .../semantic-intake-ubo-ownership-control.md | 294 ++++++++++++++++++ 1 file changed, 294 insertions(+) create mode 100644 test-drafts/semantic-intake-ubo-ownership-control.md diff --git a/test-drafts/semantic-intake-ubo-ownership-control.md b/test-drafts/semantic-intake-ubo-ownership-control.md new file mode 100644 index 0000000..5a26f8e --- /dev/null +++ b/test-drafts/semantic-intake-ubo-ownership-control.md @@ -0,0 +1,294 @@ + + +# Introduction + +This document instantiates the WE BUILD Semantic Intake template for the **beneficial-ownership** use case — the family of three closely related attestations covered by `rb-ownership`, `rb-control` and `rb-ubo`. It is a class-level model (entities, attributes, relations), and it deliberately anchors each element to the **Beneficial Ownership Data Standard (BODS) RDF Vocabulary** (`bods:` = `https://vocab.openownership.org/terms#`, `codes:` = `https://standard.openownership.org/codelists#`), reusing existing EBW Vocabulary terms (`ebwv:` = `https://w3id.org/ebwv#`) for shared identity attributes. + +The three attestations are one underlying model viewed three ways: Ownership and Control are the source relationship graph; the UBO list is a derived projection over that graph (the natural persons meeting the ≥25% ownership / control threshold). BODS represents exactly this — a graph of immutable statements about subjects, with the UBO view as a query over it — which is why it is proposed here as the reference model. + +# Use Case Overview of Beneficial Ownership (Ownership, Control & UBO) + +Purpose: Capture the story and high-level purpose of the beneficial-ownership use case. + +## Storyline + +A legal entity needs to disclose, in verifiable form, the natural persons who ultimately own or control it. It assembles two source attestations — an **Ownership** attestation (who holds direct/indirect economic interests) and a **Control** attestation (who exercises effective control, by whatever mechanism) — and from these derives a **UBO** attestation listing the natural persons above the ≥25% ownership/control threshold (or controlling by other means), as required by AMLR Article 3(17). + +These attestations are issued into the entity's company wallet — self-issued as Electronic Attestations of Attributes (EAA), or issued by a national Transparency Register / QTSP as Qualified EAAs (QEAA). A relying party (typically a bank during corporate-account KYC, or a buyer during supplier onboarding/KYS) requests them, independently recomputes the UBO set from the Ownership and Control lists (the AMLR Article 60 discrepancy cross-check), and verifies each UBO's identity against a Person Identification Data (PID) attestation. + +## Business Context / Motivation + +Identifying who ultimately owns or controls a legal entity is a foundational requirement of EU anti-money-laundering and counter-terrorist-financing law (Regulation (EU) 2024/1624 — AMLR, Articles 3(17), 20–25, 60, 62; the predecessor AMLD framework; and the proposed Implementing Act on formats for submitting beneficial-ownership information). Today this information is exchanged as unstructured documents and re-keyed at every step. A verifiable, machine-interpretable, *semantically anchored* attestation lets the same ownership facts flow — without re-keying — from the company, to obliged entities for KYC/KYS, to national Transparency Registers, and back for cross-checking. + +The semantic anchoring is the point of this submission. Without an agreed vocabulary, "25% ownership" or "control via nominee" mean whatever each issuer decides, and interoperability fails at the meaning layer even when the credential format is shared. + +## Stakeholders + +- **Issuer** — the legal entity itself (self-issued EAA), or a national Transparency Register / competent authority / QTSP (QEAA). +- **Holder** — the legal entity, via its company wallet (EU Business Wallet). +- **Verifier / Relying Party** — obliged entities performing KYC (banks, financial institutions) or KYS (procuring entities, suppliers). +- **Subject** — the legal entity whose ownership/control is described; and, for the UBO list, each natural person UBO. +- **Transparency Register / Beneficial Ownership Register** — the AMLR Article 60 register; consumer of submissions and authority for discrepancy reporting. +- **Trust Registry / governance authority** — maintains the trust list under which issuers are recognised. +- **Revocation / status service** — manages credential lifecycle (status list). + +## Expected Outcome + +When the attestations are used, a relying party can: (1) read a structured, selectively disclosable statement of ownership, control and UBOs; (2) independently recompute the UBO set from the ownership and control graph and detect discrepancies; (3) verify each UBO's identity via PID; and (4) losslessly convert the ownership/control claims to a BODS statement for register submission (AMLR Art. 60/62) and onward analysis — and back. + +By the end, modellers and implementers should understand which attributes reuse existing EU/W3C vocabulary, which reuse BODS, and which (if any) require new EBW terms. + +### Meta-purpose + +This use case is the natural test of the template's Q001/Q002 ("semantic reuse vs. semantic innovation"). It is rich enough to exercise real reuse — shared identity attributes from existing vocabulary, the full ownership/control interest model from BODS — while exposing the few genuine gaps (e.g. partnership interests) where new terms or upstream proposals may be needed. + +# Data Model or Knowledge Graph + +Purpose: Capture the entities, attributes, and relationships. + +The model mirrors the three BODS statement types: a **Subject Entity** (entity statement), an **Interested Party** that is either a **Natural Person** (person statement) or an **Intermediate Entity** (entity statement), and an **Interest** linking them (relationship statement, carrying one or more typed interests). The Interest's subject may itself be an Intermediate Entity, which is how indirect ownership chains are represented. + +```mermaid +classDiagram +direction LR +class SubjectEntity { + entityType : codes:EntityType + name + identifiers : LEI / EUID + registeredAddress : bods:Registered + incorporatedInJurisdiction +} +class NaturalPerson { + personType : codes:PersonType + names : bods:Legal + birthDate + nationalities + residenceAddress : bods:Residence +} +class IntermediateEntity { + entityType : codes:EntityType + name + identifiers : LEI / EUID + registeredAddress : bods:Registered +} +class Interest { + type : bods:InterestType + directOrIndirect : codes:DirectOrIndirect + beneficialOwnershipOrControl : boolean + share : exact / minimum / maximum + startDate +} +class Evidence { + source : bods:SourceType + url + description +} +NaturalPerson "1" --> "*" Interest : interestedParty +IntermediateEntity "1" --> "*" Interest : interestedParty +Interest "*" --> "1" SubjectEntity : subject +Interest "*" --> "1" IntermediateEntity : subject (enables indirect chains) +Interest "1" --> "*" Evidence : source +``` + +*Figure 1 — Beneficial-ownership data model, aligned to the three BODS statement types. The UBO list is a derived view: the set of `NaturalPerson` nodes whose aggregated interests meet the ≥25% threshold or constitute control by other means.* + +**Entity: SubjectEntity** — the legal entity whose ownership/control is declared. + +| Name | Description/Definition | +|--|--| +| SubjectEntity | The legal entity subject to the ownership/control/UBO disclosure. BODS *entity statement*. | + +| Attribute | Description | mandatory | private | datatype | Semantic reference (reuse → BODS) | +|--|--|--|--|--|--| +| entityType | Kind of entity (registered entity, legal entity, arrangement, state body…) | yes | no | enum | BODS `entityType.type` → `codes:RegisteredEntity` / `codes:LegalEntity` / `codes:Arrangement` / `codes:State` / `codes:StateBody` | +| name | Legal name of the entity | yes | no | string | `ebwv:legalName` ; BODS entity `name` | +| legalForm | Legal form (e.g. GmbH, SA, BV) | no | no | string | `ebwv:legalForm` | +| identifiers | LEI and/or EUID and other registry identifiers | yes | no | array | `ebwv:lei` / `ebwv:legalIdentifier` (`ebwv:Euid`) ; BODS `identifiers[]` {`id`, `scheme`, `schemeName`} | +| registeredAddress | Official registered address | yes | no | object | `ebwv:registeredAddress` ; BODS address type `bods:Registered` | +| incorporatedInJurisdiction | Jurisdiction of incorporation | no | no | object | `ebwv:jurisdiction` ; BODS `incorporatedInJurisdiction` {`name`, `code`} | + +| Relation | Description | Left Entity | Right Entity | Left Role | Right Role | Cardinality | Optional | +|--|--|--|--|--|--|--|--| +| is subject of | The entity is the subject of one or more ownership/control interests | SubjectEntity | Interest | subject | — | 1 → 0..n | no | + +**Entity: NaturalPerson** — a UBO, shareholder or controller. + +| Name | Description/Definition | +|--|--| +| NaturalPerson | A natural person holding an ownership or control interest. BODS *person statement*. | + +| Attribute | Description | mandatory | private | datatype | Semantic reference (reuse → BODS) | +|--|--|--|--|--|--| +| personType | Known / anonymous / unknown person | yes | no | enum | BODS `personType` → `codes:KnownPerson` / `codes:AnonymousPerson` / `codes:UnknownPerson` | +| given_name | First name(s) | yes | yes | string | `ebwv:givenName` ; BODS `names[].fullName` (type `bods:Legal`) | +| family_name | Surname(s) | yes | yes | string | `ebwv:familyName` ; BODS `names[]` (type `bods:Legal`) | +| birth_date | Date of birth | yes | yes | date | `ebwv:dateOfBirth` ; BODS `birthDate` | +| birthplace | Locality + country of birth | yes | yes | object | `ebwv:placeOfBirth` ; BODS address type `bods:PlaceOfBirth` | +| nationalities | Citizenship(s) | yes | yes | array | `ebwv:citizenship` ; BODS `nationalities[]` {`code`, `name`} | +| residence_address | Residential address | yes | yes | object | `ebwv:domicile` ; BODS address type `bods:Residence` | +| identity document | Passport / national ID for identity verification | yes | yes | object | Supplied via the **PID** attestation (`rb-pid`) rather than carried here — matches the Step-1 PID verification flow | + +| Relation | Description | Left Entity | Right Entity | Left Role | Right Role | Cardinality | Optional | +|--|--|--|--|--|--|--|--| +| holds interest | The person holds an ownership/control interest in the subject | NaturalPerson | Interest | interestedParty | — | 1 → 0..n | no | + +**Entity: IntermediateEntity** — an entity in an indirect ownership chain. + +| Name | Description/Definition | +|--|--| +| IntermediateEntity | A legal entity through which ownership/control is held indirectly. BODS *entity statement*; identical shape to SubjectEntity. It is simultaneously the interestedParty of one interest and the subject of others — this is how chains are expressed. | + +| Attribute | Description | mandatory | private | datatype | Semantic reference (reuse → BODS) | +|--|--|--|--|--|--| +| (as SubjectEntity) | Same attribute set as SubjectEntity | — | — | — | As above | + +| Relation | Description | Left Entity | Right Entity | Left Role | Right Role | Cardinality | Optional | +|--|--|--|--|--|--|--|--| +| holds interest | Holds an interest in a downstream entity | IntermediateEntity | Interest | interestedParty | — | 1 → 0..n | no | +| is subject of | Is itself the subject of upstream interests | IntermediateEntity | Interest | subject | — | 1 → 0..n | no | + +**Entity: Interest** — the ownership-or-control relationship (the core of the model). + +| Name | Description/Definition | +|--|--| +| Interest | A typed ownership or control interest between an interested party and a subject entity. BODS *relationship statement*, carrying one or more entries in `interests[]`. | + +| Attribute | Description | mandatory | private | datatype | Semantic reference (reuse → BODS) | +|--|--|--|--|--|--| +| type | Nature of the interest (shareholding, voting rights, board appointment, nominee, trustee…) | yes | no | enum | BODS `interests[].type` → `bods:InterestType` (see crosswalk: `bods:Shareholding`, `bods:VotingRights`, `bods:AppointmentOfBoard`, `bods:SeniorManagingOfficial`, `bods:Nominee`, `bods:Trustee`, `bods:OtherInfluenceOrControl`, …) | +| directOrIndirect | Whether held directly or via intermediates | yes | no | enum | BODS `interests[].directOrIndirect` → `codes:Direct` / `codes:Indirect` / `codes:Unknown` | +| beneficialOwnershipOrControl | Whether this interest constitutes beneficial ownership/control | yes | no | boolean | BODS `interests[].beneficialOwnershipOrControl` | +| share | Percentage held — exact or a band | yes | no | object | BODS `interests[].share` {`exact` \| `minimum`/`maximum` \| `exclusiveMinimum`/`exclusiveMaximum`} | +| startDate / endDate | Period the interest is/was held | no | no | date | BODS `interests[].startDate` / `endDate` | + +| Relation | Description | Left Entity | Right Entity | Left Role | Right Role | Cardinality | Optional | +|--|--|--|--|--|--|--|--| +| in (subject) | The entity the interest is held in | Interest | SubjectEntity / IntermediateEntity | — | subject | 0..n → 1 | no | +| by (interested party) | The party holding the interest | Interest | NaturalPerson / IntermediateEntity | — | interestedParty | 0..n → 1 | no | + +> Per the template's relation questions: the dominant flow of meaning is *interested party → subject*. Because both sides can be multiple and an entity can play both roles, the relationship is correctly modelled as its own class (the BODS relationship statement), not as an attribute on either party — which is precisely the gap in the current rulebooks, where stake is an attribute hanging off the person. + +# Workflow of the Attestation + +Purpose: Map the flow of actions, data, and interactions between entities. + +| Actor | Role | Description | +|--|--|--| +| Legal Entity | issuer (EAA) / holder | Calculates its ownership and control graph; self-issues Ownership and Control attestations; derives the UBO list; stores all three in its company wallet. | +| Transparency Register / QTSP | issuer (QEAA) | Optionally issues Ownership/Control/UBO as qualified attestations, certifying the calculation. | +| Company Wallet | wallet | Receives, stores and selectively discloses the attestations; enforces holder binding. | +| Relying Party (e.g. bank) | verifier | Requests the attestations; recomputes the UBO set from Ownership + Control (Art. 60 cross-check); verifies UBO identity via PID; handles discrepancies / applies EDD. | +| UBO | subject / PID holder | Presents a PID attestation for identity verification. | +| Trust Registry | governance authority | Establishes issuer trust status. | +| Revocation / Status Service | revocation service | Publishes credential status (revoked / active). | + +**Trigger Event:** A relying party's request for ownership/control/UBO information during KYC (corporate-account opening) or KYS (supplier onboarding); or a regulatory obligation to submit to a Transparency Register. + +**Post-condition:** The relying party holds verified, structured ownership/control/UBO data, has reconciled it against an independent calculation, and (where required) has submitted a BODS-conformant record to the register. + +```mermaid +sequenceDiagram + participant LE as Legal Entity (Holder / Wallet) + participant TR as Register / QTSP + participant RP as Relying Party (Bank, KYC) + participant U as UBO (PID holder) + LE->>LE: Calculate Ownership & Control (BODS relationship graph) + LE->>LE: Self-issue Ownership + Control EAAs + opt Register-attested + TR-->>LE: Issue Ownership / Control / UBO as QEAA + end + LE->>LE: Derive UBO list (>=25% projection over the graph) + RP->>LE: Request UBO + Ownership + Control + LE-->>RP: Present (selective disclosure) + RP->>RP: Recompute UBO from Ownership + Control (Art. 60 cross-check) + RP->>U: Request PID for identity verification (Art. 21) + U-->>RP: Present PID + RP->>RP: Verify, flag discrepancies / apply EDD +``` + +*Figure 2 — Issuance, presentation, cross-check and identity-verification flow.* + +**Notable Interactions / Dependencies:** Cross-border (the entity, its UBOs, intermediate entities and the relying party may sit in different jurisdictions — hence ISO 3166 country codes and the EUID/LEI identifier backbone); cross-domain (the same ownership facts must round-trip between the wallet/credential domain and the register/BODS domain). + +# Life Cycle of the Attestation + +Purpose: Capture how the attestation evolves over time. Two lifecycles operate in parallel and must not be conflated: the **credential** lifecycle (the VC envelope) and the **ownership-fact** lifecycle (the data). BODS handles the latter natively. + +| Stage | Description | +|--|--| +| Creation / Issuance | The legal entity (EAA) or register/QTSP (QEAA) issues the attestation once the ownership/control calculation is complete and the wallet is bound to a valid identity. In BODS terms, each fact is a statement with `statementDate` and `recordStatus: new`. | +| Usage / Presentation | Presented to relying parties with selective disclosure (SD-JWT VC). The relying party may request all three attestations to perform the Art. 60 cross-check. | +| Update / Renewal | When ownership or control changes, the entity re-issues. The *credential* gets a new validity period; the *fact* is expressed in BODS as a new statement with the same `recordId` and `recordStatus: updated`, preserving history (append-only). The UBO list is re-derived. | +| Revocation / Expiry | The *credential* is revoked or expires via the status-list mechanism (`status` claim). This is distinct from a *fact* ceasing to hold, which BODS expresses with `recordStatus: closed`. | +| Archiving / End-of-life | Prior credentials may be retained as cryptographic proof; prior BODS statements remain in the record's history for audit and for reconstructing ownership as at any past date. | + +# Requirements and Constraints + +Purpose: Capture explicit and implicit technical or policy requirements. + +## Information requirements + +| No. | Requirement | Source | Verification method | +|--|--|--|--| +| I001 | Each UBO SHALL carry the AMLR Art. 62 mandatory attributes (name, place and full date of birth, residential address, country/countries of residence, nationality, nature/extent of interest). | AMLR Art. 62 | inspect | +| I002 | The nature of each interest SHALL be expressed using a controlled vocabulary, proposed here as `bods:InterestType`. | This submission / BODS | inspect | +| I003 | Ownership percentages SHALL be expressible as an exact value or a band (min/max), to match register and Implementing-Act formats. | Proposed EU Implementing Act on BO formats; BODS `share` | inspect | +| I004 | Indirect ownership SHALL be traceable through intermediate entities, not collapsed into a single total. | AMLR Art. 3(17); BODS relationship model | review | + +## Legal and Regulatory requirements + +| No. | Requirement | Source | Verification method | +|--|--|--|--| +| L001 | The model SHALL support AMLR definitions of beneficial owner and the ≥25% threshold. | Regulation (EU) 2024/1624, Art. 3(17) | review | +| L002 | The model SHALL support submission to, and discrepancy reporting with, national Transparency Registers. | AMLR Art. 60 | review | +| L003 | Personal data (residential addresses, DOB, nationality) SHALL be minimised and selectively disclosable. | GDPR; eIDAS2 / SD-JWT VC selective disclosure | review | +| L004 | The design SHALL remain compatible with the EU Implementing Act on formats for submitting beneficial-ownership information. | Proposed Implementing Act (formats) | review | + +## Functional requirements + +| No. | Requirement | Source | Verification method | +|--|--|--|--| +| F001 | Ownership/control claims SHALL round-trip losslessly to a BODS statement and back. | This submission / BODS 0.4 | test | +| F002 | A relying party SHALL be able to recompute the UBO set from the Ownership and Control attestations. | AMLR Art. 60; `rb-ubo` §4.2.10 | test | +| F003 | The UBO list SHALL be representable as a derived projection over the ownership/control graph, not a parallel source of truth. | This submission | review | + +## Technical requirements – e.g. security, privacy, performance, usability. + +| No. | Requirement | Source | Verification method | +|--|--|--|--| +| T001 | Attribute-level selective disclosure SHALL be supported (SD-JWT VC). | `rb-ubo`/`rb-ownership`/`rb-control` §3.2 | test | +| T002 | Each enumerated value SHALL resolve to a dereferenceable IRI (`bods:` / `codes:` / `ebwv:`). | This submission | test | +| T003 | Entity identification SHALL use a consistent identifier scheme set (LEI, EUID) expressed as BODS `identifiers` {`scheme`, `schemeName`}. | GLEIF / EUID; BODS | test | + +## Operational requirements + +| No. | Requirement | Source | Verification method | +|--|--|--|--| +| O001 | A change in ownership/control SHALL trigger re-issuance and re-derivation of the UBO list. | AMLR ongoing-monitoring (Art. 25) | test | +| O002 | Historical ownership states SHALL be reconstructable (append-only fact history). | BODS `recordStatus` / `statementDate` | review | + +## Governance and trust restrictions + +| No. | Requirement | Source | Verification method | +|--|--|--|--| +| G001 | The attestation's legal category (EAA self-issued vs QEAA register/QTSP-issued) SHALL be explicit. | eIDAS2; rulebooks §2 | review | +| G002 | Provenance of each fact SHALL be recordable (official register / self-declaration / third party). | BODS `source.type` → `bods:OfficialRegister` / `bods:SelfDeclaration` / `bods:ThirdParty` | review | + +## Open Questions / Gaps – For follow-up or design iterations. + +| No. | Question | Why | +|--|--|--| +| Q-BO-001 | Adopt BODS as the reference model for the interest/ownership/control semantics, reuse existing `ebwv:` terms for shared identity attributes (person, entity, address, identifier), and define any new EBW interest terms as `ebwv:` classes aligned to BODS via `owl:equivalentClass` / `skos:closeMatch`? | This is the direct answer to template Q001/Q002 (semantic reuse vs. innovation) for this use case. | +| Q-BO-002 | "Partner in partnership structures" has no exact BODS interest type. Model via entity type `codes:Arrangement` plus a shareholding-equivalent interest, or raise an upstream BODS proposal? | A genuine gap — needs a decision and possibly coordination with Open Ownership. | +| Q-BO-003 | Reconcile the rulebooks' single-decimal `stake` (25.0–100.0) with BODS `share` as a band. EU register formats use bands. | Affects conformance with the Implementing Act and with real register data. | +| Q-BO-004 | Represent the derived UBO list as a projection/annotation over the ownership/control graph rather than a third independent dataset? | Avoids three parallel sources of truth drifting apart; matches the Art. 60 cross-check intent. | +| Q-BO-005 | "Acting in concert" / family control collapses to `bods:OtherInfluenceOrControl`, losing granularity. Accept, or capture detail in an annotation? | Trade-off between vocabulary simplicity and disclosure fidelity. | +| Q-BO-006 | Standardise EUID and LEI as BODS identifier schemes ({`scheme`, `schemeName`}) across the EBW model. | Aligns the entity-identifier backbone; GODIN/GLEIF can help define the scheme list. | +| Q-BO-007 | Keep the credential lifecycle (status list) and the ownership-fact lifecycle (BODS `recordStatus`) cleanly separated so state is not double-encoded. | Conflating them causes ambiguity about whether a fact changed or a credential was merely reissued. | From cf86b4fa6a1c5a7e0954484aeb320e982a6c8368 Mon Sep 17 00:00:00 2001 From: Stephen Abbott Pugh Date: Wed, 17 Jun 2026 12:59:23 +0200 Subject: [PATCH 2/2] Add BODS demonstrator crosswalk (worked rb-ownership example) for #58 --- test-drafts/demonstrator-bods-crosswalk.md | 267 +++++++++++++++++++++ 1 file changed, 267 insertions(+) create mode 100644 test-drafts/demonstrator-bods-crosswalk.md diff --git a/test-drafts/demonstrator-bods-crosswalk.md b/test-drafts/demonstrator-bods-crosswalk.md new file mode 100644 index 0000000..7bb71c2 --- /dev/null +++ b/test-drafts/demonstrator-bods-crosswalk.md @@ -0,0 +1,267 @@ + + +# Demonstrator: an Ownership attestation expressed in BODS + +This takes the rulebook's own non-normative example (`rb-ownership` §3.2.3) and renders the identical facts as a set of **BODS v0.4 statements**. The point is to make concrete what the current flat model cannot express — in particular an *indirect ownership chain* — and to show field-by-field how the empty **Semantic Reference** column would be filled. + +The BODS layer is the *payload* semantics only. The SD-JWT VC envelope (`vct`, selective disclosure, status list, trust anchor, holder binding) is unchanged and sits around it exactly as today. + +## The scenario + +`rb-ownership` §3.2.3 describes the ownership of one company by two owners: + +| Owner | Direct | Indirect | Total | Category | +|---|---|---|---|---| +| John Doe (natural person) | 25% | 10% | 35% | Direct shareholder | +| Acme Holdings Inc. (legal person) | 50% | 0% | 50% | Direct shareholder | + +The sample records John Doe's indirect 10% via an opaque list — `legal_person_id: ["DE12.HRB1212", "12345678901234567890"]` — with no way to say *how* the 10% arises. We make it concrete and arithmetically consistent: John Doe holds **40% of an intermediate holding company**, which in turn holds **25% of the subject** → 40% × 25% = **10% indirect**, giving **35% total**. Subject company: *Acme Manufacturing GmbH*. Intermediate: *Doe Holding BV*. + +## A. Before — the rulebook representation (trimmed) + +From `rb-ownership` §3.2.3, the natural-person owner: + +```json +{ + "vct": "eu.we-build.ownership.1", + "ownership": [ + { + "natural_person": { + "family_name": "Doe", + "given_name": "John", + "birth_date": "1980-01-15", + "natural_person_identifier": { "document_type": "Passport", "document_number": "P12345678", "issuing_country": "USA" }, + "residence_address": { "address": "123 Main St", "locality": "Anytown", "postal_code": "12345", "region": "CA", "country": "USA" }, + "stake": { + "direct_ownership": 25.00, + "indirect_ownership": 10.00, + "total_ownership": 35.00, + "legal_person_id": ["DE12.HRB1212", "12345678901234567890"], + "ownership_category": "Direct shareholder" + } + } + } + ] +} +``` + +What this representation cannot say: + +- **How the 10% indirect arises.** `legal_person_id` lists two identifiers with no structure — no percentages on the intermediate links, no direction of flow, no way to distinguish "the chain runs through these" from "these are co-owned." +- **Direct vs indirect as a property of the interest.** It is baked into `total_ownership` arithmetic rather than typed. +- **A range instead of a point.** `stake` is a single decimal; banded disclosures (common in registers) can't be represented. +- **Provenance per fact, and history.** No per-fact source; no append-only change model. + +## B. After — the same facts as BODS v0.4 + +Eight statements: three entity statements, one person statement, four relationship statements. Concatenated, they form one BODS dataset (a JSON array, or JSON Lines). IDs here are readable slugs for legibility; in production these are globally unique (UUID/ULID or content-hashed). Optional statement-grouping fields (`declaration`, `declarationSubject`) are omitted for readability. + +**Entity statements** + +```json +{ + "statementId": "stmt-entity-acme-mfg-0001", + "recordId": "acme-manufacturing-gmbh", + "recordStatus": "new", + "statementDate": "2024-01-15", + "recordDetails": { + "entityType": { "type": "registeredEntity" }, + "name": "Acme Manufacturing GmbH", + "incorporatedInJurisdiction": { "name": "Germany", "code": "DE" }, + "identifiers": [ + { "id": "529900T8BM49AURSDO55", "scheme": "XI-LEI", "schemeName": "Global Legal Entity Identifier Index" }, + { "id": "DEK1101R.HRB12345", "schemeName": "EUID" } + ], + "foundingDate": "2010-03-01", + "addresses": [ { "type": "registered", "address": "Hauptstrasse 5, 10115 Berlin", "country": "DE" } ] + }, + "source": { "type": ["selfDeclaration"] } +} +``` + +```json +{ + "statementId": "stmt-entity-doe-holding-0001", + "recordId": "doe-holding-bv", + "recordStatus": "new", + "statementDate": "2024-01-15", + "recordDetails": { + "entityType": { "type": "registeredEntity" }, + "name": "Doe Holding BV", + "incorporatedInJurisdiction": { "name": "Netherlands", "code": "NL" }, + "identifiers": [ + { "id": "7245001BLPDQU2UTPS66", "scheme": "XI-LEI", "schemeName": "Global Legal Entity Identifier Index" }, + { "id": "NLNAR.812345678", "schemeName": "EUID" } + ], + "addresses": [ { "type": "registered", "address": "Keizersgracht 1, 1015 Amsterdam", "country": "NL" } ] + }, + "source": { "type": ["selfDeclaration"] } +} +``` + +```json +{ + "statementId": "stmt-entity-acme-holdings-0001", + "recordId": "acme-holdings-inc", + "recordStatus": "new", + "statementDate": "2024-01-15", + "recordDetails": { + "entityType": { "type": "registeredEntity" }, + "name": "Acme Holdings Inc.", + "incorporatedInJurisdiction": { "name": "United States", "code": "US" }, + "identifiers": [ + { "id": "5493001KJTIIGC8Y1R12", "scheme": "XI-LEI", "schemeName": "Global Legal Entity Identifier Index" } + ], + "addresses": [ { "type": "registered", "address": "789 Corporate Blvd, Dover, DE 19901", "country": "US" } ] + }, + "source": { "type": ["selfDeclaration"] } +} +``` + +**Person statement** + +```json +{ + "statementId": "stmt-person-john-doe-0001", + "recordId": "person-john-doe", + "recordStatus": "new", + "statementDate": "2024-01-15", + "recordDetails": { + "personType": "knownPerson", + "names": [ { "type": "individual", "fullName": "John Doe" } ], + "birthDate": "1980-01-15", + "nationalities": [ { "code": "US", "name": "United States" } ], + "addresses": [ { "type": "residence", "address": "123 Main St, Anytown, CA 12345", "country": "US" } ], + "identifiers": [ { "id": "P12345678", "scheme": "US-PASSPORT", "schemeName": "Passport" } ] + }, + "source": { "type": ["selfDeclaration"] } +} +``` + +**Relationship statements** + +```json +{ + "statementId": "stmt-rel-doe-acme-direct-0001", + "recordId": "rel-doe-acme-direct", + "recordStatus": "new", + "statementDate": "2024-01-15", + "recordDetails": { + "subject": { "describedByEntityStatement": "stmt-entity-acme-mfg-0001" }, + "interestedParty": { "describedByPersonStatement": "stmt-person-john-doe-0001" }, + "interests": [ + { "type": "shareholding", "directOrIndirect": "direct", "beneficialOwnershipOrControl": true, "share": { "exact": 25 }, "startDate": "2019-06-01" } + ] + }, + "source": { "type": ["selfDeclaration"] } +} +``` + +```json +{ + "statementId": "stmt-rel-doe-holding-0001", + "recordId": "rel-doe-doeholding", + "recordStatus": "new", + "statementDate": "2024-01-15", + "recordDetails": { + "subject": { "describedByEntityStatement": "stmt-entity-doe-holding-0001" }, + "interestedParty": { "describedByPersonStatement": "stmt-person-john-doe-0001" }, + "interests": [ + { "type": "shareholding", "directOrIndirect": "direct", "beneficialOwnershipOrControl": true, "share": { "exact": 40 } } + ] + }, + "source": { "type": ["selfDeclaration"] } +} +``` + +```json +{ + "statementId": "stmt-rel-holding-acme-0001", + "recordId": "rel-doeholding-acme", + "recordStatus": "new", + "statementDate": "2024-01-15", + "recordDetails": { + "subject": { "describedByEntityStatement": "stmt-entity-acme-mfg-0001" }, + "interestedParty": { "describedByEntityStatement": "stmt-entity-doe-holding-0001" }, + "interests": [ + { "type": "shareholding", "directOrIndirect": "direct", "beneficialOwnershipOrControl": true, "share": { "exact": 25 } } + ] + }, + "source": { "type": ["selfDeclaration"] } +} +``` + +```json +{ + "statementId": "stmt-rel-acmeholdings-acme-0001", + "recordId": "rel-acmeholdings-acme", + "recordStatus": "new", + "statementDate": "2024-01-15", + "recordDetails": { + "subject": { "describedByEntityStatement": "stmt-entity-acme-mfg-0001" }, + "interestedParty": { "describedByEntityStatement": "stmt-entity-acme-holdings-0001" }, + "interests": [ + { "type": "shareholding", "directOrIndirect": "direct", "beneficialOwnershipOrControl": true, "share": { "exact": 50 } } + ] + }, + "source": { "type": ["selfDeclaration"] } +} +``` + +## The key difference: the UBO figure is derived, not stored + +John Doe's effective interest in Acme Manufacturing GmbH — **25% direct + (40% × 25%) = 35%** — is *computed by traversing the graph*, not held in a `total_ownership` field that can silently drift from the underlying holdings. The two intermediate links (Doe → Doe Holding 40%; Doe Holding → Acme 25%) are explicit and individually verifiable. This is exactly the `rb-ubo` model in reverse: the UBO list is a projection over the ownership/control graph, and here the graph is represented natively. + +(If a publisher wants to *assert* the aggregate as well, BODS permits an additional relationship statement: John Doe → Acme Manufacturing, `directOrIndirect: "indirect"`, `share: { "exact": 10 }` — the computed indirect portion — alongside the constituent links. Storing it is optional; deriving it is always possible.) + +## Field-by-field mapping + +| Rulebook field (`rb-ownership`) | BODS location | Note | +|---|---|---| +| `natural_person.given_name` / `family_name` | person `names[].fullName` (type `individual` → `bods:Legal`) | reuse `ebwv:givenName` / `ebwv:familyName` | +| `natural_person.birth_date` | person `birthDate` | reuse `ebwv:dateOfBirth` | +| `natural_person.residence_address` | person `addresses[]` (type `residence` → `bods:Residence`) | reuse `ebwv:domicile` | +| `natural_person_identifier` (passport) | person `identifiers[]` {`id`, `scheme`, `schemeName`} | via PID attestation in practice (`rb-pid`) | +| `legal_person.legal_entity_name` | entity `name` | reuse `ebwv:legalName` | +| `legal_person.legal_form_type` | entity `entityType` (+ free-form) | reuse `ebwv:legalForm` | +| `legal_person.identifier.lei` / `.euid` | entity `identifiers[]` {`scheme: XI-LEI`} / {`schemeName: EUID`} | reuse `ebwv:lei` / `ebwv:legalIdentifier` | +| `legal_person.registered_address` | entity `addresses[]` (type `registered` → `bods:Registered`) | reuse `ebwv:registeredAddress` | +| `stake.ownership_category` | relationship `interests[].type` | → `bods:InterestType` (crosswalk below) | +| `stake.direct_ownership` / `indirect_ownership` | relationship `interests[].directOrIndirect` + `share` | direct/indirect becomes a *typed property*, not arithmetic | +| `stake.total_ownership` | *derived* by graph traversal | not stored — see above | +| `stake.legal_person_id` (chain) | the graph of entity + relationship statements | the opaque list becomes explicit linked statements | +| `evidence[]` | statement `source` {`type`, `url`, `description`} → `bods:SourceType` | per-fact provenance | + +## Interest-type crosswalk (values used here) + +| `ownership_category` | BODS `interests[].type` (JSON) | RDF class | +|---|---|---| +| Direct shareholder | `shareholding` + `directOrIndirect: direct` | `bods:Shareholding` + `codes:Direct` | +| Indirect shareholder | `shareholding` + `directOrIndirect: indirect` | `bods:Shareholding` + `codes:Indirect` | + +(The full mapping for `control_mechanism` and `determination_methodology` is in issue #58.) + +## What BODS adds, shown by this example + +- **The indirect chain is explicit and verifiable** — three statements (Doe → Doe Holding → Acme) instead of an opaque two-element ID list. +- **Direct/indirect is typed** on the interest (`codes:Direct` / `codes:Indirect`), not inferred from totals. +- **`share` is a range** (`exact` here, but `minimum`/`maximum` available) — matches banded register and Implementing-Act formats. +- **Provenance is per fact** (`source.type` → `bods:OfficialRegister` / `bods:SelfDeclaration` / …) and **history is append-only** (`recordId` + `recordStatus` new/updated/closed). +- **The UBO list becomes a query** over this graph rather than a third, independently-maintained dataset that can drift. + +## Round-trip + +Because every rulebook field maps to a defined BODS location, an Ownership attestation round-trips to a BODS statement set and back without loss — which is what enables AMLR Art. 60/62 register submission and the `rb-ubo` §4.2.10 cross-check from the same wallet-held data. The credential envelope is untouched; only the payload gains agreed semantics. Existing open-source converters (the `bods-*` family) already perform this class of mapping for other formats. + +## Using this exhibit + +This is a discussion artefact, not a normative change. It pairs with issue #58 and PR #59. Suggested use: attach to the PR (or place alongside the intake submission under `test-drafts/`) and walk through the before/after at a semantics-group session as the concrete basis for deciding whether to adopt BODS as the reference model for the ownership/control/UBO semantics. + +*Illustrative identifiers (LEIs, EUIDs, passport number) are fictional; identifier `scheme` codes follow the org-id.guide list that BODS references and should be validated against it.*