Key Takeaways
- At its 2 November 2026 update, the Bank named gaps it had seen: missing framework approvals, objectives without indicators, unassessed third parties, incomplete incident response plans and weak monitoring of anomalous events.
- The RPAR lets each PSP set its own testing frequency and scope, but smaller PSPs still need risk-based, documented testing; the Bank publishes no testing template.
- There is no numeric materiality threshold: report incidents that materially affect an end user, another PSP or a clearing house, no later than 48 hours after determining materiality.
- An assessment starts with an RFI and ends with written findings; the Bank expects evidence that controls operate in practice, explained by the people who run them.
In the first year of operational risk supervision under the Retail Payment Activities Act (RPAA), the Bank of Canada found payment service providers (PSPs) missing specific, checkable requirements: annual framework approvals, measurable indicators, yearly third-party assessments, prescribed incident response plan elements and monitoring of anomalous events. At its 2 November 2026 supervision update, the Bank told PSPs that a Bank of Canada RPAA assessment asks for evidence that controls work in practice. Close those gaps before an RFI arrives, and keep your testing, incident and review records ready to produce.
Our RPAA operational risk framework guide covers each element.
What did the Bank of Canada find in its first year of RPAA supervision?
The risk management and safeguarding requirements came into force on September 8, 2025. Bank staff said at the 2 November 2026 update that assessments of some PSPs began then, and that every PSP should already comply.
Staff then named areas where they had observed some PSPs were not in compliance, while asking PSPs to review every area of the guideline. Each maps to a rule in the Retail Payment Activities Regulations (RPAR).
Has your framework been approved, and does it need to be one document?
Your framework should have at least one approval on record by now. Staff pointed out that the requirement has been in place for over a year, so the first annual approval (and the board's, if you have one) should already have happened.
The framework can be several documents. Staff confirmed this, and the Bank's Operational risk and incident response guideline says there is no one-size-fits-all structure. If you use several, list each one and its version in the approval record.
Do your integrity, confidentiality and availability objectives have indicators?
Each objective needs at least one indicator that you track. Staff said PSPs must set and track indicators for each of the three objectives, meaning something measurable that shows whether the objective was met.
Indicators might be monthly payment service uptime against a target, the number of successful unauthorized access attempts, or reconciliation breaks left open past a set period. The annual review under RPAR s. 8(2) must evaluate your results against those indicators, so the same numbers become evidence.
Have you assessed every third-party service provider this year?
Every third-party service provider that supports a payment function must be assessed at least once a year. You can scale the depth to the risk (staff gave the example of a provider that is itself federally regulated), but no provider can be skipped. Check your vendor list against Appendix H of the guideline, which includes cloud and backup storage, systems maintenance, cyber and fraud services, testing or independent review, banking services such as an operating account, and accounts, insurance or guarantees used for safeguarding. Your bank and your penetration tester can both count. RPAR s. 5(3)(b) requires a record of the date, scope and findings of each assessment.
Does your incident response plan include every prescribed element?
The RPAR lists elements the plan must reflect explicitly, and some PSPs have left elements out. Staff said, "we have observed PSPs missing some of these specific requirements," and named escalation, mitigation measures and identifying the status of transactions.
Go through RPAR s. 5(1)(i) line by line. Besides the three named, it covers manual or alternate processes, immediate investigation, measures to prevent further damage, root causes, recovery of lost or corrupted data and a record of each incident. Staff also reminded PSPs that incidents can start at, or be detected by, a third party, so the plan should say how a provider's incident reaches you.
Staff's readiness check: can the people who would use the plan understand their responsibilities and act on it? A tabletop exercise or walk-through (both listed in Appendix G) will tell you.
Are you monitoring for anomalous events as well as incidents?
Your monitoring has to catch events that could become incidents. RPAR s. 5(1)(h) requires continuous monitoring to promptly detect incidents, anomalous events that could indicate emerging operational risks, and lapses in how the framework is implemented. Staff had seen PSPs without sufficient processes for this.
Their examples were unauthorized changes to systems or assets, misuse of access by employees, third-party service providers, agents or mandataries, and breaches of internal policies. Monitoring that only alerts when a service goes down will miss most of these, and RPAR s. 5(1)(j) requires a plan for responding to them.
Could someone else follow your documentation and repeat the process?
Write procedures in enough detail to be repeated. Staff's test was whether someone with the appropriate responsibilities could follow the documentation and repeat the process reliably. RPAR s. 40 also requires records sufficient to demonstrate compliance.
For smaller or less complex PSPs, what would the Bank of Canada consider sufficient evidence to demonstrate compliance with the annual testing requirement?
A small PSP can scale its testing, but it must still test properly and keep records. Bank staff said at the 2 November 2026 update that proportionality applies, "but you do still need to be doing some fulsome testing."
The RPAR does not set testing at once a year. Section 9 lets your methodology set the frequency and scope, and requires testing before any material change. What must happen annually is the framework review (s. 8(1)) and the senior officer's approval (s. 5(6)).
The methodology must also be proportionate to the impact a disruption could have, cover high-likelihood and high-impact risks, involve internal stakeholders and consider reliance on third parties. Section 10 of the guideline expects three categories of test: verifying and validating controls, scenario-based testing, and testing of changes. Tests run for other purposes can count if they meet section 9.
Appendix G lists methods such as documentation review, interviews, sample-based testing, tabletop exercises, walk-throughs and simulations. It says more ubiquitous or interconnected PSPs could add penetration tests and attack simulations, so a smaller PSP can lean on lighter methods if they reach its higher-risk areas. For each test, RPAR s. 9(2) requires a record of the date, methodology, results and measures taken or planned, and the guideline asks you to record why any gap was left unremediated. Those records, given to the senior officer under s. 9(3), are the evidence to expect to show.
What operational threshold constitutes a material impact that requires an immediate incident report to the Bank?
There is no fixed numeric threshold. An incident is reportable when it has a material impact on an end user, another PSP or a clearing house, judged against your own business model and services. Staff acknowledged that "material impact" is an imprecise term.
The Bank's Incident notification guideline gives examples and says they are not exhaustive:
Staff stressed that this applies whether the root cause is internal, external or at a third-party service provider. Under section 18 of the RPAA, notice must be given without delay. The guideline sets this at no later than 48 hours after you determine the incident is material, to the Bank and to each materially affected party. Staff added that not reporting a reportable incident is itself a compliance issue.
What happens during a Bank of Canada RPAA assessment?
An assessment starts with a request for information and ends with written findings and a closing meeting. Staff said the steps may not be linear:
Under the RPAA the Bank can also request information (s. 65), direct a special audit at the PSP's expense (s. 67) and examine records and premises (s. 69). The incident notification guideline notes that a Bank request about an ongoing incident that could have a significant adverse impact must be answered within 24 hours (RPAR s. 43(2)). The Bank may also consider enforcement. Our article on the Bank of Canada notice of violation process covers what follows, and the XTM Inc. order shows the Bank using its order powers.
How can a PSP get ready before an assessment begins?
Assess yourself against the guidance now. Staff gave three steps: read the guidelines, at-a-glance resources and FAQs on the Bank's supervisory framework page; review your own policies, processes and controls critically; and have your evidence ready. "The assessment process is not just about telling us what your policy is," staff said. You need records of how your arrangements are designed and how they operate in practice.
A short readiness check:
Staff also reminded PSPs that registration is not a licence and does not mean the Bank has found a PSP compliant. If you are still working through RPAA registration or need help building assessment-ready records, see our PSP registration and RPAA compliance support.
Frequently asked questions
Are there examples, templates or best practice formats the Bank of Canada recommends for documenting annual testing plans and procedures?
No. Staff said the Bank does not publish a testing template, because one format would not suit the spread of business models, risks, ubiquity and interconnectedness among PSPs. Design your approach from the guideline's testing section and document how it meets each objective. Staff added that internal and independent review requirements apply to both operational risk and safeguarding.
What level of detail does the Bank expect in an incident report, and how does it want post-incident reviews handled?
Report what you know within 48 hours and add detail as you learn it. You can file an initial notice, interim notices as the incident develops, and a final notice once the root cause and the measures taken are known. If you have full information within 48 hours, you can go straight to a final notice. Staff said linked notices in PSP Connect are seen as one package, and that the Bank's step-by-step guide explains each field. After an incident, the Bank expects a post-incident review of lessons learned, including gaps in the incident response plan itself.
Does every PSP need an independent review of its framework?
No. Under RPAR s. 10, the independent review applies to PSPs that have an internal or external auditor. A sufficiently skilled person with no role in the framework must review it at least once every three years. The guideline says occasional use of an auditor for specific testing does not mean a PSP "has an external auditor." Every PSP must still do the annual internal review under s. 8.
Can a consultant speak for us during an assessment?
A consultant can help build the framework, but staff said accountability stays with the PSP and the Bank expects to hear from the people who run the framework and can explain it.
Related insights
Book a free compliance consultation?
Tell us about your business and we'll confirm which services you need. Free, no obligation, 30 minutes.
