RPAA

AI risk under the RPAA: what the Bank of Canada expects from PSPs

No AI-specific RPAA rules exist. How shadow AI, prompt injection, agent permissions, provider concentration and AI fraud fit the duties PSPs already have.

On this page
Get Expert Help

Key Takeaways

  • As of 3 November 2026 the Bank of Canada has published no AI-specific guidance for PSPs. At its 2 November 2026 session, staff said existing RPAA and RPAR expectations apply.
  • Shadow AI, prompt injection, agent permissions, shared provider concentration and AI-enabled fraud each fall under RPAR section 5: the framework, third-party assessments, monitoring and incident response.
  • Staff said human oversight must be meaningful: the reviewer needs the information and authority to stop or override an AI action.
  • Logs should let you reconstruct access, tool use and approvals, and containment steps such as revoking access or falling back to a manual process should be planned before an incident.

The Bank of Canada has not published AI-specific rules for payment service providers (PSPs). At its 2 November 2026 supervision update, Bank staff said existing RPAA and Retail Payment Activities Regulations (RPAR) expectations continue to apply as AI evolves. AI risk therefore sits inside the operational risk framework, third-party assessments, monitoring and incident notification duties you already have. Each of the five AI risks staff named maps onto one of those duties.

Has the Bank of Canada issued AI rules for PSPs?

No. As of 3 November 2026 we found no AI-specific guideline, policy or FAQ for PSPs on bankofcanada.ca. The Bank's retail payments supervisory framework page lists guidelines on registration, operational risk and incident response, safeguarding, reporting and enforcement. None of them mentions artificial intelligence, and neither does the retail payments supervision FAQ.

At the session, staff said PSPs already have the structure they need, and that the Bank focuses on outcomes without prescribing specific technologies. In their words, "AI changes the environment, but not the fundamentals."

The legal anchor is section 17 of the Retail Payment Activities Act, which requires a risk management and incident response framework for identifying and mitigating operational risks and responding to incidents. Section 5 of the RPAR sets out what that framework must contain. Neither names a technology, so an AI tool that touches a payment function is covered like any other system.

Which AI risks did Bank staff name?

Staff said most AI-related cyber risks will look familiar: data exposure, unauthorized access, fraud, third-party failure and service disruption. AI changes how quickly and how broadly they can materialize. They named five.

Shadow AI

Shadow AI is staff using AI tools the PSP has not approved and may not know about. The example given was an employee pasting sensitive end-user or authentication data into an unapproved tool. That data has left the PSP's environment, and the PSP may have little visibility over where it goes. Staff also flagged AI already embedded in existing technology, which belongs in the same inventory as approved tools.

Prompt injection and manipulated outputs

Prompt injection is a malicious instruction hidden in content the AI reads. It can lead an agent to disclose information or misuse a connected tool, and staff said the damage grows with what the AI can access and do. An unreliable or manipulated output can also sway a fraud decision, an incident response or an automated process, and the problem may go unnoticed until the impact is felt.

Agent permissions and least privilege

An AI agent may be able to retrieve data, call an API or take part in a payment workflow. A mistake or malicious instruction does more harm when the AI can act, because a reviewer can catch a bad answer, while "A bad action may already have happened." Staff gave a least-privilege example: a tool that only needs to retrieve information shouldn't automatically be able to modify a record or execute a transaction.

Shared model or cloud provider concentration

Many PSPs depend on the same AI platforms, cloud services and integrations. Staff said a common vulnerability, a compromised component or a provider outage could hit several services, or several PSPs, at once. The Bank's Financial System Survey highlights for 2026 (28 May 2026) reported that respondents, senior risk managers across Canada's financial sector, raised concerns about concentration in third-party AI and cloud providers. That survey was not limited to PSPs.

Impersonation and fraud

Staff said bad actors use AI to create far more convincing emails, messages, voices and even supporting documents. Phishing can now refer to a real system, person or payment process, which makes it harder for staff to spot. PSPs should check whether this changes their existing fraud, social engineering and attack scenarios.

Which RPAR requirements does each AI risk fall under?

Each risk maps to obligations already in the RPAR (SOR/2023-229) and the RPAA (S.C. 2021, c. 23, s. 177). Section references are to the RPAR unless marked, checked on 3 November 2026.

AI risk Operational risk framework Third-party assessment Monitoring and incident notification
Shadow AI Classify assets and data by sensitivity (s. 5(1)(e)); information and data management risk (s. 5(1)(f)(iv)); training (s. 7) An approved AI service provided under contract for a payment function is a third-party service provider (s. 5(3)) Monitor for lapses in the framework (s. 5(1)(h)); plan for anomalous events and lapses (s. 5(1)(j))
Prompt injection and manipulated outputs Cybersecurity and IT risk (s. 5(1)(f)(ii), (v)); protective controls (s. 5(1)(g)); testing (s. 9) Provider's data protection and connection security (s. 5(3)(a)(i), (ii)) Detect incidents (s. 5(1)(h)); investigate immediately (s. 5(1)(i)(iii)); notify material incidents (RPAA s. 18)
Agent permissions Roles, challenge and oversight (s. 5(1)(d)); protective controls (s. 5(1)(g)) Allocate data ownership, integrity, confidentiality and availability (s. 5(3)(c)) Monitor the controls themselves (s. 5(1)(h)(iii)); record each incident (s. 5(1)(i)(viii))
Shared model or cloud concentration Business continuity and third-party risk (s. 5(1)(f)(i), (xi)); manual or alternate solutions (s. 5(1)(i)(ii)) Assess yearly and before entering, renewing, extending or substantially amending a contract; change and breach notice (s. 5(3)(a)) Incident plan covers incidents at a third party (s. 5(1)(i)); notify affected parties and the Bank (RPAA s. 18)
Impersonation and fraud Fraud and human resources risk (s. 5(1)(f)(iii), (vi)); training (s. 7) Provider's risk management practices (s. 5(3)(a)(v)) Detect promptly (s. 5(1)(h)); notify materially affected end users with corrective measures they could take (s. 12)

The framework must be proportionate to the impact a disruption could have on end users and other PSPs (s. 5(2)), so a small PSP using one vendor chatbot need not document AI risk in the same depth as a large PSP running agents inside its payment flow. Section 22 of the RPAA also requires notice to the Bank before a significant change, meaning one that could reasonably be expected to have a material impact on operational risks. The Bank's operational risk and incident response guideline (para. 12.9) says engaging a third-party service provider, or changing how you use one, may be a significant change. Our guide to the RPAA operational risk management framework covers the framework in full.

What does meaningful human oversight of AI look like?

It means a person with the information and the authority to challenge, stop or override an action. Staff said "Having a person somewhere in the process is not enough." They framed governance as four questions for each AI use case:

The RPAR already requires specific roles and responsibilities, someone to challenge and oversee each role, and a senior officer overseeing material operational risk decisions (s. 5(1)(d)). Staff added that a new model, broader permissions or a new integration can change the risk profile, so the risk and controls should be revisited when that happens. The RPAR requires a framework review before any material change to systems or controls (s. 8(1)(b)) and testing before a material change is adopted (s. 9(1)(e)).

How detailed should AI activity logs be?

Logs should let you reconstruct what happened. Staff said logging should capture enough to reconstruct important activities, such as access attempts, connected tool use and approvals, because without that, investigation becomes very difficult.

Appendix C of the operational risk guideline says PSPs should track, log and review the activity history of internal and external access, and give people or systems only the minimum access needed (least privilege). The RPAR requires a record for each incident covering root causes, impacts, measures taken and the status of all transactions (s. 5(1)(i)(viii)). Where an AI agent initiated or approved a step, the logs should show which agent acted, under whose authority, with which tool, and what a human approved. A useful test is whether someone outside the team could rebuild the timeline from the logs alone.

How should a PSP contain an AI-related incident?

Plan the containment steps before you need them. Staff said containment might mean revoking access, disabling an integration or moving to an established fallback process, for incidents in your own AI-enabled systems and for attacks where a threat actor used AI. Lessons from each incident should feed back into the risk assessment and controls.

The RPAR requires your incident plan to identify mitigation measures, including manual processes or alternate solutions if primary systems are unavailable, and how quickly you could use them (s. 5(1)(i)(ii)). During an investigation you must take immediate measures to prevent further damage (s. 5(1)(i)(iv)).

If the incident has a material impact on end users, another PSP or a designated clearing house, section 18 of the RPAA requires you to notify them and the Bank without delay. The Bank's incident notification guideline sets the limit at no later than 48 hours after the PSP determines the incident is material, followed by interim and final notices. Staff also said at the session that failing to report a reportable incident is itself a compliance issue. Our article on the Bank of Canada notice of violation process explains what can follow.

As PSPs increasingly adopt AI for fraud detection, AML monitoring and risk management, how does the Bank view the balance between innovation, model risk, data protection and regulatory oversight?

The Bank treats responsible innovation as an explicit policy goal, and AI does not reduce a PSP's accountability for the outcomes of its systems. That was the answer in the audience Q&A at the 2 November 2026 session.

Staff said innovation can improve the effectiveness, speed and scalability of compliance and risk management. PSPs are expected to tailor their frameworks to their size, complexity, organizational structure and technology. Data protection and privacy remain fundamental, and the Bank generally looks at whether outcomes meet regulatory objectives without prescribing specific technologies. The moderator added explainability: being able to show how an AI-supported process meets your compliance obligations.

For AML use cases, remember that the RPAA covers operational risk and the safeguarding of end-user funds, while AML and anti-terrorist financing obligations sit with FINTRAC. An AI transaction monitoring model can engage both. See our comparison of MSB and PSP registration in Canada and our piece on ongoing AML monitoring with third-party onboarding tools.

What should a PSP check before its next Bank assessment?

Staff said PSPs should be able to show the scope of their AI use, the risks identified and the controls relied on, backed by testing, training, policies and procedures. Check that you:

If you are building or updating your framework ahead of an assessment, see our PSP registration services in Canada.

Frequently asked questions

How do you ensure that oversight supports innovation rather than inadvertently slowing it down?

Bank staff said innovation and oversight can work hand in hand, and the task is creating the trust and operational clarity that let innovation scale safely. The Bank publishes guidance, seeks industry feedback and then administers the regime consistently with that guidance, as it has for the RPAA. It also coordinates with the Department of Finance, provincial authorities and securities regulators to reduce duplication where jurisdictions overlap.

Is there a Bank of Canada guideline on AI for payment service providers?

No. As of 3 November 2026 the Bank had not published one. At the 2 November 2026 session, staff said existing RPAA and RPAR expectations apply and pointed PSPs to the operational risk and incident response guideline.

Is an AI vendor a third-party service provider under the RPAA?

Yes, if it provides you, under a contract, with a service related to a payment function and is not your employee, agent or mandatary. The RPAR then requires you to assess it at least once a year and before entering, renewing, extending or substantially amending the contract.

Do AI-related incidents have to be reported to the Bank?

Yes, when they have a material impact on an end user, another PSP or a designated clearing house. The RPAA does not treat incidents differently by technology, and every incident, material or not, must be investigated, responded to and recorded.

Is adopting a new AI tool a significant change under the RPAA?

It can be. A change is significant if it could reasonably be expected to have a material impact on operational risks or on how end-user funds are safeguarded, and the Bank's guideline says engaging or changing the use of a third-party service provider may qualify. If it meets the test, notify the Bank before the change.

ComplyFactor Advisory Team

ComplyFactor is a Canadian AML and regulatory compliance advisory firm serving MSBs, PSPs, fintechs and other regulated businesses.

Get started

Book a free compliance consultation?

Tell us about your business and we'll confirm which services you need. Free, no obligation, 30 minutes.

Free, no obligation, 30 minutes
Senior consultant on every engagement
Advice matched to your regulator and jurisdiction
+1 807 806 0444 Β· Suite 211, 320 Matheson Blvd West, Mississauga, ON

Talk to an AML expert

Thank you. Your message has been received. We'll be in touch within one business day.
Something went wrong while submitting the form. Please try again.