Trades Since Last In

It answers which trades arrived in the book since a stated instant, how many there are, and how much notional they add. The answer feeds two decisions. A trader reads it to check that the morning's activity landed as intended. A middle office reader reads it to confirm that the book a colleague shares carries the trades both of them expect.

The report is a query over the trade store rather than an engine output. The platform runs one report workflow for every report, and that workflow runs the engine, so the definition binds an analytic that inspects the portfolio. The catalogue classifies the methodology as audit-derived for the same reason. The section "What is not built" states what the archive therefore cannot give.

Cycle intraday. The definition is seeded with the expression */15 8-17 * * 1-5, which fires it every fifteen minutes through the London trading day on weekdays, and a person may start a run at any time. The product owner set that cadence on 2026-11-04. 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 or portfolio, and the seeded run settings read Global Portfolio for the entity.
• A stated date and time, which the catalogue names as the start of the list. No seeded parameter states it, so no seeded run names the instant.
• 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. Neither file holds a trade. The result store that would carry the trade list 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 trade, a booking time, a count or a notional.

The report's shape is a list of trades, one row for each trade booked since the stated instant. The list the reader needs carries a trade identifier, the booking date and time, and the notional. No file the analytic writes holds a trade identifier, a booking time or a notional, so the store does not hold the list. 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. 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, and the cut instant is the upper bound of the period the reader wants.
2. Recall the stated instant, which is the lower bound. No seeded parameter carries it, so the reader supplies it.
3. Open the output archive and find the run's CSV files.
4. 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.
5. Look for the trade identifiers the report states as a measure. Neither file holds one.
6. Look for the booking timestamp of each trade, which is what decides whether a trade falls inside the period. Neither file holds one either.
7. State the count, the notional added and the list of identifiers between the two instants. Until a trade list exists, the reader cannot complete this step.

• The trade list is a query over the trade store, not an engine output. The definition runs the engine because the platform has one report workflow and that workflow runs the engine.
• The trades a run prices come from the gather step's portfolio, so the archive carries the priced trades and not the booking timestamps that the stated instant needs. This definition binds no analytic that writes a trade row, so the archive it leaves holds no trade at all.
• No seeded parameter states the date and time the list starts from.
• 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 is a report read on demand from the live cut.
• Strike Map reads the book by strike and tenor.
• Report execution pipeline states the phases every run goes through.
• Report post-processing designs the tables that would hold the trade list.
• 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.