Document Verification and Fraud Detection in KYC

Identity fraud costs financial institutions an estimated $52 billion annually. Document verification sits at the front line of KYC (Know Your Customer) compliance, and yet most verification pipelines still decrypt user documents on the server before analysis -- creating a honeypot of plaintext PII that attackers can harvest in a single breach. The emerging standard is to verify documents without ever seeing them in the clear, using fully homomorphic encryption (FHE), zero-knowledge proofs (ZKP), and post-quantum cryptographic signatures to produce tamper-proof attestations at scale.

The Four-Stage Verification Pipeline

A production-grade document verification system must execute four stages in rapid succession: capture validation, data extraction, authenticity checking, and cross-referencing against known-fraud databases. Each stage introduces its own attack surface. Traditional systems perform all four stages on decrypted data, meaning a compromised server exposes every passport, driver license, and national ID card it has ever processed.

At H33, the full-stack verification pipeline -- FHE batch computation, ZKP cache lookup, and Dilithium attestation -- completes in approximately 42 microseconds per authentication. At sustained throughput on a Graviton4 metal instance, that translates to 1.595 million authentications per second across 96 parallel workers.

Stage 1: Encrypted Capture Validation

Before any data extraction can occur, the system must confirm that the submitted image is usable: sufficient resolution, correct orientation, minimal glare, and no truncated edges. In a conventional pipeline, these checks require the raw image. In an FHE pipeline, the image is encrypted client-side using BFV (Brakerski/Fan-Vercauteren) lattice-based encryption before it leaves the device.

H33's BFV engine uses SIMD batching to pack up to 32 user documents into a single ciphertext, with 4,096 polynomial slots divided across 128 feature dimensions per user. This means a single homomorphic inner-product operation validates an entire batch simultaneously. The FHE batch operation completes in roughly 1,109 microseconds for all 32 users -- not per user.

What the Server Sees

// Server-side: operates on ciphertext only
let ct_batch = bfv.encrypt_batch(&user_features[0..32]);
let ct_result = bfv.multiply_plain_ntt(&ct_batch, &validation_weights);
// ct_result is still encrypted -- server cannot read it
// Only the client (or a threshold authority) can decrypt

The server performs polynomial multiplication in NTT (Number Theoretic Transform) domain using Montgomery arithmetic with Harvey lazy reduction. The result is a ciphertext that encodes pass/fail for each of the 32 documents. At no point does the server hold plaintext pixel data.

Stage 2: Homomorphic Data Extraction

Once capture quality is confirmed, the system extracts structured fields -- name, date of birth, document number, expiry date -- from the encrypted image features. This is where most legacy KYC providers fail: they must decrypt to run OCR. H33 runs the extraction as an encrypted inner-product against pre-trained feature templates, all within BFV ciphertext space.

The extracted fields remain encrypted throughout. They can be compared against encrypted watchlists (sanctions lists, PEP databases) using the same homomorphic operations, producing an encrypted match/no-match result that only the authorized verifier can decrypt.

Stage 3: Fraud Signal Detection

Document forgery falls into several categories, each requiring a different detection approach:

• Template manipulation -- Altering text fields on a genuine document template (e.g., changing a name or date of birth). Detected by comparing encrypted feature vectors against known-good template distributions.
• Synthetic generation -- Creating entirely fabricated documents using generative AI. Detected by analyzing micro-texture patterns that GANs and diffusion models characteristically fail to reproduce at the sub-pixel level.
• Presentation attacks -- Photographing a screen displaying someone else's document, or using a printed copy. Detected via encrypted liveness signals (moire pattern analysis, reflection gradients).
• Document recycling -- Submitting the same stolen document across multiple accounts. Detected by ZKP-backed deduplication that proves two encrypted templates match without revealing either one.

Stage 4: Cross-Reference and Attestation

The final stage produces a cryptographic attestation: a signed proof that the document passed all verification checks, bound to the specific ciphertext that was analyzed. H33 uses CRYSTALS-Dilithium (ML-DSA) for this signature -- a NIST-standardized post-quantum digital signature scheme based on Module-LWE lattice problems.

The attestation includes a SHA3-256 digest of the verification result concatenated with the ciphertext hash, then signed and verified with Dilithium. Total attestation latency is approximately 244 microseconds per batch of 32 users. Because the signature is post-quantum, these attestations remain valid even against a future adversary with a cryptographically relevant quantum computer.

Why Post-Quantum Matters for KYC Documents

Identity documents have long shelf lives. A passport issued today is valid for ten years. A driver license may be valid for eight. If the cryptographic signatures protecting those verification attestations can be broken by a quantum computer within that window, then every attestation ever issued becomes worthless -- and every verified identity becomes unverified retroactively.

"Harvest now, decrypt later" is not a theoretical threat. Nation-state adversaries are already collecting encrypted KYC data for future quantum decryption. The only defense is to ensure that every signature, every encryption layer, and every proof in the verification pipeline is post-quantum from day one.

H33's pipeline is fully post-quantum at every stage. BFV encryption is lattice-based (its security reduces to Ring-LWE). The ZKP cache uses SHA3-256 commitments, which remain secure under Grover's algorithm with a 128-bit post-quantum security margin. Dilithium signatures are NIST ML-DSA Level 5. There is no classical-only component anywhere in the chain.

Implementation Considerations

Deploying encrypted document verification in production requires attention to several practical concerns:

Regulatory Alignment

GDPR Article 25 mandates data protection by design. Because FHE-based verification never exposes plaintext PII to the server, it satisfies the "by design" requirement at the architectural level rather than relying on policy controls. Under the EU AI Act's forthcoming biometric provisions, systems that process identity documents without decryption will occupy a more favorable compliance posture than those that decrypt-then-re-encrypt.

Throughput at Scale

The 1.595 million auth/sec figure is achieved on a single c8g.metal-48xl Graviton4 instance with 96 parallel workers. For most production deployments, a smaller instance suffices. A 32-vCPU configuration sustains over 213,000 authentications per second -- more than enough for all but the largest global banks.

Integration Path

// Single API call -- document verification with FHE + ZKP + PQC attestation
POST /v1/verify/document
Authorization: Bearer h33_pk_...
Content-Type: application/json

{
  "encrypted_features": "<base64 BFV ciphertext>",
  "document_type": "passport",
  "check_dedup": true
}

// Response: signed attestation (Dilithium)
{
  "verified": true,
  "attestation": "<base64 Dilithium signature>",
  "batch_latency_us": 1356,
  "pq_secure": true
}

The entire pipeline -- from encrypted feature ingestion through fraud checks to signed attestation -- executes in a single API call. There is no multi-step workflow, no callback, and no plaintext intermediate state. The client encrypts locally, the server computes homomorphically, and the attestation is post-quantum signed before the response leaves the wire.