1 / 12

ISDA EQD 2011 Implementation May 2011

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.

fritzi
Download Presentation

ISDA EQD 2011 Implementation May 2011

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ISDA EQD 2011 ImplementationMay 2011 Andrew Paul Parry Version: Draft v1.0

  2. Agenda • Executive Summary • Implementation Method • US Index Option Example • Legal Drafting Progress • Next Steps

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

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

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

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

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

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

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

  10. Transaction Supplement • Compact, modular, consistent • Will greatly benefit automation • Risk of feature bloat

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

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

More Related