Menu

VC use case

External agent access to member policies

Delegated and regulated access for agents to a customer’s policies

  • Finance
Issuer authoritative source creates the claim
Holder person or organization presents proof
Verifier service checks status and makes a decision

Overview

Financial institutions can grant regulated agents delegated access to customer policies using Verifiable Credentials, with clear proof of authority and licensing.

The policy system can verify that an agent has current authority from the policy holder and any required regulatory license before exposing policy information or allowing action.

Why it matters

Delegation is heavily regulated and hard to manage at scale. Institutions need to support advisers and agents without relying on static notes, broad manual approvals, or repeated document checks.

Verifiable Credentials create a cleaner model:

  • the policy holder grants authority with explicit scope
  • the institution issues delegation evidence
  • regulators or licensing bodies issue agent credentials where needed
  • the agent presents both forms of proof when accessing a policy
  • the verifier checks issuer trust, scope, status, and expiry before access is granted

Ecosystem roles

  • Issuer: The financial institution and relevant regulator (license or authority claims).
  • Holder: The agent or adviser.
  • Verifier: The institution’s service channels that grant access.
  • Policy holder: The customer who grants authority over a defined policy or action.
  • Trust governance: The rules that define accepted issuers, license types, delegation scope, status checks, expiry, and revocation.

Trust decision

The verifier decision is narrow: can this agent access or act on this member policy for this policy holder right now?

That decision may depend on delegation scope, agent license, policy type, transaction sensitivity, expiry, and revocation status.

Privacy and assurance

The verifier should request only the delegation and licensing evidence needed for the policy action. A read-only policy enquiry, advice update, and transaction instruction may require different scopes.

Assurance depends on checking issuer trust, credential binding, status, expiry, and whether the requested action fits the delegated authority.

Implementation notes

  • Model policy-holder consent and agent licensing as separate credentials where different issuers control them.
  • Include revocation and expiry so delegated authority can be withdrawn quickly.
  • Keep the policy platform responsible for final access enforcement even after credential verification succeeds.
  • Define exception handling for disputed authority, vulnerable customers, urgent access, and manual compliance review.
Objective
Grant an agent controlled access to a member policy.
Description
Issue and verify credentials that allow a financial agent to access a policy offered by a financial institution.
Actors
Policy holder; financial agent; financial institution; regulator or licensing body.
Dependencies
Delegation credential, license credential where required, issuer trust registry, status endpoints, and policy access rules.
Preconditions
The policy holder has granted authority for the agent to access or act on a policy.
Postconditions
The financial agent can access only approved policy information or actions while authority remains current.
flowchart LR
    PH@{icon: "tabler:user", label: "Policy holder", pos: "b"} -->|Delegates authority| AG@{icon: "tabler:tie", label: "Financial agent", pos: "b"}
    REG@{icon: "tabler:scale", label: "Regulator", pos: "b"} -->|Issues license VC| AG
    FI@{icon: "tabler:building-bank", label: "Financial institution", pos: "b"} -->|Issues delegation VC| AG
    AG -->|Stores VCs| WAL@{icon: "tabler:wallet", label: "Wallet", pos: "b"}
sequenceDiagram
    participant PolicyHolder as Policy holder
    participant FinancialInstitution as Financial institution
    participant Regulator
    participant Agent as Financial agent
    participant Wallet

    PolicyHolder->>FinancialInstitution: Request to delegate authority
    FinancialInstitution-->>Wallet: Issue delegation VC
    Regulator-->>Wallet: Issue license VC
    Agent->>Wallet: Stores credentials
    Wallet-->>Agent: Credentials ready
flowchart LR
    AG@{icon: "tabler:tie", label: "Financial agent", pos: "b"} -->|Presents credentials| VER@{icon: "tabler:id-badge", label: "Service channel / verifier", pos: "b"}
    VER -->|Verify issuer, scope, status| TR@{icon: "tabler:book", label: "Trust registry / status", pos: "b"}
    VER -->|Access granted| SYS@{icon: "tabler:file-description", label: "Policy system", pos: "b"}
sequenceDiagram
    participant Agent as Financial agent
    participant Wallet
    participant Verifier as Service channel
    participant TrustRegistry as Trust registry/status
    participant PolicySystem as Policy system

    Agent->>Wallet: Approve presentation
    Wallet->>Verifier: Present delegation + license VCs
    Verifier->>TrustRegistry: Check issuer, scope, status
    TrustRegistry-->>Verifier: Valid
    Verifier->>PolicySystem: Grant access
    PolicySystem-->>Agent: Policy details

Talk to UNIFY

Explore how this use case could work in your trust ecosystem.

Share the scenario you are testing and we will help map the issuers, holders, verifiers, and policy decisions involved.
Looks good!
Please enter your name.
Looks good!
Please enter your company.
Looks good!
Please enter your e-mail address so we can contact you.
This form uses Google ReCaptcha to ensure interactions with our site are from legitimate users. Please accept the use of recommended storage before submitting the form. Find out more at the Privacy Center.
Your message could not be sent. Try again later.