The short answer
An attacker got sensitive Revolut customer data not by breaking into an app, but by asking for it convincingly. Using an unauthorised account under a legitimate government-agency email domain, they submitted fraudulent “requests for information” that passed domain authentication and looked like a genuine official request. Staff released the data through Revolut’s standard legal-compliance disclosure process. The exposed records included identity and contact details and copies of passports and driving licences, and may have included verification selfies, account statements and transaction histories. Revolut said its systems and customer funds were unaffected, and reporting suggests a limited group — around 680 customers — was contacted. For anyone building fintech software, the takeaway is uncomfortable: the vulnerability was a business process, not a line of code.
This is the failure mode that classic application security misses. There was no injection, no unpatched CVE, no leaked credential. A trusted workflow — responding to official data requests — did exactly what it was designed to do, for a request that only looked authorised. The fix is not a patch; it is redesigning how bulk disclosure of personal data is authorised, verified, minimised and logged.
What happened at Revolut?
Revolut, one of Europe’s largest fintechs with tens of millions of users, disclosed that it had identified what it called a sophisticated external impersonation scam. An unauthorised third party used an email account operating under the official domain of a government agency to submit requests for customer information. Because the messages carried valid domain authentication and matched the form of a genuine official request, Revolut staff processed them as a routine legal obligation and released the data.
The company was careful to draw a line: its systems, its app and its core banking infrastructure were not compromised, and customer funds were safe. What failed was the human-and-process layer that sits around every regulated financial institution — the machinery for answering law-enforcement and government data requests. Revolut said that on detection it immediately blocked the address and notified the relevant government agency, along with law-enforcement, data-protection and financial regulators. It has not named the agency or disclosed the domain involved.
The data itself is the kind that makes this incident serious rather than routine. Reporting indicates the exposed records included customers’ dates of birth, postal and email addresses and phone numbers, together with copies of identity documents such as passports and driving licences — and potentially the verification selfies, account statements and transaction histories collected during onboarding. That is a near-complete identity-theft and account-takeover kit for each affected person, which is exactly why breach-notification and data-protection compliance obligations bite hard here even though the customer count appears limited.
Why did a fake request work?
The uncomfortable detail engineers should sit with is that every technical control did its job. The email was not forged. It genuinely came from the domain it claimed, passing the SPF, DKIM and DMARC checks that exist precisely to stop spoofing. The problem is that those controls answer only one question — did this message really come from this domain? — and stay silent on the one that actually matters for disclosure: is the person behind this account authorised to receive this data?
Authentication is not authorisation. A mailbox that is compromised, rogue, or freshly created under a legitimate domain sails through every authentication check while being wholly illegitimate. When a business process treats “the email authenticated” as sufficient grounds to hand over passports and financial history, it has quietly collapsed those two distinct questions into one. Attackers understand this gap well; it is the same logic behind the fraudulent Emergency Data Requests that have plagued US tech platforms, and it is now firmly a fintech problem too.
There is a second structural weakness: the blast radius of a single request. If one approved disclosure can return a full bundle — identity documents, selfies, statements, transaction history — then one successful impersonation yields a catastrophic amount of data. A system designed around least privilege and data minimisation, where each request returns only the narrow field set it can justify and anything broader triggers additional review, turns a breach into a near-miss. The Revolut incident is a reminder that how much a single trusted action can expose is a design decision teams make, consciously or not.
What it means for US & EU software teams
First, treat the official-request workflow as a first-class attack surface. Most fintech and SaaS teams pour security effort into the app, the API and the cloud, and leave the back-office processes — law-enforcement requests, subpoena handling, VIP support overrides, account-recovery escalations — to policy documents and human judgement. Those are the paths that disclose the most sensitive data with the least code review. If you cannot describe, in engineering terms, how a bulk personal-data disclosure is authorised, verified and logged, that is your highest-value gap.
Second, build out-of-band verification into the disclosure path, not around it. Domain authentication should be table stakes, but the decision to release data must depend on an independent confirmation: a call-back to a known-good number for the agency, a request submitted through an official portal rather than free-text email, or a signed request validated against a maintained allow-list of authorised requesters. The point is to break the attacker’s single channel of control. If the only proof of authorisation travels in the same email that carries the request, you have no proof at all.
Third, make data minimisation and audit logging non-negotiable on any disclosure endpoint. Design the support and compliance tooling so that no single action can dump a customer’s entire identity file; require step-up review for anything beyond a narrow field set; rate-limit bulk exports; and log every access immutably so an anomaly is detectable in hours, not weeks. And because much of this data is personal data, GDPR still governs: Article 5 minimisation, Article 32 security-of-processing, and the 72-hour breach-notification clock all apply. Teams that engineer one well-governed disclosure layer — authenticated, authorised, minimised, logged — satisfy both the security and the regulatory demand at once, instead of discovering the gap the way Revolut did.
What to do now
- Map every path that discloses personal data to an outside party. Law-enforcement and government requests, regulator requests, partner data-sharing, support overrides, account recovery. For each, write down who authorises it, on what evidence, and what it can return.
- Separate authentication from authorisation explicitly. Confirm the message is genuine (SPF/DKIM/DMARC) and confirm the requester is entitled (out-of-band verification, official portal, signed and allow-listed requests). Never let one imply the other.
- Enforce least privilege on the payload. A single approved request should return the minimum field set that satisfies it. Full identity documents, selfies and financial history in one response should require elevated, separately reviewed authorisation.
- Add rate limits, human-in-the-loop review and immutable audit logs. Bulk or unusual disclosures should trip a second reviewer and an alert. Every access should be logged in a form that supports fast investigation.
- Rehearse the attack, and the aftermath. Include social-engineering of the request process in penetration tests, and confirm your GDPR breach-notification path to regulators and affected users is ready to run before you need it.
Frequently asked questions
What happened in the Revolut data breach?
In September 2026, Revolut confirmed that an unauthorised third party used a legitimate government-agency email domain to submit fraudulent requests for customer information. Because the messages passed domain authentication and looked like a genuine official request, staff fulfilled them through the company’s standard legal-compliance disclosure process. Revolut said its systems and customer funds were not affected; it was a social-engineering abuse of a trusted process, not a technical intrusion into its app or core banking systems.
What customer data was exposed?
Customers’ identity and contact details — date of birth, postal and email addresses and phone numbers — and copies of identity documents such as passports and driving licences. Reporting indicates the data may also have included verification selfies, account statements and transaction histories. Revolut called the number of affected customers limited and contacted them directly; a Financial Times report put the figure at roughly 680 people.
How did the attacker get the data without hacking Revolut?
They did not exploit a software vulnerability. They sent requests from an unauthorised account operating under the official domain of a government agency. The messages carried valid domain authentication (SPF, DKIM and DMARC alignment), so they were not spoofed and appeared authentic, and staff processed them as a legitimate legal request. The gap was between authentication — proving the message came from that domain — and authorisation — proving the sender was entitled to the data.
Why does email domain authentication not stop this attack?
SPF, DKIM and DMARC confirm a message genuinely originated from a domain and was not forged in transit. They say nothing about whether the account or person behind it is authorised to make the request. A compromised, rogue or newly created mailbox under a legitimate domain passes every authentication check while being illegitimate. Bulk disclosure of sensitive data must therefore rely on out-of-band verification and authorisation checks, not on the fact that an email authenticated correctly.
What should fintech and software teams change after this incident?
Treat the law-enforcement and government data-request workflow as a first-class attack surface. Verify official requests out of band against a known-good contact; apply least privilege and data minimisation so a single disclosure cannot return full passport scans, selfies and statements at once; require human review, rate limits and full audit logging on any endpoint that discloses bulk personal data; and rehearse social-engineering scenarios in penetration tests. Under GDPR, confirm your breach-notification path to regulators and users is ready before you need it.
Sources
TechCrunch — Revolut confirms customer data breach through fake government requests
The Register — Revolut falls for fake government requests, hands over customer data
BleepingComputer — Revolut discloses data breach exposing financial info, passports