Strike Map

It answers where one currency pair's option notional sits when the reader buckets the book by option strike and by tenor. The answer feeds the decision a trader makes before quoting or hedging at a strike. The trader learns which strikes hold the largest part of the book and how that weight moves from one tenor to the next, and can size a hedge or price the next trade around it.

The report is the spike map with the axes changed. The spike map reads expiry date against spot level, and this report reads option strike against tenor. The catalogue states the two as separate reports because a desk asks the two questions at different moments.

The catalogue classifies the methodology as audit-derived. The report is derived from trade state and market data state, and it does not call the valuation engine to price a trade.

Cycle intraday. The catalogue states the frequency as on-demand. The seeded schedule expression is 0 0 31 2 *, which names 31 February, a date that never occurs, so the definition fires only when a person starts it. 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 roles that read the report.

• Trades selected by scope. The scope shape is book, and the seeded run settings read Global Portfolio for the entity, so a run covers the books under that portfolio rather than one named book.
• 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 Portfolio details - Global Portfolio, which states the base currency, the market data type live, the input and output paths and the log file.
• The analytic portfolioDetails, which is the only analytic the configuration binds. It inspects the portfolio and prices no trade.

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 marketObjects.csv and riskFactors.csv, the two files that portfolioDetails writes. The grid this report describes is in neither file. The result store that would carry it 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, portfolioDetails, and that analytic writes two files. Both files hold names. Neither file holds a group of trades, a bucket, or a value.

The report's shape is a grid, not a set of engine rows. Its axes are option strike and tenor, and one grid exists for each currency pair. A cell holds the notional of the trades in that bucket. Neither file holds a bucket or a value for a bucket, so the store does not hold the grid. The report post-processing design lists the tables that would hold it, and those tables are not built.

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/Legacy/Example_74/Input/ore.xml.

<Analytic type="portfolioDetails">
  <Parameter name="active">Y</Parameter>
  <Parameter name="riskFactorFileName">riskFactors.csv</Parameter>
  <Parameter name="marketObjectFileName">marketObjects.csv</Parameter>
</Analytic>

The seeded ACME configuration binds portfolioDetails at display order 1 with active set to Y. It states no parameter row for the analytic, so the file names in the fragment are the sample's and not the seed'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. The two files portfolioDetails writes support the first three steps only, because the grid does not exist yet.

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. Open the output archive and find the run's CSV files. They sit beside the engine's log.
3. Read the two files. They list the market objects and the risk factors the book reads, one row for each kind and one row for each name.
4. Once the grid exists, pick one currency pair. Read that pair as one table. Option strike runs across the page and tenor runs down it.
5. Read a cell as the notional of the options that carry that strike at that tenor.
6. Scan a tenor row for the strike that carries the most. Then read the same strike down the column across the tenors.
7. Compare one tenor with the next. A strike that dominates one tenor and disappears at the next is a shape the desk wants to know about before it quotes.
8. Carry away the pair, the strike and the tenor. That triple is what the trader acts on.

• The grid does not exist yet. No analytic writes a notional bucketed by strike and tenor, and the store has no place to hold the grid. The definition binds portfolioDetails, which writes two name lists.
• The strike and the delta of an option trade are properties of the trade and its instrument. No seeded analytic writes them bucketed.
• 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 files 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/Legacy/Example_74, which models this report's configuration and output. 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.
• Spike Map shows the same view bucketed by expiry and spot.
• Option Map shows the delta view beside the strike view.
• Trades Since Last In is the other report on demand from the live cut.
• Report execution pipeline states the phases every run goes through.
• Report post-processing designs the tables that would hold the grid.
• 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 portfolioDetails analytic writes the two files.