|
|
|
|
Main
Page by Topic |
||
|
C. Statistics |
||
Applying
Settlement Prices – CTRM Design Considerations
This page has
considerations for design around ‘Applying Settlement Prices’ in the context of
CTRM system design.
Outline
1) What Are We Talking About Here?
3) Considerations for CTRM system design
1) What Are We Talking
About Here?
By ‘Applying
Settlement Prices’ we mean, taking the settlement prices, also called closing
prices, and applying them to trades for the purposes of calculating payments.
This is sometimes
called ‘Resets’ or alternately ‘Price Fixing’.
We avoided using those terms as it isn’t clear what is considered
industry standard. So tried to use a
term that is descriptive of what is happening.
A single
payment can be based on the average of multiple settlement prices, e.g., over a
month.
Example would
be for a fixed-float commodity swap, the fixed price side doesn’t need
settlement prices, e.g., if the fixed price is $51/BBL for crude oil, that is known at the time the trade is originally
done. However, the settlement prices
won’t be known for potentially several months, i.e., whatever future month the
swap trade is for. E.g., if the current
day is June 3, the trade could be pricing over the month of December.
The two main
approaches are:
2.1) Copy the
price value, each day, onto the trade.
E.g., if you have a 1000 trades that need a
price for December 1 (assuming that is a good business day) and the price for
that date, i.e., the closing price from the price publisher for that day is
$52, then you would copy that price 1000 times.
Plus have it in the system saved with the table that holds settlement
prices.
2.2) Alternately, you can save the source settlement price just
once. And then pull it in whenever you need
to do a calculation, i.e., to calculate the payment.
Keep in mind
that a deal could have some of its prices for an average be ‘known’, meaning
the settlement prices already published and loaded into the system, and the
remainder would still be ‘unknown’, which means to get a MTM for the deal, you
would need to use projected prices, e.g., from a ‘forward curve’ .
3) Considerations for
CTRM system design
3.1) For the above two approach, if you go with a design based on
the first approach, you’ll need to have a mechanism to correct trades for when
prices change. Meaning
settlement prices change. E.g.,
if you are on December 15, and you realize that the December 3 price was loaded
into the system incorrectly, you need a way to correct it on all of the deals,
e.g., 1000.
This can be a
bit of a pain, so maybe copying the price onto each deal isn’t the best
approach.
Maybe a hybrid
approach is best, where you can specify that prices would be copied to some
deal, presumably so that they could be overridden as a one off, and in other
cases, would come from a common source, i.e., the settlement prices table.
3.2) You do need to keep in mind that you need a way to finalize
the payment amount, which would be the average of the prices for the month or
just for a single day (non-averaging).
Finalize in the sense that once an invoice goes out, you don’t want the
system to automatically change/update the payment just because you load a new
price, new meaning updated, into the system.
You may need a process to handle adjustments for prior periods or some
way to resent invoices.
In other
words, applying settlement prices, i.e., the design,
should include a specific design not just for when things work, but also when
there are issues, i.e., corrections need to be made.
3.3) As part of the deal design, you need to indicate the
publisher (a.k.a., ‘reference source’) as there can be multiple publishers for
the same ‘price index’.
Alternately,
there can be multiple published prices on a given day. For example, for gold
you might have an AM price (morning), a PM price (afternoon) or a price that is
the average of the two. i.e., it is not
enough to specify the ‘price index’ for the trade, you also need to specify,
i.e., upon trade entry, the reference source.
And then use that combination for when the system is looking up the
correct price, along with the pricing date (‘reset date’) and the contract
month (expiration date or first of month date) where applicable.
Introduction to
CTRM
Click on this
link for a great introduction to CTRM software: Introduction to CTRM Software