[OR] [MBSB] [E3] [CBS] [1] [ST] Perform Scenario Testing

CBS-1 Customer Deposit and Account Access Services

Introduction

Scenario Testing is the point at which MBSB moves from documenting Operational Resilience arrangements to demonstrating whether those arrangements can withstand disruption in practice.

For CBS-1 Customer Deposit and Account Access Services, testing should determine whether customers can continue to obtain an acceptable level of access to their deposit accounts when MBSB is exposed to Severe but Plausible Scenarios (SbPS).

The testing programme should therefore focus on the end-to-end Critical Business Service, not merely on whether an individual system, department, Business Continuity Plan or Disaster Recovery arrangement performs as designed.

CBS-1 depends on the combined operation of account processing, customer information, authentication, digital and assisted channels, transaction records, telecommunications, incident management, customer assistance, alternative arrangements, recovery and reconciliation.

A successful technical recovery does not necessarily mean that CBS-1 has been restored.

This approach is consistent with the direction set out in the 2025 Bank Negara Malaysia Operational Resilience Discussion Paper.

BNM highlights the importance of understanding dependencies, establishing tolerance boundaries and assessing critical services across scenarios severe enough to expose deficiencies while remaining credible.

BNM also states that testing isolated failures is no longer sufficient and that concurrent scenarios should be considered to obtain a realistic view of vulnerabilities.

For this chapter, the previously proposed illustrative four-hour Impact Tolerance for CBS-1 is used as the working boundary. It should be supplemented by customer-impact, channel-availability, and data-integrity measures, and it remains subject to MBSB's formal validation and approval.

Cyber and ICT Risks are embedded throughout the programme.

BNM notes that cyber incidents, technology failures, third-party outages, compromised data and power outages can cause widespread loss of essential financial services, while digital channels, APIs, cloud environments and telecommunications create increasingly complex dependency chains.

Quality-control note: The supplied catalogue contains 18 Sub-CBS processes, not 20. All 18 supplied processes are included below.

Scenario Testing Approach for CBS-1

The recommended programme uses different test methods according to the nature of the capability being challenged.

Technical dependencies are subjected to recovery, failover, capacity, network or data-integrity testing where appropriate.

Processes involving management judgement, customer response and cross-functional coordination are better challenged through simulation, tabletop or crisis exercises.

High-consequence dependencies should ultimately form part of an integrated end-to-end CBS-1 scenario test.

This is consistent with BCM Institute's methodology, which describes Scenario Testing as assessing whether the organisation can remain within its Impact Tolerance during Severe but Plausible Scenarios, with emphasis on response and recovery capability rather than merely preventive controls.

Table P6: Perform Scenario Testing for CBS-1

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-1.1	Deposit Account Establishment and Activation	Digital onboarding failure during high-volume period	Onboarding Failure and Backlog Recovery Test	Integrated business/technology simulation plus capacity test	Validate whether account establishment can continue through alternative arrangements and whether accumulated applications can be recovered without compromising data integrity or customer access.	Failed deployment; onboarding API unavailable; rollback unsuccessful; application volumes increase; branch/manual capacity constrained; service restored with backlog.	Customer onboarding; identity verification; account platform; customer records; CBS-8 Customer Transaction Authentication and Authorisation Services; branch operations.
CBS-1.2	Customer and Account Information Maintenance	Customer master-data corruption	Customer Data Integrity Recovery Test	Data integrity and reconciliation test	Determine whether corrupted customer records can be identified, isolated, restored and reconciled before they materially impair account access.	Batch update completes; latent corruption discovered; affected population initially unknown; authentication failures emerge; backup data must be validated before restoration.	Customer master data; account platform; CRM; authentication; CBS-8; backup and recovery capability.
CBS-1.3	Account Status and Access Administration	Privileged access compromise creates incorrect account restrictions	Mass Account-Control Compromise Simulation	Cyber incident simulation	Test detection, containment and controlled reversal of unauthorised account-status changes without introducing further fraud or access risks.	Privileged credentials compromised; hundreds or thousands of accounts restricted; administrator access suspended; customer complaints rise; restoration approval required.	Privileged access management; fraud operations; account administration; CBS-8; cybersecurity; customer assistance.
CBS-1.4	Deposit Receipt and Account Credit Processing	Incoming credits fail during peak salary-credit period	Peak Credit Processing Disruption Test	Transaction-processing simulation plus capacity/stress test	Determine whether delayed incoming credits can be queued, reconciled and posted within tolerance while prioritising customers at risk of financial harm.	Processing interface fails; salary credits accumulate; customer enquiries surge; duplicate submission risk develops; interface recovery occurs with significant backlog.	CBS-2 Domestic Funds Transfer and Payment Services; account processing; transaction interfaces; reconciliation; customer support.
CBS-1.5	Account Balance and Transaction Record Processing	Core account-processing failure and recovery-site capacity degradation	Core Banking End-to-End Recovery Test	Disaster recovery test plus capacity/stress test	Demonstrate that recovery infrastructure can support production-scale CBS-1 demand and restore reliable balances and transaction processing within tolerance.	Primary environment lost; failover initiated; recovery performance degrades; transaction queues grow; digital, payment and cash channels compete for capacity.	Core account processing; database; CBS-2, CBS-3 Digital Banking Services, CBS-4 Cash Access and Cash Transaction Services, CBS-6 Corporate Payment and Bulk Transaction Services and CBS-7 High-Value and Interbank Payment Services.
CBS-1.6	Customer Account Enquiry and Information Access	Coordinated DDoS attack disrupts digital account access	Digital Access Cyber Resilience Test	Cyber incident simulation plus capacity/stress test	Test whether MBSB can maintain sufficient customer account-information access while digital channels are under sustained attack.	DDoS traffic rises; digital access deteriorates; contact-centre volumes increase; branches experience additional demand; mitigation initially only partially effective.	CBS-3; CBS-8; telecommunications; contact centre; branches; cyber monitoring; external connectivity.
CBS-1.7	Account Statement and Transaction Information Provision	Statement repository and replicated archive become unavailable	Statement Data Recovery Test	Technical recovery and data-integrity test	Validate recovery of statements and historical transaction information without diverting critical resources from higher-priority CBS-1 recovery.	Repository fails; replica has same logical corruption; current account processing remains operational; customer information requests accumulate.	Account data; document repository; backup environment; CBS-3; customer service.
CBS-1.8	Account Access Request and Instruction Processing	API gateway and middleware disruption	Customer Instruction Routing Resilience Test	API resilience and network resilience test	Verify that customer instructions can use alternative routing or be safely queued and recovered without loss or duplication.	Middleware unavailable; customer channels remain online; instructions time out; customers retry; alternate routing invoked; backlog released after restoration.	CBS-3; CBS-8; API gateway; middleware; network; account-processing platform; transaction queues.
CBS-1.9	Account Access Validation and Control	Shared identity and authentication service fails	Common-Mode Authentication Failure Test	Failover/redundancy test plus integrated business simulation	Determine whether customers retain a viable means of authenticated account access when a shared authentication capability fails.	IAM service fails; mobile and internet access unavailable; assisted channels show same dependency; failover partially succeeds; emergency access decision required.	CBS-3; CBS-8; IAM; digital channels; assisted channels; network; customer-service functions.
CBS-1.10	Account Access Exception and Rejection Management	Exception surge coincides with case-management outage	Access Exception Surge Test	Simulation and operational capacity test	Test MBSB's ability to identify systemic access failure, prioritise customers and prevent exception backlogs from extending disruption.	Failed channel release; rejection rates increase; case-management platform unavailable; manual cases accumulate; vulnerable customers identified.	CBS-8; CBS-9 Customer Support and Assistance During Banking Disruptions; customer channels; application support; case management.
CBS-1.11	Account Restriction and Access Restoration	Large credential-compromise event requires mass precautionary restrictions	Mass Restriction and Controlled Restoration Exercise	Cyber incident simulation plus operational stress test	Test whether MBSB can protect compromised accounts while restoring legitimate customer access quickly enough to avoid intolerable harm.	Fraud indicators increase; mass restrictions applied; customer verification demand exceeds capacity; false positives emerge; prioritisation required.	Fraud management; CBS-8; CBS-9; account controls; customer verification; cybersecurity; contact centre.
CBS-1.12	Deposit Account Reconciliation and Integrity Management	Material transaction-data corruption	Account Data Integrity Crisis Test	Data integrity and reconciliation test plus crisis simulation	Demonstrate that MBSB can establish authoritative balances following suspected corruption and avoid restoring an unsafe service.	Ledger discrepancies detected; production and replica potentially affected; extent unknown; customer balances questioned; management pressured to restore quickly.	Account ledger; transaction records; CBS-2, CBS-4, CBS-6 and CBS-7; recovery data; reconciliation teams; crisis management.
CBS-1.13	Account Access Service Monitoring and Exception Escalation	Monitoring blind spot delays recognition of widespread degradation	Detection and Escalation Effectiveness Test	Controlled simulation/ monitoring test	Determine whether independent monitoring and escalation arrangements detect customer-impacting degradation early enough to preserve the Impact Tolerance window.	Primary alerts suppressed; response time deteriorates; synthetic monitoring detects anomalies later; customer complaints rise; escalation threshold approached.	Monitoring platforms; service management; cybersecurity; technology operations; customer feedback; CBS-9.
CBS-1.14	Customer Account Access Incident Management	Ransomware affects several interconnected services and creates conflicting recovery priorities	Integrated Cyber and Crisis Management Exercise	Cyber incident simulation plus crisis management exercise	Validate cross-functional decision-making, containment, service prioritisation and recovery sequencing under uncertainty.	Ransomware confirmed; systems isolated; CBS-1 and CBS-3 affected; data integrity uncertain; ransom demand reported; recovery options conflict with cyber containment; regulatory/customer communications required.	Cybersecurity; technology; operations; BCM; crisis management; risk; compliance; senior management; CBS-3, CBS-4, CBS-8 and CBS-9.
CBS-1.15	Disrupted Account Access Customer Assistance	Contact-centre telecommunications fail during digital banking outage	Multi-Channel Customer Assistance Continuity Test	Business continuity simulation plus telecommunications resilience test	Validate that customers, particularly vulnerable customers, can obtain timely assistance when digital access and primary customer support are disrupted simultaneously.	Digital outage active; contact-centre telephony fails; call demand surges; alternative communications activated; branch enquiries rise.	CBS-3; CBS-9; telecommunications; contact centre; branches; customer communications; crisis management.
CBS-1.16	Alternative Account Access and Continuity Processing	Primary and alternative channels share a failed dependency	Alternative Service Independence Test	Integrated end-to-end CBS scenario test	Determine whether alternative arrangements are genuinely independent and capable of sustaining minimum CBS-1 delivery at stressed demand levels.	Primary digital channel fails; alternative channel activated; shared authentication/network dependency then fails; demand exceeds planned workaround capacity.	CBS-3; CBS-4; CBS-8; CBS-9; network; authentication; account data; alternative channels; third parties.
CBS-1.17	Deposit Account Processing Recovery and Reconciliation	Primary processing and disaster recovery environment fail	Recovery Strategy Failure Test	Disaster recovery test plus tabletop/simulation of secondary recovery	Determine whether MBSB has viable recovery options when its designated DR solution is unavailable or unsuccessful.	Primary site unavailable; DR failover fails; configuration inconsistency found; recovery specialists constrained; transaction backlog grows; alternative recovery decision required.	Primary and recovery environments; databases; network; specialist personnel; CBS-2, CBS-3, CBS-4, CBS-6 and CBS-7.
CBS-1.18	Account Access Service Restoration and Validation	Premature restoration causes secondary failure	End-to-End Service Restoration Validation Test	Integrated business and technology simulation	Validate that CBS-1 is not declared restored until account integrity, interfaces, channels, authentication, capacity and service stability have been confirmed.	Systems technically restored; reconciliation incomplete; management pressure to reopen; selected channels fail; duplicate postings emerge; decision required whether to withdraw service again.	CBS-1.5, CBS-1.9, CBS-1.12, CBS-1.13, CBS-1.14 and CBS-1.17; digital channels; transaction processing; monitoring; management governance.

Table 4: Impact Tolerance, Cyber/ICT and Resilience Outcomes for CBS-1

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-1.1	Deposit Account Establishment and Activation	Failed deployment, API failure and capacity constraint are primary ICT triggers.	Prevent prolonged inability to activate funded accounts; overall, CBS remains within the illustrative 4-hour tolerance, with existing customer access unaffected.	Alternative onboarding is operational; backlog remains controlled; no material data-integrity failures; activation restored within the approved target.	Test timeline; application volumes; API logs; backlog data; recovery time; customer-impact assessment.	Strengthen rollback testing, API compatibility controls and alternate onboarding capacity.	Change-test results; rollback tests; capacity evidence; remediation closure.
CBS-1.2	Customer and Account Information Maintenance	Data corruption and delayed detection can propagate into authentication and servicing.	Corruption must not cause widespread account access failures or material uncertainty about customer records.	Corrupted population identified quickly; further propagation stopped; authoritative records restored.	Integrity results; affected records; detection time; restoration logs; reconciliation results.	Introduce enhanced data validation and controlled batch-processing safeguards.	Control-testing reports; audit logs; data-quality monitoring; recovery test results.
CBS-1.3	Account Status and Access Administration	Privileged access compromise is the cyber trigger.	Mass incorrect restrictions must be detected and reversed before customer harm becomes intolerable.	Compromise contained; affected accounts identified; safe restoration prioritised; fraud exposure controlled.	Security logs; restriction volumes; detection/escalation times; restoration times; customer-impact data.	Strengthen privileged access monitoring and scalable reversal procedures.	PAM reviews; cyber-monitoring evidence; exercise report; remediation closure.
CBS-1.4	Deposit Receipt and Account Credit Processing	Interface, queue and middleware failure during peak processing.	Customer credits should not remain unavailable long enough to create material financial hardship; peak-period harm thresholds apply.	Transactions safely queued; no loss/duplication; priority credits processed; backlog cleared within tolerance.	Transaction counts/value; queue metrics; posting times; reconciliation; complaints; recovery duration.	Increase peak capacity, transaction-queue resilience and priority-processing capability.	Stress-test results; failover reports; reconciliation controls; management review.
CBS-1.5	Account Balance and Transaction Record Processing	Infrastructure outage, database failure, and exhaustion of recovery capacity.	Illustrative maximum 4 hours, with no material balance-integrity failure and minimum customer access restored earlier where practicable.	Production-scale processing recovered; balances reliable; interconnected CBSs progressively restored without exceeding tolerance.	Recovery timestamps; capacity utilisation; transaction backlog; availability; data-integrity results; cross-CBS status.	Address recovery capacity and common technology concentration weaknesses.	DR reports; capacity tests; architecture review; remediation evidence; independent assurance.
CBS-1.6	Customer Account Enquiry and Information Access	DDoS and channel-capacity exhaustion.	Avoid simultaneous, prolonged loss of all viable account information channels; monitor the material customer population threshold.	Attack mitigated; alternative channels absorb sufficient demand; customers retain minimum access to account information.	DDoS logs; availability; customer numbers; response times; contact-centre volumes; mitigation timestamps.	Improve DDoS resilience and cross-channel surge capability.	Cyber tests; capacity results; network tests; remediation tracker.
CBS-1.7	Account Statement and Transaction Information Provision	Repository/database failure and replicated logical corruption.	Temporary loss may be tolerable where current account access remains available; data must remain accurate and recoverable.	Historical information restored without corrupting current account data or delaying higher-priority recovery.	Recovery time; restored records; integrity checks; outstanding requests.	Maintain independently recoverable historical information.	Backup tests; integrity testing; technical recovery evidence.
CBS-1.8	Account Access Request and Instruction Processing	API, middleware and network-routing disruption.	Essential customer instructions should be restored or safely queued before CBS-1 exceeds its service-level tolerance.	Alternative routing succeeds or instructions are preserved; no material transaction loss or duplication.	API availability; queue records; failed instructions; recovery time; reconciliation results.	Strengthen alternate routing and transaction idempotency/queue controls.	API resilience results; network tests; architecture review; closure evidence.
CBS-1.9	Account Access Validation and Control	IAM common-mode failure.	Widespread loss of authentication across all principal access channels should not persist into the 4-hour outer boundary; security controls must not be bypassed in an unsafe manner.	Resilient or alternative authentication enables controlled access while maintaining security.	Authentication failure rates; channels affected; failover time; access-control logs; customer numbers.	Reduce common-mode IAM dependency and strengthen authentication recovery.	IAM failover report; architecture assessment; access-control test; remediation evidence.
CBS-1.10	Account Access Exception and Rejection Management	Failed application release plus case-management outage.	Exception backlog must not cause a material population to remain locked out beyond CBS tolerance.	Systemic cause identified; vulnerable/high-impact cases prioritised; backlog controlled.	Exception volumes; ageing; identification time; manual-processing capacity; customer outcomes.	Build independent exception monitoring and manual surge procedures.	Monitoring tests; BCP exercise; capacity assessment; action closure.
CBS-1.11	Account Restriction and Access Restoration	Credential compromise, cyber fraud and restoration-capacity constraint.	Security response must protect customers without creating prolonged widespread loss of legitimate access.	Fraud risk contained while legitimate customers are verified and restored within prioritised timelines.	Restricted accounts; false positives; verification times; fraud losses avoided; customer hardship cases.	Develop scalable mass-compromise and customer-restoration playbooks.	Cyber simulation; playbook approval; capacity test; management minutes.
CBS-1.12	Deposit Account Reconciliation and Integrity Management	Database/data corruption may invalidate production and replicated information.	No tolerance for known material corruption of customer balances or unreconciled material transaction loss, irrespective of the 4-hour time threshold.	Authoritative balances established before service is declared restored; uncertain data isolated.	Reconciliation breaks; affected accounts; integrity test results; decision logs; restoration approval.	Strengthen immutable transaction evidence and clean data-recovery capability.	Integrity tests; reconciliation evidence; backup validation; independent assurance.
CBS-1.13	Account Access Service Monitoring and Exception Escalation	Monitoring or cyber-detection failure delays recognition.	Detection and escalation must leave sufficient remaining time to recover CBS-1 before tolerance is breached.	Material degradation identified through independent indicators and escalated when thresholds are exceeded.	Alert timestamps; complaint timestamps; escalation times; monitoring coverage; decision records.	Implement end-to-end CBS monitoring and independent synthetic transactions.	Monitoring test; dashboard evidence; control assessment; remediation closure.
CBS-1.14	Customer Account Access Incident Management	Ransomware, monitoring, containment and recovery conflict.	Management decisions must preserve minimum service and enable CBS-1 recovery before the approved tolerance while maintaining safe cyber containment.	Integrated command established; priorities agreed; customer harm monitored; recovery proceeds safely.	Incident log; cyber events; crisis decisions; escalation timestamps; customer impact; recovery milestones.	Strengthen integrated cyber, technology, BCM and crisis-management playbooks.	Exercise reports; approved playbooks; committee minutes; remediation register.
CBS-1.15	Disrupted Account Access Customer Assistance	Telecommunications failure amplifies digital-service outage.	Minimum customer assistance must remain available throughout disruption, particularly for vulnerable/high-harm cases.	Alternative communications activated; surge demand managed; priority customers supported.	Call volumes; abandonment; alternative-channel utilisation; customer wait times; vulnerable-customer outcomes.	Diversify customer-assistance channels and stress-test surge arrangements.	Telecom resilience tests; contact-centre exercise; capacity evidence.
CBS-1.16	Alternative Account Access and Continuity Processing	Shared infrastructure or authentication dependency defeats alternative arrangements.	Minimum service must remain viable even where the primary channel is unavailable; alternative arrangements must function within tolerance.	At least one sufficiently independent access route remains available or can be activated within the required timeframe.	Dependency failures; alternative capacity; activation times; customer coverage; transaction success rates.	Remove or mitigate hidden common dependencies and increase alternative capacity.	Dependency map; architecture review; integrated test results; remediation closure.
CBS-1.17	Deposit Account Processing Recovery and Reconciliation	Primary and DR failure; configuration drift; concentration of shared infrastructure.	CBS-1 must still have a credible recovery path to prevent disruption beyond the approved tolerance.	Secondary recovery decision made promptly; customer harm managed; data remains recoverable and reconcilable.	DR failure logs; decision times; backlog; recovery estimates; evidence of alternative recovery.	Develop and validate recovery options beyond the primary DR assumption.	DR tests; configuration validation; alternative recovery exercise; Internal Audit/assurance evidence.
CBS-1.18	Account Access Service Restoration and Validation	Premature restoration, residual defects and data inconsistency.	CBS-1 is not considered restored until stable end-to-end service and data integrity are demonstrated, with cumulative disruption remaining within tolerance.	Restoration gates prevent premature reopening; balances, interfaces, authentication and channels validated before closure.	Stability data; reconciliation results; repeat incidents; service availability; restoration approvals; customer complaints.	Establish formal CBS-level restoration acceptance criteria and stability period.	Approved restoration checklist; sign-offs; post-test report; independent validation; closure evidence.

Integrated End-to-End Scenario Tests

The tables above provide traceability for every Sub-CBS, but MBSB should not execute these as 18 independent exercises. Doing so could recreate the siloed testing that Operational Resilience is intended to overcome.

A more effective programme would group the Sub-CBS into several integrated tests.

Integrated Test	Principal Sub-CBS	Scenario	Primary Capability Tested
ST-1 Core Processing and Recovery	CBS-1.4, 1.5, 1.12, 1.17, 1.18	Primary processing outage + degraded DR + transaction backlog	End-to-end recovery, reconciliation and controlled restoration
ST-2 Digital Access and Authentication	CBS-1.6, 1.8, 1.9, 1.10, 1.13	Digital disruption + IAM failure + delayed monitoring	Multi-channel access, authentication resilience and detection
ST-3 Cyber Compromise and Account Protection	CBS-1.3, 1.11, 1.12, 1.14	Privileged compromise/ransomware + account restrictions + integrity concern	Cyber containment, customer protection and crisis decisions
ST-4 Customer Continuity Under Multi-Channel Failure	CBS-1.6, 1.15, 1.16	Digital outage + telecommunications failure + alternative-channel stress	Minimum customer service and alternative delivery
ST-5 Data and Customer Record Integrity	CBS-1.2, 1.7, 1.12, 1.18	Data corruption + replicated error + restoration pressure	Integrity, reconciliation and safe restoration
ST-6 Peak Transaction Disruption	CBS-1.4, 1.5, 1.8, 1.12	Salary-credit peak + processing/interface failure	Peak-period customer harm, capacity and transaction recovery
ST-7 Service Initiation and Operational Backlog	CBS-1.1, 1.2, 1.10	Onboarding failure + customer-data issue + exception backlog	Operational fallback, backlog management and controlled recovery

This approach provides both Sub-CBS coverage and end-to-end service testing.

Detailed Design of an End-to-End CBS-1 Test

For the highest-value annual or major-cycle test, MBSB could use ST-1 Core Processing and Recovery as the principal end-to-end exercise.

Starting Condition

CBS-1 is operating normally during a high-volume banking period. Customer use of digital banking, payments and cash services is elevated.

T+0 — Primary Failure

The primary account-processing environment becomes unavailable.

MBSB should demonstrate:

Detection → Incident Declaration → CBS Impact Assessment → Escalation → Recovery Decision

T+30 Minutes — Failover Complication

The designated recovery environment starts successfully but cannot sustain full transaction volume.

The test should measure:

capacity;
transaction latency;
backlog;
customer population affected;
interconnected CBS degradation; and
remaining time to Impact Tolerance.

T+60 Minutes — Customer Impact Escalates

Digital enquiries and transaction requests fail intermittently. Contact-centre demand increases significantly.

Management must decide which services receive priority for recovery.

T+90 Minutes — Data Integrity Concern

Reconciliation identifies inconsistencies between queued transactions and recovered account balances.

This should force a decision between:

faster availability over safe, trustworthy restoration.

T+120 Minutes — Alternative Access Constraint

An alternative customer-access arrangement reaches its capacity threshold.

Management must determine whether additional customer-protection measures are required.

T+180 Minutes — Recovery Decision Point

Technology reports that full restoration may occur close to the illustrative four-hour Impact Tolerance.

Senior management should assess:

customer harm;
vulnerable customers;
transaction backlog;
account integrity;
alternative-channel viability;
interconnected CBS impacts;
regulatory implications; and
confidence in recovery.

T+240 Minutes — Impact Tolerance Boundary

The exercise determines whether CBS-1:

Remained Within Tolerance

Breached / Would Have Breached Tolerance

The exercise should not be artificially stopped merely because the four-hour point has been reached.

If necessary, it should continue into service restoration and reconciliation to determine the full customer and operational consequences.

Participants and Governance

Scenario Testing for CBS-1 should be cross-functional. Depending on the scenario, participants should include representatives from:

CBS-1 business ownership;
Deposit and Account Operations;
Digital Banking;
Technology Operations;
Application Support;
Infrastructure and Network teams;
Cybersecurity/Security Operations;
Identity and Access Management;
Business Continuity Management;
Operational Resilience;
Operational Risk;
Technology/ICT Risk;
Fraud Management;
Customer Service and Contact Centre;
Crisis Management;
Compliance;
Third-Party Risk Management;
Communications;
relevant external providers; and
senior management.

For major tests, independent observers from Internal Audit or an independent assurance function may add value without assuming management responsibility for the exercise.

Test controllers should remain separate from operational participants so that scenario injects, timing and evidence can be managed objectively.

Scenario Testing Success Criteria

A Scenario Test should not receive a simple "Pass" merely because systems eventually recovered.

MBSB should assess performance against several dimensions:

Dimension	Success Criterion
Impact Tolerance	CBS-1 remains within the approved tolerance or the test clearly identifies why it would not.
Customer Outcome	Minimum acceptable customer access is preserved or restored before intolerable harm.
Detection	Material CBS degradation is identified sufficiently early.
Escalation	Appropriate decision-makers are engaged within defined thresholds.
Dependencies	Known dependencies perform as expected; previously unknown dependencies are identified.
Alternative Arrangements	Workarounds operate at realistic stressed volumes.
Cyber Resilience	Security containment and service continuity are appropriately balanced.
Data Integrity	Customer balances and transactions remain trustworthy or are validated before restoration.
Recovery	Recovery arrangements work under scenario conditions rather than only under ideal test conditions.
Third Parties	External providers meet the operational capability required by CBS-1.
Communications	Customers and relevant stakeholders receive timely and appropriate information.
Restoration	End-to-end service is validated before the incident is declared resolved.

A test that exposes significant weaknesses can therefore still be a successful resilience exercise if those weaknesses are accurately identified, escalated and remediated.

Evidence and Test Record

Each major CBS-1 test should produce a structured evidence package.

A practical audit trail is:

[OR] [PM] [E3] [ST] [CBF] Evidence and Test Record This evidence chain is important because Operational Resilience testing should demonstrate not only that an exercise occurred, but also what was learned and what changed as a result.

Cyber and ICT Risk Integration

Cyber and ICT Risk should not form a separate parallel testing programme disconnected from CBS-1. Instead, technology and cyber failures should be treated as disruption mechanisms that affect customer service.

For example:

Ransomware

→ Technology environments isolated

→ CBS-1.5 processing affected

→ CBS-1.12 data integrity questioned

→ CBS-1.14 crisis decisions required

→ CBS-1.17 recovery delayed

→ Customer access deteriorates

→ Impact Tolerance threatened

Similarly:

IAM Failure

→ CBS-1.9 authentication unavailable

→ CBS-1.6 customer enquiries inaccessible

→ CBS-1.8 customer instructions cannot proceed

→ CBS-1.10 exceptions increase

→ CBS-1.15 support demand increases

→ CBS-1 becomes unavailable despite healthy core processing

This service-oriented perspective is particularly important given BNM's observation that technology and third-party failures can propagate quickly through the financial ecosystem and that RMiT requirements address system availability, security controls, recovery capability and failover arrangements.

Regulatory Considerations for Scenario Testing by a Malaysian Financial Services Institution

Status of the 2025 Discussion Paper

The BNM document was issued on 19 December 2025 as a Discussion Paper setting out BNM's emerging direction and key considerations for strengthening Operational Resilience.

It should therefore not be represented as though every discussion point constitutes a new binding requirement.

However, BNM explicitly links the emerging Operational Resilience framework with existing requirements covering BCM, RMiT, Outsourcing, Operational Risk, Responsibility Mapping, Risk Governance and Corporate Governance.

This distinction should be retained in MBSB's regulatory documentation.

Testing Against Severe but Plausible Scenarios

BNM's emerging direction states that financial institutions should assess whether critical services can withstand a broad range of scenarios that are sufficiently severe to expose deficiencies while remaining credible.

BNM specifically refers to challenging assumptions and anticipating multi-layered failures.

It also identifies a key lesson from operational disruptions: testing isolated failures is insufficient and scenario testing should incorporate concurrent events to provide a realistic view of vulnerabilities.

Implementation for MBSB: CBS-1 testing should therefore include compound scenarios rather than testing every Sub-CBS independently.

Testing Against Impact Tolerance

BNM identifies the importance of establishing a boundary between acceptable and unacceptable disruption, considering duration, customer or market harm and the minimum service that needs to be maintained.

Implementation for MBSB: Scenario Testing should record CBS-level measures throughout the exercise, rather than relying solely on application RTOs.

A CBS-1 dashboard during testing should therefore track at least:

Elapsed disruption time | Customers affected | Channels unavailable | Transaction backlog | Data integrity | Alternative service capacity | Customer harm | Recovery confidence | Remaining tolerance

Dependency Testing

BNM highlights that disruption can propagate through people, processes, data, technology, facilities and business units.

Mapping should reveal vulnerabilities, critical failure points, concentrations, and external dependencies.

Existing BCM requirements referenced by BNM also require financial institutions to identify and assess internal and external interdependencies and to capture outsourcing and third-party arrangements that support critical functions in continuity planning.

Implementation for MBSB: Scenario tests should deliberately remove or degrade selected dependencies identified during MII rather than assume they remain available.

Technology and Cyber Resilience

BNM identifies cyber incidents, technology failures, third-party outages, data compromise and power failures among sources of major operational disruption.

The Discussion Paper also refers to ransomware, destructive malware, third-party attacks and supply-chain vulnerabilities.

BNM cites examples of Malaysian disruptions, including mobile application outages due to inadequate mainframe storage, a core banking disruption following a failed disaster recovery test, and ransomware linked to weak cybersecurity controls.

These examples provide a credible regulatory context for MBSB to test capacity exhaustion, failed DR, ransomware and cross-channel disruption. They should not, however, be interpreted as prescribed BNM scenarios that every institution must test in exactly the same way.

Third-Party Resilience

BNM highlights growing dependencies on cloud providers, outsourced IT and operational functions, data centres and telecommunications, including concentration and substitutability risks.

Existing Outsourcing and RMiT requirements referenced in the Discussion Paper address risk assessment, contingency planning, technology provider oversight, continuity provisions, and cybersecurity monitoring.

Implementation for MBSB: Where a third party materially supports CBS-1, scenario testing should challenge the assumption that the provider will recover as contracted. Where practical and proportionate, critical providers should participate in relevant tests.

Peak-Period Testing

BNM observes that even short disruptions can cause disproportionate consumer harm during peak periods, such as salary credit periods or major retail events.

This is particularly relevant to CBS-1.

A four-hour outage at a low-volume period and a four-hour outage during salary credit or peak payment demand should not automatically be treated as equivalent scenarios.

MBSB should therefore include stressed demand conditions when validating its Impact Tolerance.

Board and Senior Management Oversight

BNM identifies Operational Resilience as a board-level priority and discusses Board involvement in approving critical services, setting impact tolerances, reviewing resilience-testing results and holding senior management accountable for resilience outcomes.

It also emphasises cross-functional oversight spanning technology, risk, operations, outsourcing and cybersecurity.

Accordingly, major CBS-1 test results should provide management and the relevant Board or Board Risk Committee with a concise view of:

[OR] [PM] [E3] [ST] [CBF] Board and Senior Management Oversight

Lessons Identified and Remediation

Scenario Testing is incomplete if the output is only an exercise report.

Each material observation should be classified and converted into a resilience action.

A useful structure is:

Finding	Example	Required Response
Critical vulnerability	No viable recovery route after primary and DR failure	Immediate remediation and senior-management escalation
Impact Tolerance weakness	Alternative channels cannot support minimum customer demand	Capacity/resilience investment
Dependency weakness	Primary and alternate services share IAM dependency	Architecture remediation or formal risk treatment
Recovery weakness	Transaction reconciliation exceeds available tolerance	Recovery-process redesign
Cyber resilience weakness	Containment decisions delay essential service unnecessarily	Cyber/OR playbook integration
People weakness	Only one specialist can execute critical recovery	Cross-training and succession capability
Third-party weakness	Provider recovery exceeds CBS tolerance	Provider remediation, alternative arrangement or risk treatment
Governance weakness	Incident escalation delayed by unclear authority	Governance and escalation redesign
Evidence weakness	Recovery assumed rather than technically demonstrated	Additional testing or independent assurance

Every material action should have an owner, priority, target completion date, residual-risk assessment and closure evidence.

BNM emphasises continuous learning, periodic review, updated testing and improvements to processes, architecture and governance as the environment evolves.

Continuous Scenario Testing Cycle

For MBSB, the testing lifecycle should operate as:

This converts Scenario Testing from a periodic compliance exercise into a continuous mechanism for improving Operational Resilience.

Recommended CBS-1 Scenario Testing Record

For implementation purposes, each test should have a formal Scenario Test Profile containing:

CBS: CBS-1 Customer Deposit and Account Access Services

Sub-CBS in Scope: Applicable CBS-1.x processes

Scenario: Approved Severe but Plausible Scenario

Impact Tolerance: Approved CBS-1 tolerance and secondary harm thresholds

Test Method: Tabletop / simulation / technical / DR / integrated / live

Starting Conditions: Defined operating environment at commencement

Dependencies Removed: People / process / technology / data / facility / third party

Participants: Business, technology, risk, cyber, BCM, crisis and other relevant functions

Scenario Timeline: T+0 through recovery and restoration

Injects: Progressive scenario developments

Decision Points: Required management decisions

Evidence: Defined records and measurements

Expected Outcome: Minimum service and recovery expectations

Actual Outcome: Observed service performance

Tolerance Result: Within / Approaching / Breached

Lessons Identified: Vulnerabilities and strengths

Remediation: Required actions

Accountable Owner: Named organisational role

Target Date: Agreed completion

Closure Evidence: Proof of implementation

Retest Requirement: Yes / No and planned date

This format provides a consistent audit trail across CBS-1 and can subsequently be replicated for MBSB's other Critical Business Services.

Banner [Summing] [OR] [E3] Perform Scenario Testing

Scenario Testing is essential because it enables MBSB to determine whether CBS-1 Customer Deposit and Account Access Services is resilient in practice rather than merely resilient by design.

Testing at Sub-CBS level provides detailed visibility into individual failure points, but the principal resilience judgement must remain at the end-to-end Critical Business Service level.

The relevant question is not whether CBS-1.5, CBS-1.9, or CBS-1.17 recovered successfully individually.

It is whether their combined performance allowed customers to continue receiving an acceptable level of CBS-1 within the approved Impact Tolerance.

Severe but Plausible Scenarios and Impact Tolerance therefore provide the two anchors for the programme:

The Severe but Plausible Scenario defines the stress MBSB must withstand; the Impact Tolerance defines the boundary MBSB must not exceed.

Cyber and ICT Risks strengthen the Scenario Testing programme when they are incorporated as causes and amplifiers of service disruption rather than tested in isolation.

Ransomware, DDoS, data corruption, IAM failures, network disruptions, failed technology changes, capacity exhaustion, infrastructure outages, and failed disaster recovery can all propagate through CBS-1's business processes and ultimately affect customers' ability to access their deposits.

Evidence generated through testing—system logs, recovery measurements, reconciliation results, decision records, customer-impact data, third-party performance and management actions—provides demonstrable evidence of MBSB's resilience preparedness and management oversight.

The final value of Scenario Testing, however, lies in what happens after the test.

Weaknesses should be identified as lessons; lessons should lead to accountable remediation actions; remediation should drive investment and risk treatment; and completed actions should be retested.

BNM's emerging Operational Resilience direction reinforces this continuous approach, emphasising severe-but-plausible assessment, cross-functional oversight, learning from disruptions and near misses, updated testing, and ongoing improvements.

For MBSB, completion of this stage therefore closes the five-stage implementation sequence for CBS-1:

Scenario Testing should ultimately provide MBSB's senior management and Board with evidence-based assurance on where CBS-1 can withstand disruption, where its resilience boundary lies, and where further action or investment is required to ensure customers can continue to access essential deposit and account services during severe disruption.

eBook 3: Starting Your OR Implementation
CBS-1 Customer Deposit and Account Access Services
CBS-1 DP	CBS-1 MII	CBS-1 ITo	CBS-1 SbPS	CBS-1 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.

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.



	If you have any questions, click to contact us.

Operational Resilience in Action: The MBSB Approach