FpML® Financial product Markup Language Recommendation 28 May 2013 (Transparency View)

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

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

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.

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>
	          

10.3.1.3 The valuation

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

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>
	                        

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

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

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>
	          

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

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