The Email Authenticated. The Requester Did Not.

On Friday 11 September, Revolut customers began receiving a notice that copies of their identity documents and their contact details had been sent to a fraudster, and that their verification selfies, their IBANs and their complete transaction histories may have gone with them. Nobody broke into Revolut. No malware ran, no credential was stolen, no vulnerability was exploited. Somebody sent an email from a real government agency's domain asking for the data, the email passed Revolut's domain authentication checks, and staff sent the files. The company's own words are that the request "was fulfilled under the reasonable belief that it was an authentic government agency request".

Revolut confirmed the incident to TechCrunch on 12 September and described it as "a sophisticated external impersonation scam". A "limited" number of customers were affected; by 13 September a spokesperson was calling it "very limited". The company has not said how many, which agency's domain was used, which country the request came from, or when it was received and answered, and it has declined to name the agency "while investigations remain ongoing". What it has said is enough to make this a board matter for every organisation that holds customer data, not only banks: the channel that leaked was the lawful-request process, and almost every company has one.

What happened

The public record is thin on dates because Revolut has published no statement beyond its customer notice and spokesperson comments. What is established is this.

• Date not disclosedRevolut receives a request for customer information from an email account on a legitimate government agency's domain. The account is unauthorised: either created inside the agency's environment or an existing mailbox taken over. Revolut has not said which. The notice describes the message as carrying "valid domain authentication credentials".
• Date not disclosedThe request is fulfilled. The notice lists the data that was or may have been disclosed: full name, date of birth and occupation; postal address, email and phone; a copy of the identity document (passport or driving licence) and the facial verification image; account statements including IBAN, account status, opening date and wallet reference; and withdrawal records and full transaction history, including Bitcoin. Revolut states that no biometric facial telemetry was involved.
• Date not disclosedRevolut contacts the agency to validate the request and alert it to the unauthorised account. The request is established as fraudulent. Revolut blocks the email address and begins applying what it calls precautionary protections to the affected accounts.
• 11 to 12 September 2026Customer notices begin circulating on Friday 11 September. In the early hours of Saturday 12 September, UK time, former Mt. Gox chief executive Mark Karpelès posts his copy and says he is among those affected, and the investigator ZachXBT publishes the notice and assesses that the operation appears to have been aimed at high-net-worth users.
• 12 to 13 September 2026Revolut confirms the incident to TechCrunch and The Block. It says it has alerted the government agency, law enforcement, data protection authorities and financial regulators, and that systems and customer funds are unaffected. It declines to name the agency, the market or the number of customers. By 13 September the affected group is described as "very limited".

Email authentication answers one question: did this message come from that domain? It did. Every question that mattered sat outside the check. Sources: Revolut customer notice as reported by TechCrunch and The Block.

Why this one is different

Data breaches at fintechs are not rare. Three things make this one worth a leadership team's time.

The control that failed was working. SPF, DKIM and DMARC are the industry's answer to spoofed email, and most security programmes treat a message that passes all three from a government domain as trustworthy. That is what the checks are for. But they verify the domain, not the person, and not the authority. An attacker who holds a mailbox inside the real domain, by phishing an employee or by exploiting a weak account-creation process, inherits the domain's reputation in full. Revolut's phrasing, "valid domain authentication credentials", is accurate and is exactly the problem: the message was authentic, and the request was not.

The exit was a business process, not a system. Every organisation that holds personal data receives requests from police, regulators, tax authorities and courts, and most have a team, often in legal or compliance, whose job is to answer them. That team is measured on responsiveness. It sits outside the security operations centre. Its output is, by design, a bulk export of exactly the data an attacker would otherwise have to steal. The FBI warned about this in a Private Industry Notification on 4 November 2024: criminals were gaining access to compromised government and police email accounts to send fraudulent emergency data requests to companies. Krebs on Security, reporting on the notification, found one criminal vendor advertising the service at $1,000 to $3,000 per successful request. Kodex, a platform that screens such requests for around 60 technology companies, told Krebs on Security at the time that 30% of the 1,597 emergency requests it processed in twelve months failed a second-level verification. The pattern has been documented for two years. A regulated bank with more than 80 million customers has now confirmed being caught by it.

The notice lists everything a regulated firm is obliged to collect for identity verification, in one export. Source: Revolut customer notice, 11 September 2026.

The data is the full KYC file. A card number can be reissued. A passport scan, a verification selfie and a transaction history tied to a real identity cannot. That combination is what a fraudster needs to open accounts, pass liveness checks at other institutions, target the individual with a convincing impersonation of their own bank, or, in the case of the Bitcoin histories, identify who is worth extorting. ZachXBT's assessment that the targets were high-net-worth is an assessment, not a Revolut statement. If it is right, the request was not a fishing trip. It was a shopping list.

The commercial exposure for UK organisations

Regulatory. UK GDPR Article 32 requires security appropriate to the risk. The Data Protection Act 2018 provides an exemption that allows disclosure to public authorities for the prevention or detection of crime, but it is permissive, not compulsory: it allows a controller to disclose where the request is genuine and necessary. It does not relieve the controller of responsibility for checking that it is. A disclosure to an impostor is a personal data breach, which starts Article 33's 72-hour notification clock to the ICO and, where the risk to individuals is high, a duty to tell them under Article 34. Revolut says it has notified data protection authorities. For a firm that holds UK and French banking licences and, since 3 September, conditional OCC approval for a US national bank, the regulators asking questions will not be limited to the ICO.

Financial. The direct cost is remediation, notification, monitoring and legal. The larger exposure is the secondary fraud that follows a full KYC file into the market, and the liability arguments when a customer who lost money to an impersonation scam points out that the impersonator had their passport, their statements and their transaction history because the bank sent them. Revolut is reportedly weighing a listing at a valuation of up to $200bn. Incidents that go to a firm's judgement rather than its technology are the ones that surface in a prospectus.

Contractual. Any UK business that processes customer data on behalf of others, or that relies on suppliers to do so, has this channel somewhere in its supply chain. A payroll provider, a telecoms reseller, a property platform, a recruitment firm: each holds identity documents and each receives official-looking requests. Supplier questionnaires almost never ask how lawful requests are verified. After this week, they should.

Governance. The question for a board is who owns the lawful-request process and what its verification standard is. In most organisations the honest answer is that legal or compliance owns it, the standard is "it looked genuine and came from the right domain", and nobody in security has ever reviewed it. That is a privileged data-access path with weaker controls than a junior administrator's login.

What leaders should do now

1. Put the lawful-request process on the risk register with a named owner. Treat it as what it is: a route by which bulk customer data leaves the organisation on the strength of an email. It needs an owner, a documented verification standard and a review date, exactly like any other privileged access path.
2. Mandate out-of-band verification before any release. Reply to nothing. Call the agency on a number obtained independently, confirm the officer, the case reference and the legal basis, and record the call. Where a portal exists for official requests, route through it and refuse email. The cost is a phone call per request. The cost of skipping it is now public.
3. Tier the response to the sensitivity of the data. Confirming that an account exists is one decision. Releasing identity documents, selfies and full transaction histories is another. Set a threshold above which two people must approve, one of them outside the team that received the request, and require legal sign-off for anything that includes identity documents.
4. Bring the channel inside monitoring. Log every request, every approval and every export. Alert on volume, on first-time requesters from a domain, and on requests naming multiple customers. If the security team cannot see the lawful-request queue, it cannot see one of the most valuable data exits in the company.
5. Run the tabletop this month. Send the legal and compliance team a realistic request from a plausible domain and see what happens. The exercise costs a morning. It will tell the board more about real exposure than any questionnaire.

Five decisions an executive can take this week. None of them requires new technology. Garzon Cyber Solutions, September 2026.

Three questions for the board

1. Who in this company can release a customer's identity documents to an outside party, on what evidence, and who else has to agree?
2. If a request for customer records arrived this morning from a real government domain, what would we do to verify it beyond reading the email, and would security ever know it had arrived?
3. How many of our suppliers hold our customers' identity documents, and have we ever asked any of them the first two questions?

The strategic takeaway

The industry has spent a decade hardening the perimeter against people who break in. This incident involved nobody breaking in. It exploited the one route by which an organisation is expected to hand data out on request, and it worked because that route was built for compliance and never designed for adversaries. The firms that will avoid the next version of this are the ones that treat every official request as a claim to be verified rather than an instruction to be processed, and that give the process the same ownership, logging and two-person control they already apply to production access. That is not a technology decision. It is a decision about who is allowed to say yes.

Confidence note

Confirmed. That Revolut disclosed customer data to an unauthorised third party in response to a request sent from an unauthorised account on a legitimate government agency's email domain; the categories of data listed; that the notice describes the request as carrying valid domain authentication credentials and being fulfilled under the reasonable belief it was genuine; that Revolut blocked the address, contacted the agency, notified law enforcement, data protection authorities and financial regulators, and describes affected customers as "limited" in number; and that systems and customer funds were unaffected. These are Revolut's own statements, from the customer notice reproduced by TechCrunch, The Block and Security Affairs, and from spokesperson comments to TechCrunch and The Block on 12 September 2026 and to CyberInsider on 13 September. Revolut's customer count of more than 80 million, its conditional US charter on 3 September 2026, and its recent UK and French banking licences are from TechCrunch and Reuters. The FBI notification of 4 November 2024 is from the FBI; the $1,000 to $3,000 vendor price and the Kodex figures are from Krebs on Security, 9 November 2024.

Assessed. That the operation targeted high-net-worth users is ZachXBT's assessment and is not confirmed by Revolut. That the checks in question were SPF, DKIM and DMARC is our inference from Revolut's phrase "valid domain authentication credentials"; Revolut has not named them. Which of the listed data categories were disclosed to each customer is also not confirmed: TechCrunch reports identity and contact details and identity documents as exposed, with selfies, statements and transaction histories described as possibly included. Whether the mailbox was created or taken over is unknown.

Not known. The number of customers affected, the agency and country involved, when the request was received and fulfilled, whether more than one request was made, and whether other firms received requests from the same mailbox. No regulator has commented publicly at the time of writing. Mark Karpelès' statement that he was affected is his own.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification and specialist technology recruitment as one integrated capability for organisations in the UK, EU and Americas. We are a young firm and we publish our own research. Founded by Jonathan Garzon, whose career was spent selling cybersecurity, compliance and technology to security and technology buyers.