Guy, That seems like an appropriate approach. Can you point me to this payment frequency? I tried to look for it in the enum file, but couldn't find it. _____ From: Guy Gurden [mailto:guy.gurden@xxxxxxxxxxxxx] Sent: Wednesday, June 08, 2005 11:56 AM To: ird@xxxxxxxxxxxxxxxxxxxxxx; astf@xxxxxxxxxxxxxxxxxxxx Subject: RE: FpML-IRD40 RE: FpML-ASTF next meeting I think there is value in agreeing a way to represent zero-coupon payment structures within the existing swapStream. There is already a payment frequency of 1T that is used in the interest rate schema to represent OIS swaps which typically have a single payment at maturity. Maybe a 1T payment frequency would suffice rather than a boolean. Guy _____ From: Marc Gratacos [mailto:MGratacos@xxxxxxxx] Sent: Wednesday, June 08, 2005 11:45 AM To: astf@xxxxxxxxxxxxxxxxxxxx; ird@xxxxxxxxxxxxxxxxxxxxxx Subject: FpML-IRD40 RE: FpML-ASTF next meeting Pierre, I assume that "isCustomizedPaymentSchedule" element would be mandatory for asset swaps, is this correct? Would the flag, to indicate that is a zero-coupon bond, be part of the Bond type? Or would it be an optional element in the Swap or AssetSwap type (depending on the group's decision)? Thanks, -Marc _____ From: Lamy, Pierre [mailto:pierre.lamy@xxxxxx] Sent: Tuesday, June 07, 2005 8:45 PM To: 'astf@xxxxxxxxxxxxxxxxxxxx'; 'ird@xxxxxxxxxxxxxxxxxxxxxx' Cc: Weir, John; Bouklieva, Milla; Burbano, Esteban; Fahy, Tom Subject: RE: FpML-ASTF next meeting As a follow-up from the initial discussion that we had a couple of months back when reviewing the proposal developed by the IRD Working Group, and in preparation of the further review that we have scheduled for Thursday, here are my observations on this proposal (which I attach to this email): 1. I think that there is consensus that the asset swap product should be based upon the ird schema. 2. As part of the ASTF discussions, we have identified the following required extensions: * The optional bond underlyer * an element to specify whether an adjustment has been made to the leg schedule that references the bond (isCustomizedPaymentSchedule in our current internal representation here at Goldman Sachs) * a flag to indicate whether the bond that is referenced is a zero-coupon bond, in which case there is a one-off payment (excellent suggestion from Jean Chouraki, at BNPP) 3. John Weir and I are of the opinion that positioning these features through the ird schema presents two downsides: * It weakens the schema, as each standard interest rate swap can then have an associated bond; * It makes more difficult the formal identification of the asset swaps. Indeed, it would be inappropriate to conclude that an asset swap is an ird object that has the bond extension, because a number of dealers appear to be trading asset swaps without referencing explicitly the bond. Also, the suggestion of identifying those through the productId/productType does not seem necessarily appropriate, because FpML does not provide any guideline (in terms of scheme, etc.) on how those elements should be used. Let me know what you think, and let's discuss this coming Thursday. I hope that we will reach consensus, as this would be a good addition to the set of FpML products. _____ From: Karel Engelen [mailto:KEngelen@xxxxxxxx] Sent: Saturday, June 04, 2005 3:21 PM To: astf@xxxxxxxxxxxxxxxxxxxx Subject: FpML-ASTF next meeting All, The next meeting will be on Thursday June 9 at 8:30 NY time. The meeting will be together with the meeting of the IRD working group. Attached is the original document with an update from our last meeting. A document with the proposed changes to the Equity Swap structure will be distributed beginning next week together with the analysis for the Asset Swap. Karel This is a commercial communication sent by SwapsWire Limited. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Please contact info@xxxxxxxxxxxxx if you no longer wish to receive commercial communications from us, identifying the email addresses to which you no longer wish commercial emails to be sent.
<<attachment: winmail.dat>>