Attestation Rulebook for attestations of type Ownership Attestation

• Author(s):

  • [Florin Coptil, Robert Bosch GmbH]
  • [Stephan Fuchs, Deutsche Bank AG]

• Reviewer(s):

  • [Baumgardt Michaela, Commerzbank]
  • [Ricky Lamberty, Robert Bosch GmbH]
  • @TODO Florin — Add the reviewers from attestation design (meetings UseCase, Banks, TransparentRegister)

• Contact:

  • Florin Coptil*

• Feedback:

1 Introduction

This attestation addresses the following question:

Who are the Shareholders and Economic Interest Holders of this legal entity?

A Shareholder or Economic Interest Holder is any natural person, legal entity, or legal arrangement that directly or indirectly holds an ownership stake or economic interest in a legal entity.

1.1 Document Scope and Purpose

The Ownership Attestation records all natural persons, legal entities, and legal arrangements holding direct or indirect ownership interests in a legal entity, providing comprehensive transparency on beneficial ownership structures and economic interests. This attestation is a critical component of both Know Your Customer (KYC) and Know Your Supplier (KYS) processes within the EUDI Wallet ecosystem, supporting effective risk management, regulatory compliance, and anti-money laundering (AML) obligations.

Design Decisions

This Ownership Attestation Rulebook is based on:

• AMLR – Regulation (EU) 2024/1624 of the European Parliament and of the Council of 31 May 2024 on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing.
• The EU Anti-Money Laundering Regulation (AMLR 2024/1624) as the primary regulatory driver for beneficial ownership transparency obligations
• The EUDI Wallet ecosystem and eIDAS 2 framework as the digital identity infrastructure
• The SD-JWT VC specification (draft-ietf-oauth-sd-jwt-vc-09) for verifiable credential encoding
• Regulatory Technical Standards (RTS) – Draft Regulatory Technical Standards under Article 28(1) of Regulation (EU) 2024/1624, specifying the requirements for identifying beneficial owners and the information to be collected for beneficial ownership determination.
• Beneficial Ownership Submission Regulation – Commission on Implementing Regulation (EU) [number] on the formats for submitting beneficial ownership information.
• Beneficial Ownership Data Standard (BODS) version 0.4

1.2 Document Structure

This Rulebook is structured as follows:

• Chapter 2 describes the attestation attributes and metadata in an encoding-independent manner, including the data model.
• Chapter 3 specifies how the attestation attributes and metadata are encoded: Section 3.2 covers SD-JWT VC-based encoding.
• Chapter 4 specifies attestation usage scenarios, Relying Party obligations, and integration with KYC/KYS workflows.
• Chapter 5 defines trust anchors and verification mechanisms for issuer authorization.
• Chapter 6 defines revocation mechanisms for the attestation.
• Chapter 7 provides compliance information regarding the EUDI framework and applicable data protection laws.

1.3 Keywords

This document uses the capitalised keywords SHALL, SHOULD and MAY as specified in [RFC 2119], i.e. to indicate requirements, recommendations and options specified in this document.

In addition, must (non-capitalised) is used to indicate an external constraint, i.e. a requirement that is not mandated by this document, but, for instance, by an external document. The word can indicates a capability, whereas other words, such as will, and is or are are intended as statements of fact.

1.4 Terminology

Additional terminology specific to this attestation:

2 Attestation Attributes and Metadata

The Ownership Attestation is designed to provide a complete, verifiable representation of an entity's ownership structure in a standardised digital format. This attestation supports transparency, compliance, and risk management by enabling automated verification of beneficial ownership across complex, multi-tiered corporate structures.

2.1 Introduction

The Owner model supports three distinct owner types:

• natural persons (Person),
• legal entities(Entity),
• and legal arrangements (a subtype of Entity — e.g., trusts, foundations).

Data Model:

The Owner model follows a hierarchical structure:

Owner [1..n]                                    // The person or entity that holds an interest
├─ type (enum) (M)                              // "Person" | "Entity"
├─ jurisdiction (tstr) (M)                      // ISO 3166-1 alpha-2
├─ person (O, conditional on type="Person")
│   ├─ first_name (tstr) (M)
│   ├─ surname (tstr) (M)
│   └─ birth_date (date) (O)                    // ISO 8601 YYYY-MM-DD
├─ entity (O, conditional on type="Entity")
│   ├─ category (enum) (M)                      // "legal_entity" | "legal_arrangement"
│   ├─ name (tstr) (M)
│   ├─ identifier [1..n] (M)                    // At least one identifier required
│   │   ├─ euid (str) (O)                       // European Unique Identifier
│   │   ├─ lei (str) (O)                        // Legal Entity Identifier per ISO 17442
│   │   ├─ tax (str) (O)                        // National tax or registration number
│   │   └─ other (str) (O)                      // Any other applicable identifier
│   ├─ jurisdiction (tstr) (M)                  // ISO 3166-1 alpha-2
│   ├─ legal_form (tstr) (M)                    
│   ├─ form (tstr) (M)                          // See Section 2.8.6
│   └─ subtype_info (object) (O)                // Mandatory when category = "legal_arrangement"
│       ├─ settlement (tstr) (M)                // Founding instrument or trust deed
│       ├─ purpose (tstr) (M)                   // Declared purpose of the arrangement
│       ├─ assets (tstr) (M)                    // Assets held within the arrangement
│       └─ reason_for_registration (tstr) (O)   // Optional reason for formal registration
├─ address (Address) (M)                        // Residential (Person) or registered (Entity)
│   ├─ street (tstr) (M)
│   ├─ house_number (tstr) (M)
│   ├─ locality (tstr) (M)
│   ├─ region (tstr) (M)
│   ├─ postal_code (tstr) (M)
│   └─ country (tstr) (M)                       // ISO 3166-1 alpha-2
├─ interests (M)                                // Details of the economic or control interest
│   ├─ type [enum] [1..n] (M)                   // Array — see Section 2.8.5
│   ├─ level (tstr) (M)                         // "direct" | "indirect" | "joint" | "unknown"
│   ├─ percentage (Decimal) (M)                 // Ownership percentage (0–100)
│   ├─ quantity (uint) (M)                      // Number of shares or units held
│   ├─ description (tstr) (O)                   // Free-text description of the interest
│   ├─ class (tstr) (O)                         // "ordinary" | "preferred" | "dual-class" | "other"
│   └─ rights [String] [1..n] (M)              // "dividend_rights" | "liquidation_rights"
├─ effective_date (date) (M)                    // ISO 8601 YYYY-MM-DD
└─ evidence [1..n] (M)                          // At least one evidence entry required
│  ├─ id (tstr) (M)                            // Unique identifier, URI, or URN
│  ├─ type (tstr) (M)                          // Evidence type — see Section 2.8.9
│  ├─ url (uri) (O)                            // URI to publicly accessible source document
│  └─ data (base64) (O)                        // Base64-encoded — required if url absent

Note: M - mandatory / O - optional.

Explanation:

• The attestation SHALL contain at least one Owner entry of type = "Person" to comply with AML requirements mandating identification of the natural persons who ultimately own or control the entity (Ultimate Beneficial Owners).

• The attestation MAY contain zero or more Owner entries of type = "Entity" representing intermediate legal entities or legal arrangements in the ownership chain.

• Each Owner entry SHALL include:

  • type (mandatory enum: "Person" or "Entity")
  • jurisdiction (mandatory — ISO 3166-1 alpha-2)
  • address (mandatory — residential address for Person, registered address for Entity)
  • interests (mandatory — at least one record)
  • effective_date (mandatory — date when this ownership or control became effective)
  • evidence (mandatory — at least one piece of supporting evidence)

• For each Owner of type = "Person":

  • The person object SHALL be present and the entity object SHALL be absent.
  • first_name and surname SHALL be present.
  • birth_date SHALL be present (ISO 8601 YYYY-MM-DD).
  • At least one interests record SHALL be present, including:
    • type — SHALL use values from Section 2.8.5
    • level — SHALL use values from Section 2.8.2
    • percentage — decimal value in range 0–100
    • quantity — non-negative integer
    • rights — SHALL use values from Section 2.8.3

• For each Owner of type = "Entity":

  • The entity object SHALL be present and the person object SHALL be absent.
  • category SHALL be present and SHALL be one of "legal_entity" or "legal_arrangement".
  • name SHALL be present (complete official registered name).
  • identifier SHALL contain at least one of: euid, lei, tax, or other.
  • jurisdiction SHALL be present (ISO 3166-1 alpha-2).
  • form SHALL be present and SHALL use a value from Section 2.8.6.
  • At least one interests record SHALL be present, including:
    • type — SHALL use values from Section 2.8.5
    • level — SHALL use values from Section 2.8.2
    • percentage — decimal value in range 0–100
    • quantity — non-negative integer
    • rights — SHALL use values from Section 2.8.3

• When entity.category = "legal_arrangement" OR entity.form = "trust", the subtype_info object SHALL be present and SHALL include:

  • settlement — the instrument establishing the legal arrangement
  • purpose — the declared purpose of the arrangement
  • assets — description of assets held within the arrangement
  • reason_for_registration is OPTIONAL

• Each Owner entry SHALL include at least one evidence entry. Each evidence entry SHALL include:

  • id — unique identifier, URI, or URN of the source document
  • type — SHALL use values from Section 2.8.9
  • data — base64-encoded document — SHALL be provided if url is absent or not publicly accessible

• interests.type SHALL be an array allowing multiple concurrent role types to be declared for a single owner (e.g., a person may simultaneously hold shareholding and votingRights).

• interests.level SHALL use one of: "direct", "indirect", "joint", or "unknown" as defined in Section 2.8.2.

• interests.rights SHALL be an array and SHALL use values from Section 2.8.3.

• interests.class (optional) SHALL use a value from Section 2.8.1 when applicable.

• effective_date SHALL follow ISO 8601 YYYY-MM-DD format and SHALL represent the date on which the ownership or control relationship became legally effective.

Attestation Classification:

This attestation type MAY be classified as:

• EAA within the EUBW Wallet ecosystem, when self-issued by the legal entity subject to the ownership disclosure (i.e., the entity issues an attestation about its own ownership structure).
• QEAA when issued by a qualified trust service provider (QTSP) or authorized competent body that can independently attest the ownership structure (e.g., based on official company register data, audited financial statements, or notarized documentation).

Terms primarily relevant to a Person Owner

These terms describe natural persons who hold ownership or economic interests in a legal entity.

Person Ownership Role Terms

Person Interest Detail Terms

Person Source & Evidence Terms

Terms primarily relevant to an Entity Owner (as LegalEntity or LegalArrangement)

These terms describe legal entities and legal arrangements that hold ownership or economic interests in another legal entity.

Entity Classification Terms

Entity Form Terms

Legal Arrangement Specific Terms (only when entity.category = "legal_arrangement")

Entity Ownership Role Terms

Entity Interest Detail Terms

Entity Source & Evidence Terms

2.2 Mandatory Attributes

Owner Top-Level Mandatory Attributes (applies to all Owner entries)

Person Owner Mandatory Attributes (present when type = "Person")

Entity Owner Mandatory Attributes (present when type = "Entity")

Entity Identifier Fields (at least one SHALL be present)

Legal Arrangement Additional Mandatory Attributes (present when entity.category = "legal_arrangement" or entity.form = "trust")

Address Mandatory Attributes (applies to all Owner entries)

Interests Mandatory Attributes (at least one record per Owner entry)

Evidence Mandatory Attributes (at least one entry per Owner entry)

2.3 Optional Attributes

Person Owner Optional Attributes

Legal Arrangement Optional Attributes (when entity.category = "legal_arrangement")

Interests Optional Attributes

Evidence Optional Attributes

2.4 Conditional Attributes

2.5 Mandatory Metadata

Note: Only the additional mandatory attributes are listed; the mandatory attributes defined by the protocol are not specified.

2.6 Optional Metadata

2.7 Conditional Metadata

No conditional metadata elements are defined for this attestation type.

2.8 Value Lists

2.8.1 interests.class Values

2.8.2 interests.level Values

2.8.3 interests.rights Values

2.8.4 Ownership Controller Category Codes

2.8.5 interests.type Values

2.8.6 entity.form Values

2.8.7 Country Codes

owner.jurisdiction, entity.jurisdiction, and address.country SHALL use ISO 3166-1 alpha-2 two-letter country codes.

2.8.8 Date Formats

All date attributes (e.g., effective_date, person.birth_date) SHALL follow the ISO 8601 YYYY-MM-DD format.

2.8.9 Evidence Type Values

2.9 Integrity Rules

The following integrity rules SHALL be enforced:

3 Attestation Encoding

3.1 ISO/IEC 18013-5-Compliant Encoding

ISO/IEC 18013-5 (mdoc) is out of scope for this Rulebook, as offline proximity presentation is not a current requirement for the Control Attestation.

3.2 SD-JWT VC-Based Encoding

The Ownership Attestation uses the SD-JWT VC format to allow for selective disclosure of ownership structure attributes.

Selective Disclosure: Top-level claims (owner) SHALL be individually selectively disclosable, enabling a legal entity to disclose only the attributes requested by a Relying Party. The . notation is used to indicate the nesting of attributes.

Verifiable Credential Type (vct): eu.we-build:ownership:1

3.2.1 Attribute Encoding Table

Notes:

• MUST: The claim SHALL be selectively disclosable — the holder MAY choose to disclose or withhold this claim when presenting the credential to a Relying Party.
• MUST NOT: The claim SHALL NOT be selectively disclosable — it is always present in plain text in the JWT header/payload and cannot be withheld by the holder, as it is required for credential verification and trust establishment.
• owner entries are indexed as [n] where n starts at 0; at least one owner SHALL be present, and at least one SHALL be of type = "Person".
• evidence entries within each owner are indexed as [m] where m starts at 0; at least one evidence entry SHALL be present per owner.
• iat, exp, and iss follow RFC 7519 standard JWT claim naming conventions.

3.2.2 Status Claim

For SD-JWT VC-compliant Ownership Attestations, the attestation MUST include a status claim if the technical validity period is greater than 24 hours. This claim enables Relying Parties to determine if a credential has been revoked via a status list mechanism.

The status claim SHALL be a JSON object with the following members:

Example:

{
  "status": {
    "type": "status-list",
    "status_list_credential": "https://issuer.example.com/status/ownership/2025",
    "status_list_index": 456,
    "status_purpose": "revocation"
  }
}

3.2.3 Example Payload

The following is a non-normative example of an Ownership SD-JWT VC payload demonstrating a natural person owner, a legal entity owner, and a legal arrangement owner:

{
  "vct": "eu.we-build:ownership:1",
  "iss": "https://issuer.example.com",
  "iat": 1736935200,
  "exp": 1768471200,
  "attestation_legal_category": "EAA",
  "schema_version": "0.8.0",
  "trust_anchor_url": "https://trust.webuildconsortium.eu/anchors/eidas-tl",

  "owner": [
    {
      "type": "Person",
      "jurisdiction": "DE",
      "person": {
        "first_name": "Anna",
        "surname": "Schmidt",
        "birth_date": "1978-04-15"
      },
      "address": {
        "street": "Hauptstraße",
        "house_number": "12",
        "locality": "Berlin",
        "region": "Berlin",
        "postal_code": "10115",
        "country": "DE"
      },
      "interests": {
        "type": ["shareholding"],
        "level": "direct",
        "percentage": 51.0,
        "quantity": 51000,
        "class": "ordinary",
        "rights": ["dividend_rights", "liquidation_rights"]
      },
      "effective_date": "2018-03-01",
      "evidence": [
        {
          "id": "src-001",
          "type": "officialRegister",
          "url": "https://example.com/docs/shareholder-register-2024.pdf"
        }
      ]
    },
    {
      "type": "Entity",
      "jurisdiction": "DE",
      "entity": {
        "category": "legal_entity",
        "name": "Holding GmbH",
        "identifier": {
          "euid": "DE-HRB-654321",
          "lei": "529900T8BM49AURSDO55",
          "tax": "DE987654321"
        },
        "jurisdiction": "DE",
        "form": "private_company",
        "legal_form":"GmbH"
      },
      "address": {
        "street": "Musterstraße",
        "house_number": "45",
        "locality": "Frankfurt",
        "region": "Hessen",
        "postal_code": "60311",
        "country": "DE"
      },
      "interests": {
        "type": ["shareholding", "votingRights"],
        "level": "indirect",
        "percentage": 30.0,
        "quantity": 30000,
        "class": "preferred",
        "rights": ["dividend_rights"]
      },
      "effective_date": "2019-06-15",
      "evidence": [
        {
          "id": "src-002",
          "type": "shareholderAgreement",
          "url": "https://example.com/docs/shareholder-agreement-2019.pdf"
        }
      ]
    },
    {
      "type": "Entity",
      "jurisdiction": "LU",
      "entity": {
        "category": "legal_arrangement",
        "name": "Schmidt Family Trust",
        "identifier": {
          "lei": "549300ABCDEF12345678"
        },
        "jurisdiction": "LU",
        "form": "trust",
        "subtype_info": {
          "settlement": "Settled under Luxembourg trust law on 2015-03-01",
          "purpose": "Family wealth management and succession planning",
          "assets": "Real estate, securities portfolios, and cash holdings",
          "reason_for_registration": "Registered for tax transparency under CRS"
        }
      },
      "address": {
        "street": "Rue de la Forêt",
        "house_number": "7",
        "locality": "Luxembourg",
        "region": "Luxembourg",
        "postal_code": "L-1234",
        "country": "LU"
      },
      "interests": {
        "type": ["beneficiaryOfLegalArrangement", "economicBeneficiary"],
        "level": "indirect",
        "percentage": 19.0,
        "quantity": 0,
        "rights": ["dividend_rights", "liquidation_rights"]
      },
      "effective_date": "2015-03-01",
      "evidence": [
        {
          "id": "src-003",
          "type": "trustDeed",
          "url": "https://example.com/docs/trust-deed-2015.pdf"
        }
      ]
    }
  ],

  "status": {
    "type": "status-list",
    "status_list_credential": "https://issuer.example.com/status/ownership/2025",
    "status_list_index": 456,
    "status_purpose": "revocation"
  },

  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}

Sample payloads are provided under ../data-schemas/sd-jwt/sample-data/ownership-sd-jwt-sample.json

3.3 W3C Verifiable Credentials Data Model-based encoding

4 Attestation usage

4.1. Issuance process

For EAA (Self-Issued / Standard Issuance):

• The issuer (i.e., the legal entity itself) issues the attestation based on the information and supporting documentation available at the time of issuance.
• The issuer is responsible for ensuring that the attested information remains accurate and must immediately revoke the attestation if any change occurs that affects the validity or accuracy of the underlying data.

For QEAA (Qualified Issuance):

• The issuer—either a Qualified Trust Service Provider (QTSP) or another authorized competent body—must issue and verify the attestation exclusively on the basis of authoritative sources, such as official company register data or audited financial statements.
• The issuer is also responsible for maintaining a high level of assurance throughout the attestation's validity period by continuously monitoring the underlying information. If any change affecting the accuracy or validity of the attested data is detected, the issuer must promptly revoke the attestation.

The Issuer SHALL implement the base issuer obligation as defined in the Issuer Obligation specification: https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-base/verifier-base-verification.md#41-issuer-obligations

4.2 Relying Party Obligations

When receiving and processing an attestation, the Relying Party SHALL perform the following verification obligations.

4.2.1 – 4.2.8 Base Verification Process

The Relying Party SHALL perform the base attestation verification process as defined in the Base Verification specification: https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-base/verifier-base-verification.md#42-relying-party-obligations

4.2.9 Validate Integrity Rules

Validation of integrity and policy rules will be specified in a future version of this Rulebook.

5 Trust anchors

This chapter specifies the trust anchor mechanisms used by Relying Parties to establish trust in the issuer of an Electronic Attestation of Attributes (EAA) or a Qualified Electronic Attestation of Attributes (QEAA). The corresponding verification procedures are defined in Sections 4.2.2–4.2.4.

5.1 Qualified Electronic Attestations of Attributes (QEAAs)

For QEAAs, trust is established through the X.509 Public Key Infrastructure (PKI) and the applicable Trust List of Licensees (TLOL). The issuer's certificate chain, including the intermediate certificate contained in the QEAA header, SHALL be validated up to a trusted root certificate. This validation SHALL be performed using the applicable TLOL, taking into account the trust list state applicable at the time of issuance.

Successful certificate chain validation establishes that:

• the issuer's certificate was recognized within the applicable trust framework;
• the issuer's identity has been validated by the supervisory authority during inclusion in the TLOL; and
• the issuer satisfies the trust requirements applicable to QEAAs.

In addition, the Relying Party MAY apply further authorization checks based on its internal policies, such as maintaining a whitelist of accepted QEAA providers.

5.2 Electronic Attestations of Attributes (EAAs)

For EAAs, trust is established through a cryptographic chain anchored in the Electronic Business Wallet Owner Identity Document (EBWOID). The EBWOID SHALL be included in the header of every EAA. During EBWOID issuance, the EBWOID provider verifies that the public key contained in the EBWOID is owned by the Electronic Business Wallet (EBW) owner.

The Relying Party SHALL verify the EBWOID in accordance with the verification procedure defined in this Rulebook. Upon successful verification, the Relying Party obtains:

• assurance that the EBWOID was issued by an authorized provider and is not self-issued;
• the verified identity of the issuer, including its name and EUID (or another globally unique EBW owner identifier); and
• the public key authorized to verify the EAA signature.

Authorization of the issuer is subsequently determined in accordance with the Relying Party's internal policies. Such authorization MAY be based on locally maintained wallet configuration or on trusted jurisdiction- or domain-specific trust list services that identify issuers authorized for a particular type of EAA

6 Revocation

An attestation SHALL remain valid only while its underlying information is accurate, complete, and legally effective.

6.1 Revocation Mechanism

• Token Status List: The issuer must maintain an active IETF Token Status List (aligned with the Attestation Status List mechanism specified by the EU Commission).
• Credential Metadata: The metadata status_list must be populated in every issued CompanyInfo attestation, referencing the status list URI and the credential's specific index.

Authorized Authority: Only the authorized issuer (the QTSP/competent body for QEAA, or the self-issuing legal entity for EAA) may modify the status list entry.

6.2 Revocation Triggers & Business Rules

• QEAA Trigger (Automatic): The QTSP/competent body must actively monitor official company register data and audited financial statements. Any detected discrepancy or change in the company registry must automatically trigger revocation of the QEAA.
• EAA Trigger (Manual Obligation): The self-issuing legal entity is under strict obligation to immediately update or revoke its EAA if its available documents, financial thresholds, or ownership structures change.

Relying Party Action: A revoked or suspended attestation must be treated as invalid for credential-validity purposes by all RPs. The business interpretation is determined by the Relying Party's internal compliance policies.

7 References