Canada's Retail Payment Activities Regulations, section 9, requires a payment service provider to establish and implement a testing methodology for its operational-risk and incident-response framework. The methodology must be proportionate to the effect a reduction, deterioration or breakdown of its retail payment activities could have on end users and other providers. It must account for high-likelihood and high-impact risks, involve relevant stakeholders, set frequency and scope, and test before material changes. Each test also needs a record. This is a program-design and evidence obligation, not merely an instruction to book one annual security test.
Quick answer. RPAA section 9 requires a proportionate testing methodology, not a universal annual penetration test. The Bank of Canada's operational-risk guideline treats penetration testing as one possible additional cyber test, especially for more ubiquitous or interconnected PSPs, and says specialized tests should be conducted by qualified parties. Stingrai can supply human-led web, API, cloud and network penetration testing for the technical slice a PSP selects, with findings and retest evidence that the PSP can place in its section 9 record.
The Retail Payment Activities Act, section 17, requires a PSP performing retail payment activities to establish, implement and maintain the risk management and incident response framework, subject to the regulations. The Bank can assess that framework or any part of it and ask for documents and information. The Bank says the framework requirements came into force on September 8, 2025. A buyer therefore needs a method that can be explained, repeated and evidenced during ordinary operations and material changes.
This guide is for a PSP's risk owner, CISO, engineering lead and procurement team. It turns the operative language into a working testing plan and a test-purchase brief. The PSP owns the methodology and the record. A penetration tester performs a defined technical exercise within that program; it does not decide the PSP's entire operational-risk framework.
First establish whether the activity is in scope
The Bank of Canada's criteria for registering PSPs provide a four-part applicability path: whether the entity performs a payment function as a service, whether it performs retail payment activities involving an electronic funds transfer, whether there is a Canadian geographic connection, and whether an entity or activity exclusion applies. A company outside Canada can still be in scope when it both directs retail payment services at, and performs them for, end users in Canada. Banks and certain other regulated financial institutions appear among entity exclusions. The Bank's June 2026 guidance should be applied to the actual product and legal entity before this article's procurement steps are used.
The testing boundary follows the in-scope retail payment activities, but it should not be confused with only the public checkout page. A PSP may rely on onboarding, identity, risk engines, processor connections, ledger logic, support tooling, cloud infrastructure and third-party services to keep those activities available and accurate. Some are directly reachable through a web or API test; others need control validation, a tabletop or another method. The Bank guideline says the scope should be comprehensive enough to identify deficiencies in the framework and that more important elements should be tested more often and in more depth. That is a risk-based design instruction, not a list of systems every PSP must pentest.
A scope statement should name the payment function, the systems and data that enable it, the owner of each control, important dependencies, and the impact of failure on end users and other PSPs. When a cloud platform, payment network or external service is involved, the PSP should record which part it controls and what test evidence it can obtain from the other party. Section 9(1)(c) expressly requires tests to involve relevant internal stakeholders and take account of reliance on external stakeholders. A technical test that omits a critical integration without noting the dependency is harder to reconcile with that obligation.
Read section 9 as a method, not a calendar slogan
The operative text in RPAR section 9(1) says a PSP must establish and implement a testing methodology. Its purpose is to identify gaps in effectiveness and vulnerabilities in the systems, policies, procedures, processes, controls and other means in the risk management and incident response framework. Five required features determine whether the methodology is complete.
Required feature | What the PSP should write into its own method | Procurement implication |
|---|---|---|
Proportionality, §9(1)(a) | How end-user and other-PSP impact, ubiquity and connectedness change depth and frequency | Explain why critical payment interfaces receive deeper exercises than low-impact supporting tools. |
Risk design, §9(1)(b) | How both high-likelihood and high-impact operational risks shape scenarios | Give testers concrete objectives such as access isolation or transaction integrity, not a vague demand to "test everything." |
Stakeholders, §9(1)(c) | Who from operations, risk, engineering, decision-making, agents or mandataries participates, and how third-party reliance is considered | Put owners and provider coordination into the statement of work and the test record. |
Frequency and scope, §9(1)(d) | Which elements are tested, by which method, at what interval or trigger, and why | Buy the particular engagement the method calls for; record exclusions and other evidence. |
Before material change, §9(1)(e) | A gate for testing before a material change is adopted, with a decision on affected framework elements | Reserve test capacity around product releases, processor migrations and other changes the PSP classifies as material. |
Source for each section and statutory verb: Department of Justice Canada, Retail Payment Activities Regulations §9(1). The examples in the middle and right columns are proposed implementation choices, not extra requirements stated by the regulation.
The Bank's guideline, paragraphs 10.2–10.5, recommends documenting a structured methodology with scope, choice of method, frequency, stakeholder involvement, internal reporting and response to results. It recommends more frequent and deeper testing of more important or higher-inherent-risk elements. A PSP with a large network of counterparties can justify a different test mix from a narrow service with fewer interconnections, but both still need a methodology that covers their actual risk.
The Bank organizes expected testing into three broad categories in paragraph 10.7: verifying and validating controls; scenario-based testing; and testing of changes. That categorization helps the buyer avoid making a penetration test carry a job it cannot do. A web test may demonstrate whether a customer can cross a tenant boundary. It cannot, on its own, prove that the incident-response decision tree works or that a third-party outage handoff is understood by operations staff.
Figure 1: A section 9 method selects risk-based tests across controls, scenarios and material changes. Source: Department of Justice Canada, RPAR §9 and Bank of Canada, operational-risk guideline, paragraph 10.7.
Where a penetration test belongs
The Bank's Appendix G lists several possible techniques: documentation review, interviews, sample testing, desktop review, tabletop exercises, walk-throughs and simulations. It says relatively more ubiquitous or interconnected PSPs could adopt additional testing for cyber and IT risk, including penetration tests and attack simulations. The same appendix says tests may be conducted internally or by a third party and that qualified parties should perform specialized testing. These are supervisory-guideline judgments about suitable methods, not a section 9 annual-pentest mandate.
A penetration test is valuable where the open question is whether a technical control withstands an authorized attempt to bypass it. For a PSP, that may mean whether one merchant account can retrieve another merchant's settlement records; whether an API token can invoke functions beyond its assigned role; whether a support operator can change a beneficiary without the required checks; or whether an exposed cloud identity can reach payment data. Those are synthetic test objectives, not claims about a PSP's actual systems. They translate a risk statement into a safe, bounded exercise that can produce reproducible findings.
A scan is useful for a different part of the methodology. It can inventory and flag known classes of exposure over many hosts or endpoints. It does not by itself establish whether a business-logic permission boundary works across merchant roles, and its raw alerts need verification before they become findings. A tabletop is different again: it probes whether decision-makers and responders can follow their plan under a plausible operational event. The section 9 method should name the question first and then the method that can answer it.
The Bank's paragraph 10.6 allows the results of testing done for another purpose to demonstrate the RPAR testing requirements if they meet section 9's objectives and outcomes. A PCI DSS, SOC 2, customer due-diligence or internal security test can be evidence if its scope and method actually address the PSP's retail-payment risk. A certificate or report cover page cannot fill a gap left by an omitted PSP-specific process or integration. Write a short crosswalk from each reused test to the section 9 risk, scope and record fields, and schedule additional testing where the crosswalk reveals a gap.
A practical method-selection matrix
Question the risk owner needs answered | Fitting method | Evidence to keep |
|---|---|---|
Can a customer, merchant or operator act beyond its assigned payment role? | Authenticated web and API penetration test with role pairs and permitted transactions | Authorized roles, method, validated access results, fixes and retest |
Would the on-call team route a severe payment disruption to the right decision-makers? | Scenario-based tabletop or walk-through | Scenario, participants, decisions, timing, lessons and changes |
Did a new processor connection alter transaction integrity or control ownership? | Change test of integration controls, plus targeted technical testing where applicable | Change description, affected controls, pre-adoption result and approval |
Are a third-party service's controls understood and available when needed? | Provider evidence review, contract or joint exercise where possible | Dependency map, provider evidence, assumptions and unresolved risk |
Did remediation of a validated weakness work? | Focused retest, and broader regression testing if the change warrants it | Original finding, fix version, retest method and result |
The matrix is a buyer-designed implementation aid grounded in section 9 and the Bank's test categories. It is not a regulator-prescribed test menu. It also shows why a multi-method program may need a human-led penetration test for a particularly exposed payment path without turning every operational-risk control into a pentest target.
Make material-change testing a release gate
Section 9(1)(e) requires the methodology to provide for testing before adoption of a material change to framework elements, or to operations that affect them, to evaluate the change's effects. The Bank's paragraph 10.7.3 explains that change testing should cover the framework and operations affected by the change. This does not mean every code deploy is a material change requiring a full network penetration test. It means the PSP needs a defined way to recognize material changes and select enough testing before they are adopted.
Consider a synthetic PSP that replaces its merchant onboarding identity provider and adds a settlement-status API. The risk owner may mark this material because the change alters who can access merchant records and how downstream systems receive payment status. The pre-adoption plan could combine identity configuration review, an authenticated API test across merchant roles, and a walk-through of incident handling for status errors. The test record should tie each exercise to the change. If the same PSP merely updates copy on a marketing page with no effect on the framework, its documented method may route that change through ordinary release checks instead. These are examples of a PSP's risk decision, not formal Bank materiality thresholds.
A release-gate worksheet can ask:
What changes in the payment function, data flow, access path, dependency or control owner?
What is the plausible effect of failure on end users and other PSPs?
Which high-likelihood and high-impact risks change?
Which internal and external stakeholders need to participate or supply evidence?
Which test methods will show the affected controls still work?
What must be completed before adoption, and who can decide on an unresolved risk?
Which record will link the test result to the release decision?
Keep the release decision visible to the senior officer or other accountable manager under the PSP's governance. A vague line in a change ticket that says "security passed" is less useful than a dated result with the method, findings, and action. The statute's record fields make that distinction explicit.
The section 9 record: minimum fields and a useful extension
Section 9(2) requires the PSP to keep a record for each test it carries out. Four fields are mandatory: the date; methodology, including a summary of how the test involved relevant internal stakeholders and accounted for external reliance; results; and measures taken or to be taken in response. Section 9(3) adds that the record must be provided to the specified senior officer if any. The condition matters. Do not turn it into an unconditional named-officer submission rule.
Figure 2: Section 9 requires a per-test date, methodology and stakeholder summary, results, and actions; provision to the identified senior officer is conditional. Source: Department of Justice Canada, RPAR §9(2) and (3).
The minimum record is not the entire procurement file. For a penetration test, a stronger internal record also attaches the approved scope, risk rationale, tester's authorization, excluded systems, results by affected payment function, remediation owner, target date, retest result and links to the related material-change decision. Those are recommended business fields, not extra words in section 9(2). They make the prescribed fields intelligible to a reviewer who was not present during the test.
Required section 9 field | Concise record entry example for a synthetic API test |
|---|---|
Date | The date or dates on which the authorized exercise was performed. |
Methodology and stakeholder treatment | Authenticated role-pair API testing of the settlement-status function; engineering and risk supplied test accounts; the processor dependency was reviewed and excluded from active testing because separate authorization was unavailable. |
Results | One merchant role could read another merchant's status in the test environment; the finding was validated and recorded with controlled proof. |
Actions | Engineering changed the authorization check; the tester retested the affected path; the PSP recorded whether any residual risk remained. |
No row above describes a real customer or a real engagement. The point is the shape of an informative record. It answers what was tested, who was involved, what happened, and what was done with the result. A test report may carry detailed evidence, but the PSP still needs its own record that can satisfy section 9(2), especially when multiple exercises or vendors feed the methodology.
The Bank's record-keeping guidance discusses records for PSP framework operation more broadly. It includes testing results and actions among records to retain. When such a record ceases to demonstrate current compliance, the Bank says the PSP must still retain it for five years from that point; other applicable obligations may require longer. A security owner should align the section 9 record with the PSP's document controls: version, accountable owner, access permissions, sensitive-data handling and that retention schedule. Avoid filling the shared record with live payment data or credentials. Controlled technical proof can be referenced from a restricted evidence store instead.
What to ask a penetration-testing provider
The RFP should make the intended technical exercise legible under section 9, while leaving the broader methodology with the PSP. The following questions turn a high-level request into a comparably priced scope:
Payment function and objective: Which PSP risk will this test evaluate: customer access, merchant isolation, transaction integrity, privileged operations, external exposure or another defined concern?
System boundary: Which application, associated APIs, cloud resources, environments and integrations are authorized? Who owns each target, and is third-party consent documented?
Access level: Which merchant, customer, operator and administrator roles will be supplied? Will test accounts be separated from live customer data?
Method: Will testers use manual authenticated checks for authorization and business logic alongside tooling? How will they validate findings before reporting?
Stakeholder involvement: Which engineering, operations and risk owners must brief testers, receive findings or participate in a change test?
Safety: How will the engagement avoid unintended payment execution, customer impact, excessive traffic and exposure of production data?
Output: Will the final report show dates, method, precise scope, exclusions, findings, evidence, remediation guidance and retest results in a form the PSP can map to section 9(2)?
Timing: Can the provider complete the relevant work before a material change is adopted? What happens if the release or scope moves?
Price basis: Is the quote for one web application and associated APIs, or does it include cloud, network, multiple applications or a continuing program? What adds cost?
The Bank's Appendix G says testing may be internal or third-party and that qualified parties should perform specialized work such as penetration testing. A buyer can therefore assess the actual tester's expertise, not just a vendor logo. Ask for the named testers, relevant credentials, method, report sample with sensitive data removed, and retest terms. If a provider presents a scanner output as a complete pentest report, ask how it would test cross-role payment logic and validate the reported impact.
No section 9 provision sets a fixed penetration-test price. Stingrai's published fixed web packages apply to one web application and associated APIs; wider payment architecture, cloud and network scopes are quoted for the engagement. The methodology may justify a one-time test for a specific change, an annual test selected by the PSP's risk owner, or a continuous program alongside scenario and control-validation work. The rule requires the PSP to state its frequency and rationale; it does not choose one of those commercial models for everyone.
Where Stingrai fits
Stingrai is a Toronto-headquartered CREST-accredited penetration testing services company. For PSPs that select a human-led technical test, two named penetration testers from a team holding OSCE³, OSWE, OSEP, CREST CRT and CISSP certifications can assess authenticated web and API roles, business logic, access control and IDOR, then extend to a separately authorized cloud or network scope where the payment pathway warrants it. The service produces findings that support the PSP's risk methodology and supervisory evidence. It does not replace the PSP's framework owner or the Bank's review.
Every confirmed finding is posted to the PTaaS platform with a working proof of concept and prioritized remediation guidance. Retesting is included, and every human-led and hybrid report includes an attestation letter. Stingrai offers both one-time annual tests and continuous programs. That delivery can help a PSP fill in the results and action portions of its section 9 record during the engagement, rather than reconstructing them from memory after a release.
For one web application and associated APIs, Snipe, Stingrai's autonomous agent for web applications and their APIs, can be part of a hybrid engagement. Snipe and the penetration testers test together throughout. An internal network, cloud tenant, mobile app or operational process requires its own appropriately scoped service or another method; Snipe is not a substitute for those tests. Buyers can review Stingrai's web application penetration testing, cloud testing and network testing before writing a combined brief.
Frequently Asked Questions
Does the RPAA require every payment service provider to run an annual penetration test?
No. Section 9 requires each covered PSP to establish and implement a proportionate testing methodology that states scope and frequency; it does not specify a universal annual pentest. The Bank's guideline says more ubiquitous or interconnected PSPs could add penetration tests for cyber and IT risk, with qualified parties conducting specialized tests. Sources: RPAR §9; Bank of Canada, Appendix G.
What must an RPAA testing methodology cover?
Section 9(1) requires proportionality to possible effects on end users and other PSPs, consideration of high-likelihood and high-impact operational risks, relevant internal stakeholders and external reliance, a stated frequency and scope, and testing before adoption of material changes. The methodology identifies weaknesses in the risk management and incident response framework's systems, policies, processes and controls. Source: RPAR §9(1).
What record does a PSP need for each test?
Section 9(2) requires the date, the methodology with a summary of stakeholder involvement and external reliance, the results, and measures taken or planned in response. Section 9(3) requires provision of that record to the specified senior officer if one exists. A tester's report can supply much of the technical detail, but the PSP should map it into its own per-test record. Source: RPAR §9(2) and (3).
Must a PSP test before a payment-platform change?
The methodology must provide for testing before adoption of a material change to covered framework elements or operations that affect them. The PSP should classify the change, identify affected controls, select appropriate test methods and retain the result. The rule does not say every small code release requires a full penetration test. Source: RPAR §9(1)(e).
Can a PCI DSS or customer-requested penetration test count toward RPAA testing?
It can contribute if it meets section 9's objectives and outcomes for the PSP's retail payment activities. The Bank's guideline allows results from testing conducted for other purposes to be used where they meet the RPAR requirements; missing scope needs additional testing. The PSP should record the crosswalk rather than relying on the report title alone. Source: Bank of Canada, paragraph 10.6.
May a third party conduct RPAA testing?
Yes. The Bank's Appendix G says tests may be conducted internally or by a third party and notes that qualified parties should conduct specialized testing such as penetration testing. The PSP remains responsible for its methodology, stakeholder treatment, results and record. Sources: Bank of Canada, Appendix G; RPAR §9.
Do third-party payment processors need to participate in a PSP's test?
Section 9(1)(c) requires the methodology's tests to take account of the PSP's reliance on external stakeholders, including third-party service providers. That does not itself authorize an intrusive test of the provider's infrastructure. The PSP can review the provider's evidence, conduct an agreed joint exercise, or document a dependency assumption according to the risk and contract. Source: RPAR §9(1)(c).
How should a PSP choose pentest scope and frequency?
Choose from the PSP's payment functions, end-user and other-PSP impact, high-likelihood and high-impact risks, and connectedness. Document why the chosen systems, methods and interval answer those risks, and add a pre-material-change trigger. The Bank recommends deeper and more frequent testing of more important framework elements; it does not set a fixed penetration-test cadence. Sources: RPAR §9(1); Bank of Canada, paragraphs 10.2–10.5.
Related reading
References
Department of Justice Canada, Retail Payment Activities Act §17.
Department of Justice Canada, Retail Payment Activities Regulations §9.
Bank of Canada, Operational risk and incident response supervisory guideline, October 2024.
Bank of Canada, Criteria for registering payment service providers, updated June 2026.
Talk to Stingrai
For a web, API, cloud or network test whose findings can feed your section 9 record, Get a Quote or book a free discovery call.
