|
I would agree since there is no guarantee that there is a common
or legal definition of a schedule for a product as Chuck points out. The EFET
approach is to actually include the schedule with time/capacity at the ‘step’
points and to exclude zero capacity periods from the schedule. A final point is
that UTC rather than clock time should be considered as using clock time in the
delivery location can cause problems at day-light saving (i.e. clock change). This is the approach EFET have taken for physical deliveries and
for physically settled index deals. H Hugh Brunswick Managing Director EFETnet B.V. Keizersgracht 62-64 1015 CS Amsterdam Tel: +31 (0) 20 - 301 13 98 Mob: +44 (0) 7767 27 27 26 Fax: +31 (0) 20 - 520 75 10 From: commwg@xxxxxxxx [mailto:commwg@xxxxxxxx] On
Behalf Of Witter III, Charles (IT) 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 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:complexType
name="HourlyScheduleType">
For
example the PEAK for the
MIDCO delivery location would be represented as …. <hourlySchedule scheduleName="PEAK"> Regards, Chuck Charles
Witter III, Executive Director -----Original
Message----- *
Present Hugh
Brunswick, EFET *
Apologies Hans
Ellis, SWIFT (Co-Chair) *
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 BL
did raise this to the Modelling Task Force, but interest was muted. >>
Group - Review which commodities are most important to their 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. -
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: Piers
Evans ---------------------------------------------------------------------
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 subject to Value Added Tax (VAT Registration No 761 4444 34).
Contact
information Fountain
House 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. |