All, Please note that there is a call tomorrow at the usual time. Also, the group has a new member - Dirk Mattig from RWE. Hopefully Dirk will be able to introduce himself briefly tomorrow but he has significant experience of xml through collaboration with EFET. AGENDA: 1. Review outstanding actions 2. Business points from previous email (attached) and also one new one: DeliveryDateRollConvention - this currently uses the type CalculationPeriodFrequency which contains a mandatory rollConvention type. This is not so useful! It should be replaced with 1 of 2 types - Interval (a period multiplier and a period type) or Offset (same as Interval but with a day convention attached). Is this offset always going to be of type Scheduled Trading Day? If so, we should go with Interval to prevent mis-use. 3. Options Discussion Paper (also in the attachment) Dial in details: US: 1 888 481 3032 UK: 0 800 904 7961 Intl: 1 617 801 9600 Participant Code: 52016709 Note that the minutes to the last call are included below. Regards, Piers Evans ************************************************************* * Present Alistair Cross, GS Hans Ellis, SWIFT (Co-Chair) Piers Evans, Markit Wire (Co-Chair) Marc Gratacos, ISDA Raphael Iyageh, Goldman Sachs - not sure he was on call???? Owen King, Markit Wire Brian Lynn, GEM Ali Peera, GS John Solder, UBS Peter Stockman, DTCC Chuck Witter, MS * Apologies Bulent Ozkan, Triple Point * New Member of WG Krishna Devabhaktuni from Citadel joined the call * Review actions from last meeting 1500 LDN 6th June 2008 >> AP to double check why timeZone / holidayCalendar were originally in the model and report back to the group. AP confirmed that these were not required for the underlyer as mandatory elements. >> AP to report back to the group if Short Ton is required in the list of units. Short Ton is required. PE to add to unit scheme. >> PE to update underlyer model for frontline future (including / excluding). This was done for last week's call and included in underlyer model. >> OK to present a suggestion on how to represent Fallbacks and Market Disruption Events taking into account how this was done in other asset classes. OK presented this. See minutes. >>AC to see if he can send example confirmations for Conversion (Scaling) Factor purposes. AC sent in LEAP rounding spreadsheet to ensure continuity between LEAP / FpML. AC agreed to find some sample confirmations as well for model testing purposes. * Minutes 1. PE presented the swap model as far as this has been completed. 1.1 Trade-level element Effective and Termination Dates included at this level following feedback from the group. Question: Can a trade ever be based on different calculation period lengths (e.g. 1m vs. 2m) such that a novation in the middle of the 2nd month would cause each leg to start on a different date? Presumption is that the novation date would be the same for both legs and would not allow a 'full first period'. Group to confirm this. 1.2 Floating Leg valuation has been renamed to calculation to tie in more closely with ISDA Commodity Definitions terminology. notionalQuantity renamed totalNotionalQuantity Calculation Period schedule will be parameterised with the ability to specify a different notional per calculation period. Notional steps must line up with the calculation periods - i.e. one per period regardless of whether notional actually changes. PS asked whether a date should be able to be captured. AS said this was usually done. PE will review - possibly the best option is to allow the schedule to be captures as dates (AdjustableDates) such that the notional steps can be related back to a dated calculation period. 1.3 Market Disruption OK presented revised market disruption model. This was well received but group members are asked to review in more detail offline. * Decisions timeZone and holiday calendar not required in underlyer (time zone may be optionally specified for power trades - final implementation to be confirmed). Model should support the specification of actual dates in the schedule / notional steps. * Actions 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. AC to provide 'tricky' confirmations to aid testing the integrity of the final model. Group to review Effective Date question in relation to novations. Group to review market disruption model and agree it on next call. * Next meeting 1500 LDN Fri 4th 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/> .
--- Begin Message ---
- To: <commwg@xxxxxxxx>
- Subject: Latest Commodity Schema and Examples
- From: "Piers Evans" <Piers.Evans@xxxxxxxxxx>
- Date: Wed, 2 Jul 2008 19:43:45 +0100
- Thread-index: Acjcc440iYCdG1cCTS+uwnPCphEsjA==
- Thread-topic: Latest Commodity Schema and Examples
All, Please find attached the latest set of schema files and 3 worked examples borrowed from the work done by an earlier incarnation of the commodity working group. (The schema is still in FpML 4.4 format, but will need to roll to 4.5 in line with our target release.) In terms of the next steps for the group, I would suggest that we try to clarify the business points arising from the schema (see below) on the next call and not go into detail on the xml at this stage. This will leave people time to review the proposed model in more depth. We can then try to get the business logic of options complete on the next couple of calls (discussion paper by Owen King of Markit is attached), integrate this into the model and then spend several weeks on the xml. This will hopefully allow our business-facing colleagues to have maximum input on the business logic without having to wade through the xml code initially. Please let me know if this does not sound like a reasonable approach. Some more detail on the model and examples: There are a few potential gaps in the schema that we should probably discuss from the business perspective to ensure the model is able to handle all variants. Specifically, the following areas spring to mind: 1) Payment Dates - If a message contains the absolute payment dates rather than a schedule algorithm, should these be grouped per calculation period as notional steps are? If the dates were look-back and did not align with the calculation periods, this would be useful. (Perhaps this never happens?) 2) rounding - I have left the rounding model from the original GS schema unchanged, but wonder if, in addition to direction and the number of decimals there ought to be mention of when rounding is to be applied ... to the daily price calculation or to the final average price, for example. 3) FX - I have made a first stab at averaging FX but think that there is more to be done here. For example, could averaging follow rules other than daily / weekly etc? This would not currently be supported. I believe there is also a difference between converting the daily prices to the settlement currency and averaging as opposed to averaging the daily prices and converting to the settlement currency. Should the methodology in use be captured? 4) Pricing Dates - The model cannot handle a rule like 'the last 3 commodity business days on which the relevant futures contract is scheduled to trade on the exchange. Given that the frequency is controlled by a scheme, there would be an option to put 'Last 3' in this tag, but this is not easily dealt with by a machine... please advise. 5) General Question: The coding scheme for ISDA Master Agreements specifies the year - as in ISDA2002 for a 2002 Master Agreement. Generally people avoid this on paper confirms: "This Confirmation supplements, forms a part of, and is subject to the ISDA Master Agreement dated as of xxx". Should there be a generic value available 'ISDA'. With regard to the example trades, there are a few questions: * Example 1: Delivery Date(s): The calendar month and year corresponding to the Calculation Period >> I have assumed this is first nearby. Please advise. Pricing Date(s): The last Commodity Business Day on which the relevant Futures Contract is scheduled to trade on the Exchange >> I have just gone for the last Scheduled Trading Day. Is mention of the Commodity Business Day actually required? * Example 2: Pricing Date(s): The first Commodity Business Day during the Calculation Period >> In this case, I have decoded this as 5 days after the Calculation Period Start Date, which works. If the rule was 5 days after the second commodity business day, the model wouldn't handle it as is. Could this happen? * Example 3 Delivery Date(s): The calendar month and year corresponding to the Calculation Period >> As per example 1. Pricing Date(s): In respect of each Calculation Period, the last three Commodity Business Days on which the relevant Futures Contract is scheduled to trade on the Exchange >> As per point 4 above. Thanks, Piers Evans +44 20 7071 0109Attachment: Commodity Schema 2008-07-02.zip
Description: Commodity Schema 2008-07-02.zipAttachment: Commodity Options Discussion Paper_v4.doc
Description: Commodity Options Discussion Paper_v4.doc
--- End Message ---