PSP compliance primer: AML and sanctions expectations in Canada
A payment service provider (PSP) is an entity that performs one or more payment functions (fund holds, transfers, electronic funds transmissions, currency conversions, or merchant acquiring) as a service for end users. Canadian PSPs sit under two regulatory regimes at once: the Retail Payment Activities Act for operational risk, and the PCMLTFA for AML and sanctions where the PSP qualifies as a money services business. This primer covers both and explains how to comply at scale.
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:
- Providing or maintaining an account that, in relation to an electronic funds transfer, is held on behalf of one or more end users.
- Holding funds on behalf of an end user until they are withdrawn or transferred.
- The initiation of an electronic funds transfer at the request of an end user.
- The authorization of an electronic funds transfer or the transmission, reception, or facilitation of an instruction in relation to an electronic funds transfer.
- 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.
What Canadian AML framework 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.
What are the three layers of a PSP compliance program?
The three layers of a PSP compliance program, with PSP-specific items at each layer.
Which reports does a PSP have to file?
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.
What are a PSP’s sanctions screening obligations?
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.
What does the PSP technology stack need to cover?
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.
What in-house expertise does a PSP need?
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.
- 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 do 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 does BriteBase help PSPs?
BriteBase is built for the dual-regime reality of Canadian PSPs. The screening platform covers KYB screening, sanctions screening, ongoing monitoring, case workflow, and audit-ready case history, with a self-serve API for PSPs that want to embed screening in their own stack. The platform provides the system of record while your compliance team retains operational ownership.
FAQ
What is a payment service provider (PSP) under Canadian law?
Under the Retail Payment Activities Act (RPAA), a PSP is an entity that performs one or more retail payment functions as a service or business activity. The five functions are: providing or maintaining an account held on behalf of end users in relation to an electronic funds transfer; holding funds until they are withdrawn or transferred; initiating an electronic funds transfer at an end user's request; authorising an electronic funds transfer or transmitting, receiving, or facilitating a related instruction; and providing clearing or settlement services. Separately, under the PCMLTFA, a PSP that performs money transmission, foreign exchange dealing, or virtual currency activity for the public is also a money services business. Most PSPs handling cross-border or multi-currency flows fall under both regimes at once, which means the same firm answers to the Bank of Canada for operational risk and to FINTRAC for AML and sanctions.
Do PSPs have to register with both the Bank of Canada and FINTRAC?
Often yes. RPAA registration sits with the Bank of Canada and covers operational risk and end-user fund safeguarding. PCMLTFA registration sits with FINTRAC as a money services business and covers AML and sanctions obligations. A PSP that performs money transmission, foreign exchange, or virtual currency activity for the public is required to register under both, and the two are operationally separate. Registrations renew on different cycles, examinations come from different bodies, and the compliance program documentation must reflect both regimes rather than treating them as one. This is not redundancy: the RPAA governs whether the payment function operates safely, while the PCMLTFA governs whether money laundering and sanctions risk is controlled. A firm that registers with one and neglects the other has a live gap. The practical implication is that a PSP has to run both obligations in lockstep, with a single program that documents where the two regimes intersect.
What is the difference between RPAA obligations and PCMLTFA obligations?
The two regimes govern different risks. RPAA obligations cover operational risk: end-user fund safeguarding, third-party risk management, incident response, and business continuity. PCMLTFA obligations cover AML and sanctions: customer identification, suspicion-based reporting, sanctions screening, the five program pillars, and FINTRAC examination. The distinction matters most when a single event touches both. An RPAA significant incident notification is operational: it reports that a payment function was disrupted, and under the Bank of Canada framework it is due within 24 hours. A PCMLTFA Suspicious Transaction Report is suspicion-based: it reports that activity looks like money laundering or terrorist financing, filed as soon as practicable after reasonable grounds to suspect. The same underlying event can trigger both, so the compliance program must specify a distinct path for each. Treating one as a substitute for the other is a documentation gap that examiners from either body can surface during a review.
What is the most common FINTRAC examination finding for Canadian PSPs?
The most-frequent examination finding for Canadian PSPs is incomplete visibility into end-user activity processed through merchants. 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 to have visibility into the merchant's end users where the PSP's services touch identifiable individuals. Where that visibility is missing, the program cannot show it understands the activity moving across its rails, which is exactly what examiners probe. The failure pattern is treating merchant due diligence as a one-time onboarding step rather than an ongoing obligation. A merchant whose actual processing diverges materially from its declared expected volumes is a textbook examination talking point, because that drift is a signal the program should have detected. Closing this finding means documenting an approach for identifying and risk-assessing both the merchant and the end-user activity, then monitoring it continuously.
What sanctions lists do Canadian PSPs have to screen against?
At minimum, PSPs screen against the Special Economic Measures Act regulations, Justice for Victims of Corrupt Foreign Officials Act listings, United Nations Act regulations, and Criminal Code listed entities. Operationally, the OSFI Consolidated Lists are the most practical single source, and PSPs with US-jurisdiction processing should also screen against the OFAC SDN list. What is distinctive for PSPs is that screening applies at three levels of the value chain. At the merchant level, screen the legal entity, its directors, beneficial owners at the 25 percent threshold, and signing officers, both at onboarding and continuously. At the transaction level, screen originator and beneficiary names on transfers crossing the PSP's rails, especially international transfers under the Travel Rule. At the end-user level, screen identifiable individuals wherever the PSP's services touch them directly, such as account holding or money transfer initiation. Screening only the merchant leaves the transaction and end-user layers exposed.
How does Bill C-12 affect Canadian PSPs?
Bill C-12 introduced the statutory standard that a Canadian compliance program must be reasonably designed, risk-based and effective. The third word is the change: regulators now ask whether the program actually works, evidenced by outcomes, not just whether policies exist. For PSPs operating at scale, that effectiveness test is demanding because examiners look at measured outcomes, including false-positive rates on screening, STR quality and timing, merchant volume drift detection, and audit trail completeness. A PSP running tens of thousands to millions of transactions a day cannot demonstrate effectiveness through manual review alone; it has to rely on layered detection with human approval on regulated decisions. The standard applies regardless of whether the program uses traditional rule-based scenarios or modern AI-based anomaly detection, so adopting newer technology does not change the bar, only the means of meeting it. The practical implication is that PSPs must be able to evidence performance, not just process.
What does a PSP compliance technology stack include?
A defensible PSP technology stack covers seven capabilities. Merchant onboarding (KYB) handles legal entity verification, beneficial ownership capture, control person identification, document collection, and risk scoring. End-user KYC applies wherever the PSP touches identifiable end users, with full identification, address verification, and beneficial ownership where relevant. Real-time sanctions and PEP screening runs at every onboarding and every transfer above threshold, with continuous re-screening of the customer book against list updates. Transaction monitoring uses rule-based scenarios for PSP-specific patterns, such as merchant volume drift, BIN-level anomalies, velocity spikes, and cross-border corridor risk, often layered with machine learning. Case management holds alerts, investigations, dispositions, STRs, and supporting evidence in one workflow. FINTRAC reporting integration automates population and filing of STRs and EFTRs via F2R, reconciled to case records. Finally, RPAA operational risk controls cover end-user fund safeguarding, third-party risk management, incident response, and business continuity required by the Bank of Canada.
Sources
Reading is useful. A conversation is faster.
Book a platform demo and we will walk you through real-time sanctions, PEP, and adverse-media screening and the data coverage that fits your firm.
Book a call