Bump and Reprice DV01 ladder

It answers a question about one bucket of one curve at a time. If the rate at this point of this curve moves by one basis point, how much money does the scope change by? The answer feeds the hedge decision a rates desk makes every morning, and it feeds the limit that market risk sets on curve exposure.

The report states the answer twice. One statement is in zero rates, which is the form the engine shifts. The other is in par rates, which is the form a trader quotes. The two answers describe one position, and the page states which file carries which.

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 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 run records the cut it read against 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 analytic states recalibrateModels Y, outputSensitivityThreshold 0.000001, parSensitivity Y and marketConfigFile simulation.xml.
• A sensitivity document that carries ParConversion on every curve block it shifts. The shipped document does, and the fragment below shows the shape.

The run produces the engine's own output archive and records where that archive landed against the run instance. The archive holds three files for this report. sensitivity.csv carries the figures in zero rates, parsensitivity.csv carries the same figures in par rates, and scenario_par_rates.csv carries the base and scenario par rate behind each par instrument.

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.

The rate blocks are shifted at Absolute 0.0001, and ParConversion is stated on every curve block, so the figures are par-rate values. One basis point is the convention of the family, and the page states the setting so a reader does not have to assume it.

Delta is a value change and not a derivative. The shift size is already inside it, so a DV01 figure is money per one basis point and not a rate of change. A reader who wants money per ten basis points changes ShiftSize in the document and runs again.

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

The par files carry their own columns.

A reader places a figure by the bucket columns. Factor_1 carries the curve, the bucket number and the tenor, as in IndexCurve/EUR-EURIBOR-6M/11/10Y, and a discount curve factor starts DiscountCurve/<ccy>. In the par files the bucket is the ParKey, which names the instrument the curve bucket converts to. The instrument list of a curve is the Instruments list inside its ParConversion block, and the conventions it names are the ones the par rate is quoted with.

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 it against external/ore/xsd/sensitivity.xsd. Third, the document carries one block for each group of risk factors, and for a rates ladder the blocks that matter are discount curves, index curves and yield curves. Fourth, every factor block states ShiftType, ShiftSize, ShiftScheme and the bucket list, which for a curve is ShiftTenors. The par conversion group is one of the switches that are not factors, and it states the instrument list, whether the curve is a single curve and the conventions.

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 one discount curve block with its bucket list and its par conversion.

<DiscountCurve ccy="GBP">
  <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>
  <ParConversion>
    <Instruments>DEP,DEP,DEP,DEP,DEP,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS</Instruments>
    <SingleCurve>true</SingleCurve>
    <Conventions>
      <Convention id="DEP">GBP-DEPOSIT</Convention>
      <Convention id="IRS">GBP-6M-SWAP-CONVENTIONS</Convention>
      <Convention id="OIS">GBP-OIS-CONVENTIONS</Convention>
    </Conventions>
  </ParConversion>
</DiscountCurve>

The engine writes sensitivity.csv with the columns the reader saw above, it writes parsensitivity.csv and scenario_par_rates.csv beside it, 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. A DV01 ladder is this report with the rate blocks at Absolute 0.0001, and a ladder at another size is the same report with another document.

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.

1. Open the archive the run recorded and take sensitivity.csv.
2. Keep the rows whose Factor_1 starts DiscountCurve/ or IndexCurve. Those are the rate blocks.
3. Read the bucket. The trailing segments of Factor_1 name the curve, the bucket number and the tenor.
4. Read ShiftSize_1. It states the size of the move the figure belongs to, and the shipped document states one basis point.
5. Read the Delta column as money per shift. Do not divide it by the shift.
6. Open parsensitivity.csv and find the row of the same trade. Read its Delta as the same change stated in par terms.
7. Open scenario_par_rates.csv and read BaseParRate and ScenarioParRate for the ParKey. The pair states the par rate before and after the shift, and the change between them is the shift the par instrument saw.
8. Match the ParKey to the Instruments list of the curve block that shifted it. That match names the trade a desk uses to hedge the bucket.
9. Read the same bucket on the previous close. Two closes state whether the curve exposure moved.

• 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.
• No shift size is stated anywhere in the store. The store can name the document and cannot state that the document bumps one basis point.
• No stored shape holds a bucketed ladder. The bucket is a segment of a factor key in a CSV file, and the par instrument is a row of a second 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 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.

The par files have their own expected outputs in the ORE examples, which is what makes a par conversion checkable without a market data set of our own.

• 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, parsensitivity.csv and scenario_par_rates.csv.
• Bump and Reprice Rho ladder, which keeps the discount and projection curves apart.
• Bump and Reprice Delta ladder, which is the general case of the ladder family.
• 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.
• 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 ParConversion group writes the par files.