5 Critical PSP Annual Report Mistakes That Trigger Bank of Canada Scrutiny

By Marco Rud / February 11, 2026

How to Avoid This Mistake

Implement Automated Shortfall Detection: Don’t rely on manual monitoring or periodic reconciliations. Deploy automated systems that flag any instance—even momentary—where:

• Funds received aren’t immediately placed in safeguarding accounts
• Insurance or guarantee coverage amounts fall below funds held
• Asset values decline below required thresholds
• Account balances don’t reconcile with ledger records

Document Every Instance: Create a shortfall log that records:

• Date and time shortfall occurred
• Date and time shortfall was remediated
• Specific root cause (processing constraint, insurance gap, operational error, etc.)
• Dollar amount of shortfall
• Measures taken to prevent recurrence

Report Proactively: When completing your annual report, include ALL instances from your shortfall log. Provide context about processing constraints, but don’t use explanations as justification for non-reporting. Demonstrate transparency about when protection gaps occurred and what you did to address them.

Conduct Pre-Submission Safeguarding Audit: Before finalizing your annual report, have an independent reviewer examine your safeguarding arrangements throughout the year specifically to identify unreported shortfalls. This catch-all review often identifies instances that operational teams didn’t flag or didn’t consider reportable.

For comprehensive support in establishing compliant safeguarding frameworks and shortfall monitoring systems, see ComplyFactor’s end-user funds safeguarding guidance and independent review services.

Mistake #2: Inadequate Third-Party Risk Management Documentation

The operational risk section of your annual report requires extensive disclosure about third-party service provider risk management. PSPs consistently underestimate the Bank of Canada’s expectations for the depth and rigor of third-party assessments.

What the Regulations Actually Require

Section 5(3) of the RPAR specifies that PSPs must assess third-party service providers on multiple dimensions:

Before Engaging:

• Ability to protect the PSP’s and end users’ data and information
• Protection of connections to and from the PSP’s systems
• Service provider’s risk management practices
• Appropriateness of roles and responsibilities

Ongoing:

• Service provider performance against defined standards
• How you’re informed of changes to services or risk practices
• How you’re notified of security breaches or incidents
• Adequacy of the provider’s incident response capabilities

Your annual report must confirm whether you conducted these assessments before entering into agreements and whether you regularly reassess providers during the relationship.

Common Inadequate Assessment Practices

Relying Only on SOC 2 Reports: Many PSPs conduct “third-party assessments” by reviewing the provider’s SOC 2 Type II report or other standardized audit reports.

Why This Is Inadequate: SOC 2 reports describe the provider’s general control environment, but don’t address PSP-specific requirements like how you’ll be notified of incidents affecting your operations, what the provider’s recovery time objectives are for your specific services, or how data protection applies to the particular types of end-user information you share.

Conducting Assessments After Engagement: Some PSPs engage service providers based on commercial considerations, then conduct compliance assessments as an afterthought to “check the box.”

Why This Is Inadequate: The RPAR explicitly requires assessments before entering into agreements. Post-engagement assessments don’t allow you to incorporate findings into contract negotiations, establish appropriate service levels, or potentially select different providers if risk management is inadequate.

Generic Risk Questionnaires: PSPs send providers generic vendor questionnaires covering broad topics like “Do you have a business continuity plan?” without tailoring questions to the specific services provided and risks created.

Why This Is Inadequate: Generic questionnaires don’t demonstrate understanding of the specific operational risks created by each third-party relationship. The Bank of Canada expects risk-based assessments where high-risk providers (those processing transactions, holding data, or critical to payment functions) receive more rigorous evaluation than low-risk providers.

Real-World Example: What Inadequate Documentation Looks Like

A PSP uses a cloud infrastructure provider for critical payment processing systems. When asked to provide the third-party assessment during an annual report follow-up inquiry, the PSP submits:

• The provider’s marketing brochure describing security capabilities
• A copy of the provider’s ISO 27001 certification
• Email correspondence showing the PSP’s IT manager asked the provider if they have “good security”

Why This Failed Regulatory Review:

• No evidence of systematic evaluation against RPAR requirements
• No assessment of how the PSP is informed of provider incidents
• No evaluation of provider incident response plans specific to the PSP’s operations
• No documentation of how connections between systems are secured
• No evidence the assessment occurred before the engagement decision

The Bank of Canada classified this as inadequate third-party risk management and required the PSP to conduct comprehensive assessments of all providers, implement ongoing monitoring processes, and submit remediation plans with specified completion timelines.

Why This Mistake Triggers Scrutiny

Systemic Risk Concerns: Third-party failures are a leading cause of payment system disruptions. PSPs with inadequate third-party risk management present elevated systemic risk to the broader Canadian payments ecosystem.

Concentration Risk: Many PSPs use common service providers (major cloud platforms, payment processors, banking partners). Widespread inadequate third-party management across multiple PSPs creates concentrated risk that regulators take very seriously.

Indicator of Broader Control Weaknesses: If your third-party risk management is superficial, the Bank of Canada reasonably infers that other aspects of your operational risk framework may also lack rigor. This triggers expanded examination of all operational risk management practices.

How to Avoid This Mistake

Develop Comprehensive Assessment Templates: Create standardized assessment templates that explicitly address each element required by paragraph 5(3)(b) of the RPAR:

• Data protection capabilities and controls
• Connection security measures
• Performance standards and monitoring
• Change notification procedures
• Breach and incident notification protocols
• Incident response plan adequacy
• Roles, responsibilities, and service level agreements

Customize templates for different provider categories (infrastructure, processing, data services, etc.) to ensure questions are relevant and specific.

Document Timing of Assessments: Maintain clear records showing when assessments were conducted relative to engagement dates. For new providers, include assessment dates in procurement documentation. For existing providers, establish assessment schedules and document completion dates.

Implement Tiered Assessment Rigor: Apply risk-based assessment depth:

Critical Providers (payment processing, core infrastructure, data hosting):

• Comprehensive written assessments
• On-site visits or virtual walkthroughs
• Technical security reviews
• Incident response scenario testing
• Annual reassessment

Significant Providers (non-critical but supporting payment activities):

• Detailed written assessments
• Vendor questionnaire responses
• Control documentation review
• Biennial reassessment

Standard Providers (ancillary services):

• Standard questionnaire assessment
• Certification review
• Triennial reassessment

Create Assessment Summaries: For each provider, maintain a summary document that captures:

• Assessment date and methodology
• Key findings and risk ratings
• Identified gaps or concerns
• Mitigation measures implemented
• Next reassessment date

These summaries allow you to quickly demonstrate assessment completion if regulators request evidence.

Establish Ongoing Monitoring: Third-party risk management isn’t a point-in-time assessment. Implement processes for:

• Receiving and reviewing provider incident notifications
• Monitoring provider financial stability and reputation
• Tracking provider regulatory compliance
• Reviewing provider audit reports and certifications
• Conducting periodic reassessments

Your annual report should reflect this ongoing monitoring, not just initial assessments.

For expert support in developing compliant third-party risk management frameworks and conducting regulatory-grade assessments, contact ComplyFactor’s operational risk advisory team.

Mistake #3: Inconsistent or Contradictory Responses Across Report Sections

This mistake often goes unnoticed until the Bank of Canada identifies discrepancies during review. Inconsistencies signal poor data management, lack of coordination, or insufficient understanding of regulatory requirements—all of which trigger closer scrutiny.

Common Types of Inconsistencies

Resource Allocation Contradictions:

Example: A PSP reports in the operational risk section that it employs 25 people, with 20 dedicated to retail payment activities. Later in the same section, it reports that 25 employees are dedicated to operational risk management and incident response.

The Problem: These numbers are mathematically impossible. If only 20 employees are dedicated to retail payments, the maximum who could be dedicated to operational risk management is 20, not 25.

What This Signals to Regulators: Either the PSP doesn’t understand what constitutes “retail payment activities,” doesn’t have adequate systems for tracking resource allocation, or filled out the form carelessly without quality control review.

Payment Function Contradictions:

Example: A PSP indicates in Section 2 that it does NOT perform payment function (b) (holding end-user funds) and therefore skips all safeguarding questions. However, in Section 4 (ubiquity metrics), it reports maximum end-user funds held of $2.5 million.

The Problem: If you don’t hold end-user funds, you can’t report holding $2.5 million of end-user funds. These sections directly contradict each other.

What This Signals to Regulators: The PSP either doesn’t understand whether it holds funds (a fundamental compliance determination), is attempting to avoid safeguarding requirements by misrepresenting its activities, or has inadequate quality control processes.

Incident Reporting Contradictions:

Example: A PSP reports zero incidents in the incident reporting section. However, in the operational risk section, it describes implementing new monitoring tools “in response to the Q2 system outage that affected transaction processing.”

The Problem: A system outage affecting transaction processing is an incident that should be reported in the incident section. The PSP’s own narrative contradicts its claim of zero incidents.

What This Signals to Regulators: The PSP either doesn’t understand what constitutes a reportable incident, didn’t properly coordinate responses across sections, or is selectively disclosing incidents only when necessary for narrative purposes while avoiding formal reporting requirements.

Timing Contradictions:

Example: A PSP reports that its risk management framework was approved by the board of directors in February 2025. However, in the significant change section, it reports implementing a new payment technology in January 2025 that materially impacted operational risk.

The Problem: If a significant change materially impacting operational risk occurred in January, the framework should have been updated to address the new risks, which would typically require board approval. How could the framework be approved in February before the January change was incorporated?

What This Signals to Regulators: Either the PSP didn’t actually update its framework to address the significant change, the board approval date is incorrect, or the PSP doesn’t have effective change management processes.

Why Inconsistencies Are Regulatory Red Flags

Credibility Damage: When regulators identify contradictions, they question the accuracy of ALL information in your annual report. Even sections that are accurate may be subjected to verification requests because your credibility is damaged.

Indicator of Systemic Issues: Inconsistencies suggest broader organizational problems:

• Lack of internal communication between departments
• Inadequate data management and reconciliation processes
• Insufficient senior management review before submission
• Unclear understanding of regulatory requirements

Grounds for Enhanced Supervision: PSPs with inconsistent annual reports are often reclassified to higher risk categories, triggering more frequent reporting requirements, on-site examinations, and detailed follow-up inquiries that consume significant management resources.

How to Avoid This Mistake

Designate a Single Annual Report Coordinator: Don’t have multiple departments independently complete their sections. Appoint one compliance officer as the overall coordinator responsible for:

• Assigning section responsibilities to data owners
• Establishing internal deadlines
• Reviewing all sections for consistency
• Identifying and resolving contradictions before submission

Implement Cross-Referencing Quality Checks: Before submission, conduct specific consistency reviews:

Check 1 – Resource Allocation Math:

• Total employees ≥ Employees dedicated to retail payments
• Employees dedicated to retail payments ≥ Employees dedicated to operational risk management
• Budget percentages sum to 100% where applicable

Check 2 – Payment Functions Alignment:

• If you report NOT holding end-user funds in Section 2, you should report $0 for maximum and average end-user funds held in Section 4
• If you report performing certain payment functions, your transaction metrics in Section 4 should reflect those activities

Check 3 – Incident Disclosure Completeness:

• Review operational risk narrative sections for references to incidents, outages, or problems
• Verify all mentioned incidents appear in the incident reporting section
• Check that significant change notifications align with incidents if changes were made in response to incidents

Check 4 – Timeline Consistency:

• Framework approval dates should be before or contemporaneous with significant changes
• Assessment dates for new third parties should be before engagement dates
• Independent review dates should fall within the required 3-year cycles

Conduct Pre-Submission Management Review: Schedule a meeting where the report coordinator presents the complete draft annual report to senior management. Walk through the entire submission, specifically highlighting:

• Any unusual figures or outliers
• Areas where data quality is uncertain or estimated
• Potential inconsistencies that were identified and resolved
• Sections likely to trigger regulatory follow-up questions

This review often identifies inconsistencies that individual section reviewers missed because they lack visibility into other sections.

Maintain Supporting Documentation: For every figure and statement in your annual report, maintain source documentation that supports the response. This allows you to:

• Verify accuracy during quality control reviews
• Identify data sources that conflict with each other before submission
• Respond quickly to regulatory follow-up inquiries
• Demonstrate good faith if errors are later discovered

Use the Prior Year Report as a Template: Review your previous year’s annual report before starting the current year submission. Check for:

• Metrics that should show logical progression year-over-year
• Responses that should remain consistent if your operations haven’t changed
• Follow-up questions you received from regulators about prior submissions

This historical comparison helps identify inconsistencies between reporting periods and validates that changes you’re reporting actually occurred.

Mistake #4: Claiming Framework Approval Without Adequate Evidence

Both your operational risk management framework and your safeguarding-of-funds framework must be approved by designated senior officers and, where applicable, your board of directors. PSPs that claim these approvals occurred but cannot produce evidence face serious credibility and enforcement risks.

What Constitutes Adequate Approval

The RPAA and RPAR specify clear governance requirements:

Operational Risk Management Framework (Section 5 of RPAR):

• Approved by the senior officer designated under subparagraph 5(1)(d)(ii)
• Approved by the board of directors, if the PSP has one
• Re-approved by the senior officer when material changes are made to the framework

Safeguarding-of-Funds Framework (Section 15 of RPAR):

• Approved by a senior officer responsible for overseeing safeguarding practices
• Approved by the board of directors, if the PSP has one
• Re-approved when material changes are made

Your annual report requires confirmation that these approvals occurred during the reporting year.

Why PSPs Claim Approval Without Adequate Evidence

Misunderstanding Approval Requirements: Some PSPs believe that having a compliance officer involved in framework development constitutes “approval.” They don’t understand that approval requires formal action by specifically designated individuals (senior officers) and bodies (board of directors).

Example: A compliance manager develops the risk management framework and begins implementing it. The CEO is generally aware the framework exists and doesn’t object. The PSP claims board approval occurred because “the board oversees management and hasn’t raised concerns.”

Reality: This doesn’t meet regulatory requirements. Approval requires explicit board action—typically through board meeting resolutions documented in meeting minutes.

Post-Hoc Documentation: Some PSPs realize during annual report preparation that they lack approval evidence. Rather than disclosing non-compliance, they create “approval memos” backdated to appear as if approval occurred when required.

Example: A PSP’s risk management framework was actually used throughout 2025 without formal board approval. In February 2026, while preparing the annual report, the compliance officer creates a memorandum to the board describing the framework and asking for retroactive approval, then backdates the approval to January 2025.

Reality: This constitutes creating false records and providing misleading information to the Bank of Canada—violations that can result in administrative penalties and potential criminal liability under section 61 of the RPAA.

Confusion About What Requires Approval: PSPs sometimes obtain approval for high-level policies but not for detailed frameworks, or vice versa.

Example: The board approves a one-page “Risk Management Policy” stating that the PSP will manage operational risks appropriately. The compliance team separately creates a 50-page detailed risk management and incident response framework that’s never presented to the board. The PSP claims board approval of the framework based on the policy approval.

Reality: The policy and the framework required by section 5 of the RPAR are different documents. The detailed framework with all required elements must be approved, not just high-level policy statements.

What Happens When Evidence Is Requested

During follow-up inquiries or supervisory examinations, the Bank of Canada routinely requests documentation supporting claimed framework approvals:

What Regulators Want to See:

Board Approval:

• Meeting minutes showing the framework was discussed and approved
• Resolutions formally adopting the framework
• Evidence board members received the framework in advance and had opportunity to review
• Documentation of any board questions or concerns and how they were addressed

Senior Officer Approval:

• Memoranda signed by the senior officer approving the framework
• Email correspondence showing the senior officer reviewed and authorized the framework
• Approval workflow documentation from document management systems
• Evidence the senior officer has appropriate authority under corporate governance documents

Material Change Re-Approval:

• Documentation identifying what material changes occurred
• Evidence the framework was updated to reflect the changes
• Approval documentation for the updated framework
• Timeline showing approval occurred before or contemporaneously with change implementation

If You Can’t Produce This Evidence:

The Bank of Canada will presume non-compliance with framework approval requirements. This triggers several consequences:

Immediate:

• Directive to obtain proper approval within a specified timeframe (typically 30-60 days)
• Requirement to submit updated annual report disclosing the non-compliance
• Classification as higher-risk requiring enhanced supervisory monitoring

If Non-Compliance Continues:

• Administrative monetary penalties for failure to comply with directives
• Terms and conditions imposed on registration
• Potential suspension of registration until compliance is demonstrated

If False Documentation Is Discovered:

• Significantly elevated penalties for providing false or misleading information
• Potential criminal referral for document falsification
• Immediate loss of regulatory credibility affecting all future interactions

How to Avoid This Mistake

Establish Annual Approval Schedules: Don’t wait until frameworks need updating to address approval. Establish a practice of annual framework review and approval at the beginning of each year:

January:

• Schedule board meeting agenda item for framework review
• Prepare framework presentation materials
• Compile year-over-year changes and updates

February:

• Present frameworks to board for approval
• Document board approval in meeting minutes
• Obtain senior officer approval memoranda

Throughout the Year:

• When material changes occur, document them
• Present material changes for senior officer re-approval
• If multiple material changes accumulate, schedule mid-year board review

This schedule ensures you always have current approval documentation when preparing annual reports.

Create Approval Document Templates: Standardize how approvals are documented:

Board Approval Template:

[Company Name] Board of Directors Meeting
[Date]

RESOLUTION: Approval of [Framework Name]

WHEREAS the Company is required under the Retail Payment Activities Act to maintain a [framework type];

WHEREAS management has presented the [Framework Name] dated [date] for Board approval;

WHEREAS the Board has reviewed the Framework and finds it appropriate for the Company's operations;

BE IT RESOLVED that the [Framework Name] dated [date] is hereby approved;

BE IT FURTHER RESOLVED that the [Senior Officer Title] is authorized to make non-material changes to the Framework as necessary for operational implementation.

Approved: [Vote Results]

Senior Officer Approval Template:

MEMORANDUM

TO: Board of Directors / Compliance Files
FROM: [Senior Officer Name, Title]
DATE: [Date]
RE: Approval of [Framework Name]

I have reviewed the [Framework Name] dated [date] prepared by [team/individual].

I confirm that:
- The Framework addresses all requirements under [specific RPAR section]
- The Framework is appropriate for our retail payment activities
- Resources are available to implement and maintain the Framework
- The Framework is hereby approved

[Signature]
[Date]

These templates create consistent, clear evidence of approval that will satisfy regulatory requests.

Maintain Approval Registers: Create a tracking system documenting:

• Framework name and version number
• Date created or last updated
• Date presented to board
• Date board approved
• Board meeting minutes reference
• Date senior officer approved
• Senior officer approval memorandum reference
• Date of next required review

This register allows you to quickly verify all frameworks have current approvals when preparing annual reports.

Implement Change Management Approval Workflows: When operational changes occur that affect frameworks:

1. Change is proposed
2. Compliance team assesses whether change is “material” to framework
3. If material, framework is updated to reflect the change
4. Updated framework sections go through approval workflow
5. Senior officer re-approval is obtained
6. If multiple changes accumulate, board re-approval is sought
7. Approval is documented in the register

This systematic approach ensures that claims of re-approval for material changes are supported by contemporaneous evidence.

For support in establishing robust governance frameworks and approval processes that meet RPAA requirements, contact ComplyFactor’s compliance framework advisory services.

Mistake #5: Underreporting or Mischaracterizing Incidents to Avoid Scrutiny

The incident reporting section of your annual report requires comprehensive disclosure of ALL incidents that occurred during the year—not just those that met the threshold for immediate notification under section 18 of the RPAA. PSPs that selectively report incidents or mischaracterize operational failures to avoid regulatory attention create significant compliance and credibility risks.

What Constitutes an Incident

The Bank of Canada defines incidents broadly to include any operational disruption, security event, or failure that affects:

• Your ability to perform retail payment activities
• End users’ access to funds or ability to conduct transactions
• Other PSPs relying on your services
• The integrity of transaction data or end-user information

Examples of Reportable Incidents:

• System outages or technology failures
• Cyber security events (attempted or successful)
• Data breaches or unauthorized access to information
• Transaction processing errors affecting end users
• Improper clearing or settlement calculations
• Third-party service provider failures impacting your operations
• Loss of end-user funds
• Provider financial distress affecting account access

Common Mischaracterizations PSPs Use

“Scheduled Maintenance” vs. Unplanned Outage:

Scenario: A system upgrade is scheduled for a 2-hour maintenance window from 2:00 AM to 4:00 AM Sunday. During the upgrade, an error occurs extending the outage until 11:00 AM, affecting business hours and preventing customer transactions for 7 hours beyond the planned window.

How PSPs Mischaracterize: “This was scheduled maintenance that we notified customers about in advance. Since it was planned, it’s not an incident.”

Regulatory Reality: The unplanned 7-hour extension beyond the maintenance window is an incident. Even if the initial maintenance was scheduled, the extended duration that affected business operations and customer service constitutes an operational failure that must be reported.

“Near Miss” vs. Actual Incident:

Scenario: Your monitoring tools detect a cyber attack attempting to access end-user data. Your security controls successfully block the attack, and no data is accessed. Your team investigates and strengthens security measures.

How PSPs Mischaracterize: “We successfully defended against the attack and no data was compromised. This was a near-miss, not an actual incident.”

Regulatory Reality: A cyber attack—even an unsuccessful one—is a reportable incident. The Bank of Canada wants visibility into attack patterns, frequency, and your defensive capabilities. Reporting only “successful” breaches where data is compromised dramatically understates your threat environment.

“Minor Glitch” vs. Transaction Processing Error:

Scenario: A software bug causes 50 transactions to be processed twice, resulting in duplicate charges to end users. You identify the error within 2 hours, reverse the duplicate transactions, and refund any associated fees. Total customer impact: $7,500 in temporary overcharges, all remediated within 24 hours.

How PSPs Mischaracterize: “This was a minor processing glitch that we immediately fixed. Since all customers were made whole and the dollar amount was small, we didn’t consider it a material incident.”

Regulatory Reality: Transaction processing errors affecting end users are reportable incidents regardless of whether they were quickly remediated or involved relatively small amounts. The Bank of Canada uses incident patterns to assess control effectiveness and systemic vulnerabilities.

“Operational Issue” vs. End-User Fund Access Impairment:

Scenario: Your banking partner experiences technical problems preventing you from processing withdrawal requests for 6 hours. End users attempting to access their funds receive error messages. No funds are lost, but access is temporarily unavailable.

How PSPs Mischaracterize: “This was our banking partner’s issue, not our incident. Since no funds were lost and the issue was outside our control, we don’t need to report it.”

Regulatory Reality: Section 5(1)(h) of the RPAR requires your incident response framework to address incidents that occur at or are detected by third-party service providers. Incidents caused by banking partners or other providers that affect your end users or your ability to perform payment functions must be reported in your annual report.

Why This Mistake Triggers Severe Scrutiny

Pattern Suppression: The Bank of Canada uses aggregate incident data to identify systemic vulnerabilities across the payments ecosystem. PSPs that underreport incidents prevent regulators from detecting patterns that might indicate broader infrastructure or security concerns requiring policy intervention.

Competence Concerns: If your reported incident count seems implausibly low given your transaction volumes and operational complexity, regulators question whether:

• You lack adequate incident detection capabilities
• You don’t understand what constitutes a reportable incident
• You’re deliberately suppressing incident disclosure

All three explanations justify enhanced supervisory scrutiny.

False Compliance Appearance: PSPs reporting zero or very few incidents create an impression of strong operational risk management. If this impression is false—based on selective reporting—you’ve misled regulators about your risk profile and receive less appropriate supervision than your actual circumstances warrant.

How Underreporting Gets Discovered

Supervisory Examinations: During on-site reviews, examiners request:

• IT service desk tickets and helpdesk logs
• Change management records showing emergency changes or fixes
• Communications with end users about service disruptions
• Customer complaint records
• Third-party incident notifications
• Security incident logs and SIEM alerts

Examiners then compare these operational records to your annual report incident disclosures. Discrepancies trigger expanded investigation and potential enforcement for false reporting.

Cross-Reference with Other Submissions: If you submitted any immediate incident notifications under section 18 during the year, these must appear in your annual report. If you notified regulators of significant operational changes implemented “in response to the June system failure,” that June system failure must appear as an incident in your annual report.

Regulators cross-reference your various submissions to identify omissions.

Industry Intelligence: Banking partners, payment networks, and other PSPs may inform regulators about incidents that affected shared systems or services. If multiple PSPs report an infrastructure provider outage but you don’t, regulators want to understand why you didn’t experience or report the incident.

Follow-Up Questions: The Bank of Canada may ask “confirm you experienced zero system outages during 2025” or “explain why you report zero cyber security incidents despite high transaction volumes.” PSPs sometimes disclose previously unreported incidents when directly questioned, confirming inadequate initial reporting.

How to Avoid This Mistake

Establish a Comprehensive Incident Definition: Create clear, written guidance for your organization defining what constitutes a reportable incident:

Reportable Incidents Include:

• Any system downtime during business hours exceeding 15 minutes
• Any downtime outside business hours exceeding 2 hours
• Any cyber security event (blocked or successful attacks, suspicious activity)
• Any unauthorized access to systems or data (attempted or successful)
• Any transaction processing error affecting one or more end users
• Any data integrity issue affecting transaction records
• Any third-party outage or failure impacting your services
• Any end-user fund access impairment for any duration
• Any operational issue requiring emergency changes or extraordinary procedures

Not Reportable (Examples):

• Routine maintenance completed within scheduled windows
• Individual user access issues resolved through password resets
• Planned system upgrades completed without issues

Train operational staff on these definitions so incidents are flagged appropriately.

Implement Incident Logging Requirements: Require all operational teams to log potential incidents in a centralized incident management system:

Minimum Information Captured:

• Date and time incident detected
• Nature of incident (system, security, processing, third-party)
• Impact assessment (end users affected, services impaired, duration)
• Root cause determination
• Resolution actions taken
• Date and time resolved

At year-end, review the complete incident log to populate the annual report incident section. This comprehensive approach prevents incidents from being overlooked or selectively excluded.

Don’t Self-Screen Incidents: When in doubt about whether something should be reported, include it in your annual report. The Bank of Canada would rather receive comprehensive disclosure that includes marginal incidents than selective reporting that omits genuinely significant events.

Err on the side of over-reporting. You can characterize incidents as minor or quickly-remediated in your descriptions, but you should report their occurrence.

Conduct Pre-Submission Incident Audit: Before finalizing your annual report, have someone independent from operations review:

• Incident management system logs
• IT service desk tickets
• Security incident and event management (SIEM) system alerts
• Change management emergency changes
• Root cause analysis reports
• Communications with banking partners or service providers about operational issues

This independent review often identifies incidents that operational teams didn’t log or didn’t consider significant enough to report.

Include Contextual Information: When reporting incidents, provide context that demonstrates your operational maturity:

“The PSP experienced 8 system outages during 2025, a 40% reduction from 2024. All outages were resolved within target recovery time objectives. Root cause analyses were conducted for each incident, and preventive measures were implemented including [specific actions].”

This context shows you’re actively managing operational risks and improving over time, even while honestly disclosing incident patterns.

For support in developing comprehensive incident response and reporting frameworks that meet regulatory expectations, see ComplyFactor’s operational risk management services and incident response planning.

Beyond the Big Five: Other Mistakes That Attract Regulatory Attention

While the five mistakes above are the most consequential, several other common errors can trigger Bank of Canada scrutiny:

Using Outdated or Placeholder Data

The Issue: PSPs provide rough estimates or outdated metrics because they lack robust data collection systems.

Example: A PSP reports the same resource allocation percentages from 2024 in its 2025 annual report because “our organization hasn’t changed much.” The figures are generic estimates rather than actual 2025 data.

Why It Matters: The Bank of Canada can identify suspiciously static data that doesn’t reflect normal business evolution. This suggests inadequate internal controls and data management.

How to Avoid: Invest in data collection systems that enable accurate metric calculation. If you must estimate, document your methodology and show continuous improvement in data quality year-over-year.

Ignoring Changes in Payment Functions Performed

The Issue: PSPs begin or cease performing payment functions but don’t properly update their annual report disclosures.

Example: A PSP that previously only initiated payments begins holding end-user funds briefly during batch processing. The PSP doesn’t report starting to perform payment function (b) because the holding period is “temporary.”

Why It Matters: Payment function changes trigger different compliance obligations. Undisclosed changes prevent proper regulatory oversight.

How to Avoid: Quarterly review whether operational changes have resulted in performing additional payment functions. When in doubt, consult the Bank of Canada’s holding funds case scenarios or seek regulatory clarification.

Inadequate Financial Metric Attribution

The Issue: PSPs can’t accurately separate revenue attributable to retail payment activities from other business lines.

Example: A PSP provides various financial services including payments, lending, and investment management. It reports 100% of revenue as “retail payment revenue” because “payments are integrated into all services.”

Why It Matters: Inaccurate revenue attribution prevents regulators from assessing the scale of retail payment operations versus other activities.

How to Avoid: Develop revenue allocation methodologies that reasonably attribute income to retail payment activities versus other services. Document your methodology and refine it over time.

Late Submission or Missed Deadlines

The Issue: PSPs submit annual reports after the March 31 deadline.

Why It Matters: Late submission itself constitutes non-compliance with reporting obligations under section 21 of the RPAA and can trigger enforcement action regardless of the quality of the submission.

How to Avoid: Start annual report preparation at least 90 days before the deadline. Establish internal submission targets 2-3 weeks before March 31 to allow for quality review and contingencies.

Post-Submission: What to Expect After Filing Your Annual Report

Understanding the Bank of Canada’s review process helps you prepare for potential follow-up and demonstrates your commitment to responsive regulatory engagement.

Initial Completeness Review (2-4 Weeks After Submission)

The Bank conducts an automated and manual review checking for:

• All required fields completed
• Internal consistency across sections
• Mathematical accuracy of metrics
• Obvious errors or implausible data

This initial review typically occurs within 2-4 weeks of submission. If significant errors are detected, you may receive immediate requests for correction or clarification.

Detailed Substantive Review (1-3 Months After Submission)

Supervisors conduct in-depth analysis comparing your submission to:

• Prior year reports from your PSP
• Reports from comparable PSPs (similar size, payment functions, transaction volumes)
• Incident notifications and significant change reports you submitted during the year
• Intelligence from banking partners and payment networks

This review identifies potential compliance gaps, unusual patterns, or discrepancies requiring follow-up investigation.

Potential Follow-Up Inquiries

Based on substantive review, you may receive follow-up requests for:

Clarification Questions: “Your operational risk section indicates 15 third-party service providers, but you report conducting assessments on only 8 providers. Please explain the discrepancy.”

Supporting Documentation: “Please provide copies of board meeting minutes documenting approval of your safeguarding-of-funds framework dated February 15, 2025.”

Detailed Explanations: “Your PSP reported 23 incidents during 2025, an increase from 12 in 2024. Please provide detailed explanations for each incident, root cause analyses, and remediation measures implemented.”

Respond Promptly and Comprehensively: The Bank of Canada typically provides 30 days for responses to follow-up inquiries. Use this time to:

• Thoroughly address each question
• Provide all requested documentation
• Explain any errors or inconsistencies discovered
• Describe corrective actions for identified compliance gaps

Delayed, incomplete, or evasive responses escalate supervisory concerns and may trigger more intrusive oversight measures.

Risk Classification and Supervisory Planning

Your annual report—combined with other supervisory intelligence—directly influences your risk classification:

Low-Risk Classification:

• Minimal follow-up inquiries
• Standard supervisory engagement
• Focus on monitoring rather than active examination

Medium-Risk Classification:

• Periodic supervisory reviews
• Targeted examinations on specific topics
• Enhanced reporting on areas of concern

High-Risk Classification:

• Frequent supervisory reviews
• On-site examinations
• Required remediation plans with specified timelines
• Enhanced monitoring and reporting requirements

Your classification can change year-to-year based on annual report quality, incident patterns, and overall compliance posture.

How ComplyFactor Helps PSPs Avoid Critical Annual Reporting Mistakes

Preparing annual reports that meet Bank of Canada expectations while avoiding the critical mistakes outlined in this article requires specialized regulatory expertise, robust data management, and comprehensive quality control processes.

ComplyFactor provides end-to-end support for PSP annual reporting compliance:

Pre-Submission Annual Report Preparation

Compliance Assessment:

• Review your operations to identify payment functions performed
• Assess operational risk and safeguarding framework adequacy
• Identify potential compliance gaps before they appear in annual reports
• Develop remediation plans for issues requiring disclosure

Data Compilation and Validation:

• Design data collection systems for ubiquity metrics
• Calculate financial metrics and revenue attribution
• Compile incident logs with appropriate categorization
• Cross-check all sections for consistency and accuracy

Quality Control Reviews:

• Conduct “devil’s advocacy” review identifying potential regulator questions
• Verify framework approval documentation is adequate
• Confirm shortfall reporting is comprehensive
• Check third-party assessment documentation meets regulatory standards

Ongoing Framework Development and Maintenance

Annual reporting is easier when you maintain compliant frameworks throughout the year:

Operational Risk Management:

• Risk assessment methodologies and risk registers
• Incident response plans and testing procedures
• Third-party management programs including assessment templates
• Independent review coordination

End-User Funds Safeguarding:

• Trust arrangement structuring and legal opinion coordination
• Insurance and guarantee policy procurement and monitoring
• Shortfall detection and remediation procedures
• Ledger design and reconciliation controls

Governance and Documentation:

• Senior officer designation and responsibility allocation
• Board reporting and framework approval processes
• Policy documentation and procedure manuals
• Training programs for compliance personnel

Our AML compliance program services provide comprehensive framework development that positions you for efficient annual reporting.

Fractional MLRO Services

For PSPs needing dedicated compliance leadership without full-time headcount, our MLRO services provide:

• Designated senior officer for operational risk and safeguarding oversight
• Framework approval and ongoing maintenance
• Annual report coordination and submission
• Regulatory inquiry management and Bank of Canada liaison
• Continuous monitoring for RPAA compliance

Our fractional MLRO model gives small and mid-sized PSPs access to senior compliance expertise at sustainable cost levels.

Independent Reviews and Audits

The RPAA requires independent reviews of operational risk frameworks (section 10 of RPAR) and safeguarding compliance (section 17 of RPAR). Our audit services include:

• Regulatory-compliant independent reviews
• Third-party assessment reports
• Gap analyses and remediation roadmaps
• Pre-submission annual report audits

Our auditors understand Bank of Canada supervisory expectations and design reviews that satisfy regulatory requirements while providing actionable improvement recommendations.

Why PSPs Trust ComplyFactor for Annual Reporting Support

Specialized RPAA Expertise: We focus exclusively on payments and financial crime compliance. Our team understands the nuanced requirements of Canadian PSP regulation and Bank of Canada supervisory practices.

Former Regulator Perspectives: Our team includes former regulators and compliance officers who understand how annual reports are reviewed and what triggers enhanced scrutiny.

Practical, Scalable Approaches: We design compliance solutions proportionate to your operations. Small PSPs need compliant frameworks without enterprise overhead—we deliver appropriately scaled solutions.

Proven Track Record: We’ve supported dozens of PSPs through annual reporting cycles, helping them avoid the critical mistakes that trigger regulatory problems.

End-to-End Support: From initial registration through ongoing compliance and annual reporting, ComplyFactor provides comprehensive support across all RPAA obligations.

To discuss your PSP annual reporting requirements and explore how ComplyFactor can help you avoid critical mistakes, contact our team for a confidential consultation.

Your 2026 Annual Report Action Plan: Start Today

The March 31st deadline approaches faster than most PSPs anticipate. Don’t wait until February to begin preparation. Use this action plan to start today:

This Week: Assessment and Planning

• Designate an annual report coordinator
• Retrieve your 2025 annual report (if filed) and regulator follow-up questions
• Identify known compliance gaps or issues that must be disclosed
• Schedule internal kickoff meeting with all data owners
• Review this article’s five critical mistakes and assess your vulnerability to each

Next 30 Days: Data Gathering

• Compile operational risk framework approval documentation
• Retrieve incident logs for all of 2025
• Gather third-party service provider assessment reports
• Collect safeguarding arrangement documentation (trust agreements, insurance policies)
• Identify all shortfall instances during 2025
• Calculate preliminary ubiquity metrics (funds held, transaction volumes)

60 Days Before Deadline: Quality Control

• Complete draft annual report in PSP Connect
• Conduct cross-section consistency review
• Verify framework approval evidence is adequate
• Confirm all shortfalls are reported with detailed explanations
• Check incident reporting for completeness
• Review third-party assessment documentation against regulatory requirements

30 Days Before Deadline: Review and Submission

• Present draft annual report to senior management
• Conduct legal/compliance review of safeguarding and trust arrangements
• Perform final proofreading and error checking
• Compile supporting documentation for anticipated follow-up questions
• Submit annual report no later than March 25 (allowing buffer)
• Save confirmation receipt and archive complete submission

Don’t let your PSP become another statistic—a compliance failure that could have been avoided with proper preparation and expert guidance.

Conclusion: Excellence in Annual Reporting Builds Regulatory Credibility

PSP annual reporting under the RPAA isn’t just about meeting a compliance deadline—it’s about demonstrating to the Bank of Canada that you understand your regulatory obligations, manage risks effectively, and operate with transparency and integrity.

The five critical mistakes outlined in this article represent the most common and consequential errors that trigger regulatory scrutiny. By avoiding these pitfalls, you not only reduce enforcement risk but also build regulatory credibility that translates into lighter-touch supervision and stronger business relationships.

Key Takeaways:

1. Report ALL shortfalls in end-user funds safeguarding, regardless of duration or amount
2. Conduct comprehensive third-party risk assessments that address all RPAR requirements before engagement
3. Ensure internal consistency across all annual report sections through systematic quality control
4. Maintain adequate approval evidence for all frameworks with contemporaneous documentation
5. Report ALL incidents without self-screening or mischaracterization to avoid serious issues

Remember: the Bank of Canada would rather see honest disclosure of compliance challenges and remediation efforts than perfection through selective reporting. PSPs that demonstrate transparency, accountability, and continuous improvement build regulatory relationships that support long-term business success.

As Canada’s retail payments regulatory framework matures, supervisory expectations will continue to evolve. PSPs that establish strong compliance foundations today—including rigorous annual reporting practices—will be better positioned to adapt to future regulatory developments.

Whether you’re preparing your first annual report or refining your approach after several filing cycles, remember that compliance is an ongoing journey. Your annual report is a critical milestone demonstrating your commitment to protecting end users, managing operational risks, and contributing to a safe, efficient Canadian retail payments ecosystem.

For expert guidance on avoiding the critical mistakes that trigger Bank of Canada scrutiny and ensuring your annual report demonstrates compliance excellence, contact ComplyFactor today. Our specialized team is ready to support your regulatory success.

---

Related Compliance Resources

PSP Registration and Compliance:

• PSP Registration Requirements in Canada: Complete RPAA Compliance Guide
• Canada PSP and MSB Regulatory Framework
• RPAA Compliance Guide: Canadian PSP Requirements
• Complete Guide to Compliance Documentation for Canadian Payment Service Providers

Operational Risk and Safeguarding:

• AML Compliance Program Development Services
• Key Components of an Effective AML Audit Program
• How to Prepare for Your Annual Independent AML Audit

Expert Support Services:

• Global MLRO Services for Financial Institutions
• Independent AML Audit Services
• AML Advisory Services

---

About ComplyFactor: ComplyFactor is a specialized compliance consultancy providing AML advisory, audit services, fractional MLRO, and regulatory compliance support to payment institutions, electronic money institutions, and financial services firms operating under the RPAA. Our team combines deep regulatory expertise with practical implementation experience to deliver compliance solutions that protect your business while supporting sustainable growth. Learn more about our services or contact us for a confidential consultation about your PSP annual reporting requirements.