Skip to main content

Account Ownership Credential (AOC) issuance

When a customer opens a bank account, the bank verifies their identity and establishes an account relationship. Traditionally, proving that relationship later—for login, transactions, or third-party verification—relies on passwords, SMS codes, or physical tokens. An Account Ownership Credential (AOC) replaces these mechanisms by binding the account relationship to a cryptographic key in the customer's EUDI Wallet. The bank issues the AOC after account opening, and the customer presents it whenever they need to prove they own the account.

Flow overview​

Your organization acts as the credential issuer. After completing identity verification and opening the account, you create a credential offer containing the account attributes. The Truvity EUDIW Connector handles the protocol exchange with the customer's wallet, signs the credential, and delivers the result to your callback.

The flow works as follows:

  1. The customer completes identity verification and opens a bank account.
  2. Your backend creates a credential offer with the account attributes.
  3. The connector generates a credential offer URI and returns it to your backend.
  4. Your app displays a QR code (cross-device) or triggers a deep link (same-device).
  5. The customer opens their EUDI Wallet and scans the QR code or taps the link.
  6. The wallet retrieves issuer metadata, exchanges the pre-authorized code for an access token, and requests the credential.
  7. The connector signs the credential, delivers it to the wallet, and sends a callback to your backend.
  8. Your backend updates the account status to reflect that the AOC has been issued.

Business context​

An AOC addresses three problems that banks face after account opening.

Proving account ownership digitally​

Customers need to prove they hold an account for scenarios like onboarding with a new financial service, authorizing a direct debit, or verifying their identity with a third party. An AOC provides a standardized, cryptographically verifiable proof that doesn't depend on paper statements or bank-specific portals.

Enabling passwordless authentication​

Once the AOC is in the customer's wallet, it can serve as the authentication credential for future logins. Instead of entering a password, the customer presents the AOC and proves possession of the associated private key. This eliminates password databases and the attack surface they create.

Reducing fraud through cryptographic binding​

The AOC is bound to a specific key pair in the customer's wallet. Only the holder of the private key can present the credential, which prevents credential sharing and the use of stolen credentials—risks that exist with passwords and one-time codes. Replay protection is provided separately by the nonce/challenge mechanism during verification, which ensures each presentation is fresh and cannot be reused.

Relationship to passwordless authentication​

The AOC issued during account opening is the same credential verified during passwordless authentication. This creates a complete credential lifecycle:

  1. Issuance—the bank issues the AOC to the customer's wallet after account opening.
  2. Storage—the wallet stores the AOC alongside other credentials.
  3. Presentation—the customer presents the AOC when logging in or proving account ownership.
  4. Verification—the bank (or another Relying Party) verifies the AOC using the connector.

This means a single integration covers both issuance and authentication. The bank issues the credential once and verifies it on every subsequent interaction.

Privacy and security​

Selective disclosure of account attributes​

The AOC supports selective disclosure. When the customer presents the credential, they can share only the attributes the Relying Party needs. For example, a third-party service verifying account ownership might receive the account holder name and bank name without seeing the full account number.

Ephemeral data model during issuance​

The connector uses an ephemeral data model during issuance. Account attributes are held in memory only long enough to sign the credential and deliver it to the wallet. After the credential is issued and the callback is delivered, the connector purges the claim data. No customer attributes persist in the connector.

Key binding​

The credential is cryptographically bound to the customer's wallet key pair during issuance. Only the holder of the corresponding private key can present the AOC. This binding is verified every time the credential is presented, ensuring that a stolen or copied credential is useless without the private key. See device binding for details on how key binding works.

Further reading​