Please review the minutes for accuracy. Feel free to expand if needed.
- Anil Panchal (GlobeOp Financial Services)
- Kaizad Bhathena (GlobeOp Financial Services)
- Charles Miller (JPMorgan)
- David Hallinan (DB)
- Lucio Iida (Blackrock)
- Vinod Jain (Headstrong)
- Simone Milani-Foglia (LCH Clearnet)
- Tom Brown (OMGEO)
- Venkat Varkala (Citi)
- Richard Barton (algorithmics)
- Eugene Sirota (Goldman Sachs)
- Harry McAllister (BNP Paribas)
- Mike Rouse (BNP Paribas)
- Peter Walsh (State Street)
- Wayne Forsythe (State Street)
- Karel Engelen (ISDA)
- Marc Gratacos (ISDA)
- Irina Yermakova (ISDA)
- Lyteck Lynhiavu (ISDA)
- MC1: The group reviewed the revised MC1 (Issuance of Margin Call (request)) schema and example. More refinements were discussed
· Change content model to enforce the presence of at least totalMTM or Upfront Margin
· Marc discussed the use of the existing FpML <portfolio> element to identify the related portfolio with the margin call.
· As previously understood, Portfolio Reconciliation will occur outside the scope of the collateral messages; The <portfolio> element can be useful to reference a portfolio reconciliation event (probably performed by a matching service)
· See previously distributed “FpMLPortfolioRecDocumentation.doc" for more information on the support for Portfolio Reconciliation in FpML
· Richard inquired how the exposed party would be identified in elements such as the MTM that only capture quantities. Harry agreed functionality is missing in draft schema.
· The group agreed to include a reference to the exposed party to qualify the direction of this MTM amount à Action Item 1
· upfront margin, pending collateral, total collateral will require similar structure
· FpML uses a party neutral approach and does not use signs (positive/negative) to indicate the direction of payment.
· Threshold is fixed in CSA but might vary based on credit rating. The group agreed no extra elements are needed to capture the changes beyond the threshold amount.
- MC3a: The group reviewed the MC3a (Accept Call and Propose Collateral) data elements
· MC3a is the combination of MC3b (Accept Call) and MC3c (Propose Collateral). Those are split up in case the counterparty agrees but does not know yet what collateral will be given.
· The Margin Call Reference will correspond to the FpML <correlationId> which was used originally (the identifier may be issued by the service provider)
· should not be modified, otherwise an exception message should be sent if the identifier cannot be resolved
· For clarity we’ll change <payerPartyReference> & <receiverPartyReference> to <marginCallIssuer> & <marginCallReceiver>
· From a service provider’s perspective (representing both parties) there shouldn’t be any need to capture "on behalf of" information.
· Agreed Amount:
· as discussed last week, decimals will be allowed by the schema
· schema should allow for subcomponents to accommodate multiple collateral types/currencies (all combined subamounts = agreed amount)
· should there be provision to agree to MTM and Upfront Margin separately? (in case the MC1 message combines both) <unresolved>
· Eligible Currency: related to the collateral being proposed. In place of base currency. <?any additional elements needed?>
· The group discussed how to represent full acceptance vs partial acceptance vs full dispute
· The agreed amount alone could be used to convey full acceptance (agreed amount = original MC1 requested collateral), partial acceptance (agreed amount is a fraction of requested amount), or full dispute (agreed amount=0) but at the expense of only having one message type handling everything.
· Having one message type means recipients would have to decode the content. The group leaned towards having distinct semantic (different messages) for acceptance and dispute.
· information whether the variations are netted or not should be represented in original margin call (MC1) (not currently implemented in schema)
· Securities data fields
· RED identifier can easily be supported in FpML as another type of identifier (not limited to ISIN/CUSIP/Sedol)
· The system that will consume the FpML message is responsible for validating the identifier and should throw an exception if invalid/unknown.
1. à Richard + Lyteck to suggest modification to MC1 schema to include a reference to the exposed party that will qualify the direction of the MTM amount
Next Meeting – Wednesday February 17, 2010 @ 10am NY / 3pm London time (1h30)
- Revisit MC1 schema & XML example based on feedback
- Continue discussion on MC3a (Accept Call and Propose Collateral)
- Start discussion on MC5 and MC6 (Full/Partial Disputes) data elements
Dial-in details and materials will be sent Tuesday.
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.