Retail Payment Activities Act (RPAA): a plain-English explainer for Canadian payment service providers

The Retail Payment Activities Act (RPAA) is the federal Canadian law that established a supervisory framework for retail payment service providers. The Bank of Canada is the supervisor. The law's purpose is to make retail payments operationally safe (resilient, well-managed, with funds protected) and to bring previously unregulated PSPs into a registration regime. The RPAA does not replace anti-money-laundering law: many PSPs are also money services businesses under the PCMLTFA and registered with FINTRAC.

This explainer covers what the RPAA is, who has to register, the five core obligations, where it meets the PCMLTFA, the penalty regime, and what a Canadian PSP should be doing now.

What is the RPAA?

The RPAA is a prudential and operational statute. Where the PCMLTFA exists to combat money laundering and terrorist financing, the RPAA exists to make sure that when an end user moves money through a Canadian PSP, that PSP is running its operations safely and the user's funds are not at risk because of an internal failure. The Bank of Canada is named in the statute as the regulator and supervisor, and the obligations under the law are operational rather than transactional.

The framework rests on three pillars: a registration regime, an operational risk and safeguarding regime, and an incident-and-information reporting regime. Each PSP has to register with the Bank of Canada, establish and maintain frameworks to manage operational risk and safeguard end-user funds, and report material incidents to the Bank of Canada within prescribed timeframes.

Who has to register under the RPAA?

The RPAA defines five retail payment functions. A person or entity that performs one or more of these functions as a service to an end user, in Canada or for users in Canada, generally has to register.

1. Provision or maintenance of an account that, in relation to an electronic funds transfer, is held on behalf of one or more end users.
2. Holding of funds on behalf of an end user until the funds are withdrawn or transferred to another individual or entity.
3. Initiation of an electronic funds transfer at the request of an end user.
4. Authorisation of an electronic funds transfer or the transmission, reception, or facilitation of an instruction in relation to such a transfer.
5. Provision of clearing or settlement services.

Several categories are explicitly excluded. Banks and other prudentially supervised financial entities are out of scope: their primary regulator already covers operational risk and safeguarding. Pure technical service providers who never take possession or control of end-user funds (acting only as message movers) are typically out of scope as well. Internal payments within a single corporate group, payments related to securities settled by a clearing house, and certain agent arrangements are also excluded or treated as part of another regulated activity.

The practical test for most firms is functional rather than nominal. If a firm holds end-user funds even briefly, initiates an electronic funds transfer on a user's instruction, or facilitates the authorisation of such a transfer between parties, it almost certainly performs a retail payment function under the RPAA. Whether the firm calls itself a payment service provider, a fintech, a wallet, a remittance company, an embedded-finance provider, or something else does not change the analysis.

The five core RPAA obligations

Once registered, a PSP has to maintain compliance with five operational obligations on an ongoing basis.

1. Registration with the Bank of Canada

Registration is the threshold obligation. A PSP applies to the Bank of Canada, provides information about ownership, operational structure, and the retail payment functions it performs, and obtains a decision. Registration can be refused or, after the fact, revoked where the Bank of Canada concludes the applicant does not meet the requirements. Operating as a PSP without being registered is itself a violation of the Act.

2. Operational risk management framework

Every registered PSP must establish, implement, and maintain a documented framework to manage operational risk. The framework has to identify the risks the PSP faces (cyber, fraud, third-party, business continuity, operational error), set out the controls used to mitigate them, define the governance over those controls, and demonstrate testing and continuous improvement. The framework is reviewed annually and updated as the business changes.

3. Safeguarding of end-user funds

If the PSP holds end-user funds, those funds have to be safeguarded. Options include holding the funds in a designated trust account at a Canadian financial institution, holding them in a separate account combined with insurance or guarantees that meet prescribed requirements, or holding them in another manner prescribed by regulation. The PSP must be able to identify, at any time, the amount held on behalf of each end user, and to return those funds promptly in the event of insolvency or wind-down. Safeguarding is the obligation most often misunderstood by early-stage PSPs that treat customer balances like operating cash.

4. Incident reporting

The PSP must notify the Bank of Canada of any incident that has a material impact on an end user, another PSP, or a clearing house. The notification has to be made as soon as feasible after the PSP becomes aware of the incident, and follow-up information must be provided as the incident is resolved. Internal incident logs and post-mortems become part of the program of record; an examiner will read them.

5. Sanctions compliance

The RPAA explicitly incorporates Canadian sanctions law. A PSP is responsible for screening counterparties and end users against Canadian sanctions lists, applying restrictions where required, and reporting required matters. Sanctions compliance under the RPAA is not a substitute for the firm's sanctions obligations under the PCMLTFA where those also apply; both regimes run in parallel.

Where the RPAA meets the PCMLTFA

The RPAA and the PCMLTFA cover different objectives but overlap substantially in scope. The same firm can be:

• A registered PSP under the RPAA (Bank of Canada), with operational risk and safeguarding obligations.
• A registered MSB under the PCMLTFA (FINTRAC), with KYC, screening, monitoring, reporting, and recordkeeping obligations.

Where this is the case, the firm has two regulators, two ongoing registration obligations, two examination postures, and two parallel sets of records. Reconciliation between the two is where most early-stage PSPs lose time. A practical compliance program treats both regimes as one operational program with two regulatory outputs: the firm runs a single set of controls (onboarding, screening, monitoring, incident management) and surfaces evidence to each regulator in the format that regulator expects. The detail on the PCMLTFA side is in our PSP compliance primer.

Penalties under the RPAA

The RPAA authorises Administrative Monetary Penalties for violations. AMPs are graded by category (minor, serious, very serious), with separate caps for natural persons and for entities. Operating as a PSP without registering is itself a violation. Failure to maintain an operational risk management framework, failure to safeguard end-user funds, failure to report a material incident within the prescribed period, and failure to meet sanctions obligations are all enforceable individually.

The Bank of Canada may also refuse, suspend, or revoke registration where requirements are not met. Loss of registration is more consequential than an AMP for an operating PSP: it stops the regulated activity at the source.

What a Canadian PSP should do now

Six steps tighten the program against an examiner.

1. Confirm the activity classification. Map the firm's services against the five retail payment functions and document the answer. If any function applies and no exclusion fits, the firm must register.
2. Register, or confirm the registration is current. Provide accurate information about ownership, functions, jurisdictions, and material third parties. Update as the business changes.
3. Stand up the operational risk management framework on paper. Most early-stage PSPs already manage operational risk in practice; few have it written down to the standard the Bank of Canada will expect. The written framework is the artefact an examiner reads first.
4. Audit the safeguarding arrangement. Confirm the trust account or alternative mechanism in use, the reconciliation cadence, the per-user balance reporting, and the wind-down procedure. Most material RPAA findings concentrate here.
5. Build the incident-reporting muscle. Define what counts as a material incident, who decides, who notifies, and the timing. Run a tabletop exercise so the obligation does not collide with a real incident the first time.
6. Reconcile the RPAA and PCMLTFA program. Run both regimes as a single operational program. The savings are in time and headcount, not in software.

How BriteBase helps

BriteBase covers both regimes under one program. The AML Operating Platform handles onboarding, screening, monitoring, and reporting for the PCMLTFA side. The AML Managed Services bench operationalises the same controls and adds a fractional Chief Anti-Money Laundering Officer of record. Advisory Services are the consultative work around RPAA registration scoping, operational risk framework drafting, safeguarding review, and regulator meetings. For one-off needs (a registration application, a wind-down readiness review, an incident response), Special Projects are the fixed-fee path. Pricing is on the pricing page.

FAQ