PSP compliance primer: AML and sanctions expectations in Canada

Canadian PSPs operate under two regulatory regimes at once. The Retail Payment Activities Act (RPAA) governs operational risk, safeguarding of end-user funds, and Bank of Canada registration. The PCMLTFA governs AML and sanctions for any PSP that qualifies as a money services business, which most PSPs handling money transmission or currency conversion will. The two regimes are not the same, they are not redundant, and they have to be operated in lockstep.

This primer covers the AML and sanctions side of the picture, with explicit references to the RPAA where the two regimes intersect.

What is a payment service provider under Canadian law?

The RPAA defines a PSP as an entity that performs one or more retail payment activities as a service or business activity. The five payment functions captured by the RPAA are:

1. Providing or maintaining an account that, in relation to an electronic funds transfer, is held on behalf of one or more end users.
2. Holding funds on behalf of an end user until they are withdrawn or transferred.
3. The initiation of an electronic funds transfer at the request of an end user.
4. The authorization of an electronic funds transfer or the transmission, reception, or facilitation of an instruction in relation to an electronic funds transfer.
5. The provision of clearing or settlement services.

The PCMLTFA, separately, captures PSPs as MSBs where they perform money transmission, foreign exchange dealing, or virtual currency activity for the public. Most PSPs handling cross-border or multi-currency flows fall under both regimes.

Two registrations, two obligations

Registration with the Bank of Canada under the RPAA is operationally separate from registration with FINTRAC as an MSB. A PSP that does both has to do both. Registrations renew on different cycles. Examinations come from different bodies. The compliance program documentation must reflect both regimes.

The Canadian AML framework that applies to PSPs

Where a PSP is also an MSB, the PCMLTFA framework applies in full. The five program pillars are the same as for any other reporting entity (see our Bill C-12 guide), but several PSP-specific operational realities shape how they are run.

1. The volume problem

PSPs typically run at much higher transaction velocity than traditional MSBs: tens of thousands to millions of transactions per day. Manual alert review at that scale is impossible; the program has to rely on layered detection (rule-based scenarios + ML-based anomaly detection) with human approval on regulated decisions, not on every event.

2. The on-behalf-of complication

PSPs frequently process on behalf of merchant clients, who in turn serve end consumers. The PCMLTFA requires the PSP to identify and risk-assess its customer (typically the merchant) and have visibility into the merchant’s end users where the PSP’s services touch identifiable individuals. This is one of the most-frequent examination findings for PSPs: incomplete visibility into end-user activity processed through merchants.

3. The merchant onboarding pipeline

For PSPs, KYC is also KYB (know your business). The merchant due diligence file has to include beneficial ownership, control persons, the nature of the merchant’s business, sanctions screening of the entity and its principals, expected processing volumes, and ongoing monitoring against actual volumes. A merchant whose actual processing diverges materially from declared expectations is a textbook examination talking point.

The PSP compliance stack

The three layers of a PSP compliance program, with PSP-specific items at each layer.

Reporting obligations specific to PSPs

PSPs file under both the PCMLTFA (where they are also MSBs) and the RPAA operational risk framework. The combined reporting picture:

The RPAA significant incident notification is distinct from a PCMLTFA STR. The first is operational (the payment function was disrupted), the second is suspicion-based (the activity looks like ML/TF). Both can be triggered by the same underlying event and the compliance program must specify the path for each.

Sanctions screening expectations

PSPs screen at three different levels of the value chain:

• Merchant level. The legal entity, its directors, beneficial owners (25 percent threshold), and signing officers at onboarding and on a continuous basis.
• Transaction level. Originator and beneficiary names on transfers crossing the PSP’s rails, especially international transfers under the Travel Rule. See the Travel Rule primer.
• End-user level. Where the PSP’s services touch identifiable end users (account holding, money transfer initiation), screen those individuals as well.

The screening lists are the same as for MSBs: SEMA, JVCFOA, UN Act regulations, Criminal Code listed entities, and the OSFI Consolidated Lists. PSPs with US-jurisdiction processing should also screen against OFAC SDN.

The PSP technology stack

A defensible PSP technology stack covers seven capabilities:

• Merchant onboarding (KYB). Legal entity verification, beneficial ownership capture, control person identification, document collection, risk scoring.
• End-user KYC. Where the PSP touches identifiable end users, full identification, address verification, and beneficial ownership where applicable.
• Sanctions and PEP screening. Real-time at every onboarding and every transfer above threshold. Continuous re-screening of customer book against list updates.
• Transaction monitoring. Rule-based scenarios for PSP-specific patterns: merchant volume drift, BIN-level anomalies, velocity spikes, cross-border corridor risk, account takeover indicators. Often layered with ML.
• Case management. One workflow that holds alerts, investigations, dispositions, STRs and the supporting evidence.
• FINTRAC reporting integration. Automated population and filing of STRs and EFTRs via F2R, with reconciliation to case records.
• RPAA operational risk controls. End-user fund safeguarding, third-party risk management, incident response, business continuity, and the operational risk reporting framework required by the Bank of Canada.

In-house expertise required

A Canadian PSP at meaningful processing volume needs:

• CAMLO with payments background. Named compliance officer with current PCMLTFA knowledge and direct experience operating across payment rails and merchant ecosystems. Fractional CAMLO is the standard pattern for late-stage PSPs without in-house leadership; see the fractional CAMLO guide.
• Merchant risk lead. Owns the merchant onboarding queue, the KYB risk model, and the periodic review of high-risk merchants.
• Transaction monitoring analysts. Tune the rule library, review alerts, drive investigations, and own the STR filing pipeline.
• Sanctions specialist. Owns the sanctions screening engine, list updates, disposition policy, and any escalations to the CAMLO.
• RPAA operational risk lead. Owns the operational risk framework required by the RPAA, distinct from the PCMLTFA program.
• Independent reviewer. A party with no operational involvement, engaged for the two-year PCMLTFA review and any RPAA-mandated review.

What FINTRAC examiners look for in a PSP

PSPs face examination questions that traditional MSBs do not. The most-frequent in current examinations:

• How do you know what your merchants are actually processing through your rails, and how does that compare to their declared expected volumes?
• Walk me through a sanctions hit on a merchant’s beneficial owner. What did your program do, and how long did it take?
• Where is the audit trail for an alert generated by your ML-based monitoring layer that you closed without action?
• How does your RPAA significant incident process interact with your STR pipeline when they overlap on the same event?
• What does your training program show for the people approving merchant onboarding in the last quarter?

How BriteBase helps PSPs

BriteBase is built for the dual-regime reality of Canadian PSPs. The AML Operating Platform covers KYB, sanctions screening, transaction monitoring, case workflow, and FINTRAC reporting integration. Compliance-as-a-Service adds a fractional CAMLO with payments experience and the practitioner bench to run the program day to day. For PSPs running their own compliance team, the platform tier provides the system of record while the team retains operational ownership.

FAQ