Fpml Producttype

[Kandy Swartzel]

Whereapplicable, the CDM follows the data structure of the FinancialProducts Markup Language (FpML), which is widely used in the OTCDerivatives market. For example, the CDM type PayerReceiver isequivalent to the FpML PayerReceiver.model. Both of these are datastructures used frequently throughout each respective model. In othercases, the CDM data structure is more normalised, per Development Guidelines. For example, price and quantity arerepresented in a single type, TradableProduct, which is shared by allproducts. Another example is the use of a composable product modelwhereby:

Regardless of whether the data structure is the same or different fromFpML, the CDM includes defined Synonyms that map to FpML (and othermodels) and can be used for transformation purposes. More details onSynonyms are provided in the Mapping (Synonym) section of this document.

A tradable product represents a financial product that is ready to betraded, meaning that there is an agreed financial product, price,quantity, and other details necessary to complete an execution of asecurity or a negotiated contract between two counterparties. Tradableproducts are represented by the TradableProduct type.

The primary set of attributes represented in the TradableProduct datatype are ones that are shared by all trades and transactions. Forexample, every trade has a price, a quantity (treated jointly as a tradelot), and a pair of counterparties. In some cases, there are ancillaryparties, or an allowable adjustment to the notional quantity. All of theother attributes required to describe a product are defined in distinctproduct data types.

The counterparty attribute of a TradableProduct is constrained to beexactly of cardinality 2. The CDM enforces that a transaction can onlyoccur between a pair of counterparties, with any other party involved inthe transaction represented by the ancillaryParty attribute.

The counterparty attribute uses the Counterparty data type, whichlinks a specific Party object identifying that party to its role inthe transaction. The counterparty roles in the CDM are normalised to beeither Party1 or Party2 and captured as a pair of enumerated values.

This design allows to use anonymised Party1 and Party2 values tospecify the direction of flows in the definition of a tradable productwithout having to reference specific parties. This means that the sameproduct can now be defined in a party-agnostic way and used to representtransactions between potentially many different parties.

Note:The partyReference attribute in Counterparty is annotated with a[metadata reference], which means that a reference to the party objectcan be passed in instead of a copy. In that case, the attribute's typemust itself be annotated with a [metadata key], so that it isreferenceable via a key. The use of the key / reference mechanism isfurther detailed in the Rosetta DSL documentation.

In certain markets, trading the same product with the same economics(except for price and quantity) and the same counterparty may be treatedas a separate trade. Each trade is represented by a tradable productcontaining only 1 trade lot. In other markets, trading the same productwith the same characteristics (except for price and quantity) isrepresented as part of the same trade. In this case, a single tradableproduct contains multiple trade lots represented as an array of theTradeLot data type.

When a trade can have multiple trade lots, increases (or upsize) anddecreases (or unwind) are treated differently. An increase adds a newTradeLot instance to the tradadable product, whereas a decreasereduces the quantity of one or more of the existing trade lots.

Note:The term lot is borrowed from the Equity terminology that refers toeach trade lot as a tax lot, where the capital gains tax that mayarise upon unwind is calculated based on the price at which the lot wasentered.

The pricequantity attribute is represented as an array of thePriceQuantity data type. For composite financial products that aremade of different legs, each leg may require its own price and quantityattributes, and each instance of a PriceQuantity data type identifiesthe relevant information for the leg of a trade. For example, for anInterest Rate Swap, a trade lot would have one instance of thePriceQuantity data type for each interest leg, and potentially a thirdone for an upfront fee. By comparison, the purchase or sale of asecurity or listed derivative would typically have a singlePriceQuantity instance in the trade lot.

The price, quantity and observable attributes are joined together in asingle PriceQuantity data type because in some cases, those 3attributes need to be considered together. For example, the return legof an Equity Swap will have:

However, those attributes are optional because in other cases, only someof them will be specified. In the fixed leg of an Interest Rate Swap,there is no observable as the rate is already fixed. An option tradewill contain an instance of a PriceQuantity containing only thepremium as price attribute, but no quantity or observable (the quantityand/or observable for the option underlyer will be specified in adifferent PriceQuantity instance).

Both the price and quantity can be specified as arrays in a singlePriceQuantity. All elements in the array express the same values butaccording to different conventions. For example, the return leg of anEquity Swap may specify both the number of shares and the notional (acurrency amount equal to: number of shares x price per share) asquantities. In a Forward FX trade, the spot rate, forward points andforward rate (equal to spot rate + forward points) may all be specifiedas prices. When mutiple values are specified for either the price orquantity attributes in a single PriceQuantity instance, they will betied by rules that enforce that they are internally consistent.

The effective date attribute is optional and will usually be specifiedwhen a single trade has multiple trade lots, to indicate when each tradelot become effective (usually on or around the date when the lot wastraded). The trade itself will have an effective date, corresponding tothe date when the first lot was traded and the trade opened.

The price and quantity attributes in the PriceQuantity data typeeach have a metadata location which can reference a metadata address inone of the Payout data types. The metadata address-location pairallows for a reference to link objects without populating the addressobject in persistence. This capability helps to support an agnosticdefinition of the product in a trade (i.e. a product definition withouta price and quantity). However, the reference can be used to populatevalues for an input into a function or for other purposes.

MeasureBase defines the basic structure of a measure in which bothattributes are optional. Various other data types that extendMeasureBase can further constrain the existence of those attributes:for instance, a Measure requires the value attribute to be present(but unit is still optional because a measure could be unit-less).

To represent this, the MeasureSchedule type extends MeasureBase witha set of date and value pair attributes represented by the DatedValuetype. In that structure, the existing value attribute can still beomitted but, when present, represents the schedule's initial value.

The price and quantity concepts for financial instruments are bothmodelled as extensions of the MeasureSchedule data type, as detailedbelow. This means that by default, price and quantity are considered asschedules although they can also represent a single value when thedatedValue attribute is omitted.

The full form of this example can be seen by ingesting one of thesamples provided in the CDM distribution under products / equity /eqs-ex01-single-underlyer-execution-long-form-other-party.xml. As can beseen in the full example, for an interest rate leg, the unit and theperUnitOf would both be a currency (e.g. 0.002 USD per USD). ThepriceType would be an InterestRate and, in the case of a floating leg,the spreadType would be a Spread.

The QuantitySchedule data type also extends the MeasureSchedule datatype with the addition of an optional multiplier attributes. It alsorequires the unit attribute to exist, i.e. a quantity cannot beunit-less. The NonNegativeQuantitySchedule data type furtherconstrains it by requiring that all the values are non-negative.

The additional multiplier attribute that is provided for theQuantitySchedule data type allows to further qualify the value. Thisis needed for listed contracts or other purposes, as shown below. Inthis example, the trade involves the purchase or sale of 200 contractsof the WTI Crude Oil futures contract on the CME. Each contractrepresents 1,000 barrels, therefore the total quantity of the trade isfor 200,000 barrels.

The frequency attribute is used in a similar way when a quantity maybe defined based on a given time period, e.g. per hour or per day. Inthis case, the quantity needs to be multiplied by the size of therelevant period where it applies, e.g. a number of days, to get thetotal quantity.

The Observable data type requires the specification of either arateOption (i.e. a floating rate index), commodity,productIdentifier, or currencypair. This choice constraint issupported by specifying a one-of condition, as shown below:

In both the Equity Swap and Interest Rate Swap trade cases mentionedabove, there are no settlement terms attached to the price and quantity.Instead, any future settlement is driven by the product mechanics andthe price and quantity are just parameters in the definition of thatproduct.

In those cases, the corresponding PriceQuantity object also containssettlementTerms and buyerSeller attributes to define thatsettlement. The actual settlement amounts will use the price andquantity agreed as part of the tradable product.

The SettlementTerms data type defines the basic characteristics of asettlement: the settlement date, currency, whether it will be cash orphysical, and the type of transfer. For instance, a settlement could bea delivery-versus-payment scenario for a cash security transaction ora payment-versus-payment scenario for an FX spot or forwardtransaction. Those parameters that are common across all settlementmethods are captured by the SettlementBase data type.

3a8082e126