Activity-based regulation changes risk management because compliance expectations follow what the business does, not just what it is licensed as. That shifts attention toward transaction flows, customer journeys, and control evidence. PSPs need stronger risk-based processes so operational teams can detect gaps earlier, respond consistently, and prove that controls are working across different products and channels.
What changes when regulation follows the activity instead of the licence?
Activity-based regulation changes the control question from “what licence do we hold?” to “what are we actually doing, and what risks does that activity create?” For PSPs, that means risk management has to track products, payment flows, channels, and customer interactions at a more granular level. A firm can no longer rely on a single authorisation label to stand in for control maturity.
This usually makes governance more operational. Teams need evidence that controls are working where the regulated activity occurs, not just that a policy exists somewhere in the organisation. It also reduces the value of static, one-size-fits-all control sets because the same PSP may face different expectations across onboarding, payments execution, fraud monitoring, outsourcing, and incident handling.
Why transaction flows and customer journeys become the real risk boundary
When the regulator looks at the activity, the practical risk boundary becomes the journey the payment takes through the business. That boundary includes who initiates the transaction, which systems touch it, what data is collected, where exceptions are handled, and which parties can alter or delay the flow. For PSPs, risk management therefore has to follow process design, not just organisational charts.
This matters because many failures are cross-functional. A weak control in onboarding can create downstream fraud exposure, while a poor exception process can undermine reconciliation, dispute handling, or suspicious activity review. The control owner may sit in operations, compliance, technology, or risk, but the evidence must show the end-to-end activity is governed consistently.
How PSP control evidence changes under an activity-based model
PSPs need evidence that is specific, repeatable, and tied to the regulated activity. That includes monitoring outputs, review logs, exception handling records, incident responses, and control tests that show the process works in normal and adverse conditions. In practice, this pushes firms toward stronger risk-based processes because the regulator can ask not only whether a control exists, but whether it is effective across products and channels.
That shift also exposes weak documentation habits. If a PSP cannot show how a control maps to a product flow, a customer segment, or a third-party dependency, it will struggle to demonstrate that its control set matches the activity it performs. The result is often more frequent review cycles, clearer ownership, and better traceability from business activity to control outcome.
Risk and Threat Considerations
Activity-based regulation increases exposure where PSPs have inconsistent controls across similar payment journeys, because gaps can hide inside product-specific exceptions, outsourced steps, or channel-specific processes. The main risk is not simply non-compliance on paper, but control drift, where the organisation believes one standard applies while the actual activity creates a different exposure profile.
Failure mechanism: The firm defines controls around entity type or licence status, then misses activity-level variation in transaction handling, customer onboarding, fraud review, or incident escalation. That creates blind spots in evidence, monitoring, and accountability.
Impact: PSPs can face supervisory findings, remediation cost, delayed launches, inconsistent customer outcomes, and higher fraud or operational loss where the activity is not genuinely controlled.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Activity-based regulation depends on the regulated activity, not the licence label. |
| GV.RM-01 — Risk Management Strategy | PSPs need a risk-based operating model that follows business activity across products and channels. | |
| GV.OV-01 — Cybersecurity Oversight | Supervisors expect oversight evidence that controls work where the activity occurs. | |
| Recommendation — Map payment activities and operating context to the controls that govern them. Align control design and testing to the risk profile of each regulated activity. Maintain oversight evidence that shows control effectiveness at the activity level. | ||
| ISO/IEC 27001:2022 | A.5.36 — Compliance with policies, rules and standards for information security | PSPs must show that operating controls align with applicable regulatory obligations. |
| Recommendation — Document and evidence how each activity meets the applicable control requirements. | ||
Practitioner Guidance
What to prioritise: Start by mapping regulated activities to concrete payment flows and control points. If the same activity is delivered through multiple products or channels, test each path separately rather than assuming one control design covers all variants.
What to verify: Verify that each important control leaves an auditable trail at the activity level, not just at the policy or enterprise level. The most useful evidence is usually operational: sampling results, exception logs, monitoring outputs, and documented response actions.
Common mistake: Treating compliance as a legal classification exercise rather than a live operating model. PSPs that focus only on licence scope often discover too late that the regulator is judging the quality and consistency of the actual service delivered.
Practitioner takeaway: The strongest posture is the one where the business can show, for each meaningful payment activity, who owns the risk, what the control does, and how effectiveness is proven in practice.
Related resources from NHI Mgmt Group
- Why does a risk-based approach matter more than blanket compliance when protecting critical infrastructure and cloud native environments?
- What happens when organisations grant privileged access in the cloud without risk-based approval workflows?
- Why do non-human identities create more audit risk than human accounts?
- Why do non-human identities create audit risk in modern environments?
