Main Page by Topic
CRTM Trade Type Taxonomy
CTRM systems are designed to model ‘Trades’ as defined in this page, i.e., tradition trades with counterparties or exchange-traded and things that are not trades like physical inventory.
‘Trades’ as defined here meet two important criteria:
1.1) Have a definitive start and end date. i.e., have a definitive ‘term’.
1.2) Not too many of them. Could be hundreds or thousands or tens of thousands, but not millions.
Why is this important? ‘Trades’ are relatively simple for a CTRM system to handle. Often, the system is designed for trade, meaning for ‘simple trades’, meaning the kind of exchange-traded or OTC (over the counter) trades that give the ‘T’ in CTRM, i.e., ‘Trading’ its meaning.
Note that we use ‘Trade’ and ‘Deal’ synonymously, i.e., they mean the same thing in our writings. We favor the term ‘Trade’, because it is CTRM and not CDRM.
Here are the things that would be considered a ‘Trade’:
2.1) Exchange Traded futures
2.2) Exchange Traded options
2.3) Commodity Swap. i.e., financially settling derivative. E.g., a fixed payment for a payment based on the settle prices of a particular commodity, e.g., NYMEX Natural Gas.
2.4) Interest Rate Swap. We are expecting a CTRM system to support some small amount of interest rate swaps that are needed to hedge interest rate risk associated with having active commodity trades.
2.5) FX (foreign exchange). To hedge FX risk associated with having active commodity trades in multiple currencies.
2.6) Commodity Options. i.e., financially settling derivative.
2.7) Commodity Swaptions. i.e., derivative that is cash-settled or that ‘delivers’ into a Commodity Swap.
2.8) Physical Trade. i.e., a buy or sell of a commodity with a definitive start and end date for delivery.
2.8.1) Example 1: Delivery could be for Natural Gas with daily deliveries (or receipts) for each calendar day for a given month.
2.8.2) Example 2: Delivery could be for Crude Oil for a total of 40,000 BBL to be delivered by marine vessel over a certain date range, i.e., could be one trade that allows for smaller deliveries that total to the full volume, e.g., 5k, 10k and 25k, so long as they are delivered in the agreed-to date range.
When we are talking about ‘Non-Trade’ we mean in the context of CTRM system design, meaning a characterization of ‘things’ into ‘Trades’ and ‘Non Trades’, with ‘Trades’ being the simpler, at least from a historical point of view, things for CTRM to model fully, mainly because of their discreteness, i.e., a definitive start and end date.
These ‘Non-Trade’ items have some characteristics of ‘Trades’, namely:
3.1) Will have payment associated with them. ‘Payment’ is used generically to mean either a payment or a receipt
3.2) Will have a MTM (mark to market). i.e., can be valued
3.3) Will have risk. i.e., also known as ‘market risk’ or a ‘market risk position’, meaning a sensitivity (i.e., as some calculable numeric value) to market price moves.
In some CTRM systems, their design might be so ‘trade focused’ that these types of things will be given a ‘trade number’ (or ‘deal number’). That in and of itself isn’t a bad thing. At this time, there isn’t a more generic term that is industry recognized to capture the totality of things that have payments and/or MTM and/or risk.
What can be problematic is trying to force ‘non trade’ items into a design that was built assuming discreteness of trades (known start and end) and relatively small volumes.
These are examples, if not the full list of things that a well-designed CTRM
By this we mean, physical inventory. This could be gold in a vault, or cocoa in a warehouse. This could be represented as an ‘account’, i.e., there might be several gold ‘accounts’ for gold that is physical all together in the same vault, i.e., it is not just the location, but also the ownership (permanent or temporary via a lease/loan). This could also be Natural Gas in a storage tank, though we consider storage as a separate category (see below).
Inventory would need to be valued, i.e., have a MTM. This could be one of these methods:
4.1.1) MTM based on spot rate. i.e., each day your PnL (profit/loss) is the ending inventory balance from the prior day times the change in the spot rate.
4.1.2) Market risk. E.g., your market risk exposure could be to the spot price of the commodity.
We’ll assume that ‘inventory’ doesn’t earn interest or have any fees. If there are fees associated with keeping it, we’ll call that ‘storage’ and might model it differently in a CTRM design.
We’ll also assume there is no interest payments associated with holding the inventory (i.e., like there might be with gold). If there are interest rates charges, we’ll consider that a ‘Callable Loan’ or some other type.
The particular challenge with inventory for a typical CTRM system is that it does not have a start and end date like a ‘Trade’. So inventory values (physical position and MTM) will continue to appear in the End of Day calculations/reports forever, unless the inventory balance goes to zero.
This isn’t necessarily a ‘challenge’ for a CTRM system that is well designed upfront. The issue comes for a CTRM system design that treats this as an afterthought, e.g., being forced to model it is a ‘trade’, e.g., a 100-year long trade (so it doesn’t end as a practical matter).
Storage, e.g., for Natural Gas, Crude or Refined Products, i.e., physical storage tanks.
The challenge for a CTRM system is that this might be a long term, i.e., and so can have performance issues. For example, if a CTRM system models ‘Storage’ as one long, e.g., 10-year long ‘trade’, then it can cause issues if you have to include that one big trade in your end-of-day calculations/reports.
A storage tank that a firm owns effectively has no ‘end date’, i.e., something that a CTRM system would need to take into account.
Plus, a storage tank can have many injections/withdrawals in a given month, and each might be associated with a fee (charged by the storage tank’s owner). This needs to be designed right upfront, to avoid performance issues.
The main point here is that ‘Storage’ is best modelled as something other than a simple ‘Trade’ (like a fixed term swap), i.e., for CTRM system design.
This refers to long term contracts with a pipeline to transport Natural Gas, Crude or Refined Products. Similar issues to Storage with regard to design.
Transmission is to power what ‘Transportation’ it to Natural Gas. And similar lesson/advice applies, which is that you’ll have problems if you model them as a simple ‘Trade’.
We’ll note that you can buy transportation or transmission on the spot market for a day or two. Those sort of one off things can be OK to model as a ‘trade’. The issue, i.e., the challenge for CTRM design, comes with modelling the long term contracts.
4.5) FTRs (Financial Transmission Rights).
FTRs are for the Power Market. Without getting into a full explanation of them here, we’ll just note that they can be 10s of thousands FTR ‘bids’ per month. That is, as a practical matter, too much for a CTRM system (of typical design) to handle. Plus, not all ‘bids’ are accepted, i.e., many bids just go away. So there needs to be a lifecycle for tracking and handling them.
Point again here is that, for a typical CTRM system, modelling each bid as a ‘Trade’ will not work out as a practical matter (for performance reasons). So the point here, again, is that these need a different sort of design, from the ground up.
4.6) Retail trades.
CTRM systems are, as per our definition, meant to support wholesale trading. So ‘retail trades’, shouldn’t necessarily be needed to be included in our list. We’ll just note that, due there being so many (10k+) retail ‘trades’ per month for a certain business, these can’t go into a CTRM system one-to-one.
What you can do, for MTM and risk management purposes, is to consolidate these trades into a small number, and feed the consolidated trades (i.e., volumes summed by certain criteria) into a CTRM system, just to include them in the overall end of day MTM/PNL/Risk calculations and reports.
4.7) Callable loans
This would mainly be for metals, e.g., precious metals like gold, silver, platinum, palladium. The idea is that the loan is ‘forever’, i.e., doesn’t have a definitive end date. The borrower would pay based on a fixed interest rate (called the ‘GOFO’ or gold forward rate) or a ‘floating’ rate (i.e., one that is based on the published GOFO rate). The payment would be based on the currency (e.g., USD) value of the metal.
So if you have 100 oz of gold and gold is at $1300/oz for given day (the value changes daily), then the notional on which the interest is paid would be $13,000.
Typically, interest would be paid monthly, based on the sum of the daily amounts (which can be different each day based on the value of the metal in USD changing).
The challenge in the design is that they don’t have a definitive end date. However, these need some sort of assumed end date (i.e., when the outstanding balance of the loan goes to zero), so as to be able to calculate MTM and risk (if you are not using the accrual method of accounting). So what do you do to model them? Do you
4.7.1) ‘Roll’ them each month or each quarter? i.e., to add additional forward months of projected interested.
4.7.2) Have the system automatically assume that they’ll go on (i.e., continue at the current balance) for a set number of days, e.g., 90 days forward, or 6 months or a year.
Whatever design, you want to make sure that there is minimal manual work, so minimal operational risk of human error.
A really good design would support a ‘date roll’ feature, where, for risk (market or credit), users may want to roll the system date forward (temporarily) for an analysis to see what MTM and risk values would be in the future if market prices/conditions remained the same and just time moved forward.
This is somewhat easily doable with simple ‘Trades’, as you can make the necessary assumptions, e.g., that prices remain the same, etc., and just roll the date forward. However, for each of the above ‘non-trade’ items above, depending on the design (and the original system requirements), projecting what values (MTM and Risk) into the future may not be possible, e.g., because the system is only able to capture how things look ‘now’, due to the limitations of the design.
‘Simple’ trades, with a small volume and definitive start and end date are relatively easy for a CTRM-system designer to design. For the above ‘Non-Trade’ type items, best to build a good design upfront, i.e., into the most basic and high level operations of the system, because trying to force them in as ‘trades’, after the fact, into an already-designed and build CTRM system may produce sub-optimal results.
Introduction to CTRM
Click on this link for a great introduction to CTRM software: Introduction to CTRM Software