Re: FPML-CWG RE: Collateral WG Meeting: Wed 3 March 2010

----- Message from "richard.barton@xxxxxxxxxxxxxxxx" <richard.barton@xxxxxxxxxxxxxxxx> on Thu, 25 Feb 2010 17:19:00 -0500 -----

To:	"colwg@xxxxxxxx" <colwg@xxxxxxxx>
Subject:	RE: FPML-CWG Collateral WG Meeting Minutes - February 24, 2010

Hi

Sorry to all for not making the call yesterday. Please find attached some thoughts on Dispute Reasons, Margin Call Response and Collateral Proposals.

The following suggestions are an example of how we could potentially represent the Margin Call Response and Collateral Proposal which would form the reply to the Margin Call issued via MC1. These messages would potentially replace MC3a,b,c,MC5,MC6. Apologies for not annotating this in FpML but hopefully this is ok to get an idea of the suggestion.

The premise of this suggestion is as follows:
· The messages should support the scenario where an organisation knows what they can agree to but not the exact collateral that will be sent. Therefore the messages support sending the agreed details independently of the collateral details.
· When utilizing a messaging infrastructure if the messages are split then the scenario where the collateral proposal is known at the same time as the agreed amount then the rendering system will support this so it is ok to be separate
· The Margin Call Response should handle the situation where Initial Margin and Variation Margin is segregated. The respondent can agree to the IM, VM separately or in the same message. For scenarios where there is no segregation I used the term convenience response amount to relate that situation where the IM and VM is not segregated.
· The messages should not restrict the amount of information the responding party are able and willing to disclose about why they are agreeing to what they are agreeing. Therefore I suggest a section “calculation details” where they can detail their view of the margin calculation (you can even show that you thought they could have called you for more if you would like). I appreciate that typically the amount of information that is disclosed is limited i.e. ISDA guidelines assumes at most mtm, collateral and upfront. However in the case of a dispute you are eventually going to ask for this information anyway so to expedite the mitigation of risk why not support disclosure. For example the ISDA Guideline does not require you to disclose Threshold. So if I dispute and send a dispute reason Threshold. Then you are going to be reverting back to the phone/email to ask what is the Threshold. If I tell you in my response what the Threshold is it saves an out of collateral system communication.
· If the messages support disclosure of calculation details then the need for dispute reason is lessened because you are presented with the information that enables you (or your collateral system) to see why the responding party can only agree to the amount they are agreeing to. It also supports side by side comparison of calculation details.
· When separating the Collateral Proposal you can then handle the scenario where the calling party rejects a collateral proposal with the same message type and avoids having to have another message for handling rejected collateral proposals.

Other things considered about this message
· It assumes that the party that receives the Margin Call Response will look at the Undisputed Amount details and compare that to the amount that they called that party for. If the amount is 0 then the responder disputes, if the amount is equal to the call amount the responder agreed, if the amount is not 0 they partially agreed.
· There is no explicit element that says dispute, agreed, partially agreed
· There is no minimum amount of information expected when you respond (there is no limitation either)
· There is no explicit element for dispute reason (however the information you need apart from not a valid call day is available in the response details)

Dispute Reasons
I saw the various notes on Dispute Reasons and put them in a tab of the attached spreadsheet. I think when thinking about this that we need to bear in mind firstly what information we need to be able to use that reason and secondly whether we would have that information at the time of receiving the margin call request. From the table you will see those reasons that are known from the Margin Call details and at the time of the call and those that would require a Portfolio Statement or Collateral Statement and a reconciliation to have taken place. Therefore I think if we are to use a Dispute Reason we probably need to limit ourselves to those that are marked as in both the Call Details and At Call Time classifications.

Regards

Richard
From: owner-colwg@xxxxxxxx [mailto:owner-colwg@xxxxxxxx] On Behalf Of Lyteck Lynhiavu
Sent: Wednesday, February 24, 2010 3:44 PM
To: colwg@xxxxxxxx
Subject: FPML-CWG Collateral WG Meeting Minutes - February 24, 2010

Please find the minutes for today’s call. Thank you for your participation.

Participants
- Kaizad Bhathena (GlobeOp)
- Sammy Lee (GlobeOp)
- Anil Panchal (GlobeOp)
- Vivian Wu (Goldman Sachs)
- Charles Miller (JPMorgan)
- Harry McAllister (BNP Paribas)
- Wayne Forsythe (State Street)
- Tom Brown (OMGEO)
- Lucio Iida (Blackrock)b
- Marc Gratacos (ISDA)
- Irina Yermakova (ISDA)
- Lyteck Lynhiavu (ISDA)

Apologies
- Vinod Jain (Headstrong)
- Richard Barton (algorithmics)

Notes
- MC5 / MC6 (dispute)
· The group agreed in principle on the need of a mechanism in the message that will convey why a margin call is being disputed and what is disputed, but the group couldn’t agree on which mechanism(s)
1. use a free-form comment field and/or
2. use high-level reason code(s) and/or
3. return disputed field values (e.g., TotalMTM, as outlined in the business specs pdf p.24)
The group ultimately agreed to allow a combination of all of the above for maximum flexibility (the free-form comments field and reason codes will be optional)
· The group discussed the list of high-level reason codes that Peter/Wayne/Harry circulated à Action item 2
- What happens after MC12/MC13 (request portfolio)? Closing the process loop
· Kaizad raised the concern that after the MC12/MC13 exchange, there is no provision in the PDF specs to loop the result of the portfolio reconciliation back to the margin call <please correct if needed>
· The Dispute Resolution Process is outside the scope of the collateral messages, but from an implementation perspective, we may need a new message or fields (TBD) to tie the result back to the original margin call request à Action item 3
1. The FpML <correlationId> mechanism will be used to correlate related messages
2. One suggestion was to simply rescind the original call (MC2) and resend a new margin call (MC1)
3. It was also suggested that perhaps MC12/MC13 should be integrated with MC5/MC6, earlier in the process. We should be careful however, to design messages that can be used by service providers & matching services

Action Items
1. à Richard to circulate an example of margin call response that could model acceptance/full dispute/partial dispute (MC3/MC5/MC6) with a single message (deferred from 2/17 meeting)
2. à ISDA will consolidate the list of generic reason codes based on everyone’s input
3. à Everyone to think how the result of the dispute resolution process can be tied back to the margin call, if at all

Next Meeting – Wednesday March 3, 2010 @ 10am NY / 3pm London time
Draft Agenda:
- Review margin call response example from Richard (à action item 1)
- MC5/MC6 Dispute Reasons: review consolidated list (à action item 2)
- Closing the process loop (à action item 3)
- Continue reviewing data fields for MC7..MC13
- AOB

Dial-in details and materials will follow early next week.

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.