Identifying Severe but Plausible Scenarios is an essential activity in determining whether MBSB can continue delivering CBS-2: Domestic Funds Transfer and Payment Services during significant operational disruption without exceeding its approved Impact Tolerance.
Scenarios must challenge the end-to-end payment outcome rather than merely demonstrate the recovery of individual applications or business processes.
The 24 previously identified Sub-Critical Business Services (Sub-CBS) provide the detailed basis for examining how disruptions originate, propagate through interconnections and dependencies, and affect customers, counterparties and payment infrastructure.
Cybersecurity and Information and Communications Technology (ICT) risks must be embedded in scenario design because cyberattacks, technology failures, data corruption, network outages and compromised access controls can initiate or amplify operational disruptions.
By combining process-level scenario identification with service-level Impact Tolerance assessment, MBSB can identify vulnerabilities, evaluate the effectiveness of its continuity arrangements and prioritise proactive resilience improvements.
The purpose of this chapter is to establish a structured portfolio of Severe but Plausible Scenarios that can subsequently be used to design, execute and evaluate Operational Resilience scenario tests for CBS-2.
The assessment covers the complete domestic payment lifecycle, including customer initiation, payment authorisation, validation, funds verification, processing, routing, execution, settlement, beneficiary credit, reconciliation, monitoring, exception handling, continuity and recovery.
A credible scenario should explain not only what fails, but also how the disruption develops, which dependencies become unavailable, how the disruption affects customer payment outcomes and whether MBSB can remain within its approved Impact Tolerance.
The 24 scenarios provide balanced coverage of operational, cyber, ICT, people, facilities, data, third-party, and external infrastructure disruptions.
Each scenario is assigned to a principal Sub-CBS, although the resulting disruption may affect several other processes and Critical Business Services.
MBSB should apply the following principles when identifying and approving scenarios:
The previous CBS-2 Impact Tolerance assessment proposed illustrative limits for initial scenario calibration.
|
Impact Tolerance Dimension |
Illustrative Assessment Boundary |
|
Maximum material disruption duration |
2 hours |
|
Minimum essential payment processing capacity |
50% of normal peak-hour throughput |
|
Maximum materially affected customer population |
10% of normally active payment customers during the relevant period |
|
Additional essential payment processing delay |
15 minutes, where consistent with applicable payment scheme requirements |
|
Payment integrity |
No knowingly unverified, duplicate or incorrect payment execution creating material financial harm |
|
Regulatory and settlement obligations |
No breach of applicable mandatory obligations |
Important: These figures are illustrative implementation assumptions, not verified MBSB tolerances or BNM-prescribed thresholds.
MBSB must validate and formally approve appropriate limits using its actual transaction volumes, customer-harm assessment, service requirements and applicable regulatory obligations.
For this chapter, a scenario can breach Impact Tolerance if it could exceed any approved service-level boundary. A two-hour outage limit does not permit unsafe payment processing, material financial-integrity failure or serious customer harm during the first two hours.
The 24 Sub-CBS processes are grouped into seven operational stages.
|
Operational Stage |
Sub-CBS Coverage |
Principal Scenario Themes |
|
Payment Initiation |
CBS-2.1–2.3 |
Channel disruption, instruction loss and validation failure |
|
Authentication and Validation |
CBS-2.4–2.7 |
Identity compromise, account controls, fraud screening and beneficiary integrity |
|
Funds and Payment Processing |
CBS-2.8–2.11 |
Ledger availability, payment processing, transaction posting and network routing |
|
Payment Execution and Settlement |
CBS-2.12–2.15 |
Internal transfer failure, external payment infrastructure, settlement and beneficiary credit |
|
Confirmation and Reconciliation |
CBS-2.16–2.18 |
Customer communication, financial reconciliation and records integrity |
|
Monitoring and Exception Handling |
CBS-2.19–2.21 |
Detection failure, exception backlog and dispute investigation |
|
Continuity and Recovery |
CBS-2.22–2.24 |
Escalation failure, continuity capability and controlled restoration |
The scenarios are intended to form a coherent portfolio.
You may test individual scenarios separately, but you should combine selected scenarios into more demanding exercises involving simultaneous or cascading failures.
The following table identifies one principal scenario for each Sub-CBS, including its initiating event, disruption pathway, and consequences for the end-to-end domestic payment service.
Table P5: Recommended Severe but Plausible Scenarios for CBS-2
|
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-2.1 |
Customer Payment Instruction Initiation |
Coordinated DDoS attack and digital channel overload |
During a peak domestic payment period, a sustained DDoS attack overwhelms internet-facing services while increased customer retries exhaust channel capacity. Branches cannot absorb all displaced transactions. |
Coordinated DDoS attack and capacity exhaustion |
Customers cannot submit instructions reliably; requests time out or remain pending. |
Widespread payment initiation failures, missed customer obligations and rapidly increasing channel demand. |
|
CBS-2.2 |
Payment Instruction Capture and Registration |
Payment message queue failure with duplicate submissions |
A failed infrastructure change interrupts message persistence, while customer retries generate duplicate submissions. Some accepted instructions have no reliable processing reference. |
Message broker failure following technology change |
Instructions are lost, duplicated or registered inconsistently. |
Customers face uncertain payment outcomes; duplicate processing and reconciliation risks increase. |
|
CBS-2.3 |
Payment Instruction Completeness Validation |
Defective payment validation rules are deployed across channels |
A routine software release introduces incorrect mandatory-field validation. During a high-volume period, valid payment instructions are rejected across digital and branch channels. |
Failed application change and inadequate regression testing |
Valid instructions fail completeness checks and enter exception workflows. |
Large numbers of otherwise legitimate payments are delayed, increasing backlogs and customer complaints. |
|
CBS-2.4 |
Customer Authentication and Payment Authorisation |
Identity platform compromise and authentication service suspension |
The bank detects suspicious privileged access activity in the shared authentication environment. The bank restricts affected authentication services while investigating possible compromise, preventing customers from authorising payments. |
Privileged access compromise or suspected identity platform intrusion |
Payment authorisation cannot proceed safely; corporate approval workflows are interrupted. |
Domestic transfers become unavailable across several channels; security and financial-integrity concerns may create immediate serious harm. |
|
CBS-2.5 |
Account Eligibility and Payment Limit Validation |
Corrupted account restriction and payment limit records |
An erroneous bulk update corrupts account eligibility and payment limit information. The problem is discovered only after valid transactions are rejected and inconsistent account-control decisions appear. |
Data integrity failure following a defective batch update |
Account eligibility and limit decisions become unreliable. |
Payments are blocked or incorrectly authorised; restoration requires validation of account-control data before processing resumes. |
|
CBS-2.6 |
Payment Fraud and Compliance Screening |
Fraud screening service outage during coordinated fraud attempts |
A critical screening service becomes unavailable while attackers attempt high-volume suspicious transfers. Management must choose between suspending affected payments and implementing approved restricted processing arrangements. |
Third-party screening disruption combined with elevated fraud activity |
Screening capacity is lost or severely degraded; payments accumulate pending risk decisions. |
Payment availability deteriorates while unauthorised processing could create significant financial and regulatory harm. |
|
CBS-2.7 |
Beneficiary and Payment Destination Validation |
Beneficiary verification interface manipulation |
A compromised integration component returns inconsistent beneficiary validation responses. Payments appear correctly formatted but cannot be confidently linked to the intended destinations. |
API compromise or corrupted beneficiary verification responses |
Beneficiary validation becomes unreliable, and affected transfers must be restricted or investigated. |
Payments are delayed or may be misdirected; financial loss and transaction disputes may occur. |
|
CBS-2.8 |
Funds Availability and Account Balance Verification |
Core banking balance service outage during payment peak |
A core banking database performance failure prevents the timely retrieval of available balances. Digital and branch channels remain accessible but cannot reliably verify funds. |
Core banking database failure and capacity degradation |
Funds checks time out or return stale information. |
Payments cannot be safely authorised; disruption propagates to account posting and internal transfer execution. |
|
CBS-2.9 |
Payment Transaction Classification and Processing |
Payment processing capacity exhaustion following a transaction surge |
An unexpected surge in transaction volume coincides with inefficient processing rules and limited system capacity. Payment queues grow faster than they can be cleared. |
Peak-load capacity exhaustion and processing inefficiency |
Payment classification and processing become severely delayed. |
Essential payment throughput falls, backlog grows and service degradation may continue after technical recovery. |
|
CBS-2.10 |
Customer Account Debit and Transaction Posting |
Ransomware attack causing ledger transaction-state uncertainty |
Ransomware compromises a database-support environment, and interrupts account posting. Some debits are recorded, while corresponding payment-completion states remain uncertain. |
Ransomware and database integrity compromise |
Debit posting is suspended pending containment and validation of transaction states. |
Customers may experience incorrect balances, missing or duplicate payments and prolonged interruption while trusted records are restored. |
|
CBS-2.11 |
Payment Instruction Routing and Transmission |
Simultaneous primary and secondary payment gateway connectivity failure |
A telecommunications routing incident affects the primary payment connection, while an incorrectly configured secondary route fails to take over. Payment messages accumulate in transmission queues. |
Network routing failure combined with ineffective failover |
Instructions cannot be transmitted to the required execution route. |
Interbank payments are delayed or unavailable despite successful internal validation and posting. |
|
CBS-2.12 |
Internal Funds Transfer Execution |
Internal transfer processing inconsistency following failed software deployment |
A defective deployment interrupts the atomic debit-credit process. Some originating accounts are debited while beneficiary credit confirmation remains unresolved. |
Failed core banking software deployment |
Internal transfers are suspended while we investigate incomplete transaction states. |
Customers cannot rely on internal transfer completion; account balances and financial integrity may be affected. |
|
CBS-2.13 |
Domestic Interbank Payment Execution |
Prolonged industry payment network outage |
An external domestic payment infrastructure incident prevents interbank payment exchange for several hours. Multiple participating financial institutions are affected, limiting alternative routes. |
Critical external payment infrastructure failure |
Outgoing interbank payments cannot be executed normally; acknowledgements and processing outcomes may be delayed. |
Customers cannot transfer funds to other banks; payment backlogs and interbank dependencies create wider disruption. |
|
CBS-2.14 |
Interbank Clearing and Settlement Coordination |
Settlement coordination failure during the liquidity-sensitive payment period |
A settlement interface becomes unavailable while payment obligations accumulate. Incomplete settlement information creates uncertainty over positions and required funding actions. |
Settlement interface failure and delayed settlement information |
Settlement status and relevant obligations cannot be reliably confirmed. |
Payment completion and reconciliation are delayed; counterparty obligations and liquidity management may be affected. |
|
CBS-2.15 |
Beneficiary Credit and Payment Completion Management |
Incoming credit processing failure with inconsistent payment acknowledgements |
The receiving payment process experiences a database fault. Upstream acknowledges incoming payment instructions, but beneficiary credits cannot be consistently verified. |
Beneficiary credit database failure |
Credit processing becomes incomplete or uncertain; transaction completion cannot be reliably confirmed. |
Beneficiaries may not receive funds despite apparent payment submission; disputes and duplicate payment attempts increase. |
|
CBS-2.16 |
Payment Status Confirmation and Customer Notification |
Customer notification failure during payment processing degradation |
A messaging provider outage occurs while payment processing is already delayed. Customers receive no reliable status updates and repeatedly resubmit payment instructions. |
Third-party messaging failure during a payment incident |
Transaction notifications and customer status communications are delayed or unavailable. |
Customer uncertainty increases, duplicate payment attempts amplify processing pressure and support demand rises. |
|
CBS-2.17 |
Payment Reconciliation and Financial Control |
Corrupted settlement data is causing widespread reconciliation failure |
A corrupted settlement file enters the reconciliation process. Internal account postings and external settlement records no longer agree, and automated matching produces unreliable results. |
Data corruption in the settlement reporting interface |
Reconciliation cannot establish reliable transaction completeness or financial positions. |
Payment integrity becomes uncertain; unresolved discrepancies may prevent safe processing or restoration. |
|
CBS-2.18 |
Payment Records and Transaction Audit Management |
Destructive cyberattack against transaction evidence repositories |
An attacker compromises privileged access to transaction records and attempts to alter or delete payment audit trails while normal payment processing continues. |
Privileged access compromise and destructive malware |
Payment histories and audit evidence become incomplete or untrustworthy. |
Investigations, dispute resolution and safe transaction reconstruction become difficult; payment processing may require restriction. |
|
CBS-2.19 |
Payment Service Monitoring and Operational Control |
Monitoring blind spot during gradual payment service deterioration |
A monitoring configuration change suppresses critical alerts while payment queues and response times deteriorate. The issue is detected only after customers report widespread failures. |
Monitoring misconfiguration and telemetry loss |
Service degradation is not detected or escalated promptly. |
Backlogs and customer harm accumulate without intervention, reducing the time available to remain within Impact Tolerance. |
|
CBS-2.20 |
Payment Exception, Rejection and Return Management |
Mass payment rejection with simultaneous specialist staffing shortage |
A payment scheme interface defect generates thousands of rejected transactions when key exception-processing specialists are unavailable. |
Payment interface defect and critical personnel shortage |
Exception queues exceed available capacity for investigation and correction. |
Customers face unresolved payment failures, delayed returns and potential account adjustment errors. |
|
CBS-2.21 |
Payment Dispute and Transaction Investigation |
Coordinated payment fraud event overwhelming investigation capability |
A widespread fraud incident generates unusually high numbers of disputed transfers. Case management and specialist investigation capacity become insufficient to resolve urgent cases. |
Coordinated fraud activity and investigation workload surge |
Payment disputes cannot be investigated or prioritised within normal timeframes. |
Customer financial harm may persist; unresolved disputes and regulatory exposure increase. |
|
CBS-2.22 |
Payment Disruption Assessment and Service Escalation |
Delayed escalation during multi-service technology failure |
A core banking disruption affects payments, digital banking and account access simultaneously. Conflicting incident information and unclear decision authority delay recognition of the CBS-level impact. |
Cross-functional coordination failure during a major ICT incident |
Service impact is underestimated, delaying continuity and crisis decisions. |
Customer harm expands while management loses valuable response time and recovery coordination becomes fragmented. |
|
CBS-2.23 |
Payment Continuity and Alternative Processing |
Regional flooding disables primary operations and alternative processing arrangements |
Severe flooding disrupts a critical operations location and regional telecommunications. The designated alternative arrangement relies on some of the same affected connectivity and personnel. |
Regional flooding, utility disruption and shared recovery dependencies |
Alternative payment processing cannot achieve the required minimum service capacity. |
Essential payments remain unavailable; simultaneous failures may exceed the approved Impact Tolerance. |
|
CBS-2.24 |
Payment Service Recovery and Controlled Restoration |
Simultaneous primary and recovery failure with corrupted transaction states |
During recovery from a major cyber incident, the secondary environment fails integrity checks, and transaction journals contain inconsistent states. Restoration is delayed until payment records can be trusted. |
Cyber compromise combined with ineffective recovery arrangements |
Normal processing cannot resume safely; transaction backlogs and reconciliation requirements increase. |
Prolonged payment disruption, potential duplicate or missing payments and severe customer harm may result. |
The proposed scenarios cover distinct disruption mechanisms rather than repeating the same application outage across all processes.
The portfolio includes deliberate cyberattacks, accidental data corruption, defective technology changes, peak-capacity exhaustion, external payment infrastructure failure, third-party disruption, settlement uncertainty, specialist personnel shortages, monitoring failures, regional flooding and combined primary/recovery failures.
This diversity matters because MBSB's resilience cannot be demonstrated solely through successful disaster recovery of the core banking or payment processing platform.
A technically successful recovery may still leave customers unable to complete payments because of failed authentication, unavailable external payment networks, unresolved transaction records or insufficient operational staff.
The second table connects each scenario to the resources and interdependencies it challenges. It also identifies how Cyber and ICT Risks contribute to the disruption, whether the scenario could breach CBS-2's Impact Tolerance, the recommended proactive actions and the evidence required to demonstrate preparedness.
The Potential Impact Tolerance Breach column uses the illustrative limits established earlier. “Yes” means that a sufficiently severe or prolonged execution of the scenario could exceed one or more limits; it does not mean that every occurrence would automatically constitute a breach.
Table 2: Severe but Plausible Scenario Risk Management and Testing Assessment
|
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-2.1 |
Customer Payment Instruction Initiation |
Customer channels; CBS-3 Digital Banking Services; CBS-2.2; telecommunications; branch capacity |
DDoS is the trigger; digital channel capacity and network saturation amplify disruption. |
Yes — customer scope, payment availability and duration may exceed limits. |
Strengthen DDoS mitigation, independent channel capacity, traffic monitoring, and tested alternative-initiation arrangements. |
DDoS exercise; load tests; channel failover results; branch capacity assessment. |
Demonstrate that essential customers can initiate payments safely within tolerance during a coordinated channel attack. |
|
CBS-2.2 |
Payment Instruction Capture and Registration |
CBS-2.1, 2.3, 2.18; transaction database; message queues; payment gateway |
ICT change failure triggers message loss; duplicate retries amplify transaction integrity risk. |
Yes — unresolved or duplicated instructions may cause serious financial harm. |
Implement durable messaging, unique transaction identifiers, duplicate detection and controlled replay procedures. |
Queue recovery tests; transaction integrity reports; change assurance; duplicate prevention testing. |
Confirm that all accepted instructions can be reconstructed and processed exactly once after failure. |
|
CBS-2.3 |
Payment Instruction Completeness Validation |
CBS-2.2, 2.4, 2.7, 2.20; validation rules; reference data |
Defective software release is the trigger; shared validation configuration spreads the failure. |
Yes, if widespread, rejection rates and delays may exceed capacity or duration limits. |
Apply staged deployment, regression testing, automated validation monitoring and rapid rollback capability. |
Change approvals; regression test reports; rollback exercise; validation exception trends. |
Demonstrate timely detection and correction of defective validation rules without widespread payment disruption. |
|
CBS-2.4 |
Customer Authentication and Payment Authorisation |
CBS-8 Customer Transaction Authentication and Authorisation Services; CBS-3 Digital Banking Services; CBS-2.5; identity infrastructure |
Privileged access compromise is the trigger; shared identity dependency amplifies multi-service disruption. |
Yes — an inability to authorise payments or a security compromise may breach tolerance. |
Strengthen privileged access controls, authentication resilience, security monitoring and approved emergency restrictions. |
Access reviews; penetration testing; authentication failover; cyber incident exercises. |
Verify that MBSB can contain identity compromise while preserving safe essential payment capability. |
|
CBS-2.5 |
Account Eligibility and Payment Limit Validation |
CBS-1 Customer Deposit and Account Access Services; CBS-2.4, 2.8; core banking account data |
Corrupted batch update triggers inaccurate account decisions; shared data increases the affected population. |
Yes — widespread payment rejection or incorrect authorisation may exceed tolerance. |
Implement data validation, controlled bulk changes, independent reconciliation and rapid recovery of trusted account-control records. |
Data integrity testing; batch control reports; change audit trails; recovery tests. |
Validate the ability to detect incorrect account controls and restore reliable payment eligibility decisions. |
|
CBS-2.6 |
Payment Fraud and Compliance Screening |
Fraud operations; compliance; CBS-2.7, 2.9, 2.20; screening provider |
Third-party ICT failure triggers screening unavailability; coordinated fraud attempts amplify harm. |
Yes — prolonged suspension or unsafe payment execution may breach tolerance. |
Establish resilient screening, provider contingency procedures, fraud escalation, and approved restricted-processing controls. |
Screening failover tests; provider assurance; fraud simulations; compliance control testing. |
Demonstrate continuity of essential payments without bypassing mandatory fraud and compliance controls. |
|
CBS-2.7 |
Beneficiary and Payment Destination Validation |
CBS-2.3, 2.8, 2.20; beneficiary records; payment verification interfaces |
API compromise triggers unreliable beneficiary responses; corrupted data may cause misdirection. |
Yes — material misdirected payments may breach integrity limits immediately. |
Secure beneficiary interfaces, validate responses, monitor suspicious destination changes and establish transaction hold criteria. |
API security tests; beneficiary integrity reviews; fraud monitoring; interface recovery tests. |
Verify that unreliable beneficiary information is detected and unsafe payments are prevented. |
|
CBS-2.8 |
Funds Availability and Account Balance Verification |
CBS-1 Customer Deposit and Account Access Services; CBS-2.9, 2.10; core banking ledger |
Database failure triggers balance unavailability; shared ledger concentration amplifies disruption. |
Yes — payment processing may stop across multiple channels and customer groups. |
Strengthen database resilience, balance-integrity controls, failover, and capacity monitoring. |
Core banking failover tests; database performance reports; balance reconciliation; disaster recovery results. |
Confirm that trusted funds availability information can be restored before essential payments exceed tolerance. |
|
CBS-2.9 |
Payment Transaction Classification and Processing |
CBS-2.8, 2.10–2.13; payment processing engine; shared queues |
ICT capacity exhaustion triggers degradation; inefficient rules and retry storms amplify backlog. |
Yes — processing capacity may fall below 50%, and delays may exceed limits. |
Conduct peak-load testing, queue capacity planning, transaction prioritisation and performance tuning. |
Capacity tests; processing performance reports; queue monitoring; stress exercise results. |
Demonstrate minimum essential payment throughput under extreme but credible transaction demand. |
|
CBS-2.10 |
Customer Account Debit and Transaction Posting |
CBS-1 Customer Deposit and Account Access Services; CBS-2.8, 2.12, 2.17; ledger and database |
Ransomware triggers processing suspension; transaction-state corruption prolongs recovery. |
Yes — material posting uncertainty can breach financial-integrity limits without a lengthy outage. |
Implement protected transaction journals, privileged access controls, cyber recovery and reconciliation-based restoration. |
Cyber recovery tests; ledger reconciliation; privileged access audit; backup integrity reports. |
Demonstrate safe recovery of debit posting without duplicate, missing or incorrect financial transactions. |
|
CBS-2.11 |
Payment Instruction Routing and Transmission |
CBS-2.9, 2.13; payment gateway; telecommunications; external payment network |
Network routing failure triggers the outage; ineffective secondary routing amplifies it. |
Yes — interbank payment availability and backlog may exceed tolerance. |
Verify network diversity, independent routing, gateway failover, and message-queue recovery. |
Network resilience tests; routing configuration reviews; provider assurance; gateway failover results. |
Confirm that payment transmission can be restored or safely queued within approved service limits. |
|
CBS-2.12 |
Internal Funds Transfer Execution |
CBS-1 Customer Deposit and Account Access Services; CBS-2.10, 2.15, 2.17; core ledger |
Failed deployment triggers inconsistent transaction states; shared ledger architecture increases consequences. |
Yes — incomplete debit-credit processing may breach financial integrity boundaries. |
Strengthen deployment controls, atomic posting, transaction rollback and debit-credit reconciliation. |
Release testing; transaction integrity results; reconciliation reports; recovery exercise records. |
Demonstrate that internal transfers can be safely resumed without unmatched debit-credit transactions. |
|
CBS-2.13 |
Domestic Interbank Payment Execution |
CBS-2.11, 2.14, 2.15; external payment infrastructure; receiving institutions; CBS-7 High-Value and Interbank Payment Services where shared |
External ICT infrastructure outage is the trigger; industry concentration prevents easy substitution. |
Yes — prolonged interbank unavailability and widespread customer impact may exceed tolerance. |
Establish payment network contingency coordination, prioritise essential payments, and set up provider incident arrangements. |
Payment infrastructure exercise reports; third-party assurance; interbank contingency plans; joint incident records. |
Evaluate MBSB's ability to manage essential interbank payment outcomes during an industry-wide outage. |
|
CBS-2.14 |
Interbank Clearing and Settlement Coordination |
CBS-2.13, 2.15, 2.17; treasury; settlement infrastructure; counterparties |
Settlement interface failure triggers uncertainty; data latency and time synchronisation errors amplify risk. |
Yes — settlement obligations and counterparty harm may exceed acceptable limits. |
Strengthen settlement monitoring, independent data validation, liquidity contingency and external escalation procedures. |
Settlement reconciliation; treasury contingency tests; time synchronisation monitoring; provider exercise reports. |
Demonstrate reliable settlement decision-making and control of obligations during prolonged settlement disruption. |
|
CBS-2.15 |
Beneficiary Credit and Payment Completion Management |
CBS-1 Customer Deposit and Account Access Services; CBS-2.12–2.14, 2.16; beneficiary ledger |
Database failure triggers incomplete credits; inconsistent acknowledgements amplify duplicate-payment risk. |
Yes — material missing credits or uncertain completion may breach integrity limits. |
Implement transaction-state verification, duplicate controls, incoming payment reconciliation and safe suspension rules. |
Beneficiary credit tests; transaction-state reports; duplicate detection results; recovery validation. |
Confirm that every affected payment can be classified as completed, pending, rejected or requiring investigation. |
|
CBS-2.16 |
Payment Status Confirmation and Customer Notification |
CBS-3 Digital Banking Services; CBS-9 Customer Support and Assistance During Banking Disruptions; CBS-2.15, 2.21; messaging providers |
Third-party messaging failure contributes to the incident; inaccurate status data amplifies customer retries. |
Yes, when combined, duplicate attempts and customer uncertainty can increase harm beyond tolerance. |
Provide alternative customer communication, verified status information and duplicate-submission warnings. |
Messaging contingency tests; notification accuracy reports; customer communication exercises. |
Demonstrate that customers receive accurate payment status and guidance during major processing disruption. |
|
CBS-2.17 |
Payment Reconciliation and Financial Control |
CBS-2.10, 2.14–2.15, 2.18; finance; settlement data |
Corrupted data feed triggers mismatches; automated reconciliation may propagate incorrect results. |
Yes — material financial-integrity uncertainty may breach tolerance. |
Validate external data, independently reconcile ledger and settlement records, and establish exception thresholds. |
Reconciliation control tests; data integrity reports; settlement exception logs; independent reviews. |
Confirm that corrupted settlement information is detected and payment integrity can be independently established. |
|
CBS-2.18 |
Payment Records and Transaction Audit Management |
CBS-2.2, 2.10, 2.17, 2.21, 2.24; transaction archive; audit logging |
Privileged access compromise triggers evidence destruction; compromised backups prolong recovery. |
Yes, if material — inability to establish transaction outcomes may prevent safe processing and restoration. |
Protect transaction evidence, segregate privileged access, maintain tamper-evident logs, and test audit-record recovery. |
Access control audits; log integrity tests; backup restoration; cyber recovery reports. |
Demonstrate that reliable payment evidence remains available after destructive cyber activity. |
|
CBS-2.19 |
Payment Service Monitoring and Operational Control |
CBS-2.1–2.18; technology operations; incident management; payment monitoring |
Monitoring misconfiguration triggers a detection blind spot; missing telemetry prolongs service degradation. |
Yes — undetected deterioration may exceed duration, capacity and customer-impact limits. |
Establish independent end-to-end service monitoring, synthetic transactions and tested alert escalation. |
Monitoring coverage reports; synthetic transaction results; alert tests; incident detection metrics. |
Demonstrate timely detection of customer-facing payment failure even when infrastructure alerts are suppressed. |
|
CBS-2.20 |
Payment Exception, Rejection and Return Management |
CBS-2.13–2.17, 2.21; payment operations; receiving institutions; specialist staff |
Payment interface defect triggers mass exceptions; staffing shortages amplify backlog and recovery delays. |
Yes — unresolved failed payments and account adjustments may exceed tolerance. |
Implement exception prioritisation, cross-trained staffing, surge capacity and controlled correction procedures. |
Staffing continuity exercises; exception backlog reports; adjustment audits; provider incident tests. |
Demonstrate that essential payment exceptions can be resolved safely under extreme workload and reduced staffing. |
|
CBS-2.21 |
Payment Dispute and Transaction Investigation |
CBS-9 Customer Support and Assistance During Banking Disruptions; CBS-2.18, 2.20; fraud and compliance |
Fraud activity is the trigger; case management capacity and evidence availability amplify harm. |
Yes, if severe, unresolved fraud losses and customer harm may become unacceptable. |
Strengthen fraud surge response, dispute prioritisation, evidence preservation and investigation staffing. |
Fraud simulations; dispute ageing reports; case audits; specialist staffing plans. |
Demonstrate effective prioritisation and resolution of high-harm payment disputes during a widespread fraud incident. |
|
CBS-2.22 |
Payment Disruption Assessment and Service Escalation |
CBS-2.19–2.24; CBS-1 Customer Deposit and Account Access Services; CBS-3 Digital Banking Services; CBS-9 Customer Support and Assistance During Banking Disruptions |
Major ICT outage initiates the incident; fragmented monitoring and communications delay escalation. |
Yes — late activation may allow service harm to exceed tolerance before recovery begins. |
Establish CBS-level escalation triggers, integrated incident dashboards, accountable decision-makers and cross-functional exercises. |
Crisis exercises; incident escalation logs; management decision records; tolerance monitoring tests. |
Verify that management recognises CBS-level harm and activates appropriate continuity and crisis arrangements promptly. |
|
CBS-2.23 |
Payment Continuity and Alternative Processing |
CBS-2.9–2.15; BCM; payment operations; facilities; telecommunications; recovery providers |
Regional infrastructure failure triggers the disruption; common dependencies between primary and alternate arrangements amplify it. |
Yes — inability to sustain minimum payment capacity may breach duration and customer-impact limits. |
Validate geographic separation, independent connectivity, alternative staffing, and minimum safe payment-processing capacity. |
Business continuity tests; alternate-site assessments; network diversity reports; third-party assurance. |
Demonstrate sustained essential payment delivery when both normal operations and part of the contingency arrangement are unavailable. |
|
CBS-2.24 |
Payment Service Recovery and Controlled Restoration |
CBS-2.10, 2.15, 2.17–2.18, 2.23; disaster recovery; cybersecurity; finance control; external networks |
A cyber compromise triggers recovery; corrupted transaction states and ineffective secondary infrastructure prolong restoration. |
Yes — prolonged outage or unsafe transaction replay may breach tolerance. |
Maintain trusted recovery environments, transaction-state reconstruction, reconciliation gates and controlled restoration approval. |
Disaster recovery tests; cyber recovery exercises; reconciliation sign-offs; restoration decision records; remediation reports. |
Demonstrate safe restoration of essential payment outcomes without duplicate, missing or incorrect transactions. |
In addition to scenario-specific objectives, management should evaluate consistent outcomes across the portfolio.
|
Observation Area |
Questions Management Should Evaluate |
|
Customer impact |
How many customers couldn't complete payments, for how long, and what were the consequences? |
|
Service availability |
Which payment types and channels remained available, degraded or unavailable? |
|
Essential processing capacity |
Was the required minimum payment throughput maintained? |
|
Transaction integrity |
Were payments lost, duplicated, misposted or left in an uncertain state? |
|
Dependency failure |
Which internal, external or shared dependencies disrupted the propagation? |
|
Detection and escalation |
How quickly was the CBS-level impact recognised and escalated? |
|
Cyber and ICT response |
Were security controls maintained while restoring payment capability? |
|
Third-party coordination |
Did providers and payment infrastructure participants respond within workable timeframes? |
|
Recovery effectiveness |
Did restoration result in verified customer payment completion rather than only technical system availability? |
|
Impact Tolerance |
Which boundary was approached or breached, and at what point? |
|
Residual vulnerability |
What weaknesses remain after existing controls and recovery arrangements are applied? |
|
Management response |
Were decisions timely, properly authorised and supported by accurate service-impact information? |
These observations should be captured in a formal scenario testing report, supported by transaction data, incident timelines, technology logs, reconciliation records, management decisions and third-party evidence.
The BNM Operational Resilience Discussion Paper, issued 19 December 2025 (BNM/RH/DP 028-25), sets out BNM's emerging direction for strengthening operational resilience in Malaysia's financial sector.
The Discussion Paper is a consultation document.
It describes existing requirements in BNM policy documents and explores how to articulate operational resilience concepts more explicitly. Its discussion areas should not automatically be treated as newly binding requirements.
This distinction is particularly important for scenario testing.
Existing requirements under the applicable BCM, RMiT, outsourcing and governance frameworks must be distinguished from proposed enhancements and good-practice recommendations.
|
Regulatory Consideration |
What the December 2025 BNM Discussion Paper States |
Application to MBSB CBS-2 |
|
Continuity of critical services |
Paragraphs 3.2–3.3 discuss preserving critical services during severe but plausible disruption. |
Design scenarios around the ability of customers to complete domestic payments, not merely application recovery. |
|
Mapping of interdependencies |
Paragraph 3.3 discusses identifying internal and external dependencies, vulnerabilities and critical failure points. |
Use the CBS-2 mapping to identify shared authentication, ledger, payment network, staffing and provider dependencies. |
|
Impact Tolerance |
Paragraph 3.3 discusses determining acceptable disruption boundaries, including duration, harm and minimum service capability. |
Evaluate every scenario against approved customer-harm, payment-capacity, duration and financial-integrity boundaries. |
|
Severe but plausible scenarios |
Paragraph 3.3 identifies the value of broad, credible scenarios that reveal weaknesses and challenge multi-layered failures. |
Combine technology, cyber, operational, third-party and recovery failures where plausible. |
|
Concurrent failures |
Paragraph 2.9 explains why isolated failure testing is insufficient and highlights concurrent scenarios. |
Include common-cause outages, simultaneous primary/recovery failures and cascading disruptions across CBSs. |
|
Cyber resilience |
Paragraphs 2.4 and 4.3–4.7 discuss ransomware, destructive cyber incidents and the role of RMiT requirements. |
Test compromised identity, corrupted payment data, ransomware and trusted recovery. |
|
Third-party dependencies |
Paragraphs 2.6, 3.3 and 4.4–4.5 discuss concentration, substitutability and third-party continuity arrangements. |
Assess external payment infrastructure, telecommunications, managed services and screening-provider failures. |
|
Governance and oversight |
Paragraphs 3.4 and 6.1–6.4 discuss board oversight, management accountability and cross-functional coordination. |
Require accountable scenario ownership, management challenge, formal reporting and remediation decisions. |
|
Continuous improvement |
Paragraphs 2.9, 3.5 and 7.1 discuss learning from disruption, testing and improvements. |
Convert scenario findings into tracked corrective actions and repeat tests to validate improvements. |
The Discussion Paper directly supports these themes, but its proposed operational resilience framework should not be confused with final regulatory requirements.
BNM's Discussion Paper provides examples of operational disruptions particularly relevant to Malaysian banking and payment services.
|
Example Discussed by BNM |
Reference |
Relevance to MBSB Scenario Design |
|
Technology migration failure causing prolonged banking service disruption |
Paragraph 2.4, footnote 2 |
Test failed payment platform changes and recovery complications. |
|
Core payment and settlement infrastructure outage |
Paragraph 2.4, footnote 2 |
Test external payment network disruption and settlement uncertainty. |
|
Major power blackout affecting branches and payment access infrastructure |
Paragraph 2.4, footnote 2 |
Test regional infrastructure loss and alternative-channel capacity. |
|
Ransomware and destructive cyberattacks affecting critical systems |
Paragraph 2.4 |
Test containment, trusted recovery and financial data integrity. |
|
Malaysian mobile banking disruption involving inadequate core banking storage |
Paragraph 2.8, footnote 3 |
Test shared core banking capacity and cascading payment failures. |
|
Core banking disruption following a failed disaster recovery test |
Paragraph 2.8, footnote 3 |
Test recovery architecture independence and controlled restoration. |
|
Ransomware associated with weak security controls |
Paragraph 2.8, footnote 3 |
Test privileged access, authentication controls and cyber recovery preparedness. |
|
Climate-related flooding and other physical infrastructure disruption |
Paragraph 2.7 |
Test facilities, staffing, telecommunications and geographically correlated recovery failures. |
These are examples described in the BNM document, not incidents attributed to MBSB.
The following are recommendations developed for this MBSB case study, rather than scenario-testing rules expressly prescribed by the December 2025 Discussion Paper:
MBSB should apply these recommendations proportionately and align them with its approved governance framework, existing regulatory obligations and demonstrated risk exposure.
The Discussion Paper discusses board-level oversight and senior management accountability for operational resilience.
It also describes the Responsibility Mapping policy's role in assigning senior management responsibility for implementing the operational resilience framework.
For CBS-2, an appropriate implementation structure would include:
|
Governance Role |
Recommended Responsibility |
|
Board / Board Risk Committee |
Challenge the adequacy of the scenario portfolio, material resilience gaps and management's remediation plans. |
|
Senior Management is accountable for Operational Resilience |
Ensure cross-functional coordination, sufficient resources and escalation of significant weaknesses. |
|
CBS-2 Owner |
Confirm scenario relevance, customer impact, essential payment outcomes and tolerance measures. |
|
Payment Operations |
Validate payment processes, transaction flows, exception handling and operational workarounds. |
|
Technology and ICT Risk |
Assess infrastructure, applications, network resilience, change risk and recovery capability. |
|
Cybersecurity |
Validate cyber threat assumptions, containment measures and trusted recovery arrangements. |
|
BCM and Crisis Management |
Evaluate continuity activation, alternative processing, crisis coordination and prolonged disruption capability. |
|
Operational Risk |
Challenge risk assumptions, evaluate residual vulnerabilities and monitor remediation. |
|
Compliance |
Assess applicable regulatory and payment-system obligations. |
|
Internal Audit |
Provide independent assurance over the governance, control and testing framework in accordance with the approved audit plan. |
Although all 24 Sub-CBS processes should be represented in the scenario inventory, MBSB should not necessarily conduct 24 separate full-scale exercises.
MBSB can combine several scenarios to test common dependencies and cumulative harm more effectively.
A risk-based programme could prioritise the following six integrated exercises.
|
Priority |
Integrated Scenario |
Principal Sub-CBS Coverage |
Primary Resilience Challenge |
|
1 |
Ransomware, core banking disruption and transaction-state corruption |
CBS-2.8, 2.10, 2.12, 2.17, 2.18, 2.24 |
Financial integrity, trusted recovery and safe payment restoration |
|
2 |
External payment network outage during peak transaction demand |
CBS-2.9, 2.11, 2.13–2.15, 2.19–2.20 |
Interbank dependency, payment capacity, backlog and customer harm |
|
3 |
Identity compromise combined with fraud screening disruption |
CBS-2.4–2.7, 2.21–2.22 |
Security, fraud prevention, authorisation and safe service continuity |
|
4 |
Failed payment technology deployment and transaction duplication |
CBS-2.2–2.3, 2.9–2.12, 2.17 |
Change resilience, transaction integrity and controlled rollback |
|
5 |
Regional flooding with telecommunications and alternative-site failure |
CBS-2.1, 2.11, 2.16, 2.22–2.24 |
Common-cause failure, facilities, staffing and continuity arrangements |
|
6 |
Monitoring failure, mass payment exceptions and delayed crisis escalation |
CBS-2.16, 2.19–2.24 |
Detection, management decision-making, backlog control and restoration |
These six exercises should collectively demonstrate whether MBSB can protect essential payment outcomes when multiple Sub-CBS processes are disrupted.
The remaining scenarios can be evaluated through focused functional exercises, technical tests, walkthroughs, simulations or targeted control validation.
Scenario identification should lead to proactive risk management rather than remain a documentation exercise.
For each scenario, MBSB should establish a record containing:
|
Evidence Field |
Required Information |
|
Scenario reference |
Unique identifier linked to the relevant Sub-CBS |
|
Scenario owner |
Accountable business owner and participating specialist functions |
|
Scenario assumptions |
Trigger, severity, duration, timing, affected channels and simultaneous failures |
|
Dependencies challenged |
Internal processes, systems, personnel, facilities, third parties and other CBSs |
|
Impact Tolerance measures |
Approved limits for duration, customer harm, capacity, transaction integrity and other relevant dimensions |
|
Existing controls |
Preventive, detective, response, recovery and resilience arrangements |
|
Testing approach |
Tabletop, simulation, technical exercise, end-to-end test or combined exercise |
|
Expected outcomes |
Minimum payment capability, safe processing, recovery and customer-impact limits |
|
Actual observations |
Measured results, incident timeline, service degradation and control performance |
|
Vulnerabilities |
Identified weaknesses, concentration risks and failed assumptions |
|
Remediation |
Corrective action, owner, target date and risk priority |
|
Management oversight |
Approval, challenge, residual risk acceptance and reporting records |
|
Retesting |
Evidence that corrective measures have been implemented and validated |
The evidence should demonstrate not only that MBSB considered the scenario, but also that it assessed potential consequences, tested relevant capabilities, and addressed material weaknesses.
For each test, management should determine whether:
Do not classify a scenario test as successful solely because the affected technology platform was restored.
Where payment service delivery remains outside tolerance, the test should identify a resilience gap even if the underlying technology recovery target was achieved.
MBSB should maintain a central Severe but Plausible Scenario Register linked to the CBS-2 process catalogue, dependency mapping, Impact Tolerance assessment and resilience improvement programme.
MBSB should review scenario testing results to identify recurring weaknesses, particularly those involving shared technology platforms, external payment infrastructure, data integrity, specialist personnel, recovery architecture, and incident coordination.
Management reporting should distinguish between scenarios that have been designed, tested, demonstrated, and those where material gaps remain.
Where testing identifies an inability to remain within Impact Tolerance, MBSB should establish a documented remediation plan.
This may include technology resilience investment, improved monitoring, alternative processing arrangements, stronger supplier controls, revised recovery procedures, additional staffing capability or enhanced cyber recovery measures.
Assign material remediation actions to accountable owners, track them to completion, and subject them to effectiveness verification.
Severe but Plausible Scenarios provide MBSB with a practical means of evaluating whether CBS-2: Domestic Funds Transfer and Payment Services can withstand significant operational disruption without causing unacceptable harm to customers, counterparties or the financial system.
By identifying a distinct scenario for each of the 24 Sub-CBS processes, MBSB can examine how disruption affects individual operational activities while also understanding how failures propagate across the end-to-end payment lifecycle.
The analysis demonstrates that domestic payment resilience depends on more than technology availability.
It requires effective customer authentication, reliable account information, secure payment processing, external network connectivity, accurate settlement records, trained personnel, coordinated incident management and safe recovery arrangements.
Integrating Cyber and ICT Risks into scenario design is essential because cyberattacks, data corruption, technology concentration, infrastructure outages and failed system changes can simultaneously disrupt several Sub-CBS processes and other Critical Business Services.
The recommended proactive risk management actions and supporting evidence provide a basis for demonstrating resilience preparedness, evaluating control effectiveness and informing management decisions.
However, preparedness must ultimately be demonstrated through credible testing against MBSB's formally approved Impact Tolerance.
The 24 proposed scenarios therefore establish a structured foundation for Operational Resilience scenario testing.
The results should guide remediation priorities, technology and operational investments, risk treatment, third-party oversight, governance decisions and continuous resilience improvement.
The central implementation principle is that MBSB should not merely demonstrate that its payment systems can recover from disruption.
It should demonstrate that essential domestic payment services can continue or be safely restored before customers and the financial system experience unacceptable harm.
The regulatory discussion is based on BNM's Operational Resilience Discussion Paper (19 December 2025).
The scenario identification methodology is also informed by BCM Institute's What is Severe but Plausible Scenarios in Operational Resilience?, Designing Severe but Plausible Scenarios and Steps to Implement Severe but Plausible Scenarios in Operational Resilience.
The 24 scenario designs, testing recommendations, and example tolerance values illustrate applications of MBSB's proposed operating model and require validation before formal implementation or regulatory submission.
| eBook 3: Starting Your OR Implementation |
||||
| CBS-2 Domestic Funds Transfer and Payment Services | ||||
| CBS-2 DP | CBS-2 MII | CBS-2 ITo | CBS-2 SbPS | CBS-2 ST |
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. |
||
|
|