The figure 2 presents the structure of the return leg of the swap, which has 10 categories of components:
Figure 2: The structure of the return leg.
These 10 categories of components are described through the next few pages. They are the following:
- The identification of the payer and receiver party for this leg;
- The determination of the effective date and the termination date;
- The description of the underlying asset(s);
- The Rate of Return terms;
- The specification of the notional;
- The determination of the payoff amount;
- The description of the return terms;
- The notional adjustments conditions;
- The currency exchange terms that can be associated with the equity leg of the swap.
The identification of the payer and receiver party of the equity leg is done similarly to the other types of swaps, through the payerPartyReference and the receiverPartyReference data elements.
The effective date and the termination date are similarly defined for both the interest and equity leg of the trade. Each of these dates can be specified either in reference to a date defined somewhere else in the document (using the relativeDate subcomponent), or as a specific date (using the adjustableDate subcomponent).
The figure 3 presents the effective date as an example of how these two components are structured:
Figure 3: The effectiveDate.
The example 1 below presents how these schema structures are used for defining the effective date of the equity swap as a function of the trade date (the elapse time between these being the settlement cycle of the underlying security assets) and the termination date as a function of the last payment of the swap. This corresponds indeed to the most frequent practice for confirming equity swaps.
Example 1 - Effective date as a function of the trade date and effective date as a function of the last payment date:
- Effective date: 3 business days after the trade date (defined in another part of the document and referred to through the TradeDate reference);
- Termination date: on the last payment date (also defined somewhere else in the document and referred to through the FinalEquityPaymentDate reference).
<effectiveDate id="EffectiveDate">
<relativeDate>
<periodMultiplier>3</periodMultiplier>
<period>D</period>
<dayType>ExchangeBusiness</dayType>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="TradeDate"/>
</relativeDate>
</effectiveDate>
<terminationDate id="TerminationDate">
<relativeDate>
<periodMultiplier>0</periodMultiplier>
<period>D</period>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="FinalEquityPaymentDate"/>
</relativeDate>
</terminationDate>
The underlyer component provides a detailed description of the characteristic of the underlying asset(s). Seven types of asset classes have been included as part of this release, of which six are actually used by the equity swap. These six underlying types are the convertible bond, the equity, the exchange-traded fund, the future contract, the index and the mutual fund. The seventh one is the bond, that is used by the schema for credit derivatives and will be later used by the schema for trigger swaps once it will be released. Each of these asset types has been defined by extending a component named underlyingAsset that contains some key attributes that are common across most of the underlyers: the identifier, the descriptive name, the currency of denomination, the stock exchange on which the underlyer is listed and the clearance system. With the exception of the identifier element, all these attributes are optional.
Thereafter is the description of these six types of underlyers that are used by the schema for equity swaps. These diagrams also present the respective schemes that have been associated with these components. Not surprisingly, the exchangeId is used quite often.
The equity:
Figure 4: The equity underlyer extends the underlyingAsset component by adding two (optional) elements: the related exchange and the options exchange.
The index:
Figure 5: The index underlyer extends the underlyingAsset component by adding two (optional) elements: the related exchange and the identifier of the reference future contract that may have been referenced as part of the swap contract.
The mutual fund:
Figure 6: The mutual fund underlyer extends the underlyingAsset component by adding two (optional) elements: the indicator of whether the fund is open or closed and the name of the fund manager.
The exchange-traded fund:
Figure 7: The exchange-traded fund underlyer extends the underlyingAsset component by adding three (optional) elements: the related exchange, the options exchange and the name of the fund manager.
The future contract:
Figure 8: The future contract underlyer extends the underlyingAsset component by adding four (optional) elements: the related exchange, the options exchange, the contract multiplier and the specific reference of the future contract that is used as part of the swap.
The convertible bond:
Figure 9: The convertible bond underlyer extends the underlyingAsset component through six elements that characterize the instrument (the related exchange, the issuer name, the coupon rate, the maturity date, the par value and the face amount); in addition, the underlyingEquity component describes the equity underlyer in which the convertible bond can be turned into.
These various types of underlyers can be combined through two different structures, depending upon whether the swap has only one underlyer or has multiple underlying assets: the singleUnderlyer structure or the basket structure. The figure 10 below provides a high-level view of these two alternative structures, which are detailed in the following paragraphs.
Figure 10: Overview of the two alternative types of underlying structured: the singleUnderlyer and the basket.
In the case of a single underlyer, the singleUnderlyer component specifies the number of open units, the description of the underlyer (through the underlyingAsset substitution group) and the dividend payout ratio (which is defined through the underlyer component rather than the return component for reasons that are related to the basket, and that are explained below). It should be noted that the seven members of the underlyingAsset substitution group (bond, convertibleBond, equity, exchangeTradedFund, future, index, mutualFund) do not appear in this diagram: only the basis elements are represented.
Figure 11: The single underlyer.
The basket component is to be applied in the case where there are several underlyers, which are then specifically described through the basketConstituents component. This basket component is structured as follows: an identification of the number of basket units (typically, one) and a description of each of the basket constituents (through a one-to-many relationship).
Figure 12: The basket.
The structure that describes the basket is quite more complex than the one that specifies the single underlyer. Besides defining the number of basket units (typically, one), the structure specifies each of the basket constituents through an asset description, a constituent weight, a dividend payout ratio, a price and a notional description. The underlyingAsset component having been already described, the points below focus on the four latter components:
- The constituentWeight specifies the number of units of each of the basket constituents and, optionally, their respective weight in the basket. It is an optional component, considering that some more exotic types of equity swaps do not have a relative weight associated with each their underlyer components.
- The dividend payout ratio has been associated with the description of the underlyer rather than included in the definition of the return component in order to address the case where a different payout ratio is be associated with the respective components of a basket swap.
- The underlyerPrice component describes the price of each of the basket components; it is optional in order to take into consideration the cases where the market participants do not specify the breakdown by underlyer of the price that is defined at the leg level (which, in the case of a basket swap, corresponds to the notional of the equity leg of the swap). Its structure is based upon the Price complex type, which provides a great flexibility in the way the price of an asset can be defined. This price structure is described in more details through the later developments that are devoted to the valuation component.
- The underlyerNotional is also an optional component; it provides the possibility to break down by underlyer the notional for the equity leg, which can be particularly useful when several currencies are used across the various underlyers.
As an illustration of this structure of the basket component and an introduction to the upcoming developments that are devoted to the valuation, the example below presents the case of a basket swap which underlyers components are listed in various currencies.
Example 2 - Basket swap with underlyers listed in different currencies:
- The basket is comprised of one underlyer that is listed in EUR (TIM.MI) and one that is listed in GBP (VOD.L);
- The reference currency of the swap is USD (this information is carried through the equityAmount component, which is not indicated here);
- Each of the two basketConstituent structures carry the information about both its local price and its price after conversion in USD;
- The information about the currency conversion rates is specified through the valuation component (that is not depicted below), as this information is not specific to the underlyer;
- The initial price of the swap is USD 7,376,406. This corresponds to the multiplication of each of the underlyer prices by its respective quantity, after conversion in USD: 4.182*783,000 [TIM.MI ]+ 165*24,860 [VOD.L]. It also corresponds to the initial notional of the equity swap. This initial price is not depicted here, as it is part of the valuation component of the equity leg.
<underlyer>
<basket>
<openUnits>1</openUnits>
<basketConstituent>
<equity>
<instrumentId instrumentIdScheme="RIC">TIM.MI</instrumentId>
<description>Telecom Italia Mobile spa</description>
<currency>EUR</currency>
<exchangeId exchangeIdScheme="http://www.fpml.org/schemes/4.0/exchangeId">Milan Stock Exchange</exchangeId>
</equity>
<constituentWeight>
<openUnits>783000</openUnits>
</constituentWeight>
<dividendPayout>
<dividendPayoutRatio>85</dividendPayoutRatio>
</dividendPayout>
<underlyerPrice>
<grossPrice>
<currency>EUR</currency>
<amount>4.14</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</grossPrice>
<netPrice>
<currency>USD</currency>
<amount>4.182</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</netPrice>
</underlyerPrice>
<underlyerNotional>
<currency>USD</currency>
<amount>3274506</amount>
</underlyerNotional>
</basketConstituent>
<basketConstituent>
<equity>
<instrumentId instrumentIdScheme="RIC">VOD.L</instrumentId>
<description>Vodafone Group</description>
<currency>GBP</currency>
<exchangeId exchangeIdScheme="http://www.fpml.org/schemes/4.0/exchangeId">London Stock Exchange</exchangeId>
</equity>
<constituentWeight>
<openUnits>24860</openUnits>
</constituentWeight>
<dividendPayout>
<dividendPayoutRatio>85</dividendPayoutRatio>
</dividendPayout>
<underlyerPrice>
<grossPrice>
<currency>GBP</currency>
<amount>110.00</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</grossPrice>
<netPrice>
<currency>USD</currency>
<amount>165.00</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</netPrice>
</underlyerPrice>
<underlyerNotional>
<currency>USD</currency>
<amount>4101900</amount>
</underlyerNotional>
</basketConstituent>
</basket>
</underlyer>
Equity Options and Return Swaps both now use a common EquityValuation type.
Figure 13: The EquityValuation type, that specifies the valuation terms of the return leg of the swap.
The following developments present in more details the four main structures that are part of ReturnLegValuation type: the initialPrice, the valuationPriceInterim, the valuationPriceFinal and the paymentDates (old equityPaymentDates). Even if these components can appear quite complex at first glance, the objective here is to outline how they have been based upon a limited set of 'building blocks' that are systematically reused.
The purpose of the initialPrice component is to specify the initial price for the underlyer of the trade (equity, bond, index). In most of the cases, this price will be known. There can however be certain cases, such as a forward trade, where the actual price is not known on trade date and where the trade confirmation will rather specify the terms according to which this initial price will be determined at a later point.
The diagrams 14 and 15 below present the two sets of structures that are used for specifying these various cases: one (mandatory) structure that specifies the price and one (optional) structure that specifies the dates.
Figure 14: The initialPrice component of the valuation, with a specific focus on the part of the structure that specifies the price.
Three possible ways for defining the price of the underlyer are available: as an actual price and currency, in reference to an amount defined somewhere else in the document using the amountRelativeTo element, or by specifying a specific determination method using the determinationMethod component. Commissions can be associated with each of these three alternative definitions. For addressing the requirements related to composite FX swaps, the possibility is also provided, through the fxConversion component, to explicitly define the FX rate that has been used to convert the price from its listing currency to the reference currency of the swap.
Considering that in the vast majority of the cases the initial price is defined as an actual price and currency, the examples below will focus on detailing the various options available for specifying such actual price. The other possibilities offered through the Price type will be further detailed through the interim and final price components.
Example 3 - Specification of an initial price as an actual price that does not include commissions and FX terms:
- Price amount: 37.44;
- Price currency: USD;
- Price expression: in absolute terms (as opposed to as a percentage of the notional);
- There are no commissions nor FX terms associated with the price.
<initialPrice>
<netPrice>
<currency>USD</currency>
<amount>37.44</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</netPrice>
</initialPrice>
Example 4 - Specification of an initial price as an actual price that also includes commissions and FX terms:
- Basket swap, which price at the leg level corresponds to the multiplication of the respective prices and quantities of the various underlyer components, i.e. to the notional of the swap;
- Gross amount: 113,228,777 CAD;
- Net amount: 84,089,141 USD;
- Commission: 5 basis points
- Exchange rate: 1 USD = 1.34665 CAD
- Price expression: in absolute terms (as opposed to as a percentage of the notional);
- There are no commissions nor FX terms associated with the price.
<initialPrice>
<commission>
<commissionDenomination>BPS</commissionDenomination>
<commissionAmount>5</commissionAmount>
</commission>
<grossPrice>
<currency>CAD</currency>
<amount>113228777</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</grossPrice>
<netPrice>
<currency>USD</currency>
<amount>84089141</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</netPrice>
<fxConversion>
<fxRate>
<quotedCurrencyPair>
<currency1>CAD</currency1>
<currency2>USD</currency2>
<quoteBasis>Currency1PerCurrency2</quoteBasis>
</quotedCurrencyPair>
<rate>1.34665</rate>
</fxRate>
</fxConversion>
</initialPrice>
Example 5 - Specification of an initial price as a percentage of the notional, without commissions nor FX terms:
- Price: 94.80278% of the notional amount.
<initialPrice>
<netPrice>
<amount>94.80278</amount>
<priceExpression>PercentageOfNotional</priceExpression>
</netPrice>
</initialPrice>
Figure 15: The initialPrice component of the valuation, with a specific focus on the part of the structure that specifies the date and time of the initial valuation.
This structure that specifies the date and time of the valuation will typically not be used as part of the definition of the initial price. This is because in most cases the initialPrice component specifies the price of the underlyer that is used as the initial reference point for the swap, and there is no need to refer to any specific date or time. Considering that this 'building block is defined and used in a quite similar same way for the interim and final price, it will be detailed through these latter.
The purpose of the valuationPriceInterim component is to specify the interim price(s) for the equity underlyer of the trade. This is an optional component, as it does not apply in the case of a bullet swap, where there is no reset date. Its other specificity vis-a-vis the initial and final valuation components it that this components can hold an array of valuation dates, as opposed to only one valuation date.
Similarly to the initialPrice component, the diagrams 16 and 17 below present the two sets of structures that are part of the valuationPriceInterim component: one structure that specifies the price and one structure that specifies the valuation dates. Both structures are mandatory.
Figure 16: The valuationPriceInterim component of the valuation, with a specific focus on the part of the structure that specifies the price.
Figure 17: The valuationPriceInterim component of the valuation, with a specific focus on the part of the structure that specifies the dates.
The example 6 below is very illustrative of the typical use of the valuationPriceInterim structure for representing the interim valuation prices of an equity swap:
- As part of the Price structure, the determinationMethod node of the choice sequence will be used for specifying how the future prices of the underlyer will be determined;
- The definition of the time of the valuation essentially relies upon the valuationTimeType element, that specifies the time of day at which the Calculation Agent values the underlyer: the valuationTime component, which purpose is to specify an actual valuation time, is expected to be used only in some rare cases;
- Most often, a schedule of valuation dates will be specified, to which the payment schedule will refer.
Example 6 - Typical example of how the valuationPriceInterim component is used to specify the the interim valuation:
- A schedule of 11 interim valuation dates is defined, that extends from October 12, 2001 to August 12, 2002;
- This schedule of dates already takes into consideration the expected exchange holidays. Hence, no business day convention is applicable;
- On each of these valuation dates, the equity underlyer will be valued at the market close.
<valuationPriceInterim>
<determinationMethod>PriceAtValuationTime</determinationMethod>
<valuationTimeType>Close</valuationTimeType>
<valuationDates id="InterimValuationDate">
<adjustableDates>
<unadjustedDate>2001-10-12</unadjustedDate>
<unadjustedDate>2001-11-13</unadjustedDate>
<unadjustedDate>2001-12-12</unadjustedDate>
<unadjustedDate>2002-01-14</unadjustedDate>
<unadjustedDate>2002-02-12</unadjustedDate>
<unadjustedDate>2002-03-12</unadjustedDate>
<unadjustedDate>2002-04-12</unadjustedDate>
<unadjustedDate>2002-05-13</unadjustedDate>
<unadjustedDate>2002-06-12</unadjustedDate>
<unadjustedDate>2002-07-12</unadjustedDate>
<unadjustedDate>2002-08-12</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDates>
</valuationDates>
</valuationPriceInterim>
The schema also provides the ability to address some more unusual situations. One of these relates to the case where the valuation dates are defined as a function of the equity payment dates. In such case, a specific consideration needs to be given to the various types of holidays, i.e. banking holidays versus exchange holidays. The relativeDateSequence component does provide such ability to define a date as a function of another date by applying a defined sequence of offsets, as opposed to only one offset as in the case of the relativeDate component. This case is illustrated in the example 7 below.
Example 7 - The interim valuation dates are defined in relation to the payment dates:
- The settlement cycle of the underlying equity is 3 business days;
- The valuation date is defined as a function of the payment date. Considering that the payment date happens after the valuation date, a negative value is then specified as the periodMultiplier element;
- In order to give consideration to the situations where the stock exchange is opened on certain banking holidays (e.g. Veteran Day in the United States) and vice-versa, a sequence of offsets is being applied. Considering a settlement cycle of 3 days, a first sequence of 2 currency business days is first applied, and then a sequence of 1 exchange business day. This avoids a situation where an offset of 3 currency business days could lead to specifying a valuation date that corresponds to an exchange business day.
- Considering that the first offset sequence of 2 business days applies to currency business days, the ISDA business day convention is applicable; it is not applicable for the second offset sequence, which refers to exchange business days.
<valuationDates id="InterimValuationDates">
<relativeDateSequence>
<dateRelativeTo href="InterimEquityPaymentDate"/>
<!--The first offset is 2 exchange business days prior to the payment date.-->
<dateOffset>
<periodMultiplier>-2</periodMultiplier>
<period>D</period>
<dayType>CurrencyBusiness</dayType>
<businessDayConvention>FOLLOWING</businessDayConvention>
<sequence>1</sequence>
</dateOffset>
<!--The second offset is 1 banking business day prior to the payment date.-->
<dateOffset>
<periodMultiplier>-1</periodMultiplier>
<period>D</period>
<dayType>ExchangeBusiness</dayType>
<businessDayConvention>NotApplicable</businessDayConvention>
<sequence>2</sequence>
</dateOffset>
<businessCenters id="PrimaryBusinessCenter">
<businessCenter>USNY</businessCenter>
</businessCenters>
</relativeDateSequence>
</valuationDates>
The example 8 below provides another example of an unusual definition of the interim valuation date. Here, the valuation dates are defined through a rule-based schedule, which corresponds to the market practice typically in use for fixed income swaps. This practice is however used only rarely in the case of equity derivatives.
Example 8 - The interim valuation dates are defined through a rule-based schedule:
- The underlyer is valued at the market close on each of the interim valuation dates;
- The final valuation is based on the price obtained by the payer of the equity return when unwinding his hedge position;
- The first valuation date is April 10, 2002;
- Each of the following valuations is scheduled on the 10th of each month, until the last valuation date which is scheduled on March 12, 2003;
- The business day convention is not applicable, because the terms 'Modified Following', 'Following', 'Preceding', etc. are not recognized ISDA terms in the context of exchange business days. On the other hand, the ISDA Definition for Equity Derivatives is, by default, to roll forward if a scheduled valuation date is not a exchange business day.
<valuationPriceInterim>
<determinationMethod>Valuation time</determinationMethod>
<valuationTimeType>Close</valuationTimeType>
<valuationDates id="InterimValuationDates">
<periodicDates>
<calculationStartDate>
<adjustableDate>
<unadjustedDate>2002-04-10</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDate>
</calculationStartDate>
<calculationPeriodFrequency>
<periodMultiplier>1</periodMultiplier>
<period>M</period>
<rollConvention>10</rollConvention>
</calculationPeriodFrequency>
<calculationPeriodDatesAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</calculationPeriodDatesAdjustments>
</periodicDates>
</valuationDates>
</valuationPriceInterim>
<valuationPriceFinal>
<determinationMethod>HedgeUnwind</determinationMethod>
<valuationDate id="FinalValuationDate">
<adjustableDate>
<unadjustedDate>2003-03-12</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDate>
</valuationDate>
</valuationPriceFinal>
The purpose of the valuationPriceFinal component is to specify the final price for the equity underlyer of the trade.
In a similar way than what has been previously detailed for the components that specify the initial and the intermediate valuations, the diagrams 18 and 19 below respectively detail the structure that specifies the final price and the structure that specifies the date on which this valuation will take place. Both structures are mandatory.
Figure 18: The valuationPriceFinal component of the valuation, with a specific focus on the part of the structure that specifies the price.
Figure 19: The valuationPriceFinal component of the valuation, with a specific focus on the part of the structure that specifies the final valuation date.
It can be noted at this point that the only difference between this valuationPriceFinal component and the valuationPriceInterim component is that only one final valuation date can be specified, while the possibility is provided to define several interim valuation dates. The equityValuationDates component used for specifying the interim valuation dates has then been substituted with the equityValuationDate component, which allows only one date.
The example 8 below presents the most common use of this structure, a specific final valuation date being defined while the final price is specified through the use of the determinationMethod element. Of course, if the interim valuation dates would be defined in reference to the payment dates (as illustrated in the example 7) or through a rule-based schedule (example 8), such method would also be applied for defining the final valuation date.
Example 9 - The most common definition of the final valuation:
- The final price of the equity underlyer will correspond to the price at which the payer of the equity leg will unwind his hedge position;
- A commission of 60 basis points will be applied to this price;
- The final valuation date is February 3, 2004;
- In accordance to the market practice, this date has been determined by the Calculation Agent as corresponding to an exchange business day. As previously indicated, the terms 'Modified Following', 'Following', 'Preceding', etc. are not recognized ISDA terms in the context of exchange business days.
<valuationPriceFinal>
<commission>
<commissionDenomination>BPS</commissionDenomination>
<commissionAmount>60</commissionAmount>
</commission>
<determinationMethod>HedgeUnwind</determinationMethod>
<valuationDate id="FinalValuationDate">
<adjustableDate>
<unadjustedDate>2004-02-03</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDate>
</valuationDate>
</valuationPriceFinal>
The last structure that participates in the definition of the equity swap valuation is the schedule of equity payment dates. These dates are specified through the equityPaymentDates component. The structure of this component is threefold:
- An Identifier is associated to the equityPaymentDates root component, in order to allow to specify a generic reference to these payment dates. This unique reference to the payment dates is used through the dividend component, when it is specified that the dividend will be paid on the next equity payment date (see below the section related to the return component of the equity leg);
- The equityPaymentDatesInterim component specifies the interim payment dates of the swap. It is optional to address the case of bullet swaps that do not have interim equity resets;
- The equityPaymentDateFinal component specifies the final payment date.
Figure 20: The paymentDate (old equityPaymentDate) component, that specifies the schedule of payment dates.
The structure of the paymentDatesInterim (old equityPaymentDatesInterim) and the paymentDateFinal (equityPaymentDateFinal) is very similar. The only difference is that several dates can be specified in the first case, and only one date in the latter.
As a result, both the interim and the final payment dates can be defined either as a schedule of dates or in reference to a date defined somewhere else in the document. This latter approach is used most often, with the payment dates being specified as one settlement cycle after the valuation date to which they relate. This is illustrated through this final example relating to the valuation component, which provides a complete view of how the valuation dates are defined as an actual schedule of dates to which the payment dates refer.
Example 10 - Equity swap which payment dates are defined in relation to the schedule of valuation dates:
- The initial price of the swap is USD 37.44;
- A schedule of 12 valuation dates is defined: 11 interim valuation dates (from October 12, 2001 to August 12, 2001) and 1 final valuation date (September 24, 2002);
- The equity underlyer is to be valued at the market close on each of the interim valuation dates. Its final valuation will correspond to the price at which the payer of the equity return unwinds his hedge;
- The payment dates are scheduled 3 currency business days after each of the valuation dates. Considering that these are currency business days, as opposed to exchange business days, the 'Following' business day convention is specified, New York being the reference business center.
<rateOfReturn>
<initialPrice>
<netPrice>
<currency>USD</currency>
<amount>37.44</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</netPrice>
</initialPrice>
<notionalReset>true</equityNotionalReset>
<valuationPriceInterim>
<determinationMethod>PriceAtValuationTime</determinationMethod>
<valuationTimeType>Close</valuationTimeType>
<valuationDates id="InterimValuationDate">
<adjustableDates>
<unadjustedDate>2001-10-12</unadjustedDate>
<unadjustedDate>2001-11-13</unadjustedDate>
<unadjustedDate>2001-12-12</unadjustedDate>
<unadjustedDate>2002-01-14</unadjustedDate>
<unadjustedDate>2002-02-12</unadjustedDate>
<unadjustedDate>2002-03-12</unadjustedDate>
<unadjustedDate>2002-04-12</unadjustedDate>
<unadjustedDate>2002-05-13</unadjustedDate>
<unadjustedDate>2002-06-12</unadjustedDate>
<unadjustedDate>2002-07-12</unadjustedDate>
<unadjustedDate>2002-08-12</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDates>
</valuationDates>
</valuationPriceInterim>
<valuationPriceFinal>
<determinationMethod>HedgeUnwind</determinationMethod>
<valuationDate id="FinalValuationDate">
<adjustableDate>
<unadjustedDate>2002-09-24</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDate>
</valuationDate>
</valuationPriceFinal>
<paymentDates id="EquityPaymentDate">
<paymentDatesInterim id="InterimEquityPaymentDate">
<relativeDates>
<periodMultiplier>3</periodMultiplier>
<period>D</period>
<dayType>CurrencyBusiness</dayType>
<businessDayConvention>FOLLOWING</businessDayConvention>
<businessCenters id="PrimaryBusinessCenter">
<businessCenter>USNY</businessCenter>
</businessCenters>
<dateRelativeTo href="InterimValuationDate"/>
</relativeDates>
</paymentDatesInterim>
<paymentDateFinal id="FinalEquityPaymentDate">
<relativeDate>
<periodMultiplier>3</periodMultiplier>
<period>D</period>
<dayType>CurrencyBusiness</dayType>
<businessDayConvention>FOLLOWING</businessDayConvention>
<businessCentersReference href="PrimaryBusinessCenter"/>
<dateRelativeTo href="FinalValuationDate"/>
</relativeDate>
</paymentDateFinal>
</paymentDates>
</rateOfReturn>
The notional component specifies the notional of each of the legs of the swap (it is indeed also present in the interest leg of the trade). Similarly to the price of the underlyer, three possible ways of defining this notional are available:
- By specifying an actual amount and currency. This is used most often for the equity leg of the swap;
- By referencing an amount specified somewhere else in the document. This is typically the case of the interest leg of the swap, which notional refers to notional specified through equity leg;
- By specifying a determination method, using the determinationMethod component This is typically useful for forward swaps, which notional is not known on trade date.
Figure 21: The notional component.
The three examples below illustrate each of these cases mentioned before:
Example 11 - The explicit notional amount:
- This approach is typically used for specifying the notional of the equity leg of the swap;
- The identifier attribute associated with the notional element is used so that the notional of the interest leg can refer to it (example 12 below).
<notional id="EquityNotionalAmount">
<notionalAmount>
<currency>USD</currency>
<amount>28469376</amount>
</notionalAmount>
</notional>
Example 12 - The reference to a notional defined somewhere else in the document:
- This approach is typically used for specifying the notional of the interest leg of the swap;
- The relationship with the notional amount specified in the equity leg is established via the href, which refers to the value specified through the identifier associated with the explicit notional amount.
<notional>
<amountRelativeTo href="EquityNotionalAmount"/>
</notional>
Example 13 - The use of the determinationMethod for specifying the notional amount:
- The initial price of the equity underlyer is not known on trade inception: it will be determined at a later point;
- As a consequence, only the method through which the notional is calculated is specified as part of the swap.
<notional id="EquityNotionalAmount">
<determinationMethod>Number of Shares * Initial Price</determinationMethod>
</notional>
The main purpose of the amount (old equityAmount) component is to specify the method that determines the amount to be paid/received on each of the payment dates. Its role however goes quite beyond this, as it also specifies:
- Whether the swap will cash settle of physically settle;
- The settlement currency of the return leg of the swap.
Figure 22: The amount (old equityAmount) component.
This amount component is based on the LegAmount type that is also used for defining the interestAmount. It extends this type by adding a boolean cashSettlement element that specifies whether the swap will cash or physically settle.
The paymentCurrency is the first component of this structure. It specifies the payment currency of the equity leg of the swap through three possible methods:
- As an actual ISO currency code;
- As a determination method description, applicable in the case of some exotic swap where the payment currency of the trade will be a function of certain parameters;
- Through the reference to a currency defined somewhere else in the document, as in the case of a quanto swap or a composite FX swap which reference currency is specified through the fxTerms component.
The core of the component is its second component, which specifies the payoff of the return leg. This can done in three possible ways:
- The referenceAmount element is aimed at holding the reference to the standard ISDA definition of the equity amount. (It can however be used beyond this sole purpose, as it is defined as a string element, without any specific enumerations;
- The formula component is aimed at the exotic equity swaps, which equity payoff needs to be described through a mathematical formula. To meet this purpose, the formula component provides a flexible structure for describing the return payoff, using the combination of the formulaDescription component that provides a literary description of the payoff, the math container that uses the xsd:any XML structure to hold any type of formula description, and the formulaComponent element that describes the various components of the formula.
- As an alternative to the XML representation of each of the details of the return payoff, the encodedDescription element provides the ability to encode an image that describes the payout formula, using a base64Binary structure.
The optional calculationDates component is also aimed at these more complex equity swaps. It provides the possibility to define calculation dates (such as observation points in the case of an equity payoff that is a function of some specific market levels). These calculation dates can be specified similarly to the valuation dates:
- As an actual schedule of dates, using the adjustableDates component;
- In relation to some dates defined elsewhere in the document, using the relativeDateSequence component;
- Through a rule-based schedule, using the periodicDates component.
Figure 23: The calculationDates component, that provides the opportunity to define calculation dates for more exotic types of equity swaps.
Example 14 - The use of the amount component for a vanilla equity swap:
- The payment currency of the return leg is USD;
- The payoff amount of the return leg is specified as the ISDA standard definition, i.e. equal to the product of the underlyer notional amount and the rate of return;
- The settlements will be made in cash.
<amount>
<paymentCurrency id="EquityPaymentCurrency">
<currency>USD</currency>
</paymentCurrency>
<referenceAmount>ISDA Standard</referenceAmount>
<cashSettlement>true</cashSettlement>
</amount>
The return component encapsulates the information that defines the dividend to be paid to the receiver of the equity amounts, with the exception of the dividend payout ratio, that is specified through the underlyer component. (As explained earlier, this is because a specific payout ratio can be associated with each underlyer component in the case of basket swaps; such situation can typically be related to different tax regimes across countries when those various underlyers originate from different market places.)
Figure 24: The return component.
This return component has two sets of element: the returnType element, that specifies (through an enumeration) whether the contract is a total return swap, a price return swap or a dividend return swap, and the dividendConditions component, which describes the various conditions applicable to the dividend, including whether and how interests will be accrued if they are paid after the dividend pay date. This second component is optional, as it does not apply in the case of a price return swap. Its dividend terms are the following:
- The dividendReinvestment, as a Boolean data element that determines whether the dividend will be reinvested into the equity notional;
- The dividendEntitlement, to indicate when the counterparty is entitled to the dividend;
- The dividendPaymentDate, to specify when the dividend will be paid. This date can be specified either through a set of pre-defined values that are associated with the dividendDateReference element that is part of this component, or as a specific date. These pre-defined values can refer either to dividend dates (ExDate, DividendPaymentDate, RecordDate) or to dates that relate to the swap contract (TerminationDate, EquityPaymentDate, FollowingPaymentDate);
- The dividendPeriodEffectiveDate and the dividendPeriodEndDate, to indicate when the swap is considered as active from the perspective of dividend processing and when such period ends;
- The dividendFxTriggerDate, to specify the date on which the FX rate will be considered in the case of a Composite FX swap;
- The interestAccruals, to define how interests will be accrued on the dividend when this latter is paid some period of time after the dividend payment date.
The notionalAdjustments component specifies whether the adjustment to the equity notional of the swap will obey to certain specific terms. These terms can be, according to the current industry practice, threefold: standard, execution and portfolio rebalancing. An execution-style swap is a trade where the quantity of underlyers is expected to vary quite often; in order to facilitate these later 'executions', the parties agree in advance on contractual terms that will facilitate these expected adjustments to the contract. A portfolio-rebalancing swap is a trade where the basket components will be often adjusted not only in terms of quantities but also in terms of types of underlyers; similarly to the previous case, some specific language will typically accommodate such adjustments.
These legal terms are however not specified through the schema representation of the equity swap. There are two reasons for this. The first one is that they are not part of the ISDA Definitions for Equity Derivatives. The second reason is that this current version of the equity swap schema is focused on representing the economic description of the trade. These legal terms are then not part of it.
Equity Derivatives and Equity Swaps both now use a common FxFeature component
The fxFeature is an optional component that specifies the FX conversion terms that can be associated with the swap. This FX feature can either be Quanto or Composite FX. Both these components include a referenceCurrency element, which purpose is to explicitly state the reference currency of the swap.
Figure 25: The quanto component.
The quanto component includes an explicit reference to a rate, through the quantoRate element. One or several rates can be defined, in order to address the case where a basket swap is composed of several underlyers that are listed in different currencies.
The example below illustrates the application of this quanto component:
Example 15 - The quanto component:
- The business background for this trade is that the payment currency of the swap is USD, while some of the underlyers are listed in EUR and some others are listed in HKD. The payer of the equity return commits upfront to a set of exchange rates vis-a-vis the USD which are specified as part of the quanto component;
- The EUR is quoted per units of USD and the exchange rate is 0.99140;
- The HKD is also quoted per units of USD and the exchange rate is 7.80.
<fxFeature>
<quanto>
<referenceCurrency id="ReferenceCurrency">USD</referenceCurrency>
<fxRate>
<quotedCurrencyPair>
<currency1>USD</currency1>
<currency2>EUR</currency2>
<quoteBasis>Currency2PerCurrency1</quoteBasis>
</quotedCurrencyPair>
<rate>0.99140</rate>
</fxRate>
<fxRate>
<quotedCurrencyPair>
<currency1>USD</currency1>
<currency2>HKD</currency2>
<quoteBasis>Currency2PerCurrency1</quoteBasis>
</quotedCurrencyPair>
<rate>7.80</rate>
</fxRate>
</quanto>
</fxFeature>
Figure 26: The compositeFx component.
The compositeFx component provides the framework for defining a currency rate at some point in the future. This can be done either by defining a generic method using the determinationMethod component (for example, when it is agreed that the exchange rate will be determined "in good faith by the Calculation Agent") or by specifying the information source and fixing time and date reference that will be used for defining this exchange rate, using the fxDetermination component.
The example below illustrates the application of this compositeFx component:
Example 16 - The compositeFx component:
- The payment currency of the swap is EUR;
- The exchange rate will be determined in good faith by the Calculation Agent.
<fxFeature>
<compositeFx>
<referenceCurrency id="ReferenceCurrency">USD</referenceCurrency>
<determinationMethod>GoodFaith</determinationMethod>
</compositeFx>
</fxFeature>
The interest leg of the equity swap leverages for the most part the schema developed for the interest rate swaps.
However, instead of simply reusing the entire swapStream, the interest rate leg of the equity swap schema reuses certain of the components that are part of this swapStream.
This design approach is motivated by the differences in market practices that exist between the equity and fixed income products. The industry practice for the equity swaps consists in defining a schedule of actual dates for the equity valuation, while most of the other swap dates are defined in reference to this schedule. The practice in place in the interest rate area consists, on the other hand, in defining a rule-based schedule. As a result, the swapStream features are largely focused on defining such periodicity rules along with the appropriate calendar exceptions, and do not provide the possibility for defining a complete schedule of actual dates (if we except through the firstPeriodStartDate, the firstRegularPeriodStartDate and the lastRegularPeriodEndDate) and references to these.
Instead of leveraging the whole swapStream component, the interest leg of the equity swap leverages then components at a more granular level, such as the resetFrequency component, the interestCalculation component and the calculationPeriodDatesReference element.
As a result, the interest leg of the equity swap has six categories of components, which are presented in the figure 27 below and respectively specify the following features of the interest leg:
- The payer and the receiver party;
- The calculation dates;
- The notional amount;
- The interest amount;
- The interest calculation;
- The initial and final stubs.
Figure 27: The interest leg of the equity swap.
The identification of the payer and receiver party of the equity leg is done similarly than for the equity leg of the swap, through the payerPartyReference and receiverPartyReference data elements.
The interestLegCalculationPeriodDates component defines the various dates associated with the interest leg of the swap:
- The effective date, through the effectiveDate component, also used for the equity leg of the swap;
- The termination date, through the terminationDate component that is also similar to the equity leg;
- The reset dates, via the interestRateResetDates component;
- The payment dates, through the interestRatePaymentDates component.
The diagram below presents the key features of these different date structures. Three of these components are structured in the same way: the effectiveDate, the terminationDate and the interestRatePaymentDates. These components indeed all provide the possibility to define a date (or several dates, in the case of the interestRatePaymentDates component) as either an actual date or in reference to a date specified somewhere else in the document.
The interestRateResetDates component has been developed as a simplified version of the ResetDates type that is part of the interest rates derivatives schema. Three of the seven components that are part of this ResetDates type have indeed been reused:
- The calculationPeriodDatesReference is an empty element that holds an href into the identifier attribute that is associated with the interestLegCalculationPeriodDates;
- The resetRelativeTo specifies whether the reset dates are determined with respect to each adjusted calculation period start date or adjusted calculation period end date;
- The resetFrequency component provides the possibility to define a specific reset frequency, instead of defining the reset in relation to the various interest calculation dates: the effective date, the respective interest payment dates and the termination date.
Figure 28: The interestLegCalculationPeriodDates component.
The example below presents a typical example of how this schema is applied to the standard interest leg of an equity swap:
Example 17 - The calculation period dates of the interest leg of an equity swap:
- The effective date is defined similarly than for the equity leg, as one settlement cycle following the trade date;
- The termination date is also defined in the same way than the equity leg, as corresponding to the last equity payment date;
- The reset dates for the floating rate are defined as corresponding to the first day of each of the calculation periods by referencing the identifier that is associated with the interestLegCalculationPeriodDates node;
- The interest payment dates are specified in reference to the equity payment dates: this is called a combined reset, as a net amount corresponding to the difference between the interest and the equity amount will be exchanged on each payment date.
<interestLegCalculationPeriodDates id="InterestLegPeriodDates">
<effectiveDate>
<relativeDate>
<periodMultiplier>3</periodMultiplier>
<period>D</period>
<dayType>ExchangeBusiness</dayType>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="TradeDate"/>
</relativeDate>
</effectiveDate>
<terminationDate>
<relativeDate>
<periodMultiplier>0</periodMultiplier>
<period>D</period>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="FinalEquityPaymentDate"/>
</relativeDate>
</terminationDate>
<interestLegResetDates>
<calculationPeriodDatesReference href="InterestLegPeriodDates"/>
<resetRelativeTo>CalculationPeriodStartDate</resetRelativeTo>
</interestLegResetDates>
<interestLegPaymentDates>
<relativeDates>
<periodMultiplier>0</periodMultiplier>
<period>D</period>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="EquityPaymentDate"/>
</relativeDates>
</interestLegPaymentDates>
</interestLegCalculationPeriodDates>
The notional amount is defined through the same structure than for the equity leg of the swap: the notional component. As mentioned earlier, and illustrated through the example 12, this component is most often used for referencing the notional amount that is defined as part of the equity leg.
The interest amount is defined in the same way than the equity amount: using the LegAmount complex type. Used through the interest leg, it specifies the following elements:
- The settlement currency of the interest leg of the swap;
- The interest amount of the swap, either by referencing the standard ISDA Definition or by describing a very specific formula.
Example 18 - The interest amount of an equity swap:
- This example illustrates a swap that has FX terms which are referenced through the fxTerms component that is part of the equity leg. An identifier is associated with the reference currency that is defined as part of that component, and the href that is part of the paymentCurrency element refers to this identifier;
- The interest amount is specified by reference to the ISDA Equity Derivatives Definitions.
<interestAmount>
<paymentCurrency href="ReferenceCurrency"/>
<referenceAmount>Standard ISDA</referenceAmount>
</interestAmount>
The interestCalculation component specifies the interest rate reference of the swap (by referring either to a fixed interest rate or to a floating reference rate) and the day count fraction to be applied. As indicated in the introduction to the interest leg section, this structure has been developed by leveraging the components defined for the interest rate swap schema.
The component supports also compounding for on the interest leg (see optional compounding element within InterestCalculation. The compounding rate on the Interest leg can be different than that used for funding calculation. In addition, the structure supports the representation of multiple types of spreads, i.e. one for a long amount and one for a short amount.
Figure 29: The interestCalculation component.
The example below presents a typical example of how this interestCalculation component can be applied for specifying the floating rate of an equity swap:
Example 19 - Specifying the floating rate of an equity swap:
- The reference rate is 3 month USD-LIBOR-BBA;
- The spread is plus 50 basis points;
- The day count fraction is actual number of days / 360 days.
<interestCalculation>
<floatingRateCalculation>
<floatingRateIndex>USD-LIBOR-BBA</floatingRateIndex>
<indexTenor>
<periodMultiplier>3</periodMultiplier>
<period>M</period>
</indexTenor>
<spreadSchedule>
<initialValue>0.0050</initialValue>
</spreadSchedule>
</floatingRateCalculation>
<dayCountFraction>ACT/360</dayCountFraction>
</interestCalculation>
