Trade Notification Workflow Meeting Highlights

Trade Notification Workflow Meeting Highlights

ISDA and SWIFT – FpML Closed User Group

Trade Notification Workflow Meeting Highlights – 8 September 2006

Trade Notification Workflow Meeting Highlights

Attendees

MyraMooreBarclays Global Investors

Philip NikolovGoldman Sachs Asset Management

Ann BissellInvestors Bank & Trust

Michael BurgMellon Bank

John BoothNorthern Trust

Tricia Carney, Jason BrasileState Street Bank

Matt HawkinsState Street IMS

Patrick PuringtonWestern Asset Management

Brian LynnGlobal Electronic Markets

Karel Engelen, Marc Gratacos,

and Irina YermakovaISDA

Bob Chomut, Marie-Paule Dumont,

and Malene McMahonSWIFT

1. Instruments and life-cycle events

Following brief introductions and an overview of the FpML CUG pilot, we reviewed the instruments and trade life-cycle events to be included in phase 1 of the pilot. They are listed below:

Instruments:

Credit default swaps

  • Single names
  • Index CDS
  • Index tranches
  • Baskets
  • Basket tranches

Interest rate swaps

  • Single currency (vanilla, including OIS and basis swaps)
  • Cross currency (vanilla, including OIS and basis swaps)
  • Caps
  • Floors
  • Collars

Post-trade life-cycle events:

  • New
  • Amend
  • Increase
  • Novate (Partial and Full)
  • Terminate (Partial and Full)

The group agreed on the list of instruments but some discussion followed on whether or not to include AMEND and INCREASE as a life-cycle events. It appears that most investment managers do not ever AMEND or INCREASE a trade. If there is a change, it is likely be treated as a cancel and re-book than a real amendment to a trade.

Decision pending: Do we still include AMEND and INCREASE as a life-cycle events for the pilot? The participants in the meeting agreed to go back to their respective institutions and do some checking.

2. Workflow, scenario and message review

A number of different scenarios (combinations of life-cycle events above) were reviewed in detail along with their corresponding example messages that were prepared by ISDA. Observations, highlights and any pending decisions are summarised below.

2.1 Cash settlement information

There was some discussion about whether or not cash settlement information is included in the FpML messages. Most agreed that if there were any up-front payments or fees that settlement information about these payments needed to be included in the trade notification messages. There was less agreement on whether or not cash settlement information for any ongoing cash flows should be included since many rely on standing settlement instructions. Consensus was to have the option to include settlement instructions for up-front payment and fees (FpML/ISDA to look into required changes in FpML if any to accomplish this). It needs to be agreed in the rule book if this will be a requirement or an option in the pilot.

Follow-up action: Review cash settlement information in FpML messages in some additional detail with ISDA and a few pilot participants.

2.2 Acknowledgments

There was a discussion on whether or not any of the messages in any of the scenarios needed to be formally acknowledged by the custodian. There was also some discussion about the custodian sending back some ‘enriched’ messages (additional reference information, etc.) It was generally agreed that this was not required.

2.3 Linking messages together

There was a discussion around the ‘conversation ID’ in the FpML message header and how this might be used to help link messages to one another. Normally, this linking is done through the ‘trade ID’ field. It was agreed that the rulebook should provide some guidance on how to use the ‘conversation ID’ field.

2.4 Long form vs. short form

We reviewed the fact that the interest rate swap FpML messages reflect all the trade details in the confirmation. Credit default swap messages can be represented in a ‘long form’ or in a ‘short form’ format.. There was a general consensus that perhaps ‘long form’ would be best for the trade notification messages because the ‘short form’ does not include all economic details of the trade and relies on the associated Master Confirmation. Master Confirmation information is currently not known to the custodians and there is no way currently to exchange this information electronically.

Decision pending: Do we use the short or long form for the credit default swap trade notifications?

2.5 Message names

It was suggested that the ‘new’ trade notification reflect the word new in the name of the message. ISDA will review the message names and change as appropriate.

2.6 FpML messages for correcting mistakes

FpML has three basic message types that will be used for the notification messages:

  • Create
  • Modify
  • Cancel

These messages are not business-level events, but message-level actions. For example, a NewTradeNotification would be a ‘create’ message. If you sent a NewTradeNotification message in error, you can either ‘modify’ or ‘cancel’ it with the modify and cancel messages (which would be named ‘ModifyNewTradeNotification’ and ‘CancelNewTradeNotification’ respectively). The terms NEW, AMEND, NOVATE, INCREASE and TERMINATE are business-level events and not message-level actions.

Follow-up action: ISDA and SWIFT to create a message matrix/list to be circulated to the pilot group to clarify the differences between business-level events and message-level actions.

2.7 Terminations

FpML messages for terminate either contain all the details of the trade being terminated, or just the trade ID. It was agreed that all the details are required for a termination.

2.8 Rejection messages

FpML has an existing suite of ‘rejection’ messages that could be used if there is something wrong with the message that is received by the custodian. Brian explained some of these messages during the discussion. It was generally agreed that these messages would not be part of the initial phase of the pilot. We may consider adding them at a later stage.

3. Other issues

Malene briefly reviewed the service description and rulebook. These will likely be completed before the end of October and sent to all pilot participants.

A discussion about FpML’s validation rules (and other possible validation) followed. Even though SWIFT will not validate FpML during the first phase of the pilot, we should still plan to implement ‘validate-able’ messages in the first phase. A comment was made that not everyone agreed with (or likes) all of FpML’s existing validation rules.

Follow-up action: A review of FpML’s validation rules (and other possibly stricter rules) will take place in the coming weeks.

END

TradeNotif_Workflow_Meeting_Highlights_8Sept06.docPage 1

Top View