Marc, Speaking to our DOC guys they seem to use different master confirmation date for individual allocated trades. This would depend on the funds that they trade with. So in some instances they use single master confirmation date ( for PIMCO trades ) and there are other funds that they would use separate master confirmation date for each allocated trade. So I would agree with Marc Tiechman's proposal to have master confirmation element for each allocated trade... Kedar Kodlapur Fixed Income Derivatives Technology Lehman Brothers 212-526-1363 -----Original Message----- From: Marc Gratacos [mailto:MGratacos@xxxxxxxx] Sent: Thursday, May 12, 2005 3:34 PM To: mwg@xxxxxxxxxxxxxxxxxxxxxx Subject: FpML-MWG40 minutes meeting 05/12 Next meeting: May 26, 2005 4.2 First Working Draft was published early this week. May 12, 2005 Attendees --------------- Kedar Kodlapur (Lehman) Marc Teichman (DTCC) Rajeev Kotyan (Sonic Software) Matthew Rawlings (JP Morgan Chase) Brian Lynn (GEM) Henri Pegeron (ISDA) Marc Gratacos (ISDA) Regrets ----------- Brock Arnason (Morgan Stanley) Addition of masterConfirmation element within Allocation type -------------------------------------------------------------------------- -------------- -It seems that we need the addition of an optional masterConfirmation element within the Allocation type. Marc Teicham explained that the dates of the Master Confirmation or Master Confirmation Annex for the individual accounts may vary so we need the inclusion of the element for each one of the allocated trades. -Marc Teichman said that the use of the documentation element is too heavy in this case since most of the information will be contained within the documentation element in the block trade. -Kedar will check to see how Lehman handles this situation internally. Option Exercise proposal ------------------------------------ Agreed to make the following changes: -Need to identify an option. Create an option identifier element within original trade. -Produce two examples: IR Collar and Straddle -Change name exerciseCharacteristics to characteristics. -Make time element mandatory. -Move asset information to the characteristics container instead of having it inside the partial element. Make asset optional since it’s not relevant for some type of options. -the physical settlement should contain information about the new trade/tradeId -Instead of having a notification message we’d create an OptionExerciseRequest (request message) and OptionExerciseResponse (response). The only difference between the two is that in the request the settlement element will be option while it will be mandatory in the response. -We would create an OptionExpiryNotification message. This message will contain the originalTrade element as it will be defined in OptionExercise and an expiryDate element. -AOB -------- -tradeSide structure is within Trade and DataDocument type. It should be removed from DataDocument. An errata should be posted. Actions ----------- -Kedar will check inclusion of confirmation element within short form representation of allocations. -Marc G. will update the option exercise proposal. -Marc G. issue errata for tradeSide. Best Regards, -Marc -------------------------------------------------------------------------- ---- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
<<attachment: winmail.dat>>