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). 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.
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 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 '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 also float/float swaps. There is no support at present 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 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 optional 'commonPricing' flag may be relevant for a Transaction that references more than one Commodity Reference Price. If Common Pricing is not specified as applicable (value set to 'true'), it will be deemed not to apply.
The optional 'marketDisruption' structure defines how the product should behave if there is a market disruption as defined in the 'ISDA 1993 Commodity Definitions' or in the 'ISDA 2005 Commodity Definitions', as applicable.
The commodity swap's 'rounding' element, if present, defines the direction and number of decimal places to which rounding should be performed in all amount calculations.
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:
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.
The 'calculation' structure captures details relevant to the calculation of the floating price.
The structure is defined by the following elements:
The product support for commodity options in FpML is based on the creation of a new '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 'buyerPartyReference' and 'sellerPartyReference' contain references to the parties that buy or sell the instrument respectively. Buying the instrument means paying for the instrument and receiving the rights defined by it. On the other hand, selling the instrument means granting the rights defined by the instrument and in return receiving a payment for it.
The optionType element is for specifying whether this is a call option or a put option.
The 'commodity' underlyer component is specified using a reference to the 'commodity' asset (see description above at the Commodity Underlyer section).
The following elements are specific to asian/averaging commodity options only:
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).
The 'exercise' structure contains the parameters for defining how the commodity option can be exercised and how it is settled.
The different options for specifying the strike price per unit will consist of a single strike price of a strike price schedule. Note that the intention is that a strike price per unit 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 strike price schedule to the calculation periods as clearly as possible. The strike price per unit of the strike price per unit 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 'premium' element defines 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).
The 'commonPricing', 'marketDisruption', and 'rounding' elements are common across all commodity transactions. For a detailed description of them see the commoditySwap section.
Previous | Top | Next |
---|