Identifying Severe but Plausible Scenarios is a fundamental component of Operational Resilience because it enables Brunei Darussalam Central Bank (BDCB) to evaluate whether CBS-1 Payment & Settlement Systems can continue to operate within its approved Impact Tolerance when exposed to credible but highly disruptive events.
Unlike traditional business continuity testing, which often validates recovery procedures for individual systems, Operational Resilience scenario testing focuses on the continued delivery of the Critical Business Service and the prevention of unacceptable harm to financial institutions, market participants, government agencies, and the wider financial system.
The previously identified Sub-Critical Business Services (Sub-CBS) provide the appropriate level of analysis for designing realistic scenarios.
Each Sub-CBS performs a unique role within the end-to-end payment and settlement lifecycle and possesses distinct operational dependencies, cyber exposures, ICT risks, and third-party relationships.
Testing each Sub-CBS individually, while simultaneously considering cascading effects across interconnected processes, provides management with a comprehensive understanding of service resilience.
Cyber and ICT Risks are integrated throughout the scenarios rather than treated as independent technology risks. Cyberattacks, ICT failures, telecommunications outages, data corruption, privileged access compromise, failed technology changes, infrastructure failures, third-party disruption, and operational control failures frequently interact and amplify one another.
The scenarios therefore examine how operational, technology, cyber, people, facilities, and external dependencies combine to threaten delivery of the Critical Business Service.
The scenarios presented below are illustrative implementation recommendations intended to support Operational Resilience planning and scenario testing.
They are not intended to represent known weaknesses within BDCB. The scenarios should be reviewed and refined using BDCB's operational environment, payment infrastructure, transaction profile, and approved Impact Tolerance.
Table 1 (P1): Severe but Plausible Scenarios
|
Sub-CBS Code |
Name of Sub-CBS |
Recommended Severe but Plausible Scenario |
Scenario Description |
Primary Disruption Trigger |
Impact on Sub-CBS |
Impact on Critical Business Service |
|
CBS-1.1 |
Payment Participant Management |
Identity management compromise |
A privileged administrator account is compromised, resulting in unauthorised modification of participant access rights and settlement permissions immediately before the settlement day. |
Privileged access compromise |
Participant onboarding and access validation become unreliable. |
Legitimate participants may be unable to transact while unauthorised access threatens payment integrity. |
|
CBS-1.2 |
Payment Instruction Submission |
Nationwide telecommunications disruption with DDoS attack |
A telecommunications outage coincides with a DDoS attack against payment gateways, preventing multiple institutions from submitting payment instructions. |
Telecommunications failure and cyberattack |
Transaction submission channels become unavailable. |
Payment instructions cannot enter the settlement process, causing widespread transaction backlog. |
|
CBS-1.3 |
Transaction Validation and Authentication |
Corruption of digital certificate infrastructure |
Authentication services reject valid payment messages after corruption of certificate validation services during a failed security update. |
Failed technology change |
Validation controls become unavailable. |
Payment processing is suspended because transaction authenticity cannot be assured. |
|
CBS-1.4 |
Liquidity and Funds Availability Management |
Corrupted settlement account balances |
Database corruption results in inaccurate liquidity positions across multiple settlement participants. |
Database corruption |
Liquidity calculations become unreliable. |
Settlement gridlock develops as participants cannot verify available balances. |
|
CBS-1.5 |
Payment Processing and Routing |
Failed software deployment during peak settlement |
A software release introduces routing errors, causing payments to be misdirected and duplicated. |
Failed software deployment |
Payment routing fails. |
RTGS and deferred settlement processing are disrupted simultaneously. |
|
CBS-1.6 |
RTGS Processing |
Simultaneous RTGS application and storage failure |
A storage subsystem failure during peak RTGS processing corrupts active settlement records. |
ICT infrastructure failure |
High-value settlements stop immediately. |
Systemically important payments remain unsettled, threatening financial stability. |
|
CBS-1.7 |
Deferred Net Settlement Processing |
Clearing calculation failure |
Incorrect batch processing produces inaccurate multilateral net positions for participants. |
Batch processing error |
Settlement cycle cannot complete. |
Retail payment settlement is delayed, creating liquidity pressure. |
|
CBS-1.8 |
Settlement Finalisation and Confirmation |
Ledger integrity failure |
Settlement completes but confirmation records become inconsistent due to storage replication failure. |
Data replication failure |
Settlement confirmation cannot be trusted. |
Participants cannot determine final payment status, creating operational uncertainty. |
|
CBS-1.9 |
Exception and Failed Transaction Management |
Large-scale payment failure backlog |
Thousands of payment exceptions accumulate after prolonged processing disruption while the case management platform becomes unavailable. |
Operational and ICT failure |
Exception resolution becomes severely delayed. |
Payment recovery slows, extending customer and participant disruption. |
|
CBS-1.10 |
Settlement Risk Monitoring and Control |
Monitoring platform outage |
Security monitoring, operational dashboards and liquidity monitoring become unavailable due to ransomware affecting monitoring infrastructure. |
Ransomware |
Operational visibility is lost. |
Emerging payment risks remain undetected, increasing systemic exposure. |
|
CBS-1.11 |
Payment System Oversight and Compliance Monitoring |
Regulatory reporting platform compromise |
Cyber compromise corrupts supervisory reporting and compliance dashboards. |
Cyberattack |
Compliance oversight becomes unreliable. |
Regulatory reporting may become inaccurate or delayed. |
|
CBS-1.12 |
Operational Incident and Service Disruption Management |
Failure of crisis coordination |
Incident management systems fail while multiple technology teams experience communication outages. |
ICT collaboration failure |
Incident response becomes fragmented. |
Service restoration is delayed beyond planned recovery targets. |
|
CBS-1.13 |
Business Continuity and Service Recovery |
Recovery site unavailable following ransomware |
Ransomware spreads into recovery infrastructure, preventing activation of disaster recovery capability. |
Cyberattack |
Recovery cannot commence as planned. |
Payment service remains unavailable beyond the planned recovery period. |
|
CBS-1.14 |
Settlement Reporting and Regulatory Information Management |
Data warehouse corruption |
Reporting databases become corrupted after storage failure and incomplete backups. |
Storage failure |
Regulatory and management reporting becomes unreliable. |
Management loses operational visibility while regulatory reporting obligations may be affected. |
|
CBS-1.15 |
Post-Settlement Review and Continuous Improvement and Decision Support |
Loss of operational analytics |
Historical incident records become unavailable after corruption of governance repositories. |
Data corruption |
Root-cause analysis cannot be completed effectively. |
Similar operational weaknesses remain unidentified, increasing future resilience risk. |
Table 2 (P2): Severe but Plausible Scenarios
|
Sub-CBS Code |
Name of Sub-CBS |
Interconnections and Interdependencies Challenged |
Cyber and ICT Risk Linkage |
Potential Impact Tolerance Breach |
Proactive Risk Management Action |
Evidence of Proactive Risk Management |
Scenario Testing Objective |
|
CBS-1.1 |
Payment Participant Management |
Identity services, participant records, compliance |
Privileged access compromise |
High |
Privileged access management, MFA, periodic access reviews |
Access review reports, penetration testing, IAM audits |
Validate participant administration resilience. |
|
CBS-1.2 |
Payment Instruction Submission |
Banks, communication networks, payment gateways |
DDoS, network outage |
Very High |
Alternate communication channels, DDoS protection, capacity testing |
Network resilience tests, DDoS simulations |
Verify transaction submission continuity. |
|
CBS-1.3 |
Transaction Validation and Authentication |
Authentication infrastructure, PKI, validation engines |
Certificate compromise, failed technology change |
Very High |
Dual validation, PKI monitoring, secure change management |
PKI audit, change testing, vulnerability assessment |
Confirm integrity of transaction authentication. |
|
CBS-1.4 |
Liquidity and Funds Availability Management |
Settlement accounts, treasury information |
Database corruption |
Very High |
Data reconciliation, integrity monitoring, replicated databases |
Reconciliation reports, database failover testing |
Demonstrate reliable liquidity validation. |
|
CBS-1.5 |
Payment Processing and Routing |
Payment engines, RTGS, DNS |
Failed software deployment |
Very High |
Controlled release management, rollback procedures |
Release approvals, rollback exercises |
Validate routing resilience during technology changes. |
|
CBS-1.6 |
RTGS Processing |
Core settlement platform, storage, infrastructure |
Storage failure, cyberattack |
Very High |
High availability, storage redundancy, cyber resilience |
Disaster recovery tests, failover reports |
Validate uninterrupted RTGS settlement. |
|
CBS-1.7 |
Deferred Net Settlement Processing |
Clearing participants, batch systems |
Batch corruption |
High |
Independent reconciliation, control totals |
Batch validation reports, reconciliation evidence |
Verify integrity of deferred settlement cycles. |
|
CBS-1.8 |
Settlement Finalisation and Confirmation |
Settlement ledger, reporting |
Data replication failure |
Very High |
Ledger reconciliation, immutable audit records |
Ledger integrity tests, replication validation |
Validate preservation of settlement finality. |
|
CBS-1.9 |
Exception and Failed Transaction Management |
Operations, participants, support teams |
Platform outage |
High |
Automated prioritisation, alternate manual procedures |
Exercise reports, backlog recovery metrics |
Assess ability to recover payment backlogs. |
|
CBS-1.10 |
Settlement Risk Monitoring and Control |
Monitoring platforms, risk dashboards |
Ransomware |
High |
Independent monitoring, offline dashboards |
Security monitoring reports, cyber exercises |
Validate monitoring during degraded operations. |
|
CBS-1.11 |
Payment System Oversight and Compliance Monitoring |
Regulatory reporting, compliance teams |
Data integrity attack |
High |
Independent validation, protected reporting |
Internal audit, regulatory reporting tests |
Confirm supervisory oversight resilience. |
|
CBS-1.12 |
Operational Incident and Service Disruption Management |
Crisis teams, communications |
Collaboration platform failure |
High |
Out-of-band communications, crisis exercises |
Crisis exercise reports, call-tree testing |
Evaluate incident coordination effectiveness. |
|
CBS-1.13 |
Business Continuity and Service Recovery |
Recovery infrastructure, alternate facilities |
Recovery environment ransomware |
Very High |
Immutable backups, cyber recovery exercises |
DR tests, cyber recovery reports |
Demonstrate recovery within approved Impact Tolerance. |
|
CBS-1.14 |
Settlement Reporting and Regulatory Information Management |
Data warehouse, regulators, management |
Database corruption |
High |
Data validation, protected reporting architecture |
Reporting validation, backup restoration testing |
Validate regulatory reporting continuity. |
|
CBS-1.15 |
Post-Settlement Review and Continuous Improvement and Decision Support |
Governance, audit, risk management |
Repository corruption |
Medium |
Central remediation tracking, protected governance repositories |
Internal audit findings, remediation registers |
Verify organisational learning and continuous improvement capability. |
Collectively, these fifteen scenarios test the resilience of every stage of the Payment & Settlement Systems lifecycle:
These scenarios deliberately combine operational disruption, cyber events, ICT failures, people dependencies, facilities, telecommunications, and third-party interdependencies to evaluate the resilience of the complete Critical Business Service rather than isolated technology components.
The scenarios are designed to support generally recognised Operational Resilience principles that supervisory authorities expect financial institutions and financial market infrastructures to demonstrate, including:
These considerations are implementation recommendations and should not be interpreted as specific regulatory requirements of the Brunei Darussalam Central Bank unless formally prescribed.
Severe but Plausible Scenarios provide one of the most effective methods for evaluating whether CBS-1 Payment & Settlement Systems can continue operating within its approved Impact Tolerance during extreme but credible disruption.
By developing scenarios at the Sub-CBS level, BDCB can assess not only the resilience of individual operational processes but also the interaction of people, technology, cyber controls, facilities, third-party providers, and governance arrangements that collectively sustain the end-to-end payment and settlement service.
The scenarios demonstrate that Operational Resilience cannot be achieved through technology recovery alone.
Cybersecurity events, ICT failures, operational errors, human decision-making, telecommunications disruption, third-party dependencies, and ineffective incident management can interact to amplify disruption and accelerate the breach of the Critical Business Service's Impact Tolerance.
Embedding Cyber and ICT Risks directly into each scenario therefore provides a more realistic representation of how major operational incidents develop.
Equally important are the recommended proactive risk management actions and the supporting evidence identified for every scenario.
Architecture resilience reviews, cyber threat assessments, failover and disaster recovery testing, penetration testing, capacity testing, business continuity exercises, crisis management simulations, independent assurance reviews, Internal Audit findings, and Board or Board Risk Committee oversight collectively demonstrate that resilience capabilities are implemented, tested, governed, and continuously improved rather than merely documented.
The completed scenario catalogue establishes the foundation for BDCB's Operational Resilience scenario testing programme.
The outcomes of these exercises should be analysed to determine whether the approved Impact Tolerance can be maintained under severe conditions, identify residual vulnerabilities, prioritise remediation activities, inform future investment decisions, strengthen governance and oversight, and support continuous improvement of the resilience of Brunei's national payment and settlement infrastructure.
| eBook 3: Starting Your OR Implementation |
||||
| CBS-1 Payment and Settlement Systems | ||||
| CBS-1 DP | CBS-1 MII | CBS-1 ITo | CBS-1 SbPS | CBS-1 ST |
Gain Competency: For organisations looking to accelerate their journey, BCM Institute’s training and certification programs, including the OR-5000 Operational Resilience Expert Implementer course, provide in-depth insights and practical toolkits for effectively embedding this model.
To learn more about the course and schedule, click the buttons below for the [OR-3] OR-300 Operational Resilience Implementer course and the [OR-5] OR-5000 Operational Resilience Expert Implementer course.
|
If you have any questions, click to contact us. |
||
|
|