The KYC Honeypot: Reversing the Revolut Data Leak at the Process Layer

The KYC Honeypot: Reversing the Revolut Data Leak at the Process Layer

Hook

A single tweet. No transaction hash. No block number. No deployed contract to point at. That is the first anomaly.

ZachXBT flagged that a set of Revolut customer records had surfaced — reportedly carrying date of birth, home address, passport and driver's licence numbers, IBAN, email, phone, and a live selfie. The cohort is described as high-net-worth individuals. The company's visible response so far is a security alert email. No full technical disclosure. No regulator filing in the open. No independent verification from the major crypto desks at the time of writing.

Anyone who has done incident work notices what is missing. There is no partial-match signature. No column drift. No unicode mangling. No orphaned foreign keys. The dataset is internally coherent — every disclosed field belongs to the same person, to the same record, and to the same export purpose. Breaches that come through a database bug produce noise. Breaches that come through a business process produce packages.

What leaked here is a package. The defining feature of this incident is not that data escaped a system — it is that the system was asked for it and said yes. Every field in the reported set sits at the top of the sensitivity scale, and every field in the reported set is precisely what a legitimate customer-export routine is built to return. That alignment is the thread to pull.

Context

Revolut is a UK-founded fintech operating under an FCA footprint, with a European banking licence held in Lithuania. Roughly 40 million users. Crypto buy, sell, and send live inside the same application as fiat accounts, and that matters architecturally: the KYC record that protects the fiat account is also the record that maps to the crypto position. One identity file. Two attack surfaces. If the identity file leaks, the crypto position becomes addressable.

Standard KYC architecture runs in four layers.

Collection — passport or driver's licence upload, proof of address, and increasingly a liveness selfie.

Verification — document authenticity checks, face match against the selfie, sanctions and PEP screening.

Storage — an encrypted PII store under access control.

Retrieval and re-authentication — the layer that serves data back out to humans and machines: support workflows, compliance exports, data-subject access requests, law-enforcement requests, internal analytics.

Most post-mortems treat layers one through three as the security boundary. In practice, the boundary lives at layer four. Failures at the first three layers are loud — a misconfigured bucket, a leaked credential, an unpatched service — and they produce messy, mixed, partial data. Failures at layer four are quiet, because the request is well-formed, the caller is authorised, and the response is exactly what the schema promised to deliver.

Under GDPR, a live selfie is not a photograph. It is biometric data tied to a natural person, which places it inside Article 9's special categories and strips away most of the flexibility that ordinary PII handling enjoys. Passport number, IBAN, and home address sit in the adjacent high-risk tier. A complete KYC bundle is not a bigger version of a leak. It is a different legal and operational class of leak.

For scale: the EU ceiling on a data-protection fine is 4% of global annual turnover or €20 million, whichever is higher. Revolut's reported 2023 revenue sat near £1.8 billion. The arithmetic ceiling is uncomfortable, though the practical question is narrower — whether the 72-hour notification obligation was met, and whether a DPIA existed that anticipated this workflow before it was exploited.

That is the frame. Now the mechanics.

Core

Start from the data and work outward, not from the tweet inward.

The disclosed fields form the complete KYC set — nothing missing, nothing extraneous. That is the shape of a single scoped read against the customer record, not the shape of an adversary walking a database by hand. Dump a table and you get every column, including internal row IDs, soft-delete flags, and timestamp fields that never see daylight. You get rows you never asked for. Here, the reported fields are precisely the ones a legitimate export is built to return. The alignment points at the export path.

A support or compliance workflow that assembles a customer's PII for an approved purpose — an access request, a dispute, a manual review — is the natural vector. By design, that workflow holds broad read access to exactly the fields that leaked. Friction reveals the hidden dependencies. Remove the friction and collapse every request onto one path, and you have removed the internal boundary that would otherwise force an attacker to make noise.

Trace the invariant and the missing line becomes visible.

def export_customer_pii(request):
    actor = authenticate(request.actor)        # caller identity
    if not has_role(actor, ['support','compliance','csm']):
        revert('unauthorized')
    customer = request.subject                 # whose record
    # MISSING: re_auth(customer, request.proof_of_possession)
    return build_full_envelope(customer)       # passport, selfie, IBAN, address

The bug is the absent line. Not memory corruption. Not type confusion. Not reentrancy. A missing invariant — a re-authentication gate that should stand between a valid session and the most sensitive object in the system. I first internalised this shape in 2017, reverse-engineering an ERC-20 distribution contract where the distribution logic carried three integer overflow paths; the code compiled, the tests passed, and the logic still fractured on the boundary case nobody had written a test for. Same lesson, seven years later: the failure lives where the invariant is assumed rather than enforced.

Two gates should stand between an attacker and that envelope. Caller authorisation — is this actor permitted to make the request. Subject re-authentication — is the account holder actually on the other side. The evidence pattern suggests the second gate is where the logic fractures. First-time KYC is a one-shot check: document plus selfie, evaluated once, pass or fail. Re-authentication for a later, sensitive retrieval is a different control, and it is the one most often treated as either absent or trivially satisfiable.

When a system's most sensitive output is reachable through its most routine workflow, the security model has already been decided by the workflow, not by the cryptography.

There is a structural aggravator underneath this. When a single operator role — account manager, customer success, support tier two — holds read access across the full customer object, the human becomes the access-control layer. The intent is operational efficiency: one seat resolves anything. The effect is that a compromise of one seat is a compromise of every record it touches. I have watched this pattern play out well outside crypto, in password-manager operator roles and admin-with-export seats at SaaS companies. The convenience is real. So is the blast radius.

Now the target selection. The affected cohort is described as high-net-worth. That is not incidental. Sweep records by ID range and you expect a cross-section — students, salary workers, dormant accounts, people who opened the app once and never came back. A high-value cluster implies a filter applied during the request, or an internal actor who knew which records were worth pulling. Forensically, that moves the incident from opportunistic toward directed. Directed incidents evade detection longer, because the request volume is low and the request shape is normal.

What does a directed KYC leak convert into? Walk the fields and the chains build themselves.

Passport imagery plus selfie yields synthetic or impersonated account opening at any institution that accepts remote onboarding. The selfie is the expensive part of that package to source honestly; once it exists as a file, liveness checks at other providers inherit the failure.

Name plus date of birth plus phone number yields SIM swap. The carrier social-engineering surface is well understood and remains largely unpatched at the process layer. A swapped SIM intercepts SMS one-time codes, still the fallback authenticator across a meaningful share of custodial venues.

Home address plus a known crypto position yields physical-coercion risk — the wrench threat model. That field combination is what turns a data leak into a personal-safety event rather than a documents event, and it is the part of this story that the compliance conversation consistently fails to price.

I ran the same dependency analysis in 2021 on an ERC-721 derivative whose metadata resolved off-chain through a centralised host. A DNS hijack would have let an attacker redefine what the asset was, because the token pointed at a server rather than at immutable storage. Metadata is memory, but code is truth. The token contract was correct. The truth on-chain was correct. The thing that could be silently rewritten sat exactly one layer out. The KYC record follows the same architecture: an identity that looks authoritative and on-chain-grade, whose canonical copy lives on a server that answers to a workflow.

On market pricing, darknet listings for Fullz — complete identity packages — have historically cleared in the hundreds of dollars per record when the file includes government ID imagery and a selfie. The reported composition here sits at the top of that band. The second-order effect is the one most coverage will underweight: once a premium cluster of crypto-associated identities is catalogued and sold, the buyer is not a fraudster hunting a credit card. The buyer is running a targeted campaign against people who hold assets with no chargeback path. You cannot reverse a signed transaction.

Custody and insurance implications follow. Chain-native cover has long been narrative-supported rather than risk-priced, because the tail events were mostly smart-contract-shaped — reentrancy, oracle manipulation, bridge logic. A wave of KYC-derived targeting has a different loss distribution, one that is identity-loss and coercion-loss shaped and barely modelled by anything currently on-chain. I expect these instruments to stay disconnected from their real exposure for a while yet, much the way lending-protocol interest curves stay disconnected from actual funding markets: the parameters are set, they are internally consistent, and they are not the world. The curve is a number someone chose. Supply and demand is a measurement.

Let me be precise about what this is not. This is not a Layer 2 event. No rollup state is implicated. No bridge, no sequencer, no DA commitment. And that is the useful reminder: a large share of the scaling conversation runs parallel to where user risk actually concentrates. The edges of the crypto system — the fiat on-ramp and the identity gate — remain the least decentralised, the most concentrated, and the most heavily attacked surfaces, and no proof system secures them. The interesting question is not whether a rollup needs a dedicated data-availability committee. It is why the identity layer still hands the entire envelope to a server that answers to a help desk.

Incident lineage is worth stating plainly. This is not the first time a custodian has become the honeypot, and the pattern is stable enough to be useful. Binance's 2019 KYC exposure, Ledger's 2020 customer-data leak, the 2022 Whale Alert incident — each followed the same three-beat rhythm. An authoritative source discloses a package. The affected cohort is identifiable. Then comes a targeted phishing and coercion campaign that outlives the headline by years. Narrative fatigue sets in after each one, and the structural condition does not change. The fatigue is itself the signal that the underlying architecture has not moved.

The monitoring gap is the part most operators get wrong. Typical detection stacks alert on anomalous volume, not anomalous legitimacy — a spike in exports, an off-hours login, a new device fingerprint. A directed extraction run by an authorised seat, at normal volume, during business hours, from a known device, trips none of those alarms. The signals that would catch it are semantic: a support role requesting a full-envelope export when the workflow only calls for a dispute ticket; a subject set that correlates with account balance rather than with a ticket queue; a retrieval pattern that matches a curated customer list rather than a random sample. Almost nobody instruments for those, because doing so requires the security team to model intent rather than rate.

Contrarian

The conventional reading is that Revolut had a security failure. The more uncomfortable reading is that Revolut delivered exactly what the compliance regime asked it to build.

KYC mandates comprehensive collection. The stricter the jurisdiction, the more fields it demands: identity document, proof of address, biometric liveness, financial history. Every requirement is a line item that has to be stored somewhere, retrieved by someone, and justified by a workflow. The mandate is written by regulators who are genuinely worried about money laundering. The implementation is written by product teams who need the workflow fast enough that support tickets close. Neither party optimises for the attacker's cost function.

That is the paradox, and it is structural rather than incidental: the compliance process that exists to make users safer is the process that manufactures their most dangerous dataset. More KYC means a larger honeypot. A larger honeypot means a more valuable target. A more valuable target means a more motivated adversary. Users hand over the raw material of their own compromise in exchange for the right to use the product, and the trade is presented as protection.

There is a pattern-match worth noting against Revolut's own history. In 2022 the FCA placed temporary restrictions on its crypto business over anti-money-laundering and compliance concerns. The institutional muscle that failed that review is the same muscle that now has to distinguish a legitimate export request from a fraudulent one. That is not proof of causation. It is a reason to weight the process-flaw hypothesis higher than the sophisticated-external-intrusion hypothesis.

The named fix is ZK-KYC — prove a predicate without revealing the underlying record. Prove over eighteen. Prove screening passed. Prove residency. Never disclose the passport. Never disclose the face. The cryptography is real. The deployment is not. Nearly every zero-knowledge identity scheme in market is a proof layer bolted in front of an off-chain issuer that still holds the plaintext, which means the honeypot is still there, now with a nicer API in front of it. The abstraction leaks, and we measure the loss at the same place it always was: storage.

I hold confidence moderate on every causal claim here. The evidence base is one disclosure, no official post-mortem, no confirmed scope, no independent verification at time of writing. That is a reason to hold the specific attributions loosely while holding the structural argument tightly. The pattern does not depend on this single incident being fully characterised. It would hold if the scope turned out smaller. It would hold if it turned out larger.

Takeaway

What I am watching is not the apology. It is three timestamps and one file type. When Revolut notified its regulator — the 72-hour clock is the difference between a fine and a footnote. Whether a DPIA existed for the export workflow before the incident, which decides whether this reads as bad luck or bad design. And whether Fullz listings carrying the disclosed field set appear on the tracking feeds within thirty days, which is the only honest measure of how far the package travelled.

If the records were extracted and shelved, this is a compliance story. If they were extracted and sold, it becomes a multi-year targeting problem for a fixed set of names — and the people on that list will never be able to revoke what was taken. You can rotate a key. You cannot rotate a face.