A request for customer records arrives from a government email domain. It appears to belong to the kind of organisation your team routinely cooperates with. Before anyone releases information, there is a crucial question: what evidence confirms that this person is authorised to receive it?
Revolut’s recently reported data breach brings that question into focus. For compliance and operations teams, it is an opportunity to examine how an incoming request becomes an approved disclosure.
What has been reported
On 12 September 2026, Reuters reported that Revolut had confirmed disclosing sensitive customer information to an unauthorised third party after receiving fraudulent requests from a legitimate government agency email domain. The date is the public confirmation date; it does not establish when the disclosures occurred. Reuters reporting.
A spokesperson told The Block that Revolut had blocked the address, contacted affected customers and alerted relevant authorities. The company said its systems and customer funds were unaffected. The report described potentially exposed information including identity documents, contact details, account statements and transaction histories. Revolut had not disclosed the customer count or identified the agency in that reporting. The Block’s report and company response.
Those accounts describe an impersonation incident involving the disclosure process. They do not establish every internal check performed, the full technical mechanism or a regulatory finding against Revolut. Any assessment of particular control failures needs to respect those limits.
Why the request channel matters
In a LinkedIn post responding to the case, Dr. Shlomit Wagman framed it as a wake-up call, arguing that, in 2026, sensitive customer information should not be exchanged with law enforcement by email. She said police and other law enforcement agencies should provide secure, authenticated portals with audit trails for these exchanges, and that AML vendors should build secure law enforcement communication channels into their own infrastructure. Her broader point was that the risks extend beyond impersonation to misdirection, unauthorised access and human error. Wagman’s original post.
There is an established threat behind this concern. In November 2024, the FBI warned that criminals were using compromised government email accounts to submit fraudulent emergency data requests. It also warned that attackers exploit urgency to shorten scrutiny. That warning describes a broader attack pattern; it does not establish that Revolut received an emergency request. FBI industry notification, 4 November 2024.
Our operational conclusion is that a familiar domain cannot, by itself, establish the legitimacy of an individual request. Teams need a way to verify the requester’s identity, authority and requested scope before information is released.
A portal can help organise that process. Its effectiveness still depends on how users are enrolled, how access is authenticated and reviewed, and how each disclosure is authorised. Moving a weak verification process into a new interface leaves the underlying question unanswered.
What the UK guidance actually says
The ICO explains that sharing personal data with law enforcement can be lawful where it is necessary and proportionate. Organisations need an appropriate lawful basis, with additional conditions where applicable for special category or criminal offence data. Its guidance distinguishes voluntary sharing from disclosures compelled by a court order or another legal obligation. An incoming request therefore needs assessment in its own circumstances. ICO guidance on sharing with law enforcement.
It would also be misleading to describe every use of email as automatically unlawful. The ICO discusses encrypted email and encrypted attachments as possible security measures. The relevant assessment is whether the safeguards are appropriate to the information and the risks. Encryption protects information in particular ways; it does not establish that the recipient is entitled to receive it. ICO encryption scenarios, ICO encryption and data protection guidance.
Wagman also raises Suspicious Activity Report (SAR) confidentiality. The incident reporting cited here does not establish that SARs were disclosed. For UK reporting, the NCA directs organisations to submit SARs through its SAR Portal. That reporting process should be kept distinct from responding to incoming requests for customer records. NCA guidance on Suspicious Activity Reports.
Six questions to test your disclosure process
The following are suggested operational checks, rather than findings about Revolut or a universal legal checklist. A useful exercise is to take one recent request and see whether your team can answer them from the retained record.
| Question | What the record should help you establish |
|---|---|
| Who was requesting the information? | How the person and agency were independently verified, using an established contact route rather than relying solely on details in the request. |
| What supported the disclosure? | The purpose, relevant authority and documented decision on the legal basis for sharing. |
| What information was approved? | The customer, records and date range covered, with unnecessary information excluded. |
| Who authorised release? | The responsible decision-maker and any additional review required by the organisation’s policy. |
| Where did the information go? | The verified destination, approved transfer method and access restrictions. |
| Can the decision be reconstructed? | The request, verification steps, approval, information released and transfer evidence, retained under appropriate access and retention controls. |
The ICO’s checklist supports documenting the lawful basis and sharing only the minimum necessary relevant information. The FBI recommends scrutinising questionable requests and contacting the originating authority when validation is needed. The table turns those principles into a practical review exercise. ICO disclosure checklist, FBI recommendations.
Teams also need a workable route for genuine urgency. A named escalation contact, clear decision rights and a documented exception process can help staff respond quickly while preserving accountability. An urgent label should lead to that process, rather than an improvised decision in an inbox.
Where communication governance fits
An incident like this may also require updates to customer notices, support responses and other approved communications. As facts develop, teams need to know which wording was reviewed, which version was approved and which version was used.
CommsPliant is a working platform for managing customer emails, PDFs and letters through versioned templates, review and approval workflows, API rendering and audit records. It helps teams preserve the connection between approved wording and its use. How CommsPliant works.
Verifying a law enforcement requester, deciding whether a disclosure is lawful and selecting a secure transfer route remain separate responsibilities within the organisation’s wider controls. Approval of a communication template does not authorise the release of customer data.
For a disclosure process, the evidence needs to explain the decision before the information left the organisation. For customer communications, it needs to show how the message was governed. Both deserve deliberate design and a record that can withstand scrutiny.