Next meeting: June 9, 2005 May 26, 2005 Attendees --------------- Ira Fuchs (XML Associates) Kedar Kodlapur (Lehman) George Boukis (Lehman) Someone else from Lehman but I didn’t get the name. Kedar, could please give me his name? Marc Teichman (DTCC) Matthew Rawlings (JP Morgan Chase) Brock Arnason (Morgan Stanley) Marc Gratacos (ISDA) Regrets ----------- 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. Kedar confirmed this internally and posted it in the mailing list. However, an additional issue was raised by Marc Teichman. He said that the masterConfirmationType element should be expressed in the block trade structure while the masterConfirmationDate should be specified in the allocated trade level. This doesn’t work with the exisiting MasterConfirmation type since both masterConfirmationType and masterConfirmationDate are mandatory. Move this issue to Coordination Committee. Matthew Rawlings raised the issue regarding the naming of the elements contained in masterConfirmation. We don't need to duplicate the text "masterConfirmation" in the child elements of the "masterConfirmation" element. The parent element already names the context. Marc said that it’ s a valid point that should be included in the Architecture Spec. Allocations ---------------- Matthew raised the issue about the existing allocation support in FpML using the existing trade structure. He raised the word "trade" is overloaded. It is used for both the "block trade" and the "trade allocation". Matthew said that the model should distinguish the trade information from the single allocations. A block trade should have one or more allocations. Marc said that there wasn’t an agreement from participants (DTCC, Swapswire) when this was discussed six months ago. Matthew suggested using UML diagram to show the relationships between the different concepts and after agreement on the UML model, review the actual content model. Marc Teichman said that’s fine but the final solution should work for different implementations, as stands now. The DTCC approach is to send first the block trade information and then the block trade plus allocations. So the block trade is still identified upfront without allocation information. Brock added that the issue is to accommodate a solution that is backwardly compatible with the existing FpML. Option Exercise proposal ------------------------------------ We didn’t have time to discuss the updated proposal. Members will send comments to the mailing list. We’ll discuss it in the next meeting. Actions ----------- -Marc G. will update the option exercise proposal. -Marc G. will put masterConfirmation optional/mandatory elements issue in the issue tracker. -Marc G. will put naming guidelines (parent/children no prefixes) for discussion in the AWG. -Matthew will work on UML representation. Best Regards, -Marc
<<attachment: winmail.dat>>