Zero-rate sensitivity leaks to adjacent pillar when `parSensitivity=Y`

[DmitriGoloubentsev]

ORE Bug Report — Zero-rate sensitivity leaks to adjacent pillar when parSensitivity=Y

Summary

Enabling <Parameter name="parSensitivity">Y</Parameter> on a sensitivity
analytic corrupts the zero-rate sensitivity (sensitivity.csv) output.
A trade whose payoff depends on a discount factor at exactly a simmarket
pillar date receives spurious sensitivity at the adjacent pillar, even
though LogLinear DF interpolation makes that sensitivity mathematically
exactly zero.

The par-conversion computation should not affect the zero-rate bucket
output — and does not: running the same trade with parSensitivity=N
produces the correct zero-rate sensitivities. The issue is that turning
par sensitivity ON apparently modifies the scenario-sim-market yield-curve
build path in a way that no longer cleanly lines up pillar times with the
requested ShiftTenors, or equivalently introduces cross-pillar coupling
in the shift application.

Reproducer

Self-contained ORE config (from Examples/Legacy/Example_40
and Examples/Input).

/opt/.../bugs/ORE-upstream-risk-buckets/
├── README.md                       ← this file
├── ore.xml                         ← default: parSensitivity=Y → BUGGY
├── Input/
│   ├── portfolio.xml               ← single FxForward, ValueDate = asof+2Y exactly
│   ├── sensitivity.xml             ← EUR+USD discount curves, ParConversion=OIS
│   ├── simulation.xml              ← simmarket tenors incl. 1Y and 2Y pillars
│   ├── todaysmarket.xml
│   ├── pricingengine.xml
│   ├── conventions.xml
│   ├── curveconfig.xml
│   ├── market_20160205.txt
│   └── fixings_20160205.txt
└── Output_WITH_parsens/            ← buggy output saved
    Output_NO_parsens/              ← correct output saved

All inputs are taken from ORE's Examples/Legacy/Example_40/Input/
and Examples/Input/ (market_20160205.txt, fixings_20160205.txt,
conventions.xml, curveconfig.xml, pricingengine.xml). The only
trade is a stock FxForward pointing at the 2Y tenor:

<FxForwardData>
  <ValueDate>2018-02-05</ValueDate>   <!-- asof 2016-02-05 + 2Y exactly -->
  <BoughtCurrency>EUR</BoughtCurrency>
  <BoughtAmount>1000000</BoughtAmount>
  <SoldCurrency>USD</SoldCurrency>
  <SoldAmount>1100000</SoldAmount>
</FxForwardData>

Run

cd .../ORE-upstream-risk-buckets
/path/to/ore ore.xml

Default run uses parSensitivity=Y → reproduces the bug.
Toggle the parSensitivity flag in ore.xml to compare.

Expected

FxForward matures at the exact simmarket 2Y tenor date
(asof + 2Y = 2018-02-05). Its NPV is

NPV = BoughtAmount · DF_EUR(2Y) − SoldAmount · DF_USD(2Y) · FX(EURUSD)

depending on the discount curves only at t = T_2Y. Under the configured
<Interpolation>LogLinear</Interpolation>, a 1bp shift at the adjacent
1Y pillar contributes exactly zero at t = T_2Y (the LogLinear tent
has weight 0 at t=t2). See
OREAnalytics/orea/scenario/shiftscenariogenerator.cpp ~line 215:

else if (times[k] > t1 && times[k] <= t2)
    w = (t2 - times[k]) / (t2 - t1);   // = 0 at t2

Expected zero-rate sensitivities for FXFWD_2Y_EXACT:

Factor	Delta
DiscountCurve/EUR/5/1Y	0.00
DiscountCurve/EUR/6/2Y	−201.66
DiscountCurve/USD/5/1Y	0.00
DiscountCurve/USD/6/2Y	+189.45

This is exactly what Output_NO_parsens/sensitivity.csv shows.

Actual (with parSensitivity=Y)

FXFWD_2Y_EXACT, DiscountCurve/EUR/5/1Y, ShiftSize 0.0001, Delta = -1.12    ← SPURIOUS
FXFWD_2Y_EXACT, DiscountCurve/EUR/6/2Y, ShiftSize 0.0001, Delta = -200.54  ← reduced
FXFWD_2Y_EXACT, DiscountCurve/USD/5/1Y, ShiftSize 0.0001, Delta = +1.05    ← SPURIOUS
FXFWD_2Y_EXACT, DiscountCurve/USD/6/2Y, ShiftSize 0.0001, Delta = +188.40  ← reduced

The EUR total is preserved (-1.12 + -200.54 = -201.66) and the USD total
is preserved (+1.05 + +188.40 = +189.45) — but the attribution is wrong.

Both effects scale with the magnitude of the 2Y sensitivity:
approximately 0.55% of the 2Y value leaks to 1Y.

Impact

• Per-bucket sensitivity reports are misleading when parSensitivity=Y,
  which is common in production setups.
• Aggregated totals across the full curve cancel the error, but per-pillar
  attribution is wrong.
• Trades whose cashflows land on simmarket pillar dates (swaps at standard
  tenors, zero-coupon bonds, FxForwards at IMM dates, etc.) all exhibit
  the leak whenever par sensitivity is enabled.

Hypothesized root cause

Turning par sensitivity on switches the yield-curve construction path
inside ScenarioSimMarket — ParSensitivityInstrumentBuilder
constructs par instruments (OIS, IRS, etc.) to compute the Jacobian.
Building those instruments appears to either:

• re-place pillar times via a different day counter convention than the
  shift-tenor day counter, producing T_bond ≠ T_pillar by a few
  milliseconds of year-fraction, making the LogLinear interpolation no
  longer collapse to a single pillar; OR
• inject a residual shift into the adjacent pillar while building the
  Jacobi transposition.

Verifying: add DLOG of yieldCurveTimes[] in
OREAnalytics/orea/scenario/scenariosimmarket.cpp addYieldCurve
(around line 310) and compare the times between parSensitivity=Y and
parSensitivity=N runs. Alternatively, inspect
ParSensitivityInstrumentBuilder::createParInstruments() for any
side-effect that perturbs neighboring pillar quotes.

Environment

• ORE: https://github.com/OpenSourceRisk/Engine tag v1.8.15.0
  (commit 0b2fc17, QuantLib submodule 9094ab64c) — bug reproduces.
• Compiler: GCC 12.4, Linux x86-64
• Boost 1.82
• Default <ObservationMode>None</ObservationMode> (from Example_40).

Build

git clone --recurse-submodules https://github.com/OpenSourceRisk/Engine.git
cd Engine && mkdir build && cd build
cmake .. -DORE_BUILD_APP=ON -DORE_BUILD_TESTS=OFF \
  -DBOOST_ROOT=/path/to/boost -DBoost_NO_SYSTEM_PATHS=ON -G Ninja
ninja ore

ore-config.zip

[pcaspers]

Hi @DmitriGoloubentsev,

thank you for pointing this out.

The calculation of par sensitivities in ORE is done in two steps

• calculate zero sensitivities
• transform to par space by multiplying with the jacobian matrix dzero / dpar

To make this work, the zero sensis have to use the same pillars as the par instruments prescribe and that is why we align the pillars of the zero sensi calculation with those of the par instruments. We write out the zero sensitivity report in this form too, to ensure transparency of the above two steps.

To get the zero sensitivities with unadjusted pillars you have to run the sensitivity analytic without par conversion (and setting alignPillars = false).

Let us know if that works for you.

Best
Peter