Charta is on Google Play: practise on the go. Get the app
Charta

Characterise good practice for pinpointing extreme operational risk events.

FRM® Part II · Operational Risk and Resilience · Risk Identification · FRM2.ORR.3.b

The idea

Extreme operational events are rare and severe, so most firms have few or none in their own loss history, and extrapolating past losses understates the tail. Good practice for finding them is forward-looking and structured. Run facilitated scenario analysis with senior management and subject-matter experts, informed by external loss data, public events and internal near misses. Build scenarios that are plausible but severe, combining several failures at once, such as a control breakdown, a critical third party failing and a market stress. Examine interdependencies and concentrations like a shared vendor or system. Use reverse stress testing, starting from an outcome that threatens viability and working back to its causes. Guard against anchoring on past losses. Document assumptions, subject the results to independent challenge and refresh them regularly. A scenario is not invalid because it has never happened.

A practice question

From the question bank, with the reason each wrong option is wrong.

Which of the following is good practice when using scenario analysis to identify extreme operational risk events?

  1. Involve senior management and subject-matter experts in structured workshops, with external loss data and near misses as inputs. - correct
  2. Limit scenarios to events that have already occurred at the firm, so every estimate can be verified.Why not: Restricting scenarios to past events defeats the purpose, since extreme events are rare and may never have occurred internally.
  3. Assume every control works as designed, so that the scenarios remain plausible.Why not: Assuming controls never fail removes the very failures that produce extreme events.
  4. Let the owning business line set each scenario's severity and frequency from its own judgement, without any independent review or challenge.Why not: Without independent challenge, owners may understate severity; good practice includes review and challenge.

Structured workshops that bring together senior management, experts, external data and near-miss evidence are the standard route to identifying extreme events. The other options either backward-anchor the scenarios, assume perfect controls or omit challenge.

A harder one

A bank builds a scenario in which a critical outsourced provider fails, the backup site in the same region is unavailable, and a market shock raises transaction volumes at the same time. Which good practice does this illustrate?

  1. Backtesting the scenario against the firm's internal loss history to confirm that its calibration matches what has actually been observed.Why not: Backtesting compares predictions with realised losses; the scenario combines failures and is not calibrated to history.
  2. Designing plausible but severe scenarios that combine several failures and capture interdependencies. - correct
  3. Setting key risk indicator thresholds that give early warning of rising exposure.Why not: KRIs are monitoring metrics; building a combined-failure scenario is a different activity.
  4. Transferring the risk to an insurer so that the residual exposure is reduced.Why not: Risk transfer is a response to a risk already identified, not a method of identifying extreme events.

Extreme losses usually come from several things going wrong together. Combining a vendor failure, a failed backup and a volume spike in one scenario tests interdependencies and concentrations, which is the plausible-but-severe design.

The hardest tier

A firm wants to identify the combinations of events and control failures that could exhaust its capital or stop its critical services. Which approach starts from the outcome and works backward to the causes?

  1. Reverse stress testing, which defines the damaging outcome first and then searches for the chains of events that could produce it. - correct
  2. A historical scenario rerun, which replays a past event using today's exposures and projects the loss forward from that known starting point.Why not: This starts from a known event and projects forward; it does not start from an outcome and work back to causes.
  3. An RCSA, which totals the residual risk of controls rated ineffective.Why not: An RCSA works from processes and controls upward and is not driven by a target outcome.
  4. Backtesting, which compares predicted loss frequencies with those that actually occurred.Why not: Backtesting validates a model against realised results; it identifies no new event chains.

Reverse stress testing fixes the unacceptable outcome, such as capital exhaustion or loss of critical services, and then asks what combination of events and failures could cause it. This surfaces extreme events that forward scenarios may overlook.

In the app: 6 practice questions on this outcome, spaced review that brings it back before you forget it.

Start free →

More in Risk Identification