When Trusted Requests Become the Attack Path: Lessons From Revolut’s Data Breach

Revolut told reporters that an unauthorised third party used an email account on a legitimate government-agency domain to submit fraudulent requests for customer information. The company described the incident as a sophisticated external impersonation scam and says it blocked the email address after discovery.

Notifications reviewed by TechCrunch and The Block say the exposed information may have included names, dates of birth, contact details, identity documents, verification selfies, account statements, IBANs, withdrawal records, and transaction histories. The exact data differs by customer and has not been independently established for every affected account.

A message can pass technical domain-authentication checks and still be malicious if the sending account is compromised, misused, or operated by an unauthorised person. A familiar domain lowers suspicion, but it does not establish who is behind the request, whether the legal authority is valid, whether the requested records are necessary, or whether the delivery destination is safe.

The defensive lesson is broader than phishing awareness. The attacker reportedly used a channel that employees expected to receive and relied on a legitimate-looking request to activate an authorised business process. That makes the request-handling workflow itself part of the attack surface.

• A valid sending domain should contribute to confidence, but never complete the identity check on its own.
• High-risk disclosures need independent verification that does not reuse contact details supplied in the incoming message.
• Legal and privacy review should test authority and proportionality, not only whether the request appears correctly formatted.
• Sensitive data should be released through controlled exchange mechanisms with recipient authentication, expiry, and auditability.
• Request metadata should be monitored as a behavior stream so repeated targeting, unusual urgency, and new requester patterns are visible.

1. 1

   Inventory external disclosure workflows. Map law-enforcement, regulatory, legal, fraud, emergency, and data-subject requests. Record the intake channels, owners, approvers, data sources, and delivery mechanisms.

2. 2

   Separate channel trust from requester verification. Verify the person and agency using an independently maintained directory, known portal, or callback procedure. Treat a new contact, changed destination, or urgent exception as a reason for secondary review.

3. 3

   Require dual control for sensitive exports. Use two-person approval for identity documents, verification images, financial histories, or combinations that could enable impersonation and targeted fraud.

4. 4

   Minimise each response. Return only the fields, accounts, and time period supported by the validated authority. Generate a manifest of what was disclosed and why each category was included.

5. 5

   Instrument the workflow. Log requester identity, agency, case reference, approvers, search terms, records exported, destination, and delivery result. Alert on volume spikes, repeated high-value targets, new domains or accounts, and policy exceptions.

6. 6

   Prepare for downstream harm. If identity and financial records are exposed, plan for targeted phishing, account-recovery abuse, synthetic identity fraud, doxxing, and extortion—not only unauthorised transactions.

• Preserve the original messages, full headers, attachments, portal records, and any authentication or signing evidence.
• Identify every request associated with the sender, agency, case references, recipients, delivery destinations, and affected customers.
• Determine which checks were performed, which systems or people approved the response, and whether exceptions or urgency influenced the decision.
• Build a field-level record of the disclosed data and confirm whether copies remain accessible in mailboxes, ticketing systems, exports, or file-transfer platforms.
• Review related account-recovery attempts, profile changes, phishing reports, suspicious contact, and fraud indicators for affected people.
• Share indicators and request patterns with the relevant agency and authorities without speculating publicly about the agency’s identity or cause of compromise.

Revolut’s public comments, as reported by TechCrunch and The Block, establish the company’s account of the incident but do not provide a forensic report. The exact affected population, agency, countries, timeline, request count, compromise method, internal approval path, and full data scope remain undisclosed.

The Cyber Security Hub newsletter cited a figure of around 700 affected customers. Threat Field Notes could not independently confirm that number from Revolut’s public comments, so this article does not present it as fact. Claims that particular customer groups were targeted also remain unverified.

This topic was surfaced by The Cyber Security Hub newsletter on LinkedIn. Threat Field Notes independently reviewed direct statements attributed to Revolut, affected-customer notification details reported by two publications, and official data-minimisation guidance before writing this defender-focused analysis in original language.