Revolut and the Fake Government Request: When Compliance Becomes the Attack Vector

12 minutes ago

6 min read

No system was breached. The attacker sent an email from a genuine government domain, and received passports, verification selfies and complete crypto transaction histories.

What happened

On 12 September 2026, Revolut confirmed that it had disclosed sensitive customer data to an unauthorised third party. The request for information arrived from an account using a legitimate government agency email domain, carrying valid domain authentication credentials. In plain terms: the message passed every technical check designed to confirm that a communication genuinely originates from a public authority.

Revolut fulfilled the request. Only afterwards did it contact the agency, establish that the requests were not authentic, block the address and begin notifying affected customers.

According to the notification sent to customers, the disclosed data includes:

identity and contact details (date of birth, postal address, email, phone number)
copies of identity documents (passports, driver's licences)
verification selfies
account statements containing IBANs and wallet references
withdrawal records
full transaction history, including Bitcoin

The company states that its systems and customer funds are unaffected, that no biometric facial telemetry was involved, and that it has alerted the relevant agency, law enforcement, data protection authorities and financial regulators.

What Revolut has not said

Three things, all of them material:

How many people are affected. The official wording is "a limited number." That is not 80 million customers, as circulated on social media — but the absence of a figure is not the same as a small figure.
Which agency was impersonated. The company cites an active investigation.
Who now holds the data. This is the only question that means anything to the people affected.

On-chain investigator ZachXBT, who first circulated the customer notice, assessed that the incident appears to have targeted high-net-worth users. That is an investigator's reading rather than a company figure, but it is operationally relevant.

Anatomy of the attack: fraudulent authority requests

This pattern is not new. Since 2022, documented cases have shown attackers using compromised police and government accounts to submit fake emergency data requests to major technology platforms and obtain user records. Financial services inherited the same vulnerability, with a far more sensitive file sitting on the other side of it.

The mechanics are simple, which is precisely why they work:

Domain authentication proves where a message was sent from. It does not prove who sent it, or that they had authority to. SPF, DKIM and DMARC confirm that the email left the real agency's infrastructure. If an attacker has compromised or opened an account inside that infrastructure, every technical check returns green. The system performs exactly as designed — and that is why it fails.

Layered on top is an organisational dynamic: a request that looks like an order from the state does not receive the same scepticism as a request from a customer. Compliance teams are trained to act quickly, not to refuse an authority. This is not individual carelessness. It is a consequence of process design.

The "without undue delay" myth

A recurring argument in public commentary holds that a bank which responds late risks a penalty, while a bank which hands over too quickly risks nothing. The first half is partly true. The second is legally wrong — and that false belief is exactly what makes incidents of this type possible.

What the obligation actually says. The AML framework requires obliged entities to provide requested information to the financial intelligence unit without undue delay. The duty attaches to a request from a competent authority — not to a message that resembles one. Verification is not delay. It is the precondition for the obligation existing at all.

What a fast disclosure actually risks. Disclosing personal data without a valid legal basis is a GDPR violation, exposed to fines of up to EUR 20 million or 4% of global annual turnover, alongside a 72-hour supervisory notification duty, an obligation to inform data subjects where the risk is high, and liability for damages under Article 82. With high-risk clients — and here we are discussing people whose crypto holdings are now tied to their home address — civil exposure comfortably exceeds the regulatory fine.

Stated plainly: no EU legal regime requires an institution to execute an unverified request. What exists is an organisational culture that fears the regulator's deadline more than it fears unlawful disclosure. That asymmetry is the real vulnerability, and it is fixable.

Why this is a security incident, not just a privacy one

A KYC file is not a data set. It is an operational targeting package.

A single file links confirmed identity → proof of wealth → the size of a crypto position → home address → face. Everything an attacker needs for a physical operation, in one document, already verified by a regulated institution.

The 2026 figures show where that leads:

CertiK verified 52 physical attacks on crypto holders in the first half of 2026, up from 39 in the same period of 2025 — a 33% increase. Europe accounts for roughly 75% of cases, France alone for 33 of the 52. Home invasions rose from 1 to 20 year on year.
Chainalysis documented 46 violent incidents through late June, with more than USD 30 million in assets taken, and reports that home invasions now make up 37% of incidents, up from 26% in 2023. Attackers increasingly target family members, not only the holder.

The most important finding is causal: Chainalysis explicitly links the wave of attacks in France to data leakage — a case in which a tax authority official was charged with stealing and selling records containing the names, addresses and asset holdings of digital asset holders, alongside a separate breach at a crypto tax platform. Criminal crews now assemble "target packages" from leaked databases, exchange records and on-chain activity.

This is why data minimisation is a physical security measure, not an administrative formality. A hardware wallet protects no one who can be physically coerced into unlocking it.

Controls that stop this (institutions)

None of them are expensive. All of them are organisational.

1. Out-of-band verification — unconditional. Every authority request for customer data is confirmed by calling the agency on a publicly published number, never a contact detail taken from the message itself. No exceptions, regardless of urgency markings.

2. Dual authorisation. No individual may unilaterally approve the export of a customer file. Minimum: compliance plus legal, with the approval recorded.

3. A mandatory hold before release. A defined minimum interval between receipt and disclosure, with any exception approved solely by a senior officer against a written justification. Urgency is the single most common social engineering lever — treat it as a risk indicator, not a reason to accelerate.

4. Channel the requests. Authority requests arrive through official portals or a dedicated logged channel, not the general compliance inbox.

5. Minimise the response. Disclose precisely what was requested for the identified customer. A complete KYC package with verification selfie and full transaction history is not a default response — it is an exception requiring specific justification.

6. Pattern detection. A request targeting high-net-worth or crypto-exposed customers must automatically raise the verification threshold. Clustering of such requests is a signal in itself.

7. Register and audit. Every request, verification, approval and disclosure logged and subject to quarterly review. Without this you have neither a defence before the regulator nor the ability to establish scope after the fact.

What affected and exposed individuals should do

If you received a notification, the working assumption is that your file is in circulation and cannot be recalled.

Demand the exact scope. Under GDPR Article 15 you are entitled to know which specific data were disclosed. Submit the request in writing and diarise the deadline.
File with the supervisory authority. Independently of the institution's own notification.
Treat your address as compromised. Review physical security at the property, access control and the predictability of your daily routine. Attackers pose as delivery personnel.
Establish a household duress protocol. An agreed word, procedure and point of contact — for a partner, children and domestic staff. The data shows the family is a target.
Separate control from access. Multi-signature arrangements, withdrawal delays, geographically separated signatories. The objective is that coercion of one person is not sufficient to move funds.
Stop publicly linking identity to holdings. On-chain activity tied to a name is permanent.
Run an OSINT review of your own profile. What an attacker can assemble about you in an afternoon is something you should know before they do.

Conclusion

Revolut has stated that its systems and customer funds are secure. That is probably true — and it misses the point entirely. The attacker needed neither systems nor funds. He needed the file, and he obtained it through the normal channel, via a process that operated exactly as written.

The real question is not whether Revolut failed. It did. The question is how many institutions today run the identical process — verification after release — with no indicator that would tell them the request has already arrived.

The data you surrender by law, in order to be protected, is retained out of fear of sanction. And it was disclosed out of that same fear. Until that fear is balanced by equally serious accountability for unlawful disclosure, this will not be the last case.