Last week Revolut confirmed that it disclosed sensitive customer information to an unauthorised third party: identity and contact details, dates of birth, postal and email addresses, phone numbers, copies of passports and driver’s licences, and in some cases verification selfies, account statements and transaction histories. Reporting indicates the targeting was deliberate, aimed at high net worth individuals, many of them involved in crypto asset businesses.
No system was breached. No malware was deployed. No password was stolen. The requests arrived from a genuine government agency domain and carried valid email authentication — SPF, DKIM and DMARC all passed — and the team processed them as authentic. Revolut says that on detecting the fraud it blocked the sender and alerted the agency, law enforcement and the relevant regulators, and that its systems and customer funds were unaffected.
Every technical control worked exactly as designed. Authentication confirmed the domain, and the domain was genuine. The request was not.
That is the part worth sitting with. Authentication answered the question it was built to answer, and the answer was correct. It was simply the wrong question.
Every reporting entity in Canada should read this as a procedural failure rather than a technology failure, because the fix is procedural and it is available to you immediately.
Why this is the harder kind of incident
A conventional breach gives you something to patch. This one does not. The control that failed is the judgement of a person in an operations or compliance seat, working from an inbox, under the natural pressure that comes with an email that appears to come from the state.
Three features make it dangerous for Canadian money services businesses, payment service providers and fintechs in particular.
- Domain authentication proves origin, not authority. SPF, DKIM and DMARC confirm that a message really came from the domain it claims. They say nothing about whether the sender is authorised to make the request, or whether the request has any legal basis at all.
- The data at stake is the most valuable data you hold. A complete KYC file plus transaction history plus wallet addresses is an identity theft kit, an extortion package and a targeting list for physical crime. For customers holding digital assets, this information is often worth more to a criminal than the assets themselves.
- Smaller firms are softer targets. Revolut is a large, well-resourced firm with dedicated legal and compliance functions, and it still released the data. A twelve person MSB with no written procedure and a shared compliance inbox has no realistic chance unless the process is designed in advance.
A request is not a production order
The most important distinction, and the one most often collapsed in practice, is between a request and a compulsion. They are governed by different law and they deserve different responses.
A production order compels you
Under section 487.014 of the Criminal Code, a justice or judge may order a person to produce documents or data in their possession or control, on an ex parte application. Section 487.018 is the provision that matters most to our clients: it allows a judge to order a financial institution, or any person or entity referred to in section 5 of the PCMLTFA, which includes money services businesses, to prepare and produce specified financial data. Following amendments extending it to digital assets, that provision now expressly reaches the name and account number of a person whose identifier associated with digital assets is specified in the order.
Note the thresholds, because they are not the same. The general production order under section 487.014 requires reasonable grounds to believe. The financial-data order under section 487.018 requires only reasonable grounds to suspect. The order most likely to land on a reporting entity is the one issued on the lower standard.
A production order names the officer, specifies the documents and the time and form of production, and can carry conditions, including conditions protecting solicitor-client communications. It may also be accompanied by a non-disclosure order under section 487.0191 prohibiting you from revealing that the order exists.
A bare request does not compel you
Where there is no order, the governing law is PIPEDA. Section 7(3)(c) permits disclosure without consent where it is required to comply with a subpoena, warrant or court order. Section 7(3)(c.1)(ii) permits disclosure to a government institution that has made a request, identified its lawful authority to obtain the information, and indicated that the disclosure is sought to enforce a law, carry out an investigation or gather intelligence.
In R. v. Spencer, 2014 SCC 43, the Supreme Court of Canada held that a bare police request is not lawful authority for these purposes. Police may ask, but where a reasonable expectation of privacy exists they have no power to compel compliance with a simple request. The Court was explicit that neither PIPEDA nor section 487.014 creates a police search power.
Two consequences follow, and both belong in your procedure. First, PIPEDA is permissive, not mandatory. Nothing in section 7(3) obliges you to respond to a voluntary request, and section 487.0195 of the Criminal Code confirms only that an officer may ask. Second, if you are wrong about the legal basis, you have made an unauthorised disclosure of personal information.
One nuance worth knowing, and not relying on
Section 487.0195(2) provides that a person who voluntarily preserves data or provides a document to an officer does not incur criminal or civil liability for doing so — but only where they are “not prohibited by law” from doing it. That qualification is doing considerable work. It does not license disclosure that PIPEDA does not permit, and it is not a defence to a privacy complaint where there was no lawful authority to begin with. Treat it as a narrow shield for good-faith cooperation, not as a reason to skip the legal-basis question.
Foreign agencies have no direct reach into Canada
A foreign police force or regulator cannot compel a Canadian entity directly. Cross-border demands are properly routed through the Mutual Legal Assistance in Criminal Matters Act, or through a Canadian agency acting on the foreign request. An emailed demand from a foreign government domain, however convincing the letterhead, carries no compulsion in Canada.
Where FINTRAC does, and does not, speak
There is no FINTRAC guidance telling reporting entities how to receive, authenticate and respond to law enforcement requests. That gap is real, and it is not an excuse. Two obligations still bite.
Your compliance program must cover it. Section 9.6 of the PCMLTFA and the associated Regulations require documented policies and procedures, kept current and approved by a senior officer, covering how you meet your obligations and protect the records you are required to keep. A process that determines who may release five years of client identification and transaction records to an outside party sits squarely inside that requirement. FINTRAC does not need to name the scenario for an examiner to test whether you controlled it.
A production order is a suspicion trigger. FINTRAC’s guidance on reporting suspicious transactions is explicit: where you receive a production order from law enforcement related to a predicate offence, you must assess the facts, context and money laundering or terrorist activity financing indicators to determine whether you have reasonable grounds to suspect. Receiving the order does not by itself create reasonable grounds, but it obliges you to look. Many firms treat production orders as a legal task and never route them back to the analysis team. That is a reporting failure waiting to be found on examination.
One further point is easily missed. An attempted fraudulent request is itself intelligence. Someone is building a file on your customers. Consider whether the circumstances support a suspicious transaction report, and consider what the targeting tells you about the risk profile of the named clients.
Ten controls that would have prevented this
The following is what a defensible law enforcement response procedure looks like. It is deliberately mechanical. Under pressure, people follow steps, not principles.
- Write the procedure, and separate the categories. One document, four distinct paths: court-ordered production and warrants; voluntary requests for information; regulatory requests from FINTRAC, the Bank of Canada or a provincial regulator; and requests from foreign authorities. Each has a different legal basis and a different answer. Collapsing them is how firms end up treating an email like a court order.
- Route everything to one place and one owner. A single monitored channel, with the Compliance Officer or a named delegate as the only person authorised to release client data. Front line staff receive, log and escalate. They never respond, never confirm whether a person is a client, and never acknowledge the substance of the request.
- Authenticate out of band, before anything moves. Never reply through the channel the request arrived on, and never use the contact details contained in the request. Find the agency through its published website, call the general line, and ask to be connected to the officer and the file. Confirm identity, badge or employee number, file number and scope. Document who you spoke to and when.
- Establish the legal basis before you discuss scope. For anything beyond information carrying no reasonable expectation of privacy, the default response to a request without an order is to ask for a production order. This is not obstruction. It is the position the Supreme Court has effectively required of you, and legitimate investigators deal with it every day.
- Get legal review, and keep it in the loop. Counsel validates the order, checks jurisdiction and service, screens for privilege, and advises where the order is overbroad or ambiguous. Build the relationship before you need it, not on the morning a fourteen day production deadline lands.
- Produce what is compelled. Nothing beyond it. If the order specifies a period, produce that period. If an item is not named, do not assume it is wanted and do not supply it. Where a statement, email thread or file inevitably carries data outside the scope, or data belonging to another client, redact before production and keep the unredacted original. Where the order is genuinely overbroad or captures privileged material, go back to the issuing officer or apply to the court to vary it. Over-production is the failure mode that turns a lawful disclosure into a privacy breach.
- Deliver securely, and split the keys. Use a secure file transfer portal with expiry and download logging. Send the credential through a different channel from the link, ideally by telephone to the verified officer. Encrypt the package. Watermark where you can. An intercepted email should never be enough on its own to open the data.
- Keep a register. Date received, channel, requesting agency and officer, verification steps and who performed them, legal basis, scope requested, scope produced, redactions applied, approver, delivery method, date produced. This register is the first thing an independent reviewer should ask for, and the first thing that protects the firm if a disclosure is later challenged.
- Respect the confidentiality rules in both directions. Where a non-disclosure order under section 487.0191 applies, you may not tell the client. Separately, do not disclose the existence or content of a suspicious transaction report where doing so could prejudice an investigation, and do not volunteer internal suspicion analysis to a requesting officer simply because it sits in the file. Take advice on what must be produced.
- Test it with a fake. Send your own team a convincing fraudulent request from a lookalike domain twice a year and see what happens. Put the scenario in annual training. Put the procedure and the register in scope for your next effectiveness review. An untested procedure is a document, not a control.
If it happens to you, the clock starts immediately
- PIPEDA. An unauthorised disclosure of personal information is a breach of security safeguards. Where it is reasonable to believe the breach creates a real risk of significant harm, you must report to the Office of the Privacy Commissioner of Canada and notify affected individuals as soon as feasible, and notify any organisation or government institution able to reduce the harm. A disclosed KYC file with identity documents will almost always clear that threshold. Records of every breach, whether or not it meets the threshold, must be kept for 24 months.
- Provincial regimes. Quebec, Alberta and British Columbia impose their own regimes on entities within their scope. If you hold Quebec customer data, Law 25 obligations apply alongside the federal ones.
- Retail Payment Activities Act. A registered PSP that becomes aware of an incident with a material impact on an end user, another PSP or a clearing house must notify the affected parties and the Bank of Canada without delay, and no later than 48 hours after determining the incident is material. Notification runs through PSP Connect. Every incident, material or not, must be investigated, responded to and documented under your operational risk and incident response framework.
- PCMLTFA. Assess whether the circumstances support a suspicious transaction report, and consider the effect on the risk rating of the affected clients.
- Contain and correct. Block the sender, notify the impersonated agency and the police, preserve the full email chain and headers, and freeze the procedure until it is fixed.
The uncomfortable part of this incident is how ordinary it was. No sophisticated intrusion, no insider, no zero day. An email arrived, it looked legitimate, and someone decided to be helpful. Every firm holding client identification records is one such decision away from the same outcome.
The firms that get this right will not be the ones with the best technology. They will be the ones that decided in advance, and in writing, who is permitted to say yes.
Frequently Asked Questions
Sources and references
- TechCrunch, “Revolut confirms customer data breach through fake government requests”, 12 September 2026 — techcrunch.com
- The Record, “Revolut handed customer data to fraudsters using government email account” — therecord.media
- Criminal Code, RSC 1985, c C-46, ss 487.014, 487.018, 487.0191, 487.0195 — laws-lois.justice.gc.ca
- Personal Information Protection and Electronic Documents Act, ss 7(3)(c), 7(3)(c.1)(ii), 10.1 to 10.3
- R. v. Spencer, 2014 SCC 43
- FINTRAC, Reporting suspicious transactions to FINTRAC
- Office of the Privacy Commissioner of Canada, What you need to know about mandatory reporting of breaches of security safeguards
- Bank of Canada, Reminder: PSP reporting obligations under the RPAA — bankofcanada.ca
Claudius O. Otegbade
CPA (New York) · FCA · MBA · CAMS · CFE · CFCS · CBP · CIPP/CClaudius is Co-Founder and Lead Partner of C&G Professional Services Inc., with close to two decades in anti-money laundering compliance, forensic accounting, and regulatory audit. He led AML engagements at Grant Thornton LLP and MNP LLP, previously served as Director and Chief Compliance Officer at WFCU Credit Union, and has conducted over 100 AML effectiveness reviews and FINTRAC examination support engagements for reporting entities across Canada.
Full profile → LinkedIn →Does your compliance program cover law enforcement requests?
C&G builds and tests law enforcement response procedures for MSBs, PSPs, virtual currency businesses and other Canadian reporting entities — and puts them in scope at your next effectiveness review.