Hi very sorry but I will not be able to attend the call this morning I have created a suggestion and will forward to the group this evening again sorry
Please find the minutes from last week’s 2/17 meeting. Please review for accuracy –these will be used to guide the development of the schema.
Apologies for getting these out late...
Participants
-
Vivian Wu (Goldman Sachs)
-
Vinod Jain (Headstrong)
-
Nicole Jolliffe (Swift)
-
Kaizad Bhathena (GlobeOp Financial Services)
-
Sammy Lee (GlobeOp Financial Services)
-
Richard Barton (algorithmics)
-
Charles Miller (JPMorgan)
-
Peter Walsh (State Street)
-
Wayne Forsythe (State Street)
-
Lucio Iida (Blackrock)
-
Simone Milani-Foglia (LCH Clearnet)
-
Harry McAllister (BNP Paribas)
-
Marc Gratacos (ISDA)
-
Irina Yermakova (ISDA)
-
Lyteck Lynhiavu (ISDA)
Notes
-
MC1: The group reviewed the revised MC1 (Issuance of Margin Call (request))
schema and example.
·
Shouldn’t upfront margin be included in Total MTM?
·
It depends how the agreement is structured and how upfront margin is interpreted.
·
upfront margin could be additional to the MTM applied before threshold
·
upfront margin could also be called for, irrespective of exposure
·
upfront margin is optional
·
Participants use different terminology for margin <?unresolved?>
·
we are missing a field to capture “initial margin”. We need a more granular definition
·
Algo refers to Independent amount = “lock-up margin” (per the 2001 ISDA provisions, treated independently) Vs. initial margin (acquired against
the MTM) = additional margin (re: Richard email 2/17 – MC1 discussion)
·
LCH: Clearing uses “termination margin” (?)
·
We need differentiate between initial margin (MTM) and variation margin (re: Simone email 2/17)
·
GlobeOp: initial margin can be called upfront margin (upfront margin is different than upfront fee)
·
Numbers (e.g., Total MTM) are usually expressed from the issuer’s perspective but we should design the messages to be explicit and unambiguous.
This will give processing engines the flexibility to render multiple perspectives. The size of the messages is of peripheral concern. What is more important is that the content cannot be misinterpreted.
·
The group favors a design that can include Total Exposure and the initial MTM in the same message or have the flexibility to hold the initial
margin outside of the daily MTM (i.e., have a separate message for initial margin amount and another message for Total MTM, and the ability to have both)
·
one issue might be if you send one or the other, how do you know the other part is coming?
·
Harry proposed schema structures (re: Harry email 2/17 - agreed to by the group)
·
to enforce the presence of at least Total MTM or upfront margin
·
to express the direction of MTM exposure
<MarkToMarketExposureAmount> would be expressed for each side (i.e., partyA is exposed/party B is obligated for X amount AND on
the other side: PartyB is exposed/partyA is obligated for Y amount) inside the <TotalMTM> container with Richard's proposed <amountTreatment> (net/gross) at that level (re: collateral_xml_20100217.doc p.2 option 1)
·
Should net or gross information be even in scope for the request for margin call? At that stage you would already know if you're going to be
calling either in the net or gross basis and may not have to express that in the message. Having the option to include the information will allow for greater disclosure (as much disclosure as each party is willing to disclose)
·
Calls are not meant to be at the
position level (detail which amount is called for each instrument). MC1 is a summary and does
not show any portfolio. The call doesn't detail what the initial margin is comprised of, for example.
·
Business validation (e.g., summation check: initial margin + MTM =
net amount) cannot be enforced in the schema alone. Other asset classes in FpML have defined validation rules that express relationships between related elements, for example, which must be enforced for the message to be business valid. Implementation of the
validation rules is outside the scope of the message definition. The group may participate in the definition of such validation rules once the collateral messages are well defined.
-
MC3a:
·
Richard reiterated the possibility that MC3/MC5/MC6 messages could be expressed with one message type instead
à Action item 1
·
The group agreed MC3a is the combination of MC3b (Accept Call) and MC3c (Propose Collateral) (data elements were not discussed further)
-
MC5 / MC6:
·
the group discussed using a combination of free-form comment field and/or reason code(s) to capture the reason why a margin call is being disputed
·
whichever mechanism the group decides, it would have to be mandatory (Comments field specified as optional in the pdf)
·
The reason code element would be repeatable (unbounded) to allow for combination of reasons
·
The reason codes could be store in an enumeration (fixed set, defined in schema) or in an FpML scheme (extensible)
·
Peter and Harry will explore whether a reasonably short list of generic reasons can be used
à Action item 2
·
MC6 Dispute Detail Fields (p.24): Party disputing the call will return amounts from it's own perspective
·
The purpose of the messages we are defining is to give us a started point for further investigation in the dispute, but realizing we won't
be able to solve the dispute through messages
·
The ISDA Collateral is working on a Dispute Resolution process (different process than the messaging process being developed her)
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
2.
à Peter and Harry to put together a draft list of generic reason codes
Next Meeting – Wednesday February 24, 2010
@ 10am NY / 3pm London time (1h30)
(The agenda and dial-in details were distributed earlier.)
Lyteck