Attestation Rulebook for attestations of type IBAN Ownership Verification (IBAN-OV)

• Author(s):
  • [Ricky Lamberty, Robert Bosch GmbH]
  • [Stephan-A 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*

• Feedback:

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 Attestation 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 is structured as follows:

• Chapter 1 provides an introduction to the IBAN-OV attestation, including its scope and purpose, document structure, keywords, and terminology.
• 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 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).

2.1 Introduction

Data Model:

IBAN-OV Attestation
│
├── Bank_Account
│ ├── account_name
│ ├── iban
│ ├── account_type
│ └── account_currency
│
├── Account_Ownership 
│ ├── owner_type 
│ └── owner_name		(mandatory if legal person, 'entity')
│ └── euid
│ ├── given_name		(mandatory if natural person, 'person')
│ ├── surname			(mandatory if natural person, 'person')
│
└── Account_Provider
  ├── provider_name
  ├── euid
  ├── provider_country
  ├── bic_swift
  ├── national_bank_code
  ├── nace_code
  ├── clearing_number

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 EUID.
• Account_Provider describes the financial institution that issued the account 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.

2.2 Mandatory attributes

Bank_Account Mandatory Attributes

Account_Ownership Mandatory Attributes

Account_Provider Mandatory Attributes

2.3 Optional attributes

Account_Provider Optional Attributes

Account_Ownershpi Optional Attributes

2.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 SHALL be present if and only if owner_type = entity.
• euid 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.

2.5 Mandatory metadata

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 Currency Codes

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

2.8.2 Account Type Codes

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

2.8.3 OWner Type Codes

2.9 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.
• euid in Account_Provider SHALL be a non-empty string identifying the issuing financial institution.
• If owner_type = entity, euid in Account_Ownership SHALL be present and SHALL be a non-empty string identifying the register entry of the account owner.
• If owner_type = person, euid SHALL NOT be present.
• 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.

3 Attestation encoding

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

3.2 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

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

3.2.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 with the following members:

• type (string): SHALL be "status-list".
• status_list_credential (string, URI): The URI of the Status List Credential document that contains the status bitstring.
• status_list_index (integer, >= 0): The zero-based index into the status list bitstring that corresponds to this credential.
• status_purpose (string): SHALL be "revocation" for this attestation.

Example:

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

3.2.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",
    "euid": "DE-HRB-123456"
  },
  "account_provider": {
    "provider_name": "Example Bank AG",
    "bank_identifier": "DE-HRB-654321",
    "provider_country": "DEU",
    "bic_swift": "DEUTDEDB",
    "national_bank_code": "37040044",
    "nace_code": "64.19",
    "clearing_number": "37040044"
  },
  "status": {
    "type": "status-list",
    "status_list_credential": "https://bank.example.com/status/iban-ov/2025",
    "status_list_index": 456,
    "status_purpose": "revocation"
  }
}

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",
    "bank_identifier": "DE-HRB-654321",
    "provider_country": "DEU",
    "bic_swift": "DEUTDEDB",
    "national_bank_code": "37040044",
    "nace_code": "64.19",
    "clearing_number": "37040044"
  },
  "status": {
    "type": "status-list",
    "status_list_credential": "https://bank.example.com/status/iban-ov/2025",
    "status_list_index": 457,
    "status_purpose": "revocation"
  }
}

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

3.3 W3C Verifiable Credentials Data Model-based encoding

...

4 Attestation usage

4.1. Issuance process

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.

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

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.

4.2.9 Validate Integrity Rules

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

• 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.
• Additional validation of integrity and policy rules will be specified in a future version of this Rulebook.

5 Trust anchors

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

6 Revocation

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

7 References

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

8 References