Cloud Outage in Real-Time Payments: Loss Classification, Capital and Resilience Spend
A mid-sized retail bank runs its real-time payments service on a single cloud region. The business impact analysis assigns the service an RTO of 2 hours and an RPO of 15 minutes. A provider outage took the service down for 7 hours. A manual workaround cleared 12% of normal volume; about 340,000 payments were delayed, 2,100 customer complaints were logged, and the bank paid GBP 1.2m in customer remediation plus GBP 0.4m in a regulatory settlement. The internal loss database contains three comparable events over five years. Operational-risk capital is calculated under the Basel standardised approach; the business indicator is GBP 2.0bn. Management proposes buying a larger insurance policy rather than funding a second cloud region at GBP 18m over three years.
1. Classify the event, explain how the GBP 1.6m flows through the financial statements, and state whether it changes the regulatory operational-risk capital requirement.
Read the worked answer
Classification. Basel level 1: Execution, delivery and process management - system failure / third-party service disruption. The level 2 sub-category would identify the vendor or utility dependency.
Loss treatment. Both components are operational-risk losses and belong in the loss database: the GBP 1.2m customer remediation (compensation/redress) and the GBP 0.4m regulatory settlement. Total GBP 1.6m charged to P&L, reducing pre-tax earnings.
Capital. Under the standardised approach: BI = GBP 2.0bn places the bank in bucket 2, so BIC = 0.15 x 2.0bn = GBP 300m; ILM = 1 for buckets 1-3, so operational-risk RWA = 12.5 x 300 = GBP 3,750m. The GBP 1.6m loss enters neither BI nor BIC nor ILM. It reduces CET1 only through retained earnings - roughly GBP 1.2m after tax at 25%.
Judgement. 'It does not affect the formula' is not 'it does not matter'. The loss consumes buffer above the requirement, is visible to the supervisor, and is a data point in the tail that the capital number does not reflect. The danger is reading a flat capital requirement as evidence that a 7-hour outage of a critical payment service is adequately covered. The standardised approach charges for business volume, not for concentration in a single provider - which is exactly the risk here.
2. Evaluate the choice between a larger insurance policy and funding a second cloud region. What quantitative and qualitative factors should decide it?
Read the worked answer
Frame the decision correctly: resilience versus financing, not insurance versus nothing.
Insurance reimburses financial loss after the deductible and only for covered perils. Policies commonly exclude or sub-limit contingent business interruption arising from a supplier's failure, and a large disputed claim pays slowly. It does not restore the RTO - the bank still breached 2 hours by 5 hours - and it does not touch the uninsured franchise cost of 340,000 delayed payments and 2,100 complaints.
A second region costs GBP 6m per year, reduces both the frequency and the severity of the tail (a 7-hour outage becomes a failover of minutes), and removes an unhedged single-provider concentration. It pays nothing when a loss occurs anyway.
The numbers. With three events in five years, expected annual loss on this scenario is roughly 0.6 x GBP 1.6m = GBP 1m, which on its own does not justify GBP 6m per year. But expected loss is the wrong decision metric for a critical payment service. The severity distribution is heavy-tailed: a 24-hour outage over month-end or payday produces redress, supervisory action and customer attrition an order of magnitude above GBP 1.6m, and the manual workaround only cleared 12% of volume - the backlog itself becomes a risk.
Conclusion. The single-region dependency is a concentration that insurance cannot fix, and the RTO breach is a resilience failure rather than a funding shortfall. Fund the second region for the critical service and use insurance for the residual loss layer - a second layer, not a substitute.
3. The CRO proposes setting the limit for this event type from the bank's own data: 3 events in 5 years, so 0.6 per year. Critique the estimate and say what should be used instead.
Read the worked answer
The point estimate is close to uninformative. With 3 observed events, the exact Poisson 95% confidence interval for the rate over five years is approximately (0.62, 8.77), i.e. 0.12 to 1.75 events per year. The upper bound is nearly three times the point estimate. Any limit calibrated on 0.6 alone is calibrated on noise.
Additional problems with the internal data:
- The observation window is short relative to the return period that matters, and the process is not stationary - moving to a single cloud region changed both the frequency and the severity of the event class, so the three historical events may not be drawn from the current distribution.
- Reporting thresholds and near-miss capture vary over time, so the count is a floor, not an estimate.
- The events are heterogeneous: a 30-minute degradation and a 7-hour outage are different animals, and pooling them blurs the tail.
What to use instead:
- External consortium or vendor loss data, scaled to the bank's exposure (payment volumes, number of critical services, number of third-party dependencies) rather than scaled by gross income.
- A scenario for the severe-but-plausible case - 24-hour outage at peak - priced end to end including redress, fines and attrition.
- Set the limit and the economic capital number on the scenario or the 99th percentile of the combined distribution, not the historical mean. Note that none of this feeds the standardised-approach capital formula, so its real purpose is limit setting, economic capital and the resilience investment case - which makes getting the tail right more important, not less.