Revolut Handed Over Passports to a Scammer Who Faked a Government Email — The GDPR Gap Behind It

On September 12, 2026, Revolut confirmed a data breach with an unusual root cause: nobody hacked its servers. Someone emailed the company.

In its own words, Revolut said 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." Because the request appeared to come from a real, official government mail domain, it made it past whatever process Revolut had for deciding what counts as a legitimate data request — and the company handed over customer identity documents before catching the fraud.

This isn't a CLOUD Act story, and it isn't a "your cloud provider might get subpoenaed" story either. Those are the sovereignty risks we usually write about here — a legal government able to compel disclosure through a real legal process. This is the opposite failure mode: nobody with legal authority asked for anything. A fraudster just made an email look official enough, and that alone was sufficient.

What actually got handed over

Per Revolut's statement and independent reporting from The Next Web, the disclosed data included:

• Passports and driver's licenses
• Identity-verification selfies (the kind collected during KYC onboarding)
• Account statements and transaction histories
• Dates of birth, postal addresses, email addresses, and phone numbers

Revolut has declined to say how many customers were affected (only describing it as "a limited number"), which government agency's domain was compromised or spoofed, which countries were targeted, or how long the fraudulent channel operated before it was caught. The company says its systems and customer funds were not affected, that it blocked the fraudulent address, and that it notified the impersonated agency, law enforcement, and regulators.

Revolut operates in the EU under an ECB-issued banking license via the Bank of Lithuania, plus a separate Lithuanian e-money institution license for its payments entity — the license that lets it serve customers across the whole EEA. That matters here for one specific reason: this is the first time this fraud pattern has landed at this scale against an EU-licensed financial institution handling KYC-grade identity documents, rather than a US social platform handling account metadata.

This is not a new attack — it's a five-year-old playbook that finally hit a bank

The technique Revolut describes has a name in the security community: the fake Emergency Data Request (EDR). Brian Krebs documented it back in March 2022, and it wasn't new even then. The mechanics, per Krebs's reporting:

• Attackers compromise a real police or government email account or domain — via social engineering, credential stuffing with passwords from unrelated breaches, or exploiting vulnerable government web infrastructure to plant backdoors and create fake accounts inside a legitimate domain.
• They then send an "emergency data request," a legal mechanism that lets law enforcement request user data without a subpoena or court order, by asserting there's an imminent risk to someone's life.
• Because emergency requests are explicitly designed to bypass the normal court-order verification step, and because — as one expert quoted by Krebs put it — "there's no real mechanism defined by most Internet service providers or tech companies to test the validity of a search warrant or subpoena," companies that receive a request from what looks like a real government domain often comply fast, sometimes within the hour.

Krebs's reporting lists Apple, Meta (Facebook/Instagram), Discord, Snapchat, Google, Uber and multiple ISPs as prior victims of this exact technique — Discord reportedly complied with one fake request within 30 to 60 minutes. The Revolut incident is not a new class of attack. It's the same five-year-old social-engineering trick, now landing on a company that holds passports and bank statements instead of DMs and IP logs — which is a materially worse outcome per successful attempt, even if the technique itself is old news to anyone who's followed EDR fraud.

Why "it came from a real government domain" isn't a legal basis

Here's the part that's directly relevant if you build anything that processes EU personal data, financial or not: the surface plausibility of a request is not, and has never been, a lawful basis for disclosing personal data.

Under GDPR Article 6(1), processing personal data — and disclosure to a third party is processing — is lawful only if one of six specific grounds applies. The one a company would typically lean on for a government request is Article 6(1)(c): "processing is necessary for compliance with a legal obligation to which the controller is subject." Note what that requires: an actual legal obligation. A specific request, from a genuinely authorized requester, exercising a genuine legal power. "The email domain looked right" satisfies none of that — it's a plausibility signal about the sender, not evidence of a legal obligation to disclose.

This connects directly to Article 5(1)(f), the "integrity and confidentiality" principle: personal data must be processed "in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing." Disclosing a customer's passport and selfie to a fraudster is, definitionally, unauthorised processing — it doesn't stop being a GDPR violation just because the controller was also deceived. The deception explains how it happened; it doesn't change what happened under the regulation.

And the fine exposure is real: Article 83(5) puts violations of the basic principles for processing — explicitly including Articles 5 and 6 — in the higher tier: up to €20 million or 4% of total worldwide annual turnover, whichever is higher. Whether a specific regulator pursues a case here isn't the point for this post. The point is architectural: if your incident-response answer to "why did we disclose this data" is "the request looked legitimate," you don't currently have a documented Article 6(1)(c) legal-basis assessment — you have a plausibility check, and plausibility checks are exactly what this fraud pattern is built to defeat.

What a real EU government data request actually looks like

Part of what makes fake EDRs work is that most companies have never seen what a real, formal cross-border data request from an EU authority is supposed to look like — so a well-formatted email is enough to pass. It isn't a free-text email at all. Since August 2026, the EU's actual mechanism for this is the European Production Order under the e-Evidence Regulation (EU) 2023/1543 — we covered the deadline math and obligations in detail separately, but the relevant point here is structural: a genuine EPO arrives as a standardized, judicially-issued European Production Order Certificate (EPOC), tied to a specific judicial authority in a specific member state, with defined execution deadlines and a defined legal form. It is not an ad hoc plea from an inbox claiming urgency.

That gives you a usable heuristic: any data request that arrives as unstructured prose in an email body, with no reference to a specific legal instrument, case number, or issuing judicial authority you can independently look up, should be treated as unverified by default — regardless of how official the sending domain looks. A genuinely urgent, genuinely legal emergency request can survive a callback verification that takes minutes; a fraudulent one is specifically designed to not survive that delay. Urgency is the fraud vector, not evidence of legitimacy.

Building a verification pipeline instead of a plausibility check

If you're a developer or a small team that occasionally has to handle government or law-enforcement data requests — banks, fintechs, and any GDPR-regulated SaaS with EU users all eventually get one — the fix isn't "read emails more carefully." It's replacing an unstructured inbox with a verification process that doesn't depend on trusting the sender's stated identity.

None of this requires an enterprise trust-and-safety team to stand up. A minimal version you can ship this week:

1. Kill the free-text inbox as your only channel. Even a simple web form that requires structured fields (issuing authority, legal instrument cited, case/reference number, requesting officer's name and a phone number you'll look up independently) forces the requester to commit to falsifiable claims instead of prose.
2. Maintain a short internal registry of known-good contact numbers for the agencies you're actually likely to hear from (your national data protection authority, national police cybercrime units, the financial regulator in your licensing jurisdiction). Look the number up yourself from a source you already trust — never from the request.
3. Hard-code a callback step before any disclosure of identity documents or bulk data, full stop, with no "unless it's an emergency" carve-out — emergencies are the specific case this fraud pattern exploits.
4. Log the legal-basis decision, not just the disclosure. A one-line record — "Art. 6(1)(c), verified via callback to [registry entry], approved by [name], [timestamp]" — is the difference between an assessed lawful basis and a plausibility check, if you're ever asked to justify what you did.
5. Treat "identity-document bulk request" as a distinct, higher-scrutiny request class from routine single-account inquiries — the blast radius of getting this one wrong is categorically worse.

The takeaway

Revolut's engineering and fraud systems reportedly weren't touched — customer funds and the platform itself were fine. The failure was entirely in a process: someone decided a request was legitimate because it came from a domain that looked right, and that decision authorized the release of exactly the kind of data (government ID, biometric-adjacent verification selfies, financial transaction history) that's hardest to walk back once it's out. The "fake emergency data request" trick has a five-year public paper trail. If your organization handles any EU personal data and doesn't yet have a documented, callback-verified process for deciding what counts as a legitimate government or law-enforcement request, this is the incident that should move that from "someday" to this week's engineering backlog — before your inbox is the next domain a fraudster decides looks official enough.