[OR] [MBSB] [E3] [CBS] [2] [SbPS] Identify Severe but Plausible Scenarios

CBS-2 Domestic Funds Transfer and Payment Services

Introduction

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.

Purpose and Scope of Scenario Identification

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.

Scenario Design Principles

MBSB should apply the following principles when identifying and approving scenarios:

Service-oriented: Assess whether customers can complete essential domestic payments.
Severe: Challenge normal operational controls, staffing, technology capacity and recovery arrangements.
Plausible: Use credible threats, operational failure modes, known dependencies and reasonable assumptions.
Interconnected: Examine how failures propagate across Sub-CBS processes and other Critical Business Services.
Multidimensional: Consider disruption to people, processes, technology, information, facilities and third parties.
Cyber and ICT integrated: Treat technology and cybersecurity failures as operational disruption drivers, contributors or amplifiers.
Tolerance-based: Measure customer harm, payment availability, processing capacity, financial integrity and duration against approved Impact Tolerance boundaries.
Evidence-driven: Require observable outcomes, documented test results and management-approved remediation actions.

Impact Tolerance Assumptions Used in this Chapter

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.

Scenario Portfolio Structure

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.

Recommended Severe but Plausible Scenarios

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.

Assessment of Scenario Diversity

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.

Scenario Dependencies, Cyber and ICT Risks, Proactive Risk Management and Testing Objectives

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.

Scenario testing observations and resilience outcomes

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.

Regulatory Considerations for a Malaysian Financial Services Institution

Regulatory Status and Interpretation

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.

Relevant BNM Discussion Themes

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.

Examples Expressly Discussed by BNM

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.

Additional Implementation Recommendations

The following are recommendations developed for this MBSB case study, rather than scenario-testing rules expressly prescribed by the December 2025 Discussion Paper:

Establishing a portfolio of 24 Sub-CBS-linked scenarios.
Assigning each Sub-CBS a unique scenario identifier.
Testing all 24 scenarios over a risk-based multi-year programme.
Using common measures for customer impact, payment backlog, processing capacity and transaction integrity.
Combining selected scenarios into multi-CBS exercises.
Establishing transaction-integrity validation as a formal recovery acceptance criterion.
Requiring independent challenge of assumptions for high-risk scenarios.
Maintaining a central evidence register and remediation tracker.

MBSB should apply these recommendations proportionately and align them with its approved governance framework, existing regulatory obligations and demonstrated risk exposure.

Governance responsibilities

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.

Prioritising the Severe but Plausible Scenario Portfolio

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.

Proactive Risk Management and Scenario Testing Evidence

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.

Recommended Scenario Test Acceptance Criteria

For each test, management should determine whether:

Essential domestic payment outcomes remained within the approved Impact Tolerance.
Minimum processing capacity was maintained or restored before unacceptable harm occurred.
Transaction records, account balances and payment completion states remained reliable.
Cybersecurity, fraud and compliance controls were preserved.
Alternative processing arrangements were feasible and sufficiently independent.
External providers and payment infrastructure participants responded effectively.
Incident escalation and management decisions were timely.
Recovery procedures prevented duplicate, missing or incorrectly posted transactions.
The test identified material weaknesses and assigned them for remediation.

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.

Continuous Improvement and Management Reporting

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.

Banner [Summing] [OR] [E3] Identify Severe but Plausible Scenarios

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.

References

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.

More Information About OR-5000 [OR-5] or OR-300 [OR-3]

To learn more about the course and schedule, click the buttons below for the OR-300 Operational Resilience Implementer course and the OR-5000 Operational Resilience Expert Implementer course.



	If you have any questions, click to contact us.

Operational Resilience in Action: The MBSB Approach

[OR] [MBSB] [E3] [CBS] [2] [SbPS] Identify Severe but Plausible Scenarios

Operational Resilience Certified Planner-Specialist-Expert

CBS-2 Domestic Funds Transfer and Payment Services

Introduction

Purpose and Scope of Scenario Identification

Scenario Design Principles

Impact Tolerance Assumptions Used in this Chapter

Scenario Portfolio Structure

Recommended Severe but Plausible Scenarios

Assessment of Scenario Diversity

Scenario Dependencies, Cyber and ICT Risks, Proactive Risk Management and Testing Objectives

Scenario testing observations and resilience outcomes

Regulatory Considerations for a Malaysian Financial Services Institution

Regulatory Status and Interpretation

Relevant BNM Discussion Themes

Examples Expressly Discussed by BNM

Additional Implementation Recommendations

Governance responsibilities

Prioritising the Severe but Plausible Scenario Portfolio

Proactive Risk Management and Scenario Testing Evidence

Recommended Scenario Test Acceptance Criteria

Continuous Improvement and Management Reporting

References

More Information About OR-5000 [OR-5] or OR-300 [OR-3]

Your Comments Here:

Operational Resilience in Action: The MBSB Approach

[OR] [MBSB] [E3] [CBS] [2] [SbPS] Identify Severe but Plausible Scenarios

Operational Resilience Certified Planner-Specialist-Expert

hbspt.cta._relativeUrls=true;hbspt.cta.load(3893111, 'd779f9ab-aec0-4cdd-a906-81e7841c3e1c', {"useNewLoader":"true","region":"na1"});

hbspt.cta._relativeUrls=true;hbspt.cta.load(3893111, 'c9c3fddf-009e-4d50-b91c-b18d1228e9ef', {"useNewLoader":"true","region":"na1"}); CBS-2 Domestic Funds Transfer and Payment Services

Introduction

Purpose and Scope of Scenario Identification

Scenario Design Principles

Impact Tolerance Assumptions Used in this Chapter

Scenario Portfolio Structure

Recommended Severe but Plausible Scenarios

Assessment of Scenario Diversity

Scenario Dependencies, Cyber and ICT Risks, Proactive Risk Management and Testing Objectives

Scenario testing observations and resilience outcomes

Regulatory Considerations for a Malaysian Financial Services Institution

Regulatory Status and Interpretation

Relevant BNM Discussion Themes

Examples Expressly Discussed by BNM

Additional Implementation Recommendations

Governance responsibilities

Prioritising the Severe but Plausible Scenario Portfolio

Proactive Risk Management and Scenario Testing Evidence

Recommended Scenario Test Acceptance Criteria

Continuous Improvement and Management Reporting

References

More Information About OR-5000 [OR-5] or OR-300 [OR-3]

Your Comments Here:

CBS-2 Domestic Funds Transfer and Payment Services