Main Page by Topic
Intro to CTRM Software
Commodity Trading and Risk Management software (CTRM) is software that combines the functionality of ‘Trading’ and ‘Risk Management’ for commodities.
For clarity, a system that does only risk management would be a ‘risk management system’ or ‘commodities risk management software’ and not be considered CTRM, which refers to the combination of those functions.
CTRM Software began around the 1990s with such companies as OpenLink (founded 1992) and Allegro (founded 1988).
Reasons for the creation of CTRM software include:
a) Deregulation in the energy markets led to an increased need for risk management, which meant that firms that had trading systems looks to add risk management functionality.
b) In the earlier days of vendor software for commodities trading, there would have been separate software packages for trading and for risk management, similar to the way word processing software and spreadsheet software used to be sold separately and was later combined, e.g., Microsoft Word and Excel combined into Office.
Trading Functionality – Common Features
These are the most common features in CTRM software for Trading functionality:
1) Trade Capture
This is the ability to enter ‘trades’ into the system. Variations include
1.1) Manually via a screen in the system (‘via the GUI’). This could be via a:
1.1.1) ‘Trade Blotter’, which has one row per trade (or sometimes one column per trade)
1.1.2) Trade Input screen, i.e., one trade takes up the whole screen.
1.2) Import from file. Files could be
1.2.1) Text files, such as CSV.
1.2.2) Native Excel or Excel compatible
1.2.3) XML format.
1.3) Direct feed from:
1.3.1) An exchange, e.g., ICE or NYMEX
1.3.2) A broker
2) Trade Retrieval and Viewing
This is the ability for the user to request the system to load selected trades for viewing. This could be, for example, all trades for a certain date or all trades for a certain counterparty. There would also be a screen (or web page), where users could see the list of trades that meet the search criteria and potentially allow for multiple reports where different attributes of the trades, e.g., quantity, price, start date, end date, counterparty, are shown in different column configurations.
3) Ability to apply settlement prices to trade so as to calculate payments.
A typical trade will require prices that are unknown at the time the trade is done to later be applied to the trade so as to calculate a financial payment. For example, a trade done in May might be for a firm to receive 10000 Barrels physical crude oil in December (so some months after the trade date) and to pay the average of the December closing prices, with the payment due date on the 20th of the following January.
In this example, a trading system needs the ability to take the average price, e.g., $51/BBL, and use it to calculate the payment, which is just price times quantity so 10000 BBL * $51/BBL = $51,000 payment.
Note that this is not part of a risk management function. Calculating a payment based on closing (a.k.a., ‘settlement’) prices is done after the fact, i.e., after the prices are finalized and received, so this process is not a forward looking calculation of market risk.
Trading Functionality – Additional Features
These are extra features related to the Trading function that some CTRM systems may have. Even if a system does not have these, it would still be considered CTRM. The implication is that if a CTRM does not support these, a firm might do them manually if firm is small enough, or a larger firm might have other systems that perform these functions, with data fed from the CTRM.
1.1) E-mail or Fax
1.2) Electronic Confirmation eConfirm
3) Broker Fee
3.2) Broker tie out
3.3) Initial and/or variation margin
4) Regulatory Reporting functionality
Risk Management Functionality – Common Features
When the term ‘risk management’ is used, it is typically used to refer to market risk, which is the risk that market prices move against you, i.e., the risk that you lose money because of adverse market price moves.
There are other types of ‘risk’, such as ‘Credit Risk’, which is the risk that a counterparty does not pay you money that it owes you.
CTRM systems need at a minimum functionality related to market risk. While some CTRM systems may have functionality related to credit risk or other kinds of risk, those are not required for a system to be considered CTRM.
1) Ability to get a MTM (Mark to Market) for a Trade
MTM, also known as ‘Present Value’ or ‘Valuation’ is the most core feature of a risk management solution, as other aspects of risk management are dependent on being able to value a trade.
In order for a system to calculate the MTM for a trade, it needs to have the ability to have forward prices (a.k.a., ‘projected prices’). For example, if in May, a system needs to value a natural gas financial swap (a derivative trade) that runs from January to December of the following year, it needs to have forward prices for those future months.
Forward prices would typically be fed in from an exchange, e.g., NYMEX, or some other price source.
So long as the prices are for months in the future, they will fluctuate daily, which is what generates market risk. However, after the month in question, the prices are finalized based on the closing prices (a.k.a., settlement prices) and, since the now historic prices are no longer fluctuating, there is no longer market risk.
2) Ability to Calculate Market Risk Position for a Trade
The risk management component of CTRM software needs to be able to both calculate and report the price sensitivity for a trade, which is how much money a firm will make or lose for a small, usually $0.01 or $0.001, move in the market price of a commodity. This is sometimes called the ‘delta’ of a commodity, one of the ‘greeks’.
3) Price Shock Reporting, A.K.A., Stress Test, A.K.A., What If Analysis
The risk management component of CTRM software needs to be able to simulate how much money a firm will make (or lose) if market prices move up (or down) by a certain predetermined amount, for example, up 10%. A stress test report might show the results of multiple market price movements in a combined report, e.g., -10%, -5%, -2%, -1%, unchanged (for a baseline), +1%, +2%, +5%, +10%. Note that this does not take into account probabilities. So, for example, a system might calculate the change in the MTM of a trade or set of trades for a +10% move in the market, without indicating how likely it is that such a move will happen.
Some CTRM systems may also be able to calculate VaR (Value-at-risk) as part of their overall risk management capabilities. This takes the concept of a ‘Stress Test’ (change in market prices) and adds probabilities. For VaR, a typical percentage is 99% or 95%, where that probability is interpreted as the probability of losing less than the VaR amount is 99%. So, for example, if the VaR is reported as $1m at a 99% confidence level, then there is assumed to be a 1% chance that a firm will lose more than that amount.
CTRM Systems – Commodities Supported
CTRM systems commonly support the following commodities.
1.1) Natural Gas
1.4) Refined Products
2) Base Metals
3) Precious Metals
CTRM Systems – Trade Types Commonly Supported
1) Exchange Traded Futures
2) Commodity Swaps
3) Commodity Option
4) Physical Commodity Trades
CTRM Systems – Addition ‘Non Trade Types’ Commonly Supported
For a system that supports physical trading, it will often have support for these items, which are similar to trades in that they have a value (MTM) and market risk, but are not necessarily considered ‘trades’ because they don’t have a simple start and end date.
1.1) Balance MTM and position
2.1) Physical-owned storage
2.2) Contracts to use storage from other first
3) Transportation Contracts
Rights to use pipelines to transport natural gas, i.e., long term contract with pipeline service provider like Transco.
CTRM software that supports physical trading will also have a third component called ‘scheduling’ also called ‘logistics’ or ‘commodity management’.
Items that are Not Common Features of CTRM
1) Cash Applied
2) Data Warehouse
Sample CTRM Vendors and Software Packages
1) Vendor: ION Group
a) OpenLink ‘Endur’
b) Allegro ‘Horizon’
2) Vendor: Enuit
3) Vendor: ComFin Software