Bump and Reprice Three-pillar vega ladder

It answers a question about a whole surface at once. If every point of this surface moves together, and the shape of the surface stays as it is, how much money does the scope change by? The answer feeds two decisions. A desk decides how much of its volatility risk is a level risk and how much is a shape risk. Market risk decides whether the book's volatility exposure sits inside its limit before anyone argues about skew.

The three components the catalogue names move together in this reading. The at-the-money point, the risk reversal and the butterfly are three views of one surface. Move all three and the surface has moved while its shape is held. That is the ladder this page defines.

This page names the same computation twice. The store seeds one report for the full-surface shift and calls it the surface vega ladder, so the three-pillar is that report read by its other name; a second definition under this name would be a second run of one report. The report runs on both cycles, and its page states them.

The live definition selects the LIVE cut and its run settings row states market data type live; the close twin selects EOD and states eod. Nothing else changes between them, because the bump is a setting of the configuration and not the identity of the report.

• Trades selected by the definition's scope. The scope is a row of the definition and the taxonomy fixes the shapes it accepts, on Risk reporting.
• Market data at the authorised end of day cut. The run records the cut it read against the run instance, with its label, kind and instant.
• The risk report configuration the definition binds. It switches on the sensitivity analytic, states the base currency and names sensitivity.xml as the sensitivityConfigFile. The analytic states recalibrateModels Y, outputSensitivityThreshold 0.000001, parSensitivity Y and marketConfigFile simulation.xml.
• A sensitivity document that shifts every strike of every expiry of the surface. The shipped document states an empty ShiftStrikes, which shifts the at-the-money point only. A full-surface run states a strike list, and the two run documents of the shipped smile examples differ only in the marketConfigFile and the sensitivityConfigFile they name.

The run produces the engine's own output archive and records where that archive landed against the run instance. The archive holds sensitivity.csv, which carries one row for each trade and each shifted surface point, and scenario.csv, which carries the scenario value behind each row.

The rows a reader would query in a table are a later phase. The result store is designed on Report post-processing and is not built yet.

The catalogue calls this ladder the .1 Triple. Its own wording is a 0.1 bump applied to the at-the-money component, the risk reversal and the strangle together, and it calls that the equivalent of shifting the entire surface by 0.1 while the shape is preserved.

The engine's words are preferred on this page. The engine has one block for a volatility surface, and it shifts surface points. It has no risk-reversal factor and no strangle factor, so the three components are a way of reading one surface shift and not three separate bumps. A reader who wants the three components separately reads them from a full-surface run by change of basis, as the risk-reversal and butterfly ladder pages state.

Delta is a value change and not a derivative. The shift size is already inside it, so a figure is money per bump and not a ratio.

The reader opens the engine's CSV files, because the result store is not built. The tables below state the columns of the two files this report writes. The definitions are on ORE output formats.

A reader places a figure by the bucket columns. Factor_1 carries the pair, the strike and the expiry, as in FxVolatility/<pair>/<strike>/<expiry>, and ShiftSize_1 states the shift that produced the figure. A swaption volatility adds the term, as in SwaptionVolatility/<key>/<strike>/<expiry>/<term>. This ladder is built from the same full-surface run as the Surface vega ladder, so its rows carry the pair, the expiry and the strike of every shifted point.

The mechanism has four parts. First, the generated run document carries an analytic of type sensitivity, and that analytic names sensitivity.xml through sensitivityConfigFile. Second, the root of that document is SensitivityAnalysis, and ORE validates it against external/ore/xsd/sensitivity.xsd. Third, the document carries one block for each group of risk factors, and the block this ladder reads is FxVolatilities. Fourth, every factor block states ShiftType, ShiftSize, ShiftScheme and the bucket list, which for a surface is ShiftExpiries and ShiftStrikes.

ShiftType is Relative, Absolute or EqualTo. ShiftScheme is Forward, Backward or Central. Both are enumerations in external/ore/xsd/ore_types.xsd. The ATM-only switch is ShiftStrikes. An empty ShiftStrikes shifts the at-the-money point of each expiry, and a populated ShiftStrikes shifts every listed strike.

The fragment below is trimmed from external/ore/examples/MarketRisk/Input/sensitivity.xml. It shows the FX volatility block of the shipped document, with its expiry list and its empty ShiftStrikes.

<FxVolatilities>
  <FxVolatility ccypair="USDEUR">
    <ShiftType>Relative</ShiftType>
    <ShiftSize>0.01</ShiftSize>
    <ShiftScheme>Forward</ShiftScheme>
    <ShiftExpiries>1Y,2Y,3Y,5Y</ShiftExpiries>
    <ShiftStrikes/>
  </FxVolatility>
  <FxVolatility ccypair="GBPEUR">
    <ShiftType>Relative</ShiftType>
    <ShiftSize>0.01</ShiftSize>
    <ShiftScheme>Forward</ShiftScheme>
    <ShiftExpiries>1Y,2Y,3Y,5Y</ShiftExpiries>
    <ShiftStrikes/>
  </FxVolatility>
</FxVolatilities>

The full-surface variant of the same document carries a strike list in ShiftStrikes, and that is the document this ladder reads. The engine writes sensitivity.csv with the columns the reader saw above, and it writes scenario.csv with the scenario value and the difference behind each figure.

The bump is a setting of the configuration and not the identity of the report. Two reports over one book that differ only in shift size differ only in the document they bind. The catalogue's 0.1 is one setting, and a ladder at another size is the same report with another document.

A definition of this report states the rows below. The shift itself is not a parameter of the store, and no seed states a shift size anywhere.

1. Open the archive the run recorded and take sensitivity.csv.
2. Keep the rows whose Factor_1 starts FxVolatility. Those are the shifted surface points.
3. Read the bucket. The segments of Factor_1 name the pair, the strike and the expiry of the point.
4. Check that the rows of one expiry carry several strikes. A run with an empty ShiftStrikes states the at-the-money point alone, and that is a different reading from this ladder.
5. Read ShiftSize_1. It states the size of the move the figure belongs to.
6. Read the Delta column as money per shift. Do not divide it by the shift.
7. Sum the rows of one expiry. All the points of one expiry moved together, so their sum is the value change at that expiry for a surface that held its shape.
8. Open scenario.csv and read Difference for the same TradeId and Factor. It agrees with the Delta figure to the printed precision.
9. Read the same expiry on the previous close. Two closes state whether the level risk grew or shrank.

• No mapper reads or writes a SensitivityAnalysis document. The document is a name in a lookup and a row in the file library, and it is not a modelled entity.
• The run package carries only the four Setup documents, which are conventions, curve configuration, today's market and pricing engines. An analytic document that no owner exports never reaches the engine.
• No volatility market data is seeded. The ACME dataset holds 420 quotes and all of them are IR_SWAP/RATE/.... There is no FX_OPTION/RATE_LNVOL quote and no volatility surface configuration. The engine therefore refuses at the point it needs a volatility, and the run records that refusal against the run instance. This is a fact about the environment and not about the report.
• No shift size is stated anywhere in the store. The catalogue states 0.1 and the store cannot state it as a row.
• No stored shape holds a bucketed ladder. The bucket is a segment of a factor key in a CSV file.
• The result store is not built, so no table carries the rows a reader queries.

The sensitivity configuration type is seeded with root SensitivityAnalysis, the parameter sensitivityConfigFile and the owner ores.analytics. The document and its two surface variants sit in the ORE file library with their descriptions, the schema is vendored as sensitivity_schema, and the worked configurations are vendored.

No substitute is defined for this report, so a test run executes every phase and assembles its own bundle. The report is exercised by the full-pipeline proof and not by a smoke test. The machinery that proves a bundle without gathering one is Sample bundle smoke test.

• Reports, where this page is listed.
• Risk reporting, which holds the classification taxonomy, the .1 Triple entry and the measures catalogue.
• ORE output formats, which states the columns of sensitivity.csv and scenario.csv.
• Bump and Reprice ATM vega ladder, which places one shift on the at-the-money point.
• Bump and Reprice Risk-reversal vega ladder, which reads the skew by change of basis.
• Bump and Reprice Butterfly vega ladder, which reads the wing by change of basis.
• Bump and Reprice Surface vega ladder, which places the same shift on every strike.
• FX Volatility Surface, which states the smile identity the change of basis uses.
• Report execution pipeline, which states the phases every run goes through.

• Report families — the structure note that orders this cluster, and where to read this page in it.
• Open Source Risk Engine: the engine whose FxVolatilities block shifts a surface.