Download presentation
Presentation is loading. Please wait.
Published byCody Padilla Modified over 11 years ago
1
FpML Modeling Task Force Draft presentation for Feb. 6, 2008 meeting 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 February,2 2008 Speakers TBD, e.g. Karel Engelen, ISDA [Andrew Jacobs, Handcoded Marc Gratacos, ISDA Brian Lynn, Global Electronic Markets
2
KEngelen2 Agenda Objectives of the presentation Overview of Modeling Task Force Product MTF Messaging MTF Relation of MTF to version 5.0 Conclusions 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 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 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
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. 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 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 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) 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 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 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 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 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 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 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 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 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 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 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
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 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 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 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 Its 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 Its 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 –Messages arent 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 Consistency –Messages arent 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 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 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 Documentation Identification Corrections Chaining
29
Documentation Weve 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 Weve 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 Weve agreed that key business objects (e.g. trades, events) that can be communicated and modified… –Need a single explicit primary identifier –This identifier cant change –Any number of alternative identifiers can be added Weve agreed that key business objects (e.g. trades, events) that can be communicated and modified… –Need a single explicit primary identifier –This identifier cant change –Any number of alternative identifiers can be added
31
Corrections Weve 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) Weve 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 objects 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 –Correction and cancellation messages should be linked to the original request based on the business objects 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 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. 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
BLynn36 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 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
37
(All)37 Questions Questions on any aspect of the Modeling Task Force?
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.