Trade data model
Trades are generally captured in dedicated Commodities Trading and Risk Management (CTRM) systems. For the sake of clarity, to be able to explicit how trade information has to be submitted to regulators and how it is exchanged between systems, we provide hereafter a 'generic' trade datamodel. The implementation in the various systems will obviously be different, but they all describe the same objects, hence the attributes will overlap. We can describe a trade as a concentric sequence of objects, which cascade a described hereafter.
We can describe a trade as a concentric sequence of objects, which cascade a follows:
- Contract: covers merely trade framework and identifiers.
- Trade: A contract can cover a single or, in case of structured transactions, multiple trades. The trade is the elementary contract component, which drafts the core financial details, such as the template according which it is generated, timespan and the parties involved.
- Leg: the legs detail which underlying will be delivered or observed for price discovery as well as quantity at stake. A trade has minimum two legs, one receivable, the other payable. If other payments are involved which depend on index or volume given in the principal legs, declaring extra legs may be a practical way to capture those.
- Period: a transaction has minimum one period, detailing exact dates for price fixing and settlement as well as effective volume. A sequence of periods may have contractually be agreed upon, such as a monthly strip within a year contract. A period supposes a reset at period start and a payment closing it.
- Flows: there are obviously the payment flows resulting from the principal, but annex flows may exist, such as fees, brokerage or various costs related to the proper execution of the transaction.
Most trades can be captured according the data fields detailed in below schema:
For trades where the settlement currency is different from the quotation currency of the index used to price the deal, a currency conversion has to happen. The following conversion modes are often applied, which does not exclude other, more bespoke, formulas.
For conversion between unit types (volume to weight, volume to energy), factor depends from the density of the delivered physical product. For intra-day deliveries, flow factor will depend from the delivery profile.