The Real Sender, the Fake Request: What Revolut Teaches Every Board About Its Compliance Desk

Nobody hacked Revolut. That is the uncomfortable part.

On September 12, the London-based fintech confirmed that it had handed sensitive customer records to an unauthorized party. No firewall was breached. No malware ran on its systems. According to the company, someone used an email account on a legitimate government agency domain to submit requests for customer information, and Revolut's staff fulfilled them. The company called it "a sophisticated external impersonation scam."

What went out the door, according to the notification customers received: dates of birth, home and email addresses, phone numbers, copies of passports and driver's licenses, verification selfies, account statements, and transaction histories. Some affected customers reported that their notices also listed bank account numbers (IBANs) and withdrawal records.

Revolut says its systems and customer funds were unaffected, and that it notified the affected customers, the government agency involved, law enforcement, and data protection and financial regulators. It described the number of affected customers as "limited." The Financial Times and SecurityWeek have since put the figure at approximately 680. Britain's Information Commissioner's Office is reported to be investigating.

Roughly 680 customers sounds small for a company that says it serves more than 80 million. It is not small. Reporting from The Record indicates the targets appear to have been high-net-worth individuals, many with ties to crypto businesses. People claiming responsibility have posted what they say is customer data on Telegram and publicly demanded a ransom; Revolut told SecurityWeek it has received no direct contact or demand from them. Within days, at least one affected customer received a convincing phishing text in the same thread as legitimate Revolut messages. Whether that campaign is connected to the disclosure is not yet known.

This was a targeting operation, and the target list was delivered by the victim's own compliance process.

The email passed every check. That was the problem.

Here's the detail executives need to sit with. Reporting indicates the fraudulent requests carried valid technical authentication for the government domain. In plain terms: the email really did come from that government's mail system. Every automated control that asks "is this sender who they claim to be?" answered yes.

The sender was real. The request was fake.

Most organizations have built their verification around the first question and never asked the second. Email authentication tells you which mail server sent a message. It tells you nothing about whether the person behind the keyboard has the authority to ask for what they are asking for, or whether that account has been compromised or misused.

How did a criminal get inside a government mailbox? According to threat intelligence firm Hudson Rock, as reported by SecurityWeek, the account appears to belong to an employee of Italy's Ministry of the Interior, and Hudson Rock assesses that the attacker likely used credentials harvested by "infostealer" malware, the kind that quietly scrapes saved passwords from an infected computer. The attacker also claims the requests went on for roughly five months before anyone noticed. That timeline has not been confirmed by Revolut, but if it is even close, it is the more alarming detail. One bad call is a mistake. Months of them is a process.

This is not a new attack. In 2022, Bloomberg reported that Apple and Meta had provided customer data in mid-2021 to hackers who forged "emergency data requests," the fast-track process law enforcement uses when someone's life may be in danger and there is no time for a court order. In November 2024, the FBI warned companies that criminals were selling access to compromised U.S. and foreign government email accounts on underground forums, specifically for sending fraudulent emergency data requests, sometimes paired with forged subpoenas.

The playbook was published. The warning was issued. And a well-resourced, heavily regulated fintech still got caught.

Compliance is not security, and this is what that looks like

In Cyber Risk Is Business Risk, I spend a lot of time on the gap between being compliant and being secure. Revolut is a near-perfect illustration, because the failure happened inside a compliance function.

Every regulated company has a team whose job is to say yes to lawful government requests, quickly. Regulators expect it. Law enforcement depends on it. Slow-walking a genuine emergency request can carry real consequences. So these teams are built for speed and deference to authority, which is exactly the psychological profile a social engineer looks for.

Your security team probably spends its energy on the front door: firewalls, endpoint tools, multi-factor authentication. Meanwhile, a small team in legal or compliance holds the authority to package up a customer's passport, selfie, and full transaction history and email it to a stranger. That team is rarely in scope for a penetration test. Its process is rarely red-teamed. It may not appear on the risk register at all.

That is a governance gap, not a technology gap. And governance gaps are the board's business.

The Three Questions, pointed at the request desk

What are we protecting? Not "customer data" in the abstract. The complete identity kit: government ID, a live selfie, home address, and a map of where the money is. Combined, that is everything a criminal needs to impersonate a customer, take over an account, or, in the case of wealthy crypto holders, show up at their door. Know which of your processes can assemble that package, and who can trigger it.

What happens if we lose it? Revolut is reportedly weighing a public listing and recently received conditional approval from a U.S. banking regulator to set up a national bank. An incident like this lands in the middle of both conversations. The direct cost may be modest. The cost to trust, regulatory standing, and customer confidence among exactly the high-value clients a bank most wants to keep is not. When your customers learn that the danger came through a door you opened voluntarily, "our systems were not breached" is cold comfort.

Who decides? This is the one I would press hardest. Who in your organization has the authority to release a full customer file to an outside requester? Is it one person? Does a second person have to approve? Does anyone call the requesting agency back on a number you looked up yourself, not one in the email? If the honest answer is "someone in compliance, based on the email," you have made a risk decision without ever bringing it to the level where risk decisions belong.

What to ask your CISO (and your General Counsel) this week

This one needs both of them in the room, because it lives between their functions.

1. "How many teams can release customer data to an outside party, and do we have a list?" Law enforcement response, subpoena handling, customer service, fraud, HR, and vendor management often each have a path. Most companies have never mapped them.
2. "What do we do to verify a government request beyond checking the sender's address?" The answer you want is an out-of-band callback to a number from an independent directory, and a check against a known list of authorized contacts.
3. "Is there a two-person rule for releasing identity documents, selfies, or full account histories?" High-sensitivity data should never leave on one person's judgment.
4. "Do we scope the request, or send everything?" Emergency requests should get the minimum data needed for the emergency, with the full record held until proper legal process arrives.
5. "When was this process last tested?" If no one has ever sent your compliance desk a realistic fake request, you do not know whether it would stop one.
6. "If we did this by mistake, how fast would we know?" Revolut detected the problem and blocked the address. The time between disclosure and detection is the window your customers are exposed.

The takeaway

The attack surface is not just your technology. It is every process that can move sensitive data on the strength of someone's say-so. Criminals have figured out that the fastest path to your customers' most sensitive records may run straight through the people whose job is to be helpful to authority.

Boards do not need to understand email authentication protocols. They need to ask one question: who in this company can hand our customers' identities to a stranger, and what stops them from doing it by mistake? If nobody can answer that crisply, you have found your next agenda item.