1. FpML version 5.0 An introduction
Sept. 2007
Karel Engelen, ISDA
Andrew Jacobs, Handcoded
Marc Gratacos, ISDA
Brian Lynn, Global Electronic Markets

2. Agenda Major vs. Minor Releases Technical/Architecture Changes in 5.0
Possible Changes in 5.0
Business Content Changes in 5.0
Materials Distributed for 5.0
Conclusions
KEngelen

3. Major vs. Minor Releases
Minor versions can add new functionality but are limited
Instance documents must be backward compatible
No deletions/changes to existing elements
Legal technical/architectural changes are limited
Major versions can
Introduce more significant technical/architectural changes
Redesign existing product representations
Version 5.0 is intended to introduce technical or design changes that have been deferred for compatibility reasons
AJacobs

4. Architectural Changes in 5.0
Currently implemented architectural changes
Multiple Root Elements
Introduction of “Views”
These will be included in first 5.0 Working Draft
Feedback is requested while other 5.0 features are being implemented
AJacobs

5. Multiple Root Elements
FpML v 1-4.x uses “<FpML>” as the root of all documents
FpML 4.x uses “xsi:type” to distinguish between message types, e.g.
<FpML version=“4-3” xsi:type=“RequestTradeMatch” … >
FpML 5.x
uses different element names to distinguish between message types (no <FpML> root any more)
Changes “version” to “fpmlVersion” to make it easier to determine where the FpML starts, e.g.
<requestTradeMatch fpmlVersion=“5-0” … >
AJacobs

6. Example of Multiple Roots
FpML 4.3
FpML 5.0
AJacobs

7. Rationale for Multiple Roots
Easier to understand than xsi:type
Certain tools (e.g. binding frameworks, some editors) have problems with xsi:type
AJacobs

8. Multiple Roots
Questions about multiple root elements?
AJacobs

9. Introduction of “Views”
Objective of views
Views in 5.0
Example of views
Business processes by view
Implementation of views
Impact on FpML users
MGratacos

10. Objective of views
Existing FpML has normally has a single representation for each product
(some products have short form and long form)
FpML product representation is primarily designed for confirmation
Many details, precise description
It may be difficult to use FpML when not all detail is known/needed, e.g.
Pretrade: structuring, negotiation
Summary reporting
Making most/all elements optional would make confirmation too loose
Views are intended to provide multiple product representations, from very loose to very tight
MGratacos

11. Views in 5.0 FpML 5.0 currently supports 3 views Pretrade Reporting
Very loose product representation
Things like parties, notionals, and dates are optional
Everything in confirmation view is available (maybe optional)
Reporting
Intermediate representation
Key economics are required (notionals, key dates, parties) but details are not (e.g. date adjustments)
Confirmation
As current 4.x product representation
MGratacos

12. Example Pretrade IR Swap, for RFQ Required Optional
Floating rate index
Optional
Payer/receiver parties
Effective and Termination dates
Calculation Frequency
Payment date details
Notional
Fixed Rate
Day Count Fraction
Adjustments
MGratacos

13. Example Reporting IR Swap Required Optional Floating rate index
Payer parties
Effective and Termination dates
Notional
Fixed Rate
Optional
Receiver Parties
Calculation Frequency
Payment date details
Day Count Fraction
Adjustments
MGratacos

14. Example Confirmation IR Swap Required Floating rate index
Payer/receiver parties
Effective and Termination dates
Notional
Fixed Rate
Calculation Frequency
Payment date details
Day Count Fraction
Adjustments
MGratacos

15. Business Processes by View
Pre-trade
RFQ
Confirmation
Confirmation,
Post-trade event confirmation
Reporting
Everything else, e.g.
Allocation
Contract Notification
Reconciliation (cash flow and portfolio)
Valuation reporting
Post-trade event negotiation
MGratacos

16. Views - Implementation
FpML maintains a single master schema
Master schema contains annotations with view-specific details,
“make this optional in view X”
“put this only in view Y”
FpML publishes separate view-specific schemas, one per view
Each view is generated from the master prior to publication
Each view has documentation and examples
Each view-specific schema will have its own namespace, e.g.,
End users will use a view-specific schema, not the master
MGratacos

17. Views - Impact
FpML users must decide which view (schema) to use for a given application/system
Business processes are generally contained in a single view
Some messages may be available in several views (e.g. “MessageRejected”)
Once the view is selected, instance documents should be closely compatible with previous FpML versions
Choosing a looser view (e.g. pre-trade) allows more flexibility about what data must be included in an instance document
MGratacos

18. Views - Impact Extensions will be impacted by the views
Extensions will need to import the appropriate views (e.g. <xsd:import namespace=“ …>
Extensions applicable to multiple views will need to be duplicated
MGratacos

19. Views - Feedback Requested
Number/purpose of views
Business processes per view
Product representation per view
Issues related to in-house extensions
MGratacos

20. Views
Questions about views?
MGratacos

21. Possible Changes in 5.0 Product representation Message architecture
A task force is starting to look at refactoring product designs
Aim for increased consistency across asset classes
Better support for multi-feature and hybrid products
More generic FX option product representation
Message architecture
Discussions are on-going about rationalizing/ refactoring message set to improve consistency and completeness
Identification
There are ongoing discussions about trade, event, and business process identification that may result in changes
These are not major technical changes, but must be in a major version due to backward incompatibility
AJacobs

22. Business Content Changes in 5.0
Currently, plans are for NO “new” business content in 5.0
No new products
No new product features
No new business processes
EXCEPT possibly as below
As a result of the refactoring/redesign, there may be new business capabilities in 5.0
Pre-trade capability across many products
New messages (more complete and consistent)
More flexible product capabilities (e.g. combinations of features)
AJacobs

23. Business Content Changes in 5.0
In addition, deprecated structures in 4.x versions will be removed, e.g.
A2A Messages (TradeCreated, etc.)
Equity Swaps
Contractual Supplement
some minor date-related options
AJacobs

24. Business Content Changes in 5.0
Questions about business content changes?
AJacobs

25. Materials Distributed For 5.0
Initial distribution (will probably change a little)
Zip files, contents
HTML Documentation
Schema and examples
BLynn

26. Version 5.0 - Zip files, contents
ZIP files of
view-specific
HTML
documentation
ZIP files of
view-specific
schemas and
examples
Unpack
ZIP files
to see contents
BLynn

27. Launching HTML Documentation
Unpack
ZIP files
to see content
Double-click on
Index.html
for menu version
BLynn

28. Overview of HTML Documentation
Specific view
shown at top
Section 2.1-3
discusses views
Click on link
to go to section
BLynn

29. Documentation differences between views
Specific view
shown at top
Section 3
(Bus. Processes)
varies by view
BLynn

30. view-specific examples
Schema and examples
Directories for
view-specific examples
View-specific
schema files
Unpack ZIP files
to see contents
BLynn

31. Conclusions Version 5.0 introduces a number of technical changes
Multiple root elements
Multiple views
Version 5.0 may introduce additional changes
Product and message refactoring
Version 5.0 won’t add new products or business areas
Existing product and business areas may become more flexible
Version 5.0 is distributed using several .zip files
BLynn

32. FpML 5.0
Questions on any aspect of version 5.0?
(All)