A Real Government Domain Asked for Customer Data — and Revolut Sent It

A Real Government Domain Asked for Customer Data — and Revolut Sent It

On 12 September 2026 the fintech company Revolut confirmed what it described as a sophisticated external impersonation scam: an unauthorised party used an email on a legitimate government agency domain to submit fraudulent requests for customer information. The requests were fulfilled before the scheme was detected.

What makes this incident worth your attention is that it contains no breach in the usual sense. No software vulnerability, no leaked password, no malware. Revolut itself stated that its systems and customer funds were unaffected. Someone asked for the data the correct way through the correct channel, and received it. That is precisely why this matters to every business holding customer records, not just to banks.

What is actually confirmed

We limit ourselves to what the company announced and what specialist outlets reported, because the investigation is ongoing and much remains undisclosed:

• The method: mail sent from an unauthorised account inside a domain belonging to a real government agency, carrying the standing of an official information request.
• The data: identity and contact details including date of birth, postal address, email address and phone number, plus copies of identity documents such as passports and driving licences, along with the facial verification images collected during know-your-customer checks.
• The scale: the company said a limited number of customers, and released no figure.
• The agency: Revolut declined to name the government body whose domain was used, citing the ongoing investigation.
• The response: the address was blocked, affected customers were notified directly, and the company alerted the relevant government agency, law enforcement, financial regulators and data protection authorities.

A crypto security researcher known as ZachXBT assessed that the targeting appeared aimed at high net worth customers, suggesting the construction of detailed profiles rather than indiscriminate collection. That is a researcher's assessment rather than a company statement, and we cite it as such.

Why the request worked: authentication is not authorisation

Most corporate mail systems rely on technical checks that confirm a message genuinely originated from the domain it claims. Those checks work well against ordinary forgery: anyone impersonating a domain they do not control gets rejected. But they were built to answer exactly one question — did this message leave that domain?

That is not the question you need answered. Your question is whether the person who wrote the message is authorised to ask for what they are asking. No email check answers that. The distance between the two questions is the distance between authentication and authorisation, and it is the gap this entire operation walked through. When the sending account sits inside the genuine domain — whether compromised or wrongly provisioned — every trust indicator your team can see will be green.

The practical consequence: your mail gateway's job ends at delivering the request intact. Judging the request is human work, and it needs a written procedure rather than individual instinct.

Your business gets the same request in a simpler form

It is easy to file this away as a distant European fintech story. But the requests reaching Saudi businesses every day are the same thing in plainer clothing: an email asking for a customer statement, a message requesting employee details for a regulatory purpose, a call asking you to confirm contract particulars, correspondence from an address bearing a familiar official name asking for documents to complete a procedure.

In most small and mid-sized firms that request is handled like this: it lands with an employee, the sender looks official, refusing an official body feels riskier than complying, and the file is sent. There is no record of who asked, what went out, or when. There is no independent verification step. When the problem surfaces later, the company has nothing to reconstruct events with.

Note the pressure being applied as well. Urgency and official standing together are what disable verification. An employee who fears being blamed for obstructing a government procedure will skip the confirming call, and that is the designed effect of the approach rather than a side effect.

What Saudi law requires of you

The Personal Data Protection Law does not leave this open. It places a double obligation on your business: disclose only where permitted, and report when you get it wrong.

• Article 15 sets out the cases in which personal data may be disclosed, including where the requesting party is a public entity and the request serves a security purpose, implements another law, or meets judicial requirements, as specified by the regulations.
• Article 16 governs the cases where disclosure must be withheld, including where it would affect national security, endanger the safety of individuals, or interfere with an ongoing investigation.
• Article 20 obliges the controller to notify the competent authority and the data subjects of a breach or unlawful disclosure. The implementing regulations set a 72-hour window for notifying the competent authority through the National Data Governance Platform.

Read the three together and the decisive point emerges: the law grants the right to the public entity, not to the email. A request arriving from a public entity's domain does not make the request theirs. The legal duty to verify remains with you as the data controller, and it does not transfer to a sender merely because they looked official.

The Origami view

Origami is a technology company building systems for Saudi businesses, and a pattern we see repeatedly is that nearly all security investment goes into preventing unauthorised entry: passwords, two-factor authentication, firewalls. Those are necessary, but they guard one door. The incident we are discussing never came through the door. It knocked, asked for the data, and was handed it. No technical setting stops an authorised employee from sending a file to someone who asked for it in a way that looked correct.

So we treat data leaving the business as a procedure built into the system rather than guidance written in a manual: who holds the permission to export customer data, whether every export is logged with who did it and when and why, and whether third-party requests follow an approval path. A company that can answer what data left here last month and why within a minute has something to defend itself with. A company that cannot will discover the gap on the day it needs the answer.

A one-page procedure to adopt this week

This needs no project and no budget. It needs a written, published rule that protects your employee from having to decide alone under pressure:

• No customer or employee data leaves on the strength of an incoming message alone. The message opens the request; it does not execute it, however official the sender appears and however urgent the tone.
• Verify through an independent channel. Do not reply to the message and do not call a number written inside it. Call the number published on the entity's official website. That single step would have stopped this entire operation.
• One named approver. One person authorised to release data to an external party, with a named deputy for absences. Spreading the permission across everyone means nobody is accountable.
• A written log for every request. Who asked, in what capacity, what data, who approved, how it was verified, and the date. One row in a spreadsheet is enough, and its value shows up a year later rather than today.
• Send the minimum. If the request is legitimate, send exactly what was asked for, not the whole file or the entire table. The volume you send is the size of the damage if the request turns out to be fraudulent.
• Know the reporting path before you need it. Who notifies SDAIA within 72 hours, through which platform, with what details. Time spent hunting for the procedure comes straight out of the deadline.

The principle underneath all of it is that verification is not obstruction. A genuine official body will not object to a confirming call placed to its own published number, and whoever objects to being verified is exactly who should be verified. Put this in writing for your team so that refusing a request is never a personal risk one employee has to carry alone.

Sources

• TechCrunch — Revolut's confirmation of the incident on 12 September 2026, its statement, and the categories of data disclosed.
• Bloomberg — the company's disclosure that a limited number of customers were affected through an email-based scam.
• Saudi Data and Artificial Intelligence Authority (SDAIA) — the competent authority for the Personal Data Protection Law, its implementing regulations, and the National Data Governance Platform.
• Personal Data Protection Law — the official text, including the articles on permitted disclosure, prohibited disclosure, and breach notification.
• National Cybersecurity Authority — controls covering data protection and cyber incident management in organisations.