Revolut handed over documents and financial records after a fake government request. Here's how an authentic email can carry a fraud, and why protecting the balance isn't enough to protect privacy.

Revolut handed customers' personal information to someone who presented themselves as a government authority. The request was fake, but the address used belonged to an official domain. The company acknowledged the episode to the press in September 2026. Among the data potentially disclosed were identity documents and transaction histories.

What bothers me in this case is the distance between two promises we usually treat as if they were the same thing: protecting my money and protecting my private life. An account can keep working, with no balance stolen, while information that identifies its owner is already in someone else's hands.

I've seen this news going around the IndieWeb. It makes sense that it catches the attention of people who care about digital autonomy, but outrage doesn't excuse us from being careful with the facts. There's no confirmation that data was sold, that all customers were exposed or that Revolut's systems were breached. The known episode is an improper disclosure through a process that was supposed to handle legitimate requests.

What happened and what we still don't know

Notices sent to customers started circulating publicly in September. The investigator ZachXBT shared the case on his channel, pointing to a post by Mark Karpelès, who identified himself as affected. On September 12, International Cyber Digest pulled together the information that prompted this piece.

According to the shared notice, the request came from an unauthorized account within the infrastructure of a legitimate government domain. The message carried valid authentication credentials for the domain. Revolut fulfilled the request and later confirmed with the agency that it wasn't legitimate.

A spokesperson confirmed to The Block that a third party used an address on a government domain to submit fraudulent requests. The company said it blocked the sender and reported the episode to the agency, the police and regulators. It said a limited number of customers were affected and that its systems and customers' funds were not compromised.

That last assurance is Revolut's own statement, with no independent audit published.

As of my check on September 14, 2026, the sources I looked at didn't name the agency, the exact number of customers or the date the files were sent. They also didn't explain how the third party managed to use that account. These are relevant gaps: without that information, we can't fully assess how long the exposure lasted, how far it went or whether other institutions received similar requests.

ZachXBT suggested the attack seemed aimed at high-net-worth users, which the company hasn't confirmed. Nor is there any basis, in these reports, to claim that every customer who bought Bitcoin through Revolut was hit.

Why a legitimate email can carry a fraud

An authenticated email doesn't prove the authority of whoever is asking for the data. External artwork by Gerrit Halfmann, Pixelarticons, MIT license.

When we think of phishing, we picture a domain that looks like the real one, a swapped letter or a clearly odd sender. Here, the problem described is different: the message used an authority's real domain.

That helps explain how a message can pass technical checks and still be dangerous. Email authentication tries to answer questions about the sending and the domain. It doesn't decide whether the person who hit the button was authorized to ask for my passport.

SPF checks whether a server is authorized to send messages for a given domain used in the email's transport. DKIM lets you verify a signature tied to a domain and the integrity of the signed parts. DMARC uses the alignment between the sender's visible domain and the SPF or DKIM results to apply the policy published by the domain. They're useful mechanisms against forged senders, but they don't replace validating a request.

RFC 9989, published in May 2026, makes this limit clear: authenticating the use of a domain doesn't authenticate the local part of the address, nor does it guarantee the quality or legitimacy of the content. In the Revolut case, the notices mention valid domain authentication, but they don't publish the message headers. So we can't say that SPF, DKIM and DMARC each passed individually.

A simple comparison: recognizing that a call came from a government office's phone doesn't prove that the person speaking can request a citizen's documents. You still need to check who is asking, the purpose and the authorization for that specific request.

I would expect information this sensitive to require that second check before being sent. The public account shows the fraud was discovered afterwards; it doesn't give enough detail to reconstruct each internal control or to say exactly which person failed.

What the files can reveal

Documents and contact records can make impersonation attempts easier. External artwork by Gerrit Halfmann, Pixelarticons, MIT license.

The published notice lists identification and contact data, such as name, date of birth, occupation, address, phone and email. It also mentions copies of documents, the verification selfie and financial records: statements, IBAN, account information, withdrawals and transaction history, including Bitcoin. These are categories that were potentially shared, and not necessarily all of them for every customer.

Each category is useful to a criminal in a different way. An address lets you locate someone. A statement helps build a convincing approach. A copy of a document can be used in impersonation attempts. Put together, this information gives context for scams that seem to know the victim's life.

Imagine getting a message that mentions a real transfer, your full name and the last digits of a document. It can look like a legitimate continuation of a support conversation. The true detail works as an argument for trust, even when the next request is fraudulent.

That's a plausible risk, and there's no confirmation of a scam like that in this episode.

There's also a distinction to make about the selfie. The notice excludes facial biometric telemetry, but it includes the verification image among the data potentially sent. A photo of a face and a biometric template derived from it are different things. Leaving out the second doesn't make the first irrelevant.

Under the definition explained by the UK regulator, the ICO, a personal data breach can also involve unauthorized disclosure or access. Nobody needs to have installed malware or broken into a database. Information sent to the wrong recipient already deserves an investigation and an impact assessment.

The Bitcoin history

Bitcoin doesn't offer automatic anonymity. Transactions recorded on the blockchain are public, and addresses don't, on their own, carry the legal names of their users. Privacy depends in part on how hard it is to make those connections.

A financial service can know the person behind operations that, seen in isolation on the network, show up as movements between addresses. When internal records tie an identity to withdrawals or transfers, they can help connect financial activity to an identifiable person.

How far that connection goes depends on what was actually disclosed. Not every operation made inside an app corresponds to an individual transaction on the blockchain, and an account record doesn't automatically reveal every wallet its owner has.

Even so, the combination deserves attention. Knowing who someone is, where they live and what transactions they made can be more dangerous than knowing just one of those things. The sources I consulted don't confirm any violence or extortion resulting from this case.

Collecting documents also creates a duty of care

KYC stands for Know Your Customer, the term used for customer identification procedures. Financial institutions must comply with anti-money laundering requirements and other regulatory duties. Revolut itself explains that it may request documents to verify people and transactions.

That explains the collection, but nothing justifies handing it over to an impostor.

I have a hard time with the idea that piling up more information is, in itself, the same as security. For the customer, handing over documents can be a condition for using the service. For the institution, every copy it keeps increases the material that has to be protected and controlled, including in the administrative disclosure processes.

The obligation to identify customers is compatible with demanding limits on collection, restricted access, justified retention and rigorous verification of recipients. The stated purpose doesn't remove the risks of storage.

Nor can we assume that closing the account immediately erases that archive. On its UK support page, Revolut says certain data must be kept for at least six years and may remain longer for legal reasons. Deadlines and rules vary by entity and jurisdiction. Anyone who wants to leave needs to check the policy that applies to their own account.

The right to request deletion doesn't mean every piece of data will have to be erased without exception either. A concrete request can ask which categories remain, for how long and on what grounds.

The fraud didn't start with Revolut

In November 2024, the FBI warned about compromised government emails being used to submit fake emergency data requests to companies. This kind of request tries to exploit procedures meant for urgent situations.

That precedent shows the risk of relying on the institutional look of a sender, though the public sources I examined don't say whether the request to Revolut was an emergency one.

The FBI's general guidance on email fraud includes verifying requests through an independent channel. Applied to personal data, the recommendation makes sense: confirm the authority through a contact known beforehand, instead of using the phone number or link provided in the suspicious message itself.

Other precautions would be limiting the data to the proven purpose and recording who authorized the disclosure. Besides checking that the email came from a real domain, an institution has to ask whether that person can receive those files in that situation.

What this has to do with the IndieWeb

The IndieWeb starts from the wish to have more control over your own digital presence. Keeping your own site, publishing outside closed platforms and reducing dependencies doesn't solve every privacy problem, but it makes some decisions less dependent on companies.

I see a direct link with the discomfort this case causes. We can choose what we publish on a blog and still depend on third parties to keep documents, transactions and personal information we don't want to make public. Having your own domain doesn't give you control over a bank's data disclosure process.

Control varies with context, and there are relationships in which the user can't simply host their own alternative. That's why reducing unnecessary data and holding institutions accountable is still important, even for those who have already left the big social networks.

I also prefer that independent news circulation keeps the difference between evidence and opinion. An outraged post can point to a real failure and exaggerate its extent in the same sentence. Sharing the source, checking the company's later response and correcting an inaccurate headline are all part of taking care with information.

How to act without falling for a second scam

Protecting the account and protecting personal data take different kinds of care. External artwork by Gerrit Halfmann, Pixelarticons, MIT license.

Anyone who received a notice should first confirm it's authentic through the app or an official channel accessed directly. News of an exposure creates an opening for fake support messages, promises to remove data and requests for a new verification.

It's worth keeping the notice and asking for clarification about your own situation: which data was disclosed, when it was sent and which protective measures are available. Contacting the data protection officer can help formalize those questions. Revolut publishes the address dpo@revolut.com on its privacy pages.

Strengthening the protection of your account and email is still prudent. But changing a password doesn't take back a document that has already been sent.

I'd pay special attention to messages that show they know real transactions and then ask for codes, remote access or transfers to a supposedly safe account. Not sending new copies of documents through improvised contacts is an important precaution. If there's a fraud attempt or a threat, keep the evidence and go to the official channels for your country.

Anyone who didn't get a notification shouldn't conclude, from the news alone, that their data was sent. They don't have to accept vague reassurances either. They can follow the updates and ask for individual information through the institution's channels.

Security has to include where the data goes

The money still being in the account matters. For me, though, that doesn't settle the question of privacy. I also want to know who received my documents and what was done to prevent an improper disclosure.

The Revolut case exposes a problem of trust in requests that look official. Authentication systems help verify domains; decisions about authority, purpose and access need other controls. Until the investigation clears up the details, that's the conclusion the public reports support.

An institution that requires knowing its customer needs to be just as careful when deciding who gets to know that customer's data.