Accountability sits with the system operator and the relevant oversight bodies, but responsibility is shared across governance, operations, and participating institutions. The article stresses effective, accountable, and transparent governance arrangements, plus clear roles for managing credit risk, liquidity risk, security, and testing. In practice, resilience fails when ownership is diffuse and no team can enforce the required controls end to end.
Who Holds the Resilience Mandate in a Systemically Important Payment System?
The accountability model is best understood as a layered one. The system operator owns the resilience posture of the platform it runs, while oversight bodies set expectations, challenge governance, and intervene when standards are not met. Participants are still responsible for the controls they control, so resilience depends on a clear allocation of duties rather than a vague shared commitment.
That distinction matters because payment-system resilience is not just about uptime. It also covers governance, testing, incident handling, and the ability to keep critical functions operating under stress. When accountability is unclear, organisations often discover too late that no one has authority to force remediation across the full chain.
Why System Operators Carry the Primary Accountability
The operator is the only party positioned to own the full resilience design of the system: governance, technology, operational procedures, recovery arrangements, and participant coordination. That makes the operator accountable for ensuring controls are effective end to end, even when delivery depends on external institutions or service providers.
In practice, accountability must include the ability to enforce standards, not just publish them. If the operator cannot require testing, measure recovery readiness, or escalate unresolved weaknesses, the resilience model becomes advisory instead of operational. For critical payment infrastructure, that is usually a failure of governance, not just a technical gap.
Clear operator accountability also reduces ambiguity during incidents. When outages, liquidity stress, or security events occur, the system needs a decision-maker that can prioritise continuity, participant coordination, and safe restoration of service. Without that, response becomes fragmented and recovery slows.
How Oversight Bodies and Participants Share Responsibility
Oversight bodies are accountable for supervision, standards, and intervention, but they do not replace the operator’s duty to run the system safely. Their role is to ensure the governance model is credible, to challenge weak assurance, and to make sure resilience expectations are enforced consistently across the ecosystem.
Participants, meanwhile, remain responsible for their own operational readiness and for meeting the obligations attached to access, settlement, liquidity management, and incident coordination. A resilient payment system fails when one participant assumes the operator will absorb all downstream risk, or when the operator assumes participants have already hardened their own processes.
The most effective governance arrangements make these boundaries explicit. Effective accountability usually means named owners, documented escalation paths, tested recovery responsibilities, and evidence that each party can perform its role under adverse conditions. EU Digital Operational Resilience Act (DORA) is a useful comparator for this governance-and-testing mindset in regulated environments.
What Breaks When Accountability Is Diffuse
Diffuse accountability creates blind spots in exactly the places resilience depends on most: control ownership, testing authority, and incident escalation. The operator may assume participants are responsible for a dependency, while participants assume the operator has already validated it. That gap is where latent weaknesses persist until a disruption exposes them.
It also makes enforcement inconsistent. If no party can compel remediation, testing can become a box-ticking exercise, risk acceptance can linger without review, and recovery objectives can be defined but never proven. For systemically important payment systems, that is dangerous because the cost of failure is not local, it is systemic.
Resilience governance is strongest when the accountability chain is short enough to act and clear enough to audit. NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, protection, response, and recovery as linked duties rather than isolated tasks.
Risk and Threat Considerations
In systemically important payment systems, weak accountability amplifies both operational failure and adversarial opportunity. If roles are unclear, attackers and disruptive events benefit from slower decisions, delayed escalation, and fractured recovery ownership.
Failure mechanism: responsibility is split across governance, operations, and participants, but no single owner can enforce testing, remediation, or recovery readiness end to end, leaving critical dependencies unverified.
Impact: unresolved control gaps persist until stress or compromise exposes them, increasing the chance of service disruption, delayed recovery, and broader financial-system instability.
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 | Payment-system accountability depends on clearly defined operator and oversight roles. |
| GV.RM-01 — Risk Management Strategy | Systemically important payment systems need explicit resilience ownership and escalation. | |
| RC.RP-01 — Recovery Plan Execution | The question concerns who can drive recovery readiness and execution after disruption. | |
| Recommendation — Define who owns resilience decisions across governance, operations, and participants. Assign accountable owners for continuity, recovery, and unresolved risk acceptance. Test and assign recovery execution authority before an outage occurs. | ||
| ISO/IEC 27001:2022 | A.5.2 — Information security roles and responsibilities | The answer hinges on clear accountability across governance and operations. |
| A.5.29 — Information security during disruption | Payment resilience requires continuity arrangements under stress and disruption. | |
| Recommendation — Document role ownership for resilience controls and escalation paths. Maintain continuity controls that remain effective during disruptive events. | ||
Practitioner Guidance
What to verify: The accountability map should show who can approve, who can enforce, and who can escalate for every resilience control, especially testing, incident coordination, and recovery decisions. If the document only assigns responsibility without decision authority, it is not operationally complete.
Decision rule: If a control affects systemic continuity, treat the system operator as the accountable owner even when execution is shared. If a dependency cannot be owned, tested, and evidenced by name, it is too ambiguous to trust during an incident.
Practitioner takeaway: Resilience in payment systems depends less on who contributes effort than on who can compel action when the system is under stress.
