<p>FpML for Physically Settled Commodity Transactions – Schema Notes 2 Owen King, Markit 30th December 2008</p><p>This document summarises changes and additions to the FpML commodity schema to support physically settled commodity transactions.</p><p>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.</p><p>Changes The following proposed changes have been made to the schema based on the discussions at the last working group call.</p><p>Quantity Floating/Fixed Leg:</p><p> 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.</p><p>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.</p><p>1 Physical Leg:</p><p>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.</p><p>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.</p><p> 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.</p><p> 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.</p><p>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.</p><p>Gas Product Details</p><p> quality has been introduced to replace wobbeLabel and now references a coding scheme. </p><p>3 Pricing Dates</p><p>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.</p><p>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.</p><p>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?</p><p>4 Additions</p><p>Oil A preliminary structure for representing oil transactions has been added within CommodityPhysicalProduct.model, based on the ISDA and LEAP confirmation templates.</p><p> 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</p><p> 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?</p><p>5  pipeline references a coding scheme that will define the pipelines that can be used in the transaction.</p><p> 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?</p><p> withdrawalPoint represents the point at which the oil product is withdrawn from the pipeline.</p><p> 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?</p><p>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.</p><p> importerOfRecord represents the party that is designated as the importer of record for customs purposes.</p><p>Question: What delivery information is required for in-tank and tank-to-tank transactions?</p><p>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?</p><p>7</p>