Revolut Customer Data Breach: More Than One Mistake

What happened

In September 2026, Revolut confirmed that it had disclosed sensitive customer information to an unauthorised third party. The disclosure happened after criminals sent fraudulent requests that appeared to come from a real government agency email domain.

This was not primarily a break-in to Revolut's banking app or customer accounts. Instead, it was an example of attackers exploiting trust in an official-looking request and the internal process used to respond to authorities.

Revolut told Reuters that the incident affected a "very limited" number of customers, who had been notified. A company spokesperson said that "Revolut systems and customer funds are unaffected." The spokesperson added: "Upon detection, we immediately blocked the address and alerted the relevant government agency as well as enforcement agencies, data protection, and financial regulators."

Source: Revolut confirms sensitive customer data breach after falling for fake government requests

Reporting indicates that the information involved may have included contact details and identity-verification or financial information, such as identity documents, verification images, statements or transaction data. The exact data and number of people affected should always be confirmed from Revolut's current customer communications.

How the attack worked

The likely attack chain was simple in principle but highly effective:

1. An attacker gained access to, or was able to send messages from, an email account using a legitimate government agency domain.
2. The attacker sent Revolut a request for customer information that looked like an official legal or law-enforcement request.
3. The request was treated as genuine because it came through a trusted-looking channel and used the authority of a government agency.
4. Customer data was disclosed to the attacker.
5. The fraud was discovered later and the account or address was blocked.

The important point is that a real-looking email address is not the same as proof that a request is genuine, authorised or proportionate.

Attack and vulnerability types

Attack or vulnerability	What it means	Why it matters here
Social engineeringHuman factor	Using trust, pressure or familiar signals to influence someone's decision	The attacker did not need to break into a customer account. They needed a person to believe that a request was real and act on it.
ImpersonationHuman factor	Pretending to be a person or organisation that people are expected to trust	The request appeared to come from a government or law-enforcement contact, making it more likely to be treated as legitimate.
Authority pressureHuman factor	Using the status of an official body to make compliance feel necessary	A request linked to a government agency can make staff feel they should respond quickly rather than question it.
Urgency pressureHuman factor	Making a request feel time-sensitive so people have less time to check it	Fraudulent official requests can rely on deadlines, confidentiality or the implied urgency of an investigation.
Trusted-channel abuse	Using a normally reliable communication channel for an unauthorised purpose	The email came from a genuine government agency domain, which created credibility even though the request was fraudulent.
Unauthorised use of a trusted email account	Someone uses an email address or account they should not be using	Reporting indicates that an unauthorised party used an address within a legitimate government domain, rather than simply using a visibly fake address.
Business email compromise (BEC)	Using a real or convincing email account to deceive an organisation	This is a useful umbrella term if the attacker accessed or misused a real government mailbox. It is not yet clear publicly exactly how that address became available to them.
Legal-process fraud	Using a false official or legal request to obtain information	The attacker imitated a process used for genuine requests from public authorities.
Process abuse	Turning a normal business or compliance process into the route for an attack	The target was not only email. It was the full process for receiving, checking and responding to requests for customer data.
Authentication overrelianceHuman factor	Treating one technical check as proof that a whole request is safe	The email reportedly passed domain-authentication checks. That showed it was sent through the real domain, not that the requester or request itself was genuine.
Insufficient independent verificationHuman factor	Acting on a request without separately confirming who made it and why	An independent call or established verification process could help distinguish a genuine authority request from one sent through a compromised or unauthorised account.
Data disclosure failure	Sensitive information is sent to someone who has no right to receive it	The direct harm came from customer data being released to an unauthorised third party.
Data minimisation failure	Sharing more personal information than is necessary for a verified purpose	Where identity documents, verification images, statements or transaction histories are involved, the impact grows with the amount of information released.
Identity-data exposure	Personal details or identity documents become available to criminals	Names, contact details, dates of birth and identity evidence can be used to make future scams more convincing or support identity fraud.
Targeted phishing risk	Using known personal details to create a much more believable scam	Someone with real information about a customer may be able to send messages or make calls that look far more convincing than a generic phishing attempt.

Why it worked

The request did not look like a scam. There were no obvious spelling mistakes, no strange link to click, and no suspicious-looking email address. It appeared professional and came from what looked like a real government domain.

That is exactly why incidents like this are so difficult to spot. We are used to being told to watch for clumsy phishing emails. But today’s attackers do not always need to look careless or unfamiliar. Sometimes they borrow the credibility of a trusted organisation and rely on us doing what we would normally do: respond, cooperate, and move quickly.

A genuine-looking sender is not proof that a request is genuine.

The human factors involved in the Revolut incident:

What this means for Revolut users and other neobank customers

If you bank with Revolut or another neobank, this kind of incident matters even if your login was never hacked. The risk is not only that someone saw your data once. It is that exposed identity or account details can make later scams much more convincing.

Attackers may know your name, address, date of birth, that you are a Revolut or neobank customer, partial account details, or the type of documents you provided for verification. That information can support:

• A convincing fake call, chat or email claiming to be from Revolut, another neobank, your traditional bank, a delivery company, tax office or police
• Attempts to persuade you to share a one-time passcode, card details, recovery code or screen access
• Identity fraud, such as applying for services or opening accounts while pretending to be you
• Targeted phishing that refers to real personal or account details to build trust

Data exposure does not mean fraud will definitely happen. It does mean Revolut users and customers of other digital banks should treat unexpected contact with extra caution, especially messages that mention the incident, ask for codes, or push you to act fast.

Revolut advises customers who receive suspicious contact to confirm it through in-app support and not share personal or financial information unless they are sure the contact is legitimate.

What to do if you are affected

Follow the instructions in any official notification from Revolut. Do not use links or phone numbers contained in unexpected emails, text messages or calls claiming to be about the incident. Instead, open the Revolut app yourself or use contact details from its official website.

Take these practical steps:

1. Check for an official notification in the Revolut app and review what information was involved.
2. Change your Revolut password if Revolut recommends it, especially if you have reused it elsewhere. Use a unique password stored in a password manager.
3. Turn on two-factor authentication wherever it is available. Prefer an authenticator app or hardware security key where possible.
4. Review account activity, cards, transfers and login alerts. Report anything unfamiliar promptly through the official app or website.
5. Be sceptical of unexpected calls, emails and texts, even if the sender knows personal details about you.
6. Never share one-time passcodes, recovery phrases, passwords, card PINs or remote-access permissions with anyone who contacts you unexpectedly.
7. If identity documents were involved, watch for unexplained accounts, bills, contracts or credit activity in your name, according to the options available in your country.
8. Save evidence of suspicious contact, then report it through the relevant official channel.

A safer way to verify important requests

Use the pause, verify, minimise rule.

For organisations handling personal data

Awareness training should cover realistic work situations, not only generic phishing emails. Staff who handle customer data should practise how to respond to official-looking requests for information.

Useful controls include:

• Verify the identity and authority of a requester through an independent contact route.
• Require a second authorised person to review high-risk data disclosures.
• Confirm the legal basis, exact scope and minimum data needed before sharing anything.
• Use approved secure channels for sensitive data rather than replying by ordinary email.
• Escalate unusual, urgent, broad or confidential requests to privacy, legal or security teams.
• Keep a record of the request, verification steps, approvals, data shared and recipient.

The goal is not to make employees suspicious of everyone. It is to make safe verification a normal, supported part of doing their job.

Key takeaway

A cyber incident does not always begin with malware, a stolen password or a technical system failure. Sometimes the attacker wins by making a trusted person follow a trusted process for the wrong person.

For individuals and organisations alike, the safest habit is simple: official-looking is not the same as verified.

Glossary: terms to learn