Bump and Reprice Butterfly vega ladder

The report answers one question at each expiry. Does the smile bend in the wings beyond its level, and how much of the book's value moves when it does? One bucket answers one expiry, so the ladder shows the curvature exposure along the curve.

The answer feeds a hedging decision. A desk that sells or buys wing risk decides whether the curvature it carries is the curvature it meant to carry, and whether to hedge it with a structure or to leave it open.

The figure is not a factor ORE knows. ORE shifts a surface point. Each point has a native value change, and the butterfly is a combination of three of them, taken over one run. The engine is never asked for a butterfly, and the report asks it for nothing beyond a full-surface run.

The report is also not a report at a stated bump. The bump is a setting of the configuration and not the identity of the report. The report, its analytics and its reader know nothing about 0.1. 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 butterfly 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 skew 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 statement of record. 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 derivation adds nothing to the run. One full-surface run states every point the ladder needs, so the three points of an expiry are always three rows of one archive and never more than one run.

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 a strike list on the volatility block, so the run shifts the call point, the put point and the at-the-money point of each expiry.
• 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, and 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.

The files carry the surface points and not the derived figure. sensitivity.csv holds the Delta of each shifted point, and scenario.csv holds the scenario values that lie behind those figures. The ladder is three rows read together at one expiry.

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 definitions of the shared 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.

The bucket is the pair and the expiry, and the reader takes both out of the Factor_1 key. The key also holds the strike, and the strike is what separates the three rows of one expiry. The shipped sample writes FX volatility keys in the form FxVolatility/<pair>/<strike>/<expiry>.

The run is a full-surface run. The run document states one sensitivity analytic whose document carries a strike list. The fragment below is trimmed from external/ore/examples/MarketRisk/Input/ore_sensismile_surface.xml.

<Analytic type="sensitivity">
  <Parameter name="active">Y</Parameter>
  <Parameter name="marketConfigFile">simulation_fullSurface.xml</Parameter>
  <Parameter name="sensitivityConfigFile">sensitivity_fullSurface.xml</Parameter>
  <Parameter name="pricingEnginesFile">../../Input/pricingengine.xml</Parameter>
  <Parameter name="scenarioOutputFile">scenario_fullSurface.csv</Parameter>
  <Parameter name="sensitivityOutputFile">sensitivity_fullSurface.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. 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 volatility block of the shipped worked document, trimmed from external/ore/examples/MarketRisk/Input/sensitivity.xml. The empty ShiftStrikes is the at-the-money form. A strike list in its place is the form this ladder reads.

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

ShiftStrikes is the switch that decides how many points one expiry carries. An empty element shifts the at-the-money point only, and a call point and a put point never appear. A populated list shifts each strike it names, so one expiry yields a row for each point and the three rows this report reads.

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 derivation is a change of basis, and it is written here in plain ASCII.

On one expiry the surface states three points:
  ATM   the at-the-money point
  CALL  the higher strike point
  PUT   the lower strike point

The smile identity, on the FX volatility surface:
  sigma_call = sigma_ATM + sigma_BF + 0.5 * sigma_RR
  sigma_put  = sigma_ATM + sigma_BF - 0.5 * sigma_RR

Read backwards, at the same expiry:
  sigma_RR = sigma_call - sigma_put
  sigma_BF = 0.5 * (sigma_call + sigma_put) - sigma_ATM

The change of basis this report applies, where D is the Delta column at a point:
  D_BF = 0.5 * (D_call + D_put) - D_ATM

Two cautions belong to that formula. First, the smile butterfly is not the price of a strangle structure, and a reader does not treat the figure as one. Second, the butterfly style the pair is stored with decides the conversion between the points and the smile, so the identity holds for the stored style and for no 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, and the derived figure scales with the size the document states.

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, and no step asks the engine for a butterfly.

1. Open sensitivity.csv in the archive the run records.
2. Keep the rows whose Factor_1 key begins FxVolatility/.
3. Take the currency pair, the strike and the expiry out of the key.
4. Group the rows of one pair and one expiry. The strikes in the keys now separate the call point, the put point and the at-the-money point.
5. Read Delta on the call row, on the put row and on the at-the-money row.
6. Add the call figure to the put figure, halve the sum, and subtract the at-the-money figure. The result is the ladder's value for that expiry, at the shift size the row states in ShiftSize_1.
7. Repeat step 6 for each expiry. The set of results is the ladder.
8. Add the results across the trades that share a bucket, so the ladder is the book's figure and not one trade's.
9. Check the three rows against scenario.csv. The Difference column of each row must agree with its Delta.
10. Read down the ladder and state where the wings carry value, and whether one expiry bends further than its neighbours.

The ladder is a set of differences at one shift size. A reader who compares two runs compares them only when the two configuration documents state the same size, the same strike list and the same butterfly style.

• ORE has no butterfly risk factor. The ladder is derived from the surface points of one full-surface run, and it is never asked of the engine.
• The smile butterfly is not a strangle price, and the report states no strangle figure. A reader who needs one needs a different computation.
• 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 engine refuses at the point it needs a volatility, and the run records that refusal against the run instance. The refusal is a fact about the environment and not about the report.
• No shift size is stated anywhere in the store.
• No stored shape holds a bucketed ladder, and no stored shape holds the derived figure. 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 full-surface form is in external/ore/examples/MarketRisk/ExpectedOutput/SensiSmile/Surface/. A reader checks a point figure against that output and derives the ladder from it.

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 ATM vega ladder, the level of the smile, one point on each expiry.
• Bump and Reprice Risk-reversal vega ladder, the slope of the smile, from two points of the same run.
• Bump and Reprice Surface vega ladder, the run this ladder reads, one row for each point.
• Bump and Reprice Three-pillar vega ladder, the three components moved together.
• FX Volatility Surface, where the smile identity and the butterfly styles are set out.
• 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.