What happened
On 12 September 2026, Revolut confirmed to TechCrunch and Reuters that it disclosed customer information after fraudulent requests arrived from a legitimate government agency email domain. Revolut described the event as an external impersonation scam, said it blocked the address after detection and notified the relevant agency, law enforcement, data-protection authorities and financial regulators.
Potentially disclosed data included names, dates of birth, postal and email addresses, phone numbers, passports, driving licences, verification selfies, account statements and transaction histories. The Block reported that customer notices also listed IBANs, withdrawal records and full transaction histories, including Bitcoin transactions, as potentially shared. Revolut said its systems and customer funds were unaffected.
The cited sources did not publish the affected-customer count, the government agency, the originating email address, the affected market or technical indicators. Attribution posture: Revolut described an unauthorised third party using a legitimate government agency email domain; the agency and actor were not identified.
Why this matters now
The incident did not require compromise of Revolut’s production systems or customer accounts. The failure occurred at a high-trust business process that intentionally releases sensitive data. Financial institutions, telecommunications providers, cloud services, healthcare organisations and online platforms face similar requests and may have workflows that overvalue SPF, DKIM, DMARC, domain reputation or a familiar agency identity without independently validating authority.
Exposed identity documents, contact information and transaction records create durable risks even when funds and account access remain unaffected. The data can support targeted impersonation, fraud, coercion and more convincing follow-on requests. Leadership therefore needs to test both the release control and the post-disclosure response: customer notification, enhanced fraud monitoring, regulator engagement and retrospective review of requests sharing the same agency, address or procedural pattern.
The decision for security leaders
Treat government and law-enforcement disclosure workflows as privileged data-access systems. Require independent verification using a pre-established agency directory or known contact, validate legal authority and minimise each response to the approved customer and data scope. Emergency processes should retain dual control rather than replacing it with sender-domain trust.
Order a retrospective review of recent sensitive requests from government domains, focusing on repeated requesters, unusual customer selection, broad date ranges and requests involving identity documents or transaction histories. Define when security, privacy, legal, fraud and executive leadership must be engaged before fulfilment, and preserve the request, verification record and released dataset as evidence.
Evidence of closure
- Approved standard requires independent verification for sensitive government requests.
- Retrospective review records the disposition of requests using similar trust paths.
- Incident case file identifies released fields and notification decisions.
- Monitoring covers repeat targeting of affected customers.
The Security.io assessment
The confirmed fact is an unauthorised disclosure caused by a fraudulent request using a legitimate government domain. The cited evidence does not establish how the government email identity became available, whether the agency itself was compromised, how many customers were affected or whether one jurisdiction was targeted. Those unknowns warrant medium confidence on scope, not doubt about the disclosed event.
The central control failure is authority validation, not conventional network intrusion. Organisations should not overcorrect by distrusting all electronic requests; they should distinguish message authentication from requester authorisation. Closure depends on proving that high-risk disclosures require independent verification and that prior requests sharing the same trust path have been reviewed.
Questions for the morning meeting
- Does every sensitive government request receive verification through a second trusted channel?
- Can disclosure systems detect repeated or unusually broad requests from one government identity?
- Who can suspend fulfilment when sender authentication passes but authority remains uncertain?