Criteria for registering payment service providers

Publication date: December 12, 2023

This supervisory policy helps individuals and entities determine if they are subject to the Retail Payment Activities Act and if they should register with the Bank.

Introduction

The Bank of Canada is responsible for the supervision of retail payment service providers (PSPs) for compliance with the Retail Payment Activities Act (RPAA). One fundamental requirement of the RPAA is that a PSP must register with the Bank before it performs any retail payment activities. The Bank has published this guidance to explain how a potential PSP should assess whether it falls under the RPAA and should therefore submit an application for registration.

The RPAA requires you (individual or entity) to register with the Bank if all four of the following statements are true.

You are a PSP

You perform one or more of the five payment functions identified in the RPAA as a service that is not incidental to any non-payment service or business activity.

You perform retail payment activities

You perform a payment function related to an electronic funds transfer (EFT) that is made in a fiat currency or a prescribed unit.

Your payment activities fall under the geographic scope of the RPAA

You either:

• have a place of business in Canada, or
• you both direct services at, and perform services for, individuals or entities in Canada

You or your retail payment activities are not excluded from the RPAA

The RPAA excludes certain individuals or entities and activities from its application:

• Banks, authorized foreign banks, and provincially-regulated trust companies are among the list of individuals or entities that are excluded from the application of the RPAA.
• Incidental activities, securities related transactions, and internal and closed loop transactions are among the list of activities that are excluded from the application of the RPAA.

This registration criteria guidance describes the four-step application test that will help you to determine if the RPAA applies to you and if you should register with the Bank.

Step 1: Are you a payment service provider?

The RPAA defines a PSP as “an individual or entity that performs payment functions as a service or business activity that is not incidental to another service or business activity.”

Payment functions

Section 2 of the RPAA defines five payment functions. You may need to register with the Bank if you perform at least one of the following functions:

• provision or maintenance of an account that is held on behalf of one end user or more
• holding funds on behalf of an end user
• initiation of an electronic funds transfer at the request of an end user
• authorization of an electronic funds transfer or transmission, reception or facilitation of an instruction in relation to an electronic funds transfer
• provision of clearing or settlement services

Provision or maintenance of an account

You 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 EFTs.

Simply collecting the information does not automatically mean that you provide or maintain an account. If you collect the information to conduct only a single transaction and do not store it for future EFTs, you are likely not providing or maintaining an account.

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. Personal and financial information can consist of any factual or subjective information, recorded or not, about an identifiable individual.1

Examples of personal information include:

• age, name, identification numbers, income, ethnic origin
• credit records, loan records, existence of a dispute between a consumer and a merchant

Examples of financial information include:

• payment instrument (e.g., credit card number)
• funds (e.g., account balance) and transaction history
• account information (e.g., account number, routing number)
• credit rating2

These examples are not exhaustive, and other types of personal or financial information may be collected.

To be considered performing this function, the storage of the end-user information must also be for the purpose of conducting future EFTs. An individual or entity may store end-user information for various purposes. But as soon as one of these purposes is to conduct future electronic funds transfers, you are performing this payment function.

In most cases end users will have direct access to their account (e.g., by logging in to view their balance or conduct payments). However, you could perform this payment function even if end users do not have direct access to the account (e.g., there is no portal or page that allows the end user to log with credentials).

While you must maintain an account to hold funds, you do not need to hold funds to maintain an account.

It is possible that you provide or maintain an account incidentally to another business or service. This can affect whether you are considered a PSP under the RPAA.

For more information on the topic of payment functions that are incidental to another activity, refer to the section on incidental activities.

Key questions and considerations

Ask yourself the following two assessment questions to help evaluate whether you perform the payment function of provide or maintain an account. If you answer yes to both assessment questions, then you are likely providing or maintaining an account.

1. Do you store end-user information (personal or financial information)?
   • Is the information collected and kept for only a single transaction, or is it retained after the transaction has been conducted?
2. Is the end-user information stored to perform future EFTs? (i.e., is the account provided or maintained in relation to EFTs?)
• Do the reasons for storing end-user information include to conduct future EFTs, and not merely to offer other services or for other regulatory purposes?

Holding funds

You are holding funds on behalf of an end user if you keep funds at rest and available for future withdrawal or transfer by a payer or payee (i.e., end-user). The payer is an initial end user who places funds with you, and the payee is an end user that receives funds. The payer and payee could be the same individual or entity.

If the funds of a payer can be transferred or withdrawn later, then you are holding the payer’s funds (in other words, you perform this payment function). If you receive funds transferred from another PSP for one of your end users, you are holding funds if you maintain the funds until the payee withdraws or transfers them.

You begin holding funds when an end user places funds into an account with your entity. The withdrawal or transfer takes place when the payer or payee instructs you to immediately transfer or withdraw the funds or, for pre-authorized transfers, when the set transfer date arrives. Upon receipt of an instruction or the arrival of the transfer date, you have stopped performing this payment function.

Holding funds 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

Holding funds excludes:

• single payments where funds cannot be used for future transfers or withdrawals
• funds in transit (whether passing through other PSPs, financial institutions or payment systems)

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.

Key questions and considerations

Ask yourself the following two assessment questions to help evaluate whether you perform the payment function of holding funds. If you answer yes to both assessment questions, then you are likely holding funds.

1. Are you indebted to a payer or payee while their funds are with you (e.g., are the end-user funds credited into your account)?
   • Are the funds given to you, or do they simply pass through you?
   • Is there explicit (e.g., in contract) or implicit (e.g., in expectation, common understanding of the arrangement) indebtedness?
   • When you receive funds, are they always transferred immediately?
2. Are the funds with you for EFTs or withdrawals in the future?
   • Can the end user choose to transfer or to withdraw funds (this could include withdrawal by the end user who gave them to you or withdrawal by a payee)?
   • Are the funds placed with you awaiting a transaction dated in the future?

Initiation of an electronic funds transfer

You 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. Launching the first payment instruction is the process that triggers the EFT, and this can be done either as part of a push or pull payment.

• A push payment is a payment sent by a payer. It requires the payer’s consent to send the desired payment from their account into the payee’s account. The individual or entity that launches the payment instruction for the payer initiates the EFT.
• A pull payment is a payment requested by a payee. It allows payees to take agreed upon funds from a payer’s account and deposit them into their own. These payments are common for subscriptions and recurring monthly bills. The individual or entity that launches the payment instruction requested by the payee initiates the EFT.

The first instruction in an EFT includes any electronic information—financial or otherwise—necessary to carry out a payment. While many instructions can be processed throughout an EFT, 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.

• Content of the data: The initiator is the individual or entity responsible for capturing data inputs from a payer and payee at the onset of a transaction. The content of the data typically includes:
  • an end user’s credentials (e.g., the payer’s information and information related to their mean of payment, the payee’s information, etc.)
  • the details of the transaction (e.g., the sum of the EFT, its currency, the transaction type (e.g., debit vs credit), etc.).
• Sequence of the instructions: Once the data inputs are captured, the same individual or entity is responsible for packaging the data and creating the first instruction. For any particular transaction, only one individual or entity performs initiation. What distinguishes the initiation function from other functions is the creation of the first instruction.
  
  After the data are captured and packaged, the initiator may process the first instruction itself, for example by verifying the credentials and requesting to transfer funds. Alternatively, the initiator could securely route the instruction to another entity, including a PSP, to further process it (this would then become part of another payment function(s), such as the authorization of an EFT and transmission, reception or facilitation of an instruction in relation to an EFT).

Key questions and considerations

Ask yourself these two assessment questions to help evaluate whether you perform this payment function. If you answer yes to both questions, you are likely initiating an EFT.

1. Do you allow a payer or payee to launch an EFT?
• Do you provide or operate a software, interface or platform that launches a payment instruction, either as a push or pull payment?
2. Are you the first one responsible for capturing and packaging EFT data?
   • Are you responsible for capturing data from an end user’s credentials and on the details of the funds transfer request?
   • Are you responsible for packaging that data into the first instruction, before the transaction is completed?

Authorization of an EFT or the transmission, reception or facilitation of an instruction in relation to an EFT

This payment function can be divided into two elements:

• the authorization of an EFT; and
• the transmission, reception, or facilitation of an instruction in relation to an EFT.

If you undertake any of these actions, you are performing this payment function.

Authorization of an electronic funds transfer

You authorize an EFT if you establish whether an EFT can be performed. This payment function includes enabling end users—or a third party acting on their behalf—to give or withhold consent to send or receive an EFT.

Generally, you authorize an EFT if 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

You can authorize an EFT both when sending and when receiving it. Note that a single transaction can have multiple points of authorization. For example, you can request one end user to confirm that an EFT can be sent while requesting another end user to confirm that it can be received.

You may also establish an arrangement with an end user to automatically approve an EFT to be sent or received. In this case, you may not be prompting an end user to confirm whether an EFT can be sent or received for every single transaction. The arrangement itself would be the indication that you perform the authorization of an EFT.

Similarly, there are likely multiple individuals or entities that authorize an EFT in a single payment transaction. For example, one entity could request authorization from an end user at the point of sale to confirm that an EFT is requested, while another entity who maintains the end user’s account could authorize the account to be debited for the purpose of that same EFT.

Transmission, reception, or facilitation of an instruction in relation to an electronic funds transfer

You are transmitting, receiving or facilitating an instruction in relation to an EFT 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.

Generally, 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

To put this into context, an individual or entity that sends or receives payment instructions could be receiving a payment instruction 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. For example, you could send a payment instruction to another individual or entity who holds an end user’s funds in an account (e.g., a financial institution or a PSP) to transfer funds from the end user’s account to another account.

While a payment instruction may include information related to the authorization of the transaction, the authorization process discussed earlier takes place only at the distinct point(s) in the transaction when the end user gives, or gave, their consent for the EFT.

Transmitting, receiving or facilitating an instruction in relation to an EFT also includes providing the underlying infrastructure for payment instructions to flow through, thereby enabling the instructions to be sent or received between the parties in a payment transaction. For example, you could provide 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.

You can facilitate an instruction in relation to an EFT without necessarily being the one providing the network or infrastructure through which the payment instructions are sent and received. This would be the case if you provide 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. 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.

Finally, you could transmit, receive or facilitate payment instructions in relation to an EFT in addition to carrying out other payment functions such as initiating an EFT. For example, you could both initiate an EFT and send or receive payment instructions in relation to that EFT. You could also both receive a payment instruction and confirm (authorize) that the end user has sufficient funds to make the EFT according to the payment instruction.

Key questions and considerations

Authorization of an electronic funds transfer

Ask yourself the following assessment questions to help evaluate whether you authorize EFTs. If you answer yes to one of these questions, you are likely authorizing EFTs.

1. Do you directly enable the end user, or a third party acting on their behalf, to give consent to send or receive an EFT?
   • For example, do you ask an end user to confirm their request to send or receive an EFT or receive an end user’s approval to send or receive an EFT?
   • In some cases, you may not formally ask end users to confirm their request to make an EFT but still be performing an authorization. For example, this confirmation could be implied or understood when end users are prompted with a message asking them if they want to make a payment on a device, such as a point-of-sale terminal, and the end users proactively tap their payment card or phone to proceed with that payment.
   • In other cases, you may send the end user a prompt to formally confirm the payment transaction before fully processing the payment request.
2. Are you the individual or entity that confirms whether an end user has sufficient funds to make the EFT according to the payment instruction?
   • A first entity may be sending a payment instruction to confirm availability of funds, but if the end user holds their funds in an account provided by another entity, such as a financial institution or another PSP, it is often this second entity that authorizes the transaction by confirming whether the end user has sufficient funds.
   • While a payment instruction may include information related to the authorization of the transaction, the authorization process takes place only at the distinct point(s) in the transaction when the end user actually approves the EFT or when an action is taken to determine that an EFT is made (e.g., the sufficiency of funds is confirmed).
3. Are you able to debit or credit an end user’s account following a payment instruction or otherwise?
• If you provide the account where the end user holds their funds you are likely the one debiting or crediting the end user’s account.
• In some cases, however, you may be granted authority to debit or credit an end user’s account that is provided by another individual or entity (such as a financial institution or a PSP).
4. Do you have a pre-authorization agreement (or arrangement) with an end user that does not require the end user to confirm or approve each EFT?
• While the end user may not be approving an EFT every time an EFT is requested, you could be pre-authorized to carry out “authorization” activities on behalf of the end user under pre-defined circumstances.
5. Do you have an agreement with an end user to credit or debit the amount of funds held in the end user’s account that does not require the end user to approve each amount that is credited or debited below a certain threshold?
• While the end user may not be approving an EFT every time an EFT is requested, you could be pre-authorized to carry out “authorization” activities on behalf of the end user under pre-defined circumstances.

Transmission, reception, or facilitation of an instruction in relation to an electronic funds transfer

Ask yourself the following assessment questions to help evaluate whether you may transmit, receive or facilitate instructions in relation to an EFT. If you answer yes to one of assessment questions 1 to 4, you are likely transmitting, receiving and facilitating an instruction in relation to an EFT. If you answer yes to question 5 only, you may not be transmitting, receiving or facilitating an instruction.

1. Do you send payment instructions to another individual or entity in relation to an EFT?
2. Do you receive a payment instruction from another individual or entity in relation to an EFT?
• Sending and receiving payment instructions can take place multiple times throughout a payment transaction. An entity that sends payment instructions is likely to also receive payment instructions.
• There may be multiple individuals or entities involved in a payment transaction, and most, if not all of those individuals or entities may be sending and receiving payment instructions to complete that transaction.
3. Do you provide a network or the infrastructure through which payment instructions are sent or received to conduct EFTs? (e.g., credit and debit card networks).
4. Do you provide a platform or interface to end users that other individuals or entities, including PSPs, can access or use to send or receive payment instructions in relation to an EFT?
5. Do you provide a service that notifies an individual or an entity of the status of an EFT?

Provision of clearing or settlement services

This payment function consists of providing services that may be categorized as either of the following two separate but interlinked activities in relation to an EFT.

• Clearing is 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.
• Settlement is the discharge of an obligation in accordance with the terms of the underlying contract.

Clearing

Clearing is a precursor to settlement. It involves preparing and calculating payment obligations that need to be settled and exchanging information to support the settlement of such payment obligations.

You are performing this payment function if you provide clearing services to another entity. For example, you could provide clearing services to another entity by acting as its clearing agent in connection with a clearing and settlement system.

Any of the following may be considered clearing services:

• 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

While transmitting a payment instruction in relation to an EFT is part of the payment function: “authorization of an EFT and transmission of payment instruction in relation to an EFT”, transmitting payment information for clearing purposes or as a precursor to settlement (e.g., transmitting position information) is part of the “providing clearing or settlement services” payment function.

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

Settlement is the discharge of an obligation according to the terms of the underlying contract. Settlement occurs when an individual or entity enables the transfer of funds and/or adjustment of financial positions to extinguish financial obligations between other participants in a payment system.

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.

Any of the following may be considered settlement:

• 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

Key questions and considerations

Clearing

Ask yourself the following assessment questions to help evaluate whether you perform clearing services. If you answer yes to any of the questions, you are likely performing clearing services.

1. 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.
2. Do you help other entities (which can include PSPs) calculate their final positions before their settlement? This calculation may include netting of positions but does not have to.
3. Do you provide transformation services, including transforming payment instructions from one format to another, for clearing purposes (e.g., services to transform an instruction in magnetic ink character recognition format to an automated clearing house system format)?
4. Do you collect and conduct security and integrity checks of payment items to be settled?
5. Do you sort transactions by payment instrument type or by destination (e.g., to a PSP, financial institution, network operator, or other relevant party)?
6. Do you transmit final position information to relevant parties, including transmission of clearing orders (to a financial institution, network operator or another settlement organization) and distribution of notifications back to parties involved in the clearing process (e.g., showing amounts and settlement dates)?
7. Do you confirm availability of funds for settlement?
8. Do you act as the clearing agent for another entity in connection with a clearing and settlement system?

Settlement

Ask yourself the following assessment questions to help evaluate whether you perform settlement services. If you answer yes to any of the questions, you are likely performing settlement services.

1. Do you post credits and debits in the accounts of other entities (which could include other PSPs) to allow them to settle a transaction? The posting of the debit or credit may or may not be followed by a posting of credits or debits in the account of an end user of the entity you are providing services to.
2. Do you conduct account adjustments? In other words, do you settle on behalf of other entities by acting as settlement an agent in connection with a clearing and settlement system?

Incidental activities

In order to determine whether you are performing payment functions that are incidental to one or more of your non-payment services or business activities, consider the following.

Identify your business activities and services

First, review your service or business activities and identify if any are payment functions.

If your only service or business activity is to perform payment functions, you are a PSP according to the definition in the RPAA. An example of a company who fits this description would be an online payment service whose only business is to enable users to transfer funds to each other for a fee. Another example would be a company whose only business is to process retail payment transactions electronically on behalf of merchants for a fee.

If you perform any of the five payment functions as a service or business activity and one or more non-payment services or business activities, you can move to the next section to assess whether your payment functions may be incidental.

Assess the relationship between the payment functions you perform and any non-payment service or business activity you also provide

You are likely not a PSP if you perform payment functions only to directly support a non-payment service or business activity you undertake, in which case your payment functions may be considered incidental. If the payment functions are performed only because they are necessary to the non-payment service or business activity (i.e., the payment functions are essential for the provision of the non-payment activity to occur), they are likely being performed only to directly support a non-payment service or business activity.

Similarly, if the payment functions are only performed to improve the client’s experience with that non-payment service or business activity, they may also be considered as only to directly support a non-payment activity.

In either situation, the only purpose of performing the payment functions should be to directly support the provision of the non-payment service or business activity. The payment functions should not be performed as a distinct service or business activity. Overall, a payment function is generally more likely to be considered incidental (i.e., supporting in nature) if you perform it exclusively to sell your own products and services that are not themselves payment related (e.g., groceries, insurance products, accounting services, car rentals).

You are likely a PSP if you perform a payment function as a distinct service or business activity that does not exclusively support a non-payment service or business activity. Generally, this is more likely to be the case if you are not the seller of the goods or services being exchanged, but you perform a payment function that facilitates retail payment transactions taking place between other buyers and sellers.

As an example, consider 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). Rather, the payment processing business is a distinct business activity where the company allows other buyers and sellers to conduct transactions for goods or services that are completely unrelated to its non-payment service activity (the promotional material service).

Indicators

The following are indicators to help you assess the relationship between the payment functions you perform and any of your non-payment services or business activities. These indicators should not be rigidly applied but are aspects to consider when reviewing the facts and circumstances of your business to identify whether you perform payment functions as an incidental service or business activity. The list is not exhaustive, which means the Bank could use other indicators relevant to specific circumstances.

Revenues or commercial advantage

A payment function is likely not an incidental service or business activity if it directly generates revenues or provides you 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). This could be the case, for example, if you charge a fee or receive financial compensation for providing the payment functions. The Bank views this indicator as broader than the immediate revenues or profits earned from performing a payment function. When conducting your self-assessment, you should consider the full range of benefits that your company derives from your payment services. A payment function could be a distinct service or business activity if it generates less tangible benefits to the business, such as generating data that may be monetized in the future.

End-user expectations

Looking at the types of services that an end user would reasonably expect to receive when dealing with you or your organization can be another indicator of whether you are performing payment functions as an incidental service or business.

If an end user can reasonably expect or understand to be receiving payment services when using or receiving the services you offer, this could indicate that the payment function is a distinct service and is not incidental to your other non-payment service or business activity. For example, your payment services are likely not incidental if your user understands that the purpose of using your service or business is to access their account and make a payment to another individual via an EFT.

In certain cases, your end users may have differing perceptions or expectations of your payment services. However, 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.

Marketing/advertising

Marketing or advertising the payment functions you perform can indicate that you offer the payment functions as a separate service or business activity and therefore they are not performed incidentally.

Examples of advertising or marketing of a payment function include:

• advertising your payment services or the payment related features or benefits of the products and services you offer
• branding or trade names that refer to payment services, for example in the name of your entity, products, services or activities
• dedicating a budget to advertising or marketing your payment products or services

How the Bank will conduct its assessment and use these indicators

When assessing whether a payment function is performed as an incidental service or business activity, the Bank does not take a one-size-fits-all approach and will examine the facts and circumstances of each case. This means that the Bank:

• will not necessarily give each indicator equal weight but instead 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 in a particular situation
• will triage to identify the most relevant indicators, and could make an assessment based on a subset of indicators or as few as one indicator, if the facts and circumstances warrant it
• will consider precedents to determine where a decision may be guided by findings made by the Bank in its previous assessments of applicants, including of registered PSPs, in addition to considering any distinguishing facts or circumstances that require additional analysis

Services and business activities evolve over time. You should continue to monitor and self-assess your business and services, as a payment function previously assessed as incidental to a non-payment activity could become non-incidental when your business model or operating structure changes.

Step 2: Do you perform retail payment activities?

A retail payment activity is a payment function performed in relation to an EFT that is made in the currency of Canada or another country or using a unit that meets prescribed criteria. In most cases, a payment function will precede an EFT.

Electronic funds transfer

Section 2 of the RPAA defines an EFT as “a placement, transfer or withdrawal of funds by electronic means that is initiated by or on behalf of an individual or entity.”

In simpler terms, an EFT is a way of moving money between a payer and a payee through any electronic means (in other words, not in cash). Some common examples include debit, credit or prepaid card transactions made online or at the point-of-sale (POS), direct deposits and electronic peer-to-peer payments.

Currency

Payment functions that you perform must be in relation to a transaction carried out in at least one of the following:

• Canadian currency
• foreign currency (e.g., US dollars, yen)
• a unit that meets prescribed criteria

Step 3: Where is your place of business?

To meet the geographic scope requirements set out in sections 4 and 5 of the RPAA, you must satisfy one of the following:

• you have a place of business in Canada
• you do not have a place of business in Canada, but you perform retail payment activities for an end user in Canada and direct these activities at individuals or entities in Canada
• you do not have a place of business in Canada but plan to expand your business into Canada

Payment service providers with a place of business in Canada

You are considered to have a place of business in Canada if you satisfy one of the following:

• you have a physical location in Canada—this includes home offices; it does not necessarily have to be a storefront or brick and mortar location
• you are incorporated in Canada—under either federal or provincial legislation
• you have employees, agents or mandataries in Canada

Payment services providers that do not have a place of business in Canada

You are not considered to have a place of business in Canada if you satisfy the following:

• you do not have a physical location in Canada
• you are not incorporated in Canada; and
• you do not have employees, agents or mandataries in Canada

If your place of business is outside of Canada, you may still need to register with the Bank if you do both of the following:

• perform retail payment activities for an end user in Canada
• direct retail payment activities at individuals or entities in Canada

Performing retail payment activities for end users in Canada

To assess whether an end user is in Canada, the Bank will only consider the actual location of the end user and whether they are physically present in Canada. An individual will not be considered to be in Canada when they are temporarily living outside of Canada, attending school outside of Canada, working outside of Canada or vacationing outside of Canada.

When assessing whether a retail payment activity is performed in Canada, you should consider factors such as the following:

• 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

You are considered to direct 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.

If none of these apply to you, it is still possible that you are directing retail payment activities at individuals or entities in Canada. The Bank may consider additional criteria to make this determination. For example, some of the following factors may result in the Bank determining that you are directing retail payment activities at individuals or entities in Canada:

• 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.

Considering expanding business to Canada

If you do not have a place of business in Canada and are considering expanding your business to Canada, you may plan marketing or advertising to assess the demand for your retail payment activities in Canada. Such activity would only be considered directing retail payment activities and you would not need to register with the Bank. However, you would have to register with the Bank before you start performing retail payment activities for end users in Canada.

Step 4: Are you or your activities excluded from the Retail Payment Activities Act?

Even if you are a PSP that performs retail payment activities, the RPAA may not apply to you or to the retail payment activities you perform. The RPAA includes a number of scope exclusions. There are two types of exclusions:

• entity-based
• activity-based

Entity-based exclusions

Entity-based exclusions are specified in the RPAA and prescribed in regulations. These exclusions apply to:

• banks and authorized foreign banks included in Schedules I, II or III of the Bank Act
• insurance companies and fraternal benefit societies subject to the Insurance Companies Act and trust and loan companies subject to the Trust and Loan Companies Act
• provincially regulated financial institutions (including credit unions, caisses populaires, insurance companies, trust companies and loan companies) that accept deposits transferable by order
• the Bank of Canada
• the Canadian Payments Association
• the Provincial Crown and agents or mandataries of the Provincial Crown that accept deposits transferable by order
• the SWIFT messaging network4

Activity-based exclusions

Activity-based exclusions include:

• certain types of retail payment activities posing limited risk to end users
• activities that are prudentially regulated or not considered to be retail payments

Even if a specific activity is excluded, you may still need to register with the Bank if you perform other scoped-in retail payment activities. In such a case, the Bank would not supervise excluded activities but would require registration for all other activities that are within the scope of the RPAA (including systems that support these activities).

Retail payment activities excluded under the RPAA

Merchant instruments

Two types of merchant instruments are excluded:

1. Merchant instrument exclusion: This exclusion applies to a payment function performed in relation to an EFT made with an instrument issued by a merchant that allows the holder of the instrument to purchase goods or services only from the issuing merchant.
• The instrument may be either physical or electronic and must be issued to an instrument holder to purchase goods or services. An instrument is a device or set of procedures to initiate an instruction to make a payment.
• The instrument must be issued by the merchant. A merchant is an individual or entity who offers goods or services.
• The instrument holder must only be able to use the instrument at the issuing merchant.
2. Group of merchants exclusion: This exclusion applies to a payment function performed in relation to an EFT made with an instrument issued by an issuer that is not a PSP and has an agreement with a specific group of merchants and that allows the holder of the instrument to purchase goods or services only from any merchant in the group.
• The instrument may be physical or electronic and must be issued to an instrument holder to purchase goods or services.
• The instrument must be issued by an issuer that is not a PSP as defined in the RPAA. An issuer is an entity that issues an instrument to an instrument holder.
• The issuer of the instrument must have an agreement with the group of merchants.
• The instrument holder must be able to use the instrument only at the merchants in the merchant group. If the instrument can be used to purchase goods or services widely, the exclusion may not apply.

Eligible financial contracts pursuant to the Canada Deposit Insurance Corporation Act

This exclusion applies to a payment function is performed in relation to an EFT made for the purpose of giving effect to an agreement that is an eligible financial contract as defined in subsection 39.15(9) of the Canada Deposit Insurance Corporation Act.

Securities transactions

Prescribed transactions related to securities are excluded from application of the RPAA. Under Section 2 of the RPAR, transactions related to securities performed by individuals or entities that are regulated or exempted from regulation under Canadian securities legislation as defined in National Instrument 14-101 Definitions of the Canadian Securities Administrators are excluded.

Cash withdrawals at automatic teller machine

This exclusion applies to a payment function that is performed for an EFT made to withdraw cash at all automatic teller machines (ATMs), including bank and white label ATMs.

Designated systems

Under the authority of the Payment Clearing and Settlement Act, the Bank is responsible for overseeing designated financial market infrastructures that could be operated in a way that poses “systemic risk” and “payment system risk.” The RPAA does not apply in respect of a payment function that is performed using a system that is a designated financial market infrastructures.

Although the RPAA does not apply to a payment function performed using a designated system, participating in or using the designated system does not exclude a PSP from having to register. Rather, an individual or entity must register if it performs any payment function outside of the designated system. The Bank expects that likely only an operator of a designated system could perform all of its payment functions entirely within the designated system.

Internal transactions

Retail payment activities considered to be internal transactions are excluded from the RPAA. An internal transaction involves an EFT made between affiliated entities, where the PSP is one of the affiliated entities and no other PSP performs payment functions for that EFT.

Payment transactions that involve external entities that are not affiliated would likely not be an internal transaction. For example, a payment transaction involving external customers of an organization could result in an internal movement on the company’s ledger (i.e., an “on us” transaction). However, given that the customers responsible for the ledger movement (initiating the transaction) are external entities involved in the transaction, it would not be considered an internal transaction. This is because the customers are not affiliated entities of the PSP.

Examples of transactions between affiliated entities may include transactions between a parent company and a subsidiary or between two subsidiaries of a parent company.

Agents and mandataries

In the context of the RPAA, an agent or mandatary is an individual or entity that performs retail payment activities within the scope of its authority as agent or mandatary of a registered PSP. In this type of relationship, a registered PSP uses the agent or mandatary to perform retail payment activities on its behalf. The PSP is responsible for ensuring that its agents and mandataries comply with the RPAA, and therefore the Act does not apply to them. The registered PSP is required to provide information about agents and mandataries that perform retail payment activities on their behalf as part of its registration application and to notify the Bank if there are any changes to this information. A registered PSP is responsible for compliance with the RPAA and in accordance with section 87 of that act, is liable for any violation that is committed by its agents and mandataries acting within the scope of their authority as agent or mandatary.

When an agent or mandatory also performs retail payment activities outside of the agency relationship it has with a registered PSP, it may be required to register as a PSP under the RPAA, however the applicable obligations under the RPAA would apply only to its activities that are outside of its duties as an agent or mandatary.

When an agent or mandatory of an excluded PSP (such as a bank, or provincially regulated financial institution) performs retail payment activities, it is required to register as a PSP under the RPAA.

Third-party service providers

The RPAA distinguishes between agents or mandataries and third-party service providers, and third-party service providers are not excluded from application of the RPAA. Whereas agents or mandataries act within a specific scope of authority on behalf of the registered PSP, a third-party service provider is an individual or entity that:

• under a contract, provides a PSP with a service related to a payment function
• is not an employee or agent or mandatary of the PSP

It is important to note that a PSP is required to disclose its third-party service providers, as set out in paragraph 29(1)(k) of the RPAA, and that it is liable under the Act for its third parties acting within the scope of their contract, as set out in section 87.

Affiliated entities

If an affiliated entity is a PSP that performs retail payment activities and is not excluded from the application of the RPAA, it is required to register, even if an entity affiliated with it may also have registered. For example, subsidiaries may be required to register separately even if their parent organization is already registered under the RPAA. In addition, any individual or entity applying for registration is required under paragraph 29(1)(d) of the RPAA to submit specific information about its affiliated entities.

Section 3 of the RPAA defines an affiliated entity for the purposes of the registration application (paragraph 29(1)(d)) and for determining when the internal transactions exclusion applies (section 8). Any of the following are considered affiliations:

• when one entity is the subsidiary of another entity
• when two entities are subsidiaries of the same entity
• when two entities are controlled by the same individual or entity
• when two entities are affiliated with the same entity at the same time
• when an individual controls the entity

The RPAA also defines the words subsidiary and control to help interpret who is an affiliated entity.

• A subsidiary is an entity that is controlled by another entity.
• Control is broken down with respect to corporations, limited partnerships and entities other than corporations or limited partnerships:
• A corporation is controlled by an individual or entity if securities of the corporation to which are attached more than 50% of the votes that may be cast to elect directors are held, directly or indirectly (otherwise than by way of security only), by or for the benefit of that individual or entity and the votes attached to those securities are sufficient to elect a majority of directors.
• A limited partnership is controlled by its general partner.
• An entity other than a corporation or limited partnership is controlled by an individual or entity if the individual or entity, directly or indirectly, holds an interest in the entity that entitles them to receive more than 50% of the profits or more than 50% of the assets on dissolution.
• Control of a corporation or other entity can be established directly or indirectly through one or more subsidiaries.

Additional resources

For more details related to registration, see:

• Supervisory framework: Registration
• Self-assessment tool
• Case scenarios
• How to complete a registration application: A step-by-step guide
• Frequently asked questions

Endnotes