Headline Position

Answers what a book's or a portfolio's headline Greeks are right now. It feeds two decisions: whether a desk's position is where the desk thinks it is, and whether the market risk function will sign off on the current state of risk. It is deliberately shallow and wide, the first report a reader opens, and the one that says which deeper report to open next.

The Greek set is configurable, so the same report serves a desk that wants Delta and P&L and a risk function that wants the full set with the aggregation applied.

Cycle intraday and eod, frequency on-demand and scheduled. A desk asks for it during the day; the schedule produces it at the close. It is not a member of the ten-report Market Risk EOD set, so nothing orders it after the market data cut.

The two cycles are two seeded definitions, because a definition states one cut selection. Headline Position selects the LIVE cut and runs every ten minutes, and Headline Position (EOD) selects the end of day cut and runs at the close. They read one run settings document, so the two differ in the body they price from and in nothing else.

• Trades selected by scope. The scope is a book or a portfolio; the taxonomy allows no wider scope and no single-trade scope.
• Market data for the as-of date. A numeric-bump run needs the signed-off end of day cut; an intraday run needs the current market data.
• The analytics configuration the definition binds. The configuration decides, among other things, which Greek set the run computes and whether the Greeks are computed or read.
• Stored Greeks for the risk-predict methodology. That path re-prices nothing: it approximates the P&L from Greeks the platform already holds, so it needs no market data of its own and no re-valuation.

The run produces the engine's own output archive, which holds the report's CSV artefacts, and it records where that archive landed against the report instance. The report rows a reader would query are a later phase: the result store is designed on Report post-processing and is not built yet.

Aggregation is applied by the producing engine, not by the reader: the run aggregates by book, by portfolio, by currency pair, by Greek, and by unit hedge.

The set is configurable. The values below are the ones the catalogue states this report typically carries; the definitions are the measures catalogue's, on Risk reporting, and are not repeated here.

The seeded definition binds two analytics, the npv and the one the methodology selects, so the archive carries the files those analytics write. A reader uses three of them.

nvp.csv gives one row for each trade, and a reader sums its NPV(Base) column to obtain the present value of a book. Its columns are TradeId, TradeType, Maturity, MaturityTime, NPV, NpvCurrency, NPV(Base), BaseCurrency, Notional, NotionalCurrency, Notional(Base), NettingSet and CounterParty.

sensitivity.csv gives one row for each trade and risk factor, for a definition that computes its Greeks. 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 a value change in money, and the shift size that produced it is in ShiftSize_1, already inside the number.

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.

A definition that selects the risk-predict methodology writes no sensitivity file. It reads the Greeks the platform already holds, so the archive carries the present values and the approximation the report makes from them.

The numeric-bump methodology is ORE's sensitivity analytic. The fragment below is the shape of that analytic, trimmed from external/ore/examples/MarketRisk/Input/ore_sensi_eq_credit_index_decomposition.xml.

<Analytic type="sensitivity">
  <Parameter name="active">Y</Parameter>
  <Parameter name="marketConfigFile">simulation.xml</Parameter>
  <Parameter name="sensitivityConfigFile">sensitivity.xml</Parameter>
  <Parameter name="pricingEnginesFile">pricingengine.xml</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 base valuation the P&L measures are taken against comes from a second analytic in the same document:

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

The risk-predict methodology has no ORE configuration of its own. It is computed inside ORE Studio from stored Greeks, so a definition that selects it runs no valuation and needs no Analytic element.

A definition of this report states the rows below. The first five and the last four are the ones the seeded definition states, and a reader finds them on the definition and on the run settings it binds. The rest are the choices the business catalogue fixes for the report and that no seeded row carries yet. The mechanism is on ore parameter.

A person reads the intraday definition as a picture of risk that moves, and reads the close definition for a figure that stands.

1. Open the run for the entity, the book and the time. Read the run instance first. A run of this definition mints a LIVE cut, and the cut's label carries the entity and the instant, so a reader can tell two runs of one day apart.
2. Take npv.csv, select the rows for the book and sum NPV(Base). That total is the present value at the instant the run started.
3. Compare with the total from the last run of the same definition. The two totals are two bodies of market data and two results, so their difference is a movement and not one figure computed twice.
4. Take sensitivity.csv and group by Factor_1. Sum Delta in each group. The largest groups are where the book's risk sits, and the ShiftSize_1 column says what each figure was measured against.
5. Choose the deeper report from the largest group. A curve factor sends the reader to a rates ladder, a volatility factor to a vol ladder, and a spot factor to a spot ladder.
6. When the day closes, read the close definition for the figures that are signed off. A later run of this definition never replaces them.

• The report prices from a live cut, so two runs of a day do not reproduce each other. The run records the body it priced from; it cannot return the body.
• The dataset holds curve quotes only, and no volatility market data, 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 the figures live in the archive and a reader opens the CSVs by hand.
• The methodology the definition states is the computed one. The risk-predict path, which reads stored Greeks instead of revaluing, has no configuration and no seeded definition.

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 therefore exercised by the full-pipeline proof, not by a smoke test.

The smoke test that proves the machinery without gathering anything is Sample bundle smoke test.

• Reports, the inventory this page is listed in.
• Headline Position (EOD), the close twin, on the authorised end of day cut.
• Risk reporting, the classification taxonomy and the measures catalogue.
• Report execution pipeline, the phases every run goes through.
• Report compute handoff, how the run reaches the grid.
• Report execution, the workflow that runs it.
• Run a full report: scheduling, reporting and compute

• Report families — the structure note that orders this cluster, and where to read this page in it.
• Open Source Risk Engine, the valuation engine this report's numeric-bump path runs on.