About Us

PnL Explained Professionals FAQ

Site Map



Contact Us


Main Page by Topic

A. PnL Explained

B. CTRM Software

C. Statistics



Interbook Trades, Passthroughs and Allocations

Some thoughts and considerations on the topic of Interbook Trades, Passthroughs and Allocations.



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: 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. This would take up more space in the database, relative to booking as just one trade, though that would typically not be a concern. For various calculations, you would need to calculate them twice.  That could in some cases lead to performance issues, i.e., doubling the runtime. 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. 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. 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: 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’. 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




Site Map

Contact Us