Delegated access to financial accounts

Overview

Banks, credit unions, and wealth providers can let customers delegate controlled account access to an adviser, support person, or authorized representative using Verifiable Credentials.

The account provider does not need to rely on a standing manual note, shared credentials, or a broad account relationship. It can verify that a delegation exists, is current, and applies to the requested account action.

Why it matters

Delegated access is common in financial services, but it is often difficult to audit, constrain, and revoke. Customers may need help from advisers, family members, accountants, brokers, or support workers, while providers need to protect accounts and meet regulatory obligations.

Verifiable Credentials create a cleaner model:

• the customer approves a delegation with explicit scope
• the provider or trusted authority issues proof of that delegation
• the agent presents delegation and license evidence at the point of service
• the verifier checks issuer trust, credential status, scope, and expiry before granting access

This reduces reliance on static records and gives the customer and provider a clearer lifecycle for delegated authority.

Ecosystem roles

• Issuer: The account provider issuing delegation credentials, and any regulator or licensing authority issuing adviser or agent credentials.
• Holder: The delegated agent, adviser, or support person who stores authority credentials in a wallet.
• Verifier: Service channels, contact center platforms, portals, and account systems that enforce access decisions.
• Customer: The person or organization granting authority over defined accounts or actions.
• Trust governance: The rules that define accepted issuers, credential schemas, permitted scopes, status checks, and expiry handling.

Trust decision

The verifier decision is narrow: can this agent perform this account action for this customer right now?

That decision may depend on the customer’s approved delegation, the agent’s license or role, account type, transaction sensitivity, expiry, revocation status, and any step-up policy required by the provider.

Privacy and assurance

The verifier should request only the evidence needed for the requested action. A balance enquiry, document upload, advice interaction, and payment instruction may require different scopes and assurance levels.

Assurance depends on checking:

• whether the delegation issuer is trusted
• whether the agent credential and delegation credential are both current
• whether the requested action is within scope
• whether the delegation has expired, been revoked, or been superseded
• whether additional customer consent or step-up verification is required

Implementation notes

• Model delegation as a scoped authority, not a broad account relationship.
• Include expiry, revocation, and audit events in the delegation lifecycle.
• Keep account systems responsible for enforcing final policy even when credential verification succeeds.
• Define exception handling for urgent access, vulnerable customers, disputed authority, and offline verification paths.

Objective

Enable controlled delegated access to financial accounts.

Description

Issue and verify credentials that prove an agent can act on a customer account within defined limits.

Actors

Customer; financial agent; account provider; regulator or licensing authority.

Dependencies

Accepted delegation schema, issuer trust registry, license credential, status checking service, and account policy engine.

Preconditions

The customer has approved a valid delegation request and the agent holds any required authority credentials.

Postconditions

The agent can perform only approved account actions during the authorized period, or the request is denied or escalated.

flowchart LR
    CUST@{icon: "tabler:user", label: "Customer", pos: "b"} -->|Approves delegation| BANK@{icon: "tabler:building-bank", label: "Account provider", pos: "b"}
    BANK -->|Issues delegation VC| WAL@{icon: "tabler:wallet", label: "Agent wallet", pos: "b"}
    REG@{icon: "tabler:scale", label: "Regulator", pos: "b"} -->|Issues license VC| WAL
    WAL -->|Present delegation + license| VER@{icon: "tabler:id-badge", label: "Service channel", pos: "b"}
    VER -->|Check issuer, scope, status| TR@{icon: "tabler:book", label: "Trust registry", pos: "b"}
    VER -->|Grant constrained access| ACC@{icon: "tabler:file-description", label: "Account platform", pos: "b"}

sequenceDiagram
    participant Customer
    participant Provider as Account provider
    participant Regulator
    participant Wallet as Agent wallet
    participant Verifier as Service channel
    participant Registry as Trust registry

    Customer->>Provider: Approve delegated account access
    Provider-->>Wallet: Issue delegation VC (scope + expiry)
    Regulator-->>Wallet: Issue license VC
    Wallet->>Verifier: Present credentials for account action
    Verifier->>Registry: Validate issuer, scope, and status
    Registry-->>Verifier: Valid
    Verifier-->>Wallet: Access granted within policy