ORE Model Configuration

• ORE filename: pricingengine*.xml (~72 files with variants for AMC, SABR, delta-gamma).
• Root element: <PricingEngines>.
• Purpose: Maps each product type to a pricing model, model parameters, engine implementation, and engine parameters.

• ORE filename: simulation*.xml (~83 files with variants for XVA, credit, inflation).
• Root element: <Simulation>.
• Purpose: Defines the cross-asset stochastic model, Monte Carlo parameters, and market structure for scenario generation.

• ORE filename: sensitivity.xml (~36 files).
• Root element: <SensitivityAnalysis>.
• Purpose: Defines bump-and-revalue shift specifications per market risk factor type for Greeks computation.

• ORE filename: stresstest.xml (~14 files).
• Root element: <StressTesting>.
• Purpose: Defines named stress scenarios with market shifts applied to curves, spots, and volatility surfaces.

• ORE filename: ore.xml and ore_*.xml (~370 files).
• Root element: <ORE>.
• Purpose: Top-level configuration that ties everything together — specifies input paths, market configs, and which analytics to run.

• ORE filename: counterparty.xml (~10 files).
• Root element: <CounterpartyInformation>.
• Purpose: Maps counterparty IDs to regulatory risk weights for CVA and initial margin calculations.

• ORE filename: collateralbalances.xml (~10 files).
• Root element: <CollateralBalances>.
• Purpose: Specifies initial collateral positions (IM, VM) per netting set at valuation date.

• ORE filename: scriptlibrary.xml (~10 files).
• Root element: <ScriptLibrary>.
• Purpose: Defines custom payoff scripts in ORE's domain-specific language for structured products.

The instrument type (currently named trade_type in the codebase) classifies the financial product for booking, lifecycle management, and regulatory reporting. It answers: what is this trade?

Examples: Swap, Swaption, FxOption, Bond, CreditDefaultSwap, CommodityForward, ScriptedTrade.

Currently seeded with ~90 codes in ores_trading_trade_types_tbl. This taxonomy aligns with the ISDA Product Taxonomy at the base product level. In industry standards (FpML, CDM), attributes like exercise style are properties of the product, not separate product types.

The pricing engine type is a pricing-specific classification at the granularity needed by the pricing engine to select the correct model and numerical method. It answers: how should this trade be priced?

Examples: EuropeanSwaption, BermudanSwaption, AmericanSwaption, CMS, CMSSpread, CapFlooredIborLeg, CapFlooredOvernightIndexedCouponLeg.

This is not an industry-standard taxonomy — it is an ORE/QuantLib implementation concept. It exists because the pricing engine needs a lookup key to select the model and numerical engine, and that key must be finer-grained than the instrument type:

1. Exercise style determines the numerical method: A European swaption uses Black-Bachelier (analytic), a Bermudan uses LGM + Grid (finite difference), an American uses LGM + FD. Same instrument type, completely different numerical methods.
2. Coupon and leg-level pricers: CMS, CMSSpread, CapFlooredIborLeg are coupon or leg-level pricers. They do not correspond to any instrument type but are needed by the pricing engine to value specific leg types within a trade.
3. Product variants need different engines: FxOption (European) uses AnalyticEuropeanEngine; FxOptionAmerican needs FdBlackScholesVanillaEngine.

This taxonomy lives in ores.analytics as ores_analytics_pricing_engine_types_tbl:

The FK is null for coupon/leg-level types (CMS, CapFlooredIborLeg, etc.) that have no corresponding instrument type.

The mapping from instrument type to pricing engine type is determined at pricing time based on trade attributes:

Instrument Type + Trade Attributes → Pricing Engine Type → Model + Engine

Examples:
  Swaption + European exercise   → EuropeanSwaption  → BlackBachelier + BlackBachelierSwaptionEngine
  Swaption + Bermudan exercise   → BermudanSwaption   → LGM + Grid
  Swaption + American exercise   → AmericanSwaption   → LGM + FD
  FxOption + European style      → FxOption            → GarmanKohlhagen + AnalyticEuropeanEngine
  FxOption + American style      → FxOptionAmerican    → GarmanKohlhagen + FdBlackScholesVanillaEngine
  Swap (with CMS leg)            → CMS (leg-level)     → LinearTSR + LinearTSRPricer

One instrument type can map to multiple pricing engine types depending on attributes. Not every pricing engine type maps back to an instrument type.

Each layer must be independently:

• Versionable: changing Greek settings does not version the pricing model config.
• Reusable: FO and Finance may share the same smile surface but use different model parameters.
• Diffable: P&L attribution requires granular comparison — "the reversion changed from 0.03 to 0.05 for LGM" must be a diffable field, not buried in a JSON blob.
• Overridable: the layering model (system → report definition → report instance → deal-level) can swap individual layers without duplicating the whole config.

Maps each pricing engine type to the pricing model and numerical engine used to value it. In ORE terms, this is the <PricingEngines> document.

pricing_model_config (header)
 ├── pricing_model_config_parameters (global params, no product FK)
 ├── pricing_model_products (one row per pricing engine type)
 │    └── pricing_model_product_parameters (per-product params)

• Header: name, description, variant tag.
• Global parameters: normalised rows (name, value) with FK to header only. These are ORE's <GlobalParameters> (e.g. ContinueOnCalibrationError).
• Product rows: one per pricing engine type, each mapping to a model and engine. The pricing_engine_type_code references ores_analytics_pricing_engine_types_tbl.
• Product parameters: normalised rows (name, value) with FK to product row. These are ORE's <ModelParameters> and <EngineParameters>, distinguished by a parameter_scope column (model or engine).

All parameters are stored as normalised rows (not JSON) to support granular diffing. Each parameter is a name-value pair where the value is always text (numerics, booleans, comma-separated lists are all text in ORE).

Determines the vol surface model per currency pair. Three settings per pair: smile model (SABR, 5-point spline, BS flat), parameter form (ATM + RR + STR, raw vols), and interpolation method (ATM curve, linear in variance, physical, market). Supports system defaults with per-pair overrides and force-override mode.

Defines which sensitivities to compute and how: selection from canonical Greeks (PV, Delta, Gamma, Vega, Theta, Rho, etc.), computation mode per Greek (unbumped, bumped, analytic, weighted, model-specific), and bump parameters. Greek sets are reusable templates selected by name.

Cross-model parameters: rates/vols interpolation, ATM curve usage, roll types (spot, vol, rates), PV offset in days, coupon handling, brokerage inclusion, multi-threading, default bump sizes.

Scalar and term-structure parameters per pricing model. Scalar parameters may be report-specific (e.g. MC simulation count) or fixed (e.g. mean reversion). Term structure parameters have values at each tenor.

ORE's XML files do not map 1:1 to the domain layers. The mapping is:

When importing pricingengine.xml, the inline model/engine parameters should be extracted into the normalised parameter model (layer 5 or as detail rows under layer 1, depending on whether parameters are considered part of the product-model mapping or a separate concern).

Diffing pricing configurations is a core requirement for:

1. Impact of Pricing Configuration reports: quantify P&L difference between configs.
2. Model Risk Unit (MRU) analysis: compare baseline vs alternative configs.
3. Audit: track what changed between versions.

The compositional model supports this naturally: diff at the layer level first (which layers changed?), then diff within each changed layer. Normalised parameter rows enable SQL-native set diffs.