[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FPML-CWG Collateral WG Meeting: Wed August 25, 2010 @ 10am New York / 3pm London

Can't make it today due to conflict.

From: owner-colwg@xxxxxxxx [mailto:owner-colwg@xxxxxxxx] On Behalf Of richard.barton@xxxxxxxxxxxxxxxx
Sent: Wednesday, August 25, 2010 7:33 AM
To: colwg@xxxxxxxx
Subject: FPML-CWG Collateral WG Meeting: Wed August 25, 2010 @ 10am New York / 3pm London

We’ll have a meeting Wednesdsay as usual.

Next Meeting – Wednesday August 25, 2010 @ 10am New York / 3pm London


We will discuss the interest process.  Please review the two options defined within the original ISDA Working Group Requirements (see illustrations 1 and 2 below).  This meeting will discuss the requirements and determine how to approach them from an FpML perspective.


·         IN1 – Interest Notification                                                           (<requestInterest>, ex22)

·         IN1 – Interest Notification (matching service)                     (<requestInterest>, ex23)

·         IN2/IN3/IN5 – Accept/Reject Date/Dispute Interest        (<interestStatus>, ex24)


(see schema & examples attached in zip file / rename .zip-email to .zip)


Dial in details:

-          Please join the web conference


Meeting ID: 151-660-907


-          Join the conference call:

US Dial-in:                      888-481-3032

UK Toll Free:                  0800 904 7961

International Dial-in:    617-801-9600

Passcode:                       8682747



Illustration 1 – Interest Message Exchange – utilizing matching service



Illustration 2 – Interest Message Exchange – not utilizing matching service




(Ref http://www.isda.org/c_and_a/pdf/Electronic-Messaging.pdf p.9)




Supporting information that explains how the FpML messaging framework can handle the interest process using matching service:


Excerpt from FpML 5.1 section “onBehalfOf”

The FpML neutral view principle when combined with some of the notifications for post-trade processes and a common third party such as a custodian results in situations where the third party can not easily tell which side of the trade he is supposed to be processing.

For example, parties A and B negotiate a trade and then send a contract execution notification to their common custodian C. The custodian may be able to figure out which side of the trade to process by means of the message sender’s identity but as a single sender identity might be used by several legally separate trading divisions within the same company group determining the correct party might require extensive organisational reference data. This approach would also fail for internal book-to-book deals where both sides would originate from the same sender.

What is needed is an explicit indication of the party for whom the trade should be processed included in every message. In the case of book-to-book trades this information should use account references to further qualify the party. For example:



    … Basic message details




    <partyReference href=""/>

    <accountReference href=""/>


  … Request specification here




Excerpt from FpML 4.9 section 3.2.2 “The Base Message”


·         inReplyTo contains the unique identifier for the request message that is being responded to.

·         sentBy identifies the system or party sending a message.

·         sendTo identifies the systems or parties who will receive a message and should act upon it.

·         copyTo identities other systems or parties who will receive a message but who do not have to act upon it.



Substitution Process – outstanding question:

·         Do we need to distinguish between variation margin and segregated independent amount for a substitution request? The distinction was originally made for the margin call process and kept in the proposed substitution messages. This is an open question for the group.





The information contained in either this email and, if applicable, the attachment, are confidential and are intended only for the recipient. The contents of either the email or the attachment may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, or distribution is prohibited and may be unlawful. If you have received this communication in error, please notify us by e-mail at isda@xxxxxxxx <mailto:isda@xxxxxxxx> then delete the e-mail and all attachments and any copies thereof. This communication is part of an ISDA process and is not intended for unauthorized use or distribution.


This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.

This email with all information contained herein or attached hereto may contain confidential and/or privileged information intended for the addressee(s) only. If you have received this email in error, please contact the sender and immediately delete this email in its entirety and any attachments thereto.