I have obtained some UBS Power confirmation templates. The zip includes 7 templates for ISDA and EEI: EEI Heat Rate Option and Swap EEI Physical Option ISDA Financial Swaption ISDA Option ISDA Physical Index for CAISO ISDA Swap Let me know if there is something specific you require I'll see if I can dig it up. WRT rounding discussion, the conformations can contain details such as: "For the purposes of the calculation of the Floating Price(s), all numbers shall be rounded to three (3) decimal places. If the fourth (4th) decimal number is five (5) or greater, then the third (3rd) decimal number shall be increased by one (1), and if the fourth (4th) decimal number is less than five (5), then the third (3rd) decimal number shall remain unchanged" -----Original Message----- From: commwg@xxxxxxxx [mailto:commwg@xxxxxxxx] On Behalf Of Piers Evans Sent: Monday, July 14, 2008 11:15 AM To: commwg@xxxxxxxx Subject: FpML-Com Minutes of 2008-07-11 call * Present Hans Ellis, SWIFT (Co-Chair) Piers Evans, Markit (Co-Chair) Jared Getz, Glencore Marc Gratacos, ISDA Chito Jovellanos, Forward Look Owen King, Markit Brian Lynn, GEM Bulent Ozkan, Triple Point John Solder, UBS Peter Stockman, DTCC Irina Yermakova, ISDA * Apologies Alistair Cross, GS Krishna Devabhaktuni, Citadel Luis Fierro, DB Dirk Mattig, RWE Ali Peera, GS Richard Rigby, Glencore Chuck Witter, MS * Review actions from last meeting 1500 LDN 11th July 2008 >> PE to finalise the swap schema and distribute to the group for review. Schema to include sample trades based on 3 examples used by previous commodity WG. PE distributed this and proposed a formal code review once the options discussion paper has been considered and options are integrated into the schema. >> AC to provide 'tricky' confirmations to aid testing the integrity of the final model AC will try to find suitable confirmations that can be distributed. This action will be extended to the rest of the group - please see actions below. JG agreed to provide example oil confirmations to the group. >> Group to review Effective Date question in relation to novations JG said that trades would settle on a monthly basis so the novation of a trade with different calculation period lengths per leg would not result in different effective dates. Group agreed that effective and termination date made sense at the trade level. Please also see attached slides which relate to interest rate trades for an example of what was at issue here. Should there be no further comments in the light of these slides, the point will be considered closed. >> Group to review market disruption model and agree it on next call No issues were raised with the model. The group will have another chance to comment during the code review. * Minutes 1. PE went through the business points in the attached email 1.1 Pricing Dates (note the original email referred to Payment Dates - apologies) PS suggested that the ability to link absolute pricing dates to a calculation period would probably be required. PE noted that since this would add significant complexity to the schema it should be modelled only if it was definitely required. The group would like feedback from other members as to whether this issue requires consideration. In summary: If a message contains the absolute pricing dates rather than a schedule algorithm, should these be grouped per calculation period as notional steps are? If a lag were applicable and the pricing dates did not align with the calculation periods, would this not be unavoidable? For example, a "Cal '09" swap with a 3 month lag (starting 01-Jan-2009, ending 31-Dec-2009, pricing as an average of the 3 preceding months' prices) with monthly calculation periods has the following pricing dates: (a) 01-Oct to 10-Oct-2008 (b) 01-Nov to 07-Nov-2008 (c) 01-Dec to 12-Dec-2008 A parametric representation would specify something like "all commodity business days in the first two calendar weeks of each of the three months preceding the calculation period". However, if the actual dates were listed, it is not explicit which of the periods the dates should apply to. In this case, for example, all the dates would be relevant to the first calculation period and dates (b) and (c) would also be relevant for the second calculation period. Is this scenario realistic? If so we will need to provide a mechanism to say which calculation period each pricing date prices for (and it could be more than one). 1.2 Rounding PE asked whether the rounding model should represent the rounding methodology as well as the precision. JG noted that even if the methodology were represented in the schema, many systems only support one method of rounding and that it wasn't really appropriate information for a confirmation. PS agreed that rounding wasn't required for confirmations but noted it would be important for settlement. JG noted that rounding would typically be on a per-counterpart basis rather than per-trade. After general discussion, PS agreed to put together a list of rounding methodologies which will be reviewed by the group. BL said he felt there were two important steps to take when understanding rounding: 1. Go through a confirmation to identify anywhere where rounding could take place - and name them. 2. Investigate what's actually being done in the industry (some of the rounding points identified in 1 may not be relevant). 1.3 FX PE suggested that the FX averaging methodology should be subject to the same analysis as for rounding. 1.4 Pricing Dates PE asked whether the group thought the parametric model for pricing dates was flexible enough. BL stated that he felt it was important to differentiate between frequency and period/interval. In the context of the model, frequency was really being used to represent a time duration over which pricing would take place rather than an actual frequency. 1.5 ISDA Master Agreements coding scheme PE noted that master agreements were not typically referenced according to their ISDA version (e.g. ISDA 2002) on confirmations and suggested that a generic value should be added to the appropriate coding scheme. JG agreed that Glencore's systems would not know the master agreement type - the most recent contract date would be recorded and referenced. JG also said it was important to identify the ISDA definitions in use - 1993 v. 2005. PE agreed to get this added to the relevant FpML scheme. 2. PE explained the DeliveryDateRollConvention issue The group agreed that the offset would always be of type Scheduled Trading Day. 3. There was no time to go through the options discussion paper. This will be discussed on the next call. * Decisions Effective and termination dates will remain at the trade level in the swaps schema. Market disruption and fallback model will be incorporated into the swaps schema. Addition of generic value for most recent master agreement to the master-agreement-type coding scheme will be requested of the standards committee. Equally, the group will add the 1993 and 2005 Definitions to the relevant coding scheme. * Actions ALL to send in example confirms (especially those covering non-standard trades) to help test the integrity of the model. N.B. --> It should be noted that attachments to emails will be publically available on the internet from the fpml.org mailing archive and so disguising the parties involved is advisable. JG to provide example oil confirmations. PE to forward PS LEAP rounding slides. PS to write up the different methodologies for rounding and calculations within the schema. MG to pass on the request for a generic 'ISDA' value in the master agreement scheme to the standards committee. * Next meeting 1500 LDN Fri 18th July 2008 The content of this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient and may not be disclosed, copied or distributed. If you received this email in error, please contact the sender immediately by return e-mail or by telephoning +44 20 7260 2000, delete it and do not disclose its contents to any person. You should take full responsibility for checking this email for viruses. Markit reserves the right to monitor all e-mail communications through its network. Markit and its affiliated companies make no warranty as to the accuracy or completeness of any information contained in this message and hereby exclude any liability of any kind for the information contained herein. Any opinions expressed in this message are those of the author and do not necessarily reflect the opinions of Markit. For full details about Markit, its offerings and legal terms and conditions, please see Markit's website at http://www.markit.com <http://www.markit.com/> .
Attachment:
Confirms Templates.zip
Description: Confirms Templates.zip
Visit our website at http://www.ubs.com 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-mails are not encrypted and 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. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.