RPAA Compliance: Bank of Canada Framework Guide for PSPs

RPAA compliance means a payment service provider (PSP) in scope of the Retail Payment Activities Act registers with the Bank of Canada, operates a written risk management and incident response framework, reports material incidents without delay (within 48 hours under the Bank's guideline), and files an annual report, with the framework and reporting duties in force since September 8, 2025. A SOC 2 or ISO 27001 program covers much of the security work behind that framework, but the Act asks for several things neither framework produces alone.

Who is a payment service provider under the RPAA?

A payment service provider under the RPAA is an individual or entity that performs one or more payment functions as a service or business activity that is not incidental to another service or business activity. The Act defines five payment functions, and performing any one of them for an electronic funds transfer brings a business into scope.

An amendment enacted in 2026 (S.C. 2026, c. 3, s. 604) and not yet in force would add a sixth function: transmitting or maintaining an end user's encrypted or tokenized payment instrument or private key.

Which organizations and activities does the RPAA exclude?

The RPAA excludes banks and other federally or provincially regulated deposit-takers and insurers, closed-loop merchant instruments, ATM withdrawals, designated clearing systems, intra-group transfers, registered agents, SWIFT, and incidental payment activity.

When did the RPAA operational risk and safeguarding requirements take effect?

The RPAA's operational risk, incident notification, safeguarding, and annual report duties (sections 17 to 22) came into force on September 8, 2025, per the Justice Laws consolidation of the Act.

What must an RPAA risk management and incident response framework include?

An RPAA risk management and incident response framework must be in writing and meet the requirements in section 5 of the Retail Payment Activities Regulations. The Bank of Canada's Operational risk and incident response guideline organizes those requirements into identify, protect, detect, respond and recover, then review and test.

The framework must, among other things:

• Set objectives and measurable reliability targets for payment activities and system availability.
• Allocate roles and resources, including a senior officer accountable for compliance.
• Classify assets and business processes by sensitivity and criticality.
• Identify operational risks across 11 named categories, from cybersecurity and fraud to change management and third parties.
• Describe controls, continuous monitoring, and an incident response and recovery plan.
• Assess third-party service providers and agents at least once a year.

The senior officer must approve the framework at least once a year and after each material change, and the board, if the PSP has one, must approve the framework annually. Every element must be proportionate to the impact a disruption would have on end users and other PSPs.

How does a SOC 2 or ISO 27001 program map to RPAA operational risk requirements?

A SOC 2 or ISO 27001 program evidences much of the RPAA's security and resilience work, but neither produces the payment-specific artifacts the Regulations name. SOC 2 and ISO 27001 are voluntary frameworks. The RPAA is federal law with statutory penalties. One program can satisfy all three if the program closes the gaps in the right-hand column.

What does the RPAA require for incident notification to the Bank of Canada and end users?

The RPAA requires a PSP that becomes aware of an incident with a material impact on an end user, another PSP, or a designated clearing house to notify the affected party and the Bank of Canada without delay (Act, s. 18). The Bank's Incident notification guideline sets the outer limit at 48 hours after the PSP determines the incident is material.

Every incident must be investigated and documented, material or not. The Bank's examples of material impact include unrecoverable loss of end-user funds, an outage that materially affects availability, a confidentiality breach creating a real risk of significant harm, and integrity failures such as ledger compromise or misrouted funds.

Notices go directly to each affected end user, with a website posting where contact details are missing. The guideline rules out social media as the notice channel. If personal information is involved, privacy breach rules such as PIPEDA's breach reporting obligations apply in parallel.

What steps should an RPAA incident notification runbook follow?

An RPAA incident notification runbook turns the Act, the Regulations, and the Bank's guideline into steps a responder can follow.

The Bank can also request information during an ongoing incident with a potential significant adverse impact, and the Regulations give the PSP 24 hours to respond (Regs, s. 43(2)).

How should a payment service provider build an RPAA framework in 90 days?

A payment service provider with no RPAA framework can plan the build in about 90 days: a capability assessment first, then the framework document, then controls and evidence. The 90 days is a planning estimate, and the Regulations set no build deadline.

The vendor risk assessment guide covers how to scope third-party reviews by data access, which keeps the annual RPAA assessments proportionate. The SOC 2 CC9.1 business disruption post covers the continuity planning that feeds the manual fallback requirement.

What records and annual reports does the RPAA require?

The RPAA requires a PSP to keep records sufficient to demonstrate compliance until five years after they stop demonstrating current compliance (Regs, s. 40). Records must be protected against loss, falsification, and unauthorized access, including records held by agents and third-party service providers.

The annual report, due March 31 through PSP Connect, must describe framework changes, targets, third-party and agent assessments, risks, controls, reviews and tests, and every incident during the year (Regs, s. 19). The Bank's June 2026 reminder on PSP reporting obligations warns that missed reporting may lead to enforcement action. A PSP must also notify the Bank at least five business days before a significant change or a new retail payment activity (Regs, s. 20).

Why does RPAA operational risk work matter to bank partners and enterprise merchants?

RPAA operational risk work matters commercially because the same evidence answers the due diligence bank partners, card program sponsors, and enterprise merchants run before they sign. When a PSP performs services for a federally regulated bank, OSFI Guideline B-10 expects the bank to assess that third party's risks, including business continuity and recovery, and lists independent reports among acceptable evidence.

Many of the security questions in that review follow OSFI B-13, and the OSFI B-13 guide for suppliers maps those expectations to SOC 2 and ISO 27001.

A PSP that hands over the RPAA framework, a test record, and a SOC 2 report in one package shortens that review. Banking and clearing and settlement are also sectors covered by Canada's new critical cyber systems law, and the Bill C-8 supplier requirements post covers the security clauses designated operators are expected to push to vendors. The case for starting with a SOC 2 Type I explains how an early report unblocks the first counterparty, and the SOC 2 guide for Toronto fintech covers scoping for payments companies.

What keeps RPAA compliance current after registration?

RPAA compliance holds up when the framework, the controls, and the evidence come from one security program that operates every week. The Bank of Canada can assess the framework and order follow-up notices, so a document written once for registration will be out of date by the first incident.

Frequently asked questions about RPAA compliance

What is RPAA compliance?

RPAA compliance means meeting the obligations of Canada's Retail Payment Activities Act and the Retail Payment Activities Regulations. For a registered payment service provider, that includes a written risk management and incident response framework, safeguarding of end-user funds, material incident notices to the Bank of Canada and affected users, an annual report due March 31, and records kept for inspection.

Does SOC 2 satisfy the Retail Payment Activities Act?

SOC 2 covers part of the work, and the RPAA asks for more. SOC 2 is a voluntary AICPA attestation and the RPAA is federal law. A SOC 2 program evidences many of the security controls the RPAA framework needs, but the Regulations also require payment-specific reliability targets, a named senior officer, annual board approval, agent criteria, transaction status recovery, and 48-hour incident notices that SOC 2 does not test.

How quickly must a PSP report an incident under the RPAA?

The RPAA requires notice without delay when an incident has a material impact on end users, other PSPs, or a designated clearing house. The Bank of Canada's incident notification guideline sets the limit at 48 hours after the PSP determines the incident is material, using PSP Connect for the Bank and direct notice for affected users.

Do foreign payment companies need RPAA registration?

A payment service provider without a place of business in Canada is covered when the provider performs retail payment activities for an end user in Canada and directs those activities at individuals or entities in Canada. Whether a specific foreign business meets that test is a legal question, and the company should confirm the answer with Canadian payments counsel.

What are the penalties for violating the RPAA?

The Retail Payment Activities Regulations set administrative monetary penalties of up to $1 million for a serious violation and up to $10 million for a very serious violation. Late annual reports and certain notices carry $500 per day for the first 30 days, then a range of $15,000 to $1 million.