Option Map

It answers where the notional of one currency pair sits across delta and across strike in one table. The answer feeds the decision a trader makes when the book looks balanced on one axis and is not balanced on the other. A book can carry little delta risk and still hold a large notional at one strike, and this report is the one that puts the two readings side by side.

The report joins two views. The traditional option map buckets the book by delta, and the strike view buckets the same book by option strike. The catalogue states them as one report because a reader who sees one axis alone can draw the wrong conclusion about the other.

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 role that reads 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 delta bucket and strike, and one grid exists for each currency pair. A cell holds the notional of the trades that fall in both buckets. 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 it as one table, with delta buckets across the page and strikes down it.
5. Read a cell as the notional of the options that sit in that delta bucket at that strike.
6. Read one delta row and find the strike that carries the most, then read the same strike down its column. The two readings together are what the report exists to show.
7. Look for a book that appears balanced in the delta direction and holds its notional at one strike. That is the case this report is built to catch.
8. Carry away the pair, the delta bucket and the strike. That triple is what the trader acts on.

• The grid does not exist yet. No analytic writes notional bucketed by delta and strike, and the store has no place to hold the grid. The definition binds portfolioDetails, which writes two name lists.
• Delta and strike are not columns of any file ORE writes for a run that binds no sensitivity analytic. A delta bucket needs the sensitivity analytic and a strike bucket needs the volatility surface, and neither is seeded.
• 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 concentration view by expiry and spot.
• Strike Map shows the concentration view by strike and tenor.
• 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.