RPAA Operational Risk Management Framework: Preparing for Bank of Canada Supervision

A PSP can be on the Bank of Canada’s registry and still not know whether its operational risk framework would hold up in a supervisory assessment. Registration is not a licence, and it does not demonstrate that the framework meets the Bank’s supervisory expectations in practice. The application itself asks for a description of the framework the PSP has, or plans to establish and implement (RPAA s. 29(1)(i)), which is different from the Bank having assessed that framework in operation. Registered PSPs, and PSPs that have submitted an application, are already subject to the operational-risk requirements and to the Bank’s supervisory framework. Those requirements came into force on September 8, 2025.

This guide covers what the framework must contain, how it should operate, how to review and test it, and what evidence to keep. It does not re-explain who must register or how to apply. For that, see our RPAA registration process guide.

How to read this guide. We separate three levels of authority: what the RPAA or the Retail Payment Activities Regulations (RPAR) require, what the Bank’s guidelines and FAQs expect, and what we recommend as practical implementation. Practical suggestions are labelled as such. The Bank does not prescribe them.

What is the RPAA operational risk and incident response framework?

Subsection 17(1) of the RPAA requires a PSP that performs retail payment activities to establish, implement and maintain, in accordance with the regulations, a risk management and incident response framework that meets prescribed requirements. Those requirements sit in sections 5 to 12 of the RPAR. The Bank’s guideline on operational risk and incident response explains how it expects them to be met.

The framework exists to preserve the integrity, confidentiality and availability of a PSP’s retail payment activities and of the systems, data and information behind them. The RPAA defines operational risk as the risk that a deficiency in an information system or internal process, a human error, a management failure or a disruption caused by an external event will reduce, deteriorate or break down retail payment activities. An incident is an unplanned event, or series of related events, that results in or could reasonably be expected to result in that kind of reduction, deterioration or breakdown.

The two halves of the framework do different jobs. Risk management aims to stop events becoming disruptions. Incident response assumes some will happen anyway and governs detection, containment, recovery and notification. Detection links the two, so the Bank’s guideline treats continuous monitoring as part of the framework rather than as a separate IT function.

The framework covers all of a PSP’s retail payment activities and the assets and business processes involved, including work done by employees, third-party service providers, agents or mandataries. It applies wherever the PSP’s systems, data or operations are located.

Keep the regimes separate. A PSP may also be a money services business. The RPAA framework and a PCMLTFA compliance program are different obligations with different regulators.

For the perimeter question, see our guide to the MSB and PSP regimes. For the AML side, see PCMLTFA requirements in Canada.

What the Bank of Canada expects the framework to demonstrate

Read together, the RPAR and the Bank’s guideline describe a lifecycle. Response, recovery, review and testing each have their own section below. The table shows how each stage maps to legal basis and evidence.

Set objectives, reliability targets and indicators

Required: The framework must set out objectives for performing retail payment activities without reduction, deterioration or breakdown (including availability of the systems, data and information involved) and for preserving integrity and confidentiality. It must also set out clearly defined, measurable reliability targets and indicators for assessing whether each objective is met.

Bank expectation: More ubiquitous or interconnected PSPs should, at a minimum, set system availability targets, recovery time objectives, maximum tolerable downtime and recovery point objectives. The Bank measures ubiquity and interconnectedness using factors such as the number of end users, the value of end-user funds held, and the number and value of electronic funds transfers. Objectives, targets and indicators should be approved by the senior officer and the board, if any.

Practical approach: Targets that are never measured do not help. Tie each target to a data source and review it in the annual review.

Identify operational risks, assets and processes

Required: The framework must identify the assets (systems, data and information) and business processes associated with retail payment activities and classify them by sensitivity and criticality. It must identify operational risks and describe their potential causes. At a minimum, the RPAR requires coverage of business continuity and resilience, cybersecurity, fraud, information and data management, information technology, human resources, process design and implementation, product design and implementation, change management, physical security, and third parties.

Bank expectation: PSPs should identify inherent risk, meaning risk before controls. They should prioritize risks by materiality and use that ranking to decide which controls are needed. They should refresh the risk identification at least annually and after incidents. The Bank also encourages PSPs to consider concentration risk, such as reliance on one provider, system or person. Risks from planned material changes should be identified before the change is made.

Protect assets and processes

Required: The framework must describe the systems, policies, procedures, processes and controls that mitigate operational risks and protect the identified assets and processes.

Bank expectation: Protection should be risk-based and layered, so one failed control does not defeat it. The Bank recommends protective outcomes for access management (including physical access), vulnerability management and patching, security software, securely configured devices, network defences, secure cloud and outsourced IT, secure system media and secure system development. It also expects PSPs to test whether residual risk is consistent with their objectives.

Detect incidents, anomalous events and lapses

Required: The framework must describe continuous monitoring to promptly detect incidents, anomalous events that could indicate emerging operational risks, and lapses in implementing the framework. It must also include a plan for responding to anomalous events and lapses.

Bank expectation: Monitoring should cover the retail payment activities, the systems and data involved, and the protective controls themselves. The Bank’s examples of lapses include unauthorized changes to systems, misuse of access by staff or providers, missed mandatory training or approvals, and degraded controls. The escalation plan should define internal thresholds, timelines and decision-makers, and cover events at third parties and agents.

Governance and accountability

Required: The framework must allocate specific roles and responsibilities for implementing and maintaining it, both in the normal course of business and during incidents. It must also allocate responsibility for challenging and overseeing how those roles are exercised. Unless the PSP is an individual, it must allocate to a senior officer responsibility for overseeing compliance with RPAA s. 17(1), s. 18 and s. 19(3), RPAR ss. 6–10, and material decisions about identifying, mitigating and responding to operational risks and incidents.

Who can be the senior officer. The Bank’s FAQ points to the RPAR definition:

• a board member who is also a full-time employee;
• a CEO, COO, president, CRO, secretary, treasurer, controller, CFO, chief accountant, chief auditor or chief actuary, or someone performing similar functions; or
• any other officer who reports directly to the board, CEO or COO.

The senior officer need not be a direct employee of the PSP if they report directly to one of those bodies or officers, and need not be located in Canada. The Bank expects the PSP to assess whether the person has the seniority and authority for the role.

Approval. The framework must be approved by the senior officer and the board (if the PSP has one) at least once a year, and by the senior officer after each material change. The regulations do not require a board. The senior officer must also receive the findings of framework reviews (for approval), test records, independent review findings and incident information.

Bank expectations on structure. Roles should be assigned to specific positions or teams, with clear reporting lines, escalation paths and separation of duties where necessary and feasible. The Bank expects relatively more ubiquitous and interconnected PSPs to adopt a three-lines-of-defence model. For more on how that governance model works, see our guide to the Three Lines Model.

Resources. The framework must identify the human and financial resources needed, the required skills and training, and the measures for timely and reliable access to them. The RPAR also requires that everyone with a role in the framework receives the information and training they need. The RPAA imposes no capital requirement, but the Bank expects PSPs to plan for framework costs, including a buffer for incident costs. If a PSP relies on insurance or a parent’s funding for incident costs, it should be able to show how it would access those funds at the expected value when needed.

What management should be able to evidence: dated approvals, the reporting the senior officer receives, the role allocation, and the resourcing and training assessment.

Practical approach: Name a backup for each incident role. The Bank’s guideline encourages cross-training so staff absences do not leave gaps.

Building a useful operational risk register

A risk register is not a prescribed artefact. The RPAR requires the framework to identify risks and describe their causes, and the Bank expects prioritization. A register is a common way to do both. It is a practical tool, and the Bank does not mandate a format.

A register becomes useful when it connects to the rest of the framework. Practical fields:

• risk event and the payment function, asset or process affected (linked to the inventory);
• cause, using the RPAA’s four cause types (system or process deficiency, human error, management failure, external event) plus specifics;
• inherent rating, existing controls and residual rating against your objectives;
• owner, action and status;
• the indicator or target that would show the risk materializing;
• the test that exercises the control; and
• any third party involved.

The illustrative rows below use the RPAR’s risk areas. They are examples and not a checklist.

Third-party service provider risk

Who counts. The RPAA defines a third-party service provider as a person or entity that, under a contract, provides a PSP with a service related to a payment function and is not an employee, agent or mandatary. Under the Bank’s guideline this includes affiliates under contract, other PSPs (whether or not the RPAA applies to them), and providers anywhere in the world. Services only tangential to payments, such as sales, advertising, payroll or legal services alone, may be out of scope. The Bank’s FAQ confirms that financial institutions can be third-party service providers, for example where they provide accounts, safeguard funds, facilitate settlement or supply operational or technology support. Excluded entities can also be third-party service providers. Separately, the framework must address risks from all third parties, including agents, affiliates, other PSPs and clearing and settlement systems, whether or not there is a contract.

Required (RPAR 5(3)). Where a PSP receives services related to a payment function from third parties, the framework must:

• address how the PSP will assess the provider’s ability to protect data, the security of its connections, how it will inform the PSP before making changes, how its performance will be monitored (including how quickly it will report breaches or service deterioration), and its risk management practices;
• provide for those assessments at least once a year for each provider, and before entering, renewing, extending or substantially amending a contract;
• require records of the dates, scope and findings of assessments; and
• clearly allocate responsibilities between the PSP and the provider, including ownership, integrity, confidentiality and availability of data and information.

Bank expectations.

• Determine the materiality of each service and let that set the rigour of assessment and monitoring.
• Reflect the allocation of responsibilities in the contract. The Bank says contracts alone are not sufficient controls, so PSPs should add compensating controls such as monitoring financial or regulatory standing, security monitoring and testing of technical interconnections, and including the provider in testing and incident plans.
• Develop termination plans so the PSP can still meet its objectives if a provider relationship ends.
• Monitor every provider, including affiliates, at least annually even where the risk is lower.
• Do not use third parties in a way that impairs the Bank’s ability to supervise or the PSP’s ability to meet reporting and records obligations.

Accountability stays with the PSP. The August 2026 FAQ states that a PSP may take a provider’s regulatory status into account in its risk assessment, but remains accountable for the risks arising from the arrangement. A regulated bank as a vendor changes the risk assessment and does not remove the PSP’s oversight obligation. Under RPAA s. 87, a PSP is liable for violations committed by its employees, third-party service providers, agents and mandataries acting in the course of their employment, contract or authority, whether or not the individual who committed the violation is identified. When a provider reports a breach or outage, the PSP decides whether it is an incident for the PSP.

Change triggers. Starting, amending or ending a third-party arrangement, or switching cloud providers, could be a significant change requiring notice to the Bank. Information about third-party relationships is also among the registration information that must be kept up to date.

Agents and mandataries follow a parallel set of rules: the framework must set operational risk criteria they must meet before they act for the PSP (see the FAQ below).

Practical approach: Keep a provider inventory with a materiality tier, a data-flow or connection map, contract clauses mapped to the five assessment items above, an annual assessment record, tested incident contact paths, an exit plan, and a view of how many critical services sit with any one provider.

Incident response under the RPAA

There are two tracks, and they should not be confused.

• Internal handling applies to every incident.
• Bank notification applies only to incidents with a material impact.

Track 1: investigate and respond to every incident

Required (RPAR 5(1)(i)). The incident response plan must set out:

• procedures for implementing the plan and escalating, including coordination with third-party providers;
• mitigation measures, how quickly they can be put in place, and manual or alternative processes if primary systems are unavailable;
• immediate investigation on becoming aware of an incident;
• immediate measures to prevent or reduce further damage while investigating;
• measures, as soon as feasible, to fix identified root causes;
• policies for reporting and coordinating with internal and external stakeholders, including timing and information shared;
• prompt identification of the status of all transactions and recovery or correction of affected data; and
• a record of each incident: root cause and impact, mitigation measures, how it was reported and coordinated, and transaction status and data recovery.

Bank expectation. Investigation and containment begin immediately regardless of materiality. The investigation should determine root causes and the impact on retail payment activities, end users, other PSPs, clearing houses and systems. Depending on the incident, that may mean pausing activities or revoking access. After resolution, the PSP should consider lessons learned, address gaps in the plan itself and track corrective actions to completion.

Track 2: notify when the impact is material

Under RPAA s. 18(1), a PSP that becomes aware of an incident that has a material impact on an end user, another PSP (whether or not the RPAA applies to it) or a designated clearing house must notify that individual or entity and the Bank without delay.

The Bank’s incident notification guideline and its June 29, 2026 reminder add that the initial notice must be made no later than 48 hours after the PSP determines the incident is material. If an incident escalates, the clock runs from the point it is determined to be material.

The guideline’s non-exhaustive examples of potentially material incidents include:

• end-user funds becoming unrecoverably lost or permanently unavailable, other than through the end user’s own actions such as authorized fraud;
• outages materially affecting availability of payment activities, for example from technology failure, loss of a hosting provider, loss of a third party or a cyber attack;
• an insolvency event under RPAR 14(3);
• unauthorized access to confidential information creating a real risk of significant harm; and
• compromised integrity, such as a compromised ledger, transaction processing errors, misrouted funds or misdirected transfer instructions.

The PSP decides materiality based on its own circumstances.

Notices.

• Notices to the Bank go through PSP Connect. Phone is for exceptional circumstances when online submission is impossible.
• The Bank’s guideline describes initial, interim and final notices. A single notice can serve as both initial and final if all information is available within the 48 hours.
• The Bank may order follow-up notices (RPAA s. 19).
• Affected end users, PSPs and clearing houses must be notified directly using their most recent contact information, with a website notice where contact information is not available for everyone affected. Posting on social media alone is not appropriate.
• Non-material incidents are not subject to s. 18, but the Bank may still request information about them.
• If an incident also triggers privacy-law notification, the RPAA notice is still required. A single notice can serve both only if it meets every applicable requirement.

Practical approach: Because the 48-hour clock starts at the PSP’s own determination, the plan needs a named decision-maker, written materiality criteria and a timestamped materiality decision.

Pending change to watch. Amendments enacted in 2026 (S.C. 2026, c. 3, ss. 604–605) would add a further payment function covering the transmission or maintenance of an end user’s encrypted or tokenized payment instrument or private key, and would add a further category of prescribed persons to be notified under s. 18(1) for incidents relating to certain prescribed units. The Justice Laws consolidation, current to June 21, 2026, lists them as amendments not in force. They do not change s. 17 or the “without delay” wording in s. 18(1).

Hypothetical example. A payment-initiation service goes down after a hosting provider fails. The on-call engineer opens an incident record and starts containment immediately. Once the incident manager confirms that end users across the platform cannot send payments, the designated decision-maker records a materiality determination. The initial notice to the Bank and notices to affected users follow without delay and within 48 hours of that determination. The team establishes the status of in-flight transactions, reconciles after recovery, sends interim and final notices as facts develop, and keeps a record of the timeline, root cause, measures, notifications and transaction status. This is an illustration. It is not a materiality benchmark.

Testing and reviewing the framework

The RPAR creates three distinct assurance activities. “Audit” should be kept for the third.

Bank expectations on testing. The Bank expects the methodology to cover three categories: verifying and validating controls, scenario-based testing (including high-likelihood and high-impact scenarios), and testing of changes before adoption. It expects riskier and more important elements to be tested more often and in more depth. Testing should include agents and mandataries where they hold framework roles.

After a test or review. PSPs must take timely action to remedy gaps, prioritized by risk. The Bank also expects PSPs to consider whether a newly found gap was exploited before it was identified, to record the rationale for any gap deliberately left open, and to verify that planned remediation was completed.

Practical examples of useful tests (none prescribed):

• a tabletop exercise built around a material-incident scenario, including the materiality decision and the 48-hour notices;
• a recovery test measured against your recovery time and recovery point objectives;
• a control walkthrough or access review;
• a simulated third-party outage that exercises provider contact paths;
• a reconciliation or ledger-integrity check; and
• pre-release testing of a significant product change.

Significant changes and new activities

Three different concepts are easy to confuse.

The Bank’s guideline lists changes it expects to be significant, including a change in the means of safeguarding funds or a move or expansion of operations outside Canada. It lists others that could be significant depending on circumstances:

• starting or ending outsourcing;
• entering, amending or terminating a third-party agreement;
• adopting or changing technology, including switching cloud providers;
• new products or customer segments; and
• changes to the organization or staffing of functions relevant to operational risk.

Routine administrative changes are unlikely to qualify.

The notice must include the PSP’s self-assessment of risks during and after the change, whether the senior officer approved it, and a list and summary of documents amended, including any framework changes. The Bank generally does not respond to a notice, but may start an assessment afterwards.

Where a deal changes who controls a PSP, separate re-registration rules apply before closing. See our article on acquisition of control and RPAA re-registration.

Practical approach: Add a trigger question to change management: does this alter an operational risk or touch a third party, agent, cloud service or safeguarding arrangement? If yes, route it to framework review, testing, senior officer approval and a logged decision on whether a Bank notice is needed. Five business days is a minimum lead time, so start earlier.

What evidence should a PSP be able to produce?

The Bank’s guideline says PSPs must be able to demonstrate compliance on an ongoing basis, including by retaining supporting documentation, and RPAR s. 40 requires records sufficient to show how the framework was established, implemented and maintained. What the Bank asks for depends on the PSP and the assessment scope. The table is a readiness view, not a list of mandatory documents.

How Bank of Canada supervision works

The Bank’s current language is supervision, monitoring, assessment, corrective measures and enforcement. It does not describe a pass/fail audit. Searches for a “Bank of Canada PSP audit” map to assessments. The Bank also has a distinct tool it calls a special audit, where it may require a PSP to undergo an audit with a scope the Bank defines. A special audit can supplement an assessment or be requested separately.

Statutory basis. RPAA s. 17(2) allows the Bank, or a person it designates, to assess a PSP’s framework or any portion of it and to provide a list of corrective measures it considers appropriate. Under s. 17(3), the PSP must give all reasonably required assistance and provide the documents, information and access to data that the Bank or the designated person specifies.

Continuous monitoring runs on reporting: the annual report, incident notices and significant change notices. Periodic assessment tests whether the PSP meets supervisory expectations. The Bank says it will set a minimum assessment frequency and take a risk-based, proportionate approach. In the materials reviewed, it has not published a cycle for individual PSPs. Assessments may be a desk assessment (documents reviewed remotely), an on-site assessment, or a special audit.

If gaps are found, the Bank says it will inform the PSP, seek corrective measures, verify they were implemented, and take enforcement action where appropriate. Its enforcement approach is graduated. Tools include a warning letter, a compliance agreement, a Notice of Violation with an administrative monetary penalty (halved if the PSP enters the compliance agreement offered with the notice), a compliance order and court enforcement. The Bank announced in June 2026 that it will publish Notices of Violation and note them on the PSP’s registry entry. See our guide to the Notice of Violation under the RPAA and our note on the Bank’s XTM Inc. compliance order. The Bank has not described a fixed sequence, and the tool used depends on the circumstances.

Practical weaknesses to check before a Bank assessment

The Bank has not published a list of common findings in the materials reviewed. These are practical readiness checks derived from the RPAR and the guideline, and they are not Bank findings.

1. Generic framework. Language drawn from a template that never mentions your actual payment functions, providers or volumes. The RPAR requires proportionality and the Bank expects tailoring.
2. Targets that are stated but not measured. The RPAR requires measurable targets and indicators.
3. Missing or stale asset and process inventory, with no sensitivity or criticality classification.
4. A risk register disconnected from controls, indicators and tests.
5. Incomplete third-party inventory, no materiality tiers, or no annual assessment records.
6. No defined materiality decision point in the incident plan, so the notification clock has no owner.
7. Plans never exercised, or tests that exclude decision-makers, agents or key providers.
8. Annual review not recorded or approved, or records missing scope and methodology.
9. Change management not linked to framework review and Bank notices.
10. Corrective actions left open with no owner, date or rationale.
11. A framework that exists on paper but that the people who run it have not seen. The RPAR requires availability and training.

RPAA operational risk framework readiness checklist

Completing this checklist does not guarantee compliance or Bank acceptance.

Governance

☐  Senior officer designated and meets the RPAR definition

☐  Roles assigned for normal operations and for incidents, with oversight and challenge

☐  Annual approval (senior officer and board, if any) and approval after each material change recorded

☐  Senior officer receives review findings, test records, independent review findings and incident information

☐  Resourcing assessed, with backups named for incident roles

☐  Training provided and recorded for everyone with a framework role

Objectives and risk identification

☐  Integrity, confidentiality and availability objectives approved

☐  Measurable reliability targets and indicators defined and measured

☐  Asset and process inventory classified by sensitivity and criticality

☐  Operational risks identified across every RPAR area, with causes

☐  Risks prioritized and linked to controls, indicators and tests

☐  Risk identification refreshed at least annually and after incidents

Controls and detection

☐  Protective controls described for data in transit, at rest and in use

☐  Continuous monitoring covers activities, systems, data and the controls themselves

☐  Escalation thresholds, timelines and decision-makers defined

Third parties

☐  Inventory of third-party service providers, agents and other third parties

☐  Materiality assessed for each service

☐  Annual and pre-contract assessments completed and recorded

☐  Responsibilities (including data ownership) documented in contracts

☐  Compensating controls and exit plans documented

☐  Provider incident contacts and notification paths tested

☐  Agent and mandatary criteria set, with annual assessments recorded

Incident response

☐  Plan covers each RPAR 5(1)(i) element

☐  Materiality criteria and decision-maker documented

☐  Initial, interim and final notice workflow in PSP Connect rehearsed

☐  Affected-party notification contacts current

☐  Transaction status and data recovery steps documented

☐  Incident record template captures every required item

Testing and review

☐  Annual review completed and recorded

☐  Written testing methodology with frequency and scope

☐  Scenario, control and change tests run, with decision-makers and key providers involved

☐  Independent review scheduled if the PSP has an auditor

☐  Remediation tracked to closure, with rationale for any accepted gaps

Change management

☐  Change process asks whether a change is material or significant

☐  Framework review and testing occur before material changes

☐  Significant change notices filed at least five Bank business days ahead

☐  Registration-information updates handled separately

Evidence and reporting

☐  Records indexed and retrievable within Bank response times

☐  Annual report inputs gathered before March 31

☐  PSP Connect users and contacts current

When to update the framework

How ComplyFactor supports RPAA operational risk readiness

Building or reviewing the framework is a design and evidence exercise as much as a drafting one. ComplyFactor’s PSP registration and RPAA compliance support covers the work described above:

• assessing how the RPAA applies to your payment functions;
• documenting the operational risk framework, including technology and cyber risk, third-party dependencies and business continuity;
• building the incident response framework, with detection, containment and Bank of Canada notification procedures;
• setting up post-registration routines such as the annual report calendar and significant-change notification procedures; and
• registration itself where it is still required, alongside FINTRAC MSB registration and the AML compliance program for PSPs that are also MSBs.

One structural point when choosing advisers: RPAR s. 10 requires an independent review to be carried out by someone who had no role in establishing, implementing or maintaining the framework. A firm that helped design or maintain the framework cannot also be its independent reviewer.

Frequently asked questions

Is a Bank of Canada special audit the same as the independent review required by RPAR section 10?

No. They differ in who starts them, what triggers them and what they cover.

• Special audit. This is a supervisory tool. The Bank’s supervisory framework page says it may require a PSP to undergo an audit with a scope the Bank defines, either to supplement an assessment or separately, and that it will notify the PSP. The Bank decides whether and when to use it, and what it covers.
• RPAR s. 10 independent review. This is a requirement on the PSP. It applies only where the PSP has an internal or external auditor. At least once every three years, a sufficiently skilled person who had no role in establishing, implementing or maintaining the framework must review the conformity of each framework element with RPAR s. 5 and the PSP’s compliance with ss. 6 to 9, and the PSP must obtain a record and report gaps to the senior officer.

The sources reviewed do not say that a special audit counts toward the s. 10 review, or that a completed s. 10 review limits the Bank’s ability to assess or require a special audit. Plan on the basis that neither replaces the other.

Does having audited financial statements trigger the independent review?

Possibly. The independent review applies only to a PSP that has an internal or external auditor. The Bank says a PSP has an external auditor when it regularly uses one to provide independent assurance, including from a financial reporting perspective. Ad hoc use of an auditor for a specialized purpose does not count. Audits or assurance work done for other purposes, such as certifications or SOC reports, can be used only if the PSP demonstrates in writing that the scope matches the RPAR requirements. Any gap needs additional review. Confirm how this applies to your structure before relying on either reading.

What if a cloud or processing provider will not negotiate contract terms?

The Bank acknowledges that some providers use standard contracts. It still expects the PSP to manage the risk through assessment, monitoring and compensating controls. Where tailored reporting is unavailable, relying on public information or standard disclosures may be appropriate. The PSP should document the compensating controls, including where it could not negotiate particular terms.

Are agents and mandataries covered by the framework?

Yes. If a PSP uses agents or mandataries for retail payment activities, the framework must set operational risk criteria they must meet and must prohibit the PSP from using any that do not. It must also address how the PSP will assess, at least once a year, the extent to which they satisfy those criteria and their operational risk practices, and require a record of the date and findings of each assessment (RPAR 5(4)). The Bank also expects assessment before engagement and inclusion in testing where agents hold framework roles. Agents and mandataries acting within their authority do not register separately, but the PSP is liable for their violations under RPAA s. 87.

Does the framework cover marketing and corporate systems?

The Bank’s supervision applies to assets and processes associated with retail payment activities. Systems used solely for things like marketing or advertising may fall outside direct supervision. The guideline also says operational risks arising from other business activities that could affect retail payment activities should be considered. Classify by effect on payments and do not exclude a system by department.

Can testing done for SOC, ISO or other assurance work count toward RPAA testing?

It can help, but it rarely covers everything. The Bank’s guideline says a PSP may use the results of testing conducted for other purposes if they meet the objectives and outcomes of RPAR s. 9, and the PSP should be able to show the Bank how. If the scope falls short, additional testing is expected. The usual gaps are the stakeholder requirements. Section 9 requires tests that involve relevant internal stakeholders, including decision-makers and agents, and that take account of reliance on third parties, and the record must summarize how each test met those requirements. A technical or certification test often involves neither, so pair it with a scenario exercise that includes decision-makers.

Need help reviewing or building your RPAA operational risk and incident response framework? Speak with ComplyFactor about your PSP’s framework. No adviser can promise a Bank outcome, because the Bank assesses each PSP on its own facts.