Intraday Risk Monitor

It answers what risk a book carries in the middle of the day, between the close that authorised yesterday and the close that will authorise today. The decision it feeds is the one a desk head makes at the screen: hold, trim, or hedge, now, against figures that are indicative and will be replaced by the close. It is the report that says whether another, deeper report is worth opening before then.

Two facts make the answer usable. First, the figures are known to be indicative: the live cut copies the kind's indicative mark, so a reader knows the numbers will move. Second, the run records the body it priced from, so a reader of the result can say which instant it was, even though a rerun will not reproduce it.

Cycle intraday. Frequency scheduled and on-demand: the definition is seeded with the expression */30 8-17 * * 1-5, which fires it every half hour through the London trading day on weekdays, and a person may ask for one at any time. It is not a member of the ten-report Market Risk EOD set.

The concurrency policy is queue: a firing that arrives while a run of the same definition is in flight waits rather than being dropped, because a monitor that skips a half hour answers a question nobody asked.

• Trades selected by scope. The seeded definition reads the entity's whole portfolio, Global Portfolio for a trading entity, because a monitor is run on any book under it; the scope shape the catalogue allows is book or portfolio.
• Market data at the instant the run starts. The run mints a LIVE cut, which holds what the store held then: the published sets in use, the trade population, and the versions of the reference data and of the engine.
• The risk report configuration the definition binds, Intraday risk - Global Portfolio, which switches on the three analytics below and states the base currency.

The run produces the engine's own output archive with this report's CSV artefacts, and it records where that archive landed against the run. It also records the cut the run minted: 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 yet.

A LIVE result is reproducible only by naming its cut. Two runs of the monitor on one day are two bodies and two results, comparable as a movement and not as one figure computed twice.

The set is the configuration's. The measures below are the ones the business catalogue states this report carries; their definitions are on Risk reporting and are not repeated here.

The run binds three analytics, so the archive carries the files a reader uses and the intermediate file one analytic hands to another.

npv.csv, written by the npv analytic, gives one row for each trade. A reader sums its NPV(Base) column over the book to obtain the PV measure. Its columns are TradeId, TradeType, Maturity, MaturityTime, NPV, NpvCurrency, NPV(Base), BaseCurrency, Notional, NotionalCurrency, Notional(Base), NettingSet and CounterParty.

sensitivity.csv, written by the sensitivity analytic, gives one row for each trade and risk factor. The delta ladder is this file read by factor and summed over trades. Its columns are 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. A Delta is money per shift, and the shift is already inside it.

var.csv, written by the parametricVar analytic, carries the VaR estimate and its breakdown by risk class. The analytic reads sensitivity.csv as its input, which is why the file type marks that file as an intermediate the run must produce before the estimate can be computed.

scenario.csv holds the value of each trade in each shifted market, with columns TradeId, Factor, Up/Down, Base NPV, ShiftSize_1, ShiftSize_2, Scenario NPV, Difference and Base Currency. It is the evidence behind the Delta column.

The top movers and the limit utilisation are not columns of any of these files. The catalogue states them as measures the report carries, and neither has a producing analytic in the seeded configuration.

The configuration binds three analytics, in this order. The fragment for parametricVar is trimmed from external/ore/examples/MarketRisk/Input/ore_parametricvar.xml; the npv and sensitivity fragments are the shape every valuation document states.

<Analytic type="npv">
  <Parameter name="active">Y</Parameter>
  <Parameter name="baseCurrency">GBP</Parameter>
</Analytic>
<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="outputSensitivityThreshold">0.000001</Parameter>
  <Parameter name="parSensitivity">Y</Parameter>
</Analytic>
<Analytic type="parametricVar">
  <Parameter name="active">Y</Parameter>
  <Parameter name="quantiles">0.99</Parameter>
  <Parameter name="method">DeltaGammaNormal</Parameter>
  <Parameter name="breakdown">Y</Parameter>
</Analytic>

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 reader opens this report when a book is moving and the answer cannot wait for the close.

1. Open the latest run for the entity and the book. Read the run instance first. It names the cut the run minted, and that cut says which body was priced.
2. Take npv.csv, select the rows for the book and sum NPV(Base). That is the PV measure at the instant the run started.
3. Compare with the previous run's total. Two monitors of one day compare as a movement, because each priced a different body.
4. Take sensitivity.csv and group by Factor_1. Sum Delta in each group. Sort the groups by absolute total, and read the largest as the risk the desk must decide about before the close.
5. Read var.csv for the estimate at the stated quantile. The estimate is computed from the sensitivities, so a change here follows a change in the delta ladder.
6. Decide: hold, trim or hedge now. Then read the close report after the market shuts, for the figures that stand.

• The top movers and the limit utilisation have no producing analytic. The catalogue states both as measures the report carries, and the run writes neither.
• The live cut is mintable only where the store answers the parts of a body, and an environment with no published market data set mints the cut and then refuses at the engine, because there is no snapshot to price from. The engine's refusal is recorded against the run and against the cut it minted, so a reader is told which of the two failed.
• No volatility market data is seeded, so a volatility factor has nothing to shift.
• The result store is not built, so the rows a screen would query do not exist and a reader opens the CSV files in the archive.

No substitute is defined for this report, so a test run of it executes every phase: it gathers trades and market data and assembles its own bundle. The report is exercised by the full-pipeline proof, not by a smoke test, and the cut resolution it relies on is exercised by the task that lit the intraday reports: Light the intraday reports on the LIVE cut.

• Reports, the inventory this page is listed in.
• Risk reporting, the classification taxonomy and the measures catalogue.
• The cut is the body a run prices from, what a LIVE cut holds and what it does not.
• Headline Position, the shallow summary a reader opens first, and this report's sibling on the live cut.
• Intraday Change, what moved since a stated time, rather than where the risk sits now.
• Bump and Reprice Spot Greeks, the directional view this monitor's delta ladder points at.
• Trades Since Last In, the trades booked since a stated instant, when a move needs an explanation.
• Report execution pipeline, the phases every run goes through.

• 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 parametricVar analytic produces the estimate.