Greek ladder reports

The sensitivity configuration is one XML document whose root is SensitivityAnalysis, validated against external/ore/xsd/sensitivity.xsd. It carries one block for each group of risk factors — discount curves, index curves, yield curves, FX spots, FX volatilities, swaption volatilities, cap and floor volatilities, CDS volatilities, default and credit curves, equity spots and volatilities, both inflation curve families, both inflation cap/floor families, dividend yields, base correlations, security spreads, commodity curves and volatilities, intraday power curves, correlations and bond future volatilities — plus four switches that are not factors: ComputeGamma, CrossGammaFilter, ThetaPeriod and the par conversion group.

Every factor block states the same four things:

ShiftType and ShiftScheme are enums in external/ore/xsd/ore_types.xsd. The shipped external/ore/examples/MarketRisk/Input/sensitivity.xml shows the conventional numbers: curves at Absolute 0.0001 (one basis point) with a Central 0.001 override keyed IR_FD; FX spots at Relative 0.01; FX volatilities at Relative 0.01 with an expiry list and an empty ShiftStrikes; and ThetaPeriod 1D.

No shipped example states a ShiftSize of 0.1, and the schema has no element for one. A ".1 report" is a name for a shift size, and the size is meaningless without the type and the unit it is quoted in.

This is the load-bearing fact for the whole family, and it is worth stating precisely because the prose catalogue on Risk Reporting writes the Greek as a quotient.

ORE writes sensitivity.csv with Delta and Gamma columns (ORE output formats, family sensitivity_report). Both are money. Neither is divided by the shift size. Measured on the shipped MarketRisk sample at commit deb15641d0:

import csv
sens = {}
with open('sensitivity.csv') as f:
    r = csv.reader(f); next(r)
    for row in r:
        if len(row) >= 10:
            sens[(row[0], row[2])] = (float(row[3]), float(row[8]))
with open('scenario.csv') as f:
    r = csv.reader(f); next(r)
    for row in r:
        if len(row) >= 8 and row[2] == 'Up':
            shift, delta = sens[(row[0], row[1])]
            print(row[1], shift, delta, float(row[7]))

Run it from external/ore/examples/MarketRisk/ExpectedOutput/Sensi. It prints the factor, its shift size, Delta from the sensitivity report and Difference from the scenario report.

Every pair matches to the printed precision. So Delta is \(PV(\text{shifted}) - PV(\text{base})\), and the shift size is already inside it. Two consequences follow, and they decide the whole design:

1. A .1 ladder is not a comparison of a Vega against a spot move. It is the Delta column of a run configured with ShiftSize = 0.1. The number the trader reads is money per 0.1, and it is already in that unit.
2. Two reports over the same book that differ only in shift size differ only in their sensitivity configuration. Nothing in the report definition, the analytics or the reader has to know what ".1" means.

ORE distinguishes "shift the smile" from "shift the ATM level" with the same element. The two shipped configs are otherwise identical: external/ore/examples/MarketRisk/Input/SensiSmile/sensitivity_atmOnly.xml carries <ShiftStrikes/> for the swaption block, while sensitivity_fullSurface.xml carries a strike list. Their run documents, ore_sensismile_atm.xml and ore_sensismile_surface.xml, differ only in which marketConfigFile and sensitivityConfigFile they name.

That is the direct ORE analogue of the .1 ATM and .1 surface reports, and it means the ATM ladder is native while the full-surface ladder is native too — provided the surface's strikes are nameable in the configuration.

The shift size is a bare real. Its unit comes from the factor:

The shipped example quotes FX volatilities at Relative 0.01, which is one per cent of the volatility, not one volatility point. So "0.1 vol" could mean a Relative shift of 0.1 (a tenth of the level — rarely intended) or an Absolute shift of 0.1 on a surface stored in vol points. This ambiguity is the first open question for the product owner, and it is the only one that blocks every other decision.

A ladder is a Cartesian product: a risk class (which market data it bumps and so which buckets it has) times an order (what it measures about that bump).

The risk class is fixed by which block of sensitivity.xsd the factor belongs to. The order is fixed by four switches:

Each row is a ladder the engine can produce. The bucket column is the set of columns a reader needs to place a figure on the ladder.

The factor-key spellings in the table are the ones a reader parses today: the sample at MarketRisk/ExpectedOutput/Sensi/sensitivity.csv writes DiscountCurve/EUR/5/1Y, OptionletVolatility/EUR/8/2Y/0.04, BaseCorrelation/CDXIG/2/0.1/1D and Theta//0/1D, and the same spellings appear as the risk-factor vocabulary of the correlation and covariance files (ORE output formats).

The prose catalogue defines .1 ATM, .1 RR, .1 STR, .1 Triple and .1 Quad as "the PV change from a 0.1 bump" to one or more smile components. On an FX surface quoted as ATM, risk reversal and butterfly, that family is a linear change of basis over the surface points, and FX Volatility Surface already states the identity:

sigma_call = sigma_ATM + sigma_BF + 0.5 * sigma_RR
sigma_put  = sigma_ATM + sigma_BF - 0.5 * sigma_RR

Read backwards, the three components are:

sigma_ATM = sigma_ATM
sigma_RR  = sigma_call - sigma_put
sigma_BF  = 0.5 * (sigma_call + sigma_put) - sigma_ATM

So, writing \(D_x\) for the Delta column at surface point \(x\):

A caution on the STR row. The identity above is the smile butterfly. A broker quoting a strangle is quoting the price of the strangle structure, and turning that into a smile butterfly takes the calculation FX Volatility Surface describes, because the strikes implied by the two quotes are not the same strikes. The strangle ladder must therefore read the butterfly style the pair is stored with, and it cannot be read as a plain average.

Two things follow. First, the Triple is not a special configuration — it is the full-surface shift, and it already exists as a shipped example. Second, RR and STR are bookkeeping over native deltas, which is exactly what ORE's own par conversion does for rates: it converts zero-rate deltas into par-rate deltas through a change of basis rather than by re-running the engine (ORE Methods, "Sensitivity/Par-Sensitivity Analysis"). The store should treat the RR and STR ladders the same way.

Whether ShiftStrikes on an FX volatility block names a delta or an absolute strike decides whether the call and put points are addressable at all. The schema does not say, the examples leave the element empty for FX, and the store records the surface's deltas rather than its strikes (ores_refdata_fx_volatility_configs_tbl). This is the second open question, and it decides whether RR and STR can be computed from one full-surface run or need a configuration per delta.

A ladder can only be as wide as the quotes behind it. The bucket list in the configuration must be a subset of the pillars the run's curves and surfaces actually carry, because the engine shifts the factors it is told to shift and silently writes nothing for a factor it cannot find.

The FX vol key spellings are the sample's own: the shipped external/ore/examples/Input/market_20160205.txt writes FX_OPTION/RATE_LNVOL/EUR/USD/1Y/ATM alongside …/1Y/25RR and …/1Y/25BF. That the market data carries the three components as separate keys while the sensitivity configuration addresses surface points is the gap this design has to bridge.

The same document serves every ladder. A report's ladder family is therefore a property of which document it binds, and the differences a trader cares about — 0.1 against 1 basis point, ATM only against the whole smile, one currency pair against all — are differences between documents, not between reports.

The example configs show what a full document costs to write: the shipped sensitivity.xml is 517 lines for three currencies, one swaption set, one equity set and six credit names, with a ParConversion block per curve. A configuration per ladder per shift family would multiply that. The design should therefore hold one document per risk class and let the shift size vary through the keyed ShiftSize override the schema already provides, rather than one document per report.

Beyond the configuration, a run needs:

• the sensitivity analytic switched on, which the seeds already do;
• sensitivityConfigFile naming the document, which no seed does;
• marketConfigFile naming the risk-factor description, which the shipped ore_sensi.xml sets to simulation.xml and ore_sensismile_atm.xml sets to simulation_atmOnly.xml;
• recalibrateModels, parSensitivity and outputSensitivityThreshold, which the seeds already set to Y, Y and 0.000001;
• for par ladders, the conventions the ParConversion instruments name, and the ParConversionExcludes list for curves that must stay in the zero domain.

Cross-gamma needs ComputeGamma and a CrossGammaFilter listing the pairs as substrings of factor keys. The shipped filter names three pairs:

<CrossGammaFilter>
  <Pair>DiscountCurve/EUR,DiscountCurve/EUR</Pair>
  <Pair>IndexCurve/EUR,IndexCurve/EUR</Pair>
  <Pair>DiscountCurve/EUR,IndexCurve/EUR</Pair>
</CrossGammaFilter>

The engine writes cross gammas into sensitivity.csv as rows with both Factor_1 and Factor_2 populated, not into a file of their own: at v1.8.17.0 no writer reads sensitivity.crossGammaOutputFile, so crossgamma.csv never appears (ORE output formats). Measured on the sample at commit deb15641d0, sensitivity.csv holds 968 data rows of which 484 carry a second factor, and scenario.csv holds 17,225 rows, the shifted values behind both. The ladder is therefore buildable; it just does not arrive in the file its name suggests.

The product owner overruled this page's decision to hold the family back on 2026-11-04: the catalogue states the ladders and lets them fail at the engine like every other report whose inputs have not arrived. A definition that produces no figure costs nothing to hold, and a party that sees the report in its list learns what the platform runs rather than what its data reaches.

Rows 1 to 10 are seeded, and rows 11 to 14 are stated and not seeded. Each row is a definition named for the ladder page this folder already carries, so a reader of one reaches the other:

A row the design marks eod and intraday is two definitions, because a definition states one cut selection. The plain name selects the live cut and its "(EOD)" twin selects the close, so the ten rows are fifteen definitions at each of the four Acme parties and at Northwind.

Every seeded row binds the party's sensitivity run settings, which name sensitivity.xml and simulation.xml, and the Risk Sensitivities engines. The bump is not part of a definition, so the ten rows share one document and differ in their name and their cut. That is D2 holding: one document per risk class, and the report's identity in its name.

What still stops a figure is stated under What the store lacks, and it is the same list for all ten: no table holds the SensitivityAnalysis document and no mapper reads one, no table states a shift size, and the dataset holds no volatility quote and no spot for the volatility and currency pair ladders to shift. Rows 11 to 14 wait on their market data as well, which is why they are not seeded at all.

Three reports from the existing EOD set in Risk Reporting are not ladders and this design does not claim them: the "Rho/Vol Matrix", the "Spot/Vol Matrix" and the "Spot/Rho Matrix" are two-factor scenario grids, not bucketed deltas. They are built with the stress analytic and a stresstest.xml, and the sensitivity analytic with two shift sizes produces the same numbers as scenario rows (scenario.csv writes a Cross direction for them). They are the natural next step after row 4 and they are out of scope here.

The store gains no point_one report type, no point_one analytic and no per-report shift column. A .1 report differs from its 1-basis-point sibling only in the sensitivity configuration it binds. This keeps the report definition what Report definition and schedule says it is — the description of a report, with the engine parameters in a shared configuration — and it keeps the family open: a 0.5 report and a 2 basis point report cost nothing.

The schema gives ShiftSize, ShiftType and ShiftScheme entries an optional key attribute, so one document can carry a named size family alongside the default and a run selects the family by key, without duplication. The store should seed one document per risk class and select the shift family through the key, rather than seed a document per report.

The engine has no risk-reversal factor. The store therefore computes the RR and STR ladders from the surface-point deltas of one full-surface run, using the identity on FX Volatility Surface. This mirrors what ParConversion already does for rates and keeps the derived figures reproducible from one stored run.

The catalogue's ".1 Triple" and the engine's full-surface shift are the same computation. The store should name it once, prefer the engine's words, and record the catalogue's name as an alias rather than as a second report.

Until crossgamma.csv has a writer, the cross ladder reads the Factor_1 and Factor_2 rows of sensitivity.csv and keeps scenario.csv as the evidence behind them. No new output file is expected.

ThetaPeriod produces a risk factor key of its own (Theta//0/1D) and a bucket list of its own (the period). It is a report in its own right because the number means something different: the value change from moving the clock, not from moving a market.

A .1 in vol points (Absolute 0.001 on a decimal surface, or Absolute 0.1 on a vol-point surface) and a .1 as a per-cent relative shift (Relative 0.1) are two different reports and differ by orders of magnitude on a 10-vol book. The catalogue says "0.1 bump", "0.1-unit shift" and "0.1% change in interest rates" in three neighbouring paragraphs, so the unit is stated inconsistently in the source. Which one is the desk's .1, and is it the same number for rates and for volatility?

The catalogue names Delta, Gamma, Vega, Rega, Sega, Theta and Rho. The engine shifts 26 risk classes and reports delta, gamma, cross-gamma and theta for each. Rega and Sega are the risk reversal and strangle, which the engine does not have (D3). Does the .1 family mean the five vol ladders only, or the whole family in the reports table? And for each ladder, which bucket list is the desk's — the shipped sixteen-tenor curve list, the shipped four-expiry vol list, or something shorter?

Rows 7 to 10 of the family table need FX vol surfaces quoted as ATM, RR and BF; rows 11 to 14 need swaption, cap/floor, credit and equity data. Which of these is in scope for the book the .1 reports will run on, and is the vol surface a requirement for the first .1 report or a later one?

Two versions publish today, 1.8.16.0-4-g3b62ba248 and 1.8.17.0 (external/ore/packages/manifest.json). The cross-gamma finding, the crossgamma.csv gap and the analytic parameter list are all measured at 1.8.17.0. Is 1.8.17.0 the version the .1 reports must run on, and may the store stop publishing the older package?

The catalogue gives the .1 family intraday · eod for cycle and on-demand · scheduled for frequency, and the EOD set then lists ".1 Rho" and "Trade and Book Level .1 Triple Vol" as scheduled EOD members. A dual-cycle report needs two definitions with two market-data types, which Light the intraday reports on the LIVE cut is already doing for the headline reports. Which of the .1 family runs intraday, and which runs only on the authorised cut?