Revolut Sent Customer Data to Scammers Posing as a Government Agency

Revolut confirmed it sent sensitive customer data to an unauthorized third party after receiving fraudulent requests from a legitimate government email address.

The confirmation was reported on September 12, 2026. The requests impersonated a government agency. Revolut treated them as authentic and disclosed customer information. The company later determined the requests were fraudulent TechCrunch.

The data included birth dates, postal addresses, email addresses and phone numbers. It also included copies of identity documents, including passports and driver's licenses TechCrunch. That combination is high-value for identity fraud. It links a real-world identity to contact channels and to a government-issued ID in one set.

Other categories may also have been exposed. Revolut said the incident may have also included verification selfies, account statements and transaction histories. Separate reporting added Bitcoin transaction records BeInCrypto, and IBANs, the standard account numbers used for bank transfers HackRead. For affected users, that widens the exposure from static identity-check files to account activity and payment identifiers.

A Revolut spokesperson said a limited number of customers were impacted and that the company contacted those customers directly. Revolut did not disclose the exact number. It also declined to disclose which government agency was impersonated.

Revolut said it blocked the email address used in the scam after discovery. It alerted the relevant government agency, law enforcement and relevant regulators. The company stated that its systems and customer funds are unaffected.

Revolut has more than 80 million customers globally and operates as a bank in more than 30 countries.

The broader context here is request authentication, not perimeter defense. Banks and fintech companies routinely process police and regulator data requests under legal deadlines. The question is how a request is proven authentic. A legitimate domain alone is weak assurance, much as a return address alone does not prove who mailed a letter. Mailboxes get compromised. Delegated access gets abused. Display names mislead.

Looking at what this means for disclosure workflows, the controls that matter are familiar to security teams. A callback to a known contact on a separate channel. A dedicated law enforcement portal with mutual authentication rather than inbound email. Cryptographic signatures, code that proves who sent a message, on requests. Separation between intake, review and release. Tamper-proof logging of who approved what and when. None of that removes the legal obligation to respond quickly. It changes the trust assumption from domain equals authority to verify, then release.

In my view, the incident also shows why identity-check stores need data minimization and tiered access. Passports, selfies, statements and transaction histories do not need to travel together in response to every request. Scoping a response to the specific legal demand limits harm when authentication fails. For teams building these pipelines, that scoping logic is as important as the inbox it starts in. Done well, it makes this class of impersonation harder to monetize and easier to contain.