---
title: [OR] [MBSB] [E3] [CBS] [2] [ST] Perform Scenario Testing
description: [OR] [MBSB] [E3] [CBS] [2] [ST] Perform Scenario Testing
image: https://blog.bcm-institute.org/hubfs/MBSB%20Graphic%20Folder/MBSB%20CBS%202/%5BOR%5D%20%5BMBSB%5D%20%5BE3%5D%20%5BCBS%5D%20%5B2%5D%20%5BST%5D%20Domestic%20Funds%20Transfer%20and%20Payment%20Services.jpg
---
. .
[](http://www.bcm-institute.org/)
- [Home](https://www.bcm-institute.org/)
- [About Us](https://www.bcm-institute.org/about-us-3/)
- [A President’s Perspective](https://www.bcm-institute.org/about-us/a-presidents-perspective/)
- [Our History](https://www.bcm-institute.org/about-us/our-history/)
- [Our Advisory Council](https://www.bcm-institute.org/about-us/our-advisory-council/)
- [Customers’ Testimonials](https://www.bcm-institute.org/about-us/customers-testimonials/)
- [Credential Verification](https://www.bcm-institute.org/about-us/credential-verification/)
- [Courses](https://blog.bcm-institute.org/blog/course-fees-for-blended-learning-courses-master-catalog)
- [ISO 22301 Business Continuity Management System Audit](https://blog.bcm-institute.org/audit/business-continuity-management-audit-courses)
- [ISO 22301 Business Continuity Management](https://blog.bcm-institute.org/bcm/business-continuity-management-courses)
- [Crisis Communication](https://blog.bcm-institute.org/crisis-communication/crisis-communication-courses)
- [Crisis Management](https://blog.bcm-institute.org/en/crisis-management/courses)
- [IT Disaster Recovery](https://blog.bcm-institute.org/it-disaster-recovery/courses)
- [Operational Resilience](https://blog.bcm-institute.org/operational-resilience/courses)
- [Operational Resilience Audit](https://blog.bcm-institute.org/operational-resilience-audit/courses)
- [Certification](https://blog.bcm-institute.org/certification/types-of-certifications-offered)
- [ISO 22301 BCMS Audit Certification](https://blog.bcm-institute.org/certification/business-continuity-management-audit-certification)
- [ISO22301 Business Continuity Management Certification](https://blog.bcm-institute.org/bcm/business-continuity-management-certification)
- [Crisis Communication Certification](https://blog.bcm-institute.org/crisis-communication/crisis-communication-certification)
- [Crisis Management Certification](https://blog.bcm-institute.org/en/crisis-management/crisis-management-certification)
- [IT Disaster Recovery Planning Certification](https://blog.bcm-institute.org/it-disaster-recovery/it-disaster-recovery-certification)
- [Operational Resilience Certification](https://blog.bcm-institute.org/operational-resilience/operational-resilience-certification)
- [Operational Resilience Audit Certification](https://blog.bcm-institute.org/operational-resilience-audit)
- [Seminars](https://blog.bcm-institute.org/meet-the-expert/mte-webinar-mainpage)
- [Store](https://www.bcm-institute.org/store-2/)
- [Contact Us](http://www.bcm-institute.org/about-us/contact-us/)
-
-
###### Operational Resilience in Action: The MBSB Approach
![BB OR \[B\] 13](https://blog.bcm-institute.org/hs-fs/hubfs/OR%20picture/OR%20Pictures%20A/BB%20OR%20Folder%20B/BB%20OR%20%5BB%5D%2013.jpg?width=2000&height=1333&name=BB%20OR%20%5BB%5D%2013.jpg "BB OR [B] 13")
# \[OR\] \[MBSB\] \[E3\] \[CBS\] \[2\] \[ST\] Perform Scenario Testing
[![\[OR\] \[MBSB\] \[Full Banner\] Operational Resilience in Action The MBSB Bank's Approach ](https://no-cache.hubspot.com/cta/default/3893111/567eecca-dbad-4a1a-8465-5d45335ce5da.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/567eecca-dbad-4a1a-8465-5d45335ce5da)
Scenario Testing is a critical component of MBSB's Operational Resilience implementation programme.
It provides a structured way to determine whether CBS-2: Domestic Funds Transfer and Payment Services can continue delivering essential customer payment outcomes during Severe but Plausible Scenarios without exceeding its approved Impact Tolerance.
Effective Scenario Testing must extend beyond verifying the recovery of individual technology systems, business continuity arrangements, or operational departments.
It must assess the combined ability of people, processes, technology, information, facilities, third-party providers, and external payment infrastructures to sustain the end-to-end delivery of domestic payment services.
The 24 previously identified Sub-CBS processes provide a detailed foundation for designing realistic, measurable tests.
These processes cover payment initiation, authentication, validation, processing, execution, settlement, confirmation, reconciliation, monitoring, exception handling, continuity, and controlled restoration.
The Severe but Plausible Scenarios developed in the preceding chapter form the basis of this testing programme.
Each test should challenge key interconnections and interdependencies, evaluate the effectiveness of existing controls, and determine whether disruption could cause unacceptable harm.
### [](https://cta-redirect.hubspot.com/cta/redirect/3893111/3c32e9b3-ea88-44c3-9182-fa3e6a9aadee)
[Dr Goh Moh Heng](https://blog.bcm-institute.org/ebook-or/author/dr-goh-moh-heng) Oct 14, 2026
###### Operational Resilience Certified Planner-Specialist-Expert
### [![x \[OR\] \[MBSB\] Legal Disclaimer Banner](https://no-cache.hubspot.com/cta/default/3893111/d779f9ab-aec0-4cdd-a906-81e7841c3e1c.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/d779f9ab-aec0-4cdd-a906-81e7841c3e1c)
### [](https://cta-redirect.hubspot.com/cta/redirect/3893111/3c32e9b3-ea88-44c3-9182-fa3e6a9aadee)
### **CBS-2 Domestic Funds Transfer and Payment Services**
#### Introduction
[](https://cta-redirect.hubspot.com/cta/redirect/3893111/fe85e2f2-f972-49ad-8321-d370fcfd9caf)[![\[OR\] \[MBSB\] \[E3\] \[CBS\] \[2\] \[ST\] Domestic Funds Transfer and Payment Services](https://no-cache.hubspot.com/cta/default/3893111/bd69c69a-27ca-4958-b8ed-88616906ad6f.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/bd69c69a-27ca-4958-b8ed-88616906ad6f)
Scenario Testing is a critical component of MBSB's Operational Resilience implementation programme.
It provides a structured way to determine whether CBS-2: Domestic Funds Transfer and Payment Services can continue delivering essential customer payment outcomes during Severe but Plausible Scenarios without exceeding its approved Impact Tolerance.
Effective Scenario Testing must extend beyond verifying the recovery of individual technology systems, business continuity arrangements, or operational departments.
It must assess the combined ability of people, processes, technology, information, facilities, third-party providers, and external payment infrastructures to sustain the end-to-end delivery of domestic payment services.
The 24 previously identified Sub-CBS processes provide a detailed foundation for designing realistic, measurable tests.
These processes cover payment initiation, authentication, validation, processing, execution, settlement, confirmation, reconciliation, monitoring, exception handling, continuity, and controlled restoration.
The Severe but Plausible Scenarios developed in the preceding chapter form the basis of this testing programme.
Each test should challenge key interconnections and interdependencies, assess the effectiveness of existing controls, and determine whether disruption could cause unacceptable harm.
Integrate Cybersecurity and Information and Communications Technology (ICT) risks throughout the programme because cyberattacks, data corruption, technology failures, network disruptions, third-party outages, and compromised recovery environments can simultaneously affect several Sub-CBS processes.
The resulting evidence should enable MBSB's management to understand its demonstrated resilience capabilities, identify gaps between actual performance and approved Impact Tolerance, and prioritise remediation and resilience investment.
#### **Scenario Testing Objectives and Assessment Principles**
The overall objective is to demonstrate whether MBSB can maintain or safely restore CBS-2 within its approved Impact Tolerance during severe operational disruption.
The testing programme should establish whether:
1. Essential domestic payments can continue through approved normal or alternative arrangements.
2. Disruptions can be detected, assessed and escalated before unacceptable customer harm develops.
3. Cybersecurity, fraud prevention, transaction authorisation and compliance controls remain effective.
4. Critical technology, operational and external dependencies can withstand or recover from disruption.
5. Payment processing capacity remains sufficient to support essential customer outcomes.
6. Account balances, transaction records, beneficiary credits and settlement information remain reliable.
7. Recovery arrangements can restore trusted payment processing without duplicate, missing or incorrect transactions.
8. Management decisions are timely, informed and supported by accurate service-impact information.
9. Scenario test findings produce measurable improvements in resilience capability.
##### **Impact Tolerance Assumptions**
For continuity with the preceding CBS-2 assessment, this chapter uses the following illustrative thresholds.
| Impact Tolerance Dimension | Illustrative Assessment Boundary |
| --- | --- |
| Maximum material service disruption | 2 hours |
| Minimum essential payment processing capacity | 50% of normal peak-hour throughput |
| Maximum materially affected customer population | 10% of normally active payment customers in the relevant period |
| Additional essential payment processing delay | 15 minutes, where consistent with applicable scheme obligations |
| Payment integrity | No knowingly unverified, duplicate or incorrect payment execution causing material financial harm |
| Settlement and regulatory obligations | No breach of applicable mandatory requirements |
These thresholds are implementation assumptions, not confirmed MBSB tolerances or BNM-prescribed limits.
MBSB must validate them using customer-harm analysis, transaction data, payment scheme requirements, regulatory obligations and management approval.
A test may reveal a breach before two hours have elapsed if financial integrity, customer harm, settlement obligations or another approved boundary becomes unacceptable.
##### **Testing Methodology**
Select different testing methods based on the risk and resilience capability being evaluated.
| Testing Method | Appropriate Application | Principal Limitation |
| --- | --- | --- |
| Walk-through | Validate procedures, responsibilities and operational hand-offs | Does not prove actual processing or recovery capability |
| Tabletop exercise | Challenge decision-making, escalation and crisis coordination | Relies substantially on assumed technical outcomes |
| Simulation exercise | Reproduce transaction queues, customer impacts and operational workloads | Accuracy depends on representative test conditions |
| Technical recovery or failover test | Verify recovery of applications, databases, infrastructure and connectivity | Does not independently demonstrate end-to-end customer outcomes |
| Cyber incident simulation | Test detection, containment, security decisions and cyber recovery | May require supplementary transaction-integrity testing |
| Data integrity and reconciliation test | Verify transaction completeness, correctness and recoverability | Requires representative transaction states and independent evidence |
| Capacity and stress test | Establish degraded processing capacity and backlog behaviour | Must be translated into customer-impact measures |
| Third-party disruption exercise | Evaluate external dependencies and coordinated response | Participation and realism may be constrained by external parties |
| Integrated end-to-end CBS test | Assess the combined service outcome against Impact Tolerance | Requires extensive planning, coordination and controlled execution |
The programme should combine these methods rather than rely exclusively on tabletop exercises or disaster recovery testing.
#### **Integrated Scenario Testing Programme**
MBSB should establish six integrated test programmes that collectively cover the 24 Sub-CBS processes. Individual Sub-CBS tests should operate as measurable components within these broader exercises.
| Programme | Integrated Test Theme | Primary Coverage |
| --- | --- | --- |
| ST-01 | Customer Channel, Authentication and Payment Validation Resilience | CBS-2.1–2.7 |
| ST-02 | Core Banking, Payment Processing and Transaction Integrity | CBS-2.8–2.12 |
| ST-03 | Domestic Interbank Payment and Settlement Resilience | CBS-2.13–2.15 |
| ST-04 | Payment Confirmation, Reconciliation and Evidence Integrity | CBS-2.16–2.18 |
| ST-05 | Monitoring, Exceptions, Investigation and Escalation | CBS-2.19–2.22 |
| ST-06 | Payment Continuity, Cyber Recovery and Controlled Restoration | CBS-2.23–2.24, incorporating upstream processes |
These programmes should not be treated as isolated operational stages.
Each should trace disruption consequences through the payment lifecycle and measure the resulting customer and financial impacts.
[![Banner \[Table\] \[OR\] \[E3\] Perform Scenario Testing](https://no-cache.hubspot.com/cta/default/3893111/a45e9708-7139-4f4e-8e0e-41179f5cacc3.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/a45e9708-7139-4f4e-8e0e-41179f5cacc3)
#### **Recommended Scenario Testing for Each Sub-CBS**
Table 1 identifies the Severe but Plausible Scenario, recommended test, testing method, objective, scenario injects and principal dependencies to be challenged.
Conduct each test in an appropriately controlled environment.
Any live production testing must be separately risk-assessed, authorised and designed to avoid unintended customer harm or payment-system disruption.
Table P6: Perform Scenario Testing for CBS-2
| Sub-CBS Code | Name of Sub-CBS | Severe but Plausible Scenario | Recommended Scenario Test | Testing Method | Scenario Testing Objective | Key Scenario Injects / Disruption Conditions | Interconnections and Interdependencies Tested |
| --- | --- | --- | --- | --- | --- | --- | --- |
| CBS-2.1 | Customer Payment Instruction Initiation | Coordinated DDoS attack and digital channel overload | ST-01A: Payment Channel Resilience Test | Controlled DDoS simulation, capacity stress test and channel failover; directly measures customer access under load. | Verify essential payment initiation capacity and customer access within approved limits. | Digital channel traffic surge; repeated timeouts; simulated secondary-channel congestion; rising customer complaints. | CBS-3 Digital Banking Services; CBS-2.2; channel gateways; telecommunications; branch operations. |
| CBS-2.2 | Payment Instruction Capture and Registration | Message queue failure and duplicate customer submissions | ST-01B: Instruction Capture Integrity Test | Message queue fault injection and data integrity simulation; tests actual transaction-state preservation. | Demonstrate that accepted instructions remain traceable and are processed no more than once. | Message broker restart; interrupted acknowledgement; duplicate submissions; incomplete registration records. | CBS-2.1, 2.3, 2.18; message queues; transaction database; payment gateway. |
| CBS-2.3 | Payment Instruction Completeness Validation | Defective validation rules across payment channels | ST-01C: Payment Validation Change Failure Test | Application fault simulation and rollback test; measures detection and recovery from defective rules. | Detect erroneous rejection patterns and restore valid payment acceptance before material customer harm. | Defective rule deployment; abnormal rejection rate; rollback failure; growing exception queue. | CBS-2.2, 2.4, 2.7, 2.20; validation engine; change management; reference data. |
| CBS-2.4 | Customer Authentication and Payment Authorisation | Identity platform compromise and authentication suspension | ST-01D: Authentication Compromise and Safe Continuity Test | Cyber incident simulation integrated with authentication failover; tests security and service continuity together. | Demonstrate containment of identity compromise while preserving safe payment authorisation. | Suspicious privileged access; authentication service restriction; corporate approval failure; alternative channel activation. | CBS-8 Customer Transaction Authentication and Authorisation Services; CBS-3 Digital Banking Services; CBS-2.5; identity services. |
| CBS-2.5 | Account Eligibility and Payment Limit Validation | Corrupted account restriction and payment limit records | ST-01E: Account Control Data Integrity Test | Controlled data corruption simulation and independent reconciliation; tests correctness of account-control decisions. | Identify corrupted eligibility information and restore trusted payment-control records. | Incorrect account status; conflicting limits; bulk rejection; failed reference-data restoration. | CBS-1 Customer Deposit and Account Access Services; CBS-2.4, 2.8; core banking; account records. |
| CBS-2.6 | Payment Fraud and Compliance Screening | Screening service outage during coordinated fraud attempts | ST-01F: Screening Failure and Restricted Processing Test | Cyber-fraud simulation and third-party disruption exercise; challenges safe continuation without mandatory control bypass. | Validate fraud containment, screening contingency and safe prioritisation of essential payments. | Screening interface outage; suspicious transaction surge; delayed provider response; management pressure to release queued payments. | Fraud operations; compliance; CBS-2.7, 2.9, 2.20; screening services; third-party support. |
| CBS-2.7 | Beneficiary and Payment Destination Validation | Compromised beneficiary verification responses | ST-01G: Beneficiary Integrity and Payment Redirection Test | Simulates API security and data integrity; verifies prevention of misdirected payments. | Detect inconsistent beneficiary information and prevent unsafe transaction execution. | Altered verification response; mismatched beneficiary record; suspicious destination change; API failover. | CBS-2.3, 2.8, 2.20; beneficiary records; payment verification interfaces; fraud monitoring. |
| CBS-2.8 | Funds Availability and Account Balance Verification | Core banking balance service outage during payment peak | ST-02A: Core Banking Balance Resilience Test | Database failover and integrated payment simulation; tests availability and trustworthiness of balance information. | Restore reliable funds verification while protecting customer account integrity. | Balance lookup timeouts; stale replica data; increased payment retries; database failover delay. | CBS-1 Customer Deposit and Account Access Services; CBS-2.9, 2.10; core banking; ledger database. |
| CBS-2.9 | Payment Transaction Classification and Processing | Payment engine capacity exhaustion during transaction surge | ST-02B: Peak Payment Capacity and Backlog Test | Capacity and stress test with end-to-end transaction simulation; quantifies throughput and backlog behaviour. | Determine whether essential payment throughput remains above the approved minimum. | Peak-hour transaction surge; processing bottleneck; queue growth; degraded downstream gateway capacity. | CBS-2.8, 2.10–2.13; payment processing engine; message queues; payment infrastructure. |
| CBS-2.10 | Customer Account Debit and Transaction Posting | Ransomware causing ledger transaction-state uncertainty | ST-02C: Ledger Cyber Recovery and Posting Integrity Test | Cyber recovery exercise with transaction-state reconstruction and reconciliation; tests safe recovery rather than application restart. | Demonstrate trusted debit posting and prevention of duplicate or missing financial transactions. | Ransomware containment; interrupted debit posting; corrupted transaction journal; compromised recovery data. | CBS-1 Customer Deposit and Account Access Services; CBS-2.8, 2.12, 2.17; ledger; cyber recovery. |
| CBS-2.11 | Payment Instruction Routing and Transmission | Primary and secondary payment gateway connectivity failure | ST-02D: Payment Gateway Network Resilience Test | Network failover and message queue recovery test; directly challenges assumed connectivity redundancy. | Restore safe payment routing and preserve instructions during dual-route failure. | Primary route loss; secondary route misconfiguration; certificate or session failure; growing transmission queue. | CBS-2.9, 2.13; network services; payment gateway; telecommunications; external payment infrastructure. |
| CBS-2.12 | Internal Funds Transfer Execution | Defective deployment creating incomplete debit-credit states | ST-02E: Internal Transfer Atomicity and Rollback Test | Transaction integrity test and controlled software rollback; validates complete debit-credit outcomes. | Confirm that internal transfers are completed or safely reversed without unmatched account entries. | Debit succeeds but credit fails; application rollback; interrupted transfer confirmation; repeated transaction submission. | CBS-1 Customer Deposit and Account Access Services; CBS-2.10, 2.15, 2.17; core ledger. |
| CBS-2.13 | Domestic Interbank Payment Execution | Prolonged external domestic payment network outage | ST-03A: Interbank Payment Infrastructure Disruption Test | Third-party disruption exercise and end-to-end payment simulation; tests an external dependency beyond the bank's direct control. | Demonstrate management of essential interbank payments, queues and customer harm during external infrastructure failure. | External network unavailable; delayed acknowledgements; payment queue growth; industry incident notification. | CBS-2.11, 2.14, 2.15; CBS-7 High-Value and Interbank Payment Services where shared; payment infrastructure; receiving banks. |
| CBS-2.14 | Interbank Clearing and Settlement Coordination | Settlement interface failure during liquidity-sensitive period | ST-03B: Settlement Integrity and Liquidity Coordination Test | Settlement simulation and treasury crisis exercise; tests financial obligations and decision-making. | Validate settlement status, liquidity decisions and escalation when reliable external settlement information is unavailable. | Missing settlement confirmation; inconsistent settlement records; funding pressure; delayed counterparty response. | CBS-2.13, 2.15, 2.17; treasury; settlement infrastructure; counterparties. |
| CBS-2.15 | Beneficiary Credit and Payment Completion Management | Incoming credit processing failure and inconsistent acknowledgements | ST-03C: Beneficiary Credit Completion Test | End-to-end transaction replay and reconciliation test; verifies the actual customer payment outcome. | Establish the verified status of every test payment and prevent duplicate beneficiary credits. | Upstream payment acknowledgement; beneficiary posting failure; delayed credit; repeated completion messages. | CBS-1 Customer Deposit and Account Access Services; CBS-2.12–2.14, 2.16; beneficiary ledger. |
| CBS-2.16 | Payment Status Confirmation and Customer Notification | Messaging provider outage during payment degradation | ST-04A: Payment Status and Customer Communication Test | Third-party communication disruption simulation; tests verified customer messaging during uncertainty. | Provide accurate payment status and customer guidance through alternative channels. | Notification provider outage; delayed transaction status; duplicate customer retries; call-centre overload. | CBS-3 Digital Banking Services; CBS-9 Customer Support and Assistance During Banking Disruptions; CBS-2.15, 2.21; messaging provider. |
| CBS-2.17 | Payment Reconciliation and Financial Control | Corrupted settlement data causing widespread mismatches | ST-04B: Settlement Data Corruption and Reconciliation Test | Data corruption and independent reconciliation test; measures detection and correction of financial discrepancies. | Identify corrupted records, isolate unreliable data and verify payment completeness. | Altered settlement file; unexplained debit-credit differences; automated matching errors; delayed external confirmation. | CBS-2.10, 2.14–2.15, 2.18; finance; settlement data; transaction records. |
| CBS-2.18 | Payment Records and Transaction Audit Management | Destructive cyberattack against payment evidence repositories | ST-04C: Payment Evidence Preservation and Recovery Test | Cyber incident simulation and protected-record restoration; tests recovery of trustworthy audit evidence. | Recover reliable transaction evidence required for investigation, reconciliation and controlled restoration. | Privileged account compromise; audit-log deletion; corrupted archive; backup access failure. | CBS-2.2, 2.10, 2.17, 2.21, 2.24; audit logging; transaction archive; cybersecurity. |
| CBS-2.19 | Payment Service Monitoring and Operational Control | Monitoring blind spot during progressive payment degradation | ST-05A: Payment Service Detection and Monitoring Test | Monitoring fault injection and synthetic transaction testing; checks detection of actual service harm. | Detect payment degradation before customer impact and capacity limits are exceeded. | Suppressed alerts; rising payment latency; increasing failed transactions; unavailable monitoring dashboard. | CBS-2.1–2.18; technology operations; payment monitoring; incident management. |
| CBS-2.20 | Payment Exception, Rejection and Return Management | Mass payment rejection and specialist staffing shortage | ST-05B: Payment Exception Surge Test | Operational workload simulation with reduced staffing; tests exception capacity and safe corrective processing. | Prioritise and resolve essential payment exceptions without uncontrolled backlog growth. | Thousands of simulated rejections; reduced specialist staffing; failed automatic return processing; urgent customer cases. | CBS-2.13–2.17, 2.21; payment operations; receiving institutions; specialist staff. |
| CBS-2.21 | Payment Dispute and Transaction Investigation | Coordinated fraud event overwhelming investigation capacity | ST-05C: Payment Fraud Dispute Surge Test | Fraud response and operational case-management simulation; tests high-harm customer prioritisation. | Demonstrate timely investigation, evidence preservation and escalation of serious payment disputes. | Fraud alerts surge; multiple disputed transfers; incomplete evidence; rising customer complaints. | CBS-9 Customer Support and Assistance During Banking Disruptions; CBS-2.18, 2.20; fraud operations; compliance. |
| CBS-2.22 | Payment Disruption Assessment and Service Escalation | Delayed escalation during multi-CBS technology failure | ST-05D: Multi-Service Crisis Escalation Test | Integrated crisis management exercise; tests governance, decisions and service-impact assessment. | Recognise CBS-level harm promptly and activate coordinated continuity and recovery responses. | Simultaneous payment and digital banking failure; conflicting incident reports; unclear decision authority; escalating customer harm. | CBS-1 Customer Deposit and Account Access Services; CBS-3 Digital Banking Services; CBS-9 Customer Support and Assistance During Banking Disruptions; CBS-2.19–2.24. |
| CBS-2.23 | Payment Continuity and Alternative Processing | Regional flooding disables primary and alternative arrangements | ST-06A: Essential Payment Continuity Under Regional Disruption | Integrated business continuity simulation with facilities and telecommunications failure; challenges common-cause dependencies. | Sustain the minimum approved essential payment capability when normal facilities and part of the contingency arrangements are unavailable. | Flooded operations site; telecommunications outage; unavailable specialists; reduced alternative-site capacity. | CBS-2.9–2.15; BCM; facilities; telecommunications; alternative processing arrangements. |
| CBS-2.24 | Payment Service Recovery and Controlled Restoration | Primary and recovery failure with corrupted transaction states | ST-06B: End-to-End Cyber Recovery and Safe Restoration Test | Integrated cyber recovery, disaster recovery and payment reconciliation exercise; tests the complete recovery outcome. | Restore trusted payment processing within tolerance without duplicate, missing or incorrect transactions. | Compromised primary environment; failed recovery validation; corrupted transaction journal; large payment backlog. | CBS-2.10, 2.15, 2.17–2.18, 2.23; disaster recovery; cybersecurity; finance control; payment infrastructure. |
##### **Recommended Participants and Responsibilities**
The test plan should name actual participants, alternates, observers and controllers.
The following assignments are illustrative.
| Integrated Programme | Principal Participants | Test Controllers and Observers |
| --- | --- | --- |
| ST-01 | Digital Banking, Payment Operations, Identity and Access Management, Fraud, Compliance, Application Support, ICT Risk | Operational Resilience test lead; Cybersecurity and Operational Risk observers |
| ST-02 | Core Banking, Payment Technology, Database Administration, Network Operations, Cybersecurity, Finance Control | Technology recovery controller; Payment Operations and ICT Risk observers |
| ST-03 | Payment Operations, Treasury, Settlement Operations, Network Operations, external payment infrastructure representatives where feasible | CBS-2 Owner; Treasury Risk and Operational Resilience observers |
| ST-04 | Finance, Reconciliation, Customer Service, Records Management, Cybersecurity, relevant third parties | Financial Control test lead; Compliance and Internal Audit observers where appropriate |
| ST-05 | Payment Monitoring, Incident Management, Fraud Operations, Customer Support, BCM, Crisis Management | Crisis exercise controller; Operational Risk and senior management observers |
| ST-06 | BCM, Crisis Management, Payment Operations, Technology Recovery, Cybersecurity, Facilities, Third-Party Risk, Finance | Integrated exercise director; CBS-2 Owner and independent assurance observers |
Internal Audit should generally retain its independent assurance role rather than assume responsibility for designing or operating management's controls.
#### **Impact Tolerance Validation, Cyber and ICT Risk Integration, Evidence and Proactive Risk Management**
Table 2 establishes the expected resilience outcomes and evidence requirements for each Sub-CBS test.
The distinction between test evidence and evidence of proactive risk management is important.
Test evidence establishes what happened during the exercise.
Proactive risk management evidence demonstrates that preventive measures, control improvements, recovery arrangements and corrective actions have actually been implemented and verified.
**Table: Scenario Testing Outcomes and Proactive Risk Management Assessment**
| Sub-CBS Code | Name of Sub-CBS | Cyber and ICT Risk Linkage | Impact Tolerance Boundary Tested | Expected Resilience Outcome | Evidence to be Collected | Proactive Risk Management Action | Evidence of Proactive Risk Management |
| --- | --- | --- | --- | --- | --- | --- | --- |
| CBS-2.1 | Customer Payment Instruction Initiation | DDoS is the trigger; API saturation and shared telecommunications amplify channel failure. Test security detection, traffic filtering, channel failover and customer access. | Customer scope ≤10%; essential capacity ≥50%; material disruption ≤2 hours. | Essential customers can initiate payments through safe, available channels without overwhelming downstream processing. | Channel transaction counts, failed requests, latency, security alerts, failover timing and affected-customer estimates. | Improve DDoS mitigation, independently validate channel capacity and establish alternative payment initiation procedures. | DDoS test reports, capacity assurance, approved continuity procedures and completed failover remediation. |
| CBS-2.2 | Payment Instruction Capture and Registration | Failed ICT change triggers message loss; queue restart and customer retries amplify duplication. Test durable messaging and recovery. | Transaction integrity; essential for payment delays and backlog duration. | Account for every accepted instruction, and ensure no payment executes more than once. | Message sequence records, duplicate counts, instruction references, queue recovery time and reconciliation results. | Implement persistent queues, idempotent processing, transaction identifiers and controlled message replay. | Message integrity tests, architecture reviews, replay testing and approved corrective-action closure. |
| CBS-2.3 | Payment Instruction Completeness Validation | Application deployment is the trigger; shared validation configuration propagates incorrect rejection decisions. | Customer scope, rejection-related delay, essential capacity and duration. | Detect defective rules and roll them back before material payment disruption develops. | Rejection rates, alert timestamps, rollback duration, valid-payment acceptance results and exception backlog. | Strengthen regression testing, deployment controls, abnormal rejection monitoring and emergency rollback. | Change control records, automated regression results, monitoring configuration and rollback exercise reports. |
| CBS-2.4 | Customer Authentication and Payment Authorisation | Privileged access compromise triggers containment; shared identity service failure affects CBS-8 and payment channels. | Customer scope, duration and immediate authorisation-integrity harm. | Contain compromised access, prevent unauthorised payments, and preserve approved safe payment capability. | Identity security logs, access decisions, containment time, authentication success rates and customer impact. | Strengthen privileged access management, independent authentication recovery and emergency authorisation governance. | Access certification, penetration tests, authentication failover reports and cyber exercise remediation evidence. |
| CBS-2.5 | Account Eligibility and Payment Limit Validation | Corrupted account data triggers incorrect decisions; shared core banking records amplify impact. | Transaction integrity, customer scope and payment rejection rates. | Restore trusted account eligibility and limits without approving restricted or unauthorised payments. | Data comparison results, incorrect decision counts, restoration times, audit trails and payment retest outcomes. | Establish independent reference-data validation, controlled bulk changes and recovery of trusted account-control records. | Data integrity tests, dual-control records, approved change procedures and recovery validation reports. |
| CBS-2.6 | Payment Fraud and Compliance Screening | Third-party ICT failure is the trigger; coordinated fraud attempts amplify financial harm. Test alerting, provider escalation and restricted processing. | Mandatory control integrity; duration; essential payment capacity and customer scope. | Fraud and compliance controls remain effective while essential payments are processed through approved arrangements. | Screening availability, alert counts, held-payment queues, provider response, control exceptions and release decisions. | Establish resilient screening arrangements, provider contingency plans and approved payment prioritisation rules. | Provider assurance, contingency exercise reports, screening control tests and Compliance approval records. |
| CBS-2.7 | Beneficiary and Payment Destination Validation | An API compromise can trigger unreliable destination data; corrupted responses may redirect transactions. | Immediate transaction-integrity harm; affected customer and payment volumes. | Detect, restrict, and investigate unsafe beneficiary instructions before payment execution. | API response comparisons, mismatched records, blocked transactions, fraud alerts and investigation outcomes. | Strengthen API integrity validation, beneficiary-change monitoring, and suspicious-payment hold controls. | API security testing, data integrity assurance, fraud monitoring reports and completed control enhancements. |
| CBS-2.8 | Funds Availability and Account Balance Verification | Core banking database failure triggers unavailable or stale balances; shared ledger concentration amplifies disruption. | Duration, essential capacity, customer scope and balance integrity. | Reliable funds checks resume without relying on unverified balances or causing incorrect payment approvals. | Balance response times, failover timing, stale-data counts, transaction failures and reconciliation results. | Improve database resilience, replica consistency monitoring, recovery validation and core banking capacity. | Database failover tests, reconciliation reports, architecture assurance and remediation closure records. |
| CBS-2.9 | Payment Transaction Classification and Processing | Capacity exhaustion is the trigger; processing inefficiency and queue congestion amplify delays. | Essential capacity ≥50%; additional latency ≤15 minutes; duration and customer scope. | Maintain or recover essential payment throughput before unacceptable backlog-related harm occurs. | Transactions per minute, queue depth, processing latency, completion rates, capacity utilisation and customer impact. | Increase tested processing headroom, establish priority queues and implement early capacity escalation. | Stress test results, capacity plans, approved prioritisation rules and performance remediation reports. |
| CBS-2.10 | Customer Account Debit and Transaction Posting | Ransomware triggers posting suspension; corrupted transaction states prolong recovery. Test cyber detection, containment and trusted ledger restoration. | Immediate financial-integrity harm; duration and customer scope. | Restore debits safely, with no material missing, duplicated, or incorrectly posted transactions. | Cyber event logs, transaction journals, account reconciliation, recovery time and restoration approval. | Implement protected transaction journals, segregated recovery, privileged-access restrictions, and independent reconciliation gates. | Cyber recovery tests, privileged access reviews, ledger integrity reports and restoration control approvals. |
| CBS-2.11 | Payment Instruction Routing and Transmission | Network routing failure is the trigger; ineffective secondary connectivity amplifies interbank outage. | Duration, essential payment capacity, backlog and customer scope. | Instructions are safely queued or transmitted through a verified alternative route without loss or duplication. | Network telemetry, gateway failover time, queued messages, transmission success and external acknowledgements. | Validate independent connectivity, route configuration, gateway recovery and message integrity. | Network resilience reports, provider assurance, failover tests and configuration remediation records. |
| CBS-2.12 | Internal Funds Transfer Execution | Failed deployment triggers incomplete debit-credit processing; ledger-state inconsistency amplifies financial harm. | Immediate transaction-integrity harm; duration and completion latency. | Internal transfers either complete correctly or remain safely pending or reversed with a verified state. | Debit-credit matching, incomplete transaction counts, rollback logs, account balances and recovery sign-offs. | Strengthen atomic posting, rollback testing, transaction-state reconciliation and deployment controls. | Transaction integrity test results, release assurance, reconciliation records and approved corrective-action closure. |
| CBS-2.13 | Domestic Interbank Payment Execution | External payment infrastructure outage is the trigger; industry concentration limits substitutability. Test external escalation and queue controls. | Duration, customer scope, essential capacity and applicable payment scheme obligations. | MBSB manages essential payment priorities and customer harm while preserving accurate transaction states. | External incident timeline, payment queue depth, failed transactions, customer impact, provider responses and recovery status. | Strengthen payment network contingency coordination, queue management and alternative arrangements where permitted. | Joint exercise records, provider assurance, approved contingency procedures and payment network test results. |
| CBS-2.14 | Interbank Clearing and Settlement Coordination | Settlement interface failure triggers missing information; delayed data and timing inconsistencies amplify liquidity uncertainty. | Applicable settlement obligations, transaction integrity and material disruption duration. | Keep settlement positions and obligations controlled, with timely escalation of unresolved exposures. | Settlement records, position reconciliation, funding decisions, time synchronisation logs and counterparty communications. | Implement independent settlement validation, liquidity contingency and escalation for missing settlement confirmation. | Settlement reconciliation tests, treasury exercise reports, liquidity contingency approvals and control review findings. |
| CBS-2.15 | Beneficiary Credit and Payment Completion Management | Database failures trigger incomplete beneficiary credits; inconsistent acknowledgements increase duplicate attempts. | Immediate payment-integrity harm; customer scope and duration. | Every payment has a verified status, and no material duplicate or missing beneficiary credits are introduced. | Beneficiary credit records, completion acknowledgements, unmatched transaction counts, duplicate detection and reconciliation. | Implement transaction-state verification, controlled replay, duplicate prevention and beneficiary credit reconciliation. | Payment completion test reports, duplicate-control assurance, reconciliation sign-offs and recovery validation. |
| CBS-2.16 | Payment Status Confirmation and Customer Notification | Third-party messaging failures contribute to payment disruption; inaccurate status information increases retries. | Customer harm, payment delay, duplicate-submission risk and customer scope. | Customers receive accurate payment status and clear guidance through available channels. | Notification delivery rates, message accuracy, retry volumes, complaint trends and communication timelines. | Establish alternative communications, verified status feeds and duplicate-payment prevention messaging. | Messaging contingency exercises, provider assurance, communication templates and customer status accuracy testing. |
| CBS-2.17 | Payment Reconciliation and Financial Control | Corrupted settlement feed triggers mismatches; automated processing may amplify incorrect records. | Immediate financial-integrity harm; settlement obligations and safe restoration. | Corrupted records are isolated, and payment completeness is independently verified before normal processing resumes. | Reconciliation differences, exception ageing, source-file integrity, corrected balances and financial control approvals. | Strengthen independent reconciliation, source-data validation and escalation thresholds for material discrepancies. | Reconciliation testing, integrity-control reports, approved exception procedures and independent assurance findings. |
| CBS-2.18 | Payment Records and Transaction Audit Management | Privileged access compromise triggers audit-record destruction; compromised archives amplify recovery uncertainty. | Financial-integrity harm, investigation capability, and the time to safely restore. | Reliable transaction evidence remains available or is recovered from trusted protected sources. | Audit-log integrity checks, recovered records, access logs, backup recovery time and evidence completeness. | Implement tamper-resistant records, privileged access segregation and independently recoverable transaction evidence. | Audit integrity tests, access reviews, backup restoration reports and cyber remediation closure. |
| CBS-2.19 | Payment Service Monitoring and Operational Control | Monitoring misconfiguration triggers detection failure; missing telemetry amplifies delayed response. | Time to detect and intervene before duration, customer scope or capacity limits are exceeded. | Detect and escalate customer-facing payment degradation even when primary infrastructure monitoring fails. | Detection timestamps, synthetic transaction results, alert coverage, incident tickets and service-impact metrics. | Implement independent CBS-level monitoring, synthetic transactions and alert escalation testing. | Monitoring coverage assessment, alert simulation reports, approved dashboards and completed detection improvements. |
| CBS-2.20 | Payment Exception, Rejection and Return Management | Payment interface defect triggers mass rejections; specialist staffing shortage amplifies backlog. | Payment delay, customer scope, financial-integrity controls and duration. | Prioritise and resolve essential exceptions without unsafe adjustments or uncontrolled backlog growth. | Exception queue size, case ageing, staff availability, adjustment errors, resolution time and customer impact. | Establish surge staffing, cross-training, exception prioritisation and controlled adjustment procedures. | Staffing exercise records, exception capacity tests, adjustment audit reports and training completion records. |
| CBS-2.21 | Payment Dispute and Transaction Investigation | Coordinated fraud event triggers dispute surge; investigation capacity and evidence gaps amplify customer harm. | Material financial harm, customer scope and applicable investigation obligations. | Identify, escalate, and investigate high-harm cases with reliable evidence and appropriate customer protection. | Dispute volumes, case prioritisation, fraud-loss indicators, investigation times, evidence availability and escalation records. | Strengthen fraud surge capacity, evidence preservation, and prioritisation of high-harm cases. | Fraud simulation results, case management assurance, staffing plans and remediation closure records. |
| CBS-2.22 | Payment Disruption Assessment and Service Escalation | Multi-CBS ICT outage triggers operational disruption; fragmented monitoring and communications delay management decisions. | Duration, customer scope, essential capacity and time remaining before a tolerance breach. | Management identifies the full CBS-level impact and promptly activates appropriate continuity and crisis arrangements. | Incident timeline, escalation decisions, customer-impact estimates, management logs and activation timestamps. | Establish integrated service-impact dashboards, decision authority, tolerance triggers and crisis escalation exercises. | Crisis exercise reports, approved escalation matrix, committee minutes and incident response improvements. |
| CBS-2.23 | Payment Continuity and Alternative Processing | Regional flooding triggers facilities and telecommunications disruption; shared dependencies undermine alternative processing. | Essential capacity ≥50%; customer scope ≤10%; duration ≤2 hours, subject to approved limits. | Minimum essential payment capability is sustained through sufficiently independent alternative arrangements. | Staff mobilisation times, alternative-site capacity, connectivity availability, processed payments and customer-impact measures. | Strengthen geographic separation, alternative staffing, independent connectivity and prioritised payment processing. | Business continuity exercise reports, alternate-site tests, network diversity assurance and completed remediation. |
| CBS-2.24 | Payment Service Recovery and Controlled Restoration | Cyber compromise and recovery-environment failure trigger prolonged restoration; corrupted transaction states amplify financial harm. | Duration, essential capacity, customer scope and immediate transaction-integrity harm. | Restore trusted payment processing with verified transaction states and controlled backlog clearance. | Recovery timeline, cyber containment records, transaction reconciliation, backlog clearance, integrity checks and restoration sign-offs. | Establish clean recovery environments, reconstruct transaction states, stage backlog release, and implement formal restoration gates. | Integrated cyber recovery results, disaster recovery reports, reconciliation approvals and independent closure verification. |
##### **Interpreting the Results**
The expected resilience outcomes in Table 2 are test acceptance criteria, not statements about MBSB's current capabilities.
A test should record an outcome as:
| Outcome | Interpretation |
| --- | --- |
| Demonstrated within tolerance | The tested end-to-end service remained within all applicable approved boundaries, supported by sufficient evidence. |
| Demonstrated with limitations | The service remained within tolerance, but significant control weaknesses or untested assumptions remain. |
| Impact Tolerance breached | One or more approved service-level boundaries were exceeded. |
| Inconclusive | Test scope, simulation fidelity, data quality or third-party participation was insufficient to support a reliable conclusion. |
A technically successful failover does not justify a “demonstrated within tolerance” result unless the bank also verifies the relevant customer payment outcomes and financial-integrity conditions.
#### **Detailed Design and Execution of an Integrated End-to-End Scenario Test**
To demonstrate how the individual tests should operate together, MBSB should conduct at least one integrated scenario that challenges multiple Sub-CBS processes and interconnected Critical Business Services.
##### **Recommended Integrated Exercise: ST-06B**
Scenario title: Ransomware Attack, Core Banking Disruption and Compromised Payment Recovery
Scenario objective: Determine whether MBSB can maintain or safely restore essential domestic payment services within its approved Impact Tolerance following a coordinated cyber incident affecting payment processing, transaction integrity and recovery arrangements.
Principal processes: CBS-2.8, CBS-2.10, CBS-2.12, CBS-2.15, CBS-2.17, CBS-2.18, CBS-2.22, CBS-2.23 and CBS-2.24.
Interconnected services: CBS-1 Customer Deposit and Account Access Services; CBS-3 Digital Banking Services; CBS-8
Customer Transaction Authentication and Authorisation Services; CBS-9 Customer Support and Assistance During Banking Disruptions.
Participants: Payment Operations, Core Banking Technology, Cybersecurity, ICT Risk, Finance Control, Operational Risk, BCM, Crisis Management, Customer Support, Compliance and relevant third-party representatives.
Testing approach: Controlled cyber incident simulation, transaction integrity testing, disaster recovery validation, crisis management exercise and end-to-end payment processing simulation.
##### **Illustrative Exercise Timeline**
This timeline is an exercise design, not a prediction of MBSB's actual recovery performance.
| Exercise Time | Scenario Inject | Expected Management or Operational Response | Evidence and Measurement |
| --- | --- | --- | --- |
| T+00 | Cybersecurity monitoring detects suspicious privileged activity and abnormal payment processing behaviour. | Investigate, classify and contain the incident; determine whether payment integrity is affected. | Detection logs, incident classification, containment decisions. |
| T+15 minutes | Account debit posting becomes inconsistent; digital payment failures increase. | Assess CBS-2 customer harm and activate appropriate incident escalation. | Failed-payment rate, customer-impact estimate, escalation timeline. |
| T+30 minutes | Ransomware indicators appear in a database-support environment; transaction journals cannot be fully trusted. | Restrict unsafe processing, preserve evidence and initiate trusted recovery assessment. | Cyber containment records, transaction integrity findings. |
| T+45 minutes | The designated recovery environment fails an integrity check. | Challenge recovery assumptions, evaluate alternatives and escalate material capability gaps. | Recovery validation results, decision logs, alternative capability assessment. |
| T+60 minutes | Payment backlogs increase and customer complaints rise; other CBSs are affected. | Prioritise essential payments, activate customer communications and assess tolerance consumption. | Queue depth, service throughput, affected-customer counts, communications records. |
| T+90 minutes | A partial recovery becomes available, but some transactions have uncertain completion states. | Reconciliation and transaction-state verification are required before releasing affected payments. | Reconciliation exceptions, transaction-state classification, restoration approvals. |
| T+120 minutes | The illustrative maximum material disruption duration is reached. | Determine whether any approved tolerance boundary has been breached and report the position accurately. | Impact Tolerance assessment, customer harm, management decisions. |
| T+150 minutes | A trusted processing environment is available; payment queues remain substantial. | Conduct controlled backlog release, monitor capacity and validate beneficiary outcomes. | Processing throughput, queue clearance, duplicate checks, payment completion records. |
| T+180 minutes | Processing stabilises; unresolved payment exceptions remain. | Establish the residual customer impact, outstanding exceptions and recovery completion criteria. | Exception register, financial control sign-offs, customer-impact report. |
##### **End-to-end Acceptance Criteria**
The integrated test should demonstrate whether:
- Cyber threats are detected and contained without allowing further compromise of payment data.
- Customer payment impacts are measured from the point of disruption.
- Essential payment capacity is maintained or safely restored within the approved tolerance.
- Transaction records are complete, accurate and independently reconcilable.
- Alternative arrangements do not rely on the same failed infrastructure without appropriate safeguards.
- Recovery does not introduce duplicate debits, missing credits or unauthorised payments.
- The backlog can be cleared without generating a second operational incident.
- Management recognises a tolerance breach when it occurs and takes appropriate action.
A failed result is valuable when it reveals a genuine weakness.
Testing aims to establish actual resilience capability, not to guarantee a favourable test report.
#### **Scenario Testing Governance and Documentation**
##### **Scenario Testing Lifecycle**
##### **Scenario Test Design Profile**
Each approved test should have a standard design record.
| Field | Required Documentation |
| --- | --- |
| Test identifier | Unique scenario test reference, such as ST-02C |
| Critical Business Service | CBS-2 Domestic Funds Transfer and Payment Services |
| Sub-CBS coverage | Relevant Sub-CBS codes and names |
| Scenario description | Severe but plausible event, disruption pathway and assumptions |
| Test objective | Measurable resilience capability to be validated |
| Impact Tolerance | Approved duration, capacity, customer-harm and integrity boundaries |
| Starting conditions | Business period, transaction volumes, technology state and operational resources |
| Test method | Simulation, technical test, tabletop, integrated exercise or other approved approach |
| Injects and timeline | Events, escalation triggers, decision points and planned complications |
| Participants | Business, technology, risk, cyber, crisis and third-party representatives |
| Test controls | Safety limits, production safeguards, stop criteria and rollback arrangements |
| Evidence requirements | System logs, payment outcomes, reconciliation, customer impact and decision records |
| Success criteria | Service-level results required to demonstrate resilience within tolerance |
| Approval | Authorised test sponsor, accountable owner and relevant control functions |
| Results | Actual observations, deviations, tolerance assessment and evidence limitations |
| Corrective actions | Owners, priorities, target dates and effectiveness verification |
| Reporting | Management and committee review, residual risk and retesting decisions |
##### **Evidence Hierarchy**
MBSB should distinguish between evidence that merely confirms a procedure exists and evidence that demonstrates operational capability.
| Evidence Level | Example | What It Demonstrates |
| --- | --- | --- |
| 1. Documented design | Approved continuity procedure or recovery architecture | Intended capability |
| 2. Control validation | Access review, configuration check or procedure walkthrough | Control design and selected implementation elements |
| 3. Functional exercise | Application failover, reconciliation or queue recovery test | Performance of a defined function |
| 4. Integrated scenario test | Multiple Sub-CBS processes operating under simultaneous disruption | Interdependent operational capability |
| 5. End-to-end service validation | Verified customer payment outcomes measured against Impact Tolerance | Demonstrated resilience of CBS-2 under the tested conditions |
Higher levels of evidence provide stronger support for resilience conclusions, although the quality and realism of each test remain important.
#### **Regulatory Considerations for Scenario Testing by a Malaysian Financial Services Institution**
##### **Regulatory Context**
BNM's Operational Resilience Discussion Paper, 19 December 2025 (BNM/RH/DP 028-25), discusses how financial institutions can strengthen the continuity of critical financial services amid increasing digitalisation, cyber threats, and operational interdependencies.
The document is a Discussion Paper, not itself a final operational resilience policy imposing all of the proposed practices as new binding requirements.
It also explains how existing BNM policy documents, including Business Continuity Management (BCM), Risk Management in Technology (RMiT), and Outsourcing, already set out relevant obligations.
##### **Relevant Regulatory Themes and Implementation Responses**
| BNM Reference | Discussion Paper Position | Recommended Application to MBSB |
| --- | --- | --- |
| Paragraphs 2.8–2.9 | BNM discusses Malaysian disruption experiences and identifies the limitations of isolated failure testing, including the need to consider concurrent scenarios. | Combine cyber, technology, operational and third-party failures in selected integrated CBS-2 exercises. |
| Paragraph 3.3(a) | Continuity of critical operations and services is identified as a foundational operational resilience capability. | Measure whether essential domestic payment outcomes remain available during severe disruption. |
| Paragraph 3.3(b) | Mapping internal and external interdependencies is identified as important for understanding failure propagation and concentration. | Use the CBS-2 dependency map to select test injects and challenge shared infrastructure. |
| Paragraph 3.3(c) | Third-party dependencies and viable contingency arrangements are highlighted. | Test external payment infrastructure, telecommunications and critical service provider responses. |
| Paragraph 3.3(d) | Tolerances for disruption should reflect acceptable harm, disruption duration and minimum service capability. | Measure actual service disruption, customer harm, payment throughput and integrity against approved limits. |
| Paragraph 3.3(e) | BNM discusses assessing capabilities under credible, severe scenarios that challenge assumptions and multilayered failures. | Design scenarios that can expose weaknesses rather than merely confirm existing recovery procedures. |
| Paragraph 3.4 | The Discussion Paper highlights board and senior management ownership of operational resilience. | Require senior management challenge, reporting and decisions on material test findings. |
| Paragraph 3.5 | Periodic reviews, updated testing and improvement are highlighted as part of operational resilience. | Retest after remediation and reassess scenarios when services, threats or dependencies change. |
| Paragraphs 4.3–4.5 | BNM describes existing BCM, RMiT and Outsourcing requirements relevant to continuity, technology and external dependencies. | Integrate existing compliance evidence with the CBS-2 scenario testing programme to avoid unnecessary duplicate testing. |
| Paragraphs 4.10–4.12 | BNM discusses the possible evolution of a more explicit operational resilience framework. | Maintain an adaptable programme and review subsequent final regulatory developments before making formal compliance assertions. |
The December 2025 paper documents the foundational themes and discussion of existing policy requirements.
##### **Explicit BNM Examples Versus MBSB Implementation Recommendations**
The Discussion Paper expressly refers to incidents involving technology migration failures, payment and settlement infrastructure disruption, major power outages, ransomware, core banking failures and unsuccessful disaster recovery activity.
These examples support selecting the corresponding scenario categories.
However, the specific ST-01 to ST-06 programme, the 24 individual test designs, their acceptance criteria and the illustrative two-hour, 50% and 10% thresholds are recommendations developed for this MBSB implementation guide.
They are not presented as prescribed BNM requirements.
For formal supervisory review, MBSB should document which requirements arise from applicable final BNM policy documents, which expectations are discussed in the December 2025 paper, and which measures represent the bank's own approved resilience methodology.
##### **Preparing Evidence for Supervisory Review**
A supervisory-ready Scenario Testing Programme should allow a reviewer to trace:
The documentation should establish not only that testing occurred, but also that its scope was appropriate, its findings were credible, and its results influenced operational resilience decisions.
#### **Scenario Testing Programme, Remediation and Continuous Improvement**
##### **Recommended Risk-based Testing Schedule**
The following is an illustrative first-year programme.
Adjust it to MBSB's risk profile, available resources, material changes, and existing testing commitments.
| Implementation Period | Recommended Activities | Expected Deliverables |
| --- | --- | --- |
| Quarter 1 | Confirm CBS-2 scope, approve Impact Tolerance, validate dependencies, establish test governance and design ST-01. | Approved scenario inventory, test methodology, participant register and test design profiles. |
| Quarter 2 | Execute ST-01 and ST-02, including customer authentication, payment processing, ledger integrity and network resilience tests. | Test results, tolerance assessments, vulnerability register and initial remediation plans. |
| Quarter 3 | Execute ST-03, ST-04 and ST-05, focusing on external payment infrastructure, settlement, reconciliation, customer communications and escalation. | Integrated exercise reports, third-party observations, financial-integrity findings and management reporting. |
| Quarter 4 | Execute ST-06, including a major end-to-end continuity and cyber recovery exercise; retest selected material weaknesses. | Consolidated resilience assessment, remediation effectiveness evidence, residual risk report and next-year testing priorities. |
A full-scale test of every scenario is not necessarily required in the first year.
The programme should provide proportionate coverage of all 24 Sub-CBS processes, with deeper testing concentrated on the highest-risk dependencies and potentially severe customer outcomes.
##### **Remediation and Lessons Identified**
Following each exercise, MBSB should conduct a structured after-action review.
Findings should be evaluated according to their effect on CBS-2's ability to remain within Impact Tolerance.
| Finding Category | Example | Recommended Management Response |
| --- | --- | --- |
| Critical | Transaction integrity cannot be established after recovery, creating material financial harm. | Immediate escalation, containment, accountable remediation and formal risk governance review. |
| High | Essential payment capacity cannot be maintained during a credible external network failure. | Prioritised resilience investment, interim safeguards and time-bound retesting. |
| Medium | Incident escalation is delayed, but tested service outcomes remain within tolerance. | Improve escalation triggers, responsibilities and monitoring; validate through a targeted exercise. |
| Low | Exercise documentation or participant coordination requires improvement without material service impact. | Update procedures and training; verify at the next appropriate test. |
Severity should be determined using MBSB's approved risk assessment criteria, not solely the example classifications above.
Every material finding should have an accountable owner, agreed action, target completion date, evidence requirements and effectiveness verification.
##### **Management Reporting**
Senior Management and the relevant Board committee should receive a consolidated view of the programme that distinguishes:
- Scenarios designed and approved.
- Scenarios executed and the quality of testing evidence.
- CBS-2 capabilities demonstrated within Impact Tolerance.
- Tests resulting in breaches or inconclusive findings.
- Material interdependency and concentration weaknesses.
- Outstanding remediation actions and overdue items.
- Residual risks require management decisions.
- Retesting results and changes in demonstrated resilience capability.
The report should clearly differentiate planned recovery capability, tested recovery capability and demonstrated end-to-end service resilience.
[![Banner \[Summing\] \[OR\] \[E3\] Perform Scenario Testing](https://no-cache.hubspot.com/cta/default/3893111/11895c06-91e9-4cec-acb6-4356741952e4.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/11895c06-91e9-4cec-acb6-4356741952e4)
Scenario Testing is essential to validating whether CBS-2: Domestic Funds Transfer and Payment Services can withstand Severe but Plausible Scenarios while remaining within MBSB's approved Impact Tolerance.
The recommended programme covers all 24 Sub-CBS processes and connects individual tests through six integrated exercises.
This approach enables MBSB to assess the complete payment lifecycle, from customer initiation and authorisation to transaction processing, interbank settlement, reconciliation, continuity and controlled restoration.
Using severe but Plausible Scenarios as the basis for testing ensures exercises challenge credible operational weaknesses rather than merely confirming that established procedures can be followed.
The Impact Tolerance provides the service-level boundary against which customer harm, processing capacity, disruption duration, transaction integrity and recovery effectiveness can be evaluated.
Integrating Cyber and ICT Risks strengthens the programme by examining how cyberattacks, compromised data, technology concentration, network outages, failed changes and third-party failures propagate across interconnected processes and Critical Business Services.
Auditable testing evidence, management decisions, and verified proactive risk-management actions are necessary to demonstrate resilience preparedness.
Where testing reveals weaknesses, MBSB should translate the findings into lessons identified, accountable remediation, targeted resilience investment and subsequent retesting.
Ultimately, Scenario Testing is not simply to demonstrate that systems and processes can recover.
It is to establish whether MBSB can continue delivering essential domestic payment outcomes, or restore them safely, before operational disruption causes unacceptable harm.
#### **Methodological References**
The chapter also draws conceptually on the following BCM Institute publications:
- [Understanding Scenario Testing in Operational Resilience](https://blog.bcm-institute.org/operational-resilience/understanding-scenario-testing-in-operational-resilience)
- [What is Scenario Testing in Operational Resilience?](https://blog.bcm-institute.org/operational-resilience/or-p2-s4-what-is-scenario-testing-in-operational-resilience)
- [Introduction to Scenario Testing](https://blog.bcm-institute.org/ebook-or/or-p2-s4-st-c1-introduction-to-scenario-testing)
Implementation status from Author: This chapter provides a proposed scenario testing framework. It does not represent testing already performed by MBSB. All process assumptions, tolerance thresholds, testing arrangements and expected outcomes require validation and approval before formal implementation or regulatory submission.
[![\[OR\] \[MBSB\] \[3/4 Banner\] Operational Resilience in Action The MBSB Bank's Approach ](https://no-cache.hubspot.com/cta/default/3893111/8c32162b-ac29-4c9c-9413-3d8869a65490.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/8c32162b-ac29-4c9c-9413-3d8869a65490)
| **eBook 3: Starting Your OR Implementation** | | | | |
| --- | --- | --- | --- | --- |
| **CBS-2 Domestic Funds Transfer and Payment Services** | | | | |
| **CBS-2 DP** | **CBS-2 MII** | **CBS-2 ITo** | **CBS-2 SbPS** | **CBS-2 ST** |
| [![\[OR\] \[MBSB\] \[E3\] \[CBS\] \[2\] \[DP\] Domestic Funds Transfer and Payment Services](https://no-cache.hubspot.com/cta/default/3893111/6061bf66-5bbb-4d60-bf93-b90415e0c94c.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/6061bf66-5bbb-4d60-bf93-b90415e0c94c) | [![\[OR\] \[MBSB\] \[E3\] \[CBS\] \[2\] \[MII\] Domestic Funds Transfer and Payment Services](https://no-cache.hubspot.com/cta/default/3893111/44087c85-3c98-4d94-997a-4891ee09baff.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/44087c85-3c98-4d94-997a-4891ee09baff) | [![\[OR\] \[MBSB\] \[E3\] \[CBS\] \[2\] \[ITo\] Domestic Funds Transfer and Payment Services](https://no-cache.hubspot.com/cta/default/3893111/e124bae1-4ad4-4c27-8400-1fe1d67fbea9.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/e124bae1-4ad4-4c27-8400-1fe1d67fbea9) | [![\[OR\] \[MBSB\] \[E3\] \[CBS\] \[2\] \[SbPS\] Domestic Funds Transfer and Payment Services](https://no-cache.hubspot.com/cta/default/3893111/9ec97fec-0ab6-45a6-bbbe-f76f4303ad2f.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/9ec97fec-0ab6-45a6-bbbe-f76f4303ad2f) | [![\[OR\] \[MBSB\] \[E3\] \[CBS\] \[2\] \[ST\] Domestic Funds Transfer and Payment Services](https://no-cache.hubspot.com/cta/default/3893111/bd69c69a-27ca-4958-b8ed-88616906ad6f.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/bd69c69a-27ca-4958-b8ed-88616906ad6f) |
**[](https://cta-redirect.hubspot.com/cta/redirect/3893111/084e620a-46c5-419a-82ed-6a681d15c0b6)[](https://cta-redirect.hubspot.com/cta/redirect/3893111/13a448f1-f09c-42da-a57e-0988e41658c5)**
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.
#### More Information About OR-5000 \[OR-5\] or OR-300 \[OR-3\]
To learn more about the course and schedule, click the buttons below for the OR-300 Operational Resilience Implementer course and the OR-5000 Operational Resilience Expert Implementer course.
| [](https://cta-redirect.hubspot.com/cta/redirect/3893111/3530eccb-515d-401e-afc2-3469e26d7fbf) | [](https://cta-redirect.hubspot.com/cta/redirect/3893111/fdd4fa9c-ed69-40c1-925f-4eb6a1c5c255) | [](https://cta-redirect.hubspot.com/cta/redirect/3893111/77a34b84-0a6d-44f8-b8d6-6ab04cdf5edd) |
| --- | --- | --- |
| [](https://cta-redirect.hubspot.com/cta/redirect/3893111/6e5c0cda-39b9-4bbd-b3d4-4cf46a790b14) | [](https://cta-redirect.hubspot.com/cta/redirect/3893111/a68a08aa-36d3-4216-9551-202c9fde06ea) | [![ \[BL-OR\] \[3-4-5\] View Schedule](https://no-cache.hubspot.com/cta/default/3893111/d0d733a1-16c0-4b68-a26d-adbfd4fc6069.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/d0d733a1-16c0-4b68-a26d-adbfd4fc6069) |
| [![\[BL-OR\] \[3\] FAQ OR-300](https://no-cache.hubspot.com/cta/default/3893111/f20c71b4-f5e8-4aa5-8056-c374ca33a091.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/f20c71b4-f5e8-4aa5-8056-c374ca33a091) | If you have any questions, click to contact us.[![Email to Sales Team \[BCM Institute\]](https://no-cache.hubspot.com/cta/default/3893111/3c53daeb-2836-4843-b0e0-645baee2ab9e.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/3c53daeb-2836-4843-b0e0-645baee2ab9e) | [](https://cta-redirect.hubspot.com/cta/redirect/3893111/7f2718a4-ea80-4f84-a319-dc2d4df37a46) |
| [](https://cta-redirect.hubspot.com/cta/redirect/3893111/74b1e556-8cd2-4a74-8821-db1804534955) | [](https://cta-redirect.hubspot.com/cta/redirect/3893111/f2bd8eb1-32d2-4732-9267-ea53223cf58f) | [](https://cta-redirect.hubspot.com/cta/redirect/3893111/084e620a-46c5-419a-82ed-6a681d15c0b6) |
#### **Your Comments Here:**
---
---
---
---
All rights reserved. Copyright 2026
```json
{
"@context" : "https://schema.org",
"@type" : "BlogPosting",
"author" : {
"@type" : "Person",
"name" : "Dr Goh Moh Heng",
"url" : "https://blog.bcm-institute.org/ebook-or/author/dr-goh-moh-heng"
},
"dateModified" : "2026-10-14T14:10:09.300Z",
"datePublished" : "2026-10-14T04:12:58.000Z",
"headline" : "[OR] [MBSB] [E3] [CBS] [2] [ST] Perform Scenario Testing",
"mainEntityOfPage" : {
"@id" : "https://blog.bcm-institute.org/ebook-or/or-mbsb-e3-cbs-2-st-perform-scenario-testing",
"@type" : "WebPage"
},
"publisher" : {
"@type" : "Organization",
"logo" : {
"@type" : "ImageObject",
"url" : "https://blog.bcm-institute.org/hubfs/BCMI%20Logo.png"
},
"name" : "BCMI Pte Ltd"
}
}
```