|
Andrew, Please find below re my action point in the FpML EQD WG agenda. (The below are discussion points from I and James, we have not
discussed this with all of the MarkitSERV members.) In respect of MCA type handling in the FpML going forward,
please find below our suggestions. 1. <masterConfirmationType>
shall contain a value reflecting the cover level of the ISDA document. This is
usually below the Equity Definition and above the General Terms. 2. <masterConfirmationAnnexType>
shall contain a value reflecting the subsections belonging to the relevant masterConfirmationType.
This usually consists of General Terms and Transaction Supplement, and referred
to as an Annex in the document. 3. Where no annex exists, no
annex type needs to be defined - <masterConfirmationAnnexType> is
optional. 4. <masterConfirmationAnnexType>
may not be present without <masterConfirmationType>. 5. Revisions (Rev1, Rev2, etc)
shall be applicable independently to <masterConfirmationType> and <masterConfirmationAnnexType>
(assuming a revision could potentially be to the cover section only, or to the annex
only, or to both). For example, with 2009 European Share Swap (Interdealer) and 2009 European
Index Swap (Client) we propose the following values. 2009 European Share Swap (Interdealer) <masterConfirmationType>
= ISDA2009EquityEuropeInterdealer <masterConfirmationAnnexType> = ISDA2009EquityEuropeInterdealerAnnexSS 2009 European Index Swap (Client) <masterConfirmationType> = ISDA2007EquityEurope <masterConfirmationAnnexType> = ISDA2009EquityEuropeAnnexIS Due to the hierarchical nature of the ISDA document structure, the
annex values repeat the cover level classification to be unambiguous,
resembling the conventional ‘magic’ string. This may seem redundant
with the Share Swap (Interdealer ) example, but the Index (Client) example
displays the benefit of the two level FpML structure, specifying a 2009 annex
under the 2007 master confirmation type. Regards, Takeo |