Bump and Reprice Cross-gamma ladder

It answers what the second order figure between two factors is. A first order figure states the value change for one bump of one factor. A second order figure states how that first order figure moves when a second factor moves. The decision it feeds is whether two first order hedges cover the book when the two markets move together, as rates of two currencies do. They do not cover it when the cross term is large, and this ladder is the page that says by how much.

Cross gammas arrive in the rows that name two factors. A row with one factor states a figure for that factor alone. A row with both Factor_1 and Factor_2 populated states the figure for the pair, and this page reads those rows. The engine writes them into sensitivity.csv at engine version 1.8.17.0. No crossgamma.csv is written at that version. The sensitivity configuration states a file name for cross gammas, and no writer reads it, so the paired rows in sensitivity.csv are the whole statement.

The market risk function reads the ladder to test a hedge set against the case where two markets move together. The trading desk reads it to decide how much of each of two related positions to keep.

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.
• The sensitivity configuration document, sensitivity.xml, which states the shift, the pairs the engine writes and the ComputeGamma switch.

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 cross gamma 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 bucket columns of this page are the two factor keys. A rate factor key names the kind of curve and the curve. The shipped file writes them as DiscountCurve/EUR and IndexCurve/EUR-EURIBOR-6M, and the filter pairs are substrings of keys of that form. A reader groups the rows by the two curve names in the pair, and reads Gamma in each group.

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 this page uses two of them, ComputeGamma and CrossGammaFilter.

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 EUR discount curve block of the shipped external/ore/examples/MarketRisk/Input/sensitivity.xml, trimmed to the four statements every factor block carries.

<DiscountCurves>
  <DiscountCurve ccy="EUR">
    <ShiftType>Absolute</ShiftType>
    <ShiftSize>0.0001</ShiftSize>
    <ShiftSize key="IR_FD">0.001</ShiftSize>
    <ShiftScheme>Forward</ShiftScheme>
    <ShiftScheme key="IR_FD">Central</ShiftScheme>
    <ShiftTenors>2W,1M,3M,6M,9M,1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,25Y,30Y</ShiftTenors>
  </DiscountCurve>
</DiscountCurves>

The block shifts each tenor of the curve by one basis point absolute, on the forward scheme, with an override of 0.001 on the central scheme under the key IR_FD. The bucket list is the tenor list. The same file states the pairs that the filter keeps, and they are the pairs this ladder reads.

<CrossGammaFilter>
  <Pair>DiscountCurve/EUR,DiscountCurve/EUR</Pair>
  <Pair>IndexCurve/EUR,IndexCurve/EUR</Pair>
  <Pair>DiscountCurve/EUR,IndexCurve/EUR</Pair>
</CrossGammaFilter>

A pair is a list of two substrings of factor keys. The first pair keeps the cross term of a discount curve against the same discount curve, the second keeps an index curve against itself, and the third joins a discount curve to an index curve. ComputeGamma is on in a configuration that produces this ladder, and the two switches together decide which rows the engine writes.

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. At engine version 1.8.17.0 no writer reads sensitivity.crossGammaOutputFile, so no crossgamma.csv appears in the archive. The evidence behind a paired row is scenario.csv. The scenario rows hold the base value, the shifted value and the difference for the factor the row names, so a reader can rebuild the figure from them.

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_1 and Factor_2 are both populated. A row with one factor is a first order figure and belongs to another ladder.
3. Read the two factor keys. This page reads the pairs of one risk class, as the filter states them.
4. Check the pair against the filter in the configuration. A pair the filter does not name does not appear in the file.
5. Read the tenor from the last part of each key, and group the rows by the two curve names and by that tenor.
6. Read the Gamma column in each group. That figure is the cross gamma. It says how the first order figure of the second factor moves when the first factor is bumped.
7. Check ShiftSize_1 and ShiftSize_2. 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. Read Base NPV, Scenario NPV and Difference for the factor the row names. The difference is the value change for the shift that row states, and it is the evidence behind the paired row.
9. Compare two days only when the two runs bound the same sensitivity configuration. A change of shift size, or a change of pair in the filter, changes the rows the file carries.

• 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. The rate pairs of this ladder need no volatility, but the run that would write them does not reach the engine either.
• 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.
• No crossgamma.csv is written at engine version 1.8.17.0. A reader who looks for that file finds nothing, and the paired rows in sensitivity.csv are the statement.
• 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 prices, 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.
• Bump and Reprice Gamma ladder, the second order figure for one factor.
• Bump and Reprice Delta ladder, the first order column of the same run.
• Bump and Reprice Vanna ladder, the paired rows that join a spot to a volatility.
• Bump and Reprice Rho ladder, the curves bumped at each tenor with the two effects apart.
• 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.