The forged request cleared SPF. It cleared DKIM. It cleared DMARC. Three authentication checks returned green, and one email left Revolut's compliance workflow carrying passports, selfies, home addresses, and IBANs — the complete raw material of a verified human identity. No chain was forked. No smart contract reverted. No private key moved. The breach did not occur in the cryptographic layer this industry spends its budget auditing. It occurred one hop upstream, in the trust layer that treats a message passing domain authentication as a message authorized to be obeyed. That assumption is not a peripheral detail. It is the entire attack surface.
Revolut occupies a specific and unusually exposed position in the crypto stack: it is the compliance gateway between traditional finance identity requirements and on-chain activity. As a fintech and crypto trading venue, it is obligated under KYC/AML rules to collect and retain passport-grade identity documents, liveness selfies, residential addresses, bank identifiers, and full transaction histories — including Bitcoin activity. That data set is not a set of isolated fields. It is a composite profile.
The disclosed facts are narrow and worth isolating. Forged requests originated from an unauthorized mailbox hosted within the real domain infrastructure of a government agency. The requests carried valid authentication credentials. They passed SPF, DKIM, and DMARC. Revolut contacted the government agency, blocked the offending addresses, and began notifying affected customers and regulators. No customer funds were reported stolen. No passwords, PINs, or private keys were exposed. On-chain investigator ZachXBT assessed the scope as possibly limited and likely aimed at high-net-worth clients. Marc Zeller alleged that Revolut had demanded extensive additional data and threatened account closures shortly before the breach. Karpelès, for his part, argued that naming the compromised institution would let other banks and exchanges check whether they received identical forged requests. Revolut has not disclosed the agency's identity, the number of affected customers, or whether it modified its government information-request procedure.
That last omission matters more than the headline. Compliance is not optional for a regulated gateway; it is the price of operation. But compliance is also the mechanism that manufactures the target. The regulatory regime that exists to protect customers centrally accumulates precisely the data that makes a single mailbox outage catastrophic. The rule and the vulnerability are the same rule.
SPF authorizes which IP addresses may send mail on behalf of a domain. DKIM signs the message so receivers can verify it was not altered and was signed by a key the domain published. DMARC ties the two to the visible From domain and instructs receivers how to handle failures. Together they answer one question: was this message authorized by the domain it claims to originate from? They do not answer a second, more important question: is the human sending it authorized to make this request?
| Layer | Verifies | Does Not Verify | |---|---|---| | SPF | Sending IP permission | Content legitimacy | | DKIM | Message integrity and signing key | Human intent | | DMARC | Domain alignment policy | Decision authority | | Composite | Envelope authenticity | Whether the request should be fulfilled |
A mailbox living inside the legitimate domain, using valid signing keys, produces a perfectly authentic and perfectly fraudulent request. Authentication is a property of the envelope, not of the request. I verified this pattern while reviewing multi-signature custody configurations against hardware signing standards in 2024. The scriptPubKey encoding matched the documented format and failed the operational intent — a mismatch that would have caused delivery failures while passing every format check. Code does not lie, only the documentation does. The same principle applies here: the email did not lie about its origin. It lied about its authority, and authority is never encoded in a header.
The operational profile deserves attention. A mailbox inside a real government domain is not acquired in an afternoon. Sustained access, not a one-time send, is the more probable model — which implies this request was unlikely to be the only one dispatched. If that inference holds, other banks and exchanges may be sitting on identical forged messages right now without a shared signal to compare against. That is why Karpelès' suggestion to name the institution is not a courtesy; it is incident-response infrastructure. Correlating campaigns requires a common indicator, and withholding it converts a discoverable pattern into an isolated anecdote.
The exfiltrated bundle is dangerous precisely because it joins across domains. A passport and a selfie establish legal identity. Add a home address and the same person can be located physically. Add an IBAN and transaction history and you have a financial profile. Add Bitcoin activity and you have an on-chain footprint that was previously pseudonymous. Bitcoin records live on a public ledger, but pseudonymity is only as strong as the gap between an address and a name. Once a verified identity is bound to an address, the public chain stops being a ledger and becomes a map.
Risk exposure breaks down as follows:
| Risk | Mechanism | Severity | |---|---|---| | Identity theft | Passport + selfie + address | High | | Targeted phishing | Contact + transaction context | High | | Physical threat | Home address disclosure | High | | Account takeover | Partial — no credentials leaked | Medium | | On-chain tracing | Identity-to-address binding | High |
The absence of leaked private keys is a mitigation only for one row of that table. It is being sold, in effect, as the whole table.
Data minimization would have shrunk the blast radius. Fewer retained fields means fewer fields to join. But KYC retention mandates work in the opposite direction, and the compliance function rarely shares its threat model with the security function. The gap between those two teams is where this breach lived.
Here is the contrarian read. The framing "no funds stolen, no private keys leaked" is technically accurate and structurally misleading. It quietly reclassifies a high-severity identity breach as a low-severity nothing-lost incident. But the loss is deferred, not avoided. A smart contract exploit is instant and, with enough chain analysis, partially recoverable. An identity exposure is cumulative and irreversible. You can rotate an API key. You cannot rotate a passport number, a home address, or a face. This industry continues to audit bytecode while the exploit sat in a government inbox and an email policy that no one reviews quarterly. Security is a process, not a feature. A zero-trust posture that stops at the perimeter of an internal domain is not zero trust — it is one trust with better branding. The disclosure gap compounds all of it: concealing the compromised institution prevents every peer institution from correlating whether the identical campaign reached them. If it cannot be verified, it cannot be trusted — and that principle applies to access verification exactly as it applies to code.
My 2018 manual audit of EtherDelta taught the same lesson in a different layer. I found three reentrancy vulnerabilities in withdrawal functions because the code executed a state change before validating state. The exploit was never in the cryptography; it was in the ordering of trust. This incident is the email-layer equivalent — a process that validated the envelope before validating the requester. The pattern recurs because the institutional incentive to keep a workflow fast outruns the incentive to keep it verified.
Downstream, the narrative pressure points are already shifting. Self-custody, on-chain analytics, and decentralized identity quietly gain a case study. None of that is validated by capital flows yet, which is exactly why it should be watched rather than celebrated. Narratives that grow during consolidating markets tend to be the ones that were structurally true before the market noticed.
The forward-looking judgment writes itself: expect forged-but-authentic requests to spread across KYC custodians, not just one fintech. The next breach will not announce itself with a reverted transaction or a drained pool. It will arrive with three green authentication checks and a polite request for documents. Regulators will eventually ask why the request pipeline required verification of the sender's domain but never the sender's authority. The KYC database is the new cold wallet — central, valuable, and guarded by the assumption that authenticity equals authorization.
When the envelope is genuine and the request is not, which layer do you actually trust? And when was the last time anyone verified that the signature was real, but the authority behind it never was?