On December 12, 2023, the Bank of Canada published new supervisory guidance (the Guidance) to support Payment Service Providers’ (PSPs) compliance with the Retail Payment Activities Act (the Act) and regulations.

The Guidance includes guidance on criteria that potential PSPs should consider when evaluating whether the payment function they offer might be subject to the RPAA, thereby necessitating a registration, as well as guidance on the registration application fee.

Criteria for Registering PSPs

A. Further Guidance on Payment Functions

The Guidance provides further detail on when the relevant payment functions under the RPAA are engaged:

1. Provision or Maintenance of an Account

As noted in the Guidance, “[y]ou are providing or maintaining an account on behalf of an end user if you store end-user personal or financial information in relation to future [electronic funds transfers (EFTs)]”

The Guidance further states that “[s]torage of any personal or financial information about an identifiable end user is considered storing end-user information in the context of this payment function.” An entity is considered to be storing such information in relation to EFTs “as soon as one of [the] purposes [of storing information] is to conduct future electronic funds transfers”. 

The Guidance also specifically states that “you do not need to hold funds to maintain an account.”

2. Holding Funds

The Guidance notes that this payment function includes:

• “services where end users can withdraw their funds or make a fund transfer at a future point in time (e.g., neobank services or other services where end-user funds are placed for a period)
• funds received from a payer that are held for a payee to transfer or withdraw at a future date
• funds that are awaiting action by a payee to complete the transfer”

The Guidance notes this excludes “single payments where funds cannot be used for future transfers or withdrawals” and “funds in transit (whether passing through other PSPs, financial institutions or payment systems)”. In addition, “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.”

3. Initiation of an EFT

The Guidance notes that “[y]ou are initiating an EFT if you are the individual or entity that launches the first payment instruction enabling an EFT requested by a payer or payee”, which can be done either through a push payment or a pull payment. 

Here, “[t]he first instruction in an EFT includes any electronic information—financial or otherwise—necessary to carry out a payment” and the “critical identifying features for the initiation function relate to the content of the data and the sequence of the instruction in the payment chain.” In particular, “[w]hat distinguishes the initiation function from other functions is the creation of the first instruction.”

4. Authorization of an EFT or Transmission, Reception or Facilitation of an Instruction in relation to an EFT

Authorization of an EFT

The Guidance states that authorization of an EFT occurs when you:

• “request that an end user confirm sending or receiving an EFT
• confirm whether the end user has sufficient funds to make the requested EFT
• have established an arrangement with an end user to send or receive an EFT without requiring the end user to take an action (i.e., pre-authorized payments)
• debit or credit an end user’s account according to the payment instruction associated with an EFT”

The Guidance also notes that “a single transaction can have multiple points of authorization.”

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

The Guidance provides that this payment function is engaged “if you send or receive payment instructions or if you provide the infrastructure that enables payment instructions to be sent or received. The set of actions undertaken in relation to this element of the payment function is broad and can encompass almost any handling of payment instructions outside of instructions being sent to initiate or authorize an EFT.”

The Guidance also provides that “[g]enerally, you transmit, receive or facilitate an instruction in relation to EFT if you:

• send a payment instruction to another individual or entity to take an action in relation to an EFT
• receive a payment instruction from another individual or entity to take an action in relation to an EFT
• provide a platform, network or any other type of infrastructure that enables, facilitates or supports sending and receiving payment instructions”

The Guidance provides a number of examples when this payment function may be engaged, such as:

• “[sending or receiving] payment instructions (…) to transform it (e.g., by encryption or tokenization) or to simply pass it on to another individual or entity to push the EFT to the next stage in a payment chain”,
• “[providing] a network that other individuals and entities such as PSPs and financial institutions can connect to and send and receive payment instructions in relation to EFTs”, or
• “[providing] an interface or platform built to enable other individuals or entities to access or use a third-party network where instructions are sent or received.”

5. Provision of Clearing or Settlement Services

Clearing

The Guidance defines “clearing” as “the process of transmitting, reconciling and, in some cases, confirming transactions prior to settlement, potentially including the netting of transactions and the establishment of final positions for settlement.”

• “Settlementis the discharge of an obligation in accordance with the terms of the underlying contract.”

The Guidance provides that “[y]ou are performing this payment function if you provide clearing services to another entity” and provides the following examples:

• “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”

That said, the Guidance also clarifies that “You may provide services (e.g., to merchants) that are similar to the activities described above but that are not a precursor to the settlement of payment obligations. For example, you could provide software used by merchants only for accounting purposes or software that solely facilitates data analysis and reporting about their business transactions. In theses cases, you would most likely not be performing this payment function.”

Settlement

The Guidance defines “settlement” as “the discharge of an obligation according to the terms of the underlying contract.”

The Guidance states that you “perform this payment function if you are an individual or entity that provides settlement services to other entities (which can include other PSPs): for example, settling on behalf of other entities by acting as settlement agent in connection with a clearing and settlement system” and provides the following examples:

• “posting credits and debits in an entity's account (which may or may not be followed by posting credits and debits in an end user’s account maintained by that entity)
• account adjustment”

B. Further Guidance on “Incidental Activities”

The Act excludes certain retail payment activities considered incidental to another service or business activity that is not a payment function.

The Guidance sets out a number of considerations to determine whether an individual or entity is performing payment functions that are “incidental” to one or more non-payment services or business activities:

• Identifying the business activities and services - The Guidance highlights that individuals or entities that perform payment functions as their only service or business activity will be considered a PSP according to the definition in the RPAA. However, if the individual or entity performs any of the five payment functions as a service or business activity and one or more non-payment services or business activities, further criteria listed below should be assessed to determine whether the payment functions are incidental.

The Guidance provided the following scenarios as examples of entities that fall within the definition of a PSP under the RPAA:

• Online payment service whose only business is to enable users to transfer funds to each other for a fee.
• A company whose only business is to process retail payment transaction electronically on behalf of merchants for a fee.
• Assessing the relationship between the payment functions performed and any non-payment service or business activity provided - The Guidance notes that individuals and entities are unlikely to be considered as PSPs when its payment functions only serve to directly support the provision of non-payment service or business activity and are not performed as distinct service or business activity. The Guidance considers a payment function to be more likely to be incidental when it is performed exclusively to sell an entity’s own products and services that are not themselves payment related.

The Guidance provides as an example of a retail payment activity not considered as incidental to another service or business activity, a company that has two business lines from which it generates revenues, which consist of processing payment transactions electronically for merchants and creating promotional material for merchants. In this case, its payment processing business could not be incidental to its promotional material business, as the former business line does not support or enable the provision of the latter (even if the company may package the services together for some clients).

Indicators to Consider

The Guidance presents a non-exhaustive list of indicators to be taken into account when examining the particulars of an individual or entity's business to determine if they engage in payment functions as an incidental service or business activity, including:

• Revenues or commercial advantage: A payment function is less likely to be incidental if it directly generates revenues or provides a direct commercial advantage, extending beyond immediate revenue or profits. The Guidance also advises considering the comprehensive benefits derived from payment services, acknowledging that less tangible benefits such as data monetization may also classify the payment function as a distinct service or business activity.
• End-user expectations: If end users reasonably expect or understand that they will receive payment services when the offered services, this suggests that the payment function is distinct and not incidental to other non-payment activities. The Guidance acknowledges that individual perceptions or expectations may vary, however a ‘large number’ of end users expecting payment services is an indication that such services are not incidental.
• Marketing/ advertising: Marketing or advertising of payment functions can indicate that the payment functions are performed as a separate service or business activity and therefore not considered to be incidental. Examples of advertising or marketing of a payment function include:
  • Advertising the payment services or the payment related features or benefits of the products and services offered.
  • Branding or trade names that refer to payment services, for example in the name of the entity, products, services or activities.
  • Dedicating a budget to advertising or marketing of the payment products or services.

The Guidance indicate that payment functions will be assessed by the Bank of Canada based on the specific circumstances of each case. This involves a contextual analysis, where indicators are not necessarily given equal weight. The Bank may also prioritize certain indicators, assess based on a subset or even a single indicator, and consider precedents from previous assessments.

The Guidance underscores that businesses should continually monitor and self-assess, as changes in its business model or operating structure could affect previous assessments of its payment function.

C. Further Guidance on Geographic Scope

The RPAA applies to entities performing in-scope functions where either:

• The business has a place of business in Canada – This includes having a physical location in Canada (including a home office), being incorporated in Canada, or having employees, agents or mandataries in Canada.
• The business does not have a place of business in Canada, but performs retail payment activities for an end user in Canada and direct these activities at individuals or entities in Canada.

Performing retail payment activities in Canada

In determining whether an entity is performing retail payment activities in Canada, the Bank will look to the following factors:

• the actual location of the end user and whether they are physically present in Canada.
• whether the end user’s IP address at the time the payment function was performed is in Canada.
• whether the shipment address of the goods or the address where services are provided is in Canada.
• whether the end user’s payment product or service (e.g., banking services; debit, prepaid, or credit card; or payment processing service) is localized for the Canadian market.

Directing retail payment activities at individuals or entities in Canada

In determining whether retail payment activities are being directed at individuals or entities in Canada, the Bank will look to the following factors:

• Whether marketing or advertising is directed at individuals or entities located in Canada.
• Whether the business operates a “.ca” domain name.
• Whether the business is listed in a Canadian business directory.
• Whether the 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.

This is not an exhaustive list and additional criteria may be considered. The Guidance contains additional factors that may be considered as well.

• The businessdoes not have a place of business in Canada but plans to expand into Canada. The Guidance states that such businesses may engage in marketing prior to registering but would need to register before they start performing retail payment activities for end users in Canada.

Plans to expand into Canada

The Guidance states that businesses that plan to expand into Canada can engage in marketing or advertising to assess demand prior to registration but that registration is required before the business starts performing retail payment activities for end users in Canada.

The Guidance includes some specific case scenarios on geographic scope.

D. Agents and Mandataries

The Guidance provides that an agent or mandatary in the context of the RPAA is “an individual or entity that performs retail payment activities within the scope of its authority as agent or mandatary of a registered PSP.”

Generally, the RPAA does not apply to agents or mandataries, but PSPs are responsible for ensuring the agents and mandataries it uses are in compliance with the RPAA and will be liable for any violation committed by its agents and mandataries acting within the scope of their authority as agent or mandatary. A registered PSP must provide all information about its agents and mandatories as part of the registration application, and must notify the Bank on changes to those information.

However, there are certain exceptions where an agent or mandatory may be required to register as a PSP under the RPAA:

• An agent or mandatory performs retail payment activities beyond the scope of its agency relationship it has with a registered PSP. However, the obligations applicable under the RPAA shall only apply to activities conducted outside its role as an agent or mandatory.
• An agent or mandatory of an excluded PSP (such as a bank, or provincially regulated financial institution) performing retail payment activities is required to register as a PSP under the RPAA.

The Guidance includes some specific case scenarios on agents and mandataries.

E. Affiliated Entities

The RPAA requires that an affiliated entity that is (i) a PSP; (ii) performs retail payment activities; and (iii) not excluded from the application of the RPAA, must register even if another entity affiliated with it had registered. The Guidance provides that subsidiaries may be required to register separately even if their parent organization is already registered under the RPAA. Detailed information about affiliated entities will be required to be disclosed during the registration process under the RPAA.

The Guidance includes some specific case scenarios on affiliated entities.

F. Case Scenarios

As noted above, the Guidance includes a number of case scenarios to illustrate Bank of Canada’s interpretation of when certain activities may be included or excluded from the RPAA. We have outlined some of the industry or business model focused scenarios below:

For more information about our firm’s Fintech expertise, please see our Fintech group’s page.