Payments in Canada are growing — and so is the regulatory apparatus around them. The Retail Payment Activities Act (RPAA) has introduced a new layer of governance for payment service providers (PSPs), and FINTRAC's appetite for oversight in this space is clearly expanding. Fraud is a stated priority. Virtual currency reporting is getting more scrutiny. And the volume of regulated entities is set to grow as RPAA registration takes full effect.

But here's the honest reality that practitioners are talking about at industry events: the guidance has not kept pace with the complexity of how modern PSPs actually operate. The result is a sector making defensible judgment calls in the absence of clear answers — and hoping regulators eventually catch up with written guidance that matches what they're verbally telling entities.

This post is a candid look at the real compliance challenges PSPs face today, drawn from industry conversations and compliance practitioners navigating these issues on the ground.

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?

This is not a hypothetical edge case. It comes up constantly in practice, 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. This is an area where compliance teams are making documented risk decisions and waiting 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.

This is actually one area where 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 require investigation to populate
• The report needs to be submitted within 30 days of the day the reasonable grounds threshold was reached

This is where drag-and-drop report building, pre-populated field logic, and structured narrative templates make a meaningful difference. The bottleneck isn't usually knowing what to file — it's the friction involved in actually 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.

Here's the practical tension PSPs describe: the Travel Rule is the one legitimate pathway where you must pass along customer-of-customer data. It's a narrow, defined exception to the general principle that a PSP's compliance obligation focuses on its own customers. But that narrow exception creates real operational challenges.

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 of Travel Rule compliance found themselves in the position of having built the process, but sending to peers who hadn't yet — meaning the information was technically transmitted but not meaningfully 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 genuinely no avenue exists 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

In this scenario, PSPs often have the merchant's email and name — obtained through their service agreement — but lack the additional address-level data that 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 applicable, 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 of the more counterintuitive field scenarios — but one FINTRAC explicitly allows — is when 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. This is allowed and recognized by FINTRAC — you simply fill in 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 with merchant-facing businesses face a structural data challenge: their compliance relationship is with the merchant, but FINTRAC reports may ask for information about the merchant's customers — information the PSP never collected and, under their 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 is genuinely not applicable, 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 out 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 exceed $10,000 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.

A recurring theme in PSP compliance conversations is the disconnect between what FINTRAC forms ask for and what PSPs can realistically provide given their business model.

Some observations from practitioners:

• Asterisked fields (mandatory) for information that a PSP structurally cannot obtain — because it lives with the merchant, not with the PSP — create a genuine compliance 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-specific scenarios has been slow, and informal email exchanges with the regulator — while sometimes helpful — don't constitute authoritative guidance you can rely on in an examination

These aren't hypothetical compliance edge cases — they're the daily operational reality for PSP compliance teams. The manual burden of gathering, populating, and submitting FINTRAC reports accurately is real, 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 specifically for this environment:

The RPAA will continue to mature. More entities will become registered PSPs. FINTRAC examination capacity for the PSP sector will grow. And the informal interpretive clarity that practitioners have cobbled together through industry conversations and regulator emails will eventually need to be replaced by published guidance.

A few things to watch:

• Travel Rule policy updates — FINTRAC is likely to issue more specific guidance on originator/beneficiary requirements for virtual currency transfers as the sunset period for the sunrise problem becomes untenable
• Two-leg filing clarification — this is too widespread a compliance question to remain unaddressed; expect an interpretive notice or updated guidance within the year
• PSP-specific examination standards — as FINTRAC builds examination experience with PSPs, expect more sector-specific guidance to emerge from what they observe 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.