120 likes | 259 Views
ISDA EQD 2011 Implementation May 2011. Andrew Paul Parry. Version: Draft v1.0. Agenda. Executive Summary Implementation Method US Index Option Example Legal Drafting Progress Next Steps. Executive Summary.
E N D
ISDA EQD 2011 ImplementationMay 2011 Andrew Paul Parry Version: Draft v1.0
Agenda • Executive Summary • Implementation Method • US Index Option Example • Legal Drafting Progress • Next Steps
Executive Summary • ISDA EQD 2011 Definitions are designed for “eDefinitions” Electronic Publication, and are fully machine readable • NY Fed deadline to publish EQD 2011 Definitions by 31 May 2011, with two Transaction Matrices by 31 July 2011 • Equity Steering Committee ( ESC ) must then provide quarterly product implementation plan by 31 Oct 2011 • We will review a partial implementation of Main Book Definitions, and US Index Option • This implementation is a backwardly compatible extension to FpML, and is designed for full Electronic Publication
Implementation Method “Definitions” • Firstly we create the Definitions • Create Data Types ( XML Schema ) which follow Data Types in the Main Book, with associated Reference Data Logical Name • Data Type “PrimaryFeature” • Logical Name “www.fpml.org/coding-scheme/primary-feature” • Create Reference Data Sets ( XML Documents ) which contain the supported values for this Data Type • Physical Version “.../primary-feature-1-0” • Supported Values ( Forward, Swap, Option ) • Assemble Data Types into Content Groups, such as • Content Group “Option Style Mechanics” • Create Data Containers for Layering • Structural Leg, Option Leg, ...
Implementation Method “Definitions” • Create Documents • Matrix ( per Product, Industry Wide ) • Matrix Support Agreement ( per Product, per Counterparty ) • Transaction Supplement ( per Trade, per Counterparty ) • All Documents • Version Aware ( Major and Minor Version ) • Logical Name ( Publication Address ) • Version Name ( Version Publication Address ) • Publication Date • Place Definitions into Documents • Follow “what lives where” decisions made in Legal Drafting • Track changes as we finalise the Main Book, and define Products
Implementation Method “Product” • Secondly we use Definitions to define the Products • We now create populated Document instances, tied together by the Transaction Type, Version, and Publication Date • Matrix “http://www.fpml.org/eqd/2011/usio/matrix” • MSA “http://www.fpml.org/eqd/2011/usio/matrix-support” • T-Supp “http://www.fpml.org/eqd/2011/usio/transaction-supplement” • This is how we define supported Features and Values • Transaction Supplement instance ( Trade ) is for illustration only, ISDA will publish the template
Main Book • I have only implemented those Definitions required to demonstrate US Index Option • Transaction Terms • Structural Leg • Option Leg • Other Products require Performance Legs • Equity Leg, Variance Leg, Dividend Leg, Forward Leg • All Products will require • Multiple Methodology Types • Notice Dates • Risk Allocation
Matrix • An excellent way to achieve both standardised and machine readable definitions per Product Industry Wide • Easy to implement since we have the Main Book, which is a Data Dictionary by design, with distinct Data Types, Names, and Reference Data • In Spreadsheet form there are multiple entries for “xyzAvailableConsequences”, which could be factored out into a Data Type and Reference Data • Example • Data Type “PriceConsequence” • Reference Data ( Omission, Postponement, ... ) • Implementation makes use of this approach • ..., PriceElection, StrikeElection, TimeElection
Matrix Support Agreement • Matrix Support Agreement ( MSA ) is a “stub” document by design, with no accessible Economic Features • No MSA is the easiest solution to implement and manage • If the Industry wishes to use MSA, we should be very clear of the impact of per Product per Counterparty agreement • Override ? • Constrain ? • Redefine ? • Extend ? • Easiest to implement as a Matrix over ride • Made easier by Fixed Menu “A”, “B”, or “C” • Very hard to implement if based on Free Text
Transaction Supplement • Compact, modular, consistent • Will greatly benefit automation • Risk of feature bloat
US Index Option • We will now walk through a Product implementation, you are welcome to open the relevant XML files • Matrix • “isda-2011-us-index-option-matrix-1-0.xml” • Document Header, Option Leg • Matrix Support Agreement • “isda-2011-us-index-option-matrix-support-agreement-1-0.xml” • Document Header, Agreement Terms Stub, Agreement Identifier • Transaction Supplement • “isda-2011-us-index-option-transaction-supplement.xml” • Message Header, Trade Header, Document Header, Structural Leg, Option Leg
Questions, Next Steps • Legal drafting progress ? • When should I next iterate the implementation ? • When do we intend to run the RFP for Electronic Publication ? • I suggest that we also run an RFP for Document Generation