What happened
In early September 2026, it emerged that the fintech Revolut had handed sensitive customer data to attackers posing as a government authority. The incident became public on September 11, 2026, after crypto investigator ZachXBT shared a notification email from Revolut. Revolut confirmed the incident shortly afterwards, describing it as a “sophisticated external impersonation scam” in which an unauthorised third party had submitted fraudulent requests for information using a legitimate government agency domain.
What makes this case notable is that Revolut was not technically hacked. There was no break-in to its systems, no exploited software vulnerability, no theft of credentials in the classic sense. Instead, the attackers abused a legitimate process, namely the channel through which authorities and law enforcement can request customer data from financial service providers.
The attack path: fraudulent government requests
According to the available reporting, the attackers compromised the email system of an Italian government body and then posed as a law enforcement agency. Over a period of several months, they submitted targeted requests for information about specific Revolut accounts. Because the messages originated from a genuine government domain and passed the technical sender checks (domain authentication such as SPF and DKIM), Revolut processed the requests in the belief that they were authentic official enquiries.
In Revolut’s own words, the request was fulfilled “under the reasonable belief that it was an authentic government agency request”, as the communication carried valid domain authentication credentials. This is precisely where the core problem lies: the technical check only confirmed that the email genuinely came from the authority’s domain. It could not confirm that a legitimate official actually stood behind the email rather than an attacker who controlled the mailbox.
What data was affected
The data sets that were handed over were extensive and highly sensitive for the customers concerned. According to Revolut and the analysis by ZachXBT, they included identity and contact details such as names, dates of birth, occupation, postal and email addresses, and phone numbers. In addition, there were copies of identity documents, specifically passports and driver’s licenses, as well as the selfies from the identity verification process (KYC verification).
The financial dimension is particularly serious: account statements including IBANs, withdrawal records, and complete transaction histories were also exposed, including Bitcoin transactions. For the individuals affected, this means not only a risk of identity theft but also the disclosure of their wealth and payment flows to criminals.
Targeted at wealthy customers
The attack was not broadly scattered but precisely aimed at valuable targets. Revolut spoke of a “limited number” of affected customers; according to ZachXBT and several reports, at least 680 accounts were affected, with a clear focus on high-net-worth users and so-called crypto whales, meaning individuals with large cryptocurrency holdings. This selectivity is consistent with the approach: someone querying individual accounts over a period of months is not looking for volume but for particularly valuable individual targets.
The extortion
The data exfiltration was followed by an extortion attempt. A group operating under the name “iamnotavillain” demanded a ransom of 6,000 Monero (XMR), worth around 2.9 million US dollars at the time, with a 24-hour deadline. To prove authenticity, the group sent the Financial Times a video containing stolen customer documents, including driver’s licenses, passports, and identity images from the KYC process.
The choice of Monero rather than Bitcoin is no coincidence, as Monero is considerably harder to trace. Revolut stated that it had received no direct contact or demand from the group and reaffirmed that its own systems and customer funds were unaffected. Whether and how the affected data would ultimately be sold or published remained open at the time of reporting.
Emergency data requests: a growing problem
The Revolut case is not an isolated incident but a prominent example of a class of attack that has increased sharply in recent years: the abuse of official requests for information, known as emergency data requests or law enforcement requests.
Platforms and financial service providers are legally obliged to hand over customer data to authorities under certain conditions. In urgent cases, for example where there is an imminent danger to life, many legal systems even permit expedited disclosure without the court order that would otherwise be required. It is precisely this exception that attackers exploit. They forge or hijack official senders and submit urgent requests that, in the name of saving time and an apparent emergency, are scrutinised less rigorously. Major technology companies have been affected by this technique in the past, which shows that it is a structural problem of the disclosure process and not the failure of a single provider.
What organisations can learn from this
The incident shows that the trustworthiness of a request cannot be established on the basis of technical characteristics such as the sender domain alone. For organisations that themselves work with sensitive customer data or process requests for information, several concrete conclusions follow.
Verification through a second channel: Official requests for information should not be judged solely on the basis of the incoming email. A confirmation through an independent, verified channel, such as an official callback contact at the requesting authority, would very likely have exposed the fraud in this case.
Putting domain authentication in context: SPF, DKIM, and DMARC confirm the origin of an email from a domain, but not the legitimacy of the sender behind it. If the mailbox itself is compromised, all technical checks pass even though the request is fraudulent. This limitation must be consciously accounted for in processes.
Data minimisation and access control: The less data that is held centrally and easily retrievable, the smaller the damage in the event of an incident. Access to particularly sensitive data sets, such as ID document copies and complete transaction histories, should be subject to strict controls and be logged.
Detecting anomalies: A single request for information may be unremarkable. A series of requests concerning conspicuously wealthy customers over several months is not. Monitoring patterns in official requests makes it possible to detect such campaigns earlier.
Preparing for the worst case: A clear process for handling and verifying official requests, combined with a rehearsed procedure for the event of a data breach, determines how quickly and in how orderly a fashion an organisation can respond.
For customers of financial service providers, the uncomfortable realisation remains that they can barely influence how their provider handles official requests. This makes measures within their own sphere of control all the more important, such as activating all available security features on their account and maintaining a healthy scepticism towards unexpected contact attempts that refer to alleged incidents..
Does your organisation process sensitive customer data or official requests for information? Contact us for a review of your processes and security measures.
Sources:
– TechCrunch: Revolut confirms customer data breach through fake government requests
– BleepingComputer: Revolut discloses data breach exposing financial info, passports
– PYMNTS: Revolut Hackers Issue $3 Million Ransom for Customer Data
– Help Net Security: What we know about the Revolut data breach so far