RPAA testing requirements
The Retail Payment Activities Act (RPAA) is the Canadian federal law that requires payment service providers to register with the Bank of Canada, manage operational risk, report material incidents, and safeguard end-user funds. RPAA testing verifies recovery targets, incident handling, and the end-user funds ledger. FintechAssuranceLabs produces failover and recovery time results and a requirement-to-test traceability matrix.
- Jurisdiction
- Canada (federal statute, supervised by the Bank of Canada)
- Primary source
- laws-lois.justice.gc.ca
Engineering interpretation of testing requirements, not compliance advice.
What the Retail Payment Activities Act and its Regulations require
The Retail Payment Activities Act (RPAA, S.C. 2021, c. 23, s. 177; checked on 2026-09-16, consolidation current to 2026-07-21) and the Retail Payment Activities Regulations (RPAR, SOR/2023-229) apply to payment service providers (PSPs). A PSP performs payment functions listed in RPAA section 2, such as holding end-user funds or initiating an electronic funds transfer, as a service that is not incidental to another business. The RPAA covers PSPs with a place of business in Canada (section 4) and foreign PSPs that direct retail payment activities at Canada (section 5). Section 9 excludes banks, credit unions, and other listed institutions.
Per SI/2023-70, the registration application provisions came into force on 1 November 2024 and section 23 on 16 November 2024. Sections 17 to 22 (operational risk, incidents, safeguarding, reporting) came into force on 8 September 2025. Registered PSPs appear in the Bank of Canada registry.
- Registration, sections 23 and 29. A PSP is registered before it performs retail payment activities. The application describes the risk management and incident response framework (29(1)(i)), the safeguarding of end-user funds (29(1)(j)), and material third-party service providers (29(1)(k)).
- Operational risk, section 17 and RPAR sections 5 to 10. The written framework sets measurable reliability targets for payment activities and for the availability of systems, data, and information (RPAR 5(1)(b)). The incident response plan identifies the status of all transactions at the time of a disruption, recovers lost or corrupted data, and corrects data integrity issues (5(1)(i)(vii)). The testing methodology covers reliance on third-party service providers (9(1)(c)(ii)) and testing before any material change (9(1)(e)).
- Incident notification, section 18 and RPAR sections 11 and 12. A PSP notifies materially affected end users, other PSPs, designated clearing houses, and the Bank of Canada without delay. Notices go to each affected end user through the most recent contact information, and onto the website when contact information is missing (RPAR 12(1)).
- Safeguarding, section 20 and RPAR sections 13 to 17. End-user funds sit in a trust account used for no other purpose, or in a dedicated account with insurance or a guarantee (20(1)). The safeguarding-of-funds framework keeps a ledger with each end user's name, contact information, and funds held at the end of each day (RPAR 15(2)(b)). The PSP identifies, as soon as feasible, any instance where end-user funds would not have been payable in an insolvency (16(1)).
- Reporting, sections 21 and 22 and RPAR sections 18 to 20. The annual report is due by 31 March (RPAR 18(1)). A notice of significant change or new activity is due at least five business days before it (RPAR 20(1)(a)).
- Records, RPAR sections 40 and 41. Records sufficient to demonstrate compliance are kept for five years after they stop demonstrating current compliance (RPAR 40), with measures against loss, falsification, and inaccuracy (RPAR 41).
Bank of Canada supervisory guidelines add expectations. Operational risk and incident response (October 2024) recommends that more ubiquitous or interconnected PSPs should set availability targets, recovery time objectives, maximum tolerable downtime, and recovery point objectives (paragraph 2.7). Safeguarding end-user funds (December 2024) states that a PSP must update its ledger each day (paragraph 3.9) and, as best practice, should take daily measures to identify shortfalls (paragraph 4.4). The Incident notification guideline (October 2024) sets a limit of 48 hours after the PSP determines an incident is material (paragraph 4.1). RPAR section 48 sets penalties of up to $10,000,000 for a very serious violation. Section 604 of S.C. 2026, c. 3 adds the transmission or maintenance of tokenized payment instruments and private keys as a payment function; it is not in force in the 2026-07-21 consolidation.
What RPAA testing verifies
| Requirement | What we test | Evidence produced |
|---|---|---|
| RPAR 5(1)(b): measurable reliability targets for retail payment activities and system availability | Availability, recovery time, and recovery point of each payment service during forced failover | Failover and recovery time results per payment service |
| RPAR 5(1)(i)(vii): status of all transactions identified after a disruption, data integrity issues corrected | Transfer and authorisation records after failures during initiation, authorisation, and settlement file processing | Transaction status reconstruction log per failure point |
| RPAR 9(1)(c)(ii): tests that take into account reliance on third-party service providers | Processor, bank connection, and cloud region outages with timeouts, error responses, and delayed callbacks | Third-party provider outage simulation results |
| RPAR 9(1)(e): testing before a material change to systems, controls, or operations | Release candidates that change payment routing, ledger logic, or a third-party connection | Pre-change test report linked to the change record |
| Operational risk guideline, Appendix G item 11: incident response plan tests should assess backup retrieval and manual workarounds | Restoration of payment and ledger backups, and the manual payout procedure during a primary system outage | Backup restoration and workaround test results per system |
| RPAA 18(1) and RPAR 12(1): notice to each materially affected end user through the most recent contact information | Notice triggers for outage, wrong amount received, and misrouted funds scenarios, and the contact data each trigger reads | Incident notice test log per scenario |
| Incident notification guideline 4.1: notice no later than 48 hours after the materiality decision | Elapsed time from the materiality decision timestamp to the Bank of Canada and end-user notices in simulated incidents | Notification timing log per simulated incident |
| RPAR 15(2)(b): ledger of funds held for each end user at the end of each day | End-of-day ledger balances after reversals, failed payouts, and funds in transit across the day boundary | Ledger reconciliation report per end user and business day |
| RPAR 16(1): identification of instances where end-user funds would not be payable in an insolvency | Ledger total of end-user funds compared with safeguarding account balances or insurance coverage, with injected shortfalls | Shortfall detection test results per injected case |
Artifacts the Bank of Canada requests
- The written risk management and incident response framework, with objectives, reliability targets, and indicators (RPAR 5(1)), and its senior officer and board approvals (5(6)).
- Test records with date, methodology, results, and measures taken (RPAR 9(2)).
- Framework review records (RPAR 8(3)) and independent review records, due at least every three years for PSPs with an auditor (10(1) and 10(2)).
- Incident records with root causes, impacts, measures, transaction status, and data recovery (RPAR 5(1)(i)(viii)).
- Third-party service provider assessment records with dates, scope, and findings (RPAR 5(3)(b)).
- The safeguarding-of-funds framework, the end-user funds ledger, and safeguarding review records (RPAR 15(2) and 15(7)).
- The annual report (RPAR 18 and 19) and notices of significant change or new activity (RPAR 20).
- Documents and data access during a framework assessment (RPAA 17(3)), and answers to information requests within 15 days, or 24 hours for an ongoing incident with a significant adverse impact (RPAR 43).
Common findings against the RPAA and RPAR
- Transfer status unknown after failover. Transfers submitted during a database switchover stay "pending" with no record of whether the bank file was sent. The defect breaks RPAR 5(1)(i)(vii).
- Targets never measured. The framework states a recovery time objective for card authorisation, but the annual review records no measured recovery time and does not evaluate effectiveness against that target. The defect breaks RPAR 8(2)(b).
- New payout partner without pre-change testing. A new payout bank integration goes live with no tests of the changed routing and no notice to the Bank of Canada. The defect breaks RPAR 9(1)(e) and, where the change is significant, RPAA 22(1).
- Returned payouts missing from the ledger. Payouts that the receiving bank rejects after the daily cut-off return to the operating account and drop out of the end-of-day ledger amount. The defect breaks RPAR 15(2)(b)(ii).
- Operating expenses paid from the safeguarding account. A vendor invoice job debits the safeguarding account. The defect breaks the "not used for any other purpose" condition in RPAA 20(1)(a) or (c).
- Weekend shortfall found on Monday. The shortfall check runs on business days only, so a duplicated Saturday payout batch leaves the safeguarding account below the ledger total until Monday. The defect breaks the "as soon as feasible" identification in RPAR 16(1) and departs from the daily check in Safeguarding end-user funds paragraph 4.4.
- Status page instead of direct notice. An outage notice appears only on the status page although the PSP holds affected end users' email addresses. The defect breaks RPAR 12(1)(a).
How we cover RPAA requirements
Operational resilience testing produces failover and recovery time results and third-party provider outage simulations against RPAR sections 5 and 9. Payment flow testing maps every payment state and failure path and runs settlement file and payout reconciliation checks behind the end-user funds ledger. Bank transfers and payment rails testing covers cut-off times, returns, and bank file reconciliation. Audit and certification test evidence delivers the requirement-to-test traceability matrix and a test evidence pack for a Bank of Canada assessment. Reconciliation procedures are in the ledger reconciliation testing guide.
We test RPAA requirements for international transfer products, acquiring and POS, neobanks, BaaS, business banking, AP/AR, and open banking payment initiation. FINTRAC registration is a separate obligation that the application declares under RPAA 29(1)(l); its test scope is on the FINTRAC page.
Related
Services
Segments
Adjacent standards
Questions
What is RPAA?
RPAA section 20
RPAA significant change
Scope your testing
Send FintechAssuranceLabs your product, segment, money flows, and the standards that need evidence, and get a proposed test scope with its deliverables.
Scope your testing