RPAA Third-Party Service Provider Requirements for PSPs in Canada

Our mission is to help Canadian fintech companies get registered, go live, and stay compliant.

If your RPAA-registered payment service provider (PSP) uses a third-party service provider (TPSP) to help perform a payment function, the Retail Payment Activities Act (RPAA) keeps the responsibility with you, not the vendor. Your operational risk management and incident response framework has to cover each in-scope TPSP: conduct due diligence on the service provider before you sign and at least once a year, set out roles in a written contract, monitor it, build compensating controls and an exit plan, and flag significant changes to the Bank of Canada.

A TPSP is not automatically "regulated under the RPAA" just because it serves you, and you cannot pass your obligations to it by outsourcing the work. The rules apply to the services that actually touch your payments and your operational risk, not every vendor you pay. This guide explains which third parties are in scope, how a TPSP differs from an agent or mandatary, exactly what your framework must do, and when you have to tell the Bank of Canada. It follows the Bank of Canada's Operational risk and incident response guideline.

What is a third-party service provider under the RPAA?

Under section 2 of the RPAA, a TPSP is a person or entity that, under a contract, provides your PSP with a service related to a payment function and is not your employee, agent or mandatary. It can be an affiliate, an individual, or even another PSP, and it counts regardless of where it or its technology sits.

Not every vendor is in scope. The guideline focuses on services that are relevant to your RPAA compliance: those that, if they failed or were impaired, could reasonably reduce, deteriorate or break your ability to provide retail payment activities or to manage operational risk. Services that are only tangential, such as advertising, sales, payroll or legal work, may fall outside these requirements. Ultimately, you have to assess which of your providers are in scope.

Examples of services typically covered by RPAA third-party oversight

How is a TPSP different from an agent, mandatary or another PSP?

A TPSP supplies you a service under contract but does not act as your representative. An agent or mandatary is different: it performs retail payment activities on your behalf, as your representative. The RPAA treats agents and mandataries as the same thing, and a separate set of rules applies to them. For a deeper look at that line, see our explainer on what agents and mandataries mean under the RPAA.

Another trap is the "separately regulated PSP." A TPSP can itself be a regulated entity, or even another PSP. If its regulation covers the service it gives you, you can factor that into your risk assessment and ease the depth of your checks. But that never erases your own duty to oversee it, and it does not make the vendor "RPAA-compliant" on your behalf.

TPSPs compared with agents and mandataries

"But our payment processor handles the money — aren't we off the hook?"

No. Section 87 of the RPAA makes you liable for a violation committed by any of your TPSPs, agents or mandataries acting under the contract. Outsourcing the payment handling does not outsource your RPAA responsibility. You also cannot use a TPSP in a way that blocks the Bank of Canada from supervising you, and you must still meet all reporting and record requests.

For example, imagine a billing app called DocNote. A business uses DocNote to send a customer a bill. The customer pays through a separate payment processor, which handles the money. DocNote then sends the customer their document.

DocNote's founder might think: "We never hold the money, so only the payment processor has to worry about the RPAA." But not holding the money does not automatically put DocNote outside the law. What matters is what DocNote actually does in the payment process. If those activities make DocNote a PSP under the RPAA, it has its own duties—even when a separate processor handles the money.

If your business is a PSP and hires a payment processor to help provide its payment services, you still have to manage the risks of using that processor. That means checking whether it can do the job safely, putting each party's responsibilities in a written contract, and checking that it keeps meeting those responsibilities. Hiring someone else to handle the money does not remove your own RPAA duties.

What must your framework do for third-party service providers?

Your framework must actively manage the risk each in-scope TPSP creates so you can keep meeting your integrity, confidentiality and availability objectives and stay compliant. In practice, the Bank of Canada expects five things, and you can scale the rigour of each to how material and risky the service is. Keep records throughout — you have to be able to show your work.

1. Decide which TPSPs are in scope and how material they are

Before you engage a provider, judge the impact on your retail payment activities if that service were impaired or failed. Use a documented, formal method, and weigh factors like how easily you could move to another provider (substitutability) and whether you lean on one provider for many services (concentration risk). Review materiality periodically, because a service can become critical over time.

2. Assess the provider before you engage it, and at least once a year

Under RPAR subsection 5(3), your framework must address how you assess a TPSP's ability to protect your data, the security of its connections to your systems, how it will warn you before changing the service, how you will monitor its performance and get breach notifications, and its overall risk management practices. You must run this assessment before entering, renewing, extending or substantially amending a contract, and at minimum annually, keeping a record of each assessment's date, scope and findings.

3. Put it in a written contract and allocate responsibilities clearly

Your framework must clearly split responsibilities between you and the TPSP, including who owns the data, in writing. The Bank of Canada expects your contract to cover things like service levels, breach and change notification, subcontracting (fourth-party risk), audit or testing access, security, liability and indemnity, and termination. Some providers only offer standardized contracts you cannot negotiate; that does not excuse you, so you manage the gap with monitoring and compensating controls instead.

4. Build compensating controls and a termination plan

Contracts alone are not enough. Where terms fall short, add compensating controls such as broader monitoring of the provider's financial and regulatory standing, ongoing security testing of your connections, and folding the service into your own testing and incident response. Keep a termination or exit plan so that, if you have to leave a provider, you can still meet your objectives and stay compliant, with a realistic sense of who takes over and how long it takes.

5. Monitor the provider on an ongoing basis

Monitor each TPSP, including affiliates, at least once a year, to confirm it is meeting contractual terms and service standards, that your objectives and compliance hold, and that you will be told about breaches or breakdowns. If a TPSP reports a breach, reduction or breakdown, you are the one who decides whether it meets the incident notification threshold under section 18 of the RPAA. Document what your monitoring finds.

Do you have to tell the Bank of Canada about your TPSPs?

Sometimes, yes. Engaging a new TPSP, or materially changing how you use one, can be a significant change that you must report to the Bank of Canada under subsection 22(2) of the RPAA. On top of that, you cannot structure a TPSP arrangement in a way that limits the Bank of Canada's ability to supervise you, and you must stay able to meet every reporting, record and information request.

This is where the day-to-day of ongoing RPAA compliance and a well-built operational risk management framework pay off: your vendor oversight, assessments and incident handling all live inside that single framework rather than in scattered one-off checks.

How Renno & Co can help

Most of the pain here is turning these expectations into a framework that actually holds up to Bank of Canada scrutiny — scoping your TPSPs, writing the assessment and monitoring process, and getting the contract terms right. We help Canadian PSPs with RPAA registration and with preparing the operational risk management framework that sits behind it. If you are bringing on or re-papering a payment processor, cloud host or other critical vendor, book a call to review your TPSP assessments, contracts and monitoring process before the Bank of Canada reviews them.

FAQ

Does every vendor we use become an RPAA third-party service provider?

No. Only providers that deliver a service related to a payment function are in scope, and the focus is on services whose failure would hurt your retail payment activities or your operational risk management. Purely tangential services, like advertising, sales, payroll or legal work, may fall outside these requirements. You still have to assess and document which providers are in scope.

Does our third-party service provider have to comply with the RPAA?

The RPAA obligations sit on you, the PSP, not automatically on the vendor. A TPSP does not become a regulated PSP just because it serves you, although it might be separately regulated for other reasons. Under section 87 of the RPAA you remain liable for violations your TPSP commits under the contract, so you manage it through assessment, contracting and monitoring. By the same token, a platform like DocNote above cannot assume it escapes the RPAA just because a processor moves the money — scope follows the activity, not the plumbing.

How often do we have to assess our TPSPs?

Before entering, renewing, extending or substantially amending a contract, and at least once a year for each provider. You can scale the depth of the review to the risk and materiality of the service, but you must keep a record of each assessment's date, scope and findings.

What's the difference between a TPSP and an agent or mandatary?

A TPSP provides you a service under contract and is not your representative. An agent or mandatary performs retail payment activities on your behalf, as your representative, and is governed by a separate rule (RPAR subsection 5(4)) that requires you to set minimum criteria and refuse to engage anyone who does not meet them. You remain liable for both under section 87.

This content is for informational purposes only and does not constitute legal advice.