Proving one number from a bank statement without handing over the statement
By Dylan Wolpe
The short version
- Income verification routinely over-discloses by orders of magnitude: the verifier needs one number and receives a complete behavioural record, every payee, every habit, every other account.
- Proving a single derived figure while withholding the underlying document is a solved cryptographic problem; the hard part is anchoring the figure to something the verifier already trusts.
- Without a signature chain back to the issuing institution, a selective-disclosure proof only demonstrates internal consistency, it proves the applicant did the arithmetic correctly on numbers they supplied.
- This makes coverage the real constraint: the approach works exactly as far as institutions sign what they send, which varies by bank and by country.
To rent a flat you hand over three months of bank statements. The agent wants to know one thing: that your income clears some threshold. What they receive is every payment you have made, your pharmacy, your subscriptions, your other landlord, the transfer to your mother, the gym you stopped going to in March.
Nobody designed this. It is what happens when the only available proof of a number is the document the number lives in.
The size of the over-disclosure
| What the verifier needs | What they receive |
|---|---|
| Income exceeds a threshold | Every credit and its source |
| Income is regular | Every debit and its recipient |
| It is your account | Full name, address, account number |
| , | Balances, overdraft use, other institutions |
| , | A behavioural record of three months of your life |
The verifier is not usually malicious; they are inheriting a risk they did not ask for. Estate agents and small landlords end up holding files of other people’s financial records, in an inbox, indefinitely, under data-protection duties most of them have not read. Reducing what they receive is in their interest too.
What the cryptography can do
Proving a statement about hidden data is well-trodden ground. You can demonstrate that a figure derived from a document exceeds a threshold, and that the derivation was performed faithfully, while revealing neither the document nor the figure itself. The verifier learns one bit, the claim holds, and nothing else.
Done properly the verifier can establish:
- A statement exists, issued by a named institution, covering a stated period.
- The credits in it, summed, exceed the threshold.
- The arithmetic was performed on the real contents, not on numbers typed by the applicant.
- The proof was made for this request and cannot be replayed against another.
And learns nothing about individual transactions, balances, or anyone paid.
The mathematics has been ready for years. What has been missing is a reason for the verifier to believe the input.
The part that is actually hard
A proof establishes that a computation was performed correctly on some input. It says nothing about whether the input was genuine. Prove a threshold from a document I wrote myself and the proof is impeccable and worthless.
So everything rests on the trust anchor: a chain from the proof back to the institution, such that the verifier can satisfy themselves the underlying document really came from the bank. That is not a cryptography problem, it is an ecosystem problem, and it is why this has not already happened.
Three anchors exist in practice, and they are not equally good:
- The email the bank sent you. Institutional email is signed by the sending domain, and that signature covers the message and its attachments. It is a genuine, checkable link back to the bank, and it is fragile, because signatures are validated against keys that rotate, and forwarding through some systems breaks them.
- Open banking APIs. The strongest anchor where they exist, because the data is fetched from the institution rather than relayed by the applicant. Coverage is the constraint, and it is very uneven outside the jurisdictions that mandated it.
- A signed session with the bank’s own site.Attesting to what a server actually served. Promising, still maturing, and dependent on the bank’s cooperation in practice.
Why this matters beyond renting
The same shape recurs everywhere: prove you are over eighteen without revealing your birth date; prove you live in a municipality without revealing your address; prove a supplier cleared a financial threshold without revealing their accounts; prove a qualification without exposing an entire academic record.
In every case the current answer is to hand over the whole document, because that is the only thing that carries any authority. Each time, the recipient acquires data they did not want, cannot safely store, and will be liable for.
Where we are
Prove generates a proof of a single figure from a statement, and the business side lets a landlord, lender or agent request one and check it without either party installing anything. The verifier sees the claim and its provenance, not the document.
The honest summary: the disclosure problem is solved, and the anchoring problem is partially solved and improving. We would rather describe it that way than imply the second half is finished, particularly to the people whose financial records are currently sitting in somebody’s inbox.