Canada: Highlights From Bank Of Canada's Draft Guidance On Retail Payment Activities Act

Introduction

On February 21, 2024, the Bank of Canada (BOC) released draft supervisory guidelines (Guidelines) on the Retail Payments Activities Act (RPAA), providing insight into how they will be interpreting the requirements of the RPAA.

Some of the expectations set out in the Guidelines go well beyond what is contemplated from reading the RPAA and are quite comprehensive and onerous. Because the Guidelines will form the basis of the BOC's expectations from regulated payment service providers (PSPs) for compliance with the RPAA, PSPs subject to the RPAA must review the Guidelines and submit comments for provisions that may be problematic to implement. The comment period for the Guidelines is open until May 21, 2024.

For general information on the RPAA, please see our November 2023 Blakes Bulletin: The Wait Is Over: Final Regulations to the Retail Payment Activities Act and May 2021 Blakes Bulletin: Regulation of Retail Payments in Canada: The Retail Payments Activities Act Has Arrived.

What is clear from the Guidelines is that compliance with the RPAA will require PSPs to have extensive resources (including financial resources) to deal with the compliance obligations and expectations. As a result of the heavy compliance burden imposed and the intended costs, the RPAA will likely hinder start-ups from entering the Canadian payments space, ultimately leading to less competition and innovation.

The Guidelines released by the BOC are as follows:

• Operational risk and incident response
• Safeguarding end-user funds
• Incident notification
• Notice of significant change or new activity

These Guidelines are in addition to the BOC guideline Criteria for registering payment service providers, which was published on December 12, 2023 (please see our December 2023 Blakes Bulletin: Bank of Canada Releases Guidance on Retail Payments Activities Act) and the BOC's Step-by-Step Guide for completing a registration application that was published on February 14, 2024.

The newly published guidelines are extensive and not summarized here fully. PSPs are encouraged to review the guidelines to gain an appreciation of what the BOC expects so they are in a position to provide comments.

Operational Risk and Incident Response

The RPAA requires PSPs to establish, implement and maintain a risk management and incident response framework (RM Framework) that meets prescribed requirements designed to preserve the integrity, confidentiality and availability of PSPs' retail payment activities and the systems, data and information associated with the performance of those activities.

The Operational Risk and Incident Response Guideline (RM Guideline) sets out the BOC's expectations for this framework. Importantly, the BOC notes that PSPs will have different operational risk practices, depending on the nature and complexity of their operations, organizational structure, technology and other relevant factors. As such, the BOC expects PSPs to tailor their framework to their circumstances, accounting for these factors and the nature of the risks they face. In that regard, the BOC notes that tailoring requires "a more ubiquitous and interconnected PSP" to adopt a more "stringent" approach to operational risk management and incident response (a concept that the BOC refers to as "proportionality"). As such, the expectations on more sophisticated and established PSPs will be higher and more in line with those imposed upon financial institutions.

Documentation

The RM Guideline sets out examples of the type of documentation that PSPs should consider in documenting their RM Framework, including:

• A description of the approach to operational risk management and incident response, including references to relevant policies and procedures
• Objectives, reliability targets and indicators, and a rationale for how these were set
• Roles and responsibilities for operational risk management and incident response, including job descriptions, reporting lines and approval arrangements, organizational structures, and other documentation that specifies how the PSPs' roles and responsibilities provide for oversight and challenge
• Procedures for assessing the adequacy of human and financial resources (including the skills and training of human resources), whether the PSPs have timely and reliable access to those resources, and the outcomes of such assessments; supporting documentation includes records of staff qualifications and training provided (content, delivery, attendance, etc.)
• Policies and procedures for the identification of operational risks and descriptions of identified risks and their causes
• System documentation, including development, implementation, operation, configuration and user manuals, for systems related to providing retail payment activities or managing operational risks
• Descriptions and other supporting documentation for reviews, tests and independent reviews, including plans, dates performed, staff and stakeholders involved, scope, outcomes, follow-up actions and plans to implement those actions, and reasoning why certain actions are or are not recommended
• A rationale for approaches taken

We note that this is not BOC's full list, nor is the full list intended to be comprehensive. Again, this illustrates the depth of the expectations in respect of PSPs' RM Framework.

Roles and Responsibilities

The BOC expects PSPs to allocate responsibility and accountability for each step of establishing, implementing and maintaining the RM Framework. It also expects PSPs to assign specific roles and clearly define reporting lines and, when necessary, escalation paths for issues. There is also an expectation to respect separation of duties, if required, to ensure that an individual does not have control of a process from start to end.

PSPs are required to ensure they have adequate resources to fulfill each role and responsibility. Importantly, similar to the requirements imposed on financial institutions, the BOC notes that it expects more sophisticated PSPs to implement a "three-lines-of-defence" model.

Human and Financial Resources

In discussing the requirement to have appropriate human and financial resources to implement the RM Framework, the RM Guideline notes that while the RPAA does not impose a capital requirement on PSPs, PSPs must plan for the costs and resource requirements associated with establishing, implementing and maintaining their RM Framework. The RM Guideline goes on to provide that "this includes any buffer to cover foreseen additional costs and resource needs that might arise from an incident."

The RM Guideline also notes that where PSPs rely on financial resources or funding from a parent entity, they should consider how these resources are invested to ensure they are available, at the expected value, when required.

As such, the BOC clearly will be looking at PSPs' access to capital to ensure financial stability.

Objectives

Under the regulations to the RPAA (Regulations), the RM Framework is required to set out the following among its objectives:

• Ensuring the PSPs can perform retail payment activities without reduction, deterioration or breakdown by, among other things, ensuring the availability of the systems, data and information involved in the performance of those retail payment activities
• Preserving the integrity and confidentiality of those activities, systems, data and information

In respect of reliability targets, and consistent with the concept of proportionality, the BOC recommends that more "highly ubiquitous or interconnected" PSPs should, at a minimum, establish the following types of reliability targets:

• System availability targets
• Recovery time objectives
• Maximum tolerable downtimes
• Recovery point objectives

The RM Guideline sets out an appendix containing very detailed and prescriptive information regarding the BOC's expectations for objectives, reliability targets and indicators.

Detection

The Regulations require PSP RM Framework to describe the systems, policies, procedures, processes, controls and any other means that must be in place to ensure continuous monitoring to promptly detect incidents or other anomalous events.

The RM Guideline has a detailed appendix that sets expectations with respect to the relationship among continuous monitoring, incident detection and response and recovery.

Information Technology and Cybersecurity

Regarding information technology and cybersecurity controls, the RM Guideline recommends that PSPs establish, implement and maintain continuous monitoring and detection capabilities related to the following outcomes and concepts:

• Key indicators and internal thresholds (which, if breached, would trigger an action or decision)
• Logging and monitoring (e.g., through access logs or traffic logs)
• Network defences
• Malware detection
• Intrusion detection and prevention
• Vulnerability detection
• Security monitoring
• Physical security (e.g., through access logs)
• Threat Intelligence
• Other relevant controls

The more sophisticated PSPs are, the more robust and comprehensive these controls are expected to be.

Escalation of Incidents, Anomalous Events and Lapses in Implementation

The Regulations require PSP RM Framework to set out a plan for responding to anomalous events or lapses in the implementation of the RM Framework. The RM Guideline provides detailed expectations on what these plans should contain.

Incidence Response Plans

The RM Guideline provides detailed information on the expectations surrounding incident response plans, including that PSP policies and procedures for reporting and coordination of incident response should:

• Require PSPs to keep relevant internal and external stakeholders (including third parties, agents and mandataries) informed in a timely manner, including providing details on the incident, communications and action plans
• Provide clear guidance on and criteria for escalating incidents internally for awareness and involvement of applicable decision-makers
• Facilitate the PSPs' regulatory obligation to report certain incidents to the BOC and materially affected end users, PSPs and clearing houses of clearing and settlement systems, as required under the RPAA.

The incidence response plan should also be subject to testing.

Internal Review

The Regulations require PSPs to review their RM Framework at least once a year and before making any material changes to their operations or management of operational risks. The RM Guideline provides a detailed appendix that sets out the factors and sources of information that PSPs should consider in conducting the internal review.

Testing

The Regulations require PSPs to implement a testing methodology to identify gaps in the effectiveness of and vulnerabilities in the systems, policies, procedures, processes, controls and other means provided for in their RM Framework. The RM Guideline provides that this testing methodology must cover three broad categories of tests:

• Verifying and validating controls
• Testing scenarios, particularly those related to high-likelihood and high-impact operational risks
• Testing changes

The RM Guideline provides that within each category of testing, PSPs should use a variety of testing practices to identify gaps in the effectiveness of or vulnerabilities in the relevant system, policy, procedure, process or control. PSPs that use agents or mandataries are expected to include them in the scope of their testing.

The RM Guideline has a detailed appendix that sets out different testing scenarios and expectations.

Independent Review

The Regulations require PSP RM Framework to be audited at least once every three years. The RM Guideline provides information on the BOC's expectations in respect of these reviews, the required scope and results on the outcomes.

Third-Party Service Providers

The Regulations require PSPs to manage the risks arising from the use of third-party service providers. The RM Guideline clarifies that third-party service providers include PSP affiliates and other PSPs and applies regardless of the geographic location of the service provider.

The RM Guideline helpfully clarifies that services performed by third-party service providers that are tangential to PSP retail payment activities are not in the scope of the third-party service provider requirements (i.e., advertising/legal services).

While the RPAA generally requires PSPs to mitigate the risks associated with the use of third-party service providers, the RM Guideline provides prescriptive guidance on third-party relationships and their implementation and ongoing monitoring expectations.

In addition, the RM Guideline notes that PSPs must not use third-party service providers in a way that would impair the BOC's ability to supervise PSP compliance with the RPAA. This seems to echo the Office of the Superintendent of Financial Institutions (OSFI) third-party risk management guideline (OSFI B-10) requirement for regulated financial institutions to require their service providers to allow OSFI access to audit their practices. The RM Guideline also requires PSPs to establish, implement and maintain a formalized and documented approach to assess third-party service providers, similar to the requirement imposed on financial institutions under OSFI B-10.

There is a lot of detail regarding the BOC's expectations for outsourcing in the RM Guideline and in the appendix setting out regulatory expectations. PSPs should consider providing commentary that these requirements must not apply to service agreements executed before the RPAA comes into force.

Agents and Mandataries

The Regulations also require PSPs to mitigate the risks associated with the use of agents or mandataries and address the use of agents in their RM Framework. Similar to the expectations for third-party service providers, PSPs' use of agents and mandataries must not be conducted in a way that would "impair the BOC's ability to supervise PSP compliance with the RPAA."

The RM Guideline sets out detailed expectations in respect of PSPs' use of agents. It then goes on to provide that PSPs will need to assess an agent or mandatary before entering into an arrangement. If the outcome of the assessment is that the agent does not or will not be able to meet the PSPs' criteria, then the PSPs should not enter into or continue an arrangement with that agent or mandatary. This will require all PSPs that use agents to re-examine their agency relationships in light of the RPAA, which may prove to be a significant undertaking.

Safeguarding End-User Funds

The BOC's draft guideline on safeguarding end-user funds (Safeguarding Guideline) sets out important details regarding the fund-safeguarding requirement under the RPAA. Under the RPAA, PSPs that hold funds on behalf of end-users must safeguard those funds by segregating them and holding the funds in trust or maintain insurance or a guarantee in respect of the funds. Although the Safeguarding Guideline is granular and detailed, the following are key highlights of the issues it addresses:

• Consistent with the BOC's earlier guidance, the Safeguarding Guideline explains that PSPs are considered holding funds on behalf of an end-user (and, therefore, subject to the safeguarding requirements) if they keep end-user funds at rest and available for future withdrawal or transfer. PSPs are not considered holding funds when they pre-fund a transaction, reserve funds to mitigate credit risk or receive end-user funds concurrently with an instruction to immediately transfer the funds.
• The Safeguarding Guideline makes clear that regardless of the safeguarding option used (a trust or insurance/guarantee), end-user funds must be segregated from the PSPs' own funds and all other funds the PSPs hold and be placed in a separate account (the Safeguarding Account). Where PSPs handle client funds related to services that are not in the scope of the RPAA, those client funds cannot be held in the Safeguarding Account.
• The end-user funds must be placed into the Safeguarding Account upon receipt or no later than the end of the business day after the day of receipt.
• PSPs are expected to keep track of three categories of end-user funds: the total amount of funds that the PSPs are holding on behalf of end users, the total amount of funds that must be placed in a Safeguarding Account and the total amount of funds held in a Safeguarding Account.
• The Safeguarding Guideline clarifies that where an end user withdraws or transfers funds before the PSPs can place them in a Safeguarding Account within the timeline noted above, these funds do not need to be safeguarded, although the PSPs must still record the funds as end-user funds held on their ledger.
• With respect to the requirement to hold the safeguarded funds in a trust, the Safeguarding Guideline notes that PSPs must establish a valid express trust under Canadian law. PSPs must conduct due diligence to confirm the legal validity of the trust. In complex cases, PSPs are expected to obtain a legal opinion. The Safeguarding Guideline is silent on whether PSPs are expected to be the trustee of the trust and whether that role is compatible with other applicable legislation. For example, Ontario's Loan and Trust Corporations Act prohibits an entity, other than a trust company, from "acting as a trustee in respect of any service it provides to the public."
• With respect to the use of insurance or guarantee, the Safeguarding Guideline clarifies that a PSP is expected to account for fluctuations in the funds held in the Safeguarding Account and provide for insurance or guarantee amount that is always equal to or greater than the total end-user funds being safeguarded. The PSP must develop and apply a methodology to ensure this.
• The Safeguarding Guideline also sets out detailed expectations on the requirement for PSPs to maintain a safeguarding-of-funds framework.

Incident Notification

Pursuant to the RPAA, registered PSPs must notify the BOC and certain impacted parties without delay upon becoming aware of an incident that has a material impact on those parties. As outlined in the RPAA, these parties are:

• End users
• Other PSPs performing retail payment activities (regardless of whether the PSPs are registered pursuant to RPAA or not), or
• Clearing houses of a clearing and settlement system that is designated pursuant to the Payment Clearing and Settlement Act.

For ease of reference, we refer to the above parties collectively as the "Impacted Parties."

While the Regulations broadly outline the required contents of each of these notifications, the BOC's Incident Notification Guideline (Notification Guideline) provides some additional details related to that content and the incident reporting process and sets out the BOC's expectations with respect to PSPs' compliance with the Regulations.

PSPs are required to take immediate action to investigate, respond to and document allincidents regardless of their impact. Despite this, the Notification Guideline stresses that the Notification Obligation is triggered only when PSPs have determined that the incident's impact is material.

Material Impact

The RPAA defines an incident as "an event or series of related events that is unplanned by a payment service provider and that results in or could reasonably be expected to result in the reduction, deterioration or breakdown of any retail payment activity that is performed by the payment service provider." In the Notification Guideline, the BOC clarifies that such a decrease in performance occurs when not only the confidentiality, integrity or availability of PSPs' retail payment activities are negatively impacted, but also any related systems, data or information are similarly impacted.

While the RPAA framework requires that PSPs respond in particular ways to an incident that has a "material impact," it is silent on what makes an impact material versus non-material to parties (Impacted Parties). The Notification Guideline attempts to clarify this uncertainty by providing general examples of incidents that could have a material impact, including:

• Any loss or unavailability of any amount of an end-user's funds held by PSPs before they are withdrawn or transferred, whether such funds are stolen or inaccessible for other reasons
• PSPs' outage or slowdown in their retail payment activities, such as one of the examples noted below, and lasting for eight or more hours (an outage or slowdown occurs when any task, process or system is down, preventing PSPs from providing their retail payment activities to one or more end users, or affecting other PSPs or clearing houses)
  • Cyber-attacks
  • Loss of an infrastructure hosting service or data centre
  • Loss of a third party
  • Technology failure
• PSPs holding end-user funds that are the subject of an insolvency proceeding, as the term is defined in the Regulations
• Unauthorized access or disclosure of confidential end-user, PSP or clearing-house information, if there is a real risk of significant harm to the Impacted Parties, such as one of the examples noted below (PSPs must consider both the sensitivity or the information at issue and the probability that such information will be or has been misused):
  • Humiliation or bodily injury
  • Reputational damage, loss of employment, or business or professional opportunities
  • Financial loss or injury, such as an impact on credit records
  • Loss of property
• Incidents that compromise the integrity of PSPs' retail payment activities, including incidents that compromise essential components of a payment activity, such as ledgers or transaction records (transaction errors, incorrect routing, misdirected payment instructions, and clearing and settlement miscalculations can also have a material impact)

Incident Reporting

Timing

Under the RPAA, PSPs must report incidents with a material impact to the BOC and the Impacted Parties without delay after becoming aware of the incident. The Notification Guideline clarifies that "without delay" means no later than 24 hours from the point at which an incident is determined to be material. For incidents that do not meet the materiality threshold when they are first detected but progress to having a material impact, reporting must occur without delay once meeting the threshold but no later than 24 hours from the point the threshold is met.

Notice to the BOC

Building on the reporting requirements set out in the Regulations, the Notification Guideline includes additional detail related to PSPs' description of the incident, including:

• The date and time the incident started, was detected and resolved
• If it differs from the starting date, when the incident was determined to have a material impact
• How the incident was detected
• A description that includes additional specific issue details and which retail payment activities have been impacted
• Details related to the actual or estimated size of the incident's impact on the Impacted Parties (e.g., the number of impacted end users)
• An explanation of the response measures that were taken

Pursuant to the RPAA, the BOC may order the issuance of follow-up notices if it determines that more information is required or should be reported to other entities or individuals. In some cases, more than one follow-up notice may be required.

These follow-up notice orders will set out to who should receive the notice, when and how it must be given, and what information it must include. Its precise contents will depend on the type of incident at issue.

Notice to Impacted Parties

With respect to notifying the Impacted Parties, the Notification Guideline repeats the requirements set out in the Regulations, namely that the notice must be sent to the most recent contact information of the Impacted Parties that have provided their contact information to the PSPs. Additionally, for Impacted Parties that cannot be contacted, the PSPs must publish a notice on their website.

The Notification Guideline also clarifies the BOC's expectations for PSPs required to notify the Impacted Parties. For example:

• PSPs are encouraged to maintain current contact information for each end user, PSPs and clearing houses to which they are connected.
• As with notices to the BOC, notices to Impacted Parties should be provided without delay but no later than 24 hours from the incident's detection.
• Notice must be provided directly to the Impacted Parties, other than via social media because the BOC does not consider it an appropriate form of notification.

The Notification Guideline also clarifies that PSPs that are themselves Impacted Parties must notify their end users if they are also materially impacted by the incident.

The content of the notice is substantially similar to that sent to the BOC, with some differences. For example, details related to PSPs' detection measures are not required. However, PSPs are required to set out corrective measures that materially impacted parties can take to mitigate any adverse effects of the incident.

Other Reporting Obligations

Finally, the Notification Guideline notes that PSPs' reporting obligations may not be restricted to those set out in the RPAA framework. For example, PSPs may have additional obligations as clearing-house participants. A clearing house may require PSPs to provide incident reports for different circumstances. It may choose to receive reports under the RPAA framework or require PSPs follow a different reporting process for the same incident. Additionally, an incident could also have reporting implications under federal or provincial privacy laws. Regardless of whether PSPs are required to file additional reports, the Notification Guideline stresses that fulfilling such other obligations does not relieve PSPs of their Notification Obligations under the RPAA.

While the incident response and notification obligations under the RPAA framework were lacking sufficient details, the types of incidents identified in the Notification Guideline as having potential material impacts is concerning. This is particularly true given the Notification Guideline's virtual silence in setting out the range of incident impacts that the BOC would consider "material" when listing various incidents.

For example, the BOC notes that transaction processing errors or incorrect routing could be considered incidents having a material impact. However, in setting out this example, the Notification Guideline does not describe the impact of these errors on various parties. Could isolated transaction-processing errors be considered an incident that triggers an obligation to notify the BOC? Or is the materiality threshold crossed when the processing errors become systematic in nature? Additionally, while end-user-fund safeguarding is a cornerstone of the RPAA, are PSPs expected to report to the BOC any incidents where end-user funds are stolen from the PSPs themselves? Or are PSPs intended to cover all instances of theft, including instances when an end user loses their access credentials or is the victim of fraud?

As currently drafted, the Notification Guideline considers severity only in the context of a breach of confidential information and an assessment of significant harm. It would be helpful to see similar discussions of severity throughout the Notification Guideline. Absent a more detailed discussion of materiality, PSPs may find themselves reporting a vast range of irregularities to both the BOC and potentially impacted parties.

Notice of Significant Change or New Activity

Finally, the BOC's Notice of Significant Change or New Activity Guideline (Change Guideline) provides the BOC's expectations regarding the notification requirements set out in the RPAA and Regulations.

The RPAA and the Regulations require PSPs to notify the BOC at least five business days before the PSP "makes a significant change in the way it performs a retail payment activity or before it performs a new retail payment activity." The RPAA provides that a change will be considered significant if "it could reasonably be expected to have a material impact on operational risks or the manner in which end-user funds are safeguarded."

The Change Guideline provides several examples of changes that could qualify as significant and, therefore, require notification. However, as with the Notification Guideline, there is inconsistency throughout the Change Guideline in terms of applying a materiality threshold. Although the RPAA provides that a change will be considered significant if it would have a material impact on the operational risk of PSPs or how end-user funds are safeguarded, only some of the examples given in the guideline are qualified by materiality. These changes include entering, amending or terminating an agreement with a third-party service provider, changing a technology or adopting a new technology.

Examples that are not qualified by materiality include starting or ceasing to outsource an activity related to the provision of a retail payment activity or ceasing to use an agent or mandatary, which suggests that the BOC expects to be notified of all such changes, even if they are immaterial.

The Change Guideline specifies that changes of an administrative nature would not generally be considered significant (e.g., updating contact information in an incident response plan), subject to the requirements in the RPAA to provide notification of changes to certain information that PSPs would have provided during the registration process.

The Change Guideline also clarifies that the BOC will not approve or deny changes to PSPs' retail payment activities, but if it identifies compliance gaps related to the changes as part of a subsequent review, the PSPs will be expected to address such gaps.

For permission to reprint articles, please contact the Blakes Marketing Department.

© 2020 Blake, Cassels & Graydon LLP.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.