AI-assisted scenario and stress testing

AI belongs to the mechanical half of stress testing. It can expand a scenario set, translate a narrative into the parameters your engine expects, and summarize what moved between two runs. It should never set the assumptions or produce a number itself. A human decides which shocks matter and signs off; a deterministic engine computes every figure. Keep that split and the work goes faster.

Stress testing is two jobs wearing one name. One job is deciding what to worry about: which shocks are plausible, how they correlate, and where the balance sheet actually breaks. The other is the grinding mechanics of building each scenario, running it, and reading the output. That second job is where most of the calendar goes, and it is the job AI can shoulder.

An analyst copies a base forecast, adjusts a rate path, re-derives the funding cost, checks that the collateral haircuts moved the right way, then formats the result so a committee can read it. Multiply that by thirty scenarios and two reporting cycles and you have weeks of work that is mostly re-plumbing the same model with different dials. That re-plumbing is where AI earns a place, because it is repetitive and checkable against a deterministic engine.

Where the model helps, and where it must not touch

The safe division of labor is narrow and worth stating precisely. The model generates and manipulates scenario definitions. It never produces the numbers.

• Scenario expansion. Give it a handful of named scenarios and it can enumerate the neighboring ones you skipped: the same rate shock with wider deposit runoff, the same recession with a lagged unemployment peak, the combination of two shocks you had only run separately. This is combinatorial bookkeeping, and it is exactly the kind of coverage gap a human misses at quarter-end under deadline.
• Parameterization. Translating a narrative (“severe adverse: rates up 300bps, GDP down 4 percent, CRE values off 25 percent”) into the structured inputs your calculation engine expects. The model fills the parameter template. The engine does the math.
• Reading output. Summarizing which portfolios drove a capital shortfall, which line items moved most between two runs, where a covenant flipped. This is retrieval and comparison over numbers that already exist, not new numbers.

What the model must not do is compute. Ask it to estimate a loss given default or roll forward a cash position by generating text, and it will hand you a figure that reads correctly and reconciles to nothing. The rule I hold to: the AI passes parameters to the same engine your analysts run, and every output cell has a lineage back to that engine. A number that cannot be traced to a computed cell does not go in the deck.

Scenario generation without the hallucinated tail

The appeal of a language model here is that it can propose scenarios a template never would. The hazard is that it proposes scenarios that sound severe but are internally inconsistent, or that quietly leak information a real forecast could not have.

Two failures show up repeatedly. The first is incoherence: a scenario where rates spike but credit spreads stay flat, or unemployment rises while consumer defaults fall. The narrative reads fine, and the model has no economic prior that stops it. The fix is to run every generated scenario through a consistency check before it reaches the engine. Encode the relationships you actually believe as constraints the scenario must satisfy or be flagged against: spreads widen with rates, defaults rise with unemployment.

The second failure is lookahead. If the model has seen the realized path of a variable, it will happily generate a “hypothetical” that hugs what actually happened. That is leakage in a different costume, and it makes a stress test look better calibrated than it is. Wall scenario generation off from any point-in-time data past the as-of date, the same discipline you would apply to a forecasting feature.

I treat generated scenarios as candidates for an eval set, not as results. Each one gets scored on coverage, meaning whether it exercises a part of the balance sheet the existing suite ignores, and on plausibility, meaning whether it survives the consistency constraints. A human keeps the ones worth running. The model’s job was to widen the search, not to close it.

Sensitivity analysis and the audit trail

Sensitivity analysis is where AI-assisted tooling pays for itself, because the work is genuinely mechanical: hold everything fixed, move one input across a range, record how the output responds. Doing this by hand for twenty inputs is tedious and error-prone, and the errors hide well because every intermediate result looks reasonable.

Here the model orchestrates rather than calculates. It builds the grid of parameter sets, dispatches each to the engine, and assembles the response surface. Because the engine is deterministic, the entire run is reproducible: same inputs, same code version, same numbers. That reproducibility is the whole game for anyone who has to defend the result later.

For a regulated stress program, the audit trail is not paperwork you bolt on at the end. Under SR 11-7, supervisors expect model outputs to be reproducible and assumptions to be documented and subject to effective challenge, and the EU AI Act’s record-keeping and human-oversight obligations for in-scope high-risk systems point the same direction. In practice that means three concrete things:

• Every scenario carries its inputs, the engine version, and the identity of the person who approved the assumptions.
• Every run diffs against the prior run, so a reviewer sees what changed rather than re-reading a full deck.
• The AI’s contribution is logged as what it did: expanded these scenarios, flagged these inconsistencies, summarized these deltas. None of that logging includes a number the model produced on its own, because it did not produce any.

The line to hold is the one from the top. A person decides what to stress and why, and signs their name to it. The machine handles the volume. When a committee asks why a scenario was chosen, the answer is a human judgment with a rationale. When it asks how the number was computed, the answer is an engine run you can reproduce on demand. Keep those two answers separate and AI makes the exercise faster. Blur them and you have automated the part that was never the problem while corrupting the part that was.