Ongoing AML Monitoring for PSPs Using Third-Party Onboarding Tools

A payment business that uses a third-party onboarding provider maintains ongoing AML monitoring by treating the vendor's output as an input, not as the monitoring itself. The vendor's results need to reach four places:

• the business's own customer risk assessment
• its transaction monitoring
• a schedule of risk-based and event-driven reviews
• a documented escalation process

The business also has to know which system holds each piece of customer information, who updates it when it changes, and what happens when the vendor's data is late, wrong or unavailable.

That applies in full to businesses with FINTRAC ongoing monitoring obligations, such as MSBs and foreign MSBs, once a business relationship exists. Many payment service providers (PSPs) are MSBs, but the label "PSP" does not by itself create those obligations. A business needs to settle its regulatory position before designing its monitoring.

Which framework applies: FINTRAC, the RPAA, or both

Two federal regimes can apply to a payment business, and they do different jobs.

The PCMLTFA (administered by FINTRAC) applies to reporting entities, including MSBs and foreign MSBs. A business that remits or transmits funds, deals in virtual currency or deals in foreign exchange may be an MSB, whether or not it calls itself a PSP. For an MSB, a business relationship begins the second time the MSB is required to verify a client's identity, or when it enters a service agreement with an entity client in Canada. Once that happens, FINTRAC's ongoing monitoring requirements apply. Not every end user of a payment service is in a business relationship, so a PSP should not assume it must monitor every user the way it monitors established clients. The wider set of obligations is summarized in PCMLTFA requirements for reporting entities.

The Retail Payment Activities Act (supervised by the Bank of Canada) governs PSP registration, operational risk management and end-user fund safeguarding. Registration provisions took effect on November 1, 2024. The requirements to establish risk management and safeguarding frameworks have been in force since September 8, 2025. The RPAA is not an AML regime. It requires PSPs to manage the operational risk of their third-party service providers, but it does not require customer due diligence or suspicious transaction monitoring.

Whether an onboarding vendor is an RPAA third-party service provider depends on the facts. Under the Bank of Canada's operational risk and incident response guideline, a third-party service provider is a person or entity that provides a service related to a payment function under contract, and is not an employee, agent or mandatary. The Bank's supervision FAQ says classification depends on the contractual arrangement. A KYC tool that gates account opening for a payment service may meet that definition. A standalone data lookup with no connection to a payment function may not. Make the assessment and document it.

What onboarding providers actually do

Vendors differ substantially. Depending on the product and contract, a provider may:

• capture identity data and documents
• support identity verification under a FINTRAC method, such as document authentication and selfie matching for the government-issued photo ID method
• collect business registry and beneficial ownership data
• screen against sanctions and PEP lists
• produce a preliminary risk score
• store evidence and manage document refresh requests

Some run a single check at onboarding. Others re-screen continuously, or offer workflow tools. Some only return results for data the business submits through an API.

Three distinctions matter legally:

• A vendor is not automatically an agent or mandatary. FINTRAC's identity verification methods allow a reporting entity to use an agent or mandatary to verify identity. That requires a written agreement or arrangement, and the entity must obtain the information the agent relied on as soon as feasible. Buying a software service does not create that relationship by default.
• A subscription is not the reliance method. Reliance means relying on verification already carried out by another reporting entity, or a qualifying affiliated foreign entity, under a written agreement. Its conditions differ.
• A vendor "pass" is not, by itself, proof that statutory verification was done. The business needs to know which method was used and to hold the records that method requires. For the government-issued photo ID method used remotely, the business must have a process to authenticate the document, confirm it is valid and current, and match the name and photo to the person.

These points, and the methods themselves, are covered in detail in FINTRAC identity verification methods.

Three kinds of monitoring that are easy to merge

Screening sits across the first two columns. A sanctions or PEP screen is one input to customer monitoring, and sometimes to transaction review. A vendor that rescreens daily has not taken over the monitoring function. Detection rules and investigation workflows are covered in AML transaction monitoring processes.

Who does what after onboarding

Illustrative allocation. Actual responsibilities depend on the contract, the business's systems and its legal classification.

The vendor's duties are contractual. The reporting entity's obligations under the PCMLTFA stay with the reporting entity.

The onboarding-to-monitoring handoff

Data handoff failures are a significant operational risk when onboarding is outsourced: the data exists, but not where the monitoring happens. Map each element from the vendor to the system and team that use it after onboarding.

The table mixes three kinds of item. Some are required for reporting entities under FINTRAC's rules: client identification, beneficial ownership and the purpose and intended nature of the relationship kept up to date, plus records of monitoring. Some feed the risk assessment. Others, such as vendor-ID mapping and aging reports, are internal controls.

A risk-based monitoring cycle

1. Onboarding is completed and approved, with any exceptions recorded.
2. The business's own risk rating and rationale are recorded, not just the vendor's score.
3. Profile fields are synchronized to the monitoring and screening systems.
4. A baseline of normal activity is established.
5. Periodic reviews are scheduled according to risk.
6. Material changes trigger event-driven reviews.
7. Vendor alerts are reconciled with payment activity.
8. Analysts investigate exceptions.
9. Compliance updates risk ratings and applies enhanced measures where needed.
10. Outcomes, changes and evidence are recorded.

FINTRAC requires periodic monitoring based on the business's risk assessment, with enhanced ongoing monitoring for high-risk clients. It sets no universal review interval, and it does not require customers' identity to be reverified annually. An internal schedule might, for example, review low-risk customers every two years, medium-risk customers annually and high-risk customers quarterly. That is an operational choice to be justified in the business's procedures, not a regulatory timetable.

Events that should trigger a review

A trigger leads to a review, not a conclusion. A PEP match does not require closing the relationship. A screening alert is not a suspicious transaction. Where facts gathered in a review do give reasonable grounds to suspect, FINTRAC's suspicious transaction reporting guidance requires a report as soon as practicable once the measures establishing those grounds are complete. Outstanding vendor information is not a reason to delay a report once that threshold is met. Where a review needs information from the customer or a partner, structured requests for information keep those requests specific and documented.

When the vendor's score and your evidence disagree

A vendor's score is a technical output of the vendor's model. The customer risk assessment belongs to the reporting entity, based on its own risk assessment. FINTRAC's guidance expects client risk to reflect products and delivery channels, geography, client characteristics and activity patterns. A vendor's default model may not weigh these the way the business's own risk assessment does.

Example (hypothetical). A vendor rates a corporate customer "low". The PSP's records show:

• monthly volume three times the expected range
• a layered ownership structure through a foreign holding company
• payments to two corridors the PSP rates as higher risk

An analyst finds the discrepancy through a scheduled comparison of vendor scores against internal risk factors. The compliance officer reviews the ownership documents and the activity, and overrides the rating to high. The reasons, the evidence relied on and the approval are recorded. The customer moves to enhanced monitoring, with a shorter review cycle and corridor-specific rules.

"Vendor approved" is not a compliance decision. It records that a tool returned a result. The decision is the business's, made against its own risk assessment. The vendor's labels do not determine whether a client receives high-risk treatment under FINTRAC's rules.

FINTRAC's risk assessment guidance also expects reporting entities to assess the risks of new developments and new technologies before implementing them. Adopting a new onboarding platform, or materially changing how onboarding works (for example, moving from in-person to remote verification or adding a new verification method), will often bring new technology and business-model risks, and should then be assessed before launch. A routine software update that does not change verification, screening or data flows is less likely to need a separate assessment. Document which way each change was judged.

When customer information changes

Changes to a customer's information need to reach every place it is used. When the address, occupation or business activity, ownership, legal structure, identification details, risk rating, PEP status or geographic exposure changes:

1. update the customer master record
2. push the change to monitoring and screening
3. reassess risk where the change is material
4. record what changed, the source and the date
5. check whether the change affects any reporting data, such as party details in reports

Updating information is not the same as verifying identity again. FINTRAC does not require identity to be reverified for later transactions where it was verified properly and the records were kept, unless there are doubts about the information used. Doubt, rather than any change at all, is what requires reverification. High-risk clients may also call for enhanced measures to keep information current.

Data quality and integration failures

Integration failures produce silent gaps. Monitoring appears to run, but on incomplete or stale data. A dashboard with no alerts does not show that monitoring is working.

Reconciliation counts, missing-field reports, freshness checks and manual fallbacks are recommended controls. No FINTRAC rule prescribes a polling frequency, an uptime level or an architecture.

Enhanced monitoring for high-risk customers

For a high-risk client, FINTRAC requires enhanced ongoing monitoring and special measures, such as enhanced measures to verify identity or to keep client information up to date. Assigning a high-risk label does not, on its own, meet that requirement. The measures have to change what happens in practice:

• reviews that are more frequent or deeper
• additional information on the source of funds or business activity
• rules tuned to the customer's specific risk, such as the high-risk corridors
• closer examination of inconsistent transactions
• documented escalation

Example (hypothetical). A fintech marketplace payout client is rated high risk after it adds sellers in a high-risk jurisdiction. Its enhanced plan includes:

• monthly activity review against declared seller volumes
• a corridor-specific alert threshold
• updated seller-onboarding information from the client
• compliance sign-off at each review

Enhanced due diligence at onboarding, enhanced ongoing monitoring and identity reverification are different things. The plan above uses the second and does not reverify the client.

Vendor due diligence and oversight checklist

Before relying on an onboarding provider, and periodically afterwards, the business should be able to answer these questions:

• Which services are in scope, and which checks are one-time versus recurring?
• Which FINTRAC verification methods does the service actually support, and what records does each produce?
• How quickly do updates and screening results arrive, and are alerts pushed or do they have to be pulled?
• Will the vendor give notice of changes to scoring or screening models?
• How are false positives and missed matches reviewed, and can the business test them independently?
• Can the business access raw evidence and audit logs on request?
• Which subcontractors materially support the service, and where is the data processed?
• How are incidents and outages notified, and how quickly?
• Are privacy safeguards and access controls adequate?
• How do termination, migration and data export work?
• Who is responsible for fixing problems the vendor causes?

Which of these questions are legal requirements depends on the business's status and on the vendor. Three layers apply differently:

As covered above, not every onboarding supplier meets the RPAA definition, so record the classification of each vendor before deciding which layer applies. Beyond the mandatory elements, the Bank's guideline sets expectations, using "should", on materiality assessment, contract terms, compensating controls and termination planning. Where the PSP is also an MSB, its RPAA assessment of a vendor and its FINTRAC risk assessment are separate documents with different purposes, even though the same vendor facts may feed both.

Privacy and information security

Onboarding vendors hold some of a business's most sensitive data. Under PIPEDA's fair information principles, and under provincial private-sector laws where they apply, the business remains accountable for personal information it transfers to a service provider. In practice:

• Collect only what is needed for identified purposes, with consent or another valid legal basis for collection and disclosure.
• A service agreement is not, on its own, unlimited authority to disclose or reuse customer information.
• Use secure transfer and role-based access. Avoid copying identity documents into every connected system. A secure evidence reference with controlled access is often enough.
• Agree retention, deletion, audit-log integrity, subcontractor and cross-border processing terms.
• Plan exit and data export so that records stay accessible after the relationship ends.
• Treat breaches at the vendor as the business's own incident for assessment under the applicable privacy breach rules.

Illustrative monitoring control register

Illustrative internal monitoring control register: not a FINTRAC or Bank of Canada prescribed form. All entries are fictional.

The register shows that the process ran and who decided what. It is evidence of the process, not proof of compliance on its own.

Two worked scenarios

Scenario 1: Ownership changes after automated KYB onboarding

Hypothetical. A Canadian MSB onboards a corporate client through a KYB tool. At onboarding, the client has two shareholders at 50% each. Eight months later, the corporate registry feed the vendor monitors shows a new shareholder holding 35%, and the same change appears in documents the client sends with a contract amendment.

• Detection: The vendor's registry change alert and the client's documents agree.
• Records updated: The MSB updates the beneficial ownership record. FINTRAC requires reporting entities to obtain information on those who own or control 25% or more of a corporation, take reasonable measures to confirm it, and keep it up to date. The MSB also updates the ownership structure and the authorized persons. If a bank or payment partner relies on the MSB's KYB file, it may ask for the updated information too; see how KYC, KYB and CDD fit together.
• Screening and verification: The new owner is screened for sanctions and PEP status. Identity verification of the client is not repeated, because the client entity's existence is not in doubt. The beneficial ownership information is confirmed under the MSB's reasonable-measures procedure.
• Risk reassessment: The new owner is linked to a business in a higher-risk sector, so the rating moves from medium to high. The compliance officer approves an enhanced monitoring plan.
• Monitoring changes: The new owner's name is added to party-matching rules, and the high-risk review cycle starts.
• Evidence kept: The registry extract, the client documents, the screening results, the risk rationale and the approval.
• Reporting: The ownership change is not, by itself, a reason to report. A suspicious transaction report would be considered only if the reviewed facts gave reasonable grounds to suspect.

Scenario 2: A vendor change delays screening updates

Hypothetical. A PSP that is also a registered MSB receives continuous screening alerts from a provider through webhook events. After the vendor changes its API version, the PSP's listener rejects about a fifth of events for eight days without raising an error.

• Detection: The weekly reconciliation of event counts shows that the vendor sent 1,240 events and the PSP processed 994.
• Affected scope: The 246 rejected events relate to 211 customers. Payments by those customers in the gap period are pulled for review.
• Containment: The listener is fixed and rejected-event alerting is added. Until the fix is confirmed, the affected customers' payments go to manual review.
• Backfill: The vendor resends the events. Each is processed and dispositioned in priority order: potential sanctions matches first, then PEP changes, then the rest.
• Investigation: One resent alert is a likely PEP match for a customer with high recent volume. That case goes into a standard monitoring investigation. The others close as false positives or minor data updates.
• RPAA assessment: Separately, the PSP works through its RPAA incident procedure and records each answer:
  • Is the service related to a payment function? The PSP had already classified the screening provider as a third-party service provider, because screening results determine whether payments are released on its platform. That classification was on file from its vendor assessment, not made after the event.
  • Did an incident occur? The guideline makes the PSP responsible for deciding whether an event at a third party is an incident for the PSP. An unplanned failure of its own system to process vendor data for eight days meets its internal definition, so it opens an incident record and investigates the root cause and impact. A screening failure is not automatically reportable; this step only establishes that it must be assessed.
  • Was there a material impact on an end user, a PSP or a clearing house? The documented facts: no payment was released to a party later confirmed as listed or sanctioned; the manual-review hold delayed some payments by less than one business day; no end-user funds were lost; no personal information was accessed or disclosed. Continued payment processing was not treated as decisive. The PSP also considered whether any customer was wrongly blocked or delayed, whether a listed party could have been paid, and the length and extent of the gap.
  • Decision: On these facts the PSP concluded that the impact was not material, recorded its reasoning, the approver and the date, and noted that it would reassess if the investigation found new facts, such as a payment to a listed person or end-user payments held for days. Had the impact been material, the guideline requires reporting to the Bank and to materially affected individuals or entities without delay, under RPAA s.18.
  • Why it stays separate: The AML remediation asks whether customers were screened and whether anything must be reported to FINTRAC. The RPAA assessment asks whether the event affected retail payment activities. The two use different tests and records, and the outcome of one does not decide the other.
• Vendor remediation: The vendor agrees to give advance notice of API changes and to send a daily event-count file.
• Closure: A month of clean reconciliations, plus a test with injected events, confirms the fix before the exception is closed and reported to management.

The integration failure itself did not require an STR. Only the facts uncovered by the review could lead to one.

Testing whether monitoring works

A practical test cycle:

• sample recently onboarded customers and trace each vendor outcome into the customer record and the monitoring profile
• check risk ratings and their rationale against the business's own methodology
• confirm that high-risk customers actually receive the enhanced measures in their plan
• inject or replay screening changes to test synchronization
• check alert dispositions and escalation records
• compare changes in risk rating with changes in monitoring coverage
• confirm that a sample of verification evidence can still be retrieved

Four activities are related but distinct:

• Routine quality assurance is an internal choice.
• Vendor performance monitoring is a contractual and governance control. For a registered PSP whose vendor is an RPAA third-party service provider, it is also a regulatory requirement, alongside the annual assessment.
• The effectiveness review is a FINTRAC requirement: under the compliance program requirements, reporting entities must review the effectiveness of their policies and procedures, risk assessment and training. Each review must start no later than 24 months after the start of the previous review, and the previous review must be completed before the next one starts. The review is done by an internal or external auditor, or by the business itself if it has no auditor.
• RPAA operational-risk testing applies to registered PSPs under the Bank of Canada guideline.

None of these substitutes for another.

Ongoing monitoring checklist

• Regulatory status confirmed: FINTRAC reporting entity, RPAA PSP, or both
• Vendor scope documented: one-time versus recurring services, supported verification methods
• Verification method and evidence confirmed as available for each customer
• The business's own risk rating, with rationale, recorded alongside any vendor score
• Profile, ownership and screening data synchronized to monitoring, with reconciliation checks
• Event-driven triggers defined and routed to owners
• Review frequency set by risk and documented
• Enhanced measures specified and applied for high-risk customers
• Vendor data failures logged, escalated and backfilled
• STR assessment kept separate from the timing of vendor data
• Decisions and evidence recorded
• Monitoring tested, and the effectiveness review planned
• Each vendor's RPAA status recorded; for qualifying third-party service providers, assessments done at least annually and before contract changes, with dates, scope and findings kept
• RPAA incident assessments documented separately from AML remediation, where applicable

Frequently asked questions

What if the onboarding vendor shuts down and evidence becomes inaccessible?

Act while the vendor's systems or administrators can still be reached, and request a full export of evidence and audit logs. Then build an inventory, by customer, of which records were recovered and which were lost. For each affected customer, check whether the records the business still holds meet the requirements of the verification method used, and decide case by case, starting with high-risk and active customers. Report the gap to senior management as a control failure.

Can records from an old KYC vendor be used after moving to a new provider?

Yes, provided the migrated records are complete for the verification method used and stay linked to the right customer. A change of provider is not, by itself, a reason to verify identity again. The practical risks are mapping errors and lost fields, so reconcile record counts, spot-check a sample against the old system, and test retrieval in the new system before the old contract ends.

How should historical risk changes be preserved after replacing a monitoring system?

Export the full rating history with the dates, rationales and approvers, not just current ratings, and link it to each customer record in the new system. Otherwise the business can no longer show why a customer was treated as high risk two years earlier, or when its enhanced measures began.

Third-party tools speed up onboarding, but the risk assessment, monitoring procedures and governance that connect them remain the reporting entity's. ComplyFactor builds business-specific AML compliance programs for Canadian MSBs and payment businesses. These include the risk assessment, customer risk rating framework, monitoring procedures and governance that ongoing monitoring depends on.