The Domain Was Real. The Authority Behind It Was Not
Revolut confirmed on September 12 that it disclosed customer data after receiving what it called "a sophisticated external impersonation scam," in which an attacker used a legitimate government agency's own email domain to submit fraudulent requests. Revolut's statement said the request carried credentials that passed the company's own checks, and it has since blocked the address and alerted law enforcement and regulators. The company has not named the agency whose domain was used, and has not said whether the domain itself was compromised or the attacker found another way to send from it.
Revolut was clear on one point: "Revolut systems and customer funds are unaffected." This was not an intrusion into Revolut's infrastructure. It was Revolut's own process for responding to official requests, working exactly as designed, against a request that looked exactly like the ones it is designed to honor.
What Actually Left Revolut's Systems
The exposed files, according to reporting reviewed after the disclosure, went well beyond a name and an address.
| Category | What was exposed |
|---|---|
| Identity documents | Passports or driving licences, plus verification selfies |
| Personal details | Names, dates of birth, occupations, home addresses, emails, phone numbers |
| Financial records | IBANs, account statements, withdrawal records |
| Transaction history | Full transaction histories, including bitcoin activity |
Revolut has said the number of affected customers is "limited" without giving a figure, and independent reporting has not been able to confirm a count either. The inclusion of full crypto transaction histories matters beyond the immediate privacy breach: it hands whoever holds this data a ready-made list of which customers actually hold and move digital assets, the exact targeting information a follow-up scam would need.
This Is a Vendor-Verification Failure, Not a Hack
The pattern here is not new, only the target is. Business email compromise fraud has spent years tricking finance departments into wiring money to a fake supplier by spoofing or hijacking a real counterparty's domain, and the defense every finance team is taught is the same: a domain being real does not make the request behind it real, so verify out of band before anything moves. Revolut's breach is that identical failure on the data side rather than the money side. A domain that genuinely belonged to a government agency was enough to get customer files released, because nothing in the process forced a second, independent check of the actual person or office making the request.
That is the uncomfortable part for any regulated business to sit with: the domain was not fake. Everything an ordinary inbox-level check would have looked for was present and correct. Only a callback to a verified contact, using a number or address obtained independently of the email itself, would have caught it.
What Any Regulated Business Should Check Now
Any EU or UK company that receives and honors official data requests by email, not just banks and fintechs, has the same exposure Revolut just demonstrated is exploitable. Domain authentication, SPF, DKIM, a correct-looking signature block, confirms where an email came from. None of it confirms that the person sending it actually holds the authority they claim, and treating the two as the same thing is exactly the gap this breach went through.
The practical fix is not a new piece of security software. It is a written rule that any request for customer data, however official it looks, gets a call-back verification against a contact obtained independently of the email itself, the same standard that finance teams are already taught to apply before moving money. Under GDPR and, where it applies, DORA, that verification step is also the difference between a documented, defensible process and a breach report that says the request "looked legitimate."
Read next: France's Tax Agency Is Exempt From Its Own GDPR Fines | Your License Photo Sat On Their Server For A Year
