A legitimate-looking sender domain does not prove that a sensitive data request is legitimate. Revolut told Reuters that it disclosed sensitive customer information to an unauthorized third party after receiving fraudulent requests from an email address on a legitimate government-agency domain. Revolut said it blocked the address after detection, notified the relevant agency and authorities, and that its systems and customer funds were unaffected.
This was a disclosure-process failure, not evidence that attackers accessed every Revolut account or moved customer funds. The company has not publicly named the impersonated agency, given an affected-customer count, or described the complete verification workflow. The useful lesson for any organization handling identity records, account data or incident material is narrower: an external request needs its own authentication and approval path before any data leaves the organization.
What is confirmed—and what is not
Reuters reported the company's confirmation that a fraudulent request sent from a legitimate government domain resulted in disclosure to an unauthorized third party. The Block separately reported direct comment from Revolut describing a sophisticated external impersonation scam and saying that only a limited number of customers were affected. Both reports say Revolut did not disclose the exact number or identify the agency.
Public reporting lists sensitive identity, contact and financial-information categories from customer notifications. It does not establish the exact data set for every affected person, whether the disclosed information was later misused, how the mailbox became unauthorized, or whether any other organization received a request from it. Those unknowns matter: do not turn a reported data category into a claim about every customer or a claim that a particular fraud followed.
Separate the request, the authority and the data
A formal-looking email, a recognizable logo and passing email authentication checks can all belong to a compromised or improperly created account. The organization receiving a request should treat sender-domain validation as one signal, not the decision. Design a workflow in which the team that receives a request cannot both validate it and disclose the data without independent review.
- Use a known return channel. Verify the requester through an official directory, established liaison or approved portal—not a telephone number, reply address or link supplied in the request.
- Validate authority and scope separately. Confirm the legal basis, jurisdiction, case reference, required data categories, date range and deadline. An authentic agency domain does not answer all of those questions.
- Require dual control for exceptional disclosures. A legal, privacy or compliance reviewer and a data custodian should independently approve sensitive or unusual requests. Record the decision and evidence without copying the disclosed material into the ticket.
- Disclose the minimum. Return only the records explicitly authorized and necessary for the verified purpose. Avoid attaching an account export or identity-document bundle when a narrower response satisfies the request.
- Use a controlled delivery channel. Prefer the authority's approved secure portal or another organization-approved exchange method. Confirm receipt and preserve an audit trail of the approved disclosure.
Prepare for the moment verification fails
An incident plan should identify who can suspend a pending disclosure, validate the requester through a separate channel, preserve the original request and notify privacy, legal and security teams. Keep recipient contacts, approval rules and secure-delivery instructions in controlled systems; a hurried search through old email threads creates another opportunity for impersonation.
If a possible mistaken disclosure is discovered, first stop further transfers and retain the relevant request and approval evidence. Then establish the exact records sent, recipients, authorization basis and notification duties with the appropriate internal teams. Do not ask affected people to send identity documents, passwords or recovery codes in response to a notification without an independently verified process.
Where a one-time secret link fits—and where it does not
Secretus can reduce persistent plaintext when an authorized team must deliver a small temporary credential, recovery value or approval code through a separately verified channel. It is not a law-enforcement request portal, identity-proofing system, legal authority check, customer-record repository or substitute for an approved case-management process. Do not use a secret-sharing link to bypass a required verification step.
What remains unknown
Revolut has not publicly identified the agency domain, disclosed the number of customers involved, described the full validation process or reported subsequent misuse of the data. The event is a reason to test your disclosure controls, not evidence that every government request, email-authentication check or financial account is unsafe.