|
|
|
|
Main
Page by Topic |
||
|
C. Statistics |
||
Interbook Trades, Passthroughs and Allocations
Some thoughts and considerations on the topic of Interbook Trades, Passthroughs
and Allocations.
Outline
1) Interbooks
– Definition
2) Interbooks
– Design Considerations for CTRM
3) Passthroughs – Definition
4) Passthroughs – Design Considerations for CTRM
5) Allocations
– Definition
6) Allocations
– Design Considerations for CTRM
1) Interbooks – Definition
This means a
trade with another group at the firm. You
could say, between two internal parties.
For example,
suppose you have these two internal units:
NY Trading
Desk
Central
Funding Desk
You might
enter into the system a trade that is, for example, an interest rate
derivative. However, instead of entering
it between an internal party, e.g., ‘NY Trading Desk’ and an external party,
like one of the banks, you enter the trade between the NY Trading Desk and the
Central Funding Desk, both internal parties.
We can assume
that the Central Funding Desk would then trade externally so as to reduce the
market risk for real. Otherwise, you are
just, in effect, transferring the risk from one group within the firm to
another.
The Central
Funding Desk might be aggregating the trades for risk purposes from multiple
internal trading desks, e.g., for interest rate risk or for FX (foreign
exchange) risk, so the trades that are done externally won’t necessarily be one
to one with the interbook trades.
In addition to
trading between two internal parties (‘business units’),
it is also considered an interbook if you trade for
the same internal party between two ‘portfolios’ (a.k.a., ‘trade book’ or
‘strategy’). This has the effect of
moving risk… and PnL (profit/loss) around and there are various reasons why a
firm would want to do that.
2) Interbooks – Design Considerations for
CTRM
2.1) First decision. I
mean in terms of software design. Do you
want to model this as two separate trades?
Or as one ‘interbook’.
2.1.1) If two trades:
2.1.1.1) This can make reporting easier, especially if you are using
a relational database, i.e., each ‘side’ of the interbook
has the full data in its tables.
2.1.1.2) This would take up more space in the database, relative to
booking as just one trade, though that would typically not be a concern.
2.1.1.3) For various calculations, you would need to calculate them
twice. That could in some cases lead to
performance issues, i.e., doubling the runtime.
2.1.1.4) Since you have doubled up the data, need a good way to keep
both ‘sides’ in sync. E.g., amend one
and the other would need to be automatically updated.
2.1.1.5) On
the other hand, there will likely be fields that the users will not want to
keep in sync. So need a good way to
support this/manage this.
2.1.1.6) And a
variation on that, need a way to specify to flip or reverse custom fields, so
that the ‘our’ for one deal of the pair becomes the ‘their’ on the other side.
2.1.2) If you model this as one trade:
2.1.2.1) That could make the reporting harder in a SQL environment,
i.e., with relational database tables.
If you have instead saved the trade as a ‘blob’ or serialized object,
then when you do a load, which could only be done via a custom API, then you
can automatically convert it to be ‘two trades’.
2.1.2.2) This approach could potentially allow for quicker
performance. E.g., for any risk numbers,
you would calculate them once, which is the time
intensive part, and then just reverse them (multiply by -1) for the other side
of the interbook.
2.2) If it is a physical trade, do you want to allow for the
scheduling (physical logistics) on each side to be different? Or to stay in sync?
2.3) For
amending the trades, e.g., if you entered in a January to March trade and meant
to enter in a January to May trade, will you allow users to edit any one trade
of the pair? Or will one be considered
the ‘master’, so that you can edit only that one trade.
2.4) There
should be, of course, a linkage in the system, and you should, for example, be
able to see that a trade is an interbook and the
trade number of the offsetting trade, right from the trade entry/viewing GUI.
2.5) Suppose you have an interbook
trade that is a trade between a New York and a London trading desk, i.e.,
within the same firm. You might run a
London end-of-day using London settle prices, e.g.,
1pm New York time. And then a separate
end-of-day for New York using New York time settle
prices, e.g., at 6pm New York time.
Since the
prices could be different, e.g., especially the interest rates and FX rates
used in valuing (calculating the MTM), then each side of the interbook pair could have a different MTM value, assuming
you just have the one end-of-day run for each trade. That would look off, since overall the firm
should be flat (net MTM is zero) for your interbook
trades, but instead it will show a non-zero value. There would be ‘noise’ in the daily PnL.
One solution
would be to include all trades in the New York end of day run, and make those
the official numbers. You might need
some sort of reporting to indicate the difference between the MTM for the
London deal based on the London closing price and the New York closing price.
3) Passthroughs
– Definition
A ‘Passthrough’ or sometimes written as ‘Passthru’
is like an interbook, except that an interbook would have two trades, a buy and an opposite
sell, a passthrough would have exactly three trades.
3.1) An internal trade that is a ‘Buy’. Like one half of an interbook.
3.2) An internal trade that is a ‘Sell’. Like the other half of an interbook.
3.3) A trade that is between an internal trading desk, one of the
desks from the first two trades, versus an external party.
So the idea is
that one trading desk in a firm, e.g., the international desk, does the
external trade, i.e., with a traditional counterparty, and then there is an
internal trade for the firm, e.g., between the international and a domestic
trading desk.
4) Passthroughs
– Design Considerations for CTRM
4.1) As with Interbooks, users should be able to enter in one
single trade and the other, linked trades, 2 in this case, would be created
automatically. i.e.,
assuming that you are modelling passthrough trades as
three separate trades.
4.2) All trades need to be kept in sync. E.g., if the original trade was amended, e.g.,
to correct the end date of the trade, the end dates on the other two trade should change.
i.e., the trades should be linked in some way that allows for the system
to know they are connected and to make changes as needed.
4.3) As with
Interbooks, design question as to whether or not you’ll allow users to edit any
of the 3 trades, or just one of them that you’ll consider the ‘master’ from the
point of view of modelling a passthrough trade.
5) Allocations – Definition
The term
‘Allocations’ is used here to indicate the combination of:
a) An external
trade, typically used for hedging. ‘External’ meaning between the firm and a counterparty or exchange. E.g., an example would be a buy of 100
December future contracts for a certain commodity.
We’ll say the
internal party (a.k.a., business unit) for this trade is ‘Hedge Desk’
b) and then a number of allocations to various internal trading
desks (business units), such that the total volume of the external trade is
fully allocated. i.e., the hedge desk is
trading on behalf of the business units.
They submit
their hedging requirements by commodity and by month and the
hedge desk consolidated them and nets them. E.g., Business Unit #1 might want to buy 40
December future contracts and other business unit, #2, might want to sell 30
lots. So the hedge desk would buy on the
exchange just the net of 10.
As an example,
let’s say 6 business units want to buy futures as shown:
BU1: 10 lots
BU2: 20 lots
BU3: 20 lots
BU4: 20 lots
BU5: 25 lots
BU6: 5 lots
Then the Hedge
Desk would buy 100 on the exchange, e.g., NYMEX, and then the allocations would
look like this:
Hedge Desk -10
& BU1 +10
Hedge Desk -20
& BU1 +20
Hedge Desk -20
& BU1 +20
Hedge Desk -20
& BU1 +20
Hedge Desk -20
& BU1 +20
Hedge Desk -25
& BU1 +25
Hedge Desk -5
& BU1 +5
I.e., after
the allocations, the hedge desk would be flat.
Buy 100 and then allocate out (sell) 100. And each of the business units would be long
their appropriate amount.
Again, only
the hedge desk did a real trade, meaning external. The business units only ‘traded’ with the
company’s internal hedging desk.
The
expectation is that the Interbooks would be done at the same price as the
original trade, which means the PnL in the hedge desk would be zero. Alternately, the hedge desk might put some
adder, e.g., a few cents per unit, so that the business units are paying
slightly more to the hedge desk than the hedge desk pays externally. The idea is that this small adder helps pay
for the cost of the hedging program at the firm.
6) Allocations – Design Considerations for
CTRM
6.1) With an inefficient design, which may be somewhat common
with legacy vendor CTRM systems, each allocation would be booked as an interbook trade. Which generates two trade numbers. For the example above, that is 12 new trades
for the allocations to the 6 business unites plus the one original external
trade, which is 13 trades in total.
That is pretty
inefficient. A better approach would be
to have the one original trade and then have some way to mark how much volume
or percentage to allocation and to whom.
And store just that information instead of so many extra trades. A good design can still make it look as if
things were modeled as so many trade, e.g., by
generating trade numbers for the allocations, even though the full details of
each allocation aren’t also saved.
6.2) another
thing to keep in mind is the need to keep any duplicated information in
sync. For example, the
trade price. E.g., if the
original trade price was $51 per BBL, and the original trade was entered in
incorrectly at $52 and then 12 allocation trades were added, if the system is
designed to save the full trade details for each allocation, then you have to
update all 13 prices.
However, if you
just stored the allocated volume and the from/to business units, then when you
correct the trade price on the original trade, then there is nothing else to do
and/or reconcile.
Here is
another example of where an allocations design would be applicable. i.e., a case where you’ll store just the
volumes or percentages allocated instead of creating multiple trades that need
to be reconciled and kept in sync:
If you have a natural gas marketing desk.
They might sell natural gas at an all in price
of $3/MMBTU to a client. And then interbook… or allocate out the individual risk components
to other desks within the firm who are responsible for managing a certain type
of risk. E.g., the NYMEX natural gas
component of the trade would go to one desk, the basis component (perhaps
prices off IF – Inside FERC), to another desk and the Gas Daily price risk to a
third desk.
Introduction to
CTRM
Click on this
link for a great introduction to CTRM software: Introduction to CTRM Software