[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FpML-Com Latest Commodity Schema and Examples
Aplogies for Friday, UBS is closed for the holiday. I may dial in but
not have access to soft-copy docs.
-----Original Message-----
From: commwg@xxxxxxxx [mailto:commwg@xxxxxxxx] On Behalf Of Piers Evans
Sent: Wednesday, July 02, 2008 2:44 PM
To: commwg@xxxxxxxx
Subject: FpML-Com 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 0109
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/> .
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.
-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe commwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_commwgmail/threads.html