Bump and Reprice Delta ladder

It answers a question about one factor at a time. If this factor moves by the shift the configuration states, how much money does the scope gain or lose? The answer feeds three decisions. A desk decides which factor to hedge first and by how much. Market risk decides whether the book sits inside its limits. A reviewer decides whether a movement between two closes came from the market or from the book.

This page is the general case of the ladder family. Every other ladder is this reader applied to a particular block of the sensitivity document. The Gamma ladder applies it to the second-order column over the same buckets, and it states nothing new about the mechanism.

Both roles read one file. The difference is what they compare it against. A desk compares the ladder against its own position and asks what to trade. Market risk compares it against the previous close and asks what moved.

This ladder is end of day, and so are the gamma, theta, cross-gamma and par DV01 readers. A ladder is read as the risk statement of record and compared across days. The volatility ladders and the rates delta ladder also hold a live definition, which their own pages state, and a live ladder is indicative where this one stands. The end of day cut names the authorised close, so two ladders taken a day apart compare as one book measured against two closes.

The definition selects the EOD cut, and the run settings row it binds states market data type eod. The run therefore values the portfolio at the weekday before the run date, and holiday calendars are not consulted.

• Trades selected by the definition's scope. The scope is a row of the definition and the taxonomy fixes the shapes it accepts, on Risk reporting.
• Market data at the authorised end of day cut. The cut is the body the run prices from, and it is recorded on the run instance with its label, kind and instant.
• The risk report configuration the definition binds. It switches on the sensitivity analytic, states the base currency, and names sensitivity.xml as the sensitivityConfigFile. The same analytic states recalibrateModels Y, outputSensitivityThreshold 0.000001, parSensitivity Y and marketConfigFile simulation.xml.
• The SensitivityAnalysis document itself. It is a row in the file library and a name in the analytic's lookup, and it is not a modelled entity. See What is not built.

The run produces the engine's own output archive and records where that archive landed against the run instance. The archive holds sensitivity.csv, which carries one row for each trade and factor, and scenario.csv, which carries the scenario value behind each row.

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

Delta is a value change and not a derivative. It is money per shift, and the shift size is already inside it. A reader who wants the change for a larger shift does not divide by the shift to get a ratio and does not scale the figure. The reader changes ShiftSize in the document and runs the report again.

The Delta column of sensitivity.csv and the Difference column of scenario.csv agree to the printed precision. The two files state one arithmetic from two directions, and a reader uses either column and expects the same answer.

The reader opens the engine's CSV files, because the result store is not built. The tables below state the columns of the two files this report writes. The definitions are on ORE output formats.

A reader places a figure by the bucket columns. Factor_1 carries the risk class and the bucket, and ShiftSize_1 states the shift that produced the figure. A volatility factor states the pair, the strike and the expiry, as in FxVolatility/<pair>/<strike>/<expiry>. A swaption volatility adds the term, as in SwaptionVolatility/<key>/<strike>/<expiry>/<term>. An optionlet volatility states the currency, a number, the expiry and the strike. A curve factor names the curve and the bucket, as in IndexCurve/EUR-EURIBOR-6M/11/10Y, and a discount curve factor starts DiscountCurve/<ccy>.

The mechanism has four parts. First, the generated run document carries an analytic of type sensitivity, and that analytic names sensitivity.xml through sensitivityConfigFile. Second, the root of that document is SensitivityAnalysis, and ORE validates the document against external/ore/xsd/sensitivity.xsd. Third, the document carries one block for each group of risk factors, among them discount curves, index curves, FX spots, FX volatilities, swaption volatilities, cap and floor volatilities, credit curves, equity spots and volatilities and the inflation families. Fourth, every factor block states ShiftType, ShiftSize, ShiftScheme and the bucket list, which is ShiftTenors, ShiftExpiries, ShiftStrikes, ShiftLossLevels or ShiftTerms.

ShiftType is Relative, Absolute or EqualTo. ShiftScheme is Forward, Backward or Central. Both are enumerations in external/ore/xsd/ore_types.xsd.

The fragment below is trimmed from external/ore/examples/MarketRisk/Input/sensitivity.xml. It shows the FX spot block and the head of one discount curve block.

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

<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>

The engine writes sensitivity.csv with the columns the reader saw above, and it writes scenario.csv with the scenario value and the difference behind each figure.

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. Nothing in the name of this report fixes a shift, and nothing in the engine knows a ladder by name.

A definition of this report states the rows below. The shift itself is not a parameter of the store, and no seed states a shift size anywhere. The store can name the document that holds the shift, and the document states the size.

1. Open the archive the run recorded and take sensitivity.csv. Ignore the other files until step 6.
2. Choose one risk class. Read the first segment of Factor_1, for example IndexCurve or FxVolatility, and keep the rows of that class.
3. Read the bucket. The trailing segments of Factor_1 name the curve, the expiry or the strike the row sits at.
4. Read ShiftSize_1 for the row. That figure is the shift the engine applied, and it is the denominator a reader would otherwise look for.
5. Read the Delta column as money per shift. Do not divide it by the shift and do not scale it. To read a different size, change ShiftSize in the document and run again.
6. Open scenario.csv and find the row with the same TradeId and the same Factor. Read Difference and compare it against the Delta figure. The two agree to the printed precision.
7. Sum the Delta column over the trades of a book to state the book total for that bucket. Keep the bucket, because a total over all buckets is a different question.
8. Read the same bucket on the previous close. Two ladders a day apart state whether the shape of the risk changed, and not only whether its size changed.
9. Keep the Currency column and the Currency(Trade) column apart. One states the run's base currency and the other states the trade's own, so a sum across trades needs one of the two and not both.

• 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.
• No volatility market data is seeded. The ACME dataset holds 420 quotes and all of them are IR_SWAP/RATE/.... A book that needs a volatility therefore meets a refusal at the engine, and the run records that refusal against the run instance.
• No shift size is stated anywhere in the store. The store can name a document and cannot state what the document bumps.
• No stored shape holds a bucketed ladder. The bucket is a segment of a factor key in a CSV file.
• The result store is not built, so no table carries the rows a reader queries.

The sensitivity configuration type is seeded with root SensitivityAnalysis, the parameter sensitivityConfigFile and the owner ores.analytics. The document and its two surface variants sit in the ORE file library with their descriptions, the schema is vendored as sensitivity_schema, and the worked configurations are vendored.

No substitute is defined for this report, so a test run executes every phase and assembles its own bundle. The report is therefore exercised by the full-pipeline proof and not by a smoke test. The machinery that proves a bundle without gathering one is Sample bundle smoke test.

Two limits are worth stating. The engine writes a row only where a change passes the output threshold, so a small book can produce a short file. And a run over a book that needs a volatility records the engine's refusal, which is a fact about the environment and not about this report.

• Reports, where this page is listed.
• Risk reporting, which holds the classification taxonomy and the measures catalogue.
• ORE output formats, which states the columns of sensitivity.csv and scenario.csv.
• Bump and Reprice Gamma ladder, which carries the second-order column over the same buckets.
• Bump and Reprice DV01 ladder, which reads the rate blocks as par values.
• Report execution pipeline, which states the phases every run goes through.
• The cut is the body a run prices from, which states what an end of day cut holds.
• Report post-processing, which designs the result store this report waits for.
• Light the intraday reports on the LIVE cut, the task that lit the sibling reports.

• 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.