Marc, For this alternative, I was thinking about something similar to what DSWG does. For example, use the value 1900-01-01 to indicate that the date is not available. Best Regards, -Marc _____ From: Marc Teichman [mailto:mteichman@xxxxxxxx] Sent: Thursday, June 09, 2005 1:26 PM To: mwg@xxxxxxxxxxxxxxxxxxxxxx Subject: Re: FpML-MWG40 minutes meeting 06/09 Marc, The alternative that you mention, "To use the existing masterConfirmation element and have a default value for masterConfirmationDate" actually sounds quite attractive because it allows the block trade to be processed the same as any other trade to the extent possible. However, what would be the nature of the default? Regards, Marc "Marc Gratacos" <MGratacos@xxxxxxxx> 06/09/2005 12:50 PM Please respond to mwg@xxxxxxxxxxxxxxxxxxxxxx To <mwg@xxxxxxxxxxxxxxxxxxxxxx> cc Subject FpML-MWG40 minutes meeting 06/09 Due to low attendance, we only discussed the first item of the agenda. Next meeting: June 23, 2005 June 9, 2005 Attendees --------------- George Boukis (Lehman) Paresh Vyas (Lehman) Marc Teichman (DTCC) Lisa Kennedy (EBF) Henri Pegeron (ISDA) Marc Gratacos (ISDA) Regrets ----------- Ira Fuchs (XML Associates) Kedar Kodlapur (Lehman) Brock Arnason (Morgan Stanley) Amod Dixit (NESS) Andrew Parry (JPMorgan) Addition of Master Confirmation information for Allocations -------------------------------------------------------------------------- ---------- We discussed the inclusion of two key pieces of information regarding Master Confirmation for allocations. * The addition of masterConfirmationDate in the Allocation level since its value changes in that level. * How to specify masterConfirmationType in the block trade level. * In the Coordination Committee meeting, Ben Lis suggested looking at the existing brokerConfirmation element. * The element name and the values for borkerConfirmationType are very specific to a broker confirm. It doesn’t seem appropriate to use this structure for allocations. * Marc Teichman suggested including the element masterConfirmationType directly within the choice between masterConfirmation and broker confirmation. * Other options not discussed during the meeting are: * To use the existing masterConfirmation element and have a default value for masterConfirmationDate. * Instead of using masterConfirmationType directly within the choice between master/brokerConfirmation, create a third element specific for allocations. allocationMasterConfirmation (?) which would only contain the master confirmation type information. In any case, we need to get an agreement in this group and then send the proposal to the Coordination Committee. Option Exercise proposal ------------------------------------ Due to low attendance we didn’t discuss this item. Hopefully we will do it in the next meeting. Actions ----------- - Marc G will put a note/proposal for supporting master confirmation type in the block level. _____ From: Marc Gratacos [mailto:MGratacos@xxxxxxxx] Sent: Wednesday, June 08, 2005 3:00 PM To: mwg@xxxxxxxxxxxxxxxxxxxxxx Subject: FpML-MWG40 next meeting - tomorrow Thursday 10 AM NY Time All, The next MWG meeting will be tomorrow Thursday 06/09 at 10 AM NY Time. Agenda ----------- - Addition of master confirmation date element in Allocation type. (see Allocation-masterConfirmationDate.jpg) - Discuss Option Exercise proposal (see OptionExerciseRequest.jpg, OptionExerciseResponse.jpg, OptionExpiryNotification.jpg) - AOB Call details: US: 1 888 481 3032 Intl: 1 617 801 9600 Code: 8682747 Best Regards, -Marc
<<attachment: winmail.dat>>