Revolut did not get hacked.
Someone asked for customer data from an email that looked like it came from a government agency, and Revolut sent it.
That is the whole story, and it is worse than a hack.
what actually happened
Revolut confirmed it disclosed sensitive customer data to fraudsters who submitted fraudulent information requests from a legitimate government agency email domain. In its own words, it identified "a sophisticated external impersonation scam where an unauthorised third party utilised a legitimate government agency domain email to submit fraudulent requests for information."
The exposed data is the kind that cannot be reissued: passport and driver's licence copies, verification selfies, dates of birth, postal and email addresses, phone numbers, bank statements, IBANs, withdrawal records, and transaction histories including Bitcoin activity.
Revolut says a limited number of customers were affected, that it notified them directly, and that its systems and customer funds were not compromised. On detection it blocked the sender and alerted the government agency, law enforcement, data protection, and financial regulators.
The attackers appear to have gone after high net worth individuals, many of them in crypto, and an extortion payment was reportedly demanded.
None of this is new in shape. Researchers linked a wave of similar incidents in 2021 and 2022 to the Lapsus$ group, which used compromised law enforcement accounts and forged emergency data requests to pull data out of Apple, Meta, and Discord. The FBI issued an alert in 2024 about fraudulent emergency data requests, noting a growing market on criminal forums for access to compromised email accounts specifically to send them.
So the pattern is documented, the tactic is known, and it still worked.
the weak link was identity, not cryptography
Everything in that pipeline probably worked exactly as designed. TLS terminated correctly. The domain authenticated. The ticket was created, the approval probably existed, the audit log was written.
None of that answers the only question that matters: is the human on the other end who they claim to be?
Domain authentication proves a mail server, not a person. SPF, DKIM, and DMARC tell you the message really came from that domain. They tell you nothing about who composed it, whether the mailbox is compromised, or whether an insider sold access to it. A valid domain is a weak signal dressed up as a strong one, because it is the only signal most teams look at.
The attacker did not defeat Revolut's security. They used the fact that the request was boring enough to be processed and official enough to be trusted.
your security ends where your process begins
Every company has workflows that make decisions based on an external identity claim. A request from a regulator. A vendor onboarding email. A "support" phone call. A bank details change form with a letterhead attached. A legal letter asking for records.
Those dependencies are not failures by themselves. You cannot verify the world. But they are the boundary of your security model, and most teams have never drawn that boundary anywhere.
Here is the exercise that matters, and it is not a security tool purchase:
List every automated workflow that can be triggered by someone outside the company. Then mark, for each one, whether the trigger's identity is verified by you or merely asserted by them.
Asserted identity plus automation equals a breach waiting for a plausible email.
That single column usually explains incidents like this better than any threat model.
the channels we never treated as engineering
Look at the asymmetry in how we treat interfaces.
An API gets tokens, scopes, mTLS, network boundaries, rotation, rate limits, and a team that looks at it every day. If someone changes an API integration, it goes through review.
Email and phone calls got treated as plain data transfer. Not engineering. Just the way humans talk to companies.
But the moment an email can trigger a workflow that exports identity documents, email is not data transfer anymore. It is an unauthenticated control plane with a human-shaped interface. It is also the most automated channel in the company, because we wired inboxes into ticketing systems, compliance queues, and now AI agents that triage and summarise.
We hardened the channel we already understood and left the one that arrives as text.
That is the structural finding in this incident, and it applies far beyond Revolut.
guardrails, not reminders
If the root cause is a workflow that trusts an unverified channel, then "be more careful" is not a control. These are.
Tier by reversibility, not by category. If an action cannot be undone, it should never run fully automated. Handing over passport scans, selfies, and transaction histories is irreversible. That step needs a human with a name attached to it.
Separate routine from exceptional, and default the exceptional path to human. Automate the common case if you must. Anything unusual becomes a break-glass path with named approvers. Make "unusual" a computable property: new requester, broader data scope than previous requests, unusual volume, unusual urgency, unusual time of day.
Verify out of band, always. Call the agency on a number you already had, not one from the email. Use a portal with mutual authentication. If you must accept email, require signed requests with keys exchanged out of band. "The domain looked right" is not verification.
Use AI to screen, not to decide. Models are genuinely good at the anomaly detection humans skip under deadline pressure: pressure language, a request much broader than the last ten, first-time contact, mismatched signatures, formatting that does not match the agency's usual output. Let AI raise the flag and route to a human. Never let it be the final approver for an irreversible disclosure.
Cap the blast radius structurally. Ask why one request can return passports, selfies, statements, IBANs, and crypto transaction history together. Separate stores, shorter retention on biometrics, per-request record limits, and alerts on bulk document export turn a catastrophe into an inconvenience.
Log decisions as data. Who asked, what was disclosed, who approved, and on what evidence. If you cannot reconstruct that in an hour, you cannot answer a regulator in a week.
Rehearse the manual path. An untested review process becomes a rubber stamp the first time a legal deadline meets a tired engineer.
is revolut the villain here
Partly, and it is fair to say so. They owned the workflow, and the workflow handed over documents.
But look at what they did not own. The government's email domain. The agency's inability to be impersonated. And the assumption, shared across the industry, that a request arriving through an official channel is an official request.
If a legitimate domain can be used to request identity documents, and nobody in the loop is required to verify the requester, then every fintech running the same compliance process has the same exposure. Revolut is the one that got the email. It is not the only one that would have answered it.
Regulators have a part to play too. Lawful data requests should travel over authenticated channels: signed requests, registered endpoints, mutual TLS, an auditable registry of who is authorised to ask. Until that exists, companies are expected to be polite, fast, and legally compliant over a channel that proves nothing. That is a bad deal, and it is being paid for by customers whose passports are now circulating.
what to do on monday
- Inventory every automated workflow that a third party can trigger.
- Mark each trigger as verified or merely asserted.
- Remove full automation from exceptional and irreversible paths.
- Add out-of-band verification for any disclosure of identity documents.
- Put AI in the screening layer, with a human on the approval.
- Alert on bulk access to documents, selfies, and transaction history.
The lesson is not that Revolut trusted an email. The lesson is that a whole industry automated a channel that was never designed to prove identity, and then treated the resulting trust as a security control.
Fix the boundary first. Then automate.
sources
- The Record: Revolut handed customer data to fraudsters using government email account
- BleepingComputer: Revolut discloses data breach exposing financial info, passports
- Malwarebytes: Revolut gave customer IDs and financial data to a government impostor
- Forbes: Revolut shock, fake government email leaks passports and Bitcoin
- FBI IC3: Cyber criminals use compromised email accounts to submit fraudulent emergency data requests
To test my projects, I use Railway. If you want $20 USD to get started, use this link.
Top comments (0)