Derivatives scenario analysis with LSEG data

A scenario view answers one question: how does this position's value change when the market moves in a specified way, and how much of that change is real rather than an artefact of the inputs? The output is a table of base and shocked values with the assumptions written next to them. A single shocked number with no base, no shock definition and no curve date is not a scenario; it is a guess with a decimal point.

1. Pin down the position and the base case before any shock

Confirm with the user, in one line each:

• Instrument type and terms. Swap (fixed/floating, currency, tenor, notional, payment frequency), option (underlying, strike, expiry, call/put, exercise style), or a rate-sensitive bond or swap book.
• Valuation date. Every curve, surface and price must refer to the same date. Mixed dates are the most common silent error in this kind of work.
• Direction of the exposure. Long or short each leg. A receiver swap and a payer swap are opposite bets on the same curve.

Then establish the base value with ir_swap (for swaps) or option_value (for options). Record the base as the reference for every later comparison. If the base cannot be computed, stop and say so; a scenario without a base is not reportable.

2. Choose the market input that actually drives the instrument

Match the input to the risk factor, not to the tool you know best:

• Linear rate exposure (swap, bond-like cashflows): interest_rate_curve is the primary input. Use inflation_curve if the cashflows are inflation-linked, and credit_curve only if the position carries credit spread risk.
• Optionality (caps, swaptions, equity or FX options): the volatility surface is the primary input, not the spot. Use fx_vol_surface for currency options and equity_vol_surface for equity options. Note that a parallel spot shock with unchanged vol understates an option's risk materially, so shock vol separately.
• FX forwards and cross-currency swaps: fx_forward_curve and fx_spot_price. Shock spot and the forward points separately if the question is about funding basis.

If the tool needed for a leg is absent from the connector, say which leg you could not model and what that does to the total. Do not substitute a rough proxy and present it as the scenario.

3. Define shocks explicitly, then run them

Use shocks that a risk reader would recognise, and write each one down before running it:

• Parallel rate shift: +/-25, +/-100 bp across the curve. Report the shock size in basis points.
• Steepening or flattening: short end and long end moved in opposite directions by the same size. This matters more than parallel moves for curve-slope positions.
• Volatility shift: absolute vol points (for example +5 vol points) for a parallel vol move, not a relative percentage, unless the user asks otherwise.
• Spot move for options and FX: percentage moves with the direction stated.
• Historical or user-supplied scenarios: use the user's numbers exactly and label them as such.

Run each shock through yieldbook_scenario_calculation for bond-type cashflows where it applies, or re-price the swap or option with the shocked inputs. For sensitivities (DV01, vega, delta), use fixed_income_risk_analytics where the position is fixed-income, and compute the finite-difference sensitivity yourself from the base and shocked values, stating the bump size used.

4. Check the inputs before trusting the outputs

Before reporting, look for the conditions that make a scenario misleading:

• Stale or flat curves. A curve that is identical across all tenors, or whose latest point is far older than the others, will produce a near-zero rate sensitivity that looks plausible. Flag it.
• Non-monotonic or implausible vol. Vol that falls sharply across strikes or tenors with no market reason suggests a bad surface point. Flag the point, do not smooth it silently.
• Inconsistent dates between the curve, the surface and the spot. Re-run on a matched date or report the mismatch.
• Empty or partial results from any tool. An empty result is not a zero. Report it as missing and exclude that leg explicitly.

5. Separate the scenario from the interpretation

Report the numbers first, then your reading of them. Keep these distinct:

• Sourced: values returned by the tools, with the date and the input they came from.
• Calculated: differences, sensitivities and totals you computed, with the formula and bump size stated.
• Interpreted: what the result suggests about the book, hedging or risk appetite. Mark this as opinion.

Common patterns and traps

• Ignoring convexity. Linear DV01 misstates large moves on options and long-dated swaps. Run the full re-price for shocks above about 50 bp and say why.
• Shocking the wrong side of an option. Vega is positive for long options and negative for short ones. A short-vol book loses on a vol rise even when delta is hedged.
• Mixing absolute and relative shocks. "10% vol up" on a 20 vol surface is 2 points; "10 points" is far larger. State the convention.
• Netting legs with different currencies or dates without converting. Convert at the stated spot and date, or report by currency.
• Presenting one shock as the stress. A single parallel shock says little about a steepening curve position. Test at least a parallel and a slope scenario.
• Forgetting the base is also a model output. Scenario changes are only as good as the base valuation. If the base disagrees with a known traded level, fix that first.

Output

Position: <instrument, notional, tenor, direction, valuation date>
Base value: <value> (source: <tool>, <date>)

Scenario table
| Shock (definition)              | Scenario value | Change vs base | Change % |
|---------------------------------|----------------|----------------|----------|
| Parallel +100 bp                | ...            | ...            | ...      |
| Parallel -100 bp                | ...            | ...            | ...      |
| Steepen 2s10s +25 bp            | ...            | ...            | ...      |
| Vol +5 points (absolute)        | ...            | ...            | ...      |

Sensitivities: <DV01 / vega, bump size, method>
Inputs checked: <curve/surface date, any stale or flat points, any empties>
Legs not modelled: <what was excluded and its likely effect>
Assumptions: <day count, compounding, vol convention, currency>
Sourced vs calculated vs interpreted: <one line each>
Not established: <what you could not verify>

Rules

• Do not present a scenario value as a licensed market quote. Model output built on LSEG inputs is an analytical estimate; say so in the output.
• Do not run any calculation that writes, saves or publishes a scenario, report or shared model. Running a scenario or saving its output to the user's workspace counts as a change: wait for the user's explicit yes before saving, sharing or scheduling anything.
• Do not substitute a proxy curve or surface for a missing one without saying so and quantifying the difference.
• Never report a shocked value without its shock definition, base date and input source.
• Do not hide an empty or failed tool result as zero exposure.

Done when

• Base value is established and dated, and every scenario is shown as a change against it.
• Each shock is defined in the output, not just named.
• Stale, flat or missing inputs are flagged, and any leg left out is named with its likely effect.
• The "Not established" line is honest about what was not checked.