FpML Version 5, Working Draft 4 ISDA FpML Update Brian Lynn Global Electronic Markets Marc Gratacos FpML Consultant International Swaps and Derivatives Association, Inc. (ISDA)

Agenda Overview Reporting View Messaging Framework Other changes Next Steps

Overview There are 2 major changes in WD#4 Revamped reporting view New approach New fields New reports New messaging framework New message correlation mechanism Generic business processes

Reporting View Approach Example of new approach New fields New reports

Reporting View - Approach From WD#4, 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

Example of new approach <positionReport xmlns="http://www.fpml.org/FpML-5/reporting" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" fpmlVersion="5-0" xsi:schemaLocation="http://www.fpml.org/FpML-5/reporting ../fpml-main-5-0.xsd"> <header> <!-- optional, can be used if desired --> <messageId messageIdScheme="http://www.abc.com/mid">XXX00123</messageId> <sentBy>ABCDUS33</sentBy> <sendTo>HEDGUS33</sendTo> <creationTimestamp>2004-08-02T15:38:00Z</creationTimestamp> </header> <asOfDate>2004-06-02Z</asOfDate> <dataSetName>Copper</dataSetName> <position> <!-- position details go here - see next page --> </position> <party id="party1"> <partyName>ABCD Securities Inc.</partyName> </party> <party id="party2"> <partyId>HEGDUS33</partyId> <partyName>HedgeCo Capital L.L.C.</partyName> </positionReport>

Example - position description <position> <positionId positionIdScheme="http://www.abc.com/positionId">CDS-POS-01</positionId> <constituent> <trade> <tradeHeader> <tradeDate>2002-12-02Z</tradeDate> </tradeHeader> <creditDefaultSwap> <productType productTypeScheme="http://www.fpml.org/product-type-copper">Single</productType> <assetClass assetClassScheme="http://www.fpml.org/asset-class-simple">Credit</assetClass> <generalTerms> <buyerPartyReference href="party1"/> <sellerPartyReference href="party2"/> </generalTerms> <protectionTerms> <calculationAmount> <currency>EUR</currency> <amount>10000</amount> </calculationAmount> </protectionTerms> </creditDefaultSwap> </trade> </constituent> </position>

Some of the new fields added for reporting include: Report level Report contents - more detail about what the report contains (party, accounts, products, etc.) Position level Status and history information Product level Asset class

Existing reports Valuation (pricing and risk) Cash flow matching Portfolio reconciliation Position reporting

New reports Position Activity Report Event 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 Entity/Party report (work in progress) Reports on static reference data for parties.

Messaging Framework Principles General pattern of messages Naming Convention Message Correlation Correction/Retraction Acknowledgements and Exception On-behalf of Generic business processes Other changes

Messaging Framework Principles Observable completion Consistent message correlation Consistent error reporting Consistent correction and retraction Consistent processes across trades and post-trade events

General Pattern of Messages Each business process follows this message pattern: Process initiation message (request or notification) Acknowledgement Exception Retraction Optionally, response/status messages

The general naming convention is as follows: Naming Conventions 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 - example Request confirmation Could be of a trade, or of an amendment Acknowledgements and exceptions Refer to the previous request, irrespective of the event type Confirmation status message Can report status, differences on trades or any other type of post-trade 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

Example message <requestConsent xmlns="http://www.fpml.org/FpML-5/confirmation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" fpmlVersion="5-0" xsi:schemaLocation="http://www.fpml.org/FpML-5/confirmation ../../fpml-main-5-0.xsd"> <header> <messageId messageIdScheme="http://www.im01.com/mid">im12937</messageId> <sentBy>IM01</sentBy> <sendTo>DLR01</sendTo> <creationTimestamp>2003-04-02T15:38:00-04:00</creationTimestamp> </header> <isCorrection>false</isCorrection> <correlationId correlationIdScheme="http://www.ubsw.com/mid">231234213231</correlationId> <sequenceNumber>1</sequenceNumber> <novation> <!-- novation details here --> </novation> <party id="party1"> <partyId>IM01</partyId> </party> <party id="party2"> <partyId>DLR01</partyId> <party id="party3"> <partyId>DLR02</partyId> </requestConsent> Could be replaced with a trade or other post-trade event, e.g. amendment or termination

Sample Process Consent Negotiation Requestor asks for ok; recipient can grant or refuse request

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.

Other changes 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 Account references have been added to allow party references to be narrowed down

Other changes (continued) Contract Notification messages have been replaced with executionAdvice A few changes have been made to shared components Adjustable Date representation has been tweaked to allow adjusted dates in more places

Example of account usage <executionAdvice xmlns="http://www.fpml.org/FpML-5/confirmation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" fpmlVersion="5-0" xsi:schemaLocation="http://www.fpml.org/FpML-5/confirmation ../../fpml-main-5-0.xsd"> <header> <messageId messageIdScheme="http://www.ubsw.com/mid">TQ12937</messageId> <sentBy>OperationsOutsourcer</sentBy> <sendTo>Custodian</sendTo> <creationTimestamp>2003-04-02T15:38:00-04:00</creationTimestamp> </header> <isCorrection>false</isCorrection> <correlationId correlationIdScheme="http://www.ubsw.com/mid">231234213231</correlationId> <sequenceNumber>1</sequenceNumber> <onBehalfOf> <partyReference href=“party1”/> <accouontReference href=“acct1”/> </onBehalfOf> <trade> <!-- trade details here --> </trade> <party id="party1"> <partyId>IM01</partyId> </party> <party id="party2"> <partyId>DLR01</partyId> <party id=“svc_provider"> <partyId>OPS01</partyId> <account id=“acct1"> <acctId>123</acctId> <accountBeneficiary href=“party1”/> <servicingParty href=“svc_provider” </account> </executionAdvice> Ops Outsourcer is sending the message on behalf of IM01 Account 123 is serviced by ops outsource for IM01

Next Steps LCWD in early 2010 Feedback from industry is requested MTF is likely to be turned into a public working group on business processes