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

FPML-CWG Collateral WG Meeting Minutes - August 18, 2010

Please find the minutes from the August 18 meeting.



1.       Jesse Nolan (UBS)

2.       Joe Novellino (DB)

3.       Simone Milani-Foglia (LCH Clearnet)

4.       Evelyne Piron (SWIFT)

5.       Anil Panchal (GlobeOp)

6.       Kaizad Bhathena (GlobeOp)

7.       Irina Yermakova (ISDA)

8.       Marc Gratacos (ISDA)

9.       Lyteck Lynhiavu (ISDA)

10.   Richard Barton (Algorithmics)



1.       Tom Brown (OMGEO)

2.       Sammy Lee (GlobeOp)



·         The group reviewed the draft messages for the collateral substitution process (see zip distributed with meeting invitation 8/17)

·         CS1 – Request Substitution                         (<requestSubstitution>, ex18)

·         CS2/CS5 – Agree/Reject Collateral Subst   (<substitutionStatus>, ex19)

·         CS3 – Confirm Substitution                         (<substituteConfirmationStatus>, ex20)

·         CS4 – Confirm Collateral Returned            (<returnConfirmationStatus>, ex21)

·         Many of the Margin Call types and concepts have been reused in the substitution messages. Collateral definitions defined in Repo extensions 2.2 were considered but the types (collateralSubstitution, CollateralSubstitutionEvent) were not suitable. The substitution messages were received positively, and aligned with the Margin Call design.

·         Should we allow only one asset substitution per substitution request message? The group felt the substitution request (CS1) should allow a many-to-many relationship. i.e., one message can have multiple collateral assets substituted by multiple assets.

·         Kaizad noted there’s typically one asset being substituted by one or many assets but we should make the substitution messages flexible enough to support all scenarios.

·         Joe noted that multiple messages (one for each asset to be substituted) would make the settlement process tricky. The pairing of messages in the back-end would be difficult. One message would simplify the process.

·         substitution amount (total): We will add a <substitutionAmount> to indicate the total amount being substituted (within each <variationMargin> and <segregatedIndependentAmount> blocks). Capturing the total amount is not absolutely necessary but useful as a control check in case there are multiple assets being substituted.

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



Next meeting – Wednesday, August 25

We will start discussing the interest process.  Please review the following two options defined within the original Working Group Requirements.  This meeting will discuss the requirements and determine how to approach them from an FpML perspective.


Illustration 1 – Interest Message Exchange – utilizing matching service


Illustration 2 – Interest Message Exchange – not utilizing matching service





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.