What happened
On September 14, 2026, AML Intelligence reported that Revolut had confirmed an unauthorised disclosure following fraudulent government requests. The fraudulent requests came from an email account operating inside a legitimate government-agency domain. Reporting indicates Revolut treated the communications as authentic and released sensitive customer information to an unauthorised third party. The incident is therefore a failure of request authentication and approval rather than a reported intrusion into Revolut’s systems.
Revolut described the affected population as a very limited number of customers and said those customers had been notified. TrustStrike Labs reports that exposed material included identity documents, verification selfies, contact details and transaction histories, although the Revolut statement quoted by AML Intelligence did not independently enumerate those fields. The cited reporting did not publish the government agency, an exact customer count, when the fraudulent requests were sent or when the data was released.
Attribution posture: Revolut has not publicly named the requester, explained control of the government-domain account or attributed the incident to a threat group. It is also unresolved whether the external account was compromised, maliciously operated or abused through another mechanism. No public evidence in the cited sources establishes a breach of Revolut’s production systems, and the limited company statement does not yet support conclusions about regulatory materiality or customer harm.
Why this matters now
The incident demonstrates that valid email-domain signals are not sufficient proof that a data request is legitimate. A compromised or abused external government account can pass ordinary authentication checks and arrive with the urgency and authority expected by compliance, legal or customer-support teams. The attacker’s target becomes the approval process and its human trust assumptions rather than the financial institution’s production infrastructure.
Financial services, identity-verification providers, telecommunications companies, cloud platforms and other organisations routinely disclose sensitive records under lawful authority. Those workflows often sit between legal, privacy, compliance, fraud and operations teams, creating gaps in technical ownership and logging. When released data combines identity documents, verification images and transaction history, the downstream risks include convincing impersonation, targeted cryptocurrency fraud, account recovery abuse and pressure against the affected individuals.
The decision for security leaders
Assign a single accountable owner across legal, privacy and security for authenticating external authority requests. The control must verify both the requesting organisation and the individual request through a channel not supplied in the incoming message. Domain reputation, valid email authentication, official branding and urgency should be treated as supporting context, not independent authorisation to release data.
Set field-level disclosure rules before requests arrive. Case systems should record the legal basis, verified contact, approvers, exact data fields, transfer mechanism and retention decision. Requests for identity documents, verification images, transaction history or cryptocurrency activity should trigger elevated review because the combined dataset creates greater downstream identity and fraud risk than any individual field.
Evidence of closure
- The incident case records verified request origin, approvers, data fields and transfer path.
- An independent contact directory supports out-of-band verification for sensitive requestors.
- Recent high-sensitivity disclosures have documented review outcomes.
- Legal and privacy owners approve the notification and customer-protection position.
The Security.io assessment
The event changes the threat model for trusted correspondence. Traditional phishing controls focus on malicious links, attachments or spoofed domains; this incident instead involved a request delivered through an apparently legitimate government domain and exploited the authority attached to that channel. Organisations should test whether their disclosure workflow can withstand a valid-looking message from an externally compromised or abused identity.
Public facts remain limited. Revolut confirms an unauthorised disclosure and customer notification, but the exact population, agency, chronology and field list are incomplete. Leadership should avoid treating secondary detail as final scope while still acting on the control failure. Closure requires a reconstructed request trail, verified containment of the disclosure channel, an approved notification position and evidence that equivalent recent requests were reviewed.
Questions for the morning meeting
- Which team owns authentication and approval of government, legal and law-enforcement data requests?
- Do sensitive disclosures require independent verification using a pre-established contact outside the incoming message?
- Can the organisation reconstruct every data field, approver and transfer associated with a fraudulent request?