|
|
|
|
Main
Page by Topic |
||
|
C. Statistics |
||
CRTM
Trade Type Taxonomy
Overview
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.
Outline
‘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
4.1) Inventory
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).
4.2) Storage
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.
4.3)
Transportation
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.
4.4)
Transmission
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.
In summary:
‘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