RPAA annual report readiness for PSPs: what the Bank’s questions will test
The Bank of Canada’s step-by-step guide to completing the RPAA annual report shows this is not a routine filing. The form is designed to test whether your operational risk, incident response, safeguarding (where applicable), metrics integrity, and record-keeping are implemented and evidenceable. Many PSPs operate reasonably well. The exposure happens when policy claims, vendor reality, and operating evidence do not match.
Why are PSPs searching for the RPAA annual report right now?
The Bank’s annual reporting policy states that the annual report is used to support risk-based supervision and that the Bank may seek additional information after submission where necessary.
The Bank’s step-by-step guide makes the supervisory intent visible: the annual report is structured to collect comparable information across PSPs on operational risk governance, safeguarding (where applicable), metrics, and record-keeping.
Who does this apply to (scope of application in plain terms)?
This is for payment service providers (PSPs) that performed retail payment activities in scope of the Retail Payment Activities Act (RPAA) and the Retail Payment Activities Regulations (RPAR).
A practical indicator that you need a tighter perimeter definition is uncertainty about whether vendors, agents, or affiliates “count.” The bank's metrics policy explicitly addresses agent or mandatory activity performed on behalf of the PSP and how reporting scope is treated.
If the scope is unclear, treat that as a mapping task before you touch the form.
What is PSP Connect, and why does it change the filing mindset?
PSP Connect is the channel used to submit the annual report, and it operates within a supervision workflow that can include follow-up information requests.
Further details are set out in the Bank’s Annual Reporting Policy and Supervisory Framework for
AMLI Recommendation: Governance and control frameworks should operate on a continuous basis, ensuring that supporting evidence is accurate, retrievable, and supervisory-ready at all times.
What does the step-by-step guide signal about the annual report?
The guide explains what PSPs must complete in PSP Connect and helps identify the information and documents required to complete the annual report by March 31.
Two points that repeatedly create late-stage friction:
-
Registration information is confirmed first. If registration information lags operational reality, contradictions appear across the report.
-
Operational risk questions assume implementation. Approvals, criticality classification, ownership, resourcing, and measurable reliability targets are treated as program fundamentals, not plans.
AMLI Analysis: the annual report functions like a consistency test across legal, product, operations, IT, finance, and vendor reality.
Legal requirement, supervisory expectation, best practice
Keep these categories separate so your answers remain defensible.
-
Legal requirement: annual reporting obligations under the RPAA and RPAR as filed through the bank's annual report process.
-
Supervisory expectation: how the Bank evaluates readiness through mandatory reporting, follow-up, and risk-based supervision.
-
Best practice: operating discipline that keeps controls and evidence current without rebuilding them for the annual report.
How Annual Reporting Fits Within Ongoing Supervisory Reporting?
The supervision framework describes three reporting channels that require ongoing readiness.
-
Annual report: due no later than March 31 of the year following the reporting year
-
Significant change or new activity report: due at least five business days before the change or new activity
-
Incident notice: due without delay when an incident meets the required material impact threshold
If your governance only activates once per year, it does not meet the expectations of the supervisory regime.
Step 1: lock the perimeter (payment functions and dependencies)
Before writing answers, produce one perimeter statement that every team can agree on:
-
which retail payment activities are in scope
-
which payment functions you perform directly
-
which functions are delivered through vendors
-
which activities are performed by agents or mandataries on your behalf
-
which systems, assets, and processes are critical to delivering those functions
The supervisory framework expects PSPs to manage operational risks tied to assets, business processes, and third-party and agent or mandatory relationships related to retail payment activities.
Step 2: make reliability targets measurable (and provable)
The step-by-step guide asks whether your framework sets objectives and measurable reliability targets and indicators tied to availability, integrity, and confidentiality.
A defensible pattern:
-
Target: 99.9% monthly uptime for a payment initiation API
-
Indicator: uptime monitored independently plus an error-rate threshold
-
Cadence: weekly ops reporting and quarterly governance review with approvals retained
This is the difference between “we aim to be reliable” and “we can prove reliability governance exists.”
Step 3: eliminate evidence drift before you file
Evidence drift is the most common reason reasonable operations fail supervisory reporting.
The Bank’s record-keeping policy expects records sufficient to demonstrate compliance and explicitly includes records related to annual reports, significant change notices, incident requirements, information requests, and special audits, plus supporting materials and underlying data used to compile quantitative measures.
Common drift patterns:
-
incidents exist in tickets, but post-incident reviews and approvals do not
-
vendor outages were handled, but there is no consistent record and closure evidence
-
reliability targets exist in slides, not in controlled governance records
-
the same metric is calculated differently by product, ops, and finance
Common annual report errors PSPs should catch early
Use this as a quick pre-submission test:
-
Ownership gap: “the team owns it” instead of a named control owner and reviewer
-
Criticality gap: assets and processes are listed, but criticality criteria are not documented
-
Metrics gap: counts differ across systems and no data lineage exists
-
Vendor gap: critical vendors are known, but escalation paths and evidence are not centralized
-
Incident gap: incidents are handled, but structured records and post-incident actions are inconsistent
-
Change reporting gap: registration updates are filed, but significant changes or new activities were not assessed
Registration updates, significant changes, and new applications are different paths
The Bank’s policy on reporting changes explains that:
-
registered PSPs must report changes to registration information (timelines vary)
-
PSPs must consider whether a change is also a significant change or new activity requiring separate notice
-
certain changes can require a new application before acquisition of control or prescribed changes
AMLI Recommendation: Implement an internal routing decision process to ensure that all changes are classified appropriately before they are implemented.
Vendors, agents, and mandataries belong inside your reporting story
The Bank’s metrics policy includes retail payment activities performed by agents or mandataries on behalf of the PSP in the reporting scope.
The record-keeping policy expects PSPs to ensure records held by agents, mandataries, and third parties are kept and accessible for the retention period.
Minimum “review-ready vendor record”
-
vendor service and payment-function dependency
-
criticality rating and rationale
-
key risks (availability, confidentiality, integrity)
-
oversight controls and cadence
-
incident and change notification path
-
last assessment date, findings, remediation status
-
named PSP owner
Safeguarding: treat it as a mechanics and evidence question
The annual reporting policy lists safeguarding of end-user funds as an area covered by the annual report form where safeguarding obligations apply.
“We do not hold funds” must be backed by operational workflows and evidence to be defensible, not merely stated. Two practical questions:
-
Do you maintain a ledger of end-user entitlements that must reconcile to pooled balances?
-
In insolvency, could an administrator identify and return entitlements using your records and account structure?
If your team cannot answer clearly, treat this as a workflow and evidence validation task
Example: minimum incident record fields (what “evidenceable” looks like)
A consistent incident template makes annual reporting and follow-up materially easier:
-
incident start, detection, declaration timestamps
-
impacted payment function(s) and systems
-
end-user impact summary and duration
-
severity classification and escalation path
-
containment actions, recovery actions, timeline
-
communications log (internal and external)
-
vendor involvement and coordination record
-
post-incident review summary, actions, owners, due dates
-
closure evidence and approvals
RPAA annual report workflow checklist
Frequently asked questions
Q: When is the RPAA annual report due?
A: Reports must be submitted by March 31 each year and should cover the full calendar year immediately preceding the submission (January 1 to December 31).
Q: What happens after we submit the annual report?
A: The Bank may seek additional information after submission where necessary.
Q: Do agents or mandataries need to be included?
A: Yes. Agent or mandatary activity performed on behalf of the PSP is included in the reporting perimeter.
Q: When do we file a significant change or new activity notice?
A: The Bank may seek additional information after submission where necessary.
Q: What records must support annual reporting?
A: Records sufficient to demonstrate compliance, including supporting materials and underlying data used to compile quantitative measures.
Getting support
If you want a fast, defensible path to RPAA annual report readiness, AML Incubator can help you tighten scope, align your evidence, and submit a report you can stand behind.
Support typically includes perimeter mapping (payment functions, vendors, agents/mandataries), operational risk and incident response framework review, safeguarding mechanics validation where applicable, metrics definition and data lineage checks, and a review-ready evidence index built for quick retrieval if follow-up questions arrive through PSP
-
RPAA explainer (blog)
Book a consultation to review RPAA scope, evidence and control gaps, and what a maintainable compliance operating model should look like for your product, vendors, and jurisdictions.
