Revolut has confirmed that sensitive customer information was disclosed to an unauthorized third party after the company received fraudulent information requests that appeared to originate from a legitimate government agency. According to Revolut’s customer notification, the requests came from an unauthorized email account operating directly through the genuine government agency’s email domain and carried valid domain-authentication credentials. Because the communication passed the technical checks ordinarily used to establish that an email genuinely originated from the government organization, Revolut processed the request believing it to be authentic. The company later independently contacted the agency and discovered that the agency had not submitted the request. Revolut then blocked the offending address, alerted the government organization, informed law enforcement and notified relevant data-protection and financial regulators. Revolut says its own systems were not compromised and customer funds were unaffected. 

The distinction between a hacked bank and an abused lawful-data-request process is fundamental. In a conventional breach, attackers might exploit a vulnerability, steal employee credentials, compromise a database or deploy malware inside the organization. None of that was necessary here. The attacker apparently obtained sufficient control over a government email identity to make a fraudulent legal or investigative request appear legitimate. Revolut then became the mechanism through which the information was delivered. From the company’s technical perspective, the message passed authentication. From a security perspective, however, authentication of the sending domain proved only that the email genuinely traversed infrastructure belonging to the government agency. It did not prove that the person behind the mailbox was authorized to make that particular request. That gap between authentic communication infrastructure and authentic authority is the central security failure exposed by this incident.

The data reportedly disclosed makes the incident especially sensitive. Affected records could include names, dates of birth, occupations, postal addresses, email addresses, phone numbers, copies of passports or driver’s licences, verification selfies, account statements, IBAN information, wallet references, withdrawal records and transaction histories, including Bitcoin transactions. Revolut says biometric facial telemetry itself was not involved, but verification images supplied during KYC could have been included. This is an extraordinarily rich dataset because it combines government-issued identity documentation, contact information, financial records and cryptocurrency activity into one profile. A criminal holding that combination does not merely know who someone is. They may know how that person banks, what accounts they use, where they live, what identification documents they possess and potentially how they transact in digital assets.

That makes the exposed information substantially more useful than a conventional email-and-password breach. A copy of a passport or driver’s licence can support impersonation and fraudulent identity verification, while a verification selfie may help attackers build convincing fake onboarding packages. Transaction history adds another layer because it reveals financial behaviour, counterparties, account balances or patterns of cryptocurrency use. When identity records and financial activity are combined, attackers can construct highly credible fraud, extortion or social-engineering scenarios tailored to an individual rather than sending generic phishing messages. SecurityAffairs also notes that independent researcher ZachXBT assessed that the incident may have targeted high-net-worth users, although that remains an external assessment rather than a confirmed statement from Revolut.

The cryptocurrency component deserves particular attention because linking real-world identity to Bitcoin transaction history can create risks beyond ordinary banking fraud. Cryptocurrency addresses are pseudonymous rather than inherently anonymous, and once an address or transaction history is connected to verified identity information, attackers may be able to map holdings, counterparties or activity patterns. For wealthy users, that can create risks involving extortion, targeted phishing, SIM-swapping attempts or even physical security. The value of the data therefore depends not simply on individual fields but on the correlations between them.

The incident demonstrates why email authentication standards such as SPF, DKIM and DMARC cannot be treated as proof that the person sending a message is legitimate. These mechanisms answer important technical questions about whether a message was authorized by a domain and whether it was altered in transit. They are extremely useful for reducing spoofing. But if an attacker compromises or fraudulently controls a legitimate mailbox inside the government domain, those same authentication mechanisms can work perfectly and still authenticate the attacker’s message. The email is technically authentic. The authority behind it is fraudulent.

This is the same fundamental security problem seen with compromised corporate email accounts in business email compromise. Once attackers operate through a genuine mailbox, many anti-phishing indicators disappear. The sender domain is correct, SPF succeeds, DKIM validates and the message may originate from expected infrastructure. Security therefore needs to move beyond “did this email come from the right domain?” toward “is this request authorized, expected and independently verifiable?”

For legal and law-enforcement data requests, that standard should be considerably higher because the information being released may be exceptionally sensitive. An official-looking email should not be sufficient authorization to disclose complete KYC packages. Organizations should verify high-risk requests through an independent communication path, particularly when the request seeks identity documents, financial history or large volumes of customer information. That might involve contacting the government agency through a previously verified telephone number, portal or official directory rather than replying to contact information supplied inside the suspicious request itself.

Revolut’s experience illustrates why this is effectively out-of-band verification for legal process. The concept is familiar in financial fraud prevention: if an executive emails asking for an unusual multimillion-dollar wire transfer, a finance team may call the executive independently before releasing the money. The same principle should apply when an external authority requests a customer’s entire identity and transaction history. The more sensitive the requested information, the stronger the secondary verification should become.

A dedicated government-request portal with strong mutual authentication could improve this model substantially. Revolut currently publishes a dedicated address for competent authorities and legal representatives to submit official court orders and information requests. Email is convenient and universally available, but convenience is exactly what makes it a weak foundation for highly sensitive disclosure. Financial institutions could increasingly require government agencies to authenticate to secure portals using registered organizational identities, digital certificates or cryptographically signed requests, with the requesting officer tied to a previously enrolled agency account.

Cryptographic document signing could also provide stronger assurance than authenticated email alone. A government request could be digitally signed by an agency certificate and linked to an identifiable officer and case reference. The receiving institution could verify not merely the sending domain but whether the request itself was signed using a valid credential authorized for that agency. Even that system would need revocation and compromise handling, but it would provide a stronger authorization signal than possession of a mailbox.

The incident also raises an important question about account-level versus domain-level trust. An organization may maintain a list of government domains considered authoritative, but not every mailbox inside those domains should automatically be trusted to request customer information. Government agencies contain thousands of users across many roles. A compromised employee email account should not automatically inherit the authority of the entire institution. Institutions processing lawful requests should maintain approved requestor identities or agency units wherever feasible rather than trusting every sender under a recognized domain.

Behavioural analysis could provide another useful layer. If one government mailbox suddenly begins requesting unusually detailed KYC records for high-value individuals, cryptocurrency users or multiple unrelated customers, the pattern may deserve escalation even if every message is technically authenticated. Request volume, target profiles, unusual legal bases, geographic mismatch and departure from historical requesting patterns can all help detect abuse.

Data minimization should also apply to government requests. If an authority asks for information related to one specific transaction, the institution should consider whether providing an entire KYC file, full historical account statement and unrelated identity material is legally required. Compliance teams understandably err on the side of satisfying legitimate government requests, but the principle of proportionality matters because every additional field disclosed becomes additional damage if the requester is fraudulent.

This is especially important because KYC systems deliberately concentrate some of the most sensitive information a financial institution possesses. Regulations require fintech companies to collect government IDs, proof of identity, facial verification material and transaction information precisely so they can prevent money laundering and fraud. Ironically, that regulatory concentration creates an extraordinarily valuable package if the disclosure mechanism itself is abused. The same data collected to establish trust becomes useful to criminals for impersonating that trust elsewhere.

The incident should therefore prompt regulated organizations to threat-model the lawful-disclosure process with the same seriousness as customer authentication. Banks and fintech companies invest enormous resources into detecting suspicious customer logins, device changes and fraudulent payments, yet legal-request processing may still depend heavily on trained staff evaluating emails and attached documents. Attackers will naturally migrate toward whichever process has the weakest verification relative to the value it can unlock.

Government agencies also share responsibility because a legitimate official email account or domain infrastructure appears to have been misused. Revolut has not identified the government agency involved or the country concerned. Without further details it is not possible to determine whether the attacker compromised an existing mailbox, obtained unauthorized access through some other mechanism or created a rogue account inside that agency’s environment. What is clear is that financial institutions cannot solve this class of attack entirely on their own if government identity systems themselves can be compromised.

Government agencies need strong MFA, phishing-resistant authentication, conditional access and monitoring around accounts authorized to submit information requests. They should also maintain clear processes for rapidly notifying financial institutions when a mailbox has been compromised. Ideally, participating agencies and financial firms should have machine-readable revocation mechanisms so a compromised authority credential can be invalidated immediately across institutions rather than relying on individual phone calls and emails.

There is also an information-sharing argument here. SecurityAffairs notes that Revolut has not publicly named the government agency involved. There may be legitimate investigative or legal reasons for withholding that information publicly, but relevant banks and fintech platforms should ideally receive the indicator through trusted financial-sector intelligence-sharing channels. If the same mailbox or agency identity was used to submit fraudulent requests to multiple institutions, rapid sharing could prevent additional disclosures.

This incident also shows why organizations need detailed audit logs around every legal request they fulfill. Records should capture the sender identity, source infrastructure, authentication results, legal authority cited, customer records requested, exact information disclosed, reviewer approvals and any secondary verification performed. If a government identity is later found compromised, the institution should be able to search historical disclosures quickly and identify every request associated with that account.

Human review remains important, but high-risk requests should probably require dual approval. A second compliance officer independently verifying the legal basis and requestor identity creates friction, but when the requested package contains passports, selfies and complete financial histories, some friction is rather cheaper than sending the entire KYC folder to a criminal. Automated systems can flag high-risk requests while humans determine whether the disclosure is justified.

The fact that Revolut later detected the issue by independently contacting the government agency is itself instructive. The verification mechanism that discovered the fraud after disclosure would have been substantially more valuable if it had occurred before disclosure. Organizations should therefore examine whether that same callback or independent confirmation can be incorporated into the standard workflow for particularly sensitive requests.

At the same time, the incident should not be framed as evidence that Revolut’s core banking infrastructure was compromised. Reuters reports that Revolut says its systems and customer funds were unaffected. There is no public evidence that attackers broke into Revolut’s databases, accessed customer accounts or stole funds directly. The breach was one of unauthorized disclosure through a trusted compliance channel. That makes it different technically, but not necessarily less significant for the customers whose KYC records were handed over.

For affected customers, changing passwords alone would not meaningfully address much of the risk because the exposed information consists largely of persistent identity attributes. A passport or driver’s licence can sometimes be replaced, but a date of birth, historical financial activity or facial image cannot simply be rotated. Customers should therefore be particularly cautious of targeted communications that demonstrate detailed knowledge of their Revolut account, identity documents or cryptocurrency transactions. A scammer quoting accurate account information should not automatically be assumed to represent Revolut, law enforcement or another financial institution.

Financial institutions that know their customers were affected should also consider enhanced monitoring for account recovery attempts and identity-verification activity. Attackers holding genuine KYC material may attempt to open accounts elsewhere, reset existing accounts or bypass manual verification processes. Fraud-detection models need to recognize that possession of a correct identity document image is increasingly weak evidence that the presenter is actually the legitimate person.

The wider industry lesson is that authentication and authorization need to remain separate concepts even for governments. The email genuinely came through a government domain, but the request was not genuinely authorized. That distinction is almost identical to the problem enterprises face when a legitimate employee account is compromised. The identity system says the account is real; security still needs to determine whether the action is legitimate.

The broader lesson from the Revolut incident is therefore that attackers increasingly target trust relationships rather than systems directly. They did not need to exploit Revolut’s servers, bypass its customer authentication or defeat its encryption. They used an identity belonging to an organization Revolut was expected to trust and asked for the data through a process designed to provide it.

That is a much harder problem than blocking malware because the workflow itself is legitimate. Government agencies genuinely need information from financial institutions. Financial institutions are legally required to respond. Email authentication genuinely helps verify the source. Yet none of those truths establishes that every authenticated request is authorized. The security model therefore needs one additional question before sensitive data leaves the organization: not merely “Did this come from the government?” but “Have we independently established that the government actually asked for it?” Because in this case the email passed the security checks. The request passed the compliance workflow. And the data went exactly where the process told it to go. Unfortunately, so did the attacker.

Revolut handed over KYC docs, selfies, and BTC transaction histories after a fake gov email with valid domain credentials passed its checks.

Source: Revolut Exposed KYC Data After Fraudulent Government Email Passed Security Checks via securityaffairs.com.