Loading...
Home / XML  / Guide to the ORE XML Trade Data Format

Guide to the ORE XML Trade Data Format

Content

  1. Introduction
  2. Trade Data
    1. Envelope
    2. Trade Specific Data
      1. Swap
      2. Cap/Floor
      3. Swaption
      4. FX Forward
      5. FX Swap
      6. FX Option
      7. Equity Option
      8. Equity Forward
      9. CPI Swap
      10. Year on Year Inflation Swap
      11. Bond
      12. Credit Default Swap
      13. Forward Rate Agreement
    3. Trade Components
      1. Option Data
      2. Leg Data and Notionals
      3. Schedule Data and Dates
      4. Fixed Leg Data and Rates
      5. Floating Leg Data, Spreads, Gearings, Caps and Floors
      6. Leg Data with Amortisation Structures
      7. CMS Leg Data
      8. CMSSpread Leg Data
      9. CPI Leg Data
      10. YY Leg Data
    4. Allowable Values for Standard 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 11 trade types.
    Allowable values: ForwardRateAgreement, Swap, CapFloor, Swaption, FxForward, FxSwap, FxOption, EquityForward, EquityOption, 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.

<SwapData>
<LegData>

</LegData>
<LegData>

</LegData>
</SwapData>

Listing 2: Swap data

2.2.2 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 3. 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 3: 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 Rate 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 Rate 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 Rate 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 Rate element: Any real number. The rate is expressed in decimal form, eg 0.05 is a rate of 5%

2.2.3 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 4.

<SwaptionData>
<OptionData>
<Style>European</Style>

</OptionData>
<LegData>
<Currency>GBP</Currency>

</LegData>
<LegData>
<Currency>GBP</Currency>

</LegData>
</SwaptionData>

Listing 4: Swaption data

A Bermudan Swaption requires:
OptionData One OptionData sub-node
Style Bermudan
ExerciseDates At least two ExerciseDate child elements.
LegData Two LegData sub-nodes
LegType Fixed on one node and Floating on the other.
Currency The same currency for both nodes.

Table 1: Requirements for Bermudan Swaptions

2.2.4 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 5. It contains no sub-nodes.

<FxForwardData>
<ValueDate>2023-04-09</ValueDate>
<BoughtCurrency>EUR</BoughtCurrency>
<BoughtAmount>1000000</BoughtAmount>
<SoldCurrency>USD</SoldCurrency>
<SoldAmount>1500000</SoldAmount>
</FxForwardData>

Listing 5: 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 3.
  • BoughtCurrency: The currency to be bought on value date. Allowable values: See Currency in Table 3.
  • 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 3.
  • SoldAmount: The amount to be sold on value date. Allowable values: Any positive real number.

2.2.5 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 6. It contains no sub-nodes.

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

Listing 6:  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 3.
  • 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 3.
  • 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 3.
  • 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 3.
  • 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.6 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 7.

<FxOptionData>
<OptionData>

</OptionData>
<BoughtCurrency>EUR</BoughtCurrency>
<BoughtAmount>1000000</BoughtAmount>
<SoldCurrency>USD</SoldCurrency>
<SoldAmount>1350000</SoldAmount>
</FxOptionData>

Listing 7: 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 option style only.
  • BoughtCurrency: The bought currency of the FX option. Allowable values: See Currency in Table 3.
  • 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 3.
  • SoldAmount: The amount in the SoldCurrency. Allowable values: Any positive real number.

2.2.7 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 8.

<EquityOptionData>
<OptionData>

</OptionData>
<Name>SP5</Name>
<Currency>USD</Currency>
<Strike>2147.56</Strike>
<Quantity>17000</Quantity>
</EquityOptionData>

Listing 8: 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).
  • Currency: The currency of the equity option. Allowable values: See Currency in Table 3.
  • 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.8 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 9.

<EquityForwardData>
<LongShort>Long</LongShort>
<Maturity>2018-06-30</Maturity>
<Name>SP5</Name>
<Currency>USD</Currency>
<Strike>2147.56</Strike>
<Quantity>17000</Quantity>
</EquityForwardData>

Listing 9: 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.
  • 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).
  • Currency: The currency of the equity forward. Allowable values: See Currency in Table 3.
  • 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.10 CPI Swap

A CPI swap is set up as a swap, with one leg of type CPI. Listing 11 shows an example. The CPI leg contains an additional CPILegData block. See 2.3.9 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 11: CPI Swap Data

2.2.11 Year on Year Inflation Swap

A Year on Year inflation swap is set up as a swap, with one leg of type YY. Listing 12 shows an example. The YY leg contains an additional YYLegData block. See 2.3.10 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 12: Year on Year Swap Data

2.2.12 Bond

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

  • IssuerId: A unique identifier for the issuer of the bond
  • CreditCurveId: The entity defining the default curve used for pricing, via the default curves block in todaysmarket.xml
  • 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 curve in the yield curves block in todaysmarket.xml.
  • 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  13:  Bond Data

The bond pricing requires a recovery rate that can be specified in ORE per SecurityId.

2.2.13 Credit Default Swap

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

  • IssuerId: A unique identifier for the issuer of the bond
  • CreditCurveId: The entity defining the default curve used for pricing, via the default curves block in todaysmarket.xml
  • SettleAtAccrual: Whether or not the accrued coupon is due in the event of a default.
  • PaysAtDefaultTime: If set to true, any payments triggered by a default event are due at default time. If set to false, they are due at the end of the accrual period.
  • ProtectionStart: The first date where a default event will trigger the contract.
  • UpfrontDate: Settlement date for the upfront payment.
  • UpfrontFee: The upfront payment, expressed as a rate, to be multiplied by notional amount.

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 14: Credit Default Swap data

2.2.14 Forward Rate Agreement

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

  • StartDate: A FRA expires/settles on the startDate. Allowable values: See Date in Table 3.
  • 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.
  • Currency: The currency of the FRA notional. Allowable values: See Currency in Table 3.
  • Index: The name of the interest rate index the FRA is benchmarked against.
  • LongShort: Specifies whether the FRA position is long (one receives the agreed rate) or short (one pays the agreed rate).
  • Strike: The agreed forward interest rate.
  • Notional: No accretion or amortisation, just a constant notional.

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

<ForwardRateAgreementData>
<StartDate>20161028</StartDate>
<EndDate>20351028</EndDate>
<Currency>EUR</Currency>
<Index>EUR-EURIBOR-6M</Index>
<LongShort>Long</LongShort>
<Strike>0.00001</Strike>
<Notional>1000000000</Notional>
</ForwardRateAgreementData>

Listing 15: Forward Rate Agreement Data

2.2.15 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 8.

<CommodityOptionData>
<OptionData>

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

Listing 8: Equity 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 3.
  • 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.16 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 9.

<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 9: Equity 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.
  • 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.
  • 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 3.
  • 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 16.

<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 16: 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 17.

<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  17:  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
  • PayOffAtExpiry [Optional]: Relevant for options with early exercise, i.e. the ex- ercise 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 3.
  • PremiumPayDate [Optional]: Date of the option premium payment.
    Allowable values: See Date in Table 3.

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 depending on the value of the LegType element, one out of the following sub- nodes: FixedLegData, FloatingLegData. 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 18.

<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  18:  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, YY, CPI
  • 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 3.
  • PaymentConvention: The payment convention of the leg coupons. Allowable values: See Roll Convention in Table 3.
  • DayCounter: The day count convention of the leg coupons. Allowable values: See DayCount Convention in Table 5.
  • 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 19.

<Notionals>
<Notional>65000000</Notional>
<Notional>65000000</Notional>
<Notional>55000000</Notional>
<Notional>45000000</Notional>
</Notionals>

Listing  19:  Notional list

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

<Notionals>
<Notional>65000000</Notional>
<NotionalstartDate=’2016-01-02’>65000000</Notional>
<NotionalstartDate=’2017-01-02’>55000000</Notional>
<NotionalstartDate=’2021-01-02’>45000000</Notional>
</Notionals>

Listing 20: 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 21.

<Notionals>
<Notional>65000000</Notional>
<Exchanges>
<NotionalInitialExchange>true</NotionalInitialExchange>
<NotionalFinalExchange>true</NotionalFinalExchange>
<NotionalAmortizingExchange>true</NotionalAmortizingExchange>
</Exchanges>
</Notionals>

Listing 21: Notional list with exchange

FX Resets can be specified using an FXReset child element with subelements ForeignCurrency (currencyCode), ForeignAmount (double), FXIndex and FixingDays (integer) subelements, see Listing 22 for an example

<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>
</FXReset>
</Notionals>

Listing 22: Notional list with exchange

  • ScheduleData: This is a trade component sub-node outlined in section 2.3.3 Sched- ule 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
  • CPILegData: This trade component sub-node is required if LegType is set to CPI. It is outlined in section 2.3.9.
  • YYLegData: This trade component sub-node is required if LegType is set to YY. It is outlined in section 2.3.10.

2.3.3 Schedule Data and Dates

The ScheduleData trade component node is used within the LegData trade component. When IsRulesBased is set to false, the ScheduleData node includes a Dates sub-node where the schedule is determined directly by Date child elements. The schedule can also be generated from a set of rules based on the entries of the StartDate, EndDate, Tenor, Calendar, Convention, TermConvention, and Rule elements. Example structures of ScheduleData nodes based on rules respectively dates are shown in Listing 23 and Listing 24, 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 23: Schedule data, rules based

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

Listing 24: 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 the ScheduleData node follow below.

  • StartDate: The schedule start date.
    Allowable values: See Date in Table 3.
  • EndDate: The schedule end date.
    Allowable values: See Date in Table 3.
  • 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 4 Calendar.
  • Convention: Determines the adjustment of the schedule dates with regards to the selected calendar.
    Allowable values: See Roll Convention in Table 3.
  • TermConvention: Determines the adjustment of the final schedule date with re- gards to the selected calendar.
    Allowable values: See Roll Convention in Table 3.
  • Rules: Rules for the generation of the schedule using given start and end dates, tenor, calendar and business day conventions.
    Allowable values and descriptions: See Table 2 Rule.
  • Dates: This is a 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 3.

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.

Table 2: 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 25.

<FixedLegData>
<Rates>
<Rate>0.05</Rate>
</Rates>
</FixedLegData>

Listing 25:  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 26.
<FixedLegData>
<Rates>
<Rate>0.05</Rate>
<RatestartDate=’2016-02-04’>0.05</Rate>
<RatestartDate=’2019-02-05’>0.05</Rate>
</Rates>
</FixedLegData>

Listing 26: 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 compo- nent 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 27.

 

<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 27:  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, match- ing available Ibor indices in the simulation.xml file. CCY, INDEX and TERM must be separated by dashes (-). TERM must be an integer followed by D, W, M or Y. See Table 6.
  • 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.
    Allowable values: true, false
  • FixingDays: 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.
  • 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 28.
<Spreads>
<Spread>0.005</Spread>
<SpreadstartDate=’2017-03-05’>0.007</Spread>
<SpreadstartDate=’2019-03-05’>0.009</Spread>
</Spreads>

Listing 28: ’Dated’ spreads

  • 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.6 Leg Data with Amortisation Structures

Amortisation structures can (optionally) be added to a leg as indicated in the fol- lowing listing 29, 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 29: 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 30 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 30: 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 CMSSpread Leg Data

Listing 31 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 31: 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 CPI Leg Data

Listing 32 shows an example for a leg of type CPI. The CPILegData block contains the following elements:

  • Index: The underlying zero inflation index.
  • 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.
  • BaseCPI: The base CPI used to determine the lifting factor for the fixed coupons.
  • ObservationLag: The observation lag to be applied.
  • Interpolated: A flag indicating whether interpolation should be applied to inflation fixings.
<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 32: CPI Leg Data

2.3.10 YY Leg Data

Listing 33 shows an example for a leg of type YY. The YYLegData block contains the following elements:

  • Index: The underlying zero inflation index.
  • FixingDays: The number of fixing days.
  • ObservationLag: The observation lag to be applied.
  • Interpolated: A flag indicating whether interpolation should be applied to inflation fixings.
12

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 3: 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 4: 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 5: 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
USD-FedFunds
USD-LIBOR
GBP-SONIA
GBP-LIBOR
JPY-LIBOR
JPY-TIBOR
CHF-LIBOR
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 6: Allowable values for Index.