Revolut disclosed this month that customer data, full names, dates of birth, addresses, passport and driver's licence numbers, financial statements, facial verification images, ended up in the hands of a fraudulent third party. Around 700 customers globally were affected, about 12 of them in Ireland. A few weeks later, a second, unrelated incident surfaced: a breach at DriveWealth, the US broker that handles stock trading for Revolut customers, exposed a separate set of customer profile data.
Two breaches, same month, same company. Worth going through both, because they fail in almost opposite ways, and most security writeups about them are going to skip the part that actually matters to anyone building this kind of system.
No One Broke In
Here's the detail that gets buried under the word "breach": nobody hacked anything. Revolut received a data request from an email using what looked like a government agency's domain. Someone on the other end processed it, and handed over sensitive customer data to what turned out to be a fraudster, before anyone realized the sender wasn't who it claimed to be.
There's no firewall rule that stops this. No WAF signature catches it. No dependency scanner flags it. The system worked exactly as designed, take in a legitimate-looking request from an authority, provide the data it's asking for. The failure wasn't technical. It was a verification step that either didn't exist or wasn't followed under time pressure, for a channel, email, that has no reliable way to prove who actually sent it.
This is the failure mode that should worry backend engineers more than a SQL injection, not less. A SQL injection gets caught by a scanner eventually. A convincing enough email to the right inbox doesn't show up in any of your monitoring, because monitoring watches your systems, and your systems did exactly what they were told.
Email headers can claim almost anything. A domain that "looks like" a .gov or .gob address, a display name that matches a real agency, a request format that mirrors previous legitimate ones, none of that is proof of origin. If your process for handling law enforcement or regulatory data requests trusts the inbox it arrived in, you don't have a verification process. You have a filing system.
What Verifying a Data Request Actually Requires
If your company handles government or law enforcement data requests, and if you hold any personal data at scale, you probably do, the bar has to be higher than "the email looked right":
- Out-of-band confirmation. Call the agency back using a phone number you looked up independently, not one in the email's signature. This single step defeats almost every domain-spoofing and lookalike-address attack, because it forces the verification onto a channel the attacker doesn't control.
- A dedicated intake process, not an inbox. Legitimate requests should arrive through a portal, a legal case reference number, or a pre-established point of contact, something with an audit trail and a known set of prior requesters, not a cold email that could be the first contact from anyone.
- A second approver for anything sensitive. Passport numbers, financial records, biometric data, releasing any of that shouldn't be a single person's judgment call under a same-day deadline. Require sign-off from someone whose job is specifically to catch exactly this.
- Friction that survives urgency. Every one of these attacks is written to create time pressure, "urgent," "time-sensitive," "required by end of day." A verification process that gets skipped whenever something feels urgent isn't a verification process, it's a suggestion that fails precisely when it's needed most.
The Second Breach Is a Different Lesson
The DriveWealth incident is a completely separate failure category: third-party exposure. Revolut's own systems weren't compromised here, a vendor holding a copy of customer data for a specific function, US stock trading, was. Names, phone numbers, addresses, employment and citizenship data, out through someone else's infrastructure.
This is the part of the security conversation that gets less attention than it deserves, because it's less dramatic. Every vendor integration you add is a copy of your customers' data sitting in a system you don't control, secured by practices you don't audit as closely as your own, patched on a schedule you don't set. Your data footprint isn't your database. It's your database plus every processor, sub-processor, and API partner that's ever touched a copy of it.
When you integrate a third-party service that touches customer PII, the question isn't just "does this vendor have SOC 2." It's "what's the minimum data this integration actually needs, and can I send less." Data you never share can't leak from someone else's breach.
Why This Is the More Useful Story
A clean technical breach, a leaked credential, an unpatched CVE, a misconfigured S3 bucket, is uncomfortable but at least legible. You know what to fix. Add scanning, rotate the credential, patch the box.
Social engineering against a data request pipeline doesn't have that kind of fix. You can't patch a human being's judgment under deadline pressure with a config change. The fix is process, verification steps that don't bend under urgency, a second set of eyes on anything sensitive, and treating "an official-looking request" as the start of a verification process rather than the end of one.
Revolut's systems weren't breached. A person, following a process that wasn't strict enough, was. That's not a smaller problem than a hacked database. In a lot of ways it's a harder one, because you can't firewall your way past it. You have to actually slow down.
Sources: RTÉ, The Irish Times, Silicon Republic
