Summary

• Revolut fulfilled fraudulent data requests that came from an unauthorized email account created inside a legitimate government agency domain.
• The requests passed SPF, DKIM and DMARC checks, the standard email authentication controls used to block spoofed email.
• Exposed data included identity documents, onboarding selfies, IBANs, wallet references and full transaction histories, including Bitcoin activity. Passwords, private keys and full card details were not shared.
• Revolut said systems and customer funds were not affected and notified a limited number of customers, regulators and law enforcement.
• The attack targeted a process (how data requests are verified), not a system. Out-of-band verification is the control that would have stopped it.

What happened in the Revolut data disclosure incident?

Revolut treated a fraudulent information request as a genuine request from a government agency and sent sensitive customer data in response. The request came from an unauthorized email account created within the agency’s real domain infrastructure, carried valid domain authentication and passed SPF, DKIM and DMARC.

Customer notices began circulating on September 11, 2026. Blockchain investigator ZachXBT and former Mt. Gox CEO Mark Karpelès helped bring the notices into public view, and crypto media covered the story on September 12. Revolut later confirmed the incident to media outlets.

A Revolut spokesperson described it as “a sophisticated external impersonation attack where an unauthorised third party utilised a legitimate government agency domain email to submit fraudulent requests for information.” After detection, Revolut blocked the sender and alerted the agency, law enforcement, data protection authorities and financial regulators.

Revolut has not disclosed how many customers were affected or which agency’s domain was abused, citing an ongoing police investigation. On-chain researchers said the affected group appears small and skewed toward higher net worth individuals.

What customer data did Revolut share?

According to the customer notices, the disclosure package included:

• Full names, dates of birth, occupations, postal addresses, email addresses and phone numbers.
• Copies of identity documents (passports or driver’s licenses).
• Verification selfies submitted during onboarding.
• Account statements with IBANs, account status, opening dates and wallet reference numbers.
• Withdrawal records and complete transaction histories, including Bitcoin activity.

Revolut said the derived biometric face template was not shared, only the original selfie image. Login credentials, passwords, private keys and full payment card details were not part of the disclosure.

Why did the fake request pass SPF, DKIM and DMARC?

The fake request passed authentication because it was sent from the real government domain. SPF, DKIM and DMARC check whether an email truly comes from the domain it claims. They do not check whether the individual account sending it is authorized to request data.

The three controls answer different questions:

An attacker with an account inside a trusted domain, whether created without authorization or taken over, inherits that domain’s reputation. Every check passes, and the message lands as trusted mail.

What is the difference between DMARC and brand protection?

DMARC protects your own email domain from being spoofed in email. Brand protection covers the impersonation that happens outside your infrastructure: lookalike domains, fake websites, fake apps, fake social media profiles and fake support channels that use your name.

The Revolut case shows the limit of both when used alone. DMARC worked as designed, and the attacker still succeeded because the trusted identity was abused from the inside. Brand protection matters after the incident, when attackers use the news to send follow-up phishing that impersonates the affected company or the agency involved.

How can financial institutions verify government and law enforcement data requests?

Financial institutions can stop this attack pattern by verifying every high-sensitivity data request through a channel the requester did not provide. Practical steps, in order of priority:

1. Confirm each request out of band, using a contact number or portal you sourced independently, never the details in the email.
2. Keep a registry of known agency contacts and request formats, and flag any request from an address that is not on it, even inside a valid domain.
3. Require two-person review for any disclosure that includes identity documents, biometric images or full transaction histories.
4. Apply data minimization: share only the fields the legal basis requires, not the full customer file.
5. Log every disclosure and alert on unusual volume, unusual targets (for example, high net worth accounts) or unusual timing.
6. Train compliance and legal teams to treat urgency and authority in a request as risk signals, not reasons to skip checks.

Why does this matter for crypto users?

Pairing a passport image and home address with a full Bitcoin transaction history links a real-world identity to on-chain activity. For customers who buy, sell or withdraw crypto through Revolut or its Revolut X exchange, that link raises the risk of targeted phishing, extortion and physical threats against self-custody holders.

Crypto users are already a frequent phishing target. In PhishFort’s Digital Threat Intelligence Report for January to June 2026, Crypto and DeFi accounted for 14.4% of confirmed brand impersonation cases and Financial Services and Banking for 18.6% (PhishFort internal data).

What should affected Revolut customers watch for?

Affected customers should expect follow-up phishing that uses their real details to look credible. Warning signs include:

• Messages that reference your passport, address or transaction history and ask you to “verify” or “secure” your account.
• Unsolicited contact from “Revolut support”, a regulator or a government agency, by email, SMS, phone, Telegram or WhatsApp.
• Requests to move funds to a “safe” wallet or to share recovery phrases or one-time codes.
• Links to domains that look similar to revolut.com but are not the official domain.

Contact Revolut only through the official app, and treat any unexpected request for more data as suspicious, even when it knows your details.

How PhishFort helps after an impersonation incident

After incidents like this, attackers register lookalike domains and open fake support accounts to reach worried customers. PhishFort Brand Protection monitors new domain registrations, social media and app stores for impersonation of your brand and handles the takedown with registrars, hosting providers and platforms.

Frequently asked questions

Did hackers breach Revolut’s systems?

No. Revolut said its systems and customer funds were not affected. The attacker used social engineering: a fraudulent request from a real government email domain convinced Revolut to send customer data voluntarily.

Does DMARC stop impersonation attacks?

DMARC stops attackers from spoofing your exact domain in email, but it does not stop attacks sent from a legitimate domain the attacker controls or has access to. In the Revolut case, the request passed SPF, DKIM and DMARC because it came from a real government domain.

What data was exposed in the Revolut incident?

According to customer notices, the data included names, contact details, passport or driver’s license copies, onboarding selfies, IBANs, wallet references and full transaction histories including Bitcoin activity. Passwords, private keys and full card details were not shared.

How should banks verify law enforcement data requests?

Banks should confirm every sensitive request through an independently sourced contact at the requesting agency, keep a registry of known agency contacts, require two-person review for identity data and share only the minimum data required.

Sources

• Revolut statement to media on the impersonation attack, September 2026.
• Customer notices shared publicly by ZachXBT and Mark Karpelès, September 11, 2026.
• PhishFort Digital Threat Intelligence Report, January to June 2026 (PhishFort internal data).