Bump and Reprice Spot Greeks (EOD)

It answers what the book is worth, and what its Delta is, at a grid of spot shift levels, on the figures the day is closed with. The decision it feeds is the sign off. Market risk states the directional risk of a book, and a later run of the intraday definition does not replace it.

The intraday definition and this one share the analytics, the measures and the files. They differ in the cut they select and in the run settings row they bind, so the same report name on the two cycles is two definitions.

Cycle eod. The definition is seeded with the expression 0 18 * * 1-5, which fires it at 18:00 London time on weekdays. It is not a member of an ordered batch.

The concurrency policy is skip. A firing that arrives while a run of the same definition is in flight is dropped.

The definition states cut_kind_code EOD, which names the authorised end of day cut. The run settings row states market_data_type eod, so the generator takes the valuation date as the weekday before the run date. Holiday calendars are not consulted.

• Trades selected by scope. The scope shape is book.
• Market data for the as-of date, taken from the day's authorised end of day cut.
• The risk report configuration the definition binds, Valuation and sensitivities (EOD) - Global Portfolio. The row states the market data type eod and the base currency, which is the entity's, so GBP for the UK entity, USD for the US entity and HKD for the HK entity.
• The engine settings row the definition binds, through the engine_settings configuration type. The pricing engine for an end of day definition is EOD Official.

A definition binds six configuration documents, one per configuration type. The six codes 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 run produces the engine's own output archive. The archive holds the CSV artefacts of the two bound analytics: npv.csv, sensitivity.csv and scenario.csv. The run also records the cut it minted, with the cut's identity, its label, its kind and its instant.

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

The set is the business catalogue's for this report and is the same set the intraday definition carries. The definitions are on Risk reporting and are not repeated here.

The analytics write three files, the same three the intraday definition writes. The tables below state the columns of those files, as ORE output formats lists them. A (Base) column is in the run's base currency. A (Trade) column is in the trade's currency.

npv.csv holds the net present value and notional of each trade.

sensitivity.csv holds the sensitivities of each trade: Delta and Gamma for each factor, and cross gammas for factor pairs. The file has two header variants.

scenario.csv holds the value of each trade under each shifted factor.

The configuration binds two analytics, in this order. The npv fragment is trimmed from external/ore/examples/MarketRisk/Input/ore_pnl.xml and the sensitivity fragment is trimmed from external/ore/examples/MarketRisk/Input/ore_sensi.xml.

The base currency is the entity's, so the fragment shows GBP for the UK entity. The file states USD for its own sample.

<Analytic type="npv">
  <Parameter name="active">Y</Parameter>
  <Parameter name="baseCurrency">GBP</Parameter>
  <Parameter name="outputFileName">npv.csv</Parameter>
</Analytic>
<Analytic type="sensitivity">
  <Parameter name="active">Y</Parameter>
  <Parameter name="marketConfigFile">simulation.xml</Parameter>
  <Parameter name="sensitivityConfigFile">sensitivity.xml</Parameter>
  <Parameter name="scenarioOutputFile">scenario.csv</Parameter>
  <Parameter name="sensitivityOutputFile">sensitivity.csv</Parameter>
  <Parameter name="outputSensitivityThreshold">0.000001</Parameter>
  <Parameter name="recalibrateModels">Y</Parameter>
  <Parameter name="parSensitivity">Y</Parameter>
</Analytic>

The sensitivity analytic reads its shift settings from the document that sensitivityConfigFile names. That document is not part of the run package the service builds, which carries only the four Setup documents.

A definition of this report states the rows below. The values are the seeded ones; the domains are the ones the engine and the classification taxonomy fix. The mechanism is on ore parameter.

A person reads this report at the screen in the order below. No run has produced rows yet, so the steps name the files and the comparisons and quote no figure.

1. Open the archive the run recorded. Take npv.csv first, because it states the book at the cut the run priced from, and the other two files refer to it.
2. In npv.csv, read the NPV(Base) column against the TradeId and NettingSet columns. The sum over the rows is the value the day is closed with.
3. Read the Maturity and MaturityTime columns on the rows that matter. They state which trades the figure sits on.
4. Open sensitivity.csv and read the Factor_1 column to find the spot factors the run shifted. ShiftSize_1 states how far each factor moved.
5. Read the Delta column on those rows. Delta is money per shift, and the shift size is already inside it.
6. Open scenario.csv and read Base NPV, Scenario NPV and Difference across the rows with the same Factor value. The difference is the scenario value less the base value.
7. Compare the Difference column with the Delta column of step 5. The two agree to the printed precision, because both state the value change for one shift.
8. Compare this close with the last close of the intraday definition, factor by factor. The two are different cuts, so a movement between them is a movement of the book and of the market data, and not one figure computed twice.

• The spot shift grid the catalogue describes is a scenario grid, which is a stress configuration. It is not the sensitivity analytic.
• No ACME risk report configuration switches the stress analytic on. The seeded definition therefore produces the sensitivity columns and not a per shift level P&L grid.
• The dataset holds no volatility market data. Its 420 seeded quotes are all IR_SWAP/RATE/..., with no FX_OPTION/RATE_LNVOL quote and no volatility surface configuration. so a volatility factor has nothing to shift, and no volatility sensitivity can be computed until the store holds that data.
• The result store is not built, so a reader opens the CSV files in the archive.
• 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 analytic type, the sensitivity configuration type and the file types are in the store. The cut resolution this report depends on is exercised by Light the intraday reports on the LIVE cut, and the end of day cut it reads is the kind the cuts structure describes.

The pricing phase cannot produce a volatility figure in the seeded environment, because the store holds no volatility market data. A test run proves the gather, the cut and the generated run document, and it proves no volatility row. A reader who needs one supplies volatility market data first.

• Reports, the inventory this page is listed in.
• Bump and Reprice Spot Greeks, the same analytic set on the live cut.
• Risk reporting, the classification taxonomy and the measures catalogue.
• The cut is the body a run prices from, what a cut holds and what it does not.
• Report definition and schedule, how the definition and its schedule are seated.
• Report execution pipeline, the phases every run goes through.
• Report compute handoff, how the run reaches the grid.
• Report post-processing, the store that would hold the rows.
• Cuts
• Report definition and schedule

• 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 produces these rows.