DELPHI
A working prototype that rebuilds bank scenario analysis: severe-but-plausible narratives with quantified loss ranges, a two-pass challenger workflow, and a full audit trail.
The problem
In most banks, scenario analysis is a once-a-year workshop. A facilitator books a room, a dozen senior people surrender an afternoon, and the institution’s view of its tail risk gets set by whoever speaks most confidently before the coffee runs out.
The failure modes are well known to anyone who has run the process. The narratives are static: written once, refreshed annually if at all, stale the moment the threat landscape moves. Anchoring bias is unmanaged: the first loss number spoken aloud becomes the gravitational center of the estimate. Challenge is weak, because the people positioned to challenge are in the room producing, and dissent recorded in minutes is not the same as challenge built into method. And the audit trail (the thing an examiner will actually ask for) is a deck, some emails, and a spreadsheet of numbers whose provenance nobody can fully reconstruct eighteen months later.
None of this survives contact with current expectations. CCAR scenario design expectations, the PRA’s severe-but-plausible standard for resilience testing, and Basel’s Principles for the Sound Management of Operational Risk all assume something banks rarely have: a scenario process that is repeatable, challenged, and evidenced.
What it does
DELPHI is a four-module platform that rebuilds the process end to end:
Generation. The generator produces severe-but-plausible scenario narratives grounded in the bank’s own profile (business mix, geography, dependency map, loss history), with quantified loss ranges attached to each narrative rather than bolted on afterward. Scenarios are versioned; when the profile changes, the scenarios change with it.
Challenge. A two-pass challenger workflow institutionalizes effective challenge instead of hoping for it. The first pass attacks plausibility and completeness: what the narrative assumes, what it ignores. The second attacks the quantification: anchors, distributional assumptions, coherence with internal and external loss data. Every challenge and every response is captured as a structured artifact, not a meeting note.
Governance. Role-based access control separates producers, challengers, and approvers the way a bank’s control environment actually requires. Nothing reaches “approved” without the workflow that a regulator would expect to find.
Audit trail. Every narrative, estimate, challenge, revision, and approval is logged and reconstructable. The question “how did the bank arrive at this number” has a complete answer, on demand.
The prototype ships with a demo tenant (Meridian Bancorp, a realistic mid-tier bank profile) so the full workflow can be walked end to end with plausible data and no confidentiality issues.
Why it matters
Scenario analysis is where a bank’s forward-looking view of operational risk either becomes credible or doesn’t. It feeds capital discussions, stress-testing narratives, resilience testing under the UK regime and OSFI E-21, and the board’s understanding of tail exposure. A process this consequential deserves better machinery than an annual workshop; the supervisory direction of travel makes the current machinery a finding waiting to happen.
Honest framing
This is a working prototype and a blueprint, not a product. It exists to demonstrate that the process can be rebuilt (continuously generated, structurally challenged, fully evidenced) and to document the design decisions that make it defensible.