DerivSERV Technical Specification - Equity Derivatives v6.0 Revision 4

DTCC Deriv/SERV User Technical Specifications

Equity Derivatives

Version 6.0 Revision 4

Published Oct 23, 2009 Last Updated Oct 23, 2009

CONFIDENTIAL AND PROPRIETARY All rights reserved

Copyright © 2003-2009 The Depository Trust & Clearing Corporation

By receipt and review of these materials, the recipient acknowledges and agrees that these materials are and shall remain, and be treated and maintained by any recipient, as confidential and as such may not be disclosed. Further, the recipient agrees that all copyright and other intellectual property rights in or relating to these materials are and shall remain the property of DTCC.

About this document

This document is intended to provide users with the information required to use the DTCC Deriv/SERV system through the computer-to-computer interface.

The latest version of this document is available in the Participants Section of the DTCC Deriv/SERV website at the following URL: http://derivserv.dtcc.com

For information regarding the DTCC Deriv/SERV web application, refer to the “DTCC Deriv/SERV Web User Guide.”

The legal obligations of users are not addressed in this document but are set forth in the most recently published “DTCC Deriv/SERV Operating Procedures For Automated Confirmation and Matching System” (the “Operating Procedures”). This document is considered an “Applicable Publication” as described in the Operating Procedures.

http://derivserv.dtcc.com/

Revision History Date Version Description

3/31/05 2.0 revision 0 Initial Publish for Version 2.0

Added new Equity Swap and Variance Swap products.

Added Japanese Master and Independent Amount for Equity Options

4/14/05 2.0 revision 1 Value “D” will be valid for Designated Maturity

Mutual Early Termination Right will always be applicable unless specified as Not Applicable in the record.

Initial Price will contain up to seven decimal places for both Equity Swap and Variance Swap.

Variance Amount will contain up to five decimal places.

The ExpectedN field will always be required for a Variance Swap

7/6/05 2.0 revision 2 Day Count Fraction value ACT/365.ISDA corrected to ACT/ACT.ISDA

Observation Start Date for Variance Swap – element structure change in FpML

Buyer and Seller elements will not be used for Equity Swap. Only Equity Payer and Floating Payer are used. This removes two unnecessary message-only fields that were originally required by FpML.

Additional permitted values for Dividend Payment Date of an Equity Swap. These are "CumulativeEquityPaid", "CumulativeLiborPaid", "CumulativeEquityExDiv", and "CumulativeLiborExDiv"

8/31/05 2.0 revision 3 Equity Swap "Dividend Amount" is now Conditionally Optional instead of Conditionally Required.

10/7/05 2.0 revision 4 Variance Swap Cash Settlement Payment Date is now optional instead of required.

12/15/05 2.0 revision 5 Added Independent Amount Percentage for Equity Options. See revised sections 2.1.1 and 7.2.6.

2/8/2006 2.0 Revision 6 Variance Swap changes: Observation Start Date will default to trade date when omitted. Variance Cap field will contain the computed variance cap (not the un-squared factor), and there will be no tolerance for this field.

11/8/2006 2.0 Revision 7 Added Partial Termination Independent Amount fields to Equity Options and Equity Swaps. (See section 7.6.2.2) Added 15A-6 Rule field to Equity Options. (See section 7.1 and 7.6.1)

12/27/2007 3.0 Added AEJ Options (see sections 7.2.2 and 7.2.7) and Swaps (see sections 7.3.2, 7.3.3, 7.3.5, 7.3.5.1, 7.3.7 and 7.3.12) Added Japan Variance Swaps (see section 7.4.8). Added Workflow fields (Comment and Super ID only). On Variance Swaps, Reduce the number of decimal places

allowed for Initial Level and Variance Amount to 2 decimal places. Also, Reduce the number of decimal places allowed for Variance Strike Price and Variance Cap to 4 decimal places (see section 7.4.61)

1/15/2007 3.0 On Equity Swaps, Dividend Period, Dividend Amount, Dividend Percentage, and Dividend Payment Date fields are not allowed when Master Confirmation Type is ISDA2005EquityAEJInterdealer. (See sections 7.3.4 and 7.3.7) The Equity Additional Fields element has been modified and it will contain Seller Contact Info and Local Jurisdiction (see sections 7.1.1, 7.2.2 and 7.3.2)

1/26/2007 3.0 Added Appendix A which contains a mapping from the Spreadsheet Upload fields to the relevant FpML section in this document. (see section 8)

2/5/2007 3.0 Seller Contact fields were removed from AEJ Equity Options and Swaps.

2/12/2007 3.0 The Master Confirmation Type, “ISDA2005EquityAEJInterdealer", on Equity Options and Swaps was changed to “ISDA2005EquityAsiaExcludingJapanInterdealer” The Master Confirmation Type, “ISDA2006EquityJapaneseInterdealer”, on Variance Swaps was changed to “ISDA2006VarianceSwapJapaneseInterdealer”

3/13/2007 3.0 On Equity Options, the Related Exchange element is optional for the ISDA2005EquityJapaneseInterdealer Master Confirmation Transaction Type (MCA). (see section 7.2.3.1 and 7.2.3.2)

3/20/2007 3.0 Added labels to the schema diagram that note if an element is required. The Labels may also contain a number that maps to the spreadsheet reference number column (see section 7). See Appendix A for a list of the spreadsheet fields.

3/31/2007 3.1 On Equity Swaps, a user may document the share/index price, number of units and currency on Terminations and Increase. See section 7.6.1.2 On Equity Swaps, a user may enter the business day convention for the floating rate payment dates. See section 7.3.9.1. On Equity Swaps, Business Centers are optional when Payment Dates are relative dates. See section 7.3.9.1 On Equity Options and Equity Swaps, added "EquityAsia" as valid Master Confirmation Transaction Type (MCA).

5/15/2007 4.0 *See the ReadMeFirst_Equity_4.0.doc in the ZIP file for a detailed list of all the changes. 1) Added support for Reference Price Source and the ISDA2007EquityEuropean MCA to Equity Options.

2) Added additional Fields to Equity Swaps 3) Added support for the following MCAs on Variance Swaps "ISDA2007VarianceSwapAsiaExcludingJapan" or "ISDA2007VarianceSwapEuropean" or "EquityAsia" 4) Added support for a user to receive an MQ message upon manually breaking a confirmed transaction.

9/17/2007 4.0 Revision 1 1) Added support for Dividend Swaps 2) Changed the DTCC schemas, adding support for dividend swap product types, and renamed the OTC schemas in accordance with standard naming conventions.

1/31/2008 4.0 Revision 2 1) Added support to making the Floating Rate Interest Leg on Equity Swaps as Optional 2) Added support to modify the Settlement Type field for Physically Settled Options 3) Added support for 2006 ISDA Definitions for Equity Swaps

3/05/2008 4.0 Revision 3 1) Added support to include a new master confirmation type: European Equity Finance Swap. 2) Added support to include contractualTermSupplements (Candian Supplement, Full Lookthrough and Partial Lookthrough). 3) Added support to include Prime Broker Billing (workflow fields) in all equity messages.

06/05/2008 5.0 1) Added Multiple Exchanges for Exchange ID field on all index trades. 2) Added Multiple Exchanges for the Related Exchange ID field on all equity trades. 3) For physically settled options, the Settlement Type field should not be populated 4) On Equity Options, “EquityAmericas” and “EquityEuropean” added as MCA types 5) Removing support for Options Price Valuation on certain MCAs 6) Added the ISDA 2008 Americas Master Designated/Exchange-Traded contract option confirmation agreement 7) Added the ISDA 2008 Equity Finance Swap Asia Excluding Japan MCA 8) Replaced Versioned Scheme URIs with Canonical Scheme URIs.

06/12/2008 5.0 Revision 1 Changed FX Rate conditionality to optional when Master Confirmation Transaction Type is "ISDA2005EquityAsiaExcludingJapanInterdealer".

08/19/2008 5.0 Revision 2 Added support to represent Valuation Dates in periodic dates. (First Valuation Date, Last Valuation Date, Valuation Frequency) for Equity Index/Share Swap. Added support to represent Payment Dates (Floating) in periodic dates. (First Payment Date, Last Payment Date, Payment Frequency, Payment Roll Convention) for Equity Index/Share Swap. Added support to include a new master confirmation type: Japanese Dividend Swaps, Japanese Equity Option, Asia Excluding Japan Equity Option. Revised section 7.3.3.4 to clarify the inclusion of the dividendConditions and the dividendReinvestment elements on certain conditions and exclusion of the dividendConditions element on certain conditions.

11/13/2008 5.0 Revision 3 Revised section 7.3.4.2 to include Compounding Spread in Equity Index/Share Swap trades. Revised section 7.4.6.1 to expand Variance Cap to 11 whole numbers. Revised section 2.1.4 and 7.5.9 to support a new master confirmation type “EquityAmericas” for Dividend Swaps.

1/15/2009 5.0 Revision 4 Added section 2.1.5, 2.2.5, 7.6, 8.5 and Revised section 2.5 to include Equity Dispersion Variance Swaps.

2/5/2009 5.0 Revision 4 Added "ISDA2007VarianceSwapEuropean", "ISDA2007VarianceSwapAmerica” master confirmation type to Equity Dispersion Variance Swaps, Revised Section 2.1.5, 7.6.2, 7.6.8

3/23/2009 5.0 Revision 4 Clarified payerPartyReference as variance buyer and receiverPartyReference as variance seller in Section 7.6.3 Clarified the localJurisdiction and relevantJurisdiction elements are not allowed in Section 7.6.2.

2/15/1009 6.0 Revised Section 2.1.1, 7.2 to include Sub product type business rules for Equity Index Option (“Spread”, “Cliquet”). Revised Section 7.3.4.2 to include Sub product type business rules for Equity Swap (“BulletCompounding”) Revised Section 7.5.3 to clarify the inclusion of the declaredCashDividendPercentage and declaredCashEquivalentDividendPercentage elements. Revised Section 7.8.4 to clarify the numberOfOptions element is not allowed for Amendment on a Cliquet Option. Revised Section 7.5.6.to clarify the inclusion of

periodMultiplier element. 4/30/2009 6.0 Revised Section 7.6.7 to clarify the value of href attribute in

notionalAmountReference element, must be 'equityDispersionVariance".

5/19/2009 6.0 Revision 1 Added section 2.3.4 to support Partial Termination for Dividend Swaps. Added section 2.3.3 to support Partial Termination for Variance Swaps. Revised Section 2.1.1, 2.1.1.1, 7.2.2, 7.2.3.1, 7.2.4, 7.2.4.2, 7.2.4.4, 7.2.4.5, 7.2.8 to include new masterconfirmation type “ISDA2009EquityAmericas”. Revised section 7.2.4.4 to support Valuation (Averaging) Date Convention for Equity Index Option and Spread Revised section 7.3.3.1, 7.3.3.4 to make Dividend Period, Dividend Amount, Dividend Percentage and Dividend Payment Date applicable when Master Confirmation Agreement is of type “EquityAsia”. Revised Section 7.2.2 to clarify localJurisdication, 7.3.2 to clarify localJurisdication, 7.3.3.4 to clarify dividendReinvestment, 7.3.3.1 to clarify fxFeature can be included when master confirmation type is "ISDA2005EquityAsiaExcludingJapanInterdealerRev2" Revised Section 7.2.3.2 to clarify RelatedExchangeId, 7.2.5.3 to clarify Settlement Type, 7.2.2 to clarify optionEntitlement can be included for two new master confirmation types and revised sections 2.1.2, 2.1.2.1, and 7.3.7 to add two new revised master confirmations types . Revised Section 7.2.2 to clarify multipleExchangeIndexAnnexFallback, strikePercentage can be included for new master confirmation type is (ISDA2008EquityOptionAsiaExcludingJapanRev1). Revised Section 7.3.3.2.3 to clarify Cash Settlement Payment Date is optional for certain MCAs. Revised Sections 7.3.3.1.1 to clarify relatedExchangeId, 7.3.4.1.1 to clarify business Centers, 7.3.3.1 to clarify dividendPayout, 7.3.3.4 to clarify dividendPaymentDate and determinationMethod, 7.3.2 to clarify mutualEarlyTermination applicable for ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1 master confirmation type. Revised Section 7.3.3.2 to clarify Initial Price Currency, 7.3.3.2.2 to clarify futurePriceValuation, 7.3.5 to clarify Fully Funded can be included for

ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1 or ISDA2008EquityFinanceSwapAsiaExcludingJapan master confirmation types. Revised Sections 2.1.3,7.4.8 to add new revised master confirmation type ISDA2007VarianceSwapAsiaExcludingJapanRev1. Revised Sections 7.4.4.1 to clarify relatedExchangeId, 7.4.6.1 to clarify expectedN, exchangeTradedContractNearest, expiringLevel, referenceCurrency, 7.4.6 to clarify allDividends, 7.4.2 to clarify localJurisdiction, 7.4.2 to clarify multipleExchangeIndexAnnexFallback are applicable to the new revised master confirmation type (ISDA2007VarianceSwapAsiaExcludingJapanRev1). Revised Sections 7.4.6 to Clarify optionsExchangeDividends not applicable to ISDA2007VarianceSwapAsiaExcludingJapanRev1. Revised section 7.2.2, 7.3.2, 7.4.2 to include "China”,”Pakistan”,”Vietnam”,”Afghanistan”,”Hong Kong”,”Japan”,Singapore”,”Australia”,”New Zealand”,”Philippines“ and "NotApplicable" as possible values. Revised Sections 2.1.2, 2.1.2.1, 7.3.7 to add ISDA2004EquityAmericasInterdealer master confirmation type. Revised Section 7.3.7 to clarify contractualTermSupplement is applicable to ISDA2004EquityAmericasInterdealer. Revised Section 7.3.4.1.1 to clarify Interest Leg Payment Dates is optional.

05/28/2009 6.0 Revision 1 Revised Section 2.9 to clarify Amendment transaction type is not allowed while Backloading transactions.

07/06/2009 6.0 Revision 1 Revised Sections 2.1.3, 7.4.6.1 to reflect master confirmation type ISDA2007VarianceSwapAsiaExcludingJapanRev as ISDA2007VarianceSwapAsiaExcludingJapanRev1.

07/10/2009 6.0 Revision 1 Revised Sections 2.1.2, 2.1.2.1, 7.3.3.1, 7.3.3.4 to reflect changes in Dividend Fields for Master Confirmation Type ‘Equity Asia’.

07/22/2009 6.0 Revision 1 (Errata #1)

Revised section 7.2.4 to clarify numberOfvaluationDates is not allowed inside of equityExercise. Revised section 7.2.4.4 to clarify numberOfvaluationDates is allowed for Cliquet Options inside of equityValuation element. Revised section 7.3.3.1, 7.3.3.4 to inclusion of Dividend Period, Dividend Amount, Dividend Percentage and Dividend Payment Date elements is optional when Master Confirmation type is “EquityAsia”.

8/20/2009 6.0 Revision 2 Added section 2.1.1.3, 7.2.5.3 to include sub product type business rules for Equity Swap ("Barrier"). Added section 2.1.6, 2.2.6, 2.3.5, 2.4.3, 7.7 and revised section 1, 2.1, 2.3, 7.9.2, 7.9.2.2, 7.9.3 to include support for Equity Share Variance Option and Equity Index Variance Option. Revised section 2.1.2, 2.1.2.1, 7.3.2, 7.3.3, 7.3.3.1, 7.3.3.2, 7.3.3.5, 7.3.4.2, 7.3.7 and added 7.3.3.5 to support “ISDA2009EquityAmericas”, “ISDA2009EquityEuropean” as new Master Confirm types. Updated section 7.4.6 to support the Observation Day frequency representation for Variance Swaps. Revised Sections 2.1.6, 7.7.11 to clarify "EquityAmerias" master confirmation type is applicable to variance option. Revised Section 7.3.3.5 to clarify Averaging Dates is applicable to "ISDA2004EquityAmericasInterdealer" master confirmation type. Revised Section 7.2.4.4 to clarify Valuation (Averaging) Date Convention is applicable to share option. Revised section 8.7 Appendix b with two new non ISDA Floating Rate Option supported by Deriv/SERV.

09/25/2009 6.0 Revision 1 (Errata #2)

Updated section 7.4.3 to indicate futuresPriceValuation is an optional element for ISDA2007EquityEuropean.

09/25/2009 6.0 Revision 3 Revised sections 2.1.2, 7.1.1, 7.3.2, 7.3.3.1, 7.3.3.1.2, 7.3.3.2, 7.3.3.2.3, 7.3.4.1.1, 7.3.4.2, 7.3.5, 7.3.7, 7.9.1.2 and 7.9.2 to support “GlobalMCA” for Share Swap and Index Swaps. Added section 7.1.1.1 to describe the Final Fee element applicable for “GlobalMCA”

10/01/2009 6.0 Revision 4 Revised sections 8.1, 8.2, 8.3, 8.4, 8.5 and 8.6 to reference correct section mapping for field names. Revised Sections 2.1.2 to include new fields to support “Global MCA”, “ISDA2009EquityEuropean” “ISDA2007EquityEuropean”. "ISDA2009EquityInterdealerPanAsia" “ISDA2009EquityAmericas”, “EquityAsia”, “EquityEuropean” and “EquityAmericas”. Revised section 7.3 to include new elements to support “Global MCA”, “ISDA2009EquityEuropean” “ISDA2007EquityEuropean”. "ISDA2009EquityInterdealerPanAsia" “ISDA2009EquityAmericas”, “EquityAsia”, “EquityEuropean” and “EquityAmericas”.

TABLE OF CONTENTS

1 OVERVIEW .................................................................................................................... 13

2 MESSAGE PROCESSING ............................................................................................ 14

2.1 New Trade ................................................................................................................. 14 2.1.1 New Trade – Equity Option ........................................................................... 15 2.1.2 New Trade – Equity Swap ............................................................................. 25 2.1.3 New Trade – Equity Variance Swap .............................................................. 38 2.1.4 New Trade – Dividend Swap ......................................................................... 40 2.1.5 New Trade – Equity Dispersion Variance ...................................................... 42 2.1.6 New Trade – Equity Variance Option ............................................................ 44

2.2 Full Termination ......................................................................................................... 46 2.2.1 Full Termination - Equity Option .................................................................... 46 2.2.2 Full Termination – Equity Swap ..................................................................... 47 2.2.3 Full Termination – Equity Variance Swap ...................................................... 47 2.2.4 Full Termination – Dividend Swap ................................................................. 47 2.2.5 Full Termination – Equity Dispersion Variance .............................................. 48 2.2.6 Full Termination – Equity Variance Option .................................................... 48

2.3 Partial Termination .................................................................................................... 49 2.3.1 Partial Termination - Equity Option ................................................................ 49 2.3.2 Partial Termination – Equity Swap ................................................................ 50 2.3.3 Partial Termination – Equity Variance Swap ................................................. 50 2.3.4 Partial Termination – Equity Dividend Swap ................................................. 50 2.3.5 Partial Termination – Equity Variance Option ................................................ 51

2.4 Increase ..................................................................................................................... 52 2.4.1 Increase - Equity Option ................................................................................ 52 2.4.2 Increase – Equity Swap ................................................................................. 53 2.4.3 Increase – Equity Variance Option ................................................................ 53

2.5 Amendment of a Confirmed Trade ............................................................................ 54

2.6 Assignment ................................................................................................................ 54

2.7 Exit From DTCC ........................................................................................................ 54

2.8 Workflow Fields ......................................................................................................... 55

2.9 Backload .................................................................................................................... 56

3 TRANSACTION LIFE CYCLE ....................................................................................... 57

4 VALIDATION CRITERIA ............................................................................................... 57

5 COMMUNICATION - DATA TRANSMISSION .............................................................. 57

6 HOURS OF OPERATION .............................................................................................. 57

7 SCHEMA DIAGRAMS AND RULES ............................................................................. 58

7.1 Trade ......................................................................................................................... 60 7.1.1 EquityAdditionalFields ................................................................................... 61

7.2 FpML - Equity Option ................................................................................................ 67 7.2.1 FpML Trade Datatype .................................................................................... 68 7.2.2 FpML equityOptionTransactionSupplement Element .................................... 69 7.2.3 FpML underlyer Element ............................................................................... 72 7.2.4 FpML equityExercise Element ....................................................................... 76 7.2.5 FpML feature Element ................................................................................... 87 7.2.6 FpML equityPremium Element ...................................................................... 96 7.2.7 FpML collateral Element ................................................................................ 98 7.2.8 FpML documentation Element ..................................................................... 100

7.3 FpML - Equity Swap ............................................................................................... 102 7.3.1 FpML Trade Datatype .................................................................................. 103 7.3.2 FpML equitySwapTransactionSupplement Element .................................... 104 7.3.3 FpML returnLeg Element ............................................................................. 106 7.3.4 FpML interestLeg Element .......................................................................... 130 7.3.5 FpML principalExchangeFeatures Element ................................................. 139 7.3.6 FpML collateral Element .............................................................................. 140 7.3.7 FpML documentation Element ..................................................................... 142

7.4 FpML - Equity Variance Swap ................................................................................. 145 7.4.1 FpML Trade Datatype .................................................................................. 146 7.4.2 FpML equitySwapTransactionSupplement Element .................................... 147 7.4.3 FpML varianceLeg Element ......................................................................... 148 7.4.4 FpML underlyer Element ............................................................................. 149 7.4.5 FpML equityValuation Element .................................................................... 152 7.4.6 FpML equityAmount Element ...................................................................... 154 7.4.7 FpML collateral Element .............................................................................. 160 7.4.8 FpML documentation Element ..................................................................... 162

7.5 FpML - Dividend Swap ............................................................................................ 164 7.5.1 FpML Trade Datatype .................................................................................. 164 7.5.2 FpML dividendSwapTransactionSupplement Element ................................ 165 7.5.3 FpML dividendLeg element ......................................................................... 166 7.5.4 FpML dividendPeriod ................................................................................... 168 7.5.5 FpML fixedLeg element ............................................................................... 170 7.5.6 FpML fixedPayment element ....................................................................... 171 7.5.7 FpML underlyer Element ............................................................................. 172 7.5.8 FpML collateral Element .............................................................................. 175 7.5.9 FpML documentation Element ..................................................................... 176

7.6 FpML - Equity Dispersion Variance Swap ............................................................... 178 7.6.1 FpML Trade Datatype .................................................................................. 179 7.6.2 FpML varianceSwapTransactionSupplement Element ................................ 180 7.6.3 FpML varianceLeg Element ......................................................................... 181

7.6.4 FpML underlyer Element ............................................................................. 182 7.6.5 FpML valuation Element .............................................................................. 185 7.6.6 FpML amount Element ................................................................................ 186 7.6.7 FpML collateral Element .............................................................................. 190 7.6.8 FpML documentation Element ..................................................................... 191

7.7 FpML – Equity Variance Option .............................................................................. 193 7.7.1 FpML Trade Datatype .................................................................................. 194 7.7.2 FpML varianceOptionTransactionSupplement Element .............................. 195 7.7.3 FpML equityExercise Element ..................................................................... 196 7.7.4 FpML equityPremium Element .................................................................... 199 7.7.5 FpML varianceSwapTransactionSupplement Element ................................ 201 7.7.6 FpML varianceLeg Element ......................................................................... 202 7.7.7 FpML underlyer Element ............................................................................. 203 7.7.8 FpML valuation Element .............................................................................. 206 7.7.9 FpML amount Element ................................................................................ 208 7.7.10 FpML collateral Element .............................................................................. 212 7.7.11 FpML documentation Element ..................................................................... 213

7.8 Exit Element ............................................................................................................ 215

7.9 PostTrade ................................................................................................................ 216 7.9.1 PostTrade Element ...................................................................................... 217 7.9.2 Termination Element ................................................................................... 222 7.9.3 Increase Element ......................................................................................... 228 7.9.4 Amendment Element ................................................................................... 232

7.10 Error ........................................................................................................................ 233

7.11 Workflow Fields ....................................................................................................... 234 7.11.1 Default Values ............................................................................................. 235

7.12 Schemas & Sample Messages ............................................................................... 238

8 APPENDIX A – SPREADSHEET TO FPML MAPPING ............................................. 239

8.1 Equity Options Field Mappings ................................................................................ 239

8.2 Equity Swaps Field Mapping Mappings .................................................................. 242

8.3 Equity Variance Swaps Mappings ........................................................................... 246

8.4 Equity Dividend Swaps Mappings ........................................................................... 248

8.5 Equity Dispersion Variance Mappings ..................................................................... 250

8.6 Equity Variance Options Field Mappings ................................................................ 252

8.7 Appendix B: Non ISDA Floating Rate Option supported by DTCC DerivSERV : .... 254

DTCC Deriv/SERV User Technical Specifications - Equity Derivatives v 6.0 Rev 4 13

1 Overview

The Depository Trust & Clearing Corporation (DTCC) has been working with a group of major dealers in OTC derivatives to create an automated trade confirmation and matching system. Participating major dealers have formed an OTC Derivatives Steering Committee to provide policy direction, and an OTC Derivatives Operations and Technology Committee to provide more detailed operational and technology direction. Building on the work of ISDA in both documentation and FpML, the committees and DTCC have created an OTC derivatives trade confirmation solution which not only addresses immediate processing issues, but also provides the platform for additional functionality supporting any future processing initiatives the OTC derivatives industry may wish to undertake. This document describes the business and technical rules necessary to construct Deriv/SERV messages for the following OTC Derivative product types:

Equity Share Option Equity Index Option Equity Share Swap Equity Index Swap Equity Share Variance Swap Equity Index Variance Swap Equity Share Dividend Swap Equity Index Dividend Swap Equity Share Dispersion Variance Swap Equity Index Dispersion Variance Swap Equity Share Variance Option Equity Index Variance Option

This document does not stand-alone. It must be used in conjunction with the overall messaging architecture for the Deriv/SERV product found in the “Deriv/SERV User Technical Specifications – Messaging Architecture” document. Except as noted herein for Equity Derivative specific rules, the rules found in the Messaging Architecture document apply for Equity Derivative messages.


2 Message Processing The DTCC Deriv/SERV system supports input of the following transaction types:

New Trade (All Equity products) Full Termination (All Equity products) Partial Termination (Equity Option, Equity Swap and Dividend Swap only; not Variance Swap, Equity Dispersion Variance Swaps) Increase (Equity Option, Equity Swap, Dividend Swap only; not Variance Swap, Equity Dispersion Variance Swap) Amendment (All Equity products) Exit from DTCC. (All Equity products)

Please refer to the “Deriv/SERV User Technical Specifications – Message Architecture” document for business rules and technical rules for each transaction type. The following sections describe the business processing rules specific to Equity Derivatives for these transaction types and specify the information included in these transactions and are in addition to the rules specified in the “Message Architecture” documents.

2.1 New Trade The New Trade transaction record specifies an input template of Product Type/Transaction Type, from a DTCC table of valid product types. The equity derivatives product types supported are:

EquityShareOption EquityIndexOption EquityShareSwap EquityIndexSwap EquityShareVarianceSwap EquityIndexVarianceSwap Equity Share Dividend Swap Equity Index Dividend Swap Equity Share Dispersion Variance Swap Equity Index Dispersion Variance Swap Equity Share Variance Option Equity Index Variance Option

In the DTCC Deriv/SERV system, Equity Derivative trade confirmations are matched using a Master Confirmation/Transaction Supplement approach. Under this approach, two firms execute a bilateral Master Confirmation agreement that fixes the values of many of the fields in the standard ISDA confirmation for all trades executed between the two firms under that agreement. The remaining deal information that changes from trade to trade is confirmed through a Transaction Supplement, which includes the information described below.

Refer to the following sub-sections for the specific fields that are relevant to each individual Equity product.


2.1.1 New Trade – Equity Option An Equity Option includes the following fields: The parties to the trade identify by date the Master Confirmation Agreement under which the trade has been executed. For Equity Option, the parties will specify whether Master Confirm Type is:

“ISDA2004EquityAmericasInterdealer” or “2004EquityEuropeanInterdealer” or

“ISDA2005EquityJapaneseInterdealer” or “ISDA2005EquityAsiaExcludingJapanInterdealer” or “EquityAsia” or "ISDA2007EquityEuropean" “EquityAmericas” “EquityEuropean” “ISDA2008EquityAmericas” "ISDA2008EquityOptionAsiaExcludingJapan" "ISDA2008EquityOptionJapan" “ISDA2009EquityAmericas” “ISDA2005EquityAsiaExcludingJapanInterdealerRev2” “ISDA2008EquityOptionAsiaExcludingJapanRev1”

For a Share Option, the Shares are identified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange for a Share Option will be specified by the RIC suffix, a code appended to the RIC, not as a separate field. The text is case sensitive. DTCC will not validate the submitted RICs. For an Index Option, the Index is specified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange will be specified using a REC identifier (Reuters Exchange Code), in a separate field, not as a suffix. The text is case sensitive. DTCC will not validate the submitted RICs and RECs. Listing multiple Exchanges is supported by specifying multiple constituent Exchange REC identifiers with a maximum allowable occurrence of 10 unique identifiers. The Related Exchange must also be specified. Valid values are any one of the REC identifiers for exchanges or the word “ALL” to denote All Exchanges. The text is case sensitive. Listing multiple Related Exchanges is also supported by specifying more than one identifier with a maximum allowable occurrence of 10 unique identifiers. If multiple Related Exchanges are specified, then the “ALL” value must not be used. The Trade Date, Premium Payment Date, and Expiration Date are expressed as actual dates (YYYY-MM-DD in the FpML messages). These date fields are validated by the DTCC system only for date format. The Option Style is represented in the Trade record as “American” or ”European” or “Bermuda” (note that this field is independent of Master Confirm Type). The Option Type is specified as “Call” or “Put.” The Submitter, Counterparty, Seller and the Buyer are identified using DTCC-assigned numbers. These identifiers will be stored in a table with full legal names of the firms, for display on the web application and other output.


The Number of Options, a required field, may be a number with up to five decimal places. For an American-style option, the submitter may optionally specify a Minimum Number of Options and an Integral Multiple when Multiple Exercise is applicable. The Strike Price for Index Options is expressed as a level for the index; for Share Options, it is a price per share. In both cases, up to seven decimal places may be used. For Share Options, the Strike Price Currency, expressed as an ISO currency code, is also required. The Premium is represented in the trade record as the aggregate premium (not per option) and may include up to two decimal places. Note: These decimal expressions will be evaluated by the matching system as numbers – that is, “5.5” would match “5.50”. The Premium Currency is specified using ISO currency codes. For an Index Option, the record may optionally specify whether Futures Price Valuation is “Applicable” or “Not Applicable”; if “Applicable” is specified, the record must include the Exchange Traded Contract, identified by month and year. Averaging Dates is a set of optional fields that contain a list of specific dates. For Index Options, the Settlement Method must be specified as “Cash”. For Share Options, the Settlement Method must be specified as “Physical”, “Cash”, or “Election”; if “Election” is specified, the Electing Party may be optionally specified as “Buyer” or “Seller”. When the Settlement Method has a value of “Physical”, then Settlement Type and Reference Currency will not be populated. When the Master Confirmation Type is “ISDA2008EquityAmericas” or “ISDA2009EquityAmericas” the Settlement Currency must be USD and Settlement Method must be “Physical”. The Settlement Date, optional for Index Option, is specified as a “lag” – that is, the submitter specifies a number of business days after the relevant valuation date. The Settlement Date is considered optional for a Share Option unless the Master Confirmation Type is either “ISDA2007EquityEuropean” or, "ISDA2008EquityAmericas" or “ISDA2009EquityAmericas”or when the Settlement Method has a value as “Physical”. In which case the Settlement Date is not allowed. A Settlement Currency must be specified as an ISO currency code. The Multiplier is not specified, as it is assumed to always be “1”. The optional Independent Amount (Initial Margin) may be expressed either as a currency amount or as a percentage, and includes the Independent Amount Payer. The DTCC matching system compares all fields with the exception of the internal comment, link Transaction id, 15A-6 rule, and trade reference numbers, which is uniquely assigned by each firm. Two Trade records to be considered matched, all information must correspond exactly, with the exception of the Premium, which will be matched with a tolerance of one currency unit. When a trade is confirmed where the parties have submitted premium amounts that differ by up to one currency unit, both parties will receive a confirmation record with the Buyer’s premium amount. Up to the point of confirmation, the different premium amounts will appear on the respective records and show as a difference on comparison screens.


For Share Option and Index Option, the Canadian Contractual Supplement may be used with “ISDAMarch2004EquityCanadianSupplement” master confirmation. For Share Option, the Partial Lookthrough and Full lookthrough Contractual Supplements may be used for any underlying master confirmation. Deriv/SERV transaction records may optionally include any or all of the “workflow fields” that are designed to support Prime Broker Billing and other workflow functions. These fields are all optional and nonmatching. Please See Section 2.8 for a detailed description of the “workflow fields.


2.1.1.1 New Trade – Equity Index Option (Spread) An Equity Index Option with “Spread” includes the following fields: The parties to the trade identify by date the Master Confirmation Agreement under which the trade has been executed. For Equity Index Option with Spread, the parties will specify whether Master Confirm Type is:


“ISDA2005EquityJapaneseInterdealer” or “ISDA2005EquityAsiaExcludingJapanInterdealer” or “EquityAsia” or "ISDA2007EquityEuropean" “EquityAmericas” “EquityEuropean” “ISDA2008EquityAmericas” "ISDA2008EquityOptionAsiaExcludingJapan" "ISDA2008EquityOptionJapan" “ISDA2009EquityAmericas” “ISDA2005EquityAsiaExcludingJapanInterdealerRev2” “ISDA2008EquityOptionAsiaExcludingJapanRev1”

For an Index Option, the Index is specified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange will be specified using a REC identifier (Reuters Exchange Code), in a separate field, not as a suffix. The text is case sensitive. DTCC will not validate the submitted RICs and RECs. Listing multiple Exchanges is supported by specifying multiple constituent Exchange REC identifiers with a maximum allowable occurrence of 10 unique identifiers. The Related Exchange must also be specified. Valid values are any one of the REC identifiers for exchanges or the word “ALL” to denote All Exchanges. The text is case sensitive. Listing multiple Related Exchances is also supported by specifying more than one identifier with a maximum allowable occurrence of 10 unique identifiers. If multiple Related Exchanges are specified, then the “ALL” value must not be used. The Trade Date and Expiration Date are expressed as actual dates (YYYY-MM-DD in the FpML messages). These date fields are validated by the DTCC system only for date format. The Option Style is represented in the Trade record as “American” or ”European” or “Bermuda” (note that this field is independent of Master Confirm Type). The Option Type is specified as “Call” or “Put.” The Submitter, Counterparty, Seller and the Buyer are identified using DTCC-assigned numbers. These identifiers will be stored in a table with full legal names of the firms, for display on the web application and other output. The Number of Options, a required field only when Notional Amount is not present otherwise optional, may be a number with up to five decimal places. For an American-style option, the submitter may optionally specify a Minimum Number of Options and an Integral Multiple when Multiple Exercise is applicable.


The Strike Price for Index Options is expressed as a level for the index; it can be up to seven decimal places. The Premium is represented in the trade record as the aggregate premium (not per option) and may include up to two decimal places. Note: These decimal expressions will be evaluated by the matching system as numbers – that is, “5.5” would match “5.50”. The Premium Currency is specified using ISO currency codes. The Premium Payment Date is optional when the master confirm type is "ISDA2007EquityEuropean”, otherwise it is required. For an Index Option, the record may optionally specify whether Futures Price Valuation is “Applicable” or “Not Applicable”; if “Applicable” is specified, the record must include the Exchange Traded Contract, identified by month and year. Averaging Dates is a set of optional fields that contain a list of specific dates. For Index Options on “Spread”, the Settlement Method must be specified as “Cash”. When the Settlement Method has a value of “Physical”, then Settlement Type and Reference Currency will not be populated. When the Master Confirmation Type is “ISDA2008EquityAmericas” or “ISDA2009EquityAmericas” the Settlement Currency must be USD and Settlement Method must be “Physical”. The Settlement Date, optional for Index Option on Spread, is specified as a “lag” – that is, the submitter specifies a number of business days after the relevant valuation date. A Settlement Currency must be specified as an ISO currency code. The Multiplier is not specified, as it is assumed to always be “1”. The optional Independent Amount (Initial Margin) may be expressed either as a currency amount or as a percentage, and includes the Independent Amount Payer. The DTCC matching system compares all fields with the exception of the internal comment, link Transaction id, 15A-6 rule, and trade reference numbers, which is uniquely assigned by each firm. Two Trade records to be considered matched; all information must correspond exactly, with the exception of the Premium, which will be matched with a tolerance of one currency unit. When a trade is confirmed where the parties have submitted premium amounts that differ by up to one currency unit, both parties will receive a confirmation record with the Buyer’s premium amount. Up to the point of confirmation, the different premium amounts will appear on the respective records and show as a difference on comparison screens. For Index Option with Spread, the Canadian Contractual Supplement may be used with “ISDAMarch2004EquityCanadianSupplement” master confirmation. Deriv/SERV transaction records may optionally include any or all of the “workflow fields” that are designed to support Prime Broker Billing and other workflow functions. These fields are all optional and nonmatching. Please See Section 2.8 for a detailed description of the “workflow fields.


2.1.1.2 New Trade – Equity Index Option (Cliquet) An Equity Index Option with Cliquet includes the following fields: The parties to the trade identify by date the Master Confirmation Agreement under which the trade has been executed. For Equity Index Option with Cliquet, the parties will specify whether Master Confirm Type is:

"CliquetAndRainbow" For an Index Option, the Index is specified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange will be specified using a REC identifier (Reuters Exchange Code), in a separate field, not as a suffix. The text is case sensitive. DTCC will not validate the submitted RICs and RECs. Listing multiple Exchanges is supported by specifying multiple constituent Exchange REC identifiers with a maximum allowable occurrence of 10 unique identifiers. The Related Exchange must also be specified. Valid values are any one of the REC identifiers for exchanges or the word “ALL” to denote All Exchanges. The text is case sensitive. Listing multiple Related Exchances is also supported by specifying more than one identifier with a maximum allowable occurrence of 10 unique identifiers. If multiple Related Exchanges are specified, then the “ALL” value must not be used. The Trade Date, Premium Payment Date, and Expiration Date are expressed as actual dates (YYYY-MM-DD in the FpML messages). These date fields are validated by the DTCC system only for date format. The Option Style is represented in the Trade record as “American” or ”European” (note that this field is independent of Master Confirm Type). The Option Type is specified as “Call”. The Submitter, Counterparty, Seller and the Buyer are identified using DTCC-assigned numbers. These identifiers will be stored in a table with full legal names of the firms, for display on the web application and other output. The Number of Options, is not allowed for an Index Option with ‘Cliquet”. The Strike Price for Index Options is expressed as a level for the index; it can be up to seven decimal places may be used. The Premium is represented in the trade record as the aggregate premium (not per option) and may include up to two decimal places. Note: These decimal expressions will be evaluated by the matching system as numbers – that is, “5.5” would match “5.50”. The Premium Currency is specified using ISO currency codes. For an Index Option, the record may optionally specify whether Futures Price Valuation is “Applicable” or “Not Applicable”; if “Applicable” is specified, the record must include the Exchange Traded Contract, identified by month and year. Averaging Dates is a set of optional fields that contain a list of specific dates. For Index Options, the Settlement Method must be specified as “Cash”. When the Settlement Method has a value of “Physical”, then Settlement Type and Reference Currency will not be populated.


The Settlement Date, optional for Index Option, is specified as a “lag” – that is, the submitter specifies a number of business days after the relevant valuation date. A Settlement Currency must be specified as an ISO currency code. The Multiplier is not specified, as it is assumed to always be “1”. The optional Independent Amount (Initial Margin) may be expressed either as a currency amount or as a percentage, and includes the Independent Amount Payer. The DTCC matching system compares all fields with the exception of the internal comment, link Transaction id, 15A-6 rule, and trade reference numbers, which is uniquely assigned by each firm. Two Trade records to be considered matched, all information must correspond exactly, with the exception of the Premium, which will be matched with a tolerance of one currency unit. When a trade is confirmed where the parties have submitted premium amounts that differ by up to one currency unit, both parties will receive a confirmation record with the Buyer’s premium amount. Up to the point of confirmation, the different premium amounts will appear on the respective records and show as a difference on comparison screens. Deriv/SERV transaction records may optionally include any or all of the “workflow fields” that are designed to support Prime Broker Billing and other workflow functions. These fields are all optional and nonmatching. Please See Section 2.8 for a detailed description of the “workflow fields.


2.1.1.3 New Trade – Equity Option (Barrier) An Equity Option with Barrier includes the following fields: The parties to the trade identify by date the Master Confirmation Agreement under which the trade has been executed. For Equity Option, the parties will specify whether Master Confirm Type is:


“ISDA2005EquityJapaneseInterdealer” or “ISDA2005EquityAsiaExcludingJapanInterdealer” or “EquityAsia” or "ISDA2007EquityEuropean" “EquityAmericas” “EquityEuropean” “ISDA2008EquityAmericas” "ISDA2008EquityOptionAsiaExcludingJapan" "ISDA2008EquityOptionJapan" “ISDA2009EquityAmericas”

For a Share Option, the Shares are identified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange for a Share Option will be specified by the RIC suffix, a code appended to the RIC, not as a separate field. The text is case sensitive. DTCC will not validate the submitted RICs. For an Index Option, the Index is specified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange will be specified using a REC identifier (Reuters Exchange Code), in a separate field, not as a suffix. The text is case sensitive. DTCC will not validate the submitted RICs and RECs. Listing multiple Exchanges is supported by specifying multiple constituent Exchange REC identifiers with a maximum allowable occurrence of 10 unique identifiers. The Related Exchange must also be specified. Valid values are any one of the REC identifiers for exchanges or the word “ALL” to denote All Exchanges. The text is case sensitive. Listing multiple Related Exchances is also supported by specifying more than one identifier with a maximum allowable occurrence of 10 unique identifiers. If multiple Related Exchanges are specified, then the “ALL” value must not be used. The Trade Date, Premium Payment Date, and Expiration Date are expressed as actual dates (YYYY-MM-DD in the FpML messages). These date fields are validated by the DTCC system only for date format. The Option Style is represented in the Trade record as “American” or ”European. “Bermuda” Option Style is not allowed for a Barrier Option (note that this field is independent of Master Confirm Type). The Option Type is specified as “Call” or “Put.” The Submitter, Counterparty, Seller and the Buyer are identified using DTCC-assigned numbers. These identifiers will be stored in a table with full legal names of the firms, for display on the web application and other output. Potential Exercise Dates is not allowed. The Number of Options, a required field, may be a number with up to five decimal places. For an American-style option, the submitter may optionally specify a Minimum Number of Options and an Integral Multiple when Multiple Exercise is applicable.


The Strike Price for Index Options is expressed as a level for the index; for Share Options, it is a price per share. In both cases, up to seven decimal places may be used. For Share Options, the Strike Price Currency, expressed as an ISO currency code, is also required. The Premium is represented in the trade record as the aggregate premium (not per option) and may include up to two decimal places. Note: These decimal expressions will be evaluated by the matching system as numbers – that is, “5.5” would match “5.50”. The Premium Currency is specified using ISO currency codes. For an Index Option, the record may optionally specify whether Futures Price Valuation is “Applicable” or “Not Applicable”; if “Applicable” is specified, the record must include the Exchange Traded Contract, identified by month and year. Averaging Dates is a set of optional fields that contain a list of specific dates. For Index Options, the Settlement Method must be specified as “Cash”. For Share Options, the Settlement Method must be specified as “Physical”, “Cash”, or “Election”; if “Election” is specified, the Electing Party may be optionally specified as “Buyer” or “Seller”. When the Settlement Method has a value of “Physical”, then Settlement Type and Reference Currency will not be populated. When the Master Confirmation Type is “ISDA2008EquityAmericas” the Settlement Currency must be USD and Settlement Method must be “Physical”. The Settlement Date, optional for Index Option, is specified as a “lag” – that is, the submitter specifies a number of business days after the relevant valuation date. The Settlement Date is considered optional for a Share Option unless the Master Confirmation Type is either “ISDA2007EquityEuropean” or, "ISDA2008EquityAmericas" or when the Settlement Method has a value as “Physical”. In which case, the Settlement Date is not allowed. A Settlement Currency must be specified as an ISO currency code. The Multiplier is not specified, as it is assumed to always be “1”. The optional Independent Amount (Initial Margin) may be expressed either as a currency amount or as a percentage, and includes the Independent Amount Payer. For Barrier Option, the record must specify either Knock-in Event or Knock-out Event along with the event condition and triggering level. The Knock-in or Knock-out elements must include the determination days in frequency, triggering type along with valuation time type. Allowable values for Knock-in/Knock-out valuation time are “Closing”, ”Anytime”. The DTCC matching system compares all fields with the exception of the internal comment, link Transaction id, 15A-6 rule, and trade reference numbers, which is uniquely assigned by each firm. Two Trade records to be considered matched, all information must correspond exactly, with the exception of the Premium, which will be matched with a tolerance of one currency unit. When a trade is confirmed where the parties have submitted premium amounts that differ by up to one currency unit, both parties will receive a confirmation record with the Buyer’s premium amount. Up to the point of confirmation, the


different premium amounts will appear on the respective records and show as a difference on comparison screens. For Share Option and Index Option, the Canadian Contractual Supplement may be used with “ISDAMarch2004EquityCanadianSupplement”. For Share Option, the Partial Lookthrough and Full lookthrough Contractual Supplements may be used for any underlying master confirmation. Deriv/SERV transaction records may optionally include any or all of the “workflow fields” that are designed to support Prime Broker Billing and other workflow functions. These fields are all optional and nonmatching. Please See Section 2.8 for a detailed description of the “workflow fields.


2.1.2 New Trade – Equity Swap An Equity Swap contains the following fields: The parties to the trade identify by date the Master Confirmation Agreement under which the trade has been executed. For Equity Swap, the parties will specify whether Master Confirm Type is:

“EquityAmericas” or “EquityEuropean” or "ISDA2005EquityAsiaExcludingJapanInterdealer” or “EquityAsia” “ISDA2007EquityFinanceSwapEuropean” “ISDA2008EquityFinanceSwapAsiaExcludingJapan” “ISDA2005EquityAsiaExcludingJapanInterdealerRev2” “ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1” “ISDA2004EquityAmericasInterdealer” “ISDA2009EquityAmericas” “ISDA2009EquityEuropean” “GlobalMCA” "ISDA2009EquityInterdealerPanAsia" "ISDA2007EquityEuropean"

The MCA types "ISDA2007EquityFinanceSwapEuropean” and "ISDA2008EquityFinanceSwapAsiaExcludingJapan" and "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" and "ISDA2009EquityInterdealerPanAsia" are applicable only to Share swaps and not for Index swaps. The MCA Type "ISDA2007EquityEuropean" is applicable only for Index swaps and not for Share swaps. "GlobalMCA" MCA Type is not applicable to the BulletCompounding Subproduct. For a Share Swap, the Shares are identified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange for a Share Swap will be specified by the RIC suffix, a code appended to the RIC, not as a separate field. The text is case sensitive. DTCC will not validate the submitted RICs. For an Index Swap, the Index is specified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange will be specified using a REC identifier (Reuters Exchange Code), in a separate field, not as a suffix. The text is case sensitive. DTCC will not validate the submitted RICs and RECs. Listing multiple Exchanges is supported by specifying multiple constituent Exchange REC identifiers with a maximum allowable occurrence of 10 unique identifiers. The Exchange ID is optional when the MCA Type is “GlobalMCA” or “ISDA2009EquityAmericas”; otherwise Exchange ID is required for all other MCA Types for Index swap. The Related Exchange must also be specified but it is considered optional when the Master Confirmation Type is “ISDA2008EquityFinanceSwapAsiaExcludingJapan”, "ISDA2007EquityFinanceSwapEuropean", "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1", "GlobalMCA" or "ISDA2009EquityInterdealerPanAsia" for a Share Swap. For Index swaps, Related Exchange ID must be specified but it is considered optional when the Master Confirmation Type is "GlobalMCA" or "ISDA2009EquityAmericas". Valid values are any one of the REC identifiers for or the word “ALL” to denote All Exchanges. The text is case sensitive. Listing multiple Related Exchances is also supported by specifying more than one identifier with a maximum allowable occurrence of 10 unique identifiers. If


multiple Related Exchanges are specified, then the “ALL” value must not be used. Related Exchange is optional for Master Confirmation Type of “GlobalMCA” for both Share and Index Swaps. The Average Daily Trading Volume (ADTV) Limit Percentage and Average Daily Trading Volume (ADTV) Limit Period can be specified (optional element) to the underlyer for Share swap when the master confirmation type is “ISDA2009EquityAmericas” or "EquityAmericas", otherwise the fields are NOT allowed. The ADTV Limit Percentage and ADTV Limit Period fields are not allowed for Index swap. In addition the underlyer can represent whether the Depository Receipt is Applicable or Not Applicable (optional) when the master confirmation type is “ISDA2009EquityAmericas” (applicable only for Share swaps and not allowed for Index swaps). The Trade Date and Effective Date are expressed as actual dates (YYYY-MM-DD in the FpML messages). These date fields are validated by the DTCC system only for date format. The Submitter, Counterparty, Equity Amount Payer and Floating Amount Payer are identified using DTCC-assigned numbers. These identifiers will be stored in a table with full legal names of the firms, for display on the web application and other output. The Floating Amount Payer is required for Master Confirmation Type of “GlobalMCA”. The Floating Amount Payer is optional when the MCA Type is “EquityAmericas”, “EquityEuropean” or "EquityAsia". When either Fully Funded has a value of "Y" or Future Price Valuation has a value of "Y", Floating Amount Payer is not allowed. Otherwise it is a required field. The Equity Notional Amount and Equity Notional Currency must be specified but can be considered optional in case of the following:

• For Share swap, when the Master Confirmation Type is "ISDA2009EquityEuropean". • For Index swap, when the Master Confirmation Type is "ISDA2009EquityEuropean" or

"ISDA2007EquityEuropean". Equity Notional Reset is specified as “true” (Applicable) or “false” (Not Applicable). The Return Type is specified as “Total” for a Total Return Swap, and as “Price” for a Price Swap. The Dividend Conditions fields are ‘Conditional’ fields and depend on the Return Type and Master Confirmation Type. The Dividend Conditions fields are not allowed for Master Confirmation Type of “GlobalMCA”. The Dividend Period – For Index and Share swaps: When Return Type is specified as “Total” and the Master Confirmation Type is "EquityAmericas", "EquityEuropean" or "EquityAsia", the Dividend Period field is optional. This field is NOT allowed otherwise. Dividend Period is specified as “FirstPeriod” or “SecondPeriod”. The Dividend Percentage – For Share swaps: When Return Type is specified as “Total” and the Master Confirmation Type is "ISDA2007EquityFinanceSwapEuropean" or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1", the Dividend Percentage field is required. Dividend Percentage is ‘Optional’ when the Return Type is “Total” and the Master Confirmation Type is "EquityAsia" or "GlobalMCA" or "ISDA2009EquityInterdealerPanAsia" or "EquityAmericas" or "EquityEuropean". This field is NOT allowed otherwise. For Index Swap, when Type of Return is "Total" and the Master Confirmation Type is "EquityAsia" or "GlobalMCA" or "EquityAmericas" or "EquityEuropean", the Dividend Percentage field is optional. This


field is NOT allowed otherwise. Dividend Percentage is expressed as a decimal percentage with up to seven decimal places. The Dividend Payment Date – For Share Swaps: When Return Type is specified as “Total” and the Master Confirmation Type is "ISDA2007EquityFinanceSwapEuropean", "ISDA2008EquityFinanceSwapAsiaExcludingJapan", "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1", "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia", the Dividend Payment Date is required. Dividend Payment Date is ‘Optional’ when the Return Type is “Total” and the Master Confirmation Type is "EquityAsia", "EquityAmericas", "EquityEuropean" or "ISDA2009EquityAmerica". This field is NOT allowed otherwise. The Dividend Payment Date – For Index Swaps: When Return Type is specified as “Total” and the Master Confirmation Type is "EquityAsia" or "ISDA2009EquityAmericas" or "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" or "EquityAmericas" or "EquityEuropean", the Dividend Payment Date is optional. This field is NOT allowed otherwise. The valid values for Payment Date: ”ExDate”, “DividendPaymentDate”, "RecordDate", "TerminationDate", "EquityPaymentDate", "FollowingPaymentDate", "AdHocDate", "CumulativeEquityPaid", "CumulativeLiborPaid", "CumulativeEquityExDiv", "CumulativeLiborExDiv", "SharePayment", "CashSettlementPaymentDate" or "FloatingAmountPaymentDate" or "CashSettlementPaymentDate-IssuerPayment". For Master Confirmation Types "ISDA2008EquityFinanceSwapAsiaExcludingJapan", "ISDA2007EquityFinanceSwapEuropean" and "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" valid values for Dividend Payment Date are "SharePayment", "CashSettlementPaymentDate" or "FloatingAmountPaymentDate". For Master Confirmation Type "ISDA2009EquityInterdealerPanAsia", the valid values for Dividend Payment Date are "SharePayment", "CashSettlementPaymentDate" or "CashSettlementPaymentDate-IssuerPayment". The Dividend Amount – For Index and Share swaps: When Return Type is specified as “Total” and the Master Confirmation Type is "EquityAmericas" or "EquityEuropean" or "EquityAsia", Dividend Amount is ‘Optional’. It is NOT allowed otherwise. Dividend Amount is specified as "RecordAmount", "ExAmount", or "PaidAmount". For a Share Swap, the Declared Cash Dividend Percentage must be included for Master Confirmation Type "ISDA2009EquityEuropean" and is optional for "GlobalMCA". This field is not allowed otherwise. For Index Swap, the Declared Cash Dividend Percentage is required for Master Confirmation Type "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean". It is optional for "ISDA2009EquityAmericas" or "GlobalMCA" master confirmation types. This field is not allowed otherwise. For a Share swap, the Declared Cash Equivalent Dividend Percentage may be included when the master confirmation type is “ISDA2009EquityEuropean” or "GlobalMCA". This field is not allowed otherwise. For Index swap, the Declared Cash Equivalent Dividend Percentage may be specified for "ISDA2009EquityAmericas" or "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" or "GlobalMCA" master confirmation types. This field is not allowed otherwise. Initial Price is expressed as a decimal value with up to seven places after the decimal. For Share Swap, the Initial Price is required but can be considered optional when the Master Confirmation Type is "ISDA2009EquityEuropean". For Index Swap, the Initial Price is required but can be considered optional when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean".


The Cash Settlement Payment Date for the equity leg is expressed as a number of currency business days following the relevant valuation date. For Share swap, the Cash Settlement Payment Date is required but can be considered optional for Master Confirmation Types "ISDA2007EquityFinanceSwapEuropean", "ISDA2008EquityFinanceSwapAsiaExcludingJapan", "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" or "GlobalMCA" MCA... For Index swap, the Cash Settlement Payment Date is required except for the below mentioned scenarios:

• When Master Confirmation type is "GlobalMCA" or "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean", the field is optional

• When Master Confirmation type is "ISDA2009EquityAmericas", the field is NOT allowed. A Settlement Currency must be specified as an ISO currency code. For "ISDA2008EquityFinanceSwapAsiaExcludingJapan" and "ISDA2007EquityFinanceSwapEuropean" and "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" MCA, the Settlement Currency should have the same value as the Initial Price Currency. Final Price is expressed as enumerated values “Closing Price” or “VWAP Price”. Final Price can be represented using determinationMethod element.Final Price is applicable only to share swap; the field can be specified when the master confirmation type is "ISDA2009EquityAmericas" or "EquityAmericas"; This field is not allowed otherwise. For a Share Swap, the Number of Shares/Units must be specified (in all cases) and as a decimal value that may contain up to five decimal places. For Index swap, the Number of Shares/Units must be specified when the Master Confirmation Type is “GlobalMCA", "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean". Floating Rate Option will contain a value that adheres to the FpML scheme. The Designated Maturity is expressed as an integer multiplier of a period “D” (Days), “W” (Weeks), “M” (Months), or “Y” (Years). Spread is required and is expressed as a signed percentage with up to seven decimal places; zero is a valid value. Floating Rate Day Count Fraction will be specified with one of the valid FpML scheme values: 1/1, ACT/ACT.ICMA, ACT/ ACT.ISDA, ACT/ACT.ISMA, ACT/ACT.AFB, ACT/365.FIXED, ACT/360, 30/360, 30E/360, or 30E/360.ISDA. The Valuation Dates for the equity leg and the Payment Dates for the floating leg are specified as a list of up to 360 adjusted dates. The dates should be submitted in ascending date order to facilitate matching. The Business Days (for the Payment Dates) are expressed using the FpML four-character city codes. There may be one to five city codes specified. For Share swap, the Business Days field MUST be specified except for in the following cases:

• When Master confirmation type is "GlobalMCA", the field is optional. • When Floating Payment Dates or First Floating Payment Date is not populated for an

"ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia" Master Confirmation Type, the field is optional.

• When Floating Amount Payer is not populated for an "ISDA2007EquityFinanceSwapEuropean", "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1", the field is NOT allowed.

For Index swap, the Business Days field MUST be specified except for in the following cases:

• When Master confirmation type is "GlobalMCA", the field is optional.


• When Floating Payment Dates or First Floating Payment Date is not populated for an "ISDA2009EquityAmericas" or "ISDA2007EquityEuropean" or "ISDA2009EquityEuropean", the field is optional.

• When Floating Amount Payer is not populated, the field is NOT allowed. Mutual Early Termination Right will always be “Applicable” unless specified as “false” (Not Applicable) in the record. The field will not be included in the record when the value is “Applicable”. For Share swap, Mutual Early Termination Right must not be included for “ISDA2007EquityFinanceSwapEuropean”, ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" MCAs. For Index swap, Mutual Early Termination Right will be an optional field. The Multiple Exchange Index Annex is an optional field for Master Confirmation Type of “GlobalMCA” for both Share and Index Swaps. This field is NOT allowed otherwise. For Share swap, the Maximum Stock Loan Rate can be specified only when the Master confirmation type is "ISDA2009EquityAmericas", "EquityAmericas" or "GlobalMCA". The field is not allowed otherwise. For Index swap, the Maximum Stock Loan Rate can be specified only when the Master confirmation type is "GlobalMCA" or "ISDA2009EquityAmericas". The field is not allowed otherwise. For Share swap, Initial Stock Loan Rate can be specified only when the Master confirmation type is "ISDA2009EquityAmericas" or "EquityAmericas". The field is not allowed otherwise. For Index swap, Initial Stock Loan Rate can be specfified only when "ISDA2009EquityAmericas". The field is not allowed otherwise. The optional Independent Amount (Initial Margin) may be expressed either as a currency amount or as a percentage of the Notional Amount, and includes the Independent Amount Payer. The DTCC matching system compares all fields with the exception of the internal comment, link Transaction id, 15A-6 rule, and the trade reference numbers, which is uniquely assigned by each firm. All information must correspond exactly in order for two Trade records to be considered matched. For a Share Swap, the Contractual Supplement may be populated with value "ISDAMarch2004EquityCanadianSupplement" ONLY when the master confirmation type is "EquityAmericas" or “ISDA2004EquityAmericasInterdealer”. When "ISDA2009EquityAmericas" is the master confirmation type, the Contractual Supplement field is required when Depository Receipt Election field is ‘Y’ and NOT allowed when Depository Election field is ‘N’ or not populated. For Index Swap, the Contractual Supplement may be populated with value "ISDAMarch2004EquityCanadianSupplement" ONLY when the master confirmation type is "EquityAmericas" or “ISDA2004EquityAmericasInterdealer”.. For a Share Swap, the Partial Lookthrough and Full Lookthrough Contractual Supplements may be used for any underlying master confirmation. The Master Confirmation Annex Type is an optional field applicable for Share and Index Swaps only when Master Confirmation Type is “GlobalMCA” and can take any of the following values.

“SSS (US)” or “SSS (AEUS)” or “SSS (EMEA)” or


“SSS (AEJA)” or “SSS (Japan)” or “SIS (US)” or “SIS (AEUS)” or “SIS (EMEA)” or “SIS (AEJA)” or “SIS (Japan)” or “SB(SR)S (US)” or “SB(SR)S (AEUS)” or “SB(SR)S (EMEA)” or “SB(SR)S (AEJA)” or “SB(SR)S (Japan)”

The Final Fee fields may be specified when Master Confirmation Type is “GlobalMCA” for both Share and Index Swaps. Final Fee can be specified either via the Final Price Fee Percent or Final Price Fee Amount. The Final Price Fee Currency is required only when Final Price Fee Amount is specified. The Strike Date is an optional field for Share Swap when the Master Confirmation Type is “ISDA2009EquityEuropean”. For an Index Swap, the Strike Date is optional when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean". This field in NOT allowed for other cases. The Hedging Party is an optional field for Share Swap when the Master Confirmation Type is "ISDA2009EquityEuropean" or ISDA2009EquityInterdealerPanAsia". For an Index Swap, the Hedging Party field is optional when the Master Confirmation Type is "ISDA2009EquityEuropean". This field in NOT allowed for other cases. The field Initial Price Election, for Index and Share Swaps, is optional when the Strike date is populated. This field in NOT allowed otherwise. Valid values for Initial Price Election are “HedgeExecution” or “AgreedInitialPrice” or "Close" For Share Swap, the Dividend Settlement Currency, is optional when the Master Confirmation Type is "ISDA2009EquityEuropean". It is NOT allowed otherwise. The valid values for Dividend Settlement Currency are “IssuerPaymentCurrency” or "SettlementCurrency". The Dividend Settlement Currency field is NOT allowed for Index Swap. For Share Swap, Treatment of Non-Cash Dividends is optional when the Master Confirmation Type is "ISDA2009EquityEuropean". This field in NOT allowed otherwise. Valid values for Treatment of Non-Cash Dividends are “CashEquivalent”, "PotentialAdjustmentEvent". The Treatment of Non-Cash Dividends field is NOT allowed for Index Swap. For Share Swap, Composition of Dividends is optional when the Master Confirmation Type is "ISDA2009EquityEuropean". Valid values for Composition of Dividends are “EquityAmountReceiverElection” or “CalculationAgentElection”. The Composition of Dividends field is NOT allowed for Index Swap. Break Fee Election - For Share Swap, Break Fee Election may be specified ONLY when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia". When Master confirmation type is "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia" and the Early Termination Right is populated as ‘N’, Break Fee Election is NOT allowed.


For Index Swap,Break Fee Election may be specified ONLY when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean". When Master confirmation type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean” and the Early Termination Right is populated as ‘N’, the field is NOT allowed. , Valid values for Break fee Election are "FlatFee”, “AmortizedFee”, “FundingFee”, “FlatFeeAndFundingFee” or “AmortizedFeeAndFundingFee”. Break Fee Rate – For Share Swap and Index Swap, the Break Fee Rate is required ONLY when the Break Fee Election is populated except in the following cases.

• When Break Fee Election is populated with “Funding Fee”, Break Fee Rate is NOT allowed. • When Master confirmation type is "EquityAsia", the Break Fee Rate is optional.

Linear Interpolation Period – For Share Swap: When the Master Confirmation Type is "ISDA2009EquityEuropean" and Linear Interpolation is "LinearZeroYield", Linear Interpolation Period is optional. This field in NOT allowed otherwise. For Index Swap: When the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" and Linear Interpolation is "LinearZeroYield", Linear Interpolation is optional. This field in NOT allowed otherwise. Valid values for Linear Interpolation Period are “Initial” or “InitialAndFinal”. Valuation Date Convention is an optional field. Valid values for Valuation Date Convention are "PRECEDING", "FOLLOWING" and "MODFOLLOWING". Optional Early Termination Electing Party and Optional Early Termination Date – For Share and Index Swap: When the Early Termination Right is populated with N, Optional Early Termination Electing Party is not allowed. This field is optional otherwise. Valid values for Optional Early Termination Date are “AnyDay”, “ValuationDate”, “ResetDate” and “AfterFirstResetDate”. Settlement Type – For Share and Index Swap: when the Master Confirmation Type is "GlobalMCA", Settlement Type is optional. This field is NOT allowed otherwise. Valid values for Settlement Type are "Cross-Currency" and "Composite". Roll Over Commission – For Share and Index Swap: when the Master Confirmation Type is "EquityAsia", Roll Over Commission is optional. This field is optional otherwise. Reference Currency - For Share and Index Swap: when the Settlement Type is populated, Reference Currency is required. It is NOT allowed otherwise. The fields - Insolvency Filing, Loss of Stock Borrow, Increased Cost of Stock Borrow and Break Funding Recovery are optional when the Master Confirmation Type is "ISDA2009EquityAmericas" for an Index Swap. It is NOT allowed otherwise. The fields - Insolvency Filing, Loss of Stock Borrow, Increased Cost of Stock Borrow and Break Funding Recovery are NOT allowed for Share Swap. Index Disruption and Compounding – For Index Swap: when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean", Index Disruption and Compounding is optional. This field is NOT allowed for other cases. Valid values for Index Disruption are “Postponement” and “CalculationAgentAdjustment”. Index Disruption and Compounding is NOT allowed for Share Swap.


Determining Party, Calculation Agent and Reference Price Source – For Share Swap: when the Master Confirmation Type is "ISDA2009EquityInterdealerPanAsia", the fields Determining Party, Calculation Agent and Reference Price Source are Optional. It is NOT allowed otherwise. Determining Party, Calculation Agent and Reference Price Source is NOT allowed for Index Swap. Reference Price Page and Reference Price Time - For Share Swap: When Reference Price Source is populated, the fields Reference Price Page and Reference Price Time are optional. It is NOT allowed otherwise. Reference Price Page and Reference Price Time is NOT allowed for Index Swap. Deriv/SERV transaction records may optionally include any or all of the “workflow fields” that are designed to support Prime Broker Billing and other workflow functions. These fields are all optional and nonmatching. Please See Section 2.8 for a detailed description of the “workflow fields.


2.1.2.1 New Trade – Equity Swap (BulletCompounding) An Equity Swap with BulletCompounding contains the following fields: The parties to the trade identify by date the Master Confirmation Agreement under which the trade has been executed. For Equity Swap, the parties will specify whether Master Confirm Type is:

“EquityAmericas” or “EquityEuropean” or "ISDA2005EquityAsiaExcludingJapanInterdealer” or “EquityAsia” “ISDA2007EquityFinanceSwapEuropean” “ISDA2008EquityFinanceSwapAsiaExcludingJapan” “ISDA2005EquityAsiaExcludingJapanInterdealerRev2” “ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1” “ISDA2004EquityAmericasInterdealer” “ISDA2009EquityAmericas” “ISDA2009EquityEuropean” "ISDA2009EquityInterdealerPanAsia" "ISDA2007EquityEuropean"

The MCA Types "ISDA2007EquityFinanceSwapEuropean" and "ISDA2008EquityFinanceSwapAsiaExcludingJapan" and "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" and "ISDA2009EquityInterdealerPanAsia" are applicable only to Share swaps and not for Index swaps. The MCA Type "ISDA2007EquityEuropean" is applicable only for Index swaps and not for Share swaps. For a Share Swap, the Shares are identified in the trade record by the RIC identifier (Reuters Instrument Code). For a Share Swap, the Shares are identified in the trade record by the RIC identifier (Reuters Instrument Code). For an Index Swap, the Index is specified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange will be specified using a REC identifier (Reuters Exchange Code), in a separate field, not as a suffix. The text is case sensitive. DTCC will not validate the submitted RICs and RECs. Listing multiple Exchanges is supported by specifying multiple constituent Exchange REC identifiers with a maximum allowable occurrence of 10 unique identifiers. The Exchange ID is optional when the MCA Type is or “ISDA2009EquityAmericas”; otherwise Exchange ID is required for all other MCA Types for Index swap. The Related Exchange must also be specified but it is considered optional when the Master Confirmation Type is “ISDA2008EquityFinanceSwapAsiaExcludingJapan”, "ISDA2007EquityFinanceSwapEuropean", "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" or "ISDA2009EquityInterdealerPanAsia" for a Share Swap. For Index swaps, Related Exchange ID must be specified but it is considered optional when the Master Confirmation Type is "ISDA2009EquityAmericas". Valid values are any one of the REC identifiers for or the word “ALL” to denote All Exchanges. The text is case sensitive. Listing multiple Related Exchances is also supported by specifying more than one identifier with a maximum allowable occurrence of 10 unique identifiers. If multiple Related Exchanges are specified, then the “ALL” value


must not be used. Related Exchange is optional for Master Confirmation Type of “GlobalMCA” for both Share and Index Swaps. The Average Daily Trading Volume (ADTV) Limit Percentage and Average Daily Trading Volume (ADTV) Limit Period can be specified (optional element) to the underlyer for Share swaps when the master confirmation type is “ISDA2009EquityAmericas” or "EquityAmericas", otherwise the fields are NOT allowed. The ADTV Limit Percentage and ADTV Limit Period fields are not allowed for Index swaps. In addition the underlyer can represent whether the Depository Receipt is Applicable or Not Applicable (optional) when the master confirmation type is “ISDA2009EquityAmericas” (applicable only for Share swaps and not allowed for Index swaps). The Trade Date and Effective Date are expressed as actual dates (YYYY-MM-DD in the FpML messages). These date fields are validated by the DTCC system only for date format. The Submitter, Counterparty, Equity Amount Payer and Floating Amount Payer are identified using DTCC-assigned numbers. These identifiers will be stored in a table with full legal names of the firms, for display on the web application and other output. The Floating Amount Payer is required for Share and Index Bullet compounding. The Equity Notional Amount and Equity Notional Currency must be specified but can be considered optional in case of the following:

• For Share swap, when the Master Confirmation Type is "ISDA2009EquityEuropean". • For Index swap, when the Master Confirmation Type is "ISDA2009EquityEuropean" or

"ISDA2007EquityEuropean". Equity Notional Reset is specified as “true” (Applicable) or “false” (Not Applicable). The Return Type is specified as “Total” for a Total Return Swap, and as “Price” for a Price Swap. The Dividend Conditions fields are ‘Conditional’ fields and depend on the Return Type and Master Confirmation Type. The Dividend Period – For Index and Share swaps: When Return Type is specified as “Total” and the Master Confirmation Type is "EquityAmericas", "EquityEuropean" or "EquityAsia", the Dividend Period field is optional. This field is NOT allowed otherwise. Dividend Period is specified as “FirstPeriod” or “SecondPeriod”. The Dividend Percentage – For Share swaps: When Return Type is specified as “Total” and the Master Confirmation Type is "ISDA2007EquityFinanceSwapEuropean" or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1", the Dividend Percentage field is required. Dividend Percentage is ‘Optional’ when the Return Type is “Total” and the Master Confirmation Type is "EquityAsia” or "ISDA2009EquityInterdealerPanAsia" or "EquityAmericas" or "EquityEuropean". This field is NOT allowed otherwise. The Dividend Payment Date – For Share Swaps: When Return Type is specified as “Total” and the Master Confirmation Type is "ISDA2007EquityFinanceSwapEuropean", "ISDA2008EquityFinanceSwapAsiaExcludingJapan",


"ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1", "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia", the Dividend Payment Date is required. Dividend Payment Date is ‘Optional’ when the Return Type is “Total” and the Master Confirmation Type is "EquityAsia", "EquityAmericas", "EquityEuropean" or "ISDA2009EquityAmerica". This field is NOT allowed otherwise. The Dividend Payment Date – For Index Swaps: When Return Type is specified as “Total” and the Master Confirmation Type is "EquityAsia" or "ISDA2009EquityAmericas" or "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" or "EquityAmericas" or "EquityEuropean", the Dividend Payment Date is optional. This field is NOT allowed otherwise. The valid values for Payment Date: ”ExDate”, “DividendPaymentDate”, "RecordDate", "TerminationDate", "EquityPaymentDate", "FollowingPaymentDate", "AdHocDate", "CumulativeEquityPaid", "CumulativeLiborPaid", "CumulativeEquityExDiv", "CumulativeLiborExDiv", "SharePayment", "CashSettlementPaymentDate" or "FloatingAmountPaymentDate" or "CashSettlementPaymentDate-IssuerPayment". For Master Confirmation Types "ISDA2008EquityFinanceSwapAsiaExcludingJapan", "ISDA2007EquityFinanceSwapEuropean" and "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" valid values for Dividend Payment Date are "SharePayment", "CashSettlementPaymentDate" or "FloatingAmountPaymentDate". For Master Confirmation Type "ISDA2009EquityInterdealerPanAsia", the valid values for Dividend Payment Date are "SharePayment", "CashSettlementPaymentDate" or "CashSettlementPaymentDate-IssuerPayment". The Dividend Amount – For Index and Share swaps: When Return Type is specified as “Total” and the Master Confirmation Type is "EquityAmericas" or "EquityEuropean" or "EquityAsia", Dividend Amount is ‘Optional’. It is NOT allowed otherwise. Dividend Amount is specified as "RecordAmount", "ExAmount", or "PaidAmount". For a Share Swap, the Declared Cash Dividend Percentage must be included for Master Confirmation Type "ISDA2009EquityEuropean". This field is not allowed otherwise. For Index Swap, the Declared Cash Dividend Percentage is required for Master Confirmation Type "ISDA2009EquityEuropean” or "ISDA2007EquityEuropean". This field is not allowed otherwise. For share swap, the Declared Cash Equivalent Dividend Percentage may be included when the master confirmation type is “ISDA2009EquityEuropean”. This field is not allowed otherwise. For Index swap, the Declared Cash Equivalent Dividend Percentage may be specified for "ISDA2009EquityAmericas" or "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" master confirmation types. This field is not allowed otherwise. Initial Price is expressed as a decimal value with up to seven places after the decimal. For Share Swap, the Initial Price is required but can be considered optional when the Master Confirmation Type is "ISDA2009EquityEuropean". For Index Swap, the Initial Price is required but can be considered optional when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean". The Cash Settlement Payment Date for the equity leg is expressed as a number of currency business days following the relevant valuation date. For Share swap, the Cash Settlement Payment Date is required but can be considered optional for Master Confirmation Types "ISDA2007EquityFinanceSwapEuropean", "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" MCA.


For Index swap, the Cash Settlement Payment Date is required except for the below mentioned scenarios:

• When Master Confirmation type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean", the field is optional

• When Master Confirmation type is "ISDA2009EquityAmericas", the field is NOT allowed. A Settlement Currency must be specified as an ISO currency code. For "ISDA2008EquityFinanceSwapAsiaExcludingJapan” and "ISDA2007EquityFinanceSwapEuropean" and "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" MCA, the Settlement Currency should have the same value as the Initial Price Currency. Final Price is expressed as enumerated values “Closing Price” or “VWAP Price”. Final Price can be represented using determinationMethod element. Final Price is applicable only to share swap; the field can be specified when the master confirmation type is "ISDA2009EquityAmericas" or "EquityAmericas"; this field is not allowed otherwise. For a Share Swap, the Number of Shares/Units must be specified (in all cases) and as a decimal value that may contain up to five decimal places. For Index swap, the Number of Shares/Units must be specified when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean". Floating Rate Option will contain a value that adheres to the FpML scheme. The Designated Maturity is expressed as an integer multiplier of a period “D” (Days), “W” (Weeks), “M” (Months), or “Y” (Years). Spread is required and is expressed as a signed percentage with up to seven decimal places; zero is a valid value. Floating Rate Day Count Fraction will be specified with one of the valid FpML scheme values: 1/1, ACT/ACT.ICMA, ACT/ ACT.ISDA, ACT/ACT.ISMA, ACT/ACT.AFB, ACT/365.FIXED, ACT/360, 30/360, 30E/360, or 30E/360.ISDA. The Valuation Dates for the equity leg and the Payment Dates for the floating leg are specified as a list of up to 360 adjusted dates. The dates should be submitted in ascending date order to facilitate matching. The Business Days (for the Payment Dates) are expressed using the FpML four-character city codes. There may be one to five city codes specified. For a Share Swap, the Business Days field is optional when Floating Payment Dates and First Floating Payment Date are not populated and the Master Confirmation type is "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia". For a Index Swap, the Business Days field is optional when Floating Payment Dates and First Floating Payment Date is not populated and the Master Confirmation Type is for an "ISDA2009EquityAmericas" or "ISDA2007EquityEuropean" or "ISDA2009EquityEuropean". Mutual Early Termination Right will always be “Applicable” unless specified as “false” (Not Applicable) in the record. The field will not be included in the record when the value is “Applicable”. Mutual Early Termination Right must not be included for “ISDA2007EquityFinanceSwapEuropean”, "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1” or ISDA2008EquityFinanceSwapAsiaExcludingJapan" MCAs. When Additional Disruption events are applicable, the Maximum Stock Loan Rate and the Initial Stock Loan Rate can be represented for “ISDA2009EquityAmericas” or "EquityAmericas" (for share swap) master confirmation type The optional Independent Amount (Initial Margin) may be expressed either as a currency amount or as a percentage of the Notional Amount, and includes the Independent Amount Payer.


The DTCC matching system compares all fields with the exception of the internal comment, link Transaction id, 15A-6 rule, and the trade reference numbers, which is uniquely assigned by each firm. All information must correspond exactly in order for two Trade records to be considered matched. For a Share Swap and Index Swap, the Canadian Contractual Supplement may be used with “EquityAmericas” master confirmation. For a Share Swap, the Partial Lookthrough and Full Lookthrough Contractual Supplements may be used for any underlying master confirmation. Deriv/SERV transaction records may optionally include any or all of the “workflow fields” that are designed to support Prime Broker Billing and other workflow functions. These fields are all optional and nonmatching. Please See Section 2.8 for a detailed description of the “workflow fields. In addition to above fields, the Equity Swap on BulletCompounding may include the Compounding Spread when the master confirmation type is "EquityAmericas", "EquityEuropean", or "'EquityAsia".


2.1.3 New Trade – Equity Variance Swap A Variance Swap contains the following fields: The parties to the trade identify by date the Master Confirmation Agreement under which the trade has been executed. For Equity Variance Swap, the parties will specify whether Master Confirm Type is:

“EquityAmericas” or “EquityEuropean” or "ISDA2006VarianceSwapJapaneseInterdealer" or "ISDA2004VarianceSwapAmericasInterdealer" or "ISDA2007VarianceSwapAmericas" or "ISDA2007VarianceSwapAsiaExcludingJapan" or "ISDA2007VarianceSwapEuropean" or "EquityAsia" “ISDA2007VarianceSwapAsiaExcludingJapanRev1”

For a Share Variance Swap, the Shares are identified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange for a Share Variance Swap will be specified by the RIC suffix, a code appended to the RIC, not as a separate field. The text is case sensitive. DTCC will not validate the submitted RICs. For an Index Variance Swap, the Index is specified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange will be specified using a REC identifier (Reuters Exchange Code), in a separate field, not as a suffix. The text is case sensitive. DTCC will not validate the submitted RICs and RECs. Listing multiple Exchanges is supported by specifying multiple constituent Exchange REC identifiers with a maximum allowable occurrence of 10 unique identifiers. The Related Exchange must also be specified. Valid values are any one of the REC identifiers for exchanges or the word “ALL” to denote All Exchanges. The text is case sensitive. Listing multiple Related Exchances is also supported by specifying more than one identifier with a maximum allowable occurrence of 10 unique identifiers. If multiple Related Exchanges are specified, then the “ALL” value must not be used. The Trade Date and Valuation Date, required fields, are expressed as actual dates (YYYY-MM-DD in the FpML messages) and will be validated by the DTCC system only for date format. Observation Start Date, an optional field, is expressed as an actual date (YYYY-MM-DD in the FpML messages) and will be validated by the DTCC system only for date format. When Observation Start Date is omitted, the DTCC system will insert the trade date in that field. The Submitter, Counterparty, Seller and the Buyer are identified using DTCC-assigned numbers. These identifiers will be stored in a table with full legal names of the firms, for display on the web application and other output. The Variance Amount, a required field, may contain up to two decimal places. The convention for computing the Variance Amount is the vega notional divided by two times the strike price. The Strike Price is required and will be expressed as the Variance Strike Price, not the Volatility Strike Price. The field may include up to four decimal places.


For a Share Variance Swap, the Initial Share Price is specified as a decimal value with up to two decimal places. Alternately, when no Initial Share Price is specified, the Closing Share Price is specified as “true” (Applicable). For an Index Variance Swap, the Initial Index Level is specified as a decimal value with up to seven decimal places. Alternately, when no Initial Index Level is specified, the Closing Index Level or Expiring Contract Level is specified as “true” (Applicable). The record may specify whether Options Price Valuation is “Applicable” or “Not Applicable”; if “Applicable” is specified, the record must include the Exchange Traded Contract, identified by month and year. Options Price Valuation must be omitted for: "ISDA2006VarianceSwapJapaneseInterdealer", "ISDA2006VarianceSwapJapanese" and "ISDA2004VarianceSwapAmericasInterdealer” MCAs. The Cash Settlement Payment Date, an optional field, is specified as a number of currency business days following the Valuation Date. A Settlement Currency must be specified as an ISO currency code. Expected N is expressed as an integer number of days. For a Share Variance Swap, the Options Exchange Dividends field is specified as “true” (Applicable) or “false” (Not Applicable). The optional Independent Amount (Initial Margin) may be expressed either as a currency amount or as a percentage, and includes the Independent Amount Payer. Variance Cap must be specified as either “false” (Not Applicable), or by providing the computed Variance Cap (the variance cap factor squared times the variance strike price). Zero is not a valid value. The DTCC matching system compares all fields with the exception of the internal comment, link Transaction id, 15A-6 rule, and trade reference number, which is uniquely assigned by each firm. For two Trade records to be considered matched all information must correspond exactly. For a Share Variance Swap, the Partial Lookthrough and Full Lookthrough Contractual Supplements may be used for any underlying master confirmation. Deriv/SERV transaction records may optionally include any or all of the “workflow fields” that are designed to support Prime Broker Billing and other workflow functions. These fields are all optional and nonmatching. Please See Section 2.8 for a detailed description of the “workflow fields.


2.1.4 New Trade – Dividend Swap A Dividend Swap contains the following fields: The parties to the trade identify by date the Master Confirmation Agreement under which the trade has been executed. For a Dividend Swap, the parties will specify whether Master Confirm Type is:

“2006DividendSwapEuropean” or “2006DividendSwapEuropeanInterdealer” or "ISDA2008DividendSwapsJapanese" or "EquityAmericas"

The Master Confirm Date is expressed as an actual date (YYYY-MM-DD in the FpML messages) and will be validated by the DTCC system only for date format.

For a Share Dividend Swap, the Shares are identified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange for a Dividend Swap will be included in the RIC suffix, a code appended to the RIC. The text is case sensitive. DTCC will not validate the submitted RICs. For an Index Dividend Swap, the Index is specified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange will be specified using a REC identifier (Reuters Exchange Code), in a separate field, not as a suffix. The text is case sensitive. DTCC will not validate the submitted RICs and RECs. Listing multiple Exchanges is supported by specifying multiple constituent Exchange REC identifiers with a maximum allowable occurrence of 10 unique identifiers. The Related Exchange must also be specified. Valid values are any one of the REC identifiers for exchanges or the word “ALL” to denote All Exchanges. The text is case sensitive. Listing multiple Related Exchances is also supported by specifying more than one identifier with a maximum allowable occurrence of 10 unique identifiers. If multiple Related Exchanges are specified, then the “ALL” value must not be used. The Trade Date is expressed as an actual date (YYYY-MM-DD in the FpML messages) and will be validated by the DTCC system only for date format. The Originator, Counterparty, Fixed Amount Payer and Dividend Amount Payer are identified using DTCC-assigned numbers. These identifiers will be stored in a table with full legal names of the firms, for display on the web application and other output. The Number of Shares/Baskets, a required field, may contain up to five decimal places. The Settlement Currency, a required field, should contain a valid 3-character currency code. The Declared Cash Dividend Percentage and Declared Cash Equivalent Dividend Percentage, both required fields, may contain up to five decimal places. The Dividend Periods represents the number of dividend periods with a maximum value of 20. It must be a positive nonzero Integer. The Start Date, End Date Dividend Amount Payment Date, and Fixed Strike all are required per Dividend Period.


Each Dividend Period will have an associated Payment Amount which will be equal to the product of the Fixed Strike and the Number of Shares/Baskets. An optional Independent Amount (Initial Margin) may be included per Dividend Period and may be expressed either as a currency amount or as a percentage, and includes the Independent Amount Payer. The DTCC matching system compares all fields with the exception of the internal comment, link Transaction id, and trade reference number, which is uniquely assigned by each firm. For two Trade records to be considered matched all information must correspond exactly. For a Share Dividend Swap, the Partial Lookthrough and Full Lookthrough Contractual Supplements may be used for any underlying master confirmation. Deriv/SERV transaction records may optionally include any or all of the “workflow fields” that are designed to support Prime Broker Billing and other workflow functions. These fields are all optional and nonmatching. Please See Section 2.8 for a detailed description of the “workflow fields.


2.1.5 New Trade – Equity Dispersion Variance A Dispersion Variance Swap is constituted by a single Index Variance Swap and multiple Share Variance Swaps. Trade participants of Equity Dispersion Variance take an opposite position in the Equity Dispersion Index Variance swap(EDI) and Equity Dispersion Share Variance swap(EDS) components i.e. seller of an Index Variance Swap of a dispersion will be the buyer of Share Variance Swap of the same dispersion and vice versa . Equity Dispersion Variance contracts are confirmed as a single trade though it constitutes of one Index Variance Swap and multiple Share Variance Swaps. The parties to the trade identify by date the Master Confirmation Agreement under which the trade has been executed. For EDI or EDS, the parties will specify whether Master Confirm Type is:

“EquityAmericas” “EquityEuropean” "ISDA2007VarianceSwapEuropean" "ISDA2007VarianceSwapAmerica"

For a Dispersion Share Variance Swap, the Shares are identified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange for a Share Variance Swap will be specified by the RIC suffix, a code appended to the RIC, not as a separate field. The text is case sensitive. DTCC will not validate the submitted RICs. For a Dispersion Index Variance Swap, the Index is specified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange will be specified using a REC identifier (Reuters Exchange Code), in a separate field, not as a suffix. The text is case sensitive. DTCC will not validate the submitted RICs and RECs. Listing multiple Exchanges is supported by specifying multiple constituent Exchange REC identifiers with a maximum allowable occurrence of 10 unique identifiers. The Related Exchange must also be specified. Valid values are any one of the REC identifiers for exchanges or the word “ALL” to denote All Exchanges. The text is case sensitive. Listing multiple Related Exchances is also supported by specifying more than one identifier with a maximum allowable occurrence of 10 unique identifiers. If multiple Related Exchanges are specified, then the “ALL” value must not be used. The Trade Date and Valuation Date, required fields, are expressed as actual dates (YYYY-MM-DD in the FpML messages) and will be validated by the DTCC system only for date format. Observation Start Date, an optional field, is expressed as an actual date (YYYY-MM-DD in the FpML messages) and will be validated by the DTCC system only for date format. When Observation Start Date is omitted, the DTCC system will insert the trade date in that field. The Submitter, Counterparty, Seller and the Buyer are identified using DTCC-assigned numbers. These identifiers will be stored in a table with full legal names of the firms, for display on the web application and other output. The Variance Amount, a required field, may contain up to two decimal places. The convention for computing the Variance Amount is the vega notional divided by two times the strike price.


The Strike Price is required and will be expressed as the Variance Strike Price, not the Volatility Strike Price. The field may include up to four decimal places. For a Share Variance Swap, the Initial Share Price is specified as a decimal value with up to two decimal places. Alternately, when no Initial Share Price is specified, the Closing Share Price is specified as “true” (Applicable). For an Index Variance Swap, the Initial Index Level is specified as a decimal value with up to seven decimal places. Alternately, when no Initial Index Level is specified, the Closing Index Level or Expiring Contract Level is specified as “true” (Applicable). The Cash Settlement Payment Date, an optional field, is specified as a number of currency business days following the Valuation Date. A Settlement Currency must be specified as an ISO currency code. Expected N is expressed as an integer number of days. The optional Independent Amount (Initial Margin) may be expressed either as a currency amount, and includes the Independent Amount Payer. Variance Cap must be specified as either “false” (Not Applicable), or by providing the computed Variance Cap (the variance cap factor squared times the variance strike price). Zero is not a valid value. The DTCC matching system compares all fields with the exception of the internal comment, link Transaction id, and trade reference number, which is uniquely assigned by each firm. For two Trade records to be considered matched all information must correspond exactly. Deriv/SERV transaction records may optionally include any or all of the “workflow fields” that are designed to support Prime Broker Billing and other workflow functions. These fields are all optional and nonmatching. Please See Section 2.8 for a detailed description of the “workflow fields.


2.1.6 New Trade – Equity Variance Option A Variance Option contains the following fields: The parties to the trade identify by date the Master Confirmation Agreement under which the trade has been executed. For Equity Variance Option, the parties will specify whether Master Confirmation Transaction Type is: “EquityAmericas” “EquityEuropean” or "ISDA2007VarianceOptionEuropean" For an Index Variance Option, the Index is specified in the trade record by the RIC identifier (Reuters Instrument Code). The Exchange will be specified using a REC identifier (Reuters Exchange Code), in a separate field, not as a suffix. The text is case sensitive. DTCC will not validate the submitted RICs and RECs. Listing multiple Exchanges is supported by specifying multiple constituent Exchange REC identifiers with a maximum allowable occurrence of 10 unique identifiers. The Related Exchange must also be specified. Valid values are any one of the REC identifiers for exchanges or the word “ALL” to denote All Exchanges. The text is case sensitive. Listing multiple Related Exchanges is also supported by specifying more than one identifier with a maximum allowable occurrence of 10 unique identifiers. If multiple Related Exchanges are specified, then the “ALL” value must not be used. The Option Style must be “European” only. The Trade Date, a required field, is expressed as an actual date (YYYY-MM-DD in the FpML messages) and will be validated by the DTCC system only for date format. Observation Start Date and Premium Payment Date, optional fields, are expressed as an actual date (YYYY-MM-DD in the FpML messages) and will be validated by the DTCC system only for date format. When Observation Start Date is omitted, the DTCC system will insert the trade date in that field. The Originator ID, Counterparty ID, Seller and the Buyer are identified using DTCC-assigned numbers. These identifiers will be stored in a table with full legal names of the firms, for display on the web application and other output. The Variance Amount, a required field, may contain up to two decimal places. The convention for computing the Variance Amount is the vega notional divided by two times the strike price. The Strike Price is required and will be expressed as the Variance Strike Price, not the Volatility Strike Price. The field may include up to four decimal places. For a Share Variance Option, the Initial Level is specified as a decimal value with up to two decimal places. Alternately, when no Initial Level is specified, the Closing level is specified as “true” (Applicable). For an Index Variance Option, the Initial Index Level is specified as a decimal value with up to seven decimal places. Alternately, when no Initial Index Level is specified, the Closing Index Level or Expiring Contract Level is specified as “true” (Applicable).


The Cash Settlement Payment Date, an optional field, is specified as a number of currency business days. A Settlement Currency, an optional field, must be specified as an ISO currency code. Expected N, an optional field, is expressed as an integer number of days. Multiple Exchange Index Annex is required for Index variance option. The optional Independent Amount (Initial Margin) may be expressed either as a currency amount or as a percentage, and includes the Independent Amount Payer. Variance Cap, a required field, must be specified when the Variance Cap Applicable is “Y”. Zero is not a valid value. The DTCC matching system compares all fields with the exception of the internal comment, link Transaction id, 15A-6 rule, and trade reference number, which is uniquely assigned by each firm. For two Trade records to be considered matched all information must correspond exactly. Deriv/SERV transaction records may optionally include any or all of the “workflow fields” that are designed to support Prime Broker Billing and other workflow functions. These fields are all optional and nonmatching. Please See Section 2.8 for a detailed description of the “workflow fields”.


2.2 Full Termination For all supported Equity Derivative products, the DTCC Deriv/SERV system supports the matching of Full Termination records. This includes the Full Termination of trades that were previously submitted to the system, as well as the Full Termination of trades that may have been confirmed outside DTCC. The submission of a Full Termination must follow the rules in the “Message Architecture” document. Refer to the following sub-sections for specific additional rules that are relevant to each individual Equity product. 2.2.1 Full Termination - Equity Option For an Equity Option, the DTCC Deriv/SERV system will accept a Full Termination represented by including a set of additional information fields that further identify the trade that is being terminated. This set of additional information fields is required for a trade that was not previously submitted to DTCC and is optional for trades that were previously submitted to the system. If one party to the Full Termination includes the additional information fields, this does not require the counter party to do the same. The DTCC Deriv/SERV system will accept a Full Termination record that has the following enumerated information fields (in addition to those always required per the “Message Architecture” document):

Original Trade Date Expiration Date Option Style Option Type Index (for Index Options) or Shares (for Share Options) Number of Options Buyer and Seller Strike Price Strike Price Currency (for Share Options) Settlement Currency Settlement Type

Strike Percent and Strike Date may be submitted instead of Strike Price and Strike Currency.

Note that the Number of Options field will contain the number of options just prior to the termination. This form of representing the trade to terminate is the 2nd of the three (3) allowable:

1. Submitting a Trade Reference Number of a previously submitted trade, together with a Trade Reference Number Supplement.

2. Submitting a Trade Reference Number of a previously submitted trade or of a trade that may have been confirmed outside DTCC, together with a Trade Reference Number Supplement plus the above enumerated additional information fields.

3. Submitting a Trade Reference Number of a previously submitted trade or of a trade that may have been confirmed outside DTCC, together with a Trade Reference Number Supplement plus the full trade details.


Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be Fully Terminated; a matched confirmation of the Full Termination transaction does not constitute a confirmation of the information from the original trade. 2.2.2 Full Termination – Equity Swap For an Equity Swap, there are two available forms of representing the trade to terminate:


2. Submitting a Trade Reference Number of a previously submitted trade or of a trade that may

have been confirmed outside DTCC, together with a Trade Reference Number Supplement plus the full trade details.

Note that there is no third alternative for Equity Swap i.e. a “brief” form of representing the trade as there is for Equity Option. Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be Fully Terminated; a matched confirmation of the Full Termination transaction does not constitute a confirmation of the information from the original trade. 2.2.3 Full Termination – Equity Variance Swap For a Variance Swap, there are two available forms of representing the trade to terminate:




Note that there is no third alternative for Variance Swap i.e. a “brief” form of representing the trade as there is for Equity Option. Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be Fully Terminated; a matched confirmation of the Full Termination transaction does not constitute a confirmation of the information from the original trade. 2.2.4 Full Termination – Dividend Swap For a Dividend Swap, there are two available forms of representing the trade to terminate:




Note that there is no third alternative for Dividend Swap i.e. a “brief” form of representing the trade as there is for Equity Option. Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be Fully Terminated; a matched confirmation of the Full Termination transaction does not constitute a confirmation of the information from the original trade. 2.2.5 Full Termination – Equity Dispersion Variance1 For a Dispersion Variance Swap, there are two available forms of representing the trade to terminate:

1. Submitting a Trade Reference Number2 of a previously submitted trade, together with a Trade Reference Number Supplement.

2. Submitting a Trade Reference Number of a previously submitted trade, together with a Trade

Reference Number Supplement plus the full trade details. Please refer DTCC DerivSERV Messaging Specification for more details. Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be Fully Terminated; a matched confirmation of the Full Termination transaction does not constitute a confirmation of the information from the original trade. 2.2.6 Full Termination – Equity Variance Option For a Variance Option, there are two available forms of representing the trade to terminate:




Note that there is no third alternative for Variance Option i.e. a “brief” form of representing the trade as there is for Equity Option. Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be Fully Terminated; a matched confirmation of the Full Termination transaction does not constitute a confirmation of the information from the original trade.

1 A dispersion trade which is confirmed outside of DTCC will not be supported for Full Termination in DTCC Deriv/SERV. 2 Trade Reference Number in a dispersion trade is a common identifier across all components.


2.3 Partial Termination For Equity Option, Equity Swap, Variance Swap and Dividend Swap, the DTCC Deriv/SERV system supports the matching of Partial Termination records. This includes the Partial Termination of trades that were previously submitted to the system, as well as the Partial Termination of trades that may have been confirmed outside DTCC. The submission of a Partial Termination must follow the rules in the “Message Architecture” document. Refer to the following sub-sections for specific additional rules that are relevant to each individual Equity product. 2.3.1 Partial Termination - Equity Option For an Equity Option, the DTCC Deriv/SERV system will accept a Partial Termination represented by including a set of additional information fields that further identify the trade that is being terminated. This set of additional information fields is required for a trade that was not previously submitted to DTCC and is optional for a trade that was previously submitted to the system. If one party to the Partial Termination includes the additional information fields, this does not require the counter party to do the same. The DTCC Deriv/SERV system will accept a Partial Termination record that has the following enumerated information fields (in addition to those always required per the “Message Architecture” document):

Original Trade Date Expiration Date Option Style Option Type Index (for Index Options) or Shares (for Share Options) Number of Options Buyer and Seller Strike Price Strike Price Currency (for Share Options) Settlement Currency Settlement Type

Strike Percent and Strike Date may be submitted instead of Strike Price and Strike Currency.

Note that the Number of Options field will contain the Outstanding Number of Options after the Termination, which must be the same value as that contained in the Outstanding Number of Options field in the Termination Provisions. This form of representing the trade to partially terminate is the 2nd of the three (3) allowable:

1. Submitting a Trade Reference Number of a previously submitted trade together with a Trade Reference Number Supplement.




Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be partially terminated; a matched confirmation of the Partial Termination transaction does not constitute a confirmation of the information from the original trade. 2.3.2 Partial Termination – Equity Swap For an Equity Swap, there are two available forms of representing the trade to partially terminate:




Note that there is no third alternative for Equity Swap i.e. a “brief” form of representing the trade as there is for Equity Option. Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be partially terminated; a matched confirmation of the Partial Termination transaction does not constitute a confirmation of the information from the original trade. 2.3.3 Partial Termination – Equity Variance Swap For an Equity Variance Swap, there are two available forms of representing the trade to partially terminate:




Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be partially terminated; a matched confirmation of the Partial Termination transaction does not constitute a confirmation of the information from the original trade. 2.3.4 Partial Termination – Equity Dividend Swap For an Equity Dividend Swap, there are two available forms of representing the trade to partially terminate:





Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be partially terminated; a matched confirmation of the Partial Termination transaction does not constitute a confirmation of the information from the original trade. 2.3.5 Partial Termination – Equity Variance Option For an Equity Variance Option, there are two available forms of representing the trade to partially terminate:




Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be partially terminated; a matched confirmation of the Partial Termination transaction does not constitute a confirmation of the information from the original trade.


2.4 Increase For Equity Option and Equity Swap (and not Variance Swap), the DTCC Deriv/SERV system supports the matching of Increase records. This includes the Increase of trades that were previously submitted to the system, as well as the Increase of trades that may have been confirmed outside DTCC. The submission of an Increase must follow the rules in the “Message Architecture” document. Refer to the following sub-sections for specific additional rules that are relevant to each individual Equity product. 2.4.1 Increase - Equity Option For an Equity Option, the DTCC Deriv/SERV system will accept an Increase represented by including a set of additional information fields that further identify the trade that is being increased. This set of additional information fields is required for a trade that was not previously submitted to DTCC and is optional for a trade that was previously submitted to the system. If one party to the Increase includes the additional information fields, this does not require the counter party to do the same. The DTCC Deriv/SERV system will accept an Increase that has the following enumerated information fields (in addition to those always required per the “Message Architecture” document):

Original Trade Date Expiration Date Option Style Option Type Index (for Index Options) or Shares (for Share Options) Number of Options Buyer and Seller Strike Price Strike Price Currency (for Share Options) Settlement Currency Settlement Type Strike Percent and Strike Date may be submitted instead of Strike Price and Strike Currency.

Note that the Number of Options field will contain the Outstanding Number of Options after the Increase, which must be the same value as that contained in the Outstanding Number of Options field in the Increase Provisions. This form of representing the trade to increase is the 2nd of the three (3) allowable:

1. Submitting a Trade Reference Number of a previously submitted trade together with a Trade Reference Number Supplement.




Note: the information from the original trade is supplied solely for the purpose of identifying the trade for which the Increase is being processed; a matched confirmation of the Increase transaction does not constitute a confirmation of the information from the original trade. 2.4.2 Increase – Equity Swap For an Equity Swap, there are two available forms of representing the trade to Increase:




Note that there is no third alternative for Equity Swap i.e. a “brief” form of representing the trade as there is for Equity Option. Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be Increase; a matched confirmation of the Increase transaction does not constitute a confirmation of the information from the original trade. 2.4.3 Increase – Equity Variance Option For an Equity Variance Option, there are two available forms of representing the trade to Increase:




Note: the information from the original trade is supplied solely for the purpose of identifying the trade to be Increase; a matched confirmation of the Increase transaction does not constitute a confirmation of the information from the original trade.


2.5 Amendment of a Confirmed Trade The parties to a trade may agree to amend its terms after it is confirmed. Amendments apply to all currently supported equity products. To evidence that agreement through the DTCC Deriv/SERV system, the parties will submit and match Amendment transaction records. Any terms of the original trade may be changed through the amendment process with the exception of the Product Type, Parties to the trade, the roles of Buyer and Seller, the roles of Equity Amount Payer and Floating Amount Payer (for Equity Swaps), and the Trade Reference Numbers. Amendment can be done on the entire dispersion trade or on individual Dispersion Index Variance Swap/Dispersion Share Variance Swap components. The submission of an Amendment must follow the rules in the “Message Architecture” document.

2.6 Assignment The DTCC Deriv/SERV system does not currently support the matching of Assignment transaction records for Equity Derivatives.

2.7 Exit From DTCC The DTCC Deriv/SERV system supports an Exit From DTCC message to enable firms to signal their intention to document changes to a confirmed trade outside the system.

The submission of an Exit must follow the rules in the “Message Architecture” document.


2.8 Workflow Fields Deriv/SERV transaction records may optionally include any of the below six fields that are designed to support Prime Broker Billing and other workflow functions. These fields will typically be used to organize, route and prioritize Deriv/SERV records. The “workflow fields” are all optional and nonmatching. The “workflow fields” are included in the templates for all transaction types, and may be updated by resubmission of the transaction record at any time until the transaction confirms. The “current” workflow fields for a specific transaction record at any given time, is the latest submitted set of workflow fields that were included on the specific transaction record. For many of the anticipated uses of the workflow fields, the data in these fields will be constant through the lifecycle of the deal. In other cases, these fields will contain distinct data for each post-trade transaction. Deriv/SERV will apply defaulting logic to allow users to carry-over values from the underlying trade record to the initial submission of each post-trade record. Deriv/SERV will also apply separate defaulting logic to allow users to carry-over values from the previous submission of any transaction record to the subsequent “Modify” submission. The following is the set of six fields:

1. Comment – Up to 250 characters of free-form text; will enable users to flag transactions for internal processes according to their own schemes, the Comment field will not be visible to the counterparty or included in the counterparty’s output records.

2. Super ID – An identifier that may be used to group or link related transactions, whether part of a

block, strategy, collateral link; or other group, modeled on the current transaction reference number (up to 40 characters).

3. Desk ID – Used to identify the desk that executed the transaction. Up to 50 characters of free-

form text.

4. Designated Party ID – Up to 20 characters of free-form text; may be used by prime brokers to identify the PB customer on a transaction. The entered value does not have to be a valid DTCC Participant Id.

5. E-trading TRN – Transaction reference identifier assigned to a transaction by an execution

platform; modeled on the current transaction reference number (up to 40 characters). The user will enter the TRN, not the name of the platform, in the record.

6. Broker Name – Up to 40 characters of free-form text for recording the name of the broker.


2.9 Backload The Backload transaction will be used to bilaterally re-document trades that were or could have previously been legally confirmed on an automated basis using the New Trade transaction. Backload transactions that are matched or affirmed will constitute legal re-documentation of those transactions. The Backload transaction must specify an indicator to identify the trade as a Backload transaction. The Backload transaction record can be used either for trades previously confirmed in the Deriv/SERV system or for trades never previously confirmed in the Deriv/SERV system. All supported New Trade products will be supported as a Backload transaction with the same matching rules and validation; however the Backload indicator is a non matching field. A Backload transaction will be rejected when the Submitting Firm’s TRI already exists on a trade. The Submitting Firm TRI may be reused on a Backload transaction after a bilaterally confirmed Exit transaction has been confirmed. The Backload Indicator can be used on following Transaction Types for the following Product Types. Equity Index/Share Option: Trade, FullTermination, PartialTermination, or Increase. Equity Index/Share Swap: Trade, FullTermination, PartialTermination, or Increase. Equity Index/Share Variance Swap: Trade, FullTermination, PartialTermination. Equity Index/Share Dividend Swap: Trade, FullTermination, PartialTermination. Equity Dispersion Swap: Trade. Please refer the “Messaging Architecture” Technical specifications for more details.


3 Transaction Life Cycle The Transaction Life Cycle for Equity Derivatives follows the rules in the “Message Architecture V 5.0” document. Note that DTCC Deriv/SERV does not support the matching of Assignment records for Equity Derivatives.

4 Validation Criteria The Validation Criteria for Equity Derivatives follow the rules in the “Message Architecture V 5.0” document.

5 Communication - Data Transmission

Please see the “Message Architecture” document and the “Deriv/SERV User Technical Specifications – MQ Standards” document for details on data communications and transmissions.

6 Hours of Operation

The DTCC Derivative Matching and Confirmation System will be available 24x6, beginning Sunday at 3pm (NY time) / 8pm (UK time).


7 Schema Diagrams and Rules This section describes the use of the Deriv/SERV XML schemas for generating and receiving computer-to-computer transaction messages. The following documentation convention will be used:

1. XML element names will be displayed bold face

2. XML attribute names will be displayed in italics.

3. The term “must” is used to indicate a mandatory element or attribute. Note that the schema may not require the element as mandatory; in these instances the DTCC Deriv/SERV business rules mandate the use of the element or attribute.

4. The term “must not” is used to prohibit the use of an element or attribute. Note that the schema may allow the element or attribute; however, DTCC business rules prohibit the element or attribute use.

5. The term “may” is used to indicate an optional element or attribute. Often these elements or attributes may have business rules that make them conditionally required (i.e. required dependant on usage.) Careful reading of this documentation will indicate conditional requirements.

6. This documentation will be best used in conjunction with the sample messages and schemas provided under separate cover.

7. The bulk of the schemas are discussed in the “Message Architecture” document; these rules are generally true for all OTC Derivative product types (including Equity Derivatives.) The specific rules for the Trade representation of Equity Derivatives is detailed here, as are any exceptions to the “Message Architecture” documentation.

8. The schema diagrams contain printer friendly labels to display the usage of the elements that are described in the text below the schema diagrams. If there is a discrepancy in the usage of the elements between the labels and the text, the text will be held to be correct. Only Diagrams and parts of diagrams that are specific to Equity Derivatives are labeled. The labels mean the following:

a. R means that an element is required. b. NA means that an element is not allowed. c. O means that an element is optional. d. C means that an element is conditionally used.

9. When using the labels to read a schema diagram, it must be understood that they are following

the FpML tree structure. For example, in the image below the settlementRateSource element is optional and its parent element parYieldCurveUnadjustedMethod is conditional. Thus, the settlementRateSource element only becomes optional when the parYieldCurveUnadjustedMethod element is used. If the parYieldCurveUnadjustedMethod element is not used, then the settlementRateSource element is not allowed. Following this logic, the quotationRateType element will only become required when the parYieldCurveUnadjustedMethod element is used.


10. The schema diagram labels also contain numbers (as displayed in the image above) that match

the FpML elements to their counterparts in the Spreadsheet Upload Documentation as listed in Appendix A. Please note that Appendix A can also be used to match the Spreadsheet Upload Documentation fields to their counterparts in the FpML.


7.1 Trade

The Trade element consists of either contain the FpML and EquityAdditionalFields elements or the TradeReferenceInfo element. The details for the TradeReferenceInfo element are found in the “Message Architecture” document. The ShortDefaults attribute and the bond element are not allowed. The following sections describe the contents of the FpML element for each of the individual Equity Derivative products. See Section 7.2 for Equity Option, Section 7.3 for Equity Swap, and Section 0 for Equity Variance Swap. The EquityAdditionalFields element is defined in section 7.1.1 below.


7.1.1 EquityAdditionalFields

The EquityAdditionalFields element must contain either the EquityOptionFields or the EquitySwapFields elements. The EquityOptionFields element may only be used for an Equity Option and it may contain the Rule15a-6 element or the StrikeDate element. The Rule15a-6 element must have a value of true or false. The StrikeDate element may only be populated when


trade.equityOptionTransactionSupplement.strike.strikePercentage (see section 7.2.2) is populated. The StikeDate element must follow the XML date convention of YYYY-MM-DD. For a Cliquet Option or when the sub product type is “Cliquet”, the strikeDate element is not allowed. The EquitySwapFields element may only be used for an Equity Swap. When used the EquitySwapFields element it may contain the Rule15a-6 element or FinalFee element, StrikeDate, HedgingParty, InitialPriceElection, DividendSettlementCurrency, NonCashDividendTreatment, DividendComposition, BreakFeeElection, BreakFeeRate, InterpolationPeriod, OptionalEarlyTerminationElectingParty, OptionalEarlyTerminationDate, RollOverCommission, BreakFundingRecovery, IndexDisruption, Compounding, DeterminingParty, ReferencePriceSource, ReferencePricePage, ReferencePriceTime. The Rule15a-6 element must have a value of true or false. The FinalFee element may be used only when the master confirmation type is “GlobalMCA”. The FinalFee element is described in below section.

The StrikeDate element must contain the XML date convention of YYYY-MM-DD. For a Share Swap, the StrikeDate element may only be used for “ISDA2009EquityEuropean”. For an Index Swap, the StrikeDate element may only be used for "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean".

For a Share Swap, the HedgingParty element may only be used when the Master Confirmation Type is "ISDA2009EquityEuropean" or ISDA2009EquityInterdealerPanAsia". For an Index Swap, the HedgingParty element may only be used when the Master Confirmation Type is "ISDA2009EquityEuropean". HedgingParty element can occur twice in the EquitySwapFields element one HedgingParty element for party and the other element for counterparty.

For Share and Index Swap, the InitialPriceElection element may only be used when the StrikeDate is populated and not allowed otherwise. When it is used, the InitialPriceElection must contain a value of “HedgeExecution” or “AgreedInitialPrice” or "Close".

For Share Swap, the DividendSettlementCurrency element may only be used when the Master Confirmation Type is "ISDA2009EquityEuropean" and not allowed otherwise. When it is used, the DividendSettlementCurrency must contain a value of “IssuerPaymentCurrency” or "SettlementCurrency". The DividendSettlementCurrency element is not allowed for Index Swap. For Share Swap, the TreatmentofNon-CashDividends element may only be used when the Master Confirmation Type is "ISDA2009EquityEuropean" and is not allowed otherwise. When it is used, the TreatmentofNon-CashDividends must contain a value of “CashEquivalent”, "PotentialAdjustmentEvent". The TreatmentofNon-CashDividends element is not allowed for Index Swap. For Share Swap, CompositionofDividends element may only be used when the Master Confirmation Type is "ISDA2009EquityEuropean" and is not allowed otherwise. When it is used, the CompositionofDividends must contain a value of “EquityAmountReceiverElection” or “CalculationAgentElection”. The CompositionofDividends element is not allowed for Index Swap. For Share Swap, BreakFeeElection element may only be used when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia". The BreakFeeElection element is allowed only when Early Termination Right is Y and the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia".


For Index Swap, BreakFeeElection element may only be used when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia". The BreakFeeElection element is allowed only when Early Termination Right is populated with Y and if Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia". When it is used the BreakFeeElection must contain "FlatFee”, “AmortizedFee”, “FundingFee”, “FlatFeeAndFundingFee” or “AmortizedFeeAndFundingFee”. For Share Swap, the BreakFeeRate element must be used only when the BreakFeeElection is populated. The BreakFeeRate element is not allowed when BreakFeeElection is "Funding Fee" and when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia". Also, when the Master Confirmation Type is "EquityAsia", BreakFeeRate may be used and is not allowed for other Master Confirmation Types. For Index Swap, the BreakFeeRate element must be used only when the BreakFeeElection is populated. The BreakFeeRate element is not allowed when the BreakFeeElection is "Funding Fee" and the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean". Also, when the Master Confirmation Type is "EquityAsia", BreakFeeRate may be used and is not allowed for other Master Confirmation Type. For Share Swap, the LinearInterpolationPeriod element may only be used when the Master Confirmation Type is "ISDA2009EquityEuropean" and Linear Interpolation is "LinearZeroYield" and is not allowed otherwise. For Index Swap, the LinearInterpolationPeriod element may only be used when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" and Linear Interpolation is "LinearZeroYield" and is not allowed otherwise. When it is used the LinearInterpolationPeriod must contain “Initial” or “InitialAndFinal”. For Share and Index Swap, the elements - OptionalEarlyTerminationElectingParty and OptionalEarlyTerminationDate must not be used when the Early Termination Right is populated with N and is otherwise allowed. OptionalEarlyTerminationElectingParty element can occur twice in the EquitySwapFields element one OptionalEarlyTerminationElectingParty element for party and the other element for counterparty. Allowable values in the OptionalEarlyTerminationDate element are “AnyDay”, “ValuationDate”, “ResetDate” or “AfterFirstResetDate”. For Share and Index Swap, the RollOverCommission element may only be used when the Master Confirmation Type is "EquityAsia" and is not allowed for other Master Confirmation Type. For Index Swap, the BreakFundingRecovery element may only be used when the Master Confirmation Type is "ISDA2009EquityAmericas" and is not allowed otherwise. The BreakFundingRecovery element is not allowed for Share Swap. For Index Swap, IndexDisruption and Compounding element may only be used when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" and is not allowed otherwise. When it is used IndexDisruption must contain “Postponement” and “CalculationAgentAdjustment”. The IndexDisruption and Compounding is not allowed for Share Swap. For Share Swap, the elements DeterminingParty may only be used when the Master Confirmation Type is "ISDA2009EquityInterdealerPanAsia" and is not allowed for other Master Confirmation Type otherwise. The DeterminingParty is not allowed for Index Swap. The DeterminingParty element can occur twice in the EquitySwapFields element one DeterminingParty element for party and the other element for counterparty.


For Share Swap, the ReferencePriceSource may only be used when the Master Confirmation Type is "ISDA2009EquityInterdealerPanAsia" and is not allowed for other Master Confirmation Type otherwise. When present the ReferencePriceSource element it must contain the “BankOfCanada”, “BankOfJapan”, “Bloomberg”, “FederalReserve”, “FHLBSF”, “ISDA”, “Reuters”, “SAFEX”, or “Telerate” For Share Swap, the elements ReferencePricePage and ReferencePriceTime may only be used when ReferencePriceSource is populated and is not allowed otherwise. The ReferencePricePage is an alphanumeric field with a length upto 255 characters. When present the ReferencePriceTime element, it must contain the reference price timing information in HH:MM:SS format.


7.1.2 FinalFee Element

The FinalFee element may only be used when masterConfirmationType is “GlobalMCA”. The FinalFee element implements an fpML type of paymentDetail and may contain either a paymentAmount element or a paymentRule element. The paymentAmount element contains a currency element and amount element. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”. The specified currency must adhere to this scheme by being a valid ISO 4217 currency. The paymentRule element is used to represent the Final Fee as a percentage of the Notional Amount. The following diagram illustrates the PercentageRule data type, which is the actual type that the paymentRule element assumes as described below:


When the paymentRule element is used, it must include the xsi:type attribute with the value “PercentageRule” (xsi:type="PercentageRule"). This “types” the abstract paymentRule with the PercentageRule type. The paymentRule element must include the paymentPercent element, which must contain a decimal number with up to five (5) decimal places. For example, enter 0.05 for 5%. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore, paymentPercent values of "0.05" and "0.05000" will match. The value of the paymentPercent element may not be zero (0.00000). The paymentRule element must also include the notionalAmountReference element. The notionalAmountReference must be an empty element that must include the href attribute. The value of the href attribute must be “equityNotionalAmount”. This is a pointer to the id attribute in the equityNotionalAmount element described the above section.


7.2 FpML - Equity Option

he FpML element has an abstract content model allowing for several types of message to be included in

Tthis base, encompassing element. The generic details for usage of the FpML element can be found in the “Message Architecture” document. The trade element contains the details of the Equity Option itself. This document primarily deals with the specifics for the trade.


7.2.1 FpML Trade Datatype

The FpML Trade datatype allows a common representation of many OTC Derivative products while using the same generic XML structure. The usage of the Trade datatype is detailed in the “Message Architecture” document. The product element is abstract and has a unique representation for each OTC Derivative product type; the details of the product element for Equity Options is represented as the concrete element equityOptionTransactionSupplement.


7.2.2 FpML equityOptionTransactionSupplement Element


For Equity Index Option and Equity Share Option, the equityOptionTransactionSupplement FpML product element type must replace the product abstract element. The id attribute must be included with the value “equityOption”. The productType element and productId elements are not allowed in DTCC Deriv/SERV. The buyerPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the option buyer. The sellerPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the option seller. The optionType element must contain the text “Call” or “Put”. For a Cliquet3 Option, the optionType element must be “Call”. The equityEffectiveDate element may not be used. The index or share that is the underlyer of the option is identified using the underlyer component, which is explained in the next section. For Spread4 option, the notional element must be included when the numberOfOptions element is not known; otherwise optional. For Cliquet option, the notional element is required. When included the notional element it must include the amount element and the currency element. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”. The currency must adhere to this scheme by being a valid ISO 4217 currency. The amount element may have a value up to two places after the decimal point. The exercise provisions for the option are specified in the equityExercise component that is described in a following section. DTCC Deriv/SERV supports American and European style options. The feature element will be described in Section 7.2.5 The fxFeature element will be described in section 7.2.6. The strategyFeature elements may not be used. The strike element must either contain a strikePrice element or a strikePercentage element. The strikePercentage element may only be used for an “ISDA2007EquityEuropean”, ”ISDA2008EquityAmericas” or "ISDA2009EquityAmericas" or “EquityAmericas” or “EquityEuropean”,” ISDA2008EquityOptionAsiaExcludingJapan” or “ISDA2008EquityOptionAsiaExcludingJapanRev1” MCA, which is used for a forwarding starting option. When the strikePrice element is used, it is the level of the 3 Sub Product type “Cliquet” for a EquityIndexOption is introduced in Version 6.0. See the Messaging Architecture technical specifications for SubProductType element. 4 Sub Product type “Spread” for a EquityIndexOption is introduced in Version 6.0. See the Messaging Architecture technical specifications for SubProductType element.


index for an Index Option and the share price for a Share Option. The strikePrice element must contain a number with 0 to 7 decimal places. Additionally, the currency element must only be provided for a Share Option when the Strike Price is populated. When provided, the currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217” and the strike currency that must adhere to this scheme by being a valid ISO 4217 currency. The currency element may not be used for an Index Option. For Cliquet option, the strike element must contain the strikePrice element. The strikePercentage element.is not allowed for a Cliquet Option. The spotPrice element may not be used. The numberOfOptions element must specify the number of options in the option transaction. This is a decimal value that may contain up to five places after the decimal point. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore values of "100.5" and "100.50000" will match. For a Spread Option; If the value for numberOfOptions element is not known, users must submit a value “0.0099” to indicate the value is not known. DTCC will ignore the numberOfOptions element when it is “0.0099”. The outbound message will contain the value submitted in inbound message to DTCC. For Cliquet option, the numberOfOptions5 element must always be “0.0099”. DTCC will ignore the numberOfOptions element when it is “0.0099”. The equityPremium component specifies the amount and timing of the premium payment that is made for the equity option. It is described in Section 7.2.6 For Spread option, the indexPrice element must be included; otherwise not allowed. When included the indexPrice element must contain a decimal value upto eleven whole number with seven decimal places. The exchangeLookAlike element may only be used for an “ISDA2007EquityEuropean”. When it is used, the exchangeLookAlike element must contain a value of “true” for applicable and “false” for Not Applicable. For Cliquet option, the exchangeLookAlike element is not allowed. The exchangeTradedContractNearest element must not be used. The multipleExchangeIndexAnnexFallback element must only be used for an “ISDA2007EquityEuropean” Index Options and is optional for “ISDA2008EquityOptionAsiaExcludingJapan” or "ISDA2008EquityOptionAsiaExcludingJapanRev1" MCA not allowed otherwise. When it is used, the multipleExchangeIndexAnnexFallback element must contain a value of “true” for applicable and “false” for Not Applicable. For Cliquet option, the multipleExchangeIndexAnnexFallback element is not allowed.

5For a Cliquet Option, the value of the numberOfOptions element must always be “0.0099” through out the life cycle of the trade. DTCC Deriv/SERV overwrites the value of numberOfOptions to “0.0099” in out bound messages.


The methodOfAdjustment elements may not be used. The localJurisdiction element must only be used for an “ISDA2005EquityAsiaExcludingJapanInterdealer”, “ISDA2005EquityAsiaExcludingJapanInterdealerRev2” and EquityAsia Equity Share, and is not allowed otherwise. The localJurisdiction element must contain one of the following values: 'India", "Indonesia", "Korea", "Malaysia", "Taiwan", ”Thailand”,“China”,”Pakistan”,”Vietnam”,”Afghanistan”,”Hong Kong”,”Japan”,Singapore”,”Australia”,”New Zealand”,”Philippines“ and "NotApplicable". The optionEntitlement element must be used for an ISDA2005EquityAsiaExcludingJapanInterdealer or EquityAsia or ISDA2008EquityOptionAsiaExcludingJapan "ISDA2005EquityAsiaExcludingJapanInterdealerRev2" or "ISDA2008EquityOptionAsiaExcludingJapanRev1" Share Option, and is optional for all other MCAs. The optionEntitlement element must be omitted for an Index Option. This is a decimal value that may contain up to five places after the decimal point. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore values of "100.5" and "100.50000" will match. The multiplier element may only be used for an Index Option and must contain whole number values. 7.2.3 FpML underlyer Element

The underlyer element must contain the singleUnderlyer element. The basket element must not be used. The singleUnderlyer element must contain one of the types that derive from and substitute for underlyingAsset since the underlyingAsset element is abstract. For an Index Option, the index element must be used in place of underlyingAsset. The index element is described in Section 7.2.3.1. For a Share Option, the equity element must be used in place of underlyingAsset. The equity element is described in Section 7.2.3.2. The openUnits and dividendPayout elements must not be used.


7.2.3.1 FpML index Element

The index element must be used for an Index Option and must not be used for a Share Option. The index element must omit the id attribute and must contain an instrumentId element. The instrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier is case sensitive. The RIC identifier must not include the exchange code as a suffix. The exchange code is contained in the exchangeId element or constituentExchangeId elements, as explained below. The description, currency, clearanceSystem, and definition elements must not be used. The index element must include either a single exchangeId element or two (2) or more constituentExchangeId elements. The exhangeId element and constituentExchangeId elements must not be used at the same time. The exchangeId element, when included, must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier. The REC identifier is case sensitive. The exchangeId element is optional when the Master Confirmation Type is “ISDA2008EquityAmericas” “ISDA2009EquityAmericas”, GlobalMCA. For a Cliquet Option, the exchangeId element must be present. The constituentExchangeId elements, when included, must each contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier. Up to ten (10) constituentExchangeId elements can be included at the same time, but no less than two (2) can be specified at the same time. In the event that there is only


a single Exchange for the asset being traded, the ExchangeId element should be used. The REC identifier is case sensitive. The index element may optionally include one or more relatedExchangeId elements when the Master Confirmation Type is “ISDA2005EquityJapaneseInterdealer”, "ISDA2005EquityAsiaExcludingJapanInterdealer", ”ISDA2008EquityOptionAsiaExcludingJapan”,”ISDA2008EquityOptionJapan”, "ISDA2009EquityInterdealerPanAsia", "ISDA2009EquityAmericas"; otherwise, the relatedExchangeId element(s) are required. Each relatedExchangeId element must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier or the text “ALL” to denote All Exchanges or the text “N/A” to denote not applicable. The REC identifier is case sensitive. Deriv/SERV allows a mamium of 10 relatedExchangeId elements. For a Cliquet Option, the relatedExchangeId element is optional. The index element must also include the futureId element if the futuresPriceValuation element is included in the equityExercise component with the value of “true”. The futureId element must then contain a futureIdScheme attribute with the value “ExchangeTradedContract” and must contain the month and year of the futures contract. This must be in the format of MMYY. For example, June 2004 would be represented with ‘0604’. If the futuresPriceValuation element is not included in the equityExercise component, or it is included with the value of “false”, then the futureId element must not be used.


7.2.3.2 FpML equity Element

The equity element must be used for a Share Option and must not be used for an Index Option. The equity element must omit the id attribute and must contain an instrumentId element. The instrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier must include the exchange code as a suffix. The RIC identifier is case sensitive. The description, currency, exchangeId, clearanceSystem and definition elements must not be used. The equity element may optionally include one or more relatedExchangeId elements when the Master Confirmation Type is “ISDA2005EquityJapaneseInterdealer”, ”ISDA2008EquityOptionAsiaExcludingJapan”,”ISDA2008EquityOptionJapan”, “ISDA2005EquityAsiaExcludingJapanInterdealer", "ISDA2005EquityAsiaExcludingJapanInterdealerRev2" or "ISDA2008EquityOptionAsiaExcludingJapanRev1", "ISDA2009EquityInterdealerPanAsia", "ISDA2009EquityAmericas"; otherwise, the relatedExchangeId element is required. The relatedExchangeId element must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier or the text “ALL” to denote All Exchanges or the text “N/A” to denote not applicable. The REC identifier is case sensitive. Deriv/SERV allows a maximum of 10 relatedExchangeId elements. The optionsExchangeId element must not be used.


7.2.4 FpML equityExercise Element

The equityExercise element must contain either the equityEuropeanExercise element for a European style option, or the equityAmericanExercise element for an American style option, or the equityBermudaExercise element for a Bermuda style option. This is the way that FpML specifies the Option Style. These elements are described in the following sub-sections and each component contains the exercise details that are relevant to that particular style. The equityForwardExercise element must not be used. For a Cliquet Option, the equityBermudaExercise element is not allowed. The automaticExercise element must be provided and must always contain the value “true”. The prePayment element may not be used. The equityValuation element must be provided, but may be an empty element. For an "ISDA2007EquityEuropean" MCA, the equityValuation element may only contain the futuresPriceValuation element.


For all other MCAs, the equityValuation element may optionally be used to provide the Averaging Date(s) and/or to specify whether Futures Price Valuation is applicable (for both Share and Index Option) as explained in a following sub-section. The settlementDate element is not allowed for an ISDA2007EquityEuropean" or “ISDA2008EquityAmericas” or "ISDA2009EquityAmericas" MCA when the settlementType element (see below) has a value of "Physical". For all other MCAs, the settlementDate element may optionally be used as explained in a following sub-section. The settlementCurrency element must be provided and it must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the settlement currency that must adhere to this scheme by being a valid ISO 4217 currency.The value of settlementCurrency must be “USD” if the Master Confirmation Type is “ISDA2008EquityAmericas” or “ISDA2009EquityAmericas”. The settlementPriceSource element must not be used. The settlementType element must always be provided. For an Index Option, the settlementType element must contain the value “Cash”. For a Share Option, the settlementType element must contain the value “Cash”, “Physical”, or “Election”. The value of settlementType must be “Physical” if the Master Confirmation Type is “ISDA2008EquityAmericas” or "ISDA2009EquityAmericas". The settlementMethodElectionDate element may not be used. The settlementMethodElectingPartyReference may optionally be used if the value contained in the settlementType element is “Election”. When used, the settlementMethodElectingPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the option buyer or the party element that defines the option seller.


7.2.4.1 FpML equityEuropeanExercise Element

The equityEuropeanExercise element must be provided for a European-style option and must not be used otherwise. The equityEuropeanExercise element must omit the id attribute and must contain the expirationDate element. The expirationDate element must omit the id attribute and releativeDate element. The expirationDate element must contain the adjustableDate element that in turn must omit the id attribute and must contain the unadjustedDate element with the expiration date. The date must follow the XML date convention of YYYY-MM-DD. Additionally the adjustableDate must contain the dateAdjustments element. The dateAdjustments element must omit the id attribute and must contain the businessDayConvention element with the value “NONE” and may not contain the businessCentersReference and businessCenters elements. The equityExpirationTimeType element must be provided and must always contain the value “Close”, meaning the official closing time of the exchange. The equityExpirationTime element must not be used.


7.2.4.2 FpML equityAmericanExercise Element

The equityAmericanExercise element must be provided for an American-style option and must not be used otherwise. The equityAmericanExercise element must omit the id attribute and must contain the commencementDate element that must always be the same date as provided in the tradeDate element in the tradeHeader however for “ISDA2008EquityAmericas” or "ISDA2009EquityAmericas" MCA the commencementDate can be any date which follow the XML date convention of YYYY-MM-DD.When trade.equityOptionTransactionSupplement.strike.strikePercentage is populated (this represents a forward


starting option) on an “ISDA2007EquityEuropean” or “ISDA2008EquityAmericas” or "ISDA2009EquityAmericas" or “EquityAmericas” or “EquityEuropean” MCA, commencementDate element that must always be the same date as provided in the EquityAdditionalFields.EquityOptionFields.StrikeDate element. The commencementDate element must omit the id attribute and relativeDate element. The commencementDate element must contain the adjustableDate element that in turn must omit the id attribute and must contain the unadjustedDate element with the commencement date. The date must follow the XML date convention of YYYY-MM-DD. As stated earlier, this must be the trade date unless it is a forward starting “ISDA2007EquityEuropean” or “ISDA2008EquityAmericas” option. Additionally, adjustableDate must contain the dateAdjustments element. The dateAdjustments element must omit the id attribute and must contain the businessDayConvention element with the value “NONE” and may not contain the businessCentersReference and businessCenters elements. The equityAmericanExercise element must contain the expirationDate element. The expirationDate element must omit the id attribute and releativeDate element. The expirationDate element must contain the adjustableDate element that in turn must omit the id attribute and must contain the unadjustedDate element with the expiration date. The date must follow the XML date convention of YYYY-MM-DD. Additionally, the adjustableDate element must contain the dateAdjustments element. The dateAdjustments element must omit the id attribute and must contain the businessDayConvention element with the value “NONE” and may not contain the businessCentersReference and businessCenters elements. The expirationDate element must not contain the relativeDate element. The latestExerciseTime element must not be used. The latesExerciseTimeType element must be provided and must always contain the value “Close”, meaning the official closing time of the exchange. The equityExpirationTimeType element must be provided and must always contain the value “Close”, meaning the official closing time of the exchange. The equityExpirationTime element must not be used. The equityMultipleExercise component is optional and is used when Multiple Exercise is applicable for an American-style option. When the equityMultipleExercise element is provided, it must contain the integralMultipleExercise element with a decimal value. The number of options that can be exercised on a given exercise date is equal to the decimal value that is specified in the integralMultipleExercise element, or an integral multiple of this value. When the equityMultipleExercise element is provided, it must contain the minimumNumberOfOptions element with the minimum number of options that can be exercised on a given exercise date. It must also contain the maximumNumberOfOptions element with the maximum number of options that can be exercised on a given exercise date. DTCC DerivSERV requires that the value in maximumNumberOfOptions be the same as the value in the equityOptionTransactionSupplement.numberOfOptions element.


7.2.4.3 FpML equityBermudaExercise Element


The equityBermudaExercise element must be provided for a Bermuda-style option and must not be used otherwise. The equityBermudaExercise element must omit the id attribute and must contain the commencementDate element that must always be the same date as provided in the tradeDate element in the tradeHeader. The commencementDate element must omit the id attribute and relativeDate element. The commencementDate element must contain the adjustableDate element that in turn must omit the id attribute and must contain the unadjustedDate element with the commencement date. The date must follow the XML date convention of YYYY-MM-DD. Additionally; the adjustableDate must contain the dateAdjustments element. The dateAdjustments element must omit the id attribute and must contain the businessDayConvention element with the value “NONE” and may not contain the businessCentersReference and businessCenters elements. The equityBermudaExercise element must contain the expirationDate element that must always be the same date as provided in the tradeDate element in the tradeHeader. The expirationDate element must omit the id attribute and releativeDate element. The expirationDate element must contain the adjustableDate element that in turn must omit the id attribute and must contain the unadjustedDate element with the expiration date. The date must follow the XML date convention of YYYY-MM-DD. Additionally; the adjustableDate element must contain the dateAdjustments element. The dateAdjustments element must omit the id attribute and must contain the businessDayConvention element with the value “NONE” and may not contain the businessCentersReference and businessCenters elements. The expirationDate element must not contain the relativeDate element. The latestExerciseTime element must not be used. The equityBermudaExercise element must contain the bermudaExerciseDates element The bermudaExerciseDates element will be used to specify the list of exercise dates The bermudaExerciseDates element must include potential exercise dates in the date element.DTCC Deriv/SERV does not allow more than 20 exercise dates. The date element must follow the XML date convention of YYYY-MM-DD. The latestExerciseTimeType element must be provided and must always contain the value “Close”, meaning the official closing time of the exchange. The equityExpirationTimeType element must be provided and must always contain the value “Close”, meaning the official closing time of the exchange. The equityExpirationTime element must not be used. The equityMultipleExercise component is optional and is used when Multiple Exercise is applicable for an Bermudan-style option. When the equityMultipleExercise element is provided, it must contain the integralMultipleExercise element with a decimal value. The number of options that can be exercised on a given exercise date is equal to the decimal value that is specified in the integralMultipleExercise element, or an integral multiple of this value. When the equityMultipleExercise element is provided, it must contain the minimumNumberOfOptions element with the minimum number of options that can be exercised on a given exercise date. It must also contain the maximumNumberOfOptions element with the maximum number of options that can be exercised on a given exercise date. DTCC DerivSERV requires that the value in maximumNumberOfOptions be the same as the value in the equityOptionTransactionSupplement.numberOfOptions element.


7.2.4.4 FpML equityValuation Element

The equityValuation element must be provided, but may be an empty element if Averaging Dates and FuturesPriceValuation fields are not being specified. The equityValuation element must always contain the id attribute with the value “Valuation”. The reason for this is to enable the use of a pointer-style reference for Settlement Date, which is stated elsewhere as a date that is relative to valuation. The equityValuation element must not contain the valuationDate element. The valuationDates element must be omitted for an "ISDA2007EquityEuropean" or “ISDA2008EquityAmericas” or “ISDA2009EquityAmericas” MCA and is otherwise optional. The valuationDates element will be used to specify the Averaging Dates as a list of dates or in regular frequencies. The valuationDates element may include either the adjustableDates element or the periodicDates element. The adjustableDates element must be used to represent Averaging Dates in list and the periodicDates element must be used to represent Averaging Dates in regular frequencies. When included the adjustableDates element in the valuationDates element, it must contain id attribute with the value “averagingDates“ and one or more unadjustedDate elements; with each unadjustedDate element containing a single date value that must follow the XML date convention of YYYY-MM-DD. The maximum number of dates is 20. The dates should be submitted in ascending date order to facilitate matching. The adjustableDates element must also include the dateAdjustments element. The dateAdjustments element must omit the id attribute, must contain the businessDayConvention element with the value “NONE”.


For a Equity Index Option/Equity Share Option, Spread Option and Cliquet Option, the businessDayConvention element must contain one of the following values

• FOLLOWING • MODFOLLOWING • PRECEDING • NONE

And the businessDayConvention element must not contain the businessCentersReference and businessCenters elements.

When included the periodicDates element in the valuationDates element, it must include the calculationStartDate element, the calculationEndDate element, the calculationPeriodFrequency element and the calculationPeriodDatesAdjustments element. The calculationStartDate and the calculationEndDate elements must include the adjustableDates element. The adjustableDates element must include unadjustedDate element containing a single date value that must follow the XML date convention of YYYY-MM-DD. The adjustableDates element must also include the dateAdjustments element. The dateAdjustments element must omit the id attribute, must contain the businessDayConvention element with the value “NotApplicable”, and must not contain the businessCentersReference and businessCenters elements.


The calculationPeriodFrequency element must omit the id attribute. The calculationPeriodFrequency element must include the following elements:

periodMultiplier the integer number to indicate number of days/months/years between the valuationDates.

period must be one of the constant values “D”,”M”,”Y”.“D” indicating the periodMultiplier is for days, “M” indicating the periodMultiplier is for months, “Y” indicating the periodMultiplier is for years.

rollConvention must be either the value "EOM" or any integer from 1 to 30 when the value of the period is “M” or “Y”, when the period value is “W” the rollConvention must be one of the following "MON", "TUE", "WED", "THU", "FRI", "SAT", "SUN", when the period value is “D” the rollConvention must be “NONE”

The calculationPeriodDatesAdjustments element must omit the id attribute, must contain the businessDayConvention element with the value “NONE”. For a Equity Index Option/Equity Share Option, Spread Option and Cliquet Option, the businessDayConvention element must contain one of the following values

• FOLLOWING • MODFOLLOWING • PRECEDING • NONE

and the businessDayConvention element must not contain the businessCentersReference and businessCenters elements. The valuationTimeType and valuationTime elements may not be used. The futuresPriceValuation element is an optional element that can contain the value “true” to specify that Futures Price Valuation is Applicable, or the value “false” to specify that Futures Price Valuation is Not Applicable. The futuresPriceValuation element may only be used for an Index Option and must not be used for a Share Option. For a Cliquet option, the numberOfValuationDates element must be provided; otherwise not allowed. When included the numberOfValuationDates element must contain a decimal value


7.2.4.5 FpML settlementDate Element

The settlementDate element is not allowed for a share “ISDA2007EquityEuropean" or “ISDA2008EquityAmericas” or “ISDA2009EquityAmericas” MCA when trade.equityOptionTransactionSupplement.equityExercise.settlementType element (see below) has a value of "Physical". For index and all other share MCAs, the settlementDate element is an optional element that may be used to specify the settlement date as a date that is relative to the valuation date in terms of number of business days after the valuation date. When used, the settlementDate element must omit the id attribute and must not contain the adjustableDate element. The settlementDate element must contain the relativeDate element. The relativeDate element must omit the id attribute and must contain the periodMultiplier element with the number of days as an integer, and the period element with the value “D”. The dayType element must not be used. The businessDayConvention element must be included with the value “NONE”. The businessCentersReference and businessCenters elements must not be used. The dateRelativeTo element must be included and must be an empty element that must include the href attribute. The href attribute must contain the value “Valuation”, which is a pointer-style reference to the equityValuation element indicating that the date is relative to the relevant valuation date.


7.2.5 FpML feature Element

When included the feature element inside equityOptionTransactionSupplement element, it may include the asian element or the barrier element. The asian element is described in section 7.2.5.1. The barrier element is described in section 7.2.5.2 The knock element is described in section 7.2.5.3 All other remaining elements must not be used.


7.2.5.1 FpML asian Element

When included the asian element, it must include the averagingInOut element with a value “Out” indicating it’s a Averaging Price Option. The strikeFactor and the averagingPeriodIn elements must not be used. The asian element may include the averagingPeriodOut element. The averagingPeriodOut element is described in section 7.2.5.1.1. For a Cliquet Option, the asian element is not allowed.


7.2.5.1.1 FpML averagingPeriodOut Element

The averagingPeriodOut element may include the averagingWeight element if Averaging Dates are represented in list (equityValuation.valuationDates.adjustableDates) and Option style is “European”(equityExercise. equityEuropeanExercise), otherwise not allowed; and the averagingPeriodOut element must include the marketDisruption element. When included the averagingWeight element it must include href attribute with the value “averagingDates” and must include one or more weightPercentage elements. Deriv/SERV allows a maximum of 20 weightPercentage elements. The weightPercentage element must contain a decimal value up to five whole numbers with five (5) decimal places. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore values of "1.5" and "1.50000" will match. The marketDisruption element must include marketDisruptionScheme attribute with the value “http://www.fpml.org/coding-scheme/market-disruption“and always hold one of the following values.

• Postponement • Omission • ModifiedPostponement

For a Barrier Option, the averagingPeriodOut element may include the marketDisruption element if Averaging Dates are represented in equityValuation.valuationDates. (Either in frequency or list).


7.2.5.2 FpML barrier Element

The barrier element must be included when the sub product type is “Spread”; or when the optionType is “Call” and the sub product type is “Cliquet”; otherwise not allowed. For Spread Option, the barrier element may contain the barrierCap element and/or the barrierFloor element. The barrierCap element must be included when the optionType is “Call”, otherwise not allowed.


The barrierFloor element must be included when the optionType is “Put”, otherwise not allowed. When included the barrierCap element it must include trigger element which in turn must include either the level element or levelPercentage element. When included the level element it must include a positive decimal value upto eleven whole numbers with seven decimal places. ”. The levelPercentage element must contain a decimal value up to five whole numbers with five (5) decimal places. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore values of "1.5" and "1.50000" will match When included the barrierFloor element it must include trigger element which in turn must include either the level element or levelPercentage element. When included the level element it must include a positive decimal value upto eleven whole numbers with seven decimal places. ”. The levelPercentage element must contain a decimal value up to five whole numbers with five (5) decimal places. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore values of "1.5" and "1.50000" will match All other remaining elements must not be used in barrierCap or barrierFloor elements. For a Cliquet Option or when the sub product type is “Cliquet”; the barrierCap element must be include. When included the barrierCap element;it must include the trigger element which in turn must include the levelPercentage element. The levelPercentage element must contain a decimal value up to five whole numbers with five (5) decimal places. All other remaining elements must not be used in barrierCap element.The barrierFloor element must not be used for a “Cliquet” option.


7.2.5.3 FpML knock Element

The knock element must be included when the sub product type is “Barrier”; otherwise not allowed. For Barrier Option, the knock element may contain the either the knockIn element or the knockOut element. When included the knockIn element or knockout element must include the schedule element and the trigger element. The schedule element is used to describe the determination days in frequency representation. When present the schedule element, it must contains the startDate, the endDate and the averagingPeriodFrequency element. All other fields of the schedule element are not used.


The startDate will be used to represent First Knock-in/Knock-out Determination Day and the endDate will be used to represent Last Knock-in/Knock-out Determination Day and must follow the XML date convention of YYYY-MM-DD. The averagingPeriodFrequency element must contain the periodMultipler, the period and the rollConvention element. The averagingPeriodFrequency element must include the following elements:



rollConvention must be either the value "EOM" or any integer from 1 to 30 when the value of the period is “M” or “Y”, when the period value is “W” the rollConvention must be one of the following "MON", "TUE", "WED", "THU", "FRI", "SAT", "SUN", when the period value is “D” the rollConvention must be “NONE

The trigger element must include the level element which indicates either the share/index price level. The level element must include a positive decimal value upto eleven whole numbers with seven decimal places. The trigger element must include the triggerType and the triggerTimeType elements. The creditEvents element and the currency element must not be used. When included the triggerType element, it must hold one of the following values .

• EqualOrLess • EqualOrGreater • Less • Greater

When included the triggerTimeType element, it must hold one of the following values.

• Closing • Anytime


7.2.5.4 FpML fxFeature Element

The fxFeature element may only be used for an “ISDA2005EquityAsiaExcludingJapanInterdealer” MCA or “ISDA2008EquityOptionAsiaExcludingJapan” or “EquityAsia” or "ISDA2005EquityAsiaExcludingJapanInterdealerRev2" or "ISDA2008EquityOptionAsiaExcludingJapanRev1" MCA when the settlementType element does not have a value as “Physical”, otherwise the fxFeature element must not be included. The fxFeature element should also not be included for a vanilla settlement type. For Cliquet option, the fxFeature element is not allowed. The fxFeature element, when present, must include the referenceCurrency element if either the composite element, quanto element or crossCurrency element is included. The referenceCurrency element must have a currencyScheme attribute with the value”http://www.fpml.org/ext/iso4217". When the composite element is used, the referenceCurrency element must contain valid ISO currency. The composite element must omit the determinationMethod element and the relativeDate element. The composite element may contain the fxSpotRateSource element, which is defined in the next section. When the quanto element is used, the referenceCurrency element must contain the value “NotApplicable”. When a crossCurrency element is used, the referenceCurrency element must contain valid ISO currency. crossCurrency element must omit the determinationMethod element and the relativeDate


element. The composite element may contain the fxSpotRateSource element, which is defined in the next section.

7.2.5.5 FpML fxSpotRateSource Element

The fxSpotRateSource element must contain the primaryRateSource element and the fixingTime element. The fxSpotRateSource element may contain the secondaryRateSource element. For a Cliquet Option, the fxSpotRateSource element is not allowed. The primaryRateSource element must contain the rateSource element, and may optionally contain the rateSourcePage element and rateSourcePageHeading element. The rateSource element must include the informationProviderScheme attribute with the value “http://www.fpml.org/spec/2007/information-provider”. The value that is used for the rateSource element must adhere to this scheme and some valid values are “BankOfCanada”, “BankOfJapan”, “Bloomberg”, “FederalReserve”, “FHLBSF”, “ISDA”, “Reuters”, “SAFEX”, or “Telerate”. The rateSourcePage element must omit the rateSourcePageScheme attribute. The secondaryRateSource element must contain the rateSource element, and may optionally contain the rateSourcePage element and rateSourcePageHeading element. The rateSource element must include the informationProviderScheme attribute with the value “http://www.fpml.org/spec/2007/information-provider”. The value that is used for the rateSource element must adhere to this scheme and some valid values are “BankOfCanada”, “BankOfJapan”, “Bloomberg”, “FederalReserve”, “FHLBSF”, “ISDA”, “Reuters”, “SAFEX”, or “Telerate”. The rateSourcePage element must omit the rateSourcePageScheme attribute. The fixingTime element must contain the hourMinuteTime element and the businessCenter element. The hourMinuteTime element must contain a time specified in hh:mm:ss format where the second component must be '00'. The businessCenter element must include the businessCenterScheme attribute with the value “http://www.fpml.org/spec/2007/business-center” and the value contained in the


businessCenter element must adhere to this scheme. The businessCenter element must omit the id attribute. 7.2.6 FpML equityPremium Element

The payerPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the option buyer. Note that the premium payer must always be the option buyer. The receiverPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the option seller. Note that the premium receiver must always be the option seller.


The premiumType element must not be used. The paymentAmount element must be provided and it must contain the amount element with the aggregate premium, and the currency element. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the premium currency. The premium currency must adhere to this scheme by being a valid ISO 4217 currency. The amount element may have up to two places after the decimal point. From a DTCC matching perspective, there will be a matching tolerance of one currency unit. The paymentDate element may be provided for an “ISDA2007EquityEuropean” MCA and must be provided for all other MCAs. When the paymentDate element is used, it must omit the id attribute and must contain the unadjustedDate with the premium payment date. The date must follow the XML date convention of YYYY-MM-DD. Additionally, paymentDate must contain the dateAdjustments element. The dateAdjustments element must omit the id attribute and must contain the businessDayConvention element with the value “NONE” and may not contain the businessCentersReference and businessCenters elements. For a Cliquet Option, the paymentDate element must be provided. The swapPremium, pricePerOption, and percentageOfNotional elements must not be used.


7.2.7 FpML collateral Element

The use of the collateral element within the trade element is optional. When the collateral element is used, the collateral element must contain the independentAmount element. The independentAmount element must contain the payerPartyReference, the receiverPartyReference, and a single paymentDetail element. The payerPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the independent amount payer. The receiverPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the independent amount receiver. The paymentDetail element must omit the adjustablePaymentDate and the adjustedPaymentDate elements. The paymentDetail element must include either the paymentAmount element or the paymentRule element. The paymentAmount element is used to represent the Independent Amount as a currency amount. The paymentRule element is used to represent the Independent Amount as a percentage of the Notional Amount. When the paymentAmount element is used, the paymentAmount element must include the currency and the amount elements. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency. The amount element value may have up to two places after the decimal point. The paymentRule element may be used instead of the paymentAmount element. The following diagram illustrates the PercentageRule data type, which is the actual type that the paymentRule element assumes as described below:


When the paymentRule element is used, it must include the xsi:type attribute with the value “PercentageRule” (xsi:type="PercentageRule"). This “types” the abstract paymentRule with the PercentageRule type. The paymentRule element must include the paymentPercent element, which must contain a decimal number with up to seven (7) decimal places. For example, enter 0.05 for 5%. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore, paymentPercent values of "0.05" and "0.0500000" will match. The value of the paymentPercent element may not be zero (0.0000000). The paymentRule element must also include the notionalAmountReference element. The notionalAmountReference must be an empty element that must include the href attribute. The value of the href attribute must be “Valuation”. This is a pointer to the id attribute in the equityValuation element, and is just a general reference to the option, since the base amount for the percentage is not directly contained in the transaction record.


7.2.8 FpML documentation Element

The documentation element within the trade element is used to specify the dates of the master confirmation agreement and the type of master confirmation used for this supplemental transaction. The documentation element must contain a masterConfirmation element. The documentation element may also contain one or more occurances of contractualTermsSupplement elements. The documentation element may not include a masterAgreement, brokerConfirmation, contractualDefinitions, contractualSupplement, contractualMatrix or creditSupportDocument element. The masterConfirmation element must contain a masterConfirmationType element. The value of the masterConfirmationType element must be one of:

ISDA2004EquityAmericasInterdealer 2004EquityEuropeanInterdealer

ISDA2005EquityJapaneseInterdealer ISDA2005EquityAsiaExcludingJapanInterdealer EquityAsia ISDA2007EquityEuropean EquityAmericas EquityEuropean ISDA2008EquityAmericas ISDA2008EquityOptionAsiaExcludingJapan ISDA2008EquityOptionJapan


ISDA2009EquityAmericas ISDA2008EquityOptionAsiaExcludingJapanRev1 ISDA2005EquityAsiaExcludingJapanInterdealerRev2

For a Cliquet Option, the masterConfirmationType element must be “"CliquetAndRainbow". The masterConfirmation element must contain a masterConfirmationDate element. The value of the masterConfirmationDate element must follow the XML date pattern YYYY-MM-DD convention. By DTCC Deriv/SERV business rules this must be a valid date. The masterConfirmation element may contain a masterConfirmationAnnexDate element. The optional masterConfirmationAnnexDate must follow the XML date pattern YYYY-MM-DD convention. By DTCC Deriv/SERV business rules this must be a valid date. The contractualTermSupplement element may be included for an “ISDA2005EquityAsiaExcludingJapanInterdealer” and “EquityAsia” transaction to specify the Annex Amendment Date. When included, the contractualTermsSupplement element must contain the type element and the publicationDate element. The type element must have a value of “AnnexAmendment”. The publicationDate must follow the XML date pattern YYYY-MM-DD convention. By DTCC Deriv/SERV business rules this must be a valid date. The contractualTermSupplement element may be included to specify that the Canadian Supplement is applicable if the underlying master confirmation is “ISDA2004EquityAmericasInterdealer” or “EquityAmericas”. When included, the value of the type element in contractualTermSupplement element must be:

• “ISDAMarch2004EquityCanadianSupplement” For Share Option only, the contractualTermSupplement element may be included to specify that either Full or Partial Lookthrough is applicable to the trade. When included, the value of the type element in the contractualTermSupplement element must be either:

• “ISDA2007FullLookthroughDepositoryReceiptSupplement” • “ISDA2007PartialLookthroughDepositoryReceiptSupplement”

Full and/or Partial Lookthrough may be specified for any underlying master confirmation. Only one of "ISDA2007FullLookthroughDepositoryReceiptSupplement" or "ISDA2007PartialLookthroughDepositoryReceiptSupplement" may be specified, not both. For a Cliquet Option, the contractualTermSupplement element is not allowed.


7.3 FpML - Equity Swap

The FpML element has an abstract content model allowing for several types of message to be included in this base, encompassing element. The generic details for usage of the FpML element can be found in the “Message Architecture” document. The trade element contains the details of the Equity Swap itself. This document primarily deals with the specifics for the trade.



The FpML Trade datatype allows a common representation of many OTC Derivative products while using the same generic XML structure. The usage of the Trade datatype is detailed in the “Message Architecture” document. The product element is abstract and has a unique representation for each OTC Derivative product type; the detail of the product element for Equity Swap is represented as the concrete element equitySwapTransactionSupplement. When masterConfirmationType is “ISDA2009EquityInterdealerPanAsia”, maximum of 2 partyReference can be specified as calculationAgent.


7.3.2 FpML equitySwapTransactionSupplement Element

For Equity Share Swap and Equity Index Swap, the equitySwapTransactionSupplement product element must replace the abstract product element. The id attribute and the productType, productId, buyerPartyReference, sellerPartyReference and multipleExchangeIndexAnnexFallback elements must not be included. The returnSwapLeg element is abstract and must be replaced by including one returnLeg element and possibly one interestLeg element. The legs must follow the order of returnLeg element first and an optional interestLeg element second. However, the interestLeg element must not be included for a Fully Funded Swap or when Future Price Valuation is applicable. The principalExchangeFeatures element is defined in 7.3.5 and used for Fully Funded Equity Swaps.


The mutualEarlyTermination element must not be included when Mutual Early Termination Right is “true” (“Applicable”). The reason for this is that the Mutual Early Termination Right that is specified in the Master Confirmation Agreement will always be applicable unless specified in the record as not applicable. The mutualEarlyTermination element must be included with the value “false” when the Mutual Early Termination Right that is specified in the Master Confirmation Agreement is not applicable. In sum, the only valid value for the mutualEarlyTermination element is “false”. The mutualEarlyTermination element must not be included when the MCA is “ISDA2007EquityFinanceSwapEuropean” or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1. The multipleExchangeIndexAnnexFallback element is optional when masterConfirmationType is “GlobalMCA”. When included it must include the value ‘true’ or ‘false’, otherwise its not allowed. The localJurisdiction element must only be used for an “ISDA2005EquityAsiaExcludingJapanInterdealer” or “ISDA2005EquityAsiaExcludingJapanInterdealerRev2” Share Equity Swap; and is optional for an "ISDA2009EquityInterdealerPanAsia". It is not allowed otherwise. The localJurisdiction element must contain one of the following values: 'India", "Indonesia", "Korea", "Malaysia", "Taiwan",”Thailand”,“China”,”Pakistan”,”Vietnam”,”Afghanistan”,”Hong Kong”,”Japan”,Singapore”,”Australia”,”New Zealand”,”Philippines“ and "NotApplicable". For a Share Swap, the extraordinaryEvents element may be included when masterConfirmationType is “ISDA2009EquityAmericas”. When included the extraordinaryEvents element, it must include the additionalDisruptionEvents element which in turn may include the maximumStockLoanRate element and the initialStockLoanRate element. The maximumStockLoanRate element and the initialStockLoanRate elements can hold upto 5 whole numbers with 5 decimal places. For an Index Swap, the maximumStockLoanRate element is optional when Master Confirmation Type is "GlobalMCA" or "ISDA2009EquityAmericas". For a index Swap, the initialStockLoanRate element is optional when the Master Confirmation Type is "ISDA2009EquityAmericas". For an Index Swap, the extraordinaryEvents element may be included when masterConfirmationType is “ISDA2009EquityAmericas”. When included the extraordinaryEvents element, it must include the additionalDisruptionEvents element which in turn may include the insolvencyFiling element, lossOfStockBorrow element and the increasedCostOfStockBorrow element. When insolvencyFiling, lossOfStockBorrow or increasedCostOfStockborrow are included they must contain the value ‘true’ or ‘false’.


7.3.3 FpML returnLeg Element


The returnLeg element describes the Equity Leg of the Swap, and must be included within the equitySwapTransactionSupplement element in place of the abstract returnSwapLeg element. The returnLeg element will precede the optional interestLeg element. The interestLeg element describes the Floating Leg of the Swap when present. The legIdentifier attribute must not be included. The payerPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the equity leg payer. The receiverPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the equity leg receiver. The paymantFrequency element must not be included. The effectiveDate element must include the id attribute with the value “equityEffectiveDate”. The effectiveDate element must include the adjustableDate element and must omit the relativeDate element. The adjustableDate element must omit the id attribute and must include the unadjustedDate element and the dateAdjustments element. The unadjustedDate element must follow the XML date convention of YYYY-MM-DD. The dateAdjustments element must omit the id attribute, must include the businessDayConvention element, and must omit both the businessCenterReference and businessCenters element. The value of the businessDayConvention element must be ”NONE”. The Termination Date is not required for the Deriv/SERV system but is required by FpML. Therefore, the Termination Date will always be included as “zero days after the final Cash Settlement Payment Date”. The FpML usage is as follows: The terminationDate element must omit the id attribute and the adjustableDate element, and must include the relativeDate element. The relativeDate element must omit the id attribute and the dayType, businessCentersReference, and businessCenters elements. The relativeDate element must include the periodMultiplier, period, businessDayConvention, and dateRelativeTo elements. The periodMultiplier element must have the value “0”. The period element must have the value “D”. The businessDayConvention element must have the value ”NONE”. The dateRelativeTo element must be an empty element that must include an href attribute with the value “finalCashSettlementPaymentDate”. The underlyer element usage is explained in Section 7.3.3.1 The rateOfReturn element usage is explained in Section 7.3.3.2 The notional element must include the id attribute with the value “equityNotionalAmount”. For Share Swap, the Equity Notional Amount and Equity Notional Currency are optional when the Master Confirmation Type is "ISDA2009EquityEuropean". For an Index Swap, the Equity Notional Amount and Equity Notional Currency are optional when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean". When the Equity Notional Amount and Equity Notional Currency are NOT available , the relativeNotionalAmount element must be populated in the notional element. Therefore, relativeNotionalAmount element will be used ONLY when the master confirmation type is "ISDA2009EquityEuropean" or “ISDA2007EquityEuropean”. The relativeNotionalAmount element must contain a href attribute with the value “equityNotionalAmount”.


The notional element must not include the determinationMethod and amountRelativeTo elements. The notional element must include the notionalAmount element. The notionalAmount element must omit the id attribute, and must include the currency and amount elements. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency. The amount element will contain a decimal value that may have up to two places after the decimal point. The amount element usage is described in Section 7.3.3.3 The return element usage is described in Section 7.3.3.4 The notionalAdjustments element is required and must have a value of “Standard”. The fxFeature element may be used for an “ISDA2005EquityAsiaExcludingJapanInterdealer” or “ISDA2005EquityAsiaExcludingJapanInterdealerRev2” Equity Index/Share Swap, and not allowed otherwise. The fxFeature element may contain either an empty composite or a crossCurrency element for index/share swap to indicate the settlement type in case of ‘GlobalMCA’. For all other MCA types, the fxFeature element will omit both the elements. The fxFeature element must contain the referenceCurrency and the quanto elements. The referenceCurrency element must have the same currency as the equitySwapTransactionSupplement.returnLeg.notional.notionalAmount.currency. The quanto element must contain the fxRate element and must omit the fxSpotRateSource element. The fxRate element must contain the quotedCurrencyPair and the rate elements. The quotedCurrencyPair element must contain the currency1, currency2 and quoteBasis elements. The currency1 element must have the same currency as the referenceCurrency (mentioned earlier in this paragraph), and the currency2 element must have the same currency as the equitySwapTransactionSupplement. returnLeg.amount.paymentAmount.currency. The quotaBasis element must have the value “Currency1PerCurrency2”. The rate element is a decimal value that may contain up to five places after the decimal point. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore values of "100.5" and "100.50000" will match. The returnLeg element must include the notionalAdjustments element with the value “Standard”. The averagingDates element is described in section 7.3.3.5


7.3.3.1 FpML underlyer Element

The underlyer element must contain the singleUnderlyer element. The basket element must not be used. The singleUnderlyer element must contain one of the types that derive from and substitute for underlyingAsset since the underlyingAsset element is abstract. For an Index Swap, the index element must be used in place of underlyingAsset. The index element is described in Section 7.3.3.1.2. For a Share Swap, the equity element must be used in place of underlyingAsset. The equity element is described in Section 7.3.3.1.1. For a Share Swap, when the masterConfirmationType is “ISDA2009EquityAmericas” or "EquityAmericas", the underlyer element may include the averageDailyTradingVolume element. When included the averageDailyTradingVolume element, it must include the limitationPeriod element and the limitationPercentage element. When included the limitationPeriod element it must include a positive number without any decimal places. The limitationPercentage element must contain a decimal value up to five whole numbers with five (5) decimal places. For a Share Swap, when the masterConfirmationType is “ISDA2009EquityAmericas”, the underlyer element may include the depositoryReceipt element, which must have a value of “true” or “false” to represent whether the Depository receipt is applicable or not applicable. The openUnits element may be included for an Index Swap and must be included when Future Price Valuation is applicable and when the master confirmation type is "GlobalMCA", "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean". The openUnits element must be included for a Share Swap, to state the number of shares. The value may contain up to five decimal places. When the sub product type is “BulletCompounding6” for a Equity Index Swap, the openUnits element may be included. When masterConfirmationType is "ISDA2009EquityEuropean" or

6 Sub Product type “BulletCompounding” for a EquityIndexSwap/EquityShareSwap is introduced in Version 6.0. See the Messaging Architecture technical specifications for SubProductType element.


"ISDA2007EquityEuropean", the openUnits element must be included for Bullet compounding Index swap; For BulletCompounding share swap, the openUnits element must be included. The dividendPayout element, which is used to express the Dividend Percentage, must be omitted for an “ISDA2005EquityAsiaExcludingJapanInterdealer” Equity Swap, or when the returnLeg.return.returnType element contains the value “Price”. For Share swap, the dividendPayout element must be used for "ISDA2007EquityFinanceSwapEuropean" or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" when the returnLeg.return.returnType element contains the value “Total” (See Section7.3.3.4 for the returnType element). And the dividendPayout is optional when the returnLeg.return.returnType element contains the value “Total” and the master confirmation type is "EquityAsia", "GlobalMCA", "ISDA2009EquityInterdealerPanAsia", "EquityAmericas" or "EquityEuropean".. For Index swap, the dividendPayout element may be used ONLY when the returnLeg.return.returnType element contains the value “Total” (See Section7.3.3.4 for the returnType element) and master confirmation type is "EquityAsia" or "GlobalMCA" or "EquityAmericas" or "EquityEuropean". When provided, the dividendPayout element must include the dividendPayoutRatio element and must omit the dividendPayoutConditions element. The dividendPayoutRatio element will contain a decimal number with up to seven (7) decimal places. For example, enter 0.05 for 5%. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore, dividendPayoutRatio values of "0.05" and "0.0500000" will match. 7.3.3.1.1 FpML equity Element


The equity element must be used for a Share Swap and must not be used for an Index Swap. The equity element must omit the id attribute and must contain an instrumentId element. The instrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier must include the exchange code as a suffix. The RIC identifier is case sensitive. The description, currency, exchangeId, clearanceSystem and definition elements must not be used. The relatedExchangeId element in the equity element is optional for an ISDA2007EquityFinanceSwapEuropean” or “ISDA2008EquityFinanceSwapAsiaExcludingJapan”, "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1", "GlobalMCA" or "ISDA2009EquityInterdealerPanAsia" MCA, otherwise the equity element must include the relatedExchangeId element for share swap. The relatedExchangeId element in the equity element is optional for a "GlobalMCA" or "ISDA2009EquityAmericas" MCA, otherwise the equity element must include the relatedExchangeId element for index swap. The relatedExchangeId element must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier or the text “ALL” to denote All Exchanges or the text “N/A” to denote not applicable. The REC identifier is case sensitive. Deriv/SERV allows a maximum of 10 relatedExchangeId elements. The optionsExchangeId element must not be used.


7.3.3.1.2 FpML index Element

The index element must be used for an Index Swap, but is optional when masterConfirmationType is "GlobalMCA" or "ISDA2009EquityAmericas". The index element must not be used for a Share Swap. The index element must omit the id attribute and must contain an instrumentId element. The instrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier is case sensitive. The RIC identifier must not include the exchange code as a suffix. The exchange code is contained in the exchangeId element, as explained below. The description, currency, clearanceSystem, and definition elements must not be used. The index element must include either a single exchangeId element or two (2) or more constituentExchangeId elements. The exhangeId element and constituentExchangeId elements must not be used at the same time. The exchangeId element, when included, must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier. The REC identifier is case sensitive


The constituentExchangeId elements, when included, must each contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier. Up to ten (10) constituentExchangeId elements can be included at the same time, but no less than two (2) can be specified at the same time. In the event that there is only a single Exchange for the asset being traded, the ExchangeId element should be used. The REC identifier is case sensitive. The index element must also include the relatedExchangeId element. The relatedExchangeId element must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier or the text “N/A” to denote not applicable. The REC identifier is case sensitive. Deriv/SERV allows a mamium of 10 relatedExchangeId elements.. The index element must not include the futureId element.


7.3.3.2 FpML rateOfReturn Element


The valuation element must include the initialPrice element. The initialPrice element must omit the determinationMethod,grossPrice, accruedInterestPrice, clearNetPrice, quotationCharacteristics and valuationRule elements if netPrice element is included. The initialPrice element must include the netPrice element, and may only include the commission and fxConversion elements for an “EquityAsia” MCA. The netPrice element must include the currency element for an “EquityAsia” Share/Index Swap, “ISDA2007EquityFinanceSwapEuropean” or “GlobalMCA” Share Swap and it is optional for all other MCAs. The netPrice element must include the amount element with a value that may contain up to seven places after the decimal. When the Initial price is not available for "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" MCA type, then the amountRelativeTo element inside of initialPrice must be populated. The amountRelativeTo element must contain href attribute with the value “equityNotionalAmount”. For an "ISDA2007EquityFinanceSwapEuropean" MCA, the Initial Price Currency should have the same value as the Settlement Currency. The netPrice element must also include the priceExpression element with the value “AbsoluteTerms”. The fxConversion element will be defined in section 7.3.3.2.1. When included, the commsission element must include the commissionDenomination element with the value of “Percentage”, and the commissionAmount element must contain a percentage value with up to 7 decimal places. For example 5% would have the 0.05. The notionalReset element must be included, and must have a value of “true” when Equity Notional Reset is Applicable and a value of “false” when Equity Notional Reset is Not Applicable. The valuationPriceInterim element must be included and is described Section 7.3.3.2.1. The valuationPriceFinal element must not include the commission, amountRelativeTo, grossPrice, netPrice, accruedInterestPrice, fxConversion, and valuationRule elements. The valuationPriceFinal element must include the determinationMethod element with a value of “PriceAtValuation”. For a Share Swap, when the masterConfirmationType is “ISDA2009EquityAmericas” or "EquityAmericas", the determinationMethod element must contain the determinationMethodScheme with a value of “http://www.fpml.org/determination-method” and the determinationMethod element must hold one of the values “Closing Price”,”VWAP Price”. The paymentDates element may optionally be included for “ISDA2007EquityFinanceSwapEuropean” Share Swaps, otherwise it is required. When included, the paymentDates element must follow the rules as described in Section 7.3.3.2.3 The exchangeTradedContract element is detailed in the following Section .

http://www.fpml.org/determination-method


7.3.3.2.1 FpML fxConversion Element

The fxConversion element may only be used for an EquityAsia MCA Index/Share Swap, and is not allowed otherwise. The fxConversion element must omit the amountRelativeTo element and must contain the fxRate element. The fxRate element must contain the quotedCurrencyPair and the rate elements. The quotedCurrencyPair element must contain the currency1, currency2 and quoteBasis elements. The currency1 element is the Gross Price Currency, and the currency2 element must have the same currency as the equitySwapTransactionSupplement.returnLeg.rateOfReturn. initialPrice.netPrice.currency. The quotaBasis element must have the value “Currency1PerCurrency2”. The rate element is a decimal value that may contain up to five places after the decimal point. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore values of "100.5" and "100.50000" will match.


7.3.3.2.2 FpML valuationPriceInterim Element

The valuationPriceInterim element will be used to contain the list of up to 360 adjusted valuation dates. The specific usage is as follows: The valuationPriceInterim element must not include the commission, amountRelativeTo, grossPrice, netPrice, accruedInterestPrice, fxConversion, cleanNetPrice and quotationCharacteristics elements. The valuationPriceInterim element must include the determinationMethod with a value of “PriceAtValuation”.


The valuationPriceInterim element must include the valuationRules element. The valuationRules element must not include the valuationDate, valuationTimeType, valuationTime, and optionsPriceValuation elements. The valuationRules element must include the id attribute with a value of “equityValuationDates”, must include the valuationDates element and may include futuresPriceValuation element. The valuationDates element must omit the id attribute, and the


relativeDatesSequence element. The futuresPriceValuation element must be omitted for an “ISDA2005EquityAsiaExcludingJapanInterdealer” or "ISDA2007EquityFinanceSwapEuropean" or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2005EquityAsiaExcludingJapanInterdealerRev2" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia" and is otherwise optional for a Share Swap. The futuresPriceValuation element must be omitted for an “ISDA2005EquityAsiaExcludingJapanInterdealer” or "ISDA2005EquityAsiaExcludingJapanInterdealerRev2" and is otherwise optional for a Index Swap. When included, the futuresPriceValuation element must contain a value of “true”. The valuationDates element must include either the adjustableDates element or the periodicDates element. When included the adjustableDates element in the valuationDates element, it must contain one or more unadjustedDate elements; with each unadjustedDate element containing a single date value that must follow the XML date convention of YYYY-MM-DD. The maximum number of dates is 360. The dates should be submitted in ascending date order to facilitate matching. The adjustableDates element must also include the dateAdjustments element. The dateAdjustments element must omit the id attribute, must contain the businessDayConvention element with the value “NotApplicable”, and must not contain the businessCentersReference and businessCenters elements. When included the periodicDates element in the valuationDates element, it must include the calculationStartDate element, the calculationEndDate element, the calculationPeriodFrequency element and the calculationPeriodDatesAdjustments element. The calculationStartDate and the calculationEndDate elements must include the adjustableDates element. The adjustableDates element must include unadjustedDate element containing a single date value that must follow the XML date convention of YYYY-MM-DD. The adjustableDates element must also include the dateAdjustments element. The dateAdjustments element must omit the id attribute, may contain the businessDayConvention element to indicate the valuation date convention with a value of either "PRECEDING" or "FOLLOWING" or "MODFOLLOWING", and must not contain the businessCentersReference and businessCenters elements. The calculationPeriodFrequency element must omit the id attribute. The calculationPeriodFrequency element must include the following elements:




The calculationPeriodDatesAdjustments element must omit the id attribute, may contain the businessDayConvention element with a value of either "PRECEDING" or "FOLLOWING" or "MODFOLLOWING" or “NotApplicable”.


7.3.3.2.3 FpML paymentDates Element

The paymentDates element will be used to specify the Cash Settlement Payment Date as a number of days relative to the relevant valuation date. The specific usage is as follows: The paymentDates element must include the id attribute with a value of "CashSettlementPaymentDate", and must include the


paymentDatesInterim and paymentDateFinal elements. Each of these elements will contain the same Cash Settlement Payment Date information, as explained below. Essentially, the data is repeated twice because of the FpML requirements. For a Share Swap, when masterConfirmationType is “"ISDA2007EquityFinanceSwapEuropean" or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" or “GlobalMCA” the Cash Settlement Payment Date is optional otherwise required. For a Index Swap, when the masterConfirmationType is "GlobalMCA" or "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean", the Cash Settlement Payment Date is optional. It is not allowed when the masterConfirmationType is "ISDA2009EquityAmericas". For transactions where Cash Settlement Payment Date information is optional or not applicable, the paymentDates structure would still be required with the periodMultiplier element value as “0”. The periodMultiplier element must be “0” when masterConfirmationType is “GlobalMCA”. The paymentDatesInterim element must omit the id attribute and the adjustableDates element. The paymentDatesInterim element must include the relativeDates element. The relativeDates element must omit the id attribute, and must omit the businessCentersReference, businessCenters, periodSkip and scheduleBounds elements. The relativeDates element must include the periodMultiplier element with the integer number of days, the period element with a value of “D”, the dayType element with a value of “CurrencyBusiness”, and the businessDayConvention element with a value of “NONE”. The relativeDates element must also include the dateRelativeTo element, which must be an empty element that includes an href attribute with the value “equityValuationDates”. The paymentDateFinal element must include id attribute with the value “finalCashSettlementPaymentDate”. The paymentDateFinal element must omit the adjustableDate element, and must include the relativeDate element. The relativeDate element must omit the id attribute, and must omit the businessCentersReference and businessCenters elements. The relativeDate element must include the periodMultiplier element with the integer number of days. The periodMultiplier element must contain the same value as the equityPaymentDatesInterim.relativeDates.periodMultiplier element. The relativeDate element must include the period element with a value of “D”, the dayType element with a value of “CurrencyBusiness”, and the businessDayConvention element with a value of “NONE”. The relativeDate element must also include the dateRelativeTo element, which must be an empty element that includes an href attribute with the value “equityValuationDates”.


7.3.3.2.4 FpML exchangeTradedContract element

The exchangeTradedContractNearest element must only be included when Future Price Valuation (trade.equitySwapTransactionSupplement.returnLeg.rateOfReturn.valuationPriceInterim. futuresPriceValuation) has a value of “true”. When provided, the exchangeTradedContractNearest element must not include the id attribute, and the description, currency, exchangeId, clearenceSystem, definition, relatedExchangeId, optionsExchangeId, contractReference, and expirationDate elements. When provided, the exchangeTradedContractNearest element must include the instrumentId element and may include the multiplier element.


The instumentId element must include the instrumentIdScheme attribute with the value “MonthYearId”, and must contain the month and year of the futures contract. This must be in the format of MMYY. For example, June 2004 would be represented with “0604”. When the multiplier element is used, it must contain a positive integer. 7.3.3.3 FpML amount Element

The amount element (which substitutes the ReturnSwapAmount element) must include the paymentCurrency element. The paymentCurrency element must include the id attribute with the value “settlementCurrency”. The paymentCurrency element must omit the determinationMethod element, and must include the currency element. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency.


The equityAmount element must include the referenceAmount element with the value “StandardISDA”. The equityAmount element must not include the formula, encodedDescription, variance, and calculationDates elements. The equityAmount element must include the cashSettlement element with the value “true”. The equityAmount element must not include the optionsExchangeDividends and additionalDividends elements.


7.3.3.4 FpML return Element

The return element must include the returnType element with a value of either “Total” or “Price”. The value “Total” denotes a Total Return Swap, whereas the value “Price” denotes a Price Swap.


When the returnType element has a value of “Total”, the dividendConditions element must be included for an "ISDA2007EquityFinanceSwapEuropean" or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" or "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia" for share swap. The dividendConditions element may be included for "EquityAsia", "GlobalMCA", "ISDA2009EquityInterdealerPanAsia", "EquityAmericas" or "EquityEuropean" or "ISDA2009EquityAmerica" when returnType element has a value of “Total” for share swap. When the returnType element has a value of “Total”, the dividendConditions element may be included for "EquityAsia", "GlobalMCA", "EquityAmericas" or "EquityEuropean" or "ISDA2009EquityAmericas" or "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" for an Index Swap. When the returnType element has a value of “Price”, the dividendConditions element must not be provided for the “EquityAmericas”, “EquityEuropean”,"EquityAsia", “ISDA2005EquityAsiaExcludingJapanInterDealer” or “ISDA2007EquityFinanceSwapEuropean” or "ISDA2008EquityFinanceSwapAsiaExcludingJapan” or “ISDA2009EquityEuropean” MCAs. The dividendConditions element, when provided, must omit the dividendEntitlement, dividendPeriodEffectiveDate, dividendPeriodEndDate, extraOrdinaryDividends, excessDividendAmount, paymentCurrency, dividendFxTriggerDate, and interestAccrualsMethod elements. For an "ISDA2007EquityFinanceSwapEuropean" or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" or "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia" Equity Swap, the dividendConditions element, when present, must be constructed as follows:

1. When provided the dividendConditions element, it may contain the dividendAmount element, when the return.returnType element contains a value of “Total” and the Master confirmation type is "EquityAmericas", "EquityEuropean" or “EquityAsia”, otherwise not allowed. The valid values for the dividendAmount element are “RecordAmount”, “ExAmount”, and “PaidAmount”.

2. When provided the dividendConditions element it may contain the dividendPaymentDate element which in turn must omit the adjustableDate element and must contain the dividendDateReference element when the underlying MCA is "EquityAmericas", “ISDA2007EquityFinanceSwapEuropean”, "ISDA2008EquityFinanceSwapAsiaExcludingJapan", “ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1”, "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia" for a Share Swap.

The dividendDateReference element may be included when the underlying MCA is "EquityAmericas", "EquityEuropean", “EquityAsia” "ISDA2009EquityAmericas" or "ISDA2009EquityEuropean"for an Index Swap. The dividendDateReference element must contain one of the following values: “ExDate”, “DividendPaymentDate”, "RecordDate", "TerminationDate", "EquityPaymentDate", "FollowingPaymentDate", "AdHocDate", "CumulativeEquityPaid", "CumulativeLiborPaid", "CumulativeEquityExDiv", "CumulativeLiborExDiv", "SharePayment", "CashSettlementPaymentDate" or "FloatingAmountPaymentDate" or "CashSettlementPaymentDate-IssuerPayment".


When the Master confirmation type is "ISDA2008EquityFinanceSwapAsiaExcludingJapan" and "ISDA2007EquityFinanceSwapEuropean" and "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1", the allowable values are the dividendDateReference element is "SharePayment", "CashSettlementPaymentDate" or "FloatingAmountPaymentDate". When the Master confirmation type is "ISDA2009EquityInterdealerPanAsia", the allowable values in the dividendDateReference element are "SharePayment", "CashSettlementPaymentDate" or "CashSettlementPaymentDate-IssuerPayment". When provided the paymentDateOffset element, it must include the periodMultiplier and period elements. The paymentDateOffset element may be included if the dividendDateReference element has a value as “SharePayment”

3. The dividendConditions element may contain the determinationMethod element when the underlying MCA is “ISDA2007EquityFinanceSwapEuropean”, "ISDA2008EquityFinanceSwapAsiaExcludingJapan", “ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1” or "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia" or "EquityAsia" or "EquityAmericas" or "EquityEuropean",.

Allowable values in the determinationMethod element are “Close” or “HedgeExecution”.

For a Share Swap, the determinationMethod element is optional for "ISDA2007EquityFinanceSwapEuropean" or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" or "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia" or "EquityAsia" or "EquityAmericas" or "EquityEuropean" Master Confirmation Type, otherwise not allowed. For a Index Swap, the determinationMethod element is optional for "ISDA2009EquityEuropean" or " ISDA2007EquityEuropean" or "EquityAsia" or "EquityAmericas" or "EquityEuropean" Master Confirmation Type, otherwise not allowed.

4. When provided the dividendConditions element it may contain the dividendPeriod element and the

dividendPeriod element must contain a value that adheres to the FpML Dividend Period Enumeration. The valid values are “FirstPeriod”, and “SecondPeriod”.

The dividendPeriod element is optional when the return.returnType element contains a value of “Total” and the Master Confirmation Type is "EquityAmericas","EquityEuropean", “EquityAsia”, otherwise not allowed.

5. The dividendConditions element must contain the dividendReinvestment element when the

return.returnType element contains a value of “Total” and Master Confirmation Type is an “ISDA2005EquityAsiaExcludingJapanInterdealer” or “ISDA2005EquityAsiaExcludingJapanInterdealerRev2”. The dividendReinvestment element must contain a value of “true” or “false”. The dividendReinvestment element is not allowed for Index Swap.


6. The dividendConditions element must contain the declaredCashDividendPercentage element and may contain the declaredCashEquivalentDividendPercentage element when the master confirmation type is “ISDA2009EquityEuropean”. The declaredCashDividendPercentage or the declaredCashEquivalentDividendPercentage element must contain a decimal number with up to five (5) decimal places. For example, enter 0.05 for 5%. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore, values "0.05" and "0.05000" will match. The value of the declaredCashDividendPercentage/ declaredCashEquivalentDividendPercentage element may be zero (0.00000) and may be a negative value. For Share Swap, the declaredCashDividendPercentage element is optional when the Master Confirmation Type is “GlobalMCA”. It is required when the Master Confirmation type is "ISDA2009EquityEuropean" (share swap).

For Index Swap, the declaredCashDividendPercentage element must be provided when the Master Confirmation Type is "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" MCA. The declaredCashDividendPercentage element is optional for "ISDA2009EquityAmericas" or "GlobalMCA" (index swap). Otherwise it is not allowed. For a Index Swap, the declaredCashEquivalentDividendPercentage element is optional for "ISDA2009EquityAmericas" or "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" or "GlobalMCA" MCA. Otherwise it is not allowed. For a Share Swap, the declaredCashEquivalentDividendPercentage element is optional for "ISDA2009EquityEuropean" or "GlobalMCA" MCA. Otherwise it is not allowed.


7.3.3.5 FpML averagingDates Element

For a Share Swap,the averagingDates element may be included when the masterConfirmationType is "ISDA2009EquityAmericas" or "ISDA2004EquityAmericasInterdealer" or “EquityAmericas”. When included the averagingDates element it must include the schedule element to represent averaging dates in frequency. To represent averaging dates in list the averagingDateTimes element must be included. The schedule element must contain the startDate and the endDate elements must follow the XML date convention of YYYY-MM-DD. The schedule element must also include the averagingPeriodFrequency which in turn must include the following elements



rollConvention must be either the value "EOM" or any integer from 1 to 30 when the value of the period is “M” or “Y”, when the period value is “W” the rollConvention must be one of the following "MON", "TUE", "WED", "THU", "FRI", "SAT", "SUN", when the period value is “D” the rollConvention must be “NONE”.

When included the averagingDateTimes element, it must include the dateTime element. The format of the date in dateTime element must be “YYYY-MM-DDT00:00:00”.


7.3.4 FpML interestLeg Element


The interestLeg element is an optional element that must be either omitted completely or the included where the following rules apply: The interestLeg element describes the Floating Leg of the Swap, and is included within the equitySwapTransactionSupplement element in place of the abstract assetSwapLeg element. The interestLeg element must follow the equityLeg element that describes the Equity Leg of the Swap. The interestLeg element must be omitted when Future Price Valuation or Fully Funded is Applicable. For a BulletCompounding Swap or when the sub product type is “BulletCompounding7” for a Equity Swap, the interestLeg element must be present. The legIdentifier attribute must not be included. The payerPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the interest leg payer. The receiverPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the interest leg receiver. The interestLegCalculationPeriodDates element is described in the following Section 7.3.4.1 The notional element must not include the id attribute, and the determinationMethod and notionalAmount elements. The notional element must include the amountRelativeTo element. The amountRelativeTo element must be an empty element that must include the href attribute with the value “equityNotionalAmount”. The interestAmount element must not include the formula, encodedDescription, variance, and calculationDates elements. The interestAmount element must include the paymentCurrency and referenceAmount elements. The paymentCurrency element must not include the id attribute, the currency element, and the determinationMethod element. The paymentCurrency element must be an empty element that must include the href attribute with the value “settlementCurrency”. The referenceAmount element must contain the value “StandardISDA”. The interestCalculation element must be included and is described in Section 7.3.4.2 The stubCalculationPeriod element must not be used.



7.3.4.1 FpML interestLegCalculationPeriodDates Element


The InterestLegCalculationPeriodDates element must include the id attribute with the value “floatingCalculationPeriodDates”. The InterestLegCalculationPeriodDates element must also include the effectiveDate, terminationDate, InterestLegResetDates, and InterestLegPaymentDates elements. FpML requires the effective date to be specified on both legs of the Swap. In the Deriv/SERV system, these two dates must be the same. Therefore, the explicit date will be specified on the Equity Leg, and this date will be referenced in the Floating Leg. The following is the usage for the effectiveDate element of the Floating Leg. The effectiveDate element must not include the id attribute and the adjustableDate element, and must include the relativeDate element. The relativeDate element must not include the id attribute, and the dayType, businessCentersReference, and businessCenters elements. The relativeDate element must include periodMultiplier, period, businessDayConvention, and dayRelativeTo elements. The periodMultiplier element must have a value of “0” (zero). The period element must have a value of “D”. The businessDayConvention element must have a value of “NONE”. The dateRelativeTo element must be an empty element that must include an href attribute with the value “equityEffectiveDate”. The Termination Date is not required for the Deriv/SERV system but is required by FpML. Therefore, the Termination Date will always be included as “zero days after the final Cash Settlement Payment Date”. The FpML usage is as follows: The terminationDate element must omit the id attribute and the adjustableDate element, and must include the relativeDate element. The relativeDate element must omit the id attribute and the dayType, businessCentersReference, and businessCenters elements. The relativeDate element must include the periodMultiplier, the period, the businessDayConvention, and the dateRelativeTo elements. The periodMultiplier element must have the value “0”. The period element must have the value “D”. The businessDayConvention element must have the value ”NONE”. The dateRelativeTo element must be an empty element that must include an href attribute with the value “finalCashSettlementPaymentDate”. Reset Dates are not required for the Deriv/SERV system, but some minimal information is required by FpML. Therefore, the Reset Dates will always be included as “relative to the Calculation Period Start Date”. The FpML usage is as follows: The InterestLegResetDates element must not include the resetFrequency element, and must include the calculationPeriodDatesReference and resetRelativeTo elements. The calculationPeriodDatesReference element must be an empty element that includes an href attribute with the value “floatingCalculationPeriodDates”. The resetRelativeTo element must have a value of “CalculationPeriodStartDate”. The InterestLegPaymentDates element must be included and is described in Section 7.3.4.1.1.


7.3.4.1.1 FpML InterestLegPaymentDates Element


The InterestLegPaymentDates element may either contain the adjustableDates element or the relativeDates element or the periodicDates element. InterestLegPaymentDates element must omit the id attribute. The adjustableDates element will be used to contain a list of up to 360 adjusted payment dates. It will also be used to contain a list of up to five Business Centers. The specific usage is as follows: The adjustableDates element must include the adjustableDates element. The adjustableDates element must contain one or more unadjustedDate elements; with each unadjustedDate element containing a single date value that must follow the XML date convention of YYYY-MM-DD. The maximum number of dates is 360. The dates should be submitted in ascending date order to facilitate matching. The adjustableDates element must also include the dateAdjustments element. The dateAdjustments element must omit the id attribute, must contain the businessDayConvention element and may not contain the businessCentersReference element. The businessDayConvention element must have one of the following values: "FOLLOWING", "FRN”, “MODFOLLOWING", "PRECEDING", "MODPRECEDING", "NONE", "NotApplicable". For a Share Swap, the dateAdjustments element must omit the businessCenters element when the underlying MCA is “ISDA2007EquityFinanceSwapEuropean” or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" else it must contain the businessCenters element. The businessCenters element may be specified when masterConfirmationType is "GlobalMCA".The businessCenters element may be specified when masterConfirmationType is "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia" MCA and when InterestLegPaymentDates. adjustableDates or InterestLegPaymentDates. periodicDates is not populated, otherwise businessCenters is required. For an Index Swap, the businessCenters element may be specified when masterConfirmationType is "ISDA2009EquityAmericas" or "ISDA2007EquityEuropean" or "ISDA2009EquityEuropean" MCA and when InterestLegPaymentDates. adjustableDates or InterestLegPaymentDates. periodicDates is not populated, otherwise businessCenters is required. For a Share Bullet Compounding Swap, the businessCenters element may be specified when masterConfirmationType is "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia" MCA and when InterestLegPaymentDates. adjustableDates or InterestLegPaymentDates. periodicDates is not populated, otherwise businessCenters is required. For an Index Bullet Compounding Swap, the businessCenters element may be specified when masterConfirmationType is "ISDA2009EquityAmericas" or "ISDA2007EquityEuropean" or "ISDA2009EquityEuropean" MCA and when InterestLegPaymentDates. adjustableDates or InterestLegPaymentDates. periodicDates is not populated, otherwise businessCenters is required. The businessCenters element must omit the id attribute and must contain at least one, but not more than five, businessCenter elements. Each businessCenter element must omit the id attribute and must include a businessCenterScheme attribute with the value http://www.fpml.org/spec/2004/business-center. The value of the businessCenter element must be a valid four-character city code that adheres to this scheme. If InterestLegPaymentDates is not applicable or not available for any master confirmation type,the relativeDates element may be used Equity Share and Index Swap. When included the relativeDates


element must omit the id attribute, the dayType element, the businessCentersReference element, the periodSkip element, and the scheduleBounds element. The relativeDates element must contain the periodMultiplier, period, businessDayConvention and dateRelativeTo elements. The periodMultiplier element must have a value of “0” (zero). The period element must have a value of “D” (for day). The businessDayConvention element must have the value as "NotApplicable". The businessDayConvention element may not contain the businessCentersReference element. The dateRelativeTo element must contain the href attribute with value “CashSettlementPaymentDate”. The relativeDates element may contain the businessCenters element. The businessCenters element must omit the id attribute and must contain at least one, but not more than five, businessCenter elements. Each businessCenter element must omit the id attribute and must include a businessCenterScheme attribute with the value http://www.fpml.org/spec/2004/business-center. The value of the businessCenter element must be a valid four-character city code that adheres to this scheme. When included the periodicDates element in the InterestLegPaymentDates element, it must include the calculationStartDate element, the calculationEndDate element, the calculationPeriodFrequency element and the calculationPeriodDatesAdjustments element. The calculationStartDate and the calculationEndDate elements must include the adjustableDates element. The adjustableDates element must include unadjustedDate element containing a single date value that must follow the XML date convention of YYYY-MM-DD. The adjustableDates element must also include the dateAdjustments element. The dateAdjustments element must omit the id attribute, must contain the businessDayConvention element with the value “NotApplicable”, and must not contain the businessCentersReference and businessCenters elements. The calculationPeriodFrequency element must omit the id attribute. The calculationPeriodFrequency element must include the following elements:

periodMultiplier the integer number to indicate number of days/months/years between the Payment Dates.


rollConvention must be either the value "EOM" or any integer from 1 to 30 when the value of the period is “M” or “Y”, when the period value is “W” the rollConvention must be one of the following "MON", "TUE", "WED", "THU", "FRI", "SAT", "SUN", and when the period value is “D” the rollConvention must be “NONE”

The calculationPeriodDatesAdjustments element element must omit the id attribute, must contain the businessDayConvention element with the value “NotApplicable” The calculationPeriodDatesAdjustments element must omit the businessCenters element when the underlying MCA is “ISDA2007EquityFinanceSwapEuropean” or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" else it must contain the businessCenters element. The businessCenters element must omit the id attribute and must contain at least one, but not more than five, businessCenter elements. Each businessCenter element must omit the id attribute and must include a businessCenterScheme attribute with the value http://www.fpml.org/spec/2004/business-center.


The value of the businessCenter element must be a valid four-character city code that adheres to this scheme.

7.3.4.2 FpML interestCalculation Element

The interestCalculation element must omit the id attribute, the fixedRate element. The interestCalculation element must include the floatingRateCalculation and dayCountFraction elements.


The floatingRateCalculation element must include the id attribute with the value “floatingRateCalculation”, and the floatingRateMultiplierSchedule, rateTreatment, capRateSchedule, floorRateSchedule, initialRate, finalRateRounding, averagingMethod, and negativeInterestRateTreatment elements. The floatingRateCalculation element must include the floatingRateIndex, indexTenor, and spreadSchedule elements. The floatingRateIndex element must contain the floatingRateIndexScheme attribute with the value “http://www.fpml.org/ext/isda-2006-definitions”. The value of the floatingRateIndex element must adhere to this scheme of values. In addition to ISDA defined Floating Rate Options, DTCC DerivSERV will support other non ISDA defined Floating Rate Options. Please refer Appendix B for list of ISDA defined and non ISDA Floating Rate Option supported by DTCC DerivSERV. The indexTenor element must include the periodMultiplier and period elements and must not include the id attribute. The periodMultiplier element must contain an integer value. The period element must contain one of “D” (Days), “W” (Weeks), “M” (Months), or “Y” (Years). The spreadSchedule element must be included. The spreadSchedule element must include the initialValue element and must omit the type and step elements. The initialValue element must contain a decimal number with up to five (5) decimal places. For example, enter 0.05 for 5%. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore, initialValue values of "0.05" and "0.05000" will match. The value of the initialValue element may be zero (0.00000) and may be a negative value. The dayCountFraction element must include the dayCountFractionScheme attribute with the value "http://www.fpml.org/spec/2004/day-count-fraction", and the value of the dayCountFraction element must adhere to this scheme. The current valid values are 1/1, ACT/ACT.ICMA, ACT/ ACT.ISDA, ACT/ACT.ISMA, ACT/ACT.AFB, ACT/365.FIXED, ACT/360, 30/360,30E/360 and 30E/360.ISDA. For a BulletCompounding Swap or when the sub product type is “BulletCompounding8” for a Equity Swap,the compounding element must be included when the underlying master confirmation type is "EquityAmericas", "EquityEuropean", or "'EquityAsia". When included it must include the compoundingRate element and the compoundingSpread element.



The compoundingRate element must include the interestLegRate element with the href attribute value as “floatingRateCalculation”. The compoundingSpread element must contain a decimal value up to five whole numbers with five (5) decimal places. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore values of "1.5" and "1.50000" will match. The value of the compoundingSpread element may be zero (0.00000) and may be a negative value. For a Share Swap, the interpolationMethod element may be included when the master confirmation type is "ISDA2009EquityAmericas", "ISDA2009EquityEuropean", "GlobalMCA" or "ISDA2009EquityInterdealerPanAsia" or "EquityAmericas" and for an Index Swap, the interpolationMethod element may be included when masterConfirmationType is "GlobalMCA", "ISDA2009EquityAmericas" or "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean". When included the interpolationMethod element, it must include the attribute interpolationMethodScheme with the value “http://www.fpml.org/coding-scheme/interpolation-method” and the must hold the value either “LinearZeroYield" or “None”. The value ‘LinearZeroYield” indicates Linear interpolation is applicable and the value “None” indicates Linear interpolation is not applicable. 7.3.5 FpML principalExchangeFeatures Element

The principalExchangeFeatures element is used to represent a Fully Funded Swap. The principalExchangeFeatures element must be omitted for an “ISDA2005EquityAsiaExcludingJapanInterdealer” or “ISDA2007EquityFinanceSwapEuropean” or "ISDA2008EquityFinanceSwapAsiaExcludingJapan" or "ISDA2005EquityAsiaExcludingJapanInterdealerRev2" or "ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1" or “GlobalMCA” or "ISDA2009EquityEuropean" or "ISDA2009EquityInterdealerPanAsia" and is otherwise optional for a Share Swap. The principalExchangeFeatures element must be omitted for an “ISDA2005EquityAsiaExcludingJapanInterdealer” or "ISDA2005EquityAsiaExcludingJapanInterdealerRev2" or “GlobalMCA” or "ISDA2009EquityAmericas" or "ISDA2009EquityEuropean" or "ISDA2007EquityEuropean" and is otherwise optional for an Index Swap.

http://www.fpml.org/coding-scheme/interpolation-method


For a BulletCompounding Swap or when the sub product type is “BulletCompounding9” for a Equity Swap, the principalExchangeFeatures element is not allowed.

eference, and principalExchangesAmount element,

e equity amount receiver SwapTransactionSupplement.returnLeg.receiverPartyReference).

es the equity amount payer SwapTransactionSupplement.returnLeg.payerPartyReference).

he principalExchangesAmount element must include the principalAmount element

valid ISO 4217 currency. The mount element value may have up to two places after the decimal point.


The principalExchangeFeatures element must omit the principalExchanges element and must include the principalExchangesDescriptions element. The principalExchangesDescriptions element must include the payerPartyReference, receiverPartyRand must omit principalExchangeDate element. The payerPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines th(equity The receiverPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defin(equity T The principalAmount element must include the currency and the amount elements. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to this scheme by being a a

The use of the collateral element within the trade element is optional.

tain the payerPartyReference, the ceiverPartyReference, and a single paymentDetail element.

When the collateral element is used, the collateral element must contain the independentAmount element. The independentAmount element must conre



The payerPartyReference must be an empty element that must include the href attribute. The value of

he receiverPartyReference must be an empty element that must include the href attribute. The value

ent must include either the paymentAmount element or the aymentRule element. The paymentAmount element is used to represent the Independent Amount as

ements. The currency element must contain the currencyScheme attribute with the alue “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to this

he paymentRule element may be used instead of the paymentAmount element. The following diagram illustrates the PercentageRule data type, which is the actual type that the paymentRule element assumes as described below:

the href attribute will match the id attribute from the party element that defines the independent amount payer. Tof the href attribute will match the id attribute from the party element that defines the independent amount receiver. The paymentDetail element must omit the adjustablePaymentDate and the adjustedPaymentDate elements. The paymentDetail elempa currency amount. The paymentRule element is used to represent the Independent Amount as a percentage of the Notional Amount. When the paymentAmount element is used, the paymentAmount element must include the currency and the amount elvscheme by being a valid ISO 4217 currency. The amount element value may have up to two places after the decimal point. T

When the paymentRule element is used, it must include the xsi:type attribute with the value “PercentageRule” (xsi:type="PercentageRule"). This “types” the abstract paymentRule with the PercentageRule type. The paymentRule element must include the paymentPercent element, which must contain a decimal number with up to seven (7) decimal places. For example, enter 0.05 for 5%.

rom a DTCC matching perspective, trailing zeros will not be considered during the matching process,

he paymentRule element must also include the notionalAmountReference element. The otionalAmountReference must be an empty element that must include the href attribute. The value of e href attribute must be “equityNotionalAmount”.

Ftherefore, paymentPercent values of "0.05" and "0.0500000" will match. The value of the paymentPercent element may not be zero (0.0000000). Tnth



The documentation element within the trade element is used to specify the dates of the master confirmation agreement and the type of master confirmation used for this supplemental transaction. The documentation element must contain a masterConfirmation element. The documentation element may contain one or more occurances of contractualTermSupplement elements. The documentation element may not include a masterAgreement, brokerConfirmation, contractualDefinitions, contractualSupplement or creditSupportDocument element. The masterConfirmation element must contain a masterConfirmationType element. The value of the masterConfirmationType element must be one of:

EquityAmericas or EquityEuropean or ISDA2005EquityAsiaExcludingJapanInterdealer or

EquityAsia ISDA2007EquityFinanceSwapEuropean ISDA2004EquityAmericasInterdealer


ISDA2005EquityAsiaExcludingJapanInterdealerRev2 ISDA2008EquityFinanceSwapAsiaExcludingJapanRev1 ISDA2009EquityAmericas ISDA2009EquityEuropean ISDA2008EquityFinanceSwapAsiaExcludingJapan GlobalMCA ISDA2009EquityInterdealerPanAsia ISDA2007EquityEuropean

The masterConfirmation element must contain a masterConfirmationDate element. The value of the masterConfirmationDate element must follow the XML date pattern YYYY-MM-DD convention. By DTCC Deriv/SERV business rules this must be a valid date. The masterConfirmation element may optionally contain a masterConfirmationAnnexDate element. The optional masterConfirmationAnnexDate must follow the XML date pattern YYYY-MM-DD convention. By DTCC Deriv/SERV business rules this must be a valid date. masterConfirmationAnnexDate is NOT allowed for “GlobalMCA” MCA type. For masterConfirmationType of type “GlobalMCA”, the masterConfirmation element may contain a masterConfirmationAnnexType element. The value of the masterConfirmationAnnexType element must be one of:

SSS (US) SSS (AEUS) SSS (EMEA) SSS (AEJA) SSS (Japan) SIS (US) SIS (AEUS) SIS (EMEA) SIS (AEJA) SIS (Japan) SB(SR)S (US) SB(SR)S (AEUS) SB(SR)S (EMEA) SB(SR)S (AEJA) SB(SR)S (Japan)

The contractualTermSupplement element must include the type element and must not contain a publicationDate element. The contractualTermSupplement element may be included to specify that the Canadian Supplement is applicable if the underlying master confirmation is “EquityAmericas” or “ISDA2004EquityAmericasInterdealer”. When included, the value of the type element in contractualTermSupplement element must be:

• “ISDAMarch2004EquityCanadianSupplement”


For Share Swap only, the contractualTermSupplement element may be included to specify that either Full or Partial Lookthrough is applicable to the trade. When included, the value of the type element in the contractualTermSupplement element must be either:


For Share Swap only, When the master confirmation type is “ISDA2009EquityAmericas” the contractualTermSupplement element must be included when Depository Receipt Election is applicable otherwise contractualTermSupplement element must not be included for “ISDA2009EquityAmericas” MCA. The contractualTermSupplement element must specify that either Full or Partial Lookthrough is applicable to the trade. When included, the value of the type element in the contractualTermSupplement element must be either: Full and/or Partial Lookthrough may be specified for any underlying master confirmation. Only one of "ISDA2007FullLookthroughDepositoryReceiptSupplement" or "ISDA2007PartialLookthroughDepositoryReceiptSupplement" may be specified, not both.


7.4 FpML - Equity Variance Swap

The FpML element has an abstract content model allowing for several types of message to be included in this base, encompassing element. The generic details for usage of the FpML element can be found in the “Message Architecture” document. The trade element contains the details of the Equity Variance Swap itself. This document primarily deals with the specifics for the trade.



The FpML Trade datatype allows a common representation of many OTC Derivative products while using the same generic XML structure. The usage of the Trade datatype is detailed in the “Message Architecture” document. The product element is abstract and has a unique representation for each OTC Derivative product type; the detail of the product element for Equity Variance Swap is represented as the concrete element equitySwapTransactionSupplement.


7.4.2 FpML equitySwapTransactionSupplement Element

For Share Variance Swap and Index Variance Swap, the equitySwapTransactionSupplement product element must replace the abstract product element. The id attribute must be included with the value “varianceSwap”. The productType and productId elements must not be included. The buyerPartyReference element must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the variance buyer. The sellerPartyReference element must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the variance seller. The returnSwapLeg element is abstract and must be replaced by the varianceLeg element that is described in the following Section 7.4.3 The mutualEarlyTermination element must not be included. The multipleExchangeIndexAnnexFallback element must be omitted for a Variance Swap Share. For Variance Swap Index, multipleExchangeIndexAnnexFallback element must be included for an “ISDA2007VarianceSwapEuropean", "ISDA2007VarianceSwapAsiaExcludingJapan", "EquityAsia" and and “ISDA2007VarianceSwapAsiaExcludingJapanRev1” Master Confirmation Transaction Type (MCA),


and must be omitted for all other MCA types. The multipleExchangeIndexAnnexFallback element is may only have a value of “true” or “false”. The localJurisdiction element must be used for an “ISDA2007VarianceSwapAsiaExcludingJapan”, “EquityAsia” and “ISDA2007VarianceSwapAsiaExcludingJapanRev1” Variance Swap Share, and is not allowed otherwise. The localJurisdiction element must contain one of the following values: 'India", "Indonesia", "Korea", "Malaysia", "Taiwan",”Thailand”,, “China”,”Pakistan”,”Vietnam”,”Afghanistan”,”Hong Kong”,”Japan”,Singapore”,”Australia”,”New Zealand”,”Philippines“ and "NotApplicable". 7.4.3 FpML varianceLeg Element

The varianceLeg element describes the details of the Variance Swap, and must be included within the equitySwapTransactionSupplement element in place of the abstract assetSwapLeg element. The varianceLeg element must not include the legIdentifier attribute, and must include the payerPartyReference, receiverPartyReference, underlyer, equityValuation, and equityAmount elements. The payerPartyReference element must be an empty element that must include the href attribute. The value of the href attribute must match the value of the href attribute in the equitySwapTransactionSupplement.sellerPartyReference element described in Section 7.4.2. The receiverPartyReference element must be an empty element that must include the href attribute. The value of the href attribute must match the value of the href attribute in the equitySwapTransactionSupplement.buyerPartyReference element described in Section 7.4.2.


he paymentFrequency element is not allowed.

he underlyer element is described in Section

T T 7.4.4

he equityValuation element is described in Section T 7.4.5

he equityAmount element is described in Section T 7.4.6

.4.4 FpML underlyer Element 7

he underlyer element must contain the singleUnderlyer element. The basket element must not be

he singleUnderlyer element must contain one of the types that derive from and substitute for

Tused. TunderlyingAsset since the underlyingAsset element is abstract. For an Index Variance Swap, the index element must be used in place of underlyingAsset. The index element is described in Section7.4.4.2. For a Share Variance Swap, the equity element must be used in place of underlyingAsset. The equity element is described in Section 7.4.4.1.

he openUnits, dividendPayout and couponPayment elements must not be used. T



The equity element must be used for a Share Variance Swap and must not be used for an Index Variance Swap. The equity element must omit the id attribute and must contain an instrumentId element. The instrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier must include the exchange code as a suffix. The RIC identifier is case sensitive. The description, currency, exchangeId, clearanceSystem and definition elements must not be used. The relatedExchangeId element must be omitted for an "ISDA2004VarianceSwapAmericasInterdealer" and "ISDA2007VarianceSwapAmericas" Master Confirmation Transaction Type (MCA). The relatedExchangeId element may be used for an “ISDA2007VarianceSwapAsiaExcludingJapan” and and "EquityAsia" and “ISDA2007VarianceSwapAsiaExcludingJapanRev1” MCA. Otherwise, the relatedExchangeId element must be used. When the relatedExchangeId element is used, it must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier or the text “ALL” to denote All Exchanges or the text “N/A” to denote not applicable. The REC identifier is case sensitive. Deriv/SERV allows a maximum of 10 relatedExchangeId elements. The optionsExchangeId element must not be used.



The index element must be used for an Index Variance Swap and must not be used for a Share Variance Swap. The index element must omit the id attribute and must contain an instrumentId element. The instrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier is case sensitive. The RIC identifier must not include the exchange code as a suffix. The exchange code is contained in the exchangeId element, as explained below. The description, currency, clearanceSystem, definition, optionsExchangeId and futureId elements must not be used. The index element must include either a single exchangeId element or two (2) or more constituentExchangeId elements. The exhangeId element and constituentExchangeId elements must not be used at the same time. The exchangeId element, when included, must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier. The REC identifier is case sensitive.


The constituentExchangeId elements, when included, must each contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier. Up to ten (10) constituentExchangeId elements can be included at the same time, but no less than two (2) can be specified at the same time. In the event that there is only a single Exchange for the asset being traded, the ExchangeId element should be used. The REC identifier is case sensitive. The relatedExchangeId element must be omitted for an "ISDA2004VarianceSwapAmericasInterdealer" and "ISDA2007VarianceSwapAmericas" Master Confirmation Transaction Type (MCA). The relatedExchangeId element may be used for an “ISDA2007VarianceSwapAsiaExcludingJapan” and and "EquityAsia" MCA. Otherwise, the relatedExchangeId element must be used. When the relatedExchangeId element is used, it must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier or the text “N/A” to denote not applicable. The REC identifier is case sensitive. Deriv/SERV allows a maximum of 10 relatedExchangeId elements. 7.4.5 FpML equityValuation Element

The equityValuation element must not include the id attribute, and the valuationDates, valuationTimeType, and valuationTime elements. The equityValuation element must include the valuationDate and may either include the optionsPriceValuation elements or the futuresPriceValuation element. The valuationDate element must include the id attribute with the value “valuationDate”. The valuationDate element must omit the relativeDateSequence element, and must include the


adjustableDate element. The adjustableDate element must omit the id attribute and must include the unadjustedDate and dateAdjustments elements. The unadjustedDate element will contain the adjusted valuation date, which must follow the XML date convention of YYYY-MM-DD. The dateAdjustments element must not include the id attribute, and the businessCentersReference and businessCenters elements. The dateAdjustments element must include the businessDayConvention element with the value “NotApplicable”. The futuresPriceValuation element may optionally be used, but must be omitted when the Options Price Valuation element (below) is used. The futuresPriceValuation element must contain a value of “true” or “false”. The optionsPriceValuation element may only be populated for an "EquityAmericas", "EquityEuropean", Master Confirmation. However, the optionsPriceValuation element must be omitted when the futuresPriceValuation element is used. The optionsPriceValuation element must contain a value of “true” or “false”.


7.4.6 FpML equityAmount Element


The paymentCurrency element is used to describe the Settlement Currency. The Settlement Currency will be expressed in the record by including the explicit currency value in the equityAmount.variance.varianceAmount.currency element described in Section 7.4.6.1, and by referencing this value from the paymentCurrency element. The specific usage is as follows: The paymentCurrency element must omit the id attribute, and the currency and determinationMethod elements. The paymentCurrency element must be an empty element that must include the href attribute with the value “varianceAmountCurrency”. For an "ISDA2007EquityFinanceSwapEuropean" MCA, the Settlement Currency should have the same value as the Initial Price Currency. The referenceAmount, formula, and encodedDescription elements must not be included. The variance element is described in Section 7.4.6.1 The calculationDates element may be used to represent Observation Days in frequency. When included the calculationDates element, it must include the id attribute with the value “observationDates”and must include the periodicDates element. When included the periodicDates element in the calculationDates element, it must include the calculationStartDate element, the calculationEndDate element, the calculationPeriodFrequency element and the calculationPeriodDatesAdjustments element. The calculationStartDate and the calculationEndDate elements must include the adjustableDates element.The adjustableDates element must include unadjustedDate element containing a single date value that must follow the XML date convention of YYYY-MM-DD. The adjustableDates element must also include the dateAdjustments element. The dateAdjustments element must omit the id attribute, must contain the businessDayConvention element with the value “NotApplicable”, and must not contain the businessCentersReference and businessCenters elements. The unadjustedDate element in calculationStartDate must have the same value as the unadjustedDate element in observationStartDate while the unadjustedDate element in calculationEndDate must have the same value as the unadjustedDate element in valuationDate. The calculationPeriodFrequency element must omit the id attribute. The calculationPeriodFrequency element must include the following elements:




The calculationPeriodDatesAdjustments element must omit the id attribute, must contain the businessDayConvention element with the value “NONE”.


The cashSettlement element must be included with the value “true”. The optionsExchangeDividends element must be omitted when All Dividends is populated. Furthermore, the optionsExchangeDividends element must be omitted for an “ISDA2007VarianceSwapEuropean", "ISDA2007VarianceSwapAsiaExcludingJapan", "EquityAsia" and “ISDA2007VarianceSwapAsiaExcludingJapanRev1” Share Swap and is optional for all other MCAs. The optionsExchangeDividends element must be omitted for an Index Variance Swap. When provided, the optionsExchangeDividends element will have the value “true” when applicable, and the value “false” when not applicable. The additionalDividends element must not be included. The cashSettlementPaymentDate element is only required for “ISDA2006VarianceSwapJapaneseInterdealer” MCA transactions, and it is not allowed for "ISDA2004VarianceSwapAmericasInterdealer" and "ISDA2007VarianceSwapAmericas" MCA transactions. The cashSettlementPaymentDate is optional for all other transactions. When included, the cashSettlementPaymentDate element must omit the id attribute and the adjustableDate element, and must include the relativeDate element. The relativeDate element must omit the id attribute, and the businessCentersReference and businessCenters elements. The relativeDate element must include the periodMultiplier element with the integer number of days, the period element with a value of “D”, the dayType element with a value of “CurrencyBusiness”, and the businessDayConvention element with a value of “NONE”. The relativeDate element must also include the dateRelativeTo element, which must be an empty element that includes an href attribute with the value “valuationDate”. The observationStartDate element is an optional element that is used to provide the Observation Start Date. When the observationStartDate element is omitted, the DTCC system will insert the trade date in that field on all outbound messages. When provided, the observationStartDate element must omit the dateRelativeTo element, and must include the adjustableDate element. The adjustableDate element must omit the id attribute and must include the unadjustedDate and dateAdjustments elements. The unadjustedDate element will contain the date, which must follow the XML date convention of YYYY-MM-DD. The dateAdjustments element must not include the id attribute, and the businessCentersReference and businessCenters elements. The dateAdjustments element must include the businessDayConvention element with the value “NotApplicable”. The allDividends element may be included for a Share Variance Swap and must be omitted for an Index Variance Swap. Furthermore, the allDividends element must be included for an “ISDA2007VarianceSwapAsiaExcludingJapan", "EquityAsia" and “ISDA2007VarianceSwapAsiaExcludingJapanRev1“ Share Swap. When provided, the allDividends element will have the value “true” when applicable, and the value “false” when not applicable.


7.4.6.1 FpML variance Element


The initial price of the underlyer must be specified, by including one of the following elements 1. initialLevel element with a specific initial price, 2. closingLevel element with a value of “true” to indicate that the price at the close of trading on

the Trade Date will apply. 3. expiringLevel element with a value of “true” to indicate that the Official Settlement Price of the

Expiring Contract on the Observation Start Date will apply. The specific usage is as follows: When provided, the initialLevel element will contain a decimal value with up to two decimal places. When provided, the closingLevel element must contain the value “true”. The expiringLevel element must contain the value “true” and may only be used for an Index Variance Swap “ISDA2007VarianceSwapEuropean", "ISDA2004VarianceSwapAmericasInterdealer", "ISDA2007VarianceSwapAmericas", "ISDA2007VarianceSwapAsiaExcludingJapan", "EquityAsia" and “ISDA2007VarianceSwapAsiaExcludingJapanRev1” Master Confirmation Transaction Type (MCA). The varianceAmount element must include the id attribute with the value “varianceAmountCurrency” so that the Settlement Currency described in Section 7.4.6 can point to the explicit currency value contained herein. The varianceAmount element must also include the currency and amount elements. The currency element must contain the currencyScheme attribute with the value http://www.fpml.org/ext/iso4217, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency. The amount element must contain a decimal value with up to two decimal places. The convention for computing the Variance Amount is the vega notional divided by two times the strike price. The volatilityStrikePrice element must not be included. The varianceStrikePrice element must be included and will contain a decimal value that may have up to four decimal places. The expectedN element is optional for "ISDA2007VarianceSwapEuropean", "ISDA2004VarianceSwapAmericasInterdealer", "ISDA2007VarianceSwapAmericas" "ISDA2007VarianceSwapAsiaExcludingJapan" and “ISDA2007VarianceSwapAsiaExcludingJapanRev1” MCAs. For all other MCAs, the expectedN element is required. When the expectedN element is included, it will contain an integer number that represents a number of days. For Share Variance Swaps, the varianceCap element must be omitted for an "ISDA2007VarianceSwapEuropean", "ISDA2004VarianceSwapAmericasInterdealer" and an "ISDA2007VarianceSwapAmericas" Master Confirmation Transaction Type (MCA); otherwise, it is optional. For Index Variance Swaps, the varianceCap element may optionally be used. When the varianceCap element is used it must contain the value “false” for Variance Cap is not applicable and “true” for Variance Cap is applicable. The unadjustedVarianceCap element may be included for an "ISDA2007VarianceSwapEuropean", "ISDA2004VarianceSwapAmericasInterdealer" and an "ISDA2007VarianceSwapAmericas" Master Confirmation Transaction Type (MCA), but must be omitted when the varianceCap element contains the value “false”. For all other MCAs, the unadjustedVarianceCap element must be included when the varianceCap element contains the value “true”, and otherwise must be omitted. When provided, the unadjustedVarianceCap element will contain the computed Variance Cap (the variance cap factor squared times the variance strike price), as a decimal value up to eleven whole numbers with four decimal places. Zero is not a valid value. For an Index Variance Swap, the exchangeTradedContractNearest element is optional for "ISDA2004VarianceSwapAmericasInterdealer", "ISDA2007VarianceSwapAmericas", "ISDA2007VarianceSwapAsiaExcludingJapan", "EquityAsia" and


“ISDA2007VarianceSwapAsiaExcludingJapanRev1” MCA; but, must be omitted when either Future Price Valuation or Options Prices contains the value “false”. Please note that if both Future Price Valuation and Options Price Valuation is omitted, then exchangeTradedContractNearest element is in reference to Future Price Valuation. For all other Index Variance Swap MCAs and Share variance Swaps, the exchangeTradedContractNearest element is required when Futures Price Valuation or Options Price Valuation (equityValuation.optionsPriceValuation element described in Section 7.4.5) contains a value of "true". Otherwise, it is not allowed. When provided, the exchangeTradedContractNearest element must omit the id attribute, and the description, currency, exchangeId, clearenceSystem, definition, relatedExchangeId, optionsExchangeId, multiplier, contractReference, and expirationDate elements. When provided, the exchangeTradedContractNearest element must include the instrumentId element. The instumentId element must include the instrumentIdScheme attribute with the value “MonthYearId”, and must contain the month and year of the futures contract. This must be in the format of MMYY. For example, June 2004 would be represented with “0604”. The vegaNotionalAmount element is not allowed. The fxFeature may only be used for an “ISDA2007VarianceSwapAsiaExcludingJapan”, “EquityAsia” and “ISDA2007VarianceSwapAsiaExcludingJapanRev1” Master Confirmation Type and is not allowed otherwise. The fxFeature element must omit composite and quanto elements. The fxFeature element must include the referenceCurrency element and crossCurrency element. The referenceCurrency element must have a currencyScheme attribute with the value”http://www.fpml.org/ext/iso4217" and must contain valid ISO currency. The crossCurrency element must omit the determinationMethod element and the relativeDate element. The crossCurrency element may contain the fxSpotRateSource element, which is defined in the next section. 7.4.6.1.1 FpML fxSpotRateSource Element

The fxSpotRateSource element must contain the primaryRateSource element and the fixingTime element. The fxSpotRateSource element may contain the secondaryRateSource element.


The primaryRateSource element must contain the rateSource element, and may optionally contain the rateSourcePage element and rateSourcePageHeading element. The rateSource element must include the informationProviderScheme attribute with the value “http://www.fpml.org/spec/2007/information-provider”. The value that is used for the rateSource element must adhere to this scheme. The

teSourcePage element must omit the rateSourcePageScheme attribute.

eadin

ere to this scheme. The rateSourcePage element must omit the rateSourcePageScheme ttribute.

Center element must adhere to this scheme. The businessCenter element must omit the id ttribute.


ra The secondaryRateSource element must contain the rateSource element, and may optionally contain the rateSourcePage element and rateSourcePageH g element. The rateSource element must include the informationProviderScheme attribute with the value “http://www.fpml.org/spec/2007/information-provider”. The value that is used for the rateSource element must adha The fixingTime element must contain the hourMinuteTime element and the businessCenter element. The hourMinuteTime element must contain a time specified in hh:mm:ss format where the second component must be '00'. The businessCenter element must include the businessCenterScheme attribute with the value “http://www.fpml.org/spec/2007/business-center” and the value contained in the businessa

The use of the collateral element within the trade element is optional.

tain the payerPartyReference, the ceiverPartyReference, and a single paymentDetail element.

attribute will match the id attribute from the party element that defines the independent amount ayer.

When the collateral element is used, the collateral element must contain the independentAmount element. The independentAmount element must conre The payerPartyReference must be an empty element that must include the href attribute. The value of the href p


The receiverPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the independent amount receiver. The paymentDetail element must omit the adjustablePaymentDate and the adjustedPaymentDate elements. The paymentDetail element must include either the paymentAmount element or the paymentRule element. The paymentAmount element is used to represent the Independent Amount as a currency amount. The paymentRule element is used to represent the Independent Amount as a percentage of the Notional Amount. When the paymentAmount element is used, the paymentAmount element must include the currency and the amount elements. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency. The amount element value may have up to two places after the decimal point. The paymentRule element may be used instead of the paymentAmount element. The following diagram illustrates the PercentageRule data type, which is the actual type that the paymentRule element assumes as described below:

When the paymentRule element is used, it must include the xsi:type attribute with the value “PercentageRule” (xsi:type="PercentageRule"). This “types” the abstract paymentRule with the PercentageRule type. The paymentRule element must include the paymentPercent element, which must contain a decimal number with up to seven (7) decimal places. For example, enter 0.05 for 5%. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore, paymentPercent values of "0.05" and "0.0500000" will match. The value of the paymentPercent element may not be zero (0.0000000). The paymentRule element must also include the notionalAmountReference element. The notionalAmountReference must be an empty element that must include the href attribute. The value of the href attribute must be “varianceSwap”. This is a pointer to the equitySwapTransactionSupplement element, and is a general reference to the Variance Swap, since the base amount for the percentage is not directly contained in the transaction record.



The documentation element within the trade element is used to specify the dates of the master confirmation agreement and the type of master confirmation used for this supplemental transaction. The documentation element must contain a masterConfirmation element. The documentation element may not include a masterAgreement, brokerConfirmation, contractualDefinitions, contractualSupplement, contractualTermsSupplement, contractualMatrix or creditSupportDocument element. The masterConfirmation element must contain a masterConfirmationType element. The value of the masterConfirmationType element must be one of:

EquityAmericas or EquityEuropean or

ISDA2006VarianceSwapJapaneseInterdealer or ISDA2004VarianceSwapAmericasInterdealer or ISDA2007VarianceSwapAmericas or ISDA2007VarianceSwapAsiaExcludingJapan or ISDA2007VarianceSwapEuropean or EquityAsia ISDA2007VarianceSwapAsiaExcludingJapanRev1


The masterConfirmation element must contain a masterConfirmationDate element. The value of the masterConfirmationDate element must follow the XML date pattern YYYY-MM-DD convention. By DTCC Deriv/SERV business rules this must be a valid date. The masterConfirmation element may optionally contain a masterConfirmationAnnexDate element. The optional masterConfirmationAnnexDate must follow the XML date pattern YYYY-MM-DD convention. By DTCC Deriv/SERV business rules this must be a valid date. For Share VarianceSwap only, the contractualTermSupplement element may be included to specify that either Full or Partial Lookthrough is applicable to the trade. When included, the value of the type element in the contractualTermSupplement element must be either:


Full and/or Partial Lookthrough may be specified for any underlying master confirmation. Only one of "ISDA2007FullLookthroughDepositoryReceiptSupplement" or "ISDA2007PartialLookthroughDepositoryReceiptSupplement" may be specified, not both.


7.5 FpML - Dividend Swap 7.5.1 FpML Trade Datatype

The FpML Trade datatype allows a common representation of many OTC Derivative products while using the same generic XML structure. The usage of the Trade datatype is detailed in the “Message Architecture” document. The product element is abstract and has a unique representation for each OTC Derivative product type; the detail of the product element for Dividend Swap is represented as the concrete element dividendSwapTransactionSupplement.


7.5.2 FpML dividendSwapTransactionSupplement Element

For Share Dividend Swap and Index Dividend Swap, the dividendSwapTransactionSupplement product element must replace the abstract product element. The dividendLeg element is described in the following Section 7.4.3 The fixedLeg element is described in the following Section 7.5.5


7.5.3 FpML dividendLeg element

The dividendLeg element describes the details of the Dividend Swap, and must be included within the dividendSwapTransactionSupplement element.


The dividendLeg element must include the payerPartyReference, receiverPartyReference, underlyer, settlementCurrency, dividendPeriod elements. The dividendLeg must not include the declaredCashDividendPercentage, declaredCashEquivalentDividendPercentage elements when the master confirmation type is "ISDA2008DividendSwapsJapanese”. The dividendLeg element must include the specialDividends element when the master confirmation type is “ISDA2008DividendSwapsJapanese” otherwise not allowed. The dividendLeg element may include the materialDividend element when the master confirmation type is “ISDA2008DividendSwapsJapanese” otherwise not allowed. The payerPartyReference element must be an empty element that must include the href attribute, and will match the id attribute from one of the party elements that defines the Floating Rate Payer. The receiverPartyReference element must be an empty element that must include the href attribute, and will match the id attribute from one of the party elements that defines the Fixed Rate Payer. The underlyer element is described in Section 7.5.7 The dividendPeriod element is described in Section 7.5.4


7.5.4 FpML dividendPeriod

The dividendPeriod element must include the id attribute and the value of the id attribute will be “dividendPeriodN”, where N is the incremental number of dividendPeriods. N will be a running integer starting from ‘1’ and no greater than ‘20’. The dividendPeriod element must also include the unadjustedStartDate, unadjustedEndDate, dateAdjustments, fixedStrike and paymentDate


elements. For an Index Dividend Swap the dividendPeriod element must contain the valuationDate element when the master confirmation type is ISDA2008DividendSwapsJapanese otherwise not allowed. The dateAdjustments element must include the businessDayConvention element, which must have the value “NONE”. The paymentDate element must include the id attribute and the value of the id attribute will be “dividendPeriodPaymentDateN”, where N is the incremental number of dividendPeriods. N will be a running integer starting from ‘1’ and no greater than ‘20’. The paymentDate element must only contain the adjustableDate element. The adjustableDate element must contain the unadjustedDate and the dateAdjustments elements. The dateAdjustments element must include the businessDayConvention element, which must have the value “NONE”. The valuationDate element must only contain the adjustableDate element. The adjustableDate element must contain the unadjustedDate and the dateAdjustments elements. The dateAdjustments element must include the businessDayConvention element, which must have the value “NONE”.


7.5.5 FpML fixedLeg element

The fixedLeg element describes the details of the Dividend Swap, and must be included within the dividendSwapTransactionSupplement element. The fixedLeg element must include the payerPartyReference, the receiverPartyReference, and one or more fixedPayment element(s). The payerPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the Fixed Rate Payer. The receiverPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the Floating Rate Payer. The fixedPayment element is described in Section 7.5.6


7.5.6 FpML fixedPayment element

The fixedPayment element must contain the paymentAmount and paymentDate elements. The paymentAmount element must include the currency and the amount elements. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency. The value of the paymentAmount.amount element will be the product of the values of openUnits and fixedStrike elements. The paymentAmount.amount element value may have up to two places after the decimal point. DTCC will not validate the value of the paymentAmount.amount element on input. The paymentDate element must contain the periodMultiplier, period, businessDayConvention¸and dateRelativeTo elements.


periodMultiplier10 the integer number to indicate number of days between the Fixed Amount Payment Dates and Dividend Amount Payment Date, a positive number indicates the Currency Business Days following the Dividend Amount Payment Date,a negative number indicate number of Currency Business Days prior to the Dividend Amount Payment Date,”0” indicates the Fixed Amount Payment Dates are the Dividend Amount Payment Dates.

period must have the value “D”.“D” indicating the periodMultiplier is for days. businessDayConvention must have the value ”NONE"

The dateRelativeTo element must be an empty element, and must include the href attribute. The value of the href attribute will match the id attribute from the dividendPeriod.paymentDate element that corresponds to that period. 7.5.7 FpML underlyer Element

The underlyer element must contain the singleUnderlyer element. The basket element must not be used. The singleUnderlyer element must contain one of the types that derive from and substitute for underlyingAsset since the underlyingAsset element is abstract. For a Share Dividend Swap, the equity element must be used in place of underlyingAsset. The equity element is described in Section 7.4.4.1. For an Index Dividend Swap, the index element must be used in place of underlyingAsset. The index element is described in Section 7.4.4.2. The dividendPayout and couponPayment elements must not be used.

10 For Equity Index Dividend Swap if the master confirmation type is "ISDA2008DividendSwapsJapanese", the periodMultiplier value must be between "0" and "31".

For master confirmation types other than "ISDA2008DividendSwapsJapanese" or Equity Share Dividend Swap, the periodMultiplier value must be "0" indicating fixedPayment.paymentDate is not applicable.



The equity element must be used for a Share Dividend Swap and must not be used for an Index Dividend Swap. The equity element must omit the id attribute and must contain an instrumentId element. The instrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier must include the exchange code as a suffix. The RIC identifier is case sensitive. The description, currency, exchangeId, optionsExchangeId, clearanceSystem and definition elements must not be used. The relatedExchangeId element must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier or the text “ALL” to denote All Exchanges or the text “N/A” to denote not applicable. The REC identifier is case sensitive. Deriv/SERV allows a maximum of 10 relatedExchangeId elements.



The index element must be used for an Index Dividend Swap and must not be used for a Share Dividend Swap. The index element must omit the id attribute and must contain an instrumentId element. The instrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier is case sensitive. The RIC identifier must not include the exchange code as a suffix. The exchange code is contained in the exchangeId element, as explained below. The index element must include either a single exchangeId element or two (2) or more constituentExchangeId elements. The exhangeId element and constituentExchangeId elements must not be used at the same time. The exchangeId element, when included, must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier. The REC identifier is case sensitive.


The constituentExchangeId elements, when included, must each contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier. Up to ten (10) constituentExchangeId elements can be included at the same time, but no less than two (2) can be specified at the same time. In the event that there is only a single Exchange for the asset being traded, the ExchangeId element should be used. The REC identifier is case sensitive. The description, currency, clearanceSystem, definition, optionsExchangeId and futureId elements must not be used. The exchangeId and relatedExchangeId elements must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier or the text “N/A” to denote not applicable. The REC identifier is case sensitive. Deriv/SERV allows a mamium of 10 relatedExchangeId elements. 7.5.8 FpML collateral Element

The use of the collateral element within the trade element is optional. When the collateral element is used, the collateral element must contain the independentAmount element. The independentAmount element must contain the payerPartyReference, the receiverPartyReference, and must contain one or more paymentDetail element(s). The payerPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the independent amount payer. The receiverPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the independent amount receiver.


The paymentDetail element(s) must omit the adjustablePaymentDate and the adjustedPaymentDate elements. The paymentDetail element(s) must include the paymentAmount element. The paymentAmount element is used to represent the Independent Amount as a currency amount. The paymentAmount element must include the id attribute and the value of the id attribute will be “independentAmountN”, where N is the incremental number of dividendPeriods. N will be a running integer starting from ‘1’ and no greater than ‘20’. The paymentAmount element must include the currency and the amount elements. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency. The amount element value may have up to two places after the decimal point. 7.5.9 FpML documentation Element

The documentation element within the trade element is used to specify the dates of the master confirmation agreement and the type of master confirmation used for this supplemental transaction. The documentation element must contain a masterConfirmation element. The documentation element may not include a masterAgreement, brokerConfirmation, contractualDefinitions, contractualSupplement, contractualTermsSupplement, contractualMatrix or creditSupportDocument elements. The masterConfirmation element must contain a masterConfirmationType element. The value of the masterConfirmationType element must be one of:


“2006DividendSwapEuropean” or “2006DividendSwapEuropeanInterdealer” or "ISDA2008DividendSwapsJapanese" or "EquityAmericas"

The masterConfirmation element must contain a masterConfirmationDate element. The value of the masterConfirmationDate element must follow the XML date pattern YYYY-MM-DD convention. By DTCC Deriv/SERV business rules this must be a valid date. For Share DividendSwap only, the contractualTermSupplement element may be included to specify that either Full or Partial Lookthrough is applicable to the trade. When included, the value of the type element in the contractualTermSupplement element must be either:


Full and/or Partial Lookthrough may be specified for any underlying master confirmation. Only one of "ISDA2007FullLookthroughDepositoryReceiptSupplement" or "ISDA2007PartialLookthroughDepositoryReceiptSupplement" may be specified, not both.


7.6 FpML - Equity Dispersion Variance Swap

The FpML element has an abstract content model allowing for several types of message to be included in this base, encompassing element. The generic details for usage of the FpML element can be found in the “Message Architecture” document. The trade element contains the details of the Equity Dispersion Variance itself. This document primarily deals with the specifics for the trade.



The FpML Trade datatype allows a common representation of many OTC Derivative products while using the same generic XML structure. The usage of the Trade datatype is detailed in the “Message Architecture” document. The product element is abstract and has a unique representation for each OTC Derivative product type; the detail of the product element for Equity Dispersion Variance is represented as the concrete element varianceSwapTransactionSupplement. Equity Dispersion Variance (EDV) is constituted by a single Equity Dispersion Index Variance Swap (EDI) and multiple Equity Dispersion Share Variance Swap (EDS).


7.6.2 FpML varianceSwapTransactionSupplement Element

For Dispersion Variance Swap (Dispersion Share Variance Swap and Dispersion Index Variance Swap), the varianceSwapTransactionSupplement product element must replace the abstract product element. The id attribute must be included with the value “equityDispersionVariance”. The productType and the productId elements must not be included. The varianceLeg element must be included. For a Dispersion Index Variance Swap the multipleExchangeIndexAnnexFallback element is only allowed when the master confirmation type is "EquityEuropean" or "ISDA2007VarianceSwapEuropean". The localJurisdiction and the relevantJurisdiction elements are not allowed.


7.6.3 FpML varianceLeg Element

The varianceLeg element must not include the legIdentifier attribute, and must include the payerPartyReference, receiverPartyReference, underlyer, valuation, and amount elements. The varianceLeg element may include settlementType, settlementDate and settlementCurrency elements remaining all other elements must not be used. The payerPartyReference11 element must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the variance buyer. The payerPartyReference element represents the variance buyer. 11 Variance Seller is not allowed to differ on an “Amendment” transaction type from the Variance Seller already specified on the underlying confirmed “Trade”.


The receiverPartyReference12 element must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the variance seller. The receiverPartyReference element represents the variance seller. When the settlementType element is included, the value of settlementType element must be “Cash”. When included, the settlementDate element must omit the id attribute and the adjustableDate element, and must include the relativeDate element. The relativeDate element must omit the id attribute, and the businessCentersReference and businessCenters elements. The relativeDate element must include the periodMultiplier element with the integer number of days, the period element with a value of “D”, the dayType element with a value of “CurrencyBusiness”, and the businessDayConvention element with a value of “NONE”. The relativeDate element must also include the dateRelativeTo element, which must be an empty element that includes an href attribute with the value “valuationDate”. The settlementCurrency element must contain the currencyScheme attribute with the value http://www.fpml.org/ext/iso4217, and the value of the settlementCurrency element must adhere to this scheme by being a valid ISO 4217 currency. The underlyer element is described in Section 7.6.4 The valuation element is described in Section 7.6.5 The amount element is described in Section 7.6.6 7.6.4 FpML underlyer Element

The underlyer element must contain the singleUnderlyer element. The basket element must not be used. 12 Variance Buyer is not allowed to differ on an “Amendment” transaction type from the Variance Buyer already specified on the underlying confirmed “Trade”.


he singleUnderlyer element must contain one of the types that derive from and substitute for T

underlyingAsset since the underlyingAsset element is abstract. For a Dispersion Share Variance Swap, the equity element must be used in place of underlyingAsset. The equity element is described in Section 7.4.4.1. For a Dispersion Index Variance Swap, the index element must be used in place of underlyingAsset. The index element is described in Section7.4.4.2. The openUnits, dividendPayout and couponPayment elements must not be used.

.6.4.1 FpML equity Element

7

The equity element must be used for a Dispersion Share Variance Swap and must not be sed for an uDispersion Index Variance Swap. The equity element must omit the id attribute and must contain an instrumentId element. The instrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier must include the exchange code as a suffix. The RIC identifier is case sensitive. The description, currency, exchangeId, clearanceSystem and definition elements must not be used.

he equity element must contain the relatedExchangeId, when included it must contain the

he optionsExchangeId element must not be used.

TexchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier or the text “ALL” to denote All Exchanges or the text “N/A” to denote not applicable. The REC identifier is case sensitive. Deriv/SERV allows a maximum of 10 relatedExchangeId elements. T



he index element must be used for an Index Variance Swap and must not be used for a Share Variance

ex element must omit the id attribute and must contain an instrumentId element. The

TSwap.

he indTinstrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier is case sensitive. The RIC identifier must not include the exchange code as a suffix. The exchange code is contained in the exchangeId element, as explained below.

he desT cription, currency, clearanceSystem, definition, optionsExchangeId and futureId elements

nt must include either a single exchangeId element or two (2) or more

ed, must contain the exchangeIdScheme attribute with the value ttp://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange

Code) identifier. The REC identifier is case sensitive.

must not be used.

he index elemeTconstituentExchangeId elements. The exhangeId element and constituentExchangeId elements must not be used at the same time.

he exchangeId element, when includT"h


The constituentExchangeId elements, when included, must each contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC

euters Exchange Code) identifier. Up to ten (10) constituentExchangeId elements can be included at

with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must ontain a valid REC (Reuters Exchange Code) identifier or the text “N/A” to denote not applicable. The

.6.5 FpML valuation Element

(Rthe same time, but no less than two (2) can be specified at the same time. In the event that there is only a single Exchange for the asset being traded, the exchangeId element should be used. The REC identifier is case sensitive. The index element must contain the relatedExchangeId, when included it must contain the exchangeIdScheme attributecREC identifier is case sensitive. Deriv/SERV allows a maximum of 10 relatedExchangeId elements. 7

The valuation element must not include the id attribute the valuationDates, valuationTimeType, and valuationTime elements.

x Variance Swap.

lativeDateSequence element, and must include the djustableDate element. The adjustableDate element must omit the id attribute and must include the

The valuation element must include the valuationDate and may include the futuresPriceValuation element for Dispersion Inde The valuationDate element must include the id attribute with the value “valuationDate”. The valuationDate element must omit the reaunadjustedDate and dateAdjustments elements. The unadjustedDate element will contain the adjusted valuation date, which must follow the XML date convention of YYYY-MM-DD. The


dateAdjustments element must not include the id attribute, and the businessCentersReference and businessCenters elements. The dateAdjustments element must include the businessDayConvention element with the value “NotApplicable”. The futuresPriceValuation element may optionally be used for a Dispersion Index Variance Swap, but must be omitted for Dispersion Share Variance Swap. The futuresPriceValuation element must contain

value of “true” or “false”.

.6.6 FpML amount Element

a The optionsPriceValuation must not be included. 7


The ca element must nolculationDates t be included. The observationStartDate element is an optional element that is used to provide the Observation Start Date. When the observationStartDate element is omitted, the DTCC system will insert the trade date in that field on all outbound messages. When provided, the observationStartDate element must omit the dateRelativeTo element, and must include the adjustableDate element. The adjustableDate element must omit the id attribute and must include the unadjustedDate and dateAdjustments elements. The unadjustedDate element will contain the date, which must follow the XML date convention of YYYY-MM-DD. The dateAdjustments element must not include the id attribute, and the businessCentersReference and businessCenters elements. The dateAdjustments element must include the businessDayConvention element with the value “NotApplicable”. The optionsExchangeDividends element must not be included. The additionalDividends element must not be included. The allDividends element may be included for a Dispersion Share Variance Swap and must be omitted for an Disperion Index Variance Swap. When provided, the allDividends element will have the value “true” when applicable, and the value “false” when not applicable. The variance element is described in Section 7.6.6.1



The initial price of the underlyer must be specified, by including one of the following elements

1. initialLevel element with a specific initial price, 2. closingLevel element with a value of “true” to indicate that the price at the close of trading on


Expiring Contract on the Observation Start Date will apply.


For a Dispersion Index Variance Swap the initialLevel element must be included when the closingLevel and the expiringLevel elements are not used and for a Disperison Share Variance Swap the initialLevel element must be included when the closingLevel element is not used. When provided, the initialLevel element will contain a decimal value with up to two decimal places. For a Dispersion Index Variance Swap the closingLevel element must be included when the initialLevel and the expiringLevel elements are not used and for a Disperison Share Variance Swap the closingLevel element must be included when the initialLevel element is not used. When provided, the closingLevel element must contain the value “true”. The expiringLevel element must contain the value “true” and may only be used for an Dispersion Index Variance Swap. The expiringLevel element must be included when the initialLevel and closingLevel are not used. The expiringLevel element must not be used for a Disperison Share Variance Swap. The expectedN element is optional. When the expectedN element is included, it will contain an integer number that represents a number of days. The varianceAmount element must include the id attribute with the value “varianceAmountCurrency”. The varianceAmount element must also include the currency and amount elements. The currency element must contain the currencyScheme attribute with the value http://www.fpml.org/ext/iso4217, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency. The amount element must contain a decimal value with up to twelve whole numbers with two decimal places. The convention for computing the Variance Amount is the vega notional divided by two times the strike price. The volatilityStrikePrice element must not be included. The varianceStrikePrice element must be included and will contain a decimal value that may have up to eleven whole numbers with four decimal places. The varianceCap element may optionally be used. When the varianceCap element is used it must contain the value “false” for Variance Cap is not applicable and “true” for Variance Cap is applicable. The unadjustedVarianceCap element must be included when the varianceCap element contains the value “true” otherwise optional. The unadjustedVarianceCap element will contain the computed Variance Cap (the variance cap factor squared times the variance strike price), as a decimal value up to eleven whole numbers with four decimal places. Zero is not a valid value. For an Index Variance Swap, the exchangeTradedContractNearest element is required when either Future Price Valuation contains the value “true” otherwise it is not allowed. When provided, the exchangeTradedContractNearest element must omit the id attribute, and the description, currency, exchangeId, clearenceSystem, definition, relatedExchangeId, optionsExchangeId, multiplier, contractReference, and expirationDate elements. When provided, the

xchangeTradedContractNearest element must include the instrumentId element. The instumentId ust contain

, June 2004

eelement must include the instrumentIdScheme attribute with the value “MonthYearId”, and mthe n in the format of MMYY. For examplemo th and year of the futures contract. This must bewould be represented with “0604”. The vegaNotionalAmount element is not allowed.



The use of the element within the element is optional.

f attribute will match the id attribute from the party element that defines the independent amount ayer.

he must be an empty element that must include the href attribute. The value

e element. The element is used to represent the Independent Amount as

ust include the currency nd the amount elements. The currency element must contain the currencyScheme attribute with the

collateral trade When the collateral element is used, the collateral element must contain the independentAmount element. The independentAmount element must contain the payerPartyReference, the receiverPartyReference, and a single paymentDetail element. The payerPartyReference must be an empty element that must include the href attribute. The value of the hrep T receiverPartyReferenceof the href attribute will match the id attribute from the party element that defines the independent amount receiver. The paymentDetail element must omit the adjustablePaymentDate and the adjustedPaymentDate elements. The paymentDetail element must include either the paymentAmount element or thpaymentRule paymentAmount a currency amount. The paymentRule element is used to represent the Independent Amount as a percentage of the Notional Amount. When the paymentAmount element is used, the paymentAmount element mavalue “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency. The amount element value may have up to two places after the decimal point. The paymentRule element may be used instead of the paymentAmount element. The following diagram illustrates the PercentageRule data type, which is the actual type that the paymentRule element assumes as described below:


When the paymentRule element is used, it must include the xsi:type attribute with the value “PercentageRule” (xsi:type="PercentageRule"). This “types” the abstract paymentRule with the PercentageRule type. The paymentRule element must include the paymentPercent element, which must contain a decimal number with up to seven (7) decimal places. For example, enter 0.05 for 5%. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore, paymentPercent values of "0.05" and "0.0500000" will match. The value of the paymentPercent element may not be zero (0.0000000).

ence element. The the href attribute. The value of

The paymentRule element must also include the notionalAmountReferotionalAmountReference must be an empty element that must includen

the href attribute must be “equityDispersionVariance”. This is a pointer to the varianceSwapTransactionSupplement element, and is a general reference to the Variance Swap, since the base amount for the percentage is not directly contained in the transaction record. 7.6.8 FpML documentation Element


The documentation element within the trade element is used to specify the dates of the master confirmation agreement and the type of master confirmation used for this supplemental transaction. The documentation element must contain a masterConfirmation element. The documentation element may not include a masterAgreement, brokerConfirmation, contractualDefinitions, contractualSupplement, contractualTermsSupplement, contractualMatrix or

reditSupportDocument element.

he masterConfirmation element may optionally contain a masterConfirmationAnnexDate element. must follow the XML date pattern YYYY-MM-DD

ss rules this must be a valid date.

c The masterConfirmation element must contain a masterConfirmationType element. The value of the masterConfirmationType element must be one of:

“EquityAmericas“ “EquityEuropean” "ISDA2007VarianceSwapEuropean" "ISDA2007VarianceSwapAmerica"

The masterConfirmation element must contain a masterConfirmationDate element. The value of themasterConfirmationDate element must follow the XML date pattern YYYY-MM-DD convention. By DTCC Deriv/SERV business rules this must be a valid date. TThe optional masterConfirmationAnnexDateconvention. By DTCC Deriv/SERV busine


7.7 FpML – Equity Variance Option

The FpML element has an abstract content model allowing for several types of message to be included in

is base, encompassing element. The generic details for usage of the FpML element can be found in e “Message Architecture” document. The trade element contains the details of the Equity Variance ption itself.

ththO



The FpML Trade datatype allows a common representation of many OTC Derivative products while using the same generic XML structure. The usage of the Trade datatype is detailed in the “Message Architecture” document. The product element is abstract and has a unique representation for each OTC Derivative product type; the details of the product element for Equity Variance Option are represented as

e concrete element varianceOptionTransactionSupplement. th


7.7.2 FpML varianceOptionTransactionSupplement Element

For Equity Variance Index Option and Equity Variance Share Option, the varianceOptionTransactionSupplement must be included. When included the varianceOptionTransactionSupplement element, it must include the id attribute with the value “equityVarianceOption”. The productType element and productId elements are not allowed in DTCC Deriv/SERV.

he buyerPartyReference must be an empty element that must include the href attribute. The value of href attribute will match the id attribute from the element that defines the option buyer.

Tthe party The sellerPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the option seller.

The optionType element must contain the text “Call” or “Put”.


The equityPremium component specifies the amount and timing of the premium payment that is made for the equity option. It is described in section 7.7.4. The exercise provisions for the option are specified in the equityExercise component that is described in a following section. DTCC Deriv/SERV supports only European style option for a Variance Option.

The exchangeLookAlike, methodOfAdjustment, localJurisdiction, optionEntitlement, multiplier must not be used. 7.7.3 FpML equityExercise Element


The equityExercise element must contain the equityEuropeanExercise element.

tion.

he automatic Exercise element must be provided and must always contain the value “true”. The

he equityValuation element must be provided, and must be an empty element.

e provided and it must contain the currencyScheme attribute ith the value “http://www.fpml.org/ext/iso4217”, and the settlement currency that must adhere to this cheme by being a valid ISO 4217 currency. The value of the settlementCurrency element must be ame as the currency element described in varianceSwapTransactionSupplement.amount arianceAmount.currency.

The settlementPriceSource element must not be used. The settlementType element must always be provided and must have the value as “Cash”. The settlementMethodElectionDate, settlementMethodElectingPartyReference elements must not be used.

The equityEuropeanExercise element is described in the following sub-section. Remaining other

xercise elements are not applicable for Variance Ope The equityForwardExercise element must not be used. Tprepayment element may not be used.

T

he setTw

tlementCurrency element must b

ssv


7.7.3.1 FpML equityEuropeanExercise Element

The equityEuropeanExercise element must omit the id attribute and must contain the expirationDate element. The expirationDate element must omit the id attribute and releativeDate element. The expirationDate element must contain the adjustableDate element that in turn must omit the id attribute and must contain the unadjustedDate element with the expiration date. The date must follow the XML date convention of YYYY-MM-DD. Additionally the adjustableDate must contain the dateAdjustments element. The dateAdjustments element must omit the id attribute and must contain the businessDayConvention element with the value “NONE” and may not contain the businessCentersReference and businessCenters elements. The equityExpirationTimeType element must be provided and must always contain the value “Close”, meaning the official closing time of the exchange. The equityExpirationTime element must not be used.


7.7.4 FpML equityPremium Element


The payerPartyReference must be an emhe href attribute will match the id attribute

pty element that must include the href attribute. The value of from the party element that defines the option buyer. Note that

e premium payer must always be the option buyer.

The receiverPartyReference must be an empty element that must include the href attribute. The value of the href attribute will match the id attribute from the party element that defines the option seller. Note that the premium receiver must always be the option seller. The premiumType element must not be used. The paymentAmount element must be provided and it must contain the amount element with the aggregate premium, and the currency element. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the premium currency. The premium currency must adhere to this scheme by being a valid ISO 4217 currency. The amount element may have up to two places after the decimal point. From a DTCC matching perspective, there will be a matching tolerance of one currency unit. The paymentDate element must be provided. When provided, it must omit the id attribute and must contain the unadjustedDate with the premium payment date. The date must follow the XML date convention of YYYY-MM-DD. Additionally; paymentDate must contain the dateAdjustments element. The dateAdjustments element must omit the id attribute and must contain the businessDayConvention element with the value “NONE” and may not contain the businessCentersReference and businessCenters elements. The swapPremium, pricePerOption, and percentageOfNotional elements must not be used.

tth


7.7.5 FpML varianceSwapTransactionSupplement Element

The varianceSwapTransactionSupplement product element must replace the abstract product element and must not include the id attribute. The productType and the productId elements must not be included. The varianceLeg element must be included. For an Index Variance Swap Option the multipleExchangeIndexAnnexFallback element must be provided, otherwise not allowed. The localJurisdiction and the relevantJurisdiction elements are not allowed.


7.7.6 FpML varianceLeg Element

The varianceLeg element must not include the legIdentifier attribute, and must include thpayerPartyReference, receiverPartyReference, underlyer, valuation, and amount elements.

e

ntCurrency elements remaining all

an empty element that must include the href attribute. The riance

The varianceLeg element may include settlementDate and settlemeother elements must not be used. The payerPartyReference element must be value of the href attribute will match the id attribute from the party element that defines the vabuyer. The payerPartyReference element represents the variance buyer.


The receiverPartyReference element must be an empty element that must include the href attribute. The the id attribute from the party element that defines the variance ement represents the variance seller.

When included, the settlementDate element must omit the id attribute and the adjustableDate element, and must include the relativeDate element. The relativeDate element must omit the id attribute, and the businessCentersReference and businessCenters elements. The relativeDate element must include the periodMultiplier element with the integer number of days, the period element with a value of “D”, the dayType element with a value of “CurrencyBusiness”, and the businessDayConvention element with a value of “NONE”. The relativeDate element must also include the dateRelativeTo element, which must be an empty element that includes an href attribute with the value “valuationDate”. The settlementCurrency element must contain the currencyScheme attribute with the value http://www.fpml.org/ext/iso4217, and the value of the settlementCurrency element must adhere to this scheme by being a valid ISO 4217 currency. When included the settlementCurrency it must be same as varianceOptionTransactionSupplement.equityExercise.settlementCurrency. The underlyer element is described in Section 7.7.7

value of the href attribute will match seller. The receiverPartyReference el

The valuation element is described in Section 7.7.8 The amount element is described in Section 7.7.9 7.7.7 FpML underlyer Element

The underlyer element must contain the singleUnderlyer element. The basket element must not be

sed. u The singleUnderlyer element must contain one of the types that derive from and substitute for

nderlyingAsset since the underlyu ingAsset element is abstract. For a Share Variance Option, the equity element must be used in place of underlyingAsset. The equity element is described in Section 7.4.4.1. For a Index Variance Option, the index element must be used in place of underlyingAsset. The index element is described in Section7.4.4.2. The openUnits, dividendPayout and couponPayment elements must not be used.



The equity element must be used for a Share Variance Option and must not be used for an Index Variance Option. The equity element must omit the id attribute and must contain an instrumentId element. The instrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier must include the exchange code as a suffix. The RIC identifier is case sensitive. The description, currency, exchangeId, clearanceSystem and definition elements must not be used. The equity element must contain the relatedExchangeId, when included it must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier or the text “ALL” to denote All Exchanges or the text “N/A” to denote not applicable. The REC identifier is case sensitive. Deriv/SERV allows a maximum of 10 relatedExchangeId elements.

he element must not be used. T optionsExchangeId



he index element must be used for an Index Variance Option and must not be used for a Share TVariance Option. The index element must omit the id attribute and must contain an instrumentId element. The instrumentId element must contain the instrumentIdScheme attribute with a value of "http://www.fpml.org/spec/2003/instrument-id-Reuters-RIC" and must contain a valid RIC (Reuters Instrument Code) identifier. The RIC identifier is case sensitive. The RIC identifier must not include the exchange code as a suffix. The exchange code is contained in the exchangeId element, as explained elow.

he description, currency, clearanceSystem, definition, optionsExchangeId and futureId elements ust not be used.

The index element must include either a single exchangeId element or two (2) or more constituentExchangeId elements. The exhangeId element and constituentExchangeId elements must not be used at the same time. The exchangeId element, when included, must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier. The REC identifier is case sensitive.

b Tm


The constituentExchangeId elements, when included, must each contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier. Up to ten (10) constituentExchangeId elements can be included at the same time, but no less than two (2) can be specified at the same time. In the event that there is only a single Exchange for the asset being traded, the exchangeId element should be used. The REC identifier is case sensitive. The index element must contain the relatedExchangeId, when included it must contain the exchangeIdScheme attribute with the value "http://www.fpml.org/spec/2002/exchange-id-REC" and must contain a valid REC (Reuters Exchange Code) identifier or the text “N/A” to denote not applicable. The REC identifier is case sensitive. Deriv/SERV allows a maximum of 10 relatedExchangeId elements. 7.7.8 FpML valuation Element

The valuation element must not include the id attribute the valuationDates, valuationTimeType, and

he valuation element must include the valuationDate and may include the futuresPriceValuation

lude the id attribute with the value “valuationDate”. The aluationDate element must omit the relativeDateSequence element, and must include the

te convention of YYYY-MM-DD. The

valuationTime elements. Telement for Index Variance Option. The valuationDate element must incvadjustableDate element. The adjustableDate element must omit the id attribute and must include the unadjustedDate and dateAdjustments elements. The unadjustedDate element will contain the adjusted valuation date, which must follow the XML da


unadjustedDate must be same as the expirationDate element in equityEuropeanExercise. The

e Swap Option. The futuresPriceValuation element must contain a value of rue” or “false”.

dateAdjustments element must not include the id attribute, and the businessCentersReference and businessCenters elements. The dateAdjustments element must include the businessDayConvention element with the value “NotApplicable”. The futuresPriceValuation element may optionally be used for a Index Variance Swap Option, but must be omitted for Share Varianc“t The optionsPriceValuation must not be included.


7.7.9 FpML amount Element

The calculationDates element must not be included. The observationStartDate element is an optional element that is used to provide the Observation Start Date. When the observationStartDate element is omitted, the DTCC system will insert the trade date in that field on all outbound messages. When provided, the observationStartDate element must omit the dateRelativeTo element, and must include the adjustableDate element. The adjustableDate element must omit the id attribute and must include the unadjustedDate and dateAdjustments elements. The unadjustedDate element will contain


the date, which must follow the Xmust not include the id attribute,

ML date convention of YYYY-MM-DD. The dateAdjustments element and the businessCentersReference and businessCenters elements.

The dateAdjustments element must include the businessDayConvention element with the value “NotApplicable”. The optionsExchangeDividends element must not be included. The additionalDividends element must not be included. The allDividends element may be included for a Share Variance Option and must be omitted for an Index Variance Option. When provided, the allDividends element will have the value “true” when applicable, and the value “false” when not applicable. The variance element is described in Section 7.7.9.1



The initial price of the underlyer must be specified, by including one of the following elements

4. initialLevel element with a specific initial price, 5. closingLevel element with a value of “true” to indicate that the price at the close of trading on


Expiring Contract on the Observation Start Date will apply.


For a Index Variance Option the initialLevel element must be included when the closingLevel and the expiringLevel elements are not used and for a Share Variance Option the initialLevel element must be included when the closingLevel element is not used. When provided, the initialLevel element will contain a decimal value with up to two decimal places. For a Index Variance Option the closingLevel element must be included when the initialLevel and the expiringLevel elements are not used and for a Share Variance Option the closingLevel element must be included when the initialLevel element is not used. When provided, the closingLevel element must contain the value “true”. The expiringLevel element must contain the value “true” and may only be used for an Index Variance Option. The expiringLevel element must be included when the initialLevel and closingLevel are not used. The expiringLevel element must not be used for a Share Variance Option. The expectedN element is optional. When the expectedN element is included, it will contain an integer number that represents a number of days. The varianceAmount element must include the id attribute with the value “varianceAmountCurrency”. The varianceAmount element must also include the currency and amount elements. The currency element must contain the currencyScheme attribute with the value http://www.fpml.org/ext/iso4217, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency. The amount element must contain a decimal value with up to twelve whole numbers with two decimal places. The convention for computing the Variance Amount is the vega notional divided by two times the strike price. The volatilityStrikePrice element must not be included. The varianceStrikePrice element must be included and will contain a decimal value that may have up to eleven whole numbers with four decimal places. The varianceCap element may optionally be used. When the varianceCap element is used it must contain the value “false” for Variance Cap is not applicable and “true” for Variance Cap is applicable. The unadjustedVarianceCap element must be included when the varianceCap element contains the value “true” otherwise optional. The unadjustedVarianceCap element will contain the computed Variance Cap (the variance cap factor squared times the variance strike price), as a decimal value up to eleven whole numbers with four decimal places. Zero is not a valid value. For an Index Variance Option, the exchangeTradedContractNearest element is required when either Future Price Valuation contains the value “true” otherwise it is not allowed. When provided, the exchangeTradedContractNearest element must omit the id attribute, and the description, currency, exchangeId, clearenceSystem, definition, relatedExchangeId, optionsExchangeId, multiplier, contractReference, and expirationDate elements. When provided, the

xchangeTradedContractNearest element must include the instrumentId element. The instumentId ust contain June 2004

eelement must include the instrumentIdScheme attribute with the value “MonthYearId”, and mthe n in the format of MMYY. For example, mo th and year of the futures contract. This must be would be represented with “0604”. The vegaNotionalAmount element is not allowed.



The use of the element within the element is optional.

f attribute will match the id attribute from the party element that defines the independent amount ayer.

he must be an empty element that must include the href attribute. The value

e element. The element is used to represent the Independent Amount as

ust include the currency nd the amount elements. The currency element must contain the currencyScheme attribute with the

is aces after

element. The following diagram t

collateral trade When the collateral element is used, the collateral element must contain the independentAmount element. The independentAmount element must contain the payerPartyReference, the receiverPartyReference, and a single paymentDetail element. The payerPartyReference must be an empty element that must include the href attribute. The value of the hrep T receiverPartyReferenceof the href attribute will match the id attribute from the party element that defines the independent amount receiver. The paymentDetail element must omit the adjustablePaymentDate and the adjustedPaymentDate elements. The paymentDetail element must include either the paymentAmount element or thpaymentRule paymentAmount a currency amount. The paymentRule element is used to represent the Independent Amount as a percentage of the Notional Amount. When the paymentAmount element is used, the paymentAmount element mavalue “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to thscheme by being a valid ISO 4217 currency. The amount element value may have up to two plthe decimal point. The paymentRule element may be used instead of the paymentAmountillustrates the PercentageRule data type, which is the actual type that the paymentRule elemenassumes as described below:


When the paymentRule element is used, it must include the xsi:type attribute with the value “PercentageRule” (xsi:type="PercentageRule"). This “types” the abstract paymentRule with the PercentageRule type. The paymentRule element must include the paymentPercent element, which must contain a decimal number with up to seven (7) decimal places. For example, enter 0.05 for 5%. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore, paymentPercent values of "0.05" and "0.0500000" will match. The value of the paymentPercent element may not be zero (0.0000000).

ence element. The the href attribute. The value of

The paymentRule element must also include the notionalAmountReferotionalAmountReference must be an empty element that must includen

the href attribute must be “equityVarianceOption”. This is a pointer to the varianceOptionTransactionSupplement element, and is a general reference to the Variance Option, since the base amount for the percentage is not directly contained in the transaction record. 7.7.11 FpML documentation Element


The documentation element within the trade element is used to specify the dates of the master confirmation agreement and the type of master confirmation used for this supplemental transaction. The documentation element must contain a masterConfirmation element. The documentation element may not include a masterAgreement, brokerConfirmation, contractualDefinitions, contractualSupplement, contractualTermsSupplement, contractualMatrix or

reditSupportDocument element.

value of the

nt. YYY-MM-DD

onvention. By DTCC Deriv/SERV business rules this must be a valid date.

c The masterConfirmation element must contain a masterConfirmationType element. The value of the masterConfirmationType element must be one of:

“EquityAmericas” “EquityEuropean” “ISDA2007VarianceOptionEuropean”

The masterConfirmation element must contain a masterConfirmationDate element. ThemasterConfirmationDate element must follow the XML date pattern YYYY-MM-DD convention. ByDTCC Deriv/SERV business rules this must be a valid date. The masterConfirmation element may optionally contain a masterConfirmationAnnexDate eleme

he optional masterConfirmationAnnexDate must follow the XML date pattern YTc


7.8 Exit Element

The Exit element is used to exit a transaction, for any reason, from the DTCC Deriv/SERV system. Exit transactions must be matched and confirmed; Exit from the DTCC Deriv/SERV system is bilateral and not unilateral. The details for the Exit element must follow the rules in the “Message Architecture” document.


7.9 PostTrade

A Post-Trade transaction is a transaction between parties that involves an existing underlying trade. Typically, the underlying trade is referenced, and the pertinent details of the post-trade transaction are included. PostTrade is an abstract type and the head of a substitution group that includes the various post-trade transactions. The PostTrade element may not be used in any records; it must be substituted with one of the following derived types:

• Termination • Increase • Amendment

Note that DTCC Deriv/SERV does not currently support Assignment record matching for Equity Derivatives. The details for the PostTrade element must follow the rules in the “Message Architecture” document except for the Equity Derivative specific rules as detailed below.


7.9.1 PostTrade Element

The abstract PostTrade element defines the elements that are collectively used in the derived types. This includes the trade, partyTradeIdentifier, EquityAdditionalFields, payment, collateral, party, and TradeReferenceInfo elements. The trade element for Equity Derivatives follows the rules defined in the sections above. The remaining elements contained in the PostTrade element follow the rules in the “Message Architecture” document.

he EquityAdditionalFields element is explained in section 7.1.1T . The PostTradeAdditionalFields element is explained in section 7.6.1.2. The collateral element is explained in section 7.9.2.2 and may only be used on a Partial Termination Equity Swap and a Partial Termination Equity Option.


7.9.1.1 trade Element

The trade element is used for representing the details of the original underlying trade, either with a scaled-down subset of the full trade details, or with the full trade representation. This element is the same element that is contained in the FpML portion of a New Trade submission. The usage of the elements comprising the trade element for a post-trade type transaction is the same as the usage for a Trade.


The trade element contains a tradeHeader that is used to identify the submitter, and the submitter’s trade reference number and trade reference number supplement. The tradeDate is the trade date of the underlying transaction. The trade element contains the abstract product element that is replaced with the specific concrete product. The trade element also contains the collateral and documentation element. For Equity Option, refer to Sections 7.2.2-7.2.8 for the usage rules of these elements. For Equity Swap, refer to Sections7.3.2-7.3.77for the usage rules of these elements. For Variance Swap, refer to Sections 7.4.2-7.4.8 for the usage rules of these elements. For Dividend Swap, refer to Sections 7.5.8-7.5.9 for the usage rules of these elements. 7.9.1.2 PostTradeAdditionalFields

The PostTradeAdditionalFields element must contain the EquityPostTradeAdditionalFields element. The EquityPostTradeAdditionalFields element must contain the EquitySwapPostTradeFields element may The EquitySwapPostTradeFields element may only be used for an Increase, Partial Termination, and Full Termination. The EquitySwapPostTradeFields element may contain the IntialPrice element and the AggregateAveragingPrice element. The InitialPrice element is defined below and the AggregateAveragingPrice element must contain 0 to 11 whole numbers with 0 to 7 decimal places. The AggregateAveragingPrice element is not allowed when masterConfirmationType is "GlobalMCA"


7.9.1.2.1 InitialPrice

The InitialPrice element must omit include the determinationMethod, amountRelativeTo, grossPrice, accruedInterestPrice, clearNetPrice, quotationCharacteristics and valuationRule elements. The initialPrice element may only include the commission element for an “EquityAsia” MCA when netPrice element is used (see below). When included, the commsission element must include the commissionDenomination element with the value of “Percentage”, and the commissionAmount element must contain a percentage value with up to 7 decimal places. For example 5% would have the 0.05. The initialPrice element must include the netPrice element. The netPrice element must include the currency, amount and priceExpression elements.The currency element that contains a valid ISO currency and must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217“. The amount element must contain 0 to 11 whole numbers with 0 to 7 decimal places. The priceExpression element must contain the value “AbsoluteTerms”.


The InitialPrice element may only include the fxConversion element for an EquityAsia MCA when the

etPrice element is populated, and is not allowed otherwise. The fxConversion element will be defined in section 7.3.3.2.1. 7.9.1.2.1.1 FpML fxConversion Element

n

The fxConversion element may only be used for an EquityAsia MCA for Index/Share Swap, and not allowed otherwise. The fxConversion element must omit the amountRelativeTo element and must contain the fxRate element. The fxRate element must contain the quotedCurrencyPair and the rate elements. The quotedCurrencyPair element must contain the currency1, currency2 and quoteBasis elements. The currency1 element is the Gross Price Currency, and the currency2 element must have the same currency as the equitySwapTransactionSupplement.returnLeg.rateOfReturn. initialPrice.netPrice.currency. The quotaBasis element must have the value “Currency1PerCurrency2”. The rate element is a decimal value that may contain up to five places after the decimal point. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore values of "100.5" and "100.50000" will match.


7.9.2 Termination Element

The Termination element is used to terminate a trade prior to the expiration date. The Termination element can be used to effect a full or partial termination of a trade previously entered into the DTCC Deriv/SERV system, or a trade that was not previously submitted to the system. The Termination element is used for both full and partial terminations. A Termination element will include either a TradeReferenceInfo element or the following set of elements:

• trade or partyTradeIdentifier


• EquityAdditionalFields • PostTradeAdditionalFields • TerminationProvisions • Optionally contain a payment element • two (2) party elements

The EquityAdditionalFields element is explained in section 7.1.1. The PostTradeAdditionalFields element is explained in section 7.6.1.2 The TerminationProvisions element will follow the rules in the Messaging Architecture Document. However, the following rules only apply to an Equity Swap.

1. On a Full Termination, TerminationProvisions.Full.DecreaseInNumberOfUnits must be populated an “EquityAsia” MCA and is otherwise optional.

2. On a Partial Termination, both TerminationProvisions.Partial.DecreaseInNotionalAmount and TerminationProvisions.Partial.OutstandingNotionalAmount may be populated when both TerminationProvisions.Partial.DecreaseInNumberOfUnits and TerminationProvisions.Partial.OutstandingNumberOfUnits are populated. Otherwise, TerminationProvisions.Partial.DecreaseInNotionalAmount and TerminationProvisions.Partial.OutstandingNotionalAmount are required.

3. On a Partial Termination, both TerminationProvisions.Partial.DecreaseInNumberOfUnits and TerminationProvisions.Partial.OutstandingNumberOfUnits must be populated for an “EquityAsia” MCA. For all other MCAs, these fields must both be populated or neither of them populated.

For a Share or Index Swap, where masterConfirmationType is “GlobalMCA” the following additional rules will apply.

1. On a Full Termination, TerminationProvisions.Full.PriorNotionalAmount may be included. When included the PriorNotionalAmount element must include the currency and the amount elements. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency. The amount element value may have up to two places after the decimal point.

For a Spread Option/Cliquet Option or when the sub product type is “Spread” or “Cliquet” the following rules will apply.

1. When notional element is present on the underlying trade, the Partial Termination must include both TerminationProvisions.Partial.DecreaseInNotionalAmount and TerminationProvisions.Partial.OutstandingNotionalAmount; otherwise both the elements are

tandingVarianceAmount element (the variance

not allowed on a Partial Termination.

For a Variance Swap trade, the Partial element must contain a DecreaseInVarianceAmount element ndicating the variance amount reduced) and an Outs(i

amount remaining after the partial termination).


For a lement must contain a DecreaseInNumberOfUnits element (indi an OutstandingNumberOfUnits element (the number of sha on). For a Va contain a DecreaseInVarianceAmount element nd an OutstandingVarianceAmount element (the variance mount remaining after the partial termination).

TradeIdentifier element will be used. The of three ways:

Equity

ing the the

re” document.

Note that the below fields that are marked with an *asterisk are required FpML fields that re insignificant because they will always contain set values as per DTCC business rules. The following

eme=” TradeRefNbrSupplement”

buyerPartyReference

[for Share Option] equityExercise

[for European-style only]

[for American-style only] commencementDate

expirationDate

Dividend Swap trade, the Partial ecating the number of shares reduced) and

res remaining after the partial terminati

riance Option trade, the Partiaicating the variance amount reduced) and

l element must (ia

7.9.2.1 trade or partyTradeIdentifier For an Activity of New or Modify, the trade or partyunderlying trade being terminated can be represented in one

1. partyTradeIdentifier which contains: partyReference tradeId with tradeIdScheme=”TradeRefNbr” tradeId with tradeIdScheme=” TradeRefNbrSupplement”

2. trade element with a scaled-down subset of a full trade representation (available forOption only).

3. trade element with the full trade details. Using option 1, it is sufficient for a submitter to supply its trade reference identifier uspartyTradeIdentifier element. The details for the partyTradeIdentifier element are found in “Message Architectu Using option 2 (for Equity Option only), the submitter can supply the trade element with a subset of full trade elements. atrade elements (and all container elements) can be submitted as follows: tradeHeader partyReference tradeId with tradeIdScheme=”TradeRefNbr” tradeId with tradeIdSch tradeDate equityOptionTransactionSupplement sellerPartyReference

optionType underlyer

index.instrumentId and index.exchangeId [for Index Option] or equity.instrumentId

equityEuropeanExercise expirationDate *equityExpirationTimeType (always “Close”) equityAmericanExercise


*latestExerciseTimeType (always “Close”) *equityExpirationTimeType (always “Close”)

equityBermudaExercise [for Bermuda-style only] *commencementDate (always trade date)

meType (always “Close”) *equityExpirationTimeType (always “Close”) *automaticExercise (always “true”) *equityValuation (empty element)

ncy

r forward starting Index/Share Options]

ull Termination, the numberOfOptions element will

expirationDate bermudaExerciseDates *latestExerciseTi

settlementCurre settlementTypestrike

strikePrice [for Index Option] or strikePrice and strike.currency [for Share Option] strikePercentage [fo

tions numberOfOp*equityPremium *payerPartyReference (always the buyer)

*receiverPartyReference (always the seller)

orF option 2 (used only for Equity Option), on a Fcontain the number of options just prior to the termination. On a Partial Termination, the numberOfOptions element will contain the Outstanding Number of Options after the Termination, which must be the same value as that contained in

erminationProvisions.Partial.OutT standingNumberOfOptions.

e trade element values do not ade details, the Termination submission will be rejected.

s specified in the “Message Architecture”

Using option 3, the full information as documented in Trade above would be submitted. When the trade element is used, the information contained in the trade element must match the data on

e Trade previously submitted to the DTCC Deriv/SERV system. If ththmatch the underlying tr The remaining aspects of the Termination follow the ruledocument.


7.9.2.2 Collateral (for Partial Terminations only)

The use of the c tional.

ment is used, the collateral element must contain the independentAmount the

hat defines the independent amount

ribute. The value

adjustedPaymentDate

amount. The paymentRule element is used to represent the Independent Amount as a percentage of the Notional Amount. When the paymentAmount element is used, the paymentAmount element must include the currency and the amount elements. The currency element must contain the currencyScheme attribute with the value “http://www.fpml.org/ext/iso4217”, and the value of the currency element must adhere to this scheme by being a valid ISO 4217 currency. The amount element value may have up to two places after the decimal point. On an Equity Swap and,Equity Variance Swap and Equity Variance Option the paymentRule element may be used instead of the paymentAmount element. The following diagram illustrates the PercentageRule data type, which is the actual type that the paymentRule element assumes as described below:

ollateral element within the Termination element is op When the collateral eleelement. The independentAmount element must contain the payerPartyReference, receiverPartyReference, and a single paymentDetail element. The payerPartyReference must be an empty element that must include the href attribute. The value ofthe href attribute will match the id attribute from the party element tayer. p

he receiverPartyReference must be an empty element that must include the href attT

of the href attribute will match the id attribute from the party element that defines the independent amount receiver.

he paymentDetail element must omit the adjustablePaymentDate and theTelements. The paymentDetail element must include either the paymentAmount element or the paymentRule element. The paymentAmount element is used to represent the Independent Amount as a currency


When the paymentRule element is used, it must include the xsi:type attribute with the value “PercentageRule” (xsi:type="PercentageRule"). This “types” the abstract paymentRule with the PercentageRule type. The paymentRule element must include the paymentPercent element, which must contain a decimal number with up to seven (7) decimal places. For example, enter 0.05 for 5%. From a DTCC matching perspective, trailing zeros will not be considered during the matching process, therefore, paymentPercent values of "0.05" and "0.0500000" will match. The value of the paymentPercent element may not be zero (0.0000000). On an Equity Swap only, the paymentRule element must also include the notionalAmountReference element. The notionalAmountReference must be an empty element that must include the href attribute. The value of the href attribute must be “outstandingNotionalAmount”.

unt element must contain

paymentRule element must also

Furthermore, the TerminationProvisions.Partial.OutstandingNotionalAmoan ID attribute with the value ”outstandingNotionalAmount” when the Partial Termination Collateral paymentRule element is used. On an Equity Variance Swap and Equity Variance Option only, theinclude the notionalAmountReference element. The notionalAmountReference must be an empty element that must include the href attribute. The value of the href attribute must be “outstandingVarianceAmount”. Furthermore, the TerminationProvisions.Partial.OutstandingVarianceAmount element must contain an ID attribute with the value ”outstandingVarianceAmount” when the Partial Termination Collateral paymentRule element is used.


7.9.3 Increase Element

The Increase element is used to increase the number of options or the notional amount of a trade. The Increase element can be used to effect an increase in the number of options or the notional for a trade previously entered into the DTCC Deriv/SERV system, or a trade that was not previously submitted to the system. An Increase element will include either a TradeReferenceInfo element or the following set of elements:

• trade or partyTradeIdentifier • EquityAdditionalFields • PostTradeAdditionalFields • IncreaseProvisions


• Optionally contain a payment element • two (2) party elements

s element is explained in section 7.1.1 The EquityAdditionalField The PostTradeAdditionalFields element is explained in section 7.6.1.2 The IncreaseProvisions element will follow the rules in the Messaging Architecture Document. However, the following rules only appliy to an Equity Swap.

1. On an Increase, both IncreaseProvisions.IncreaseInNotionalAmount and IncreaseProvisions.OutstandingNotionalAmount must be populated when IncreaseProvisions.IncreaseInNumberOfUnits is omitted.

2. On an Increase, both IncreaseProvisions.IncreaseInNotionalAmount and IncreaseProvisions.OutstandingNotionalAmount may be populated when IncreaseProvisions.IncreaseInNumberOfUnits is populated.

3. On an Increase, both IncreaseProvisions.IncreaseInNumberOfUnits and IncreaseProvisions.OutstandingNumberOfUnits must be populated for an “EquityAsia” MCA.

For a Spread Option/Cliquet Option or when the sub product type is “Spread” or “Cliquet” the following rules will apply.

1. When notional element is present on the underlying trade the Partial Termination must include both IncreaseProvisions.Partial. IncreaseInNotionalAmount and IncreaseProvisions.Partial.OutstandingNotionalAmount; otherwise both the elements are not allowed on a Increase transaction.

2. When numberOfOptions element is other than “0.0099” on the underlying trade the Partial Termination must include both IncreaseProvisions.Partial. IncreaseInNumberOfUnits and IncreaseProvisions.Partial.OutstandingNumberOfUnits; otherwise both the elements are not allowed on a Increase transaction.

For a Variance Option trade, the IncreaseProvisions element must contain a IncreaseInVarianceAmount element (indicating the variance amount reduced) and an OutstandingVarianceAmount element (the variance amount remaining after the partial termination).

7.9.3.1 trade or partyTradeIdentifier For an Activity of New or Modify, the trade or partyTradeIdentifier element will be used. The underlying trade being increased can be represented in one of three ways:

1. partyTradeIdentifier which contains: a. partyReference

element with the full trade details.

part r the partyTradeIdentifier element are found in the “Me

b. tradeId with tradeIdScheme=”TradeRefNbr” c. tradeId with tradeIdScheme=” TradeRefNbrSupplement”

2. trade element with a scaled-down subset of a full trade representation (available for Equity Option only).

3. trade Using optio itter to supply its trade reference identifier using then 1, it is sufficient for a subm

ails foyTradeIdentifier element. The detssage Architecture” document.


Usi an supply the trade element with a subset of full trade el arked with an *asterisk are required FpML fields that

re insignificant because they will always contain set values as per DTCC business rules. The following

partyReference

Supplement”

n] or

equityExercise

expirationDate *equityExpirationTimeType (always “Close”)

ciseTimeType (always “Close”)

ate bermudaExerciseDates

*equityValuation (empty element) ency

n] rting Index/Share Options]

mberOfOptions element will contain the Outstanding

ng option 2 (for Equity Option only), the submitter cements. Note that the below fields that are m

atrade elements (and all container elements) can be submitted as follows: tradeHeader tradeId with tradeIdScheme=”TradeRefNbr” tradeId with tradeIdScheme=” TradeRefNbr tradeDate equityOptionTransactionSupplement buyerPartyReference sellerPartyReference

optionType underlyer

index.instrumentId and index.exchangeId [for Index Optioequity.instrumentId [for Share Option]

equityEuropeanExercise [for European-style only]

equityAmericanExercise [for American-style only] commencementDate

expirationDate *latestExer

*equityExpirationTimeType (always “Close”) equityBermudaExercise [for Bermuda-style only]

*commencementDate (always trade date) expirationD

*latestExerciseTimeType (always “Close”) *equityExpirationTimeType (always “Close”) *automaticExercise (always “true”)

settlementCurr settlementTypestrike

strikePrice [for Index Option] or strikePrice and strike.currency [for Share OptiostrikePercentage [for forward sta

numberOfOptions *equityPremium *payerPartyReference (always the buyer)

(always the seller) *receiverPartyReference

oF

Nr option 2 (used only for Equity Option), the nu

umber of Options after the Increase, which must be the same value as that contained in IncreaseProvisions.OutstandingNumberOfOptions. Using option 3, the full information as documented in Trade above would be submitted.


When the trade element is used, the information contained in the trade element must match the data on the Trade previously submitted to the DTCC Deriv/SERV system. If the trade element values do not match the underlying trade details, the Increase submission will be rejected. The remaining aspects of the Increase follow the rules specified in the “Message Architecture” document.


7.9.4 Amendment Element

The Amendment13 element is used to modify any of the trade details with the exception of the parties to the trade. The Amendment element can be used to effect trade detail changes to a trade previously confirmed in the DTCC Deriv/SERV system. The Amendment element will follow the rules detailed in the “Message Architecture” document except in each case where the trade element is referenced then the details in Section 7.2Error! Reference source not found. (Equity Option), Section 7.3 (Equity Swap), Section 0 (Variance Swap), and Section 7.5 (Dividend Swap) of this document will apply. The EquityAdditionalFields element is explained in section 7.1.1.

13 Amendment of numberOfOptions element is not allowed on a Cliquet Option.Please refer section 7.2.2.


7.10 Error

The Error element is used to report back to the submitter that errors have been detected in the message submitted to DTCC’s Deriv/SERV system. The Error element will follow the rules detailed in the “Message Architecture” document.


7.11 Workflow Fields

Deriv/SERV transaction records may optionally include the following elements

• comment • superId • deskId • eTradeId • designatedParty • brokerName

These workflow fields14 are designed to enable users to better manage their workflow. These fields will typically be used to organize, route and prioritize Deriv/SERV records. The “workflow fields” are all optional and nonmatching 14 For a Dispersion trade, except eTradeId element remaining other workflow fields are common fields between Dispersion Index Variance Swap and all Dispersion Share Variance Swap components.


1. comment – The comment element will will enable users to flag transactions for internal

processes according to their own schemes as free-form text. Unlike the other new fields, the Comment field will not be visible to the counterparty or included in the counterparty’s output records. (up to 254 characters)

2. super ID – The superId element will contain an identifier that may be used to group or link related

transactions, whether part of a block, strategy, collateral link, or other group; modeled on the current transaction reference number (up to 20 characters).

3. deskId - The deskId element will contain the identifier related to the trader’s desk, a string with a

maximum size of 50 characters.

4. eTradeId – The eTradeId element will contain the Trader’s internal reference identifier assigned to a trade (up to 40 characters).

5. designatedParty – The designatedParty element is a free-form text field,subjected to a limitation

of 20 charecters, used by Prime Brokers to identify the PB customer on a transaction.

6. brokerName – The brokerName element represents name of the internal broker who is involved in the transaction,subjected to a limitation of 40 charecters.

The OTC_Matching element is used in all DTCC messages and it may contain WorkflowData element. The WorkflowData element must contain the PartyWorkflowFields and must not contain the WorkflowTransType or the ContraWorkFlowFields elements. The ContraWorkFlowFields element is used to in DTCC output messages to display the counterparty’s workflow fields. The PartyWorkflowFields element may contain the comment,superId deskId, eTradeId, designatedParty or brokerName elements. Deriv/SERV output messages will include the “workflow fields” whenever they have been populated. The Comment field will only be included in output to the party that submitted it; the other workflow fields will be included in output to both parties. In addition, if the transaction is confirmed, the output messages will contain the workflow fields of both parties. For example, on a confirmed trade, a user might see his comment and the superId fields along with his counterparty’s superId field.

y and brokerName lements may include an action attribute with the value “erase” on a WorkflowUpdate element. When

attribute with the value “erase” the workflow fields will override the underlying value

lues d uses of the workflow fields, the data in these fields will be constant through in other cases, these fields will contain distinct data for each post-trade

will apply defaulting logic to allow users to carry-over values from the underlying

defaulting processes work.

The workflow fields comment, superId, deskId, eTradeId, designatedParteincluded the action with blank. 7.11.1 Default VaFor many of the anticipate

al;the lifecycle of the detransaction. Deriv/SERV trade record to the initial “New” submission of each post-trade record. Deriv/SERV will also apply separate defaulting logic to allow users to carry-over values from the previous submission of any transaction record to the subsequent “Modify” submission. The following explains how these two

A. Default Values for “New” post-trade submissions


The following post-trade submissions will be subject to the defaulting described below: Termination (full

tion is accepted for processing, the set of workflow fields urrently associated with the underlying trade record” (whether confirmed or unconfirmed) will serve as

• “Current” means the latest submitted set of workflow fields that were included on the underlying

• Other post-trade transaction records will be ignored. (For example, a Trade and Partial

ing on the second Partial Termination. In this example, only the current set of workflow fields associated

• Any workflow fields included in the submission of the post-trade transaction record will override the default values from the “underlying trade record”. To override a default value with a blank, the

t

the post-trade transaction. The following explains more distinctly how

ue that is different than the

ade and post-trade “Modify” submissions

odify record.

ields associated with this specific

and partial), Increase, Amendment and Exit. This defaulting will only apply to the initial “New” post-trade submissions and not subsequent “Modify” submissions. This defaulting will only apply to post-trade events where the “underlying trade record” was previously sent to the system and not to outside post-trade events. When a post-trade transac“cthe default values for the workflow fields on the post-trade transaction record. For purposes of determining the set of workflow fields “currently associated with the underlying trade record”, the following logic will be used: The “underlying trade record” is the Trade or the last Amendment.

trade record (as defined above) or on a Workflow Update that referenced that record.

Termination confirmed and then a second Partial Termination was submitted. The set of workflow fields associated with the first Partial Termination will not have any bear

with the Trade will be used for defaulting).

user will include an explicit erase flag on the appropriate fields. It is important to understand thathe new (or blank) values that are submitted will override the defaults for the current submission, but will not affect the values associated with the “underlying trade record”.

• Additionally, any subsequent modifications to the workflow fields on the “underlying trade record”

will not be propagated todefaulting will work for each individual workflow field on the post-trade submission:

• If the element for the workflow field is omitted, or the element is included and is

empty: The value will be taken from the underlying trade record.

• If the workflow field is included on the record with a valvalue on the underlying trade record: The submitted value will be used.

• If the record includes the erase flag on this workflow field: The workflow field will be blank and the element for this field will not be included on the output messages.

B. Default Values for TrThe following “Modify” submissions will be subject to the defaulting described below: Trade, Termination (full and partial), Increase, Amendment, and Exit. This defaulting will only apply to subsequent “Modify” submissions and not initial “New” transaction submissions. When a “Modify” submission is accepted for processing, the “current set of workflow fields associated with this specific record” will serve as the default values for the workflow fields on the M For purposes of determining the “current set of workflow f


record”, the following logic will be used:

• “Current” means the latest submitted set of workflow fields that were included on this sptransaction record or on a Workflow Update that referenced this specific transaction record.

• Other Trade and post-trade transaction records will be ignored. (For example, a Trade and Partia

Termination confirmed and then a second Partial Termination was submitted. SubseModify of the second Partial Termination was submitted. The sets of workflow fields associated with the Tr

ecific

l quently, a

ade and first Partial Termination will not have any bearing on the Modify of the second Partial Termination. Only the current set of workflow fields associated with the second Partial

lue that is different than the default value: The submitted value will be used.

Termination will be used for defaulting).

• If the element for the workflow field is omitted, or the element is included and is empty: The default value will be used. If the workflow field is included on the record with a va

• If the record includes the erase flag on this workflow field: The workflow field will be blank and the

element for this field will not be included on the output messages.


7.12 Schemas & Sample Messages

DTCC h ages sho

owing mandatory rule: the schemaLocation must be as

ticipant section of the DTCC

as prepared a number of sample messages corresponding to the above rules. These mess

uld be read with this documentation – where the documentation above is unclear the actual message should provide clarity. DTCC has validated both the schemas and the sample messages with both OxygenXML and Xerces. Schema diagrams and images have been generated by TIBCO TurboXML.

DTCC Deriv/SERV system imposes the follThe shown in the sample messages. This rule may seem arbitrary; however, it assures simplicity of problem resolution where three parties (you, your counterparty and DTCC) are involved.

ou will find the schemas and sample FpML messages in the ParYDeriv/SERV web site at:

http://derivserv.dtcc.com


8 Appendix A – Spreadsheet to FpML Mapping

ied by the Section column next to the field. Some fields may be found in multiple ections because they map to multiple FpML paths.

This appendix can is used to match the Spreadsheet Upload Documentation fields to their counterparts in the FpML. This can be accomplished by identifying the field you want in this table, going to the section(s) in this document identifs

8.1 Equity Options Field Mappings

Column # Index Data Field Section Notes 1 A Comment Specific to Spreadsheet Upload 2 B Activity See “Messaging Architecture” document

3 C Transaction Type See “Messaging Architecture” document 4 D Product Type See “Messaging Architecture” document

5 E Originator ID 7.1 See “Messaging Architecture” document 6 F Trade Reference Number 7.1, 7.2.1 See “Messaging Architecture” document 7 G Counterparty ID See “Messaging Architecture” document 8 H Trade Date 7.2.4.2 See “Messaging Architecture” document 9 I Master Confirm Date 7.2.8

10 J Master Confirmation Transaction Type 7.2.8 11 K Option Style 7.2.4 Also see 7.2.4.1 and 7.2.4.2 12 L Option Type 7.2.2 13 M Seller 7.1.1, 7.2.2, 7.2.6 14 N Buyer 7.2.2, 7.2.6 15 O Shares ID / Index ID 7.2.3.1, 7.2.3.2 16 P Exchange ID 7.2.3.1 17 Q Related Exchange ID 7.2.3.1, 7.2.3.2 18 R Number of Options 7.2.2, 7.2.4.2 19 S Strike Price 7.2.2 20 T Strike Price Currency 7.2.2 21 U Premium Amount 7.2.6 22 V Premium Currency 7.2.6 23 W Premium Payment Date 7.2.6 24 X Expiration Date 7.2.4.1, 7.2.4.2 25 Y Settlement Currency 7.2.4 26 Z Settlement Method 7.2.4 27 AA Settlement Date (Number of Days After

Valuation) 7.2.4.5

28 AB Minimum Number of Options 7.2.4.2 29 AC Integral Multiple 7.2.4.2 30 AD Averaging Dates 7.2.4.4 31 AE Futures Price Valuation (Y/N) 7.2.4.4 32 AF Exchange Traded Contract 7.2.3.1 33 AG Electing Party 7.2.4 34 AH Independent Amount 7.2.6


35 AI Independent Amount Currency 7.2.6 36 AJ Independent Amount Payer 7.2.6 37 AK Independent Amount Receiver 7.2.6 38 AL Master Confirm Annex Date 7.2.8 39 AM Trade Reference Number Supplement See “Messaging Architecture” document 40 AN Post Trade Transaction Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document 41 AO Post Trade Effective Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document 42 AP Affected Number of Options 7.9.2, 7.9.3 See “Messaging Architecture” document 43 AQ Outstanding Number of Options 7.9.2, 7.9.3 See “Messaging Architecture” document 44 AR Post Trade Payment Amount See “Messaging Architecture” document 45 AS Post Trade Payment Currency See “Messaging Architecture” document 46 AT Post Trade Payment Date See “Messaging Architecture” document 47 AU Post Trade Payment Payer See “Messaging Architecture” document 48 AV Post Trade Pa yment Receiver See “Messaging Architecture” document 49 AW DK Reason 7.8 See “Messaging Architecture” document 50 AX Exit Message 7.8 See “Messaging Architecture” document 51 AY Exit Additional Message See “Messaging Architecture” document 52 AZ Independent Amount Percentage .2.6 7 53 BA 15A-6 Rule 7.1.1 54 BB Post Trade Independent Amount 7.8.2.2

55 BC Post Trade Independent Amount Currency 7.8.2.2 56 BD Post Trade Independent Amount Payer 7.8.2.2

57 BE nt Amount Receiver Post Trade Independe 7.8.2.2 58 BF Local Jurisdiction 7.2.2 59 BG pe Settlement Ty 7.2.4 60 BH Reference Currency 7.2.4 61 BI Option Entitlement 7.2.2 62 BJ Multiplier 7.2.2 63 BK Annex Amendment Date 7.2.8 64 BL Internal Comment 7.11 65 BM Link Transaction ID 7.11 66 BN Reference Currency Primary Rate Source 7.2.5.5 67 BO urrency Primary Rate Source Reference C

Page 7.2.5.5

68 BP Reference Currency Primary Rate Source Page Heading

7.2.5.5

69 BQ ondary Rate Reference Currency SecSource

7.2.5.5

70 BR Reference Currency Secondary Rate Source Page

7.2.5.5

71 BS Reference CurrencySource Page Headin

Secondary Rate g

7.2.5.5

72 BT Reference Currency Fixing Time 7.2.5.5 73 BF Reference Currency Business Days 7.2.5.5 74 BV Exchange Look-alike 7.2.2 75 BW Multiple Exchange Index Annex Fallback 7.2.2 76 BY Strike Price Percent 7.2.2 77 BY Strike Date 7.1.1 78 BZ E-Trading TRN 7.11 79 CA Broker Name 7.11


80 CB Desk ID 7.11 81 CC Designated party ID 7.11 82 CD Contractual Supplements 2.1.1, 7.2.8 83 CE Multiple Exercise 7.2.4.2, 7.2.4.3 84 CF Potential Exercise Dates 7.2.4.3 85 CG Commencement Date 7.2.4.2, 7.2.4.3 86 CH Sub Product Type See “Messaging Architecture” document 87 CI First Averaging Date 7.2.4.4 88 CJ Last Averaging Date 7.2.4.4. 89 CK Averaging Frequency 7.2.4.4. 90 CL Averaging Roll Convention 7.2.4.4. 91 CM Averaging Weight 7.2.5.1.1 92 CN Averaging Date Disruption 7.2.5.1.1 93 CO Cap 7.2.5.1.2 94 CP Cap Percent 7.2.5.1.2 95 CQ Floor 7.2.5.1.2 96 CR Floor Percent 7.2.5.1.2 97 CS Index Price 7.2.2 98 CT Notional Amount 7.2.2 99 CU Notional Amount Currency 7.2.2

100 CV Affected Notional Amount 7.8.2, 7.8.3 ee “Messaging Architecture” document S101 CW Outstanding Notional Amount 7.8.2, 7.8.3 cument See “Messaging Architecture” do102 CX Outstanding Notional Currency 7.8.2, 7.8.3 ee “Messaging Architecture” document S103 CY Number of Valuation Dates 7.2.4 104 CZ Valuation (Averaging) Date Convention 7.2.4.4 105 DA Backload See “Messaging Architecture” document 106 DB Knock-in Event 7.2.5.3107 DC Knock-in Price 7.2.5.3 108 DD First Knock-in Determination Day 7.2.5.3109 DE Last Knock-in Determination Day 7.2.5.3110 DF Knock-in Frequency 7.2.5.3 111 DG Knock-in Roll Convention 7.2.5.3 112 DH -in Valuation Time 7.2.5.3 Knock113 DI Knock-out Event 7.2.5.3 114 DJ Knock-out Price 7.2.5.3 115 DK First Knock-out Determination Day 7.2.5.3 116 DL Last Knock-out Determination Day 7.2.5.3 117 DM Knock-out Frequency 7.2.5.3 118 DN Knock-out Roll Convention 7.2.5.3 119 DO Knock-out Valuation Time 7.2.5.3


8 Eq Sw Mappings

# oluIndex

.2 uity aps Field Mapping

C mn

Data Field Section Notes

1 A oC mment Specific to Spreadsheet Upload 2 B Act See “Messaging Architecture” document ivity

3 C ra See “Messaging Architecture” document T nsaction Type 4 D ro See “Messaging Architecture” document P duct Type

5 E ri See “Messaging Architecture” document O ginator ID 6 F Tra See “Messaging Architecture” document de Reference Number 7 G o See “Messaging Architecture” document C unterparty ID 8 H Trade See “Messaging Architecture” document Date 9 I Effective Date 7.3.3

10 J Master Confirm Date 7.3.7 11 K a Type M ster Confirmation Transaction 7.3.7 12 L ha 1.1, 7.3.3.1.2 S res ID / Index ID 7.3.3.13 M xc 1.2 E hange ID 7.3.3.

14 N Related Exchang 3.1.2 e ID 7.3.3.1.1, 7.3. 15 O Equity Amount Payer 7.3.3 16 P uN mber of Shares/Units 7.3.3.1 17 Q quE ity Notional Amount 7.3.3 18 R qu E ity Notional Currency 7.3.3 19 S qu E ity Notional Reset 7.3.3.2 20 T yp .3.3.4 T e of Return 7 21 U niti I al Price 7.3.3.2 22 V al 2 V uation Date(s) 7.3.3.2.23 W et S tlement Currency 7.3.3.3 24 X a 3 C sh Settlement Payment Date 7.3.3.2.25 Y lo F ating Amount Payer 7.3.4.1 26 Z Floating Rate Option 7.3.4.2 27 AA e D signated Maturity 7.3.4.2 28 AB Spr ead 7.3.4.2 29 AC Flo unt Fraction ating Rate Day Co 7.3.4.2 30 AD us 1 B iness Days 7.3.4.1.31 AE y 1 Pa ment Dates 7.3.4.1.32 AF iv D idend Period 7.3.3.4 33 AG iv D idend Amount 7.3.3.4 34 AH iv D idend Percentage 7.3.3.1 35 AI Dividend Pa 7.3.3.4 yment Date 36 AJ Early Termination Right 7.3.2 37 AK Independent Amount Percentage 7.3.6 38 AL Independent Amount 7.3.6 39 AM Independent Amount Currency 7.3.6 40 AN Independent Amount Payer 7.3.6 41 AO Independent Amount Receiver 7.3.6 42 AP Master Confirm Annex Date 7.3.7


43 AQ Trade Reference Number Supplement See “Messaging Architecture” document 44 AR Post Trade Transaction Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document 45 AS Post Trade Effective Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document 46 AT Affected Notional Amount 7.9.2, 7.9.3 See “Messaging Architecture” document 47 AU Affected Notional Currency 7.9.2, 7.9.3 See “Messaging Architecture” document 48 AV Outstanding Notional Amount 7.9.2, 7.9.3 See “Messaging Architecture” document 49 AW Outstanding Notional Currency 7.9.2, 7.9.3 See “Messaging Architecture” document 50 AX Post Trade Payment Amount See “Messaging Architecture” document 51 AY Post Trade Payment Currency See “Messaging Architecture” document 52 AZ Post Trade Payment Date See “Messaging Architecture” document 53 BA Post Trade Payment Payer See “Messaging Architecture” document 54 BB Post Trade Payment Receiver See “Messaging Architecture” document

55 BC DK Reason See “Messaging Architecture” document 56 BD Exit Message 7.8 See “Messaging Architecture” document

57 BE Exit Additional Message 7.8 See “Messaging Architecture” document 58 BF pendent Amount Percentage Post Trade Inde 7.9.2.2 59 BG Post Trade Independent Amount 7.9.2.2 60 BH Post Trade Independent Amount Currency 7.9.2.2 61 BI Post Trade Independent Amount Payer 7.9.2.2 62 BJ Post Trade Independent Amount Receiver 7.9.2.2 63 BK Local Jurisdiction 7.3.2 64 BL Re-investment of Dividends 7.3.3.4 65 BM FX Rate 7.3.3 66 BN Internal Comment 7.11 67 BO Link Transaction ID 7.11 68 BP (Floating) Payment Dates Business Day

Convention 7.3.4.1.1

69 BQ Post Trade Initial Price 7.9.1.2.1 70 BR Post Trade Initial Price Currency 7.9.1.2.1 71 BS Post Trade Affected Number of Shares/Units .3 7.9.2, 7.9 72 BT Post Trade Gross Price Currency 7.9.1.2.1.1 73 BU Post Trade Initial FX Rate .1 7.9.1.2.1 74 BV Post Trade Commission 7.9.1.2.1 75 BW Post Trade Outstanding Number of

nits .3

Shares/U7.9.2, 7.9

76 BX Post Aggregate Averaging Price 7.9.1.2 77 BY Future Price Valuation 7.3.3.2.2 78 BZ Exchange Traded Contract 7.3.3.2.4 79 CA Multiplier 7.3.3.2.4 80 CB Fully Funded 7.3.5 81 CC Fully Funded Amount 7.3.5 82 CD Fully Funded Amount Currency 7.3.5 83 CE 15A-6 Rule 7.1.1 84 CF Initial Price Currency 7.3.3.2 85 CG Initial FX Rate 7.3.3.2.1 86 CH Gross Price Currency 7.3.3.2.1 87 CI Commission 7.3.3.2 88 CJ Final Price Default Election 7.3.3.4 89 CK Share Payment 7.3.3.4


90 CL E-Trading TRN 7.11 91 CM Broker Name 7.11 92 CN Desk ID 7.11 93 CO Designated party ID 7.11 94 CP Contractual Supplements 7.3.7 95 CQ First Valuation Date 7.3.3.2.2 96 CR Last Valuation Date 7.3.3.2.2 97 CS Valuation Frequency 7.3.3.2.2 98 CT Valuation Roll Convention 7.3.3.2.2 99 CU First (Floating) Payment Date 3.4.1.1 7.

100 CV Last (Floating) Payment Date 7.3.4.1.1 101 CW (Floating) Payment Frequency 7.3.4.1.1 102 CX (Floating) Payment Roll Convention .1.1 7.3.4 103 CY Compounding Spread .2 7.3.4 104 CZ Sub Product Type See “Messaging Architecture” document 105 DA Backload See “Messaging Architecture” document 106 DB Final Price 7.3.3.2 107 DC ADTV Limitation Percentage 7.3.3.1 108 DD ADTV Limit Period 7.3.3.1 109 DE Averaging Dates 7.3.3.5 110 DF First Averaging Date 7.3.3.5 111 DG Last Averaging Date 7.3.3.5 112 DH Averaging Frequency 7.3.3.5 113 DI Averaging Roll Convention 7.3.3.5 114 DJ Linear Interpolation 7.3.4.2 115 DK Maximum Stock Loan Rate 7.3.2 116 DL Initial Stock Loan Rate 7.3.2 117 DM Depository Receipt Election 7.3.3.1 118 DN Declared Cash Dividend Percentage 7.3.3.4 119 DO Declared Cash Equivalent Dividend

Percentage 7.3.3.4

120 DP Multiple Exchange Index Annex 7.3.2 121 DQ Applicable Product Regional Annex 7.3.7 122 DR Final Price Fee Percent 7.1.2 123 DS Final Price Fee Amount 7.1.2 124 DT Final Price Fee Currency 7.1.2 125 DU Prior Notional Amount 7.9.2 126 DV Prior Notional Amount Currency 7.9.2 127 DW Strike Date 7.1.1 128 DX Hedging Party 7.1.1 129 DY Initial Price Election 7.1.1 130 DZ Dividend Settlement Currency 7.1.1 131 EA Treatment of Non-Cash Dividends 7.1.1 132 EB Composition of Dividends 7.1.1 133 EC Break Fee Election 7.1.1 134 ED Break Fee Rate 7.1.1 135 EE Linear Interpolation Period 7.1.1 136 EF Valuation Date Convention 7.3.3.2.2


137 EG Optional Early Termination Electing Party 7.1.1 138 EH Optional Early Termination Date 7.1.1 139 EI Settlement Type 7.3.3 140 EJ Roll Over Commission 7.1.1 141 EK Reference Currency 7.3.3 142 EL Insolvency Filing 7.3.2 143 EM Loss of Stock Borrow 7.3.2 144 EN Increased Cost of Stock Borrow 7.3.2 145 EO Break Funding Recovery 7.1.1 146 EP Index Disruption 7.1.1 147 EQ Compounding 7.1.1 148 ER Determining Party 7.1.1 149 ES Calculation Agent 7.3.1 150 ET Reference Price Source 7.1.1 151 EU Reference Price Page .1.1 7 152 EV Reference Price Time .1.1 7


8.3 Equity gs

Column Index ield Section Notes

Variance Swaps Mappin

#

Data F1 A Comment pecific to Spreadsheet Upload S2 B Activity ee “Messaging Architecture” document S3 C Transaction Type ee “Messaging Architecture” document S4 D Product Type ee “Messaging Architecture” document S

5 E Originator ID ee “Messaging Architecture” document S6 F Trade Reference Number ee “Messaging Architecture” document S7 G Counterparty ID ee “Messaging Architecture” document S8 H Trade Date ee “Messaging Architecture” document S9 I Master Confirm Date 7.4.8

10 J Master Confirmation Transaction Type 7.4.8 11 K Variance Seller 7.4.2, 7.4.3 12 L Variance Buyer 7.4.2, 7.4.3 13 M Shares ID / Index ID 7.4.4.1, 7.4.4.2 14 N Exchange ID 7.4.4.2 15 O Related Exchange ID 7.4.4.1, 7.4.4.2 16 P Initial Level 7.4.6.1 17 Q Closing Level 7.4.6.1 18 R Variance Amount 7.4.6.1 19 S Variance Strike Price 7.4.6.1 20 T Variance Cap Applicable 7.4.6.1 21 U Variance Cap 7.4.6.1 22 V Observation Start Date 7.4.6 23 W Valuation Date 7.4.5 24 X Expected N 7.4.6.1 25 Y Options Price Valuation 7.4.5 26 Z Exchange Traded Contract 7.4.6.1 27 AA Options Exchange Dividends 7.4.6 28 AB Settlement Currency 7.4.6.1 29 AC Cash Settlement Payment Date 7.4.6 30 AD Independent Amount Percentage 7.4.7 31 AE Independent Amount 7.4.7 32 AF Independent Amount Currency 7.4.7 33 AG Independent Amount Payer 7.4.7 34 AH Independent Amount Receiver 7.4.7 35 AI Master Confirm Annex Date 7.4.8 36 AJ Trade Reference Number Supplement See “Messaging Architecture” document 37 AK Post Trade Transaction Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document 38 AL Post Trade Effective Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document 39 AM Post Trade Payment Amount See “Messaging Architecture” document 40 AN Post Trade Payment Currency See “Messaging Architecture” document 41 AO Post Trade Payment Date See “Messaging Architecture” document 42 AP Post Trade Payment Payer See “Messaging Architecture” document 43 AQ Post Trade Payment Receiver See “Messaging Architecture” document 44 AR DK Reason See “Messaging Architecture” document


45 AS Exit Message 7.8 See “Messaging Architecture” document 46 AT Exit Additional Message 7.8 See “Messaging Architecture” document 47 AU Internal Comment 7.11 48 AV Link Transaction ID 7.11 49 AW Options Price Valuation 7.4.5 50 AX Expiring Contract Level 7.4.6.1 51 AY Reference Currency .4.6.1 7 52 AZ Reference Currency Primar

Source y Rate .4.6.1.1 7

53 BA Reference Currency Primary Rate .4.6.1.1 Source Page

7

54 BB Reference Currency PrimaSource Page Heading

ry Rate .4.6.1.1 7

55 BC Reference Currency Secondary Rate .4.6.1.1 Source

7

56 BD econdary Rate .1 Reference Currency SSource Page

7.4.6.1

57 BE Reference Currency Secondary Rate Source Page Heading

7.4.6.1.1

58 BF Reference Currency Fixing Time 7.4.6.1.1 59 BG Reference Currency Business Days 7.4.6.1.1 60 BH All Dividends 7.4.6 61 BI Local Jurisdiction 7.4.2 62 BJ Multiple Exchange Index Annex 7.4.2 63 BK E-Trading TRN 7.11 64 BL Broker Name 7.11 65 BM Desk ID 7.11 66 BN Designated party ID 7.11 67 BO Contractual Supplements 7.4.8 68 BP Affected Variance Amount 7.9.2, 7.9.3 69 BQ riance Amount Outstanding Va 7.9.2.2, 7.9.3 70 BR Backload See “Messaging Architecture” document 71 BS Observation Frequency 7.4.6 72 BT Observation Roll Convention 7.4.6


8.4 ity appings

mex ield n Notes

Equ Dividend Swaps M

# Colu n

Ind Data F Sectio1 A Comment Specific to Spreadsheet Upload 2 B Activity See “Messaging Architecture” document 3 C nsaction Type See “Messaging Architecture” document Tra4 D Product Type See “Messaging Architecture” document 5 E Originator ID See “Messaging Architecture” document 6 F Number See “Messaging Architecture” document Trade Reference 7 G Counterparty ID See “Messaging Architecture” document 8 H Trade Date See “Messaging Architecture” document 9 I Master Date 7.5.9 Confirm

10 j Master Confirmation TransactionType

7.5.9

11 K Shares ID / Index ID 7.5.7.1, 7.5.7.2 12 L Exchange ID 2 7.5.7.13 M ange ID 1, 7.5.7.2 Related Exch 7.5.7.14 N Fixed Amount Payer 7.5.3 15 O Number of Shares/Baskets 7.5.716 P Settlement Currency 7.5.317 Q Dividend Amount Payer 7.5.3 18 R Declared Cash Dividend

Percentage 7.5.3

19 S Declared Cash Equivalent Dividend Percentage

7.5.3

20 T Dividend Periods 7.5.3 21 U Start Date 7.5.422 V End Date 7.5.423 W Fixed Strike 7.5.4 24 X Dividend Amount Payment Date 7.5.4

25 Y Independent Amount 7.5.8 26 Z Independent Amount Currency 7.5.8

27 AA Independent Amount Payer 7.5.8 28 AB Independent Amount Receiver 7.5.8

29 AC Trade Reference Number Supplement

See “Messaging Architecture” document

30 AD Post Trade Transaction Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document 31 AE Post Trade Effective Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document 32 AF Post Trade Payment Amount See “Messaging Architecture” document 33 AG Post Trade Payment Currency See “Messaging Architecture” document 34 AH Post Trade Payment Date See “Messaging Architecture” document 35 AI Post Trade Payment Payer See “Messaging Architecture” document


36 AJ Post Trade Payment Receiver See “Messaging Architecture” document 37 AK DK Reason See “Messaging Architecture” document 38 AL Exit Message 7.8 See “Messaging Architecture” document 39 AM Exit Additional Message 7.8 See “Messaging Architecture” document 40 AN Internal C omment 7.11 41 AO Link Transaction ID .11 7

42 AP E-Trading TRN .11 7

43 AQ Broker Name 7.11

44 AR Desk ID 7.11

45 AS Designated party ID .11 7

46 AT Contractual Supplements 7.5.9

47 AU Special Dividends .5.3 7

48 AV Material Non-cash Dividend .5.3 7

49 A W Valuation Dates 7.5.4

50 AX Fixed Amount Payment Dates 7.5.6

51 A Y Affected Number of Shares/Baskets

7.9.2

52 AZ Outstanding Number of Shares/Baskets

7.9.2

53 BA Backload See “Messaging Architecture” document


8.5 Eq Dis riance Mappings

ColuInde d ection Notes

uity persion Va

# mn x

Data Fiel S

1 A Comm Specific to Spreadsheet Upload ent 2 B Activi See “Messaging Architecture” document ty 3 C Trans See “Messaging Architecture” document action Type 4 D Produ See “Messaging Architecture” document ct Type

5 E Origin See “Messaging Architecture” document Common field among Index/Share Var Swaps (both)

ator ID

6 F Trade See “Messaging Architecture” document Common field among Index/Share Var Swaps (both)

Reference Number

7 G Coun See “Messaging Architecture” document Common field among Index/Share Var Swaps (both)

terparty ID

8 H Trade See “Messaging Architecture” document Common field among Index/Share Var Swaps (both)

Date

9 I Maste 7.6.8 Common field among Index/Share Var Swaps (both) r Confirm Date 10 J Master Confirmation Transaction Type 7.6.8 Comm oth) on field among Index/Share Var Swaps (b11 K Variance Seller 7.6.3 Common field among Share Var Swaps only

Not allowed for Amendment.

12 L Variance Buyer 7.6.3 Common field among Share Var Swaps only Not allowed for Amendment.

13 M Shares ID / Index ID 7.6.4.1, 7.6.4.2 14 N Exchange ID 7.6.4.2 15 O Related Exchange ID 7.6.4.1, 7.6.4.2 16 P Initial Level 7.6.6.1 17 Q Closing Level 7.6.6.1 18 R Variance Amount 7.6.6.1 19 S Variance Strike Price 7.6.6.1 20 T Variance Cap Applicable 7.6.6.1 21 U Variance Cap 7.6.6.1 22 V Observation Start Date 7.6.6 Common field among Index/Share Var Swaps (both) 23 W Valuation Date 7.6.5 Common field among Index/Share Var Swaps (both) 24 X Expected N 7.6.6.1 25 Y Exchange Traded Contract 7.6.6.1 26 Z Settlement Currency 7.6.3 Common field among Index/Share Var Swaps (both) 27 AA Cash Settlement Payment Date 7.6.3 Common field among Index/Share Var Swaps (both) 28 AB Independent Amount 7.6.7 Common field among Index/Share Var Swaps (both) 29 AC Independent Amount Currency 7.6.7 Common field among Index/Share Var Swaps (both) 30 AD Independent Amount Payer 7.6.7 Common field among Index/Share Var Swaps (both) 31 AE Independent Amount Receiver 7.6.7 Common field among Index/Share Var Swaps (both) 32 AF Master Confirm Annex Date 7.6.8 Common field among Index/Share Var Swaps (both) 33 AG Trade Reference Number Supplement See “Messaging Architecture” document

Common field among Index/Share Var Swaps (both)

34 AH Post Trade Transaction Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document


Common field among Index/Share Var Swaps (both) 35 AI Post Trade Effective Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document

Common field among Index/Share Var Swaps (both)

36 AJ Post Trade Payment Amount See “Messaging Architecture” document Common field among In waps (both) dex/Share Var S

37 AK Post Trade Payment Currency See “Messaging Architecture” document Common field among Index/Share Var Swaps (both)

38 AL Post Trade Payment Date See “Messaging Architecture” document Common field among Index/Share Var Swaps (both)

39 AM Post Trade Payment Payer See “Messaging Architecture” document Common field among Index/Share Var Swaps (both)

40 AN Post Trade Payment Receiver See “Messaging Architecture” document Common field among Index/Share Var Swaps (both)

41 AO DK Reason See “Messaging Architecture” document 42 AP Exit Message 7.8 See “Messaging Architecture” document 43 AQ Exit Additional Message 7.8 See “Messaging Architecture” document 44 AR Internal Comment 7.11 45 AS Link Transaction ID 7.11 46 AT Expiring Contract Level 7.6.6.1 47 AU Futures Price Valuation 7.6.5 48 AV All Dividends 7.6.6 49 AW e Index Annex Multiple Exchang 7.6.2 50 AX E-Trading TRN 7.11 51 AY Broker Name 7.11 Common field among Index/Share Var Swaps (both) 52 AZ Desk ID 7.11 Common field among Index/Share Var Swaps (both) 53 BA Designated party ID 7.11 Common field among Index/Share Var Swaps (both) 54 BB Component Sequence Number ee “Messaging Architecture” document S55 BC Backload See “Messaging Architecture” document


8.6 y eld Mappin

# Column

Index Data Field Section

Equit Variance Options Fi gs

Notes

1 A Comment Specific to Spreadsheet Upload 2 B Activity See “Messaging Architecture” document 3 C Transaction Type See “Messaging Architecture” document 4 D Product Type See “Messaging Architecture” document

5 E Originator ID See “Messaging Architecture” document 6 F Trade Reference Number See “Messaging Architecture” document 7 G Counterparty ID See “Messaging Architecture” document 8 H Trade Date See “Messaging Architecture” document 9 I Master Confirm Date 7.7.11

10 J Master Confirmation Transaction Type 7.11 7.11 K Option Style 7.7.3 Also see 7.2.4.1 and 7.2.4.2 12 L Option Type 7.7.2 13 M Seller 7.7.2 14 N Buyer 7.7.2 15 O Shares ID / Index ID 7.7.7.1, 7.7.7.2 16 P Exchange ID 7.7.7.2 17 Q Related Exchange ID 7.7.7.1, 7.7.7.2 18 R Premium Amount 7.7.4 19 S Premium Currency 7.7.4 20 T Premium Payment Date 7.7.4 21 U Expiration Date 7.7.3.122 V Initial Level 7.7.9.123 W Closing Level 7.7.9.1 24 X Expiring Contract Level 7.7.9.1 25 Y Variance Amount .7.9.1 726 Z Variance Strike Price 7.7.9.1 27 AA Variance Cap Applicable 7.7.9.1 28 AB Variance Cap 7.7.9.1 29 AC Expected N 7.7.9.1 30 AD All Dividends 7.7.9 31 AE Futures Price Valuation 7.7.8 32 AF Exchange Traded Contract 33 AG Observation Start Date 34 AH Settlement Currency 7.7.3 35 AI Cash Settlement Payment Date 7.7.6 36 AJ Multiple Exchange Index Annex 7.7.5 37 AK Independent Amount Percentage 7.7.10 38 AL Independent Amount 7.7.10 39 AM Independent Amount Currency 7.7.10 40 AN Independent Amount Payer 7.7.10 41 AO Independent Amount Receiver 7.7.10 42 AP Master Confirm Annex Date 7.7.10 43 AQ Trade Reference Number Supplement See “Messaging Architecture” document 44 AR Post Trade Transaction Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document


45 AS Post Trade Effective Date 7.9.2, 7.9.3, 7.9.4 See “Messaging Architecture” document 46 AT Affected Variance Amount 7.9.2, 7.9.3 See “Messaging Architecture” document 47 AU Outstanding Variance Amount 7.9.2.2, 7.9.3 See “Messaging Architecture” document 48 AV Post Trade Payment Amount See “Messaging Architecture” document 49 AW Post Trade Payment Currency See “Messaging Architecture” document 50 AX Post Trade P See “Messaging Architeayment Date cture” document 51 AY Post Trade Payment Payer cument See “Messaging Architecture” do52 AZ Post Trade Payment Receiver See “Messaging Architecture” document 53 BA DK Reason See “Messaging Architecture” document 54 BB Exit Message 7.8 See “Messaging Architecture” document 55 BC Exit Additional Message .8 7 See “Messaging Architecture” document 56 BD Internal Comment 7.11 57 BE Link Transaction ID .11 7 58 BF E-Trading TRN .11 7 59 B G Broker Name 7.11 60 BH Desk ID 7.11 61 BI Designated party ID 7.11 62 BJ Contractual Supplements .2.11 2.1.1, 7 63 BK Backload ee “Messaging Architecture” document S


8.7 en ting Rate pportApp dix B: Non ISDA Floa Option su ed by DTCC DerivSERV :


USD-LIBOR-BBA-ON

USD-LIBOR-BBA-ON shall be USD-LIBOR-BBA, provided that Section 7.1(ab)(xxii) and hat is two

elevant Reset Date". However, if such Reset Date is not a London and New York Banking Day, the Floating Rate Option for such Reset Date shall be the rate as of the first immediately preceding London and New York Banking Day, determined in accordance with the abovementioned provisions.

(xxv) of the 2006 Definitions shall be amended by deleting the words "the day tLondon Banking Days preceding that Reset Date" and replacing them with "the r

SGD-SONAR

For a Reset Date, a reference rate equal to the overnight rate as calculated by the Association of banks in Singapore and appearing on the Reuters Screen ABSIRFIX01 Page under the heading "SGD SWAP OFFER" as of 11:00 a.m., Singapore time, in respect of that day. If such rate does not appear on the Reuters Screen ABSIRFIX01 Page in respect of a Reset Date, the rate for that day will be determined by the Calculation Agent.

Documents

DerivSERV Technical Specification - Equity Derivatives v6.0 Revision 4