OCTOBER 14, 2010 - SLIDE 1 Copyright © 2010 International Swaps and Derivatives Association, Inc. FpML 5.0 Overview ® ISDA is a registered trademark of

OCTOBER 14, 2010 - SLIDE 1Copyright © 2010 International Swaps and Derivatives Association, Inc.FpML 5.0 Overview

FpML 5.0 Overview

® ISDA is a registered trademark of the International Swaps & Derivatives Association, Inc.

® FpML is a registered trademark of the International Swaps & Derivatives Association, Inc.

ISDA

Andrew Jacobs (UBS) Brian Lynn (Global Electronic Markets)Marc Gratacos (ISDA)


Agenda

• FpML 5.0 Highlights

• Messaging Framework

• Demo

• Questions


FpML 5.0 Highlights

ISDA


Agenda

• Unit Objectives

• Major vs. Minor Releases

• Architectural Changes in 5.0

• Multiple Root Elements

• Views

• Accounts and Roles

• Recap


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 introduces technical and design changes that have been deferred for compatibility reasons


Architectural Changes in 5.0

• Implemented architectural changes– Multiple Root Elements– Introduction of “Views”: confirmation and reporting– Messaging correlation [covered in Messaging]– Generic Business Processes [covered in Messaging]– Separation of parties and accounts– Better support for roles


Multiple Root Elements

• FpML v 1-4.x use “<FpML>” as the root of all documents

• FpML 4.x uses “xsi:type” to distinguish between message types, e.g.– <FpML version=“4-7” xsi:type=“RequestTradeConfirmation”

… >

• 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.– <requestConfirmation fpmlVersion=“5-0” … >


Rationale for Multiple Roots

• Easier to understand than xsi:type

• Certain tools (e.g. binding frameworks, some editors) have problems with xsi:type


Objective of views

• Existing FpML 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


Views in 5.0

• FpML 5.0 currently supports 2 views– Reporting

• Very flexible product representation (almost everything is optional)

• Everything in confirmation view is available (but optional)

– Confirmation• As current 4.x product representation


Implementation of Views• 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.,– http://www.fpml.org/FpML-5/reporting

• End users will use a view-specific schema, not the master


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. reporting) allows more flexibility about what data must be included in an instance document, but with less validation


Views - Impact

• Extensions will be impacted by the views– Extensions will need to import the appropriate

views (e.g. <xsd:import namespace=“http://www.fpml.org/FpML-5/confirmation” …>

– Extensions applicable to multiple views will need to be duplicated


Accounts and Roles

• Accounts have been moved out of party– Now can reference either servicingParty,

accountBeneficiary, or both

• TradeSide has been removed– A new, more flexible “relatedParty” structure

has been added to partyTradeInformation to support roles

• Account references have been added to allow party references to be narrowed down


Other Changes

• Product Representation– Adjusted dates– Booleans in CDS– Product refactoring

• Messaging Framework– Covered in the next presentation


Recap of Key Points

• What are the main changes in 5.0?– Multiple root elements, views, accounts, and

roles

• What is the impact of such changes?– Business process selection, extensions are

affected


FpML Messaging

® ISDA is a registered trademark of the International Swaps & Derivatives Association, Inc.

® FpML is a registered trademark of the International Swaps & Derivatives Association, Inc.


Agenda

• Unit Objectives

• FpML messaging purpose

• FpML message types

• Version 5 Messaging Features

• Business process categories– Confirmation View– Reporting

• Recap


Objectives - Questions to Answer

• What is FpML messaging for?

• What types of messages are there?

• What are the differences in messaging between 4.x and 5.x?

• What business processes does it support each view?


FpML Messaging Purpose

• Define a protocol for communicating between firms to implement a business process

• Allow a recipient of an FpML document to understand how to process it.


FpML Message Types

• 4.x– Message

• Request Message• Response Message• Notification Message

5.x– Message

Request Message– Correctable Request

Message– Non Correctable

Request Message

Response MessageNotification Message


Message Header 4.x

• Provides message and context identifiers

• Identifies sender and recipients

• Records timing information

• Provides additional party information

• Provides assurance of sender


Message Header 5.x

• Same as 4.x except there is no conversationId element


General Pattern of Messages in 5.0

• Each business process follows this message pattern:– Process initiation message (request or

notification)– Acknowledgement – Exception– Retraction– Optionally, response/status messages


Naming Conventions in 5.0

• The general naming convention is as follows:– requestXXX– xxxAcknowledgement– xxxException– requestXXXRetracted– xxx[Status] or xxx[Response]

• XXX is the name of the business process


Message Correlation and Sequencing

• Successive messages are “correlated” (linked together) using a new, explicit “correlationId”

• Correlation ID is assigned by the initiator• Correlation ID is intended to be a business/application level

element, not transport level• Corrections or cancellations use the correlation ID to refer to the

previous request/notification• Responses use the correlation ID to link to the request.• Sequence numbers may be used to establish message order


Correction/Retraction

• The initial request and any corrections use the same message

• There is a boolean correction indicator to indicate whether the message corrects a previous one

• Retractions are a separate message (may have less detail than the original request)

• Corrections and retractions are linked to original request using correlationId


Acknowledgements and Exceptions

• All initiating messages have corresponding (named) acknowledgement and exception messages

• Most of these use generic “Acknowledgement” and “Exception” types

• In some case these may be extended to hold process specific information.


On-behalf Of

• Added to each message the ability to specify on-behalf-of whom the message was sent

– Party

– Account

• Allows recipient to interpret messages more easily when sender can send messages on behalf of multiple parties/accounts

– E.g. when sender is a central service provider, platform, prime broker.


Generic business processes

• Most FpML 5 business processes are “generic” process that can apply to new trades and/or any post-trade events

• This means that the message name indicates the business process (e.g. confirmation, execution notification) but not the type of event (e.g. trade, amendment)

• Payload of the message indicates the type of the event


Generic processes supported

• Pre-trade (currently out of scope, but some modeling has been done)– Quotation– Ordering

• Post-trade (confirmation view)– Execution notification (for platforms to report order fills)– Execution advice (to report executions and settlement info

to service providers)– Allocation (expanded for version 5)– Confirmation– Consent negotiation– Clearing (new for version 5)– Status reporting


Events

• Current list of events available within the generic business processes


• Demo– FpML.org

• Login to development area (free account)• “Specification” tab (www.FpML.org/spec/)

– Documentation• http://www.fpml.org/spec/fpml-5-0-8-rec-1/html/confirmation/index.html

• Browse online HTML version or download complete zip• Section 3 shows “Business Process Architecture”

– Schemas and samples• Download schema and examples (confirmation_xml.zip) from: http://www.fpml.org/spec/fpml-5-0-8-rec-

1/ • See confirmation messages in fpml-confirmation-processes-5-0.xsd• XML examples are in subfolders inside zip

Browsing the FpML 5.0 Confirmation View


Generic processes - benefits

• Improved consistency across post-trade events

• Easier to ensure all necessary messages are present

• Reduces the number of messages required to provided full coverage – (not everyone agrees that this is a benefit)


Generic processes - drawbacks

• Need to look inside messages to see what type of payload is inside

• May make it slightly harder to route/report on messages by event type.


Reporting View

• Approach

• Example of new approach

• New fields

• New reports


Reporting View - Approach

• All elements are optional, except for a very small number of exceptions

• This is ensured using a schema generation script• The list of fields required for a specific report will

be specified using validation rules– List of expected field names and Xpaths– If a field is missing, this won’t be a schema

error – it will be a business rule validation error


• Demo– FpML.org

• Login to development area (free account)

• “Specification” tab (www.FpML.org/spec/)

– Documentation• http://www.fpml.org/spec/fpml-5-0-8-rec-1/html/reporting/index.html

• Browse online HTML version or download complete zip

• Section 3.4 shows “Reporting Business Processes”

– Schemas and samples• Download schema and examples (reporting_xml.zip) from: http://www.fpml.org/spec/fpml-5-0-8-rec-1/

• See reporting messages in fpml-reporting-5-0.xsd

• Reporting XML examples are in subfolders inside zip

Browsing the FpML 5.0 Reporting View


Existing reports (available in 4.x and 5.0)

• Valuation (pricing and risk)

• Cash flow matching

• Portfolio reconciliation

• Position reporting


New reports (only available in 5.0)

• Position Activity Report– Reports on changes to position over a time

period (new, modified, removed)

• Event Activity Report– Reports on events (new trades and post trade

events) over a time period

• Reset report– Reports on index settings and the affected

positions


Recap of Key Points

• What is FpML messaging for?– Define protocol for business processes

• What types of messages are there?– Request, Response, Notification,

CorrectableRequest, etc.

• What business processes does it support?– Confirmation view: execution, execution advice,

confirmation, etc.– Reporting view: Valuation, Cash flow matching, etc.


Questions?

• Resources: www.FpML.org• Download the FpML specification and drafts• Participate to the development of the standard and join

FpML Working Groups• Post questions on the FpML Forum

• Questions, feedback: [email protected]

Documents

OCTOBER 14, 2010 - SLIDE 1 Copyright © 2010 International Swaps and Derivatives Association, Inc. FpML 5.0 Overview ® ISDA is a registered trademark of