FpML Modeling Task Force February 6, 2008

1. FpML Modeling Task Force February 6, 2008 Speakers: Karel Engelen, ISDA Brian Lynn, Global Electronic Markets Marc Gratacos, ISDA And members of the MTF

2. Agenda • Objectives of the presentation • Overview of Modeling Task Force • Product MTF • Messaging MTF • Relation of MTF to version 5.0 • Conclusions

3. Objectives for Today • Describe the process and recommendations of the FpML Modeling Task Force • Get feedback on the proposals • Seek commitment from working groups to address proposals 3

4. Overview of Modeling Task Force • Task force created Sept/Oct. 2007 • Participants include members of Coordination Committee plus invited guests with extensive FpML experience • Objective is to identify and address modeling inconsistencies and issues in FpML 4.x • Two strands: • Product modeling MTF focuses on cross-product inconsistencies • Messaging MTF focuses on implementability of the FpML messaging framework 4

5. Product MTF • Inconsistencies/Issues • MTF researched and discussed modeling differences and weaknesses across different asset classes • It identified about 3 dozen areas where differences occurred • It listed approximately 37 issues to be resolved • It prioritized these issues based on impact, difficulty to resolve, degree of consensus, etc. 5

6. Categories of Inconsistencies • Underlyers and Generic Underlyers • Modeling of choices • Granularity • Sharing across asset classes • Date related • Outside product • Naming conventions • Detailed type modeling 6

7. Examples of inconsistencies • Underlyer-related • E.g. non-equity underlyers in equityOptions • Pricing/Market environment related instruments as OTC derivative underlyers • Naming, • e.g. cashFlow vs. cashflow • unadjustedDate vs. adjustableDate • equityAmericanExercise vs. americanExercise 7

8. Examples of inconsistencies (2) • Date-related • Different ways to handle adjustable vs. relative dates • Differences in availability of adjusted dates, adjustments, etc. • Modeling approach • Option modeling structure (generic option model vs. product-specific models) • Product granularity; use of sub-typing vs. aggregation of features (e.g. equityOption with Asian feature vs. fxAverageRateOption) 8

9. Prioritization of inconsistencies 9

10. Guidelines • Product MTF is developing some guidelines to try to improve consistency in the future • Granularity of products • Generalization across asset classes • Mapping of products to schema files • Naming conventions 10

11. Recommendations • Product MTF has developed a number of recommendations to address inconsistencies • Reviewed all 37 issues • Determined approach to each issue • Some required no action • Sometimes several issues result in the same recommendation • A few require further investigation before a decision can be reached. • Many resulted in issues assigned to specific FpML WGs for implementation • Not all of these will be implemented, as the working groups may not agree to implement the recommendations 11

12. MTF Recommendations • Cross-product • Credit Derivatives • Equity Derivatives • IR Derivatives • BPWG • Open questions 12

13. Cross-product recommendations • 0) Publish conversion algorithms • 3) Standardize adjusted date handling • 13) Improve business object identification • 15) Standardize leg/stream type inheritance • 20a) Remove optionality of booleans where possible • 29) Refactor underlying asset inheritance hierarchy • 33) Review use of TRS for non-equities • 34) Review use of deprecated elements in TRS • 36) Eliminate “contract”, revert to “trade” 13

14. Equity Derivatives – recommendations • 2, 22) Implement the Generic Option Model for Equity Options • 6, 8) Eliminate underlyer substitution group, uses choice instead • 7) Remove “equity” prefix from element names within products • 9) Eliminate leg substitution group, replace with specific products (extends on-going work) • 24) Eliminate separate product elements for short form 14

15. Credit Derivatives – recommendations • 5) Consolidate singlePayment and initialPayment • 20b) Eliminate use of optional empty element as synonym for boolean 15

16. IR Derivatives - recommendations • 22) Base IR swaption model off generic option model • 12) Investigate feasibility of generalizing IRS leg and TRS interest leg 16

17. BPWG/PRWG recommendations • 1) Replace “CashFlow” with “Cashflow” • 4) Standardize payment and premium structures based on SimplePayment type • 21) Eliminate settlement info from payments and products, move elsewhere • 25) Replace valuation references that point to multiple types with multiple elements 17

18. Open questions • 16) eliminate context prefixes from IRD element names (e.g. cashSettlementXX) • 17) standardize treatment of IRS effective and termination dates with other products • 19) fix dateRelativeTo • various FX related issues • proposals on tradeSide, account, product granularity/extension/composition, strategy element 18

19. Impact of Product MTF • If all recommendations are implemented • There will be substantial change to detailed FpML element naming and detailed organization • There will be relatively minimal changes to overall structure and organization in most areas • Many of the changes will be backward-incompatible • Backward-incompatible changes will need to be addressed in a major release (i.e. FpML 5.0) due to FpML change control guidelines • Recommendations and tools for instance document migration will be important 19

20. Product MTF • Questions? 20

21. Messaging MTF • Message Modeling Task Force • Seeks to identify and resolve issues with existing FpML message framework that • Pose implementation difficulties • Prevent more widespread adoption of the standard • Process • 1) Identify and agree on issues • 2) Discuss and agree solutions • 3) Define new or modified framework • Status • Step 1 is done, 2 is in process, 3 is mostly not started 21

22. Messaging MTF – Issues • Issues with the existing FpML Message Framework: • Completeness • Implementability • Consistency • Complexity 22

23. Completeness • Not all messages needed to implement every business process have been defined in the standard • E.g. correction and cancellation messages not always available for every request that should have them • Status return and error message types not always available • E.g. matching/confirmation status messages for post-trade events • Error messages for various cases, e.g. “Post trade event not found” 23

24. Implementability • It’s not always clear how to use the existing messages to implement a business process • Expected/possible returns for a given message • Processing requirements for a message in every state • Linkage of several messages (e.g. correction/update messages) together as part of a single business process 24

25. Other Issues • Consistency • Messages aren’t always named and defined consistently, e.g. contractFullTermination vs. contractNovated • Complexity • FpML has many messages, often similar • Some MTF members feel that this adds complexity • Other MTF members feel that each message should be as simple and independent of others as possible 25

26. Messaging MTF Guidelines • The group has discussed and is refining guidelines in several areas, including • Documentation • Message Naming • Correlating messages • Identifying business objects • Defining roles of message senders and receivers • Number and types of messages 26

27. Number and types of messages • Most contentious area relates to granularity. Topics include • Corrections • Cancellations • Status return messages • Failure/rejection messages • Similar requests on different business objects 27

28. Decisions to Date • Documentation • Identification • Corrections • Cancellations • Correlating messages • Error Returns 28

29. Documentation • We’ve been working to define what documentation/diagrams etc. are needed to define business processes, with a good degree of consensus, e.g. • Overview trade lifecycle activity diagram to provide context • State transition diagrams/tables • Documentation of expected action by state, and return messages 29

30. Identification • We’ve agreed that key business objects (e.g. trades, events) that can be communicated and modified… • Need a single explicit primary identifier • This identifier can’t change • Any number of alternative identifiers can be added 30

31. Corrections and Cancellations • We’ve agreed that • Corrections should be indicated by a correction indicator within a request message, rather than by a separate message • Only certain types of requests require corrections (others can just be resubmitted) • Cancellations will continue to be supported with a separate message for each request • A mechanism (documentation and/or validation script) will be adopted to ensure that cancellation messages are provided where necessary 31

32. Chaining/Message Correlations • Correction and cancellation messages should be linked to the original request based on the business object’s primary identifier • Requests that must support correction and/or cancellation will require the sender to specify a business object identifier for subsequent linking • E.g. to modify or cancel a report request, you must provide an ID for the report in the initial request 32

33. Alternative Flow Returns • No final decision made, but group is leaning toward consolidating application level failure returns (e.g. “Trade Not Found”) into a single message or a small set of messages • Maybe use MessageRejected, • Maybe defined a new message (e.g. Message Processing Status) • Define a scheme with various reason codes • MTF hasn’t yet reached complete consensus • Your input is welcome 33

34. Request Granularity • No final decision made, but group is leaning toward consolidating requests of the same type on different objects into one set of messages • Instead of RequestTradeConfirmation, RequestNovationConfirmation, etc. … • Now there would be just Request Confirmation containing a trade, novation, etc. • Responses would also be consolidated similarly • MTF hasn’t yet reached complete consensus • Your input is welcome 34

35. Remaining Work • Remaining Message MTF work includes: • Review proposals against other standards (FIX, ISO, etc.) to validate them • Define documentation format to be followed for each business process • Gain consensus on the changes to be made • Develop a revised message framework schema to support the various recommendations • Working with various WGs (eg. BPWG, PRWG), update the message set based on the new framework 35

36. Relation of MTF to version 5.0 • Some MTF recommendations can be implemented in 4.x • E.g., adjusting schema type derivations where there is no impact on instance documents • Most MTF recommendations will need to be implemented in a major version • We plan to try to implement most of the recommendations in 5.0. 36

37. Conclusions • The MTF recommendations are intended to make FpML easier to implement by making it more • Consistent • Complete • Clearly documented • The MTF recommendations propose the most substantial number of changes to existing FpML since 1.0 • The product recommendations mostly change small details rather than overall structures. • The message recommendations affect completeness, implementability, and consistency more than business content

38. Questions • Questions on any aspect of the Modeling Task Force?