From Sharing Data to Sharing Proofs: How Zero-Knowledge Proofs Could Reshape Financial Services
Financial services runs on disclosure. Banks ask for statements, lenders ask for income, investors ask for financials, regulators ask for ever more detailed reports. The assumption behind all of it is the same: if you want someone to trust a fact, you hand them the data behind it.
That assumption is starting to look inefficient. What if a fintech could prove its NPL ratio is below 3% without opening its entire loan book? What if a customer could prove their income exceeds €60,000 without revealing the exact figure? Zero-knowledge proofs (ZKPs) make this possible — not by encrypting data differently, but by changing what gets shared in the first place: instead of sharing the information, you share a proof about it.
The problem with "just share the data"
Take a fintech applying to become a banking partner. The bank wants to understand its financial health — loan-book size, NPL ratio, liquidity, customer concentration, revenue, capital position. Today that usually means opening an extensive data room.
But the bank doesn't need every borrower, every loan balance, every transaction. It needs to confirm a handful of thresholds: NPL under 3%, liquidity above €30M, concentration under 20%. The verifier needs confidence in a claim, not access to the data that produced it. Disclosure has simply been our default mechanism for building that confidence — not the only possible one.
What a ZKP actually is
A ZKP lets one party (the prover) convince another (the verifier) that a statement is true, without revealing the information behind it. Instead of "my income is €87,423," you prove "my income is greater than €60,000." Instead of opening a portfolio, you prove "my exposure to this sector is below 10%." The claim becomes verifiable; the underlying data stays private.
ZKP is not encryption
Encryption answers who can see my data. A ZKP answers can I prove something about my data without showing it to you. They solve different problems, and ZKP isn't the right tool for everything:
If a bank genuinely needs to inspect the underlying transaction, a proof doesn't replace that.
If a simple signature or selective-disclosure credential is enough, a ZK system is overkill.
And critically: a ZKP only proves a computation was performed correctly on the data it was given. It says nothing about whether that data reflects reality. That still requires trusted data sources, attestations, and audits.
This last point is the one most often lost in the hype.
Where ZKPs could actually change finance
The more useful question isn't "where can we use ZKPs" but "where are we sharing sensitive information today only because we have no better way to prove something?" A few areas stand out.
Private financial credentials. Rather than repeatedly handing over payslips, bank statements, and tax documents, a trusted issuer could issue a credential containing financial attributes — income above X, debt-to-income below Y, liquid assets above Z — that a customer proves without exposing the underlying numbers. This is the direction the EU Digital Identity Wallet ecosystem is exploring, though ZK isn't yet a standard deployed capability there.
Private creditworthiness. A lender cares about income thresholds, debt-to-income ratios, repayment history — not a borrower's complete financial life. A credential-and-proof model lets a lender confirm "this applicant satisfies our affordability policy" instead of receiving a full financial history, changing the economics of data minimisation: institutions can ask for less, not just store less.
Private due diligence. A fintech seeking a banking, payments, or lending partnership could prove NPL < 3%, liquidity > €30M, revenue > €50M, or concentration < 20% — without the underlying financials ever crossing the boundary. This doesn't remove due diligence, it changes what gets disclosed during it. It still depends on the counterparty trusting the data source and the methodology behind each metric: trusted data → defined computation → cryptographic proof → verification, not just fintech → proof.
Cross-border payments. Transactions crossing jurisdictions currently require exchanging information to satisfy KYC, AML, sanctions, and reporting checks independently at each hop. A proof attached to a transaction — "this satisfies the required compliance conditions" — points toward compliance without unnecessary disclosure. BIS Project Mandala has already experimented with embedding jurisdiction-specific rules into cross-border protocols using cryptographic proofs.
Verifiable regulatory reporting. If a regulator publishes a standardised computation, an institution could run it against internal data and submit a proof that it satisfies the condition — rather than the raw data itself. This wouldn't remove regulators' power to inspect institutions directly; it would give them a low-disclosure channel for routine verification, with deeper inspection still available when needed.
Proof of reserves and solvency. An institution could prove assets ≥ liabilities, or liquid assets ≥ redemption obligations, without publishing every position — useful where transparency matters but full portfolio disclosure creates commercial or security risk. The open question is still what counts as an authoritative asset figure in the first place.
Private AML and KYC. Instead of handing over full identity documents, someone could prove "KYC completed," "resident of an eligible jurisdiction," "above the required age," "not on a prohibited list" — nothing more. This pairs naturally with digital identity, verifiable credentials, and selective disclosure.
Private portfolio proofs. An asset manager could prove sector exposure is under 10%, or no single issuer exceeds 5%, without revealing full holdings — useful when portfolio composition is itself commercially sensitive.
ZKP doesn't work alone
ZKP is one privacy-enhancing technology among several, each answering a different question:
Technology | Core question |
|---|---|
TEE | Can we protect the environment where computation happens? |
Homomorphic encryption | Can we compute while data stays encrypted? |
MPC | Can multiple parties compute without revealing their inputs? |
PSI | Can we find overlap without revealing everything? |
Federated learning | Can we learn across datasets without centralising them? |
ZKP | Can we prove a statement without revealing the underlying data? |
In practice these combine: private data → secure computation → financial metric → cryptographic proof → external verification. The right question is never "should we use ZKP" — it's "what trust and privacy problem are we actually solving?"
The maturity gap
The cryptography itself is real and increasingly production-ready. But most proposed applications aren't ready to deploy, because of open questions around proving cost, circuit complexity, credential issuance, data provenance, revocation, interoperability, key management, and regulatory acceptance.
There's a real gap between cryptographic maturity (moving fast) and ecosystem maturity (slow, by nature). Institutions won't adopt a new primitive just because it works cryptographically — they need to know who issued the data, what the proof actually guarantees, what happens when the underlying data changes, who's liable if it's wrong, and whether counterparties and regulators will even recognise the proof. Those questions are often harder than building the proof system itself.
The bigger shift
The real implication isn't that financial data becomes "more private." It's that the unit of exchange changes.
Today: data → decision. With privacy-preserving computation: data → computation → decision. With ZKPs: data → proof → decision, where the verifier only receives the property it actually cares about. Eventually these combine: private data → trusted computation → verifiable proof → decision — a genuinely different information architecture.
From sharing data to sharing proofs
The more interesting question for financial services isn't "where can we use zero-knowledge proofs." It's "what are we still sharing today that the other party doesn't actually need to see?"
Appendix:
How does a zero-knowledge proof actually work?
The analogy first.
Imagine a circular cave with a single entrance and a fork deep inside — path A and path B — that reconnect behind a locked door. Only someone who knows the secret word can open that door and cross from one path to the other.
You want to convince me you know the secret word, without ever saying it out loud.
Here's how: I wait outside while you walk in and take either path, at random. Then I shout which path I want you to come back out of — A or B. If you really know the word, you can open the door and come out the side I asked for, every time, regardless of which path you originally took. If you don't know the word, you can only get it right by guessing which path I'd call — a coin flip.
Do this once, and there's a 50% chance you're bluffing. Do it twenty times, and the odds you faked it every round are less than one in a million. I never learn the secret word. I just become statistically convinced you know it.
That's the essence of a zero-knowledge proof: a challenge-response game, repeated enough times, that a bluffer can't consistently win but a genuine knower always can.
The small amount of math behind it.
Real ZK systems replace "the cave" with algebra — typically a sigma protocol, a three-step exchange between prover and verifier:
Commitment — the prover picks a random value and sends a "locked box" derived from it.
Challenge — the verifier sends back a random number.
Response — the prover combines their secret, their random value, and the challenge into a single number that only someone who truly knows the secret could produce correctly.
A toy version, using small numbers so the arithmetic stays checkable: suppose the "secret" is a number x = 6, and the public statement is y = 5ˣ mod 23 = 8 (public: the numbers 5, 23, and 8; private: the number 6).
Prover picks a random r = 3, sends t = 5³ mod 23 = 10.
Verifier sends a random challenge c = 2.
Prover computes s = r + c·x = 3 + 12 = 15, and sends s.
Verifier checks: 5¹⁵ mod 23 should equal t · y^c mod 23. Both sides come out to 19 — they match.
The verifier is now convinced the prover knows x = 6 — but x never appeared anywhere in the exchange. Only t, c, and s were sent, and none of those reveal it.
Production systems (zk-SNARKs, zk-STARKs) build on this same commit-challenge-response skeleton, but apply it to entire computations — expressed as circuits or polynomials — rather than a single number. That's what lets a prover show "this financial statement satisfies this policy" rather than just "I know this number," without a verifier ever seeing the statement itself.
