FpML version 5.0 An introduction FpML version 5.0 An introduction Sept Karel Engelen, ISDA Andrew Jacobs, Handcoded Marc Gratacos, ISDA Brian Lynn, Global Electronic Markets Sept Karel Engelen, ISDA Andrew Jacobs, Handcoded Marc Gratacos, ISDA Brian Lynn, Global Electronic Markets

KEngelen2 Agenda Major vs. Minor Releases Technical/Architecture Changes in 5.0 Possible Changes in 5.0 Business Content Changes in 5.0 Materials Distributed for 5.0 Conclusions Major vs. Minor Releases Technical/Architecture Changes in 5.0 Possible Changes in 5.0 Business Content Changes in 5.0 Materials Distributed for 5.0 Conclusions

AJacobs3 Major vs. Minor Releases Minor versions can add new functionality but are limited –Instance documents must be backward compatible –No deletions/changes to existing elements –Legal technical/architectural changes are limited Major versions can –Introduce more significant technical/architectural changes –Redesign existing product representations Version 5.0 is intended to introduce technical and design changes that have been deferred for compatibility reasons Minor versions can add new functionality but are limited –Instance documents must be backward compatible –No deletions/changes to existing elements –Legal technical/architectural changes are limited Major versions can –Introduce more significant technical/architectural changes –Redesign existing product representations Version 5.0 is intended to introduce technical and design changes that have been deferred for compatibility reasons

AJacobs4 Architectural Changes in 5.0 Currently implemented architectural changes –Multiple Root Elements –Introduction of Views These are included in first 5.0 Working Draft Feedback is requested while other 5.0 features are being implemented Currently implemented architectural changes –Multiple Root Elements –Introduction of Views These are included in first 5.0 Working Draft Feedback is requested while other 5.0 features are being implemented

AJacobs5 Multiple Root Elements FpML v 1-4.x use as the root of all documents FpML 4.x uses xsi:type to distinguish between message types, e.g. – FpML 5.x –uses different element names to distinguish between message types (no root any more) –Changes version to fpmlVersion to make it easier to determine where the FpML starts, e.g. – FpML v 1-4.x use as the root of all documents FpML 4.x uses xsi:type to distinguish between message types, e.g. – FpML 5.x –uses different element names to distinguish between message types (no root any more) –Changes version to fpmlVersion to make it easier to determine where the FpML starts, e.g. –

AJacobs6 Example of Multiple Roots FpML 4.3 FpML 5.0

AJacobs7 Rationale for Multiple Roots Easier to understand than xsi:type Certain tools (e.g. binding frameworks, some editors) have problems with xsi:type Easier to understand than xsi:type Certain tools (e.g. binding frameworks, some editors) have problems with xsi:type

AJacobs8 Multiple Roots Questions about multiple root elements?

MGratacos9 Introduction of Views Objective of views Views in 5.0 Example of views Business processes by view Implementation of views Impact on FpML users Objective of views Views in 5.0 Example of views Business processes by view Implementation of views Impact on FpML users

MGratacos10 Objective of views Existing FpML has a single representation for each product –(some products have short form and long form) FpML product representation is primarily designed for confirmation –Many details, precise description It may be difficult to use FpML when not all detail is known/needed, e.g. –Pretrade: structuring, negotiation –Summary reporting Making most/all elements optional would make confirmation too loose Views are intended to provide multiple product representations, from very loose to very tight Existing FpML has a single representation for each product –(some products have short form and long form) FpML product representation is primarily designed for confirmation –Many details, precise description It may be difficult to use FpML when not all detail is known/needed, e.g. –Pretrade: structuring, negotiation –Summary reporting Making most/all elements optional would make confirmation too loose Views are intended to provide multiple product representations, from very loose to very tight

MGratacos11 Views in 5.0 FpML 5.0 currently supports 3 views –Pretrade Very loose product representation elements like parties, notionals, and dates are optional Everything in confirmation view is available (maybe optional) –Reporting Intermediate representation Key economics are required (notionals, key dates, parties) but details are not (e.g. date adjustments) Everything in confirmation view is available (maybe optional) –Confirmation As current 4.x product representation FpML 5.0 currently supports 3 views –Pretrade Very loose product representation elements like parties, notionals, and dates are optional Everything in confirmation view is available (maybe optional) –Reporting Intermediate representation Key economics are required (notionals, key dates, parties) but details are not (e.g. date adjustments) Everything in confirmation view is available (maybe optional) –Confirmation As current 4.x product representation

MGratacos12 Example Pretrade IR Swap, for RFQ –Required Floating rate index –Optional Payer/receiver parties Effective and Termination dates Calculation Frequency Payment date details Notional Fixed Rate Day Count Fraction Adjustments Pretrade IR Swap, for RFQ –Required Floating rate index –Optional Payer/receiver parties Effective and Termination dates Calculation Frequency Payment date details Notional Fixed Rate Day Count Fraction Adjustments

MGratacos13 Example Reporting IR Swap –Required Floating rate index Payer parties Effective and Termination dates Notional Fixed Rate –Optional Receiver Parties Calculation Frequency Payment date details Day Count Fraction Adjustments Reporting IR Swap –Required Floating rate index Payer parties Effective and Termination dates Notional Fixed Rate –Optional Receiver Parties Calculation Frequency Payment date details Day Count Fraction Adjustments

MGratacos14 Example Confirmation IR Swap –Required Floating rate index Payer/receiver parties Effective and Termination dates Notional Fixed Rate Calculation Frequency Payment date details Day Count Fraction Adjustments Confirmation IR Swap –Required Floating rate index Payer/receiver parties Effective and Termination dates Notional Fixed Rate Calculation Frequency Payment date details Day Count Fraction Adjustments

MGratacos15 Business Processes by View Pre-trade –RFQ Confirmation –Confirmation, –Post-trade event confirmation Reporting –Everything else, e.g. Allocation Contract Notification Reconciliation (cash flow and portfolio) Valuation reporting Post-trade event negotiation Pre-trade –RFQ Confirmation –Confirmation, –Post-trade event confirmation Reporting –Everything else, e.g. Allocation Contract Notification Reconciliation (cash flow and portfolio) Valuation reporting Post-trade event negotiation

MGratacos16 Views - Implementation FpML maintains a single master schema Master schema contains annotations with view-specific details, –make this optional in view X –put this only in view Y FpML publishes separate view- specific schemas, one per view –Each view is generated from the master prior to publication –Each view has documentation and examples Each view-specific schema will have its own namespace, e.g., – 0/pretrade End users will use a view-specific schema, not the master FpML maintains a single master schema Master schema contains annotations with view-specific details, –make this optional in view X –put this only in view Y FpML publishes separate view- specific schemas, one per view –Each view is generated from the master prior to publication –Each view has documentation and examples Each view-specific schema will have its own namespace, e.g., – 0/pretrade End users will use a view-specific schema, not the master

MGratacos17 Views - Impact FpML users must decide which view (schema) to use for a given application/system Business processes are generally contained in a single view Some messages may be available in several views (e.g. MessageRejected) Once the view is selected, instance documents should be closely compatible with previous FpML versions Choosing a looser view (e.g. pre-trade) allows more flexibility about what data must be included in an instance document FpML users must decide which view (schema) to use for a given application/system Business processes are generally contained in a single view Some messages may be available in several views (e.g. MessageRejected) Once the view is selected, instance documents should be closely compatible with previous FpML versions Choosing a looser view (e.g. pre-trade) allows more flexibility about what data must be included in an instance document

MGratacos18 Views - Impact Extensions will be impacted by the views –Extensions will need to import the appropriate views (e.g. –Extensions applicable to multiple views will need to be duplicated Extensions will be impacted by the views –Extensions will need to import the appropriate views (e.g. –Extensions applicable to multiple views will need to be duplicated

MGratacos19 Views - Feedback Requested Number of views Business processes per view Product representation per view Issues related to in-house extensions Number of views Business processes per view Product representation per view Issues related to in-house extensions

MGratacos20 Views Questions about views?

AJacobs21 Possible Changes in 5.0 Product representation –A task force is starting to look at refactoring product designs –Aim for increased consistency across asset classes –Better support for multi-feature and hybrid products –More generic FX option product representation –Swaption, equity option, and FX option representations aligned with new CDS options and bond options models. Message architecture –Discussions are on-going about rationalizing/ refactoring message set to improve consistency and completeness Identification –There are ongoing discussions about trade, event, and business process identification that may result in changes These are not major technical changes, but must be in a major version due to backward incompatibility Product representation –A task force is starting to look at refactoring product designs –Aim for increased consistency across asset classes –Better support for multi-feature and hybrid products –More generic FX option product representation –Swaption, equity option, and FX option representations aligned with new CDS options and bond options models. Message architecture –Discussions are on-going about rationalizing/ refactoring message set to improve consistency and completeness Identification –There are ongoing discussions about trade, event, and business process identification that may result in changes These are not major technical changes, but must be in a major version due to backward incompatibility

AJacobs22 Business Content Changes in 5.0 Currently, plans are for NO new business content in 5.0 –No new products –No new product features –No new business processes –EXCEPT possibly as below As a result of the refactoring/redesign, there may be new business capabilities in 5.0 –Pre-trade capability across many products –New messages (more complete and consistent) –More flexible product capabilities (e.g. combinations of features) Currently, plans are for NO new business content in 5.0 –No new products –No new product features –No new business processes –EXCEPT possibly as below As a result of the refactoring/redesign, there may be new business capabilities in 5.0 –Pre-trade capability across many products –New messages (more complete and consistent) –More flexible product capabilities (e.g. combinations of features)

AJacobs23 Business Content Changes in 5.0 In addition, deprecated structures in 4.x versions will be removed, e.g. –A2A Messages (TradeCreated, etc.) –Equity Swaps –Contractual Supplement –some minor date-related options In addition, deprecated structures in 4.x versions will be removed, e.g. –A2A Messages (TradeCreated, etc.) –Equity Swaps –Contractual Supplement –some minor date-related options

AJacobs24 Business Content Changes in 5.0 Questions about business content changes?

BLynn25 Materials Distributed For 5.0 Initial distribution (will probably change a little) –Zip files, contents –HTML Documentation –Schema and examples Initial distribution (will probably change a little) –Zip files, contents –HTML Documentation –Schema and examples

BLynn26 Version Zip files, contents ZIP files of view-specific HTML documentation ZIP files of view-specific schemas and examples Unpack ZIP files to see contents

BLynn27 Launching HTML Documentation Unpack ZIP files to see content Double-click on Index.html for menu version

BLynn28 Overview of HTML Documentation Section discusses views Click on link to go to section Specific view shown at top

BLynn29 Documentation differences between views Section 3 (Bus. Processes) varies by view Specific view shown at top

BLynn30 Schema and examples Unpack ZIP files to see contents Directories for view-specific examples View-specific schema files

BLynn31 Conclusions Version 5.0 introduces a number of technical changes –Multiple root elements –Multiple views Version 5.0 may introduce additional changes –Product and message refactoring Version 5.0 wont add new products or business areas Existing product and business areas may become more flexible Version 5.0 is distributed using several.zip files Version 5.0 introduces a number of technical changes –Multiple root elements –Multiple views Version 5.0 may introduce additional changes –Product and message refactoring Version 5.0 wont add new products or business areas Existing product and business areas may become more flexible Version 5.0 is distributed using several.zip files

(All)32 FpML 5.0 Questions on any aspect of version 5.0?