FpML Modeling Task Force

Draft presentation for Feb. 6, 2008 meeting

FpML Modeling Task Force

Draft presentation for Feb. 6, 2008 meeting

February,2 2008Speakers TBD, e.g.Karel Engelen, ISDA

[Andrew Jacobs, HandcodedMarc Gratacos, ISDA

Brian Lynn, Global Electronic Markets

February,2 2008Speakers TBD, e.g.Karel Engelen, ISDA

[Andrew Jacobs, HandcodedMarc Gratacos, ISDA

Brian Lynn, Global Electronic Markets

KEngelen 2

AgendaAgenda

• 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

Objectives for TodayObjectives 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

Overview of Modeling Task ForceOverview 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

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

Categories of InconsistenciesCategories 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

Examples of inconsistenciesExamples 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

Examples of inconsistencies (2)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)

Prioritization of inconsistenciesPrioritization of inconsistenciesNum Category Issue Sev Effort Consen Compat Tot

1 X-Asset Cashflow vs CashFlow 7 9 10 10 362 X-Asset Inconsistent modeling of multiple exercise 6 9 9 10 343 Date Consistent availability of Adjusted dates 4 8 10 10 324 X-Asset Inconsistent payment and premium structures 6 8 8 10 325 X-Asset Single Payment 4 9 8 10 316 Gen Und Specific Name/Generic Underlyer 7 6 7 10 307 Naming Element names within product shouldn't include asset class 6 6 7 10 298 Gen Und Inappropriate Underlyers 5 6 7 10 289 Choices Leg Substitution group 5 6 7 10 28

10 X-Asset Differences in modeling option features in FX from elsewhere 6 4 8 10 2811 X-Asset Differences in modeling rate observations 5 6 7 10 2812 X-Asset Interest Leg modeled inconsistently 7 3 7 10 2713 Non-Prod Object identification 8 5 4 10 2714 Choices Rate calc subst group 4 7 5 10 2615 X-Asset Not all legs derived from abstract base type 6 4 6 10 2616 Naming Element names should not repeat path/context 6 4 6 10 2617 Date Consistent availability/modeling of Absolute vs Relative Dates 4 5 7 10 2618 Date Availability of adjustable dates in FX 4 6 6 10 2619 Date DateRelativeTo issues - simple/complex target, single legal value 6 4 6 10 2620 Details Use of boolean 6 6 4 10 2621 Non-Prod Settlement information 4 5 7 10 2622 X-Asset Not all options derived from abstract base type 5 4 6 10 2523 X-Asset Not all leg/stream types allow linking to other legs 4 7 3 10 2424 Granularity Short form vs. long form 6 3 5 10 2425 Non-Prod PR type references several types (AssetOrTermPoint…) 4 4 6 10 2426 Granularity Confusing use of types for short/long forms (eq) 5 6 7 5 2327 Non-Prod TradeSide 4 5 4 10 2328 Non-Prod Accounts 3 5 5 10 2329 Gen Und Incorrect underlyer derivation/hierarchy 5 8 9 0 2230 Choices Floating vs. Fixed Leg 3 4 4 10 2131 Granularity Broad vs. Narrow 4 2 5 10 2132 Granularity Inconsistent availability of short/long form (eq) 6 6 8 0 2033 Gen Und Use for new areas 8 4 7 0 1934 Details ReturnSwapLeg references deprecated type 6 6 6 0 1835 Non-Prod Documentation location 4 4 5 5 1836 Non-Prod Trade vs Contract 8 0 0 10 1837 Non-Prod Strategy 3 4 5 0 12

GuidelinesGuidelines

• 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

RecommendationsRecommendations

• 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

MTF RecommendationsMTF Recommendations

• Cross-product• Credit Derivatives• Equity Derivatives• IR Derivatives• BPWG• Open questions

• Cross-product• Credit Derivatives• Equity Derivatives• IR Derivatives• BPWG• Open questions

Cross-product recommendationsCross-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”

Equity Derivatives – recommendationsEquity 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

Credit Derivatives – recommendationsCredit 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

IR Derivatives - recommendationsIR 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

BPWG/PRWG recommendationsBPWG/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

Open questionsOpen 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

Impact of Product MTFImpact 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

Product MTFProduct MTF

• Questions?• Questions?

Messaging MTFMessaging 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

Messaging MTF – IssuesMessaging MTF – Issues

• Issues with the existing FpML Message Framework:– Completeness– Implementability– Consistency– Complexity

• Issues with the existing FpML Message Framework:– Completeness– Implementability– Consistency– Complexity

CompletenessCompleteness

• 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”

ImplementabilityImplementability

• 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

• 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

Other IssuesOther 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

• 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

Messaging MTF GuidelinesMessaging 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

Number and types of messagesNumber 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

Decisions to DateDecisions to Date

• Documentation• Identification• Corrections• Chaining

• Documentation• Identification• Corrections• Chaining

DocumentationDocumentation

• 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

• 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

IdentificationIdentification

• 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

• 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

CorrectionsCorrections

• 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)

• 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)

Chaining/Message CorrelationsChaining/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

– 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

Remaining WorkRemaining 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

Questions?Questions?

• Questions on Message MTF?• Questions on Message MTF?

Relation of MTF to version 5.0Relation 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.

BLynn 36

ConclusionsConclusions• 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

(All) 37

QuestionsQuestions

• Questions on any aspect of the Modeling Task Force?

• Questions on any aspect of the Modeling Task Force?