Bump and Reprice ATM vega ladder

The report answers one question. What does a shift in the at-the-money volatility of one expiry cost the book, or pay it? One bucket answers one expiry, so the ladder shows where the exposure sits along the curve and not only its total.

The answer feeds a hedging decision. A desk decides whether to buy or sell volatility at a named expiry, and whether the concentration the ladder shows is the concentration the desk intended to carry overnight.

The report is not a report at a stated bump. ORE has no such concept. It has a shift, and the shift is a setting of the configuration. The report, its analytics and its reader know nothing about 0.1. They know the size the configuration states and the bucket the engine keys. A desk that wants a tenth of a volatility point states that size in the document the definition binds, and the same report then answers that question.

The at-the-money volatility ladder runs on both cycles. The plain definition selects the LIVE cut and reads the market data of the instant it starts, so a desk watches the smile move between the closes. Its "(EOD)" twin selects the EOD cut and values the portfolio at the weekday before the run date, which is the at-the-money statement of record, taken at the close the market risk function signs off. A live ladder is indicative and a close ladder stands, so the two are separate definitions with separate run settings and neither run replaces the record of the other.

The plain definition selects the LIVE cut and its run settings row states market data type live; the twin selects EOD and states eod.

• Trades selected by scope. A definition states the scope it selects, and the ladder reads the trade set that scope names.
• Market data for the as-of date, from the end of day cut. The run settings row states market data type eod, so the valuation date is the weekday before the run date, and holiday calendars are not consulted.
• The sensitivity configuration the analytic binds, through sensitivityConfigFile. The document states the shift on the FX volatility block, with an expiry list and an empty ShiftStrikes.
• The pricing engine the definition binds. It prices the book before the shift and again after it.
• The base currency, from the run settings row. The figures are expressed in it.

The run produces the engine's own output archive. The archive holds this report's CSV artefacts, whose names the run states in its output parameters: sensitivity.csv for the value changes and scenario.csv for the scenarios. The run records where the archive landed against the run instance. It also records the cut the run minted, with the cut's label, kind and instant.

sensitivity.csv carries the value change of each shifted factor in its Delta column, and scenario.csv carries the scenario values that lie behind those figures. A reader sets a row of one file against a row of the other.

The rows a reader would query are a later phase. The result store is designed on Report post-processing and is not built, so today a reader opens the two files in the archive.

The set is the configuration's. The definitions of the risk measures are on Risk reporting and are not repeated here.

A run writes two files. sensitivity.csv carries the value change for each shifted factor. scenario.csv carries the value under the shift. The columns are the ones ORE output formats states.

A reader places a figure by the Factor_1 key and by no other column. The key holds the currency pair and the expiry, so one key is one bucket of the ladder. The shipped sample writes FX volatility keys in the form FxVolatility/<pair>/<strike>/<expiry>.

The run document states one sensitivity analytic. The analytic names the market configuration and the SensitivityAnalysis document, and it states the output files the engine writes. The fragment below is trimmed from external/ore/examples/MarketRisk/Input/ore_sensismile_atm.xml.

<Analytic type="sensitivity">
  <Parameter name="active">Y</Parameter>
  <Parameter name="marketConfigFile">simulation_atmOnly.xml</Parameter>
  <Parameter name="sensitivityConfigFile">sensitivity_atmOnly.xml</Parameter>
  <Parameter name="pricingEnginesFile">../../Input/pricingengine.xml</Parameter>
  <Parameter name="scenarioOutputFile">scenario.csv</Parameter>
  <Parameter name="sensitivityOutputFile">sensitivity_atmOnly.csv</Parameter>
  <Parameter name="outputSensitivityThreshold">0.000001</Parameter>
  <Parameter name="recalibrateModels">Y</Parameter>
</Analytic>

The SensitivityAnalysis document is a document of its own. ORE validates it against sensitivity.xsd, and it carries one block for each risk class: the curves, the spots, the volatilities, the credit families, the inflation families, the correlations and the rest. This report reads the FX volatility block. Every factor block states four things. ShiftType says how the shift is applied and is Relative, Absolute or EqualTo. ShiftSize says how large it is and is a real, with an optional key for an alternative size. ShiftScheme says where the shift is anchored and is Forward, Backward or Central. The bucket list says which points move, and it is ShiftTenors, ShiftExpiries, ShiftStrikes, ShiftLossLevels or ShiftTerms. ShiftType and ShiftScheme are enums in ore_types.xsd.

The fragment below is the worked case. It is trimmed from external/ore/examples/MarketRisk/Input/sensitivity.xml.

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

An empty ShiftStrikes is the at-the-money switch. The block shifts one point on each expiry in the list, and that point is the at-the-money volatility. A populated list shifts every strike it names, which is the surface ladder.

The engine's own names for the two files are sensitivity.csv, which carries the Delta and Gamma columns, and scenario.csv, which carries the scenario values that lie behind them. A run that states output names in its analytic gets the names it states. Delta is a value change and not a derivative. It is money per shift, and the shift size is already inside it. The Difference column of scenario.csv carries the same value, so a reader checks one file against the other.

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. A 0.1 vol point bump is ShiftSize 0.1 on a surface stored in vol points, or Absolute 0.001 on a surface stored in decimals. The report itself, its analytics and its reader are the same either way.

A definition of this report states the rows below. The store states no shift size today, so the shift rows carry no seeded value, and a reader takes the size from the document the definition binds. The mechanism is on ore parameter.

A reader opens the archive the run records and reads the two files in order. No step needs a tool beyond a CSV reader.

1. Open sensitivity.csv in the archive the run records.
2. Keep the rows whose Factor_1 key begins FxVolatility/.
3. Read the currency pair and the expiry out of the key. That pair and that expiry name the bucket.
4. Read ShiftSize_1 on the row. It states the size of the shift that produced the figure, and it is the only place the size appears.
5. Read Delta on the same row. It is the value change of that trade at that bucket, already scaled by the shift.
6. Add Delta across the trades that share the bucket. The sum is the book's figure for that expiry.
7. Repeat step 6 for each expiry in the block's list. The set of sums is the ladder.
8. Open scenario.csv and find the row of the same trade and the same factor. Check that Difference agrees with the Delta of the row. A disagreement says the reader has paired the wrong factor.
9. Read down the ladder and state which expiries carry the exposure, and which expiry the desk did not expect to carry any.

The ladder is a set of value changes at one shift size. It is not a set of derivatives, and a reader who compares two runs compares them only when the two configuration documents state the same size.

• 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.
• The store seeds no volatility market data. The dataset holds no FX_OPTION/RATE_LNVOL quote and no volatility surface configuration, so the surface point this ladder names has no quote to shift. That is a fact about the data and not about the report.
• No shift size is stated anywhere in the store.
• No stored shape holds a bucketed ladder, so the rows a reader of this report would query have no table to land in. The result store is not built.

No substitute is defined for this report, so a test run of it executes every phase. It gathers trades and market data and assembles its own bundle. The full-pipeline proof therefore exercises the report, and no smoke test does.

The mechanism the page describes is exercised by the shipped ORE sample. Its two forms are the files in SensiSmile, and the expected output of the at-the-money form is in external/ore/examples/MarketRisk/ExpectedOutput/SensiSmile/Atm/.

The cut resolution the report relies on is exercised by the task that lit the intraday reports, Light the intraday reports on the LIVE cut.

• Reports, the inventory this page is listed in.
• Bump and Reprice Risk-reversal vega ladder, the ladder built from two of these points.
• Bump and Reprice Butterfly vega ladder, the ladder built from three of these points.
• Bump and Reprice Surface vega ladder, the same shift on every strike.
• Bump and Reprice Three-pillar vega ladder, the three components moved together.
• FX Volatility Surface, the surface these points sit on.
• Risk reporting, the classification taxonomy and the measures catalogue.
• Report execution pipeline, the phases every run goes through.
• Report post-processing, the result store that is not built.
• Report definition and schedule, the definition that binds the configuration.
• The cut is the body a run prices from, what an end of day cut holds.
• sensitivity.xml, the shipped worked document.
• Rework the market data feeds into a market data service with adapters, the remaining work, the work that would seed volatility market data.

• Report families — the structure note that orders this cluster, and where to read this page in it.
• Open Source Risk Engine, the engine whose sensitivity analytic writes these files.