Attestation Rulebook for attestations of type IBAN Ownership Verification

Category: non-qualified EAA

• Author(s):

  • [Ricky Lamberty, Robert Bosch GmbH]
  • [Stephan Fuchs, Deutsche Bank AG]

• Previous Authors:

• Reviewer(s):

  • [Florin Coptil, Robert Bosch GmbH]
  • [Stefan, Kauhaus, Visa Inc.]
  • [Ivan Faltus, BankID.CZ]
  • [Filip Hladký, BankID.CZ]
  • @Reviewers: Contact Ricky to be added in the Reviewers section if you're missing.

• Contact:

  • Ricky Lamberty
  • Stephan Fuchs

• Feedback:

Written against: ARF version 3.0.0, WE BUILD template version 1.0 (generic)

Feedback: GitHub issues

Table of contents

• 1 Introduction
  • 1.1 Document scope and purpose
  • 1.2 Document structure
  • 1.3 Key words
  • 1.4 Terminology
• 2 Compliance
  • 2.1 Compliance statement
  • 2.2 Regulatory basis
  • 2.3 Traceability
• 3 Attestation attributes
  • 3.1 Introduction
  • 3.2 Mandatory attributes
  • 3.3 Optional attributes
  • 3.4 Conditional attributes
• 4 Metadata
  • 4.1 Mandatory metadata
  • 4.2 Optional metadata
  • 4.3 Conditional metadata
  • 4.4 Code lists
  • 4.5 Integrity rules
• 5 Formats
  • 5.1 SD-JWT VC-based encoding
  • 5.2 ISO/IEC 18013-5-compliant encoding
  • 5.3 W3C Verifiable Credentials Data Model-based encoding
• 6 Protocols
• 7 Issuance
  • 7.1 Binding
  • 7.2 Issuance Policy
  • 7.3 Lifecycle management
  • 7.4 Embedded disclosure policy
• 8 Revocation
• 9 Presentation
  • 9.1 Presentation Policy
  • 9.2 Presentation modes
  • 9.3 Transactional data
• 10 Trust Framework
• 11 References

1 Introduction

This attestation addresses the following question:

Is a specific IBAN legally owned by a designated legal entity or natural person, and has this ownership been verified and confirmed by the account-servicing financial institution?

The IBAN Ownership Verification (IBAN-OV) Attestation provides trusted assurance to third parties that a specific IBAN is legally owned by a designated legal entity or natural person (e.g. acting as a sole trader), enabling structured and fraud-resistant exchange of bank account ownership data for use in KYS, KYC, and payment compliance processes.

1.1 Document scope and purpose

The IBAN-OV attestation provides trusted assurance to third parties that a specific IBAN is legally owned by a designated legal entity or natural person. This verified proof of ownership can be used across various business processes (e.g. onboarding process, supporting payment-related triggers) to reduce errors and mitigate fraud risks. This attestation will not be used to initiate or execute any kind of payment.

The IBAN-OV attestation will be provided within the RP registration process (e.g. bank account opening) or upon request from the legal entity or natural person owning the IBAN account. Its purpose is to ensure that, at a later stage, payments for delivered services or sold products can be properly attributed to the verified legal entity or natural person.

Once issued and securely stored in the EBW wallet, the IBAN-OV attestation can be reused for multiple transactions as long as it will not be revoked. This increases operational efficiency while ensuring continued compliance with banking regulations and applicable legal standards.

Design Decisions

This IBAN-OV Attestation Rulebook is based on:

• IBAN Attestation Data Rulebook from EWC: https://github.com/EWC-consortium/eudi-wallet-rulebooks-and-schemas/blob/main/rulebooks/rb003_IBAN_attestation.md
• PSD2 / PSD3 framework as the foundational payment services regulatory layer
• ISO 13616:2020 for IBAN formatting and validation
• ISO 9362:2022 for BIC/SWIFT code formatting
• ISO 4217:2015 for currency codes
• ISO 3166-1 for country codes (Alpha-3)

1.2 Document structure

This Rulebook follows the generic WE BUILD attestation rulebook template. Chapter 2 states how it complies with the ARF and the applicable Regulations. Chapters 3 and 4 define the attributes and metadata in an encoding-independent manner. Chapter 5 states the formats in which this attestation is issued. Chapters 6 to 9 cover protocols, issuance, revocation and presentation. Chapter 10 sets out the trust framework, and chapter 11 lists references.

1.3 Key words

This document uses the capitalised key words 'SHALL', 'SHOULD' and 'MAY' as specified in [RFC 2119], to indicate requirements, recommendations and options.

In addition, 'must' (non-capitalised) indicates an external constraint, a requirement not mandated by this document but by an external document. The word 'can' indicates a capability. Other words such as 'will', 'is' and 'are' are statements of fact.

1.4 Terminology

Additional terminology specific to this attestation:

2 Compliance

2.1 Compliance statement

This Rulebook complies with the applicable requirements of Topic 12, Attestation Rulebooks, in Annex 2 of the Architecture and Reference Framework, version 3.0.0. It uses the terminology of Annex 1 of the ARF.

2.2 Regulatory basis

This attestation is not a qualified electronic attestation of attributes. The data described in Annex V points b, c and e of Regulation (EU) 2024/1183 is addressed as required by EW-DM-12-018 and as recommended by EW-DM-12-020 and EW-DM-12-022. Where a recommendation is not followed, the reason is stated below.

2.3 Traceability

Every applicable requirement mapped to the section that satisfies it. Requirements marked not applicable carry a stated reason.

3 Attestation attributes

Attributes are defined here in an encoding-independent manner (EW-DM-12-007). The encoding of each attribute is given in chapter 5.

3.1 Introduction

The IBAN-OV Attestation is a document that provides verified information about the bank account details of the account owner. It ensures that a legal entity (or natural person) can confidentially prove to a third party that this IBAN also belongs to the same legal entity (or natural person).

Data Model:

IBAN-OV Attestation
│
├── Bank_Account 				(m)
│ ├── account_name				(m)
│ ├── iban						(m)
│ ├── national_account_number	(o)
│ ├── account_type				(m)
│ └── account_currency			(m)
│
├── Account_Ownership 			(m)
│ ├── owner_type 				(m)
│ ├── owner_name				(m)		(mandatory if legal person, 'entity')
│ ├── legal_person_identifiers	(m)     (array of objects, mandatory if 'entity')
│ │   ├── type					(m)
│ │   └── value					(m)
│ ├── given_name				(m)		(mandatory if natural person, 'person')
│ └── surname					(m)		(mandatory if natural person, 'person')
│
└── Account_Provider			(m)
  ├── provider_name				(m)
  ├── legal_person_identifiers	(m)     (array of objects)
  │   ├── type					(m)
  │   └── value					(m)
  ├── provider_country			(m)
  ├── bic_swift					(m)
  ├── national_bank_code		(o)	
  ├── nace_code					(o)	
  └── clearing_number			(o)

Explanation:

• Bank_Account contains the core details of the account itself, such as IBAN, currency, and type.
• Account_Ownership identifies the legal owner of the account, including name and an array of flexible company identifiers (e.g., EUID, LEI, TAX) to accommodate global entities.
• Account_Provider describes the financial institution that issued the account (also utilizing flexible identifiers) and metadata about the attestation.

This structure effectively separates the what (the bank account), the who (the bank account owner) and the where & how (the provider & metadata).

Attestation Classification:

This attestation type MAY be classified as:

• "EAA" when issued by the bank (ASPSP) acting as an authorized issuer within the EUDI framework according to ETSI 119 478.

3.2 Mandatory attributes

Bank_Account Mandatory Attributes

Account_Ownership Mandatory Attributes

Account_Provider Mandatory Attributes

3.3 Optional attributes

Account_Provider Optional Attributes

3.4 Conditional attributes

The following conditional attributes are defined for the Account_Ownership object. Their presence is mandatory or prohibited depending on the value of owner_type:

• owner_name and legal_person_identifiers SHALL be present if and only if owner_type = 'entity'.
• given_name and surname SHALL be present if and only if owner_type = 'person'.
• given_name and surname SHALL NOT be present when owner_type = 'entity'.

This conditional structure is enforced via JSON Schema if/then validation (Draft 2020-12) in the accompanying data schema.

4 Metadata

Metadata describes the attestation rather than its subject.

4.1 Mandatory metadata

Legal category. This Rulebook retains the attestation_legal_category attribute. Section 4.1 of the generic template replaces it with the category attribute of [ETSI TS 119 472-1], whose value for this category is eaa:eu:non-qualified. EW-DM-12-029, legacy ARB_25, of ARF version 3.0.0 is a SHALL that still requires attestation_legal_category, so the template and the ARF disagree. The attribute is left as written and the deviation is recorded for the rulebook quality assurance group.

4.2 Optional metadata

4.3 Conditional metadata

No conditional metadata elements are defined for this attestation type.

4.4 Code lists

4.4.1 Currency Codes

The account_currency attribute SHALL follow ISO 4217:2015 currency codes.

4.4.2 Account Type Codes

The account_type attribute SHOULD use one of the following standardized values:

4.4.3 Owner Type Codes

4.5 Integrity rules

The following integrity rules SHALL be enforced:

• The IBAN-OV attestation SHALL be cryptographically bound and issued exclusively to the specific Holder wallet that was onboarded by the Issuer (the bank).
• expiry_date SHALL be dated after the issuance_date.
• iban SHALL conform to the ISO 13616:2020 format: [A-Z]{2}[0-9A-Z]{13,30}.
• bic_swift SHALL conform to the ISO 9362:2022 format: [A-Z]{6}[A-Z0-9]{2}([A-Z0-9]{3}).
• provider_country SHALL be a valid ISO 3166-1 alpha-3 country code.
• account_currency SHALL contain at least one valid ISO 4217:2015 currency code.
• legal_person_identifiers in Account_Provider SHALL be present, be an array, and contain at least one valid identifier object with type and value identifying the issuing financial institution.
• If owner_type = entity, legal_person_identifiers in Account_Ownership SHALL be present, be an array, and contain at least one valid identifier object with type and value identifying the account owner.
• Each attribute SHALL appear at most once in the attestation.
• owner_type in Account_Ownership SHALL be present and SHALL contain exactly one of the values entity or person.
• If owner_type = entity, owner_name SHALL be present and given_name and surname SHALL NOT be present.
• If owner_type = person, given_name and surname SHALL both be present and owner_name SHALL NOT be present.
• The attestation SHALL NOT be used to directly initiate or execute payments.

5 Formats

5.1 SD-JWT VC-based encoding

The IBAN-OV attestation uses the SD-JWT VC format to allow for selective disclosure of account attributes.

Selective Disclosure: Top-level claims (bank_account, account_ownership, account_provider) SHALL be individually selectively disclosable, enabling the account holder to disclose only the attributes requested by a Relying Party.

The . notation is used to indicate the nesting of attributes.

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

5.1.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.
• iat, exp, and iss follow RFC 7519 standard JWT claim naming conventions.

5.1.2 Status Claim

For SD-JWT VC-compliant IBAN-OV 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, as specified in SD-JWT VC.

The status claim SHALL be a JSON object containing a status_list member with the following fields:

• idx (integer, >= 0): The zero-based index into the status list bitstring that corresponds to this credential.
• uri (string, URI): The URI of the Status List Token that contains the status bitstring for this credential.

This structure follows the Token Status List specification as defined in [draft-ietf-oauth-status-list-21]: https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/21/

Example:

{
  "status": {
    "status_list": {
      "idx": 456,
      "uri": "https://issuer.example.com/status/iban-ov/2026"
    }
  }
}

5.1.3 Example Payload

The following is a non-normative example of an IBAN-OV SD-JWT VC payload for a legal person:

{
  "vct": "eu.we-build:iban-ov:1",
  "iss": "https://bank.example.com",
  "iat": 1736935200,
  "exp": 1768471200,
  "issuing_entity": "did:example:bank-123",
  "attestation_legal_category": "EAA",
  "schema_version": "1.0",
  "bank_account": {
    "account_name": "Company A Main Account",
    "iban": "DE89370400440532013000",
    "account_type": "CURRENT",
    "account_currency": ["EUR"]
  },
  "account_ownership": {
    "owner_type": "entity",
    "owner_name": "Company A GmbH",
    "legal_person_identifiers": [
      {
        "type": "EUID",
        "value": "DE-HRB-123456"
      },
      {
        "type": "LEI",
        "value": "529900T8BM49AURSDO55"
      },
      {
        "type": "TAX",
        "value": "123/456/7890"
      }
    ]
  },
  "account_provider": {
    "provider_name": "Example Bank AG",
    "legal_person_identifiers": [
      {
        "type": "EUID",
        "value": "DE12121.HRB654321"
      },
      {
        "type": "BIC",
        "value": "DEUTDEDB"
      },
      {
        "type": "LEI",
        "value": "529900XYZ123ABCDEF99"
      }
    ],
    "provider_country": "DEU",
    "bic_swift": "DEUTDEDB",
    "national_bank_code": "37040044",
    "nace_code": "64.19",
    "clearing_number": "37040044"
  },
  "status": {
    "status_list": {
      "idx": 456,
      "uri": "https://bank.example.com/status/iban-ov/2025"
    }
  }
}

The following is a non-normative example of an IBAN-OV SD-JWT VC payload for a natural person (sole trader):

{
  "vct": "eu.we-build:iban-ov:1",
  "iss": "https://bank.example.com",
  "iat": 1736935200,
  "exp": 1768471200,
  "issuing_entity": "did:example:bank-123",
  "attestation_legal_category": "EAA",
  "schema_version": "1.0",
  "bank_account": {
    "account_name": "Maria Müller Consulting",
    "iban": "DE89370400440532013001",
    "account_type": "CURRENT",
    "account_currency": ["EUR"]
  },
  "account_ownership": {
    "owner_type": "person",
    "given_name": "Maria",
    "surname": "Müller"
  },
  "account_provider": {
    "provider_name": "Example Bank AG",
    "legal_person_identifiers": [
      {
        "type": "EUID",
        "value": "DE1212.HRB654321"
      },
      {
        "type": "BIC",
        "value": "DEUTDEDB"
      }
    ],
    "provider_country": "DEU",
    "bic_swift": "DEUTDEDB",
    "national_bank_code": "37040044",
    "nace_code": "64.19",
    "clearing_number": "37040044"
  },
  "status": {
  "status_list": {
    "idx": 457,
    "uri": "https://bank.example.com/status/iban-ov/2026"
  }
}

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

5.2 ISO/IEC 18013-5-compliant encoding

ISO/IEC 18013-5 (also called mdoc) is out of scope for this Rulebook, as offline proximity presentation is not a current requirement for the IBAN-OV attestation.

5.3 W3C Verifiable Credentials Data Model-based encoding

This Rulebook does not define a W3C Verifiable Credentials Data Model encoding for this attestation type.

6 Protocols

This attestation is issued using OpenID for Verifiable Credential Issuance [OpenID4VCI] and presented using OpenID for Verifiable Presentations [OpenID4VP], both as profiled by [HAIP].

7 Issuance

7.1 Binding

7.2 Issuance Policy

The IBAN-OV attestation is issued by the bank (ASPSP) holding the account, either:

• Within the RP registration process, or

• Upon explicit request from the legal entity owning the IBAN account.

• 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.

• The issuer is responsible for ensuring that the device binding is assured

  • ex. EUDI Wallet
  • ex. EBW Wallet - always in the same wallet by onboarding

7.3 Lifecycle management

The issuer sets the validity period of the attestation and reissues it when the underlying facts change, revoking the superseded attestation as described in chapter 8.

7.4 Embedded disclosure policy

This attestation defines no embedded disclosure policy.

8 Revocation

This chapter will be completed in a future version of this Rulebook.

9 Presentation

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

In accordance with sections 4.2.5 and 4.2.6 of the Base Verification Process, relying parties are required to automatically verify the credential's revocation status. This verification confirms the current status of the bank account, thereby rendering an additional 'bank_account_status' attribute obsolete.

Validate Integrity Rules

• The Relying Party SHALL verify that the attestation is NOT being used to initiate or execute a payment.
• The Relying Party SHALL verify that the IBAN conforms to ISO 13616:2020 format.
• The Relying Party SHALL verify that the bic_swift conforms to ISO 9362 format.
• The Relying Party SHALL verify that the expiry_date is after the issuance_date.
• The Relying Party SHALL verify that owner_type is present in account_ownership and contains exactly one of the permitted values ('entity', 'person').
• The Relying Party SHALL verify that the name attributes present in account_ownership are consistent with the declared owner_type: owner_name for legal persons; given_name and surname for natural persons.

9.1 Presentation Policy

To verify and validate a received presentation of an attestation of this type, the following steps SHALL be performed:

1. verify the signature over the attestation using a trust anchor obtained as described in chapter 10;
2. verify that the attestation is within its validity period;
3. check revocation status as described in chapter 8, unless the attestation is short-lived, or its remaining lifetime is below the revocation time threshold;
4. verify device binding where section 7.1 records the attestation as device-bound;
5. request only those attributes that are necessary for the stated purpose of the transaction, and, where the trust model for this attestation requires Relying Party registration, only those attributes it is registered and authorised to request.

Obligations specific to this attestation type, carried over from the previous version of this Rulebook:

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

9.2 Presentation modes

Remote presentation is in scope. Proximity presentation is in scope only where chapter 5 records an mdoc encoding.

9.3 Transactional data

This Rulebook defines no transactional data.

10 Trust Framework

This chapter will be completed in a future version of this Rulebook.

Trust anchor location

The attribute or metadata carrying the trust anchor location contains at least the URL at which a machine-readable version can be found or looked up.

11 References

This chapter will be completed in a future version of this Rulebook.