From: Irina
Yermakova [mailto:IYermakova@xxxxxxxx]
Sent: Tuesday, July 17, 2007 11:48
AM
To: Whiting, Elaine;
andrew.jacobs@xxxxxxxxxxxxxx; andrew.p.parry@xxxxxxxxxxxx; Brian Lynn; Lamy,
Pierre; Joseph, Rosh; Marc Gratacos
Cc: Karel Engelen
Subject: FW: FpML commodities model
discussion
Apologies
everyone,
but
since some of the people in the group are unable to join Commodity meeting
on Wed 18 July, we have to start from the begging again and propose new
meeting days. We suggest the small group meeting on any of the following
days: Wednesday 24, Thursday 26, Friday 27 and Monday 30 July at 10:00 a.m.
NY time. The meeting with LEAP could be done equally on one of those days as
well.
Please
let me know which of the above days would work for
you?
Rosh,
Could you please circulate the revisions prior to the meeting for the group
to review.
Kind
regards,
Irina
Yermakova
From: Irina
Yermakova
Sent: Tuesday,
June 05, 2007 8:44 AM
To:
Elaine.Whiting@xxxxxxxxxxxxxxxx; 'andrew.jacobs@xxxxxxxxxxxxxx';
andrew.p.parry@xxxxxxxxxxxx; brian.lynn@xxxxxxxxxxxxxxxxxxx; Marc Gratacos;
Lamy, Pierre; 'Joseph, Rosh'
Cc: Karel Engelen
Subject: FpML commodities model
discussion
All,
As
agreed, we’ll have a meeting this Friday, June 8 at 11:00 a.m. NY
time to discuss the current commodity work and the comments
received. Below and attached please find the agenda, dial in details and
supporting materials.
Dial-in
details:
If calling from the
US: 1 888 481 3032
If calling
Intl: 1 617 801 9600
Passcode: 751365
Agenda:
- Review the GS
comments (see copied below from the original e-mail) on the current
proposal and the alternative commodity underlyer proposal (attached)
- Review Brian’s
feedback (see copied below from the original e-mail) on the current
proposal.
- Other comments or
proposals.
Pierre’s
comments:
“This
is as a follow-up from concerns that Rosh expressed earlier (see below under
Rosh’s comments) in relation to the fact that the current underlyer
representation seemed to be focused on listed index underlyers (as it
extends the ExchangeTraded type), leading to a possible scope/usage
confusion in relation to the existing index
construct.
The
alternative construct that we propose aims at covering the various sets of
commodity underlyers (listed index, OTC index and physicals). Because
of time constraints we did not had a chance to fully develop the two schemes
that we suggest to have, nor to write all appropriate schema
definitions. We would do this if the group considers this approach as
a viable avenue. “
Rosh’s
comments:
“I
would just like to address some of the issues that I'm alluding
to.
1.
The Index underlyer
For the
swap, the recommendation below would have been fine but it is
based on the ExchangeTraded class. In commodities there are
also index-based swaps that come from Non-exchange publications.
And to extend the current definition would imply that other definitions
using this would also have to work with the
Commodities extensions. I would think we don't want to increase
the scope of this work needlessly.
2. The
Future underlyer
When we
represent a swap that is settling against the Nymex WTI contract
settlement, I would prefer for us to not use the future, as the
swap does not have a Future as it's underlying even though it gets its
price from the future settlement. Furthermore, when we extend the swap to
represent EFS's there shouldn't be any
ambiguity.
3. The
Commodity underlyer
Currently,
this underlyer also extends the ExchangeTraded class. Cleary that shouldn't
be the case if we want to represent Physicals and Index-based
( i.e. exchange contract settlements and publications
) underlyers. It may make more sense to redefine this underlyer to meet
our needs better.
4.
Underlyer type of Basket
Is this
supposed to be used for Indexation swaps? Can we keep it out for now? Or do
people have examples?
5. The
Underlyer class
Given
that most of the definitions under the SingleUnderlyer is not useful for
Commodities swaps, should we be looking to extend the Underlyer class to
include a "CommodityUnderlyer" or replace it instead of
extending?
6. The
FxFeature class : Regarding non-standard currency
settlement
For
example, NBP can be quoted in both EUR or GBP and settled accordingly, this
could be represented with the "Composite" feature set, if it stands for the
Avg( Commod * FX ). Can I ask what your definition of a composite
is? The definition in the FpML for Composite doesn't make sense
....
'If
“Composite” is specified as the Settlement Type in the relevant Transaction
Supplement, an amount in the Settlement Currency, determined by the
Calculation Agent as being equal to the number of Options exercised or
deemed exercised, multiplied by: (Settlement Price – Strike Price) / (Strike
Price – Settlement Price) x Multiplier provided that if the above is equal
to a negative amount the Option Cash Settlement Amount shall be deemed to be
zero.'
Besides
references to options, the formula also evaluates to
-1*Multiplier. Clearly that cannot be correct. Furthermore, is there an
example of a Quanto Swap that someone can supply? Not sure if doing so would
even complicate the swap unnecessarily. Similarly I would like to
understand "CrossCurrency" if anyone knows what it
represents.“
Brian’s
feedback:
“Following
please find some feedback on the proposal. Most of this has more to do
with the long term extensibility of the proposal than any shortcomings of
the existing proposal, which looks quite good. It comes based on my
background with commodity derivatives, which is a bit out of date, so it’s
possible that the industry has moved on in some areas and therefore some of
my comments are no longer quite so relevant.
This model looks like a
good first start. The main concerns I have about it are related to its
extensibility for additional cases.
In particular, I'm a little
concerned about the following types of cases:
- cases where the
commodity prices are based on averaging a series of futures prices, and the
rules for observing these prices must be defined.
- cases where there is
one or more FX conversions, especially where the FX prices must also be
averaged.
- cases where there is a basis (crack spread) that involves
units conversion (e.g. BBL vs. GAL, MMBTU vs. GJ) and/or FX
conversion.
I'm my experience the commodity indexes need to be able
to be more explicitly defined, at least in some cases, to specify which
contract is observed (nth nearby with a roll date of m) and the averaging
period (calendar month, last 3 days of period, etc.). In addition, in
my experience it may be necessary to combine multiple index values (possibly
involving a units conversion) to get an overall price either prior to or
after FX conversion. This may not be easy to do in a model where there
is only a single underlyer per leg.
I think that it would be
beneficial to do a number of examples involving basis trades, cross-currency
trades and/or averaging to flesh this
out.
General/Product
-----------------------
Is there any way
to tell the asset class of the product/underlyer? (ie. NG vs. CL
etc.)
It might be worth taking a look at base metal swap examples,
too, at some point. These tend to be very similar to energy
swaps.
Underlyer
- support seems to be lacking for customized
indexes, such as first nearby except 5 (i.e. use first nearby contract,
rolls to next contract 5 days before first nearby contract maturity).
The assumption here seems to be that the index is defined by some
platform. In my experience the index observation rules need to be defined per
contract (e.g. first vs. second nearby contract, roll date,
averaging period (last 3 days vs. full month vs. single price etc)
-
single underlyer per leg might be a problem for some more complex products,
e. crack spread with an FX conversion, where the FX rate is
averaged.
CommodityNotional element names
quantity => rename to
quantityPerPeriod?
FxFeature - this seems to allow only single FX rate
observations. In some markets, averaged FX rates are common (e.g. last 3 FX
rates in the observation period, or averaged over a full
month).
Units
=====
Why is the scheme for price
units different from that for quantity units? Shouldn't they be the
same scheme? Shouldn't these also be the same as the "PriceQuoteUnits"
scheme in fpml-valuation-base.xsd?
Documentation
=============
CommodityMarketDisruption
- most elements aren't documented.
FloatingPriceLeg, FixedPriceLeg -
documentation appears to be obsolete - refers to Return
Swap.
Naming
-
=====
Should
FixedPriceLeg and FloatingPriceLeg be renamed to more specifically refer to
commodities?
Example:
=======
Scheme URIs should be specified
for e-Confirm sourced coding schemes, e.g. productType, productCode,
partyId; these should be added to the appropriate coding scheme definitions
(e.g. partyIdScheme)
Spread schedule looks odd, as it is the same on
both sides. Also, spread is expressed in percent rather than
BBL.”
Feel
free to send your comments or proposals.
Kind
regards,
Irina
Yermakova
**************************************************************************************************************************
The information contained in either this email and, if applicable, the
attachment, are confidential and are intended only for the recipient. The
contents of either the email or the attachment may not be disclosed or used
by anyone other than the addressee. If you are not the intended
recipient(s), any use, disclosure, copying, or distribution is prohibited
and may be unlawful. If you have received this communication in error,
please notify us by e-mail at isda@xxxxxxxx then delete the e-mail and all
attachments and any copies thereof. This communication is part of an ISDA
process and is not intended for unauthorized use or distribution.
**************************************************************************************************************************