Case scenarios about card program managers

Publication date: October 2, 2024

The following fictional case scenarios provide examples of incidental activities under the Retail Payment Activities Act, especially in the context of card program managers.

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: Merchant card program

Merchant A has introduced a credit card program for their customers to improve their shopping experience with them and increase brand loyalty. 

To design and issue its cards, Merchant A partnered with Company B. Company B arranged for Merchant A’s credit cards to be issued by their partner institution Bank C, pursuant to their license from Company D, a credit card network. The credit cards bear Merchant A’s and Bank C‘s logos and can be used at any store that accepts cards on Company D’s network. In other words, the credit card can be used at Merchant A premises, but also as payment method at many other stores that are not affiliated with Merchant A. Pursuant to its agreement with Merchant A, Bank C and Company D, Company B is in charge of processing and authorizing payment transactions initiated with Merchant A’s cards.

Merchant A collects and stores customers’ personal information to run its loyalty points program and to share with Company B for the purpose of the card program. Accordingly, Merchant A stores end users’ personal information for purposes that include supporting future electronic funds transfers, and, as a result, performs a payment function: the provision or maintenance of an account.

In this case, however, the payment function of maintaining an account is performed solely to enable the card program, and Merchant A’s only objective for the card program is to support its non-payment-related business by improving the client shopping experience and increasing brand loyalty. Although Merchant A advertises its card program, it does not generate direct revenues from this activity. As such, the payment function performed by Merchant A is incidental, and Merchant A is not a payment service provider (PSP) under the Retail Payment Activities Act (RPAA) definition. It does not need to register with the Bank of Canada.

Case scenario: Program manager

Let’s now turn to Company B, which works with Merchant A to execute their card program. Among other things, Company B enables merchants to offer a branded credit card program. They do this by offering several services, such as assisting their customers with meeting the different requirements set out by the card issuers, and processing the day-to-day operations of the card programs on the merchants’ behalf.

Company B stores end-users’ personal information linked to the payment credentials generated for them and maintains a transaction ledger on behalf of the issuing bank for each cardholder. When cardholders use the card (for example, at a POS terminal or an online payment gateway), a merchant acquirer sends an authorization request through Company D’s card network. Company B responds to authorize or decline each cardholder transaction based on its ledger for that cardholder. At the end of each day, Company B nets all cardholder transactions and determines the appropriate balance of funds needed for settlement. Funds are later settled through the Company D card network between Bank C and other financial institutions.

This means that Company B performs the following payment functions: provision and maintenance of an account; authorization of an EFT and the transmission, reception or facilitation of an instruction in relation to an EFT; and the provision of clearing services.

The payment functions performed by Company B are not incidental to another service or business activity, since they are directly part of their core business of supporting payment card programs. Company B advertises its services as enabling entities to set up payment card programs and generates revenues from this activity. As a result, Company B meets the definition of a PSP under the RPAA and needs to register with the Bank of Canada, assuming it meets the other registration criteria.

Case scenario: Neobank

Another of Company B’s clients is Company Z, an entity that markets itself as a neobank and offers a deposit account and corresponding open-loop prepaid card to its clients for a fee. Company B processes the day-to-day operations of Company Z’s card program.

Like in the previous scenarios, Company Z’s prepaid cards are issued by Bank C pursuant to a license with Company D, a card payment network. Company Z has developed its own application through which its clients can check their balance, initiate EFTs to other parties (e.g., Interac e-Transfer®, bill payments, etc.) and view their transaction history.

When a client deposits money into their Company Z account, the funds are received and held under Company Z’s name at Bank C. Since Company B maintains the ledger with the amount of funds that clients of Company Z have on their card balances, Bank C does not know to whom the money belongs. All issuer processing, dispute resolution, and customer service is provided by Company B. Company B also pays Company Z a portion of the revenues generated by the card program through interchange fees.

Notwithstanding that Company Z contracts with Company B to issue a pre-paid card, Company Z is also a payment service provider in its own right. In this case, Company Z performs several payment functions: provision and maintenance of an account; holding of funds on behalf of an end user; initiation of an EFT at the request of an end user; and authorization and transmission, reception or facilitation of an instruction in relation to an EFT. Company Z’s core business model involves providing payment services, which it advertises and with which it generates revenues. As a result, Company Z meets the definition of a PSP under the RPAA and 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.

On this page
Table of contents