If your PSP holds end-user funds in a segregated bank account and assumes deposit insurance covers the safeguarding requirement, the Bank of Canada has just told you otherwise. In an expanded FAQ published on 14 August 2026, the Bank set out — in more operational language than anything it has issued to date — what it expects to see when it supervises registered payment service providers under the Retail Payment Activities Act. [1]
The FAQ does not amend the RPAA or its regulations, and creates no new obligations. What it does is narrow the space for a good-faith misreading — and several of those readings will surprise PSPs who thought they were already compliant.
Deposit insurance is not safeguarding
This is the clarification with the sharpest operational edge. The Bank states that federal or provincial deposit insurance, on its own, would not meet the safeguarding requirements under subsection 20(1) of the RPAA. [1] The logic is simple once you see it: deposit insurance protects you against the failure of the financial institution holding the account. Safeguarding protects end users against the failure of the PSP itself. (Subsection 20(2) carves out one narrow case — a PSP that itself accepts provincially insured or guaranteed deposits, in respect of those deposits.[2])
The Bank went further on trust arrangements. Where a PSP relies on a trust, it says it will request a written legal opinion describing how a valid express trust has been established under common law or the Civil Code of Québec — and it expects that opinion to also describe and assess the risks to the trust’s validity, and how the PSP has addressed them. [1] That drafting burden sits with the PSP, not the Bank.
The Bank also flags a practice that quietly undermines many trust structures. As a best practice, it says a PSP should not pay expenses other than trust expenses from the trust account, and should settle its obligations to payment networks or financial institutions from a separate account. [1][4]
For PSPs relying on insurance or a guarantee instead, paragraph 20(1)(c) of the RPAA requires coverage equal to or greater than the amount held in the account. [2] The Bank expects a methodology that accounts for daily fluctuations, and monitoring to match. [1][4] And the PSP — not the Bank — must document how end users actually get their money back: the Bank will supervise compliance, but will not administer the claims or reimbursement process. [1]
The sentence worth putting in front of your operations team: funds can be segregated without being safeguarded.
Governance and annual reporting: who, and by when
On governance, the Bank confirmed that a senior officer does not need to be located in Canada, provided the individual meets the definition in section 1 of the Retail Payment Activities Regulations. [1][3] It added that, in light of limb (c) of that definition, a senior officer need not be a direct employee of the PSP — provided the individual reports directly to the PSP’s board of directors, CEO or COO. [1][3] “Not an employee” and “not in Canada” are permitted. “Not accountable” is not.
On reporting, the annual report is due by 31 March each year. [1][5] The first report generally covers activities from the 2025 calendar year, while financial metrics are pegged to the PSP’s own fiscal year-end. [1]
The Bank also confirmed that a PSP may use an existing risk-management framework — including a parent entity’s — on the condition that the framework meets the expectations set out in the RPAA, its regulations and the Bank’s guidelines. [1] That condition is the whole sentence. Inheriting a parent’s framework is permitted; inheriting it unexamined is not.
You can outsource a function. You can’t outsource accountability.
A bank or other regulated financial institution can itself be a third-party service provider where it provides services connected to the PSP’s payment functions. A PSP must assess its third-party service providers, and may take a third party’s regulatory status into account in that assessment — but it remains accountable for managing the risks arising from the relationship, and must meet all of its own regulatory obligations. [1]
The statutory backstop is section 87 of the RPAA: a PSP is liable for a violation committed by any of its employees, third-party service providers, or agents or mandataries acting in the course of their employment, their contract or the scope of their authority — whether or not the party that actually committed the violation is ever identified. [2] In our reading, that closes off a defence some PSPs may have assumed they had, though due diligence remains available as a defence under section 86. [2] “It was the vendor” is a fact about causation, not a fact about liability.
Four assumptions the FAQ corrects
Each appears in the Bank’s own answers, and each is the kind of assumption that gets expensive. [1]
- “We don’t make money from payments, so we’re out of scope.” A business subject to the RPAA must register whether or not it generates revenue from the activity.
- “We use Interac e-Transfer, so we’re covered.” Payment functions performed within a designated system fall outside the Act — but functions performed outside it, such as maintaining an account, initiating an EFT, or transmitting payment instructions, can remain in scope.
- “Our partner is already registered, so we don’t need to be.” Whether or not you are doing business with another registered PSP, you are responsible for registering with the Bank and for your own compliance with the RPAA and its regulations.
- “We’ll register once we’re bigger.” A PSP performing covered activities without having applied is operating in violation of the Act.
Worth noting alongside these: registration is not a licence. The RPAA requires PSPs to register with the Bank; it does not license them. [1] The distinction matters when you describe your regulatory status to partners, banks or investors.
One more registration question the FAQ doesn’t answer
The FAQ is a document about one statute. It answers scope questions within the RPAA, and only within the RPAA. It is worth being explicit about what sits outside that frame, because this is where PSPs most often get caught.
A money services business in Canada can answer to two separate regimes. Two regimes means two regulators and two separate registrations — each carrying its own requirements. Maintaining compliance with one, and satisfying one, does not mean you have been deemed compliant under the other.
Under paragraph 5(h) of the PCMLTFA, a person or entity with a place of business in Canada that is engaged in the business of foreign exchange dealing, remitting or transmitting funds by any means, issuing or redeeming money orders, or dealing in virtual currencies is a money services business — and section 11.1 requires it to register with FINTRAC. [6] Paragraph 5(h.1) captures the equivalent foreign business directed at persons in Canada. [6] A registered MSB must also maintain a compliance program under section 9.6, with the elements prescribed by section 156 of the regulations: an appointed compliance officer, written policies approved by a senior officer, a documented risk assessment, an ongoing training program, and a documented plan to review the program’s effectiveness. [6][7]
“Can” is doing real work in that sentence. Being a money services business does not automatically make you a payment service provider under the RPAA. RPAA scope turns on whether you perform retail payment activities, and sections 6 through 10 exclude certain entities and activities outright. Section 9 excludes banks, authorized foreign banks, and credit unions, caisses populaires and centrals regulated under a provincial Act; section 10 excludes an agent or mandatary of a registered PSP acting within the scope of its authority and named on that PSP’s list. [2] Payment functions performed inside a designated system such as Interac e-Transfer sit outside the Act as well. [1] Not every business model that registers with FINTRAC is required to register with the Bank.
The reverse direction is just as live. FINTRAC retracted its merchant-servicing and payment-processing positions (PI-7670) in April 2022, stating at the time that certain payment service providers are covered as MSBs or foreign MSBs and must register. [8] A business that concluded it sat outside MSB scope before that date should re-run the determination — and it should not assume its RPAA answer settles it.
One caution on reading the public record. Section 27 of the RPAA requires the Bank to maintain and publish a list of applicants it has refused to register and PSPs whose registrations have been revoked, together with the reasons. [2] That published list currently shows no entries. [9] But under subsection 27(2) a name is not added until the period for requesting a review has expired or the refusal has been confirmed — so an empty list is not proof that every applicant was accepted, and it is not a safe basis for assuming your own model is in scope. [2]
The practical takeaway is to run each determination separately, against its own statute, and to document the reasoning either way. A conclusion that you are outside RPAA scope is a position you may have to defend — and it says nothing at all about where you land under the PCMLTFA.
What to do with this
If your RPAA compliance program was built on the statute alone, this FAQ tells you how the supervisor reads it. Note that this is your RPAA program — if you are also a reporting entity, the PCMLTFA requires a separate compliance program, assessed by FINTRAC against its own prescribed elements. [6][7] And if you have concluded you are outside RPAA scope, document why.
Two questions worth putting to your team this quarter: if our safeguarding arrangement were tested tomorrow, would the legal opinion and the settlement flows both hold up? And can we name every third party connected to a payment function, and show the RPAA risk assessment behind it?
How Tamlo Can Help
Tamlo International works with PSPs at every stage of RPAA compliance — from registration through annual reporting and ongoing readiness. We also work with PSPs on the obligations that sit alongside the RPAA: MSB registration with FINTRAC, compliance programs under section 9.6 of the PCMLTFA, and the reviews and training those programs require. If your team needs a compliance review, staff training, or help preparing for a Bank of Canada inquiry or a FINTRAC examination, reach out to us at Tamlo International.
Sources
- Bank of Canada — Frequently Asked Questions About Retail Payments Supervision, 14 August 2026 (regulator guidance)
- Retail Payment Activities Act, S.C. 2021, c. 23, s. 177 (legislation)
- Retail Payment Activities Regulations, SOR/2023-229 (legislation)
- Bank of Canada — Safeguarding End-User Funds (supervisory guideline)
- Bank of Canada — Annual Reporting (supervisory policy)
- Proceeds of Crime (Money Laundering) and Terrorist Financing Act, S.C. 2000, c. 17 (legislation)
- Proceeds of Crime (Money Laundering) and Terrorist Financing Regulations, SOR/2002-184 (legislation)
- FINTRAC — Crowdfunding platforms and certain payment service providers must register with FINTRAC, 27 April 2022 (regulator guidance)
- Bank of Canada — Payment service providers with refused or revoked registrations (public registry, checked 17 August 2026)