PSP & FINTRAC Compliance: The Questions Still Open

Payments in Canada are growing, and so is the regulation around them. The Retail Payment Activities Act (RPAA) adds a new layer of governance for payment service providers (PSPs), and FINTRAC plainly wants to oversee more of this space. Fraud is a stated priority. Virtual currency reporting draws more scrutiny. And the number of regulated entities will grow as RPAA registration takes full effect.

Practitioners say it openly at industry events: the guidance has not kept pace with how modern PSPs work. So the sector makes defensible judgment calls without clear answers, and hopes the regulator will one day put in writing what it now says aloud.

This post sets out the compliance problems PSPs face today, drawn from industry conversations and from practitioners working through them.

One of the most persistent sources of confusion for PSPs is what gets called the "two-leg" problem: when a transaction flows through a payment processor, does the PSP have to file a report covering both the incoming and outgoing legs, or just one?

It is no edge case. It comes up all the time, and the industry is divided:

• Some companies file for both legs of the transaction
• Others file for only one
• Still others apply different logic depending on the transaction type and their position in the payment chain

The regulators are still working through this. Informal conversations with FINTRAC examiners have not produced consistent answers, and there is no published interpretive guidance that definitively settles it. Here compliance teams make documented risk decisions, and wait for formal guidance to confirm or correct them.

The safest posture right now is to:

1. Document your interpretation in a written compliance memo
2. Note what industry peers are doing, to the extent known
3. Log any verbal guidance received from FINTRAC and who provided it
4. Set a review trigger for when formal guidance is published

Fraud is explicitly on FINTRAC's radar for PSPs, and Suspicious Transaction Reports (STRs) related to fraud activity are receiving heightened attention during examinations.

Here, at least, the obligation is clearer: if you have reasonable grounds to suspect a transaction is related to fraud, you must file. The challenge is operational: gathering the right information, documenting the grounds for suspicion, and completing all applicable fields correctly before the filing deadline.

In practice, fraud STR workflows tend to be the most manual, time-pressured process in a PSP's compliance operation. The scenario often looks like this:

• A fraud alert fires from your transaction monitoring system
• A compliance analyst needs to pull transaction details, counterparty information, and relevant account history
• They need to articulate the grounds for suspicion clearly in the narrative
• All applicable FINTRAC fields need to be completed, including those that take investigation to fill
• The report needs to be submitted as soon as practicable once the reasonable grounds threshold is reached. There is no fixed deadline to work back from, and unjustified delay is itself a violation

This is where pre-filled fields, checks on every field and a narrative drafted from the case evidence make a real difference. The bottleneck is rarely knowing what to file. It is the friction of completing the report correctly, and quickly.

FATF Recommendation 16, the Travel Rule, requires that originator and beneficiary information travel with wire transfers and virtual currency transactions above certain thresholds. In Canada, FINTRAC has incorporated Travel Rule obligations for virtual currency transfers.

PSPs describe the tension this way: the Travel Rule is the one legitimate case where you must pass along customer-of-customer data. It is a narrow, defined exception to the principle that a PSP's compliance obligation centres on its own customers. Narrow as it is, it makes real operational trouble.

The "sunrise problem" is widely recognized in the crypto compliance industry: you can only successfully transmit Travel Rule data if your counterparty can receive it. Early adopters built the process, then found themselves sending to peers who had not. The information was transmitted, but not, in any useful sense, received.

What PSPs are doing in practice:

• Building outreach processes to gather Travel Rule data from counterparties before or during the transaction
• Accepting that some transfers will go to entities without Travel Rule capability and documenting this as a known gap with a mitigation plan
• Using N/A designations or leaving fields blank only where there is truly no way to obtain the information, and documenting why

PSPs handling virtual currency face two distinct transaction scenarios, each with its own field completion challenges:

Type 1: Crypto-to-Invoice (Client Pays in Crypto)

A client sends crypto to pay a merchant invoice. The PSP is in the middle. Fields that seem straightforward become complicated when:

• The merchant's wallet address is known, but there is no IP address or physical address associated with it
• The counterparty used an external wallet that has no KYC data attached
• The "conductor" is a business, not an individual, and the fields expect individual-style data

Here PSPs often have the merchant's email and name, from the service agreement, but not the address-level data some FINTRAC fields expect. The practical answer is to report what you have and document that reasonable measures were taken to obtain what you don't.

Type 2 (EFTR): Client Receives Crypto From Their Client

Your client receives crypto from a third party into their wallet, which you custody. Now:

• You know your client (the beneficiary)
• You may have partial or no data on the originating party
• The Travel Rule, if it applies, should carry originator information, but may not have

This is where the conductor = beneficiary scenario frequently arises legitimately, and it's explicitly recognized by FINTRAC.

One field scenario seems odd but is explicitly allowed by FINTRAC: the same entity appears as both conductor and beneficiary on a transaction report.

This happens when someone moves their own funds for their own benefit. A merchant sends crypto into their own wallet that you custody. They are the one who initiated the transfer (conductor) and the one who benefits from it being deposited (beneficiary). Both fields should contain the same entity. FINTRAC allows and recognizes this: you simply enter the same person or business in both fields.

Where teams run into problems is when they leave the beneficiary field blank in these scenarios, or insert placeholder text, when the correct answer is simply to repeat the conductor information.

PSPs that serve merchants face a structural data problem. Their compliance relationship is with the merchant, but FINTRAC reports may ask about the merchant's customers: information the PSP never collected and, under its business model, was never expected to collect.

The general principle: PSPs are not expected to know their customers' customers. Your compliance obligations run to the entities you have a direct service relationship with. The Travel Rule carves out a specific, narrow exception for required pass-through data.

In practice, what PSPs have access to for merchants is typically:

• Business name
• Contact email
• Wallet address(es)
• Service agreement details

What they often don't have:

• Physical address
• Individual beneficial owner details beyond KYB minimums
• IP address of the sending party
• Transaction-level customer data from the merchant's own users

The compliance answer here is: use what you have, document what you don't, and explain why reasonable measures to obtain the missing data were either taken or weren't required. Where a field truly does not apply, leave it blank. Do not insert "N/A" or placeholder characters.

Large Virtual Currency Transaction Reports (LVCTRs) are triggered for virtual currency transactions of $10,000 or more. The obligation applies to both:

• Incoming transactions: crypto received into a wallet you custody or control (who sent it, from where, how much)
• Outgoing transactions: crypto sent from a wallet you custody or control (where it goes, to whom, how much)

For PSPs, this creates a bilateral reporting obligation that mirrors the two-leg problem: you may need to report on the receipt of funds and again on their disposition.

Aggregate Reporting to the Same Beneficiary

Multiple transactions to the same beneficiary within a 24-hour period that together total $10,000 or more are treated as a single reportable transaction for LVCTR purposes. This is an area where:

• Transaction monitoring systems need to aggregate across counterparty, not just per-transaction
• The reporting logic is more complex than single-transaction thresholds
• Internal data sharing between teams (transaction monitoring, compliance, operations) is critical

If your systems track transactions individually without counterparty aggregation, you may be missing reportable events.

One theme recurs in PSP compliance conversations: the gap between what FINTRAC forms ask for and what a PSP's business model lets it provide.

Some observations from practitioners:

• Asterisked fields (mandatory) for information a PSP structurally cannot obtain, because it lives with the merchant and not the PSP, create a real dilemma
• "Reasonable measures" is the legal standard, but what counts as reasonable for a PSP vis-à-vis its merchants isn't always clear
• Some entities have chosen to document specific fields as "N/A" in their internal processes with a written justification, while FINTRAC's formal position is that blank is preferred over N/A for non-applicable fields
• Written interpretive guidance from FINTRAC on PSP scenarios has been slow, and informal emails with the regulator, though sometimes helpful, are not authoritative guidance you can rely on in an examination

These are not edge cases. They are the daily work of PSP compliance teams, and gathering, filling in and submitting FINTRAC reports by hand is a real burden, especially when:

• Fraud STRs require rapid information gathering under time pressure
• LVCTR aggregation logic needs to run across counterparties, not just transactions
• Field completion decisions need to be consistent, documented, and auditable

Quantoflow is built for this work:

The RPAA will mature. More entities will register as PSPs. FINTRAC will examine the sector more. And the informal answers practitioners have pieced together from industry conversations and regulator emails will, in time, have to give way to published guidance.

A few things to watch:

• Travel Rule policy updates: FINTRAC is likely to issue more specific guidance on originator and beneficiary requirements for virtual currency transfers as the sunset period for the sunrise problem becomes untenable
• Two-leg filing clarification: the question is too widespread to stay unanswered; expect an interpretive notice or updated guidance within the year
• PSP-specific examination standards: as FINTRAC gains experience examining PSPs, expect more sector-specific guidance drawn from what it sees in the field

For now, the standard of care is: make a documented, defensible decision on every ambiguous question, stay engaged with industry groups where interpretations are being shared, and build compliance infrastructure that can adapt when guidance changes.