FpML 4.1 Trial Recommendation

9 EQUITY DERIVATIVE SWAPS PRODUCT ARCHITECTURE

9.1 Introduction

FpML 4.1 Equity Derivative Swaps Product Architecture amends the product coverage introduced in FpML to support full conformance with ISDA 2002 Equity Derivative Defintions, intial and final stubs, and introduce Equity Swap Transaction Supplement.

This document provides an in-depth review of the technical architecture of the FpML 4.1 Equity 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 Equity Derivatives Swaps Scope

As shown in the section 8.1 Overall Architecture, FpML 4.1 provides for both "short form" transaction supplement and "long form" Equity Swap Representations.

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

The scope of this FpML representation for equity 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);
Swaps that have specific adjustment conditions, such as execution swaps or portfolio rebalancing swaps;
Swaps that involve the exchange of principal cashflows;
Swaps that have inital and final stubs;
Swaps which can be represented as Transaction Supplements under ISDA Master Agreements;
Variance Swaps, a type of volatility swap where the payout is linear to variance rather than volatility, therefore the payout will rise at a higher rate than volatility.

Extraordinary Events terms have been incorporated, to take into consideration the release of the 2002 ISDA Definitions for Equity Derivatives.

Trigger swaps, in which equity risk morphs into a fixed income risk once a certain market level is reached, may be supported in a subsequent release.

9.3 The structure of the equity swap

The FpML representation of the equity swap relies on five key structures that are presented in the figure 1 below:

Figure 1: The equitySwap main components.

Swaps may have 1-to-many Legs, the principal components of the equity swap schema are as follows:

The equityLeg component specifies the equity leg of the swap. There can be one or several equity legs;
The interestLeg component defines the interest leg of the swap. The possibility is provided for having swaps that do not have an interest leg (case of an outperformance swap where 2 equity underlyers are swapped, or a fully-funded swap where there is no financing component);
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 equity 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.

equitySwapTransactionSupplement implements Equity Swap Transaction Supplements by providing a short form representation for use in trades governed by a Master Confirmation Agreement. Due to the wide scope of the Equity Swap Transaction Supplement, it has not been possible to make the equitySwapTransactionSupplement component as compact as equityOptionTransactionSupplement

The various sections below detail each of these five structures of the equity leg of the swap.

9.4 The equity leg

The figure 2 presents the structure of the equity leg of the swap, which has 10 categories of components:

Figure 2: The structure of the equity leg.

These 10 categories of components are described through the next few pages. They are the following:

The identification of the payer and receiver party for this equity leg;
The determination of the effective date and the termination date;
The description of the underlying asset(s);
The valuation terms;
The specification of the notional;
The determination of the equity 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.4.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.

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

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

The equity:

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

The index:

Figure 5: The index underlyer extends the underlyingAsset component by adding two (optional) elements: the related exchange and the identifier of the reference future contract that may have been referenced as part of the swap contract.

The mutual fund:

Figure 6: The mutual fund underlyer extends the underlyingAsset component by adding two (optional) elements: the indicator of whether the fund is open or closed and the name of the fund manager.

The exchange-traded fund:

Figure 7: The exchange-traded fund underlyer extends the underlyingAsset component by adding three (optional) elements: the related exchange, the options exchange and the name of the fund manager.

The future contract:

Figure 8: The future contract underlyer extends the underlyingAsset component by adding four (optional) elements: the related exchange, the options exchange, the contract multiplier and the specific reference of the future contract that is used as part of the swap.

The convertible bond:

Figure 9: The convertible bond underlyer extends the underlyingAsset component through six elements that characterize the instrument (the related exchange, the issuer name, the coupon rate, the maturity date, the par value and the face amount); in addition, the underlyingEquity component describes the equity underlyer in which the convertible bond can be turned into.

These various types of underlyers can be combined through two different structures, depending upon whether the swap has only one underlyer or has multiple underlying assets: the singleUnderlyer structure or the basket structure. The figure 10 below provides a high-level view of these two alternative structures, which are detailed in the following paragraphs.

Figure 10: Overview of the two alternative types of underlying structured: the singleUnderlyer and the basket.

In the case of a single underlyer, the singleUnderlyer component specifies the number of open units, the description of the underlyer (through the underlyingAsset substitution group) and the dividend payout ratio (which is defined through the underlyer component rather than the return component for reasons that are related to the basket, and that are explained below). It should be noted that the seven members of the underlyingAsset substitution group (bond, convertibleBond, equity, exchangeTradedFund, future, index, mutualFund) do not appear in this diagram: only the basis elements are represented.

Figure 11: The single underlyer.

The basket component is to be applied in the case where there are several underlyers, which are then specifically described through the basketConstituents component. This basket component is structured as follows: an identification of the number of basket units (typically, one) and a description of each of the basket constituents (through a one-to-many relationship).

Figure 12: The basket.

The structure that describes the basket is quite more complex than the one that specifies the single underlyer. Besides defining the number of basket units (typically, one), the structure specifies each of the basket constituents through an asset description, a constituent weight, a dividend payout ratio, a price and a notional description. The underlyingAsset component having been already described, the points below focus on the four latter components:

The constituentWeight specifies the number of units of each of the basket constituents and, optionally, their respective weight in the basket. It is an optional component, considering that some more exotic types of equity swaps do not have a relative weight associated with each their underlyer components.
The dividend payout ratio has been associated with the description of the underlyer rather than included in the definition of the return component in order to address the case where a different payout ratio is be associated with the respective components of a basket swap.
The underlyerPrice component describes the price of each of the basket components; it is optional in order to take into consideration the cases where the market participants do not specify the breakdown by underlyer of the price that is defined at the leg level (which, in the case of a basket swap, corresponds to the notional of the equity leg of the swap). Its structure is based upon the Price complex type, which provides a great flexibility in the way the price of an asset can be defined. This price structure is described in more details through the later developments that are devoted to the valuation component.
The underlyerNotional is also an optional component; it provides the possibility to break down by underlyer the notional for the equity leg, which can be particularly useful when several currencies are used across the various underlyers.

As an illustration of this structure of the basket component and an introduction to the upcoming developments that are devoted to the valuation, the example below presents the case of a basket swap which underlyers components are listed in various currencies.

Example 2 - Basket swap with underlyers listed in different currencies:

The basket is comprised of one underlyer that is listed in EUR (TIM.MI) and one that is listed in GBP (VOD.L);
The reference currency of the swap is USD (this information is carried through the equityAmount component, which is not indicated here);
Each of the two basketConstituent structures carry the information about both its local price and its price after conversion in USD;
The information about the currency conversion rates is specified through the valuation component (that is not depicted below), as this information is not specific to the underlyer;
The initial price of the swap is USD 7,376,406. This corresponds to the multiplication of each of the underlyer prices by its respective quantity, after conversion in USD: 4.182*783,000 [TIM.MI ]+ 165*24,860 [VOD.L]. It also corresponds to the initial notional of the equity swap. This initial price is not depicted here, as it is part of the valuation component of the equity leg.

<underlyer>
  <basket>
    <openUnits>1</openUnits>
    <basketConstituent>
      <equity>
        <instrumentId instrumentIdScheme="RIC">TIM.MI</instrumentId>
        <description>Telecom Italia Mobile spa</description>
        <currency>EUR</currency>
        <exchangeId exchangeIdScheme="http://www.fpml.org/schemes/4.0/exchangeId">Milan Stock Exchange</exchangeId>
      </equity>
      <constituentWeight>
        <openUnits>783000</openUnits>
      </constituentWeight>
      <dividendPayout>
        <dividendPayoutRatio>85</dividendPayoutRatio>
      </dividendPayout>
      <underlyerPrice>
        <grossPrice>
          <currency>EUR</currency>
          <amount>4.14</amount>
          <priceExpression>AbsoluteTerms</priceExpression>
        </grossPrice>
        <netPrice>
          <currency>USD</currency>
          <amount>4.182</amount>
          <priceExpression>AbsoluteTerms</priceExpression>
        </netPrice>
      </underlyerPrice>
      <underlyerNotional>
        <currency>USD</currency>
        <amount>3274506</amount>
      </underlyerNotional>
    </basketConstituent>
    <basketConstituent>
      <equity>
        <instrumentId instrumentIdScheme="RIC">VOD.L</instrumentId>
        <description>Vodafone Group</description>
        <currency>GBP</currency>
        <exchangeId exchangeIdScheme="http://www.fpml.org/schemes/4.0/exchangeId">London Stock Exchange</exchangeId>
      </equity>
      <constituentWeight>
        <openUnits>24860</openUnits>
      </constituentWeight>
      <dividendPayout>
        <dividendPayoutRatio>85</dividendPayoutRatio>
      </dividendPayout>
      <underlyerPrice>
        <grossPrice>
          <currency>GBP</currency>
          <amount>110.00</amount>
          <priceExpression>AbsoluteTerms</priceExpression>
        </grossPrice>
        <netPrice>
          <currency>USD</currency>
          <amount>165.00</amount>
          <priceExpression>AbsoluteTerms</priceExpression>
        </netPrice>
      </underlyerPrice>
      <underlyerNotional>
        <currency>USD</currency>
        <amount>4101900</amount>
      </underlyerNotional>
    </basketConstituent>
  </basket>
</underlyer>

9.4.4 The valuation

Equity Derivatives and Equity Swaps both now use a common equityValuation component.

Figure 13: The EquityValuation type, that specifies the valuation terms of the equity leg of the swap.

The following developments present in more details the four main structures that are part of this EquitySwapValuation type: the initialPrice, the valuationPriceInterim, the valuationPriceFinal and the 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 equity underlyer of the trade. In most of the cases, this price will be known. There can however be certain cases, such as a forward trade, where the actual price is not known on trade date and where the trade confirmation will rather specify the terms according to which this initial price will be determined at a later point.

The diagrams 14 and 15 below present the two sets of structures that are used for specifying these various cases: one (mandatory) structure that specifies the price and one (optional) structure that specifies the dates.

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

Three possible ways for defining the price of the underlyer are available: as an actual price and currency, in reference to an amount defined somewhere else in the document using the amountRelativeTo element, or by specifying a specific determination method using the determinationMethod component. Commissions can be associated with each of these three alternative definitions. For addressing the requirements related to composite FX swaps, the possibility is also provided, through the fxConversion component, to explicitly define the FX rate that has been used to convert the price from its listing currency to the reference currency of the swap.

Considering that in the vast majority of the cases the initial price is defined as an actual price and currency, the examples below will focus on detailing the various options available for specifying such actual price. The other possibilities offered through the Price type will be further detailed through the interim and final price components.

Example 3 - Specification of an initial price as an actual price that does not include commissions and FX terms:

Price amount: 37.44;
Price currency: USD;
Price expression: in absolute terms (as opposed to as a percentage of the notional);
There are no commissions nor FX terms associated with the price.

<initialPrice>
  <netPrice>
    <currency>USD</currency>
    <amount>37.44</amount>
    <priceExpression>AbsoluteTerms</priceExpression>
  </netPrice>
</initialPrice>

Example 4 - Specification of an initial price as an actual price that also includes commissions and FX terms:

Basket swap, which price at the leg level corresponds to the multiplication of the respective prices and quantities of the various underlyer components, i.e. to the notional of the swap;
Gross amount: 113,228,777 CAD;
Net amount: 84,089,141 USD;
Commission: 5 basis points
Exchange rate: 1 USD = 1.34665 CAD
Price expression: in absolute terms (as opposed to as a percentage of the notional);
There are no commissions nor FX terms associated with the price.

<initialPrice>
  <commission>
    <commissionDenomination>BPS</commissionDenomination>
    <commissionAmount>5</commissionAmount>
  </commission>
  <grossPrice>
    <currency>CAD</currency>
    <amount>113228777</amount>
    <priceExpression>AbsoluteTerms</priceExpression>
  </grossPrice>
  <netPrice>
    <currency>USD</currency>
    <amount>84089141</amount>
    <priceExpression>AbsoluteTerms</priceExpression>
  </netPrice>
  <fxConversion>
    <fxRate>
      <quotedCurrencyPair>
        <currency1>CAD</currency1>
        <currency2>USD</currency2>
        <quoteBasis>Currency2PerCurrency1</quoteBasis>
      </quotedCurrencyPair>
      <rate>1.34665</rate>
    </fxRate>
  </fxConversion>
</initialPrice>

Example 5 - Specification of an initial price as a percentage of the notional, without commissions nor FX terms:

Price: 94.80278% of the notional amount.

      
<initialPrice>
  <netPrice>
    <amount>94.80278</amount>
    <priceExpression>PercentageOfNotional</priceExpression>
  </netPrice>
</initialPrice>

Figure 15: The initialPrice component of the valuation, with a specific focus on the part of the structure that specifies the date and time of the initial valuation.

This structure that specifies the date and time of the valuation will typically not be used as part of the definition of the initial price. This is because in most cases the initialPrice component specifies the price of the underlyer that is used as the initial reference point for the swap, and there is no need to refer to any specific date or time. Considering that this 'building block is defined and used in a quite similar same way for the interim and final price, it will be detailed through these latter.

The purpose of the valuationPriceInterim component is to specify the interim price(s) for the equity underlyer of the trade. This is an optional component, as it does not apply in the case of a bullet swap, where there is no reset date. Its other specificity vis-a-vis the initial and final valuation components it that this components can hold an array of valuation dates, as opposed to only one valuation date.

Similarly to the initialPrice component, the diagrams 16 and 17 below present the two sets of structures that are part of the valuationPriceInterim component: one structure that specifies the price and one structure that specifies the valuation dates. Both structures are mandatory.

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

Figure 17: The valuationPriceInterim component of the valuation, with a specific focus on the part of the structure that specifies the dates.

The example 6 below is very illustrative of the typical use of the valuationPriceInterim structure for representing the interim valuation prices of an equity swap:

As part of the Price structure, the determinationMethod node of the choice sequence will be used for specifying how the future prices of the underlyer will be determined;
The definition of the time of the valuation essentially relies upon the valuationTimeType element, that specifies the time of day at which the Calculation Agent values the underlyer: the valuationTime component, which purpose is to specify an actual valuation time, is expected to be used only in some rare cases;
Most often, a schedule of valuation dates will be specified, to which the payment schedule will refer.

Example 6 - Typical example of how the valuationPriceInterim component is used to specify the the interim valuation:

A schedule of 11 interim valuation dates is defined, that extends from October 12, 2001 to August 12, 2002;
This schedule of dates already takes into consideration the expected exchange holidays. Hence, no business day convention is applicable;
On each of these valuation dates, the equity underlyer will be valued at the market close.

    
<valuationPriceInterim>
  <determinationMethod>PriceAtValuationTime</determinationMethod>
  <valuationTimeType>Close</valuationTimeType>
  <equityValuationDates 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>
  </equityValuationDates>
</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.

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

The example 8 below provides another example of an unusual definition of the interim valuation date. Here, the valuation dates are defined through a rule-based schedule, which corresponds to the market practice typically in use for fixed income swaps. This practice is however used only rarely in the case of equity derivatives.

Example 8 - The interim valuation dates are defined through a rule-based schedule:

The underlyer is valued at the market close on each of the interim valuation dates;
The final valuation is based on the price obtained by the payer of the equity return when unwinding his hedge position;
The first valuation date is April 10, 2002;
Each of the following valuations is scheduled on the 10th of each month, until the last valuation date which is scheduled on March 12, 2003;
The business day convention is not applicable, because the terms 'Modified Following', 'Following', 'Preceding', etc. are not recognized ISDA terms in the context of exchange business days. On the other hand, the ISDA Definition for Equity Derivatives is, by default, to roll forward if a scheduled valuation date is not a exchange business day.

<valuationPriceInterim>
  <determinationMethod>Valuation time</determinationMethod>
  <valuationTimeType>Close</valuationTimeType>
  <equityValuationDates 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>
  </equityValuationDates>
</valuationPriceInterim>
<valuationPriceFinal>
  <determinationMethod>HedgeUnwind</determinationMethod>
  <equityValuationDate id="FinalValuationDate">
    <adjustableDate>
      <unadjustedDate>2003-03-12</unadjustedDate>
      <dateAdjustments>
        <businessDayConvention>NotApplicable</businessDayConvention>
      </dateAdjustments>
    </adjustableDate>
  </equityValuationDate>
</valuationPriceFinal>

The purpose of the valuationPriceFinal component is to specify the final price for the equity underlyer of the trade.

In a similar way than what has been previously detailed for the components that specify the initial and the intermediate valuations, the diagrams 18 and 19 below respectively detail the structure that specifies the final price and the structure that specifies the date on which this valuation will take place. Both structures are mandatory.

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

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

It can be noted at this point that the only difference between this valuationPriceFinal component and the valuationPriceInterim component is that only one final valuation date can be specified, while the possibility is provided to define several interim valuation dates. The equityValuationDates component used for specifying the interim valuation dates has then been substituted with the equityValuationDate component, which allows only one date.

The example 8 below presents the most common use of this structure, a specific final valuation date being defined while the final price is specified through the use of the determinationMethod element. Of course, if the interim valuation dates would be defined in reference to the payment dates (as illustrated in the example 7) or through a rule-based schedule (example 8), such method would also be applied for defining the final valuation date.

Example 9 - The most common definition of the final valuation:

The final price of the equity underlyer will correspond to the price at which the payer of the equity leg will unwind his hedge position;
A commission of 60 basis points will be applied to this price;
The final valuation date is February 3, 2004;
In accordance to the market practice, this date has been determined by the Calculation Agent as corresponding to an exchange business day. As previously indicated, the terms 'Modified Following', 'Following', 'Preceding', etc. are not recognized ISDA terms in the context of exchange business days.

<valuationPriceFinal>
  <commission>
    <commissionDenomination>BPS</commissionDenomination>
    <commissionAmount>60</commissionAmount>
  </commission>
  <determinationMethod>HedgeUnwind</determinationMethod>
  <equityValuationDate id="FinalValuationDate">
    <adjustableDate>
      <unadjustedDate>2004-02-03</unadjustedDate>
      <dateAdjustments>
        <businessDayConvention>NotApplicable</businessDayConvention>
      </dateAdjustments>
    </adjustableDate>
  </equityValuationDate>
</valuationPriceFinal>

The last structure that participates in the definition of the equity swap valuation is the schedule of equity payment dates. These dates are specified through the equityPaymentDates component. The structure of this component is threefold:

An Identifier is associated to the equityPaymentDates root component, in order to allow to specify a generic reference to these payment dates. This unique reference to the payment dates is used through the dividend component, when it is specified that the dividend will be paid on the next equity payment date (see below the section related to the return component of the equity leg);
The equityPaymentDatesInterim component specifies the interim payment dates of the swap. It is optional to address the case of bullet swaps that do not have interim equity resets;
The equityPaymentDateFinal component specifies the final payment date.

Figure 20: The equityPaymenDate component, that specifies the schedule of equity payment dates.

The structure of the equityPaymentDatesInterim and the 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 equity 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 equity payment dates are scheduled 3 currency business days after each of the valuation dates. Considering that these are currency business days, as opposed to exchange business days, the 'Following' business day convention is specified, New York being the reference business center.

<valuation>
  <initialPrice>
    <netPrice>
      <currency>USD</currency>
      <amount>37.44</amount>
      <priceExpression>AbsoluteTerms</priceExpression>
    </netPrice>
  </initialPrice>
  <equityNotionalReset>true</equityNotionalReset>
  <valuationPriceInterim>
    <determinationMethod>PriceAtValuationTime</determinationMethod>
    <valuationTimeType>Close</valuationTimeType>
    <equityValuationDates 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>
    </equityValuationDates>
  </valuationPriceInterim>
  <valuationPriceFinal>
    <determinationMethod>HedgeUnwind</determinationMethod>
    <equityValuationDate id="FinalValuationDate">
      <adjustableDate>
        <unadjustedDate>2002-09-24</unadjustedDate>
        <dateAdjustments>
          <businessDayConvention>NotApplicable</businessDayConvention>
        </dateAdjustments>
      </adjustableDate>
    </equityValuationDate>
  </valuationPriceFinal>
  <equityPaymentDates id="EquityPaymentDate">
    <equityPaymentDatesInterim 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>
    </equityPaymentDatesInterim>
    <equityPaymentDateFinal id="FinalEquityPaymentDate">
      <relativeDate>
        <periodMultiplier>3</periodMultiplier>
        <period>D</period>
        <dayType>CurrencyBusiness</dayType>
        <businessDayConvention>FOLLOWING</businessDayConvention>
        <businessCentersReference href="PrimaryBusinessCenter"/>
        <dateRelativeTo href="FinalValuationDate"/>
      </relativeDate>
    </equityPaymentDateFinal>
  </equityPaymentDates>
</valuation>

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

By specifying an actual amount and currency. This is used most often for the equity leg of the swap;
By referencing an amount specified somewhere else in the document. This is typically the case of the interest leg of the swap, which notional refers to notional specified through equity leg;
By specifying a determination method, using the determinationMethod component This is typically useful for forward swaps, which notional is not known on trade date.

Figure 21: The notional component.

The three examples below illustrate each of these cases mentioned before:

Example 11 - The explicit notional amount:

This approach is typically used for specifying the notional of the equity leg of the swap;
The identifier attribute associated with the notional element is used so that the notional of the interest leg can refer to it (example 12 below).

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

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

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

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

Example 13 - The use of the determinationMethod for specifying the notional amount:

The initial price of the equity underlyer is not known on trade inception: it will be determined at a later point;
As a consequence, only the method through which the notional is calculated is specified as part of the swap.

<notional id="EquityNotionalAmount">
  <determinationMethod>Number of Shares * Initial Price</determinationMethod>
</notional>

9.4.6 The equity amount

The main purpose of the equityAmount component is to specify the method that determines the equity amount to be paid/received on each of the equity 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 equity leg of the swap.

Figure 22: The equityAmount component.

This equityAmount component is based on the LegAmount type that is also used for defining the interestAmount. It extends this type by adding a boolean cashSettlement element that specifies whether the swap will cash or physically settle.

The paymentCurrency is the first component of this structure. It specifies the payment currency of the equity leg of the swap through three possible methods:

As an actual ISO currency code;
As a determination method description, applicable in the case of some exotic swap where the payment currency of the trade will be a function of certain parameters;
Through the reference to a currency defined somewhere else in the document, as in the case of a quanto swap or a composite FX swap which reference currency is specified through the fxTerms component.

The core of the equityAmount component is its second component, which specifies the payoff of the equity 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 equity 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 equity payoff, the encodedDescription element provides the ability to encode an image that describes the payout formula, using a base64Binary structure.

The optional calculationDates component is also aimed at these more complex equity swaps. It provides the possibility to define calculation dates (such as observation points in the case of an equity payoff that is a function of some specific market levels). These calculation dates can be specified similarly to the valuation dates:

As an actual schedule of dates, using the adjustableDates component;
In relation to some dates defined elsewhere in the document, using the relativeDateSequence component;
Through a rule-based schedule, using the periodicDates component.

Figure 23: The calculationDates component, that provides the opportunity to define calculation dates for more exotic types of equity swaps.

Example 14 - The use of the equityAmount component for a vanilla equity swap:

The payment currency of the equity leg is USD;
The payoff amount of the equity leg is specified as the ISDA standard definition, i.e. equal to the product of the equity notional amount and the rate of return;
The settlements will be made in cash.

<equityAmount>
  <paymentCurrency id="EquityPaymentCurrency">
    <currency>USD</currency>
  </paymentCurrency>
  <referenceAmount>ISDA Standard</referenceAmount>
  <cashSettlement>true</cashSettlement>
</equityAmount>

9.4.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 24: The return component.

This return component has two sets of element: the returnType element, that specifies (through an enumeration) whether the contract is a total return swap, a price return swap or a dividend return swap, and the dividendConditions component, which describes the various conditions applicable to the dividend, including whether and how interests will be accrued if they are paid after the dividend pay date. This second component is optional, as it does not apply in the case of a price return swap. Its dividend terms are the following:

The dividendReinvestment, as a Boolean data element that determines whether the dividend will be reinvested into the equity notional;
The dividendEntitlement, to indicate when the counterparty is entitled to the dividend;
The dividendPaymentDate, to specify when the dividend will be paid. This date can be specified either through a set of pre-defined values that are associated with the dividendDateReference element that is part of this component, or as a specific date. These pre-defined values can refer either to dividend dates (ExDate, DividendPaymentDate, RecordDate) or to dates that relate to the swap contract (TerminationDate, EquityPaymentDate, FollowingPaymentDate);
The dividendPeriodEffectiveDate and the dividendPeriodEndDate, to indicate when the swap is considered as active from the perspective of dividend processing and when such period ends;
The dividendFxTriggerDate, to specify the date on which the FX rate will be considered in the case of a Composite FX swap;
The interestAccruals, to define how interests will be accrued on the dividend when this latter is paid some period of time after the dividend payment date.

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

9.4.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 25: The quanto component.

The quanto component includes an explicit reference to a rate, through the quantoRate element. One or several rates can be defined, in order to address the case where a basket swap is composed of several underlyers that are listed in different currencies.

The example below illustrates the application of this quanto component:

Example 15 - The quanto component:

The business background for this trade is that the payment currency of the swap is USD, while some of the underlyers are listed in EUR and some others are listed in HKD. The payer of the equity return commits upfront to a set of exchange rates vis-a-vis the USD which are specified as part of the quanto component;
The EUR is quoted per units of USD and the exchange rate is 0.99140;
The HKD is also quoted per units of USD and the exchange rate is 7.80.

<fxFeature>
  <quanto>
    <referenceCurrency id="ReferenceCurrency">USD</referenceCurrency>
    <fxRate>
      <quotedCurrencyPair>
        <currency1>USD</currency1>
        <currency2>EUR</currency2>
        <quoteBasis>Currency2PerCurrency1</quoteBasis>
      </quotedCurrencyPair>
      <rate>0.99140</rate>
    </fxRate>
    <fxRate>
      <quotedCurrencyPair>
        <currency1>USD</currency1>
        <currency2>HKD</currency2>
        <quoteBasis>Currency2PerCurrency1</quoteBasis>
      </quotedCurrencyPair>
      <rate>7.80</rate>
    </fxRate>
  </quanto>
</fxFeature>

Figure 26: The compositeFx component.

The compositeFx component provides the framework for defining a currency rate at some point in the future. This can be done either by defining a generic method using the determinationMethod component (for example, when it is agreed that the exchange rate will be determined "in good faith by the Calculation Agent") or by specifying the information source and fixing time and date reference that will be used for defining this exchange rate, using the fxDetermination component.

The example below illustrates the application of this compositeFx component:

Example 16 - The compositeFx component:

The payment currency of the swap is EUR;
The exchange rate will be determined in good faith by the Calculation Agent.

<fxFeature>
  <compositeFx>
    <referenceCurrency id="ReferenceCurrency">USD</referenceCurrency>
    <determinationMethod>GoodFaith</determinationMethod>
  </compositeFx>
</fxFeature>

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

The payer and the receiver party;
The calculation dates;
The notional amount;
The interest amount;
The interest calculation;
The initial and final stubs.

Figure 27: The interest leg of the equity swap.

9.5.1 The payer and receiver party

The identification of the payer and receiver party of the equity leg is done similarly than for the equity leg of the swap, through the payerPartyReference and receiverPartyReference data elements.

9.5.2 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 interestRateResetDates component;
The payment dates, through the interestRatePaymentDates component.

The diagram below presents the key features of these different date structures. Three of these components are structured in the same way: the effectiveDate, the terminationDate and the interestRatePaymentDates. These components indeed all provide the possibility to define a date (or several dates, in the case of the interestRatePaymentDates component) as either an actual date or in reference to a date specified somewhere else in the document.

The interestRateResetDates component has been developed as a simplified version of the ResetDates type that is part of the interest rates derivatives schema. Three of the seven components that are part of this ResetDates type have indeed been reused:

The calculationPeriodDatesReference is an empty element that holds an href into the identifier attribute that is associated with the interestLegCalculationPeriodDates;
The resetRelativeTo specifies whether the reset dates are determined with respect to each adjusted calculation period start date or adjusted calculation period end date;
The resetFrequency component provides the possibility to define a specific reset frequency, instead of defining the reset in relation to the various interest calculation dates: the effective date, the respective interest payment dates and the termination date.

Figure 28: The interestLegCalculationPeriodDates component.

The example below presents a typical example of how this schema is applied to the standard interest leg of an equity swap:

Example 17 - The calculation period dates of the interest leg of an equity swap:

The effective date is defined similarly than for the equity leg, as one settlement cycle following the trade date;
The termination date is also defined in the same way than the equity leg, as corresponding to the last equity payment date;
The reset dates for the floating rate are defined as corresponding to the first day of each of the calculation periods by referencing the identifier that is associated with the interestLegCalculationPeriodDates node;
The interest payment dates are specified in reference to the equity payment dates: this is called a combined reset, as a net amount corresponding to the difference between the interest and the equity amount will be exchanged on each payment date.

<interestLegCalculationPeriodDates id="InterestLegPeriodDates">
  <effectiveDate>
    <relativeDate>
      <periodMultiplier>3</periodMultiplier>
      <period>D</period>
      <dayType>ExchangeBusiness</dayType>
      <businessDayConvention>NotApplicable</businessDayConvention>
      <dateRelativeTo href="TradeDate"/>
    </relativeDate>
  </effectiveDate>
  <terminationDate>
    <relativeDate>
      <periodMultiplier>0</periodMultiplier>
      <period>D</period>
      <businessDayConvention>NotApplicable</businessDayConvention>
      <dateRelativeTo href="FinalEquityPaymentDate"/>
    </relativeDate>
  </terminationDate>
  <interestLegResetDates>
    <calculationPeriodDatesReference href="InterestLegPeriodDates"/>
    <resetRelativeTo>CalculationPeriodStartDate</resetRelativeTo>
  </interestLegResetDates>
  <interestLegPaymentDates>
    <relativeDates>
      <periodMultiplier>0</periodMultiplier>
      <period>D</period>
      <businessDayConvention>NotApplicable</businessDayConvention>
      <dateRelativeTo href="EquityPaymentDate"/>
    </relativeDates>
  </interestLegPaymentDates>
</interestLegCalculationPeriodDates>

9.5.3 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.5.4 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.5.5 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.

Figure 29: The interestCalculation component.

The example below presents a typical example of how this interestCalculation component can be applied for specifying the floating rate of an equity swap:

Example 19 - Specifying the floating rate of an equity swap:

The reference rate is 3 month USD-LIBOR-BBA;
The spread is plus 50 basis points;
The day count fraction is actual number of days / 360 days.

<interestCalculation>
  <floatingRateCalculation>
    <floatingRateIndex>USD-LIBOR-BBA</floatingRateIndex>
    <indexTenor>
      <periodMultiplier>3</periodMultiplier>
      <period>M</period>
    </indexTenor>
    <spreadSchedule>
      <initialValue>0.0050</initialValue>
    </spreadSchedule>
  </floatingRateCalculation>
  <dayCountFraction>ACT/360</dayCountFraction>
</interestCalculation>

9.6 The variance leg

The variance leg supports equity variance swaps as defined in ISDA Equity Variance Swap Transaction Supplements. Due to the need to maintain backwards compatibility in this release it has not been possible to change the existing equity leg in order to support both a "short form" representation, and the concept of return based on variance. Due to the diversity of choices supported by the Equity Swap Transacation Supplement a "short form" would in any case not be much more compact than "long form".

9.7 The initial and final stub

The representation of the stub periods for the equity swaps schema makes use of the Stub type that was initially developed for the interest rates schema.

The initialStub and the finalStub components respectively describe the initial and final stubs. For each of those, the component specifies the rate (or stub amount), the stub start date and the stub end date. The payment dates that relate to the stub period(s) are specified along with the payment dates of the main period, in the interestLegCalculationPeriodDates component.

9.8 The principal exchange

Some types of equity swaps do not have an interest leg. Their economic structure relies instead in the exchange of the principal of the swap between the parties. These are the fully funded and zero-strike swaps. The purpose of the PrincipalExchangeFeatures component is to specify this feature that is associated with those swaps. (It should however be noted that the schema also accommodates some more exotic cases that would combine an interest leg which notional would be smaller than the notional of the equity leg, and that would also have a principal exchange.)

Figure 30: The exchange of principal amounts.

This component extends the design developed for the interest rate swaps (through the principalExchanges component) by adding the PrincipalExchangeDescriptions component, which has the following features:

It specifies the payer and receiver party references;
The date of each of the principal exchanges can be defined either as an actual date (using the adjustableDate component) or in relation to a date defined somewhere else in the document (via the relativeDate component);
The principal exchange amount can be defined in three possible ways: (i) By pointing to an amount defined elsewhere in the swap document, through the use of the amountRelativeTo element; (ii) By using the determinationMethod element, that describes a method according to which an amount is determined; (iii) By using the principalAmount component, which allows to explicitly determine an actual amount.

Example 20 - Initial principal exchange:

The principal exchange takes place at the initial period of the swap;
The payment date is defined as being the effective date of the swap;
The amount paid to Party A is USD 55,911.60.

<principalExchangeFeatures>
  <principalExchanges>
    <initialExchange>true</initialExchange>
    <finalExchange>false</finalExchange>
    <intermediateExchange>false</intermediateExchange>
  </principalExchanges>
  <principalExchangeDescriptions>
    <payerPartyReference href="PartyB"/>
    <receiverPartyReference href="PartyA"/>
    <principalExchangeAmount>
      <principalAmount>
        <currency>USD</currency>
        <amount>55911.60</amount>
      </principalAmount>
    </principalExchangeAmount>
    <principalExchangeDate>
      <relativeDate>
        <periodMultiplier>0</periodMultiplier>
        <period>D</period>
        <businessDayConvention>NotApplicable</businessDayConvention>
        <dateRelativeTo href="EffectiveDate"/>
      </relativeDate>
    </principalExchangeDate>
  </principalExchangeDescriptions>
</principalExchangeFeatures>

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

Figure 31: The additionalPayment component.

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

The payer and receiver parties are specified similarly to the swap legs and the principal exchange, through the payerPartyReference and receiverPartyReference elements;
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.10 The optional early termination

The purpose of the equitySwapEarlyTermination 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 30 below presents the structure of this component:

Figure 32: The earlyTermination component.

Similarly to the other date-related components that are part of the equity 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.

Example 22 - Each of the parties have the right to early terminate the trade starting on Trade Date:

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