Verifiable Credentials in KYC: Selective Disclosure Done Right

Most KYC flows collect far more than they verify. A passport scan proves a date of birth, but you end up storing the document number, place of birth, machine-readable zone, and a face image — data you never needed and now have to protect. Verifiable credentials (VCs) and selective disclosure offer a different model: prove the attribute, not the artifact. This article outlines how the approach works and where it falls short.

What a Verifiable Credential Actually Is

A verifiable credential is a cryptographically signed set of claims issued by a trusted party — a government agency, bank, or accredited identity provider. The credential lives in a holder's wallet (often a mobile app), and the holder presents it to you, the verifier, when needed. The W3C Verifiable Credentials Data Model defines the structure; ISO/IEC 18013-5 governs the mobile driving licence (mDL) variant now issued in several jurisdictions.

Three roles matter:

• Issuer — signs claims (e.g. "date of birth = 1990-04-12") and publishes a public key.
• Holder — stores the credential and controls what gets shared.
• Verifier — checks the signature against the issuer's key and confirms revocation status.

Because the signature is verifiable offline against the issuer's published key, you can confirm authenticity without calling the issuer for every check — a meaningful reduction in third-party data exposure.

Selective Disclosure: Proving Less

Selective disclosure is the mechanism that makes VCs privacy-relevant. Schemes such as SD-JWT and BBS+ signatures let the holder reveal a subset of claims while keeping the rest hidden, and still produce a valid signature over only what was shared. A step further, zero-knowledge predicates let a holder prove "over 18" without revealing the birth date at all.

For a KYC or age-gated flow, that means you can request:

• Confirmation that the person is over a threshold age — without the exact date.
• A country of residence — without the full address.
• A name match against a signed credential — without retaining the document image.

This aligns cleanly with data minimization: you hold a signed assertion and the claims you actually needed, not a stack of source documents. When your retention policy expires, there is far less to delete.

Where the Model Still Breaks

Verifiable credentials are not a finished replacement for document verification. Several gaps remain:

• Coverage. Issuance is uneven. Outside a handful of mDL and EU Digital Identity Wallet programs, most of your customers will not hold a usable credential in 2025.
• Binding. A signed birth date proves the claim is authentic, not that the presenter is its subject. You still need a liveness check or biometric binding to connect the credential to the person in the session.
• Revocation. Status lists and cryptographic accumulators exist, but checking them can reintroduce a call to the issuer — and a phone-home trail you were trying to avoid.
• Regulatory acceptance. Whether a VC satisfies your obligations depends on jurisdiction and supervisor guidance. Treat this as general information and confirm acceptance with counsel or your regulator before relying on it.

Adopting It Pragmatically

The realistic path is hybrid. Accept verifiable credentials where they exist and fall back to document capture where they don't. In a chat-based flow, this is straightforward: the conversation branches based on what the applicant can present, and the same session records which method was used for your audit trail.

Design for the end state now. Store the claims you verified and the proof method, not the raw artifacts, whenever the credential model allows it. Set retention per attribute rather than per document. That way, as issuance coverage grows, your data footprint shrinks without a re-architecture. Learn more about applying these principles at privatekycbot.com. The goal is not chasing a standard — it is verifying what you must and holding as little as possible afterward.