On 12 September 2026 Revolut confirmed that customer data had been disclosed to an unauthorised third party following what it described as a sophisticated external impersonation scam. The request arrived by email from an address on the genuine domain of a government agency. It passed every authentication check, because there was nothing to fail — the domain really did belong to the institution it claimed. Inside Revolut, the message was handled as what it appeared to be: a binding legal request for customer information.
Revolut states that its systems, databases, accounts and customer funds were not compromised. That is almost certainly accurate, and it is the point. Nothing technical was broken. What failed was a process — the sequence of steps a person follows when a request for data arrives from someone who looks entitled to ask.
Reporting puts the number of contacted customers at roughly 680. The categories disclosed are considerably worse than the count suggests: full names, dates of birth, occupations, postal and email addresses, phone numbers, passport and driving licence copies, KYC verification selfies, account statements, IBANs, withdrawal records and full transaction histories, including cryptocurrency activity. Revolut says it blocked the sending address, notified the relevant government agency, law enforcement and regulators, and self-reported to the UK Information Commissioner's Office, which opened a formal investigation on 14 September.
Since 13 September, a party holding the data has been publishing customer dossiers on Telegram and threatening daily releases until a payment is made.
Authentication answers the wrong question
SPF, DKIM and DMARC establish that a message was sent by a server the domain owner authorised, and that the visible sender matches. They are useful controls and every organisation should have them configured correctly. They answer where a message came from.
Getting them right remains worth doing, and it is quickly checked. ClickScan, our scanning service, reads a domain's public DNS and reports whether SPF ends in a hard fail (-all) or a soft one (~all) that receivers widely ignore, whether you are under the ten-lookup limit that silently invalidates the record as departments add tools, whether DKIM signing covers every service that sends as you, and whether DMARC is enforcing rather than parked at p=none. It needs no proof of ownership, because every record it reads is public, so it takes about a minute — run it against your own domain.
What none of the three answers is the only question that mattered here: am I permitted to send this, to this requester, through this channel?
That question is not technical and cannot be delegated to a mail gateway. It is answered by a person following a procedure, or not following one. Which is why the same organisation can have excellent authentication records, a mature security programme and a large budget, and still hand over passport scans because an email looked official and sounded urgent.
There is a precedent inside the same company. In September 2022, an attacker combined a highly targeted social-engineering campaign with a phished employee credential and reached data on 50,150 customers, of whom 20,687 were in the EEA and 379 in Lithuania, according to the notification that prompted the Lithuanian State Data Protection Inspectorate to investigate. Different mechanics, same weakness, four years apart.
The procedure, in full
The procedure below is written to be adopted as it stands, or adapted to your own approval thresholds. The control that would have stopped the 2026 incident is a behaviour, and a behaviour can be specified, trained and measured.
- Never respond on the channel the request arrived on. Treat the contact details in the message — the reply address, the phone number in the signature, the link to a portal — as content supplied by the requester, not as identification. Confirmation happens on a channel you choose.
- Use a published, independent contact route. The institution's official switchboard number from its own website, an address from a register you maintain, an established liaison contact. Not the number in the email.
- Require a request reference number and verify it exists on the independent channel. A legitimate authority issuing a binding request can identify that request; a good-faith requester will not be offended by being asked.
- Confirm before anything leaves, not after. The verification step happens while the data is still inside your organisation. A callback made after the files were sent is an incident note, not a control.
- Add a second approver above a threshold. Define it by volume and by sensitivity — identity documents, KYC media, full transaction history and anything about more than a handful of customers should require two people, one of whom did not receive the original request.
- Give staff an explicit, written right to delay. Urgency is the requester's instrument, not the authority's. An employee who slows down a request that turns out to be genuine must face no consequence. If that guarantee does not exist in writing, the procedure will not survive contact with a caller who sounds senior and impatient.
- Log every request, its verification and its outcome. This is what you show a supervisor later, and what lets you spot the second attempt.
The same pattern, in any organisation
Any organisation with a process for sending data to a requester who appears legitimate is exposed to this.
HR receives a payroll data request that appears to come from a tax authority. Accounting receives a supplier bank-detail change on what looks like the supplier's letterhead. The service desk receives an account recovery request from someone who knows an employee's date of birth and manager's name. Legal receives a subpoena or a court order by email. In each case the deciding factor is the same: whether the person is required to confirm on a channel they chose before acting.
What click-rate simulations measure instead
A conventional phishing simulation measures whether someone clicked a link. In this scenario there is no link to click. There is a request for data and a decision to disclose. An employee with a perfect click-rate record can still email a folder of passport scans to a well-written request from a genuine-looking domain.
A simulation that measures this risk looks different. It sends a plausible data request through a channel the recipient believes is trusted, and then records what the person did:
- Did they attempt independent verification on a channel they selected, rather than replying?
- How long until the request was reported to security, measured from receipt?
- Was the second-approver rule applied where the threshold required it?
- Did anyone disclose, partially disclose, or promise to disclose?
Those are the metrics. Click rate is not among them. The two that carry a programme are the independent-verification rate and time-to-report, because they are the only ones that describe what people actually did rather than what they avoided.
This is the design we use when building data-request and vishing scenarios in our human risk management work, and the reason our phishing simulation programmes are structured as continuous measurement with role-specific scenarios rather than an annual campaign. The staff who need this scenario most — finance, HR, the service desk, legal, customer operations — are usually the ones a generic simulation serves worst. Targeted security training for those roles is the other half of it.
The obligations, and the long tail
For financial entities, a major ICT-related incident under DORA (Regulation (EU) 2022/2554) carries an initial notification within four hours of classification and no later than 24 hours from becoming aware, an intermediate report within 72 hours of the initial notification, and a final report within one month. In Romania the supervisory route runs through BNR for banks and non-bank financial institutions, and through ASF for insurers, pension funds and capital market entities. In parallel, GDPR Article 33 sets 72 hours for notifying the supervisory authority, and Article 34 requires communication to affected individuals where the risk to them is high. Mapping which report goes where, before an incident, is part of audit, risk and compliance preparation rather than something to work out at 3am.
Then there is the part that does not close when the incident does. Identity documents and verification selfies cannot be reissued the way a password can. They become raw material for the next fraud: vishing with accurate personal details, fraudulent account recovery, SIM swap, synthetic identity. For customers whose cryptocurrency holdings are now documented alongside their home address, the risk is not only financial.
That is the argument for spending on the disclosure decision rather than another filtering layer. The message that caused this passed every technical check that existed, and would pass them again tomorrow.
This article is general information and does not constitute legal or regulatory advice. For how DORA, GDPR or NIS 2 apply to your organisation, consult the applicable legal framework and your legal adviser.
Note on sourcing: Revolut's confirmation, the categories of data and the ICO investigation are drawn from the company's statements and mainstream reporting. The figure of approximately 680 affected customers originates with the Financial Times and has not been confirmed by Revolut. The extortion demand and the volume of published data come from secondary reporting of a Telegram channel and have not been independently verified by us.
Sources: TechCrunch — Revolut confirms customer data breach through fake government requests; The Register — Revolut falls for fake government requests; Help Net Security — What we know about the Revolut data breach so far; RTÉ — Revolut customer data breach after fake Govt requests; SecurityWeek — Over 50,000 Revolut Customers Affected by Data Breach (2022); Regulation (EU) 2022/2554 (DORA), Article 19; GDPR Articles 33 and 34.