Quick Answer
The Revolut data breach 2026 happened when an unauthorized party used a legitimate government agency’s email domain to submit a fraudulent request for customer information, and Revolut staff fulfilled it. Nothing was hacked. Customer funds were unaffected. But sensitive records, including identity documents and transaction histories, were disclosed to the attacker in what the company calls a social engineering attack rather than a technical intrusion
What Happened: Timeline of the Revolut Data Breach 2026
Revolut is a UK-based fintech with more than 80 million customers across over 30 countries. In mid-September 2026, it confirmed that it had disclosed sensitive customer data to an unauthorized third party. The company described the Revolut data breach 2026 as “a sophisticated external impersonation scam”, framing it as a case of financial data breach through social engineering rather than a system intrusion
Here’s the sequence as currently documented.
- September 11 to 12, 2026: An attacker submitted a fraudulent request for customer information using an email address on a legitimate government agency’s domain. The message carried valid domain authentication, so Revolut staff fulfilled it under the reasonable belief it was an authentic government request
- September 12, 2026: Crypto investigator ZachXBT publicly shared Revolut’s breach notification to affected customers, noting the incident appeared targeted at high-net-worth users. Revolut confirmed the incident to TechCrunch the same day.
- September 14, 2026: Revolut formally disclosed the breach, telling affected customers the request “carried valid domain authentication credentials” and explaining that staff acted in the reasonable belief it was a genuine government agency request.
Revolut has not named the government agency involved, the number of affected customers, or which markets were impacted. The company says it has since blocked the fraudulent email address, alerted the impersonated agency, and notified law enforcement, data protection authorities, and financial regulators
Important distinction: the Revolut data breach 2026 is separate from an unverified claim, circulated in mid-2026, of 75 million Revolut records for sale on a cybercrime forum. Revolut disputed that listing after finding no valid identifiers in the sample data (per The CyberSec Guru, Sept 2026, unconfirmed independently). Don’t conflate the two stories.
What Data Was Exposed in the Revolut Data Breach
Based on the notification Revolut sent to affected customers, the customer data exposure may have included the following
- Full name, date of birth
- Postal and email addresses, phone numbers
- Copies of identity documents (passports, driver’s licenses)
- Verification (KYC) selfies
- Account statements and complete transaction histories, including Bitcoin-related activity
Revolut explicitly stated that no biometric facial-recognition templates, card details, PINs, or passwords were part of the disclosure, and that customer funds and Revolut’s core systems were unaffected.
That distinction matters operationally. A new password protects nothing here, because no credential was stolen. The exposure is identity-document and financial-history data: the raw material for identity theft, targeted phishing, and account-takeover attempts against other services, not a way back into Revolut itself.
How the Attack Worked: Fraudulent Emergency Data Requests Explained
The Revolut data breach 2026 fits a well-documented and growing attack pattern: the fraudulent emergency data request (EDR), a form of social engineering attack aimed at the request-intake process rather than at a login page.
An emergency data request is a legitimate mechanism that lets law enforcement obtain customer data quickly, without a warrant, when there’s a credible claim of imminent harm. The exception exists because in a real emergency, waiting for a court order can cost a life.
Criminals abuse that same exception: they compromise or spoof a government or law-enforcement email account and submit a request that looks, technically, identical to a real one (FBI Private Industry Notification 20241104-001, Nov 4, 2024).
The FBI has warned since November 2024 about compromised US and foreign government email addresses being used to submit fraudulent EDRs, extracting personally identifying information from companies that have no reliable way to distinguish a genuine emergency request from a forged one on the wire (FBI PIN 20241104-001, Nov 4, 2024).
This has since become a documented criminal service. Research published by Kodex describes fraudulent-EDR-as-a-service listings running from roughly $100 for basic how-to kits to $1,000 to $3,000 per successful completed request, with some vendors advertising turnaround under an hour (Kodex, “Fraudulent Emergency Data Requests”).
Here’s the critical technical point: domain authentication is not proof of authorization. SPF, DKIM, and DMARC confirm that an email genuinely originated from a given domain. They say nothing about whether the person who sent it was authorized to send it, or whether that mailbox itself has been compromised. Revolut’s own account of the incident makes this explicit: the company confirmed the request passed its technical domain checks and was answered on that basis. The forgery wasn’t in the email’s technical origin. It was in who was actually behind the keyboard.
CyberInfos Analyst Insight
What makes this incident worth studying isn’t the sophistication of the attack. CyberInfos assesses that fraudulent EDRs are, mechanically, a fairly simple social-engineering technique. What’s notable is how little technical compromise was required to extract high-value data from a regulated financial institution with mature security controls. No malware. No credential theft. No infrastructure breach. Just a plausible-looking request routed through the process built to move fast in emergencies.
A common mistake organizations make is treating “verified sender domain” as equivalent to “verified requester identity.” Those are two different claims, and conflating them is exactly the gap this attack class exploits. CyberInfos assesses that any organization handling law-enforcement, regulatory, or “urgent” data requests as a routine part of compliance operations (banks, telecoms, cloud providers, identity-verification services) carries the same exposure Revolut did, regardless of how strong their perimeter security otherwise is.
Why This Matters Now: Pretexting Is a Rising Attack Vector
The Revolut data breach 2026 lands alongside broader industry data showing that pretexting is growing as an initial access vector. Pretexting is social engineering built on impersonation and manufactured urgency, rather than a malicious link or attachment.
Verizon’s 2026 Data Breach Investigations Report, drawing on more than 22,000 confirmed breaches, found the human element present in 62% of breaches and identified pretexting as reaching 6% of breaches as an initial access vector, enough to warrant its own tracked category for the first time (Verizon 2026 DBIR, via Push Security analysis, Aug 2026).
The same report notes that traditional anti-phishing training doesn’t transfer well to this category. Teaching someone to check a sender’s email address doesn’t help when the domain genuinely is legitimate, and the manipulation happens through urgency and authority rather than a malicious link. That’s precisely the dynamic Revolut described: a request that passed every technical check because the underlying premise, a real agency sending from its real domain, was true.
Regulatory and Legal Fallout
Revolut operates under multiple, overlapping regulatory regimes, and the Revolut data breach 2026 touches several of them.
- GDPR (EU/UK): Article 33 requires notifying the relevant supervisory authority of a personal data breach; Article 34 requires notifying affected individuals when the breach poses a high risk to their rights. Article 82 allows individuals to claim compensation for material or non-material damage (GDPR Articles 33/34/82, as cited by Zyphe, Sept 14, 2026).
- DORA (EU): As a licensed EU entity, Revolut Bank UAB falls under the Digital Operational Resilience Act, which requires ICT-incident reporting and governance of operational risk from social engineering against critical processes (Zyphe, Sept 14, 2026).
- UK oversight: UK-facing operations bring FCA principles and UK GDPR obligations, overseen by the ICO, which was also engaged during Revolut’s earlier 2022 breach (Zyphe, Sept 14, 2026).
- India relevance: Revolut has been expanding its India presence (TechCrunch, Sept 12, 2026), which brings India’s Digital Personal Data Protection (DPDP) Act into scope for any Indian customer data involved in a future incident of this kind. It’s a useful reminder for Indian fintechs and their compliance teams that the same EDR-fraud pattern applies regardless of jurisdiction.
This isn’t Revolut’s first breach. In September 2022, Revolut disclosed a separate incident in which attackers used a phished employee credential to access the personal, contact, and partial payment data of 50,150 customers, including roughly 20,687 in the European Economic Area.
That incident was investigated by Lithuania’s State Data Protection Inspectorate, the lead GDPR supervisory authority for Revolut’s EEA entities. The attack vector differed. A phished credential is not a forged government request. But the underlying theme is the same: the human and process layer, not the technical perimeter, is where Revolut’s most consequential incidents have originated.
How Organizations Can Prevent Authority Impersonation Attacks
The lesson of the Revolut data breach 2026 for every business, not just fintechs, is that the fix for a fraudulent-EDR-style social engineering attack isn’t better email filtering. It’s changing how “urgent, official-looking” requests get processed at all.
- Independent, out-of-band verification. Never validate a request using contact details supplied in the request itself. Call the requesting agency back using a number sourced independently: a published directory, a prior verified contact, or an official government portal, not a phone number in the email signature (CyberHoot, “Emergency Data Request (EDR)”).
- Dual approval for high-risk disclosures. Any request for identity documents, financial history, or bulk customer data should require sign-off from at least two authorized people, one of whom has no involvement in the original intake.
- A dedicated intake and trust-scoring process. Specialized verification platforms exist specifically to screen and authenticate law-enforcement and government data requests against known department rosters, rather than relying on inbox judgment calls.
- Immutable audit trails. Log every legal or regulatory data request received and every approval decision made, and review the logs periodically for anomalous patterns: repeated requests from a newly active government account, unusual request volume, or requests inconsistent with an agency’s normal process.
- Train the process, not just the inbox. Standard phishing awareness training teaches people to scrutinize suspicious senders. It does not teach a compliance or support team to slow down and independently verify a request that looks entirely legitimate. That requires a specific, documented “stop and verify” step built into the workflow itself, not a training module.
- Data minimization on release. Even a verified request should trigger a scoped response, only the specific data legitimately required, rather than a full customer file. That limits the blast radius if verification is later found to have failed.
What Revolut Customers Should Do Now
- Check the Revolut app directly for a breach notification. Don’t rely solely on email, since a message referencing your account isn’t proof it’s from Revolut.
- If you’re an affected EU/UK customer, you can file a subject access request under GDPR Article 15 to see exactly what data was held and disclosed.
- Watch for follow-on phishing that uses the leaked details (address, ID document data, transaction history) to appear more credible than a generic scam attempt.
- Since login credentials weren’t part of the disclosure, a password reset doesn’t address this specific exposure. The risk here is identity theft and targeted social engineering, not account takeover.
- If you believe you’re affected and haven’t heard from Revolut, contact Revolut support directly through the official app rather than any link in an unsolicited message.
FAQ
What happened in the Revolut data breach 2026?
Revolut disclosed customer data to an unauthorized party who submitted a fraudulent request using a legitimate government agency’s email domain. The company says the request passed technical checks and was fulfilled under a reasonable belief it was authentic.
Was Revolut hacked?
No. Revolut says its systems, mobile app, and customer accounts were not compromised, and no funds were accessed. The incident was a social-engineering request, not an intrusion.
What data was exposed in the Revolut breach?
Reportedly identity and contact details, copies of passports and driver’s licenses, verification selfies, account statements, and transaction histories, potentially including Bitcoin activity. Passwords, PINs, and biometric templates were not included.
How many customers were affected?
Revolut has described the number as “limited” but has not disclosed a specific figure or which markets were affected.
What is a fraudulent emergency data request (EDR)?
It’s when a criminal uses a compromised or spoofed government or law-enforcement email account to request customer data under the emergency exception that lets companies disclose data quickly without a warrant (FBI PIN 20241104-001).
Why didn’t email authentication catch the fake request?
Because domain authentication (SPF/DKIM/DMARC) confirms an email came from a real domain. It doesn’t confirm the sender was authorized to use it, or that the mailbox itself wasn’t compromised.
How can my organization prevent this kind of attack?
Verify high-risk requests through an independent, out-of-band channel, require dual approval for sensitive data releases, and log every request and decision for audit review. See the prevention checklist above.
Actionable Checklist: Preventing Authority Impersonation Attacks
- Never verify a data request using contact details supplied in the request itself
- Independently source a callback number for the requesting agency (directory, prior verified contact, official portal)
- Require dual approval for any release of identity documents, financial history, or bulk customer data
- Route law-enforcement/government requests through a dedicated, logged intake process, not general inboxes
- Maintain immutable audit logs of every request and approval decision
- Review logs periodically for anomalous request patterns
- Apply data minimization: release only what’s specifically required, even for verified requests
- Build “stop and verify” into the workflow itself, not just into annual awareness training
Final Thoughts
At its core, the Revolut data breach 2026 is a fake government request that succeeded not through malware or stolen credentials but through a process built for speed. It’s a reminder that a company’s technical perimeter can be entirely intact while its most sensitive data still walks out the door, because the request that took it looked exactly like one Revolut was obligated to answer.
No malware, no stolen credentials, no system compromise. Just a forged government email and a process built for speed rather than verification.
For security teams, the immediate action isn’t rewriting phishing training. It’s auditing how your own organization handles “urgent” official requests today, and whether a single email, however authentic it looks, could still walk sensitive data out the same way it did at Revolut.
Longer term, treat every request-intake workflow as a target in its own right: log it, verify it out-of-band, and require more than one person’s judgment before high-risk data leaves the building.
CyberInfos will update this article as Revolut, regulators, or the impersonated agency release further confirmed details.
