Bank of Canada Releases New Retail Payment Activities Act Supervisory Guidance
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:
Activity | Activity included in scope of the RPAA | Activity not included in scope of the RPAA |
· Payment service provider that services an online merchant: “To accept online payments from its clients, Merchant ABC Inc. enters into an agreement with Fintech DEF Inc., a financial services platform. In exchange for a merchant fee, Fintech DEF Inc. provides an application programming interface (API) that allows merchants like Merchant ABC Inc. to accept a large set of payment methods on their website and process online payments.” · Merchant activity that is not incidental: “Merchant ABC Inc. expands the functionalities of its mobile application so other merchants not affiliated with or owned by Merchant ABC Inc. can use it. As a result, other merchants or businesses can sign a contract to use Merchant ABC Inc.’s application to accept payments at their own stores. The Merchant ABC Inc. account solution now appears as an option on the other merchants’ online stores. Clients can use their Merchant ABC Inc. log-in credentials to use the information stored on their Merchant ABC Inc. account to make payments to the other merchants. In exchange, those merchants pay a transaction fee to Merchant ABC Inc. every time their customers use the mobile application as their means of payment.” | · Incidental merchant activity: “Merchant ABC Inc. sells boots online. At no additional cost, its customers can create an account to store personal information, like their name and address, to simplify future purchases. This way, they can simply log in to their account and make purchases without having to re-enter all their information.” | |
· Accounting software that includes payment services: “Company A starts offering additional services that allow its clients to initiate and accept payments. From its interface, clients can issue email invoices that include a Pay button. Company A advertises the new service under the Payments section of its website as part of a premium package with a higher monthly fee than for its basic accounting services offer. After clicking the Pay button in the email invoice, payers are redirected to a payment page powered by Company A. Transaction details are pre-filled on the page. Payers select a payment method from those offered by Company A and proceed.” | · Basic accounting software: “Company A specializes in financial software. In exchange for a monthly fee, Company A provides its client companies with an accounting software package designed to help them record their transactions and account balances. Users of Company A’s software typically include finance departments, bookkeepers and accountants. Company A stores its clients’ legal and financial information, their beneficiaries (employees, suppliers) and their revenue history. The software uses this information to draft accounting and tax-management reports that clients can use to complete their tax returns, for example. Company A also updates its clients’ transaction records using data feeds provided by their banks.” | |
· Payment terminal that is also a payment gateway: “Company A not only manufactures the POS card payment terminals, but also provides the payment gateway software to merchants. Company A directly advertises to merchants and provides its terminals in exchange for a brokerage fee on every transaction, thus competing with Company B.” | · Payment terminal manufacturer and payment gateway are two separate entities: “Company A is a manufacturer of point-of-sale (POS) card payment terminals. It designs and sells payment terminals to entities, like Company B, that provide payment processing and acquiring services to merchants. Company B enters into agreements with merchants. For a fee, merchants use Company B’s proprietary software that runs on payment terminals designed by Company A. When a payer initiates a transaction at one of Company B’s merchant clients, Company B’s proprietary software that runs its POS interface captures and packages the payment data to launch the first payment instruction for further processing. | |
· Prepaid rewards card: “Company C issues a prepaid card using a payment network processor called Rails ABC.” | · Single merchant (coffee store gift card): Coffee Shop A issues a reloadable card that customers can use to purchase goods by electronic or physical means at any of the merchant’s shops across Canada. The terms and conditions of the card state that cardholders can use the physical or digital card only to purchase goods from Coffee Shop A. · Group of merchants (transit card): “The transport operator Commute issues reloadable cards that allow card holders to pre-load funds to pay for transit fares. Commute enters into agreements with numerous local transit agencies that have decided to adopt this card system.” | |
· PSP using a designated payment system: PSP A is a fintech company that offers pre-paid accounts and payment transfer services to its clients. To receive and carry out electronic funds transfers (EFTs) from or to end users using another payment service provider (PSP), PSP A uses a system that is designated under subsection 4(1) of the Payment Clearing and Settlement Act (PCSA). PSP A maintains an account that stores end users’ personal information and the payment credentials generated for them. To send funds, clients connect to the PSP A online interface and enter the transaction details. PSP A’s website captures the information to initiate the EFT and sends a payment instruction to the designated payment system. Further processing of the transaction takes place on the designated system, with the transferee eventually receiving the funds. When one of their clients is receiving funds, PSP A makes the funds available in their PSP A account after the transfer is completed on the designated payment system. PSP A holds the funds until the client transfers further or withdraw those funds. · Designated payment system operator with multiple lines of business: In addition to the clearing and settlement services performed on its designated system, Entity XYZ starts distributing a new risk-management tool that manages rules in real time to flag or decline suspicious transactions with a high fraud risk score. It offers this service to other entities, including other PSPs, on a platform that is separate from the designated system. Clients can choose to opt-in for an additional fee. | · Designated payment system operator: Entity XYZ, owned by a group of financial institutions, operates the designated payment system used by PSP A. In operating the system, Entity XYZ performs the following retail payment functions on behalf of its members, as defined in section 2 of the RPAA: the transmission, reception or facilitation of an instruction in relation to an EFT and the provision of clearing and settlement. These are the only payment functions Entity XYZ performs. |
For more information about our firm’s Fintech expertise, please see our Fintech group’s page.
payments Fintech