Publication date: December 12, 2023
The following fictional case scenarios provide details about the payment functions: provision or maintenance of an account on behalf of an end user; the initiation of an electronic funds transfer at the request of an end user; the provision of clearing and settlement services; as well as examples of incidental activities under the Retail Payment Activities Act.
The examples provided are not a replacement for the Criteria for registering payment service providers supervisory policy, but rather they are meant to complement the policy. They should be read in conjunction with the policy.
These examples build off each other. We recommend reading them in the order they appear.
Case scenario: 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.
Company A does not initiate, authorize, transmit, receive or facilitate electronic funds transfers (EFTs), nor does it hold funds on behalf of its clients.
Even though Company A stores information, it does not do so for the purpose of conducting future EFTs. Therefore, Company A does not perform the payment function of maintaining an account as defined under section 2 of the Retail Payment Activities Act (RPAA).
Some of Company A’s activities, such as helping clients reconcile their sales information, might be compared with performing clearing services, which is a payment function under the RPAA (clearing or settlement services). However, in this example, Company A’s activities are not undertaken as a precursor to settling EFT transactions. As a result, Company A does not provide clearing or settlement services.
Overall, this means that Company A is not performing any payment functions under the RPAA. It is not a PSP and does not need to register with the Bank of Canada.
Case scenario: Accounting software and payment services
Assume now that 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.
In this new set-up, Company A performs payment functions as defined in the RPAA. End users’ personal and financial information is now stored for purposes that include conducting future EFTs. This means that Company A performs the maintaining of an account payment function. In addition, the payment page provided by Company A linked in the invoice acts as the interface that captures the relevant payment information and launches the first payment instruction that triggers the EFT requested by the payee (in this case, Company A’s business clients). More precisely, the page is pre-filled with transaction details and allows the payer to input payment credentials, like their credit card, before the page sends the payment instructions to other entities for further processing (such as card networks). This means that Company A also performs the function of initiating an EFT.
The payment functions that Company A performs are not considered incidental to the accounting services it provides. This is because the payment functions are not performed exclusively to enable or support the provision of accounting services. For example, Company A was able to offer those accounting services before the payment services even existed. Indicators also show that invoice payment functions are performed as a distinct business activity. Company A advertises its new activity as a payment service on its website, and it directly generates additional revenues from the new payment service.
As a result, Company A now meets the definition of a PSP under the RPAA. Company A needs to register with the Bank of Canada, assuming it meets the other registration criteria.
Disclaimer
The case scenarios are illustrative examples reflecting the Bank of Canada’s interpretation of certain requirements set out in the Retail Payment Activities Act (RPAA). All names, facts and descriptions in these scenarios are entirely fictitious and do not reflect any real or actual individuals or entities.
Additionally, they do not represent legal advice and should not be used as a replacement for seeking such advice if an individual or entity is unsure about whether they are required to register with the Bank of Canada as a payment service provider. The nature of the products and services offered by each individual or entity will vary, as will the circumstances around offering these products and services. Therefore, any individual or entity that may be subject to the RPAA should assess their own situation on a case-by-case basis according to their own facts and circumstances. Any entity or individual that may be subject to the RPAA is ultimately responsible for determining whether they are required to register with the Bank.
The examples provided are not a replacement for the Criteria for registering payment service providers supervisory policy, but rather they are meant to complement the policy. They should be read in conjunction with the policy.
Topic(s):
Registration