Fpml modeling task force february 6 2008
This presentation is the property of its rightful owner.
Sponsored Links
1 / 38

FpML Modeling Task Force February 6, 2008 PowerPoint PPT Presentation


  • 79 Views
  • Uploaded on
  • Presentation posted in: General

FpML Modeling Task Force February 6, 2008. Speakers: Karel Engelen, ISDA Brian Lynn, Global Electronic Markets Marc Gratacos, ISDA And members of the MTF. Agenda. Objectives of the presentation Overview of Modeling Task Force Product MTF Messaging MTF Relation of MTF to version 5.0

Download Presentation

FpML Modeling Task Force February 6, 2008

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Fpml modeling task force february 6 2008

FpML Modeling Task Force

February 6, 2008

Speakers:

Karel Engelen, ISDA

Brian Lynn, Global Electronic Markets

Marc Gratacos, ISDA

And members of the MTF


Agenda

Agenda

  • Objectives of the presentation

  • Overview of Modeling Task Force

  • Product MTF

  • Messaging MTF

  • Relation of MTF to version 5.0

  • Conclusions


Objectives for today

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


Overview of modeling task force

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


Product mtf

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


Categories of inconsistencies

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


Examples of inconsistencies

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


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)

8


Prioritization of inconsistencies

Prioritization of inconsistencies

9


Guidelines

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


Recommendations

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


Mtf recommendations

MTF Recommendations

  • Cross-product

  • Credit Derivatives

  • Equity Derivatives

  • IR Derivatives

  • BPWG

  • Open questions

12


Cross product recommendations

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


Equity derivatives recommendations

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


Credit derivatives recommendations

Credit Derivatives – recommendations

  • 5) Consolidate singlePayment and initialPayment

  • 20b) Eliminate use of optional empty element as synonym for boolean

15


Ir derivatives recommendations

IR Derivatives - recommendations

  • 22) Base IR swaption model off generic option model

  • 12) Investigate feasibility of generalizing IRS leg and TRS interest leg

16


Bpwg prwg recommendations

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


Open questions

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


Impact of product mtf

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


Product mtf1

Product MTF

  • Questions?

20


Messaging mtf

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


Messaging mtf issues

Messaging MTF – Issues

  • Issues with the existing FpML Message Framework:

    • Completeness

    • Implementability

    • Consistency

    • Complexity

22


Completeness

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


Implementability

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


Other issues

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


Messaging mtf guidelines

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


Number and types of messages

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


Decisions to date

Decisions to Date

  • Documentation

  • Identification

  • Corrections

  • Cancellations

  • Correlating messages

  • Error Returns

28


Documentation

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


Identification

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


Corrections and cancellations

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


Chaining message correlations

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


Alternative flow returns

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


Request granularity

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


Remaining work

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


Relation of mtf to version 5 0

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

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


Questions

Questions

  • Questions on any aspect of the Modeling Task Force?


  • Login