Revolut Data Breach: Fake Law-Enforcement Requests Explained

Reading time: ~6 minutes · For AML, fraud, compliance and data protection professionals Last updated: 22 September 2026

The reported Revolut data breach raises an awkward question for anyone working in compliance: could your team hand customer information to a criminal while believing it was helping an investigation?

Reuters reported on 12 September 2026 that Revolut confirmed disclosing sensitive customer information after fraudulent requests appeared to come from a genuine government agency email domain. The case puts the process for responding to official requests under scrutiny, from verifying the sender to deciding what information can be released.

I covered the case and the wider problem of fraudulent emergency data requests in a video on my YouTube channel.

The Revolut Data Breach: How a Fake Government Email Got Past Compliance

Watch: The Revolut Data Breach: How a Fake Government Email Got Past Compliance on YouTube.

The video is sponsored by Kodex, whose work on law-enforcement request management and requester verification made it a relevant partner for this subject. This blog post is not paid for by Kodex.

What has been reported about the Revolut case?

The Financial Times reported claims from the purported attackers that they had compromised an Italian government email system and posed as law enforcement over several months. Customers believed to hold substantial cryptocurrency assets were reportedly among the targets.

In separate reporting, the Financial Times said Revolut had contacted 680 people it believed were affected following an initial investigation, citing people familiar with the matter.

ANSA reported on 16 September that investigators were examining whether the prefecture’s certified email account had been compromised or cloned. The precise technical mechanism therefore remained under investigation.

The Guardian reported an alleged $3 million ransom demand. Revolut denied receiving a direct demand. The figure represents a reported demand, not a payment.

In the statement published by ANSA, Revolut said: “Revolut systems and customer funds are unaffected.”

There is still a limit to what we can conclude from public reporting. Without the underlying requests and internal review records, I would avoid guessing which employee or team made which decision, or whether every request used the same method.

How fake law-enforcement requests work

A criminal impersonates an authority and asks a business to disclose customer information. The request may include official-looking letterhead, an officer’s name, a case reference and an urgent explanation. A compromised government mailbox can make the communication harder to distinguish from a genuine request.

In its 4 November 2024 notification, the FBI described criminals using compromised US and foreign government email accounts to submit fraudulent emergency data requests to US companies. It also reported increased criminal-forum activity involving these requests and the sale of compromised credentials.

The FBI described an August 2024 advertisement offering government email access and assistance with emergency requests, including stolen subpoena documents. This gives compliance teams a concrete reason to look beyond a convincing document or email address.

The pattern behind most fraudulent emergency data requests: the chain breaks at the callback, not at the paperwork.

Was the Revolut request an emergency data request?

The public reporting reviewed for this article does not establish whether the fraudulent requests used an emergency-disclosure procedure. The Revolut case illustrates the wider problem of impersonating authorities to obtain customer information. The video above explores that wider risk, including fraudulent emergency data requests, or EDRs.

Genuine emergency requests can involve an immediate threat to life. For example, 18 U.S.C. § 2702(c)(4) permits covered service providers to disclose relevant non-content customer records to a governmental entity when they believe in good faith that an emergency involving danger of death or serious physical injury requires disclosure without delay.

That US provision applies to the providers covered by the statute. It is not a general permission for every bank to release KYC files, and it does not establish the legal basis invoked in the Revolut case. The applicable rules depend on the jurisdiction, the institution, the information and the request.

Why customer data remains valuable after a breach

A passport copy, identity-verification image or transaction record can give criminals material for further impersonation. A convincing follow-up scam might refer to a transaction the customer recognises or include personal details that make the caller sound credible.

The reported cryptocurrency angle adds another concern. Linking a wallet to an identifiable person can help a criminal decide whom to target. Depending on the information exposed, potential consequences include tailored phishing, identity misuse and extortion. These are risks to consider, rather than proof that every affected Revolut customer has experienced them.

For an affected customer, useful breach communication should explain what information was exposed and what practical steps to take. A statement about account balances alone would leave those questions unanswered.

What compliance teams should check before sharing data

I would start by walking through a request with the people who handle it, including those covering evenings and weekends. Ask them to show where they obtain trusted contact details and how they record the authority for disclosure.

There are four areas worth testing:

1. The requester. Confirm the agency and the individual’s identity through a trusted route independent of the incoming request. Calling a number printed on the same document can take you straight back to the impersonator.
2. The authority. Establish the legal basis and whether the request is valid for the institution receiving it. Identifying a genuine officer does not settle what that officer is entitled to obtain.
3. The information. Review the accounts, dates and data categories requested. A broad request for an entire customer file deserves scrutiny of its scope.
4. The decision. Record the checks, reviewer, approval and information disclosed. Emergency procedures need a defined escalation route and timely second review that can operate under genuine time pressure.

Requester-verification tools can support this work. The institution still needs to assess the particular request and its authority to disclose information.

For your next team exercise, use a fictional urgent request and ask someone to demonstrate the callback process. Follow it through to approval and disclosure. If the process depends on contact details supplied by the requester, you have a specific control to fix.

This article is for general information only and does not constitute legal advice. Public reporting on this case is still developing and some details may change. Sources: Reuters, the Financial Times, ANSA, the Guardian, the FBI Internet Crime Complaint Center, and 18 U.S.C. § 2702, as linked throughout.