Guide to the ORE XML Trade Data Format

Content

Introduction
Trade Data

1. Introduction

This guide describes ORE XML, i.e. the XML representation of trades in ORE.

2. Trade Data

The trades that make up a 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 <portofolio> and a closing </portofolio> 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 portfolio.xml file with one Swap trade including the full envelope node is shown in Listing 1.

<Portfolio>
<Tradeid=”Swap#1“>
<TradeType>Swap</TradeType>
<Envelope>
<CounterParty>Counterparty#1</CounterParty>
<NettingSetId>NettingSet#2</NettingSetId>
<PortfolioIds>
<PortoliodId>PF#1</PortfolioId>
<PortoliodId>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>

Listing 1: 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 are two XML elements directly under the top level Portfolio node:

Trade id: The first element of each trade is the Trade id and it is used to identify trades within a portfolio. Trade ids should be unique within a portfolio. The Trade id element is entered as an attribute to the XML element <Trade>, such as <Trade id=”ExampleTrade”> in the beginning closed by </Trade> at the end of the trade data.
Allowable values: Any alphanumeric string. The underscore ( ) sign may be used as well.
TradeType: ORE currently supports 14 trade types.
Allowable values: ForwardRateAgreement, Swap, CapFloor, Swaption, FxForward, FxSwap, FxOption, EquityForward, EquityOption, EquitySwap, CommodityFor- ward, CommodityOption, CreditDefaultSwap, Bond

2.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 pur- poses 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 a unique identifier for the netting set. 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, el- ements 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.

2.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.

2.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 2.3.2. An example structure of a two-legged SwapData node is shown in Listing 2.

Listing 2: Swap data

2.2.2 Zero Coupon Swap

A Zero Coupon swap is set up as a swap, with one leg of type ZeroCouponFixed. Listing 3 shows an example. The ZeroCouponFixed leg contains an additional ZeroCouponFixedLegData block. See 2.3.13 for details on the ZeroCouponFixed leg specification

<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>

Listing 3: Zero Coupon Swap Data

2.2.3 Cap/Floor

The CapFloorData node is the trade data container for trade type CapFloors. 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 or CMS rates. 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 element must be set to Floating or CMS, plus elements for the Cap and Floor rates. An example structure with Cap rates is shown in in Listing 4.
A CapFloorData node must have either Caps or Floors elements, or both.

<CapFloorData>
<LongShort>Long</LongShort>
<LegData>
<Payer>false</Payer>
<LegType>Floating</LegType>
…
</LegData>
<Caps>
<Rate>0.05</Rate>
</Caps>
</CapFloorData>

Listing 4: Cap/Floor data

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 2.3.2. Exactly one LegData node is allowed and the LegType element must be set to Floating or CMS.
Caps: This node has child elements of type Cap capping the floating leg. 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. 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%

2.2.4 Forward Rate Agreement

A forward rate agreement is set up using a ForwardRateAgreementData block as shown in listing 5. The forward rate agreement specific elements are:

StartDate: A FRA expires/settles on the startDate.
Allowable values: See Date in Table 4.
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 4.
Currency: The currency of the FRA notional.
Allowable values: See Currency in Table 4.
Index: The name of the interest rate index the FRA is benchmarked against.
Allowable values: 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 7.
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.

<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>

Listing 5: Forward Rate Agreement Data

2.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 2.3.1 and section 2.3.2.
Supported swaption exercise styles are European and Bermudan. European swaptions can have unlimited number of legs, with each leg represented by a LegData sub-node. Bermudan swaptions must have two legs, i.e. two LegData sub-nodes. See Table 1 for further details on requirements for Bermudan swaptions. 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.
The structure of an example SwaptionData node of a two-legged European swaption is shown in Listing 6.

<SwaptionData>
<OptionData>
<Style>European</Style>
…
</OptionData>
<LegData>
<Currency>GBP</Currency>
…
</LegData>
<LegData>
<Currency>GBP</Currency>
…
</LegData>
</SwaptionData>

Listing 6: Swaption data

	A Bermudan Swaption requires:
OptionData	One OptionData sub-node
Style	Bermudan or European
ExerciseDates	Bermudan swaptions require at least two ExerciseDate child elements. European swaptions can only have one ExerciseDate child element. Note that the exercise date of a European swaption must be before or on the start date of the underlying swap.
LegData	Two LegData sub-nodes
Currency	The same currency for both nodes.
LegType	Bermudan swaptions must have: Fixed on one node and Floating on the other. No such requirement for European swaptions.

Table 1: Requirements for Bermudan Swaptions

2.2.6 FX Forward

The FXForwardData node is the trade data container for the FX Forward trade type. The structure – including example values – of the FXForwardData node is shown in Listing 7. It contains no sub-nodes.

Listing 7: FX Forward data

The meanings and allowable values of the various elements in the FXForwardData node follow below. All elements are required.

ValueDate: The value date of the FX Forward. Allowable values: See Date in Table 4.
BoughtCurrency: The currency to be bought on value date. Allowable values: See Currency in Table 4.
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 Currency in Table 4.
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 settlemen Delivery type does not impact pricing in ORE. Allowable values: Cash or Physical. Defaults to Physical if left blank or omitted.

2.2.7 FX Swap

The FXSwapData node is the trade data container for the FX Swap trade type. The structure – including example values – of the FXSwapData node is shown in Listing 8. It contains no sub-nodes.

Listing 8: FX Swap data

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 4.
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 Currency in Table 4.
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 Currency in Table 4.
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 4.
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.

2.2.8 FX Option

The FXOptionData node is the trade data container for the FX Option trade type. Vanilla FX options are supported, the exercise style must be European. The strike rate of an FX option is: SoldAmount / BoughtAmount. The FXOptionData node includes one and only one OptionData trade component sub-node plus elements specific to the FX Option. The structure of an example FXOptionData node for a FX Option is shown in Listing 9.

Listing 9: FX Option data

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 2.3.1. Note that the FX option type allows for European and American option style only.
BoughtCurrency: The bought currency of the FX option. Allowable values: See Currency in Table 4.
BoughtAmount: The amount in the BoughtCurrency. Allowable values: Any positive real number.
SoldCurrency: The sold currency of the FX option. Allowable values: See Currency in Table 4.
SoldAmount: The amount in the SoldCurrency. Allowable values: Any positive real number.

2.2.9 Equity Option

The EquityOptionData node is the trade data container for the equity option trade type. Vanilla equity options are supported, the exercise style must be European. 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 10.

Listing 10: Equity Option data

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 2.3.1 Option Data. Note that the equity option type allows for European option style only.
Name: The name of the underlying equity.
Allowable values: Any string (provided it is the ID of an equity in the market configuration). Typically an ISIN-code with the ISIN: prefix.
Currency: The currency of the equity option. Allowable values: See Currency in Table 4.
Strike: The option strike price.
Allowable values: Any positive real number.
Quantity: The number of units of the underlying covered by the transaction. Allowable values: Any positive real number.

2.2.10 Equity Forward

The EquityForwardData node is the trade data container for the equity forward trade type. Vanilla equity forwards are supported. The structure of an example EquityForwardData node for an equity option is shown in Listing 11.

Listing 11: Equity Forward data

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 4.
Name: The name of the underlying equity single name or equity index.
Allowable values: Any string (provided it is the ID of an equity in the market configuration). Typically an ISIN-code with the ISIN: prefix.
Currency: The currency of the equity forward. Allowable values: See Currency in Table 4.
Strike: The agreed buy/sell price of the equity forward.
Allowable values: Any positive real number.
Quantity: The number of units of the underlying equity to be bought/sold. Allowable values: Any positive real number.

2.2.11 Equity Swap

An Equity Swap is set up as a swap using the SwapData node, with one leg of type Equity and one more leg that can be either Fixed or Floating. Listing 12 shows an example. The Equity leg contains an additional EquityLegData block. See 2.3.10 for details on the Equity leg specification.

<SwapData><LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
…
</LegData>
<LegData>
<LegType>Equity</LegType>
<Payer>false</Payer>
…
<EquityLegData>
…
</EquityLegData>
</LegData>
</SwapData>

Listing 12: Equity Swap Data

2.2.12 CPI Swap

A CPI swap is set up as a swap, with one leg of type CPI. Listing 13 shows an example. The CPI leg contains an additional CPILegData block. See 2.3.11 for details on the CPI leg specification.

<SwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
…
</LegData>
<LegData>
<LegType>CPI</LegType>
<Payer>false</Payer>
…
<CPILegData>
…
</CPILegData>
</LegData>
</SwapData>

Listing 13: CPI Swap Data

2.2.13 Year on Year Inflation Swap

A Year on Year inflation swap is set up as a swap, with one leg of type YY. Listing 14 shows an example. The YY leg contains an additional YYLegData block. See 2.3.12 for details on the YY leg specification.

<SwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>true</Payer>
…
</LegData>
<LegData>
<LegType>YY</LegType>
<Payer>false</Payer>
…
<YYLegData>
…
</YYLegData>
</LegData>
</SwapData>

Listing 14: Year on Year Swap Data

2.2.14 Bond

A vanilla Bond is set up using a BondData block as shown in listing 15. The bond specific elements are

IssuerId: A unique identifier for the issuer of the bond
CreditCurveId: The identifier of the default curve used for pricing, which must match a default curve id in the market data configuration
SecurityId: A unique identifier for the security, this defines the security specific spread to be used for pricing.
ReferenceCurveId: The benchmark curve to be used for pricing, this must match a name of a yield curve in the market data configuration.
SettlementDays: The settlement delay applicable to the security.
Calendar: The calendar associated to the settlement lag.
IssueDate: The issue date of the security.

A LegData block then defines the cashflow structure of the bond, this can be of type fixed, floating etc.

<BondData>
<IssuerId>CPTY_C</IssuerId>
<CreditCurveId>CPTY_C</CreditCurveId>
<SecurityId>SECURITY_1</SecurityId>
<ReferenceCurveId>EUR-EURIBOR-6M</ReferenceCurveId>
<SettlementDays>2</SettlementDays>
<Calendar>TARGET</Calendar>
<IssueDate>20160203</IssueDate>
<LegData>
<LegType>Fixed</LegType>
<Payer>false</Payer>
…
</LegData>
</BondData>

Listing 15: Bond Data

The bond pricing requires a recovery rate that can be specified per SecurityId in the market data configuration.

2.2.15 Credit Default Swap

A credit default swap is set up using a CreditDefaultSwapData block as shown in listing 16. The CDS specific elements are

IssuerId: An identifier for the reference entity of the For informational pur- poses and not used for pricing.
CreditCurveId: Typically the ISIN-code of the reference entity defining the default curve used for Other identifiers may be used as well, provided they are supported in the market data configuration.
SettlesAccrual [Optional]: Whether or not the accrued coupon is due in the event of a This defaults to true if not provided.
PaysAtDefaultTime [Optional]: If set to true, any payments triggered by a default event are due at default If set to false, they are due at the end of the accrual period. This defaults to true if not provided.
ProtectionStart [Optional]: The first date where a default event will trigger the contrac This defaults to the first date in the schedule if it is not provided.
UpfrontDate [Optional]: Settlement date for the UpfrontFee if an UpfrontFee is provided. If an UpfrontFee is provided and it is non-zero, UpfrontDate is 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 notional amoun
FixedRecoveryRate [Optional]: This node holds the fixed recovery rate if the CDS is a fixed recovery For a standard CDS, this field should be omitted.

A LegData block then defines the cashflow structure of the credit default swap, this must be be of type fixed.

<CreditDefaultSwapData>
<IssuerId>CPTY_A</IssuerId>
<CreditCurveId>BANK</CreditCurveId>
<SettlesAccrual>Y</SettlesAccrual>
<PaysAtDefaultTime>Y</PaysAtDefaultTime>
<ProtectionStart>20160206</ProtectionStart>
<UpfrontDate>20160208</UpfrontDate>
<UpfrontFee>0.0</UpfrontFee>
<LegData>
<LegType>Fixed</LegType>
<Payer>false</Payer>
…
</LegData>
</CreditDefaultSwapData>

Listing 16: CreditDefaultSwap Data

2.2.16 Commodity Option

The CommodityOptionData node is the trade data container for the commodity option trade type. Vanilla commodity options are supported, the exercise style must be European. The CommodityOptionData node includes one and only one OptionData trade component sub-node plus elements specific to the commodity option. The structure of an example CommodityOptionData node for a commodity option is shown in Listing 17.

<CommodityOptionData>
<OptionData>
…
</OptionData>
<Name>COMDTY_WTI_USD</Name>
<Currency>USD</Currency>
<Strike>70</Strike>
<Quantity>500000</Quantity>
</CommodityOptionData>

Listing 17: Commodity Option data

The meanings and allowable values of the elements in the CommodityOptionData node follow below.

OptionData: This is a trade component sub-node outlined in section 2.3.1 Option Data. Note that the commodity option type allows for European option style only.
Name: The name of the underlying commodity.
Allowable values: Any string (provided it is the ID of a commodity in the market configuration).
Currency: The currency of the commodity option. Allowable values: See Currency in Table 4.
Strike: The option strike price.
Allowable values: Any positive real number.
Quantity: The number of units of the underlying commodity covered by the transaction. Allowable values: Any positive real number.

2.2.17 Commodity Forward

The CommodityForwardData node is the trade data container for the commodity forward trade type. The structure of an example CommodityForwardData node for an equity option is shown in Listing 18.

<CommodityForwardData>
<LongShort>Long</LongShort>
<Maturity>2018-06-30</Maturity>
<Name>COMDTY_GOLD_USD</Name>
<Currency>USD</Currency>
<Strike>1355</Strike>
<Quantity>1000</Quantity>
</CommodityForwardData>

Listing 18: Commodity Forward data

The meanings and allowable values of the elements in the CommodityForwardData node follow below.

LongShort: Defines whether the underlying commodity will be bought (long) or sold (short).
Allowable values: Long, Short.
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 4.
Name: The name of the underlying commodity.
Allowable values: Any string (provided it is the ID of an equity in the market configuration).
Currency: The currency of the commodity forward.
Allowable values: See Currency in Table 4.
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.

2.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 compo- nents which in turn include further trade components such as FixedLegData, ScheduleData and FloatingLegData is shown in Listing 19.

<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>

Listing 19: Trade Components Example

Descriptions of all trade components supported in ORE follow below.

2.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 20.

<OptionData>
<LongShort>Long</LongShort>
<OptionType>Call</OptionType>
<Style>Bermudan</Style>
<Settlement>Cash</Settlement>
<PayOffAtExpiry>true</PayOffAtExpiry>
<ExerciseDates>
<ExerciseDate>2016-04-20</ExerciseDate>
<ExerciseDate>2017-04-20</ExerciseDate>
</ExerciseDates>
</OptionData>

Listing 20: Option data

The meanings and allowable values of the elements in the OptionData node follow below.

LongShort: Specifies whether the option position is long or short. Allowable values: Long, LONG, long, L or Short, SHORT, short, S
OptionType: Specifies whether it is a call or a put option.
Allowable values: Call or Put
The meaning of Call and Put values depend on the asset class of the option, see Table 2:

Asset Class	Call / Put Specifications
Equity / Commodity Option	Call: The right to buy the underlying equity/commodity at the strike price. Put: The right to sell the underlying equity/commodity at the strike price.
IR Swaption	Call/Put values are ignored. Payer/Receiver swaption is determined in the Leg Data nodes of the underlying swap.
FX Option	Call: Bought and Sold currencies/amounts stay as determined in the Option Data node. Put: Bought and Sold currencies/amounts are switched compared to the Option Data node.

Table 2: Specification of Option Type Call / Put

Style: The exercise style of the option.
Allowable values: European or American or Bermudan. Note that trade type Swaption can have style European or Bermudan, but not American. The FX Option trade type can have style European or American, but not Bermudan.
Settlement: Delivery type. Allowable values: Cash or Physical
SettlementMethod [Optional]: Specifies the method to calculate the settlement amount for swaptions.
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 1 2
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 false if left blank or omitted.
Allowable values: true, false
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.
PremiumAmount [Optional]: Option premium amount paid by the option buyer to the option seller.
Allowable values: Any positive real number.
PremiumCurrency [Optional]: Currency of the option premium.
Allowable values: See Currency in Table 4.
PremiumPayDate [Optional]: Date of the option premium payment.
Allowable values: See Date in Table 4.

2.3.2 Leg Data and Notionals

The LegData trade component node is used within the CapFloorData, SwapData and SwaptionData 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 de- scribed below. An example structure of a LegData node of LegType Floating is shown in Listing 21.

<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>

Listing 21: Leg data

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, CMSSpread, DigitalCMSSpread, Equity, YY, CPI, ZeroCouponFixed
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 Currency in Table 4.
PaymentConvention: The payment convention of the leg coupons. Allowable values: See Roll Convention in Table 4.
PaymentLag [optional]: The payment lag given as as number business days, applies to fixed, Ibor and OIS legs.
Allowable values: A non-negative whole number, if not given it defaults to zero.
DayCounter: The day count convention of the leg coupons. Allowable values: See DayCount Convention in Table 6.
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 22.

Listing 22: Notional list

Another allowable specification of the notional schedule is shown in Listing 23.

Listing 23: Notional list with dates

The first notional must not have a start date, it will be associated with the sched- ule’s start, The subsequent notionals can 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.

In case of exchange of currencies 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 24.

Listing 24: Notional list with exchange

FX Resets, used for Rebalancing Cross-currency swaps, can be specified using an FXReset child element with the following subelements: See Listing 25 for an exam- ple.

ForeignCurrency: The foreign currency the notional of the leg resets Allowable values: See Currency in Table 4.
ForeignAmount: The notional amount in the foreign currency that the notional of the leg resets
Allowable values: Any positive real number.
FXIndex: A reference to an FX Index source for the FX reset Allowable values: A string on the form FX-SOURCE-CCY1-CCY2.
FixingDays: The FX fixing lag in business days Allowable values: Any integer.
FixingCalendar[Optional]: The calendar associated with the FX

Allowable values: See Table 5 Calendar. Defaults to the null calendar if left blank or omitted.

<Currency>USD</Currency>
<Notionals>
<Notional>65000000</Notional> <!– in USD –>
<FXReset>
<ForeignCurrency>EUR</ForeignCurrency>
<ForeignAmount>60000000</ForeignAmount>
<FXIndex>FX-SOURCE-USD-EUR</FXIndex>
<FixingDays>2</FixingDays>
<FixingCalendar>TARGET</FixingCalendar>
</FXReset>
</Notionals>

Listing 25: Notional list with exchange

After the Notional sub-node the LegData node includes a ScheduleData sub- node, and a sub-node based on the choice of LegType as per below:

ScheduleData: This is a trade component sub-node outlined in section 2.3.3 Schedule Data and Dates
FixedLegData: This trade component sub-node is required if LegType is set to fixed It is outlined in section 2.3.4.
FloatingLegData: This trade component sub-node is required if LegType is set to floating It is outlined in section 2.3.5 Floating Leg Data and Spreads.
CMSLegData: This trade component sub-node is required if LegType is set to CMS. It is outlined in section 2.3.7.
CMSSpreadLegData: This trade component sub-node is required if LegType is set to CMSSpread. It is outlined in section 2.3.8.
DigitalCMSSpreadLegData: This trade component sub-node is required if LegType is set to DigitalCMSSpread. It is outlined in section 2.3.9.
EquityLegData: This trade component sub-node is required if LegType is set to Equity. It is outlined in section 2.3.10.
CPILegData: This trade component sub-node is required if LegType is set to CPI. It is outlined in section 2.3.11.
YYLegData: This trade component sub-node is required if LegType is set to YY. It is outlined in section 2.3.12.
ZeroCouponFixedLegData: This trade component sub-node is required if LegType is set to ZeroCouponFixed. It is outlined in section 2.3.13.

2.3.3 Schedule Data (Rules and Dates)

The ScheduleData trade component node is used within the LegData trade component. The Schedule can both be rules based (at least one sub-node Rules exists) and dates based (at least one Dates sub-node exists, where the schedule is determined directly by Date child elements). 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 respectively dates are shown in Listing 26 and Listing 27, respectively.

<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>

Listing 26: Schedule data, rules based

Listing 27: Schedule data, date based

The ScheduleData section can contain any number and combination of <Dates> and <Rules> 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: Start- Date, EndDate, Tenor, Calendar, Convention, TermConvention, and Rule. If not existing, the Dates sub-node is required
StartDate: The schedule start date.
Allowable values: See Date in Table 4.
EndDate: The schedule end date.
Allowable values: See Date in Table 4.
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
Calendar: The calendar used to generate schedule dates.
Allowable values: See Table 5 Calendar.
Convention: Determines the adjustment of the schedule dates with regards to the selected calendar.
Allowable values: See Roll Convention in Table 4.
TermConvention: Determines the adjustment of the final schedule date with re- gards to the selected calendar.
Allowable values: See Roll Convention in Table 4
Rule [Optional]: Rule for the generation of the schedule using given start and end dates, tenor, calendar and business day conventions.
Allowable values and descriptions: See Table 3 Rule. Defaults to Forward if left blank or omitted.
EndOfMonth [Optional]: Specifies whether the date generation rule is different for end of month.
Allowable values: True, False. 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.
Allowable values: See Date in Table 4. Incompatible with date generation Rule
CDS and CDS2015.
LastDate [Optional]: Date for final stub period. Allowable values: See Date in Table 4.

The meanings and allowable values of the elements in a 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 payment dates, and also to com- pute day count fractions for irregular periods when day count convention is ActActISMA and the schedule is dates based.
Allowable values: See Table 5 Calendar. Defaults to NullCalendar if omitted, i.e. no holidays at all, not even on weekends.
Convention [Optional]: Convention used to compute day count fractions for irregular periods when day count convention is ActActISMA and the schedule is dates based.
Allowable values: See Roll Convention in Table 4. 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.
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.
Allowable values: Each Date child element can take the allowable values listed in Date in Table 4.

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.)
Twentieth	All dates but the effective date are taken to be the twentieth of their month (used for CDS sched- ules 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 log/short stub coupon period (old CDS convention).
CDS	Credit derivatives standard rule since ’Big Bang’ changes in 2009.
CDS2015	Credit derivatives standard rule updated in 2015. Same as CDS but with termination dates adjusted to 20th June and 20th December.

Table 3: Allowable Values for Rule

2.3.4 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 28.

Listing 28: Fixed leg data

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 29.

Listing 29: Fixed leg data with ’dated’ rates

2.3.5 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 as well as the Spreads sub-node which contains the spreads of the floating leg as child elements of type Spread.
An example of a FloatingLegData node is shown in Listing 30.

<FloatingLegData>
<Index>USD-LIBOR-3M</Index>
<IsInArrears>false</IsInArrears>
<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>
</FloatingLegData>
<NakedOption>N</NakedOption>

Listing 30: Floating leg data

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-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 7.
IsAveraged [Optional]: For cases where there are multiple index fixings over a pe- riod 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. IsAver- aged 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.
Allowable values: true, false. Defaults to false if left blank or omitted.
IncludeSpread [Optional]: Only applies to Sub Periods 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.
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.
Allowable values: Positive integers. Defaults to 0 if left blank or omitted.
Spreads: This node contains child elements of type Spread. If the spread is con- stant 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 section, the same applies as for notionals and rates – a list of changing spreads can be specified without or with individual starte dates as shown in Listing 31.

Listing 31: ’Dated’ spreads

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). 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]: Optional node (defaults to N), if Y the leg represents only the em- bedded floor, cap or collar. By convention these embedded options are considered long if the leg is a receiver leg, otherwise short.

2.3.6 Leg Data with Amortisation Structures

Amortisation structures can (optionally) be added to a leg as indicated in the following listing 32, within a block of information enclosed by <Amortizations> and </Amortizations> tags.

<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>

Listing 32: Amortisation data

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, RelativeToInitial- Notional, RelativeToPreviousNotional, Annuity.
Value: Interpreted depending on Type, see below.
StartDate: Amortisation starts on first schedule date on or beyond StartDate.
Frequency, entered as a period: Frequency of amortisations.
Underflow: Allow amortisation below zero notional if true, otherwise amortisation stops at zero notional.

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 current notional on each amortisation date.
Annuity: The value is interpreted as annuity amount (redemption plus coupon).

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.

2.3.7 CMS Leg Data

Listing 33 shows an example for a leg of type CMS.

<LegData>
<LegType>CMS</LegType>
<Payer>false</Payer>
<Currency>GBP</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>
</CMSLegData>
<NakedOption>N</NakedOption>
</LegData>

Listing 33: CMS leg data

The CMSLegData block contains the following elements:

Index: The underlying CMS index.
Spreads: The spreads applied to index fixings. As usual, this can be a single value, a vector of values or a dated vector of values.
IsInArrears: 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.
FixingDays: This is the fixing gap, i.e. the number of days before the period end date an index fixing is taken.
Gearings: This node contains child elements of type Gearing indicating that the coupon rate is multiplied by the given factors. The mode of specification is anal- ogous to spreads, see above.
Caps: 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: 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 node (defaults to N), if Y the leg represents only the em- bedded floor, cap or collar. By convention these embedded options are considered long if the leg is a receiver leg, otherwise short.

2.3.8 CMS Spread Leg Data

Listing 34 shows an example for a leg of type CMSSpread.

<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>
</CMSSpreadLegData>
<NakedOption>N</NakedOption>
</LegData>

Listing 34: CMS Spread leg data

The elements of the CMSSpreadLegData block are identical to those of the CMSLegData (see 2.3.7), except for the index which is defined by two CMS indices as the difference between Index1 and Index2.

2.3.9 Digital CMS Spread Leg Data

Listing 35 shows an example for a leg of type DigitalCMSSpread.

<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>N</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>

Listing 35: Digital CMS Spread leg data

The DigitalCMSLegData block contains the following elements:

DigitalCMSLegData: a DigitalCMSSpreadLegData block describing the underly- ing digital cms spread leg (see 2.3.9.)
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 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 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

2.3.10 Equity Leg Data

Listing 36 shows an example of a leg of type Equity. The EquityLegData block contains the following elements:

ReturnType: Price indicates that the coupons on the equity leg are determined by the price movement of the underlying equity, whereas Total indicates that coupons are determined by the total return of the underlying equity including dividends.
Allowable values: Price or Total
Name: The identifier of the underlying equity or equity index.
Allowable values: Any string (provided it is an ID of an equity in the market configuration). Typically an ISIN-code with the ISIN: prefix.
InitialPrice [Optional]: Initial Price of the equity, if not present, the first valuation date is used to determine the initial price.
Allowable values: Any positive real number
NotionalReset [Optional]: Defaults to false. If set to true, the Notional is reset at the beginning of each coupon period. Notional resets only affect the equity leg.
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.
Allowable values: A node on the same form as ScheduleData, (see 2.3.3). 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 valu- ation. N.B. Only used when no valuation schedule present. Defaults to 0.

<LegData>
<LegType>Equity</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>10000000</Notional>
</Notionals>
<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>
<ReturnType>Price</ReturnType>
<Name>ISIN:US78378X1072</Name>
<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>
</EquityLegData>
</LegData>

Listing 36: Equity Leg Data

2.3.11 CPI Leg Data

Listing 37 shows an example for a leg of type CPI. The CPILegData 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).
Rates: The fixed rate(s) of the leg. As usual, 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 ex- pressed in decimal form, e.g. 0.05 is a rate of 5%.
BaseCPI: The base CPI used to determine the lifting factor for the fixed coupons.
Allowable values: Any positive real number.
ObservationLag: The observation lag to be applied.
Allowable values: An integer followed by D, W, M or Y. Interpolation lags are typically expressed in M, months.
Interpolated: A flag indicating whether interpolation should be applied to inflation fixings.
Allowable values: true, false
SubtractInflationNotional [Optional]: A flag indicating whether the non-inflation adjusted notional amount should be subtracted from the the final inflation-adjusted notional exchange at maturity. Note that the final coupon payment is not affected by this flag.
Allowable values: true, false
Defaults to false if left blank or omitted.

<LegData>
<LegType>CPI</LegType>
<Payer>false</Payer>
<Currency>GBP</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>
<CPILegData>
<Index>UKRPI</Index>
<Rates>
<Rate>0.02</Rate>
</Rates>
<BaseCPI>210</BaseCPI>
<ObservationLag>2M</ObservationLag>
<Interpolated>false</Interpolated>
</CPILegData>
</LegData>

Listing 37: CPI Leg Data

2.3.12 YY Leg Data

Listing 38 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: The observation lag to be applied.
Allowable values: An integer followed by D, W, M or Y. Interpolation lags are typically expressed in M, months.
Caps: 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: 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.

<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>
<Caps>
<Cap>0.05</Cap>
</Caps>
<Floors>
<Floor>0.01</Floor>
</Floors>
<NakedOption>N</NakedOption>
</YYLegData>
</LegData>

Listing 38: YY Leg Data

2.3.13 ZeroCouponFixed Leg Data

Listing 39 shows an example for a leg of type Zero Coupon Fixed. The ZeroCoupon- FixedLegData block contains the following elements:

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, the current ZeroCouponFixed leg requires only a single rate value to be passed.
Allowable values: Each rate element can take any real number. The rate is ex- pressed in decimal form, e.g. 0.05 is a rate of 5%.
Compounding: The method of compounding applied to the rate.
Allowable values: ’Simple’ i.e. (1 + r * t), or ’Compounded’ i.e. (1 + r)ˆt

<LegData>
<LegType>ZeroCouponFixed</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>5Y</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>
</ZeroCouponFixedLegData>
</LegData>

Listing 39: ZeroCouponFixed leg data

2.4 Allowable Values for Standard Trade Data

Trade Data	Allowable Values
Date	The following date formats are supported: yyyymmdd yyyy-mm-dd yyyy/mm/dd yyyy.mm.dd dd-mm-yy dd/mm/yy dd.mm.yy dd-mm-yyyy dd/mm/yyyy dd.mm.yyyy 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.
Currency	ATS, AUD, BEF, BRL, CAD, CHF, CNY, CZK, DEM, DKK, EUR, ESP, FIM, FRF, GBP, GRD, HKD, HUF, IEP, ITL, INR, ISK, JPY, KRW, LUF, NLG, NOK, NZD, PLN, PTE, RON, SEK, SGD, THB, TRY, TWD, USD, ZAR, ARS, CLP, COP, IDR, ILS, KWD, PEN, MXN, SAR, RUB, TND, MYR, UAH, KZT, QAR, MXV, CLF, EGP, BHD, OMR, VND, AED, PHP, NGN, MAD, Note: Currency codes must also match available currencies in the simulation.xml file.
Roll Convention	F, Following, FOLLOWING MF, ModifiedFollowing, Modified Following, MODIFIED P, Preceding, PRECEDING MP, ModifiedPreceding, Modified Preceding, MODIFIED U, Unadjusted, INDIFF

Table 4: Allowable values for standard trade data.

Calendar
Allowable Values	Resulting Calendar
TARGET, TGT, EUR	Target Calendar
CA, TRB, CAD	Canada Calendar
TKB, JP, JPY	Japan Calendar
ZUB, CHF	Switzerland Calendar
GB, LNB, UK	UK Calendar
London stock exchange	London Stock Exchange Calendar
US, NYB, USD	US Calendar
US-SET	US Settlement Calendar
US-GOV	US Government Bond Calendar
US-NYSE, New York stock exchange	US NYSE Calendar
US with Libor impact	US Calendar for Libor fixings
US-NERC	US NERC Calendar
AU, AUD	Australia Calendar
SA, ZAR	South Africa Calendar
SS, SEK	Sweden Calendar
ARS	Brazil Calendar
BRL	Brazil Calendar
CNY	China Calendar
CZK	Czech Republic Calendar
DEN, DKK	Denmark Calendar
FIN	Finland Calendar
HKD	HongKong Calendar
ISK	Iceland Calendar
INR	India Calendar
IDR	Indonesia Calendar
MXN	Mexico Calendar
NZD	New Zealand Calendar
NOK	Norway Calendar
PLN	Poland Calendar
RUB	Russia Calendar
SAR	Saudi Arabia
SGD	Singapore Calendar
KRW	South Korea Calendar
TWD	Taiwan Calendar
TRY	Turkey Calendar
UAH	Ukraine Calendar
WeekendsOnly	Weekends Only Calendar

Table 5: Allowable Values for Calendar. Combinations of up to four calendars can be provided using comma separated calendar names.

DayCount Convention
Allowable Values	Resulting DayCount Convention
A360, Actual/360, ACT/360	Actual 360
A365, A365F, Actual/365, Actual/365 (fixed)	Actual 365 Fixed
T360, 30/360, 30/360 (Bond Basis), ACT/nACT	Thirty 360 (US)
30E/360, 30E/360 (Eurobond Basis)	Thirty 360 (European)
30/360 (Italian)	Thirty 360 (Italian)
ActActISDA, ActualActual (ISDA), ACT/ACT, ACT	Actual Actual (ISDA)
ActActISMA, ActualActual (ISMA)	Actual Actual (ISMA)
ActActAFB, Actual/Actual (AFB)	Actual Actual (AFB)

Table 6: Allowable Values for DayCount Convention

Index
On form CCY-INDEX-TENOR, and matching available indices in the simulation.xml file.
Index Component	Allowable Values
CCY-INDEX	EUR-EONIA EUR-EURIBOR EUR-LIBOR EUR-CMS USD-FedFunds USD-LIBOR USD-SIFMA USD-CMS GBP-SONIA GBP-LIBOR GBP-CMS JPY-LIBOR JPY-TIBOR JPY-TONAR JPY-CMS CHF-LIBOR CHF-SARON AUD-LIBOR AUD-BBSW CAD-CDOR CAD-BA SEK-STIBOR SEK-LIBOR DKK-LIBOR DKK-CIBOR SGD-SIBOR SGD-SOR HKD-HIBOR NOK-NIBOR HUF-BUBOR IDR-IDRFIX INR-MIFOR MXN-TIIE PLN-WIBOR SKK-BRIBOR NZD-BKBM
TENOR	An integer followed by D, W, M or Y

Table 7: Allowable values for Index.