Fintechs like Revolut field a constant stream of legitimate data requests from law enforcement and regulators, and they're built to respond to them quickly - that's part of what compliance with financial crime law requires. According to TechCrunch's reporting, Revolut said in a statement that it had "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 word doing the most work in that sentence is "legitimate" - whoever sent the request wasn't spoofing a look-alike domain or hoping nobody checked the sender address closely. The email genuinely came from inside a real government agency's mail infrastructure, which is precisely why it got past whatever verification step was supposed to catch a fraudulent request.
What went out the door
Per TechCrunch's account of the disclosure, the data Revolut handed over included customers' names, dates of birth, postal and email addresses and phone numbers, alongside copies of identity documents such as passports and driving licences. Verification selfies, account statements and transaction histories were also exposed for at least some of those affected - the full set a fintech collects to satisfy know-your-customer obligations at onboarding, now sitting with whoever crafted the request. Revolut described the number of customers affected as "limited" without giving a figure, and crypto investigator ZachXBT, who first drew attention to the notifications customers were receiving, said the pattern of who was contacted pointed toward high-net-worth accounts being the specific target rather than a broad, untargeted pull.
The failure wasn't technical
It's worth being precise about what didn't happen here. Revolut has been explicit that its systems were not hacked and customer funds were not touched - this wasn't an intrusion in any conventional sense. The company said it blocked the sender's address as soon as the fraud was identified and notified the impersonated government agency along with law enforcement, data protection authorities and financial regulators, though it hasn't named which ones. What failed was a process question that has nothing to do with firewalls or encryption: when a request arrives from an authenticated, genuine government mail server, how much additional verification does a compliance team actually apply before releasing a bundle of identity documents and financial history on a named individual? Here, apparently, not enough - and the attacker's insight was recognising that a real domain is often treated as sufficient proof on its own.
Why "the email was real" isn't the same as "the request was authorised"
A compromised or misused account inside a legitimate government mail system is a well-established attack pattern well beyond fintech - it's the same trick behind fraudulent emergency data requests that have hit US tech platforms in past years, where a subpoena or request looked procedurally correct because it genuinely originated from inside a real law-enforcement domain whose account had been compromised. The lesson generalises past Revolut: any organisation that has a fast-path process for releasing sensitive data on receipt of an "official" request needs a way to verify the request itself, independent of whether the sending mail server checks out. A genuine domain proves the mail server is real. It proves nothing about whether the person using it that day is authorised to ask for what they're asking for.
- Treat sender-domain authenticity as necessary but not sufficient for releasing sensitive data on request - a genuine government or law-enforcement domain can itself be compromised or misused.
- Build an independent verification step for high-sensitivity data requests, such as callback confirmation through a separately published contact channel, before identity documents or financial records are released.
- Apply extra scrutiny where a request's targeting pattern looks unusual, such as requests concentrated on high-value or high-net-worth accounts rather than a broad or random set.
- Log and review every government or law-enforcement data request against known, pre-verified contacts and case-reference formats for the agency in question.
- Have a rehearsed notification path ready - regulators, the impersonated agency, and affected customers - so that once a fraudulent request is caught, disclosure isn't improvised under pressure.
No exploit, no breach of Revolut's infrastructure, and customer funds untouched - and still a real loss of identity documents and financial history for the people affected. If you'd like help stress-testing how your own organisation verifies "official" data requests before releasing sensitive customer data, email sales@halfteck.com.