How do I set up a scenario analysis platform for simulating price shocks across power, gas, and oil positions?

To set up a scenario analysis platform for simulating price shocks across power, gas, and oil positions, design it as a pipeline with four layers:

1. Market data ingestion
2. Scenario generation
3. Portfolio valuation / risk engine
4. Reporting and controls

Here’s a practical blueprint.

---

1) Define the business scope

Start by being explicit about:

• Products: spot, forwards, futures, swaps, options, storage, transport, swing, spark/dark spreads
• Asset classes: power, gas, oil, related FX and emissions if relevant
• Regions / hubs: e.g. UK power, EEX, PJM, Henry Hub, TTF, JKM, Brent, WTI, etc.
• Risk measures: PnL, delta, gamma, VaR, stress loss, CVaR, Greeks, liquidity-adjusted metrics
• Time granularity: intraday, daily, monthly, quarterly
• Horizon: overnight shock, 1 week, 1 month, multi-year
• Use case: trading, risk, hedging, stress testing, regulatory reporting

This determines how complex your models need to be.

---

2) Build the data foundation

Inputs you need

• Prices
  • Power curves by region and tenor
  • Gas hub curves
  • Oil benchmarks and differentials
• Volatility surfaces
  • For optionality and stress testing
• Correlations
  • Cross-commodity correlations: power-gas, gas-oil, oil-FX, power-load, etc.
• Fundamentals
  • Load, weather, outages, storage, LNG flows, refinery runs, pipeline constraints, hydro, renewables
• Position data
  • Trades, volumes, delivery dates, optionality terms, mark-to-market info
• Curve metadata
  • Commodity, hub, tenor, contract type, currency, units, seasonality rules

Data design

Create a canonical schema so all markets look similar:

• instrument_id
• commodity
• hub/region
• delivery_start, delivery_end
• price, currency, unit
• curve_type (spot, prompt month, seasonal strip, etc.)
• source
• timestamp

Use a time-series store or warehouse, plus an in-memory layer for simulation runs.

---

3) Create a consistent risk factor model

Don’t simulate each instrument independently. Map everything to a smaller set of risk factors:

Example risk factors

• Power:
  • Regional baseload / peakload curves
  • Spark spread drivers
• Gas:
  • Hub price curves
  • Basis differentials
• Oil:
  • Brent / WTI prompt and curve points
  • Crack spread components if relevant
• Macro:
  • FX, rates, carbon, weather indices

Factor representation

Represent each curve as:

• Level
• Slope
• Curvature
• Seasonal components
• Calendar spread relationships

This makes scenarios more realistic and easier to shock consistently.

---

4) Define scenario types

Your platform should support several scenario classes:

A. Deterministic shocks

Simple, transparent scenarios:

• Brent +10%, TTF -15%, power +20%
• Gas up more than power
• Regional outage causing power spike
• Winter demand shock
• LNG disruption scenario

B. Historical replay

Use past events:

• Russia/Ukraine gas shock
• Texas freeze
• COVID demand collapse
• OPEC supply shock

C. Statistical scenarios

Generate shocks from distributions:

• Monte Carlo on factors
• Correlated shocks
• Mean reversion and jumps
• Regime-switching volatility

D. Custom stress scenarios

User-defined combinations:

• Supply disruption + weather extreme + FX move
• Inventory draw + freight spike + refinery outage

E. Reverse stress testing

Find the shock that causes:

• breach of limits
• margin call
• liquidity shortfall
• specified loss threshold

---

5) Model cross-commodity relationships

Power, gas, and oil are linked, but not always linearly.

Useful relationships

• Power ↔ Gas
  • Gas-fired generation sets marginal price in many markets
  • Spark spread: Power - Heat Rate × Gas
• Power ↔ Carbon
  • Emissions costs affect generation economics
• Gas ↔ Oil
  • Less direct, but linked through global macro, LNG, substitution, and fuel demand
• Crude ↔ Products
  • Crack spreads for refined products
• Weather ↔ Power/Gas
  • Load and heating demand

Practical approach

Use a hybrid model:

• Core factor correlations for baseline
• Rule-based conditional shocks for crisis regimes
• Spread relationships for economically linked products

Example:

• If gas rises 20%, power may rise 8–15% depending on fuel mix and market structure
• In constrained markets, power can spike more than gas

---

6) Choose valuation methodology

The scenario engine needs a pricing layer.

For linear products

• Revalue positions using shocked forward curves:
  • futures, swaps, forwards, CFDs
• PnL = shocked MTM - base MTM

For optionality

Use:

• Black-76 / Black-Scholes-style models for simple options
• Tree / lattice models if needed
• Monte Carlo for path-dependent payoffs
• Fundamental dispatch models for power options or tolling

For physical assets

Include operational constraints:

• storage inventory limits
• injection/withdrawal rates
• pipeline capacity
• generation dispatch
• minimum up/down constraints

For many energy portfolios, a dispatch-aware valuation engine is critical.

---

7) Build the scenario engine

A good architecture:

Step 1: Load base curves

Pull the latest clean market data.

Step 2: Apply scenario shock rules

Each scenario produces transformations on risk factors:

• parallel shifts
• term-structure twists
• volatility shifts
• basis widenings
• correlation regime changes

Step 3: Map factor shocks to instrument prices

Convert factor changes back to instrument-level prices.

Step 4: Revalue portfolio

Run valuation/pricing models on all positions.

Step 5: Aggregate results

Produce:

• desk
• commodity
• region
• strategy
• legal entity
• trader
• maturity bucket

Step 6: Store and compare

Save scenario runs for:

• audit trail
• replay
• comparison over time

---

8) Add calibration and plausibility controls

Scenarios should be realistic and governed.

Controls

• Historical range checks
• Cross-factor consistency checks
• Limit on correlated moves
• Term-structure smoothness
• Seasonality preservation
• Sign constraints where economically necessary
• User approval for extreme scenarios

Example checks

• Power price cannot be negative in some markets unless your model allows it
• Gas basis should stay within plausible transport constraints
• Long-dated shocks should fade toward equilibrium unless a structural scenario is intended

---

9) Make it interactive for users

Users need to define and compare scenarios easily.

UI features

• Scenario builder with sliders and templates
• Base vs shocked curve charts
• PnL waterfall
• Risk factor heatmap
• Position sensitivity by tenor
• Comparison of multiple scenarios
• Scenario library and bookmarks

Helpful outputs

• Top contributors to loss/gain
• Worst instruments
• Margin impact
• Threshold breaches
• Hedged vs unhedged comparison

---

10) Use a scalable technical architecture

Typical stack

• Data lake / warehouse: Snowflake, BigQuery, Redshift, Databricks
• Time-series store: kdb+, TimescaleDB, InfluxDB
• Compute: Python, Spark, C++ for pricing hot paths
• Workflow orchestration: Airflow, Prefect, Dagster
• API layer: FastAPI, Java/Spring, .NET
• UI: React, Angular, or Tableau/Power BI for reporting
• Messaging: Kafka or RabbitMQ for feeds and async runs

Suggested system pattern

• Batch jobs for end-of-day risk
• Event-driven updates for intraday shocks
• Cached base valuations to speed up re-runs
• Parallelized revaluation by book, commodity, or maturity

---

11) Governance, audit, and model risk

Because this affects trading and risk decisions, add controls:

• Version every scenario definition
• Version pricing models and market data
• Keep audit logs of who ran what and when
• Validate models with backtesting and historical replay
• Separate scenario authoring from approval
• Keep explainability: why did PnL change?

This is especially important for regulatory and internal model governance.

---

12) A practical MVP roadmap

Phase 1: MVP

• Ingest base curves and positions
• Support deterministic shocks
• Revalue linear products
• Generate PnL reports

Phase 2: Better realism

• Correlated shocks
• Historical replay
• Volatility shocks
• Curve twist/steepening scenarios
• More commodities and regions

Phase 3: Advanced risk

• Optionality revaluation
• Physical dispatch
• Monte Carlo simulation
• Reverse stress testing
• Intraday streaming updates

---

13) Example scenario specification

A simple scenario definition might look like this:

{
  "scenario_name": "Winter supply shock",
  "date": "2026-01-15",
  "shocks": [
    {"risk_factor": "TTF_prompt", "type": "percent", "value": 25},
    {"risk_factor": "UK_power_Q1", "type": "percent", "value": 18},
    {"risk_factor": "Brent_prompt", "type": "percent", "value": 8},
    {"risk_factor": "gas_power_correlation", "type": "override", "value": 0.85}
  ]
}

Your engine would:

1. Load current curves
2. Apply these shocks
3. Reprice positions
4. Report PnL and risk metrics

---

14) Key design recommendation

The biggest mistake is to build the platform around instruments instead of risk factors.
Model the underlying market drivers first, then map positions to them. That makes shocks more consistent across power, gas, and oil and avoids contradictory scenario outcomes.

---

If you want, I can also provide:

1. a reference architecture diagram,
2. a data model/schema, or
3. a sample Python implementation of the scenario engine.