1 / 29

ISDA FpML Update

ISDA FpML Update. FpML Version 5, Working Draft 4. 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.

jacie
Download Presentation

ISDA FpML Update

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • Overview • Reporting View • Messaging Framework • Other changes • Next Steps

  3. 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

  4. Reporting View • Approach • Example of new approach • New fields • New reports

  5. 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

  6. 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> </party> </positionReport>

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

  8. New fields • 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

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

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

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

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

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

  14. 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

  15. 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

  16. 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

  17. 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.

  18. 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.

  19. 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

  20. 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

  21. 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

  22. 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> <party id="party3"> <partyId>DLR02</partyId> </party> </requestConsent> Could be replaced with a trade or other post-trade event, e.g. amendment or termination

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

  24. 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)

  25. 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.

  26. 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

  27. 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

  28. Example of account usage <executionAdvicexmlns="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> <messageIdmessageIdScheme="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> <correlationIdcorrelationIdScheme="http://www.ubsw.com/mid">231234213231</correlationId> <sequenceNumber>1</sequenceNumber> <onBehalfOf> <partyReferencehref=“party1”/> <accouontReferencehref=“acct1”/> </onBehalfOf> <trade> <!-- trade details here --> </trade> <party id="party1"> <partyId>IM01</partyId> </party> <party id="party2"> <partyId>DLR01</partyId> </party> <party id=“svc_provider"> <partyId>OPS01</partyId> </party> <account id=“acct1"> <acctId>123</acctId> <accountBeneficiaryhref=“party1”/> <servicingPartyhref=“svc_provider” </account> </executionAdvice> Ops Outsourcer is sending the message on behalf of IM01 Account 123 is serviced by ops outsource for IM01

  29. 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

More Related