FpML® Financial product Markup Language Recommendation 17 February 2012 (Confirmation View)

10.3.1.1 The payer and receiver party

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.

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

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

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.

Figure 12: 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 basketConstituent 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 13: 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 dividendPayout 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>
	          

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

The diagrams 15 and 16 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 15: 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 ( 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>
			          

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 16: 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 17: The valuationPriceInterim component of the valuation, with a specific focus on the part of the structure that specifies the price.

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

Figure 19: The valuationPriceFinal component of the valuation, with a specific focus on the part of the structure that specifies the price.

Figure 20: The valuationRules 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 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.

Figure 21: The paymentDates (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 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>
	                        

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

Figure 22: The notional component.

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>
	                        

10.3.1.6 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 23: 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.

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

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

Figure 25: 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 dividendAmount, to refer to one on the 3 Amounts: RecordAmount, ExAmount, PaidAmount; 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 extraOrdinaryDividends, to reference the party which determines if dividends are extraordinary in relation to normal levels; The excessDividendAmount, to determine Gross Cash Dividend per Share; The CurrencyAndDeterminationMethod.model, a choice between currency, determinationMethod and currencyReferenceto, to define return swap amount currency definition methods; The dividendFxTriggerDate, to specify the date on which the FX rate will be considered in the case of a Composite FX swap; The interestAccrualsMethod, 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 numberOfIndexUnits, to define the Number Of Index Units applicable to a Dividend; The DeclaredCashAndCashEquivalentDividendPercentage.model, to declared Cash Dividend Percentage, or Cash Equivalent Dividend Percentage; The nonCashDividendTreatment, to define treatment of Non-Cash Dividends; The dividendComposition, to defines how the composition of Dividends is to be determined; The specialDividends, to specify the method according to which special dividends are determined.;

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

10.3.1.9 The FX Feature (old FX terms)

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 26: The quanto component. The quanto component includes an explicit reference to a rate, through the fxRate 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 27: The FX composite component. The FX composite 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"); specifying a relativeDate specifying fxSpotRateSource (the information source and fixing time and date reference that will be used for defining this exchange rate, using the fx determination component).

The example below illustrates the application of this compositeFx component:

Example 16 - The composite 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>CalculationAgent</determinationMethod>
	  </compositeFx>
	</fxFeature>