A Severe but Plausible Scenario should not be a generic risk statement such as "system outage" or "cyberattack."
It should describe a credible disruption severe enough to challenge MBSB's normal preventive controls, continuity arrangements, recovery assumptions and management response.
The scenario should also establish a clear pathway from the initiating event through the affected Sub-CBS processes and dependencies to the potential customer impact.
This is consistent with Bank Negara Malaysia's 2025 Operational Resilience Discussion Paper.
BNM observes that testing isolated failures is no longer sufficient and highlights the need for severe yet reasonably plausible scenarios, including concurrent failures, which provide a more realistic view of vulnerabilities.
BNM also describes resilience as the ability of critical operations or services to withstand disruption within acceptable and tolerable levels under severe but plausible scenarios.
For CBS-1, the 18 previously identified Sub-CBS processes provide the detailed basis for scenario identification.
They enable MBSB to examine not only whether a particular application can recover but whether the entire chain required for customers to access their deposit accounts remains viable.
Cyber and ICT risks are incorporated directly into the scenarios because technology failure, ransomware, destructive malware, compromised data, third-party outages, network disruption and shared infrastructure failures can propagate rapidly across financial services.
BNM specifically highlights these forms of disruption and the growing dependence on real-time digital channels, cloud environments, APIs and telecommunications infrastructure.
The scenarios in this chapter should ultimately be tested against MBSB's approved Impact Tolerance for CBS-1.
For continuity with the preceding implementation chapter, the analysis uses the illustrative four-hour Impact Tolerance previously proposed for CBS-1, together with customer-scope, channel-availability and data-integrity thresholds. This remains an implementation assumption until formally validated and approved by MBSB.
The scenarios have been designed to provide a balanced portfolio of disruptions rather than 18 variations of a technology outage.
Collectively, they challenge:
The scenarios also deliberately include compound and cascading events.
This reflects BNM's observation that scenario assessment should challenge assumptions, anticipate multi-layered failures and validate whether critical services can endure the resulting disruption.
|
Sub-CBS Code |
Name of Sub-CBS |
Recommended Severe but Plausible Scenario |
Scenario Description |
Primary Disruption Trigger |
Impact on Sub-CBS |
Impact on Critical Business Service |
|
CBS-1.1 |
Deposit Account Establishment and Activation |
Digital Onboarding Failure During High-Volume Period |
A failed software deployment disrupts digital onboarding and account activation during a period of high application volume. The automated rollback is unsuccessful because the associated API version has also changed. Branch-assisted onboarding remains available but cannot absorb the displaced volume. |
Failed technology change combined with API incompatibility |
New accounts cannot be reliably established or activated; application backlogs and incomplete onboarding records accumulate. |
Existing deposit access remains largely available, but customers awaiting activation cannot obtain expected banking access. Prolonged disruption increases complaints, manual workload and customer detriment. |
|
CBS-1.2 |
Customer and Account Information Maintenance |
Customer Master Data Corruption |
A defective batch update corrupts selected customer contact details and account-maintenance records. The issue is not immediately apparent because processing completes without a technical failure alert. |
Data corruption following failed batch processing or software change |
Account information cannot be trusted until affected records are identified and corrected. |
Incorrect customer information may cause authentication problems, failed servicing, misdirected communications and inappropriate restrictions, with impacts propagating to other Sub-CBS. |
|
CBS-1.3 |
Account Status and Access Administration |
Privileged Access Compromise Causes Incorrect Account Restrictions |
Compromised privileged credentials are used to modify account status or restriction parameters across a significant customer population. Emergency security measures require temporary suspension of automated status changes while the compromise is investigated. |
Privileged account compromise |
Account status information becomes unreliable and large numbers of legitimate customers may be incorrectly restricted. |
Customers may be unable to access funds despite core account processing remaining operational. Security investigation may prolong restoration. |
|
CBS-1.4 |
Deposit Receipt and Account Credit Processing |
Incoming Credit Processing Failure on Salary-Credit Day |
A transaction interface failure prevents a large volume of incoming credits from posting to customer accounts during a peak salary-credit period. Queued transactions continue accumulating while customers expect immediate availability of funds. |
Transaction interface/API or middleware failure during peak processing |
Valid deposits and incoming credits remain unposted or delayed. |
Customers may lack access to expected funds for essential expenditure. Customer harm can develop substantially faster during the peak period. |
|
CBS-1.5 |
Account Balance and Transaction Record Processing |
Core Account Processing Outage with Capacity Failure at Recovery Site |
The primary account-processing environment becomes unavailable. Failover begins, but the recovery environment experiences capacity degradation under the full production workload, causing intermittent processing and unstable balance enquiries. |
Major ICT infrastructure failure compounded by inadequate recovery capacity |
Account balances and transaction processing become unavailable or unreliable. |
CBS-1 may become unavailable across several channels simultaneously. Payment, cash and digital services dependent on the same account records may also degrade, creating a high probability of an Impact Tolerance breach. |
|
CBS-1.6 |
Customer Account Enquiry and Information Access |
Coordinated DDoS Against Digital Account Access |
A sustained DDoS attack overwhelms internet-facing account-access services. Customers migrate to contact-centre and branch channels, creating severe secondary capacity pressure. |
Distributed Denial-of-Service attack |
Customers cannot reliably retrieve balances or transaction histories digitally. |
Widespread inability to verify account positions, combined with overloaded alternatives, can result in effective loss of account access and rapid customer dissatisfaction. |
|
CBS-1.7 |
Account Statement and Transaction Information Provision |
Statement Repository and Archive Unavailable |
A storage or infrastructure failure makes current and historical account statements unavailable while transaction processing continues normally. Recovery is delayed because the replicated repository contains the same corrupted index. |
Storage/database failure with replicated logical corruption |
Statements and historical transaction information cannot be generated or retrieved. |
Immediate access to funds remains available, but prolonged failure affects reconciliation, disputes, financial administration and potentially regulatory or evidentiary requirements. |
|
CBS-1.8 |
Account Access Request and Instruction Processing |
API Gateway and Middleware Disruption |
A network-routing or middleware failure prevents instructions from digital and assisted channels from reaching downstream account-processing services. Core account systems remain operational. |
API, middleware or network-routing failure |
Customer instructions are received at the channel but cannot be successfully routed for processing. |
Customers perceive the account service as unavailable despite healthy core processing. Repeated attempts may create duplicate-risk and backlog issues during recovery. |
|
CBS-1.9 |
Account Access Validation and Control |
Common Identity and Authentication Platform Failure |
A shared identity and authentication capability fails following a configuration change. Mobile, internet and selected assisted channels all rely on the same service, creating a common-mode access failure. |
Identity and Access Management failure following failed change |
Legitimate customers cannot be authenticated or authorised. |
Multiple customer channels become inaccessible simultaneously. CBS-1 may breach its Impact Tolerance even though account processing remains fully operational. |
|
CBS-1.10 |
Account Access Exception and Rejection Management |
Exception Surge Combined with Case-Management Failure |
A channel release causes an abnormal increase in rejected account access requests at the same time the case-management platform becomes unavailable. Operational teams cannot effectively distinguish isolated failures from systemic defects. |
Failed software deployment plus case-management outage |
Exceptions accumulate and cannot be prioritised, diagnosed or resolved efficiently. |
Customers remain locked out for longer, while delayed recognition of the common defect allows the affected population to expand. |
|
CBS-1.11 |
Account Restriction and Access Restoration |
Fraud Event Causes Mass Precautionary Restrictions |
A significant credential-compromise campaign prompts MBSB to impose precautionary restrictions on a large number of accounts. Customer verification and restoration capacity becomes overwhelmed. |
Large-scale cyber-enabled credential compromise |
Legitimate and suspicious accounts require rapid review, restriction and controlled restoration. |
A large customer population may remain unable to access funds while MBSB protects accounts against fraud. The security-versus-availability trade-off directly challenges the Impact Tolerance. |
|
CBS-1.12 |
Deposit Account Reconciliation and Integrity Management |
Transaction Data Integrity Compromise |
Following an application failure, MBSB discovers discrepancies between transaction source records and posted account balances. The extent of the corruption is initially unknown and affects both the production and replicated datasets. |
Data corruption or database integrity failure |
Reconciliation teams cannot establish authoritative account balances within normal timelines. |
CBS-1 cannot safely be considered restored even if applications are technically available. Material uncertainty over customer balances could constitute intolerable harm before the time threshold is reached. |
|
CBS-1.13 |
Account Access Service Monitoring and Exception Escalation |
Monitoring Blind Spot Delays Recognition of Widespread Degradation |
A monitoring platform configuration error suppresses critical alerts while account access response times progressively deteriorate. Customer complaints become the first reliable indication of a major service problem. |
Failure of monitoring and detection controls |
Operational teams lack timely visibility of service degradation and do not escalate promptly. |
Valuable response time is lost, customer impact grows and MBSB has less time to recover before the Impact Tolerance is reached. |
|
CBS-1.14 |
Customer Account Access Incident Management |
Major Cyber Incident with Conflicting Recovery Priorities |
Ransomware affects several technology environments. Security teams prioritise containment while operations seek rapid restoration. Incomplete situational information creates conflicting recovery decisions and delayed executive escalation. |
Ransomware affecting interconnected systems |
Cross-functional incident coordination, decision-making and recovery sequencing are severely challenged. |
Poorly coordinated containment and recovery may prolong CBS-1 disruption, affect other CBSs and cause the Impact Tolerance to be exceeded. |
|
CBS-1.15 |
Disrupted Account Access Customer Assistance |
Contact Centre Loss During Digital Banking Outage |
A widespread telecommunications failure affects the primary contact centre, while a separate digital service disruption is already preventing customers from accessing their accounts online. |
Telecommunications failure combined with digital-channel disruption |
Customer assistance capacity becomes severely constrained when demand is at its highest. |
Customers lose both normal account access and an important means of obtaining support or alternative instructions. Vulnerable customers may experience disproportionate harm. |
|
CBS-1.16 |
Alternative Account Access and Continuity Processing |
Primary and Alternative Channels Share a Failed Dependency |
Following the loss of normal digital account access, MBSB activates alternative arrangements but discovers that both the primary and alternate channels depend on the same network, authentication, or account information component. |
Technology concentration/common dependency failure |
Approved continuity arrangements cannot provide the expected alternative access. |
The absence of a genuinely independent workaround can cause rapid escalation toward an Impact Tolerance breach and expose weaknesses in dependency mapping. |
|
CBS-1.17 |
Deposit Account Processing Recovery and Reconciliation |
Primary and Disaster Recovery Processing Failure |
A major production outage triggers disaster recovery, but the failover is unsuccessful due to configuration inconsistencies or latent failures in the recovery environment. Transaction queues continue accumulating while recovery teams investigate. |
Simultaneous primary and disaster recovery failure |
Normal processing cannot resume and the assumed recovery path is unavailable. |
Outage duration can extend beyond the CBS tolerance. Payment, digital and cash-related services dependent on account processing may experience cascading disruption. |
|
CBS-1.18 |
Account Access Service Restoration and Validation |
Premature Restoration Followed by Secondary Failure |
After a prolonged outage, account services are restored under management pressure before transaction reconciliation and stability testing are complete. Latent interface problems generate duplicate or missing postings and force a second outage. |
Delayed recovery followed by premature restoration |
Restoration cannot be validated and the service must be withdrawn again for corrective action. |
Customer harm is compounded by repeated disruption and uncertainty over account information. The combined elapsed disruption may exceed the Impact Tolerance and damage confidence in recovery capability. |
|
Sub-CBS Code |
Name of Sub-CBS |
Interconnections and Interdependencies Challenged |
Cyber and ICT Risk Linkage |
Potential Impact Tolerance Breach |
Proactive Risk Management Action |
Evidence of Proactive Risk Management |
Scenario Testing Objective |
|
CBS-1.1 |
Deposit Account Establishment and Activation |
Customer onboarding; customer records; identity verification; core account platform; CBS-8 Customer Transaction Authentication and Authorisation Services |
Failed change and API incompatibility are triggers; technology concentration can amplify the outage. |
Possible but lower immediate likelihood. More likely if activated accounts containing customer funds are also inaccessible. |
Implement end-to-end pre-production testing, rollback validation, API compatibility controls and scalable alternate onboarding arrangements. |
Change risk assessment; regression-test results; rollback test evidence; API monitoring; continuity exercise; management approval. |
Demonstrate that MBSB can contain failed onboarding changes and maintain or restore account activation without creating an uncontrolled backlog. |
|
CBS-1.2 |
Customer and Account Information Maintenance |
Customer master data; CRM; account platform; authentication and servicing processes |
Data corruption is the principal trigger; delayed detection amplifies downstream effects. |
Possible. Could contribute when corrupted records cause widespread account access failures. |
Implement integrity validation, controlled batch changes, reconciliation, immutable audit trails and tested data restoration. |
Data-integrity test results; batch-control reports; database recovery tests; audit logs; remediation records. |
Determine whether corrupted customer data can be identified, isolated and restored before it materially affects account access. |
|
CBS-1.3 |
Account Status and Access Administration |
Account controls; fraud/compliance functions; CBS-8; customer-access channels |
A privileged access compromise is the trigger; the access-control architecture determines propagation. |
High potential if large customer populations are incorrectly restricted. |
Strengthen privileged-access management, dual control, behavioural monitoring and rapid bulk reversal capability. |
Privileged-access reviews; SOC records; access-control testing; cyber simulation results; exception reports. |
Test whether unauthorised account-status changes can be detected and safely reversed at scale. |
|
CBS-1.4 |
Deposit Receipt and Account Credit Processing |
CBS-2 Domestic Funds Transfer and Payment Services; CBS-4 Cash Access and Cash Transaction Services; transaction interfaces; reconciliation |
Interface, middleware or queue failure initiates the scenario; peak capacity amplifies harm. |
High potential, particularly during salary or other peak-credit periods. |
Establish resilient transaction interfaces, queue monitoring, alternate processing paths and peak-period capacity testing. |
Interface failover reports; capacity tests; reconciliation evidence; incident playbooks; management peak-period readiness review. |
Verify that incoming customer funds can be posted or safely queued and recovered before unacceptable customer harm occurs. |
|
CBS-1.5 |
Account Balance and Transaction Record Processing |
Core account platform; databases; integration services; CBS-2, CBS-3, CBS-4, CBS-6 and CBS-7 |
Infrastructure failure is the trigger; recovery capacity and technology concentration amplify the event. |
Very High potential. This scenario could rapidly breach the four-hour illustrative tolerance. |
Test production-scale recovery capacity; remove single points of failure; strengthen database resilience and validate cross-CBS recovery sequencing. |
Architecture resilience review; DR test; load/capacity test; failover report; independent assurance; remediation register. |
Demonstrate that recovered infrastructure can sustain full production demand and support all critical interconnected services. |
|
CBS-1.6 |
Customer Account Enquiry and Information Access |
CBS-3 Digital Banking Services; CBS-8; telecommunications; contact centre; branches |
DDoS is the trigger; channel concentration and inadequate surge capacity amplify disruption. |
High potential where digital loss combines with inadequate alternatives. |
Strengthen DDoS protection, alternative-channel capacity, network diversity and customer-demand surge planning. |
DDoS simulation; capacity testing; network resilience tests; contact-centre stress test; cyber monitoring reports. |
Test whether customers retain sufficient access to reliable account information while the primary digital channel is unavailable. |
|
CBS-1.7 |
Account Statement and Transaction Information Provision |
Account data; document repository; CBS-3; customer servicing |
Storage/database failure initiates the event; replicated logical corruption may defeat normal recovery. |
Low-to-Medium potential in isolation, but increases with prolonged outage or wider data problems. |
Maintain independently recoverable statement data, test logical corruption recovery and provide alternate transaction-history access. |
Backup restoration results; repository DR test; data-integrity tests; recovery procedures. |
Establish whether statement and historical information can be restored without compromising current account-access priorities. |
|
CBS-1.8 |
Account Access Request and Instruction Processing |
Customer channels; middleware; core account processing; CBS-3 and CBS-8 |
API, network and middleware failure are direct triggers. |
High potential if all major channels use the same routing layer. |
Implement resilient middleware, alternate routing, queue integrity controls and end-to-end synthetic transaction monitoring. |
Architecture review; API failover test; synthetic monitoring; queue reconciliation; penetration and resilience testing. |
Determine whether instructions can continue through alternative routes or be safely recovered without duplication or loss. |
|
CBS-1.9 |
Account Access Validation and Control |
Shared authentication; IAM; CBS-3; CBS-8; branch and assisted channels |
IAM failure is the trigger and a common technology dependency amplifies impact across channels. |
Very High potential. CBS-1 may become unavailable even though account processing remains healthy. |
Remove avoidable common-mode authentication dependencies; establish resilient authentication and emergency controlled-access arrangements. |
IAM failover results; architecture assessment; cyber exercise; access-control tests; management risk acceptance. |
Validate that a shared authentication failure does not eliminate all viable customer account-access routes. |
|
CBS-1.10 |
Account Access Exception and Rejection Management |
Customer channels; case management; application support; CBS-8 and CBS-9 |
Failed release triggers access exceptions; case-management failure acts as an amplifier. |
Medium-to-High potential where systemic failure remains undetected. |
Establish independent exception monitoring, manual case fallback, surge staffing and release kill-switch/rollback criteria. |
Release test records; exception dashboards; continuity tests; rollback evidence; incident simulation. |
Test MBSB's ability to identify the common cause, prioritise affected customers and prevent exception backlogs from becoming systemic. |
|
CBS-1.11 |
Account Restriction and Access Restoration |
Fraud management; authentication; account controls; customer service; CBS-8 and CBS-9 |
Credential compromise triggers security restrictions; restoration capacity becomes the operational constraint. |
High potential, especially where restrictions affect a material customer population. |
Predefine mass-compromise playbooks, scalable verification arrangements, automated prioritisation and restoration capacity. |
Cyber threat assessment; incident playbook; simulation report; capacity analysis; Board/management reporting. |
Determine whether MBSB can protect accounts from fraud while restoring legitimate access quickly enough to remain within tolerance. |
|
CBS-1.12 |
Deposit Account Reconciliation and Integrity Management |
Transaction records; ledger; core account data; payment interfaces; CBS-2, CBS-4, CBS-6 and CBS-7 |
Data corruption is the trigger; replicated corruption may defeat conventional recovery. |
Very High potential. Material balance uncertainty may constitute an immediate tolerance breach regardless of elapsed time. |
Maintain independent transaction evidence, immutable logs, data-integrity controls and tested point-in-time recovery and reconciliation. |
Data-integrity tests; reconciliation reports; backup validation; recovery exercises; independent assurance. |
Demonstrate that MBSB can establish authoritative balances and transaction positions following a material integrity event. |
|
CBS-1.13 |
Account Access Service Monitoring and Exception Escalation |
Monitoring platforms; service management; operations; cybersecurity; customer complaints |
Monitoring-control failure is the trigger; absence of end-to-end observability amplifies disruption. |
High contribution potential because delayed detection consumes the available tolerance. |
Deploy independent service-level monitoring, synthetic transactions, tested alerts and customer-impact dashboards. |
Alert tests; monitoring coverage assessment; incident detection metrics; SOC records; control-testing reports. |
Determine whether MBSB detects CBS-level degradation early enough to preserve sufficient time for response and recovery. |
|
CBS-1.14 |
Customer Account Access Incident Management |
Technology; cyber; operations; BCM; crisis management; senior management; CBS-3, CBS-4, CBS-8 and CBS-9 |
Ransomware is the trigger; incomplete information and competing containment/recovery objectives amplify the incident. |
Very High potential. Poor coordination can turn a contained event into a prolonged service failure. |
Conduct integrated cyber-resilience and crisis exercises; establish decision authorities, recovery priorities and minimum-service objectives. |
Cyber exercise report; crisis-management exercise; incident playbook; decision logs; Board/management review; remediation tracker. |
Validate cross-functional decisions under uncertainty and determine whether containment and recovery can protect CBS-1 within tolerance. |
|
CBS-1.15 |
Disrupted Account Access Customer Assistance |
Contact centre; branches; telecommunications; CBS-3 and CBS-9 |
A telecommunications outage is a trigger; digital disruption and a surge in customer demand amplify the event. |
High potential, particularly for vulnerable customers and where no viable alternative assistance exists. |
Diversify communication channels, establish alternate contact-centre capability and test surge and vulnerable-customer arrangements. |
Telecom resilience test; contact-centre BCP exercise; capacity results; customer-communication exercise; action tracker. |
Confirm that customers can obtain timely information and assistance even when primary digital and contact-centre services fail together. |
|
CBS-1.16 |
Alternative Account Access and Continuity Processing |
Alternative channels; authentication; network; account data; CBS-3, CBS-4, CBS-8 and CBS-9 |
Technology concentration is the key amplifier; a supposedly alternative service shares the original failure point. |
Very High potential. Failure removes the mechanism intended to prevent a tolerance breach. |
Perform dependency-diversity assessment, eliminate hidden common dependencies where feasible and test alternatives under realistic demand. |
Dependency map; architecture review; continuity test; capacity test; risk acceptance; remediation plan. |
Prove that alternative arrangements are genuinely operationally independent enough to preserve minimum CBS-1 delivery. |
|
CBS-1.17 |
Deposit Account Processing Recovery and Reconciliation |
Primary/recovery infrastructure; databases; network; specialist personnel; interconnected payment and digital CBSs |
DR failure is the trigger; configuration drift, replication problems or shared infrastructure may amplify the outage. |
Very High potential. Extended loss of both primary and recovery environments is likely to exceed tolerance. |
Perform unannounced or production-representative DR testing, configuration validation, recovery-environment monitoring and alternate recovery planning. |
DR test reports; configuration-comparison records; failover evidence; recovery capacity tests; Internal Audit/independent assurance. |
Establish whether CBS-1 can be recovered when the assumed primary recovery solution is itself unavailable. |
|
CBS-1.18 |
Account Access Service Restoration and Validation |
Reconciliation; core account platform; customer channels; authentication; monitoring; incident management |
Premature restoration and residual technology defects are amplifiers following the original outage. |
Very High potential. Repeated failures can push cumulative disruption beyond tolerance and cause data-integrity harm. |
Establish formal end-to-end restoration gates, data-integrity sign-off, stability periods and senior management acceptance criteria. |
Restoration checklist; reconciliation sign-off; stability-monitoring report; post-incident review; management approval; independent review. |
Confirm that "technology recovered" is not treated as "CBS restored" until end-to-end customer service and data integrity have been validated. |
The individual Sub-CBS scenarios should not be treated as 18 unrelated tests. They form a portfolio that challenges the entire CBS-1 service architecture.
A mature testing programme should combine them into several end-to-end scenario families.
Combines:
Example pathway:
This challenges the notion that technical recovery translates into the actual restoration of customer service.
Combines:
Example pathway:
This tests common-mode dependency risk.
Combines:
Example pathway:
This tests the trade-off between rapid availability and secure restoration.
Combines:
Example pathway:
This tests whether MBSB can continue protecting customer outcomes when multiple customer-facing channels are impaired.
Combines:
Example pathway:
BNM specifically notes that even relatively short disruptions may cause disproportionate customer harm during peak periods, such as salary credit periods or major retail events.
An important distinction should be maintained when using the 2025 BNM Operational Resilience Discussion Paper.
The document, issued on 19 December 2025, outlines BNM's emerging direction and key considerations for strengthening Operational Resilience. It was issued as a Discussion Paper seeking industry feedback; therefore, not every concept discussed in it should automatically be represented as a binding new regulatory requirement.
At the same time, the Discussion Paper connects Operational Resilience with existing BNM policy requirements covering areas such as BCM, technology risk, outsourcing, operational risk, responsibility mapping, risk governance, and corporate governance.
Accordingly, this chapter distinguishes between:
BNM's stated emerging Operational Resilience direction and existing regulatory expectations, and
implementation recommendations proposed in this guide for MBSB.
BNM's Discussion Paper identifies preservation of critical operations and services as a foundational Operational Resilience capability.
It emphasises that financial institutions should prioritise services essential to customers and stakeholders, as failure can harm customers, create contagion risks, and undermine confidence.
This is directly relevant to CBS-1 because BNM separately observes that consumers have particularly low tolerance for disruption to services affecting access to their funds, including mobile and online banking and real-time payments.
Implementation implication for MBSB: Scenario severity should therefore be assessed primarily by the resulting loss of customer deposits and account access, rather than solely by the technical severity of the initiating event.
BNM describes mapping internal and external interdependencies as important because disruption can propagate across people, processes, data, technology, facilities and business units. Mapping enables identification of vulnerabilities, concentration and critical points of failure.
Existing BCM requirements also include identification and assessment of internal and external interdependencies, including people, processes and technology, while relevant outsourcing arrangements supporting critical functions should be captured in continuity planning.
Implementation implication for MBSB: The previously completed CBS-1 interconnection and interdependency map should be used directly when selecting scenarios. High-concentration dependencies should receive greater attention in scenario testing.
BNM's Discussion Paper describes the need to understand the boundary between acceptable and unacceptable disruption, including duration, customer or market impact and the minimum level of service that should be maintained.
It also notes that traditional internal measures such as MTD and RTO remain necessary but may not be sufficient.
Implementation implication for MBSB: Each scenario should therefore test whether CBS-1 remains within its approved service-level Impact Tolerance rather than simply asking whether individual applications recover within their RTOs.
BNM expressly discusses assessing critical services under scenarios sufficiently severe to reveal deficiencies while remaining credible. It highlights challenging assumptions and anticipating multi-layered failures.
The Discussion Paper also states that testing isolated failures is no longer sufficient and calls for incorporating concurrent scenarios to provide a more realistic view of vulnerabilities and failure events.
This provides a strong basis for MBSB to include combined scenarios such as:
These combinations are implementation recommendations derived from the BNM direction; they should not be described as individually mandated BNM test scenarios unless expressly prescribed elsewhere.
The Discussion Paper itself refers to several types of actual disruption relevant to scenario design.
BNM identifies operational disruption arising from:
It discusses risks from ransomware, destructive malware, attacks through third-party providers, software supply chains and coordinated multi-entity attacks.
BNM also cites examples such as an IT migration failure causing prolonged service disruption, a failure of core payment and securities settlement infrastructure, and a major regional blackout affecting branches and self-service/payment terminals.
In the Malaysian context, the Discussion Paper specifically refers to recent examples including:
These examples support the credibility of scenarios involving technology capacity, failed recovery, ransomware and cross-channel disruption.
BNM highlights increasing reliance on cloud services, outsourced operational and IT functions, fintech partners, data centres and telecommunications networks.
It notes that shared infrastructure can create concentration and systemic risks, and that substitutability can be difficult when dependencies are opaque, or providers are highly specialised.
The Discussion Paper also identifies the importance of contingency arrangements for critical third-party services and notes existing requirements for third-party risk assessment, continuity provisions, and monitoring.
Implementation implication for MBSB: A severe third-party scenario should not assume that contractual SLA compliance guarantees MBSB's resilience. Testing should determine what MBSB can actually do when the provider cannot recover within the CBS Impact Tolerance.
BNM notes that technology failures, cyber incidents, and disruptions at critical third parties can propagate quickly through the financial ecosystem.
The Discussion Paper identifies system availability, security controls, recovery capability and failover arrangements as important technology-resilience areas under existing RMiT requirements.
For CBS-1, this means Cyber and ICT scenarios should test not merely the effectiveness of security controls but also the resulting ability to continue delivering account access.
The sequence should be considered as:
Cyber/ICT Event
↓
Technology or Data Impact
↓
Affected Sub-CBS
↓
Propagation Across Dependencies
↓
Customer Service Impact
↓
Impact Tolerance Position
↓
Response and Recovery Decision
This is what integrates Cyber and ICT Risk into Operational Resilience rather than treating it as a separate technical risk exercise.
BNM's Discussion Paper states that Operational Resilience should be a board-level priority and identifies Board involvement in approving critical services, setting impact tolerances, reviewing resilience testing results and holding senior management accountable for resilience outcomes.
It also emphasises the cross-functional nature of resilience across technology, operations, risk, outsourcing and cybersecurity.
For MBSB, scenario-test reporting should therefore allow senior management and the appropriate Board or Board Risk Committee to understand:
Scenario testing should not be reduced to a technical pass/fail report.
Scenario identification itself can reveal weaknesses before an exercise is performed.
For each selected scenario, MBSB should undertake a pre-test resilience assessment addressing:
Where the assessment already identifies a material weakness, management should determine whether:
BNM's Discussion Paper recognises that architectural enhancements, redundancy, monitoring, and improved failover arrangements may require material investment and highlights the importance of informed governance decisions regarding technology investment and recovery capability.
Examples of auditable proactive evidence include:
The objective is to demonstrate that MBSB is actively managing identified resilience vulnerabilities before an actual disruption occurs.
The scenarios identified in this chapter provide the input to the next implementation stage: Perform Scenario Testing [ST].
The ultimate scenario-testing question should be:
A successful test is not necessarily one in which nothing fails. A valuable test may deliberately reveal that an assumed workaround, recovery solution or dependency does not perform as expected.
BCM Institute's Severe but Plausible Scenario methodology similarly emphasises the use of realistic yet demanding disruptions to expose vulnerabilities, challenge assumptions, and assess whether the Critical Business Service remains within its Impact Tolerance.
Management should evaluate more than technical recovery times.
For CBS-1, key observations should include:
|
Evaluation Area |
Management Question |
|
Detection |
Did MBSB recognise CBS-level disruption early enough? |
|
Escalation |
Was the correct management authority engaged promptly? |
|
Customer Harm |
How many customers were affected, for how long and with what consequences? |
|
Impact Tolerance |
Was the service maintained within the approved tolerance? |
|
Minimum Service |
Could MBSB maintain an acceptable minimum account-access capability? |
|
Dependencies |
Did any previously unknown dependency fail? |
|
Concentration |
Did several channels fail because they shared one component? |
|
Cyber Response |
Did security containment conflict with service continuity? |
|
Data Integrity |
Could MBSB establish authoritative customer balances and transaction records? |
|
Third Parties |
Did external providers respond and recover within MBSB's required timeframe? |
|
Alternative Arrangements |
Did workarounds operate at realistic customer volumes? |
|
Recovery |
Did technology recovery result in actual end-to-end CBS restoration? |
|
Communications |
Were customers, management, and relevant stakeholders informed appropriately? |
|
Decision-Making |
Were critical trade-offs made at the appropriate authority level? |
|
Lessons Learned |
Were weaknesses converted into accountable remediation actions? |
These observations should provide the basis for determining whether MBSB has demonstrated resilience, rather than merely demonstrated that documented recovery procedures exist.
Severe but Plausible Scenarios should evolve as MBSB's operating environment changes.
BNM's Discussion Paper states that Operational Resilience is not a one-off exercise and highlights periodic reviews, updated testing, and improvements to processes, architecture, and governance as the threat landscape changes.
Accordingly, MBSB should reconsider its scenario catalogue when there are material changes to:
A scenario that was sufficiently severe last year may no longer meaningfully challenge the organisation after resilience improvements have been implemented.
Conversely, technology consolidation or a new third-party dependency may create a concentration risk that requires a new scenario.
Severe but Plausible Scenarios provide MBSB with a mechanism to convert its understanding of CBS-1 Customer Deposit and Account Access Services into meaningful resilience challenges.
The Sub-CBS-level analysis strengthens scenario design by identifying precisely where disruption can enter the service chain, how it can propagate through interconnected processes and dependencies, and how individual failures can combine to threaten the end-to-end customer outcome.
The 18 scenarios developed in this chapter deliberately cover a balanced range of operational, technology, cyber, data, people, telecommunications, third-party, capacity, monitoring, continuity and recovery failures.
They also recognise that the most revealing resilience tests may involve multiple failures occurring simultaneously, rather than the isolated loss of a single system.
Cyber and ICT risks are embedded throughout the analysis because ransomware, DDoS, identity system failure, data corruption, failed technology change, network disruption, infrastructure failure, and technology concentration can directly result in customers losing access to their deposit accounts.
This reflects BNM's emerging Operational Resilience direction, which emphasises complex interdependencies, cyber threats, third-party dependencies, multi-layered failures and the need for credible scenario assessment.
The implementation pathway for CBS-1 can now be expressed as:
The next stage—Perform Scenario Testing [ST]—should therefore use these scenarios to challenge MBSB's actual operational capabilities, management decisions, alternative arrangements, recovery strategies and cross-functional coordination.
The purpose is not to prove that MBSB can prevent every disruption.
It is to determine whether, when a severe but credible disruption occurs, CBS-1 can continue to deliver an acceptable customer outcome within its Impact Tolerance—and, where it cannot, to identify precisely what must be strengthened before the weakness is exposed by a real event.
| 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.
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. |
||
|
|