Zero-Knowledge KYC:
How to Verify Identity Without Sharing Documents

The KYC Problem Nobody Wants to Talk About

Know Your Customer regulations exist for good reason. Governments need to prevent money laundering, terrorist financing, sanctions evasion, and fraud. Platforms need to verify that users are who they claim to be. Nobody disputes the goal. The problem is the implementation.

Traditional KYC requires users to upload passport scans, driver's license photos, utility bills, bank statements, and selfies to third-party verification vendors. Those vendors process the documents, extract the data, and store copies — sometimes indefinitely. The platform itself often retains a second copy. The result is a sprawling network of databases containing the most sensitive identity documents on earth, each one a breach waiting to happen.

The track record speaks for itself. Equifax exposed 147 million Social Security numbers, names, and dates of birth in a single breach. Capital One lost 100 million credit applications including SSNs and bank account numbers. T-Mobile leaked 40 million records including driver's license numbers. KYC vendors like Jumio, Onfido, and Au10tix process hundreds of millions of identity documents annually. Each one stores copies. Each one is a target. The question is not whether the next KYC vendor will be breached. It is when, and how many passport scans will be in the dump.

The fundamental architectural flaw is this: to verify that someone is over 18, the platform collects and stores their full date of birth, passport photo, document number, and home address. To verify that someone lives in the United States, the platform stores their complete residential address, utility bill, and bank statement. To check sanctions lists, the platform stores the user's full legal name and date of birth alongside OFAC query logs. Every single one of these verification tasks collects far more data than the actual decision requires.

How Zero-Knowledge Proofs Work for KYC

A zero-knowledge proof allows one party (the prover) to convince another party (the verifier) that a statement is true without revealing any information beyond the truth of the statement itself. In the context of KYC, this means proving identity attributes without revealing the underlying identity documents.

Consider four concrete examples that cover the vast majority of KYC requirements:

The STARK Circuit: Real Implementation

H33 ZK-KYC uses ZK-STARK proofs rather than SNARKs for three reasons: no trusted setup ceremony, transparent verification (anyone can validate), and post-quantum security (hash-based, no elliptic curve assumptions). The age verification circuit illustrates the approach:

// AgeVerificationCircuit — ZK-STARK with SHA3-256 commitments
// Proves: age >= min_age without revealing date_of_birth

struct AgeVerificationCircuit {
    // Private witness (known only to prover)
    dob_day: u8,
    dob_month: u8,
    dob_year: u16,
    salt: [u8; 32],          // Random salt for commitment

    // Public inputs (visible to verifier)
    dob_commitment: [u8; 32], // SHA3-256(dob || salt)
    current_date: u32,        // YYYYMMDD format
    min_age: u8,              // Required minimum age
}

impl AgeVerificationCircuit {
    fn constraints(&self) {
        // 1. Verify commitment matches private DOB
        let computed = sha3_256(self.dob_year, self.dob_month,
                               self.dob_day, self.salt);
        assert_eq!(computed, self.dob_commitment);

        // 2. Compute age from DOB and current date
        let age = compute_age(self.dob_year, self.dob_month,
                              self.dob_day, self.current_date);

        // 3. Assert age constraint
        assert!(age >= self.min_age);

        // 4. Range checks (DOB is valid calendar date)
        assert!(self.dob_month >= 1 && self.dob_month <= 12);
        assert!(self.dob_day >= 1 && self.dob_day <= 31);
        assert!(self.dob_year >= 1900 && self.dob_year <= 2026);
    }
}

The circuit enforces three things: the prover knows the preimage of the committed DOB hash, the DOB yields an age that meets the minimum requirement, and the DOB values are valid calendar dates. The verifier checks the proof in under 50 microseconds. At no point does the verifier learn the date of birth, the birth year, or even the decade.

Three-Tier Verification

Different regulatory contexts require different levels of identity assurance. H33 ZK-KYC offers three tiers, each building on the previous one. Platforms choose the tier that matches their compliance obligations.

OFAC Screening on Encrypted Identifiers

Sanctions screening is the hardest problem in privacy-preserving KYC. Traditional screening requires sending the user's full legal name and date of birth to an OFAC screening provider, who runs a fuzzy match against the Specially Designated Nationals (SDN) list. Every screening provider stores query logs. Every query log is a record of who was screened, when, and what their name and DOB are.

H33 solves this with Fully Homomorphic Encryption. The user's device encrypts their name and DOB using BFV (Brainfuck Verifiable — just kidding, it is Brakerski/Fan-Vercauteren lattice-based FHE). The encrypted identifier is sent to the H33 screening engine. The engine performs fuzzy string matching, phonetic matching, and alias resolution entirely on the ciphertext. It never decrypts. The match result is an encrypted YES/NO that only the user's device can decrypt. If the result is NO (not on the list), the user's device generates a ZK-STARK proof attesting to the result and signs it with Dilithium-5.

The screening server never sees the name. The platform never sees the name. The only entity that ever possesses the plaintext identity is the user themselves, on their own device. If the screening server is breached, the attacker gets ciphertexts — lattice-based encryption that is secure against both classical and quantum computers.

Biometric Liveness via FHE

Enhanced and Full tier verifications include biometric liveness detection. The user takes a selfie, and their device extracts a 128-dimensional biometric template from it. The device also extracts a template from the photo on their identity document. Both templates are encrypted using BFV Fully Homomorphic Encryption before leaving the device.

The H33 biometric engine computes the inner product of the two encrypted templates — the same operation used for face matching — entirely on ciphertext. The encrypted similarity score is returned to the user's device, which decrypts it locally. If the score exceeds the liveness threshold (indicating the selfie matches the document photo and is a live capture, not a printed photo or screen replay), the device generates a ZK-STARK proof of the match and signs it.

The server processes biometric data without ever seeing a face. There is no biometric database to breach. There are no selfie images stored on any server. The BIPA, CCPA, and GDPR exposure that accompanies every traditional biometric KYC vendor is eliminated entirely.

What the Platform Actually Receives

This is the critical difference. After a Full tier ZK-KYC verification, the platform receives the following payload:

{
  "verification_id": "zkkyc_7f3a9b2c...",
  "tier": "full",
  "result": true,
  "confidence": 0.997,
  "proofs": {
    "age_gte_18":       "STARK proof (verified)",
    "jurisdiction_us":  "STARK proof (verified)",
    "biometric_live":   "STARK proof (verified)",
    "ofac_clear":       "STARK proof (verified)",
    "pep_clear":        "STARK proof (verified)"
  },
  "sanctions_list_version": "SDN-2026-04-04-sha3-a8f2...",
  "signature": "Dilithium-5 (ML-DSA-87)",
  "timestamp": "2026-04-05T14:32:01Z",
  "pii_fields_received": 0
}

No name. No date of birth. No address. No SSN. No passport number. No selfie. No document scan. The platform stores this payload for compliance records. If the platform is breached, the attacker gets cryptographic proofs that reveal nothing about the user's identity. There is nothing to steal.

Traditional KYC vs. H33 ZK-KYC

Who Needs This

Any platform that performs identity verification and does not want to become the next Equifax headline. Specifically:

Fintech platforms and neobanks — subject to BSA/AML, required to perform KYC on every account holder, and exposed to massive class-action liability when (not if) their KYC vendor is breached. ZK-KYC eliminates the PII storage requirement entirely while satisfying the same regulatory obligations.

Cryptocurrency exchanges — required by FinCEN to perform KYC, hated by their user base for collecting identity documents. ZK-KYC resolves the tension: the exchange meets its regulatory obligations, the user never surrenders their passport scan to a centralized database.

Lending platforms — need to verify income, identity, and address for underwriting. ZK range proofs verify income thresholds. ZK jurisdiction proofs verify residency. The lender makes the same credit decision with the same confidence, backed by cryptographic proofs instead of document copies.

Marketplaces — platforms like Airbnb, Uber, and eBay that verify seller and host identities. These platforms hold millions of identity documents and are prime targets. ZK-KYC reduces their liability surface to zero while maintaining trust and safety.

Age-gated platforms — as age verification mandates expand globally (EU Digital Services Act, UK Online Safety Act, US state-level laws), platforms need a way to verify age without building databases of children's and adults' identity documents. ZK age proofs are the only technically sound solution.

Pricing

H33 ZK-KYC is priced per verification, not per seat. Volume discounts apply at every tier. No minimums, no contracts required.

Compare this to traditional KYC vendors that charge $1 to $5 per verification and create ongoing breach liability that can exceed $100 per compromised record in class-action settlements. At 100,000 verifications per month on the Full tier, H33 ZK-KYC costs $4,000/month. A single breach of 100,000 passport scans at a traditional vendor can result in $10 million or more in settlements, regulatory fines, and remediation costs. The ROI calculation is not close.

The Technical Stack

Every component in the ZK-KYC stack is post-quantum secure. STARK proofs are hash-based (SHA3-256) with no elliptic curve assumptions. BFV encryption is lattice-based. Dilithium (ML-DSA) signatures are NIST-standardized post-quantum. There is no component in the pipeline that a quantum computer can break. This is not a future-proofing claim — it is a present-tense architectural decision that eliminates harvest-now-decrypt-later risk for identity data that will remain sensitive for decades.

The entire verification pipeline — from document commitment through STARK proof generation through Dilithium signing — runs in under 2 seconds on a modern mobile device. Server-side proof verification takes less than 50 microseconds. At scale on H33 infrastructure, the system processes over 2 million verifications per second.

Get Started

H33 ZK-KYC is available now via API. Integration requires replacing your existing KYC vendor's SDK with the H33 client library. The API accepts verification requests and returns signed proof bundles. Average integration time is under one day for platforms with existing KYC flows.