Hook
Three checks. Three passes. One forgery.
Let's be clear about what actually happened at Revolut, because the imprecision in the coverage is where the real lesson is buried. A data request arrived at the platform ostensibly from a government agency. It did not originate from an authorized official. It originated from an unauthorized mailbox sitting inside that agency's genuine domain infrastructure. The message was signed. SPF validated the sending host against the domain's published policy. DKIM validated the cryptographic signature over the message headers and body. DMARC confirmed alignment between the two and instructed the receiver what to do on failure. Nothing failed.
The control plane performed exactly as specified. Passports, liveness-check selfies, home addresses, IBANs, and transaction histories left the building.
This is not a story about a broken cryptographic primitive. Nobody factored a key. Nobody found a reentrancy bug, nobody triggered a stack underflow, nobody reordered a mempool to front-run a mint. This is a story about a trust boundary drawn in the wrong place a decade ago, standardized, deployed across the entire financial internet, and then walked through by a human with an email client.
Context: What Revolut Actually Holds
Revolut sits at the intersection of two data regimes that were never designed to coexist โ banking compliance on one side, crypto trading access on the other.
Under modern AML/KYC frameworks, a regulated institution cannot open an account without accumulating a dossier. Passport scan. Liveness-check selfie. Proof of address โ utility bill, bank statement, sometimes a lease. Tax residency. Source of funds. IBAN and account history. Then, layered on top, trading records: which assets, which amounts, which timestamps, which counterparties.
When the same account also trades bitcoin, one more artifact joins the pile. Every BTC transaction the customer ever touched is permanently and publicly recorded on a ledger that anyone can read, forever, without permission. That ledger was always public. It was never personal. The KYC database is the thing that makes it personal.
The critical property is composition. None of these fields is catastrophic in isolation. A passport number without a name is noise. A home address without an account balance is a phone-book entry. But passport plus selfie plus address plus IBAN plus financial history plus confirmed bitcoin holdings is not a dataset. It is a targeting package.
ZachXBT's read was that the exposure appeared limited, possibly aimed at high-net-worth clients. Marc Zeller noted that Revolut had, shortly before the breach, been demanding significant additional documentation and threatening account closure for non-compliance. Kraken's Jesse Powell-adjacent commentary from Karpelรจs went further in the useful direction: identifying the compromised government institution would let other banks and exchanges check whether they had received identical forged requests.
Revolut has not named the agency. It has not disclosed how many customers were affected. It has not said whether it changed the workflow that processes government information requests.
Three unanswered questions. Only the last one matters to anyone who is not already a victim.
Core: The Trust Chain, Disassembled
Let me open the opcodes.
Email authentication is three loosely coupled mechanisms that get treated as one.
SPF publishes a DNS TXT record listing authorized sending hosts for a domain. It validates the envelope sender. It does not protect the visible From header. It does not survive naive forwarding. DKIM has the domain sign a hash of selected headers and the body with a private key, publishing the public key at a selector under _domainkey. It survives forwarding. DMARC binds the two to the visible From domain through alignment and publishes a policy โ none, quarantine, or reject.
All three answer one question: did this message legitimately leave this domain's infrastructure? None of them answers a different question: should this request be honored?
If an attacker holds any mailbox on the domain โ a contractor account, a dormant intern address, a shared service mailbox whose credentials leaked in an unrelated paste three years ago โ every subsequent message passes all three checks. The authentication stack cannot distinguish an authorized official from an unauthorized squatter inside the same namespace. That is not a bug in the protocol. That is the protocol's declared scope. DKIM signs origin, not intent. A signature proves origin, never intent.
So the attack surface was never the email layer. It was the workflow layer.
Reconstruct the state machine Revolut must be running for inbound government requests:
- State 0 โ message arrives.
- State 1 โ authentication check (SPF / DKIM / DMARC).
- State 2 โ procedural check; is this the right category of request?
- State 3 โ human verification; does this come from a verified contact at that agency?
- State 4 โ data assembly.
- State 5 โ data egress.
The attacker forced a transition from State 1 directly to State 4, bypassing State 3. Every defensive dollar invested in this pipeline historically went into State 1, because State 1 is automatable and cheap and produces a green checkmark that auditors like. State 3 was never automated, never threat-modeled, never independently reviewed โ because it was assumed to be subsumed by State 1.
That is the structural error, and it is not unique to Revolut. Every bank, every exchange, every fintech with a compliance desk runs the same three-line function, and the third line is almost always a TODO.
Here is what the correct implementation looks like, written out because prose hides the omission:
fn handle_government_request(msg: Email, req: DataRequest) -> Result<()> {
verify_spf(msg)?; // transport provenance
verify_dkim(msg)?; // domain signature
verify_dmarc(msg)?; // alignment policy// The line that was missing. let contact = registry.lookup_verified_contact(req.agency); let channel = contact.out_of_band_channel(); // phone, portal, signed key if !channel.confirm(req.request_id, req.hash) { return Err(UnverifiedRequest); } dispatch(req) } ```
The interesting part is the economics of that missing line. Verification out of band costs almost nothing to implement and adds minutes of latency. verify_dmarc returns in microseconds. Organizations route investment toward the check that returns fastest and looks best in a compliance report. Code does not lie, but it often forgets to breathe. The DMARC verification runs, returns, and the pipeline moves on without ever pausing for the one step that requires a human voice on a phone line.
Now the second layer โ what the leaked fields actually do downstream.
Consider bitcoin transaction history as a data class. Every address is public. Every transaction is public. Clustering heuristics link addresses into wallets with reasonable accuracy. The hard part has always been the linkage from address cluster to legal identity. That linkage is precisely what chain-analysis vendors sell, and it is the reason their margins are what they are. When a KYC database leaks with identity data and trading history in the same row, the linkage is handed over precomputed. The attacker receives a labeled training set: name, photograph, home address, and a confirmed on-chain footprint with timestamps.
I spent six months after the Terra collapse reverse-engineering oracle manipulation vectors in algorithmic stablecoins, and the pattern that kept surfacing was never the exotic input. The fatal input was always the one everyone trusted to be boring. A price feed with a 30-second heartbeat looked boring. A Mail-from header looks boring. Both are the same class of dependency.
Exposure categories, sorted by how badly they degrade under composition:
| Field | Standalone value | Composed value | Remediation difficulty | |---|---|---|---| | Passport scan | Low | High โ enables account opening elsewhere | Impossible; document number is permanent | | Liveness selfie | Low | High โ defeats biometric re-verification | Impossible; face cannot be rotated | | Home address | Low | High โ enables physical threat | Impossible; moving is the only fix | | IBAN / transaction history | Medium | High โ reveals cash-flow rhythm | Hard; account can be closed | | BTC trading history | Public | Very high โ pre-links identity to chain | Impossible; chain is append-only | | Password / PIN / private key | Critical if leaked | Critical | Rotatable |
Read that last row carefully. It is the one that did not leak, and it is the one the entire remediation playbook was built for. Passwords rotate. PINs reset. Private keys can be migrated to a new wallet in an afternoon. Identity documents do not rotate. There is no key ceremony for a home address.
Meanwhile the fields that did leak are the fields with no revocation path. That asymmetry โ not the headline count of affected users โ is the actual severity metric, and it is the one nobody published.
Contrarian: More KYC Is the Wrong Reflex
The instinctive regulatory response will be more data, more verification, more retention, more attestation.
That is precisely backwards.
KYC regimes exist to reduce counterparty risk, and they do reduce it in the aggregate. But each additional field increases the value of the resulting honeypot superlinearly, because the value of a data store is combinatorial, not additive. Doubling the field count roughly squares the number of usable combinations. Doubling the verification frequency does nothing to shrink the blast radius once the store exists. Compliance regimes optimize a per-account risk metric. Breach severity is governed by a portfolio-aggregate metric. These two quantities move in opposite directions as collection expands.
Zeller's account is the sharpest detail in the whole story. According to him, Revolut had been demanding extensive additional documentation and threatening account closures for non-compliance โ and then the breach landed. A platform that escalates data collection aggressively while its third-party verification workflow remains unverified is not increasing security. It is increasing inventory.
Gas wars are just ego masquerading as utility. The 2021 mint mania is the same pathology in a different costume. I calculated then that ERC-721A batching saved users roughly $45 per transaction at peak congestion, and the market still overwhelmingly chose the premium path. Nobody optimizes for the thing they claim to optimize for. Compliance desks claim to optimize for risk reduction and in practice optimize for how well an audit form fills out.
The deeper blind spot is categorical. The industry treats email as an authentication layer. It is a transport layer. SPF, DKIM, and DMARC were built to stop spam and domain spoofing. We quietly promoted them into an identity system because identity is expensive and email was already bolted to the wall.
The uncomfortable implication is that the passwords, PINs, and private keys that were not leaked are the least important fact in this story. The industry will read "no funds lost" as a soft landing. It is not one. Funds can be re-frozen, re-issued, insured, clawed back by court order, or reimbursed out of a marketing budget. An identity dossier with a home address and a confirmed bitcoin position cannot be un-leaked. There is no revoke function. There is no governance proposal to roll it back. Data has finality that settlement layers only pretend to have.
Takeaway
The vulnerability forecast, stated plainly.
Every regulated crypto gateway currently running a government-request workflow that terminates at a DMARC pass is a candidate for the identical attack. The only thing standing between them and this headline is whether an attacker has yet bothered to compromise a mailbox at an agency they care about. High-net-worth clients will be targeted first, because that is where the data-to-effort ratio peaks.
Watch three signals over the next two quarters. Whether Revolut names the agency and the affected customer count. Whether it publishes a material change to its inbound request verification procedure. Whether any other institution discloses the same forged-request pattern. If two of the three resolve toward silence, treat that silence as the finding.
The question for anyone holding assets on a custodial platform right now is not whether the platform is solvent. It is whether its identity database is a liability you are underwriting every time you upload a document that cannot be deleted.