A genuine government domain was enough to obtain passports and ten years of Bitcoin history
On 11 September 2026, Revolut customers received a message titled « Urgent security update about your Revolut account ». In it, the bank explained that it had handed over their identity documents, their verification selfie and their entire transaction history to an address operating inside the domain of a government agency. I received that notification, took it for phishing, and deleted it.

The reflex was right, applied to the wrong message. An email from a bank, sent on a Friday, talking about urgency and security, announcing that identity documents had circulated: every signal of a phishing campaign following a leak. I learned the next day that the message was genuine, because Mark Karpelès published long extracts from it on 12 September at 07:06 UTC, and the trade press obtained confirmation shortly afterwards.
The fake government request has been documented since 2021. Revolut answered one in September 2026.
What the customer notice says, and what the statement chose to describe
The notice lists four families of data. Civil identity, with name, date of birth and occupation. Contact details, with postal address, email address and phone number. KYC verification documents, meaning the copy of the passport or driving licence and the selfie taken when the account was opened. Financial details, finally, with the IBAN, the opening date, wallet references, withdrawals and the complete transaction history, including Bitcoin activity.
Revolut points out that no biometric facial telemetry was involved. The photograph of the face, however, went out. The distinction means something to a lawyer looking at how a biometric template is classified under Article 9 of the GDPR. It means nothing at all to someone who wants to open an account in another person's name.
The company spokesperson describes a sophisticated external impersonation scam, says a limited number of customers are affected, that the address was blocked as soon as it was detected, and that the agency, law enforcement, data protection authorities and financial regulators have been alerted. He adds that Revolut's systems and customer funds are unaffected. Those last two statements are accurate. They describe the perimeter the attacker chose not to touch, while the one he was aiming at left as an attachment.
ZachXBT, who made the case public on his Telegram channel, believes the operation targeted high-net-worth profiles. Revolut has not confirmed that point, which remains an analyst's reading rather than an established fact. The exact number is not published, the agency is not named on grounds of an ongoing investigation, and no dedicated announcement appears on Revolut's press page as of 13 September.
A mailbox inside the domain: SPF, DKIM and DMARC have nothing to answer for
The three protocols everyone has deployed over the past decade each answer one precise question. SPF checks that the sending server is authorised to send mail for that domain. DKIM checks, through a cryptographic signature, that the content of the message was not altered in transit. DMARC ties the two together and tells the receiving server what to do when the checks fail. None of the three claims to establish that the human being behind the mailbox is entitled to ask for anything.
According to the notice, the mailbox used by the attacker operated inside the real domain infrastructure of the agency, which made the signature genuine in the strict sense. Revolut eventually contacted the agency to verify the request, and it was that call which revealed the existence of an unauthorised account created in its environment. The call came after the documents had been sent.
The check the industry has industrialised therefore answers the question « does this domain authorise this server ». Nobody has built the check that answers the question « does this agency authorise this request ». The second question was the only one that mattered here, and it is not settled in the header of a message.
The method is four years old, Bloomberg published it and the FBI repeated it in 2024
On 30 March 2022, Bloomberg revealed that Apple and Meta had handed subscriber data to attackers who had sent fake emergency data requests, the mechanism that lets US law enforcement obtain information without going through a judge when a life is at risk. Discord confirmed it had processed a request of the same kind. Snap received one. Some cases went back to early 2021. Two days earlier, Brian Krebs had described the market that had formed around the method, with access to police mailboxes sold on forums by members of the Recursion Team, and later Lapsus$.
Apple at the time pointed journalists to its own law enforcement guidelines, which already included the option of contacting the supervisor of the requesting officer to confirm that an emergency request was genuine. The countermeasure was written down, published, and known across the industry in 2022.
In November 2024 the FBI issued a private industry notification about these same fake requests sent from compromised government mailboxes.
Twenty-two months passed between that alert and the notice of 11 September 2026. Four and a half years passed between the Bloomberg story and that same notice.
Nor is Revolut a company discovering social engineering for the first time. In September 2022 it declared to the Lithuanian data protection inspectorate an unauthorised access to one of its databases, obtained by manipulating an employee, affecting 50,150 customers, or 0.16 % of its base at the time. Four years later the target has moved up a floor: the manipulation no longer aims at a support agent, it aims at the process that answers the authorities.
What banks demand of their suppliers and do not apply to themselves
For two years now, my clients have all been asking me the same question, and it now arrives in writing, in supplier questionnaires and contractual annexes. What is your process if a government authority asks you for our data? The requirement is always worded the same way: hand over nothing immediately, contact us before any transfer, and verify by your own means that the request is well founded.
Those clients are energy operators, public administrations, insurers and banks. Several banks are in my portfolio, and every one of them demands this arrangement of me, an independent consultant, for data infinitely less sensitive than a scanned passport and ten years of transaction history. I document it, I test it, and it is audited.
The requirement is entirely justified. What makes it interesting is that it travels down the supply chain without ever travelling back to its starting point. The same organisations that require their suppliers to make an outbound call before answering any authority have not built that call-back at home, at the counter where the most sensitive requests in their entire information system arrive. Revolut answered a request without calling the agency before sending, which is exactly the behaviour its peers would flag in a supplier during a third-party audit.
Why does a regulated bank answer the state faster than its own duty to minimise?
Because the two regulators watching it do not react on the same timescale. Delaying a genuine request shows up within days, is hard to defend, and can bring criminal exposure under anti-money-laundering obligations. Handing over too much data to a requester who turns out to be fake is discovered months later, investigated slowly, and usually ends in an administrative procedure. A compliance team arbitrating under that asymmetry rationally chooses yes.
The GDPR says the opposite of what that arbitration produces. Article 6.1.c allows processing based on a legal obligation, strictly to the extent that the obligation requires. Article 5.1.c requires that data transferred be adequate, relevant and limited to what is necessary. A fraudulent request carries no legal obligation, which leaves the transfer without any legal basis and qualifies it as a personal data breach under Article 4.12, with the notification duties of Articles 33 and 34. The metric that drives compliance teams remains response time to authorities. No dashboard measures the share of requests rejected for failed verification, because nobody asks for it in the audit committee. The process therefore does exactly what it is measured on.
How many institutions received the same request, and why can nobody check?
Karpelès asked the only operational question that matters, and it remains unanswered. As long as the agency and the address are not identified, no other bank, no exchange, no insurer can search for that address in its own log of legal requests. Revolut blocked the mailbox in its systems. That block protects Revolut.
An unauthorised mailbox existed inside a government agency's infrastructure long enough to prepare a credible request, send it, receive passports and transaction histories, and probably start again elsewhere. How long that account lived is the single most useful piece of information in the whole file. It has not been published. Investigative secrecy protects the investigator, and it also covers the method while other institutions carry on processing requests sent from the same domain.
There is a precedent in method. After the 2022 revelations, several US platforms set up directories of contacts and shared confirmation procedures. The difference is that the technology sector was able to organise without waiting for states, whereas the banking sector depends on judicial cooperation channels it does not control.
The request counter, the blind spot of certification
As an ISO 27001 lead auditor, I have never seen a process for answering requests from authorities presented as a tested control, with evidence that the outbound call-back was performed and an audit sample. Annex A control 5.31 requires identifying and documenting applicable legal, regulatory and contractual requirements. Control 5.34 deals with the protection of personal data. Neither one prescribes verifying, through an independent channel, the identity of the authority demanding an identity document. The subject therefore appears in audit as a list of obligations kept up to date, not as a control with a failure rate and an audit trail.
DORA covers third-party ICT risk, incident management and resilience testing. The counter that answers requests falls into none of those categories, because it is not a technical asset but a legal procedure. SOC 2 handles it at best under the confidentiality criterion, with no call-back requirement. The request from an authority thus crosses every framework without ever being tested by anyone.
The comparison that makes this hard to defend sits inside the bank itself. A change of IBAN on a supplier account has for ten years triggered an outbound call to a known number, four-eyes validation and an auditable record, because invoice fraud cost enough for the control to become mandatory. The same institution applies that arrangement to a fifty-thousand-euro transfer and does not apply it to the release of a passport, a verification selfie and ten years of named financial activity. The transfer gets a call-back. The identity document leaves without being reversible.
What would actually protect a request from an authority
A mandatory outbound call before any identity document is handed over, to a pre-registered contact, on a channel chosen by the recipient and independent of the message received. The principle is the one used to validate changes of bank details, it is well known, it is tooled, and it requires no new technology.
An enforceable directory of requesting authorities, published and maintained by each state, with verifiable service identities and a call-back channel that institutions are obliged to use. As long as a message that passes DMARC is enough to obtain a passport, government email remains the most profitable tool on the personal data market.
A reply scope bounded to what the request names explicitly, so that a selfie and a complete Bitcoin history do not go out because an email asked for the whole file. Two-person human validation, with one of the two validators outside the line that handles the request. An auditable, timestamped log, usable in audit and disclosable to the regulator.
On Revolut's side, three figures are missing and could be published without harming the investigation: the number of people affected, the date of transfer, and the number of requests processed from that mailbox. On the side of banking regulators and data protection authorities, one question would change the state of the industry within a quarter: ask every supervised institution to produce evidence of an outbound call-back on the last three requests it processed, with the date and the contact.
The only notification Revolut sent looked enough like a scam for me to delete it, and nothing was published on its site. The customers affected who had the same reflex as me still do not know that their passport is gone.
Further reading
- 153 million identity documents for sale, and not one stolen from a careless user
- France's tax authority knew in late June. You found out on 13 August
- On 1 January 2027, France will verify the identity of all its adults
- Cybersecurity must not become an election issue
- Concrete steps, by user profile, are gathered on etrecyber.fr.
Sources
- Revolut, notice sent to affected customers, issued 11 September 2026, long extracts of which were published by Mark Karpelès (@MagicalTux) on 12 September 2026 at 07:06 UTC and by investigator ZachXBT on his Telegram channel.
- Revolut, statements given to TechCrunch, CoinDesk and BeInCrypto, 12 September 2026.
- TechCrunch, Revolut confirms customer data breach through fake government requests, 12 September 2026, and CoinDesk, 12 September 2026.
- The Crypto Times, Decrypt and CryptoSlate, 12 September 2026, for the detail of the SPF, DKIM and DMARC checks as described in the notice.
- Bloomberg, investigation into fake emergency data requests sent to Apple, Meta, Discord and Snap, 30 March 2022, and Krebs on Security, 29 and 31 March 2022.
- FBI, private industry notification on fake emergency data requests sent from compromised government mailboxes, November 2024.
- Lithuanian State Data Protection Inspectorate, declaration concerning the Revolut incident of September 2022, 50,150 customers affected.
- Office of the Comptroller of the Currency, Corporate Decision #1390, preliminary conditional approval of Revolut Bank US, 3 September 2026.
- Cybernews and heise online, sale listing of 75 million records attributed to Revolut, 25 to 30 July 2026, and Revolut's denial that the identifiers matched.
- ISO/IEC 27001:2022, Annex A, controls 5.31 and 5.34.
- Regulation (EU) 2016/679, Articles 4.12, 5.1.c, 6.1.c, 9, 33 and 34.
Frequently asked questions
How do I know if I am affected?
Revolut says it contacted directly the people whose data was handed over. The notification arrived by message on 11 September 2026 and the company published nothing on its press page. A customer who deleted that message, taking it for a phishing attempt, can request written confirmation from Revolut's data protection officer, who must answer under Article 15 of the GDPR.
Was Revolut hacked?
No intrusion into the systems has been reported. The data was handed over voluntarily by the company, in response to a request it judged to be genuine. That characterisation does not rule out a personal data breach under the GDPR, since Article 4.12 covers unauthorised disclosure, whatever the means that made it possible.
Is the problem KYC itself?
The obligation to collect and retain identity documents is imposed by anti-money-laundering rules, and it deserves a debate about how long that stock is kept and how centralised it is. That debate is about the loot. What was exploited here is the process that decides to hand the stock over, and it would have produced the same result with a file half the size.
What can someone holding this data do with it?
The combination of an identity document, a selfie, a postal address and a named transaction history allows accounts to be opened in the person's name, phone numbers to be hijacked, accounts to be taken over through recovery procedures, and a civil identity to be correlated with public Bitcoin addresses. That last operation also exposes known holders of digital assets to physical risk.
Is a company allowed to refuse a request it cannot verify?
Pausing a transfer long enough to confirm the origin of a request through an independent channel is not a refusal to cooperate. Guidelines published by several large platforms have explicitly provided for that confirmation since 2022. The legal risk sits in handing data to an unverified requester, which remains without any legal basis.
What should a notified customer do today?
Treat as suspect any message or call claiming to come from Revolut, a tax authority or a police service, and confirm nothing outside the app. Turn on strong authentication for the mailbox used to reset other accounts, and ask the mobile operator to lock number porting. A written request to the data protection officer will produce the exact list of data handed over.

Être en cybersécurité
A cyber roadmap in plain language, for everyone, not just the experts.
