## 9 RETURN SWAPS PRODUCT ARCHITECTURE

### 9.1 Return Swaps Scope

FpML provides generic Return Swaps support including "long form" Equity Swap representations, as well as Total Return Swaps. A separate product element called equitySwapTransactionSupplement supports "short form" Equity Swap Transaction Supplement.

Return-type Swaps have 1-to-many Legs, all of which must be derived from the ReturnSwapLeg type. Instances of Legs are returnLeg, interestLeg. Other Leg types may be derived from ReturnSwapLeg at will, to allow for private extensions to support whatever type of Generic Return Swap is desired.

The scope of this FpML representation for return swaps is to capture the following types of swaps that have equity-related underlyers:

- Single stock swaps as well as basket swaps (i.e. swaps with multiple underlyers);
- Swaps that have a different types of underlying assets (equity, index, mutual funds, exchange-traded funds, convertible bond, futures), or a combination of these;
- 2-legged swaps with a combination of an equity leg and a funding leg, as well as swaps that either have only one leg (e.g. fully funded or zero-strike swap) or multiple equity legs (e.g. outperformance swaps);
- Total Return Swaps, a type of swap in which one party (total return payer) transfers the total economic performance of a reference obligation to the other party (total return receiver).

### 9.2 Introduction

FpML Return Swaps Product Architecture amends the previous Equity Swaps Product Architecture since it describes a more generic representation of return type swaps, not only equities. The generic representation includes the product coverage introduced in previous versions of FpML to support full conformance with ISDA 2002 Equity Derivative Definitions, intial and final stubs, and Equity Swap Transaction Supplement. In addition, it supports the representation of Total Return Swaps.

This document provides an in-depth review of the technical architecture of the FpML Return Swap subschema. The scope as well as the current limitations of this schema, which will be addressed through a next release, are described in the first section of this document.

####

9.2.1 The structure of the generic Return Swap

The FpML representation of the returnSwap relies on the structures that are presented in the figure below:

| Swaps may have 1-to-many Legs, the principal components of the return swap schema are as follows: In Transparency view, Return-type Swaps have 2 Legs, all of which must be derived from the ReturnSwapLeg type. Normally one will be a returnLeg and the other an interestLeg. The returnLeg (old equityLeg) component specifies the return leg of the swap. There can be one or several return legs; The interestLeg component defines the interest leg of the swap. Note: The equityLeg was deprecated in FpML 4.2 Second Working Draft and it has been removed in version 5.0. The principalExchangeFeatures is an optional component that describes the case where principal cashflows are exchanged between the parties to the trade; Similarly to the interest rate swap (but with a different structure, that serves the specific features of the return swaps), the additionalPayment component supports the other types of payments involving the parties to the trade, such as fees; Finally, the earlyTermination component specifies, for one or for both the parties to the trade, the date from which it can be early terminated.

### 9.3 Component Descriptions

####

9.3.1 The return leg

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 categories of components are described through the next few pages. They are the following: The determination of the effective date and the termination date; The determination of the strike date for forward starting swaps; 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.

##### 9.3.1.1 The effective date and the termination date

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>

##### 9.3.1.2 The underlyer

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.

##### 9.3.1.2.1 The equity:

| Figure 4: The equity underlyer extends the underlyingAsset component by adding two (optional) elements: the related exchange and the options exchange.

##### 9.3.1.2.2 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.

##### 9.3.1.2.3 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.

##### 9.3.1.2.4 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.

##### 9.3.1.2.5 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.

##### 9.3.1.2.6 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.

##### 9.3.1.2.7 The commodity:

| Figure 10: The commodity underlyer extends the IdentifiedAsset component and may be used in the same way as all other FpML underlyers.

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 11 below provides a high-level view of these two alternative structures, which are detailed in the following paragraphs.

| Figure 11: 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 dividendPayout 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 eleven members of the underlyingAsset substitution group (The bond, convertibleBond, cash, commodity, equity, exchangeTradedFund, future, index, loan, mortgage, mutualFund) do not appear in this diagram: only the basis elements are represented.

Basket underlyers are currently not supported in Transparency view.

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

##### 9.3.1.3 The valuation

Equity Options and Return Swaps both now use a common EquityValuation type.

| Figure 14: 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.

Three possible ways for defining the price of the underlyer are available: as an actual price and currency ( EquityPrice.model), 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>

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

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.

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>ValuationTime</determinationMethod>
    	  <valuationRules>
    	    <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>
    		<valuationTimeType>Close</valuationTimeType>
    	  </valuationRules>
        </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.

        <valuationPriceInterim>
    	  <valuationRules>
    	    <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>
    	  </valuationRules>
    	 </valuationPriceInterim>

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>ValuationTime</determinationMethod>
    	  <valuationRules>
    	  	 <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>
    	    <valuationTimeType>Close</valuationTimeType>
    	  </valuationRules>
    	</valuationPriceInterim>
    	<valuationPriceFinal>
    		<determinationMethod>HedgeExecution</determinationMethod>
    		<valuationRules>
    			<valuationDate id="FinalValuationDate">
    				<adjustableDate>
    					<unadjustedDate>2003-03-12</unadjustedDate>
    					<dateAdjustments>
    						<businessDayConvention>NotApplicable</businessDayConvention>
    					</dateAdjustments>
    				</adjustableDate>
    			</valuationDate>
    		</valuationRules>
    	</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.

It can be noted at this point that the only difference between this valuationPriceFinal component and the valuationPriceInterim component is that only one final valuationDate can be specified, while the possibility is provided to define several interim valuationDates. The equity valuationDates component used for specifying the interim valuation dates has then been substituted with the equity valuationDate 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>HedgeExecution</determinationMethod>
    		<valuationRules>
    		  <valuationDate id="FinalValuationDate">
    		  <adjustableDate>
    		    <unadjustedDate>2004-02-03</unadjustedDate>
    			<dateAdjustments>
    			  <businessDayConvention>NotApplicable</businessDayConvention>
    			</dateAdjustments>
    		  </adjustableDate>
    		</valuationDate>
          </valuationRules>
    	</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 equity paymentDates 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 equity paymentDatesInterim 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 equity paymentDateFinal component specifies the final payment date.

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 calendar location.

    	<rateOfReturn>
    	  <initialPrice>
    	    <netPrice>
    	      <currency>USD</currency>
    	      <amount>37.44</amount>
    	      <priceExpression>AbsoluteTerms</priceExpression>
    	    </netPrice>
    	  </initialPrice>
    	  <notionalReset>true</equityNotionalReset>
    	  <valuationPriceInterim>
    	    <determinationMethod>ValuationTime</determinationMethod>
    	    <valuationRules>
    	      <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>
    	      <valuationTimeType>Close</valuationTimeType>
    	    </valuationRules>
    	  </valuationPriceInterim>
    	  <valuationPriceFinal>
    	    <determinationMethod>HedgeExecution</determinationMethod>
    	    <valuationRules>
    	      <valuationDate id="FinalValuationDate">
    	        <adjustableDate>
    	          <unadjustedDate>2002-09-24</unadjustedDate>
    	          <dateAdjustments>
    	            <businessDayConvention>NotApplicable</businessDayConvention>
    	          </dateAdjustments>
    	        </adjustableDate>
    	      </valuationDate>
    	   	</valuationRules>
    	  </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>

##### 9.3.1.4 The notional amount

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, four possible ways of defining this notional are available:

- By using notionalAmount component to specify an actual amount and currency. This is used most often for the equity leg of the swap;
- By using relativeNotionalAmount component to reference 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 using determinationMethod component to specify a determination method. This is typically useful for forward swaps, which notional is not known on trade date.
- By using relativeDeterminationMethod component to reference a determination method specified somewhere else in the document. This is typically the case of the interest leg of the swap, which determination method refers to a determination method specified through equity leg;

The four 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 amount element is used so that the notional amount of the interest leg can refer to it (example 12 below).

    	<notional>
    	  <notionalAmount id="EquityNotionalAmount">
    	    <currency>USD</currency>
    	    <amount>28469376</amount>
    	  </notionalAmount>
    	</notional>

Example 12 - The reference to a notional amount defined somewhere else in the document:

- This approach is typically used for specifying the notional amount 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>
    	  <relativeNotionalAmount 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>
    	  <determinationMethod id="EquityNotionalAmount">Number of Shares * Initial Price</determinationMethod>
    	</notional>

Example 13b - The reference to a determination method defined somewhere else in the document:

- This approach is typically used for specifying the notional determination method of the interest leg of the swap;
- The relationship with the notional determination method specified in the equity leg is established via the href, which refers to the value specified through the identifier associated with the explicit notional determination method.

    	<notional>
    	  <relativeDeterminationMethod href="EquityNotionalAmount"/>
    	</notional>

##### 9.3.1.5 The amount

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: The amount 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 payment currency 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 determinationMethod 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 currencyReference 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.

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>

##### 9.3.1.6 The return

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

In Transparency view the return component has only a 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.

##### 9.3.1.7 The notional adjustment

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.

####

9.3.2 The interest leg

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 several categories of components, which are presented in the figure 28 below and respectively specify the following features of the interest leg:

- The calculation dates (represented by interestLegCalculationPeriodDates component);
- The notional amount (represented by notional component);
- The interest amount (represented by interestAmount component);
- The interest calculation (represented by interestCalculation component);

| Figure: The interestLeg of the returnSwap.

##### 9.3.2.1 The calculation dates

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 interestLegResetDates component;
- The payment dates, through the interestLegPaymentDates 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 interestLegPaymentDates. These components indeed all provide the possibility to define a date (or several dates, in the case of the interestLegPaymentDates component) as either an actual date or in reference to a date specified somewhere else in the document.

The interestLegResetDates 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.

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 effectiveDate is defined similarly than for the equity leg, as one settlement cycle following the trade date;
- The terminationDate is also defined in the same way than the equity leg, as corresponding to the last equity payment date;
- The interestLegResetDates 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 interestLegPaymentDates 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>

##### 9.3.2.2 The notional amount

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.

##### 9.3.2.3 The interest amount

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>

##### 9.3.2.4 The interest calculation

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

####

9.3.3 The additional payments when involving the principal parties to the trade

Similarly to the principal exchange, the EquitySwapAdditionalPayment complex type extends the design developed for the interest rate swaps by providing the ability to define dates in relation to other dates, as well as to specify the calculation logic that supports certain types of fees.

This additionalPayment structure leverages some of the features that are also used through other components:

- The additionalPaymentAmount component provides the flexibility to define an actual amount (through the paymentAmount component) and/or to describe the methodology for determining such amount, leveraging the formula component developed for the LegAmount complex type;
- Similarly to the PrincipalExchangeFeatures component, the date of each of the additional payments can be defined either as actual dates or in relation to dates defined somewhere else in the document, through respectively the adjustableDate and the relativeDate components;
- The optional paymentType string element provides the opportunity to characterize the additional payment.

Example 21 - Upfront fee:

- An upfront fee is paid by Party A to Party B, on the effective date of the swap;
- This upfront fee is equal to: 18388000 * Reference Price * [6.5% (the upfront Fee) + 0.63% (taxes)].

    	<additionalPayment>
    	  <payerPartyReference href="PartyA"/>
    	  <receiverPartyReference href="PartyB"/>
    	  <additionalPaymentAmount>
    	    <formula>
    	      <formulaDescription>18388000 * Reference Price * [6.5% (the upfront Fee) + 0.63% (taxes)]</formulaDescription>
    	      <math>
    	        <mn>18388000 </mn>
    	        <mo>*</mo>
    	        <mi>ReferencePrice</mi>
    	        <mo>*</mo>
    	        <mo>(</mo>
    	        <mn>6.5</mn>
    	        <mo>%</mo>
    	        <mo>+</mo>
    	        <mn>0.63</mn>
    	        <mo>%</mo>
    	        <mo>)</mo>
    	      </math>
    	      <formulaComponent name="ReferencePrice">
    	        <componentDescription>Volume-weighted average price per share of underlying security on Trade Date</componentDescription>
    	      </formulaComponent>
    	    </formula>
    	  </additionalPaymentAmount>
    	  <additionalPaymentDate>
    	    <relativeDate>
    	      <periodMultiplier>0</periodMultiplier>
    	      <period>D</period>
    	      <businessDayConvention>NotApplicable</businessDayConvention>
    	      <dateRelativeTo href="EffectiveDate"/>
    	    </relativeDate>
    	  </additionalPaymentDate>
    	  <paymentType>Upfront fee</paymentType>
    	</additionalPayment>

####

9.3.4 The optional early termination

The purpose of the ReturnSwapEarlyTermination component is to specify the date from which each of the parties to the trade may have the right to terminate it early. The figure 33 below presents the structure of this component:

Figure: The earlyTermination component.

Similarly to the other date-related components that are part of the return swap, the date can be specified using either the adjustableDate component or the relativeDate component. Considering that the standard market practice is to provide the ability for both the parties to the trade to early terminate it starting on Trade Date, the relativeDate element should be used most often. This is illustrated in the example below.

    	<earlyTermination>
    	  <partyReference href="PartyA"/>
    	  <startingDate>
    	    <dateRelativeTo href="TradeDate"/>
    	  </startingDate>
    	</earlyTermination>
    	<earlyTermination>
    	  <partyReference href="PartyB"/>
    	  <startingDate>
    	    <dateRelativeTo href="TradeDate"/>
    	  </startingDate>
    	</earlyTermination>

Previous | Top of Section | Next
--- | --- | ---