Bump and Reprice Triple Vol Spot Ladder (EOD)

It answers where a book carries volatility risk at the close, and how that risk stands against spot, in one read. The decision it feeds is the sign off on vol risk. The close states the position of record, and the intraday definition states the view taken between closes.

The intraday definition and this one share the analytic, the measures and the files. They differ in the cut they select and in the run settings row they bind, so the same report name on the two cycles is two definitions, two run settings and two binding sets.

Vega is the change in value for a shift of a volatility point. Rega is the same change read along the risk reversal, so it states the slope of the smile. Sega is the same change read along the butterfly, so it states the wings.

Cycle eod. The definition is seeded with the expression 0 18 * * 1-5, which fires it at 18:00 London time on weekdays. It is not a member of an ordered batch.

The concurrency policy is skip. A firing that arrives while a run of the same definition is in flight is dropped.

The definition states cut_kind_code EOD, which names the authorised end of day cut. The run settings row states market_data_type eod, so the generator takes the valuation date as the weekday before the run date. Holiday calendars are not consulted.

• Trades selected by scope. The scope shape is book. Only the London entity holds the triple vol reports, because the option books are there.
• Market data for the as-of date, taken from the day's authorised end of day cut.
• The risk report configuration the definition binds, Sensitivities (EOD) - Global Portfolio. The row states the market data type eod and the base currency, which is the entity's.
• The engine settings row the definition binds. The pricing engine for an end of day definition is EOD Official.

A definition binds six configuration documents, one per configuration type. The six codes are conventions, curve_configuration, todays_market, pricing_engines, risk_report_config and engine_settings. A definition that omits one of the first five cannot run, because ORE reads all of them before it prices.

The run produces the engine's own output archive. The archive holds the CSV artefacts of the one bound analytic: sensitivity.csv and scenario.csv. The run also records the cut it minted, with the cut's identity, its label, its kind and its instant.

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

The set is the catalogue's for this report, read per tenor and per spot shift level. The standard shift series is 30, 20, 10, 5, 2, 1, 0.5 and 0 percent. The definitions of the measures are on Risk reporting and are not repeated here.

The analytic writes two files, the same two the intraday definition writes. The tables below state the columns of those files, as ORE output formats lists them. A (Base) column is in the run's base currency. A (Trade) column is in the trade's currency. A shift size is in the factor's unit.

sensitivity.csv holds the sensitivities of each trade: Delta and Gamma for each factor, and cross gammas for factor pairs. The file has two header variants. The volatility Greek a reader takes from it is the Delta column on a volatility factor row.

scenario.csv holds the value of each trade under each shifted factor.

The factor keys the vol rows carry have the shapes FxVolatility/<pair>/<strike>/<expiry> and OptionletVolatility/<ccy>/<n>/<expiry>/<strike>. A reader sorts on the pair, the expiry and the strike of those keys to place a row at a tenor.

The configuration binds one analytic. The fragment is trimmed from external/ore/examples/MarketRisk/Input/ore_sensi.xml.

The base currency is the entity's, so the fragment shows GBP for the UK entity. The file states EUR for its own sample.

<Analytic type="sensitivity">
  <Parameter name="active">Y</Parameter>
  <Parameter name="marketConfigFile">simulation.xml</Parameter>
  <Parameter name="sensitivityConfigFile">sensitivity.xml</Parameter>
  <Parameter name="scenarioOutputFile">scenario.csv</Parameter>
  <Parameter name="sensitivityOutputFile">sensitivity.csv</Parameter>
  <Parameter name="outputSensitivityThreshold">0.000001</Parameter>
  <Parameter name="recalibrateModels">Y</Parameter>
  <Parameter name="parSensitivity">Y</Parameter>
</Analytic>

The sensitivity analytic reads its shift settings from the document that sensitivityConfigFile names. That document states, for each group of risk factors, a ShiftType, a ShiftSize, a ShiftScheme and the bucket list. The shipped external/ore/examples/MarketRisk/Input/sensitivity.xml states curves at Absolute 0.0001 and FX volatilities at Relative 0.01 with an expiry list and an empty ShiftStrikes. An empty ShiftStrikes is the at-the-money-only switch.

That document is not part of the run package the service builds, which carries only the four Setup documents.

A definition of this report states the rows below. The values are the seeded ones; the domains are the ones the engine and the classification taxonomy fix. The mechanism is on ore parameter.

A person reads this report at the screen in the order below. No run has produced rows yet, so the steps name the files and the comparisons and quote no figure.

1. Open the archive the run recorded and take sensitivity.csv. Read the Factor_1 column and keep the rows whose key begins FxVolatility/ or OptionletVolatility/. Those rows are the volatility points of the surface.
2. On those rows, read Delta. It is money per shift on the volatility point, and ShiftSize_1 states the shift it was measured with. This column is the native vega.
3. Sort the kept rows by the pair, the expiry and the strike inside the key. That order is the surface, expiry by expiry and strike by strike, and it is what a desk reads a vol ladder against.
4. Group the strikes of one expiry into the at-the-money point, the call wing and the put wing. The three groups state where the value sits across the smile.
5. Take the risk reversal of that expiry as the call wing figure less the put wing figure, and the butterfly as half the sum of the two wings less the at-the-money figure. The change of basis is stated on Risk-reversal vega ladder and Butterfly vega ladder.
6. Open scenario.csv and read Base NPV and Difference on the rows of the same factors. The difference states the value change for the shift.
7. Compare the Difference column with the Delta column of step 2 for one factor. The two agree to the printed precision, because both state the value change for one shift.
8. Compare this close with the last close of the intraday definition, tenor by tenor. The two are different cuts, so a movement between them is a movement of the book and of the market data, and not one figure computed twice.
9. Look for a row whose key states a spot shift level, such as 30, 20 or 10 percent. No such row exists, because the sensitivity analytic shifts factors and does not step spot.

• ORE has no Rega and no Sega risk factor. A risk reversal and a strangle are not ORE factors. ORE shifts a surface point.
• The vega of the surface points is native. The skew and the wing components must be derived by the change of basis stated on Risk-reversal vega ladder and Butterfly vega ladder.
• The seeded definition therefore produces surface-point sensitivities and not a Rega or Sega column.
• The spot shift levels are not part of the sensitivity analytic either. The grid the catalogue names is a scenario shape and no seeded analytic writes it.
• The dataset holds no volatility market data. Its 420 seeded quotes are all IR_SWAP/RATE/..., with no FX_OPTION/RATE_LNVOL quote and no volatility surface configuration. so a volatility factor has nothing to shift, and no volatility sensitivity can be computed until the store holds that data.
• The result store is not built, so a reader opens the CSV files in the archive.
• No mapper reads or writes a SensitivityAnalysis document. The document is a name in a lookup and a row in the file library, not a modelled entity.
• No shift size is stated anywhere in the store.

The sensitivity analytic type, the sensitivity configuration type and the file library entries are in the store, and the schema is vendored as sensitivity_schema. The end of day cut this report reads is the kind the cuts structure describes, and its name is recorded on the run.

The shift document the analytic names is a name in a lookup and not a modelled entity, and the run package carries only the four Setup documents. An analytic document that no owner exports never reaches the engine. The pricing phase also stops where the engine needs a volatility. A test run therefore proves the gather, the cut and the generated run document, and it proves no priced row.

• Reports, the inventory this page is listed in.
• Bump and Reprice Triple Vol Spot Ladder, the same analytic set on the live cut.
• Bump and Reprice Spot Greeks (EOD), the Delta view of spot risk on the same cut.
• Risk reporting, the classification taxonomy and the measures catalogue.
• FX Volatility Surface, the smile identity a change of basis uses.
• The cut is the body a run prices from, what a cut holds and what it does not.
• Report definition and schedule, how the definition and its schedule are seated.
• Report execution pipeline, the phases every run goes through.
• Report compute handoff, how the run reaches the grid.
• Report post-processing, the store that would hold the rows.
• Risk-reversal vega ladder
• Butterfly vega ladder
• Cuts

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