16.1 Introduction
This section provides a detailed description of the product architecture for commodity derivatives. FpML provides support for commodity swaps (whether fix/float or float/float) and commodity options (American, European and Asian). Physically-settled trades are also covered including swaps for Electricity, Natural Gas, Oil, and Coal commodities. Support for Bullion Forwards is also included. A representation for a commodity underlyer has also been introduced, which is used within the commodity products but that can also be used within other products such as equity baskets.
For an overview of the commodities coverage in FpML and its linking with the legal documentation see the following document: FpML Commodities Coverage Matrix (pdf file)
The 'commodity' underlyer is meant to identify the commodity ‘index’ which is subject to the trade and is flexible enough to support agricultural products, and energy. Support for other commodity types has not been fully evaluated but this does not preclude their being able to be represented A number of global elements are already defined in the FpML schema for various asset types. The commodity underlyer follows the same model.
|
|
|
The 'instrumentId' and the 'description' elements are derived from the IdentifiedAsset type, which is used by multiple underlyers. The 'instrumentId' contains the unique identifier for the asset, and is intended to hold a Commodity Reference Price in the format set out by ISDA in the 1993 or 2005 Commodity Definitions. However, a CUSIP, ISIN, or any other identifier could also be used. The 'description' contains the name of the asset.
The following sequence of elements is optional and they are specified only in the event that no ISDA Commodity Reference Price or other identifier for this commodity ‘index’ exists.
- The 'commodityBase' element identifies the base type of the commodity being traded, for example 'Oil'.
- The 'commodityDetails' also identifies the type of commodity but it is more specific than the base, for example 'Brent'.
- The 'unit' element identifies the unit in which the underlyer is denominated.
- The 'currency' identifies the currency in which the Commodity Reference Price is published.
- Either the 'exchange' or the 'publication' is specified. For those commodities being traded with reference to the price of a listed future, the exchange where that future is listed should be specified in the 'exchange' element. On the other hand, for those commodities being traded with reference to a price distributed by a publication, that publication should be specified in the 'publication' element.
The 'specified Price' is not defined in the Commodity Reference Price and so needs to be stated in the underlyer definition as it will impact the calculation of the Floating Price.
The 'deliveryDates' element is applicable for a Commodity Transaction that references a listed future.
The 'deliveryDateRollConvention' specifies, for a Commodity Transaction that references a listed future via the 'deliveryDates' element, the day on which the specified future will roll to the next nearby month when the referenced future expires.
The 'multiplier' specifies the multiplier associated with the transaction. This element is intended for use with freight transactions.
The commodity swap product is designed to support both fixed/float swaps and float/float swaps. There is also support for describing the attributes of physical commodity delivery. Its design is fully compatible with other FpML products and reuses standard common types.
As with all products in FpML the commodity swaps are accessed through a global element 'commoditySwap' which can substitute the 'product' element used in the construction of trade structures. The following diagram outlines the product structure.
|
|
|
The 'commoditySwap' structure only defines parameters for product-related information (e.g. dates, rates, underlying commodity, price source, etc.). Other trade-related information (e.g. trade date, identifiers, legal documentation, etc.) is held in the containing trade structure.
The 'commoditySwapLeg' element is placeholder within commoditySwap structure for the actual commoditySwap swap legs (e.g. fixedLeg and floatingLeg).
The repeating 'fixedLeg' and 'floatingLeg' elements contain the details of any scheduled payments or exchanges during the life of the instrument and are described later. A simple commodity swap would contain two legs, typically one fixed and one floating, but the repetition allows more complex multi-legged exchanges to be described.
The product representation of physically-settled trades is done within 'coalPhysicalLeg', 'elecricityPhysicalLeg', 'gasPhysicalLeg', 'oilPhysicalLeg' paired with 'fixedLeg' or 'floatingLeg' - see details in the Physical Leg section.
CommodityContent.model-Items common to all Commodity Transactions.
|
|
|
A schedule of fixed payments associated with a commodity swap are defined within a 'fixedLeg' using the following structure.
|
|
|
As with other FpML leg structures the payer and receiver parties are explicitly indicated in the 'payerPartyReference' and 'receiverPartyReference'.
The role of the remaining elements is as follows:
- The 'calculationPeriods' or 'calculationDates' if the Calculation Periods are all one day long or the 'calculationPeriodsSchedule' is only intended to be used if the Calculation Periods differ on each leg. If Calculation Periods mirror another leg, then the 'calculationPeriodsReference' element should be used to point to the Calculation Periods on that leg or 'calculationPeriodsDatesReference' element should be used to point to the single-day-duration Calculation Periods on that leg or the 'calculationPeriodsScheduleReference' can be used to point to the Calculation Periods Schedule for that leg.
- The 'fixedPrice' structure defines the price for a given unit of the underlying commodity where that price is fixed for the life of the trade.
- On the other hand, if the fixed price varies over the life of the trade, then the 'fixedPriceSchedule' structure is used instead of the 'fixedPrice'. Note that the intention is that a fixed price step should be specified for each Calculation Period in the trade, regardless of whether there is a change in value between two periods. This is so as to match the fixed price schedule to the calculation periods as clearly as possible. The fixed price steps must be in chronological order (i.e the first step corresponds to the first Calculation Period, the last step to the last Calculation Period).
- The 'totalPrice' structure specifies the total amount of all fixed payments due during the term of the trade.
- The notional amount is specified stating either the 'notionalQuantity' or if the notional changes over the life of the transaction, then the 'notionalQuantitySchedule' is specified. The 'settlementPeriodsNotionalQuantity' should be specified for an electricity transaction, the Notional Quantity for a one or more groups of Settlement Periods to which the Notional Quantity is based. If the schedule differs for different groups of Settlement Periods, this element should be repeated. In addition, the 'totalNotionalQuantity' must be specified. Note that the intention is that a notional step should be specified for each Calculation Period in the trade, regardless of whether there is a change in value between two periods. This is so as to match the notional quantity schedule to the calculation periods as clearly as possible. The notional steps must be in chronological order (i.e the first step corresponds to the first Calculation Period, the last step to the last Calculation Period). If notional amount mirror another leg, then the 'quantityReference' element should be used to point to the Notional Quantity.
- The 'paymentDates' structure supports either the definition of dates as either a series of unadjusted dates along with a date roll convention and business calendar location list for adjustment, or as set of adjusted dates relative to some other date schedule defined elsewhere in the product (e.g. in the floating leg).
- The 'relativePaymentDates' are specified when the payment dates are relative to the calculation periods.
- The Flat Rate, applicable to Wet Voyager Charter Freight Swaps. Whether the Flat Rate is the New Worldwide Tanker Nominal Freight Scale for the Freight Index Route taken at the Trade Date of the transaction or taken on each Pricing Date. The 'flatRateAmount', If 'flatRate' is set to 'Fixed', is the actual value of the Flat Rate.
Each 'floatingLeg' defines a series of financial payments for a commodity who's value is derived from a floating price source such as an exchange.
|
|
|
As with the 'fixedLeg' they parties obligation to pay and receive the payments are explicitly indicated by the 'payerPartyReference' and 'receiverPartyReference' elements.
Two structures distinguish the 'floatingLeg' from the 'fixedLeg': the existence of the 'commodity' underlyer (see description above at the Commodity Underlyer section) and the 'calculation' structure within the floating leg.
16.3.4.1 calculation
The 'calculation' structure captures details relevant to the calculation of the floating price.
FloatingLegCalculation-A type to capture details relevant to the calculation of the floating price.
The structure is defined by the following elements:
|
|
|
16.3.4.1.1 pricingDates
CommodityPricingDates-The dates on which prices are observed for the underlyer.
|
|
|
16.3.4.1.2 fx
fx-FX observations to be used to convert the observed Commodity Reference Price to the Settlement Currency.
|
|
|
16.3.5.1 Coverage
The support for physically-settled commodities trades includes,
- Natural Gas
- Oil
- Electricity
- Coal
16.3.5.2 Product Representation
The product representation of physically-settled trades is done within the commoditySwap product element by adding a family of physical legs.
- Fixed price transaction = xxxPhysicalLeg + fixedLeg
- Floating price transaction = xxxPhysicalLeg + floatingLeg
Note: xxx gets replaced by oil, gas, electricity, and coal.
The following structures vary between all these commodities,
- Delivery periods
- Product
- Delivery
- Quantities
commodityOption-Defines a commodity option product.
The product support for financially-settled or physically-settled bullion forward options in FpML is based on the creation of a 'commodityOption' product. The product references the 'commodity' underlyer in order to support the underlying asset of the option.
All FpML products inherit two optional elements from the Product type: 'productType' and 'productId'. The 'productType' defines a classification of the type of product. FpML defines a simple product categorization using a coding scheme. The 'productId' contains a product reference identifier allocated by a party. In this case, FpML does not define the domain values associated with this element.
|
|
|
The choice allows to selecet the financially-settled commodity options or bullion forward options.
CommodityFinancialOption.model-Items specific to financially-settled commodity options.
|
|
|
16.4.1.1 commodityOption - CommodityFinancialOption - CommodityAsian
CommodityAsian.model-Model group containing features specific to asian/averaging commodity options.
The following elements are specific to asian/averaging commodity options only:
|
|
|
16.4.1.2 commodityOption - CommodityFinancialOption - CommodityNotionalQuantity
As with the 'commoditySwap', the notional amount of the 'commodityOption' is specified stating either the 'notionalQuantity' or if the notional changes over the life of the transaction, then the 'notionalQuantitySchedule' is specified. In addition, the 'totalNotionalQuantity' must be specified. Note that the intention is that a notional step should be specified for each Calculation Period in the trade, regardless of whether there is a change in value between two periods. This is so as to match the notional quantity schedule to the calculation periods as clearly as possible. The notional steps must be in chronological order (i.e the first step corresponds to the first Calculation Period, the last step to the last Calculation Period).
|
|
|
16.4.1.3 commodityOption - CommodityFinancialOption - CommodityExercise
CommodityExercise-The parameters for defining how the commodity option can be exercised, how it is priced and how it is settled.
|
|
|
16.4.1.3.1 CommodityAmericanExercise
CommodityAmericanExercise-A type for defining exercise procedures associated with an American style exercise of a commodity option.
|
|
|
16.4.1.3.2 CommodityEuropeanExercise
CommodityEuropeanExercise-A type for defining exercise procedures associated with a European style exercise of a commodity option.
|
|
|
CommodityPhysicalOption.model-Items specific to financially-settled commodity options.
The approach is similar to that used for interest rate swaptions by embedding a physically-settled preciouse and non-preciouse metal forward transaction within the option transaction. So that the exercise of an option results in a new physically-settled forward transaction.
|
|
|
The 'commodityForward' component is described in the 'Commodity Forward' section below.
The 'physicalExercise' component is the same as for physically-settled commodity options described in the 'commoditySwaption' section below.
NOTE: support for other physically-settled options within 'commodityOption' is DEPRICATED. The 'commoditySwaption' product should be used instead.
The commoditySwaption is specific to physically-settled commodity options:
All FpML products inherit two optional elements from the Product type: 'productType' and 'productId'. The 'productType' defines a classification of the type of product. FpML defines a simple product categorization using a coding scheme. The 'productId' contains a product reference identifier allocated by a party. In this case, FpML does not define the domain values associated with this element.
|
|
|
The approach is similar to that used for interest rate swaptions by embedding a physically-settled swap transaction within the option transaction. So that the exercise of an option results in a new physically-settled swap transaction.
|
|
|
physicalExercise-The parameters for defining how the commodity option can be exercised into a physical transaction.
|
|
|
premium-The option premium payable by the buyer to the seller.
Should the premium differ over the course of an Asian options life (e.g. because delivery is per calendar day which is reflected in the premium), a premium schedule should be specified. Note that the intention is that a premium step should be specified for each Calculation Period in the trade, regardless of whether there is a change in value between two periods. This is so as to match the premium schedule to the calculation periods as clearly as possible. The premium steps must be in chronological order (i.e the first step corresponds to the first Calculation Period, the last step to the last Calculation Period).
|
|
|
CommodityContent.model-Items common to all Commodity Transactions.
The 'commonPricing', 'marketDisruption', and 'rounding' elements are common across all commodity transactions. For a detailed description of them see the commoditySwap section.
|
|
|
The commodityForward product element supports the representation of Bullion Forwards. Whilst some commodity forwards are booked as single period swaps, precious forwards are extremely basic trades and are confirmed under a different ISDA confirmation template
Even though the initial scope is limited to Bullion Forward, the intention of the working group is to allow support for other commodity classes should this be required.
|
|
|
The fixed payment of the Commodity Forward product is represented using the fixedLeg element of type NonPeriodicFixedPriceLeg.
|
|
|
The 'commodityForwardLeg' element is placeholder within commodityForward structure for the actual Precious and Non-Precious metal legs (e.g. bullionPhysicalLeg and metalPhysicalLeg).
The intention of the new leg is to re-use as many existing commodity components as possible to achieve a flexible implementation of a forward that will be adaptable for use with further commodity classes.
Consequently, the BullionPhysicalLeg component will be a member of a choice group such that further commodity types can be added over time.
|
|
|
