Skip Navigation

Bank of Canada Releases Guidance on Retail Payments Activities Act

December 13, 2023

The Bank of Canada (BOC) has released the first segment of its long-awaited guidance in respect of the application of the Retail Payments Activities Act (RPAA), dealing with the criteria for registering payment service providers (PSPs) (Guidance). The Guidance provides insight into how the BOC interprets its mandate in respect of who is subject to the RPAA and it casts the BOC’s regulatory net very broadly. Notably, the Guidance is not open to comments or consultation.

As a reminder, the registration requirements under the RPAA will come into force on November 1, 2024. There will be a transition period between November 1, 2024 and September 7, 2025.

  • If you plan to operate as a PSP during the transition period, you are required to apply for registration by November 16, 2024.

  • If you plan to begin performing retail payment activities during the transition period, you must apply for registration with the BOC and wait 60 days before beginning to perform these activities.

  • Beginning on September 8, 2025, PSPs must be registered with the BOC before they perform retail payment activities.

All of the requirements under the RPAA, including the requirements to establish risk management and funds safeguarding frameworks, will be in force as of September 8, 2025.

Focus on “End Users”

As noted in our previous bulletins, the RPAA applies to payment service providers that perform “payment functions.” 

See our May 2021 Blakes Bulletin: Regulation of Retail Payments in Canada - The Retail Payments Activities Act Has Arrived and our November 2023 Blakes Bulletin: The Wait Is Over: Final Regulations to the Retail Payment Activities Act.

A “payment function” is defined in the RPAA to mean:

  • The provision or maintenance of an account that is held on behalf of one end user or more.

  • The holding funds on behalf of an end user.

  • The initiation of an electronic funds transfer at the request of an end user.

  • The authorization of an electronic funds transfer or transmission, reception or facilitation of an instruction in relation to an electronic funds transfer.

  • The provision of clearing or settlement services.

In discussing the concept of an “end user” the BOC notes the following:

Practically speaking, end users are the individuals or entities located at the end points of retail payment transactions. Accordingly, your end users may not be your direct customer or counterparty when an electronic funds transfer involves several PSPs.

As such, the BOC appears to be interpreting the scope of the RPAA as applicable to PSPs even where there is no direct relationship or privity of contract between a PSP and an end user. As long as there is an end user somewhere in the transaction chain, the RPAA could be applicable to the PSP. This interpretation has very far-reaching effects.

What follows is a summary of how the BOC is interpreting certain prongs of the definition of a “payment function,” and therefore, who is in scope as a PSP under the RPAA.

Provision or Maintenance of an Account

As noted above, the RPAA applies to PSPs that provide or maintain an account held on behalf of an “end user.” The Guidance provides that a PSP is deemed to be providing or maintaining an account on behalf of an end user if it stores end-user personal or financial information in relation to future electronic funds transfers (EFTs). In that regard, the Guidance provides that storage of any personal or financial information about an identifiable end user is considered storing end-user information in the context of this payment function. In this context, examples of personal information include:

  • Age, name, identification numbers, income, ethnic origin.

  • Credit records, loan recordsexistence of a dispute between a consumer and a merchant.

The Guidance provides that these examples are not exhaustive and that collecting other types of personal or financial information may constitute storing of end-user information (although the information needs to be in relation to future EFTs). In addition, as was contained in the draft guidance, it is not necessary to hold funds to maintain an account. 

Holding Funds

The guidance provides that a person is “holding funds” for an end user for the purposes of the RPAA where the PSP keeps funds at rest and available for future withdrawal or transfer by a payer or payee.

Based on the wording of the Guidance, it would appear that funds held as a security deposit  would not be in scope as the end user does not control the release of funds in these circumstances. 

In respect of the funds being “at rest,” the Guidance provides the following:

As funds must be at rest to be considered to be held, in a situation where funds are being transferred from an end user account with one PSP to an end user’s account at another PSP via intermediary PSPs, only the initial and final PSP would be identified to be holding funds, provided that funds are continuously in transit.

However, the Guidance does not address how “holding funds” is interpreted where there is no “end-user” account or where the transfer may take time to finalize. This was an area where many PSPs were looking for more definitive guidance from the BOC.

Authorization of an EFT

Interestingly, the Guidance speaks to the “authorization of an EFT” and indicates that a PSP can authorize an EFT both when sending and when receiving it, and a single transaction can have “multiple points of authorization.” The Guidance goes on to provide that authorizing an EFT includes crediting an end-user’s account in accordance with a payment instruction. This interpretation is likely not what many in the payments industry expected.

Transmission, Reception or Facilitation of an Instruction in Relation to an EFT

The Guidance provides that a PSP is transmitting, receiving or facilitating an instruction in relation to an EFT if it sends or receives payment instructions or if the PSP provides the infrastructure that enables payment instructions to be sent or received. The Guidance in this respect indicates that this can include a payment network, but the BOC’s interpretation of this provision is much broader and will include payment gateways and those that provide platforms or interfaces for payment instructions to be sent or received. In that regard, the BOC uses the following example:

For example, you could provide a service to other PSPs to enable them to easily input data fields into standardized payment instruction formats. While not directly sending or receiving a payment instruction, nor providing the main network that allows for the transmission and reception of the instruction, you would still be providing an interface that facilitates the transmission of an instruction.

The Guidance also uses the example of providing a service that notifies an individual or an entity of the status of an EFT. Again, this has very far-reaching effects in respect of who is in scope of the RPAA.

Provision of Clearing or Settlement Services

In respect of clearing, the guidance indicates that any of the following may be considered clearing services if performed in relation to an EFT:

  • Calculating final positions, which may include netting positions.

  • Transforming payment instructions from one format to another for settlement purposes.

  • Performing collection, and security and integrity checks of payment items to be settled.

  • Sorting transactions by payment instrument type or by destination (e.g., to a PSP, financial institution, network operator).

  • Transmitting final position information to relevant parties, including transmitting clearing orders to a financial institution, network operator or another settlement organization, and distributing notifications back to parties involved in the clearing process (e.g., showing amounts and settlement dates).

  • Confirming availability of funds for settlement.

In the key questions and considerations, the Guidance asks:

  • Do you provide services to payees to sort their sales information (e.g., by payment instrument or network) to submit claims to the relevant parties (e.g., respective networks, other PSPs or financial institutions)? This could be done through the software in a point-of-sale terminal or through an online platform or page.

  • Do you collect and conduct security and integrity checks of payment items to be settled?

As with the rest of the Guidance, the services which the BOC believes are in scope are broader than one would expect from the RPAA’s plain wording.

Incidental Activities

Even if a party performs a “payment function” as defined, they will not be subject to the RPAA where the payment function is “incidental” to one or more non-payment services or business activities. The concept of what constitutes “incidental” activity is therefore critical in determining if the RPAA will apply to many types of businesses that have a payment component but where payment itself is not the main activity. 

The Guidance provides some parameters of what may constitute “incidental” activity. Of relevance in that regard is the following:

  • A payment function will likely not be seen as an incidental service or business activity if it directly generates revenues or provides a PSP with a direct commercial advantage (i.e., performing the payment function enables you to sustain or grow your activities or develop a future commercial advantage.

  • End-user expectations — if an end user can reasonably expect to be receiving payment services when using or receiving the PSP’s services, this could indicate that the payment function is a distinct service and is not incidental to other non-payment service or business activity. The guidance in this regard provides that if a large number of end users expect to receive payment services when they do business with you, this is an indication that your payment services are not incidental.

  • If a PSP markets or advertises the payment functions, this may indicate that the payment function is not “incidental.” The guidance provides that:

Advertising payment services or the payment related features or benefits of products and services offered or branding or trade names that refer to payment services, or dedicating a budget to advertising or marketing of payment products or services would be factors that would be considered.

In respect of what incidental activities are, the Guidance indicates that the BOC may not necessarily give each indicator equal weight. Instead, the BOC will conduct a contextual analysis, based on the evidence and information available in each case, to determine what factors or elements are most relevant to consider. This lacks the certainty that many potential registrants are likely looking for and seems to allow for more of a subjective determination of who is in scope.

Geographic Scope

Canadian entities that perform payment functions that are not incidental or not otherwise exempt, are subject to the provisions of the RPAA. However, for those PSPs that do not have a place of business in Canada, the RPAA only applies to those PSPs that perform retail payment activities for an end user in Canada and direct retail payment activities at individuals or entities in Canada. Given the large number of PSPs that carry on business on a cross-border basis, the concept of “directing services” is important in determining whether a PSP will be subject to the RPAA.

The BOC borrows some of its guidance on “directing services” from FINTRAC’s guidance on the same topic. In that regard, the Guidance provides that a PSP will be considered to be directing retail payment activities at individuals or entities in Canada if one or more of the following applies:

  • Your business’s marketing or advertising is directed at individuals or entities located in Canada.

  • Your business operates a “.ca” domain name.

  • Your business is listed in a Canadian business directory.

  • Your business has an agreement related to retail payments in place or a working relationship related to retail payments with an individual or entity in Canada or has representatives, agents or mandataries in Canada to promote its retail payment activities.

  • Additional factors include:

    • You describe your retail payment activities as being offered in Canada.

    • You offer retail payment activities in Canadian dollars.

    • You make end-user service support available to individuals or entities in Canada.

    • You seek feedback from individuals or entities in Canada.

    • You have employees, third-party service providers, agents or mandataries in Canada that promote your retail payment activities to individuals or entities in Canada.

    • Your target market is made up of a high proportion of end users in Canada.

    • Your business operates in multiple countries and is well known in Canada.

While some of these criteria seem sensible, others are more problematic. For example, just because a company is “well known in Canada” does not mean it is directing services to people in Canada; the two are not equivalent. Similarly, seeking feedback from customers is something that all companies do as a routine matter on their websites after a service has been provided; this is also not indicative of “directing services.” Moreover, if an end user reaches out to a company and has a question or needs assistance, would the company be expected to indicate that no assistance is provided to Canadians? Again, these are common customer service practices; they do not necessarily indicate that services are being directed to persons in Canada.

Additional Resources

The Guidance links to additional resources, including the BOC’s supervisory framework for registration, a self-assessment tool for organizations to determine whether they are subject to the regime. There are also numerous "case scenarios" where the BOC considers fact patterns and indicates whether, in its view, the activities or entities under consideration are meant to be subject to the RPAA, and a set of Frequently Asked Questions, which includes additional information on the registration process. While some of the case scenarios are very informative, there are still a lot of common use cases that are not given any consideration.

For more information, please contact:

or any other member of our Financial Services group.