We Converted a Mortgage Lending Platform to Full Post-Quantum Encryption in 7 Minutes

A real SBA lending platform. Real SSNs, EINs, tax returns, bank statements, spouse names, children's names, credit scores, loan amounts. Every field that would destroy someone's life if leaked. We wrapped all of it in fully homomorphic encryption without changing a single line of application code.

00:00:00 → 00:07:40

What We Started With

The platform is a production SBA lending application built on Fastify and PostgreSQL. Forty-seven microservices. Multi-tenant architecture. Loan applications flow in from borrowers, get matched to lenders, pass through underwriting, credit checks, document processing, and SBA eligibility scoring.

Every loan application contains the most sensitive data a person owns: Social Security numbers, Employer Identification Numbers, dates of birth, spouse names, children's names, annual income, bank account numbers, routing numbers, credit card numbers, credit scores, and loan amounts. For the co-borrower too. All of it stored in PostgreSQL JSONB columns. All of it in plaintext.

If someone breached this database — and databases get breached every single week — they would have everything needed to steal the identity of every borrower, their spouse, and their children. That is the current state of financial services infrastructure in 2026. This is not unique to this platform. This is how almost every lender in America stores data right now.

What We Changed

We built two files. One is the H33 FHE integration module — a client that talks to the H33 API for encryption, decryption, homomorphic comparison, and STARK-attested audit logging. The other is a repository wrapper that intercepts every database INSERT, UPDATE, and SELECT to encrypt PII fields on the way in and decrypt them on the way out.

The application code — the loan application service, the lender matching engine, the underwriting pipeline, the document processor — did not change. Not one line. The repository wrapper sits between the service layer and the database. The service layer still passes plain JavaScript objects. The wrapper encrypts the sensitive fields before they reach PostgreSQL. When the service reads data back, the wrapper decrypts transparently.

What Happens to the Data Now

When a borrower submits a loan application, here is what happens to their SSN:

The SSN enters the API as a string. The FHE middleware converts it to a 512-dimensional numerical embedding. The H33 API encrypts that embedding using BFV fully homomorphic encryption with a polynomial degree of 4096 and a 56-bit modulus — NIST Level 1 post-quantum security. The encrypted ciphertext and a SHA3-256 commitment hash come back. The ciphertext goes into the database. The plaintext SSN existed in server memory for microseconds, then was garbage collected. It never touched disk.

The decryption key does not exist in one place. It is split across five independent authority nodes using Shamir secret sharing with a 3-of-5 threshold. Any three must agree to reconstruct the key. No single server, no single employee, no single breach can access it. The key reconstruction happens in memory for microseconds during authorized decryption, then is zeroed.

If someone breaches this database now, they get ciphertext. Every SSN field, every EIN field, every bank account number, every income figure, every name — all BFV ciphertext. Lattice-based. Post-quantum. Computationally indistinguishable from random noise to anyone without the threshold key shares.

Lender Matching Without Decrypting

This is where it gets interesting. The lending platform matches borrowers to lenders based on loan amount, annual revenue, credit tier, industry, and geography. Before today, the matching engine read plaintext financials from the database and compared them to lender criteria.

Now, the matching engine uses homomorphic range checks. It asks the H33 API: does this encrypted loan amount fall between $100,000 and $500,000? The API computes the comparison on the ciphertext and returns a boolean. The matching engine never sees the actual loan amount. The lender never sees the actual loan amount. The server that processed the match never sees the actual loan amount. The borrower gets matched to the right lender, and their financial data stays encrypted the entire time.

This is not a theoretical capability. This is BFV fully homomorphic encryption running at production latency. The same engine that processes 2,209,429 authentications per second on Graviton4.

The Audit Trail

Every time any service accesses any PII field — for underwriting, for document processing, for lender matching, for any reason — the access event is logged with a STARK zero-knowledge proof and signed with a Dilithium ML-DSA-65 post-quantum digital signature. The proof attests that the access was computed correctly. The signature makes it unforgeable and quantum-resistant.

This is not a log file. This is a cryptographic audit trail that cannot be modified, deleted, or disputed. Every regulator, every auditor, every court can verify the proof independently. You cannot fake a STARK proof. You cannot forge a Dilithium signature. Not today, not with a quantum computer.

What This Means

Why Financial Institutions Should Do This Today

Equifax leaked 147 million SSNs. Capital One leaked 100 million credit applications. First American Financial exposed 885 million mortgage documents. Every single one of these breaches involved plaintext data sitting in a database. Not encrypted. Not hashed. Not protected. Just there.

The technology to prevent this has existed for years. Fully homomorphic encryption was first proposed in 2009. What didn't exist was a production implementation fast enough to be practical. BFV at 4096 polynomial degree with Montgomery NTT and Harvey lazy reduction running 2.2 million operations per second on a single ARM CPU — that did not exist until H33 built it.

This is no longer a research project. This is no longer a theoretical capability. We just proved you can take a real lending platform with real PII fields and wrap every sensitive field in post-quantum encryption in under 8 minutes. No application code changes. No database migration. No downtime. One wrapper, one environment variable, and every SSN in your database becomes lattice-based ciphertext that a quantum computer cannot break.

The question is not whether your organization can afford to do this. The question is whether your organization can afford another quarter with plaintext SSNs in production.