Scenario analysis is broken. Here's the blueprint for fixing it.

Every bank I have worked in or examined alongside runs some version of the same scenario analysis process, and it fails in the same four ways. This essay names the failures precisely, explains why the standard process cannot fix them, and lays out the blueprint I am building against, in the open, as a working prototype.

I should establish standing before throwing stones: I have facilitated these workshops, owned the aggregate numbers they produced, and defended those numbers in front of examiners and committees. The criticism here is self-criticism. The process I am describing is one I ran, as well as the industry standard.

The four failures

The narratives are static. Scenario analysis in most institutions is an annual event. The narratives (cyber attack, third-party failure, processing error, conduct event) get written once, then lightly edited each year by whoever inherits the file. The threat landscape they describe moves continuously; the narratives move annually, if that. By month eight, the bank’s official view of its tail risk describes a world that no longer exists. Nobody considers this scandalous because everybody’s process works this way.

The anchoring is unmanaged. Get twelve senior people in a room and ask for a severe loss estimate. The first number spoken becomes the anchor; every subsequent estimate is a negotiation against it. This is the most reliably documented bias in group estimation, and the standard workshop format does nothing to counter it: no independent estimates before discussion, no structured decomposition of the loss into drivers, no reconciliation against the bank’s own loss history or relevant external events. The output is a socially negotiated number wearing the costume of an analytical one.

The challenge is theatre. Effective challenge is the load-bearing wall of the second line, and the scenario workshop is where it is weakest. The people positioned to challenge the narrative helped write it. Dissent, when it happens, is recorded as a sentence in the minutes and resolved by the facilitator moving the meeting along. Contrast that with what challenge means anywhere else it is taken seriously: a documented position, a documented response, and an artifact showing how the disagreement was resolved. Most scenario processes produce nothing of the kind, and most practitioners know it.

The audit trail is a reconstruction project. Eighteen months later, an examiner asks the only question that matters: how did the bank arrive at this number? The honest answer lives in a deck, a spreadsheet with no version history, and the fading memory of whoever facilitated. I have watched capable teams spend weeks reconstructing the provenance of a single scenario estimate. A process whose output feeds capital discussions and board risk appetite should not require archaeology to explain itself.

The bar has moved

These failures were tolerable when scenario analysis was a compliance exercise. It is not one anymore.

CCAR expectations around scenario design and the supporting analytics have hardened over a decade; the Federal Reserve’s capital-planning letters (SR 15-18 for the largest firms, SR 15-19 for the next tier) are explicit that estimation approaches and their assumptions must be documented and supportable. The UK regime made “severe but plausible” the operative testing standard for resilience, and the phrase does real work: severe rules out the comfortable middle of the distribution, plausible rules out hand-waving, and demonstrating both requires method. OSFI’s E-21 expects scenario testing of critical operations, with the full guideline in force by September 2026. The Basel Committee’s revised operational risk principles assume scenario analysis is a governed, repeatable component of the framework, not an offsite.

Read against that bar, the annual workshop is not a quaint tradition. It is a finding waiting for an examination team with time to look.

The blueprint

The fix is not a better workshop. It is a different process, one where generation, challenge, and evidence are properties of the system rather than aspirations of the facilitator. The blueprint has four requirements.

Continuous, profile-driven generation. Scenario narratives should be generated from the bank’s actual profile (business mix, geography, technology and third-party dependency map, internal loss history, relevant external events) and regenerated when the profile changes. A new critical vendor, a new business line, a major industry loss event: each should perturb the scenario set within days, not at the next annual cycle. This is precisely the kind of structured synthesis language models are good at, and precisely the kind of ongoing maintenance humans never get budget for. The narratives stay severe and current, with quantified loss ranges built from decomposed drivers rather than a number conjured whole in a meeting.

Independent estimates before negotiation. Anchoring is beaten by structure, not willpower: independent quantification against the same narrative before any group discussion, explicit decomposition of loss drivers, and automatic reconciliation against internal losses and external comparators. Where estimates diverge, the divergence itself becomes analytical material; the interesting question is always why two informed views differ by 5x.

Challenge as a workflow, not a virtue. A two-pass challenger workflow, enforced by the system: first pass attacks the narrative (plausibility, completeness, ignored dependencies), second pass attacks the quantification (anchors, distributional assumptions, coherence with the data). Every challenge is a structured artifact with a documented response and resolution. Producers, challengers, and approvers are separated by role-based access control, the way a bank separates them everywhere else it means it. Challenge stops being a personality trait of the second line and becomes a property of the process.

Evidence as a by-product. Every narrative version, estimate, challenge, response, and approval logged at the moment it happens, so the answer to “how did the bank arrive at this number” is a query, not a project. The audit trail is not a report someone writes after the fact. It is the exhaust of the process working.

None of these requirements is exotic. Together they describe a process that is defensible by construction, and buildable now, which is the point. I have built it: DELPHI, a working prototype implementing all four requirements, with a realistic mid-tier demo bank so the workflow can be walked end to end. The build and its design decisions are documented in the Lab, and the companion page explains what it does and does not claim to be. It is a blueprint, not a product, published so practitioners and supervisors can challenge it, which is the treatment I am arguing every scenario deserves.

The uncomfortable conclusion

The tools banks use shape the arguments banks can make. As long as scenario analysis runs on an annual workshop and a spreadsheet, its outputs will be exactly as defensible as the workshop was, which is to say defensible until someone competent asks. A discipline that exists to institutionalize challenge should be embarrassed by how little of it its own flagship process can withstand.

The bar is now demonstration, with evidence. The machinery to meet it exists. What remains is the will to admit that the current process fails four ways at once, and to rebuild it rather than refresh the deck one more year.