Bump and Reprice Vanna ladder

It answers what the cross term between a spot and a volatility is. A vega figure states how the value moves with the surface. A delta figure states how it moves with spot. The cross term states how the vega figure itself moves when spot moves, which is the risk a desk keeps when it hedges each of the two on its own. The decision it feeds is whether a delta hedge holds after spot moves, and how often it must be rebalanced. A book with no cross term keeps its vega through a spot move. A book with a large cross term does not.

The paired rows are vanna. One factor of the pair is a spot and the other is a volatility, and the row carries both Factor_1 and Factor_2. A row that names one factor states a first order figure and belongs to the delta ladder or to the vega ladder. A row that names two states the cross term, and this page reads it.

The trading desk reads the ladder to decide where a delta hedge must be rebalanced as spot moves. The market risk function reads it to see where a volatility position arrives without a trade.

The cycle is end of day. A ladder is read as the risk statement of record and compared across days. A live ladder would be priced against a body that is not reproducible, so the same row on two runs would not be the same figure.

The family seeds no intraday variant of any ladder. A live ladder would need a definition whose cut selection is LIVE, a run settings row whose market data type is live, and the same sensitivity configuration. The store seeds none of the three for this ladder.

• Trades selected by scope. The scope is the book or the portfolio that the definition states, and the run prices the trades the gather step selects.
• Market data for the valuation date. The risk_report_config row states the market data type. This ladder is end of day, so the type is eod and the valuation date is the weekday before the run date. Holiday calendars are not consulted.
• The six configuration documents the definition binds, one for each configuration type. The types 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.
• A spot and a volatility surface to bump. The dataset holds no FX volatility quote, so this input is the one the environment does not supply.
• The sensitivity configuration document, sensitivity.xml, which states the shift and the pairs.

The run produces the engine's own output archive. The archive holds sensitivity.csv with the paired rows and the Delta and Gamma columns, and scenario.csv with the scenario value behind each of them. The run records where the archive landed against the run instance.

The tables that would carry the rows a reader queries are designed on Report post-processing and are not built. So a reader opens the CSV files in the archive, and the columns in the next section are the columns of those files.

The values below are the ones the files carry. The definitions of the measures the catalogue names are on Risk reporting and are not repeated here.

A reader places a vanna figure by the two factors the row names and by the two shift sizes. The bucket columns are the ones that break each factor key into the parts a desk thinks in.

The spot factor key is written FXSpot/<pair>/<index>, and the output formats page shows one as FXSpot/USDEUR/0. The volatility factor key is written FxVolatility/<pair>/<strike>/<expiry>. A vanna row names one of each, so the currency pair is in both keys while the strike and the expiry are in the volatility key alone. The bucket columns of this page are the pair, the expiry and the strike.

A definition of this report binds the sensitivity analytic. The analytic names the sensitivity configuration document, and that document is the one whose root is SensitivityAnalysis. ORE validates it against external/ore/xsd/sensitivity.xsd. The analytic element in the run document states the parameters below.

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

The SensitivityAnalysis document carries one block for each group of risk factors. The groups are the discount curves, the index curves, the yield curves, the FX spots, the FX volatilities, the swaption volatilities, the cap and floor volatilities, the CDS volatilities, the default and credit curves, the equity spots and volatilities, the two inflation curve families, the two inflation cap and floor families, the dividend yields, the base correlations, the security spreads, the commodity curves and volatilities, the intraday power curves, the correlations and the bond future volatilities. It also carries four switches that are not factors, and ComputeGamma is one of them.

Every factor block states four things. ShiftType is Relative, Absolute or EqualTo. ShiftSize is a real, with an optional key for an alternative size. ShiftScheme is Forward, Backward or Central. The bucket list is one of ShiftTenors, ShiftExpiries, ShiftStrikes, ShiftLossLevels or ShiftTerms. ShiftType and ShiftScheme are enums in external/ore/xsd/ore_types.xsd.

The fragment below is the FX spot and FX volatility part of the shipped external/ore/examples/MarketRisk/Input/sensitivity.xml, trimmed to the first currency pair of each block.

<FxSpots>
  <FxSpot ccypair="USDEUR">
    <ShiftType>Relative</ShiftType>
    <ShiftSize>0.01</ShiftSize>
    <ShiftScheme>Forward</ShiftScheme>
  </FxSpot>
</FxSpots>

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

The spot block shifts the pair by one per cent relative. The volatility block shifts every expiry of the same pair by one per cent relative on the forward scheme. Its strike list is empty, and an empty strike list states the at-the-money point of each expiry alone. The two blocks are separate statements about one pair, and the pair of them is what a cross term needs. This ladder buckets by strike, so the configuration it binds states a strike list rather than the empty one the shipped block carries.

The engine writes sensitivity.csv with the columns TradeId, IsPar, Factor_1, ShiftSize_1, Factor_2, ShiftSize_2, Currency, Base NPV, Delta, Gamma, Currency(Trade), Base NPV(Trade), Delta(Trade), Gamma(Trade) and Scenario. It writes scenario.csv with the columns TradeId, Factor, Up/Down, Base NPV, ShiftSize_1, ShiftSize_2, Scenario NPV, Difference and Base Currency. A cross term arrives as a row with both Factor_1 and Factor_2 populated.

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 means ShiftSize 0.1 on a surface stored in vol points, or Absolute 0.001 on a surface stored in decimals. The store seeds neither, and the store states no shift size at all today.

A definition of this report states the rows below. Where the store states no value, the column says so. A parameter is declared with its domain on ore parameter, and a configuration binds it on configuration parameter.

1. Open sensitivity.csv from the run's output archive. Open scenario.csv beside it, because it holds the values behind the columns.
2. Keep the rows where Factor_2 is populated. A row with one factor is a first order figure and belongs to another ladder.
3. Read the kind of each factor. One is FXSpot and the other is FxVolatility. If both factors are of one kind, the row is a cross gamma and the cross-gamma page reads it.
4. Read the currency pair from the spot key. Read the strike and the expiry from the volatility key. These are the buckets of the ladder.
5. Group the rows by pair, by expiry and by strike, in that order.
6. Read the Gamma column in each bucket. That figure is the cross term. It says how much the vega of the position moves for the spot shift that ShiftSize_1 states.
7. Check both shift sizes. A cross term is a figure for one pair of shifts, and it is not comparable with a figure taken at another pair.
8. For one row you doubt, open scenario.csv on the same TradeId and the same factor. Read Scenario NPV and Difference. The difference is the value change for the shift that row states.
9. Compare two days only when the two runs bound the same sensitivity configuration. A change of shift size changes the scale of every figure on the ladder.

• 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.
• The run package carries only the four Setup documents, 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 seeded quotes and all of them are IR_SWAP/RATE/.... so a volatility factor has nothing to shift, and no volatility sensitivity can be computed until the store holds that data. A cross term needs a volatility on one side of the pair, so this ladder cannot be priced in the seeded environment.
• No shift size is stated anywhere in the store, so the document that would set this ladder has no stored value to read.
• No stored shape holds a pair of factors as a key. The paired row exists in the CSV file and in no table.
• The result store is not built, so a reader opens the CSV files and no table answers a query over them.

The report has no smoke test of its own. The smoke test that proves the machinery without gathering anything is Sample bundle smoke test.

A test run of this ladder executes the whole pipeline from the gather step and records the run. It stops before the engine has a volatility to shift, for the two reasons above. The run package carries no analytic document, and the dataset seeds no volatility market data. So the report is exercised by the full-pipeline proof and not by a run that writes rows.

• Reports, the inventory this page is listed in.
• Risk reporting, the classification taxonomy and the measures catalogue.
• ORE output formats, the columns of sensitivity.csv and scenario.csv.
• FX Volatility Surface, the surface one factor of the pair belongs to.
• Bump and Reprice Volga ladder, the curvature within the volatility factor.
• Bump and Reprice Cross-gamma ladder, the rows that pair two factors of one risk class.
• Bump and Reprice Delta ladder, the first order column of the same run.
• Bump and Reprice ATM vega ladder, the first order figure at one point of each expiry.
• Report execution pipeline, the phases every run goes through.
• Report definition and schedule, the definition that states the cycle and the cut.

• 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 writes the two files.
• Open Source Risk, the project home of the engine.