The Challenge
Revolut's security team faced a straightforward yet deceptive attack: fraudulent data requests from a legitimate government agency email domain. These requests had valid technical domain authentication. Revolut employees, following standard legal compliance procedures, fulfilled them.
The threat actor obtained what Muhammad Yahya Patel, vCISO at Huntress, described as "a complete identity theft kit", full names, dates of birth, addresses, phone numbers, government ID documents, verification selfies, IBANs, account-opening dates, transaction histories, and Bitcoin wallet reference numbers.
Independent researcher ZachXBT disclosed the breach on September 12, sharing a customer notification from the day before. Revolut confirmed the incident, calling it "a sophisticated external impersonation scam" affecting a "very limited group of customers." Although the company's systems and customer funds remained secure, the incident revealed a critical gap: passing legal compliance checks doesn't ensure the requester's legitimacy.
Regulatory Environment
Revolut operates in a regulatory environment that demands quick responses to lawful data requests. Financial institutions must comply with law enforcement inquiries, court orders, and regulatory demands. Delays can lead to regulatory penalties or obstruct investigations.
This creates tension. Your legal team needs to fulfill legitimate requests efficiently. Your security team must verify the requester's identity. When a request arrives from an authenticated government domain, technical signals indicate legitimacy. Domain authentication protocols like SPF, DKIM, and DMARC confirm the email's origin.
However, domain authentication only proves the email came from the domain's infrastructure. It doesn't confirm the sender's authority to request customer data. Government agency domains, like corporate domains, can be compromised. Employees can be phished. Credentials can be stolen. An authenticated email from a legitimate domain can still be fraudulent.
Fintech companies face an additional challenge: their business model relies on digital identity verification. Revolut verifies customers remotely, without in-person document checks. This verification infrastructure should inform how they handle incoming data requests, but it often doesn't. The controls for verifying customers and requesters operate separately.
Revolut's Response
Revolut's employees followed their standard legal compliance process. They treated requests from authenticated government domains as legitimate and disclosed the requested customer information.
The company detected the fraud after the fact. Once the security team identified the fraudulent nature of the requests, they blocked the email address, notified affected customers, and alerted the relevant government agency, enforcement agencies, data protection regulators, and financial regulators.
This reactive approach is common. Most organizations lack verification controls that distinguish between an authenticated email and an authorized request. They rely on post-disclosure detection, monitoring for anomalies in request patterns, unusual data access, or external tips.
Impact and Risks
The breach exposed sensitive customer information to an unauthorized third party. Revolut described the affected group as "very limited" but didn't specify numbers or targeted markets.
The exposed data creates long-term risk for affected customers. As Patel noted, the combination of government IDs, verification selfies, transaction histories, and account details provides everything needed for identity theft and targeted fraud. Jamie Akhtar, CEO of CyberSmart, warned that this information enables highly targeted phishing attacks, even though customer funds and Revolut's systems weren't compromised.
The breach also triggered mandatory disclosure obligations. Revolut notified customers, regulators, and law enforcement. For a fintech company built on trust and digital identity verification, the reputational impact extends beyond the immediate incident.
Improving Verification Controls
Patel's question cuts to the core issue: "Why didn't a regulated financial institution handling highly sensitive data have sufficiently rigorous verification controls to catch it?"
A robust verification control framework for third-party data requests should include:
Out-of-band verification for sensitive requests. When a data request arrives via email, verify it through a separate channel. Call the government agency's published contact number. Confirm the request with the specific individual whose name appears on the request. Don't use contact information provided in the email itself.
Request metadata analysis. Compare the request to historical patterns. Is this the first request from this individual? Does the scope of data requested match typical patterns for this agency? Are multiple requests arriving in a compressed timeframe?
Dual authorization for bulk disclosures. Require two separate employees to review and approve any request that includes identity documents, financial records, or transaction histories. One reviewer checks legal compliance. The other verifies the requester's legitimacy.
Technical verification beyond domain authentication. Domain authentication proves the email came from the claimed domain. It doesn't prove authorization. Build verification workflows that require additional proof: case numbers that can be independently verified, court order reference numbers you can look up, or digital signatures from known public keys.
Segregation between compliance and security review. Your legal team should confirm the request is properly formatted and legally valid. Your security team should confirm the requester is who they claim to be. Don't collapse these into a single check.
Action Steps for Your Team
If you're handling regulated data, you're receiving third-party requests. Law enforcement inquiries, regulatory audits, court orders, and government investigations all require data disclosure. The question isn't whether to comply, it's how to verify you're complying with the right party.
Start by mapping your current verification process. What checks do you run when a data request arrives? Who authorizes disclosure? What evidence do you require beyond an authenticated email? If your answer is "we check that the email domain is legitimate," you have the same gap Revolut had.
Build verification controls that match the sensitivity of the data. A request for publicly available information needs less verification than a request for government IDs and transaction histories. Define verification tiers based on data classification.
Test your controls with tabletop exercises. Have your security team send a simulated fraudulent request through your standard channels. Does your legal team catch it? If not, you've identified a control gap before an attacker does.
Document your verification decisions. When you fulfill a data request, record what verification steps you took, who authorized the disclosure, and what evidence you reviewed. If you later discover the request was fraudulent, this documentation shows your controls were operating as designed, even if they weren't sufficient.
Your legal compliance obligations don't conflict with security verification. They require it. A fraudulent disclosure isn't compliance. It's a data breach.
