Scenario Analysis and Operational-Risk Event Cases - Article

Introduction

Historical operational-loss data tells a bank what has already happened.

However, some of the most serious operational risks are:

• rare;

• difficult to predict;

• potentially very severe; and

• absent from the bank's own historical records.

A bank may never have suffered:

• a major cyberattack;

• simultaneous failure of primary and backup systems;

• a very large internal fraud;

• prolonged disruption of a critical third party; or

• destruction of an important operating facility.

The absence of such losses in historical data does not mean the risks are insignificant.

This is why banks use scenario analysis.

The current 2026 CAIIB BFM syllabus specifically includes Scenario Analysis under Operational Risk and Integrated Risk Management in Module B.

Basel's current operational-risk principles define scenario analysis as a method for identifying, analysing and measuring a range of scenarios, including low-probability, high-severity events capable of producing severe operational losses.

The basic question is:

What serious event could happen, why could it happen, how severe could it become and are our controls strong enough?

Learning Objectives

After studying this topic, you should be able to:

• explain the purpose of operational-risk scenario analysis;

• understand why historical loss data alone is insufficient;

• identify useful inputs for scenario development;

• distinguish causes, events and consequences;

• assess likelihood and impact logically;

• understand the role of expert judgement;

• connect scenario analysis with RCSA, KRIs and business continuity;

• classify important operational-risk events; and

• solve CAIIB scenario-based cases systematically.

What Is Scenario Analysis?

Scenario analysis examines hypothetical but plausible operational-risk events to understand their possible consequences.

A scenario normally describes:

• what happens;

• what causes it;

• which processes or systems are affected;

• how existing controls respond;

• how long disruption lasts;

• what financial and non-financial effects arise; and

• what corrective or resilience measures are required.

Scenario analysis is especially valuable where actual historical experience is limited.

Why Scenario Analysis Is Needed

Historical Data Is Backward-Looking

Internal loss data is important but reflects the bank's past.

The future may involve:

• new technology;

• new fraud methods;

• new products;

• changing customer behaviour;

• new outsourcing arrangements;

• cyber threats; or

• different external disruptions.

Past data may therefore understate emerging risk.

Severe Events May Be Rare

A bank may have twenty years of operations without experiencing a catastrophic data-centre failure.

This does not make such an event impossible.

Rare events may have:

Low frequency + Very high impact

These are exactly the situations where scenario analysis is useful.

The Bank's Own Data May Be Insufficient

Internal data may contain no comparable incident.

Relevant external loss events can therefore help the bank understand what has happened:

• at other banks;

• in other industries; or

• in similar technology environments.

Basel expects scenario analysis to use information such as internal and external loss data, self-assessments, control information, forward-looking metrics and root-cause analysis.

Main Inputs to Scenario Analysis

A sound scenario should not be based merely on imagination.

Useful inputs include:

Internal Loss Data

What operational events has the bank actually experienced?

External Loss Data

What serious events have occurred at other institutions?

RCSA

Which processes already have high inherent or residual risk?

KRIs

Which risk indicators show deterioration?

Near Misses

What almost caused a major loss?

Audit and Control Findings

Which important weaknesses remain unresolved?

Root-Cause Analysis

Why have previous incidents occurred?

Emerging Risks

Examples include:

• artificial-intelligence misuse;

• new cyberattack methods;

• concentration in cloud providers;

• rapid process automation; or

• changing fraud patterns.

Expert Judgement

Subject-matter experts may understand operational vulnerabilities that are not visible from historical data alone.

Basel notes that scenario workshops typically involve relevant senior management, business management, operational-risk specialists and functions such as compliance, HR and IT risk.

Scenario Analysis Process

Step 1: Select a Material Risk

Start with an important operational-risk exposure.

Examples:

• payment-system failure;

• internal fraud;

• cyberattack;

• data leakage;

• third-party outage; or

• natural disaster.

Avoid spending excessive effort on insignificant scenarios.

Step 2: Define the Scenario Clearly

A useful scenario should be specific.

Weak scenario:

“The system fails.”

Better scenario:

“The primary payment-processing system becomes unavailable during peak business hours, failover to the secondary site is unsuccessful, and service remains unavailable for eight hours.”

The second scenario allows meaningful assessment.

Step 3: Identify Causes

Possible causes may include:

• hardware failure;

• software defect;

• cyberattack;

• human error;

• inadequate change management;

• vendor failure; or

• natural disaster.

Step 4: Assess Existing Controls

Consider controls such as:

• redundancy;

• maker-checker;

• access management;

• monitoring;

• backups;

• incident-response procedures;

• insurance; and

• business continuity.

Step 5: Estimate Likelihood

The bank assesses how plausible the event is.

This does not require false precision.

For management purposes, the scenario may use categories such as:

• rare;

• unlikely;

• possible;

• likely.

The methodology should be consistent with the bank's framework.

Step 6: Assess Impact

Consequences may include:

• direct financial loss;

• customer compensation;

• restoration expense;

• legal consequences;

• regulatory action;

• business interruption;

• loss of data; and

• operational disruption.

Basel also expects business-continuity scenario assessments to consider financial, operational, legal and reputational consequences.

Step 7: Determine Residual Vulnerability

Ask:

After existing controls operate, is the remaining exposure within risk appetite and tolerance?

Step 8: Develop Action Plan

Possible actions include:

• strengthen controls;

• improve system resilience;

• reduce dependence on one vendor;

• revise limits;

• improve monitoring;

• purchase appropriate insurance;

• change business-continuity arrangements; or

• formally accept residual risk where authorised.

Step 9: Review and Update

Scenarios should change when:

• systems change;

• products change;

• external threats change;

• major incidents occur; or

• controls are redesigned.

Scenario Analysis and Other Operational-Risk Tools

Scenario analysis should not operate in isolation.

Together, these tools create a more complete operational-risk picture.

Example

Suppose:

• RCSA identifies high cyber risk;

• failed login attempts are rising as a KRI;

• external banks report ransomware attacks; and

• the bank has never experienced a major ransomware loss.

Scenario analysis can combine these signals into a severe ransomware scenario.

Scenario Analysis vs Stress Testing

The two concepts are closely related but should not automatically be treated as identical.

Scenario analysis develops and evaluates a specific possible event or combination of events.

Stress testing generally examines the bank's ability to withstand severe adverse conditions.

Operational-risk scenarios may be used as inputs for:

• stress testing;

• business continuity testing; and

• operational-resilience testing.

Basel explicitly states that scenario analysis can be integrated with disaster-recovery and business-continuity arrangements for operational-resilience testing.

Scenario Analysis and Business Continuity

A scenario becomes especially valuable when it tests a critical operation.

Examples include:

• payment processing;

• customer access to accounts;

• treasury settlement;

• core banking;

• cash operations; and

• important regulatory reporting.

Basel requires business-continuity planning to use forward-looking scenarios covering relevant disruptions, critical operations and important internal and external dependencies.

RBI's April 30, 2024 Guidance Note on Operational Risk Management and Operational Resilience likewise aims to strengthen banks' ability to continue delivering critical operations through disruption.

Questions should include:

• How long can the operation remain unavailable?

• Is the backup site genuinely independent?

• Can staff operate remotely?

• Are critical vendors available?

• How quickly can data be restored?

• How will customers and regulators be informed?

• What happens if multiple controls fail together?

Operational-Risk Event Classification

RBI's operational-risk loss-event taxonomy contains seven major Level 1 categories, including:

1. Internal Fraud

2. External Fraud

3. Employment Practices and Workplace Safety

4. Clients, Products and Business Practices

5. Damage to Physical Assets

6. Business Disruption and System Failures

7. Execution, Delivery and Process Management

In case studies, the challenge is often to classify the event, rather than merely identify the underlying source.

For example:

Cause: weak password management Event: external hacking and theft Event Type: External Fraud

Case Study 1: Major Internal Fraud Scenario

A bank's operations unit has experienced several small unauthorised overrides, but no major fraud loss.

RCSA shows:

• weak segregation of duties;

• excessive privileged access;

• delayed review of exception reports; and

• dependence on a small group of experienced employees.

Management argues that fraud risk is low because historical loss data contains no major internal fraud.

Analysis

This conclusion is weak.

Scenario analysis should consider a situation in which:

• an employee with excessive access deliberately creates unauthorised transactions;

• exception reports are manipulated;

• the activity continues undetected for several months; and

• significant financial loss accumulates.

Inputs supporting the scenario include:

• control weaknesses;

• near misses;

• unauthorised overrides; and

• external fraud-loss experience.

Event Classification

If the event involves deliberate fraud by an employee, it falls under Internal Fraud. RBI's taxonomy includes intentional unauthorised activity, misappropriation and similar events in this category.

Mitigation

Possible actions include:

• stronger segregation of duties;

• privileged-access review;

• automated exception monitoring;

• mandatory leave or job rotation where appropriate;

• enhanced supervisory review; and

• prompt investigation of overrides.

CAIIB Lesson

Absence of historical loss does not prove absence of severe operational risk.

Case Study 2: Core Banking System Failure

A bank's primary data centre is highly reliable and has never suffered an extended outage.

A backup centre exists, but a recent test identified minor failover problems.

Management classifies the residual risk as low because no actual loss has occurred.

Scenario

Assume:

• primary data centre fails;

• automated failover does not work;

• core banking becomes unavailable;

• branches and digital channels are affected; and

• restoration takes several hours.

Analysis

The bank should assess:

• maximum tolerable disruption;

• customer impact;

• manual alternatives;

• recovery procedures;

• communication;

• data integrity;

• third-party dependencies; and

• whether recovery objectives can actually be achieved.

Event Classification

Loss caused by hardware, software, telecommunications or similar system disruption falls under Business Disruption and System Failures.

CAIIB Lesson

A backup system provides protection only if it can actually operate when required.

Case Study 3: Wrong High-Value Payment

An employee enters ₹8 crore instead of ₹80 lakh in a payment instruction.

Maker-checker control exists, but the checker approves the transaction without proper verification.

The payment is completed before the error is detected.

Risk Analysis

The event involves:

• human error;

• ineffective checking;

• process weakness; and

• potentially inadequate system validation.

Event Classification

RBI includes data-entry errors, transaction-processing errors and similar failures under Execution, Delivery and Process Management.

Scenario Lesson

The bank should not examine only the actual ₹8 crore incident.

Scenario analysis may ask:

What if the same control failure occurs in a much larger transaction or repeatedly across several transactions?

Possible mitigation includes:

• amount-validation alerts;

• stronger maker-checker controls;

• unusual-transaction thresholds; and

• targeted control testing.

Case Study 4: Cyberattack on Digital Banking

A bank observes rapidly increasing phishing and credential-theft attempts.

No major financial loss has yet occurred.

A scenario is developed in which:

• attackers obtain customer credentials;

• thousands of accounts are targeted;

• fraudulent transfers are initiated; and

• digital channels are temporarily restricted during incident response.

Analysis

The scenario should assess:

• fraud loss;

• customer impact;

• system capacity;

• incident-response speed;

• detection capability;

• communication; and

• recovery procedures.

Event Classification

If attackers steal funds or information for monetary gain, the incident may fall under External Fraud, which includes hacking damage and theft of information with monetary loss in RBI's event taxonomy.

However, if the same cyberattack mainly produces a system outage, Business Disruption and System Failures may also become relevant to analysis.

CAIIB Lesson

“Cyber risk” is not itself one universal Level 1 event category. Classification depends on what actually happens.

Case Study 5: Critical Vendor Failure

A bank outsources an important transaction-processing activity to one service provider.

The vendor:

• handles a large portion of daily transactions;

• has no readily substitutable alternative;

• has experienced several minor outages; and

• recently failed a resilience test.

A scenario assumes that the vendor becomes unavailable for two days.

Analysis

The bank should examine:

• concentration in the vendor;

• alternative processing;

• contractual obligations;

• service recovery;

• data availability;

• impact on customers;

• regulatory consequences; and

• exit arrangements.

The fact that the activity is outsourced does not remove the bank's operational-risk exposure.

Scenario Response

Possible actions include:

• alternative provider arrangements;

• improved contingency processing;

• stronger service-level monitoring;

• reduced concentration;

• joint resilience testing; and

• improved exit planning.

CAIIB Lesson

Outsourcing transfers performance of an activity, not responsibility for managing the resulting operational risk.

Case Study 6: Natural Disaster and Branch Operations

A bank has many important branches and processing facilities in a flood-prone region.

Historical flood losses have been small.

A scenario assumes:

• severe flooding;

• several branches become inaccessible;

• power and telecom services fail;

• cash movement is disrupted; and

• employees cannot reach normal workplaces.

Analysis

The bank should assess:

• alternative branches;

• remote-working capability;

• telecommunications backup;

• cash availability;

• customer communication;

• recovery time; and

• dependence on regional vendors.

Event Classification

Physical loss from a natural disaster falls under Damage to Physical Assets in RBI's taxonomy.

The same event may also create business disruption, demonstrating that a single external event can generate multiple operational consequences.

Case Study 7: Mis-Selling and Customer Compensation

A bank aggressively promotes a complex investment-linked product.

Internal complaints show that:

• staff training is incomplete;

• suitability assessments are weak;

• disclosures are inconsistent; and

• sales incentives strongly reward volume.

No major regulatory action has yet occurred.

Scenario

Assume widespread customer complaints result in:

• compensation;

• litigation;

• regulatory action; and

• product withdrawal.

Event Classification

RBI's Clients, Products and Business Practices category includes suitability and disclosure failures, aggressive sales, privacy breaches and certain improper business practices.

CAIIB Lesson

A scenario does not need to involve system failure or fraud. Conduct and product-related failures can also produce major operational losses.

How to Analyse an Operational-Risk Scenario

For CAIIB case studies, use E–C–I–R–A.

E — Event

What could happen or has happened?

C — Cause and Controls

Why could it happen?

Which control:

• failed;

• was missing; or

• may fail under stress?

I — Impact

Assess possible:

• financial;

• operational;

• customer;

• legal; and

• regulatory

consequences.

R — Risk Classification

Identify:

• source of operational risk;

• relevant event type; and

• residual risk.

A — Action

Determine whether the bank should:

• strengthen controls;

• improve resilience;

• transfer part of the financial impact;

• change the process;

• reduce exposure; or

• formally accept residual risk.

Finally, ask:

Has the scenario revealed a vulnerability that pushes the bank outside its risk appetite or tolerance?

Limitations of Scenario Analysis

Scenario analysis is useful but not perfect.

Subjectivity

Expert assessments may differ.

False Precision

A highly detailed numerical estimate may look more accurate than the underlying information justifies.

Scenario Blind Spots

Management may focus on familiar events while missing emerging risks.

Groupthink

Participants may share similar assumptions and underestimate extreme consequences.

Outdated Scenarios

Technology and external threats can change rapidly.

Basel therefore emphasises robust governance and independent review because scenario analysis contains significant judgement.

A good process should:

• use diverse experts;

• challenge assumptions;

• compare scenarios with internal and external events;

• document reasoning;

• periodically refresh scenarios; and

• connect outcomes with action plans.

CAIIB Exam Focus

Remember these high-value concepts:

• Scenario analysis is forward-looking.

• It is particularly useful for low-frequency, high-severity operational risks.

• Absence of historical loss does not prove low risk.

• Internal loss data is only one scenario input.

• External events can reveal risks not present in the bank's own history.

• RCSA, KRIs, near misses, root-cause analysis and control findings can support scenario development.

• Expert judgement is important but introduces subjectivity.

• A scenario should clearly define the event, causes, controls and consequences.

• Scenario analysis should consider both likelihood and impact.

• The effect of existing controls should be examined.

• Scenario results should be compared with risk appetite and tolerance.

• Scenario analysis can support business continuity and operational resilience.

• Scenario analysis and stress testing are related but should not automatically be treated as identical.

• Operational-risk event classification should focus on the nature of the event.

• Internal fraud requires involvement of an internal party.

• System failures are distinct from processing errors.

• Cyber events can fall into different event categories depending on their nature.

• Outsourced activities continue to create operational risk for the bank.

• Scenario analysis should result in mitigation, resilience improvement or conscious risk acceptance.

• Scenarios must be periodically reviewed as threats and processes change.

Common Exam Traps

Trap 1: “Scenario analysis uses only historical internal loss data.”

Incorrect. It may use internal and external events, RCSA, KRIs, control information, root-cause analysis and expert judgement.

Trap 2: “A bank need not analyse an event that has never happened before.”

Incorrect. Rare severe events are a major reason for scenario analysis.

Trap 3: “Scenario analysis is useful only for estimating financial loss.”

Incorrect. Operational, customer, legal, regulatory and continuity impacts may also be relevant.

Trap 4: “The existence of a backup system proves that system-failure risk is low.”

Incorrect. Failover and recovery arrangements must work under the actual disruptive scenario.

Trap 5: “Every cyber incident is classified as External Fraud.”

Incorrect. Classification depends on the event. Cyber incidents can also create system disruption or other operational effects.

Trap 6: “A processing error and internal fraud belong to the same event category.”

Incorrect. Processing error generally falls under Execution, Delivery and Process Management, while deliberate internal misconduct may be Internal Fraud.

Trap 7: “Outsourcing eliminates the bank's operational-risk exposure.”

Incorrect. Vendor dependency and service failure remain risks requiring management.

Trap 8: “The most extreme imaginable event is always the best scenario.”

Incorrect. Scenarios should be severe enough to challenge the bank but also sufficiently plausible and useful for decision-making.

Trap 9: “Once a scenario is developed, it can be used permanently.”

Incorrect. Changes in technology, business activities, threats and controls require periodic review.

Trap 10: “Scenario analysis is complete once likelihood and impact are estimated.”

Incorrect. The important final steps are assessing control adequacy, comparing residual risk with appetite and implementing necessary action.

Memory Technique

Remember W–W–S–A:

W — What can happen?W — Why can it happen?S — So what is the severity?A — Action: what should the bank change?

For event cases, use:

Cause → Event → Impact → Classification → Mitigation

The central CAIIB principle is:

Scenario analysis prepares the bank for serious events that historical experience alone may fail to reveal.