ORE User Guide

24 May 2024

1
Document History

Date Author Comment

7 October 2016 Quaternion initial release
28 April 2017 Quaternion updates for release 2
7 December 2017 Quaternion updates for release 3
20 March 2019 Quaternion updates for release 4
19 June 2020 Quaternion updates for release 5
30 June 2021 Acadia updates for release 6
16 September 2022 Acadia updates for release 7
6 December 2022 Acadia updates for release 8
31 March 2023 Acadia updates for release 9
16 June 2023 Acadia updates for release 10
16 October 2023 Acadia updates for release 11
24 May 2024 Acadia updates for release 12

2
Contents
1 Introduction 13
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 ORE in Python or Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Further Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Release Notes 17

3 ORE Data Flow 21

4 Getting and Building ORE 22

4.1 ORE Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Building ORE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.2 Boost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3 ORE Libraries and Application . . . . . . . . . . . . . . . . . . . 25
4.2.4 Supported Compiler and Boost Versions . . . . . . . . . . . . . . 28
4.3 Python and Jupyter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Building ORE-SWIG and Python Wheels . . . . . . . . . . . . . . . . . . 29

5 Examples 30
5.0 ORE Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1 Interest Rate Swap Exposure, Flat Market . . . . . . . . . . . . . . . . . 33
5.2 Interest Rate Swap Exposure, Realistic Market . . . . . . . . . . . . . . . 35
5.3 European Swaption Exposure . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Bermudan Swaption Exposure . . . . . . . . . . . . . . . . . . . . . . . . 36
5.5 Callable Swap Exposure . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6 Cap/Floor Exposure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.7 FX Forward and FX Option Exposure . . . . . . . . . . . . . . . . . . . 39
5.8 Cross Currency Swap Exposure, without FX Reset . . . . . . . . . . . . 40
5.9 Cross Currency Swap Exposure, with FX Reset . . . . . . . . . . . . . . 40
5.10 Netting Set, Collateral, XVAs, XVA Allocation . . . . . . . . . . . . . . . 41
5.11 Basel Exposure Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.12 Long Term Simulation with Horizon Shift . . . . . . . . . . . . . . . . . 45
5.13 Dynamic Initial Margin and MVA . . . . . . . . . . . . . . . . . . . . . . 46
5.14 Minimal Market Data Setup . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.15 Sensitivity Analysis, Stress Testing and Parametric Value-at-Risk . . . . 47
5.16 Equity Derivatives Exposure . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.17 Inflation Swap Exposure under Dodgson-Kainth . . . . . . . . . . . . . . 52
5.18 Bonds and Amortisation Structures . . . . . . . . . . . . . . . . . . . . . 53
5.19 Swaption Pricing with Smile . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.20 Credit Default Swap Pricing . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.21 CMS and CMS Cap/Floor Pricing . . . . . . . . . . . . . . . . . . . . . . 55
5.22 Option Sensitivity Analysis with Smile . . . . . . . . . . . . . . . . . . . 55
5.23 FRA and Average OIS Exposure . . . . . . . . . . . . . . . . . . . . . . . 55
5.24 Commodity Derivatives, Pricing, Sensitivity, Exposure . . . . . . . . . . 56
5.25 CMS Spread with (Digital) Cap/Floor . . . . . . . . . . . . . . . . . . . 56

3
 5.26 Bootstrap Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.27 BMA Basis Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.28 Discount Ratio Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.29 Curve Building using Fixed vs. Float Cross Currency Helpers . . . . . . 58
5.30 USD-Prime Curve Building via Prime-LIBOR Basis Swap . . . . . . . . 58
5.31 Exposure Simulation using a Close-Out Grid . . . . . . . . . . . . . . . . 58
5.32 Inflation Swap Exposure under Jarrow-Yildrim . . . . . . . . . . . . . . . 59
5.33 CDS Exposure Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.34 Wrong Way Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.35 Flip View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.36 Choice of Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.37 Multifactor Hull-White Scenario Generation . . . . . . . . . . . . . . . . 62
5.38 Cross Currency Swap Exposure using Multifactor Hull-White Models . . 64
5.39 Exposure Simulation using American Monte Carlo . . . . . . . . . . . . . 64
5.40 Par Sensitivity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.41 Multi-threaded Exposure Simultion . . . . . . . . . . . . . . . . . . . . . 72
5.42 ORE Python Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.43 Credit Portfolio Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.44 Initial Margin: ISDA SIMM and IM Schedule . . . . . . . . . . . . . . . 74
5.45 Collateralized Bond Obligation . . . . . . . . . . . . . . . . . . . . . . . 76
5.46 Generic Total Return Swap . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.47 Composite Trade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.48 Convertible Bond and ASCOT . . . . . . . . . . . . . . . . . . . . . . . . 76
5.49 Bond Yield Shifted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.50 Zero to Par sensitivity Conversion Analysis . . . . . . . . . . . . . . . . . 77
5.51 Custom Trade Fixings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.52 Scripted Trade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.53 Curve Building around Central Bank Meeting Dates . . . . . . . . . . . . 80
5.54 Scripted Trade Exposure with AMC: Bermudan Swaption and LPI Swap 80
5.55 Scripted Trade Exposure with AMC: Target Redemption Forward . . . . 81
5.56 CVA Sensitivities using AAD . . . . . . . . . . . . . . . . . . . . . . . . 81
5.57 Base Scenario Analytic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.58 Historical Simlation VaR Analytic . . . . . . . . . . . . . . . . . . . . . . 81
5.59 SABR Model for Swaptions and Caps/Floors . . . . . . . . . . . . . . . . 82
5.60 Overlapping Close-Out Grids . . . . . . . . . . . . . . . . . . . . . . . . 83
5.61 Fast Sensitivities using AAD and GPUs . . . . . . . . . . . . . . . . . . 83
5.62 P&L and P&L Explain Analytics . . . . . . . . . . . . . . . . . . . . . . 83
5.63 Stress Tests in the Par-Rate Domain . . . . . . . . . . . . . . . . . . . . 84
5.64 Formula-based Coupon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.65 Flexi Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.66 Balance Guaranteed Swap . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.67 XVA Stress Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.68 XVA Bump & Revalue Sensitivities . . . . . . . . . . . . . . . . . . . . . 85
5.69 Zero Rate Shifts To Par Shifts . . . . . . . . . . . . . . . . . . . . . . . . 85

6 Launchers and Visualisation 86

6.1 Jupyter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.2 Calc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.3 Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4
7 Parameterisation 87
7.1 Master Input File: [Link] . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.1.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.1.2 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.1.3 Markets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.1.4 Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.2 Market: [Link] . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.2.1 Discounting Curves . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.2.2 Index Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.2.3 Yield Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.2.4 Swap Index Curves . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.2.5 FX Spot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.2.6 FX Volatilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.2.7 Swaption Volatilities . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.2.8 Cap/Floor Volatilities . . . . . . . . . . . . . . . . . . . . . . . . 109
7.2.9 Default Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.2.10 Securities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.2.11 Equity Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.2.12 Equity Volatilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.2.13 Inflation Index Curves . . . . . . . . . . . . . . . . . . . . . . . . 111
7.2.14 Inflation Cap/Floor Volatility Surfaces . . . . . . . . . . . . . . . 112
7.2.15 CDS Volatility Structures . . . . . . . . . . . . . . . . . . . . . . 112
7.2.16 Base Correlation Structures . . . . . . . . . . . . . . . . . . . . . 113
7.2.17 Correlation Structures . . . . . . . . . . . . . . . . . . . . . . . . 113
7.2.18 Market Configurations . . . . . . . . . . . . . . . . . . . . . . . . 113
7.3 Pricing Engines: [Link] . . . . . . . . . . . . . . . . . . . . 115
7.3.1 Product Type: Ascot . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.3.2 Product Type: Bond . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.3.3 Product Type: BondOption . . . . . . . . . . . . . . . . . . . . . 116
7.3.4 Product Type: ConvertibleBond . . . . . . . . . . . . . . . . . . . 116
7.3.5 Product Type: CreditLinkedSwap . . . . . . . . . . . . . . . . . . 119
7.3.6 Product Type: EuropeanSwaption . . . . . . . . . . . . . . . . . 120
7.3.7 Product Type: BermudanSwaption . . . . . . . . . . . . . . . . . 124
7.3.8 Product Type: AmericanSwaption . . . . . . . . . . . . . . . . . . 128
7.3.9 Product Type: BondRepo . . . . . . . . . . . . . . . . . . . . . . 132
7.3.10 Product Type: BondTRS . . . . . . . . . . . . . . . . . . . . . . 133
7.3.11 Product Type: CapFloor . . . . . . . . . . . . . . . . . . . . . . . 134
7.3.12 Product Type: CapFlooredIborLeg . . . . . . . . . . . . . . . . . 134
7.3.13 Product Type: CapFlooredOvernightIndexedCouponLeg . . . . . 135
7.3.14 Product Type: CapFlooredAverageONIndexedCouponLeg . . . . 135
7.3.15 Product Type: CapFlooredAverageBMAIndexedCouponLeg . . . 136
7.3.16 Product Type: CappedFlooredCpiLegCoupons . . . . . . . . . . . 136
7.3.17 Product Type: CappedFlooredCpiLegCashFlows . . . . . . . . . . 137
7.3.18 Product Type: CommodityAveragePriceOption . . . . . . . . . . 137
7.3.19 Product Type: CommodityAveragePriceBarrierOption . . . . . . 138
7.3.20 Product Type: CommodityForward . . . . . . . . . . . . . . . . . 139
7.3.21 Product Type: CreditDefaultSwap . . . . . . . . . . . . . . . . . 139
7.3.22 Product Type: CreditDefaultSwapOption . . . . . . . . . . . . . . 140

5
7.3.23 Product Type: IndexCreditDefaultSwap . . . . . . . . . . . . . . 141
7.3.24 Product Type: IndexCreditDefaultSwapOption . . . . . . . . . . 141
7.3.25 Product Type: CpiCapFloor . . . . . . . . . . . . . . . . . . . . . 142
7.3.26 Product Type: YYCapFloor . . . . . . . . . . . . . . . . . . . . . 143
7.3.27 Product Type: CappedFlooredYYLeg . . . . . . . . . . . . . . . . 143
7.3.28 Product Type: CappedFlooredNonStdYYLeg . . . . . . . . . . . 144
7.3.29 Product Type: CMS . . . . . . . . . . . . . . . . . . . . . . . . . 144
7.3.30 Product Type: SyntheticCDO . . . . . . . . . . . . . . . . . . . . 145
7.3.31 Product Type: CBO . . . . . . . . . . . . . . . . . . . . . . . . . 147
7.3.32 Product Type: CMSSpread . . . . . . . . . . . . . . . . . . . . . 147
7.3.33 Product Type: DurationAdjustedCMS . . . . . . . . . . . . . . . 148
7.3.34 Product Type: CommodityAsianOptionArithmeticPrice . . . . . . 149
7.3.35 Product Type: CommodityAsianOptionArithmeticStrike . . . . . 150
7.3.36 Product Type: CommodityAsianOptionGeometricPrice . . . . . . 151
7.3.37 Product Type: CommodityAsianOptionGeometricStrike . . . . . 154
7.3.38 Product Type: CommoditySpreadOption . . . . . . . . . . . . . . 155
7.3.39 Product Type: CommodityOption . . . . . . . . . . . . . . . . . . 156
7.3.40 Product Type: CommodityOptionForward . . . . . . . . . . . . . 156
7.3.41 Product Type: CommodityOptionEuropeanCS . . . . . . . . . . . 157
7.3.42 Product Type: CommodityOptionAmerican . . . . . . . . . . . . 157
7.3.43 Product Type: CommoditySwap . . . . . . . . . . . . . . . . . . 158
7.3.44 Product Type: CommoditySwaption . . . . . . . . . . . . . . . . 159
7.3.45 Product Type: EquityAsianOptionArithmeticPrice . . . . . . . . 160
7.3.46 Product Type: EquityAsianOptionArithmeticStrike . . . . . . . . 162
7.3.47 Product Type: EquityAsianOptionGeometricPrice . . . . . . . . . 163
7.3.48 Product Type: EquityAsianOptionGeometricStrike . . . . . . . . 165
7.3.49 Product Type: EquityBarrierOption, FxBarrierOption . . . . . . 167
7.3.50 Product Type: EquityDoubleBarrierOption, FxDoubleBarrierOp-
tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.3.51 Product Type: EquityDigitalOption, FxDigitalOption . . . . . . . 168
7.3.52 Product Type: EquityEuropeanCompositeOption . . . . . . . . . 169
7.3.53 Product Type: EquityForward . . . . . . . . . . . . . . . . . . . . 169
7.3.54 Product Type: EquityFutureOption . . . . . . . . . . . . . . . . . 170
7.3.55 Product Type: EquityOption . . . . . . . . . . . . . . . . . . . . 170
7.3.56 Product Type: EquityCliquetOption . . . . . . . . . . . . . . . . 171
7.3.57 Product Type: QuantoEquityOption . . . . . . . . . . . . . . . . 172
7.3.58 Product Type: EquityOptionEuropeanCS . . . . . . . . . . . . . 172
7.3.59 Product Type: EquityOptionAmerican . . . . . . . . . . . . . . . 173
7.3.60 Product Type: EquityTouchOption, FxTouchOption . . . . . . . 174
7.3.61 Product Type: ForwardBond . . . . . . . . . . . . . . . . . . . . 174
7.3.62 Product Type: EquityVarianceSwap, CommodityVarianceSwap,
FxVarianceSwap . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
7.3.63 Product Type: FxAsianOptionArithmeticPrice . . . . . . . . . . . 176
7.3.64 Product Type: FxAsianOptionArithmeticStrike . . . . . . . . . . 178
7.3.65 Product Type: FxAsianOptionGeometricPrice . . . . . . . . . . . 180
7.3.66 Product Type: FxAsianOptionGeometricStrike . . . . . . . . . . 182
7.3.67 Product Type: FxDigitalOptionEuropeanCS . . . . . . . . . . . . 183
7.3.68 Product Type: FxDigitalBarrierOption . . . . . . . . . . . . . . . 184

6
 7.3.69 Product Type: FormulaBasedCoupon . . . . . . . . . . . . . . . . 185
7.3.70 Product Type: FxForward . . . . . . . . . . . . . . . . . . . . . . 185
7.3.71 Product Type: FxOption . . . . . . . . . . . . . . . . . . . . . . . 186
7.3.72 Product Type: FxOptionEuropeanCS . . . . . . . . . . . . . . . . 187
7.3.73 Product Type: FxOptionAmerican . . . . . . . . . . . . . . . . . 187
7.3.74 Product Type: FxDoubleTouchOption . . . . . . . . . . . . . . . 188
7.3.75 Product Type: MultiLegOption . . . . . . . . . . . . . . . . . . . 189
7.3.76 Product Type: Swap . . . . . . . . . . . . . . . . . . . . . . . . . 191
7.3.77 Product Type: CurrencySwap . . . . . . . . . . . . . . . . . . . . 192
7.3.78 Product Type: RiskParticipationAgreement_Vanilla . . . . . . . 193
7.3.79 Product Type: RiskParticipationAgreement_Vanilla_XCcy . . . 193
7.3.80 Product Type: RiskParticipationAgreement_Structured . . . . . 194
7.3.81 Product Type: RiskParticipationAgreement_TLock . . . . . . . . 195
7.3.82 Product Type: ScriptedTrade . . . . . . . . . . . . . . . . . . . . 197
7.3.83 Global Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7.4 Simulation: [Link] . . . . . . . . . . . . . . . . . . . . . . . . 198
7.4.1 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
7.4.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
7.4.3 Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
7.5 Sensitivity Analysis: [Link] . . . . . . . . . . . . . . . . . . . 214
7.6 Stress Scenario Analysis: [Link] . . . . . . . . . . . . . . . . 219
7.7 Calendar Adjustment: [Link] . . . . . . . . . . . . . 221
7.8 Curves: [Link] . . . . . . . . . . . . . . . . . . . . . . . . . . 223
7.8.1 Yield Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
7.8.2 Default Curves from CDS . . . . . . . . . . . . . . . . . . . . . . 237
7.8.3 Benchmark Default Curve . . . . . . . . . . . . . . . . . . . . . . 239
7.8.4 Multi-Section Default Curve . . . . . . . . . . . . . . . . . . . . . 241
7.8.5 Swaption Volatility Structures . . . . . . . . . . . . . . . . . . . . 242
7.8.6 Cap Floor Volatility Structures . . . . . . . . . . . . . . . . . . . 244
7.8.7 FX Volatility Structures . . . . . . . . . . . . . . . . . . . . . . . 260
7.8.8 Equity Curve Structures . . . . . . . . . . . . . . . . . . . . . . . 263
7.8.9 Equity Volatility Structures . . . . . . . . . . . . . . . . . . . . . 265
7.8.10 Inflation Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
7.8.11 Inflation Cap/Floor Volatility Surfaces . . . . . . . . . . . . . . . 271
7.8.12 CDS Volatilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
7.8.13 Base Correlations . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
7.8.14 FXSpots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
7.8.15 Securities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
7.8.16 Correlations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
7.8.17 Commodity Curves . . . . . . . . . . . . . . . . . . . . . . . . . . 279
7.8.18 Commodity Volatilities . . . . . . . . . . . . . . . . . . . . . . . . 285
7.8.19 Bootstrap Configuration . . . . . . . . . . . . . . . . . . . . . . . 295
7.8.20 One Dimensional Solver Configuration . . . . . . . . . . . . . . . 297
7.9 Reference Data [Link] . . . . . . . . . . . . . . . . . . . . 299
7.10 Ibor Fallback Config: [Link] . . . . . . . . . . . . . . 301
7.11 SIMM Calibration: [Link] . . . . . . . . . . . . . . . . . 302
7.11.1 SIMM Calibration . . . . . . . . . . . . . . . . . . . . . . . . . . 303
7.11.2 General Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

7
 7.11.3 Interest Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
7.11.4 Credit Qualifying . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
7.11.5 Credit Non-Qualifying . . . . . . . . . . . . . . . . . . . . . . . . 309
7.11.6 Equity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
7.11.7 Commodity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
7.11.8 FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
7.12 Conventions: [Link] . . . . . . . . . . . . . . . . . . . . . . . 314
7.12.1 Zero Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
7.12.2 Deposit Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 315
7.12.3 Future Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 316
7.12.4 FRA Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
7.12.5 OIS Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
7.12.6 Swap Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
7.12.7 Average OIS Conventions . . . . . . . . . . . . . . . . . . . . . . . 319
7.12.8 Tenor Basis Swap Conventions . . . . . . . . . . . . . . . . . . . . 320
7.12.9 Tenor Basis Two Swap Conventions . . . . . . . . . . . . . . . . . 321
7.12.10 FX Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
7.12.11 Cross Currency Basis Swap Conventions . . . . . . . . . . . . . . 323
7.12.12 Inflation Swap Conventions . . . . . . . . . . . . . . . . . . . . . 325
7.12.13 CMS Spread Option Conventions . . . . . . . . . . . . . . . . . . 327
7.12.14 Ibor Index Conventions . . . . . . . . . . . . . . . . . . . . . . . . 328
7.12.15 Overnight Index Conventions . . . . . . . . . . . . . . . . . . . . 329
7.12.16 Inflation Index Conventions . . . . . . . . . . . . . . . . . . . . . 330
7.12.17 Swap Index Conventions . . . . . . . . . . . . . . . . . . . . . . . 330
7.12.18 FX Option Conventions . . . . . . . . . . . . . . . . . . . . . . . 331
7.12.19 Commodity Forward Conventions . . . . . . . . . . . . . . . . . . 332
7.12.20 Commodity Future Conventions . . . . . . . . . . . . . . . . . . . 333
7.12.21 Credit Default Swap Conventions . . . . . . . . . . . . . . . . . . 338
7.12.22 Bond Yield Conventions . . . . . . . . . . . . . . . . . . . . . . . 340

8 Trade Data 343

8.1 Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
8.1.1 Netting Set Details . . . . . . . . . . . . . . . . . . . . . . . . . . 344
8.2 Trade Specific Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
8.2.1 Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
8.2.2 Zero Coupon Swap . . . . . . . . . . . . . . . . . . . . . . . . . . 347
8.2.3 Cap/Floor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
8.2.4 Forward Rate Agreement . . . . . . . . . . . . . . . . . . . . . . . 350
8.2.5 Swaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
8.2.6 Callable Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
8.2.7 FX Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
8.2.8 FX Average Forward . . . . . . . . . . . . . . . . . . . . . . . . . 359
8.2.9 FX Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
8.2.10 FX Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
8.2.11 FX Asian Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
8.2.12 FX Barrier Option . . . . . . . . . . . . . . . . . . . . . . . . . . 366
8.2.13 FX Digital Barrier Option . . . . . . . . . . . . . . . . . . . . . . 369
8.2.14 FX Digital Option . . . . . . . . . . . . . . . . . . . . . . . . . . 371
8.2.15 FX Double Barrier Option . . . . . . . . . . . . . . . . . . . . . . 373

8
8.2.16 FX Double Touch Option . . . . . . . . . . . . . . . . . . . . . . 375
8.2.17 FX European Barrier Option . . . . . . . . . . . . . . . . . . . . 377
8.2.18 FX KIKO Barrier Option . . . . . . . . . . . . . . . . . . . . . . 379
8.2.19 FX Touch Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
8.2.20 FX Variance and Volatility Swap . . . . . . . . . . . . . . . . . . 384
8.2.21 Equity Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
8.2.22 Equity Futures Option . . . . . . . . . . . . . . . . . . . . . . . . 388
8.2.23 Equity Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
8.2.24 Equity Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
8.2.25 Dividend Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
8.2.26 Equity Asian Option . . . . . . . . . . . . . . . . . . . . . . . . . 394
8.2.27 Equity Barrier Option . . . . . . . . . . . . . . . . . . . . . . . . 396
8.2.28 Equity Digital Option . . . . . . . . . . . . . . . . . . . . . . . . 398
8.2.29 Equity Double Barrier Option . . . . . . . . . . . . . . . . . . . . 399
8.2.30 Equity Double Touch Option . . . . . . . . . . . . . . . . . . . . 401
8.2.31 Equity European Barrier Option . . . . . . . . . . . . . . . . . . 403
8.2.32 Equity Touch Option . . . . . . . . . . . . . . . . . . . . . . . . . 404
8.2.33 Equity Variance Swap . . . . . . . . . . . . . . . . . . . . . . . . 406
8.2.34 Equity Cliquet Option . . . . . . . . . . . . . . . . . . . . . . . . 408
8.2.35 Equity Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
8.2.36 Equity Option Position . . . . . . . . . . . . . . . . . . . . . . . . 412
8.2.37 CPI Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
8.2.38 Year on Year Inflation Swap . . . . . . . . . . . . . . . . . . . . . 415
8.2.39 Bond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
8.2.40 Bond Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
8.2.41 Forward Bond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
8.2.42 Bond Forward / T-Lock / J-Lock (using ref. data) . . . . . . . . 423
8.2.43 Bond Repo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
8.2.44 Bond Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
8.2.45 Bond Option (using bond reference data) . . . . . . . . . . . . . . 429
8.2.46 Bond Total Return Swap . . . . . . . . . . . . . . . . . . . . . . . 431
8.2.47 Convertible Bond . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
8.2.48 Ascot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
8.2.49 Collateral Bond Obligation CBO . . . . . . . . . . . . . . . . . . 457
8.2.50 Composite Trade . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
8.2.51 Credit Default Swap / Quanto Credit Default Swap . . . . . . . . 461
8.2.52 Index Credit Default Swap . . . . . . . . . . . . . . . . . . . . . . 464
8.2.53 Index Credit Default Swap Option . . . . . . . . . . . . . . . . . 467
8.2.54 Synthetic CDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
8.2.55 Credit Linked Swap . . . . . . . . . . . . . . . . . . . . . . . . . . 473
8.2.56 Commodity Forward . . . . . . . . . . . . . . . . . . . . . . . . . 474
8.2.57 Commodity Swap and Basis Swap . . . . . . . . . . . . . . . . . . 477
8.2.58 Commodity Swaption . . . . . . . . . . . . . . . . . . . . . . . . . 477
8.2.59 Commodity Option . . . . . . . . . . . . . . . . . . . . . . . . . . 479
8.2.60 Commodity Digital Option . . . . . . . . . . . . . . . . . . . . . . 481
8.2.61 Commodity Spread Option . . . . . . . . . . . . . . . . . . . . . . 481
8.2.62 Commodity Average Price Option . . . . . . . . . . . . . . . . . . 483
8.2.63 Commodity Option Strip . . . . . . . . . . . . . . . . . . . . . . . 486

9
 8.2.64 Commodity Variance and Volatility Swap . . . . . . . . . . . . . . 488
8.2.65 Commodity Position . . . . . . . . . . . . . . . . . . . . . . . . . 488
8.2.66 Generic Total Return Swap / Contract for Difference (CFD) . . . 490
8.2.67 Equity Outperformance Option . . . . . . . . . . . . . . . . . . . 500
8.2.68 Double Digital Option . . . . . . . . . . . . . . . . . . . . . . . . 503
8.2.69 European Option Contingent on a Barrier . . . . . . . . . . . . . 505
8.2.70 Autocallable Type 01 . . . . . . . . . . . . . . . . . . . . . . . . . 507
8.2.71 Performance Option Type 01 . . . . . . . . . . . . . . . . . . . . 509
8.2.72 Window Barrier Option . . . . . . . . . . . . . . . . . . . . . . . 512
8.2.73 Generic Barrier Option . . . . . . . . . . . . . . . . . . . . . . . . 516
8.2.74 Best Entry Option . . . . . . . . . . . . . . . . . . . . . . . . . . 522
8.2.75 Basket Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
8.2.76 Worst Of Basket Swaps . . . . . . . . . . . . . . . . . . . . . . . . 539
8.2.77 Rainbow Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
8.2.78 Exotic Variance and Volatility Derivatives . . . . . . . . . . . . . 570
8.2.79 Accumulators and Decumulators . . . . . . . . . . . . . . . . . . . 603
8.2.80 Target Redemption Forward (TaRF) . . . . . . . . . . . . . . . . 618
8.2.81 Knock Out Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
8.2.82 Flexi Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
8.2.83 Balance Guaranteed Swap (BGS) . . . . . . . . . . . . . . . . . . 629
8.3 Trade Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
8.3.1 Option Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
8.3.2 Premiums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
8.3.3 Leg Data and Notionals . . . . . . . . . . . . . . . . . . . . . . . 640
8.3.4 Schedule Data (Rules, Dates and Derived) . . . . . . . . . . . . . 645
8.3.5 Fixed Leg Data and Rates . . . . . . . . . . . . . . . . . . . . . . 649
8.3.6 Floating Leg Data, Spreads, Gearings, Caps and Floors . . . . . . 650
8.3.7 Leg Data with Amortisation Structures . . . . . . . . . . . . . . . 657
8.3.8 Indexings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
8.3.9 Cashflow Leg Data . . . . . . . . . . . . . . . . . . . . . . . . . . 662
8.3.10 CMS Leg Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
8.3.11 Constant Maturity Bond Leg Data . . . . . . . . . . . . . . . . . 665
8.3.12 Digital CMS Leg Data . . . . . . . . . . . . . . . . . . . . . . . . 667
8.3.13 Duration Adjusted CMS Leg Data . . . . . . . . . . . . . . . . . 668
8.3.14 CMS Spread Leg Data . . . . . . . . . . . . . . . . . . . . . . . . 670
8.3.15 Digital CMS Spread Leg Data . . . . . . . . . . . . . . . . . . . . 671
8.3.16 Equity Leg Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
8.3.17 CPI Leg Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
8.3.18 YY Leg Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
8.3.19 ZeroCouponFixed Leg Data . . . . . . . . . . . . . . . . . . . . . 683
8.3.20 Commodity Fixed Leg . . . . . . . . . . . . . . . . . . . . . . . . 685
8.3.21 Commodity Fixed Leg Data . . . . . . . . . . . . . . . . . . . . . 685
8.3.22 Commodity Floating Leg . . . . . . . . . . . . . . . . . . . . . . . 686
8.3.23 Commodity Schedules . . . . . . . . . . . . . . . . . . . . . . . . 686
8.3.24 Commodity Floating Leg Data . . . . . . . . . . . . . . . . . . . 688
8.3.25 Equity Margin Leg . . . . . . . . . . . . . . . . . . . . . . . . . . 694
8.3.26 Equity Margin Leg Data . . . . . . . . . . . . . . . . . . . . . . . 694
8.3.27 CDS Reference Information . . . . . . . . . . . . . . . . . . . . . 695

10
 8.3.28 Basket Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
8.3.29 Underlying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
8.3.30 StrikeData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
8.3.31 Barrier Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
8.3.32 RangeBound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
8.3.33 Bond Basket Data for Cashflow CDO . . . . . . . . . . . . . . . . 706
8.3.34 CBO Tranches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
8.3.35 Formula Based Leg Data . . . . . . . . . . . . . . . . . . . . . . . 708
8.4 Allowable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

9 Netting Set Definitions 746

9.1 Uncollateralised Netting Set . . . . . . . . . . . . . . . . . . . . . . . . . 746
9.2 Collateralised Netting Set . . . . . . . . . . . . . . . . . . . . . . . . . . 746

10 Market Data 750

10.1 Zero Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
10.2 Discount Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
10.3 FX Spot Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
10.4 FX Forward Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
10.5 Deposit Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
10.6 FRA Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
10.7 Money Market Futures Price . . . . . . . . . . . . . . . . . . . . . . . . . 756
10.8 Overnight Index Futures Price . . . . . . . . . . . . . . . . . . . . . . . . 757
10.9 Swap Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
10.10Basis Swap Spread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
10.11Cross Currency Basis Swap Spread . . . . . . . . . . . . . . . . . . . . . 759
10.12CDS Spread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
10.13CDS Upfront Price . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
10.14CDS Recovery Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
10.15CDS Option Implied Volatility . . . . . . . . . . . . . . . . . . . . . . . . 761
10.16Security Recovery Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
10.17Hazard Rate (Instantaneous Probability of Default) . . . . . . . . . . . . 762
10.18FX Option Implied Volatility . . . . . . . . . . . . . . . . . . . . . . . . 763
10.19Cap Floor Implied Volatility . . . . . . . . . . . . . . . . . . . . . . . . . 764
10.20Swaption Implied Volatility . . . . . . . . . . . . . . . . . . . . . . . . . 765
10.21Equity Spot Price . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
10.22Equity Forward Price . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
10.23Equity Dividend Yield . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
10.24Equity Option Implied Volatility . . . . . . . . . . . . . . . . . . . . . . 767
10.25Equity Option Premium . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
10.26Commodity Spot Price . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
10.27Commodity Forward Price . . . . . . . . . . . . . . . . . . . . . . . . . . 769
10.28Commodity Option Implied Volatility . . . . . . . . . . . . . . . . . . . . 769
10.29Zero Coupon Inflation Swap Rate . . . . . . . . . . . . . . . . . . . . . . 771
10.30Year on Year Inflation Swap Rate . . . . . . . . . . . . . . . . . . . . . . 772
10.31Zero Coupon Inflation Cap Floor Price . . . . . . . . . . . . . . . . . . . 772
10.32Inflation Seasonality Correction Factors . . . . . . . . . . . . . . . . . . . 773
10.33Bond Yield Spreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
10.34Bond Prices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773

11
 10.35Base Correlations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
10.36Correlations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
10.37Conditional Prepayment Rates . . . . . . . . . . . . . . . . . . . . . . . . 775

11 Fixing History 776

12 Dividends History 779

A Methodology Summary 781

A.1 Risk Factor Evolution Model . . . . . . . . . . . . . . . . . . . . . . . . . 781
A.2 Analytical Moments of the Risk Factor Evolution Model . . . . . . . . . 784
A.3 Change of Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
A.4 Exposures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
A.5 Exposures using American Monte Carlo . . . . . . . . . . . . . . . . . . . 793
A.5.1 *Implementation Details . . . . . . . . . . . . . . . . . . . . . . . 794
A.6 CVA and DVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
A.7 FVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
A.8 COLVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
A.9 Collateral Floor Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
A.10 Dynamic Initial Margin and MVA . . . . . . . . . . . . . . . . . . . . . . 801
A.11 KVA (CCR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
A.12 KVA (BA-CVA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
A.13 Collateral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
A.14 Exposure Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
A.15 Sensitivity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
A.16 Par Sensitivity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
A.17 Economic P&L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
A.18 Risk Hypothetical P&L . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
A.19 Value at Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820

12
1 Introduction
The Open Source Risk Project [1] aims at providing a transparent platform for pricing
and risk analysis that serves as
• a benchmarking, validation, training, and teaching reference,
• an extensible foundation for tailored risk solutions.
Its main software project is Open Source Risk Engine (ORE), an application that
provides
• a Monte Carlo simulation framework for contemporary risk analytics and value
adjustments
• simple interfaces for trade data, market data and system configuration
• simple launchers and result visualisation in Jupyter, Excel, LibreOffice
• unit tests and various examples.
ORE is open source software, provided under the Modified BSD License. It is based on
QuantLib, the open source library for quantitative finance [2].

Audience
The project aims at reaching quantitative risk management practitioners (be it in
financial institutions, audit firms, consulting companies or regulatory bodies) who are
looking for accessible software solutions, and quant developers in charge of the
implementation of pricing and risk methods similar to those in ORE. Moreover, the
project aims at reaching academics and students who would like to teach or learn
quantitative risk management using a freely available, contemporary risk application.
And in the meantime, as ORE is used in risk services at industrial scale since 2018
with over 150 users, ORE is aimed at firms that consider the replacement of third
party licensed software.

Contributions
Quaternion Risk Management [3] has been committed to sponsoring the Open Source
Risk project through ongoing project administration, through providing an initial
release and a series of subsequent releases in order to achieve a wide analytics, product
and risk factor class coverage. Since Quaternion’s acquisition by Acadia Inc. in
February 2021, Acadia [4] has been committed to continue the sponsorship. The Open
Source Risk project work continues with former Quaternion operating as Acadia’s
Quantitative Services unit. And with Acadia’s acquisiton by London Stock Exchange
Group (LSEG) in 2023, the journey continues under the roof of LSEG Post Trade.
The community is invited to contribute to ORE, for example through feedback,
discussions and suggested enhancement in the forum on the ORE site [1], as well as
contributions of ORE enhancements in the form of source code. See the FAQ section
on the ORE site [1] on how to get involved.

13
1.1 Scope
ORE currently provides portfolio pricing, cash flow generation, market risk analysis
and a range of contemporary derivative portfolio analytics. The latter are based on a
Monte Carlo simulation framework which yields the evolution of various exposure
measures:
• EE aka EPE (Expected Exposure or Expected Positive Exposure)
• ENE (Expected Negative Exposure, i.e. the counterparty’s perspective)
• ’Basel’ exposure measures relevant for regulatory capital charges under internal
model methods
• PFE (Potential Future Exposure at some user defined quantile)
and derivative value adjustments (xVA)
• CVA (Credit Value Adjustment)
• DVA (Debit Value Adjustment)
• FVA (Funding Value Adjustment)
• COLVA (Collateral Value Adjustment)
• MVA (Margin Value Adjustment)
for portfolios with netting, variation and initial margin agreements.

The market risk framework provides

• sensitivity analysis, also in the “par” domain
• stress testing, also in the “par” domain
• several parametric VaR versions (Delta VaR, Delta-Gamma Normal VaR,
Delta-Gamma VaR with Cornish-Fisher expansion and Saddlepoint method)
• historical simulation VaR
• P&L and P&L explain
across all asset classes and products.

Thanks to Acadia’s open-source strategy, ORE’s financial instrument scope was

extended beyond the initial vanilla scope with quarterly releases since version 7 to cover
• "First Generation" Equity and FX Exotics, released September with ORE v7
• Commodity products (Swaps, Basis Swaps, Average Price Options, Swaptions),
released December 22 with ORE v8
• Credit products (Index CDS and Index CDS Options, Credit-Linked Swaps,
Synthetic CDOs), released March 23 with ORE v9
• Bond products and Hybrids (Bond Options, Bond Repos, Bond TRS, Composite
Trades, Convertible Bonds, Generic TRS with mixed basket underlyings, CFDs),
released in June 23 with ORE v10

14
 • a Scripted Trade framework in October 23 with ORE v11: This allows the
modelling of complex hybrid payoffs such as Accumulators, TARFs, PRDCs,
Basket Options, etc, across IR, FX, INF, EQ, COM classes. Scripted Trades are
fully integrated into the market risk and exposure simulation frameworks,
supported by American Monte Carlo methods for pricing and exposure
simulation. The user can now extend the instrument scope conveniently by
adding payoff scripts (embedded into the trade XML or in separate script
"library" XML) and without recompiling the code base.
• Formula-based legs, Callable Swaps, Flexi Swaps, Balance Guaranteed Swaps
and American Swaptions in May 24 with ORE v12
These contributions were accompanied by analytics extensions to enhance ORE
usability
• Exposure simulation for xVA and PFE, adding Commodity to the asset class
coverage, and adding American Monte Carlo for Exotics, released in December
22 with ORE v8
• Market Risk including multi-threaded sensitivity analysis, par sensitivity
conversion, parametric delta/gamma VaR with Cornish-Fisher expansion and
Saddlepoint method, released in March 23 with ORE v9
• Portfolio Credit Model, released in June 23 with ORE v10
• ISDA’s Standard Initial Margin Model (SIMM), released in June 23 with ORE
v10
• Historical Simulation VaR, P&L and P&L Explain, released in May 24 with ORE
v12

The product coverage of the latest release of ORE is sketched in Table 1.

The simulation models applied in ORE’s risk factor evolution implement the models
discussed in detail in Modern Derivatives Pricing and Credit Exposure Analysis [21]:
The IR/FX/INF/EQ risk factor evolution is based on a cross currency model
consisting of an arbitrage free combination of Linear Gauss Markov models for all
interest rates and lognormal processes for FX rates and EQ prices, Dodgson-Kainth (or
Jarrow-Yildirim) models for inflation. The model components are calibrated to cross
currency discounting and forward curves, Swaptions, FX Options, EQ Options and
CPI caps/floors. With the 8th release, Commodity simulation has been added, as well
as the foundation for a multi-factor Hull-White based IR/FX/COM simulation model.

1.2 ORE in Python or Java

ORE is written in C++ and comes with a command line executable [Link] that
supports batch processes. But since early versions of ORE we also provide language
bindings following QuantLib’s example using SWIG, in ORE’s case with focus on
Python and Java modules. The ORE SWIG module extends (contains) the QuantLib
SWIG module and offers moreover access to a part of ORE’s functionality. Since ORE
v9, Python wheels are provided for each release, so that users can install the most
recent ORE Python module by calling

15
 Product Pricing and Sensitivity Stress Exposure
Cashflows Analysis Testing Simulation
& XVA
Fixed and Floating Rate Bonds/Loans Y Y Y N
Interest Rate Swaps Y Y Y Y
Caps/Floors Y Y Y Y
Swaptions, Callable Swaps Y Y Y Y
Constant Maturity Swaps, CMS Caps/Floors Y Y Y Y
FX Forwards and Average Forwards Y Y Y Y
Cross Currency Swaps Y Y Y Y
FX European and Asian Options Y Y Y Y
FX Exotic Options (see below) Y Y Y Y
Equity Forwards Y Y Y Y
Equity Swaps Y Y Y N
Equity European and Asian Options Y Y Y Y
Equity Exotic Options (see below) Y Y Y Y
Equity Future Options Y Y Y Y
Commodity Forwards and Swaps Y Y Y Y
Commodity European and Asian Options Y Y Y Y
Commodity Digital Options Y Y Y Y
Commodity Swaptions Y Y Y Y
CPI Swaps Y Y N Y
CPI Caps/Floors Y Y N N
Year-on-Year Inflation Swaps Y Y N Y
Year-on-Year Inflation Caps/Floors Y Y N N
Credit Default Swaps, Options Y Y N Y
Index Credit Default Swaps, Options Y Y N Y
Credit Linked Swaps Y Y N Y
Index Tranches, Synthetic CDOs Y Y N Y
Composite Trades Y Y Y Y
Total Return Swaps and Contracts for Difference Y Y Y Y
Convertible Bonds Y Y Y N
ASCOTs Y Y Y Y
Scripted Trades Y Y Y Y
Flexi Swaps and Balance Guaranteed Swaps Y Y Y Y

Table 1: ORE product coverage. FX/Equity Exotics include Barrier, Digital, Digital Barrier
(FX only), Double Barrier, European Barrier, KIKO Barrier (FX only), Touch and Double
Touch Options, Outperformance options and Pairwise Variance Swaps. Scripted Trades cover
single and multi-asset products across all asset classes except Credit (so far), see Example_52
and the separate documentation in Docs/ScriptedTrade.

pip install open-source-risk-engine

See section 5.42 on how to use ORE-Python.

1.3 Roadmap
It is planned that subsequent ORE releases will also provide the calculation of
regulatory capital charges
• for Counterparty Credit Risk under the standardised approach (SA-CCR)
• for Market Risk (SMRC, FRTB-SA)
• for CVA Risk (BA-CVA, SA-CVA)
Performance: ORE v12 contains applications of AAD for sensitivity analysis, CVA
sensitivity (proof-of concept stage), as well as applications of GPUs to parallelize
computations (see Examples 56 and 61), with significant speed-ups. Both areas are
active work in progress, and further enhancements and tests should be released with
the next versions.

16
ORE Python: Moreover, there is demand among ORE users for extended coverage of
the ORE-Python version, so that we also expect steady growth of the Python wrapper
around ORE.
ORE Service: ORE v12 contains an implementation of a restful API around ORE,
see folder ore/Api and the example therein. This is written in Python, uses the
ORE-Python module and the Flask web framework. This implementation is proof of
concept, for demonstration purposes and to encourage the community to extend and
contribute alternatives.

1.4 Further Resources

• Open Source Risk Project site: [Link]
• Frequently Asked Questions: [Link]
• Forum: [Link]
• Source code and releases: [Link]
• Language bindings: [Link]
• Follow ORE on Twitter @OpenSourceRisk for updates on releases and events

Organisation of this document

This document focuses on instructions how to use ORE to cover basic workflows from
individual deal analysis to portfolio processing. After an overview over the core ORE
data flow in section 3 and installation instructions in section 4 we start in section 5
with a series of examples that illustrate how to launch ORE using its command line
application, and we discuss typical results and reports. We then illustrate in section 6
interactive analysis of resulting ’NPV cube’ data. The final sections of this text
document ORE parametrisation and the structure of trade and market data input.

2 Release Notes
See the full history of release notes in [Link] in the top level directory of the ORE’s
github repository.

This section summarises the notable changes between release 11 (October 2023) and 12
(May 2024).

INSTRUMENTS & PRICING

• add formula-based leg (ticket 12263), see Example 64
• add Callable Swap (ticket 12370), Example, see extended Example 5
• add Flexi Swap (ticket 12370), see Example 65
• add Balance Guaranteed Swap (ticket 12370), see Example 66
• add American Swaption with finite difference pricing in LGM (ticket 11618), see
extended Example 4

17
 • add Equity Outperformance Option (ticket 12456)
• add Pairwise Variance Swap (ticket 12456)
• add analytic pricer for Overnight Index Swaptions (ticket 11974)
• add finite difference LGM pricers for Bermudan and European Swaptions
• add numerical integration LGM pricer for European Swaptions
• support indexed cashflows in AMC (ticket 12206)
• scripted trades: support LGM1F using finite difference and numerical integration
(ticket 12306)
• scripted trades: support generating past cashflows (ticket 12417)
• scripted trades: handle near-collinear predictor variables in linear regression for
AMC (ticket 12419)
• support for rules-based Bermudan exercise dates (ticket 11947)
• improved AMC regression model for resetting XCCY Swaps (ticket 12119)
• add Burley 2020 scrambled Sobol sequence (ticket 12140), used in Example 56
• rates curve building: support mixed interpolations (ticket 12159), used in
Example 53
• add priorities to yield curve segments (ticket 9557)
• configurable settlement date flows handling (ticket 12372)
• introduce notional payment lag for resetting Cross Currency Swaps (ticket 12379)
• support security spreads over discount in Single Currency Swaps, Swaptions and
Scripted Trades (ticket 12201 and 12275)
• add pricing engines that provide analytical deltas and gammas for Swaps,
Swaptions, FX Forwards, FX Options (ticket 12456)

MARKETS & TERMSTRUCTURES

• SABR pricing for Swaptions and Caps/Floors (ticket 12325), see Example 59
• allow importing external SABR parameters (ticket 12491)

ANALYTICS
• add XVA Sensitivitiy Proof of Concept using AAD (ticket 12028), see Example 56
• support overlapping close-out date grid in exposure/XVA (ticket 9859), see
Example 60
• add scenario analytic (ticket 11990), see Example 57
• add historical simulation VaR analytic (ticket 9793), see Example 58
• add IM Schedule analytic (ticket 11730), see extended Example 44
• add P&L and P&L Explain analytics (ticket 12458), see Example 62

18
 • add par stress test support (ticket 12148), see Example 63
• add XVA stress testing (ticket 12376), see Example 67
• add XVA bump & revalue sensitivities (ticket 12437), see Example 68
• add bond spread imply to ORE (ticket 12370)
• add market risk backtest analytic (ticket 12370)
• add calculation of stoplight bounds for backtests (ticket 12370)
• feed t0 Variation Margin into xVA calculation (ticket 12241)
• support flat Initial Margin projection in exposure calculations (ticket 12318)
• fix the Independent Amount implementation in exposure calculations (ticket
12277)
• introduce configurable shift size and difference scheme per product for sensitivity
analysis (ticket 12014)
• improve performance of SIMM calculations for large CRIF files (ticket 12397)
• output effective SOFR / RFR cap volatilities in reports (ticket 12192)

TESTS
• add a test suite for ORE-SWIG (ticket 11823)
• add AD unit tests (ticket 12188)
• add delta/gamma engine tests (ticket 12370)
• add pairwise variance swap tests (ticket 12370)
• add equity outperformance option tests (ticket 12370)
• QuantExt: 298 test functions (vs 272 in the previous release)
• OREData: 264 test functions (vs. 257 in the previous release)
• OREAnalytics: 79 test functions (vs. 78 in the previous release)

DOCUMENTATION
• add documentation of pricing engine configuration (ticket 12337)
• add documentation for added instruments (ticket 12317)
• add supported compiler and boost versions (ticket 11431) TODO update user
guide
• clean up ORE cmake build flags (ticket 12048) TODO and update user guide
• update the ORE Design document (ticket 12375)
• the user guide has grown significantly to about 820 pages, due to the migration
of more instruments into ORE, additional examples, and especially the added
documentation of pricing engine configurations.

19
LANGUAGE BINDINGS & PYTHON MODULE
• add NPV Cube and joint cube to the swig interface (ticket 12421)
• refactor OREApp to allow repeated run() calls (ticket 12317)
• add Python wheels workflow on github (ticket 12436)
ORE SERVICE
• add a restful API to ORE, based on ORE-Python, see Example 0
(Examples/API)

GPU
• The external device interface based on the scripted trade and in particular its
computation graph implementation is progressing. This release has several
notable changes
– an option to use double precision in opencl (ticket 12386)
– a mersenne twister random number generator implementation for opencl
(ticket 12387)
– a working example that parallelizes bump & reval sensitivity analysis on a
GPU, see Example 61
– smoke test are passing on several external devices
• Next steps
– implementation of the conditional expectation operator on the GPU
– implementation of several coupon types to cover IR/FX products more
broadly
– implementation of a computation graph version of the post processor

NEW & EXTENDED EXAMPLES

• 0: ORE Web Service
• 4: American Swaption added
• 5: Callable Swap instrument added
• 44: IM Schedule added
• 54: Scripted Trade exposure with AMC: Bermudan Swaption and LPI Swap
• 55: Scripted Trade exposure with AMC: TaRF
• 56: Proof of Concept: CVA Sensitivities using AAD
• 57: Base Scenario Analytic
• 58: Historical Simulation VaR
• 59: SABR model for Swaptions and Caps/Floors
• 60: Exposure and XVA with Overlapping Close-Out Grid

20
 • 61: Fast Sensitivities using AAD and GPUs
• 62: P&L and P&L Explain Analytic
• 63: Stresstest with shifts in the par-rate domain
• 64: Formual-based Coupon
• 65: Flexi Swap
• 66: Balance Guaranteed Swap
• 67: XVA Stress Testing
• 68: XVA Bump & Revalue Sensitivities

3 ORE Data Flow

The core processing steps followed in ORE to produce risk analytics results are
sketched in Figure 1. All ORE calculations and outputs are generated in three
fundamental process steps as indicated in the three boxes in the upper part of the
figure. In each of these steps appropriate data (described below) is loaded and results
are generated, either in the form of a human readable report, or in an intermediate
step as pure data files (e.g. NPV data, exposure data).

Portfolio Loading t0 Pricing Aggregation

“Curve” Building Market Simulation Collateral Modeling
Model Calibration Forward Pricing Exposure Analytics

Trade data (xml) NPV Report Exposure Reports

Cashflow Report XVA Reports
Market data
NPV Cube Net NPV Cube
Configuration (xml)

Processing
Input Interactive Visualisation:
Output Evolution of Exposure and NPV distributions

Figure 1: Sketch of the ORE process, inputs and outputs.

The overall ORE process needs to be parametrised using a set of configuration XML
files which is the subject of section 7. The portfolio is provided in XML format which
is explained in detail in sections 8 and 9. Note that ORE comes with ’Schema’ files for
all supported products so that any portfolio xml file can be validated before running
through ORE. Market data is provided in a simple three-column text file with unique
human-readable labelling of market data points, as explained in section 10.
The first processing step (upper left box) then comprises
• loading the portfolio to be analysed,

21
 • building any yield curves or other ’term structures’ needed for pricing,
• calibration of pricing and simulation models.
The second processing step (upper middle box) is then
• portfolio valuation, cash flow generation,
• going forward - conventional risk analysis such as sensitivity analysis and stress
testing, standard-rule capital calculations such as SA-CCR, etc,
• and in particular, more time-consuming, the market simulation and portfolio
valuation through time under Monte Carlo scenarios.
This process step produces several reports (NPV, cashflows etc) and in particular an
NPV cube, i.e. NPVs per trade, scenario and future evaluation date. The cube is
written to a file in both condensed binary and human-readable text format.
The third processing step (upper right box) performs more ’sophisticated’ risk analysis
by post-processing the NPV cube data:
• aggregating over trades per netting set,
• applying collateral rules to compute simulated variation margin as well as
simulated (dynamic) initial margin posting,
• computing various XVAs including CVA, DVA, FVA, MVA for all netting sets,
with and without taking collateral (variation and initial margin) into account, on
demand with allocation to the trade level.
The outputs of this process step are XVA reports and the ’net’ NPV cube, i.e. after
aggregation, netting and collateral.
The example section 5 demonstrates for representative product types how the
described processing steps can be combined in a simple batch process which produces
the mentioned reports, output files and exposure evolution graphs in one ’go’.
Moreover, both NPV cubes can be further analysed interactively using a visualisation
tool introduced in section 6.1. And finally, sections 6.2 and 6.3 demonstrate how ORE
processes can be launched in spreadsheets and key results presented automatically
within the same sheet.

4 Getting and Building ORE

You can get ORE in two ways, either by downloading a release bundle as described in
section 4.1 (easiest if you just want to use ORE) or by checking out the source code
from the github repository as described in section 4.2 (easiest if you want to build and
develop ORE).

4.1 ORE Releases

ORE releases are regularly provided in the form of source code archives, Windows
executables [Link], example cases and documentation. Release archives will be
provided at [Link]

22
The release contains the QuantLib source version that ORE depends on. This is the
latest QuantLib release that precedes the ORE release including a small number of
patches.

The release consists of a single archive in zip format

• ORE-<VERSION>.zip
When unpacked, it creates a directory ORE-<VERSION> with the following files
respectively subdirectories
1. App/
2. Docs/
3. Examples/
4. FrontEnd/
5. OREAnalytics/
6. OREData/
7. ORETest/
8. QuantExt/
9. QuantLib/
10. ThirdPartyLibs/
11. tools/
12. xsd/
13. [Link]
The first three items and [Link] are sufficient to run the compiled ORE
application on the list of examples described in the user guide (this works on Windows
only). The Windows executables are located in App/bin/Win32/Release/ respectively
App/bin/x64/Release/. To continue with the compiled executables:
• Ensure that the scripting language Python is installed on your computer, see also
section 4.3 below;
• Move on to the examples in section 5.

The release bundle contains the ORE source code, which is sufficient to build ORE
from sources as follows (if you build ORE for development purposes, we recommend
using git though, see section 4.2):
• Set up Boost as described in section 4.2.2, unless already installed
• Build QuantLib, QuantExt, OREData, OREAnalytics, App (in this order) as
described in section 4.2.3
• Note that ThirdPartyLibs does not need to be built, it contains RapidXml,
header only code for reading and writing XML files
• Move on to section 4.3 and the examples in section 5.

23
Open Docs/html/[Link] to see the API documentation for QuantExt, OREData
and OREAnalytics, generated by doxygen.

4.2 Building ORE

ORE’s source code is hosted at [Link]

4.2.1 Git
To access the current code base on GitHub, one needs to get git installed first.
1. Install and setup Git on your machine following instructions at [6]
2. Fetch ORE from github by running the following:
% git clone [Link] ore
This will create a folder ’ore’ in your current directory that contains the codebase.
3. Initially, the QuantLib subdirectory under ore is empty as it is a submodule
pointing to the official QuantLib repository. To pull down locally, use the
following commands:
% cd ore
% git submodule init
% git submodule update
Note that one can also run
% git clone –recurse-submodules [Link] ore

in step 2, which also performs the steps in 3.

4.2.2 Boost
QuantLib and ORE depend on the boost C++ libraries. Hence these need to be
installed before building QuantLib and ORE. On all platforms the minimum required
boost version is 1_78.

Windows
1. Download the pre-compiled binaries for your MSVC version (e.g. MSVC-14.3 for
MSVC2022) from [7]
• 32-bit: [7]\VERSION\boost_VERSION-[Link]\download
• 64-bit: [7]\VERSION\boost_VERSION-[Link]\download
2. Start the installation file and choose an installation folder (the “boost root
directory”). Take a note of that folder as it will be needed later on.
3. Finish the installation by clicking Next a couple of times.
Alternatively, compile all Boost libraries directly from the source code:
1. Open a Visual Studio Tools Command Prompt
• 32-bit: VS2022 x86 Native Tools Command Prompt

24
 • 64-bit: VS2022 x64 Native Tools Command Prompt
2. Navigate to the boost root directory
3. Run [Link]
4. Build the libraries from the source code
• 32-bit:
.\b2 –stagedir=.\lib\Win32\lib –build-type=complete toolset=msvc-14.3 \
address-model=32 –with-test –with-system –with-filesystem \
–with-serialization –with-regex –with-date_time stage

• 64-bit:
.\b2 –stagedir=.\lib\x64\lib –build-type=complete toolset=msvc-14.3 \
address-model=64 –with-test –with-system –with-filesystem \
–with-serialization –with-regex –with-date_time stage

Unix
1. Download Boost from [8] and build following the instructions on the site
2. Define the environment variable BOOST that points to the boost directory (so
includes should be in BOOST and libs should be in BOOST/stage/lib)

4.2.3 ORE Libraries and Application

Windows
1. Download and install Visual Studio Community Edition (Version 2019 or later,
2022 is recommended). During the installation, make sure you install the Visual
C++ support under the Programming Languages features (disabled by default).
2. Configure boost paths:
Set environment variables, e.g.:
• %BOOST% pointing to your directory, e.g, C:\boost_1_72_0
• %BOOST_LIB32% pointing to your Win32 lib directory, e.g,
C:\boost_1_72_0\lib32msvc14.3
• %BOOST_LIB64% pointing to your x64 lib directory, e.g,
C:\boost_1_72_0\lib64msvc14.3
3. Download and install CMake for Windows ([Link]
Visual Studio Community Edition 2019 or later supports CMake and you can
install the feature ’C++ CMake Tools for Windows’ instead of installing CMake
as standalone program.
Visual Studio 2019 and later supports CMake Projects.
1. Start Visual Studio 2019 or later.
2. Select "Open a local folder" from the start page or menu.
3. In the dialog window, select the ORE root directory.

25
 4. Visual Studio will read the cmake presets from [Link] and the
project file [Link] and configure the project.
5. Once the configuration is finished and one can build the project.
6. The executables are built in the subfolder
/build/TARGET/CONFIGURATION/EXECUTABLE, e.g.
/build/App/Release/[Link].
ORE is shipped with configuration and build presets using Visual Studio 2022 and the
Ninja build system. Those presets are configured in the [Link] which is
read by Visual Studio by default when opening the CMake project. If you want to use
Visual Studio 2019 instead, you would have to change the Generator in the
[Link] from "Visual Studio 17 2022" to "Visual Studio 16 2019".
You can switch in the solution explorer from the file view to the projects view, where
the CMake Targets View can be selected. In this view, the various target projects can
be seen below "ORE Project" and be used in a similar manner as the usual VS
projects.

Alternatively, Visual Studio project files can be auto-generated from the CMake
project files or ORE can be built with the CMake command line tool, similar to UNIX
/ Mac systems.
1. Generate MSVC project files from CMake files:
• Open a Visual Studio Tools Command Prompt
– 32-bit: VS2022/x86 Native Tools Command Prompt for VS 2022
– 64-bit: VS2022/x64 Native Tools Command Prompt for VS 2022
• Navigate to the ORE root directory
• Run CMake command:
– 64-bit:
cmake -G "Visual Studio 17 2022" -A x64
-DBOOST_INCLUDEDIR=%BOOST% -DBOOST_LIBRARYDIR=%BOOST_LIB64%
-DQL_ENABLE_SESSIONS=ON -DMSVC_LINK_DYNAMIC_RUNTIME=true -B
build
– 32-bit:
cmake -G "Visual Studio 17 2022" -A x32
-DBOOST_INCLUDEDIR=%BOOST% -DBOOST_LIBRARYDIR=%BOOST_LIB32%
-DQL_ENABLE_SESSIONS=ON -DMSVC_LINK_DYNAMIC_RUNTIME=true -B
build
Replace the generator "Visual Studio 17 2022" with the actual installed
version. The solution and project files will be generated in the
⟨ORE_ROOT⟩\build subdirectory.
2. build the cmake project with the command cmake –build build -v –config
Release,

26
 3. or open the MSVC solution file build\[Link] and build the entire solution
with Visual Studio (again, make sure to select the correct platform in the
configuration manager first).

Optional: Install optional dependencies with VCPKG

VCPKG is an open source c++ library manager. ORE can be built optionally with
ZLIB and Eigen library support.
For both features the libraries needed to be installed on the system. On Windows one
can use the VCPKG package manager to install those dependencies:
• Install vcpkg: [Link]
• Install dependencies with invoking the command
vcpkg install –triplet x64-windows zlib
vcpkg install –triplet x64-windows eigen3
To make VCPKG visible to CMAKE, create an environment variable VCPKG_ROOT
pointing to the root of the vcpkg directory and configure ORE with the flag
-DCMAKE_TOOLCHAIN_FILE=%VCPKG_ROOT%/scripts/buildsystems/[Link].
To use VCPKG with Visual Studio add the toolChainFile to the configurePresets in
the [Link]:
"toolchainFile": "$env{VCPKG_ROOT}/scripts/buildsystems/[Link]",

Unix
With the 5th release we have discontinued automake support so that ORE can only be
built with CMake on Unix systems, as follows.
1. set environment variable to locate the boost include and boost library directories
export BOOST_LIB=path/to/boost/lib
export BOOST_INC=path/to/boost/include

2. Change to the ORE project directory that contains the QuantLib, QuantExt, etc,
folders; create subdirectory build and change to subdirectory build
3. Configure CMake by invoking
cmake -DBOOST_ROOT=$BOOST_INC -DBOOST_LIBRARYDIR=$BOOST_LIB
-DQL_ENABLE_SESSIONS=ON ..
where the QL_ENABLE_SESSIONS variable is set to ON in order to enable some
multi-threading applications in ORE.
Alternatively, set environment variables BOOST_ROOT and BOOST_LIBRARYDIR
directly and run
cmake ..
4. Build all ORE libraries, QuantLib, as well as the doxygen API documentation for
QuantExt, OREData and OREAnalytics, by invoking
make -j4

27
 using four threads in this example.

5. Run all test suites by invoking

ctest -j4
6. Run Examples (see section 5)
Note:
• If the boost libraries are not installed in a standard path they might not be
found during runtime because of a missing rpath tag in their path. Run the
script rename_libs.sh to set the rpath tag in all libraries located in
$BOOST/stage/lib.
• Unset LD_LIBRARY_PATH respectively DYLD_LIBRARY_PATH before running the
ORE executable or the test suites, in order not to override the rpath information
embedded into the libaries built with CMake
• On Linux systems, the ’locale’ settings can negatively affect the ORE process
and output. To avoid this, we recommend setting the environment variable
LC_NUMERIC to C, e.g. in a bash shell, do
% export LC_NUMERIC=C

before running ORE or any of the examples below. This will suppress thousand
separators in numbers when converted to strings.
• Generate [Link]:
The .cpp and .hpp files included in the build process need to be explicitly
specified in the various [Link] files in the project directory. The
python script (in Tools/update_cmake_files.py) can be used to update all
[Link] files automatically.

4.2.4 Supported Compiler and Boost Versions

The following table 2 reflects the compiler / boost version combinations that the
users/developers at Acadia/LSEG can confirm as working combinations with the latest
ORE v12.

Compiler Boost ORE

AppleClang version 13.0.0 1.82.0 12
AppleClang version 13.1.6 1.84.0 12
AppleClang version 14.0.0 1.82.0 12
AppleClang version 15.0.0 1.83.0 12
gcc 10.2.1 1.74.0 12
gcc 11.4.0 1.74.0 12
VS2019 1.72.0 12
VS2022 1.78.0 12
VS2022 1.83.0 12

Table 2: Supported compiler and boost versions for ORE v12.

28
ZLIB support
To enable zlib support configure CMake with the flag -DORE_USE_ZLIB=ON.
If zlib is not installed on the system, it can be installed on Windows with the package
manager VCPKG.

4.3 Python and Jupyter

Python (version 3.5 or higher) is required to use the ORE Python language bindings in
section 4.4, or to run the examples in section 5 and plot exposure evolutions.
Moreover, we use Jupyter [9] in section 6 to visualise simulation results. Both are part
of the ’Anaconda Open Data Science Analytics Platform’ [10]. Anaconda installation
instructions for Windows, OS X and Linux are available on the Anaconda site, with
graphical installers for Windows1 , Linux and OS X.
With Linux and OS X, the following environment variable settings are required
• set LANG and LC_ALL to en_US.UTF-8 or en_GB.UTF-8
• set LC_NUMERIC to C.
The former is required for both running the Python scripts in the examples section, as
well as successful installation of the following packages.
The full functionality of the Jupyter notebook introduced in section 6.1 requires
furthermore installing
• jupyter_dashboards: [Link]
• ipywidgets: [Link]
• pythreejs: [Link]
• bqplot: [Link]
With Python and Anaconda already installed, this can be done by running these
commands
• conda install -c conda-forge ipywidgets
• pip install jupyter_dashboards
• jupyter dashboards quick-setup –sys-prefix
• conda install -c conda-forge bqplot
• conda install -c conda-forge pythreejs
Note that the bqplot installation requires the environment settings mentioned above.

4.4 Building ORE-SWIG and Python Wheels

Since release 4, ORE comes with Python and Java language bindings following the
QuantLib-SWIG example. The ORE bindings extend the QuantLib SWIG wrappers
1
With Windows, after a fresh installation of Python the user may have to run the python command
once in a command shell so that the Python executable will be found subsequently when running the
example scripts in section 5.

29
and allow calling ORE functionality in the QuantExt/OREData/OREAnalytics
libraries alongside with functionality in QuantLib.

The ORE-SWIG source code is hosted in a separate git repository at

[Link] The [Link] in the top level
directory of this git repository contains build instructions and refers to tutorials for
installing and building Python wrappers and wheels.

Typical usage of the Python wrapper is shown in ORE’s Example_42 and in ORE
SWIG’s OREAnalytics/Python/Examples directory.

5 Examples
The examples shown in table 3 are intended to help with getting started with ORE,
and to serve as plausibility checks for the simulation results generated with ORE.

30
Example Description
0 ORE Web Service
1 Vanilla at-the-money Swap with flat yield curve
2 Vanilla Swap with normal yield curve
3 European Swaption
4 Bermudan Swaption
5 Callable Swap
6 Cap/Floor
7 FX Forward
European FX Option
8 Cross Currency Swap without notional reset
9 Cross Currency Swap with notional reset
10 Three-Swap portfolio with netting and collateral
XVAs - CVA, DVA, FVA, MVA, COLVA
Exposure and XVA Allocation to trade level
11 Basel exposure measures - EE, EPE, EEPE
12 Long term simulation with horizon shift
13 Dynamic Initial Margin and MVA
14 Minimal Market Data Setup
15 Sensitivity Analysis and Stress Testing
16 Equity Derivatives Exposure
17 Inflation Swap Exposure under Dodgson-Kainth
18 Bonds and Amortisation Structures
19 Swaption Pricing with Smile
20 Credit Default Swap Pricing
21 Constant Maturity Swap Pricing
22 Option Sensitivity Analysis with Smile
23 Forward Rate Agreement and Averaging OIS Exposure
24 Commodity Forward and Option Pricing and Sensitivity
25 CMS Spread with (Digital) Cap/Floor Pricing, Sensitivity and Exposures
26 Bootstrap Consistency
27 BMA Basis Swap Pricing and Sensitivity
28 Discount Ratio Curves
29 Curve Building using Fixed vs. Float Cross Currency Helpers
30 USD-Prime Curve Building via Prime-LIBOR Basis Swap
31 Exposure Simulation using a Close-out Grid
32 Inflation Swap Exposure under Jarrow-Yildrim
33 CDS Exposure Simulation
34 Wrong Way Risk
35 Flip View
36 Choice of Measure
37 Multifactor Hull-White scenario generation
38 Cross Currency Exposure using Multifactor Hull-White Models
39 Exposure Simulation using American Monte Carlo
40 Par Sensitivity Analysis
41 Multi-threaded Exposure Simulation
42 ORE Python Module
43 Credit Portfolio Model
44 Initial Margin: ISDA SIMM and IM Schedule
45 Collateralized Bond Obligation
46 Generic Total Return Swap
47 Composite Trade
48 Convertible Bond and ASCOT
49 Bond Yield Shifted
50 Par Sensitivity Conversion of external "Raw" Sensis
51 Custom Trade Fixings
52 Scripted Trades
53 Curve Building using FRAs tailored to Central Bank Meeting Dates
54 Scripted Trade Exposure with AMC: Bermudan Swaption and LPI Swap
55 Scripted Trade Exposure with AMC: Fx TaRF
56 CVA Sensitivity using AAD
57 Base Scenario Analytic
58 Historical Simulation VaR
59 SABR model for Swaptions and Caps/Floors
60 Exposure and XVA with Overlapping Close-Out Grids
61 Fast Sensitivties using AAD and GPUs
62 P&L and P&L Explain Analytics
63 Stress Tests in the Par-Rate Domain
64 Formula-based Coupon
65 Flexi Swap
66 Balance Guaranteed Swap
67 XVA Stress Testing
68 XVA Bump & Revalue Sensitivities
69 Convert Zero Rate Shifts into Par Rate Shifts
31
Table 3: ORE examples.
All example results can be produced with the Python scripts [Link] in the ORE
release’s Examples/Example_# folders which work on both Windows and Unix
platforms. In a nutshell, all scripts call ORE’s command line application with a single
input XML file
ore[.exe] [Link]

They produce a number of standard reports and exposure graphs in PDF format. The
structure of the input file and of the portfolio, market and other configuration files
referred to therein will be explained in section 7.

ORE is driven by a number of input files, listed in table 4 and explained in detail in
sections 7 to 11. In all examples, these input files are either located in the example’s
sub directory Examples/Example_#/Input or the main input directory
Examples/Input if used across several examples. The particular selection of input files
is determined by the ’master’ input file [Link].
File Name Description
[Link] Master input file, selection of further inputs below and selection of analytics
[Link] Trade data
[Link] Collateral (CSA) data
[Link] Configuration of simulation model and market
[Link] Market data snapshot
[Link] Index fixing history
[Link] Dividends history
[Link] Curve and term structure composition from individual market instruments
[Link] Market conventions for all market data points
[Link] Configuration of the market composition, relevant for the pricing of the given portfolio
as of today (yield curves, FX rates, volatility surfaces etc)
[Link] Configuration of pricing methods by product

Table 4: ORE input files

The typical list of output files and reports is shown in table 5. The names of output
files can be configured through the master input file [Link]. Whether these reports
are generated also depends on the setting in [Link]. For the examples, all output
will be written to the directory Examples/Example_#/Output.
File Name Description
[Link] NPV report
[Link] Cashflow report
[Link] Generated yield (discount) curves report
[Link] XVA report, value adjustments at netting set and trade level
exposure_trade_*.csv Trade exposure evolution reports
exposure_nettingset_*.csv Netting set exposure evolution reports
[Link] NPV cube in readable text format
[Link] NPV cube after netting and colateral, in readable text format
*.[Link] Intermediate storage of NPV cube and scenario data
*.pdf Exposure graphics produced by the python script [Link] after ORE completed

Table 5: ORE output files

Note: When building ORE from sources on Windows platforms, make sure that you
copy your [Link] to the binary directory App/bin/win32/ respectively
App/bin/x64/. Otherwise the examples may be run using the pre-compiled
executables which come with the ORE release.

32
5.0 ORE Web Service
Since release 12, ORE comes with a proof-of-concept implementation of a web service
around ORE that is written in Python, see folder Examples/API.
The service is based on
• the flask web framework [Link] and
• the ORE Python module which can be installed using
pip install open-source-risk-engine
or built from sources following the instructions in the ORE-SWIG repository at
[Link]

Main files in the Examples/API directory:

• [Link] runs a flask api as analytics service that takes a post request (e.g.
from a server like postman, or from a python script): The request contains a json
body which corresponds to the data usually contained in the master input file
[Link]. [Link] calls the [Link] class (see below) to do the work. By
default, the analytics service listens for requests on port 5001.
• [Link] reads the json body, compiles all ORE input parameters, calls into a
data service (see below) to retrieve additional data. Then it kicks off an ORE run
to process the request. Finally it posts resulting reports through the data service.
• [Link] runs a flask api as a data service. It takes requests from
the analytics service above in the form of urls of xml files that contain additional
data required by ORE (market data, portfolio, configuration). By default, the
data service listens on port 5000, reads from the Input directory in
Examples/API and writes reports to the Output directory in Examples/API.

Run a local example:

• start the data service:
python3 [Link] &
• start the analytics service:
python3 [Link] &
• send a request to run the equivalent of Example 1:
python3 [Link]
Note that the json equivalent of Example_1/Input/[Link] is contained in
[Link], and all other inputs are retrieved from folder Examples/API/Input
via the data service.

5.1 Interest Rate Swap Exposure, Flat Market

We start with a vanilla single currency Swap (currency EUR, maturity 20y, notional
10m, receive fixed 2% annual, pay 6M-Euribor flat). The market yield curves (for both
discounting and forward projection) are set to be flat at 2% for all maturities, i.e. the
Swap is at the money initially and remains at the money on average throughout its
life. Running ORE in directory Examples/Example_1 with
python [Link]

33
yields the exposure evolution in
Examples/Example_1/Output/*.pdf

and shown in figure 2. Both Swap simulation and Swaption pricing are run with calls

600,000 Example 1 - Simulated exposures vs analytical swaption prices

Swap EPE
Swap ENE
500,000 NPV Swaptions

400,000
Exposure

300,000

200,000

100,000

0
0 5 10 15 20 25
Time / Years

Figure 2: Vanilla ATM Swap expected exposure in a flat market environment from both parties’
perspectives. The symbols are European Swaption prices. The simulation was run with monthly
time steps and 10,000 Monte Carlo samples to demonstrate the convergence of EPE and ENE
profiles. A similar outcome can be obtained more quickly with 5,000 samples on a quarterly
time grid which is the default setting of Example_1.

to the ORE executable, essentially

ore[.exe] [Link]
ore[.exe] ore_swaption.xml

which are wrapped into the script Examples/Example_1/[Link] provided with the
ORE release. It is instructive to look into the input folder in Examples/Example_1,
the content of the main input file [Link], together with the explanations in section 7.
This simple example is an important test case which is also run similarly in one of the
unit test suites of ORE. The expected exposure can be seen as a European option on
the underlying netting set, see also appendix A.4. In this example, the expected
exposure at some future point in time, say 10 years, is equal to the European Swaption
price for an option with expiry in 10 years, underlying Swap start in 10 years and
underlying Swap maturity in 20 years. We can easily compute such standard European
Swaption prices for all future points in time where both Swap legs reset, i.e. annually
in this case2 . And if the simulation model has been calibrated to the points on the
Swaption surface which are used for European Swaption pricing, then we can expect to
see that the simulated exposure matches Swaption prices at these annual points, as in
figure 2. In Example_1 we used co-terminal ATM Swaptions for both model
calibration and Swaption pricing. Moreover, as the yield curve is flat in this example,
the exposures from both parties’ perspectives (EPE and ENE) match not only at the
annual resets, but also for the period between annual reset of both legs to the point in
time when the floating leg resets. Thereafter, between floating leg (only) reset and next
joint fixed/floating leg reset, we see and expect a deviation of the two exposure profiles.
2
Using closed form expressions for standard European Swaption prices.

34
5.2 Interest Rate Swap Exposure, Realistic Market
Moving to Examples/Example_2, we see what changes when using a realistic (non-flat)
market environment. Running the example with
python [Link]

yields the exposure evolution in

Examples/Example_2/Output/*.pdf

shown in figure 3. In this case, where the curves (discount and forward) are upward

1,400,000 Example 2
EPE
1,200,000 ENE
Payer Swaption
Receiver Swaption
1,000,000

800,000
Exposure

600,000

400,000

200,000

0
0 5 10 15 20 25
Time / Years

Figure 3: Vanilla ATM Swap expected exposure in a realistic market environment as of

05/02/2016 from both parties’ perspectives. The Swap is the same as in figure 2 but receiv-
ing fixed 1%, roughly at the money. The symbols are the prices of European payer and receiver
Swaptions. Simulation with 5000 paths and monthly time steps.

sloping, the receiver Swap is at the money at inception only and moves (on average)
out of the money during its life. Similarly, the Swap moves into the money from the
counterparty’s perspective. Hence the expected exposure evolutions from our
perspective (EPE) and the counterparty’s perspective (ENE) ’detach’ here, while both
can still be be reconciled with payer or respectively receiver Swaption prices.

5.3 European Swaption Exposure

This demo case in folder Examples/Example_3 shows the exposure evolution of
European Swaptions with cash and physical delivery, respectively, see figure 4. The
delivery type (cash vs physical) yields significantly different valuations as of today due
to the steepness of the relevant yield curves (EUR). The cash settled Swaption’s
exposure graph is truncated at the exercise date, whereas the physically settled
Swaption exposure turns into a Swap-like exposure after expiry. For comparison, the
example also provides the exposure evolution of the underlying forward starting Swap
which yields a somewhat higher exposure after the forward start date than the
physically settled Swaption. This is due to scenarios with negative Swap NPV at
expiry (hence not exercised) and positive NPVs thereafter. Note the reduced EPE in
case of a Swaption with settlement of the option premium on exercise date.

35
 1,200,000 Example 3
EPE Swap
EPE Swaption Cash
1,000,000 EPE Swaption Physical
EPE Swaption Cash with Premium
800,000
Exposure

600,000

400,000

200,000

0
0 5 10 15 20 25
Time / Years

Figure 4: European Swaption exposure evolution, expiry in 10 years, final maturity in 20 years,
for cash and physical delivery. Simulation with 1000 paths and quarterly time steps.

5.4 Bermudan Swaption Exposure

This demo case in folder Examples/Example_4 shows the exposure evolution of
Bermudan rather than European Swaptions with cash and physical delivery,
respectively, see figure 5. The underlying Swap is the same as in the European

1,200,000 Example 4
EPE Forward Swap
EPE Swaption (Cash)
1,000,000 EPE Swaption (Physical)

800,000
Exposure

600,000

400,000

200,000

0
0 5 10 15 20 25
Time / Years

Figure 5: Bermudan Swaption exposure evolution, 5 annual exercise dates starting in 10 years,
final maturity in 20 years, for cash and physical delivery. Simulation with 1000 paths and
quarterly time steps.

Swaption example in section 5.3. Note in particular the difference between the
Bermudan and European Swaption exposures with cash settlement: The Bermudan
shows the typical step-wise decrease due to the series of exercise dates. Also note that
we are using the same Bermudan option pricing engines for both settlement types, in
contrast to the European case, so that the Bermudan option cash and physical
exposures are identical up to the first exercise date. When running this example, you
will notice the significant difference in computation time compared to the European
case (ballpark 30 minutes here for 2 Swaptions, 1000 samples, 90 time steps). The

36
Bermudan example takes significantly more computation time because we use an LGM
grid engine for pricing under scenarios in this case. In a realistic context one would
more likely resort to American Monte Carlo simulation, feasible in ORE, but not
provided in the current release. However, this implementation can be used to
benchmark any faster / more sophisticated approach to Bermudan Swaption exposure
simulation.

5.5 Callable Swap Exposure

This demo case in folder Examples/Example_5 shows the exposure evolution of a
European callable Swap, represented as two trades - the non-callable Swap and a
Swaption with physical delivery. We have sold the call option, i.e. the Swaption is a
right for the counterparty to enter into an offsetting Swap which economically
terminates all future flows if exercised. The resulting exposure evolutions for the
individual components (Swap, Swaption), as well as the callable Swap are shown in
figure 6. The example is an extreme case where the underlying Swap is deeply in the

9,000,000 Example 5
EPE Swap
8,000,000 ENE Swaption
EPE Netting Set
7,000,000 EPE Short Swap
6,000,000
5,000,000
Exposure

4,000,000
3,000,000
2,000,000
1,000,000
0
0 5 10 15 20 25
Time / Years

Figure 6: European callable Swap represented as a package consisiting of non-callable Swap and
Swaption. The Swaption has physical delivery and offsets all future Swap cash flows if exercised.
The exposure evolution of the package is shown here as ’EPE Netting Set’ (green line). This
is covered by the pink line, the exposure evolution of the same Swap but with maturity on the
exercise date. The graphs match perfectly here, because the example Swap is deep in the money
and exercise probability is close to one. Simulation with 5000 paths and quarterly time steps.

money (receiving fixed 5%), and hence the call exercise probability is close to one.
Modify the Swap and Swaption fixed rates closer to the money (≈ 1%) to see the
deviation between net exposure of the callable Swap and the exposure of a ’short’
Swap with maturity on exercise.
We have added more recently the combined CallableSwap instrument representation,
check [Link] and compare the CallableSwap NPV in [Link] to the package
NPV of Swap and Swaption.

37
5.6 Cap/Floor Exposure
The example in folder Examples/Example_6 generates exposure evolutions of several
Swaps, caps and floors. The example shown in figure 7 (’portfolio 1’) consists of a 20y
Swap receiving 3% fixed and paying Euribor 6M plus a long 20y Collar with both cap
and floor at 4% so that the net exposure corresponds to a Swap paying 1% fixed.

600,000 Example 6, Portfolio 1

EPE Swap
ENE Collar
500,000 ENE Netting

400,000
Exposure

300,000

200,000

100,000

0
0 5 10 15 20
Time / Years

Figure 7: Swap+Collar, portfolio 1. The Collar has identical cap and floor rates at 4% so that
it corresponds to a fixed leg which reduces the exposure of the Swap, which receives 3% fixed.
Simulation with 1000 paths and quarterly time steps.

The second example in this folder shown in figure 8 (’portfolio 2’) consists of a short
Cap, long Floor and a long Collar that exactly offsets the netted Cap and Floor.

35,000 Example 6, Portfolio 2

EPE Floor
30,000 ENE Cap
EPE Net Cap and Floor
ENE Collar
25,000

20,000
Exposure

15,000

10,000

5,000

0
0 5 10 15 20
Time / Years

Figure 8: Short Cap and long Floor vs long Collar, portfolio 2. Simulation with 1000 paths and
quarterly time steps.

Further three test portfolios are provided as part of this example. Run the example
and inspect the respective output directories
Examples/Example_6/Output/portfolio_#. Note that these directories have to be
present/created before running the batch with python [Link].

38
5.7 FX Forward and FX Option Exposure
The example in folder Examples/Example_7 generates the exposure evolution for a
EUR / USD FX Forward transaction with value date in 10Y. This is a particularly
simple show case because of the single cash flow in 10Y. On the other hand it checks
the cross currency model implementation by means of comparison to analytic limits -
EPE and ENE at the trade’s value date must match corresponding Vanilla FX Option
prices, as shown in figure 9.

300,000 Example 7 - FX Forward

EPE
ENE
250,000 Call Price
Put Price
200,000
Exposure

150,000

100,000

50,000

0
0 2 4 6 8 10 12
Time / Years

Figure 9: EUR/USD FX Forward expected exposure in a realistic market environment as of

26/02/2016 from both parties’ perspectives. Value date is obviously in 10Y. The flat lines are
FX Option prices which coincide with EPE and ENE, respectively, on the value date. Simulation
with 5000 paths and quarterly time steps.

FX Option Exposure
This example (in folder Examples/Example_7, as the FX Forward example) illustrates
the exposure evolution for an FX Option, see figure 10. Recall that the FX Option
value N P V (t) as of time 0 ≤ t ≤ T satisfies

(X(T ) − K)+
 
N P V (t)
= Nominal × Et
N (t) N (T )
N P V + (t)
   
N P V (t)
N P V (0) = E =E = EPE (t)
N (t) N (t)

where N (t) denotes the numeraire asset. One would therefore expect a flat exposure
evolution up to option expiry. The deviation from this in ORE’s simulation is due to
the pricing approach chosen here under scenarios. A Black FX option pricer is used
with deterministic Black volatility derived from today’s volatility structure (pushed or
rolled forward, see section 7.4.3). The deviation can be removed by extending the
volatility modelling, e.g. implying model consistent Black volatilities in each
simulation step on each path.

39
 300,000 Example 7 - FX Option
EPE
ENE
250,000 Call Price
Put Price
200,000
Exposure

150,000

100,000

50,000

0
0 2 4 6 8 10 12
Time / Years

Figure 10: EUR/USD FX Call and Put Option exposure evolution, same underlying and mar-
ket data as in section 5.7, compared to the call and put option price as of today (flat line).
Simulation with 5000 paths and quarterly time steps.

5.8 Cross Currency Swap Exposure, without FX Reset

The case in Examples/Example_8 is a vanilla cross currency Swap. It shows the typical
blend of an Interest Rate Swap’s saw tooth exposure evolution with an FX Forward’s
exposure which increases monotonically to final maturity, see figure 11.

3,500,000 Example 8
EPE CCSwap
3,000,000 ENE CCSwap

2,500,000

2,000,000
Exposure

1,500,000

1,000,000

500,000

0
0 5 10 15 20 25
Time / Years

Figure 11: Cross Currency Swap exposure evolution without mark-to-market notional reset.
Simulation with 1000 paths and quarterly time steps.

5.9 Cross Currency Swap Exposure, with FX Reset

The effect of the FX resetting feature, common in Cross Currency Swaps nowadays, is
shown in Examples/Example_9. The example shows the exposure evolution of a
EUR/USD cross currency basis Swap with FX reset at each interest period start, see
figure 12. As expected, the notional reset causes an exposure collapse at each period
start when the EUR leg’s notional is reset to match the USD notional.

40
 14,000,000 Example 9
Swap
12,000,000 Resettable Swap

10,000,000

8,000,000
Exposure

6,000,000

4,000,000

2,000,000

0
0 2 4 6 8 10 12
Time / Years

Figure 12: Cross Currency Basis Swap exposure evolution with and without mark-to-market
notional reset. Simulation with 1000 paths and quarterly time steps.

5.10 Netting Set, Collateral, XVAs, XVA Allocation

In this example (see folder Examples/Example_10) we showcase a small netting set
consisting of three Swaps in different currencies, with different collateral choices
• no collateral - figure 13,
• collateral with threshold (THR) 1m EUR, minimum transfer amount (MTA)
100k EUR, margin period of risk (MPOR) 2 weeks - figure 14
• collateral with zero THR and MTA, and MPOR 2w - figure 15
The exposure graphs with collateral and positive margin period of risk show typical
spikes. What is causing these? As sketched in appendix A.13, ORE uses a classical
collateral model that applies collateral amounts to offset exposure with a time delay
that corresponds to the margin period of risk. The spikes are then caused by
instrument cash flows falling between exposure measurement dates d1 and d2 (an
MPOR apart), so that a collateral delivery amount determined at d1 but settled at d2
differs significantly from the closeout amount at d2 causing a significant residual
exposure for a short period of time. See for example [23] for a recent detailed discussion
of collateral modelling. The approach currently implemented in ORE corresponds to
Classical+ in [23], the more conservative approach of the classical methods. The less
conservative alternative, Classical-, would assume that both parties stop paying trade
flows at the beginning of the MPOR, so that the P&L over the MPOR does not
contain the cash flow effect, and exposure spikes are avoided. Note that the size and
position of the largest spike in figure 14 is consistent with a cash flow of the 40 million
GBP Swap in the example’s portfolio that rolls over the 3rd of March and has a cash
flow on 3 March 2020, a bit more than four years from the evaluation date.

CVA, DVA, FVA, COLVA, MVA, Collateral Floor

We use one of the cases in Examples/Example_10 to demonstrate the XVA outputs,
see folder Examples/Example_10/Output/collateral_threshold_dim.

41
 4,000,000 Example 10
EPE Swap 1
3,500,000 EPE Swap 2
EPE Swap 3
3,000,000 EPE NettingSet

2,500,000
Exposure

2,000,000

1,500,000

1,000,000

500,000

0
0 2 4 6 8 10 12
Time / Years

Figure 13: Three Swaps netting set, no collateral. Simulation with 5000 paths and bi-weekly
time steps.

The summary of all value adjustments (CVA, DVA, FVA, COLVA, MVA, as well as the
Collateral Floor) is provided in file [Link]. The file includes the allocated CVA and
DVA numbers to individual trades as introduced in the next section. The following
table illustrates the file’s layout, omitting the three columns containing allocated data.

TradeId NettingSetId CVA DVA FBA FCA COLVA MVA CollateralFloor BaselEPE BaselEEPE
CPTY_A 6,521 151,193 -946 72,103 2,769 -14,203 189,936 113,260 1,211,770
Swap_1 CPTY_A 127,688 211,936 -19,624 100,584 n/a n/a n/a 2,022,590 2,727,010
Swap_3 CPTY_A 71,315 91,222 -11,270 43,370 n/a n/a n/a 1,403,320 2,183,860
Swap_2 CPTY_A 68,763 100,347 -10,755 47,311 n/a n/a n/a 1,126,520 1,839,590

The line(s) with empty TradeId column contain values at netting set level, the others
contain uncollateralised single-trade VAs. Note that COLVA, MVA and Collateral
Floor are only available at netting set level at which collateral is posted.

Detailed output is written for COLVA and Collateral Floor to file

colva_nettingset_*.csv which shows the incremental contributions to these two
VAs through time.

Exposure Reports & XVA Allocation to Trades

Using the example in folder Examples/Example_10 we illustrate here the layout of an
exposure report produced by ORE. The report shows the exposure evolution of
Swap_1 without collateral which - after running Example_10 - is found in folder
Examples/Example_10/Output/collateral_none/exposure_trade_Swap_1.csv:

TradeId Date Time EPE ENE AllocEPE AllocENE PFE BaselEE BaselEEE
Swap_1 05/02/16 0.0000 0 1,711,748 0 0 0 0 0
Swap_1 19/02/16 0.0383 38,203 1,749,913 -1,200,677 511,033 239,504 38,202 38,202
Swap_1 04/03/16 0.0765 132,862 1,843,837 -927,499 783,476 1,021,715 132,845 132,845
Swap_1 ... ... ... ... ... ... ... ... ...

The exposure measures EPE, ENE and PFE, and the Basel exposure measures EEB
and EEEB , are defined in appendix A.4. Allocated exposures are defined in appendix
A.14. The PFE quantile and allocation method are chosen as described in section 7.1.4.

42
 3,000,000 Example 10
EPE NettingSet, Threshold 1m
EPE NettingSet, Threshold 1m, Breaks
2,500,000

2,000,000
Exposure

1,500,000

1,000,000

500,000

0
0 2 4 6 8 10 12
Time / Years

Figure 14: Three Swaps netting set, THR=1m EUR, MTA=100k EUR, MPOR=2w. The red
evolution assumes that the each trade is terminated at the next break date. The blue evolution
ignores break dates. Simulation with 5000 paths and bi-weekly time steps.

4,000,000 Example 10
EPE NettingSet
3,500,000 EPE NettingSet, MPOR 2W
3,000,000

2,500,000
Exposure

2,000,000

1,500,000

1,000,000

500,000

0
0 2 4 6 8 10 12
Time / Years

Figure 15: Three Swaps, THR=MTA=0, MPOR=2w. Simulation with 5000 paths and bi-weekly
time steps.

In addition to single trade exposure files, ORE produces an exposure file per netting
set. The example from the same folder as above is:

NettingSet Date Time EPE ENE PFE ExpectedCollateral BaselEE BaselEEE

CPTY_A 05/02/16 0.0000 1,203,836 0 1,203,836 0 1,203,836 1,203,836
CPTY_A 19/02/16 0.0383 1,337,713 137,326 3,403,460 0 1,337,651 1,337,651
CPTY_A ... ... ... ... ... ... ... ...

Allocated exposures are missing here, as they make sense at the trade level only, and
the expected collateral balance is added for information (in this case zero as
collateralisation is deactivated in this example).

The allocation of netting set exposure and XVA to the trade level is frequently
required by finance departments. This allocation is also featured in
Examples/Example_10. We start again with the uncollateralised case in figure 16,

43
followed by the case with threshold 1m EUR in figure 17. In both cases we apply the

2,500,000 Example 10
Allocated EPE Swap 1
2,000,000 Allocated EPE Swap 2
Allocated EPE Swap 3
1,500,000

1,000,000
Exposure

500,000

-500,000

-1,000,000

-1,500,000
0 2 4 6 8 10 12
Time / Years

Figure 16: Exposure allocation without collateral. Simulation with 5000 paths and bi-weekly
time steps.

marginal (Euler) allocation method as published by Pykhtin and Rosen in 2010, hence
we see the typical negative EPE for one of the trades at times when it reduces the
netting set exposure. The case with collateral moreover shows the typical spikes in the
allocated exposures. The analytics results also feature allocated XVAs in file [Link]

Example 10
Allocated EPE Swap 1
8,000,000 Allocated EPE Swap 2
Allocated EPE Swap 3
6,000,000

4,000,000
Exposure

2,000,000

-2,000,000

-4,000,000

-6,000,000
0 2 4 6 8 10
Time / Years

Figure 17: Exposure allocation with collateral and threshold 1m EUR. Simulation with 5000
paths and bi-weekly time steps.

which are derived from the allocated exposure profiles. Note that ORE also offers
alternative allocation methods to the marginal method by Pykhtin/Rosen, which can
be explored with Examples/Example_10.

5.11 Basel Exposure Measures

Example Example_11 demonstrates the relation between the evolution of the expected
exposure (EPE in our notation) to the ‘Basel’ exposure measures EE_B, EEE_B,
EPE_B and EEPE_B as defined in appendix A.4. In particular the latter is used in
internal model methods for counterparty credit risk as a measure for the exposure at

44
default. It is a ‘derivative’ of the expected exposure evolution and defined as a time
average over the running maximum of EE_B up to the horizon of one year.

700,000 Example 11 - Basel Measures

EPE
600,000 BASEL EE
BASEL EEE
BaselEPE
500,000 BaselEEPE
400,000
Exposure

300,000

200,000

100,000

0
0 5 10 15 20
Time / Years

Figure 18: Evolution of the expected exposure of Vanilla Swap, comparison to the ‘Basel’ expo-
sure measures EEE_B, EPE_B and EEPE_B. Note that the latter two are indistinguishable
in this case, because the expected exposure is increasing for the first year.

5.12 Long Term Simulation with Horizon Shift

The example in folder Example_12 finally demonstrates an effect that, at first glance,
seems to cause a serious issue with long term simulations. Fortunately this can be
avoided quite easily in the Linear Gauss Markov model setting that is used here.
In the example we consider a Swap with maturity in 50 years in a flat yield curve
environment. If we simulate this naively as in all previous cases, we obtain a
particularly noisy EPE profile that does not nearly reconcile with the known exposure
(analytical Swaption prices). This is shown in figure 19 (‘no horizon shift’). The origin
of this issue is the width of the risk-neutral NPV distribution at long time horizons
which can turn out to be quite small so that the Monte Carlo simulation with finite
number of samples does not reach far enough into the positive or negative NPV range
to adequately sample the distribution, and estimate both EPE and ENE in a single
run. Increasing the number of samples may not solve the problem, and may not even
be feasible in a realistic setting.
The way out is applying a ‘shift transformation’ to the Linear Gauss Markov model,
see Example_12/Input/[Link] in lines 92-95:

<ParameterTransformation>
<ShiftHorizon>30.0</ShiftHorizon>
<Scaling>1.0</Scaling>
</ParameterTransformation>

The effect of the ’ShiftHorizon’ parameter T is to apply a shift to the Linear Gauss
Markov model’s H(t) parameter (see appendix A.1) after the model has been
calibrated, i.e. to replace:
H(t) → H(t) − H(T )

45
It can be shown that this leaves all expectations computed in the model (such as EPE
and ENE) invariant. As explained in [21], subtracting an H shift effectively means
performing a change of measure from the ‘native’ LGM measure to a T-Forward
measure with horizon T , here 30 years. Both negative and positive shifts are
permissible, but only negative shifts are connected with a T-Forward measure and
improve numerical stability.
In our experience it is helpful to place the horizon in the middle of the portfolio
duration to significantly improve the quality of long term expectations. The effect of
this change (only) is shown in the same figure 19 (‘shifted horizon’). Figure 20 further

1,600,000 Example 12 - Simulated exposures with and without horizon shift

Swap EPE (no horizon shift)
1,400,000 Swap ENE (no horizon shift)
Swap EPE (shifted horizon)
1,200,000 Swap ENE (shifted horizon)
NPV Swaptions
1,000,000
Exposure

800,000

600,000

400,000

200,000

0
0 10 20 30 40 50 60
Time / Years

Figure 19: Long term Swap exposure simulation with and without horizon shift.

illustrates the origin of the problem and its resolution: The rate distribution’s mean
(without horizon shift or change of measure) drifts upwards due to convexity effects
(note that the yield curve is flat in this example), and the distribution’s width is then
too narrow at long horizons to yield a sufficient number of low rate scenarios with
contributions to the Swap’s EPE (it is a floating rate payer). With the horizon shift
(change of measure), the distribution’s mean is pulled ’back’ at long horizons, because
the convexity effect is effectively wiped out at the chosen horizon, and the expected
rate matches the forward rate.

5.13 Dynamic Initial Margin and MVA

This example in folder Examples/Example_13 demonstrates Dynamic Initial Margin
calculations (see also appendix A.10) for a number of elementary products:
• A single currency Swap in EUR (case A),
• a European Swaption in EUR with physical delivery (case B),
• a single currency Swap in USD (case C), and
• a EUR/USD cross currency Swap (case D).
The examples can be run as before with
python run_A.py

46
 0.1600 Example 12 - 5y zero rate (EUR) distribution with and without horizon shift
No horizon shift (mean)
0.1400 No horizon shift (mean +/- std)
Shifted horizon (mean)
0.1200 Shifted horizon (mean +/- std)
0.1000
0.0800
Zero Rate

0.0600
0.0400
0.0200
0.0000
-0.0200
2017 2022 2027 2032 2037 2042 2047 2052 2057 2062
Time

Figure 20: Evolution of rate distributions with and without horizon shift (change of measure).
Thick lines indicate mean values, thin lines are contours of the rate distribution at ± one
standard deviation.

and likewise for cases B, C and D. The essential results of each run are are visualised
in the form of
• evolution of expected DIM
• regression plots at selected future times
illustrated for cases A and B in figures 21 - 24. In the three swap cases, the regression
orders do make a noticeable difference in the respective expected DIM evolution. In
the Swaption case B, first and second order polynomial choice makes a difference
before option expiry. More details on this DIM model and its performance can be
found in [22, 26].

5.14 Minimal Market Data Setup

The example in folder Examples/Example_14 demonstrates using a minimal market
data setup in order to rerun the vanilla Swap exposure simulation shown in
Examples/Example_1. The minimal market data uses single points per curve where
possible.

5.15 Sensitivity Analysis, Stress Testing and Parametric

Value-at-Risk
The example in folder Examples/Example_15 demonstrates the calculation of
sensitivities and stress scenarios. The portfolio used in this example consists of
• a vanilla swap in EUR
• a cross currency swap EUR-USD
• a resettable cross currency swap EUR-USD
• a FX forward EUR-USD

47
 600,000 Example 13 (A) - DIM Evolution Swap EUR
Zero Order Regression
First Order Regression
500,000 Second Order Regression

400,000

300,000
DIM

200,000

100,000

0
0 50 100 150 200 250 300
Timestep

Figure 21: Evolution of expected Dynamic Initial Margin (DIM) for the EUR Swap of Example
13 A. DIM is evaluated using regression of NPV change variances versus the simulated 3M
Euribor fixing; regression polynomials are zero, first and second order (first and second order
curves are not distinguishable here). The simulation uses 1000 samples and a time grid with
bi-weekly steps in line with the Margin Period of Risk.

Example 13 (A) - DIM Regression Swap EUR, Timestep 100

3 Simulation Data
Zero Order Regression
3 First Order Regression
Second Order Regression
2
Clean NPV Variance

0
0.03 0.02 0.01 0.00 0.01 0.02 0.03
Rate

Figure 22: Regression snapshot at time step 100 for the EUR Swap of Example 13 A.

• a FX call option on USD/GBP

• a FX put option on USD/EUR
• an European swaption
• a Bermudan swaption
• a cap and a floor in USD
• a cap and a floor in EUR
• a fixed rate bond
• a floating rate bond with floor

48
 140,000 Example 13 (B) - DIM Evolution Swaption (physical delivery) EUR
Zero Order Regression
120,000 First Order Regression
Second Order Regression
100,000

80,000
DIM

60,000

40,000

20,000

0
0 100 200 300 400 500 600
Timestep

Figure 23: Evolution of expected Dynamic Initial Margin (DIM) for the EUR Swaption of
Example 13 B with expiry in 10Y around time step 100. DIM is evaluated using regression of
NPV change variances versus the simulated 3M Euribor fixing; regression polynomials are zero,
first and second order. The simulation uses 1000 samples and a time grid with bi-weekly steps
in line with the Margin Period of Risk.

Example 13 (B) - DIM Regression Swaption (physical delivery) EUR, Timestep 100
Simulation Data
Zero Order Regression
8 First Order Regression
Second Order Regression
Clean NPV Variance

0
0.03 0.02 0.01 0.00 0.01 0.02 0.03 0.04
Regressor

Figure 24: Regression snapshot at time step 100 (before expiry) for the EUR Swaption of
Example 13 B.

• an Equity call option, put option and forward on S&P500

• an Equity call option, put option and forward on Lufthansa
• a CPI Swap referencing UKRPI
• a Year-on-Year inflation swap referencing EUHICPXT
• a USD CDS.
The sensitivity configuration in [Link] aims at computing the following
sensitivities
• discount curve sensitivities in EUR, USD; GBP, CHF, JPY, on pillars 6M, 1Y,

49
 2Y, 3Y, 5Y, 7Y, 10Y, 15Y, 20Y (absolute shift of 0.0001)
• forward curve sensitivities for EUR-EURIBOR 6M and 3M indices,
EUR-EONIA, USD-LIBOR 3M and 6M, GBP-LIBOR 3M and 6M,
CHF-LIBOR-6M and JPY-LIBOR-6M indices (absolute shift of 0.0001)
• yield curve shifts for a bond benchmark curve in EUR (absolute shift of 0.0001)
• FX spot sensitivities for USD, GBP, CHF, JPY against EUR as the base
currency (relative shift of 0.01)
• FX vegas for USDEUR, GBPEUR, JPYEUR volatility surfaces (relative shift of
0.01)
• swaption vegas for the EUR surface on expiries 1Y, 5Y, 7Y, 10Y and underlying
terms 1Y, 5Y, 10Y (relative shift of 0.01)
• caplet vegas for EUR and USD on an expiry grid 1Y, 2Y, 3Y, 5Y, 7Y, 10Y and
strikes 0.01, 0.02, 0.03, 0.04, 0.05. (absolute shift of 0.0001)
• credit curve sensitivities on tenors 6M, 1Y, 2Y, 5Y, 10Y (absolute shift of
0.0001).
• Equity spots for S&P500 and Lufthansa
• Equity vegas for S&P500 and Lufthansa at expiries 6M, 1Y, 2Y, 3Y, 5Y
• Zero inflation curve deltas for UKRPI and EUHICPXT at tenors 6M, 1Y, 2Y,
3Y, 5Y, 7Y, 10Y, 15Y, 20Y
• Year on year inflation curve deltas for EUHICPXT at tenors 6M, 1Y, 2Y, 3Y,
5Y, 7Y, 10Y, 15Y, 20Y
Furthermore, mixed second order derivatives (“cross gammas”) are computed for
discount-discount, discount-forward and forward-forward curves in EUR.
By definition the sensitivities are zero rate sensitivities and optionlet sensitivities, no
par sensitivities are provided. The sensitivity analysis produces three output files.
The first, [Link], contains the shift direction (UP, DOWN, CROSS), the base NPV,
the scenario NPV and the difference of these two for each trade and sensitivity key.
For an overview over the possible scenario keys see 7.5.
The second file, [Link], contains the shift size (in absolute terms always)
and first (“Delta”) and second (“Gamma”) order finite differences computed from the
scenario results. Note that the Delta and Gamma results are pure differences, i.e. they
are not divided by the shift size.
The second file also contains second order mixed differences according to the specified
cross gamma filter, along with the shift sizes for the two factors involved.
The stress scenario definition in [Link] defines two stress tests:
• parallel_rates: Rates are shifted in parallel by 0.01 (absolute). The EUR
bond benchmark curve is shifted by increasing amounts 0.001, ..., 0.009 on the
pillars 6M, ..., 20Y. FX Spots are shifted by 0.01 (relative), FX vols by 0.1

50
 (relative), swaption and cap floor vols by 0.0010 (absolute). Credit curves are not
yet shifted.
• twist: The EUR bond benchmark curve is shifted by amounts -0.0050, -0.0040,
-0.0030, -0.0020, 0.0020, 0.0040, 0.0060, 0.0080, 0.0100 on pillars 6M, 1Y, 2Y, 3Y,
5Y, 7Y, 10Y, 15Y, 20Y.
The corresponding output file [Link] contains the base NPV, the NPV
under the scenario shifts and the difference of the two for each trade and scenario label.

Finally, this example demonstrates a parametric VaR calculation based on the

sensitivity and cross gamma output from the sensitivity analysis (deltas, vegas,
gammas, cross gammas) and an external covariance matrix input. The result in
[Link] shows a breakdown by portfolio, risk class (All, Interest Rate, FX, Inflation,
Equity, Credit) and risk type (All, Delta & Gamma, Vega). The results shown are
Delta Gamma Normal VaRs for the 95% and 99% quantile, the holding period is
incorporated into the input covariances. Alternatively, one can choose a Monte Carlo
VaR which means that the sensitivity based P&L distribution is evaluated with MC
simulation assuming normal respectively log-normal risk factor distribution.

5.16 Equity Derivatives Exposure

The example in folder Examples/Example_16 demonstrates the computation of NPV,
sensitivities, exposures and XVA for a portfolio of OTC equity derivatives. The
portfolio used in this example consists of:
• an equity call option denominated in EUR (“Luft”)
• an equity put option denominated in EUR (“Luft”)
• an equity forward denominated in EUR (“Luft”)
• an equity call option denominated in USD (“SP5”)
• an equity put option denominated in USD (“SP5”)
• an equity forward denominated in USD (“SP5”)
• an equity Swap in USD with return type “price” (“SP5”)
• an equity Swap in USD with return type “total” (“SP5”)
The step-by-step procedure for running ORE is identical for equities as for other asset
classes; the same market and portfolio data files are used to store the equity market
data and trade details, respectively. For the exposure simulation, the calibration
parameters for the equity risk factors can be set in the usual [Link] file.
Looking at the MtM results in the output file [Link] we observe that put-call parity
(VF wd = VCall − VP ut ) is observed as expected. Looking at Figure 25 we observe that
the Expected Exposure profile of the equity call option trade is relatively smooth over
time, while for the equity forward trade the Expected Exposure tends to increase as we
approach maturity. This behaviour is similar to what we observe in sections 5.7 and
5.7.

51
 2,000 Example 16 - Simulated exposures for Luft call option and fwd trade
Call EE
Fwd EE
1,500
Exposure

1,000

500

0
0 5 10 15 20 25
Time / Years

Figure 25: Equity (“Luft”) call option and OTC forward exposure evolution, maturity in ap-
proximately 2.5 years. Simulation with 10000 paths and quarterly time steps.

5.17 Inflation Swap Exposure under Dodgson-Kainth

The example portfolio in folder Examples/Example_17 contains two CPI Swaps and
one Year-on-Year Inflation Swap. The terms of the three trades are as follows:
• CPI Swap 1: Exchanges on 2036-02-05 a fixed amount of 20m GBP for a 10m
GBP notional inflated with UKRPI with base CPI 210
• CPI Swap 2: Notional 10m GBP, maturity 2021-07-18, exchanging GBP Libor
for GBP Libor 6M vs. 2% x CPI-Factor (Act/Act), inflated with index UKRPI
with base CPI 210
• YOY Swap: Notional 10m EUR, maturity 2021-02-05, exchanging fixed coupons
for EUHICPXT year-on-year inflation coupons
• YOY Swap with capped/floored YOY leg: Notional 10m EUR, maturity
2021-02-05, exchanging fixed coupons for EUHICPXT year-on-year inflation
coupons, YOY leg capped with 0.03 and floored with 0.005
• YOY Swap with scheduled capped/floored YOY leg: Notional 10m EUR,
maturity 2021-02-05, exchanging fixed coupons for EUHICPXT year-on-year
inflation coupons, YOY leg capped with cap schedule and floored with floor
schedule
The example generates cash flows, NPVs, exposure evolutions, XVAs, as well as two
exposure graphs for CPI Swap 1 respectively the YOY Swap. For the YOY Swap and
the both YOY Swaps with capped/floored YOY leg, the example generates their cash
flows, NPVs, exposure evolutions, XVAs and sensitivities. Figure 26 shows the CPI
Swap exposure evolution.
Figure 27 shows the evolution of the 5Y maturity Year-on-Year inflation swap for
comparison. Note that the inflation simulation model (Dodgson-Kainth, see appendix
A.1) yields the evolution of inflation indices and inflation zero bonds which allows
spanning future inflation zero curves and the pricing of CPI swaps. To price
Year-on-Year inflation Swaps under future scenarios, we imply Year-on-Year inflation

52
 5,000,000 Example 17
EPE CPI Swap

4,000,000

3,000,000
Exposure

2,000,000

1,000,000

0
0 5 10 15 20 25
Time / Years

Figure 26: CPI Swap 1 exposure evolution. Simulation with 1000 paths and quarterly time
steps.

curves from zero inflation curves3 . Note that for pricing Year-on-Year Swaps as of
today we use a separate inflation curve bootstrapped from quoted Year-on-Year
inflation Swaps.

300,000 Example 17
EPE YoY Swap
250,000

200,000
Exposure

150,000

100,000

50,000

0
0 5 10 15 20 25
Time / Years

Figure 27: Year-on-Year Inflation Swap exposure evolution. Simulation with 1000 paths and
quarterly time steps.

5.18 Bonds and Amortisation Structures

The example in folder Examples/Example_18 computes NPVs and cash flow
projections for a vanilla bond portfolio consisting of a range of bond products, in
particular demonstrating amortisation features. Also, pricing using a benchmark bond
price curve (bond definitions in [Link]) is demonstrated:
• fixed rate bond
3
Currently we discard the required (small) convexity adjustment. This will be supplemented in a
subsequent release.

53
 • floating rate bond linked to Euribor 6M
• bond switching from fixed to floating
• bond with ’fixed amount’ amortisation
• bond with percentage amortisation relative to the initial notional
• bond with percentage amortisation relative to the previous notional
• bond with fixed annuity amortisation
• bond with floating annuity amortisation (this example needs QuantLib 1.10 or
higher to work, in particular the amount() method in the Coupon class needs to
be virtual)
• bond with fixed amount amortisation followed by percentage amortisation
relative to previous notional
• fixed rate bond using a benchmark bond price curve instead of the benchmark
yield curve
After running the example, the results of the computation can be found in the output
files [Link] and [Link], respectively.

Note that the amortisation features used here are linked to the LegData structure,
hence not limited to the Bond instrument, see section 8.3.7.

5.19 Swaption Pricing with Smile

This example in folder Examples/Example_19 demonstrates European Swaption
pricing with and without smile. Calling
python [Link]

will launch two ORE runs using config files ore_flat.xml and ore_smile.xml,
respectively. The only difference in these is referencing alternative market
configurations todaymarket_flat.xml and todaysmarket_smile.xml using an ATM
Swaption volatility matrix and a Swaption cube, respectively. NPV results are written
to npv_flat.cvs and npv_smile.csv.

5.20 Credit Default Swap Pricing

This example in folder Examples/Example_20 demonstrates Credit Default Swap
pricing via ORE. Calling
python [Link]

will launch a single ORE run to process a single name CDS example and to generate
NPV and cash flows in the usual result files.

CDS can be included in sensitivity analysis and stress testing. Exposure simulation for
credit derivatives will follow in the next ORE release.

54
5.21 CMS and CMS Cap/Floor Pricing
This example in folder Examples/Example_21 demonstrates the pricing of CMS and
CMS Cap/Floor using a portfolio consisting of a CMS Swap (CMS leg vs. fixed leg)
and a CMS Cap. Calling
python [Link]

will launch a single ORE run to process the portfolio and generate NPV and cash flows
in the usual result files.

CMS structures can be included in sensitivity analysis, stress testing and exposure
simulation.

5.22 Option Sensitivity Analysis with Smile

The example in folder Examples/Example_22 demonstrates the current state of
sensitivity calculation for European options where the volatility surface has a smile.

The portfolio used in this example consists of

• an equity call option denominated in USD (“SP5”)
• an equity put option denominated in USD (“SP5”)
• a receiver swaption in EUR
• an FX call option on EUR/USD

Refer to appendix A.15 for the current status of sensitivity implementation with smile.
In this example the setup is as follows
• today’s market is configured with volatility smile for all three products above
• simulation market has two configurations, to simulate “ATM only” or the “full
surface”; “ATM only” means that only ATM volatilities are to be simulated and
shifts to ATM vols are propagated to the respective smile section (see appendix
A.15);
• the sensitivity analysis has two corresponding configurations as well, “ATM only”
and “full surface”; note that the “full surface” configuration leads to explicit
sensitivities by strike only in the case of Swaption volatilities, for FX and Equity
volatilities only ATM sensitivity can be specified at the moment and sensitivity
output is currently aggregated to the ATM bucket (to be extended in subsequent
releases).
The respective output files end with “_fullSurface.csv” respectively
“_atmOnly.csv”.

5.23 FRA and Average OIS Exposure

This example in folder Examples/Example_23 demonstrates pricing, cash flow
projection and exposure simulation for two additional products
• Forward Rate Agreements

55
 • Averaging Overnight Index Swaps
using a minimal portfolio of four trades, one FRA and three OIS. The essential results
are in [Link], [Link] and four exposure_trade_*.csv files.

5.24 Commodity Derivatives, Pricing, Sensitivity, Exposure

Calling
python [Link]

in folder Examples/Example_24 will launch two ORE runs. The first one determined
by [Link] demonstrates pricing and sensitivity analysis for
• Commodity Forwards
• European Commodity Options
using a minimal portfolio of four forwards and two options referencing WTI and Gold.
The essential results are in [Link] and [Link].
The second run determined by ore_wti.xml demonstrates Commodity exposure
simulation for a portfolio including a
• Commodity Forward
• Commodity Swap
• European Commodity Option
• Commodity Average Price Option
• Commodity Swaption
with the usual results, exposure reports and graphs.

5.25 CMS Spread with (Digital) Cap/Floor

The example in folder Examples/Example_25 demonstrates pricing, sensitivity analysis
and exposure simulation for
• Capped/Floored CMS Spreads
• CMS Spreads with Digital Caps/Floors
The example can be run with
python [Link]

and results are in [Link], [Link], exposure_*.csv and the exposure

graphs in mpl_cmsspread.pdf.

5.26 Bootstrap Consistency

The example in folder Examples/Example_26 confirms that bootstrapped curves
correctly reprice the bootstrap instruments (FRAs, Interest Rate Swaps, FX Forwards,
Cross Currency Basis Swaps) using three pricing setups with

56
 • EUR collateral discounting (configuration xois_eur)
• USD collateral discounting (configuration xois_usd)
• in-currency OIS discounting (configuration collateral_inccy)
all defined in Examples/Input/[Link].

The required portfolio files need to be generated from market data and conventions in
Examples/Input and trade templates in Examples/Example_26/Helpers, calling
python [Link]

This will place three portfolio files *_portfolio.xml in the input folder. Thereafter,
the three consistency checks can be run calling
python [Link]

Results are in three files *_npv.csv and should show zero NPVs for all benchmark
instruments.

5.27 BMA Basis Swap

The example in folder Examples/Example_27 demonstrates pricing and sensitivity
analysis for a series of USD Libor 3M vs. Averaged BMA (SIFMA) Swaps that
correspond to the instruments used to bootstrap the BMA curve.
The example can be run with
python [Link]

and results are in [Link] and [Link].

5.28 Discount Ratio Curves

The example in folder Examples/Example_28 shows how to use a yield curve built
from a DiscountRatio segment. In particular, it builds a GBP collateralized in EUR
discount curve by referencing three other discount curves:
• a GBP collateralised in USD curve
• a EUR collateralised in USD curve
• a EUR OIS curve i.e. a EUR collateralised in EUR curve
The implicit assumption in building the curve this way is that EUR/GBP FX forwards
collateralised in EUR have the same fair market rate as EUR/GBP FX forwards
collateralised in USD. This assumption is illustrated in the example by the NPV of the
two forward instruments in the portfolio returning exactly 0 under both discounting
regimes i.e. under USD collateralization with direct curve building and under EUR
collateralization with the discount ratio modified “GBP-IN-EUR” curve.
Also, in this example, an assumption is made that there are no direct GBP/EUR FX
forward or cross currency quotes available which in general is false. The example s
merely for illustration.
Both collateralizaton scenarios can be run calling python [Link].

57
5.29 Curve Building using Fixed vs. Float Cross Currency
Helpers
The example in folder Examples/Example_29 demonstrates using fixed vs. float cross
currency swap helpers. In particular, it builds a TRY collateralised in USD discount
curve using TRY annual fixed vs USD 3M Libor swap quotes.
The portfolio contains an at-market fixed vs. float cross currency swap that is included
in the curve building. The NPV of this swap should be zero when the example is run,
using python [Link] or “directly” calling ore[.exe] [Link].

5.30 USD-Prime Curve Building via Prime-LIBOR Basis Swap

The example in folder Examples/Example_30 demonstrates the implementation of the
USD-Prime index in the ORE. The USD-Prime yield curve is built from USD-Prime vs
USD 3M Libor basis swap quotes. The portfolio consists of two fair basis swaps (NPVs
equal to 0):
• US Dollar Prime Rate vs 3 Month LIBOR
• US Dollar 3 Month LIBOR vs Fed Funds + 0.027
In particular, it is confirmed that the bootstrapped curves USD-FedFunds and
USD-Prime follow the 3% rule observed on the market: U.S. Prime Rate = (The
Fed Funds Target Rate + 3%). (See [Link]
Running ORE in directory Examples/Example_30 with python [Link] yields the
USD-Prime curve in Examples/Example_30/Output/[Link].

5.31 Exposure Simulation using a Close-Out Grid

In the previous examples we have used a “lagged” approach, described at the end of
appendix A.13, to take the Margin Period of Risk into account in exposure modelling.
This has the disadvantage in ORE that we need to use equally-spaced time grids with
time steps that match the MPoR, e.g. 2W, out to final portfolio maturity.
In this example we demonstrate an alternative approach supported by ORE since
release 6. In this approach we use two nested grids: The (almost) arbitrary main
simulation grid is used to compute “default values” which feed into the collateral
balance C(t) filtered by MTA and Threshold etc; an auxiliary “close-out” grid, offset
from the main grid by the MPoR, is used to compute the delayed close-out values V (t)
associated with time default time t. The difference between V (t) and C(t) causes a
residual exposure [V (t) − C(t)]+ even if minimum transfer amounts and thresholds are
zero.
The close-out date value can be computed in two ways in ORE
• as of default date, by just evolving the market from default date to close-out date
(“sticky date”), or
• as of close-out date, by evolving both valuation date and market over the
close-out period (“actual date”), i.e., the portfolio ages and cash flows might
occur in the close-out period causing spikes in the evolution of exposures.

58
We are reusing one case from Example 10 here, perfect CSA with zero threshold and
minimum transfer amount, so that the remaining exposure is solely due to the MPoR
effect. The portfolio consists of a single at-the-money Swap in GBP. The relevant
configuration changes that trigger this modelling are in the Parameters section of
[Link] as shown in Listing 1

Listing 1: Close-out grid specification

<Parameters>
<Grid> ... </Grid>
<Calendar> ... </Calendar>
<Sequence> ... </Sequence>
<Scenario> ... </Scenario>
<Seed> ... </Seed>
<Samples> ... </Samples>
<CloseOutLag> 2W </CloseOutLag>
<MporMode> StickyDate </MporMode><!-- Alternative: ActualDate -->
</Parameters>

and moreover in the XVA analytics section of ore_mpor.xml as shown in Listing 2.

Listing 2: Close-out grid specification

<Analytic type="xva">
...
<Parameter name="calculationType"> NoLag </Parameter>
...
</Parameters>

Run as usual calling python [Link].

5.32 Inflation Swap Exposure under Jarrow-Yildrim

The example here is similar to that in Section 5.17 in that we are generating exposures
for inflation swaps. The example in Section 5.17 uses the Dodgson-Kainth model
whereas this example uses the Jarrow-Yildrim model. The valuation date is 2 Nov
2020 and the portfolio contains four spot starting inflation swaps:
• trade_01: 20Y standard UKRPI ZCIIS struck at the fair market rate of 3.1925%
giving an NPV of 0.0.
• trade_02: 20Y standard EUHICPXT ZCIIS struck at the fair market rate of
1.16875% giving an NPV of 0.0.
• trade_03: 20Y year on year EUHICPXT swap.
• trade_04: 20Y year on year UKRPI swap.
The example generates cash flows, NPVs, exposure evolutions and XVAs.

59
5.33 CDS Exposure Simulation
The example in folder Examples/Example_33 is the credit variant of the example in
5.1. Running ORE in directory Examples/Example_33 with
python [Link]

yields the exposure evolution in

Examples/Example_33/Output/*.pdf

and shown in figure 28. Both CDS simulation and CDS Option pricing are run with

Example 35 - Simulated exposures vs analytical cds option prices

CDS EPE
CDS ENE
80,000 NPV CDS Ooptions

60,000
Exposure

40,000

20,000

0
0 1 2 3 4 5
Time / Years

Figure 28: Credit Default Swap expected exposure in a flat market environment from both
parties’ perspectives. The symbols are CDS Option prices. The simulation was run with bi-
weekly time steps and 10,000 Monte Carlo samples to demonstrate the convergence of EPE and
ENE profiles. A similar outcome can be obtained more quickly with 5,000 samples on a monthly
time grid which is the default setting of Example_33.

calls to the ORE executable, essentially

ore[.exe] [Link]
ore[.exe] ore_cds_option.xml

which are wrapped into the script Examples/Example_33/[Link] provided with the
ORE release.
This example demonstrates credit simulation using the LGM model and the
calculation of Wrong Way Risk due to credit correlation between the underlying entity
of the CDS and the counterparty of the CDS trade via dynamic credit. Positive
correlation between the two names weakens the protection of the CDS whilst negative
correlation strengthens the protection.
The following table lists the XVA result from the example at different levels of
correlation.

5.34 Wrong Way Risk

The example in folder Examples/Example_34 is an extension of the example in 5.1
with dynamic credit and IR-CR correlation. As we are paying float, negative
correlation implies that we pay more when the counterparty’s credit worsens, leading
to a surge of CVA.

60
 Correlation NettingSetId CVA DVA FBA FCA
-100% CPTY_B -2,638 2,906 486 -1,057
-90% CPTY_B -2,204 2,906 488 -1,053
-50% CPTY_B -485 2,906 493 -1,040
-40% CPTY_B -60 2,906 495 -1,037
-30% CPTY_B 363 2,906 496 -1,033
-20% CPTY_B 784 2,906 498 -1,030
-10% CPTY_B 1,204 2,906 500 -1,027
0% CPTY_B 1,621 2,906 501 -1,023
10% CPTY_B 2,036 2,906 503 -1,020
20% CPTY_B 2,450 2,906 504 -1,017
30% CPTY_B 2,861 2,906 506 -1,013
40% CPTY_B 3,271 2,906 507 -1,010
50% CPTY_B 3,679 2,906 509 -1,017
90% CPTY_B 5,290 2,906 515 -994
100% CPTY_B 5,689 2,906 517 -991

Table 6: CDS XVA results with LGM model

The following table lists the XVA result from the example at different levels of
correlation.
Correlation NettingSetId CVA DVA FBA FCA
-30% CPTY_A 105,146 68,061 31,519 -4,127
-20% CPTY_A 88,442 68,061 30,976 -4,219
-10% CPTY_A 71,059 68,061 30,439 -4,314
0% CPTY_A 52,983 68,061 29,909 -4,411
10% CPTY_A 34,199 68,061 29,386 -4,511
20% CPTY_A 14,691 68,061 28,869 -4,614
30% CPTY_A -5,554 68,061 28,360 -4,719

Table 7: IR Swap XVA results with LGM model

5.35 Flip View

The example in folder Examples/Example_35 demonstrates how ORE can be used to
quickly switch perspectives in XVA calculations with minimal changes in the [Link]
file only. In particular it does not involve manipulating the portfolio input or the
netting set.

5.36 Choice of Measure

The example in folder Examples/Example_36 illustrates the effect of measure changes
on simulated expected and peak exposures. For that purpose we reuse Example 1
(un-collateralized vanilla swap exposure) and run the simulation three times with
different risk-neutral measures,
• in the LGM measure as in Example 1 (note <Measure>LGM</Measure> in
simulation_lgm.xml, this is the default also if the Measure tag is omitted)
• in the more common Bank Account measure (note <Measure>BA</Measure> in
simulation_ba.xml)
• in the T-Forward measure with horizon T=20 at the Swap maturity (note
<Measure>LGM</Measure> and <ShiftHorizon>20.0</ShiftHorizon> in
simulation_fwd.xml)
The results are summarized in the exposure evolution graphs in figure 29. As expected,
the expected exposures evolutions match across measures, as these are expected

61
discounted NPVs and hence measure independent. However, peak exposures are
dependent on the measure choice as confirmed graphically here. Many more measures
are accessible with ORE, by way of varying the T-Forward horizon which was chosen
arbitrarily here to match the Swap’s maturity.

Example 36
PFE LGM
PFE BA
2,500,000 PFE FWD
EPE LGM
EPE BA
2,000,000 EPE FWD
Exposure

1,500,000

1,000,000

500,000

0
0.0 2.5 5.0 7.5 10.0 12.5 15.0 17.5 20.0
Time / Years

Figure 29: Evolution of expected exposures (EPE) and peak exposures (PFE at the 95% quantile)
in three measures, LGM, Bank Account, T-Forward with T=20, with 10k Monte Carlo samples.

5.37 Multifactor Hull-White Scenario Generation

The example in folder Examples/Example_37 illustrates the scenario generation under
a Hull-White multifactor model. The model is driven by two independent Brownian
motions and has four states. The diffusion matrix sigma is therefore 2 x 4. The
reversion matrix is a 4 x 4 diagonal matrix and entered as an array. Both diffusion and
reversion are constant in time. Their values are not calibrated to the option market,
but hardcoded in [Link].
The values for the diffusion and reversion matrices were fitted to the first two principal
components of a (hypothetical) analyis of absolute rate curve movements. These input
principal components can be found in [Link] in the input folder. The
tenor is given in years, and the two components are given as column vectors, see table
8.
tenor eigenvector 1 eigenvector 2
1 0.353553390593 -0.537955502871
2 0.353553390593 -0.374924478795
3 0.353553390593 -0.252916811525
5 0.353553390593 -0.087587539893
10 0.353553390593 0.12267800393
15 0.353553390593 0.240659435416
20 0.353553390593 0.339148675322
30 0.353553390593 0.552478951238
Table 8: Input principal components

The first eigenvector represent perfectly parallel movements. The second eigenvector
represent a rotation around the 7y point of the curve. Furthermore we prescribe an
annual volatility of 0.0070 for the first components and 0.0030 for the second one. The
values can be compared to normal (bp) volatilities.

62
We follow [25] chapter 12.1.5 “Multi-Factor Statistical Gaussian Model” to calibrate
the diffusion and reversion matrices to the prescribed components and volatilities. We
do not detail the procedure here and refer the interested reader to the given reference.
The example generates a single monte carlo path with 5000 daily steps and outputs
the generated scenarios in [Link]. The python script [Link] performs a
principal component analysis on this output. The model implied eigenvalues are given
in table 9.

number value
1 4.9144936649319346e-05
2 8.846877641067412e-06
3 5.82566039467854e-10
4 2.1298948225571415e-10
5 9.254913949332787e-11
6 1.0861256211767673e-11
7 8.478795662698618e-14
8 9.74468069377584e-13
Table 9: Input principal components

Only the first two values are relevant, the following are all close to zero. The square
root of the first two eigenvalues is given in table 10.

number sqrt(value)
1 0.007010344973631422
2 0.0029743701250966414
Table 10: Input principal components

matching the prescribed input values of 0.0070 and 0.0030 quite well. The
correpsonding eigenvectors are given in etable 11.

tenor eigenvector 1 eigenvector 2

1 0.34688826736335926 0.5441204725042812
2 0.3489303472083185 0.380259707350115
3 0.350362134519783 0.2581408080614405
5 0.3523983915961889 0.09230899007104967
10 0.3550169593982022 -0.11856777284904292
15 0.35647835947136625 -0.23676104168229614
20 0.3577146190751303 -0.3354486339442275
30 0.36042236352102563 -0.549124709243042
Table 11: Input principal components

again matching the input principal components quite well. The second eigenvector is
the negative of the input vector here (the principal compoennt analysis can not
distinguish these of course).
The example also produces a plot comparing the input eigenvectors and the model
implied eigenvectors as shown in figure 30.

63
 Example 37 - Model implied principal components vs. input principal components
0.6

0.4

0.2
Model Eigenvector 1
Model Eigenvector 2
0.0
shift

Input Eigenvector 1
Input Eigenvector 2
0.2

0.4

0.6
0 5 10 15 20 25 30
Time / Years

Figure 30: Input and model implied eigenvectors for a Hull-White 4-factor model calibrated to
2 principal components of rate curve movements (parallel + rotation). Notice that the model
implied 2nd eigenvector is the negative of the input vector.

5.38 Cross Currency Swap Exposure using Multifactor

Hull-White Models
The example in folder Examples/Example_38 is similar to Example 8 (EPE, ENE for
xccy swap), but uses a multifactor HW model for EUR and USD to generate scenarios.
The parametrization of the HW models is taken from Example 37.
Each of the two factors of each HW model is correlated with each of the two factors of
the other currency’s HW model and with the FX factors. Remember that the factors
represent principal components of interest rate movements and so the correlations can
be interpreted as correlations of these principal components with each other and the fx
rate processes.

5.39 Exposure Simulation using American Monte Carlo

The example in folder Examples/Example_39 demonstrates how to use American
Monte Carlo simulation (AMC) to generate exposures in ORE. For a sketch of the
methodology and comments on its implementation in ORE see appendix A.5.
Calling
python [Link]

performs two ORE runs, a ’classical’ exposure simulation and an American Monte
Carlo simulation, both on a quarterly simulation grid and for the same portfolio
consisting of four trades:
• Bermudan swaption
• Single Currency Swap
• Cross Currency Swap
• FX Option

64
 Example 39 - Simulated exposure for 10y10y EUR Bermudan Payer Swaption
AMC Swaption EPE
50,000 AMC Swaption ENE
Classic Swaption EPE
Classic Swaption ENE
40,000

30,000
Exposure
20,000

10,000

0
0 5 10 15 20
Time / Years

Figure 31: EPE of a EUR Bermudan Swaption computed with the classic and AMC valuation
engines, using 50k training paths for the AMC simulation.

We use a ’flat’ market here (yield curve and Swaption volatility surface). The number
of simulation paths is 2k in the classic simulations. If not stated otherwise below, the
number of training paths and simulation paths is 10k in the AMC simulations.
In the following we compare the AMC exposure profiles to those produced by the
’classic’ valuation engine for each trade and the netting set.
Figure 31 shows the EPE and ENE for a Bermudan Swaption 10y into 10y in (base
ccy) EUR with physical settlement. The classic run uses the LGM grid engine for
valuation. We observe close agreement between the two runs. To achieve the observed
agreement, it is essential to set the LGM model’s mean reversion speed to zero in both
• the Bermudan Swaption LGM pricing model (see Input/[Link]), and
• the Cross Asset Model’s IR model components (see Input/[Link] and
Input/simulation_amc.xml)
and to use a high order 6 of the regression polynomials (see
Input/pricingengine_amc.xml).
Figure 32 shows the EPE and ENE for a 20y vanilla Swap in USD. The currency of the
amc calculator is USD in this case, i.e. it is different from the base ccy of the
simulation (EUR). The consistency of the classic and amc runs in particular
demonstrates the correct application of the currency conversion factor 27. To get a
better accuracy for purposes of the plot in this document we increased the number of
training paths for this example to 50k and the order of the basis functions to 6.
Figure 33 shows the EPE and ENE for a 20y cross currency Swap EUR-USD.
Figure 34 shows the EPE and ENE for a vanilla FX Option EUR-USD with 10y1m
expiry. For the classic run the FX volatility surface is not implied by the cross asset
model but kept flat, which yields a slight hump in the profile. The AMC profile is flat
on the other hand which demonstrates the consistency of the FX Option pricing with
the risk factor evolution model.

Analytic Configuration
To use the AMC engine for an XVA simulation the following needs to be added to the
simulation analytic in [Link]:

65
 Example 39 - Simulated exposure for 20y EUR Payer Swap
AMC Vanilla Swap USD EPE
700,000 AMC Vanilla Swap USD ENE
Classic Vanilla Swap USD EPE
600,000 Classic Vanilla Swap USD ENE

500,000
Exposure

400,000

300,000

200,000

100,000

0
0 5 10 15 20
Time / Years

Figure 32: EPE of a USD swap computed with the classic and AMC valuation engines

Example 39 - Simulated exposure for XCcy Swap EUR-USD

AMC XCcy Swap EPE
35,000,000 AMC XCcy Swap ENE
Classic XCcy Swap EPE
30,000,000 Classic XCcy Swap ENE

25,000,000
Exposure

20,000,000

15,000,000

10,000,000

5,000,000

0
0 5 10 15 20
Time / Years

Figure 33: EPE of a EUR-USD cross currency swap computed with the classic and AMC
valuation engines

Example 39 - Simulated exposure for FX Call Option EUR-USD

AMC FX Call Option EPE
AMC FX Call Option ENE
250,000 Classic FX Call Option EPE
Classic FX Call Option ENE
200,000
Exposure

150,000

100,000

50,000

0
0 5 10 15 20
Time / Years

Figure 34: EPE of a EUR-USD FX option computed with the classic and AMC valuation
engines

66
<Analytic type="simulation">
...
<Parameter name="amc">Y</Parameter>
<Parameter name="amcPricingEnginesFile">pricingengine_amc.xml</Parameter>
<Parameter name="amcTradeTypes">Swaption</Parameter>
...
</Analytic>

The trades which have a trade type matching one of the types in the amcTradeTypes
list, will be built against the pricing engine config provided and processed in the AMC
engine. As a naming convention, pricing engines with engine type AMC provide the
required functionality to be processed by the AMC engine, for technical details cf. A.5.
All other trades are processed by the classic simulation engine in ORE. The resulting
cubes from the classic and AMC simulation are joined and passed to the post processor
in the usual way.
Note that since sometimes the AMC pricing engines have a different base ccy than the
risk factor evolution model (see below), a horizon shift parameter in the simulation set
up should be set for all currencies, so that the shift also applies to these reduced
models.

Pricing Engine Configuration

At this point we assume that the reader is generally familiar with the configuration
section 7, in particular pricing engine configuration in section 7.3.
The pricing engine configuration is similar for all AMC enabled products, e.g. for
Bermudan Swaptions:

<Product type="BermudanSwaption">
<Model>LGM</Model>
<ModelParameters/>
<Engine>AMC</Engine>
<EngineParameters>
<Parameter name="[Link]">MersenneTwisterAntithetic</Parameter>
<Parameter name="[Link]">42</Parameter>
<Parameter name="[Link]">50000</Parameter>
<Parameter name="[Link]">Monomial</Parameter>
<Parameter name="[Link]">6</Parameter>
<Parameter name="[Link]">SobolBrownianBridge</Parameter>
<Parameter name="[Link]">17</Parameter>
<Parameter name="[Link]">0</Parameter>
<Parameter name="BrownianBridgeOrdering">Steps</Parameter>
<Parameter name="SobolDirectionIntegers">JoeKuoD7</Parameter>
<Parameter name="MinObsDate">true</Parameter>
<Parameter name="RegressionOnExerciseOnly">false</Parameter>
</EngineParameters>
</Product>

The Model differs by product type, table 12 summarises the supported product types
and model and engine types. The engine parameters are the same for all products:
1. [Link]: The sequence type for the traning phase, can be
MersenneTwister, MersenneTwisterAntithetc, Sobol, Burley2020Sobol,
SobolBrownianBridge, Burley2020SobolBrownianBridge
2. [Link]: The seed for the random number generation in the training
phase

67
 3. [Link]: The number of samples to be used for the training phase
4. [Link]: The sequence type for the pricing phase, same values
allowed as for training
5. [Link]: The type of basis function system to be used for the
regression analysis, can be Monomial, Laguerre, Hermite, Hyperbolic,
Legendre, Chbyshev, Chebyshev2nd
6. BasisFunctionOrder: The order of the basis function system to be used
7. [Link]: The seed for the random number generation in the pricing
8. [Link]: The number of samples to be used for the pricing phase. If
this number is zero, no pricing run is performed, instead the (T0) NPV is
estimated from the training phase (this result is used to fill the T0 slice of the
NPV cube)
9. BrownianBridgeOrdering: variate ordering for Brownian bridges, can be Steps,
Factors, Diagonal
10. SobolDirectionIntegers: direction integers for Sobol generator, can be Unit,
Jaeckel, SobolLevitan, SobolLevitanLemieux, JoeKuoD5, JoeKuoD6,
JoeKuoD7, Kuo, Kuo2, Kuo3
11. MinObsDate: if true the conditional expectation of each cashflow is taken from
the minimum possible observation date (i.e. the latest exercise or simulation date
before the cashflow’s event date); recommended setting is true
12. RegressionOnExerciseOnly: if true, regression coefficients are computed only
on exercise dates and extrapolated (flat) to earlier exercise dates; only for
backwards compatibility to older versions of the AMC module, recommended
setting is false

Product Type Model Engine

Swap CrossAssetModel AMC
CrossCurrencySwap CrossAssetModel AMC
FxOption CrossAssetModel AMC
BermudanSwaption LGM AMC
MultiLegOption CrossAssetModel AMC
Table 12: AMC enabled products with engine and model types

Additional Features
As a side product the AMC module provides plain MC pricing engines for Bermudan
Swaptions and a new trade type MultiLegOption with a corresponding MC pricing
engine.

MC pricing engine for Bermudan swaptions

The following listing shows a sample configuration for the MC Bermudan Swaption
engine. The model parameters are identical to the LGM Grid engine configuration.
The engine parameters on the other hand are the same as for the AMC engine, see 5.39.

68
<Product type="BermudanSwaption">
<Model>LGM</Model>
<ModelParameters>
<Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalDealStrike</Parameter>
<Parameter name="Reversion_EUR">0.0050</Parameter>
<Parameter name="Reversion_USD">0.0030</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="VolatilityType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">1.0</Parameter>
</ModelParameters>
<Engine>MC</Engine>
<EngineParameters>
<Parameter name="[Link]">MersenneTwisterAntithetic</Parameter>
<Parameter name="[Link]">42</Parameter>
<Parameter name="[Link]">10000</Parameter>
<Parameter name="[Link]">Monomial</Parameter>
<Parameter name="[Link]">6</Parameter>
<Parameter name="[Link]">SobolBrownianBridge</Parameter>
<Parameter name="[Link]">17</Parameter>
<Parameter name="[Link]">25000</Parameter>
<Parameter name="BrownianBridgeOrdering">Steps</Parameter>
<Parameter name="SobolDirectionIntegers">JoeKuoD7</Parameter>
</EngineParameters>
</Product>

Multi Leg Options / MC pricing engine

The following listing shows a sample MultiLegOption trade. It consists of
1. an option data block; this is optional, see below
2. a number of legs; in principle all leg types are supported, the number of legs is
arbitrary and they can be in different currencies; if the payment currency of a leg
is different from a floating index currency, this is interpreted as a quanto payoff
If the option block is given, the trade represents a Bermudan swaption on the
underlying legs. If the option block is missing, the legs themselves represent the trade.
See A.5.1 for limitations of the multileg option pricing engine.

<Trade id="Sample_MultiLegOption">
<TradeType>MultiLegOption</TradeType>
<Envelope>...</Envelope>
<MultiLegOptionData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>Bermudan</Style>
<Settlement>Physical</Settlement>
<PayOffAtExpiry>false</PayOffAtExpiry>
<ExerciseDates>
<ExerciseDate>2026-02-25</ExerciseDate>
<ExerciseDate>2027-02-25</ExerciseDate>
<ExerciseDate>2028-02-25</ExerciseDate>
</ExerciseDates>
</OptionData>
<LegData>
<LegType>Floating</LegType>
<Payer>false</Payer>
<Currency>USD</Currency>
<Notionals>
<Notional>100000000</Notional>
</Notionals>
...

69
 </LegData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>100000000</Notional>
</Notionals>
...
</LegData>
</MultiLegOptionData>
</Trade>

The pricing engine configuration is similar to that of the MC Bermudan swaption

engine, cf. 5.39, also see the following listing.

<Product type="MultiLegOption">
<Model>CrossAssetModel</Model>
<ModelParameters>
<Parameter name="Tolerance">0.0001</Parameter>
<!-- IR -->
<Parameter name="IrCalibration">Bootstrap</Parameter>
<Parameter name="IrCalibrationStrategy">CoterminalATM</Parameter>
<Parameter name="ShiftHorizon">1.0</Parameter>
<Parameter name="IrReversion_EUR">0.0050</Parameter>
<Parameter name="IrReversion_GBP">0.0070</Parameter>
<Parameter name="IrReversion_USD">0.0080</Parameter>
<Parameter name="IrReversion">0.0030</Parameter>
<Parameter name="IrReversionType">HullWhite</Parameter>
<Parameter name="IrVolatilityType">HullWhite</Parameter>
<Parameter name="IrVolatility">0.0050</Parameter>
<!-- FX -->
<Parameter name="FxCalibration">Bootstrap</Parameter>
<Parameter name="FxVolatility_EURUSD">0.10</Parameter>
<Parameter name="FxVolatility">0.08</Parameter>
<Parameter name="ExtrapolateFxVolatility_EURUSD">false</Parameter>
<Parameter name="ExtrapolateFxVolatility">true</Parameter>
<!-- Correlations IR-IR, IR-FX, FX-FX -->
<Parameter name="Corr_IR:EUR_IR:GBP">0.80</Parameter>
<Parameter name="Corr_IR:EUR_FX:GBPEUR">-0.50</Parameter>
<Parameter name="Corr_IR:GBP_FX:GBPEUR">-0.15</Parameter>
</ModelParameters>
<Engine>MC</Engine>
<EngineParameters>
<Parameter name="[Link]">MersenneTwisterAntithetic</Parameter>
<Parameter name="[Link]">42</Parameter>
<Parameter name="[Link]">10000</Parameter>
<Parameter name="[Link]">SobolBrownianBridge</Parameter>
<Parameter name="[Link]">17</Parameter>
<Parameter name="[Link]">25000</Parameter>
<Parameter name="[Link]">Monomial</Parameter>
<Parameter name="[Link]">4</Parameter>
<Parameter name="BrownianBridgeOrdering">Steps</Parameter>
<Parameter name="SobolDirectionIntegers">JoeKuoD7</Parameter>
</EngineParameters>
</Product>

Model Parameters special to that product are

1. IrCalibrationStrategy can be None, CoterminalATM, UnderlyingATM
2. FXCalibration can be None or Bootstrap
3. ExtrapolateFxVolatility can be true or false; if false, no calibration
instruments are used that require extrapolation of the market fx volatilty surface
in option expiry direction
4. Corr_Key1_Key2: These entries describe the cross asset model correlations to be

70
 used; the syntax for Key1 and Key2 is the same as in the simulation configuration
for the cross asset model

5.40 Par Sensitivity Analysis

The example in folder Examples/Example_40 demonstrates ORE’s par sensitivity
analysis (e.g. to Swap rates) that is implemented by means of a Jacobi transformation
of the "raw" sensitivities (e.g. to zero rates), see a sketch of the methodology in
appendix A.16 and section 7.5 for configuration details.
To perform a par sensitivity analysis, the following required change in [Link] is
required

<Analytic type="sensitivity">
<Parameter name="active">Y</Parameter>
<Parameter name="marketConfigFile">[Link]</Parameter>
<Parameter name="sensitivityConfigFile">[Link]</Parameter>
<Parameter name="pricingEnginesFile">../../Input/[Link]</Parameter>
<Parameter name="scenarioOutputFile">sensi_scenarios.csv</Parameter>
<Parameter name="sensitivityOutputFile">[Link]</Parameter>
<Parameter name="outputSensitivityThreshold">0.000001</Parameter>
<!-- Additional parametrisation for par sensitivity analysis -->
<Parameter name="parSensitivity">Y</Parameter>
<Parameter name="parSensitivityOutputFile">[Link]</Parameter>
<Parameter name="outputJacobi">Y</Parameter>
<Parameter name="jacobiOutputFile">[Link]</Parameter>
<Parameter name="jacobiInverseOutputFile">jacobi_inverse.csv</Parameter>
</Analytic>

The portfolio used in this example includes products sensitive to

• Discount and index curves
• Credit curves
• Inflation curves
• CapFloor volatilities
The usual sensitivity analysis is performed by bumping the "raw" rates (zero rates,
hazard rates, inflation zero rates, optionlet vols). This is followed by the Jacobi
transformation that turns "raw" sensitivities into sensitivities in the par domain
(Deposit/FRA/Swap rates, FX Forwards, CC Basis Swap spreads, CDS spreads, ZC
and YOY Inflation Swap rates, flat Cap/Floor vols). The conversion is controlled by
the additional ParConversion data blocks in [Link] where the assumed
par instruments and corresponding conventions are coded, as shown below for three
types of discount curves.

<DiscountCurves>

<DiscountCurve ccy="EUR">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
<ShiftTenors>2W,1M,3M,6M,9M,1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,25Y,30Y</ShiftTenors>
<ParConversion>
<!--DEP, FRA, IRS, OIS, FXF, XBS -->
<Instruments>OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS</Instruments>
<SingleCurve>true</SingleCurve>
<Conventions>
<Convention id="OIS">EUR-OIS-CONVENTIONS</Convention>
</Conventions>

71
 </ParConversion>
</DiscountCurve>

<DiscountCurve ccy="USD">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
<ShiftTenors>2W,1M,3M,6M,9M,1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,25Y,30Y</ShiftTenors>
<ParConversion>
<Instruments>FXF,FXF,FXF,FXF,FXF,XBS,XBS,XBS,XBS,XBS,XBS,XBS,XBS,XBS,XBS,XBS</Instruments>
<SingleCurve>true</SingleCurve>
<Conventions>
<Convention id="XBS">EUR-USD-XCCY-BASIS-CONVENTIONS</Convention>
<Convention id="FXF">EUR-USD-FX-CONVENTIONS</Convention>
</Conventions>
</ParConversion>

<DiscountCurve ccy="GBP">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
<ShiftTenors>2W,1M,3M,6M,9M,1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,25Y,30Y</ShiftTenors>
<ParConversion>
<Instruments>DEP,DEP,DEP,DEP,DEP,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS</Instruments>
<SingleCurve>true</SingleCurve>
<Conventions>
<Convention id="DEP">GBP-DEPOSIT</Convention>
<Convention id="IRS">GBP-6M-SWAP-CONVENTIONS</Convention>
</Conventions>
</ParConversion>
</DiscountCurve>

</DiscountCurves>

Finally note that par sensitivity analysis requires that the shift tenor grid in the
sensitivity data above matches the corresponding grid in the simulation (market)
configuration. See also section 7.5.

5.41 Multi-threaded Exposure Simultion

The example in folder Examples/Example_41 demonstrates the multithreaded
valuation engine to generate the exposure for a portfolio of 8 copies of the vanilla swap
in Example_1.

5.42 ORE Python Module

Since release 9 (March 2023) we provide easy access to ORE via a pre-compiled
Python module. Some example scripts using this ORE module are provided in this
example, so change to this directory first

cd Example_42

The examples require Python 3. The ORE Python module is then installed with a
one-liner, see step 3 below. However, to separate ORE from any other Python
environments on your machine, we recommend creating a virtual environment first. In
that case the steps are as follows.
1. To create a virtual environment: python -m venv env1
2. To activate this environment on Windows: .\env1\Scripts\[Link]
or on macOS/Linux: ./env1/bin/activate
3. Then install the latest release of ORE:

72
 pip install open-source-risk-engine
4. Try examples:
• python [Link]
This demonstrates the Python-wrapped version of the ORE application that
is also used in the command line application [Link]. We use it here to
re-run the Swap exposure of Example_1.
• python [Link]
This extends the previous example and shows how to access and
post-process ORE in-memory results in the Python framework without
reading files.
• python [Link]
The ORE Python module also allows lower-level access to the QuantLib and
QuantExt libraries, demonstrated here for a CommodityForward instrument
defined in QuantExt. Note that the ORE Python module contains the
entire QuantLib Python functionality.
More use cases of the ORE Python module including Jupyter notebooks can be
found in the ORE SWIG repository, in particular in folder
OREAnalytics-SWIG/Python/Examples.
5. You can deactivate the environment with deactivate
or even fully remove the environment again by removing the env1 folder.
Finally, you can build the Python module and installable packages yourself following
the instructions in sections 4.4 based on your local ORE code.

5.43 Credit Portfolio Model

The purpose of the credit portfolio model in ORE is to generate an integrated portfolio
gain/loss distribution at a given future horizon which is driven by
• credit defaults and rating migrations in Bonds and CDS, and
• the PnL of a portfolio of derivatives over the specified time horizon.
The model integrates Credit and Market Risk by jointly evolving systemic credit risk
drivers alongside the usual risk factors in ORE’s Cross Asset Model. See also the
separate documentation in Docs/UserGuide/[Link].
By running
python [Link]

this example demonstrates the model’s outcome for seven demo portfolios

73
 Case Credit Mode Exposure Mode Evaluation
Single Bond Migration Value Analytic
Bond and Swap Migration Value Analytic
3 Bonds Migration Value Analytic
10 Bonds Migration Value Analytic
10 Bonds Migration Value Terminal Simulation
Bonds and CDS Migration Notional Analytic
100 Bonds Default Notional Analytic
The last demo case in this table can be activated by uncommenting the corresponding
section at the end of the [Link] script.

5.44 Initial Margin: ISDA SIMM and IM Schedule

This example demonstrates the calculation of initial margin using ISDA’s Standard
Initial Margin Model (SIMM) based on a provided sensitivity file in ISDA’s Common
Risk Interchange Format (CRIF). In addition, we show how to use the standard "IM
Schdule" method to compute initial margin.
ORE covers all SIMM versions since inception to date, i.e. 1.0, 1.1, 1.2, 1.3, 1.3.38, 2.0,
2.1, 2.2, 2.3, 2.4 (=2.3.8), 2.5, 2.5A, 2.6 (=2.5.6). All versions have been tested against
the respective ISDA SIMM model unit test suites and pass these tests. Any new SIMM
versions will be added with each ORE release.
For SIMM versions >= 2.2 we support SIMM calculation for both MPoR horizons, 1d
and 10d.
Note that you need to purchase a SIMM model license from ISDA if you want to use
the model in production, and the unit test suites mentioned above are provided to
licensed vendors only. Therefore we unfortunately cannot share our ORE SIMM model
test suite here either.
By running
python [Link]

ORE will pick up the small example CRIF file in Input/[Link] (i.e. par sensitivities
rebucketed and reformatted to match the ISDA CRIF template) and generate the
resulting SIMM report in a [Link] file. This report shows ISDA SIMM results with
the usual breakdown by product class, risk class, margin type, bucket and SIMM “side”
(IM to call or post). The SIMM calculation in this example is done for SIMM version
2.4 and 2.6, with MPoR 1d and 10d:
• SIMM 2.4, 1-day MPoR
• SIMM 2.4, 10-day MPoR
• SIMM 2.6, 1-day MPoR
• SIMM 2.6, 10-day MPoR

There are four SIMM-related input files – ore_SIMM2.4_1D.xml,

ore_SIMM2.4_10D.xml, ore_SIMM2.6_1D.xml, ore_SIMM2.6_10D.xml – with
corresponding folders in the Output/ directory. The relevant inputs in the files are:

74
 • SIMM version
• name of the CRIF file to be loaded
• calculation currency - this determines which Risk_FX entries of the CRIF will
be ignored in the SIMM calculation
• result currency (optional) - currency of the resulting SIMM amounts in the
report, by default equal to the calculation currency
• MPoR horizon, in terms of days
The market data input and todays’s market configuration required here is minimal -
limited to FX rates for conversions from base/calculation currency into USD and into
the result currency.

If the ORE Python module is installed, as shown in Example 42, then you can also run
the SIMM example using
python [Link]

IM Schedule
As an additonal case in this example we demonstrate how to use the IM Schedule
method to compute initial margin. The related input file is Input/ore_schedule.xml.
It is also run when calling python [Link], and results are written to folder
Output/IM_SCHEDULE. The basic input is provided in CRIF file format where ORE
expects two lines per trade, one with RiskClass = PV and one with RiskClass =
Notional, so that the amounts in these CRIF lines are interpeted as NPV respectively
notional. Further required columns are product class and end date, as shown in the
example Input/crif_schedule.csv. Note that the product class has to be in
• Rates
• FX
• Equity
• Credit
• Commodity
in contrast to SIMM where we use the combined RatesFX.
To run the IM Schedule analytic, the following minimal addition to
Input/ore_schedule.xml is required.

<Analytics>
<Analytic type="imschedule">
<Parameter name="active">Y</Parameter>
<Parameter name="crif">crif_schedule.csv</Parameter>
<Parameter name="calculationCurrency">USD</Parameter>
</Analytic>
</Analytics>

75
5.45 Collateralized Bond Obligation
This example in folder Examples/Example_45 demonstrates a Cashflow CDO or
Collateralized Bond Obligation (CBO) via ORE. Calling
python [Link]

will launch a single ORE run to process a CBO example, referencing underyling bond
portfolio of 20 trades. The CBO is represented by a CBO reference datum specified in
the reference data file. NPV results are calculated for the investment in the junior
tranche.

5.46 Generic Total Return Swap

This example in folder Examples/Example_46 demonstrates ORE’s generic Total
Return Swap referencing a CBO. Calling
python [Link]

will launch a single ORE run to process a TRS example and to generate NPV and cash
flows in the usual result files. As opposed to example 45, the CBO and its bondbasket
are represented explicitly in the CBO node.

5.47 Composite Trade

This example in folder Examples/Example_47 demonstrates the input of ORE’s
Composite Trade that can consist on any number and type of products covered by
ORE. In this case the composite consists of two Equity Swaps. Calling
python [Link]

runs ORE and generates an NPV report.

5.48 Convertible Bond and ASCOT

This example in folder Examples/Example_48 demonstrates the input of
• a ConvertibleBond trade
• a related Asset Swapped Convertible Option Transaction (ASCOT)
• a vanilla Swap that represents the package of Convertible Bond position and
ASCOT
Calling
python [Link]

runs ORE and generates an NPV report.

5.49 Bond Yield Shifted

The example in folder Examples/Example_49 shows how to use a yield curve built
from a BondYieldShifted segment, as described in section 7.8.1.

76
In particular, it builds the curve [Link].CURVE_SHIFTED shifted by three liquid
Bonds:
• Fixed rate USD Bond maturing in August 2023 with id EJ7706660.
• Fixed rate USD Bond maturing in September 2049 with id ZR5330686.
• Floating Rate Bond maturing in May 2025 with id AS064441.
The resulting curve is exhibited in the [Link] output file. Moreover, the results
can be crosschecked against the NPVs, i.e. prices, of the ZeroBonds comprised in the
portfolio.
• ZeroBond_long, maturing 2052-03-01 shows a price of 0.2080 akin to the 0.2080
in the curves output at the same date.
• ZeroBond_short, maturing 2032-06-01 shows a price of 0.5808 aktin to the 0.808
in the curves output at the same date.
The example can be run calling python [Link].

5.50 Zero to Par sensitivity Conversion Analysis

The example in folder Examples/Example_50 demonstrates ORE’s capability to
convert external computed zero sensitivities (e.g Zero rates) to par sensitivities (e.g. to
Swap rates) that is implemented by means of a Jacobi transformation of the "raw"
sensitivities (e.g. to zero rates), see a sketch of the methodology in appendix A.16 and
section 7.5 for configuration details.
To perform a par sensitivity analysis, the following required change in [Link] is
required

<Analytic type="zeroToParSensiConversion">
<Parameter name="active">Y</Parameter>
<Parameter name="marketConfigFile">[Link]</Parameter>
<Parameter name="sensitivityConfigFile">[Link]</Parameter>
<Parameter name="pricingEnginesFile">../../Input/[Link]</Parameter>
<!-- Input file with the raw sensitivities -->
<Parameter name="sensitivityInputFile">[Link]</Parameter>
<Parameter name="idColumn">TradeId</Parameter>
<Parameter name="riskFactorColumn">Factor_1</Parameter>
<Parameter name="deltaColumn">Delta</Parameter>
<Parameter name="currencyColumn">Currency</Parameter>
<Parameter name="baseNpvColumn">Base NPV</Parameter>
<Parameter name="shiftSizeColumn">ShiftSize_1</Parameter>
<Parameter name="outputThreshold">0.000001</Parameter>
<Parameter name="outputFile">parconversion_sensitivity.csv</Parameter>
<Parameter name="outputJacobi">Y</Parameter>
<Parameter name="jacobiOutputFile">[Link]</Parameter>
<Parameter name="jacobiInverseOutputFile">jacobi_inverse.csv</Parameter>
</Analytic>

The portfolio used in this example includes zero sensitivities of

• Discount and index curves
• Credit curves
• Inflation curves
• CapFloor volatilities

77
ORE reads the raw sensitivites from the csv input file *sensitivityInputFile*. The
input file needs to have six columns, the column names can be user configured. Here is
a description of each of the columns:
1. idColumn : Column with a unique identifier for the trade / nettingset / portfolio.
2. riskFactorColumn: Column with the identifier of the zero/raw sensitiviy. The
risk factor name needs to follow the ORE naming convention, e.g.
DiscountCurve/EUR/5/1Y (the 6th bucket in EUR discount curve as specified in
the [Link])
3. deltaColumn: The raw sensitivity of the trade/nettingset / portfolio with respect
to the risk factor
4. currencyColumn: The currency in which the raw sensitivity is expressed, need to
be the same as the BaseCurrency in the simulation settings.
5. shiftSizeColumn: The shift size applied to compute the raw sensitivity, need to
be consistent to the sensitivity configuration.
6. baseNpvColumn: The base npv of the trade / nettingset / portfolio in currency.
This is followed by the Jacobi transformation that turns "raw" sensitivities into
sensitivities in the par domain (Deposit/FRA/Swap rates, FX Forwards, CC Basis
Swap spreads, CDS spreads, ZC and YOY Inflation Swap rates, flat Cap/Floor vols).
The conversion is controlled by the additional ParConversion data blocks in
[Link] where the assumed par instruments and corresponding conventions
are coded, as shown below for three types of discount curves.

<DiscountCurves>

<DiscountCurve ccy="EUR">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
<ShiftTenors>2W,1M,3M,6M,9M,1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,25Y,30Y</ShiftTenors>
<ParConversion>
<!--DEP, FRA, IRS, OIS, FXF, XBS -->
<Instruments>OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS</Instruments>
<SingleCurve>true</SingleCurve>
<Conventions>
<Convention id="OIS">EUR-OIS-CONVENTIONS</Convention>
</Conventions>
</ParConversion>
</DiscountCurve>

<DiscountCurve ccy="USD">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
<ShiftTenors>2W,1M,3M,6M,9M,1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,25Y,30Y</ShiftTenors>
<ParConversion>
<Instruments>FXF,FXF,FXF,FXF,FXF,XBS,XBS,XBS,XBS,XBS,XBS,XBS,XBS,XBS,XBS,XBS</Instruments>
<SingleCurve>true</SingleCurve>
<Conventions>
<Convention id="XBS">EUR-USD-XCCY-BASIS-CONVENTIONS</Convention>
<Convention id="FXF">EUR-USD-FX-CONVENTIONS</Convention>
</Conventions>
</ParConversion>

<DiscountCurve ccy="GBP">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
<ShiftTenors>2W,1M,3M,6M,9M,1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,25Y,30Y</ShiftTenors>
<ParConversion>
<Instruments>DEP,DEP,DEP,DEP,DEP,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS,IRS</Instruments>

78
 <SingleCurve>true</SingleCurve>
<Conventions>
<Convention id="DEP">GBP-DEPOSIT</Convention>
<Convention id="IRS">GBP-6M-SWAP-CONVENTIONS</Convention>
</Conventions>
</ParConversion>
</DiscountCurve>

</DiscountCurves>

Finally note that par sensitivity analysis requires that the shift tenor grid in the
sensitivity data above matches the corresponding grid in the simulation (market)
configuration. See also section 7.5.

5.51 Custom Trade Fixings

The example in folder Examples/Example_51 demonstrates ORE’s capability to use
custom trade specific fixings. For OIS and Ibor floating legs one can specify historical
fixing on a trade level, see 8.3.6. Those trade level fixings will be only use for the
specific trade, all other trades will use the global fixings.

5.52 Scripted Trade

The scripted trade was added to ORE to gain more flexibility in representing exotic
products, with hyprid payoffs across asset classes, path-dependence, multiple kinds of
early termination options. The scripted trade module uses Monte Carlo and Finite
Difference pricing approaches, it is an evolving interface to implement parallel
processing with GPUs and a central interface to implement AD methods in ORE. See
the separate documentation in folder Docs/ScriptedTrade for an introduction to trade
representation, scripting language, model and pricing engine configuration.

The example in this folder Examples/Example_52 is a basic demonstration of ORE’s

scripted trade functionality. In this example we provide a self-contained case that can
be run as usual calling
python [Link]

This generates an NPV and cash flow report for the following portfolio
• Trade 1: Vanilla European Equity Option, represented as standard ORE XML
with analytical pricing
• Trade 2: Same Option as above, represented as “generic” scripted trade with
scripted payoff embedded into the trade XML, pricing via Monte Carlo
• Trade 3: Same Option as above, same representation, pricing via Finite
Differences triggered by a ProductTag assigned to the script and used in
[Link]
• Trade 4: Same Option as above, the scripted trade now refers to an “external”
script in [Link], MC pricing
• Trade 4b: Same as trade 4, but “compact” scripted trade representation
(uncomment trade 4b in [Link])

79
 • Trade 5: Barrier Option with single continuously observed Up & Out barrier,
represented as standard ORE XML with analytical pricing
• Trade 6: Same Barrier Option as above, approximated as generic scripted trade
with daily barrier observation
• Trade 6b: Same Barrier Option as above, approximated as “compact” scripted
trade with daily barrier observation (uncomment trade 6b in [Link])
• Trade 7: Same Barrier Option as above, represented as generic scripted trade
with continuously observed barrier, i.e. adjusting for the probability of knock-out
between daily observations
• Trade 7b: Same Barrier Option as of above, represented as “compact” scripted
trade (uncomment trade 7b in [Link])
• Trade 8: Equity Accumulator, represented as generic scripted trade with external
payoff script
• Trade 8b: Same Equity Accumulator as above, represented as compact scripted
trade with external payoff script (uncomment trade 8b in [Link])
Note:
• In all cases we use the Black-Scholes model to drive the Equity process.
• The Barrier Option pricing using the scripted trade deviates noticeably from the
analytical pricing when we use daily observations (trade 6 and 6b), but matches
quite closely when we adjust for the probability of knock-out between
observation dates (trade 7 and 7b)
• We are not aware of analytical pricing for the Accumulator product in trade 8 to
benchmark against; trade 8 is priced with MC, FD pricing of the Accumulator is
possible as well but requires a separate payoff script, only in the vanilla
European option case we can utilize the same script for both MC and FD pricing
Though this initial Example_52 shows only single-asset Equity cases, the scripted
trade in its current version is significantly more versatile, more examples and scripts to
follow.

5.53 Curve Building around Central Bank Meeting Dates

This example demonstrates the build of a GBP OIS curve using MPC Swaps at the
short end.

5.54 Scripted Trade Exposure with AMC: Bermudan Swaption

and LPI Swap
This example demonstrates exposure simulation using AMC for selected scripted trade
types
• Bermudan Swaption
• LPI Swap

80
Both payoffs are defined in [Link] which is referenced in [Link].
To enable the AMC processing requires the following highlighted settings in [Link].

<Analytic type="simulation">
<Parameter name="active">Y</Parameter>
<!-- Set to Y to trigger AMC processing -->
<Parameter name="amc">Y</Parameter>
<Parameter name="simulationConfigFile">[Link]</Parameter>
<Parameter name="pricingEnginesFile">[Link]</Parameter>
<!-- Specify a separate pricing engine file for AMC engines -->
<Parameter name="amcPricingEnginesFile">pricingengine\_amc.xml</Parameter>
<!-- Specify trade types to be covered by the AMC processing -->
<Parameter name="amcTradeTypes">ScriptedTrade</Parameter>
<Parameter name="baseCurrency">EUR</Parameter>
<Parameter name="storeScenarios">N</Parameter>
<Parameter name="cubeFile">[Link]</Parameter>
<Parameter name="aggregationScenarioDataFileName">[Link]</Parameter>
<Parameter name="aggregationScenarioDataDump">[Link]</Parameter>
</Analytic>

Note that ORE can handle a mix of trades covered by AMC simulation and covered by
“classic” simulation. The respective NPV cubes are combined before generating results
such as exposures or XVAs.

5.55 Scripted Trade Exposure with AMC: Target Redemption

Forward
This example in folder Examples/Example_55 demonstrates exposure simulation and
XVA for another scripted product, an FX Target Redemption Forward (TaRF). In
contrast to the cases presented above, you won’t see the payoff script library in the
Input folder, nor is the script embedded into the trade XML file. The trade type in
this case is FxTARF which has its own implementation in
OREData/ored/portfolio/[Link] and a separate trade schema. However, the scipted
trade framework is used under the hood, and the payoff script is embedded into the
C++ code in OREData/ored/portfolio/[Link].

5.56 CVA Sensitivities using AAD

This example in folder Examples/Example_56 demonstrates a prototype CVA
sensitivity calculation applying Adjoint Algorithmic Differentiation (AAD) to a Swap
instrument represented as scripted trade.

5.57 Base Scenario Analytic

Demonstration of the Scenario analytic which has been added to export the
simulation market’s base scenario as a file.

5.58 Historical Simlation VaR Analytic

This example in folder Examples/Example_58 demonstrates a historical simulation
VaR calculation given a portfolio and externally provided “market scenarios” covering
one or several historical observation period(s). The analytic is specified as usual in
[Link] with the following parameters:

81
 • outputFile: csv file name of the resulting VaR report
• quantiles: comma searated list of quantiles to be reported
• portfolioFilter (optional): Only trades with portfolioId equal to the provided
filter name are processed, see [Link]; the entire portfolio is processed, if
omitted
• historicalPeriod: comma-separated date list, an even number of ordered dates is
required (d1, d2, d3, d4, ...), where each pair (d1-d2, d3-d4, ...) defines the start
and end of historical observation periods used
• mporDays: Number of calendar days between historical scenarios taken from the
observation periods in order to compute P&L effects (typically 1 or 10)
• mporCalendar: Calendar applied in the scenario date calculation
• mporOverlappingPeriods: Boolean, if true we use overlapping periods of length
mporDays (t to t + 10 calendate days, t+1 to t+11, t+2 to t+12, ...), otherwise
consecutive periods (t to t+10, t+10 to t+20, ...)
• simulationConfigFile: defines the structure of the simulation market applied in
the P&L calculation, e.g. discount and index curves, yield curve tenor points
used, FX pairs etc.
• historicalScenarioFile: csv file containing the market scenarios for each date in
the observation periods defined below; the granularity of the scenarios (e.g.
discount and index curves, number of yield curve tenors) needs to match the
simulation market definition above; each yield curve tenor scenario is represented
as a discount factor
The example is run as usual by calling python [Link]

5.59 SABR Model for Swaptions and Caps/Floors

This example in folder Examples/Example_59 demonstrates the pricing of a Swaption
and a Cap on volatility surfaces that are interpolated in smile direction using a SABR
model flavour. As usual the example is run by calling python [Link]
The essential configuration is in [Link] where the Interpolation (Swaption)
resp. StrikeInterpolation (Caps/Floors) allows the following new SABR types
• Hagan2002Lognormal
• Hagan2002Normal
• Hagan2002NormalZeroBeta
• Antonov2015FreeBoundaryNormal
• KienitzLawsonSwaynePde
• FlochKennedy
SABR parameters can be calibrated or have fixed externally provided values per option
tenor and Swap tenor (Swaptions) resp. optionlet (Caps/Floors).

82
5.60 Overlapping Close-Out Grids
The example in folder Examples/Example_60 demonstrates ORE’s capability to
handle xVA simulations using American Monte-Carlo with overlapping close-out grids.

5.61 Fast Sensitivities using AAD and GPUs

This example in folder Examples/Example_61 demonstrates alternative ways of
speeding up sensitivity calculations - using AAD or an external compute device. The
test portfolio consists of
• Vanilla Equity Option
• Equity Barrier Option
• Equity Accumulator
• Asian Basket Option
• FX TaRFs
The sensitivity analysis is run in four ways, see [Link],
• with “classic” bump and revalue
• as above but using the Computation Graph, see UseCG=true in
pricingengine_cg.xml, which is the basis for the following two approaches
• using AAD, see pricingengine_ad.xml (as in Example
• using the external device if available, see pricingengine_gpu.xml
to compare sensitivities and performance. In the latter case we have set the external
device in pricingengine_gpu.xml to “BasicCpu/Default/Default” which mimics an
external device on the CPU. On a macbook pro (2023) with M2 Max processor, we can
also choose “OpenCL/Apple/Apple M2 Max” here (a 38 core GPU). The Jupyter
notebook [Link] in this Example_61 folder also kicks off these four runs, but adds
further commentary and visualises results. To run this notebook you need to build the
Python bindings for release 12 or “pip install” ORE v12.

5.62 P&L and P&L Explain Analytics

This example in folder Examples/Example_62 demonstrates the P&L analytic type on
a very simple test portfolio that consists of two single-leg swaps. The example can be
run as usual by calling python [Link]. Main output is the P&L report in
Output/Pnl/[Link] with the following columns
• TradeId
• Maturity and MaturityTime
• StartDate and EndDate of the P&L period, referred to as t0 and t1 below
• NPV(t0)
• NPV(asof=t0; mkt=t1)
• NPV(asof=t1; mkt=t0)

83
 • NPV(t1)
• PeriodCashFlow: Aggregate of trade flows in the period, converted into the P&L
currency below
• Theta: NPV(asof=t1; mkt=t0) - NPV(t0) + PeriodCashFLow
• HypotheticalCleanPnL: NPV(asof=t0; mkt=t1) - NPV(t0)
• CleanPnL: NPV(t1) - NPV(t0) + PeriodCashFlow
• DirtyPnL: NPV(t1) - NPV(t0)
• Currency
Moreover we write
• Four “flavours” of NPV reports used here
• Four related additional results reports
• Two reports for the market scenarios used in the two “lagged” NPV calculations
This analytic is work in progress since it is based on the portfolio at t0 only: The t1
portfolio needs to be taken into account in order to work out the effects of portfolio
changes (maturities, new business, trade changes) in the observation period.
Furthermore, this example runs a second batch (see Input/ore_explain.xml) to
explain the P&L above in terms of portfolio sensitivities and changes in related market
moves. The main output of this is in Output/PnlExplain/pnl_explain.csv. The
PnlExplain analytic contains the Pnl analytic as dependent analytic, i.e. the
PnlExplain analytic is self-sufficient kicking off Pnl calculation internally. The only
additional piece of input for the explainer run is [Link].

5.63 Stress Tests in the Par-Rate Domain

The stress testing framework in ORE has been operated so far in the “raw” domain of
zero rate shifts, hazard rate shifts, optionlet volatility shifts etc. To analyse the impact
of market rate shifts (Swap rates, CDS spreads, flat vols), one had to manipulate the
market data input into ORE and re-run the entire ORE process multiple times.
This example in folder Examples/Example_63 demonstrates the extended stress testing
framework that can be operated in the “par” rate domain instead.

5.64 Formula-based Coupon

The example in folder Examples/Example_64 demonstrates the formula based leg in
the context of Swaps with CMS Spread and Digital CMS Spread legs, as well as a
Bond with a CMS Spread leg.
The formula-based leg can be seen as a predecessor of the more versatile scripted trade
framework. However, the formula leg may be used to apply a multi-factor Log-normal
Swap Rate model instead of the Gaussian interest rate models currently applied in the
scripted trade framework.

84
5.65 Flexi Swap
The example in folder Examples/Example_65 demonstrates the FlexiSwap instrument
in ORE - in a nutshell an amortizing swap in which one party has the option to reduce
the notional in each period to any value between the current notional and a specified
lower bound for that period.

5.66 Balance Guaranteed Swap

The example in folder Examples/Example_66 demonstrates the Balance Guaranteed
Swap (BGS) instrument, an amortizing Swap with prepayments that match
prepayments in an underlying reference security. In ORE this BGS is approximated by
a FlexiSwap instrument with amorization bounds given by two “conditional
prepayment rate (CPR)” levels, e.g. determined by current and past CPRs or expert
judgement.

5.67 XVA Stress Testing

The example in folder
tt Examples/Example_67 demonstrates the XVA stresstesting with the classical and
AMC XVA engine. The new analytic type
emphXVA_STRESS utilizes the existing stresstest framework and supports stresstests
in both zero and par domain. The Stresstest scenarios are given in the same input
format as for the regular stresstest.
To analyse the impact of market rate shifts (Swap rates, CDS spreads, flat vols), one
had to manipulate the market data input into ORE and re-run the entire ORE process
multiple times.
The generated outputs are the xva and exposure reports under each scenario.

5.68 XVA Bump & Revalue Sensitivities

The example in folder
tt Examples/Example_68 demonstrates the XVA sensitivity analysis with the AMC
XVA engine. The new analytic type XVA_SENSITIVITY applies zero shifts as
specified in the [Link] and computes the xva and exposure measures under
each shifted market condition.
The aggregation of the results to sensitivites need to handled outside of ORE. These
external computed sensitivites can be converted to par sensitivities with the
zero-to-par conversion analytic (see 5.50).

5.69 Zero Rate Shifts To Par Shifts

The example in folder
tt Examples/Example_69 demonstrates the conversion of zero shifts to par rate shifts.
ORE applies the zero rate shifts to the zero curves and computes the resulting shifts in
the implied fair rate of a given set of par instruments. The zero rate shifts are defined
as stresstests and the par instruments are defined in the usual sensitivity configuration.

85
6 Launchers and Visualisation
6.1 Jupyter
ORE comes with an experimental Jupyter notebook for launching ORE batches and in
particular for drilling into NPV cube data. The notebook is located in directory
FrontEnd/Python/Visualization/npvcube. To launch the notebook, change to this
directory and follow instructions in the [Link]. In a nutshell, type4
jupyter notebook

to start the ipython console and open a browser window. From the list of files
displayed in the browser then click
ore_jupyter_dashboard.ipynb

to open the ORE notebook. The notebook offers

• launching an ORE job
• selecting an NPV cube file and netting sets or trades therein
• plotting a 3d exposure probability density surface
• viewing exposure probability density function at a selected future time
• viewing expected exposure evolution through time
The cube file loaded here by default when processing all cells of the notebook (without
changing it or launching a ORE batch) is taken from Example_7 (FX Forwards and
FX Options).

6.2 Calc
ORE comes with a simple LibreOffice Calc [11] sheet as an ORE launcher and basic
result viewer. This is demonstrated on the example in section 5.1. It is currently based
on the stable LibreOffice version 5.0.6 and tested on OS X.
To launch Calc, open a terminal, change to directory Examples/Example_1, and run
./[Link]

The user can choose a configuration (one of the ore*.xml files in Example_1’s
subfolder Input) by hitting the ’Select’ button. Initially Input/[Link] is pre-selected.
The ORE process is then kicked off by hitting ’Run’. Once completed, standard ORE
reports (NPV, Cashflow, XVA) are loaded into several sheets. Moreover, exposure
evolutions can then be viewed by hitting ’View’ which shows the result in figure 35.
This demo uses simple Libre Office Basic macros which call Python scripts to execute
ORE. The Libre Office Python uno module (which comes with Libre Office) is used to
communicate between Python and Calc to upload results into the sheets.
With Mac OS X, you may need to set the environment variable LANG to en_US.UTF-8 before
4

running jupyter, as mentioned in the installation section 4.3.

86
 Figure 35: Calc sheet after hitting ’Run’.

6.3 Excel
ORE also comes with a basic Excel sheet to demonstrate launching ORE and
presenting results in Excel. This demo is more self-contained than the Calc demo in
the previous section, as it uses VBA only rather than calls to external Python scripts.
The Excel demo is available in Example_1. Launch Example_1.xlsm. Then modify
the paths on the first sheet, and kick off the ORE process.

7 Parameterisation
A run of ORE is kicked off with a single command line parameter
ore[.exe] [Link]

which points to the ’master input file’ referred to as [Link] subsequently. This file is
the starting point of the engine’s configuration explained in the following sub section.
An overview of all input configuration files respectively all output files is shown in
Table 4 respectively Table 5. To set up your own ORE configuration, it might be not
be necessary to start from scratch, but instead use any of the examples discussed in
section 5 as a boilerplate and just change the folders, see section 7.1, and the trade
data, see section 8, together with the netting definitions, see section 9.

87
7.1 Master Input File: [Link]
The master input file contains general setup information (paths to configuration, trade
data and market data), as well as the selection and configuration of analytics. The file
has an opening and closing root element <ORE>, </ORE> with three sections
• Setup
• Logging
• Markets
• Analytics
which we will explain in the following.

7.1.1 Setup
This subset of data is easiest explained using an example, see listing 3.

Listing 3: ORE setup example

<Setup>
<Parameter name="asofDate">2016-02-05</Parameter>
<Parameter name="inputPath">Input</Parameter>
<Parameter name="outputPath">Output</Parameter>
<Parameter name="logFile">[Link]</Parameter>
<Parameter name="logMask">255</Parameter>
<Parameter name="marketDataFile">../../Input/market_20160205.txt</Parameter>
<Parameter name="fixingDataFile">../../Input/fixings_20160205.txt</Parameter>
<Parameter name="dividendDataFile">../../Input/dividends_20160205.txt</Parameter> <!-- Optional --
<Parameter name="implyTodaysFixings">Y</Parameter>
<Parameter name="curveConfigFile">../../Input/[Link]</Parameter>
<Parameter name="conventionsFile">../../Input/[Link]</Parameter>
<Parameter name="marketConfigFile">../../Input/[Link]</Parameter>
<Parameter name="pricingEnginesFile">../../Input/[Link]</Parameter>
<Parameter name="portfolioFile">[Link]</Parameter>
<Parameter name="calendarAdjustment">../../Input/[Link]</Parameter>
<Parameter name="currencyConfiguration">../../Input/[Link]</Parameter>
<Parameter name="referenceDataFile">../../Input/[Link]</Parameter>
<Parameter name="iborFallbackConfig">../../Input/[Link]</Parameter>
<!-- None, Unregister, Defer or Disable -->
<Parameter name="observationModel">Disable</Parameter>
<Parameter name="lazyMarketBuilding">false</Parameter>
<Parameter name="continueOnError">false</Parameter>
<Parameter name="buildFailedTrades">true</Parameter>
<Parameter name="nThreads">4</Parameter>
</Setup>

Parameter names are self explanatory: Input and output path are interpreted relative
from the directory where the ORE executable is executed, but can also be specified
using absolute paths. All file names are then interpreted relative to the ’inputPath’
and ’outputPath’, respectively. The files starting with ../../Input/ then point to
files in the global Example input directory Example/Input/*, whereas files such as
[Link] are local inputs in Example/Example_#/Input/.

88
Parameter logMask determines the verbosity of log file output. Log messages are
internally labelled as Alert, Critical, Error, Warning, Notice, Debug, associated with
logMask values 1, 2, 4, 8, ..., 64. The logMask allows filtering subsets of these
categories and controlling the verbosity of log file output5 . LogMask 255 ensures
maximum verbosity.
When ORE starts, it will initialise today’s market, i.e. load market data, fixings and
dividends, and build all term structures as specified in [Link]. Moreover,
ORE will load the trades in [Link] and link them with pricing engines as
specified in [Link]. When parameter implyTodaysFixings is set to Y,
today’s fixings would not be loaded but implied, relevant when pricing/bootstrapping
off hypothetical market data as e.g. in scenario analysis and stress testing. The
curveConfigFile [Link], the conventionsFile [Link], the
referenceDataFile [Link], the iborFallbackConfig, the marketDataFile
and the fixingDataFile are explained in the sections below.

Parameter calendarAdjustment includes the [Link] which lists

out additional holidays and business days to be added to specified calendars.

The optional parameter currencyConfiguration points to a configuration file that

contains additional currencies to be added to ORE’s setup, see
Examples/Input/[Link] for a full list of ISO currencies and a few unofficial
currency codes that can thus be made available in ORE. Note that the external
configuration does not override any currencies that are hard-coded in the
QuantLib/QuantExt libraries, only currencies not present already are added from the
external configuration file.

The last parameter observationModel can be used to control ORE performance

during simulation. The choices Disable and Unregister yield similarly improved
performance relative to choice None. For users familiar with the QuantLib design - the
parameter controls to which extent QuantLib observer notifications are used when
market and fixing data is updated and the evaluation date is shifted:
• The ’Unregister’ option limits the amount of notifications by unregistering
floating rate coupons from indices;
• Option ’Defer’ disables all notifications during market data and fixing updates
with ObservableSettings::instance().disableUpdates(true) and kicks off
updates afterwards when enabled again
• The ’Disable’ option goes one step further and disables all notifications during
market data and fixing updates, and in particular when the evaluation date is
changed along a path, with
ObservableSettings::instance().disableUpdates(false)
Updates are not deferred here. Required term structure and instrument
recalculations are triggered explicitly.

If the parameter lazyMarketBuilding is set to true, the build of the curves in the
TodaysMarket is delayed until they are actually requested. This can speed up the
5
by bitwise comparison of the external logMask value with each message’s log level

89
processing when some curves configured in TodaysMarket are not used. If not given,
the parameter defaults to true.

If the parameter continueOnError is set to true, the application will not exit on an
error, but try to continue the processing. If not given, the parameter defaults to false.

If the parameter buildFailedTrades is set to true, the application will build a dummy
trade if loading or building the original trade fails. The dummy trade has trade type
“Failed”, zero notional and NPV. If not given, the parameter defaults to false.

If the parameter nThreads is given, multiple threads will be used for valuation engine
runs where applicable (Sensitivity, Exposure Classic, Exposure AMC). If not given, the
parameter defaults to 1.

7.1.2 Logging
The Logging section (see listing 4) is used to configure some ORE logging options.

Listing 4: ORE logging

<Logging>
<Parameter name="logFile">[Link]</Parameter>
<Parameter name="logMask">31</Parameter>
<Parameter name="progressLogFile">my_log_progress_%[Link]</Parameter>
<Parameter name="progressLogRotationSize">102400</Parameter>
<Parameter name="progressLogToConsole">false</Parameter>
<Parameter name="structuredLogFile">my_structured_logs_%[Link]</Parameter>
<Parameter name="structuredLogRotationSize">102400</Parameter>
</Logging>

Parameter logFile and logMask will override the same parameters in the Setup
section.
Parameters progressLogFile and structuredLogFile are the filename where
progress log messages and structured log messages are written out to, respectively,
which supports Boost string [Link] defaults to “log_progress_%[Link]” and
“log_structured_%[Link]”, respectively, where N will be an integer (beginning at 0)
used for log file rotation.
Parameters progressLogRotationSize and structuredLogRotationSize are the size
limit (in bytes) of each log file before applying log file rotation to the progress log file
and structured log message file, respectively.. For example, 10 ∗ 1024 ∗ 1024 = 10MiB.
Defaults to 100 MiB.
If the parameter progressLogToConsole is set to true, then progress logs will be
written to std::cout. This can be used simultaneously with progressLogFile, i.e.
progress logs can be written out to both file and std::cout.

7.1.3 Markets
The Markets section (see listing 5) is used to choose market configurations for
calibrating the IR, FX and EQ simulation model components, pricing and simulation,

90
respectively. These configurations have to be defined in [Link] (see
section 7.2).

Listing 5: ORE markets

<Markets>
<Parameter name="lgmcalibration">collateral_inccy</Parameter>
<Parameter name="fxcalibration">collateral_eur</Parameter>
<Parameter name="eqcalibration">collateral_inccy</Parameter>
<Parameter name="pricing">collateral_eur</Parameter>
<Parameter name="simulation">collateral_eur</Parameter>
</Markets>

For example, the calibration of the simulation model’s interest rate components
requires local OIS discounting whereas the simulation phase requires cross currency
adjusted discount curves to get FX product pricing right. So far, the market
configurations are used only to distinguish discount curve sets, but the market
configuration concept in ORE applies to all term structure types.

7.1.4 Analytics
The Analytics section lists all permissible analytics using tags <Analytic
type="..."> ... </Analytic> where type can be (so far) in
• npv
• cashflow
• curves
• simulation
• xva
• sensitivity
• stress
• parStressConversion
• parametricVar
• historicalSimulationVar
• pnl
• pnlExplain
• simm
• imschedule
• scenario
Each Analytic section contains a list of key/value pairs to parameterise the analysis of
the form <Parameter name="key">value</Parameter>. Each analysis must have one

91
key active set to Y or N to activate/deactivate this analysis. The following listing 6
shows the parametrisation of the first four basic analytics in the list above.

Listing 6: ORE analytics: npv, cashflow, curves, additional results, todays market calibration

<Analytics>
<Analytic type="npv">
<Parameter name="active">Y</Parameter>
<Parameter name="baseCurrency">EUR</Parameter>
<Parameter name="outputFileName">[Link]</Parameter>
<Parameter name="additionalResults">Y</Parameter>
<Parameter name="additionalResultsReportPrecision">6</Parameter>
</Analytic>
<Analytic type="cashflow">
<Parameter name="active">Y</Parameter>
<Parameter name="outputFileName">[Link]</Parameter>
<Parameter name="includePastCashflows">N</Parameter>
</Analytic>
<Analytic type="curves">
<Parameter name="active">Y</Parameter>
<Parameter name="configuration">default</Parameter>
<Parameter name="grid">240,1M</Parameter>
<Parameter name="outputFileName">[Link]</Parameter>
<Parameter name="outputTodaysMarketCalibration">N</Parameter>
</Analytic>
<Analytic type="...">
<!-- ... -->
</Analytic>
</Analytics>

The cashflow analytic writes a report containing all future cashflows of the portfolio.
Table 13 shows a typical output for a vanilla swap.
#ID Type LegNo PayDate Amount Currency Coupon Accrual fixingDate fixingValue Notional
tr123 Swap 0 13/03/17 -111273.76 EUR -0.00201 0.50556 08/09/16 -0.00201 100000000.00
tr123 Swap 0 12/09/17 -120931.71 EUR -0.002379 0.50833 09/03/17 -0.002381 100000000.00
...

Table 13: Cashflow Report

The amount column contains the projected amount including embedded caps and
floors and convexity (if applicable), the coupon column displays the corresponding rate
estimation. The fixing value on the other hand is the plain fixing projection as given
by the forward value, i.e. without embedded caps and floors or convexity.
Note that the fixing value might deviate from the coupon value even for a vanilla
coupon, if the QuantLib library was compiled without the flag
QL_USE_INDEXED_COUPON (which is the default case). In this case the coupon value
uses a par approximation for the forward rate assuming the index estimation period to
be identical to the accrual period, while the fixing value is the actual forward rate for
the index estimation period, i.e. whenever the index estimation period differs from the
accrual period the values will be slightly different.
The Notional column contains the underlying notional used to compute the amount of
each coupon. It contains #NA if a payment is not a coupon payment.

92
The curves analytic exports all yield curves that have been built according to the
specification in [Link]. Key configuration selects the curve set to be
used (see explanation in the previous Markets section). Key grid defines the time grid
on which the yield curves are evaluated, in the example above a grid of 240 monthly
time steps from today. The discount factors for all curves with configuration default
will be exported on this monthly grid into the csv file specified by key
outputFileName. The grid can also be specified explicitly by a comma separated list
of tenor points such as 1W, 1M, 2M, 3M, ....
The additionalResults analytic writes a report containing any additional results
generated for the portfolio. The results are pricing engine specific but Table 14 shows
the output for a vanilla swaption.
#TradeId ResultId ResultType ResultValue
example_swaption annuity double 2123720984
example_swaption atmForward double 0.01664135
example_swaption spreadCorrection double 0
example_swaption stdDev double 0.00546015
example_swaption strike double 0.024
example_swaption swapLength double 4
example_swaption vega double 309237709.5
...

Table 14: AdditionalResults Report

The todaysMarketCalibration analytic writes a report containing information on the

build of the t0 market.

The purpose of the simulation ’analytics’ is to run a Monte Carlo simulation which
evolves the market as specified in the simulation config file. The primary result is an
NPV cube file, i.e. valuations of all trades in the portfolio file (see section Setup), for
all future points in time on the simulation grid and for all paths. Apart from the NPV
cube, additional scenario data (such as simulated overnight rates etc) are stored in this
process which are needed for subsequent XVA analytics.

93
Listing 7: ORE analytic: simulation

<Analytics>
<Analytic type="simulation">
<Parameter name="active">Y</Parameter>
<Parameter name="amc">Y</Parameter>
<Parameter name="amcCg">Y</Parameter>
<Parameter name="xvaCgSensitivityConfigFile">[Link]</Parameter>
<Parameter name="amcTradeTypes">Swap</Parameter>
<Parameter name="amcPricingEnginesFile">pricingengine_amc.xml</Parameter> -> not documented
<Parameter name="simulationConfigFile">[Link]</Parameter>
<Parameter name="pricingEnginesFile">../../Input/[Link]</Parameter>
<Parameter name="baseCurrency">EUR</Parameter>
<Parameter name="storeFlows">Y</Parameter>
<Parameter name="storeSurvivalProbabilities">Y</Parameter>
<Parameter name="salvageCorrelationMatrix">true</Parameter>
<Parameter name="scenariodump">[Link]</Parameter>
<Parameter name="aggregationScenarioDataFileName">[Link]</Parameter>
<Parameter name="storeCreditStateNPVs">8</Parameter>
<Parameter name="cubeFile">cube_A.[Link]</Parameter>
</Analytic>
</Analytics>

The pricing engines file specifies how trades are priced under future scenarios which
can differ from pricing as of today (specified in section Setup). Key base currency
determines into which currency all NPVs will be converted. Key store scenarios (Y or
N) determines whether the market scenarios are written to a file for later reuse. Key
‘store flows’ (Y or N) controls whether cumulative cash flows between simulation dates
are stored in the (hyper-) cube for post processing in the context of Dynamic Initial
Margin and Variation Margin calculations. And finally, the key ‘store survival
probabilities’ (Y or N) controls whether survival probabilities on simulation dates are
stored in the cube for post processing in the context of Dynamic Credit XVA
calculation. The additional scenario data (written to the specified file here) is likewise
required in the post processor step. These data comprise simulated index fixing e.g.
for collateral compounding and simulated FX rates for cash collateral conversion into
base currency. The scenario dump file, if specified here, causes ORE to write simulated
market data to a human-readable csv file. Only those currencies or indices are written
here that are stated in the AggregationScenarioDataCurrencies and
AggregationScenarioDataIndices subsections of the simulation files market section, see
also section 7.4.3.

The XVA analytic section offers CVA, DVA, FVA and COLVA calculations which can
be selected/deselected here individually. All XVA calculations depend on a previously
generated NPV cube (see above) which is referenced here via the cubeFile parameter.
This means one can re-run the XVA analytics without regenerating the cube each
time. The XVA reports depend in particular on the settings in the csaFile which
determines CSA details such as margining frequency, collateral thresholds, minimum
transfer amounts, margin period of risk. By splitting the processing into pre-processing
(cube generation) and post-processing (aggregation and XVA analysis) it is possible to
vary these CSA details and analyse their impact on XVAs quickly without
re-generating the NPV cube. The cube file is usually a compressed csv file (using gzip

94
compression, with file ending .[Link]), except when the file extension is set explicitly to
txt or csv in which case an uncompressed version of the file is written to disk.

95
Listing 8: ORE analytic: xva

<Analytics>
<Analytic type="xva">
<Parameter name="active">Y</Parameter>
<Parameter name="csaFile">[Link]</Parameter>
<Parameter name="cubeFile">[Link]</Parameter>
<Parameter name="scenarioFile">[Link]</Parameter>
<Parameter name="collateralBalancesFile">[Link]</Parameter>
<Parameter name="baseCurrency">EUR</Parameter>
<Parameter name="exposureProfiles">Y</Parameter>
<Parameter name="exposureProfilesByTrade">Y</Parameter>
<Parameter name="quantile">0.95</Parameter>
<Parameter name="calculationType">NoLag</Parameter>
<Parameter name="allocationMethod">None</Parameter>
<Parameter name="marginalAllocationLimit">1.0</Parameter>
<Parameter name="exerciseNextBreak">N</Parameter>
<Parameter name="cva">Y</Parameter>
<Parameter name="dva">N</Parameter>
<Parameter name="dvaName">BANK</Parameter>
<Parameter name="fva">N</Parameter>
<Parameter name="fvaBorrowingCurve">BANK_EUR_BORROW</Parameter>
<Parameter name="fvaLendingCurve">BANK_EUR_LEND</Parameter>
<Parameter name="colva">Y</Parameter>
<Parameter name="collateralFloor">Y</Parameter>
<Parameter name="dynamicCredit">N</Parameter>
<Parameter name="kva">Y</Parameter>
<Parameter name="kvaCapitalDiscountRate">0.10</Parameter>
<Parameter name="kvaAlpha">1.4</Parameter>
<Parameter name="kvaRegAdjustment">12.5</Parameter>
<Parameter name="kvaCapitalHurdle">0.012</Parameter>
<Parameter name="kvaOurPdFloor">0.03</Parameter>
<Parameter name="kvaTheirPdFloor">0.03</Parameter>
<Parameter name="kvaOurCvaRiskWeight">0.005</Parameter>
<Parameter name="kvaTheirCvaRiskWeight">0.05</Parameter>
<Parameter name="dim">Y</Parameter>
<Parameter name="dimModel">Regression</Parameter>
<Parameter name="mva">Y</Parameter>
<Parameter name="dimQuantile">0.99</Parameter>
<Parameter name="dimHorizonCalendarDays">14</Parameter>
<Parameter name="dimRegressionOrder">1</Parameter>
<Parameter name="dimRegressors">EUR-EURIBOR-3M,USD-LIBOR-3M,USD</Parameter>
<Parameter name="dimLocalRegressionEvaluations">100</Parameter>
<Parameter name="dimLocalRegressionBandwidth">0.25</Parameter>
<Parameter name="dimScaling">1.0</Parameter>
<Parameter name="dimEvolutionFile">dim_evolution.txt</Parameter>
<Parameter name="dimRegressionFiles">dim_regression.txt</Parameter>
<Parameter name="dimOutputNettingSet">CPTY_A</Parameter>
<Parameter name="dimOutputGridPoints">0</Parameter>
<Parameter name="rawCubeOutputFile">[Link]</Parameter>
<Parameter name="netCubeOutputFile">[Link]</Parameter>
<Parameter name="nettingSetCubeFile">nettingSetCube_A.[Link]</Parameter>
<Parameter name="cptyCubeFile">cptyCube_A.[Link]</Parameter>
<Parameter name="fullInitialCollateralisation">true</Parameter>
<Parameter name="flipViewXVA">N</Parameter>
<Parameter name="flipViewBorrowingCurvePostfix">_BORROW</Parameter>
<Parameter name="flipViewLendingCurvePostfix">_LEND</Parameter>
<Parameter name="mporCashFlowMode">NonePay</Parameter>
</Analytic>
</Analytics>
96
Parameters:
• csaFile: Netting set definitions file covering CSA details such as margining
frequency, thresholds, minimum transfer amounts, margin period of risk
• cubeFile: NPV cube file previously generated and to be post-processed here
• scenarioFile: Scenario data previously generated and used in the
post-processor (simulated index fixings and FX rates)
• collateralBalancesFile: References an xml file that contains current VM and
IM balances by netting set
• baseCurrency: Expression currency for all NPVs, value adjustments, exposures
• exposureProfiles: Flag to enable/disable exposure output for each netting set
• exposureProfilesByTrade: Flag to enable/disable stand-alone exposure output
for each trade
• quantile: Confidence level for Potential Future Exposure (PFE) reporting
• calculationType: Determines the settlement of margin calls. The admissible
choices depend on having a close-out grid, see table 15;
– if there isn’t any “close-out” grid -see section 7.4-, the choices are:
∗ Symmetric - margin for both counterparties settled after the margin
period of risk;
∗ AsymmetricCVA - margin requested from the counterparty settles with
delay, margin requested from us settles immediately;
∗ AsymmetricDVA - vice versa.
– If there is a “close-out” grid -see section 7.4-, only choice is:
∗ NoLag - used to disable any delayed settlement of the margin.
NoLag is the default configuration.

Grid Type calculationType Comment

NoLag Not Supported
Symmetric Supported6
without close-out grid
AsymmetricCVA Supported 6
AsymmetricDVA Supported 6
NoLag Supported7
Symmetric Not Supported
with close-out grid
AsymmetricCVA Not Supported
AsymmetricDVA Not Supported

Table 15: Overview of admissible calculation types with combination of grid types.

6
The calculations are correct only if the simulation grid (see section 7.4) is equally-spaced with
time steps that match the MPoR defined in netting-set definition (see section 9.2). See section A.13 for
further explanation.
7
Close-out lag (see section 7.4) must be equal to MPoR defined in netting-set definition (see section

97
 • allocationMethod: XVA allocation method, choices are None, Marginal,
RelativeXVA, RelativeFairValueGross, RelativeFairValueNet
• marginalAllocationLimit: The marginal allocation method a la
Pykhtin/Rosen breaks down when the netting set value vanishes while the
exposure does not. This parameter acts as a cutoff for the marginal allocation
when the absolute netting set value falls below this limit and switches to equal
distribution of the exposure in this case.
• exerciseNextBreak: Flag to terminate all trades at their next break date
before aggregation and the subsequent analytics
• cva, dva, fva, colva, collateralFloor, dim, mva: Flags to
enable/disable these analytics.
• dimModel: Type of dynamic initial margin model to be applied – Regression or
Flat. Regression is applied by default when the dimModel node is omitted (see
appendix and further settings related to the regression DIM model below); Flat
means a simple flat projection of todays’s IM amount on each path (this requires
providing today’s IM using the collateralBalancesFile parameter, see above)
• dvaName: Credit name to look up the own default probability curve and recovery
rate for DVA calculation
• fvaBorrowingCurve: Identifier of the borrowing yield curve
• fvaLendingCurve: Identifier of the lending yield curve
• dynamicCredit: Flag to enable using pathwise survival probabilities when
calculating CVA, DVA, FVA and MVA increments from exposures. If set to N
the survival probabilities are extracted from T0 curves.
• kva: Flag to enable setting the kva ccr parameters.
• kvaCapitalDiscountRate, kvaAlpha, kvaRegAdjustment,
kvaCapitalHurdle, kvaOurPdFloor, kvaTheirPdFloor
kvaOurCvaRiskWeight, kvaTheirCvaRiskWeight: the kva CCR parameters
(see A.11 and A.12.
• dimQuantile: Quantile for Dynamic Initial Margin (DIM) calculation
• dimHorizonCalendarDays: Horizon for DIM calculation, 14 calendar days for 2
weeks, etc.
• dimRegressionOrder: Order of the regression polynomial (netting set clean
NPV move over the simulation period versus netting set NPV at period start)
• dimRegressors: Variables used as regressors in a single- or multi-dimensional
regression; these variable names need to match entries in the [Link]’s
AggregationScenarioDataCurrencies and AggregationScenarioDataIndices
sections (only these scenario data are passed on to the post processor); if the list
is empty, the NPV will be used as a single regressor
• dimLocalRegressionEvaluations: Nadaraya-Watson local regression evaluated
at the given number of points to validate polynomial regression. Note that
9.2). Otherwise, an error will be thrown.

98
 Nadaraya-Watson needs a large number of samples for meaningful results.
Evaluating the local regression at many points (samples) has a significant
performance impact, hence the option here to limit the number of evaluations.
• dimLocalRegressionBandwidth: Nadaraya-Watson local regression bandwidth
in standard deviations of the independent variable (NPV)
• dimScaling: Scaling factor applied to all DIM values used, e.g. to reconcile
simulated DIM with actual IM at t0
• dimEvolutionFile: Output file name to store the evolution of zero order DIM
and average of nth order DIM through time
• dimRegressionFiles: Output file name(s) for a DIM regression snapshot,
comma separated list
• dimOutputNettingSet: Netting set for the DIM regression snapshot
• dimOutputGridPoints: Grid point(s) (in time) for the DIM regression snapshot,
comma separated list
• rawCubeOutputFile: File name for the trade NPV cube in human readable csv
file format (per trade, date, sample), leave empty to skip generation of this file.
• netCubeOutputFile: File name for the aggregated NPV cube in human
readable csv file format (per netting set, date, sample) after taking collateral into
account. Leave empty to skip generation of this file.
• fullInitialCollateralisation: If set to true, then for every netting set, the
collateral balance at t = 0 will be set to the NPV of the setting set. The
resulting effect is that EPE, ENE and PFE are all zero at t = 0. If set to false
(default value), then the collateral balance at t = 0 will be set to zero.
• flipViewXVA: If set to Y, the perspective in XVA calculations is switched to the
cpty view, the npvs and the netting sets being reverted during calculation. In
order to get the lending/borrowing curve, the calculation assumes these curves
being set up with the cptyname + the postfix given in the next two settings.
• flipViewBorrowingCurvePostfix: postfix for the borrowing curve, the
calculation assumes this is curves being set up with cptyname + postfix given.
• flipViewLendingCurvePostfix: postfix for the lending curve, the calculation
assumes this is curve being set up with cptyname + postfix given.
• mporCashFlowMode: Assumption about payment of cashflows within mpor
period. One of NonePay, BothPay, WePay, TheyPay, Unspecified. Defaults to
Unspecified, in this case PP will assume NonePay if mpor sticky date is used,
otherwise to BothPay.
The two cube file outputs rawCubeOutputFile and netCubeOutputFile are provided
for interactive analysis and visualisation purposes, see section 6.

The sensitivity and stress ’analytics’ provide computation of bump and revalue
(zero rate resp. optionlet) sensitivities and NPV changes under user defined stress
scenarios. Listing 9 shows a typical configuration for sensitivity calculation.

99
Listing 9: ORE analytic: sensitivity

<Analytics>
<Analytic type="sensitivity">
<Parameter name="active">Y</Parameter>
<Parameter name="marketConfigFile">[Link]</Parameter>
<Parameter name="sensitivityConfigFile">[Link]</Parameter>
<Parameter name="pricingEnginesFile">../../Input/[Link]</Parameter>
<Parameter name="scenarioOutputFile">[Link]</Parameter>
<Parameter name="sensitivityOutputFile">[Link]</Parameter>
<Parameter name="crossGammaOutputFile">[Link]</Parameter>
<Parameter name="outputSensitivityThreshold">0.000001</Parameter>
<Parameter name="recalibrateModels">Y</Parameter>
<!-- Additional parametrisation for par sensitivity analysis -->
<Parameter name="parSensitivity">Y</Parameter>
<Parameter name="parSensitivityOutputFile">[Link]</Parameter>
<Parameter name="outputJacobi">Y</Parameter>
<Parameter name="jacobiOutputFile">[Link]</Parameter>
<Parameter name="jacobiInverseOutputFile">jacobi_inverse.csv</Parameter>
</Analytic>
</Analytics>

The parameters have the following interpretation:

• marketConfigFile: Configuration file defining the simulation market under
which sensitivities are computed, see 7.4. Only a subset of the specification is
needed (the one given under Market, see 7.4.3 for a detailed description).
• sensitivityConfigFile: Configuration file for the sensitivity calculation, see
section 7.5.
• pricingEnginesFile: Configuration file for the pricing engines to be used for
sensitivity calculation.
• scenarioOutputFile: File containing the results of the sensitivity calculation in
terms of the base scenario NPV, the scenario NPV and their difference.
• sensitivityOutputFile: File containing the results of the sensitivity
calculation in terms of the base scenario NPV, the shift size together with the
risk-factor and the resulting first and (pure) second order finite differences. Also
included is a second set of shift sizes together with the risk-factor with a (mixed)
second order finite difference associated to a cross gamma calculation
• outputSensitivityThreshold: Only finite differences with absolute value
greater than this number are written to the output files.
• recalibrateModels: If set to Y, then recalibrate pricing models after each shift
of relevant term structures; otherwise do not recalibrate
• parSensitivity: If set to Y, par sensitivity analysis is performed following the
"raw" sensitivity analysis; note that in this case the sensitivityConfigFile
needs to contain ParConversion sections, see Example_40
• parSensitivityOutputFile: Output file name for the par sensitivity report

100
 • outputJacobi: If set to Y, then the relevant Jacobi and inverse Jacobi matrix is
written to a file, see below
• jacobiOutputFile: Output file name for the Jacobi matrx
• jacobiInverseOutputFile: Output file name for the inverse Jacobi matrix
The zero to par sensitivity conversion analytics configuration is similar to the one of
the sensitivity calculation. Listing 10 shows an example.

Listing 10: ORE analytic: Zero to Par Sensitivity Conversion

<Analytics>
<Analytic type="zeroToParSensiConversion">
<Parameter name="active">Y</Parameter>
<Parameter name="marketConfigFile">[Link]</Parameter>
<Parameter name="sensitivityConfigFile">[Link]</Parameter>
<Parameter name="pricingEnginesFile">../../Input/[Link]</Parameter>
<Parameter name="sensitivityInputFile">[Link]</Parameter>
<Parameter name="outputThreshold">0.000001</Parameter>
<Parameter name="outputFile">parconversion_sensitivity.csv</Parameter>
<Parameter name="outputJacobi">Y</Parameter>
<Parameter name="jacobiOutputFile">[Link]</Parameter>
<Parameter name="jacobiInverseOutputFile">jacobi_inverse.csv</Parameter>
</Analytic>
</Analytics>

The parameters have the same interpretation as for the sensitivity analytic. There is
one new parameter *sensitivityInputFile* which points to a csv file with the raw
(zero)sensitivites. Those raw sensitivites will be converted into par sensitivities, using
the same methodology described in A.16 and the configuration is described in 7.5.
The raw sensitivites csv input file *sensitivityInputFile* needs to have at least six
columns, the column names can be user configured in the master input file. Here is a
description of each of the columns:
1. idColumn : Column with a unique identifier for the trade / nettingset / portfolio.
2. riskFactorColumn: Column with the identifier of the zero/raw sensitiviy. The
risk factor name needs to follow the ORE naming convention, e.g.
DiscountCurve/EUR/5/1Y (the 6th bucket in EUR discount curve as specified in
the [Link])
3. deltaColumn: The raw sensitivity of the trade/nettingset / portfolio with respect
to the risk factor
4. currencyColumn: The currency in which the raw sensitivity is expressed, need to
be the same as the BaseCurrency in the simulation settings.
5. shiftSizeColumn: The shift size applied to compute the raw sensitivity, need to
be consistent to the sensitivity configuration.
6. baseNpvColumn: The base npv of the trade / nettingset / portfolio in currency.
Here is an example for an input file:

101
 #TradeId Factor_1 ShiftSize_1 Currency Base NPV Delta
0 Swap DiscountCurve/EUR/3/6M 0.0001 EUR 1335.27 5.05
1 Swap DiscountCurve/EUR/4/9M 0.0001 EUR 1335.27 0.35
2 Swap DiscountCurve/EUR/5/1Y 0.0001 EUR 1335.27 -5.41
3 Swap DiscountCurve/EUR/6/2Y 0.0001 EUR 1335.27 -0.22
4 Swap DiscountCurve/EUR/7/3Y 0.0001 EUR 1335.27 -0.32

The stress analytics configuration is similar to the one of the sensitivity calculation.
Listing 11 shows an example.

Listing 11: ORE analytic: stress

<Analytics>
<Analytic type="stress">
<Parameter name="active">Y</Parameter>
<Parameter name="marketConfigFile">[Link]</Parameter>
<Parameter name="stressConfigFile">[Link]</Parameter>
<Parameter name="pricingEnginesFile">../../Input/[Link]</Parameter>
<Parameter name="scenarioOutputFile">[Link]</Parameter>
<Parameter name="outputThreshold">0.000001</Parameter>
</Analytic>
</Analytics>

The parameters have the same interpretation as for the sensitivity analytic. The
configuration file for the stress scenarios is described in more detail in section 7.6.

The VaR ’analytics’ provide computation of Value-at-Risk measures based on the

sensitivity (delta, gamma, cross gamma) data above. Listing 12 shows a configuration
example.

Listing 12: ORE analytic: VaR

<Analytics>
<Analytic type="parametricVar">
<Parameter name="active">Y</Parameter>
<Parameter name="portfolioFilter">PF1|PF2</Parameter>
<Parameter name="sensitivityInputFile">
../Output/[Link],../Output/[Link]
</Parameter>
<Parameter name="covarianceInputFile">[Link]</Parameter>
<Parameter name="salvageCovarianceMatrix">N</Parameter>
<Parameter name="quantiles">0.01,0.05,0.95,0.99</Parameter>
<Parameter name="breakdown">Y</Parameter>
<!-- Delta, DeltaGammaNormal, Cornish-Fisher, Saddlepoint, MonteCarlo -->
<Parameter name="method">DeltaGammaNormal</Parameter>
<Parameter name="mcSamples">100000</Parameter>
<Parameter name="mcSeed">42</Parameter>
<Parameter name="outputFile">[Link]</Parameter>
</Analytic>
</Analytics>

The parameters have the following interpretation:

• portfolioFilter:
 Regular expression used to filter the portfolio for which VaR is
computed; if the filter is not provided, then the full portfolio is processed

102
 • sensitivityInputFile: Reference to the sensitivity (deltas, vegas, gammas)
and cross gamma input as generated by ORE in a comma separated list
• covarianceFile: Reference to the covariances input data; these are currently
not calculated in ORE and need to be provided externally, in a
blank/tab/comma separated file with three columns (factor1, factor2,
covariance), where factor1 and factor2 follow the naming convention used in
ORE’s sensitivity and cross gamma output files. Covariances need to be
consistent with the sensitivity data provided. For example, if sensitivity to
factor1 is computed by absolute shifts and expressed in basis points, then the
covariances with factor1 need to be based on absolute basis point shifts of
factor1; if sensitivity is due to a relative factor1 shift of 1%, then covariances
with factor1 need to be based on relative shifts expressed in percentages to, etc.
Also note that covariances are expected to include the desired holding period, i.e.
no scaling with square root of time etc is performed in ORE;
• salvageCovarianceMatrix: If set to Y, turn the input covariance matrix into a
valid (positive definite) matrix applying a Salvaging algorithm; if set to N, throw
an exception if the matrix is not positive definite
• quantiles: Several desired quantiles can be specified here in a comma separated
list; these lead to several columns of results in the output file, see below. Note
that e.g. the 1% quantile corresponds to the lower tail of the P&L distribution
(VaR), 99% to the upper tail.
• breakdown: If yes, VaR is computed by portfolio, risk class (All, Interest Rate,
FX, Inflation, Equity, Credit) and risk type (All, Delta & Gamma, Vega)
• method: Choices are Delta, DeltaGammaNormal, Cornish-Fisher, Saddlepoint,
MonteCarlo, see appendix A.19
• mcSamples: Number of Monte Carlo samples used when the MonteCarlo method
is chosen
• mcSeed: Random number generator seed when the MonteCarlo method is chosen
• outputFile: Output file name

The simm ’analytic’ provides computation of initial margin using ISDA’s Standard
Initial Margin Model (SIMM) based on sensitivities in the Common Risk Interchange
Format (CRIF) defined by ISDA. Listing 13 shows a configuration example.

103
Listing 13: ORE analytic: SIMM

<Analytics>
<Analytic type="simm">
<Parameter name="active">Y</Parameter>
<Parameter name="version">2.1</Parameter>
<Parameter name="crif">[Link]</Parameter>
<Parameter name="calculationCurrency">USD</Parameter>
<Parameter name="resultCurrency">USD</Parameter>
<Parameter name="enforceIMRegulations">true</Parameter>
<Parameter name="mporDays">1</Parameter>
<Parameter name="simmCalibration">[Link]</Parameter>
</Analytic>
<Analytics>

The parameters have the following interpretation:

• version: SIMM model version string
Allowable values: 1.0, 1.1, 1.2, 1.3, 1.3.38, 2.0, 2.1, 2.2, 2.3, 2.4 (or 2.3.8), 2.5,
2.5A, 2.6 (or 2.5.6)
Note that any new SIMM model versions are integrated into ORE with each
release, tested against the official ISDA SIMM unit tests.
• crif: Name of the CRIF file to be loaded
• calculationCurrency: Determines the Risk_FX CRIF entry that is ignored in
ISDA SIMM calculation
Allowable values: See Table 32 Currency.
• resultCurrency (optional): Currency for expressing the amounts in the
resulting SIMM report, by default set to the calculationCurrency.
Allowable values: See Table 32 Currency.
• enforceIMRegulations (optional): Whether to take collect/post regulations into
account.
Allowable values: Allowable boolean values are given in Table 46. Defaults to
False if omitted.
• mporDays (optional): Currency for expressing the amounts in the resulting
SIMM report, by default set to the calculationCurrency.
Allowable values: See Table 32 Currency.
• simmCalibration (optional): Name of the SIMM calibration configuration file.
See Section 7.11 SIMM Calibration.
The SIMM analytic requires minimal market data input and today’s market
configuration - FX rates for conversions calculation currency, USD and result currency.

The imschedule ’analytic’ provides initial margin calculation using the standard "IM
Schedule" method that is based on trade NPV, notional, end date and product class.
ORE expects the inputs in the form of a CRIF file. Listing 13 shows a configuration
example.

104
Listing 14: ORE analytic: IM Schedule

<Analytics>
<Analytic type="imschedule">
<Parameter name="active">Y</Parameter>
<Parameter name="crif">schedule_crif.csv</Parameter>
<Parameter name="calculationCurrency">USD</Parameter>
</Analytic>
<Analytics>

The input CRIF file here has two lines per trade, for RiskClass = PV respectively
RiskClass Notional. Additonally required columns are product class and end date, see
example 44. The idea is that the inputs can be externally provided. Therefore the IM
Schedule analytic does not require a portfolio. The alternative – ORE uses a portfolio
to compute NPV, imply product class and end date – has not been implemented yet.
Note that the IM Schedule product class has to be in
• Rates
• FX
• Equity
• Credit
• Commodity
in contrast to SIMM where we use the combined RatesFX product class.

7.2 Market: [Link]

This configuration file determines the subset of the ’market’ universe which is going to
be built by ORE. It is the user’s responsibility to make sure that this subset is
sufficient to cover the portfolio to be analysed. If it is not, the application will
complain at run time and exit.

We assume that the market configuration is provided in file [Link],

however, the file name can be chosen by the user. The file name needs to be entered
into the master configuration file [Link], see section 7.1.

The file starts and ends with the opening and closing tags <TodaysMarket> and
</TodaysMarket>. The file then contains configuration blocks for
• Discounting curves
• Index curves (to project index fixings)
• Yield curves (for other purposes, e.g. as benchmark curve for bond pricing)
• Swap index curves (to project Swap rates)
• FX spot rates
• Inflation index curves (to project zero or yoy inflation fixings)

105
 • Equity curves (to project forward prices)
• Default curves
• Swaption volatility structures
• Cap/Floor volatility structures
• FX volatility structures
• Inflation Cap/Floor volatility surfaces
• Equity volatility structures
• CDS volatility structures
• Base correlation structures
• Correlation structures
• Securities
There can be alternative versions of each block each labeled with a unique identifier
(e.g. Discount curve block with ID ’default’, discount curve block with ID ’ois’,
another one with ID ’xois’, etc). The purpose of these IDs will be explained at the end
of this section. We now discuss each block’s layout.

7.2.1 Discounting Curves

We pick one discounting curve block as an example here (see
Examples/Input/[Link]), the one with ID ’ois’

Listing 15: Discount curve block with ID ’ois’

<DiscountingCurves id="ois">
<DiscountingCurve currency="EUR">Yield/EUR/EUR1D</DiscountingCurve>
<DiscountingCurve currency="USD">Yield/USD/USD1D</DiscountingCurve>
<DiscountingCurve currency="GBP">Yield/GBP/GBP1D</DiscountingCurve>
<DiscountingCurve currency="CHF">Yield/CHF/CHF6M</DiscountingCurve>
<DiscountingCurve currency="JPY">Yield/JPY/JPY6M</DiscountingCurve>
<!-- ... -->
</DiscountingCurves>

This block instructs ORE to build five discount curves for the indicated currencies.
The string within the tags, e.g. Yield/EUR/EUR1D, uniquely identifies the curve to
be built. Curve Yield/EUR/EUR1D is defined in the curve configuration file explained
in section 7.8 below. In this case ORE is instructed to build an Eonia Swap curve
made of Overnight Deposit and Eonia Swap quotes. The right most token of the string
Yield/EUR/EUR1D (EUR1D) is user defined, the first two tokens Yield/EUR have to
be used to point to a yield curve in currency EUR.

7.2.2 Index Curves

See an excerpt of the index curve block with ID ’default’ from the same example file:

106
Listing 16: Index curve block with ID ’default’

<IndexForwardingCurves id="default">
<Index name="EUR-EURIBOR-3M">Yield/EUR/EUR3M</Index>
<Index name="EUR-EURIBOR-6M">Yield/EUR/EUR6M</Index>
<Index name="EUR-EURIBOR-12M">Yield/EUR/EUR12M</Index>
<Index name="EUR-EONIA">Yield/EUR/EUR1D</Index>
<Index name="USD-LIBOR-3M">Yield/USD/USD3M</Index>
<!-- ... -->
</IndexForwardingCurves>

This block of curve specifications instructs ORE to build another set of yield curves,
unique strings (e.g. Yield/EUR/EUR6M etc.) point to the [Link] file
where these curves are defined. Each curve is then associated with an index name (of
format Ccy-IndexName-Tenor, e.g. EUR-EURIBOR-6M) so that ORE will project the
respective index using the selected curve (e.g. Yield/EUR/EUR6M).

7.2.3 Yield Curves

See an excerpt of the yield curve block with ID ’default’ from the same example file:

Listing 17: Yield curve block with ID ’default’

<YieldCurves id="default">
<YieldCurve name="BANK_EUR_LEND">Yield/EUR/BANK_EUR_LEND</YieldCurve>
<YieldCurve name="BANK_EUR_BORROW">Yield/EUR/BANK_EUR_BORROW</YieldCurve>
<!-- ... -->
</YieldCurves>

This block of curve specifications instructs ORE to build another set of yield curves,
unique strings (e.g. Yield/EUR/EUR6M etc.) point to the [Link] file
where these curves are defined. Other than discounting and index curves the yield
curves in this block are not tied to a particular purpose. The curves defined in this
block typically include
• additional curves needed in the XVA post processor, e.g. for the FVA calculation
• benchmark curves used for bond pricing

7.2.4 Swap Index Curves

The following is an excerpt of the swap index curve block with ID ’default’ from the
same example file:

107
Listing 18: Swap index curve block with ID ’default’

<SwapIndexCurves id="default">
<SwapIndex name="EUR-CMS-1Y">
<Index>EUR-EURIBOR-6M</Index>
<Discounting>EUR-EONIA</Discounting>
</SwapIndex>
<SwapIndex name="EUR-CMS-30Y">
<Index>EUR-EURIBOR-6M</Index>
<Discounting>EUR-EONIA</Discounting>
</SwapIndex>
<!-- ... -->
</SwapIndexCurves>

These instructions do not build any additional curves. They only build the respective
swap index objects and associate them with the required index forwarding and
discounting curves already built above. This enables a swap index to project the fair
rate of forward starting Swaps. Swap indices are also containers for conventions.
Swaption volatility surfaces require two swap indices each available in the market
object, a long term and a short term swap index. The curve configuration file below
will show that in particular the required short term index has term 1Y, and the
required long term index has 30Y term. This is why we build these two indices at this
point.

7.2.5 FX Spot
The following is an excerpt of the FX spot block with ID ’default’ from the same
example file:

Listing 19: FX spot block with ID ’default’

<FxSpots id="default">
<FxSpot pair="EURUSD">FX/EUR/USD</FxSpot>
<FxSpot pair="EURGBP">FX/EUR/GBP</FxSpot>
<FxSpot pair="EURCHF">FX/EUR/CHF</FxSpot>
<FxSpot pair="EURJPY">FX/EUR/JPY</FxSpot>
<!-- ... -->
</FxSpots>

This block instructs ORE to provide four FX quotes, all quoted with target currency
EUR so that foreign currency amounts can be converted into EUR via multiplication
with that rate.

7.2.6 FX Volatilities
The following is an excerpt of the FX Volatilities block with ID ’default’ from the same
example file:

108
Listing 20: FX volatility block with ID ’default’

<FxVolatilities id="default">
<FxVolatility pair="EURUSD">FXVolatility/EUR/USD/EURUSD</FxVolatility>
<FxVolatility pair="EURGBP">FXVolatility/EUR/GBP/EURGBP</FxVolatility>
<FxVolatility pair="EURCHF">FXVolatility/EUR/CHF/EURCHF</FxVolatility>
<FxVolatility pair="EURJPY">FXVolatility/EUR/JPY/EURJPY</FxVolatility>
<!-- ... -->
</FxVolatilities>

This instructs ORE to build four FX volatility structures for all FX pairs with target
currency EUR, see curve configuration file for the definition of the volatility structure.

7.2.7 Swaption Volatilities

The following is an excerpt of the Swaption Volatilities block with ID ’default’ from
the same example file:

Listing 21: Swaption volatility block with ID ’default’

<SwaptionVolatilities id="default">
<SwaptionVolatility currency="EUR">SwaptionVolatility/EUR/EUR_SW_N</SwaptionVolatility>
<SwaptionVolatility currency="USD">SwaptionVolatility/USD/USD_SW_N</SwaptionVolatility>
<SwaptionVolatility currency="GBP">SwaptionVolatility/GBP/GBP_SW_N</SwaptionVolatility>
<SwaptionVolatility currency="CHF">SwaptionVolatility/CHF/CHF_SW_N</SwaptionVolatility>
<SwaptionVolatility currency="JPY">SwaptionVolatility/CHF/JPY_SW_N</SwaptionVolatility>
</SwaptionVolatilities>

This instructs ORE to build five Swaption volatility structures, see the curve
configuration file for the definition of the volatility structure. The latter token (e.g.
EUR_SW_N) is user defined and will be found in the curve configuration’s CurveId
tag.

7.2.8 Cap/Floor Volatilities

The following is an excerpt of the Cap/Floor Volatilities block with ID ’default’ from
the same example file:

Listing 22: Cap/Floor volatility block with ID ’default’

<CapFloorVolatilities id="default">
<CapFloorVolatility currency="EUR">CapFloorVolatility/EUR/EUR_CF_N</CapFloorVolatility>
<CapFloorVolatility currency="USD">CapFloorVolatility/USD/USD_CF_N</CapFloorVolatility>
<CapFloorVolatility currency="GBP">CapFloorVolatility/GBP/GBP_CF_N</CapFloorVolatility>
</CapFloorVolatilities>

This instructs ORE to build three Cap/Floor volatility structures, see the curve
configuration file for the definition of the volatility structure. The latter token (e.g.
EUR_CF_N) is user defined and will be found in the curve configuration’s CurveId
tag.

109
7.2.9 Default Curves
The following is an excerpt of the Default Curves block with ID ’default’ from the
same example file:

Listing 23: Default curves block with ID ’default’

<DefaultCurves id="default">
<DefaultCurve name="BANK">Default/USD/BANK_SR_USD</DefaultCurve>
<DefaultCurve name="CPTY_A">Default/USD/CUST_A_SR_USD</DefaultCurve>
<DefaultCurve name="CPTY_B">Default/USD/CUST_A_SR_USD</DefaultCurve>
<!-- ... -->
</DefaultCurves>

This instructs ORE to build a set of default probability curves, again defined in the
curve configuration file. Each curve is then associated with a name (BANK,
CUST_A) for subsequent lookup. As before, the last token (e.g. BANK_SR_USD) is
user defined and will be found in the curve configuration’s CurveId tag.

7.2.10 Securities
The following is an excerpt of the Security block with ID ’default’ from the same
example file:

Listing 24: Securities block with ID ’default’

<Securities id="default">
<Security name="SECURITY_1">Security/SECURITY_1</Security>
</Securities>

The pricing of bonds includes (among other components) a security specific spread and
rate. This block links a security name to a spread and rate pair defined in the curve
configuration file. This name may then be referenced as the security id in the bond
trade definition.

7.2.11 Equity Curves

The following is an excerpt of the Equity curves block with ID ’default’ from the same
example file:

Listing 25: Equity curves block with ID ’default’

<EquityCurves id="default">
<EquityCurve name="SP5">Equity/USD/SP5</EquityCurve>
<EquityCurve name="Lufthansa">Equity/EUR/Lufthansa</EquityCurve>
</EquityCurves>

This instructs ORE to build a set of equity curves, again defined in the curve
configuration file. Each equity curve after construction will consist of a spot equity
price, as well as a term structure of dividend yields, which can be used to determine

110
forward prices. This object is then associated with a name (e.g. SP5) for subsequent
lookup.

7.2.12 Equity Volatilities

The following is an excerpt of the equity volatilities block with ID ’default’ from the
same example file:

Listing 26: EQ volatility block with ID ’default’

<EquityVolatilities id="default">
<EquityVolatility name="SP5">EquityVolatility/USD/SP5</EquityVolatility>
<EquityVolatility name="Lufthansa">EquityVolatility/EUR/Lufthansa</EquityVolatility>
</EquityVolatilities>

This instructs ORE to build two equity volatility structures for SP5 and Lufthansa,
respectively. See the curve configuration file for the definition of the equity volatility
structure.

7.2.13 Inflation Index Curves

The following is an excerpt of the Zero Inflation Index Curves block with ID ’default’
from the sample example file:

Listing 27: Zero Inflation Index Curves block with ID ’default’

<ZeroInflationIndexCurves id="default">
<ZeroInflationIndexCurve name="EUHICPXT">
Inflation/EUHICPXT/EUHICPXT_ZC_Swaps
</ZeroInflationIndexCurve>
<ZeroInflationIndexCurve name="FRHICP">
Inflation/FRHICP/FRHICP_ZC_Swaps
</ZeroInflationIndexCurve>
<ZeroInflationIndexCurve name="UKRPI">
Inflation/UKRPI/UKRPI_ZC_Swaps
</ZeroInflationIndexCurve>
<ZeroInflationIndexCurve name="USCPI">
Inflation/USCPI/USCPI_ZC_Swaps
</ZeroInflationIndexCurve>
...
</ZeroInflationIndexCurves>

This instructs ORE to build a set of zero inflation index curves, which are defined in
the curve configuration file. Each curve is then associated with an index name (like
e.g. EUHICPXT or UKRPI). The last token (e.g. EUHICPXT_ZC_Swap) is user
defined and will be found in the curve configuration’s CurveId tag.
In a similar way, Year on Year index curves are specified:

111
Listing 28: YoY Inflation Index Curves block with ID ’default’

<YYInflationIndexCurves id="default">
<YYInflationIndexCurve name="EUHICPXT">
Inflation/EUHICPXT/EUHICPXT_YY_Swaps
</YYInflationIndexCurve>
...
</YYInflationIndexCurves>

Note that the index name is the same as in the corresponding zero index curve
definition, but the token corresponding to the CurveId tag is different. This is because
the actual underlying index (and in particular its fixings) are shared between the two
index types, while different projection curves are used to forecast future index
realisations.

7.2.14 Inflation Cap/Floor Volatility Surfaces

The following is an excerpt of the Inflation Cap/Floor Volatility Surfaces blocks with
ID ’default’ from the sample example file:

Listing 29: Inflation Cap/Floor Volatility Surfaces block with ID ’default’

<YYInflationCapFloorVolatilities id="default">
<YYInflationCapFloorVolatility name="EUHICPXT">
InflationCapFloorVolatility/EUHICPXT/EUHICPXT_YY_CF
</InflationCapFloorVolatility>
</YYInflationCapFloorVolatilities>

<ZeroInflationCapFloorVolatilities id="default">
<ZeroInflationCapFloorVolatility name="UKRPI">
InflationCapFloorVolatility/UKRPI/UKRPI_ZC_CF
</ZeroInflationCapFloorVolatility>
<ZeroInflationCapFloorVolatility name="EUHICPXT">
InflationCapFloorVolatility/EUHICPXT/EUHICPXT_ZC_CF
</ZeroInflationCapFloorVolatility>
<ZeroInflationCapFloorVolatility name="USCPI">
InflationCapFloorVolatility/USCPI/USCPI_ZC_CF
</ZeroInflationCapFloorVolatility>
</ZeroInflationCapFloorVolatilities>

This instructs ORE to build a set of year-on-year and zero inflation cap floor volatility
surfaces, which are defined in the curve configuration file. Each surface is associated
with an index name. The last token (e.g. EUHICPXT_ZC_CF) is user defined and
will be found in the curve configuration’s CurveId tag.

7.2.15 CDS Volatility Structures

CDS volatility structures are configured as follows

112
Listing 30: CDS volatility structure block with ID ’default’

<CDSVolatilities id="default">
<CDSVolatility name="CDSVOL_A">CDSVolatility/CDXIG</CDSVolatility>
<CDSVolatility name="CDSVOL_B">CDSVolatility/CDXHY</CDSVolatility>
</CDSVolatilities>

The composition of the CDS volatility structures is defined in the curve configuration.

7.2.16 Base Correlation Structures

Base correlation structures are configured as follows

Listing 31: Base Correlations block with ID ’default’

<BaseCorrelations id="default">
<BaseCorrelation name="CDXIG">BaseCorrelation/CDXIG</BaseCorrelation>
</BaseCorrelations>

The composition of the base correlation structure is defined in the curve configuration.

7.2.17 Correlation Structures

Correlation structures are configured as follows

Listing 32: Correlations block with ID ’default’

<Correlations id="default">
<Correlation name="EUR-CMS-10Y:EUR-CMS-1Y">Correlation/EUR-CORR</Correlation>
<Correlation name="USD-CMS-10Y:USD-CMS-1Y">Correlation/USD-CORR</Correlation>
</Correlations>

The composition of the correlation structure is defined in the curve configuration.

7.2.18 Market Configurations

Finally, representatives of each type of block (Discount Curves, Index Curves, Volatility
structures, etc, up to Inflation Cap/Floor Price Surfaces) can be bundled into a market
configuration. This is done by adding the following to the [Link] file:

113
Listing 33: Market configurations

<Configuration id="default">
<DiscountingCurvesId>xois_eur</DiscountingCurvesId>
</Configuration>
<Configuration id="collateral_inccy">
<DiscountingCurvesId>ois</DiscountingCurvesId>
</Configuration>
<Configuration id="collateral_eur">
<DiscountingCurvesId>xois_eur</DiscountingCurvesId>
</Configuration>
<Configuration id="libor">
<DiscountingCurvesId>inccy_swap</DiscountingCurvesId>
</Configuration>

When ORE constructs the market object, all market configurations will be build and
labelled using the ’Configuration Id’. This allows configuring a market setup for
different alternative purposes side by side in the same [Link] file. Typical
use cases are
• different discount curves needed for model calibration and risk factor evolution,
respectively
• different discount curves needed for collateralised and uncollateralised derivatives
pricing.
The former is actually used throughout the Examples section. Each master input file
[Link] has a Markets section (see 7.1) where four market configuration IDs have to
be provided - the ones used for ’lgmcalibration’, ’fxcalibration’, ’pricing’ and
’simulation’ (i.e. risk factor evolution).

The configuration ID concept extends across all curve and volatility objects though
currently used only to distinguish discounting.

114
7.3 Pricing Engines: [Link]
The pricing engine configuration file is provided to select pricing models and pricing
engines by product type.

7.3.1 Product Type: Ascot

Used by trade type: Ascot
Available Model/Engine pairs:
• BlackScholes/Intrinsic
Engine description:
BlackScholes/Intrinsic builds a IntrinsicAscotEngine. A sample configuration is shown
in listing 34.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="Ascot">
<Model>BlackScholes</Model>
<ModelParameters/>
<Engine>Intrinsic</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">EQ_FD</Parameter>
</EngineParameters>
</Product>

Listing 34: Configuration for Product Ascot, Model: BlackScholes, Engine: Intrinsic

7.3.2 Product Type: Bond

Used by trade type: Bond
Available Model/Engine pairs:
• DiscountedCashflows/DiscountingRiskyBondEngine
• DiscountedCashflows/DiscountingRiskyBondEngineMultiState
Engine description:
DiscountedCashflows/DiscountingRiskyBondEngine builds a
DiscountingRiskyBondEngine. A sample configuration is shown in listing 35.
The parameters have the following meaning:
• TimestepPeriod: discretization interval for zero bond pricing
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="Bond">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>DiscountingRiskyBondEngine</Engine>
<EngineParameters>
<Parameter name="TimestepPeriod">3M</Parameter>

115
 <Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 35: Configuration for Product Bond, Model DiscountedCashflows, Engine Discountin-
gRiskyBondEngine
DiscountedCashflows/DiscountingRiskyBondEngineMultiState builds a
DiscountingRiskyBondEngineMultiState for use in the Credit Model. We refer to the
credit model documentation for further details.

7.3.3 Product Type: BondOption

Used by trade type: BondOption
Available Model/Engine pairs:
• Black/BlackBondOptionEngine
Engine description:
Black/BlackBondOptionEngine builds a BlackBondOptionEngine. A sample
configuration is shown in listing 36.
The parameters have the following meaning:
• TimestepPeriod: discretization interval for zero bond pricing
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="BondOption">
<Model>Black</Model>
<ModelParameters/>
<Engine>BlackBondOptionEngine</Engine>
<EngineParameters>
<Parameter name="TimestepPeriod">3M</Parameter>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 36: Configuration for Product BondOption, Model Black, Engine BlackBondOptio-
nEngine

7.3.4 Product Type: ConvertibleBond

Used by trade type: ConvertibleBond
Available Model/Engine pairs: DefaultableEquityJumpDiffusion/FD
• DefaultableEquityJumpDiffusion/FD
Engine description:
DefaultableEquityJumpDiffusion/FD builds a
FdDefaultableEquityJumpDiffusionConvertibleBondEngine following Andersen, L., and
Buffum, D.: Calibration and Implementation of Convertible Bond Models (2002):
The model dynamics for the stock price S(t) is given by

116
 dS/S(t− ) = (r(t) − q(t) + ηh(t, S(t− )))dt + σ(t)dW (t) − ηdN (t) (1)

with a risk free rate r(t), a continuous dividend yield q(t), a default intensity h(t, S), a
volatility σ(t), a default loss fraction for the equity η ∈ [0, 1] and a Cox process N (t)
with

Et (dN (t)) = h(t, S(t− ))dt (2)

The notation S(t− ) is shorthand for limϵ↓0 S(t − ϵ). The first jump of N (t) represents
the default of the equity. See equation (1) in Andersen, Buffum. We support a local
default intensity of the form
 p
S(0)
h(t, S(t)) = h0 (t) (3)
S(t)

with a deterministic function h0 (t) that is independent from S(t) and a parameter
p ≥ 0. The parameters p and η can be set in the pricing engine configuration. More
details on the pricing model is available in a separate model documentation. A sample
configuration is shown in listing 37.
The parameters have the following meaning:
• p: the model parameter p
• eta: the model parameter eta
• AdjustEquityForward: If false, the term ηh(t, ez ) in the coefficient of vz in the
convertible bond pricing pde (see separate model documentation) is set to zero,
i.e. the hazard rate h is still used in the discounting term, but the equity drift is
not corrected upwards accordingly. The default value is true.
• AdjustEquityVolatility: If false, the market equity volatility input is not
adjusted, but directly used in the pricing model. This setting is only possible if
p = 0. It will then set the weighting with the market survival probability S(0, ti )
in the context of formula for the equity volatility match (see separate model
documentation) to zero, i.e. V is taken as the market implied volatility without
adjustment. The default value is true.
• AdjustDiscounting: If false, the adjustment of the discounting rate r to the
benchmark curve b is suppressed, i.e. the change of the bond pricing PDE to the
bond pricing pde with benchmark curve (see separate model documentation) is
not made (see also section “Curves used in practice” in separate model
documentation). The default value is true.
• AdjustCreditSpreadToRR: If true, the credit curve h(·) is adjusted by a factor
1−R
1−ρ
where R is the recovery rate associated to the market default curve and ρ is
the recovery rate of the bond. Usually, R = ρ, i.e. the bond recovery rate is the
same as the recovery rate of the associated credit curve. In this case, the flag has
no effect, since the multiplier is 1. However, when ρ is overwritten with zero due
to the flag ZeroRecoveryOverwrite set to true, the flag AdjustCreditSpreadToRR
should also be set to true. The default value is false.

117
 • ZeroRecoveryOverwrite: If true, the recovery rate ρ of the convertible bond is
overwritten with zero. This option is usually used in conjunction with
AdjustCreditSpreadToRR set to true (see below). The default value is false.
• TreatSecuritySpreadAsCreditSpread: If true, the security spread is not
incoroporated into the benchmark curve b as described above, but rather added
as a spread on top of the credit curve, i.e. it is added to h(t, ez ). For
exchangeables, the security spread is added to both hB and hS , i.e. it
simultaneously increases the credit pread of both the equity and the bond
component. Since the security spread is understood as an effective discounting
spread, it is scaled by s → s/(1 − ρ) before it is added to h, where ρ is the
recovery rate of the bond.
• MesherIsStatic: whether to use the same finite-difference mesher under scenario /
sensi calculations
• [Link]: The model is calibrated on a configurable set of times
. All tenors from the specified grid before the maturity date of the convertible
bond are kept and the maturity date itself is added to the resulting grid to avoid
calibration for times beyond the bond maturity and at the same time ensuring
that we do not need to extrapolate model functions beyond the last calibration
point in the pricing.
• [Link]: The number of state grid points of the
Fokker-Planck PDE in the calibration phase
• [Link]: The mesher epsilon of the Fokker-Planck PDE in the
calibration phase
• [Link]: The mesher scaling multiplier of the Fokker-Planck
PDE in the calibration phase
• [Link]: bootstrap strategy: “Simultaneously” or “Alternating”, see
separate model docs for further details
• [Link]: The number of time steps per year to be used for the
pricing PDE
• [Link]: The number of state grid points to be used for the
pricing PDE
• [Link]: The mesher epsilon for the pricing PDE
• [Link]: The mesher scaling multiplier for the pricing PDE
• ConversionRatioDiscretizationGrid: Multipliers to be used for conversion ratio
discretization in the presence of conversion resets / adjustments. See separate
model documentation for more details.
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="ConvertibleBond">
<Model>DefaultableEquityJumpDiffusion</Model>
<ModelParameters>
<Parameter name="p">0.0</Parameter>
<Parameter name="eta">1.0</Parameter>

118
 <Parameter name="AdjustEquityForward">true</Parameter>
<Parameter name="AdjustEquityVolatility">false</Parameter>
<Parameter name="AdjustDiscounting">false</Parameter>
<Parameter name="AdjustCreditSpreadToRR">true</Parameter>
<Parameter name="ZeroRecoveryOverwrite">true</Parameter>
<Parameter name="TreatSecuritySpreadAsCreditSpread">true</Parameter>
</ModelParameters>
<Engine>FD</Engine>
<EngineParameters>
<Parameter name="MesherIsStatic">true</Parameter>
<Parameter name="[Link]">
6M,1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,25Y,30Y,40Y,50Y
</Parameter>
<Parameter name="[Link]">24</Parameter>
<Parameter name="[Link]">400</Parameter>
<Parameter name="[Link]">1E-5</Parameter>
<Parameter name="[Link]">1.5</Parameter>
<Parameter name="[Link]">Alternating</Parameter>
<Parameter name="[Link]">24</Parameter>
<Parameter name="[Link]">100</Parameter>
<Parameter name="[Link]">1E-4</Parameter>
<Parameter name="[Link]">1.5</Parameter>
<Parameter name="[Link]">
0.5,0.55,0.6,0.65,0.7,0.75,
0.8,0.85,0.9,0.95,1.0,1.05,
1.1,1.15,1.2,1.25,1.5,1.75,2.0
</Parameter>
<Parameter name="SensitivityTemplate">EQ_FD</Parameter>
</EngineParameters>
</Product>

Listing 37: Configuration for Product ConvertibleBond, Model DefaultableEquityJumpDiffu-

sion, Engine FD

7.3.5 Product Type: CreditLinkedSwap

Used by trade type: CreditLinkedSwap
Available Model/Engine pairs:
• DiscountedCashflows/DiscountingCreditLinkedSwapEngine
Engine description:
DiscountedCashflows/DiscountingCreditLinkedSwapEngine builds a
DiscountingCreditLinkedSwapEngine. A sample configuration is shown in listing 38.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CreditLinkedSwap">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>DiscountingCreditLinkedSwapEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

119
Listing 38: Configuration for Product CreditLinkedSwap, Model DiscountedCashflows, Engine
DiscountingCreditLinkedSwapEngine

7.3.6 Product Type: EuropeanSwaption

Used by trade type: Swaption, for European exercise on vanilla underlying coupon
types
Available Model/Engine pairs:
• BlackBachelier/BlackBachelierSwaptionEngine
• LGM/Grid
• LGM/FD
• LGM/MC
• LGM/AMC
Engine description:
BlackBachelier/BlackBachelierSwaptionEngine builds a BlackMultiLegOptionEngine .
A sample configuration is shown in listing 39
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EuropeanSwaption">
<Model>BlackBachelier</Model>
<ModelParameters/>
<Engine>BlackBachelierSwaptionEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 39: Configuration for Product EuropeanSwaption, Model BlackBachelier, Engine Black-
BachelierSwaptionEngine
LGM/Grid builds a NumericLgmMultiLegOptionEngine using LgmConvoluationSolver
as a solver. The rollback follows the paper “Hagan, P: Methodology for callable swaps
and Bermudan exercise into swaptions”. A sample configuration is shown in listing 40
The parameters have the following meaning:
• Calibration: Bootstrap, BestFit, None
• CalibrationStrategy: CoterminalDealStrike, CoterminalATM
• ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept
• Reversion: The mean reversion
• ReversionType: Hagan, HullWhite

120
 • Volatility: The volatility (start value for calibration if calibrated)
• VolatilityType: Hagan, HullWhite
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• FloatSpreadMapping: mapping of float spreads in analytic swaption pricing for
model calibration: proRata, nextCoupon, simple, optional, defaults to proRata.
• sy, sx: Number of covered standard deviations (notation as in Hagan’s paper)
• ny, nx: Number of grid points for numerical integration (notation as in Hagan’s
paper)
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EuropeanSwaption">
<Model>LGM</Model>
<ModelParameters>
<Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalDealStrike</Parameter>
<Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="VolatilityType">Hagan</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.20</Parameter>
<Parameter name="FloatSpreadMapping">proRata</Parameter>
</ModelParameters>
<Engine>Grid</Engine>
<EngineParameters>
<Parameter name="sy">5.0</Parameter>
<Parameter name="ny">30</Parameter>
<Parameter name="sx">5.0</Parameter>
<Parameter name="nx">30</Parameter>
<Parameter name="SensitivityTemplate">IR_FD</Parameter>
</EngineParameters>
</Product>

Listing 40: Configuration for Product EuropeanSwaption, Model LGM, Engine Grid
LGM/FD builds a NumericLgmMultiLegOptionEngine using LgmFdSolver as a solver
using finite difference. A sample configuration is shown in listing 41
The parameters have the following meaning:
• Calibration: Bootstrap, BestFit, None
• CalibrationStrategy: CoterminalDealStrike, CoterminalATM
• ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept
• Reversion: The mean reversion
• ReversionType: Hagan, HullWhite

121
 • Volatility: The volatility (start value for calibration if calibrated)
• VolatilityType: Hagan, HullWhite
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• Scheme: The finite difference scheme to use
• StateGridPoints: The number of grid points in state direction
• TimeStepsPerYear: The number of time steps per year to use
• MesherEpsilon: determines the covered probability mass, mass outside state grid
is Φ−1 (1 − 2ϵ)
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EuropeanSwaption">
<Model>LGM</Model>
<ModelParameters>
<Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalDealStrike</Parameter>
<Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="VolatilityType">Hagan</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.20</Parameter>
</ModelParameters>
<Engine>FD</Engine>
<EngineParameters>
<Parameter name="Scheme">Douglas</Parameter>
<Parameter name="StateGridPoints">64</Parameter>
<Parameter name="TimeStepsPerYear">24</Parameter>
<Parameter name="MesherEpsilon">1E-4</Parameter>
</EngineParameters>
</EngineParameters>
</Product>

Listing 41: Configuration for Product EuropeanSwaption, Model LGM, Engine FD

LGM/MC builds a McMultiLegOptionEngine. A sample configuration is shown in
listing 42
The parameters have the following meaning:
• Calibration: Bootstrap, BestFit, None
• CalibrationStrategy: CoterminalDealStrike, CoterminalATM
• ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept
• Reversion: The mean reversion
• ReversionType: Hagan, HullWhite
• Volatility: The volatility (start value for calibration if calibrated)

122
 • VolatilityType: Hagan, HullWhite
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• [Link]: The sequence type for the traning phase, can be
MersenneTwister+, MersenneTwisterAntithetc+, Sobol+, Burley2020Sobol+,
SobolBrownianBridge+, Burley2020SobolBrownianBridge+
• [Link]: The seed for the random number generation in the training phase
• [Link]: The number of samples to be used for the training phase
• [Link]: The sequence type for the pricing phase, same values allowed
as for training
• [Link]: The type of basis function system to be used for the
regression analysis, can be Monomial+, Laguerre+, Hermite+, Hyperbolic+,
Legendre+, Chbyshev+, Chebyshev2nd+
• BasisFunctionOrder: The order of the basis function system to be used
• [Link]: The seed for the random number generation in the pricing
• [Link]: The number of samples to be used for the pricing phase. If this
number is zero, no pricing run is performed, instead the (T0) NPV is estimated
from the training phase (this result is used to fill the T0 slice of the NPV cube)
• BrownianBridgeOrdering: variate ordering for Brownian bridges, can be Steps+,
Factors+, Diagonal+
• SobolDirectionIntegers: direction integers for Sobol generator, can be Unit+,
Jaeckel+, SobolLevitan+, SobolLevitanLemieux+, JoeKuoD5+, JoeKuoD6+,
JoeKuoD7+, Kuo+, Kuo2+, Kuo3+
• MinObsDate: if true the conditional expectation of each cashflow is taken from
the minimum possible observation date (i.e. the latest exercise or simulation date
before the cashflow’s event date); recommended setting is true+
• RegressorModel: Simple, LaggedFX. If not given, it defaults to Simple.
Depending on the choice the regressor is built as follows:
– Simple: For an observation date the full model state observed on this date is
included in the regressor. No past states are included though.
– LaggedFX: For an observation date the full model state observed on this
date is included in the regressor. In addition, past FX states that are
relevant for future cashflows are included. For example, for a FX resettable
cashflow the FX state observed on the FX reset date is included.
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EuropeanSwaption">
<Model>LGM</Model>
<ModelParameters>
<Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalDealStrike</Parameter>

123
 <Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="VolatilityType">Hagan</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.20</Parameter>
</ModelParameters>
<Engine>MC</Engine>
<EngineParameters>
<Parameter name="[Link]">MersenneTwisterAntithetic</Parameter>
<Parameter name="[Link]">42</Parameter>
<Parameter name="[Link]">10000</Parameter>
<Parameter name="[Link]">Monomial</Parameter>
<Parameter name="[Link]">6</Parameter>
<Parameter name="[Link]">SobolBrownianBridge</Parameter>
<Parameter name="[Link]">17</Parameter>
<Parameter name="[Link]">0</Parameter>
<Parameter name="BrownianBridgeOrdering">Steps</Parameter>
<Parameter name="SobolDirectionIntegers">JoeKuoD7</Parameter>
<Parameter name="MinObsDate">true</Parameter>
<Parameter name="RegressorModel">Simple</Parameter>
<Parameter name="SensitivityTemplate">IR_MC</Parameter>
</EngineParameters>
</Product>

Listing 42: Configuration for Product EuropeanSwaption, Model BlackBachelier, Engine Black-
BachelierSwaptionEngine
LGM/AMC builds a McMultiLegOptionEngine for use in AMC simulations. We refer
to the AMC module documentation for further details.

7.3.7 Product Type: BermudanSwaption

Used by trade type: Swaption, for Bermudan exercise or European exercise on
non-vanilla underlying coupon types
Available Model/Engine pairs:
• LGM/Grid
• LGM/FD
• LGM/MC
• LGM/AMC
Engine description:
LGM/Grid builds a NumericLgmMultiLegOptionEngine using LgmConvoluationSolver
as a solver. The rollback follows the paper “Hagan, P: Methodology for callable swaps
and Bermudan exercise into swaptions”. A sample configuration is shown in listing 43
The parameters have the following meaning:
• Calibration: Bootstrap, BestFit, None
• CalibrationStrategy: CoterminalDealStrike, CoterminalATM

124
 • ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept
• Reversion: The mean reversion
• ReversionType: Hagan, HullWhite
• Volatility: The volatility (start value for calibration if calibrated)
• VolatilityType: Hagan, HullWhite
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• sy, sx: Number of covered standard deviations (notation as in Hagan’s paper)
• ny, nx: Number of grid points for numerical integration (notation as in Hagan’s
paper)
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="BermudanSwaption">
<Model>LGM</Model>
<ModelParameters>
<Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalDealStrike</Parameter>
<Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="VolatilityType">Hagan</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.20</Parameter>
</ModelParameters>
<Engine>Grid</Engine>
<EngineParameters>
<Parameter name="sy">5.0</Parameter>
<Parameter name="ny">30</Parameter>
<Parameter name="sx">5.0</Parameter>
<Parameter name="nx">30</Parameter>
<Parameter name="SensitivityTemplate">IR_FD</Parameter>
</EngineParameters>
</Product>

Listing 43: Configuration for Product BermudanSwaption, Model LGM, Engine Grid
LGM/FD builds a NumericLgmMultiLegOptionEngine using LgmFdSolver as a solver
using finite difference. A sample configuration is shown in listing 44
The parameters have the following meaning:
• Calibration: Bootstrap, BestFit, None
• CalibrationStrategy: CoterminalDealStrike, CoterminalATM
• ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept
• Reversion: The mean reversion

125
 • ReversionType: Hagan, HullWhite
• Volatility: The volatility (start value for calibration if calibrated)
• VolatilityType: Hagan, HullWhite
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• Scheme: The finite difference scheme to use
• StateGridPoints: The number of grid points in state direction
• TimeStepsPerYear: The number of time steps per year to use
• MesherEpsilon: determines the covered probability mass, mass outside state grid
is Φ−1 (1 − 2ϵ)
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="BermudanSwaption">
<Model>LGM</Model>
<ModelParameters>
<Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalDealStrike</Parameter>
<Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="VolatilityType">Hagan</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.20</Parameter>
</ModelParameters>
<Engine>FD</Engine>
<EngineParameters>
<Parameter name="Scheme">Douglas</Parameter>
<Parameter name="StateGridPoints">64</Parameter>
<Parameter name="TimeStepsPerYear">24</Parameter>
<Parameter name="MesherEpsilon">1E-4</Parameter>
</EngineParameters>
</Product>

Listing 44: Configuration for Product BermudanSwaption, Model LGM, Engine FD

LGM/MC builds a McMultiLegOptionEngine. A sample configuration is shown in
listing 45
The parameters have the following meaning:
• Calibration: Bootstrap, BestFit, None
• CalibrationStrategy: CoterminalDealStrike, CoterminalATM
• ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept
• Reversion: The mean reversion
• ReversionType: Hagan, HullWhite

126
 • Volatility: The volatility (start value for calibration if calibrated)
• VolatilityType: Hagan, HullWhite
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• [Link]: The sequence type for the traning phase, can be
MersenneTwister+, MersenneTwisterAntithetc+, Sobol+, Burley2020Sobol+,
SobolBrownianBridge+, Burley2020SobolBrownianBridge+
• [Link]: The seed for the random number generation in the training phase
• [Link]: The number of samples to be used for the training phase
• [Link]: The sequence type for the pricing phase, same values allowed
as for training
• [Link]: The type of basis function system to be used for the
regression analysis, can be Monomial+, Laguerre+, Hermite+, Hyperbolic+,
Legendre+, Chbyshev+, Chebyshev2nd+
• BasisFunctionOrder: The order of the basis function system to be used
• [Link]: The seed for the random number generation in the pricing
• [Link]: The number of samples to be used for the pricing phase. If this
number is zero, no pricing run is performed, instead the (T0) NPV is estimated
from the training phase (this result is used to fill the T0 slice of the NPV cube)
• BrownianBridgeOrdering: variate ordering for Brownian bridges, can be Steps+,
Factors+, Diagonal+
• SobolDirectionIntegers: direction integers for Sobol generator, can be Unit+,
Jaeckel+, SobolLevitan+, SobolLevitanLemieux+, JoeKuoD5+, JoeKuoD6+,
JoeKuoD7+, Kuo+, Kuo2+, Kuo3+
• MinObsDate: if true the conditional expectation of each cashflow is taken from
the minimum possible observation date (i.e. the latest exercise or simulation date
before the cashflow’s event date); recommended setting is true+
• RegressorModel: Simple, LaggedFX. If not given, it defaults to Simple.
Depending on the choice the regressor is built as follows:
– Simple: For an observation date the full model state observed on this date is
included in the regressor. No past states are included though.
– LaggedFX: For an observation date the full model state observed on this
date is included in the regressor. In addition, past FX states that are
relevant for future cashflows are included. For example, for a FX resettable
cashflow the FX state observed on the FX reset date is included.
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="BermudanSwaption">
<Model>LGM</Model>
<ModelParameters>

127
 <Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalDealStrike</Parameter>
<Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="VolatilityType">Hagan</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.20</Parameter>
</ModelParameters>
<Engine>MC</Engine>
<EngineParameters>
<Parameter name="[Link]">MersenneTwisterAntithetic</Parameter>
<Parameter name="[Link]">42</Parameter>
<Parameter name="[Link]">10000</Parameter>
<Parameter name="[Link]">Monomial</Parameter>
<Parameter name="[Link]">6</Parameter>
<Parameter name="[Link]">SobolBrownianBridge</Parameter>
<Parameter name="[Link]">17</Parameter>
<Parameter name="[Link]">0</Parameter>
<Parameter name="BrownianBridgeOrdering">Steps</Parameter>
<Parameter name="SobolDirectionIntegers">JoeKuoD7</Parameter>
<Parameter name="MinObsDate">true</Parameter>
<Parameter name="RegressorModel">Simple</Parameter>
<Parameter name="SensitivityTemplate">IR_MC</Parameter>
</EngineParameters>
</Product>

Listing 45: Configuration for Product BermudanSwaption, Model BlackBachelier, Engine

BlackBachelierSwaptionEngine
LGM/AMC builds a McMultiLegOptionEngine for use in AMC simulations. We refer
to the AMC module documentation for further details.

7.3.8 Product Type: AmericanSwaption

Used by trade type: Swaption, for American exercise on vanilla underlying coupon
types
Available Model/Engine pairs:
• LGM/FD
• LGM/Grid (Not recommended due to inferior performance)
• LGM/MC
• LGM/AMC
Engine description:
LGM/FD builds a NumericLgmMultiLegOptionEngine using LgmFdSolver as a solver
using finite difference. A sample configuration is shown in listing 46
The parameters have the following meaning:
• Calibration: Bootstrap, BestFit, None
• CalibrationStrategy: CoterminalDealStrike, CoterminalATM

128
 • ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept
• Reversion: The mean reversion
• ReversionType: Hagan, HullWhite
• Volatility: The volatility (start value for calibration if calibrated)
• VolatilityType: Hagan, HullWhite
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• Scheme: The finite difference scheme to use
• StateGridPoints: The number of grid points in state direction
• TimeStepsPerYear: The number of time steps per year to use
• MesherEpsilon: determines the covered probability mass, mass outside state grid
is Φ−1 (1 − 2ϵ)
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="AmericanSwaption">
<Model>LGM</Model>
<ModelParameters>
<Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalDealStrike</Parameter>
<Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="VolatilityType">Hagan</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.20</Parameter>
</ModelParameters>
<Engine>FD</Engine>
<EngineParameters>
<Parameter name="Scheme">Douglas</Parameter>
<Parameter name="StateGridPoints">64</Parameter>
<Parameter name="TimeStepsPerYear">24</Parameter>
<Parameter name="MesherEpsilon">1E-4</Parameter>
</EngineParameters>
</Product>

Listing 46: Configuration for Product AmericanSwaption, Model LGM, Engine FD

LGM/Grid builds a NumericLgmMultiLegOptionEngine using LgmConvoluationSolver
as a solver. The rollback follows the paper “Hagan, P: Methodology for callable swaps
and American exercise into swaptions”. A sample configuration is shown in listing 47.
Not recommended due to inferior performance.
The parameters have the following meaning:
• Calibration: Bootstrap, BestFit, None
• CalibrationStrategy: CoterminalDealStrike, CoterminalATM

129
 • ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept
• Reversion: The mean reversion
• ReversionType: Hagan, HullWhite
• Volatility: The volatility (start value for calibration if calibrated)
• VolatilityType: Hagan, HullWhite
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• sy, sx: Number of covered standard deviations (notation as in Hagan’s paper)
• ny, nx: Number of grid points for numerical integration (notation as in Hagan’s
paper)
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="AmericanSwaption">
<Model>LGM</Model>
<ModelParameters>
<Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalDealStrike</Parameter>
<Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="VolatilityType">Hagan</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.20</Parameter>
</ModelParameters>
<Engine>Grid</Engine>
<EngineParameters>
<Parameter name="sy">5.0</Parameter>
<Parameter name="ny">30</Parameter>
<Parameter name="sx">5.0</Parameter>
<Parameter name="nx">30</Parameter>
<Parameter name="SensitivityTemplate">IR_FD</Parameter>
</EngineParameters>
</Product>

Listing 47: Configuration for Product AmericanSwaption, Model LGM, Engine Grid (Not rec-
ommended due to inferior performance)
LGM/MC builds a McMultiLegOptionEngine. A sample configuration is shown in
listing 48
The parameters have the following meaning:
• Calibration: Bootstrap, BestFit, None
• CalibrationStrategy: CoterminalDealStrike, CoterminalATM
• ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept

130
• Reversion: The mean reversion
• ReversionType: Hagan, HullWhite
• Volatility: The volatility (start value for calibration if calibrated)
• VolatilityType: Hagan, HullWhite
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• [Link]: The sequence type for the traning phase, can be
MersenneTwister+, MersenneTwisterAntithetc+, Sobol+, Burley2020Sobol+,
SobolBrownianBridge+, Burley2020SobolBrownianBridge+
• [Link]: The seed for the random number generation in the training phase
• [Link]: The number of samples to be used for the training phase
• [Link]: The sequence type for the pricing phase, same values allowed
as for training
• [Link]: The type of basis function system to be used for the
regression analysis, can be Monomial+, Laguerre+, Hermite+, Hyperbolic+,
Legendre+, Chbyshev+, Chebyshev2nd+
• BasisFunctionOrder: The order of the basis function system to be used
• [Link]: The seed for the random number generation in the pricing
• [Link]: The number of samples to be used for the pricing phase. If this
number is zero, no pricing run is performed, instead the (T0) NPV is estimated
from the training phase (this result is used to fill the T0 slice of the NPV cube)
• BrownianBridgeOrdering: variate ordering for Brownian bridges, can be Steps+,
Factors+, Diagonal+
• SobolDirectionIntegers: direction integers for Sobol generator, can be Unit+,
Jaeckel+, SobolLevitan+, SobolLevitanLemieux+, JoeKuoD5+, JoeKuoD6+,
JoeKuoD7+, Kuo+, Kuo2+, Kuo3+
• MinObsDate: if true the conditional expectation of each cashflow is taken from
the minimum possible observation date (i.e. the latest exercise or simulation date
before the cashflow’s event date); recommended setting is true+
• RegressorModel: Simple, LaggedFX. If not given, it defaults to Simple.
Depending on the choice the regressor is built as follows:
– Simple: For an observation date the full model state observed on this date is
included in the regressor. No past states are included though.
– LaggedFX: For an observation date the full model state observed on this
date is included in the regressor. In addition, past FX states that are
relevant for future cashflows are included. For example, for a FX resettable
cashflow the FX state observed on the FX reset date is included.
• SensitivityTemplate [optional]: the sensitivity template to use

131
<Product type="AmericanSwaption">
<Model>LGM</Model>
<ModelParameters>
<Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalDealStrike</Parameter>
<Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="VolatilityType">Hagan</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.20</Parameter>
</ModelParameters>
<Engine>MC</Engine>
<EngineParameters>
<Parameter name="[Link]">MersenneTwisterAntithetic</Parameter>
<Parameter name="[Link]">42</Parameter>
<Parameter name="[Link]">10000</Parameter>
<Parameter name="[Link]">Monomial</Parameter>
<Parameter name="[Link]">6</Parameter>
<Parameter name="[Link]">SobolBrownianBridge</Parameter>
<Parameter name="[Link]">17</Parameter>
<Parameter name="[Link]">0</Parameter>
<Parameter name="BrownianBridgeOrdering">Steps</Parameter>
<Parameter name="SobolDirectionIntegers">JoeKuoD7</Parameter>
<Parameter name="MinObsDate">true</Parameter>
<Parameter name="RegressorModel">Simple</Parameter>
<Parameter name="SensitivityTemplate">IR_MC</Parameter>
</EngineParameters>
</Product>

Listing 48: Configuration for Product AmericanSwaption, Model BlackBachelier, Engine Black-
BachelierSwaptionEngine
LGM/AMC builds a McMultiLegOptionEngine for use in AMC simulations. We refer
to the AMC module documentation for further details.

7.3.9 Product Type: BondRepo

Used by trade type: BondRepo
Available Model/Engine pairs:
• DiscountedCashflows/DiscountingRepoEngine
• Accrual/AccrualRepoEngine
Engine description:
DiscountedCashflows/DiscountingRepoEngine builds a DiscountingBondRepoEngine.
A sample configuration is shown in listing 49.
The parameters have the following meaning:
• IncludeSecurityLeg: include the security leg in the valuation
• SensitivityTemplate [optional]: the sensitivity template to use

132
<Product type="BondRepo">
<Model>DiscountedCashflows</Model>
<ModelParameters>
<Parameter name="IncludeSecurityLeg">true</Parameter>
</ModelParameters>
<Engine>DiscountingRepoEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 49: Configuration for Product BondRepo, Model DiscountedCashflows, Engine Dis-
countingRepoEngine
Accrual/AccrualRepoEngine builds a AccrualBondRepoEngine. A sample
configuration is shown in listing 50.
The parameters have the following meaning:
• IncludeSecurityLeg: include the security leg in the valuation
• SensitivityTemplate [optional]: the sensitivity template to use
Product type="BondRepo">
<Model>Accrual</Model>
<ModelParameters>
<Parameter name="IncludeSecurityLeg">true</Parameter>
</ModelParameters>
<Engine>AccrualRepoEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 50: Configuration for Product BondRepo, Model Accrual, Engine DiscountingBondRepo-
Engine

7.3.10 Product Type: BondTRS

Used by trade type: BondTRS
Available Model/Engine pairs: DiscountedCashflows/DiscountingBondTRSEngine
Engine description:
DiscountedCashflows/DiscountingBondTRSEngine builds a
DisountingBondTRSEngine. A sample configuration is shown in listing 51.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="BondTRS">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>DiscountingBondTRSEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>

133
 </EngineParameters>
</Product>

Listing 51: Configuration for Product BondTRS , Model DiscountedCashflows, Engine Dis-
countingBondTRSEngine

7.3.11 Product Type: CapFloor

Used by trade type: CapFloor on underlying Ibor with subperiods (all other
underlying use their respective coupon pricers)
Available Model/Engine pairs: IborCapModel/IborCapEngine
Engine description:
IborCapModel/IborCapEngine builds a BlackCapFloorEngine or
BachelierCapFloorEngine depending on the input volatility type. A sample
configuration is shown in listing 52
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CapFloor">
<Model>IborCapModel</Model>
<ModelParameters/>
<Engine>IborCapEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 52: Configuration for Product CapFloor, Model IborCapModel, Engine IborCapEngine

7.3.12 Product Type: CapFlooredIborLeg

Used by trade type: any trade with a cap / floored ibor / rfr term rate leg
Available Model/Engine pairs: BlackOrBachelier/BlackIborCouponPricer
Engine description:
BlackOrBachelier/BlackIborCouponPricer builds a BlackIborCouponPricer. A sample
configuration is shown in listing 53.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CapFlooredIborCouponLeg">
<Model>BlackOrBachelier</Model>
<ModelParameters/>
<Engine>BlackIborCouponPricer</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

134
Listing 53: Configuration for Product CapFlooredIborLeg, Model BlackOrBachelier, Engine
BlackIborCouponPricer

7.3.13 Product Type: CapFlooredOvernightIndexedCouponLeg

Used by trade type: any trade with a cap / floored OIS leg
Available Model/Engine pairs: BlackOrBachelier/BlackOvernightIndexedCouponPricer
Engine description:
BlackOrBachelier/BlackOvernightIndexedCouponPricer builds a
BlackOvernightIndexedCouponPricer. A sample configuration is shown in listing 54.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CapFlooredOvernightIndexedCouponLeg">
<Model>BlackOrBachelier</Model>
<ModelParameters/>
<Engine>BlackOvernightIndexedCouponPricer</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 54: Configuration for Product CapFlooredOvernightIndexedCouponLeg, Model BlackO-

rBachelier, Engine BlackOvernightIndexedCouponPricer

7.3.14 Product Type: CapFlooredAverageONIndexedCouponLeg

Used by trade type: any trade with a cap / floored OIS leg
Available Model/Engine pairs:
BlackOrBachelier/BlackAverageONIndexedCouponPricer
Engine description:
BlackOrBachelier/BlackAverageONIndexedCouponPricer builds a
BlackAverageONIndexedCouponPricer. A sample configuration is shown in listing 55.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CapFlooredAverageONIndexedCouponLeg">
<Model>BlackOrBachelier</Model>
<ModelParameters/>
<Engine>BlackAverageONIndexedCouponPricer</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

135
Listing 55: Configuration for Product CapFlooredAverageONIndexedCouponLeg, Model Black-
OrBachelier, Engine BlackAverageONIndexedCouponPricer

7.3.15 Product Type: CapFlooredAverageBMAIndexedCouponLeg

Used by trade type: any trade with a cap / floored OIS leg
Available Model/Engine pairs:
BlackOrBachelier/BlackAverageBMAIndexedCouponPricer
Engine description:
BlackOrBachelier/BlackAverageBMAIndexedCouponPricer builds a
BlackAverageBMAIndexedCouponPricer. A sample configuration is shown in listing 56.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CapFlooredAverageBMAIndexedCouponLeg">
<Model>BlackOrBachelier</Model>
<ModelParameters/>
<Engine>BlackAverageBMAIndexedCouponPricer</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 56: Configuration for Product CapFlooredAverageBMAIndexedCouponLeg, Model Black-

OrBachelier, Engine BlackAverageBMAIndexedCouponPricer

7.3.16 Product Type: CappedFlooredCpiLegCoupons

Used by trade type: any trade with a cap / floored CPI leg (coupons)
Available Model/Engine pairs: Black/BlackAnalytic
Engine description:
Black/BlackAnalytic builds a BlackCPICouponPricer or BachelierCPICouponPricer,
depending on the volatility input. A sample configuration is shown in listing 57
The parameters have the following meaning:
• useLastFixingDate: if true, use the last known fixing date as the base date of the
volatility structure, otherwise use observation lag
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CapFlooredCpiLegCoupons">
<Model>Black</Model>
<ModelParameters/>
<Engine>BlackAnalytic</Engine>
<EngineParameters>
<Parameter name="useLastFixingDate">true</Parameter>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>

136
 </EngineParameters>
</Product>

Listing 57: Configuration for Product CapFlooredCpiLegCoupons, Model Black, Engine Black-
Analytic

7.3.17 Product Type: CappedFlooredCpiLegCashFlows

Used by trade type: any trade with a cap / floored CPI leg (cashflows)
Available Model/Engine pairs: Black/BlackAnalytic
Engine description:
Black/BlackAnalytic builds a BlackCPICashFLowPricer or
BachelierCPICashFlowPricer, depending on the volatility input. A sample
configuration is shown in listing 58
The parameters have the following meaning:
• useLastFixingDate: if true, use the last known fixing date as the base date of the
volatility structure, otherwise use observation lag
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CappedFlooredCpiLegCashFlows">
<Model>Black</Model>
<ModelParameters/>
<Engine>BlackAnalytic</Engine>
<EngineParameters>
<Parameter name="useLastFixingDate">true</Parameter>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 58: Configuration for Product CapFlooredCpiLegCoupons, Model Black, Engine Black-
Analytic

7.3.18 Product Type: CommodityAveragePriceOption

Used by trade type: CommodityAveragePriceOption
Available Model/Engine pairs:
• Black/AnalyticalApproximation
• Black/MonteCarlo
Engine description:
Black/AnalyticalApproximation builds a
CommodityAveragePriceOptionAnalyticalEngine. The correlation between two future
contracts is parametrized as

ρ(s, t) = e−β|s−t|

where s and t are times to futures expiry. A sample configuration is shown in listing 59.

137
The parameters have the following meaning:
• beta: parameter in correlation parametrization
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAveragePriceOption">
<Model>Black</Model>
<ModelParameters/>
<Engine>AnalyticalApproximation</Engine>
<EngineParameters>
<Parameter name="beta">0</Parameter>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 59: Configuration for Product CommodityAveragePriceOption, Model Black, Engine

AnalyticalApproximation
Black/MonteCarlo builds a CommodityAveragePriceOptionMonteCarloEngine. A
sample configuration is shown in listing 60.
The parameters have the following meaning:
• samples: the number of Monte Carlo Samples
• beta: parameter in correlation parametrization
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAveragePriceOption">
<Model>Black</Model>
<ModelParameters/>
<Engine>MonteCarlo</Engine>
<EngineParameters>
<Parameter name="samples">10000</Parameter>
<Parameter name="beta">0</Parameter>
<Parameter name="SensitivityTemplate">COMM_MC</Parameter>
</EngineParameters>
</Product>

Listing 60: Configuration for Product CommodityAveragePriceOption, Model Black, Engine

MonteCarlo

7.3.19 Product Type: CommodityAveragePriceBarrierOption

Used by trade type: CommodityAveragePriceOption with BarrierData
Available Model/Engine pairs:
• Black/MonteCarlo
Engine description:
Black/MonteCarlo builds a CommodityAveragePriceOptionAnalyticalEngine. The
correlation between two future contracts is parametrized as

ρ(s, t) = e−β|s−t|

138
where s and t are times to futures expiry. A sample configuration is shown in listing 61.
The parameters have the following meaning:
• samples: the number of Monte Carlo Samples
• beta: parameter in correlation parametrization
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAveragePriceBarrierOption">
<Model>Black</Model>
<ModelParameters/>
<Engine>MonteCarlo</Engine>
<EngineParameters>
<Parameter name="samples">10000</Parameter>
<Parameter name="beta">0</Parameter>
<Parameter name="SensitivityTemplate">COMM_MC</Parameter>
</EngineParameters>
</Product>

Listing 61: Configuration for Product CommodityAveragePriceBarrierOption, Model Black,

Engine MonteCarlo

7.3.20 Product Type: CommodityForward

Used by trade type: CommodityForward
Available Model/Engine pairs:
• DiscountedCashflows/DiscountingCommodityForwardEngine
Engine description:
DiscountedCashflows/DiscountingCommodityForwardEngine builds a
DiscountingCommodityForwardEngine. A sample configuration is shown in listing 62.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityForward">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>DiscountingCommodityForwardEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 62: Configuration for Product CommodityForward, Model DiscountedCashflows, Engine

DiscountingCommodityForwardEngine

7.3.21 Product Type: CreditDefaultSwap

Used by trade type: CreditDefaultSwap
Available Model/Engine pairs:

139
 • DiscountedCashflows/MidPointCdsEngine
• DiscountedCashflows/MidPointCdsEngineMultiState
Engine description:
DiscountedCashflows/MidPointCdsEngine builds a MidPointCdsEngine. A sample
configuration is shown in listing 63.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CreditDefaultSwap">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>MidPointCdsEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 63: Configuration for Product CreditDefaultSwap, Model DiscountedCashflows, Engine

MidPointCdsEngine
DiscountedCashflows/MidPointCdsEngineMultiState builds a
MidPointCdsEngineMultiState. This engine is only used in the context of the Credit
Model. We refer to the documentation of this module for further details.

7.3.22 Product Type: CreditDefaultSwapOption

Used by trade type: CreditDefaultSwapOption
Available Model/Engine pairs:
• Black/BlackCdsOptionEngine
Engine description:
Black/BlackCdsOptionEngine builds a BlackCdsOptionEngine. A sample
configuration is shown in listing 64.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CreditDefaultSwapOption">
<Model>Black</Model>
<ModelParameters/>
<Engine>BlackCdsOptionEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 64: Configuration for Product CreditDefaultSwap, Model DiscountedCashflows, Engine

MidPointCdsEngine

140
7.3.23 Product Type: IndexCreditDefaultSwap
Used by trade type: IndexCreditDefaultSwap
Available Model/Engine pairs:
• DiscountedCashflows/MidPointIndexCdsEngine
Engine description:
DiscountedCashflows/MidPointIndexCdsEngine builds a MidPointIndexCdsEngine. A
sample configuration is shown in listing 65.
The parameters have the following meaning:
• Curve: Index, Underlying
• SensitivityDecomposition: Underlying, NotionalWeighted, LossWeighted,
DeltaWeighted
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="IndexCreditDefaultSwap">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>MidPointIndexCdsEngine</Engine>
<EngineParameters>
<Parameter name="Curve">Index</Parameter>
<Parameter name="SensitivityDecomposition">DeltaWeighted</Parameter>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 65: Configuration for Product CreditDefaultSwap, Model DiscountedCashflows, Engine

MidPointIndexCdsEngine

7.3.24 Product Type: IndexCreditDefaultSwapOption

Used by trade type: IndexCreditDefaultSwapOption
Available Model/Engine pairs:
• Black/BlackIndexCdsOptionEngine
• LognormalAdjustedIndexSpread/NumericalIntegrationEngine
Engine description:
Black/BlackIndexCdsOptionEngine builds a BlackIndexCdsOptionEngine. A sample
configuration is shown in listing 66.
The parameters have the following meaning:
• Curve: Index, Underlying
• FepCurve: Index, Underlying
• SensitivityDecomposition: Underlying, NotionalWeighted, LossWeighted,
DeltaWeighted

141
 • SensitivityTemplate [optional]: the sensitivity template to use
<Product type="IndexCreditDefaultSwapOption">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>MidPointIndexCdsEngine</Engine>
<EngineParameters>
<Parameter name="Curve">Index</Parameter>
<Parameter name="FepCurve">Index</Parameter>
<Parameter name="SensitivityDecomposition">DeltaWeighted</Parameter>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 66: Configuration for Product CreditDefaultSwap, Model DiscountedCashflows, Engine

MidPointIndexCdsEngine
LognormalAdjustedIndexSpread/NumericalIntegrationEngine builds a
NumericalIntegrationIndexCdsOptionEngine. A sample configuration is shown in
listing 67.
The parameters have the following meaning:
• Curve: Index, Underlying
• FepCurve: Index, Underlying
• SensitivityDecomposition: Underlying, NotionalWeighted, LossWeighted,
DeltaWeighted
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="IndexCreditDefaultSwapOption">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>MidPointIndexCdsEngine</Engine>
<EngineParameters>
<Parameter name="Curve">Index</Parameter>
<Parameter name="FepCurve">Index</Parameter>
<Parameter name="SensitivityDecomposition">DeltaWeighted</Parameter>
<Parameter name="SensitivityTemplate">IR_Semianalytical</Parameter>
</EngineParameters>
</Product>

Listing 67: Configuration for Product CreditDefaultSwap, Model DiscountedCashflows, Engine

MidPointIndexCdsEngine

7.3.25 Product Type: CpiCapFloor

Used by trade type: CapFloor with underlying leg of leg type CPI.
Available Model/Engine pairs: CpiCapModel/CpiCapEngine
Engine description:
CpiCapModel/CpiCapEngine builds a CPIBlackCapFloorEngine or
CPIBachelierCapFloorEngine depneding on the volatility type of the market surface.
A sample configuration is shown in listing 68.

142
The parameters have the following meaning:
• useLastFixingDate: if true, use the last known fixing date as the base date of the
volatility structure, otherwise use observation lag
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CpiCapFloor">
<Model>CpiCapModel</Model>
<ModelParameters/>
<Engine>CpiCapEngine</Engine>
<EngineParameters>
<Parameter name="useLastFixingDate">true</Parameter>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 68: Configuration for Product CpiCapFloor, Model CpiCapModel, Engine Cpi-
CapEngine

7.3.26 Product Type: YYCapFloor

Used by trade type: CapFloor with underlying leg of leg type YoY.
Available Model/Engine pairs: YYCapModel/YYCapEngine
Engine description:
YYCapModel/YYCapEngine builds a YoYInflationBlackCapFloorEngine,
YoYInflationUnitDisplacedBlackCapFloorEngine,
YoYInflationBachelierCapFloorEngine depending on the volatility type of the market
surface. A sample configuration is shown in listing 69.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CpiCapFloor">
<Model>YYCapModel</Model>
<ModelParameters/>
<Engine>YYCapEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 69: Configuration for Product YYCapFloor, Model YYCapModel, Engine YYCapEngine

7.3.27 Product Type: CappedFlooredYYLeg

Used by trade type: any trade with a cap / floored YY leg
Available Model/Engine pairs: CapFlooredYYModel/CapFlooredYYCouponPricer
Engine description:
CapFlooredYYModel/CapFlooredYYCouponPricer builds a
BlackYoYInflationCouponPricer, UnitDisplacedBlackYoYInflationCouponPricer,

143
BachelierYoYInflationCouponPricer, depending on the volatility input. A sample
configuration is shown in listing 70
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CappedFlooredYYLeg">
<Model>CapFlooredYYModel</Model>
<ModelParameters/>
<Engine>CapFlooredYYCouponPricer</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 70: Configuration for Product CapFlooredYYLeg, Model CapFlooredYYModel, Engine

CapFlooredYYCouponPricer

7.3.28 Product Type: CappedFlooredNonStdYYLeg

Used by trade type: any trade with a cap / floored YY leg if IrregularYoY is true in
YoY leg data
Available Model/Engine pairs:
CapFlooredYNonStdYYModel/CapFlooredNonStdYYCouponPricer
Engine description:
CapFlooredYNonStdYYModel/CapFlooredNonStdYYCouponPricer builds a
NonStandardBlackYoYInflationCouponPricer,
NonStandardUnitDisplacedBlackYoYInflationCouponPricer,
NonStandardBachelierYoYInflationCouponPricer, depending on the volatility input. A
sample configuration is shown in listing 71
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CappedFlooredNonStdYYLeg">
<Model>CapFlooredNonStdYYModel</Model>
<ModelParameters/>
<Engine>CapFlooredNonStdYYCouponPricer</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 71: Configuration for Product CapFlooredNonStdYYLeg, Model CapFlooredNonStdYY-

Model, Engine CapFlooredNonStdYYCouponPricer

7.3.29 Product Type: CMS

Used by trade type: any trade referencing a CMS leg, also used by CMS Spread
coupon pricers
Available Model/Engine pairs:

144
 • LinearTSR/LinearTSRPricer
• Hagan/Analytic
• Hagan/Numerical
Engine description:
LinearTSR/LinearTSRPricer builds a LinearTRSPricer. A sample configuration is
shown in listing 72.
The parameters have the following meaning:
• MeanReversion: the mean reversion for the model
• Policy: RateBound, VegaRatio, PriceThreshold, BsStdDev
• LowerRateBoundLogNormal, UpperRateBoundLogNormal: rate bounds for ln /
sln vol input
• LowerRateNormal, UpperRateNormal: rate bounds for normal vol input
• VegaRatio: vega ratio for policy
• PriceThreshold: price threshold for policy
• BsStdDev: std devs for BsStdDev
• SensitivityTemplate [optional]: the sensitivity template to use
<Prooduct type="CMS">
<Model>LinearTSR</Model>
<ModelParameters/>
<Engine>LinearTSRPricer</Engine>
<EngineParameters>
<Parameter name="MeanReversion">0.0</Parameter>
<Parameter name="Policy">RateBound</Parameter>
<Parameter name="LowerRateBoundLogNormal">0.0001</Parameter>
<Parameter name="UpperRateBoundLogNormal">2.0000</Parameter>
<Parameter name="LowerRateBoundNormal">-2.0000</Parameter>
<Parameter name="UpperRateBoundNormal">2.0000</Parameter>
<Parameter name="VegaRatio">0.01</Parameter>
<Parameter name="PriceThreshold">0.0000001</Parameter>
<Parameter name="BsStdDev">3.0</Parameter>
<Parameter name="SensitivityTemplate">IR_Semianalytical</Parameter>
</EngineParameters>
</Product>

Listing 72: Configuration for Product CMS, Model LinearTSR, Engine LinearTSRPricer
Hagan/Analytic, Hagan/Numerical build AnalyticHaganPricer, NumericHaganPricer
(TODO add parameters and sample config).

7.3.30 Product Type: SyntheticCDO

Used by trade type: SyntheticCDO
Available Model/Engine pairs: GaussCopula/Bucketing
Engine description:

145
GaussCopula/Bucketing builds a IndexCdsTrancheEngine. A sample configuration is
shown in listing 73
The parameters have the following meaning:
• min, max: min max std dev for Gauss copula
• steps: integration steps
• useStochasticRecovery: whether to use deterministic (false) or stochastic (true)
recovery model
• recoveryRateGrid: Constant (flat market recovery rate R), Markit2020 (3-pillar
recovery grid [0.1, R, 2R − 0.1]
• reocveryRateProbabilities: recovery rate probabilities for the recovery rate grid
• buckets: number of buckets in Hull-White bucketing
• SensitivityDecomposition: Underlying, NotionalWeighted, LossWeighted,
DeltaWeighted
• useLossDistWhenJustified: whether to use QuantLib::LossDist for determinisitc
recovery instead of HulWhiteBucketing
• homogeneousPoolWhenJustified: whether to use homogeneous pool if possible,
applies to QuantLib::LossDist
• useQuadrature: whether to use quadrature
• calibrateConstituentCurves: whether to calibrate constituent curves to index
level
• calibrationIndexTerms: terms for constituent curve calibration
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="SyntheticCDO">
<Model>GaussCopula</Model>
<ModelParameters>
<Parameter name="min">-5.0</Parameter>
<Parameter name="max">5.0</Parameter>
<Parameter name="steps">64</Parameter>
<Parameter name="useStochasticRecovery">Y</Parameter>
<Parameter name="recoveryRateGrid">Markit2020</Parameter>
<Parameter name="recoveryRateProbabilities">0.35,0.3,0.35</Parameter>
</ModelParameters>
<Engine>Bucketing</Engine>
<EngineParameters>
<Parameter name="buckets">124</Parameter>
<Parameter name="SensitivityDecomposition">DeltaWeighted</Parameter>
<Parameter name="useLossDistWhenJustified">N</Parameter>
<Parameter name="homogeneousPoolWhenJustified">N</Parameter>
<Parameter name="calibrateConstituentCurves">N</Parameter>
<Parameter name="calibrationIndexTerms">3Y,5Y</Parameter>
<Parameter name="SensitivityTemplate">CR_Semianalytical</Parameter>
</EngineParameters>
</Product>

146
Listing 73: Configuration for Product SyntheticCDO, Model GaussCopula, Engine Bucketing

7.3.31 Product Type: CBO

Used by trade type: CBO
Available Model/Engine pairs: OneFactorCopula/MonteCarloCBOEngine
Engine description:
OneFactorCopula/MonteCarloCBOEngine builds a MonteCarloCBOEngine. A sample
configuration is shown in listing 74
The parameters have the following meaning:
• Samples: number of MC samples
• Bins: number of bins used for discretization
• Seed: seed for MC simulation
• LossDistributionPeriods:
• Correlation: correlation to use
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CBO">
<Model>OneFactorCopula</Model>
<ModelParameters/>
<Engine>MonteCarloCBOEngine</Engine>
<EngineParameters>
<Parameter name="Samples">1000</Parameter>
<Parameter name="Bins">20</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="LossDistributionPeriods"/>
<Parameter name="Correlation">0.2</Parameter>
<Parameter name="SensitivityTemplate">CR_MC</Parameter>
</EngineParameters>
</Product>

Listing 74: Configuration for Product CBO, Model OneFactorCopula, Engine MonteCarloCBO-
Engine

7.3.32 Product Type: CMSSpread

Used by trade type: any trade referencing a CMSSpread leg
Available Model/Engine pairs:
• BrigoMercurio/Analytic
Engine description:
BrigoMercurio/Analytic builds a LognormalCmsSpreadPricer (following Brigo,
Mercurio, Interest Rate Models - Theory and Practice, section 13.16.2). A sample
configuration is shown in listing 75.

147
The parameters have the following meaning:
• IntegrationPoints: Number of points for Gauss-Hermite numerical integration
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CMSSpread">
<Model>BrigoMercurio</Model>
<ModelParameters/>
<Engine>Analytic</Engine>
<EngineParameters>
<Parameter name="IntegrationPoints">16</Parameter>
<Parameter name="SensitivityTemplate">IR_Semianalytical</Parameter>
</EngineParameters>
</Product>\caption{Configuration for Product CMSSpread, Model BrigoMercurio, Engine Analytic}

Listing 75: Configuration for Product CMSSpread, Model BrigoMercurio, Engine Analytic

7.3.33 Product Type: DurationAdjustedCMS

Used by trade type: any trade referencing a DurationAdjustedCMS leg
Available Model/Engine pairs:
• LinearTSR/LinearTSRPricer
Engine description:
LinearTSR/LinearTSRPricer builds a DurationAdjustedCmsCouponTsrPricer with
LinearAnnuityMapping. A sample configuration is shown in listing 76.
The parameters have the following meaning:
• MeanReversion: the mean reversion for the model
• LowerRateBoundLogNormal, UpperRateBoundLogNormal: rate bounds for ln /
sln vol input
• LowerRateNormal, UpperRateNormal: rate bounds for normal vol input
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="DurationAdjustedCMS">
<Model>LinearTSR</Model>
<ModelParameters/>
<Engine>LinearTSRPricer</Engine>
<EngineParameters>
<Parameter name="MeanReversion">0.0</Parameter>
<Parameter name="LowerRateBoundLogNormal">0.0001</Parameter>
<Parameter name="UpperRateBoundLogNormal">2.0000</Parameter>
<Parameter name="LowerRateBoundNormal">-2.0000</Parameter>
<Parameter name="UpperRateBoundNormal">2.0000</Parameter>
<Parameter name="SensitivityTemplate">IR_Semianalytical</Parameter>
</EngineParameters>
</Product>

Listing 76: Configuration for Product DurationAdjustedCMS, Model LinearTSR, Engine Lin-
earTSRPricer

148
7.3.34 Product Type: CommodityAsianOptionArithmeticPrice
Used by trade type: CommodityAsianOption if payoffType2 is Arithmetric and
payoffType is Asian
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteArithmeticAPEngine
• BlackScholesMerton/TurnbullWakemanAsianEngine
• ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteArithmeticAPEngine builds a
MCDiscreteArithmeticAPEngine using Sobol sequences. A sample configuration is
shown in listing 77.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation
• ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given
• MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionArithmeticPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteArithmeticAPEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>
<Parameter name="RequiredTolerance">0</Parameter>
<Parameter name="MaxSamples">0</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">COMM_MC</Parameter>
</EngineParameters>
</Product>

Listing 77: Configuration for Product CommodityAsianOptionArithmeticPrice, Model BlackSc-

holesMerton, Engine MCDiscreteArithmeticAPEngine
BlackScholesMerton/TurnbullWakemanAsianEngine builds a
TurnbullWakemanAsianEngine. A sample configuration is shown in listing 78.

149
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionArithmeticPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>TurnbullWakemanAsianEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 78: Configuration for Product CommodityAsianOptionArithmeticPrice, Model BlackSc-

holesMerton, Engine TurnbullWakemanAsianEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 79.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionArithmeticPrice">
<Model>ScriptedTrade</Model>
<ModelParameters/>
<Engine>ScriptedTrade</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_MC</Parameter>
</EngineParameters>
</Product>

Listing 79: Configuration for Product CommodityAsianOptionArithmeticPrice, Model Script-

edTrade, Engine ScriptedTrade

7.3.35 Product Type: CommodityAsianOptionArithmeticStrike

Used by trade type: CommodityAsianOption if payoffType2 is Arithmetric and
payoffType is AverageStrike
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteArithmeticASEngine
• ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteArithmeticASEngine builds a
MCDiscreteArithmeticASEngine using Sobol sequences. A sample configuration is
shown in listing 80.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation

150
 • ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given
• MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionArithmeticStrike">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteArithmeticASEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>
<Parameter name="RequiredTolerance">0</Parameter>
<Parameter name="MaxSamples">0</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">COMM_MC</Parameter>
</EngineParameters>
</Product>

Listing 80: Configuration for Product CommodityAsianOptionArithmeticStrike, Model BlackSc-

holesMerton, Engine MCDiscreteArithmeticASEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 81.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionArithmeticStrike">
<Model>ScriptedTrade</Model>
<ModelParameters/>
<Engine>ScriptedTrade</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_MC</Parameter>
</EngineParameters>
</Product>

Listing 81: Configuration for Product CommodityAsianOptionArithmeticStrike, Model Script-

edTrade, Engine ScriptedTrade

7.3.36 Product Type: CommodityAsianOptionGeometricPrice

Used by trade type: CommodityAsianOption if payoffType2 is Geometric and
payoffType is Asian

151
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteGeometricAPEngine
• BlackScholesMerton/AnalyticDiscreteGeometricAPEngine
• BlackScholesMerton/AnalyticContinuousGeometricAPEngine
• ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteGeometricAPEngine builds a
MCDiscreteGeometricAPEngine using Sobol sequences. A sample configuration is
shown in listing 82.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation
• ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given
• MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionGeometricPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteGeometricAPEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>
<Parameter name="RequiredTolerance">0</Parameter>
<Parameter name="MaxSamples">0</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">COMM_MC</Parameter>
</EngineParameters>
</Product>

Listing 82: Configuration for Product CommodityAsianOptionGeometricPrice, Model BlackSc-

holesMerton, Engine MCDiscreteGeometricAPEngine
BlackScholesMerton/AnalyticDiscreteGeometricAPEngine builds a
AnalyticDiscreteGeometricAveragePriceAsianEngine. A sample configuration is shown
in listing 83.
The parameters have the following meaning:

152
 • SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionGeometricPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticDiscreteGeometricAPEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 83: Configuration for Product CommodityAsianOptionGeometricPrice, Model BlackSc-

holesMerton, Engine AnalyticDiscreteGeomtetricAPEngine
BlackScholesMerton/AnalyticContinuousGeometricAPEngine builds a
AnalyticContinuousGeometricAveragePriceAsianEngine. A sample configuration is
shown in listing 84.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionGeometricPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticContinuousGeometricAPEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 84: Configuration for Product CommodityAsianOptionGeometricPrice, Model BlackSc-

holesMerton, Engine AnalyticContinuousGeomtetricAPEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 85.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionGeometricPrice">
<Model>ScriptedTrade</Model>
<ModelParameters/>
<Engine>ScriptedTrade</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_MC</Parameter>
</EngineParameters>
</Product>

Listing 85: Configuration for Product CommodityAsianOptionGeometricPrice, Model Scripted-

Trade, Engine ScriptedTrade

153
7.3.37 Product Type: CommodityAsianOptionGeometricStrike
Used by trade type: CommodityAsianOption if payoffType2 is Geometric and
payoffType is AverageStrike
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteGeometricASEngine
• BlackScholesMerton/AnalyticDiscreteGeometricASEngine
• ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteGeometricASEngine builds a
MCDiscreteGeometricASEngine using Sobol sequences. A sample configuration is
shown in listing 86.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation
• ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given
• MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionGeometricStrike">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteGeometricASEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>
<Parameter name="RequiredTolerance">0</Parameter>
<Parameter name="MaxSamples">0</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">COMM_MC</Parameter>
</EngineParameters>
</Product>

Listing 86: Configuration for Product CommodityAsianOptionGeometricStrike, Model BlackSc-

holesMerton, Engine MCDiscreteGeometricASEngine
BlackScholesMerton/AnalyticDiscreteGeometricASEngine builds a
AnalyticDiscreteGeometricAverageStrikeAsianEngine. A sample configuration is shown

154
in listing 87.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionGeometricStrike">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticDiscreteGeometricASEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 87: Configuration for Product CommodityAsianOptionGeometricStrike, Model BlackSc-

holesMerton, Engine AnalyticDiscreteGeomtetricASEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 88.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityAsianOptionGeometricStrike">
<Model>ScriptedTrade</Model>
<ModelParameters/>
<Engine>ScriptedTrade</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_MC</Parameter>
</EngineParameters>
</Product>

Listing 88: Configuration for Product CommodityAsianOptionGeometricStrike, Model Script-

edTrade, Engine ScriptedTrade

7.3.38 Product Type: CommoditySpreadOption

Used by trade type: CommoditySpreadOption
Available Model/Engine pairs: BlackScholes/CommoditySpreadOptionEngine
Engine description:
BlackScholes/CommoditySpreadOptionEngine builds a
CommoditySpreadOptionAnalyticalEngine, which uses the Kirk approximation
described in Iain J. Clark, Commodity Option Pricing, Section 2.9. The correlation
between two commodities resp. the intra-asset correlation between two future
contracts is parametrized as

ρ(s, t) = e−β|s−t|

where s and t are times to futures expiry. A sample configuration is shown in listing 89.
The parameters have the following meaning:

155
 • beta: the parameter “beta” in the correlation parametrization
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommoditySpreadOption">
<Model>BlackScholes</Model>
<ModelParameters/>
<Engine>CommoditySpreadOptionEngine</Engine>
<EngineParameters>
<Parameter name="beta">2.05</Parameter>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 89: Configuration for Product CommoditySpreadOption, Model BlackScholes, Engine

CommoditySpreadOptionEngine

7.3.39 Product Type: CommodityOption

Used by trade type: CommodityOption
Available Model/Engine pairs: BlackScholes/AnalyticEuropeanEngine
Engine description:
BlackScholes/AnalyticEuropeanEngine builds a AnalyticEuropeanEngine. A sample
configuration is shown in listing 90
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityOption">
<Model>BlackScholes</Model>
<ModelParameters/>
<Engine>AnalyticEuropeanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 90: Configuration for Product CommodityOption, Model BlackScholes, Engine Analyt-
icEuropeanEngine

7.3.40 Product Type: CommodityOptionForward

Used by trade type: CommodityOption if a future is referenced
Available Model/Engine pairs: BlackScholes/AnalyticEuropeanForwardEngine
Engine description:
BlackScholes/AnalyticEuropeanForwardEngine builds a
AnalyticEuropeanForwardEngine. A sample configuration is shown in listing 91
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use

156
<Product type="CommodityOptionForward">
<Model>BlackScholes</Model>
<ModelParameters/>
<Engine>AnalyticForwardEuropeanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 91: Configuration for Product CommodityOptionForward, Model BlackScholes, Engine

AnalyticForwardEuropeanEngine

7.3.41 Product Type: CommodityOptionEuropeanCS

Used by trade type: CommodityOption if cash settled
Available Model/Engine pairs: BlackScholes/AnalyticCashSettledEuropeanEngine
Engine description:
BlackScholes/AnalyticCashSettledEuropeanEngine builds a
AnalyticCashSettledEuropeanEngine. A sample configuration is shown in listing 92
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityOptionEuropeanCS">
<Model>BlackScholes</Model>
<ModelParameters/>
<Engine>AnalyticCashSettledEuropeanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 92: Configuration for Product CommodityOptionEuropeanCS, Model BlackScholes, En-

gine AnalyticCashSettledEuropeanEngine

7.3.42 Product Type: CommodityOptionAmerican

Used by trade type: CommodityOption if exercise stly is american
Available Model/Engine pairs:
• BlackScholes/FdBlackScholesVanillaEngine
• BlackScholes/BaroneAdesiWhaleyApproximationEngine
Engine description:
BlackScholes/FdBlackScholesVanillaEngine builds a FdBlackScholesVanillaEngine. A
sample configuration is shown in listing 93
The parameters have the following meaning:
• Scheme: The finite difference scheme to use

157
 • TimeStepsPerYear: Time grid specification
• XGrid: State grid specification
• DampingSteps: Number of damping steps taken by FD solver
• EnforceMonotoneVariance [optional]: If true variance is modified to be monotone
if needed, defaults to true
• TimeGridMinimumSize [optional]: Minimum number in resulting time grid,
defaults to 1 if not given
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityOptionAmerican">
<Model>BlackScholes</Model>
<ModelParameters/>
<Engine>FdBlackScholesVanillaEngine</Engine>
<EngineParameters>
<Parameter name="Scheme">Douglas</Parameter>
<Parameter name="TimeGridPerYear">100</Parameter>
<Parameter name="XGrid">100</Parameter>
<Parameter name="DampingSteps">0</Parameter>
<Parameter name="EnforceMonotoneVariance">true</Parameter>
<Parameter name="SensitivityTemplate">COMM_FD</Parameter>
</EngineParameters>
</Product>

Listing 93: Configuration for Product CommodityOptionAmerican, Model BlackScholes, Engine

FdBlackScholesVanillaEngine
BlackScholes/BaroneAdesiWhaleyApproximationEngine builds a
BaroneAdesiWhaleyApproximationEngine. A sample configuration is shown in listing
94
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommodityOptionAmerican">
<Model>BlackScholes</Model>
<ModelParameters/>
<Engine>BaroneAdesiWhaleyApproximationEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 94: Configuration for Product CommodityOptionAmerican, Model BlackScholes, Engine

BaroneAdesiWhaleyApproximationEngine

7.3.43 Product Type: CommoditySwap

Used by trade type: CommoditySwap
Available Model/Engine pairs: DiscountedCashflows/CommoditySwapEngine
Engine description:

158
DiscountedCashflows/CommoditySwapEngine builds a DiscountingSwapEngine. A
sample configuration is shown in listing 95
The parameters have the following meaning:
•
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommoditySwap">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>CommoditySwapEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 95: Configuration for Product CommoditySwap, Model DiscountedCashflows, Engine

CommoditySwapEngine

7.3.44 Product Type: CommoditySwaption

Used by trade type: CommoditySwaption
Available Model/Engine pairs:
• Black/AnalyticalApproximation
• Black/MonteCarlo
Engine description:
Black/AnalyticalApproximation builds a CommoditySwaptionEngine using moment
matching. The correlation between two future contracts is parametrized as

ρ(s, t) = e−β|s−t|

where s and t are times to futures expiry. A sample configuration is shown in listing 96
The parameters have the following meaning:
• beta: the parameter “beta” in the correlation parametrization
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommoditySwaption">
<Model>Black</Model>
<ModelParameters/>
<Engine>AnalyticalApproximation</Engine>
<EngineParameters>
<Parameter name="beta">2.05</Parameter>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 96: Configuration for Product CommoditySwaption, Model Black, Engine AnalyticalAp-
proximation

159
Black/MonteCarlo builds a CommoditySwaptionMonteCarloEngine using Sobol
sequences. The same correlation parametrization as above is used. A sample
configuration is shown in listing 97
The parameters have the following meaning:
• beta: the parameter “beta” in the correlation parametrization
• samples: the number of MC samples to use
• seed: the seed to use
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CommoditySwaption">
<Model>Black</Model>
<ModelParameters/>
<Engine>MonteCarlo</Engine>
<EngineParameters>
<Parameter name="beta">2.05</Parameter>
<Parameter name="samples">10000</Parameter>
<Parameter name="seed">42</Parameter>
<Parameter name="SensitivityTemplate">COMM_MC</Parameter>
</EngineParameters>
</Product>

Listing 97: Configuration for Product CommoditySwaption, Model Black, Engine MonteCarlo

7.3.45 Product Type: EquityAsianOptionArithmeticPrice

Used by trade type: EquityAsianOption if payoffType2 is Arithmetric and payoffType
is Asian
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteArithmeticAPEngine
• BlackScholesMerton/TurnbullWakemanAsianEngine
• ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteArithmeticAPEngine builds a
MCDiscreteArithmeticAPEngine using Sobol sequences. A sample configuration is
shown in listing 98.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation
• ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given

160
 • MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionArithmeticPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteArithmeticAPEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>
<Parameter name="RequiredTolerance">0</Parameter>
<Parameter name="MaxSamples">0</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">EQ_MC</Parameter>
</EngineParameters>
</Product>

Listing 98: Configuration for Product EquityAsianOptionArithmeticPrice, Model BlackSc-

holesMerton, Engine MCDiscreteArithmeticAPEngine
BlackScholesMerton/TurnbullWakemanAsianEngine builds a
TurnbullWakemanAsianEngine. A sample configuration is shown in listing 99.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionArithmeticPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>TurnbullWakemanAsianEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">EQ_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 99: Configuration for Product EquityAsianOptionArithmeticPrice, Model BlackSc-

holesMerton, Engine TurnbullWakemanAsianEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 100.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionArithmeticPrice">
<Model>ScriptedTrade</Model>
<ModelParameters/>
<Engine>ScriptedTrade</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">EQ_MC</Parameter>

161
 </EngineParameters>
</Product>

Listing 100: Configuration for Product EquityAsianOptionArithmeticPrice, Model Scripted-

Trade, Engine ScriptedTrade

7.3.46 Product Type: EquityAsianOptionArithmeticStrike

Used by trade type: EquityAsianOption if payoffType2 is Arithmetric and payoffType
is AverageStrike
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteArithmeticASEngine
• ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteArithmeticASEngine builds a
MCDiscreteArithmeticASEngine using Sobol sequences. A sample configuration is
shown in listing 101.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation
• ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given
• MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionArithmeticStrike">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteArithmeticASEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>
<Parameter name="RequiredTolerance">0</Parameter>
<Parameter name="MaxSamples">0</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">EQ_MC</Parameter>
</EngineParameters>
</Product>

162
Listing 101: Configuration for Product EquityAsianOptionArithmeticStrike, Model BlackSc-
holesMerton, Engine MCDiscreteArithmeticASEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 102.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionArithmeticStrike">
<Model>ScriptedTrade</Model>
<ModelParameters/>
<Engine>ScriptedTrade</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">EQ_MC</Parameter>
</EngineParameters>
</Product>

Listing 102: Configuration for Product EquityAsianOptionArithmeticStrike, Model Scripted-

Trade, Engine ScriptedTrade

7.3.47 Product Type: EquityAsianOptionGeometricPrice

Used by trade type: EquityAsianOption if payoffType2 is Geometric and payoffType is
Asian
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteGeometricAPEngine
• BlackScholesMerton/AnalyticDiscreteGeometricAPEngine
• BlackScholesMerton/AnalyticContinuousGeometricAPEngine
• ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteGeometricAPEngine builds a
MCDiscreteGeometricAPEngine using Sobol sequences. A sample configuration is
shown in listing 103.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation
• ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given

163
 • MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionGeometricPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteGeometricAPEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>
<Parameter name="RequiredTolerance">0</Parameter>
<Parameter name="MaxSamples">0</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">EQ_MC</Parameter>
</EngineParameters>
</Product>

Listing 103: Configuration for Product EquityAsianOptionGeometricPrice, Model BlackSc-

holesMerton, Engine MCDiscreteGeometricAPEngine
BlackScholesMerton/AnalyticDiscreteGeometricAPEngine builds a
AnalyticDiscreteGeometricAveragePriceAsianEngine. A sample configuration is shown
in listing 104.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionGeometricPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticDiscreteGeometricAPEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">EQ_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 104: Configuration for Product EquityAsianOptionGeometricPrice, Model BlackSc-

holesMerton, Engine AnalyticDiscreteGeomtetricAPEngine
BlackScholesMerton/AnalyticContinuousGeometricAPEngine builds a
AnalyticContinuousGeometricAveragePriceAsianEngine. A sample configuration is
shown in listing 105.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionGeometricPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticContinuousGeometricAPEngine</Engine>
<EngineParameters>

164
 <Parameter name="SensitivityTemplate">EQ_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 105: Configuration for Product EquityAsianOptionGeometricPrice, Model BlackSc-

holesMerton, Engine AnalyticContinuousGeomtetricAPEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 106.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionGeometricPrice">
<Model>ScriptedTrade</Model>
<ModelParameters/>
<Engine>ScriptedTrade</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">EQ_MC</Parameter>
</EngineParameters>
</Product>

Listing 106: Configuration for Product EquityAsianOptionGeometricPrice, Model Scripted-

Trade, Engine ScriptedTrade

7.3.48 Product Type: EquityAsianOptionGeometricStrike

Used by trade type: EquityAsianOption if payoffType2 is Geometric and payoffType is
AverageStrike
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteGeometricASEngine
• BlackScholesMerton/AnalyticDiscreteGeometricASEngine
• ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteGeometricASEngine builds a
MCDiscreteGeometricASEngine using Sobol sequences. A sample configuration is
shown in listing 107.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation
• ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given

165
 • MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionGeometricStrike">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteGeometricASEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>
<Parameter name="RequiredTolerance">0</Parameter>
<Parameter name="MaxSamples">0</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">EQ_MC</Parameter>
</EngineParameters>
</Product>

Listing 107: Configuration for Product EquityAsianOptionGeometricStrike, Model BlackSc-

holesMerton, Engine MCDiscreteGeometricASEngine
BlackScholesMerton/AnalyticDiscreteGeometricASEngine builds a
AnalyticDiscreteGeometricAverageStrikeAsianEngine. A sample configuration is shown
in listing 108.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionGeometricStrike">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticDiscreteGeometricASEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">EQ_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 108: Configuration for Product EquityAsianOptionGeometricStrike, Model BlackSc-

holesMerton, Engine AnalyticDiscreteGeomtetricASEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 109.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityAsianOptionGeometricStrike">
<Model>ScriptedTrade</Model>
<ModelParameters/>
<Engine>ScriptedTrade</Engine>
<EngineParameters>

166
 <Parameter name="SensitivityTemplate">EQ_MC</Parameter>
</EngineParameters>
</Product>

Listing 109: Configuration for Product EquityAsianOptionGeometricStrike, Model Scripted-

Trade, Engine ScriptedTrade

7.3.49 Product Type: EquityBarrierOption, FxBarrierOption

Used by trade type: EquityBarrierOption resp. FxBarrierOption
Available Model/Engine pairs:
• BlackScholesMerton/AnalyticBarrierEngine
• BlackScholesMerton/FdBlackScholesBarrierEngine
Engine description:
BlackScholes/AnalyticBarrierEngine builds a AnalyticBarrierEngine. A sample
configuration is shown in listing 110 for equity. The configuration for fx is identical
except the Model is set to GarmanKohlhagen.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityBarrierOption">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticBarrierEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">EQ_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 110: Configuration for Product EquityBarrierOption, Model BlackScholesMertong En-

gine AnalyticBarrierEngine
BlackScholes/FdBlackScholesBarrierEngine builds a FdBlackScholesBarrierEngine. A
sample configuration is shown in listing 111 for equity. The configuration for fx is
identical except the Model is set to GarmanKohlhagen.
The parameters have the following meaning:
• Scheme: The finite difference scheme to use
• TimeStepsPerYear: Time grid specification
• XGrid: State grid specification
• DampingSteps: Number of damping steps taken by FD solver
• EnforceMonotoneVariance [optional]: If true variance is modified to be monotone
if needed, defaults to true
• SensitivityTemplate [optional]: the sensitivity template to use

167
<Product type="EquityBarrierOption">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>FdBlackScholesBarrierEngine</Engine>
<EngineParameters>
<Parameter name="Scheme">Douglas</Parameter>
<Parameter name="TimeGridPerYear">100</Parameter>
<Parameter name="XGrid">100</Parameter>
<Parameter name="DampingSteps">0</Parameter>
<Parameter name="EnforceMonotoneVariance">true</Parameter>
<Parameter name="SensitivityTemplate">EQ_FD</Parameter>
</EngineParameters>
</Product>

Listing 111: Configuration for Product EquityBarrierOption, Model BlackScholesMerton, En-

gine FdBlackScholesBarrierEngine

7.3.50 Product Type: EquityDoubleBarrierOption,

FxDoubleBarrierOption
Used by trade type: EquityDoubleBarrierOption, FxDoubleBarrierOption
Available Model/Engine pairs: GarmanKohlhagen/AnalyticDoubleBarrierEngine (both
fx and equity)
Engine description:
GarmanKohlhagen/AnalyticDoubleBarrierEngine builds a
AnalyticDoubleBarrierEngine. A sample configuration is shown in listing 112. The
configuration for equity is identical.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxDoubleBarrierOption">
<Model>GarmanKohlhagen</Model>
<ModelParameters/>
<Engine>AnalyticDoubleBarrierEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 112: Configuration for Product FxDoubleBarrierOption, Model GarmanKohlhagen, En-

gine AnalyticDoubleBarrierBinaryEngine

7.3.51 Product Type: EquityDigitalOption, FxDigitalOption

Used by trade type: EquityDigitalOption, FxDigitalOption
Available Model/Engine pairs: BlackScholesMerton/AnalyticEuropeanEngine (equity)
resp. GarmanKohlhagen/AnalyticEuropeanEngine (fx)
Engine description:

168
BlackScholesMerton/AnalyticEuropeanEngine (equity) resp.
GarmanKohlhagen/AnalyticEuropeanEngine (fx) builds a AnalyticEuropeanEngine. A
sample configuration is shown in listing 113 for fx. The configuration for equity is
identical except the Model is set to BlackScholesMerton.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxDigitalOption">
<Model>GarmanKohlhagen</Model>
<ModelParameters/>
<Engine>AnalyticEuropeanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 113: Configuration for Product FxDigitalOption, Model GarmanKohlhagen, Engine An-
alyticEuropeanEngine

7.3.52 Product Type: EquityEuropeanCompositeOption

Used by trade type: EquityOption if a composite option is built
Available Model/Engine pairs: BlackScholes/AnalyticEuropeanEngine
Engine description:
BlackScholes/AnalyticEuropeanEngine builds a AnalyticEuropeanEngine (with a vol
composed from the relevant equity and fx vol surfaces). A sample configuration is
shown in listing 114
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityEuropeanCompositeOption">
<Model>BlackScholes</Model>
<ModelParameters/>
<Engine>AnalyticEuropeanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">EQ_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 114: Configuration for Product EquityEuropeanCompositeOption, Model BlackScholes,

Engine AnalyticEuropeanEngine

7.3.53 Product Type: EquityForward

Used by trade type: EquityForward
Available Model/Engine pairs: DiscountedCashflows/DiscountingEquityForwardEngine
Engine description:

169
DiscountedCashflows/DiscountingEquityForwardEngine builds a
DiscountingEquityForwardEngine. A sample configuration is shown in listing 115
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityForward">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>DiscountingEquityForwardEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">EQ_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 115: Configuration for Product EquiytForward, Model DiscountedCashflows, Engine

DiscountingEquityForwardEngine

7.3.54 Product Type: EquityFutureOption

Used by trade type: EquityFuturesOption
Available Model/Engine pairs: BlackScholes/AnalyticEuroepanForwardEngine
Engine description:
BlackScholes/AnalyticEuroepanForwardEngine builds a
AnalyticEuropeanForwardEngine. A sample configuration is shown in listing 116
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityFutureOption">
<Model>BlackScholes</Model>
<ModelParameters />
<Engine>AnalyticEuropeanForwardEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 116: Configuration for Product EquiytFutureOption, Model BlackScholes, Engine Ana-
lyticEuropeanForwardEngine

7.3.55 Product Type: EquityOption

Used by trade type: EquityOption
Available Model/Engine pairs: BlackScholesMerton/AnalyticEuropeanEngine
Engine description:
BlackScholesMerton/AnalyticEuropeanEngine builds a AnalyticEuropeanEngine. A
sample configuration is shown in listing 117
The parameters have the following meaning:

170
 • SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityOption">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticEuropeanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 117: Configuration for Product EquityOption, Model BlackScholesMerton, Engine An-
alyticEuropeanEngine

7.3.56 Product Type: EquityCliquetOption

Used by trade type: EquityCliquetOption
Available Model/Engine pairs: BlackScholes/MCScript
Engine description:
BlackScholes/MCScript builds a CliquetOptionMcScriptEngine which uses the scripted
trade framework. A sample configuration is shown in listing 118
The parameters have the following meaning:
• Samples: number of MC samples to use
• RegressionOrder: the regression order to use for conditional expectations (not
used by this engine)
• Interactive: whether to enable the interactive debugger
• ScriptedLibraryOverride: whether to override a script ’EquityCliquetOption’ in
the script library with a hardcoded script
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityCliquetOption">
<Model>BlackScholes</Model>
<ModelParameters/>
<Engine>MCScript</Engine>
<EngineParameters>
<Parameter name="Samples">10000</Parameter>
<Parameter name="RegressionOrder">6</Parameter>
<Parameter name="Interactive">false</Parameter>
<Parameter name="ScriptedLibraryOverride">false</Parameter>
<Parameter name="SensitivityTemplate">EQ_MC</Parameter>
</EngineParameters>
</Product>

Listing 118: Configuration for Product EquityCliquetOption, Model BlackScholes, Engine MC-
Script

171
7.3.57 Product Type: QuantoEquityOption
Used by trade type: EquityOption with quanto payoff (pay currency does not match
equity currency)
Available Model/Engine pairs: BlackScholes/AnalyticEuropeanEngine
Engine description:
BlackScholes/AnalyticEuropeanEngine builds a AnalyticEuropeanEngine. A sample
configuration is shown in listing 119
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="QuantoEquityOption">
<Model>BlackScholes</Model>
<ModelParameters>
<Parameter name="FXSource">GENERIC</Parameter>
</ModelParameters>
<Engine>AnalyticEuropeanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">EQ_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 119: Configuration for Product QuantoEquityOption, Model BlackScholes, Engine An-
alyticEuropeanEngine

7.3.58 Product Type: EquityOptionEuropeanCS

Used by trade type: EquityOption if cash settled
Available Model/Engine pairs:
BlackScholesMerton/AnalyticCashSettledEuropeanEngine
Engine description:
BlackScholesMerton/AnalyticCashSettledEuropeanEngine builds a
AnalyticCashSettledEuropeanEngine. A sample configuration is shown in listing 120
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityOptionEuropeanCS">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticCashSettledEuropeanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 120: Configuration for Product EquityOptionEuropeanCS, Model BlackScholesMerton,

Engine AnalyticCashSettledEuropeanEngine

172
7.3.59 Product Type: EquityOptionAmerican
Used by trade type: EquityOption if exercise stly is american
Available Model/Engine pairs:
• BlackScholesMerton/FdBlackScholesVanillaEngine
• BlackScholesMerton/BaroneAdesiWhaleyApproximationEngine
Engine description:
BlackScholesMerton/FdBlackScholesVanillaEngine builds a
FdBlackScholesVanillaEngine. A sample configuration is shown in listing 121
The parameters have the following meaning:
• Scheme: The finite difference scheme to use
• TimeStepsPerYear: Time grid specification
• XGrid: State grid specification
• DampingSteps: Number of damping steps taken by FD solver
• EnforceMonotoneVariance [optional]: If true variance is modified to be monotone
if needed, defaults to true
• TimeGridMinimumSize [optional]: Minimum number in resulting time grid,
defaults to 1 if not given
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityOptionAmerican">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>FdBlackScholesVanillaEngine</Engine>
<EngineParameters>
<Parameter name="Scheme">Douglas</Parameter>
<Parameter name="TimeGridPerYear">100</Parameter>
<Parameter name="XGrid">100</Parameter>
<Parameter name="DampingSteps">0</Parameter>
<Parameter name="EnforceMonotoneVariance">true</Parameter>
<Parameter name="SensitivityTemplate">COMM_FD</Parameter>
</EngineParameters>
</Product>

Listing 121: Configuration for Product EquityOptionAmerican, Model BlackScholesMerton, En-

gine FdBlackScholesVanillaEngine
BlackScholesMerton/BaroneAdesiWhaleyApproximationEngine builds a
BaroneAdesiWhaleyApproximationEngine. A sample configuration is shown in listing
122
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="EquityOptionAmerican">
<Model>BlackScholesMerton</Model>

173
 <ModelParameters/>
<Engine>BaroneAdesiWhaleyApproximationEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 122: Configuration for Product EquityOptionAmerican, Model BlackScholesMerton, En-

gine BaroneAdesiWhaleyApproximationEngine

7.3.60 Product Type: EquityTouchOption, FxTouchOption

Used by trade type: EquityTouchOption, FxTouchOption
Available Model/Engine pairs: BlackScholesMerton/AnalyticDigitalAmericanEngine
for equity resp. GarmanKohlhagen/AnalyticDigitalAmericanEngine for fx
Engine description:
BlackScholesMerton/AnalyticDigitalAmericanEngine (equity) reps.
GarmanKohlhagen/AnalyticDigitalAmericanEngine (fx) builds a
AnalyticDigitalAmericanEngine (one touch) or AnalyticDigitalAmericanKOEngine (no
touch). A sample configuration is shown in listing 123 for fx. The configuration for
equity is the same except the Model ist set to BlackScholesMerton.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxTouchOption">
<Model>GarmanKohlhagen</Model>
<ModelParameters/>
<Engine>AnalyticDigitalAmericanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 123: Configuration for Product FxTouchOption, Model GarmanKohlhagen, Engine An-
alyticDigitalAmericanEngine

7.3.61 Product Type: ForwardBond

Used by trade type: ForwardBond
Available Model/Engine pairs: DiscountedCashflows/DiscountingForwardBondEngine
Engine description:
DiscountedCashflows/DiscountingForwardBondEngine builds a
DiscountingForwardBondEngine. A sample configuration is shown in listing 124.
The parameters have the following meaning:
• TimestepPeriod: discretization interval for zero bond pricing
• SensitivityTemplate [optional]: the sensitivity template to use

174
<Product type="ForwardBond">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>DiscountingForwardBondEngine</Engine>
<EngineParameters>
<Parameter name="TimestepPeriod">3M</Parameter>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 124: Configuration for Product ForwardBond, Model DiscountedCashflows, Engine Dis-
countingForwardBondEngine

7.3.62 Product Type: EquityVarianceSwap, CommodityVarianceSwap,

FxVarianceSwap
Used by trade type: EquityVarianceSwap, CommodityVarianceSwap, FxVarianceSwap
Available Model/Engine pairs: BlackScholesMerton/EquityVarianceSwap (resp.
Commodity, Fx)
Engine description:
BlackScholesMerton/EquityVarianceSwap (resp. Commodity, Fx) builds a
GeneralisedReplicatingVarianceSwapEngine or VolatilityFromVarianceSwapEngine
depending on MomentType Variance, Volatility. A sample configuration is shown in
listing 125 and 126. The example is for Equity, but holds equally for product types
CommodityVarianceSwap, FxVarianceSwap.
The parameters have the following meaning:
• Scheme [Optional, default GaussLobatto]: GaussLobatto or Segment, this
determines the integration scheme used
• Bounds [Optional, default PriceThreshold]: “Fixed”: The integration bounds are
found by

√ √
Lower = F emσ T
, Upper = F eM σ T

where m is the FixedMinStdDevs and M is the FixedMaxStdDevs parameter

listed below and σ is the ATMF volatility of the underlying at maturity T .
“PriceThreshold”: The integration bounds are found by looking for the largest
(smallest) strikes Lower, Upper such that the integrand in the replication formula
above is below the PriceThreshold parameter listed below. The search starts at
the forward level F for Lower, Upper and then Lower, Upper are updated by
factors 1 − p resp. 1 + p where p is the PriceThresholdStep parameter below,
until either the price threshold criterium is met or the number of updates exceeds
the MaxPriceThresholdSteps parameter.
• Accuracy [Optional, default 10−5 ]: Numerical accuracy tolerance for the
numerical integration. This only applies to the GaussLobatto scheme.

175
 • MaxIterations [Optional, default 1000]: The maximum number of iterations
performed in the numerical integration. This only applies to the GaussLobatto
scheme.
• Steps [Optional, default 100]: The number of steps in the Segment numerical
integration scheme (only applies for this scheme).
• PriceThreshold [Optional, default 10−10 ]: Used to determine the integration
bounds if Bounds = PriceThredshold, see above.
• MaxPriceThresholdSteps [Optional, default 100]: Used to determine the
integration bounds if Bounds = PriceThredshold, see above.
• PriceThresholdStep [Option, default 0.1]: Used to determine the integration
bounds if Bounds = PriceThredshold, see above.
• FixedMinStdDevs [Optional, default −5]: Used to determine the integration
bounds if Bounds = Fixed, see above.
• FixedMaxStdDevs [Optional, default 5]: Used to determine the integration
bounds, if Bounds = Fixed, see above.
• StaticTodaysSpot [Optional, default false]: If true the contribution to the
variance from the last day before the valuation date to the valuation date is
ignored in scenario / sensitivity calculations. See below for more details.
• SensitivityTemplate [optional]: the sensitivity template to use

Listing 125: Configuration for Product EquityVarianceSwap, Model BlackScholesMerton, En-

gine ReplicatingVarianceSwapEngine, “Robust” configuration using PriceThreshold if market
smiles are of lower quality.

<Product type="EquityVarianceSwap">
<Model>BlackScholesMerton</Model>
<ModelParameters>
<Parameter name="StaticTodaysSpot">false</Parameter>
</ModelParameters>
<Engine>ReplicatingVarianceSwapEngine</Engine>
<EngineParameters>
<Parameter name="Scheme">Segment</Parameter>
<Parameter name="Bounds">PriceThreshold</Parameter>
<Parameter name="Steps">1000</Parameter>
<Parameter name="PriceThreshold">1E-10</Parameter>
<Parameter name="MaxPriceThresholdSteps">500</Parameter>
<Parameter name="PriceThresholdStep">0.1</Parameter>
</EngineParameters>
</Product>

7.3.63 Product Type: FxAsianOptionArithmeticPrice

Used by trade type: FxAsianOption if payoffType2 is Arithmetric and payoffType is
Asian
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteArithmeticAPEngine

176
Listing 126: Configuration for Product EquityVarianceSwap, Model BlackScholesMerton, En-
gine ReplicatingVarianceSwapEngine, Alternative “Robust” variance swap pricing engine con-
figuration using fixed integration bounds.

<Product type="EquityVarianceSwap">
<Model>BlackScholesMerton</Model>
<ModelParameters>
<Parameter name="StaticTodaysSpot">false</Parameter>
</ModelParameters>
<Engine>ReplicatingVarianceSwapEngine</Engine>
<EngineParameters>
<Parameter name="Scheme">Segment</Parameter>
<Parameter name="Bounds">Fixed</Parameter>
<Parameter name="Steps">1000</Parameter>
<Parameter name="FixedMinStdDevs">-5.0</Parameter>
<Parameter name="FixedMaxStdDevs">5.0</Parameter>
</EngineParameters>
</Product>

• BlackScholesMerton/TurnbullWakemanAsianEngine
• ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteArithmeticAPEngine builds a
MCDiscreteArithmeticAPEngine using Sobol sequences. A sample configuration is
shown in listing 127.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation
• ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given
• MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionArithmeticPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteArithmeticAPEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>

177
 <Parameter name="RequiredTolerance">0</Parameter>
<Parameter name="MaxSamples">0</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">FX_MC</Parameter>
</EngineParameters>
</Product>

Listing 127: Configuration for Product FxAsianOptionArithmeticPrice, Model BlackSc-

holesMerton, Engine MCDiscreteArithmeticAPEngine
BlackScholesMerton/TurnbullWakemanAsianEngine builds a
TurnbullWakemanAsianEngine. A sample configuration is shown in listing 128.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionArithmeticPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>TurnbullWakemanAsianEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 128: Configuration for Product FxAsianOptionArithmeticPrice, Model BlackSc-

holesMerton, Engine TurnbullWakemanAsianEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 129.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionArithmeticPrice">
<Model>ScriptedTrade</Model>
<ModelParameters/>
<Engine>ScriptedTrade</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_MC</Parameter>
</EngineParameters>
</Product>

Listing 129: Configuration for Product FxAsianOptionArithmeticPrice, Model ScriptedTrade,

Engine ScriptedTrade

7.3.64 Product Type: FxAsianOptionArithmeticStrike

Used by trade type: FxAsianOption if payoffType2 is Arithmetric and payoffType is
AverageStrike
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteArithmeticASEngine

178
 • ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteArithmeticASEngine builds a
MCDiscreteArithmeticASEngine using Sobol sequences. A sample configuration is
shown in listing 130.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation
• ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given
• MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionArithmeticStrike">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteArithmeticASEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>
<Parameter name="RequiredTolerance">0</Parameter>
<Parameter name="MaxSamples">0</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">FX_MC</Parameter>
</EngineParameters>
</Product>

Listing 130: Configuration for Product FxAsianOptionArithmeticStrike, Model BlackSc-

holesMerton, Engine MCDiscreteArithmeticASEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 131.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionArithmeticStrike">
<Model>ScriptedTrade</Model>
<ModelParameters/>
<Engine>ScriptedTrade</Engine>

179
 <EngineParameters>
<Parameter name="SensitivityTemplate">FX_MC</Parameter>
</EngineParameters>
</Product>

Listing 131: Configuration for Product FxAsianOptionArithmeticStrike, Model ScriptedTrade,

Engine ScriptedTrade

7.3.65 Product Type: FxAsianOptionGeometricPrice

Used by trade type: FxAsianOption if payoffType2 is Geometric and payoffType is
Asian
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteGeometricAPEngine
• BlackScholesMerton/AnalyticDiscreteGeometricAPEngine
• BlackScholesMerton/AnalyticContinuousGeometricAPEngine
• ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteGeometricAPEngine builds a
MCDiscreteGeometricAPEngine using Sobol sequences. A sample configuration is
shown in listing 132.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation
• ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given
• MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionGeometricPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteGeometricAPEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>
<Parameter name="RequiredTolerance">0</Parameter>
<Parameter name="MaxSamples">0</Parameter>

180
 <Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">FX_MC</Parameter>
</EngineParameters>
</Product>

Listing 132: Configuration for Product FxAsianOptionGeometricPrice, Model BlackSc-

holesMerton, Engine MCDiscreteGeometricAPEngine
BlackScholesMerton/AnalyticDiscreteGeometricAPEngine builds a
AnalyticDiscreteGeometricAveragePriceAsianEngine. A sample configuration is shown
in listing 133.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionGeometricPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticDiscreteGeometricAPEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 133: Configuration for Product FxAsianOptionGeometricPrice, Model BlackSc-

holesMerton, Engine AnalyticDiscreteGeomtetricAPEngine
BlackScholesMerton/AnalyticContinuousGeometricAPEngine builds a
AnalyticContinuousGeometricAveragePriceAsianEngine. A sample configuration is
shown in listing 134.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionGeometricPrice">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticContinuousGeometricAPEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 134: Configuration for Product FxAsianOptionGeometricPrice, Model BlackSc-

holesMerton, Engine AnalyticContinuousGeomtetricAPEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 135.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionGeometricPrice">
<Model>ScriptedTrade</Model>

181
 <ModelParameters/>
<Engine>ScriptedTrade</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_MC</Parameter>
</EngineParameters>
</Product>

Listing 135: Configuration for Product FxAsianOptionGeometricPrice, Model ScriptedTrade,

Engine ScriptedTrade

7.3.66 Product Type: FxAsianOptionGeometricStrike

Used by trade type: FxAsianOption if payoffType2 is Geometric and payoffType is
AverageStrike
Available Model/Engine pairs:
• BlackScholesMerton/MCDiscreteGeometricASEngine
• BlackScholesMerton/AnalyticDiscreteGeometricASEngine
• ScriptedTrade/ScriptedTrade
Engine description:
BlackScholesMerton/MCDiscreteGeometricASEngine builds a
MCDiscreteGeometricASEngine using Sobol sequences. A sample configuration is
shown in listing 136.
The parameters have the following meaning:
• BrownianBridge: whether to use Brownian Bridge for MC simulation
• AntitheticVariate: whether to use antithetic variates for MC simulation
• ControlVariate: whether to use control variate for MC simulation
• RequiredSamples: minimum number of samples for MC simulation, if 0 (not
specified) RequiredTolerance must be given
• RequiredTolernace: max tolerance for MC error, if 0 (not specified)
RequiredSamples must be given
• MaxSamples: max number of samples for MC simulation
• Seed: seed for random number generator
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionGeometricStrike">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>MCDiscreteGeometricASEngine</Engine>
<EngineParameters>
<Parameter name="BrownianBridge">true</Parameter>
<Parameter name="AntitheticVariate">true</Parameter>
<Parameter name="ControlVariate">true</Parameter>
<Parameter name="RequiredSamples">10000</Parameter>
<Parameter name="RequiredTolerance">0</Parameter>

182
 <Parameter name="MaxSamples">0</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="SensitivityTemplate">FX_MC</Parameter>
</EngineParameters>
</Product>

Listing 136: Configuration for Product FxAsianOptionGeometricStrike, Model BlackSc-

holesMerton, Engine MCDiscreteGeometricASEngine
BlackScholesMerton/AnalyticDiscreteGeometricASEngine builds a
AnalyticDiscreteGeometricAverageStrikeAsianEngine. A sample configuration is shown
in listing 137.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionGeometricStrike">
<Model>BlackScholesMerton</Model>
<ModelParameters/>
<Engine>AnalyticDiscreteGeometricASEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 137: Configuration for Product FxAsianOptionGeometricStrike, Model BlackSc-

holesMerton, Engine AnalyticDiscreteGeomtetricASEngine
ScriptedTrade/ScriptedTrade delegates to the scripted trade engine and the associated
pricing engine configuration for Product Type ScriptedTrade, see there for details. A
sample configuration is given in listing 138.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxAsianOptionGeometricStrike">
<Model>ScriptedTrade</Model>
<ModelParameters/>
<Engine>ScriptedTrade</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_MC</Parameter>
</EngineParameters>
</Product>

Listing 138: Configuration for Product FxAsianOptionGeometricStrike, Model ScriptedTrade,

Engine ScriptedTrade

7.3.67 Product Type: FxDigitalOptionEuropeanCS

Used by trade type: FxDigitalOption if cash settled, FxEuropeanBarrierOption
Available Model/Engine pairs:
GarmanKohlhagen/AnalyticCashSettledEuropeanEngine
Engine description:

183
GarmanKohlhagen/AnalyticCashSettledEuropeanEngine builds a
AnalyticCashSettledEuropeanEngine. A sample configuration is shown in listing 139
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxDigitalOptionEuropeanCS">
<Model>GarmanKohlhagen</Model>
<ModelParameters/>
<Engine>AnalyticCashSettledEuropeanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 139: Configuration for Product FxDigitalOptionEuropeanCS, Model GarmanKohlhagen,

Engine AnalyticCashSettledEuropeanEngine

7.3.68 Product Type: FxDigitalBarrierOption

Used by trade type: FxDigitalBarrierOption
Available Model/Engine pairs: GarmanKohlhagen/FdBlackScholesBarrierEngine
Engine description:
GarmanKohlhagen/FdBlackScholesBarrierEngine builds a
FdBlackScholesBarrierEngine. A sample configuration is shown in listing 140
The parameters have the following meaning:
• Scheme: The finite difference scheme to use
• TimeStepsPerYear: Time grid specification
• XGrid: State grid specification
• DampingSteps: Number of damping steps taken by FD solver
• EnforceMonotoneVariance [optional]: If true variance is modified to be monotone
if needed, defaults to true
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxDigitalBarrierOption">
<Model>GarmanKohlhagen</Model>
<ModelParameters/>
<Engine>FdBlackScholesBarrierEngine</Engine>
<EngineParameters>
<Parameter name="Scheme">Douglas</Parameter>
<Parameter name="TimeGridPerYear">100</Parameter>
<Parameter name="XGrid">100</Parameter>
<Parameter name="DampingSteps">0</Parameter>
<Parameter name="SensitivityTemplate">FX_FD</Parameter>
</EngineParameters>
</Product>

184
Listing 140: Configuration for Product FxDigitalBarrierOption, Model GarmanKohlhagen, En-
gine FdBlackScholesBarrierEngine

7.3.69 Product Type: FormulaBasedCoupon

Used by trade type: leg type FormulaBased (coupon pricer)
Available Model/Engine pairs:
• BrigoMercurio/MC
Engine description:
BrigoMercurio/MC builds a MCGaussianFormulaBasedCouponPricer. A sample
configuration is shown in listing 141. We refer to the formula based coupon module
documentation for further details.
The parameters have the following meaning:
• FXSource: specifies the FX index tag to be used to look up FX-Ibor or FX-CMS
correlations
• Samples: number of MC samples to use
• Sobol: whether to use Sobol numbers for simulation
• SalvageCorrelationMatrix: whether to make the input correlation matrix positive
definite
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FormulaBasedCoupon">
<Model>BrigoMercurio</Model>
<ModelParameters>
<Parameter name="FXSource">GENERIC</Parameter>
</ModelParameters>
<Engine>MC</Engine>
<EngineParameters>
<Parameter name="Samples">10000</Parameter>
<Parameter name="Seed">42</Parameter>
<Parameter name="Sobol">Y</Parameter>
<Parameter name="SalvageCorrelationMatrix">Y</Parameter>
<Parameter name="SensitivityTemplate">IR_MC</Parameter>
</EngineParameters>
</Product>

Listing 141: Configuration for Product FormulaBasedCoupon, Model BrigoMercurio, Engine

MC

7.3.70 Product Type: FxForward

Used by trade type: FxForward
Available Model/Engine pairs:
• DiscountedCashflows/DiscountingFxForwardEngine

185
 • CrossAssetModel/AMC (for use in AMC simulations only)
Engine description:
DiscountedCashflows/DiscountingFxForwardEngine builds a
DiscountingFxForwardEngine. A sample configuration is shown in listing 142.
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxForward">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>DiscountingFxForwardEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_Analytical</Parameter>
<Parameter name="IncludeSettlementDateFlows">true</Parameter>
</EngineParameters>
</Product>

Listing 142: Configuration for Product FxForward, Model DiscountedCashflows, Engine Dis-
countingFxForwardEngine
CrossAssetModel/AMC builds a McCamFxForwardEngine for use in AMC
simulations. We refer to the AMC module documentation for further details.
Parameter IncludeSettlementDateFlows is set to false by default, i.e. cash flows on the
maturity date of the trade are not taken into account when pricing as of maturity date
so that the trade has zero value on maturity. In case of true we do take the final flows
into account while the trade is “maturing”.

7.3.71 Product Type: FxOption

Used by trade type: FxOption
Available Model/Engine pairs:
• GarmanKohlhagen/AnalyticEuropeanEngine
• CrossAssetModel/AMC (for use in AMC simulations only)
Engine description:
GarmanKohlhagen/AnalyticEuropeanEngine builds a AnalyticEuropeanEngine. A
sample configuration is shown in listing 143
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxOption">
<Model>GarmanKohlhagen</Model>
<ModelParameters/>
<Engine>AnalyticEuropeanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

186
Listing 143: Configuration for Product FxOption, Model GarmanKohlhagen, Engine Analyt-
icEuropeanEngine
CrossAssetModel/AMC builds a McCamFxOptionEngine for use in AMC simulations.
We refer to the AMC module documentation for further details.

7.3.72 Product Type: FxOptionEuropeanCS

Used by trade type: FxOption if cash settled
Available Model/Engine pairs:
GarmanKohlhagen/AnalyticCashSettledEuropeanEngine
Engine description:
GarmanKohlhagen/AnalyticCashSettledEuropeanEngine builds a
AnalyticCashSettledEuropeanEngine. A sample configuration is shown in listing 144
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxOptionEuropeanCS">
<Model>GarmanKohlhagen</Model>
<ModelParameters/>
<Engine>AnalyticCashSettledEuropeanEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 144: Configuration for Product FxOptionEuropeanCS, Model GarmanKohlhagen, En-

gine AnalyticCashSettledEuropeanEngine

7.3.73 Product Type: FxOptionAmerican

Used by trade type: FxOption if exercise stly is american
Available Model/Engine pairs:
• GarmanKohlhagen/FdGarmanKohlhagenVanillaEngine
• GarmanKohlhagen/BaroneAdesiWhaleyApproximationEngine
Engine description:
GarmanKohlhagen/FdBlackScholesVanillaEngine builds a
FdBlackScholesVanillaEngine. A sample configuration is shown in listing 145
The parameters have the following meaning:
• Scheme: The finite difference scheme to use
• TimeStepsPerYear: Time grid specification
• XGrid: State grid specification
• DampingSteps: Number of damping steps taken by FD solver

187
 • EnforceMonotoneVariance [optional]: If true variance is modified to be monotone
if needed, defaults to true
• TimeGridMinimumSize [optional]: Minimum number in resulting time grid,
defaults to 1 if not given
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxOptionAmerican">
<Model>GarmanKohlhagen</Model>
<ModelParameters/>
<Engine>FdBlackScholesVanillaEngine</Engine>
<EngineParameters>
<Parameter name="Scheme">Douglas</Parameter>
<Parameter name="TimeGridPerYear">100</Parameter>
<Parameter name="XGrid">100</Parameter>
<Parameter name="DampingSteps">0</Parameter>
<Parameter name="EnforceMonotoneVariance">true</Parameter>
<Parameter name="SensitivityTemplate">COMM_FD</Parameter>
</EngineParameters>
</Product>

Listing 145: Configuration for Product FxOptionAmerican, Model GarmanKohlhagen, Engine

FdBlackScholesVanillaEngine
GarmanKohlhagen/BaroneAdesiWhaleyApproximationEngine builds a
BaroneAdesiWhaleyApproximationEngine. A sample configuration is shown in listing
146
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxOptionAmerican">
<Model>GarmanKohlhagen</Model>
<ModelParameters/>
<Engine>BaroneAdesiWhaleyApproximationEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">COMM_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 146: Configuration for Product FxOptionAmerican, Model GarmanKohlhagen, Engine

BaroneAdesiWhaleyApproximationEngine

7.3.74 Product Type: FxDoubleTouchOption

Used by trade type: FxDoubleTouchOption
Available Model/Engine pairs:
GarmanKohlhagen/AnalyticDoubleBarrierBinaryEngine
Engine description:
GarmanKohlhagen/AnalyticDoubleBarrierBinaryEngine builds a
AnalyticDoubleBarrierBinaryEngine. A sample configuration is shown in listing 147
The parameters have the following meaning:

188
 • SensitivityTemplate [optional]: the sensitivity template to use
<Product type="FxDoubleTouchOption">
<Model>GarmanKohlhagen</Model>
<ModelParameters/>
<Engine>AnalyticDoubleBarrierBinaryEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">FX_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 147: Configuration for Product FxDoubleTouchOption, Model GarmanKohlhagen, En-

gine AnalyticDoubleBarrierBinaryEngine

7.3.75 Product Type: MultiLegOption

Used by trade type: MultiLegOption
Available Model/Engine pairs:
• CrossAssetModel/MC
• CrossAssetModel/AMC
Engine description:
CrossAssetModel/MC builds a McMultiLegOptionEngine. A sample configuration is
shown in listing 148
The parameters have the following meaning:
• IrCalibration: Bootstrap, BestFit, None
• IrCalibrationStrategy: CoterminalDealStrike, CoterminalATM
• ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept
• IrReversion: The mean reversion (given per ccy)
• IrReversionType: Hagan, HullWhite (given per ccy)
• IrVolatility: The volatility (start value for calibration if calibrated, given per ccy)
• IrVolatilityType: Hagan, HullWhite (given per ccy)
• FxVolatility: The fx volatility (start value for calibration if calibrated, given per
ccy)
• Corr_Key1_key2: The correlations for ir/fx keys (multiple entries possible)
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• [Link]: The sequence type for the traning phase, can be
MersenneTwister+, MersenneTwisterAntithetc+, Sobol+, Burley2020Sobol+,
SobolBrownianBridge+, Burley2020SobolBrownianBridge+
• [Link]: The seed for the random number generation in the training phase

189
 • [Link]: The number of samples to be used for the training phase
• [Link]: The sequence type for the pricing phase, same values allowed
as for training
• [Link]: The type of basis function system to be used for the
regression analysis, can be Monomial+, Laguerre+, Hermite+, Hyperbolic+,
Legendre+, Chbyshev+, Chebyshev2nd+
• BasisFunctionOrder: The order of the basis function system to be used
• [Link]: The seed for the random number generation in the pricing
• [Link]: The number of samples to be used for the pricing phase. If this
number is zero, no pricing run is performed, instead the (T0) NPV is estimated
from the training phase (this result is used to fill the T0 slice of the NPV cube)
• BrownianBridgeOrdering: variate ordering for Brownian bridges, can be Steps+,
Factors+, Diagonal+
• SobolDirectionIntegers: direction integers for Sobol generator, can be Unit+,
Jaeckel+, SobolLevitan+, SobolLevitanLemieux+, JoeKuoD5+, JoeKuoD6+,
JoeKuoD7+, Kuo+, Kuo2+, Kuo3+
• MinObsDate: if true the conditional expectation of each cashflow is taken from
the minimum possible observation date (i.e. the latest exercise or simulation date
before the cashflow’s event date); recommended setting is true+
• RegressorModel: Simple, LaggedFX. If not given, it defaults to Simple.
Depending on the choice the regressor is built as follows:
– Simple: For an observation date the full model state observed on this date is
included in the regressor. No past states are included though.
– LaggedFX: For an observation date the full model state observed on this
date is included in the regressor. In addition, past FX states that are
relevant for future cashflows are included. For example, for a FX resettable
cashflow the FX state observed on the FX reset date is included.
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="MultiLegOption">
<Model>CrossAssetModel</Model>
<ModelParameters>
<Parameter name="IrCalibration">Bootstrap</Parameter>
<Parameter name="IrCalibrationStrategy">CoterminalDealStrike</Parameter>
<Parameter name="FxCalibration">Bootstrap</Parameter>
<Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="IrReversion_EUR">0.0</Parameter>
<Parameter name="IrReversionType_EUR">HullWhite</Parameter>
<Parameter name="IrVolatility_EUR">0.01</Parameter>
<Parameter name="IrVolatilityType_EUR">Hagan</Parameter>
<Parameter name="IrReversion_GBP">0.0</Parameter>
<Parameter name="IrReversionType_GBP">HullWhite</Parameter>
<Parameter name="IrVolatility_GBP">0.01</Parameter>
<Parameter name="IrVolatilityType_GBP">Hagan</Parameter>
<Parameter name="FxVolatility_GBP">0.08</Parameter>
<Parameter name="Corr_IR:EUR_FX:GBP">0.23</Parameter>

190
 <Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.20</Parameter>
</ModelParameters>
<Engine>MC</Engine>
<EngineParameters>
<Parameter name="[Link]">MersenneTwisterAntithetic</Parameter>
<Parameter name="[Link]">42</Parameter>
<Parameter name="[Link]">10000</Parameter>
<Parameter name="[Link]">Monomial</Parameter>
<Parameter name="[Link]">6</Parameter>
<Parameter name="[Link]">SobolBrownianBridge</Parameter>
<Parameter name="[Link]">17</Parameter>
<Parameter name="[Link]">0</Parameter>
<Parameter name="BrownianBridgeOrdering">Steps</Parameter>
<Parameter name="SobolDirectionIntegers">JoeKuoD7</Parameter>
<Parameter name="MinObsDate">true</Parameter>
<Parameter name="RegressorModel">Simple</Parameter>
<Parameter name="SensitivityTemplate">IR_MC</Parameter>
</EngineParameters>
</Product>

Listing 148: Configuration for Product MultiLegSwaption, Model CrossAssetModel, Engine MC

LGM/AMC builds a McMultiLegOptionEngine for use in AMC simulations. We refer
to the AMC module documentation for further details.

7.3.76 Product Type: Swap

Used by trade type: Swap for single-currency swaps
Available Model/Engine pairs:
• DiscountedCashflows/DiscountingSwapEngine
• DiscountedCashflows/DiscountingSwapEngineOptimised
• CrossAssetModel/AMC
Engine description:
DiscountedCashflows/DiscountingSwapEngine builds a DiscountingSwapEngine. A
sample configuration is shown in listing 149
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="Swap">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>DiscountingSwapEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 149: Configuration for Product Swap, Model DiscountedCashflows, Engine Discount-
ingSwapEngine

191
DiscountedCashflows/DiscountingSwapEngineOptimised builds a
DiscountingSwapEngineOptimised. This is a speed-optimized version of the
DiscountingSwapEngine. In general, results should be validated against
DiscountingSwapEngine.A sample configuration is shown in listing 150
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="Swap">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>DiscountingSwapEngineOptimised</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 150: Configuration for Product Swap, Model DiscountedCashflows, Engine Discount-
ingSwapEngineOptimised
CrossAssetModel/AMC builds a McLgmSwapEngine for use in AMC simulations. We
refer to the AMC module documentation for further details.

7.3.77 Product Type: CurrencySwap

Used by trade type: Swap for cross-currency swaps
Available Model/Engine pairs:
• DiscountedCashflows/DiscountingCrossCurrencySwapEngine
• CrossAssetModel/AMC
Engine description:
DiscountedCashflows/DiscountingCrossCurrencySwapEngine builds a
DiscountingCurrencySwapEngine. A sample configuration is shown in listing 151
The parameters have the following meaning:
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="CurrencySwap">
<Model>DiscountedCashflows</Model>
<ModelParameters/>
<Engine>DiscountingCurrencySwapEngine</Engine>
<EngineParameters>
<Parameter name="SensitivityTemplate">IR_Analytical</Parameter>
</EngineParameters>
</Product>

Listing 151: Configuration for Product Swap, Model DiscountedCashflows, Engine Discount-
ingCurrencySwapEngine
CrossAssetModel/AMC builds a McCamCurrencySwapEngine for use in AMC
simulations. We refer to the AMC module documentation for further details.

192
7.3.78 Product Type: RiskParticipationAgreement_Vanilla
Used by trade type: RiskParticipationAgreement with
• exactly one fixed and one floating leg with opposite payer flags and
• only fixed, ibor, ois (comp, avg) coupons allowed, no cap / floors, no in arrears
fixings for ibor
Available Model/Engine pairs: Black/Analytic
Engine description:
Black/Analytic builds a AnalyticBlackRiskParticipationAgreementEngine. A sample
configuration is shown in listing 152
The parameters have the following meaning:
• Reversion: the mean reversion parameter to use for underlying matching in a
HW1F model
• MatchUnderlyingTenor: whether to match the trade underlying tenor in scenario
/ sensi calculations
• AlwaysRecomputeOptionRepresentation: whether to recompute underlying
representation on each scenario or keep the initial representation across all
scenarios
• MaxGapDays: the maximum gap between option expiry dates used for the
underlying representation
• MaxDiscretizationPoints: the maximum number of discretization points used for
underlying representation
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="RiskParticipationAgreement_Vanilla">
<Model>Black</Model>
<ModelParameters>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="MatchUnderlyingTenor">true</Parameter>
</ModelParameters>
<Engine>Analytic</Engine>
<EngineParameters>
<Parameter name="AlwaysRecomputeOptionRepresentation">false</Parameter>
<Parameter name="MaxGapDays">400</Parameter>
<Parameter name="MaxDiscretisationPoints">20</Parameter>
<Parameter name="SensitivityTemplate">IR_Semianalytical</Parameter>
</EngineParameters>
</Product>

Listing 152: Configuration for Product RiskParticipationAgreement_Vanilla, Model Black, En-

gine Analytic

7.3.79 Product Type: RiskParticipationAgreement_Vanilla_XCcy

Used by trade type: RiskParticipationAgreement with

193
 • two legs in different currencies with arbitrary coupons allowed, no optionData
though (as in structured variant)
Available Model/Engine pairs: Black/Analytic
Engine description:
Black/Analytic builds a AnalyticXCcyBlackRiskParticipationAgreementEngine. A
sample configuration is shown in listing 153
The parameters have the following meaning:
• AlwaysRecomputeOptionRepresentation: whether to recompute underlying
representation on each scenario or keep the initial representation across all
scenarios
• MaxGapDays: the maximum gap between option expiry dates used for the
underlying representation
• MaxDiscretizationPoints: the maximum number of discretization points used for
underlying representation
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="RiskParticipationAgreement_Vanilla_XCcy">
<Model>Black</Model>
<ModelParameters/>
<Engine>Analytic</Engine>
<EngineParameters>
<Parameter name="AlwaysRecomputeOptionRepresentation">false</Parameter>
<Parameter name="MaxGapDays">400</Parameter>
<Parameter name="MaxDiscretisationPoints">20</Parameter>
<Parameter name="SensitivityTemplate">FX_Semianalytical</Parameter>
</EngineParameters>
</Product>

Listing 153: Configuration for Product RiskParticipationAgreement_Vanilla_XCcy, Model

Black, Engine Analytic

7.3.80 Product Type: RiskParticipationAgreement_Structured

Used by trade type: RiskParticipationAgreement with
• arbitrary number of fixed, floating, cashflow legs
• only fixed, ibor coupons, ois (comp, avg), simple cashflows allowed, but possibly
capped / floored, as naked option, with in arrears fixing for ibor
• with optionData (i.e. callable underlying), as naked option (i.e. swaption)
Available Model/Engine pairs: LGM/Grid
Engine description:
LGM/Grid builds a NumericLgmRiskParticipationAgreementEngine. A sample
configuration is shown in listing 154
The parameters have the following meaning:

194
 • Calibration: Bootstrap, BestFit, None
• CalibrationStrategy: CoterminalDealStrike, CoterminalATM
• ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept
• Reversion: The mean reversion
• ReversionType: Hagan, HullWhite
• Volatility: The volatility (start value for calibration if calibrated)
• VolatilityType: Hagan, HullWhite
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• sy, sx: Number of covered standard deviations (notation as in Hagan’s paper)
• ny, nx: Number of grid points for numerical integration (notation as in Hagan’s
paper)
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="RiskParticipationAgreement_Structured">
<Model>LGM</Model>
<ModelParameters>
<Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalDealStrike</Parameter>
<Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="VolatilityType">Hagan</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.02</Parameter>
</ModelParameters>
<Engine>Grid</Engine>
<EngineParameters>
<Parameter name="sy">5.0</Parameter>
<Parameter name="ny">30</Parameter>
<Parameter name="sx">5.0</Parameter>
<Parameter name="nx">30</Parameter>
<Parameter name="MaxGapDays">400</Parameter>
<Parameter name="MaxDiscretisationPoints">20</Parameter>
<Parameter name="SensitivityTemplate">IR_FD</Parameter>
</EngineParameters>
</Product>

Listing 154: Configuration for Product RiskParticipationAgreement_Structured, Model LGM,

Engine Grid

7.3.81 Product Type: RiskParticipationAgreement_TLock

Used by trade type: RiskParticipationAgreement with TLock underlying.
Available Model/Engine pairs: LGM/Grid

195
Engine description:
LGM/Grid builds a NumericLgmRiskParticipationAgreementEngine. A sample
configuration is shown in listing 155
The parameters have the following meaning:
• Calibration: Bootstrap, BestFit, None
• CalibrationStrategy: CoterminalDealStrike, CoterminalATM
• ReferenceCalibrationGrid: An optional grid, only one calibration instrument per
interval is kept
• Reversion: The mean reversion
• ReversionType: Hagan, HullWhite
• Volatility: The volatility (start value for calibration if calibrated)
• VolatilityType: Hagan, HullWhite
• ShiftHorizon: Shift horizon for LGM model as fraction of deal maturity
• Tolerance: Error tolerance for calibration
• sy, sx: Number of covered standard deviations (notation as in Hagan’s paper)
• ny, nx: Number of grid points for numerical integration (notation as in Hagan’s
paper)
• SensitivityTemplate [optional]: the sensitivity template to use
<Product type="RiskParticipationAgreement_TLock">
<Model>LGM</Model>
<ModelParameters>
<Parameter name="Calibration">Bootstrap</Parameter>
<Parameter name="CalibrationStrategy">CoterminalATM</Parameter>
<Parameter name="ReferenceCalibrationGrid">400,3M</Parameter>
<Parameter name="Reversion">0.0</Parameter>
<Parameter name="ReversionType">HullWhite</Parameter>
<Parameter name="Volatility">0.01</Parameter>
<Parameter name="VolatilityType">Hagan</Parameter>
<Parameter name="ShiftHorizon">0.5</Parameter>
<Parameter name="Tolerance">0.02</Parameter>
<Parameter name="CalibrationInstrumentSpacing">3M</Parameter>
</ModelParameters>
<Engine>Grid</Engine>
<EngineParameters>
<Parameter name="sy">5.0</Parameter>
<Parameter name="ny">30</Parameter>
<Parameter name="sx">5.0</Parameter>
<Parameter name="nx">30</Parameter>
<Parameter name="TimeStepsPerYear">24</Parameter>
<Parameter name="SensitivityTemplate">IR_FD</Parameter>
</EngineParameters>
</Product>

Listing 155: Configuration for Product RiskParticipationAgreement_TLock, Model LGM, En-

gine Grid

196
7.3.82 Product Type: ScriptedTrade
Used by trade type: ScriptedTrade (and trades wrapped as scripted trade)
Available Model/Engine pairs: ScriptedTrade/ScriptedTrade
Engine description:
ScriptedTrade/ScriptedTrade builds a ScriptedInstrumentPricingEngine (and
variants). We refer to the scripted trade module documentation for a sample
configuration and more details.

7.3.83 Global Parameters

In addition to product specific settings there is also a block with global parameters
with the following meaning:
• ContinueOnCalibrationError: If set to true an exceedence of a prescribed model
calibration tolerance (for e.g. the LGM model) will not cause the trade building
to fail, instead a warning is logged and the trade is processed anyway. Optional,
defaults to false.
• Calibrate: If false, model calibration is disabled. This flag is usually not present
in a user configuration, but only used internally for certain workflows within
ORE which do not require a model calibration. Optional, defaults to true.
• GenerateAdditionalResults: If false, the generation of additional results within
pricing engines will be suppressed (for those pricing engines which support this).
This flag is usually not present in a user configuration, but only used internally
to improve the performance for processes which only rely on the NPV as a result
from pricing engines, e.g. when repricing trades under sensitivity or stress
scenarios. Option, defaults to false.
• RunType: Set automatically. One of NPV, SensitivityDelta,
SensitivityDeltaGamma, Stress, Exposure, Capital, TradeDetails,
PortfolioAnalyser, HistoricalPnL, BondSpreadImply, AbsMaturityUpdate
depending on the context for which a portfolio was built. Might also be left
empty. This is used by some pricing engines to adapt to certain run types. E.g. a
first order sensitivity pnl expansion might be used for a SensitivityDelta run by
an engine which is able to compute analytical or AAD first order sensitivities.

197
7.4 Simulation: [Link]
This file determines the behaviour of the risk factor simulation (scenario generation)
module. It is structured in three blocks of data.

Listing 156: Simulation configuration

<Simulation>
<Parameters> ... </Parameters>
<CrossAssetModel> ... </CrossAssetModel>
<Market> ... </Market>
</Simulation>

Each of the three blocks is sketched in the following.

7.4.1 Parameters
Let us discuss this section using the following example

Listing 157: Simulation configuration

<Parameters>
<Grid>80,3M</Grid>
<Calendar>EUR,USD,GBP,CHF</Calendar>
<DayCounter>ACT/ACT</DayCounter>
<Sequence>SobolBrownianBridge</Sequence>
<Seed>42</Seed>
<Samples>1000</Samples>
<Ordering>Steps</Ordering>
<DirectionIntegers>JoeKuoD7</DirectionIntegers>
<!-- The following two nodes are optional -->
<CloseOutLag>2W</CloseOutLag>
<MporMode>StickyDate</MporMode>
</Parameters>

• Grid: Specifies the simulation time grid, here 80 quarterly steps.8

• Calendar: Calendar or combination of calendars used to adjust the dates of the
grid. Date adjustment is required because the simulation must step over ’good’
dates on which index fixings can be stored.
• DayCounter: Day count convention used to translate dates to times. Optional,
defaults to ActualActual ISDA.
• Sequence: Choose random sequence generator (MersenneTwister,
MersenneTwisterAntithetic, Sobol, Burley2020Sobol, SobolBrownianBridge,
Burley2020SobolBrownianBridge).
• Seed: Random number generator seed
8
For exposure calculation under DIM, the second parameter has to match the Margin Period of
Risk, i.e. if MarginPeriodOfRisk is set to for instance 2W in a netting set definition in [Link],
then one has to set Grid to for instance 80,2W.

198
 • Samples: Number of Monte Carlo paths to be produced use (Backward,
Forward, BestOfForwardBackward, InterpolatedForwardBackward), which number
of forward horizon days to use if one of the Forward related methods is chosen.
• Ordering: If the sequence type SobolBrownianBridge or
Burley2020SobolBrownianBridge is used, ordering of variates (Factors, Steps,
Diagonal)
• DirectionIntegers: If the sequence type SobolBrownianBridge,
Burley2020SobolBrownianBridge, Sobol or Burley2020Sobol is used, type of
direction integers in Sobol generator (Unit, Jaeckel, SobolLevitan,
SobolLevitanLemieux, JoeKuoD5, JoeKuoD6, JoeKuoD7, Kuo, Kuo2, Kuo3)
• CloseOutLag: If this tag is present, this specifies the close-out period length (e.g.
2W) used; otherwise no close-out grid is built. The close-out grid is an auxiliary
time grid that is offset from the main default date grid by the close-out period,
typically set to the applicable margin period of risk. If present, it is used to
evolve the portfolio value and determine close-out values associated with the
preceding default date valuation.
• MporMode: This tag is expected if the previous one is present, permissible values
are then StickyDate and ActualDate. StickyDate means that only market
data is evolved from the default date to close-out date for close-out date
valuation, the valuation as of date remains unchanged and trades do not “age”
over the period. As a consequence, exposure evolutions will not show spikes
caused by cash flows within the close-out period. ActualDate means that trades
will also age over the close-out period so that one can experience exposure
evolution spikes due to cash flows.

7.4.2 Model
The CrossAssetModel section determines the cross asset model’s number of currencies
covered, composition, and each component’s calibration. It is currently made of
• a sequence of LGM models for each currency (say nc currencies),
• nc − 1 FX models for each exchange rate to the base currency,
• ne equity models,
• ni inflation models,
• ncr credit models,
• ncom commodity models,
• a specification of the correlation structure between all components.

The simulated currencies are specified as follows, with clearly identifying the domestic
currency which is also the target currency for all FX models listed subsequently. If the
portfolio requires more currencies to be simulated, this will lead to an exception at run
time, so that it is the user’s responsibility to make sure that the list of currencies here
is sufficient. The list can be larger than actually required by the portfolio. This will
not lead to any exceptions, but add to the run time of ORE.

199
Listing 158: Simulation model currencies configuration

<CrossAssetModel>
<DomesticCcy>EUR</DomesticCcy>
<Currencies>
<Currency>EUR</Currency>
<Currency>USD</Currency>
<Currency>GBP</Currency>
<Currency>CHF</Currency>
<Currency>JPY</Currency>
</Currencies>
<Equities>
<!-- ... -->
</Equities>
<InflationIndices>
<!-- ... -->
</InflationIndices>
<CreditNames>
<!-- ... -->
</CreditNames>
<Commodities>
<!-- ... -->
</Commodities>
<BootstrapTolerance>0.0001</BootstrapTolerance>
<Measure>LGM</Measure><!-- Choices: LGM, BA -->
<Discretization>Exact</Discretization>
<!-- ... -->
</CrossAssetModel>

Bootstrap tolerance is a global parameter that applies to the calibration of all model
components. If the calibration error of any component exceeds this tolerance, this will
trigger an exception at runtime, early in the ORE process.
The Measure tag allows switching between the LGM and the Bank Account (BA)
measure for the risk-neutral market simulations using the Cross Asset Model. Note
that within LGM one can shift the horizon (see ParameterTransformation below) to
effectively switch to a T-Forward measure.
The Discretization tag chooses between time discretization schemes for the risk factor
evolution. Exact means exploiting the analytical tractability of the model to avoid any
time discretization error. Euler uses a naive time discretization scheme which has
numerical error and requires small time steps for accurate results (useful for testing
purposes or if more sophisticated component models are used.)

Each interest rate model is specified by a block as follows

200
Listing 159: Simulation model IR configuration

<CrossAssetModel>
<!-- ... -->
<InterestRateModels>
<LGM ccy="default">
<CalibrationType>Bootstrap</CalibrationType>
<Volatility>
<Calibrate>Y</Calibrate>
<VolatilityType>Hagan</VolatilityType>
<ParamType>Piecewise</ParamType>
<TimeGrid>1.0,2.0,3.0,4.0,5.0,7.0,10.0</TimeGrid>
<InitialValue>0.01,0.01,0.01,0.01,0.01,0.01,0.01,0.01<InitialValue>
</Volatility>
<Reversion>
<Calibrate>N</Calibrate>
<ReversionType>HullWhite</ReversionType>
<ParamType>Constant</ParamType>
<TimeGrid/>
<InitialValue>0.03</InitialValue>
</Reversion>
<CalibrationSwaptions>
<Expiries>1Y,2Y,4Y,6Y,8Y,10Y,12Y,14Y,16Y,18Y,19Y</Expiries>
<Terms>19Y,18Y,16Y,14Y,12Y,10Y,8Y,6Y,4Y,2Y,1Y</Terms>
<Strikes/>
</CalibrationSwaptions>
<ParameterTransformation>
<ShiftHorizon>0.0</ShiftHorizon>
<Scaling>1.0</Scaling>
</ParameterTransformation>
<FloatSpreadMapping>proRata</FloatSpreadMapping>
</LGM>
<LGM ccy="EUR">
<!-- ... -->
</LGM>
<LGM ccy="USD">
<!-- ... -->
</LGM>
</InterestRateModels>
<!-- ... -->
</CrossAssetModel>

We have LGM sections by currency, but starting with a section for currency ’default’.
As the name implies, this is used as default configuration for any currency in the
currency list for which we do not provide an explicit parametrisation. Within each
LGM section, the interpretation of elements is as follows:
• CalibrationType: Choose between Bootstrap and BestFit, where Bootstrap is
chosen when we expect to be able to achieve a perfect fit (as with calibration of
piecewise volatility to a series of co-terminal Swaptions)
• Volatility/Calibrate: Flag to enable/disable calibration of this particular
parameter
• Volatility/VolatilityType: Choose volatility parametrisation a la
HullWhite or Hagan

201
 • Volatility/ParamType: Choose between Constant and Piecewise
• Volatility/TimeGrid: Initial time grid for this parameter, can be left empty
if ParamType is Constant
• Volatility/InitialValue: Vector of initial values, matching number of
entries in time (for CalibrationType BestFit this should be one more entry than
the Volatility/TimeGrid entries, for Bootstrap this is ignored), or single value
if the time grid is empty
• Reversion/Calibrate: Flag to enable/disable calibration of this particular
parameter
• Reversion/VolatilityType: Choose reversion parametrisation a la
HullWhite or Hagan
• Reversion/ParamType: Choose between Constant and Piecewise
• Reversion/TimeGrid: Initial time grid for this parameter, can be left empty
if ParamType is Constant
• Reversion/InitialValue: Vector of initial values, matching number of
entries in time, or single value if the time grid is empty
• CalibrationSwaptions: Choice of calibration instruments by expiry,
underlying Swap term and strike. There have to be at least one more calibration
options configured than Volatility/TimeGrid entries were given.
• ParameterTransformation: LGM model prices are invariant under scaling
and shift transformations [21] with advantages for numerical convergence of
results in long term simulations. These transformations can be chosen here.
Default settings are shiftHorizon 0 (time in years) and scaling factor 1.
• FloatSpreadMapping: mapping of float spreads in analytic swaption pricing
for model calibration: proRata, nextCoupon, simple, optional, defaults to
proRata.
The reason for having to specify one more Volatility/InitialValue entries than
Volatility/TimeGrid entries (and at least one more calibration option than
Volatility/TimeGrid entries) is the fact that the intervals defined by the
Volatility/TimeGrid entries are spanning from [0, t1 ], [t1 , t2 ] . . . [tn , ∞], which results
in n + 1 intervals.

Each FX model is specified by a block as follows

202
Listing 160: Simulation model FX configuration

<CrossAssetModel>
<!-- ... -->
<ForeignExchangeModels>
<CrossCcyLGM foreignCcy="default">
<DomesticCcy>EUR</DomesticCcy>
<CalibrationType>Bootstrap</CalibrationType>
<Sigma>
<Calibrate>Y</Calibrate>
<ParamType>Piecewise</ParamType>
<TimeGrid>1.0,2.0,3.0,4.0,5.0,7.0,10.0</TimeGrid>
<InitialValue>0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1</InitialValue>
</Sigma>
<CalibrationOptions>
<Expiries>1Y,2Y,3Y,4Y,5Y,10Y</Expiries>
<Strikes/>
</CalibrationOptions>
</CrossCcyLGM>
<CrossCcyLGM foreignCcy="USD">
<!-- ... -->
</CrossCcyLGM>
<CrossCcyLGM foreignCcy="GBP">
<!-- ... -->
</CrossCcyLGM>
<!-- ... -->
</ForeignExchangeModels>
<!-- ... -->
<CrossAssetModel>

CrossCcyLGM sections are defined by foreign currency, but we also support a default
configuration as above for the IR model parametrisations. Within each CrossCcyLGM
section, the interpretation of elements is as follows:
• DomesticCcy: Domestic currency completing the FX pair
• CalibrationType: Choose between Bootstrap and BestFit as in the IR section
• Sigma/Calibrate: Flag to enable/disable calibration of this particular
parameter
• Sigma/ParamType: Choose between Constant and Piecewise
• Sigma/TimeGrid: Initial time grid for this parameter, can be left empty if
ParamType is Constant
• Sigma/InitialValue: Vector of initial values, matching number of entries in
time (for CalibrationType BestFit this should be one more entry than the
Sigma/TimeGrid entries, for Bootstrap this is ignored), or single value if the time
grid is empty
• CalibrationOptions: Choice of calibration instruments by expiry and strike,
strikes can be empty (implying the default, ATMF options), or explicitly
specified (in terms of FX rates as absolute strike values, in delta notation such as
±25D, AT M F for at the money). There have to be at least one more calibration
options configured than Sigma/TimeGrid entries were given

203
Each equity model is specified by a block as follows

Listing 161: Simulation model equity configuration

<CrossAssetModel>
<!-- ... -->
<EquityModels>
<CrossAssetLGM name="default">
<Currency>EUR</Currency>
<CalibrationType>Bootstrap</CalibrationType>
<Sigma>
<Calibrate>Y</Calibrate>
<ParamType>Piecewise</ParamType>
<TimeGrid>1.0,2.0,3.0,4.0,5.0,7.0,10.0</TimeGrid>
<InitialValue>0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1</InitialValue>
</Sigma>
<CalibrationOptions>
<Expiries>1Y,2Y,3Y,4Y,5Y,10Y</Expiries>
<Strikes/>
</CalibrationOptions>
</CrossAssetLGM>
<CrossAssetLGM name="SP5">
<!-- ... -->
</CrossAssetLGM>
<CrossAssetLGM name="Lufthansa">
<!-- ... -->
</CrossAssetLGM>
<!-- ... -->
</EquityModels>
<!-- ... -->
<CrossAssetModel>

CrossAssetLGM sections are defined by equity name, but we also support a default
configuration as above for the IR and FX model parameterisations. Within each
CrossAssetLGM section, the interpretation of elements is as follows:
• Currency: Currency of denomination
• CalibrationType: Choose between Bootstrap and BestFit as in the IR section
• Sigma/Calibrate: Flag to enable/disable calibration of this particular
parameter
• Sigma/ParamType: Choose between Constant and Piecewise
• Sigma/TimeGrid: Initial time grid for this parameter, can be left empty if
ParamType is Constant
• Sigma/InitialValue: Vector of initial values, matching number of entries in
time (for CalibrationType BestFit this should be one more entry than the
Sigma/TimeGrid entries, for Bootstrap this is ignored), or single value if the time
grid is empty
• CalibrationOptions: Choice of calibration instruments by expiry and strike,
strikes can be empty (implying the default, ATMF options), or explicitly specified

204
 (in terms of equity prices as absolute strike values). There have to be at least one
more calibration options configured than Sigma/TimeGrid entries were given

For the inflation model component, there is a choice between a Dodgson Kainth model
and a Jarrow Yildrim model. The Dodgson Kainth model is specified in a LGM or
DodgsonKainth node as outlined in Listing 162. The inflation model parameterisation
inherits from the LGM parameterisation for interest rate components, in particular the
CalibrationType, Volatility and Reversion elements. The CalibrationCapFloors
element specify the model’s calibration to a selection of either CPI caps or CPI floors
with specified strike.

Listing 162: Simulation model DK inflation component configuration

<CrossAssetModel>
...
<InflationIndexModels>
<LGM index="EUHICPXT">
<Currency>EUR</Currency>
<!-- As in the LGM parameterisation for any IR components -->
<CalibrationType> ... </CalibrationType>
<Volatility> ... </Volatility>
<Reversion> ... </Reversion>
<ParameterTransformation> ... </ParameterTransformation>
<!-- Inflation model specific -->
<CalibrationCapFloors>
<!-- not used yet, as there is only one strategy so far -->
<CalibrationStrategy> ... </CalibrationStrategy>
<CapFloor> Floor </CapFloor> <!-- Cap, Floor -->
<Expiries> 2Y, 4Y, 6Y, 8Y, 10Y </Expiries>
<!-- can be empty, this will yield calibration to ATM -->
<Strikes> 0.03, 0.03, 0.03, 0.03, 0.03 </Strikes>
</CalibrationCapFloors>
</LGM>
<LGM index="USCPI">
...
</LGM>
...
</InflationIndexModels>
...
<CrossAssetModel>

The calibration instruments may be specified in an alternative way via a

CalibrationBaskets node. In general, a CalibrationBaskets node can contain
multiple CalibrationBasket nodes each containing a list of calibration instruments of
the same type. For Dodgson Kainth, only a single calibration basket is allowed and the
instruments must be of type CpiCapFloor. So, for example, the
CalibrationCapFloors node in Listing 162 could be replaced with the
CalibrationBaskets node in 163.

205
Listing 163: Calibration basket for DK inflation model component

<CalibrationBaskets>
<CalibrationBasket>
<CpiCapFloor>
<Type>Floor</Type>
<Maturity>2Y</Maturity>
<Strike>0.03</Strike>
</CpiCapFloor>
<CpiCapFloor>
<Type>Floor</Type>
<Maturity>4Y</Maturity>
<Strike>0.03</Strike>
</CpiCapFloor>
<CpiCapFloor>
<Type>Floor</Type>
<Maturity>6Y</Maturity>
<Strike>0.03</Strike>
</CpiCapFloor>
<CpiCapFloor>
<Type>Floor</Type>
<Maturity>8Y</Maturity>
<Strike>0.03</Strike>
</CpiCapFloor>
<CpiCapFloor>
<Type>Floor</Type>
<Maturity>10Y</Maturity>
<Strike>0.03</Strike>
</CpiCapFloor>
</CalibrationBasket>
</CalibrationBaskets>

The Jarrow Yildrim model is specified in a JarrowYildirim node as outlined in

Listing 164. The RealRate node describes the JY real rate process and has
Volatility and Reversion nodes that follow those outlined in the interest rate LGM
section above. The Index node describes the JY index process and has a Volatility
component that follows the Sigma component of the FX model above. The
CalibrationBaskets node is as outlined above for Dodgson Kainth but up to two
baskets may be used and extra inflation instruments are supported in the calibration.
More information is provided below.
The CalibrationType determines the calibration approach, if any, that is used to
calibrate the various parameters of the model i.e. the real rate reversion, the real rate
volatility and the index volatility. If the CalibrationType is None, no calibration is
attempted and all parameter values must be explicitly specified. If the
CalibrationType is BestFit, the parameters that have Calibrate set to Y will be
calibrated to the instruments specified in the CalibrationBaskets node. If the
CalibrationType is Bootstrap, there are a number of options:
1. The index volatility parameter may be calibrated, indicated by setting
Calibrate to Y for that parameter, with both of the real rate parameters not
calibrated and set explicitly in the RealRate node. There should be exactly one
CalibrationBasket in the CalibrationBaskets node and its parameter
attribute may be set to Index or omitted.

206
 2. One of the real rate parameters may be calibrated, indicated by setting
Calibrate to Y for that parameter, with the index volatility not calibrated and
set explicitly in the Volatility node. There should be exactly one
CalibrationBasket in the CalibrationBaskets node and its parameter
attribute may be set to RealRate or omitted.
3. One of the real rate parameters and the index volatility parameter may be
calibrated together. There should be exactly two CalibrationBasket nodes in
the CalibrationBaskets node. The parameter attribute should be set to
RealRate on the CalibrationBasket node that should be used for the real rate
parameter calibration. Similarly, the parameter attribute should be set to Index
on the CalibrationBasket node that should be used for the index volatility
parameter calibration. The parameters are calibrated iteratively in turn until the
root mean squared error over all calibration instruments in the two baskets is
below the tolerance specified by the RmseTolerance in the
CalibrationConfiguration node or until the maximum number of iterations as
specified by the MaxIterations in the CalibrationConfiguration node has
been reached. The CalibrationConfiguration node is optional. If it is omitted,
the RmseTolerance defaults to 0.0001 and the MaxIterations defaults to 50.
Note that it is an error to attempt to calibrate both of the real rate parameters
together when CalibrationType is Bootstrap. If a parameter is being calibrated with
CalibrationType set to Bootstrap, the ParamType should be Piecewise. The
TimeGrid will be overridden for that parameter by the relevant calibration instrument
times and the parameter’s initial values are set to the first element of the
InitialValue list. So, leaving the TimeGrid node empty and giving a single value in
the InitialValue node is the clearest XML setup in this case.

207
Listing 164: Simulation model JY inflation component configuration

<JarrowYildirim index="EUHICPXT">
<Currency>EUR</Currency>
<CalibrationType>Bootstrap</CalibrationType>
<RealRate>
<Volatility>
<Calibrate>Y</Calibrate>
<VolatilityType>Hagan</VolatilityType>
<ParamType>Piecewise</ParamType>
<TimeGrid/>
<InitialValue>0.0001</InitialValue>
</Volatility>
<Reversion>
<Calibrate>N</Calibrate>
<ReversionType>HullWhite</ReversionType>
<ParamType>Constant</ParamType>
<TimeGrid/>
<InitialValue>0.5</InitialValue>
</Reversion>
<ParameterTransformation>
<ShiftHorizon>0.0</ShiftHorizon>
<Scaling>1.0</Scaling>
</ParameterTransformation>
</RealRate>
<Index>
<Volatility>
<Calibrate>Y</Calibrate>
<ParamType>Piecewise</ParamType>
<TimeGrid/>
<InitialValue>0.0001</InitialValue>
</Volatility>
</Index>
<CalibrationBaskets>
<CalibrationBasket parameter="Index">
<CpiCapFloor>
<Type>Floor</Type>
<Maturity>2Y</Maturity>
<Strike>0.0</Strike>
</CpiCapFloor>
...
</CalibrationBasket>
<CalibrationBasket parameter="RealRate">
<YoYSwap>
<Tenor>2Y</Tenor>
</YoYSwap>
...
</CalibrationBasket>
</CalibrationBaskets>
<CalibrationConfiguration>
<RmseTolerance>0.00000001</RmseTolerance>
<MaxIterations>40</MaxIterations>
</CalibrationConfiguration>
</JarrowYildirim>

The CpiCapFloor and YoYSwap calibration instruments can be seen in Listing 164. A
YoYCapFloor is also allowed and it has the structure shown in Listing 165. The Type

208
may be Cap or Floor. The Tenor should be a maturity period e.g. 5Y. The Strike
should be an absolute strike level for the year on year cap or floor e.g. 0.01 for 1%.

Listing 165: Layout for YoYCapFloor calibration instrument.

<YoYCapFloor>
<Type>...</Type>
<Tenor>...</Tenor>
<Strike>...</Strike>
</YoYCapFloor>

For commodity simulation we currently provide one model, as described in the

methodology appendix. Commodity model components are specified by commodity
name, by a block as follows

Listing 166: Simulation model commodity configuration

<CrossAssetModel>
<!-- ... -->
<CommodityModels>
<CommoditySchwartz name="default">
<Currency>EUR</Currency>
<CalibrationType>None</CalibrationType>
<Sigma>
<Calibrate>Y</Calibrate>
<InitialValue>0.1</InitialValue>
</Sigma>
<Kappa>
<Calibrate>Y</Calibrate>
<InitialValue>0.1</InitialValue>
</Kappa>
<CalibrationOptions>
...
</CalibrationOptions>
<DriftFreeState>false</DriftFreeState>
</CommoditySchwartz>
<CommoditySchwartz name="WTI">
<!-- ... -->
</CommoditySchwartz>
<CommoditySchwartz name="NG">
<!-- ... -->
</CommoditySchwartz>
<!-- ... -->
</CommodityModels>
<!-- ... -->
<CrossAssetModel>

CommoditySchwartz sections are defined by commodity name, but we also support a

default configuration as above for the IR and FX model parameterisations. Each
component is parameterised in terms of two constant, non time-dependent parameters
σ and κ so far (see appendix). Within each CommoditySchwartz section, the
interpretation of elements is as follows:
• Currency: Currency of denomination

209
 • CalibrationType: Choose between BestFit and None. The choice None will
deactivate calibration as usual. BestFit will attempt to set the model
parameter(s) such that the error in matching calibration instrument prices is
minimised. The option Bootstrap is not available here because the model
parameters are not time-dependent and the model’s degrees of freedom in general
do not suffice to perfectly match the calibration instrument prices.
• Sigma/Calibrate: Flag to enable/disable calibration of this particular
parameter
• Sigma/InitialValue: Initial value of the constant parameter
• Kappa/Calibrate: Flag to enable/disable calibration of this particular
parameter
• Kappa/InitialValue: Initial value of the constant parameter
• CalibrationOptions: Choice of calibration instruments by expiry and strike,
strikes can be empty (implying the default, ATMF options), or explicitly
specified (in terms of commodity prices as absolute strike values).
• DriftFreeState[Optional]: Boolean to switch between the two
implementations of the state variable, see appendix. By default this is set to
false.

Finally, the instantaneous correlation structure is specified as follows.

Listing 167: Simulation model correlation configuration

<CrossAssetModel>
<!-- ... -->
<InstantaneousCorrelations>
<Correlation factor1="IR:EUR" factor2="IR:USD">0.3</Correlation>
<Correlation factor1="IR:EUR" factor2="IR:GBP">0.3</Correlation>
<Correlation factor1="IR:USD" factor2="IR:GBP">0.3</Correlation>
<Correlation factor1="IR:EUR" factor2="FX:USDEUR">0</Correlation>
<Correlation factor1="IR:EUR" factor2="FX:GBPEUR">0</Correlation>
<Correlation factor1="IR:GBP" factor2="FX:USDEUR">0</Correlation>
<Correlation factor1="IR:GBP" factor2="FX:GBPEUR">0</Correlation>
<Correlation factor1="IR:USD" factor2="FX:USDEUR">0</Correlation>
<Correlation factor1="IR:USD" factor2="FX:GBPEUR">0</Correlation>
<Correlation factor1="FX:USDEUR" factor2="FX:GBPEUR">0</Correlation>
<!-- ... -->
</InstantaneousCorrelations>
</CrossAssetModel>

Any risk factor pair not specified explicitly here will be assumed to have zero
correlation. Note that the commodity components can have non-zero correlations
among each other, but correlations to all other CAM components must remain set to
zero for the time being.

7.4.3 Market
The last part of the simulation configuration file covers the specification of the
simulated market. Note that the simulation model will yield the evolution of risk

210
factors such as short rates which need to be translated into entire yield curves that can
be ’understood’ by the instruments which we want to price under scenarios.
Moreover we need to specify how volatility structures evolve even if we do not
explicitly simulate volatility. This translation happens based on the information in the
simulation market object, which is configured in the section within the enclosing tags
<Market> and </Market>, as shown in the following small example.
It should be noted that equity volatilities are taken to be a curve by default. To
simulate an equity volatility surface with smile the xml node <Surface> must be
supplied. There are two methods in ORE for equity volatility simulation:
• Simulating ATM volatilities only (and shifting other strikes relative to this using
the T0 smile). In this case set <SimulateATMOnly> to true and no surface node is
given.
• Simulating the full volatility surface. The node <SimulateATMOnly> should be
omitted or set to false, and explicit moneyness levels for simulation should be
provided.
Swaption volatilities are taken to be a surface by default. To simulate a swaption
volatility cube with smile the xml node <Cube> must be supplied. There are two
methods in ORE for swaption volatility cube simulation:
• Simulating ATM volatilities only (and shifting other strikes relative to this using
the T0 smile). In this case set <SimulateATMOnly> to true.
• Simulating the full volatility cube. The node <SimulateATMOnly> should be
omitted or set to false, and explicit strike spreads for simulation should be
provided.
FX volatilities are taken to be a curve by default. To simulate an FX volatility cube
with smile the xml node <Surface> must be supplied. The surface node contains the
moneyness levels to be simulated.
For Yield Curves, Swaption Volatilities, CapFloor Volatilities, Default Curves, Base
Correlations and Inflation Curves, a DayCounter may be specified for each risk factor
using the node <DayCounter name="EXAMPLE_CURVE">. If no day counter is specified
for a given risk factor then the default Actual365 is used. To specify a new default for
a risk factor type then use the daycounter node without any attribute, <DayCounter>.
For Yield Curves, there are several choices for the interpolation and extrapolation:
• Interpolation: This can be LogLinear or LinearZero. If not given, the value
defaults to LogLinear.
• Extrapolation: This can be FlatFwd or FlatZero. If not given, the value defaults
to FlatFwd.
For Default Curve, there is a similar choice for the extrapolation:
• Extrapolation: This can be FlatFwd or FlatZero. If not given, the value defaults
to FlatFwd.
For swap, yield, interest cap-floor, yoy inflation cap-floor, zc inflation cap-floor, cds, fx,
equity, commodity volatilities the smile dynamics can be specified as shown in listing

211
Listing 168: Smile Configuration Node

<SmileDynamics key="">StickyStrike</SmileDynamics>
<SmileDynamics key="EUR-ESTER">StickyMoneyness</SmileDynamics>

168 for swap vols. The empty key serves as a default configuration for all keys for
which no own smile dynamics node is present. The allowed smile dynamics values are
StickyStrike and StickyMoneyness. If not given, the smile dynamics defaults to
StickyStrike.
<Market>
<BaseCurrency>EUR</BaseCurrency>
<Currencies>
<Currency>EUR</Currency>
<Currency>USD</Currency>
</Currencies>
<YieldCurves>
<Configuration>
<Tenors>3M,6M,1Y,2Y,3Y,4Y,5Y,7Y,10Y,12Y,15Y,20Y</Tenors>
<Interpolation>LogLinear</Interpolation>
<Extrapolation>FlatFwd</Extrapolation>
<DayCounter>ACT/ACT</DayCounter> <!-- Sets a new default for all yieldCurves -->
</Configuration>
</YieldCurves>
<Indices>
<Index>EUR-EURIBOR-6M</Index>
<Index>EUR-EURIBOR-3M</Index>
<Index>EUR-EONIA</Index>
<Index>USD-LIBOR-3M</Index>
</Indices>
<SwapIndices>
<SwapIndex>
<Name>EUR-CMS-1Y</Name>
<ForwardingIndex>EUR-EURIBOR-6M</ForwardingIndex>
<DiscountingIndex>EUR-EONIA</DiscountingIndex>
</SwapIndex>
</SwapIndices>
<DefaultCurves>
<Names>
<Name>CPTY1</Name>
<Name>CPTY2</Name>
</Names>
<Tenors>6M,1Y,2Y</Tenors>
<SimulateSurvivalProbabilities>true</SimulateSurvivalProbabilities>
<DayCounter name="CPTY1">ACT/ACT</DayCounter>
<Extrapolation>FlatFwd</Extrapolation>
</DefaultCurves>
<SwaptionVolatilities>
<ReactionToTimeDecay>ForwardVariance</ReactionToTimeDecay>
<Currencies>
<Currency>EUR</Currency>
<Currency>USD</Currency>
</Currencies>
<Expiries>6M,1Y,2Y,3Y,5Y,10Y,12Y,15Y,20Y</Expiries>
<Terms>1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,30Y</Terms>
<SimulateATMOnly>false</SimulateATMOnly>

212
 <Cube>
<StrikeSpreads>-0.02,-0.01,0.0,0.01,0.02</StrikeSpreads>
</Cube>
<!-- Sets a new daycounter for just the EUR swaptionVolatility surface -->
<DayCounter ccy="EUR">ACT/ACT</DayCounter>
</SwaptionVolatilities>
<CapFloorVolatilities>
<ReactionToTimeDecay>ConstantVariance</ReactionToTimeDecay>
<Currencies>
<Currency>EUR</Currency>
<Currency>USD</Currency>
</Currencies>
<DayCounter ccy="EUR">ACT/ACT</DayCounter>
</CapFloorVolatilities>
<FxVolatilities>
<ReactionToTimeDecay>ForwardVariance</ReactionToTimeDecay>
<CurrencyPairs>
<CurrencyPair>EURUSD</CurrencyPair>
</CurrencyPairs>
<Expiries>6M,1Y,2Y,3Y,4Y,5Y,7Y,10Y</Expiries>
<Surface>
<Moneyness>0.5,0.6,0.7,0.8,0.9</Moneyness>
</Surface>
</FxVolatilities>
<EquityVolatilities>
<Simulate>true</Simulate>
<ReactionToTimeDecay>ForwardVariance</ReactionToTimeDecay>
<!-- Alternative: ConstantVariance -->
<Names>
<Name>SP5</Name>
<Name>Lufthansa</Name>
</Names>
<Expiries>6M,1Y,2Y,3Y,4Y,5Y,7Y,10Y</Expiries>
<SimulateATMOnly>false</SimulateATMOnly>
<Surface>
<Moneyness>0.1,0.5,1.0,1.5,2.0,3.0</Moneyness>
</Surface>
<TimeExtrapolation>Flat</TimeExtrapolation>
<StrikeExtrapolation>Flat</StrikeExtrapolation>

</EquityVolatilities>
...
<BenchmarkCurves>
<BenchmarkCurve>
<Currency>EUR</Currency>
<Name>BENCHMARK_EUR</Name>
</BenchmarkCurve>
...
</BenchmarkCurves>
<Securities>
<Simulate>true</Simulate>
<Names>
<Name>SECURITY_1</Name>
...
</Names>
</Securities>
<ZeroInflationIndexCurves>
<Names>

213
 <Name>EUHICP</Name>
<Name>UKRPI</Name>
<Name>USCPI</Name>
...
</Names>
<Tenors>6M,1Y,2Y,3Y,5Y,7Y,10Y,15Y,20Y</Tenors>
</ZeroInflationIndexCurves>
<YYInflationIndexCurves>
<Names>
<Name>EUHICPXT</Name>
...
</Names>
<Tenors>1Y,2Y,3Y,5Y,7Y,10Y,15Y,20Y</Tenors>
</YYInflationIndexCurves>
<DefaultCurves>
<Names>
<Name>ItraxxEuropeCrossoverS26V1</Name>
...
</Names>
<Tenors>1Y,2Y,3Y,5Y,10Y</Tenors>
<SimulateSurvivalProbabilities>true</SimulateSurvivalProbabilities>
</DefaultCurves>
<BaseCorrelations/>
<CDSVolatilities/>
<Correlations>
<Simulate>true</Simulate>
<Pairs>
<Pair>EUR-CMS-10Y,EUR-CMS-2Y</Pair>
</Pairs>
<Expiries>1Y,2Y</Expiries>
</Correlations>
<AggregationScenarioDataCurrencies>
<Currency>EUR</Currency>
<Currency>USD</Currency>
</AggregationScenarioDataCurrencies>
<AggregationScenarioDataIndices>
<Index>EUR-EURIBOR-3M</Index>
<Index>EUR-EONIA</Index>
<Index>USD-LIBOR-3M</Index>
</AggregationScenarioDataIndices>
</Market>

Listing 169: Simulation market configuration

7.5 Sensitivity Analysis: [Link]

ORE currently supports sensitivity analysis with respect to
• Discount curves (in the zero rate domain)
• Index curves (in the zero rate domain)
• Yield curves including e.g. equity forecast yield curves (in the zero rate domain)
• FX Spots
• FX volatilities
• Swaption volatilities, ATM matrix or cube

214
 • Cap/Floor volatility matrices (in the caplet/floorlet domain)
• Default probability curves (in the “zero rate” domain, expressing survival
probabilities S(t) in term of zero rates z(t) via S(t) = exp(−z(t) × t) with
Actual/365 day counter)
• Equity spot prices
• Equity volatilities, ATM or including strike dimension
• Zero inflation curves
• Year-on-Year inflation curves
• CDS volatilities
• Bond credit spreads
• Base correlation curves
• Correlation termstructures
The [Link] file specifies how sensitivities are computed for each market
component. The general structure is shown in listing 172, for a more comprehensive
case see Examples/Example_15. A subset of the following parameters is used in each
market component to specify the sensitivity analysis:
• ShiftType: Both absolute or relative shifts can be used to compute a sensitivity,
specified by the key words Absolute resp. Relative.
• ShiftSize: The size of the shift to apply.
• ShiftScheme: The finite difference scheme to use (Forward, Backward,
Central), if not given, this parameter defaults to Forward
• ShiftTenors: For curves, the tenor buckets to apply shifts to, given as a comma
separated list of periods.
• ShiftExpiries: For volatility surfaces, the option expiry buckets to apply shifts
to, given as a comma separated list of periods.
• ShiftStrikes: For cap/floor, FX option and equity option volatility surfaces,
the strikes to apply shifts to, given as a comma separated list of absolute strikes
• ShiftTerms: For swaption volatility surfaces, the underlying terms to apply
shifts to, given as a comma separated list of periods.
• Index: For cap / floor volatility surfaces, the index which together with the
currency defines the surface. list of absolute strikes
• CurveType: In the context of Yield Curves used to identify an equity “risk free”
rate forecasting curve; set to EquityForecast in this case
The ShiftType, ShiftSize, ShiftScheme nodes take an optional attribute key that allows
to configure different values for different sensitivity templates. The sensitivity
templates are defined in the pricing engine configuration. This is best explained by an
example: In Example 15 the product type BermudanSwaption has a sensitivity
template IR_FD attached, see 170. This can be used to specify different shifts for

215
trades that were built against this engine configuration, see 171: For Bermudan
swaptions a larger shift size of 10bp and a central difference scheme is used to compute
discount curve sensitivities in EUR. Since no separate shift type is specified, the
default shift type Absolute is used. Note regarding the reports:
• the sensi scenario report contains scenario NPVs related to the possibly product
specific configured shift sizes
• the sensi report contains renormalized sensitivities, i.e. sensitivities are always
expressed w.r.t. the default shift sizes
• the sensi config report only contains the default configuration
<Product type="BermudanSwaption">
<Model>LGM</Model>
<ModelParameters>
...
</ModelParameters>
<Engine>Grid</Engine>
<EngineParameters>
...
<Parameter name="SensitivityTemplate">IR_FD</Parameter>
</EngineParameters>
</Product>

Listing 170: Sensitivity template definition

<DiscountCurve ccy="EUR">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
<ShiftScheme>Forward</ShiftScheme>
<ShiftSize key="IR_FD">0.001</ShiftSize>
<ShiftScheme key="IR_FD">Central</ShiftScheme>
<ShiftTenors>6M,1Y,2Y,3Y,5Y,7Y,10Y,15Y,20Y</ShiftTenors>
</DiscountCurve>

Listing 171: Sensitivity template definition

The cross gamma filter section contains a list of pairs of sensitivity keys. For each
possible pair of sensitivity keys matching the given strings, a cross gamma sensitivity is
computed. The given pair of keys can be (and usually are) shorter than the actual
sensitivity keys. In this case only the prefix of the actual key is matched. For example,
the pair DiscountCurve/EUR,DiscountCurve/EUR matches all actual sensitivity pairs
belonging to a cross sensitivity by one pillar of the EUR discount curve and another
(different) pillar of the same curve. We list the possible keys by giving an example in
each category:
• DiscountCurve/EUR/5/7Y: 7y pillar of discounting curve in EUR, the pillar is at
position 5 in the list of all pillars (counting starts with zero)
• YieldCurve/BENCHMARK_EUR/0/6M: 6M pillar of yield curve
“BENCHMARK_EUR”, the index of the 6M pillar is zero (i.e. it is the first
pillar)
• IndexCurve/EUR-EURIBOR-6M/2/2Y: 2Y pillar of index forwarding curve for the
Ibor index “EUR-EURIBOR-6M”, the pillar index is 2 in this case
• OptionletVolatility/EUR/18/5Y/0.04: EUR caplet volatility surface, at 5Y
option expiry and 4% strike, the running index for this expiry - strike pair is 18;
the index counts the points in the surface in lexical order w.r.t. the dimensions

216
 option expiry, strike
• FXSpot/USDEUR/0/spot: FX spot USD vs EUR (with EUR as base ccy), the
index is always zero for FX spots, the pillar is labelled as “spot” always
• SwaptionVolatility/EUR/11/10Y/10Y/ATM: EUR Swaption volatility surface at
10Y option expiry and 10Y underlying term, ATM level, the running index for
this expiry, term, strike triple has running index 11; the index counts the points
in the surface in lexical order w.r.t. the dimensions option expiry, underlying
term and strike
Additional flags:
• ComputeGamma: If set to false, second order sensitivity computation is
suppressed
• UseSpreadedTermStructures: If set to true, spreaded termstructures over t0 will
be used for sensitivity calculation (where supported), to improve the alignment
of the scenario sim market and t0 curves
<SensitivityAnalysis>
<DiscountCurves>
<DiscountCurve ccy="EUR">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
<ShiftTenors>6M,1Y,2Y,3Y,5Y,7Y,10Y,15Y,20Y</ShiftTenors>
</DiscountCurve>
...
</DiscountCurves>
...
<IndexCurves>
<IndexCurve index="EUR-EURIBOR-6M">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
<ShiftTenors>6M,1Y,2Y,3Y,5Y,7Y,10Y,15Y,20Y</ShiftTenors>
</IndexCurve>
</IndexCurves>
...
<YieldCurves>
<YieldCurve name="BENCHMARK_EUR">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
<ShiftTenors>6M,1Y,2Y,3Y,5Y,7Y,10Y,15Y,20Y</ShiftTenors>
</YieldCurve>
</YieldCurves>
...
<FxSpots>
<FxSpot ccypair="USDEUR">
<ShiftType>Relative</ShiftType>
<ShiftSize>0.01</ShiftSize>
</FxSpot>
</FxSpots>
...
<FxVolatilities>
<FxVolatility ccypair="USDEUR">
<ShiftType>Relative</ShiftType>
<ShiftSize>0.01</ShiftSize>
<ShiftExpiries>1Y,2Y,3Y,5Y</ShiftExpiries>
<ShiftStrikes/>
</FxVolatility>
</FxVolatilities>
...
<SwaptionVolatilities>
<SwaptionVolatility ccy="EUR">
<ShiftType>Relative</ShiftType>
<ShiftSize>0.01</ShiftSize>
<ShiftExpiries>1Y,5Y,7Y,10Y</ShiftExpiries>
<ShiftStrikes/>

217
 <ShiftTerms>1Y,5Y,10Y</ShiftTerms>
</SwaptionVolatility>
</SwaptionVolatilities>
...
<CapFloorVolatilities>
<CapFloorVolatility ccy="EUR">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
<ShiftExpiries>1Y,2Y,3Y,5Y,7Y,10Y</ShiftExpiries>
<ShiftStrikes>0.01,0.02,0.03,0.04,0.05</ShiftStrikes>
<Index>EUR-EURIBOR-6M</Index>
</CapFloorVolatility>
</CapFloorVolatilities>
...
<SecuritySpreads>
<SecuritySpread security="SECURITY_1">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.0001</ShiftSize>
</SecuritySpread>
</SecuritySpreads>
...
<Correlations>
<Correlation index1="EUR-CMS-10Y" index2="EUR-CMS-2Y">
<ShiftType>Absolute</ShiftType>
<ShiftSize>0.01</ShiftSize>
<ShiftExpiries>1Y,2Y</ShiftExpiries>
<ShiftStrikes>0</ShiftStrikes>
</Correlation>
</Correlations>
...
<CrossGammaFilter>
<Pair>DiscountCurve/EUR,DiscountCurve/EUR</Pair>
<Pair>IndexCurve/EUR,IndexCurve/EUR</Pair>
<Pair>DiscountCurve/EUR,IndexCurve/EUR</Pair>
</CrossGammaFilter>
...
<ComputeGamma>true</ComputeGamma>
<UseSpreadedTermStructures>false</UseSpreadedTermStructures>
</SensitivityAnalysis>

Listing 172: Sensitivity configuration

Par Sensitivity Analysis

To perform a par sensitivity analysis, additional sensitivity configuration is required
that describes the assumed par instruments and related conventions. This additional
data is required for:
• DiscountCurves
• IndexCurves
• CapFloorVolatilities
• CreditCurves
• ZeroInflationIndexCurves
• YYInflationIndexCurves
• YYCapFloorVolatilities
Using DiscountCurves as an example, the full sensitivity specification including par
conversion data is as follows:
<DiscountCurve ccy="EUR">
<ShiftType>Absolute</ShiftType>

218
 <ShiftSize>0.0001</ShiftSize>
<ShiftTenors>2W,1M,3M,6M,9M,1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,25Y,30Y</ShiftTenors>
<ParConversion>
<!--DEP, FRA, IRS, OIS, FXF, XBS -->
<Instruments>OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS,OIS</Instruments>
<SingleCurve>true</SingleCurve>
<Conventions>
<Convention id="DEP">EUR-EURIBOR-CONVENTIONS</Convention>
<Convention id="IRS">EUR-6M-SWAP-CONVENTIONS</Convention>
<Convention id="OIS">EUR-OIS-CONVENTIONS</Convention>
</Conventions>
</ParConversion>
</DiscountCurve>

Listing 173: Par sensitivity configuration

Note
• The list of shift tenors needs to match the list of tenors matches the
corresponding grid in the simulation (market) configuration
• The length of list of (par) instruments needs to match the length of the list of
shift tenors
• Permissible codes for the assumed par instruments:
– DEP, FRA, IRS, OIS, TBS, FXF, XBS in the case of DiscountCurves
– DEP, FRA, IRS, OIS, TBS in the case of IndexCurves
– DEP, FRA, IRS, OIS, TBS, XBS in the case of YieldCurves
– ZIS, YYS for YYInflationIndexCurves, interpreted as Year-on-Year Inflation
Swaps linked to Zero Inflation resp. YoY Inflation curves
– ZIS, YYS for YYCapFloorVolatilities, interpreted as Year-on-Year Inflation
Cap Floor linked to Zero Inflation resp. YoY Inflation curves
– Any code for CreditCurves, interpreted as CDS
– Any code for ZeroInflationIndexCurves, interpreted as CPI Swaps linked to
Zero Inflation curves
– Any code for CapFloorVolatilities, interpreted as flat Cap/Floor
• One convention needs to be referenced for each of the instrument codes

7.6 Stress Scenario Analysis: [Link]

Stress tests can be applied in ORE to the same market segments and with same
granularity as described in the sensitivity section 7.5.

This file [Link] specifies how stress tests can be configured. The general
structure is shown in listing 174.
In this example, two zero stress scenarios “parallel_rates” and “twist” and one par rate
“par_parallel” are defined. Each scenario definition contains the market components to
be shifted in this scenario in a similar syntax that is also used for the sensitivity

219
configuration, see 7.5. Components that should not be shifted, can just be omitted in
the definition of the scenario. Shifts for rate curves, credit curves and interest rate
cap/floors can be given as par or zero rate shifts. By default shifts are zero rate shifts.
If shifts are marked as par rate shifts all components (rate/credit/caps) shifts are par
shifts in that category, for example it is not possible to have par rate first for one yield
curve and zero rate for another curve in the same scenario. In case of par stress
scenario, the shifted par instruments and related conventions are defined in a
sensitivity configuration. The number number stress shifts (tenors/expiries and strikes)
need to be allign with the tenors/expiries and strikes of par instruments 7.5.
However, instead of specifying one shift size per market component, here a whole
vector of shifts can be given, with different shift sizes applied to each point of the curve
(or surface / cube).
In case of the swaption volatility shifts, the single value given as Shift (without the
attributes expiry and term) represents a default value that is used whenever no
explicit value is given for a expiry / term pair.
UseSpreadedTermStructures: If set to true, spreaded termstructures over t0 will be
used for the scenario calculation, to improve the alignment of the scenario sim market
and t0 curves.
<StressTesting>
<UseSpreadedTermStructures>false</UseSpreadedTermStructures>
<StressTest id="parallel_rates">
<DiscountCurves>
<DiscountCurve ccy="EUR">
<ShiftType>Absolute</ShiftType>
<ShiftTenors>6M,1Y,2Y,3Y,5Y,7Y,10Y,15Y,20Y</ShiftTenors>
<Shifts>0.01,0.01,0.01,0.01,0.01,0.01,0.01,0.01,0.01</Shifts>
</DiscountCurve>
...
</DiscountCurves>
<IndexCurves>
...
</IndexCurves>
<YieldCurves>
...
</YieldCurves>
<FxSpots>
<FxSpot ccypair="USDEUR">
<ShiftType>Relative</ShiftType>
<ShiftSize>0.01</ShiftSize>
</FxSpot>
</FxSpots>
<FxVolatilities>
...
</FxVolatilities>
<SwaptionVolatilities>
<SwaptionVolatility ccy="EUR">
<ShiftType>Absolute</ShiftType>
<ShiftExpiries>1Y,10Y</ShiftExpiries>
<ShiftTerms>5Y</ShiftTerms>
<Shifts>
<Shift>0.0010</Shift>
<Shift expiry="1Y" term="5Y">0.0010</Shift>
<Shift expiry="1Y" term="5Y">0.0010</Shift>
<Shift expiry="1Y" term="5Y">0.0010</Shift>
<Shift expiry="10Y" term="5Y">0.0010</Shift>
<Shift expiry="10Y" term="5Y">0.0010</Shift>
<Shift expiry="10Y" term="5Y">0.0010</Shift>
</Shifts>
</SwaptionVolatility>
</SwaptionVolatilities>
<CapFloorVolatilities>

220
 <CapFloorVolatility ccy="EUR">
<ShiftType>Absolute</ShiftType>
<ShiftExpiries>6M,1Y,2Y,3Y,5Y,10Y</ShiftExpiries>
<Shifts>0.001,0.001,0.001,0.001,0.001,0.001</Shifts>
</CapFloorVolatility>
</CapFloorVolatilities>
</StressTest>
<StressTest id="twist">
...
</StressTest>
<StressTest id="par_parallel">
<ParShifts>
<IRCurves>true</IRCurves>
<SurvivalProbability>true</SurvivalProbability>
<CapFloorVolatilities>true</CapFloorVolatilities>
</ParShifts>
<DiscountCurves>
<DiscountCurve ccy="EUR">
<ShiftType>Absolute</ShiftType>
<ShiftTenors>6M,1Y,2Y,3Y,5Y,7Y,10Y,15Y,20Y</ShiftTenors>
<Shifts>0.01,0.01,0.01,0.01,0.01,0.01,0.01,0.01,0.01</Shifts>
</DiscountCurve>
...
</DiscountCurves>
<IndexCurves>
...
</IndexCurves>
<YieldCurves />
<FxSpots />
<FxVolatilities />
<SwaptionVolatilities />
<CapFloorVolatilities>
<CapFloorVolatility key="EUR-EURIBOR-6M">
<ShiftType>Absolute</ShiftType>
<ShiftExpiries>1Y, 2Y, 3Y, 4Y, 5Y, 6Y, 7Y, 8Y, 9Y</ShiftExpiries>
<Shifts>
<Shift tenor="1Y">0.01</Shift>
<Shift tenor="2Y">0.01</Shift>
<Shift tenor="3Y">0.01</Shift>
<Shift tenor="4Y">0.01</Shift>
<Shift tenor="5Y">0.01</Shift>
<Shift tenor="6Y">0.01</Shift>
<Shift tenor="7Y">0.01</Shift>
<Shift tenor="8Y">0.01</Shift>
<Shift tenor="9Y">0.01</Shift>
</Shifts>
</CapFloorVolatility>
</CapFloorVolatilities>
<EquitySpots />
<EquityVolatilities />
<SecuritySpreads />
<RecoveryRates />
<SurvivalProbabilities>
<SurvivalProbability name="Underlying1">
<ShiftType>Absolute</ShiftType>
<Shifts>0.01, 0.01, 0.01, 0.01, 0.01</Shifts>
<ShiftTenors>1Y, 2Y, 3Y, 5Y, 10Y</ShiftTenors>
</SurvivalProbability>
</SurvivalProbabilities>
</StressTest>
</StressTesting>

Listing 174: Stress configuration

7.7 Calendar Adjustment: [Link]

This file [Link] list out all additional holidays and business days
that are added to a specified calendar in ORE. These dates would originally be missing
from the calendar and has to be [Link] general structure is shown in listing 175.

221
In this example, two additional dates had been added to the calendar "Japan", one
additional holiday and one additional business day. If the user is not certain wether
the date is already included or not, adding it to the [Link] to be
safe won’t raise any errors. A sample [Link] file can be found in
the global example input directory. However, it is only used in Example_1.
<CalendarAdjustments>
<Calendar name="Japan">
<AdditionalHolidays>
<Date>2020-01-01</Date>
</AdditionalHolidays>
<AdditionalBusinessDays>
<Date>2020-01-02</Date>
</AdditionalBusinessDays>
</CalendarAdjustments>

Listing 175: Calendar Adjustment

If the parameter BaseCalendar is provided then a new calendar will be created using
the specified calendar as a base, and adding any AdditionalHolidays or
AdditionalBusinessDays. In the example below a new calendar CUSTOM_Japan is
being created, it will include any additional holidays or business days specified in the
original Japan calendar plus one additional date.
If a new calendar is added in this way and the schema is being used to validate XML
input, the corresponding calendar name must be prefixed with ‘CUSTOM_’.
<CalendarAdjustments>
<Calendar name="CUSTOM_Japan">
<BaseCalendar>Japan</BaseCalendar>
<AdditionalHolidays>
<Date>2020-04-06</Date>
</AdditionalHolidays>
</CalendarAdjustments>

Listing 176: Calendar Adjustment creating a new calendar

222
7.8 Curves: [Link]
The configuration of various term structures required to price a portfolio is covered in
a single configuration file which we will label [Link] in the following though
the file name can be chosen by the user. This configuration determines the
composition of
• Yield curves
• Default curves
• Inflation curves
• Equity forward price curves
• Swaption volatility structures
• Cap/Floor volatility structures
• FX Option volatility structures
• CDS volatility structures
• Inflation Cap/Floor price surfaces
• Equity volatility structures
• Security spreads and recovery rates
• Base correlation curves
• Correlation termstructures
This file also contains other market objects such as FXSpots, Security Spreads and
Security Rates which are necessary for the construction of a market.

7.8.1 Yield Curves

The top level XML elements for each YieldCurve node are shown in Listing 177.

Listing 177: Top level yield curve node

<YieldCurve>
<CurveId> </CurveId>
<CurveDescription> </CurveDescription>
<Currency> </Currency>
<DiscountCurve> </DiscountCurve>
<Segments> </Segments>
<InterpolationVariable> </InterpolationVariable>
<InterpolationMethod> </InterpolationMethod>
<MixedInterpolationCutoff> </MixedInterpolationCutoff>
<YieldCurveDayCounter> </YieldCurveDayCounter>
<Tolerance> </Tolerance>
<Extrapolation> </Extrapolation>
<BootstrapConfig>
...
</BootstrapConfig>
</YieldCurve>

223
The meaning of each of the top level elements in Listing 177 is given below. If an
element is labelled as ’Optional’, then it may be excluded or included and left blank.
• CurveId: Unique identifier for the yield curve.
• CurveDescription: A description of the yield curve. This field may be left blank.
• Currency: The yield curve currency.
• DiscountCurve: If the yield curve is being bootstrapped from market
instruments, this gives the CurveId of the yield curve used to discount cash flows
during the bootstrap procedure. If this field is left blank or set equal to the
current CurveId, then this yield curve itself is used to discount cash flows during
the bootstrap procedure.
• Segments: This element contains child elements and is described in the following
subsection.
• InterpolationVariable [Optional]: The variable on which the interpolation is
performed. The allowable values are given in Table 16. If the element is omitted
or left blank, then it defaults to Discount.
• InterpolationMethod [Optional]: The interpolation method to use. The allowable
values are given in Table 17. If the element is omitted or left blank, then it
defaults to LogLinear.
• MixedInterpolationCutoff [Optional]: If a mixed interpolation method is used,
the number of segments to which the first interpolation method is applied.
Defaults to 1.
• YieldCurveDayCounter [Optional]: The day count basis used internally by the
yield curve to calculate the time between dates. In particular, if the curve is
queried for a zero rate without specifying the day count basis, the zero rate that
is returned has this basis. If the element is omitted or left blank, then it defaults
to A365.
• Tolerance [Optional]: The tolerance used by the root finding procedure in the
bootstrapping algorithm. If the element is omitted or left blank, then it defaults
to 1.0 × 10−12 . It is preferable to use the Accuracy node in the
BootstrapConfig node below for specifying this value. However, if this node is
explicitly supplied, it takes precedence for backwards compatibility purposes.
• Extrapolation [Optional]: Set to True or False to enable or disable extrapolation
respectively. If the element is omitted or left blank, then it defaults to True.
• BootstrapConfig [Optional]: this node holds configuration details for the
iterative bootstrap that are described in section 7.8.19. If omitted, this node’s
default values described in section 7.8.19 are used.
Variable Description
Zero The continuously compounded zero rate
Discount The discount factor
Forward The instantaneous forward rate

Table 16: Allowable interpolation variables.

224
 Method Description
Linear Linear interpolation
LogLinear Linear interpolation on the natural log of the interpolation
variable
NaturalCubic Monotonic Kruger cubic interpolation with zero second
derivative at left and right
FinancialCubic Monotonic Kruger cubic interpolation with zero second
derivative at left and zero first derivative at right
ConvexMonotone Convex Monotone Interpolation (Hagan, West)
Quadratic Quadratic interpolation
LogQuadratic Quadratic interpolation on the natural log of the interpolation
variable
LogNaturalCubic Monotonic Kruger cubic interpolation with zero second
derivative at left and right
hline LogFinancialCubic Monotonic Kruger cubic interpolation with zero second
derivative at left and zero first derivative at right
hline LogCubicSpline Non-monotonic cubic spline interpolation with zero second
derivative at left and right
hline Hermite Hermite cubic spline interpolation
CubicSpline Non-monotonic cubic spline interpolation with zero second
derivative at left and right
DefaultLogMixedLinearCubic Mixed interpolation, first linear, then monotonic Kruger cubic
spline
MonotonicLogMixedLinearCubic Mixed interpolation, first linear, then monotonic natural cubic
spline
KrugerLogMixedLinearCubic Mixed interpolation, first linear, then non-monotonic Kruger
cubic spline
LogMixedLinearCubicNaturalSpline Mixed interpolation, first linear, then non-monotonic natural
cubic spline
ExponentialSplines Exponential Spline curve fitting, for Fitted Bond Curves only
NelsonSiegel Nelson-Siegel curve fitting, for Fitted Bond Curves only
Svensson Svensson curve fitting, for Fitted Bond Curves only

Table 17: Allowable interpolation methods.

Segments Node
The Segments node gives the zero rates, discount factors and instruments that
comprise the yield curve. This node consists of a number of child nodes where the
node name depends on the segment being described. Each node has a Type that
determines its structure. The following sections describe the type of child nodes that
are available. Note that for all segment types below, with the exception of
DiscountRatio and AverageOIS, the Quote elements within the Quotes node may
have an optional attribute indicating whether or not the quote is optional. Example:

<Quotes>
<Quote optional="true"></Quote>
</Quotes>

225
Direct Segment
When the node name is Direct, the Type node has the value Zero or Discount and the
node has the structure shown in Listing 178. We refer to this segment here as a direct
segment because the discount factors, or equivalently the zero rates, are given explicitly
and do not need to be bootstrapped. The Quotes node contains a list of Quote
elements. Each Quote element contains an ID pointing to a line in the [Link] file,
i.e. in this case, pointing to a particular zero rate or discount factor. The Conventions
node contains the ID of a node in the [Link] file described in section 7.12.
The Conventions node associates conventions with the quotes.
For Discount type segments, the quotes can be given using a wildcard. Any valid and
matching quotes will then be loaded from the provided market data. An example
wildcard is:
• DISCOUNT/RATE/EUR/EUR3M/*

Listing 178: Direct yield curve segment

<Direct>
<Type> </Type>
<Quotes>
<Quote> </Quote>
<Quote> </Quote>
<!--...-->
</Quotes>
<Conventions> </Conventions>
</Direct>

Simple Segment
When the node name is Simple, the Type node has the value Deposit, FRA, Future,
OIS, Swap or BMA Basis Swap and the node has the structure shown in Listing 179.
This segment holds quotes for a set of deposit, FRA, Future, OIS or swap instruments
corresponding to the value in the Type node. These quotes will be used by the
bootstrap algorithm to imply a discount factor, or equivalently a zero rate, curve. The
only difference between this segment and the direct segment is that there is a
ProjectionCurve node. This node allows us to specify the CurveId of another curve
to project floating rates on the instruments underlying the quotes listed in the Quote
nodes during the bootstrap procedure. This is an optional node. If it is left blank or
omitted, then the projection curve is assumed to equal the curve being bootstrapped
i.e. the current CurveId. The PillarChoice node determines the bootstrap pillars
that are used (MaturityDate, LastRelevantDate, if not given ’LastRelevantDate’ is the
default value).
The Priority node determines the priority of the segment, this has to be a
non-negative integer. A lower number means a higher priority (more “important”)
segment. If two adjacent segments overlap w.r.t. the pillar dates of their instruments,
instruments from the segment with lower priority are removed until the overlap is
resolved. In addition, a minimum distance (measured in calendar days) between the
segments is preserved. This distance is given in the MinDistance node for the
instruments of the current and following segment. If not given, the priority of a

226
segment defaults to 0 (highest possible priority), the minimum distance defaults to 1.
Consider the example given in 180. In this case:
• instruments from the start of the second segment with pillar date strictly earlier
than d1 + 5, where d1 is the maximum pillar date of instruments in the first
segment, will be removed
• instruments from the end of the second segment with pillar date strictly later
than d3 − 10, where d3 is the mininum pillar date of instruments in the third
segment, will be removed

Listing 179: Simple yield curve segment

<Simple>
<Type> </Type>
<Quotes>
<Quote> </Quote>
<Quote> </Quote>
<!--...-->
</Quotes>
<Conventions> </Conventions>
<PillarChoice> </PillarChoice>
<Priority> </Priority>
<MinDistance> </MinDistance>
<ProjectionCurve> </ProjectionCurve>
</Simple>

Listing 180: Example for priorities and min distances

<Simple>
...
<Priority>0</Priority>
<MinDistance>5</MinDistance>
</Simple>
<Simple>
...
<Priority>2</Priority>
<MinDistance>10</MinDistance>
</Simple>
<Simple>
...
<Priority>1</Priority>
</Simple>

Average OIS Segment

When the node name is AverageOIS, the Type node has the value Average OIS and
the node has the structure shown in Listing 181. This segment is used to hold quotes
for Average OIS swap instruments. The Quotes node has the structure shown in
Listing 182. Each quote for an Average OIS instrument (a typical example in a USD
Overnight Index Swap) consists of two quotes, a vanilla IRS quote and an OIS-LIBOR
basis swap spread quote. The IDs of these two quotes are stored in the
CompositeQuote node. The RateQuote node holds the ID of the vanilla IRS quote and

227
the SpreadQuote node holds the ID of the OIS-LIBOR basis swap spread quote. The
PillarChoice node determines the bootstrap pillars that are used (MaturityDate,
LastRelevantDate, if not given ’LastRelevantDate’ is the default value).
For the Priority and MinDistance nodes see the explanation under “Simple Segment”.

Listing 181: Average OIS yield curve segment

<AverageOIS>
<Type> </Type>
<Quotes>
<CompositeQuote> </CompositeQuote>
<CompositeQuote> </CompositeQuote>
<!--...-->
</Quotes>
<Conventions> </Conventions>
<PillarChoice> </PillarChoice>
<Priority> </Priority>
<MinDistance> </MinDistance>
<ProjectionCurve> </ProjectionCurve>
</AverageOIS>

Listing 182: Average OIS segment’s quotes section

<Quotes>
<CompositeQuote>
<SpreadQuote> </SpreadQuote>
<RateQuote> </RateQuote>
</CompositeQuote>
<!--...-->
</Quotes>

Tenor Basis Segment

When the node name is TenorBasis, the Type node has the value Tenor Basis Swap
or Tenor Basis Two Swaps and the node has the structure shown in Listing 183. This
segment is used to hold quotes for tenor basis swap instruments. The quotes may be
for a conventional tenor basis swap where Ibor of one tenor is swapped for Ibor of
another tenor plus a spread. In this case, the Type node has the value Tenor Basis
Swap. The quotes may also be for the difference in fixed rates on two fair swaps where
one swap is against Ibor of one tenor and the other swap is against Ibor of another
tenor. In this case, the Type node has the value Tenor Basis Two Swaps. Again, the
structure is similar to the simple segment in Listing 179 except that there are two
projection curve nodes. There is a ProjectionCurveReceive node for the index with
the shorter tenor. This node holds the CurveId of a curve for projecting the floating
rates on the receiving side. Similarly, there is a ProjectionCurvePay node for the
index of the pay side. The deprecated values are short for receive, and long for pay.
These are optional nodes. If they are left blank or omitted, then the projection curve is
assumed to equal the curve being bootstrapped i.e. the current CurveId. However, at
least one of the nodes needs to be populated to allow the bootstrap to proceed. The
PillarChoice node determines the bootstrap pillars that are used (MaturityDate,
LastRelevantDate, if not given ’LastRelevantDate’ is the default value).

228
For the Priority and MinDistance nodes see the explanation under “Simple Segment”.

Listing 183: Tenor basis yield curve segment

<TenorBasis>
<Type> </Type>
<Quotes>
<Quote> </Quote>
<Quote> </Quote>
<!--...-->
</Quotes>
<Conventions> </Conventions>
<PillarChoice> </PillarChoice>
<Priority> </Priority>
<MinDistance> </MinDistance>
<ProjectionCurvePay> </ProjectionCurvePay>
<ProjectionCurveReceive> </ProjectionCurveReceive>
</TenorBasis>

Cross Currency Segment

When the node name is CrossCurrency, the Type node has the value FX Forward,
Cross Currency Basis Swap or Cross Currency Fix Float Swap. When the Type node
has the value FX Forward, the node has the structure shown in Listing 184. This
segment is used to hold quotes for FX forward instruments. The DiscountCurve node
holds the CurveId of a curve used to discount cash flows in the other currency i.e. the
currency in the currency pair that is not equal to the currency in Listing 177. The
SpotRate node holds the ID of a spot FX quote for the currency pair that is looked up
in the [Link] file. The PillarChoice node determines the bootstrap pillars that
are used (MaturityDate, LastRelevantDate, if not given ’LastRelevantDate’ is the
default value).

Listing 184: FX forward yield curve segment

<CrossCurrency>
<Type> </Type>
<Quotes>
<Quote> </Quote>
<Quote> </Quote>
...
</Quotes>
<Conventions> </Conventions>
<PillarChoice> </PillarChoice>
<Priority> </Priority>
<MinDistance> </MinDistance>
<DiscountCurve> </DiscountCurve>
<SpotRate> </SpotRate>
</CrossCurrency>

When the Type node has the value Cross Currency Basis Swap then the node has the
structure shown in Listing 185. This segment is used to hold quotes for cross currency
basis swap instruments. The DiscountCurve node holds the CurveId of a curve used

229
to discount cash flows in the other currency i.e. the currency in the currency pair that
is not equal to the currency in Listing 177. The SpotRate node holds the ID of a spot
FX quote for the currency pair that is looked up in the [Link] file. The
ProjectionCurveDomestic node holds the CurveId of a curve for projecting the
floating rates on the index in this currency i.e. the currency in the currency pair that is
equal to the currency in Listing 177. It is an optional node and if it is left blank or
omitted, then the projection curve is assumed to equal the curve being bootstrapped
i.e. the current CurveId. Similarly, the ProjectionCurveForeign node holds the
CurveId of a curve for projecting the floating rates on the index in the other currency.
If it is left blank or omitted, then it is assumed to equal the CurveId provided in the
DiscountCurve node in this segment.
For the Priority and MinDistance nodes see the explanation under “Simple Segment”.

Listing 185: Cross currency basis yield curve segment

<CrossCurrency>
<Type> </Type>
<Quotes>
<Quote> </Quote>
<Quote> </Quote>
...
</Quotes>
<Conventions> </Conventions>
<PillarChoice> </PillarChoice>
<Priority> </Priority>
<MinDistance> </MinDistance>
<DiscountCurve> </DiscountCurve>
<SpotRate> </SpotRate>
<ProjectionCurveDomestic> </ProjectionCurveDomestic>
<ProjectionCurveForeign> </ProjectionCurveForeign>
</CrossCurrency>

Zero Spread Segment

When the node name is ZeroSpread, the Type node has the only allowable value Zero
Spread, and the node has the structure shown in Listing 186. This segment is used to
build yield curves which are expressed as a spread over some reference yield curve.

Listing 186: Zero spread yield curve segment

<ZeroSpread>
<Type>Zero Spread</Type>
<Quotes>
<Quote>ZERO/YIELD_SPREAD/EUR/BANK_EUR_LEND/A365/2Y</Quote>
<Quote>ZERO/YIELD_SPREAD/EUR/BANK_EUR_LEND/A365/5Y</Quote>
<Quote>ZERO/YIELD_SPREAD/EUR/BANK_EUR_LEND/A365/10Y</Quote>
<Quote>ZERO/YIELD_SPREAD/EUR/BANK_EUR_LEND/A365/20Y</Quote>
</Quotes>
<Conventions>EUR-ZERO-CONVENTIONS-TENOR-BASED</Conventions>
<ReferenceCurve>EUR1D</ReferenceCurve>
</ZeroSpread>

230
Fitted Bond Segment
When the node name is FittedBond, the Type node has the only allowable value
FittedBond, and the node has the structure shown in Listing 187. This segment is used
to build yield curves which are fitted to liquid bond prices. The segment has the
following elements:
• Quotes: a list of bond price quotes, for each security in the list, reference data
must be available
• IborIndexCurves: for each Ibor index that is required by one of the bonds to
which the curve is fitted, a mapping to an estimation curve for that index must
be provided
• ExtrapolateFlat: if true, the parametric curve is extrapolated flat in the
instantaneous forward rate before the first and after the last maturity of the
bonds in the calibration basket. This avoids unrealistic rates at the short end or
for long maturities in the resulting curve.
The BootstrapConfig has the following interpretation for a fitted bond curve:
• Accuracy [Optional, defaults to 1E-12]: the desired accuracy expressed as a
weighted rmse in the implied quote, where 0.01 = 1 bp. Once this accuracy is
reached in a calibration trial, the fit is accepted, no further calibration trials re
run. In general, this parameter should be set to a higher than the default value
for fitted bond curves.
• GlobalAccuracy [Optional]: the acceptable accuracy. If the Accuracy is not
reached in any calibration trial, but the GlobalAccuracy is met, the best fit
among the calibration trials is selected as a result of the calibration. If not given,
the best calibration trial is compared to the Accuracy parameter instead.
• DontThrow [Optional, defaults to false]: If true, the best calibration is always
accepted as a result, i.e. no error is thrown even if the GlobalAccuracy is
breached.
• MaxAttempts [Optional, defaults to 5]: The maximum number of calibration
trials. Each calibration trial is run with a random calibration seed. Random
calibration seeds are currently only supported for the NelsonSiegel interpolation
method.

231
Listing 187: Fitted bond yield curve segment

<YieldCurve>
...
<Segments>
<FittedBond>
<Type>FittedBond</Type>
<Quotes>
<Quote>BOND/PRICE/SECURITY_1</Quote>
<Quote>BOND/PRICE/SECURITY_2</Quote>
<Quote>BOND/PRICE/SECURITY_3</Quote>
<Quote>BOND/PRICE/SECURITY_4</Quote>
<Quote>BOND/PRICE/SECURITY_5</Quote>
</Quotes>
<!-- mapping of Ibor curves used in the bonds from which the curve is built -->
<IborIndexCurves>
<IborIndexCurve iborIndex="EUR-EURIBOR-6M">EUR6M</IborIndexCurve>
</IborIndexCurves>
<!-- flat extrapolation before first and after last bond maturity -->
<ExtrapolateFlat>true</ExtrapolateFlat>
</FittedBond>
</Segments>
<!-- NelsonSiegel, Svensson, ExponentialSplines -->
<InterpolationMethod>NelsonSiegel</InterpolationMethod>
<YieldCurveDayCounter>A365</YieldCurveDayCounter>
<Extrapolation>true</Extrapolation>
<BootstrapConfig>
<!-- desired accuracy (in implied quote) -->
<Accuracy>0.1</Accuracy>
<!-- tolerable accuracy -->
<GlobalAccuracy>0.5</GlobalAccuracy>
<!-- do not throw even if tolerable accuracy is breached -->
<DontThrow>false</DontThrow>
<!-- max calibration trials to reach desired accuracy -->
<MaxAttempts>20</MaxAttempts>
</BootstrapConfig>
</YieldCurve>

Bond Yield Shifted

When the node name is BondYieldShifted, the Type node has the only allowable value
Bond Yield Shifted, and the node has the structure shown in Listing 188. This segment
is used to build yield curves which are adjusted by liquid bond yields. The adjustment
is derived as an average of the spreads between the bond’s yields-to-maturity and the
reference curve level at the tenor points corresponding the bond durations.
Compared to the fitted bond segment the shifted curve can be built with only one
liquid bond. This approach is useful in cases of limited number of liquid comparable
bonds and hence unstable fitting of Nelson Siegel. The average spread at the average
duration point may be considered as a sensitivity point of a corresponding zero coupon
bond.
The segment has the following elements:
• Quotes: a list of bond price quotes, for each security in the list, reference data
must be available

232
 • ReferenceCurve: the curve which will be used to calculate the bond spread. This
curve will also be shifted by the resulting spread
• IborIndexCurves: for each Ibor index that is required by one of the bonds to
which the curve is fitted, a mapping to an estimation curve for that index must
be provided
• ExtrapolateFlat: if true, the parametric curve is extrapolated flat in the
instantaneous forward rate before the first and after the last maturity of the
bonds in the calibration basket. This avoids unrealistic rates at the short end or
for long maturities in the resulting curve.

Listing 188: Bond Yield Shifted curve segment

<YieldCurve>
<CurveId>[Link].Curve_Shifted</CurveId>
<CurveDescription>Curve shifted with a bond's spreads at the bond duration tenors</CurveDesc
<Currency>USD</Currency>
<DiscountCurve/>
<Segments>
<BondYieldShifted>
<Type>Bond Yield Shifted</Type>
<ReferenceCurve>USD1D</ReferenceCurve>
<Quotes>
<Quote>BOND/PRICE/EJ7706660</Quote>
<Quote>BOND/PRICE/ZR5330686</Quote>
<Quote>BOND/PRICE/AS0644417</Quote>
</Quotes>
<Conventions>BOND_CONVENTIONS</Conventions>
<ExtrapolateFlat>true</ExtrapolateFlat>
<IborIndexCurves>
<IborIndexCurve iborIndex="USD-LIBOR-3M">USD3M</IborIndexCurve>
</IborIndexCurves>
</BondYieldShifted>
</Segments>
<InterpolationVariable>Discount</InterpolationVariable>
<InterpolationMethod>Linear</InterpolationMethod>
<YieldCurveDayCounter>A365</YieldCurveDayCounter>
<Tolerance> </Tolerance>
<Extrapolation>true</Extrapolation>
<BootstrapConfig> </BootstrapConfig>
</YieldCurve>

Yield plus Default Segment

When the node name is YieldPlusDefault, the Type node has the only allowable
value Yield Plus Default, and the node has the structure shown in Listing 189. This
segment is used to build all-in discounting yield curves from a benchmark curve and (a
weighted sum of) default curves. The construction is in some sense inverse to the
benchmark default curve construction, see 7.8.3.
• ReferenceCurve: the benchmark yield curve serving as the basis of the resulting
yield curve
• DefaultCurves: a list of default curves whose weighted sum is added to the

233
 benchmark yield curve
• Weights: a list of weights for the default curves, the number of weights must
match the number of default curves
Notice that it is explicitly allowed to use default curves in different currencies than the
benchmark yield curve. In the construction, the hazard rate is reinterpreted as an
instantaneous forward rate, and the sum of the curves is being built in the
instantaneous forward rate.
The definition takes into account the recovery rates associated to each default curve.
The resulting discount factor is computed as

Y
P (0, t) = Si (t)(1−R)wi (4)
i

where Si and Ri are the survival probabilities and recovery rates of the source default
curves, and wi are the weights.

Listing 189: Yield plus default curve segment

<YieldCurve>
<CurveId>BenchmarkPlusDefault</CurveId>
<CurveDescription>USD Libor 3M + 0.5 x [Link] + 0.5 x EUR.10BP</CurveDescription>
<Currency>USD</Currency>
<DiscountCurve/>
<Segments>
<YieldPlusDefault>
<Type>Yield Plus Default</Type>
<ReferenceCurve>USD3M</ReferenceCurve>
<DefaultCurves>
<DefaultCurve>Default/USD/[Link]</DefaultCurve>
<DefaultCurve>Default/EUR/EUR.10BP</DefaultCurve>
</DefaultCurves>
<Weights>
<Weight>0.5</Weight>
<Weight>0.5</Weight>
</Weights>
</YieldPlusDefault>
</Segments>
</YieldCurve>
</YieldCurves>

Weighted Average Segment

When the node name is WeightedAverage, the Type node has the only allowable value
Weighted Average, and the node has the structure shown in Listing 190. This segment
is used to build a curve with instantaneous forward rates that are the weighted sum of
instantaneous forward rates of reference curves. This way a projection curve for
non-standard Ibor curves can be build, e.g. to project a Euribor2M index using the
curves for 1M and 3M.
• ReferenceCurve1: the first source curve
• ReferenceCurve2: the second source curve

234
 • Weight1: the weight of the first curve
• Weights: the weight of the second curve
If P1 (0, t) and P2 (0, t) denote the discount factors of the two reference curves, the
discount factor P (0, t) of the resulting curve is defined as

P (0, t) = P1 (0, t)w1 P2 (0, t)w2 (5)

Listing 190: Weighted Average yield curve segment

<YieldCurve>
<CurveId>EUR2M</CurveId>
<CurveDescription>Euribor2M forwarding curve, interpolated from 1M and 3M</CurveDescription>
<Currency>EUR</Currency>
<DiscountCurve>EUR1D</DiscountCurve>
<Segments>
<WeightedAverage>
<Type>Weighted Average</Type>
<ReferenceCurve1>EUR1M</ReferenceCurve1>
<ReferenceCurve2>EUR3M</ReferenceCurve2>
<Weight1>0.5</Weight1>
<Weight2>0.5</Weight2>
</WeightedAverage>
</Segments>
</YieldCurve>

Ibor Fallback Segment

When the node name is IborFallback, the Type node has the only allowable value Ibor
Fallback, and the node has the structure shown in Listing 191. This segment is used to
build a projection curve for an Ibor index based on a risk free rate and a spread.

Listing 191: Ibor fallback segment

<YieldCurve>
<CurveId>USD-LIBOR-3M</CurveId>
<CurveDescription>USD-Libor-3M built from USD-SOFR plus spread</CurveDescription>
<Currency>USD</Currency>
<DiscountCurve/>
<Segments>
<IborFallback>
<Type>Ibor Fallback</Type>
<IborIndex>USD-LIBOR-3M</IborIndex>
<RfrCurve>Yield/USD/USD-SOFR</RfrCurve>
<!-- optional, if not given the rfr index and spread are read from the ibor
fallback configuration -->
<RfrIndex>USD-SOFR</RfrIndex>
<Spread>0.0026161</Spread>
</IborFallback>
</Segments>
</YieldCurve>

235
Discount Ratio Segment
When the node name is DiscountRatio, the Type node has the only allowable value
Dicount Ratio and the node has the structure shown in Listing 192. This segment is
used to build a curve with discount factors P (0, t) from three input curves with
discount factors Pb (0, t), Pn (0, t) and Pd (0, t) (“base”, “numerator”, “denominator”
curves) following the equation

Pn (0, t)
P (0, t) = Pb (0, t) (6)
Pd (0, t)

The main use case of this segment is to build a discount curve “CCY1-IN-CCY2” for
cashflows in CCY1 collateralized in CCY2 when curves “CCY1-IN-BASE” and
“CCY2-IN-BASE” are known for a common base currency BASE:
For a maturity t denote the zero rate on a curve “X” by rX (t) and the correpsonding
discount factor by PX (0, t). Furthermore, write “CCY” as shorthand for
“CCY-IN-CCY”, i.e. for the discount curve for cashflows in the same currency as the
collateral currency “CCY”. We write the desired zero rate as

rCCY1-IN-CCY2 = rCCY2 +(rBASE-IN-CCY2 − rCCY2 )+

(7)
(rCCY1-IN-CCY2 − rBASE-IN-CCY2 )

We now assume that these two rate differentials stay the same when we switch from
collateral currency “CCY2” to “BASE”, i.e.

rBASE-IN-CCY2 − rCCY2 ≈ rBASE − rCCY2-IN-BASE (8)

rCCY1-IN-CCY2 − rBASE-IN-CCY2 ≈ rCCY1-IN-BASE − rBASE (9)

In less technical terms we assume that FX Forward Quotes CCY2 / BASE and CCY1
/ BASE stay constant when the collateral currency changes, which seems reasonable, if
no further market information is available.
The discount factors associated to the RHS of 8 and 9 can be written

PBASE (0, t)/PCCY2-IN-BASE (0, t) (10)

PCCY1-IN-BASE (0, t)/PBASE (0, t) (11)

and so 6 can be written

PCCY2 (0, t)PCCY1-IN-BASE (0, t)

PCCY1-IN-CCY2 (0, t) = (12)
PCCY2-IN-BASE (0, t)

so the following choice of curves will result in the desired “CCY1-IN-CCY2” curve:
• base curve = “CCY2-IN-CCY2”

236
 • numerator curve = “CCY1-IN-BASE”
• denominator curve = “CCY2-IN-BASE”

Listing 192: Discount Ratio segment

<YieldCurve>
<CurveId>GBP-IN-EUR</CurveId>
<CurveDescription>GBP collateralized in EUR discount curve</CurveDescription>
<Currency>GBP</Currency>
<DiscountCurve/>
<Segments>
<DiscountRatio>
<Type>Discount Ratio</Type>
<BaseCurve currency="EUR">EUR1D</BaseCurve>
<NumeratorCurve currency="GBP">GBP-IN-USD</NumeratorCurve>
<DenominatorCurve currency="EUR">EUR-IN-USD</DenominatorCurve>
</DiscountRatio>
</Segments>
</YieldCurve>

7.8.2 Default Curves from CDS

Default curves can be bootstrapped from credit default swap (CDS) market
instruments. The CDS market quotes may be given as a par spread or as an upfront
price. These market quotes are documented in Sections 10.12 and 10.13 respectively.
The bootstrap also requires a market recovery rate quote and this is documented in
Section 10.14.
Listing 193 outlines the configuration required to build a default curve from CDS
quotes. The meaning of each of the nodes is as follows:
• CurveId: Unique identifier for the bootstrapped default curve. For index term
curves a suffix _5Y should be appended to the name indicating the index term,
since this is the prefered name looked up by index cds and index cds option
pricers. If such a curve is not found, the pricers will fall back to the specified
credit curve id without suffix, i.e. following this naming convention is not
mandatory, but recommended.
• CurveDescription [Optional]: A description of the default curve. It is for
information only and may be left blank.
• Currency: The default curve’s currency.
• Type: For a default curve built from CDS, the Type should be set to SpreadCDS
if the Quotes reference CDS spread quotes or Price if the Quotes reference
upfront price quotes.
• DiscountCurve: A reference to a valid discount curve specification that will be
used to discount cashflows during the bootstrap process. It should be of the form
Yield/Currency/curve_name where curve_name is the name of a yield curve
defined in the yield curve configurations.
• DayCounter: The day counter used to convert from dates to times in the
underlying structure. Allowable values are given in the Table 35.

237
• RecoveryRate: A valid recovery rate quote name as documented in Section 10.14.
• StartDate [Optional]: The StartDate is optional and is used for index CDS to
specify the start date of the index CDS. This is then used to determine the
maturity associated with the index CDS spread quotes which are quoted with a
tenor. For single name CDS, this should be omitted.
• RunningSpread [Optional]: The RunningSpread is optional and is used for
– stripping cds curves from upfront quotes. Alternatively the upfront quote
labels can contain the running spread.
– the calculation of the ATM level in cds and index cds volatility surfaces that
are strike dependent
The value should be set whenever one of these use cases applies.
• IndexTerm [Optional]: The IndexTerm is optional and is used to set up index cds
curves for a specific term. If several quotes are specified explicitly or via
wildcards, the quote matching the specified term is used to build a flat curve. If
no quote is available for the specified term, an interpolated term quote will be
built using the adjacent terms of the provided quotes.
• Quotes: The Quotes element should be populated with a list of valid Quote
elements. If the Type is SpreadCDS, the quotes should be CDS spread quote
strings as documented in Section 10.12 and if Type is Price, the quotes should
be CDS upfront price quote strings as documented in Section 10.13. The
attribute optional in the Quote element should be set to true if the associated
quote is optional and set to false if the associated quote is mandatory. If a
quote is mandatory and not found in the market, the default curve building will
fail. The attribute optional may be omitted from the quote element. In this
case, it defaults to false and the quote is mandatory. Note also that instead of a
list of explicit quotes, a single quote may be provided with the wildcard character
*. In this case, the market is searched for quotes matching the pattern. For
example, CDS/CREDIT_SPREAD/JPM/SNRFOR/USD/XR14/* would return all quotes
in the market that start with CDS/CREDIT_SPREAD/JPM/SNRFOR/USD/XR14.
• Conventions: The name of a valid set of CDS conventions, as documented in
Section 7.12.21, to use in the bootstrap.
• Extrapolation [Optional]: A boolean value indicating if the bootstrapped
default curve allows for extrapolation past the last pillar date. Allowable boolean
values are given in the Table 46. If omitted, it defaults to true.
• ImplyDefaultFromMarket [Optional]: A boolean value indicating if a reference
entity’s default should be implied from the market data. Allowable boolean
values are given in the Table 46. If omitted, it defaults to false. When a default
credit event has been determined for an entity, certain market data providers
continue to supply a recovery rate from the credit event determination date up to
the credit event auction settlement date. In this period, no CDS spreads or
upfront prices are provided. When this flag is true, we assume an entity is in
default and awaiting a credit event auction if we find a recovery rate in the
market but no CDS spreads or upfront prices. In this case, we build a survival

238
 probability curve with a value of close to but greater than 0.0 for one day after
the valuation date. This will give an approximation to the correct price for CDS
and index CDS in these cases. When this flag is false, we make no such
assumption and the default curve building will fail.
• BootstrapConfig [Optional]: This node holds configuration details for the
iterative bootstrap that are described in section 7.8.19. If omitted, this node’s
default values described in section 7.8.19 are used.
• AllowNegativeRates [Optional]: If set to false (default) negative instantaneous
hazard rates implied by the CDS quotes lead to an exception or - if the
DontThrow flag in the BootstrapConfig is set to true - to a zero instantaneous
hazard rate in the relevant segment of the curve. In the latter case the market
CDS instrument associated to the critical curve segment will not match the
market quote exactly. If set to true, negative instantaneous hazard rates will be
allowed during the bootstrap (in a range that is technically defined by the
MaxFactor and MaxAttempts parameters for the survival probability in the
bootstrap config).
<DefaultCurve>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>
<Currency>USD</Currency>
<Type>...</Type>
<DiscountCurve>...</DiscountCurve>
<DayCounter>...</DayCounter>
<RecoveryRate>...</RecoveryRate>
<StartDate>...</StartDate>
<RunningSpread>...</RunningSpread>
<IndexTerm>...</IndexTerm>
<Quotes>
<Quote optional="true">...</Quote>
...
</Quotes>
<Conventions>...</Conventions>
<Extrapolation>...</Extrapolation>
<ImplyDefaultFromMarket>...</ImplyDefaultFromMarket>
<BootstrapConfig>
...
</BootstrapConfig>
<AllowNegativeRates>...</AllowNegativeRates>
</DefaultCurve>

Listing 193: Default curve configuration based on CDS quotes

7.8.3 Benchmark Default Curve

Default curves can be set up as a difference curve of two yield curves as shown in
listing 194. A typical use case is to back out a default curve from an all-in discounting
curve fitted to a series of liquid bond prices (the “source curve”) and a benchmark
curve representing a benchmark funding level. The default curve can then be used in
models consuming a benchmark curve and a default curve.
If PB (0, t) and PS (0, t) denote the discount factors of the given benchmark and source
curve respectively the resulting default term structures has survival probabilities

239
 S(t) = (PS (0, t)/PB (0, t))1/(1−R) (13)

on the given pillar times. Her, R is the specified recovery rate. If the recovery rate is
zero, which is the usual case, the formula simplifies to

S(0, t) = PS (0, t)/PB (0, t) (14)

The interpolation is backward flat in the hazard rate. The meaning of each node is as
follows:
• CurveId: The curve id.
• CurveDescription: The curve description.
• Currency: The currency of the curve.
• Type: Must be set to Benchmark.
• DayCounter: The day counter used to convert dates to times.
• RecoveryRate [optional]: The recovery rate for the resulting default curve.
Defaults to zero. The recovery rate can be a market quote as usual or also a fixed
numeric value for this curve type.
• BenchmarkCurve: The benchmark yield curve, typically this is the standard Ibor
curve in the currence (e.g. EUR-EURIBOR-6M, USD-Libor-3M, ...)
• SourceCurve: The all-in discounting curve.
• Pillars: The pillars on which to match the source curve
• SpotLag: The pillar dates are derived using the spot lag and the tenors as
specified in the Pillars node using the specified calendar.
• Calendar: The calendar used to derive the pillar dates.
• Extrapolation [Optional]: If set to true, the curve is extrapoalted beyond the last
pillar. Defaults to true.
• AllowNegativeRates [Optional]: If set to true, the check for non-negative
instantaneous hazard rate in the result curve is disabled, i.e. the relation
PS (0, t) ≤ PB (0, t) is not enforced. This flag should be enabled with care, i.e. a
model consuming the resulting default curve must be able to handle negative
hazard rates appropriately. On the other hand in some situations it is natural
that the source curve rates are below the benchmark rates. Defaults to false.
<DefaultCurve>
<CurveId>BOND_YIELD_EUR_OVER_OIS</CurveId>
<CurveDescription>Default curve derived as bond yield curve over Eonia</CurveDescription>
<Currency>EUR</Currency>
<Type>Benchmark</Type>
<DayCounter>A365</DayCounter>
<RecoveryRate>RECOVERY_RATE/RATE//SNR/USD</RecoveryRate>
<BenchmarkCurve>Yield/EUR/EUR6M</BenchmarkCurve>
<SourceCurve>Yield/EUR/BOND_YIELD_EUR</SourceCurve>
<Pillars>1Y,2Y,3Y,4Y,5Y,7Y,10Y</Pillars>

240
 <SpotLag>0</SpotLag>
<Calendar>TARGET</Calendar>
<Extrapolation>true</Extrapolation>
<AllowNegativeRates>false</AllowNegativeRates>
</DefaultCurve>
</DefaultCurves>

Listing 194: Benchmark default curve

7.8.4 Multi-Section Default Curve

Default curves can be build by stitching together instantaneous hazard rates from
multiple source curves for multiple date ranges as shown in listing 195.
The hazard rate of the resulting curve is taken from the ith input curve (i = 0, 1, 2, . . .)
for dates before the ith switch date and (if i > 0) on or after the i − 1th switch date.
The day counter of all input curves should be equal to the day counter of the result
curve. The interpolation is hardcoded as backward flat in the hazard rate.
If not given, the recovery rate R is assumed to be zero. The result default curve’s
survival probabiltiies are computed as

" 1
(1−Rn )  (1−Ri ) # 1−R
PS,n (t) PS,i (ti+1 )
S(t) = n−1
Πi=0 (15)
PS,n (tn ) PS,i (ti )

where PS,i is the survival probability of the ith source curve, Ri is the associated
recovery rate for the ith source curve, n is chosen such that PS,n is the relevant source
curve for time t according to the given switch dates and curve i is relevant for times in
[ti , ti+1 ].
The meaning of each node is as follows:
• CurveId: The curve id.
• CurveDescription: The curve description.
• Currency: The currency of the curve.
• Type: Must be set to MutliSection.
• SourceCurves: The list of input default curves.
• SwitchDates: The list of dates where we switch from one input curve to the next.
The number of switch dates must be one less than the number of source curves.
• DayCounter: The day counter used to convert dates to times.
• RecoveryRate [optional]: The recovery rate for the resulting default curve.
Defaults to zero. The recovery rate can be a market quote as usual or also a fixed
numeric value for this curve type.
• Extrapolation [Optional]: If set to true, the curve is extrapoalted beyond the last
pillar. Defaults to true.

241
<DefaultCurve>
<CurveId>MyMultiSectionDefaultCurve</CurveId>
<CurveDescription>Default curve with multiple sections</CurveDescription>
<Currency>USD</Currency>
<Type>MultiSection</Type>
<SourceCurves>
<SourceCurve>Default/USD/Generic_AA_Curve</SourceCurve>
<SourceCurve>Default/USD/Generic_B_Curve</SourceCurve>
<SourceCurve>Default/USD/Generic_C_Curve</SourceCurve>
</SourceCurves>
<SwitchDates>
<SwitchDate>2020-10-01</SwitchDate>
<SwitchDate>2021-12-01</SwitchDate>
<SwitchDates>
<Extrapolation>true</Extrapolation>
<DayCounter>A365</DayCounter>
<RecoveryRate>RECOVERY_RATE/RATE/NAME/SR/USD</RecoveryRate>
</DefaultCurve>

Listing 195: Multi-Section default curve

7.8.5 Swaption Volatility Structures

Listing 196 shows an example of a Swaption volatility structure configuration.
<SwaptionVolatilities>
<SwaptionVolatility>
<CurveId>EUR_SW_N</CurveId>
<CurveDescription>EUR normal swaption volatilities</CurveDescription>
<Dimension>ATM</Dimension>
<VolatilityType>Normal</VolatilityType>
<Interpolation>Hagan2002NormalZeroBeta</Interpolation>
<ParametricSmileConfiguration>
<Parameters>
<Parameter>
<Name>alpha</Name>
<InitialValue>0.0050</InitialValue>
<IsFixed>false</IsFixed>
</Parameter>
<Parameter>
<Name>beta</Name>
<InitialValue>0.0</InitialValue>
<IsFixed>true</IsFixed>
</Parameter>
<Parameter>
<Name>nu</Name>
<InitialValue>0.30</InitialValue>
<IsFixed>false</IsFixed>
</Parameter>
<Parameter>
<Name>rho</Name>
<InitialValue>0.0</InitialValue>
<IsFixed>false</IsFixed>
</Parameter>
</Parameters>

242
 <Calibration>
<MaxCalibrationAttempts>10</MaxCalibrationAttempts>
<ExitEarlyErrorThreshold>0.005</ExitEarlyErrorThreshold>
<MaxAcceptableError>0.05</MaxAcceptableError>
</Calibration>
</ParametricSmileConfiguration>
<Extrapolation>Flat</Extrapolation>
<OutputVolatilityType>Normal</OutputVolatilityType>
<DayCounter>Actual/365 (Fixed)</DayCounter>
<Calendar>TARGET</Calendar>
<BusinessDayConvention>Following</BusinessDayConvention>
<!-- ATM matrix specification -->
<OptionTenors>1M,3M,6M,1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,25Y,30Y</OptionTenors>
<SwapTenors>1Y,2Y,3Y,4Y,5Y,7Y,10Y,15Y,20Y,25Y,30Y</SwapTenors>
<ShortSwapIndexBase>EUR-CMS-1Y</ShortSwapIndexBase>
<SwapIndexBase>EUR-CMS-30Y</SwapIndexBase>
<!-- Smile section specification -->
<SmileOptionTenors>6M,1Y,10Y</SmileOptionTenors>
<SmileSwapTenors>2Y,5Y</SmileSwapTenors>
<SmileSpreads>-0.02,-0.01,0.01,0.02</SmileSpreads>
<QuoteTag/>
</SwaptionVolatility>
...
</SwaptionVolatilities>

Listing 196: Swaption volatility configuration

The meaning of each of the elements in Listing 196 is given below.
• CurveId: Unique identifier of the swaption volatility structure
• CurveDescription [Optional]: A description of the volatility structure, may be
left blank.
• Dimension: Distinguishes at-the-money matrices and full volatility cubes.
Allowable values: ATM, Smile
• VolatilityType: Specifies the type of market volatility inputs.
Allowable values: Normal, Lognormal, ShiftedLognormal
In the case of ShiftedLognormal, a matrix of shifts (by option and swap tenor)
has to be provided in the market data input.
• Interpolation: Optional. Possible values: Linear, Hagan2002Lognormal,
Hagan2002Normal, Hagan2002NormalZeroBeta,
Antonov2015FreeBoundaryNormal, KienitzLawsonSwaynePde, FlochKennedy. If
not given, defaults to Linear.
• ParametricSmileConfiguration: Optional. Applies to SABR only. If not given,
default values are used. Allows to specify initial values for calibrated parameters,
to exclude single parameters from calibration and to set calibration parameters.
See Example 60 for how to configure single value and termstructures of sabr
parameters for swaption and cap curve configs.
• Extrapolation: Specifies the extrapolation behaviour in all dimensions.
Allowable values: Linear, Flat, None
• OutputVolatilityType: Optional, defaults to input volatility type and applies to

243
 SABR variants only. For Interpolation = Linear it must be set to the input
VolatilityType or (better) omitted. Possible values: Normal, Lognormal (alias for
ShiftedLognormal, shift is always implied from input data), ShiftedLognormal.
• DayCounter: The term structure’s day counter used in date to time conversions
• Calendar: The term structure’s calendar used in option tenor to date conversions
• BusinessDayConvention: The term structure’s business day convention used in
option tenor to date conversion
• ATM Matrix specification, required for both Dimension choices:
– OptionTenors: Option expiry in period form
– SwapTenors: Underlying Swap term in period form
– ShortSwapIndexBase: Swap index (ORE naming convention, e.g.
EUR-CMS-1Y) used to compute ATM strikes for tenors up to and including
the tenor given in the index (1Y in this example)
– SwapIndexBase: Swap index used to compute ATM strikes for tenors longer
than the one defined by the short index
• Smile section specification, this part is required when Dimension is set to Smile,
otherwise it can be omitted:
– SmileOptionTenors: Option expiries, in period form, where smile section
data is to be taken into account
– SmileSwapTenors: Underlying Swap term, in period form, where smile
section data is to be taken into account
– SmileSpreads: Strikes in smile direction expressed as strike spreads, relative
to the ATM strike at the expiry/term point of the ATM matrix. Note that
trailing 0s are not ignored.
• QuoteTag [Optional]: If non-empty, a tag will be included in the market datum
labels. This can be used to set up underlying specific volatility date. For
example, if the quote tag is set to EUR-EURIBOR-3M, the market datum labels
will be SWAPTION/RATE_LNVOL/EUR/EUR-EURIBOR-3M/5Y/10Y/ATM instead of
SWAPTION/RATE_LNVOL/EUR/5Y/10Y/ATM. See section 10.20.

7.8.6 Cap Floor Volatility Structures

The cap volatility structure parameterisation allows the user to pick out term cap
volatilities or optionlet volatilities in the market data.
If term cap volatilities are given, users can define how they should be stripped to
create an optionlet volatility structure. The parameterisation allows for three separate
types of input term cap volatility structures:
1. A strip of at-the-money (ATM) cap volatilities.
2. A cap maturity tenor by absolute cap strike grid of cap volatilities.

244
 3. A combined structure containing both the ATM cap volatilities and the maturity
by strike grid of cap volatilities.
If optionlet volatilities are given, no bootstrapping will be performed on the input
market data. The curve or surface will be constructed using the interpolation method
defined by user. The parameterisation allows for three separate types of input
optionlet volatilities structures:
1. A strip of at-the-money (ATM) optionlet volatilities.
2. A optionlet maturity tenor by absolute optionlet strike grid of optionlet
volatilities.
3. A combined structure containing both the ATM optionlet volatilities and the
maturity by strike grid of optionlet volatilities.
The input volatilities may be normal, lognormal or shifted lognormal. The structure of
the market quotes is provided in Table 68.
Whether the input market data are term cap volatilities or optionlet volatilities
depends on the value of the InputType node. This node may be set to
TermVolatilities for term cap volatilites or OptionletVolatilities for optionlet
volatilities.
For term cap volatilities, the structure of the XML, i.e. the nodes that are necessary,
used and ignored, and the way that the optionlet volatilities are stripped hinges on the
value of the InterpolateOn node. This node may be set to TermVolatilities or
OptionletVolatilities. This node will be ignored if the inputs are optionlet
volatilities.
When set to TermVolatilities, a column of sequential caps or floors, are created for
each strike level out to the maximum cap maturity configured. In other words, if the
index tenor is 6M, the first cap created would have a maturity of 1Y, the second cap
18M, the third cap 2Y and so on until we have a cap with maturity equal to the
maximum maturity tenor in the configuration. The volatility for each of these caps or
floors is then interpolated from the term cap volatility surface using the configured
interpolation. Finally, the optionlet volatility at each cap or floor maturity, starting
from the first, is derived in turn such that the column of cap or floor volatilities are
matched.
When set to OptionletVolatilities, the optionlet volatility structure pillar dates
are set to the fixing dates on the last caplet on each of the configured caps or floors i.e.
caps or floors with the maturities in the configured Tenors or AtmTenors. The
optionlet volatilities on these pillar dates are then solved for such that the configured
cap or floor volatilities are matched.
In the following sections, we describe six XML configurations separately for clarity:
1. Term volatility ATM curve with interpolation on term volatilities.
2. Term volatility ATM curve with interpolation on optionlet volatilities.
3. Term volatility surface, possibly including an ATM column, with interpolation on
term volatilities.

245
 4. Term volatility surface, possibly including an ATM column, with interpolation on
optionlet volatilities.
5. Optionlet volatility ATM curve.
6. Optionlet volatility surface.
Listing 197 shows the layout for parameterising an ATM cap volatility curve with
interpolation on term volatilities. Nodes that have no effect for this parameterisation
but that are allowed by the schema are not referenced. The meaning of each of the
nodes is as follows:
• CurveId: Unique identifier for the cap floor volatility structure.
• CurveDescription [Optional]: A description of the volatility structure. It is for
information only and may be left blank.
• VolatilityType: Indicates the cap floor volatility type. It may be Normal,
Lognormal or ShiftedLognormal. Note that this then determines which market
data points are looked up in the market when creating the ATM cap floor curve
and how they are interpreted when stripping the optionlets. In particular, the
market will be searched for market data points of the form
CAPFLOOR/RATE_NVOL/Currency/Tenor/IndexTenor/1/1/0,
CAPFLOOR/RATE_LNVOL/Currency/Tenor/IndexTenor/1/1/0 or
CAPFLOOR/RATE_SLNVOL/Currency/Tenor/IndexTenor/1/1/0 respectively.
• Extrapolation: Indicates the extrapolation in the time direction before the first
optionlet volatility and after the last optionlet volatility. The extrapolation
occurs on the stripped optionlet volatilities. The allowable values are None, Flat
and Linear. If set to None, extrapolation is turned off and an exception is
thrown if the optionlet surface is queried outside the allowable times. If set to
Flat, the first optionlet volatility is used before the first time and the last
optionlet volatility is used after the last time. If set to Linear, the interpolation
method configured in InterpolationMethod is used to extrapolate.
• InterpolationMethod [Optional]: Indicates the interpolation in the time
direction. As InterpolateOn is set to TermVolatilities here, the interpolation
is used in the stripping process to interpolate the term cap floor volatility curve
as explained above. It is also used to interpolate the optionlet volatilities when
an optionlet volatility is queried from the stripped optionlet structure. The
allowable values are Bilinear and BicubicSpline. If not set, BicubicSpline is
assumed. Obviously, as we are describing an ATM curve here, there is no
interpolation in the strike direction so when Bilinear is set the time
interpolation is linear and when BicubicSpline is set the time interpolation is
cubic spline.
• IncludeAtm: A boolean value indicating if an ATM curve should be used.
Allowable boolean values are given in the Table 46. As we are describing an
ATM curve here, this node should be set to true as shown in 197.
• DayCounter: The day counter used to convert from dates to times in the
underlying structure. Allowable values are given in the Table 35.
• Calendar: The calendar used to advance dates by periods in the underlying

246
 structure. In particular, it is used in deriving the cap maturity dates from the
configured cap tenors. Allowable values are given in the Table 34.
• BusinessDayConvention: The business day convention used to advance dates by
periods in the underlying structure. In particular, it is used in deriving the cap
maturity dates from the configured cap tenors. Allowable values are given in the
Table 30 under Roll Convention.
• Tenors [Optional]: A comma separated list of valid tenor strings giving the cap
floor maturity tenors to be used in the ATM curve. If omitted, the tenors for the
ATM curve must be provided in the AtmTenors node instead. If the tenors are
provided here, the AtmTenors node may be omitted.
• OptionalQuotes [Optional]: A boolean flag to indicate whether market data
quotes for all tenors are required. If true, we attempt to build the curve from
whatever quotes are provided. If false, the curve will fail to build if any quotes
are missing. This also applies to quotes for the AtmTenors. Default value is false.
• IborIndex: A valid interest rate index name giving the index underlying the cap
floor quotes. Allowable values are given in the Table 36.
• DiscountCurve: A reference to a valid discount curve specification that will be
used to discount cashflows during the stripping process. It should be of the form
Yield/Currency/curve_name where curve_name is the name of a yield curve
defined in the yield curve configurations.
• AtmTenors [Optional]: A comma separated list of valid tenor strings giving the
cap floor maturities to be used in the ATM curve. If omitted, the tenors for the
ATM curve must be provided in the Tenors node instead. If the tenors are
provided here, the Tenors node may be omitted.
• SettlementDays [Optional]: Any non-negative integer is allowed here. If omitted,
it is assumed to be 0. If provided the reference date of the term volatility curve
and the stripped optionlet volatility structure will be calculated by advancing the
valuation date by this number of days using the configured calendar and business
day convention. In general, this should be omitted or set to 0.
• InterpolateOn: As referenced above, the allowable values are
TermVolatilities or OptionletVolatilities. As we are describing here an
ATM curve with interpolation on term volatilities, this should be set to
TermVolatilities as shown in Listing 197.
• BootstrapConfig [Optional]: This node holds configuration details for the
iterative bootstrap that are described in section 7.8.19. If omitted, this node’s
default values described in section 7.8.19 are used.
• InputType [Optional]: The type of the marketdata input. Allowable values are
TermVolatilities or OptionletVolatilities. As we are describing term cap
volatilities input, this should be set to TermVolatilities or omitted as shown in
Listing 197. If omitted, the default value is TermVolatilities.
<CapFloorVolatility>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>

247
 <VolatilityType>...</VolatilityType>
<Extrapolation>...</Extrapolation>
<InterpolationMethod>...</InterpolationMethod>
<IncludeAtm>true</IncludeAtm>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<BusinessDayConvention>...</BusinessDayConvention>
<Tenors>...</Tenors>
<OptionalQuotes>...</OptionalQuotes>
<IborIndex>...</IborIndex>
<DiscountCurve>...</DiscountCurve>
<AtmTenors>...</AtmTenors>
<SettlementDays>...</SettlementDays>
<InterpolateOn>TermVolatilities</InterpolateOn>
<BootstrapConfig>...</BootstrapConfig>
<InputType>TermVolatilities</InputType>
</CapFloorVolatility>

Listing 197: ATM cap floor configuration with interpolation on term volatilities.
Listing 198 shows the layout for parameterising an ATM cap volatility curve with
interpolation on optionlet volatilities. Nodes that have no effect for this
parameterisation but that are allowed by the schema are not referenced. The meaning
of each of the nodes is as follows:
• CurveId: Unique identifier for the cap floor volatility structure.
• CurveDescription [Optional]: A description of the volatility structure. It is for
information only and may be left blank.
• VolatilityType: Indicates the cap floor volatility type. It may be Normal,
Lognormal or ShiftedLognormal. Note that this then determines which market
data points are looked up in the market when creating the ATM cap floor curve
and how they are interpreted when stripping the optionlets. In particular, the
market will be searched for market data points of the form
CAPFLOOR/RATE_NVOL/Currency/Tenor/IndexTenor/1/1/0,
CAPFLOOR/RATE_LNVOL/Currency/Tenor/IndexTenor/1/1/0 or
CAPFLOOR/RATE_SLNVOL/Currency/Tenor/IndexTenor/1/1/0 respectively.
• Extrapolation: The allowable values are None, Flat and Linear. If set to None,
extrapolation is turned off and an exception is thrown if the optionlet surface is
queried outside the allowable times. Otherwise, extrapolation is allowed and the
type of extrapolation is determined by the TimeInterpolation node value
described below.
• IncludeAtm: A boolean value indicating if an ATM curve should be used.
Allowable boolean values are given in the Table 46. As we are describing an
ATM curve here, this node should be set to true as shown in 198.
• DayCounter: The day counter used to convert from dates to times in the
underlying structure. Allowable values are given in the Table 35.
• Calendar: The calendar used to advance dates by periods in the underlying
structure. In particular, it is used in deriving the cap maturity dates from the
configured cap tenors. Allowable values are given in the Table 34.

248
• BusinessDayConvention: The business day convention used to advance dates by
periods in the underlying structure. In particular, it is used in deriving the cap
maturity dates from the configured cap tenors. Allowable values are given in the
Table 30 under Roll Convention.
• Tenors [Optional]: A comma separated list of valid tenor strings giving the cap
floor maturity tenors to be used in the ATM curve. If omitted, the tenors for the
ATM curve must be provided in the AtmTenors node instead. If the tenors are
provided here, the AtmTenors node may be omitted.
• OptionalQuotes [Optional]: A boolean flag to indicate whether market data
quotes for all tenors are required. If true, we attempt to build the curve from
whatever quotes are provided. If false, the curve will fail to build if any quotes
are missing. This also applies to quotes for the AtmTenors. Default value is false.
• IborIndex: A valid interest rate index name giving the index underlying the cap
floor quotes. Allowable values are given in the Table 36.
• DiscountCurve: A reference to a valid discount curve specification that will be
used to discount cashflows during the stripping process. It should be of the form
Yield/Currency/curve_name where curve_name is the name of a yield curve
defined in the yield curve configurations.
• AtmTenors [Optional]: A comma separated list of valid tenor strings giving the
cap floor maturities to be used in the ATM curve. If omitted, the tenors for the
ATM curve must be provided in the Tenors node instead. If the tenors are
provided here, the Tenors node may be omitted.
• SettlementDays [Optional]: Any non-negative integer is allowed here. If omitted,
it is assumed to be 0. If provided the reference date of the term volatility curve
and the stripped optionlet volatility structure will be calculated by advancing the
valuation date by this number of days using the configured calendar and business
day convention. In general, this should be omitted or set to 0.
• InterpolateOn: As referenced above, the allowable values are
TermVolatilities or OptionletVolatilities. As we are describing here an
ATM curve with interpolation on optionlet volatilities, this should be set to
OptionletVolatilities as shown in Listing 198.
• TimeInterpolation [Optional]: Indicates the interpolation and extrapolation, if
allowed by the Extrapolation node, in the time direction. As InterpolateOn is
set to OptionletVolatilities here, the interpolation is used to interpolate the
optionlet volatilities only i.e. there is no interpolation on the term cap floor
volatility curve. The allowable values are Linear, LinearFlat, BackwardFlat,
Cubic and CubicFlat. If not set, LinearFlat is assumed. Note that Linear
indicates linear interpolation and linear extrapolation. LinearFlat indicates
linear interpolation and flat extrapolation. Analogous meanings apply for Cubic
and CubicFlat.
• BootstrapConfig [Optional]: This node holds configuration details for the
iterative bootstrap that are described in section 7.8.19. If omitted, this node’s
default values described in section 7.8.19 are used.

249
 • InputType [Optional]: The type of the marketdata input. Allowable values are
TermVolatilities or OptionletVolatilities. As we are describing term cap
volatilities input, this should be set to TermVolatilities or omitted as shown in
Listing 198. If omitted, the default value is TermVolatilities.
<CapFloorVolatility>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>
<VolatilityType>...</VolatilityType>
<Extrapolation>...</Extrapolation>
<IncludeAtm>true</IncludeAtm>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<BusinessDayConvention>...</BusinessDayConvention>
<Tenors>...</Tenors>
<OptionalQuotes>...</OptionalQuotes>
<IborIndex>...</IborIndex>
<DiscountCurve>...</DiscountCurve>
<AtmTenors>...</AtmTenors>
<SettlementDays>...</SettlementDays>
<InterpolateOn>OptionletVolatilities</InterpolateOn>
<TimeInterpolation>...</TimeInterpolation>
<BootstrapConfig>...</BootstrapConfig>
<InputType>TermVolatilities</InputType>
</CapFloorVolatility>

Listing 198: ATM cap floor configuration with interpolation on optionlet volatilities.
Listing 199 shows the layout for parameterising a cap tenor by absolute cap strike
volatility surface with interpolation on term volatilities. This parameterisation also
allows for the inclusion of a cap floor ATM curve in combination with the surface.
Nodes that have no effect for this parameterisation but that are allowed by the schema
are not referenced. The meaning of each of the nodes is as follows:
• CurveId: Unique identifier for the cap floor volatility structure.
• CurveDescription [Optional]: A description of the volatility structure. It is for
information only and may be left blank.
• VolatilityType: Indicates the cap floor volatility type. It may be Normal,
Lognormal or ShiftedLognormal. Note that this then determines which market
data points are looked up in the market when creating the cap floor surface and
how they are interpreted when stripping the optionlets. In particular, the market
will be searched for market data points of the form
CAPFLOOR/RATE_NVOL/Currency/Tenor/IndexTenor/0/0/Strike,
CAPFLOOR/RATE_LNVOL/Currency/Tenor/IndexTenor/0/0/Strike or
CAPFLOOR/RATE_SLNVOL/Currency/Tenor/IndexTenor/0/0/Strike respectively.
• Extrapolation: Indicates the extrapolation in the time and strike direction.
The extrapolation occurs on the stripped optionlet volatilities. The allowable
values are None, Flat and Linear. If set to None, extrapolation is turned off and
an exception is thrown if the optionlet surface is queried outside the allowable
times or strikes. If set to Flat, the optionlet volatility on the time strike
boundary is used if the optionlet surface is queried outside the allowable times or
strikes. If set to Linear, the interpolation method configured in

250
 InterpolationMethod is used to extrapolate either time or strike direction.
• InterpolationMethod [Optional]: Indicates the interpolation in the time and
strike direction. As InterpolateOn is set to TermVolatilities here, the
interpolation is used in the stripping process to interpolate the term cap floor
volatility surface as explained above. It is also used to interpolate the optionlet
volatilities when an optionlet volatility is queried from the stripped optionlet
structure. The allowable values are Bilinear and BicubicSpline. If not set,
BicubicSpline is assumed.
• IncludeAtm: A boolean value indicating if an ATM curve should be used in
combination with the surface. Allowable boolean values are given in the Table
46. If set to true, the AtmTenors node needs to be populated with the ATM
tenors to use. The ATM quotes that are searched for are as outlined in the
previous two ATM sections above. The original stripped optionlet surface is
amended by inserting the optionlet volatilities at the successive ATM strikes that
reproduce the sequence of ATM cap volatilities.
• DayCounter: The day counter used to convert from dates to times in the
underlying structure. Allowable values are given in the Table 35.
• Calendar: The calendar used to advance dates by periods in the underlying
structure. In particular, it is used in deriving the cap maturity dates from the
configured cap tenors. Allowable values are given in the Table 34.
• BusinessDayConvention: The business day convention used to advance dates by
periods in the underlying structure. In particular, it is used in deriving the cap
maturity dates from the configured cap tenors. Allowable values are given in the
Table 30 under Roll Convention.
• Tenors: A comma separated list of valid tenor strings giving the cap floor
maturity tenors to be used in the tenor by strike surface. In this case, i.e.
configuring a surface, they must be provided.
• OptionalQuotes [Optional]: A boolean flag to indicate whether market data
quotes for all tenors are required. If true, we attempt to build the curve from
whatever quotes are provided. If false, the curve will fail to build if any quotes
are missing. This also applies to quotes for the AtmTenors. Default value is false.
• IborIndex: A valid interest rate index name giving the index underlying the cap
floor quotes. Allowable values are given in the Table 36.
• DiscountCurve: A reference to a valid discount curve specification that will be
used to discount cashflows during the stripping process. It should be of the form
Yield/Currency/curve_name where curve_name is the name of a yield curve
defined in the yield curve configurations.
• AtmTenors [Optional]: A comma separated list of valid tenor strings giving the
cap floor maturity tenors to be used in the ATM curve. It must be provided
when IncludeAtm is true and omitted when IncludeAtm is false.
• SettlementDays [Optional]: Any non-negative integer is allowed here. If omitted,
it is assumed to be 0. If provided the reference date of the term volatility curve
and the stripped optionlet volatility structure will be calculated by advancing the

251
 valuation date by this number of days using the configured calendar and business
day convention. In general, this should be omitted or set to 0.
• InterpolateOn: As referenced above, the allowable values are
TermVolatilities or OptionletVolatilities. As we are describing here a
surface with interpolation on term volatilities, this should be set to
TermVolatilities as shown in Listing 199.
• BootstrapConfig [Optional]: This node holds configuration details for the
iterative bootstrap that are described in section 7.8.19. If omitted, this node’s
default values described in section 7.8.19 are used.
• InputType [Optional]: The type of the marketdata input. Allowable values are
TermVolatilities or OptionletVolatilities. As we are describing term cap
volatilities input, this should be set to TermVolatilities or omitted as shown in
Listing 199. If omitted, the default value is TermVolatilities.
<CapFloorVolatility>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>
<VolatilityType>...</VolatilityType>
<Extrapolation>...</Extrapolation>
<InterpolationMethod>...</InterpolationMethod>
<IncludeAtm>...</IncludeAtm>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<BusinessDayConvention>...</BusinessDayConvention>
<Tenors>...</Tenors>
<OptionalQuotes>...</OptionalQuotes>
<IborIndex>...</IborIndex>
<DiscountCurve>...</DiscountCurve>
<AtmTenors>...</AtmTenors>
<SettlementDays>...</SettlementDays>
<InterpolateOn>TermVolatilities</InterpolateOn>
<BootstrapConfig>...</BootstrapConfig>
<InputType>TermVolatilities</InputType>
</CapFloorVolatility>

Listing 199: Cap floor surface with interpolation on term volatilities.

Listing 200 shows the layout for parameterising a cap tenor by absolute cap strike
volatility surface with interpolation on optionlet volatilities. This parameterisation also
allows for the inclusion of a cap floor ATM curve in combination with the surface.
Nodes that have no effect for this parameterisation but that are allowed by the schema
are not referenced. The meaning of each of the nodes is as follows:
• CurveId: Unique identifier for the cap floor volatility structure.
• CurveDescription [Optional]: A description of the volatility structure. It is for
information only and may be left blank.
• VolatilityType: Indicates the cap floor volatility type. It may be Normal,
Lognormal or ShiftedLognormal. Note that this then determines which market
data points are looked up in the market when creating the cap floor surface and
how they are interpreted when stripping the optionlets. In particular, the market
will be searched for market data points of the form

252
 CAPFLOOR/RATE_NVOL/Currency/Tenor/IndexTenor/0/0/Strike,
CAPFLOOR/RATE_LNVOL/Currency/Tenor/IndexTenor/0/0/Strike or
CAPFLOOR/RATE_SLNVOL/Currency/Tenor/IndexTenor/0/0/Strike respectively.
• Extrapolation: The allowable values are None, Flat and Linear. If set to None,
extrapolation is turned off and an exception is thrown if the optionlet surface is
queried outside the allowable times or strikes. Otherwise, extrapolation is
allowed and the type of extrapolation is determined by the TimeInterpolation
and StrikeInterpolation node values described below.
• IncludeAtm: A boolean value indicating if an ATM curve should be used in
combination with the surface. Allowable boolean values are given in the Table
46. If set to true, the AtmTenors node needs to be populated with the ATM
tenors to use. The ATM quotes that are searched for are as outlined in the
previous two ATM sections above. The original stripped optionlet surface is
amended by inserting the optionlet volatilities at the configured ATM strikes
that reproduce the configured ATM cap volatilities.
• DayCounter: The day counter used to convert from dates to times in the
underlying structure. Allowable values are given in the Table 35.
• Calendar: The calendar used to advance dates by periods in the underlying
structure. In particular, it is used in deriving the cap maturity dates from the
configured cap tenors. Allowable values are given in the Table 34.
• BusinessDayConvention: The business day convention used to advance dates by
periods in the underlying structure. In particular, it is used in deriving the cap
maturity dates from the configured cap tenors. Allowable values are given in the
Table 30 under Roll Convention.
• Tenors: A comma separated list of valid tenor strings giving the cap floor
maturity tenors to be used in the tenor by strike surface. In this case, i.e.
configuring a surface, they must be provided.
• OptionalQuotes [Optional]: A boolean flag to indicate whether market data
quotes for all tenors and strikes are required. If true, we attempt to build the
curve from whatever quotes are provided. If false, the curve will fail to build if
any quotes are missing. This also applies to quotes for the AtmTenors. Default
value is false.
• IborIndex: A valid interest rate index name giving the index underlying the cap
floor quotes. Allowable values are given in the Table 36.
• DiscountCurve: A reference to a valid discount curve specification that will be
used to discount cashflows during the stripping process. It should be of the form
Yield/Currency/curve_name where curve_name is the name of a yield curve
defined in the yield curve configurations.
• AtmTenors [Optional]: A comma separated list of valid tenor strings giving the
cap floor maturity tenors to be used in the ATM curve. It must be provided
when IncludeAtm is true and omitted when IncludeAtm is false.
• SettlementDays [Optional]: Any non-negative integer is allowed here. If omitted,
it is assumed to be 0. If provided the reference date of the term volatility curve

253
 and the stripped optionlet volatility structure will be calculated by advancing the
valuation date by this number of days using the configured calendar and business
day convention. In general, this should be omitted or set to 0.
• InterpolateOn: As referenced above, the allowable values are
TermVolatilities or OptionletVolatilities. As we are describing here a
surface with interpolation on optionlet volatilities, this should be set to
OptionletVolatilities as shown in Listing 200.
• TimeInterpolation: Indicates the interpolation and extrapolation, if allowed by
the Extrapolation node, in the time direction. As InterpolateOn is set to
OptionletVolatilities here, the interpolation is used to interpolate the
optionlet volatilities only i.e. there is no interpolation on the term cap floor
volatility curve. The allowable values are Linear, LinearFlat, BackwardFlat,
Cubic and CubicFlat. If not set, LinearFlat is assumed. Note that Linear
indicates linear interpolation and linear extrapolation. LinearFlat indicates
linear interpolation and flat extrapolation. Analogous meanings apply for Cubic
and CubicFlat.
• StrikeInterpolation: Indicates the interpolation and extrapolation, if allowed
by the Extrapolation node, in the strike direction. Again, as InterpolateOn is
set to OptionletVolatilities here, the interpolation is used to interpolate the
optionlet volatilities in the strike direction. The allowable values are Linear,
LinearFlat, Cubic and CubicFlat or one of the SABR variants
Hagan2002Lognormal, Hagan2002Normal, Hagan2002NormalZeroBeta,
Antonov2015FreeBoundaryNormal, KienitzLawsonSwaynePde, FlochKennedy.
The SABR variants are only supported for InterpolateOn = OptionVolatilities
(or if InputType = OptionletVolatilities). If not set, LinearFlat is assumed.
• ParametricSmileConfiguration: Optional. Applies to SABR only. If not given,
default values are used. Allows to specify initial values for calibrated parameters,
to exclude single parameters from calibration and to set calibration parameters.
See listing 203.
• QuoteIncludesIndexName [Optional]: If true, the quote labels that are looked up
in the market data to build the surface include the index name as e.g. in
CAPFLOOR/RATE_NVOL/USD/USD-LIBOR-3M/1Y/3M/0/0/0.01. If false, the index
name is not include as in CAPFLOOR/RATE_NVOL/USD/1Y/3M/0/0/0.01. If the flag
is not given, it defaults to false. Including the index name in the market quotes
allows to build cap surfaces on different underlying indices with the same tenor.
The flag also affects shift quotes as e.g. CAPFLOOR/SHIFT/USD/USD-LIBOR-3M/5Y
(index included in quote) vs. CAPFLOOR/SHIFT/USD/5Y (index not included in
quote).
• BootstrapConfig [Optional]: This node holds configuration details for the
iterative bootstrap that are described in section 7.8.19. If omitted, this node’s
default values described in section 7.8.19 are used.
• InputType [Optional]: The type of the marketdata input. Allowable values are
TermVolatilities or OptionletVolatilities. As we are describing term cap
volatilities input, this should be set to TermVolatilities or omitted as shown in
Listing 200. If omitted, the default value is TermVolatilities.

254
<CapFloorVolatility>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>
<VolatilityType>...</VolatilityType>
<Extrapolation>...</Extrapolation>
<InterpolationMethod>...</InterpolationMethod>
<IncludeAtm>...</IncludeAtm>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<BusinessDayConvention>...</BusinessDayConvention>
<Tenors>...</Tenors>
<OptionalQuotes>...</OptionalQuotes>
<IborIndex>...</IborIndex>
<DiscountCurve>...</DiscountCurve>
<AtmTenors>...</AtmTenors>
<SettlementDays>...</SettlementDays>
<InterpolateOn>OptionletVolatilities</InterpolateOn>
<TimeInterpolation>...</TimeInterpolation>
<StrikeInterpolation>...</StrikeInterpolation>
<QuoteIncludesIndexName>...</QuoteIncludesIndexName>
<BootstrapConfig>...</BootstrapConfig>
<InputType>TermVolatilities</InputType>
</CapFloorVolatility>

Listing 200: Cap floor surface with interpolation on optionlet volatilities.

Listing 201 shows the layout for parameterising an ATM optionlet volatility curve.
Nodes that have no effect for this parameterisation but that are allowed by the schema
are not referenced. The meaning of each of the nodes is as follows:
• CurveId: Unique identifier for the cap floor volatility structure.
• CurveDescription [Optional]: A description of the volatility structure. It is for
information only and may be left blank.
• VolatilityType: Indicates the cap floor volatility type. It may be Normal,
Lognormal or ShiftedLognormal. Note that this then determines which market
data points are looked up in the market when creating the ATM optionlet curve.
In particular, the market will be searched for market data points of the form
CAPFLOOR/RATE_NVOL/Currency/Tenor/IndexTenor/1/1/0,
CAPFLOOR/RATE_LNVOL/Currency/Tenor/IndexTenor/1/1/0 or
CAPFLOOR/RATE_SLNVOL/Currency/Tenor/IndexTenor/1/1/0 respectively.
• Extrapolation: The allowable values are None, Flat and Linear. If set to None,
extrapolation is turned off and an exception is thrown if the optionlet surface is
queried outside the allowable times. Otherwise, extrapolation is allowed and the
type of extrapolation is determined by the TimeInterpolation node value
described below.
• IncludeAtm: A boolean value indicating if an ATM curve should be used.
Allowable boolean values are given in the Table 46. As we are describing an
ATM curve here, this node should be set to true as shown in 201.
• DayCounter: The day counter used to convert from dates to times in the
underlying structure. Allowable values are given in the Table 35.

255
 • Calendar: The calendar used to advance dates by periods in the underlying
structure. In particular, it is used in deriving the cap maturity dates from the
configured cap tenors. Allowable values are given in the Table 34.
• BusinessDayConvention: The business day convention used to advance dates by
periods in the underlying structure. In particular, it is used in deriving the cap
maturity dates from the configured cap tenors. Allowable values are given in the
Table 30 under Roll Convention.
• Tenors [Optional]: A comma separated list of valid tenor strings giving the cap
floor maturity tenors to be used in the tenor by strike surface. A single wildcard
character, *, can also be used for wildcard tenor. In this case, i.e. configuring a
surface, they must be provided.
• OptionalQuotes [Optional]: A boolean flag to indicate whether market data
quotes for all tenors are required. Optionlet volatilities do not support optional
quotes, so this node should be false or omitted. Default value is false.
• IborIndex: A valid interest rate index name giving the index underlying the cap
floor quotes. Allowable values are given in the Table 36.
• DiscountCurve: A reference to a valid discount curve specification that will be
used to discount cashflows. It should be of the form
Yield/Currency/curve_name where curve_name is the name of a yield curve
defined in the yield curve configurations.
• AtmTenors [Optional]: A comma separated list of valid tenor strings giving the
cap floor maturities to be used in the ATM curve. A single wildcard character, *,
can also be used for wildcard tenor. In this case, all the tenors found in the
market data input will be used to construct the ATM curve. If omitted, the
tenors for the ATM curve must be provided in the Tenors node instead. If the
tenors are provided here, the Tenors node may be omitted.
• SettlementDays [Optional]: Any non-negative integer is allowed here. If omitted,
it is assumed to be 0. If provided the reference date of the term volatility curve
and the stripped optionlet volatility structure will be calculated by advancing the
valuation date by this number of days using the configured calendar and business
day convention. In general, this should be omitted or set to 0.
• TimeInterpolation [Optional]: Indicates the interpolation and extrapolation, if
allowed by the Extrapolation node, in the time direction. The allowable values
are Linear, LinearFlat, BackwardFlat, Cubic and CubicFlat. If not set,
LinearFlat is assumed. Note that Linear indicates linear interpolation and
linear extrapolation. LinearFlat indicates linear interpolation and flat
extrapolation. Analogous meanings apply for Cubic and CubicFlat.
• InputType: The type of the marketdata input. Allowable values are
TermVolatilities or OptionletVolatilities. As we are describing ATM
curve on optionlet volatilities, this should be set to OptionletVolatilities as
shown in Listing 201.
<CapFloorVolatility>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>

256
 <VolatilityType>...</VolatilityType>
<Extrapolation>...</Extrapolation>
<IncludeAtm>true</IncludeAtm>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<BusinessDayConvention>...</BusinessDayConvention>
<Tenors>...</Tenors>
<OptionalQuotes>false</OptionalQuotes>
<IborIndex>...</IborIndex>
<DiscountCurve>...</DiscountCurve>
<AtmTenors>...</AtmTenors>
<SettlementDays>...</SettlementDays>
<TimeInterpolation>...</TimeInterpolation>
<BootstrapConfig>...</BootstrapConfig>
<InputType>OptionletVolatilities</InputType>
</CapFloorVolatility>

Listing 201: ATM cap floor configuration with optionlet volatilities input.
Listing 202 shows the layout for parameterising an optionlet tenor by absolute
optionlet strike volatility surface. This parameterisation also allows for the inclusion of
an optionlet ATM curve in combination with the surface. Nodes that have no effect for
this parameterisation but that are allowed by the schema are not referenced. The
meaning of each of the nodes is as follows:
• CurveId: Unique identifier for the cap floor volatility structure.
• CurveDescription [Optional]: A description of the volatility structure. It is for
information only and may be left blank.
• VolatilityType: Indicates the cap floor volatility type. It may be Normal,
Lognormal or ShiftedLognormal. Note that this then determines which market
data points are looked up in the market when creating the ATM optionlet curve.
In particular, the market will be searched for market data points of the form
CAPFLOOR/RATE_NVOL/Currency/Tenor/IndexTenor/1/1/0,
CAPFLOOR/RATE_LNVOL/Currency/Tenor/IndexTenor/1/1/0 or
CAPFLOOR/RATE_SLNVOL/Currency/Tenor/IndexTenor/1/1/0 respectively.
• Extrapolation: The allowable values are None, Flat and Linear. If set to None,
extrapolation is turned off and an exception is thrown if the optionlet surface is
queried outside the allowable times. Otherwise, extrapolation is allowed and the
type of extrapolation is determined by the TimeInterpolation node value
described below.
• IncludeAtm: A boolean value indicating if an ATM curve should be used in
combination with the surface. Allowable boolean values are given in the Table
46. If set to true, the AtmTenors node needs to be populated with the ATM
tenors to use. The ATM quotes that are searched for are as outlined in the
previous sections above. The optionlet surface is amended by inserting the
optionlet volatilities at the forecast fixings.
• DayCounter: The day counter used to convert from dates to times in the
underlying structure. Allowable values are given in the Table 35.
• Calendar: The calendar used to advance dates by periods in the underlying

257
 structure. In particular, it is used in deriving the cap maturity dates from the
configured cap tenors. Allowable values are given in the Table 34.
• BusinessDayConvention: The business day convention used to advance dates by
periods in the underlying structure. In particular, it is used in deriving the cap
maturity dates from the configured cap tenors. Allowable values are given in the
Table 30 under Roll Convention.
• Tenors [Optional]: A comma separated list of valid tenor strings giving the cap
floor maturity tenors to be used in the surface. A single wildcard character, *,
can also be used for wildcard tenor. In this case, all the tenors found in the
market data input will be used to construct the ATM curve. If omitted, the
tenors for the ATM curve must be provided in the AtmTenors node instead. If
the tenors are provided here, the AtmTenors node may be omitted.
• OptionalQuotes [Optional]: A boolean flag to indicate whether market data
quotes for all tenors are required. Optionlet volatilities do not support optional
quotes, so this node should be false or omitted. Default value is false.
• IborIndex: A valid interest rate index name giving the index underlying the cap
floor quotes. Allowable values are given in the Table 36.
• DiscountCurve: A reference to a valid discount curve specification that will be
used to discount cashflows. It should be of the form
Yield/Currency/curve_name where curve_name is the name of a yield curve
defined in the yield curve configurations.
• AtmTenors [Optional]: A comma separated list of valid tenor strings giving the
cap floor maturities to be used in the ATM curve. A single wildcard character, *,
can also be used for wildcard tenor. It must be provided when IncludeAtm is
true and omitted when IncludeAtm is false.
• SettlementDays [Optional]: Any non-negative integer is allowed here. If omitted,
it is assumed to be 0. If provided the reference date of the term volatility curve
and the stripped optionlet volatility structure will be calculated by advancing the
valuation date by this number of days using the configured calendar and business
day convention. In general, this should be omitted or set to 0.
• TimeInterpolation [Optional]: Indicates the interpolation and extrapolation, if
allowed by the Extrapolation node, in the time direction. The allowable values
are Linear, LinearFlat, BackwardFlat, Cubic and CubicFlat. If not set,
LinearFlat is assumed. Note that Linear indicates linear interpolation and
linear extrapolation. LinearFlat indicates linear interpolation and flat
extrapolation. Analogous meanings apply for Cubic and CubicFlat.
• StrikeInterpolation [Optional]: Indicates the interpolation and extrapolation,
if allowed by the Extrapolation node, in the strike direction. Again, as
InterpolateOn is set to OptionletVolatilities here, the interpolation is used
to interpolate the optionlet volatilities in the strike direction. The allowable
values are Linear, LinearFlat, Cubic and CubicFlat. If not set, LinearFlat is
assumed.
• QuoteIncludesIndexName [Optional]: If true, the quote labels that are looked up

258
 in the market data to build the surface include the index name as e.g. in
CAPFLOOR/RATE_NVOL/USD/USD-LIBOR-3M/1Y/3M/0/0/0.01. If false, the index
name is not include as in CAPFLOOR/RATE_NVOL/USD/1Y/3M/0/0/0.01. If the flag
is not given, it defaults to false. Including the index name in the market quotes
allows to build cap surfaces on different underlying indices with the same tenor.
The flag also affects shift quotes as e.g. CAPFLOOR/SHIFT/USD/USD-LIBOR-3M/5Y
(index included in quote) vs. CAPFLOOR/SHIFT/USD/5Y (index not included in
quote).
• InputType: The type of the marketdata input. Allowable values are
TermVolatilities or OptionletVolatilities. As we are describing ATM
curve on optionlet volatilities, this should be set to OptionletVolatilities as
shown in Listing 202.
<CapFloorVolatility>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>
<VolatilityType>...</VolatilityType>
<Extrapolation>...</Extrapolation>
<IncludeAtm>...</IncludeAtm>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<BusinessDayConvention>...</BusinessDayConvention>
<Tenors>...</Tenors>
<OptionalQuotes>false</OptionalQuotes>
<IborIndex>...</IborIndex>
<DiscountCurve>...</DiscountCurve>
<AtmTenors>...</AtmTenors>
<SettlementDays>...</SettlementDays>
<TimeInterpolation>...</TimeInterpolation>
<StrikeInterpolation>...</StrikeInterpolation>
<QuoteIncludesIndexName>...</QuoteIncludesIndexName>
<InputType>OptionletVolatilities</InputType>
</CapFloorVolatility>

Listing 202: Cap floor surface with optionlet volatilities input.

<ParametricSmileConfiguration>
<Parameters>
<Parameter>
<Name>alpha</Name>
<InitialValue>0.0050</InitialValue>
<IsFixed>false</IsFixed>
</Parameter>
<Parameter>
<Name>beta</Name>
<InitialValue>0.0</InitialValue>
<IsFixed>true</IsFixed>
</Parameter>
<Parameter>
<Name>nu</Name>
<InitialValue>0.30</InitialValue>
<IsFixed>false</IsFixed>
</Parameter>
<Parameter>
<Name>rho</Name>

259
 <InitialValue>0.0</InitialValue>
<IsFixed>false</IsFixed>
</Parameter>
</Parameters>
<Calibration>
<MaxCalibrationAttempts>10</MaxCalibrationAttempts>
<ExitEarlyErrorThreshold>0.005</ExitEarlyErrorThreshold>
<MaxAcceptableError>0.05</MaxAcceptableError>
</Calibration>
</ParametricSmileConfiguration>

Listing 203: Cap floor surface with optionlet volatilities input.

7.8.7 FX Volatility Structures

Listings 204, 205, 206, 207, 208, 209 shows examples of FX volatility structure
configurations.
<FXVolatility>
<CurveId>EURUSD</CurveId>
<CurveDescription />
<Dimension>ATM</Dimension>
<Expiries>1M,3M,6M,1Y,2Y,3Y,10Y</Expiries>
<FXSpotID>FX/EUR/USD</FXSpotID>
<FXForeignCurveID>Yield/EUR/EUR-IN-USD</FXForeignCurveID>
<FXDomesticCurveID>Yield/USD/USD1D</FXDomesticCurveID>
<DayCounter>A365</DayCounter>
<Calendar>US,TARGET</Calendar>
<Conventions>EUR-USD-FXOPTION</Conventions>
</FXVolatility>

Listing 204: FX option volatility configuration ATM

<FXVolatility>
<CurveId>USDJPY</CurveId>
<CurveDescription />
<Dimension>Smile</Dimension>
<SmileType>VannaVolga</SmileType>
<SmileInterpolation>VannaVolga2</SmileInterpolation>
<Expiries>1M,3M,6M,1Y,2Y,3Y,10Y</Expiries>
<SmileDelta>25</SmileDelta>
<FXSpotID>FX/USD/JPY</FXSpotID>
<FXForeignCurveID>Yield/USD/USD1D</FXForeignCurveID>
<FXDomesticCurveID>Yield/JPY/JPY-IN-USD</FXDomesticCurveID>
<DayCounter>A365</DayCounter>
<Calendar>US,JP</Calendar>
<Conventions>USD-JPY-FXOPTION</Conventions>
</FXVolatility>

Listing 205: FX option volatility configuration Smile / VannaVolga

<FXVolatility>
<CurveId>USDJPY</CurveId>
<CurveDescription />
<Dimension>Smile</Dimension>
<SmileType>Delta</SmileType>
<SmileInterpolation>Linear</SmileInterpolation>

260
 <Expiries>1M,3M,6M,1Y,2Y,3Y,10Y</Expiries>
<Deltas>10P,20P,30P,40P,ATM,40C,30C,20C,10C</Deltas>
<FXSpotID>FX/USD/JPY</FXSpotID>
<FXForeignCurveID>Yield/USD/USD1D</FXForeignCurveID>
<FXDomesticCurveID>Yield/JPY/JPY-IN-USD</FXDomesticCurveID>
<DayCounter>A365</DayCounter>
<Calendar>US,JP</Calendar>
<Conventions>USD-JPY-FXOPTION</Conventions>
<SmileExtrapolation>UseInterpolator</SmileExtrapolation>
</FXVolatility>

Listing 206: FX option volatility configuration Smile / Delta

<FXVolatility>
<CurveId>USDJPY</CurveId>
<CurveDescription />
<Dimension>Smile</Dimension>
<SmileType>BFRR</SmileType>
<SmileInterpolation>Cubic</SmileInterpolation>
<Expiries>1M,3M,6M,1Y,2Y,3Y,10Y</Expiries>
<SmileDelta>10,25</SmileDelta>
<FXSpotID>FX/USD/JPY</FXSpotID>
<FXForeignCurveID>Yield/USD/USD1D</FXForeignCurveID>
<FXDomesticCurveID>Yield/JPY/JPY-IN-USD</FXDomesticCurveID>
<DayCounter>A365</DayCounter>
<Calendar>US,JP</Calendar>
<Conventions>USD-JPY-FXOPTION</Conventions>
</FXVolatility>

Listing 207: FX option volatility configuration Smile / BFRR with 10 and 25 BF and RR

<FXVolatility>
<CurveId>USDJPY</CurveId>
<CurveDescription />
<Dimension>Smile</Dimension>
<SmileType>Absolute</SmileType>
<SmileInterpolation>Cubic</SmileInterpolation>
<Expiries>1M,3M,6M,1Y,2Y,3Y,10Y</Expiries>
<FXSpotID>FX/USD/JPY</FXSpotID>
<FXForeignCurveID>Yield/USD/USD1D</FXForeignCurveID>
<FXDomesticCurveID>Yield/JPY/JPY-IN-USD</FXDomesticCurveID>
<DayCounter>A365</DayCounter>
<Calendar>US,JP</Calendar>
<Conventions>USD-JPY-FXOPTION</Conventions>
</FXVolatility>

Listing 208: FX option volatility configuration Smile / Absolute vols

<FXVolatility>
<CurveId>EURJPY</CurveId>
<CurveDescription />
<Dimension>ATMTriangulated</Dimension>
<FXSpotID>FX/EUR/JPY</FXSpotID>
<DayCounter>A365</DayCounter>
<Calendar>US,JP</Calendar>
<BaseVolatility1>EURUSD</BaseVolatility1>
<BaseVolatility2>USDJPY</BaseVolatility2>

261
 </FXVolatility>

Listing 209: FX option volatility configuration ATM Triangulated

The meaning of each of the elements in Listings 204, 205, 206, 207, 208, 209 is given
below.
• CurveId: Unique identifier of the FX volatility structure
• CurveDescription [Optional]: A description of the volatility structure, may be
left blank.
• Dimension: Distinguishes at-the-money volatility curves from volatility surfaces.
An ‘ATMTriangulated’ value denotes a curve triangulated from two other
surfaces.
Allowable values: ATM, Smile, ATMTriangulated
• SmileType [Optional]: Required field in case of Dimension Smile, otherwise it
can be omitted.
Allowable values: VannaVolga as per (Castagna & Mercurio - 2006), Delta,
BFRR, Absolute, with default value VannaVolga if left blank.
• SmileInterpolation [Optional]: Smile interpolation method applied, required field
in case of Dimension Smile, otherwise it can be omitted.
Allowable values:
– VannaVolga1 or VannaVolga2 in case of SmileType VannaVolga with
default VannaVolga2 if left blank. VannaVolga1/VannaVolga2 refer to the
first/second approximation in (eq. 13) and (eq. 14) of the reference above.
– Linear or Cubic in case of SmileType Delta or BFRR with default Linear
for SmileType Delta and Cubic for SmileType BFRR and Absolute if left
blank
• Expiries: Option expiries in period form. A wildcard may also be used. In the
wildcard case, it will look for any matching quotes provided in the loader, and
construct the curve from these. This is currently only supported for ATM or Delta
or BFRR or Absolute curves.
• Deltas [Optional]: Strike grid, required in case of SmileType Delta
Allowable values: ATM, *P, *C, see example in Listing 206
• SmileDelta [Optional]: Strike grid for SmileType VannaVolga and BFRR, defaults
to 25 for VannaVolga resp. 10,25 for BFRR
Allowable values: a list of integers, see example in Listing 207
• FXSpotID: ORE representation of the relevant FX spot quote in the form
FX/CCY1/CCY2
• FXForeignCurveID [Optional]: Yield curve, in ORE format Yield/CCY/ID, used
as foreign yield curve in smile curves, may be omitted for ATM curves.
• FXDomesticCurveID [Optional]: Yield curve, in ORE format Yield/CCY/ID,
used as domestic yield curve in smile curves, may be omitted for ATM curves.

262
 • DayCounter: The term structure’s day counter used in date to time conversions.
Optional, defaults to A365.
• Calendar: The term structure’s calendar used in option tenor to date
conversions. Optional, defaults to source ccy + target ccy default calendars.
• Conventions [Optional]: FX conventions object ID that is used to determine the
at-the-money type and delta type of the volatility quotes, these default to
AtmDeltaNeutral and Spot for option tenors <= 2Y and AtmDeltaNeutral and
Fwd for option tenors > 2Y if the conventions ID is omitted or left blank.
Furthermore, the conventions hold information on the side of risk reversals
(RiskReversalInFavorOf, defaults to Call) and the quote style of butterflies
(ButterflyStyle, defaults to Broker), these latter two are relevant for BF, RR
market data input. See 7.12.18 for more details.
• BaseVolatility1: For ‘ATMTriangulated’ this denotes one of the surfaces we want
to triangulate from
• BaseVolatility2: For ‘ATMTriangulated’ this denotes one of the surfaces we want
to triangulate from
• SmileExtrapolation [Optional]: Applicable only in case of SmileType Delta.
Indicates the extrapolation in the smile direction. The allowable values are None,
UseInterpolator (or Linear) and Flat. Both Flat and None give flat extrapolation.
UseInterpolator indicates that the configured interpolation should be continued in
the strike direction in order to extrapolate. Default if not provided value is Flat.

7.8.8 Equity Curve Structures

Listing 210 shows the configuration of equity forward price curves.
<EquityCurves>
<EquityCurve>
<CurveId>SP5</CurveId>
<CurveDescription>SP 500 equity price projection curve</CurveDescription>
<Currency>USD</Currency>
<ForecastingCurve>EUR1D</ForecastingCurve>
<!-- DividendYield, ForwardPrice, OptionPremium, NoDividends, ForwardDividendPrice -->
<Type>DividendYield</Type>
<!-- Optional node, only used when Type is OptionPremium -->
<ExerciseStyle>American</ExerciseStyle>
<!-- Spot quote from the market data file -->
<SpotQuote>EQUITY/PRICE/SP5/USD</SpotQuote>
<!-- Note: do not provide Quotes if Type is NoDividends -->
<Quotes>
<Quote>EQUITY_DIVIDEND/RATE/SP5/USD/3M</Quote>
<Quote>EQUITY_DIVIDEND/RATE/SP5/USD/20160915</Quote>
<Quote>EQUITY_DIVIDEND/RATE/SP5/USD/1Y</Quote>
<Quote>EQUITY_DIVIDEND/RATE/SP5/USD/20170915</Quote>
</Quotes>
<!-- Optional interpolation options, default Zero and Linear -->
<!-- Note: do not provide DividendInterpolation if Type is NoDividends -->
<DividendInterpolation>
<!-- Zero, Discount -->
<InterpolationVariable>Zero</InterpolationVariable>
<!-- See Table 17 for allowed interpolation methods -->

263
 <InterpolationMethod>Linear</InterpolationMethod>
</DividendInterpolation>
<DividendExtrapolation>False</DividendExtrapolation>
<!-- Optional node, defaults to false -->
<Extrapolation>False</Extrapolation>
<DayCounter>A365</DayCounter>
</EquityCurve>
<EquityCurve>
...
</EquityCurve>
</EquityCurves>

Listing 210: Equity curve configuration

The meaning of each of the elements is given below.
• CurveId: Unique identifier of the equity curve structure.
• CurveDescription [Optional]: A description of the equity curve structure, may be
left blank.
• Currency: Currency of the equity.
• Calendar [Optional]: The term structure’s calendar used in tenor to date
conversions. Defaults to the calendar corresponding to Currency.
• ForecastingCurve: CurveId of the curve used for discounting equity fixing
forecasts.
• Type: The quote types in Quote (e.g. option premium, forward equity price) and
whether dividends are taken into account. Allowable values: DividendYield,
ForwardPrice, ForwardDividendPrice, OptionPremium, NoDividends
• ExerciseStyle [Optional]: Exercise type of the underlying option quotes. Only
required if Type is OptionPremium. Allowable values: American, European
• SpotQuote: Market datum ID/name of the current spot rate for the equity
underlying.
• Quotes [Optional]: Market datum IDs/names to be used in building the curve
structure.
• DayCounter [Optional]: The term structure’s day counter used in date to time
conversions. Defaults to A365F.
• DividendInterpolation [Optional]: This node contains an
InterpolationVariable and InterpolationMethod sub-node, which define the
variable on which the interpolation is performed and the interpolation method
for the dividend curve, respectively. The allowable values are found in Table 16
and Table 17, respectively. This should not be provided if Type is NoDividends.
• DividendExtrapolation [Optional]: Boolean flag indicating whether extrapolation
in the dividend curve is allowed. If True the dividend curve is extrapolated
forward at the risk free rate beyond the last date of the curve - this is only
considered when Extrapolation is False. Defaults to False.

264
 • Extrapolation [Optional]: Boolean flag indicating whether extrapolation in the
forward price is allowed. Defaults to False.
The equity curves here consists of a spot equity price, as well as a set of either forward
prices or else dividend yields. If the index is a dividend futures index then curve type
should be entered as ForwardDividendPrice. In this case the curve will be built from
forward prices as normal, but excluded from the SIMM calculations as required by the
SIMM methodology. Upon construction, ORE stores internally an equity spot price
quote, a forecasting curve and a dividend yield term structure, which are then used
together for projection of forward prices.

7.8.9 Equity Volatility Structures

When configuring volatility structures for equities, there are four options:
1. a constant volatility for all expiries and strikes.
2. a volatility curve with a dependency on expiry but no strike dimension.
3. a volatility surface with an expiry and strike dimension.
4. a proxy surface - point to another surface as a proxy.
There are a number of fields common to all configurations:
• CurveId: Unique identifier for the curve.
• CurveDescription [Optional]: A description of the curve. This field may be left
blank.
• EquityId: [Optional] Identifies the underlying equity name, this is used in the
construction of the Quote strings. If omitted the CurveId is used instead.
• Currency: Currency of the equity.
• Calendar [Optional]: allowable value is any valid calendar. Defaults to
NullCalendar.
• DayCounter [Optional]: allowable value is any valid day counter. Defaults to
A365.
• OneDimSolverConfig [Optional]: A configuration for the one dimensional solver
used in deriving volatilities from prices. This node is described in detail in
Section 7.8.20. If not provided, a default step based configuration is used. This is
only used when volatilities are stripped from prices.
• PreferOutOfTheMoney [Optional]: allowable value is any boolean value. Defaults
to false for backwards compatibility. It is used, when building the volatility
surface, to choose between a call and put option price or volatility when both are
provided. When set to true, the out of the money option is chosen by comparing
the quote’s strike with the forward price at the associated expiry. Conversely,
when set to false, the in the money option is chosen.
Listing 211 shows the configuration of equity volatility structures with constant
volatility. A node Constant takes one Quote, as described in Section 10.24, which is
held constant for all strikes and expiries.

265
<EquityVolatilities>
<EquityVolatility>
<CurveId>SP5</CurveId>
<CurveDescription>Lognormal option implied vols for SP 500</CurveDescription>
<EquityId>RIC:.SP5</EquityId>
<Currency>USD</Currency>
<DayCounter>Actual/365 (Fixed)</DayCounter>
<Constant>
<Quote>EQUITY_OPTION/RATE_LNVOL/RIC:.SP5/USD/5Y/ATMF</Quote>
</Constant>
</EquityVolatility>
<EquityVolatility>
...
</EquityVolatility>
</EquityVolatilities>

Listing 211: Equity option volatility configuration - constant

Secondly, the volatility curve configuration layout is given in Listing 212. With this
curve construction the volatility is held constant in the strike direction, and quotes of
varying expiry can be provided, for examlple if only ATM volatility quotes are
available. The volatility quote IDs in the Quotes node should be Equity option
volatility quotes as described in Section 10.24. An explicit list of quotes can be
provided, or a single quote with a wildcard replacing the expiry/strike. In the wildcard
case, it will look for any matching quotes provided in the loader, and construct the
curve from these. The Interpolation node supports Linear, Cubic and LogLinear
interpolation. The Extrapolation node supports either None for no extrapolation or
Flat for flat extrapolation in the volatility.
<EquityVolatilities>
<EquityVolatility>
<CurveId>SP5</CurveId>
<CurveDescription>Lognormal option implied vols for SP 500</CurveDescription>
<EquityId>RIC:.SP5</EquityId>
<Currency>USD</Currency>
<DayCounter>Actual/365 (Fixed)</DayCounter>
<Curve>
<QuoteType>ImpliedVolatility</QuoteType>
<VolatilityType>Lognormal</VolatilityType>
<Quotes>
<Quote>EQUITY_OPTION/RATE_LNVOL/RIC:.SP5/USD/*</Quote>
</Quotes>
<Interpolation>LinearFlat</Interpolation>
<Extrapolation>Flat</Extrapolation>
</Curve>
</EquityVolatility>
<EquityVolatility>
...
</EquityVolatility>
</EquityVolatilities>

Listing 212: Equity option volatility configuration - curve

The volatility strike surface configuration layout is given in Listing 213. This allows a
full surface of Strikes and Expiries to be defined. The following are the valid nodes:

266
 • QuoteType: either ImpliedVolatility of Premium, indicating the type of quotes
provided in the market.
• ExerciseType [Optional]: only valid when QuoteType is Premium. Valid types
are European and American.
• VolatilityType [Optional]: only valid when QuoteType is ImpliedVolatility.
Valid types are Lognormal, ShiftedLognormal and Normal.
• Strikes: comma separated list of strikes, representing the absolute strike values
for the option. In other words, A single wildcard character, *, can be used here
also to indicate that all strikes found in the market data for this equity volatility
configuration should be used when building the equity volatility surface.
• Expiries: comma separated list of expiry tenors and or expiry dates. A single
wildcard character, *, can be used here also to indicate that all expiries found in
the market data for this equity volatility configuration should be used when
building the equity volatility surface.
• TimeInterpolation: interpolation in the option expiry direction. If either
Strikes or Expiries are configured with a wildcard character, Linear is used.
If both Strikes and Expiries are configured explicitly, Linear or Cubic is
allowed here but the value must agree with the value for StrikeInterpolation.
• StrikeInterpolation: interpolation in the strike direction. If either Strikes or
Expiries are configured with a wildcard character, Linear is used. If both
Strikes and Expiries are configured explicitly, Linear or Cubic is allowed here
but the value must agree with the value for TimeInterpolation.
• Extrapolation: boolean value. If true, extrapolation is allowed. If false,
extrapolation is not allowed.
• TimeExtrapolation: extrapolation in the option expiry direction. If both
Strikes and Expiries are configured explicitly, the extrapolation in the time
direction is flat in volatility regardless of the setting here. If either Strikes or
Expiries are configured with a wildcard character, Linear, UseInterpolator,
Flat or None are allowed. If Linear or UseInterpolator is specified, the
extrapolation is linear. If Flat is specified, the extrapolation is flat. If None is
specified, it is ignored and the extrapolation is flat since extrapolation in the
time direction cannot be turned off in isolation i.e. extrapolation can only be
turned off for the surface as a whole using the Extrapolation flag.
• StrikeExtrapolation: extrapolation in the strike direction. The allowable
values are Linear, UseInterpolator, Flat or None. If Linear or
UseInterpolator is specified, the extrapolation uses the strike interpolation
setting for extrapolation i.e. linear or cubic in this case. If Flat is specified, the
extrapolation is flat. If None is specified, it is ignored and the extrapolation is
flat since extrapolation in the strike direction cannot be turned off in isolation
i.e. extrapolation can only be turned off for the surface as a whole using the
Extrapolation flag.
When this configuration is used, the market is searched for quote strings of the form
EQUITY_OPTION/PRICE/[NAME]/[CURRENCY]/[EXPIRY]/[STRIKE] or

267
EQUITY_OPTION/RATE_LNVOL/[NAME]/[CURRENCY]/[EXPIRY]/[STRIKE], depending on
the QuoteType. When both the Strikes and Expiries are configured explicitly, it is
clear that the [EXPIRY] field is populated from the list of expiries in turn and the
[STRIKE] field is populated from the list of strikes in turn. If there are m expiries in
the Expiries list and n strikes in the Strikes list, there will be m × n quotes created
and searched for in the market data. If Expiries are configured via the wildcard
character, *, all quotes in the market data matching the pattern
EQUITY_OPTION/RATE_LNVOL/[NAME]/[CURRENCY]/*/[STRIKE]. Similarly for Strikes
configured via the wildcard character, *.
<EquityVolatilities>
<EquityVolatility>
<CurveId>SP5</CurveId>
<CurveDescription>Lognormal option implied vols for SP 500</CurveDescription>
<EquityId>RIC:.SP5</EquityId>
<Currency>USD</Currency>
<DayCounter>Actual/365 (Fixed)</DayCounter>
<StrikeSurface>
<QuoteType>Premium</QuoteType>
<ExerciseType>European</ExerciseType>
<Strikes>*</Strikes>
<Expiries>*</Expiries>
<TimeInterpolation>Linear</TimeInterpolation>
<StrikeInterpolation>Linear</StrikeInterpolation>
<Extrapolation>true</Extrapolation>
<TimeExtrapolation>UseInterpolator</TimeExtrapolation>
<StrikeExtrapolation>Flat</StrikeExtrapolation>
</StrikeSurface>
</EquityVolatility>
<EquityVolatility>
...
</EquityVolatility>
</EquityVolatilities>

Listing 213: Equity option volatility configuration - strike surface

A volatility surface can also be given in terms of moneyness levels as shown in listing
214. The nodes have the same meaning as in the case of a strike surface with the
following exceptions:
• QuoteType: only ImpliedVolatility is allowed
• VolatilityType [Optional]: only Lognormal is allowed
• MoneynessType: Spot or Fwd, indicating the type of moneyness. See 10.24 for
the definition of moneyness types.
• MoneynessLevels: comma separated list of moneyness levels, no wild cards are
allowed.
• Expiries: comma separated list of expiry tenors and or expiry dates. A single
wildcard character, *, can be used here also to indicate that all expiries found in
the market data for this equity volatility configuration should be used when
building the equity volatility surface.
Notice that the market data for the moneyness level 1.0 must be given as a moneyness

268
quote, not an ATM or ATMF quote, see 10.24 for details of the market data.
<EquityVolatilities>
<EquityVolatility>
<CurveId>SP5</CurveId>
<CurveDescription>Lognormal option implied vols for SP 500</CurveDescription>
<EquityId>RIC:.SP5</EquityId>
<Currency>USD</Currency>
<DayCounter>Actual/365 (Fixed)</DayCounter>
<MoneynessSurface>
<QuoteType>ImpliedVolatility</QuoteType>
<VolatilityType>Lognormal</VolatilityType>
<MoneynessType>Fwd</MoneynessType>
<MoneynessLevels>0.5,0.6,0.7,0.8,0.9,1.0,1.1,1.2,1.3,1.4,1.5</MoneynessLevels>
<Expiries>*</Expiries>
<TimeInterpolation>Linear</TimeInterpolation>
<StrikeInterpolation>Linear</StrikeInterpolation>
<Extrapolation>true</Extrapolation>
<TimeExtrapolation>UseInterpolator</TimeExtrapolation>
<StrikeExtrapolation>Flat</StrikeExtrapolation>
</MoneynessSurface>
</EquityVolatility>
<EquityVolatility>
...
</EquityVolatility>
</EquityVolatilities>

Listing 214: Equity option volatility configuration - moneyness surface

Finally, the volatility proxy surface configuration layout is given in Listing 215. This
allows us to use any other surface as a proxy, in cases where there is no option data for
a given equity. We provide a name in the EquityVolatilityCurve field, which must
match the CurveId of another configuration. FXVolatilityCurve and
CorrelationCurve must be provided if the currency of the proxy surface is different to
that of current surface, that can be omitted otherwise. The proxy surface looks up the
volatility in the reference surface based on moneyness.
<EquityVolatilities>
<EquityVolatility>
<CurveId>ABC</CurveId>
<CurveDescription>Lognormal option implied vols for APC - proxied from SP5</CurveDescription>
<EquityId>RIC:.SP5</EquityId>
<Currency>USD</Currency>
<DayCounter>Actual/365 (Fixed)</DayCounter>
<ProxySurface>
<EquityVolatilityCurve>RIC:.SPX</EquityVolatilityCurve>
<FXVolatilityCurve>GBPUSD</FXVolatilityCurve>
<CorrelationCurve>FX-GENERIC-GBP-USD&amp;EQ-RIC:VOD.L</CorrelationCurve>
</ProxySurface>
</EquityVolatility>
<EquityVolatility>
...
</EquityVolatility>
</EquityVolatilities>

Listing 215: Equity option volatility configuration - proxy surface

269
7.8.10 Inflation Curves
Listing 216 shows the configuration of an inflation curve. The inflation curve specific
elements are the following:
<InflationCurves>
<InflationCurve>
<CurveId>USCPI_ZC_Swaps</CurveId>
<CurveDescription>Estimation Curve for USCPI</CurveDescription>
<NominalTermStructure>Yield/USD/USD1D</NominalTermStructure>
<Type>ZC</Type>
<Quotes>
<Quote>ZC_INFLATIONSWAP/RATE/USCPI/1Y</Quote>
<Quote>ZC_INFLATIONSWAP/RATE/USCPI/2Y</Quote>
...
<Quote>ZC_INFLATIONSWAP/RATE/USCPI/30Y</Quote>
<Quote>ZC_INFLATIONSWAP/RATE/USCPI/40Y</Quote>
</Quotes>
<Conventions>USCPI_INFLATIONSWAP</Conventions>
<Extrapolation>true</Extrapolation>
<Calendar>US</Calendar>
<DayCounter>A365</DayCounter>
<Lag>3M</Lag>
<Frequency>Monthly</Frequency>
<BaseRate>0.01</BaseRate>
<Tolerance>0.000000000001</Tolerance>
<Seasonality>
<BaseDate>20160101</BaseDate>
<Frequency>Monthly</Frequency>
<Factors>
<Factor>SEASONALITY/RATE/MULT/USCPI/JAN</Factor>
<Factor>SEASONALITY/RATE/MULT/USCPI/FEB</Factor>
<Factor>SEASONALITY/RATE/MULT/USCPI/MAR</Factor>
<Factor>SEASONALITY/RATE/MULT/USCPI/APR</Factor>
<Factor>SEASONALITY/RATE/MULT/USCPI/MAY</Factor>
<Factor>SEASONALITY/RATE/MULT/USCPI/JUN</Factor>
<Factor>SEASONALITY/RATE/MULT/USCPI/JUL</Factor>
<Factor>SEASONALITY/RATE/MULT/USCPI/AUG</Factor>
<Factor>SEASONALITY/RATE/MULT/USCPI/SEP</Factor>
<Factor>SEASONALITY/RATE/MULT/USCPI/OCT</Factor>
<Factor>SEASONALITY/RATE/MULT/USCPI/NOV</Factor>
<Factor>SEASONALITY/RATE/MULT/USCPI/DEC</Factor>
</Factors>
<OverrideFactors>
1.00,1.00,1.00,1.00,1.00,1.00,1.00,1.00,1.00,1.00,1.00,1.00
</OverrideFactors>
</Seasonality>
</InflationCurve>
</InflationCurves>

Listing 216: Inflation Curve Configuration

• NominalTermStructure: The interest rate curve to be used to strip the inflation
curve.
• Type: The type of the curve, ZC for zero coupon, YY for year on year.
• Quotes: The instruments’ market quotes from which to bootstrap the curve.

270
 • Conventions: The conventions applicable to the curve instruments.
• Lag: The observation lag used in the term structure.
• Frequency: The frequency of index fixings.
• BaseRate: The rate at t = 0, this introduces an additional degree of freedom to
get a smoother curve. If not given, it is defaulted to the first market rate.
The optional seasonality block defines a multiplicative seasonality and contains the
following elements:
• BaseDate: Defines the first inflation period to which to apply the seasonality
correction, only day and month matters, the year is ignored.
• Frequency: Defines the frequency of the factors (usually identical to the index’s
fixing frequency).
• Factors: Multiplicative seasonality correction factors, must be part of the
market data.
• OverrideFactors: A numeric list of seasonality correction factors, replacing the
Factors. This allows to specify a static seasonality correction that does not
require market data quotes. If both Factors and OverrideFactors are given, the
OverrideFactors are used. Otherwise only one of Factors, OverrideFactors is
required in a seasonality block.
We note that if zero coupon swap market quotes are given, but the type is set to YY,
the zero coupon swap quotes will be converted to year on year swap quotes on the fly,
using the plain forward rates, i.e. no convexity adjustment is applied.

7.8.11 Inflation Cap/Floor Volatility Surfaces

Listing 217 shows the configuration of an zero coupon inflation cap floor price surface.
<InflationCapFloorVolatility>
<CurveId>EUHICPXT_ZC_CF</CurveId>
<CurveDescription>
EUHICPXT CPI Cap/Floor vol surface derived from price quotes
</CurveDescription>
<Type>ZC</Type>
<QuoteType>Price</QuoteType>
<VolatilityType>Normal</VolatilityType>
<Extrapolation>Y</Extrapolation>
<DayCounter>ACT</DayCounter>
<Calendar>TARGET</Calendar>
<BusinessDayConvention>MF</BusinessDayConvention>
<Tenors>1Y,2Y,3Y,4Y,5Y,6Y,7Y,8Y,9Y,10Y,12Y,15Y,20Y,30Y</Tenors>
<!-- QuoteType 'Volatility' requires <Strikes>: -->
<!-- <Strikes>-0.02,-0.01,-0.005,0.00,0.01,0.015,0.02,0.025,0.03</Strikes> -->
<!-- QuoteType 'Price' requires <CapStrikes> and/or <FloorStrikes>: -->
<CapStrikes/>
<FloorStrikes>-0.02,-0.01,-0.005,0.00,0.01,0.015,0.02,0.025,0.03</FloorStrikes>
<Index>EUHICPXT</Index>
<IndexCurve>Inflation/EUHICPXT/EUHICPXT_ZC_Swaps</IndexCurve>
<IndexInterpolated>false</IndexInterpolated>
<ObservationLag>3M</ObservationLag>

271
 <YieldTermStructure>Yield/EUR/EUR1D</YieldTermStructure>
<QuoteIndex>...</QuoteIndex>
</InflationCapFloorVolatility>

Listing 217: Inflation ZC cap floor volatility surface configuration

• Type: The type of the surface, ZC for zero coupon, YY for year on year.
• QuoteType: The type of the quotes used to build the surface, Volatility for
volatility quotes, Price for bootstrap from option premia.
• VolatilityType: If QuoteType is Volatility, this specifies whether the input
is Normal, Lognormal or ShiftedLognormal.
• Extrapolation: Boolean to indicate whether the surface should allow
extrapolation.
• DayCounter: The term structure’s day counter
• Calendar: The term structure’s calendar
• BusinessDayConvention: The term structure’s business day convention
• Tenors: The maturities for which cap and floor prices are quoted
• Strikes: In the case of QuoteType Volatility, the strikes for which floor prices
are quoted (may, and will usually, overlap with the cap strike region); neither
CapStrikes nor FloorStrikes are expected in this case.
• CapStrikes: The strikes for which cap prices are quoted (may, and will usually,
overlap with the floor strike region); if the QuoteType above is Price, either
CapStrikes or FloorStrikes or both are required.
• FloorStrikes: The strikes for which floor prices are quoted (may and will
usually) overlap with the cap strike region); if the QuoteType above is Price,
either CapStrikes or FloorStrikes or both are required.
• Index: The underlying zero inflation index.
• IndexCurve: The curve id of the index’s projection curve used to determine the
ATM levels for the surface.
• IndexInterpolated: Flag indicating whether the index should be interpolating.
• Observation Lag: The observation lag applicable to the term structure.
• YieldTermStructure: The nominal term structure.
• QuoteIndex: An optional node allowing the user to provide an alternative index
name for forming the quotes that will be used in building the cap floor surface. If
this node is not provided, the Index node value is used in quote construction.
For example, quotes must be created from each strike and each tenor and these
quotes are subsequently looked up in the market data when building the cap
floor volatility surface. The quotes are formed by concatenating
[Type]_INFLATIONCAPFLOOR, PRICE or RATE_[Vol_Type]VOL, [Index_Name],
[Tenor], C or F and [Strike] delimited by /. If QuoteIndex is provided, it is
used as the [Index_Name] token. If it is not provided Index is used as usual.

272
7.8.12 CDS Volatilities
When configuring volatility structures for CDS and index CDS options, there are three
options:
1. a constant volatility for all expiries, strikes and terms.
2. a volatility curve with a dependency on expiry and term, but no strike dimension.
3. a volatility surface with an expiry, term and strike dimension.
Firstly, the constant volatility configuration layout is given in Listing 218. The single
volatility quote ID, constant_quote_id, in the Quote node should be a CDS option
volatility quote as described in Section 10.15. The DayCounter node is optional and
defaults to A365F. The Calendar node is optional and defaults to NullCalendar. The
DayCounter and Calendar nodes are common to all three CDS volatility
configurations.
<CDSVolatility>
<CurveId>..<CurveId>
<CurveDescription>...</CurveDescription>
<Constant>
<Quote>constant_quote_id</Quote>
</Constant>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
</CDSVolatility>

Listing 218: Constant CDS volatility configuration

Secondly, the volatility curve configuration layout is given in Listing 219. The volatility
quote IDs, quote_id_1, quote_id_2, etc., in the Quotes node should be CDS option
volatility quotes as described in Section 10.15. The Interpolation node supports
Linear, Cubic and LogLinear interpolation. The Extrapolation node supports
either None for no extrapolation or Flat for flat extrapolation in the volatility.
The optional boolean parameter EnforceMontoneVariance should be set to true to
raise an exception if the curve implied variance is not montone increasing with time
and should be set to false if you want to suppress such an exception. The default
value for EnforceMontoneVariance is true.
<CDSVolatility>
<CurveId>..<CurveId>
<CurveDescription>...</CurveDescription>
<Terms>
<Term>
<Label>...</Label>
<Curve>...</Curve>
</Term>
</Terms>
<Curve>
<Quotes>
<Quote>quote_id_1</Quote>
<Quote>quote_id_2</Quote>
...
</Quotes>
<Interpolation>...</Interpolation>

273
 <Extrapolation>...</Extrapolation>
<EnforceMontoneVariance></EnforceMontoneVariance>
</Curve>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
</CDSVolatility>

Listing 219: CDS volatility curve configuration

For backwards compatibility, the volatility curve configuration can also be given using
a single Expiries node as shown in Listing 220. Note that this configuration is
deprecated and the configuration in 219 is preferred. The Expiries node should take a
comma separated list of tenors and or expiry dates e.g.
<Expiries>1M,3M,6M</Expiries>. The list of expiries are extracted and a set of
quotes are created of the form INDEX_CDS_OPTION/RATE_LNVOL/[NAME]/[EXPIRY] or
INDEX_CDS_OPTION/RATE_LNVOL/[NAME]/[TERM]/[EXPIRY]. There is one quote for
each expiry in the list where the [EXPIRY] field is understood to be replaced with the
expiry string extracted from the list.
The [NAME] field is populated with the curve id or with the [QuoteName] if that is
specified. The rules for including market quotes into the volatility surface construction
are as follows:
• All quotes explicitly specified with their full name are loaded (applies to configs
of type constant or curve without wildcards)
• If a quote does not contain a term, we only load it if at most one term is
specified in the vol curve config. The quote gets the unique term specified in the
vol curve configs assigned or 5Y if the config does not specify any terms.
• If a quote contains a term if this matches one of the configured terms in the
curve configuration or if the curve configuration does not specify any terms.
The [Terms] node specifies a list of term labels “5Y”, “7Y”, ... and associated credit
curve spec names representing the curve suitable to estimate the ATM level for that
term.
If only one expiry is provided in the list, there is only one quote and a constant
volatility structure is configured as in Listing 218. If more than one expiry is provided,
a curve is configured as in 219. The interpolation is Linear, the extrapolation is Flat
and EnforceMontoneVariance is true.
<CDSVolatility>
<CurveId>..<CurveId>
<CurveDescription>...</CurveDescription>
<Terms>
<Term>
<Label>...</Label>
<Curve>...</Curve>
</Term>
</Terms>
<Expiries>...</Expiries>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<QuoteName>...</QuoteName>

274
</CDSVolatility>

Listing 220: Legacy deprecated CDS volatility curve configuration

Thirdly, the volatility surface configuration layout is given in Listing 221. The nodes
have the following meanings and supported values:
• Strikes: comma separated list of strikes. The strikes may be in terms of spread
or price. However, it is important to ensure that the trade XML for a CDS
option or index CDS option provides the strike in the same way. In other words,
if the strike is in terms of spread on the trade XML, the strike must be in terms
of spread in the CDS volatility configuration here. Similarly for strikes in terms
of price. A single wildcard character, *, can be used here also to indicate that all
strikes found in the market data for this CDS volatility configuration should be
used when building the CDS volatility surface.
• Expiries: comma separated list of expiry tenors and or expiry dates. A single
wildcard character, *, can be used here also to indicate that all expiries found in
the market data for this CDS volatility configuration should be used when
building the CDS volatility surface.
• TimeInterpolation: interpolation in the option expiry direction. If either
Strikes or Expiries are configured with a wildcard character, Linear is used.
If both Strikes and Expiries are configured explicitly, Linear or Cubic is
allowed here but the value must agree with the value for StrikeInterpolation.
• StrikeInterpolation: interpolation in the strike direction. If either Strikes or
Expiries are configured with a wildcard character, Linear is used. If both
Strikes and Expiries are configured explicitly, Linear or Cubic is allowed here
but the value must agree with the value for TimeInterpolation.
• Extrapolation: boolean value. If true, extrapolation is allowed. If false,
extrapolation is not allowed.
• TimeExtrapolation: extrapolation in the option expiry direction. If both
Strikes and Expiries are configured explicitly, the extrapolation in the time
direction is flat in volatility regardless of the setting here. If either Strikes or
Expiries are configured with a wildcard character, Linear, UseInterpolator,
Flat or None are allowed. If Linear or UseInterpolator is specified, the
extrapolation is linear. If Flat is specified, the extrapolation is flat. If None is
specified, it is ignored and the extrapolation is flat since extrapolation in the
time direction cannot be turned off in isolation i.e. extrapolation can only be
turned off for the surface as a whole using the Extrapolation flag.
• StrikeExtrapolation: extrapolation in the strike direction. The allowable
values are Linear, UseInterpolator, Flat or None. If Linear or
UseInterpolator is specified, the extrapolation uses the strike interpolation
setting for extrapolation i.e. linear or cubic in this case. If Flat is specified, the
extrapolation is flat. If None is specified, it is ignored and the extrapolation is
flat since extrapolation in the strike direction cannot be turned off in isolation
i.e. extrapolation can only be turned off for the surface as a whole using the
Extrapolation flag.

275
 • DayCounter: allowable value is any valid day count fraction. As stated above,
this node is optional and defaults to A365F.
• Calendar: allowable value is any valid calendar. As stated above, this node is
optional and defaults to NullCalendar.
• StrikeType: allowable value is either Price or Spread. This flag denotes if the
strikes are in terms of spread or price. Currently, this is merely informational
and as outlined in the Strikes section above, it is the responsibility of the user
to ensure that the strike type in trades aligns with the configured strike type in
the CDS volatility surfaces.
• QuoteName: this node is optional and the allowable value is any string. This
value can be used in determining the name and term that appears in the quote
strings that are searched for in the market data to feed into the CDS volatility
surface construction. How it is used has been outlined above when describing the
deprecated CDS volatility curve configuration.
• StrikeFactor: this node is optional and the allowable value is any positive real
number. It defaults to 1. The strikes configured and found in the market data
quote strings may not be in absolute terms. For example, a quote string such as
INDEX_CDS_OPTION/RATE_LNVOL/CDXIGS33V1/5Y/1M/115 could be given to
indicate an index CDS option volatility quote for CDX IG Series 33 Version 1,
with underlying index term 5Y expiring in 1M with a strike spread of 115 bps.
The strike here is in bps and needs to be divided by 10,000 before being used in
the ORE volatility objects. The StrikeFactor would be set to 10000 here.
When the CDS volatility surface is configured as in Listing 221, the market is searched
for quote strings of the form
INDEX_CDS_OPTION/RATE_LNVOL/[NAME]/[EXPIRY]/[STRIKE] or
INDEX_CDS_OPTION/RATE_LNVOL/[NAME]/[TERM]/[EXPIRY]/[STRIKE]. The
population of the [NAME] field, and possibly the [TERM] field, and how they depend on
the QuoteName and ParseTerm nodes has been discussed at length above when
describing the deprecated CDS volatility curve configuration. When both the Strikes
and Expiries are configured explicitly, it is clear that the [EXPIRY] field is populated
from the list of expiries in turn and the [STRIKE] field is populated from the list of
strikes in turn. If there are m expiries in the Expiries list and n strikes in the
Strikes list, there will be m × n quotes created and searched for in the market data.
If Expiries are configured via the wildcard character, *, all quotes in the market data
matching the pattern INDEX_CDS_OPTION/RATE_LNVOL/[NAME]/*/[STRIKE] will be
used if [TERM] has not been populated and all quotes in the market data matching the
pattern INDEX_CDS_OPTION/RATE_LNVOL/[NAME]/[TERM]/*/[STRIKE] will be used if
[TERM] has been populated. Similarly for Strikes configured via the wildcard
character, *.
<CDSVolatility>
<CurveId/>
<CurveDescription/>
<Terms>
<Term>
<Label>...</Label>
<Curve>...</Curve>
</Term>

276
 </Terms>
<StrikeSurface>
<Strikes>...</Strikes>
<Expiries>...</Expiries>
<TimeInterpolation>...</TimeInterpolation>
<StrikeInterpolation>...</StrikeInterpolation>
<Extrapolation>...</Extrapolation>
<TimeExtrapolation>...</TimeExtrapolation>
<StrikeExtrapolation>...</StrikeExtrapolation>
</StrikeSurface>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<StrikeType>...</StrikeType>
<QuoteName>...</QuoteName>
<StrikeFactor>..</StrikeFactor>
<ParseTerm>...</ParseTerm>
</CDSVolatility>

Listing 221: CDS volatility surface configuration

7.8.13 Base Correlations

Listing 222 shows the configuration of a Base Correlation curve.
<BaseCorrelations>
<BaseCorrelation>
<CurveId>CDXIG</CurveId>
<CurveDescription>CDX IG Base Correlations</CurveDescription>
<Terms>1D</Terms>
<DetachmentPoints>0.03, 0.06, 0.10, 0.20, 1.0</DetachmentPoints>
<SettlementDays>0</SettlementDays>
<Calendar>US</Calendar>
<BusinessDayConvention>F</BusinessDayConvention>
<DayCounter>A365</DayCounter>
<Extrapolate>Y</Extrapolate>
</BaseCorrelation>
</BaseCorrelations>

Listing 222: Base Correlation Configuration

The meaning of each of the elements in Listing 222 is given below.
• CurveId: Unique identifier of the base correlation structure
• CurveDescription [Optional]: A description of the base correlation structure, may
be left blank.
• Terms: Comma-separated list of tenors, sorted in increasing order, possibly a
single term to represent a flat term structure in time-direction
• DetachmentPoints: Comma-separated list of equity tranche detachment points,
sorted in increasing order
Allowable values: Any positive number less than one
• SettlementDays: The floating term structure’s settlement days argument used in
the reference date calculation
• DayCounter: The term structure’s day counter used in date to time conversions

277
 • Calendar: The term structure’s calendar used in tenor to date conversions
• BusinessDayConvention: The term structure’s business day convention used in
tenor to date conversion
• Extrapolate: Boolean to indicate whether the correlation curve shall be
extrapolated or not

7.8.14 FXSpots
Listing 223 shows the configuration of the fxSpots. It is assumed that each FXSpot
CurveId is of the form "Ccy1Ccy2".
<FXSpots>
<FXSpot>
<CurveId>EURUSD</CurveId>
<CurveDescription/>
</FXSpot>
<FXSpot>
<CurveId>EURGBP</CurveId>
<CurveDescription/>
</FXSpot>
<FXSpot>
<CurveId>EURCHF</CurveId>
<CurveDescription/>
</FXSpot>
<FXSpot>
<CurveId>EURJPY</CurveId>
<CurveDescription/>
</FXSpot>
</FXSpots>

Listing 223: FXSpot Configuration

7.8.15 Securities
Listing 224 shows the configuration of the Securities. Each Security name is associated
with
• an optional SpreadQuote
• an optional RecoveryRateQuote. Usually a pricer will fall back on the recovery
rate associated to the credit curve involved in the pricing if no security specific
recovery rate is given. If no credit curve is given either, a zero recovery rate will
be assumed.
If no configuration is given for a security, in general a pricer will assume as zero spread
and recovery rate. Notice that in this case the spread and recovery will not be
simulated and therefore also be excluded from the sensitivity and stress analysis.
<Securities>
<Security>
<CurveId>SECURITY_1</CurveId>
<CurveDescription>Security</CurveDescription>
<SpreadQuote>BOND/YIELD_SPREAD/SECURITY_1</SpreadQuote>
<RecoveryRateQuote>RECOVERY_RATE/RATE/SECURITY_1</RecoveryRateQuote>

278
 </Security>
</Securities>

Listing 224: Security Configuration

7.8.16 Correlations
Listing 225 shows the configuration of the Correlations. The Correlation type can be
either CMSSpread or Generic. The former one is to configure the correlation between
two CMS indexes, the latter one is to generally configure the correlation between two
indexes, e.g. between a CMS index and a IBOR index. Currently only ATM
correlation curves or Flat correlation structures are supported. Correlation quotes may
be loaded directly (by setting QuoteType to RATE) or calibrated from prices (set
QuoteType to PRICE). Moreover a flat zero correlation curve can be loaded (by
setting QuoteType to NULL). In this case market quotes are not needed to be
provided. Currently only CMSSpread correlations can be calibrated. This is done
using CMS Spread Options, and requires a CMSSpreadOption convention,
SwaptionVolatility and DiscountCurve to be provided. OptionTenors can be a comma
separated list of periods, 1Y,2Y etc, or a * to indicate a wildcard. If a wildcard is
provided, all relevant market data quotes are used.
<Correlations>
<Correlation>
<CurveId>EUR-CORR</CurveId>
<CurveDescription>EUR CMS correlations</CurveDescription>
<!--CMSSpread, Generic-->
<CorrelationType>CMSSpread</CorrelationType>
<Index1>EUR-CMS-10Y</Index1>
<Index2>EUR-CMS-2Y</Index2>
<!--Conventions, SwaptionVolatility and DiscountCurve only required when QuoteType = PRICE-->
<Conventions>EUR-CMS-10Y-2Y-CONVENTION</Conventions>
<SwaptionVolatility>EUR</SwaptionVolatility>
<DiscountCurve>EUR-EONIA</DiscountCurve>
<Currency>EUR</Currency>
<!-- ATM, Constant -->
<Dimension>ATM</Dimension>
<!-- RATE, PRICE, NULL -->
<QuoteType>PRICE</QuoteType>
<Extrapolation>true</Extrapolation>
<!-- Day counter for date to time conversion -->
<DayCounter>Actual/365 (Fixed)</DayCounter>
<!--Ccalendar and Business day convention for option tenor to date conversion -->
<Calendar>TARGET</Calendar>
<BusinessDayConvention>Following</BusinessDayConvention>
<OptionTenors>1Y,2Y</OptionTenors>
</Correlation>

Listing 225: Correlation Configuration

7.8.17 Commodity Curves

Commodity Curves are setup as price curves in ORE, meaning that they return a price
for a given time t rather than a rate or discount factor, these curves are common in
commodities and can be populated with futures prices directly.

279
Listing 226 shows the configuration of Commodity curves built from futures prices, in
this example WTI Oil prices, note there is no spot price in this configuration, rather
we have a set of futures prices only.
<CommodityCurve>
<CurveId>WTI_USD</CurveId>
<CurveDescription>WTI USD price curve</CurveDescription>
<Currency>USD</Currency>
<Quotes>
<Quote>COMMODITY_FWD/PRICE/WTI/USD/2016-06-30</Quote>
<Quote>COMMODITY_FWD/PRICE/WTI/USD/2016-07-31</Quote>
...
</Quotes>
<DayCounter>A365</DayCounter>
<InterpolationMethod>Linear</InterpolationMethod>
<Extrapolation>true</Extrapolation>
</CommodityCurve>

Listing 226: Commodity Curve Configuration for WTI Oil

Listing 227 shows the configuration for a Precious Metal curve using FX style spot and
forward point quotes, note that SpotQuote is used in this case. The different
interpretation of the forward quotes is controlled by the conventions.
<CommodityCurve>
<CurveId>XAU</CurveId>
<CurveDescription>Gold USD price curve</CurveDescription>
<Currency>USD</Currency>
<SpotQuote>COMMODITY/PRICE/XAU/USD</SpotQuote>
<Quotes>
<Quote>COMMODITY_FWD/PRICE/XAU/USD/ON</Quote>
<Quote>COMMODITY_FWD/PRICE/XAU/USD/TN</Quote>
<Quote>COMMODITY_FWD/PRICE/XAU/USD/SN</Quote>
<Quote>COMMODITY_FWD/PRICE/XAU/USD/1W</Quote>
...
</Quotes>
<DayCounter>A365</DayCounter>
<InterpolationMethod>Linear</InterpolationMethod>
<Conventions>XAU</Conventions>
<Extrapolation>true</Extrapolation>
</CommodityCurve>

Listing 227: Commodity Curve Configuration for Gold in USD

The meaning of each of the top level elements is given below. If an element is labelled
as ’Optional’, then it may be excluded or included and left blank.
• CurveId: Unique identifier for the curve.
• CurveDescription: A description of the curve. This field may be left blank.
• Currency: The commodity curve currency.
• SpotQuote [Optional]: The spot price quote, if omitted then the spot value will
be interpolated.
• Quotes: forward price quotes. These can be a futures price or forward points.

280
 • DayCounter: The day count basis used internally by the curve to calculate the
time between dates.
• InterpolationMethod [Optional]: The variable on which the interpolation is
performed. The allowable values are Linear, LogLinear, Cubic, Hermite,
LinearFlat, LogLinearFlat, CubicFlat, HermiteFlat, BackwardFlat. This is
different to yield curves above in that Flat versions of the standard methods are
defined, with each of these if there is no Spot price than any extrapolation
between T0 and the first future price will be flat (i.e. the first future price will be
copied back "Flat" to T0 ). If the element is omitted or left blank, then it defaults
to Linear.
• Conventions [Optional]: The conventions to use, if omited it is assumed that
these quotes are Outright prices.
• Extrapolation [Optional]: Set to True or False to enable or disable extrapolation
respectively. If the element is omitted or left blank, then it defaults to True.
Alternatively commodity curves can be set up as a commodity curve times the ratio of
two yield curves as shown in listing 228. This can be used to setup commodity curves
in different currencies, for example Gold in EUR (XAUEUR) can be built from a Gold
in USD curve and then the ratio of the EUR and USD discount factors at each pillar.
This is akin to crossing FX forward points to get FX forward prices for any pair.
<CommodityCurve>
<CurveId>XAUEUR</CurveId>
<CurveDescription>Gold EUR price curve</CurveDescription>
<Currency>EUR</Currency>
<BasePriceCurve>XAU</BasePriceCurve>
<BaseYieldCurve>USD-FedFunds</BaseYieldCurve>
<YieldCurve>EUR-IN-USD</YieldCurve>
<Extrapolation>true</Extrapolation>
</CommodityCurve>

Listing 228: Commodity Curve Configuration for Gold in EUR

Commodity curves may also be set up using a base future price curve and a set of
future basis quotes to give an outright price curve. There are a number of options here
depending on whether the base future and basis future are averaging or not averaging.
Whether or not the base future and basis future is averaging is determined from the
conventions supplied in the BasePriceConventions and BasisConventions fields.
• The base future is not averaging and the basis future is not averaging. The
commodity curve that is built gives the outright price of the non-averaging
future. An example of this is the CME Henry Hub future contract, symbol NG,
and the various locational gas basis future contracts, e.g. ICE Waha Basis
Future, symbol WAH. Listing 229 demonstrates an example set-up for this curve.
The curve that is built will give the ICE Waha outright price on the basis
contract’s expiry dates.
• The base future is not averaging and the basis future is averaging. The
commodity curve that is built gives the outright price of the averaging future. In
this case, if the AverageBase field is true the base price will be averaged from
and excluding one basis future expiry to and including the next basis future

281
 expiry. An example of this is the CME Light Sweet Crude Oil future contract,
symbol CL, and the various locational oil basis future contracts, e.g. CME WTI
Midland (Argus) Future, symbol FF. Listing 230 demonstrates an example
set-up for this curve. The curve that is built will give the outright average price
of WTI Midland (Argus) over the calendar month. If the AverageBase field is
false, the base price is not averaged and the basis is added to the base price to
give a curve that can be queried on an expiry date for an average price. An
example of this is a curve built for the average of the daily prices published by
Gas Daily using the ICE futures that reference the difference between the Inside
FERC price and the average Gas Daily price.
• The base future is averaging and the basis future is averaging. The commodity
curve that is built gives the outright price of the averaging future. The set-up is
identical to that outlined in Listings 229 and 230.
• The base future is averaging and the basis future is not averaging. This
combination is not currently supported.
<CommodityCurve>
<CurveId>ICE:WAH</CurveId>
<Currency>USD</Currency>
<BasisConfiguration>
<BasePriceCurve>NYMEX:NG</BasePriceCurve>
<BasePriceConventions>NYMEX:NG</BasePriceConventions>
<BasisQuotes>
<Quote>COMMODITY_FWD/PRICE/ICE:WAH/*</Quote>
</BasisQuotes>
<BasisConventions>ICE:WAH</BasisConventions>
<DayCounter>A365</DayCounter>
<InterpolationMethod>LinearFlat</InterpolationMethod>
<AddBasis>true</AddBasis>
</BasisConfiguration>
<Extrapolation>true</Extrapolation>
</CommodityCurve>

Listing 229: Commodity curve configuration for ICE Waha

<CommodityCurve>
<CurveId>NYMEX:FF</CurveId>
<Currency>USD</Currency>
<BasisConfiguration>
<BasePriceCurve>NYMEX:CL</BasePriceCurve>
<BasePriceConventions>NYMEX:CL</BasePriceConventions>
<BasisQuotes>
<Quote>COMMODITY_FWD/PRICE/NYMEX:FF/*</Quote>
</BasisQuotes>
<BasisConventions>NYMEX:FF</BasisConventions>
<DayCounter>A365</DayCounter>
<InterpolationMethod>LinearFlat</InterpolationMethod>
<AddBasis>true</AddBasis>
<AverageBase>true</AverageBase>
<PriceAsHistoricalFixing>true</PriceAsHistoricalFixing>
</BasisConfiguration>
<Extrapolation>true</Extrapolation>
</CommodityCurve>

282
Listing 230: Commodity curve configuration for WTI Midland (Argus)
The meaning of the fields in the BasisConfiguration node in Listings 229 and 230
are as follows:
• BasePriceCurve: The identifier for the base future commodity price curve.
• BasePriceConventions: The identifier for the base future contract conventions.
• BasisQuotes: The set of basis quotes to look for in the market. Note that this
can be a single wildcard string as shown in the Listings or a list of explicit
COMMODITY_FWD PRICE quote strings.
• BasisConventions: The identifier for the basis future contract conventions.
• DayCounter: Has the meaning given previously in this section.
• InterpolationMethod [Optional]: Has the meaning given previously in this
section.
• AddBasis [Optional]: This is a boolean flag where true, the default value,
indicates that the basis value should be added to the base price to give the
outright price and false indicates that the basis value should be subtracted from
the base price to give the outright price.
• MonthOffset [Optional]: This is an optional non-negative integer value. In
general, the basis contract period and the base contract period are equal, i.e. the
value of the March basis contract for ICE Waha will be added to the value of thr
March contract for CME NG. If for contracts with a monthly cycle or greater,
the base contract month is n months prior to the basis contract month, the
MonthOffset should be set to n. The default value if omitted is 0.
• PriceAsHistoricalFixing [Optional]: This is a boolean flag where true, the
default value, indicates that the historical fixings are prices of the underlying. If
set to false, the fixings are basis spreads and ORE will convert them into prices
by adding the corresponding base index fixings.
A commodity curve may also be set up as a piecewise price curve involving sets of
quotes e.g. direct future price quotes, future price quotes that are the average of other
future prices over a period, future price quotes that are the average of spot price over a
period etc. This is particularly useful for cases where there are future contracts with
different cycles. For example, in the power markets, there are daily future contracts at
the short end and monthly future contracts that average the daily prices over the
month at the long end. An example of such a set-up is shown in Listing 231.
<CommodityCurve>
<CurveId>ICE:PDQ</CurveId>
<Currency>USD</Currency>
<PriceSegments>
<PriceSegment>
<Type>Future</Type>
<Priority>1</Priority>
<Conventions>ICE:PDQ</Conventions>
<Quotes>
<Quote>COMMODITY_FWD/PRICE/ICE:PDQ/*</Quote>

283
 </Quotes>
</PriceSegment>
<PriceSegment>
<Type>AveragingFuture</Type>
<Priority>2</Priority>
<Conventions>ICE:PMI</Conventions>
<Quotes>
<Quote>COMMODITY_FWD/PRICE/ICE:PMI/*</Quote>
</Quotes>
</PriceSegment>
</PriceSegments>
<DayCounter>A365</DayCounter>
<InterpolationMethod>LinearFlat</InterpolationMethod>
<Extrapolation>true</Extrapolation>
<BootstrapConfig>...</BootstrapConfig>
</CommodityCurve>

Listing 231: Commodity curve configuration for PJM Real Time Peak
The BootstrapConfig node is described in Section 7.8.19. The remaining nodes in
Listing 231 have been described already in this section. The meaning of each of the
fields in the PriceSegment node in Listing 231 is as follows:
• Type: The type of the future contract for which quotes are being provided in the
current PriceSegment. The allowable values are:
– Future: This indicates that the quote is a straight future contract price
quote.
– AveragingFuture: This indicates that the quote is for a future contract
price that is the average of other future contract prices over a given period.
The averaging period for each quote and other conventions are given in the
associated conventions determined by the Conventions node.
– AveragingSpot: This indicates that the quote is for a future contract price
that is the average of spot prices over a given period. The averaging period
for each quote and other conventions are given in the associated conventions
determined by the Conventions node.
• Priority [Optional]: An optional non-negative integer giving the priority of the
current PriceSegment relative to the other PriceSegments when there are
quotes for contracts with the same expiry dates in those segments. Values closer
to zero indicate higher priority i.e. quotes in this segment are given priority in
the event of clashes. If omitted, the PriceSegments are currently read in the
order that they are provided in the XML so that quotes in segments appearing
earlier in the XML will be given preference in the case of clashes.
• Conventions: The identifier for the future contract conventions associated with
the quotes in the PriceSegment. Details on these conventions are given in
Section 7.12.20.
• Quotes: The set of future price quotes to look for in the market. Note that this
can be a single wildcard string as shown in the Listing 231 or a list of explicit
COMMODITY_FWD PRICE quote strings.

284
7.8.18 Commodity Volatilities
The following types of commodity volatility structures are supported in ORE:
• A constant volatility structure giving the same single volatility for all expiry
times and strikes.
• A one-dimensional expiry dependent volatility structure i.e. the volatility
returned is dependent on the time to option expiry but does not change with
option strike.
• A two-dimensional volatility structure with a dependence on both expiry and
strike. There is support for absolute strikes, delta strikes and moneyness strikes.
• An average price option (APO) volatility surface. In particular, this structure
returns the volatility of an average price that can then be used directly in the
Black 76 formula to give the value of the APO.
Listing 232 outlines the configuration for a constant volatility structure.
<CommodityVolatility>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>
<Currency>...</Currency>
<Constant>
<Quote>...</Quote>
</Constant>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
</CommodityVolatility>

Listing 232: Constant commodity volatility configuration

The meaning of each of the elements is as follows:
• CurveId: Unique identifier for the curve.
• CurveDescription: A description of the curve. This field may be left blank.
• Currency: The commodity curve currency.
• Quote: The single quote giving the constant volatility.
• DayCounter [Optional]: The day count basis used internally by the curve to
calculate the time between dates. If omitted it defaults to A365.
• Calendar [Optional]: The calendar used internally by the volatility structure to
amend dates generated from option tenors i.e. if a volatility is requested from the
surface using an expiry tenor. If omitted it defaults to NullCalendar meaning
there is no adjustment to the expiry on applying the option tenor.
Listing 233 outlines the configuration for the one-dimensional expiry dependent
volatility curve.
<CommodityVolatility>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>
<Currency>...</Currency>

285
 <Curve>
<QuoteType>...</QuoteType>
<VolatilityType>...</VolatilityType>
<ExerciseType>...</ExerciseType>
<Quotes>
<Quote>...</Quote>
<Quote>...</Quote>
...
</Quotes>
<Interpolation>...</Interpolation>
<Extrapolation>...</Extrapolation>
<EnforceMontoneVariance>...</EnforceMontoneVariance>
</Curve>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<FutureConventions>...</FutureConventions>
<OptionExpiryRollDays>...</OptionExpiryRollDays>
</CommodityVolatility>

Listing 233: Commodity volatility curve configuration

The meaning of each of the elements is given below. Elements that were defined for the
previous configuration and are common to all of the configurations are not repeated.
• QuoteType [Optional]: The allowable values in general for QuoteType are
ImpliedVolatility and Premium. Currently, only ImpliedVolatility is
supported for commodity volatility curves. This is the default for QuoteType so
this node may be omitted.
• VolatilityType [Optional]: The allowable values in general for VolatilityType
are Lognormal, ShiftedLognormal and Normal. Currently, only Lognormal is
supported for commodity volatility curves. This is the default for
VolatilityType so this node may be omitted.
• ExerciseType [Optional]: This node is described below in the context of
surfaces. For commodity volatility curves, it is ignored and should be omitted.
• Quotes: A list of commodity option volatility quotes with different expiries to
use in the commodity curve building. The commodity option volatility quotes are
explained in Section 10.28. As indicated above, any quote string used here much
start with COMMODITY_OPTION/RATE_LNVOL. A single regular expression Quote is
also supported here in place of a list of explicit Quote strings. Note that if a list
of explicit Quote strings are provided, it is an error to have a duplicated option
expiry date. If a regular expression is used, the first quote found is used and
subsequent qutoes with the same expiry are discarded with a warning issued.
• Interpolation: The interpolation to use to give volatilities between option
expiry times. The allowable values are Linear, Cubic and LogLinear. Note that
the interpolation here is on the variance.
• Extrapolation: The extrapolation to use to give volatilities after the last expiry
date in the variance curve. The allowable values are None, UseInterpolator,
Linear and Flat. However, all options except None yield the same extrapolation
i.e. flat extrapolation in the volatility. None disables extrapolation so that an
exception is raised if the curve is queried after the last expiry for a volatility.

286
 Note that as the curve is parameterised in variance, interpolation is used to
interpolate between time zero where the variance is zero and the first expiry time.
• EnforceMontoneVariance [Optional]: Boolean parameter that should be set to
true to raise an exception if the implied variance curve is not montone increasing
with time. It should be set to false to suppress such an exception. The default
value if omitted is true.
• FutureConventions [Optional]: Depending on the quotes that are provided in
the Quotes section, a CommodityFuture convention may be needed in order to
derive an option expiry date from the Expiry portion of the commodity option
quote. In particular, as outlined in Section 10.28, the Expiry portion of a
commodity option quote allows for continuation expiries of the form cN. The N is
a positive integer meaning the N-th next expiry after the valuation date on which
we are building the commodity volatility curve. When a continuation expiry is
used in a quote, the FutureConventions is needed and gives the ID of the
conventions associated with the commodity for which we are trying to build the
volatility curve. These conventions are used to determine the explicit expiry date
for the given option quote from the continuation expiry.
• OptionExpiryRollDays [Optional]: The OptionExpiryRollDays can be any
non-negative integer and may be needed when deriving an option expiry date
from the Expiry portion of the commodity option quote. If the Expiry portion of
the commodity option quote is a continuation expiry, an explicit expiry date is
deduced as explained in the previous bullet point. Additionally, in some cases,
the option quotes for the next option expiry may stop a number of business days
before that option expiry and the cN expiry in this period begins referring to the
N+1-th next option expiry. As an example, assume dv is the valuation date and
e1 = dv is the next option expiry date. If OptionExpiryRollDays is 0 then a
commodity option quote with an Expiry portion equal to c1 on dv indicates that
the option quote is for an option with expiry date equal to e1 . However, if
OptionExpiryRollDays is 1, a commodity option quote with an Expiry portion
equal to c1 on dv indicates that the option quote is for an option with expiry date
equal to e2 where e2 is the next option expiry date after e1 . In other words, with
OptionExpiryRollDays set to 1 the option quotes for expiry date e1 stopped on
the business day before e1 . If omitted, OptionExpiryRollDays defaults to 0.
Listing 234 outlines the configuration for the two-dimensional expiry and absolute
strike commodity option surface.
<CommodityVolatility>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>
<Currency>...</Currency>
<StrikeSurface>
<QuoteType>...</QuoteType>
<VolatilityType>...</VolatilityType>
<ExerciseType>...</ExerciseType>
<Strikes>...</Strikes>
<Expiries>...</Expiries>
<TimeInterpolation>...</TimeInterpolation>
<StrikeInterpolation>...</StrikeInterpolation>
<Extrapolation>...</Extrapolation>

287
 <TimeExtrapolation>...</TimeExtrapolation>
<StrikeExtrapolation>...</StrikeExtrapolation>
</StrikeSurface>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<FutureConventions>..</FutureConventions>
<OptionExpiryRollDays>...</OptionExpiryRollDays>
<PriceCurveId>...</PriceCurveId>
<YieldCurveId>...</YieldCurveId>
<OneDimSolverConfig>
<MaxEvaluations>100</MaxEvaluations>
<InitialGuess>0.35</InitialGuess>
<Accuracy>0.0001</Accuracy>
<MinMax>
<Min>0.0001</Min>
<Max>2.0</Max>
</MinMax>
</OneDimSolverConfig>
<PreferOutOfTheMoney>...</PreferOutOfTheMoney>
<QuoteSuffix>...</QuoteSuffix>
</CommodityVolatility>

Listing 234: Expiry and absolute strike commodity option surface configuration
The meaning of each of the elements is given below. Again, nodes explained in the
previous configuration are not repeated here.
• QuoteType [Optional]: As above, the allowable values for QuoteType are
ImpliedVolatility and Premium. If omitted, the default is
ImpliedVolatility. If the QuoteType is Premium, a volatility surface will be
stripped from option premium quotes. Note that Premium is only allowed if one
or both of Strikes or Expiries below is set to the single wildcard value *. In
other words, if we explicitly specify all of the strikes and expiries, we can only
build a volatility surface directly and the QuoteType must be
ImpliedVolatility.
• VolatilityType [Optional]: As above, the allowable values for VolatilityType
are Lognormal, ShiftedLognormal and Normal. This is only needed if
QuoteType is ImpliedVolatility. Currently, only Lognormal is supported for
commodity volatility surfaces. This is the default for VolatilityType so this
node may be omitted.
• ExerciseType [Optional]: The allowable values for ExerciseType are European
and American. This is only needed if QuoteType is Premium and indicates if the
option premium quotes are American or European exercise. If omitted the
default is European.
• Strikes: This can be a single wildcard value * or a comma separated list of
explicit strike prices. We explain below how these strikes are combined with the
other parameters in the configuration to give a list of commodity option quotes
to search for in the market data.
• Expiries: This can be a single wildcard value * or a comma separated list of
expiry strings. We explain below how these expiries are combined with the other
parameters in the configuration to give a list of commodity option quotes to

288
 search for in the market data. Note that as outlined in Section 10.28, the Expiry
portion of the commodity option quote may be an explicit expiry date, an expiry
tenor or a continuation expiry of the form cN explained in the volatility curve
section above.
• TimeInterpolation: Indicates the interpolation in the time direction. There are
quite a number of restrictions here. If either Strikes or Expiries use the single
wildcard value *, the interpolation in both the time and strike direction is linear
regardless of the value passed here in the TimeInterpolation node. If neither
Strikes nor Expiries use the single wildcard value *, TimeInterpolation may
be set to Linear or Cubic but StrikeInterpolation must have the same value.
If it does not, then Linear is used for both. In other words, if neither Strikes
nor Expiries use the single wildcard value *, we can configure bilinear or bicubic
interpolation. Again, in all cases, the interpolation is carried out on the variance.
• StrikeInterpolation: Indicates the interpolation in the strike direction. The
requirements are exactly as outlined for the TimeInterpolation node.
• Extrapolation: A boolean value indicating if extrapolation is allowed.
• TimeExtrapolation: Indicates the extrapolation in the time direction. The
allowable values are None, UseInterpolator, Linear and Flat. If neither
Strikes nor Expiries use the single wildcard value *, the extrapolation in the
time direction is flat regardless of the value passed here. If either Strikes or
Expiries use the single wildcard value *, both Flat and None give flat
extrapolation in the time direction whereas UseInterpolator and Linear
indicate that the configured interpolation (linear or cubic) should be continued in
the time direction in order to extrapolate. Linear is only allowable here for
backward compatibility and UseInterpolator should be preferred for clarity.
• StrikeExtrapolation: Indicates the extrapolation in the strike direction. The
allowable values are None, UseInterpolator, Linear and Flat. Both Flat and
None give flat extrapolation in the strike direction. UseInterpolator and Linear
indicate that the configured interpolation (linear or cubic) should be continued in
the strike direction in order to extrapolate. Linear is only allowable here for
backward compatibility and UseInterpolator should be preferred for clarity.
• PriceCurveId [Optional]: The ID of a price curve for the commodity of the form
Commodity/{CCY}/{NAME}. This is needed if the QuoteType is Premium. It is also
needed when the QuoteType is ImpliedVolatility if either Strikes or
Expiries use the single wildcard value * and both call and put quotes are found
in the market for the same expiry and strike pair. In this case, it is needed to
determine which quotes to use based on the value of the PreferOutOfTheMoney
node.
• YieldCurveId [Optional]: The ID of a yield curve in the currency of the
commodity of the form Yield/{CCY}/{NAME}. This is needed if the QuoteType is
Premium in the stripping of the volatilities from premia.
• OneDimSolverConfig [Optional]: This is used if the QuoteType is Premium. It
provides the options for the root search in the stripping of the volatilities from
premia. If omitted, the default set of options shown in Listing 234 are used. The

289
 MinMax node can be replaced with a single Step node that accepts a double
giving the step size to use in the root search.
• PreferOutOfTheMoney [Optional]: A node accepting a boolean value. If set to
true, quotes for out of the money options are preferred where a call and a put
quote are found for the same expiry strike pair. If set to false, quotes for in the
money options are preferred where a call and a put quote are found for the same
expiry strike pair. If omitted, true is assumed.
• QuoteSuffix [Optional]: The allowable values are C and P indicating Call and
Put respectively. If given, they are used in the construction of the commodity
option quote strings as explained below. They are useful in cases where the
market data contains both call and put volatility quotes for the same expiry
strike pair and you want to use only the calls (set QuoteSuffix to C) or the puts
(set QuoteSuffix to P).
As mentioned above, a number of parameters from the two-dimensional expiry and
absolute strike configuration are used in constructing the commodity option quote
strings that are looked up in the market data. There are two cases:
1. Both the Strikes and Expiries node provide a comma separated list of values.
As mentioned above, we can only use a QuoteType of ImpliedVolatility in this
case where we have explicit expiries and strikes and the VolatilityType must
be Lognormal. For example, assume the Expiries node has the set of values
e_1,e_2,...,e_N and that the Strikes node has the set of values
s_1,s_2,...,s_M. For each of the N × M expiry strike pairs (en , sm ), a quote of
the form COMMODITY_OPTION/RATE_LNVOL/{N}/{C}/e_n/s_m[/{S}] is created to
be looked up in the market data. {N} is the value in the CurveId node, {C} is
the value in the Currency node and {S} is the value in the QuoteSuffix node if
given. This explicit grid of volatility quotes must be present in the market for
the commodity volatility surface to be constructed.
2. One or both of the Strikes and Expiries node use a single wildcard value *. As
mentioned above, the QuoteType can be ImpliedVolatility or Premium in this
case. As above, assume the Expiries node has the set of values
e_1,e_2,...,e_N and that the Strikes node has the set of values
s_1,s_2,...,s_M. The additional constraint here is that N = 1 and e_1 is * or
that M = 1 and s_1 is *, or both. For each of the N × M expiry strike pairs
(en , sm ), a quote of the form COMMODITY_OPTION/{T}/{N}/{C}/e_n/s_m[/{S}]
is created to be looked up in the market data. {T} is PRICE when QuoteType is
Premium and is RATE_LNVOL when QuoteType is ImpliedVolatility, {N} is the
value in the CurveId node, {C} is the value in the Currency node and {S} is the
value in the QuoteSuffix node if given. Any quote in the market with a name
matching any of the quote strings formed in this way are then included in the
commodity volatility curve building. Note that the QuoteSuffix has no effect in
this case and should be omitted i.e. it is only used in the case of an explicit grid
of quotes above.
Listing 235 outlines the configuration for the two-dimensional expiry and moneyness
strike commodity option surface. This is similar to the absolute strike surface
configuration above but currently only supports a QuoteType of ImpliedVolatility

290
i.e. QuoteType of Premium is not supported. Also, the VolatilityType must be
Lognormal. Both forward and spot moneyness is supported.
<CommodityVolatility>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>
<Currency>...</Currency>
<MoneynessSurface>
<QuoteType>...</QuoteType>
<VolatilityType>...</VolatilityType>
<ExerciseType>...</ExerciseType>
<MoneynessType>...</MoneynessType>
<MoneynessLevels>...</MoneynessLevels>
<Expiries>...</Expiries>
<TimeInterpolation>...</TimeInterpolation>
<StrikeInterpolation>...</StrikeInterpolation>
<Extrapolation>...</Extrapolation>
<TimeExtrapolation>...</TimeExtrapolation>
<StrikeExtrapolation>...</StrikeExtrapolation>
<FuturePriceCorrection>...</FuturePriceCorrection>
</MoneynessSurface>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<FutureConventions>..</FutureConventions>
<OptionExpiryRollDays>...</OptionExpiryRollDays>
<PriceCurveId>...</PriceCurveId>
<YieldCurveId>...</YieldCurveId>
</CommodityVolatility>

Listing 235: Expiry and moneyness strike commodity option surface configuration
The meaning of each of the elements is given below. Again, nodes explained in the
previous configuration are not repeated here.
• MoneynessType: The allowable values are Spot for spot moneyness and Fwd for
forward moneyness.
• MoneynessLevels: This must be a comma separated list of moneyness values. A
moneyness value of 1 indicates a strike equal to spot or forward depending on the
value given in the MoneynessType node.
• TimeInterpolation: Only Linear is currently supported here.
• StrikeInterpolation: Only Linear is currently supported here.
• Extrapolation: A boolean value indicating if extrapolation is allowed.
• TimeExtrapolation: Only Flat is currently supported here giving flat
extrapolation of the volatility.
• StrikeExtrapolation: Indicates the extrapolation in the strike direction. The
allowable values are None, UseInterpolator, Linear and Flat. Both Flat and
None give flat extrapolation in the strike direction. UseInterpolator and
Linear indicate that the configured interpolation (linear) should be continued in
the strike direction in order to extrapolate.
• FuturePriceCorrection [Optional]: This is a boolean flag that defaults to true.

291
 In most cases, for options on futures, the option expiry date is a short period
before the future expiry. If there is an arbitrary interpolation applied to the
future price curve, the future price on the option expiry date may not equal the
associated future price. If FuturePriceCorrection is true, this is corrected i.e.
the future price on option expiry is the associated future price for the future
expiry date. Note that a valid FutureConventions is needed for the correction
to be applied.
• PriceCurveId: This is required for both a spot and forward moneyness surface.
• YieldCurveId: This is required for a forward moneyness surface.
Note that, similar to the procedure outlined above for the absolute strike surface,
quote strings of the form COMMODITY_OPTION/RATE_LNVOL/{N}/{C}/e_n/MNY/{T}/l_m
are created from the moneyness configuration to be looked up in the market. Here, l_m
are the moneyness levels for m = 1, . . . , M and {T} is the moneyness type i.e. either
Spot or Fwd.
Listing 236 outlines the configuration for the two-dimensional expiry and delta strike
commodity option surface. Similar to the moneyness strike surface configuration
above, this currently only supports a QuoteType of ImpliedVolatility i.e. QuoteType
of Premium is not supported. Also, the VolatilityType must be Lognormal. Various
delta and ATM types are supported.
<CommodityVolatility>
<CurveId>...</CurveId>
<CurveDescription>...</CurveDescription>
<Currency>...</Currency>
<DeltaSurface>
<QuoteType>...</QuoteType>
<VolatilityType>...</VolatilityType>
<ExerciseType>...</ExerciseType>
<DeltaType>...</DeltaType>
<AtmType>...</AtmType>
<AtmDeltaType>...</AtmDeltaType>
<PutDeltas>...</PutDeltas>
<CallDeltas>...</CallDeltas>
<Expiries>...</Expiries>
<TimeInterpolation>...</TimeInterpolation>
<StrikeInterpolation>...</StrikeInterpolation>
<Extrapolation>...</Extrapolation>
<TimeExtrapolation>...</TimeExtrapolation>
<StrikeExtrapolation>...</StrikeExtrapolation>
<FuturePriceCorrection>...</FuturePriceCorrection>
</DeltaSurface>
<DayCounter>...</DayCounter>
<Calendar>...</Calendar>
<FutureConventions>..</FutureConventions>
<OptionExpiryRollDays>...</OptionExpiryRollDays>
<PriceCurveId>...</PriceCurveId>
<YieldCurveId>...</YieldCurveId>
</CommodityVolatility>

Listing 236: Expiry and delta strike commodity option surface configuration
The meaning of each of the elements is given below. Again, nodes explained in the

292
previous configuration are not repeated here.
• DeltaType: The allowable supported values are Spot for spot delta Fwd for
forward delta.
• AtmType: The allowable supported values are AtmSpot, AtmFwd and
AtmDeltaNeutral.
• AtmDeltaType [Optional]: This is only needed if the AtmType is
AtmDeltaNeutral.
• PutDeltas: A comma separated list of one or more put deltas to use in the
volatility surface. Note that the put deltas should be given without a sign e.g.
<PutDeltas>0.10,0.20,0.30,0.40</PutDeltas> would be an example.
• CallDeltas: A comma separated list of one or more call deltas to use in the
volatility surface.
• Expiries: A comma separated list of one or more expiries (e.g. 1W, 1M) to
load. Supports using the single wildcard value *.
• TimeInterpolation: Only Linear is currently supported here.
• StrikeInterpolation: Allowable values are Linear, NaturalCubic,
FinancialCubic and CubicSpline.
• Extrapolation: A boolean value indicating if extrapolation is allowed.
• TimeExtrapolation: Only Flat is currently supported here giving flat
extrapolation of the volatility.
• StrikeExtrapolation: Indicates the extrapolation in the strike direction. The
allowable values are None, UseInterpolator, Linear and Flat. Both Flat and
None give flat extrapolation in the strike direction. UseInterpolator and
Linear indicate that the configured interpolation should be continued in the
strike direction in order to extrapolate.
• PriceCurveId: This is required for a delta surface.
• YieldCurveId: This is required for a delta surface.
Note that, similar to the procedure outlined above for the absolute strike surface,
quote strings are created from the configuration to be looked up in the market. For the
put deltas, quote strings of the form
COMMODITY_OPTION/RATE_LNVOL/{N}/{C}/e_n/DEL/{T}/Put/d_m are created. Here,
d_m are the PutDeltas and {T} is the delta type i.e. either Spot or Fwd. Similarly for
the call deltas, quote strings of the form
COMMODITY_OPTION/RATE_LNVOL/{N}/{C}/e_n/DEL/{T}/Call/d_j are created where
d_j are the CallDeltas. For ATM, quote strings of the form
COMMODITY_OPTION/RATE_LNVOL/{N}/{C}/e_n/DEL/ATM/{A}[/DEL/{T}] are created
where {A} is the AtmType i.e. AtmSpot, AtmFwd or AtmDeltaNeutral and {T} is the
optional delta type.
Also, it is worth adding a note here on the interpolation for a delta based surface.
Assume we want the volatility at time t and absolute strike s i.e. at the (t, s) node.
For the maturity time t, a delta "slice" i.e. a set of (delta, vol) pairs for that time t, is

293
obtained by interpolating, or extrapolating, the variance in the time direction on each
delta column. Then for each (delta, vol) pair at time t, an absolute strike value is
deduced to give a slice at time t in terms of absolute strike i.e. a set of (strike, vol)
pairs at time t. This strike versus volatility curve is then interpolated, or extrapolated,
to give the vol at the (t, s).
Listing 237 outlines the configuration for the APO volatility surface. This currently
only supports a QuoteType of ImpliedVolatility and VolatilityType must be
Lognormal. This configuration takes a base commodity volatility surface and builds a
surface that can be queried for volatilities to price APOs directly i.e. using the
volatility directly in a Black 76 formula along with the average future price. It uses the
approach described in the Section entitled Commodity Average Price Option - Future
Settlement Prices in the Product Catalogue to go from future option volatilities to
APO volatilities.
We describe here briefly a motivating example encountered in practice. We have
commodity APOs where the underlying is WTI Midland Argus averaged over the
calendar month. We do not have direct volatilities for these APO contracts. We have a
price curve for the average of WTI Midland Argus over the calendar month from the
futures market. We can use the volatility surface that we have for CME WTI to build
an APO surface for WTI Midland Argus. Listing 237 shows the configuration used in
this context.
<CommodityVolatility>
<CurveId>WTI_MIDLAND</CurveId>
<CurveDescription>WTI Midland (CAL) APO surface</CurveDescription>
<Currency>USD</Currency>
<ApoFutureSurface>
<QuoteType>ImpliedVolatility</QuoteType>
<VolatilityType>Lognormal</VolatilityType>
<MoneynessLevels>0.50,0.75,1.00,1.25,1.50</MoneynessLevels>
<VolatilityId>CommodityVolatility/USD/WTI</VolatilityId>
<PriceCurveId>Commodity/USD/WTI</PriceCurveId>
<FutureConventions>WTI</FutureConventions>
<TimeInterpolation>Linear</TimeInterpolation>
<StrikeInterpolation>Linear</StrikeInterpolation>
<Extrapolation>true</Extrapolation>
<TimeExtrapolation>Flat</TimeExtrapolation>
<StrikeExtrapolation>Flat</StrikeExtrapolation>
<MaxTenor>2Y</MaxTenor>
<Beta>0</Beta>
</ApoFutureSurface>
<DayCounter>A365</DayCounter>
<Calendar>CME</Calendar>
<FutureConventions>WTI_MIDLAND</FutureConventions>
<PriceCurveId>Commodity/USD/WTI_MIDLAND</PriceCurveId>
<YieldCurveId>Yield/USD/USD-FedFunds</YieldCurveId>
</CommodityVolatility>

Listing 237: APO surface configuration

The meaning of each of the elements is given below.
• MoneynessLevels: A comma separated list of the moneyness levels used in the
APO surface construction. Forward moneyness is assumed with a value of 1

294
 indicating a strike equal to the future price.
• VolatilityId: The ID of an existing commodity option surface for options on
the future settlement price referenced in the APOs used in the generation of the
volatilities for this surface.
• PriceCurveId: The ID of an existing commodity price curve for the future
settlement price referenced in the APOs used in the generation of the volatilities
for this surface.
• FutureConventions: This ID of the commodity future conventions for the future
settlement price referenced in the APOs used in the generation of the volatilities
for this surface.
• TimeInterpolation: Only Linear is currently supported here. Note that the
interpolation is in terms of variance.
• StrikeInterpolation: Only Linear is supported here. Note that the
interpolation is in terms of variance.
• Extrapolation: A boolean value indicating if extrapolation is allowed.
• TimeExtrapolation: Only Flat is currently supported here. The flat
extrapolation is in terms of the volatility.
• StrikeExtrapolation: Indicates the extrapolation in the strike direction. The
allowable values are None, UseInterpolator, Linear and Flat. Both Flat and
None give flat extrapolation in the strike direction. UseInterpolator and
Linear indicate that the configured interpolation should be continued in the
strike direction in order to extrapolate.
• PriceCurveId: The ID of an existing commodity price curve giving the average
price for the APO period.
• YieldCurveId: This ID of a yield curve in the currency of the commodity used
for discounting.

7.8.19 Bootstrap Configuration

The BootstrapConfig node, outlined in listing 238, can be added to curve
configurations that use a bootstrap algorithm to alter the default behaviour of the
bootstrap algorithm.
<BootstrapConfig>
<Accuracy>...</Accuracy>
<GlobalAccuracy>...</GlobalAccuracy>
<DontThrow>...</DontThrow>
<MaxAttempts>...</MaxAttempts>
<MaxFactor>...</MaxFactor>
<MinFactor>...</MinFactor>
<DontThrowSteps>...</DontThrowSteps>
</BootstrapConfig>

Listing 238: BootstrapConfig node outline

The meaning of each of the elements is:

295
• Accuracy [Optional]: The accuracy with which the implied quote must match
the market quote for each instrument in the curve bootstrap. This node should
hold a positive real number. If omitted, the default value is 1.0 × 10−12 .
• GlobalAccuracy [Optional]: If the interpolation method in the bootstrap is
global, e.g. cubic spline, the bootstrap routine needs to perform multiple
iterative bootstraps of the curve to converge. After each such bootstrap of the
full curve, the absolute value of the change between the current bootstrap and
previous bootstrap for the curve value at each pillar is calculated. The global
bootstrap is deemed to have converged if the maximum of these changes is less
than the global accuracy or the accuracy from the Accuracy node. This node
should hold a positive real number. If omitted, the global accuracy is set equal to
the accuracy from the Accuracy node. This node is useful in some cases where a
slightly less restrictive accuracy, than that given by the Accuracy node, is needed
for the global bootstrap.
• DontThrow [Optional]: If this node is set to true, the curve bootstrap does not
throw an error when the bootstrap fails at a pillar. Instead, a curve value is
sought at the failing pillar that minimises the absolute value of the difference
between the implied quote and the market quote at that pillar. The minimum is
sought between the minimum and maximum curve value that was used in the
root finding routine that failed at the pillar. The number of steps used in this
search is given by the DontThrowSteps node below. This node should hold a
boolean value. If omitted, the default value is false i.e. the bootstrap throws an
exception at the first pillar where the bootstrap fails.
• MaxAttempts [Optional]: At each pillar, the bootstrap routine searches between a
minimum curve value and a maximum curve value for a curve value that gives an
implied quote that matches the market quote at that pillar. In some cases, the
minimum curve value and maximum curve value are too restrictive and the
bootstrap fails at a pillar. This node determines how many times the bootstrap
should be attempted at each pillar. For example, if the node is set to 1, the
bootstrap uses the minimum curve value and maximum curve value implied in
the code and fails if a root is not found. If this node is set to 2 and the first
attempt fails, the minimum curve value is reduced by a factor specified in the
node MinFactor, the maximum curve value is increased by a factor specified in
the node MaxFactor and a second attempt is made to find a root between the
enlarged bounds. If no root is found, the bootstrap then fails at this pillar. This
node should hold a positive integer. If omitted, the default value is 5.
• MaxFactor [Optional]: This node is used only if MaxAttempts is greater than 1.
The meaning of this node is given in the description of the MaxAttempts node.
This node should hold a positive real number. If omitted, the default value is 2.0.
• MinFactor [Optional]: This node is used only if MaxAttempts is greater than 1.
The meaning of this node is given in the description of the MaxAttempts node.
This node should hold a positive real number. If omitted, the default value is 2.0.
• DontThrowSteps [Optional]: This node is used only if DontThrow is true. The
meaning of this node is given in the description of the DontThrow node. This
node should hold a positive integer. If omitted, the default value is 10.

296
7.8.20 One Dimensional Solver Configuration
The OneDimSolverConfig node, outlined in Listing 239, can be added to certain curve
configurations that lead to a one dimensional solver being used in the curve
construction. For example, the EquityVolatility curve configuration can lead to
equity volatilities being stripped from equity option premiums. In this case, the
OneDimSolverConfig node can be added to the EquityVolatility curve
configuration to indicate how the solver should behave i.e. maximum number of
evaluations, initial guess, accuracy etc. The various options are outlined below.
<OneDimSolverConfig>
<MaxEvaluations>...</MaxEvaluations>
<InitialGuess>...</InitialGuess>
<Accuracy>...</Accuracy>
<MinMax>
<Min>...</Min>
<Max>...</Max>
</MinMax>
<!-- Step only needed if MinMax not provided. -->
<Step>...</Step>
<LowerBound>...</LowerBound>
<UpperBound>...</UpperBound>
</OneDimSolverConfig>

Listing 239: OneDimSolverConfig node outline

The meaning of each of the elements is:
• MaxEvaluations: This node should hold a positive integer. The maximum
number of function evaluations that can be made by the solver.
• InitialGuess: This node should hold a real number. The initial guess used by
the solver.
• Accuracy: This node should hold a positive real number. The accuracy used by
the solver in the root find.
• MinMax [Optional]: A node that holds a Min and a Max node each of which should
hold a real number. This indicates that the solver should search for a root
between the value in Min and the value in Max. The value in Min should
obviously be less than the value in Max. This node is optional. If not provided,
the Step node below should be provided to set up a step based solver.
• Step [Optional]: This node should hold a real number. The validation is a choice
between MinMax and Step so that Step can only be provided if MinMax is not and
vice versa. The value in Step provides the solver with a step size to use in its
search for a root.
• LowerBound [Optional]: This node should hold a real number. It provides a lower
bound for the search domain. If omitted, no lower bound is applied to the search
domain.
• UpperBound [Optional]: This node should hold a real number. It provides an
upper bound for the search domain. If omitted, no upper bound is applied to the
search domain. Obviously, if both LowerBound and UpperBound are provided, the

297
value in LowerBound should be less than the value in UpperBound.

298
7.9 Reference Data [Link]
Reference Data is used to ease the burden on portfolio xml representation, by taking
common elements and storing them as static data. Currently this can be used for Bond
Derivatives that require bond static information.
Bond reference data is also used to build yield curves fitted to liquid bond prices, see
7.8.1.
The allowable types for ReferenceData is
1. Bond static data consists of the Leg data for a given bond.
2. SubType has been added for reporting purposes, to feed into the ISDA product
taxonomy, without impact on pricing.
Valid SubTypes are:
• ABS, Corp(orate), Loans, Muni, Sovereign
• ABX, CMBX, MBX, PrimeX, TRX, iBoxx (in case the Bond represents a
Credit or Bond index)
Note that the SubType field is currently optional and not covered by schema
checks.

<ReferenceData>
<!-- Bond reference datum -->
<ReferenceDatum id="SECURITY_1">
<Type>Bond</Type>
<BondReferenceData>
<SubType>Muni</SubType>
<IssuerId>CPTY_C</IssuerId>
<CreditCurveId>ZERO</CreditCurveId>
<ReferenceCurveId>EURBENCHMARK-EUR-6M</ReferenceCurveId>
<SettlementDays>2</SettlementDays>
<Calendar>TARGET</Calendar>
<IssueDate>20110215</IssueDate>
<LegData>
<LegType>Fixed</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>1</Notional>
</Notionals>
<DayCounter>ActActISMA</DayCounter>
<PaymentConvention>F</PaymentConvention>
<FixedLegData>
<Rates>
<Rate>0.02</Rate>
</Rates>
</FixedLegData>
<ScheduleData>

299
 <Rules>
<StartDate>20190103</StartDate>
<EndDate>20200103</EndDate>
<Tenor>1Y</Tenor>
<Calendar>TARGET</Calendar>
<Convention>U</Convention>
<TermConvention>U</TermConvention>
<Rule>Forward</Rule>
<EndOfMonth/>
<FirstDate/>
<LastDate/>
</Rules>
</ScheduleData>
</LegData>
</BondReferenceData>
</ReferenceDatum>
</ReferenceData>

300
7.10 Ibor Fallback Config: [Link]
The Ibor Fallback Configuration represents the rules for replacing Ibor reference rates
by risk free rates. If no configuration is specified, a standard configuration is used.
Specifying a custom configuration mainly serves testing purposes. The fields are:
• EnableIborFallbacks: If false, Ibor fallbacks are disabled.
• UseRfrCurveInTodaysMarket: If true, the todays market Ibor forwarding curve
for a replaced Ibor index is built using the RfrIndex OIS curve and the Spread.
• UseRfrCurveInSimulationMarket: If true, the simulation market Ibor forward
curve for a replaced Ibor index is built using the RfrIndex OIS curve and the
Spread.
• Fallback: Each Ibor index to be replaced is declared by
– IborIndex: the Ibor index name
– RfrIndex: the rfr index name
– Spread: the spread to apply to the rfr rate
– SwitchDate: the date on which the fallback is used

<IborFallbackConfig>
<GlobalSettings>
<EnableIborFallbacks>true</EnableIborFallbacks>
<UseRfrCurveInTodaysMarket>true</UseRfrCurveInTodaysMarket>
<UseRfrCurveInSimulationMarket>true</UseRfrCurveInSimulationMarket>
</GlobalSettings>
<Fallbacks>
<Fallback>
<IborIndex>CHF-LIBOR-12M</IborIndex>
<RfrIndex>CHF-SARON</RfrIndex>
<Spread>0.0020479999999999999</Spread>
<SwitchDate>2022-01-01</SwitchDate>
</Fallback>
<Fallback>
<IborIndex>CHF-LIBOR-1M</IborIndex>
<RfrIndex>CHF-SARON</RfrIndex>
<Spread>-0.000571</Spread>
<SwitchDate>2022-01-01</SwitchDate>
</Fallback>
....

301
7.11 SIMM Calibration: [Link]
The SIMM Calibration can be used to add or override SIMM versions by specifying the
risk weights, correlations, concentration thresholds along with associated
buckets/labels and currency groups (for risk class FX and IR). See Example_44 for a
full SIMM calibration file for SIMM 2.5A [24].
The file consists of a <SIMMCalibrationData> node, with <SIMMCalibration>
subnodes that each define a given SIMM version, as in Listing 240 below.

Listing 240: SIMM Calibration data

<SIMMCalibrationData>
<SIMMCalibration id="official">
<VersionNames>
<Name>2.6</Name>
<Name>2.5.6</Name>
</VersionNames>
<AdditionalFields>
<SIMM_EffectiveDate>2023-12-02</SIMM_EffectiveDate>
</AdditionalFields>
<InterestRate>
<RiskWeights>
......
</RiskWeights>
<Correlations>
......
</Correlations>
<ConcentrationThresholds>
......
</ConcentrationThresholds>
</InterestRate>
<CreditQualifying>
......
</CreditQualifying>
<CreditNonQualifying>
......
</CreditNonQualifying>
<Equity>
......
</Equity>
<Commodity>
......
</Commodity>
<FX>
......
</FX>
<RiskClassCorrelations>
......
</RiskClassCorrelations>
</SIMMCalibration>
<SIMMCalibration id="next">
......
</SIMMCalibration>
</SIMMCalibrationData>

302
7.11.1 SIMM Calibration
A SIMM Calibration is defined by a <SIMMCalibration> node that defines a
particular SIMM version, i.e. it defines a single set of risk weights, correlations,
concentration thresholds and currency groups. The <SIMMCalibration> has the
following components:
1. Version names - <VersionNames>
This may contain any number of <Name> sub-nodes, where each value will be
associated with the given SIMM calibration. In order to use a given calibration,
one of its names must be specified in the "version" parameter of the SIMM
analytic (see Listing 13). In the example listing 240 above, the SIMM calibration
will override the original SIMM 2.5.6/2.6 defined in the source code.
2. Additional fields - <AdditionalFields>
This node is used for purely descriptive purposes and can contain any subnode.
3. Risk-class-specific sub-nodes:
• <InterestRate>
• <CreditQualifying>
• <CreditNonQualifying>
• <Equity>
• <Commodity>
• <FX>
4. Risk class correlations - <RiskClassCorrelations>
The risk class correlations and its subcomponents are given in Listing 241:

Listing 241: SIMM Calibration: risk class correlations

<RiskClassCorrelations>
<Correlation label1="InterestRate" label2="FX">0.14</Correlation>
<Correlation label1="InterestRate" label2="Equity">0.29</Correlation>
<Correlation label1="InterestRate" label2="CreditQualifying">0.27</Correlation>
<Correlation label1="InterestRate" label2="CreditNonQualifying">0.26</Correlation>
<Correlation label1="InterestRate" label2="Commodity">0.31</Correlation>
<Correlation label1="FX" label2="InterestRate">0.14</Correlation>
<Correlation label1="FX" label2="Equity">0.25</Correlation>
<Correlation label1="FX" label2="CreditQualifying">0.25</Correlation>
<Correlation label1="FX" label2="CreditNonQualifying">0.14</Correlation>
<Correlation label1="FX" label2="Commodity">0.3</Correlation>
<Correlation label1="Equity" label2="InterestRate">0.29</Correlation>
.......
</RiskClassCorrelations>

Each correlation value is given by a <Correlation> node with attributes label1 and
label2 to specify the risk classes to which it applies.
Since the risk-class-specific components have many sub-nodes in common, the
following section will be a description of the general ‘base’ structure, and then a

303
section will be given for each risk class to explain its specific XML structure along with
any components unique to that risk class. We will also make reference to the
corresponding sections in the ISDA SIMM Methodology [24].

7.11.2 General Structure

All risk class subnodes (i.e. InterestRate, CreditQualifying, etc.) in the SIMM
calibration will contain the following three components:
1. <RiskWeights>
2. <Correlations>
3. <ConcentrationThresholds>
The general stucture is given by Listing 242. Note that
<HistoricalVolatilityRatio> only applies to InterestRate, Equity, Commodity and
FX, and <CurrencyLists> only applies to InterestRate and FX.

Listing 242: SIMM Calibration - General XML Structure

<RiskWeights>
<Delta mporDays="10">
....
</Delta>
<Vega mporDays="10">
....
</Vega>
<HistoricalVolatilityRatio mporDays="10">...</HistoricalVolatilityRatio>
</RiskWeights>
<Correlations>
<IntraBucketCorrelation>
....
</IntraBucketCorrelation>
<InterBucketCorrelation>
....
</InterBucketCorrelation>
</Correlations>
<ConcentrationThresholds>
<Delta>
....
</Delta>
<Vega>
....
</Vega>
<CurrencyLists>
....
</CurrencyLists>
</ConcentrationThresholds>

The structure of the <RiskWeights> node is given by Listing 243. Every top-level
node in <RiskWeights> should have an <mporDays> attribute (which defaults to “10”
when omitted).

304
Listing 243: SIMM Calibration - Risk Weights

<RiskWeights>
<Delta mporDays="10">
<!-- e.g. for IR -->
<Weight bucket="1" label1="2w">109</Weight>
<Weight bucket="1" label1="1m">105</Weight>

<!-- e.g. for CreditQualifying/CreditNonQualifying/Equity/Commodity -->

<Weight bucket="1">75</Weight>
<Weight bucket="2">90</Weight>

<!-- e.g. for FX -->

<Weight label1="2" label2="2">7.4</Weight>
<Weight label1="2" label2="1">14.7</Weight>
</Delta>
<HistoricalVolatilityRatio mporDays="10">0.47</HistoricalVolatilityRatio>
<Vega mporDays="10">
<!-- e.g. for IR/CreditQualifying/Commodity/FX -->
<Weight>0.76</Weight>

<!-- e.g. for CreditNonQualifying/Equity -->

<Weight bucket="1">280</Weight>
<Weight bucket="2">1300</Weight>
</Vega>
</RiskWeights>

The structure of the <Correlations> node is given by Listing 244.

Listing 244: SIMM Calibration - Correlations

<Correlations>
<IntraBucketCorrelation>
<!-- e.g. for IR -->
<Correlation label1="2w" label2="1m">0.77</Correlation>
<Correlation label1="2w" label2="3m">0.67</Correlation>

<!-- e.g. for CreditQualifying/CreditNonQualifying -->

<Correlation label1="aggregate" label2="same">0.93</Correlation>
<Correlation label1="aggregate" label2="different">0.46</Correlation>

<!-- e.g. for Equity/Commodity -->

<Correlation bucket="1">0.18</Correlation>
<Correlation bucket="2">0.2</Correlation>

<!-- e.g. for FX -->

<Correlation bucket="2" label1="2" label2="2">0.5</Correlation>
<Correlation bucket="2" label1="2" label2="1">0.25</Correlation>
</IntraBucketCorrelation>
<InterBucketCorrelation>
<!-- e.g. for CreditQualifying/CreditNonQualifying/Equity/Commodity -->
<Correlation label1="1" label2="2">0.38</Correlation>
<Correlation label1="1" label2="3">0.38</Correlation>
</InterBucketCorrelation>
</Correlations>

305
The structure of the <ConcentrationThresholds> node is given by Listing 245.

Listing 245: SIMM Calibration - Concentration Thresholds

<ConcentrationThresholds>
<Delta>
<!-- e.g. for IR/CreditQualifying/CreditNonQualifying/Equity/Commodity/FX -->
<Threshold bucket="1">30</Threshold>
<Threshold bucket="2">330</Threshold>
</Delta>
<Vega>
<!-- e.g. for IR -->
<Threshold bucket="1">74</Threshold>
<Threshold bucket="2">4900</Threshold>

<!-- e.g. for CreditQualifying/CreditNonQualifying/Equity/Commodity/FX -->

<Threshold>360</Threshold>
</Vega>
</ConcentrationThresholds>

7.11.3 Interest Rate

The structure for the <InterestRate> node is given by Listing 246.

Listing 246: SIMM Calibration - Interest Rate Risk

<InterestRate>
<RiskWeights>
<Delta mporDays="10">...</Delta>
<Vega mporDays="10">...</Vega>
<HistoricalVolatilityRatio mporDays="10">0.47</HistoricalVolatilityRatio>
<Inflation mporDays="10">61</Inflation>
<XCcyBasis mporDays="10">21</XCcyBasis>
<CurrencyLists>
<Currency bucket="1">USD</Currency>
....
<Currency bucket="3">Other</Currency>
</CurrencyLists>
</RiskWeights>
<Correlations>
<IntraBucket>...</IntraBucket>
<SubCurves>0.993</SubCurves>
<Inflation>0.24</Inflation>
<XCcyBasis>0.04</XCcyBasis>
<Outer>0.32</Outer>
</Correlations>
<ConcentrationThresholds>
<Delta>...</Delta>
<Vega>...</Vega>
<CurrencyLists>
<Currency bucket="1">Other</Currency>
<Currency bucket="2">USD</Currency>
....
</CurrencyLists>
</ConcentrationThresholds>
</InterestRate>

306
The above values are found in the following sections of the ISDA SIMM Methodology
[24]:
• Delta risk weights: Section D.1, 33.
Each <Weight> node must have a bucket (defining the currency group) and
label1 (defining the tenor) attribute.
Allowable bucket values: “1” for regular volatility currencies, “2” for
low-volatility currencies, and “3” for high-volatility currencies.
Allowable label1 values: “2w”, “1m”, “3m”, “6m”, “1y”, “2y”, “3y”, “5y”, “10y”,
“15y”, “20y”, “30y".
• Vega risk weight: Section D.1, 35.
There should only be one <Weight> node, and no attributes are required.
• Historical volatility ratio (HVR): Section D.1 34.
There should only be one <HistoricalVolatilityRatio> node, and the only
attributed needed is mporDays (which defaults to “10” if omitted).
• Inflation risk weight: Section D.1, 33.
There should only be one <Weight> node, and the only attributed needed is
mporDays (which defaults to “10” if omitted).
• Risk weight for cross-currency basis swap spread (<XCcyBasis>): Section D.1, 33
There should only be one <Weight> node, and the only attributed needed is
mporDays (which defaults to “10” if omitted).
• Currency groups for risk weights (<CurrencyLists>): Section D.1 33(1) to (3).
Each <Currency> must have a bucket attribute associating it with a currency
volatility group.
• Intra-bucket correlations: Section D.2, 36.
Each <Correlation> must have a label1 and label2 attribute. Note that
although the correlations are symmetric, the correlation value for both directions
must be provided.
• Correlation between sub-curves: Section D.2, 36.
• Correlation for inflation rate: Section D.2, 36.
• Correlation for Cross-currency basis swap spread (XCcyBasis): Section D.2, 36.
• Correlation across different currencies (<Outer>): Section D.2, 37.
• Delta concentration thresholds: Section J.1, 74
Each <Threshold> must have a bucket attribute associating it with a currency
group.
Allowable bucket values: “1” for high volatility, “2” for regular volatility,
well-traded, “3” for regular volatility, less-traded, and “4” for low volatility.
• Vega concentration thresholds: Section J.6, 81.
Each <Threshold> must have a bucket attribute associating it with a currency
group.
Allowable bucket values: “1” for high volatility, “2” for regular volatility,
well-traded, “3” for regular volatility, less-traded, and “4” for low volatility.

307
 • Concentration threshold currency groups (CurrencyLists): Section J.1, 75.
Each <Currency> must have a bucket attribute associating it with a currency
group.
Allowable bucket values: “1” for high volatility, “2” for regular volatility,
well-traded, “3” for regular volatility, less-traded, and “4” for low volatility.

7.11.4 Credit Qualifying

The structure for the <CreditQualifying> node is given by Listing 247.

Listing 247: SIMM Calibration - Credit Qualifying Risk

<CreditQualifying>
<RiskWeights>
<Delta mporDays="10">...</Delta>
<Vega mporDays="10">...</Vega>
<BaseCorrelation mporDays="10">10</BaseCorrelation>
</RiskWeights>
<Correlations>
<IntraBucket>...</IntraBucket>
<InterBucket>...</InterBucket>
<BaseCorrelation>...</BaseCorrelation>
</Correlations>
<ConcentrationThresholds>
<Delta>...</Delta>
<Vega>...</Vega>
</ConcentrationThresholds>
</CreditQualifying>

The above values are found in the following sections of the ISDA SIMM Methodology
[24]:
• Delta risk weights: Section E.1, 39.
Each <Weight> node must have a bucket attribute.
Allowable bucket values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “11”, “12”,
“Residual”, as defined in Section E.1, 38.
• Vega risk weight: Section E.1, 40.
There should only be one <Weight> node, and no attributes are required.
• Base correlation risk: Section E.1 41.
• Intra-bucket correlations: Section E.2, 42.
Each <Correlation> must have a label1 and label2 attribute.
Allowable label1 values: aggregate or residual.
Allowable label2 values: same or different.
• Inter-bucket correlations: Section E.2, 43.
Each <Correlation> must have a label1 and label2 attribute. Note that
although the correlations are symmetric, the correlation value for both directions
must be provided.
Allowable label1/label2 values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”,
“11”, “12”, as defined in Section E.1, 38.

308
 • Correlation for Base correlation risks: Section E.2, 42.
• Delta concentration thresholds: Section J.2, 76
Each <Threshold> must have a bucket attribute.
Allowable bucket values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “11”, “12”,
“Residual”, as defined in Section E.1, 38.
• Vega concentration threshold: Section J.7, 83.
There should only be one <Threshold>, and no attributes are required.

7.11.5 Credit Non-Qualifying

The structure for the <CreditNonQualifying> node is given by Listing 248.

Listing 248: SIMM Calibration - Credit Non-Qualifying Risk

<CreditNonQualifying>
<RiskWeights>
<Delta mporDays="10">...</Delta>
<Vega mporDays="10">...</Vega>
</RiskWeights>
<Correlations>
<IntraBucket>...</IntraBucket>
<InterBucket>...</InterBucket>
</Correlations>
<ConcentrationThresholds>
<Delta>...</Delta>
<Vega>...</Vega>
</ConcentrationThresholds>
</CreditNonQualifying>

The above values are found in the following sections of the ISDA SIMM Methodology
[24]:
• Delta risk weights: Section F.1, 46.
Each <Weight> node must have a bucket attribute.
Allowable bucket values: “1”, “2”, “Residual”, as defined in Section F.1, 45.
• Vega risk weight: Section F.1, 47.
There should only be one <Weight> node, and no attributes are required.
• Intra-bucket correlations: Section F.2, 48.
Each <Correlation> must have a label1 and label2 attribute.
Allowable label1 values: aggregate or residual.
Allowable label2 values: same or different.
• Inter-bucket correlations: Section F.2, 49.
Each <Correlation> must have a label1 and label2 attribute. Note that
although the correlations are symmetric, the correlation value for both directions
must be provided.
Allowable label1/label2 values: “1”, “2”, as defined in Section F.1, 45.
• Delta concentration thresholds: Section J.2, 76
Each <Threshold> must have a bucket attribute.

309
 Allowable bucket values: “1”, “2”, “Residual”, as defined in Section F.1, 45.
• Vega concentration threshold: Section J.7, 83.
There should only be one <Threshold>, and no attributes are required.

7.11.6 Equity
The structure for the <Equity> node is given by Listing 249.

Listing 249: SIMM Calibration - Equity Risk

<Equity>
<RiskWeights>
<Delta mporDays="10">...</Delta>
<Vega mporDays="10">...</Vega>
<HistoricalVolatilityRatio mporDays="10">0.6</HistoricalVolatilityRatio>
</RiskWeights>
<Correlations>
<IntraBucket>...</IntraBucket>
<InterBucket>...</InterBucket>
</Correlations>
<ConcentrationThresholds>
<Delta>...</Delta>
<Vega>...</Vega>
</ConcentrationThresholds>
</Equity>

The above values are found in the following sections of the ISDA SIMM Methodology
[24]:
• Delta risk weights: Section G.1, 56.
Each <Weight> node must have a bucket attribute.
Allowable bucket values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “11”, “12”,
“Residual”, as defined in Section G.1, 50.
• Vega risk weight: Section G.1, 58.
Each <Weight> node must have a bucket attribute.
Allowable bucket values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “11”, “12”,
“Residual”, as defined in Section G.1, 50.
• Historical volatility ratio (HVR): Section G.1 57.
There should only be one <HistoricalVolatilityRatio> node, and the only
attributed needed is mporDays (which defaults to “10” if omitted).
• Intra-bucket correlations: Section G.2, 59.
Each <Correlation> must have a bucket attribute. Allowable bucket values:
“1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “11”, “12”, “Residual”, as defined in
Section G.1, 50.
• Inter-bucket correlations: Section G.2, 60.
Each <Correlation> must have a label1 and label2 attribute. Note that
although the correlations are symmetric, the correlation value for both directions
must be provided.

310
 Allowable label1/label2 values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”,
“11”, “12”, as defined in Section G.1, 50.
• Delta concentration thresholds: Section J.3, 77
Each <Threshold> must have a bucket attribute.
Allowable bucket values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “11”, “12”,
“Residual”, as defined in Section G.1, 50.
• Vega concentration thresholds: Section J.8, 84.
Each <Threshold> must have a bucket attribute.
Allowable bucket values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “11”, “12”,
“Residual”, as defined in Section G.1, 50.

7.11.7 Commodity
The structure for the <Commodity> node is given by Listing 250.

Listing 250: SIMM Calibration - Commodity Risk

<Commodity>
<RiskWeights>
<Delta mporDays="10">...</Delta>
<Vega mporDays="10">...</Vega>
<HistoricalVolatilityRatio mporDays="10">0.74</HistoricalVolatilityRatio>
</RiskWeights>
<Correlations>
<IntraBucket>...</IntraBucket>
<InterBucket>...</InterBucket>
</Correlations>
<ConcentrationThresholds>
<Delta>...</Delta>
<Vega>...</Vega>
</ConcentrationThresholds>
</Commodity>

The above values are found in the following sections of the ISDA SIMM Methodology
[24]:
• Delta risk weights: Section H.1, 61.
Each <Weight> node must have a bucket attribute.
Allowable bucket values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “11”, “12”,
“13”, “14”, “15”, “16”, “17”, as defined in Section H.1, 61.
• Vega risk weight: Section H.1, 63.
There should only be one <Weight> node, and no attributes are required.
• Historical volatility ratio (HVR): Section H.1 62.
There should only be one <HistoricalVolatilityRatio> node, and the only
attributed needed is mporDays (which defaults to “10” if omitted).
• Intra-bucket correlations: Section H.2, 64.
Each <Correlation> must have a bucket attribute.
Allowable bucket values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “11”, “12”,
“13”, “14”, “15”, “16”, “17”, as defined in Section H.1, 61.

311
 • Inter-bucket correlations: Section H.2, 65.
Each <Correlation> must have a label1 and label2 attribute. Note that
although the correlations are symmetric, the correlation value for both directions
must be provided.
Allowable label1/label2 values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”,
“11”, “12”, “13”, “14”, “15”, “16”, “17”, as defined in Section H.1, 61.
• Delta concentration thresholds: Section J.4, 78.
Each <Threshold> must have a bucket attribute.
Allowable bucket values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “11”, “12”,
“13”, “14”, “15”, “16”, “17”, as defined in Section H.1, 61.
• Vega concentration thresholds: Section J.9, 85.
Each <Threshold> must have a bucket attribute.
Allowable bucket values: “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “10”, “11”, “12”,
“13”, “14”, “15”, “16”, “17”, as defined in Section H.1, 61.

7.11.8 FX
The structure for the <FX> node is given by Listing 251.

Listing 251: SIMM Calibration - FX Risk

<FX>
<RiskWeights>
<Delta mporDays="10">...</Delta>
<Vega mporDays="10">...</Vega>
<HistoricalVolatilityRatio mporDays="10">0.57</HistoricalVolatilityRatio>
<CurrencyLists>
<Currency bucket="2">Other</Currency>
<Currency bucket="1">BRL</Currency>
<Currency bucket="1">TRY</Currency>
<Currency bucket="1">RUB</Currency>
</CurrencyLists>
</RiskWeights>
<Correlations>
<IntraBucket>...</IntraBucket>
<Volatility>0.5</Volatility>
</Correlations>
<ConcentrationThresholds>
<Delta>...</Delta>
<Vega>...</Vega>
<CurrencyLists>
<Currency bucket="1">USD</Currency>
<Currency bucket="1">EUR</Currency>
....
<Currency bucket="3">Other</Currency>
</CurrencyLists>
</ConcentrationThresholds>
</FX>

The above values are found in the following sections of the ISDA SIMM Methodology
[24]:

312
• Delta risk weights: Section I.1, 69.
Each <Weight> node must have a label1 (defining the first currency’s volatility
group) and label2 (defining the second currency’s volatility group) attribute.
Allowable label1/label2 values: “1” for high FX volatility currencies and “2”
for regular FX volatility currencies.
• Vega risk weight: Section I.1, 71.
There should only be one <Weight> node, and no attributes are required.
• Historical volatility ratio (HVR): Section I.1 70.
There should only be one <HistoricalVolatilityRatio> node, and the only
attributed needed is mporDays (which defaults to “10” if omitted).
• Currency groups for risk weights (<CurrencyLists>): Section I.1 67. and 68.
Each <Currency> must have a bucket attribute associating it with a currency
volatility group.
Allowable bucket values: Allowable label1/label2 values: “1” for high FX
volatility currencies and “2” for regular FX volatility currencies.
• Intra-bucket correlations: Section I.2, 72.
Each <Correlation> must have a label1 and label2 attribute. Note that
although the correlations are symmetric, the correlation value for both directions
must be provided.
Allowable bucket values: “1” if the SIMM calculation currency is in the regular
FX volatility group, and “2” if it is in the high FX volatility group.
Allowable label1/label2 values: “1” for high FX volatility currencies and “2”
for regular FX volatility currencies.
• Correlation between FX volatility and curvature risk factors (<Volatility>):
Section I.2. 73
• Delta concentration thresholds: Section J.5, 79
Each <Threshold> must have a bucket attribute associating it with a currency
risk group.
Allowable bucket values: “1”, “2”, “3”.
• Vega concentration thresholds: Section J.10, 86.
Each <Threshold> must have a bucket attribute associating it with a currency
group.
Allowable bucket values: “1” for “Category 1 - Category 1”, “2” for “Category 1 -
Category 2”, “3” for “Category 1 - Category 3”, “4” for “Category 2 - Category 2”,
“5” for “Category 2 - Category 3”, and “6” for “Category 3 - Category 3”.
• Concentration threshold currency groups (CurrencyLists): Section J.5, 80.
Each <Currency> must have a bucket attribute associating it with a currency
risk group.
Allowable bucket values: “1” for “Category 1 - Significantly material”, “2” for
“Category 2 - Frequently traded”, and “3” for “Category 3 - Others”.

313
7.12 Conventions: [Link]
The conventions to associate with a set market quotes in the construction of
termstructures are specified in another xml file which we will refer to as
[Link] in the following though the file name can be chosen by the user.
Each separate set of conventions is stored in an XML node. The type of conventions
that a node holds is determined by the node name. Every node has an Id node that
gives a unique identifier for the convention set. The following sections describe the
type of conventions that can be created and the allowed values.

7.12.1 Zero Conventions

A node with name Zero is used to store conventions for direct zero rate quotes. Direct
zero rate quotes can be given with an explicit maturity date or with a tenor and a set
of conventions from which the maturity date is deduced. The node for a zero rate
quote with an explicit maturity date is shown in Listing 252. The node for a tenor
based zero rate is shown in Listing 253.

Listing 252: Zero conventions

<Zero>
<Id> </Id>
<TenorBased>False</TenorBased>
<DayCounter> </DayCounter>
<CompoundingFrequency> </CompoundingFrequency>
<Compounding> </Compounding>
</Zero>

Listing 253: Zero conventions, tenor based

<Zero>
<Id> </Id>
<TenorBased>True</TenorBased>
<DayCounter> </DayCounter>
<CompoundingFrequency> </CompoundingFrequency>
<Compounding> </Compounding>
<TenorCalendar> </TenorCalendar>
<SpotLag> </SpotLag>
<SpotCalendar> </SpotCalendar>
<RollConvention> </RollConvention>
<EOM> </EOM>
</Zero>

The meanings of the various elements in this node are as follows:

• TenorBased: True if the conventions are for a tenor based zero quote and False if
they are for a zero quote with an explicit maturity date.
• DayCounter: The day count basis associated with the zero rate quote (for choices
see section 8.4)
• CompoundingFrequency: The frequency of compounding (Choices are Once,
Annual, Semiannual, Quarterly, Bimonthly, Monthly, Weekly, Daily).

314
 • Compounding: The type of compounding for the zero rate (Choices are Simple,
Compounded, Continuous, SimpleThenCompounded).
• TenorCalendar: The calendar used to advance from the spot date to the
maturity date by the zero rate tenor (for choices see section 8.4).
• SpotLag [Optional]: The number of business days to advance from the valuation
date before applying the zero rate tenor. If not provided, this defaults to 0.
• SpotCalendar [Optional]: The calendar to use for business days when applying
the SpotLag. If not provided, it defaults to a calendar with no holidays.
• RollConvention [Optional]: The roll convention to use when applying the zero
rate tenor. If not provided, it defaults to Following (Choices are Backward,
Forward, Zero, ThirdWednesday, Twentieth, TwentiethIMM, CDS,
ThirdThursday, ThirdFriday, MondayAfterThirdFriday,
TuesdayAfterThirdFriday, LastWednesday).
• EOM [Optional]: Whether or not to use the end of month convention when
applying the zero rate tenor. If not provided, it defaults to false.

7.12.2 Deposit Conventions

A node with name Deposit is used to store conventions for deposit or index fixing
quotes. The conventions can be index based, in which case all necessary conventions
are deduced from a given index family. The structure of the index based node is shown
in Listing 254. Alternatively, all the necessary conventions can be given explicitly
without reference to an index family. The structure of this node is shown in Listing
255.
Listing 254: Deposit conventions

<Deposit>
<Id> </Id>
<IndexBased>True</IndexBased>
<Index> </Index>
</Deposit>

Listing 255: Deposit conventions

<Deposit>
<Id> </Id>
<IndexBased>False</IndexBased>
<Calendar> </Calendar>
<Convention> </Convention>
<EOM> </EOM>
<DayCounter> </DayCounter>
</Deposit>

The meanings of the various elements in this node are as follows:

• IndexBased: True if the deposit conventions are index based and False if the
conventions are given explicitly.

315
 • Index: The index family from which to imply the conventions for the deposit
quote. For example, this could be EUR-EURIBOR, USD-LIBOR etc.
• Calendar: The business day calendar for the deposit quote.
• Convention: The roll convention for the deposit quote.
• EOM: True if the end of month roll convention is to be used for the deposit
quote and False if not.
• DayCounter: The day count basis associated with the deposit quote.

7.12.3 Future Conventions

A node with name Future is used to store conventions for money market (MM) or
overnight index (OI) interest rate future quotes, for example futures on Euribor 3M or
SOFR 3M underlyings. The structure of this node is shown in Listing 256. The fields
have the following meaning:
• Id: The name of the convention.
• Index: The underlying index of the futures, this is either a MM (i.e. Ibor) index
like e.g. EUR-EURIBOR-3M or an overnight index like e.g. USD-SOFR.
• DateGenerationRule [Optional]: This should be set to ’IMM’ when the start and
end dates of the future are following the IMM date logic or ’FirstDayOfMonth’
when the start and end date are the first day of a month. If not given this field
defaults to ’IMM’.
– For MM futures only ’IMM’ is allowed and the expiry date is determined as
the next 3rd Wednesday of the expiry month of a future.
– For an overnight index future ’IMM’ means that the end date of the future
is set to the 3rd Wednesday of the expiry month and the start date is set to
the 3rd Wednesday of the expiry month minus the future tenor. The setting
’IMM’ applies to SOFR-3M futures for example. ’FirstDayOfMonth’ on the
other hand means that the end date of the future is set to the first day in
the month following the future’s expiry month and the start date is set to
the first day of the month lying n months before the end date’s month
where n is the number of months of the future’s underlying tenor. The
setting ’FirstDayOfMonth’ applies to SOFR-1M futures for example. This
tenor is derived from the market quote, see 10.8.
• OvernightIndexFutureNettingType [Optional]: Only relevant for OI futures. Can
be ’Compounding’ (which is also the default value if no value is given) or
’Averaging’. For example, SOFR 3M futures are compounding while SOFR 1M
futures are averaging the daily overnight fixings over the calculation period of the
future.
Listings 257, 258, 259 show examples for Euribor-3M, SOFR-3M and SOFR-1M future
conventions.

316
Listing 256: Future conventions

<Future>
<Id> </Id>
<Index> </Index>
<DateGenerationRule> </DateGenerationRule>
<OvernightIndexFutureNettingType> </OvernightIndexFutureNettingType>
</Future>

Listing 257: Euribor 3M MM Future conventions

<Future>
<Id>EURIBOR-3M-FUTURES</Id>
<Index>EUR-EURIBOR-3M</Index>
</Future>

Listing 258: USD SOFR 3M OI Future conventions

<Future>
<Id>USD-SOFR-3M-FUTURES</Id>
<Index>USD-SOFR</Index>
<DateGenerationRule>IMM</DateGenerationRule>
<OvernightIndexFutureNettingType>Compounding</OvernightIndexFutureNettingType>
</Future>

Listing 259: USD SOFR 1M OI Future conventions

<Future>
<Id>USD-SOFR-1M-FUTURES</Id>
<Index>USD-SOFR</Index>
<DateGenerationRule>FirstDayOfMonth</DateGenerationRule>
<OvernightIndexFutureNettingType>Averaging</OvernightIndexFutureNettingType>
</Future>

7.12.4 FRA Conventions

A node with name FRA is used to store conventions for FRA quotes. The structure of
this node is shown in Listing 260. The only piece of information needed is the
underlying index name and this is given in the Index node. For example, this could be
EUR-EURIBOR-6M, CHF-LIBOR-6M etc.

Listing 260: FRA conventions

<FRA>
<Id> </Id>
<Index> </Index>
</FRA>

317
7.12.5 OIS Conventions
A node with name OIS is used to store conventions for Overnight Indexed Swap (OIS)
quotes. The structure of this node is shown in Listing 261.
Listing 261: OIS conventions

<OIS>
<Id> </Id>
<SpotLag> </SpotLag>
<Index> </Index>
<FixedDayCounter> </FixedDayCounter>
<FixedCalendar> </FixedCalendar>
<PaymentLag> </PaymentLag>
<EOM> </EOM>
<FixedFrequency> </FixedFrequency>
<FixedConvention> </FixedConvention>
<FixedPaymentConvention> </FixedPaymentConvention>
<Rule> </Rule>
<PaymentCalendar> </PaymentCalendar>
</OIS>

The meanings of the various elements in this node are as follows:

• SpotLag: The number of business days until the start of the OIS.
• Index: The name of the overnight index. For example, this could be
EUR-EONIA, USD-FedFunds etc.
• FixedDayCounter: The day count basis on the fixed leg of the OIS.
• FixedCalendar [Optional]: The business day calendar on the fixed leg. Optional
to retain backwards compatibility with older versions, if not given defaults to
index fixing calendar.
• PaymentLag [Optional]: The payment lag, as a number of business days, on both
legs. If not provided, this defaults to 0.
• EOM [Optional]: True if the end of month roll convention is to be used when
generating the OIS schedule and False if not. If not provided, this defaults to
False.
• FixedFrequency [Optional]: The frequency of payments on the fixed leg. If not
provided, this defaults to Annual.
• FixedConvention [Optional]: The roll convention for accruals on the fixed leg. If
not provided, this defaults to Following.
• FixedPaymentConvention [Optional]: The roll convention for payments on the
fixed leg. If not provided, this defaults to Following.
• Rule [Optional]: The rule used for generating the OIS dates schedule i.e.
Backward or Forward. If not provided, this defaults to Backward.
• PaymentCalendar [Optional]: The business day calendar used for determining
coupon payment dates. If not specified, this defaults to the fixing calendar
defined on the overnight index.

318
7.12.6 Swap Conventions
A node with name Swap is used to store conventions for vanilla interest rate swap
(IRS) quotes. The structure of this node is shown in Listing 262.

Listing 262: Swap conventions

<Swap>
<Id> </Id>
<FixedCalendar> </FixedCalendar>
<FixedFrequency> </FixedFrequency>
<FixedConvention> </FixedConvention>
<FixedDayCounter> </FixedDayCounter>
<Index> </Index>
<FloatFrequency> </FloatFrequency>
<SubPeriodsCouponType> </SubPeriodsCouponType>
</Swap>

The meanings of the various elements in this node are as follows:

• FixedCalendar: The business day calendar on the fixed leg.
• FixedFrequency: The frequency of payments on the fixed leg.
• FixedConvention: The roll convention on the fixed leg.
• FixedDayCounter: The day count basis on the fixed leg.
• Index: The Ibor index on the floating leg.
• FloatFrequency [Optional]: The frequency of payments on the floating leg, to be
used if the frequency is different to the tenor of the index (e.g. CAD swaps for
BA-3M have a 6M or 1Y payment frequency with a Compounding coupon)
• SubPeriodsCouponType [Optional]: Defines how coupon rates should be
calculated when the float frequency is different to that of the index. Possible
values are "Compounding" and "Averaging".

7.12.7 Average OIS Conventions

A node with name AverageOIS is used to store conventions for average OIS quotes.
An average OIS is a swap where a fixed rate is swapped against a daily averaged
overnight index plus a spread. The structure of this node is shown in Listing 263.

319
Listing 263: Average OIS conventions

<AverageOIS>
<Id> </Id>
<SpotLag> </SpotLag>
<FixedTenor> </FixedTenor>
<FixedDayCounter> </FixedDayCounter>
<FixedCalendar> </FixedCalendar>
<FixedConvention> </FixedConvention>
<FixedPaymentConvention> </FixedPaymentConvention>
<FixedFrequency> </FixedFrequency>
<Index> </Index>
<OnTenor> </OnTenor>
<RateCutoff> </RateCutoff>
</AverageOIS>

The meanings of the various elements in this node are as follows:

• SpotLag: Number of business days until the start of the average OIS.
• FixedTenor: The frequency of payments on the fixed leg.
• FixedDayCounter: The day count basis on the fixed leg.
• FixedCalendar: The business day calendar on the fixed leg.
• FixedFrequency: The frequency of payments on the fixed leg.
• FixedConvention: The roll convention for accruals on the fixed leg.
• FixedPaymentConvention: The roll convention for payments on the fixed leg.
• FixedFrequency [Optional]: The frequency of payments on the fixed leg. If not
provided, this defaults to Annual.
• Index: The name of the overnight index.
• OnTenor: The frequency of payments on the overnight leg.
• RateCutoff: The rate cut-off on the overnight leg. Generally, the overnight fixing
is only observed up to a certain number of days before the payment date and the
last observed rate is applied for the remaining days in the period. This rate
cut-off gives the number of days e.g. 2 for Fed Funds average OIS.

7.12.8 Tenor Basis Swap Conventions

A node with name TenorBasisSwap is used to store conventions for tenor basis swap
quotes. The structure of this node is shown in Listing 264.

320
Listing 264: Tenor basis swap conventions

<TenorBasisSwap>
<Id> </Id>
<PayIndex> </PayIndex>
<PayFrequency> </PayFrequency>
<ReceiveIndex> </ReceiveIndex>
<ReceiveFrequency> </ReceiveFrequency>
<SpreadOnRec> </SpreadOnRec>
<IncludeSpread> </IncludeSpread>
<SubPeriodsCouponType> </SubPeriodsCouponType>
</TenorBasisSwap>

The meanings of the various elements in this node are as follows:

• PayIndex: The name of Ibor/Overnight Index of the pay leg.
• PayFrequency [Optional]: The frequency of payments on the PayIndex leg. This
is usually the same as the PayIndex’s tenor. However, it can also be longer, e.g.
overnight indexed vs overnight indexed basis swaps that may be quarterly on
both legs. If not provided, this defaults to the PayIndex’s tenor.
• ReceiveIndex: The name of Ibor/Overnight Index of the receive leg.
• ReceiveFrequency [Optional]: The frequency of payments on the ReceiveIndex
leg. This is usually the same as the ReceiveIndex’s tenor. However, it can also be
longer, e.g. overnight indexed vs overnight indexed basis swaps that may be
quarterly on both legs. If not provided, this defaults to the ReceiveIndex’s tenor.
• SpreadOnRec [Optional]: True if the tenor basis swap quote has the spread on
the pay index leg and False if not. If not provided, this defaults to True.
• IncludeSpread [Optional]: True if the tenor basis swap spread is to be included
when compounding is performed on the spread leg and False if not. If not
provided, this defaults to False.
• SubPeriodsCouponType [Optional]: This field can have the value Compounding
or Averaging. It applies to Ibor vs OI and Ibor vs Ibor basis swaps when the
frequency of payments on the spread leg does not equal the spread leg index’s
tenor. If Compounding is specified, then the spread tenor Ibor index is
compounded and paid on the frequency specified in the corresponding node. If
Averaging is specified, then the short tenor Ibor index is averaged and paid on
the frequency specified in the corresponding node.

7.12.9 Tenor Basis Two Swap Conventions

A node with name TenorBasisTwoSwap is used to store conventions for tenor basis
swap quotes where the quote is the spread between the fair fixed rate on two swaps
against Ibor indices of different tenors. We call the swap against the Ibor index of
longer tenor the long swap and the remaining swap the short swap. The structure of
the tenor basis two swap conventions node is shown in Listing 265.

321
Listing 265: Tenor basis two swap conventions

<TenorBasisTwoSwap>
<Id> </Id>
<Calendar> </Calendar>
<LongFixedFrequency> </LongFixedFrequency>
<LongFixedConvention> </LongFixedConvention>
<LongFixedDayCounter> </LongFixedDayCounter>
<LongIndex> </LongIndex>
<ShortFixedFrequency> </ShortFixedFrequency>
<ShortFixedConvention> </ShortFixedConvention>
<ShortFixedDayCounter> </ShortFixedDayCounter>
<ShortIndex> </ShortIndex>
<LongMinusShort> </LongMinusShort>
</TenorBasisTwoSwap>

The meanings of the various elements in this node are as follows:

• Calendar: The business day calendar on both swaps.
• LongFixedFrequency: The frequency of payments on the fixed leg of the long
swap.
• LongFixedConvention: The roll convention on the fixed leg of the long swap.
• LongFixedDayCounter: The day count basis on the fixed leg of the long swap.
• LongIndex: The Ibor index on the floating leg of the long swap.
• ShortFixedFrequency: The frequency of payments on the fixed leg of the short
swap.
• ShortFixedConvention: The roll convention on the fixed leg of the short swap.
• ShortFixedDayCounter: The day count basis on the fixed leg of the short swap.
• ShortIndex: The Ibor index on the floating leg of the short swap.
• LongMinusShort [Optional]: True if the basis swap spread is to be interpreted as
the fair rate on the long swap minus the fair rate on the short swap and False if
the basis swap spread is to be interpreted as the fair rate on the short swap
minus the fair rate on the long swap. If not provided, it defaults to True.

7.12.10 FX Conventions
A node with name FX is used to store conventions for FX spot and forward quotes for
a given currency pair. The structure of this node is shown in Listing 266.

322
Listing 266: FX conventions

<FX>
<Id> </Id>
<SpotDays> </SpotDays>
<SourceCurrency> </SourceCurrency>
<TargetCurrency> </TargetCurrency>
<PointsFactor> </PointsFactor>
<AdvanceCalendar> </AdvanceCalendar>
<SpotRelative> </SpotRelative>
</FX>

The meanings of the various elements in this node are as follows:

• SpotDays: The number of business days to spot for the currency pair.
• SourceCurrency: The source currency of the currency pair. The FX quote is
assumed to give the number of units of target currency per unit of source
currency.
• TargetCurrency: The target currency of the currency pair.
• PointsFactor: The number by which a points quote for the currency pair should
be divided before adding it to the spot quote to obtain the forward rate.
• AdvanceCalendar [Optional]: The business day calendar(s) used for advancing
dates for both spot and forwards. If not provided, it defaults to a calendar with
no holidays.
• SpotRelative [Optional]: True if the forward tenor is to be interpreted as being
relative to the spot date. False if the forward tenor is to be interpreted as being
relative to the valuation date. If not provided, it defaults to True.

7.12.11 Cross Currency Basis Swap Conventions

A node with name CrossCurrencyBasis is used to store conventions for cross currency
basis swap quotes. The structure of this node is shown in Listing 267.

323
Listing 267: Cross currency basis swap conventions

<CrossCurrencyBasis>
<Id> </Id>
<SettlementDays> </SettlementDays>
<SettlementCalendar> </SettlementCalendar>
<RollConvention> </RollConvention>
<FlatIndex> </FlatIndex>
<SpreadIndex> </SpreadIndex>
<EOM> </EOM>
<IsResettable> </IsResettable>
<FlatIndexIsResettable> </FlatIndexIsResettable>>
<PaymentLag> </PaymentLag>
<FlatPaymentLag> </FlatPaymentLag>
<!-- for OIS only -->
<IncludeSpread> </IncludeSpread>
<Lookback> </Lookback>
<FixingDays> </FixingDays>
<RateCutoff> </RateCutoff>
<IsAveraged> </IsAveraged>
<FlatIncludeSpread> </FlatIncludeSpread>
<FlatLookback> </FlatLookback>
<FlatFixingDays> </FlatFixingDays>
<FlatRateCutoff> </FlatRateCutoff>
<FlatIsAveraged> </FlatIsAveraged>
</CrossCurrencyBasis>

The meanings of the various elements in this node are as follows:

• SettlementDays: The number of business days to the start of the cross currency
basis swap.
• SettlementCalendar: The business day calendar(s) for both legs and to arrive at
the settlement date using the SettlementDays above.
• RollConvention: The roll convention for both legs.
• FlatIndex: The name of the index on the leg that does not have the cross
currency basis spread.
• SpreadIndex: The name of the index on the leg that has the cross currency basis
spread.
• EOM [Optional]: True if the end of month convention is to be used when
generating the schedule on both legs, and False if not. If not provided, it defaults
to False.
• IsResettable [Optional]: True if the swap is mark-to-market resetting, and False
otherwise. If not provided, it defaults to False.
• FlatIndexIsResettable [Optional]: True if it is the notional on the leg paying the
flat index that resets, and False otherwise. If not provided, it defaults to True.
• FlatTenor [Optional]: the flat leg period length (typical value is 3M), defaults to
index tenor except for ON indices for which it defaults to 3M

324
 • SpreadTenor [Optional]: the spread leg period length (typical value is 3M),
defaults to index tenor except for ON indices for which it defaults to 3M
• SpreadPaymentLag [Optional]: the payment lag for the spread leg, allowable
values are 0, 1, 2, ..., defaults to 0 if not given
• FlatPaymentLag [Optional]: the payment lag for the flat leg, allowable values are
0, 1, 2, ..., defaults to 0 if nove given
• SpreadIncludeSpread [Optional]: Only relevant if spread leg is OIS, allowable
values are true, false, defaults to false if not given
• SpreadLookback [Optional]: Only relevant if spread leg is OIS, allowable values
are 0D, 1D, ..., defaults to 0D if not given
• SpreadFixingDays [Optional]: Only relevant if spread leg is OIS, allowable values
are 0, 1, 2, ..., defaults to 0 if not given
• SpreadRateCutoff [Optional]: Only relevant if spread leg is OIS, allowable values
are 0, 1, 2, ..., defaults to 0 if not given
• SpreadIsAveraged [Optional]: Only relevant if spread leg is OIS, allowable values
are true, false, defaults to false if not given
• FlatIncludeSpread [Optional]: Only relevant if spread leg is OIS, allowable values
are true, false, defaults to false if not given
• FlatLookback [Optional]: Only relevant if spread leg is OIS, allowable values are
0D, 1D, ..., defaults to 0D if not given
• FlatFixingDays [Optional]: Only relevant if spread leg is OIS, allowable values
are 0, 1, 2, ..., defaults to 0 if not given
• FlatRateCutoff [Optional]: Only relevant if spread leg is OIS, allowable values
are 0, 1, 2, ..., defaults to 0 if not given
• FlatIsAveraged [Optional]: Only relevant if spread leg is OIS, allowable values
are true, false, defaults to false if not given

7.12.12 Inflation Swap Conventions

A node with name InflationSwap is used to store conventions for zero or year on year
inflation swap quotes. The structure of this node is shown in Listing 268

325
Listing 268: Inflation swap conventions

<InflationSwap>
<Id>EUHICPXT_INFLATIONSWAP</Id>
<FixCalendar>TARGET</FixCalendar>
<FixConvention>MF</FixConvention>
<DayCounter>30/360</DayCounter>
<Index>EUHICPXT</Index>
<Interpolated>false</Interpolated>
<ObservationLag>3M</ObservationLag>
<AdjustInflationObservationDates>false</AdjustInflationObservationDates>
<InflationCalendar>TARGET</InflationCalendar>
<InflationConvention>MF</InflationConvention>
</InflationSwap>

The meaning of the elements is as follows:

• FixCalendar: The calendar for the fixed rate leg of the swap.
• FixConvention: The rolling convention for the fixed rate leg of the swap.
• DayCounter: The payoff or coupon day counter, applied to both legs.
• Index: The underlying inflation index.
• Interpolated: Flag indicating interpolation of the index in the swap’s payoff
calculation.
• ObservationLag: The index observation lag to be applied.
• AdjustInflationObservationDates: Flag indicating whether index observation
dates should be adjusted or not.
• InflationCalendar: The calendar for the inflation leg of the swap.
• InflationConvention: The rolling convention for the inflation leg of the swap.
• PublicationRoll: This is an optional node taking the values None,
OnPublicationDate or AfterPublicationDate. If omitted, the value None is
used. Currently, our only known use case for a value other than None is for
Australian zero coupon inflation indexed swaps (ZCIIS). Here, the index is
published quarterly on the last Wednesday of the month following the end of the
reference quarter. The start date and maturity date of the market quoted ZCIIS
roll to the next quarterly date after the publication date of the index. For
example, the AU CPI value for Q3 2020, i.e. 1 Jul 2020 to 30 Sep 2020 was
released on 28 Oct 2020. On 27 Oct 2020, before the index publication date, the
market 5Y ZCIIS would start on 15 Sep 2020 and end on 15 Sep 2025 and
reference the Q2 inflation index value. On 29 Oct 2020, after the index
publication date, the market 5Y ZCIIS would start on 15 Dec 2020 and end on
15 Dec 2025 and reference the Q3 inflation index value. On the release date, i.e.
28 Oct 2020, the market ZCIIS that is set up is determined by whether the
PublicationRoll value is OnPublicationDate or AfterPublicationDate. If it
is set to OnPublicationDate, the swap rolls on this date and hence the market
5Y ZCIIS would start on 15 Dec 2020 and end on 15 Dec 2025 and reference the
Q3 inflation index value. If it is set to AfterPublicationDate, the swap does

326
 not roll on the publication date and instead rolls on the next day, and hence the
market 5Y ZCIIS would start on 15 Sep 2020 and end on 15 Sep 2025 and
reference the Q2 inflation index value. The publication schedule for the index
must be provided in the PublicationSchedule node if PublicationRoll is not
None. An example of the AU CPI conventions set up is given in Listing 269.
• PublicationSchedule: This is an optional node and is not used if
PublicationRoll is None. If PublicationRoll is not None, it must be provided
and gives the publication dates for the inflation index. The node fields are the
same fields that are described in the Section 8.3.4, i.e. they are ScheduleData
elements. An example of the AU CPI conventions set up is given in Listing 269.
The PublicationSchedule must cover the dates on which you intend to perform
valuations, i.e. the first publication schedule date must be less than the smallest
valuation date that you intend to use and the last publication schedule date must
be greater than the largest valuation date that you intend to use.

Listing 269: AU CPI inflation swap conventions

<InflationSwap>
<Id>AUCPI_INFLATIONSWAP</Id>
<FixCalendar>AUD</FixCalendar>
<FixConvention>F</FixConvention>
<DayCounter>30/360</DayCounter>
<Index>AUCPI</Index>
<Interpolated>false</Interpolated>
<ObservationLag>3M</ObservationLag>
<AdjustInflationObservationDates>false</AdjustInflationObservationDates>
<InflationCalendar>AUD</InflationCalendar>
<InflationConvention>F</InflationConvention>
<PublicationRoll>AfterPublicationDate</PublicationRoll>
<PublicationSchedule>
<Rules>
<StartDate>2001-01-24</StartDate>
<EndDate>2030-01-30</EndDate>
<Tenor>3M</Tenor>
<Calendar>AUD</Calendar>
<Convention>Preceding</Convention>
<TermConvention>Unadjusted</TermConvention>
<Rule>LastWednesday</Rule>
</Rules>
</PublicationSchedule>
</InflationSwap>

7.12.13 CMS Spread Option Conventions

A node with name CmsSpreadOption is used to store the conventions.

327
Listing 270: Inflation swap conventions

<CmsSpreadOption>
<Id>EUR-CMS-10Y-2Y-CONVENTION</Id>
<ForwardStart>0M</ForwardStart>
<SpotDays>2D</SpotDays>
<SwapTenor>3M</SwapTenor>
<FixingDays>2</FixingDays>
<Calendar>TARGET</Calendar>
<DayCounter>A360</DayCounter>
<RollConvention>MF</RollConvention>
</CmsSpreadOption>

The meaning of the elements is as follows:

• ForwardStart: The calendar for the fixed rate leg of the swap.
• SpotDays: The number of business days to spot for the CMS Spread Index.
• SwapTenor: The frequency of payments on the CMS Spread leg.
• FixingDays: The number of fixing days.
• Calendar: The calendar for the CMS Spread leg.
• DayCounter: The day counter for the CMS Spread leg.
• RollConvention: The rolling convention for the CMS Spread Leg.

7.12.14 Ibor Index Conventions

A node with name IborIndex is used to store conventions for Ibor indices. This can be
used to define new Ibor indices without the need of adding them to the C++ code, or
also to override the conventions of existing Ibor indices.

Listing 271: Ibor index convention

<IborIndex>
<Id>EUR-EURIBOR_ACT365-3M</Id>
<FixingCalendar>TARGET</FixingCalendar>
<DayCounter>A365F</DayCounter>
<SettlementDays>2</SettlementDays>
<BusinessDayConvention>MF</BusinessDayConvention>
<EndOfMonth>true</EndOfMonth>
</IborIndex>

The meaning of the elements is as follows:

• Id: The index name. This must be of the form “CCY-NAME-TENOR” with a
currency “CCY”, an index name “NAME” and a string “TENOR” representing a
period. The name should not be “GENERIC”, since this is reserved.
• FixingCalendar: The fixing calendar of the index.
• DayCounter: The day count convention used by the index.

328
 • SettlementDays: The settlement days for the index. This must be a non-negative
whole number.
• BusinessDayConvention: The business day convention used by the index.
• EndOfMonth: A flag indicating whether the index employs the end of month
convention.
Notice that if another convention depends on an Ibor index convention (because it
contains the Ibor index name defined in the latter convention), the Ibor index
convention must appear before the convention that depends on it in the convention
input file.
Also notice that customised indices can not be used in cap / floor volatility surface
configurations.

7.12.15 Overnight Index Conventions

A node with name OvernightIndex is used to store conventions for Overnight indices.
This can be used to define new Overnight indices without the need of adding them to
the C++ code, or also to override the conventions of existing Overnight indices.

Listing 272: Overnight index convention

<OvernightIndex>
<Id>EUR-ESTER</Id>
<FixingCalendar>TARGET</FixingCalendar>
<DayCounter>A360</DayCounter>
<SettlementDays>0</SettlementDays>
</OvernightIndex>

The meaning of the elements is as follows:

• Id: The index name. This must be of the form “CCY-NAME” with a currency
“CCY” and an index name “NAME”. The name should not be “GENERIC”, since
this is reserved.
• FixingCalendar: The fixing calendar of the index.
• DayCounter: The day count convention used by the index.
• SettlementDays: The settlement days for the index. This must be a non-negative
whole number.
Notice that if another convention depends on an Overnight index convention (because
it contains the Overnight index name defined in the latter convention), the Overnight
index convention must appear before the convention that depends on it in the
convention input file.
Also notice that customised indices can not be used in cap / floor volatility surface
configurations.

329
7.12.16 Inflation Index Conventions
A node with the name ZeroInflationIndex is used to store data for the creation of a
new inflation index. This avoids having to add the index definition to the C++ code
and recompile. Note that the ZeroInflationIndex node should be placed before its
use in any other convention, e.g. in an InflationSwap convention, to avoid an error
due to the new index itself not being created. If the Id node matches an existing
inflation index, the newly created index will take precedence and its defintion will be
used in the code for the given Id.

Listing 273: ZeroInflationIndex node

<ZeroInflationIndex>
<Id>...</Id>
<RegionName>...</RegionName>
<RegionCode>...</RegionCode>
<Revised>...</Revised>
<Frequency>...</Frequency>
<AvailabilityLag>...</AvailabilityLag>
<Currency>...</Currency>
</ZeroInflationIndex>

The meaning of each element is as follows:

• Id: The new inflation index name.
• RegionName: The name of the region with which the inflation index is associated.
• RegionCode: A code for the region with which the inflation index is associated.
• Revised: A boolean flag indicating whether the index is a revised index or not.
This is generally set to false but is left as an option to align with the C++
InflationIndex class definition.
• Frequency: A valid frequency indicating the publication frequency of the
inflation index, generally Monthly, Quarterly or Annual.
• AvailabilityLag: A valid period indicating the lag between the inflation index
publication for a given period and the period itself. For example, if March’s
inflation index value is published in April, the AvailabilityLag would be 1M.
• Currency: The ISO currency code of the currency associated with the inflation
index, generally the currency of the region.

7.12.17 Swap Index Conventions

A node with name SwapIndex is used to store conventions for Swap indices (also
known as “CMS” indices).

330
Listing 274: Swap index convention

<SwapIndex>
<Id>EUR-CMS-2Y</Id>
<Conventions>EUR-EURIBOR-6M-SWAP</Conventions>
<FixingCalendar>TARGET</FixingCalendar>
</SwapIndex>

The meaning of the elements is as follows:

• Id: The index name. This must be of the form “CCY-CMS-TENOR” with a
currency “CCY” and a string “TENOR” representing a period. The index name
can contain an optional tag “CCY-CMS-TAG-TENOR” which is an arbitrary
label that allows to define more than one swap index per currency.
• Conventions: A swap convention defining the index conventions.
• FixingCalendar [Optional]: The fixing calendar for the swap index fixings
publication. If not given, the fixed leg calendar from the swap conventions will be
used as a fall back.

7.12.18 FX Option Conventions

A node with name FxOption is used to store conventions for FX option quotes for a
given currency pair. The structure of this node is shown in Listing 275.

Listing 275: FX option conventions

<FxOption>
<Id>EUR-USD-FXOPTION</Id>
<FXConventionID>EUR-USD-FX</FXConventionID>
<AtmType>AtmDeltaNeutral</AtmType>
<DeltaType>Spot</DeltaType>
<SwitchTenor>2Y</SwitchTenor>
<LongTermAtmType>AtmDeltaNeutral</LongTermAtmType>
<LongTermDeltaType>Fwd</LongTermDeltaType>
<RiskReversalInFavorOf>Call</RiskReversalInFavorOf>
<ButterflyStyle>Broker</ButterflyStyle>
</FxOption>

The meanings of the various elements in this node are as follows:

• FXConventionID: The FX convention for the currency pair (see 7.12.10).
Optional, if not given, the FX spot days default to 2 and the advance calendar
defaults to source ccy + target ccy default calendars.
• AtmType: Convention of ATM option quote (Choices are AtmNull, AtmSpot,
AtmFwd, AtmDeltaNeutral, AtmVegaMax, AtmGammaMax, AtmPutCall50).
• DeltaType: Convention of Delta option quote (Choices are Spot, Fwd, PaSpot,
PaFwd).

331
 • SwitchTenor [Optional]: If given, different ATM and Delta conventions will be
used if the option tenor is greater or equal the switch tenor (“long term” atm and
delta type)
• LongTermAtmType [Mandatory if and only if SwitchTenor is given]: ATM type
to use for options with tenor > switch point, if SwitchTenor is given
• LongTermDeltaType [Mandatory if and only if SwitchTenor is given]: Delta type
to use for options with tenor > switch point, if SwitchTenor is given
• RiskReversalInFavorOf [Optional]: Call (default), Put. Only relevant for BF, RR
market data input.
• ButterflyStyle [Optional]: Broker (default), Smile. Only relevant for BF, RR
market data input.

7.12.19 Commodity Forward Conventions

A node with name CommodityForward is used to store conventions for commodity
forward price quotes. The structure of this node is shown in Listing 276.

Listing 276: Commodity forward conventions

<CommodityForward>
<Id>...</Id>
<SpotDays>...</SpotDays>
<PointsFactor>...</PointsFactor>
<AdvanceCalendar>...</AdvanceCalendar>
<SpotRelative>...</SpotRelative>
<BusinessDayConvention>...</BusinessDayConvention>
<Outright>...</Outright>
</CommodityForward>

The meanings of the various elements in this node are as follows:

• Id: The identifier for the commodity forward convention. The identifier here
should match the Name that would be provided for the commodity in the trade
XML as described in Table 42.
• SpotDays [Optional]: The number of business days to spot for the commodity.
Any non-negative integer is allowed here. If omitted, this takes a default value of
2.
• PointsFactor [Optional]: This is only used if Outright is false. Any positive
real number is allowed here. When Outright is false, the commodity forward
quotes are provided as points i.e. a number that should be added to the
commodity spot to give the outright commodity forward rate. The PointsFactor
is the number by which the points quote should be divided before adding it to the
spot quote to obtain the forward price. If omitted, this takes a default value of 1.
• AdvanceCalendar [Optional]: The business day calendar(s) used for advancing
dates for both spot and forwards. The allowable values are given in Table 34. If
omitted, it defaults to NullCalendar i.e. a calendar where all days are
considered good business days.

332
 • SpotRelative [Optional]: The allowable values are true and false. If true, the
forward tenor is interpreted as being relative to the spot date. If false, the
forward tenor is interpreted as being relative to the valuation date. If omitted, it
defaults to True.
• BusinessDayConvention [Optional]: The business day roll convention used to
adjust dates when getting from the valuation date to the spot date and the
forward maturity date. The allowable values are given in Table 30. If omitted, it
defaults to Following.
• Outright [Optional]: The allowable values are true and false. If true, the
forward quotes are interpreted as outright forward prices. If false, the forward
quotes are interpreted as points i.e. as a number that must be added to the spot
price to get the outright forward price. If omitted, it defaults to true.

7.12.20 Commodity Future Conventions

A node with name CommodityFuture is used to store conventions for commodity
future contracts and options on them. These conventions are used in commodity
derivative trades and commodity curve construction to calculate contract expiry dates.
The structure of this node is shown in Listing 277.
The meanings of the various elements in this node are as follows:
• Id: The identifier for the commodity future convention. The identifier here
should match the Name that would be provided for the commodity in the trade
XML as described in Table 42.
• AnchorDay [Optional]: This node is not applicable for daily future contracts and
hence is optional. It is necessary for future contracts with a monthly cycle or
greater or if the option contracts cycle is monthly or greater. This node is used
to give a date in the future contract month to use as a base date for calculating
the expiry date. It can contain a DayOfMonth node, a CalendarDaysBefore node
or an NthWeekday node:
– The DayOfMonth This node can contain any integer in the range 1, . . . , 31
indicating the day of the month. A value of 31 will guarantee that the last
day in the month is used a base date.
– The CalendarDaysBefore This node can contain any non-negative integer.
The contract expiry date is this number of calendar days before the first
calendar day of the contract month.
– The NthWeekday This node has the elements shown in Listing 278. This
node is used to indicate a date in a given month in the form of the n-th
named weekday of that month e.g. 3rd Wednesday. The allowable values for
Nth are 1, 2, 3, 4. The Weekday node takes a weekday in the form of the first
three characters of the weekday with the first character capitalised.
– The LastWeekday [Optional]: This node is used to indicate a date in a given
month in the form of the last named weekday of that month e.g. last
Wednesday. The node takes a weekday in the form of the first three
characters of the weekday with the first character capitalised.

333
 – The BusinessDaysAfter This node can contain any integer. If the number
is positive the contract expiry is the n-th business day of the contract
month. If the number is negative the contract expiry date is this number of
business days before the first calendar day of the contract month.
– The WeeklyDayOfTheWeek [Optional]: This node is used to indicate a date
in a given week in the form of the named weekday, e.g. Wednesday. This
node is mandatory for weekly contract frequencies and is not allowed with
any other frequency. The node takes a weekday in the form of the first three
characters of the weekday with the first character capitalised.
• ContractFrequency: This node indicates the frequency of the commodity future
contracts. The value here is usually Monthly or Quarterly, but allowed values
are Daily, Weekly, Monthly, Quaterly and Annual.
• Calendar: The business day trading calendar(s) applicable for the commodity
future contract.
• ExpiryCalendar [Optional]: The business day expiry calendar(s) applicable for
the commodity future contract. This calendar is used when deriving expiry
dates. If omitted, this defaults to the trading day calendar specified in the
Calendar node.
• ExpiryMonthLag [Optional]: The allowable values are any integer. This value
indicates the number of months from the month containing the expiry date to
the contract month. If 0, the commodity future contract expiry date is in the
contract month. If the value of ExpiryMonthLag is n > 0, the commodity future
contract expires in the n-th month prior to the contract month. If the value of
ExpiryMonthLag is n < 0, the commodity future contract expires in the n-th
month after the contract month. The value of ExpiryMonthLag is generally 0, 1
or 2. For example, NYMEX:CL has an ExpiryMonthLag of 1 and ICE:B has an
ExpiryMonthLag of 2. If omitted, it defaults to 0.
• OneContractMonth [Optional]: This node takes a calendar month in the form of
the first three characters of the month with the first character capitalised. The
month provided should be an arbitrary valid future contract month. It is used in
cases where the ContractFrequency is not Monthly in order to determine the
valid contract months. If omitted, it defaults to January.
• OffsetDays [Optional]: The number of business days that the expiry date is
before the base date where the base date is implied by the AnchorDay node
above. Any non-negative integer is allowed here. If omitted, this takes a default
value of zero.
• BusinessDayConvention [Optional]: The business day roll convention used to
adjust the expiry date. The allowable values are given in Table 30. If omitted, it
defaults to Preceding.
• AdjustBeforeOffset [Optional]: The allowable values are true and false. If
true, if the base date implied by the AnchorDay node above is not a good
business day according to the calendar provided in the Calendar node, this date
is adjusted before the offset specified in the OffsetDays is applied. If false, this
adjustment does not happen. If omitted, it defaults to true.

334
• IsAveraging [Optional]: The allowable values are true and false. This node
indicates if the future contract is based on the average commodity price of the
contract period. If omitted, it defaults to false.
• OptionExpiryOffset [Optional]: The number of business days that the option
expiry date is before the future expiry date. Any non-negative integer is allowed
here. If omitted, this takes a default value of zero and the expiry date of an
option on the future contract is assumed to equal the expiry date of the future
contract.
• ProhibitedExpiries [Optional]: This node can be used to specify explicit dates
which are not allowed as future contract expiry dates or as option expiry dates.
A useful example of this is the ICE Brent contract which has the following
constraint on expiry dates: If the day on which trading is due to cease would be
either: (i) the Business Day preceding Christmas Day, or (ii) the Business Day
preceding New Year’s Day, then trading shall cease on the next preceding Business
Day. Each Date node can take optional attributes. The default values of these
attributes is shown in Listing 277. The convention attribute accepts a valid
business day convention in the list Preceding, ModifiedPreceding, Following
and ModifiedFollowing. This convention indicates how the future expiry date
should be adjusted if it lands on the prohibited expiry Date. If omitted, the
default is Preceding. Both Preceding and ModifiedPreceding indicate that
the next available business day before the date is tested. Following and
ModifiedFollowing indicate that the next available business day after the date
is tested. The optionConvention attribute allows the same values and behaves
in the same way to determine how the option expiry date should be adjusted if it
lands on the prohibited expiry Date. The forFuture and forOption boolean
attributes enable the prohibited expiry to apply only for the future expiry date
or the option expiry date respectively by setting the value to false.
• OptionExpiryMonthLag [Optional]: The allowable values are any integer. This
value indicates the number of months from the month containing the option
expiry date to the month containing the expiry date. If 0, the commodity future
option contract expiry date is anchored in the same month as the commodity
future contract expiry date. If the value of OptionExpiryMonthLag is n > 0, the
commodity option future contract expires in the n-th month prior to the
commodity future contract expiry month. If the value of OptionExpiryMonthLag
is n < 0, the commodity option future contract expires in the n-th month after
the commodity future contract expiry month. The value of
OptionExpiryMonthLag should be equal to ExpiryMonthLag when
OptionExpiryOffset is used. The OptionExpiryMonthLag is rarely used. An
example is the Crude Palm Oil contract XKLS:FCPO where the future contract
expiry is in the delivery month and the option expiry is in the month that is 2
months prior to this. In this case, OptionExpiryMonthLag is 2. If omitted,
OptionExpiryMonthLag defaults to 0.
• OptionExpiryDay [Optional]: This node can contain any integer in the range
1, . . . , 31 indicating the day of the month on which an option expiry date is
anchored. A value of 31 will guarantee that the last day in the month is used a
base date. If omitted, this is not used. Setting this field takes precedence over

335
 OptionExpiryOffset.
• OptionBusinessDayConvention [Optional]: The business day convention used to
adjust the option expiry date to a good business day if OptionExpiryDay is used.
• OptionContractFrequency [Optional]: This node indicates the frequency of the
commodity future options if it differs from the frequency of the underlying future
contract. The value here is usually Monthly
• OptionNthWeekday [Optional]: This node has the elements shown in Listing 278.
This node is used to indicate a date in a given month in the form of the n-th
named weekday of that month e.g. 3rd Wednesday. The allowable values for Nth
are 1, 2, 3, 4. The Weekday node takes a weekday in the form of the first three
characters of the weekday with the first character capitalised.
• OptionBusinessDayConvention [Optional]: The business day convention used to
adjust the option expiry date to a good business day if OptionExpiryDay is used.
• OptionExpiryLastWeekdayOfMonth [Optional]: This node is used to indicate a
date in a given month in the form of the last named weekday of that month e.g.
last Wednesday. The node takes a weekday in the form of the first three
characters of the weekday with the first character capitalised.
• OptionExpiryWeeklyDayOfTheWeek [Optional]: This node is used to indicate a
date in a given week in the form of the named weekday, e.g. Wednesday. The
node takes a weekday in the form of the first three characters of the weekday
with the first character capitalised. This node is mandatory for weekly expiring
options. The node is not allowed to use with any other option contract frequency.
• OptionUnderlyingFutureConvention [Optional]: Sometimes the next contract
expiry, as specified in the convention, is not the correct option underlying. For
example the base metals options expiries on the 1st Wednesday of the contract
month, and during the first 3 months there are daily future contracts available.
The option underlying is not the future contract which matures on the option
expiry but the one which matures on the 3rd Wednesday of the month. This field
is referencing to an commodity future convention which specifies the correct
expiry date for the underlying contract.
• FutureContinuationMappings [Optional]: When building future curves, we may
use market data that has a continuation expiry, i.e. c1, c2, etc. , as opposed to
an explicit expiry date or tenor. In some cases, the continuation expiries coming
from the market data provider may skip serial months and therefore we use the
mapping here to map from the market data provider index to the relevant serial
month.
• OptionContinuationMappings [Optional]: When building option volatility
structures, we may use market data that has a continuation expiry, i.e. c1, c2,
etc. , as opposed to an explicit expiry date or tenor. In some cases, the
continuation expiries coming from the market data provider may skip serial
months and therefore we use the mapping here to map from the market data
provider index to the relevant serial month. For example, for the Crude Palm Oil
contract XKLS:FCPO, the option expiry months are serial up to the 9th month
and then alternate months. So, we would add a mapping from 10 to 11, 11 to 13

336
 and so on so that the correct option expiry is arrived at when reading the market
data quotes and constructing the option volatility structure.
• AveragingData [Optional]: This node is needed for future contracts that are
used in a piecewise commodity curve PriceSegment and whose underlying is the
average of other future prices or spot prices over a given period. An example is
the ICE PMI power contract with contract specifications outlined here. It is
described in detail below.
• HoursPerDay [Optional]: For power derivatives, quantities are sometimes given
as a quantity per hour. To deduce the quantity for the day which is multiplied by
that day’s future price, one needs to know the number of hours in the day
associated with the future price. For example ICE PDQ is the daily PJM
Western Hub Real Time Peak future contract. The price each day for this
contract is the average of the locational marginal prices (LMPs) for all hours
ending 08:00 to 23:00 Eastern Pacific Time. In other words, there are 16 hours in
the day that feed in to the average yielding this settlement price. For this
contract, HoursPerDay would be 16. This field is only needed if a trade XML
references this commodity contract, has CommodityQuantityFrequency set to
PerHour and has no HoursPerDay value set directly in the XML.
• SavingsTime [Optional]: For some derivatives, quantities are given as quantity
per calendar day and hour. The monthly quantity is then scaled by the number
of calendar days times hours per day (see above) plus or minus a daylight savings
correction. To compute the daylight savings correction a convention is needed
that describes the dates on which dates one hour is gained resp. lost. Currently
supported conventions are US, Null. Default is US if no convention is given.
• ValidContractMonths [Optional]: For some commodities the contract frequency
is almost monthly but for some calendar months there are no contracts listed. For
example Corn Futures are only listed for the expiry months March, May, July,
September and December. For those contracts the ContractFrequency need to be
set to Monthly and the valid months have to be added to this node. This node is
ignored for all other frequencies and if its omitted all calendar months are valid.
An example CommodityFuture node for the NYMEX WTI future contract, specified
here, is provided in Listing 279.
The AveragingData node referenced above has the structure shown in Listing 280.
The meaning of each of the fields is as follows:
• CommodityName: The name of the commodity being averaged.
• Conventions: The identifier for the conventions associated with the commodity
being averaged.
• Period: This indicates the averaging period relative to the future expiry date.
The allowable values are:
– PreviousMonth: The calendar month prior to the month in which the (top
level) future contract’s expiry date falls is used as the averaging period.
– ExpiryToExpiry: Given a (top level) future contract’s expiry date, the
averaging period is from and excluding the previous expiry date to and

337
 including the expiry date.
• PricingCalendar: The pricing calendar(s) used to determine the pricing dates
in the averaging period.
• UseBusinessDays [Optional]: A boolean flag that defaults to true if omitted.
When set to true, the pricing dates in the averaging period are the set of
PricingCalendar good business days. When set to false, the pricing dates in
the averaging period are the complement of the set of PricingCalendar good
business days. This may be useful in certain situations. For example, the
contract ICE PW2 with specifications here averages the PJM Western Hub
locational marginal prices over each day in the averaging period that is a
Saturday, Sunday or NERC holiday. So, in this case, UseBusinessDays would be
false and PricingCalendar would be US-NERC.
• DeliveryRollDays [Optional]: This node allows any non-negative integer value.
When averaging a commodity future contract price over the averaging period,
the averaging period may include an underlying future contract expiry date. This
node’s value indicates when we should begin using the next future contract’s
price in the averaging. If the value is zero, we should include the future contract
prices up to and including the contract expiry. If the value is one, we should
include the contract prices up to and including the day that is one business day
before the contract expiry and then switch to using the next future contract’s
price thereafter. Similarly for other non-negative integer values. If this node is
omitted, it is set to zero.
• FutureMonthOffset [Optional]: This node allows any non-negative integer value.
If this node is omitted, it is set to zero. This node indicates which future
contract is being referenced on each Pricing Date in the averaging period by
acting as an offset from the next available expiry date. If FutureMonthOffset is
zero, the settlement price of the next available monthly contract that has not
expired with respect to the Pricing Date is used as the price on that Pricing
Date. If FutureMonthOffset is one, the settlement price of the second available
monthly contract that has not expired with respect to the Pricing Date is used
as the price on that Pricing Date. Similarly for other positive values of
FutureMonthOffset.
• DailyExpiryOffset [Optional]: This node allows any non-negative integer value.
It should only be used where the CommodityName being averaged has a daily
contract frequency. If this node is omitted, it is set to zero. This node indicates
which future contract is being referenced on each Pricing Date in the averaging
period by acting as a business day offset, using the CommodityName’s expiry
calendar, from the Pricing Date. It is useful in the base metals market where the
future contract being averaged on each Pricing Date is the cash contract on that
Pricing Date i.e. the contract with expiry date two business days after the
Pricing Date.

7.12.21 Credit Default Swap Conventions

A node with name CDS is used to store conventions for credit default swaps. The
structure of this node is shown in Listing 281.

338
Listing 281: CDS conventions

<CDS>
<Id>...</Id>
<SettlementDays>...</SettlementDays>
<Calendar>...</Calendar>
<Frequency>...</Frequency>
<PaymentConvention>...</PaymentConvention>
<Rule>...</Rule>
<DayCounter>...</DayCounter>
<SettlesAccrual>...</SettlesAccrual>
<PaysAtDefaultTime>...</PaysAtDefaultTime>
</CDS>

The meanings of the various elements in this node are as follows:

• Id: The identifier for the CDS convention.
• SettlementDays: The number of days after the CDS trade date when protection
starts i.e. the Protection effective date or step-in date. Any non-negative integer
is allowed here. For standard CDS after, this is generally set to 1.
• Calendar: The calendar associated with the CDS. For non-JPY currencies, this
is generally WeekendsOnly to agree with the ISDA standard. For JPY CDS, the
ISDA standard calendar is TYO documented at
[Link] This could be set up as an additional
calendar or JPN could be used as a proxy. Allowable calendar values are given in
Table 34.
• Frequency: The frequency of fee leg payments for the CDS. The ISDA standard
is Quarterly but any valid frequency is allowed.
• PaymentConvention: The business day convention for payments on the CDS.
The ISDA standard is Following but any valid business day convention from
Table 30 is allowed.
• Rule: The date generation rule for the fee leg on the CDS. The ISDA standard is
CDS2015 but any valid date generation rule is allowed.
• DayCounter: The day counter for fee leg payments on the CDS. The ISDA
standard is A360 but any valid day counter from Table 35 is allowed.
• SettlesAccrual: A boolean value indicating if an accrued fee is due on the
occurrence of a credit event. Allowable boolean values are given in the Table 46.
In general, this is set true.
• PaysAtDefaultTime: A boolean value indicating if the accrued fee, on the
occurrence of a credit event, is payable at the credit event date or the end of the
fee period. A value of true indicates that the accrued is payable at the credit
event date and a value of false indicates that it is payable at the end of the fee
period. In general, this is set true.

339
7.12.22 Bond Yield Conventions
A node with name BondYield is used to store conventions for the conversion of bond
prices into bond yields. The structure of this node is shown in Listing 282.

Listing 282: Bond yield conventions

<BondYield>
<Id>CMB-DE-BUND-10Y</Id>
<Compounding>Compounded</Compounding>
<Frequency>Annual</Frequency>
<PriceType>Clean</PriceType>
<Accuracy>1.0e-8</Accuracy>
<MaxEvaluations>100</MaxEvaluations>
<Guess>0.05</Guess>
</BondYield>

The meaning of the elements is as follows:

• Id: The constant maturity index index name. This must be of the form
“CMB-FAMILY-TENOR” where FAMILY can consist of any number of tags
separated by “-”
• Compounding: Compounding of the yield - Simple, Compounded, Continuous,
SimpleThenCompounded
• Frequency: Frequency of the cash flows - Annual, Semiannual, Quarterly,
Monthly etc.
• PriceType: Dirty or Clean
• Accuracy/MaxEvaluations/Guess: QuantLib parameters that control the
convergence of the numerical price to yield conversion.

340
Listing 277: Commodity future conventions

<CommodityFuture>
<Id>...</Id>
<AnchorDay>
...
</AnchorDay>
<ContractFrequency>...</ContractFrequency>
<Calendar>...</Calendar>
<ExpiryCalendar>...</ExpiryCalendar>
<ExpiryMonthLag>...</ExpiryMonthLag>
<OneContractMonth>...</OneContractMonth>
<OffsetDays>...</OffsetDays>
<BusinessDayConvention>...</BusinessDayConvention>
<AdjustBeforeOffset>...</AdjustBeforeOffset>
<IsAveraging>...</IsAveraging>
<OptionExpiryOffset>...</OptionExpiryOffset>
<ProhibitedExpiries>
<Dates>
<Date forFuture="true" convention="Preceding" forOption="true"
,→ optionConvention="Preceding">...</Date>
...
</Dates>
</ProhibitedExpiries>
<OptionExpiryMonthLag>...</OptionExpiryMonthLag>
<OptionExpiryDay>...</OptionExpiryDay>
<OptionContractFrequency>...</OptionContractFrequency>
<OptionNthWeekday>
<Nth>...</Nth>
<Weekday>...</Weekday>
</OptionNthWeekday>
<OptionExpiryLastWeekdayOfMonth>...</OptionExpiryLastWeekdayOfMonth>
<OptionExpiryWeeklyDayOfTheWeek>...</OptionExpiryWeeklyDayOfTheWeek>
<OptionBusinessDayConvention>...</OptionBusinessDayConvention>
<FutureContinuationMappings>
<ContinuationMapping>
<From>...</From>
<To>...</To>
</ContinuationMapping>
...
</FutureContinuationMappings>
<OptionContinuationMappings>
<ContinuationMapping>
<From>...</From>
<To>...</To>
</ContinuationMapping>
...
</OptionContinuationMappings>
<AveragingData>
...
</AveragingData>
<HoursPerDay>...</HoursPerDay>
<SavingsTime>...<SavingsTime>
<ValidContractMonths>
<Month>...</Month>
</ValidContractMonths>
<OptionUnderlyingFutureConvention>...</OptionUnderlyingFutureConvention>
</CommodityFuture>

341
Listing 278: NthWeekday node outline

<NthWeekday>
<Nth>...</Nth>
<Weekday>...</Weekday>
</NthWeekday>

Listing 279: NYMEX WTI CommodityFuture node

<CommodityFuture>
<Id>NYMEX:CL</Id>
<AnchorDay>
<DayOfMonth>25</DayOfMonth>
</AnchorDay>
<ContractFrequency>Monthly</ContractFrequency>
<Calendar>US-NYSE</Calendar>
<ExpiryMonthLag>1</ExpiryMonthLag>
<OffsetDays>3</OffsetDays>
<BusinessDayConvention>Preceding</BusinessDayConvention>
<IsAveraging>false</IsAveraging>
</CommodityFuture>

Listing 280: AveragingData node structure

<AveragingData>
<CommodityName>...</CommodityName>
<Conventions>...</Conventions>
<Period>...</Period>
<PricingCalendar>...</PricingCalendar>
<UseBusinessDays>...</UseBusinessDays>
<DeliveryRollDays>...</DeliveryRollDays>
<FutureMonthOffset>...</FutureMonthOffset>
<DailyExpiryOffset>...</DailyExpiryOffset>
</AveragingData>

342
8 Trade Data
The trades that make up the portfolio are specified in an XML file where the portfolio
data is specified in a hierarchy of nodes and sub-nodes. The nodes containing
individual trade data are referred to as elements or XML elements. These are generally
the lowest level nodes.

The top level portfolio node is delimited by an opening <Portfolio> and a closing
</Portfolio> tag. Within the portfolio node, each trade is defined by a starting
<Trade id="[Tradeid]"> and a closing </Trade> tag. Further, the trade type is set
by the TradeType XML element. Each trade has an Envelope node that includes the
same XML elements for all trade types (Id, Type, Counterparty, Rating, NettingSetId)
plus the Additional fields node, and after that, a node containing trade specific data.

An example of a [Link] file with one Swap trade including the full envelope
node is shown in Listing 283.

Listing 283: Portfolio

<Portfolio>
<Trade id="Swap#1">
<TradeType> Swap </TradeType>
<Envelope>
<CounterParty> Counterparty#1 </CounterParty>
<NettingSetId> NettingSet#2 </NettingSetId>
<PortfolioIds>
<PortfoliodId> PF#1 </PortfolioId>
<PortfoliodId> PF#2 </PortfolioId>
</PortfolioIds>
<AdditionalFields>
<Sector> SectorA </Sector>
<Book> BookB </Book>
<Rating> A1 </Rating>
</AdditionalFields>
</Envelope>
<SwapData>
...
[Trade specific data for a Swap]
...
</SwapData>
</Trade>
</Portfolio>

A description of all portfolio data, i.e. of each node and XML element in the portfolio
file, with examples and allowable values follows below. There is only one XML
elements directly under the top level Portfolio node:
• TradeType: ORE currently supports 14 trade types.
Allowable values: ForwardRateAgreement, Swap, CapFloor, Swaption,
FxForward, FxSwap, FxOption, EquityForward, EquityOption, VarianceSwap,
CommodityForward, CommodityOption, CreditDefaultSwap, Bond

343
8.1 Envelope
The envelope node contains basic identifying details of a trade (Id, Type,
Counterparty, NettingSetId), a PortfolioIds node containing a list of portfolio
assignments, plus an AdditionalFields node where custom elements can be added for
informational purposes such as Book or Sector. Beside the custom elements within the
AdditionalFields node, the envelope contains the same elements for all Trade types.
The Id, Type, Counterparty and NettingSetId elements must have non-blank entries
for ORE to run. The meanings and allowable values of the various elements in the
Envelope node follow below.
• Id: The Id element in the envelope is used to identify trades within a portfolio.
It should be set to identical values as the Trade id=" " element.
Allowable values: Any alphanumeric string. The underscore (_) sign may be
used as well.
• Counterparty: Specifies the name of the counterparty of the trade. It is used to
show exposure analytics by counterparty.
Allowable values: Any alphanumeric string. Underscores (_) and blank spaces
may be used as well.
• NettingSetId [Optional]: The NettingSetId element specifies the identifier for
a netting set. If a NettingSetId is specified, the trade is eligible for close-out
netting under the terms of an associated ISDA agreement. The specified
NettingSetId must be defined within the netting set definitions file (see section
9). If left blank or omitted the trade will not belong to any netting set, and thus
not be eligible for netting.
Allowable values: Any alphanumeric string. Underscores (_) and blank spaces
may be used as well.
• PortfolioIds [Optional]: The PortfolioIds node allows the assignment of a given
trade to several portfolios, each enclosed in its own pair of tags <PortfolioId>
and </PortfolioId> . Note that ORE does not assume a hierarchical
organisation of such portfolios. If present, the portfolio IDs will be used in the
generation of some ORE reports such as the VaR report which provides
breakdown by any portfolio id that occurs in the trades’ envelopes.
Allowable values for each PortfolioId: Any string.
• AdditionalFields [Optional]: The AdditionalFields node allows the insertion of
additional trade information using custom XML elements. For example, elements
such as Sector, Desk or Folder can be used. The elements within the
AdditionalFields node are used for informational purposes only, and do not
affect any analytics in ORE.
Allowable values: Any custom element.

8.1.1 Netting Set Details

Instead of a single netting set ID, defined by a NettingSetId node, an alternative
NettingSetDetails node can be provided, which itself contains a NettingSetId

344
sub-node, and four other optional sub-nodes, which altogether allow for extending the
uniqueness of netting sets beyond the netting set ID. The allowable values for each
sub-node are any alphanumeric string. The underscore (‘_’) sign may be used as well.

The NettingSetDetails node is given in the following XML format:

Listing 284: Netting set details

<NettingSetDetails>
<NettingSetId> </NettingSetId>
<AgreementType> </AgreementType>
<CallType> </CallType>
<InitialMarginType> </InitialMarginType>
<LegalEntityId> </LegalEntityId>
</NettingSetDetails>

8.2 Trade Specific Data

After the envelope node, trade-specific data for each trade type supported by ORE is
included. Each trade type has its own trade data container which is defined by an XML
node containing a trade-specific configuration of individual XML tags - called elements
- and trade components. The trade components are defined by XML sub-nodes that
can be used within multiple trade data containers, i.e. by multiple trade types.

Details of trade-specific data for all trade types follow below.

8.2.1 Swap
The SwapData node is the trade data container for the Swap trade type. A Swap must
have at least one leg, and can have an unlimited number of legs. Each leg is
represented by a LegData trade component sub-node, described in section 8.3.3. An
example structure of a two-legged SwapData node is shown in Listing 285.
• Settlement [Optional]: Delivery type applicable to cross currency swaps, and
ignored for all other swap types. Delivery type does not impact pricing in ORE,
but npv results are produced with and without SIMM exemptions.
Settlement Cash indicates that principal exchanges on the cross currency swap
should be included in Initial Margin (IM). According to ISDA non-deliverable
(Cash) trades are excluded from the exemption from IM for the principal
exchange, i.e. the principal exchanges are included in IM.
Settlement Physical indicates that principal exchanges on the cross currency
swap should be excluded in IM (the ISDA exemption applies).
Allowable values: Cash or Physical. Defaults to Physical if left blank or omitted.

345
Listing 285: Swap data

<SwapData>
<Settlement>Cash</Settlement>
<LegData>
...
</LegData>
<LegData>
...
</LegData>
</SwapData>

Note that Swaps in non-deliverable currencies with payment in a deliverable currency

are supported by setting Settlement to Cash and - on both legs - using the Indexings
node (8.3.8), as well as setting the Currency to the deliverable currency, while keeping
the Notional expressed in the non-deliverable currency amount.
Within the Indexings node, an fx Index field is mandatory defining the deliverable and
non-deliverable currencies and fixing source. The Indexing node can also include
optional FixingCalendar, IsInArrears and FixingDays fields to determine the date(s) of
the fx fixing(s). See Listing 286 for an example non-deliverable IR swap where USD is
the payment currency and CLP is the non-deliverable currency.

346
Listing 286: Non deliverable single currency IR Swap

<SwapData>
<Settlement>Cash</Settlement>
<LegData>
<LegType>Fixed</LegType>
<Payer>false</Payer>
<Currency>USD</Currency><!-- Payment currency is USD rather than CLP -->
<Notionals>
<Notional>850000000</Notional><!-- in CLP -->
</Notionals>
<Indexings>
<Indexing>
<Index>FX-TR20H-CLP-USD</Index><!-- to convert CLP flows into USD -->
<FixingCalendar>CLP,USD</FixingCalendar>
<IsInArrears>true</IsInArrears>
<FixingDays>2</FixingDays>
</Indexing>
</Indexings>
...
</LegData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
<Currency>USD</Currency><!-- Payment currency is USD rather than CLP -->
<Notionals>
<Notional>850000000</Notional><!-- in CLP -->
</Notionals>
<Indexings>
<Indexing>
<Index>FX-TR20H-CLP-USD</Index><!-- to convert CLP flows into USD -->
<FixingCalendar>CLP,USD</FixingCalendar>
<IsInArrears>true</IsInArrears>
<FixingDays>2</FixingDays>
</Indexing>
</Indexings>
...
</LegData>
</SwapData>

8.2.2 Zero Coupon Swap

A Zero Coupon swap is set up as a swap (trade type Swap) , with one leg of type
ZeroCouponFixed. Listing 287 shows an example. The ZeroCouponFixed leg contains
an additional ZeroCouponFixedLegData block. See 8.3.19 for details on the
ZeroCouponFixed leg specification.

347
Listing 287: Zero Coupon Swap Data

<SwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
...
</LegData>
<LegData>
<LegType>ZeroCouponFixed</LegType>
<Payer>false</Payer>
...
<ZeroCouponFixedLegData>
<Rates>
<Rate>0.02</Rate>
</Rates>
<Compounding>Simple</Compounding>
</ZeroCouponFixedLegData>
</LegData>
</SwapData>

8.2.3 Cap/Floor
The CapFloorData node is the trade data container for the CapFloor trade type. It’s a
cap, floor or collar (i.e. a portfolio of a long cap and a short floor for a long position in
the collar) on a series of Ibor, SIFMA, OIS, CMS, Duration-adjusted CMS, CMS
Spread, CPI, YY coupons.
The CapFloorData node contains a LongShort sub-node which indicates whether the
cap (floor, collar) is long or short, and a LegData sub-node where the LegType can be
set to Floating, CMS, CMSSpread, DurationAdjustedCMS, CPI or YY, plus elements
for the Cap and Floor rates. An example structure with Cap rates is shown in in
Listing 288. The optional node PaymentDates in the LegData subnode is currently
only used for OIS and IBOR indices (see 8.3.3).
A CapFloorData node must have either Caps or Floors elements, or both. In the case
of both (I.e. a collar with long cap and short floor) the sequence is that Caps elements
must be above the Floors elements. Note that the Caps and Floors elements must be
outside the LegData sub-node, i.e. a CapFloor can’t have a capped or floored Floating
or CMS leg. The Payer flag in the LegData subnode is ignored for this instrument.
Notice that the signs in the definition of a collar (long cap, short floor) for the
CapFloor instruments is exactly opposite to 8.3.6.

348
Listing 288: Cap/Floor data

<CapFloorData>
<LongShort>Long</LongShort>
<LegData>
<Payer>false</Payer>
<LegType>Floating</LegType>
...
</LegData>
<Caps>
<Cap>0.05</Cap>
</Caps>
<Premiums>
<Premium>
<Amount>1000</Amount>
<Currency>EUR</Currency>
<PayDate>2021-01-27</PayDate>
</Premium>
</Premiums>
</CapFloorData>

The meanings and allowable values of the elements in the CapFloorData node follow
below.
• LongShort: This node defines the position in the cap (floor, collar) and can take
values Long or Short.
• LegData: This is a trade component sub-node outlined in section 8.3.3. Exactly
one LegData node is allowed, and the LegType element must be set to Floating
(Ibor and OIS), CMS, CMSSpread, DurationAdjustedCMS, CPI or YY.
• Caps: This node has child elements of type Cap capping the floating leg (after
applying spread if any). The first rate value corresponds to the first coupon, the
second rate value corresponds to the second coupon, etc. If the number of
coupons exceeds the number of rate values, the rate will be kept flat at the value
of last entered rate for the remaining coupons. For a fixed cap rate over all
coupons, one single rate value is sufficient. The number of entered rate values
cannot exceed the number of coupons.
Allowable values for each Cap element: Any real number. The rate is expressed
in decimal form, eg 0.05 is a rate of 5%
• Floors: This node has child elements of type Floor flooring the floating leg (after
applying spread if any). The first rate value corresponds to the first coupon, the
second rate value corresponds to the second coupon, etc. If the number of
coupons exceeds the number of rate values, the rate will be kept flat at the value
of last entered rate for the remaining coupons. For a fixed floor rate over all
coupons, one single rate value is sufficient. The number of entered rate values
cannot exceed the number of coupons.
Allowable values for each Floor element: Any real number. The rate is expressed
in decimal form, eg 0.05 is a rate of 5%
• Premiums [Optional]: Option premium amounts paid by the option buyer to the

349
 option seller.
Allowable values: See section 8.3.2

8.2.4 Forward Rate Agreement

A forward rate agreement (trade type ForwardRateAgreement is set up using a
ForwardRateAgreementData block as shown in listing 289. The forward rate
agreement specific elements are:
• StartDate: A FRA expires/settles on the startDate.
Allowable values: See Date in Table 30.
• EndDate: EndDate is the date when the forward loan or deposit ends. It follows
that (EndDate - StartDate) is the tenor/term of the underlying loan or deposit.
Allowable values: See Date in Table 30.
• Currency: The currency of the FRA notional.
Allowable values: See Table 32 Currency.
• Index: The name of the interest rate index the FRA is benchmarked against.
Allowable values: An alphanumeric string of the form CCY-INDEX-TENOR.
CCY, INDEX and TENOR must be separated by dashes (-). CCY and INDEX
must be among the supported currency and index combinations. TENOR must
be an integer followed by D, W, M or Y, except for Overnight indices which do
not require a TENOR. See Table 36.
• LongShort: Specifies whether the FRA position is long (one receives the agreed
rate) or short (one pays the agreed rate).
Allowable values: Long, Short.
• Strike: The agreed forward interest rate.
Allowable values: Any real number. The strike rate is expressed in decimal form,
e.g. 0.05 is a rate of 5%.
• Notional: No accretion or amortisation, just a constant notional.
Allowable values: Any positive real number.

Listing 289: Forward Rate Agreement Data

<ForwardRateAgreementData>
<StartDate>20161028</StartDate>
<EndDate>20351028</EndDate>
<Currency>EUR</Currency>
<Index>EUR-EURIBOR-6M</Index>
<LongShort>Long</LongShort>
<Strike>0.001</Strike>
<Notional>1000000000</Notional>
</ForwardRateAgreementData>

350
8.2.5 Swaption
The SwaptionData node is the trade data container for the Swaption trade type. The
SwaptionData node has one and exactly one OptionData trade component sub-node,
and at least one LegData trade component sub-node. These trade components are
outlined in section 8.3.1 and section 8.3.3.

Supported swaption exercise styles are European, Bermudan, American. Swaptions of

all exercise styles can have an arbitrary number of legs, with each leg represented by a
LegData sub-node. Cross currency swaptions are not supported for either exercise
style, i.e. the Currency element must have the same value for all LegData sub-nodes of
a swaption. There must be at least one full coupon period after the exercise date for
European Swaptions, and after the last exercise date for Bermudan and American
Swaptions. See Table 18 for further details on requirements for swaptions.

The structure of an example SwaptionData node of a European swaption is shown in

Listing 290.

Listing 290: Swaption data

<SwaptionData>
<OptionData>
<LongShort>Long</LongShort>
<Style>European</Style>
<Settlement>Physical</Settlement>
<ExerciseDates>
<ExerciseDate>2027-03-02</ExerciseDate>
</ExerciseDates>
...
<Premiums>
<Premium>
<Amount>807000</Amount>
<Currency>GBP</Currency>
<PayDate>2021-06-15</PayDate>
</Premium>
</Premiums>
</OptionData>
<LegData>
<LegType>Fixed</LegType>
<Payer>false</Payer>
<Currency>GBP</Currency>
...
</LegData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
<Currency>GBP</Currency>
...
</LegData>
</SwaptionData>

351
 A Swaption requires:
OptionData One OptionData sub-node
Style Bermudan or European or American
ExerciseDates European swaptions can only have one ExerciseDate
child element. American swaptions must have two
ExerciseDate child elements. Bermudan swaptions
must have at least two ExerciseDate child elements,
or a Rules or Dates based exercise schedule.
LegData At least one LegData sub-node
Currency The same currency for all LegData sub-nodes.
LegType Allowed types are Cashflow, Fixed or Floating. Float-
ing coupons can be (capped / floored) Ibor, (capped /
floored) compounded or averaged OIS, or BMA/SIFMA.
Standalone options (nakedOption = true) are not al-
lowed, neither are local OIS cap/floors.

Table 18: Requirements for Swaptions

The OptionData trade component sub-node is outlined in section 8.3.1. The relevant
fields in the OptionData node for a Swaption are:
• LongShort: The allowable values are Long or Short. Note that the payer and
receiver legs in the underlying swap are always from the perspective of the party
that is Long. E.g. for a Short swaption with a fixed leg where the Payer flag is
set to false, it means that the counterparty receives the fixed flows.

Payer for Fixed leg Payer for Floating leg

LongShort Resulting Set Up and Flows
on underlying Swap on underlying Swap
The Party to the trade buys an
option to enter a swap where the
Long true false
Party pays fixed and receives
floating
The Party to the trade sells an
option to the Counterparty to enter
Short true false
a swap where the Counterparty
pays fixed and receives floating
The Party to the trade buys an
option to enter a swap where the
Long false true
Party receives fixed and pays
floating
The Party to the trade sells an
option to the Counterparty to enter
Short false true
a swap where the Counterparty
receives fixed and pays floating

Table 19: Swaption set up and resulting flows

• OptionType[Optional]: This flag is optional for swaptions, and even if set, has no

352
 impact. Whether a swaption is a payer or receiver swaption is determined by the
Payer flags on the legs of the underlying swap.
• Style: The exercise style of the Swaption. The allowable values are European,
Bermudan or American.
• NoticePeriod[Optional]: The notice period defining the date (relative to the
exercise date) on which the exercise decision has to be taken. If not given the
notice period defaults to 0D, i.e. the notice date is identical to the exercise date.
Allowable values: A number followed by D, W, M, or Y
• NoticeCalendar[Optional]: The calendar used to compute the notice date from
the exercise date. If not given defaults to the NullCalendar (no holidays,
weekends are no holidays either). Allowable values: See Table 34 Calendar.
• NoticeConvention[Optional]: The roll convention used to compute the notice
date from the exercise date. Defaults to Unadjusted if not given. Allowable
values: See Table 31 Roll Convention.
• Settlement: Delivery Type. The allowable values are Cash or Physical. Note
that for TradeType CallableSwap only Physical is allowed.
• SettlementMethod[Optional]: Specifies the method to calculate the settlement
amount for Swaptions and CallableSwaps. Allowable values: PhysicalOTC,
PhysicalCleared, CollateralizedCashPrice, ParYieldCurve. Defaults to
ParYieldCurve if Settlement is Cash and defaults to PhysicalOTC if Settlement
is Physical.
PhysicalOTC = OTC traded swaptions with physical settlement
PhysicalCleared = Cleared swaptions with physical settlement
CollateralizedCashPrice = Cash settled swaptions with settlement price
calculation using zero coupon curve discounting
ParYieldCurve = Cash settled swaptions with settlement price calculation using
par yield discounting 9 10
• ExerciseFees[Optional]: This node contains child elements of type
ExerciseFee. Similar to a list of notionals (see 8.3.3) the fees can be given either
– as a list where each entry corresponds to an exercise date and the last entry
is used for all remaining exercise dates if there are more exercise dates than
exercise fee entries, or
– using the startDate attribute to specify a change in a fee from a certain
day on (w.r.t. the exercise date schedule)
Fees can either be given as an absolute amount or relative to the current notional
of the period immediately following the exercise date using the type attribute
together with specifiers Absolute resp. Percentage. If not given, the type
defaults to Absolute. Percentage fees are expressed in decimal form, e.g. 0.05 is
a fee of 5% of notional.
If a fee is given as a positive number the option holder has to pay a
9
[Link]
10
[Link]

353
 corresponding amount if they exercise the option. If the fee is negative on the
other hand, the option holder receives an amount on the option exercise.
Only supported for Swaptions and Callable Swaps currently.
• ExerciseFeeSettlementPeriod[Optional]: The settlement lag for exercise fee
payments. Defaults to 0D if not given. This lag is relative to the exercise date
(as opposed to the notice date). Allowable values: A number followed by D, W,
M, or Y
• ExerciseFeeSettlementCalendar[Optional]: The calendar used to compute the
exercise fee settlement date from the exercise date. If not given defaults to the
NullCalendar (no holidays, weekends are no holidays either). Allowable values:
See Table 34 Calendar.
• ExerciseFeeSettlementConvention[Optional]: The roll convention used to
compute the exercise fee settlement date from the exercise date. Defaults to
Unadjusted if not given. Allowable values: See Table 31 Roll Convention.
• An ExerciseDates node where for European style swaptions exactly one
ExerciseDate date element must be given, and for American style swaptions
exactly two ExerciseDate date element must be given, defining the start and the
end of the American exercise period. Bermudan style swaptions can have
ExerciseDate elements given directly (at least two ExerciseDate elements must
be given). See Listing 291
• Bermudan style swaptions can also have Rules or Dates based exercise dates
using an ExerciseSchedule node instead of ExerciseDates. See Listings 292
and 293.

Listing 291: Bermudan Swaption ExerciseDate:s

<SwaptionData>
<OptionData>
<LongShort>Long</LongShort>
<Style>Bermudan</Style>
<Settlement>Physical</Settlement>
<ExerciseDates>
<ExerciseDate>2027-03-02</ExerciseDate>
<ExerciseDate>2028-03-02</ExerciseDate>
<ExerciseDate>2029-03-02</ExerciseDate>
</ExerciseDates>
...
</OptionData>
...

354
Listing 292: Bermudan Swaption Rules based

<SwaptionData>
<OptionData>
<LongShort>Long</LongShort>
<Style>Bermudan</Style>
<Settlement>Physical</Settlement>
<ExerciseSchedule>
<Rules>
<StartDate>2027-03-02</StartDate>
<EndDate>2029-03-02</EndDate>
<Tenor>1Y</Tenor>
<Calendar>US</Calendar>
<Convention>MF</Convention>
</Rules>
</ExerciseSchedule>
...
</OptionData>
...

Listing 293: Bermudan Swaption Dates based

<SwaptionData>
<OptionData>
<LongShort>Long</LongShort>
<Style>Bermudan</Style>
<Settlement>Physical</Settlement>
<ExerciseSchedule>
<Dates>
<Calendar>NullCalendar</Calendar>
<Convention>Unadjusted</Convention>
<Dates>
<Date>2027-03-02</Date>
<Date>2028-03-02</Date>
<Date>2029-03-02</Date>
</Dates>
</Dates>
</ExerciseSchedule>
...
</OptionData>
...

• Premiums [Optional]: Option premium node with amounts paid by the option
buyer to the option seller.
Allowable values: See section 8.3.2
• An ExerciseData [Optional] node where one Date element must be given, and
one Price element can optionally also be given. See Listing 294
This node marks the Swaption as exercised. If the ExerciseData node is omitted
it is assumed the Swaption has not been exercised.
The effective exercise date is the next ExerciseDate in the ExerciseDates node
greater or equal the given Date in ExerciseData.

355
 For a cash-settled Swaption, the Price given in ExerciseData represents the
cash settlement amount. It is paid according to the PaymentData node: If an
explicit list of payment dates is given, the payment takes place on the next date
following the effective exercise date. If the PaymentData is rules-based, the
payment date is derived from the effective exercise date using the given calendar,
lag and convention.
If a Swaption is cash-settled and has an ExerciseData node with a Date but no
Price, then the Swaption is considered exercised on the given date, but without
a settlement amount being paid.

Listing 294: ExerciseData to mark a Swaption or CallableSwap as exercised

<ExerciseData>
<Date>2023-09-03</Date>
<Price>112000</Price>
</ExerciseData>

• A PaymentData [Optional] node can be added which defines dates or rules-based

settlement date(s) for cash-settled Swaptions. Note that if rules-based, only
Exercise is allowed in the RelativeTo field for Swaptions. See PaymentData in
8.3.1

8.2.6 Callable Swap

The CallableSwapData node is the trade data container for the CallableSwap trade
type. A Callable Swap is a swap that can be cancelled at predefined dates by one of
the counterparties. A Callable Swap must have at least one leg, each leg described by a
LegData trade component sub-node as described in section 8.3.3.
There must be at least one full coupon period after the exercise date for European
Callable Swaps, and after the last exercise date for Bermudan and American Callable
Swaps.
The CallableSwapData node also contains an OptionData node which describes the
exercise dates and specifies which party holds the call right, see 8.3.1. An example
structure of a CallableSwapData node is shown in Listing 295.

356
Listing 295: Callable Swap data

<CallableSwapData>
<OptionData>
<LongShort>Short</LongShort>
<Style>Bermudan</Style>
<Settlement>Physical</Settlement>
<ExerciseDates>
<ExerciseDate>2031-10-01</ExerciseDate>
<ExerciseDate>2032-10-01</ExerciseDate>
<ExerciseDate>2033-10-01</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<LegData>
<LegType>Fixed</LegType>
<Payer>false</Payer>
<Currency>USD</Currency>
...
</LegData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
<Currency>USD</Currency>
...
</LegData>
</CallableSwapData>

The meanings and allowable values of the elements in the CallableSwapData node
follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
exercise dates specify the dates on which one of the counterparties may terminate
the swap. The counterpart holding the call right is specified by the LongShort
flag. The Settlement should be set to Physical always. See also the OptionData
node outlined for a Swaption - see 8.2.5, which is identical for a CallableSwap
with the exception of the requirement that Settlement must be Physical. A
callable swap can be marked as exercised as explained in 8.2.5 using the
ExerciseData node within OptionData.
• LegData: This is a trade component sub-node described in section 8.3.3 outlining
each leg of the underlying Swap. A Callable Swap must have at least one leg on
the underlying Swap, but can have multiple legs, i.e. multiple LegData nodes.
The LegType elements must be of types Floating, Fixed or Cashflow. All legs
must have the same Currency.
Note that the direction of the legs, determined by the Payer tag, is like for a
Swap, from the perspective of the party to the trade. I.e. unlike for a Swaption
where the direction of the legs is from the perspective of the party that is long.

8.2.7 FX Forward
The FXForwardData node is the trade data container for the FxForward trade type.
The structure - including example values - of the FXForwardData node is shown in

357
Listing 296.

Listing 296: FX Forward data

<FxForwardData>
<ValueDate>2023-04-09</ValueDate>
<BoughtCurrency>EUR</BoughtCurrency>
<BoughtAmount>1000000</BoughtAmount>
<SoldCurrency>USD</SoldCurrency>
<SoldAmount>1500000</SoldAmount>
<Settlement>Physical</Settlement>
<SettlementData>
...
</SettlementData>
</FxForwardData>

The meanings and allowable values of the various elements in the FXForwardData node
follow below.
• ValueDate: The value date of the FX Forward.
Allowable values: See Date in Table 30.
• BoughtCurrency: The currency to be bought on value date.
Allowable values: See Table 32 Currency.
• BoughtAmount: The amount to be bought on value date.
Allowable values: Any positive real number.
• SoldCurrency: The currency to be sold on value date.
Allowable values: See Table 32 Currency.
• SoldAmount: The amount to be sold on value date.
Allowable values: Any positive real number.
• Settlement [Optional]: Delivery type. Note that Non-Deliverable Forwards can
be represented by Cash settlement.
Allowable values: Cash or Physical. Defaults to Physical if left blank or omitted.
• SettlementData [Optional]: This node is used to specify the settlement of the
cash flows on the value date.
A SettlementData node is shown in Listing 297, and the meanings and allowable
values of its elements follow below.
• Currency: The currency in which the FX Forward is settled. This field is only
used if settlement is Cash.
Allowable values: See Table 32 Currency. Defaults to the sold currency if left
blank or omitted.
• FXIndex: The FX reference index for determining the FX fixing at the value
date. This field is required if settlement is Cash and the payment date is greater
than the value date. Otherwise, it is ignored.
Allowable values: The format of the FXIndex is “FX-FixingSource-CCY1-CCY2”
as described in Table 38.

358
 • Date [Optional]: If specified, this will be the payment date.
Allowable values: See Date in Table 30. If left blank or omitted, defaults to the
value date with some adjustments applied from the Rules sub-node.
• Rules [Optional]: If Date is left blank or omitted, this node will be used to derive
the payment date from the value date. The Rules sub-node is shown in Listing
297, and the meanings and allowable values of its elements follow below.
– PaymentLag [Optional]: The lag between the value date and the payment
date.
Allowable values: Any valid period, i.e. a non-negative whole number,
optionally followed by D (days), W (weeks), M (months), Y (years). For
cash settlement and if a FXIndex is specified defaults to the fx convention
(field “SpotDays”) if blank or omitted, otherwise to 0. If a whole number is
given and no letter, it is assumed that it is a number of D (days).
– PaymentCalendar [Optional]: The calendar to be used when applying the
payment lag.
Allowable values: See Table 34 Calendar. For cash settlement and if a
FXIndex is specified defaults to the fx convention (field “AdvanceCalendar”)
if left blank or omitted, otherwise to NullCalendar (no holidays).
– PaymentConvention [Optional]: The roll convention to be used when
applying the payment lag.
Allowable values: See Table 31 Roll Convention. For cash settlement and if
a FXIndex is specified defaults to the fx convention ((field “Convention”) if
left blank or omitted, otherwise to Unadjusted.
Note that FX Forwards also cover Precious Metals forwards, i.e. with currencies XAU,
XAG, XPT, XPD, and Cryptocurrency forwards, see supported Cryptocurrencies in
Table 32.

Listing 297: Example SettlementData node with Rules sub-node

<SettlementData>
<Currency>USD</Currency>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
<Date>2020-09-03</Date>
<Rules>
<PaymentLag>2D</PaymentLag>
<PaymentCalendar>USD</PaymentCalendar>
<PaymentConvention>Following</PaymentConvention>
</Rules>
</SettlementData>

8.2.8 FX Average Forward

The FXAverageForwardData node is the trade data container for the
FxAverageForward trade type. The structure with example values node is shown in
Listing 298.

359
Listing 298: FX Average Forward data

<FxAverageForwardData>
<PaymentDate>2023-04-09</PaymentDate>
<!-- Schedule block that determines observation dates for FX averaging -->
<ObservationDates>
...
</ObservationDates>
<FixedPayer>true</FixedPayer>
<ReferenceNotional>8614</ReferenceNotional>
<ReferenceCurrency>EUR</ReferenceCurrency>
<SettlementNotional>10000</SettlementNotional>
<SettlementCurrency>USD</SettlementCurrency>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
<Settlement>Cash</Settlement>
</FxAverageForwardData>

The instrument’s payoff is driven by an arithmetic average of observed FX rates,

expressed in terms of the node names:

ω × (ReferenceNotional × AverageFX − SettlementNotional)

The meanings and allowable values of the various elements in the

FXAverageForwardData node follow below.
• PaymentDate: The date of the settlement cash flow.
Allowable values: See Date in Table 30.
• ObservationDates: Schedule data that determine the observation dates that are
taken into account in the FX rate averaging. See section 8.3.4
• FixedPayer: If true, the payoff multiplier ω is set to 1, otherwise -1.
Allowable values: true, false
• ReferenceNotional: The amount to be converted into settlement currency at the
average FX rate
Allowable values: Any positive real number.
• ReferenceCurrency: The currency of the reference notional above.
Allowable values: See Table 32 Currency.
• SettlementNotional: The fixed amount to be paid or received depending on the
fixed payer flag above
Allowable values: Any positive real number.
• SettlementCurrency: The currency of the settlement notional above.
Allowable values: See Table 32 Currency.
• FXIndex: The FX reference index for determining the FX fixing for averaging.
Allowable values: The format of the FXIndex is “FX-FixingSource-CCY1-CCY2”
as described in Table 38. Notice that since the payoff is based on an arithmetic
average, the order of the currencies in the FX index matters: The averaging will
be done on fx rates quoted as CCY1-CCY2 (foreign-domestic).

360
8.2.9 FX Swap
The FXSwapData node is the trade data container for the FxSwap trade type. The
structure - including example values - of the FXSwapData node is shown in Listing 299.
It contains no sub-nodes.

Listing 299: FX Swap data

<FxSwapData>
<NearDate>2018-09-01</NearDate>
<NearBoughtCurrency>EUR</NearBoughtCurrency>
<NearBoughtAmount>1000000</NearBoughtAmount>
<NearSoldCurrency>USD</NearSoldCurrency>
<NearSoldAmount>1140000</NearSoldAmount>
<FarDate>2028-09-01</FarDate>
<FarBoughtAmount>1300000</FarBoughtAmount>
<FarSoldAmount>1000000</FarSoldAmount>
<Settlement>Cash</Settlement>
</FxSwapData>

The meanings and allowable values of the various elements in the FXSwapData node
follow below. All elements are required.
• NearDate: The date of the initial fx exchange of the FX Swap.
Allowable values: See Date in Table 30.
• NearBoughtCurrency: The currency to be bought in the initial exchange at near
date, and sold in the final exchange at far date.
Allowable values: See Table 32 Currency.
• NearBoughtAmount: The amount to be bought on near date.
Allowable values: Any positive real number.
• NearSoldCurrency: The currency to be sold in the initial fx exchange at near
date, and bought in the final exchange at far date.
Allowable values: See Table 32 Currency.
• NearSoldAmount: The amount to be sold on near date.
Allowable values: Any positive real number.
• FarDate: The date of the final fx exchange of the FX Swap.
Allowable values: Any date further into the future than NearDate. See Date in
Table 30.
• FarBoughtAmount: The amount to be bought on far date.
Allowable values: Any positive real number.
• FarSoldAmount: The amount to be sold on far date.
Allowable values: Any positive real number.
• Settlement [Optional]: Delivery type. Note that Non-Deliverable FX Swaps can
be represented by Cash settlement, and that deliverable FX Swaps will be
excluded from the CRIF output. Delivery type does not impact pricing in ORE.
Allowable values: Cash or Physical. Defaults to Physical if left blank or omitted.

361
Note that FX Swaps also cover Precious Metals swaps, i.e. with currencies XAU, XAG,
XPT, XPD, and Cryptocurrency swaps, see supported Cryptocurrencies in Table 32.

8.2.10 FX Option
The FXOptionData node is the trade data container for the FxOption trade type. FX
options with exercise styles European or American are supported. The FXOptionData
node includes one and only one OptionData trade component sub-node plus elements
specific to the FX Option. The structure of an FXOptionData node for an FX Option
is shown in Listing 300.

Listing 300: FX Option data

<FxOptionData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>European</Style>
<Settlement>Cash</Settlement>
<PayOffAtExpiry>false</PayOffAtExpiry>
<ExerciseDates>
<ExerciseDate>2026-03-01</ExerciseDate>
</ExerciseDates>
<Premiums>
<Premium>
<Amount>10900</Amount>
<Currency>EUR</Currency>
<PayDate>2020-03-01</PayDate>
</Premium>
</Premiums>
</OptionData>
<BoughtCurrency>EUR</BoughtCurrency>
<BoughtAmount>1000000</BoughtAmount>
<SoldCurrency>USD</SoldCurrency>
<SoldAmount>1700000</SoldAmount>
</FxOptionData>

The meanings and allowable values of the elements in the FXOptionData node follow
below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an FxOption are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put. For option type Put,
Bought and Sold currencies/amounts are switched compared to the trade
data node. For example, a holder of BoughtCurrency EUR SoldCurrency
USD FX Call Option has the right to buy EUR using USD, while holder of
the Put counterpart has the right to buy USD using EUR, or equivalently
sell EUR for USD.
– Style The allowable values are European or American.
– Settlement The allowable values are Cash or Physical.

362
 – PayOffAtExpiry [Optional] The allowable values are true for payoff at
expiry, or false for payoff at exercise (relevant for American style
FxOptions). Defaults to true if left blank or omitted.
– AutomaticExercise [Optional] The allowable values are true indicating
Automatic Exercise is applicable and false indicates that it is not. Used if
the FXOption expiry date is on the current date or in the past, and the
payment date is in the future - so that there still is an outstanding cashflow
if the FXOption was in the money on the expiry date. In this case, if
AutomaticExercise is applied, the FX fixing on the expiry date is used to
automatically determine the payoff and thus whether the option was
exercised or not. Defaults to false if left blank or omitted.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given. For American style FxOptions the ExerciseDate represents the
Expiry date, i.e. they can be exercised up until this date.
– A PaymentData [Optional] node can be added which defines the settlement
date of the option payoff. See PaymentData in 8.3.1
– Premiums [Optional]: Option premium amounts paid by the option buyer to
the option seller. See section 8.3.2
See 8.3.1 for further specifications of the OptionData node.
• BoughtCurrency: The bought currency of the FX option. See OptionData above
for more details.
Allowable values: See Table 32.
• BoughtAmount: The amount in the BoughtCurrency.
Allowable values: Any positive real number.
• SoldCurrency: The sold currency of the FX option. See OptionData above for
more details.
Allowable values: See Table 32.
• SoldAmount: The amount in the SoldCurrency.
Allowable values: Any positive real number.
• FXIndex [Optional]: If the option European, has cash settlement and is subject
to Automatic Exercise, as indicated by the AutomaticExercise node under
OptionData, this node must be populated with a valid FX index. The FX index
is used to retrieve an FX rate on the expiry date that is in turn used to
determine the payoff on the cash settlement date. The payoff is in the
SoldCurrency i.e. the domestic currency.
Allowable values: A valid FX index from the Table 38.
Note that FX Options also cover Precious Metals Options, i.e. with currencies XAU,
XAG, XPT, XPD, and Cryptocurrency options, see supported Cryptocurrencies in
Table 32.

363
8.2.11 FX Asian Option
The FxAsianOptionData node is the trade data container for the FxAsianOption trade
type. The FxAsianOptionData node includes one OptionData trade component
sub-node plus elements specific to the FX Asian Option.
A FX Asian Option is a path-dependent option whose payoff depends upon the
averaged foreign exchange rate over a pre-set period of time.
The structure of an example FxAsianOptionData node for a FX Asian Option is
shown in Listing 301.

Listing 301: FX Asian Option data

<Trade id="FxAsianOption">
<TradeType>FxAsianOption</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields />
</Envelope>
<FxAsianOptionData>
<Currency>USD</Currency>
<Quantity>100</Quantity>
<Strike>1.05</Strike>
<Underlying>
<Type>FX</Type>
<Name>ECB-EUR-USD</Name>
</Underlying>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<PayoffType>Asian</PayoffType>
<PayoffType2>Arithmetic</PayoffType2>
<ExerciseDates>
<ExerciseDate>2020-07-15</ExerciseDate>
</ExerciseDates>
</OptionData>
<Settlement>2020-07-20</Settlement>
<ObservationDates>
<Rules>
<StartDate>2019-12-27</StartDate>
<EndDate>2020-07-06</EndDate>
<Tenor>1D</Tenor>
<Calendar>US</Calendar>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ObservationDates>
</FxAsianOptionData>
</Trade>

In the above example, the holder of the FxAsianOption has a call option that gives the
right but not obligation to pay 105 USD (the strike) and receive 100*[the average
USDEUR FX rate during the Asian period] USD (the underlying).

364
If OptionType would be changed to Put, the holder of the option would have the right
to receive 105 USD (the strike) and pay 100*[the average USDEUR FX rate during the
Asian period] USD (the underlying).
The payoff is:
P ayof f = Quantity · M AX(ω · (A(0, T ) − K), 0)
where:
• A(0, T ): the arithmetic average FX rate over the Asian observation period from
start 0 to end T, expressed as amount of CCY2 per one unit of CCY1.
• K: strike FX rate, expressed as amount of CCY2 per one unit of CCY1.
• ω: 1 for a call option (ie receiving averaged FX and paying strike), -1 for a put
option
The meanings and allowable values of the elements in the FxAsianOptionData node
follow below.
• Currency: The payoff currency.
Allowable values: See Table 32 Currency.
• Quantity: The quantity of the underlying currency (CCY1). See payoff formula
above.
Allowable values: all positive real numbers
• Strike: The strike of the option, expressed as amount of CCY2 per one unit of
CCY1.
Allowable values: all positive real numbers
• Underlying: An Underlying node where Type must be set to FX and Name is the
foreign exchange currency pair (on the form SOURCE-CCY1-CCY2) including
the Currency above typically as CCY2 and another currency defined as the
underlying currency as CCY1.
Allowable values: See 8.3.29
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an FxAsianOption are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put.
– PayoffType which must be set to Asian or AverageStrike to identify a fixed
or floating strike asian payoff,
– PayoffType2 [Optional] can be optionally set to Arithmetic or Geometric
and defaults to Arithmetic if not given.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– A PaymentData [Optional] node can be added which defines the settlement
of the option payoff.
– A Premiums [Optional] node can be added to represent deterministic option
premia to be paid by the option holder. See section 8.3.2

365
 • Settlement[Optional]: The settlement date.
Allowable values: See Date in Table 30. Defaults to the ExerciseDate if left blank
or omitted.
• ObservationDates: The observation dates for the asian period, given as a
rules-based or dates-based schedule, analogous to a ScheduleData node but
called ObservationDates.
Allowable values: See the definition in 8.3.4

8.2.12 FX Barrier Option

European exercise, American barrier.
The FxBarrierOptionData node is the trade data container for the FxBarrierOption
trade type. The barrier level of an FX Barrier Option is quoted as the amount in
SoldCurrency per unit BoughtCurrency. The FxBarrierOptionData node includes one
OptionData trade component sub-node and one BarrierData trade component
sub-node plus elements specific to the FX Barrier Option.
An FX Barrier option is a path-dependent option whose existence depends upon an
FX spot rate reaching a pre-set barrier level. Exercise is European.
This product has a continuously monitored single barrier (American Barrier style) with
a Vanilla European FX Option Underlying.
The structure of an example FxBarrierOptionData node for a FX Barrier Option is
shown in Listing 302.

366
Listing 302: FX Barrier Option data

<FxBarrierOptionData>
<OptionData>
<LongShort>Long</LongShort>
<!-- Bought and Sold currencies/amounts are switched for Put -->
<OptionType>Call</OptionType>
<Style>European</Style>
<Settlement>Cash</Settlement>
<ExerciseDates>
<ExerciseDate>2021-12-14</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<BarrierData>
<Type>UpAndIn</Type>
<Levels>
<Level>1.2</Level>
</Levels>
<Rebate>0.0</Rebate>
</BarrierData>
<StartDate>2019-01-25</StartDate>
<Calendar>TARGET</Calendar>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
<BoughtCurrency>EUR</BoughtCurrency>
<BoughtAmount>1000000</BoughtAmount>
<SoldCurrency>USD</SoldCurrency>
<SoldAmount>1100000</SoldAmount>
</FxBarrierOptionData>

The meanings and allowable values of the elements in the FxBarrierOptionData node
follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an FxBarrierOption are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put.
Call means that the holder of the option, upon expiry - assuming knock-in
or no knock-out - has the right to receive the BoughtAmount and pay the
SoldAmount.
Put means that the Bought and Sold currencies/amounts are switched
compared to the trade data node. For example, holder of BoughtCurrency
EUR SoldCurrency JPY FX Barrier Call Option has the right to buy EUR
using JPY, while holder of the Put counterpart has the right to buy JPY
using EUR, or equivalently sell EUR for JPY. An alternative to define the
latter option is to copy the Call option with following changes:
a) swapping BoughtCurrency with SoldCurrency, b) swapping
BoughtAmount with SoldAmount and c) inverting the barrier level (for
example changing 110 to 0.0090909). Here barrier level is quoted as amount
of EUR per unit JPY, which is not commonly seen on market and
inconsistent with the format in Call options. For these reasons, using
Put/Call flag instead is recommended.

367
 – Style The FX Barrier Option type allows for European option exercise style
only.
– Settlement The allowable values are Cash or Physical.
– A PaymentData [Optional] node can be added which defines the settlement
of the option payoff.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer to
the option seller. See section 8.3.2
• BarrierData: This is a trade component sub-node outlined in section 8.3.31.
Level specified in BarrierData should be quoted as the amount in SoldCurrency
per unit BoughtCurrency, with both currencies as defined in
FxBarrierOptionData node. Note that the barrier Level stays quoted as
SoldCurrency per unit BoughtCurrency, regardless of Put/Call.
• StartDate [Optional]: The start date for checking if a barrier has been breached
prior to today’s date. If omitted or left blank no check is made and it is assumed
no barrier has been breached in the past. Has no impact if set to today’s date or
a date in the future.
Allowable values: See Date in Table 30.
• Calendar [Optional]: The calendar associated with the FX Index. Required if
StartDate is set to a date prior to today’s date, otherwise optional.
Allowable values: See Table 34 Calendar.
• FXIndex [Optional]: A reference to an FX Index source to check if the barrier has
been breached. Required if StartDate is set to a date prior to today’s date,
otherwise optional and can be omitted but not left blank.
Allowable values: The format of the FX Index is“FX-SOURCE-CCY1-CCY2” as
described in table 38.
• BoughtCurrency: The bought currency of the FX barrier option. See
OptionData above for more details.
Allowable values: See Table 32 Currency.
• BoughtAmount: The amount in the BoughtCurrency.
Allowable values: Any positive real number.
• SoldCurrency: The sold currency of the FX barrier option. See OptionData
above for more details.
Allowable values: See Table 32 Currency.
• SoldAmount: The amount in the SoldCurrency.
Allowable values: Any positive real number.

368
Note that FX Barrier Options also cover Precious Metals, i.e. with currencies XAU,
XAG, XPT, XPD, and Cryptocurrencies, see supported Cryptocurrencies in Table 32.

8.2.13 FX Digital Barrier Option

The FxDigitalBarrierOptionData node is the trade data container for the
FxDigitalBarrierOption trade type. The FxDigitalBarrierOptionData node includes
one OptionData trade component sub-node and one BarrierData trade component
sub-node plus elements specific to the FX Digital Barrier Option.
An FX Digital Barrier Option pays a given cash amount in domestic currency at
expiry, if the underlying fx rate has hit (or not hit) a continuously monitored barrier
(as for the FxTouchOption) and the fx rate at the expiry date is above (call) or below
(put) a given strike.
The structure of an example FxDigitalBarrierOptionData node for a FX Digital
Barrier Option is shown in Listing 303.

Listing 303: FX Digital Barrier Option data

<FxDigitalBarrierOptionData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>European</Style>
<Settlement>Cash</Settlement>
<ExerciseDates>
<ExerciseDate>2021-12-14</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<BarrierData>
<Type>DownAndIn</Type>
<Levels>
<Level>1.18</Level>
</Levels>
</BarrierData>
<StartDate>2019-01-25</StartDate>
<Calendar>TARGET</Calendar>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
<Strike>1.1</Strike>
<PayoffAmount>100000</PayoffAmount>
<PayoffCurrency>USD</PayoffCurrency>
<ForeignCurrency>EUR</ForeignCurrency>
<DomesticCurrency>USD</DomesticCurrency>
</FxDigitalBarrierOptionData>

The meanings and allowable values of the elements in the

FxDigitalBarrierOptionData node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an FxDigitalBarrierOption are:
– LongShort The allowable values are Long or Short.

369
 – OptionType The allowable values are Call or Put. Given knock-in or no
knock-out, Call means that the digital payout will occur if the fx rate at the
expiry date is above the given strike, and Put means that the digital payout
will occur if the fx rate at the expiry date is below the given strike.
– Style The FX Digital Barrier Option type allows for European option
exercise style only.
– Settlement The allowable values are Cash or Physical.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer
to the option seller.
Allowable values: See section 8.3.2
• BarrierData: This is a trade component sub-node outlined in section 8.3.31.
Note that the FxDigitalBarrierOption is a single barrier instrument, and can
have only one BarrierData node with one barrier level.
Level specified in BarrierData should be quoted as the amount in
DomesticCurrency per one unit of ForeignCurrency, with both currencies as
defined in FxDigitalBarrierOptionData node.
Type specified in BarrierData can be one of: UpAndIn, DownAndIn, UpAndOut,
DownAndOut
• StartDate[Optional]: The start date for checking if a barrier has been breached
prior to today’s date. If omitted or left blank no check is made and it is assumed
no barrier has been breached in the past. Has no impact if set to today’s date or
a date in the future. If‘StartDate’ is provided then the fixings for dates between
this date and the asof date are checked to see if the option was triggered. If no
fixing is available then we skip that date. This is to allow for backwards
compatibility.
Allowable values: See Date in Table 30.
• Calendar[Optional]: The calendar associated with the FX Index. Required if
StartDate is set to a date prior to today’s date, otherwise optional.
Allowable values: See Table 34 Calendar.
• FXIndex[Optional]: A reference to an FX Index source to check if the barrier has
been breached. Required if StartDate is set to a date prior to today’s date,
otherwise optional, and can be omitted but not left blank.
Allowable values: The format of the FX Index is“FX-SOURCE-CCY1-CCY2” as
described in table 38.
• Strike: The FX strike price, expressed as the amount in DomesticCurrency per
one unit of ForeignCurrency.
Allowable values: Any positive real number.

370
 • PayoffAmount: The fixed payoff amount expressed in the PayoffCurrency. It is
cash-or-nothing payoff that depends on the option being in or out of the money,
and whether the barrier has been breached.
Allowable values: Any positive real number.
• PayoffCurrency[Optional]: The payoff currency of the FX digital option is the
currency of the payoff amount. Must be either the Domestic or Foreign currency
for this trade, If omitted this defaults to DomesticCurrency as defined in
FxDigitalBarrierOptionData node.
Allowable values: See Table 32 Currency.
• ForeignCurrency: The foreign currency of the FX digital barrier option is
equivalent to the bought currency.
Allowable values: See Table 32 Currency.
• DomesticCurrency: The domestic currency of the FX digital barrier option is
equivalent to the sold currency.
Allowable values: See Table 32 Currency.
Note that FX Digital Barrier Options also cover Precious Metals, i.e. with currencies
XAU, XAG, XPT, XPD, and Cryptocurrencies, see supported Cryptocurrencies in
Table 32.

8.2.14 FX Digital Option

The FxDigitalOptionData node is the trade data container for the FxDigitalOption
trade type. The FxDigitalOptionData node includes one OptionData trade
component sub-node plus elements specific to the FX Digital Option. The structure of
an example FxDigitalOptionData node for a FX Digital Option is shown in Listing
304.

Listing 304: FX Digital Option data

<FxDigitalOptionData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>European</Style>
<Settlement>Cash</Settlement>
<ExerciseDates>
<ExerciseDate>2021-12-14</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<Strike>1.1</Strike>
<PayoffCurrency>USD</PayoffCurrency>
<PayoffAmount>100000</PayoffAmount>
<ForeignCurrency>EUR</ForeignCurrency>
<DomesticCurrency>USD</DomesticCurrency>
</FxDigitalOptionData>

371
The meanings and allowable values of the elements in the FxDigitalOptionData node
follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an FxDigitalOption are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put. Call means that the
digital payout will occur if the fx rate at the expiry date is above the given
strike, and Put means that the digital payout will occur if the fx rate at the
expiry date is below the given strike.
– Style The FX Digital Option type allows for European option exercise style
only.
– Settlement The allowable values are Cash or Physical.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer
to the option seller.
Allowable values: See section 8.3.2
• Strike: The FX strike price, expressed as the amount in DomesticCurrency per
one unit of ForeignCurrency.
Allowable values: Any positive real number.
• PayoffCurrency[Optional]: The payoff currency of the FX digital option is the
currency of the payoff amount. Must be either the Domestic or Foreign currency
for this trade, If omitted this defaults to the domestic currency.
Allowable values: See Table 32 Currency.
• PayoffAmount: The fixed payoff amount expressed in payoff currency. It is
cash-or-nothing payoff that depends on the option being in or out of the money.
Allowable values: Any positive real number.
• ForeignCurrency: The foreign currency of the FX digital option is equivalent to
the bought currency.
Allowable values: See Table 32 Currency.
• DomesticCurrency: The domestic currency of the FX digital option is equivalent
to the sold currency.
Allowable values: See Table 32 Currency.
Note that FX Digital Options also cover Precious Metals, i.e. with currencies XAU,
XAG, XPT, XPD, and Cryptocurrencies, see supported Cryptocurrencies in Table 32.

372
8.2.15 FX Double Barrier Option
The FxDoubleBarrierOptionData node is the trade data container for the
FxDoubleBarrierOption trade type.
An FX Double Barrier Option is a path-dependent option whose existence depends
upon an FX spot rate reaching one of the two pre-set barrier levels. Exercise is
European, and barriers are American (continuously monitored).
FX Double Barrier options can be knock-in or knock-out:
• A knock-in option is a barrier option that only comes into existence/becomes
active when the FX spot rate reaches the one of the barrier level at any point in
the option’s life. Once a barrier is knocked-in, the option will not cease to exist
until the option expires and effectively it becomes a Vanilla FX Option.
• A knock-out option starts its life active, but ceases to exist/becomes inactive, if
the one of the barriers is reached during the life of the option.
The barrier levels of an FX Double Barrier Option are quoted as the amount in
SoldCurrency per unit BoughtCurrency. The FxDoubleBarrierOptionData node
includes one OptionData trade component sub-node and one BarrierData trade
component sub-node plus elements specific to the FX Double Barrier Option. The
structure of an example FxDoubleBarrierOptionData node for a FX Double Barrier
Option is shown in Listing 305.

Listing 305: FX Double Barrier Option data

<FxDoubleBarrierOptionData>
<OptionData>
<LongShort>Long</LongShort>
<!-- Bought and Sold currencies/amounts are switched for Put -->
<OptionType>Call</OptionType>
<Style>European</Style>
<ExerciseDates>
<ExerciseDate>2021-12-14</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<BarrierData>
<Type>KnockOut</Type> <!-- KnockOut or KnockIn -->
<Levels>
<Level>1.1</Level>
<Level>1.2</Level>
</Levels>
<Rebate>0.0</Rebate>
</BarrierData>
<StartDate>2019-01-25</StartDate>
<Calendar>TARGET</Calendar>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
<BoughtCurrency>EUR</BoughtCurrency>
<BoughtAmount>1000000</BoughtAmount>
<SoldCurrency>USD</SoldCurrency>
<SoldAmount>1100000</SoldAmount>
</FxDoubleBarrierOptionData>

373
The meanings and allowable values of the elements in the
FxDoubleBarrierOptionData node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an FxDoubleBarrierOption are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put.
Call means that the holder of the option, upon expiry - assuming knock-in
or no knock-out - has the right to receive the BoughtAmount and pay the
SoldAmount.
Put means that the Bought and Sold currencies/amounts are switched
compared to the trade data node. For example, holder of BoughtCurrency
EUR SoldCurrency JPY FX Double Barrier Call Option has the right to
buy EUR using JPY, while holder of the Put counterpart has the right to
buy JPY using EUR, or equivalently sell EUR for JPY. An alternative to
define the latter option is to copy the Call option with following changes:
a) swapping BoughtCurrency with SoldCurrency, b) swapping
BoughtAmount with SoldAmount and c) inverting the barrier level (for
example changing 110 to 0.0090909). Here barrier level is quoted as amount
of EUR per unit JPY, which is not commonly seen on market and
inconsistent with the format in Call options. For these reasons, using
Put/Call flag instead is recommended.
– Style The FX Double Barrier Option type allows for European option
exercise style only.
– Settlement The allowable values are Cash or Physical.
– A PaymentData [Optional] node can be added which defines the settlement
of the option payoff.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer to
the option seller.
Allowable values: See section 8.3.2
• BarrierData: This is a trade component sub-node outlined in section 8.3.31.
Levels specified in BarrierData should be quoted as the amount in SoldCurrnecy
per unit BoughtCurrency, with both currencies as defined in
FxDoubleBarrierOptionData node. Changing the option from Call to Put or vice
versa does not require switching the barrier levels. Two levels in ascending order
should be defined in Levels. Type should be KnockOut or KnockIn.
• StartDate [Optional]: The start date for checking if a barrier has been breached
prior to today’s date. If omitted or left blank no check is made and it is assumed
no barrier has been breached in the past. Has no impact if set to today’s date or
a date in the future.
Allowable values: See Date in Table 30.

374
 • Calendar [Optional]: The calendar associated with the FX Index. Required if
StartDate is set to a date prior to today’s date, otherwise optional.
Allowable values: See Table 34 Calendar.
• FXIndex [Optional]: A reference to an FX Index source to check if the barrier has
been breached. Required if StartDate is set to a date prior to today’s date,
otherwise optional and can be omitted but not left blank.
Allowable values: The format of the FX Index is“FX-SOURCE-CCY1-CCY2” as
described in table 38.
• BoughtCurrency: The bought currency of the FX barrier option. See
OptionData above for more details.
Allowable values: See Table 32 Currency.
• BoughtAmount: The amount in the BoughtCurrency.
Allowable values: Any positive real number.
• SoldCurrency: The sold currency of the FX barrier option. See OptionData
above for more details.
Allowable values: See Table 32 Currency.
• SoldAmount: The amount in the SoldCurrency.
Allowable values: Any positive real number.

8.2.16 FX Double Touch Option

The FxDoubleTouchOptionData node is the trade data container for the
FxDoubleTouchOption trade type. The FxDoubleTouchOptionData node includes one
OptionData trade component sub-node and one BarrierData trade component
sub-node plus elements specific to the FX Double Touch Option.
An FX Double Touch Option pays a given cash amount (PayoffAmount) at expiry or
at hit if the underlying fx rate has hit either of the barriers (KnockIn) resp. has not
hit any of barriers (KnockOut) using continuous monitoring between start and expiry
date. No rebates are supported.
The structure of an example FxDoubleTouchOptionData node for an FX Double
Touch Option is shown in Listing 306.

375
Listing 306: FX Double Touch Option data

<FxDoubleTouchOptionData>
<OptionData>
<LongShort>Long</LongShort>
<PayOffAtExpiry>true</PayOffAtExpiry>
<ExerciseDates>
<ExerciseDate>2021-12-14</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<BarrierData>
...
<Type>KnockOut</Type> <!-- KnockOut or KnockIn -->
<Levels>
<Level>1.1</Level>
<Level>1.2</Level>
</Levels>
...
</BarrierData>
<ForeignCurrency>EUR</ForeignCurrency>
<DomesticCurrency>USD</DomesticCurrency>
<PayoffCurrency>USD</PayoffCurrency>
<PayoffAmount>100000</PayoffAmount>
<StartDate>2019-01-25</StartDate>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
<Calendar>TARGET</Calendar>
</FxDoubleTouchOptionData>

The meanings and allowable values of the elements in the FxDoubleTouchOptionData

node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an FxDoubleTouchOption are as
below. Note that the OptionType can be omitted.
– LongShort The allowable values are Long or Short.
– PayOffAtExpiry [Optional] true for payoff at expiry and false for payoff at
hit. Currently, for both KnockOut and KnockIn barriers, only payoff at
expiry (i.e. true) is supported. Defaults to true if left blank or omitted.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– PaymentData [Optional]: This defines the settlement of the option payoff.
– Premiums [Optional]: Option premium amounts paid by the option buyer to
the option seller.
Allowable values: See section 8.3.2
• BarrierData: This is a trade component sub-node outlined in section 8.3.31.
Two levels in ascending order should be defined in Levels. Type should be
KnockOut or KnockIn. Levels specified in BarrierData should be quoted as the

376
 amount in DomesticCurrency (sold currency) per unit ForeignCurrency (bought
currency).
• ForeignCurrency: The foreign currency of the FX touch option is equivalent to
the bought currency.
Allowable values: See Table 32 Currency.
• DomesticCurrency: The domestic currency of the FX touch option is equivalent
to the sold currency.
Allowable values: See Table 32 Currency.
• PayoffCurrency: The payoff currency of the FX touch option is the currency of
the payoff amount.
Allowable values: See Table 32 Currency.
• PayoffAmount: The fixed payoff amount expressed in payoff currency. It is
cash-or-nothing payoff that depends on the option being in or out of the money,
and whether the barrier has been touched.
Allowable values: Any positive real number.
• StartDate [Optional]: The start date for checking if a barrier has been breached
prior to today’s date. If omitted or left blank no check is made and it is assumed
no barrier has been breached in the past. Has no impact if set to today’s date or
a date in the future.
Allowable values: See Date in Table 30.
• FXIndex [Optional]: A reference to an FX Index source to check if the barrier has
been breached. Required if StartDate is set to a date prior to today’s date,
otherwise optional, and can be omitted but not left blank.
Allowable values: The format of the FX Index is“FX-SOURCE-CCY1-CCY2” as
described in table 38.
• Calendar [Optional]: The calendar associated with the FX Index. Required if
StartDate is set to a date prior to today’s date, otherwise optional.
Allowable values: See Table 34 Calendar.

8.2.17 FX European Barrier Option

European exercise, European barrier.
The FxEuropeanBarrierOptionData node is the trade data container for the
FxEuropeanBarrierOption trade type. The barrier level of an FX European Barrier
Option is quoted as the amount in SoldCurrency per unit BoughtCurrency. The
FxEuropeanBarrierOptionData node includes one OptionData trade component
sub-node and one BarrierData trade component sub-node plus elements specific to
the FX Barrier Option.
An FX European Barrier option gives the buyer the right, but not the obligation, to
exchange a set amount of one currency for another, at a predetermined exchange rate,
at one predetermined time in the future. This right may be withdrawn depending upon

377
an FX spot rate reaching a predetermined barrier level at the predetermined time, the
underlying is monitored only at expiry with a single barrier (European Barrier style).
The structure of an example FxEuropeanBarrierOptionData node for a FX European
Barrier Option is shown in Listing 307.

Listing 307: FX European Barrier Option data

<FxEuropeanBarrierOptionData>
<OptionData>
<LongShort>Long</LongShort>
<!-- Bought and Sold currencies/amounts are switched for Put -->
<OptionType>Call</OptionType>
<Style>European</Style>
<Settlement>Cash</Settlement>
<ExerciseDates>
<ExerciseDate>2021-12-14</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<BarrierData>
<Type>UpAndIn</Type>
<Levels>
<Level>1.2</Level>
</Levels>
<Rebate>100000</Rebate>
</BarrierData>
<BoughtCurrency>EUR</BoughtCurrency>
<BoughtAmount>1000000</BoughtAmount>
<SoldCurrency>USD</SoldCurrency>
<SoldAmount>1100000</SoldAmount>
</FxEuropeanBarrierOptionData>

The meanings and allowable values of the elements in the

FxEuropeanBarrierOptionData node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an FxEuropeanBarrierOption are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put.
Call means that the holder of the option, upon expiry - assuming knock-in
or no knock-out - has the right to receive the BoughtAmount and pay the
SoldAmount.
Put means that the Bought and Sold currencies/amounts are switched
compared to the trade data node. For example, holder of BoughtCurrency
EUR SoldCurrency JPY FX European Barrier Call Option has the right to
buy EUR using JPY, while holder of the Put counterpart has the right to
buy JPY using EUR, or equivalently sell EUR for JPY. An alternative to
define the latter option is to copy the Call option with following changes:
a) swapping BoughtCurrency with SoldCurrency, b) swapping
BoughtAmount with SoldAmount and c) inverting the barrier level (for
example changing 110 to 0.0090909). Here barrier level is quoted as amount

378
 of EUR per unit JPY, which is not commonly seen on market and
inconsistent with the format in Call options. For these reasons, using
Put/Call flag instead is recommended.
– Style The FX European Barrier Option type allows for European option
exercise style only.
– Settlement The allowable values are Cash or Physical.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– A PaymentData [Optional] node can be added which defines the settlement
date of the option payoff.
– Premiums [Optional]: Option premium amounts paid by the option buyer to
the option seller. See section 8.3.2
• BarrierData: This is a trade component sub-node outlined in section 8.3.31.
Level specified in BarrierData should be quoted as the amount in SoldCurrency
per unit BoughtCurrency, with both currencies as defined in
FxEuropeanBarrierOptionData node. Changing the option from Call to Put or
vice versa does not require switching the barrier level, i.e. the level stays quoted
as SoldCurrency per unit BoughtCurrency, regardless of Put/Call.
• BoughtCurrency: The bought currency of the FX barrier option. See
OptionData above for more details.
Allowable values: See Table 32 Currency.
• BoughtAmount: The amount in the BoughtCurrency.
Allowable values: Any positive real number.
• SoldCurrency: The sold currency of the FX barrier option. See OptionData
above for more details.
Allowable values: See Table 32 Currency.
• SoldAmount: The amount in the SoldCurrency.
Allowable values: Any positive real number.
Note that FX European Barrier Options also cover Precious Metals, i.e. with
currencies XAU, XAG, XPT, XPD, and Cryptocurrencies, see supported
Cryptocurrencies in Table 32.

8.2.18 FX KIKO Barrier Option

European exercise, American barriers.
The FXKIKOBarrierOptionData node is the trade data container for the
FxKIKOBarrierOption trade type.
An FX KIKO Barrier option is an option with both a knock-out and a knock-in barrier.
The knock-out barrier can be happen at any time (American barrier), and once the
knock-in barrier is hit the trade becomes a single (American) barrier knock-out trade.

379
The KIKO option can only be exercised (one time, European style) if the knock-out
barrier is never touched and the knock-in barrier is touched at least once.
The strike rate and barrier levels of an FX KIKO Barrier Option are expressed as
amount in SoldCurrency per unit BoughtCurrency.
The FXKIKOBarrierOptionData node includes one OptionData trade component
sub-node and two BarrierData trade component sub-nodes plus elements specific to
the FX KIKO Barrier Option. The structure of an example
FXKIKOBarrierOptionData node for a FX KIKO Barrier Option is shown in Listing
308.

Listing 308: FX KIKO Barrier Option data

<FxKIKOBarrierOptionData>
<OptionData>
<LongShort>Long</LongShort>
<!-- Bought and Sold currencies/amounts are switched for Put -->
<OptionType>Call</OptionType>
<Style>European</Style>
<Settlement>Cash</Settlement>
<ExerciseDates>
<ExerciseDate>2021-12-14</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<Barriers>
<BarrierData>
<Type>UpAndIn</Type>
<Levels>
<Level>1.2</Level>
</Levels>
</BarrierData>
<BarrierData>
<Type>DownAndOut</Type>
<Levels>
<Level>1.2</Level>
</Levels>
</BarrierData>
</Barriers>
<StartDate>2019-01-25</StartDate>
<Calendar>TARGET</Calendar>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
<BoughtCurrency>EUR</BoughtCurrency>
<BoughtAmount>1000000</BoughtAmount>
<SoldCurrency>USD</SoldCurrency>
<SoldAmount>1100000</SoldAmount>
</FxKIKOBarrierOptionData>

The meanings and allowable values of the elements in the FXKIKOBarrierOptionData

node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an FxKIKOBarrierOption are:
– LongShort The allowable values are Long or Short.

380
 – OptionType The allowable values are Call or Put.
Call means that the holder of the option, upon expiry - assuming knock-in
or no knock-out - has the right to receive the BoughtAmount and pay the
SoldAmount.
Put means that the Bought and Sold currencies/amounts are switched
compared to the trade data node. For example, holder of BoughtCurrency
EUR SoldCurrency JPY FX KIKO Barrier Call Option has the right to buy
EUR using JPY, while holder of the Put counterpart has the right to buy
JPY using EUR, or equivalently sell EUR for JPY. An alternative to define
the latter option is to copy the Call option with following changes:
a) swapping BoughtCurrency with SoldCurrency, b) swapping
BoughtAmount with SoldAmount and c) inverting the barrier level (for
example changing 110 to 0.0090909). Here barrier level is quoted as amount
of EUR per unit JPY, which is not commonly seen on market and
inconsistent with the format in Call options. For these reasons, using
Put/Call flag instead is recommended.
– Style The FX KIKO Barrier Option type allows for European option
exercise style only.
– Settlement The allowable values are Cash or Physical.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer
to the option seller.
Allowable values: See section 8.3.2
• Barriers: This node contains two barrierData nodes, one must be a KnockIn
barrier (UpAndIn or DownAndIn) and the other must be a KnockOut barrier
(UpAndOut or DownAndOut).
• BarrierData: This is a trade component sub-node outlined in section 8.3.31.
FxKIKOBarrierOptions do not currently support rebates. Level specified in
BarrierData should be quoted as the amount in SoldCurrency per unit
BoughtCurrency, with both currencies as defined in FxKIKOBarrierOptionData
node. Changing the option from Call to Put or vice versa does not require
switching the barrier level, i.e. the level stays quoted as SoldCurrency per unit
BoughtCurrency, regardless of Put/Call.
• StartDate[Optional]: The start date for checking if a barrier has been breached
prior to today’s date. If omitted or left blank no check is made and it is assumed
no barrier has been breached in the past. Has no impact if set to today’s date or
a date in the future.
Allowable values: See Date in Table 30.
• Calendar[Optional]: The calendar associated with the FX Index. Required if
StartDate is set to a date prior to today’s date, otherwise optional.
Allowable values: See Table 34 Calendar.

381
 • FXIndex[Optional]: A reference to an FX Index source to check if the barrier has
been breached. Required if StartDate is set to a date prior to today’s date,
otherwise optional and can be omitted but not left blank.
Allowable values: The format of the FX Index is“FX-SOURCE-CCY1-CCY2” as
described in table 38.
• BoughtCurrency: The bought currency of the FX barrier option. See
OptionData above for more details.
Allowable values: See Table 32 Currency.
• BoughtAmount: The amount in the BoughtCurrency.
Allowable values: Any positive real number.
• SoldCurrency: The sold currency of the FX barrier option. See OptionData
above for more details.
Allowable values: See Table 32 Currency.
• SoldAmount: The amount in the SoldCurrency.
Allowable values: Any positive real number.
Note that FX KIKO Options also cover Precious Metals, i.e. with currencies XAU,
XAG, XPT, XPD, and Cryptocurrencies, see supported Cryptocurrencies in Table 32.

8.2.19 FX Touch Option

The FxTouchOptionData node is the trade data container for the FxTouchOption
trade type. The FxTouchOptionData node includes one OptionData trade component
sub-node and one BarrierData trade component sub-node plus elements specific to
the FX Touch Option.
An FX Touch Option pays a given cash amount (PayoffAmount) at expiry or at hit if
the underlying fx rate has hit a barrier (UpAndIn, DownAndIn - called One Touch)
resp. has not hit a barrier (UpAndOut, DownAndOut - called No Touch) using
continuous monitoring between start and expiry date. No rebates are supported.
The structure of an example FxTouchOptionData node for an FX Touch Option is
shown in Listing 309.

382
Listing 309: FX Touch Option data

<FxTouchOptionData>
<OptionData>
<LongShort>Long</LongShort>
<PayOffAtExpiry>true</PayOffAtExpiry>
<ExerciseDates>
<ExerciseDate>2021-12-14</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<BarrierData>
<Type>DownAndOut</Type>
<Levels>
<Level>0.009</Level>
</Levels>
</BarrierData>
<ForeignCurrency>JPY</ForeignCurrency>
<DomesticCurrency>USD</DomesticCurrency>
<PayoffCurrency>USD</PayoffCurrency>
<PayoffAmount>100000</PayoffAmount>
<StartDate>2019-01-25</StartDate>
<FXIndex>FX-TR20H-USD-JPY</FXIndex>
<Calendar>NYB,TKB</Calendar>
</FxTouchOptionData>

The meanings and allowable values of the elements in the FxTouchOptionData node
follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
OptionType sub-node is not required and is inferred from the BarrierData type
(i.e. Call for an Up barrier, and Put for a Down barrier). The relevant fields in
the OptionData node for an FxTouchOption are:
– LongShort The allowable values are Long or Short.
– PayOffAtExpiry [Optional] true for payoff at expiry and false for payoff at
hit. For UpAndOut and DownAndOut barrier, only payoff at expiry ( true)
is supported. Defaults to true if left blank or omitted. This field is ignored
in pricing, and the option payoff will be calculated at expiry. This field only
has an impact on the description of the trade economics. The
GenericBarrierOption can also be used to ‘replicate’ the FXTouchOption
with payoff at hit if required.
– An ExerciseDates node where exactly one ExerciseDate date element
must be given.
– A PaymentData [Optional] node can be added which defines the settlement
of the option payoff. If the option is payoff at hit, (i.e. PayoffAtExpiry is
false), the option payment data must be rules-based, and the RelativeTo
sub-node of (Rules) must be set to Exercise.
– Premiums [Optional]: Option premium amounts paid by the option buyer to
the option seller.

383
 Allowable values: See section 8.3.2
• BarrierData: This is a trade component sub-node outlined in section 8.3.31.
Level specified in BarrierData should be quoted as the amount in
DomesticCurrency (sold currency) per unit ForeignCurrency (bought currency).
Note that the level stays quoted as DomesticCurrency per unit ForeignCurrency,
regardless of barrier type.
• ForeignCurrency: The foreign (bought) currency of the FX touch option.
Allowable values: See Table 32 Currency.
• DomesticCurrency: The domestic (sold) currency of the FX touch option.
Allowable values: See Table 32 Currency.
• PayoffCurrency: The payoff currency of the FX touch option is the currency of
the payoff amount.
Allowable values: See Table 32 Currency.
• PayoffAmount: The fixed payoff amount expressed in payoff currency. It is
cash-or-nothing payoff that depends on the option being in or out of the money,
and whether the barrier has been touched.
Allowable values: Any positive real number.
• StartDate [Optional]: The start date for checking if a barrier has been breached
prior to today’s date. If omitted or left blank no check is made and it is assumed
no barrier has been breached in the past. Has no impact if set to today’s date or
a date in the future.
Allowable values: See Date in Table 30.
• FXIndex [Optional]: A reference to an FX Index source to check if the barrier has
been breached. Required if StartDate is set to a date prior to today’s date,
otherwise optional, and can be omitted but not left blank.
Allowable values: The format of the FX Index is“FX-SOURCE-CCY1-CCY2” as
described in table 38.
• Calendar [Optional]: The calendar associated with the FX Index. Required if
StartDate is set to a date prior to today’s date, otherwise optional.
Allowable values: See Table 34 Calendar.
Note that FX Touch Options also cover Precious Metals, i.e. with currencies XAU,
XAG, XPT, XPD, and Cryptocurrencies, see supported Cryptocurrencies in Table 32.

8.2.20 FX Variance and Volatility Swap

The FxVarianceSwapData node is the trade data container for the FxVarianceSwap
trade type. Only vanilla variance swaps are supported by this trade type - exotic
variance swaps are supported by ScriptedTrade. The structure of an example
VarianceSwapData node for an FX variance swap is shown in Listing 310.

384
Listing 310: Variance Swap data

<FxVarianceSwapData>
<StartDate>2018-05-10</StartDate>
<EndDate>2018-11-12</EndDate>
<Currency>EUR</Currency>
<Underlying>
<Type>FX</Type>
<Name>ECB-EUR-JPY</Name>
</Underlying>
<LongShort>Long</LongShort>
<Strike>0.05</Strike>
<Notional>200000</Notional>
<Calendar>EUR</Calendar>
<MomentType>Variance</MomentType>
</FxVarianceSwapData>

The meanings and allowable values of the elements in the FxVarianceSwapData node
below.
• StartDate: The variance swap start date.
Allowable values: See Date in Table 30.
• EndDate: The variance swap end date.
Allowable values: See Date in Table 30.
• Currency: The bought currency of the variance swap.
Allowable values: See Table 32 Currency.
• Name: The identifier of the underlying currency pair.
Allowable values: A string of the form SOURCE-CCY1-CCY2, where SOURCE
is the fixing source and the fixing is expressed as amount in CCY2 per one unit
of CCY1.
See Table 38. Note that FxVarianceSwap is an exception in that the ordering of
CCY1 and CCY2 must be set up as for FxIndex.
• Underlying: This node may be used as an alternative to the Name node to specify
the underlying FX. The Underlying node is described in further detail in Section
8.3.29.
• LongShort: Defines whether the trade is long in the FX variance. For the
avoidance of doubt, a long FX swap has positive value if the realised variance
exceeds the variance strike.
Allowable values: Long, Short
• Strike: The volatility strike Kvol of the variance swap quoted absolutely (i.e. not
as a percent). If the swap was struck in terms of variance, the square root of that
variance should be used here.
Allowable values: Any positive real number.
• Notional: The vega notional of the variance swap. This is the notional in terms
of volatility units (like the strike). If the swap was struck in terms of a variance
notional Nvar , the corresponding vega notional is given by
Nvol = Nvar ∗ 2 ∗ 100 ∗ Kvol (where Kvol is in absolute terms).

385
 Allowable values: Any non-negative real number.
• Calendar: The calendar determining the observation/fixing dates according to
which variance is accrued is the combination of the calendar(s) given here plus
the combined calendars of the two involved currencies.
Allowable values: See Table 34.
• MomentType[Optional]: A flag to distinguish if the swap is struck in terms of
volatility or variance. The MomentType should be set to Volatility or Variance
depending on the payoff. Note that MomentType does not necessarily need to be
equivalent to the way the Strike is quoted which is always as a Volatility.
Allowable values: Volatility or Variance. Defaults to Variance if left blank or
omitted.
Note that FX Variance and Volatility Swaps also cover Precious Metals, i.e. with
currencies XAU, XAG, XPT, XPD, and Cryptocurrencies, see supported
Cryptocurrencies in Table 32.

8.2.21 Equity Option

The EquityOptionData node is the trade data container for the EquityOption trade
type. Equity options with exercise styles European and American are supported. For a
Quanto payoff and Composite equity options, only European exercise is supported.
Quanto payoff means that the payoff Currency is different than currency the
underlying equity is quoted in.
Composite or "compo" equity options have a StrikeCurrency that is different than
currency the underlying equity is quoted in. (This is unrelated to the CompositeTrade
trade type.)
The EquityOptionData node includes one and only one OptionData trade component
sub-node plus elements specific to the equity option. The structure of an example
EquityOptionData node for an equity option is shown in Listing 311.

Listing 311: Equity Option data

<EquityOptionData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>American</Style>
<Settlement>Cash</Settlement>
<PayOffAtExpiry>true</PayOffAtExpiry>
<ExerciseDates>
<ExerciseDate>2022-03-01</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<Name>RIC:.SPX</Name>
<Currency>USD</Currency>
<Strike>2147.56</Strike>
<StrikeCurrency>USD</StrikeCurrency>
<Quantity>17000</Quantity>
</EquityOptionData>

386
The meanings and allowable values of the elements in the EquityOptionData node
follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1 Option
Data. The relevant fields in the OptionData node for an EquityOption are:
– LongShort: The allowable values are Long or Short.
– OptionType: The allowable values are Call or Put. Call means that the
option holder has the right to buy the given quantity of the underlying
equity at the strike price. Put means that the option holder has the right to
sell the given quantity of the underlying equity at the strike price.
– Style: The allowable values are European and American. For Quanto
payoffs, i.e. if Currency and underlying equity currency are different, this
must be set to European.
– Settlement: The allowable values are Cash or Physical. If Currency and
underlying equity currency are different, i.e. Quanto payoff, this must be set
to Cash.
– PayOffAtExpiry [Optional]: The allowable values are true for payoff at
expiry, or false for payoff at exercise. This field is relevant for American
style EquityOptions, and defaults to true if left blank or omitted.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer
to the option seller.
Allowable values: See section 8.3.2
• Name: The identifier of the underlying equity or equity index.
Allowable values: See Name for equity trades in Table 41.
• Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• Currency: The payment currency of the equity option.
Allowable values: See Currency and Minor Currencies in Table 30. If this is
different to the currency that the underlying equity is quoted in, then a Quanto
payoff will be applied. Using the corresponding major currency for an equity
quoted in the minor currency will not correspond to a Quanto payoff.
• Strike[Mandatory except if StrikeData node is used]: The option strike price.
Allowable values: Any positive real number.
• StrikeCurrency [Mandatory for Quanto/Compo, Optional otherwise]: The
currency that the Strike is quoted in. If the option is Quanto, then this field
must not be left blank, and must equal the currency that the underlying equity is
quoted in, up to the minor/major currency. For example, if the underlying equity
is quoted in GBP, thenStrikeCurrency must be either GBP or GBp. If the

387
 option is a Compo option, then this field must not be left blank, and it must
equal the payment currency of the option and different to the underlying
currency.
Note:
Quanto: Payment currency and the currency the underlying equity is quoted in
differ. StrikeCurrency is in the currency the equity is quoted in.
Compo (Composite): Payment currency and the currency the underlying equity
is quoted in differ. StrikeCurrency is in the payment currency.
Allowable values: See Fiat Currencies and Minor Currencies in Table 32. Must
be the major or minor currency of the Currency field above, or in the Quanto
case it must be the major or minor currency the underlying is quoted in. If left
blank or omitted, and payment currency is the same as the equity currency, it
defaults to the Currency field (payment currency) above.
• StrikeData[Optional]: Alternatively, instead of the Strike and the
StrikeCurrency fields above a StrikeData node can be used as described in
Section 8.3.30. Note that for EquityOptions only StrikePrice is supported
within the StrikeData node, and not StrikeYield.
• Quantity: The number of units of the underlying covered by the transaction.
Allowable values: Any positive real number.

8.2.22 Equity Futures Option

The EquityFutureOptionData node is the trade data container for the
EquityFutureOption trade type. Equity options with exercise styles European and
American are supported. The EquityFutureOptionData node includes one and only
one OptionData trade component sub-node plus elements specific to the equity future
option. The structure of an example EquityFutureOptionData node for an equity
option is shown in Listing 312.

388
Listing 312: Equity Future Option data

<EquityFutureOptionData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>American</Style>
<Settlement>Cash</Settlement>
<PayOffAtExpiry>true</PayOffAtExpiry>
<ExerciseDates>
<ExerciseDate>2022-03-01</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<Name>RIC:.SPX</Name>
<Currency>USD</Currency>
<StrikeData>
<StrikePrice>
<Value>2147.56</Value>
<Currency>USD</Currency>
</StrikePrice>
</StrikeData>
<Quantity>17000</Quantity>
<FutureExpiryDate>2021-01-29</FutureExpiryDate>
</EquityFutureOptionData>

The meanings and allowable values of the elements in the EquityFutureOptionData

node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1 Option
Data. The relevant fields in the OptionData node for an EquityOption are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put. Call means that the
option holder has the right to buy the given quantity of the underlying
equity at the strike price. Put means that the option holder has the right to
sell the given quantity of the underlying equity at the strike price.
– Style The allowable value is European.
– Settlement The allowable values are Cash or Physical.
– PayOffAtExpiry [Optional] The allowable values are true for payoff at
expiry, or false for payoff at exercise. This field is relevant for American
style EquityOptions, and defaults to true if left blank or omitted.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer
to the option seller.
Allowable values: See section 8.3.2
• Name: The identifier of the underlying equity or equity index.
Allowable values: See Name for equity trades in Table 40.

389
 • Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• Currency: The currency of the equity option.
Allowable values: See Table 32.
• StrikeData: The option strike price.
Allowable values: Only supports StrikePrice as described in Section 8.3.30.
• Quantity: The number of units of the underlying covered by the transaction.
Allowable values: Any positive real number.
• FutureExpiryDate [Optional]: If IsFuturePrice is true and the underlying is a
future contract settlement price, this node allows the user to specify the expiry
date of the underlying future contract.
Allowable values: This should be a valid date as outlined in Table 30. If not
provided, it is assumed that the future contract’s expiry date is equal to the
option expiry date provided in the OptionData node.

8.2.23 Equity Forward

The EquityForwardData node is the trade data container for the EquityForward trade
type. Vanilla equity forwards are supported. The structure of an example
EquityForwardData node for an equity forward is shown in Listing 313.

Listing 313: Equity Forward data

<EquityForwardData>
<LongShort>Long</LongShort>
<Maturity>2018-06-30</Maturity>
<Name>RIC:.SPX</Name>
<Currency>USD</Currency>
<Strike>2147.56</Strike>
<StrikeCurrency>USD</StrikeCurrency>
<Quantity>17000</Quantity>
</EquityForwardData>

The meanings and allowable values of the elements in the EquityForwardData node
follow below.
• LongShort: Defines whether the underlying equity will be bought (long) or sold
(short).
Allowable values: Long, Short.
• Maturity: The maturity date of the forward contract, i.e. the date when the
underlying equity will be bought/sold.
Allowable values: Any date string, see Date in Table 30.
• Name: The identifier of the underlying equity or equity index.
Allowable values: See Name for equity trades in Table 40.

390
 • Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• Currency: The currency of the equity forward.
Allowable values: See Fiat Currencies and Minor Currencies in Table 32.
• Strike: The agreed buy/sell price of the equity forward.
Allowable values: Any positive real number.
• StrikeCurrency: [Optional] The currency of the strike value. Defaults to
Currency field
Allowable values: See Fiat Currencies and Minor Currencies in Table 32.
• Quantity: The number of units of the underlying equity to be bought/sold.
Allowable values: Any positive real number.

8.2.24 Equity Swap

An Equity Swap uses its own trade type EquitySwap, and is set up using a
EquitySwapData node with one leg of type Equity and one more leg - called Funding
leg - that can be either Fixed or Floating. Listing 314 shows an example. The Equity
leg contains an additional EquityLegData block. See 8.3.16 for details on the Equity
leg specification.
Cross currency EquitySwaps are supported, i.e. the Equity and the Funding legs do
not need to have the same currency. However, if the Funding leg uses Indexings with
FromAssetLeg set to true to derive the notionals from the Equity leg, then the
Funding leg must use the same currency as the Equity leg.
Note that pricing for an EquitySwap is based on discounted cashflows, whereas pricing
for a TotalReturnSwap (GenericTRS) on an equity underlying uses the accrual
method. The accrual method is common practice when daily unwind rights are present
in the trade terms.
Also note that, unlike other leg types, the DayCounter field is optional for an Equity
leg, and defaults to ACT/365 if left blank or omitted. The daycount convention for
the equity leg of an equity swap does not impact pricing, only the accrued amount
(displayed in cashflows).

391
Listing 314: Equity Swap Data

<EquitySwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
<DayCounter>ACT/365</DayCounter>
...
</LegData>
<LegData>
<LegType>Equity</LegType>
<Payer>false</Payer>
<DayCounter>ACT/365</DayCounter>
...
<EquityLegData>
...
</EquityLegData>
</LegData>
</EquitySwapData>

If the equity swap has a resetting notional, typically the Funding leg’s notional will be
aligned with the equity leg’s notional. To achieve this, Indexings on the floating leg
can be used, see 8.3.8. In the context of equity swaps the indexings can be defined in a
simplified way by adding an Indexings node with a subnode FromAssetLeg set to true
to the Funding leg’s LegData node. The Notionals node is not required in the
Funding leg’s LegData in this case. An example is shown in listing 315.

392
Listing 315: Equity Swap Data with notional reset and FX indexing

<EquitySwapData>
<LegData>
<LegType>Floating</LegType>
<Currency>USD</Currency>
...
<!-- Notionals node is not required, set to 1 internally -->
...
<Indexings>
<!-- derive the indexing information (equity price, FX) from the Equity leg -->
<FromAssetLeg>true</FromAssetLeg>
</Indexings>
</LegData>
<LegData>
<LegType>Equity</LegType>
<Currency>USD</Currency>
...
<EquityLegData>
<Quantity>1000</Quantity>
<Underlying>
<Type>Equity</Type>
<Name>.STOXX50E</Name>
<IdentifierType>RIC</IdentifierType>
</Underlying>
<InitialPrice>2937.36</InitialPrice>
<NotionalReset>true</NotionalReset>
<FXTerms>
<EquityCurrency>EUR</EquityCurrency>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
</FXTerms>
</EquityLegData>
...
</LegData>
</EquitySwapData>

8.2.25 Dividend Swap

An Dividend Swap uses its the trade type EquitySwap, shown above 8.2.24, and is set
up using a EquitySwapData node with one leg of type Equity, with ReturnType equal
to Dividend and one more leg that can be either Fixed or Floating. Listing 316 shows
an example.
An example is shown in listing 315.

393
Listing 316: Dividend Swap Data

<EquitySwapData>
<LegData>
...
</LegData>
<LegData>
<Payer>false</Payer>
<LegType>Equity</LegType>
<Currency>EUR</Currency>
<PaymentConvention>Following</PaymentConvention>
<DayCounter>A360</DayCounter>
<EquityLegData>
<ReturnType>Dividend</ReturnType>
<Underlying>
<Type>Equity</Type>
<Name>.STOXX50E</Name>
<IdentifierType>RIC</IdentifierType>
</Underlying>
<Quantity>10000</Quantity>
</EquityLegData>
<ScheduleData>
<Rules>
<StartDate>2018-12-31</StartDate>
<EndDate>2020-12-31</EndDate>
<Tenor>6M</Tenor>
<Calendar>EUR</Calendar>
<Convention>ModifiedFollowing</Convention>
<TermConvention>ModifiedFollowing</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</LegData>
</EquitySwapData>

8.2.26 Equity Asian Option

The EquityAsianOptionData node is the trade data container for the
EquityAsianOption trade type. The EquityAsianOptionData node includes one
OptionData trade component sub-node plus elements specific to the Equity Asian
Option.
An Equity Asian Option is a path-dependent option whose payoff depends upon the
averaged price of an Equity underlying over a pre-set period of time.
The structure of an example EquityAsianOptionData node for an Equity Asian
Option is shown in Listing 317.

394
Listing 317: Equity Asian Option data

<Trade id="EquityAsianOption">
<TradeType>EquityAsianOption</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields />
</Envelope>
<EquityAsianOptionData>
<Quantity>100</Quantity>
<Currency>USD</Currency>
<StrikeData>
<Value>3100</Value>
<Currency>USD</Currency>
</StrikeData>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
<Currency>USD</Currency>
</Underlying>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<PayoffType>Asian</PayoffType>
<PayoffType2>Arithmetic</PayoffType2>
<ExerciseDates>
<ExerciseDate>2020-07-15</ExerciseDate>
</ExerciseDates>
<Premiums> ... </Premiums>
</OptionData>
<Settlement>2020-07-20</Settlement>
<ObservationDates>
<Rules>
<StartDate>2019-12-27</StartDate>
<EndDate>2020-07-06</EndDate>
<Tenor>1D</Tenor>
<Calendar>US</Calendar>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ObservationDates>
</EquityAsianOptionData>
</Trade>

In the above example, the holder of the EquityAsianOption has a call option that gives
the right but not obligation to pay 310,000 USD (Strike*Quantity) and receive [the
averaged equity spot price during the Asian period] USD multiplied by the Quantity.
If OptionType would be changed to Put, the holder of the option would have the right
to receive 310,000 USD (Strike*Quantity) and pay [the averaged equity spot price
during the Asian period] USD multiplied by the Quantity.
The payoff is:
P ayof f = Quantity · M AX(ω · (A(0, T ) − K), 0)

395
where:
• A(0, T ): the arithmetic average of underlying euqity spot price over the Asian
observation period from start 0 to end T, quoted in Currency
• K: equity strike price, quoted in Currency
• ω: 1 for a call option (ie receiving averaged equity spot price and paying strike),
-1 for a put option
The meanings and allowable values of the elements in the EquityAsianOptionData
node follow below.
• StrikeData: A node containing the strike in Value and the currency in which
both the underlying and the strike are quoted in Currency. Allowable values:
See Currency in Table 30. The strike may be any positive real number. The
currency provided in this node may be quoted as corresponding minor currency
to the underlying major currency.
• Quantity: The quantity of the underlying equities. See payoff formula above.
Allowable values: all positive real numbers
• Underlying: One (and only one) Underlying node where Type must be set to
Equity.
Allowable values: See 8.3.29. Note that the equity must be quoted in the
Currency above.
• OptionData: The relevant fields in the OptionData node for an
EquityAsianOption are the LongShort flag, the OptionType (call/put), the
PayoffType which must be set to Asian or AverageStrike to identify a fixed or
floating strike asian payoff, and the ExerciseDates node where exactly one
ExerciseDate date element must be given. PayoffType2 can be optionally set to
Arithmetic or Geometric and defaults to Arithmetic if not given. Furthermore, a
Premiums node can be added to represent deterministic option premia to be paid
by the option holder.
Allowable values: See 8.3.1 for the general structure of the option data node
• Settlement[Optional]: The settlement date.
Allowable values: See Date in Table 30. Defaults to the ExerciseDate if left blank
or omitted.
• ObservationDates: The observation dates for the asian period, given as a
rules-based or dates-based schedule, analogous to a ScheduleData node but
called ObservationDates.
Allowable values: See the definition in 8.3.4

8.2.27 Equity Barrier Option

European exercise, American barrier.
The EquityBarrierOptionData node is the trade data container for the
EquityBarrierOption trade type. The barrier level of an Equity Barrier Option should
be quoted in the currency of the underlying Equity spot price. The
EquityBarrierOptionData node includes one OptionData trade component sub-node

396
and one BarrierData trade component sub-node plus elements specific to the Equity
Barrier Option.
An Equity Barrier Option is a path-dependent option whose existence depends upon
an Equity underlying spot price reaching a pre-set barrier level. Exercise is European.
This product has a continuously monitored single barrier (American Barrier style) with
a Vanilla European Equity Option Underlying.
The structure of an example EquityBarrierOptionData node for an Equity Barrier
Option is shown in Listing 318.

Listing 318: Equity Barrier Option data

<EquityBarrierOptionData>
<OptionData>
...
</OptionData>
<BarrierData>
...
</BarrierData>
<StartDate>2019-01-25</StartDate>
<Calendar>TARGET</Calendar>
<EQIndex>EQ-RIC:.SPX</EQIndex>
<Name>RIC:.SPX</Name>
<StrikeData>
<StrikePrice>
<Value>3200.00</Value>
<Currency>USD</Currency>
</StrikePrice>
</StrikeData>
<Quantity>1000</Quantity>
</EquityBarrierOptionData>

The meanings and allowable values of the elements in the EquityBarrierOptionData

node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. Note
that the Equity Barrier Option type allows for European option style only.
• BarrierData: This is a trade component sub-node outlined in section 8.3.31.
Level specified in BarrierData should be quoted in the same currency with the
underlying Equity spot price. Changing the option from Call to Put or vice versa
does not require switching the barrier level.
• StartDate[Optional]: The start date for checking if a barrier has been breached
prior to today’s date. If omitted or left blank no check is made and it is assumed
no barrier has been breached in the past. Has no impact if set to today’s date or
a date in the future.
Allowable values: See Date in Table 30.
• Calendar[Optional]: The calendar associated with the Equity Index. Required if
StartDate is set to a date prior to today’s date, otherwise optional.
Allowable values: See Table 34 Calendar.

397
 • EQIndex[Optional]: A reference to an Equity Index source to check if the barrier
has been breached. Required if StartDate is set to a date prior to today’s date,
otherwise optional and can be omitted but not left blank.
Allowable values: The format of the Equity Index is“EQ-RIC:Code”.
• Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• StrikeData: A node containing the strike in Value and the currency in which
both the underlying and the strike are quoted in Currency. Allowable values:
Only supports StrikePrice as described in Section 8.3.30.
• Quantity: The number of units of the underlying covered by the transaction.
Allowable values: Any positive real number.

8.2.28 Equity Digital Option

The EquityDigitalOptionData node is the trade data container for the
EquityDigitalOption trade type. The EquityDigitalOptionData node includes one
OptionData trade component sub-node plus elements specific to the Equity Digital
Option. The structure of an example EquityDigitalOptionData node for an Equity
Digital Option is shown in Listing 319.

Listing 319: Equity Digital Option data

<EquityDigitalOptionData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>European</Style>
<ExerciseDates>
<ExerciseDate>2027-02-26</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<Strike>3300</Strike>
<PayoffCurrency>USD</PayoffCurrency>
<PayoffAmount>1000</PayoffAmount>
<Name>RIC:.SPX</Name>
<Quantity>1000</Quantity>
</EquityDigitalOptionData>

The meanings and allowable values of the elements in the EquityDigitalOptionData

node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an EquityDigitalOption are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put. Call means that the
option is in the money when the underlying equity price is above the strike,

398
 and Put means that the option is in the money when the underlying equity
price is below the strike.
– Style The allowable value is European. Note that the Equity Digital
Option type allows for European option style only.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer
to the option seller.
Allowable values: See section 8.3.2
• Strike: The option strike price per one unit of the underlying, expressed in the
currency of the underlying equity .
Allowable values: Any positive real number.
• PayoffCurrency: The payoff currency of the Equity Digital Option is the
currency of the payoff amount. Must be consistent with the currency of the
underlying Equity spot price.
Allowable values: See Table 32 Currency.
• PayoffAmount: The fixed payoff amount per unit of underlying expressed in
payoff currency. It is cash-or-nothing payoff that depends on the option being in
or out of the money.
Allowable values: Any positive real number.
• Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• Quantity: The number of units of the underlying covered by the transaction.
Allowable values: Any positive real number.

8.2.29 Equity Double Barrier Option

The EquityDoubleBarrierOptionData node is the trade data container for the
EquityDoubleBarrierOption trade type.
An Equity Double Barrier Option is a path-dependent option whose existence depends
upon an Equity spot rate reaching one of the two pre-set barrier levels. Exercise is
European, and barriers are American (continuously monitored).
Equity Double Barrier options can be knock-in or knock-out:
• A knock-in option is a barrier option that only comes into existence/becomes
active when the Equity spot rate reaches the one of the barrier level at any point
in the option’s life. Once a barrier is knocked-in, the option will not cease to
exist until the option expires and effectively it becomes a Vanilla Equity Option.
• A knock-out option starts its life active, but ceases to exist/becomes inactive, if
the one of the barriers is reached during the life of the option.

399
The barrier levels of an Equity Double Barrier Option should be quoted in the
currency of the underlying Equity spot price. The EquityDoubleBarrierOptionData
node includes one OptionData trade component sub-node and one BarrierData trade
component sub-node plus elements specific to the Equity Double Barrier Option. The
structure of an example EquityDoubleBarrierOptionData node for a Equity Double
Barrier Option is shown in Listing 320.

Listing 320: Equity Double Barrier Option data

<EquityDoubleBarrierOptionData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>European</Style>
<Settlement>Cash</Settlement>
<ExerciseDates>
<ExerciseDate>2021-01-29</ExerciseDate>
</ExerciseDates>
</OptionData>
<BarrierData>
<Type>KnockOut</Type>
<Levels>
<Level>3000.00</Level>
<Level>3500.00</Level>
</Levels>
</BarrierData>
<Name>RIC:.SPX</Name>
<Currency>USD</Currency>
<StrikeData>
<StrikePrice>
<Value>3200.00</Value>
<Currency>USD</Currency>
</StrikePrice>
</StrikeData>
<Quantity>1000</Quantity>
<StartDate>2019-12-27</StartDate>
<Calendar>US-NYSE</Calendar>
<EQIndex>EQ-RIC:.SPX</EQIndex>
</EquityDoubleBarrierOptionData>

The meanings and allowable values of the elements in the

EquityDoubleBarrierOptionData node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an EquityDoubleBarrierOption are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put.
– Style The Equity Double Barrier Option type allows for European option
exercise style only.
– Settlement The allowable values are Cash or Physical.

400
 – An ExerciseDates node where exactly one ExerciseDate date element
must be given.
– Optional PremiumAmount, PremiumCurrency, and PremiumPayDate fields to
specify the Equity Double Barrier Option premium.
• BarrierData: This is a trade component sub-node outlined in section 8.3.31. Two
levels in ascending order should be defined in Levels. Type should be KnockOut
or KnockIn.
Allowable values: See Table 34 Calendar.
• Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• Currency: The currency of the equity option.
Allowable values: See Table 32 Currency.
• StrikeData: A node containing the strike in Value and the currency in which
both the underlying and the strike are quoted in Currency. Allowable values:
Only supports StrikePrice as described in Section 8.3.30.
• Quantity: The number of units of the underlying covered by the transaction.
Allowable values: Any positive real number.
• StartDate [Optional]: The start date for checking if a barrier has been breached
prior to today’s date. If omitted or left blank no check is made and it is assumed
no barrier has been breached in the past. Has no impact if set to today’s date or
a date in the future.
Allowable values: See Date in Table 30.
• Calendar [Optional]: The calendar associated with the Equity Index. Required if
StartDate is set to a date prior to today’s date, otherwise optional.
• EQIndex [Optional]: A reference to an Equity Index source to check if the barrier
has been breached. Required if StartDate is set to a date prior to today’s date,
otherwise optional and can be omitted but not left blank.
Allowable values: The format of the Equity Index is“EQ-RIC:Code”.

8.2.30 Equity Double Touch Option

The EquityDoubleTouchOptionData node is the trade data container for the
EquityDoubleTouchOption trade type. The EquityDoubleTouchOptionData node
includes one OptionData trade component sub-node and one BarrierData trade
component sub-node plus elements specific to the Equity Double Touch Option.
An Equity Double Touch Option pays a given cash amount (PayoffAmount) at expiry
or at hit if the underlying equity price or index has hit either of the barriers (KnockIn)
resp. has not hit any of barriers (KnockOut) using continuous monitoring between
start and expiry date. No rebates are supported.

401
The structure of an example EquityDoubleTouchOptionData node for an Equity
Double Touch Option is shown in Listing 321.

Listing 321: Equity Double Touch Option data

<EquityDoubleTouchOptionData>
<OptionData>
<LongShort>Long</LongShort>
<PayOffAtExpiry>true</PayOffAtExpiry>
<ExerciseDates>
<ExerciseDate>2021-12-14</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<BarrierData>
...
<Type>KnockIn</Type> <!-- KnockOut or KnockIn -->
<Levels>
<Level>3000</Level>
<Level>4500</Level>
</Levels>
...
</BarrierData>
<PayoffCurrency>USD</PayoffCurrency>
<PayoffAmount>1000000</PayoffAmount>
<Name>RIC:.SPX</Name>
<StartDate>2021-03-01</StartDate>
<Calendar>USD</Calendar>
<EQIndex>EQ-RIC:.SPX</EQIndex>
</EquityDoubleTouchOptionData>

The meanings and allowable values of the elements in the

EquityDoubleTouchOptionData node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an EquityDoubleTouchOption are as
below. Note that the OptionType can be omitted.
– LongShort The allowable values are Long or Short.
– PayOffAtExpiry [Optional] true for payoff at expiry and false for payoff at
hit. Currently, for both KnockOut and KnockIn barriers, only payoff at
expiry (i.e. true) is supported. Defaults to true if left blank or omitted.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer
to the option seller.
Allowable values: See section 8.3.2
• BarrierData: This is a trade component sub-node outlined in section 8.3.31. Two
levels in ascending order should be defined in Levels. Type should be KnockOut
or KnockIn. Levels specified in BarrierData should be quoted in the same
currency as the underlying Equity spot prices.

402
 • PayoffCurrency: The payoff currency of the Equity Double Touch Option is the
currency of the payoff amount. Must be consistent with the currency of the
underlying Equity spot prices.
Allowable values: See Table 32 Currency.
• PayoffAmount: The fixed payoff amount expressed in payoff currency. It is
cash-or-nothing payoff that depends on the option being in or out of the money,
and whether the barrier has been touched.
Allowable values: Any positive real number.
• Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• StartDate[Optional]: The start date for checking if a barrier has been breached
prior to today’s date. If omitted or left blank no check is made and it is assumed
no barrier has been breached in the past. Has no impact if set to today’s date or
a date in the future.
Allowable values: See Date in Table 30.
• Calendar[Optional]: The calendar associated with the Equity Index. Required if
StartDate is set to a date prior to today’s date, otherwise optional.
Allowable values: See Table 34 Calendar.
• EQIndex[Optional]: A reference to an Equity Index source to check if the barrier
has been breached. Required if StartDate is set to a date prior to today’s date,
otherwise optional and can be omitted but not left blank.
Allowable values: The format of the Equity Index is“EQ-RICCode”.

8.2.31 Equity European Barrier Option

European exercise, European barrier.
The EquityEuropeanBarrierOptionData node is the trade data container for the
EquityEuropeanBarrierOption trade type. The barrier level of an Equity European
Barrier Option is quoted in the currency of the underlying Equity spot price. The
EquityEuropeanBarrierOptionData node includes one OptionData trade component
sub-node and one BarrierData trade component sub-node plus elements specific to
the Equity European Barrier Option.
An Equity European Barrier Option gives the buyer the right, but not the obligation,
to buy a set number of shares of a single name equity or an equity index, at a
predetermined strike price, at one predetermined time in the future. This right may be
withdrawn depending upon an Eqity spot price or index reaching a predetermined
barrier level at the predetermined time, the underlying is monitored only at expiry
with a single barrier (European Barrier style).
The structure of an example EquityEuropeanBarrierOptionData node for an Equity
European Barrier Option is shown in Listing 322.

403
Listing 322: Equity European Barrier Option data

<EquityEuropeanBarrierOptionData>
<OptionData>
...
</OptionData>
<BarrierData>
...
</BarrierData>
<Name>RIC:.SPX</Name>
<StrikeData>
<StrikePrice>
<Value>3200.00</Value>
<Currency>USD</Currency>
</StrikePrice>
</StrikeData>
<Quantity>1000</Quantity>>
</EquityEuropeanBarrierOptionData>

The meanings and allowable values of the elements in the

EquityEuropeanBarrierOptionData node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. Note
that the Equity European Barrier Option type allows for European option style
only.
• BarrierData: This is a trade component sub-node outlined in section 8.3.31.
Level specified in BarrierData should be quoted in the same currency with the
underlying Equity spot price. Changing the option from Call to Put or vice versa
does not require switching the barrier level.
• Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• StrikeData: A node containing the strike in Value and the currency in which
both the underlying and the strike are quoted in Currency. Allowable values:
Only supports StrikePrice as described in Section 8.3.30.
• Quantity: The number of units of the underlying covered by the transaction.
Allowable values: Any positive real number.

8.2.32 Equity Touch Option

The EquityTouchOptionData node is the trade data container for the
EquityTouchOption trade type. The EquityTouchOptionData node includes one
OptionData trade component sub-node and one BarrierData trade component
sub-node plus elements specific to the Equity Touch Option.
An Equity Touch Option pays a given cash amount (PayoffAmount) at expiry or at hit
if the underlying equity price or index has hit a barrier (UpAndIn, DownAndIn) resp.
has not hit a barrier (UpAndOut, DownAndOut) using continuous monitoring between
start and expiry date. No rebates are supported.

404
The structure of an example EquityTouchOptionData node for an Equity Touch
Option is shown in Listing 323.

Listing 323: Equity Touch Option data

<EquityTouchOptionData>
<OptionData>
<LongShort>Long</LongShort>
<PayOffAtExpiry>true</PayOffAtExpiry>
<Settlement>Cash</Settlement>
<ExerciseDates>
<ExerciseDate>2022-03-01</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<BarrierData>
<Type>UpAndIn</Type>
<Levels>
<Level>3300</Level>
</Levels>
</BarrierData>
<PayoffCurrency>USD</PayoffCurrency>
<PayoffAmount>1000000</PayoffAmount>
<Name>RIC:.SPX</Name>
<StartDate>2019-12-27</StartDate>
<Calendar>US-NYSE</Calendar>
<EQIndex>EQ-RIC:.SPX</EQIndex>>
</EquityTouchOptionData>

The meanings and allowable values of the elements in the EquityTouchOptionData

node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
OptionType sub-node is not required and is inferred from the BarrierData type
(i.e. Call for an Up barrier, and Put for a Down barrier). The relevant fields in
the OptionData node for an EquityTouchOption are:
– LongShort The allowable values are Long or Short.
– PayOffAtExpiry [Optional] true for payoff at expiry and false for payoff at
hit. For UpAndOut and DownAndOut barriers, only payoff at expiry (i.e.
true) is supported. Defaults to true if left blank or omitted.
– Settlement The allowable values are Cash or Physical.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer
to the option seller.
Allowable values: See section 8.3.2
• BarrierData: This is a trade component sub-node outlined in section 8.3.31.
Level specified in BarrierData should be quoted in the same currency as the
underlying Equity spot price.

405
 • PayoffCurrency: The payoff currency of the Equity Touch Option is the currency
of the payoff amount. Must be consistent with the currency of the underlying
Equity spot price.
Allowable values: See Currency in Table 30.
• PayoffAmount: The fixed payoff amount expressed in payoff currency. It is
cash-or-nothing payoff that depends on the option being in or out of the money,
and whether the barrier has been touched.
Allowable values: Any positive real number.
• Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• StartDate[Optional]: The start date for checking if a barrier has been breached
prior to today’s date. If omitted or left blank no check is made and it is assumed
no barrier has been breached in the past. Has no impact if set to today’s date or
a date in the future.
Allowable values: See Date in Table 30.
• Calendar[Optional]: The calendar associated with the Equity Index. Required if
StartDate is set to a date prior to today’s date, otherwise optional.
Allowable values: See Table 34 Calendar.
• EQIndex[Optional]: A reference to an Equity Index source to check if the barrier
has been breached. Required if StartDate is set to a date prior to today’s date,
otherwise optional and can be omitted but not left blank.
Allowable values: The format of the Equity Index is“EQ-RICCode”.

8.2.33 Equity Variance Swap

The EqutiyVarianceSwapData node is the trade data container for the
EquityVarianceSwap trade type. Only vanilla variance swaps are supported. The
structure of an example EqutiyVarianceSwapData node for an equity variance swap is
shown in Listing 324.

406
Listing 324: Variance Swap data

<EquityVarianceSwapData>
<StartDate>2016-01-29</StartDate>
<EndDate>2016-05-05</EndDate>
<Currency>USD</Currency>
<Underlying>
<Type>Equity</Type>
<Name>.SPX</Name>
<IdentifierType>RIC</IdentifierType>
</Underlying>
<LongShort>Long</LongShort>
<Strike>0.20</Strike>
<Notional>50000</Notional>
<Calendar>US</Calendar>
<MomentType>Variance</MomentType>
<AddPastDividends>true</AddPastDividends>
</EqutiyVarianceSwapData>

The meanings and allowable values of the elements in the EquityVarianceSwapData

node below.
• StartDate: The variance swap start date.
Allowable values: See Date in Table 30.
• EndDate: The variance swap end date.
Allowable values: See Date in Table 30.
• Currency: The bought currency of the variance swap.
Allowable values: See Currency in Table 30.
• Name: The identifier of the underlying equity or equity index.
Allowable values: See Name for equity trades in Table 40.
• Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• LongShort: Defines whether the trade is long in the equity variance. For the
avoidance of doubt, a long variance swap has positive value if the realised
variance exceeds the variance strike.
Allowable values: Long, Short
• Strike: The volatility strike Kvol of the variance swap quoted absolutely (i.e. not
as a percent). If the swap was struck in terms of variance, the square root of that
variance should be used here.
Allowable values: Any positive real number.
• Notional: The vega notional of the variance swap. This is the notional in terms
of volatility units (like the strike). If the swap was struck in terms of a variance
notional Nvar , the corresponding vega notional is given by
Nvol = Nvar ∗ 2 ∗ 100 ∗ Kvol (where Kvol is in absolute terms).
Allowable values: Any non-negative real number.

407
 • Calendar: The calendar determining the observation/fixing dates according to
which variance is accrued is the combination of the calendar(s) given here plus
the calendar associated with the equity in the equity curve configuration. If no
such calendar is given in the equity curve configuration the standard calendar for
the equity currency (also defined in the curve config) is used instead.
Allowable values: See Table 34.
• MomentType[Optional]: A flag to distinguish if the swap is struck in terms of
volatility or variance. The MomentType should be set to Volatility or Variance
depending on the payoff. Note that MomentType does not necessarily need to be
equivalent to the way the Strike is quoted which is always as a Volatility.
Allowable values: Volatility or Variance. Defaults to Variance if left blank or
omitted.
• AddPastDividends[Optional]: A flag to distinguish if past dividend payments
should be added to the fixings when calculating accrued variance.
Allowable values: true or false. Defaults to false if left blank or omitted.

8.2.34 Equity Cliquet Option

The EquityCliquetOptionData node is the trade data container for the
EquityCliquetOption trade type. A cliquet option consists of a series of consecutive
forward starting equity options, with each option being struck at a given moneyness
(commonly at-the-money) when it becomes active.
The payoff is:

n
!!
X


N · min capg , max f loorg , δ · min capl , max f loorl , Sti /Sti−1 − M
i=1

where
• Sti : Price of the underlying at time tt .
• capg : Global Cap.
• f loorg : Global Floor.
• capl : Local Cap.
• f loorl : Local Floor.
• δ: 1 for Call, -1 for Put option.
• M : Moneyness.
• n: Number of valuation dates.
• N : Notional
The structure of an example EquityCliquetOptionData node for an equity cliquet
option is shown in Listing 325.

408
Listing 325: Cliquet Option data

<EquityCliquetOptionData>
<Underlying>
<Type>Equity</Type>
<Name>.SPX</Name>
<IdentifierType>RIC</IdentifierType>
</Underlying>
<Currency>USD</Currency>
<Notional>1000000.0</Notional>
<LongShort>Short</LongShort>
<OptionType>Call</OptionType>
<Moneyness>1.0</Moneyness>
<LocalCap>0.07</LocalCap>
<LocalFloor>-0.06</LocalFloor>
<GlobalCap>0.07</GlobalCap>
<GlobalFloor>-0.07</GlobalFloor>
<ScheduleData>
<Dates>
<Dates>
<Date>20171231</Date>
<Date>20181231</Date>
<Date>20191231</Date>
<Date>20201231</Date>
<Date>20211231</Date>
<Date>20221231</Date>
</Dates>
<Calendar>USD</Calendar>
<Convention>F</Convention>
</Dates>
</ScheduleData>
<SettlementDays>5</SettlementDays>
<Premium>0.027</Premium>
<PremiumPaymentDate>31-12-2017</PremiumPaymentDate>
<PremiumCurrency>USD</PremiumCurrency>
</EquityCliquetOptionData>

The meanings and allowable values of the elements in the CliquetOptionData node
below.
• Name: The identifier of the underlying equity or equity index.
Allowable values: See Name for equity trades in Table 40.
• Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• Currency: The currency of the notional, and thus of the option.
Allowable values: See Currency in Table 30. The Currency must be the same as
the currency of the underlying equity.
• Notional: The notional of the cliquet option.
Allowable values: Any positive real number.
• LongShort: Defines whether the trade is long or short the option.
Allowable values: Long, Short

409
• OptionType: The type of the option.
Allowable values: Call, Put
• Moneyness: Adjustment of option return. The moneyness M each forward
starting option is being struck at.
Allowable values: Any real number. Expressed in decimal form where 1.0 is
at-the-money, 1.1 is 110% of the at-the-money strike, 0.9 is 90% of the
at-the-money strike, etc.
• LocalCap[Optional]: The local cap, capl , in each of the option return.
Allowable values: Any real number. If omitted, no local cap is applied. Can’t be
left blank.
• LocalFloor[Optional]: The local floor, f loorl , in each of the option return.
Allowable values: Any real number. If omitted, no local floor is applied. Can’t be
left blank.
• GlobalCap[Optional]: The global cap, capg , for the option return.
Allowable values: Any real number. If omitted, no global cap is applied. Can’t
be left blank.
• GlobalFloor[Optional]: The global floor,f loorg , for the option return.
Allowable values: Any real number. If omitted, no global floor is applied. Can’t
be left blank.
• ScheduleData: A schedule of dates that define the valuation dates of the
consecutive forward starting options forming the Equity Cliquet Option. The
first date in the schedule is the start date of the first consecutive option, the
second date in the schedule is the end/valuation date of the first consecutive
option, and also the start date of the second consecutive option, etc. The last
date is the final valuation date, with payoff of the whole Cliquet option at this
date plus SettlementDays.
Allowable values: A node on the same form as ScheduleData, (see 8.3.4).
• SettlementDays[Optional]: Number of days from the last valuation date to the
payoff being paid or received. The payoff date is determined with regards to
calendar and term date convention of the schedule’s calendar.
Allowable values: Any positive integer. Defaults to zero if left blank or omitted.
• Premium[Optional]: The premium paid for the option.
Allowable values: Any real number. Expressed in decimal form relative to
notional.
• PremiumPaymentDate[Optional]: The date the premium is the paid.
Allowable values: See Date in Table 30. Note that if a Premium is specified, a
PremiumPaymentDate must also be specified.
• PremiumCurrency[Optional]: The currency the premium is to paid in.
Allowable values: See Currency in Table 30. Defaults to the currency of the
notional.

410
8.2.35 Equity Position
An equity position represents a position in a single equity - using a single Underlying
node, or in a weighted basket of underlying equities - using multiple Underlying nodes.
An Equity Position can be used both as a stand alone trade type (TradeType:
EquityPosition) or as a trade component (EquityPositionData) used within the
TotalReturnSwap (Generic TRS) trade type, to set up for example Equity Basket
trades.
It is set up using an EquityPositionData block as shown in listing 326. The meanings
and allowable values of the elements in the block are as follows:
• Quantity: The number of shares or units of the weighted basket held.
Allowable values: Any positive real number
• Underlying: One or more underlying descriptions. If a basket of equities is
defined, the Weight field should be populated for each underlyings. The weighted
basket price is then given by
X
Basket-Price = Quantity × Weighti × Si × FXi
i

where
– Si is the price of the ith share in the basket
– F Xi is the FX Spot converting from the ith equity currency to the first
equity currency which is by definition the currency in which the npv of the
basket is expressed.
Allowable values: See 8.3.29 for the definition of an underlying. Only equity
underlyings are allowed.

411
Listing 326: Equity position data

<Trade id="EquityPosition">
<TradeType>EquityPosition</TradeType>
<Envelope>...</Envelope>
<EquityPositionData>
<Quantity>1000</Quantity>
<Underlying>
<Type>Equity</Type>
<Name>BE0003565737</Name>
<Weight>0.5</Weight>
<IdentifierType>ISIN</IdentifierType>
<Currency>EUR</Currency>
<Exchange>XFRA</Exchange>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>GB00BH4HKS39</Name>
<Weight>0.5</Weight>
<IdentifierType>ISIN</IdentifierType>
<Currency>GBP</Currency>
<Exchange>XLON</Exchange>
</Underlying>
</EquityPositionData>
</Trade>

8.2.36 Equity Option Position

An equity option position represents a position in a single equity option - using a
single Underlying node, or in a weighted basket of underlying equity options - using
multiple Underlying nodes.
An Equity Option Position can be used both as a stand alone trade type (TradeType:
EquityOptionPosition) or as a trade component (EquityOptionPositionData) used
within the TotalReturnSwap (Generic TRS) trade type, to set up for example Equity
Option Basket trades.
It is set up using an EquityOptionPositionData block as shown in listing 327. The
meanings and allowable values of the elements in the block are as follows:
• Quantity: The number of options written on one underlying share resp. the
number of units of the option basket held.
Allowable values: Any positive real number
• Underlying: One or more underlying descriptions, each comprising an
Underlying block, an Optiondata block and a Strike element, in that order:
– Underlying: an underlying description, see 8.3.29, only equity underlying
are allowed
– OptionData: the option description, see 8.3.1, the relevant / allowed data is
∗ LongShort: the type of the position,long and Short positions are
allowed. Note that negative weights are allowed. A long position with a
negative weight results in a short position, and a short position with a
negative weight results in a long position.

412
 ∗ OptionType: Call or Put
∗ Style: European or American
∗ Settlement: Cash or Physical
∗ ExerciseDates: exactly one exercise must be given representing the
European exercise date or the last American exercise date
– Strike: the strike of the option. Allowable values are non-negative real
numbers.
If a basket of equities is defined, the Weight field should be populated for each
underlying. The weighted basket price is then given by
X
Basket-Price = Quantity × Weighti × pi × FXi
i

where
• pi is the price of the ith option in the basket, written on one underlying share
• F Xi is the FX Spot converting from the ith equity currency to the first equity
currency which is by definition the currency in which the npv of the basket is
expressed.

413
Listing 327: Equity Option position data

<Trade id="EquityOptionPositionTrade">
<TradeType>EquityOptionPosition</TradeType>
<EquityOptionPositionData>
<!-- basket price = quantity x sum_i ( weight_i x equityOptionPrice_i x fx_i ) -->
<Quantity>1000</Quantity>
<!-- option #1 -->
<Underlying>
<Underlying>
<Type>Equity</Type>
<Name>.SPX</Name>
<Weight>0.5</Weight>
<IdentifierType>RIC</IdentifierType>
</Underlying>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>European</Style>
<Settlement>Cash</Settlement>
<ExerciseDates>
<ExerciseDate>2021-01-29</ExerciseDate>
</ExerciseDates>
</OptionData>
<Strike>3300</Strike>
</Underlying>
<!-- option #2 -->
<Underlying>
<Underlying>
<Type>Equity</Type>
<Name>.SPX</Name>
<Weight>0.5</Weight>
<IdentifierType>RIC</IdentifierType>
</Underlying>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>European</Style>
<Settlement>Cash</Settlement>
<ExerciseDates>
<ExerciseDate>2021-01-29</ExerciseDate>
</ExerciseDates>
</OptionData>
<Strike>3400</Strike>
</Underlying>
<!-- option #3 -->
<!-- ... -->
</EquityOptionPositionData>
</Trade>

8.2.37 CPI Swap

A CPI inflation swap can be set up using the InflationSwap trade type, with one leg of
type CPI. and the other leg(s) can be of any leg type. Listing 328 shows an example.
The CPI leg contains an additional CPILegData block. See 8.3.17 for details on the
CPI leg specification.

414
Note that Cross Currency Inflation Swaps are supported, as the currencies on the legs
of an InflationSwap do not need to be the same.

Listing 328: CPI Swap Data (using InflationSwap trade type)

<InflationSwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
...
</LegData>
<LegData>
<LegType>CPI</LegType>
<Payer>false</Payer>
...
<CPILegData>
...
</CPILegData>
</LegData>
</InflationSwapData>

Alternatively, a CPI swap can be set up as a swap with trade type Swap, with one leg
of type CPI, see listing 329.

Listing 329: CPI Swap Data (using Swap trade type)

<SwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
...
</LegData>
<LegData>
<LegType>CPI</LegType>
<Payer>false</Payer>
...
<CPILegData>
...
</CPILegData>
</LegData>
</SwapData>

8.2.38 Year on Year Inflation Swap

A Year on Year inflation swap can be set up with trade type Swap, with one leg of
type YY. Listing 330 shows an example. The YY leg contains an additional YYLegData
block. See 8.3.18 for details on the YY leg specification.

415
Listing 330: Year on Year Swap Data (using Swap trade type)

<SwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
...
</LegData>
<LegData>
<LegType>YY</LegType>
<Payer>false</Payer>
...
<YYLegData>
...
</YYLegData>
</LegData>
</SwapData>

Alternatively, a Year on Year inflation swap can be set up using the InflationSwap
trade type, see Listing 331. The structure of the InflationSwapData container is the
same as for SwapData above.

Listing 331: Year on Year Swap Data (using InflationSwap trade type)

<InflationSwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
...
</LegData>
<LegData>
<LegType>YY</LegType>
<Payer>false</Payer>
...
<YYLegData>
...
</YYLegData>
</LegData>
</InflationSwapData>

8.2.39 Bond
A Bond is set up using a BondData block, and can be both a stand-alone instrument
with trade type Bond, or a trade component used by multiple bond derivative
instruments.
A Bond can be set up in a short version referencing an underlying bond static, or in a
long version where the underlying bond details are specified explicitly, including a full
LegData block. The short version is shown in listing 332. The details of the bond are
read from the reference data in this case using the SecurityId as a key. The bond trade
is fully specified by
• SecurityId: The id identifying the bond.

416
 Allowable Values: A valid bond identifier, typically the ISIN of the reference
bond with the ISIN: prefix, e.g.: ISIN:XXNNNNNNNNNN
• BondNotional: The notional of the position in the reference bond, expressed in
the currency of the bond.
Allowable Values: Any non-negative real number
• CreditRisk [Optional] Boolean flag indicating whether to show Credit Risk on
the Bond product. If set to false, the product class will not be set to Credit, and
there will be no credit sensitivities. However, if the underlying bond reference is
set up without a CreditCurveId - typically for some highly rated government
bonds - the CreditRisk flag will have no impact on the product class and no
credit sensitivities will be shown even if CreditRisk is set to true.
Allowable Values: true or false Defaults to true if left blank or omitted.
in this case.

Listing 332: Bond Data

<BondData>
<SecurityId>ISIN:XS0982710740</SecurityId>
<BondNotional>100000000.0</BondNotional>
<CreditRisk>true</CreditRisk>
</BondData>

For the long version, the bond details are inlined in the trade as shown in listing 333.
The bond specific elements are
• IssuerId [Optional]: A text description of the issuer of the bond. This is for
informational purposes and not used for pricing.
Allowable values: Any string. If left blank or omitted, the bond will not have any
issuer description.
• CreditCurveId [Optional]: The unique identifier of the bond. This is used for
pricing, and is required for bonds for which a credit - related margin component
should be generated, and otherwise left blank. If left blank, the bond (and any
bond derivatives using the bond as a trade component) will be plain IR rather
than a IR/CR.
Allowable values: A valid bond identifier, typically the ISIN of the reference
bond with the ISIN: prefix, e.g.: ISIN:XXNNNNNNNNNN
• SecurityId: The unique identifier of the bond. This defines the security specific
spread to be used for pricing.
Allowable values: A valid bond identifier, typically the ISIN of the reference
bond with the ISIN: prefix, e.g.: ISIN:XXNNNNNNNNNN
• ReferenceCurveId: The benchmark curve to be used for pricing. This is typically
the main ibor index for the currency of the bond, and if no ibor index is available
for the currency in question, a currency-specific benchmark curve can be used.

417
 Allowable values: For currencies with available ibor indices:
An alphanumeric string of the form [CCY]-[INDEX]-[TERM]. CCY, INDEX and
TERM must be separated by dashes (-). CCY and INDEX must be among the
supported currency and index combinations. TERM must be an integer followed
by D, W, M or Y. See Table 36.
For currencies without available ibor indices:
An alphanumeric string, matching a benchmark curve set up in the market data
configuration in [Link] Yield curves section.
Examples: IDRBENCHMARK-IDR-3M, EGPBENCHMARK-EGP-3M,
UAHBENCHMARK-UAH-3M, NGNBENCHMARK-NGN-3M
• SettlementDays: The settlement lag in number of business days applicable to the
security.
Allowable values: A non-negative integer.
• Calendar: The calendar associated to the settlement lag.
Allowable values: See Table 34 Calendar.
• IssueDate: The issue date of the security.
See Date in Table 30.
• PriceQuoteMethod [Optional]: The quote method of the bond. Bond price
quotes and historical bond prices (stored as “fixings”) follow this method. Also,
the initial price for bond total return swaps follows this method. Defaults to
PerentageOfPar.
Allowable values: PercentageOfPar or CurrencyPerUnit
• PriceQuoteBaseValue [Optional]: The base value for quote method =
CurrencyPerUnit. Bond price quotes, historical bond prices stored as fixings and
initial prices in bond total return swaps are divided by this value. Defaults to 1.0.
Allowable values: Any real number.
A LegData block then defines the cashflow structure of the bond, this can be of type
fixed, floating etc. Note that a LegData block should only be included in the long
version.

418
Listing 333: Bond Data

<BondData>
<IssuerId>Ineos Group Holdings SA</IssuerId>
<CreditCurveId>ISIN:XS0982710740</CreditCurveId>
<SecurityId>ISIN:XS0982710740</SecurityId>
<ReferenceCurveId>EUR-EURIBOR-6M</ReferenceCurveId>
<SettlementDays>2</SettlementDays>
<Calendar>TARGET</Calendar>
<IssueDate>20160203</IssueDate>
<PriceQuoteMethod>PercentageOfPar</PriceQuoteMethod>
<PriceQuoteBaseValue>1.0</PriceQuoteBaseValue>
<LegData>
<LegType>Fixed</LegType>
<Payer>false</Payer>
...
</LegData>
</BondData>

The bond trade type supports perpetual schedules, i.e. perpetual bonds can be
represented by omitting the EndDate in the leg data schedule definition. Only rule
based schedules can be used to indicate perpetual schedules.

8.2.40 Bond Position

A bond position represents a position in a weighted basket of underlying bonds.
A bond position can be used both as a stand alone trade type (TradeType:
BondPosition) or as a trade component (BondBasketData) used within the
TotalReturnSwap (Generic TRS) trade type.
It is set up using an BondBasketData block as shown in listing 334. The meanings and
allowable values of the elements in the block are as follows:
• Quantity: The number of units of the weighted basket held.
Allowable values: Any positive real number
• Identifier: The identifier of the weighted basket. The Underlying data can be
retrieved from the reference data via this identifier, if not given in the trade itself.
• Underlying[Optional]: One or more underlying descriptions. If bond basket data
is set up in the reference data for the given identifier, the underlying data will be
populated from there and does not need to be provided in the trade.
Allowable values: See 8.3.29 for the definition of an underlying. Only bond
underlyings are allowed.

419
Listing 334: Bond position data

<Trade id="BondPosition">
<TradeType>BondPosition</TradeType>
<Envelope>...</Envelope>
<BondBasketData>
<Quantity>1000</Quantity>
<Identifier>ISIN:GB00B4KT9Q30</Identifier>
<Underlying>
<Type>Bond</Type>
<Name>US69007TAB08</Name>
<IdentifierType>ISIN</IdentifierType>
<Weight>0.5</Weight>
<BidAskAdjustment>-0.0025</BidAskAdjustment>
</Underlying>
<Underlying>
<Type>Bond</Type>
<Name>US750236AW16</Name>
<IdentifierType>ISIN</IdentifierType>
<Weight>0.5</Weight>
<BidAskAdjustment>-0.005</BidAskAdjustment>
</Underlying>
</BondBasketData>
</Trade>

8.2.41 Forward Bond

A Forward Bond (or Bond Forward) is a contract that establishes an agreement to buy
or sell (determined by LongInForward) an underlying bond at a future point in time
(the ForwardMaturityDate) at an agreed price (the settlement Amount).
A T-Lock is a Forward Bond with a US Treasury Bond as underlying, whereas a
J-Lock is a Forward Bond with a Japanese Government Bond as underlying. T-Locks
can be specified in terms of a lock-in yield rather then a settlement amount. The cash
settlement amount is given by (bond yield at maturity - lock rate) x DV01 in this case.
Listing 335 shows an example for a physically settled forward bond. Listing 336 shows
an example for a cash settled T-Lock transaction specified by a lock-in yield.
A Forward Bond is set up using a ForwardBondData block as shown below and the
trade type is ForwardBond. The specific elements are
• BondData: A BondData block specifying the underlying bond as described in
section 8.2.39. A long position must be taken in the bond, i.e. (Payer) flag must
be set to (true). The bond data block contains an additional field for forward
bonds
– IncomeCurveId: The benchmark curve to be used for compounding, this
must match a name of a curve in the yield curves or index curve block in
[Link]. It is optional to provide this curve. If left out the
market reference yield curve from [Link] is used for
compounding.
• SettlementData: The entity defining the terms of settlement:
– ForwardMaturityDate: The date of maturity of the forward contract.

420
 Allowable values: See Date in Table 30.
– Settlement [Optional]: Cash or Physical. Option, defaults to Physcial,
except in case the settlement is defined by LockRate, in which case it
defaults to Cash.
Allowable values: Cash, Physical
– Amount [Optional]: The settlement amount (also called strike) transferred
at forward maturity in return for the bond (physical delivery) or a cash
amount equal to the dirty price of the bond (cash settlement). This is
transferred from the party that is long to the party that is short
(determined by LongInForward) and cannot be a negative amount. It is
assumed to be in the same currency as the underlying bond. Exactly one of
the fields Amount, LockRate must be given.
Allowable values: Any non-negative real number.
– LockRate [Optional]: The payoff is given by (yield at forward maturity -
LockRate) x DV01 (LongInForward = true). Exactly one of the fields
Amount, LockRate must be given. In case the LockRate is given, the
Settlement must be set to Cash. If Settlement is not given, it defaults to
Cash in this case.
Allowable values: Any non-negative real number.
– LockRateDayCounter [Optional]: The day counter w.r.t. which the lock
rate is expressed. Optional, defaults to A360.
Allowable values: see table 35
– SettlementDirty [Optional]: A flag that determines whether the settlement
amount (Amount) reflects a clean (false) or dirty (true) price. In either case,
the dirty amount is actually paid on the forward maturity date, i.e. if
SettlementDirty = false, the (forward) accruals are computed internally and
added to the given amount to get the actual settlement amount. Optional,
defaults to true.
Allowable values: true, false
• PremiumData: The entity defining the terms of a potential premium payment.
This node is optional. If left out it is assumed that no premium is paid.
– Date: The date when a premium is paid.
Allowable values: See Date in Table 30.
– Amount: The amount transferred as a premium. This is transferred from
the party that is long to the party that is short (determined by
LongInForward) and cannot be a negative amount. It is assumed to be in
the same currency as the underlying bond.
Allowable values: Any non-negative real number.
• LongInForward: A flag that determines whether the forward contract is entered
in long (true) or short (false) position.
Allowable values: true, false

421
Listing 335: Forward Bond Data

<ForwardBondData>
<BondData>
...
<IncomeCurveId>BENCHMARKINCOME-EUR<IncomeCurveId>
</BondData>
<SettlementData>
<ForwardMaturityDate>20160808</ForwardMaturityDate>
<Settlement>Physcial</Settlement>
<ForwardSettlementDate>20160810</ForwardSettlementDate>
<Amount>1000000.00</Amount>
<SettlementDirty>true</SettlementDirty>
</SettlementData>
<PremiumData>
<Amount>1000.00</Amount>
<Date>20160808</Date>
</PremiumData>
<LongInForward>true</LongInForward>
</ForwardBondData>

Listing 336: Forward Bond Date (T-Lock)

<ForwardBondData>
<BondData>
...
</BondData>
<SettlementData>
<ForwardMaturityDate>20160808</ForwardMaturityDate>
<ForwardSettlementDate>20160810</ForwardSettlementDate>
<LockRate>0.02365</LockRate>
</SettlementData>
<LongInForward>true</LongInForward>
</ForwardBondData>

As for the ordinary bond the forward bond pricing requires a recovery rate that can be
specified in ORE per SecurityId.

Forward Bond - Pricing Engine configuration

The configuration for the pricing engine of the forward bond is identical to the
ordinary [Link] pricing engine called by forward bond products is the
DiscountingForwardBondEngine, see below for a configuration example.

<Product type="ForwardBond">
<Model>DiscountedCashflows</Model>
<ModelParameters></ModelParameters>
<Engine>DiscountingForwardBondEngine</Engine>
<EngineParameters>

422
 <Parameter name="TimestepPeriod">3M</Parameter>
</EngineParameters>
</Product>

8.2.42 Bond Forward / T-Lock / J-Lock (using ref. data)

A Forward Bond (or Bond Forward) is a contract that establishes an agreement to buy
or sell (determined by LongInForward) an underlying bond at a future point in time
(the ForwardMaturityDate) at an agreed price (the settlement Amount).
A T-Lock is a Forward Bond with a US Treasury Bond as underlying, whereas a
J-Lock is a Forward Bond with a Japanese Government Bond as underlying. T-Locks
can be specified in terms of a lock-in yield rather then a settlement amount. The cash
settlement amount is given by (bond yield at maturity - lock rate) x DV01 in this case.
Listing 337 shows an example for a physically settled forward bond. Listing 338 shows
an example for a cash settled T-Lock transaction specified by a lock-in yield.
A Forward Bond is set up using a ForwardBondData block as shown below and the
trade type is ForwardBond. The specific elements are
• The BondData block specifies the underlying bond, see below for more details.
– SecurityId: The underlying security identifier
Allowable values: Typically the ISIN of the underlying bond, with the ISIN:
prefix.
– BondNotional: The notional of the underlying bond on which the forward is
written expressed in the currency of the bond
Allowable values: Any positive real number.
– CreditRisk [Optional] Boolean flag indicating whether to show Credit Risk
on the Bond product. If set to false, the product class will be set to
RatesFX instead of Credit, and there will be no credit sensitivities. Note
that if the underlying bond reference is set up without a CreditCurveId -
typically for some highly rated government bonds - the CreditRisk flag will
have no impact on the product class and no credit sensitivities will be
shown even if CreditRisk is set to true.
Allowable Values: true or false Defaults to true if left blank or omitted.
• SettlementData: The entity defining the terms of settlement:
– ForwardMaturityDate: The date of maturity of the forward contract.
Allowable values: See Date in Table 30.
– ForwardSettlementDate [Optional]: Settlement date for forward bond or
cash settlement payment date.
Allowable values: See Date in Table 30.
– Settlement [Optional]: Cash or Physical. Option, defaults to Physcial,
except in case the settlement is defined by LockRate, in which case it
defaults to Cash.
Allowable values: Cash, Physical

423
 – Amount [Optional]: The settlement amount (also called strike) transferred
at forward maturity in return for the bond (physical delivery) or a cash
amount equal to the dirty price of the bond (cash settlement). This is
transferred from the party that is long to the party that is short
(determined by LongInForward) and cannot be a negative amount. It is
assumed to be in the same currency as the underlying bond. Exactly one of
the fields Amount, LockRate must be given.
Allowable values: Any non-negative real number.
– LockRate [Optional]: The payoff is given by (yield at forward maturity -
LockRate) x DV01 (LongInForward = true). Exactly one of the fields
Amount, LockRate must be given. In case the LockRate is given, the
Settlement must be set to Cash. If Settlement is not given, it defaults to
Cash in this case.
Allowable values: Any non-negative real number. The LockRate is
expressed in decimal form, eg 0.05 is a rate of 5%
– dv01 [Optional]: When the LockRate is given, it is possible to implement a
contractual DV01 instead of deriving it from the bond price.
Allowable values: Any positive real number. E.G If the dPdY is given then
dv01=10000*dPdY/N.
– LockRateDayCounter [Optional]: The day counter w.r.t. which the lock
rate is expressed. Optional, defaults to A360.
Allowable values: see table 35
– SettlementDirty [Optional]: A flag that determines whether the settlement
amount (Amount) reflects a clean (false) or dirty (true) price. In either case,
the dirty amount is actually paid on the forward maturity date, i.e. if
SettlementDirty = false, the (forward) accruals are computed internally and
added to the given amount to get the actual settlement amount. Optional,
defaults to true.
Allowable values: true, false
• PremiumData: The entity defining the terms of a potential premium payment.
This node is optional. If left out it is assumed that no premium is paid.
– Date: The date when a premium is paid.
Allowable values: See Date in Table 30.
– Amount: The amount transferred as a premium. This is transferred from
the party that is long to the party that is short (determined by
LongInForward) and cannot be a negative amount. It is assumed to be in
the same currency as the underlying bond.
Allowable values: Any non-negative real number.
• LongInForward: A flag that determines whether the forward contract is entered
in long (true) or short (false) position.
Allowable values: true, false

424
Listing 337: Forward Bond Data

<ForwardBondData>
<BondData>
<SecurityId>ISIN:XS1234567890</SecurityId>
<BondNotional>100000</BondNotional>
<BondData>
<SettlementData>
<ForwardMaturityDate>20160808</ForwardMaturityDate>
<Settlement>Physcial</Settlement>
<ForwardSettlementDate>20160810</ForwardSettlementDate>
<Amount>1000000.00</Amount>
<SettlementDirty>true</SettlementDirty>
</SettlementData>
<PremiumData>
<Amount>1000.00</Amount>
<Date>20160808</Date>
</PremiumData>
<LongInForward>true</LongInForward>
</ForwardBondData>

Listing 338: Forward Bond Date (T-Lock)

<ForwardBondData>
<BondData>
<SecurityId>ISIN:XS1234567890</SecurityId>
<BondNotional>100000</BondNotional>
</BondData>
<SettlementData>
<ForwardMaturityDate>20160808</ForwardMaturityDate>
<ForwardSettlementDate>20160810</ForwardSettlementDate>
<LockRate>0.02365</LockRate>
</SettlementData>
<LongInForward>true</LongInForward>
</ForwardBondData>

425
Listing 339: Forward Bond Date (T-Lock) with DV01

<ForwardBondData>
<BondData>
<SecurityId>ISIN:XS1234567890</SecurityId>
<BondNotional>100000</BondNotional>
</BondData>
<SettlementData>
<ForwardMaturityDate>20160808</ForwardMaturityDate>
<ForwardSettlementDate>20160810</ForwardSettlementDate>
<LockRate>0.02365</LockRate>
<dv01>0.8</dv01>
</SettlementData>
<LongInForward>true</LongInForward>
</ForwardBondData>

8.2.43 Bond Repo

A bond repo trade is set up using the trade type BondRepo and a BondRepoData block
as shown in listing 340. The block contains two nodes
• BondData, which specifies the underlying bond and its quantity, and
• RepoData, which specifies the cash leg of the repo
The BondData block contains the following fields
• SecurityId: The identified of the underlying security.
Allowable values: A valid key, usually of the form “ISIN::XY012345679”
• BondNotional: The notional of the underlying bond. This is the effective
notional used as collateral, i.e. it should include hair cuts. Usually the number
Bond Notional x Bond Dirty Price x (1 - Haircut) will correspond to the nominal
on the cash leg at trade inception.
Allowable values: Any positive real number.
• CreditRisk [Optional] Boolean flag indicating whether to show Credit Risk on
the Bond product.
Allowable Values: true or false Defaults to true if left blank or omitted.
In this case the details of the underlying bond is read from the reference data. It is
also possible to inline the details in the trade, see 8.2.39 for more details on this.
The RepoData block contains exactly one LegData subnode that describes the
payments on the cash leg of the repo, see 8.3.3 for details on how to set this up. The
Payer leg determines whether interest is paid (regular repo) or received (reversed repo).

426
Listing 340: Bond Repo Data

<BondRepoData>
<BondData>
<SecurityId>ISIN:US912828X703</SecurityId>
<BondNotional>27807597.777444</BondNotional>
</BondData>
<RepoData>
<LegData>
<LegType>Fixed</LegType>
<Payer>true</Payer>
<Currency>USD</Currency>
<Notionals>
<Notional>28371510.00</Notional>
</Notionals>
<ScheduleData>
<Rules>
<StartDate>2020-01-06</StartDate>
<EndDate>2020-04-07</EndDate>
<Tenor>1Y</Tenor>
<Calendar>US</Calendar>
<Convention>MF</Convention>
<TermConvention>MF</TermConvention>
<Rule>Forward</Rule>
<EndOfMonth/>
<FirstDate/>
<LastDate/>
</Rules>
</ScheduleData>
<DayCounter>A360</DayCounter>
<PaymentConvention>F</PaymentConvention>
<FixedLegData>
<Rates>
<Rate>0.0178</Rate>
</Rates>
</FixedLegData>
</LegData>
</RepoData>
</BondRepoData>

8.2.44 Bond Option

The structure of a trade node representing a BondOption is shown in listing 341:
• The BondOptionData node is the trade data container for the option part of a
bond option trade type. Vanilla bond options are supported, the exercise style
must be European. The BondOptionData node includes one and only one
OptionData trade component sub-node plus elements specific to the bond option.
• The latter also includes the underlying Bond description in the BondData node,
see section 8.2.39, listing 333 for details

427
Listing 341: Bond Option data

<Trade id="...">
<TradeType>BondOption</TradeType>
<Envelope>
...
</Envelope>
<BondOptionData>
<OptionData>
...
</OptionData>
<StrikeData>
<StrikePrice>
<Value>11809123.56</Value>
<Currency>EUR</Currency>
</StrikePrice>
</StrikeData>
<Redemption>100.00</Redemption>
<PriceType>Dirty</PriceType>
<KnocksOut>false</KnocksOut>
<BondData>
<VolatilityCurveId>YieldVols-EUR</VolatilityCurveId>
...
<BondData>
</BondOptionData>
</Trade>

The meanings and allowable values of the elements in the BondOptionData node follow
below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1 Option
Data. Note that the bond option type allows for European option style only.
• StrikeData: A node containing the strike information. Allowable values:
Supports StrikePrice and StrikeYield as described in Section 8.3.30.
• Redemption: Redemption ratio in percent
• PriceType: This node defines which strike should be used for the pricing. If the
node takes the value Dirty, the strike price should be set equal to the value of the
Strike node. If the node takes the value Clean, the strike price should be set
equal to the value of the Strike node plus accrued interest at the expiration date
of the option.
Allowable values: Dirty or Clean.
• KnocksOut: If true the option knocks out if the underlying defaults before the
option expiry, if false the option is written on the recovery value in case of a
default of the bond before the option expiry
The meanings and allowable values of the elements in the BondData are:
• VolatilityCurveId: The yield volatility curve to use for the valuation of this bond
option.

428
8.2.45 Bond Option (using bond reference data)
The structure of a trade node representing a BondOption is shown in listing 342:
• The BondOptionData node is the trade data container for the option part of a
bond option trade type. Vanilla bond options are supported, the exercise style
must be European. The BondOptionData node includes one and only one
OptionData trade component sub-node plus elements specific to the bond option.
• The latter also includes the underlying Bond description in the BondData node,
see below for details
Note that only par redemption vanilla bonds are supported.

Listing 342: Bond Option data using bond reference data

<Trade id="...">
<TradeType>BondOption</TradeType>
<Envelope>
...
</Envelope>
<BondOptionData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>European</Style>
<ExerciseDates>
<ExerciseDate>20210203</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<StrikeData>
<StrikePrice>
<Value>1.23</Value>
</StrikePrice>
</StrikeData>
<PriceType>Dirty</PriceType>
<KnocksOut>false</KnocksOut>
<BondData>
<SecurityId>ISIN:XS1234567890</SecurityId>
<BondNotional>100000</BondNotional>
<BondData>
</BondOptionData>
</Trade>

The meanings and allowable values of the elements in the BondOptionData node follow
below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1
Option Data.
The relevant fields in the OptionData node for a BondOption are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put. For option type Call, the
Bond Option holder has the right to buy the underlying Bond at the strike

429
 price. For option type Put, the Bond Option holder has the right to sell the
underlying Bond at the strike price.
– Style The allowable value is European only.
– Settlement [Optional] The allowable values are Cash or Physical, but this
field is currently ignored.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer
to the option seller.
Allowable values: See section 8.3.2
• StrikeData: A StrikeData node is used as described in Section 8.3.30 to
represent the Bond Option strike price or strike yield. If StrikePrice is used, the
strike price (Value field) is expressed per unit notional. If StrikeYield is used,
the Yield is quoted in decimal form, e.g. 5% should be entered as 0.05.
• PriceType [Mandatory for StrikePrice, no impact for StrikeYield]:
The payoff for a bond option is
max(B - X, 0)
where B is always the dirty NPV of the underlying bond on the exercise
settlement date.
If PriceType is Clean, X is (Strike + Underlying Bond Accruals) x BondNotional
If PriceType is Dirty, X is Strike x BondNotional
Allowable values: Dirty or Clean. If the StrikeData node uses StrikeYield,
PriceType can be omitted as it is not relevant in the yield case.
• KnocksOut: If true the option knocks out if the underlying defaults before the
option expiry, if false the option is written on the recovery value in case of a
default of the bond before the option expiry.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46.
The meanings and allowable values of the elements in the BondData are:
• SecurityId: The underlying security identifier
Allowable values: Typically the ISIN of the underlying bond, with the ISIN:
prefix.
• BondNotional: The notional of the underlying bond on which the option is
written expressed in the currency of the bond.
Allowable values: Any positive real number.
• CreditRisk [Optional] Boolean flag indicating whether to show Credit Risk on
the Bond product.
Allowable Values: true or false Defaults to true if left blank or omitted.

430
8.2.46 Bond Total Return Swap
A vanilla Bond Total Return Swap (Trade type: BondTRS ) is set up using a
BondTRSData block as shown in listing 344. The block is comprised of three sub-blocks,
which are BondData, TotalReturnData and FundingData.
• The BondData block specifies the underlying bond, usually by specifiying the
security id and the quantity / bond notional and relying on reference data:
– SecurityId: The underlying security identifier
Allowable values: Typically the ISIN of the underlying bond, with the ISIN:
prefix.
– BondNotional: The quantity or number of bonds that is relevant for the
TRS, with the convention that 1 bond always corresponds to a face value of
1 unit of bond currency.
Allowable values: Any positive real number.
– CreditRisk [Optional] Boolean flag indicating whether to show Credit Risk
on the Bond product. If set to true, the product class will be set to Credit
instead of RatesFX, and there will be credit sensitivities. Note that if the
underlying bond reference is set up without a CreditCurveId - typically for
some highly rated government bonds - the CreditRisk flag will have no
impact on the product class and no credit sensitivities will be shown even if
CreditRisk is set to true.
Allowable Values: true or false Defaults to true if left blank or omitted.
Alternatively, the BondData block can be specified fully explicit, as outlined in
8.2.39
• The TotalReturnData block specifies
– Payer: Indicates whether the total return leg is paid.
Allowable values: true or false
– InitialPrice [Optional]: Should be filled if the bond price on the first date of
the total return schedule is contractually given, in which case the price must
correspond to the price type of the total return leg, i.e. if the price type is
Dirty then the InitialPrice must also be a dirty price (as it is usually given
in the term sheet in this case). The price must given in percent, e.g.
101.20.11 If not given, the bond price for the first date of the total return
schedule is read from the price history. Notice that if a bond is quoted in
Currency per Unit the initial price should be given in this format too: If e.g.
one unit is 50.0 USD an initial price of 51.0 would correspond a dirty
amount of 51.0 USD for one unit of the bond.
Allowable values: Any positive real number.
– PriceType: The price type on which these payments are based
Allowable values: Dirty or Clean
– ObservationLag [Optional]: The lag between the valuation date and the
reference schedule period start date.
11
as opposed to the bond price in the fixing history, where it must be given as 1.0120 and is always
a clean quotation

431
 Allowable values: Any valid period, i.e. a non-negative whole number,
followed by D (days), W (weeks), M (months), Y (years). Defaults to 0D if
left blank or omitted.
– ObservationConvention [Optional]: The roll convention to be used when
applying the observation lag.
Allowable values: A valid roll convention (F, MF, P, MP, U, NEAREST ),
see Table 31 Roll Convention. Defaults to U if left blank or omitted.
– ObservationCalendar [Optional]: The calendar to be used when applying
the observation lag.
Allowable values: Any valid calendar, see Table 34 Calendar. Defaults to
the NullCalendar (no holidays) if left blank or omitted.
– PaymentLag [Optional]: The lag between the reference schedule period end
date and the payment date.
Allowable values: Any valid period, i.e. a non-negative whole number,
optionally followed by D (days), W (weeks), M (months), Y (years).
Defaults to 0D if left blank or omitted. If a whole number is given and no
letter, it is assumed that it is a number of D (days).
– PaymentConvention [Optional]: The business day convention to be used
when applying the payment lag.
Allowable values: A valid roll convention (F, MF, P, MP, U, NEAREST ),
see Table 31 Roll Convention. Defaults to U if left blank or omitted.
– PaymentCalendar [Optional]: The calendar to be used when applying the
payment lag.
Allowable values: Any valid calendar, see Table 34 Calendar. Defaults to
the NullCalendar (no holidays) if left blank or omitted.
– PaymentDates [Optional]: This node allows for the specification of a list of
explicit payment dates, using PaymentDate elements. The list must contain
exactly n − 1 dates where n is the number of dates in the reference schedule
given in the ScheduleData node. See Listing 343 for an example with an
assumed ScheduleData with 4 dates.
Listing 343: Payment dates

<PaymentDates>
<PaymentDate>2020-01-15</PaymentDate>
<PaymentDate>2021-01-15</PaymentDate>
<PaymentDate>2022-01-17</PaymentDate>
</PaymentDates>

– FXTerms [Mandatory when underlying bond and BondTRS currencies

differ]: Required if the bond currency is different from the return currency,
which is always assumed to be equal to the funding leg currency. This kind
of trade is also known as a “composite trs”. The subnode for the FXTerms
node is:

432
 ∗ FXIndex: The fx index to use for the conversion, this must contain the
bond currency and the funding leg currency (in the order defined in
table 38, i.e. it does not matter which one is the bond currency and
which is the funding currency)
Allowable values: See Table 38
– ScheduleData: The reference schedule for the return leg, where the
valuation dates are derived from this schedule using the ObservationLag,
ObservationConvention and ObservationCalendar fields. The payment dates
are derived from this schedule using the PaymentLag, PaymentConvention
and PaymentCalendar fields. The payment dates can also be given as an
explicit list in the PaymentDates node. Allowable values: A ScheduleData
block as defined in section 8.3.4
– PayBondCashFlowsImmediately [Optional]: If true, bond cashflows like
coupon or amortisation payments are paid when they occur. If false, these
cashflows are paid together with the next return payment. If omitted, the
default value is false.
Allowable values: true (immediate payment of bond cashflows) or false
(bond cashflows are paid on the next return payment date)
• The FundingData block specifies the funding leg, which can be of any leg type.
The FundingData contains exactly one Leg. The currency of this leg also defines
the currency in which the return is paid. Usually the funding leg’s notional will
be aligned with the return leg’s notional. To achieve this, indexings on the
floating leg can be used, see 8.3.8. In the context of bond total return swaps, the
indexings can be defined in a simplified way by adding an Indexings node with a
subnode FromAssetLeg set to true to the funding leg’s LegData node. The
notionals node is not required either in the funding leg’s LegData in this case.
An example for this setup is shown in 344.

433
Listing 344: Bond Total Return Swap Data with indexed funding leg

<BondTRSData>
<BondData>
<SecurityId>ISIN:NZIIBDT005C5</SecurityId>
<BondNotional>100000</BondNotional>
</BondData>
<TotalReturnData>
<Payer>false</Payer>
<InitialPrice>102.0</InitialPrice>
<PriceType>Clean</PriceType>
<ObservationLag>0D</ObservationLag>
<ObservationConvention>P</ObservationConvention>
<ObservationCalendar>USD</ObservationCalendar>
<PaymentLag>2D</PaymentLag>
<PaymentConvention>F</PaymentConvention>
<PaymentCalendar>TARGET</PaymentCalendar>
<!-- <PaymentDates> -->
<!-- <PaymentDate> ... </PaymentDate> -->
<!-- <PaymentDate> ... </PaymentDate> -->
<!-- </PaymentDates> -->
<FXTerms>
<FXIndex>FX-TR20H-NZD-USD</FXIndex>
</FXTerms>
<ScheduleData>
...
</ScheduleData>
<PayBondCashFlowsImmediately>false</PayBondCashFlowsImmediately>
</TotalReturnData>
<FundingData>
<LegData>
<Payer>true</Payer>
<LegType>Floating</LegType>
<Currency>USD</Currency>
...
<!-- Notionals node is not required, set to 1 internally -->
...
<Indexings>
<!-- derive the indexing information (bond price, FX) from the total return leg -->
<FromAssetLeg>true</FromAssetLeg>
</Indexings>
...
</LegData>
</FundingData>
</BondTRSData>

8.2.47 Convertible Bond

A convertible bond is set up using a ConvertibleBondData block as shown in listing
345. The bond details are read from reference data in this case.
A convertible bond is a bond, that can be converted into a prespecified number of
shares, given by:
BondN otional
N umberOf Shares =
ConversionRatio
Where the Conversion Ratio is specified in the underlying bond reference data.

434
The shares are usually from the bond issuer, but it is also possible that the shares are
from a different issuer (exchangeables). In addition, the share currency can be different
from the bond currency in both cases (cross-currency convertibles).
The bond might be callable by the issuer (typically in American style) and / or
puttable by the investor (typically in Bermudan style). The issuer calls can be “hard
calls”, which are call rights in the traditional sense, as opposed to “soft calls” which can
only the exercised if the equity price observed on the exercise date is above a
prespecified threshold given by TriggerRatios. If a soft call is exercised, the investor
has the right to convert the bond into shares instead of accepting the payment from
the issuer call (“forced conversion”).
The meanings and allowable values of the elements in the ConvertibleBondData block
are as follows:
• SecurityId: The underlying security identifier
Allowable values: Typically the ISIN of the underlying bond, with the ISIN:
prefix.
• BondNotional: The notional of the underlying bond expressed in the currency of
the bond.
Allowable values: Any positive real number.
• CreditRisk [Optional] Boolean flag indicating whether to show Credit Risk on
the Bond product.
Allowable Values: true or false Defaults to true if left blank or omitted.

Listing 345: Convertible bond set up using reference data

<Trade id="ConvertibleBond">
<TradeType>ConvertibleBond</TradeType>
<Envelope>...</Envelope>
<ConvertibleBondData>
<BondData>
<SecurityId>ISIN:XS0451905367</SecurityId>
<BondNotional>1000000.00</BondNotional>
</BondData>
</ConvertibleBondData>
</Trade>

Alternatively the bond can be set up with further explicit details using the blocks as
shown in listing 346. All fields that are not given in the trade XML are filled up with
the information from the reference data if available in the reference data. In other
words, if reference data is given, the trade xml can still be used to overwrite the
information partially, if this seems appropriate. The meanings and allowable values of
the elements in the block are as follows:
• BondData: The vanilla part of the bond, see 8.2.39.
• CallData: The call terms of the bond, as described below. Optional, if not given,
no calls are present.
• PutData: The put terms of the bond, as described below. Optional, if not given,
no puts are present.

435
 • ConversionData: The conversion terms of the bond, as described below. This
node must always be given, even if no conversion rights are present (in which
case an empty conversion date list can be used).
• DividendProtectionData: The dividend protection terms of the bond, as
described below. Optional, if not given, no dividend prtection is present.
• Detachable: If true, the trade represents the embedded optionality, i.e. the
difference between the full convertible bond and the bond floor. Optional,
defaults to false.
Allowable values: true, false
The convertible bond trade type supports perpetual schedules, i.e. perpetual
convertible bonds can be represented by omitting the EndDate in the following
schedules to indicate perpetual schedules. Only rule based schedules can be used to
indicate perpetual schedules.
• BondData / LegData: Omitting the EndDate in this schedule indicates that the
underlying bond runs perpetually.
• CallData: Omitting the EndDate in this schedule indicates perpetual call dates.
For American call dates, where only two dates have to be specified (start and end
date of the american call window), a rule based schedule with Tenor = 0D, Rule
= Zero and without EndDate can be used to indicate an end date infinitely far
away in the future.
• PutData: Same as CallData.
• ConversionData: Omitting the EndDate in this schedule indicates perpetual
conversion rights. For American rights, the same comment as under CallData
applies.
• ConversionData / ConversionResets: Omitting the EndDate in this schedule
indicates perpetual conversion resets.
• DividendProtectionData: Omitting the EndDate in this schedule indicates a
perpetual dividend protection schedule.

Listing 346: Convertible bond set up using the detail blocks

<Trade id="ConvertibleBond">
<TradeType>ConvertibleBond</TradeType>
<Envelope>...</Envelope>
<ConvertibleBondData>
<BondData> ... </BondData>
<CallData> ... </CallData>
<PutData> ... </PutData>
<ConversionData> ... </ConversionData>
<DividendProtectionData> ... </DividendProtectionData>
<Detachable>false</Detachable>
</ConvertibleBondData>
</Trade>

Specification of CallData / PutData:

436
All lists specified in subnodes (except the date list itself of course) can be specified as
either an explicit list of values corresponding to the schedule dates list or using the
attribute startDate. An explicit value list can be shorter than the list of dates, in
which case the last value from the list is associated to the remaining dates.
See listings 347,348,349,350,351,352,353 for examples of exercise schedules.
• Styles: A list of the exercise styles. Notice that Bermudan is used to define
European exercises as well, namely as a Bermudan exercise with a single exercise
date. The attribute startDate can be used to specify the list.
Allowable values: American, Bermudan
• ScheduleData: A schedule of exercise dates (for Bermudan exercises) or start /
end dates (for American exercises)
Allowable values: see 8.3.4.
• Prices: A list of exercise prices in relative terms, i.e. if the price is 1.02 then the
amount paid on the exercise is this price times the current notional of the bond
(plus accrued interest, if the price type is clean, see below). The attribute
startDate can be used to specify the list.
Allowable values: Any positive real number.
• PriceType: A list of the flavour in which the exercise prices are given. The
attribute startDate can be used to specify the list.
Allowable values: Clean, Dirty.
• IncludeAccrual: A list of flags specifying whether accruals have to be paid on
exercise. This is independent of the quoting style of the exercise prices
(PriceType).
Allowable values: true, false
• Soft: A list of flags specifying whether the call is soft (true) or hard (false). The
attribute startDate can be used to specify the list. Optional, defaults to false.
Only applicable to Calls, not to Puts. Optional, if not given, false is assumed, i.e.
hard calls. If soft calls are specified, at least one conversion exercise date with
corresponding conversion rate must be defined under ConversionData.
Allowable values: true, false
• TriggerRatios: A list of trigger ratios T for soft calls. A soft call can be executed
only if the equity price on the exercise date is above the Conversion Price
(defined below) times the trigger ratio, i.e. St > CtP T . Only applicable to Calls,
not to Puts. Required for soft calls, can be omitted otherwise.
1
ConversionP rice, CtP =
ConversionRatio
For cross-currency trades the conversion price is usually quoted in equity ccy, i.e.

1
ConversionP rice, CtP =
ConversionRatio · Xt

where Xt converts one equity ccy unit to bond ccy

Allowable values: Any positive real number.

437
• NofMTriggers: A list of n-of-m trigger specifications for calls, i.e. the soft-call
trigger defined by TriggerRatios must be observed on n of the m days before the
exercise dates for the call to be active. Only applicable to Calls, not to Puts.
Optional, defaults to “0-of-0”
Allowable values: x-of-y with x, y non-negative integers, “0-of-0” disables the
trigger
• MakeWhole: A list of make whole conditions. Optional. Possible subnodes are:
– ConversionRatioIncrease: In case of a call exercise, the conversion ratio
(applicable in case of a forced conversion) is adjusted upwards. The
adjustment is additive, i.e. if the current conversion ratio is CR the
conversion ratio applicable in case of a forced conversion will be CR + d
where d is interpolated from a matrix of effective dates (rows) and stock
prices (columns). The conversion rate adjustment might be capped by a
prespecified rate. If the exercise date / stock price lies outside the matrix, d
is zero, i.e. no adjustment is made. Notice that a soft call trigger is checked
w.r.t. CR, i.e. the unadjusted conversion ratio.
∗ Cap: An upper bound for the adjusted conversion ratio. Optional, if
not given, no cap will be applied.
Allowable values: Any non-negative real number.
∗ StockPrices: A comma separated list of stock prices defining the
interpolation grid’s x values. At least two stock prices must be given.
Allowable values: A list of non-negative real numbers.
∗ CrIncreases: A node that contains at least two subnodes CrIncrease.
Each subnode must have an attribute startDate defining the effective
date of the adjustment and a list of conversion ratio adjustments d. The
number of adjustments must match the number of prices given in the
StockPrices node.
Allowable values: A list of non-negative real numbers.

438
Listing 347: Convertible bond call data example 1

<!-- Bermudan issuer call on three dates at a clean price of 100 (hard calls),
accruals are paid on exercise -->
<CallData>
<Styles>
<Style>Bermudan</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2017-08-03</Date>
<Date>2018-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<Prices>
<Price>1.00</Price>
</Prices>
<PriceTypes>
<PriceType>Clean</PriceType>
</PriceTypes>
<IncludeAccruals>
<IncludeAccrual>true</IncludeAccrual>
</IncludeAccruals>
<Soft>
<Soft>false</Soft>
</Soft>
<TriggerRatios/>
<NofMTriggers>
<NOfMTrigger>20-of-30</NOfMTrigger>
</NofMTriggers>
</CallData>

439
Listing 348: Convertible bond call data example 2

<!-- Bermudan issuer call on three dates at a clean price of 101, 102 and 103,
soft calls with trigger ratio of 0.8, 0.85, 0.9,
accrual are _not_ paid on exercise -->
<CallData>
<Styles>
<Style>Bermudan</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2017-08-03</Date>
<Date>2018-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<Prices>
<Price>1.01</Price>
<Price>1.02</Price>
<Price>1.03</Price>
</Prices>
<PriceTypes>
<PriceType>Clean</PriceType>
</PriceTypes>
<IncludeAccruals>
<IncludeAccrual>false</IncludeAccrual>
</IncludeAccruals>
<Soft>
<Soft>true</Soft>
</Soft>
<TriggerRatios>
<TriggerRatio>0.8</TriggerRatio>
<TriggerRatio>0.85</TriggerRatio>
<TriggerRatio>0.9</TriggerRatio>
</TriggerRatios>
</CallData>

440
Listing 349: Convertible bond call data example 3

<!-- American issuer call between 2016-08-03 and 2018-08-03

at a clean price of 100 (hard calls) -->
<CallData>
<Styles>
<Style>American</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2018-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<Prices>
<Price>1.00</Price>
</Prices>
<PriceTypes>
<PriceType>Clean</PriceType>
</PriceTypes>
<IncludeAccruals>
<IncludeAccrual>true</IncludeAccrual>
</IncludeAccruals>
<Soft>
<Soft>false</Soft>
</Soft>
<TriggerRatios/>
</CallData>

441
Listing 350: Convertible bond call data example 4

<!-- American issuer call between 2016-08-03 and 2020-08-03 (excl),

hard calls at 100 between 2016-08-03 and 2018-08-03 (excl),
soft calls at 102 between 2018-08-03 and 2019-08-03 (excl),
soft calls at 103 between 2019-08-03 and 2020-08-03 -->
<CallData>
<Styles>
<Style>American</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2018-08-03</Date>
<Date>2019-08-03</Date>
<Date>2020-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<Prices>
<Price>1.00</Price>
<Price startDate="2018-08-03">1.02</Price>
<Price startDate="2019-08-03">1.03</Price>
</Prices>
<PriceTypes>
<PriceType>Clean</PriceType>
</PriceTypes>
<IncludeAccruals>
<IncludeAccrual>true</IncludeAccrual>
</IncludeAccruals>
<Soft>
<Soft>false</Soft>
<Soft startDate="2018-03-03">true</Soft>
</Soft>
<TriggerRatios>
<TriggerRatio>0.8</TriggerRatio>
<TriggerRatio startDate="2019-08-03">0.9</TriggerRatio>
</TriggerRatios>
</CallData>

442
Listing 351: Convertible bond call data example 5

<!-- Bermudan (hard) calls at 100 at 3 dates from 2016 to 2018,

followed by American (soft) calls at 102 between 2018 and 2020 -->
<CallData>
<Styles>
<Style>Bermudan</Style>
<Style startDate="2018-08-03">American</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2017-08-03</Date>
<Date>2018-08-03</Date>
<Date>2020-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<Prices>
<Price>1.00</Price>
<Price startDate="2018-08-03">1.02</Price>
</Prices>
<PriceTypes>
<PriceType>Clean</PriceType>
</PriceTypes>
<IncludeAccruals>
<IncludeAccrual>true</IncludeAccrual>
</IncludeAccruals>
<Soft>
<Soft>false</Soft>
<Soft startDate="2018-08-03">true</Soft>
</Soft>
<TriggerRatios>
<TriggerRatio>0.8</TriggerRatio>
</TriggerRatios>
</CallData>

443
Listing 352: Convertible bond put data example 6

<!-- Bermudan puts calls at 100, 101, 102 at 3 dates from 2016 to 2018 -->
<PutData>
<Styles>
<Style>Bermudan</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2017-08-03</Date>
<Date>2018-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<Prices>
<Price>1.00</Price>
<Price>1.01</Price>
<Price>1.02</Price>
</Prices>
<PriceTypes>
<PriceType>Clean</PriceType>
</PriceTypes>
<IncludeAccruals>
<IncludeAccrual>true</IncludeAccrual>
</IncludeAccruals>
</PutData>

Listing 353: Convertible bond make whole data (conversion ratio increase)

<CallData>
...
<MakeWhole>
<ConversionRatioIncrease>
<Cap>0.0740740</Cap>
<StockPrices>13.50,15.00,16.20,18.00</StockPrices>
<CrIncreases>
<CrIncrease startDate="2020-06-25">0.0123456,0.0107487,0.0097173,0.0084567</CrIncrease>
<CrIncrease startDate="2021-07-01">0.0123456,0.0096880,0.0086963,0.0075294</CrIncrease>
<CrIncrease startDate="2022-07-01">0.0123456,0.0083927,0.0074222,0.0063383</CrIncrease>
<CrIncrease startDate="2023-07-01">0.0123456,0.0069360,0.0058790,0.0048322</CrIncrease>
<CrIncrease startDate="2024-07-01">0.0123456,0.0054453,0.0040025,0.0028833</CrIncrease>
<CrIncrease startDate="2025-07-01">0.0123456,0.0049380,0.0000000,0.0000000</CrIncrease>
</CrIncreases>
</ConversionRatioIncrease>
</MakeWhole>
</CallData>

Specification of ConversionData:
As in the case of the CallData, all lists can be specified as either an explicit list of
values corresponding to the schedule dates list or using the attribute startDate. The
ConversionRatios element is an expcetion, the given start dates are interpreted
independently of these schedule dates.

444
See listings 354, 355,356,357, 358,359 for examples of conversion schedules.
• Styles: The styles of the conversion rights. Notice that Bermudan is used to
define European conversion rights as well, namely as a Bermudan conversion
right with a single date. The attribute startDate can be used to specify the list.
Can be omitted, if no conversion dates are given.
Allwoable values: American, Bermudan
• ScheduleData: The dates defining when the bond is convertible. For Bermudan
exercises, the conversion can be executed on the single dates given in the list. For
American exercises, the conversion can be executed between a given start and
end date. Can be omitted, if no conversion rights are present.
Allowable values: see 8.3.4.
• ConversionRatios: A list of conversion ratios C R . The attribute startDate can
be used to specify a date from which the ratio is valid. Notice that this date is
always interpreted “as is”, i.e. it is not mapped onto the next date in the defined
schedule. If no startDate is given for a ratio, this ratio is interpreted as the initial
ratio.
Allowable values: Any non-negative real number.
• FixedConversionAmounts: If this node is given, the conversion is specified to be
conversion to fixed cash amounts instead of equity. If the cash amount currency
is different from the bond currency, the FXIndex node must be given. See 359 for
an example. As for ConversionRatios the attribute startDate can be used to
specify a date from which the amount is valid and this date is interpreted “as is”,
i.e. not mapped onto the next date in the defined schedule. The nodes
– ConversionRatios
– ContingentConversion
– MandatoryConversion
– ConversionResets
– Underlying
– Exchangeable
must not be given, if this node is present. Furthermore, the following nodes from
other sections are not applicable if the conversion is specified to be fixed cash
amounts, and must therefore not be given:
– CallData/Soft
– CallData/TriggerRatios
– CallData/NoMTriggers
– CallData/MakeWhole
– DividendProtectionData (including all subnodes)
• ContingentConversion: This adds a condition CtR St > B on the convertibility for
the periods defined by the conversion dates. Optional.

445
 – Observations: A list of observation modes.
Allowable values: Spot (trigger is checked on the conversion date),
StartOfPeriod (trigger is checked on the start of the conversion period
defined by the dates list, for American style conversion only)
– Barriers: A list of barriers B associated to the conversion dates.
Allowable values: Positive real number or zero (conversion is not made
contingent for this date).
• MandatoryConversion: This adds a mandatory conversion obligation at a date
greater than all other conversion dates (if any). Optional.
– Date: The mandatory conversion date.
Allowable values: Any date not earlier than the last otherwise specified
conversion date.
– Type: The type of the mandatory conversion.
Allowable values: PEPS
– PepsData: Details of mandatory conversion type PEPS.
∗ UpperBarrier: upper barrier for PEPS payoff.
Allowable values: A real number.
∗ LowerBarrier: lower barrier for PEPS payoff.
Allowable values: A real number.
∗ UpperConversionRatio: conversion ratio for upper barrier in PEPS
payoff.
Allowable values: A real number.
∗ LowerConversionRatio: conversion ratio for lower barrier in PEPS
payoff.
Allowable values: A real number.
• ConversionResets: This adds a reset schedule for the conversion rate. If a reset
feature is defined, only an initial ConversionRatio can be defined, the future
conversion ratios are determined by the resets. The startDate attribute can be
used to define references, thresholds, gearings, floors, global floors. Optional.
– ScheduleData: The conversion reset dates.
Allowable values: see 8.3.4.
– References: Whether the initial conversion price C0P or the current
conversion price CtP is the reference for the reset.
Allowable values: InitialConversionPrice, CurrentConversionPrice
– Thresholds: The threshold T that triggers a reset (St < T C0P or St < T CtP ,
depending on Reference)
Allowable values: positive number or zero (disables the reset on this date
effectively)
– Gearings: The gearings g for the conversion rate adjustment. Option,
defaults to 0 (= no gearing applicable)

446
 Allowable values: positive number or zero (no gearing applicable on this
date).
– Floors: The floors f for the conversion rate adjustment. Optional, defaults
to 0 (= no floor applicable)
Allowable values: positive number or zero (no floor applicable on this date)
– GlobalFloors: The global floors for the conversion rate adjustment. Option,
defaults to 0 (= no global floor applicable)
Allowable values: positive number or zero (no global floor applicable on this
date)
• Underlying: The equity underlying.
Allwoable values: See 8.3.29, the underlying type must be equity.
• FXIndex: If equity ccy is different from bond ccy, an fx index for the two
involved ccy is required.
Allowable values: The format of the FX Index is“FX-SOURCE-CCY1-CCY2” as
described in table 38.
• Exchangeable: Node with data for exchangeables. Option, if omitted, the
structure is considered non-exchangeable. Subnodes are:
– IsExchangeable: indicates whether the convertible bond is exchangeable
Allowable values: true, false
– EquityCreditCurve: the credit curve modeling the equity issuer default,
required if IsExchangeable is true.
Allowable values: A valid credit curve identifier, e.g the ISIN of a reference
bond with the ISIN: prefix: ISIN:XXNNNNNNNNNN
– Secured: Indicates whether the convertible is secured with pledged shares or
not. Optional, defaults to false.
Allowable values: true, false.

447
Listing 354: Convertible bond conversion example 1

<!-- Three conversion dates (Bermudan), conversion ratio is 0.5 -->

<ConversionData>
<Styles>
<Style>Bermudan</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2017-08-03</Date>
<Date>2018-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<ConversionRatios>
<ConversionRatio>0.05</ConversionRatio>
</ConversionRatios>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.ABCD</Name>
</Underlying>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
<Exchangeable>
<IsExchangeable>true</IsExchangeable>
<EquityCreditCurve>ISIN:XS0982710740</EquityCreditCurve>
<Secured>true</Secured>
</Exchangeable>
</ConversionData>

448
Listing 355: Convertible bond conversion example 2

<!-- American conversion between 2016-08-03 and 2020-08-03, with

conversion ratio 0.5 for 2016-08-03 through 2018-08-03 (excl) and
conversion ratio 0.6 for 2018-08-03 through 2020-08-03 -->
<ConversionData>
<Styles>
<Style>American</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2018-08-03</Date>
<Date>2020-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<ConversionRatios>
<ConversionRatio>0.05</ConversionRatio>
<ConversionRatio startDate="2018-08-03">0.06</ConversionRatio>
</ConversionRatios>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.ABCD</Name>
</Underlying>
</ConversionData>

449
Listing 356: Convertible bond conversion example 3

<!-- American conversion between 2016-08-03 and 2018-08-03, with conversion

ratio 0.5, the conversion is contingent on the parity being above 1.3
on 2016-08-03 for the conversion between 2016-08-03 and 2017-08-03 (excl)
on 2017-08-03 for the conversion between 2017-08-03 and 2018-08-03 -->
<ConversionData>
<Styles>
<Style>American</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2017-08-03</Date>
<Date>2018-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<ConversionRatios>
<ConversionRatio>0.05</ConversionRatio>
</ConversionRatios>
<ContingentConversion>
<Observations>
<Observation>StartOfPeriod</Observation>
</Observations>
<Barriers>
<Barrier>1.3</Barrier>
</Barriers>
</ContingentConversion>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.ABCD</Name>
</Underlying>
</ConversionData>

450
Listing 357: Convertible bond conversion example 4

<!-- American converion between 2016-08-03 and 2018-08-03 with CR 0.5.

Mandatory conversion on 2020-08-03:
LowerConversionRatio applies if stock price < LowerBarrier,
UpperConversionRatio applies if stock price > UpperBarrier -->
<ConversionData>
<Styles>
<Style>American</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2018-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<ConversionRatios>
<ConversionRatio>0.05</ConversionRatio>
</ConversionRatios>
<MandatoryConversion>
<Date>2020-08-03</Date>
<Type>PEPS</Type>
<PepsData>
<UpperBarrier>32.5</UpperBarrier>
<LowerBarrier>20.5</LowerBarrier>
<UpperConversionRatio>0.08</UpperConversionRatio>
<LowerConversionRatio>0.03</LowerConversionRatio>
</PepsData>
</MandatoryConversion>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.ABCD</Name>
</Underlying>
</ConversionData>

451
Listing 358: Convertible bond conversion example 5

<!-- American conversion between 2016-08-03 and 2018-08-03 with CR 0.5.

The conversion ratio is reset on 2016-11-03, 2017-02-03, 2018-05-03
using T = 0.9, g = 0.8, f = 0.6, F = 0.6. -->
<ConversionData>
<Styles>
<Style>American</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2018-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<ConversionRatios>
<ConversionRatio>0.05</ConversionRatio>
</ConversionRatios>
<ConversionResets>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-11-03</Date>
<Date>2017-02-03</Date>
<Date>2018-05-03</Date>
</Dates>
</Dates>
</ScheduleData>
<References>
<Reference>InitialConversionPrice</Reference>
</References>
<Thresholds>
<Threshold>0.9</Threshold>
</Thresholds>
<Gearings>
<Gearing>0.8</Gearing>
</Gearings>
<Floors>
<Floor>0.7</Floor>
</Floors>
<GlobalFloors>
<GlobalFloor>15</GlobalFloor>
</GlobalFloors>
</ConversionResets>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.ABCD</Name>
</Underlying>
</ConversionData>

452
Listing 359: Convertible bond conversion example 6

<!-- American conversion between 2024-08-24 and 2027-05-13, with

conversion to 0.87 GBP cash for 2024-08-24 through 2024-11-23 (excl) and
conversion to 0.75 GBP cash for 2024-11-23 through 2027-05-13 -->
<ConversionData>
<Styles>
<Style>American</Style>
</Styles>
<ScheduleData>
<Dates>
<Dates>
<Date>2024-08-24</Date>
<Date>2024-11-23</Date>
<Date>2027-05-13</Date>
</Dates>
</Dates>
</ScheduleData>
<FixedAmountConversion>
<Currency>GBP</Currency>
<Amounts>
<Amount>0.87</Amount>
<Amount startDate="2024-11-24">0.75</Amount>
</Amounts>
</FixedAmountConversion>
</ConversionData>

Specification of DividendProtectionData:
As for the CallData, all lists can be specified as either an explicit list of values
corresponding to the schedule dates list or using the attribute startDate.
See listings 360, 361 for examples of dividend protection schedules.
• ScheduleData: The dates of the dividend protection schedule. The first date
marks the date when the dividend protection becomes effective, i.e. dividend
payments from this date on are taken into account in conversion ratio
adjustments or passthroughs. The second date is then the first date on which the
accumulated dividends between the first and second date trigger a conversion
ratio reset or passthrough, and similar for all subsequent dates. The last given
date is the last date with a conversion ratio reset or passthrough.
Allowable values: see 8.3.4.
• AdjustmentStyles: Whether the dividend excessing the threshold is passed
through or the conversion ratio is adjusted. In both cases, the adjustment can be
upwards only or up and down.
Allwoable values: CrUpOnly, CrUpDown, CrUpOnly2, CrUpDown2,
PassThroughUpOnly, PassThroughUpDown
• DividendTypes: Whether the conversion ratio adjustment is calculated in terms
of absolute or relative dividends. Does not have an effect for pass through
dividends (should be set to Aboslute in this case).
Allwoable values: Absolute, Relative
• Thresholds: The threshold H. Notice that the threshold applies to each single

453
 period of the dividend protection schedule. If the threshold is e.g. provided on an
annual basis in the terms of the convertible bond, but the dividend protection
schedule is quarterly, then the threshold in the trade xml should be the annual
threshold divided by 4.
Allwoable values: Any non-negativee number.

Listing 360: Convertible bond dividend protection example 1

<!-- Divdend protection based on aboslute dividend amounts via adjustment

of the conversion rate, up-only adjustment. -->
<DividendProtectionData>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2017-08-03</Date>
<Date>2018-08-03</Date>
<Date>2019-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<AdjustmentStyles>
<AdjustmentStyle>CrUpOnly</AdjustmentStyle>
</AdjustmentStyles>
<DividendTypes>
<DividendType>Absolute</DividendType>
</DividendTypes>
<Thresholds>
<Threshold>1.2</Threshold>
</Thresholds>
</DividendProtectionData>

454
Listing 361: Convertible bond dividend protection example 2

<!-- Dividend protection based on relative dividend amounts via adjustment

of the conversion rate, up-only adjustment. -->
<DividendProtectionData>
<ScheduleData>
<Dates>
<Dates>
<Date>2016-08-03</Date>
<Date>2017-08-03</Date>
<Date>2018-08-03</Date>
<Date>2019-08-03</Date>
</Dates>
</Dates>
</ScheduleData>
<AdjustmentStyles>
<AdjustmentStyle>CrUpOnly</AdjustmentStyle>
</AdjustmentStyles>
<DividendTypes>
<DividendType>Relative</DividendType>
</DividendTypes>
<Thresholds>
<Threshold>0.01</Threshold>
</Thresholds>
</DividendProtectionData>

8.2.48 Ascot
An Ascot is set up using an AscotData block as shown in listing 362. The bond details
are read from reference data in this case.
An Ascot or a Convertible Bond Option is an American style option to buy back a
convertible bond. The buyer of a Call Ascot can exercise the deal and get the
underlying bond in exchange for paying the strike.
The payout formula for a Call Ascot is:

P ayout = max(0, convertibleP rice − Strike)

And for a Put Ascot:

P ayout = max(0, Strike − convertibleP rice)

where:

Strike = bondQuantity ·(upf rontP ayment+assetLeg −redemptionLeg)−f undingLeg

455
Listing 362: Ascot set up using reference data

<Trade id="Ascot">
<TradeType>Ascot</TradeType>
<Envelope>...</Envelope>
<AscotData>
<ConvertibleBondData>
<BondData>
<SecurityId>ISIN:XY1000000000</SecurityId>
<BondNotional>1000000.00</BondNotional>
</BondData>
</ConvertibleBondData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>American</Style>
<Settlement>Physical</Settlement>
<ExerciseDates>
<ExerciseDate>2029-02-03</ExerciseDate>
</ExerciseDates>
</OptionData>
<ReferenceSwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>false</Payer>
...
</LegData>
</ReferenceSwapData>
<AscotData>
</Trade>

The meanings and allowable values of the elements in the block are as follows:
• ConvertibleBondData: This describes the underlying convertible bond, see 8.2.47.
• OptionData: This is a trade component sub-node outlined in section 8.3.1
Option Data. The relevant fields in the OptionData node for an Ascot are:
– LongShort The allowable values are Long or Short. The LongShort flag
multiplies the option price with +1 / -1. Call and Put payout formulas
above are from the long perspective
– OptionType The allowable values are Call or Put. See payout formulas
above.
– Style The Ascot type allows for American option exercise style only.
– Settlement The allowable values are Cash or Physical.
– An ExerciseDates node where exactly one ExerciseDate date element
must be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer to
the option seller.
Allowable values: See section 8.3.2

456
 • ReferenceSwapData: Contains a single LegData node that describes the trade’s
reference swap funding leg. The asset leg is implied from the bond data. Payer
should always be false i.e. the swap is entered from the viewpoint of the asset
swap buyer.

8.2.49 Collateral Bond Obligation CBO

A Cashflow CDO or Collateral Bond Obligation CBO (trade type CBO) can be set up
in a short version referencing the underlying CBO structure in a static CBO reference
datum or a long version, where the CBO structure is specified explicitly.
The main building block is the CBOData block as shown in listing 363. The CBOData
requires the two components CBOInvestment and CBOStructure. Where the latter
represents the general structure, the former specfies the actual investment. For the
short version, the CBO is fully specified using the component CBOInvestment only, the
component CBOStructure can be omitted.
Listing 363 exhibits the long version:

Listing 363: CBO Data

<CBOData>
<CBOInvestment>
<TrancheName>JuniorNote</TrancheName>
<Notional>4000000.00</Notional>
<StructureId>Constellation</StructureId>
</CBOInvestment>
<CBOStructure>
<DayCounter>ACT/ACT</DayCounter>
<PaymentConvention>F</PaymentConvention>
<Currency>EUR</Currency>
<ReinvestmentEndDate>2019-12-31</ReinvestmentEndDate>
<SeniorFee>0.01</SeniorFee>
<FeeDayCounter>A365</FeeDayCounter>
<SubordinatedFee>0.02</SubordinatedFee>
<EquityKicker>0.25</EquityKicker>
<BondBasketData>
...
</BondBasketData>
<CBOTranches>
...
</CBOTranches>
<ScheduleData>
...
</ScheduleData>
</CBOStructure>
</CBOData>

The meanings of the elements of the CBOData node follow below:

• TrancheName: Specifies of which tranche, results are shown in the report files
(NPV, Sensitivity, ...). The name needs to match one the names specified in
CBOTranches.

457
 • Notional: Is the invested amount into the tranche specified above. The value is
used to scale the NPV from the general tranche NPV, so it may be different to
the face amount specified in CBOTranches.
• StructureId: if details of the cbo are read from the reference data, StructureId is
used as a key.
• DayCounter: The day count convention of the tranches. Allowable values: See
table 35.
• PaymentConvention: The payment convention of the tranches. Allowable values:
See Table 31 Roll Convention.
• Currency: Defines the currency of the trade, i.e. the currency of the tranches.
Allowable values: See Table 32 Currency.
• ReinvestmentEndDate: Defines the end of the reinvestment period. During the
reinvestment period, principal proceeds are used to reinvest in eliglible assets
rather than to redeem CBO notes. Currently the model cannot handle
underlying bonds with full amortisation within the reinvestment period. In case
the underlying bonds amortise only parts of their full notional (during that
period), the model will leave outstanding balance constant until the end of the
reinvestment period. Therafter the underyling bonds amortises at a higher speed.
• SeniorFee: The fee, expressed as rate, paid before all other obligations, top of the
waterfall.
• FeeDayCounter: The day count convention for the fees. Allowable values: See
table 35.
• SubordinatedFee: The fee, expressed as rate, paid after all other obligations.
• EquityKicker: Fraction x of the residual payment, that will be split among the
senior fee receiver (x) and the equity piece (1-x).
• BondBasketData: All specifications of the underlying bond basket. Uses the sub
node BondBasketData as described in section 8.3.33.
• CBOTranches: All required instrument data for the tranches of the CBO. Uses
the sub node CBOTranches as described in section 8.3.34.
• ScheduleData: This is a trade component sub-node outlined in section 8.3.4
Schedule Data and Dates.
Listing 364 exhibits the reference data in conjunction with short version of the
CBOData in listing 365. The element meanings are the same as in the long version.

458
Listing 364: CboReferenceData

<ReferenceDatum id="Constellation">
<Type>CBO</Type>
<CboReferenceData>
<Currency>USD</Currency>
<DayCounter>A365</DayCounter>
<PaymentConvention>F</PaymentConvention>
<SeniorFee>0.001</SeniorFee>
<FeeDayCounter>A365</FeeDayCounter>
<SubordinatedFee>0.005</SubordinatedFee>
<EquityKicker>0.01</EquityKicker>
<CBOTranches>
...
</CBOTranches>
<ScheduleData>
...
</ScheduleData>
<BondBasketData>
...
</BondBasketData>
</CboReferenceData>
</ReferenceDatum>

Listing 365: CBOInvestment

<CBOData>
<CBOInvestment>
<TrancheName>JuniorNote</TrancheName>
<Notional>4000000.00</Notional>
<StructureId>Constellation</StructureId>
</CBOInvestment>
</CBOData>

8.2.50 Composite Trade

The CompositeTradeData node is the trade data container for the CompositeTrade
trade type. A composite trade is a hybrid position consisting of multiple component
trades. The structure of an example CompositeTradeData node for a commodity
option is shown in Listing 366.

459
Listing 366: Composite trade data

<CompositeTradeData>
<Currency>USD</Currency>
<NotionalCalculation>Sum</NotionalCalculation>
<Components>
<Trade id="">
<!-- A valid trade xml -->
</Trade>
<Trade id="">
<!-- A valid trade xml -->
</Trade>
</Components>
</CompositeTradeData>

Listing 367: Composite trade data with Reference Data

<CompositeTradeData>
<Currency>USD</Currency>
<NotionalCalculation>Sum</NotionalCalculation>
<PortfolioBasket>true</PortfolioBasket>
<BasketName>NAME</BasketName>
</CompositeTradeData>

The meanings and allowable values of the elements in the CompositeTradeData node
follow below.
• Currency: Defines the currency the NPV of the composite trade will be
represented in.
Allowable values: See Table 32 Currency.
• NotionalCalculation [Optional]: The method by which the notional of the
composite trade will be calculated.
Allowable values:
Sum: The notional will be calculated as the sum of the notionals of the
constituent trades. This is the default behaviour if the field is omitted
(unless an override is provided).
Mean or Average: The notional will be calculated as the mean of the
notionals of the constituent trades.
First: The notional of the first constituent trade will be used.
Last: The notional of the first constituent trade will be used.
Min: The notional will be calculated as the minimum of the notionals of the
constituent trades.
Max : The notional will be calculated as the minimum of the notionals of
the constituent trades.
Override: the notional will be read directly from the notional override field.

460
 • NotionalOverride [Optional]: The notional which will be used for the trade,
overriding any calculation method specified.
Allowable values: Any non-negative real number.
• Components: The portfolio of trades that make up the composite trade.
Allowable values: These trades should be valid xmls that could otherwise be
entered into the portfolio, with the exception that they can have empty ids.
• PortfolioBasket [Optional]: Indicate if the Component represent a portfolio
basket.
Allowable values: Boolean true or false.
• BasketName [Optional]: The portfolio Id.
Allowable values: Any string. Note that if PortfolioBasket is True then there
must be a BasketName. We look up the Basket within the reference data.

8.2.51 Credit Default Swap / Quanto Credit Default Swap

A credit default swap, trade type CreditDefaultSwap, is set up using a
CreditDefaultSwapData block as shown in listing 368 or 369. The
CreditDefaultSwapData block must include either a CreditCurveId element or a
ReferenceInformation node.
The LegData sub-node must be a fixed leg, and represents the recurring premium
payments. The direction of the fixed leg payments define if the CDS is for bought
(Payer: true) or sold (Payer: false) protection.
The elements have the following meaning:
• IssuerId [Optional]: An identifier for the reference entity of the CDS. For
informational purposes and not used for pricing.
• CreditCurveId: The identifier of the reference entity defining the default curve
used for pricing. For the allowable values, see CreditCurveId for credit trades -
single name in Table 40. A ReferenceInformation node may be used in place of
this CreditCurveId node.
• ReferenceInformation: This node may be used as an alternative to the
CreditCurveId node to specify the reference entity, tier, currency and
documentation clause for the CDS. This in turn defines the credit curve used for
pricing. The ReferenceInformation node is described in further detail in
Section 8.3.27.
• SettlesAccrual [Optional]: Whether or not the accrued coupon is due in the event
of a default. This defaults to true if not provided.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46.
• ProtectionPaymentTime [Optional]: Controls the payment time of protection and
premium accrual payments in case of a default event. Defaults to atDefault.
Allowable values: atDefault, atPeriodEnd, atMaturity. Overrides the
PaysAtDefaultTime node

461
• PaysAtDefaultTime [Deprecated]: true is equivalent to ProtectionPaymentTime
= atDefault, false to ProtectionPaymentTime = atPeriodEnd. Overridden by
the ProtectionPaymentTime node if set
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46.
• ProtectionStart [Optional]: The first date where a credit event will trigger the
contract. This defaults to the first date in the schedule if it is not provided.
Must be set to a date before or on the first date in the schedule if the LegData
has a rule that is not one of CDS or CDS2015. In general, for standard CDS
traded after the CDS Big Bang in 2009, the protection start date is equal to the
trade date. Therefore, typically the ProtectionStart should be set to the trade
date of the CDS.
• UpfrontDate [Optional]: Settlement date for the UpfrontFee if an UpfrontFee is
provided. If an UpfrontFee is provided and it is non-zero, UpfrontDate is
required. The UpfrontDate, if provided, must be on or after the ProtectionStart
date. Typically, it is 3 business days after the CDS contract trade date.
• UpfrontFee [Optional]: The upfront payment, expressed as a percentage in
decimal form, to be multiplied by notional amount. If an UpfrontDate is
provided, an UpfrontFee must also be provided. The UpfrontFee can be omitted
but cannot be left blank. The UpfrontFee can be negative. The UpfrontFee is
treated as an amount payable by the protection buyer to the protection seller. A
negative value for the UpfrontFee indicates that the UpfrontFee is being paid by
the protection seller to the protection buyer.
Allowable values: Any real number, expressed in decimal form as a percentage of
the notional. E.g. an UpfrontFee of 0.045 and a notional of 10M, would imply an
upfront fee amount of 450K.
• FixedRecoveryRate [Optional]: This node holds the fixed recovery rate if the
CDS is a fixed recovery CDS. For a standard CDS, this field should be omitted.
• TradeDate [Optional]: The CDS trade date. If omitted, the trade date is
deduced from the protection start date. If the schedule provided in the LegData
has a rule that is either CDS or CDS2015, the trade date is set equal to the
protection start date. This is the standard for CDS traded after the CDS Big
Bang in 2009. Otherwise, the trade date is set equal to the protection start date
minus 1 day as it was standard before the CDS Big Bang to have protection
starting on the day after the trade date.
• CashSettlementDays [Optional]: The number of business days between the trade
date and the cash settlement date. For standard CDS, this is 3 business days. If
omitted, this defaults to 3.
• RebatesAccrual [Optional]: The protection seller pays the accrued scheduled
current coupon at the start of the contract. The rebate date is not provided but
computed to be two days after protection start. This defaults to true if not
provided.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set

462
 of allowable values is given in Table 46.
The LegData block then defines the CDS premium leg structure. This premium leg
must be be of type Fixed as described in Section 8.3.5.

Listing 368: CreditDefaultSwap Data

<CreditDefaultSwapData>
<IssuerId>CPTY_A</IssuerId>
<CreditCurveId>RED:008CA0|SNRFOR|USD|MR14</CreditCurveId>
<SettlesAccrual>Y</SettlesAccrual>
<ProtectionPaymentTime>atDefault</ProtectionPaymentTime>
<ProtectionStart>20160206</ProtectionStart>
<UpfrontDate>20160208</UpfrontDate>
<UpfrontFee>0.0</UpfrontFee>
<LegData>
<LegType>Fixed</LegType>
<Payer>false</Payer>
...
</LegData>
</CreditDefaultSwapData>

Listing 369: CreditDefaultSwapData with ReferenceInformation

<CreditDefaultSwapData>
<ReferenceInformation>
<ReferenceEntityId>RED:008CA0</ReferenceEntityId>
<Tier>SNRFOR</Tier>
<Currency>USD</Currency>
<DocClause>MR14</DocClause>
</ReferenceInformation>
<LegData>
...
</LegData>
</CreditDefaultSwapData>

A quanto credit default swap is a credit default swap with different denomination and
settlement currencies. Listing 370 shows an Example: The trade has a notional of 50
million BRL and pays a 6% premium. The premuim amounts are converted using the
FX-TR20H-USD-BRL fixing two days before they are settled in USD. The
hypothetical protection amounts computed for pricing purposes are converted to USD
in a similar fashion.

463
Listing 370: Quanto CDS CreditDefaultSwap Data

<LegData>
<LegType>Fixed</LegType>
<Payer>true</Payer>
<!-- This is the settlement currency -->
<Currency>USD</Currency>
<!-- This is the BRL notional -->
<Notionals>
<Notional>50000000</Notional>
</Notionals>
<!-- The FX index used to convert BRL amounts to the settlement ccy USD -->
<Indexings>
<Indexing>
<Index>FX-TR20H-USD-BRL</Index>
<FixingDays>2</FixingDays>
<FixingCalendar>USD,BRL</FixingCalendar>
<IsInArrears>true</IsInArrears>
</Indexing>
</Indexings>
...
<FixedLegData>
<Rates>
<Rate>0.06</Rate>
</Rates>
</FixedLegData>
...
</LegData>

8.2.52 Index Credit Default Swap

An index credit default swap (trade type IndexCreditDefaultSwap) is set up using an
IndexCreditDefaultSwapData block as shown in listing 371 and includes LegData and
BasketData trade component sub-nodes.
The LegData sub-node must be a fixed leg, and represents the recurring premium
payments. The direction of the fixed leg payments define if the Index CDS is for
bought (Payer: true) or sold (Payer: false) protection. The notional on the fixed leg is
the “unfactored notional”, i.e. the notional excluding any defaults. This is opposed to
the “trade date notional” which is reduced by defaults since the series inception until
the trade date and the “current notional” or “factored notional” which is reduced by
defaults between the series inception and the current evaluation date of the trade.
The BasketData sub-node (see section 8.3.28) is optional and specifies the constituent
reference entities of the index. This sub-node is intended for non-standard indices, that
require a bespoke basket. When BasketData is omitted, the index constituents are
derived from the CreditCurveId element in the IndexCreditDefaultSwapData block.

464
Listing 371: Index CreditDefaultSwap Data

<IndexCreditDefaultSwapData>
<CreditCurveId>RED:2I65BRHH6</CreditCurveId>
<SettlesAccrual>Y</SettlesAccrual>
<ProtectionPaymentTime>atDefault</ProtectionPaymentTime>
<ProtectionStart>20160206</ProtectionStart>
<UpfrontDate>20160208</UpfrontDate>
<UpfrontFee>0.0</UpfrontFee>
<LegData>
<LegType>Fixed</LegType>
<Payer>false</Payer>
...
</LegData>
<BasketData>
<Name>
<IssuerId>CPTY_1</IssuerId>
<CreditCurveId>RED:</CreditCurveId>
<Notional>100000.0</Notional>
<Currency>USD</Currency>
</Name>
<Name>
<IssuerId>CPTY_2</IssuerId>
<CreditCurveId>RED:</CreditCurveId>
<Notional>100000.0</Notional>
<Currency>USD</Currency>
</Name>
<Name>
<IssuerId>CPTY_3</IssuerId>
<CreditCurveId>RED:</CreditCurveId>
<Notional>100000.0</Notional>
<Currency>USD</Currency>
</Name>
<!-- ... -->
</BasketData>
</IndexCreditDefaultSwapData>

The meanings of the elements of the IndexCreditDefaultSwapData node follow below:

• CreditCurveId: The identifier of the index defining the default curve used for
pricing. The pricing can be set up to either use the index curve id, or use the
curve id:s of the individual index components defined in BasketData.
Allowable values: See CreditCurveId for credit trades - index in Table 40. Note
that the CreditCurveId cannot be a redcode or other identifier for an ABX or
CMBX. For these underlyings, trade type AssetBackedCreditDefaultSwap is used
instead.
• SettlesAccrual [Optional]: Whether or not the accrued coupon is due in the event
of a default. This defaults to true if not provided.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46.
• ProtectionPaymentTime [Optional]: Controls the payment time of protection and
premium accrual payments in case of a default event. Defaults to atDefault.

465
 Allowable values: atDefault, atPeriodEnd, atMaturity. Overrides the
PaysAtDefaultTime node
• PaysAtDefaultTime [Deprecated]: true is equivalent to ProtectionPaymentTime
= atDefault, false to ProtectionPaymentTime = atPeriodEnd. Overridden by
the ProtectionPaymentTime node if set
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46.
• ProtectionStart [Optional]: The first date where a credit event will trigger the
contract. This defaults to the first date in the schedule if it is not provided.
Must be set to a date before or on the first date in the schedule if the LegData
has a rule that is not one of CDS or CDS2015. In general, for standard index CDS,
the protection start date is equal to the trade date. Therefore, typically the
ProtectionStart should be set to the trade date of the index CDS.
Allowable values: See Date in Table 30.
• UpfrontDate [Optional]: Settlement date for the UpfrontFee if an UpfrontFee is
provided. If an UpfrontFee is provided and it is non-zero, UpfrontDate is
required.
Allowable values: See Date in Table 30. The UpfrontDate, if provided, must be
on or after the ProtectionStart date.
• UpfrontFee [Optional]: The upfront payment, expressed in decimal form as a
percentage of the notional. If an UpfrontDate is provided, an UpfrontFee must
also be provided. The UpfrontFee can be omitted but cannot be left blank. The
UpfrontFee can be negative. The UpfrontFee is treated as an amount payable by
the protection buyer to the protection seller. A negative value for the UpfrontFee
indicates that the UpfrontFee is being paid by the protection seller to the
protection buyer.
Allowable values: Any real number, expressed in decimal form as a percentage of
the notional. E.g. an UpfrontFee of 0.045 and a notional of 10M, would imply an
upfront fee amount of 450K.
• TradeDate [Optional]: The index CDS trade date. If omitted, the trade date is
deduced from the protection start date. If the schedule provided in the LegData
has a rule that is either CDS or CDS2015, the trade date is set equal to the
protection start date. Otherwise, the trade date is set equal to the protection
start date minus 1 day.
Allowable values: See Date in Table 30.
• CashSettlementDays [Optional]: The number of business days between the trade
date and the cash settlement date. For standard index CDS, this is generally 3
business days. If omitted, this defaults to 3.
Allowable values: Any non-negative integer.
• RebatesAccrual [Optional]: The protection seller pays the accrued scheduled
current coupon at the start of the contract. The rebate date is not provided but

466
 computed to be two days after protection start. This defaults to true if not
provided.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46.
The LegData block then defines the Index CDS premium leg structure. This premium
leg must be be of type Fixed as described in Section 8.3.5.

8.2.53 Index Credit Default Swap Option

An index CDS option, trade type IndexCreditDefaultSwapOption, is an option to
enter into an index CDS at a specified strike spread or strike price. The Index CDS
Option is set up using an IndexCreditDefaultSwapOptionData node as shown in
Listing 372. Its child nodes have the following meanings:
• IndexTerm [Optional]: An optional node giving the term of the underlying index
CDS e.g. 3Y, 5Y, 7Y, 10Y etc. The main function of this node is to allow for
different index CDS option volatility structures for different terms of the same
index series e.g. a CDX HY Series 34 5Y volatility structure and a CDX HY
Series 34 10Y volatility structure. If this node is omitted, the market is searched
for a CDS volatility surface with ID equal to the value of the CreditCurveId
node under IndexCreditDefaultSwapData. There will generally be one
CreditCurveId for each index CDS series e.g. CDXHYS34V1 for CDX HY Series
34 Version 1. Consequently, there can only be one CDS volatility surface for this
index CDS series. When IndexTerm is populated with the underlying index term,
the market is searched for a CDS volatility surface with ID equal to the value of
the CreditCurveId node with suffix -[IndexTerm]. For example, if the
CreditCurveId node on an index CDS option trade is CDXHYS34V1 and the
IndexTerm node is populated with 5Y, the market will be searched for a CDS
volatility surface with ID CDXHYS34V1-5Y and this will be used in the trade
valuation. In this way, different volatility surfaces can be used to value different
terms of the same CDS index series.
Allowable values: A string that can be parsed as a term that is a valid term for
the underlying CDS index e.g. 5Y, 10Y, etc.
• OptionData: A node defining the option details as described in Section 8.3.1.
The relevant fields in the OptionData node for an IndexCDSOption are:
– LongShort The allowable values are Long or Short. Long meaning that the
holder has the option to enter into the underlying index CDS.
– OptionType [Optional] Put/Call is optional and not used. The Payer field
in the underlying Index CDS leg determines if the option is to buy or sell
protection.
– Style Must be set to European as this is the only supported exercise for
IndexCreditDefaultSwapOption.
– Settlement The allowable values are Cash or Physical.
– PayOffAtExpiry Must be set to false as only payoff at exercise is supported.

467
 – An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer
(Long) to the option seller (Short). See section 8.3.2
• IndexCreditDefaultSwapData: A node defining the underlying index CDS as
described in Section 8.2.52. Note that the StartDate in the Scheduledata in the
premium leg in the IndexCreditDefaultSwapData should be the date on which
the underlying CDS is entered into if the option is exercised (as opposed to the
inception date of the underlying index CDS series). Under standard terms, the
StartDate would be equal to the ExerciseDate but it can also be on a date
after the ExerciseDate, but not on a date before the ExerciseDate, unless Rule
is CDS2015 or CDS and StartDate is set at the start of the full IMM period
that the ExerciseDate falls into.
The TradeDate and ProtectionStart on the underlying CDS do not need to be
populated. If omitted, which is recommended, the TradeDate and
ProtectionStart on the underlying CDS default as follows:
TradeDate = max (option ExerciseDate, underlying schedule StartDate)
ProtectionStart = max (option ExerciseDate, underl. schedule StartDate)
Note that the cash settlement date for the underlying swap upfront premium is
set to the underlying TradeDate with defaults as above, plus 3 business days.
Also note that for schedules with IMM rules (e.g. CDS2015 ), if the underlying
schedule StartDate is not falling on an IMM date, it is adjusted to the previous
quarterly IMM date.
Finally, the notional is - as in the case of an Index Credit Default Swap - the
“unfactored notional”, i.e. the notional excluding any defaults between the series
inception and the trade or evaluation date of the trade.
• Strike [Optional]: A real number defining the option strike level. If this is an
empty string or omitted the strike will be determined according to table 20.
Note that if a strike is given, the UpfrontFee on the underlying IndexCDS must
be zero or omitted. The UpfrontFee is interpreted as a price strike.
Allowable values: Any real number. Note that the Strike is expressed in
decimal form when StrikeType is Spread, and in decimal form as percentage of
notional when StrikeType is Price. I.e. a Strike of 1.05 is 105% of the notional
when StrikeType is Price.
• StrikeType [Optional]: Determines the strike type. If Spread is given, the
Strike is interpreted as a strike spread. If Price is given, the Strike is
interpreted as a strike price. If omitted or left blank, it will be determined
according to table 20.
Allowable values: Spread or Price. Note that Spread is only supported when the
underlying market data is set up with spread strikes, and Price is only supported
when the market data is set up with price strikes. Typically the market data
convention for Index CDS Options is spread strikes, with the exception of CDX

468
 North America High Yield (CDX NA HY) names, where the convention is to use
price strikes.
• TradeDate [Optional]: The trade date. If not given defaults to the valuation
date. In case of an underlying default the trade date is used to determine
whether the underlying notional before default should be considered part of the
outstanding notional (TradeDate < AuctionDate) or not (TradeDate ≥
AuctionDate).
Allowable values: See Date in Table 30. Can not be later than the valuation date.
• FrontEndProtectionStartDate [Optional]: The date on which the front end
protection kicks in. If not given, it defaults to the TradeDate. In case of an
underlying default this date is used to determine whether the underlying
contributes to the realised front end protection amount
(FrontEndProtectionStartDate < AuctionDate) or not
(FrontEndProtectionStartDate ≥ AcutionDate).
Allowable values: See Date in Table 30. Can not be later than the trade date.
• FixedRecoveryRate[Optional]: If provided, this recovery rate will be used in
palce of the market quoted recovery rate of the underlying.

Listing 372: Example Structure of IndexCreditDefaultSwapOptionData node.

<IndexCreditDefaultSwapOptionData>
<IndexTerm>5Y</IndexTerm>
<OptionData>
<LongShort>Long</LongShort>
<Style>European</Style>
<Settlement>Cash</Settlement>
<PayOffAtExpiry>false</PayOffAtExpiry>
<ExerciseDates>
<ExerciseDate>2023-05-09</ExerciseDate>
</ExerciseDates>
</OptionData>
<IndexCreditDefaultSwapData>
...
</IndexCreditDefaultSwapData>
<Strike>1.063</Strike>
<StrikeType>Price</StrikeType>
</IndexCreditDefaultSwapOptionData>

469
 Strike StrikeType UpfrontFee Effective Strike Effective StrikeType
na na na RunningCoupon Spread
na Spread na RunningCoupon Spread
na Price na 1.0 Price
K na na K Spread
K Spread na K Spread
K Price na K Price
na na U 1.0 - U Price
na Spread U (= 0) RunningCoupon Spread
na Spread U (̸= 0) (not allowed) (not allowed)
na Price U 1.0 - U Price
K na U (= 0) K Spread
K na U (̸= 0) (not allowed) (not allowed)
K Spread U (= 0) K Spread
K Spread U (̸= 0) (not allowed) (not allowed)
K Price U (= 0) K Price
K Price U (̸= 0) (not allowed) (not allowed)
Table 20: Effective strike and strike type to be used in an Index CDS Option dependent on the
Strike, StrikeType and UpfrontFee in the underlying Index CDS

8.2.54 Synthetic CDO

A Synthetic Collateralized Debt Obligation (CDO), uses trade type SyntheticCDO and
is set up using a CdoData block as shown in listing 373.
A synthetic CDO is a basket credit derivative, where the protection seller receives a
premium cash flow in exchange for providing (notional) protection against portfolio
losses due to defaults in a specific tranche characterized by the attachment point A
and detachment point D.
CDOs can refer to the constituents of an index such as CDX or iTraxx, or be bespoke,
i.e. refer to a bespoke basket of underlying credit names, using the BasketData
sub-node, (see section 8.3.28)

470
Listing 373: CDO Data

<CdoData>
<Qualifier>RED:2I65BRHH6</Qualifier>
<AttachmentPoint>0.12</AttachmentPoint>
<DetachmentPoint>0.22</DetachmentPoint>
<ProtectionStart> 20140425 </ProtectionStart>
<UpfrontDate/>
<UpfrontFee/>
<SettlesAccrual>Y</SettlesAccrual>
<ProtectionPaymentTime>atDefault</ProtectionPaymentTime>
<!-- Premium leg -->
<LegData>
<LegType>Fixed</LegType>
<Payer>true</Payer>
...
</LegData>
<BasketData>
...
</BasketData>
</CdoData>

The meanings of the elements of the CdoData node follow below:

• Qualifier: The identifier of the credit index defining the default and base
correlation curves used for pricing. In the case of a bespoke basket, i.e. when the
BasketData sub-node is used, the Qualifer should be set to the credit index most
closely matching the bespoke basket.
Allowable values: See CreditCurveId for credit trades - index in Table 40.
• AttachmentPoint: Losses where protection starts, expressed as a fraction of the
basket notional. Note that Attachment- and DetachmentPoints (AP, DP) are
defined as fractions of the current basket notional.
Allowable values: A number between 0 and 1, below the DetachmentPoint.
• DetachmentPoint: Losses where protection end, expressed as a fraction of the
basket notional
Note that Attachment- and DetachmentPoints (AP, DP) are defined as fractions
of the current basket notional.
Allowable values: A number between 0 and 1, above the AttachmentPoint.
• SettlesAccrual: Whether or not the accrued coupon is due in the event of a
default.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46.
• ProtectionPaymentTime [Optional]: Controls the payment time of protection and
premium accrual payments in case of a default event. Defaults to atDefault.
Allowable values: atDefault, atPeriodEnd, !atMaturity. Overrides the
PaysAtDefaultTime node

471
• PaysAtDefaultTime [Deprecated]: true is equivalent to ProtectionPaymentTime
= atDefault, false to ProtectionPaymentTime = atPeriodEnd. Overridden by
the ProtectionPaymentTime node if set
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46.
• ProtectionStart: The first date where a default event will trigger the contract
Allowable values: See Date in Table 30. Must be set to a date before or on the
first date in the premium leg schedule.
• UpfrontDate[Optional]: Settlement date for the UpfrontFee if an UpfrontFee is
provided. If an UpfrontFee is provided and it is non-zero, UpfrontDate is
required.
Allowable values: See Date in Table 30. The UpfrontDate, if provided, must be
on or after the ProtectionStart date.
• UpfrontFee[Optional]: The upfront payment, expressed as a rate, to be
multiplied by the tranche Notional amount. Note that a positive amount
indicates that the UpfrontFee is paid by the protection buyer to the protection
seller, and a negative amount indicates that the UpfrontFee is paid by the
protection seller to the protection buyer. The UpfrontFee cannot be left blank.
Allowable values: Any real number
• FixedRecoveryRate[Optional]: If provided, this recovery rate will be used in
palce of the market quoted recovery rates of the underlying basket or index
constituents, to work out the portfolio loss distribution and expected tranche loss.
Allowable values: Any real number in the range [0, 1]
• LegData: Premium leg description as in an Index CDS (see section 8.2.52) with
Notional corresponding to the initial tranche notional.
Note that the Payer field in LegData determines whereas protection is bought
(true) or sold (false).
The StartDate in LegData is the first accrual start date on the premium leg of
the index tranche. If the date generation Rule is CDS2015, one can enter the
index tranche trade date for StartDate and the correct accrual start date will be
deduced, i.e. the first accrual start date before the trade date using the CDS2015
date generation rules.
• BasketData[Optional]: Underlying basket description for bespoke baskets (see
section 8.3.28). This is analogous to a bespoke basket in an Index CDS (see
section 8.2.52). If omitted, CreditIndex static data, with id Qualifier element
in CdoData, is extracted from ReferenceData.
Note that the sum of notionals of the basket components must add up to the
complete basket notional.
Sumof ComponentN otionals = CompleteBasketN otional =
InitialT rancheN otional/(DetachmentP oint − AttachmentP oint)
If weights are used instead of notionals in the basket components, the sum of the
weights must add up to 1.

472
8.2.55 Credit Linked Swap
A credit linked swap, trade type CreditLinkedSwap, is set up using a
CreditLinkedSwapData block as shown in listing 374. The elements have the following
meaning:
• CreditCurveId: The referenced CDS credit curve.
Allowable values: See CreditCurveId for credit trades - single name in Table 40.
A ReferenceInformation node may be used in place of this CreditCurveId
node.
• SettlesAccrual [Optional]: A flag indicating whether accrued coupon amounts are
paid in case of a credit event. Optional, defaults to true. Applies to the
payments specified under ContingentPayments.
Allowable values: true, false
• FixedRecoveryRate [Optional]: A fixed (digital) recovery rate to apply. If not
given, the market recovery rate is used. Applies to the payments specified under
DefaultPayments and RecoveryPayments.
Allowable values: Any non-negative real number.
• DefaultPaymentTime [Optional]: Controls the timing of the payments specified
under DefaultPayments and RecoveryPayments. Defaults to atDefault.
Allowable values: atDefault, atPeriodEnd, atMaturity.
• IndependentPayments [Optional]: The legs for which payments are made
independent from credit events. The node contains one or more LegData
subnodes representing these legs. Optional, can be omitted if no such payments
are made.
Allowable values: See 8.3.3 for the LegData subnode structure.
• ContingentPayments [Optional]: The legs for which payments are contingent on
no credit event having occured until the payment date. If no such payments are
made, the node can be omitted.
Allowable values: See 8.3.3 for the LegData subnode structure.
• DefaultPayments [Optional]: The legs for which payments are contingent on a
credit event having occured. If no such payments are made, the node can be
omitted. If a default happens at a date d, the associated payment is the earliest
payment with date greater or equal to d.
Allowable values: See 8.3.3 for the LegData subnode structure.
• RecoveryPayments [Optiopnal]: The legs for which payments are contingent on a
credit event having occured. The node works analogously to the
DefaultPayments node, the only difference is that that payment amounts are
weighted by RR instead of 1 − RR.
Allowable values: See 8.3.3 for the LegData subnode structure.
All legs must be given in the same currency.

473
Listing 374: Credit Linked Swap Data

<CreditLinkedSwapData>
<CreditCurveId>RED:46A844|SNRFOR|USD|XR14</CreditCurveId>
<SettlesAccrual>false</SettlesAccrual>
<FixedRecoveryRate>0.4</FixedRecoveryRate>
<DefaultPaymentTime>atDefault</DefaultPaymentTime>
<IndependentPayments>
<LegData> ... </LegData>
<LegData> ... </LegData>
...
</IndependentPayments>
<ContingentPayments>
<LegData> ... </LegData>
<LegData> ... </LegData>
...
</ContingentPayments>
<DefaultPayments>
<LegData> ... </LegData>
<LegData> ... </LegData>
...
</DefaultPayments>
<RecoveryPayments>
<LegData> ... </LegData>
<LegData> ... </LegData>
...
</RecoveryPayments>
</CreditLinkedSwapData>

8.2.56 Commodity Forward

The CommodityForwardData node is the trade data container for the
CommodityForward trade type. The structure of an example CommodityForwardData
node is shown in Listings 375 and 376.

Listing 375: Commodity Forward data

<CommodityForwardData>
<Position>Long</Position>
<Maturity>2018-06-30</Maturity>
<Name>PM:XAUUSD</Name>
<Currency>USD</Currency>
<Strike>1355</Strike>
<Quantity>1000</Quantity>
<IsFuturePrice>...</IsFuturePrice>
<FutureExpiryDate>...</FutureExpiryDate>
<FutureExpiryOffset>...</FutureExpiryOffset>
<FutureExpiryOffsetCalendar>...</FutureExpiryOffsetCalendar>
<PhysicallySettled>...</PhysicallySettled>
<PaymentDate>...</PaymentDate>
</CommodityForwardData>

474
Listing 376: CommodityForwardData for forward on LME Aluminium 3M future.

<CommodityForwardData>
<Position>Long</Position>
<Maturity>2021-08-16</Maturity>
<Name>XLME:AH</Name>
<Currency>USD</Currency>
<Strike>2160</Strike>
<Quantity>1000</Quantity>
<IsFuturePrice>true</IsFuturePrice>
<FutureExpiryDate>2021-11-16</FutureExpiryDate>
<PhysicallySettled>true</PhysicallySettled>
</CommodityForwardData>

The meanings and allowable values of the elements in the CommodityForwardData

node follow below.
• Position: Defines whether the underlying commodity will be bought (long) or
sold (short).
Allowable values: Long, Short
• Maturity: The maturity date of the forward contract, i.e. the date when the
underlying commodity will be bought/sold.
Allowable values: Any date string, see Date in Table 30.
• Name: The name of the underlying commodity.
Allowable values: See Name for commodity trades in Table 42.
• Currency: The currency of the commodity forward.
Allowable values: See Currency in Table 30.
• Strike: The agreed buy/sell price of the commodity forward.
Allowable values: Any positive real number.
• Quantity: The number of units of the underlying commodity to be bought/sold.
Allowable values: Any positive real number.
• IsFuturePrice [Optional]: This should be set to true if the forward contract
underlying is the settlement price of a commodity future contract. If omitted, it
defaults to false.
Allowable values: Any string that evaluates to true or false as outlined in Table
46.
• FutureExpiryDate [Optional]: If IsFuturePrice is set to true, this gives the
expiration date of the underlying commodity future contract. If omitted, the
expiration date of the underlying commodity future contract is set equal to the
value in the Maturity node. If FutureExpiryDate is provided, it takes
precedence over any value provided in the Maturity, FutureExpiryOffset or
FutureExpiryOffsetCalendar fields.
Allowable values: Any date string, see Date in Table 30.
• FutureExpiryOffset [Optional]: If IsFuturePrice is set to true and
FutureExpiryDate is not explicitly specified, this gives the offset period that
should be applied to the Maturity date to generate the underlying commodity

475
 future contract expiration date. If omitted, the expiration date of the underlying
commodity future contract is set equal to the value in the Maturity node.
Allowable values: Any string that can be parsed as a period e.g. 2D, 3M, etc.
• FutureExpiryOffsetCalendar [Optional]: If FutureExpiryOffset is provided
and is being used, this gives the calendar that should be used when generating
the underlying commodity future contract expiration date from the Maturity
date. If omitted, all days are considered good business days when generating the
commodity future contract expiration date which is generally not what is desired.
Allowable values: Any calendar string, see Calendar in Table 34.
• PhysicallySettled [Optional]: A value of true indicates that the forward
contract is physically settled e.g. if the underlying is a future contract, that
future contract is entered into on the Maturity date. A value of false indicates
that the forward contract is cash settled e.g. if the underlying is a future
contract, that future contract settlement price is observed on the Maturity date
(or the FutureExpiryDate, when given) and the net amount due is exchanged on
the cash settlement date. If omitted, it defaults to true.
Allowable values: Any string that evaluates to true or false as outlined in Table
46.
• PaymentDate [Optional]: If PhysicallySettled is set to false, this gives the
cash settlement date. It must be greater than or equal to the Maturity date. If
omitted and the forward is cash settled, the Maturity date is used.
Allowable values: Any date string, see Date in Table 30.
• SettlementData [Optional]: This node is used to specify the settlement of the
cash flows for non-deliverable futures.
A SettlementData node is shown in Listing 377, and the meanings and allowable
values of its elements follow below.
• PayCurrency: The settlement currency for the payment cashflow.
Allowable values: See Currency in Table 30.
• FXIndex: The FX reference index for determining the FX fixing at the value
date. This field is required if settlement is Cash and the payment date is greater
than the value date.
Allowable values: The format of the FXIndex is “FX-FixingSource-CCY1-CCY2”
as described in Table 38.
• FixingDate: The date on which the FXIndex is observed. Allowable values: See
Date in Table 30.

Listing 377: Example SettlementData node with Rules sub-node

<SettlementData>
<PayCurrency>EUR</PayCurrency>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
<FixingDate>2021-05-28</FixingDate>
</SettlementData>

Note that a Precious Metal Forward should be represented as an FX Forward using the

476
appropriate commodity “currency” (XAU, XAG, XPT, XPD).

8.2.57 Commodity Swap and Basis Swap

The structure of a CommoditySwap trade node is shown in listing 378. This trade node
can be used to represent commodity swaps and commodity basis swaps. It consists of
the generic Envelope and the specific SwapData section.
The SwapData node may contain two or more LegData nodes. There must be at least
one LegData node of a commodity LegType, i.e. CommodityFixed or
CommodityFloating, but non-commodity leg types are also allowed. The commodity
leg types are described in sections 8.3.20 and 8.3.22 respectively.

Listing 378: Commodity Swap

<Trade id="...">
<TradeType>CommoditySwap</TradeType>
<Envelope>
</Envelope>
<SwapData>
<LegData>
<LegType>CommodityFixed</LegType>
...
</LegData>
<LegData>
<LegType>CommodityFloating</LegType>
...
</LegData>
</SwapData>
</Trade>

8.2.58 Commodity Swaption

The structure of a trade node representing a commodity swaption is shown in listing
379. It consists of the generic Envelope and the specific CommoditySwaptionData
node.
The CommoditySwaptionData node contains an OptionData node described in 8.3.1.
The relevant fields in the OptionData node for a CommoditySwaption are:
• LongShort: The allowable values are Long or Short. Note that the payer and
receiver legs in the underlying swap are always from the perspective of the party
that is Long. E.g. for a Short CommoditySwaption with a fixed leg where the
Payer flag is set to false, it means that the counterparty receives the fixed flows.
• OptionType[Optional]: This flag is optional for CommoditySwaptions, and even
if set, has no impact. The direction of flows is determined entirely by the Payer
flags on the underlying legs (and the LongShort flag above).
• Style: The exercise style of the CommoditySwaption. Only exercise style
European is supported.
• NoticePeriod[Optional]: The notice period defining the date (relative to the
exercise date) on which the exercise decision has to be taken. If not given the

477
 notice period defaults to 0D, i.e. the notice date is identical to the exercise date.
Allowable values: A number followed by D, W, M, or Y
• NoticeCalendar[Optional]: The calendar used to compute the notice date from
the exercise date. If not given defaults to the NullCalendar (no holidays,
weekends are no holidays either). Allowable values: See Table 34 Calendar.
• NoticeConvention[Optional]: The roll convention used to compute the notice
date from the exercise date. Defaults to Unadjusted if not given. Allowable
values: See Table 31 Roll Convention.
• Settlement: Delivery Type. The allowable values are Cash or Physical.
• ExerciseFees[Optional]: This node contains child elements of type
ExerciseFee. Similar to a list of notionals (see 8.3.3) the fees can be given either
– as a list where each entry corresponds to an exercise date and the last entry
is used for all remaining exercise dates if there are more exercise dates than
exercise fee entries, or
– using the startDate attribute to specify a change in a fee from a certain
day on (w.r.t. the exercise date schedule)
Fees can either be given as an absolute amount or relative to the current notional
of the period immediately following the exercise date using the type attribute
together with specifiers Absolute resp. Percentage. If not given, the type
defaults to Absolute. Percentage fees are expressed in decimal form, e.g. 0.05 is
a fee of 5% of notional.
If a fee is given as a positive number the option holder has to pay a
corresponding amount if they exercise the option. If the fee is negative on the
other hand, the option holder receives an amount on the option exercise.
• ExerciseFeeSettlementPeriod[Optional]: The settlement lag for exercise fee
payments. Defaults to 0D if not given. This lag is relative to the exercise date
(as opposed to the notice date). Allowable values: A number followed by D, W,
M, or Y
• ExerciseFeeSettlementCalendar[Optional]: The calendar used to compute the
exercise fee settlement date from the exercise date. If not given defaults to the
NullCalendar (no holidays, weekends are no holidays either). Allowable values:
See Table 34 Calendar.
• ExerciseFeeSettlementConvention[Optional]: The roll convention used to
compute the exercise fee settlement date from the exercise date. Defaults to
Unadjusted if not given. Allowable values: See Table 31 Roll Convention.
• An ExerciseDates node where exactly one ExerciseDate date element must be
given for European style CommoditySwaptions. Allowable values: The
ExerciseDate must be on or before the StartDate of the underlying legs, and be
on or after the valuation date. For the format, see Date in Table 30.
• Premiums [Optional]: Option premium node with amounts paid by the option
buyer to the option seller.

478
 Allowable values: See section 8.3.2
The CommoditySwaptionData node should contain exactly two LegData nodes. One
LegData node should be of type CommodityFixed described in section 8.3.20 and one
should be of type CommodityFloating described in section 8.3.22. Note that on the
CommodityFloating leg, the Spread must be omitted or set to 0, and the Gearing
must be omitted or set to 1.
Listing 379: Commodity swaption

<Trade id="...">
<TradeType>CommoditySwaption</TradeType>
<Envelope>
...
</Envelope>
<CommoditySwaptionData>
<OptionData>
<LongShort>Long</LongShort>
<Style>European</Style>
<Settlement>Cash</Settlement>
<ExerciseDates>
<ExerciseDate>2023-01-05</ExerciseDate>
</ExerciseDates>
</OptionData>
<LegData>
<LegType>CommodityFixed</LegType>
...
</LegData>
<LegData>
<LegType>CommodityFloating</LegType>
...
</LegData>
</CommoditySwaptionData>
</Trade>

8.2.59 Commodity Option

The CommodityOptionData node is the trade data container for the CommodityOption
trade type. Vanilla commodity options are supported. The exercise style may be
European or American. The CommodityOptionData node includes exactly one
OptionData trade component sub-node plus elements specific to the commodity
option. The structure of a CommodityOptionData node for a commodity option is
shown in Listing 380.

479
Listing 380: Commodity Option data

<CommodityOptionData>
<OptionData>
<LongShort>Short</LongShort>
<OptionType>Put</OptionType>
<Style>European</Style>
<Settlement>Cash</Settlement>
<PayOffAtExpiry>false</PayOffAtExpiry>
<ExerciseDates>
<ExerciseDate>2029-04-28</ExerciseDate>
</ExerciseDates>
</OptionData>
<Name>NYMEX:CL</Name>
<Currency>USD</Currency>
<StrikeData>
<StrikePrice>
<Value>100</Value>
<Currency>USD</Currency>
</StrikePrice>
</StrikeData>
<Quantity>500000</Quantity>
<IsFuturePrice>true<IsFuturePrice>
<FutureExpiryDate>2029-04-28<FutureExpiryDate>
</CommodityOptionData>

The meanings and allowable values of the elements in the CommodityOptionData node
follow below.
• The CommodityOptionData node contains an OptionData node described in
8.3.1. The relevant fields in the OptionData node for a CommodityOption are:
– LongShort: The allowable values are Long or Short.
– OptionType: The allowable values are Call or Put.
– Style: The exercise style of the CommodityOption. The allowable values
are European or American.
– PayOffAtExpiry: This must be set to false as payoff at expiry is not
currently supported.
– An ExerciseDates node where exactly one ExerciseDate date element
must be given for. Allowable values: See Date in Table 30.
– Premiums [Optional]: Option premium node with amounts paid by the
option buyer to the option seller. Allowable values: See section 8.3.2
• Name: The name of the underlying commodity.
Allowable values: See Name for commodity trades in Table 42.
• Currency: The currency of the commodity option.
Allowable values: See Currency in Table 30.
• StrikeData: The option strike price. It uses the price quotation outlined in the
underlying contract specs for the commodity name in question.
Allowable values: Only supports StrikePrice as described in Section 8.3.30.

480
 • Quantity: The number of units of the underlying commodity covered by the
transaction. The unit type is defined in the underlying contract specs for the
commodity name in question. For avoidance of doubt, the Quantity is the
number of units of the underlying commodity, not the number of contracts.
Allowable values: Any positive real number.
• IsFuturePrice [Optional]: A boolean indicating if the underlying is a future
contract settlement price, true, or a spot price, false.
Allowable values: A boolean value given in Table 46. If not provided, the default
value is true.
• FutureExpiryDate [Optional]: If IsFuturePrice is true and the underlying is a
future contract settlement price, this node allows the user to specify the expiry
date of the underlying future contract.
Allowable values: This should be a valid date as outlined in Table 30. If not
provided, it is assumed that the future contract’s expiry date is equal to the
option expiry date provided in the OptionData node.

8.2.60 Commodity Digital Option

A commodity digital option is represented with trade type CommodityDigitalOption
and a corresponding CommodityDigitalOptionData node. The latter differs from the
CommodityOptionData node in section 8.2.59 by replacing tag Quantity with tag
Payoff which is the cash amount paid in the Currency of the option from the party
that is short to the party that is long, when the underlying price exceeds the strike at
expiry in case of a Call (or falls below the strike in case of a Put). The digital option is
priced in ORE as a spread of vanilla Commodity options at two slightly different
strikes. For option type Call and Put, respectively, the digital call/put is constructed
as
Payoff
Digital Call = × (Call(K − ∆/2) − Call(K + ∆/2))
∆
Payoff
Digital Put = × (Put(K + ∆/2) − Put(K − ∆/2))
∆
so that the long digital option has positive value in both cases. The strike spread ∆
used here is set to 1% of strike K.

8.2.61 Commodity Spread Option

A commodity Spread Option is represented with trade type CommoditySpreadOption
and a corresponding CommoditySpreadOptionData node.
The CommoditySpreadOptionData node is the trade data container for the
CommoditySpreadOption trade type. The structure of a CommoditySpreadOptionData
node for a commodity option is shown in Listing 381.
The CommoditySpreadOptionData include exactly two LegData nodes of type
CommodityFloating. Details on these are described in 8.3.22. The resulting Legs must
produce the same amount of cashflows (i.e. the number of calculation period s must be
the same for the long and short positions). If the number of cashflows per leg is 1, this

481
trade represents a vanilla commodity spread option. If is greater than 1, it represents a
multi-period commodity spread option. Exactly one payer and one receiver leg are
required, the leg with isPayer setto true is the long (positive) position in the spread
payoff.
Within the two LegData, the Quantity node has must be equal. If the underlying
contracts are quoted using different units (e.g. barrels vs liters), the Gearing node
must be used to account for this difference. The gearing could also be used for the heat
rate factor in spark / heat rate options.
Other than the two legs, the following nodes complete the
CommoditySpreadOptionData container:
• SpreadStrike: The strike value for the spread. Allowable values: Any real
number.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an CommoditySpreadOption are
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put.
– A PaymentData [Optional] node can be added which defines the settlement
date of the option payoff.
– Premiums [Optional]: Option premium amounts paid by the option buyer to
the option seller. See section 8.3.2
• OptionStripPaymentDates [Optional]: If the number of cashflows per leg is
greater than 1, we can group options by their expiry date into strips. All option
in a strip will have the same payment date as defined in this node. The payment
date will be lag business days after the latest expiry date in the strip. The node
has following sub-nodes:
– OptionStripDefinition A schedule node 8.3.4 defining the option strips.
The n dates in the schedule defining n − 1 strips, each strip include the
period’s start date and excludes period’s end date. All options with expiry
within start and end of a period are falling in the same strip. The schedule
has to cover all option expiries. The first date in the schedule has to be
before or on the first expiry date of the options and the last date in the
schedule has to be after last expiry date of the options.
– PaymentCalendar Calendar defining valid business days for the payment
date.
– PaymentLag number of business days.
– PaymentConvention business day convention for the option strip payment
date.

482
Listing 381: Commodity Spread Option data

<CommoditySpreadOptionData>
<LegData>
<LegType>CommodityFloating</LegType>
<IsPayer>true<IsPayer>
...
</LegData>
<LegData>
<LegType>CommodityFloating</LegType>
<IsPayer>false<IsPayer>
...
</LegData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Premiums>
<Premium>
<Amount>10900</Amount>
<Currency>EUR</Currency>
<PayDate>2020-03-01</PayDate>
</Premium>
</Premiums>
</OptionData>
<SpreadStrike>2.3</SpreadStrike>
<OptionStripPaymentDates>
<OptionStripDefinition>
<Rules>
<StartDate>2023-07-01</StartDate>
<EndDate>2023-10-01</EndDate>
<Tenor>1M</Tenor>
<Calendar>NullCalendar</Calendar>
<Convention>Unadjusted</Convention>
<TermConvention>Unadjusted</TermConvention>
<Rule>Backward</Rule>
</Rules>
</OptionStripDefinition>
<PaymentCalendar>ICE_FuturesUS,US-NERC</PaymentCalendar>
<PaymentLag>5</PaymentLag>
<PaymentConvention>MF</PaymentConvention>
</OptionStripPaymentDates>
</CommoditySpreadOptionData>

8.2.62 Commodity Average Price Option

The structure of a trade node representing a commodity average price option (APO) is
shown in listing 382. It consists of the generic Envelope and the specific
CommodityAveragePriceOptionData node. A strip of these options may be booked
using the commodity option strip trade outlined in section 8.2.63. The meanings and
allowable values of the elements in the CommodityAveragePriceOptionData are as
follows:
• OptionData: This node is described in section 8.3.1. The relevant fields in the
OptionData node for a CommodityAveragePriceOption are:
– LongShort: The allowable values are Long or Short.

483
 – OptionType: The allowable values are Call or Put, where Call is an option
for the party that is Long to buy the underlying commodity, and Put is an
option to sell the underlying commodity.
– Style: only European exercise style is supported.
– the ExerciseDates node should contain exactly one ExerciseDate, and the
single ExerciseDate should be on or before the payment date. Also, the
single ExerciseDate should be on or after the final date in the calculation
period i.e. the EndDate below.
– Premiums [Optional]: Option premium node with amounts paid by the
option buyer to the option seller. Allowable values: See section 8.3.2
• BarrierData [optional]: If given this node specifies the barrier terms of the
option:
– Type: One of UpAndIn, DownAndIn, UpAndOut, DownAndOut
– Style: One of European, American. A European barrier is observed on the
last relevant pricing date of the APO while an American barrier is observed
on all pricing dates of the APO.
– LevelData: The barrier level. Only single-barrier options are allowed, i.e.
exactly one level must be given.
• Name: An identifier specifying the commodity being referenced. This is described
in section 8.3.24.
Allowable values: See Name for commodity trades in Table 42.
• Currency: The currency of the payoff which must be consistent with either
currency of the market data set up for the commodity or the other currency
specified in FXIndex (see below).
Allowable values: See Currency in Table 30.
• Quantity: The number of units of the underlying commodity covered by the
APO. The unit type is defined in the underlying contract specs for the
commodity name in question. For avoidance of doubt, the Quantity is the
number of units of the underlying commodity, not the number of contracts.
The meaning of the Quantity is influenced by the CommodityQuantityFrequency
value as described in section 8.3.24. If CommodityQuantityFrequency is set to
PerCalculationPeriod, this quantity is used directly in the APO payoff. If
CommodityQuantityFrequency is set to PerCalendarDay, this quantity is
multiplied by the number of calendar days in the APO period to give the final
quantity that is used in the APO payoff.
Allowable values: Any positive real number.
• StrikeData: A StrikeData node is used as described in Section 8.3.30 to
represent the APO strike price and Currency of the [Link] APO strike price.
The strike uses the price quotation outlined in the underlying contract specs for
the commodity name in question. Note that for CommodityAPOs only
StrikePrice is supported within the StrikeData node, and not StrikeYield.

484
 Allowable values: Only supports StrikePrice as described in Section 8.3.30.
• PriceType: The price type is Spot if the APO is referencing a commodity spot
price, and it is FutureSettlement if the APO is referencing a commodity future
contract settlement price.
Allowable values: Spot or FutureSettlement.
• StartDate: The start date of the APO’s calculation period.
Allowable values: See Date in Table 30.
• EndDate: The end date of the APO’s calculation period.
Allowable values: See Date in Table 30.
• PaymentCalendar: The business calendar used to determine the valid payment
date.
Allowable values: See Table 34 Calendar.
• PaymentLag: The payment date is this number of business days after a given
base date. The base date is determined by the value of the
CommodityPayRelativeTo node below which is generally omitted for APOs and
allowed to take its default value of CalculationPeriodEndDate.
Allowable values: Any valid period, i.e. a non-negative whole number, optionally
followed by D (days), W (weeks), M (months), Y (years). Defaults to 0D if left
blank or omitted. If a whole number is given and no letter, it is assumed that it
is a number of D (days).
• PaymentConvention: The roll convention used to adjust the payment date.
Allowable values: See Table 31 Roll Convention. Defaults to Unadjusted if left
blank or omitted.
• PricingCalendar: The business calendar used for determining the Pricing Dates
in the calculation period.
Allowable values: See Table 34 Calendar. Defaults to NullCalendar (no
holidays) if left blank or omitted.
• PaymentDate [Optional]: An explicit payment date for the APO if the
combination of PaymentCalendar, PaymentLag and PaymentConvention is not
sufficient. If PaymentDate is provided, it overrides the values provided in
PaymentCalendar, PaymentLag and PaymentConvention.
• Gearing [Optional]: An optional gearing factor that the average price is
multiplied by in the APO payoff. The default value is 1.0.
• Spread [Optional]: An optional spread that is added to the average price in the
APO payoff. The default value is 0.0.
• CommodityQuantityFrequency [Optional]: This is as described in section 8.3.24.
• CommodityPayRelativeTo [Optional]: This is as described in section 8.3.24.

485
 • FutureMonthOffset [Optional]: This is as described in section 8.3.24. Note that
IsAveraged defaults to false as it cannot be used as a tag within the
CommodityAveragePriceOptionData node. Thus, if e.g. FutureMonthOffset is
set to 2, the future contract month and year is taken as the second month
following the base date’s month and year; and so on for all positive values of
FutureMonthOffset.
• DeliveryRollDays [Optional]: This is as described in section 8.3.24.
• IncludePeriodEnd [Optional]: This is as described in section 8.3.24.
• FXIndex [Optional]: This is an FX index used to apply currency conversion daily
in the average. The currencies pair must include the currency used in the
underlying commodity trade and the currency used for settlement.
Allowable values: See Table 38 for supported fx indices.

8.2.63 Commodity Option Strip

The structure of a trade node representing a commodity option strip is shown in listing
383. This node can be used to represent a strip of commodity average price options as
described in section 8.2.62 or a strip of European commodity options as described in
section 8.2.59. It consists of the generic Envelope and the specific
CommodityOptionStripData node.
The CommodityOptionStripData node has a LegData node with LegType set to
CommodityFloating. This LegData node is described in detail in sections 8.3.22 and
8.3.24. Note that the Payer field in CommodityFloatingLegData, while mandatory, has
no impact on flows. The node IsAveraged in CommodityFloatingLegData determines
whether a strip of European commodity options or a strip of APOs are created:
• If IsAveraged is false, a strip of European commodity options is created.
There is a European put and or European call option created for each calculation
period. The exercise date of the option in the calculation period is given by the
Pricing Date in the calculation period using the rules outlined in section 8.3.24.
The quantity is given by the quantity in the calculation period using the rules
outlined in section 8.3.24. If cash settled, the cash settlement date is given by the
payment date for the calculation period using the rules outlined in section 8.3.24.
• If IsAveraged is true, a strip of commodity average price options is created.
There is a put and or call option created for each calculation period. The
exercise date of the option in the calculation period is given by the calculation
period end date. The quantity is given by the quantity in the calculation period
using the rules outlined in section 8.3.24.
Each calculation period may contain a put and a call that may be either bought or
sold. The type of option, whether they are bought or sold and the strike price is
determined by the Calls and Puts nodes. We describe here the settings for the Calls
node with the understanding that analogous descriptions apply to the Puts node. If
the Calls node is omitted, it is assumed that there are no call options in the strip.
The LongShorts node may contain one LongShort node or the same number of
LongShort nodes as calculation periods. Each LongShort node has the allowable

486
Listing 382: Commodity average price option

<Trade id="...">
<TradeType>CommodityAveragePriceOption</TradeType>
<Envelope>
...
</Envelope>
<CommodityAveragePriceOptionData>
<OptionData>
<LongShort>Short</LongShort>
<OptionType>Call</OptionType>
<Style>European</Style>
<ExerciseDates>
<ExerciseDate>2020-01-31</ExerciseDate>
</ExerciseDates>
</OptionData>
<BarrierData>
<Type>UpAndIn</Type>
<Style>American</Style>
<LevelData>
<Level>
<Value>80</Value>
</Level>
</LevelData>
</BarrierData>
<Name>NYMEX:CL</Name>
<Currency>USD</Currency>
<Quantity>6000</Quantity>
<StrikeData>
<StrikePrice>
<Value>80</Value>
<Currency>USD</Currency>
</StrikePrice>
</StrikeData>
<PriceType>FutureSettlement</PriceType>
<StartDate>2022-01-01</StartDate>
<EndDate>2023-01-31</EndDate>
<PaymentCalendar>USD</PaymentCalendar>
<PaymentLag>5</PaymentLag>
<PaymentConvention>Following</PaymentConvention>
<PricingCalendar>USD</PricingCalendar>
<Gearing>1</Gearing>
<Spread>0.0</Spread>
<CommodityQuantityFrequency>PerCalculationPeriod</CommodityQuantityFrequency>
<CommodityPayRelativeTo>CalculationPeriodEndDate</CommodityPayRelativeTo>
<FutureMonthOffset>0</FutureMonthOffset>
<DeliveryRollDays>0</DeliveryRollDays>
<IncludePeriodEnd>true</IncludePeriodEnd>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
</CommodityAveragePriceOptionData>
</Trade>

values Long or Short. If LongShort is Long, then the call option is bought and if
LongShort is Short then the call option is sold. If a single LongShort node is
provided, it is applied to all options in the strip. If the same number of LongShort
nodes as calculation periods are provided, a LongShort node is applied to the option in

487
the corresponding period. The optional BarrierData node specifies the barrier terms
of the options. See section 8.2.62 for details on this. Call and put options can have
different barrier terms, but all call (resp. put) options share the same terms. In listing
383 only the call options have a barrier feature.
Similar to the LongShorts node, the Strikes node may contain one Strike node or
the same number of Strike nodes as calculation periods. If only one is provided, this
strike applies to all options in the strip. If the same number of Strike nodes as
calculation periods are provided, a Strike node is applied to the option in the
corresponding period. In this way, we support varying strikes across options in the
strip. At least one of Calls or Puts needs to be provided for a valid option strip to be
created.
The Premiums node allows for the addition of premiums. If the PremiumAmount is
negative, it is paid and if it is positive, it is received. See 8.3.2.
The optional Style node can be set to European or American to change the exercise
style for the strip of options. If not set, European is assumed. If the strip is a strip of
APOs, European is assumed and a warning is issued if Style is not European.
The optional Settlement node can be set to Cash or Physical to change the
settlement method for the strip of options. If not set, Cash is assumed. If the strip is a
strip of APOs, Cash is assumed and a warning is issued if Settlement is not Cash.
The optional IsDigital node allows the creation of a strip of
CommodityDigitalOptions (see 8.2.60). If set to true the node PayoffPerUnit needs
to be set.
Node PayoffPerUnit [Optional] specifies the payoff per commodity unit, expressed in
leg currency, in case a digital option is exercised. If the trade is a strip of digital
options, this node must be set. It accepts real numbers as input.

8.2.64 Commodity Variance and Volatility Swap

The CommodityVarianceSwapData node is the trade data container for the
CommodityVarianceSwap trade type. The structure of an example
CommodityVarianceSwapData node for a Commodity Variance Swap is the same as for
an Equity Variance Swap in section 8.2.33, with the exception of the underlying node
which is of type ’Commodity’ here. See section 8.3.29 for additional optional elements
of the underlying node and allowable values.

8.2.65 Commodity Position

An commodity position represents a position in a single commodity - using a single
Underlying node, or in a weighted basket of underlying commodities - using multiple
Underlying nodes.
An commodity Position can be used both as a stand alone trade type (TradeType:
CommodityPosition) or as a trade component (CommodityPositionData) used within
the TotalReturnSwap (Generic TRS) trade type, to set up for example Commodity
Basket trades.

488
Listing 383: Commodity option strip

<Trade id="...">
<TradeType>CommodityOptionStrip</TradeType>
<Envelope>
...
</Envelope>
<CommodityOptionStripData>
<LegData>
<LegType>CommodityFloating</LegType>
...
</LegData>
<Calls>
<LongShorts>
<LongShort>Short</LongShort>
</LongShorts>
<Strikes>
<Strike>5.3</Strike>
</Strikes>
<BarrierData>
<Type>UpAndIn</Type>
<Style>American</Style>
<LevelData>
<Level>
<Value>70.0</Value>
</Level>
</LevelData>
</BarrierData>
</Calls>
<Puts>
<LongShorts>
<LongShort>Long</LongShort>
</LongShorts>
<Strikes>
<Strike>8.17</Strike>
</Strikes>
</Puts>
<Premiums> ... </Premiums>
<Style>European</Style>
<Settlement>Cash</Settlement>
</CommodityOptionStripData>
</Trade>

If the PriceType is set to FutureSettlement it will refer by default to today’s prompt

(lead) future. At the moment a generic TRS doesn’t support rolling of the future
contracts. Today’s prompt future could be different from the prompt future at
inception. If the initial price for the basket is not set, it will use the price of today’s
prompt future at trade inception as initial price and the TRS will also ignore the roll
yield caused by rolling from one prompt future to the next contract.
It is set up using an CommodityPositionData block as shown in listing 384. The
meanings and allowable values of the elements in the block are as follows:
• Quantity: The number of shares or units of the weighted basket held.
Allowable values: Any positive real number

489
 • Underlying: One or more underlying descriptions. If a basket of commodities is
defined, the Weight field should be populated for each underlyings. The weighted
basket price is then given by
X
Basket-Price = Quantity × Weighti × Si × FXi
i

where
– Si is the i-th commodity prompt future or spot price in the basket
– F Xi is the FX Spot converting from the ith commodity currency to the first
commodity currency which is by definition the currency in which the npv of
the basket is expressed.
Allowable values: See 8.3.29 for the definition of an underlying. Only commodity
underlyings are allowed.

Listing 384: Commodity position data

<Trade id="CommodityPosition">
<TradeType>CommodityPosition</TradeType>
<Envelope>...</Envelope>
<CommodityPositionData>
<Quantity>1000</Quantity>
<Underlying>
<Type>Commodity</Type>
<Name>NYMEX:CL</Name>
<Weight>0.5</Weight>
<PriceType>FutureSettlement</PriceType>
<FutureMonthOffset>0</FutureMonthOffset>
<DeliveryRollDays>0</DeliveryRollDays>
<DeliveryRollCalendar>TARGET</DeliveryRollCalendar>
</Underlying>
<Underlying>
<Type>Commodity</Type>
<Name>ICE:B</Name>
<Weight>0.5</Weight>
<PriceType>FutureSettlement</PriceType>
<FutureMonthOffset>0</FutureMonthOffset>
<DeliveryRollDays>0</DeliveryRollDays>
<DeliveryRollCalendar>TARGET</DeliveryRollCalendar>
</Underlying>
</CommodityPositionData>
</Trade>

8.2.66 Generic Total Return Swap / Contract for Difference (CFD)

A generic total return swap / CFD (Trade type: TotalReturnSwap or
ContractForDifference) is set up using a TotalReturnSwapData (or
ContractForDifferenceData) block as shown in listing 387 and 392. Both trade types
behave exactly the same.
Usually CFDs are traded without a funding component and captured with only two
dates in the return schedule, namely the start date on which the initial price is fixed
and a fictitious closing date usually set to “tomorrow” or another suitable future date.

490
See listing 392 for the setup of a CFD on STOXX50E with initial price 3399.20 on
2019-09-28.
The generic total return swap is priced using the accrual method as opposed to a full
discounting method as it is used for the equity swap trade type. The accrual method is
common practice when daily unwind rights are present in the trade terms or when the
underlying valuation is too complex to allow for future projection.
The TotalReturnSwapData (ContractForDifferenceData) block is comprised of four
sub-blocks, which are
• UnderlyingData containing one or more Trade subnodes describing the asset
position of the TRS
• ReturnData describing the fixing and payment schedule of the return leg and
specifying indices for FX conversion if applicable
• FundingData (optional) containing one or more funding legs of the TRS, whose
notionals are based on either
– “PeriodReset”: the underlying price on the last valuation date before or on
the accrual start date of the relevant funding coupon, this price is converted
to the funding currency using the FX rate on this same valuation date for
compo / cross currency swaps (see below)
– “DailyReset”: the underlying price on each day of the accrual period, again
converted to the funding currency using the FX rate of the same date for
compo / cross currency swaps. This notional type is only supported for
fixed rate funding legs.
– “Fixed”: a fixed notional given explicitly in the funding leg
• AdditionalCashflowData (optional) a single leg of type Cashflow containing
additional payments
The ReturnData and FundingData schedule periods often match, but this is not a
strict requirement: In general, the funding notional is determined as described above
dependent on the notional types “PeriodReset”, “DailyReset”, “Fixed”.
Notice that in every case, the UnderlyingData schedule (if applicable to the
underlying trade type as e.g. for a bond) is completely independent from the funding /
return schedules: The underlying schedule defines the underlying flows to compute its
NPV, and is not directly related to the return swap itself.
Generic TRS can be used to represent total return swaps on a wide range of underlying
assets including e.g. single bonds or equities, CFDs on an underlying basket of
EquityPositions, proprietary indices on equity options and equity or bond indices.
• The UnderlyingData block specifies on or more underlyings, which can be a
trades of one of the following types. See the trade type specific sections for
details on the setup of these underlyings.
– Bond: See 8.2.39, the trade data is given in a BondData sub node.
– ForwardBond: See 8.2.42, the trade data is given in a ForwardBondData
sub node.

491
 – CBO: See 8.2.49, the trade data is given in a CBOData sub node.
– CommodityPosition: See 8.2.65, the trade data is given in a
CommodityPositionData sub node.
– ConvertibleBond: See 8.2.47, the trade data is given in a
ConvertibleBondData sub node. When using reference data, a TRS on a
convertible bond can also be captured as a TRS on a bond, i.e. there is no
need to distinguish between a TRS on a Bond and a TRS on a convertible
Bond in this case, the pricer will figure out which underlying to set up based
on the type of reference data that is set up for the ISIN referenced in the
security id field.
– EquityPosition: See 8.2.35, the trade data is given in a EquityPositionData
sub node. Notice that the equities given in the basket must be available as
quoted market data.
– EquityOptionPosition: See 8.2.36, the trade data is given in a
EquityOptionPositionData sub node.
– BondPosition: See 8.2.40, the trade data is given in a BondBasketData sub
node.
– Derivative: An arbitrary underlying derivative trade (of any type covered by
ORE), allowing the set up of a so called Portfolio Swap with multiple
underlying derivatives. The derivative subnode has exactly two subnodes
∗ Id: A unqiue identifier for the derivative position. Historical prices must
be given under the fixing name “GENERIC-< Id >”.
∗ Trade: The root node of a derivative trade.
Each trade is specified by a TradeType and a trade type dependent data block as
listed above. Listing 387 shows an example for a convertible bond underlying.
Listing 388 shows an example for an equity basket underlying. Listing 389 shows
an example for a bond basket underlying. Listing 390 shows an example for a
derivative underlying (a swaption in this case).
• The ReturnData block specifies the details of the return leg.
– Payer: Indicates whether the return leg is paid.
Allowable values: true, false
– Currency: The currency in which the return is expressed. This can be
different from the underlying currency (“composite” swap) and also from the
funding leg currency (“cross currency” swap). The “composite” and “cross
currency” features can occur alone or in combination.
Allowable values: A valid currency code, see Currency in Table 30, provided
it is the same as on the funding leg.
– ScheduleData: The reference schedule for the return leg, where the
valuation dates are derived from this schedule using the ObservationLag,
ObservationConvention and ObservationCalendar fields. The payment dates
are derived from this schedule using the PaymentLag, PaymentConvention

492
 and PaymentCalendar fields. The payment dates can also be given as an
explicit list in the PaymentDates node.
Allowable values: A ScheduleData block as defined in section 8.3.4
– ObservationLag [Optional]: The lag between the valuation date and the
reference schedule period start date.
Allowable values: Any valid period, i.e. a non-negative whole number,
followed by D (days), W (weeks), M (months), Y (years). Defaults to 0D if
left blank or omitted.
– ObservationConvention [Optional]: The roll convention to be used when
applying the observation lag.
Allowable values: A valid roll convention (F, MF, P, MP, U, NEAREST ),
see Table 31 Roll Convention. Defaults to U if left blank or omitted.
– ObservationCalendar [Optional]: The calendar to be used when applying
the observation lag.
Allowable values: Any valid calendar, see Table 34 Calendar. Defaults to
the NullCalendar (no holidays) if left blank or omitted.
– PaymentLag [Optional]: The lag between the reference schedule period end
date and the payment date.
Allowable values: Any valid period, i.e. a non-negative whole number,
optionally followed by D (days), W (weeks), M (months), Y (years).
Defaults to 0D if left blank or omitted. If a whole number is given and no
letter, it is assumed that it is a number of D (days).
– PaymentConvention [Optional]: The business day convention to be used
when applying the payment lag.
Allowable values: A valid roll convention (F, MF, P, MP, U, NEAREST ),
see Table 31 Roll Convention. Defaults to U if left blank or omitted.
– PaymentCalendar [Optional]: The calendar to be used when applying the
payment lag.
Allowable values: Any valid calendar, see Table 34 Calendar. Defaults to
the NullCalendar (no holidays) if left blank or omitted.
– PaymentDates [Optional]: This node allows for the specification of a list of
explicit payment dates, using PaymentDate elements. The list must contain
exactly n − 1 dates where n is the number of dates in the reference schedule
given in the ScheduleData node. See Listing 385 for an example with an
assumed ScheduleData with 4 dates.

493
Listing 385: Payment dates

<PaymentDates>
<PaymentDate>2020-01-15</PaymentDate>
<PaymentDate>2021-01-15</PaymentDate>
<PaymentDate>2022-01-17</PaymentDate>
</PaymentDates>

– InitialPrice [Optional]: The equity (or bond) price of the underlying on the
valuation date associated with the start date. Commonly contractually
given. The price can be given in the underlying currency or the return
currency as specified by the InitialPriceCurrency field and is given as
∗ a (dirty) price for Bond, ForwardBond and Convertible Bond
underlyings, the format is dependent on the price quotation method of
the referenced bond:
· Percentage of Par: the InitialPrice should be given as e.g. 1.02 for
102% relative dirty price
· Currency per Unit: the InitialPrice should be given as e.g. 0.51 for a
dirty amount of 51 USD per unit of the bond worth (say) 50.0 USD.
∗ the weighted price of one unit of the bond underlying basket, notice
that this is always a “percentage of par” price regardless of the
quotation style of the single bonds in the basket
∗ the (weighted) price of (one unit of) the equity underlying (basket)
∗ the (weighted) price of (one unit of) the equity option underlying
(basket)
∗ an absolute amount in the initial price ccy (“dollar amount”) if more
than one underlying is specified and if a derivative is specified
∗ absolute NPV if underlying is a CBO
Notice that for an equity basket underlying with several currencies involved,
the initial price is assumed to be given in the return currency in case no
InitialPriceCurrency is given.
Allowable values: A real number. If omitted or left blank it defaults to the
equity (or bond) price of the valuation date associated with the start date.
When this valuation date is in the future there is no fixed price, and in
these cases the InitialPrice defaults to the forward price.
– InitialPriceCurrency [Optional]: Only relevant if InitialPrice is given. This
specifies whether the initial price is given in the asset currency, the return
currency or the funding currency.
Allowable values: One of the currencies in ReturnData / Currency (return
currency), FundingData/ LegData / currency (funding currency) or the
currency of the underlying asset. Defaults to the return currency if omitted.

494
 – FXTerms [Mandatory when underlying asset / return / additional cashflow
/ funding currencies differ]: If the underlying asset currency is different from
the return currency, an FXIndex for the conversion underlying / return
currency must be given. The same holds for the funding and additional
cashflow currencies: Whenever one of these currencies are different from the
underlying currency, an FXIndex for the conversion to the underlying
currency must be given. If multiple currencies differ, multiple FXIndex
elements must be given.
∗ FXIndex: The fx index to use for the conversion, this must contain the
funding / return / additional cashflow currency and the underlying
asset currency (in the order defined in table 38, i.e. it does not matter
which one is the funding / return / additional cashflow currency and
which is the underlying currency)
Allowable values: see 38
Notice that for an underlying of type EquityPosition or
EquityOptionPosition additional FXIndex entries are required if there is
more than one equity position in a different currency: Eventually, for each
equity currency there must be a FXIndex specifying the conversion from the
equity currency to the funding currency (or for the return/cashflow vs
funding currency conversion). In this case multiple FXIndex entries are used
within a single FXTerms node, see 386.

Listing 386: FXTerms with multiple FXIndex

<FXTerms>
<FXIndex>FX-TR20H-GBP-SEK</FXIndex>
<FXIndex>FX-TR20H-GBP-EUR</FXIndex>
<FXIndex>FX-TR20H-GBP-USD</FXIndex>
</FXTerms>

– PayUnderlyingCashFlowsImmediately [Optional]: If true, underlying

cashflows like coupon or amortisation payments from bonds or dividend
payments from equities, are paid when they occur. If false, these cashflows
are paid together with the next return payment. If omitted, the default
value is false for trade type TotalReturnSwap and true for trade type
ContractForDifference.
Allowable values: true (immediate payment of underlying cashflwos) or false
(underlying cashflows are paid on the next return payment date)
• The FundingData block specifies the details of the funding leg(s). The block is
optional and can be omitted if no funding legs are present in the swap (e.g. for
CFDs). It contains one or more LegData nodes, see 8.3.3. Allowed leg types are
– Fixed
– Floating
– CMS

495
 – CMB
The number of coupons defined by the legs often match the number of periods of
the return schedule, but this is not a strict requirement. All funding legs must
share the same payment currency.
There are several ways to determine the notional of each funding leg, which is
determined by additional, optional NotionalType tags. If given, there must be
exactly one NotionalType tag for each LegData nodes. The types have the
following meanings:
– “PeriodReset”: the notional of a funding period is determined by the
underlying price on the last valuation date before or on the accrual start
date of the relevant funding coupon, this price is converted to the funding
currency using the FX rate on this same valuation date for compo / cross
currency swaps.
– “DailyReset”: the notional of a funding period is determined by the
underlying price on each day of the accrual period, again converted to the
funding currency using the FX rate of the same date for compo / cross
currency swaps. This notional type is only supported for fixed rate funding
legs.
– “Fixed”: The notional is explicitly given in the leg data.
If the NotionalType tags are not given, they default to “PeriodReset” in case no
explicit notional is given on the leg and “Fixed” in case an explicit notional is
given on the leg. See listing 387 for and example with two funding legs, one with
a notional of type DailyReset and one with a notional of type PeriodReset.
If a FundingResetGracePeriod is given, a lag of the given number of calendar
days is applied when determining the relevant return valuation date that
determines the funding notional. For example if FundingResetGracePeriod is set
to 2, a valuation date that lies at most 2 calendar days after the funding accrual
start date will be still considered eligible for this period.
• The AdditionalCashflowData block is optional and specifies unpaid amounts to
be included in the NPV. The type of this leg must be Cashflow. The currency of
the leg must be either the asset currency or the funding currency or the return
currency.

496
Listing 387: Generic Total Return Swap with Convertible Bond underlying

<TotalReturnSwapData>
<UnderlyingData>
<Trade>
<TradeType>Bond</TradeType>
<BondData>
<SecurityId>ISIN:XY1000000000</SecurityId>
<BondNotional>1000000.00</BondNotional>
</BondData>
</Trade>
</UnderlyingData>
<ReturnData>
<Payer>false</Payer>
<Currency>EUR</Currency>
<ScheduleData>...</ScheduleData>
<ObservationLag>0D</ObservationLag>
<ObservationConvention>P</ObservationConvention>
<ObservationCalendar>USD</ObservationCalendar>
<PaymentLag>2D</PaymentLag>
<PaymentConvention>F</PaymentConvention>
<PaymentCalendar>TARGET</PaymentCalendar>
<!-- <PaymentDates> -->
<!-- <PaymentDate> ... </PaymentDate> -->
<!-- <PaymentDate> ... </PaymentDate> -->
<!-- </PaymentDates> -->
<InitialPrice>1.05</InitialPrice>
<InitialPriceCurrency>EUR</InitialPriceCurrency>
<FXTerms>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
<FXIndex>FX-ECB-GBP-USD</FXIndex>
</FXTerms>
<PayUnderlyingCashFlowsImmediately>false</PayUnderlyingCashFlowsImmediately>
</ReturnData>
<FundingData>
<FundingResetGracePeriod>2</FundingResetGracePeriod>
<NotionalType>DailyReset</NotionalType>
<LegData>
<Payer>true</Payer>
<LegType>Fixed</LegType>
...
</LegData>
<NotionalType>PeriodReset</NotionalType>
<LegData>
<Payer>true</Payer>
<LegType>Floating</LegType>
...
</LegData>
</FundingData>
<AdditionalCashflowData>
<LegData>
<Payer>false</Payer>
<LegType>Cashflow</LegType>
...
</LegData>
</AdditionalCashflowData>
</TotalReturnSwapData>

497
Listing 388: Generic Total Return Swap with equity basket underlying

<TotalReturnSwapData>
<UnderlyingData>
<Trade>
<TradeType>EquityPosition</TradeType>
<EquityPositionData>
<!-- basket price = quantity x sum_i ( weight_i x equityPrice_i x fx_i ) -->
<Quantity>1000</Quantity>
<Underlying>
<Type>Equity</Type>
<Name>BE0003565737</Name>
<Weight>0.5</Weight>
<IdentifierType>ISIN</IdentifierType>
<Currency>EUR</Currency>
<Exchange>XFRA</Exchange>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>GB00BH4HKS39</Name>
<Weight>0.5</Weight>
<IdentifierType>ISIN</IdentifierType>
<Currency>GBP</Currency>
<Exchange>XLON</Exchange>
</Underlying>
</EquityPositionData>
</Trade>
</UnderlyingData>
<ReturnData>
...
<InitialPrice>112.0</InitialPrice>
<InitialPriceCurrency>USD</InitialPriceCurrency>
<FXTerms>
<FXIndex>FX-ECB-EUR-USD</FXIndex>
<FXIndex>FX-TR20H-GBP-USD</FXIndex>
</FXTerms>
</ReturnData>
<FundingData>
<LegData>
<Payer>true</Payer>
<LegType>Floating</LegType>
<Currency>USD</Currency>
...
</LegData>
</FundingData>
<AdditionalCashflowData>
<LegData>
<Payer>false</Payer>
<LegType>Cashflow</LegType>
...
</LegData>
</AdditionalCashflowData>
</TotalReturnSwapData>
</Trade>

498
Listing 389: Generic Total Return Swap with bond basket underlying

<TotalReturnSwapData>
<UnderlyingData>
<Trade>
<TradeType>BondPosition</TradeType>
<BondBasketData>
<Quantity>100000000</Quantity>
<Identifier>ISIN:GB00B4KT9Q30</Identifier>
</BondBasketData>
</Trade>
</UnderlyingData>
<!-- omitting ReturnData, FundingData, AdditionalCashflowData -->
</TotalReturnSwapData>
</Trade>

Listing 390: Generic Total Return Swap on a derivative underlying

<TotalReturnSwapData>
<UnderlyingData>
<Derivative>
<Id>DERIV:XR3JF32BFD</Id>
<Trade>
<TradeType>Swaption</TradeType>
<SwaptionData> ... </SwaptionData>
</Trade>
</Derivative>
</UnderlyingData>
<!-- omitting ReturnData, FundingData, AdditionalCashflowData -->
</TotalReturnSwapData>
</Trade>

Listing 391: Generic Total Return Swap on a commodity index underlying

<TotalReturnSwapData>
<UnderlyingData>
<Trade>
<TradeType>CommodityPosition</TradeType>
<CommodityPositionData>
<!-- basket price = quantity x sum_i ( weight_i x price_i x fx_i ) -->
<Quantity>1000</Quantity>
<Underlying>
<Type>Commodity</Type>
<Name>RIC:.BCOM</Name>
<Weight>1.0</Weight>
<PriceType>Spot</PriceType>
</Underlying>
</CommodityPositionData>
</Trade>
</UnderlyingData>
<!-- omitting ReturnData, FundingData, AdditionalCashflowData -->
</TotalReturnSwapData>
</Trade>

499
Listing 392: CFD on STOXX50E with initial price 3399.20 EUR

<ContractForDifferenceData>
<UnderlyingData>
<Trade>
<TradeType>EquityPosition</TradeType>
<EquityPositionData>
<Quantity>1000</Quantity>
<Underlying>
<Type>Equity</Type>
<Name>.STOXX50E</Name>
<Weight>1.0</Weight>
<IdentifierType>RIC</IdentifierType>
</Underlying>
</EquityPositionData>
</Trade>
</UnderlyingData>
<ReturnData>
<Payer>false</Payer>
<Currency>EUR</Currency>
<ScheduleData>
<Dates>
<Dates>
<!-- the start date of the CFD on which the initial price was set -->
<Date>2018-09-28</Date>
<!-- fictitious closing date, e.g. set to "tomorrow" -->
<Date>2019-01-04</Date>
</Dates>
</Dates>
</ScheduleData>
<InitialPrice>3399.20</InitialPrice>
<InitialPriceCurrency>EUR</InitialPriceCurrency>
</ReturnData>
</ContractForDifferenceData>

8.2.67 Equity Outperformance Option

The EquityOutperformanceOptionData node is the trade data container for the
EquityOutperformanceOption trade type. The EquityOutperformanceOptionData
node includes one OptionData trade component sub-node plus elements specific to the
Equity Outperformance Option.
An Equity Outperformance option has a payoff that depends on the ‘outperformance’
of two equity indices (i.e. the difference between their returns) against a strike return.
The buyer has the right but not the obligation to receive the outperformance in
exchange for the strike rate at a predetermined time in the future.
The trade may optionally have a knockIn or knockOut price (or both). Only if the
price of Underlying2 is above the knockIn value or below the knockOut value is the
payoff paid.
The structure of an example EquityOutperformanceOptionData node for an Equity
Outperformace Option is shown in Listing 393.

500
Listing 393: Equity Outperformance Option Data

<EquityOutperformanceOptionData>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>European</Style>
<Settlement>Cash</Settlement>
<ExerciseDates>
<ExerciseDate>2022-09-21</ExerciseDate>
</ExerciseDates>
...
</OptionData>
<Currency>USD</Currency>
<Notional>500000</Notional>
<Underlying1>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
</Underlying1>
<Underlying2>
<Type>Equity</Type>
<Name>RIC:.NDX</Name>
</Underlying2>
<InitialPrice1>2140</InitialPrice1>
<InitialPrice2>13000</InitialPrice2>
<StrikeReturn>0.01</StrikeReturn>
<KnockInPrice>12500</KnockInPrice>
<KnockOutPrice>14000</KnockOutPrice>
</EquityOutperformanceOptionData>

The Payoff is:

N · max(0, R1 − R2 − K)
where:
• N is the notional amount
• R1 is the return of Underlying1
• R2 is the return of Underlying2
• K is the StrikeReturn.
The meanings and allowable values of the elements in the
EquityOutperformaceOptionData node follow below.
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an EquityOutperformanceOption are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put. Call means that the
holder has the right but not obligation to receive the Outperformance and
pay the StrikeReturn. Put means that the holder has the right but not
obligation to pay the Outperformance and receive the StrikeReturn.
– Style The allowable value is European. Note that the Equity
Outperformance Option type allows for European option style only.

501
 – Settlement The allowable values are Cash or Physical.
– An ExerciseDates node where exactly one ExerciseDate date element must
be given.
– Premiums [Optional]: Option premium amounts paid by the option buyer
to the option seller.
Allowable values: See section 8.3.2
• Currency: The currency of the equity outperformance option.
Allowable values: See Table 32 Currency.
• Underlying1: Specifies the first underlying equity. This in turn defines the equity
curve used for pricing. The Underlying node is described in further detail in
Section 8.3.29. Note that the node name is Underlying1.
• Underlying2: Specifies the second underlying equity. This in turn defines the
equity curve used for pricing. The Underlying node is described in further detail
in Section 8.3.29. Note that the node name is Underlying2.
Also note that the equities in Underlying1 and Underlying2 must be quoted in
the same currency.
• InitialPrice1: Specifies the initial price for first underlying equity.
Allowable values: Any positive real number.
• InitialPrice2: Specifies the initial price for second underlying equity.
Allowable values: Any positive real number.
• StrikeReturn: The option strike return.
Allowable values: Any positive real number.
• Notional: The notional amount for the trade.
Allowable values: Any positive real number.
• KnockInPrice[Optional]: The payoff is only paid if on the settlement date the
price of underlying2 is above this value.
Allowable values: Any positive real number.
• KnockOutPrice[Optional]: The payoff is only paid if on the settlement date the
price of underlying2 is below this value.
Allowable values: Any positive real number.
• InitialPriceCurrency1 [Optional]: Only relevant if InitialPrice1 is given in a
currency other than Underlying1’s currency.
Allowable values: See Table 32 Currency.
• InitialPriceCurrency2 [Optional]: Only relevant if InitialPrice1 is given in a
currency other than Underlying2’s currency.
Allowable values: See Table 32 Currency.

502
 • InitialPriceFXTerms1 [Mandatory when InitialPriceCurrency1 is provided]: The
node must be given if and only if the underlying currency is different from the
initialPrice currency. The node contains the following sub nodes:
– FXIndex: The fx index to use for the conversion, this must contain the
underlying asset currency and the funding leg currency (in the order defined
in table 38, i.e. it does not matter which one is the asset currency and
which is the funding currency)
Allowable values: see 38
– InitialPriceFXTerms2 [Mandatory when InitialPriceCurrency2 is provided]:
The node must be given if and only if the underlying currency is different
from the initialPrice currency. Contains the same subnodes as
InitialPriceFXTerms1.
Allowable values: Any valid calendar, see Table 34 Calendar. Defaults to
the NullCalendar (no holidays) if left blank or omitted.

8.2.68 Double Digital Option

The DoubleDigitalOptionData node is the trade data container for the
DoubleDigitalOption trade type, listing 394 shows the structure of an example with
two underlying FX rates. Equity, Commodity and IR underlyings are also supported in
arbitrary combinations. A double digital option is a binary option that pays out a
fixed amount if the two underlyings (FX spots, Equity or Commodity prices, interest
rates) are simultaneously in the money w.r.t. given strikes and option types at the
option expiry.

Listing 394: Double Digital Option data

<DoubleDigitalOptionData>
<Expiry>2021-09-01</Expiry>
<Settlement>2021-09-03</Settlement>
<BinaryPayout>12000000</BinaryPayout>
<BinaryLevel1>1.1</BinaryLevel1>
<BinaryLevel2>0.006</BinaryLevel2>
<BinaryLevelUpper2>0.008</BinaryLevelUpper2>
<Type1>Call</Type1>
<Type2>Collar</Type2>
<Position>Long</Position>
<Underlying1>
<Type>FX</Type>
<Name>ECB-EUR-USD</Name>
</Underlying1>
<Underlying2>
<Type>FX</Type>
<Name>ECB-JPY-USD</Name>
</Underlying2>
<PayCcy>USD</PayCcy>
</DoubleDigitalOptionData>

The meanings and allowable values of the elements in the DoubleDigitalOptionData

node follow below.

503
• Expiry: The expiry date of the option. Allowable values are valid dates.
• Settlement: The payout settlement date. Allowable values are valid dates.
• BinaryPayout: The amount that is paid if the option is in the money. Allowable
values are all non-negative numbers.
• BinaryLevel1: The strike for underlying 1 for Call or Put option and the lower
bound for a Collar option. For an FX underlying (SOURCE-CCY1-CCY2) this
is the number of units of CCY2 per units of CCY1. For an Equity underlying
this is the equity price expressed in the equity ccy. For a Commodity underlying
this is the commodity price expressed in the commodity ccy. For an IR
underlying this is the rate expressed in decimal form. Allowable values are
non-negative numbers.
• BinaryLevel2: The strike for underlying 2 for Call or Put option and the lower
bound for a Collar. For an FX underlying (SOURCE-CCY1-CCY2) this is the
number of units of CCY2 per units of CCY1. For an Equity underlying this is the
equity price expressed in the equity ccy. For a Commodity underlying this is the
commodity price expressed in the commodity ccy. For an IR underlying this is
the rate expressed in decimal form. Allowable values are non-negative numbers.
• Type1: The option type that applies to underlying 1. Allowable values: Call, Put
or Collar. Underlying 1 is considered to be in the money if the spot is above
(Call) / below (Put) the BinaryLevel1 resp. between (Collar) the BinaryLevel1
and BinaryLevelUpper1 at the expiry.
• Type2: The option type that applies to underlying 2. Allowable values: Call, Put
or Collar. Underlying 2 is considered to be in the money if the spot is above
(Call) / below (Put) the BinaryLevel1 resp. between (Collar) the BinaryLevel2
andthe BinaryLevelUpper2 at the expiry.
• Position: The option position type. Allowable values: Long or Short.
• Underlying1: The first underlying, see 8.3.29.
• Underlying2: The second underlying, see 8.3.29. Note that Type for both
underlyings has allowable values Equity, Commodity, FX, and IR.
• Underlying3 [Optional]: If defined, the first underlying in this transaction is
treated as a spread between Underlying1 and Underlying3 (i.e. Underlying1
fixing minus Underlying3 fixing), see 8.3.29. Underlying3 Type must be the same
as Underlying1 Type.
• Underlying4 [Optional]: If defined, the second underlying in this transaction is
treated as a spread between Underlying2 and Underlying4 (i.e. Underlying2
fixing minus Underlying4 fixing), see 8.3.29. Underlying4 Type must be the same
as Underlying2 Type.
• PayCcy: The currency in which the BinaryPayout is paid. See Table 32 for
allowable currency codes.
• BinaryLevelUpper1 [Optional]: This is field is used only for Collar option. The
upper bound for underlying 1. For an FX underlying (SOURCE-CCY1-CCY2)
this is the number of units of CCY2 per units of CCY1. For an Equity

504
 underlying this is the equity price expressed in the equity ccy. For a Commodity
underlying this is the commodity price expressed in the commodity ccy. For an
IR underlying this is the rate expressed in decimal form. Allowable values are
non-negative numbers.
• BinaryLevelUpper2 [Optional]: This field is used only for Collar option. The
upper bound for underlying 2. For an FX underlying (SOURCE-CCY1-CCY2)
this is the number of units of CCY2 per units of CCY1. For an Equity
underlying this is the equity price expressed in the equity ccy. For a Commodity
underlying this is the commodity price expressed in the commodity ccy. For an
IR underlying this is the rate expressed in decimal form. Allowable values are
non-negative numbers.

8.2.69 European Option Contingent on a Barrier

European exercise, American or European barrier, multi-asset
This is a plain vanilla European option on a given underlying, whose final payoff is
contingent on the price level of another underlying (forming the barrier). Both
underlyings can be of multiple asset classes.
The trade container for this product is the EuropeanOptionBarrierData node, and
the corresponding trade type is EuropeanOptionBarrier. The barrier can be
continuously monitored (American) or only be monitored on the option expiry date
(European). Currently, we support Equity, FX, Commodity and InterestRate for the
option underlying. For the barrier underlying, we support Equity, FX, Commodity and
InterestRate for European-style barriers, but not InterestRate for an American-style
barrier.
Listing 395 shows the structure of an Equity European option with an American-style
FX barrier. For a European-style barrier, the BarrierType must be set to European
and the BarrierSchedule can be omitted.

505
Listing 395: European Option Barrier data (continuous barrier)

<Trade id="Equity_EuropeanOptionWithAmericanFxBarrier">
<TradeType>EuropeanOptionBarrier</TradeType>
<Envelope>
.....
</Envelope>
<EuropeanOptionBarrierData>
<Quantity>8523</Quantity>
<PutCall>Call</PutCall>
<LongShort>Short</LongShort>
<Strike>3520</Strike>
<PremiumAmount>114.40</PremiumAmount>
<PremiumCurrency>EUR</PremiumCurrency>
<PremiumDate>2019-12-13</PremiumDate>
<OptionExpiry>2020-06-19</OptionExpiry>
<OptionUnderlying>
<Type>Equity</Type>
<Name>RIC:.STOXX50E</Name>
</OptionUnderlying>
<BarrierUnderlying>
<Type>FX</Type>
<Name>ECB-EUR-USD</Name>
</BarrierUnderlying>
<BarrierLevel>1.09335</BarrierLevel>
<BarrierType>DownAndIn</BarrierType>
<BarrierStyle>American</BarrierStyle>
<BarrierSchedule>
<Rules>
<StartDate>2019-12-11</StartDate>
<EndDate>2020-06-19</EndDate>
<Tenor>1D</Tenor>
<Calendar>USA</Calendar>
<Convention>Following</Convention>
<TermConvention>Following</TermConvention>
<Rule>Forward</Rule>
</Rules>
</BarrierSchedule>
<SettlementDate>2020-06-24</SettlementDate>
<PayCcy>USD</PayCcy>
</EuropeanOptionBarrierData>
</Trade>

The meanings and allowable values of the elements in the

EuropeanOptionBarrierData node follow below.
• Quantity: Number of option contracts.
Allowable values: Any non-negative number.
• PutCall: Option type.
Allowable values: Call, Put
• LongShort: Own party position.
Allowable values: Long, Short
• Strike: Option strike price.
Allowable values: Any positive number.

506
 • PremiumAmount: Premium amount per option.
Allowable values: Any number.
• PremiumCurrency: Currency of the option premium.
Allowable values: See Currency in Table 30.
• PremiumDate: The option premium payment date.
Allowable values: See Date in Table 30.
• OptionExpiry: Option expiry date.
Allowable values: See Date in Table 30.
• OptionUnderlying: The option underlying.
Allowable values: A node of the same form as Underlying, (see 8.3.29). The
supported types are Equity, FX, Commodity and InterestRate.
• BarrierUnderlying: The underlying monitored against the barrier level.
Allowable values: A node of the same form as Underlying, (see 8.3.29). The
supported types are Equity, FX, Commodity and InterestRate if BarrierStyle is
European. For BarrierStyle American, we only support Equity, FX and
Commodity.
• BarrierLevel: Knock-in/knock-out barrier level.
Allowable values: Any number.
• BarrierType: The type of knock-in or knock-out barrier.
Allowable values: DownIn, UpIn, DownOut, UpOut
• BarrierStyle: Whether the barrier is continuously monitored or only at the
option expiry date.
Allowable values: American, European
• BarrierSchedule [Optional]: The schedule specifying the schedule of trading days
over which the continuous barrier will be monitored. This is required only when
BarrierStyle is American.
Allowable values: A node of the same form as ScheduleData, (see 8.3.4).
• SettlementDate: Settlement date of the option exercise payoff.
Allowable values: See Date in Table 30. The Settlement date must be on or after
the Option expiry date.
• PayCcy: Settlement currency.
Allowable values: See Table 32 Currency.

8.2.70 Autocallable Type 01

The Autocallable_01 node is the trade data container for the Autocallable_01 trade
type, listing 396 shows the structure of an example.

507
Listing 396: Autocallable Type 01 data

<Autocallable01Data>
<NotionalAmount>12000000</NotionalAmount>
<DeterminationLevel>11.0</DeterminationLevel>
<TriggerLevel>9.8</TriggerLevel>
<Underlying>
<Type>FX</Type>
<Name>ECB-EUR-NOK</Name>
</Underlying>
<Position>Long</Position>
<PayCcy>EUR</PayCcy>
<FixingDates>
<ScheduleData>
<Dates>
<Dates>
<Date>2018-09-27</Date>
<Date>2019-09-27</Date>
<Date>2020-09-27</Date>
<Date>2021-09-29</Date>
<Date>2022-09-28</Date>
</Dates>
</Dates>
</ScheduleData>
</FixingDates>
<SettlementDates>
<ScheduleData>
<Dates>
<Dates>
<Date>2018-10-07</Date>
<Date>2019-10-09</Date>
<Date>2020-10-07</Date>
<Date>2021-10-07</Date>
<Date>2022-10-07</Date>
</Dates>
</Dates>
</ScheduleData>
</SettlementDates>
<AccumulationFactors>
<Factor>0.344</Factor>
<Factor>0.733</Factor>
<Factor>0.911</Factor>
<Factor>1.123</Factor>
<Factor>1.544</Factor>
</AccumulationFactors>
<Cap>1.0</Cap>
</Autocallable01Data>

If a trigger event occurs on the i-th fixing date, the option holder receives the following:

P ayout = NotionalAmount ∗ AccumulationF actori .

If a trigger event never occurs and the underlying spot at the fixing date fn is above
the DeterminationLevel, the option holder pays the following:

508
 P ayout = min(Cap, Underlying(fn ) − DeterminationLevel).

The meanings and allowable values of the elements in the Autocallable01Data node
follow below.
• NotionalAmount: The notional amount of the option. Allowable values are
non-negative numbers.
• DeterminationLevel: The determination level. For an FX underlying
FX-SOURCE-CCY1-CCY2 this is the number of units of CCY2 per units of
CCY1. For an EQ underlying this is the equity price expressed in the equity ccy.
Allowable values are non-negative numbers.
• TriggerLevel: The trigger level. For an FX underlying
FX-SOURCE-CCY1-CCY2 this is the number of units of CCY2 per units of
CCY1. For an EQ underlying this is the equity price expressed in the equity ccy.
Allowable values are non-negative numbers.
• Underlying: The option underlying, see 8.3.29.
• Position: The option position type. Allowable values: Long or Short.
• PayCcy: The pay currency of the option. See the appendix for allowable
currency codes.
• FixingDates: The fixing date schedule given as a ScheduleData subnode, see
8.3.4
• SettlementDates: The settlement date schedule given as a ScheduleData
subnode, see 8.3.4
• AccumulationFactors: The accumulation factors given as a list of values
corresponding to the fixing dates. Allowable values are non-negative numbers.
• Cap: The maximum amount, per unit of notional, payable by the option holder if
a trigger event never occurred (i.e. underlying value was never below the
TriggerLevel on any of the fixing dates) and if the underlying value is greater
than the DeterminationLevel at the last fixing date. Allowable values are
non-negative numbers.

8.2.71 Performance Option Type 01

The performace option of type “01” is characterized by the following data
• a notional amount N
• a participation rate q
• a valuation date V and a settlement date S
• a number of underlyings Ui for i = 1, . . . , n
• weights for the underlyings wi for i = 1, . . . , n
• initial strike prices for the underlyings si for i = 1, . . . , n

509
 • an option strike K
On the valuation date the average performance of the underlying basket is computed as

n   !
X Ui (V )
P = max wi − K ,0
i=1
si

The option holder receives an amount N · q · P on the settlement date S. The

underlyings can be Equity, FX or Commodity underlyings.
The above payoff includes the strike in the performance calculation. There is another
variant with excluded strike and payoff:
" n
# !
X Ui (V )
P = max wi − K, 0
i=1
si

The PerformanceOption_01 node is the trade data container for the

PerformanceOption_01 trade type, listing 397 shows the structure of an example.

510
Listing 397: Performance Option Type 01 data

<PerformanceOption01Data>
<NotionalAmount>12500000</NotionalAmount>
<ParticipationRate>0.9</ParticipationRate>
<ValuationDate>2022-05-03</ValuationDate>
<SettlementDate>2022-05-05</SettlementDate>
<Underlyings>
<Underlying>
<Type>FX</Type>
<Name>ECB-CHF-EUR</Name>
<Weight>0.34</Weight>
</Underlying>
<Underlying>
<Type>FX</Type>
<Name>ECB-NOK-EUR</Name>
<Weight>0.32</Weight>
</Underlying>
<Underlying>
<Type>FX</Type>
<Name>ECB-SEK-EUR</Name>
<Weight>0.24</Weight>
</Underlying>
<Underlying>
<Type>FX</Type>
<Name>ECB-SEK-EUR</Name>
<Weight>0.10</Weight>
</Underlying>
</Underlyings>
<StrikePrices>
<StrikePrice>0.910002</StrikePrice>
<StrikePrice>0.097192</StrikePrice>
<StrikePrice>0.096085</StrikePrice>
<StrikePrice>0.035032</StrikePrice>
</StrikePrices>
<Strike>1.15</Strike>
<StrikeIncluded>true</StrikeIncluded>
<Position>Long</Position>
<PayCcy>EUR</PayCcy>
</PerformanceOption01Data>

The meanings and allowable values of the elements in the PerformanceOption01Data

node follow below.
• NotionalAmount: The notional amount of the option. Allowable valus are
non-negative numbers.
• ParticipationRate: The participation rate. Allowable values are non-negative
numbers. Usually the value will be between 0 and 1.
• ValuationDate: The valuation date. Allowable values are valid dates.
• SettlementDate: The settlement date. Allowable values are valid dates.
• Underlyings: The underlyings of the option. See 8.3.29 for each underlying.
• StrikePrices: The initial strike prices of the underlyings. For an FX underlying

511
 FX-SOURCE-CCY1-CCY2 this is the number of units of CCY2 per units of
CCY1. For an EQ underlying this is the equity price expressed in the equity ccy.
For a Commodity underlying this is the commodity price quoted as per the
underlying commodity. Allowable values are non-negative numbers.
• Strike: The option strike. This is expressed in terms of the performance of the
underlying basket (see the product description for more details). Allowable
values are numbers.
• StrikeIncluded [optional]: If true the strike is included in the performance
calculation, this is also the default if the flag not given. If false the strike is
excluded.
• Position: The option position. Allowable values are Long or Short.
• PayCcy: The payment currency of the option. See the appendix for allowable
currency codes.

8.2.72 Window Barrier Option

The FxWindowBarrierOptionData, EquityWindowBarrierOptionData,
CommodityWindowBarrierOptionData is the trade data container for the
FxWindowBarrierOption, EquityWindowBarrierOption, CommodityBarrierOption
trade type. The following listing shows the structure of an example trade for an FX
underlying.

<Trade id="FX_Window_BarrierOption">
<TradeType>FxWindowBarrierOption</TradeType>
<Envelope>
...
</Envelope>
<FxWindowBarrierOptionData>
<Currency>USD</Currency>
<FixingAmount>1000000</FixingAmount>
<Underlying>
<Type>FX</Type>
<Name>ECB-EUR_USD</Name>
</Underlying>
<Strike>1.1</Strike>
<StartDate>2023-03-01</StartDate>
<EndDate>024-03-01</EndDate>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<ExerciseDates>
<ExerciseDate>2026-03-01</ExerciseDate>
</ExerciseDates>
<Premiums>
<Premium>
<Amount>10900</Amount>
<Currency>EUR</Currency>
<PayDate>2018-03-01</PayDate>
</Premium>
</Premiums>
<PaymentData>
<Dates>

512
 <Date>2026-03-01</Date>
</Dates>
</PaymentData>
</OptionData>
<BarrierData>
<Type>UpAndOut</Type>
<Levels>
<Level>1.3</Level>
</Levels>
</BarrierData>
</FxWindowBarrierOptionData>
</Trade>

The meanings and allowable values of the elements in the data node follow below.
• Currency: The payout currency. The result of the payout formula above is
treated to be in this currency. Note that for (non-quanto)
FxWindowBarrierOption this should be the domestic (CCY2) currency. For
non-quanto Equity- and CommodityWindowBarrierOptions this should be the
currency the equity or commodity is quoted in. Notice section “Payment
Currency” in ore/Docs/ScriptedTrade.
Allowable values: See Table 32 Currency.
• FixingAmount: The notional amount. For FxWindowBarrierOptions: The
FixingAmount is expressed in the foreign currency (CCY1). For
EquityWindowBarrierOptions: The FixingAmount is expressed as number of
shares/units of the underlying equity or equity index. For
CommodityWindowBarrierOptions: The FixingAmount is expressed as number
of units of the underlying commodity.
Allowable values: Any positive real number.
• Underlying: A node with the underlying of the Window Barrier instrument. For
FxWindowBarrierOption: Type is set to FX and Name is a string of the form
SOURCE-CCY1-CCY2 where CCY1 is the foreign currency, CCY2 is the domestic
currency, and SOURCE is the fixing source, see Table 38 and 8.3.29. For
EquityWindowBarrierOption: Type is set to Equity and Name and other fields are
as outlined in 8.3.29. For CommodityWindowBarrierOption: Type is set to
Commodity and Name is an identifier of the commodity as outlined in 8.3.29 and
in Table 42.
Allowable values: Any FX, Equity or Commodity underlying as specified in 8.3.29
• StrikeData [Optional]: A node containing the strike in Value and the currency in
which both the underlying and the strike are quoted in Currency. Only
supported for EquityWindowBarrierOption.
Allowable values: See Currency in Table 30. The strike may be any positive real
number. The currency provided in this node may be quoted as corresponding
minor currency to the underlying major currency.
• Strike [Optional]: For FxWindowBarrierOptions: The the fx strike rate is defined
as amount in domestic currency (CCY2) for one unit of foreign currency (CCY1).
For Equity- and CommodityWindowBarrierOptions: The strike value for one
unit/share/contract of the underlying equity or commodity, expressed in the
currency the equity or commodity is quoted in. For

513
 EquityWindowBarrierOptions, the StrikeData node (see above) should be used.
Allowable values: Any positive real number.
• StartDate: The start date of the continuous observation window.
Allowable values: Any valid date.
• EndDate: The end date of the continuous observation window.
Allowable values: Any valid date.
• OptionData: See 8.3.1. The relevant fields in the OptionData node for a Window
Barrier Option are:
– LongShort The allowable values are Long or Short.
– OptionType The allowable values are Call or Put.
– ExerciseDates Must contain the single exercise date of the option.
– Premiums [Optional] Option premium amounts paid by the option buyer to
the option seller. See section 8.3.2
– PaymentData [Optional] Optional pay date associated to the exercise date.
• BarrierData: Specification of the barrier type and level. The barrier is
continuosly monitored between the StartDate and EndDate.
Allowable values: See 8.3.31, allowable types are UpAndOut,
DownAndOut,UpAndIn, DownAndIn. Exactly one level must be given as a
positive real number.
Window Barrier Options can be alternatively represented as scripted trades, refer to
ore/Docs/ScriptedTrade for an introduction.
Trade input and the payoff script are described below.

<Trade id="WindowBarrierOption#1">
<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<WindowBarrierOptionData>
<PremiumPayDate type="event">2018-03-01</PremiumPayDate>
<Settlement type="event">2026-03-01</Settlement>
<Expiry type="event">2026-03-01</Expiry>
<StartDate type="event">2023-03-01</StartDate>
<EndDate type="event">2024-03-01</EndDate>
<PremiumAmount type="number">10900</PremiumAmount>
<BarrierLevel type="number">1.3</BarrierLevel>
<PutCall type="optionType">Call</PutCall>
<BarrierType type="barrierType">UpOut</BarrierType>
<LongShort type="longShort">Long</LongShort>
<Quantity type="number">1000000</Quantity>
<Strike type="number">1.1</Strike>
<PayCcy type="currency">USD</PayCcy>
<PremiumCcy type="currency">EUR</PremiumCcy>
<Underlying type="index">FX-ECB-EUR-USD</Underlying>
</WindowBarrierOptionData>
</Trade>

The WindowBarrierOption script referenced in the trade above is shown in Listing 398.

514
Listing 398: Payoff script for a WindowBarrierOption.

REQUIRE BarrierType == 1 OR BarrierType == 2 OR BarrierType == 3 OR BarrierType == 4;

NUMBER i, Payoff, TriggerProbability, ExerciseProbability, isUp, currentNotional;

IF BarrierType == 1 OR BarrierType == 3 THEN

TriggerProbability = BELOWPROB(Underlying, StartDate, EndDate, BarrierLevel);
ELSE
TriggerProbability = ABOVEPROB(Underlying, StartDate, EndDate, BarrierLevel);
END;

Payoff = Quantity * PutCall * (Underlying(Expiry) - Strike);

IF Payoff > 0.0 THEN
IF BarrierType == 1 OR BarrierType == 2 THEN
Option = PAY(Payoff * TriggerProbability, Expiry, Settlement, PayCcy);
ExerciseProbability = TriggerProbability;
ELSE
Option = PAY(Payoff * (1 - TriggerProbability), Expiry, Settlement, PayCcy);
ExerciseProbability = (1 - TriggerProbability);
END;
END;

Option = LongShort * (Option - PAY(PremiumAmount, PremiumPayDate, PremiumPayDate, PremiumCcy));

currentNotional = Quantity * Strike;

The meanings and allowable values of the elements in the WindowBarrierOptionData

node below.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [event] StartDate: Barrier monitoring start date.
Allowable values: See Date in Table 30.
• [event] EndDate: Barrier monitoring start date.
Allowable values: See Date in Table 30.
• [number] Strike: The option strike price. For FX, this should be the amount of
CCY1 divided by amount of CCY2 as defined in Index.
Allowable values: Any positive real number.
• [number] BarrierLevel: Knock-in or knock-out barrier level. For FX, this
should be quoted as amount of CCY2 per unit CCY1 as defined in Index.
Allowable values: Any positive real number.
• [barrierType] BarrierType: Barrier type.
Allowable values: DownIn, UpIn, DownOut, UpOut
• [optionType] PutCall: Option type. For FX, this should be Call if we buy CCY1
and sell CCY2, Put if we buy CCY2 and sell CCY1 (with CCY1, CCY2 defined in
Index ).
Allowable values: Call, Put

515
 • [longShort] LongShort: Long if we buy the option. Short if we sell the option.
Allowable values: Long, Short
• [number] Quantity: Number of option contracts. For FX, this should be the
bought amount.
Allowable values: Any positive real number.
• [index] Underlying: Underlying index.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes. Allowable values:
See Currency in Table 30.
• [event] PremiumPayDate: Option premium payment date.
Allowable values: See Date in Table 30.
• [number] PremiumAmount: Option premium amount in PremiumPayCcy.
Allowable values: Any positive real number.
• [currency] PremiumCcy: Option premium currency.
Allowable values: See Table 32 Currency.

8.2.73 Generic Barrier Option

Generic Barrier Options are defined using one of the trade types
FxGenericBarrierOption, EquityGenericBarrierOption,
CommodityGenericBarrierOption depending on the underlying asset class and an
associated node FxGenericBarrierOptionData, EquityGenericBarrierOptionData,
CommodityGenericBarrierOptionData. Listing 399 shows an example for an FX
Underlying. Generic Barrier Option can have one or multiple underlyings. In the case
of multiple underlyings, there must be one level per underlying provided in each
barrier, see 400. The nodes have the following meaning:
• Underlying: The underlying definition. Note that for FX underlyings the order of
the currencies defines the observed underlying value, i.e. for EUR-USD the
domestic currency is USD (the observed value is e.g. 1.2 USD per EUR) while
for USD-EUR the domestic currency is EUR (the observed value is e.g. 0.8 EUR
per USD).
Allowable Values: See 8.3.29
• Underlyings: An alternative to Underlying - only one can be present. Can
contain multiple Underlying nodes. Allowable Values: A list of Underlying
nodes, with each node given by 8.3.29
• PayCurrency: The payment currency. This is required for all Payoff Types and is
usually

516
 – the domestic currency if underlying = FX
– the eq / comm currency if underlying = Equity, Commodity
But we allow for quanto payoffs as well, i.e.
– the foreign currency if underlying = FX or also
– a third currency if underlying = FX and
– a currency not equal to the equity, commodity currency for these underlying
types.
See payoff description which amount is paid in which currency dependent on the
type.
Allowable Values: See Currency in Table 30.
• OptionData: The option descripting, see 8.3.1 Relevant sub nodes are:
– LongShort (allowable values: Long or Short)
– PayoffType, with S = Underlying Value and K = Strike this is:
∗ Vanilla: max(0, S − K) for a call or max(0, K − S) for a put, this is
paid in PayCurrency
∗ AssetOrNothing: S paid in PayCurrency
∗ CashOrNothing: Amount paid in PayCurrency
– OptionType: Required for PayoffType = Vanilla, Call or Put.
– ExerciseDate: The exercise date
– Premiums [Optional]: Option premiums to be paid unconditionally. See
section 8.3.2
• SettlementDate [Optional]: The date on which the option payoff is settled. The
SettlementDate is used unadjusted as given. Instead of the SettlementDate, a
settlement lag, convention and calendar relative to the ExerciseDate can be
specified, see below. If the SettlementDate is given on the other hand,
SettlementLag, SettlementCalendar and SettlementConvention must not be
given.
Allowable Values: any valid date greater or equal to the exercise date
• SettlementLag [Optional]: Alternative specification of the option settlement date
via a lag, see the explanation under SettlementDate. Defaults to 0D if not given.
Allowable Values: any valid period (1D, 2W, 3M, ...)
• SettlementCalendar [Optional]: Alternative specification of the option settlement
date via a lag, see the explanation under SettlementDate. Defaults to the
underlying calendar, if not given.
Allowable values: See Table 34 Calendar.

517
• SettlementConvention [Optional]: Alternative specification of the option
settlement date via a lag, see the explanation under SettlementDate. Defaults to
Following if not given.
Allowable values: See Table 31 Roll Convention.
• Quantity: The option quantity. Required for PayoffType = AssetOrNothing,
Vanilla. For FX this is the amount in foreign currency. For Equity, Commodity
this is the number of equities, commodities.
Allowable Values: any real number
• Strike: Required for PayoffType = Vanilla.
Allowable Values: any real number
• Amount: Required for PayoffType = CashOrNothing.
Allowable Values: any real number
• Barriers. The barrier definition. Subnodes are:
– ScheduleData [Optional]: the observation schedule for the barrier (see 8.3.4.
Instead of the ScheduleData, a daily schedule w.r.t. the underlying calendar
can be specified by populating the StartDate and EndDate nodes.
– StartDate [Optional]: Start date of the observation schedule, see the
explanation under ScheduleData.
– EndDate [Optional]: End date of the observation schedule, see the
explanation under ScheduleData.
– BarrierData [Optional]: a sequence of barrier definitions. See 8.3.31.
Relevant fields are:
∗ Type: The barrier type (allowed values are UpAndIn, UpAndOut,
DownAndIn, DownAndOut)
∗ Levels: Exactly one barrier level per BarrierData block must be given.
∗ Rebate [Optional]: The rebate amount. Defaults to zero. Rebate
amounts and currencies can be different across barriers if only “out”
barriers are defined, but must be identical as soon as at least one “in”
barrier is defined.
∗ RebateCurrency [Optional]: The currency in which the rebate is paid.
Defaults to PayCurrency.
∗ RebatePayTime [Optional]: atExpiry ar atHit. For “in” barriers only
atExpiry is allowed.
– KikoType: Required if both a KI and KO barriers are defined. Allowable
values are KoAlways, KoBeforeKi, KoAfterKi.
• TransatlanticBarrier [Optional]: An additional barrier to be checked on option
expiry. May contain exactly one BarrierData block with number of levels equal
to the number of underlyings or contain same amount of BarrierData blocks with
the number of underlyings, exactly one level is allowed in each block for each

518
underlying. The type (UpAndIn, UpAndOut, DownAndIn, DownAndOut), the
(unqiue) level and the rebate are relevant fields.
For CashOrNothing, the payoff occurs if the underlying at expiry is equal to or
below the level of transatlantic barrier type DownAndIn, or equal to or above
barrier type UpAndIn, or equal to or above barrier type DownAndOut, or equal
to or below barrier type UpAndOut. I.e. the barrier checks use <=, >= to check
In-barriers and <, > to check Out-barriers.
The rebate is paid if there is no knock-out from the American barriers and no
payoff from the Transatlantic barrier.

519
Listing 399: Generic Barrier Option data (FX Underlying)

<FxGenericBarrierOptionData>
<Underlying>
<Type>FX</Type>
<Name>ECB-EUR-USD</Name>
</Underlying>
<PayCurrency>USD</PayCurrency>
<OptionData>
<LongShort>Long</LongShort>
<PayoffType>Vanilla</PayoffType>
<OptionType>Call</OptionType>
<ExerciseDates>
<ExerciseDate>2023-06-06</ExerciseDate>
</ExerciseDates>
</OptionData>
<SettlementDate>2023-06-08</SettlementDate>
<Quantity>100000000</Quantity>
<Strike>1.2</Strike>
<Barriers>
<ScheduleData>
<Rules>
<StartDate>2021-07-10</StartDate>
<EndDate>2023-06-06</EndDate>
<Tenor>1D</Tenor>
<Calendar>TGT,US</Calendar>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
<BarrierData>
<Type>DownAndOut</Type>
<Levels>
<Level>1.1</Level>
</Levels>
<Rebate>1000000</Rebate>
<RebateCurrency>USD</RebateCurrency>
<RebatePayTime>atExpiry</RebatePayTime>
</BarrierData>
<BarrierData>
<Type>UpAndIn</Type>
<Levels>
<Level>1.3</Level>
</Levels>
<Rebate>1000000</Rebate>
<RebateCurrency>USD</RebateCurrency>
<RebatePayTime>atExpiry</RebatePayTime>
</BarrierData>
<KikoType>KoAfterKi</KikoType>
</Barriers>
<TransatlanticBarrier>
<BarrierData>
<Type>UpAndOut</Type>
<Levels>
<Level>1.3</Level>
</Levels>
<Rebate>2000000</Rebate>
<RebateCurrency>USD</RebateCurrency>
</BarrierData>
</TransatlanticBarrier>
520
</FxGenericBarrierOptionData>
Listing 400: Multi Asset Generic Barrier Option data (FX Underlyings)

<FxGenericBarrierOptionData>
<Underlyings>
<Underlying>
<Type>FX</Type>
<Name>ECB-EUR-USD</Name>
</Underlying>
<Underlying>
<Type>FX</Type>
<Name>ECB-USD-JPY</Name>
</Underlying>
</Underlyings>
<PayCurrency>USD</PayCurrency>
<OptionData>
<LongShort>Long</LongShort>
<PayoffType>Vanilla</PayoffType>
<OptionType>Call</OptionType>
<ExerciseDates>
<ExerciseDate>2023-06-06</ExerciseDate>
</ExerciseDates>
</OptionData>
<Amount>1500000</Amount>
<SettlementDate>2023-06-08</SettlementDate>
<Barriers>
<ScheduleData>
<Rules>
<StartDate>2021-07-10</StartDate>
<EndDate>2023-06-06</EndDate>
<Tenor>1D</Tenor>
<Calendar>TGT,US</Calendar>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
<BarrierData>
<Type>DownAndOut</Type>
<Levels>
<Level>1.1</Level>
<Level>125</Level>
</Levels>
<Rebate>1000000</Rebate>
<RebateCurrency>USD</RebateCurrency>
<RebatePayTime>atExpiry</RebatePayTime>
</BarrierData>
<BarrierData>
<Type>UpAndIn</Type>
<Levels>
<Level>1.3</Level>
<Level>135</Level>
</Levels>
<Rebate>1000000</Rebate>
<RebateCurrency>USD</RebateCurrency>
<RebatePayTime>atExpiry</RebatePayTime>
</BarrierData>
<KikoType>KoAfterKi</KikoType>
</Barriers>
<TransatlanticBarrier>
<BarrierData>
<Type>UpAndOut</Type>
521
<Levels>
<Level>1.3</Level>
<Level>135</Level>
8.2.74 Best Entry Option
Best Entry Options are defined using one of the trade types FxBestEntryOption,
EquityBestEntryOption, CommodityBestEntryOption depending on the underlying
asset class and an associated node FxBestEntryOptionData,
EquityBestEntryOptionData, CommodityBestEntryOptionData. Listing 401 shows an
example for an Equity Underlying. For a more detailed description of the computation
of the payoff of this option, please see the product description. The nodes have the
following meaning:
• Underlying: The underlying definition. Note that for FX underlyings the order of
the currencies defines the observed underlying value, i.e. for EUR-USD the
domestic currency is USD (the observed value is e.g. 1.2 USD per EUR) while
for USD-EUR the domestic currency is EUR (the observed value is e.g. 0.8 EUR
per USD).
Allowable Values: See 8.3.29
• Currency: The payment currency.
Allowable Values: See Currency in Table 30.
• SettlementDate: The date on which the option payoff is settled. The
SettlementDate is used unadjusted as given.
Allowable Values: any valid date greater or equal to the exercise date.
• Notional: The notional amount.
Allowable Values: any real number
• Strike: The strike value used to compute the payoff of the option. This value
should be provided as a decimal, representing a percentage of the value of
IndexInitial , e.g. a value of K = 0.6 =⇒ 0.6 × IndexInitial in the computation of
the payoff. Allowable Values: any real number
• Multiplier: The payoff multiplier used in the case that the underlying index is
greater than the strike on the settlement date. If omitted defaults to 1.
Allowable Values: any real number
• TriggerLevel: The value that is compared to the underlying index on each strike
observation date to determine if a Trigger Event has occurred. This should be
provided as a decimal, representing a percentage of the value of Strike Index
Level, ie the value of the underlying on the StrikeDate.
Allowable Values: any real number
• LongShort: Denotes whether the payoff is computed relative to the holder or
seller of the option.
Allowable Values: Long, Short.
• Cap: The maximum value of the payoff (before the notional and multiplier are
applied). This value should be interpreted as a percentage and should be in
decimal format in the trade XML, e.g. 0.06 = 6%.

522
 Allowable Values: any real number
• ResetMinimum: The minimum value of IndexInitial in the case that a Trigger
Event has occurred at least once during the option’s lifetime. This should be
provided as a decimal, representing a percentage of the value of Strike Index
Level used in the computation of IndexInitial .
Allowable Value: any real number
• StrikeDate: The date on which the level on the underlying index is used to
compute the payoff, in the case that there has not been a Trigger Event during
the option’s lifetime.
Allowable Value: any valid date before the option expiry date.
• ExpiryDate: The date on which the option expires and the payoff is computed.
Allowable Values: any valid date before the SettlementDate
• Premium: The option premium. Defaults to 0.
Allowable Values: any real number.
• PremiumDate: The date on which the option premium is paid.
Allowable Values: any valid date.
• StrikeObservationDates: The set of dates on which the underlying index level is
observed - the lowest of which is used to compute the option payoff if the
underlying index is greater than the strike on the expiry date.
Allowable Values: any valid dates schedule (see 8.3.4).

523
Listing 401: Best Entry Option data (Equity Underlying)

<EquityBestEntryOptionData>
<LongShort>Long</LongShort>
<Strike>0.85</Strike>
<Cap>0.06</Cap>
<ResetMinimum>0.85</ResetMinimum>
<Notional>1000000</Notional>
<Multiplier>1</Multiplier>
<TriggerLevel>0.95</TriggerLevel>
<SettlementDate>2021-11-20</SettlementDate>
<PremiumDate>2021-11-22</PremiumDate>
<StrikeDate>2020-12-15</StrikeDate>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
</Underlying>
<StrikeObservationDates>
<Dates>
<Dates>
<Date>2021-03-01</Date>
<Date>2021-06-01</Date>
<Date>2021-09-01</Date>
</Dates>
</Dates>
</StrikeObservationDates>
<Currency>USD</Currency>
<Premium>100</Premium>
<ExpiryDate>2021-11-20</ExpiryDate>
</EquityBestEntryOptionData>

8.2.75 Basket Options

Basket Options are represented as traditional trades or scripted trades, refer to
ore/Docs/ScriptedTrade for an introduction of the latter. Each of the supported
variations is represented by a separate payoff script as shown in Table 21.

Basket Option Type Payoff Script Name

Vanilla VanillaBasketOption
Asian AsianBasketOption
Average strike AverageStrikeBasketOption
Lookback call LookbackCallBasketOption
Lookback put LookbackPutBasketOption

Table 21: Basket option types and associated script names.

The supported underlying types are Equity, Fx or Commodity resulting in

corresponding trade types and trade data container names
• EquityBasketOption / EquityBasketOptionData
• FxBasketOption / FxBasketOptionData
• CommodityBasketOption / CommodityBasketOptionData

524
Trade input and the associated payoff script are described in the following for all
supported Basket Option variations.

Vanilla Basket Option

The traditional trade representation is as follows, using an equity underlying in this
example:

<Trade id="VanillaBasketOption#1">
<TradeType>EquityBasketOption</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<EquityBasketOptionData>
<Currency>USD</Currency>
<Notional>1</Notional>
<Strike>5000</Strike>
<Underlyings>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
<Weight>1.0</Weight>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.STOXX50E</Name>
<Currency>EUR</Currency>
<Weight>1.0</Weight>
</Underlying>
</Underlyings>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<PayoffType>Vanilla</PayoffType>
<ExerciseDates>
<ExerciseDate>2020-02-15</ExerciseDate>
</ExerciseDates>
<Premiums> ... </Premiums>
</OptionData>
<Settlement>2020-02-20</Settlement>
</EquityBasketOptionData>
</Trade>

with the following elements:

• Currency: The pay currency. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: all supported currency codes, see Table 32 Currency.
• Notional: The quantity (for equity, commodity underlyings) / foreign amount (fx
underlying)
Allowable values: all positive real numbers
• Strike: The strike of the option
Allowable values: all positive real numbers
• Underlyings: The basket of underlyings.
Allowable values: for each underlying see 8.3.29
• OptionData: relevant are the long/short flag, the call/put flag, the payoff type
(must be set to Vanilla to identify the payoff), and the exercise date (exactly one

525
 date must be given). A Premiums node can be added to represent deterministic
option premia to be paid by the option holder.
Allowable values: see 8.3.1 for the general structure of the option data node
• Settlement: the settlement date (optional, if not given defaults to the exercise
date)
Allowable values: each valid date.
The representation as a scripted trade is as follows:

<Trade id="VanillaBasketOption#1">
<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<VanillaBasketOptionData>
<Expiry type="event">2020-02-15</Expiry>
<Settlement type="event">2020-02-20</Settlement>
<PutCall type="optionType">Call</PutCall>
<LongShort type="longShort">Long</LongShort>
<Notional type="number">1</Notional>
<Strike type="number">5000</Strike>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>
<Weights type="number">
<Value>1.0</Value>
<Value>1.0</Value>
</Weights>
<PayCcy type = "currency">USD</PayCcy>
</VanillaBasketOptionData>
</Trade>

The VanillaBasketOption script referenced in the trade above is shown in Listing 402.

Listing 402: Payoff script for a VanillaBasketOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

NUMBER u, basketPrice, ExerciseProbability, Payoff, currentNotional;

FOR u IN (1, SIZE(Underlyings)) DO

basketPrice = basketPrice + Underlyings[u](Expiry) * Weights[u];
END;

Payoff = max(PutCall * (basketPrice - Strike), 0);

Option = LongShort * Notional * PAY(Payoff, Expiry, Settlement, PayCcy);

IF Payoff > 0 THEN

ExerciseProbability = 1;
END;
currentNotional = Notional * Strike;

The meanings and allowable values of the elements in the VanillaBasketOptionData

node are given below, with data type indicated in square brackets.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [optionType] PutCall: Option type with
Allowable values Call, Put.

526
 • [longShort] LongShort: Position type, Long if we buy, Short if we sell.
Allowable values: Long, Short.
• [number] Notional: Quantity multiplier applied to the basket price
Allowable values: Any positive real number.
• [number] Strike: Strike basket price in PayCcy (see below)
Allowable values: Any positive real number.
• [index] Underlyings: List of underlying indices enclosed by <Value> and
</Value> tags.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] Weights: List of weights applied to the underlying prices in the basket,
given in the same order as the Underlyings above, each weight enclosed by
<Value> and </Value> tags.
Allowable values: Any positive real number.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade. Allowable values: See Table 32 Currency for allowable
currency codes.

Asian Basket Option

The traditional trade representation is as follows, using an equity underlying in this
example:

<Trade id="AsianBasketOption#1">
<TradeType>EquityBasketOption</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<EquityBasketOptionData>
<Currency>USD</Currency>
<Notional>1</Notional>
<Strike>5000</Strike>
<Underlyings>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
<Currency>USD</Currency>
<Weight>1.0</Weight>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.STOXX50E</Name>
<Weight>1.0</Weight>
</Underlying>
</Underlyings>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<PayoffType>Asian</PayoffType>
<ExerciseDates>
<ExerciseDate>2020-02-15</ExerciseDate>
</ExerciseDates>

527
 <Premiums> ... </Premiums>
</OptionData>
<Settlement>2020-02-20</Settlement>
<ObservationDates>
<Rules>
<StartDate>2019-02-06</StartDate>
<EndDate>2020-02-06</EndDate>
<Tenor>1D</Tenor>
<Calendar>US</Calendar>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ObservationDates>
</EquityBasketOptionData>
</Trade>

with the following elements:

• Currency: The pay currency. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: all supported currency codes, see Table 32 Currency.
• Notional: The quantity (for equity, commodity underlyings) / foreign amount (fx
underlying)
Allowable values: all positive real numbers
• Strike: The strike of the option
Allowable values: all positive real numbers
• Underlyings: The basket of underlyings.
Allowable values: for each underlying see 8.3.29
• OptionData: relevant are the long/short flag, the call/put flag, the payoff type
(must be set to Asian to identify the payoff), and the exercise date (exactly one
date must be given). PayoffType2 can be optionally set to Arithmetic or
Geometric and defaults to Arithmetic if not given. Furthermore, a Premiums
node can be added to represent deterministic option premia to be paid by the
option holder.
Allowable values: see 8.3.1 for the general structure of the option data node
• Settlement: the settlement date (optional, if not given defaults to the exercise
date)
Allowable values: each valid date.
• ObservationDates: the observation dates for the asian
Allowable values: See the definition in 8.3.4
The representation as a scripted trade is as follows:

<Trade id="AsianBasketOption#1">
<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<AsianBasketOptionData>
<Expiry type="event">2020-02-15</Expiry>
<Settlement type="event">2020-02-20</Settlement>
<ObservationDates type="event">
<ScheduleData>
<Rules>
<StartDate>2019-02-06</StartDate>
<EndDate>2020-02-06</EndDate>
<Tenor>1D</Tenor>

528
 <Calendar>US</Calendar>
<Convention>F</Convention>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</ObservationDates>
<PutCall type="optionType">Call</PutCall>
<LongShort type="longShort">Long</LongShort>
<Notional type="number">1</Notional>
<Strike type="number">5000</Strike>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>
<Weights type="number">
<Value>1.0</Value>
<Value>1.0</Value>
</Weights>
<PayCcy type="currency">USD</PayCcy>
</AsianBasketOptionData>
</Trade>

The AsianBasketOption script referenced in the trade above is shown in Listing 403.
Listing 403: Payoff script for an AsianBasketOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

NUMBER d, u, basketPrice, ExerciseProbability, Payoff;

NUMBER currentNotional;

FOR d IN (1, SIZE(ObservationDates)) DO

FOR u IN (1, SIZE(Underlyings)) DO
basketPrice = basketPrice + Underlyings[u](ObservationDates[d]) * Weights[u];
END;
END;

basketPrice = basketPrice / SIZE(ObservationDates);

Payoff = max(PutCall * (basketPrice - Strike), 0);

Option = LongShort * Notional * PAY(Payoff, Expiry, Settlement, PayCcy);

IF Payoff > 0 THEN

ExerciseProbability = 1;
END;

currentNotional = Notional * Strike;

The meanings and allowable values of the elements in the AsianBasketOptionData

node are given below, with data type indicated in square brackets.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [event] ObservationDates: Price monitoring schedule.
Allowable values: See section 8.3.4 Schedule Data and Dates, or DerivedSchedule
(see ore/Docs/ScriptedTrade).
• [optionType] PutCall: Option type with
Allowable values Call, Put.
• [longShort] LongShort: Position type, Long if we buy, Short if we sell.

529
 Allowable values: Long, Short.
• [number] Notional: Quantity multiplier applied to the basket price
Allowable values: Any positive real number.
• [number] Strike: Strike basket price in PayCcy (see below)
Allowable values: Any positive real number.
• [index] Underlyings: List of underlying indices enclosed by <Value> and
</Value> tags.
See ore/Docs/ScriptedTrade’s Index Section for allowable values.
• [number] Weights: List of weights applied to the underlying prices in the basket,
given in the same order as the Underlyings above, each weight enclosed by
<Value> and </Value> tags.
Allowable values: Any positive real number.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 Currency for allowable currency codes.

Average Strike Basket Option

The traditional trade representation is as follows, using an equity underlying in this
example:

<Trade id="AverageStrikeBasketOption#1">
<TradeType>EquityBasketOption</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<EquityBasketOptionData>
<Currency>USD</Currency>
<Notional>1</Notional>
<Underlyings>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
<Currency>USD</Currency>
<Weight>1.0</Weight>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.STOXX50E</Name>
<Weight>1.0</Weight>
</Underlying>
</Underlyings>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<PayoffType>AverageStrike</PayoffType>
<ExerciseDates>
<ExerciseDate>2020-02-15</ExerciseDate>
</ExerciseDates>
<Premiums> ... </Premiums>
</OptionData>
<Settlement>2020-02-20</Settlement>
<ObservationDates>

530
 <Rules>
<StartDate>2019-02-06</StartDate>
<EndDate>2020-02-06</EndDate>
<Tenor>1D</Tenor>
<Calendar>US</Calendar>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ObservationDates>
</EquityBasketOptionData>
</Trade>

with the following elements:

• Currency: The pay currency. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: all supported currency codes, see Table 32 Currency.
• Notional: The quantity (for equity, commodity underlyings) / foreign amount (fx
underlying)
Allowable values: all positive real numbers
• Underlyings: The basket of underlyings.
Allowable values: for each underlying see 8.3.29
• OptionData: relevant are the long/short flag, the call/put flag, the payoff type
(must be set to AverageStrike to identify the payoff), and the exercise date
(exactly one date must be given). PayoffType2 can be optionally set to
Arithmetic or Geometric and defaults to Arithmetic if not given. Furthermore, a
Premiums node can be added to represent deterministic option premia to be paid
by the option holder.
Allowable values: see 8.3.1 for the general structure of the option data node
• Settlement: the settlement date (optional, if not given defaults to the exercise
date)
Allowable values: each valid date.
• ObservationDates: the observation dates for the average strike
Allowable values: See the definition in 8.3.4
The representation as a scripted trade is as follows:

<Trade id="AverageStrikeBasketOption#1">
<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<AverageStrikeBasketOptionData>
<Expiry type="event">2020-02-15</Expiry>
<Settlement type="event">2020-02-20</Settlement>
<ObservationDates type="event">
<ScheduleData>
<Rules>
<StartDate>2019-02-06</StartDate>
<EndDate>2020-02-06</EndDate>
<Tenor>1D</Tenor>
<Calendar>US</Calendar>
<Convention>F</Convention>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</ObservationDates>
<PutCall type="optionType">Call</PutCall>

531
 <LongShort type="longShort">Long</LongShort>
<Notional type="number">1</Notional>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>
<Weights type="number">
<Value>1.0</Value>
<Value>1.0</Value>
</Weights>
<PayCcy type="currency">USD</PayCcy>
</AverageStrikeBasketOptionData>
</Trade>

The AverageStrikeBasketOption script referenced in the trade above is shown in

Listing 404.

Listing 404: Payoff script for an AverageStrikeBasketOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

NUMBER d, u, timeAverageBasketPrice, currentNotional;

FOR d IN (1, SIZE(ObservationDates)) DO
FOR u IN (1, SIZE(Underlyings)) DO
timeAverageBasketPrice = timeAverageBasketPrice
+ Underlyings[u](ObservationDates[d]) * Weights[u];
END;
END;
timeAverageBasketPrice = timeAverageBasketPrice / SIZE(ObservationDates);

NUMBER expiryBasketPrice;
FOR u IN (1, SIZE(Underlyings)) DO
expiryBasketPrice = expiryBasketPrice + Underlyings[u](Expiry) * Weights[u];
END;

NUMBER Payoff;
Payoff = max(PutCall * (expiryBasketPrice - timeAverageBasketPrice), 0);

Option = LongShort * Notional * PAY(Payoff, Expiry, Settlement, PayCcy);

NUMBER ExerciseProbability;
IF Payoff > 0 THEN
ExerciseProbability = 1;
END;
FOR u IN (1, SIZE(Underlyings)) DO
currentNotional = currentNotional + Notional * Underlyings[u](ObservationDates[1])
* Weights[u];
END;

The meanings and allowable values of the elements in the

AverageStrikeBasketOptionData node are given below, with data type indicated in
square brackets.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [event] ObservationDates: Price monitoring schedule.
Allowable values: See section 8.3.4 Schedule Data and Dates, or DerivedSchedule
(see ore/Docs/ScriptedTrade).
• [optionType] PutCall: Option type with
Allowable values Call, Put.

532
 • [longShort] LongShort: Position type, Long if we buy, Short if we sell.
Allowable values: Long, Short.
• [number] Notional: Quantity multiplier applied to the basket price
Allowable values: Any positive real number.
• [index] Underlyings: List of underlying indices enclosed by <Value> and
</Value> tags.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] Weights: List of weights applied to the underlying prices in the basket,
given in the same order as the Underlyings above, each weight enclosed by
<Value> and </Value> tags.
Allowable values: Any positive real number.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 Currency for allowable currency codes.

Lookback Call Basket Option

The traditional trade representation is as follows, using an equity underlying in this
example:

<Trade id="LookbackCallBasketOption#1">
<TradeType>EquityBasketOption</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<EquityBasketOptionData>
<Currency>USD</Currency>
<Notional>1</Notional>
<Underlyings>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
<Currency>USD</Currency>
<Weight>1.0</Weight>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.STOXX50E</Name>
<Weight>1.0</Weight>
</Underlying>
</Underlyings>
<OptionData>
<LongShort>Long</LongShort>
<PayoffType>LookbackCall</PayoffType>
<ExerciseDates>
<ExerciseDate>2020-02-15</ExerciseDate>
</ExerciseDates>
<Premiums> ... </Premiums>
</OptionData>
<Settlement>2020-02-20</Settlement>
<ObservationDates>
<Rules>
<StartDate>2019-02-06</StartDate>

533
 <EndDate>2020-02-06</EndDate>
<Tenor>1D</Tenor>
<Calendar>US</Calendar>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ObservationDates>
</EquityBasketOptionData>
</Trade>

with the following elements:

• Currency: The pay currency. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: all supported currency codes, see Table 32 Currency.
• Notional: The quantity (for equity, commodity underlyings) / foreign amount (fx
underlying)
Allowable values: all positive real numbers
• Underlyings: The basket of underlyings.
Allowable values: for each underlying see 8.3.29
• OptionData: relevant are the long/short flag, the payoff type (must be set to
LookbackCall to identify the payoff), and the exercise date (exactly one date
must be given). Furthermore, a Premiums node can be added to represent
deterministic option premia to be paid by the option holder.
Allowable values: see 8.3.1 for the general structure of the option data node
• Settlement: the settlement date (optional, if not given defaults to the exercise
date)
Allowable values: each valid date.
• ObservationDates: the observation dates for the lookback call
Allowable values: See the definition in 8.3.4
The representation as a scripted trade is as follows:

<Trade id="LookbackCallBasketOption#1">
<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<LookbackCallBasketOptionData>
<Expiry type="event">2020-02-15</Expiry>
<Settlement type="event">2020-02-20</Settlement>
<ObservationDates type="event">
<ScheduleData>
<Rules>
<StartDate>2019-02-06</StartDate>
<EndDate>2020-02-06</EndDate>
<Tenor>1D</Tenor>
<Calendar>US</Calendar>
<Convention>F</Convention>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</ObservationDates>
<LongShort type="longShort">Long</LongShort>
<Notional type="number">1</Notional>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>

534
 <Weights type="number">
<Value>1.0</Value>
<Value>1.0</Value>
</Weights>
<PayCcy type="currency">USD</PayCcy>
</LookbackCallBasketOptionData>
</Trade>

The LookbackCallBasketOption script referenced in the trade above is shown in

Listing 405.

Listing 405: Payoff script for a LookbackCallBasketOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

NUMBER d, u, basketPrice, minBasketPrice, currentNotional;

FOR d IN (1, SIZE(ObservationDates)) DO
basketPrice = 0;
FOR u IN (1, SIZE(Underlyings)) DO
basketPrice = basketPrice + Underlyings[u](ObservationDates[d]) * Weights[u];
END;
IF d == 1 THEN
minBasketPrice = basketPrice;
END;
IF basketPrice < minBasketPrice THEN
minBasketPrice = basketPrice;
END;
END;

NUMBER expiryBasketPrice;
FOR u IN (1, SIZE(Underlyings)) DO
expiryBasketPrice = expiryBasketPrice + Underlyings[u](Expiry) * Weights[u];
END;

NUMBER Payoff;
Payoff = max(expiryBasketPrice - minBasketPrice, 0);

Option = LongShort * Notional * PAY(Payoff, Expiry, Settlement, PayCcy);

NUMBER ExerciseProbability;
IF Payoff > 0 THEN
ExerciseProbability = 1;
END;
FOR u IN (1, SIZE(Underlyings)) DO
currentNotional = currentNotional + Notional * Underlyings[u](ObservationDates[1])
* Weights[u];
END;

The meanings and allowable values of the elements in the

LookbackCallBasketOptionData node are given below, with data type indicated in
square brackets.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [event] ObservationDates: Price monitoring schedule.
Allowable values: See section 8.3.4 Schedule Data and Dates, or DerivedSchedule
(see ore/Docs/ScriptedTrade).
• [longShort] LongShort: Position type, Long if we buy, Short if we sell.
Allowable values: Long, Short.

535
 • [number] Notional: Quantity multiplier applied to the basket price
Allowable values: Any positive real number.
• [index] Underlyings: List of underlying indices enclosed by <Value> and
</Value> tags.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] Weights: List of weights applied to the underlying prices in the basket,
given in the same order as the Underlyings above, each weight enclosed by
<Value> and </Value> tags.
Allowable values: Any positive real number.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 Currency for allowable currency codes.

Lookback Put Basket Option

The traditional trade representation is as follows, using an equity underlying in this
example:

<Trade id="LookbackPutBasketOption#1">
<TradeType>EquityBasketOption</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<EquityBasketOptionData>
<Currency>USD</Currency>
<Notional>1</Notional>
<Underlyings>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
<Currency>USD</Currency>
<Weight>1.0</Weight>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.STOXX50E</Name>
<Weight>1.0</Weight>
</Underlying>
</Underlyings>
<OptionData>
<LongShort>Long</LongShort>
<PayoffType>LookbackPut</PayoffType>
<ExerciseDates>
<ExerciseDate>2020-02-15</ExerciseDate>
</ExerciseDates>
<Premiums> ... </Premiums>
</OptionData>
<Settlement>2020-02-20</Settlement>
<ObservationDates>
<Rules>
<StartDate>2019-02-06</StartDate>
<EndDate>2020-02-06</EndDate>
<Tenor>1D</Tenor>
<Calendar>US</Calendar>
<Convention>F</Convention>

536
 <TermConvention>F</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ObservationDates>
</EquityBasketOptionData>
</Trade>

with the following elements:

• Currency: The pay currency. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: all supported currency codes, see Table 32 Currency.
• Notional: The quantity (for equity, commodity underlyings) / foreign amount (fx
underlying)
Allowable values: all positive real numbers
• Underlyings: The basket of underlyings.
Allowable values: for each underlying see 8.3.29
• OptionData: relevant are the long/short flag, the payoff type (must be set to
LookbackPut to identify the payoff), and the exercise date (exactly one date
must be given). Furthermore, a Premiums node can be added to represent
deterministic option premia to be paid by the option holder.
Allowable values: see 8.3.1 for the general structure of the option data node
• Settlement: the settlement date (optional, if not given defaults to the exercise
date)
Allowable values: each valid date.
• ObservationDates: the observation dates for the lookback call
Allowable values: See the definition in 8.3.4
The representation as a scripted trade is as follows:

<Trade id="LookbackPutBasketOption#1">
<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<LookbackPutBasketOptionData>
<Expiry type="event">2020-02-15</Expiry>
<Settlement type="event">2020-02-20</Settlement>
<ObservationDates type="event">
<ScheduleData>
<Rules>
<StartDate>2019-02-06</StartDate>
<EndDate>2020-02-06</EndDate>
<Tenor>1D</Tenor>
<Calendar>US</Calendar>
<Convention>F</Convention>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</ObservationDates>
<LongShort type="longShort">Long</LongShort>
<Notional type="number">1</Notional>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>
<Weights type="number">
<Value>1.0</Value>
<Value>1.0</Value>
</Weights>

537
 <PayCcy type="currency">USD</PayCcy>
</LookbackPutBasketOptionData>
</Trade>

The LookbackCallBasketOption script referenced in the trade above is shown in

Listing 406.

Listing 406: Payoff script for a LookbackPutBasketOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

NUMBER d, u, basketPrice, maxBasketPrice;

FOR d IN (1, SIZE(ObservationDates)) DO
basketPrice = 0;
FOR u IN (1, SIZE(Underlyings)) DO
basketPrice = basketPrice + Underlyings[u](ObservationDates[d]) * Weights[u];
END;
IF d == 1 THEN
maxBasketPrice = basketPrice;
END;
IF basketPrice > maxBasketPrice THEN
maxBasketPrice = basketPrice;
END;
END;

NUMBER expiryBasketPrice, Payoff;

FOR u IN (1, SIZE(Underlyings)) DO
expiryBasketPrice = expiryBasketPrice + Underlyings[u](Expiry) * Weights[u];
END;

Payoff = max(maxBasketPrice - expiryBasketPrice, 0);

Option = LongShort * Notional * LOGPAY(Payoff, Expiry, Settlement, PayCcy);

The meanings and allowable values of the elements in the

LookbackPutBasketOptionData node are given below, with data type indicated in
square brackets.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [event] ObservationDates: Price monitoring schedule.
Allowable values: See section 8.3.4 Schedule Data and Dates, or DerivedSchedule
(see ore/Docs/ScriptedTrade).
• [longShort] LongShort: Position type, Long if we buy, Short if we sell.
Allowable values: Long, Short.
• [number] Notional: Quantity multiplier applied to the basket price
Allowable values: Any positive real number.
• [index] Underlyings: List of underlying indices enclosed by <Value> and
</Value> tags.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] Weights: List of weights applied to the underlying prices in the basket,
given in the same order as the Underlyings above, each weight enclosed by
<Value> and </Value> tags.

538
 Allowable values: Any positive real number.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 Currency for allowable currency codes.

8.2.76 Worst Of Basket Swaps

The FxWorstOfBasketSwap, EquityWorstOfBasketSwap, and
CommodityWorstOfBasketSwap trade types have trade data containers (respectively):
• FxWorstOfBasketSwapData
• EquityWorstOfBasketSwapData
• CommodityWorstOfBasketSwapData
Listing 407 shows the structure of example trades for an Equity underlying.

539
Listing 407: EquityWorstOfBasketSwap data

<Trade id="EQ_WorstOfBasketSwap">
<TradeType>EquityWorstOfBasketSwap</TradeType>
<Envelope>
......
</Envelope>
<EquityWorstOfBasketSwapData>
<LongShort>Long</LongShort>
<Currency>EUR</Currency>
<Quantity>1955000</Quantity>
<Underlyings>
<Underlying>
.......
</Underlying>
</Underlyings>
<InitialPrices>
<InitialPrice>...</InitialPrice>
</InitialPrices>
<FloatingPeriodSchedule>
<Dates>
...
</Dates>
</FloatingPeriodSchedule>
<FixedDeterminationSchedule>
............
</FixedDeterminationSchedule>
<KnockOutDeterminationSchedule>
.............
</KnockOutDeterminationSchedule>
<FloatingPayDates>
<Dates>
....
</Dates>
</FloatingPayDates>
<KnockInDeterminationSchedule>
............
</KnockInDeterminationSchedule>
<FixedPayDates>
............
</FixedPayDates>
<KnockOutLevels>
<KnockOutLevel>...</KnockOutLevel>
</KnockOutLevels>
<FixedTriggerLevels>
<FixedTriggerLevel>...</FixedTriggerLevel>
</FixedTriggerLevels>
<KnockInLevel>0.75</KnockInLevel>
<FixedRate>0.04</FixedRate>
<FixedAccrualSchedule>
<Rules>
...
</Rules>
</FixedAccrualSchedule>
<FloatingIndex>EUR-EURIBOR-3M</FloatingIndex>
<FloatingDayCountFraction>Actual/360</FloatingDayCountFraction>
<FloatingFixingSchedule>
............
</FloatingFixingSchedule>
</EquityWorstOfBasketSwapData>
</Trade>

The net cashflows under a worst of basket swap from the long perspective are:
1. Receive an initial fixed amount: InitialFixedRate ∗ Quantity,
2. At each determination date (if a knock-out has not occurred for any previous
determination date):
• Pay a floating amount: Quantity ∗f loatingRate ∗ accrualF raction,

540
 • If a coupon trigger event occurs for this date, receive a fixed coupon amount
(as well as any other fixed coupon amounts not previously received because
a coupon trigger event had not occurred): Quantity ∗ CouponRate.
If AccumulatingFixedCoupons is True, the coupon amounts are guaranteed
to be paid out, with the amounts scaled relative to the fraction of days
during the accrual period where a coupon trigger event occurs: Quantity ∗
CouponRate ∗triggerAccrualF raction
3. On the final determination date, if
worstP erf ormance < min(Strike, KnockInLevel), pay Quantity
∗(Strike−worstP erf ormance), where worstP erf ormance is the performance,
i.e. ST /S0 , of the worst-performing asset as of the final determination date T .
The meanings and allowable values of elements in the EquityWorstOfBasketSwapData
node follow below.
• Currency: The payout currency for all cashflows. For FX, this should be CCY2 as
defined (see Table 38) in the Name field in the Underlying node. Note that for
(non-quanto) FxWorstOfBasketSwaps, this should be the domestic (CCY2)
currency, as defined in the Name field in the Underlying node. For non-quanto
Equity- and CommodityWorstOfBasketSwaps, this should be currency the equity
or commodity is quoted in. Notice Section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 Currency.
• LongShort: Own party position.
Allowable values: Long, Short
• Quantity: The equity notional amount, or the quantity multiplier.
Allowable values: Any number.
• InitialFixedRate [Optional]: The coupon rate for the initial fixed payment, to
be paid to the Long party.
Allowable values: Any number, as a percentage expressed in decimal form. If left
blank or omitted, defaults to zero.
• InitialFixedPayDate [Optional]: Settlement date for the initial fixed payment.
Allowable values: See Date in Table 30. If left blank or omitted, this defaults to
the first date in the FloatingPayDates schedule.
• Underlyings: The basket of underlyings.
Allowable values: For each underlying, see 8.3.29.
• InitialPrices: The observed price of each underlying in Underlyings.
Allowable values: For each underlying, an InitialPrice sub-node with any
positive number.
• BermudanKnockIn [Optional]: Whether the knock-in event is observed on a
regular basis (True), as defined by the KnockInDeterminationSchedule, or only
at the final date in the FloatingPeriodSchedule (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46. If left blank or omitted, defaults to False.

541
• KnockInLevel: The barrier level used to determine whether a knock-in event has
occurred for the given knock-in observation date/s, upon which the equity
amount is payable at the KnockInPayDate, subject to no knock-out event having
occurred over the life of the contract.
Allowable values: Any number, as a percentage of the initial prices expressed in
decimal form.
• FloatingPeriodSchedule: Period dates used for calculating floating coupon
accrual fractions, and for observing underlying prices for calculating
performances.
Allowable values: See section 8.3.4 Schedule Data and Dates/Rules, or
DerivedSchedule for scripted trades (see the Event data structure in the scripted
trade documentation at ore/Docs/ScriptedTrade).
• FloatingFixingSchedule [Optional]: Fixing dates for floating coupons linked to
Ibor indices. The dth date in this schedule is the fixing date for the (d + 1)th date
in the FloatingPayDates. For floating coupons linked to overnight indices this
scheulde is not relevant, the fixing dates are derived from the
FloatingPeriodScheudle and FloatingLookback.
Allowable values: See section 8.3.4 Schedule Data and Dates/Rules, or
DerivedSchedule for scripted trades (see the Event data structure in
ore/Docs/ScriptedTrade). If left blank or omitted, defaults to a
DerivedSchedule with the FloatingPeriodSchedule set as the base schedule.
• FixedDeterminationSchedule [Optional]: If AccruingFixedCoupons is False,
the observation dates on which a fixed trigger event is evaluated, upon which a
fixed coupon payout is made. Otherwise, there is no payout. If
AccruingFixedCoupons is True, these will be the dates on which fixed coupon
amounts are calculated. The coupon amount is scaled by the number of fixed
trigger days relative to the total number of days in the period.
Allowable values: See section 8.3.4 Schedule Data and Dates/Rules, or
DerivedSchedule for scripted trades (see the Event data structure in
ore/Docs/ScriptedTrade). If left blank or omitted, defaults to a
DerivedSchedule with the FloatingPeriodSchedule set as the base schedule.
• KnockOutDeterminationSchedule [Optional]: Dates on which a knock-out event
is evaluated, after which the instrument is considered to be terminated and no
payout is made.
Allowable values: See section 8.3.4 Schedule Data and Dates/Rules, or
DerivedSchedule for scripted trades (see the Event data structure in
ore/Docs/ScriptedTrade). If left blank or omitted, defaults to a
DerivedSchedule with the FloatingPeriodSchedule set as the base schedule.
• KnockInDeterminationSchedule [Optional]: Observation dates for determining
if a knock-in event has occurred. If BermudanKnockIn is True, this node is
required.
Allowable values: See section 8.3.4 Schedule Data and Dates/Rules, or
DerivedSchedule for scripted trades (see the Event data structure in
ore/Docs/ScriptedTrade).
• FixedAccrualSchedule [Optional]: The fixed coupon paid out for each

542
 determination date in the FixedDeterminationSchedule is scaled according to
the number of days in the FixedAccrualSchedule for which a fixed trigger event
occurred, as a fraction of the total number of days in the period (defined by the
FixedDeterminationSchedule). If AccruingFixedCoupons is True, this node is
required.
Allowable values: See section 8.3.4 Schedule Data and Dates/Rules, or
DerivedSchedule for scripted trades (see the Event data structure in
ore/Docs/ScriptedTrade).
• FloatingPayDates: Floating coupon payment dates.
Allowable values: See section 8.3.4 Schedule Data and Dates, Rules, or
DerivedSchedule (see ore/Docs/ScriptedTrade).
• FixedPayDates [Optional]: Fixed coupon payment dates.
Allowable values: See section 8.3.4 Schedule Data and Dates/Rules, or
DerivedSchedule for scripted trades (see the Event data structure in
ore/Docs/ScriptedTrade). If left blank or omitted, defaults to the
FloatingPayDates.
• KnockInPayDate [Optional]: Settlement date for the knock-in payment, subject
to a knock-in event having been triggered.
Allowable values: See Date in Table 30. If left blank or omitted, this defaults to
the last date in the FloatingPayDates schedule.
• KnockOutLevels: For each determination date in
KnockOutDeterminationSchedule except for the first date, the barrier level used
to determine whether a knock-out trigger event has occurred, resulting in a
knock-out (i.e. contract termination).
Allowable values: For each knock-out determination date, a KnockOutLevel
sub-node with any positive number, as a percentage of the initial prices,
expressed in decimal form.
• FixedTriggerLevels: For each fixed trigger determination date, the barrier level
used to determine whether a coupon trigger event has occurred, upon which a
fixed coupon is paid out at the corresponding payment date.
Allowable values: For each fixed trigger evaluation date, a FixedTriggerLevel
sub-node with any positive number, as a percentage of the initial prices expressed
in decimal form.
• FixedRate: Rate of the fixed coupon leg.
Allowable values: Any number, as a percentage expressed in decimal form.
• AccumulatingFixedCoupons [Optional]: Whether the fixed coupons are
accumulating or not.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46. If left blank or omitted, defaults to False.
• AccruingFixedCoupons [Optional]: Whether the fixed coupons are paid out on
an accrual basis (True), or subject to a single fixed trigger event (given by the
FixedDeterminationSchedule).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46. If left blank or omitted, defaults to False.

543
 • FloatingIndex: Underlying index of the floating leg.
Allowable values: See ore/Docs/ScriptedTrade (section Data Node / Index).
This must be an InterestRate underlying. Overnight indices are not supported.
• FloatingSpread [Optional]: Spread on the floating rate.
Allowable values: Any number. If left blank or omitted, defaults to zero.
• FloatingDayCountFraction: The day count fraction for the floating leg accrual
calculations.
Allowable values: See DayCount Convention in Table 35.
• Strike [Optional]: Strike price for for each underlying in the basket. When
calculating the equity amount, this is the price used to calculate the number of
shares (for Equity underlyings) owing of the worst-performing asset.
Allowable values: Any number, as a percentage of the initial prices, expressed in
decimal form. If left blank or omitted, defaults to one, i.e. the initial price of the
underlying.
• FloatingLookback [Optional]: Only applicable when the floating leg reference
rate is an overnight index. The shift applied to each value date in
FloatingFixingSchedule to obtain the fixing reference date.
Allowable values: Any period definition in unit “Days” (e.g. 2D, 30D, but not
1M ). If omitted or left blank, defaults to 0D.
• FloatingRateCutoff [Optional]: Only applicable when the floating leg reference
rate is an overnight index. The number of fixing dates at the end of the fixing
period for which the fixing value is held constant and set to the previous value.
Allowable values: Any non-negative whole number. If left blank or omitted,
defaults to zero.
• IsAveraged [Optional]: Only applicable when the floating leg reference rate is an
overnight index (where there are multiple fixings over a period). If True, the
average of the fixings is used to calculate the coupon. If False, the coupon is
calculated by compounding the fixings.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46. Defaults to false If left blank or omiited.
• IncludeSpread [Optional]: Only applicable when the floating leg reference rate is
an overnight index and if IsAveraged is false, i.e. the coupon rate is compounded.
If true the spread is included in the compounding, otherwise it is excluded.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
Worst Of Basket Swaps can alternatively be represented as scripted trades, refer to
ore/Docs/ScriptedTrade for an introduction.

<TradeType>ScriptedTrade</TradeType>
<Envelope>
....
</Envelope>
<WorstOfBasketSwapData>
<LongShort type="longShort">Long</LongShort>
<Quantity type="number">1955000</Quantity>
<InitialFixedRate type="number">0.015</InitialFixedRate>
<Underlyings type="index">
<Value>EQ-RIC:.STOXX50E</Value>

544
 <Value>EQ-RIC:.SPX</Value>
</Underlyings>
<InitialPrices type="number">
<Value>3481.44</Value>
<Value>3714.24</Value>
</InitialPrices>
<DeterminationDates type="event">
<ScheduleData>
....
</ScheduleData>
</DeterminationDates>
<SettlementDates type="event">
<ScheduleData>
<Dates>
....
</Dates>
</ScheduleData>
</SettlementDates>
<KnockOutLevels type="number">
<Value>...</Value>
</KnockOutLevels>
<CouponTriggerLevels type="number">
<Value>...</Value>
</CouponTriggerLevels>
<KnockInLevel type="number">0.75</KnockInLevel>
<CouponRate type="number">0.04</CouponRate>
<AccumulatingCoupons type="bool">true</AccumulatingCoupons>
<FloatingIndex type="index">EUR-EURIBOR-3M</FloatingIndex>
<FloatingSpread type="number">0.002</FloatingSpread>
<FloatingDayCountFraction type="dayCounter">Actual/360</FloatingDayCountFraction>
<FixingSchedule type="event">
<DerivedSchedule>
....
</DerivedSchedule>
</FixingSchedule>
<Strike type="number">1.0</Strike>
<PayCcy type="currency">EUR</PayCcy>
</WorstOfBasketSwapData>

The WorstOfBasketSwap script referenced in the trade above is shown in Listing 408.
The net cashflows under a (scripted) worst of basket swap from the long perspective
are:
1. Receive an initial fixed amount: InitialFixedRate ∗ Quantity,
2. At each determination date (if a knock-out has not occurred for any previous
determination date):
• Pay a floating amount: Quantity ∗f loatingRate ∗ accrualF raction,
• If a coupon trigger event occurs for this date, receive a fixed coupon amount
(as well as any other fixed coupon amounts not previously received because
a coupon trigger event had not occurred): Quantity ∗ CouponRate
3. On the final determination date, if
worstP erf ormance < min(Strike, KnockInLevel), pay Quantity
∗(Strike−worstP erf ormance), where worstP erf ormance is the performance,
i.e. ST /S0 , of the worst-performing asset as of the final determination date T .
The meanings and allowable values of the elements in the WorstOfBasketSwap node
below.
• [longShort] LongShort: Own party position.
Allowable values: Long, Short

545
• [number] Quantity: Quantity multiplier, or the equity notional amount.
Allowable values: Any number.
• [number] InitialFixedRate: Rate of the initial fixed payment.
Allowable values: Any number, as a percentage expressed in decimal form.
• [index] Underlyings: The basket of underlyings.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] InitialPrices: The agreed initial price for each underlying in the
basket.
Allowable values: Any positive number. The number of Value sub-nodes should
match the number of underlyings. This must have the same number of entries as
Underlyings.
• [event] DeterminationDates: Floating leg period dates, knock-out determination
dates, and fixed trigger determination dates. The first date is only used for
calculating the floating leg accrual fraction, and corresponds to the contract
effective date.
Allowable values: See Section 8.3.4 ScheduleData, or DerivedSchedule (see
ore/Docs/ScriptedTrade) if derived from SettlementDates or FixingSchedule.
The number of determination dates should match the number of settlement and
fixing dates.
• [event] SettlementDates: The set of settlement dates corresponding to each
determination date. While the first settlement date is unused in the calculations,
this format simplifies the input, e.g. the settlement schedule can be a derived
schedule, with the DeterminationDates as the base schedule.
Allowable values: See section 8.3.4 ScheduleData, or DerivedSchedule (see
ore/Docs/ScriptedTrade) if derived from DeterminationDates or
FixingSchedule. The number of settlement dates should match the number of
determination and fixing dates.
• [number] KnockOutLevels: For each determination date, the barrier level used to
determine whether a knock-out trigger event has occurred, resulting in a
knock-out (i.e. contract termination) at the corresponding settlement date.
Allowable values: Any number, as a percentage of the initial prices expressed in
decimal form. This should have the same number of entries as the number of
dates in DeterminationDates minus one.
• [number] CouponTriggerLevels: For each determination date, the barrier level
used to determine whether a coupon trigger event has occurred, upon which a
fixed coupon is paid out at the corresponding settlement date.
Allowable values: Any number, as a percentage of the initial prices expressed in
decimal form. This should have the same number of entries as the number of
dates in DeterminationDates minus one.
• [number] KnockInLevel: For the final determination date, the barrier level used
to determine whether a knock-in event has occurred, upon which the equity
amount is payable at the final settlement date, subject to no knock-out event
having occurred in the life of the contract.

546
 Allowable values: Any number, as a percentage of the initial price expressed in
decimal form.
• [number] CouponRate: Rate of the fixed coupon leg.
Allowable values: Any number, as a percentage expressed in decimal form.
• [bool] AccumulatingCoupons: Whether the fixed coupons are accumulating or
not.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [index] FloatingIndex: Underlying index of the floating leg.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values. Overnight indices are not supported.
• [number] FloatingSpread: Spread on the floating rate.
Allowable values: Any number.
• [dayCounter] FloatingDayCountFraction: The day count fraction for the
floating leg accrual calculations.
Allowable values: See DayCount Convention in Table 35.
• [event] FixingSchedule: The fixing schedule of the floating leg payments.
Allowable values: See Section 8.3.4 ScheduleData, or DerivedSchedule (see
ore/Docs/ScriptedTrade) if derived from DeterminationDates or
SettlementDates. The number of fixing dates should match the number of
determination and settlement dates.
• [number] Strike: Strike price for each underlying in the basket. When
calculating the equity amount, this is the price used to calculate the number of
shares owing of the worst-performing asset.
Allowable values: Any number, as a percentage of the initial prices, expressed in
decimal form.
• [currency] PayCcy: Settlement currency. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 Currency.

8.2.77 Rainbow Options

Rainbow Options are represented as traditional trades or scripted trades, refer to the
scripted trade documentation in ore/Docs/ScriptedTrade for an introduction of the
latter. Each of the supported variations, all European style, is represented by a
separate payoff script as shown in Table 22 (excluding Rainbow Call Spread Options
and Worst Performance Rainbow Options).

Rainbow Option Payoff Payoff Script Name

max(w1 S1 , . . . , wn Sn , K) BestOfAssetOrCashRainbowOption
min(w1 S1 , . . . , wn Sn , K) WorstOfAssetOrCashRainbowOption
max(ω(max(w1 S1 , . . . , wn Sn ) − K, 0) MaxRainbowOption
max(ω(min(w1 S1 , . . . , wn Sn ) − K, 0) MinRainbowOption

Table 22: Rainbow option types and associated script names.

547
The supported underlying types are Equity, Fx or Commodity resulting in
corresponding trade types and trade data container names
• EquityRainbowOption / EquityRainbowOptionData
• FxRainbowOption / FxRainbowOptionData
• CommodityRainbowOption / CommodityRainbowOptionData
Trade input and the associated payoff script are described in the following for all
supported Rainbow Option variations.

Best Of Asset Or Cash Rainbow Option

The traditional trade representation is as follows, using an equity underlying in this
example:

<Trade id="BestOfAssetOrCashRainbowOption#1">
<TradeType>EquityRainbowOption</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<EquityRainbowOptionData>
<Currency>USD</Currency>
<Notional>1</Notional>
<Strike>2000</Strike>
<Underlyings>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
<Weight>1.0</Weight>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.STOXX50E</Name>
<Currency>EUR</Currency>
<Weight>1.0</Weight>
</Underlying>
</Underlyings>
<OptionData>
<LongShort>Long</LongShort>
<PayoffType>BestOfAssetOrCash</PayoffType>
<ExerciseDates>
<ExerciseDate>2020-02-15</ExerciseDate>
</ExerciseDates>
</OptionData>
<Settlement>2020-02-20</Settlement>
</EquityRainbowOptionData>
</Trade>

with the following elements:

• Currency: The pay currency. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: all supported currency codes, see Table 32 Currency.
• Notional: The quantity (for equity, commodity underlyings) / foreign amount (fx
underlying)
Allowable values: all positive real numbers
• Strike: The strike of the option
Allowable values: all positive real numbers

548
 • Underlyings: The basket of underlyings.
Allowable values: for each underlying see 8.3.29
• OptionData: relevant are the long/short flag, the payoff type (must be set to
BestOfAssetOrCash to identify the payoff), and the exercise date (exactly one
date must be given)
Allowable values: see 8.3.1 for the general structure of the option data node
• Settlement: the settlement date (optional, if not given defaults to the exercise
date)
Allowable values: each valid date.
The representation as a scripted trade is as follows:

<Trade id="BestOfAssetOrCashRainbowOption#1">
<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<BestOfAssetOrCashRainbowOptionData>
<Expiry type="event">2020-02-15</Expiry>
<Settlement type="event">2020-02-20</Settlement>
<LongShort type="longShort">Long</LongShort>
<Notional type="number">1</Notional>
<Strike type="number">2000</Strike>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>
<Weights type="number">
<Value>1.0</Value>
<Value>1.0</Value>
</Weights>
<PayCcy type="currency">USD</PayCcy>
</BestOfAssetOrCashRainbowOptionData>
</Trade>

The BestOfAssetOrCashRainbowOption script referenced in the trade above is shown

in Listing 409.
The meanings and allowable values of the elements in the
BestOfAssetOrCashRainbowOptionData node are given below, with data type
indicated in square brackets.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [longShort] LongShort: Position type, Long if we buy, Short if we sell.
Allowable values: Long, Short.
• [number] Notional: Quantity multiplier applied to the basket price
Allowable values: Any positive real number.
• [number] Strike: Strike price in PayCcy (see below)
Allowable values: Any positive real number.
• [index] Underlyings: List of underlying indices enclosed by <Value> and
</Value> tags.

549
 Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] Weights: List of weights applied to each of the underlying prices, given
in the same order as the Underlyings above, each weighted enclosed by <Value>
and </Value> tags.
Allowable values: Any positive real number.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Worst Of Asset Or Cash Rainbow Option

The traditional trade representation is as follows, using an equity underlying in this
example:

<Trade id="WorstOfAssetOrCashRainbowOption#1">
<TradeType>EquityRainbowOption</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<EquityRainbowOptionData>
<Currency>USD</Currency>
<Notional>1</Notional>
<Strike>2000</Strike>
<Underlyings>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
<Currency>USD</Currency>
<Weight>1.0</Weight>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.STOXX50E</Name>
<Weight>1.0</Weight>
</Underlying>
</Underlyings>
<OptionData>
<LongShort>Long</LongShort>
<PayoffType>WorstOfAssetOrCash</PayoffType>
<ExerciseDates>
<ExerciseDate>2020-02-15</ExerciseDate>
</ExerciseDates>
</OptionData>
<Settlement>2020-02-20</Settlement>
</EquityRainbowOptionData>
</Trade>

with the following elements:

• Currency: The pay currency. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: all supported currency codes, see Table 32 Currency.
• Notional: The quantity (for equity, commodity underlyings) / foreign amount (fx

550
 underlying)
Allowable values: all positive real numbers
• Strike: The strike of the option
Allowable values: all positive real numbers
• Underlyings: The basket of underlyings.
Allowable values: for each underlying see 8.3.29
• OptionData: relevant are the long/short flag, the payoff type (must be set to
WorstOfAssetOrCash to identify the payoff), and the exercise date (exactly one
date must be given)
Allowable values: see 8.3.1 for the general structure of the option data node
• Settlement: the settlement date (optional, if not given defaults to the exercise
date)
Allowable values: each valid date.
The representation as a scripted trade is as follows:

<Trade id="WorstOfAssetOrCashRainbowOption#1">
<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<WorstOfAssetOrCashRainbowOptionData>
<Expiry type="event">2020-02-15</Expiry>
<Settlement type="event">2020-02-20</Settlement>
<LongShort type="longShort">Long</LongShort>
<Notional type="number">1</Notional>
<Strike type="number">2000</Strike>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>
<Weights type="number">
<Value>1.0</Value>
<Value>1.0</Value>
</Weights>
<PayCcy type="currency">USD</PayCcy>
</WorstOfAssetOrCashRainbowOptionData>
</Trade>

The WorstOfAssetOrCashRainbowOption script referenced in the trade above is shown

in Listing 410.
The meanings and allowable values of the elements in the
BestOfAssetOrCashRainbowOptionData node are given below, with data type
indicated in square brackets.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [longShort] LongShort: Position type, Long if we buy, Short if we sell.
Allowable values: Long, Short.
• [number] Notional: Quantity multiplier applied to the basket price
Allowable values: Any positive real number.
• [number] Strike: Strike price in PayCcy (see below)

551
 Allowable values: Any positive real number.
• [index] Underlyings: List of underlying indices enclosed by <Value> and
</Value> tags.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] Weights: List of weights applied to each of the underlying prices, given
in the same order as the Underlyings above, each weighted enclosed by <Value>
and </Value> tags.
Allowable values: Any positive real number.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Put/Call on Max Rainbow Option

The traditional trade representation is as follows, using an equity underlying in this
example:

<Trade id="MaxRainbowOption#1">
<TradeType>EquityRainbowOption</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<EquityRainbowOptionData>
<Currency>USD</Currency>
<Notional>1</Notional>
<Strike>3000</Strike>
<Underlyings>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
<Weight>1.0</Weight>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.STOXX50E</Name>
<Weight>1.0</Weight>
</Underlying>
</Underlyings>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<PayoffType>MaxRainbow</PayoffType>
<ExerciseDates>
<ExerciseDate>2020-02-15</ExerciseDate>
</ExerciseDates>
</OptionData>
<Settlement>2020-02-20</Settlement>
</EquityRainbowOptionData>
</Trade>

with the following elements:

• Currency: The pay currency. Notice section “Payment Currency” in

552
 ore/Docs/ScriptedTrade.
Allowable values: all supported currency codes, see Table 32 Currency.
• Notional: The quantity (for equity, commodity underlyings) / foreign amount (fx
underlying)
Allowable values: all positive real numbers
• Strike: The strike of the option
Allowable values: all positive real numbers
• Underlyings: The basket of underlyings.
Allowable values: for each underlying see 8.3.29
• OptionData: relevant are the long/short flag, the option type, the payoff type
(must be set to MaxRainbow to identify the payoff), and the exercise date
(exactly one date must be given)
Allowable values: see 8.3.1 for the general structure of the option data node
• Settlement: the settlement date (optional, if not given defaults to the exercise
date)
Allowable values: each valid date.
The representation as a scripted trade is as follows:

<Trade id="MaxRainbowOption#1">
<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<MaxRainbowOptionData>
<Expiry type="event">2020-02-15</Expiry>
<Settlement type="event">2020-02-20</Settlement>
<PutCall type="optionType">Call</PutCall>
<LongShort type="longShort">Long</LongShort>
<Notional type="number">1</Notional>
<Strike type="number">3000</Strike>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>
<Weights type="number">
<Value>1.0</Value>
<Value>1.0</Value>
</Weights>
<PayCcy type="currency">USD</PayCcy>
</MaxRainbowOptionData>
</Trade>

The MainRainbowOption script referenced in the trade above is shown in Listing 411.
The meanings and allowable values of the elements in the MaxRainbowOptionData
node are given below, with data type indicated in square brackets.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [optionType] PutCall: Option type with
Allowable values Call, Put.
• [longShort] LongShort: Position type, Long if we buy, Short if we sell.

553
 Allowable values: Long, Short.
• [number] Notional: Quantity multiplier applied to the basket price
Allowable values: Any positive real number.
• [number] Strike: Strike price in PayCcy (see below)
Allowable values: Any positive real number.
• [index] Underlyings: List of underlying indices enclosed by <Value> and
</Value> tags.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] Weights: List of weights applied to each of the underlying prices, given
in the same order as the Underlyings above, each weight enclosed by <Value>
and </Value> tags.
Allowable values: Any positive real number.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Put/Call on Min Rainbow Option

The traditional trade representation is as follows, using an equity underlying in this
example:

<Trade id="MinRainbowOption#1">
<TradeType>EquityRainbowOption</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<EquityRainbowOptionData>
<Currency>USD</Currency>
<Notional>1</Notional>
<Strike>2000</Strike>
<Underlyings>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
<Weight>1.0</Weight>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.STOXX50E</Name>
<Weight>1.0</Weight>
</Underlying>
</Underlyings>
<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<PayoffType>MinRainbow</PayoffType>
<ExerciseDates>
<ExerciseDate>2020-02-15</ExerciseDate>
</ExerciseDates>
</OptionData>
<Settlement>2020-02-20</Settlement>

554
 </EquityRainbowOptionData>
</Trade>

with the following elements:

• Currency: The pay currency. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: all supported currency codes, see Table 32 Currency.
• Notional: The quantity (for equity, commodity underlyings) / foreign amount (fx
underlying)
Allowable values: all positive real numbers
• Strike: The strike of the option
Allowable values: all positive real numbers
• Underlyings: The basket of underlyings.
Allowable values: for each underlying see 8.3.29
• OptionData: relevant are the long/short flag, the option type, the payoff type
(must be set to MaxRainbow to identify the payoff), and the exercise date
(exactly one date must be given)
Allowable values: see 8.3.1 for the general structure of the option data node
• Settlement: the settlement date (optional, if not given defaults to the exercise
date)
Allowable values: each valid date.
The representation as a scripted trade is as follows:

<Trade id="MinRainbowOption#1">
<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<MinRainbowOptionData>
<Expiry type="event">2020-02-15</Expiry>
<Settlement type="event">2020-02-20</Settlement>
<PutCall type="optionType">Call</PutCall>
<LongShort type="longShort">Long</LongShort>
<Notional type="number">1</Notional>
<Strike type="number">2000</Strike>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>
<Weights type="number">
<Value>1.0</Value>
<Value>1.0</Value>
</Weights>
<PayCcy type="currency">USD</PayCcy>
</MinRainbowOptionData>
</Trade>

The MinRainbowOption script referenced in the trade above is shown in Listing 412.
The meanings and allowable values of the elements in the MinRainbowOptionData
node are given below, with data type indicated in square brackets.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.

555
 Allowable values: See Date in Table 30.
• [optionType] PutCall: Option type with
Allowable values Call, Put.
• [longShort] LongShort: Position type, Long if we buy, Short if we sell.
Allowable values: Long, Short.
• [number] Notional: Quantity multiplier applied to the basket price
Allowable values: Any positive real number.
• [number] Strike: Strike price in PayCcy (see below)
Allowable values: Any positive real number.
• [index] Underlyings: List of underlying indices enclosed by <Value> and
</Value> tags.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] Weights: List of weights applied to each of the underlying prices, given
in the same order as the Underlyings above, each weight enclosed by <Value>
and </Value> tags.
Allowable values: Any positive real number.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

European Rainbow Call Spread Option

European rainbow call spread options are represented as scripted trades, refer to the
scripted trade documentation in ore/Docs/ScriptedTrade for an introduction.
Trade input and the payoff script are described below.

<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<EuropeanRainbowCallSpreadOptionData>
<Expiry type="event">2020-02-15</Expiry>
<Settlement type="event">2020-02-20</Settlement>
<LongShort type="longShort">Long</LongShort>
<Notional type="number">1000000</Notional>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>
<InitialStrikes type="number">
<Value>2100</Value>
<Value>3000</Value>
</InitialStrikes>
<Weights type="number">
<Value>0.8</Value>
<Value>0.3</Value>
</Weights>
<Floor type="number">0.02</Floor>
<Cap type="number">0.10</Cap>
<PayCcy type="currency">USD</PayCcy>
</EuropeanRainbowCallSpreadOptionData>

556
The EuropeanRainbowCallSpreadOption script referenced in the trade above is shown
in listing 413.
The meanings and allowable values of the elements in the
EuropeanRainbowCallSpreadOptionData node below.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [longShort] LongShort: long short flag.
Allowable values: Long, Short
• [number] Notional: The notional.
Allowable values: A real number.
• [index] Underlyings: The underlyings.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] InitialStrikes: The initial strikes of the underlyings.
Allowable values: A real number for each underlying.
• [number] Weights: The weights for the best, second best, ..., worst performing
underlying.
Allowable values: A real number for each rank.
• [number] Floor: The floor. If no floor applies, use e.g. -1E10. Allowable values:
A real number.
• [number] Cap: The floor. If no floor applies, use e.g. 1E10. Allowable values: A
real number.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Rainbow Call Spread Barrier Option

A rainbow call spread barrier option is an extension of the European Rainbow Call
Spread Option, and is represented as scripted trades, refer to the scripted trade
documentation in ore/Docs/ScriptedTrade for an introduction.
Trade input and the payoff script are described below.

<TradeType>ScriptedTrade</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>

557
 </Envelope>
<RainbowCallSpreadBarrierOptionData>
<Expiry type="event">2020-02-15</Expiry>
<Settlement type="event">2020-02-20</Settlement>
<LongShort type="longShort">Long</LongShort>
<Notional type="number">1000000</Notional>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>
<InitialPrices type="number">
<Value>2100</Value>
<Value>3000</Value>
</InitialPrices>
<Weights type="number">
<Value>0.8</Value>
<Value>0.3</Value>
</Weights>
<Strike type="number">1.0</Strike>
<Floor type="number">0.02</Floor>
<Cap type="number">0.10</Cap>
<Gearing type="number">1.0</Gearing>
<BermudanBarrier type="bool">false</BermudanBarrier>
<BarrierLevel type="number">1000.0</BarrierLevel>
<BarrierSchedule type="event">
<ScheduleData>
<Rules>
<StartDate>2018-12-31</StartDate>
<EndDate>2020-02-15</EndDate>
<Tenor>1M</Tenor>
<Calendar>USD</Calendar>
<Convention>ModifiedFollowing</Convention>
<TermConvention>ModifiedFollowing</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</BarrierSchedule>
<PayCcy type="currency">USD</PayCcy>
</RainbowCallSpreadBarrierOptionData>

The EuropeanRainbowCallSpreadOption script referenced in the trade above is shown

in listing 414.
The meanings and allowable values of the elements in the
RainbowCallSpreadBarrierOptionData node below.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [longShort] LongShort: long short flag.
Allowable values: Long, Short
• [number] Notional: The notional.
Allowable values: A real number.
• [index] Underlyings: The underlyings.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] InitialPrices: The initial prices of the underlyings.
Allowable values: A real number for each underlying.

558
 • [number] Weights: The weights for the best, second best, ..., worst performing
underlying.
Allowable values: A real number for each rank.
• [number] Strike: The option strike price.
Allowable values: Any number, as a percentage expressed in decimal form.
• [number] Floor: The floor. If no floor applies, use e.g. -1E10.
Allowable values: A real number.
• [number] Cap: The floor. If no floor applies, use e.g. 1E10.
Allowable values: A real number.
• [number] Gearing: The gearing/payoff multiplier, applied after the cap and/or
floor.
Allowable values: A real number.
• [bool] BermudanBarrier: Whether the KI barrier observation is Bermudan
(True) or European (False).
Allowable values: True or False.
• [number] BarrierLevel: The agreed knock-in barrier price level.
Allowable values: Any number.
• [event] BarrierSchedule: If BermudanBarrier is True, this is the barrier
observation schedule. If False, this sub-node is still required but will not be used.
Allowable values: See Section 8.3.4.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 Currency for allowable currency codes.

Asian Rainbow Call Spread Option

Asian rainbow call spread options are represented as scripted trades, refer to the
scripted trade documentation in ore/Docs/ScriptedTrade for an introduction.
Trade input and the payoff script are described below.

<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<AsianRainbowCallSpreadOptionData>
<Expiry type="event">2020-02-15</Expiry>
<AveragingDates type="event">
<ScheduleData>
<Dates>
<Dates>
<Date>2019-01-29</Date>
.....
<Date>2020-02-15</Date>
</Dates>
<Calendar>USD</Calendar>
<Convention>MF</Convention>
</Dates>
</ScheduleData>
</AveragingDates>

559
 <Settlement type="event">2020-02-20</Settlement>
<LongShort type="longShort">Long</LongShort>
<Notional type="number">1000000</Notional>
<Underlyings type="index">
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.STOXX50E</Value>
</Underlyings>
<InitialStrikes type="number">
<Value>2100</Value>
<Value>3000</Value>
</InitialStrikes>
<Weights type="number">
<Value>0.8</Value>
<Value>0.3</Value>
</Weights>
<Floor type="number">0.02</Floor>
<Cap type="number">0.10</Cap>
<PayCcy type="currency">USD</PayCcy>
</AsianRainbowCallSpreadOptionData>

The AsianRainbowCallSpreadOption script referenced in the trade above is shown in

Listing 415.
The meanings and allowable values of the elements in the
AsianRainbowCallSpreadOptionData node below.
• [event] Expiry: Option expiry date.
Allowable values: See Date in Table 30.
• [event] AveragingDates: Observation dates for calculating the final (average)
price of each underlying. Allowable values: See Section 8.3.4.
• [event] Settlement: Option settlement date.
Allowable values: See Date in Table 30.
• [longShort] LongShort: long short flag.
Allowable values: Long, Short
• [number] Notional: The notional.
Allowable values: A real number.
• [index] Underlyings: The underlyings.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] InitialStrikes: The initial strikes of the underlyings.
Allowable values: A real number for each underlying.
• [number] Weights: The weights for the best, second best, ..., worst performing
underlying.
Allowable values: A real number for each rank.
• [number] Floor: The floor. If no floor applies, use e.g. -1E10. Allowable values:
A real number.
• [number] Cap: The floor. If no floor applies, use e.g. 1E10. Allowable values: A
real number.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this

560
 will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Worst Performance Rainbow Option 01

A worst performance rainbow option 01 is represented as a scripted trade, refer to the
scripted trade documentation in ore/Docs/ScriptedTrade for an introduction.
Trade input and the payoff script are described below.

<TradeType>ScriptedTrade</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<WorstPerformanceRainbowOption01Data>
<LongShort type="longShort">Long</LongShort>
<Underlyings type="index">
<Value>EQ-RIC:.STOXX50E</Value>
<Value>EQ-RIC:.SPX</Value>
</Underlyings>
<InitialPrices type="number">
<Value>5455.60</Value>
<Value>500</Value>
</InitialPrices>
<Premium type="number">291264</Premium>
<PremiumDate type="event">2020-03-11</PremiumDate>
<Quantity type="number">72816000</Quantity>
<PayoffMultiplier type="number">0.4625</PayoffMultiplier>
<ObservationDate type="event">2020-09-04</ObservationDate>
<SettlementDate type="event">2020-09-11</SettlementDate>
<PayCcy type="currency">EUR</PayCcy>
</WorstPerformanceRainbowOption01Data>

The WorstPerformanceRainbowOption01 script referenced in the trade above is shown

in listing 416.
The payout formula from the long perspective, determined on the ObservationDate, is

P ayout = Quantity ∗ (worstP erf ormance − 1)

where worstP erf ormance is the performance, i.e. ST /S0 , of the worst-performing
asset as of the final determination date T .
The meanings and allowable values for the WorstPerformanceRainbowOption01Data
node below.
• [longShort] LongShort: Own party position in the option.
Allowable values: Long, Short.
• [index] Underlyings: The basket of underlyings.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] InitialPrices: The agreed initial price for each basket underlying.
Allowable values: Any positive number.

561
 • [number] Premium: Total option premium amount in terms of the PayCcy
Allowable values: See Table 32 Currency.
• [event] PremiumDate: The premium payment date.
Allowable values: See Date in Table 30.
• [number] Quantity: A quantity multiplier applied to the option payoff.
Allowable values: Any number.
• [number] PayoffMultiplier: A factor that is multiplied to the option payoff
when the option buyer incurs a negative net cash flow, i.e. when the performance
of the worst-performing asset is less than 1.
Allowable values: Any number, as a percentage expressed in decimal form.
• [event] ObservationDate: The date on which the final levels of the assets are
determined.
Allowable values: See Date in Table 30.
• [event] SettlementDate: The settlement date for the option payoff.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Worst Performance Rainbow Option 02

A worst performance rainbow option 02 is represented as a scripted trade, refer to the
scripted trade documentation in ore/Docs/ScriptedTrade for an introduction.
Trade input and the payoff script are described below.

<TradeType>ScriptedTrade</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<WorstPerformanceRainbowOption02Data>
<LongShort type="longShort">Long</LongShort>
<Underlyings type="index">
<Value>EQ-RIC:.STOXX50E</Value>
<Value>EQ-RIC:.SPX</Value>
</Underlyings>
<InitialPrices type="number">
<Value>4890.00</Value>
<Value>108.84</Value>
</InitialPrices>
<Premium type="number">1731</Premium>
<PremiumDate type="event">2020-02-27</PremiumDate>
<Quantity type="number">90000000</Quantity>
<PayoffMultiplier type="number">1.7</PayoffMultiplier>
<Floor type="number">-0.05</Floor>
<ObservationDate type="event">2020-11-13</ObservationDate>
<SettlementDate type="event">2020-11-27</SettlementDate>
<PayCcy type="currency">USD</PayCcy>
</WorstPerformanceRainbowOption02Data>

562
The WorstPerformanceRainbowOption02 script referenced in the trade above is shown
in listing 417.
The payout formula from the long perspective, determined on the ObservationDate, is
as follows, where worstP erf ormance is the performance, i.e. ST /S0 , of the
worst-performing asset as of the final determination date T :
If worstP erf ormance > 1, receive

P ayout = Quantity ∗ PayoffMultiplier ∗ (worstP erf ormance − 1).

If worstP erf ormance ≤ 1, pay

P ayout = Quantity ∗ max(Floor, worstP erf ormance − 1)

The meanings and allowable values for the WorstPerformanceRainbowOption02Data

node below.
• [longShort] LongShort: Own party position in the option.
Allowable values: Long, Short.
• [index] Underlyings: The basket of underlyings.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] InitialPrices: The agreed initial price for each basket underlying.
Allowable values: Any positive number.
• [number] Premium: Total option premium amount in terms of the PayCcy
Allowable values: See Table 32 Currency.
• [event] PremiumDate: The premium payment date.
Allowable values: See Date in Table 30.
• [number] Quantity: A quantity multiplier applied to the option payoff.
Allowable values: Any number.
• [number] PayoffMultiplier: A factor that is multiplied to the option payoff
when the option buyer incurs a positive net cash flow, i.e. when the performance
of the worst-performing asset is greater than 1.
Allowable values: Any number, as a percentage expressed in decimal form.
• [number] Floor: The maximum loss that the option buyer can incur.
Allowable values: Any non-positive number, as a percentage expressed in decimal
form.
• [event] ObservationDate: The date on which the final levels of the assets are
determined.
Allowable values: See Date in Table 30.
• [event] SettlementDate: The settlement date for the option payoff.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.

563
 If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 Currency for allowable currency codes.

Worst Performance Rainbow Option 03

A worst performance rainbow option 03 is an extension of the Worst Performance
Rainbow Option 01, and is represented as a scripted trade, refer to the scripted trade
documentation in ore/Docs/ScriptedTrade for an introduction.
Trade input and the payoff script are described below.

<TradeType>ScriptedTrade</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<WorstPerformanceRainbowOption03Data>
<LongShort type="longShort">Long</LongShort>
<Underlyings type="index">
<Value>EQ-RIC:.STOXX50E</Value>
<Value>EQ-RIC:.SPX</Value>
</Underlyings>
<InitialPrices type="number">
<Value>5455.60</Value>
<Value>500</Value>
</InitialPrices>
<Premium type="number">291264</Premium>
<PremiumDate type="event">2020-03-11</PremiumDate>
<Strike type="number">1.0</Strike>
<Quantity type="number">72816</Quantity>
<PayoffMultiplier type="number">2.5</PayoffMultiplier>
<Cap type="number">100.0</Cap>
<Floor type="number">-100.0</Floor>
<BermudanBarrier type="bool">false</BermudanBarrier>
<BarrierLevel type="number">0.7</BarrierLevel>
<BarrierSchedule type="event">
<ScheduleData>
<Rules>
<StartDate>2020-03-11</StartDate>
<EndDate>2020-09-04</EndDate>
<Tenor>1D</Tenor>
<Calendar>USD</Calendar>
<Convention>ModifiedFollowing</Convention>
<TermConvention>ModifiedFollowing</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</BarrierSchedule>
<ObservationDate type="event">2020-09-04</ObservationDate>
<SettlementDate type="event">2020-09-11</SettlementDate>
<PayCcy type="currency">EUR</PayCcy>
</WorstPerformanceRainbowOption03Data>

The WorstPerformanceRainbowOption03 script referenced in the trade above is shown

in listing 418.
The payout formula from the long perspective, determined on the ObservationDate, is
as follows, where worstP erf ormance is the performance, i.e. ST /S0 , of the
worst-performing asset as of the final determination date T :

564
If worstP erf ormance ≥ Strike, receive


P ayout = Quantity ∗ min Cap, max(Floor, worstP erf ormance − Strike) .

If worstP erf ormance < Strike, pay

P ayout = Quantity∗PayoffMultiplier∗min Cap, max(Floor, worstP erf ormance−Strike) .

The above payouts are conteningent on a knock-in event. If no knock-in has occurred,
the payout is zero.
The meanings and allowable values for the WorstPerformanceRainbowOption03Data
node below.
• [longShort] LongShort: Own party position in the option.
Allowable values: Long, Short.
• [index] Underlyings: The basket of underlyings.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] InitialPrices: The agreed initial price for each basket underlying.
Allowable values: Any positive number.
• [number] Premium: Total option premium amount in terms of the PayCcy
Allowable values: See Table 32 Currency.
• [event] PremiumDate: The premium payment date.
Allowable values: See Date in Table 30.
• [number] Strike: The option strike price.
Allowable values: Any number, as a percentage expressed in decimal form.
• [number] Quantity: A quantity multiplier applied to the option payoff.
Allowable values: Any number.
• [number] PayoffMultiplier: A factor that is multiplied to the option payoff
when the option buyer incurs a positive net cash flow, i.e. when the performance
of the worst-performing asset is greater than 1.
Allowable values: Any number, as a percentage expressed in decimal form.
• [number] Cap: The maximum profit that the option buyer can receive.
Allowable values: Any number, as a percentage expressed in decimal form.
• [number] Floor: The maximum loss that the option buyer can incur.
Allowable values: Any number, as a percentage expressed in decimal form.
• [bool] BermudanBarrier: Whether the KI barrier observation is Bermudan
(True) or European (False).
Allowable values: True or False.
• [number] BarrierLevel: The agreed knock-in barrier price level. For example, in
the case of a Bermudan barrier, if a knock-in is set to occur when one of the
underlying prices falls below 70% of its initial price, then the appropriate value is
0.7, as in the sample trade input above.

565
 Allowable values: Any number, as a percentage of the InitialPrices expressed
in decimal form.
• [event] BarrierSchedule: If BermudanBarrier is True, this is the barrier
observation schedule. If False, this sub-node is still required but will not be used.
Allowable values: See Section 8.3.4.
• [event] ObservationDate: The date on which the final levels of the assets are
determined.
Allowable values: See Date in Table 30.
• [event] SettlementDate: The settlement date for the option payoff.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Worst Performance Rainbow Option 04

A worst performance rainbow option 04 is represented as a scripted trade, refer to the
scripted trade documentation in ore/Docs/ScriptedTrade for an introduction.
Trade input and the payoff script are described below.

<TradeType>ScriptedTrade</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<WorstPerformanceRainbowOption04Data>
<LongShort type="longShort">Long</LongShort>
<Underlyings type="index">
<Value>EQ-RIC:.STOXX50E</Value>
<Value>EQ-RIC:.SPX</Value>
</Underlyings>
<InitialPrices type="number">
<Value>5455.60</Value>
<Value>500</Value>
</InitialPrices>
<Premium type="number">291264</Premium>
<PremiumDate type="event">2020-03-11</PremiumDate>
<Strike type="number">1.0</Strike>
<Quantity type="number">72816</Quantity>
<PayoffMultiplier type="number">2.5</PayoffMultiplier>
<Cap type="number">100.0</Cap>
<Floor type="number">-100.0</Floor>
<BermudanBarrier type="bool">false</BermudanBarrier>
<BarrierLevel type="number">0.7</BarrierLevel>
<BarrierSchedule type="event">
<ScheduleData>
<Rules>
<StartDate>2020-03-11</StartDate>
<EndDate>2020-09-04</EndDate>
<Tenor>1D</Tenor>
<Calendar>USD</Calendar>
<Convention>ModifiedFollowing</Convention>
<TermConvention>ModifiedFollowing</TermConvention>
<Rule>Forward</Rule>
</Rules>

566
 </ScheduleData>
</BarrierSchedule>
<ObservationDate type="event">2020-09-04</ObservationDate>
<SettlementDate type="event">2020-09-11</SettlementDate>
<PayCcy type="currency">EUR</PayCcy>
</WorstPerformanceRainbowOption04Data>

The WorstPerformanceRainbowOption04 script referenced in the trade above is shown

in listing 419.
The payout formula, determined on the ObservationDate, is as follows, where
worstP erf ormance is the performance, i.e. ST /S0 , of the worst-performing asset as of
the final determination date T :
If a knock-in event was triggered:

P ayout = Quantity ∗ (worstP erf ormance − Strike).

If no knock-in event was triggered:



P ayout = Quantity∗min Cap, max Floor, PayoffMultiplier∗(worstP erf ormance−Strike) .

From the long perspective, the above amounts are received if they are positive, and
paid out from the short perspective.
The meanings and allowable values for the WorstPerformanceRainbowOption04Data
node below.
• [longShort] LongShort: Own party position in the option.
Allowable values: Long, Short.
• [index] Underlyings: The basket of underlyings.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] InitialPrices: The agreed initial price for each basket underlying.
Allowable values: Any positive number.
• [number] Premium: Total option premium amount in terms of the PayCcy
Allowable values: See Table 32 Currency.
• [event] PremiumDate: The premium payment date.
Allowable values: See Date in Table 30.
• [number] Strike: The option strike price.
Allowable values: Any number, as a percentage expressed in decimal form.
• [number] Quantity: A quantity multiplier applied to the option payoff.
Allowable values: Any number.
• [number] PayoffMultiplier: A factor that is multiplied to the option payoff
when no knock-in event has ocurred. This multiplier is applied before the cap
and/or floor. Allowable values: Any number, as a percentage expressed in
decimal form.

567
 • [number] Cap: The maximum profit that the option buyer can receive when a
knock-in event has occurred.
Allowable values: Any number, as a percentage expressed in decimal form.
• [number] Floor: The maximum loss that the option buyer can incur when a
knock-in event has occurred.
Allowable values: Any number, as a percentage expressed in decimal form.
• [bool] BermudanBarrier: Whether the KI barrier observation is Bermudan
(True) or European (False).
Allowable values: True or False.
• [number] BarrierLevel: The agreed knock-in barrier price level. For example, in
the case of a Bermudan barrier, if a knock-in is set to occur when one of the
underlying prices falls below 70% of its initial price, then the appropriate value is
0.7, as in the sample trade input above.
Allowable values: Any number, as a percentage of the InitialPrices expressed
in decimal form.
• [event] BarrierSchedule: If BermudanBarrier is True, this is the barrier
observation schedule. If False, this sub-node is still required but will not be used.
Allowable values: See Section 8.3.4.
• [event] ObservationDate: The date on which the final levels of the assets are
determined.
Allowable values: See Date in Table 30.
• [event] SettlementDate: The settlement date for the option payoff.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Worst Performance Rainbow Option 05

A worst performance rainbow option 05 is represented as a scripted trade, refer to the
scripted trade documentation in ore/Docs/ScriptedTrade for an introduction.
Trade input and the payoff script are described below.

<TradeType>ScriptedTrade</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<WorstPerformanceRainbowOption05Data>
<LongShort type="longShort">Long</LongShort>
<PutCall type="optionType">Put</PutCall>
<Underlyings type="index">
<Value>EQ-RIC:.STOXX50E</Value>
<Value>EQ-RIC:.SPX</Value>
</Underlyings>

568
 <InitialPrices type="number">
<Value>5455.60</Value>
<Value>500</Value>
</InitialPrices>
<Premium type="number">291264</Premium>
<PremiumDate type="event">2020-03-11</PremiumDate>
<Strike type="number">1.0</Strike>
<Quantity type="number">72816</Quantity>
<BarrierType type="barrierType">DownIn</BarrierType>
<BarrierLevel type="number">0.6</BarrierLevel>
<ObservationDate type="event">2020-09-04</ObservationDate>
<SettlementDate type="event">2020-09-11</SettlementDate>
<PayCcy type="currency">EUR</PayCcy>
</WorstPerformanceRainbowOption05Data>

The WorstPerformanceRainbowOption05 script referenced in the trade above is shown

in listing 420.
The payout formula, determined on the ObservationDate, is as follows, where
worstP erf ormance is the performance, i.e. ST /S0 , of the worst-performing asset as of
the final determination date T . The payout for a long put option is as follows:
If a knock-in event was triggered,


P ayout = Quantity ∗ max Strike − worstP erf ormance , 0 .

Otherwise, the payoff is zero.

The meanings and allowable values for the WorstPerformanceRainbowOption05Data
node below.
• [longShort] LongShort: Own party position in the option.
Allowable values: Long, Short.
• [optionType] PutCall: Option type. For FX, this should be Call if we buy CCY1
and sell CCY2, Put if we buy CCY2 and sell CCY1 (where the Underlying is in the
form FX-SOURCE-CCY1-CCY2).
• [index] Underlyings: The basket of underlyings.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] InitialPrices: The agreed initial price for each basket underlying.
Allowable values: Any positive number.
• [number] Premium: Total option premium amount in terms of the PayCcy
Allowable values: See Table 32 Currency.
• [event] PremiumDate: The premium payment date.
Allowable values: See Date in Table 30.
• [number] Strike: The option strike price.
Allowable values: Any number, as a percentage expressed in decimal form.
• [number] Quantity: A quantity multiplier applied to the option payoff.
Allowable values: Any number.

569
 • [barrierType] BarrierType: The knock-in barrier type. For trades with no
barrier, set BarrierType to UpIn and BarrierLevel to zero (or any negative
number).
Allowable values: DownIn, UpIn.
• [number] BarrierLevel: The agreed European knock-in barrier level.
Allowable values: Any number, as a percentage of the InitialPrices expressed
in decimal form.
• [event] ObservationDate: The date on which the final levels of the assets are
determined.
Allowable values: See Date in Table 30.
• [event] SettlementDate: The settlement date for the option payoff.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

8.2.78 Exotic Variance and Volatility Derivatives

Exotic variance/volatility swaps and options are represented as scripted trades, refer to
the scripted trade documentation in ore/Docs/ScriptedTrade for an introduction. Each
of the supported variations and their payoff script name are shown in Table 23. All
swaps have an optional cap/floor feature.

Variance/Volatility Product Variation Payoff Script Name

Variance/Volatility Option VarianceOption
Variance/Volatility Swap with KI/KO Barrier KIKOVarianceSwap
Corridor Volatility/Variance Swap CorridorVarianceSwap
Corridor Variance Swap with KI/KO Barrier KIKOCorridorVarianceSwap
ConditionalVarianceSwap01
Conditional Variance/Volatility Swap
ConditionalVarianceSwap02
Pairwise Variance Swap PairwiseVarianceSwap
Variance Dispersion Swap VarianceDispersionSwap
Corridor Variance Dispersion Swap CorridorVarianceDispersionSwap
Corridor Variance Dispersion Swap with KO Barrier KOCorridorVarianceDispersionSwap
Gamma Swap GammaSwap
Basket Variance Swap BasketVarianceSwap

Table 23: Exotic variance/volatility product types and associated script names.

Trade input and the associated payoff script are described in the following for all
supported variations.

570
Variance Option
The traditional trade representation is as follows, using an EQ underlying in this
example:

<Trade id="EQ_VarianceOption">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
.....
</Envelope>
<VarianceOptionData>
<LongShort type="longShort">Long</LongShort>
<PutCall type="optionType">Call</PutCall>
<PremiumAmount type="number">0</PremiumAmount>
<PremiumDate type="event">2020-11-26</PremiumDate>
<Notional type="number">138000</Notional>
<VarianceReference type="number">0.19</VarianceReference>
<Strike type="number">0.19</Strike>
<Underlying type="index">EQ-RIC:.SPX</Underlying>
<ValuationSchedule type="event">
<ScheduleData>
<Rules>
<StartDate>2020-11-26</StartDate>
<EndDate>2021-09-18</EndDate>
<Tenor>1D</Tenor>
<Convention>Following</Convention>
<TermConvention>Following</TermConvention>
<Calendar>USA</Calendar>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</ValuationSchedule>
<SquaredPayoff type="bool">true</SquaredPayoff>
<SettlementDate type="event">2021-09-22</SettlementDate>
<PayCcy type="currency">USD</PayCcy>
</VarianceOptionData>
</Trade>

The VarianceOption script referenced in the trade above is shown in listing 421
The payout formulas for a variance put and call option are:

Notional
P utP ayof f = 1002 ∗ ∗ max[Strike − RealisedVariance, 0],
2 ∗ 100 ∗ VarianceReference
Notional
CallP ayof f = 1002 ∗ ∗ max[Strike − RealisedVariance, 0].
2 ∗ 100 ∗ VarianceReference
The meanings and allowable values for the VarianceOptionData node below.
• [longShort] LongShort: Own party position in the option. Long corresponds to
paying out on the fixed/strike variance (volatility) and receiving on the
floating/realised variance (volatility). In other words, a long position has positive
value if the realised variance (volatility) exceeds the variance (volatility) strike.
Allowable values: Long, Short.
• [optionType] PutCall: Option type. For FX, this should be Call if we buy CCY1
and sell CCY2, Put if we buy CCY2 and sell CCY1 (where the Underlying is in the
form FX-SOURCE-CCY1-CCY2).
Allowable values: Put, Call
• [number] PremiumAmount: The total option premium amount. Allowable values:
Any non-negativenumber.

571
 • [event] PremiumDate: The option premium payment date. Allowable values: See
Date in Table 30.
• [number] Notional: The vega notional amount. If the option was struck in terms
of a variance notional Nvar , the corresponding vega notional is given by
Nvol = Nvar · 2 · 100 · Kvol (where Kvol is in absolute terms).
Allowable values: Any non-negative number.
• [number] Strike: The volatility strike Kvol quoted in absolute terms. If the
option was struck in terms of variance, the square root of that variance should be
used here.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• [number] VarianceReference: The parameter used to convert the vega notional
amount into the corresponding variance amount. Similar to the Strike, this
should be quoted in absolute terms, e.g. if the (volatility) strike price is 20% and
the variance reference is 32.4%, then the Strike is 0.20 and the
VarianceReference should be 0.324.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• [index] Underlying: Underlying index.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [event] ValuationSchedule: The schedule defining the (daily) observation period
for the variance accrual.
Allowable values: See Section 8.3.4.
• [bool] SquaredPayoff: Flag indicating whether the trade is a variance option
(True) or a volatility option (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [event] SettlementDate: The date on which the option payoff is settled.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Variance Swap with KI/KO Barrier

The traditional trade representation is as follows, using an FX underlying in this
example:

<Trade id="FX_VarianceSwap_KIKO">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
.....

572
 </Envelope>
<KIKOVarianceSwapData>
<LongShort type="longShort">Long</LongShort>
<Strike type="number">0.02</Strike>
<Notional type="number">50000</Notional>
<Underlying type="index">FX-ECB-EUR-USD</Underlying>
<ValuationSchedule type="event">
<ScheduleData>
<Rules>
<StartDate>2018-12-31</StartDate>
<EndDate>2019-05-05</EndDate>
<Tenor>1D</Tenor>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Calendar>US</Calendar>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</ValuationSchedule>
<SquaredPayoff type="bool">true</SquaredPayoff>
<BarrierType type="barrierType">UpIn</BarrierType>
<BarrierLevel type="number">0</BarrierLevel>
<Cap type="number">2.5</Cap>
<Floor type="number">0</Floor>
<SettlementDate type="event">2019-05-06</SettlementDate>
<PayCcy type="currency">USD</PayCcy>
</KIKOVarianceSwapData>
</Trade>

The KIKOVarianceSwap script referenced in the trade above is shown in listing 422
The payout formula when no knock-out has occurred is:

h i
P ayout = 1002 ∗varianceAmount∗ min max(realisedV ariance2 , Floor), Cap −Strike2 .

If a knock-out has occurred, the above amount is scaled by the number of days
between the first variance accrual date and the date of knock-out, as a fraction of the
total number of variance accrual dates.
The meanings and allowable values for the KIKOVarianceSwapData node below.
• [longShort] LongShort: Own party position in the swap. Long corresponds to
paying out on the fixed/strike variance (volatility) and receiving on the
floating/realised variance (volatility). In other words, a long position has positive
value if the realised variance (volatility) exceeds the variance (volatility) strike.
Allowable values: Long, Short.
• [number] Strike: The volatility strike Kvol of the variance swap quoted in
absolute terms. If the swap was struck in terms of variance, the square root of
that variance should be used here.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• [number] Notional: The vega notional amount. If the swap was struck in terms
of a variance notional Nvar , the corresponding vega notional is given by
Nvol = Nvar · 2 · 100 · Kvol (where Kvol is in absolute terms).
Allowable values: Any non-negative number.
• [index] Underlying: Underlying index.

573
 Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [event] ValuationSchedule: The schedule defining the (daily) observation period
for the variance accrual.
Allowable values: See Section 8.3.4.
• [bool] SquaredPayoff: Flag indicating whether the trade is a variance swap
(True) or a volatility swap (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [barrierType] BarrierType: Whether the barrier is a knock-in (DownIn or UpIn)
or a knock-out (DownOut or UpOut) barrier. For trades with no barrier, which is
equivalent to a capped/floored variance swap, set BarrierType to UpIn and
BarrierLevel to zero, as in the sample trade representation above.
Allowable values: DownIn, UpIn, DownOut, UpOut.
• [number] BarrierLevel: The agreed knock-in/knock-out barrier price level.
Allowable values: Any non-negative real number.
• [number] Cap: The cap on the realised variance (or volatility), as a factor of the
Strike. For example, if Cap is 2.5, then the cap level will be 2.52 × Strike2 for
variance swaps, and 2.5 × Strike for volatility swaps. For trades with no cap, set
Cap to zero.
Allowable values: Any non-negative number.
• [number] Floor: The floor on the realised variance (or volatility), as a factor of
the Strike. For example, if Floor is 0.1, then the floor level will be
0.12 × Strike for variance swaps, and 0.1 × Strike for volatility swaps. For
trades with no floor, set Floor to zero.
Allowable values: Any non-negative number.
• [event] SettlementDate: The date on which the swap payoff is settled.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Corridor Variance Swap

The traditional trade representation is as follows, using an FX underlying in this
example:

<Trade id="FX_VarianceSwap_Corridor">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
.....
</Envelope>
<CorridorVarianceSwapData>
<LongShort type="longShort">Long</LongShort>

574
 <Strike type="number">0.02</Strike>
<Notional type="number">50000</Notional>
<Underlying type="index">FX-ECB-EUR-USD</Underlying>
<ValuationSchedule type="event">
<ScheduleData>
<Rules>
<StartDate>2018-12-31</StartDate>
<EndDate>2019-05-05</EndDate>
<Tenor>1D</Tenor>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Calendar>US</Calendar>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</ValuationSchedule>
<SquaredPayoff type="bool">true</SquaredPayoff>
<UpperBarrierLevel type="number">1000000000</UpperBarrierLevel>
<LowerBarrierLevel type="number">0</LowerBarrierLevel>
<CountBothObservations type="bool">true</CountBothObservations>
<AccrualAdjustment type="bool">false</AccrualAdjustment>
<Cap type="number">2.5</Cap>
<Floor type="number">0</Floor>
<SettlementDate type="event">2019-05-06</SettlementDate>
<PayCcy type="currency">USD</PayCcy>
</CorridorVarianceSwapData>
</Trade>

The CorridorVarianceSwap script referenced in the trade above is shown in listing 423
The payout formula is:

h i
2 2 2


P ayout = 100 ∗varianceAmount∗ min max(realisedV ariance , Floor), Cap −Strike ,

where the realisedV ariance only consists of variance accrual contributions for when
the underlying price/level was trading within the window defined by the corridor.
The meanings and allowable values for the CorridorVarianceSwapData node below.
• [longShort] LongShort: Own party position in the swap. Long corresponds to
paying out on the fixed/strike variance (volatility) and receiving on the
floating/realised variance (volatility). In other words, a long position has positive
value if the realised variance (volatility) exceeds the variance (volatility) strike.
Allowable values: Long, Short.
• [number] Strike: The volatility strike Kvol of the variance swap quoted in
absolute terms. If the swap was struck in terms of variance, the square root of
that variance should be used here.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• [number] Notional: The vega notional amount. If the swap was struck in terms
of a variance notional Nvar , the corresponding vega notional is given by
Nvol = Nvar · 2 · 100 · Kvol (where Kvol is in absolute terms).
Allowable values: Any non-negative number.
• [index] Underlying: Underlying index.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.

575
• [event] ValuationSchedule: The schedule defining the (daily) observation period
for the variance accrual.
Allowable values: See Section 8.3.4.
• [bool] SquaredPayoff: Flag indicating whether the trade is a variance swap
(True) or a volatility swap (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [number] UpperBarrierLevel: The agreed upper barrier price level.
Allowable values: Any non-negative real number.
• [number] LowerBarrierLevel: The agreed lower barrier price level.
Allowable values: Any non-negative real number.
• [bool] CountBothObservations: Whether the variance/volatility is accrued
based on both the current and previous underlying prices falling within the
corridor (True) or only on the previous underlying price (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [bool] AccrualAdjustment: Whether the strike will be scaled relative to the
number of days that the underlying traded within the corridor. See K e var (for
variance swaps) and K e vol (for volatility swaps) in section Capped/Floored
Corridor Variance Swap of the Product Description for Exotic Variance and
Volatility Swaps. Allowable values: Boolean node, allowing Y, N, 1, 0, true, false,
etc.
• [number] Cap: The cap on the realised variance (or volatility), as a factor of the
Strike after the accrual adjustment is applied (only when AccrualAdjustment
is True). For example, if Cap is 2.5, then the cap level will be 2.52 × K
e var for
variance swaps, and 2.5 × Ke vol for volatility swaps. For trades with no cap, set
Cap to zero.
Allowable values: Any non-negative number.
• [number] Floor: The floor on the realised variance (or volatility), as a factor of
the Strike after the accrual adjustment is applied (only when
AccrualAdjustment is True). For example, if Floor is 0.1, then the floor level
will be 0.12 × K
e var for variance swaps, and 0.1 × K
e var for volatility swaps. For
trades with no floor, set Floor to zero.
Allowable values: Any non-negative number. The full set of allowable values is
given in Table 46.
• [event] SettlementDate: The date on which the swap payoff is settled.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

576
Corridor Variance Swap with KI/KO Barrier
The traditional trade representation is as follows, using an EQ underlying in this
example:

<Trade id="EQ_VarianceSwap_KIKO_Corridor">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
.....
</Envelope>
<KIKOCorridorVarianceSwapData>
<LongShort type="longShort">Long</LongShort>
<Strike type="number">0.19</Strike>
<Notional type="number">1380</Notional>
<Underlying type="index">EQ-RIC:.SPX</Underlying>
<ValuationSchedule type="event">
<ScheduleData>
<Rules>
<StartDate>2020-11-26</StartDate>
<EndDate>2021-09-18</EndDate>
<Tenor>1D</Tenor>
<Convention>Following</Convention>
<TermConvention>Following</TermConvention>
<Calendar>USA</Calendar>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</ValuationSchedule>
<CorridorUpperBarrierLevel type="number">3469.18</CorridorUpperBarrierLevel>
<CorridorLowerBarrierLevel type="number">2207.66</CorridorLowerBarrierLevel>
<KIKOBarrierType type="barrierType">UpOut</KIKOBarrierType>
<KIKOBarrierLevel type="number">3469.18</KIKOBarrierLevel>
<CountBothObservations type="bool">true</CountBothObservations>
<AccrualAdjustment type="bool">true</AccrualAdjustment>
<Cap type="number">0</Cap>
<Floor type="number">0</Floor>
<SettlementSchedule type="event">
<DerivedSchedule>
<BaseSchedule>ValuationSchedule</BaseSchedule>
<Shift>2D</Shift>
<Calendar>USA</Calendar>
<Convention>Following</Convention>
</DerivedSchedule>
</SettlementSchedule>
<PayCcy type="currency">USD</PayCcy>
</KIKOCorridorVarianceSwapData>
</Trade>

The KIKOCorridorVarianceSwap script referenced in the trade above is shown in

listing 422
The meanings and allowable values for the KIKOCorridorVarianceSwapData node
below.
• [longShort] LongShort: Own party position in the swap. Long corresponds to
paying out on the fixed/strike variance and receiving on the floating/realised
variance. In other words, a long position has positive value if the realised
variance exceeds the variance strike.
Allowable values: Long, Short.
• [number] Strike: The volatility strike Kvol of the variance swap quoted in
absolute terms. If the swap was struck in terms of variance, the square root of
that variance should be used here.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.

577
• [number] Notional: The vega notional amount. If the swap was struck in terms
of a variance notional Nvar , the corresponding vega notional is given by
Nvol = Nvar · 2 · 100 · Kvol (where Kvol is in absolute terms).
Allowable values: Any non-negative number.
• [index] Underlying: Underlying index. Currently only EQ, FX and COMM
underlyings are supported.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [event] ValuationSchedule: The schedule defining the (daily) observation period
for the variance accrual.
Allowable values: See Section 8.3.4.
• [number] CorridorUpperBarrierLevel: The agreed upper barrier price level for
the corridor.
Allowable values: Any non-negative real number.
• [number] CorridorLowerBarrierLevel: The agreed lower barrier price level for
the corridor.
Allowable values: Any non-negative real number.
• [barrierType] KIKOBarrierType: Whether the barrier is a knock-in (DownIn or
UpIn) or a knock-out (DownOut or UpOut) barrier. For trades with no barrier,
which is equivalent to a capped/floored corridor variance swap, set
KIKOBarrierType to UpIn and KIKOBarrierLevel to zero, as in the sample
trade representation above.
Allowable values: DownIn, UpIn, DownOut, UpOut.
• [number] KIKOBarrierLevel: The agreed knock-in/knock-out barrier price level.
Allowable values: Any non-negative real number.
• [bool] CountBothObservations: Whether the variance is accrued based on both
the current and previous underlying prices falling within the corridor (True) or
only on the previous underlying price (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [bool] AccrualAdjustment: Whether the strike will be scaled relative to the
number of days that the underlying traded within the corridor. See K
e var in
section Capped/Floored Corridor Variance Swap of the Product Description for
Exotic Variance and Volatility Swaps. Allowable values: Boolean node, allowing
Y, N, 1, 0, true, false, etc.
• [number] Cap: The cap on the realised variance, as a factor of the Strike. For
example, if Cap is 2.5, then the cap level will be 2.52 × Strike2 . For trades with
no cap, set Cap to zero.
Allowable values: Any non-negative number.
• [number] Floor: The floor on the realised variance, as a factor of the Strike.
For example, if Floor is 0.1, then the floor level will be 0.12 × Strike. For trades
with no floor, set Floor to zero.
Allowable values: Any non-negative number.

578
 • [event] SettlementSchedule: The settlement dates derived from the
ValuationSchedule using a settlement lag to reflect settlement after a
knock-out event, or after the final variance observation date if no knock-out
occurs. If the barrier is knock-in, this represents the settlement date, which is the
final valuation date plus the settlement lag.
Allowable values: See section 8.3.4 Schedule Data and Dates, or DerivedSchedule
(see the scripted trade documentation in ore/Docs/ScriptedTrade).
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Conditional Variance Swap 01

The traditional trade representation is as follows, using an FX underlying in this
example:

<Trade id="FX_VarianceSwap_Conditional_01">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
.....
</Envelope>
<ConditionalVarianceSwap01Data>
<LongShort type="longShort">Long</LongShort>
<Strike type="number">0.02</Strike>
<Notional type="number">50000</Notional>
<Underlying type="index">FX-ECB-EUR-USD</Underlying>
<ValuationSchedule type="event">
<ScheduleData>
<Rules>
<StartDate>2018-12-31</StartDate>
<EndDate>2019-05-05</EndDate>
<Tenor>1D</Tenor>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Calendar>US</Calendar>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</ValuationSchedule>
<SquaredPayoff type="bool">true</SquaredPayoff>
<BarrierType type="barrierType">UpIn</BarrierType>
<BarrierLevel type="number">0</BarrierLevel>
<CountBothObservations type="bool">true</CountBothObservations>
<Cap type="number">2.5</Cap>
<Floor type="number">0</Floor>
<AccrualAdjustment type="bool">false</AccrualAdjustment>
<SettlementDate type="event">2019-05-06</SettlementDate>
<PayCcy type="currency">USD</PayCcy>
</ConditionalVarianceSwap01Data>
</Trade>

The ConditionalVarianceSwap01 script referenced in the trade above is shown in listing

425
The payout formula is:
h i
P ayout = 1002 ∗varianceAmount∗ min max(realisedV ariance2 , Floor), Cap −Strike2 ,

579
where the realisedV ariance only consists of variance accrual contributions for when
the underlying price/level was trading within the pre-defined window.
The meanings and allowable values for the ConditionalVarianceSwapData01 node
below.
• [longShort] LongShort: Own party position in the swap. Long corresponds to
paying out on the fixed/strike variance (volatility) and receiving on the
floating/realised variance (volatility). In other words, a long position has positive
value if the realised variance (volatility) exceeds the variance (volatility) strike.
Allowable values: Long, Short.
• [number] Strike: The volatility strike Kvol of the variance swap quoted in
absolute terms. If the swap was struck in terms of variance, the square root of
that variance should be used here.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• [number] Notional: The vega notional amount. If the swap was struck in terms
of a variance notional Nvar , the corresponding vega notional is given by
Nvol = Nvar · 2 · 100 · Kvol (where Kvol is in absolute terms).
Allowable values: Any non-negative number.
• [index] Underlying: Underlying index.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [event] ValuationSchedule: The schedule defining the (daily) observation period
for the variance accrual.
Allowable values: See Section 8.3.4.
• [bool] SquaredPayoff: Flag indicating whether the trade is a variance swap
(True) or a volatility swap (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [barrierType] BarrierType: Whether the instrument is an up-variance swap
(UpIn or DownOut) or a down-variance swap (DownIn or UpOut).
Allowable values: DownIn, UpIn, DownOut, UpOut.
• [number] BarrierLevel: The agreed barrier price level.
Allowable values: Any non-negative real number.
• [bool] CountBothObservations: Whether the variance/volatility is accrued
based on both the current and previous underlying prices falling within the range
(True) or only on the previous underlying price (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [bool] AccrualAdjustment: Whether the strike will be scaled relative to the
number of days that the underlying traded within the range. See K e var (for
variance swaps) and Kvol (for volatility swaps) in section Capped/Floored
e
Conditional Variance Swap of the Product Description for Exotic Variance and

580
 Volatility Swaps. Allowable values: Boolean node, allowing Y, N, 1, 0, true, false,
etc.
• [number] Cap: The cap on the realised variance (or volatility), as a factor of the
Strike after the accrual adjustment is applied (only when AccrualAdjustment
is True). For example, if Cap is 2.5, then the cap level will be 2.52 × K
e var for
variance swaps, and 2.5 × Ke vol for volatility swaps. For trades with no cap, set
Cap to zero.
Allowable values: Any non-negative number.
• [number] Floor: The floor on the realised variance (or volatility), as a factor of
the Strike after the accrual adjustment is applied (only when
AccrualAdjustment is True). For example, if Floor is 0.1, then the floor level
will be 0.12 × K
e var for variance swaps, and 0.1 × K
e var for volatility swaps. For
trades with no floor, set Floor to zero.
Allowable values: Any non-negative number. The full set of allowable values is
given in Table 46.
• [event] SettlementDate: The date on which the swap payoff is settled.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Conditional Variance Swap 02

The traditional trade representation is as follows, using an FX underlying in this
example:

<Trade id="FX_VarianceSwap_Conditional_02">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
.....
</Envelope>
<ConditionalVarianceSwap02Data>
<LongShort type="longShort">Long</LongShort>
<Strike type="number">0.02</Strike>
<Notional type="number">50000</Notional>
<VarianceReference type="number">0.03</VarianceReference>
<Underlying type="index">FX-ECB-EUR-USD</Underlying>
<ValuationSchedule type="event">
<ScheduleData>
<Rules>
<StartDate>2018-12-31</StartDate>
<EndDate>2019-05-05</EndDate>
<Tenor>1D</Tenor>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Calendar>US</Calendar>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</ValuationSchedule>
<SquaredPayoff type="bool">true</SquaredPayoff>
<BarrierType type="barrierType">UpIn</BarrierType>
<BarrierLevel type="number">0</BarrierLevel>

581
 <CountBothObservations type="bool">true</CountBothObservations>
<Cap type="number">2.5</Cap>
<Floor type="number">0</Floor>
<AccrualAdjustment type="bool">false</AccrualAdjustment>
<SettlementDate type="event">2019-05-06</SettlementDate>
<PayCcy type="currency">USD</PayCcy>
</ConditionalVarianceSwap02Data>
</Trade>

The ConditionalVarianceSwap02 script referenced in the trade above is shown in listing

426
The payout formula is:
h i
P ayout = 1002 ∗varianceAmount∗ min max(realisedV ariance2 , Floor), Cap −Strike2 ,

where the realisedV ariance only consists of variance accrual contributions for when
the underlying price/level was trading within the pre-defined window, and the
“variance strike” used to obtain the varianceAmount is given by the variance reference
strike (instead of the actual strike).
The meanings and allowable values for the ConditionalVarianceSwapData02 node
below.
• [longShort] LongShort: Own party position in the swap. Long corresponds to
paying out on the fixed/strike variance (volatility) and receiving on the
floating/realised variance (volatility). In other words, a long position has positive
value if the realised variance (volatility) exceeds the variance (volatility) strike.
Allowable values: Long, Short.
• [number] Strike: The volatility strike Kvol of the variance swap quoted in
absolute terms. If the swap was struck in terms of variance, the square root of
that variance should be used here.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• [number] Notional: The vega notional amount. If the swap was struck in terms
of a variance notional Nvar , the corresponding vega notional is given by
Nvol = Nvar · 2 · 100 · Kvol (where Kvol is in absolute terms).
Allowable values: Any non-negative number.
• [number] VarianceReference: The (volatility) strike value used (in place of the
actual strike) to scale down the vega notional in order to obtain the variance
amount. If the swap was struck in terms of variance, the square root of that
variance should be used here.
Allowable values: Any non-negative number.
• [index] Underlying: Underlying index.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [event] ValuationSchedule: The schedule defining the (daily) observation period
for the variance accrual.
Allowable values: See Section 8.3.4.

582
• [bool] SquaredPayoff: Flag indicating whether the trade is a variance swap
(True) or a volatility swap (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [barrierType] BarrierType: Whether the instrument is an up-variance swap
(UpIn or DownOut) or a down-variance swap (DownIn or UpOut).
Allowable values: DownIn, UpIn, DownOut, UpOut.
• [number] BarrierLevel: The agreed barrier price level.
Allowable values: Any non-negative real number.
• [bool] CountBothObservations: Whether the variance/volatility is accrued
based on both the current and previous underlying prices falling within the range
(True) or only on the previous underlying price (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [bool] AccrualAdjustment: Whether the strike will be scaled relative to the
number of days that the underlying traded within the range. See K e var (for
variance swaps) and K e vol (for volatility swaps) in section Capped/Floored
Conditional Variance Swap of the Product Description for Exotic Variance and
Volatility Swaps. Allowable values: Boolean node, allowing Y, N, 1, 0, true, false,
etc.
• [number] Cap: The cap on the realised variance (or volatility), as a factor of the
Strike after the accrual adjustment is applied (only when AccrualAdjustment
is True). For example, if Cap is 2.5, then the cap level will be 2.52 × K
e var for
variance swaps, and 2.5 × Ke vol for volatility swaps. For trades with no cap, set
Cap to zero.
Allowable values: Any non-negative number.
• [number] Floor: The floor on the realised variance (or volatility), as a factor of
the Strike after the accrual adjustment is applied (only when
AccrualAdjustment is True). For example, if Floor is 0.1, then the floor level
will be 0.12 × K
e var for variance swaps, and 0.1 × K
e var for volatility swaps. For
trades with no floor, set Floor to zero.
Allowable values: Any non-negative number. The full set of allowable values is
given in Table 46.
• [event] SettlementDate: The date on which the swap payoff is settled.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

583
Pairwise Variance Swap
The FxPairwiseVarianceSwap and EquityPairwiseVarianceSwap trade types have
trade data containers (respectively):
• FxPairwiseVarianceSwapData
• EquityPairwiseVarianceSwapData
Listing 427 shows the structure of example trades for an Equity underlying.

Listing 427: EquityPairwiseVarianceSwap data

<Trade id="EQ_VarianceSwap_Pairwise">
<TradeType>EquityPairwiseVarianceSwap</TradeType>
<Envelope>
.......
</Envelope>
<EquityPairwiseVarianceSwapData>
<LongShort>Long</LongShort>
<Underlyings>
<Value>EQ-RIC:.STOXX50E</Value>
<Value>EQ-RIC:.SPX</Value>
</Underlyings>
<UnderlyingStrikes>
<Value>0.33859119894055129</Value>
<Value>0.39039467209479178</Value>
</UnderlyingStrikes>
<UnderlyingNotionals>
<Value>577.75847822419905</Value>
<Value>603.54235516510619</Value>
</UnderlyingNotionals>
<BasketNotional>1339.2898822637151</BasketNotional>
<BasketStrike>0.31612972020991642</BasketStrike>
<ValuationSchedule>
<Rules>
.......
</Rules>
</ValuationSchedule>
<LaggedValuationSchedule>
<Derived>
.......
</Derived>
</LaggedValuationSchedule>
<AccrualLag>3</AccrualLag>
<PayoffLimit>5</PayoffLimit>
<Cap>2.5</Cap>
<Floor>0</Floor>
<SettlementDate>2022-06-29</SettlementDate>
<PayCcy>USD</PayCcy>
</EquityPairwiseVarianceSwapData>
</Trade>

The payout formula is:


P ayout = min max(equityAmount1+equityAmount2+equityAmountBasket, LowerLimit), U pperLi

where

U pperLimit = PayoffLimit ∗ |notional1| + |notional2|


LowerLimit = − PayoffLimit ∗ |notional1| + |notional2|

584
The meanings and allowable values of elements in the
EquityPairwiseVarianceSwapData node follow below.
• LongShort: Own party position.
Allowable values: Long, Short
• Underlyings: The basket of underlyings.
Allowable values: The format follows that of a scripted trade underlying. See the
scripted trade documentation in ore/Docs/ScriptedTrade (section Data Node /
Index) for allowable values.
• UnderlyingStrikes: The volatility strikes Kvol
1,2
of the underlyings quoted in
absolute terms. If the swap was struck in terms of variance, the square roots of
the variances should be used here.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• UnderlyingNotionals: The vega notional amount. If the swap was struck in
terms of variance notionals Nvar , the corresponding vega notionals are given by
1,2
Nvol 1,2
= Nvar 1,2
· 2 · 100 · Kvol (where Kvol
1,2
is in absolute terms).
Allowable values: Any non-negative number.
• BasketNotional: The basket vega notional amount.
Allowable values: Any non-negative number.
• ValuationSchedule: The start dates of the variance accrual schedule. This node
can also be used to derive the variance accrual schedule (or vice versa) using a
DerivedSchedule (e.g. with a two-day lag, -2D). For the standard accrual period
lengths of one day, set Shift to -1D.
Allowable values: See Section 8.3.4. If this uses a DerivedSchedule, the Shift
must be less than or equal to -1D.
• LaggedValuationSchedule: The end dates of the variance accrual schedule.
This node can be derived from the ValuationSchedule (or vice versa) using a
DerivedSchedule (e.g. with a two-day lag, 2D). For the standard accrual period
lengths of one day, set Shift to 1D.
Allowable values: See section 8.3.4. If this uses a DerivedSchedule, the Shift
must be greater than or equal to 1D. If left blank or omitted, defaults to a
derived schedule, with Shift equal to 1D.
• AccrualLag: The length (in days) of each variance accrual period. For classic
variance swaps, set this to 1.
Allowable values: Any integer greater than or equal to 1. If left blank or omitted,
defaults to 1.
• PayoffLimit: The factor used to determine the maximum/minimum payoff
under the swap. This corresponds to C in the final equation in the Product
Description for Pairwise Variance Swap.
Allowable values: Any non-negative number. If left blank or omitted, defaults to
zero, i.e. no payoff limit.
• Cap: The cap on the realised variances, as a factor of the corresponding strikes.
For example, if Cap is 2.5, then the cap level will be 2.52 × K̂var for the basket

585
 realised variance. For trades with no cap, set Cap to zero.
Allowable values: Any non-negative number.
• Floor: The floor on the realised variances, as a factor of the corresponding
strikes. For example, if Floor is 0.1, then the floor level will be 0.12 × K̂var for
the basket realised variance. For trades with no floor, set Floor to zero.
Allowable values: Any non-negative number.
• SettlementDate: The date on which the swap payoff is settled.
Allowable values: See Date in Table 30.
• PayCcy: The settlement currency.
Allowable values: See Table 32 Currency.
Pairwise variance swaps can alternatively be represented as scripted trades, refer to the
scripted trade documentation in ore/Docs/ScriptedTrade for an introduction.

<Trade id="EQ_VarianceSwap_Pairwise">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
.....
</Envelope>
<PairwiseVarianceSwapData>
<LongShort type="longShort">Long</LongShort>
<Underlyings type="index">
<Value>EQ-RIC:.STOXX50E</Value>
<Value>EQ-RIC:.SPX</Value>
</Underlyings>
<UnderlyingStrikes type="number">
<Value>0.3385911989405513</Value>
<Value>0.3903946720947918</Value>
</UnderlyingStrikes>
<UnderlyingNotionals type="number">
<Value>577.7584782241991</Value>
<Value>603.5423551651062</Value>
</UnderlyingNotionals>
<BasketNotional type="number">1339.289882263715</BasketNotional>
<BasketStrike type="number">0.3161297202099164</BasketStrike>
<ValuationSchedule type="event">
<ScheduleData>
<Rules>
<StartDate>2021-06-25</StartDate>
<EndDate>2022-06-25</EndDate>
<Tenor>3D</Tenor>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Calendar>US</Calendar>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>
</ValuationSchedule>
<LaggedValuationSchedule type="event">
<DerivedSchedule>
<BaseSchedule>ValuationSchedule</BaseSchedule>
<Shift>2D</Shift>
<Calendar>US</Calendar>
<Convention>F</Convention>
</DerivedSchedule>
</LaggedValuationSchedule>
<AccrualLag type="number">3</AccrualLag>
<PayoffLimit type="number">5</PayoffLimit>
<Cap type="number">2.5</Cap>
<Floor type="number">0</Floor>
<SettlementDate type="event">2022-06-29</SettlementDate>
<PayCcy type="currency">USD</PayCcy>
</PairwiseVarianceSwapData>
</Trade>

586
The PairwiseVarianceSwap script referenced in the trade above is shown in listing 428
The meanings and allowable values for the PairwiseVarianceSwapData node below.
• [longShort] LongShort: Own party position in the swap. Long corresponds to
paying out on the fixed/strike variance (volatility) and receiving on the
floating/realised variance (volatility). In other words, a long position has positive
value if the realised variance (volatility) exceeds the variance (volatility) strike.
Allowable values: Long, Short.
• [number] UnderlyingStrikes: The volatility strikes Kvol1,2
of the underlyings
quoted in absolute terms. If the swap was struck in terms of variance, the square
roots of the variances should be used here.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• [number] UnderlyingNotionals: The vega notional amount. If the swap was
struck in terms of variance notionals Nvar , the corresponding vega notionals are
given by Nvol
1,2 1,2
= Nvar 1,2
· 2 · 100 · Kvol (where Kvol
1,2
is in absolute terms).
Allowable values: Any non-negative number.
• [index] Underlyings: Underlying index.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] BasketStrike: The basket volatility strike K̂vol quoted in absolute
terms.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• [number] BasketNotional: The basket vega notional amount.
Allowable values: Any non-negative number.
• [event] ValuationSchedule: The base schedule which defines the start dates of
the variance accrual schedule. This node is also used to derive the variance
accrual schedule.
Allowable values: See Section 8.3.4.
• [event] LaggedValuationSchedule: The end dates of the variance accrual
schedule. This can be derived from the Schedule using a DerivedSchedule (e.g.
with a two-day lag, 2D). For the standard accrual period lengths of one day, set
Shift to 1D.
Allowable values: See section 8.3.4 Schedule Data and Dates, or DerivedSchedule
(see the scripted trade documentation in ore/Docs/ScriptedTrade).
• [number] AccrualLag: The length (in days) of each variance accrual period. For
classic variance swaps with no lag, set this to 1.
Allowable values: Any integer greater than or equal to 1.
• [number] PayoffLimit: The factor used to determine the maximum/minimum
payoff under the swap. This corresponds to C in the final equation in the
Product Description for Pairwise Variance Swap.
Allowable values: Any non-negative number.

587
 • [number] Cap: The cap on the realised variances, as a factor of the corresponding
strikes. For example, if Cap is 2.5, then the cap level will be 2.52 × K̂var for the
basket realised variance. For trades with no cap, set Cap to zero.
Allowable values: Any non-negative number.
• [number] Floor: The floor on the realised variances, as a factor of the
corresponding strikes. For example, if Floor is 0.1, then the floor level will be
0.12 × K̂var for the basket realised variance. For trades with no floor, set Floor
to zero.
Allowable values: Any non-negative number.
• [event] SettlementDate: The date on which the swap payoff is settled.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Variance Dispersion Swap

The traditional trade representation is as follows, using EQ underlyings in this
example:

<Trade id="EQ_VarianceDispersionSwap">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
.....
</Envelope>
<VarianceDispersionSwapData>
<LongShort type="longShort">Long</LongShort>
<Underlyings1 type="index">
<Value>EQ-RIC:HSBA.L</Value>
<Value>EQ-RIC:[Link]</Value>
<Value>EQ-RIC:AMZN.O</Value>
</Underlyings1>
<Weights1 type="number">
.....
</Weights1>
<Strikes1 type="number">
.....
</Strikes1>
<Spreads1 type="number">
.....
</Spreads1>
<Notionals1 type="number">
.....
</Notionals1>
<Caps1 type="number">
.....
</Caps1>
<Floors1 type="number">
.....
</Floors1>
<Underlyings2 type="index">
<Value>EQ-RIC:.STOXX50E</Value>
<Value>EQ-RIC:.SPX</Value>
</Underlyings2>
<Weights2 type="number">
.....
</Weights2>

588
 <Strikes2 type="number">
.....
</Strikes2>
<Spreads2 type="number">
.....
</Spreads2>
<Notionals2 type="number">
.....
</Notionals2>
<Caps2 type="number">
.....
</Caps2>
<Floors2 type="number">
.....
</Floors2>
<ValuationSchedule type="event">
<ScheduleData>
.....
</ScheduleData>
</ValuationSchedule>
<DividendAdjustment type="bool">false</DividendAdjustment>
<SettlementDate type="event">2021-01-10</SettlementDate>
<PayCcy type="currency">USD</PayCcy>
</VarianceDispersionSwapData>
</Trade>

The VarianceDispersionSwap script referenced in the trade above is shown in listing

429
The meanings and allowable values for the VarianceDispersionSwapData node below.
• [longShort] LongShort: Own party position in the swap. Long corresponds to
selling volatility on the Underlyings1 basket and buying volatility on
Underlyings2.
Allowable values: Long, Short.
• [index] Underlyings1: The basket of underlyings whose volatility is bought in
the Long position.
Allowable values: For each underlying, see 8.3.29.
• [number] Weights1: List of weights applied to the final realised volatility of each
underlying in the Underlyings1 basket.
Allowable values: Any positive number.
• [number] Strikes1: The volatility strike K1,u,vol of the variance swap for each
underlying u in the Underlyings1 basket, quoted in absolute terms. If the swap
was struck in terms of variance, the square root of that variance should be used
here.
Allowable values: Any positive number, as a percentage expressed in decimal
form.
• [number] Spreads1: Additional spread to the realised variance, for each
underlying in the Underlyings1 basket.
Allowable values: Any real number.
• [number] Notionals1: For each underlying u in the Underlyings1 basket, the
vega notional amount. If the swap was struck in terms of variance notionals
N1,u,var , the corresponding vega notionals are given by
N1,u,vol = N1,u,var · 2 · 100 · K1,u,vol (where K1,u,vol is in absolute terms).
Allowable values: Any real number.

589
• [number] Caps1: For each underlying u in the Underlyings1 basket, the cap on
the realised variance as a factor of the strike. For example, if the value in Caps1
is 2.5, then the cap level will be 2.52 × K1,u,var . For underlyings with no cap, set
the value in Caps1 to zero.
Allowable values: Any non-negative number.
• [number] Floors1: For each underlying u in the Underlyings1 basket, the floor
on the realised variance as a factor of the strike. For example, if the value in
Floors1 is 0.1, then the floor level will be 0.12 × K1,u,var . For underlyings with
no floor, set the value in Floors1 to zero.
Allowable values: Any non-negative number.
• [index] Underlyings2: The basket of underlyings whose volatility is sold in the
Long position.
Allowable values: For each underlying, see 8.3.29.
• [number] Weights2: List of weights applied to the final realised volatility of each
underlying in the Underlyings2 basket.
Allowable values: Any positive number.
• [number] Strikes2: The volatility strike K2,u,vol of the variance swap for each
underlying u in the Underlyings2 basket, quoted in absolute terms. If the swap
was struck in terms of variance, the square root of that variance should be used
here.
Allowable values: Any positive number, as a percentage expressed in decimal
form.
• [number] Spreads2: Additional spread to the realised variance, for each
underlying in the Underlyings2 basket.
Allowable values: Any real number.
• [number] Notionals2: For each underlying u in the Underlyings2 basket, the
vega notional amount. If the swap was struck in terms of variance notionals
N2,u,var , the corresponding vega notionals are given by
N2,u,vol = N2,u,var · 2 · 100 · K2,u,vol (where K2,u,vol is in absolute terms).
Allowable values: Any real number.
• [number] Caps2: For each underlying u in the Underlyings2 basket, the cap on
the realised variance as a factor of the strike. For example, if the value in Caps2
is 2.5, then the cap level will be 2.52 × K2,u,var . For underlyings with no cap, set
the value in Caps2 to zero.
Allowable values: Any non-negative number.
• [number] Floors2: For each underlying u in the Underlyings2 basket, the floor
on the realised variance as a factor of the strike. For example, if the value in
Floors2 is 0.1, then the floor level will be 0.12 × K2,u,var . For underlyings with
no floor, set the value in Floors2 to zero.
Allowable values: Any non-negative number.
• [bool] DividendAdjustment: Whether or not the underlying price is adjusted for
dividend payments. This feature is not yet supported. Allowable values: Boolean
node, allowing Y, N, 1, 0, true, false, etc. The full set of allowable values is given
in Table 46.

590
 • [event] ValuationSchedule: The schedule defining the (daily) observation period
for the variance accrual.
Allowable values: See Section 8.3.4.
• [event] SettlementDate: The date on which the swap payoff is settled.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Corridor Variance Dispersion Swap

This instrument is a variance dispersion swap with a corridor feature, where variance is
accrued only when the the price of the first underlying of each pair of underlyings
(between the first and second basket) falls within the ‘corridor’. This means that the
number of underlyings in each basket should be the same, and each pair is determined
based on the order that they are provided in the trade XML, as in the example below.
The traditional trade representation is as follows, using EQ underlyings in this
example:

<Trade id="EQ_VarianceDispersionSwap_Corridor">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
.....
</Envelope>
<CorridorVarianceDispersionSwapData>
<LongShort type="longShort">Long</LongShort>
<Weights type="number">
.....
</Weights>
<Underlyings1 type="index">
<Value>EQ-RIC:HSBA.L</Value>
<Value>EQ-RIC:[Link]</Value>
<Value>EQ-RIC:AMZN.O</Value>
</Underlyings1>
<Strikes1 type="number">
.....
</Strikes1>
<Spreads1 type="number">
.....
</Spreads1>
<Notionals1 type="number">
.....
</Notionals1>
<Caps1 type="number">
.....
</Caps1>
<Floors1 type="number">
.....
</Floors1>
<Underlyings2 type="index">
<Value>EQ-RIC:.STOXX50E</Value>
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.SPX</Value>
</Underlyings2>
<Strikes2 type="number">
.....
</Strikes2>
<Spreads2 type="number">

591
 .....
</Spreads2>
<Notionals2 type="number">
.....
</Notionals2>
<Caps2 type="number">
.....
</Caps2>
<Floors2 type="number">
.....
</Floors2>
<UpperBarrierLevels type="number">
.....
</UpperBarrierLevels>
<LowerBarrierLevels type="number">
.....
</LowerBarrierLevels>
<CountBothObservations type="bool">true</CountBothObservations>
<AccrualAdjustment type="bool">true</AccrualAdjustment>
<DividendAdjustment type="bool">false</DividendAdjustment>
<ValuationSchedule type="event">
<ScheduleData>
.....
</ScheduleData>
</ValuationSchedule>
<SettlementDate type="event">2021-01-10</SettlementDate>
<PayCcy type="currency">USD</PayCcy>
</CorridorVarianceDispersionSwapData>
</Trade>

The CorridorVarianceDispersionSwap script referenced in the trade above is shown in

listing 430
The meanings and allowable values for the CorridorVarianceDispersionSwapData
node below.
• [longShort] LongShort: Own party position in the swap. Long corresponds to
selling volatility on the Underlyings1 basket and buying volatility on
Underlyings2.
Allowable values: Long, Short.
• [number] Weights: List of weights applied to the final realised volatility of each
underlying in the Underlyings1 and Underlyings2 baskets.
Allowable values: Any positive number.
• [index] Underlyings1: The basket of underlyings whose volatility is bought in
the Long position.
Allowable values: For each underlying, see 8.3.29.
• [number] Strikes1: The volatility strike K1,u,vol of the variance swap for each
underlying u in the Underlyings1 basket, quoted in absolute terms. If the swap
was struck in terms of variance, the square root of that variance should be used
here.
Allowable values: Any positive number, as a percentage expressed in decimal
form.
• [number] Spreads1: Additional spread to the realised variance, for each
underlying in the Underlyings1 basket.
Allowable values: Any real number.
• [number] Notionals1: For each underlying u in the Underlyings1 basket, the
vega notional amount. If the swap was struck in terms of variance notionals

592
 N1,u,var , the corresponding vega notionals are given by
N1,u,vol = N1,u,var · 2 · 100 · K1,u,vol (where K1,u,vol is in absolute terms).
Allowable values: Any real number.
• [number] Caps1: For each underlying u in the Underlyings1 basket, the cap on
the realised variance as a factor of the strike. For example, if the value in Caps1
is 2.5, then the cap level will be 2.52 × K1,u,var . For underlyings with no cap, set
the value in Caps1 to zero.
Allowable values: Any non-negative number.
• [number] Floors1: For each underlying u in the Underlyings1 basket, the floor
on the realised variance as a factor of the strike. For example, if the value in
Floors1 is 0.1, then the floor level will be 0.12 × K1,u,var . For underlyings with
no floor, set the value in Floors1 to zero.
Allowable values: Any non-negative number.
• [index] Underlyings2: The basket of underlyings whose volatility is sold in the
Long position.
Allowable values: For each underlying, see 8.3.29.
• [number] Strikes2: The volatility strike K2,u,vol of the variance swap for each
underlying u in the Underlyings2 basket, quoted in absolute terms. If the swap
was struck in terms of variance, the square root of that variance should be used
here.
Allowable values: Any positive number, as a percentage expressed in decimal
form.
• [number] Spreads2: Additional spread to the realised variance, for each
underlying in the Underlyings2 basket.
Allowable values: Any real number.
• [number] Notionals2: For each underlying u in the Underlyings2 basket, the
vega notional amount. If the swap was struck in terms of variance notionals
N2,u,var , the corresponding vega notionals are given by
N2,u,vol = N2,u,var · 2 · 100 · K2,u,vol (where K2,u,vol is in absolute terms).
Allowable values: Any real number.
• [number] Caps2: For each underlying u in the Underlyings2 basket, the cap on
the realised variance as a factor of the strike. For example, if the value in Caps2
is 2.5, then the cap level will be 2.52 × K2,u,var . For underlyings with no cap, set
the value in Caps2 to zero.
Allowable values: Any non-negative number.
• [number] Floors2: For each underlying u in the Underlyings2 basket, the floor
on the realised variance as a factor of the strike. For example, if the value in
Floors2 is 0.1, then the floor level will be 0.12 × K2,u,var . For underlyings with
no floor, set the value in Floors2 to zero.
Allowable values: Any non-negative number.
• [number] UpperBarrierLevels: The agreed upper barrier price levels for each
underlying in Underlyings1.
Allowable values: Any real number.

593
 • [number] LowerBarrierLevels: The agreed lower barrier price levels for each
underlying in Underlyings1.
Allowable values: Any real number.
• [bool] CountBothObservations: Whether the variance is accrued based on both
the current and previous underlying prices (of each underlying in Underlyings1)
falling within the corridor (True) or only on the previous underlying price
(False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [bool] AccrualAdjustment: Whether the strike will be scaled relative to the
number of days that the underlying traded within the corridor. See, for example,
Ke var in section Corridor Variance Swap of the Product Description for Exotic
Variance and Volatility Swaps.
• [bool] DividendAdjustment: Whether or not the underlying price is adjusted for
dividend payments. This feature is not yet supported. Allowable values: Boolean
node, allowing Y, N, 1, 0, true, false, etc. The full set of allowable values is given
in Table 46.
• [event] ValuationSchedule: The schedule defining the (daily) observation period
for the variance accrual.
Allowable values: See Section 8.3.4.
• [event] SettlementDate: The date on which the swap payoff is settled.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

KO Corridor Variance Dispersion Swap

This instrument is a variance dispersion swap with a double-barrier knock-out and a
corridor feature.
With the corridor feature, variance is accrued only when the the price of the first
underlying of each pair of underlyings (between the first and second basket) falls
within the ‘corridor’. This means that the number of underlyings in each basket should
be the same, and each pair is determined based on the order that they are provided in
the trade XML, as in the example below.
The traditional trade representation is as follows, using EQ underlyings in this
example:

<Trade id="EQ_VarianceDispersionSwap_Corridor_KO">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
.....
</Envelope>
<KOCorridorVarianceDispersionSwapData>

594
 <LongShort type="longShort">Long</LongShort>
<Weights type="number">
.....
</Weights>
<Underlyings1 type="index">
<Value>EQ-RIC:HSBA.L</Value>
<Value>EQ-RIC:[Link]</Value>
<Value>EQ-RIC:AMZN.O</Value>
</Underlyings1>
<Strikes1 type="number">
.....
</Strikes1>
<Spreads1 type="number">
.....
</Spreads1>
<Notionals1 type="number">
.....
</Notionals1>
<Caps1 type="number">
.....
</Caps1>
<Floors1 type="number">
.....
</Floors1>
<Underlyings2 type="index">
<Value>EQ-RIC:.STOXX50E</Value>
<Value>EQ-RIC:.SPX</Value>
<Value>EQ-RIC:.SPX</Value>
</Underlyings2>
<Strikes2 type="number">
.....
</Strikes2>
<Spreads2 type="number">
.....
</Spreads2>
<Notionals2 type="number">
.....
</Notionals2>
<Caps2 type="number">
.....
</Caps2>
<Floors2 type="number">
.....
</Floors2>
<CorridorUpperBarrierLevels type="number">
.....
</CorridorUpperBarrierLevels>
<CorridorLowerBarrierLevels type="number">
.....
</CorridorLowerBarrierLevels>
<KOUpperBarrierLevels type="number">
.....
<KOUpperBarrierLevels/>
<KOLowerBarrierLevels type="number">
.....
</KOLowerBarrierLevels>
<CountBothObservations type="bool">true</CountBothObservations>
<AccrualAdjustment type="bool">true</AccrualAdjustment>
<DividendAdjustment type="bool">false</DividendAdjustment>
<KnockOutSchedule type="event">
<ScheduleData>
.....
</ScheduleData>
</KnockOutSchedule>
<VarianceAccrualStartDate type="event">2020-12-02</VarianceAccrualStartDate>
<SettlementSchedule type="event">
<DerivedSchedule>
<BaseSchedule>KnockOutSchedule</BaseSchedule>
.....
</DerivedSchedule>
</SettlementSchedule>
<PayCcy type="currency">USD</PayCcy>
</KOCorridorVarianceDispersionSwapData>
</Trade>

595
The KOCorridorVarianceDispersionSwap script referenced in the trade above is shown
in listing 431
The meanings and allowable values for the KOCorridorVarianceDispersionSwapData
node below.
• [longShort] LongShort: Own party position in the swap. Long corresponds to
selling volatility on the Underlyings1 basket and buying volatility on
Underlyings2.
Allowable values: Long, Short.
• [number] Weights: List of weights applied to the final realised volatility of each
underlying in the Underlyings1 and Underlyings2 baskets.
Allowable values: Any positive number.
• [index] Underlyings1: The basket of underlyings whose volatility is bought in
the Long position.
Allowable values: For each underlying, see 8.3.29.
• [number] Strikes1: The volatility strike K1,u,vol of the variance swap for each
underlying u in the Underlyings1 basket, quoted in absolute terms. If the swap
was struck in terms of variance, the square root of that variance should be used
here.
Allowable values: Any positive number, as a percentage expressed in decimal
form.
• [number] Spreads1: Additional spread to the realised variance, for each
underlying in the Underlyings1 basket.
Allowable values: Any real number.
• [number] Notionals1: For each underlying u in the Underlyings1 basket, the
vega notional amount. If the swap was struck in terms of variance notionals
N1,u,var , the corresponding vega notionals are given by
N1,u,vol = N1,u,var · 2 · 100 · K1,u,vol (where K1,u,vol is in absolute terms).
Allowable values: Any real number.
• [number] Caps1: For each underlying u in the Underlyings1 basket, the cap on
the realised variance as a factor of the strike. For example, if the value in Caps1
is 2.5, then the cap level will be 2.52 × K1,u,var . For underlyings with no cap, set
the value in Caps1 to zero.
Allowable values: Any non-negative number.
• [number] Floors1: For each underlying u in the Underlyings1 basket, the floor
on the realised variance as a factor of the strike. For example, if the value in
Floors1 is 0.1, then the floor level will be 0.12 × K1,u,var . For underlyings with
no floor, set the value in Floors1 to zero.
Allowable values: Any non-negative number.
• [index] Underlyings2: The basket of underlyings whose volatility is sold in the
Long position.
Allowable values: For each underlying, see 8.3.29.

596
• [number] Strikes2: The volatility strike K2,u,vol of the variance swap for each
underlying u in the Underlyings2 basket, quoted in absolute terms. If the swap
was struck in terms of variance, the square root of that variance should be used
here.
Allowable values: Any positive number, as a percentage expressed in decimal
form.
• [number] Spreads2: Additional spread to the realised variance, for each
underlying in the Underlyings2 basket.
Allowable values: Any real number.
• [number] Notionals2: For each underlying u in the Underlyings2 basket, the
vega notional amount. If the swap was struck in terms of variance notionals
N2,u,var , the corresponding vega notionals are given by
N2,u,vol = N2,u,var · 2 · 100 · K2,u,vol (where K2,u,vol is in absolute terms).
Allowable values: Any real number.
• [number] Caps2: For each underlying u in the Underlyings2 basket, the cap on
the realised variance as a factor of the strike. For example, if the value in Caps2
is 2.5, then the cap level will be 2.52 × K2,u,var . For underlyings with no cap, set
the value in Caps2 to zero.
Allowable values: Any non-negative number.
• [number] Floors2: For each underlying u in the Underlyings2 basket, the floor
on the realised variance as a factor of the strike. For example, if the value in
Floors2 is 0.1, then the floor level will be 0.12 × K2,u,var . For underlyings with
no floor, set the value in Floors2 to zero.
Allowable values: Any non-negative number.
• [number] CorridorUpperBarrierLevels: The agreed corridor upper barrier
price levels for each underlying in Underlyings1.
Allowable values: Any real number.
• [number] CorridorLowerBarrierLevels: The agreed corridor lower barrier price
levels for each underlying in Underlyings1.
Allowable values: Any real number.
• [number] KOUpperBarrierLevels: The agreed knock-out upper barrier price
levels for each underlying in Underlyings1.
Allowable values: Any real number.
• [number] KOLowerBarrierLevels: The agreed knock-out lower barrier price
levels for each underlying in Underlyings1.
Allowable values: Any real number.
• [bool] CountBothObservations: Whether the variance is accrued based on both
the current and previous underlying prices (of each underlying in Underlyings1)
falling within the corridor (True) or only on the previous underlying price
(False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46.
• [bool] AccrualAdjustment: Whether the strike will be scaled relative to the

597
 number of days that the underlying traded within the corridor. See, for example,
e var in section Corridor Variance Swap of the Product Description for Exotic
K
Variance and Volatility Swaps.
• [bool] DividendAdjustment: Whether or not the underlying price is adjusted for
dividend payments. This feature is not yet supported. Allowable values: Boolean
node, allowing Y, N, 1, 0, true, false, etc. The full set of allowable values is given
in Table 46.
• [event] KnockOutSchedule: The schedule defining the (daily) knock-out
observation period.
Allowable values: See Section 8.3.4.
• [event] VarianceAccrualStartDate: The date on which variance
observation/accrual starts. The last variance observation date is the same as the
last date in the KnockOutSchedule.
Allowable values: See Date in Table 30.
• [event] SettlementSchedule: The settlement dates derived from the
KnockOutSchedule using a settlement lag to reflect settlement after a knock-out
event, or after the final variance observation date if no knock-out occurs..
Allowable values: See section 8.3.4 Schedule Data and Dates, or DerivedSchedule
(see (see the scripted trade documentation in ore/Docs/ScriptedTrade).
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Gamma Swap
The traditional trade representation is as follows, using EQ underlyings in this
example:

<Trade id="EQ_GammaSwap">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
.....
</Envelope>
<GammaSwapData>
<LongShort type="longShort">Long</LongShort>
<Strike type="number">0.19</Strike>
<Notional type="number">1380</Notional>
<SettlementDate type="event">2021-09-25</SettlementDate>
<Underlying type="index">EQ-RIC:.SPX</Underlying>
<ValuationSchedule type="event">
<ScheduleData>
<Rules>
<StartDate>2020-11-26</StartDate>
<EndDate>2021-09-18</EndDate>
<Tenor>1D</Tenor>
<Convention>Following</Convention>
<TermConvention>Following</TermConvention>
<Calendar>USA</Calendar>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>

598
 </ValuationSchedule>
<PayCcy type="currency">USD</PayCcy>
</GammaSwapData>
</Trade>

The GammaSwap script referenced in the trade above is shown in listing 432
The meanings and allowable values for the GammaSwapData node below.
• [longShort] LongShort: Own party position in the swap. Long corresponds to
paying out on the fixed/strike variance (volatility) and receiving on the
floating/realised variance (volatility). In other words, a long position has positive
value if the realised variance (volatility) exceeds the variance (volatility) strike.
Allowable values: Long, Short.
• [number] Strike: The volatility strike K of the underlying quoted in absolute
terms. If the swap was struck in terms of variance, the square roots of the
variances should be used here.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• [number] Notional: The vega notional amount. If the swap was struck in terms
of a variance notional Nvar , the corresponding vega notional is given by
Nvol = Nvar · 2 · 100 · K (where K is in absolute terms).
Allowable values: Any non-negative number.
• [event] SettlementDate: The date on which the swap payoff is settled.
Allowable values: See Date in Table 30.
• [index] Underlying: Underlying index.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [event] ValuationSchedule: The base schedule which defines the start dates of
the variance accrual schedule. This node is also used to derive the variance
accrual schedule. Note that the end date (or last date) of this schedule must be
the final period end date of the instrument.
Allowable values: See Section 8.3.4.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.

Basket Variance Swap

The FxBasketVarianceSwap and EquityBasketVarianceSwap
CommodityBasketVarianceSwap trade types have trade data containers (respectively):
• FxBasketVarianceSwapData
• EquityBasketVarianceSwapData

599
 • CommodityBasketVarianceSwapData
Listing 433 shows the structure of example trades for an Equity underlying.

Listing 433: EquityBasketVarianceSwap data

<Trade id="Equity_VarianceSwap_Basket">
<TradeType>EquityBasketVarianceSwap</TradeType>
<Envelope>
.......
</Envelope>
<EquityBasketVarianceSwapData>
<LongShort>Long</LongShort>
<Strike>0.31613</Strike>
<Notional>1340.0</Notional>
<Underlyings>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
<Weight>0.75</Weight>
</Underlying>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.STOXX50E</Name>
<Weight>0.25</Weight>
</Underlying>
</Underlyings>
<SquaredPayoff>true</SquaredPayoff>
<ValuationSchedule>
<Rules>
.......
</Rules>
</ValuationSchedule>
<Cap>2.5</Cap>
<SettlementDate>2022-06-29</SettlementDate>
<Currency>USD</Currency>
</EquityBasketVarianceSwapData>
</Trade>

The payout formula is the same as for a standard capped/floored variance swap, with
the realised variance calculated as follows:

D
" N  #2
252 X X Xi,n
RealisedV ariance = wn ln ,
D i=1 n=1 Xi−1,n

for D variance accrual/valuation dates over the life of the trade, where
• Xi,n denotes the fixing for the n-th underlying at ti .
• wn is the basket weight for the n-th underlying.
The meanings and allowable values of elements in the
EquityBasketVarianceSwapData node follow below.
• LongShort: Own party position.
Allowable values: Long, Short
• Strike: The volatility strike Kvol of the variance swap quoted in absolute terms.
If the swap was struck in terms of variance, the square root of that variance
should be used here.

600
 Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• Notional: The vega notional amount. If the swap was struck in terms of a
variance notional Nvar , the corresponding vega notional is given by
Nvol = Nvar · 2 · 100 · Kvol (where Kvol is in absolute terms).
Allowable values: Any non-negative number.
• Underlyings: The basket of underlyings.
For FxBasketVarianceSwap, Type is set to FX and Name is a string of the form
SOURCE-CCY1-CCY2 where CCY1 is the foreign currency, CCY2 is the
domestic currency, and SOURCE is the fixing source, see Table 38. (section Data
Node / Index) for allowable values.
For EquityBasketVarianceSwap, Type is set to Equity and Name and other fields
are as outlined in 8.3.29.
For CommodityBasketVarianceSwap, Type is set to Commodity and Name is an
identifier of the commodity as outlined in 8.3.29 and in Table 42
Allowable values: For each underlying, an Underlying node as outlined in 8.3.29.
All underlyings must be from the same asset class.
• SquaredPayoff [Optional]: Flag indicating whether the trade is a variance swap
(True) or a volatility swap (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. Defaults to
False if left blank or omitted. The full set of allowable values is given in Table 46.
• ValuationSchedule: The schedule defining the (daily) observation period for the
variance accrual.
Allowable values: See Section 8.3.4.
• Cap [Optional]: The cap on the realised variance, as a factor of the corresponding
strike. For example, if Cap is 2.5, then the cap level will be 2.52 × K̂var for the
basket realised variance. For trades with no cap, set Cap to zero.
Allowable values: Any non-negative number. Defaults to zero if left blank or
omitted.
• Floor [Optional]: The floor on the realised variance, as a factor of the
corresponding strike. For example, if Floor is 0.1, then the floor level will be
0.12 × K̂var for the basket realised variance. For trades with no floor, set Floor
to zero.
Allowable values: Any non-negative number. Defaults to zero if left blank or
omitted.
• SettlementDate: The date on which the swap payoff is settled.
Allowable values: See Date in Table 30.
• Currency: The settlement currency.
Allowable values: See Table 32 Currency.
Basket variance swaps can alternatively be represented as scripted trades, refer to the
scripted trade documentation in ore/Docs/ScriptedTrade for an introduction.

601
<Trade id="EQ_VarianceSwap_Basket">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
......
</Envelope>
<BasketVarianceSwapData>
<LongShort type="longShort">Long</LongShort>
<Underlyings type="index">
<Value>EQ-RIC:.STOXX50E</Value>
<Value>EQ-RIC:.SPX</Value>
</Underlyings>
<Weights type="number">
<Value>0.25</Value>
<Value>0.75</Value>
</Weights>
<Strike type="number">0.31613</Strike>
<Notional type="number">1339.0</Notional>
<SquaredPayoff type="bool">true</SquaredPayoff>
<ValuationSchedule type="event">
<ScheduleData>
<Rules>
......
</Rules>
</ScheduleData>
</ValuationSchedule>
<Cap type="number">2.5</Cap>
<Floor type="number">0</Floor>
<SettlementDate type="event">2022-06-29</SettlementDate>
<PayCcy type="currency">USD</PayCcy>
</BasketVarianceSwapData>
</Trade>

The PairwiseVarianceSwap script referenced in the trade above is shown in listing 434
The meanings and allowable values for the BasketVarianceSwapData node below.
• [longShort] LongShort: Own party position in the swap. Long corresponds to
paying out on the fixed/strike variance (volatility) and receiving on the
floating/realised variance (volatility). In other words, a long position has positive
value if the realised variance (volatility) exceeds the variance (volatility) strike.
Allowable values: Long, Short.
• [index] Underlyings: List of underlying indices.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [number] Strike: The volatility strike Kvol of the variance swap quoted in
absolute terms. If the swap was struck in terms of variance, the square root of
that variance should be used here.
Allowable values: Any non-negative number, as a percentage expressed in
decimal form.
• [number] Notional: The vega notional amount. If the swap was struck in terms
of a variance notional Nvar , the corresponding vega notional is given by
Nvol = Nvar · 2 · 100 · Kvol (where Kvol is in absolute terms).
Allowable values: Any non-negative number.
• SquaredPayoff: Flag indicating whether the trade is a variance swap (True) or
a volatility swap (False).
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. Defaults to
False if left blank or omitted. The full set of allowable values is given in Table 46.

602
 • [event] ValuationSchedule: The schedule defining the (daily) observation period
for the variance accrual.
Allowable values: See Section 8.3.4.
• [number] Cap: The cap on the realised variance, as a factor of the corresponding
strike. For example, if Cap is 2.5, then the cap level will be 2.52 × K̂var for the
basket realised variance. For trades with no cap, set Cap to zero.
Allowable values: Any non-negative number.
• [number] Floor: The floor on the realised variance, as a factor of the
corresponding strike. For example, if Floor is 0.1, then the floor level will be
0.12 × K̂var for the basket realised variance. For trades with no floor, set Floor
to zero.
Allowable values: Any non-negative number.
• [event] SettlementDate: The date on which the swap payoff is settled.
Allowable values: See Date in Table 30.
• [currency] PayCcy: The settlement currency.
Allowable values: See Table 32 for allowable currency codes.

8.2.79 Accumulators and Decumulators

The FxAccumulatorData, EquityAccumulatorData, CommodityAccumulatorData is
the trade data container for the FxAccumulator, EquityAccumulator,
CommodityAccumulator trade type. The following listings and show the structure of
example trades for an FX and Equity underlying. Here the FX accumulator is of “type
01” meaning that a settlement takes place on each observation date while the equity
accumulator is of “type 02” meaning that a settlement takes place on specific period
end dates for all observation dates in that period.

<Trade id="FX_ACCUMULATOR">
<TradeType>FxAccumulator</TradeType>
<Envelope>
...
</Envelope>
<FxAccumulatorData>
<Currency>USD</Currency>
<FixingAmount>1000000</FixingAmount>
<Strike>1.1</Strike>
<Underlying>
<Type>FX</Type>
<Name>ECB-EUR-USD</Name>
</Underlying>
<OptionData>
<LongShort>Long</LongShort>
<PayoffType>Accumulator</PayoffType>
</OptionData>
<StartDate>2016-03-01</StartDate>
<ObservationDates>
<Dates>
<Dates>
<Date>2017-03-01</Date>
<Date>2020-03-01</Date>
<Date>2025-03-01</Date>

603
 <Date>2029-03-01</Date>
</Dates>
</Dates>
</ObservationDates>
<SettlementDates>
<Dates>
<Dates>
<Date>2017-03-03</Date>
<Date>2020-03-03</Date>
<Date>2025-03-03</Date>
<Date>2029-03-03</Date>
</Dates>
</Dates>
</SettlementDates>
<RangeBounds>
<RangeBound>
<RangeTo>1.14</RangeTo>
<Leverage>1</Leverage>
</RangeBound>
<RangeBound>
<RangeFrom>1.14</RangeFrom>
<Leverage>1</Leverage>
</RangeBound>
</RangeBounds>
<Barriers>
<BarrierData>
<Type>UpAndOut</Type>
<Style>American</Style>
<Levels>
<Level>1.5</Level>
</Levels>
</BarrierData>
<BarrierData>
<Type>FixingFloor</Type>
<Levels>
<Level>2</Level>
</Levels>
</BarrierData>
</Barriers>
</FxAccumulatorData>
</Trade>

<Trade id="Equity_Decumulator">
<TradeType>EquityAccumulator</TradeType>
<Envelope>
...
</Envelope>
<EquityAccumulatorData>
<FixingAmount>30</FixingAmount>
<StrikeData>
<Value>4000</Value>
<Currency>EUR</Currency>
</StrikeData>
<Underlying>
<Type>Equity</Type>
<Name>.STOXX50</Name>
<IdentifierType>RIC</IdentifierType>

604
 </Underlying>
<OptionData>
<LongShort>Long</LongShort>
<PayoffType>Decumulator</PayoffType>
</OptionData>
<StartDate>20190925</StartDate>
<ObservationDates>
<Rules>
<StartDate>20190925</StartDate>
<EndDate>20200925</EndDate>
<Tenor>1D</Tenor>
<Calendar>TARGET</Calendar>
<Convention>F</Convention>
<TermConvention>F</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ObservationDates>
<PricingDates>
<Dates>
<Dates>
<Date>20211025</Date>
<Date>20211125</Date>
...
</Dates>
</Dates>
</PricingDates>
<SettlementLag>2D</SettlementLag>
<SettlementCalendar>TARGET</SettlementCalendar>
<SettlementConvention>F</SettlementConvention>
<RangeBounds>
<RangeBound>
<RangeTo>4000</RangeTo>
<Leverage>1</Leverage>
</RangeBound>
<RangeBound>
<RangeFrom>4000</RangeFrom>
<Leverage>2</Leverage>
</RangeBound>
</RangeBounds>
<Barriers>
<BarrierData>
<Type>DownAndOut</Type>
<LevelData>
<Level>
<Value>3500</Value>
<Currency>EUR</Currency>
</Level>
</LevelData>
</BarrierData>
<BarrierData>
<Type>FixingFloor</Type>
<Levels>
<Level>1</Level>
</Levels>
</BarrierData>
</Barriers>
</EquityAccumulatorData>
</Trade>

605
Accumulator Payout Formula
The payout formula, from the perspective of the party that is long, for each
observation date of an Accumulator is:

P ayout = RangeBound(Leverage) · F ixingAmount · (f ix − Strike),

i.e. for an Accumulator the holder pays [Strike * FixingAmount *

RangeBound(Leverage)] expressed in Currency and receives/buys [fix * FixingAmount
* RangeBound(Leverage)]’s worth of equity/CCY1/commodity in Currency on each
observation date.
If NakedOption is true, the payout formula for an Accumulator (long perspective) is:

P ayout = |RangeBound(Leverage)| · F ixingAmount · max(0, ϕ · (f ix − Strike)),

where ϕ = ±1 is the option type (+1 for Call, -1 for Put) inferred from the sign of the
values of RangeBound(Leverage), which are all required to be the same.

Decumulator Payout Formula

The payout formula, from the perspective of the party that is long, for each
observation date of a Decumulator is:

P ayout = RangeBound(Leverage) · F ixingAmount · (Strike − f ix),

For a Decumulator the holder pays/sells [fix * FixingAmount *

RangeBound(Leverage)]’s worth of equity/CCY1/commodity in Currency, and receives
[Strike * FixingAmount * RangeBound(Leverage)] expressed in Currency on each
observation date.
If NakedOption is true, the payout formula for a Decumulator (long perspective) is:

P ayout = |RangeBound(Leverage)| · F ixingAmount · max(0, ϕ · (Strike − f ix),

where ϕ = ±1 is the option type (+1 for Call, -1 for Put) inferred from the sign of the
values of RangeBound(Leverage), which are all required to be the same.
The meanings and allowable values of the elements in the data node follow below.
• StrikeData [Optional]: A node containing the global strike in Value and the
currency in which both the underlying and the strike are quoted in Currency.
Only supported for EquityAccumulators.
Allowable values: See Currency in Table 30. The strike may be any positive real
number. The currency provided in this node may be quoted as corresponding
minor currency to the underlying major currency. If omitted, local strikes should
be used in each RangeBound node.

606
• Currency: The payout currency. The result of the payout formula above is
treated to be in this currency. Note that for (non-quanto) FxAccumulators this
should be the domestic (CCY2) currency. For non-quanto Equity- and
CommodityAccumulators this should be the currency the equity or commodity is
quoted in. Notice section “Payment Currency” in ore/Docs/ScriptedTrade.
Allowable values: See Table 32 Currency.
• FixingAmount: The unleveraged notional amount accumulated at each fixing
date.
For FxAccumulators: The FixingAmount is expressed in the foreign currency
(CCY1).
For EquityAccumulators: The FixingAmount is expressed as number of
shares/units of the underlying equity or equity index.
For CommodityAccumulators: The FixingAmount is expressed as number of
units of the underlying commodity.
Allowable values: Any real number. Note that a negative amount causes an
Accumulator to become a Decumulator, and vice-versa.
• DailyFixingAmount [Optional]: For accumulator type “01” only: If true, the
fixing amount for a period is calculated as the given FixingAmount times the
number of calendar days in the period. The periods are given by [StartDate,
ObservationDate(1)], [ObservationDate(1), ObservationDate(2)], ... etc. i.e. if
true, a StartDate is required to determine the calendar days in the first period. If
false, the fixing amount is used directly without any weighting.
Allowable values: true or false. Defaults to false if left blank or omitted.
• Strike [Optional]: Global strike associated to the ranges. Is overwritten by local
strikes defined in RangeBounds or modified by range strike adjustments. Note
that each RangeBound needs a strike, either the global strike defined here, or a
local one in the RangeBounds nodes which then overwrites the global one.
For FxAccumulators: The the fx strike rate (global and local) is defined as
amount in domestic currency (CCY2) for one unit of foreign currency (CCY1).
For Equity- and CommodityAccumulators: The strike value (global and local) for
one unit/share/contract of the underlying equity or commodity, expressed in the
currency the equity or commodity is quoted in. For EquityAccumulators, the
StrikeData node (see above) should be used.
The logic for global and local strikes is as follows:
- if a local Strike for an interval is given, this local Strike will be used for the
interval (a global Strike will be ignored if given)
- otherwise if a global Strike and a local StrikeAdjustment are given, the strike
used for the interval will be global Strike + local StrikeAdjustment
- otherwise if a global Strike, but no local StrikeAdjustment is given, the strike
used for the interval will be the global Strike
- if no global strike and no local strike is given for an interval, an error is thrown,
since the strike information is not sufficient

607
 Allowable values: Any positive real number.
• Underlying: A node with the underlying of the Accumulator instrument.
For FxAccumulators: Type is set to FX and Name is a string of the form
SOURCE-CCY1-CCY2 where CCY1 is the foreign currency, CCY2 is the domestic
currency, and SOURCE is the fixing source, see Table 38 and 8.3.29.
For EquityAccumulators: Type is set to Equity and Name and other fields are as
outlined in 8.3.29
For CommodityAccumulators: Type is set to Commodity and Name is an
identifier of the commodity as outlined in 8.3.29 and in Table 42.
Allowable values: Any FX, Equity or Commodity underlying as specified in 8.3.29
• OptionData: See 8.3.1. A node that describes whether the instrument is Long or
Short, whether the payoff type is Accumulator or Decumulator,
The relevant fields in the OptionData node for an Accumulator are:
– LongShort The allowable values are Long or Short. Note that a Long
Accumulator is equivalent to a Short Decumulator except when there are
guaranteed fixings, i.e. when a Barrier node of Type FixingFloor is present.
The FixingFloor causes asymmetry in the payoff.
PayoffType The allowable values are Accumulator or Decumulator. For a
long accumulator the strike is paid and the underlying received, for a long
decumulator it is the other way around.
• StartDate [Mandatory for American Style Barrier or if a daily fixing amount is
used, Optional for European Style or no Barrier and no daily fixing amount is
used]: Used to set the start of the knock out monitoring - American knock out
events are monitored from this date on. This field is only relevant for
accumulators of type American Knock-Out, and not used otherwise. Can be
omitted for European knock outs, or if there is no barrier.
Allowable values: See Date in Table 30.
• ObservationDates: The observation dates given as schedule data.
Allowable values: See the ScheduleData definition 8.3.4.
• PricingDates[Optional]: The dates defining observation period end dates on
which the settlement for all dates in the period takes place. Note that the
inclusion or not of PricingDates determines the Accumulator type. If included
the Accumulator is of “type 02”, and otherwise, if PricingDates are not included
it is of “type 01”.
Allowable values: See the ScheduleData definition 8.3.4. Note that the final
pricing period end date (defining the final observation period end date) must be
on or after the final observation date.
• SettlementLag [Optional]: The settlement delay. Optional, if not given it is
defaulted to 0D.
Allowable values: Any period definition (e.g. 2D, 1W, 1M, 1Y )

608
• SettlementCalendar [Optional]: The calendar used to compute the settlement
date from the corresponding observation date.
Allowable values: Any valid calendar, see Table 34 Calendar.. Optional, defaults
to the null calendar (no holidays).
• SettlementConvention [Optional]: The convention used to compute the
settlement date from the corresponding observation date. Optional, defaults to F
(following).
Allowable values: Any valid roll convention (U,F,P,MF,MP ), see Table 31 Roll
Convention.
• SettlementDates [Optional]: The settlement dates can also be given as an explicit
list of dates, see the FX accumulator listing above for an example. For a “type
01” accumulator the number of dates must be equal to the number of observation
dates. For a “type 02” accumulator the number of dates must be equal to the
number of pricing dates. If an explicit list of settlement dates is given, no
settlement lag, calendar, conventions should be given.
• NakedOption [Optional]: If true, the payoff represents that of an option, and
only positive values are accumulated in the instrument. The option type (Call or
Put) is inferred from the sign of the Leverage values in RangeBound, which are
all required to be the same.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false, etc. The full set
of allowable values is given in Table 46. Defaults to false if left blank or omitted.
• RangeBounds: Nodes for the specification of ranges and associated leverages. A
leverage can be specified to apply for all values the underlying can take, or for
specific ranges using RangeFrom and RangeTo. Multiple RangeBound sub-nodes
can be included within the RangeBounds node. If no leverage is specified for a
range, it defaults to 1 for this range. In addition a range bound specific strike
can be specified for Accumulators of “type 01” (and only this type!) which
overwrites the global Strike field. If all range bounds have a specific strike
defined, the global Strike field might be omitted.
Allowable values: For each range, see 8.3.32. Only the Leverage is relevant for a
given range. All Leverage parameters in one instrument must have the same
sign. For “type 01” Accumulators, the Strike is relevant too and overwrites the
global strike if given. Finally, for “type 01” Accumulators a range bound specific
strike can be specified by specifying a range bound specific strike adjustment to
the global strike (see the range bound spec for details).
• Barriers: Specification of barriers and fixing floors (guaranteed fixings). Multiple
BarrierData sub-nodes can be included within the Barriers node. Relevant
fields for each BarrierData sub-node are Type, Style, and Level. The barrier is
monitored on the
– the observation dates (type 02 accumulator, i.e. PricingDates are given)
– the observation dates (type 01 accumulator, i.e. no PricingDates are given),
if barrier style is European
– from the start date to the first observation date and between the
observation dates on a continuous basis (type 01 accumulator), if barrier

609
 style is American
For type 01 accumulators (no pricing dates are given), the FixingFloor
guarantees a specific number of fixings to be settled even in case of a knock out.
On a guaranteed fixing date, Only positive payouts (from the buyer/long
perspective) are realised. Where payout = fix - strike for accumulators and strike
- fix for decumulators.
For type 02 accumulators (pricing dates are given), the FixingFloor specifies the
number of periods (rather than observation dates) that are guaranteed to settle.
If a knock out event occurs within a settlement period the fixings after the knock
event within this period are assumed to fall into the first defined range and the
settlement takes place on the knock out day plus the defined settlement delay.
The barrier Level for Type UpAndOut and DownAndOut is expressed in the
same way as Strike outlined above. For EquityAccumulators, each Level node
should be provided a Value and a Currency and contained in a LevelData node
(see example trade above). This Currency supports minor currencies.
The barrier Level for Type FixingFloor is a non-negative integer.
Allowable values: For each BarrierData node, see 8.3.31. For
Accumulators/Decumulators, the following values for Type are relevant:
UpAndOut, DownAndOut and FixingFloor. The barrier Style can be European
(monitored on observation dates) or American (continuously monitored).
Accumulators can also be represented as scripted trades, refer to the separate
documentation in ore/Docs/ScriptedTrade for an introduction. Listing 435 shows the
structure of an Accumulator (type 01) example, here on a FX underlying (EQ or
COMM underlyings are possible as well).

610
Listing 435: Accumulator (type 01) Scripted Representation

<Trade id="SCRIPTED_FX_ACCUMULATOR">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<Accumulator01Data>
<Strike type="number">1.1</Strike>
<FixingAmount type="number">1000000</FixingAmount>
<LongShort type="longShort">Long</LongShort>
<Underlying type="index">FX-ECB-EUR-USD</Underlying>
<PayCcy type="currency">USD</PayCcy>
<StartDate type="event">2016-03-01</StartDate>
<FixingDates type="event">
<ScheduleData>
<Dates>
<Dates>
<Date>2017-03-01</Date>
<Date>2020-03-01</Date>
<Date>2025-03-01</Date>
<Date>2029-03-01</Date>
</Dates>
</Dates>
</ScheduleData>
</FixingDates>
<SettlementDates type="event">
<DerivedSchedule>
<BaseSchedule>FixingDates</BaseSchedule>
<Shift>2D</Shift>
<Calendar>TARGET</Calendar>
<Convention>F</Convention>
</DerivedSchedule>
</SettlementDates>
<RangeUpperBounds type="number">
<Value>1.14</Value>
<Value>10000</Value>
</RangeUpperBounds>
<RangeLowerBounds type="number">
<Value>0</Value>
<Value>1.14</Value>
</RangeLowerBounds>
<RangeLeverages type="number">
<Value>1</Value>
<Value>2</Value>
</RangeLeverages>
<KnockOutLevel type="number">1.5</KnockOutLevel>
<KnockOutType type="barrierType">UpOut</KnockOutType>
<AmericanKO type="bool">true</AmericanKO>
<GuaranteedFixings type="number">2</GuaranteedFixings>
</Accumulator01Data>
</Trade>

The meanings and allowable values of the elements in the Accumulator01Data

representation follow below.

611
 • Strike: The strike value the bought currency is purchased at.
• FixedAmount: The unleveraged notional amount accumulated at each fixing date
• LongShort: 1 for a long, -1 for a short position
• Underlying: See ore/Docs/ScriptedTrade’s Index section for allowable values.
• PayCcy: The payment currency of the trade. Notice section Notice section
“Payment Currency” in ore/Docs/ScriptedTrade.
• StartDate: The start date. American knock out events are monitored from this
date on. Notice that the start date must be given in the scripted trade
representation for European knock outs, although it is not used for this variant.
• FixingDates: The fixing dates, given as a ScheduleData, or DerivedSchedule (see
ore/Docs/ScriptedTrade).
• SettlementDates: The fixing dates, given as a ScheduleData, or DerivedSchedule
(see ore/Docs/ScriptedTrade).
• RangeUpperBound: Values of upperbounds for the leverage ranges. If a given
range has no upperbound add 100000
• RangeLowerBound: Values of lowerbounds for the leverage ranges. If a given
range has no lowerbound add 0
• RangeLeverages: Values of leverages for the leverage ranges.
• KnockOutLevel: The KnockOut Barrier level
• KnockOutType: The KnockOut Barrier type, can be UpOut or DownOut
• AmericanKO: If true, knock out events are monitored on a continuous basis,
otherwise they are monitored on the fixing dates only.
• GuaranteedFixings: Number of the first n Fixings that are guaranteed, regardless
of whether or not the trade has been knocked out.
The script ‘Accumulator01’ referenced in the trade above is shown in Listing 436.

612
Listing 436: Accumulator type 01 script

REQUIRE KnockOutType == 3 OR KnockOutType == 4;

NUMBER Payoff, fix, d, r, Alive, currentNotional, Factor, ThisPayout, Fixing[SIZE(FixingDates)];
Alive = 1;
FOR d IN (1, SIZE(FixingDates), 1) DO
fix = Underlying(FixingDates[d]);
Fixing[d] = fix;

IF AmericanKO == 1 THEN
IF KnockOutType == 4 THEN
IF FixingDates[d] >= StartDate THEN
IF d == 1 OR FixingDates[d-1] <= StartDate THEN
Alive = Alive * (1 - ABOVEPROB(Underlying, StartDate, FixingDates[d], KnockOutLevel));
ELSE
Alive = Alive * (1 - ABOVEPROB(Underlying, FixingDates[d-1], FixingDates[d], KnockOutL
END;
END;
ELSE
IF FixingDates[d] >= StartDate THEN
IF d == 1 OR FixingDates[d-1] <= StartDate THEN
Alive = Alive * (1 - BELOWPROB(Underlying, StartDate, FixingDates[d], KnockOutLevel));
ELSE
Alive = Alive * (1 - BELOWPROB(Underlying, FixingDates[d-1], FixingDates[d], KnockOutL
END;
END;
END;
ELSE
IF {KnockOutType == 4 AND fix >= KnockOutLevel} OR
{KnockOutType == 3 AND fix <= KnockOutLevel} THEN
Alive = 0;
END;
END;

IF d <= GuaranteedFixings THEN

Factor = 1;
ELSE
Factor = Alive;
END;

FOR r IN (1, SIZE(RangeUpperBounds), 1) DO

IF fix > RangeLowerBounds[r] AND fix <= RangeUpperBounds[r] THEN
ThisPayout = RangeLeverages[r] * FixingAmount * (fix - Strike) * Factor;
IF d > GuaranteedFixings OR ThisPayout >= 0 THEN
Payoff = Payoff + LOGPAY(RangeLeverages[r] * FixingAmount * (fix - Strike) * Factor,
FixingDates[d], SettlementDates[d], PayCcy);
END;
END;
END;
END;
value = LongShort * Payoff;
currentNotional = FixingAmount * Strike;

Accumulators of Type 02 can also be represented as scripted trades, see

ore/Docs/ScriptedTrade for an introduction. Listing 437 shows the structure of an
Accumulator (Type 02) example, here on an equity underlying. FX and COMM

613
underlyings are possible as well.

614
Listing 437: EQ Accumulator (type 02) Scripted Representation

<Trade id="EqDecumulator">
<TradeType>ScriptedTrade</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<Accumulator02Data>
<Strike type="number">59.9842</Strike>
<FixingAmount type="number">11</FixingAmount>
<LongShort type="longShort">Long</LongShort>
<Underlying type="index">EQ-RIC:.SPX</Underlying>
<PayCcy type="currency">EUR</PayCcy>
<ObservationDates type="event">
<ScheduleData>
<Rules>
<StartDate>20190925</StartDate>
<EndDate>20200925</EndDate>
<Tenor>1D</Tenor>
...
</Rules>
</ScheduleData>
</ObservationDates>
<KnockOutSettlementDates type="event">
<DerivedSchedule>
<BaseSchedule>ObservationDates</BaseSchedule>
<Shift>2D</Shift>
<Calendar>TARGET</Calendar>
<Convention>F</Convention>
</DerivedSchedule>
</KnockOutSettlementDates>
<ObservationPeriodEndDates type="event">
<ScheduleData>
<Dates>
<Dates>
<Date>20191025</Date>
<Date>20191125</Date>
...
<Date>20200925</Date>
</Dates>
</Dates>
</ScheduleData>
</ObservationPeriodEndDates>
<SettlementDates type="event">
<ScheduleData>
<Dates>
<Dates>
<Date>20191027</Date>
<Date>20191127</Date>
...
<Date>20200927</Date>
</Dates>
</Dates>
</ScheduleData>
</SettlementDates>
<RangeUpperBounds type="number">
<Value>59.9842</Value>
<Value>10000000.0</Value>
</RangeUpperBounds>
615
<RangeLowerBounds type="number">
<Value>-10000000.0</Value>
<Value>59.9842</Value>
The script ‘Accumulator02’ referenced in the trade above is shown in Listing 438.
The meanings and allowable values of the elements in the DecumulatorData node
folllow below.
• Strike: The forward price. For an FX underlying FX-SOURCE-CCY1-CCY2 this is
the number of units of CCY2 per units of CCY1. For an EQ underlying this is the
equity price expressed in the equity ccy. Allowable values are non-negative
numbers.
• FixingAmount: The number of shares per day (EQ Undlerinyg) resp. the foreign
amount (FX Undderlying). Allowable values are non-negative values.
• LongShort: The position, allowable values are “Long” and “Short”
• Underlying: The underlying index
See ore/Docs/ScriptedTrade’s Index section for allowable values.
• PayCcy: The payment currency. See the appendix for allowable currency codes.
Notice section Notice section “Payment Currency” in ore/Docs/ScriptedTrade.
• ObservationDates: The observation date schedule. See ore/Docs/ScriptedTrade
on how this is set up.
• KnowOutSettlementDates: The settlement dates associated to the observation
dates in case of a knock out event, the number of observation and knock out
settlement dates must be equal. See ore/Docs/ScriptedTrade on how this is set
up.
• ObservationPeriodEndDates: The last date for each observation period. See
ore/Docs/ScriptedTrade on how this is set up.
• SettlementDates: The settlement dates for each observation period, the number
of settlement dates and the number of observation period end dates must be
equal. See ore/Docs/ScriptedTrade on how this is set up.
• RangeUpperBounds: The multiplier for the “number of days below” in the payoff.
Allowable values are non-negative numbers.
• RangeLowerBounds: The multiplier for the “number of days above” in the payoff.
Allowable values are non-negative numbers.
• RangeLeverages: The multiplier for the defined ranges. Allowable values are
non-negative numbers.
• DefaultRange: The default range used in case of a knock-out event to classify the
remaining days until the GuaranteedPeriodEndDate. Allowable values are
1, 2, . . . , r where r is the number of defined ranges.
• KnockOutLevel: The knock out price. See Strike for more details and allowable
values.
• KnockOutType: The KnockOut Barrier type, can be UpOut or DownOut
• GuaranteedPeriodEndDate: The last date of the guaranteed period. Allowable
values are any valid dates.

616
Listing 438: Accumulator type 02 script.

REQUIRE SIZE(ObservationDates) == SIZE(KnockOutSettlementDates);

REQUIRE SIZE(ObservationPeriodEndDates) == SIZE(SettlementDates);
REQUIRE SIZE(RangeUpperBounds) == SIZE(RangeLowerBounds);
REQUIRE SIZE(RangeUpperBounds) == SIZE(RangeLeverages);
NUMBER Payoff, fix, d, dd, KnockedOut, currentNotional, Days[SIZE(RangeUpperBounds)];
NUMBER currentPeriod, r;
currentPeriod = 1;
FOR d IN (1, SIZE(ObservationDates)) DO
fix = Underlying(ObservationDates[d]);
IF KnockedOut == 0 THEN
IF {KnockOutType == 4 AND fix >= KnockOutLevel} OR
{KnockOutType == 3 AND fix <= KnockOutLevel} THEN
KnockedOut = 1;
FOR dd IN (d + 1, SIZE(ObservationDates)) DO
IF ObservationDates[d] <= GuaranteedPeriodEndDate THEN
Days[DefaultRange] = Days[DefaultRange] + 1;
END;
END;
FOR r IN (1, SIZE(RangeUpperBounds)) DO
value = value + PAY( LongShort * FixingAmount * RangeLeverages[r] * Days[r]
* ( fix - Strike ),
ObservationDates[d], KnockOutSettlementDates[d], PayCcy );
END;
END;
END;
IF KnockedOut == 0 THEN
FOR r IN (1, SIZE(RangeUpperBounds)) DO
IF fix > RangeLowerBounds[r] AND fix <= RangeUpperBounds[r] THEN
Days[r] = Days[r] + 1;
END;
END;
IF ObservationDates[d] >= ObservationPeriodEndDates[currentPeriod] THEN
FOR r IN (1, SIZE(RangeUpperBounds)) DO
value = value + PAY( LongShort * FixingAmount * RangeLeverages[r] * Days[r]
* ( fix - Strike ),
ObservationDates[d], SettlementDates[currentPeriod], PayCcy );
END;
END;
END;
IF ObservationDates[d] >= ObservationPeriodEndDates[currentPeriod] THEN
currentPeriod = currentPeriod + 1;
IF currentNotional == 0 THEN
FOR r IN (1, SIZE(RangeUpperBounds)) DO
currentNotional = currentNotional + FixingAmount * RangeLeverages[r] * Days[r] * Strike;
END;
END;
FOR r IN (1, SIZE(RangeUpperBounds)) DO
Days[r] = 0;
END;
END;
END;

617
8.2.80 Target Redemption Forward (TaRF)
The FxTaRFData, EquityTaRFData, CommodityTaRFData is the trade data container
for the FxTaRF, EquityTaRF, CommodityTaRF trade type, listings 439 and 440 show
the structure of example trades for an FX and Equity underlying.

Listing 439: FxTaRF data

<Trade id="FX_TARF">
<TradeType>FxTaRF</TradeType>
<Envelope/>
<FxTaRFData>
<Currency>USD</Currency>
<FixingAmount>1000000</FixingAmount>
<TargetAmount>100000</TargetAmount>
<Strike>1.1</Strike>
<Underlying>
<Type>FX</Type>
<Name>ECB-EUR-USD</Name>
</Underlying>
<ScheduleData>
<Dates>
<Dates>
<Date>2017-03-01</Date>
<Date>2020-03-01</Date>
<Date>2025-03-01</Date>
<Date>2029-03-01</Date>
</Dates>
</Dates>
</ScheduleData>
<OptionData>
<LongShort>Long</LongShort>
<PayoffType>TargetExact</PayoffType>
</OptionData>
<RangeBounds>
<RangeBound>
<RangeTo>1.05</RangeTo>
<Leverage>2</Leverage>
</RangeBound>
<RangeBound>
<RangeFrom>1.1</RangeFrom>
<Leverage>1</Leverage>
</RangeBound>
</RangeBounds>
<Barriers>
<BarrierData>
<Type>CumulatedProfitCap</Type>
<Levels>
<Level>100000</Level>
</Levels>
</BarrierData>
</Barriers>
</FxTaRFData>
</Trade>

618
Listing 440: EquityTaRF data

<Trade id="EQ_TARF">
<TradeType>EquityTaRF</TradeType>
<Envelope/>
<EquityTaRFData>
<Currency>USD</Currency>
<FixingAmount>775</FixingAmount>
<Strike>2900</Strike>
<Underlying>
<Type>Equity</Type>
<Name>RIC:.SPX</Name>
</Underlying>
<ScheduleData>
<Dates>
<Dates>
<Date>2017-03-01</Date>
<Date>2020-03-01</Date>
<Date>2025-03-01</Date>
<Date>2026-03-01</Date>
<Date>2027-03-01</Date>
<Date>2028-03-01</Date>
</Dates>
</Dates>
</ScheduleData>
<OptionData>
<LongShort>Long</LongShort>
<PayoffType>TargetFull</PayoffType>
</OptionData>
<RangeBounds>
<RangeBound>
<RangeTo>3300</RangeTo>
<Leverage>1</Leverage>
</RangeBound>
<RangeBound>
<RangeFrom>3300</RangeFrom>
<Leverage>2</Leverage>
<StrikeAdjustment>100</StrikeAdjustment>
</RangeBound>
</RangeBounds>
<Barriers>
<BarrierData>
<Type>FixingCap</Type>
<Levels>
<Level>3</Level>
</Levels>
</BarrierData>
</Barriers>
</EquityTaRFData>
</Trade>

The payout formula for each fixing date of a TaRF - for a Long position - is:
P ayout = RangeBound(Leverage) · F ixingAmount · (f ix − Strike(global/local))
The meanings and allowable values of the elements in the data node follow below.
• Currency: The payout currency of the TaRF. The TargetAmount and the result

619
 of the payout formula above are expressed in this currency. For FX, this should
be CCY2 as defined in the Name field in the Underlying node. Note that for
(non-quanto) FxTaRFs this should be the domestic (CCY2) currency, as defined in
the Name field in the Underlying node. For non-quanto Equity- and
CommodityTaRFs this should be the currency the equity or commodity is quoted
in. Notice section “Payment Currency” in ore/Docs/ScriptedTrade.
Allowable values: See Table 32 Currency.
• FixingAmount: The unlevered FixingAmount amount to be used at each fixing
date, as per the payout formula above.
For FxTaRFs: The FixingAmount is expressed in the foreign currency (CCY1).
For EquityTaRFs: The FixingAmount is expressed as number of shares/units of
the underlying equity or equity index.
For CommodityTaRFs: The FixingAmount is expressed as number of units of the
underlying commodity.
Allowable values: Any positive real number. Note that the FixingAmount must
be positive both for Long and Short positions.
• TargetAmount[Optional]: If PayoffType = TargetExact, after a knock-out event
the last payout is adjusted so that the cumulated profit since the start of the
TaRF matches the target amount. TargetAmount is optional, only required for
PayoffType = TargetExact. The TargetAmount is a currency amount, for
FxTaRFs it is in (CCY2).
Notice that if the barrier type is CumulatedProfitCapPoints the last payout is
adjusted in a way such that the cumulated profit in relative terms (as defined for
this barrier type below) matches the target amount divided by the fixing amount
(i.e. the target amount in points).
Allowable values: Any positive real number.
• TargetPoints[Optional]: For PayoffType = TargetExact, this provides an
alternative way of expressing the TargetAmount as a percentage of
FixingAmount in decimal form. For example a FixingAmount = 1, 000, 000 and
TargetPoints = 0.0700 translates to a TargetAmount = 70, 000.
Allowable values: Any positive real number.
• Strikes [Optional]: Global strikes associated to the ranges. Either this node or
the Strike node must be given to specify (a) global strike(s) valid across all
ranges. If no such global strikes are given, the strikes have to be specified as part
of the range bound definition. The Strikes node represents time-varying strikes
while the Strike node represents a strike that is constant over time. If the Strikes
node is given, it must contain a number of Strike subnodes. Either
– the Strike subnodes except the first one must contain an attribute startDate
which indicates from which fixing date on the strike is valid. The first strike
is valid until the minimum startDate given in the other nodes, or
– the values in the Strike subnodes are associated to the given fixing dates in
their order, the number of values must be equal to the number of fixing

620
 dates or less, in the latter case the last given value is repeated to match the
number of fixing dates.
See the description under Strike for further information on the single strike
values and the relation to strike information given in range bounds.
• Strike [Optional]: Global strike associated to the ranges. Is overwritten by local
strikes defined in RangeBounds or modified by range strike adjustments. Note
that each RangeBound needs a strike, either the global strike defined here, or a
local one in the RangeBounds nodes which then overwrites the global one. For
FX, the strike is expressed as amount in CCY2 per one unit of CCY1 as defined in
the Name field in the Underlying node.
The logic for global and local strikes is as follows:
- if a local Strike for a range is given, this local Strike will be used for the range
(a global Strike will be ignored if given)
- otherwise if a global Strike and a local StrikeAdjustment are given, the strike
used for the range will be global Strike + local StrikeAdjustment
- otherwise if a global Strike, but no local StrikeAdjustment is given, the strike
used for the range will be the global Strike
- if no global strike and no local strike is given for an range, an error is thrown,
since the strike information is not sufficient
Allowable values: Any positive real number.
• Underlying: A node with the underlying of the TaRF instrument.
For FxTaRFs: Type is set to FX and Name is a string on the form
SOURCE-CCY1-CCY2 where CCY1 is the foreign currency, CCY2 is the domestic
currency, and SOURCE is the fixing source, see Table 38 and 8.3.29.
For EquityTaRFs: Type is set to Equity and Name and other fields are as outlined
in 8.3.29
For CommodityTaRFs: Type is set to Commodity and Name is an identifier of the
commodity as outlined in 8.3.29 and in Table 42.
Allowable values: Any FX, Equity or Commodity underlying as specified in 8.3.29
• ScheduleData: The fixing dates schedule of the TaRF.
Allowable values: See 8.3.4
• SettelementLag [Optional]: The settlement delay.
Allowable values: Any period definition (e.g. 2D, 1W, 1M, 1Y ). If omitted or left
blank, defaults to 0D.
• SettlementCalendar [Optional]: The calendar used to compute the settlement
date from the corresponding fixing date.
Allowable values: Any valid calendar, see Table 34 Calendar. If omitted or left
blank, defaults to the NullCalendar (no holidays).
• SettlementConvention [Optional]: The convention used to compute the
settlement date from the corresponding fixing date.

621
 Allowable values: Any valid roll convention (U,F,P,MF,MP ), see Table 31 Roll
Convention. If omitted or left blank, defaults to F (following).
• OptionData: This is a trade component sub-node outlined in section 8.3.1. The
relevant fields in the OptionData node for an TaRF are:
– LongShort The allowable values are Long or Short.
– PayoffType can be TargetFull, TargetExact, or TargetTruncated, impacting
the payment after a Knock-Out event as per:
TargetExact: the payment is set to the pre-determined TargetAmount
TargetFull : the unadjusted payment is made
TargetTruncated : no payment is made
• RangeBoundSet: Time-varying range-bound information. Either this node or the
RangeBonds node (for time-independent range bounds) must be given. If the
RangeBoundSet node is given, it must contain a number of RangeBounds nodes.
Either
– the RangeBounds subnodes except the first one must contain an attribute
startDate which indicates from which fixing date on the values are valid.
The first value is valid until the minimum startDate given in the other
nodes, or
– the values in the RangeBounds subnodes are associated to the given fixing
dates in their order, the number of RangeBounds subnodes must be equal to
the number of fixing dates or less, in the latter case the last given
RangeBounds subnode is repeated to match the number of fixing dates.
See the description under RangeBounds for further information on the single
RangeBounds nodes.
• RangeBounds: Nodes for the specification of ranges (intervals) and associated
Leverage, local Strike and local StrikeAdjustment. A range/interval can be
specified to apply for all values the underlying can take, or for specific ranges
using RangeFrom and RangeTo. Multiple RangeBound sub-nodes can be included
within the RangeBounds node. If the value for RangeFrom is omitted it is
interpreted as −∞ (unbounded towards minus infinity). If RangeTo is omitted it
is interpreted as ∞ (unbounded towards plus infinity). Note that if the
underlying takes a value not covered by any range/interval, no payout will occur.
For FxTaRFs: The the Strike, StrikeAdjustment, RangeFrom and RangeTo Fx
rates are all defined as amount in domestic currency (CCY2) for one unit of
foreign currency (CCY1).
For Equity- and CommodityTaRFs: The Strike, StrikeAdjustment, RangeFrom
and RangeTo are all defined as the value of one unit/share/contract of the
underlying equity or commodity, expressed in the currency the equity or
commodity is quoted in.
Allowable values: For each range, see 8.3.32. Note that an interval/range can’t
have both a local Strike and a local StrikeAdjustment. If no global Strike is
given, each interval/range must have a local Strike.

622
 • Barriers[Optional]: Specification of barriers, see 8.3.31. Multiple BarrierData
sub-nodes can be included within the Barriers node. Relevant fields for each
TaRF BarrierData sub-node are Type and Level. For a TaRF, Type can be set
to CumulatedProfitCap, CumulatedProfitCapPoints or FixingCap. Notice that
CumulatedProfitCapPoints can not be combined with the other barrier types.
– CumulatedProfitCap: The TaRF terminates once the generated profit from
the long side’s view reaches the CumulatedProfitCap. (Continuous TaRF)
For an FxTaRF the CumulatedProfitCap is quoted in CCY2.
Allowable values: The Level for a CumulatedProfitCap can be set to any
non-negative real number.
– CumulatedProfitCapPoints: The TaRF terminates once the generated profit
from the long side’s view reaches the CumulatedProfitCapPoints.
(Continuous TaRF) Here, the generated profit is measured as the absolute
profit amount (as used in CumulatedProfitCap) divided by the
FixingAmount and divided by the absolute value of the leverage.
Allowable values: The Level for a CumulatedProfitCapPoints can be set to
any non-negative real number.
– FixingCap: The TaRF terminates once number of fixings where a profit is
generated - from the long side’s view -reaches the FixingCap. (Digital
TaRF)
Allowable values: The Level for a FixingCap can be set to a non-negative
integer.
Target Redemption Forwards can alternatively represented as scripted trades, refer to
the scripted trade documentation in ore/Docs/ScriptedTrade for an introduction. This
representation does not allow for time varying strikes or range bounds and also not for
a target amount / cumulated profit cap specification in points.

<Trade id="TaRF#1">
<TradeType>ScriptedTrade</TradeType>
<Envelope/>
<TaRFData>
<FixingAmount type="number">1000000</FixingAmount>
<LongShort type="longShort">Long</LongShort>
<Underlying type="index">FX-ECB-EUR-USD</Underlying>
<PayCcy type="currency">USD</PayCcy>
<FixingDates type="event">
<ScheduleData>
<Dates>
<Dates>
<Date>2017-03-01</Date>
<Date>2020-03-01</Date>
<Date>2025-03-01</Date>
<Date>2029-03-01</Date>
</Dates>
</Dates>
</ScheduleData>
</FixingDates>
<SettlementDates type="event">
<DerivedSchedule>
<BaseSchedule>FixingDates</BaseSchedule>

623
 <Shift>2D</Shift>
<Calendar>TARGET</Calendar>
<Convention>F</Convention>
</DerivedSchedule>
</SettlementDates>
<RangeUpperBounds type="number">
<Value>1.05</Value>
<Value>10000</Value>
</RangeUpperBounds>
<RangeLowerBounds type="number">
<Value>0</Value>
<Value>1.1</Value>
</RangeLowerBounds>
<RangeLeverages type="number">
<Value>2</Value>
<Value>1</Value>
</RangeLeverages>
<RangeStrikes type="number">
<Value>1.1</Value>
<Value>1.1</Value>
</RangeStrikes>
<KnockOutProfitAmount type="number">100000</KnockOutProfitAmount>
<KnockOutProfitEvents type="number">0</KnockOutProfitEvents>
<TargetAmount type="number">100000</TargetAmount>
<TargetType type="number">0</TargetType>
</TaRFData>
</Trade>

The TaRF script referenced in the trade above is shown in Listing 441.
The meanings and allowable values of the elements in the TaRFData node below.
• [number] FixingAmount: Amount to buy/sell on each fixing day should be
FixingAmount times Leverage of the range that the spot level fixes within.
Allowable values: Any positive real number.
• [longShort] LongShort: Long if we buy the option. Short if we sell the option.
Allowable values: Long, Short
• [index] Underlying: Underlying index.
Allowable values: See ore/Docs/ScriptedTrade’s Index Section for allowable
values.
• [currency] PayCcy: The payment currency. For FX, where the underlying is
provided in the form FX-SOURCE-CCY1-CCY2 (see Table 38) this should be CCY2.
If CCY1 or the currency of the underlying (for EQ and COMM underlyings), this
will result in a quanto payoff. Notice section “Payment Currency” in
ore/Docs/ScriptedTrade.
Allowable values: See Table 32 for allowable currency codes.
• [event] FixingDates: The fixing dates, given as a ScheduleData node
Allowable values: See section 8.3.4 Schedule Data and Dates, or DerivedSchedule
(see the scripted trade documentation in ore/Docs/ScriptedTrade).
• [event] SettlementDates: The settlement dates, given as a ScheduleData or
DerivedSchedule node. Allowable values: See section 8.3.4 Schedule Data and

624
 Dates, or DerivedSchedule (see the scripted trade documentation in
ore/Docs/ScriptedTrade).
• [number] RangeUpperBound: Values of upperbounds for the leverage ranges. If a
given range has no upperbound, add 100000.
Allowable values: Any list of positive real numbers. RangeUpperBound,
RangeLowerBound and RangeLeverages must have the same size.
RangeUpperBound [i] ≥ RangeLowerBound [i] for all i
• [number] RangeLowerBound: Values of lowerbounds for the leverage ranges. If a
given range has no lowerbound add 0
Allowable values: Any list of positive real numbers.
• [number] RangeLeverages: Values of leverages for the leverage ranges. Positive
for Bullish TaRF, Negative for Bearish TaRF.
Allowable values: Any list of real numbers.
• [number] RangeStrikes: Strikes associated to the ranges. .
Allowable values: Any positive real number.
• [number] KnockOutProfitAmount: If positive, cap of the profit the buyer can
make.
Allowable values: Any positive real number or zero if not applicable.
• [number] KnockOutProfitEvents: If positive, cap of the number of fixing days
on which buyer makes profit.
Allowable values: Any positive real number or zero if not applicable.
• [number] TargetAmount: The target amount to be paid as an accumulated profit
for TargetType = exact.
Allowable values: Any positive real number or zero if not applicable.
• [number] TargetType: -1 for truncated, 0 for exact, 1 for full. If
DigitalKnockOut is true the target type must be set to full.
Allowable values: -1,0,1

8.2.81 Knock Out Swap

A Knock Out Swap is represented using the TradeType KnockOutSwap and a
KnockOutSwapData block as shown in listing 442. It must have one BarrierData
node, and two legs, one fixed and one floating, each represented by a LegData trade
component.
A Knock Out Swap is a Swap with one Fixed and one Floating leg, where the Swap is
terminated if the Floating leg Index hits a barrier. The barrier is monitored on all
floating leg fixing dates after the BarrierStartDate.
The meanings and allowable values in this block are as follows:
• BarrierData: This node specifies the barrier Type and Level. The Type must be
UpAndOut or DownAndOut. Exactly one Level must be specified. All other
values of the barrier data block are not relevant.
Allowable values: See 8.3.31.

625
 • BarrierStartDate: The barrier is monitored on all floating leg fixing dates that
are on or after the barrier start date.
Allowable values: See Date in Table 30.
• LegData: This specifies the swap terms. Exactly two LegData nodes must be
given, one of type Fixed and one of type Floating.
Allowable values: See 8.3.3.

8.2.82 Flexi Swap

A Flexi Swap is an amortizing swap in which one party has the option to further
reduce the notional in each period to each value between the current notional and a
specified lower bound for that period.
Flexi Swaps are priced in ORE following the Replication Approach described in (F.
Jamshidian, 2005). The replicating basket of Bermudan Swaptions is priced using the
method as described under Product Type “Bermudan Swaption”, but using one global
calibration for all swaptions derived from the flexi swap structure. Prepayment option
types “ReductionByAbsoluteAmount” and “ReductionUpToAbsoluteAmount” are both
treated approximately by generating a schedule of deterministic, lower notional bounds
from assuming that all earlier prepayment options were executed.
The FlexiSwapData node is the trade data container for trade type Flexi Swap. A
Flexi Swap is a two-legged swap with optional and customisable pre-payments. Flexi
Swaps are typically used for representing swaps linked to Asset Backed Securities with
flexible amortisation. A Flexi Swap must have two legs, one fixed and one floating.
The floating leg must have a pay frequency that is a multiple of the fixed leg frequency
and corresponding floating and fixed leg periods must have the same notional. The
legs typically have an amortising notional and are represented by LegData trade
component sub-nodes, described in section 8.3.3. The FlexiSwapData node also
contains a OptionLongShort node indicating the holder of the prepayment option and
a node describing the optional prepayments, see below.
An example structure of a FlexiSwapData node is shown in Listing 443. In this case
the optional pre-payments are given by a subnode LowerNotionalBounds meaning
that the notional of the swap can be reduced to any value between the given lower
bound and the original notional in each fixed leg period.

626
Listing 443: Flexi Swap data

<FlexiSwapData>
<LowerNotionalBounds>
<Notional>451389557.145667</Notional>
<Notional>427876791.621303</Notional>
<Notional>404435982.369285</Notional>
<Notional>379353200.32956</Notional>
...
</LowerNotionalBounds>
<OptionLongShort>Short</OptionLongShort>
<LegData>
<LegType>Fixed</LegType>
...
</LegData>
<LegData>
<LegType>Floating</LegType>
...
</LegData>
</FlexiSwapData>

Alternatively the optional pre-payments can be described by a subnode

NotionalDecreases which is more general than the description via
LowerNotionalBounds (using the reduction type RedutionToLowerBound, see below
for more details on this), see Listing 444 for an example.

627
Listing 444: Flexi Swap data

<FlexiSwapData>
<Prepayment>
<NoticePeriod>5D</NoticePeriod>
<NoticeCalendar>TARGET</NoticeCalendar>
<NoticeConvention>F</NoticePeriod>
<PrepaymentOptions>
<PrepaymentOption>
<ExerciseDate>2015-02-01</ExerciseDate>
<Type>ReductionUpToLowerBound</Type>
<Value>404435982.369285</Value>
</PrepaymentOption>
<PrepaymentOption>
<ExerciseDate>2016-02-01</ExerciseDate>
<Type>ReductionByAbsoluteAmount</Type>
<Value>100000.0</Value>
</PrepaymentOption>
<PrepaymentOption>
<ExerciseDate>2017-02-01</ExerciseDate>
<Type>ReductionUpToAbsoluteAmount</Type>
<Value>50000.0</Value>
</PrepaymentOption>
<PrepaymentOptions>
</Prepayment>
<OptionLongShort>Short</OptionLongShort>
<LegData>
<LegType>Fixed</LegType>
...
</LegData>
<LegData>
<LegType>Floating</LegType>
...
</LegData>
</FlexiSwapData>

The meanings and allowable values of the elements in the FlexiSwapData node follow
below.
• OptionLongShort: Specifies which party has the right to pre-pay the notional
down to the lower notional bound. Short means that for pricing purposes
pre-payments are assumed to be done in such a way to maximise the value of the
Flexi Swap for the “other” counterparty, Long means that the Flexi Swap value is
maximised from “our” point of view.
Allowable values: Long or Short
• LegData: This is a trade component sub-node outlined in section 8.3.3. A Flexi
Swap must have two LegData nodes and the LegType element must be set to
Floating on one leg and Fixed on the other. The two legs must have the same
Currency. The float leg pay frequency must be a multiple of the fixed leg
frequency.
The optional prepayments are described by either a LowerNotionalBounds node or a
Prepyment node.

628
In case the optional prepayments are described by a LowerNotionalBounds node, the
minimum level to which the notional can be amortised down to must be given as a
notional schedule. The schedule can be specified as described in 8.3.3, i.e. using a
sequence of Notional subnodes or using the startDate attribute to specify notional
changes. The given schedule must be given for the fixed leg periods since the notional
can be decreased for each whole fixed leg period and the corresponding floating leg
periods (remember that the floating leg frequency must be a multiple of the fixed leg
frequency). Each lower notional bound child element can take a positive real number
that cannot exceed the notional amount of the corresponding coupon period on either
leg and (from the second fixed coupon period on) the lower notional bound of the
previous coupon period.
In case the optional prepayments are described by a Prepayment node, the the single
exercise opportunities are described by a PrepaymentOptions subnode that contains
one or several PerpaymentOption subnodes, each of which comprises the following
elements:
• ExerciseDate: The date on which the notional can be decreased.
• Type: The type of the allowed notional reduction. The allowable types are
– ReductionUpTpLowerBound: The notional can be reduced to any value
between the current notional and the lower bound given in the Value node.
– ReductionByAbsoluteAmount: The notional can be reduced by an absolute
amount given in the Value node. If this value is greater than the current
notional, the reduction amount is equal to the current notional.
– ReductionUpToAbsoluteAmount: The notional can be reduced by any value
between zero and a given absolute amount (given in the Value node).
• Value: The value that together with the type describes the amount by which the
notional can be decreased.
In addition the Prepayment node contains the following optional subnodes describing
the conventions for deriving the option notice date from the exercise date:
• NoticePeriod [Optional]: The notice period defining the date (relative to the
exercise date) on which the exercise decision has to be taken. If not given the
notice period defaults to 0D, i.e. the notice date is identical to the exercise date.
• NoticeCalendar [Optional]: The calendar used to compute the notice date from
the exercise date. If not given defaults to the null calendar (no holidays,
weekends are no holidays either).
• NoticeConvention [Optional]: The convention used to compute the notice date
from the exercise date. Defaults to Unadjusted if not given.

8.2.83 Balance Guaranteed Swap (BGS)

A Balance Guaranteed Swap is similar to an amortizing interest rate swap, but the
notional amortization matches actual prepayments of a Reference Security which can
be either a tranche or a reference pool of assets, or securitized interest backed by a

629
pool of assets. The BGS differs from an amortizing swap in that the notional
amortizations are uncertain.
BGS are priced in ORE yusing an auxiliary Flexi Swap as a proxy. The amortization
schedule of the Flexi Swap is set up as the notional schedule of the BGS assuming a
zero CPR (Conditional Prepayment Rate). The lower notional bound of the Flexi
Swap is constructed assuming a MaxCPR (Maximum Conditional Prepayment Rate)
which is dependent on the Reference Security. The MaxCPR is estimated on the basis
of the current CPR, historical CPRs and / or expert judgement as to provide a
(hypothetical) sufficiently realistic hedge for the BGS. The option holder in the Flexi
Swap is the payer of the structured leg (i.e. the leg replicating the payments of the
reference security) in the BGS.
The BalanceGuaranteedSwapData node is the trade data container for trade type
BalanceGuaranteedSwap. A BGS must have two legs, one fixed and one floating. Each
leg typically has an amortising notional and is represented by a LegData trade
component sub-node, described in section 8.3.3. The BalanceGuaranteedSwapData
node also contains a ReferenceSecurity sub-node specifying the Asset Backed
Security to which the notional schedule of the BGS is linked. An example structure of
a BalanceGuaranteedSwapData node is shown in Listing 445.

Listing 445: Balance Guaranteed Swap data

<BalanceGuaranteedSwapData>
<ReferenceSecurity>ISIN:XS0983610930</ReferenceSecurity>
<Tranches>
<Tranche>
<Description>Class A</Description>
<SecurityId>ISIN:XS0983610930</SecurityId>
<Seniority>1</Seniority>
<Notionals>
...
</Notionals>
</Tranche>
<Tranche>
<Description>Class B</Description>
<SecurityId>ISIN:XS0983610931</SecurityId>
<Seniority>2</Seniority>
<Notionals>
...
</Notionals>
</Tranche>
<ScheduleData>
...
</ScheduleData>
</Tranches>
<LegData>
<LegType>Fixed</LegType>
...
</LegData>
<LegData>
<LegType>Floating</LegType>
...
</LegData>
<BalanceGuaranteedSwapData>

630
The meanings and allowable values of the elements in the
BalanceGuaranteedSwapData node follow below.
• ReferenceSecurity: The ISIN of the Asset Backed Security tranche to which the
BGS is linked.
Allowable values: The prefix ISIN: followed by an ISIN code for the Reference
Security.
• Tranches: A description of the Asset Backed Security tranche notionals. Each
Tranche is identified by a SecurityId and an optional Description. Each
Tranche has a Seniority given as a positive integer value where lower values
mean higher seniority, i.e. 1 is the most senior tranche (e.g. “class A”) followed
by 2 (e.g. “class B”) etc. The notionals are given in a sub-node Notionals as
described in section 8.3.3 w.r.t. a schedule given in ScheduleData which is
shared across all tranches. There must be exactly one tranche with a security id
matching the reference security.
• LegData: This is a trade component sub-node outlined in section 8.3.3. A BGS
must have two LegData nodes and the LegType element must be set to Floating
on one leg and Fixed on the other. The two legs must have the same Currency.
The notionals of the swap and the referenced tranche must be consistent. Furthermore,
notionals for periods with a start date in the past must be given with their actual
value, i.e. including actual prepayments that were made in the previous periods.
Notionals for periods with a start dats in the future on the other hand must be given
assuming a zero conditional prepayment rate. For the latter periods a prepayment
model is used to generate suitable notional schedules when pricing the swap. The
prepayment model assumes that tranches with higher seniority are amortised first, i.e.
in the example here the class A tranche is amortised before the class B tranche.

8.3 Trade Components

Trade components are XML sub-nodes used within the trade data containers to define
sets of trade data that more than one trade type can have in common, such as a leg or
a schedule. A trade data container can include multiple trade components such as a
swap with multiple legs, and a trade component can itself contain further trade
components in a nested way.

An example of a SwapData trade data container, including two LegData trade

components which in turn include further trade components such as FixedLegData,
ScheduleData and FloatingLegData is shown in Listing 446.

631
Listing 446: Trade Components Example

<SwapData>
<LegData>
<Payer>true</Payer>
<LegType>Fixed</LegType>
<Currency>EUR</Currency>
<PaymentConvention>Following</PaymentConvention>
<DayCounter>30/360</DayCounter>
<Notionals>
<Notional>1000000</Notional>
</Notionals>
<ScheduleData>
...
</ScheduleData>
<FixedLegData>
<Rates>
<Rate>0.035</Rate>
</Rates>
</FixedLegData>
</LegData>
<LegData>
...
<ScheduleData>
...
</ScheduleData>
<FloatingLegData>
...
</FloatingLegData>
</LegData>
</SwapData>

Descriptions of all trade components supported in ORE follow below.

8.3.1 Option Data

This trade component node is used within the SwaptionData and FXOptionData trade
data containers. It contains the ExerciseDates sub-node which includes
ExerciseDate child elements. An example structure of the OptionData trade
component node is shown in Listing 447.

632
Listing 447: Option data

<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>Bermudan</Style>
<NoticePeriod>5D</NoticePeriod>
<NoticeCalendar>TARGET</NoticeCalendar>
<NoticeConvention>F</NoticePeriod>
<Settlement>Cash</Settlement>
<SettlementMethod>CollateralizedCashPrice</SettlementMethod>
<PayOffAtExpiry>true</PayOffAtExpiry>
<ExerciseFees>
<ExerciseFee type="Percentage">0.0020</ExerciseFee>
<ExerciseFee type="Absolute" startDate="2020-04-20">25000</ExerciseFee>
</ExerciseFees>
<ExerciseFeeSettlementPeriod>2D</ExerciseFeeSettlementPeriod>
<ExerciseFeeSettlementConvention>F</ExerciseFeeSettlementConvention>
<ExerciseFeeSettlementCalendar>TARGET</ExerciseFeeSettlementCalendar>
<ExerciseDates>
<ExerciseDate>2019-04-20</ExerciseDate>
<ExerciseDate>2020-04-20</ExerciseDate>
</ExerciseDates>
<!-- Alternative format for exercise dates using Schedule format -->
<ExerciseSchedule>
<Rules>
<StartDate>2019-04-20</StartDate>
<EndDate>2024-04-20</EndDate>
<Tenor>3M</Tenor>
</Rules>
</ExerciseSchedule>
<Premiums>
<Premium>
<Amount>100000</Amount>
<Currency>EUR</Currency>
<PayDate>2018-05-07</PayDate>
</Premium>
</Premiums>
<AutomaticExercise>...</AutomaticExercise>
<ExerciseData>
<Date>...</Date>
<Price>...</Price>
</ExerciseData>
<PaymentData>...</PaymentData>
</OptionData>

The meanings and allowable values of the elements in the OptionData node follow
below.
• LongShort: Specifies whether the option position is long or short. Note that for
Swaptions, Callable Swaps, and Index CDS Options setting LongShort to short
makes the Payer indicator on the underlying Swap / Index CDS to be set from
the perspective of the Counterparty.
Allowable values: Long, L or Short, S
• OptionType: Specifies whether it is a call or a put option. Optional for trade

633
types Swaption and CallableSwap.
Allowable values: Call or Put
The meaning of Call and Put values depend on the trade type and asset class of
the option, see Table 24.

634
Asset Class and Trade Type Call / Put Specifications
Equity/ Commodity/Bond Op- Call : The right to buy the underlying equi-
tion ty/commodity/bond at the strike price.
Put: The right to sell the underlying equi-
ty/commodity/bond at the strike price.
IR Swaption, CallableSwap, Call/Put values are ignored, and the Option-
Commodity Swaption Type field is optional. Payer/Receiver swap-
tion is determined by the Payer fields in the
Leg Data nodes of the underlying swap.
FX Options (all variants, except Call : Bought and Sold currencies/amounts
Touch, Digital, Asian) stay as determined in the trade data node.
Put: Bought and Sold currencies/amounts
are switched compared to the trade data
node. Note that barriers are not switched
/ unaffected.
Index CDS Option Call/Put values are ignored, and the Option-
Type field is optional. The Payer field in the
underlying Index CDS leg determines if the
option is to buy or sell protection.
Asian FX Options Call : The right to buy/receive the underly-
ing currency at the strike price.
Put: The right to sell/pay the underlying
currency at the strike price.
Digital FX Options Call : The digital payout will occur if the fx
rate at the expiry date is above the given
strike,
Put: The digital payout will occur if the fx
rate at the expiry date is below the given
strike.
FX Single Touch Options Call/Put values are ignored, and are instead
inferred from the BarrierData type, and the
OptionType field is optional.
FX Double Touch Options Call/Put values are ignored, and and the Op-
tionType field is optional.
Ascot Call has payout:

max(0, convertibleP rice − Strike)

Put has payout:

max(0, Strike − convertibleP rice)

Table 24: Specification of Option Type Call / Put

• PayoffType [Optional, except for trade types detailed below]: Specifies a detailed
payoff type for exotic options. Only applicable to specific trade types as
indicated in parentheses:

635
 Allowable values:
– Accumulator, Decumulator (applies to trade types EquityAccumulator,
FxAccumulator, CommodityAccumulator only)
– TargetFull, TargetExact, TargetTruncated (applies to trade types
EquityTaRF, FxTaRF, CommodityTaRF only)
– BestOfAssetOrCash, WorstOfAssetOrCash, MaxRainbow, MinRainbow
(applies to trade types EquityRainbowOption, FxRainbowOption,
CommodityRainbowOption only)
– Vanilla, Asian, AverageStrike, LookbackCall, LookbackPut (applies to trade
types EquityBasketOption, FxBasketOption, CommodityBasketOption
only)
– Asian (applies to trade types EquityAsianOption, FxAsianOption only)
– Vanilla, AssetOrNothing, CashOrNothing (applies to trade type
FxGenericBarrierOption, EquityGenericBarrierOption,
CommodityGenericBarrierOption)
• Style: The exercise style of the option.
Allowable values: European or American or Bermudan.
Note that trade types IR Swaption and CallableSwap can have all three styles:
European, Bermudan, or American.
FX, Equity and Commodity vanilla options can have styles European or
American, but not Bermudan.
Exotic FX, Equity and Commodity options can generally only have style
European, see each trade type for details.
Commodity Swaption and Commodity Average Price Options must have style
European.
Index CDS Options must have style European.
Ascots must have style American.
• PayoffType2 [Optional]: Subtype for payoff of exotic options. Only applicable to
specific trade types as indicated in parantheses:
Allowable values:
– Arithmetic, Geometric (applies to trade types EquityAsianOption,
FxAsianOption only, if not given it defaults to Arithmetic)
• NoticePeriod [Optional]: The notice period defining the date (relative to the
exercise date) on which the exercise decision has to be taken. If not given the
notice period defaults to 0D, i.e. the notice date is identical to the exercise date.
Only supported for Swaptions and Callable Swaps currently.
• NoticeCalendar [Optional]: The calendar used to compute the notice date from
the exercise date. If not given defaults to the null calendar (no holidays,
weekends are no holidays either).

636
 • NoticeConvention [Optional]: The convention used to compute the notice date
from the exercise date. Defaults to Unadjusted if not given.
• Settlement: Delivery type. Note that Settlement is not required for Asian
options.
Allowable values: Cash or Physical
• SettlementMethod [Optional]: Specifies the method to calculate the settlement
amount for Swaptions and CallableSwaps.
Allowable values: PhysicalOTC, PhysicalCleared, CollateralizedCashPrice,
ParYieldCurve.
Defaults to ParYieldCurve if Settlement is Cash and defaults to PhysicalOTC if
Settlement is Physical.
PhysicalOTC = OTC traded swaptions with physical settlement
PhysicalCleared = Cleared swaptions with physical settlement
CollateralizedCashPrice = Cash settled swaptions with settlement price
calculation using zero coupon curve discounting
ParYieldCurve = Cash settled swaptions with settlement price calculation using
par yield discounting 12 13
• PayOffAtExpiry [Optional]: Relevant for options with early exercise, i.e. the
exercise occurs before expiry; true indicates payoff at expiry, whereas false
indicates payoff at exercise. Defaults to true if left blank or omitted.
Allowable values: true, false .
Note that for IndexCreditDefaultSwapOption PayOffAtExpiry must be set to
false as only payoff at exercise is supported.
• ExerciseFees [Optional]: This node contains child elements of type ExerciseFee.
Similar to a list of notionals (see 8.3.3) the fees can be given either
– as a list where each entry corresponds to an exercise date and the last entry
is used for all remaining exercise dates if there are more exercise dates than
exercise fee entries, or
– using the startDate attribute to specify a change in a fee from a certain
day on (w.r.t. the exercise date schedule)
Fees can either be given as an absolute amount or relative to the current notional
of the period immediately following the exercise date using the type attribute
together with specifiers Absolute resp. Percentage. If not given, the type
defaults to Absolute.
If a fee is given as a positive number the option holder has to pay a
corresponding amount if they exercise the option. If the fee is negative on the
other hand, the option holder receives an amount on the option exercise.
Only supported for Swaptions and Callable Swaps currently.
12
[Link]
13
[Link]

637
• ExerciseFeeSettlementPeriod [Optional]: The settlement lag for exercise fee
payments. Defaults to 0D if not given. This lag is relative to the exercise date
(as opposed to the notice date).
Allowable values: A number followed by D, W, M, or Y
• ExerciseFeeSettlementCalendar [Optional]: The calendar used to compute the
exercise fee settlement date from the exercise date. If not given defaults to the
NullCalendar (no holidays, weekends are no holidays either).
Allowable values: See Table 34 Calendar.
• ExerciseFeeSettlementConvention [Optional]: The convention used to compute
the exercise fee settlement date from the exercise date. Defaults to Unadjusted if
not given.
Allowable values: See Table 31 Roll Convention.
• ExerciseDates: This node contains child elements of type ExerciseDate.
Options of style European or American require a single exercise date expressed
by one single ExerciseDate child element. Bermudan style options must have
two or more ExerciseDate child elements. One can alternatively use
ExerciseSchedule to specify the option exercise dates.
• ExerciseSchedule [Optional]: This node can be provided instead of
ExerciseDates and should be specified in the same format as a Schedule (see
Section 8.3.4), e.g. for a list of Bermudan exercise dates.
• Premiums [Optional]: Option premium amounts paid by the option buyer to the
option seller.
Allowable values: See section 8.3.2
• AutomaticExercise [Optional]: Used if the option expiry date is on the current
date or in the past, and the payment date is in the future - so that there still is
an outstanding cashflow if the option was in the money on the expiry date. In
this case, if AutomaticExercise is applied, the FX / Commodity / Equity fixing
on the expiry date is used to automatically determine the payoff and thus
whether the option was exercised or not.
Currently, this field is only used for vanilla European cash settled FX, equity and
commodity options. It is a boolean flag indicating if Automatic Exercise is
applicable for the option trade. A value of true indicates that Automatic
Exercise is applicable and a value of false indicates that it is not.
Allowable values: A boolean value given in Table 46. If not provided, the default
value is false.
• ExerciseData [Optional]: Currently, this node is only used for vanilla European
cash settled FX, equity and commodity options where Automatic Exercise is not
applicable. It has the structure shown in Listing 447 i.e. a child Date and Price
node. It is used to supply the price at which an option was exercised and the
date of exercise. For a European option, the supplied date clearly has to match
the single option ExerciseDate. It is needed where the cash settlement date is
after the ExerciseDate. If this node is not supplied, and the ExerciseDate is in

638
 the past relative to the valuation date, the option is assumed to have expired
unexercised.
Allowable values: The Date node should be a valid date as outlined in Table 30
and the Price node should be a valid price as a real number.
• PaymentData [Optional]: This node is used to supply the date on which the
option is cash settled if it is exercised. There are two methods in which this data
may be supplied:
1. The first method is an explicit list of dates as shown in Listing 448. The
Date node should be a valid date as outlined in Table 30. Obviously, for
European options, there should be exactly one date supplied.
2. The second method is a set of rules that are used to generate the settlement
date relative to either the exercise date of the option or the expiry date of
the option. The structure of the PaymentData node in this case is given in
Listing 449. The optional RelativeTo node must be either Expiry or
Exercise. If it is Expiry, the expiry date is taken as the base date from
which the rules are applied. If it is Exercise, the exercise date is taken as
the base date from which the rules are applied. These two dates are the
same in the case of a European option. If not provided, Expiry is assumed.
The Lag node is a non-negative integer giving the number of days from the
base date to the cash settlement date. The Calendar gives the business day
calendar for the cash settlement date and should be a valid calendar code as
outlined in Table 34. The Convention gives the roll convention for the cash
settlement date and should be a valid roll convention as outlined in Table 31.

Listing 448: Dates based PaymentData

<PaymentData>
<Dates>
<Date>...</Date>
</Dates>
</PaymentData>

Listing 449: Rules based PaymentData

<PaymentData>
<Rules>
<Lag>...</Lag>
<Calendar>...</Calendar>
<Convention>...</Convention>
<RelativeTo>...</RelativeTo>
</Rules>
</PaymentData>

8.3.2 Premiums
The Premiums node holds data of one or more premiums to be paid. It is used in
different trade types, notably in caps / floors (see section 8.2.3) and more generally in

639
the option data component (see section 8.3.1). Listing 450 shows an example for a
Premiums data block representing two premiums.

Listing 450: Premiums Node

<Premiums>
<Premium>
<Amount>1000</Amount>
<Currency>EUR</Currency>
<PayDate>2021-01-27</PayDate>
</Premium>
<Premium>
<Amount>5000</Amount>
<Currency>USD</Currency>
<PayDate>2023-01-27</PayDate>
</Premium>
</Premiums>

The meanings and allowable values of the elements in the Premium node follow below.
• Amount: Option premium amounts paid by the option buyer to the option seller.
A positive amount is considered to be paid by the option holder to the option
seller and thus results in a negative contribution to the NPV of a long option.
Allowable values: arbitrary number
• Currency: Currency of the premium to be paid
Allowable values: See Table 32 Currency.
• PayDate: Date of the premium payment.
Allowable values: See Date in Table 30.
We support a deprecated schema to represent a single premium as shown in listing 451
for backwards compatibility. The 3 nodes PremiumAmount, PremiumCurrency,
PremiumPayDate can be used on the same level as the new Premiums node to
represent a single premium payment. The deprecated and new schema may not be
mixed.

Listing 451: Deprecated Single Premium Representation

<PremiumAmount>1000</PremiumAmount>
<PremiumCurrency>EUR</PremiumCurrency>
<PremiumPayDate>2021-01-27</PremiumPayDate>

8.3.3 Leg Data and Notionals

The LegData trade component node is used within the CapFloorData, SwapData ,
SwaptionData and EquitySwapData trade data containers. It contains a
ScheduleData trade component sub-node, and a sub-node that depends on the value
of the LegType element, e.g.: FixedLegData for LegType Fixed or FloatingLegData
for LegType Floating. The LegData node also includes a Notionals sub-node with
Notional child elements described below. An example structure of a LegData node of
LegType Floating is shown in Listing 452.

640
Listing 452: Leg data

<LegData>
<Payer>false</Payer>
<LegType>Floating</LegType>
<Currency>EUR</Currency>
<PaymentConvention>Following</PaymentConvention>
<DayCounter>30/360</DayCounter>
<Notionals>
<Notional>1000000</Notional>
</Notionals>
<ScheduleData>
...
</ScheduleData>
<FloatingLegData>
...
</FloatingLegData>
</LegData>

The meanings and allowable values of the elements in the LegData node follow below.
• LegType: Determines which of the available sub-nodes must be used.
Allowable values: Fixed, Floating, Cashflow, CMS, CMB, DigitalCMS,
DurationAdjustedCMS, CMSSpread, DigitalCMSSpread, Equity, CPI, YY,
ZeroCouponFixed, FormulaBased, CommodityFloating, CommodityFixed,
EquityMargin
• Payer: The flows of the leg are paid to the counterparty if true, and received if
false.
Allowable values: true, false
• Currency: The currency of the leg.
Allowable values: See Table 32 Currency. When LegType is Equity, Minor
Currencies in Table 32 are also allowable.
• PaymentCalendar [Optional]: The payment calendar of the leg coupons. The
PaymentCalendar is used in conjunction with the PaymentConvention,
PaymentLag and NotionalPaymentLag to determine the payments dates, unless
the PaymentDates node is used which defines the payment dates explicitly.
Allowable values: See Table 34 Calendar. If left blank or omitted, defaults to the
calendar in the ScheduleData node, unless LegType is Floating and Index is
OIS, in which case this defaults to the index calendar.
The PaymentCalendar calendar field is currently only supported for LegType
Floating (with an IBOR, BMA or OIS underlying index), CMS, CMSSpread,
DigitalCMSSpread, Equity, YY, CPI, Fixed, ZeroCouponFixed, DigitalCMS. For
unsupported legs it defaults to the schedule calendar, and if no calendar is set in
the ScheduleData node (for dates-based schedules the calendar field is optional),
the NullCalendar is used.
• PaymentConvention: The payment convention of the leg coupons.

641
 Allowable values: See Table 31.
• PaymentLag [optional]: The payment lag applies to the coupons on Fixed legs,
Equity legs, and Floating legs with Ibor and OIS indices (but not to
BMA/SIFMA indices), as well as CMS legs, CMSSpread legs, CPI legs and Zero
Coupon Fixed legs.
PaymentLag is also not supported for CapFloor Floating legs that have Ibor
coupons with sub periods (HasSubPeriods = true), nor for CapFloor Floating
legs with averaged ON coupons (IsAveraged = true).
Allowable values: Any valid period, i.e. a non-negative whole number, optionally
followed by D (days), W (weeks), M (months), Y (years). Defaults to 0D if left
blank or omitted. If a whole number is given and no letter, it is assumed that it
is a number of D (days).
• NotionalPaymentLag [optional]: The notional payment lag (in days) applied to
any notional exchanges.
Allowable values: Any non-negative integer. Defaults to zero if left blank or
omitted.
• DayCounter: The day count convention of the leg coupons. Note that
DayCounter is mandatory for all leg types except Equity.
Allowable values: See DayCount Convention in Table 35. For Equity legs, if left
blank or omitted, it defaults to ACT/365.
• Notionals: This node contains child elements of type Notional. If the notional is
fixed over the life of the leg only one notional value should be entered. If the
notional is amortising or accreting, this is represented by entering multiple
notional values, each represented by a Notional child element. The first notional
value corresponds to the first coupon, the second notional value corresponds to
the second coupon, etc. If the number of coupons exceeds the number of notional
values, the notional will be kept flat at the value of last entered notional for the
remaining coupons. The number of entered notional values cannot exceed the
number of coupons.
Allowable values: Each child element can take any positive real number.

An example of a Notionals element for an amortising leg with four coupons is

shown in Listing 453.

Listing 453: Notional list

<Notionals>
<Notional>65000000</Notional>
<Notional>65000000</Notional>
<Notional>55000000</Notional>
<Notional>45000000</Notional>
</Notionals>

Another allowable specification of the notional schedule is shown in Listing 454.

642
Listing 454: Notional list with dates

<Notionals>
<Notional>65000000</Notional>
<Notional startDate='2016-01-02'>65000000</Notional>
<Notional startDate='2017-01-02'>55000000</Notional>
<Notional startDate='2021-01-02'>45000000</Notional>
</Notionals>

The first notional must not have a start date, it will be associated with the
schedule’s start, The subsequent notionals must either all or none have a start
date specified from which date onwards the new notional is applied. This allows
specifying notionals only for dates where the notional changes.

An initial exchange, a final exchange and an amortising exchange can be

specified using an Exchanges child element with
NotionalInitialExchange, NotionalFinalExchange and
NotionalAmortizingExchange as subelements, see Listing 455. The Exchanges
element is typically used in cross-currency swaps and inflation swaps, but can
also be used in other trade and leg types. Note that for cross-currency swaps, the
NotionalInitialExchange must be set to the same value on both legs. The
NotionalFinalExchange must also be set to the same value on both legs, i.e.
true on both, or false on both.
Allowable values for NotionalInitialExchange, NotionalFinalExchange and
NotionalAmortizingExchange: true, false. Defaults to false if omitted, or if the
entire Exchanges block is omitted.

Listing 455: Notional list with exchange

<Notionals>
<Notional>65000000</Notional>
<Exchanges>
<NotionalInitialExchange>true</NotionalInitialExchange>
<NotionalFinalExchange>true</NotionalFinalExchange>
<NotionalAmortizingExchange>true</NotionalAmortizingExchange>
</Exchanges>
</Notionals>

FX Resets, used for Rebalancing Cross-currency swaps, can be specified using an

FXReset child element with the following subelements: See Listing 456 for an
example.

• ForeignCurrency: The foreign currency the notional of the leg resets to.
Allowable values: See Table 32 Currency.
• ForeignAmount: The notional amount in the foreign currency that the notional
of the leg resets to.
Allowable values: Any positive real number.

643
 • FXIndex: A reference to an FX Index source for the FX reset fixing.
Allowable values: A string on the form FX-SOURCE-CCY1-CCY2.

Listing 456: Notional list with fx reset

<Currency>USD</Currency>
<Notionals>
<Notional>65000000</Notional> <!-- in USD -->
<FXReset>
<ForeignCurrency> EUR </ForeignCurrency>
<ForeignAmount> 60000000 </ForeignAmount>
<FXIndex> FX-ECB-USD-EUR </FXIndex>
</FXReset>
</Notionals>

• StrictNotionalDates [Optional]: If given and set to true, notional changes

specified by startDate will be interpreted as taking place on the exact given date,
even if that date falls into a calculation (accrual) period. Otherwise the notional
change is applied for the next calculation period. Supported only for fixed and
floating legs with IBOR / RFR term rate coupons.
• ScheduleData: This is a trade component sub-node outlined in section 8.3.4
Schedule Data and Dates.
• PaymentSchedule [Optional]: This node allows for the specification of an explicit
payment schedule, see 8.3.4. Supported in commodity trades, fixed legs and
floating legs with underlying OIS and IBOR indices.
• PaymentDates [Deprecated]: This node allows for the specification of a list of
explicit payment dates. The usage is deprecated, use PaymentSchedule instead.
• FixedLegData: This trade component sub-node is required if LegType is set to
Fixed It is outlined in section 8.3.5.
• FloatingLegData: This trade component sub-node is required if LegType is set to
Floating It is outlined in section 8.3.6 Floating Leg Data and Spreads.
• CashflowLegData: This trade component sub-node is required if LegType is set
to Cashflow. It is outlined in section 8.3.9.
• CMSLegData: This trade component sub-node is required if LegType is set to
CMS (Constant Maturity Swap). It is outlined in section 8.3.10.
• CMBLegData: This trade component sub-node is required if LegType is set to
CMB (Constant Maturity Bond). It is outlined in section 8.3.11.
• DigitalCMSLegData: This trade component sub-node is required if LegType is
set to DigitalCMS. It is outlined in section 8.3.12.
• DurationAdjustedCMSLegData: This trade component sub-node is required if
LegType is set to DurationAdjustedCMS. It is outlined in section 8.3.13.
• CMSSpreadLegData: This trade component sub-node is required if LegType is
set to CMSSpread. It is outlined in section 8.3.14.

644
 • DigitalCMSSpreadLegData: This trade component sub-node is required if
LegType is set to DigitalCMSSpread. It is outlined in section 8.3.15.
• EquityLegData: This trade component sub-node is required if LegType is set to
Equity. It is outlined in section 8.3.16.
• CPILegData: This trade component sub-node is required if LegType is set to
CPI. It is outlined in section 8.3.17.
• YYLegData: This trade component sub-node is required if LegType is set to YY.
It is outlined in section 8.3.18.
• ZeroCouponFixedLegData: This trade component sub-node is required if
LegType is set to ZeroCouponFixed. It is outlined in section 8.3.19.
• FormulaBasedLegData: This trade component sub-node is required if LegType is
set to FormulaBased. It is outlined in section 8.3.35.
• CommodityFloatingLegData: This trade component sub-node is required if
LegType is set to CommodityFloating It is outlined in section 8.3.24.
• CommodityFixedLegData: This trade component sub-node is required if
LegType is set to CommodityFixed It is outlined in section 8.3.21.
• EquityMarginLegData: This trade component sub-node is required if LegType is
set to EquityMargin It is outlined in section 8.3.26.

8.3.4 Schedule Data (Rules, Dates and Derived)

The ScheduleData trade component node is used within the LegData trade
component. The Schedule can be rules based (at least one Rules sub-node exists),
dates based (at least one Dates sub-node exists, where the schedule is determined
directly by Date child elements), or derived from another schedule in the same leg (at
least one Derived sub-node exists). In rules based schedules, the schedule dates are
generated from a set of rules based on the entries of the sub-node Rules, having the
elements StartDate, EndDate, Tenor, Calendar, Convention, TermConvention, and
Rule. Example structures of ScheduleData nodes based on rules, dates and derived
from a base schedule are shown in Listing 457, Listing 458, and Listing 459 respectively.

Listing 457: Schedule data, rules based

<ScheduleData>
<Rules>
<StartDate>2013-02-01</StartDate>
<EndDate>2030-02-01</EndDate>
<Tenor>1Y</Tenor>
<Calendar>UK</Calendar>
<Convention>MF</Convention>
<TermConvention>MF</TermConvention>
<Rule>Forward</Rule>
</Rules>
</ScheduleData>

645
Listing 458: Schedule data, date based

<ScheduleData>
<Dates>
<Calendar>NYB</Calendar>
<Convention>Following</Convention>
<Tenor>3M</Tenor>
<EndOfMonth>false</EndOfMonth>
<Dates>
<Date>2012-01-06</Date>
<Date>2012-04-10</Date>
<Date>2012-07-06</Date>
<Date>2012-10-08</Date>
<Date>2013-01-07</Date>
<Date>2013-04-08</Date>
</Dates>
</Dates>
</ScheduleData>

Listing 459: Schedule data, derived

<ScheduleData>
<Derived>
<BaseSchedule>ScheduleData</BaseSchedule>
<Shift>3M</Shift>
<Calendar>GBP</Calendar>
<Convention>Following</Convention>
</Derived>
</ScheduleData>

The ScheduleData section can contain any number and combination of <Dates>,
<Rules> and <Derived> sections. The resulting schedule will then be an ordered
concatenation of individual schedules.

The meanings and allowable values of the elements in a <Rules> based section of the
ScheduleData node follow below.
• Rules: a sub-node that determines whether the schedule is set by specifying
rules that generate the schedule. If existing, the following entries are required:
StartDate, EndDate, Tenor, Calendar, Convention, and Rule.
EndDateConvention is optional. If not existing, a Dates or Derived sub-node is
required.
• StartDate: The schedule start date.
Allowable values: See Date in Table 30.
• EndDate: The schedule end date. This can be omitted to indicate a perpetual
schedule. Notice that perpetual schedule are only supported by specific trade
types (e.g. Bond).
Allowable values: See Date in Table 30.

646
• AdjustEndDateToPreviousMonthEnd [Optional]: Only relevant for commodity
legs. Allows for the EndDate to be on a date other than the end of the month. If
set to true the given EndDate is restated to the end date of the previous month.
Allowable values: true or false. Defaults to false if left blank or omitted.
• Tenor: The tenor used to generate schedule dates.
Allowable values: A string where the last character must be D or W or M or Y.
The characters before that must be a positive integer.
D = Day, W = Week, M = Month, Y = Year
Note that 0D and 1T are equivalent valid values, and both cause there to be no
intermediate dates between StartDate and EndDate.
• Calendar: The calendar used to generate schedule dates. Also used to determine
payment dates (except for compounding OIS index legs, which use the index
calendar to determine payment dates).
Allowable values: See Table 34 Calendar.
• Convention: Determines the adjustment of the schedule dates with regards to
the selected calendar, i.e. the roll convention.
Allowable values: See Table 31 Roll Convention.
• TermConvention [Optional]: Determines the adjustment of the final schedule
date with regards to the selected calendar. If left blank or omitted, defaults to
the value of Convention.
Allowable values: See Table 31 Roll Convention.
• Rule [Optional]: Rule for the generation of the schedule using given start and
end dates, tenor, calendar and roll conventions.
Allowable values and descriptions: See Table 33 Rule. Defaults to Forward if
omitted. Cannot be left blank.
• EndOfMonth [Optional]: Specifies whether the date generation rule is different for
end of month, so that the last date of each month is generated, regardless of
number of days in the month.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46. Defaults to false if left blank or omitted.
Must be set to false or omitted if the date generation Rule is set to CDS or
CDS2015.
• FirstDate [Optional]: Date for initial stub period. For date generation rules
CDS and CDS2015, if given, this overwrites the first date of the schedule that is
otherwise built from IMM dates.
Allowable values: See Date in Table 30.
• LastDate [Optional]: Date for final stub period. For date generation rules CDS
and CDS2015, if given, this overwrites the last date of the schedule that is
otherwise built from IMM dates.

647
 Allowable values: See Date in Table 30.
• RemoveFirstDate [Optional]: If true the first date will be removed from the
schedule. Useful to define a payment schedule using the rules for a calculation
schedule.
Allowable values: true, false
• RemoveLastDate [Optional]: If true the last date will be removed from the
schedule. Useful to define a fixing or reset schedule using the rules for a
calculation schedule.
Allowable values: true, false

The meanings and allowable values of the elements in a <Dates> based section of the
ScheduleData node follow below.
• Dates: a sub-node that determines that the schedule is set by specifying schedule
dates explicitly.
• Calendar [Optional]: Calendar used to determine the accrual schedule dates.
Also used to determine payment dates (except for compounding OIS index legs,
which use the index calendar), and also to compute day count fractions for
irregular periods when day count convention is ActActISMA and the schedule is
dates based.
Allowable values: See Table 34 Calendar. Defaults to NullCalendar if omitted,
i.e. no holidays at all, not even on weekends.
• Convention [Optional]: Roll Convention to determine the accrual schedule dates,
and also used to compute day count fractions for irregular periods when day
count convention is ActActISMA and the schedule is dates based.
Allowable values: See Table 31 Roll Convention. Defaults to Unadjusted if
omitted.
• Tenor [Optional]: Tenor used to compute day count fractions for irregular periods
when day count convention is ActActISMA and the schedule is dates based.
Allowable values: A string where the last character must be D or W or M or Y.
The characters before that must be a positive integer.
D = Day, W = Week, M = Month, Y = Year
Defaults to null if omitted.
• EndOfMonth [Optional]: Specifies whether the end of month convention is applied
when calculating reference periods for irregular periods when the day count
convention is ActActICMA and the schedule is dates based.
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46. Defaults to false if left blank or omitted.
• Dates: This is a sub-sub-node and contains child elements of type Date. In this
case the schedule dates are determined directly by the Date child elements. At
least two Date child elements must be provided. Dates must be provided in

648
 chronological order. Note that if no calendar and roll convention is given, the
specified dates must be given as adjusted dates.
Allowable values: Each Date child element can take the allowable values listed in
Date in Table 30.

The meanings and allowable values of the elements in a <Derived> section of the
ScheduleData node follow below.
• BaseSchedule: The schedule from which the derived schedule will be deduced.
Allowable values: Must be the node name of another schedule in a given leg data
node.
• Shift [Optional]: The tenor/period offset to be applied to each date in the base
schedule in order to obtain the derived schedule.
Allowable values: A string where the last character must be D or W or M or Y.
The characters before that must be a positive integer.
D = Day, W = Week, M = Month, Y = Year. If left blank or omitted, defaults
to 0D.
• Calendar [Optional]: The calendar adjustment to be applied to each date in the
base schedule in order to obtain the derived schedule.
Allowable values: See Table 34 Calendar. Defaults to NullCalendar if left blank
or omitted, i.e. no holidays at all, not even on weekends.
• Convention [Optional]: The roll convention to be applied to each date in the
base schedule in order to obtain the derived schedule.
Allowable values: See Table 31 Roll Convention. Defaults to Unadjusted if left
blank or omitted.
• RemoveFirstDate [Optional]: If true the first date will be removed from the
schedule. Useful to define a payment schedule based on a calculation schedule.
Allowable values: true, false
• RemoveLastDate [Optional]: If true the last date will be removed from the
schedule. Useful to define a fixing or reset schedule based on a calculation
schedule.
Allowable values: true, false

8.3.5 Fixed Leg Data and Rates

The FixedLegData trade component node is used within the LegData trade component
when the LegType element is set to Fixed. The FixedLegData node only includes the
Rates sub-node which contains the rates of the fixed leg as child elements of type Rate.
An example of a FixedLegData node for a fixed leg with constant notional is shown in
Listing 460.

649
Listing 460: Fixed leg data

<FixedLegData>
<Rates>
<Rate>0.05</Rate>
</Rates>
</FixedLegData>

The meanings and allowable values of the elements in the FixedLegData node follow
below.
• Rates: This node contains child elements of type Rate. If the rate is constant
over the life of the fixed leg, only one rate value should be entered. If two or
more coupons have different rates, multiple rate values are required, each
represented by a Rate child element. The first rate value corresponds to the first
coupon, the second rate value corresponds to the second coupon, etc. If the
number of coupons exceeds the number of rate values, the rate will be kept flat
at the value of last entered rate for the remaining coupons. The number of
entered rate values cannot exceed the number of coupons.
Allowable values: Each child element can take any real number. The rate is
expressed in decimal form, e.g. 0.05 is a rate of 5%.
As in the case of notionals, the rate schedule can be specified with dates as
shown in Listing 461.

Listing 461: Fixed leg data with ’dated’ rates

<FixedLegData>
<Rates>
<Rate>0.05</Rate>
<Rate startDate='2016-02-04'>0.05</Rate>
<Rate startDate='2019-02-05'>0.05</Rate>
</Rates>
</FixedLegData>

8.3.6 Floating Leg Data, Spreads, Gearings, Caps and Floors

The FloatingLegData trade component node is used within the LegData trade
component when the LegType element is set to Floating. It is also used directly within
the CapFloor trade data container. The FloatingLegData node includes elements
specific to a floating leg.
An example of a FloatingLegData node is shown in Listing 462.

650
Listing 462: Floating leg data

<FloatingLegData>
<Index>USD-LIBOR-3M</Index>
<IsInArrears>false</IsInArrears>
<IsAveraged>false</IsAveraged>
<HasSubPeriods>false</HasSubPeriods>
<IncludeSpread>false</IncludeSpread>
<FixingDays>2</FixingDays>
<Spreads>
<Spread>0.005</Spread>
</Spreads>
<Gearings>
<Gearing>2.0</Gearing>
</Gearings>
<Caps>
<Cap>0.05</Cap>
</Caps>
<Floors>
<Floor>0.01</Floor>
</Floors>
<NakedOption>false</NakedOption>
<LocalCapFloor>false</LocalCapFloor>
<HistoricalFixings>
<Fixing fixingDate="2016-02-01">0.2</Fixing>
</HistoricalFixings>
</FloatingLegData>

The meanings and allowable values of the elements in the FloatingLegData node
follow below.
• Index: The combination of currency, index and term that identifies the relevant
fixings and yield curve of the floating leg.
Allowable values: An alphanumeric string of the form CCY-INDEX-TENOR.
CCY, INDEX and TENOR must be separated by dashes (-). CCY and INDEX
must be among the supported currency and index combinations. TENOR must
be an integer followed by D, W, M or Y. See Table 36. TENOR is not required
for Overnight indices, but can be set to 1D.
• IsAveraged [Optional]: For cases where there are multiple index fixings over a
period true indicates that the average of the fixings is used to calculate the
coupon. false indicates that the coupon is calculated by compounding the
fixings. IsAveraged only applies to Overnight indices and Sub Periods Coupons.
Allowable values: true, false. Defaults to false if left blank or omitted.
• HasSubPeriods [Optional]: For cases where several Ibor fixings result in a single
payment for a period, e.g. if the Ibor tenor is 3M and the schedule tenor is 6M,
two fixings are used to compute the amount of the semiannual coupon payments.
true indicates that an average (IsAveraged = true) or a compounded
(IsAveraged=false) value of the fixings is used to determine the payment rate.
false indicates that the initial index period fixing determines the payment rate
for the full tenor, i.e. no further fixings, no averaging and no compounding.

651
 IsAveraged is ignored for Ibor legs when HasSubPeriods is set to false.
HasSubPeriods does not apply to Overnight indices.
Allowable values: true, false. Defaults to false if left blank or omitted.
• IncludeSpread [Optional]: Only applies to Sub Periods and (compounded) OIS
Coupons. If true the spread is included in the compounding, otherwise it is
excluded.
Allowable values: true, false. Defaults to false if left blank or omitted.
A Zero Coupon Floating leg with compounding that includes spread can be set
up using a rules-based schedule as shown in Listing 463. Note that the Tenor in
the rules-based schedule is not used when Rule is set to Zero.

Listing 463: Zero Coupon Floating Leg - Rules-based

<LegData>
<LegType>Floating</LegType>
<Payer>false</Payer>
<Currency>USD</Currency>
<Notionals>
<Notional>200000.0000</Notional>
</Notionals>
<DayCounter>A360</DayCounter>
<PaymentConvention>MF</PaymentConvention>
<ScheduleData>
<Rules>
<StartDate>2020-01-14</StartDate>
<EndDate>2020-07-14</EndDate>
<Tenor>3M</Tenor>
<Calendar>USD</Calendar>
<Convention>MF</Convention>
<TermConvention>MF</TermConvention>
<Rule>Zero</Rule>
</Rules>
</ScheduleData>
<FloatingLegData>
<Index>USD-LIBOR-3M</Index>
<IsAveraged>false</IsAveraged>
<HasSubPeriods>true</HasSubPeriods>
<IncludeSpread>true</IncludeSpread>
<Spreads>
<Spread>0.006500</Spread>
</Spreads>
<IsInArrears>false</IsInArrears>
<FixingDays>2</FixingDays>
</FloatingLegData>
</LegData>

A Zero Coupon Floating leg with compounding that includes spread can also be
set up using a dates-based schedule with two dates (start and end) as shown in
Listing 464.

652
Listing 464: Zero Coupon Floating Leg - Dates-based

<LegData>
<LegType>Floating</LegType>
<Payer>false</Payer>
<Currency>USD</Currency>
<Notionals>
<Notional>200000.0000</Notional>
</Notionals>
<DayCounter>A360</DayCounter>
<PaymentConvention>MF</PaymentConvention>
<ScheduleData>
<Dates>
<Calendar>USD</Calendar>
<Convention>MF</Convention>
<Dates>
<Date>2020-01-14</Date>
<Date>2020-07-14</Date>
</Dates>
</Dates>
</ScheduleData>
<FloatingLegData>
<Index>USD-LIBOR-3M</Index>
<IsAveraged>false</IsAveraged>
<HasSubPeriods>true</HasSubPeriods>
<IncludeSpread>true</IncludeSpread>
<Spreads>
<Spread>0.006500</Spread>
</Spreads>
<IsInArrears>false</IsInArrears>
<FixingDays>2</FixingDays>
</FloatingLegData>
</LegData>

• IsInArrears [Optional]: true indicates that fixing is in arrears, false indicates that
fixing is in advance.
– For Ibor coupons, “in arrears” means that the fixing gap is calculated in
relation to the current period end date, while “in advance” means that the
fixing gap is calculated in relation to the period start date.
– For OIS coupons, “in arrears” means that the compounding (or averaging)
of ON rates is done over the current period, while “in advance” means that
the compounding (averaging) is done over the previous period. For the first
period, a virtual previous period will be constructed based on the schedule
construction rules. In the context of RFRs there are two common “in
advance” variants:
∗ “Last Recent” which means the length of the period used for
compounding / averaging is independent of the original period. This
former period is specified in the LastRecentPeriod field.
∗ “Last Reset” which means the original period will be used for
compounding / averaging. This variant is indicated by omitting the
LastRecentPeriod field.

653
 Notice that the use of the LastRecentPeriod field is not restricted to “in
advance” OIS coupons, i.e. it can also be used in combination with “in
arrears”.
Allowable values: true, false. Defaults to false for Ibor and to true for OIS
coupons, if left blank or omitted.
• LastRecentPeriod [Optional]: Only applies to OIS coupons. If given, the
compounding / averaging of ON rates will not be done over the usual reference
period derived from the accrual period and the Lookback, FixingDays and
IsInArrears parameters, but instead over a period determined by the end date of
this usual period and the LastRecentPeriod parameter as [ EndDate -
LastRecentPeriod, EndDate ]. The calendar used to compute EndDate -
LastRecentPeriod is the schedule calendar unless a specific
LastRecentPeriodCalendar is specified. To represent SOFR 30D, 90D, 180D
average indices, the LastRecentPeriodCalendar should be set to NullCalendar,
since these averages refer to rolling averages over 30, 90, 180 calendar days.
Allowable values: any valid period, e.g. 30D, 90D, 180D, 1M, 2M, 6M
• LastRecentPeriodCalendar [Optional]: The calendar used to compute the
LastRecentPeriod, see this field for more details. If not given, defaults to the
schedule calendar.
Allowable values: See Table 34 Calendar.
• FixingDays [Optional]: The fixing gap. For Ibor coupons this is the number of
business days before the accrual period’s reference date to observe the index
fixing. Here, the accrual period reference date is the accrual start date for an in
advanced fixed coupon and the accrual end date for in arrears fixed coupon.
For overnight coupons this is the number of business days by which the value
dates are shifted into the past to get the fixing observation dates. In the context
of RFRs the FixingDays parameter is sometimes also called “obervation lag”.
The calendar used for the fixing gap, is the calendar associated with the floating
index, as defined in the conventions for the index.
Allowable values: A non-negative whole number. Defaults to the index’s fixing
days if blank or omitted. See defaults per index in Table 37.
• Lookback [Optional]: Only applicable to OIS legs. A period by which the value
dates schedule of (averaged, compounded) OIS legs is shifted into the past. On
top of this the gap defined by the FixingDays is applied to get the final fixing
date for an original date in the OIS value dates schedule. In the context of RFRs
the Lookback parameter is sometimes also called “shift”. With this terminology,
first the shift and then the observation lag is applied to get the fixing date for an
original value date of an overnight coupon.
Allowable values: any valid period, e.g. 2D, 3M, 1Y
• RateCutoff [Optional]: Only applicable to OIS legs. The number of fixing dates
at the end of the fixing period for which the fixing value is held constant and set
to the previous value. Defaults to 0.
Allowable values: any non-negative whole number

654
 • Spreads [Optional]: This node contains child elements of type Spread. If the
spread is constant over the life of the floating leg, only one spread value should
be entered. If two or more coupons have different spreads, multiple spread values
are required, each represented by a Spread child element. The first spread value
corresponds to the first coupon, the second spread value corresponds to the
second coupon, etc. If the number of coupons exceeds the number of spread
values, the spread will be kept flat at the value of last entered spread for the
remaining coupons. The number of entered spread values cannot exceed the
number of coupons.
Allowable values: Each child element can take any real number. The spread is
expressed in decimal form, e.g. 0.005 is a spread of 0.5% or 50 bp.
For the <Spreads> section, the same applies as for notionals and rates - a list of
changing spreads can be specified without or with individual start dates as shown
in Listing 465.

Listing 465: ’Dated’ spreads

<Spreads>
<Spread>0.005</Spread>
<Spread startDate='2017-03-05'>0.007</Spread>
<Spread startDate='2019-03-05'>0.009</Spread>
</Spreads>

If the entire <Spreads> section is omitted, it defaults to a spread of 0%.

• Gearings [Optional]: This node contains child elements of type Gearing
indicating that the coupon rate is multiplied by the given factors. The mode of
specification is analogous to spreads, see above.
If the entire <Gearings> section is omitted, it defaults to a gearing of 1.
• Caps [Optional]: This node contains child elements of type Cap indicating that
the coupon rate is capped at the given rate (after applying gearing and spread, if
any). The mode of specification is analogous to spreads, see above. Caps /
Floors are supported for Ibor, SIFMA, compounded / averaged OIS coupons, but
not for coupons with subperiods.
For OIS coupons notice how the gearing g and spread s enter the calculation of
the coupon amount A dependent on the IncludeSpread and LocalCapFloor flags
and the cap rate C, floor rate F , daily rates fi , daily accrual fractions τi and the
coupon accrual fraction τ . Notice that the gearing must be 1 if include spread is
set to true for capped / floored coupons. The cases for compounded coupons are:
– IncludeSpread = false, LocalCapFloor = false:
  Q  
(1 + τi fi ) − 1
A = min max g · + s, F , C
τ

– IncludeSpread = true, LocalCapFloor = false:

655
  Q  
(1 + τi (fi + s)) − 1
A = min max · ,F ,C
τ

– IncludeSpread = false, LocalCapFloor = true:

Q
(1 + τi min(max(fi , F ), C)) − 1
A=g· +s
τ
– IncludeSpread = true, LocalCapFloor = true:
Q
(1 + τi min(max(fi + s, F ), C)) − 1
A=·
τ
The cases for Averaged coupons are:
– IncludeSpread = false, LocalCapFloor = false:
  P  
(τi fi )
A = min max g · + s, F , C
τ

– IncludeSpread = true, LocalCapFloor = false:

 P  
(τi fi )
A = min max + s, F , C
τ

– IncludeSpread = false, LocalCapFloor = true:

P
(τi min(max(fi , F ), C))
A=g· +s
τ
– IncludeSpread = true, LocalCapFloor = true:
P
(τi min(max(fi + s, F ), C))
A=·
τ
• Floors [Optional]: This node contains child elements of type Floor indicating
that the coupon rate is floored at the given rate (after applying gearing and
spread, if any). The mode of specification is analogous to spreads, see above.
• NakedOption [Optional]: Optional node, if true the leg represents only the
embedded floor, cap or collar. By convention the embedded floor (or cap) are
considered long if the leg is a receiver leg, otherwise short. For a collar the floor
is long and the cap is short if the leg is a receiver leg. Notice that this is opposite
to the definition of a collar in 8.2.3.
Allowable values: true, false . Defaults to false if left blank or omitted.
• LocalCapFloor [Optional]: Optional node, if true a cap (floor) will be applied to
the daily rates of a compounded / averaged overnight coupon. If false the
effective period rate will be capped (floored). The flag is ignored for coupons
other than overnight coupons.
Allowable values: true, false . Defaults to false if left blank or omitted.

656
 • FixingSchedule [Optional]: This node allows for the specification of an explicit
fixing schedule, see 8.3.4. Supported for underlying IBOR / term rate index. A
given fixing will become effective as specified by FixingDays relative to the fixing
schedule or by an explicit ResetSchedule.
• ResetSchedule [Optional]: This node allows for the specification of an explicit
reset schedule, see 8.3.4, i.e. the dates on which fixings become effective.
Supported for underlying IBOR / term rate index. Can be given together with
FixingSchedule or FixingDays. In the latter case, the fixing dates are derived
from the reset schedule.
• HistoricalFixings [Optional]: This node allows for the specification of an
custom trade specific fixings. Supported for underlying OIS / IBOR / term rate
index. If a historical fixing for date in the provided list is needed for pricing, the
custom fixings will be used instead of an exisiting global index fixings.

8.3.7 Leg Data with Amortisation Structures

Amortisation structures can (optionally) be added to a leg as indicated in the following
listing 466, within a block of information enclosed by <Amortizations> and
</Amortizations> tags. Note that <Amortizations> structures are not supported for
trade type CapFloor.
Listing 466: Amortisation data

<LegData>
<LegType> ... </LegType>
<Payer> ... </Payer>
<Currency> ... </Currency>
<Notionals>
<Notional>10000000</Notional>
</Notionals>
<Amortizations>
<AmortizationData>
<Type>FixedAmount</Type>
<Value>1000000</Value>
<StartDate>20170203</StartDate>
<Frequency>1Y</Frequency>
<Underflow>false</Underflow>
</AmortizationData>
<AmortizationData>
...
</AmortizationData>
</Amortizations>
...
</LegData>

The user can specify a sequence of AmortizationData items in order to switch from
one kind of amortisation to another etc. Within each AmortisationData block the
meaning of elements is
• Type: Amortisation type with allowable values FixedAmount,
RelativeToInitialNotional, RelativeToPreviousNotional, Annuity,
LinearToMaturity.

657
 • Value [optional]: Interpreted depending on Type, see below. Required for all
types except LinearToMaturity.
• StartDate [optional]: Amortisation starts on first schedule date on or beyond
StartDate. If not given, amortisation starts in first schedule period. If more than
one AmortizationData block is specified, the StartDate is mandatory for all
blocks except the first.
• EndDate [optional]: Amortization is applied for schedule periods with start date
before EndDate. If more than one AmortizationData block is specified, the
EndDate is mandatory for all blocks except the last.
• Frequency, entered as a period [optional]: Frequency of amortisations. If not
given, an amortization is applied in each schedule period, otherwise in each nth
period, where n is determined from Frequency. Amortizations are always applied
to whole periods though, i.e. not within a period. The frequency is ignored for
type Annuity, in which case an amortisation is applied in each period.
• Underflow [optional]: Allow amortisation below zero notional if true, otherwise
amortisation stops at zero notional. Defaults to false;
The amortisation data block’s Value element is interpreted depending on the chosen
Type:
• FixedAmount: The value is interpreted as a notional amount to be subtracted
from the current notional on each amortisation date.
• RelativeToInitialNotional: The value is interpreted as a fraction of the initial
notional to be subtraced from the current notional on each amortisation date.
• RelativeToPreviousNotional: The value is interpreted as a fraction of the
previous notional to be subtraced from the previous notional to get the current
notional on each amortisation date.
• Annuity: The value is interpreted as annuity amount (redemption plus coupon).
• LinearToMaturity: The value is not relevant, and does not need to be provided.
Annuity type amortisation is supported for fixed rate legs as well as floating (ibor) legs.
Note:
• Floating annuities require at least one previous vanilla coupon in order to work
out the first amortisation amount.
• Floating legs with annuity amortisation currently do not allow switching the
amortisation type, i.e. only a single block of AmortizationData.

8.3.8 Indexings
This trade component can be used as an optional node within the LegData component
to scale the notional of the coupons of a leg by one or several index prices. This
feature is typically used within equity swaps with notional reset to align the notional
of the funding leg with the one from the equity leg for all return periods. See 8.2.24 for
the specific usage in equity swaps. Notice that typically it is sufficient to set the
FromAssetLeg flag to true in the Indexings node definition, i.e.

658
<LegData>
<LegType>Floating</LegType>
<!-- no notionals node required -->
<ScheduleData> ... </ScheduleData>
<Indexings>
<FromAssetLeg>true</FromAssetLeg>
</Indexings>
<FloatingLegData> ... </FloatingLegData>
</LegData>

which will cause the trade builder to pull all the indexing details from the asset leg
(the equity leg in an equity swap) and populate the indexing data on the funding leg
accordingly. Notice that no definition of a Notionals node is required in this case, this
will also generated automatically.
In what follows we will describe the full syntax of the Indexings node below for
reference. The Indexing component can be used in combination with the following leg
types:
• Fixed
• Floating
• CMS
• DigitalCMS
• CMSSpread
• DigitalCMSSpread
If specified the notional of the single coupons in the leg is scaled by one or several
index prices and a quantity. The indices can be equity or FX indices. Notice that if
notional exchanges are enabled on a leg with the FromAssetLeg flag set to true, the
notional exchanges are not influenced by the indexing definitions. In general we
assume that notional exchanges are not enabled in combination with FromAssetLeg
true, but it is not forbidden technically. Listing 467 shows an example of a Floating leg
indexed by both an equity price and a FX rate.
Another use case for Indexings is for non-deliverable IR and Cross Currency Swaps. A
non-deliverable IR Swap has Currency set to the deliverable currency on both legs,
Notional in the non-deliverable currency on both legs, and Indexings with an FX Index
between the deliverable and non-deliverable currency on both legs. See the Swap
section for an example non-deliverable IR swap where USD is the payment currency
and CLP is the non-deliverable currency.
A non-deliverable Cross Currency Swap has Settlement set to Cash, and one leg is a
regular leg in the deliverable currency without Indexings. The other leg has Currency
set to the deliverable currency, Notional in the non-deliverable currency and Indexings
with an FX Index between the deliverable and non-deliverable currency. See the Swap
section for an example USD-CLP non-deliverable cross currency swap where CLP is
the non-deliverable currency.

659
Listing 467: Indexings node

<LegData>
<LegType>Floating</LegType>
<Notionals> ... </Notionals>
<ScheduleData> ... </ScheduleData>
<Indexings>
<FromAssetLeg>false</FromAssetLeg>
<Indexing>
<Quantity>1000</Quantity>
<Index>EQ-RIC:.STOXX50E</Index>
<InitialFixing>2937.36</InitialFixing>
<ValuationSchedule>
<Dates>...</Dates>
<Rules>...</Rules>
</ValuationSchedule>
<FixingDays>0</FixingDays>
<FixingCalendar/>
<FixingConvention>U</FixingConvention>
<IsInArrears>false</IsInArrears>
</Indexing>
<Indexing>
<Index>FX-ECB-EUR-USD</Index>
<InitialFixing>1.1469</InitialFixing>
<ValuationSchedule> ... </ValuationSchedule>
<FixingDays>0</FixingDays>
<FixingCalendar/>
<FixingConvention>U</FixingConvention>
<IsInArrears>false</IsInArrears>
</Indexing>
</Indexings>
<FloatingLegData> ... </FloatingLegData>
</LegData>

The Indexings node contains the following elements:

• FromAssetLeg [Optional]: If true, and the trade type supports this, the notionals
on the funding leg (i.e. the leg with the FromAssetLeg field) will be derived from
the respective asset leg. Internally, the trade builder will add Indexing blocks
automatically reflecting the necessary indexings (equity price and FX in the case
of an equity swap) from the notional reset feature of the asset leg. Also, the
Notionals node of the funding leg will internally be set to a single notional 1.
The actual Notionals node in the XML on the funding leg is not required and
can be omitted.
FromAssetLeg is supported for the following trade types:
– EquitySwap: Setting FromAssetLeg to true, aligns the notionals for all
return periods on the non-equity funding leg, to the equity leg by deriving
equity price, quantity and FX from the equity leg.
Note that FromAssetLeg is only supported if NotionalReset is true on the
equity leg - FromAssetLeg is ignored otherwise. Also FromAssetLeg is only
supported when Quantity is given on the equity leg, not InitialPrice and
Notional.

660
 – BondTRS: Setting FromAssetLeg to true, aligns the notionals for all return
periods on the funding leg (in the FundingData block), to the total return
leg (in the TotalReturnData block) by deriving bond price, bond notional
and FX from the total return leg, bond data and the reference bond.
Allowable values: true, false. Defaults to false if left blank or omitted.
• Indexing [Optional, an arbitrary number can be given]: Each Indexing node
describes one indexing as follows:
– Quantity [Optional]: The quantity that applies. For equity that should be
the number of shares, for FX it should be 1, i.e. for FX this field can be
omitted. The notional of each coupon is in general determined as
Original Coupon Notional x Quantity x Equity Price x FX Rate
depending on which indexing types are given. Typically, the original coupon
notional will be set to 1.
Allowable values: Any number. Defaults to 1 if left blank or omitted.
– Index: The relevant index. This is either an equity or FX index. For an FX
index, one of the currencies of the index must match the leg currency. It is
then ensured that the FX conversion is applied using the correct direction,
i.e. if the foreign currency of the index matches the leg currency, the
reciprocals of the index fixings are used as a multiplier.
Allowable values: This is “FX-SOURCE-CCY1-CCY” for FX, see 8.3.29 and
38 for details, or “EQ-NAME” for Equity with “Name” being the general
string representation for equity underlyings
IdentifierType:Name:Currency:Exchange, see 8.3.29.
– Dirty [Optional]: Only used for bond indices. Indicates whether to use dirty
(true) or clean (false) prices.
Allowable values: true, false. Defaults to true if left blank or omitted.
– Relative [Optional]: Only used for bond indices. Indicates whether to use
relative (true) or absolute prices (false). The absolute price is the dirty or
clean npv as of the settlement date of the bond in absolute “dollar” terms
using the bond details (in particular the notional) from the reference data.
The relative price is the absolute price divided by the current notional as of
the settlement date.
Allowable values: true, false. Defaults to true if left blank or omitted.
– ConditionalOnSurvival [Optional]: Only used for bond indices. Indicates
whether to forecast bond prices conditional on survival (true) or including
the default probability from today until the fixing date (false).
Allowable values: true, false. Defaults to true if left blank or omitted.
– InitialFixing [Optional]: If given the index fixing value to apply on the
fixing date of the first coupon. If not given the value is read from the
relevant fixing history.
Allowable values: any number

661
 – InitialNotionalFixing [Optional]: If given the index fixing value to apply on
the fixing date of the first notional exchange flow. This is used in
non-deliverable XCCY swaps. If not given the value is read from the
relevant fixing history.
Allowable values: any number
– ValuationSchedule [Optional]: If given the schedule from which the fixing
dates are deduced. If not given, it defaults to the original leg’s schedule.
If the valuation schedule has the same size as the original leg’s schedule, it is
assumed that the periods correspond one to one, i.e. the ith fixing date is
derived from the ith (inArrears = false) or i + 1th (inArrears = true) date
in the valuation schedule using the FixingDays, FixingCalendar and
FixingConvention.
If the valuation schedule has a different size than the original leg’s schedule,
the relevant valuation date for the ith original leg’s coupon is determined as
the latest valuation date that is less or equal to accrual start date
(inArrears = false) resp. accrual end date (inArrears = true) of that
coupon. The fixing date is derived from the relevant valuation date as
above, i.e. using the FixingDays, FixingCalendar and FixingConvention.
Allowable values: a valid schedule definition, see 8.3.4
– FixingDays [Optional]: If given defines the number of fixing days to apply
when deriving the fixing dates from the valuation schedule (see above).
Allowable values: Any non-negative whole number. Defaults to 0 if left
blank or omitted.
– FixingCalendar [Optional, defaults to NullCalendar (no holidays): If given
defines the fixing calendar to use when deriving the fixing dates from the
valuation schedule (see above).
Allowable values: Allowable values: See Table 34 Calendar. Defaults to the
NullCalendar (no holidays) if left blank or omitted.
– FixingConvention [Optional]: If given defines the business day convention to
use when deriving the fixing dates from the valuation schedule (see above).
Defaults to Preceding if left blank or omitted.
Allowable values: Any valid roll convention, e.g. (F, MF, P, MP, U ). See
Table 31.
– IsInArrears [Optional]: If true, the fixing dates are derived from the period
end dates, otherwise from the period start dates as described for
ValuationSchedule above.
Allowable values: true, false. Defaults to false if left blank or omitted.

8.3.9 Cashflow Leg Data

A Cashflow leg is used to represent one or more custom cashflows, with specified dates
and amounts. Listing 468 shows an example for a leg of type Cashflow.

662
Listing 468: Cashflow leg data

<LegData>
<Payer>false</Payer>
<LegType>Cashflow</LegType>
<Currency>EUR</Currency>
<PaymentConvention>ModifiedFollowing</PaymentConvention>
<CashflowData>
<Cashflow>
<Amount date="2024-12-15">105000</Amount>
</Cashflow>
</CashflowData>
</LegData>

The CashflowData block contains the following elements:

• Cashflow: This node contains child elements of type Amount, each representing a
cashflow. Each child element should include the date of the cashflow using the
form:

<Amount date="YYYY-MM-DD">[amount]</Amount>

Allowable values: Each child element can take any real number.

8.3.10 CMS Leg Data

Listing 469 shows an example for a leg of type CMS.

663
Listing 469: CMS leg data

<LegData>
<LegType>CMS</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>10000000</Notional>
</Notionals>
<DayCounter>ACT/ACT</DayCounter>
<PaymentConvention>Following</PaymentConvention>
<ScheduleData>
...
</ScheduleData>
<CMSLegData>
<Index>EUR-CMS-10Y</Index>
<Spreads>
<Spread>0.0010</Spread>
</Spreads>
<Gearings>
<Gearing>2.0</Gearing>
</Gearings>
<Caps>
<Cap>0.05</Cap>
</Caps>
<Floors>
<Floor>0.01</Floor>
</Floors>
<NakedOption>false</NakedOption>
</CMSLegData>
</LegData>

The CMSLegData block contains the following elements:

• Index: The underlying CMS index.
Allowable values: See 36, a string on the form CCY-CMS-TENOR, where the
CMS part stays constant and TENOR is an integer followed by Y.
• Spreads [Optional]: The spreads applied to index fixings. As usual, this can be a
single value, a vector of values or a dated vector of values.
Allowable values: Each child spread element can take any real number. The
spread is expressed in decimal form, e.g. 0.005 is a spread of 0.5% or 50 bp.
• IsInArrears [Optional]: true indicates that fixing is in arrears, i.e. the fixing gap
is calculated in relation to the current period end date.
false indicates that fixing is in advance, i.e. the fixing gap is calculated in
relation to the previous period end date.
Allowable values: true, false. Defaults to false if left blank or omitted.
• FixingDays [Optional]: This is the fixing gap, i.e. the number of days before the
period end date an index fixing is taken. Defaults to the index’s fixing gap.
Allowable values: A non-negative whole number. Defaults to the fixing days of
the Ibor index the swap references if blank or omitted. See defaults per index in

664
 Table 37.
• Gearings [Optional]: This node contains child elements of type Gearing
indicating that the coupon rate is multiplied by the given factors. The mode of
specification is analogous to spreads, see above.
If the entire <Gearings> section is omitted, it defaults to a gearing of 1.
• Caps [Optional]: This node contains child elements of type Cap indicating that
the coupon rate is capped at the given rate (after applying gearing and spread, if
any). The mode of specification is analogous to spreads, see above.
• Floors [Optional]: This node contains child elements of type Floor indicating
that the coupon rate is floored at the given rate (after applying gearing and
spread, if any). The mode of specification is analogous to spreads, see above.
• NakedOption [Optional]: If true the leg represents only the embedded floor, cap
or collar. By convention the embedded floor (or cap) are considered long if the
leg is a receiver leg, otherwise short. For a collar the floor is long and the cap is
short if the leg is a receiver leg.
Allowable values: true, false . Defaults to false if left blank or omitted.

8.3.11 Constant Maturity Bond Leg Data

In close analogy to the CMS leg one can create a leg that is linked to a Constant
Maturity Bond yield index. The associated leg type is CMB.
Listing 470 shows an example for a leg of type CMB.

Listing 470: CMB leg data

<LegData>
<LegType>CMB</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>10000000</Notional>
</Notionals>
<DayCounter>ACT/ACT</DayCounter>
<PaymentConvention>Following</PaymentConvention>
<ScheduleData>
...
</ScheduleData>
<CMBLegData>
<Index>CMB-US-TBILL-HD-13W</Index>
<FixingDays>2</FixingDays>
<Spreads>
<Spread>0.0010</Spread>
</Spreads>
<Gearings>
<Gearing>2.0</Gearing>
</Gearings>
</CMBLegData>
</LegData>

665
The CMBLegData block contains the following elements:
• Index: The underlying CMB index.
Allowable values: A string of the form CMB-FAMILY-TENOR, where FAMILY
might consist of several tokens separated by “-” as e.g. in CMB-US-TBILL-HD or
CMB-DE-BUND, and TENOR is a valid period.
• Spreads [Optional]: The spreads applied to index fixings. As usual, this can be a
single value, a vector of values or a dated vector of values.
Allowable values: Each child spread element can take any real number. The
spread is expressed in decimal form, e.g. 0.005 is a spread of 0.5% or 50 bp.
Defaults to zero if left blank or omitted.
• FixingDays: This is the fixing gap, i.e. the number of days before the period end
date an index fixing is taken. Defaults to the index’s fixing gap.
Allowable values: A non-negative whole number. Defaults to the fixing days of
the Ibor index the swap references if blank or omitted. See defaults per index in
Table 37.
• IsInArrears [Optional]: true indicates that fixing is in arrears, i.e. the fixing gap
is calculated in relation to the current period end date.
false indicates that fixing is in advance, i.e. the fixing gap is calculated in
relation to the previous period end date.
Allowable values: true, false. Defaults to false if left blank or omitted.
• Gearings [Optional]: This node contains child elements of type Gearing
indicating that the coupon rate is multiplied by the given factors. The mode of
specification is analogous to spreads, see above.
If the entire <Gearings> section is omitted, it defaults to a gearing of 1.
Note:
• For each CMB index name one needs to maintain bond reference data with ID
equal to the index name. This reference data is used to project the CMB index
fixings as follows: For a future index period (from future date to future date +
index tenor), a forward starting bond is constructed using the schedule frequency
defined in the reference data and with constant maturity (future date + tenor).
The forward bond is priced using the reference yield curve and credit curve
defined in the reference data. And the bond price is then converted into a bond
yield using the bond yield conventions (compounding, frequncy, price type)
maintained for that same ID. If the conventions are not set up, then default
values are used (compounded, annual, clean).
• For periods with start dates in the past, historical index fixings need to be
provided, as for interest rate indices.
• No convexity adjustment is applied here yet, in contrast to CMS index
projections.
• The CMB leg does not support Caps or Floors yet, in contrast to the CMS leg.

666
8.3.12 Digital CMS Leg Data
Listing 471 shows an example for a leg of type DigitalCMS.

Listing 471: Digital CMS leg data

<LegData>
<LegType>DigitalCMS</LegType>
<Payer>false</Payer>
<Currency>GBP</Currency>
<Notionals>
<Notional>10000000</Notional>
</Notionals>
<DayCounter>ACT/ACT</DayCounter>
<PaymentConvention>Following</PaymentConvention>
<ScheduleData>
...
</ScheduleData>
<DigitalCMSLegData>
<CMSLegData>
<Index>EUR-CMS-10Y</Index>
<FixingDays>2</FixingDays>
<Gearings>
<Gearing>3.0</Gearing>
</Gearings>
<Spreads>
<Spread>0.0010</Spread>
</Spreads>
<NakedOption>false</NakedOption>
</CMSLegData>
<CallPosition>Long</CallPosition>
<IsCallATMIncluded>false</IsCallATMIncluded>
<CallStrikes>
<Strike>0.003</Strike>
</CallStrikes>
<CallPayoffs>
<Payoff>0.003</Payoff>
</CallPayoffs>
<PutPosition>Short</PutPosition>
<IsPutATMIncluded>false</IsPutATMIncluded>
<PutStrikes>
<Strike>0.05</Strike>
</PutStrikes>
<PutPayoffs>
<Payoff>0.05</Payoff>
</PutPayoffs>
</DigitalCMSLegData>
</LegData>

The DigitalCMSLegData block contains the following elements:

• CMSLegData: a CMSLegData block describing the underlying Digital CMS leg
(see 8.3.10). Caps and floors in the underlying CMS leg are not supported for
Digital CMS Options. The NakedOption flag in the CMSLegData block is
supported and can be used to separate the digital option payoff from the
underlying CMS coupon.

667
 • CallPosition: Specifies whether the call option position is long or short.
• IsCallATMIncluded: inclusion flag on the call payoff if the call option ends
at-the-money
• CallStrikes: strike rate for the call option
• CallPayoffs: digital call option payoff rate. If included the option is
cash-or-nothing, if excluded the option is asset-or-nothing
• PutPosition: Specifies whether the put option position is long or short.
• IsPutATMIncluded: inclusion flag on the put payoff if the put option ends
at-the-money
• PutStrikes: strike rate for the put option
• PutPayoffs: digital put option payoff rate. If included the option is
cash-or-nothing, if excluded the option is asset-or-nothing

8.3.13 Duration Adjusted CMS Leg Data

Listing 472 shows an example for a leg of type DurationAdjustedCMS.

668
Listing 472: Duration Adjusted CMS leg data

<LegData>
<LegType>DurationAdjustedCMS</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>21000000</Notional>
</Notionals>
<DayCounter>Simple</DayCounter>
<PaymentConvention>Following</PaymentConvention>
<PaymentLag>0</PaymentLag>
<PaymentCalendar>TARGET</PaymentCalendar>
<DurationAdjustedCMSLegData>
<Index>EUR-CMS-20Y</Index>
<Duration>10</Duration>
<Spreads>
<Spread>0</Spread>
</Spreads>
<Gearings>
<Gearing>1</Gearing>
</Gearings>
<IsInArrears>false</IsInArrears>
<FixingDays>2</FixingDays>
<Caps>
<Cap>0.015</Cap>
</Caps>
<NakedOption>true</NakedOption>
</DurationAdjustedCMSLegData>
<ScheduleData>
<Rules>
<StartDate>2019-12-31</StartDate>
<EndDate>2023-12-31</EndDate>
<Tenor>3M</Tenor>
<Calendar>EUR</Calendar>
<Convention>ModifiedFollowing</Convention>
<TermConvention>ModifiedFollowing</TermConvention>
<Rule>Backward</Rule>
</Rules>
</ScheduleData>
</LegData>

The DurationAdjustedCMSLegData is identical to the CMSLegData block (see 8.3.10).

In addition to this it contains a field defining the duration adjustment:
• Duration [Optional]: A non-negative whole number n that defines the duration
adjustment for the coupons. If γ is the underlying CMS index fixing for a coupon
the duration adjustment δ is defined as
n
X 1
δ=
i=1
(1 + γ)i

If n is zero or the duration is not given, δ is defined as 1, i.e. no adjustment is

applied in this case and the coupon will be an ordinary CMS coupon. The
coupon amount A for a duration adjusted coupon with a spread s, a gearing g, a

669
 cap c, a floor f and with nominal N and accrual fraction τ is given by:

A = δ · N · τ · max(min(g · γ + s, c), f )

Allowable values: A non-negative whole number.

8.3.14 CMS Spread Leg Data

Listing 473 shows an example for a leg of type CMSSpread.

Listing 473: CMS Spread leg data

<LegData>
<LegType>CMSSpread</LegType>
<Payer>false</Payer>
<Currency>GBP</Currency>
<Notionals>
<Notional>10000000</Notional>
</Notionals>
<DayCounter>ACT/ACT</DayCounter>
<PaymentConvention>Following</PaymentConvention>
<ScheduleData>
...
</ScheduleData>
<CMSSpreadLegData>
<Index1>EUR-CMS-10Y</Index1>
<Index2>EUR-CMS-2Y</Index2>
<Spreads>
<Spread>0.0010</Spread>
</Spreads>
<Gearings>
<Gearing>8.0</Gearing>
</Gearings>
<Caps>
<Cap>0.05</Cap>
</Caps>
<Floors>
<Floor>0.01</Floor>
</Floors>
<NakedOption>false</NakedOption>
</CMSSpreadLegData>
</LegData>

The elements of the CMSSpreadLegData block are identical to those of the

CMSLegData (see 8.3.10), except for the index which is defined by two CMS indices as
the difference between Index1 and Index2.
The payout for each coupon is thus:
N · (gearing · (Index1 − Index2) + Spread) · daycountf raction
Adding a cap, and assuming no spread, a gearing of 1, a daycount fraction of 1, and a
notional of 1, the payout becomes:
min(Cap; Index1 − Index2)

670
If there is a floor instead of a cap, the payout is:
max(F loor; Index1 − Index2)
Note that a CMS Spread Option can be created by setting NakedOption to true. With
this setting, the payout for the CMS Spread leg with a cap becomes an option with the
cap rate as strike:
max(0; (Index1 − Index2) − Cap)
And the payout for a CMS Spread leg with a floor, and with NakedOption set to true
is :
max(0; F loor − (Index1 − Index2))

8.3.15 Digital CMS Spread Leg Data

Listing 474 shows an example for a leg of type DigitalCMSSpread.

671
Listing 474: Digital CMS Spread leg data

<LegData>
<LegType>DigitalCMSSpread</LegType>
<Payer>false</Payer>
<Currency>GBP</Currency>
<Notionals>
<Notional>10000000</Notional>
</Notionals>
<DayCounter>ACT/ACT</DayCounter>
<PaymentConvention>Following</PaymentConvention>
<ScheduleData>
...
</ScheduleData>
<DigitalCMSSpreadLegData>
<CMSSpreadLegData>
<Index1>EUR-CMS-10Y</Index1>
<Index2>EUR-CMS-2Y</Index2>
<Spreads>
<Spread>0.0010</Spread>
</Spreads>
<Gearings>
<Gearing>8.0</Gearing>
</Gearings>
<NakedOption>false</NakedOption>
</CMSSpreadLegData>
<CallPosition>Long</CallPosition>
<IsCallATMIncluded>false</IsCallATMIncluded>
<CallStrikes>
<Strike>0.0001</Strike>
</CallStrikes>
<CallPayoffs>
<Payoff>0.0001</Payoff>
</CallPayoffs>
<PutPosition>Long</PutPosition>
<IsPutATMIncluded>false</IsPutATMIncluded>
<PutStrikes>
<Strike>0.001</Strike>
</PutStrikes>
<PutPayoffs>
<Payoff>0.001</Payoff>
</PutPayoffs>
</DigitalCMSSpreadLegData>
</LegData>

The DigitalCMSSpreadLegData block contains the following elements:

• CMSSpreadLegData: a CMSSpreadLegData block describing the underlying
Digital CMS Spread leg (see 8.3.14). Caps and floors in the underlying CMS
Spread leg are not supported for Digital CMS Spread Options. The NakedOption
flag in the CMSSpreadLegData block is supported and can be used to separate the
digital option payoff from the underlying CMS Spread coupon.
• CallPosition: Specifies whether the call option position is long or short.
• IsCallATMIncluded: inclusion flag on the call payoff if the call option ends
at-the-money

672
 • CallStrikes: strike rate for the call option
• CallPayoffs: digital call option payoff rate. If included the option is
cash-or-nothing, if excluded the option is asset-or-nothing
• PutPosition: Specifies whether the put option position is long or short.
• IsPutATMIncluded: inclusion flag on the put payoff if the put option ends
at-the-money
• PutStrikes: strike rate for the put option
• PutPayoffs: digital put option payoff rate. If included the option is
cash-or-nothing, if excluded the option is asset-or-nothing

8.3.16 Equity Leg Data

Listing 475 shows an example of a leg of type Equity. Note that a resetting Equity Leg
(NotionalReset set to true) must have either:
a) a Quantity, or
b) an InitialPrice and a Notional in the leg
The EquityLegData block contains the following elements:
• Quantity[Optional with one exception]: The number of shares. Either a Notional
or the Quantity must be given for the leg, but not both at the same time.
Quantity is optional with the exception that when FXTerms is used and
NotionalReset is set to true, and the InitialPriceCurrency differs from the leg
currency, Quantity must be given, and Notional cannot be used.
Allowable values: Any positive real number
• ReturnType: Price indicates that the coupons on the equity leg are determined
by the price movement of the underlying equity, i.e.:
N otional · F inalPInitialP
rice−InitialP rice
rice
,
Total indicates that coupons are determined by the total return of the underlying
equity including dividends, i.e.:
N otional · (F inalP rice+dividends∗DividendF
InitialP rice
actor)−InitialP rice
,
Dividend indicates that the coupons are determined by the dividened paid on the
underlying equity.
Allowable values: Price, PRICE, Total, TOTAL, Dividend, DIVIDEND
• Name: The identifier of the underlying equity or equity index.
Allowable values: See Name for equity trades in Table 41.
• Underlying: This node may be used as an alternative to the Name node to specify
the underlying equity. This in turn defines the equity curve used for pricing. The
Underlying node is described in further detail in Section 8.3.29.
• InitialPrice [Optional]: Initial Price of the equity, if not present, the first
valuation date is used to determine the initial price. If InitialPrice is zero then
each coupon’s price is just the discounted fixing from the coupon’s
FixingEndDate. For any divisions we assume the value is one, i.e. when

673
 NotionalReset = true we have instead Quantity = Notional. The Initial price can
be either given in the currency of the equity or in the leg currency, see
InitialPriceCurrency.
Allowable values: Any positive real number. If omitted or left blank it defaults
to the equity price of the fixing at the valuation date associated with the start
date. Note that when this valuation date is in the future the forward equity price
is used.
• InitialPriceCurrency [Optional]: If an initial price is given, it can be either given
in the original equity ccy or the leg currency (if these are different). This field
determines in which currency the initial price is given. If omitted, it is assumed
that the initial price is given in equity currency.
Allowable values: A valid currency code, See Fiat Currencies and Minor
Currencies in Table 32.
• NotionalReset [Optional]: Defaults to true. Notional resets only affect the equity
leg. If NotionalReset is set to true the quantity or number of shares of the
underlying equity is fixed for all the coupons on the equity leg and the Notional
for a period is computed as
Notional = Quantity x (share price at valuation date for period) x (FX
conversion rate at valuation date for period)
Notice that either a) the Quantity or b) a Notional and an explicit InitialPrice
must be given in the leg data for a resettable leg. In the latter case the Quantity
is computed as
Quantity = Notional / InitialPrice
No FX conversion is allowed if the Quantity has to be derived from the Notional
and the InitialPrice.
If NotionalReset is set to false the quantity of the underlying equity varies per
period, as per:
Quantity = Notional / (Equity Price at valuation date for the period)
For the first period, the InitialPrice is the Equity Price at valuation date. Here,
the Notional is taken to be the Notional specified in the leg or - if the Quantity is
given - to be
Notional = Quantity x InitialPrice
where again the InitialPrice must be explicitly given in the leg data and no FX
conversion is allowed in this case.
Allowable values: true or false
• DividendFactor [Optional]: Factor of dividend to be included in return. Note
that the DividendFactor is only relevant when the ReturnType is set to Total. It
is not used if the ReturnType is set to Price.
Allowable values: 0 < DividendFactor ≤ 1. Defaults to 1 if left blank or omitted.
• ValuationSchedule [Optional]: Schedule of dates for equity valuation.

674
 Allowable values: A node of the same form as ScheduleData, (see 8.3.4). Note
that the number of dates (and periods) in the ValuationSchedule must be the
same as in the ScheduleData. If omitted, equity valuation dates follow the
schedule of the equity leg adjusted for FixingDays.
• FixingDays [Optional]: The number of days before payment date for equity
valuation. N.B. Only used when no valuation schedule present. Defaults to 0.
Allowable values: Any non-negative integer.
• FXTerms [Mandatory when leg and equity currencies differ]: For the case when
the currency the underlying equity is quoted in, is different from the leg currency.
The FXTerm node contains the following elements:
– EquityCurrency [Mandatory within FXTerms]: Currency underlying equity
is quoted in. Required if FXTerms is present.
Allowable values: See Fiat Currencies and Minor Currencies in Table 32.
– FXIndex [Mandatory within FXTerms]: Name of the index for FX fixings for
the leg vs equity currency pair, e.g. FX-TR20H-EUR-USD for Thomson
Reuters 20:00 EURUSD FX fixing. Required if FXTerms present.
Allowable values: See Table 38

675
Listing 475: Equity leg data

<LegData>
<LegType>Equity</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<DayCounter>ACT/ACT</DayCounter>
<PaymentConvention>Following</PaymentConvention>
<ScheduleData>
<Rules>
<StartDate>2016-03-01</StartDate>
<EndDate>2018-03-01</EndDate>
<Tenor>3M</Tenor>
<Calendar>TARGET</Calendar>
<Convention>ModifiedFollowing</Convention>
<TermConvention>ModifiedFollowing</TermConvention>
<Rule>Forward</Rule>
<EndOfMonth/>
<FirstDate/>
<LastDate/>
</Rules>
</ScheduleData>
<EquityLegData>
<Quantity>1000.0</Quantity>
<ReturnType>Price</ReturnType>
<Underlying>
<Type>Equity</Type>
<Name>.SPX</Name>
<IdentifierType>RIC</IdentifierType>
</Underlying>
<InitialPrice>100</InitialPrice>
<NotionalReset>true</NotionalReset>
<DividendFactor>1</DividendFactor>
<ValuationSchedule>
<Dates>
<Calendar>USD</Calendar>
<Convention>ModifiedFollowing</Convention>
<Dates>
<Date>2016-03-01</Date>
<Date>2016-06-01</Date>
<Date>2016-09-01</Date>
<Date>2016-12-01</Date>
<Date>2017-03-01</Date>
<Date>2017-06-01</Date>
<Date>2017-09-01</Date>
<Date>2017-12-01</Date>
<Date>2018-03-01</Date>
</Dates>
</Dates>
</ValuationSchedule>
<FixingDays>0</FixingDays>
<FXTerms>
<EquityCurrency>USD</EquityCurrency>
<FXIndex>FX-TR20H-EUR-USD</FXIndex>
<FXTerms>
</EquityLegData>
</LegData>

676
8.3.17 CPI Leg Data
A CPI leg contains a series of CPI-linked coupon payments N r (I(t)/I0 ) δ and, if
NotionalFinalExchange is set to true, a final inflation-linked redemption (I(t)/I0 ) N .
Each coupon and the final redemption can be subtracting the (un-inflated) notional N ,
i.e. (I(t)/I0 − 1) N , see below.
Note that CPI legs with just a final redemption and no coupons, can be set up with a
dates-based Schedule containing just a single date - representing the date of the final
redemption flow. In this case NotionalFinalExchange must be set to true, otherwise
the whole leg is empty, and the Rate is not used and can be set to any value.
Listing 476 shows an example for a leg of type CPI with annual coupons, and 477
shows an example for a leg of type CPI with just the final redemption.
The CPILegData block contains the following elements:
• Index: The underlying zero inflation index.
Allowable values: See Inflation CPI Index in Table 39.
• Rates: The contractual fixed real rate(s) of the leg, r. As usual, this can be a
single value, a vector of values or a dated vector of values.
Note that a CPI leg coupon payment at time t is:

I(t)
Nr δ
I0
where:
– N : notional
– r: the contractual fixed real rate
– I(t): the relevant CPI fixing for time t
– I0 : the BaseCPI
– δ: the day count fraction for the accrual period up to time t
Allowable values: Each rate element can take any real number. The rate is
expressed in decimal form, e.g. 0.05 is a rate of 5%.
• BaseCPI [Optional]: The base CPI value I0 used to determine the lifting factor
for the fixed coupons. If omitted it will take the observed CPI fixing on
startDate - observationLag.
Allowable values: Any positive real number.
• StartDate [Optional]: The start date needs to be provided in case the schedule
comprises only a single date. If the schedule has at least two dates and a start
date is given at the same time, the first schedule date is taken as the start date
and the supplied StartDate is ignored.
Allowable values: See Date in Table 30.
• ObservationLag [Optional]: The observation lag to be applied. It’s the amount of
time from the fixing at the start or end of the period, moving backward in time,

677
 to the inflation index observation date (the inflation fixing). Fallback to the
index observation lag as specified in the inflation swap conventions of the
underlying index, if not specified.
Allowable values: An integer followed by D, W, M or Y. Interpolation lags are
typically expressed in a positive number of M, months. Note that negative values
are allowed, but mean that the inflation is observed forward in time from the
period start/end date, which is unusual.
• Interpolation [Optional]: The type of interpolation that is applied to inflation
fixings. Linear interpolation means that the inflation fixing for a given date is
interpolated linearly between the surrounding - usually monthly - actual fixings,
whereas with Flat interpoltion the inflation fixings are constant for each day at
the value of the previous/latest actual fixing (flat forward interpolation).
Fallback to the Interpolation as specified in the inflation swap conventions of the
underlying index, if not specified.
Allowable values: Linear, Flat
• SubtractInflationNotional [Optional]: A flag indicating whether the non-inflation
adjusted notional amount should be subtracted from the final inflation-adjusted
notional exchange at maturity. Note that the final coupon payment is not
affected by this flag.
Final notional payment if true: N (I(T )/I0 − 1).
Final notional payment if false: N I(T )/I0
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46.
Defaults to false if left blank or omitted.
• SubtractInflationNotionalAllCoupons [Optional]: A flag indicating whether the
non-inflation adjusted notional amount should be subtracted from all coupons.
Note that the final redemption payment is not affected by this flag.
Coupon payment if true: N (I(T )/I0 − 1).
Coupon payment if false: N I(T )/I0
Allowable values: Boolean node, allowing Y, N, 1, 0, true, false etc. The full set
of allowable values is given in Table 46.
Defaults to false if left blank or omitted.
• Caps [Optional]: This node contains child elements of type Cap indicating that
the inflation indexed payment is capped; the cap is applied to the inflation index
and expressed as an inflation rate, see CPI Cap/Floor in the Product Description.
If the cap is constant over the life of the cpi leg, only one cap value should be
entered. If two or more coupons have different caps, multiple cap values are
required, each represented by a Cap child element. The first cap value
corresponds to the first coupon, the second cap value corresponds to the second
coupon, etc. If the number of coupons exceeds the number of cap values, the cap
will be kept at at the value of last entered spread for the remaining coupons. The
number of entered cap values cannot exceed the number of coupons. Notice that
the caps defined under this node only apply to the cpi coupons, but not a final
notional flow (if present). A cap for the final notional flow can be defined under

678
 the FinalFlowCap node.
Allowable values: Each child element can take any real number. The cap is
expressed in decimal form, e.g. 0.03 is a cap of 3%.
• Floors [Optional]: This node contains child elements of type Floor indicating
that the inflation indexed payment is floored; the floor is applied to the inflation
index and expressed as an inflation rate. The mode of specification is analogous
to caps, see above. Notice that the floors defined under this node only apply to
the cpi coupons, but not a final notional flow (if present). A floor for the final
notional flow can be defined under the FinalFlowFloor node.
Allowable values: Each child element can take any real number. The floor is
expressed in decimal form, e.g. 0.01 is a cap of 1%.
• FinalFlowCap [Optional]: The cap to be applied to the final notional flow of the
cpi leg. If not given, no cap is applied.
Note that final and non-final inflation cap/floor strikes are quoted as a number K
and converted to a price via:
(1 + K)t
where
K = the cap/floor rate
t = time to expiry.
So inflation caps/floors are caps/floors on the inflation rate and not the inflation
index ratio. For example, to cap the final flow at the initial notional it should be
K=0, i.e. FinalFlowCap should be 0.
Allowable values: A real number. The FinalFlowCap is expressed in decimal
form, e.g. 0.01 is a cap on the final flow at 1% of the inflation rate over the life of
the trade.
• FinalFlowFloor [Optional]: The floor to be applied to the final notional flow of
the cpi leg. If not given, no floor is applied.
Allowable values: A real number. The FinalFlowFloor is expressed in decimal
form, e.g. 0.01 is a floor on the final flow at 1% of the inflation rate over the life
of the trade.
• NakedOption [Optional]: Optional node, if true the leg represents only the
embedded floor, cap or collar. By convention these embedded options are
considered long if the leg is a receiver leg, otherwise short.
Allowable values: true, false. Defaults to false if left blank or omitted.
Whether the leg cotains a final redemption flow at all or not depends on the notional
exchange setting, see section 8.3.3 and listing 455.

679
Listing 476: CPI leg data with capped annual coupons

<LegData>
<LegType>CPI</LegType>
<Payer>false</Payer>
<Currency>GBP</Currency>
<Notionals>
<Notional>10000000</Notional>
<Exchanges>
<NotionalInitialExchange>false</NotionalInitialExchange>
<NotionalFinalExchange>true</NotionalFinalExchange>
</Exchanges>
</Notionals>
<DayCounter>ACT/ACT</DayCounter>
<PaymentConvention>Following</PaymentConvention>
<ScheduleData>
<Rules>
<StartDate>2016-07-18</StartDate>
<EndDate>2021-07-18</EndDate>
<Tenor>1Y</Tenor>
<Calendar>UK</Calendar>
<Convention>ModifiedFollowing</Convention>
<TermConvention>ModifiedFollowing</TermConvention>
<Rule>Forward</Rule>
<EndOfMonth/>
<FirstDate/>
<LastDate/>
</Rules>
</ScheduleData>
<CPILegData>
<Index>UKRPI</Index>
<Rates>
<Rate>0.02</Rate>
</Rates>
<BaseCPI>210</BaseCPI>
<StartDate>2016-07-18</StartDate>
<ObservationLag>2M</ObservationLag>
<Interpolation>Linear</Interpolation>
<Caps>
<Cap>0.03</Cap>
</Caps>
<Floors>
<Floor>0.0</Floor>
<Floors>
<FinalFlowCap>0.03</FinalFlowCap>
<FinalFlowFloor>0.0</FinalFlowFloor>
<NakedOption>false</NakedOption>
<SubtractInflationNotionalAllCoupons>false</SubtractInflationNotionalAllCoupons>
</CPILegData>
</LegData>

680
Listing 477: CPI leg data with just the final redemption

<LegData>
<Payer>false</Payer>
<LegType>CPI</LegType>
<Currency>GBP</Currency>
<PaymentConvention>ModifiedFollowing</PaymentConvention>
<DayCounter>ActActISDA</DayCounter>
<Notionals>
<Notional>25000000.0</Notional>
<Exchanges>
<NotionalInitialExchange>false</NotionalInitialExchange>
<NotionalFinalExchange>true</NotionalFinalExchange>
</Exchanges>
</Notionals>
<ScheduleData>
<Dates>
<Calendar>GBP</Calendar>
<Dates>
<Date>2020-08-17</Date>
</Dates>
</Dates>
</ScheduleData>
<CPILegData>
<Index>UKRPI</Index>
<Rates>
<Rate>1.0</Rate>
</Rates>
<BaseCPI>280.64</BaseCPI>
<StartDate>2018-08-19</StartDate>
<ObservationLag>2M</ObservationLag>
<Interpolation>Linear</Interpolation>
<SubtractInflationNotional>true</SubtractInflationNotional>
<SubtractInflationNotionalAllCoupons>false</SubtractInflationNotionalAllCoupons>
</CPILegData>
</LegData>

8.3.18 YY Leg Data

Listing 478 shows an example for a leg of type YY. The YYLegData block contains the
following elements:
• Index: The underlying zero inflation index.
Allowable values: Any string (provided it is the ID of an inflation index in the
market configuration).
• FixingDays: The number of fixing days.
Allowable values: An integer followed by D,
• ObservationLag [Optional]: The observation lag to be applied. Fallback to the
index observation lag as specified in the inflation swap conventions of the
underlying index, if not specified.
Allowable values: An integer followed by D, W, M or Y. Interpolation lags are
typically expressed in M, months.

681
• Spreads [Optional]: The spreads applied to index fixings. As usual, this can be a
single value, a vector of values or a dated vector of values.
• Gearings [Optional]: This node contains child elements of type Gearing
indicating that the coupon rate is multiplied by the given factors. The mode of
specification is analogous to spreads, see above.
• Caps [Optional]: This node contains child elements of type Cap indicating that
the coupon rate is capped at the given rate (after applying gearing and spread, if
any).
• Floors [Optional]: This node contains child elements of type Floor indicating
that the coupon rate is floored at the given rate (after applying gearing and
spread, if any).
• NakedOption [Optional]: Optional node (defaults to N), if Y the leg represents
only the embedded floor, cap or collar. By convention these embedded options
are considered long if the leg is a receiver leg, otherwise short.
• AddInflationNotional [Optional]: If true, the payoff will include the notional of
the coupon N τ It−1Y
It
.
• IrregularYoY [Optional]: If true, instead of using a YoY inflation rate the coupon
is based on the inflation rate during the actual coupon period, e.g. for a 6M
coupon the inflation rate will be computed as It−6m
It
− 1.

682
Listing 478: YY leg data

<LegData>
<LegType>YY</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>10000000</Notional>
</Notionals>
<DayCounter>ACT/ACT</DayCounter>
<PaymentConvention>Following</PaymentConvention>
<ScheduleData>
<Rules>
<StartDate>2016-07-18</StartDate>
<EndDate>2021-07-18</EndDate>
<Tenor>1Y</Tenor>
<Calendar>UK</Calendar>
<Convention>ModifiedFollowing</Convention>
<TermConvention>ModifiedFollowing</TermConvention>
<Rule>Forward</Rule>
<EndOfMonth/>
<FirstDate/>
<LastDate/>
</Rules>
</ScheduleData>
<YYLegData>
<Index>EUHICPXT</Index>
<FixingDays>2</FixingDays>
<ObservationLag>2M</ObservationLag>
<Interpolated>true</Interpolated>
<Spreads>
<Spread>0.0010</Spread>
</Spreads>
<Gearings>
<Gearing>2.0</Gearing>
</Gearings>
<Caps>
<Cap>0.05</Cap>
</Caps>
<Floors>
<Floor>0.01</Floor>
</Floors>
<NakedOption>N</NakedOption>
<AddInflationNotional>false</AddInflationNotional>
<IrregularYoY>false</IrregularYoY>
</YYLegData>
</LegData>

8.3.19 ZeroCouponFixed Leg Data

A Zero Coupon Fixed leg contains a series of Zero Coupon payments, i.e (1 + r)t N for
a compounded coupon. The uninflated notional N can be subtracted from the
payment , i.e ((1 + r)t − 1) N , see SubtractNotional below.
Listing 479 shows an example for a leg of type Zero Coupon Fixed.
To create a leg with only one payment, the schedule must only contain the start and

683
end date. Note that this can be achieved by setting the Tenor to 0D or 1T in a rules
based Schedule.
Note that the DayCounter in a Zero Coupon Fixed leg is used to compute t in (1 + r)t
so that the series of zero coupon payments are calculated as (1 + r)t N . For all other
leg types, the DayCounter is used to compute the “Accrual” (i.e. the accrual time
period of a coupon) in a coupon payment calculated as: N ∗ Accrual ∗ r. However, the
“Accrual” in the coupon formula is defaulted to 1 for the Zero Coupon Fixed leg type.
• Rates: The fixed real rate(s) of the leg. While this can be a single value, a vector
of values or a dated vector of values.
Allowable values: Each rate element can take any real number. The rate is
expressed in decimal form, e.g. 0.05 is a rate of 5%.
• Compounding [Optional]: The method of compounding applied to the rate.
Allowable values: Simple i.e. (1 + r ∗ t), or Compounded i.e. (1 + r)t . Defaults to
Compounded if left blank or omitted.
• SubtractNotional [Optional]: Decides whether the notional is subtracted from the
compounding factor, i.e. (1 + r ∗ t) − 1 respectively (1 + r)t − 1, or not, i.e.
(1 + r ∗ t) respectively (1 + r)t
Note that if NotionalFinalExchange is set to true an additional final uninflated
notional flow N is added. So if NotionalFinalExchange is set to true, and
SubtractNotional is set to false, there will be two final notional flows. It is
recommended to omit NotionalFinalExchange causing it to default to false, and
solely use SubtractNotional to determine the final notional flow.
Allowable values: true, Y or false, N, defaults to true if left blank or omitted.

684
Listing 479: ZeroCouponFixed leg data

<LegData>
<LegType>ZeroCouponFixed</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>10000000</Notional>
</Notionals>
<DayCounter>Year</DayCounter>
<PaymentConvention>Following</PaymentConvention>
<ScheduleData>
<Rules>
<StartDate>2016-07-18</StartDate>
<EndDate>2021-07-18</EndDate>
<Tenor>0D</Tenor>
<Calendar>UK</Calendar>
<Convention>ModifiedFollowing</Convention>
<TermConvention>ModifiedFollowing</TermConvention>
<Rule>Forward</Rule>
<EndOfMonth/>
<FirstDate/>
<LastDate/>
</Rules>
</ScheduleData>
<ZeroCouponFixedLegData>
<Rates>
<Rate>0.02</Rate>
</Rates>
<Compounding>Simple</Compounding>
<SubtractNotional>false</SubtractNotional>
</ZeroCouponFixedLegData>
</LegData>

8.3.20 Commodity Fixed Leg

A commodity fixed leg is specified in a LegData node with LegType set to
CommodityFixed. It is used to define a sequence of cashflows that are linked to a fixed
price in a commodity derivative contract. Each cashflow has an associated Calculation
Period. The outline of a commodity fixed leg is given in listing 480. It has the usual
LegData elements described in section 8.3.3 and a CommodityFixedLegData node that
is described in section 8.3.21 below. The section 8.3.23 describes some aspects of the
ScheduleData node in the context of commodity derivatives.

8.3.21 Commodity Fixed Leg Data

The CommodityFixedLegData node outline is shown in listing 481. The meaning and
allowable values for each node are as follows:
• Quantities [Optional]: this node is used to specify a constant quantity or a
quantity that varies over the calculation periods. The usage of this node is
analagous to the usage of the Notionals node as outlined in section 8.3.3. For
convenience, this node can be omitted if the quantities are identical to those on a
commodity floating leg, outlined in Section 8.3.22, on the same trade. In this

685
 case, the quantities from the floating leg are used. If there is only a single
commodity floating leg, as is the case in a standard swap, the quantities are
taken from that leg. If there are multiple commodity floating legs on the trade, a
specific commodity floating leg can be picked using the Tag node specified below.
In other words, a Tag can be specified on the fixed leg and the same Tag specified
on the floating leg from which the quantities should be taken.
• Prices: this node is used to specify a constant price or a price that varies over
the calculation periods. The usage of this node is analagous to the usage of the
Notionals node as outlined in section 8.3.3.
• CommodityPayRelativeTo [Optional]: the allowable values for this node are
CalculationPeriodStartDate, CalculationPeriodEndDate,
TerminationDate, FutureExpiryDate. They specify whether payment is relative
to the calculation period start date, calculation period end date, leg maturity
date or the future expiry date (of the corresponding cashflow on the floating leg
with the same Tag as the fixed leg) respectively. The default is
CalculationPeriodEndDate. The payment date is then further adjusted by the
payment conventions outlined in section 8.3.3 i.e. PaymentConvention and
PaymentLag. If explicit payment dates are given via the PaymentDates node
described in section 8.3.3, then those explicit payment dates are used instead and
adjusted by the PaymentCalendar and PaymentConvention.
• Tag [Optional]: The use of this node is explained in the Quantities resp.
CommodityPayRelativeTo piece above.

8.3.22 Commodity Floating Leg

A commodity floating leg is specified in a LegData node with LegType set to
CommodityFloating. It is used to define a sequence of cashflows that are linked to the
price of a given commodity. Each cashflow has an associated Calculation Period. The
price that is being referenced may be a commodity spot price or a commodity future
contract settlement price. The cashflow may depend on the price observed on a single
Pricing Date in the Calculation Period or it may depend on the arithmetic average of
the prices over some or all of the business days in the Calculation Period.
The outline of a commodity floating leg is given in listing 482. It has the usual
LegData elements described in section 8.3.3 and a CommodityFloatingLegData node
that is described in section 8.3.24 below. Before describing the
CommodityFloatingLegData node, we devote section 8.3.23 to the ScheduleData node
in the context of commodity derivatives.

8.3.23 Commodity Schedules

The Calculation Period in a commodity derivative contract is in general specified as a
period from and including a given Start Date to and including a given End Date. A
commodity trade leg consists of a sequence of these Calculation Period s. It is
important to set up the ScheduleData in the trade XML such that these periods are
correctly represented in the ORE instrument. The ScheduleData allows for the
creation of a list of dates that define the boundaries of the periods from the trade
Effective Date to the trade Termination Date. When the ScheduleData is used on a

686
commodity leg in the ORE trade XML, the StartDate is included in the first period
and the EndDate is included in the final period. Each intervening date generated by
the ScheduleData is understood to be the included end date of a period with the
subsequent period beginning on the day after the intervening date. The following two
examples illustrate the set up of the ScheduleData.
A common commodity derivative schedule is one that has monthly periods running
from and including the first calendar day in the month to and including the last
calendar day in the month. For example, the contract periods may be specified as
shown in table 25. The corresponding ScheduleData node that should be used to
represent this in ORE XML is shown in listing 483. Note that Convention and
TermConvention are set to Unadjusted and EndOfMonth is set to true to place all
dates at the end of the month when generating the dates Backward from 30 Apr 2020.
In general, these values should be used when generating monthly periods for
commodity derivatives.

Start Date End Date

2020-01-01 2020-01-31
2020-02-01 2020-02-29
2020-03-01 2020-03-31
2020-04-01 2020-04-30

Table 25: Commodity derivative monthly schedule.

Note that for fixed and floating commodity legs, the

AdjustEndDateToPreviousMonthEnd field can be added to automatically adjust the
end date to the end of the previous month:
AdjustEndDateToPreviousMonthEnd [Optional]: Only relevant for commodity legs.
Allows for the EndDate to be on a date other than the end of the month. If set to true
the given EndDate is restated to the end date to the end of previous month.
Allowable values: true or false. Defaults to false if left blank or omitted.
In certain cases, a sequence of periods may be provided which do not fit within the
Rules provided by ScheduleData. In this case, one may use the Dates node provided
by ScheduleData. As an example of such a case, consider table 26 which shows the
periods for a commodity swap leg on the arithmetic average of the nearby month
NYMEX WTI future contract settlement price. In this example, the Calculation
Period runs from the day after the previous future contract expiry to and including the
nearby month’s contract expiry. In this case, we need to use explicit dates as shown in
listing 484.

Start Date End Date

2019-11-21 2019-12-19
2019-12-20 2020-01-21
2020-01-22 2020-02-20
2020-02-21 2020-03-20

Table 26: Commodity derivative explicit schedule.

687
8.3.24 Commodity Floating Leg Data
The CommodityFloatingLegData node outline is shown in listing 485. The meaning
and allowable values for each node are as follows:
• Name: An identifier specifying the commodity being referenced in the leg. Table
42 lists the allowable values for Name and gives a description.
• PriceType: It is Spot if the leg is referencing a commodity spot price. It is
FutureSettlement if the leg is referencing a commodity future contract settlement
price.
Allowable values: Spot, FutureSettlement
• Quantities: This node is used to specify a constant quantity or a quantity that
varies over the calculation periods. The usage of this node is analogous to the
usage of the Notionals node as outlined in section 8.3.3.
Each Quantity is the number of units of the underlying commodity covered by
the transaction or calculation period. The unit type is defined in the underlying
contract specs for the commodity name in question. For avoidance of doubt, the
Quantity is the number of units of the underlying commodity, not the number of
contracts.
• CommodityQuantityFrequency [Optional]: In some cases, the quantity in a
commodity derivatives contract is given as a quantity per time period. This
quantity is then multiplied by the number of such time periods in each
calculation period to give the quantity relevant for that full calculation period.
The CommodityQuantityFrequency can be set to
– PerCalculationPeriod : This indicates that quantitie(s) as given are for the
full calculation period and that no multiplication or alteration is required.
This is the default setting if this node is omitted.
– PerPricingDay: This indicates that the quantitie(s) are to be considered
per pricing date. In general, this can be seen on averaging contracts where
the quantity provided must be multiplied by the number of pricing dates in
the averaging period to give the quantity applicable for the full calculation
period i.e. the quantity to which the average price over the period is applied.
– PerHour : This indicates that quantitie(s) are to be considered per hour.
This is common in the electricity markets. The quantity then must be
multiplied by the hours per day to give the quantity for a given pricing
date. Also, if the contract is averaging, the resulting daily amount is
multiplied by the number of pricing dates in the period to give the quantity
for the full calculation period. Note that the hours per day may be specified
in the HoursPerDay node directly. If it is omitted, it is looked up in the
conventions associated with the commodity. If it is not found there and
PerHour is used, an exception is thrown during trade building.
– PerCalendarDay: This indicates that quantitie(s) are to be considered per
calendar day in the period. In other words, the quantity provided is
multiplied by the number of calendar days in the period to give the quantity
applicable for the full calculation period.

688
 – PerHourAndCalendarDay: This indicates that quantitie(s) are to be
considered per hour and per calendar day in the period. In other words, the
quantity provided is multiplied by the number of calendar days and number
of hours per day in the period to give the quantity applicable for the full
calculation period. The number of hours per period is corrected by daylight
saving hours as specified in the conventions of the commodity.
Allowable values: PerCalculationPeriod, PerPricingDay, PerHour,
PerCalendarDay, PerHourAndCalendarDay. Defaults to PerCalculationPeriod if
omitted.
• CommodityPayRelativeTo [Optional]: The allowable values for this node are
CalculationPeriodStartDate, CalculationPeriodEndDate, TerminationDate,
FutureExpiryDate. They specify whether payment is relative to the calculation
period start date, calculation period end date, leg maturity date or the future
expiry date (not allowed for averaging legs) respectively. The default is
CalculationPeriodEndDate. The payment date is then further adjusted by the
payment conventions outlined in section 8.3.3 i.e. PaymentConvention and
PaymentLag. If explicit payment dates are given via the PaymentDates node
described in section 8.3.3, then those explicit payment dates are used instead and
adjusted by the PaymentCalendar and PaymentConvention.
Allowable values: CalculationPeriodStartDate, CalculationPeriodEndDate,
TerminationDate. Defaults to CalculationPeriodEndDate if omitted.
• Spreads [Optional]: This node allows for the addition of an optional spread to
the referenced commodity price in each calculation period. The usage of this
node is exactly as described in section 8.3.6, except that for a Commodity leg,
the Spread is not a percentage but an amount in the currency the commodity is
quoted in.
Allowable values: Each child Spread element can take any real number. Defaults
to zero spread in each calculation period if the Spreads node is omitted.
• Gearings [Optional]: This node allows for the multiplication of the referenced
commodity price in each calculation period by an optional gearing factor. The
usage of this node is exactly as described in section 8.3.6. If the Gearings node
is omitted, the gearing is one in each calculation period. Note that any spread is
added to the referenced price before the gearing is applied.
• PricingDateRule [Optional]: The allowable values are FutureExpiryDate and
None. This setting is ignored when IsAveraged is true or when PriceType is
Spot. In particular, when there is no averaging and the leg is referencing a
commodity future contract price, setting PricingDateRule to FutureExpiryDate
ensures that the future contract price is observed on its expiry date i.e. that the
Pricing Date is the future contract expiry date. The particular future contract
being referenced is determined by the IsInArrears node and the
FutureMonthOffset node. If IsInArrears is true, a base date is set as the
calculation period end date. If IsInArrears is false a base date is set as the
calculation period start date. The base date’s month and year is then possibly
moved forward by an integral number of months using the FutureMonthOffset
node value. If this node value is zero, the base date’s month and year are

689
 unchanged. The Pricing Date is then the expiry date of the future contract with
base date month and base date year. Setting PricingDateRule to None allows
the Pricing Date to be determined using the PricingCalendar and PricingLag
below.
Allowable values: FutureExpiryDate, None. Defaults to FutureExpiryDate if
omitted.
• PricingCalendar [Optional]: This is the business day calendar used to
determine pricing date(s) and in the application of the PricingLag if provided.
If it is omitted, the calendar that has been set up for the reference commodity
future contract or referenced commodity spot price will be used.
• PricingLag [Optional]: Any non-negative integer is allowed here. This node
indicates that the Pricing Date is this number of business days before a given
base date. The base date is the period start date if IsInArrears is true and it is
the period end date if IsInArrears is false. This setting is not used when
IsAveraged is true.
Allowable values: Any non-negative integer. Defaults to zero if omitted.
• PricingDates [Optional]: This node is not used when IsAveraged is true. When
IsAveraged is false, this node allows the Pricing Date in each period to be given
an explicit value. If this node is included, it must contain the same number of
PricingDate nodes as calculation periods. In general, this node is omitted but is
used when the other options do not give the desired Pricing Date as specified in
the trade’s contractual terms.
• IsAveraged [Optional]: This node is set to true if the Floating Price is the
arithmetic average of the commodity reference price over each business day in
the calculation period. This node is set to false if there is no averaging of the
underlying commodity price. Note that IsAveraged must be set to true if the
Name given references a future contract that is averaging itself. There is more on
this below.
Allowable values: true, false. Defaults to false if omitted.
• IsInArrears [Optional]: This node is not used when IsAveraged is true.
Although, if the observed underlying is averaging itself, having IsAveraged set
to true would be ignored with regards this node. As noted above, this setting
determines a base date from which the Pricing Date is determined. The base
date is the period end date if IsInArrears is true and it is the period start date
if IsInArrears is false. How the Pricing Date is then determined from this
base date is determined by the PricingDateRule node or the PricingCalendar
and PricingLag nodes.
Allowable values: true, false. Defaults to true if omitted.
• FutureMonthOffset [Optional]: This node allows any non-negative integer value.
If this node is omitted, it is set to zero. The node has a different usage depending
on whether IsAveraged is true or false:
– If IsAveraged is true, this node indicates which future contract is being
referenced on each Pricing Date in the calculation period by acting as an

690
 offset from the next available expiry date. If FutureMonthOffset is zero,
the settlement price of the next available monthly contract that has not
expired with respect to the Pricing Date is used as the price on that Pricing
Date. If FutureMonthOffset is one, the settlement price of the second
available monthly contract that has not expired with respect to the Pricing
Date is used as the price on that Pricing Date. Similarly for other positive
values of FutureMonthOffset.
– If IsAveraged is false, this node acts as an offset for the contract month
and is used in conjunction with the IsInArrears setting to determine the
future contract being referenced. If IsInArrears is true, a base date is set
as the calculation period end date. If IsInArrears is false, a base date is
set as the calculation period start date. If FutureMonthOffset is zero, the
future contract month and year is taken as the base date’s month and year.
If FutureMonthOffset is one, the future contract month and year is taken
as the month following the base date’s month and year and so on for all
positive values of FutureMonthOffset.
• DeliveryRollDays [Optional]: This node allows any non-negative integer value
and is only applicable when IsAveraged is true. When averaging a commodity
future contract price during a calculation period, where the calculation period
includes the contract expiry date, this node’s value indicates when we should
begin using the next future contract prices in the averaging. If the value is zero,
we should include the contract prices up to and including the contract expiry. If
the value is one, we should include the contract prices up to and including the
day that is one business day before the contract expiry and then switch to using
the next contract prices thereafter. Similarly for other non-negative integer
values.
Allowable values: Any non-negative integer. Defaults to zero if omitted.
• IncludePeriodEnd [Optional]: If this node is set to true, the period end date is
included in the calculation period. If it is set to false, the period end date is
excluded from the calculation period. There is more about this in the section
8.3.23. If this node is omitted, it is set to true. In general, this node should be
omitted and allowed to take its default value.
• ExcludePeriodStart [Optional]: If this node is set to true, the period start date
is excluded from the calculation period. If it is set to false, the period start date
is included from the calculation period. There is more about this in the section
8.3.23. If this node is omitted, it is set to true. In general, this node should be
omitted and allowed to take its default value.
• HoursPerDay [Optional]: This node is used if CommodityQuantityFrequency is
set to PerHour or PerHourAndCalendarDay. It is described above under
CommodityQuantityFrequency.
Allowable values: A number between 0 and 24. If omitted it defaults to the value
of the HoursPerDay node in the conventions for the referenced commodity.
• UseBusinessDays [Optional]: A boolean flag that defaults to true if omitted. It
is not applicable if IsAveraged is false. When set to true, the pricing dates in

691
 the averaging period are the set of PricingCalendar good business days. When
set to false, the pricing dates in the averaging period are the complement of the
set of PricingCalendar good business days. This may be useful in certain
situations. For example, the contract ICE PW2 with specifications here averages
the PJM Western Hub locational marginal prices over each day in the averaging
period that is a Saturday, Sunday or NERC holiday. So, in this case,
UseBusinessDays would be false and PricingCalendar would be US-NERC to
generate the correct pricing dates in the averaging period.
Allowable values: true, false. Defaults to true if omitted.
• UnrealisedQuantity [Optional]: A boolean flag that defaults to false if omitted.
This is a rarely used flag. When set to true, it allows the user, on a given
valuation date, to enter the current period quantity as an amount remaining in
the current period after the valuation date i.e. the unrealised portion of the
current period’s quantity. This unrealised quantity is then scaled up internally to
give the quantity over the full period.
Allowable values: true, false. Defaults to false if omitted.
• LastNDays [Optional]: This node allows a positive integer value less than or
equal to 31 and is currently only supported when PriceType is
FutureSettlement. When included, instead of the commodity future price being
observed on the single Pricing Date in the period, it is observed on the
LastNDays Pricing Dates, up to and including the original Pricing Date, for
which future settlement prices are available.
• Tag [Optional]: This node takes any string and can be used to link the floating
leg with a fixed leg that has not explicitly provided its own quantities. This can
be useful in situations where the quantities on the floating leg are specified with
a CommodityQuantityFrequency that is not simply PerCalculationPeriod.
The fixed leg does not have the CommodityQuantityFrequency field. In these
cases, the fixed leg can omit its Quantities node and take the quantities from
the floating leg. This Tag node allows the fixed leg to link to a specific floating
leg if there is more than one floating leg on the trade i.e. the fixed leg must just
have the same Tag. The link is also used to set the payment dates of the fixed leg
if CommodityPayRelativeTo is set to FutureExpiryDate.
• DailyExpiryOffset [Optional]: This node allows any non-negative integer value.
It only has effect the underlying commodity Name is not being averaged and has a
daily contract frequency.
If this node is omitted, it defaults to zero. This node indicates which future
contract is being referenced on each Pricing Date by acting as a business day
offset, using the commodity Name’s expiry calendar, from the Pricing Date. It is
useful e.g. in the base metals market where a future contract on each Pricing
Date is the cash contract on that Pricing Date i.e. the contract with expiry date
two business days after the Pricing Date. In this case, the DailyExpiryOffset
would be set to 2.
• FXIndex [Optional]: If IsAveraged is true this node allows the fx conversion to
be applied daily in the computation of averaged cash flows. It cannot be used

692
 with the Indexing node.
Allowable values: See Table 38 for supported fx indices.
We note above that IsAveraged must be set to true if the Name given references a
future contract that is averaging itself. For the avoidance of doubt, this does not lead
to the prices of the averaging future contract being averaged in each calculation period.
Instead, a check is performed in the code if the contract defined by Name is averaging,
and if the leg itself is averaging we switch to observing the averaging future contract
price on the single Pricing Date determined by the PricingDateRule node or the
PricingCalendar and PricingLag nodes or the PricingDates node. This is best
illustrated using an example. Suppose that we have a commodity swap with the
schedule shown in table 27. Suppose that the Floating Price for the swap is specified
as For each Calculation Period, the arithmetic average of the Commodity Reference
Price, for each Commodity Business Day in the Calculation Period and that the
Commodity Reference Price is specified as OIL-WTI-NYMEX with Delivery Date of
First Nearby Month. There are two approaches to setting up the XML for this
commodity floating leg:
1. The first approach is shown in listing 486. Note that the Name is NYMEX:CL to
indicate the NYMEX WTI future contract, IsAveraged is true and
FutureMonthOffset is 0 to indicate that we are using the nearby month contract
price in the averaging. This approach is clear.
2. The second approach is to use the CommodityFloatingLegData shown in listing
487. Note that we have changed the Name to NYMEX:CSX to reference the
NYMEX WTI Financial Futures contract. This future contract settlement price
at expiry is the exact payoff of the swap leg in that it is the arithmetic average of
the nearby month NYMEX WTI future contract settlement prices over the
calendar month. The contract details are given here. We keep IsAveraged set to
true. If we set IsAveraged to false, an error will be thrown. When
IsAveraged is set to true and the Name references a future contract that is
averaging, it is understood that the commodity leg is to use the same averaging
as the future contract. In this case, we switch to a non-averaging cashflow in the
code and read the averaged price directly off the price curve that we have set up
using the averaging future contract prices.
In some cases, we will only have an averaging future contract available as an allowable
Name value. For example, NYMEX:A7Q is one such instance. The contract details are
given here. This future contract’s price at the end of each contract month is the
arithmetic average of the OPIS Mt. Belvieu Natural Gasoline (non-LDH) price for
each business day during the contract month. The corresponding commodity floating
leg would be set up with Name set to NYMEX:A7Q and IsAveraged set to true. Again,
for the avoidance of doubt, we are not averaging the averaging future contract price.
Instead, we switch to a non-averaging cashflow in the code and read the averaged price
directly off the price curve that we have built out of NYMEX:A7Q future contract prices.
We are pricing a leg that has the same payoff as the future contract.
If we have an averaging coupon and the valuation date is during the coupon period,
the choice between the first and second approach above will have an effect on the
sensitivities that are generated for that one single coupon. It should not affect the

693
NPV of the coupon. The effect becomes more pronounced as the number of days
remaining in the coupon period reduce. In the first approach, the coupon is priced by
reading the expected future prices on future Pricing Dates off the non-averaging future
price curve and fetching past fixed settlement prices on past Pricing Dates. All of
these prices are then averaged. It is clear that as the valuation date approaches the
final date in the coupon period, the sensitivity decreases because any bump in the
curve used for pricing is only affecting the values on the remaining future Pricing
Dates. In the second approach, the average price relevant for the full coupon period is
read directly off the averaging future price curve. Any bump to the averaging future
price curve affects the full coupon regardless of the position of the valuation date in
the coupon period. The sensitivity will therefore be larger than using the first
approach and the difference will become more noticeable as the valuation date moves
towards the end of the coupon period. This subtlety can lead to differences that are
larger than expected on basis swaps with averaging coupons and short maturities. If
one commodity floating leg references a non-averaging price curve and the other leg
references an averaging price curve, the differing effects of the bump outlined above on
each leg can lead to a larger than expected net sensitivity.

Start Date End Date Quantity Per Period

2019-09-01 2019-09-30 5,000
2019-10-01 2019-10-31 5,000

Table 27: Example commodity swap schedule.

8.3.25 Equity Margin Leg

An equity margin leg is specified in a LegData node with LegType set to
EquityMargin. It is used to define a sequence of cashflows that are linked to an equity
price and it’s associated margin factor. Each cashflow has an associated Calculation
Period. This leg is typically used to represent a part of a Total Return Swap (TRS) on
an Equity Index Future. The full TRS on the Equity Index Future uses TradeType
Swap, and one leg of type Equity, and the other leg of type EquityMargin. Note that
the equity identifier on both legs (the Name field) should be for the Equity Index, and
not the Future.
The outline of a equity margin leg is given in listing 488. It has the usual LegData
elements described in section 8.3.3 and a EquityMarginLegData node that is described
in section 8.3.26 below.

8.3.26 Equity Margin Leg Data

The EquityMarginLegData node outline is shown in listing 488. The meaning and
allowable values for each node are as follows:
• Rates: The fixed real rate(s) of the leg. While this can be a single value, a vector
of values or a dated vector of values. Allowable values: Each rate element can
take any real number. The rate is expressed in decimal form, e.g. 0.05 is a rate
of 5%..
• InitialMarginFactor: this node is used to specify the equity margin factor for
the first period of the trade. It’s a percentage that reflecting the current

694
 applicable official Exchange initial margin requirement. It is expressed in decimal
form, e.g. 0.05 is a rate of 5%..
• EquityLegData: this node is used to specify the underlying equity details. It’s
values are as outlined in section 8.3.16.
• Multiplier [Optional]: in some cases, the cashflow amounts are multiplied by a
fixed amount. Defaults to 1.

8.3.27 CDS Reference Information

This trade component can be used to define the reference entity, tier, currency and
documentation clause in credit derivative trades. For example, it can be used in the
CreditDefaultSwapData section in a CDS trade and in the BasketData section in
credit derivatives involving more than one underlying reference entity. The value for
each of these fields is generally agreed and specified in the credit derivative contract
and they determine the credit curve that is used in pricing the trade.

Listing 490: CDS reference information node

<ReferenceInformation>
<ReferenceEntityId>...</ReferenceEntityId>
<Tier>...</Tier>
<Currency>...</Currency>
<DocClause>...</DocClause>
</ReferenceInformation>

The meanings and allowable values of the elements in the ReferenceInformation

node are as follows:
• ReferenceEntityId: This is typically a six digit Markit RED code specifying
the underlying reference entity with the prefix RED: e.g. RED:008CA0.
• Tier: The debt tier that is applicable for the specified reference entity in the
credit derivative. Table 43 provides the allowable values.
• Currency: The currency that is applicable for the specified reference entity in
the credit derivative. Table 32 provides the allowable values.
• DocClause: The documentation clause that is applicable for the specified
reference entity in the credit derivative. This defines what constitutes a credit
event for the contract as well as any limitations on the deliverable debt in the
event of a credit event. Table 44 provides the allowable values.

8.3.28 Basket Data

This trade component node is used in credit derivative trades referencing more than
one reference entity e.g. in the IndexCreditDefaultSwapData node of an index CDS
trade. It contains Name sub-nodes with the details of each constituent reference entities
(names) of the basket. An example structure of the BasketData trade component node
is shown in Listing 491.

695
Listing 491: Basket data

<BasketData>
<Name>
<IssuerId>CPTY_1</IssuerId>
<CreditCurveId>RED:...</CreditCurveId>
<Notional>100000.0</Notional>
<Currency>USD</Currency>
</Name>
<Name>
<IssuerId>CPTY_2</IssuerId>
<CreditCurveId>RED:...</CreditCurveId>
<Notional>100000.0</Notional>
<Currency>USD</Currency>
</Name>
<Name>
<IssuerId>CPTY_3</IssuerId>
<CreditCurveId>RED:...</CreditCurveId>
<Notional>100000.0</Notional>
<Currency>USD</Currency>
</Name>
...
</BasketData>

The meanings and allowable values of the elements in each Name sub-node of the
BasketData node follow below.
• IssuerId: A unique identifier for the index component reference entity. For
informational purposes and not used for pricing.
Allowable values: Any alphanumeric string.
• CreditCurveId: The unique identifier of the index component defining one of the
default curves used for pricing. The pricing can be set up to either use the curve
identifiers of the index components, or one single index curve id defined in the
trade specific data. A ReferenceInformation node may be used in place of this
CreditCurveId node.
Allowable values: See CreditCurveId for credit trades - single name in Table 40.
Duplicate CreditCurveId:s are not allowed.
• ReferenceInformation: This node may be used as an alternative to the
CreditCurveId node to specify the reference entity, tier, currency and
documentation clause for the basket constituent. This in turn defines the credit
curve used for this basket constituent in the pricing. The
ReferenceInformation node is described in further detail in Section 8.3.27.
• Notional: The notional of the index component reference entity. Note that the
sum of index component notionals (all names) must match the fixed premium leg
notional. Allowable values: Any positive real number.
• Weight: Can be used, instead of Notional, to specify the weight of the index
component reference entity. Note that the sum of index component notionals (all
names) must match 1. Allowable values: Any positive real number.

696
 • Currency: Defines the currency of the component, only mandatory together with
a given notional.

8.3.29 Underlying
This trade component can be used to define the underlying entity for an Equity,
Commodity or FX trade, but it can also define an underlying interest rate, inflation
index, credit name or an underlying bond. It can be used for a single underlying, or
within a basket with associated weight. For an equity underlying a string
representation is used to match Underlying node to required configuration and
reference data. The string representation is of the form
IdentifierType:Name:Currency:Exchange, with all entries optional except for Name.

Listing 492: Underlying node

<Underlying>
<Type>...</Type>
<Name>...</Name>
<Weight>...</Weight>
<Currency>...</Currency>
<IdentifierType>...</IdentifierType>
<Exchange>...</Exchange>
<PriceType>...</PriceType>
<FutureMonthOffset>...</FutureMonthOffset>
<DeliveryRollDays>...</DeliveryRollDays>
<DeliveryRollCalendar>...</DeliveryRollCalendar>
</Underlying>

Example structures of the Underlying trade component node are shown in Listings
493 and 494 for an equity underlying, in Listing 497 for an fx underlying, in Listing
498 for a commodity underlying, in Listing 499 for an underlying interest rate index, in
Listing 500 for an underlying inflation index, in Listing 501 for an underlying credit
name, in listing 502 for an underlying bond.

Listing 493: Equity Underlying - RIC

<Underlying>
<Type>Equity</Type>
<Name>.SPX</Name>
<Weight>1.0</Weight>
<IdentifierType>RIC</IdentifierType>
</Underlying>

697
Listing 494: Equity Underlying - ISIN

<Underlying>
<Type>Equity</Type>
<Name>NL0000852580</Name>
<Weight>1.0</Weight>
<IdentifierType>ISIN</IdentifierType>
<Currency>EUR</Currency>
<Exchange>XAMS</Exchange>
</Underlying>

Listing 495: Equity Underlying - FIGI

<Underlying>
<Type>Equity</Type>
<Name>BBG000BLNNV0</Name>
<IdentifierType>FIGI</IdentifierType>
</Underlying>

Listing 496: Equity Underlying - Bloomberg Identifier (Parsekey)

<Underlying>
<Type>Equity</Type>
<Name>BARC LN Equity</Name>
<IdentifierType>BBG</IdentifierType>
</Underlying>

Listing 497: FX Underlying

<Underlying>
<Type>FX</Type>
<Name>ECB-EUR-USD</Name>
<Weight>1.0</Weight>
</Underlying>

Listing 498: Commodity Underlying

<Underlying>
<Type>Commodity</Type>
<Name>NYMEX:CL</Name>
<Weight>1.0</Weight>
<PriceType>FutureSettlement</PriceType>
<FutureMonthOffset>0</FutureMonthOffset>
<DeliveryRollDays>0</DeliveryRollDays>
<DeliveryRollCalendar>TARGET</DeliveryRollCalendar>
<FutureContractMonth>Nov2023</FutureContractMonth>
</Underlying>

698
Listing 499: InterestRate Underlying

<Underlying>
<Type>InterestRate</Type>
<Name>USD-CMS-10Y</Name>
<Weight>1.0</Weight>
</Underlying>

Listing 500: Inflation Index Underlying

<Underlying>
<Type>Inflation</Type>
<Name>USCPI</Name>
<Weight>1.0</Weight>
<!-- optional -->
<Interpolation>Linear</Interpolation>
</Underlying>

Listing 501: Credit Underlying

<Underlying>
<Type>Credit</Type>
<Name>ISSUER_A</Name>
<Weight>1.0</Weight>
</Underlying>

Listing 502: Bond Underlying

<Underlying>
<Type>Bond</Type>
<Name>US69007TAB08</Name>
<IdentifierType>ISIN</IdentifierType>
<Weight>0.5</Weight>
<BidAskAdjustment>-0.0025</BidAskAdjustment>
</Underlying>

The meanings and allowable values of the elements in the Underlying node are as
follows:
• Type: The type of the Underlying asset.
Allowable values: Equity, FX, Commodity, InterestRate, Inflation, Credit, Bond
• Name: The name of the Underlying asset.
Allowable values:
Equity: See Name for equity trades in Table 41
FX : A string on the form SOURCE-CCY1-CCY2, where SOURCE is the FX
fixing source, and the fixing is expressed as amount in CCY2 per one unit of

699
 CCY1. See Table 38, and note that the FX- prefix is not included in Name as it is
already included in Type.
InterestRate: Any valid interest rate index name, see Table 36
Inflation: Any valid zero coupon inflation index (CPI) name, See Table 39
Credit: Any valid credit name with a configured default curve, see Table 40
Bond : Any valid bond identifier, the bond must be set up in the reference data.
Commodity: An identifier specifying the commodity being referenced in the leg.
Table 42 lists the allowable values for Name and gives a description.
• Weight [Optional]: The relative weight of the underlying if part of a basket. For
a single underlying this can be omitted or set to 1.
Allowable values: A real number. Defaults to 1 if left blank or omitted.
Notes on negative weights in the TotalReturnSwap trade type:
Negative weights for EquityOptionPositions are allowed, but not recommended.
A negative weight for an EquityOptionPosition is equivalent to inverting the
LongShort flag in the respective OptionData node.
For EquityPositions a negative weight means that flows are in the opposite
direction of the Payer flag on the return leg. A use case for negative weights is
for a basket of EquityPositions that include both long and short positions.
• IdentifierType [Optional]: Only valid when Type is Equity or Bond. The type
of the identifier being used.
Allowable values: RIC, ISIN, FIGI, BBG. Defaults to RIC, if left blank or
omitted, and Type: is Equity.
• Currency [Mandatory when IdentifierType is ISIN ]: Only valid when Type is
Equity. The currency the underlying equity is quoted in. Used when
IdentifierType is ISIN, to - together with the Exchange convert a given ISIN
to a RIC code.
Allowable values: See Table 32 Currency. Mandatory when IdentifierType is
ISIN, and should not be used for other IdentifierType:s When Type is Equity,
Minor Currencies in Table 32 are also allowable.
• Exchange [Mandatory when IdentifierType is ISIN ]: Only valid when Type is
Equity. A string code representing the exchange the equity is traded on. Used
when IdentifierType is ISIN, to - together with the Currency convert a given
ISIN to a RIC code.
Allowable values: The MIC code of the exchange, see Table 45. Mandatory when
IdentifierType is ISIN, and should not be used for other IdentifierType:s.
• PriceType [Optional]: Only valid when Type is Commodity. Whether the Spot
or Future price is referenced.
Allowable values: Spot, FutureSettlement. Mandatory when Type is Commodity .
• FutureMonthOffset [Optional]: Only valid when Type is Commodity. Only
relevant for the FutureSettlement price type, in which case the N + 1th future

700
 with expiry greater than ObservationDate for the given commodity underlying
will be referenced.
Allowable values: An integer. Mandatory for when Type is Commodity and
PriceType is FutureSettlement.
• DeliveryRollDays [Optional]: Only valid when Type is Commodity. The
number of days the observation date is rolled forward before the next future
expiry is looked up.
Allowable values: An integer. Defaults to 0 if left blank or omitted, and Type: is
Commodity.
• DeliveryRollCalendar [Optional]: Only valid when Type is Commodity. The
calendar used to roll forward the observation date.
Allowable values: See Table 34. Defaults to the null calendar if left blank or
omitted, and Type: is Commodity.
• FutureContractMonth [Optional]: Only valid when Type is Commodity,
PriceType is FutureSettlement and there is no FutureExpiryDate node. It
specifies the underlying future contract month in the format MonYYYY, for
example Nov2023.
• FutureExpiryDate [Optional]: Only valid when Type is Commodity, PriceType
is FutureSettlement and there is no FutureContractMonth node. This gives the
expiration date of the underlying commodity future contract.
If the field FutureExpiryDate and FutureContractMonth are omitted, the
expiration date of the underlying commodity future contract is set to the prompt
future, adjusted for any FutureMonthOffset.
• Interpolation [Optional]: Only valid when Type is Inflation. The index
observation interpolation between fixings.
Allowable values: Flat, Linear
• BidAskAdjustment [Optional]: Only valid when Type is Bond. A correction
applied to the price found in the market data (usually mid), if the bond basket
price is defined on the bid or ask side rather than mid.
Allowable values: Any real number.

8.3.30 StrikeData
This trade component that can be used to define the strike entity for commodity,
equity and bond options. It can be used to define either a Price or Yield strike, with
examples below in 503 and 504 respectively.

701
Listing 503: Strike Price

<StrikeData>
<StrikePrice>
<Value>1</Value>
<Currency>EUR</Currency>
</StrikePrice>
</StrikeData>

The meanings and allowable values of the elements in the StrikePrice node are as
follows:
• Value: The strike price.
Allowable values: Any positive real number.
• Currency [Mandatory for Quanto/Compo, Optional otherwise]: The currency of
the amount given in Value, i.e. the strike currency.
Note:
Quanto: The payment/leg currency and the currency the underlying asset is
quoted in differ. The strike currency is in the currency the asset is quoted in.
Compo (Composite): The payment/leg currency and the currency the underlying
asset is quoted in differ. The strike currency is in the payment/leg currency.
Allowable values: See Table 32 Currency. Minor Currencies in Table 32 are also
allowable. In non-quanto/compo cases, if left blank or omitted, it defaults to the
currency of the leg for equity and commodity options, and to the currency the
underlying bond is quoted in for BondOptions using reference data.

Listing 504: Strike Yield

<StrikeData>
<StrikeYield>
<Yield>0.055</Yield>
<Compounding>SimpleThenCompounded</Compounding>
</StrikeYield>
</StrikeData>

The meanings and allowable values of the elements in the StrikeYield node are as
follows:
• Yield: A Yield quoted in decimal form, e.g. 10% should be entered as 0.1.
Allowable values: Any real number.
• Compounding [Optional]: The compounding or the yield given in Yield.
Allowable values: Simple, Compounded, Continuous, SimpleThenCompounded.
Defaults to SimpleThenCompounded if left blank or omitted.

702
 Trade Data Container Supported Barrier Styles
FxBarrierOptionData American
FxDigitalBarrierOptionData American
FxEuropeanBarrierOptionData European
FxTouchOptionData American
FxDoubleTouchOptionData American
FxDoubleBarrierOptionData American
FxKIKOBarrierOptionData American
FxTaRFData European
FxAccumulatorData European, American
EquityTaRFData European
EquityAccumulatorData European, American
CommodityAccumulatorData European, American
FxGenericBarrierOption American
EquityGenericBarrierOption American
CommodityGenericBarrierOption American
Table 28: Supported barrier styles per trade data container

8.3.31 Barrier Data

This trade component node is used within the trade data containers listed in table 28.
Note that not every trade type allows for all barrier styles, the allowable combinations
are listed in in table 28.
The barrier data element is specified as in listing 505

Listing 505: Barrier data

<BarrierData>
<Type>UpAndIn</Type>
<Style>American</Style>
<Levels>
<Level>1.2</Level>
</Levels>
<Rebate>100000</Rebate>
<RebateCurrency>USD</RebateCurrency>
<RebatePayTime>atExpiry</RebatePayTime>
</BarrierData>

The meanings and allowable values of the elements in the BarrierData node follow
below.
• Type: Specifies barrier type. The allowable values are given in Table 29.

703
Type Description
UpAndOut The underlying price starts below the barrier level and has to move
up for the option to be knocked out.
DownAndOut The underlying price starts above the barrier level and has to move
down for the option to become knocked out.
UpAndIn The underlying price starts below the barrier level and has to move
up for the option to become activated.
DownAndIn The underlying price starts above the barrier level and has to move
down for the option to become activated.
KnockOut For double level only. The underlying price starts between the
barrier levels and has to move up or down for the option to be
knocked out.
KnockIn For double level only. The underlying price starts between the
barrier levels and has to move up or down for the option to become
activated.
CumulatedProfitCap For TaRFs only. The instrument terminates once the generated
profit reaches the CumulatedProfitCap.
CumulatedProfitCapPoints For TaRFs only. The instrument terminates once the generated
profit divided by fixing amount and absolute value of leverage
reaches the CumulatedProfitCapPoints.
FixingCap For TaRFs only. The instrument terminates once the number of
observations where a profit is generated reaches the FixingCap.
FixingFloor For Accumulators only. The first n fixings are guaranteed regardless
of whether the trade has been knocked out already.

Table 29: Allowable Type Values.

• Style[Optional]: Specifies the monitoring style of the barrier. Optional, if not

given, defaults to the supported barrier style (see table 28 and if both American
and European barriers are supported, defaults to American.
Allowable values: American, European.
• Level: The barrier level, defined as the amount in sold (domestic) currency per
unit bought (foreign) currency. Double barrier instruments can have two Level
elements, and these must be in ascending order.
Allowable values: Any positive real number.
• Rebate[Optional]: The barrier rebate is a fixed amount, expressed in domestic /
sold currency paid out to the option holder if a barrier option expires inactive,
i.e. it is not knocked in/out. Note that Rebate is supported for
– FxBarrierOptionData
– FxDigitalBarrierOptionData
– FxDoubleBarrierOptionData
– FxEuropeanBarrierOptionData
– FxGenericBarrierOptionData
– EquityGenericBarrierOptionData

704
 – CommodityGenericBarrierOptionData
only. If defined for several “in” barriers, the amounts must be identical across all
barrier definitions (because the rebate amount is paid if none of the “in” barrier is
touched and can therefore not depend on the particular barrier). Also, the
RebatePayTime must be atExpiry for “in” barriers obviously.
Allowable values: Any positive real number. Defaults to zero if omitted. Cannot
be left blank.
• RebateCurrency [Optional]: The currency in which the rebate amount is paid.
Defaults to the natural pay currency of the trade. Deviating currencies are
supported by the following trade types only:
– FxGenericBarrierOptionData
– EquityGenericBarrierOptionData
– CommodityGenericBarrierOptionData
Allowable Values: See Table 32 Currency.
• RebatePayTime [Optional]: For “in” barriers only atExpiry is allowed. For “out”
barriers, both atExpiry and atHit is possible. If not given, defaults to “atExpiry”.
This field is only supported by the following trade types:
– FxGenericBarrierOptionData
– EquityGenericBarrierOptionData
– CommodityGenericBarrierOptionData
Allowable Values: atExpiry, atHit

8.3.32 RangeBound
This trade component node is used within the following trade data containers
• FxTaRFfData, EquityTaRFData, CommodityTaRFData
• FxAccumulatorData, EquityAccumulatorData, CommodityAccumulatorData
An example structure of the RangeBound trade component node is shown in Listing
506.

Listing 506: RangeBound

<RangeBound>
<RangeFrom>0</RangeFrom>
<RangeTo>155.00</RangeTo>
<Leverage>2</Leverage>
<Strike>150.54</Strike>
</RangeBound>

The meanings and allowable values of the elements in the RangeBound node follow
below.

705
 • RangeFrom [Optional]: The lower bound of the range.
Allowable values: Any real number. If omitted, no lower bound applies. Cannot
be left blank.
• RangeTo [Optional]: The upper bound of the range.
Allowable values: Any real number. If omitted, no lower bound applies. Cannot
be left blank.
• Leverage [Optional]: The leverage that applies to the range. For TaRFs, negative
leverage can be mixed with positive leverage to reflect a TaRF with switching
buyer/seller. However, for Accumulators all given Leverage parameters within
the same instrument (in multiple RangeBound nodes) must have the same sign.
Allowable values: Any real number. Defaults to 1 if omitted. Cannot be left
blank.
• Strike [Optional]: The strike specific to the range. If given overwrites a strike
given on the trade level.
Allowable values: Any real number. Defaults to the trade level strike if omitted.
Cannot be left blank.
• StrikeAdjustment [Optional]: A strike adjustment relative to the strike given on
the trade level. If given the strike for the defined range is computed as K + A
where K is the strike on the trade level and A is the strike adjustment. Notice
that Strike and StrikeAdjustment can not be given both at the same time.
Allowable values: Any real number.

8.3.33 Bond Basket Data for Cashflow CDO

This trade component node is used in a Cashflow CDO trade as explained in 8.2.49.
An example structure of the BondBasketData trade component node is shown in
Listing 507.

706
Listing 507: Bond Basket Data for Cashflow CDO

<BondBasketData>
<Trade id="Bond_1">
<TradeType>Bond</TradeType>
<Envelope>
...
</Envelope>
<BondData>
...
</BondData>
</Trade>
<Trade id="Bond_2">
<TradeType>Bond</TradeType>
<Envelope>
...
</Envelope>
<BondData>
...
</BondData>
</Trade>
</BondBasketData>

The usage of the BondBasketData is akin to a portfolio of bond trades, but is

embraced by the keyword BondBasketData as opposed to Portfolio. Compare the
vanilla bond section 8.2.39 for usage and allowable values.

8.3.34 CBO Tranches

This trade component node is used in a CBO trade as explained in 8.2.49. An example
structure of the CBOTranches trade component node is shown in Listing 508.

Listing 508: CBO Tranches

<CBOTranches>
<Tranche>
<Name>JuniorNote</Name>
<ICRatio>0.0</ICRatio>
<OCRatio>0.0</OCRatio>
<Notional>4000000.00</Notional>
<FixedLegData>
<Rates>
<Rate>0.03</Rate>
</Rates>
</FixedLegData>
</Tranche>
...
</CBOTranches>

The meanings of the elements of the CBO tranches node follow below:
• Tranche: Multiple tranches are allowed and are indicated by the tranche node
within the embracing CBOTranches node.

707
 • Name: This string is the name of the tranche, possibly reflecting the position in
the capital structure.
• ICRatio: The interest coverage ratio is a number, defined as BasketInterest over
TrancheInterest (incl. all senior tranches).
• OCRatio: The overcollateralisation ratio is a number, defined as BasketNotional
over TrancheNotional (incl. all senior tranches).
• Notional: The face amount of the tranche.
Depending on the tranche, one can specify a floating or fixed return via the nodes:
• FixedLegData, which is outlined in section 8.3.5.
• FloatingLegData, which is outlined in section 8.3.6.

8.3.35 Formula Based Leg Data

The formula based leg data allows to use complex formulas to describe coupon payoffs.
Its LegType is FormulaBased, and it has the data section FormulaBasedLegData. It
supports IBOR and CMS based payoffs with quanto and digital features. The
following example shows the definition of a coupon paying a capped / floored cross
currency EUR-GBP CMS Spread contingent on a USD CMS barrier.
The Index field supports operations of the following kind:
• indices like IBOR and CMS indices, and constants as factors, spreads and/or
cap/floor values;
• basic operations: +, −, ·, /;
• operators gtZero() (greater than zero) and geqZero() (greater than or equal zero)
yielding 1 if the argument is > 0 (resp. ≥ 0) and zero otherwise
• functions: abs(), exp(), log(), min(), max(), pow()
In listing 509, we present a FormulaBasedLegData example.
This leg data type can be used in Swap and Bond trades.

708
Listing 408: Payoff script for a Worst Of Basket Swap.

REQUIRE SIZE(Underlyings) == SIZE(InitialPrices);

REQUIRE SIZE(SettlementDates) == SIZE(DeterminationDates);
REQUIRE SIZE(KnockOutLevels) == SIZE(DeterminationDates) - 1;
REQUIRE SIZE(CouponTriggerLevels) == SIZE(DeterminationDates) - 1;

NUMBER alive, couponAccumulation, numOfKnockedAssets, fixing, n, accrualFraction, indexInitial;

NUMBER numOfTriggeredAssets, indexFinal, performance, worstPerformance, d, payoff, u;

Option = Option + LOGPAY(LongShort * Quantity * InitialFixedRate,

SettlementDates[1], SettlementDates[1], PayCcy, 0, InitialFixedAmount);

alive = 1;
couponAccumulation = 1;
n = SIZE(DeterminationDates);

FOR d IN (2, n, 1) DO
fixing = FloatingIndex(FixingSchedule[d-1]) + FloatingSpread;
accrualFraction = dcf(FloatingDayCountFraction, DeterminationDates[d-1], DeterminationDates[d]);
Option = Option - LOGPAY(LongShort * Quantity * alive * fixing * accrualFraction,
FixingSchedule[d-1], SettlementDates[d], PayCcy, 1, FloatingLeg);

numOfTriggeredAssets = 0;
FOR u IN (1, SIZE(Underlyings), 1) DO
IF Underlyings[u](DeterminationDates[d]) >= CouponTriggerLevels[d-1] * InitialPrices[u] THEN
numOfTriggeredAssets = numOfTriggeredAssets + 1;
END;
END;
IF numOfTriggeredAssets == SIZE(Underlyings) THEN
Option = Option + LOGPAY(LongShort * Quantity * alive * CouponRate * couponAccumulation,
SettlementDates[d], SettlementDates[d], PayCcy, 2, FixedCouponLeg);
couponAccumulation = 1;
ELSE
IF AccumulatingCoupons == 1 THEN
couponAccumulation = couponAccumulation + 1;
END;
END;

IF d == n THEN
FOR u IN (1, SIZE(Underlyings), 1) DO
indexInitial = InitialPrices[u];
indexFinal = Underlyings[u](DeterminationDates[n]);
performance = indexFinal / indexInitial;

IF {u == 1} OR {performance < worstPerformance} THEN

worstPerformance = performance;
END;
END;

IF worstPerformance < min(Strike, KnockInLevel) THEN

payoff = worstPerformance - Strike;
Option = Option + LOGPAY(LongShort * Quantity * alive * payoff, DeterminationDates[n],
SettlementDates[n], PayCcy, 3, EquityAmountPayoff);
END;
END;

IF d != n THEN
numOfKnockedAssets = 0;
FOR u IN (1, SIZE(Underlyings), 1) DO
IF Underlyings[u](DeterminationDates[d]) >= KnockOutLevels[d-1] * InitialPrices[u] THEN
numOfKnockedAssets = numOfKnockedAssets + 1;
END;
END;
IF numOfKnockedAssets == SIZE(Underlyings) THEN
alive = 0;
END;
END;
END;

Listing 409: Payoff script for a BestOfAssetOrCashRainbowOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

NUMBER u, thisPrice, bestPrice, Payoff, currentNotional;
bestPrice = Strike;
FOR u IN (1, SIZE(Underlyings)) DO
thisPrice = Underlyings[u](Expiry) * Weights[u];
IF thisPrice > bestPrice THEN
bestPrice = thisPrice;
END;
END;
Option = LongShort * Notional * PAY(bestPrice, Expiry, Settlement, PayCcy);
currentNotional = Notional * Strike;

709
Listing 410: Payoff script for a WorstOfAssetOrCashRainbowOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

NUMBER u, thisPrice, worstPrice, Payoff, currentNotional;
worstPrice = Strike;
FOR u IN (1, SIZE(Underlyings)) DO
thisPrice = Underlyings[u](Expiry) * Weights[u];
IF thisPrice < worstPrice THEN
worstPrice = thisPrice;
END;
END;
Option = LongShort * Notional * PAY(worstPrice, Expiry, Settlement, PayCcy);
currentNotional = Notional * Strike;

Listing 411: Payoff script for a MaxRainbowOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

NUMBER u, thisPrice, maxPrice, Payoff, ExerciseProbability, currentNotional;

maxPrice = 0;
FOR u IN (1, SIZE(Underlyings)) DO
thisPrice = Underlyings[u](Expiry) * Weights[u];
IF thisPrice > maxPrice THEN
maxPrice = thisPrice;
END;
END;

Payoff = max(PutCall * (maxPrice - Strike), 0);

Option = LongShort * Notional * PAY(Payoff, Expiry, Settlement, PayCcy);

IF Payoff > 0 THEN

ExerciseProbability = 1;
END;
currentNotional = Notional * Strike;

Listing 412: Payoff script for a MinRainbowOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

REQUIRE SIZE(Underlyings) > 0;

NUMBER u, thisPrice, minPrice, Payoff, ExerciseProbability, currentNotional;

minPrice = Underlyings[1](Expiry) * Weights[1];
FOR u IN (1, SIZE(Underlyings)) DO
thisPrice = Underlyings[u](Expiry) * Weights[u];
IF thisPrice < minPrice THEN
minPrice = thisPrice;
END;
END;

Payoff = max(PutCall * (minPrice - Strike), 0);

Option = LongShort * Notional * PAY(Payoff, Expiry, Settlement, PayCcy);

IF Payoff > 0 THEN

ExerciseProbability = 1;
END;
currentNotional = Notional * Strike;

710
Listing 413: Payoff script for a EuropeanRainbowCallSpreadOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

NUMBER perf[SIZE(Underlyings)], return, u;
FOR u IN (1, SIZE(Underlyings)) DO
perf[u] = Underlyings[u](Expiry) / InitialStrikes[u];
END;
SORT (perf);
FOR u IN (1, SIZE(Underlyings)) DO
return = return + Weights[u] * perf[SIZE(Underlyings) + 1 - u];
END;
Option = PAY( Notional * min( max( Floor, return - 1 ), Cap ), Expiry,
Settlement, PayCcy );

Listing 414: Payoff script for a RainbowCallSpreadBarrierOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

REQUIRE Floor <= Cap;
NUMBER performance, perf[SIZE(Underlyings)], return, u, d, payoff, knockedIn;

FOR u IN (1, SIZE(Underlyings), 1) DO

perf[u] = Underlyings[u](Expiry) / InitialPrices[u];
END;
SORT (perf);

FOR u IN (1, SIZE(Underlyings), 1) DO

return = return + Weights[u] * perf[SIZE(Underlyings) + 1 - u];
END;

IF BermudanBarrier == 1 THEN
FOR d IN (1, SIZE(BarrierSchedule), 1) DO
IF knockedIn == 0 THEN
FOR u IN (1, SIZE(Underlyings), 1) DO
performance = Underlyings[u](BarrierSchedule[d]) / InitialPrices[u];
IF performance <= BarrierLevel THEN
knockedIn = 1;
END;
END;
END;
END;
ELSE
FOR u IN (1, SIZE(perf), 1) DO
IF perf[u] <= BarrierLevel THEN
knockedIn = 1;
END;
END;
END;

payoff = min( max( Floor, return - Strike ), Cap );

Option = LongShort * PAY(Notional * Gearing * payoff * knockedIn,
Expiry, Settlement, PayCcy);

Listing 415: Payoff script for a AsianRainbowCallSpreadOption.

REQUIRE SIZE(Underlyings) == SIZE(Weights);

NUMBER perf[SIZE(Underlyings)], return, d, u;
FOR u IN (1, SIZE(Underlyings), 1) DO
FOR d IN (1, SIZE(AveragingDates), 1) DO
perf[u] = perf[u] + Underlyings[u](AveragingDates[d]);
END;
perf[u] = perf[u] / SIZE(AveragingDates);
END;
SORT (perf);
FOR u IN (1, SIZE(Underlyings), 1) DO
return = return + Weights[u] * perf[SIZE(Underlyings) + 1 - u];
END;
Option = LongShort * PAY( Notional * min( max( Floor, return - 1 ), Cap ), Expiry,
Settlement, PayCcy );

711
Listing 416: Payoff script for a WorstPerformanceRainbowOption01.

REQUIRE SIZE(Underlyings) == SIZE(InitialPrices);

REQUIRE ObservationDate <= SettlementDate;

NUMBER u, indexInitial, indexFinal, performance;

NUMBER worstPerformance, payoff, premium;

FOR u IN (1, SIZE(Underlyings), 1) DO

indexInitial = InitialPrices[u];
indexFinal = Underlyings[u](ObservationDate);
performance = indexFinal / indexInitial;

IF {u == 1} OR {performance < worstPerformance} THEN

worstPerformance = performance;
END;
END;

payoff = LOGPAY(Quantity * (worstPerformance - 1), ObservationDate,

SettlementDate, PayCcy, 1, Payoff);

IF worstPerformance < 1 THEN

payoff = payoff * PayoffMultiplier;
END;

premium = LOGPAY(Premium, PremiumDate, PremiumDate, PayCcy, 0, Premium);

Option = LongShort * (payoff - premium);

Listing 417: Payoff script for a WorstPerformanceRainbowOption02.

REQUIRE SIZE(Underlyings) == SIZE(InitialPrices);

REQUIRE ObservationDate <= SettlementDate;
REQUIRE Floor <= 0;

NUMBER u, initialPrice, finalPrice, performance;

NUMBER worstPerformance, payoff, premium;

FOR u IN (1, SIZE(Underlyings), 1) DO

initialPrice = InitialPrices[u];
finalPrice = Underlyings[u](ObservationDate);
performance = finalPrice / initialPrice;

IF {u == 1} OR {performance < worstPerformance} THEN

worstPerformance = performance;
END;
END;

IF worstPerformance > 1 THEN

payoff = PayoffMultiplier * (worstPerformance - 1);
ELSE
IF worstPerformance < 1 THEN
payoff = max(Floor, worstPerformance - 1);
ELSE
payoff = 0;
END;
END;

payoff = Quantity * LOGPAY(payoff, ObservationDate, SettlementDate,

PayCcy, 1, Payoff);
premium = LOGPAY(Premium, PremiumDate, PremiumDate, PayCcy,
0, Premium);

Option = LongShort * (payoff - premium);

712
Listing 418: Payoff script for a WorstPerformanceRainbowOption03.

REQUIRE SIZE(Underlyings) == SIZE(InitialPrices);

REQUIRE ObservationDate <= SettlementDate;
REQUIRE Floor <= Cap;

NUMBER indexInitial, indexFinal, performance, d;

NUMBER worstPerformance, payoff, premium, knockedIn, u;

FOR u IN (1, SIZE(Underlyings), 1) DO

indexInitial = InitialPrices[u];
indexFinal = Underlyings[u](ObservationDate);
performance = indexFinal / indexInitial;

IF {u == 1} OR {performance < worstPerformance} THEN

worstPerformance = performance;
END;
END;

IF BermudanBarrier == 1 THEN
FOR d IN (1, SIZE(BarrierSchedule), 1) DO
IF knockedIn == 0 THEN
FOR u IN (1, SIZE(Underlyings), 1) DO
indexInitial = InitialPrices[u];
indexFinal = Underlyings[u](BarrierSchedule[d]);
performance = indexFinal / indexInitial;

IF performance <= BarrierLevel THEN

knockedIn = 1;
END;
END;
END;
END;
ELSE
IF worstPerformance <= BarrierLevel THEN
knockedIn = 1;
END;
END;

payoff = min(Cap, max(Floor, worstPerformance - Strike));

payoff = LOGPAY(Quantity * payoff * knockedIn, ObservationDate,
SettlementDate, PayCcy, 1, Payoff);

IF worstPerformance < 1 THEN

payoff = payoff * PayoffMultiplier;
END;

premium = LOGPAY(Premium, PremiumDate, PremiumDate,

PayCcy, 0, Premium);

Option = LongShort * (payoff - premium);

713
Listing 419: Payoff script for a WorstPerformanceRainbowOption04.

REQUIRE SIZE(Underlyings) == SIZE(InitialPrices);

REQUIRE ObservationDate <= SettlementDate;
REQUIRE Floor <= Cap;

NUMBER indexInitial, indexFinal, performance, d;

NUMBER worstPerformance, payoff, premium, knockedIn, u;

FOR u IN (1, SIZE(Underlyings), 1) DO

indexInitial = InitialPrices[u];
indexFinal = Underlyings[u](ObservationDate);
performance = indexFinal / indexInitial;

IF {u == 1} OR {performance < worstPerformance} THEN

worstPerformance = performance;
END;
END;

IF BermudanBarrier == 1 THEN
FOR d IN (1, SIZE(BarrierSchedule), 1) DO
IF knockedIn == 0 THEN
FOR u IN (1, SIZE(Underlyings), 1) DO
indexInitial = InitialPrices[u];
indexFinal = Underlyings[u](BarrierSchedule[d]);
performance = indexFinal / indexInitial;

IF performance <= BarrierLevel THEN

knockedIn = 1;
END;
END;
END;
END;
ELSE
IF worstPerformance <= BarrierLevel THEN
knockedIn = 1;
END;
END;

payoff = worstPerformance - Strike;

IF knockedIn == 0 THEN
payoff = min(Cap, max(Floor, PayoffMultiplier * payoff));
END;

payoff = LOGPAY(Quantity * payoff, ObservationDate,

SettlementDate, PayCcy, 1, Payoff);

premium = LOGPAY(Premium, PremiumDate, PremiumDate,

PayCcy, 0, Premium);

Option = LongShort * (payoff - premium);

714
Listing 420: Payoff script for a WorstPerformanceRainbowOption05.

REQUIRE SIZE(Underlyings) == SIZE(InitialPrices);

REQUIRE ObservationDate <= SettlementDate;
REQUIRE BarrierType == 1 OR BarrierType == 2;

NUMBER indexInitial, indexFinal, performance;

NUMBER worstPerformance, payoff, premium, knockedIn, u;

FOR u IN (1, SIZE(Underlyings), 1) DO

indexInitial = InitialPrices[u];
indexFinal = Underlyings[u](ObservationDate);
performance = indexFinal / indexInitial;

IF {u == 1} OR {performance < worstPerformance} THEN

worstPerformance = performance;
END;
END;

IF {{BarrierType == 1 OR BarrierType == 4}
AND worstPerformance <= BarrierLevel}
OR {{BarrierType == 2 OR BarrierType == 3}
AND worstPerformance >= BarrierLevel} THEN
knockedIn = 1;
END;

IF knockedIn == 0 THEN
payoff = 0;
ELSE
payoff = max(0, PutCall * (worstPerformance - Strike));
END;

payoff = LOGPAY(Quantity * payoff, ObservationDate,

SettlementDate, PayCcy, 1, Payoff);

premium = LOGPAY(Premium, PremiumDate, PremiumDate,

PayCcy, 0, Premium);

Option = LongShort * (payoff - premium);

715
Listing 421: Payoff script for a VarianceOption.

REQUIRE {Notional >= 0} AND {Strike >= 0};

NUMBER expectedN, realisedVariance, currPrice, currentNotional;

NUMBER prevPrice, payoff, realisedVariation, strike, premium, d;

FOR d IN (2, SIZE(ValuationSchedule), 1) DO

currPrice = Underlying(ValuationSchedule[d]);
prevPrice = Underlying(ValuationSchedule[d-1]);
realisedVariance = realisedVariance + pow(ln(currPrice/prevPrice), 2);
END;

expectedN = SIZE(ValuationSchedule) - 1;
realisedVariance = (252/expectedN) * realisedVariance;

IF SquaredPayoff == 1 THEN
realisedVariation = realisedVariance;
currentNotional = pow(100, 2) * Notional / (2 * 100 * VarianceReference);
strike = pow(Strike, 2);
ELSE
realisedVariation = sqrt(realisedVariance);
currentNotional = 100 * Notional;
strike = Strike;
END;

payoff = currentNotional * max(PutCall * (realisedVariation - strike), 0);

NUMBER ExerciseProbability;
IF payoff > 0 THEN
ExerciseProbability = 1;
END;

premium = PAY(PremiumAmount, PremiumDate, SettlementDate, PayCcy);

payoff = PAY(payoff, ValuationSchedule[SIZE(ValuationSchedule)],
SettlementDate, PayCcy);
Option = LongShort * (payoff - premium);

716
Listing 422: Payoff script for a KIKOVarianceSwap.

REQUIRE {Notional >= 0} AND {Strike >= 0};

REQUIRE {Cap >= 0} AND {Floor >= 0};

alive = 1;
FOR d IN (2, SIZE(ValuationSchedule), 1) DO
IF alive == 1 THEN
currPrice = Underlying(ValuationSchedule[d]);
prevPrice = Underlying(ValuationSchedule[d-1]);
realisedVariance = realisedVariance + pow(ln(currPrice/prevPrice), 2);

IF BarrierType == 3 OR BarrierType == 4 THEN

daysBeforeKO = daysBeforeKO + 1;
END;

IF {BarrierType == 3 AND currPrice <= BarrierLevel} OR

{BarrierType == 4 AND currPrice >= BarrierLevel} THEN
alive = 0;
END;

IF knockedIn == 0 THEN
IF {BarrierType == 1 AND currPrice <= BarrierLevel} OR
{BarrierType == 2 AND currPrice >= BarrierLevel} THEN
knockedIn = 1;
END;
END;
END;
END;

expectedN = SIZE(ValuationSchedule) - 1;
realisedVariance = (252/expectedN) * realisedVariance;

IF SquaredPayoff == 1 THEN
realisedVariation = realisedVariance;
currentNotional = pow(100, 2) * Notional / (2 * 100 * Strike);
strike = pow(Strike, 2);
ELSE
realisedVariation = sqrt(realisedVariance);
currentNotional = 100 * Notional;
strike = Strike;
END;

IF Floor > 0 THEN

IF SquaredPayoff == 1 THEN
floor = pow(Floor, 2);
ELSE
floor = Floor;
END;
realisedVariation = max(floor * strike, realisedVariation);
END;
IF Cap > 0 THEN
IF SquaredPayoff == 1 THEN
cap = pow(Cap, 2);
ELSE
cap = Cap;
END;
realisedVariation = min(cap * strike, realisedVariation);
END;

payoff = LongShort * knockedIn * (daysBeforeKO / expectedN) *

currentNotional * (realisedVariation - strike);

Swap = PAY(payoff, ValuationSchedule[SIZE(ValuationSchedule)],

SettlementDate, PayCcy);

717
Listing 423: Payoff script for a CorridorVarianceSwap.

REQUIRE {Notional >= 0} AND {Strike >= 0};

REQUIRE UpperBarrierLevel >= LowerBarrierLevel;

FOR d IN (2, SIZE(ValuationSchedule), 1) DO

currPrice = Underlying(ValuationSchedule[d]);
prevPrice = Underlying(ValuationSchedule[d-1]);

IF {CountBothObservations == 1 AND
currPrice >= LowerBarrierLevel AND currPrice <= UpperBarrierLevel AND
prevPrice >= LowerBarrierLevel AND prevPrice <= UpperBarrierLevel} OR
{CountBothObservations == -1 AND
prevPrice >= LowerBarrierLevel AND prevPrice <= UpperBarrierLevel} THEN
realisedVariance = realisedVariance + pow(ln(currPrice/prevPrice), 2);
accruedDays = accruedDays + 1;
END;
END;

expectedN = SIZE(ValuationSchedule) - 1;
realisedVariance = (252/expectedN) * realisedVariance;

IF AccrualAdjustment == -1 THEN
accruedDays = expectedN;
END;

IF SquaredPayoff == 1 THEN
realisedVariation = realisedVariance;
currentNotional = pow(100, 2) * Notional / (2 * 100 * Strike);
strike = pow(Strike, 2);
adjustedStrike = (accruedDays / expectedN) * strike;
ELSE
realisedVariation = sqrt(realisedVariance);
currentNotional = 100 * Notional;
strike = Strike;
adjustedStrike = sqrt(accruedDays/expectedN) * strike;
END;

IF Floor > 0 THEN

IF SquaredPayoff == 1 THEN
floor = pow(Floor, 2);
ELSE
floor = Floor;
END;
realisedVariation = max(floor * adjustedStrike, realisedVariation);
END;
IF Cap > 0 THEN
IF SquaredPayoff == 1 THEN
cap = pow(Cap, 2);
ELSE
cap = Cap;
END;
realisedVariation = min(cap * adjustedStrike, realisedVariation);
END;

payoff = LongShort * currentNotional * (realisedVariation - adjustedStrike);

Swap = PAY(payoff, ValuationSchedule[SIZE(ValuationSchedule)],

SettlementDate, PayCcy);

718
Listing 424: Payoff script for a KIKOCorridorVarianceSwap.

REQUIRE {Notional >= 0} AND {Strike >= 0} AND {KIKOBarrierLevel > 0};
REQUIRE CorridorUpperBarrierLevel >= CorridorLowerBarrierLevel;

n = SIZE(ValuationSchedule);

alive = 1;
FOR d IN (2, n, 1) DO
currPrice = Underlying(ValuationSchedule[d]);
prevPrice = Underlying(ValuationSchedule[d-1]);

IF alive == 1 THEN
IF {CountBothObservations == 1 AND
currPrice >= CorridorLowerBarrierLevel AND currPrice <= CorridorUpperBarrierLevel AND
prevPrice >= CorridorLowerBarrierLevel AND prevPrice <= CorridorUpperBarrierLevel} OR
{CountBothObservations == -1 AND
prevPrice >= CorridorLowerBarrierLevel AND prevPrice <= CorridorUpperBarrierLevel} THEN
realisedVariance = realisedVariance + pow(ln(currPrice/prevPrice), 2);
accruedDays = accruedDays + 1;
END;

IF {KIKOBarrierType == 3 AND currPrice <= KIKOBarrierLevel} OR

{KIKOBarrierType == 4 AND currPrice >= KIKOBarrierLevel} THEN
alive = 0;
END;
END;

IF knockedIn == 0 THEN
IF {KIKOBarrierType == 1 AND currPrice <= KIKOBarrierLevel} OR
{KIKOBarrierType == 2 AND currPrice >= KIKOBarrierLevel} THEN
knockedIn = 1;
END;
END;

IF {alive == 0 OR d == n} AND {calculated == 0} THEN

calculated = 1;
expectedN = n - 1;
realisedVariance = (252/expectedN) * realisedVariance;

IF AccrualAdjustment == -1 THEN
accruedDays = expectedN;
END;

currentNotional = pow(100, 2) * Notional / (2 * 100 * Strike);

strike = pow(Strike, 2);
adjustedStrike = (accruedDays / expectedN) * strike;

IF Floor > 0 THEN

floor = pow(Floor, 2);
realisedVariance = max(floor * adjustedStrike, realisedVariance);
END;
IF Cap > 0 THEN
cap = pow(Cap, 2);
realisedVariance = min(cap * adjustedStrike, realisedVariance);
END;

IF {{KIKOBarrierType == 1 OR KIKOBarrierType == 2} AND {knockedIn == 1}} OR

{{KIKOBarrierType == 3 OR KIKOBarrierType == 4} AND {alive == 0}} THEN
TriggerProbability = 1;
END;

IF KIKOBarrierType == 3 OR KIKOBarrierType == 4 THEN

knockedIn = 1;
END;

payoff = LongShort * knockedIn * currentNotional

* (realisedVariance - adjustedStrike);

Swap = LOGPAY(payoff, ValuationSchedule[d], SettlementSchedule[d], PayCcy);

END;
END;

719
Listing 425: Payoff script for a ConditionalVarianceSwap01.

REQUIRE {Notional >= 0} AND {Strike > 0};

FOR d IN (2, SIZE(ValuationSchedule), 1) DO

currPrice = Underlying(ValuationSchedule[d]);
prevPrice = Underlying(ValuationSchedule[d-1]);

IF {CountBothObservations == 1 AND {
{{BarrierType == 1 OR BarrierType == 4} AND
currPrice <= BarrierLevel AND prevPrice <= BarrierLevel} OR
{{BarrierType == 2 OR BarrierType == 3} AND
currPrice >= BarrierLevel AND prevPrice >= BarrierLevel}}}
OR {CountBothObservations == -1 AND {
{{BarrierType == 1 OR BarrierType == 4} AND
prevPrice <= BarrierLevel} OR
{{BarrierType == 2 OR BarrierType == 3} AND
prevPrice <= BarrierLevel} }}
THEN
realisedVariance = realisedVariance + pow(ln(currPrice/prevPrice), 2);
accruedDays = accruedDays + 1;
END;
END;

expectedN = SIZE(ValuationSchedule) - 1;
realisedVariance = (252/expectedN) * realisedVariance;

IF AccrualAdjustment == -1 THEN
accruedDays = expectedN;
END;

IF SquaredPayoff == 1 THEN
realisedVariation = realisedVariance;
currentNotional = pow(100, 2) * Notional / (2 * 100 * Strike);
strike = pow(Strike, 2);
adjustedStrike = (accruedDays / expectedN) * strike;
ELSE
realisedVariation = sqrt(realisedVariance);
currentNotional = 100 * Notional;
strike = Strike;
adjustedStrike = sqrt(accruedDays/expectedN) * strike;
END;

IF Floor > 0 THEN

IF SquaredPayoff == 1 THEN
floor = pow(Floor, 2);
ELSE
floor = Floor;
END;
realisedVariation = max(floor * adjustedStrike, realisedVariation);
END;
IF Cap > 0 THEN
IF SquaredPayoff == 1 THEN
cap = pow(Cap, 2);
ELSE
cap = Cap;
END;
realisedVariation = min(cap * adjustedStrike, realisedVariation);
END;

payoff = LongShort * currentNotional * (realisedVariation - adjustedStrike);

Swap = PAY(payoff, ValuationSchedule[SIZE(ValuationSchedule)],

SettlementDate, PayCcy);

720
Listing 426: Payoff script for a ConditionalVarianceSwap02.

REQUIRE {Notional >= 0} AND {Strike > 0} AND {VarianceReference > 0};

FOR d IN (2, SIZE(ValuationSchedule), 1) DO

currPrice = Underlying(ValuationSchedule[d]);
prevPrice = Underlying(ValuationSchedule[d-1]);

IF {CountBothObservations == 1 AND {
{{BarrierType == 1 OR BarrierType == 4} AND
currPrice <= BarrierLevel AND prevPrice <= BarrierLevel} OR
{{BarrierType == 2 OR BarrierType == 3} AND
currPrice >= BarrierLevel AND prevPrice >= BarrierLevel}}}
OR {CountBothObservations == -1 AND {
{{BarrierType == 1 OR BarrierType == 4} AND
prevPrice <= BarrierLevel} OR
{{BarrierType == 2 OR BarrierType == 3} AND
prevPrice <= BarrierLevel} }}
THEN
realisedVariance = realisedVariance + pow(ln(currPrice/prevPrice), 2);
accruedDays = accruedDays + 1;
END;
END;

expectedN = SIZE(ValuationSchedule) - 1;
realisedVariance = (252/expectedN) * realisedVariance;

IF AccrualAdjustment == -1 THEN
accruedDays = expectedN;
END;

IF SquaredPayoff == 1 THEN
realisedVariation = realisedVariance;
currentNotional = pow(100, 2) * Notional / (2 * 100 * VarianceReference);
strike = pow(Strike, 2);
adjustedStrike = (accruedDays / expectedN) * strike;
ELSE
realisedVariation = sqrt(realisedVariance);
currentNotional = 100 * Notional;
strike = Strike;
adjustedStrike = sqrt(accruedDays/expectedN) * strike;
END;

IF Floor > 0 THEN

IF SquaredPayoff == 1 THEN
floor = pow(Floor, 2);
ELSE
floor = Floor;
END;
realisedVariation = max(floor * adjustedStrike, realisedVariation);
END;
IF Cap > 0 THEN
IF SquaredPayoff == 1 THEN
cap = pow(Cap, 2);
ELSE
cap = Cap;
END;
realisedVariation = min(cap * adjustedStrike, realisedVariation);
END;

payoff = LongShort * currentNotional * (realisedVariation - adjustedStrike);

Swap = PAY(payoff, ValuationSchedule[SIZE(ValuationSchedule)],

SettlementDate, PayCcy);

721
Listing 428: Payoff script for a PairwiseVarianceSwap.

REQUIRE {SIZE(Underlyings) == 2} AND {SIZE(UnderlyingStrikes) == 2}

REQUIRE {SIZE(UnderlyingNotionals) == 2} AND {UnderlyingStrikes[1] >= 0};
REQUIRE {UnderlyingStrikes[2] >= 0} AND {BasketStrike >= 0};
REQUIRE {UnderlyingNotionals[1] >= 0} AND {UnderlyingNotionals[2] >= 0};
REQUIRE {BasketNotional >= 0} AND {PayoffLimit > 0};
REQUIRE {SIZE(ValuationSchedule) == SIZE(LaggedValuationSchedule)};

FOR d IN (1, SIZE(ValuationSchedule)-1, 1) DO

performance1 = ln(Underlyings[1](LaggedValuationSchedule[d]) /
Underlyings[1](ValuationSchedule[d]));
performance2 = ln(Underlyings[2](LaggedValuationSchedule[d]) /
Underlyings[2](ValuationSchedule[d]));
basketPerformance = (performance1 + performance2) / 2;

realisedVariance1 = realisedVariance1 + pow(performance1, 2);

realisedVariance2 = realisedVariance2 + pow(performance2, 2);
realisedVarianceBasket = realisedVarianceBasket + pow(basketPerformance, 2);
END;

expectedN = SIZE(ValuationSchedule) - 1;
realisedVariance1 = 252 / (expectedN * AccrualLag) * realisedVariance1;
realisedVariance2 = 252 / (expectedN * AccrualLag) * realisedVariance2;
realisedVarianceBasket = 252 / (expectedN * AccrualLag) * realisedVarianceBasket;

currentNotional1 = pow(100, 2) * UnderlyingNotionals[1] /

(2 * 100 * UnderlyingStrikes[1]);
currentNotional2 = pow(100, 2) * UnderlyingNotionals[2] /
(2 * 100 * UnderlyingStrikes[2]);
currentNotionalBasket = pow(100, 2) * BasketNotional / (2 * 100 * BasketStrike);
strike1 = pow(UnderlyingStrikes[1], 2);
strike2 = pow(UnderlyingStrikes[2], 2);
strikeBasket = pow(BasketStrike, 2);

IF Floor > 0 THEN

floor = pow(Floor, 2);
realisedVariance1 = max(floor * strike1, realisedVariance1);
realisedVariance2 = max(floor * strike2, realisedVariance2);
realisedVarianceBasket = max(floor * strikeBasket, realisedVarianceBasket);
END;
IF Cap > 0 THEN
cap = pow(Cap, 2);
realisedVariance1 = min(cap * strike1, realisedVariance1);
realisedVariance2 = min(cap * strike2, realisedVariance2);
realisedVarianceBasket = min(cap * strikeBasket, realisedVarianceBasket);
END;

equityAmount1 = currentNotional1 * (realisedVariance1 - strike1);

equityAmount2 = currentNotional2 * (realisedVariance2 - strike2);
equityAmountBasket = currentNotionalBasket * (realisedVarianceBasket - strikeBasket);
pairEquityAmount = equityAmount1 + equityAmount2 + equityAmountBasket;

maxPairEquityAmount = PayoffLimit * (abs(UnderlyingNotionals[1]) +

abs(UnderlyingNotionals[2]));
minPairEquityAmount = -maxPairEquityAmount;

pairEquityAmount = max(minPairEquityAmount, pairEquityAmount);

pairEquityAmount = min(maxPairEquityAmount, pairEquityAmount);

Swap = PAY(LongShort * pairEquityAmount, ValuationSchedule[SIZE(ValuationSchedule)],

SettlementDate, PayCcy);

722
Listing 429: Payoff script for a VarianceDispersionSwap.

D = SIZE(ValuationSchedule);
expectedN = D - 1;

FOR u IN (1, n1, 1) DO

FOR d IN (2, D, 1) DO
currPrice = Underlyings1[u](ValuationSchedule[d]);
prevPrice = Underlyings1[u](ValuationSchedule[d-1]);
realisedVariance = realisedVariance + pow(ln(currPrice/prevPrice), 2);
END;

realisedVariance = (252/expectedN) * realisedVariance + Spreads1[u];

currentNotional = pow(100, 2) * Notionals1[u] / (2 * 100 * Strikes1[u]);
strike = pow(Strikes1[u], 2);

IF Floors1[u] > 0 THEN

floor = pow(Floors1[u], 2);
realisedVariance = max(floor * strike, realisedVariance);
END;
IF Caps1[u] > 0 THEN
cap = pow(Caps1[u], 2);
realisedVariance = min(cap * strike, realisedVariance);
END;
payoff1 = payoff1 + currentNotional * (realisedVariance - strike) * Weights1[u];
END;

FOR u IN (1, n2, 1) DO

FOR d IN (2, D, 1) DO
currPrice = Underlyings2[u](ValuationSchedule[d]);
prevPrice = Underlyings2[u](ValuationSchedule[d-1]);
realisedVariance = realisedVariance + pow(ln(currPrice/prevPrice), 2);
END;

realisedVariance = (252/expectedN) * realisedVariance + Spreads2[u];

currentNotional = pow(100, 2) * Notionals2[u] / (2 * 100 * Strikes2[u]);
strike = pow(Strikes2[u], 2);

IF Floors2[u] > 0 THEN

floor = pow(Floors2[u], 2);
realisedVariance = max(floor * strike, realisedVariance);
END;
IF Caps2[u] > 0 THEN
cap = pow(Caps2[u], 2);
realisedVariance = min(cap * strike, realisedVariance);
END;
payoff2 = payoff2 + currentNotional * (realisedVariance - strike) * Weights2[u];
END;

payoff = LongShort * (payoff1 - payoff2);

Swap = PAY(payoff, ValuationSchedule[D], SettlementDate, PayCcy);

NUMBER currentNotional1, currentNotional2;

FOR u IN (1, n1, 1) DO

currentNotional1 = currentNotional1 + (pow(100, 2) * Notionals1[u]
/ (2 * 100 * Strikes1[u]));
END;
FOR u IN (1, n2, 1) DO
currentNotional2 = currentNotional2 + (pow(100, 2) * Notionals2[u]
/ (2 * 100 * Strikes2[u]));
END;

723
Listing 430: Payoff script for a CorridorVarianceDispersionSwap.

N = SIZE(Underlyings1);
D = SIZE(ValuationSchedule);
expectedN = D - 1;

FOR u IN (1, N, 1) DO
FOR d IN (2, D, 1) DO
currPrice1 = Underlyings1[u](ValuationSchedule[d]);
prevPrice1 = Underlyings1[u](ValuationSchedule[d-1]);

IF {CountBothObservations == 1 AND
currPrice1 >= LowerBarrierLevels[u] AND currPrice1 <= UpperBarrierLevels[u] AND
prevPrice1 >= LowerBarrierLevels[u] AND prevPrice1 <= UpperBarrierLevels[u]} OR
{CountBothObservations == -1 AND
prevPrice >= LowerBarrierLevels[u] AND prevPrice <= UpperBarrierLevels[u]} THEN
currPrice2 = Underlyings2[u](ValuationSchedule[d]);
prevPrice2 = Underlyings2[u](ValuationSchedule[d-1]);
realisedVariance1 = realisedVariance1 + pow(ln(currPrice1/prevPrice1), 2);
realisedVariance2 = realisedVariance2 + pow(ln(currPrice2/prevPrice2), 2);
accruedDays = accruedDays + 1;
END;
END;

IF AccrualAdjustment == -1 THEN
accruedDays = expectedN;
END;

realisedVariance1 = (252/expectedN) * realisedVariance1 + Spreads1[u];

realisedVariance2 = (252/expectedN) * realisedVariance2 + Spreads2[u];

currentNotional1 = pow(100, 2) * Notionals1[u] / (2 * 100 * Strikes1[u]);

currentNotional2 = pow(100, 2) * Notionals2[u] / (2 * 100 * Strikes2[u]);

strike1 = pow(Strikes1[u], 2);

strike2 = pow(Strikes2[u], 2);

adjustedStrike1 = (accruedDays / expectedN) * strike1;

adjustedStrike2 = (accruedDays / expectedN) * strike2;

IF Floors1[u] > 0 THEN

floor1 = pow(Floors1[u], 2);
realisedVariance1 = max(floor1 * adjustedStrike1, realisedVariance1);
END;
IF Floors2[u] > 0 THEN
floor2 = pow(Floors2[u], 2);
realisedVariance2 = max(floor2 * adjustedStrike2, realisedVariance2);
END;
IF Caps1[u] > 0 THEN
cap1 = pow(Caps1[u], 2);
realisedVariance1 = max(cap1 * adjustedStrike1, realisedVariance1);
END;
IF Caps2[u] > 0 THEN
cap2 = pow(Caps2[u], 2);
realisedVariance2 = max(cap2 * adjustedStrike2, realisedVariance2);
END;

payoff1 = currentNotional1 * (realisedVariance1 - adjustedStrike1);

payoff2 = currentNotional2 * (realisedVariance2 - adjustedStrike2);
payoff = payoff + LongShort * Weights[u] * (payoff1 - payoff2);
END;

Swap = PAY(payoff, ValuationSchedule[D], SettlementDate, PayCcy);

724
Listing 431: Payoff script for a KOCorridorVarianceDispersionSwap.

N = SIZE(Underlyings1);
Dk = SIZE(KnockOutSchedule);
expectedN = D - 1;

FOR d IN (1, Dk, 1) DO

IF KnockOutSchedule[d] > VarianceAccrualStartDate THEN
expectedN = expectedN + 1;
END;
END;

alive = 1;
FOR d IN (1, Dk, 1) DO
IF alive == 1 THEN
IF KnockOutSchedule[d] > VarianceAccrualStartDate THEN
FOR u IN (1, N, 1) DO
currPrice1 = Underlyings1[u](KnockOutSchedule[d]);
prevPrice1 = Underlyings1[u](KnockOutSchedule[d-1]);

IF {CountBothObservations == 1 AND
currPrice1 >= CorridorLowerBarrierLevels[u] AND currPrice1 <= CorridorUpperBarrierLevels[u] AND
prevPrice1 >= CorridorLowerBarrierLevels[u] AND prevPrice1 <= CorridorUpperBarrierLevels[u]} OR
{CountBothObservations == -1 AND
prevPrice >= CorridorLowerBarrierLevels[u] AND prevPrice <= CorridorUpperBarrierLevels[u]} THEN
currPrice2 = Underlyings2[u](KnockOutSchedule[d]);
prevPrice2 = Underlyings2[u](KnockOutSchedule[d-1]);
realisedVariance1 = realisedVariance1 + pow(ln(currPrice1/prevPrice1), 2);
realisedVariance2 = realisedVariance2 + pow(ln(currPrice2/prevPrice2), 2);
accruedDays = accruedDays + 1;
END;
END;
END;

FOR u IN (1, N, 1) DO
currPrice1 = Underlyings1[u](KnockOutSchedule[d]);
IF currPrice1 <= KOLowerBarrierLevels[u] OR currPrice1 >= KOUpperBarrierLevels[u] THEN
alive = 0;
END;
END;
END;

IF {alive == 0 OR d == Dk} AND {calculated == 0} THEN

calculated = 1;

realisedVariance1 = (252/expectedN) * realisedVariance1 + Spreads1[u];

realisedVariance2 = (252/expectedN) * realisedVariance2 + Spreads2[u];

IF AccrualAdjustment == -1 THEN
accruedDays = expectedN;
END;

currentNotional1 = pow(100, 2) * Notionals1[u] / (2 * 100 * Strikes1[u]);

currentNotional2 = pow(100, 2) * Notionals2[u] / (2 * 100 * Strikes2[u]);

strike1 = pow(Strikes1[u], 2);

strike2 = pow(Strikes2[u], 2);

adjustedStrike1 = (accruedDays / expectedN) * strike1;

adjustedStrike2 = (accruedDays / expectedN) * strike2;

IF Floors1[u] > 0 THEN

floor1 = pow(Floors1[u], 2);
realisedVariance1 = max(floor1 * adjustedStrike1, realisedVariance1);
END;
IF Floors2[u] > 0 THEN
floor2 = pow(Floors2[u], 2);
realisedVariance2 = max(floor2 * adjustedStrike2, realisedVariance2);
END;
IF Caps1[u] > 0 THEN
cap1 = pow(Caps1[u], 2);
realisedVariance1 = max(cap1 * adjustedStrike1, realisedVariance1);
END;
IF Caps2[u] > 0 THEN
cap2 = pow(Caps2[u], 2);
realisedVariance2 = max(cap2 * adjustedStrike2, realisedVariance2);
END; 725
payoff1 = currentNotional1 * (realisedVariance1 - adjustedStrike1);
payoff2 = currentNotional2 * (realisedVariance2 - adjustedStrike2);
Listing 432: Payoff script for a GammaSwap.

REQUIRE {Notional >= 0} AND {Strike >= 0};

NUMBER d, expectedN, realisedVariance, currPrice, prevPrice, presPrice, currentNotional;

NUMBER payoff, realisedVariation, strike;

presPrice = Underlying(ValuationSchedule[1]);

FOR d IN (2, SIZE(ValuationSchedule), 1) DO

currPrice = Underlying(ValuationSchedule[d]);
prevPrice = Underlying(ValuationSchedule[d-1]);
realisedVariance = realisedVariance + (currPrice/presPrice) * pow(ln(currPrice/prevPrice), 2);
END;

expectedN = SIZE(ValuationSchedule) - 1;
realisedVariance = (252/expectedN) * realisedVariance;

realisedVariation = realisedVariance;
currentNotional = pow(100, 2) * Notional / (2 * 100 * Strike);
strike = pow(Strike, 2);

payoff = LongShort * currentNotional * (realisedVariation -

strike);

Swap = PAY(payoff, ValuationSchedule[SIZE(ValuationSchedule)],

SettlementDate, PayCcy);

726
Listing 434: Payoff script for a BasketVarianceSwap.

NUMBER sumOfWeights;
FOR i IN (1, n, 1) DO
sumOfWeights = sumOfWeights + Weights[i];
END;
REQUIRE sumOfWeights == 1;

NUMBER d, expectedN, currPrice[n], prevPrice[n];

NUMBER realisedVariance, basketVariation, realisedVariation;
NUMBER strike, cap, floor, currentNotional, payoff;

FOR d IN (2, SIZE(ValuationSchedule), 1) DO

basketVariation = 0;
FOR i IN (1, n, 1) DO
currPrice[i] = Underlyings[i](ValuationSchedule[d]);
prevPrice[i] = Underlyings[i](ValuationSchedule[d-1]);
basketVariation = basketVariation + Weights[i] * ln(currPrice[i]/prevPrice[i]);
END;
realisedVariance = realisedVariance + pow(basketVariation, 2);
END;

expectedN = SIZE(ValuationSchedule) - 1;
realisedVariance = (252/expectedN) * realisedVariance;

IF SquaredPayoff == 1 THEN
realisedVariation = realisedVariance;
currentNotional = pow(100, 2) * Notional / (2 * 100 * Strike);
strike = pow(Strike, 2);
ELSE
realisedVariation = sqrt(realisedVariance);
currentNotional = 100 * Notional;
strike = Strike;
END;

IF Floor > 0 THEN

IF SquaredPayoff == 1 THEN
floor = pow(Floor, 2);
ELSE
floor = Floor;
END;
realisedVariation = max(floor * strike, realisedVariation);
END;
IF Cap > 0 THEN
IF SquaredPayoff == 1 THEN
cap = pow(Cap, 2);
ELSE
cap = Cap;
END;
realisedVariation = min(cap * strike, realisedVariation);
END;

payoff = LongShort * currentNotional * (realisedVariation - strike);

Swap = PAY(payoff, ValuationSchedule[SIZE(ValuationSchedule)],

SettlementDate, PayCcy);

727
Listing 441: Payoff script for a TaRF.

REQUIRE FixingAmount > 0;

REQUIRE LongShort == 1 OR LongShort == -1;
REQUIRE SIZE(RangeUpperBounds) == SIZE(RangeLowerBounds);
REQUIRE SIZE(RangeLowerBounds) == SIZE(RangeLeverages);
REQUIRE SIZE(RangeLowerBounds) == SIZE(RangeStrikes);
REQUIRE TargetType == -1 OR TargetType == 0 OR TargetType == 1;
REQUIRE SIZE(FixingDates) == SIZE(SettlementDates);

NUMBER Payoff, d, r, PnL, wasTriggered, AccProfit, Hits, currentNotional;

NUMBER Fixing[SIZE(FixingDates)], Triggered[SIZE(FixingDates)];

FOR r IN (1, SIZE(RangeUpperBounds), 1) DO

REQUIRE RangeLowerBounds[r] <= RangeUpperBounds[r];
REQUIRE RangeStrikes[r] >= 0;
END;

FOR d IN (1, SIZE(FixingDates), 1) DO

Fixing[d] = Underlying(FixingDates[d]);
IF wasTriggered != 1 THEN
PnL = 0;
FOR r IN (1, SIZE(RangeUpperBounds), 1) DO
IF Fixing[d] > RangeLowerBounds[r] AND Fixing[d] <= RangeUpperBounds[r] THEN
PnL = PnL + RangeLeverages[r] * FixingAmount * (Fixing[d] - RangeStrikes[r]);
END;
END;

IF PnL >= 0 THEN

AccProfit = AccProfit + PnL;
Hits = Hits + 1;
END;

IF {KnockOutProfitEvents > 0 AND Hits >= KnockOutProfitEvents} OR

{KnockOutProfitAmount > 0 AND AccProfit >= KnockOutProfitAmount} THEN
wasTriggered = 1;
Triggered[d] = 1;
IF TargetType == 0 THEN
Payoff = Payoff + LOGPAY(TargetAmount - (AccProfit - PnL), FixingDates[d], SettlementDates[d
END;
IF TargetType == 1 THEN
Payoff = Payoff + LOGPAY(PnL, FixingDates[d], SettlementDates[d], PayCcy, 0, Cashflow);
END;
ELSE
Payoff = Payoff + LOGPAY(PnL, FixingDates[d], SettlementDates[d], PayCcy, 0, Cashflow);
END;
END;
END;
value = LongShort * Payoff;
currentNotional = FixingAmount * RangeStrikes[1];

728
Listing 442: Knock Out Swap

<Trade id="194837232">
<TradeType>KnockOutSwap</TradeType>
<Envelope>...</Envelope>
<KnockOutSwapData>
<!-- BarrierData and BarrierStartDate specify the knock out terms -->
<BarrierData>
<Type>UpAndOut</Type>
<Levels>
<Level>0.05</Level>
</Levels>
</BarrierData>
<BarrierStartDate>2024-10-01</BarrierStartDate>
<!-- we require exactly one Floating and one Fixed Leg -->
<LegData>
<LegType>Floating</LegType>
...
</LegData>
<LegData>
<LegType>Fixed</LegType>
...
</LegData>
</KnockOutSwapData>
</Trade>

Listing 480: Commodity fixed leg outline.

<LegData>
<LegType>CommodityFixed</LegType>
<Payer>...</Payer>
<Currency>...</Currency>
<PaymentConvention>...</PaymentConvention>
<PaymentLag>...</PaymentLag>
<PaymentCalendar>...</PaymentCalendar>
<ScheduleData>
...
</ScheduleData>
<PaymentDates>
<PaymentDate>...</PaymentDate>
</PaymentDates>
<CommodityFixedLegData>
...
</CommodityFixedLegData>
</LegData>

729
Listing 481: Commodity fixed leg data outline.

<CommodityFixedLegData>
<Quantities>
<Quantity>...</Quantity>
</Quantities>
<Prices>
<Price>...</Price>
</Prices>
<CommodityPayRelativeTo>...</CommodityPayRelativeTo>
<Tag>...</Tag>
</CommodityFixedLegData>

Listing 482: Commodity floating leg outline.

<LegData>
<LegType>CommodityFloating</LegType>
<Payer>...</Payer>
<Currency>...</Currency>
<PaymentConvention>...</PaymentConvention>
<PaymentLag>...</PaymentLag>
<PaymentCalendar>...</PaymentCalendar>
<ScheduleData>
...
</ScheduleData>
<PaymentDates>
<PaymentDate>...</PaymentDate>
</PaymentDates>
<CommodityFloatingLegData>
...
</CommodityFloatingLegData>
</LegData>

Listing 483: ScheduleData node for monthly periods.

<ScheduleData>
<Rules>
<StartDate>2020-01-01</StartDate>
<EndDate>2020-04-30</EndDate>
<Tenor>1M</Tenor>
<Calendar>NullCalendar</Calendar>
<Convention>Unadjusted</Convention>
<TermConvention>Unadjusted</TermConvention>
<Rule>Backward</Rule>
<EndOfMonth>true</EndOfMonth>
<AdjustEndDateToPreviousMonthEnd>false</AdjustEndDateToPreviousMonthEnd>
</Rules>
</ScheduleData>

730
Listing 484: ScheduleData node for explicit periods.

<ScheduleData>
<Dates>
<Calendar>NullCalendar</Calendar>
<Convention>Unadjusted</Convention>
<Dates>
<Date>2019-11-21</Date>
<Date>2019-12-19</Date>
<Date>2020-01-21</Date>
<Date>2020-02-20</Date>
<Date>2020-03-20</Date>
</Dates>
</Dates>
</ScheduleData>

Listing 485: Commodity floating leg data outline.

<CommodityFloatingLegData>
<Name>...</Name>
<PriceType>...</PriceType>
<Quantities>
<Quantity>...</Quantity>
</Quantities>
<CommodityQuantityFrequency>...</CommodityQuantityFrequency>
<CommodityPayRelativeTo>...</CommodityPayRelativeTo>
<Spreads>
<Spread>...</Spread>
</Spreads>
<Gearings>
<Gearing>...</Gearing>
</Gearings>
<PricingDateRule>...</PricingDateRule>
<PricingCalendar>...</PricingCalendar>
<PricingLag>...</PricingLag>
<PricingDates>
<PricingDate>...</PricingDate>
</PricingDates>
<IsAveraged>...</IsAveraged>
<IsInArrears>...</IsInArrears>
<FutureMonthOffset>...</FutureMonthOffset>
<DeliveryRollDays>...</DeliveryRollDays>
<IncludePeriodEnd>...</IncludePeriodEnd>
<ExcludePeriodStart>...</ExcludePeriodStart>
<HoursPerDay>...</HoursPerDay>
<UseBusinessDays>...</UseBusinessDays>
<Tag>...</Tag>
<DailyExpiryOffset>...</DailyExpiryOffset>
</CommodityFloatingLegData>

731
Listing 486: Example WTI averaging floating leg, first approach.

<LegData>
<LegType>CommodityFloating</LegType>
<Payer>true</Payer>
<Currency>USD</Currency>
<PaymentLag>2</PaymentLag>
<PaymentConvention>Following</PaymentConvention>
<PaymentCalendar>US-NYSE</PaymentCalendar>
<CommodityFloatingLegData>
<Name>NYMEX:CL</Name>
<PriceType>FutureSettlement</PriceType>
<Quantities>
<Quantity>5000</Quantity>
</Quantities>
<IsAveraged>true</IsAveraged>
<FutureMonthOffset>0</FutureMonthOffset>
</CommodityFloatingLegData>
<ScheduleData>
<Rules>
<StartDate>2019-09-01</StartDate>
<EndDate>2019-10-31</EndDate>
<Tenor>1M</Tenor>
<Calendar>NullCalendar</Calendar>
<Convention>Unadjusted</Convention>
<TermConvention>Unadjusted</TermConvention>
<Rule>Backward</Rule>
<EndOfMonth>true</EndOfMonth>
</Rules>
</ScheduleData>
</LegData>

Listing 487: Example WTI averaging floating leg, second approach.

<CommodityFloatingLegData>
<Name>NYMEX:CSX</Name>
<PriceType>FutureSettlement</PriceType>
<Quantities>
<Quantity>5000</Quantity>
</Quantities>
<IsAveraged>true</IsAveraged>
<FutureMonthOffset>0</FutureMonthOffset>
</CommodityFloatingLegData>

732
Listing 488: Equity Margin leg outline.

<LegData>
<LegType>EquityMargin</LegType>
<Payer>true</Payer>
<Currency>EUR</Currency>
<PaymentConvention>Following</PaymentConvention>
<PaymentLag>2D</PaymentLag>
<PaymentCalendar>TARGET</PaymentCalendar>
<ScheduleData>
<Dates>
<Dates>
<Date>2019-12-31</Date>
<Date>2020-03-30</Date>
<Date>2020-06-30</Date>
<Date>2020-09-30</Date>
<Date>2020-12-30</Date>
<Date>2021-03-30</Date>
</Dates>
</Dates>
</ScheduleData>
<PaymentDates>
<PaymentDate>...</PaymentDate>
</PaymentDates>
<EquityMarginLegData>
...
</EquityMarginLegData>
</LegData>

Listing 489: Equity margin leg data outline.

<EquityMarginLegData>
<Rates>
<Rate>0.003</Rate>
</Rates>
<InitialMarginFactor>0.12</InitialMarginFactor>
<Multiplier>10</Multiplier>
<EquityLegData>
<ReturnType>Total</ReturnType>
<Name>RIC:.STOXX50E</Name>
<InitialPrice>2946</InitialPrice>
<NotionalReset>false</NotionalReset>
<FixingDays>2</FixingDays>
</EquityLegData>
</EquityMarginLegData>

733
Listing 509: FormulaBasedLegData configuration.

<LegData>
<LegType>FormulaBased</LegType>
<Payer>true</Payer>
<Currency>EUR</Currency>
<PaymentConvention>MF</PaymentConvention>
<PaymentLag>2</PaymentLag>
<PaymentCalendar>TARGET</PaymentCalendar>
<DayCounter>A360</DayCounter>
...
<FormulaBasedLegData>
<Index>gtZero({USD-CMS-5Y}-0.03)*
max(min(9.0*({EUR-CMS-10Y}-{GBP-CMS-2Y})+0.02,0.08),0.0)</Index>
<IsInArrears>false</IsInArrears>
<FixingDays>2</FixingDays>
</FormulaBasedLegData>
...
</LegData>

734
8.4 Allowable Values
Date
Date Fields Allowable Values
Any of the following date formats are supported:
yyyymmdd
yyyy-mm-dd
All Date fields: yyyy/mm/dd
StartDate [Link]
EndDate dd-mm-yy
Date dd/mm/yy
ExerciseDate [Link]
PayDate dd-mm-yyyy
ValueDate dd/mm/yyyy
NearDate [Link]
FarDate
etc and
Dates as serial numbers, comparable to Microsoft Excel
dates, with a minimum of 367 for Jan 1, 1901,
and a maximum of 109574 for Dec 31, 2199.

Table 30: Allowable Values for Date

Convention
Roll Convention Fields Allowable Values
F, Following, FOLLOWING
All Convention fields: MF, ModifiedFollowing, Modified Following, MODIFIEDF
Convention P, Preceding, PRECEDING
TermConvention MP, ModifiedPreceding, Modified Preceding, MODIFIEDP
PaymentConvention U, Unadjusted, INDIFF
etc HMMF, HalfMonthModifiedFollowing, HalfMonthMF, Half Month Modifi
NEAREST (takes future date in case of equal distance)

Table 31: Allowable Values for Roll Conventions

735
Currency
Category Allowable Values
Fiat Currencies AED,AFN,ALL,AMD,ANG,AOA,ARS,AUD,AWG,AZN,
BAM,BBD,BDT,BGN,BHD,BIF,BMD,BND,BOB,BOV,
BRL,BSD,BTN,BWP,BYN,BZD,CAD,CDF,CHE,CHF,
CHW,CLF,CLP,CNH,CNT,CNY,COP,COU,CRC,CUC,
CUP,CVE,CZK,DJF,DKK,DOP,DZD,EGP,ERN,ETB,
EUR,FJD,FKP,GBP,GEL,GGP,GHS,GIP,GMD,GNF,
GTQ,GYD,HKD,HNL,HRK,HTG,HUF,IDR,ILS,IMP,
INR,IQD,IRR,ISK,JEP,JMD,JOD,JPY,KES,KGS,
KHR,KID,KMF,KPW,KRW,KWD,KYD,KZT,LAK,LBP,
LKR,LRD,LSL,LYD,MAD,MDL,MGA,MKD,MMK,MNT,
MOP,MRU,MUR,MVR,MWK,MXN,MXV,MYR,MZN,NAD,
NGN,NIO,NOK,NPR,NZD,OMR,PAB,PEN,PGK,PHP,
PKR,PLN,PYG,QAR,RON,RSD,RUB,RWF,SAR,SBD,
SCR,SDG,SEK,SGD,SHP,SLL,SOS,SRD,SSP,STN,
SVC,SYP,SZL,THB,TJS,TMT,TND,TOP,TRY,TTD,
TWD,TZS,UAH,UGX,USD,USN,UYI,UYU,UYW,UZS,
VES,VND,VUV,WST,XAF,XAU,XCD,XOF,
XPF,XSU,XUA,YER,ZAR,ZMW,ZWL
GBp, GBX (for pennies of GBP)
ILa, ILX, ILs, ILA (for agorot of ILS)
Minor Currencies
ZAc, ZAC, ZAX (for cents of ZAR)
Note: Minor Currency codes are only supported for equity products.
Precious Metals XAG, XAU, XPD, XPT
treated as Currencies
Cryptocurrencies BTC, XBT, ETH, ETC, BCH, XRP, LTC
This full list of currencies is available via loading the provided [Link] at start-up.
Note: Currency codes must also match available currencies in the [Link] file.

Table 32: Allowable Values for Currency

Rule
Allowable Values Effect
Backward Backward from termination date to effective date.
Forward Forward from effective date to termination date.
Zero No intermediate dates between effective date and termination date.
ThirdWednesday All dates but effective date and termination date are taken to be on
the third Wednesday of their month (with forward calculation.)
LastWednesday All dates but effective date and termination date are taken to be on
the last Wednesday of their month (with forward calculation.)
ThirdThursday All dates but effective date and termination date are taken to be on
the third Thursday of their month (with forward calculation.)
ThirdFriday All dates but effective date and termination date are taken to be on
the third Friday of their month (with forward calculation.)

736
MondayAfterThird- All dates but effective date and termination date are taken to be on
Friday the Monday following the third Friday of their month (with forward
calculation.)
TuesdayAfterThird- All dates but effective date and termination date are taken to be on
Friday the Tuesday following the third Friday of their month (with forward
calculation.)
Twentieth All dates but the effective date are taken to be the twentieth of their
month (used for CDS schedules in emerging markets.) The termination
date is also modified.
TwentiethIMM All dates but the effective date are taken to be the twentieth of an
IMM month (used for CDS schedules.) The termination date is also
modified.
OldCDS Same as TwentiethIMM with unrestricted date ends and long/short
stub coupon period (old CDS convention).
CDS Credit derivatives standard rule defined in ’Big Bang’ changes in 2009.

For quarterly periods (Tenor set to 3M ):

(Assuming no FirstDate/LastDate)
Dates fall on 20th of March, June, September, December. A Following
roll convention will be applied if the 20th falls on a non-business day.
If the EndDate in the schedule is set to a date beyond the rolled
quarterly CDS date, the actual trade termination date will be on the
following quarterly CDS date.
The first coupon will be paid on the quarterly CDS date following the
StartDate, and be for the period since the previous quarterly CDS
date.

For monthly periods (Tenor set to 1M ):

(Assuming no FirstDate/LastDate)
Dates fall on 20th of each month, but the termination is still adjusted
to be in line with quarterly periods.
If the EndDate in the schedule is set to a date beyond the rolled
quarterly CDS date (i.e. the 20th+roll Mar, Jun, Sep, Dec),
the actual termination date will be on the following quarterly CDS
date, causing a long final stub.
The first coupon will be paid on the next 20th monthly following the
StartDate, and be for the period since the previous month’s 20th.
CDS2015 Credit derivatives standard rule updated in 2015.
Same as CDS but with termination dates adjusted to
20th June and 20th December.
For schedule EndDates from the 20th of March to the 19th September,
both included, the termination date will fall on the 20th June (with
Following roll).
For schedule EndDates from the 20th September to the 19th March,
both included, the termination date will fall on the 20th December
(with Following roll).

737
EveryThursday If FirstDate is not given, all thursdays between start and end date. If
FirstDate is given, FirstDate plus all thursdays between FirstDate and
end date.

Table 33: Allowable Values for Rule

Calendar
Allowable Values Resulting Calendar
TARGET, TGT, EUR Target Calendar
CA, CAN, CAD, TRB Canada Calendar
JP, JPN, JPY, TKB Japan Calendar
CH, CHE, CHF, ZUB Switzerland Calendar
GB, GBR, GBP, LNB, UK Calendar
UK
US, USA, USD, NYB US Calendar
US-SET US Settlement Calendar
US-GOV US Government Bond Calendar
US-NYSE, New York US NYSE Calendar
stock exchange
US with Libor impact US Calendar for Libor fixings
US-NERC US NERC Calendar
US-SOFR US SOFR fixing Calendar
AR, ARG, ARS Argentina Calendar
AU, AUD, AUS Australia Calendar
AT, AUT, ATS Austria Calendar
BE, BEL, BEF Belgium Calendar
BW, BWA, BWP Botswana Calendar
BR, BRA, BRL Brazil Calendar
CL, CHL, CLP Chile Calendar
CN, CHN, CNH, CNY China Calendar
CO, COL, COP Colombia Calendar
CY, CYP Cyprus Calendar
CZ, CZE, CZK Czech Republic Calendar
DK, DNK, DKK, DEN Denmark Calendar
FI, FIN Finland Calendar
FR, FRF France Calendar
DE, DEU Germany Calendar
GR, GRC Greek Calendar
HK, HKG, HKD Hong Kong Calendar
HU, HUN, HUF Hungary Calendar
IS, ISL, ISK Iceland Calendar
IN, IND, INR India Calendar
ID, IDN, IDR Indonesia Calendar
IE, IRL Ireland Calendar
IL, ISR, ILS Israel Calendar
Telbor Tel Aviv Inter-Bank Offered Rate Calendar

738
IT, ITA, ITL Italy Calendar
LU, LUX, LUF Luxembourg Calendar
MX, MEX, MXN Mexico Calendar
MY, MYS, MYR Malaysia Calendar
NL, NLD, NZD New Zealand Calendar
NO, NOR, NOK Norway Calendar
PE, PER, PEN Peru Calendar
PH, PHL, PHP Philippines Calendar
PO, POL, PLN Poland Calendar
RO, ROU, RON Romania Calendar
RU, RUS, RUB Russia Calendar
SAU, SAR Saudi Arabia
AE, ARE, AED United Arab Emirates
SG, SGP, SGD Singapore Calendar
ZA, ZAF, ZAR, SA South Africa Calendar
KR, KOR, KRW South Korea Calendar
ES, ESP Spain Calendar
SE, SWE, SEK, SS Sweden Calendar
TW, TWN, TWD Taiwan Calendar
TH, THA, THB Thailand Calendar
TR, TUR, TRY Turkey Calendar
UA, UKR, UAH Ukraine Calendar
XASX Australian Securities Exchange Calendar
BVMF Brazil Bovespa Calendar
XTSE Canada Toronto Stock Exchange Calendar
XSHG China Shanghai Stock Exchange Calendar
XFRA Germany Frankfurt Stock Exchange
XETR Germany XETRA Calendar
ECAG Germany EUREX Calendar
EUWA Germany EUWAX Calendar
XJKT Indonesia Jakarta Stock Exchange (now IDX) Calendar
XIDX Indonesia Indonesia Stock Exchange Calendar
XDUB Ireland Stock Exchange Calendar
XTAE Israel Tel Aviv Stock Exchange Calendar
XMIL Italy Italian Stock Exchange Calendar
MISX Russia Moscow Exchange Calendar
XKRX Korea Exchange Calendar
XSWX Switzerland SIX Swiss Exchange Calendar
XLON UK London Stock Exchange
XLME UK London Metal Exchange
XNYS US New York Stock Exchange Calendar
XPAR Paris stock exchange
WMR Thomson Reuters QM/Reuters Spot
WeekendsOnly Weekends Only Calendar
ICE_FuturesUS ICE Futures U.S. Currency, Stock and Credit Index, Metal,
Nat Gas, Power, Oil and Environmental

739
 ICE_FuturesUS_1 ICE Futures U.S. Sugar, Cocoa, Coffee, Cotton and FCOJ
ICE_FuturesUS_2 ICE Futures U.S. Canola
ICE_FuturesEU ICE Futures Europe
ICE_FuturesEU_1 ICE Futures Europe for contracts where 26 Dec is a holiday
ICE_EndexEnergy ICE Endex European power and natural gas products
ICE_EndexEquities ICE Endex European equities
ICE_SwapTradeUS ICE Swap Trade U.S.
ICE_SwapTradeUK ICE Swap Trade U.K.
ICE_FuturesSingapore ICE futures Singapore
CME CME group exchange calendar
NullCalendar, Null Null Calendar, i.e. all days are business days

Table 34: Allowable Values for Calendar. Combinations of calendars can be provided using
comma separated calendar names.

740
DayCount Convention
Allowable Values Resulting DayCount Conven-
tion
A360, Actual/360, ACT/360, Actual 360
Act/360
A365, A365F, Actual/365 Actual 365 Fixed
(Fixed), Actual/365 (fixed),
ACT/[Link], ACT/365,
ACT/365L, Act/365, Act/365L
A364, Actual/364, Act/364, Actual 364
ACT/364
Actual/365 (No Leap), Act/365 Actual 365 Fixed (No Leap Year)
(NL), NL/365, Actual/365
(JGB)
Act/365 (Canadian Bond) Actual 365 Fixed (Canadian
Bond)
T360, 30/360, ACT/nACT, Thirty 360 (US)
30/360 US, 30/360 (US),
30U/360, 30US/360
30/360 (Bond Basis) Thirty 360 (Bond Basis)
30E/360 (Eurobond Basis), Thirty 360 (European)
30E/360, 30/360 AIBD (Euro),
30E/[Link], 30E/360 ICMA
30E/360E, 30E/360 ISDA, Thirty 360 (German)
30E/[Link], 30/360 German,
30/360 (German)
30/360 Italian, 30/360 (Italian) Thirty 360 (Italian)
ActActISDA, ACT/[Link], Actual Actual (ISDA)
Actual/Actual (ISDA), ActualAc-
tual (ISDA), ACT/ACT, Ac-
t/Act, ACT
ActActISMA, Actual/Actual Actual Actual (ISMA)
(ISMA), ActualActual (ISMA),
ACT/[Link]
ActActICMA, Actual/Actual Actual Actual (ICMA)
(ICMA), ActualActual (ICMA),
ACT/[Link]
ActActAFB, ACT/[Link], Actual Actual (AFB)
Actual/Actual (AFB), ACT29
BUS/252, Business/252 Brazilian Bus/252
1/1 1/1
Simple Simple Day Counter
Year Year Counter

Table 35: Allowable Values for DayCount Convention

741
Index
On form CCY-INDEX-TENOR, and matching available
indices in the market data configuration.
Index Component Allowable Values
EUR-EONIA
EUR-ESTER, EUR-ESTR, EUR-STR
EUR-EURIBOR, EUR-EURIBOR365
EUR-LIBOR
EUR-CMS
USD-FedFunds
USD-SOFR
USD-Prime
USD-LIBOR
USD-SIFMA
USD-CMS
GBP-SONIA
GBP-LIBOR
GBP-CMS
GBP-BoEBase
JPY-LIBOR
JPY-TIBOR
JPY-EYTIBOR
JPY-TONAR
JPY-CMS
CHF-LIBOR
CHF-SARON
AUD-LIBOR
AUD-BBSW
CCY-INDEX
CAD-CDOR
CAD-BA
SEK-STIBOR
SEK-LIBOR
SEK-STINA
DKK-LIBOR
DKK-CIBOR
DKK-CITA
SGD-SIBOR
SGD-SOR
HKD-HIBOR
HKD-HONIA
NOK-NIBOR
HUF-BUBOR
IDR-IDRFIX
INR-MIFOR
MXN-TIIE
PLN-WIBOR
RUB-MOSPRIME
SKK-BRIBOR
THB-THBFIX
THB-THOR
742
THB-BIBOR
NZD-BKBM
TENOR An integer followed by D, W, M or Y
 Defaults for FixingDays
Index Default value
Ibor indices 2, except for the Ibor indices below:
USD-SIFMA 1
GBP-LIBOR 0
AUD-BBSW 0
CAD-CDOR 0
CNY-SHIBOR 1
HKD-HIBOR 0
MXN-TIIE 1
MYR-KLIBOR 0
TRY-TRLIBOR 0
ZAR-JIBAR 0
Overnight indices 0, except for the Overnight indices below:
CHF-TOIS 1
CLP-CAMARA 2
PLN-POLONIA 1
DKK-DKKOIS 1
SEK-SIOR 1

Table 37: Defaults for FixingDays

FX Index
Index Format Allowable Values
FX-SOURCE-CCY1-CCY2 The FX- part of the string stays constant for all currency
pairs. SOURCE is the market data fixing source defined
in the market configuration. CCY1 and CCY2 are the ISO
currency codes of the fx pair. Fixings are expressed as
amount in CCY2 for one unit of CCY1.

Table 38: Allowable values for FX index fixings.

Inflation CPI Index

Trade Data Allowable Values
Index for CPI leg Any string (provided it is the ID of an infla-
tion index in the market configuration)

Table 39: Allowable values for CPI index.

743
Credit CreditCurveId
Trade Data Allowable Values
Any string (provided it is the ID of a single name or index
reference entity in the market configuration).
Typically a RED-code with the RED: prefix
CreditCurveId
Examples:
for credit trades
RED:2I65BRHH6 (CDX N.A. High Yield, Series 13, Version 1)
- single name
RED:008CA0|SNRFOR|USD|MR14 (Agilent Tech Senior USD)
and index

Table 40: Allowable values for credit CreditCurveId

Equity Name
Trade Data Allowable Values
Any string (provided it is the ID of an equity in the market
configuration).
Typically a RIC-code with the RIC: prefix
Name for equity trades
Examples:
RIC:.SPX (S&P 500 Index)
RIC:EEM.N (iShares MSCI Emerging Markets ETF)

Table 41: Allowable values for equity Name.

Commodity Curve Name

Trade Data Allowable Values
Name for com- Any string (provided it is the ID of an commodity in the market
modity trades configuration)

Table 42: Allowable values for commodity data.

Tier
Value Description
SNRFOR Senior unsecured for corporates or foreign debt for sovereigns
SUBLT2 Subordinated or lower Tier 2 debt for banks
SNRLAC Senior loss absorbing capacity
SECDOM Secured for corporates or domestic debt for sovereigns
JRSUBUT2 Junior subordinated or upper Tier 2 debt for banks
PREFT1 Preference shares or Tier 1 capital for banks
LIEN1 First lien
LIEN2 Second lien
LIEN3 Third lien

Table 43: Allowable values for Tier

744
DocClause
Value Description
CR Full or old restructuring referencing the 2003 ISDA Definitions
MM Modified modified restructuring referencing the 2003 ISDA Defini-
tions
MR Modified restructuring referencing the 2003 ISDA Definitions
XR No restructuring referencing the 2003 ISDA Definitions
CR14 Full or old restructuring referencing the 2014 ISDA Definitions
MM14 Modified modified restructuring referencing the 2014 ISDA Defini-
tions
MR14 Modified restructuring referencing the 2014 ISDA Definitions
XR14 No restructuring referencing the 2014 ISDA Definitions

Table 44: Allowable values for DocClause

Exchange
Trade Data Allowable Values
Exchange Any string, typically a MIC code (provided it is the ID of an ex-
change in the market configuration)

Table 45: Allowable Values for Exchange

Boolean nodes
Node Value Evaluates To
Y, YES, TRUE, true, 1 true
N, NO, FALSE, false, 0 false

Table 46: Allowable values for boolean node

745
9 Netting Set Definitions
The netting set definitions file - [Link] - contains a list of definitions for various
ISDA netting agreements. The file is written in XML format.

Each netting set is defined within its own NettingSet node. All of these NettingSet
nodes are contained as children of a NettingSetDefinitions node.

There are two distinct cases to consider:

• An ISDA agreement which does not contain a Credit Support Annex (CSA).
• An ISDA agreement which does contain a CSA.

9.1 Uncollateralised Netting Set

If an ISDA agreement does not contain a Credit Support Annex, the portfolio
exposures are not eligible for collateralisation. In such a case the netting set can be
defined within the following XML template:

Listing 510: Uncollateralised netting set definition

<NettingSet>
<NettingSetId> </NettingSetId>
<ActiveCSAFlag> </ActiveCSAFlag>
<CSADetails></CSADetails>
</NettingSet>

The meanings of the various elements are as follows:

• NettingSetId: The unique identifier for the ISDA netting set.
Allowable values: Any string
• ActiveCSAFlag [Optional]: Boolean indicating whether the netting set is covered
by a Credit Support Annex. Allowable values: For uncollateralised netting sets
this flag should be False. If left blank or omitted, defaults to True.
• CSADetails [Optional]: Node containing as children details of the governing
Credit Support Annex. For uncollateralised netting sets, this node is not needed.

9.2 Collateralised Netting Set

If an ISDA agreement contains a Credit Support Annex, the portfolio exposures are
eligible for collateralisation. In such a case the netting set can be defined within the
following XML template:

746
Listing 511: Collateralised netting set definition

<NettingSet>
<NettingSetId> </NettingSetId>
<ActiveCSAFlag> </ActiveCSAFlag>
<CSADetails>
<Bilateral> </Bilateral>
<CSACurrency> </CSACurrency>
<Index> </Index>
<ThresholdPay> </ThresholdPay>
<ThresholdReceive> </ThresholdReceive>
<MinimumTransferAmountPay> </MinimumTransferAmountPay>
<MinimumTransferAmountReceive> </MinimumTransferAmountReceive>
<IndependentAmount>
<IndependentAmountHeld> </IndependentAmountHeld>
<IndependentAmountType> </IndependentAmountType>
</IndependentAmount>
<MarginingFrequency>
<CallFrequency> </CallFrequency>
<PostFrequency> </PostFrequency>
</MarginingFrequency>
<MarginPeriodOfRisk> </MarginPeriodOfRisk>
<CollateralCompoundingSpreadReceive>
</CollateralCompoundingSpreadReceive>
<CollateralCompoundingSpreadPay> </CollateralCompoundingSpreadPay>
<EligibleCollaterals>
<Currencies>
<Currency>USD</Currency>
<Currency>EUR</Currency>
<Currency>CHF</Currency>
<Currency>GBP</Currency>
<Currency>JPY</Currency>
<Currency>AUD</Currency>
</Currencies>
</EligibleCollaterals>
<ApplyInitialMargin>Y</ApplyInitialMargin>
<InitialMarginType>Bilateral</InitialMarginType>
<CalculateIMAmount>true</CalculateIMAmount>
<CalculateVMAmount>true</CalculateVMAmount>
</CSADetails>
</NettingSet>

CSADetails
The CSADetails node contains details of the Credit Support Annex which are relevant
for the purposes of exposure calculation. The meanings of the various elements are as
follows:
• Bilateral [Optional]: There are three possible values here:
– Bilateral : Both parties to the CSA are legally entitled to request collateral
to cover their counterparty credit risk exposure on the underlying portfolio.
– CallOnly: Only we are entitled to hold collateral; the counterparty has no
such entitlement.
– PostOnly: Only the counterparty is entitled to hold collateral; we have no

747
 such entitlement.
Defaults to Bilateral if left blank or omitted.
• CSACurrency [Optional]: A three-letter ISO code specifying the master currency
of the CSA. All monetary values specified within the CSA are assumed to be
denominated in this currency.
Allowable values: Any currency. See Table 32.
• Index [Optional]: The index is used to derive the fixing which is used for
compounding cash collateral in the master currency of the CSA.
Allowable values: An alphanumeric string of the form CCY-INDEX-TENOR.
CCY, INDEX and TENOR must be separated by dashes (-). CCY and INDEX
must be among the supported currency and index combinations. TENOR must
be an integer followed by D, W, M or Y, except for Overnight indices which do
not require a TENOR. See Table 36.
• ThresholdPay [Optional]: A threshold amount above which the counterparty is
entitled to request collateral to cover excess exposure.
Allowable values: Any number.
• ThresholdReceive [Optional]: A threshold amount above which we are entitled
to request collateral from the counterparty to cover excess exposure.
Allowable values: Any number.
• MinimumTransferAmountPay [Optional]: Any margin calls issued by the
counterparty must exceed this minimum transfer amount. If the collateral
shortfall is less than this amount, the counterparty is not entitled to request
margin.
Allowable values: Any number.
• MinimumTransferAmountReceive [Optional]: Any margin calls issued by us to
the counterparty must exceed this minimum transfer amount. If the collateral
shortfall is less than this amount, we are not entitled to request margin.
Allowable values: Any number.
• IndependentAmount [Optional]: This element contains two child nodes:
– IndependentAmountHeld: The netted sum of all independent amounts
covered by this ISDA agreement/CSA.
Allowable values: Any number. A negative number implies that the
counterparty holds the independent amount.
– IndependentAmountType: The nature of the independent amount as defined
within the Credit Support Annex.
Allowable values: The only supported value here is FIXED.
• MarginingFrequency: This element contains two child nodes:
– CallFrequency: The frequency with which we are entitled to request
additional margin from the counterparty (e.g. 1D, 2W, 1M ).
Allowable values:
– PostFrequency: The frequency with which the counterparty is entitled to
request additional margin from us.

748
 Allowable values: Any period definition (e.g. 2D, 1W, 1M, 1Y ).
This covers only the case where only one party has to post an independent
amount. In a future release this will be extended to the situation prescribed by
the Basel/IOSCO regulation (initial margin to be posted by both parties without
netting).
• MarginPeriodOfRisk: The length of time assumed necessary for closing out the
portfolio position after a default event.
Allowable values: Any period definition (e.g. 2D, 1W, 1M, 1Y ).
• CollateralCompoundingSpreadReceive: The spread over the O/N interest
accrual rate taken by the clearing house, when holding collateral.
Allowable values: Any number.
• CollateralCompoundingSpreadPay: The spread over the O/N interest accrual
rate taken by the clearing house, when collateral is held by the counterparty.
Allowable values: Any number.
• EligibleCollaterals: For now the only supported type of collateral is cash. If
the CSA specifies a set of currencies which are eligible as collateral, these can be
listed using Currency nodes.
Allowable values: Any currency. See Table 32.
• ApplyInitialMargin: Apply (dynamic) initial Margin in addition to variation
margin
Allowable values: Boolean node, the set of allowable values is given in Table 46.
• InitialMarginType There are three possible values here:
– Bilateral : Both parties to the CSA are legally entitled to request collateral
to cover their MPOR risk exposure on the underlying portfolio.
– CallOnly: Only we are entitled to hold collateral; the counterparty has no
such entitlement.
– PostOnly: Only the counterparty is entitled to hold collateral; we have no
such entitlement.
• CalculateIMAmount: Boolean indicating whether to calculate initial margin from
SIMM. For uncollateralised netting sets this flag will be ignored. This only
applies to the SA-CCR calculations.
Allowable values: Boolean node, the set of allowable values is given in Table 46.
• CalculateVMAmount: Boolean indicating whether to calculate variation margin
from the netting set NPV. For uncollateralised netting sets this flag will be
ignored. This only applies to the SA-CCR calculations.
Allowable values: Boolean node, the set of allowable values is given in Table 46.

749
10 Market Data
In this section we discuss the market data, which enters into the calibration of OREs
risk factor evolution models. Market data in the [Link] file is given in three
columns; Date, Quote and Quote value.
• Date: The as of date of the market quote value.
Allowable values: See Date in Table 30.
• Quote: A generic description that contains Instrument Type and Quote Type,
followed by instrument specific descriptions (see 10.1 ff.). The base of a quote
consists of InstType/QuoteType followed by instrument specific information
separated by slashes "/".
Allowable values for Instrument Types and Quote Types are given in Table 47.
• Quote Value: The market quote value in decimal form for the given quote on
the given as of date. Quote values are assumed to be mid-market.
Allowable values: Any real number.

750
 Market Data Parameter Allowable Values
Instrument Type ZERO, DISCOUNT, MM,
MM_FUTURE, FRA,
IMM_FRA, IR_SWAP,
BASIS_SWAP,
CC_BASIS_SWAP,
CDS, CDS_INDEX,
FX_SPOT, FX_FWD,
SWAPTION, CAPFLOOR,
FX_OPTION, HAZ-
ARD_RATE, RE-
COVERY_RATE,
ZC_INFLATIONSWAP,
YY_INFLATIONSWAP,
ZC_INFLATIONCAPFLOOR,
SEASONALITY, EQ-
UITY_SPOT, EQ-
UITY_FWD, EQ-
UITY_DIVIDEND, EQ-
UITY_OPTION, BOND,
INDEX_CDS_OPTION,
CPR, COMMODITY,
COMMODITY_FWD,
COMMODITY_OPTION
Quote Type BASIS_SPREAD,
CREDIT_SPREAD,
YIELD_SPREAD,
HAZARD_RATE,
RATE, RATIO, PRICE,
RATE_LNVOL,
RATE_NVOL,
RATE_SLNVOL,
BASE_CORRELATION,
SHIFT

Table 47: Allowable values for Instrument and Quote type market data.

An excerpt from a typical [Link] file is shown in Listing 512.

751
Listing 512: Excerpt of a market data file

2011-01-31 MM/RATE/EUR/0D/1D 0.013750

2011-01-31 MM/RATE/EUR/1D/1D 0.010500
2011-01-31 MM/RATE/EUR/2D/1D 0.010500
2011-01-31 MM/RATE/EUR/2D/1W 0.009500
2011-01-31 MM/RATE/EUR/2D/1M 0.008700
2011-01-31 MM/RATE/EUR/2D/2M 0.009100
2011-01-31 MM/RATE/EUR/2D/3M 0.010200
2011-01-31 MM/RATE/EUR/2D/4M 0.011000

2011-01-31 FRA/RATE/EUR/3M/3M 0.013080

2011-01-31 FRA/RATE/EUR/4M/3M 0.013890
2011-01-31 FRA/RATE/EUR/5M/3M 0.014630
2011-01-31 FRA/RATE/EUR/6M/3M 0.015230

2011-01-31 IR_SWAP/RATE/EUR/2D/3M/1Y 0.014400

2011-01-31 IR_SWAP/RATE/EUR/2D/3M/1Y3M 0.015400
2011-01-31 IR_SWAP/RATE/EUR/2D/3M/1Y6M 0.016500
2011-01-31 IR_SWAP/RATE/EUR/2D/3M/2Y 0.018675
2011-01-31 IR_SWAP/RATE/EUR/2D/3M/3Y 0.022030
2011-01-31 IR_SWAP/RATE/EUR/2D/3M/4Y 0.024670
2011-01-31 IR_SWAP/RATE/EUR/2D/3M/5Y 0.026870
2011-01-31 IR_SWAP/RATE/EUR/2D/3M/6Y 0.028700
2011-01-31 IR_SWAP/RATE/EUR/2D/3M/7Y 0.030125
2011-01-31 IR_SWAP/RATE/EUR/2D/3M/8Y 0.031340
2011-01-31 IR_SWAP/RATE/EUR/2D/3M/9Y 0.032450

10.1 Zero Rate

The instrument specific information to be captured for quotes representing Zero Rates
is shown in Table 48.

Property Allowable values Description

Instrument Type ZERO
Quote Type RATE, YIELD_SPREAD
Currency See Currency in Table 30 Currency of the Zero rate
CurveId A CCY concatenated Unique identifier for the yield curve as-
with a Tenor. Should sociated with the zero quote
match CurveIds in the
[Link] file
DayCounter See DayCount Convention The day count basis associated with the
in Table 35 zero quote
Tenor or ZeroDate Tenor: An integer followed Either a Tenor for tenor based zero
by D, W, M or Y, ZeroDate: quotes, or an explicit maturity date
See Date in Table 30 (ZeroDate)

Table 48: Zero Rate

Examples with a Tenor and with a ZeroDate:

• ZERO/RATE/USD/USD6M/A365F/6M

752
 • ZERO/RATE/USD/USD6M/A365F/12-05-2018

10.2 Discount Factor

The instrument specific information to be captured for quotes representing Discount
Factors is shown in Table 49.

Property Allowable values Description

Instrument Type DISCOUNT
Quote Type RATE
Currency See Currency in Table 30 Currency of the Discount rate
CurveId A CCY concatenated Unique identifier for the yield curve as-
with a Tenor. Should sociated with the discount quote
match CurveIds in the
[Link] file
Term or Discount- Term: An integer followed Either a Term is used to determine the
Date by D, W, M or Y, Discount- maturity date, or an explicit maturity
Date: See Date in Table 30 date (Discount Date) is given.

Table 49: Discount Rate

If a Term is given in the last element of the quote, it is converted to a maturity date
using the calendar, specified in the conventions. Bear in mind, only zero conventions
(see Listing 253) can be used for the discount factor instruments.

Examples with a Term and with a DiscountDate:

• DISCOUNT/RATE/EUR/EUR3M/3Y
• DISCOUNT/RATE/EUR/EUR3M/12-05-2018

10.3 FX Spot Rate

Property Allowable values Description

Instrument FX
Type
Quote Type RATE
Unit currency See Currency in Unit/Source currency
Table 30
Target currency See Currency in Target currency
Table 30

Table 50: FX Spot Rate

Example:
• FX/RATE/EUR/USD

753
10.4 FX Forward Rate
An FX Forward quote is expected in either a “forward points” quotation, or an
“outright” quotation.
The forward points convention is given by:
FX Forward − FX Spot
Forward Points =
Conversion Factor
with conversion factor set to 1.

Property Allowable values Description

Instrument Type FX_FWD
Quote Type RATE
Unit currency See Currency in Unit/Source currency
Table 30
Target currency See Currency in Target currency
Table 30
Term An integer followed Period from today to maturity
by D, W, M or Y.

Table 51: FX Forward Rate

The forward outright is given by:

Forward Outright = FX Spot + Forward Points × Conversion Factor

with conversion factor set to 1.

Property Allowable values Description

Instrument Type FX_FWD
Quote Type PRICE
Unit currency See Currency in Unit/Source currency
Table 30
Target currency See Currency in Target currency
Table 30
Term An integer followed Period from today to maturity
by D, W, M or Y.

Table 52: FX Forward Rate

Example:
• FXFWD/RATE/EUR/USD/1M
• FXFWD/PRICE/EUR/USD/3M

754
10.5 Deposit Rate

Property Allowable values Description

Instrument MM
Type
Quote Type RATE
Currency See Currency in Currency of the Deposit rate
Table 30
IndexName Optional, any Generally used to differentiate money
string market rates referencing different inter-
est rate indices with the same tenor
Forward start An integer followed Period from today to start
by D, W, M or Y.
Term An integer followed Period from start to maturity
by D, W, M or Y.

Table 53: Deposit Rate

Deposits are usually quoted as ON (Overnight), TN (Tomorrow Next), SN (Spot

Next), SW (Spot Week), 3W (3 Weeks), 6M (6 Months), etc.
Forward start for ON is today (i.e. forward start = 0D), for TN tomorrow (forward
start = 1D), for SN two days from today (forward start = 2D). For longer term
Deposits, forward start is derived from conventions, see 7.12, and is between 0D and
2D, i.e. "spot days" are between 0 and 2.

Example:
• MM/RATE/EUR/2D/3M

10.6 FRA Rate

Property Allowable values Description
Instrument Type FRA
Quote Type RATE
Currency See Currency in Currency of the FRA rate
Table 30
Forward start An integer followed Period from today to start
by D, W, M or Y
Term An integer followed Period from start to maturity
by D, W, M or Y

Table 54: FRA Rate

FRAs are typically quoted as e.g. 6x9 which means forward start 6M from today,
maturity 9M from today, with appropriate adjustment of dates.

IMM FRA quotes are represented as follows.

755
 Property Allowable values Description
Instrument Type IMM_FRA
Quote Type RATE
Currency See Currency in Currency of the FRA rate
Table 30
Start An integer Number of IMM dates from today to
start
End An integer Number of IMM dates from today to
maturity

Table 55: IMM FRA Rate

Example:
• FRA/RATE/EUR/9M/3M
• IMM_FRA/RATE/EUR/2/3

10.7 Money Market Futures Price

Property Allowable values Description

Instrument MM_FUTURE
Type
Quote Type PRICE
Currency See Currency in Table 30 Currency of the MM Future price
Expiry Alphanumeric string of Expiry month and year
the form YYYY-MM
Contract String Contract name
Term An integer followed by D, Underlying Term
W, M or Y

Table 56: Money Market Futures Price

Expiry month is quoted here as YYYY-MM. The exact expiry date follows from a date
rule defined in the future conventions, see 7.12.3.

Example:
• MM_FUTURE/PRICE/EUR/2018-06/LIF3ME/3M

756
10.8 Overnight Index Futures Price

Property Allowable values Description

Instrument OI_FUTURE
Type
Quote Type PRICE
Currency See Currency in Table 30 Currency of the Overnight Index Fu-
ture price
Expiry Alphanumeric string of Expiry month and year
the form YYYY-MM
Contract String Contract name
Term An integer followed by M Underlying Term in months or years
or Y

Table 57: Overnight Index Futures Price

Expiry month is quoted here as YYYY-MM. The exact expiry date follows from a date
rule defined in the future conventions, see 7.12.3.

Example: Three Months SOFR Futures (DEC 2019):

• OI_FUTURE/PRICE/USD/2019-12/CME:SR3Z2019/3M

10.9 Swap Rate

Property Allowable values Description

Instrument IR_SWAP
Type
Quote Type RATE
Currency See Currency in Currency of the Swap rate
Table 30
IndexName Optional, any Generally used to differentiate swaps
string referencing different interest rate in-
dices with the same tenor
Forward start An integer followed Generic period from today to start
by D, W, M or Y
Tenor An integer followed Underlying index period
by D, W, M or Y
Term An integer followed Swap length from start to maturity
by D, W, M or Y

Table 58: Swap Rate

757
 Property Allowable values Description
Instrument IR_SWAP
Type
Quote Type RATE
Currency See Currency in Currency of the Swap rate
Table 30
IndexName Optional, any Generally used to differentiate swaps
string referencing different interest rate in-
dices with the same tenor
Start Date A valid date
Tenor An integer followed Underlying index period
by D, W, M or Y
End Date A valid date

Table 59: Swap Rate with Start and End Date

Forward start for the non-dated variant is usually not quoted, but needs to be derived
from conventions.

Example:
• IR_SWAP/RATE/EUR/2D/6M/10Y
• IR_SWAP/RATE/GBP/20230921/1D/20231102

10.10 Basis Swap Spread

Property Allowable values Description
Instrument Type BASIS_SWAP
Quote Type BASIS_SPREAD
Flat tenor An integer followed Zero spread leg’s index tenor
by D, W, M or Y
Tenor An integer followed Non-zero spread leg’s index tenor
by D, W, M or Y
Currency See Currency in Ta- Currency of the basis swap spread
ble 30
Optional Identifier String Basis swap name
Term An integer followed Swap length from start to maturity
by D, W, M or Y

Table 60: Basis Swap Spread

Examples:
• BASIS_SWAP/BASIS_SPREAD/6M/3M/CHF/10Y
• BASIS_SWAP/BASIS_SPREAD/3M/1D/USD/2Y
• BASIS_SWAP/BASIS_SPREAD/3M/1D/USD/LIBOR_PRIME/2Y
• BASIS_SWAP/BASIS_SPREAD/3M/1D/USD/LIBOR_FEDFUNDS/2Y

758
10.11 Cross Currency Basis Swap Spread
Property Allowable values Description
Instrument CC_BASIS_SWAP
Type
Quote Type BASIS_SPREAD
Flat currency See Currency in Currency for zero spread leg
Table 30
Flat tenor An integer followed Zero spread leg’s index tenor
by D, W, M or Y
Currency See Currency in Currency for non-zero spread leg
Table 30
Tenor An integer followed Non-zero spread leg’s index tenor
by D, W, M or Y
Term An integer followed Swap length from start to maturity
by D, W, M or Y

Table 61: Cross Currency Basis Swap Spread

Example:
• CC_BASIS_SWAP/BASIS_SPREAD/USD/3M/JPY/6M/10Y

10.12 CDS Spread

Property Allowable values Description
Instrument CDS
Type
Quote Type CREDIT_SPREAD or
CONV_CREDIT_SPREAD
Entity String The CDS reference entity name
Tier String The CDS tier
DocClause String Optional, the CDS doc clause
Currency See Currency in The CDS currency
Table 30
Term A valid tenor string The CDS tenor
RunningSpread A number The CDS running coupon in bps e.g.
100 for 0.01

Table 62: CDS spread quote

There are two possible quote types to allow for the presence of two CDS spread types
in the market data. In particular, there is typically a conventional CDS spread and a
par CDS spread quoted in the market. The quote type distinction here would allow the
conventional spreads to be stored with quote type set to CONV_CREDIT_SPREAD and the
par spreads to be stored with quote type set to CREDIT_SPREAD. As noted in the table
above, the CDS documentation clause and CDS running spread is optional. The
following list shows valid CDS spread quote examples.

759
 • CDS/CREDIT_SPREAD/JPM/SNRFOR/USD/5Y
• CDS/CREDIT_SPREAD/JPM/SNRFOR/USD/5Y/100
• CDS/CREDIT_SPREAD/JPM/SNRFOR/USD/XR14/5Y
• CDS/CREDIT_SPREAD/JPM/SNRFOR/USD/XR14/5Y/100
• CDS/CREDIT_SPREAD/RBS/SUBLT2/EUR/MR14/10Y
• CDS/CREDIT_SPREAD/RBS/SUBLT2/EUR/MR14/10Y/500
• CDS/CREDIT_SPREAD/RBS/SUBLT2/EUR/1Y
• CDS/CREDIT_SPREAD/RBS/SUBLT2/EUR/1Y/500

10.13 CDS Upfront Price

Property Allowable values Description

Instrument CDS
Type
Quote Type PRICE
Entity String The CDS reference entity name
Tier String The CDS tier
Currency See Currency in The CDS currency
Table 30
DocClause String Optional, the CDS doc clause
Term A valid tenor string The CDS tenor
RunningSpread A number The CDS running coupon in bps e.g.
100 for 0.01

Table 63: CDS upfront price quote

As noted in the table above, the CDS documentation clause and CDS running spread is
optional. Note that if the running spread is omitted from the CDS upfront price quote
string, it should be included in any default curve configuration that uses those quotes.
In other words, to bootstrap a default curve from CDS price quotes, the contractual
running spread needs to be provided in either the quote string or in the default curve
configuration. If both are provided, the running spread in the quote string takes
precedence. The following list shows valid CDS upfront price quote examples.
• CDS/PRICE/JPM/SNRFOR/USD/5Y
• CDS/PRICE/JPM/SNRFOR/USD/5Y/100
• CDS/PRICE/JPM/SNRFOR/USD/XR14/5Y
• CDS/PRICE/JPM/SNRFOR/USD/XR14/5Y/100
• CDS/PRICE/RBS/SUBLT2/EUR/MR14/10Y
• CDS/PRICE/RBS/SUBLT2/EUR/MR14/10Y/500
• CDS/PRICE/RBS/SUBLT2/EUR/1Y

760
 • CDS/PRICE/RBS/SUBLT2/EUR/1Y/500

10.14 CDS Recovery Rate

Property Allowable values Description

Instrument RECOVERY_RATE
Type
Quote Type RATE
Entity String The CDS reference entity name
Tier String The CDS tier
Currency See Currency in The CDS currency
Table 30
DocClause String Optional, the CDS doc clause

Table 64: CDS Recovery Rate

As noted in the table above, the CDS documentation clause is optional. The following
list shows valid recovery rate quote examples.
• RECOVERY_RATE/RATE/JPM/SNRFOR/USD
• RECOVERY_RATE/RATE/JPM/SNRFOR/USD/XR14
• RECOVERY_RATE/RATE/RBS/SUBLT2/EUR/MR14
• RECOVERY_RATE/RATE/RBS/SUBLT2/EUR

10.15 CDS Option Implied Volatility

A CDS option implied volatility quote can take any one of the following four forms:
1. INDEX_CDS_OPTION/RATE_LNVOL/[NAME]/[EXPIRY]
2. INDEX_CDS_OPTION/RATE_LNVOL/[NAME]/[EXPIRY]/[STRIKE]
3. INDEX_CDS_OPTION/RATE_LNVOL/[NAME]/[TERM]/[EXPIRY]
4. INDEX_CDS_OPTION/RATE_LNVOL/[NAME]/[TERM]/[EXPIRY]/[STRIKE]
The terms in the quote string have the following interpretations:
• The [NAME] is the name of the CDS reference entity or index CDS.
• The [EXPIRY] is the expiry of the CDS option and may be a tenor or an explicit
date.
• The [TERM] is optional and gives the term of the underlying CDS or index CDS.
This should be a tenor e.g. 3Y, 5Y, etc.
• The [STRIKE] is optional and gives the strike of the CDS or index CDS option.

761
10.16 Security Recovery Rate
Bond recovery rates can also be specified per security. This requires only one key, the
security ID, no need to specify a seniority or currency as for CDS:

Property Allowable values Description

Instrument RECOVERY_RATE
Type
Quote Type RATE
ID String Security ID

Table 65: Security Recovery Rate

Example:
• RECOVERY_RATE/RATE/SECURITY_1

10.17 Hazard Rate (Instantaneous Probability of Default)

This allows to directly pass hazard rates as instantaneous probabilities of default.

Property Allowable values Description

Instrument HAZARD_RATE
Type
Quote Type RATE
Issuer String Issuer name
Seniority String Seniority status
Currency See Currency in Hazard rate currency
Table 30
Term An integer followed Generic period from start to maturity
by D, W, M or Y

Table 66: Hazard Rate

Example:
• HAZARD_RATE/RATE/CPTY_A/SR/USD/30Y
• HAZARD_RATE/RATE/CPTY_C/SR/EUR/0Y

762
10.18 FX Option Implied Volatility

Property Allowable values Description

Instrument FX_OPTION
Type
Quote Type RATE_LNVOL
Unit currency See Currency in Unit/Source currency
Table 30
Target currency See Currency in Target currency
Table 30
Expiry An integer followed Period from today to expiry
by D, W, M or Y
Strike ATM, RR, BF ATM (Straddle), RR (Risk Reversal),
BF (Butterfly)

Table 67: FX Option Implied Volatility

Volatilities are quoted in terms of strategies - at-the-money straddle, risk reversal and
butterfly.

Example:
• FX_OPTION/RATE_LNVOL/EUR/USD/3M/ATM

763
10.19 Cap Floor Implied Volatility
Property Allowable values Description
Instrument CAPFLOOR
Type
Quote Type RATE_LNVOL, Lognormal quoted volatility, normal
RATE_NVOL, quoted volatility, shifted lognormal
RATE_SLNVOL, quoted volatility, shift quote, premium
SHIFT, PRICE quote.
Currency See Currency in Currency of the cap floor quote.
Table 30
Index Name A string (optional) An interest rate index name
giving the index underlying the cap
floor quotes. See Table 36.
Term A valid tenor string Period from start to cap or floor matu-
rity.
Index Tenor A valid tenor string Underlying index tenor e.g. 3M for
EUR-EURIBOR-3M.
ATM 1 or 0 True, i.e. 1, for an ATM quote and
false, i.e. 0, for a strike quote.
Relative 1 or 0 Should be set to 1 for a quote relative
to ATM and to 0 for an absolute strike
quote.
Strike Real number Strike of cap or floor. Should be set to
0 for an ATM quote.
Option Style C or F (optional) Valid for premium quotes
only, indicates whether the datum is a
cap or floor quote respectively.

Table 68: Cap floor implied volatility quote

An index name should be used where a currency has more than one index of a given
tenor with an options surface. It must match IborIndex in its corresponding
CapFloorVolatility configuration, see section 7.8.6.
If a cap floor shift quote needs to be provided, i.e. in the case of a shifted lognormal
surface, the quote is of the form CAPFLOOR/SHIFT/Currency/Index Tenor where the
meaning of Currency and Index Tenor are given in Table 68.
We have the following examples of cap floor implied volatility, shift, and premium
quotes:
• CAPFLOOR/RATE_LNVOL/EUR/10Y/6M/1/1/0: 10Y ATM cap floor implied
lognormal volatility quote where the index tenor is 6M.
• CAPFLOOR/RATE_LNVOL/EUR/10Y/6M/0/0/0.035: 10Y 3.5% strike cap floor
implied lognormal volatility quote where the index tenor is 6M.
• CAPFLOOR/RATE_SLNVOL/EUR/EURIBOR/5Y/6M/0/0/0.03: 5Y 3% strike cap floor
implied shifted lognormal volatility quote where the underlying rate is the
EUR-EURIBOR-6M.

764
 • CAPFLOOR/SHIFT/EUR/EURIBOR/6M: Strike shift convention corresponding to
shifted lognormal implied capfloor volatility quotes where the underlying rate is
the EUR-EURIBOR-6M.
• CAPFLOOR/PRICE/EUR/EURIBOR/5Y/6M/0/0/0.03/C: 5Y 3% strike cap floor
premium quote where the underlying rate is the EUR-EURIBOR-6M.

10.20 Swaption Implied Volatility

Property Allowable values Description
Instrument SWAPTION
Type
Quote Type RATE_LNVOL, Lognormal quoted volatility, Normal
RATE_NVOL, quoted volatility, shifted lognormal
RATE_SLNVOL, quoted volatility, shift, premium quote.
SHIFT, PRICE
Currency See Currency in Currency of the Swaption volatility
Table 30
Quote Tag A string (optional) A tag to differentiate differ-
ent sets of swaption data in a currency.
See note below.
Expiry An integer followed Period from start to expiry
by D, W, M or Y
Term An integer followed Underlying Swap term
by D, W, M or Y
Dimension Smile, ATM Whether volatility quote is a Smile or
ATM
Strike Real number (not required for ATM), deviation from
the ATM strike. Note that trailing 0s
are not ignored.
Option Style P or R (optional) Valid for premium quotes
only, indicates whether the datum rep-
resents a payer or receiver swaption
premium respectively.

Table 69: Swaption Implied Volatility

A quote tag should be used where a currency has more than one index with a swaption
surface. It must match QuoteTag in its corresponding SwaptionVolatility
configuration, see section 7.8.5.
Note: The volatility quote is expected to be an absolute volatility, and not the
deviation from the at-the-money volatility (the latter is e.g. the quotation convention
used by BGC partners).
If a swaption shift quote needs to be provided, i.e. in the case of a shifted lognormal
surface, the quote is of the form SWAPTION/SHIFT/Currency/Term where the meaning
of Currency and Term are given in Table 69.

Examples:

765
 • SWAPTION/RATE_LNVOL/EUR/5Y/10Y/ATM (absolute ATM vol quote)
• SWAPTION/RATE_LNVOL/EUR/5Y/10Y/Smile/0.0050 (absolute vol quote
for ATM strike plus 50bp)

10.21 Equity Spot Price

Property Allowable values Description

Instrument EQUITY_SPOT
Type
Quote Type PRICE
Name String Identifying name of the equity
Currency See Currency in Currency of the equity
Table 30

Table 70: Equity Spot Price

10.22 Equity Forward Price

Property Allowable values Description

Instrument EQUITY_FWD
Type
Quote Type PRICE
Name String Identifying name of the equity
Currency See Currency in Currency of the equity
Table 30
Maturity Date string, or in- Maturity of the forward quote
teger followed by D,
W, M or Y

Table 71: Equity Forward Price

Examples:
• EQUITY_FWD/PRICE/SP5/USD/2016-06-16
• EQUITY_FWD/PRICE/SP5/USD/2Y

766
10.23 Equity Dividend Yield

Property Allowable values Description

Instrument EQUITY_DIVIDEND
Type
Quote Type RATE
Name String Identifying name of the equity
Currency See Currency in Currency of the equity
Table 30
Maturity Date string, or in- Maturity of the forward quote
teger followed by D,
W, M or Y

Table 72: Equity Dividend Yield Rate

Examples:
• EQUITY_DIVIDEND/RATE/SP5/USD/2016-06-16
• EQUITY_DIVIDEND/RATE/SP5/USD/2Y

10.24 Equity Option Implied Volatility

Property Allowable values Description

Instrument EQUITY_OPTION
Type
Quote Type RATE_LNVOL
Name String Identifying name of the eq-
uity
Currency See Currency in Table 30 Currency of the equity
Expiry Date string, or integer followed Maturity of the forward
by D, W, M or Y quote
Strike ATM/AtmSpot (= ATM), strike
ATM/AtmFwd (=ATMF),
MNY/[Spot|Fwd]/1.2 where
1.2 is the moneyness level, or
a Real for an absolute strike
CallPut C for Call, P for Put Optional Call/Put flag (de-
faults to Call)

Table 73: Equity Option Implied Volatility

Volatilities are quoted as a function of strike price - either at-the-money spot or

forward, a moneyness level or else a specified real number, corresponding to the
absolute strike value. Only log-normal implied volatilities (RATE_LNVOL) are supported.
If K is the absolute strike, S the spot, F the forward and m the moneyness level, we
have K = Sm if spot moneyness and K = F m if forward moneyness is specified.

767
Example:
• EQUITY_OPTION/RATE_LNVOL/SP5/USD/6M/ATMF
• EQUITY_OPTION/RATE_LNVOL/SP5/USD/2018-06-30/ATMF
• EQUITY_OPTION/RATE_LNVOL/SP5/USD/6M/MNY/Fwd/1.2

10.25 Equity Option Premium

Property Allowable values Description
Instrument EQUITY_OPTION
Type
Quote Type PRICE
Name String Identifying name of the eq-
uity
Currency See Currency in Table 30 Currency of the equity
Expiry Date string, or integer followed Maturity of the forward
by D, W, M or Y quote
Strike ATM/AtmSpot (= ATM), strike
ATM/AtmFwd (=ATMF) or a
Real for an absolute strike
CallPut C for Call, P for Put Optional Call/Put flag (de-
faults to Call)

Table 74: Equity Option Premium

Premiums are quoted as a function of strike price - either at-the-money spot or

forward or else a specified real number, corresponding to the absolute strike value.

Example:
• EQUITY_OPTION/PRICE/SP5/USD/6M/ATMF
• EQUITY_OPTION/PRICE/SP5/USD/2018-06-30/2000
• EQUITY_OPTION/PRICE/SP5/USD/2018-06-30/2000/C

10.26 Commodity Spot Price

Property Allowable values Description
Instrument COMMODITY
Type
Quote Type PRICE
Name String Identifying name of the commodity
Currency See Currency in Currency of the commodity
Table 30

Table 75: Commodity Spot Price

Examples:

768
 • COMMODITY/PRICE/PM:XAUUSD/USD

10.27 Commodity Forward Price

Property Allowable values Description

Instrument COMMODITY_FWD
Type
Quote Type PRICE
Name String Identifying name of the commodity
Currency See Currency in Table 30 Currency of the commodity
Maturity Date string, or integer Maturity of the forward quote
followed by D, W, M or
Y

Table 76: Commodity Forward Price

Examples:
• COMMODITY_FWD/PRICE/NYMEX:CL/USD/2030-11-20

10.28 Commodity Option Implied Volatility

Property Allowable values Description

Instrument Type COMMODITY_OPTION
Quote Type RATE_LNVOL
Name String Identifying name of the commodity
Currency See Currency in Table 30 Currency of the commodity
Expiry Date string, or integer followed Expiry of the volatility quote, for continu-
by D, W, M or Y or continua- ation notation c1 indicates the next expiry,
tion notation c1, c2, etc c2 the one after that, etc.
Vol Quote Type, DEL, ATM or MNY DEL is for delta quotes, i.e. the volatility is
or Absolute Strike or a Real for absolute strikes for a call or put option with a given delta.
ATM is for At-The-Money volatility quotes.
MNY is for volatility smile quotes for given
relative moneyness levels.
Each Vol Quote Type is described further
in sub-tables below.
Note that instead of a Vol Quote Type, an
absolute strike level can be entered

Table 77: Commodity Option Implied Volatility - Root table

769
 Property Allowable values Description
Vol Quote Type DEL, ATM or MNY In this table it is assumed DEL is chosen.
Delta Conven- Fwd or Spot Delta forward or spot quote
tion
Option Type Call or Put Option type for the delta quote
Delta a positive Real number, Delta, e.g. a delta of 0.40 for a Call means
typically between 0.1 that if the underlying commodity price
and 0.45 increases by 1 unit, the call option price
increases by 0.40 units

Table 78: Commodity Option Implied Volatility - Delta Quotes Table

Property Allowable values Description

Vol Quote Type DEL, ATM or MNY In this table it is assumed ATM is chosen.
Atm Convention AtmFwd, AtmSpot, Atm Forward or Atm Spot quote, to be used stand-
or AtmDeltaNeutral alone, or when the smile is given by moneyness
(MNY) quotes.
The Delta Neutral Atm to be used as standalone,
or when the smile is given by delta (DEL) quotes.

Note that when AtmFwd or AtmSpot are used,

the string stops here, no further entries "tokens"
are required
Atm Quote Type DEL When AtmDeltaNeutral is used, the quote type
must be set to Delta (DEL)
Atm Delta Con- Fwd or Spot When AtmDeltaNeutral is used, the Atm delta
vention quote can be a Spot or Forward quote.

Table 79: Commodity Option Implied Volatility - ATM Quotes Table

Property Allowable values Description

Vol Quote Type DEL, ATM or MNY In this table it is assumed MNY is chosen.
Moneyness Type Fwd or Spot Moneyness Forward or Spot quote
Moneyness a positive Real num- The relative moneyness expressed in decimal form,
ber relative to the AtmSpot or the AtmFwd strikes

Table 80: Commodity Option Implied Volatility - Moneyness Quotes Table

Volatilities are quoted:

• as a function of the delta - either the delta neutral at-the-money spot or forward,
or for a call or put option with a given delta, or
• as a function of strike price - either at-the-money spot or forward, or a relative
strike moneyness level, or else
• as a specified real number, corresponding to the absolute strike value.

770
Only log-normal implied commodity volatilities (RATE_LNVOL) are supported.
For strike quoted volatilities, If K is the absolute strike, S the spot, F the forward and
m the moneyness level, we have K = Sm if spot moneyness and K = F m if forward
moneyness is specified.

Example of delta forward quotes:

COMMODITY_OPTION/RATE_LNVOL/ICE:B/USD/c9/DEL/Fwd/Put/0.40
COMMODITY_OPTION/RATE_LNVOL/ICE:B/USD/c9/DEL/Fwd/Put/0.45
COMMODITY_OPTION/RATE_LNVOL/ICE:B/USD/c9/ATM/AtmDeltaNeutral/DEL/Fwd
COMMODITY_OPTION/RATE_LNVOL/ICE:B/USD/c9/DEL/Fwd/Call/0.45
COMMODITY_OPTION/RATE_LNVOL/ICE:B/USD/c9/DEL/Fwd/Call/0.40
Example of delta spot quotes:
COMMODITY_OPTION/RATE_LNVOL/PM:XAGEUR/EUR/1Y/DEL/Spot/Put/0.35
COMMODITY_OPTION/RATE_LNVOL/PM:XAGEUR/EUR/1Y/DEL/Spot/Put/0.45
COMMODITY_OPTION/RATE_LNVOL/PM:XAGEUR/EUR/1Y/ATM/AtmDeltaNeutral/DEL
/Spot
COMMODITY_OPTION/RATE_LNVOL/PM:XAGEUR/EUR/1Y/DEL/Spot/Call/0.25
COMMODITY_OPTION/RATE_LNVOL/PM:XAGEUR/EUR/1Y/DEL/Spot/Call/0.15
Example of forward strike quotes with relative moneyness:
COMMODITY_OPTION/RATE_LNVOL/NYMEX:AA5/USD/c11/MNY/Fwd/1.40
COMMODITY_OPTION/RATE_LNVOL/NYMEX:AA5/USD/c11/MNY/Fwd/1.20
COMMODITY_OPTION/RATE_LNVOL/NYMEX:AA5/USD/c11/ATM/AtmFwd
COMMODITY_OPTION/RATE_LNVOL/NYMEX:AA5/USD/c11/MNY/Fwd/0.80
COMMODITY_OPTION/RATE_LNVOL/NYMEX:AA5/USD/c11/MNY/Fwd/0.60
Example of absolute moneyness quotes:
COMMODITY_OPTION/RATE_LNVOL/PM:XAUUSD/USD/c12/1600
COMMODITY_OPTION/RATE_LNVOL/PM:XAUUSD//USD/c12/1700
COMMODITY_OPTION/RATE_LNVOL/PM:XAUUSD//USD/c12/1800
COMMODITY_OPTION/RATE_LNVOL/PM:XAUUSD//USD/c12/1900
COMMODITY_OPTION/RATE_LNVOL/PM:XAUUSD//USD/c12/2000

10.29 Zero Coupon Inflation Swap Rate

Property Allowable values Description

Instrument ZC_INFLATIONSWAP
Type
Quote Type RATE
Index String Identifying name of the inflation index
Maturity integer followed by Maturity of the swap quote
D, W, M or Y

Table 81: Zero Coupon Inflation Swap Rate

Examples:

771
 • ZC_INFLATIONSWAP/RATE/EUHICPXT/1Y
• ZC_INFLATIONSWAP/RATE/EUHICPXT/2Y
Examples for inflation index names include EUHICP, EUHICPXT, FRHICP, FRCPI,
UKRPI, USCPI, ZACPI, BEHICP, AUCPI.

10.30 Year on Year Inflation Swap Rate

Property Allowable values Description

Instrument YY_INFLATIONSWAP
Type
Quote Type RATE
Index String Identifying name of the inflation index
Maturity integer followed by Maturity of the swap quote
D, W, M or Y

Table 82: Year on Year Inflation Swap Rate

Examples:
• YY_INFLATIONSWAP/RATE/EUHICPXT/1Y
• YY_INFLATIONSWAP/RATE/EUHICPXT/2Y
Examples for inflation index names include EUHICP, EUHICPXT, FRHICP, FRCPI,
UKRPI, USCPI, ZACPI, BEHICP.

10.31 Zero Coupon Inflation Cap Floor Price

Property Allowable values Description

Instrument ZC_INFLATIONCAPFLOOR
Type
Quote Type PRICE
Index String Identifying name of the inflation index
Maturity integer followed by Maturity of the swap quote
D, W, M or Y
Cap/Floor C or F Cap or Floor tag
Strike Real number Strike

Table 83: Zero Coupon Inflation Cap Floor Price

Examples:
• ZC_INFLATIONCAPFLOOR/PRICE/EUHICPXT/1Y/F/-0.02
• ZC_INFLATIONCAPFLOOR/PRICE/EUHICPXT/2Y/C/0.01
Examples for inflation index names include EUHICP, EUHICPXT, FRHICP, FRCPI,
UKRPI, USCPI, ZACPI, BEHICP.

772
10.32 Inflation Seasonality Correction Factors

Property Allowable values Description

Instrument SEASONALITY
Type
Quote Type RATE
Type MULT Type of the correction factor
Index String Identifying name of the inflation index
Month JAN, ..., DEC Month of the correction factor

Table 84: Inflation Seasonality Correction Factors

Examples:
• SEASONALITY/RATE/MULT/EUHICPXT/JAN
• SEASONALITY/RATE/MULT/EUHICPXT/FEB
• SEASONALITY/RATE/MULT/EUHICPXT/NOV
Examples for inflation index names include EUHICP, EUHICPXT, FRHICP, FRCPI,
UKRPI, USCPI, ZACPI, BEHICP.

10.33 Bond Yield Spreads

Property Allowable values Description

Instrument BOND
Type
Quote Type YIELD_SPREAD
Name String Identifying name of the bond

Table 85: Bond Yield Spreads

This quote provides the spread for a specified bond over the benchmark rate.

Examples:
• BOND/YIELD_SPREAD/SECURITY_1

10.34 Bond Prices

Property Allowable values Description
Instrument BOND
Type
Quote Type PRICE
Name String Identifying name of the bond

Table 86: Bond Prices

773
This quote provides the clean price for a specified bond in units.

Examples:
• BOND/PRICE/SECURITY_1

10.35 Base Correlations

Property Allowable values Description
Instrument CDS_INDEX
Type
Quote Type BASE_CORRELATION
Index String CDS index name
Term Period (e.g. 5Y) Term on the base correlation curve, the
curve is flat if quotes for only one term
are provided
DetachmentPoint Real in (0...1) Detachment point of the equity tranche
this quote refers to

Table 87: Base correlation quotes

This quote provides the base correlation for a CDS index’ equity tranche with the
specified detachment point. Example:

• CDS_INDEX/BASE_CORRELATION/2I65BYBD6/5Y/0.03
Typically there are several base correlation quotes per term for several detachment
points such as 0.03, 0.07, 0.15.

10.36 Correlations
Property Allowable values Description
Instrument Correlation
Type
Quote Type RATE or PRICE
Index1 String Identifying name of the first index
Index2 String Identifying name of the second index

Table 88: Correlation quotes

This quote either provides the correlation between two indices, in which case Quote
Type is RATE, or a premium that can be used to bootstrap the correlations, in which
case Quote Type is Price. Currently only CMS Spread correlations are supported, in
this case the Price quote is the price of a CMS Spread Cap.

Examples:
• CORRELATION/RATE/INDEX1/INDEX2/1Y/ATM

774
10.37 Conditional Prepayment Rates

Property Allowable values Description

Instrument CPR
Type
Quote Type RATE
Name String Identifying name of the bond

Table 89: Conditional Prepayment Rates

This quote provides the spread for a specified bond over the benchmark rate.

Examples:
• CPR/RATE/SECURITY_1

775
11 Fixing History
Historical fixings data in the [Link] file is given in three columns; Index Name,
Fixing Date and Index value. Columns are separated by semicolons ";" or blanks.
Fixings are used in cases where the current coupon of a trade has been fixed in the
past, or other path dependent features.
• Fixing Date: The date of the fixing.
Allowable values: See Date in Table 30.
• Index Name: The name of the Index.
Allowable values are given in Table 90.
• Index Value: The index value for the given fixing date.
Allowable values: Any real number (not expressed as a percentage or basis
points).
An excerpt of a fixings file is shown in Listing 513. Note that alternative index name
formats are used (Table 90).

Listing 513: Excerpt of a fixings file

20150202 EUR-EONIA -0.00024

20150202 EUR-EURIBOR-1M 0.00003
20150202 EUR-EURIBOR-1W -0.00022
20150202 EUR-EURIBOR-2W -0.00017
20150202 EUR-EURIBOR-3M 0.00055
20150202 EUR-EURIBOR-3M 0.00055
20150202 EUR-EURIBOR-6M 0.00134
20150202 EUR-EURIBOR-6M 0.00271
20150202 GBP-LIBOR-12M 0.009565
20150202 GBP-LIBOR-1M 0.0050381
20150202 GBP-LIBOR-1W 0.0047938
20150202 GBP-LIBOR-3M 0.0056338
20150202 GBP-LIBOR-6M 0.006825
20150202 JPY-LIBOR-12M 0.0026471
20150202 JPY-LIBOR-1M 0.0007143
20150202 JPY-LIBOR-1W 0.0004357
20150202 JPY-LIBOR-3M 0.0010429
20150202 JPY-LIBOR-6M 0.0014357
20150202 USD-LIBOR-12M 0.006194
20150202 USD-LIBOR-1M 0.001695
20150202 USD-LIBOR-1W 0.00136
20150202 USD-CMS-10Y 0.01500
20150202 EUR-CMS-20Y 0.01700
20150202 FX-ECB-EUR-USD 1.0919
20150801 FRHICP 100.36

776
IR Index of form CCY-INDEX-TENOR:
Index Component Allowable Values
EUR-EONIA
EUR-EURIBOR
EUR-LIBOR
USD-FedFunds
USD-Prime
USD-LIBOR
GBP-SONIA
GBP-LIBOR
JPY-TONAR
JPY-LIBOR
CHF-LIBOR
CHF-TOIS
AUD-LIBOR
AUD-BBSW
CAD-CDOR
CAD-BA
CAD-LIBOR
SEK-STIBOR
SEK-STINA
SEK-LIBOR
DKK-LIBOR
DKK-CIBOR
DKK-CITA
CCY-INDEX
SGD-SIBOR
HKD-HIBOR
CZK-PRIBOR
HUF-BUBOR
IDR-IDRFIX
INR-MIFOR
JPY-TIBOR
JPY-EYTIBOR
KRW-KORIBOR
MXN-TIIE
MYR-KLIBOR
NOK-NIBOR
NZD-BKBM
PLN-WIBOR
RUB-MOSPRIME
SEK-STIBOR
SGD-SOR
SKK-BRIBOR
TWD-TAIBOR
THB-THBFIX
THB-BIBOR
ZAR-JIBAR
DEM-LIBOR
TENOR An integer followed by D, W, M or Y

Table 90: Allowable values for IR indices.

777
If the interest rate index is for an overnight rate (e.g. EONIA), then the third token
(i.e. the tenor) is not needed.

IR Swap Index of form CCY-CMS-TENOR or CCY-CMS-TAG-TENOR:

Index Component Allowable Values
CCY Any supported currency code
CMS Must be “CMS” (to denote a swap index)
TAG An optional tag that allows to define several CMS indices per currency
TENOR An integer followed by D, W, M or Y

Table 91: Allowable values for IR swap indices.

FX fixings of form FX-SOURCE-FOR-DOM:

Index Component Allowable Values
FX Must be “FX” (to denote an FX fixing)
SOURCE Any string
FOR Any supported currency code
DOM Any supported currency code

Table 92: Allowable values for FX fixings.

Zero Inflation Indices of form NAME:

Index Component Allowable Values
CACPI
DKCPI
EUHICP
EUHICPXT
FRHICP
NAME FRCPI
SECPI
UKRPI
USCPI
ZACPI
BEHICP

Table 93: Allowable values for zero inflation indices.

Generic Indices of form GENERIC-NAME:

Index Component Allowable Values
GENERIC Must be “GENERIC” (to denote a generic fixing)
NAME Any string

Table 94: Allowable values for generic indices.

778
12 Dividends History
Historical dividend payments data in the [Link] file is given in three columns;
Equity Name, Ex-Dividend Date and Dividend Amount in the Currency of the Equity
Curve. Columns are separated by semicolons ";" or blanks. Dividends are used in
some trades with path dependent features.
• Ex-Dividend Date: The day the stock starts trading without the value of the
dividend payment
Allowable values: See Date in Table 30.
• Equity Name: The name of the dividend paying equity.
Allowable values are the names of the Equity Curves defined in
[Link].
• Dividend Amount: The amount of the dividend payment date.
Allowable values: Any real number (not expressed as a percentage).
An excerpt of a fixings file is shown in Listing 514.

779
Listing 514: Excerpt of a dividends file

20130411 DAI:GR 2.2

20140410 DAI:GR 2.25
20150402 DAI:GR 2.45
20160407 DAI:GR 3.25
20170330 DAI:GR 3.25
20180406 DAI:GR 3.65
20190523 DAI:GR 3.25
20120815 HSBA:LN 5.5538
20121024 HSBA:LN 5.604
20130320 HSBA:LN 11.585
20130522 HSBA:LN 6.58
20130821 HSBA:LN 6.2033
20131023 HSBA:LN 6.102
20140312 HSBA:LN 11.2919
20140521 HSBA:LN 5.8768
20140820 HSBA:LN 6.1622
20141023 HSBA:LN 6.3633
20150305 HSBA:LN 13.4
20150521 HSBA:LN 6.3709
20150813 HSBA:LN 6.4436
20151022 HSBA:LN 6.6015
20160303 HSBA:LN 14.7908
20160519 HSBA:LN 7.5421
20160811 HSBA:LN 7.6633
20161020 HSBA:LN 8.0417
20170223 HSBA:LN 16.6757
20170518 HSBA:LN 7.8636
20170803 HSBA:LN 7.577
20171012 HSBA:LN 7.6405
20180222 HSBA:LN 14.762
20180517 HSBA:LN 7.5502
20180816 HSBA:LN 7.632
20181011 HSBA:LN 7.78
20190221 HSBA:LN 15.9271
20190516 HSBA:LN 7.8368

780
A Methodology Summary
A.1 Risk Factor Evolution Model
ORE applies the cross asset model described in detail in [21] to evolve the market
through time. So far the evolution model in ORE supports IR and FX risk factors for
any number of currencies, Equity and Inflation as well as Credit. Extensions to full
simulation of Commodity is planned.
The Cross Asset Model is based on the Linear Gauss Markov model (LGM) for interest
rates, lognormal FX and equity processes, Dodgson-Kainth model for inflation, LGM
or Extended Cox-Ingersoll-Ross model (CIR++) for credit, and a single-factor
log-normal model for commodity curves. We identify a single domestic currency; its
LGM process, which is labelled z0 ; and a set of n foreign currencies with associated
LGM processes that are labelled zi , i = 1, . . . , n.
We denote the equity spot price processes with state variables sj and the index of the
denominating currency for the equity process as ϕ(j). The dividend yield
corresponding to each equity process sj is denoted by qj .
Following [21], 13.27 - 13.29 we write the inflation processes in the domestic LGM
measure with state variables zI,k and yI,k for k = 1, . . . , K and the credit processes in
the domestic LGM measure with state variables C, k and yC,k for k = 1, . . . , K. If we
consider n foreign exchange rates for converting foreign currency amounts into the
single domestic currency by multiplication, xi , i = 1, . . . , n, then the cross asset model
is given by the system of SDEs

dz0 = α0 dW0z
dzi = γi dt + αi dWiz , i>0
dxi
= µi dt + σi dWix , i>0
xi
dsj
= µSj dt + σjS dWjS
sj
dzI,k = αI,k (t)dWkI
dyI,k = αI,k (t)HI,k (t)dWkI
dzC,k = αC,k (t)dWkC
dyC,k = HC,k (t)αC,k (t)dWkC

γi = −αi2 Hi − ρzx zz
ii σi αi + ρi0 αi α0 H0
µi = r0 − ri + ρzx 0i α0 H0 σi
µj = (rϕ(j) (t) − qj (t) + ρzs
S S sx S
0j α0 H0 σj − ϵϕ(j) ρjϕ(j) σj σϕ(j) )
Z t
′ ′
ri = fi (0, t) + zi (t) Hi (t) + ζi (t) Hi (t) Hi (t), ζi (t) = αi2 (s) ds
0

dWaα dWbβ = ραβ

ij dt, α, β ∈ {z, x, I, C}, a, b suitable indices

where we have dropped time dependencies for readability, fi (0, t) is the instantaneous
forward curve in currency i, and ϵi is an indicator such that ϵi = 1 − δ0i , where δ is the
Kronecker delta.

781
Parameters Hi (t) and αi (t) (or alternatively ζi (t)) are LGM model parameters which
determine, together with the stochastic factor zi (t), the evolution of numeraire and
zero bond prices in the LGM model:
 
1 1 2
N (t) = exp Ht zt + Ht ζt (16)
P (0, t) 2
 
P (0, T ) 1 2 2
(17)


P (t, T, zt ) = exp −(HT − Ht ) zt − HT − Ht ζt .
P (0, t) 2

Note that the LGM model is closely related to the Hull-White model in T-forward
measure [21].

The parameters HI,k (t) and αI,k (t) determine together with the factors zI,k (t), yI,k (t)
the evolution of the spot Index I(t) and the forward index I(t,
ˆ T ) = PI (t, T )/Pn (t, T )
defined as the ratio of the inflation linked zero bond and the nominal zero bond,

ˆ
ˆ T ) = I(0, T ) e(HI,k (T )−HI,k (t))zI,k (t)+Ṽ (t,T )
I(t,
ˆ t)
I(0,
ˆ t)eHI,k (t)zI,k (t)−yI,k (t)−V (0,t)
I(t) = I(0)I(0,

with, in case of domestic currency inflation,

Z T
1
V (t, T ) = (HI,k (T ) − HI,k (s))2 αI,k
2
(s)ds
2 t
Z T
zI
−ρ0,k H0 (T ) (HI,k (t) − HI,k (s))α0 (s)αI,k (s)ds
t
Ṽ (t, T ) = V (t, T ) − V (0, T ) − V (0, t)
1 2 2
= − (HI,k (T ) − HI,k (t))ζI,k (t, 0)
2
+(HI,k (T ) − HI,k (t))ζI,k (t, 1)
+(H0 (T )HI,k (T ) − H0 (t)HI,k (t))ζ0I (t, 0)
−(H0 (T ) − H0 (t))ζ0I (t, 1)
1 2 1
V (0, t) = HI,k (t)ζI,k (t, 0) − HI,k (t)ζI,k (t, 1) + ζI,k (t, 2)
2 2
−H0 (t)HI,k (t)ζ0I (t, 0) + H0 (t)ζ0I (t, 1)
Z t
k 2
ζI,k (t, k) = HI,k (s)αI,k (s)ds
0
Z t
zI k
ζ0I (t, k) = ρ0,k HI,k (t)α0 (s)αI,k (s)ds
0

and for foreign currency inflation in currency i > 0, with

Ṽ (t, T ) = V (t, T ) − V (0, T ) + V (0, T )

782
and

Z T
1
V (t, T ) = (HI,k (T ) − HI,k (s))2 αI,k (s)ds
2 t
Z T
zI
−ρ0,k H0 (s)α0 (s)(HI,k (T ) − HI,k (s)αI,k (s))ds
t
Z T
zI
−ρi,k (Hi (T ) − Hi (s))αi (s)(HI,k (T ) − HI,k (s))αI,k (s)ds
t
Z T
xI
+ρi,k σi (s)(HI,k (T ) − HI,k (s))αI,k (s)ds
t

Commodity
Each commodity component models the commodity price curve as
dF (t, T )
= σ e−κ (T −t) dW (t) (18)
F (t, T )
which is a single-factor version of the Gabillon (1991) model that is e.g. described in
[21]. It can also be seen as the Schwartz (1997) model formulated in terms of forward
curve dynamics. The extension to the full Gabillon model with two factors and
time-dependent multiplier
dF (t, T )
= α(t) σS e−κ (T −t) dWS (t) + σL 1 − e−κ (T −t) dWL (t) (19)



F (t, T )
for richer dynamics of the curve and accurate calibration to options will follow.
The commodity components’ Wiener processes can be correlated. However, the
integration of commodity components into the overall CAM assumes zero correlations
between commodities and non-commodity drivers for the time being.
To propagate the one-factor model, we can use an artificial (Ornstein-Uhlenbeck) spot
price process

dX(t) = −κ X(t) dt + σ(t) dW (t), X(0) = 0

Z t
X(t) = X(s) e−κ(t−s) + σ e−κ(t−u) dW (u)
s

with
 
−κ (T −t) 1
F (t, T ) = F (0, T ) exp X(t) e − (V (0, T ) − V (t, T ))
2
Z T
−2κT
V (t, T ) = e σ 2 e2κu du.
t

Note that
V[ln F (T, T )] = V[X(T )]
is the variance that is used in the pricing of a Futures Option which in turn is used in
the calibration of the Schwartz model.

783
Alternatively, one can use the drift-free state variable Y (t) = eκt X(t) with

dY (t) = σ eκ t dW (t).

Both choices of state dynamics are possible in ORE.

A.2 Analytical Moments of the Risk Factor Evolution Model

We follow [21], chapter 16. The expectation of the interest rate process zi conditional
on Ft0 at t0 + ∆t is

Et0 [zi (t0 + ∆t)] = zi (t0 ) + Et0 [∆zi ], with ∆zi = zi (t0 + ∆t) − zi (t0 )
Z t0 +∆t Z t0 +∆t
z z 2 zz
= zi (t0 ) − Hi (αi ) du + ρ0i H0z α0z αiz du
t0 t0
Z t0 +∆t
−ϵi ρzx
ii σix αiz du
t0

where ϵi is zero for i = 0 (domestic currency) and one otherwise.

The expectation of the FX process xi conditional on Ft0 at t0 + ∆t is

Et0 [ln xi (t0 + ∆t)] = ln xi (t0 ) + Et0 [∆ ln xi ], with ∆ ln xi = ln xi (t0 + ∆t) − ln xi (t0 )
= ln xi (t0 ) + (H0 (t) − H0 (s)) z0 (s) − (Hiz (t) − Hiz (s)) zi (s)
z z
 n
P0 (0, s) Pin (0, t)

+ ln
P n (0, t) Pin (0, s)
Z t 0
1
− (σ x )2 du
2 s i
 Z t 
1 z 2 z z 2 z z 2 z 2
+ (H0 (t)) ζ0 (t) − (H0 (s)) ζ0 (s) − (H0 ) (α0 ) du
2 s
 Z t 
1 z 2 z z 2 z z 2 z 2
− (Hi (t)) ζi (t) − (Hi (s)) ζi (s) − (Hi ) (αi ) du
2 s
Z t
zx
+ρ0i H0z α0z σix du
Z t s
− (Hiz (t) − Hiz ) γi du, with s = t0 , t = t0 + ∆t
s

with

γi = −Hiz (αiz )2 + H0z α0z αiz ρzz x z zx

0i − σi αi ρii

The expectation of the Inflation processes zI,k , yI,k conditional on Ft0 at any time
t > t0 is equal to zI,k (t0 ) resp. yI,k (t0 ) since both processes are drift free.

784
The expectation of the equity processes sj conditional on Ft0 at t0 + ∆t is

Et0 [ln sj (t0 + ∆t)] = ln sj (t0 ) + Et0 [∆ ln sj ], with ∆ ln sj = ln sj (t0 + ∆t) − ln sj (t0 )
 Z t
1 t S

Pϕ(j) (0, s)
Z
= ln sj (t0 ) + ln − qj (u)du − σj (u)σjS (u)du
Pϕ(j) (0, t) s 2 s
Z t Z t
+ρzs0j α0 (u)H0 (u)σjS (u)du − ϵϕ(j) ρsx
jϕ(j) σjS (u)σϕ(j) (u)du
s s
 Z t 
1 2 2 2 2
+ Hϕ(j) (t)ζϕ(j) (t) − Hϕ(j) (s)ζϕ(j) (s) − Hϕ(j) (u)αϕ(j) (u)du
2 s
Z t
+(Hϕ(j) (t) − Hϕ(j) (s))zϕ(j) (s) + ϵϕ(j) γϕ(j) (u)(Hϕ(j) (t) − Hϕ(j) (u))du
s

The IR-IR covariance over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 ) is

Z t
Cov[∆za , ∆ ln xb ] = ρzz
0a (H0z (t) − H0z ) α0z αaz du
s
Z t
−ρzz
ab αaz (Hbz (t) − Hbz ) αbz du
Zs t
+ρzx
ab αaz σbx du.
s

The IR-FX covariance over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 ) is

Z t
Cov[∆za , ∆ ln xb ] = ρzz
0a (H0z (t) − H0z ) α0z αaz du
s
Z t
−ρzz
ab αaz (Hbz (t) − Hbz ) αbz du
Zs t
+ρzx
ab αaz σbx du.
s

The FX-FX covariance over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 ) is

785
 Z t
Cov[∆ ln xa , ∆ ln xb ] = (H0z (t) − H0z )2 (α0z )2 du
s
Z t
zz
−ρ0a (Haz (t) − Haz ) αaz (H0z (t) − H0z ) α0z du
Zs t
−ρzz
0b (H0z (t) − H0z ) α0z (Hbz (t) − Hbz ) αbz du
Zs t
+ρzx
0b (H0z (t) − H0z ) α0z σbx du
Zs t
+ρzx
0a (H0z (t) − H0z ) α0z σax du
Zs t
−ρzx
ab (Haz (t) − Haz ) αaz σbx , du
Zs t
−ρzx
ba (Hbz (t) − Hbz ) αbz σax du
Zst
+ρzz
ab (Haz (t) − Haz ) αaz (Hbz (t) − Hbz ) αbz du
Zs t
+ρxx
ab σax σbx du
s

The IR-INF covariance over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 ) is

Z t
Cov[∆za , ∆zI,b ] = ρzI
ab αa (s)αI,b (s)ds
s
Z t
Cov[∆za , ∆yI,b ] = ρzI
ab αa (s)HI,b (s)αI,b (s)ds
s

The FX-INF covariance over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 ) is

Z t
Cov[∆xa , ∆zI,b ] = ρzI
0b α0 (s)(H0 (t) − H0 (s))αI,b (s)ds
s
Z t
−ρzI
ab αa (s)(Ha (t) − Ha (s))αI,b (s)ds
s
Z t
+ρxI
ab σa (s)αI,b (s)ds
s
Z t
Cov[∆xa , ∆yI,b ] = ρzI
0b α0 (s)(H0 (t) − H0 (s))HI,b (s)αI,b (s)ds
s
Z t
−ρzI
ab αa (s)(Ha (t) − Ha (s))HI,b (s)αI,b (s)ds
s
Z t
+ρxI
ab σa (s)HI,b (s)αI,b (s)ds
s

The INF-INF covariance over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 ) is

786
 Z t
Cov[∆zI,a , ∆zI,b ] = ρII
ab αI,a (s)αI,b (s)ds
s
Z t
Cov[∆zI,a , ∆yI,b ] = ρII
ab αI,a (s)HI,b (s)αI,b (s)ds
s
Z t
Cov[∆yI,a , ∆yI,b ] = ρII
ab HI,a (s)αI,a (s)HI,b (s)αI,b (s)ds
s

The equity/equity covariance over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 )
is
Z t
zz
Cov [∆ln[si ], ∆ln[sj ]] = ρϕ(i)ϕ(j) (Hϕ(i) (t) − Hϕ(i) (u))(Hϕ(j) (t)
s
−Hϕ(j) (u))αϕ(i) (u)αϕ(j) (u)du
Z t
zs
+ρϕ(i)j (Hϕ(i) (t) − Hϕ(i) (u))αϕ(i) (u)σjS (u)du
Zs t
+ρzs
ϕ(j)i (Hϕ(j) (t) − Hϕ(j) (u))αϕ(j) (u)σiS (u)du
Z ts
+ρss
ij σiS (u)σjS (u)du
s

The equity/FX covariance over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 ) is
Z t
zz
Cov [∆ln[si ], ∆ln[xj ]] = ρϕ(i)0 (Hϕ(i) (t) − Hϕ(i) (u))(H0 (t) − H0 (u))αϕ(i) (u)α0 (u)du
s
Z t
zz
−ρϕ(i)j (Hϕ(i) (t) − Hϕ(i) (u))(Hj (t) − Hj (u))αϕ(i) (u)αj (u)du
s
Z t
zx
+ρϕ(i)j (Hϕ(i) (t) − Hϕ(i) (u))αϕ(i) (u)σj (u)du
s
Z t
sz
+ρi0 (H0 (t) − H0 (u))α0 (u)σiS (u)du
Zs t
−ρszij (Hj (t) − Hj (u))αj (u)σiS (u)du
Zs t
+ρsxij σiS (u)σj (u)du
s

The equity/IR covariance over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 ) is
Z t
zz
Cov [∆ln[si ], ∆zj ] = ρϕ(i)j (Hϕ(i) (t) − Hϕ(i) (u))αϕ(i) (u)αj (u)du
s
Z t
sz
+ρij σiS (u)αj (u)du
s

787
The equity/inflation covariances over the interval [s, t] := [t0 , t0 + ∆t] (conditional on
Ft0 ) are as follows:
Z t
zI
Cov [∆ln[si ], ∆zI,j ] = ρϕ(i)j (Hϕ(i) (t) − Hϕ(i) (u))αϕ(i) (u)αI,j (u)du
s
Z t
sI
+ρij σiS (u)αI,j (u)du
Zs t
Cov [∆ln[si ], ∆yI,j ] = ρzI
ϕ(i)j (Hϕ(i) (t) − Hϕ(i) (u))αϕ(i) (u)HI,j (u)αI,j (u)du
s
Z t
sI
+ρij σiS (u)HI,j (u)αI,j (u)du
s

The expectation of the Credit processes zC,k , yC,k conditional on Ft0 at any time t > t0
is equal to zC,k (t0 ) resp. yC,k (t0 ) since both processes are drift free.
The credit/credit covariances over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 )
are as follows:
Z t
CC
Cov [∆zC,a , ∆zC,b ] = ρab αC,a (u)αC,b (u)du
s
Z t
CC
Cov [∆zC,a , ∆yC,b ] = ρab αC,a (u)HC,b (u)αC,b (u)du
s
Z t
CC
Cov [∆yC,a , ∆yC,b ] = ρab αC,a (u)HC,a (u)αC,b (u)HC,b (u)du
s

The IR/credit covariances over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 ) are
as follows:
Z t
zC
Cov [∆za , ∆zC,b ] = ρab αa (u)αC,b (u)du
s
Z t
zC
Cov [∆za , ∆yC,b ] = ρab αa (u)HC,b (u)αC,b (u)du
s

The FX/credit covariances over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 )
are as follows:
Z t
zC
Cov[∆xa , ∆zC,b ] = ρ0b α0 (s)(H0 (t) − H0 (s))αC,b (s)ds
s
Z t
zC
−ρab αa (s)(Ha (t) − Ha (s))αC,b (s)ds
s
Z t
xC
+ρab σa (s)αC,b (s)ds
s
Z t
zC
Cov[∆xa , ∆yC,b ] = ρ0b α0 (s)(H0 (t) − H0 (s))HC,b (s)αC,b (s)ds
s
Z t
zC
−ρab αa (s)(Ha (t) − Ha (s))HC,b (s)αC,b (s)ds
s
Z t
xC
+ρab σa (s)HC,b (s)αC,b (s)ds
s

788
The inflation/credit covariances over the interval [s, t] := [t0 , t0 + ∆t] (conditional on
Ft0 ) are as follows:
Z t
IC
Cov[∆zI,a , ∆zC,b ] = ρab αI,a αC,b (u)du
s
Z t
IC
Cov[∆zI,a , ∆yC,b ] = ρab αI,a HC,b (u)αC,b (u)du
s
Z t
IC
Cov[∆yI,a , ∆zC,b ] = ρab αI,a HI,a (u)αC,b (u)du
s
Z t
IC
Cov[∆yI,a , ∆yC,b ] = ρab αI,a HI,a (u)αC,b (u)HC,b (u)du
s

The equity/credit covariances over the interval [s, t] := [t0 , t0 + ∆t] (conditional on Ft0 )
are as follows:
Z t
zC
Cov [∆ln[si ], ∆zC,j ] = ρϕ(i)j (Hϕ(i) (t) − Hϕ(i) (u))αϕ(i) (u)αC,j (u)du
s
Z t
sC
+ρij σiS (u)αC,j (u)du
Z st
Cov [∆ln[si ], ∆yC,j ] = ρzC
ϕ(i)j (Hϕ(i) (t) − Hϕ(i) (u))αϕ(i) (u)HC,j (u)αC,j (u)du
s
Z t
sC
+ρij σiS (u)HC,j (u)αC,j (u)du
s

A.3 Change of Measure

We can change measure from LGM to the T-Forward measure by applying a shift
transformation to the H parameter of the domestic LGM process, as explained in [21]
and shown in Example 12, section 5.12. This does not involve amending the system of
SDEs above.

In the following we show how to move from the LGM to the Bank Account measure
when we start with the Cross Asset Model in the LGM measure. This description and
the implementation in ORE is limited so far to the cross currency case.
First note that the stochastic Bank Account (BA) can be written
Z t
1 t
Z 
1 B 2 2
B(t) = exp (Ht − Hs ) αs dWs + (Ht − Hs ) αs ds
P (0, t) 0 2 0

with Wiener processes in the BA measure. We can express this in terms of the
domestic LGM’s state variable z(t) and an auxiliary random variable y(t)
 
1 1 2


B(t) = exp H(t) z(t) − y(t) + H (t) ζ0 (t) + ζ2 (t)
P (0, t) 2

789
with

dz(t) = α(t) dW B (t) − H(t) α2 (t) dt

dy(t) = H(t) α(t) dW B (t)
Z t
ζn (t) = α2 (s) H n (s) ds
0

Note the drift of LGM state variable z(t) in the BA measure and the auxiliary state
variable y(t) which is driven by the same Wiener process as z(t). The instantaneous
correlation of dz and dy is one, but the terminal correlation of z(t) and y(t) is less than
one because of their different volatility functions. This is all we need to switch measure
to BA in a pure domestic currency case.
To change measure in the cross currency case we need to make changes to the SDE
beyond adding an auxiliary state variable y and adding a drift to the domestic LGM
state. Let us write down the SDEs in the LGM and BA measure with respective drift
terms that ensure martingale properties.
SDE in the LGM measure

dz0 = α0 dW0z
dzi = −αi2 Hi − ρzx zz z


ii σi αi + ρi0 αi α0 H0 dt + αi dWi
 
1 2 zx
d ln xi = r0 − ri − σi + ρ0i α0 H0 σi dt + σi dWix
2

SDE in the BA measure

fz
dy0 = α0 H0 dW0

dz0 = −α02 H0 dt + α0 dW
fz
0
2 zx fiz


dzi = −αi Hi − ρii σi αi dt + αi dW
 
1
d ln xi = r0 − ri − σi2 dt + σi dWfix , ri = fi (0, t) + zi (t) Hi′ (t) + ζi (t) Hi (t) Hi′ (t)
2

Blue terms are added, red terms are removed when moving from LGM to BA.

790
These drift term changes lead to the following changes in conditional expectations
E[∆y0 ] =0
Z t
E[∆z0 ] = − H0 α02 du
Zs t Z t Z t
E[∆zi ] = − Hi αi2 du − ρzx
ii σix αi du + ρzz
0i H0 α0 αi du
s s s
E[∆ ln x] = (H0 (t) − H0 (s)) z0 (s) − (Hi (t) − Hi (s)) zi (s)
 n
P0 (0, s) Pin (0, t)

+ ln
P n (0, t) Pin (0, s)
Z t0
1
− (σ x )2 du
2 s i
 Z t 
1 2 2 2 2
+ H0 (t) ζ0 (t) − H0 (s) ζ0 (s) − H0 α0 du
2 s
 Z t 
1 2 2 2 2
− Hi (t) ζi (t) − Hi (s) ζi (s) − Hi αi du
2 s
Z t
zx
+ ρ0i H0 α0 σix du
Z t s
− (Hi (t) − Hi ) γi du with γi = −αi2 Hi − ρzx zz
ii σi αi + ρi0 αi α0 H0
Zs t
+ (H0 (t) − H0 ) γ0 du with γ0 = −H0 α02
s

and the following additional variances and covariances

Z t
Var[∆y0 ] = α02 H02 du
s
Z t
zz
Cov[∆y0 , ∆zi ] =ρ0i α0 H0 αi du
s
Z t
Cov[∆y0 , ∆ ln xi ] = (H0 (t) − H0 ) α02 H0 du
s
Z t
zz
− ρ0i α0 H0 (Hi (t) − Hi ) αi du
s
Z t
zx
+ ρ0i α0 H0 σix du
s

Example 36 in section 5.36 illustrates the effect of the choice of measure on exposure
simulations.

A.4 Exposures
In ORE we use the following exposure definitions
+
 
N (N P V (t) − C(t))
EE (t) = EPE (t) = E (20)
N (t)
+
 
N (−N P V (t) + C(t))
ENE (t) = E (21)
N (t)

791
where NPV (t) stands for the netting set NPV and C(t) is the collateral balance14 at
time t. Note that these exposures are expectations of values discounted with numeraire
N (in ORE the Linear Gauss Markov model’s numeraire) to today, and expectations
are taken in the measure associated with numeraire N . These are the exposures which
enter into unilateral CVA and DVA calculation, respectively, see next section. Note
that we sometimes label the expected exposure (20) EPE, not to be confused with the
Basel III Expected Positive Exposure below.

Basel III defines a number of exposures each of which is a ’derivative’ of Basel’s

Expected Exposure:

Expected Exposure

EEB (t) = E[max(N P V (t) − C(t), 0)] (22)

Expected Positive Exposure

1X
EP EB (T ) = EEB (t) · ∆t (23)
T t<T

Effective Expected Exposure, recursively defined as running maximum

EEEB (t) = max(EEEB (t − ∆t), EEB (t)) (24)

Effective Expected Positive Exposure

1X
EEP EB (T ) = EEEB (t) · ∆t (25)
T t<T

The last definition, Effective EPE, is used in Basel documents since Basel II for
Exposure At Default and capital calculation. Following [12, 13] the time averages in
the EPE and EEPE calculations are taken over the first year of the exposure evolution
(or until maturity if all positions of the netting set mature before one year).

To compute EEB (t) consistently in a risk-neutral setting, we compound (20) with the
deterministic discount factor P (t) up to horizon t:
1
EEB (t) = EE (t)
P (t)

Finally, we define another common exposure measure, the Potential Future Exposure
(PFE), as a (typically high) quantile α of the NPV distribution through time, similar
to Value at Risk but at the upper end of the NPV distribution:

PFE α (t) = (inf {x|Ft (x) ≥ α})+ (26)

where Ft is the cumulative NPV distribution function at time t. Note that we also take
the positive part to ensure that PFE is a positive measure even if the quantile yields a
negative value which is possible in extreme cases.
14
C(t) > 0 means that we have received collateral from the counterparty

792
A.5 Exposures using American Monte Carlo
The exposure analysis implemented in ORE that is used in the bulk of the examples in
this user guide, mostly vanilla portfolios, is divided into two independent steps:
1. in a first step a list of NPVs (or a “NPV cube”) is computed. The list is indexed
by the trade ID, the simulation time step and the scenario sample number. Each
entry of the cube is computed using the same pricers as for the T0 NPV
calculation by shifting the evaluation date to the relevant time step of the
simulation and updating the market term structures to the relevant scenario
market data. The market data scenarios are generated using a risk factor
evolution model which can be a cross asset model, but also be based on e.g.
historical simulation.
2. in a second step the generated NPV cube is passed to a post processor that
aggregates the results to XVA figures of different kinds.
We label this approach in the following as the classic exposure analysis.
The AMC module in ORE allows to replace the first step by a different approach
which works faster in particular for exotic deals. The second step remains the same.
The risk factor evolution model coincides with the pricing models for the single trades
in this approach and is always a cross asset model operated in a pricing measure.
For AMC the entries of the NPV cube are now viewed as conditional NPVs at the
simulation time given the information that is generated by the cross asset model’s
driving stochastic process up to the simulation time. The conditional expectations are
then computed using a regression analysis of some type. In our current implementation
this is chosen to be a parametric regression analysis.
The regression models are calibrated per trade during a training phase and later on
evaluated in the simulation phase. The set of paths in the two phases is in general
different w.r.t. their number, time step structure, and generation method (Sobol,
Mersenne Twister) and seed. Typically the regressand is the (deflated) dirty path NPV
of the trade in question, or also its underlying NPV or an option continuation value (to
take exercise decisions or represent the physical underlying for physical exercise rights).
The regressor is typically the model state. Certain exotic features that introduce
path-dependency (e.g. a TaRN structure) may require an augmentation of the
regressor though (e.g. by the already accumulated amount in case of the TaRN).
The path NPVs are generated at their natural event dates, like the fixing date for
floating rate coupons or the payment date for fixed cashflows. This reduces the
requirements for the cross asset model to provide closed form expressions for the
numeraire and conditional zero bonds only.
Since the evaluation of the regression functions is computationally cheap the overall
timings of the NPV cube generation are generally smaller compared to the classic
approach, in particular for exotic deals like Bermudan Swaptions.
From a methodology point of view an important difference between the classic and the
AMC exposure analysis lies in the model consistency: While the conditional NPVs
computed with AMC are by construction consistent with the risk factor evolution
model driving the XVA simulation, the scenario NPVs in the classic approach are in

793
general not consistent in this sense unless the market scenarios are fully implied by the
cross asset model. Here “fully implied” means that not only rate curves, but also
market volatility and correlation term structures like FX volatility surfaces, Swaption
volatilities or CMS correlation term structures as well as other parameters used by the
single trade pricers have to be deduced from the cross asset model, e.g. the mean
reversion of the Hull White 1F model and a suitable model volatility feeding into a
Bermudan Swaption pricer.
We note that the generation of such implied term structures can be computationally
expensive even for simple versions of a cross asset model like one composed from LGM
IR and Black-Scholes FX components etc., and even more so for more exotic
component flavours like Cheyette IR components, Heston FX components etc.
In the current implementation only a subset of all ORE trade types can be simulated
using AMC while all other trade types are still simulated using the classic engine. The
separation of the trades and the joining of the resulting classic and AMC cubes is
automatic. The post processing step is run on the joint cube from the classic and
AMC simulations as before.
Trade types supported by AMC so far:
1. Swap
2. CrossCurrencySwap
3. FxOption
4. BermudanSwaption
5. MultiLegOption

A.5.1 *Implementation Details

AMC valuation engine and AMC pricing engines
The AMCValuationEngine is responsible for generating a NPV cube for a portfolio of
AMC enabled trades and (optionally) to populate a AggregationScenarioData
instance with simulation data for post processing, very similar to the classic
ValuationEngine in ORE.
The AMC valuation engine takes a cross asset model defining the risk factor evolution.
This is set up identically to the cross asset model used in the
CrossAssetModelScenarioGenerator. Similarly the same parameters for the path
generation (given as a ScenarioGeneratorData instance) are used, so that it is
guaranteed that both the AMC engine and the classic engine produce the same paths,
hence can be combined to a single cube for post processing. It is checked, that a
non-zero seed for the random number generation is used.
The portfolio that the AMC engine consumes is build against an engine factory set up
by a pricing engine configuration given in the amc analytics type (see 5.39). This
configuration should select special AMC engine builders which (by a pure naming
convention) have the engine type “AMC”. These engine builders are retrieved from
getAmcEngineBuilders() in [Link] and are special in that unlike usual
engine builders they take two parameters

794
 1. the cross asset model which serves as a risk factor evolution model in the AMC
valuation engine
2. the date grid used within the AMC valuation engine
For technical reasons, the configuration also contains configurations for
CapFlooredIborLeg and CMS because those are used within the trade builders (more
precisely the leg builders called from these) to build the trade. The configuration can
be the same as for T0 pricing for them, it is actually not used by the AMC pricing
engines.
The AMC engine builders build a smaller version of the global cross asset model only
containing the model components required to price the specific trade. Note that no
deal specific calibration of the model is performed.
The AMC pricing engines perform a T0 pricing and - as a side product - can be used
as usual T0 pricing engines if a corresponding engine builder is supplied, see 5.39.
In addition the AMC pricing engines perform the necessary calculations to yield
conditional NPVs on the given global simulation grid. How these calcuations are
performed is completely the responsibility of the pricing engines, altough some
common framework for many trade types is given by a base engine, see A.5.1. This
way the approximation of conditional NPVs on the simulation grid can be taylored to
each product and also each single trade, with regards to
1. the number of traning paths and the required date grid for the training (e.g.
containing all relevant coupon and exercise event dates of a trade)
2. the order and type of regressoin basis functions to be used
3. the choice of the regressor (e.g. a TaRN might require a regressor augmented by
the accumulated coupon amount)
The AMC pricing engines then provide an additional result labelled amcCalculator
which is a class implementing the AmcCalculator interface which consists of two
methods: The method simulatePath() takes a MultiPath instance representing one
simulated path from the global risk factor evolution model and returns an array of
conditional, deflated NPVs for this path. The method npvCurrency() returns the
currency c of the calculated conditional NPVs. This currency can be different from the
base currency b of the global risk factor evolution model. In this case the conditional
NPVs are converted to the global base currency within the AMC valuation engine by
multiplying them with the conversion factor

Nc (t)Xc,b (t)
(27)
Nb (t)

where t is the simulation time, Nc (t) is the numeraire in currency c, Nb (t) is the
numeraire in currency b and Xc,b (t) is the FX rate at time t converting from c to b.
The technical criterion for a trade to be processed within the AMC valuation is engine
is that a) it can be built against the AMC engine factory described above and b) it
provides an additional result amcCalculator. If a trade does not meet these criteria it

795
is simulated using the classic valuation engine. The logic that does this is located in
the overide of the method OREAppPlus::generateNPVCube().
The AMC valuation engine can also populate an aggregation scenario data instance.
This is done only if necessary, i.e. only if no classic simulation is performed anyway.
The numeraire and fx spot values produced by the AMC valuation engine are identical
to the classic engine. Index fixings are close, but not identical, because the AMC
engine used the T0 curves for projection while the classic engine uses scenario
simulation market curves, which are not exactly matching those of the T0 market. In
this sense the AMC valuation engine produces more precise values compared to the
classic engine.

The multileg option AMC base engine and derived engines

Table 12 provides an overview of the implemented AMC engine builders. These
builders use the following QuantExt pricing engines
1. McLgmSwapEngine for single currency swaps
2. McCamCurrencySwapEngine for cross currency swaps
3. McCamFxOptionEngine for fx options
4. McLgmSwaptionEngine for Bermudan swaptions
5. McMultiLegOptionEngine for Multileg option
All these engine are based on a common McMultiLegBaseEngine which does all the
computations. For this each of the engines sets up the following protected member
variables (serving as parameters for the base engine) in their calculate() method:
1. leg_: a vector of QuantLib::Leg
2. currency_: a vector of QuantLib::Currency corresponding to the leg vector
3. payer_: a vector of +1.0 or −1.0 double values indicating receiver or payer legs
4. exercise_: a QuantLib::Exercise instance describing the exercise dates (may
be nullptr, if the underlying represents the deal already)
5. optionSettlement_: a Settlement::Type value indicating whether the option
is settled physically or in cash
A call to McMultiLegBaseEngine::calculate() will set the result member variables
1. resultValue_: T0 NPV in the base currency of the cross asset model passed to
the pricing engine
2. underlyingValue_: T0 NPV of the underlying (again in base ccy)
3. *amcCalculator_: the AMC calculator engine to be used in the AMC valuation
engine
The specific engine implementations should convert the resultValue_ to the npv
currency of the trade (as defined by the (ORE) trade builder) so that they can be used
as regular pricing engine consistently within ORE. Note that only the additional

796
amcCalculator result is used by the AMC valuation engine, not any of the T0 NPVs
directly.

Limitations and Open Points

This sections lists known limitations of the AMC simulation engine.

Trade Features
Some trade features are not yet supported by the multileg option engine:
1. exercise flows (like a notional exchange common to cross currency swaptions) are
not supported

Flows Generation (for DIM Analysis)

At the current stage the AMC engine does not generate flows which are required for
the DIM analysis in the post processor.

State interpolation for exercise decisions

During the simulation phase exercise times of a specific trade are not necessarily part
of the simulated time grid. Therefore the model state required to take the exercise
decision has in to be interpolated in general on the simulated path. Currently this is
done using a simple linear interpolation while from a pure methodology point of view a
Brownian Bridge would be preferable. In our tests we do not see a big impact of this
approximation though.

Basis Function Selection

Currently the basis function system is generated by specifying the type of the
functions and the order, see 5.39. The number of independent variables varies by
product type and details. Depending on the number of independent variables and the
order the number of generated basis functions can get quite big which slows down the
computation of regression coefficients. It would be desirable to have the option to filter
the full set of basis functions, e.g. by explicitly enumerating them in the configuration,
so that a high order can be chosen even for products with a relatively large number of
independent variables (like e.g. FX Options or Cross Currency Swaps).

Outlook: Trade Compression

For vanilla trades where the regression is only required to produce the NPV cube
entries (and not to take exercise decisions etc.) it is not strictly necessary to do the
regression analysis on a single trade level15 . Although in the current implementation
there is no direct way to do the regression analysis on whole (sub-)portfolios instead of
single trades, one can represent such a subportfolio as a single technical trade (e.g. as
a single swap or multileg option trade) to achieve a similar result. This might lead to
better performance than the usual single trade calculation. However one should also try
to keep the regressions as low-dimensional as possible (for performance and accuracy
15
except single trade exposures are explicitly required of course

797
reasons) and therefore define the sub-portfolios by e.g. currency, i.e. as big as possible
while at the same time keeping the associated model dimension as small as possible.

A.6 CVA and DVA

Using the expected exposures in A.4 unilateral discretised CVA and DVA are given by
[21]
X
CVA = PD(ti−1 , ti ) × LGD × EPE (ti ) (28)
i
X
DVA = PD Bank (ti−1 , ti ) × LGD Bank × ENE (ti ) (29)
i

where
EPE (t) expected exposure (20)
ENE (t) expected negative exposure (21)
P D(ti , tj ) counterparty probability of default in [ti ; tj ]
P DBank (ti , tj ) our probability of default in [ti ; tj ]
LGD counterparty loss given default
LGDBank our loss given default

Note that the choice ti in the arguments of EPE (ti ) and ENE (ti ) means we are
choosing the advanced rather than the postponed discretization of the CVA/DVA
integral [16]. This choice can be easily changed in the ORE source code or made
configurable.
Moreover, formulas (28, 29) assume independence of credit and other market risk
factors, so that PD and LGD factors are outside the expectations. With the extension
of ORE to credit asset classes and in particular for wrong-way-risk analysis, CVA/DVA
formulas is generaised and is applicable to calculations with dynamic credit

PD dyn (ti−1 , ti ) × PE (ti )

X  
CVA dyn
= E N
× LGD (30)
i
N (t)
" #
dyn
X PD (t
Bank i−1 i , t ) × NE (t i )
DVAdyn = EN × LGD Bank (31)
i
N (t)

where
PE (t) random variables representing positive exposure at t : (N P V (t) − C(t))+
NE (t) random variables representing negative exposure at t : (−N P V (t) + C(t))+
P Ddyn (ti , tj ) random variables representing counterparty probability of default in [ti ; tj ]
dyn
P DBank (ti , tj ) random variables representing our probability of default in [ti ; tj ]
LGD counterparty loss given default
LGDBank our loss given default

798
A.7 FVA
Any exposure (uncollateralised or residual after taking collateral into account) gives
rise to funding cost or benefits depending on the sign of the residual position. This can
be expressed as a Funding Value Adjustment (FVA). A simple definition of FVA can
be given in a very similar fashion as the sum of unilateral CVA and DVA which we
defined by (28,29), namely as an expectation of exposures times funding spreads:
n
X
fl (ti−1 , ti ) δi EN SC (ti−1 ) SB (ti−1 ) [−NPV (ti ) + C(ti )]+ D(ti )

FVA =
|i=1 {z }
Funding Benefit Adjustment (FBA)
n
X
fb (ti−1 , ti ) δi EN SC (ti−1 ) SB (ti−1 ) [NPV (ti ) − C(ti )]+ D(ti ) (32)

−
i=1
| {z }
Funding Cost Adjustment (FCA)
where

D(ti ) stochastic discount factor, 1/N (ti ) in LGM

NPV (ti ) portfolio value at time ti
C(ti )Collateral account balance at time ti
SC (tj ) survival probability of the counterparty
SB (tj ) survival probability of the bank
fb (tj ) borrowing spread for the bank relative to OIS flat
fl (tj ) lending spread for the bank relative to OIS flat

For details see e.g. Chapter 14 in Gregory [19] and the discussion in [21].

The reasoning leading to the expression above is as follows. Consider, for example, a
single partially collateralised derivative (no collateral at all or CSA with a significant
threshold) between us (the Bank) and counterparty 1 (trade 1).
We assume that we enter into an offsetting trade with (hypothetical) counterparty 2
which is perfectly collateralised (trade 2). We label the NPV of trade 1 and 2 NPV 1,2
respectively (from our perspective, excluding CVA). Then NPV 2 = −NPV 1 . The
respective collateral amounts due to trade 1 and 2 are C1 and C2 from our perspective.
Because of the perfect collateralisation of trade 2 we assume C2 = NPV 2 . The
imperfect collateralisation of trade 1 means C1 ̸= NPV 1 . The net collateral balance
from our perspective is then C = C1 + C2 which can be written
C = C1 + C2 = C1 + NPV 2 = −NPV 1 + C1 .
• If C > 0 we receive net collateral and pay the overnight rate on this notional
amount. On the other hand we can invest the received collateral and earn our
lending rate, so that we have a benefit proportional to the lending spread fl
(lending rate minus overnight rate). It is a benefit assuming fl > 0. C > 0 means
−NPV 1 + C1 > 0 so that we can cover this case with “lending notional”
[−NPV 1 + C1 ]+ .
• If C < 0 we post collateral amount −C and receive the overnight rate on this
amount. Amount −C needs to be funded in the market, and we pay our

799
 borrowing rate on it. This leads to a funding cost proportional to the borrowing
spread fb (borrowing rate minus overnight). C < 0 means NPV 1 − C1 > 0, so
that we can cover this case with “borrowing notional” [NPV 1 − C1 ]+ . If the
borrowing spread is positive, this term proportional to fb × [NPV 1 − C1 ]+ is
indeed a cost and therefore needs to be subtracted from the benefit above.
Formula (32) evaluates these funding cost components on the basis of the original
trade’s or portfolio’s NPV . Perfectly collateralised portfolios hence do not contribute
to FVA because under the hedging fiction, they are hedged with a perfectly
collateralised opposite portfolio, so any collateral payments on portfolio 1 are canceled
out by those of the opposite sign on portfolio 2.

A.8 COLVA
When the CSA defines a collateral compounding rate that deviates from the overnight
rate, this gives rise to another value adjustment labeled COLVA [21]. In the simplest
case the deviation is just given by a constant spread ∆:
" #
X
COLVA = EN −C(ti ) · ∆ · δi · D(ti+1 ) (33)
i

where C(t) is the collateral balance16 at time t and D(t) is the stochastic discount
factor 1/N (t) in LGM. Both C(t) and N (t) are computed in ORE’s Monte Carlo
framework, and the expectation yields the desired adjustment.
Replacing the constant spread by a time-dependent deterministic function in ORE is
straight forward.

A.9 Collateral Floor Value

A less trivial extension of the simple COLVA calculation above, also covered in ORE,
is the case where the deviation between overnight rate and collateral rate is stochastic
itself. A popular example is a CSA under which the collateral rate is the overnight rate
floored at zero. To work out the value of this CSA feature one can take the difference
of discounted margin cash flows with and without the floor feature. It is shown in [21]
that the following formula is a good approximation to the collateral floor value
" #
X
ΠF loor = EN −C(ti ) · (−r(ti ))+ · δi · D(ti+1 ) (34)
i

where r is the stochastic overnight rate and (−r)+ = r+ − r is the difference between
floored and ’un-floored’ compounding rate.
Taking both collateral spread and floor into account, the value adjustment is
" #
X
ΠF loor,∆ = EN −C(ti ) · ((r(ti ) − ∆)+ − r(ti )) · δi · D(ti+1 ) (35)
i
16
see A.4, C(t) > 0 means that we have received collateral from the counterparty

800
A.10 Dynamic Initial Margin and MVA
The introduction of Initial Margin posting in non-cleared OTC derivatives business
reduces residual credit exposures and the associated value adjustments, CVA and
DVA.
On the other hand, it gives rise to additional funding cost. The value of the latter is
referred to as Margin Value Adjustment (MVA).
To quantify these two effects one needs to model Initial Margin under future market
scenarios, i.e. Dynamic Initial Margin (DIM). Potential approaches comprise
• Monte Carlo VaR embedded into the Monte Carlo simulation
• Regression-based methods
• Delta VaR under scenarios
• ISDA’s Standard Initial Margin (SIMM) under scenarios
We skip the first option as too computationally expensive for ORE. In the current ORE
release we focus on a relatively simple regression approach as in [22, 26]. Consider the
netting set values NPV (t) and NPV (t + ∆) that are spaced one margin period of risk
∆ apart. Moreover, let F (t, t + ∆) denote cumulative netting set cash flows between
time t and t + ∆, converted into the NPV currency. Let X(t) then denote the netting
set value change during the margin period of risk excluding cash flows in that period:
X(t) = NPV (t + ∆) + F (t, t + ∆) − NPV (t)
ignoring discounting/compounding over the margin period of risk. We actually want to
determine the distribution of X(t) conditional on the ‘state of the world’ at time t, and
pick a high (99%) quantile to determine the Initial Margin amount for each time t.
Instead of working out the distribution, we content ourselves with estimating the
conditional variance V(t) or standard deviation S(t) of X(t), assuming a normal
distribution and scaling S(t) to the desired 99% quantile by multiplying with the usual
factor α = 2.33 to get an estimate of the Dynamic Initial Margin DIM :
p
V(t) = Et [X 2 ] − E2t [X], S(t) = V(t), DIM (t) = α S(t)
We further assume that Et [X] is small enough to set it to the expected value of X(t)
across all Monte Carlo samples X at time t (rather than estimating a scenario
dependent mean). The remaining task is then to estimate the conditional expectation
Et [X 2 ]. We do this in the spirit of the Longstaff Schwartz method using regression of
X 2 (t) across all Monte Carlo samples at a given time. As a regressor (in the
one-dimensional case) we could use NPV (t) itself. However, we rather choose to use an
adequate market point (interest rate, FX spot rate) as regression variable x, because
this is generalised more easily to the multi-dimensional case. As regression basis
functions we use polynomials, i.e. regression functions of the form
c0 + c1 x + c2 x2 + ... + cn xn where the order n of the polynomial can be selected by the
user. Choosing the lowest order n = 0, we obtain the simplest possible estimate, the
variance of X across all samples at time t, so that we apply a single DIM (t)
irrespective of the ’state of the world’ at time t in that case. The extension to
multi-dimensional regression is also implemented in ORE. The user can choose several
regressors simultaneously (e.g. a EUR rate, a USD rate, USD/EUR spot FX rate, etc.)
in order order to cover complex multi-currency portfolios.

801
Given the DIM estimate along all paths, we can next work out the Margin Value
Adjustment [21] in discrete form
n
X
MVA = (fb − sI ) δi SC (ti ) SB (ti ) × EN [DIM (ti ) D(ti )] . (36)
i=1

with borrowing spread fb as in the FVA section A.7 and spread sI received on initial
margin, both spreads relative to the cash collateral rate.

A.11 KVA (CCR)

The KVA is calculated for the Counterparty Credit Risk Capital charge (CCR)
following the IRB method concisely described in [20], Appendix 8A. It is following the
Basel rules by computing risk capital as the product of alpha weighted exposure at
default, worst case probability of default at 99.9 and a maturity adjustment factor also
described in the Basel annex 4. The risk capital charges are discounted with a capital
discount factor and summed up to give the total CCR KVA after being multiplied with
the risk weight and a capital charge (following the RWA method).

Basel II internal rating based (IRB) estimate of worst case probability of default: large
homogeneous pool (LHP) approximation of Vasicek (1997), KVA regulatory
probability of default is the worst case probability of default floored at 0.03 (the latter
is valid for corporates and banks, no such floor applies to sovereign counterparties):
 −1 √
N (PD) + ρN −1 (0.999)
  
PD 99.9% = max f loor, N √ − PD
1−ρ

N is the cumulative standard normal distribution,

1 − e−50PD 1 − e−50PD
 
ρ = 0.12 + 0.24 1 −
1 − e−50 1 − e−50

Maturity adjustment factor for RWA method capped at 5, floored at 1:

  
1 + (M − 2.5)B(PD)
MA(PD, M ) = min 5, max 1,
1 − 1.5B(PD)

where B(PD) = (0.11852 − 0.05478 ln(PD))2 and M is the effective maturity of the
portfolio (capped at 5):
 P 
EE B (tk )∆tk B(0, tk )
tk >1yr
M = min 5, 1 + P
 
EEE B (tk )∆tk B(0, tk )

tk ≤1yr

where B(0, tk ) is the risk-free discount factor from the simulation date tk to today, ∆tk
is the difference between time points, EE B (tk ) is the expected (Basel) exposure at time
tk and EEE B (tk ) is the associated effective expected exposure.

802
Expected risk capital at ti :

RC (ti ) = EAD(ti ) × LGD × PD 99.9% × MA(PD, M )

where
• EAD(ti ) = α × EEPE (ti )
• EEPE (ti ) is estimated as the time average of the running maximum of EPE (t)
over the time interval ti ≤ t ≤ ti + 1
• α is the multiplier resulting from the IRB calculations (Basel II defines a
supervisory alpha of 1.4, but gives banks the option to estimate their own
α,subject to a floor of 1.2).
• the maturity adjustment MA is derived from the EPE profile for times t ≥ ti

KVACCR is the sum of the expected risk capital amount discounted at capital discount
rate rcd and compounded at rate given by the product of capital hurdle h and
regulatory adjustment a:
X 1
KVACCR = RC (ti ) × δ(ti−1 ,ti )
× δ(ti−1 , ti ) × h × a
i
(1 + rcd )

assuming Actual/Actual day count to compute the year factions delta.

In ORE we compute KVA CCR from both perspectives - “our” KVA driven by EPE
and the counterparty default risk, and similarly “their” KVA driven by ENE and our
default risk.

A.12 KVA (BA-CVA)

This section briefly summarizes the calculation of a capital value adjustment
associated with the CVA capital charge (in the basic approach, BA-CVA) as
introduced in Basel III [13, 14, 15]. ORE implements the stand-alone capital charge
SCVA for a netting set and computes a KVA for it17 . In the basic approach, the
stand-alone capital charge for a netting set is given by

SCVA = RW c · M · EEPE · DF

with
• supervisory risk weight RW c for the counterparty;
• effective netting set maturity M as in section A.11 (for a bank using IMM to
calculate EAD), but without applying a cap of 5;
17
In the reduced version of BA-CVA, where hedges are not recognized, the total BA-CVA capital
charge across all counterparties c is given by
v !2
u
u X X
K= t ρ SCVAc + (1 − ρ2 ) SCVA2c
c c

with supervisory correlation ρ = 0.5 to reflect that the credit spread risk factors across counterparties
are not perfectly correlated. Each counterparty SCVAc is given by a sum over all netting sets with this
counterparty.

803
 • supervisory discount DF for the netting set which is equal to one for banks using
IMM to calculate EEPE and DF = (1 − exp (−0.05 M )) /(0.05 M ) for banks not
using IMM to calculate EEPE .
The associated capital value adjustment is then computed for each netting set’s
stand-alone CVA charge as above
X 1
KVABA−CVA = SCVA(ti ) × × δ(ti−1 , ti ) × h × a
i
(1 + rcd )δ(ti−1 ,ti )

with
SCVA(ti ) = RW c · M (ti ) · EEPE (ti ) · DF
where we derive both M and EEPE from the EPE profile for times t ≥ ti .
In ORE we compute KVA BA-CVA from both perspectives - “our” KVA driven by
EPE and the counterparty risk weight, and similarly “their” KVA driven by ENE and
our risk weight.
Note: Banks that use the BA-CVA for calculating CVA capital requirements are
allowed to cap the maturity adjustment factor MA(PD, M ) in section A.11 at 1 for
netting sets that contribute to CVA capital, if using the IRB approach for CCR capital.

A.13 Collateral Model

The collateral model implemented in ORE is based on the evolution of collateral
account balances along each Monte Carlo path taking into account thresholds,
minimum transfer amounts and independent amounts defined in the CSA, as well as
margin periods of risk.
ORE computes the collateral requirement (aka Credit Support Amount) through time
along each Monte Carlo path
(
max(0, NPV (tm ) + IA − TH rec ), NPV (tm ) + IA ≥ 0
CSA(tm ) = (37)
min(0, NPV (tm ) + IA + TH pay ), NPV (tm ) + IA < 0

where
• NPV (tm ) is the value of the netting set as of time tm from our persepctive,
• TH rec is the threshold exposure below which we do not require collateral,
likewise pay is the threshold that applies to collateral posted to the counterparty,
• IA is the sum of all collateral independent amounts attached to the underlying
portfolio of trades (positive amounts imply that we have received a net inflow of
independent amounts from the counterparty), assumed here to be cash.
As the collateral account already has a value of C(tm ) at time tm , the collateral
shortfall is simply the difference between C(tm ) and CSA(tm ). However, we also need
to account for the possibility that margin calls issued in the past have not yet been
settled (for instance, because of disputes). If M (tm ) denotes the net value of all
outstanding margin calls at tm , and ∆(t) is the difference

∆(t) = CSA(tm ) − C(tm ) − M (tm )

804
between the Credit Support Amount and the current and outstanding collateral, then
the actual margin Delivery Amount D(tm ) is calculated as follows:
(
∆(t), |∆(t)| ≥ M T A
D(tm ) = (38)
0, |∆(t)| < M T A

where M T A is the minimum transfer amount.

Consider the upper case of (37): If the initial value of the netting set is zero
(NPV (t0 ) = 0) and if TH rec = 0, but the combined IA > 0, then the Credit Support
Amount equals the Independent Amount, CSA(t0 ) = IA. If moreover the initial
collateral balance is zero (because the Independent Amount has not been received yet),
then ∆(t0 ) = CSA(t0 ) = IA, and the delivery amount D(t0 ) also matches the IA
(assuming this exceeds the MTA), so that the next call leads to the transfer of the
Independent Amount to us. For a positive TH rec > 0, the transfer to us is reduced
accordingly. In that case we can view the Independent Amount as an offset to the
threshold.
Consider the lower case of (37): If the netting set value is negative from our
perspective and in absolute terms larger than the IA, then the Credit Support Amount
is just the negative difference CSA = −|NPV | + IA + TH pay so that we need to post
collateral, but only the amount beyond the combined threshold IA + TH pay .

Margin Period of Risk

After a counterparty defaults, it takes time to close out the portfolio. During this time
period the portfolio value will change upon market conditions, therefore the portfolio’s
close-out value is subject to market risk, which is referred also as the close-out risk and
the corresponding close-out period is called as the Margin Period of Risk (MPoR).
Therefore, when a loss on the defaulted counterparty is realised at time td , the last
time the collateral could be received is td − τ , where τ denotes the MPoR. That is, the
collateral at time td is determined by the collateral value at td − τ , namely
CSA(td − τ ), see equation 37.
In ORE, we have two approaches to incorporate MPoR in the exposure simulations:
• Close-out Approach: Simulating on an auxiliary close-out grid additional to the
default time grid.
• Lagged Approach: Simulating only on a default time grid and delaying the
margin calls on the grid.

In the Close-out Approach, we use an auxiliary “close-out” grid in addition to the main
simulation grid (see section 7.4). The main simulation grid is used to compute “default
values” which feed into the collateral balance C(t) filtered by MTA and Threshold etc.
The auxiliary “close-out” grid, offset from the main grid by the MPoR, is used to
compute the delayed close-out values V (t) associated with default time t18 . The
difference between V (t) and C(t) causes a residual exposure [V (t) − C(t)]+ even if
18
We note that in ORE when the exposure of an uncollateralised netting-set or a single trade without
considering the netting-set is calculated, then the default value is calculated at the main simulation
grid, not on the close-out grid.

805
minimum transfer amounts and thresholds are zero, see for example [17]. This
approach allows a detailed modelling of what happens in the close-out period by
calculating the close-out values in different ways. ORE currently supports two options:
• the close-out value can be computed as of default date, by just evolving the
market from default date to close-out date (“sticky date”), or
• the close-out value can be computed as of close-out date, by evolving both
valuation date and market over the close-out period (“actual date”), i.e., the
portfolio ages and cash flows might occur in the close-out period causing spikes
in the evolution of exposures.
The option “sticky date” is more aggressive in that it avoids any exposure evolution
spikes due to contractual cashflows that occur in the close-out period after default, the
only exposure effect is due to market evolution over the period. The “actual date”
option is more conservative in that it includes the effect of all contractual cash flows in
the close-out period, in particular outgoing cashflows at any time in the period which
cause an exposure jump upwards. A more detailed framework for collateralised
exposure modelling is introduced in the article [23], indicating a potential route for
extending ORE.

On the other hand, in the Lagged Approach the simulation is conducted only on a
default time grid. The collateral values are calculated, by delaying the delivery
amounts between default times, specified by the Margin Period of Risk (MPoR) which
leads to residual exposure.
In table 95, we present a toy example to illustrate how the delayed margin calls lead to
residual exposures. In this example, we assume that the default time grid is
equally-spaced with time steps that match the MPoR (which is 1M). Further, we
assume zero threshold and MTA. At the initial time, the delivery amount is 2.00,
which is the difference between the initial value of the portfolio and the default value
at 1M. If this amount were settled immediately, then the collateral value would have
been 10 and hence the residual exposure would habe been zero at 1M. The delay of the
delivery amount by MPoR implies a collateral value of 8.00 until 1M and hence a
residual exposure of 2.

Time Default Delivery Delivery Collateral NPV

Grid Value Amount Amount Value
Delayed
0 8.00 2.00 True
1M 10.00 5.00 True 8.00 10.00
2M 15.00 -3.00 True 10.00 15.00
3M 12.00 -3.00 True 15.00 12.00
4M 9.00 5.00 True 12.00 9.00
5M 14.00 6.00 True 9.00 14.00
6M 20.00 14.00 20.00

Table 95: Toy example for delayed margin calls.

Some remarks and observations:

806
 • Lagged Approach has the disadvantage that we need to use equally-spaced time
grids with time steps that match the MPoR. In the above example, let us assume
that the MPoR is 2W. Then, delaying the first delivery amount by 2W would
still imply a collateral value of 10.00 at 1M and hence a zero residual exposure.
• In Lagged Approach approach, we support three calculation (settlement) types
where the delay of the Delivery Amount depends on its sign. The above example
corresponds to a “symmetric” calculation type where both positive and negative
delivery amounts are settled with delay, see section 7.1.4 for other calculation
types.
• In ORE, the Close-out Approach is the preferred method -and the Lagged
Approach is the legacy method- to incorporate MPoR in the collateral model.

A.14 Exposure Allocation

XVAs and exposures are typically computed at netting set level. For accounting
purposes it is typically required to allocate XVAs from netting set to individual trade
level such that the allocated XVAs add up to the netting set XVA. This distribution is
not trivial, since due to netting and imperfect correlation single trade (stand-alone)
XVAs hardly ever add up to the netting set XVA: XVA is sub-additive similar to VaR.
ORE provides an allocation method (labeled marginal allocation in the following)
which slightly generalises the one proposed in [18]. Allocation is done pathwise which
first leads to allocated expected exposures and then to allocated CVA/DVA by
inserting these exposures into equations (28,29). The allocation algorithm in ORE is as
follows:
• Consider the netting set’s discounted NPV after taking collateral into account,
on a given path at time t:

E(t) = D(0, t) (NPV (t) − C(t))

• On each path, compute contributions Ai of the latter to trade i as


E(t) × NPV i (t)/NPV (t), |NPV (t)| > ϵ
Ai (t) =
E(t)/n, |NPV (t)| ≤ ϵ

with number of trades n in the netting set and trade i’s value NPV i (t).
• The EPE fraction allocated to trade i at time t by averaging over paths:

EPE i (t) = E A+
 
i (t)

By construction, i Ai (t) = E(t) and hence i EPE i (t) = EPE (t).

P P
We introduced the cutoff parameter ϵ > 0 above in order to handle the case where the
netting set value NPV (t) (almost) vanishes due to netting, while the netting set
’exposure’ E(t) does not. This is possible in a model with nonzero MTA and MPoR.
Since a single scenario with vanishing NPV (t) suffices to invalidate the expected
exposure at this time t, the cutoff is essential. Despite introducing this cutoff, it is
obvious that the marginal allocation method can lead to spikes in the allocated
exposures. And generally, the marginal allocation leads to both positive and negative
EPE allocations.

807
As a an example for a simple alternative to the marginal allocation of EPE we provide
allocation based on today’s single-trade CVAs
X
wi = CVAi / CVAi .
i

This yields allocated exposures proportional to the netting set exposure, avoids spikes
and negative EPE , but does not distinguish the ’direction’ of each trade’s contribution
to EPE and CVA.

A.15 Sensitivity Analysis

ORE’s sensitivity analysis framework uses “bump and revalue” to compute Interest
Rate, FX, Inflation, Equity and Credit sensitivities to
• Discount curves (in the zero rate domain)
• Index curves (in the zero rate domain)
• Yield curves including e.g. equity forecast yield curves (in the zero rate domain)
• FX Spots
• FX volatilities
• Swaption volatilities, ATM matrix or cube
• Cap/Floor volatility matrices (in the caplet/floorlet domain)
• Default probability curves (in the “zero rate” domain, expressing survival
probabilities S(t) in term of zero rates z(t) via S(t) = exp(−z(t) × t) with
Actual/365 day counter)
• Equity spot prices
• Equity volatilities, ATM or including strike dimension
• Zero inflation curves
• Year-on-Year inflation curves
• CDS volatilities
• Base correlation curves
Apart from first order sensitivities (deltas), ORE computes second order sensitivities
(gammas and cross gammas) as well. Deltas are computed using up-shifts and base
values as
f (x + ∆) − f (x)
δ= ,
∆
where the shift ∆ can be absolute or expressed as a relative move ∆r from the current
level, ∆ = x ∆r . Gammas are computed using up- and down-shifts
f (x + ∆) + f (x − ∆) − 2 f (x)
γ= ,
∆2
cross gammas using up-shifts and base values as
f (x + ∆x , y + ∆y ) − f (x + ∆x , y) − f (x, y + ∆y ) + f (x, y)
γcross = .
∆x ∆y

808
From the above it is clear that this involves the application of 1-d shifts (e.g. to
discount zero curves) and 2-d shifts (e.g. to Swaption volatility matrices). The
structure of the shift curves/matrices does not have to match the structure of the
underlying data to be shifted, in particular the shift “curves/matrices” can be less
granular than the market to be shifted. Figure 36 illustrates for the one-dimensional
case how shifts are applied.

shifted curve grid points

shift curve grid points

Figure 36: 1-d shift curve (bottom) applied to a more granular underlying curve (top).

Shifts at the left and right end of the shift curve are extrapolated flat, i.e. applied to
all data of the original curve to the left and to the right of the shift curve ends. In
between, all shifts are distributed linearly as indicated to the left and right up to the
adjacent shift grid points. As a result, a parallel shift of the all points on the shift
curve yields a parallel shift of all points on the underlying curve.
The two-dimensional case is covered in an analogous way, applying flat extrapolation at
the boundaries and “pyramidal-shaped” linear interpolation for the bulk of the points.
The details of the computation of sensitivities to implied volatilities in strike direction
can be summarised as follows, see also table 96 for an overview of the admissible
configurations and the results that are obtained using them.

For Swaption Volatilities, the initial market setup can be an ATM surface only or a full
cube. The simulation market can be set up to simulate ATM only or to simulate the
full cube, but the latter choice is only possible if a full cube is set up in the initial
market. The sensitivity set up must match the simulation setup with regards to the
strikes (i.e. it is ATM only if and only if the simulation setup is ATM only, or it must
contain exactly the same strike spreads relative to ATM as the simulation setup).
Finally, if the initial market setup is a full cube, and the simulation / sensitivity setup
is to simulate ATM only, then sensitivities are computed by shifting the ATM
volatility w.r.t. the given shift size and type and shifting the non-ATM volatilities by
the same absolute amount as the ATM volatility.

For Cap/Floor Volatilities, the initial market setup always contains a set of fixed
strikes, i.e. there is no distinction between ATM only and a full surface. The same
holds for the simulation market setup. The sensitivity setup may contain a different
strike grid in this case than the simulation market. Sensitivity are computed per
expiry and per strike in every case.

For Equity Volatilities, the initial market setup can be an ATM curve or a full surface.
The simulation market can be set up to simulate ATM only or to simulate the full

809
surface, where a full surface is allowed even if the initial market setup in an ATM
curve only. If we have a full surface in the initial market and simulate the ATM curve
only in the simulation market, sensitivities are computed as in the case of Swaption
Volatilities, i.e. the ATM volatility is shifted w.r.t. the specified shift size and type and
the non-ATM volatilities are shifted by the same absolute amount as the ATM
volatility. If the simulation market is set up to simulate the full surface, then all
volatilities are shifted individually using the specified shift size and type. In every case
the sensitivities are aggregated on the ATM bucket in the sensitivity report.

For FX Volatilities, the treatment is similar to Equity Volatilities, except for the case
of a full surface definition in the initial market and an ATM only curve in the
simulation market. In this case, the pricing in the simulation market is using the ATM
curve only, i.e. the initial market’s smile structure is lost.

For CDS Volatilities only an ATM curve can be defined.

In all cases the smile dynamics is “sticky strike”, i.e. the implied vol used for pricing a
deal does not change if the underlying spot price changes.
Type Init Mkt. Config. Sim. Mkt Config. Sensitivity Config. Pricing Sensitivities w.r.t.
Swaption ATM Simulate ATM only Shift ATM only ATM Curve ATM Shifts
Swaption Cube Simulate Cube Shift Smile Strikes Full Cube Smile Strike Shiftsa
Swaption Cube Simulate ATM only Shift ATM only Full Cube ATM Shiftsb
Cap/Floor Surface Simulate Surface Shift Smile Strikes Full Surface Smile Strike Shifts
Equity ATM Simulate ATM only Shift ATM only ATM Curve ATM Shifts
Equity ATM Simulate Surface Shift ATM only ATM Curve Smile Strike Shiftsc
Equity Surface Simulate ATM only Shift ATM only Full Surface ATM Shiftsb
Equity Surface Simulate Surface Shift ATM only Full Surface Smile Strike Shiftsc
FX ATM Simulate ATM only Shift ATM only ATM Curve ATM Shifts
FX ATM Simulate Surface Shift ATM only ATM Curve Smile Strike Shiftsc
FX Surface Simulate ATM only Shift ATM only ATM Curve ATM Shifts
FX Surface Simulate Surface Shift ATM only Full Surface Smile Strike Shiftsc
CDS ATM Simulate ATM only Shift ATM only ATM Curve ATM Shifts

Table 96: Admissible configurations for Sensitivity computation in ORE

a
smile strike spreads must match simulation market configuration
b
smile is shifted in parallel
c
result sensitivities are aggregated on ATM

A.16 Par Sensitivity Analysis

The “raw” sensitivities in ORE are generated in a computationally convenient domain
(such as zero rates, caplet/floorlet volatilities, integrated hazard rates, inflation zero
rates). These raw sensitivities are typically further processed in risk analytics such as
VaR measures. On the other hand, for hedging purposes one is rather interested in
sensitivities with respect to fair rates of hedge instruments such as Forward Rate
Agreements, Swaps, flat Caps/Floors, CDS, Zero Coupon Inflation Swaps.
It is possible to generate par sensitivities from raw sensitivities using the chain rule as
follows, and this is the approach taken in ORE. Recall for example the fair swap rate c
for some maturity as a function of zero rates zi in a single curve setting:

1 − e−zn tn
c= n
P −zi ti
i=1 δi e

810
More realistically, a given fair swap rate might be a function of the zero rates spanning
the discount and index curves in the chosen currency. In a multi currency curve
setting, that swap rate might even be a function of the zero rates spanning a foreign
(collateral) currency discount curve, foreign and domestic currency index curves.
Generally, we can write any fair par rate ci as function of raw rates zj ,

ci ≡ ci (z1 , z2 , ..., zn )

This function may not be available in closed form, but numerically we can evaluate the
sensitivity of ci with respect to changes in all raw rates,
∂ci
.
∂zj

These sensitivities form a Jacobi matrix of derivatives. Now let V denote some trade’s
price. Its sensitivity with respect a raw rate change ∂V /∂zk can then be expressed in
terms of sensitivities w.r.t. par rates using the chain rule
n
∂V X ∂V ∂ci
= ,
∂zj i=1
∂c i ∂z j

or in vector/matrix form

∂ci
∇z V = C · ∇c V, Cji = .
∂zj

Given the raw sensitivity vector ∇z V , we need to invert the Jacobi matrix C to obtain
the par rate sensitivity vector
∇c V = C −1 · ∇z V.

We then compute the Jacobi matrix C by

• setting up par instruments with links to all required term structures expressed in
terms of raw rates
• “bumping” all relevant raw rates and numerically computing the par instrument’s
fair rate shift for each bump
• thus filling the Jacobi matrix with finite difference approximations of the partial
derivatives ∂ci /∂zj .
The par rate conversion supports the following par instruments:
• Deposits
• Forward rate Agreements
• Interest Rate Swaps (fixed vs. ibor)
• Overnight Index Swaps
• Tenor Basis Swaps (ibor vs. ibor)
• Overnight Index Basis Swaps (ibor vs. OIS)
• FX Forwards

811
 • Cross Currency Basis Swaps
• Credit Default Swaps
• Caps/Floors

A.17 Economic P&L

The economic P&L of a portfolio denotes the change in its economic value over a time
period t1 to t2 . The economic value evolution during the period is due to three
components
• the change in present value from period start to end
• incoming and outgoing cash flows
• accumulated cost of funding required to set up the portfolio initially
In the following, we consider a portfolio consisting of assets in various currencies. We
decompose the portfolio into parts each denominated in a different currency and value
each sub-portfolio in its currency. We denote the sub-portfolio values at time t in the
respective currency P1 (t), P2 (t), . . . . Instruments with cash flows in more than one
currency are decomposed into single-currency instruments and assigned into the related
sub-portfolio. The total portfolio value expressed in base currency (e.g. EUR) is
X
P (t) = Pc (t) Xc (t) (39)
c

where Xc is the exchange rate that converts an amount in currency c into an amount
in base currency by multiplication. All prices Pc (t) denote dirty market values (or
theoretical values where market values are not available) at time t.
In the following we consider three points in time,
• t0 : the time just before the first actual cash flow has appeared in the portfolio
under consideration, possibly years ago
• t1 : the beginning of the period for which we want to determine P&L
• t2 : the end of the period for which we want to determine P&L

Original P&L
The original P&L is the portfolio’s P&L from portfolio inception t0 . In this case the
portfolio value at t0 is
P (t0 ) = 0,
and the P&L up to time t2 is given by the portfolio value at t2 plus the balance of
currency accounts that collect incoming and outgoing cash flows and are compounded
up to time t2 : X
π(0, t2 ) = P (t2 ) + Xc (t2 ) Bc (t2 ) (40)
c
where
I(t2 )−1 I(t2 )−1
X Y
Bc (t2 ) = Fc (τj ) Cc (τj , t2 ), Cc (τj , t2 ) = (1 + rc (τk )δk ), (41)
j=0 k=I(τj )

812
sums and products are taken over daily time steps τj and

I(t) is the day’s index associated with time t

Fc (τj ) is the net cash flow in currency c on date/time τj , pos-
sibly zero
rc (τj ) is the Bank’s overnight funding and investment rate in
currency c for interest period [τj , τj+1 ] (overnight)
δj is the related day count fraction for period [τj , τj+1 ]

The balances Bc can also be constructed iteratively

Bc (τj+1 ) = Bc (τj )(1 + rc (τj )δj ) + Fc (τj+1 )
j = 0, 1, 2, . . .
Bc (τ0 ) = 0.

The P&L for a period of interest [t1 ; t2 ] is then computed by taking the difference
π(t1 , t2 ) = π(0, t2 ) − π(0, t1 ) (42)
X
= P (t2 ) − P (t1 ) + (Xc (t2 ) Bc (t2 ) − Xc (t1 ) Bc (t1 ))
c

One can show that

I(t2 )−1
X
Bc (t2 ) = Bc (t1 ) Cc (t1 , t2 ) + Fc (τj ) Cc (τj , t2 ) (43)
j=I(t1 )

which separates the contribution to Bc (t2 ) from cash flows in period [t1 ; t2 ] (right-most
sum) and contributions from realized P&L and cost of funding of previous periods
accumulated in Bc (t1 ). We can now insert (43) into (42) to eliminate Bc (t2 ) and obtain
I(t2 )−1
X X
π(t1 , t2 ) = P (t2 ) − P (t1 ) + Xc (t2 ) Fc (τj ) Cc (τj , t2 )
c j=I(t1 )
X
+ Bc (t1 ) {Xc (t2 ) Cc (t1 , t2 ) − Xc (t1 )} (44)
c

Cost of Carry
Separating actual cash flows and prices from compounding effects yields
I(t2 )−1
X X
π(t1 , t2 ) = P (t2 ) − P (t1 ) + Xc (t2 ) Fc (τj ) + CC(t1 , t2 )
c j=I(t1 )

where the cost of carry term is

I(t2 )−1
X X
CC(t1 , t2 ) = Xc (t2 ) Fc (τj ) (Cc (τj , t2 ) − 1)
c j=I(t1 )
X
+ Bc (t1 ) {Xc (t2 ) Cc (t1 , t2 ) − Xc (t1 )} (45)
c

813
Period P&L after Sell-Down
At time t1 , we can write the original P&L (equation 40) in respective currencies
X
πc (t1 ) = Pc (t1 ) + Bc (t1 ), π(t1 ) = Xc (t1 ) πc (t1 ).
c

Inserting this into (45),

I(t2 )−1
X X
CC(t1 , t2 ) = Xc (t2 ) Fc (τj ) (Cc (τj , t2 ) − 1)
c j=I(t1 )
X
+ (πc (t1 ) − Pc (t1 )) {Xc (t2 ) Cc (t1 , t2 ) − Xc (t1 )} ,
c

shows that there is a contribution to π(t1 , t2 ), via the cost of carry, due to
compounding and FX effects on previous periods’ P&L result.

We now take the view that the portfolio is liquidated at time t1 , so that the account
balance equals the P&L at t1 . We further assume that this balance is then removed
("sell down" of P&L) and transfered into a separate portfolio, the Bank’s equity19 .
The same portfolio is thereafter set up again so that the currency account balance
turns into a liability Bc (t1 ) = −Pc (t1 ), and the total starting balance is
B(t1 ) = −P (t1 ). In contrast to the previous section, this changes the balance at time
t1 suddenly and without relation to an actual cash flow.
This raises the question how the artificial initial balance is funded subsequently, in
currency for each sub-portfolio or in base currency only. This choice may vary by
portfolio, depend on the actual currencies in which the Bank can source funding,
depend on the location/economy in which the portfolio is run, which currency is a
reasonable benchmark, etc.

Funding in Currency
In this section we take the view that each sub-portfolio is funded in currency so that
we start with opening balances Bc (t1 ) = −Pc (t1 ).
Inserting the artificial opening balances at t1 into (44) yields
I(t2 )−1
X X
π2 (t1 , t2 ) = P (t2 ) − P (t1 ) + Xc (t2 ) Fc (τj ) Cc (τj , t2 )
c j=I(t1 )
X
− Pc (t1 ) {Xc (t2 ) Cc (t1 , t2 ) − Xc (t1 )}
c
I(t2 )−1
X X
= P (t2 ) + Xc (t2 ) Fc (τj ) Cc (τj , t2 )
c j=I(t1 )
X
− Pc (t1 ) Xc (t2 ) Cc (t1 , t2 ) (46)
c

Note that only exchange rates at t2 enter into the expression.

19
Equity is in turn managed and most likely invested into financial instruments other than a Bank
account

814
Cost of Carry
Separating actual cash flows and prices from compounding effects yields
 
 I(t2 )−1 
X X
π2 (t1 , t2 ) = P (t2 ) + Xc (t2 ) −Pc (t1 ) + Fc (τj ) + CC2 (t1 , t2 )
c
 
j=I(t1 )

where the cost of carry term is

I(t2 )−1
X X
CC2 (t1 , t2 ) = Xc (t2 ) Fc (τj ) (Cc (τj , t2 ) − 1)
c j=I(t1 )
X
− Xc (t2 ) Pc (t1 ) (Cc (t1 , t2 ) − 1)
c

Funding in Base Currency

In this section we assume that the setup cost for the portfolio is converted into base
currency at t1 and funded subsequently in base currency. This means we insert
artificial initial balances Bc (t1 ) = 0 except for the base currency account
B(t1 ) = −P (t1 ). Inserting this opening balance at t1 into (44) now yields
I(t2 )−1
X X
π3 (t1 , t2 ) = P (t2 ) + Xc (t2 ) Fc (τj ) Cc (τj , t2 )
c j=I(t1 )

−P (t1 ) C(t1 , t2 ) (47)

where C(t1 , t2 ) is the compounding factor in base currency.

Cost of Carry
Separating actual cash flows and prices from compounding effects yields now

I(t2 )−1
X X
π3 (t1 , t2 ) = P (t2 ) − P (t1 ) + Xc (t2 ) Fc (τj ) + CC3 (t1 , t2 )
c j=I(t1 )

where
I(t2 )−1
X X
CC3 (t1 , t2 ) = Xc (t2 ) Fc (τj ) (Cc (τj , t2 ) − 1)
c j=I(t1 )

−P (t1 ) (C(t1 , t2 ) − 1)

FX Effect
The difference between (46) and (40) is

X
π2 (t1 , t2 ) − π3 (t1 , t2 ) = P (t1 ) C(t1 , t2 ) − Pc (t1 ) Xc (t2 ) Cc (t1 , t2 ).
c

The expected value of this difference at period start t1 is zero, but the retrospectively
realized difference at period end t2 is nonzero in general.

815
A.18 Risk Hypothetical P&L
In the following we briefly describe approaches to generating P&L vectors that feed
into several subsequent sections for the purpose of computing risk measures such as
Value at Risk or for backtesting a market risk model.
These P&L’s are different from the economic P&L introduced in section A.17 above,
but rather risk-hypothetical due to the application of some historical market moves to
the current market which gives rise to a valuation change.
Consider a history of market risk factors Xi (j) where i ∈ {1, . . . , n} identifies the risk
factor and j ∈ {1, . . . , m} corresponds to a time tj on which the risk factor was
observed. The times are assumed to be equally spaced, with tj+1 − tj corresponding to
1 business day w.r.t. a given calendar. To generate an overlapping k-day PL, define
the k day return at time tj to be

ri (j) = RTi (Xi (j), Xi (j + k)) (48)

for j = 1, . . . , m − k. Note that the case of non-overlapping k day returns fits in with
straightforward modifications of the scheme described here. R defines the return value
for two observations of the same factor, which is one of the following

RA (x, y) = y − x (49)
RR (x, y) = y/x − 1 (50)
RL (x, y) = log(y/x) (51)

where the subscript stands for absolute (A), relative (R) and lognormal (L) returns,
respectively. Note that the relative and lognormal returns are not defined for x = 0,
and we consider a data point with Xi (j) = 0 and for which we compute relative or
lognormal returns to be an error in the data that needs to be corrected or excluded
from the analysis. Also note that RR ≈ RL for small values of y/x − 1, the difference
RR − RL approaching zero when y/x approaches 1.
Now assume tm to be the reference date (e.g. for the value at risk calculation) and

X(m) = {Xi (m)}i=1,...,n (52)

the market factor values on the reference date.

Full Revaluation P&L

For a given portfolio denote its NPV at tm by ν(X(m)). Then we can compute a full
revaluation PL vector

πF = {πF (j)}j=1,...,m−k (53)

as

816
 πF (j) = ν(X ′ (m, j)) − ν(X(m)) (54)

by pricing the portfolio under each perturbed market factor vector

X ′ (m, j) = {Xi′ (m, j)}i=1,...,n (55)

which is defined by

Xi′ (m, j) = aTi (Xi (m), RTi (Xi (j), Xi (j + k))) (56)

with the return application function

aA (x, r) = x + r (57)
aR (x, r) = x(1 + r) (58)
aL (x, r) = xer (59)

and return types Ti ∈ {A, R, L}, dependent on the particular factor Xi . Table 97
shows a possible choice of return types for the different risk factors (in ORE notation).
Note, that the factors Discount Curve, Index Curve and Survival Probability are
discount factors resp. survival probabilities that are converted to zero rate resp.
hazard rate shifts by taking the log. Also note, that the factors Recovery Rate and
Basis Correlation are bounded (a recovery rate must be in [0, 1] while the base
correlation must be in [−1, 1]), so that after a shift is applied, the result has to be
capped / floored appropriately to ensure valid scenario values.

Sensitivity based P&L

As an alternative to the full revaluation PL in (53) we can approximate this PL using
a Taylor expansion of ν(X ′ (m, j)) viewed as a function of the returns RTi 20 around the
expansion point (0, 0, . . . , 0) generating a sensitivity based PL,

πS = {πS (j)}j=1,...,m−k (60)

with

n
X
πS (j) = DTi i ν(X(m))RTi (Xi (m), Xi′ (m, j))+
i=1
n (61)
1 X i,l
DTi ,Tl ν(X(m))RTi (Xi (m), Xi′ (m, j))RTl (Xl (m), Xl′ (m, j)),
2 i,l=1

where we use sensitivities up to second order. Here DTi i denotes a first or second order
derivative operator, depending on the market factor specific shift type Ti ∈ {A, R, L},
i.e.
20
i.e. we view ν as a function of the second argument of aTi in 56

817
 ∂f (x)
i
DA f (x) = , (62)
∂xi
∂f (x)
i
DR f (x) = DLi f (x) = xi (63)
∂xi

and using the short hand notation

DTi,li ,Tl f (x) = DTi i DTl l f (x). (64)

These first and second order sensitivities may be computed analytically, or (more
common) as finite difference approximations (“bump and revalue” approximations), see
section A.15. To clarify the relationship of (62) and a finite difference scheme for
derivatives computation in a bit more detail we note that for a absolute shift h > 0

f (x + h) − f (x)
→ f ′ (x) (65)
h
for h → 0 by definition of f ′ while for a relative shift

f (x(1 + h)) − f (x) f (x(1 + h)) − f (x)

=x → xf ′ (x) (66)
h xh
for h → 0 and for a log shift

f (xeh ) − f (x)
→ xf ′ (x) (67)
h
using e.g. L’Hospital’s rule, so that
• both a relative and a log shift bump and revalue sensitivity approximate the
same value xf ′ (x) in the limit for h → 0,
• an absolute shift sensitivity can be transformed into a relative / log shift
sensitivity (in the limit for h → 0) by multiplying with the risk factor value x,
and vice versa.
We also note that the usual way of bumping continuously compounded zero rates to
compute a Discount Curve or Index Curve sensitivity by h∗ is equivalent to (67) with
h = h∗ t, where t is the maturity of the respective rate. Therefore in practice a log
return of discount factors can not directly be combined with a sensitivity expressed in
zero rate shifts, but has to be scaled by 1/t before doing so.
Since the number of second order deriviatives can be quite big in realistic setups with
hundreds or even thousands of market factors, in practice only part of the second order
deriviatives might be fed into (61) assuming the rest to be zero.
Note that the types Ti used to generate the historical returns (56) can be different
from those used in the Taylor expansion (61). It is important though that the same
types Ti are used for the derivatives operators DTi i and the returns RTi in (61).

818
A number of configurations are hard-coded into ORE depending on whether raw
sensitivities, backtesting sensitivities or CRIF sensitivities are being called. These
configurations are displayed in 97 - note that there is currently no distinction made in
ORE between raw sensitivities and backtest sensitivities.

Backtest Sensitivities CRIF Sensitivities

ORE Risk Factor
Return Type Shift Size Return Type Shift Size
Discount Curve A 0.01% A 0.01%
Index Curve A 0.01% A 0.01%
Yield Curve A 0.01% A 0.01%
Dividend Yield A 0.01% A 0.01%
Equity Forecast Curve A 0.01% A 0.01%
Swaption Volatility* R 1% A 0.01%
Optionlet Volatility* R 1% A 0.01%
FX Spot** R 1% R 0.1%
FX Volatility R 1% A 1%
Equity Spot R 1% R 1%
Equity Volatility R 1% A 1%
Yield Volatility R 1% R 1%
Survival Probability A 0.01% A 0.01%
CDS Volatility R 1% R 1%
Correlation R 1% - -
Base Correlation A 1% A 1%
Zero Inflation Curve A 0.01% A 0.01%
YoY Inflation Curve A 0.01% A 0.01%
Zero Inflation CF Vol R 1% R 1%
YoY Inflation CF Vol R 1% R 1%
Commodity Curve R 1% R 1%
Commodity Volatility R 1% A 1%
Security Spread A 0.01% - -

Table 97: Sensitivity return type configuration for raw, backtest and CRIF sensitivities

819
*We predominantly use normal IR volatilities with an absolute shift of 0.01%. For
lognormal IR volatilities an absolute shift of 1% applies. Also, notice that “Optionlet
Volatility” is the ORE name for “Cap / Floor Volatility”.
**During a CRIF run, the FX spot delta is computed using the central difference
approximation by default. A smaller shift size of 0.1% is used because of this.
Furthermore, for FX vanilla European and American options, there are analytic
formulae available for FX deltas. These are implemented in ORE during a CRIF run.
Note - the values A and R here refer to the absolute and relative shifts defined in (62).

A.19 Value at Risk

Historical Simulation VaR
The historical simulation VaR is defined to be a p-quantile of the empirical distribution
generated by the full revaluation PL vector πF = {πF (j)}j . Here, with “generated” we
mean that we weigh each πF (j) with the same probability 1/J, where J denotes the
number of elements in the vector.

Historical Simulation Taylor VaR

Similarly, the historical simulation Taylor VaR is defined to be the p-quantile of the
empirical distribution generated by the sensitivity based PL vector πS (call side), resp.
−πS (post side).

Parametric VaR
For the computation of the parametric, or variance-covariance VaR, we rely on a
second order sensitivity-based P&L approximation

n n
X 1 X i,j
πS = DTi i V · Yi + D V · Yi · Yj (68)
i=1
2 i,j=1 Ti ,Tj

with
• portfolio value V
• random variables Yi representing risk factor returns; these are assumed to be
multivariate normally distributed with zero mean and covariance matrix matrix
C = {ρi,k σi σk }i,k , where σi denotes the standard deviation of Yi ; covariance
matrix C may be estimated using the Pearson estimator on historical return data
{ri (j)}i,j . Since the raw estimate might not be positive semidefinite, we apply a
salvaging algorithm to ensure this property, which basically replaces negative
Eigenvalues by zero and renormalises the resulting matrix, see [27];
• first or second order derivative operators D, depending on the market factor
specific shift type Ti ∈ {A, R, L} (absolute shifts, relative shifts, absolute

820
 log-shifts), i.e.

i ∂V (x)
DA V (x) =
∂xi
i ∂V (x)
DR V (x) = DLi f (x) = xi
∂xi
and using the short hand notation

DTi,ji ,Tj V (x) = DTi i DTj j V (x)

In ORE, these first and second order sensitivities are computed as finite
difference approximations (“bump and revalue”).
To approximate the p-quantile of πS in (68) ORE offers the techniques outlined below.

Delta Gamma Normal Approximation

The distribution of (68) is non-normal due to the second order terms. The delta
gamma normal approximation in ORE computes mean m and variance v of the
portfolio value change πS (discarding moments higher than two) following [28] and
provides a simple VaR estimate
√
V aR = m + N −1 (q) v

for the desired quantile q (N is the cumulative standard normal distribution).

Omitting the second order terms in (68) yields the delta normal approximation.

Cornish-Fisher Expansion
The first four moments of the distribution of πS in (68) can be computed in closed
form using the covariance matrix C and the sensitivities of first and second order Di
and Di,k , see e.g. [28]. Once these moments are known, an approximation to the true
quantile of πS can be computed using the Cornish-Fisher expansion, see also [7], which
in practice often gives a decent approximation of the true value, but may also show
bigger differences in certain configurations.

Saddlepoint Approximation
Another approximation of the true quantile of πS can be computed using the
Saddlepoint approximation using results from [29] and [30]. This method typically
produces more accurate results than the Cornish-Fisher method, while still being fast
to evaluate.

Monte Carlo Simulation

By simulating a large number of realisations of the return vector Y = {Yi }i and
computing the corresponding realisations of πS in (68) we can estimate the desired
quantile as the quantile of the empirical distribution generated by the Monte Carlo
samples. Apart from the Monte Carlo Error no approximation is involved in this
method, so that albeit slow it is well suited to produce values against which any other
approximate approaches can be tested. Numerically, the simulation is implemented

821
using a Cholesky Decomposition of the covariance matrix C in conjunction with a
pseudo random number generator (Mersenne Twister) and an implementation of the
inverse cumulative normal distribution to transform U [0, 1] variates to N (0, 1) variates.

References
[1] [Link]
[2] [Link]
[3] [Link]
[4] [Link]
[5] [Link]
[6] [Link]
[7] [Link]
[8] [Link]
[9] [Link]
[10] [Link]
[11] [Link]
[12] Basel Committee on Banking Supervision, International Convergence of Capital
Measurement and Capital Standards, A Revised Framework,
[Link] June 2006
[13] Basel Committee on Banking Supervision, Basel III: A global regulatory
framework for more resilient banks and banking systems,
[Link] June 2011
[14] Basel Committee on Banking Supervision, Review of the Credit Valuation
Adjustment Risk Framework, [Link] 2015
[15] Basel Committee on Banking Supervision, Basel III: Finalising post-crisis
reforms, [Link] 2017
[16] Damiano Brigo and Fabio Mercurio, Interest Rate Models: Theory and Practice,
2nd Edition, Springer, 2006.
[17] Michael Pykhtin, Collateralized Credit Exposure, in Counterparty Credit Risk, (E.
Canabarro, ed.), Risk Books, 2010
[18] Michael Pykhtin and Dan Rosen, Pricing Counterparty Risk at the Trade Level
and CVA Allocations, Finance and Economics Discussion Series, Divisions of
Research & Statistics and Monetary Affairs, Federal Reserve Board, Washington,
D.C., 2010
[19] Jon Gregory, Counterparty Credit Risk and Credit Value Adjustment, 2nd Ed.,
Wiley Finance, 2013.
[20] Jon Gregory, The xVA Challenge, 3rd Ed., Wiley Finance, 2015.

822
[21] Roland Lichters, Roland Stamm, Donal Gallagher, Modern Derivatives Pricing
and Credit Exposure Analysis, Theory and Practice of CSA and XVA Pricing,
Exposure Simulation and Backtesting, Palgrave Macmillan, 2015.
[22] Fabrizio Anfuso, Daniel Aziz, Paul Giltinan, Klearchos Loukopoulos, A Sound
Modelling and Backtesting Framework for Forecasting Initial Margin Requirements,
[Link] 2016
[23] Leif B. G. Andersen, Michael Pykhtin, Alexander Sokol, Rethinking Margin Period
of Risk, [Link] 2016
[24] ISDA SIMM Methodology, version 2.5A, (based on v2.5a)
[Link]
[25] Andersen, L., and Piterbarg, V. (2010): Interest Rate Modeling, Volume I-III
[26] Peter Caspers, Paul Giltinan, Paul; Lichters, Roland; Nowaczyk , Nikolai.
Forecasting Initial Margin Requirements – A Model Evaluation, Journal of Risk
Management in Financial Institutions, Vol. 10 (2017), No. 4,
[Link]
[27] R. Rebonato and P. Jaeckel, The most general methodology to create a valid
correlation matrix for risk management and option pricing purposes, The Journal
of Risk, 2(2), Winter 1999/2000,
[Link]
[28] Carol Alexander, Market Risk Analysis, Volume IV, Value at Risk Models, Wiley
2009
[29] Lugannani, [Link] [Link] (1980), Saddlepoint Approximations for the Distribution
of the Sum of Independent Random Variables, Advances in Applied Probability,
12,475-490.
[30] Daniels, H. E. (1987), Tail Probability Approximations, International Statistical
Review, 55, 37-48.
[31] ORE Scripted Trade Module, latest version at https:
//[Link]/OpenSourceRisk/Engine/tree/master/Docs/ScriptedTrade

823