FHE Platform Discussion

That's a clean, well-scoped use of FHE — and age verification is exactly the right wedge to lead with. The pattern you're describing is essentially privacy-preserving attribute verification, and it's having a real moment right now for reasons that work in your favor.

Why age verification is the right opening salvo

Three converging pressures make this market genuinely live, not speculative:

1. Regulatory mandates without good solutions. UK's Online Safety Act (in force 2025), EU's age-verification requirements under DSA, Australia's social-media age ban, multiple US states (Texas, Louisiana, Utah, etc.) requiring age gates on adult content and increasingly social media. Canada's Online Harms Act is heading similar directions. Everyone is being told "verify age" and the current options are all bad — either upload a government ID to a third party (privacy nightmare) or use face-estimation AI (creepy and inaccurate at the boundary).
2. Apple and Google's age-signal APIs (2025) created the framing but not the answer. Both shipped declared-age APIs that pass a coarse signal from the OS to apps. This educated the market on the concept of verified-attribute-without-document-sharing, but the implementations rely on trusting Apple/Google's underlying account data. There's a gap between "platform says trust me" and "cryptographically verifiable."
3. The incumbents are W3C Verifiable Credentials + Zero-Knowledge Proofs, not FHE. This is important — it's both your biggest competitive challenge and your biggest opportunity.

The honest competitive landscape

You're entering a space where the dominant cryptographic approach is ZK proofs over verifiable credentials, not FHE. Players like:

• Privado ID (formerly Polygon ID), Anon Aadhaar (India's national ID + ZK), zkPassport / ZKPassport (ZK over machine-readable passport zones)
• Privately.eu, Yoti, AU10TIX, Persona — incumbent KYC/age verification vendors, mostly using face estimation + ID upload, increasingly adding ZK layers
• Apple/Google declared age APIs — the path of least resistance for app developers, even if cryptographically weak
• EUDI Wallet (EU Digital Identity Wallet, mandatory by 2026) — will become the default in Europe, uses selective disclosure on signed credentials

The dominant pattern: you get a signed credential from an issuer (government, bank, mobile carrier) and prove a predicate over it (age >= 18) without revealing the underlying data. ZK is the standard tool because the proof can be verified by anyone with the issuer's public key, no further computation needed.

Where FHE fits — and the harder question of whether it should

The strict FHE flow you described — user FHE-encrypts PII, server homomorphically evaluates age >= 18, returns encrypted yes/no, user decrypts — is technically elegant but has a structural problem: the verifier (the service provider asking the question) ends up with an encrypted answer they can't read. If the user decrypts and tells the verifier, you've removed the cryptographic guarantee at the last step. If the verifier holds the decryption key, then the user's PII was effectively shared with the verifier under encryption only in transit, which is just TLS with extra steps.

To make FHE actually fit verification, you need one of:

• Multi-key / threshold FHE where decryption requires cooperation, and the protocol guarantees only the boolean result leaks. This is real but adds significant complexity and latency.
• FHE + a trusted issuer model where the issuer holds the canonical encrypted record and the user authorizes queries via signed requests. This works but the trust assumption migrates to the issuer.
• FHE as a server-side privacy layer where the value-add is that the issuer's database itself never decrypts the PII, even during query evaluation. This is the most defensible FHE story — your platform sits behind issuers (banks, governments, telcos) who want to offer attribute verification without ever loading PII into plaintext memory.

The third one is your strongest pitch. The story becomes: "Banks/governments/telcos want to offer 'is over 18' as a service to their downstream partners, but they don't want to centralize plaintext PII or expose it during query processing. Our FHE platform lets them answer attribute queries without their own systems ever decrypting the underlying record."

Where FHE wins over ZK that's worth emphasizing

Be specific about this in pitches:

1. Mutable records. ZK credentials are signed at issuance and frozen. FHE records can be updated in place (address changes, name changes, revocation) without reissuing credentials.
2. Complex predicates over multiple attributes. ZK can do this but circuits get heavy. "Is this person over 18 AND a resident of Ontario AND not on a sanctions list" is a natural FHE query; in ZK it's a custom circuit per predicate.
3. Issuer doesn't need to anticipate every query at credential-issuance time. With ZK-over-VC, the credential schema constrains what can be proved. With FHE on a stored encrypted record, the verifier gets to specify the predicate at query time.
4. Low-latency, high-performance is your team's claimed differentiator — emphasize benchmarks. The standard objection to FHE is "too slow for real-time." If your platform genuinely answers a >= 18 query in <100ms, that's the headline.

The "is it 18+" query is the worst-case showcase

A single boolean comparison is the easiest possible FHE operation and the weakest showcase of an FHE platform. ZK can do it in milliseconds with smaller proofs. If your demo is just "we computed age >= 18 in FHE," sophisticated buyers will ask why not ZK.

Strong demos for an FHE platform are:

• Multi-attribute compound queries with policy engines
• Encrypted-database joins (verify across multiple records without decrypting either)
• Aggregate statistics ("how many of your users are 18+" computed across an encrypted population)
• Encrypted scoring/ranking (credit scoring, fraud detection across encrypted features)

The age-verification wedge is good for market entry because of regulatory pull. The platform's real value is in the more complex use cases that ZK genuinely can't do well.

My honest read

The idea is good and the timing is right, but I'd reframe the pitch:

• Lead with the issuer-side privacy story, not consumer-side encryption. Issuers have budget and pain.
• Use age verification as the wedge (regulatory pull) but the product needs to credibly handle compound predicates and updates, or ZK eats your lunch on the simple cases.
• Be ready to articulate why FHE over ZK specifically — mutable records, query flexibility, and the latency claim are your three.
• The bootstrap problem matters more than the cryptography. Whoever wins this space wins by integrating with existing identity issuers, not by having the best math.

Good — that clarifies it. You're a B2B2C encrypted-attribute platform: issuers/holders put PII in once, service providers query it under FHE, no plaintext PII ever leaves your platform. That's a coherent positioning and a real category.

The category, named honestly

What you're building is closest to what the industry calls a "privacy-preserving attribute provider" or "confidential identity oracle." You sit between:

• Issuer/holder side: somebody attests to the PII (could be the consumer themselves at signup with ID verification, could be a bank, could be a government). Result: an FHE-encrypted record sits on your platform.
• Verifier side: service providers submit predicate queries (age >= 18, province == "ON", credit_score > 650), get back yes/no or bounded answers, never see the underlying data.

This is a meaningfully different category from KYC vendors (Persona, Jumio, Onfido) and from ZK credential platforms (Privado ID, zkPassport). It's also different from confidential computing platforms (which use TEEs/enclaves rather than FHE). Naming this clearly matters because buyers categorize vendors before they evaluate them.

The five structural questions your platform has to answer

1. The bootstrap problem: how does PII enter the system credibly?

If a user just types "I'm 35" and you FHE-encrypt that, the encryption is mathematically perfect and the data is worthless — garbage in, garbage out. Service providers need to trust the attestation, not just the encryption.

The realistic answers:

• Federated issuance: government/bank/telco asserts attributes, signs them, you store FHE-encrypted under your key with the signature attached.
• One-time KYC at onboarding: you (or a partner) verifies ID once, then PII lives encrypted on your platform.
• Hybrid: different attributes have different attestation chains.

FHE doesn't solve this; it changes what you do with the data after.

2. Key management — who holds decryption authority?

This is where most FHE pitches collapse under scrutiny. Options:

• Platform holds keys: simplest, but you're now a high-value PII target. The whole point of FHE is undermined.
• User holds keys: most privacy-preserving, but creates UX/recovery problems.
• Threshold/MPC key custody: keys split across multiple parties, decryption only with quorum. Strongest enterprise story.
• Per-query ephemeral keys + result re-encryption to verifier: the verifier gets the boolean answer encrypted to their key. Architecturally cleanest.

3. Query authorization — what stops a verifier from brute-forcing PII via clever predicates?

If a verifier can run arbitrary predicate queries, they can binary-search any continuous attribute. Ask age >= 18, then age >= 30, then age >= 40... they reconstruct exact age in ~7 queries. Same problem for income, credit score, address, anything continuous.

This is the query oracle problem and it's the first attack any sophisticated security reviewer will raise. Defenses:

• Predicate allowlisting: verifier can only submit pre-approved query templates.
• Differential privacy noise with privacy budget per verifier per user.
• Rate limiting + audit logs to catch query patterns.
• User consent per query class.

Your platform has to enforce a policy layer above the FHE math. The cryptography is necessary but not sufficient.

4. Revocation, updates, and lifecycle

• User moves provinces → update encrypted record
• User wants to delete their data (PIPEDA right to deletion) → encrypted blob must actually be destroyed, with audit trail
• Issuer revokes an attestation (fraud cases, identity theft)
• Verifier's key is compromised (re-encryption needed?)

ZK-credential platforms have well-known answers here. FHE platforms often handwave it. You need the operational story.

5. Performance under realistic load

Own the claim with specifics:

• Single-attribute predicate: target <100ms p99
• Compound predicate (5 attributes, AND/OR logic): target <500ms p99
• Throughput: queries/sec per node
• Cost per query at scale

If you can credibly hit checkout-flow latency, that's a major differentiator.

Go-to-market: who actually writes the check

Tier 1: regulatory-forced buyers

• Adult content / gaming / alcohol / cannabis platforms under age-verification mandates
• Social media platforms facing age-gating laws
• Online gambling operators (iGaming Ontario, hard age + jurisdiction requirements)

These have immediate pain. Easy story to tell.

Tier 2: financial services

• Open banking aggregators
• Buy-now-pay-later and consumer credit
• Crypto exchanges under FINTRAC requirements

Higher contract values, longer sales cycles.

Tier 3: ad-tech and analytics

• Privacy-preserving audience verification without revealing the individual

Tier 4: government and large enterprise

• Provincial digital ID, federated health records

Start in Tier 1 for reference customers, then move up.

The honest competitive matrix

Your honest competitive position: you're not better than ZK for the simple cases. You're better than ZK for the complex, mutable, multi-attribute cases — if your platform performance lives up to the claim. The wedge is "age" because of regulatory pull; the moat is everything beyond that.

Yes — and this is a substantially better story than pure age verification. You're describing a privacy-preserving comparison-shopping layer where the agent acts on behalf of the consumer with the FHE repository as the authoritative attribute source.

The shape of what you're proposing

Three parties, four roles:

1. Consumer — owns the encrypted PII record, authorizes the agent
2. Agent — autonomous shopper acting under consumer authorization, queries multiple lenders
3. Lenders — submit predicate queries through the agent to your platform
4. Your platform — evaluates encrypted predicates, returns yes/no or bounded answers

The agent's job is to translate the consumer's intent ("find me the best 5-year fixed mortgage") into a sequence of FHE queries against the consumer's record, submitted to multiple lenders in parallel, then return offers to the consumer for selection.

This is genuinely a new product category, and a much stronger pitch than age verification because:

• The buyers have real budget — lenders pay for qualified leads today; you're offering qualified leads with cryptographic guarantees.
• The unit economics work — a successful mortgage origination is worth $2,000–$5,000+ in lender acquisition cost. A few dollars per query is trivial.
• The privacy story resonates with consumers — nobody likes giving 12 mortgage brokers their SIN, income, and credit history.
• It's a wedge into the whole comparison-shopping market — mortgages, auto loans, credit cards, insurance, business banking.

Why this works conceptually

Lenders don't need to know who you are to pre-qualify you. They need to know:

• Does this person meet our underwriting bar? (predicate queries)
• If yes, what rate would we offer? (the lender computes this on their side)

Full identity only needs to be revealed at the point the consumer chooses a lender and commits to a formal application. Until that moment, the consumer can shop ten lenders without exposing PII to nine of them.

Structurally similar to what mortgage brokers do today, except:

• The PII never sits in plaintext with the broker
• The consumer can be their own broker via the agent
• The lender gets cryptographic assurance the answer is true

That last point is the real value-add over a human broker. Brokers can fudge, lie, or be wrong. Your platform returns a mathematically guaranteed answer derived from attested source data.

The hard problems, in order of severity

Problem 1: Lenders don't just want predicates — they want underwriting

A mortgage underwriter doesn't just need "income > $80K." They need:

• Exact debt-service ratios (GDS, TDS)
• Down payment source verification
• Employment verification (often a phone call)
• Property appraisal
• Credit bureau full pull

You can return predicate answers for the initial qualification stage, but at some point the file has to become a real application with real documents. Your platform's value is in the pre-qualification and rate-shopping stage, not the underwriting stage.

That's still hugely valuable. The pre-qual stage is where the comparison happens and where consumer PII gets most exposed today. But be precise in the pitch: you're replacing the "rate quote" and "pre-approval" steps, not the full underwriting.

Problem 2: The compound-query oracle problem gets worse

For mortgage shopping, lenders need many attributes:

• Income range, debt range, credit score band
• Employment duration, down payment range
• Residency duration, citizenship/PR status

If a lender (or a malicious actor posing as one) gets to ask 10–20 predicate queries per "qualification check," they can reconstruct a fairly precise picture through binary search.

Defenses get harder:

• Predicate templates must be standardized ("Mortgage Pre-Qual v1" = these 8 specific queries with these specific thresholds, take it or leave it).
• Per-lender query budgets enforced over time.
• Differential privacy noise is harder here — lenders need correct answers for underwriting.
• Consumer consent per qualification round — the consumer authorizes "shop 10 mortgage lenders in the next 30 minutes" and that's a finite, audited window.

This needs to be solved at the protocol level. It's not optional.

Problem 3: Lender trust in the data source

Lenders won't accept "the platform says income > $80K" unless they trust:

• Who attested the income (CRA, payroll provider, bank?)
• When it was attested
• Whether the attestation has been revoked

For mortgage qualification, lenders want:

• Income: CRA NOA, T4s, or payroll-provider attestation (Plaid Income, Inverite, Flinks)
• Credit: direct pull from Equifax/TransUnion (lenders typically want this themselves at some stage)
• Employment: employer letter or payroll API
• Identity: government ID + liveness
• Residency: utility bills, lease, government records
• Assets: bank account aggregation (Plaid/Flinks/Inverite/MX)

Your platform needs federated attestation infrastructure — you're storing PII with provenance, signed by the source that attested it.

You probably don't build all the integrations yourself — you partner with one or two aggregators. That's the pragmatic play.

Problem 4: The agent's authority and liability

When you say "authorized agentic agent," there are real questions:

• Who is the agent legally? A licensed mortgage broker (regulated)? A software product owned by the consumer? A SaaS run by a third party?
• What is the agent's fiduciary duty? If the agent picks Lender B because Lender B pays a higher referral fee, but Lender A would have been better — is that disclosed?
• What happens when the agent makes a wrong decision?
• Anti-steering rules. In Ontario, mortgage brokers (FSRA-regulated) have anti-steering obligations. An agentic broker is still a broker for regulatory purposes.

This is where I'd push hardest in your business model. You probably don't want to be the agent. You want to be the infrastructure the agent runs on. Let licensed mortgage brokers, fintechs, or eventually the banks themselves operate the agent layer; you're the FHE attribute oracle they query.

Problem 5: The consumer side — UX and key custody

The consumer needs to:

• Onboard once (KYC + attestation gathering)
• Hold a key (or delegate to your platform under a recovery model)
• Authorize each shopping session
• Receive and choose from offers
• Eventually identify themselves to the chosen lender

The hard UX bit is first-time onboarding. The thing that makes consumers do it is a lender-side incentive: "Get pre-approved in 5 minutes with 8 lenders, no SIN required."

What this actually looks like as a product

1. Consumer downloads "MortgageShop" app (built by a partner broker/fintech, running on your platform)
2. Onboards once: ID verification, connects bank via Flinks, connects CRA via My Account import, employment confirmed
3. App helps them define their mortgage goal: $500K, 25-year amortization, 5-year term, fixed
4. Authorizes a 30-minute shopping session: "Query up to 12 lenders, return all offers"
5. Your platform runs FHE qualification queries against the consumer's encrypted record, one query bundle per lender, in parallel
6. Lenders return rate offers based on their qualification result + their pricing model
7. Consumer sees 12 offers, chooses one
8. At choice time, full PII unlocks to the chosen lender for formal underwriting; the other 11 never see anything beyond predicate answers
9. Lender takes the file forward as a regular mortgage application

That's a real product. It compresses what's currently a multi-week, multiple-broker, paperwork-heavy process into one session, with cryptographic privacy guarantees.

The expanded TAM

Mortgage is just the first vertical. The same pattern works for:

• Auto loans — same comparison pain, lower complexity per deal
• Personal loans / lines of credit — quick qualification, high volume
• Credit cards — soft-pull pre-qual is already a thing; FHE makes it cryptographically sound
• Insurance quoting — life, auto, home all run on attribute-based pricing
• Business banking and SMB credit — even more broken than consumer
• Rental applications — "soft credit/income checks" without seeing underlying data

Each has the same structure: comparison-shopping, attribute-based qualification, current process leaks PII to many parties before commitment.

Honest competitive positioning

Who's adjacent today:

• Mortgage marketplaces (Ratehub, RateSpy, LowestRates) — lead-gen, not cryptographic. They collect your data and resell leads.
• Embedded credit / pre-qual APIs (Plaid, Inverite, Flinks) — attestation partners, not competitors.
• Open banking (Canada, ~2026–2027) — your platform sits on top, using it as an attestation layer.

The honest pitch: "open banking + FHE = privacy-preserving comparison shopping", and you're the FHE layer.

Where I'd push back, gently

1. Lenders may not want this. Lenders make money on information asymmetry. A platform that lets consumers shop 12 lenders in parallel compresses lender margins. Your early-adopter list is probably non-Big-Six.
2. Regulatory uncertainty is real. Canadian financial regulation hasn't grappled with "agentic AI broker" yet. Plan for an 18-month regulatory engagement before you're widely deployable. Engage with sandboxes (OSC LaunchPad, FCAC) early.
3. The "agent" word is doing a lot of work. If you mean "automated software that runs queries on the consumer's behalf," that's clean. If you mean "AI that decides which mortgage to take," that's a regulated activity. Be precise in product positioning about whether the agent recommends or just shops.

My recommendation on positioning

Reframe the pitch as:

"We're the privacy-preserving attribute infrastructure for financial comparison shopping. Consumers onboard once with their attested PII encrypted on our platform. Authorized intermediaries — licensed brokers, fintech apps, eventually banks themselves — run predicate queries against the encrypted record on the consumer's behalf, getting back qualification answers without ever seeing the underlying data. The result: consumers can compare-shop dozens of financial products in minutes with cryptographic privacy guarantees; lenders get qualified leads with provable data integrity; brokers and fintechs get a better consumer data layer to build on."

That's a clear category, a clear buyer, and a clear value prop.