Revolut confirmed to Reuters on September 12 that sensitive customer information was disclosed to an unauthorized third party after the company received fraudulent requests sent from a legitimate government agency email domain. Revolut said its systems and customer funds were not affected, but the reported data exposure included high-value identity material such as contact details, dates of birth, and identity-document copies.

This is not just a fintech story. It is a trust-boundary story. Any organization that responds to law-enforcement, regulator, subpoena, public-records, insurance, HR, or customer-support data requests can be targeted through the same basic pattern: make the request look official enough that the workflow does the attacker’s work for them.

What happened

According to Reuters, Revolut said it blocked the address after detecting the issue and notified the relevant government agency, enforcement agencies, data-protection authorities, financial regulators, and affected customers. Reuters also noted that Revolut did not disclose the exact number of individuals affected.

TechCrunch reporting cited by Reuters said the compromised data included customer birth dates, postal and email addresses, phone numbers, and copies of identity documents such as passports and driver’s licenses. Those details matter because they are not disposable like a password. They can support impersonation, synthetic identity fraud, account recovery abuse, and highly tailored phishing.

Why this matters for SMBs and government contractors

Smaller organizations often treat “official-looking” requests as administrative work rather than a security process. A request arrives from a recognizable domain, references a case number, uses urgent language, and asks for customer, employee, vendor, or applicant records. If the recipient only verifies the email header and not the authority behind the request, the organization can disclose sensitive data without a malware infection, exploit, or account takeover.

Government contractors should pay close attention. Contractor environments may handle CUI-adjacent project records, personnel information, subcontractor details, vulnerability reports, facility-access records, and customer documentation. A fraudulent request that looks like it came from an agency, prime contractor, regulator, auditor, or law-enforcement office can become a clean path to sensitive data.

The security failure pattern

  • Trusted domain bias: staff may assume a request is legitimate because the sender domain appears official.
  • Process pressure: legal, support, compliance, and fraud teams are trained to respond quickly to authority-driven requests.
  • Overbroad disclosure: once a request is accepted, too much data may be exported instead of the minimum required subset.
  • Weak independent verification: confirmation may happen inside the same email thread instead of through a known-good phone number, portal, or agency contact.
  • Limited auditability: many organizations cannot easily reconstruct who approved a disclosure, what was sent, and why the request was accepted.

Defensive takeaways

1. Create a dedicated data-request intake path

Do not let sensitive disclosures happen through ordinary inbox handling. Route government, law-enforcement, regulator, subpoena, HR, insurance, and customer-data requests through a controlled intake process with ticketing, identity verification, approval, and logging.

2. Verify authority out-of-band

Official-looking email is not enough. Verify through a known-good agency directory, previously established secure portal, signed request channel, or callback number independently obtained by your team. Do not use contact details supplied in the request itself as the only verification path.

3. Require two-person approval for sensitive exports

Any release involving identity documents, financial records, credentials, customer records, employee records, CUI, contract data, or bulk exports should require approval from at least two roles: one legal/compliance owner and one security/privacy owner.

4. Minimize what gets released

Respond to the validated scope, not the broadest possible interpretation. Redact unnecessary fields, limit date ranges, avoid bulk exports where a narrow record will satisfy the request, and document exactly why each data class was included.

5. Log and monitor the disclosure workflow

Security teams should monitor for unusual export size, unusual requester domains, emergency language, repeated requests for the same subject, new agency contacts, and after-hours approvals. These workflows deserve detection logic just like privileged admin activity.

6. Prepare customer-notification language before you need it

If sensitive identity data is disclosed, speed and clarity matter. Maintain a breach-response template covering what happened, what data was involved, what was not affected, what actions customers should take, and which regulators or agencies were notified.

Bulwark Black assessment

The Revolut incident is a sharp reminder that not every breach starts with malware. Sometimes the attacker targets the business process that is allowed to move sensitive data on purpose.

For SMBs and government contractors, the practical answer is to treat external data requests as a security control surface. Validate the requester independently, require dual approval, disclose the minimum necessary data, and preserve a clear audit trail. The goal is not to slow down legitimate legal or government cooperation. The goal is to make sure the organization is cooperating with the right party.

Original reporting: Reuters via WSAU — Revolut confirms sensitive customer data breach, falling for fake government requests. Additional context: TechCrunch — Revolut confirms data breach after falling for fake government requests.