Intraday Change

It answers how far a book's value and its Greeks have moved since the desk last looked, and how much of that move the market data explains. The answer feeds the decision a trader makes between two readings of the same book, which is whether to act now or to leave the position to the close. It is the intraday counterpart of the end of day explain run, and it is read while the move is still in progress.

The catalogue classifies the methodology as risk-predict, which approximates a P&L from stored Greeks and re-values nothing. The seeded definition binds npv, which re-values the book. The two statements do not agree, and the run follows the bound analytic.

The catalogue states the report against a reference time. A reader sets the instant to measure from, and the report states the change between that instant and the instant of the run. That construction needs two readings of the same book, and the run produces one. The section "What is not built" states the consequence.

Cycle intraday. The catalogue states the frequency as scheduled and event-driven. The seeded schedule expression is */30 8-17 * * 1-5, which fires the definition every half hour through the trading day on weekdays. The concurrency policy is skip, so a firing that arrives while a run of the same definition is in flight does not start a second run. The report belongs to no ordered batch.

The Owner row names the role that reads the report.

• Trades selected by scope. The scope shape is book or portfolio, and the seeded run settings read Global Portfolio for the entity.
• Six configuration bindings, one for each configuration type. They 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 the engine reads all of them before it prices.
• The run settings row Valuation - Global Portfolio, which states the base currency, the market data type live, the input and output paths and the log file.
• The analytic npv, with the base currency as its parameter. It is the only analytic the configuration binds.
• A reference time, which the catalogue states as configurable. No seeded parameter states it, so no seeded run names the instant to measure from.

The run produces the engine's own output archive, and it records where that archive landed against the run instance. It also records the cut the run minted, with the cut's identity, its label, its kind and its instant. The archive holds npv.csv, the one file that npv writes. The file holds one valuation of each trade at the run's instant. It holds no reference time, no earlier valuation and no difference. The result store that would carry the change is designed on Report post-processing and is not built.

The values below are the ones the business catalogue states this report carries. Their definitions belong to the measures catalogue on Risk reporting and are not repeated here.

The definition binds one analytic, npv, and that analytic writes one file. The table states its columns and what each one holds.

The report's shape is not the engine's rows. Its shape is a table of changes, with one row for each trade or each Greek and one column for the move since the reference time. The file ORE writes holds one valuation per trade and no column for an earlier valuation or for a difference, so the store does not hold the change.

The run document is generated, not stored. The service builds it from the definition's bindings and the run settings, in run document generator. The analytics appear in the configuration's display order, with their parameters. The fragment below is the shape the generator writes for the analytic, and it is trimmed from external/ore/examples/MarketRisk/Input/ore_pnl.xml.

<Analytic type="npv">
  <Parameter name="active">Y</Parameter>
  <Parameter name="baseCurrency">USD</Parameter>
  <Parameter name="outputFileName">npv.csv</Parameter>
  <Parameter name="additionalResults">Y</Parameter>
</Analytic>

The seeded ACME configuration binds npv at display order 1 with active set to Y. It states one parameter row, baseCurrency, whose value is GBP for the UK entity. It states no row for outputFileName and none for additionalResults, so those two values in the fragment are the sample's.

The table states the rows a definition of this report carries. The mechanism is on ore parameter.

A person at the screen reads this report in the steps below. No run has produced rows, so the steps state what the reader does and what the archive would and would not give.

1. Open the report instance and read the cut it minted. The label says indicative, so the figures are a view taken between closes.
2. Read the instant of the cut, and the instant of the previous reading. The change is measured between the two.
3. Open the output archive and find npv.csv.
4. Read one row for each trade. The row states the trade, its type, its maturity, its present value in its own currency and its present value in the base currency.
5. Sum the NPV(Base) column over the book to state the present value at the run's instant.
6. Look for the same sum at the reference time. No file in the archive holds it.
7. State the change as the difference between step 5 and the reading at the reference time, and read the market data move beside it. Only the first half of that sentence is available today.

• The change needs two valuations of the same book. The run produces one.
• The definition binds npv only. That analytic writes no Greek and no market data series, so the run carries neither the Greek changes nor the market data changes the catalogue names.
• Nothing in the store keeps a reference-time valuation for a live run, so the earlier reading has no place to come from.
• The pnlExplain analytic is the ORE analytic that decomposes a P&L between two dates. The P&L Attribution report binds it, and this definition does not.
• The ACME dataset holds no volatility market data. Its 420 seeded quotes are all IR_SWAP/RATE/.... There is 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 file in the archive rather than a table of rows.

No substitute is defined for this report, so a test run executes every phase. It gathers trades and market data, assembles its own bundle, builds the run document, submits the work and collects what comes back. The run stops where the engine needs a volatility, and the refusal is recorded against the run instance. The analytic the definition binds is also exercised by the engine's own sample, external/ore/examples/MarketRisk/Input/ore_pnl.xml, which binds npv in the same element shape. The task that lit the report is Light the intraday reports on the LIVE cut.

• Reports is the inventory this page is listed in.
• Risk reporting carries the classification taxonomy and the measures catalogue.
• Intraday Risk Monitor reads the book's risk between closes.
• Headline Position states the headline Greeks the change is measured on.
• Report execution pipeline states the phases every run goes through.
• Report post-processing designs the tables that would hold the change.
• The cut is the body a run prices from states what a LIVE cut holds.
• Report definition and schedule states the definition fields and the schedule.

• Report families — the structure note that orders this cluster, and where to read this page in it.
• Open Source Risk Engine is the engine whose npv analytic writes the file.