Revolut has confirmed a sensitive customer data breach after an unauthorized third party successfully impersonated a legitimate government authority and persuaded employees to release customer information.
The incident is particularly significant because there was no conventional intrusion into Revolut's core infrastructure. Instead, attackers exploited something much harder to patch: trust in an apparently legitimate external request.
Revolut described the incident as a “sophisticated external impersonation scam.” The company said its systems and customer funds were not affected, but a limited group of customers had personal and financial information disclosed to the unauthorized party.
What happened?
The attackers submitted fraudulent requests for customer information using an email address associated with a legitimate government agency domain.
Because the request appeared to come from an official government source, Revolut employees processed the requests as legitimate information demands.
The attacker therefore did not need to exploit a software vulnerability, steal administrator credentials or break through Revolut's network perimeter.
Instead, the attack targeted the human and procedural layer of security.
Once Revolut identified the fraud, the company blocked the email address and notified the relevant government agency, law-enforcement authorities, data-protection authorities and financial regulators. Affected customers were also contacted directly.
What customer data was exposed?
Information potentially disclosed included highly sensitive identity and financial information.
Reported categories include:
- Names and dates of birth
- Postal, email and telephone details
- Copies of passports and driving licences
- Identity documents
- Verification selfies
- Account statements
- IBAN and withdrawal information
- Transaction histories, including cryptocurrency transactions for some customers
The exact information varied by customer, and Revolut has been contacting affected individuals directly with details of what was involved.
As of September 15, reports citing information from Revolut put the affected group at approximately 680 customers. Revolut has described the group as limited and has not indicated that the entire customer base was affected.
Why is this attack different from a typical data breach?
Traditional breaches usually involve attackers gaining unauthorized technical access to a system.
For example, an attacker might exploit:
- A vulnerable internet-facing application
- Stolen administrator credentials
- A cloud configuration error
- Malware
- A software vulnerability
- A compromised third-party service
The Revolut incident demonstrates another category of threat: authorized systems being manipulated into performing an unauthorized action.
From the perspective of the organization's systems, an employee received what appeared to be a legitimate government request and processed it.
The security failure therefore occurred at the intersection of identity, trust, verification and business processes.
This is one reason social engineering remains such a serious problem even for organizations with mature technical security controls.
Why impersonating a government authority worked
Government and law-enforcement requests naturally carry a high level of authority.
Employees handling sensitive information may be accustomed to responding quickly to legitimate regulatory or legal requests. An attacker who can make such a request appear authentic can potentially bypass many of the controls designed to stop conventional cyberattacks.
In this case, the request came through a legitimate government email domain, making conventional checks based on the sender's domain considerably less useful.
That is an important distinction:
A legitimate domain does not automatically mean a legitimate request.
Organizations need to verify not only where a request came from, but also whether the request itself is genuine, authorized and consistent with established procedures.
What are the risks for affected customers?
Revolut says customer funds were not affected and that its core systems were not compromised.
However, exposed identity and financial information can create significant second-stage risks.
Attackers who possess legitimate personal information can use it to make future scams considerably more convincing.
For example, criminals could potentially use the leaked information to:
- Impersonate Revolut support staff
- Conduct targeted phishing campaigns
- Attempt identity theft
- Build convincing investment or cryptocurrency scams
- Target customers through phone, email or messaging platforms
- Combine the information with data obtained from other breaches
This makes the incident more than a simple privacy problem. It can provide attackers with the background information needed to make subsequent social-engineering attacks much more credible.
What should affected customers do?
Customers who have received a direct notification from Revolut should take it seriously.
Recommended precautions include:
- Be suspicious of unexpected calls, emails or messages referring to the Revolut incident.
- Never provide passwords, authentication codes or recovery information to someone who contacts you unexpectedly.
- Do not transfer money to a “secure” account because someone claims your Revolut account has been compromised.
- Verify communications through the official Revolut application rather than using contact details supplied by an unexpected message.
- Monitor account activity and statements for anything unusual.
- Treat unexpected requests involving identity documents with particular caution.
- Report suspicious activity through Revolut's official support channels.
Revolut itself advises customers to stop communicating with suspected scammers and use official channels if they believe they have been targeted.
What organizations can learn from the incident?
The most important lesson is that technical security controls cannot compensate for weak verification processes.
Organizations handling sensitive information should consider implementing additional controls around external information requests, particularly those involving government agencies, law enforcement, regulators or other high-authority entities.
Effective measures can include:
✅ Independent verification
Sensitive requests should be verified through a second, independently sourced communication channel.
An employee should not rely solely on the contact information contained in the original request.
✅ Dual authorization
Highly sensitive customer information should require approval from more than one authorized employee before disclosure.
✅ Strict data-minimization rules
Even when a request is legitimate, organizations should release only the information that is legally and operationally necessary.
✅ Strong identity verification
Organizations should verify the person and authority behind a request, not simply the email domain.
✅ Continuous social-engineering training
Employees responsible for customer data need training against increasingly sophisticated impersonation techniques, including attacks involving legitimate infrastructure and apparently valid communications.
✅ Logging and monitoring
Requests for large or unusual volumes of sensitive information should generate alerts and receive additional scrutiny.
The bigger cybersecurity lesson
The Revolut incident demonstrates an important evolution in modern cyberattacks.
Attackers do not always need to break into a system.
Sometimes the more effective strategy is to convince the organization to open the door itself.
This is particularly relevant for banks, fintech companies, healthcare providers, government contractors and other organizations that routinely process highly sensitive information and receive large volumes of legitimate external requests.
Security teams therefore need to protect not only networks, applications and identities, but also the decision-making processes that determine when sensitive information is released.
Final thoughts
The Revolut incident is a powerful reminder that cybersecurity is not exclusively a technical problem.
A perfectly secured database can still be followed by a data breach if an attacker can successfully convince an authorized employee to provide the information.
Organizations must verify the legitimacy of sensitive requests independently — even when those requests appear to come from trusted government or institutional sources.
