Bump and Reprice Rho ladder

It answers a question about one curve and one point at a time. If the rate at this point of this curve moves, how much money does the scope change by? The answer feeds two decisions. Market risk decides whether the book's exposure sits on the discount curve or on the projection curve. A desk decides which of the two to hedge with a swap.

The distinction matters because one trade reads both curves. A swap discounts its cash flows on one curve and projects its floating rate on another. A single number that adds the two effects hides which curve moved, and this report does not add them.

The rates delta 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 questions the shape of its rate risk while the day is still moving. Its "(EOD)" twin selects the EOD cut and values the portfolio at the weekday before the run date, which is the figure market risk compares across closes. 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 plain definition selects the LIVE cut and its run settings row states market data type live; the twin selects EOD and states eod. Holiday calendars are not consulted, so the close is the weekday before the run date whether or not that weekday traded.

• 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 with a block for each curve family. The discount curves and the index curves are separate blocks in the shipped document, so a reader sees the two effects in two rows rather than in one.

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, curve and bucket, 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.

The catalogue states the measure as a 0.1 per cent change of the rate at each point. That statement names the size of the bump the report is for. It does not change what the file holds, because the bump is a setting of the configuration and not the identity of the report. A reader who wants another size changes ShiftSize in the document and runs again.

Delta is a value change and not a derivative. The shift size is already inside it, so the figure is money per bump and not a ratio.

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 states the curve family and the curve, and ShiftSize_1 states the shift that produced the figure. A discount curve factor starts DiscountCurve/<ccy>, as in the Pair DiscountCurve/EUR,DiscountCurve/EUR of the shipped filter. A projection curve factor starts IndexCurve/<index>, as in IndexCurve/EUR-EURIBOR-6M/11/10Y. The first segment separates the discount effect from the projection effect, and the trailing segments name the bucket.

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 the two blocks a rho ladder reads are DiscountCurves and IndexCurves. Fourth, every factor block states ShiftType, ShiftSize, ShiftScheme and the bucket list, which for a curve is ShiftTenors.

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 and one index curve block. The discount curve is keyed by currency and the index curve is keyed by index, and that difference is what keeps the two effects apart in the output.

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

<IndexCurves>
  <IndexCurve index="EUR-EURIBOR-6M">
    <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>false</SingleCurve>
      <Conventions>
        <Convention id="DEP">EUR-EURIBOR-CONVENTIONS</Convention>
        <Convention id="IRS">EUR-6M-SWAP-CONVENTIONS</Convention>
        <Convention id="OIS">EUR-OIS-CONVENTIONS</Convention>
      </Conventions>
    </ParConversion>
  </IndexCurve>
</IndexCurves>

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

1. Open the archive the run recorded and take sensitivity.csv.
2. Separate the two families. Keep the rows whose Factor_1 starts DiscountCurve/, and read them as the discount effect. Keep the rows whose Factor_1 starts IndexCurve/, and read them as the projection effect.
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.
5. Read the Delta column as money per shift. Do not divide it by the shift.
6. Compare the two families at one tenor. The comparison states which curve the exposure sits on, and it is the reading this report exists for.
7. Open scenario.csv and read Difference for the same TradeId and Factor. It agrees with the Delta figure to the printed precision.
8. Read the same bucket on the previous close. Two closes state whether the exposure moved from one curve to the other.

• 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 catalogue states 0.1 per cent and the store cannot repeat that statement as a row.
• No stored shape holds a bucketed ladder, and nothing in the store holds the two curve effects as separate columns. They are separate rows, told apart by the factor key.
• 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.

• 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 DV01 ladder, which reads the same rate blocks as par values.
• 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 DiscountCurves and IndexCurves blocks produce these rows.