FpML for Physically Settled Commodity Transactions
– Schema Notes 2
Owen King, Markit
30th December 2008
This document summarises changes and additions to the FpML commodity schema
to support physically settled commodity transactions.
For clarity, in diagrams where an element exists and is unchanged from the FpML
4.5 Last Call Working Draft of the financial commodities schema, it is greyed out.
Changes
The following proposed changes have been made to the schema based on the
discussions at the last working group call.
Quantity
Floating/Fixed Leg:

quantityReference
has
been
added
to
CommodityNotionalQuantity.model to allow the floating or fixed leg to
reference the quantities defined within the physical leg. The element would
reference the id attribute of the quantities element within the
physicalLeg.
Where the floating or fixed leg quantities match those of the physical leg, i.e
the quantity to be physically delivered, this element can be used. It also
allows the fixed or floating les to reference the variable quantity structure
within the physical leg, if applicable.
1
Physical Leg:
The model has been simplified into a choice between two sequences; one for fixed
quantity trades the other for variable quantity trades. Note that fixed/variable in this
context is intended to refer to the quantities confirmed, not necessarily those actually
delivered.
2

firm if true, indicates that the quantities specified are legally binding. If false,
delivery of the quantities is on a best-efforts basis. “Firm” is a defined term in
the ISDA North American gas Annex.

minQuantity and maxQuantity within the variable sequence, allow a
minimum and maximum quantity to be specified. These elements can be
repeated if different maximums are required per day and per month, for
example.

electingParty optionally represents the party who can decide the quantity
to be delivered. It is intended that this element could be used to distinguish
between swing and interruptible trades, for example.
It is intended that the elements within quantities could be used to reach a
classification equivalent to the LoadType element within the EFET eCM schema.
Gas Product Details

quality has been introduced to replace wobbeLabel and now references a
coding scheme.
3
Pricing Dates
In order to represent floating price (physical index) trades, a method of specifying
that the calculation/averaging of the floating price should only take place on days in
which the commodity is actually delivered is required.
PricingDays.model, which is already part of the floating leg structure, currently
allows the construct “All Commodity Business Days in each Calculation Period”, by
setting dayType to “CommodityBusiness” and dayDistribution to “All”. The
coding scheme referenced by dayType could be extended to include “GasFlow” as a
day type so that “All Gas Flow Days in each Delivery Period” could be specified.
Question: Gas Flow Day is a defined term in NBP 97. Is it also used in other markets
or are there equivalent terms that should also be included or used instead?
4
Additions
Oil
A preliminary structure for representing oil transactions has been added within
CommodityPhysicalProduct.model, based on the ISDA and LEAP confirmation
templates.

type is to represent the type of oil product being confirmed. For example,
crude oil, fuel oil etc.
o Question: Does the group feel the oil types defined by ISDA in Annex
B of the Commodity Definitions (listed below) represent industry
practice? If so a default coding scheme could be constructed
containing these.
1. Benzene
2. Diesel
3. Fuel Oil
4. Gas Oil
5. Gasoline
6. Heating Oil
7. Jet Fuel
8. Methanol
9. Naphtha
10. Butane
11. Propane
12. Ethane
13. Isobutane
14. LNG
15. EP Mix
16. Crude Oil
17. Ultra Low Sulfur Diesel

grade is to represent a specific characteristic of the oil product, for example
viscosity.
o Question:
How is the grade actually represented? Does the
representation differ between oil types?
5

pipeline references a coding scheme that will define the pipelines that can
be used in the transaction.

entryPoint optionally represents the point at which the oil product enters
the pipeline, again using a value defined in a coding scheme.
o Question: Does the group think that the ability to confirm the entry
point is actually required for pipeline trades?

withdrawalPoint represents the point at which the oil product is withdrawn
from the pipeline.

cycle is to specify the operational cycle of the pipeline during which the oil
will be delivered.
o Question: How is a cycle actually represented (a number, code or
times etc)? Is it necessary to specify multiple cycles or any more
complex grouping of cycles?
6

liableParty is to represent which party is liable for the shipping and
loading costs. This is intended to be equivalent to specifying FOB/FIP.

importerOfRecord represents the party that is designated as the importer
of record for customs purposes.
Question: What delivery information is required for in-tank and tank-to-tank
transactions?
Question:
Barge/Tanker oil trades are not currently covered by the ISDA
documentation (although LEAP is working on a Rotterdam Barges contract). Does
the group feel that it would be beneficial to attempt to model delivery details for these
types of trades at this stage?
7