1. FpML Modeling Task Force Draft presentation for Feb. 6, 2008 meeting
February,2 2008
Speakers TBD, e.g.
Karel Engelen, ISDA
[Andrew Jacobs, Handcoded
Marc Gratacos, ISDA
Brian Lynn, Global Electronic Markets

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

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

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

5. Inconsistencies/Issues
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.

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

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

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)

9. Prioritization of inconsistencies

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

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

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

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”

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

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

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

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

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

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

20. Product MTF
Questions?

21. Message Modeling Task Force
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

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

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”

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

25. Other Issues Consistency Complexity
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

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

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

28. Decisions to Date
Documentation
Identification
Corrections
Chaining

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

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

31. Corrections 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)

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

33. Remaining Work Remaining Message MTF work includes:
Reach agreement (if possible) on remaining topics
Corrections
Status and error messages
Request message granularity
Develop a revised message framework schema to support the various recommendations
Update the message set based on the new framework

34. Questions?
Questions on Message MTF?

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

37. Questions
Questions on any aspect of the Modeling Task Force?
(All)