Current advisory · Verified against Cisco guidance updated 9 September 2026. Check the primary source for revisions before acting.
01

What happened

Revolut confirmed in September 2026 that an unauthorised third party used an email address on a legitimate government agency domain to submit fraudulent requests for customer information. Revolut described the incident as a sophisticated external impersonation scam, rather than a compromise of its own core systems.

The company said a limited number of customers were affected, that it blocked the address when it identified the activity, and that it notified the relevant agency, law enforcement, data-protection authorities and financial regulators. Revolut said its systems and customer funds were unaffected.

Reportedly exposed information may have included names, dates of birth, postal and email addresses, telephone numbers, identity documents, verification selfies, account statements, IBANs, withdrawal records and transaction histories, including Bitcoin transactions. Revolut has not publicly identified the agency or disclosed the exact number of affected customers. Later reporting cited an estimate of about 680 customers; treat that figure as reported, not as a confirmed company total.

02

Why it matters

This was a failure of trust validation around a sensitive-data process. A request can arrive from a real government domain, pass normal email authentication checks and still be fraudulent if the underlying mailbox or account has been abused.

The risk is broader than identity exposure. A combination of identity documents, verification imagery, contact details and transaction history can make follow-on impersonation, extortion and targeted phishing more credible. The reported appearance of phishing messages after the disclosure also shows why customer communications and monitoring need to continue after containment.

03

Who is affected

Revolut customers who received a direct notification should follow the account-specific information in that message. For other organisations, the relevant population includes teams that handle law-enforcement, regulatory or legal data requests; privacy and fraud teams; customer support; and security functions responsible for identity, email and third-party risk.

04

What to do next

  1. Map sensitive-request workflows. Identify every route by which a government, regulator or law-enforcement request can cause customer data to be released. Include email inboxes, portals, ticketing systems and outsourced operations.
  2. Add independent verification. Require a second channel, such as a callback to a number sourced independently of the request, a known portal, or a documented escalation path. Do not treat a valid sender domain or email authentication as sufficient proof.
  3. Use a risk-based approval gate. Bulk requests, identity documents, financial records, transaction history and verification images should trigger additional approval and a recorded legal basis before disclosure.
  4. Preserve evidence. Retain the original request, headers, attachments, access logs, approvals, exported records and communications. Capture the decision trail before closing or changing the workflow.
  5. Prepare affected-person support. Coordinate privacy, fraud, customer-support and communications teams. Give affected people specific guidance for suspicious calls, texts, emails and account-recovery attempts.
  6. Reassess after containment. Review whether the same requester, domain, staff process or supplier relationship could be used again. Test the revised control with a realistic exercise.
05

For security leaders

Ask for an evidence-based account of which requests were received, approved and fulfilled; what data categories were disclosed; how the request was independently validated; and which controls now prevent recurrence. Keep the customer-fraud risk visible even when funds and core systems were not accessed.

06

For technical teams

Review mail authentication, mailbox access, forwarding rules, delegate permissions and audit logs for the trusted government account involved where those records are available. On your own side, identify automated exports, broad search permissions and approval bypasses in data-request tooling. Monitor for post-incident phishing that uses details plausibly connected to the exposed records.

07

For GRC teams

Update the data-disclosure procedure, control mapping and supplier assurance questions. Record the independent-verification requirement, approval thresholds, evidence-retention period and accountable owner. Revisit breach-notification and contractual analysis with privacy and legal specialists based on the confirmed scope.

08

What to monitor next

Watch for Revolut's updates on affected customers, data categories and the investigation; regulator or law-enforcement statements; credible reports of phishing or extortion; and evidence that the abused government account or related requests affected other organisations.

Primary sources

Start with the original guidance and check for updates before applying this runbook.