Bump and Reprice Spot Ladder

It answers what a currency pair's forward curve is at a tenor the desk names, and what the neighbouring tenors are. The decision it feeds is a quote. The desk states a forward rate at one tenor, and the ladder tells it whether that tenor sits where the curve says it should, and what a hedge at a nearby tenor would cost.

The catalogue states the report is read from the live cut and not from a valuation, because a desk asks for it in the middle of a quote. The definition runs every half hour through the London trading day, so the curve a desk reads is at most half an hour old, and a desk may still ask for a run at any instant. The product owner set that cadence on 2026-11-04.

The section "What is not built" states what a run of the seeded definition actually leaves behind, because the analytic the definition binds inspects the book and does not price it.

Cycle intraday. The definition is seeded with the expression */30 8-17 * * 1-5, which fires it every half hour through the London trading day on weekdays, and a person may ask for a run at any time. It is not a member of an ordered batch.

The concurrency policy is skip. A firing that arrives while a run of the same definition is in flight is dropped.

The definition states cut_kind_code LIVE. A LIVE cut mints at the instant the run begins and carries the indicative label.

• Trades selected by scope. The scope shape is book.
• Market data at the instant the run starts. The run mints a LIVE cut, which holds what the store held then, and the curve the run builds comes from that body.
• The risk report configuration the definition binds, Portfolio details - Global Portfolio. The row states the market data type live and the base currency, which is the entity's.
• The engine settings row the definition binds. The pricing engine for a live definition is Intraday Indicative.

A definition binds six configuration documents, one per configuration type. The six codes 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 ORE reads all of them before it prices.

The run produces the engine's own output archive. The archive holds the CSV artefacts of the one bound analytic, portfolioDetails. Those files are marketObjects.csv and riskFactors.csv. The run also records the cut it minted, with the cut's identity, its label, its kind and its instant.

The rows a reader would query are a later phase. The result store is designed on Report post-processing and is not built, so a reader opens the CSV files in the archive.

The set is the catalogue's for this report. The definitions are on Risk reporting and are not repeated here.

The aggregation can be out of today, out of tomorrow or out of spot. The choice states the date the points are counted from, and a reader who compares two ladders states which one the ladder was built on.

The analytic writes two files. The tables below state the columns of those files, as ORE output formats lists them. The values in both files are names, not amounts.

marketObjects.csv holds the market objects a portfolio depends on, one row for each kind, with the objects of that kind.

riskFactors.csv holds the risk factors a portfolio depends on, one row for each kind, with the factors of that kind.

Neither file carries a column for a tenor, a rate or a points figure. The two files list names, so the reader of a run of the seeded definition learns which objects and which factors the book reads, and not what the curve states.

The configuration binds one analytic. The fragment 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 two parameters name the two output files. portfolioDetails is the analytic a report asks for when it inspects data rather than prices it, because ORE needs at least one analytic in the document and a report of this kind has no valuation to request.

A definition of this report states the rows below. The values are the seeded ones; the domains are the ones the engine and the classification taxonomy fix. The mechanism is on ore parameter.

A person reads this report at the screen in the order below. No run has produced rows yet, so the steps name the files and the comparisons and quote no figure.

1. Open the archive the run recorded and take riskFactors.csv first. Read the RiskFactorType column to see which kinds of factor the book depends on, and the RiskFactorName column to see which factor keys sit under each kind.
2. Find the rows whose type states a discount curve or a yield curve. Those rows are the curve factors, and the names in them carry the currency and the index of each curve.
3. Find the rows whose type states an FX spot. The name states the currency pair, so a reader connects the ladder to the pair the desk is quoting.
4. Open marketObjects.csv and read MarketObjectType against MarketObjectName. The objects of the curve kind are the curves the run built, and a reader matches each one to the factor rows of step 2.
5. Compare the curve names in the two files. A curve the market objects list and the risk factors do not is a curve the book reads and does not address, and it is the first thing a reader checks before asking for a rate.
6. Look for a column that states a tenor, a rate, a discount factor or a points figure. No such column exists in either file, so the ladder of rates a desk asked for is not in the archive.
7. Compare the set of market objects with the pair the desk named. If the pair is absent from both files, the book reads no curve for it, and a ladder for that pair cannot come from this book.

• No seeded analytic writes a ladder of forward outrights per tenor.
• The forward rates come from the curve the run builds. ORE writes them as the curve's quotes and discount factors, in curves.csv, which only the curves analytic writes.
• The definition binds the portfolio details, so the seeded report lists the market objects the book reads and not a ladder of rates.
• The dataset holds no volatility market data. Its 420 seeded quotes are all IR_SWAP/RATE/..., with 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.
• No shift size is stated anywhere in the store, and no stored shape holds a bucketed ladder.

The portfolioDetails analytic type and the two file types are in the store, and the worked configuration the fragment comes from is vendored.

The definition fires on its own schedule now, so a test run starts either from the scheduler or from a person. It proves the gather, the cut and the generated run document. It proves no ladder of rates, because the bound analytic writes names. The pricing phase also stops where the engine needs a volatility, so a run of this definition records the refusal and not a priced book.

• Reports, the inventory this page is listed in.
• Bump and Reprice Spot Greeks, the spot risk view of the same cut.
• Risk reporting, the classification taxonomy and the measures catalogue.
• The cut is the body a run prices from, what a LIVE cut holds and what it does not.
• Report definition and schedule, how the definition and its schedule are seated.
• Report execution pipeline, the phases every run goes through.
• Report compute handoff, how the run reaches the grid.
• Report post-processing, the store that would hold the rows.
• ORE output formats
• Report definition and schedule

• Report families — the structure note that orders this cluster, and where to read this page in it.
• Open Source Risk Engine, the valuation engine whose portfolioDetails analytic writes these two files.