CBS-3 Digital Banking Services
Introduction
Scenario Testing is a fundamental component of Operational Resilience because it enables MBSB to determine whether its people, processes, technology, information, facilities and external service providers can collectively sustain CBS-3 Digital Banking Services during severe operational disruption.
The objective is not simply to establish whether an individual application, disaster recovery arrangement or business continuity plan functions as intended.
It is to demonstrate whether customers can continue receiving essential digital banking services safely, accurately and within an acceptable level of harm.
The Severe but Plausible Scenarios identified in the preceding chapter provide the foundation for the Scenario Testing Programme.
Each scenario introduces credible disruptive conditions that challenge the delivery of one or more Sub-CBS processes, including their interconnections with other Critical Business Services.
The approved Impact Tolerance provides the boundary against which the resulting disruption must be assessed.
Cyber and ICT Risks must be integrated throughout the testing programme because cyberattacks, technology failures, compromised data, failed system changes, network outages and shared infrastructure dependencies can initiate, amplify or prolong disruptions.
Testing must therefore examine how business operations, cybersecurity response, technology recovery, customer assistance and crisis management work together to protect essential banking outcomes.
This chapter presents a practical testing programme covering all 24 Sub-CBS processes, with recommended testing methods, disruption injects, dependency challenges, expected resilience outcomes, auditable evidence and proactive risk management actions.
Implementation qualification from the author: The testing programme is illustrative. It does not imply that MBSB currently operates the specific architectures, systems, controls or recovery arrangements described. All scenarios, participants, dependencies and success criteria require validation against MBSB's actual operating environment.
Scenario Testing Framework and Assessment Criteria
Purpose of Scenario Testing
For CBS-3, Scenario Testing should establish whether MBSB can maintain essential customer outcomes despite the failure or degradation of critical supporting capabilities.
The programme should answer five fundamental questions:
- Can customers continue to access essential digital banking services during severe disruption?
- Can MBSB protect customer funds, authentication controls and transaction integrity?
- Can operational teams detect, assess, escalate and coordinate a response before unacceptable harm occurs?
- Can alternative arrangements and recovery capabilities restore essential customer outcomes within the approved Impact Tolerance?
- Can MBSB demonstrate these capabilities through reliable testing evidence and management oversight?
A successful test must demonstrate the required customer and service outcomes, not merely completion of predefined technical recovery steps.
Impact Tolerance Used for Scenario Design
The preceding CBS-3 assessment proposed the following illustrative Impact Tolerance parameters.
|
Impact Tolerance Dimension |
Illustrative Assessment Parameter |
Scenario Testing Application |
|
Maximum material disruption duration |
2 consecutive hours without an effective alternative |
Measure elapsed time from material customer service degradation to verified restoration of essential capability. |
|
Affected customer boundary |
20% of active digital banking customers unable to complete essential journeys |
Estimate the proportion of affected customers using representative customer cohorts and demand data. |
|
Minimum essential journey completion |
80% of legitimate attempted essential journeys |
Measure successful end-to-end completion, not merely application availability or request acceptance. |
|
Material financial data integrity compromise |
No tolerance for uncontrolled unauthorised transactions or materially incorrect authoritative financial outcomes |
Test containment, reconciliation, authorisation integrity and safe restoration. |
|
Additional customer harm |
Urgent financial needs, vulnerable customers, critical payment obligations and unavailable alternatives |
Assess whether unacceptable harm could arise even when quantitative thresholds have not been crossed. |
These figures are illustrative implementation assumptions, not approved MBSB limits or BNM-prescribed requirements. The actual Scenario Testing Programme must use MBSB's formally approved tolerance and associated measurement rules.
Do not interpret the numerical boundaries as permission to allow customer harm.
For example, a material transaction integrity failure may require immediate containment even if the disruption has lasted only a few minutes.
Scenario Testing methods
MBSB should use different testing methods based on the nature of the risk, the maturity of the capability being tested, and the consequences of test execution.
|
Testing Method |
Primary Application |
Important Limitation |
|
Desktop review and walkthrough |
Validate process completeness, roles, dependencies and decision pathways. |
Cannot demonstrate actual recovery or transaction processing capability. |
|
Tabletop exercise |
Challenge management decisions, escalation, prioritisation and coordination. |
Outcomes depend on assumptions unless supported by technical evidence. |
|
Cyber incident simulation |
Test detection, investigation, containment, security decisions and recovery coordination. |
Must be linked to business service outcomes rather than security activity alone. |
|
API and network resilience test |
Test interface failure, latency, routing, queue recovery and connectivity alternatives. |
Technical results must be translated into customer journey impacts. |
|
Capacity and stress test |
Test peak demand, transaction-processing capacity, and customer support surge capability. |
Load profiles must represent realistic severe conditions. |
|
Data integrity and reconciliation test |
Test authoritative data, transaction states, duplication prevention and recovery accuracy. |
A technically successful restore may still contain incorrect financial information. |
|
Failover and disaster recovery test |
Demonstrate recovery arrangements and infrastructure resilience. |
Infrastructure restoration does not automatically establish CBS restoration. |
|
Third-party disruption exercise |
Test external provider failures, substitution and communication. |
Challenge provider assurances with evidence and joint testing where feasible. |
|
Integrated business and technology simulation |
Test multiple Sub-CBS processes and interdependent business functions together. |
Requires strong coordination, controlled injects and objective evidence collection. |
|
End-to-end CBS scenario test |
Assess whether essential customer outcomes remain within Impact Tolerance under combined failures. |
Requires reliable customer journey measurements and clearly defined success criteria. |
Live production exercises should be undertaken only where formally authorised, risk assessed, adequately safeguarded and supported by rollback arrangements.
Simulate potentially destructive cyber events in controlled environments.
Testing Programme Design Principles
Every test should have an approved scenario profile defining the starting conditions, initiating event, affected customer journeys, participating functions, dependencies, test timeline, injects, decision points, Impact Tolerance measures and evidence requirements.
MBSB should also identify a test controller, facilitators, technical and business observers, an evidence custodian, an accountable CBS Owner and a designated authority to stop the test if safety, security or production integrity is threatened.
The test design should deliberately challenge assumptions.
For example, an authentication failover test should not assume the standby service is immediately available, the recovery team is fully staffed, or all customer identity records remain trustworthy.
Recommended Scenario Testing for All 24 Sub-CBS Processes
The following table converts the previously identified Severe but Plausible Scenarios into executable testing recommendations.
The tests are designed as components of an integrated CBS-3 programme. They should not be treated as 24 unrelated exercises.
Severe but Plausible Scenarios, Testing Methods and Dependency Challenges
Table P6: Perform Scenario Testing for CBS-3
|
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-3.1 |
Digital Banking Customer Registration and Enrolment |
Compromised identity verification service during a surge in customer enrolment. |
ST-01A: Secure Enrolment Continuity Test |
Third-party disruption exercise combined with controlled API failure simulation and operational walkthrough. Tests both provider dependency and manual exception capability. |
Demonstrate that legitimate customer enrolment can resume securely, with accurate identity decisions and controlled backlogs, without weakening fraud prevention. |
Verification provider returns inconsistent decisions; enrolment requests increase sharply; provider recovery estimate is uncertain; exception-handling capacity is reduced. |
Identity verification provider; onboarding workflows; customer records; fraud operations; customer support; CBS-1 account access. |
|
CBS-3.2 |
Digital Banking Access Activation and Maintenance |
Mass customer access lockout following an erroneous identity policy deployment. |
ST-01B: Mass Access Restoration Test |
Controlled configuration rollback and access restoration simulation with customer service capacity testing. Demonstrates more than a policy walkthrough. |
Measure how quickly legitimate customers regain secure access while compromised or restricted accounts remain protected. |
Device registrations become invalid; automated rollback fails; reactivation requests surge; privileged administrators are unavailable. |
Identity and Access Management; device registration; CBS-8; customer support; access administration; digital channels. |
|
CBS-3.3 |
Digital Banking Channel Access and Service Availability |
Coordinated DDoS attack during peak digital banking demand. |
ST-01C: Multi-Channel DDoS Resilience Test |
Controlled DDoS simulation, capacity stress test, network failover test and end-to-end customer journey monitoring. |
Verify that essential digital banking journeys remain available or recover within the approved Impact Tolerance during sustained hostile traffic. |
Attack traffic increases; mitigation capacity degrades; a network route fails; legitimate traffic rises; mobile and internet channels share a constrained dependency. |
Internet connectivity; DDoS mitigation; application infrastructure; API gateways; hosting; CBS-1 and CBS-2. |
|
CBS-3.4 |
Digital Customer Authentication and Identity Verification |
Shared authentication platform compromise and emergency shutdown. |
ST-01D: Shared Authentication Compromise Test |
Cyber incident simulation integrated with controlled authentication failover and cross-CBS business testing. |
Demonstrate secure authentication continuity or restoration while preventing unauthorised access and identifying impacts on interconnected CBSs. |
Privileged account compromise detected; primary authentication isolated; standby identity data requires validation; payment authorisation demand continues. |
Shared identity services; CBS-8; CBS-3.5; CBS-3.12; security operations; payment channels. |
|
CBS-3.5 |
Digital Session Establishment and Management |
Session infrastructure failure causing interrupted and potentially duplicated customer transactions. |
ST-01E: Session Failure and Safe Retry Test |
Application resilience test, session failover simulation and end-to-end transaction replay validation. |
Confirm that session disruption does not produce duplicate instructions, unauthorised continuation or unresolved transaction states. |
Session tokens expire unexpectedly; session-state replication lags; customers retry payments; some acknowledgements are delayed. |
Authentication; session stores; digital applications; CBS-3.11; CBS-3.15; payment interfaces. |
|
CBS-3.6 |
Digital Access Security and Customer Account Protection |
Coordinated account takeover attack during security-control degradation. |
ST-01F: Account Takeover Containment Test |
Threat-led cyber simulation combined with fraud operations exercise and controlled account restriction testing. |
Verify rapid detection, containment and safe restoration of affected accounts without uncontrolled unauthorised financial activity. |
Stolen credentials used; fraud alerts delayed; account restriction interface fails; customer contact information is unreliable. |
Fraud monitoring; identity controls; CBS-8; customer records; account restriction services; customer assistance. |
|
CBS-3.7 |
Digital Account Information Retrieval and Presentation |
Corrupted account balance information following core banking data synchronisation failure. |
ST-02A: Account Data Integrity and Customer Journey Test |
Controlled data corruption simulation, reconciliation test and customer journey validation. |
Verify that materially incorrect balances are detected, suppressed or corrected before customers rely on them for essential transactions. |
Replication lag increases; balances differ across channels; cache invalidation fails; payment attempts are initiated using stale information. |
Core banking; account information APIs; CBS-1; CBS-3.11; data management; customer channels. |
|
CBS-3.8 |
Digital Transaction History and Statement Services |
Ransomware affecting transaction history and statement repositories. |
ST-02B: Trusted Financial Records Recovery Test |
Cyber recovery simulation, protected backup restoration and records integrity testing. |
Demonstrate that essential financial records can be recovered accurately and urgent customer evidence requests can continue. |
Historical records encrypted; recent backups fail integrity checks; urgent disputes increase; document delivery service is unavailable. |
Transaction repositories; document storage; CBS-1/CBS-2; records management; customer service; backup infrastructure. |
|
CBS-3.9 |
Digital Customer Profile and Banking Preference Management |
Unauthorised customer contact changes through a compromised profile management interface. |
ST-02C: Customer Profile Integrity and Fraud Propagation Test |
API security simulation, data integrity test, and coordinated fraud-response exercise. |
Verify detection and reversal of unauthorised profile changes before security alerts are diverted or further account compromise occurs. |
Contact details altered; confirmation messages routed incorrectly; fraud monitoring detects anomalies; profile restoration produces conflicting records. |
Customer master data; identity controls; messaging services; fraud operations; CBS-8. |
|
CBS-3.10 |
Digital Banking Service Request Management |
Loss of service request processing during simultaneous system and staffing disruption. |
ST-02D: Urgent Service Request Continuity Test |
Integrated business continuity simulation, workflow recovery test and workforce capacity exercise. |
Demonstrate that urgent customer requests can be prioritised, processed and reconciled despite workflow failure and reduced specialist staffing. |
Workflow queue unavailable; operational facility inaccessible; specialist staffing reduced; urgent service requests accumulate. |
Customer service; workflow systems; facilities; CBS-1; CBS-5; specialist processing teams. |
|
CBS-3.11 |
Digital Financial Transaction Initiation |
Transaction initiation overload with uncertain submission outcomes. |
ST-03A: Peak-Demand Transaction Initiation Stress Test |
Capacity and stress test integrated with API resilience and transaction integrity testing. |
Verify essential transaction initiation capacity and safe retry handling under severe load and partial interface failure. |
Demand surges; API response times increase; submission acknowledgements time out; repeated customer attempts occur. |
Digital channels; authentication; payment initiation APIs; CBS-2; CBS-3.12; CBS-3.15. |
|
CBS-3.12 |
Digital Transaction Validation and Authorisation Coordination |
Compromised transaction authorisation rules during a major payment processing period. |
ST-03B: Transaction Authorisation Integrity Test |
Cyber incident simulation, controlled rule-change testing and payment journey validation. |
Demonstrate that unauthorised approvals are prevented, compromised rules are contained and legitimate payment authorisation can be safely restored. |
Authorisation rule altered; suspicious approvals increase; rollback requires additional validation; legitimate transactions are rejected. |
CBS-8; fraud controls; payment processing; privileged administration; CBS-2; digital channels. |
|
CBS-3.13 |
Digital Payment and Funds Transfer Processing Coordination |
Payment interface disruption with message duplication and delayed acknowledgements. |
ST-03C: Payment Interface Failure and Reconciliation Test |
API and network resilience test, queue recovery simulation and end-to-end payment reconciliation. |
Verify that authorised payment instructions are neither lost nor duplicated and that reliable outcomes are established despite interface disruption. |
Network route fails; payment messages queue; retry processing generates duplicate attempts; acknowledgements arrive out of sequence. |
CBS-2; payment interfaces; telecommunications; message queues; transaction reconciliation; external payment connectivity. |
|
CBS-3.14 |
Digital Financing and Account Servicing Transactions |
Financing servicing failure during a critical repayment period. |
ST-02E: Financing Repayment Continuity Test |
Integrated business and technology simulation with database recovery and alternative servicing exercise. |
Verify accurate and timely handling of urgent financing repayments despite corrupted servicing data and constrained operational capacity. |
Financing database unavailable; repayment deadline approaches; alternative processing capacity is limited; reconciliation exceptions arise. |
CBS-5; financing records; core banking; CBS-2; servicing specialists; customer support. |
|
CBS-3.15 |
Digital Transaction Status and Completion Management |
Incorrect payment completion status caused by event messaging and clock synchronisation failure. |
ST-03D: Transaction Status Integrity and Duplicate Prevention Test |
Data integrity and reconciliation test with controlled time synchronisation and event-ordering faults. |
Demonstrate that customer-facing payment status matches authoritative records and prevents duplicate transactions. |
Timestamps diverge; payment acknowledgements arrive out of order; completed payments display as pending; customers retry transactions. |
Payment processing; event messaging; time services; CBS-2; CBS-3.11–3.13; customer channels. |
|
CBS-3.16 |
Digital Banking Customer Notification and Alert Management |
Critical messaging provider outage during widespread suspicious account activity. |
ST-04A: Critical Customer Alert Continuity Test |
Third-party disruption exercise with alternative notification-channel simulation and fraud-response testing. |
Verify that customers receive essential security and transaction communications through secure alternative routes during provider failure. |
Messaging provider unavailable; suspicious transactions increase; contact details are incomplete; alternate route capacity is constrained. |
Messaging providers; telecommunications; fraud operations; customer profiles; CBS-8; CBS-9. |
|
CBS-3.17 |
Digital Banking Customer Enquiry and Assistance Management |
Customer support capacity collapse during a simultaneous digital banking outage. |
ST-04B: Customer Assistance Surge and Channel Continuity Test |
Contact centre capacity stress test, business continuity exercise and cross-CBS customer assistance simulation. |
Demonstrate that urgent customer needs are addressed when digital banking and primary support channels are simultaneously degraded. |
Call volumes surge; contact centre connectivity fails; staffing falls; branches receive increased urgent requests. |
Contact centres; telecommunications; branches; customer records; CBS-9; incident communications. |
|
CBS-3.18 |
Digital Banking Complaint and Service Issue Resolution |
Loss of investigation records during a surge in disputed digital transactions. |
ST-04C: Financial Dispute and Evidence Recovery Test |
Records recovery test combined with operational dispute resolution simulation. |
Verify that urgent financial disputes can be investigated and prioritised using trustworthy evidence despite case system disruption. |
Case records inaccessible; disputed transactions increase; evidence is incomplete; investigation specialists are overloaded. |
Complaint systems; transaction records; compliance; payment operations; CBS-9; investigation teams. |
|
CBS-3.19 |
Digital Banking Service Performance and Availability Monitoring |
Monitoring blind spot during progressive customer journey degradation. |
ST-05A: Customer Journey Detection and Monitoring Failure Test |
Controlled monitoring fault injection, synthetic transaction testing and incident detection simulation. |
Measure whether the system detects and escalates material customer-facing degradation before it approaches approved tolerance boundaries. |
Monitoring alerts suppressed; infrastructure appears healthy; synthetic journeys fail; customer complaints increase. |
Monitoring platforms; digital applications; service desk; incident management; CBS Owners. |
|
CBS-3.20 |
Digital Banking Security Event Detection and Response Coordination |
Coordinated ransomware attack with compromised security monitoring. |
ST-05B: Coordinated Cyberattack and Service Continuity Test |
Threat-led cyber incident simulation integrated with business continuity, crisis management and clean recovery testing. |
Demonstrate coordinated containment, trusted recovery and preservation of essential customer outcomes during a multi-system cyberattack. |
Privileged compromise; security logs tampered with; ransomware spreads; shared services isolated; recovery data integrity questioned. |
Security operations; identity; infrastructure; core banking; CBS-3.21–3.24; interconnected CBSs. |
|
CBS-3.21 |
Digital Banking Incident Assessment and Service Escalation |
Delayed crisis escalation caused by incomplete cross-service impact information. |
ST-05C: Cross-CBS Crisis Escalation and Decision Test |
Crisis management exercise using timed injects, incomplete information and multi-function decision simulation. |
Verify timely recognition of interconnected disruption, accurate customer-harm assessment and escalation before Impact Tolerance breach. |
Conflicting incident reports; authentication and payment failures escalate; communication channels degrade; decision authority is unavailable. |
Incident management; crisis management; CBS-1/CBS-2/CBS-8 owners; technology operations; customer service. |
|
CBS-3.22 |
Digital Banking Continuity and Alternative Service Delivery |
Regional flooding disables digital operations and overwhelms alternative banking channels. |
ST-06A: Multi-Channel Continuity Under Regional Disruption |
Integrated business continuity and crisis simulation with facility, telecommunications and alternative-channel capacity testing. |
Demonstrate continued essential customer service when digital channels, facilities and alternative delivery arrangements face simultaneous disruption. |
Flooding affects facilities; power and telecommunications degrade; staff cannot reach sites; alternative channels reach capacity. |
Branches; contact centres; utilities; telecommunications; core banking; CBS-1; CBS-9; workforce arrangements. |
|
CBS-3.23 |
Digital Banking Technology Recovery and Service Reinstatement |
Simultaneous primary and recovery environment failure following destructive cyber compromise. |
ST-06B: Dual-Site Failure and Clean Digital Banking Recovery Test |
Controlled disaster recovery and cyber recovery test, with independent backup restoration and cross-CBS validation. |
Demonstrate recovery of trusted essential digital banking capability when primary and normal recovery arrangements are simultaneously unavailable. |
Production environment compromised; recovery replication untrusted; privileged recovery credentials restricted; shared network unavailable. |
Primary and recovery infrastructure; backups; identity services; networks; digital applications; CBS-1/CBS-2/CBS-8. |
|
CBS-3.24 |
Digital Banking Service Restoration and Post-Incident Validation |
Premature digital banking restoration with unresolved transaction integrity defects. |
ST-06C: Safe Restoration and Business Acceptance Test |
End-to-end CBS simulation with transaction reconciliation, security clearance, business acceptance and rollback testing. |
Verify that unrestricted digital banking restoration occurs only after essential customer journeys, financial data and security controls are validated. |
Technology declared recovered; balances inconsistent; payment statuses unresolved; management pressured to reopen; defects recur. |
Digital channels; core banking; payment processing; cybersecurity; business owners; CBS-1/CBS-2; customer support. |
Interpretation of the Testing Recommendations
Table 1 shows why testing methods should vary by failure mechanism and resilience objective.
For example, CBS-3.3 requires network and capacity testing because a DDoS attack primarily threatens digital service availability.
CBS-3.7 requires authoritative data reconciliation because the principal risk is incorrect customer information.
CBS-3.21 requires crisis management testing because the key weakness being challenged is delayed cross-service decision-making.
However, these tests should ultimately be connected through common customer journeys and integrated scenarios.
A technically successful authentication failover, for example, does not establish CBS-3 resilience if customers subsequently cannot initiate payments, receive accurate transaction status or obtain assistance.
The appropriate measure of success is whether MBSB can continue providing essential customer outcomes within its approved Impact Tolerance.
Cyber and ICT Risk Integration, Impact Tolerance Validation and Proactive Risk Management
Table 2 establishes the evidence and control requirements associated with each test.
It distinguishes between evidence collected during scenario execution and evidence later required to show that identified improvements have been implemented.
The proposed outcomes are success criteria, not predictions of MBSB's existing capability.
Table: Impact Tolerance, Resilience Outcomes and Evidence Requirements
|
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-3.1 |
Digital Banking Customer Registration and Enrolment |
Identity verification API compromise is the trigger; provider unavailability and processing surge amplify disruption. |
Customer access delay; proportion unable to activate essential services; integrity of identity decisions. |
Unverified registrations remain blocked; legitimate customers can be securely enrolled through validated recovery or contingency procedures. |
API error and latency logs; identity decision samples; enrolment backlog; provider response records; customer activation times. |
Establish provider failover or secure contingency verification, fraud-screening controls and surge processing capacity. |
Approved third-party assessment; contingency procedure; provider test results; fraud-control testing; corrective-action closure. |
|
CBS-3.2 |
Digital Banking Access Activation and Maintenance |
Failed identity policy deployment causes mass lockouts; administrative platform concentration delays rollback. |
Affected customer boundary: 20%; material access disruption duration: two hours. |
Legitimate customers regain secure access within approved limits without uncontrolled access overrides. |
Lockout counts; reactivation times; change and rollback logs; customer support queue measurements. |
Introduce staged access-policy changes, tested rollback, independent privileged recovery and secure bulk reactivation. |
Change-control evidence; rollback test report; privileged access review; access recovery exercise. |
|
CBS-3.3 |
Digital Banking Channel Access and Service Availability |
DDoS triggers channel overload; network routing and hosting concentration amplify the outage. |
Two-hour duration; 20% affected customers; 80% essential journey completion. |
Essential journeys remain available through resilient infrastructure or recover before approved boundaries are breached. |
Synthetic journey results; DDoS telemetry; channel success rates; customer-impact estimates; failover timestamps. |
Strengthen DDoS mitigation, network diversity, application redundancy and peak-demand capacity. |
Capacity test; DDoS exercise; network failover results; architecture review; remediation verification. |
|
CBS-3.4 |
Digital Customer Authentication and Identity Verification |
Privileged compromise triggers isolation of shared authentication; identity-data trust issues prolong recovery. |
Customer access and journey completion; immediate integrity concern over unauthorised access. |
Restore authentication using trusted controls, contain compromised identities, and understand cross-CBS effects. |
Authentication success rates; access logs; cyber alerts; isolation and failover timestamps; identity validation results. |
Segregate identity administration, protect recovery credentials and validate independent authentication recovery. |
Privileged access assessment; authentication recovery test; cyber simulation; identity integrity review. |
|
CBS-3.5 |
Digital Session Establishment and Management |
Failed deployment causes session-state inconsistency; retries amplify transaction duplication risk. |
Essential journey completion of 80%; no material transaction integrity compromise. |
Sessions recover or terminate safely, and interrupted transactions are not duplicated or incorrectly completed. |
Session error rates; retry records; transaction references; duplicate detection results; recovery timings. |
Implement resilient session storage, safe token invalidation, idempotent submission and deployment rollback. |
Session failover report; duplicate prevention testing; secure token assessment; change-control closure. |
|
CBS-3.6 |
Digital Access Security and Customer Account Protection |
Credential attacks trigger account takeover attempts; degraded fraud controls delay protective action. |
Immediate integrity boundary for unauthorised transactions; effectiveness of customer protection. |
Detect and restrict compromised accounts promptly without exposing customer funds or unnecessarily disabling legitimate customers. |
Fraud alerts; account restriction timestamps; attempted transaction outcomes; incident decisions; customer impact records. |
Strengthen account takeover analytics, independent restriction controls and secure customer recovery procedures. |
Fraud-control effectiveness testing; incident simulation; restriction test; remediation evidence. |
|
CBS-3.7 |
Digital Account Information Retrieval and Presentation |
Replication defects corrupt account information; stale caching and interface weaknesses amplify incorrect presentation. |
No material compromise of authoritative financial data integrity; account information freshness. |
Detect and withhold or correct incorrect information before customers make materially harmful decisions. |
Source-to-channel reconciliation; stale data counts; API latency; balance discrepancies; customer journey results. |
Implement authoritative balance checks, freshness alerts, automated suppression and recovery reconciliation. |
Data integrity test; reconciliation control review; replication monitoring; approved recovery procedure. |
|
CBS-3.8 |
Digital Transaction History and Statement Services |
Ransomware affects records repositories; compromised backups prolong evidence recovery. |
Availability of essential financial records; customer harm from delayed dispute or information access. |
Recover trusted records and handle urgent customer requests through approved alternatives. |
Backup restoration results; record checksums or equivalent integrity checks; request backlog; recovery times. |
Maintain protected recovery copies, records integrity controls and prioritised retrieval procedures. |
Backup integrity report; recovery exercise; records retention review; remediation closure. |
|
CBS-3.9 |
Digital Customer Profile and Banking Preference Management |
Compromised credentials or API exploitation cause unauthorised profile changes and diversion of notifications. |
Immediate account security and integrity concern; timely delivery of essential alerts. |
Detect, contain, and reverse unauthorised changes without enabling downstream fraud. |
Profile audit logs; notification routing records; fraud alerts; reversal times; customer confirmation results. |
Strengthen sensitive-change authorisation, independent confirmation, anomaly detection and profile reconciliation. |
Access review; profile integrity test; security simulation; corrective-action verification. |
|
CBS-3.10 |
Digital Banking Service Request Management |
Workflow outage is the technology trigger; loss of specialist personnel prolongs request backlogs. |
Timely completion of essential customer requests; harm to urgent customers; duration of unavailable servicing. |
Urgent requests continue through controlled alternative processing with complete records and eventual reconciliation. |
Request backlog; priority-case completion times; staff availability; manual processing records; reconciliation results. |
Establish secure manual workarounds, cross-training, urgent-case prioritisation and queue recovery. |
BCM exercise; workforce contingency records; workflow recovery test; backlog reduction evidence. |
|
CBS-3.11 |
Digital Financial Transaction Initiation |
Capacity exhaustion and API timeouts trigger submission failures and repeated customer attempts. |
80% essential journey completion; affected customers; no duplicate or unauthorised instructions. |
Essential payments can be initiated or safely deferred, and repeated attempts do not create duplicate instructions. |
Transaction throughput; error and latency rates; retry logs; duplicate counts; customer journey success. |
Increase tested capacity headroom, implement unique transaction references and strengthen safe retry controls. |
Stress test; API resilience report; transaction integrity test; approved capacity improvement plan. |
|
CBS-3.12 |
Digital Transaction Validation and Authorisation Coordination |
Privileged rule manipulation affects authorisation decisions; shared controls propagate risk across channels. |
Immediate transaction authorisation integrity boundary; essential for completing payments. |
Reject unauthorised transactions, contain compromised rules, and safely restore legitimate authorisation. |
Authorisation decisions; fraud-rule changes; privileged-access logs; rejected legitimate transactions; rollback timing. |
Enforce dual control, monitor rule integrity, secure rollbacks, and independent fraud detection. |
Rule-control testing; penetration test; privileged access review; remediation validation. |
|
CBS-3.13 |
Digital Payment and Funds Transfer Processing Coordination |
Network and message queue failures can delay, duplicate, or lose payment instructions. |
Essential payment completion; two-hour disruption boundary; no material transaction duplication or loss. |
Authorised instructions remain traceable, duplicate payments are prevented, and reliable payment outcomes are established. |
Queue depth; message identifiers; reconciliation exceptions; payment completion times; network failover logs. |
Strengthen durable messaging, interface failover, duplicate suppression and controlled queue replay. |
Payment reconciliation test; queue recovery exercise; network resilience test; corrective-action closure. |
|
CBS-3.14 |
Digital Financing and Account Servicing Transactions |
Database corruption interrupts financing servicing; constrained specialist capacity delays repayments. |
Timely essential financing servicing; customer financial harm; data integrity. |
Urgent repayments are accurately processed or safely accommodated through approved alternatives. |
Repayment records; financing balance reconciliation; missed-deadline cases; recovery timestamps; customer exceptions. |
Validate financing data recovery, alternative repayment arrangements and due-date-sensitive customer prioritisation. |
Financing recovery test; repayment reconciliation; continuity exercise; management approval. |
|
CBS-3.15 |
Digital Transaction Status and Completion Management |
Time synchronisation and event ordering defects produce incorrect customer-facing payment status. |
Immediate transaction status integrity boundary; no material duplicate payment or incorrect confirmation. |
Customer status agrees with authoritative payment records, and uncertain outcomes are handled safely. |
Timestamp comparisons; status mismatches; duplicate attempts; reconciliation exceptions; customer notifications. |
Implement authoritative status reconciliation, clock monitoring, safe retry controls and pending-state management. |
Time synchronisation test; event replay validation; reconciliation control testing; defect closure. |
|
CBS-3.16 |
Digital Banking Customer Notification and Alert Management |
Third-party messaging outage delays security alerts during suspicious account activity. |
Timely security communication; financial harm from missed alerts; affected customer scope. |
Ensure essential security warnings reach customers through secure alternatives, and contain high-risk activity when communication fails. |
Alert delivery times; failed message counts; provider incident records; alternative-channel success; fraud outcomes. |
Establish priority notification routes, provider contingency arrangements, and delivery-assurance monitoring. |
Messaging failover report; provider assurance; notification simulation; corrective-action verification. |
|
CBS-3.17 |
Digital Banking Customer Enquiry and Assistance Management |
Telecommunications disruption and staffing shortages reduce support capacity during digital outage. |
Customer access to urgent assistance; duration and scope of unmet essential needs. |
Priority customers receive timely assistance through validated support channels despite primary channel failure. |
Contact centre availability; call abandonment; queue times; urgent-case resolution; alternative-channel capacity. |
Test independent customer support channels, surge staffing and prioritisation of vulnerable or urgent cases. |
Contact centre continuity exercise; staffing contingency test; customer support capacity assessment. |
|
CBS-3.18 |
Digital Banking Complaint and Service Issue Resolution |
A compromised case repository prevents access to evidence as disputed transactions increase. |
Prolonged financial harm from unresolved disputes; integrity and availability of investigation records. |
Investigate urgent disputes using trustworthy evidence, with appropriate customer protection and escalation. |
Evidence recovery results; complaint ageing; dispute volumes; investigation timelines; data integrity checks. |
Protect case evidence, establish priority redress procedures and test alternative investigation arrangements. |
Complaint recovery exercise; evidence integrity review; case management control test; remediation closure. |
|
CBS-3.19 |
Digital Banking Service Performance and Availability Monitoring |
Monitoring change suppresses alerts while customer journeys degrade. |
Early warning before a two-hour duration or customer-scope boundary; monitor journey completion. |
Detect material degradation through independent indicators and escalate promptly. |
Detection time; synthetic journey failures; alert logs; customer complaints; incident classification timeline. |
Deploy independent customer journey monitoring, alert coverage testing and detection-gap reviews. |
Monitoring effectiveness test; synthetic monitoring reports; alert simulation; independent review. |
|
CBS-3.20 |
Digital Banking Security Event Detection and Response Coordination |
Ransomware and privileged compromise affect shared systems; tampered security logs delay containment. |
Customer service availability; immediate integrity concern; cross-CBS propagation. |
Contain the cyber compromise, preserve trusted evidence, and coordinate essential service recovery with business owners. |
Security event logs; containment timestamps; affected assets; customer impact; clean recovery evidence; decision records. |
Strengthen independent security telemetry, privileged-access segregation, cyber recovery, and threat-led testing. |
Cyber exercise; detection validation; privileged access review; clean recovery test; remediation closure. |
|
CBS-3.21 |
Digital Banking Incident Assessment and Service Escalation |
Shared service failure creates fragmented incident reporting and delayed cross-CBS escalation. |
Timeliness of action before any approved tolerance boundary; customer-harm assessment. |
Decision-makers recognise interconnected disruption and activate appropriate continuity measures before unacceptable harm occurs. |
Incident timeline; escalation records; CBS impact assessment; crisis decisions; customer impact estimates. |
Establish CBS-level escalation triggers, integrated incident reporting and alternative crisis communications. |
Crisis exercise; escalation matrix; decision logs; management review; corrective-action verification. |
|
CBS-3.22 |
Digital Banking Continuity and Alternative Service Delivery |
Flooding and utility disruptions can affect digital operations and alternative banking channels at the same time. |
Essential service availability; affected customers; duration without effective alternatives. |
Secure alternative delivery remains available for priority customer needs, or promptly identify and escalate limitations. |
Alternative-channel capacity; facility status; staffing; customer completion outcomes; continuity activation times. |
Validate geographic separation, workforce contingency, alternative-channel independence and capacity. |
Regional BCM exercise; alternative-channel test; facility dependency assessment; remediation closure. |
|
CBS-3.23 |
Digital Banking Technology Recovery and Service Reinstatement |
Destructive cyber compromise affects production and recovery data, with shared administrative dependencies. |
Two-hour disruption boundary; essential journey restoration; no untrusted financial data release. |
Restore the trusted essential capability through validated recovery arrangements without reintroducing compromise. |
Recovery timestamps; backup integrity; infrastructure restoration logs; cross-CBS test results; customer journey success. |
Strengthen recovery isolation, protect backups, and use independent credentials and recovery sequencing. |
Disaster recovery test; cyber recovery report; architecture review; backup validation; retest evidence. |
|
CBS-3.24 |
Digital Banking Service Restoration and Post-Incident Validation |
Premature reopening occurs before financial records and transaction status are fully reconciled. |
Immediate integrity boundary; verified restoration of essential customer outcomes. |
Reopen digital banking only after business, security, and transaction integrity acceptance criteria are met. |
Reconciliation reports; business sign-off; security clearance; customer journey results; rollback and monitoring records. |
Establish mandatory restoration gates, joint acceptance authority, enhanced monitoring and controlled rollback. |
Approved restoration checklist; end-to-end validation; reconciliation evidence; post-incident review; closure records. |
How to Evaluate the Expected Resilience Outcomes
Assess the expected outcomes in Table 2 using objective evidence rather than participant assertions.
For availability-related scenarios, the test should establish the number of affected customers, the duration of material disruption and the proportion of essential journeys completed.
For integrity-related scenarios, the test should determine whether the system prevented, detected, contained, and corrected incorrect data, unauthorised transactions, duplicate instructions, or misleading payment status.
For operational and crisis management scenarios, the test should measure detection time, escalation time, decision quality, continuity activation, alternative-channel capacity and customer assistance effectiveness.
For recovery scenarios, the test should distinguish between technical system recovery and verified restoration of essential digital banking services.
A test that restores an application within its RTO but leaves customers unable to complete payments should not be reported as successful CBS-3 Scenario Testing.
Integrated End-to-End Scenario Testing Programme
Organise the 24 Sub-CBS tests into six integrated testing groups.
Each group should challenge a different part of the digital banking service lifecycle, while at least one comprehensive exercise should test the entire service under simultaneous failures.
Recommended Integrated Testing Groups
|
Integrated Test |
Sub-CBS Coverage |
Lead Participants |
Primary Testing Methods |
End-to-End Outcome |
|
ST-01: Digital Access, Authentication and Customer Protection |
CBS-3.1–3.6 |
Digital Banking, Identity Management, Cybersecurity, Fraud Operations, Customer Service, Technology |
Cyber simulation, API resilience, capacity stress, controlled failover and customer journey testing |
Customers retain or regain secure access without unauthorised account activity. |
|
ST-02: Account Information and Customer Servicing Integrity |
CBS-3.7–3.10 and CBS-3.14 |
Core Banking, Data Management, Financing Operations, Customer Service, BCM |
Data integrity testing, application recovery, workflow continuity and business simulation |
Customers receive trustworthy account information and essential servicing despite system and personnel disruption. |
|
ST-03: Digital Transaction and Payment Resilience |
CBS-3.11–3.13 and CBS-3.15 |
Payment Operations, Digital Banking, CBS-2 Owner, CBS-8 Owner, Technology, Cybersecurity |
Transaction stress, network and API resilience, reconciliation and end-to-end payment simulation |
Authorised payments are processed or safely deferred without loss, duplication or misleading status. |
|
ST-04: Customer Communication, Assistance and Resolution |
CBS-3.16–3.18 |
Customer Service, Fraud Operations, Communications, Compliance, Third-Party Risk, BCM |
Third-party disruption, contact centre stress and customer assistance continuity exercise |
Customers receive urgent alerts, support and appropriate handling of financial disputes. |
|
ST-05: Detection, Cyber Response and Crisis Escalation |
CBS-3.19–3.21 |
Cybersecurity, Technology Operations, Operational Risk, Crisis Management, CBS Owners |
Threat-led cyber simulation, monitoring fault injection and crisis management exercise |
Significant disruption is detected, escalated and managed before unacceptable harm develops. |
|
ST-06: Continuity, Recovery and Safe Restoration |
CBS-3.22–3.24, incorporating critical upstream processes |
Technology Recovery, BCM, Cybersecurity, Digital Banking, Payment Operations, Customer Service |
Combined cyber and disaster recovery test, alternative-channel exercise and end-to-end service validation |
Essential digital banking capability is maintained or safely restored within approved boundaries. |
Recommended programme design: ST-01 to ST-06 should share a common customer journey catalogue, dependency map, evidence standard and Impact Tolerance assessment method.
Their findings should then inform a comprehensive cross-CBS exercise rather than remain isolated test results.
Essential Customer Journeys to be Validated
For CBS-3, MBSB should select representative customer journeys that reflect essential banking needs.
|
Customer Journey |
Principal Sub-CBS |
Connected CBS |
Required Validation |
|
Access digital banking securely |
CBS-3.3–3.6 |
CBS-8 |
Customers can authenticate and establish a secure session. |
|
Retrieve account information |
CBS-3.7–3.8 |
CBS-1 |
Account information is accurate, current and accessible. |
|
Initiate and authorise a payment |
CBS-3.11–3.13 |
CBS-2, CBS-8 |
Accept, authorise, and process legitimate payment instructions safely. |
|
Verify payment completion |
CBS-3.15–3.16 |
CBS-2 |
Customers receive accurate transaction outcomes and appropriate notifications. |
|
Service an urgent financing obligation |
CBS-3.10, CBS-3.14 |
CBS-5, CBS-2 |
Complete or safely accommodate urgent repayment or servicing activity. |
|
Obtain assistance during disruption |
CBS-3.16–3.18, CBS-3.22 |
CBS-9 |
Customers can obtain support and appropriate alternatives. |
|
Resume banking after a major incident |
CBS-3.19–3.24 |
CBS-1, CBS-2, CBS-8, CBS-9 |
Recovery is verified through secure, accurate, end-to-end customer transactions. |
Illustrative Comprehensive Scenario
Scenario title: Coordinated Cyberattack, Shared Authentication Failure and Compromised Recovery Capability
A coordinated cyberattack compromises privileged access to a shared identity environment while a DDoS attack disrupts digital banking channels.
Customers begin experiencing authentication failures and incomplete payment journeys.
During containment, security teams discover that some recovery configuration data cannot be trusted.
Customer support volumes increase sharply, and a telecommunications disruption limits the capacity of an alternative assistance channel.
MBSB must determine whether it can preserve essential digital banking outcomes while maintaining customer fund protection, coordinating interconnected CBSs and restoring trusted systems.

Illustrative Exercise Timeline
The following timeline is for a compressed simulation.
The times represent simulated incident time, not necessarily the actual duration of exercise execution.
|
Simulated Time |
Scenario Inject |
Expected Response |
Evidence Required |
|
T+00 minutes |
Digital banking authentication failures and increased channel latency. |
Detect customer-facing degradation and open a coordinated incident record. |
Monitoring alerts, customer journey failures, detection timestamp. |
|
T+15 minutes |
Security operations identify suspicious privileged access and abnormal external traffic. |
Assess cyber compromise, isolate affected controls and evaluate customer impact. |
Cyber logs, containment decisions, access records. |
|
T+30 minutes |
Payment initiation success rates decline; customers begin repeating transactions. |
Engage CBS-2 and CBS-8 owners; assess duplicate-payment exposure and activate protective measures. |
Transaction logs, payment reconciliation, cross-CBS escalation. |
|
T+45 minutes |
Recovery teams report that standby authentication configuration cannot be trusted. |
Reassess recovery assumptions and initiate clean recovery or alternative access arrangements. |
Recovery decision log, integrity assessment, alternative capability status. |
|
T+60 minutes |
Customer support volumes surge while an alternative telecommunications route becomes unavailable. |
Prioritise urgent customer needs and evaluate remaining service capability. |
Contact centre capacity, urgent-case handling, customer impact estimates. |
|
T+90 minutes |
Recovery infrastructure becomes available, but some transaction acknowledgements remain unresolved. |
Maintain transaction safeguards and begin business reconciliation before reopening. |
Transaction-state comparisons, reconciliation exceptions, recovery timeline. |
|
T+120 minutes |
The illustrative maximum material disruption boundary is reached. |
Determine whether essential customer outcomes remained within every approved tolerance dimension. |
Formal Impact Tolerance assessment, customer journey metrics, decision records. |
|
T+150 minutes |
A restoration defect creates incorrect payment status for a simulated customer cohort. |
Stop or restrict affected processing, investigate integrity and invoke rollback if necessary. |
Validation results, rollback records, customer harm assessment. |
|
Exercise closure |
Controllers disclose additional dependency and monitoring weaknesses. |
Conduct an after-action review and approve remediation and retesting requirements. |
Observation report, action register, management decisions. |
The test should allow failure.
Controllers should not provide artificial recovery success simply because the scenario has reached a scheduled milestone.
Participants and Independent Observation
The comprehensive exercise should involve the CBS-3 Owner, Digital Banking Operations, Payment Operations, Core Banking, Identity Management, Technology Infrastructure, Cybersecurity, Fraud Operations, Customer Service, BCM, Operational Resilience, Operational Risk, Crisis Management, Third-Party Risk and Compliance.
Where relevant, critical providers should participate in controlled portions of the exercise.
Independent observers should evaluate the effectiveness of detection, escalation, decision-making, dependency coordination, customer harm assessment and evidence collection.
Internal Audit may observe or independently review the exercise under its assurance mandate, without assuming responsibility for designing or operating the controls being tested.
Scenario Test Design, Execution and Evidence Management
Minimum Scenario Test Design Profile
Every material CBS-3 scenario test should have an approved design profile before execution.
|
Test Design Element |
Required Content |
|
Test identifier and title |
Unique reference, test group and scenario name. |
|
Critical Business Service |
CBS-3 Digital Banking Services. |
|
Sub-CBS scope |
Relevant process codes and exact process names. |
|
Business owner |
Accountable CBS Owner and supporting process owners. |
|
Scenario description |
Credible initiating event, escalation and cascading consequences. |
|
Starting conditions |
Customer demand, operational capacity, technology status and assumed control availability. |
|
Scenario severity |
Duration, affected customers, integrity risks and additional adverse conditions. |
|
Interdependencies |
Supporting people, systems, data, facilities, third parties and connected CBSs. |
|
Cyber and ICT exposures |
Relevant threats, failure mechanisms, detection and recovery dependencies. |
|
Testing methods |
Selected methods and rationale for their suitability. |
|
Participants and observers |
Business, technology, risk, crisis, third-party and independent observation roles. |
|
Impact Tolerance |
Approved measures, calculation methods and breach criteria. |
|
Scenario timeline and injects |
Event sequence, decision points and controlled complications. |
|
Expected resilience capability |
Required service continuity, containment, alternative delivery and recovery outcomes. |
|
Success criteria |
Measurable customer outcomes, integrity requirements and escalation performance. |
|
Evidence requirements |
Logs, timestamps, reconciliations, observations and management decisions. |
|
Safety controls |
Test authorisation, production safeguards, stop conditions and rollback procedures. |
|
Post-test arrangements |
Lessons, remediation owners, deadlines, risk acceptance and retesting. |
Recommended Evidence Collection Structure
MBSB should retain a consolidated evidence package for each test.
|
Evidence Category |
Examples |
Assessment Purpose |
|
Test approval and preparation |
Approved test plan, risk assessment, participant list, scenario profile. |
Demonstrate appropriate governance and controlled preparation. |
|
Execution evidence |
Inject log, controller notes, participant records, timestamps. |
Establish what actually occurred and when. |
|
Customer service outcomes |
Journey success rates, affected customer estimates, transaction latency, support capacity. |
Assess end-to-end service delivery against Impact Tolerance. |
|
Cybersecurity and ICT |
Security alerts, system logs, API performance, network events, capacity and failover records. |
Establish the causes, propagation and containment of disruption. |
|
Transaction and data integrity |
Reconciliation reports, duplicate detection, authoritative status comparisons, data validation. |
Demonstrate that financial outcomes remained accurate and controlled. |
|
Response and recovery |
Escalation records, crisis decisions, continuity activation, recovery logs and restoration approvals. |
Evaluate management decisions and operational effectiveness. |
|
Independent observations |
Observer reports, control weaknesses, assumptions challenged. |
Provide an objective assessment of resilience performance. |
|
Remediation and closure |
Action plans, accountable owners, due dates, retest evidence, committee minutes. |
Demonstrate that lessons result in verified improvements. |
Protect evidence against unauthorised alteration and retain it in accordance with MBSB's applicable records management, information security, and regulatory obligations.
Test Outcome Classification
CBS-3 Scenario Test Outcome Assessment

Regulatory Considerations for Scenario Testing by a Malaysian Financial Services Institution
BNM Regulatory Reference and Status
The principal reference is Bank Negara Malaysia's Operational Resilience Discussion Paper, issued on 19 December 2025 (BNM/RH/DP 028-25).
The document outlines the emerging direction of operational resilience for Malaysian financial institutions, emphasising continuity of critical services, internal and external dependencies, disruption tolerances, severe but plausible scenarios, governance, and continuous improvement.
Importantly, the document is a Discussion Paper, not a final standalone Operational Resilience policy document. Its discussion themes and proposals should not be represented as newly binding regulatory requirements.
Relevant BNM discussion Themes and Implementation Implications
|
BNM Reference |
What the Discussion Paper States |
Implication for MBSB Scenario Testing |
Classification |
|
Paragraph 2.2 |
Cyber incidents, technology failures, third-party outages, compromised information and power failures can disrupt essential financial services. |
Include combined cyber, ICT, third-party and infrastructure disruptions in the CBS-3 test portfolio. |
Explicit BNM discussion; test design is a recommendation. |
|
Paragraphs 2.5–2.6 |
Digital financial access matters to customers, but interconnected infrastructure and concentrated providers can amplify disruption. |
Measure customer outcomes and test dependencies across shared authentication, telecommunications, and payment systems. |
Explicit BNM discussion; implementation method is recommended. |
|
Paragraph 2.9(d) |
Customer and external harm must inform disruption tolerances; internal recovery metrics alone may be inadequate. |
Assess CBS-3 using customer impact, essential service capability and transaction integrity rather than RTO alone. |
Explicit BNM discussion theme. |
|
Paragraph 2.9(e) |
Isolated failure testing is insufficient; severe but plausible testing should incorporate concurrent disruptions. |
Conduct integrated exercises involving multiple Sub-CBS processes and simultaneous failures. |
Explicit BNM discussion theme. |
|
Paragraph 3.3(b) |
Mapping internal and external dependencies helps reveal vulnerabilities and critical points of failure. |
Use the CBS-3 dependency map to select test injects and assess cascading consequences. |
Explicit BNM discussion theme. |
|
Paragraph 3.3(c) |
Third-party dependencies and viable alternatives are important resilience considerations. |
Include critical providers and challenge the independence of alternative arrangements. |
Explicit BNM discussion theme. |
|
Paragraph 3.3(d) |
Disruption tolerances should consider duration, customer or market harm and minimum service capability. |
Apply approved multi-dimensional Impact Tolerance criteria to every integrated test. |
Explicit BNM discussion theme. |
|
Paragraph 3.3(e) |
Severe but plausible scenarios should challenge assumptions, anticipate multilayered failures and reveal deficiencies. |
Include adverse injects, failed recovery assumptions and realistic operational constraints. |
Explicit BNM discussion theme. |
|
Paragraphs 3.4–3.5 |
Board and senior management ownership, resource decisions, periodic reviews and continuous improvement are important. |
Establish management approval, reporting, corrective-action tracking and retesting. |
Explicit BNM discussion theme; proposed governance workflow is recommended. |
|
Paragraphs 4.3–4.5 |
Existing BCM, RMiT and outsourcing policy documents address recovery, technology resilience and external dependencies. |
Integrate CBS-3 Scenario Testing with existing BCM, cyber, ICT and third-party assurance arrangements. |
Description of existing policy areas; detailed integration is recommended. |
Regulatory Examples Relevant to Scenario Testing
BNM's Discussion Paper refers to operational disruption examples, including mobile banking and payment failures linked to core banking capacity, a widespread banking outage after an unsuccessful disaster recovery test, and ransomware linked to weaknesses in cybersecurity controls.
It also discusses international disruption involving technology migration, payment and settlement infrastructure, and widespread electricity failure.
These examples support including challenging scenarios that extend beyond a single application or infrastructure component.
For MBSB, appropriate consultant-recommended tests include:
- A prolonged digital banking outage during peak customer demand.
- Simultaneous authentication and payment-processing disruption.
- A cyber incident affecting production and recovery capabilities.
- Failure of a critical telecommunications or technology service provider.
- Corruption of account balances or records of completed transactions.
- Loss of critical operational personnel during a technology incident.
- Cascading disruption involving CBS-1, CBS-2, CBS-3 and CBS-8.
- Restoration of digital banking when transaction integrity cannot yet be demonstrated.
These specific MBSB tests are implementation recommendations, not BNM-prescribed exercises.
Relationship with Existing BNM Requirements
The Discussion Paper identifies existing BNM policy documents addressing BCM, Risk Management in Technology, outsourcing, operational risk and governance.
It also distinguishes operational resilience's service-outcome focus from more granular recovery and technology controls.
MBSB should therefore integrate the proposed Scenario Testing Programme with its applicable regulatory obligations and existing assurance arrangements.
|
Management Discipline |
Contribution to Scenario Testing |
Required Integration |
|
Business Continuity Management |
Business recovery arrangements, alternative processes, workforce and facility continuity. |
Validate whether business recovery arrangements preserve essential CBS-3 customer outcomes. |
|
Risk Management in Technology |
ICT availability, cybersecurity, system resilience, failover and recovery. |
Use technical test evidence while assessing its effect on end-to-end service delivery. |
|
Third-Party Risk Management |
Provider resilience, concentration, assurance and contingency. |
Test whether critical external dependencies and alternatives remain viable. |
|
Operational Risk Management |
Control weaknesses, operational incidents, residual risks and risk treatment. |
Incorporate scenario findings into risk assessments and control improvement. |
|
Crisis Management |
Escalation, decision-making, coordination and communications. |
Test whether management intervenes before unacceptable harm develops. |
|
Governance and Independent Assurance |
Accountability, challenge, approval and remediation oversight. |
Maintain auditable evidence of management decisions and independent review. |
Before using the chapter as part of a formal regulatory submission, MBSB should confirm the current status and applicability of relevant BNM policy documents and any subsequent developments following the December 2025 Discussion Paper.
Management Oversight, Remediation, and Continuous Improvement
Recommended Scenario Testing Governance
The CBS-3 Owner should remain accountable for demonstrating that essential digital banking outcomes can be maintained within the approved Impact Tolerance.
Operational Resilience should coordinate the programme, while Technology, Cybersecurity, BCM, Operational Risk, Customer Service and other participating functions provide specialist evidence and execute their respective responsibilities.
Senior management should review significant weaknesses, tolerance breaches, limitations in recovery capability, and material investment requirements.
The Board or relevant Board committee should receive reporting proportionate to the significance of the findings and the bank's governance arrangements.
Recommended Management Reporting Dashboard
|
Management Indicator |
Recommended Measurement |
Management Interpretation |
|
Sub-CBS testing coverage |
Number of Sub-CBS processes meaningfully tested out of 24. |
Identifies gaps in the test programme. |
|
Integrated scenario coverage |
Number of integrated tests completed against the approved programme. |
Demonstrates whether cross-service failures have been challenged. |
|
Impact Tolerance outcomes |
Tests within tolerance, breached, or inconclusive. |
Provides evidence of CBS-level resilience. |
|
Customer journey completion |
Percentage of essential journeys completed during simulated disruption. |
Measures customer-facing service capability. |
|
Maximum customer disruption |
Duration and proportion of customers materially affected. |
Evaluates customer harm and remaining resilience margin. |
|
Transaction integrity exceptions |
Unauthorised, duplicated, lost or unreconciled transactions. |
Identifies potentially intolerable financial integrity weaknesses. |
|
Detection and escalation performance |
Time to detect, assess, escalate and activate response. |
Measures operational preparedness and decision effectiveness. |
|
Recovery and restoration capability |
Time to recover trusted essential capability and obtain business acceptance. |
Distinguishes technology recovery from safe service restoration. |
|
Third-party resilience |
Critical dependencies tested and unresolved provider weaknesses. |
Identifies concentration and external dependency exposures. |
|
Remediation progress |
Open, overdue, completed and independently verified corrective actions. |
Demonstrates management accountability and continuous improvement. |
Converting Findings into Corrective Actions
Scenario Testing should follow a structured corrective-action process.

Illustrative Remediation Action Register
|
Finding |
Potential Resilience Consequence |
Recommended Action |
Responsible Function |
Closure Evidence |
|
Authentication failover depends on the same administrative control environment. |
Simultaneous primary and recovery failure could disable essential digital banking access. |
Establish and test independently protected recovery administration. |
Identity Management and Cybersecurity |
Architecture review, privileged recovery test and successful retest. |
|
Payment acknowledgements become inconsistent after message queue recovery. |
Customers may receive incorrect payment status or submit duplicate transactions. |
Implement authoritative reconciliation and controlled message replay. |
Payment Technology and Operations |
Reconciliation testing, defect closure and end-to-end payment retest. |
|
Infrastructure monitoring does not detect customer journey degradation. |
Incident response may begin too late to prevent an Impact Tolerance breach. |
Implement independent synthetic customer journey monitoring and CBS-level alert thresholds. |
Technology Monitoring and Digital Banking |
Monitoring coverage report, alert simulation and detection-time evidence. |
|
Alternative customer support cannot handle peak incident demand. |
Customers may be unable to access essential assistance during digital banking disruption. |
Increase tested surge capacity and establish independent assistance channels. |
Customer Service and BCM |
Capacity exercise, staffing evidence and customer support continuity retest. |
|
Recovery validation does not include authoritative transaction-state checks. |
Services may reopen with incorrect balances or unresolved payments. |
Introduce mandatory transaction-integrity and business-acceptance gates. |
Core Banking, Payment Operations and Digital Banking |
Approved restoration checklist, reconciliation evidence and recovery retest. |
|
Fragmented incident reporting delays cross-CBS escalation. |
Simultaneous failures may exceed the tolerance before coordinated action occurs. |
Establish shared customer-impact reporting and explicit CBS-level escalation triggers. |
Crisis Management and Operational Resilience |
Update the escalation procedure, crisis exercise, and decision-time records. |
These are illustrative findings and actions, not confirmed weaknesses within MBSB.
Recommended Testing Frequency and Review Triggers
MBSB should establish a risk-based testing calendar rather than apply an identical testing frequency to every Sub-CBS.
As an illustrative implementation recommendation, MBSB could conduct periodic integrated CBS-3 exercises, supplemented by targeted tests of critical dependencies and controls.
The bank should determine the appropriate cadence based on risk, materiality, regulatory obligations and previous test results.
Consider additional testing after material technology changes, new external dependencies, significant cyber threats, major incidents, changes in customer service delivery, unsuccessful recovery exercises, or remediation of critical findings.
Document the frequency in the approved programme. No particular testing interval in this chapter is represented as a BNM-prescribed frequency.
Recommended Scenario Testing Deliverables
The Scenario Testing Programme should produce a controlled set of documents suitable for operational use, management oversight and supervisory review.
|
Deliverable |
Purpose |
Recommended Owner |
|
ST-01: Scenario Testing Programme and Schedule |
Establish approved scope, priorities, methods, integrated test groups and timetable. |
Operational Resilience |
|
ST-02: Scenario Test Design Profiles |
Document each scenario's objectives, assumptions, injects, dependencies, participants and success criteria. |
Scenario Test Lead |
|
ST-03: Test Execution and Evidence Register |
Maintain execution records, logs, timestamps, observations and supporting artefacts. |
Test Controller and Evidence Custodian |
|
ST-04: Impact Tolerance Assessment Report |
Determine whether CBS-3 remained within approved customer-harm and service capability boundaries. |
CBS-3 Owner and Operational Resilience |
|
ST-05: Scenario Testing Results and Vulnerability Register |
Consolidate findings, dependency weaknesses, control failures and residual risks. |
Operational Risk and Operational Resilience |
|
ST-06: Corrective Action and Remediation Plan |
Assign actions, accountable owners, deadlines, investment needs and acceptance criteria. |
Relevant Control and Service Owners |
|
ST-07: Retesting and Effectiveness Verification Report |
Demonstrate that corrective actions resolve identified weaknesses. |
Test Lead and Independent Reviewer |
|
ST-08: Management and Board Reporting Pack |
Present resilience outcomes, tolerance breaches, significant risks, investment decisions and remediation progress. |
Operational Resilience and Relevant Governance Functions |
These document identifiers are proposed for this eBook and do not imply existing MBSB document codes.
Scenario Testing is essential for validating whether CBS-3 Digital Banking Services can withstand severe operational disruption while maintaining essential customer outcomes within an acceptable level of harm.
Assessing all 24 Sub-CBS processes provides a detailed understanding of the activities and dependencies that support digital banking, while the six integrated testing groups enable MBSB to challenge the service as a connected operating system rather than a collection of isolated applications or departments.
Severe but Plausible Scenarios provide the necessary stress conditions, while the approved Impact Tolerance establishes the boundary against which resilience must be assessed.
Together, they ensure that Scenario Testing focuses on customers' ability to access funds, complete legitimate transactions, receive accurate financial information and obtain essential assistance.
Integrating Cyber and ICT Risks strengthens the programme by examining how cyberattacks, infrastructure failures, data corruption, technology concentration, and compromised recovery arrangements can interact with operational processes, personnel constraints, and external dependencies.
Auditable evidence from testing, monitoring, transaction reconciliation, incident response, continuity exercises, recovery validation and management decisions is necessary to demonstrate resilience preparedness.
This evidence also lets management distinguish demonstrated capability from untested assumptions.
Most importantly, Scenario Testing must lead to action.
Findings should translate into lessons learned, accountable remediation, risk treatment, resilience investment, effectiveness verification, and retesting.
The ultimate objective is not to demonstrate that MBSB can recover individual digital banking systems.
It is to establish, through credible, independently reviewable evidence, that MBSB can continue delivering essential digital banking services safely and within its approved Impact Tolerance, even when multiple operational, cyber, and technology dependencies fail simultaneously.
Quality-control note: The supplied catalogue contains 24 Sub-CBS processes, although the quality-control instructions refer to 20. Both detailed tables include all 24, CBS-3.1 through CBS-3.24, using the exact supplied names.
All thresholds, testing designs, potential findings and control recommendations are illustrative and require MBSB validation.
Regulatory references distinguish BNM's December 2025 Discussion Paper from existing binding policy requirements.
References
Understanding Scenario Testing in Operational Resilience; What is Scenario Testing in Operational Resilience?; Introduction to Scenario Testing; and BNM Operational Resilience Discussion Paper (2025).
| eBook 3: Starting Your OR Implementation |
||||
| CBS-3 Digital Banking Services | ||||
| CBS-3 DP | CBS-3 MII | CBS-3 ITo | CBS-3 SbPS | CBS-3 ST |
![]() |
![]() |
![]() |
![]() |
![]() |
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.

![BB OR [B] 13 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)
![[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)

![x [OR] [MBSB] Legal Disclaimer Banner](https://no-cache.hubspot.com/cta/default/3893111/d779f9ab-aec0-4cdd-a906-81e7841c3e1c.png)

![[OR] [MBSB] [E3] [CBS] [3] [ST] Digital Banking Services](https://no-cache.hubspot.com/cta/default/3893111/c22a5556-09bb-4c57-b9a4-7ea2ab5be915.png)
![Banner [Summing] [OR] [E3] Perform Scenario Testing](https://no-cache.hubspot.com/cta/default/3893111/11895c06-91e9-4cec-acb6-4356741952e4.png)
![[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)
![[OR] [MBSB] [E3] [CBS] [3] [DP] Digital Banking Services](https://no-cache.hubspot.com/cta/default/3893111/46949462-c4aa-464d-bef5-c0a9b2e6bab6.png)
![[OR] [MBSB] [E3] [CBS] [3] [MII] Digital Banking Services](https://no-cache.hubspot.com/cta/default/3893111/74c4f462-7a20-49b5-aaf1-068e2f4956e9.png)
![[OR] [MBSB] [E3] [CBS] [3] [ITo] Digital Banking Services](https://no-cache.hubspot.com/cta/default/3893111/56aa144a-f755-4aef-ab05-f29c3cd8ad89.png)
![[OR] [MBSB] [E3] [CBS] [3] [SbPS] Digital Banking Services](https://no-cache.hubspot.com/cta/default/3893111/6e7f0ef7-370b-4182-8814-6b83fe57964a.png)







![[BL-OR] [3-4-5] View Schedule](https://no-cache.hubspot.com/cta/default/3893111/d0d733a1-16c0-4b68-a26d-adbfd4fc6069.png)
![[BL-OR] [3] FAQ OR-300](https://no-cache.hubspot.com/cta/default/3893111/f20c71b4-f5e8-4aa5-8056-c374ca33a091.png)
![Email to Sales Team [BCM Institute]](https://no-cache.hubspot.com/cta/default/3893111/3c53daeb-2836-4843-b0e0-645baee2ab9e.png)








