Revolut stopped sending customer data to this provider up to 33 months ago. The records were still there

The relationship ended. The data did not

DriveWealth, a United States brokerage that provided the plumbing for Revolut customers trading American shares, says unauthorised access to its network took place on 4 and 5 September 2026, which it attributes to a social engineering campaign by unknown third parties.

Revolut moved its customers in the United Kingdom, the European Economic Area and Australia away from that arrangement between December 2023 and June 2025, depending on the market. After those changes it stopped sending individual customer details in those regions to DriveWealth.

It stopped sending them. The ones already sent stayed.

So a customer whose data left Revolut for DriveWealth before December 2023 was exposed in an incident 33 months after the flow stopped for the earliest market, and 15 months after it stopped for the latest. In between, nothing about that person's relationship with either company generated a single new record, and the old ones were still there to be taken.

What that does not establish. It does not establish that either company broke a retention rule, because neither has published how long it intended to keep the records or on what legal basis, and brokerages carry genuine statutory retention obligations that can run for years. It does not establish that anyone has been defrauded. It does not establish the number of people affected, which has not been published. And it does not establish that Revolut could have compelled deletion: that depends on the contract, and nobody outside has seen it.

The fields that cannot be rotated

Look at what was taken, and at what was not.

Taken: name, email address, phone number, postal address, employment information, country of citizenship, age, gender, and partial DriveWealth account numbers.

Not taken, according to DriveWealth: passwords, payment card numbers, bank account details, Revolut passcodes and identity documents.

The second list is the one that produces reassurance, and it is genuinely better news than the alternative. But notice the asymmetry in what the two lists are worth over time.

Every item on the second list can be replaced. A password is changed in seconds. A card is reissued within days. A passcode is reset. That is the entire design intent of a credential: it is a secret chosen to be disposable.

Nothing on the first list can be replaced. You cannot rotate your date of birth, your citizenship, your employment history or the street you live on. A postal address can be changed only by moving house. The data that was taken is precisely the data that stays true, and it stays true for the rest of the affected person's life.

The two categories in the DriveWealth notification, and what a person can do about each. Field lists are as published.

Category	Examples	What the affected person can do
Taken	Name, address, phone, employment, citizenship, age, gender	Nothing. None of it can be changed or reissued
Not taken	Passwords, card numbers, bank details, passcodes, identity documents	Rotate them, which is why their loss is recoverable

What the law asks, and what it does not

UK data protection law contains a principle usually given least attention of the six: storage limitation. Personal data must be kept in an identifiable form no longer than is necessary for the purposes it was processed for. It is a duty, and it is also the only control that would have made any difference to this incident.

That is the uncomfortable part for anyone who has run a supplier offboarding. The standard exit checklist covers access revocation, credential rotation, connection teardown, certificate removal and the final invoice. Deletion of the data already transferred appears on most of those checklists as a line, and is one of the hardest to actually evidence, because it happens inside somebody else's systems and the only proof is their word.

And the necessity test genuinely cuts both ways here. A regulated brokerage may be required to retain transaction records for a defined period regardless of whether the client relationship continues, which is a lawful reason to hold data that has nothing to do with the customer's current arrangements. That is a real answer, and it is not the same as never having asked the question.

There is a second structural point in this incident that is easy to miss. Both of the Revolut customer data incidents reported this month arrived through third parties rather than through Revolut's own systems.

That is not unusual and it is not a defence. Under data protection law the controller remains responsible for the processors it chooses, which means the security work that matters most for a business like this is increasingly not about its own perimeter at all. It is about who else holds the data, what they hold, and whether anybody has checked recently.

What to do about it

The question this leaves

There is a habit in breach coverage of reading the excluded list as the story: no passwords, no card numbers, so not serious. That reading gets it backwards. The excluded items are the ones the affected person can do something about. The included items are the ones they will carry for life.

And the structure of the incident is the part worth carrying into your own work. Nobody at Revolut sent this data anywhere in the last fifteen months, and for some markets the last thirty three. The exposure had nothing to do with current arrangements, current controls or current suppliers. It was a consequence of a relationship that had already been ended properly, with the one step that is hardest to verify left in somebody else's hands.

So the question for your own supplier list: for every processor you stopped using in the past three years, can you say today what happened to the data you sent them, and would you be able to show it?