Fraudulent Government Data Requests: How the Attack Works

On 12 September 2026 TechCrunch reported that Revolut confirmed it disclosed sensitive customer information to an unauthorised third party after receiving fraudulent requests sent from a legitimate government agency email domain.

According to the customer notification reviewed by TechCrunch, the exposed data included identity and contact details such as dates of birth, postal and email addresses, and phone numbers, along with copies of identity documents including passports and driver's licences. The notification said the data may also have included verification selfies, account statements, and transaction histories. A Revolut spokesperson told TechCrunch that a limited number of customers were affected.

Two details matter for anyone running a service desk or a legal response function.

First, the requests came from a legitimate government domain. Sender authentication checks such as SPF, DKIM, and DMARC pass when mail genuinely originates from that domain, so the usual phishing signals were absent.

Second, the data disclosed is not revocable. A customer can change a password. They cannot change a passport photo that is now in someone else's hands, and the combination of identity documents, selfies, and transaction history is exactly what is needed to pass identity checks elsewhere.

Why this class of request exists

Email authentication proves the domain, not the request. If an attacker has access to a real government mailbox or a compromised account within that domain, authentication checks confirm exactly what the attacker wants them to confirm.

The process is designed to comply. Legal and support teams are trained that failing to respond to a lawful request has consequences. Attackers exploit that incentive.

Urgency suppresses verification. Emergency framing, references to risk of harm, and short deadlines push staff past the step where they would call the agency back.

Volume hides anomalies. Companies receiving many genuine requests process them as routine work, so one fraudulent request does not stand out.

The requester's story is checkable but rarely checked. Case numbers, officer names, and agency letterheads can be verified, and verification takes time that urgency is designed to remove.

Documents leave the security boundary entirely. Once identity documents are emailed out, no technical control can recall them.

Where the request usually lands

Verify out of band, every time. Call the agency using contact details published by the agency, never a number or address supplied in the request. Record who verified, when, and how.

Use a single intake channel. Route all legal and law enforcement requests to one queue owned by a trained team, so requests cannot arrive directly in a support agent's inbox and be answered informally.

Require dual approval for identity documents. Treat passports, licences, and verification selfies as a separate, higher tier requiring a second approver regardless of urgency.

Write a standing rule for emergency requests. Define what may be disclosed under emergency provisions before verification completes, and keep it narrow. Subscriber identifiers are a different category from full identity document sets.

Log and review disclosures. Every disclosure recorded with requester, legal basis, data categories, and verification evidence, reviewed on a schedule. Patterns of unusual requests appear in that log first.

Rehearse it. Run a tabletop exercise where an urgent request arrives at 7pm from a genuine agency domain and the named officer does not answer the phone. The failure modes surface immediately.

Tell customers what happened, specifically. Notifications that list exactly which data categories were disclosed let customers take targeted action, such as monitoring for identity fraud in the documents involved.

Reporting cited here is current as of publication. Check the linked sources for updates, since details of active incidents change.