The RPAA application has a section for the risk-management framework. It looks like one chapter among many. It is, in practice, the chapter the Bank of Canada examines most carefully, and the most common reason a file is sent back for revisions.
Generic frameworks lifted from ISO 31000 or COSO ERM templates do not pass. Reviewers are not looking for a description of risk management as a discipline. They are looking for a framework that demonstrably governs your payment activities.
What the Bank of Canada is testing
- Whether you have identified the operational, financial, and conduct risks specific to your retail payment activities.
- Whether you have controls in place that address those risks, not in the abstract but in the operational detail.
- Whether responsibility for each control is clearly assigned and traceable.
- Whether the framework is reviewed on a defined cadence and updated when business activities change.
- Whether incidents — both financial and operational — are governed by an incident-response process consistent with the framework.
The structure that works
1. Activity inventory
Open with a precise inventory of the regulated retail payment activities you perform. Wallet provision. EFT initiation. Holding of balances. Account maintenance. Authorization or transmission of instructions. This inventory is the spine of the rest of the document — every risk and every control will reference back to it.
2. Risk identification
For each activity in the inventory, identify the relevant operational risks (technology failure, third-party dependency, fraud, processing error), the financial risks (settlement failure, liquidity, custody loss), and the conduct risks (mis-selling, fee transparency, complaint handling). Generic risks belong in an appendix. The body of this section names risks that map to your activities.
3. Controls
For each risk, describe the controls in place. The mistake here is to list a control by category ("we have monitoring") instead of by operation ("our processing system flags any transaction over $X to a destination we have not seen before; the alert is reviewed by [role] within [time]; disposition is logged"). Reviewers read controls at the operational level.
4. Governance and assignment
Name the roles responsible for each control category, not the individual employees. Show the committee structure that oversees risk. State the reporting line from the risk function to the board or equivalent oversight body. The Bank of Canada looks for an independent voice somewhere in the structure — risk reporting that flows entirely through the COO is a finding.
5. Review and update
Commit to a review cadence — annual at minimum, with event-driven updates when the business changes materially. Describe what triggers an out-of-cycle review. State who signs off on changes.
6. Incident-response
The framework's incident-response section should describe how an incident is identified, escalated, contained, communicated to affected users, and reported to regulators. RPAA registrants have specific reporting obligations to the Bank of Canada for material incidents — those obligations belong inside the framework, not in a separate annex.
What reviewers commonly send back
- Frameworks that don't name third-party dependencies. Card networks, custodians, banking partners, KYC providers, cloud infrastructure — each is a risk vector that has to be named and addressed.
- Controls described as policy, not operation. "We screen for fraud" is policy. The control is who does the screening, with what tools, on what cadence, with what escalation.
- Risk taxonomies imported from banking. Banking risk frameworks are denser than what RPAA requires and often miss the specific risks of payment processing. A focused RPAA framework is better than a generic financial-institution framework.
- Missing capital and liquidity considerations. If you hold customer funds, the framework must address how those funds are safeguarded and what happens to them in a wind-down scenario.
The shape of a clean framework
- A short document — 20 to 40 pages — that maps to your activities, not a 200-page binder that maps to a template.
- An activity inventory that matches the application's activity description word-for-word.
- Risks named at the operational level, not the discipline level.
- Controls described in terms of who, what, when, and how the result is captured.
- A governance structure with a named oversight body and a defined reporting line.
- An incident-response process that explicitly addresses the Bank of Canada's reporting obligations.