2026-09-13 · view entry permalink →
Revolut discloses a customer KYC data breach after fulfilling a fraudulent request sent from inside a genuine government agency's own email domain
Revolut confirmed to TechCrunch on 2026-09-12 that it disclosed sensitive customer data after receiving a fraudulent information request sent from "an unauthorised email account...using the official government agency's email domain" (Revolut, via Security Affairs, 2026-09-12); Security Affairs assesses the attacker either registered a rogue mailbox within that domain or compromised an existing one. Because the message carried valid domain-authentication credentials, Revolut's compliance and KYC-response process treated it as authentic and fulfilled it: exposed data included full name, date of birth, occupation, postal and email address, phone number, passport or driver's-licence copies, verification selfies, IBAN and account statements, withdrawal records and full transaction history including Bitcoin (Security Affairs, 2026-09-12). No Revolut system was compromised and no malware was involved; the entire incident was a social-engineering compromise of the legal and regulatory data-request channel rather than a technical intrusion. Revolut says a "limited" number of customers were affected and declines to name the government agency, the country, or the customer count. Revolut discovered the fraud only when it independently contacted the agency to verify the request and was told the agency never sent it; it has since blocked the sending mailbox and notified the agency, law enforcement and financial regulators.
The same weakness applies to any organization whose legal or regulatory data-request process trusts that a request's sending domain is proof of the sender's authority: an attacker who obtains or spoofs access to a single mailbox on that domain can submit an urgent, seemingly authentic request that bypasses the normal verification a company would otherwise apply. Here that pattern reached a major fintech's KYC/AML compliance channel, and the entire compromise happened at the request-verification step: no phishing link was clicked and no credential was stolen, only an email that domain-authenticated correctly and asked for the right kind of data in a plausible way.
For any organization that operates a legal or regulatory data-request intake process, the transferable lesson is that domain-level email authentication (the same trust SPF, DKIM and DMARC exist to establish) is not proof of institutional authority: an adversary who controls, or convincingly spoofs, a single mailbox on a trusted government or law-enforcement domain can defraud any recipient who verifies a request only by checking that it came from the right domain. This cuts both ways for a public-sector authority: any authority that itself issues legal data requests to third parties (banks, telcos, cloud providers, ISPs) as part of investigations should assume that a compromise of its own mail infrastructure could be used to defraud those third parties in its name, and should expect the recipients of its own legitimate requests to apply out-of-band verification rather than treat that as an insult to its authority.
Revolut received a request for customer information that appeared to come from a legitimate government agency. The request came from an unauthorised email account sent directly using the official government agency's email domain.
As the communication carried valid domain authentication credentials, it was fulfilled under the reasonable belief that it was an authentic government agency request.
Revolut recently identified a sophisticated external impersonation scam where an unauthorised third party utilised a legitimate government agency domain email to submit fraudulent requests for information.