For many electricity trades it is common to specify the daily/hourly delivery schedule using common industry conventions such as
PEAK - High Usage Days/Hours
OFF PEAK - Low Usage Periods Days/Hours
BASE - 24 hours per day ; 7 Days per week
The specific days/hours that are considered PEAK or OFF PEAK are associated with the specific delivery location.
For example most East coast locations PEAK is defined as Monday-Friday 8am-11pm (excluding NERC holidays) and OFF PEAK is defined as Monday-Friday 11pm-8am + Sat & Sunday all 24 hours 11pm (excluding NERC holidays) Eastern Prevailing Time
For most West coast delivery locations PEAK is defined as Monday-Saturday 7am-10pm (excluding NERC holidays) and OFF PEAK is defined as Monday-Friday 10pm-7am + Sunday all 24 hours Pacific Prevailing Time
BASE is always 24x7 - no holidays
Since these "trading conventions" are continuously expanding - I would recommend we develop an xml Hourly Schedule which can be used to parametrically capture this at the schedule level. Here is a possible implementation for consideration.
<xs:complexType name="DayScheduleType">
<xs:sequence>
<xs:element name="type" type="xs:string"/>
<xs:element name="hours" type="xs:string"/>
<xs:element name="days" type="xs:string"/>
<xs:element name="timezone" type="xs:string"/>
<xs:element name="includeHolidays" type="xs:boolean"/>
</xs:sequence>
<xs:attribute name="scheduleName" type="xs:string"/>
</xs:complexType>
<xs:complexType name="HourlyScheduleType">
<xs:sequence>
<xs:element name="scheduleName" type="xs:string"/>
<xs:element name="scheduleCalendar" type="xs:string" minOccurs="0"/>
<xs:element name="ignoreDaylightSavings" type="xs:boolean" minOccurs="0"/>
<xs:element name="daySchedule" type="ct1:DayScheduleType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="scheduleName" type="xs:string"/>
</xs:complexType>
For example the PEAK for the MIDCO delivery location would be represented as ….
<hourlySchedule scheduleName="PEAK">
<scheduleCalendar>NERC</scheduleCalendar>
<ignoreDaylightSavings>false</ignoreDaylightSavings>
<daySchedule scheduleName="PEAK_PACIFIC">
<hours>000000111111111111111100</hours>
<days>1111110</days>
<:timezone>PPT</timezone>
<includeHolidays>false</includeHolidays>
</daySchedule>
</hourlySchedule>
Regards,
Chuck
Charles Witter III, Executive Director
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY 10577
Phone: +1 914 225-8064
Charles.Witter.III@xxxxxxxxxxxxxxxxx
-----Original Message-----
From: commwg@xxxxxxxx [mailto:commwg@xxxxxxxx] On Behalf Of Piers Evans
Sent: Monday, May 19, 2008 2:00 PM
To: commwg@xxxxxxxx
Subject: FpML-Com Minutes of 2008-05-16 call
* Present
Hugh Brunswick, EFET
Piers Evans, SwapsWire (Co-Chair)
Marc Gratacos, ISDA
Chito Jovellanos, Forward Look
Owen King, SwapsWire
Lyteck Lynhiavu, ISDA
Brian Lynn, GEM
John Solder, UBS
Peter Stockman, DTCC
Chuck Witter, Morgan Stanley
* Apologies
Hans Ellis, SWIFT (Co-Chair)
Luis Fierro, Deutsche Bank
* Review actions from last meeting 1500 LDN 02 May 2008
>> BL - Continue to produce cash flow matching explanation document.
Brian will continue to work on this document.
>> BL - Consider whether BL's point on the modelling of interest rate
underlyers should be raised to the Modelling Task Force.
BL did raise this to the Modelling Task Force, but interest was muted.
This point will be removed from the commodity group's actions given that it is beyond the scope of the work the group is doing. BL can update the group if anything happens at the Modelling Task Force level.
>> Group - Review which commodities are most important to their
institutions so that the model can be tested for business compliance once it has been developed.
This action is now complete. All participants identified some combination of oil, power and gas as the most important commodities for them overall.
* Minutes
PE presented the revised underlyer model as per the text file 'Commodity Underlyer Implementation.txt'.
- The first six points were agreed by the group.
- Point seven - the removal of the deliveryLocation element was questioned.
PS wondered whether delivery location was related to the index definition.
PE to review how often delivery location is used in ISDA's Commodity Reference Price definitions by way of determining its relative importance to defining the index (it is not a field that ISDA include in their own commodity reference price framework).
PE to ask EC why this element existed in the original GS proposal.
HB wondered whether it might be related to holiday centres, however this could generally be derived from the exchange if any. In the case of publications, the group was unsure as to whether the publication calendar would always align with the underlying commodity - could there ever be a date when the publication was to publish but the commodity was not?
HB to investigate further.
Group will revisit this issue in the light of HB's and EC's feedback.
- Point eight was agreed but some additional questions were raised.
CW felt it would be necessary to differentiate peak periods from off-peak periods. CW to obtain an example of such a trade for the group to review.
CJ said that power can settle in fifteen minute increments in Europe. HB agreed. PE to add a 'QuarterHourly' value to the SettlementPeriodDurantionEnum.
MG asked that the parent SettlementPeriods type be removed as this is not FpML compliant. PE to revise model.
- Points 9 and 10 were questioned in a similar fashion to point seven.
PE to contact EC to establish why these items were in the model originally. Group will review based on EC's feedback.
- Points 11 and 12 were agreed. HB explained that the '_Including ' and '_Excluding' values referred to the futures contract that will apply on a roll date: i.e. whether it will it be the expiring contract or the new front month contract.
The group felt that this could apply to all delivery dates and not just the first and so will aim to model this concept in a different way. PE to review options. HB to look for examples of how this is confirmed currently.
- Group agreed that commodity indices such as the GS Commodity Index could be reviewed later given that they may have extra complexities such as multiple exchanges.
- Group to decide whether the EFET element names should be included in the schema documentation to aid mapping from one schema to another.
- Group reviewed HB's feedback on the underlyer discussion paper.
1. Value of 'Other' for specified price will be omitted.
2. Factor is a basket item and may be covered by the existing FpML basket model. The group will return to this item when modelling baskets.
3. Only delivery dates referencing futures will be supported.
4. Group agreed that pricing dates is more a function of the trade than the commodity underlyer and should be modelled elsewhere.
HB pointed out that the CBD value in the pricing dates enumeration does mean every day on which the commodity prices. However, a value of 'All-Days' is being considered by EFET as the commodity business day may not be relevant for averaging.
Group will review the options for this field when modelling the commodity products.
- Time ran out at this point. Group will continue to review HB's feedback next week and determine any impact on the underlyer model before moving on to review the Commodity Swap Discussion Paper.
* Decisions
The group will aim to validate the new Underlyer proposal next week as far as possible before moving on to the swap model.
Next meeting 1500 LDN Fri 23 May 2008
* Actions
PE to ask EC why deliveryLocation existed in the original GS proposal and review how often it is used by ISDA to define Commodity Reference Prices.
HB to investigate need for deliveryLocation in underlyer representation.
CW to obtain an example financial power confirmation for the group showing peak vs. off-peak in use.
PE to add a 'QuarterHourly' value to the SettlementPeriodDurantionEnum.
PE to revise model for settlementPeriod to be FpML compliant.
PE to contact EC to establish why holidayCalendar and timeZone were in the model originally.
PE to review options for modelling the concept of delivery dates needing to reference the expiring / new front month contract on the last trading day.
HB to look for examples of how delivery dates includin / excluding the expiring contract are confirmed currently.
(Revised underlyer model is attached as a zip. Please note that these can be downloaded here:
http://www.fpml.org/_wgmail/_commwgmail/threads.html)
Piers Evans
---------------------------------------------------------------------
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.
Company Details
SwapsWire Limited is regulated by the Financial Services Authority and is entered in the FSA's Register (FSA Reference Number 207294).
SwapsWire Limited is subject to Value Added Tax (VAT Registration No 761 4444 34).
SwapsWire Limited is registered in England at Companies House, no: 4027741.
Registered Office: One Silk Street, London, EC2Y 8HQ
Contact information
If you have any questions in relation to this policy please contact us at:
Fountain House
130 Fenchurch Street
London EC3M 5DJ
Attn: Rachel Cunningham-Day, General Counsel
Email: Rachel.cunningham-day@xxxxxxxxxxxxx
If you currently receive marketing information from us which you would prefer not to receive in the future please email us at info@xxxxxxxxxxxxxx
All email messages sent to and from info@xxxxxxxxxxxxx may be monitored to ensure compliance with internal policies and to protect our business.
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.