Revolut: when an official address becomes a Trojan horse

In September 2026, Revolut told affected customers that an unauthorised third party had obtained their data through fraudulent information requests. The messages had nevertheless come from an email domain belonging to a government agency. That is what makes the case worth studying: the attacker did not have to open a hole in the banking system. They exploited trust in a channel that appeared official.

Revolut says a limited number of customers were affected but has not published a figure. Italian news reports put the number at around 680 and linked the incident to a compromised certified-email mailbox. Those details remain under investigation and have not all been confirmed by the bank. The central fact is established: information was released to a person who was not authorised to receive it.

This was more than one employee clicking a deceptive link. The weakness lay in a decision chain that likely crossed operations, legal, compliance and the team handling government requests. When such a chain confuses the authenticity of an address with the legitimacy of a request, the vulnerability is organisational.

What was exposed

According to the notification sent to affected customers, the data may have included names, dates of birth, postal and email addresses, phone numbers, copies of passports or driving licences, verification selfies, account statements and transaction histories. Revolut said its systems and customer funds were unaffected.

The absence of direct theft does not make the breach harmless. An identity document is sensitive on its own. Combined with an address, a face, banking details and transaction records, it becomes a highly accurate financial profile. It can support identity fraud, a convincing call from a supposed fraud team, or targeted pressure on a customer whose assets are now visible.

The trap of a genuinely official channel

Public information in Italy directed the investigation towards a compromised PEC mailbox. PEC, Italy’s certified-email system, provides evidence of sending and delivery and plays an important role in administrative communication. It does not guarantee that the rightful owner still controls the mailbox, that the person at the keyboard has the authority they claim, or that an attachment is genuine.

Italy’s CERT-AGID makes the distinction explicit: certification covers transmission and delivery; it does not prove that the sender’s mailbox has not been compromised. Just days after the Revolut disclosure, the CERT again warned of malware being sent through hijacked PEC accounts.

The difference is simple. A legitimate domain proves, at most, the immediate technical origin. It proves neither the human identity, the authority to act, the legal basis nor the permitted scope of the requested data.

An official-looking form is not a legal basis

The case also reportedly involved a document presented as a European Investigation Order. Appearance is not enough here either. The EU directive sets out a procedure between competent authorities in the issuing and executing states. Requests for bank information must explain why the data is relevant, identify the accounts or operations concerned and remain subject to the law of the executing state.

The receiving organisation should therefore ask more than whether a document looks official. It must establish which authority issued it, which channel should have carried it, who must recognise or execute it, which legal entity holds the data and whether every requested category is necessary.

A legal review without identity verification lets impersonation through. Identity verification without a scope review can release one hundred files where only one was authorised. The defence must assemble all of the evidence.

Where the process should have stopped

A robust government-request process must not depend on an employee’s instinct. It should make exceptions difficult, visible and reversible.

• Register every request with a case number, relevant legal entity, claimed authority, legal basis, people concerned, requested fields and time period.
• Verify the requester through a second channel that is already known: an official directory, a public switchboard or a registered institutional contact. Never use contact details supplied in the message for this check.
• Have authority and legal basis reviewed by someone who did not prepare the export. For cross-border requests, confirm the prescribed route between authorities and the applicable law.
• Require two-person approval before exporting identity documents, statements or transaction history. Urgency increases the level of control.
• Minimise the export. People, fields and periods that are not explicitly covered stay out, even when they are easy to retrieve.
• Use a secure, time-limited delivery space tied to the case. Email should not become a bulk-export channel.
• Keep an immutable log of the original request, checks, decisions, database queries, generated files, recipient and access expiry.

These measures are not only for banks. A nonprofit, law firm, IT provider or small business may hold identity copies, payroll records, donor lists, backups or health data. An official-looking request may meet fewer controls there while reaching equally useful information.

Why security tools were not enough

Organisations rightly invest in email filtering, multifactor authentication and malware detection. Those controls largely answer whether an account and message are technically plausible. In this case, the account being used was precisely what gave the request credibility.

A business control had to say: even if the transport is authentic, we still do not know whether the person is authorised, the procedure is correct or the volume of data is proportionate. This is why the GDPR requires organisational as well as technical measures. Confidentiality depends on encryption and on procedures that prevent unauthorised disclosure.

A sound process also creates an escalation path. If a requester invokes urgency, threatens sanctions or refuses independent verification, the employee must be able to pause the request without being accused of obstructing an authority. Urgency then becomes a documented risk signal.

After disclosure, blocking is not enough

Revolut said it blocked the address used and notified the agency concerned, law enforcement and regulators. Those are necessary first steps. A complete response must also reconstruct exactly who received what, through which link or file, for how long, and which data was actually accessed.

For affected customers, the risk extends beyond their Revolut password. A caller may already know their address, identity document and some transactions. They should treat unsolicited contact as potentially hostile, use only the app or official contact details already saved, monitor movements and credit applications, and report targeted threats quickly. Changing a password can be useful, but it cannot revoke a passport copy that has already escaped.

The organisation must review earlier requests that followed the same route, preserve evidence, inform people according to their real risk and test the revised process with scenarios in which the attacker uses an authentic but compromised address.

What the Revolut case reveals

Modern cybersecurity does not stop at the boundary of the information system. It is also decided when an authorised person exports data in response to a request that appears legitimate. That is where security engineering, law, compliance and operations must meet.

Revolut did not describe an intrusion into its infrastructure. That makes the case more instructive than a conventional hack. An attacker found a door designed for authorities and presented the signs that the organisation associated with trust.