When the request looks official, check anyway
Somewhere in your business, someone can hand over customer data if the right person asks. A regulator, the police, a court, a government agency chasing a case. It happens rarely enough that most firms have never written down how that person checks who is actually asking before they send anything.
Revolut just found out what happens when nobody had.
What happened
Revolut, the UK-founded banking app used by more than 80 million people worldwide, has confirmed it disclosed sensitive customer records to a fraudster who impersonated a government agency. The request came from an email address on the agency's genuine domain. An unauthorised third party had taken over a mailbox inside it, according to The Register. Revolut's staff followed what Infosecurity Magazine reported as standard legal compliance: the request carried valid technical domain authentication, so it was fulfilled.
The data handed over included passport and driving licence copies, verification selfies, full names, dates of birth, home addresses, phone numbers, account statements, IBANs, and complete transaction histories, according to customer notification emails seen by The Register. Revolut says its own systems and customer funds were not touched. This was not a hack. Nobody broke in. Someone asked, and someone else said yes.
The company says it blocked the address on detection and told the real agency, law enforcement, data protection authorities, and financial regulators. It has not named the agency involved, and says only a small proportion of its customers were affected. People claiming responsibility have since posted samples of the data on Telegram and are demanding a ransom, per The Register.
Why the email being real does not make the request real
The uncomfortable lesson is that the usual advice, check the sender's domain, does not cover this case. The domain was genuine. The mailbox behind it was not under the agency's control at that moment. Muhammad Yahya Patel, a virtual chief information security officer (a part-time, outsourced security lead) at the security firm Huntress, put it plainly to Infosecurity Magazine: "For a fintech built on digital identity verification, the bar for verifying third-party data requests should be exceptionally high. The question is: why a regulated financial institution handling highly sensitive data didn't have sufficiently rigorous verification controls to catch it."
That question applies to any business that discloses customer data to someone claiming official standing, not just banks. If your process for verifying a data request stops at "does the email domain look right", it stops one step too early. A compromised government mailbox, a hijacked supplier account, or a convincing forgery on genuine-looking letterhead all clear that bar.
What to ask your own provider or process
You do not need a legal department to close this gap. You need one written answer to a question most firms have never asked: who is allowed to disclose customer data to a third party, and how do they confirm the requester is who they say they are, before anything goes out.
A workable answer has three parts. Slow the request down: nobody has to reply within the hour, and a genuine agency will not object to a callback. Verify through a second channel: ring the organisation on a number you already hold or find independently, never one supplied in the request itself. Get it in writing to a named person, not a shared inbox, so there is a record of who authorised what.
If your business occasionally gets asked for customer data, by a regulator, an insurer, a landlord's solicitor, anyone, ask whoever handles that request what they currently do to check. If the honest answer is "we look at where the email came from," you have the same gap Revolut had.
How Steelwise can help
Writing down who can disclose customer data, and what they check before they do, is a short piece of work most SMEs have never had reason to do until now. Get in touch if you want a hand with it.
Further reading
- ICO: sharing personal data with law enforcement authorities
- NCSC: phishing attacks, defending your organisation
- ICO: report a personal data breach