Data Privacy
What a KYC Provider Should Prove After a Data Breach
October 28, 2026
9 mins read
After a KYC data breach, a provider should prove what it held, that the data was not altered and who accessed it. See how a verifiable record does that.
TL;DR: After a KYC data breach, the provider should be able to prove four things: what it held, that the record was not altered, who accessed it and when, and that a regulator can verify all of that without the data being exposed again.
Two incidents surfaced in September, eleven days apart, making the same point about a KYC data breach from different angles. On September 12, Revolut confirmed a fake government request had pulled customer IDs and transaction histories from a limited set of accounts. On September 1, the FBI opened an investigation into a dark web listing tied to IDScan.net, later confirmed as more than 153 million leaked driver's licenses.
What Does a KYC Data Breach Actually Expose?
A KYC data breach exposes three separate things: the documents themselves, the customer's trust in the provider, and the provider's ability to prove what happened to the record before, during and after the incident.
Revolut's own account of the incident is instructive: the company said it identified an impersonation scam after the fraudulent requests had already been processed, meaning the data was gone before anyone could verify who was asking. IDScan.net's disclosure moved in stages for the same reason: an initial acknowledgment on September 1, then a confirmed count of names and government ID numbers a week later. Reconstructing what the database held, and when, took a separate forensic pass rather than a lookup. Neither company lacked the data. Both lacked a fast, verifiable answer to what had been held, changed, or accessed.
Three losses in a KYC data breach:
- The data - the documents and personal details themselves, now outside the provider's control.
- The trust - the customer's and regulator's confidence that this will not happen again.
- The evidence - the provider's inability to reconstruct, on demand, what its own systems held, when it changed, and who touched it.
The KYC data crisis on fiat on-ramps covers the same storage problem from the on-ramp provider's side; this piece looks at what happens after the breach, from the identity provider's side.
Selective Disclosure Stops the Storage Problem, Not the Evidence Problem
Zero-knowledge KYC, proving a fact like age or identity status without handing over the underlying document, reduces how much personal data a provider stores. It does not answer what a regulator asks after a breach: who held the record, was it altered, and can the original verification still be traced.
World's ProveKit and StarkWare's private-KYC demo both let a user prove an identity attribute, such as being over eighteen or holding a valid ID, without handing over the underlying document. A 2024 Deutsche Bank and Privado ID proof of concept tested the same idea for institutional onboarding and found the technology worked, but concluded that "counterparties still require detailed and costly KYC processes" behind the proof. Regulators reach a similar conclusion from the compliance side. When a suspicious-activity report opens an investigation, supervisors and law enforcement still need to confirm what happened and connect the record to a real identity. The provider whose data was breached still carries the liability exposure if it was mishandled.
Selective disclosure changes what moves across the wire between a customer and a verifier, the party checking the proof. It does not remove the question of who is holding the verifiable data behind it, or whether that holder can prove the record's state on request.
Four Things a Provider Should Be Able to Prove
After a KYC data breach, a provider should be able to prove four things: what it held, whether the record was altered, who accessed it, and that a regulator can confirm all of this without exposing the data again.
| Proof | What it means | Who asks | What today's stack answers | Where it falls short |
|---|---|---|---|---|
| Held | Exactly what data was stored, in what form, as of a given date | Customer, regulator | Static database snapshots, occasional exports | No cryptographic guarantee the snapshot matches production state |
| Unchanged | The record has not been altered since collection or last verification | Auditor, regulator | Manual audits, periodic attestations | Attestations cover only the audit date, not the gap between them |
| Accessed | Who read, exported, or queried the record, and when | Regulator, law enforcement | Application logs | Logs are editable by anyone with admin access; not independently verifiable |
| Verifiable without exposure | A regulator or auditor confirms the above without the data being handed over again | Regulator, customer | Selective-disclosure credentials, which prove an attribute | Proves the credential, not the state of the record behind it |
A Verifiable Record Makes the Proof Possible
A database that generates a Zero-Knowledge Proof for every state change gives a KYC provider the held and unchanged evidence a breach investigation needs today, without re-exposing the underlying documents.
This is the layer the identity-protocol vendors above are not building, and it maps to capabilities zkDatabase already applies in adjacent compliance work. Private KYC/KYB Compliance Proofs, KYC/KYB meaning Know Your Customer / Know Your Business, answer held: a Zero-Knowledge Proof confirms an identity attribute or the current state of a record without exposing the underlying documents. Continuous Audit Trail answers unchanged, since every state change (each time a record is created, edited or deleted) is cryptographically logged and queryable rather than checked at scheduled intervals. Selective Disclosure is what makes verifiable without exposure possible: a provider can answer true or false to "was this record altered" without handing the record itself back over.
Accessed is the harder question. Today's audit trail proves state changes, the writes to a record, not who read or exported it. Extending the same mechanism to access events would mean writing every read and export into that trail as a state change of its own. A log any administrator could edit would then become a record a regulator can independently query. That is a design extension of the same mechanism, not something zkDatabase does today.
Applied to a KYC provider's own records rather than a reserve balance (zkDatabase's original use case, proving an exchange's holdings without exposing custodian data), the mechanism answers three of the four questions above now: the proof itself is evidence that the data was held and unchanged, and provable without exposing it again. Accessed is the piece that still needs to be engineered in.
What This Changes for the Reusable-KYC Model
Reusable KYC only works if the original verification behind the reusable credential is itself provable, otherwise the model just moves the unprovable record from many providers to one.
Most reusable-credential vendors today are hybrid for exactly this reason: a trusted issuer runs the initial verification, then issues Zero-Knowledge Proofs a customer can reuse across platforms. That hybrid model holds up only if the trusted issuer's own record is provable, since a regulator investigating a reused credential will eventually ask the issuer the same four questions a directly-breached provider faces. Orochi Network's Sumsub partnership sits in that layer: Sumsub verifies identity and compliance, and a verifiable record behind that verification is what lets the proof be trusted after the fact, not just at the moment it was issued. A follow-up piece will look at the reusable-KYC vendor side of this model in more depth.
Key Takeaways
- After a KYC data breach, the provider should be able to prove what it held, whether it changed, who accessed it, and that a regulator can confirm this without re-exposure.
- Zero-knowledge KYC and reusable credentials reduce what gets stored, but regulators still need audit trails and the ability to re-identify parties during an investigation.
- A database that proves every state change closes the evidence gap that selective disclosure alone leaves open.
- Reusable KYC only holds up if the original verification behind it is itself provable.
Conclusion
A KYC data breach exposes more than documents; it exposes whether the provider can answer basic questions about its own records under pressure. The September incidents at Revolut and IDScan.net showed what happens when a provider cannot answer quickly: disclosures moved in stages, and customers and regulators were left waiting for facts the provider should have had on hand. Selective disclosure and reusable credentials narrow what gets collected going forward, but the harder problem, proving what already happened to a record, needs a database that produces evidence as a byproduct of normal operation, not a forensic project after the fact.
Schedule Consultation - Walk through what your KYC records could prove today. orochi.network/partnership
Explore zkDatabase - See how zkDatabase generates a proof for every record it touches. zkdatabase.org
FAQ
What should a KYC provider prove after a data breach?
A KYC provider should be able to prove what data it held, that the record was not altered, who accessed it and when, and that a regulator can confirm all of this without the underlying data being exposed again. Most providers today can only answer the first with any speed.
Does zero-knowledge KYC prevent data breaches?
Zero-knowledge KYC reduces how much personal data a provider stores or shares, which shrinks what an attacker can steal in the first place. It does not remove the need for the remaining record, wherever it is held, to be provably unaltered and traceable.
What is reusable KYC?
Reusable KYC lets a customer verified once by one provider present a Zero-Knowledge Proof of that verification to a second provider, instead of resubmitting documents. Most production implementations today are hybrid: a trusted issuer runs the original check, then proofs carry it forward.
Can a regulator still investigate if KYC data is not stored?
Yes, but the investigation needs a different kind of evidence. Regulators still require an audit trail, a way to connect a record to a real identity, and clear liability if something goes wrong, so the provable state of the record matters as much as reducing what is stored.
Related toData Privacy
