Revolut gave away its customers’ passports. Five days later, what do we actually know?
Inhaltsübersicht
Between 11 and 12 September 2026, Revolut told first its customers and then the public that it had handed sensitive personal data to someone impersonating a government agency, after an unauthorised third party sent fraudulent requests for information from an email address sitting on a legitimate government agency domain, and those requests cleared the bank’s checks.
What went out, according to the notification Revolut emailed to the people affected, was close to everything a bank holds about a customer: names, dates of birth and occupations, postal addresses, email addresses and phone numbers, copies of passports and driving licences, the onboarding verification selfie taken to prove those documents belonged to the person presenting them, and then the financial half, meaning account statements, IBANs, account-opening dates, withdrawal records and complete transaction histories, including Bitcoin activity. Revolut says it blocked the sending address once it detected the fraud, alerted the impersonated agency along with enforcement bodies, data protection authorities and financial regulators, and that its own systems and its customers’ funds were never touched, which is true and is also the narrowest possible reading of what happened. The company initially described the impact only as limited; by 15 September the Financial Times had put a number on it, around 680 customers, with 12 of them in Ireland, while the Information Commissioner’s Office confirmed it had received a report and was assessing it and the Financial Conduct Authority said it was engaging with the firm to understand the impact. Somewhere in the middle of those statements, on 13 September, whoever holds the data stopped waiting and began publishing it, one customer dossier at a time, alongside a promise to keep going daily until the bank pays.
That is an unusual amount of established fact for five days into an incident, and it is surrounded by a much larger volume of material that is not established at all, a ransom figure no one at Revolut has acknowledged, a list of high-profile victims sourced entirely to the people running the extortion, a suspended Telegram channel, and a steady upgrade across the coverage from “the regulator has received a report” to “the regulator has opened a probe”. Sorting one from the other is the first reason this piece exists.
The second is that the mechanism should worry anyone holding customer data, because nothing here required a vulnerability, a credential, a piece of malware or a single line of code. It required an email from the right domain, sent to an organisation whose process for answering official requests assumed that a trustworthy sender implies a trustworthy request. Revolut is a competent, heavily regulated bank with a mature security function, and that assumption is sitting inside almost every company that has ever answered a subpoena. The market for making exactly this happen is mature, priced and openly advertised. The control that stops it is unglamorous, procedural and slow, which is precisely why so few organisations have implemented it.
Inbound request, from a mailbox on a legitimate government agency domain
| Answers | Did this message really come from that domain? |
| Answers | Was it altered in transit? |
| Answers | Does it satisfy the domain owner’s own sending policy? |
| Cannot answer | Is the person at the keyboard entitled to demand this data? |
Domain authentication confirms provenance rather than authority, so when the domain is genuine every anti-spoofing control in the stack returns a clean result while telling you nothing whatsoever about whether the request is lawful. Revolut’s process treated a trustworthy sender as evidence of a trustworthy request, and the files went out.
Answering the most important questions
Was this a hack, or wasn’t it?
● Confirmed: Revolut statement
It was not, and Revolut is entirely right to say so, because its systems were not intruded upon, no malware was deployed, no credential was stolen and no customer funds were touched at any point. The problem is that the distinction is being asked to carry far more public-relations weight than it can bear, since under both UK and EU data protection law a personal data breach explicitly includes unauthorised disclosure and requires nobody to break into anything at all. Revolut evidently understands this perfectly well, because it reported itself to the regulator rather than treating the incident as a customer-service matter, which means the two statements “we were not hacked” and “we suffered a reportable personal data breach” are both true at the same time and neither cancels the other out.
680 people out of more than 80 million. Why is this a story?
● Reported by the FT, confirmed to City AM
Because the smallness is the alarming part rather than the reassuring one, and a figure representing roughly 0.00085% of the customer base tells you immediately that this was not a database being hoovered up wholesale by someone taking whatever they could reach. Somebody specified who they wanted, by name, in advance. The crypto investigator ZachXBT, who first surfaced the customer notification publicly, assessed that the incident appeared to have been aimed at high-net-worth users, which is consistent with both the tiny victim count and the inclusion of complete Bitcoin transaction histories in what was handed over. A bulk breach is fundamentally a volume problem that you solve with notification letters and credit monitoring; this was a selection problem, and selection implies that the attacker already knew which customers were worth the risk of asking for.
So where did the target list come from?
○ Unaddressed, by Revolut or anyone else
This is the question that nobody in the coverage is asking, and it may well be the most consequential one in the entire incident, because in order to submit a request naming specific individuals the attacker needed those names in advance, needed to know that those particular people banked with Revolut, and needed some basis for believing they were worth the operational risk. That intelligence came from somewhere, and the plausible candidates (previously leaked data, on-chain analysis identifying high-balance individuals, an insider with access to customer segmentation, or simply publicly visible wealth) have very different implications for how worried everyone else should be. Revolut has not addressed the question and no reporting has established an answer, which means there is currently no way to determine whether this was a single well-executed email or the visible endpoint of a much longer reconnaissance operation, and the 680 should therefore be treated as a floor on what the attacker knew rather than a ceiling.
Why didn’t the email get flagged?
● Reported: mechanism consistent with the known technique
Because there was nothing to flag: the mailbox sat on a genuine government domain rather than a lookalike, and reporting indicates the message carried valid domain-authentication credentials, which is precisely what you would expect when the sending domain is real rather than spoofed. Email authentication exists to answer the question “did this message actually originate from the domain it claims?” and it answers that question well, but it has never been designed to answer the entirely separate question of whether the human being operating that mailbox holds any legal authority to demand the data they are asking for. Every anti-spoofing control in the chain was functioning exactly as specified and every one of them was completely irrelevant to the attack that was underway.
Revolut has not published the specific header results, so this particular technical detail rests on secondary reporting rather than on anything the company itself has confirmed.
When did Revolut actually verify the request?
● Reported: from the customer notification
Afterwards, which is the entire incident compressed into a single fact. According to the notification sent to affected customers, Revolut independently contacted the government agency to validate the request only once it had become aware that something was wrong, and in the course of doing so it was Revolut that alerted the agency to the fact that its identity was being abused. The verification step capable of stopping this attack therefore existed within the organisation, was understood by the people who performed it, and worked exactly as intended when it was finally carried out. It was simply executed in the wrong order, after the data had already left, at which point its only remaining function was forensic.
What, specifically, went out of the door?
● Confirmed: Revolut customer notification
Four categories, which together amount to a near-complete customer file: identity details including full name, date of birth and occupation; contact details including postal address, email address and telephone number; know-your-customer documentation including passport or driving licence copies together with the onboarding verification selfie; and financial records including account statements, IBANs, account-opening dates, withdrawal records and complete transaction histories, with Bitcoin activity explicitly included.
Revolut has been careful to state that passwords and passcodes were not involved and that the biometric facial-recognition telemetry used to match verification selfies against identity documents was not shared, and both of those distinctions are real and worth acknowledging, but both are also considerably thinner than they first appear, because the selfie image itself went out of the door and only the mathematical template derived from it stayed behind.
Which government agency was impersonated?
○ Not disclosed. Revolut declines to say
Revolut has not named the agency, has not said which market or markets the requests targeted, and has not indicated whether the mailbox in question was compromised through credential theft or whether the domain was abused by some other route, all of which are material questions for anyone trying to assess whether the same mailbox might be used against them next. Recorded Future News reported that extortion images circulated on Telegram by an account claiming responsibility for the attack suggested the email had originated from an Italian domain, and that a range of Italian authorities it approached did not respond to requests for comment; that Telegram account has since been suspended. It is a lead worth following rather than a confirmation worth repeating as fact.
Is the 10,000 bitcoin ransom demand real?
◆ Unverified: threat-actor claim
Unconfirmed, and the provenance of the figure matters a great deal here, because it originates in threat-actor posts and social-media amplification before being repeated across several crypto outlets that attribute it to a group calling itself Revolut Smilik, which is a chain of custody running entirely through the people committing the extortion. Revolut has confirmed no ransom figure whatsoever, City AM reported that the two sides had not been in direct contact at all, and other coverage explicitly notes that no independently corroborated amount exists, which means anyone printing that number as established fact is in practice republishing an extortionist’s press release under their own masthead. What is considerably better established is the behaviour itself: since 13 September, material has been appearing publicly on a recurring basis alongside a stated threat to continue daily until payment is made.
Is the leaked material genuine?
● Partially corroborated, not verified by Revolut
Partially, and the corroboration that does exist is narrow enough to be worth stating precisely. Recorded Future News reported that a Revolut customer whose supposedly stolen data had been posted publicly as proof of the breach did not dispute its authenticity in a subsequent social media post, which is meaningful but amounts to a single sample. Former Mt. Gox chief executive Mark Karpelès separately confirmed that he had received a notification from Revolut and published excerpts from it, which is self-disclosure by a recipient rather than verification of anything the attacker has released. Neither Revolut nor any law enforcement body has authenticated the published material, not all of the details contained in the actor’s posts could be confirmed by the journalists examining them, and the high-profile names circulating in those posts remain purely actor-attributed, which is why this piece does not repeat them.
Why extort the bank rather than the 680 customers?
● Observable, from actor behaviour
Because the bank has vastly more to lose and a very much larger cheque book, and because the economics of this particular attack invert the usual ransomware logic in a way that works entirely in the attacker’s favour. There is no encrypted server to unlock and therefore no technical hostage, so the hostage becomes reputation and the pressure mechanism becomes a publication schedule, with every day of institutional silence costing the bank another customer dossier in public. The actor has additionally framed the campaign around an accusation that Revolut allowed customer data to leave its own jurisdiction, positioning the extortion as a form of accountability journalism rather than a crime, which is a well-worn pressure technique rather than a position anyone should take at face value.
Would paying make it stop?
● Structural, not speculative
No, and this is a structural conclusion rather than a speculative one, because the data was copied rather than encrypted and payment therefore purchases nothing more than a promise from someone whose entire business model consists of breaking promises, while doing precisely nothing about whatever copies have already been distributed elsewhere. For a firm holding fresh conditional approval from the US Office of the Comptroller of the Currency and openly weighing a public listing, a ransom payment would also constitute a significant regulatory event in its own right, with its own disclosure consequences. The genuinely interesting question is therefore not whether Revolut should pay, which it should not, but whether it can outlast the publication schedule without doing so.
Why does the Bitcoin history matter more than the passport?
● Analytic, based on confirmed data categories
Because a passport can eventually be reissued whereas an identity-to-address mapping can never be unpublished, and that asymmetry is the most durable damage in the entire incident. Once a named individual has been reliably tied to on-chain activity, standard clustering and change-address heuristics allow anyone holding that map to extend it forward indefinitely, across transactions that have not yet happened and wallets not yet created, which makes the passport a one-time fraud asset and the chain mapping a permanent surveillance asset. It also arrives pre-verified by a regulated bank that performed full know-your-customer checks on the person in question, which makes it far more valuable and far more actionable than the identical claim appearing in a forum post of uncertain provenance.
Combine the categories and the real problem comes into focus: an identity document scan, plus the verification selfie taken specifically to prove that document belonged to that face, plus a detailed financial history. That is not three separate data points that happen to have leaked together; it is a functioning kit for passing an identity verification check somewhere else, as that person.
Is the ICO “investigating”?
● Precision matters here
Carefully, and the precise wording is worth preserving, because what the Information Commissioner’s Office has actually said is that it received a report and is assessing the information provided, which several outlets have since upgraded to “investigation” or “probe” in headlines that are doing real work in shaping public perception. An assessment is not a finding, and neither an assessment nor an investigation establishes that Revolut broke any law. The Financial Conduct Authority has separately confirmed that it is aware of the reported incident and is engaging with the firm to understand the impact and the steps being taken to address potential harm. Under UK GDPR, organisations generally notify the regulator within seventy-two hours of becoming aware of a reportable breach and must inform affected individuals without undue delay where the risk to them is high, both of which Revolut appears to have done. The genuinely interesting question is what ends up being examined, because the object of regulatory attention here is not the email filter but the legal-request pipeline sitting behind it.
Hasn’t this happened to Revolut before?
● Confirmed: 2022 precedent
Not this specific attack, but something close enough in character to be uncomfortable, because in September 2022 Revolut disclosed a breach in which a threat actor used social engineering to reach customer data, prompting scrutiny from Lithuania’s data protection regulator, which supervises the company’s EU banking entity. The mechanism was different and the technique has evolved considerably in the intervening four years, but the root cause is recognisably the same: a human process was talked into granting access that no software flaw would ever have surrendered. Four years, several banking licences and a great deal of growth later, the attack surface that failed is still people conscientiously following a procedure.
Could my organisation answer a fake request tomorrow?
● Yes, and the market is priced
If your organisation holds customer data and maintains any process at all for responding to law enforcement or regulatory requests, then yes, and the reason to be confident about that answer is that the supply side of this attack has been commercially mature for years. The FBI warned in November 2024 of a marked surge in compromised government and police email accounts being sold on criminal forums alongside forged legal documents, specifically in order to enable fraudulent emergency data requests against US companies. Researchers have since documented an open market with genuine product segmentation, in which the price of an account varies according to how quickly the platforms you intend to defraud are likely to respond to it.
| What is being sold | Advertised price | Marketed purpose |
|---|---|---|
| Active .gov or .police mailbox | from $40 | Impersonating an official; sending requests that clear authentication |
| Fake emergency data request, as a service | from ~$100 | Submission handled for you; turnaround claimed as low as 30 minutes |
| Verified US police department account | $1,000 | Emergency data requests to major platforms |
| EU police account, higher-tier jurisdictions | $1,000 | Priced for faster platform response than cheaper alternatives |
| Kodex Global portal access | $2,000 | Submitting through the vetting platform built to screen these out |
Pricing observed by Abnormal, Help Net Security und Dataminr.
Accounts from the United States, United Kingdom, Germany, India and Brazil have all been observed in circulation, and sellers have shifted from quietly reselling access to actively marketing the use case, which is the clearest possible signal of a maturing market. Tiered pricing by jurisdiction, with a premium charged for the credentials that major platforms respond to fastest, is not the signature of an emerging threat; it is the signature of a functioning industry that has already worked out what its customers want.
Then what actually fixes it?
● One control, and it is unpopular
Out-of-band verification, which means calling the agency back on a publicly listed telephone number and confirming the request before releasing anything at all, and that really is the whole of it. The control is resisted almost everywhere precisely because it is slow, and slowness is exactly what an emergency data request is engineered to make you feel bad about. Digital signatures have been proposed as a technical alternative, but they do nothing whatsoever when the sending account is entirely legitimate and merely compromised, and there exists no validated master list of authorised law enforcement personnel against which any service provider could check the identity of a requester even if it wanted to, a gap identified as far back as 2022 and still open. No technical fix is on its way. There is only a procedural one, and it costs time.
- Mandatory callback on a published number for every urgent or emergency request, with no exception granted on the grounds of urgency, because urgency is the attack.
- A named and deliberately small group of people authorised to release a complete know-your-customer file, with a second pair of eyes required before anything leaves.
- Logging and rate-limiting of legal-request fulfilment, because a cluster of requests concentrated on high-value customers is the detectable signal here and it only becomes visible if somebody is counting.
- An inventory of every third party currently holding duplicates of your customers’ identity documents, since your exposure is not limited to the copies you hold yourself.
- External monitoring for your own brand appearing in identity-document listings and leak channels, because in this incident, as in most of them, the outside world knew before the organisation did.
What we still don’t know
Five days in, the list of unanswered questions remains considerably longer than the list of answered ones, and it includes almost everything that would allow another organisation to assess its own exposure. We do not know which agency was impersonated, whether its mailbox was compromised or its domain abused by some other route, how many fraudulent requests were submitted in total or across what period, or how long the gap was between the data leaving Revolut and Revolut noticing that it had. We do not know how the 680 customers were selected, whether 680 will remain the final figure once regulators press for specifics, or whether any of the published material beyond that single undisputed sample is authentic. And we do not know whether the same technique, using the same mailbox, has already succeeded against other institutions that have not yet noticed.
The bank verified the request with the agency only after it already knew something was wrong. That sequence, disclose and then check, is the whole incident, and the gap between the two is the number nobody has published.
Timeline
| 11 Sept | Notification emails begin reaching affected customers. |
| 12 Sept | ZachXBT posts the notification publicly. Revolut confirms to TechCrunch and Reuters, describing an external impersonation scam affecting a limited number of customers. |
| 13 Sept | Customer dossiers begin appearing on a public Telegram channel alongside a threat to publish daily until payment. |
| 14 Sept | Reporting tracks the shift from disclosure to active extortion. The Telegram account is subsequently suspended. |
| 15 Sept | FT reports around 680 affected; RTÉ reports 12 in Ireland. ICO confirms it has received a report and is assessing. FCA says it is engaging with the firm. |
| 16 Sept | No agency named. No ransom figure confirmed. Investigation ongoing. |
Einpacken
The uncomfortable conclusion is not that Revolut did something unusual. It is that Revolut did something completely ordinary. A request arrived from a domain that every control in the stack confirmed was genuine, a team that was doing its job released the data that a lawful request of that kind would legitimately entitle someone to receive, and the verification call that would have stopped the whole thing was made a few hours too late. Almost every organisation that has ever answered a subpoena has the same shape of process, the same pressure to respond quickly, and the same unexamined assumption sitting underneath it.
The other uncomfortable conclusion is about timing. In this incident, as in most of them, the material surfaced publicly before anyone inside the organisation could have known where it had gone, and the evidence of exposure appeared on a Telegram channel rather than in a log. Identity documents, verification selfies, customer files and credentials tend to be visible outside the perimeter well before they are visible inside it, which is why the gap between disclosure and detection is the number that matters and the one almost nobody can produce on demand.
If you have received a request you were not entirely sure about, if you are not confident you would spot a cluster of them aimed at your most valuable customers, or if you suspect your data is already circulating somewhere you cannot see, those are questions worth answering now rather than eventually. Our team works with organisations facing exactly this, and we are happy to take a look.
Compiled 16 September 2026. This is a live incident and figures, particularly the affected-customer count, may change.
Über den Autor
