Systems building - execution

People often get systematic and automated trading mixed up. The latter is a subset of the first. You can't have a system which is fully automated if it relies on discretionary input, no matter how small. But you can have a system which needs a human to make it run, even though there is no discretion, and its fully systematic.

The main area where humans are often used with systematic trading is in execution. It's relatively common for people to create software that analyses prices and produces a trade, which the person then has to execute.

(At the large hedge fund I used to work for, we used a mixture of automated execution algos, and real people to execute trades. FWIW the best humans were better than the best algos, on certain kinds of markets)

This post isn't for you. It's only for those who want to automate their execution as well, and avoid the stress of actually trading.

If you don't want to be like this guy, then read the rest of this post.

This is the fourth post in a series giving pointers on the nuts and bolts of building systematic trading systems. You may also want to look at my post on building a simple execution algo, which I'll refer to occasionally here.

Event driven versus Sample driven

As I've discussed before in this series there are two ways of running a trading system. The first method is event driven; you wait for something to happen (price hitting a particular level, or the next tick arriving) and then you take the appropriate action (buying or selling, or cancelling an existing order perhaps).

The second method, which I use, is sample driven (and there is no agreed nomenclature here, so you may hear it called other things). Here we periodically check / 'sample' the data we are interested in (eg prices), calculate what we want our optimal position to be, and then trade to achieve it.

The former system is most suited to high frequency trading, and to relatively simple algorithims (if you have to spend a minute analysing the tick event, then you lose any benefit from running an event driven system). It doesn't work as well with, for example, trading relative value systems.

Anyway this isn't the place to get into a debate about which is better. For my application (relatively slow trading) sample driven trading is more natural. There are also advantages in that debugging is easier, and code can be simpler.

Much of this post will be relevant to event driven systems, but those running sample systems will get more out of it.

Key principles

There are a number of factors, some mutually exclusive, to consider when designing a system to do execution. In particular there is a potential conflict between robustness and speed. To be precise, if I'm in a situation where the system might do something potentially dangerous such as an incorrect trade, I would rather delay the trade until the situation can be resolved; even if the delay could be several days.

Because I want a fully automated system, that literally should be able to run for months without being touched or watched (rolls apart), this robustness is incredibly important.

The optimal position

To be clear then before the part of my program that does execution comes into the picture something else has created a theoretically optimal position, which was true at some point in time, and with some data (in practice then, for my simple technical system, at some price).


I'll talk more in a later post about whether this is a separate process, or all one big happy function, and how separate processes 'talk' to each other.

Essentially then the job of the execution component of my system is to compare the optimal position with the current position; and if they are out of line, try and do a trade that brings the actual position back to what we want it to be.

If you want more detail on what I mean by 'out of line' you'll have to read my forthcoming book, www.systematictrading.org, chapter 11.

What can go wrong

This all sounds very simple, but in fact there are a number of things that can go wrong:

• Optimal position is  unavailable
• The price on which the optimal is predicated is out of date
• We don't know what our current position is
• Our current position is out of date, as we've recently done a trade that will change it
• We're running two processes and they will both issue the same order, ending up with the position 'overshooting' the optimal
• The market is closed
• The market isn't liquid enough to do the adjusting trade required
• We might, for some reason, not want to do the adjusting trade

Writing exhaustive lists of 'what can go wrong' like this is vital before you write a robust process. We need to make sure all our processes deal with these issues. Also my bias towards purely automated systems that run themselves, on which a delay in trading can be shrugged off, influences how these problems are solved.

Getting the current position: Storage and lining up

I won't discuss where the optimal position is stored, as this will be the subject of a future post. Just for now imagine there is a database table populated with it (as indeed is the case in my own system). However just to note that if we can't read the optimal position then we probably have a fairly broken database (or perhaps a file lock), and we shouldn't try and do any trading.

There are two main places you can store your current position:

• Your own database
• Your brokers database

In the latter case you'd need to use the brokers API to get positions. Note that unfortunately neithier of these methods is 100% reliable*. I've had issues the IB API** giving me the wrong position (usually eithier missing one instrument entirely, or doubling up on the real position). I've also had issues with fills arriving which I've missed, thus making my own database estimate of the current position wrong.

* The NASA way of avoiding conflicts of this kind would be to have three sources of current position and institute some kind of voting algorithm. Sadly I can't think of a further, independent, source of position.

** References to my broker IB (Interactive Brokers), can clearly refer to other brokers as well.

The solution I use is to make my database the primary source of current position. I then crosscheck this 3 times a day with the position the broker thinks I have. If there is a difference of opinion between me and the broker then I change the trading state to STOP (see more below about different states). Genuine differences of opinion are rare, and more often than not caused by a position cash settling or being forced to close by IB when for some reason I haven't closed it myself before expiry (discussed more here).

I also avoid creating new orders when I think, or know, I have an existing order (of which more below).

Lessons from the database managers

Let's take a few of those problems I outlined above and rephrase them slightly:

• Our current record is out of date, as we've recently done a transaction that will change it
• We're running two processes and they will both issue the same transaction, ending up with the record being incorrect.

These problems then are exactly those faced by people who create database systems. The solution that they, and anyone involved in worrying about files being updated by multiple users / processes, is locking.

If I google (images) 'database' this is the first thing that comes up. It would be much cooler if databases actually came with holograms of pieces of paper flying in and out of your server.

I use locking in the following way. Locks are applied at an instrument level (eg to the whole of the Gold future, regardless of which contract we're trading). The normal status of an instrument is unlocked. This means we can issue a new order related to that instrument. Once an order is issued however the instrument becomes locked.

In a locked status no new orders can be issued for an instrument. Because I am super paranoid I'll also check with the IB API that there are no outstanding orders; even if the instrument is unlocked if the API reports the existence of an outstanding order (which shouldn't happen... but...) means I can't do any more.

The lock will only be removed once the order is completely filled and the current position updated to reflect that, or the order is cancelled by my software (of which more later). Because I can miss fills, and because of other gremlins, I have a periodic (hourly) process which checks to see if there are any instruments that are locked, but with no outstanding orders reported by the IB API. If there are, then they are automatically unlocked.

This may seem like paranoia. Why not just check for oustanding orders from the IB API, and don't trade if they exist? Because there is a tiny period of time where IB will say 'yeah, no outstanding orders' but the relevant fill hasn't yet arrived (or the fill may be missed somehow) and my current position hasn't been updated, meaning I might try and issue the same trade again. By periodically removing locks that apparently aren't needed I do open myself up to this happening, but it's much less likely than if I used the presence of IB outstanding orders as my only check to see if it is safe to trade.

Enemy of the state

I won't always want to trade an instrument, or do certain types of trade. For this reason I have a number of trading states which an instrument can be in:

• OK - allow all kinds of trades
• NOOPEN - do not open any new trades, but allow any existing orders to continue.
• NOINCREASE - do not do any trades that will increase our position, but allow closing trades. I use this a lot; for example when I recently wanted to get out of my German 2 year bond position.
• NOCLOSE - do not do any trades that will reduce our position. It's hard to think of a situation where this would make sense, but I hate asymmetry.
• STOP - do not open any new trades, and cancel any existing orders. Once existing orders are cancelled, this migrates to 'NOOPEN'
• CLOSE - immediately try and issue a trade to close the entire position (but which will respect trading limits; see below).

Locks and states are different; locks are applied and can be removed by software. The state can be changed by software (such as when opinions on current positions vary); but can only be reset to 'ok' by human hands.

Rolling rolling rolling...

Applicable to future traders only (or spread bets, options... others where positions can't be held indefinitely and need to be 'rolled over' to the next maturity). You should have already read my post on the mechanics of rolling. Suffice to say that we can be:

• Not rolling, in which case we'll buy and sell the current contract
• Passively rolling, when we'll issue reducing orders in the current contract, and increasing orders in the new one
• Actively rolling with a spread trade, when we'll issue a single order to (if long) sell the current contract and buy the new one
• Actively rolling with an individual leg trade, when we'll issue two orders to close the current contract, and open a position in the new one

The important point here is that the code first needs to identify the roll state, work out which combination of orders makes sense, and then needs to have the logic to issue one or two orders in the current and/or new contract; or a spread order.

Open all hours

There is no point trying to trade if nobody wants to trade with you. There are five reasons I can think of why you might not be able to trade:

• The market is closed today (a regular closure, depending on the day)
• The market isn't open right now (a regular closure, depending on the hour).
• The market is unexpectedly closed.
• There isn't enough liquidity in the market to trade
• You have been banned from the market, or blown up and lost all your money; or upset your broker.

Don't copy this guy if you don't want to be banned from the market

Leaving aside the last point; for the first two points we can of course download and create tables storing market holidays and market opening times. Beware this is a lot of work; and you need to then waste your life worrying about daylight savings changes. This doesn't deal with point three of course. 

For point four you're going to have to check the liquidity before you trade. I'll discuss below exactly what a liquidity check might involve.

I pretty much choose the laziest possible option; which is to treat the first four points all in the same way as a lack of liquidity. What I do in practice then is have a table of when I know markets should be open and liquid(ish). During the times specified in that table if I feel the need to trade I will periodically check to see if that market is liquid. If it is, then I go ahead and trade (if trading is needed). If not, then I don't. Not liquid could mean the market is on holiday today, or has closed early for some reason, or it might just not be liquid.

Note that if I was even lazier, and just checked all markets 'all'* the time, then I'd be frequently checking a lot of closed markets which is a waste of processing power and bandwidth.

* My execution process runs from 10pm to 8pm the next day, local UK time. It is kicked off Sunday evening, Monday evening .... Thursday evening. The two hours of down time is used to run reports and create backups.

Liquid liquid everywhere and not a drop to drink

I said above we need to check for liquidity. There are many ways to measure liquidity of course. In my simple world, where I only have level 1 data (and L2 in any case could be corrupted by spoofers), I use the following simple test:

• Is the inside bid-ask spread in the market smaller than X (where X is some value I've set for each market, which depends on how I'm executing the order)?
• Is the size available at the bid and ask larger than the trade I want to do?

Note that if the market is closed then the values for bid-ask spread and size will be NAN and NAN respectively, so by definition there isn't enough liquidity.

I'll discuss in a second how the method of execution affects the required maximum spread. Just to note that if the size available is smaller than the trade I want to do (but is bigger than zero), and I want to do more than one contract, the execution code will reduce the size of the trade so its possible given the available size.

There is a further check I will do at this stage. Remember from above the theoretically optimal position, which was true at some point in time, and with ... some price. So I need to have a concept of staleness, and a concept of maximum price movement.

To put it another way, given the speed of my system, I would be concerned if I'd calculated my optimal position based on a price from more than a hour ago. By the way this will happen if you're running seperate optimal position calculation and trading processes as I am; and the latter kicks off in the morning before the former has had a chance to update the price. It won't happen if you have a single pipeline process 'collect price -> calculate optimal position -> create order', or if you're using event driven systems. Again this kind of stuff will be the subject of another post.

Secondly I'd be concerned if the price had moved since I checked it. If for example a market had moved more than 4 daily standard deviations in price in the hour or less since I last grabbed a price, then it's quite likely my optimal position is out of date, and I will want to recalculate it before trading. Otherwise the risk is I might buy based on the old price, and then quickly sell again, once a new price has percolated through the system.

The messy business of actually executing

When you actually execute you can:

• Issue a market order, that will most probably cross the spread
• Use your own algo, as I do (much, much more is here).
• Use a brokers algo. IB have a good set of algos for equities, fewer for futures.
• Use a third party algo. Unfortunately the good ones are only available to institutional traders. I can recommend QB for interest rate products.

I will usually use my own algo, although for manual trades (see later) I give myself the option of using a market order. Eventually I'd expect to have a suite of algos for different instruments; so I have the ability to do this ready in my database, although I don't yet use it. Algo evaluation is a science; just like evaluating other trading systems it has very noisy data and again only large institutions can realistically collect enough data to make meaningful comparisions (and possibly not even then).

As I alluded to above I have different liquidity requirements depending on whether I am issuing a market order or using my algo. If I'm issuing a market order I want the spread to be tight (normally a single tick, or whatever the minimum increment is, unless the market normally trades a little wider), since I know for sure I'll be paying half of it. If I'm using my algo I am less choosy; a much larger spread might mean I capture more of it when I submit my initial lot at the bid (if I'm buying) or offer (selling). This is true to a point - very large spreads mean the market is probably dangerously thin and I wouldn't try and issue an order.

Safety first

The scariest thing about fully automated trading is the doomsday scenario; what if this thing just goes bad and trades like crazy?

What my automated system might say if I tried to stop it trading. Although, just to be clear, my name isn't Dave.

Although I've been ultra careful there is still an outside chance something could go wrong. To avoid this I use daily, and 'lifetime' trade limits.

So before I actually issue an order the software will check to see how many contracts I'd done today already, and whether I will break that cumulative limit. If so it will reduce the trade (sometimes down to zero). I also have 'lifetime' limits. In practice if I'm going on holiday I will set the lifetime limits to a reasonably large level of trading I'd expect to do over that period (clearly less than N x daily limit, where N is the number of days I'm away, otherwise they won't bind), and then when I get back I'll reset them to large numbers.

Limits are set by looking at values in my backtest, and so are contract dependent.

In my current setup active roll trades (as spreads or legs) are exempt from trade limits, although once done they count towards the limit (often meaning you can't do any more trading that day after a roll). It would probably be better to count rolls seperately towards another, larger, limit. That is on my, very long, to-do list.

Note that IB API also has limits, but they are not instrument dependent. Unless you're trading only stocks, or  just one future, this makes them pretty useless. So I turn them off.

Correcting mistakes

Stuff happens. And when it happens you need to fix the mess it creates.

The first kind of stuff, which I've already mentioned, is where my position and the IB API position get out of line. Normally what has happened here is that I issued an order which was filled, and I missed seeing the fill; or IB closed out or settled a position which I hadn't got around to rolling in time.

To deal with this my software has the ability to do a manual fill or a balancing order. The former is where I update an existing, unfilled, order in my database to include the fill that actually happened. The latter is where I create an entirely new order in the database to reflect the trade that happened. After I've done this I should be in a situation where my, and my brokers, record of position are perfectly matched.

The other kind of stuff is sometimes I might want to trade outside of the normal execution process. For example suppose I have a contract I have to roll today. I've tried passive rolling, issuing spread orders, and even individual leg orders. None of these have filled, so what I will do is issue a manual trade from the command line, and then manually override the normal execution method to do a market order. Unlike a manual fill or a balancing order a manual trade will be sent to IB for execution, as well as going in the database.

Done

Hurray. Instead of being tied to your computer, following its robotic commands to execute trades, you can now do something else instead.

In the next post I'll look at working out how much lovely moolah you're making.

This is the fourth post in a series on building systematic trading systems.

The first three posts are:

http://qoppac.blogspot.co.uk/2015/04/system-building-data-capture.html
http://qoppac.blogspot.co.uk/2015/05/systems-building-futures-rolling.html
http://qoppac.blogspot.co.uk/2015/06/systems-building-deciding-positions.html

The next post is here:

http://qoppac.blogspot.co.uk/2015/08/systems-building-accounting.html

Equilibrium asset pricing models - a quickie (a bit technical)

In my usual daily trawl through FT Alphaville's further reading (worth looking at, registration required but free - it isn't behind the FT's paywall) I came across this little gem.

It's worth reading the full article, but I'd just like to quote a couple of parts:

"Actually I think there has been historically quite a lot of interest in models based on macro factors that would lend themselves relatively naturally to interpretation in terms of equilibrium valuation models. The problem is that they don't tend to work very well empirically... those models just didn't do a good job of explaining a substantial fraction of asset returns... Plus they usually seem to have unobservable or hard-to-observe components. For example, any model of interest rates is going to have to have some place for a market price of interest rate risk.... Even a small error in that estimate is going to produce a huge discrepancy to observed yields."

To be clear we're talking about models of the form P = f (a,b,c....) where P is the 'correct' asset price, and a,b,c are factors like for example the market price of interest rate risk and other such. To make these models work you also need to know the factor loadings; if the model was linear these loadings would just be the coefficients on the various factors in a pricing equation.

If this sounds like mumbo jumbo, bear in mind you probably already know about one such model, which is the CAPM (if you don't know what the CAPM is then it's still going to sound like mumbo jumbo and this post probably isn't for you). In the CAPM the factor is the market return and the loadings is the much maligned beta (covariance with the market). The CAPM equation is specified in excess returns rather than expected values, but it's easy to switch between the two when we note that the correct value is equal to todays price plus the expected return. If we add in the expected speed of reversion to the correct value then we can make the two approaches equivalent.

Now I've spent a fair bit of my own time in the past messing around with these models, and I have a few thoughts and ideas to share. To make this post more tractable I'll refer to a specific examples: where we are trying to estimate the equity risk premium.

Choice of factor

There is an unfortunate habit in the literature of these models to choose factors which have nice economic meaning, regardless of whether they are observable. So for example in the equity risk premium world it usually makes more sense to use expected real interest rates. However it's difficult to get inflation expectations for some long horizon. In some countries you can use inflation linked securities, but biases mean it's not easy to extract inflation expectations from them. Survey measures are better, but will rarely go back  (for a longer and better discussion of this see Expected Returns).

It's tempting to fall back on creating your own model to forecast inflation. A reasonable model would include an equilibrium (based on a moving average of inflation), a rate of change (recent changes in inflation) and survey and asset price measures if available. Note however we've just exploded the number of coefficients we have to estimate. Also if the model is to forecast a long time in the future (say 20 years) it's going to consume a lot of data history, and waste the last two decades worth.

An unpleasant class of models is where the loadings are specified, and you find the factors. This is done in parts of the bond pricing literature. One of the few nice things about the macro factor models is that the factors have some kind of meaning. But rather than have intuitive interest rate factors like the level of rates, and the steepness of the curve, we have a factor which is based on a weird function of forward rates.

Reversion to equilibrium

An obvious point is that these models are no good if they don't get the equilibrium value correct. As the quote notes a slight difference in the equilibrium can make a big difference. For example the equilibrium PE ratio of stocks (which we can extract from the equity risk premium) under one model might be 20, and with slightly different assumptions it might be 15. Give the normal range of stock PE ratios this will make a huge difference to performance.

source: investopedia

The opposition - kitchen sink

You can think of a macro factor model as a big bunch of variables in a regression; on some of which the coefficients or relative coefficients are specified (like the current real interest rate is the nominal interest rate minus current inflation); and others (the loadings) which we have to estimate.

Given all the caveats above you might conclude the best approach is to just throw all the observable factors you have into a giant kitchen sink regression and let them fight it out. So rather than trying to cobble together an inflation forecasting mini model as above, you just chuck the underlying observable variables into the regression with everything else.

But the big advantage of having some pre-existing structure in your data is it reduces the degrees of freedom, and if you are right about the structure will give you a more robust model.

(You could also take a Bayesian view that you think your imposed structure is correct, unless proven statistically false).

The opposition - simple mean reversion

There is an even simpler method, which is to do a simple mean reversion model on one or more valuation factors. So in stocks you would just take the history of PE ratios, and then take some kind of slow moving average to measure the equilibrium. If the PE dips below that equilibrium then you buy; otherwise you sell.

Mild improvements can be made to this by incorporating more sensible variables, as is done in the CAPE model with real earnings, as long as you don't put yourself into a position when you have to start estimating coefficients again.

Mean reversion isn't, usually, strong enough

These macro models should have an advantage over a kitchen sink approach where the same kind and number of underlying variables are regressed without any structure being imposed. However they're unlikely to beat a relatively simple mean reverting model. Worst still all such mean reverting models only perform well at relatively slow time scales, useless to any active investor.

If for example you are forecasting at a horizon of a few months, and you add a 'momentum' factor to your model, you'll find it dominates all your other predictive variables.

What kind of valuation model works at sensible time scales?* No, not a macro model but a micro, relative value, model with asset specific factors in it. In this case we don't need to worry if the equilibrium is correct or not; it's implicit in the fact that we have no net exposure, only relative value bets.

* though having said that relative momentum is also important in these kinds of models.

Good at telling you where you are... not where you're going

I have similar feelings about these kinds of models as I do about "big data" (bear with me). Big data, it strikes me, is very good at modelling the current behaviour of for example spending by loyalty card shoppers*. Each of those shoppers is relatively similar (they all go to the same supermarket for a start), and importantly they are not interacting with each other, nor do their shopping habits change much when for example the US non farm release comes out. Unless their behaviour changes radically, which it tends not to, we can make some reasonable predictions about how they will behave.

However big data and market forecasting is more difficult. The prices are a result of a large number of relatively heterogenous participants interacting, and reacting to exogenous news and shocks, in a way that supermarket shoppers hardly do. At best you can overfit to the extreme and tell some interesting stories. Just don't try using it to trade.

Similarly well specified macro models can tell you some very interesting stories about the past. So it's possible to disaggregate the equity risk premium (without incidentally needing to estimate any coefficients), and conclude that much of the excess return of equities in the last 40 years is due to a secular fall in inflation.

The only useful prediction I can make out of that is that equity returns are likely to be lower in the future. That's useful, but it barely qualifies as a forecast and its no use whatsoever for any kind of dynamic trading.

 

Conclusion

It's fun playing with macro models, and they're intellectually interesting, but they have no place in the armory of any investor or trader.

The death of global variables

I've updated the code on github used for the series of posts on using swigibpy with python to talk to the interactive brokers API, of which this is the first.

Key changes:

• Global variables are no longer used. They make the code very hard to debug and are considered a generally bad thing. Instead I pass data between the client and server using the callback instance. I never liked using globals, but when I originally started looking at this stuff I didn't have the confidence to start messing with the IBWrapper class. Plus they worked. But now they are dead.
• While loops are now clearer and more consistent with their treatment of error, finished and time out conditions.
• The code is now more careful about honoring the use of request ID's, and storing data for different ID's in different places. Although this wasn't necessary for the simple example it's probably safer if people are copying and pasting the code without understanding the potential dangers.
• Specific error messages are passed upstream from the server wrapper in case you'd like to handle them yourself.
• I've made some simplifications; removing the bar data from the third example, and combining the separate client functions for portfolio and account data in the final example.
• The handling of fills versus a request for execution is done more robustly in the 4th example.

The blog posts have been updated to reflect the new code.  If you're playing with this stuff it might be worth having a look at the new version, or even downloading it from scratch.

Enjoy

A tale of two positions

Mostly running a systematic trading strategy is dull. Occasionally however something interesting happens. Here is a tale of two positions. One went well, the other badly. Examining these will also allow you to see 'under the hood' of my trading strategy, which you might find interesting. Also it illustrates the kind of diagnostics you need to have available on a systematic system (though there will be a longer post on this in my continuing series).

The last few weeks in the Agricultural markets have seen a pretty wild ride.
I found this headline interesting "Commodities jump most since february as corn, soybeans rally". I found it interesting not because I'm interested in weather reports from the US Mid-West, but because I am long soybeans, and short corn. Sure enough when I looked at my p&l for the last couple of weeks it was dominated by a large profit in soy; and a big loss in Corn.

But that is jumping ahead. Let's start by looking at why I had these positions on.

The setup

The picture for the first half of this year has been a gradual slide in Ags prices. Corn for example was down around 14%:

Soya wasn't much better, down around 10%.

What kind of positions did I have on, any why? Well I was short Corn:


Some explanation is needed. The top left is the 'signal'. This is in units that are risk adjusted, so they are comparable across different assets. Clearly I was short, and had been getting shorter all year. The top right and the bottom left show how the position is adjusted for the volatility of the asset price, and how much capital I am employing, respctively. In the bottom right is my position, or at least what it would have been if I could hold fractional contracts.
 
As for Soya:
Again I was short, although on a risk adjusted basis my position was only 2/3 of what it was in corn.

We can dig a little deeper. Here is the underlying signal breakdown by trading style for corn:

 

I have a short position on for 'trend' (which makes sense with the falling price'), and also because of 'carry'. And the same for soybeans:

Here the 'carry' signal is almost flat; and the 'trend' signal has started to fade. 'Carry' in this case just means that the market is in local contango. The contract I am trading is more expensive than a contract that has a nearer expiry. If the shape of the futures price curve is unchanged, the price of the contract I have should fall.

Let's see this in corn. I am trading the Z15 (December 2015) contract. The price of this is shown in the following plot as a green line (for the colour blind, the higher line).

I want to compare this to a nearer contract, U15 (September 2015) which is the blue, lower, line. If the shape of the forward curve remains unchanged I'll make money by being short Z15, as the price drifts down to U15. Here for Corn there is quite a big gap, hence the strong short carry signal.

Now for soya:

Here the green line that I am trading is X15 (November 2015), and the blue line for comparison again is U15. These two lines are almost on top of each other, but on average blue is above green - the reverse of what we see here. So there is a very slightly backwardation in soyabeans; which implies we should go long.

The rally

So we already know what happened next - prices went up. Here's corn:

20% in a couple of weeks is pretty good. Soya also saw a decent push:

  

As trend followers we don't try and forecast turning points, but we do react to them after they've happened. Here is how my system reacted for Corn. In the top left we can see the short signal compressing; falling by perhaps 3/4. The risk on the contract also increased (top right). The position then fell - these are the buys I did (columns are my ticket id, contract month, trade date and time, trade size, and price).

4087 CORN 201512 2015-06-11 14:30:00 1 373.000000
4291 CORN 201512 2015-06-24 14:30:00 1 378.750000
4303 CORN 201512 2015-06-25 18:11:08 1 391.250000
4354 CORN 201512 2015-06-30 17:18:26 1 412.750000
4390 CORN 201512 2015-07-02 14:30:00 1 430.000000

 

Above is the same picture for Soya. The signal moved from negative to positive - we've gone long.

4168 SOYBEAN 201511 2015-06-16 18:15:58 1 922.500000
4228 SOYBEAN 201511 2015-06-18 12:05:40 1 935.750000
4234 SOYBEAN 201511 2015-06-18 16:36:39 1 940.250000
4267 SOYBEAN 201511 2015-06-22 14:30:00 1 947.250000
4294 SOYBEAN 201511 2015-06-24 15:22:48 1 961.750000
4315 SOYBEAN 201511 2015-06-29 12:15:04 1 985.250000
4375 SOYBEAN 201511 2015-07-02 12:03:36 -1 1029.750000

Notice the last sell. This is because in the last few days of the plot the risk (top right) was jumping faster than the signal (upper left) was increasing. The former causes the position to fall, and the latter to increase it; net net I reduced my position slightly.

We can get some more illumination by looking at the signal breakdown. Here's corn:

 

And soya:

 Now carry hasn't moved very much; it's still quite short for Corn, and a little positive for Soya. However look closely at the 'trend' lines. For corn the trend signal goes from -0.07 to about zero. For soya it goes from -0.8 to +0.6. It's moved about twice as fast for roughly the same size of move. What's going on here?

Well we can breakdown the trend signal even further. Here is corn:

(Note: this is a simplification. I have four 'trend' subsystems, and we are seeing a break down here of just one 'momentum'. However it is representative of what was going on across the other subsystems)

 And soya:


The numbers indicate how quick the various trend following signals are. So 'momentum2' is a very fast system, which as you can see neithier instrument is using (flat lines in the plot). 'momentum 64' is a very slow one.

(If you are interested each is an exponentially weighted moving average crossover with spans N and 4N)

Notice that corn only has three systems - all slow- 16, 32 and 64. Whereas soya has five; and much of it's change in signal is coming from the fastest two - 4 and 8. That is why I react so much quicker to the price move in soya than in corn.

The next obvious question is why the heck do I have such different setups for the two instruments? The answer comes to to one simple thing - costs. Corn is simply too expensive to trade as quickly as Soya.

Both corn and soya have contract sizes of $50 per point, and have spreads of about 1/4 point wide; which implies that to trade I'd expect conservatively to pay slippage of 1/8 point; $6.25. On both I pay about $1.15 in exchange fees and commission per contract; so the total cost is around $7.40 per contract. However what matters is not the outright cost but the cost adjusted for risk (see chapter 12 of http://www.systematictrading.org/ for more).

The volatility on corn is about half what it is on soya. So you need a position that is twice as big to get the same risk, which means doubling your costs.

Does this mean that trading corn will always be a money losing proposition? Not necessarily; if for example the current trend reverses at about the same speed it developed then I'd be more heavily whipsawed. However given that I don't know what trends will come up, all things considered it's always going to be better to trade an expensive instrument like Corn more slowly than something like Soybeans.

I would never use two weeks as a basis for judging my trading system. But for fun let's look at the p&l.

This year I've lost about -0.6% of my account value in corn:

But I've made about 1.3% in soya:

So the final lesson here is that diversification pays; had I just got one agricultural commodity in my portfolio; and had that been Corn, I'd be pretty sad right now.

Happy trading.

LOBO's in pictures

You might follow this blog, or you might have come to it via google after watching the Dispatches programme on channel 4 which was broadcast on 6th July, about Lender Option Borrower Option ("LOBO") loans - loans with embedded derivatives made by banks to local authorities. You might want to read my original post on LOBO's or watch the programme if you haven't done so already (or read the press release).

I'm writing this post:

- To give people a more intuitive, pictorial understanding of why LOBO's are a bad thing
- To reiterate and explain in more detail, again with pictures, why the LOBO market didn't appear to be operating fairly for the local authorities and borrowers within it.

I also want to address the following points which were made in rebuttal by both borrowers and lenders during the broadcast, and in subsequent coverage. I've given each of these a catchy label:

Borrower option smugness: "If the lender raises the interest rate, so what? We've got the option to cancel the loan"
Unfair hindsight moan: "It isn't fair to look at these in hindsight"
Initial rate whinge: "These loans were cheaper than normal fixed rates at the time"
Current rate complaint: "These loans are cheaper than the rates we are paying on the rest of our portfolio"
Future hope: "In the long run they will be a good deal"
Portfolio excuse: "They should be looked at in the context of the local authorities overall borrowing portfolio rather than in isolation"

This will be a deliberately back to basics post so you won't need any technical background to understand it. Some, but not all, of it is a retreading with more pictures of my last post. If you didn't read that you don't need to. If you did  (and followed it) you can probably go pretty quickly through the first few pages until I get to the 'portfolio' arguments which is the new content here.

LOBO's in pretty pictures

Fixed and floating

Let's start with the basics. When you take out a mortgage you have two main options - fixed or floating rate. The same option is available to local authorities, who could borrow from the Public Works Loan Board (PWLB) at eithier a long term fixed rate (up to several decades), or a short term rate of just a year (which is as good as floating for the purposes of this discussion). Which is a good idea? Well, it depends on how things work out. 

This graph shows the average interest rate paid by the authority (LA) on the y axis, and on the x axis the average level of interest rates throughout the life of the loan. Here the LA had two options. They could have taken out a fixed rate loan at 5%, in which case they'd pay 5% for the whole period (red). Or they could have taken out a floating rate loan (blue). 

The line 'par', shows the current level of expectations of what average rates will be.

To repeat: what we're seeing here is the average rate paid by the LA. It might be that on the short term loan the initial rate was 3%; and that at the end they ended up paying 7%. However over the whole life of the loan they paid 5%. 

(technical note: I'm glossing over some stuff here about different discounting interest payments over the life of the loan, and the difference between expected forward rates and the evolution of spot; but these don't affect the main point).

It's important to note here that:

a) when the loan was taken out the expectation was that, given the information available at the time, the LA should have been indifferent between the fixed and the floating rate. 

b) With hindsight one loan would have looked better than the other.

Both the fixed and the floating aren't perhaps ideal. Although the fixed gives you certainty; it can look expensive, particularly as normally the initial floating rates are quite low.

Suppose you take out a 50 year fixed rate loan*, but then after a short period of time interest rates fell. The interest rate is now 3%, but you are stuck with 5%. What can you do? 

* Unlike mortgages LOBO's aren't limited to 25 or perhaps 30 years. Terms of 40,50 or even 70 years weren't uncommon.

You could:

- stick with the loan and hope that interest rates rise again

- ask the lender to 'tear up' the contract and repay the money

If you 'tear up' the contract then you have a problem and the lender has a problem. Your problem is that you will need to borrow from someone else to repay the money (assuming you don't have it down the back of the sofa). But that is fine because you can borrow at 3% - less than before.

Your lenders problem is that when you return their money they will only be able to lend it out at 3%. The lender won't let you do this. Most lenders have something called a 'tear up' clause. You will have to pay them the difference between what they would have earned if you'd kept the loan, and what they will earn at the lower lending rate. Rather than pay this every month, you have to pay a lump sum.

What if interest rates rose? Then there is the opposite problem. The lender would happily pay you to tear the contract up.

If we plot the value of these tear up costs depending on what has happened to interest rates we get this kind of plot

The y-axis shows the tear up cost. If you borrow on a fixed basis (red line) and interest rates fall you have to pay more - a bigger negative number. If rates rise then the lender has to pay you (a bigger positive number).

Note with the floating rate the tear up cost is always zero**. If you borrowed on a floating basis, and rates went down to 2%, because you're already paying 2% the lender can turn around and re-lend your money at the same rate.

* technical note: clearly simplified, removing the effect of convexity to make a straight line

** clearly this is a slight simplification because normally an administrative cost would be charged.

What about the lenders tear up costs? You'd expect them to be the reverse of the above; a flat line for floating rates, and a line sloping downwards for fixed rates.

In fact most lenders hedge their exposure so that they aren't unduly exposed to interest rate changes. The lenders tear up cost will be something like a flat, horizontal, line for both the fixed and the floating loans.* I won't bother plotting this.

* again this is a simplification; and most loans would be hedged as part of a portfolio rather than in isolation. It's my understanding that PWLB loans are hedged / funded with UK gilts on a duration matched basis.

Both fixed and floating clearly have advantages and disadvantages. Good advice for people borrowing money (like LA treasury officials) is to mix both fixed and floating; eg ending up with something like this (y axis is average interest rate):

I'll come back to this option in a moment.

Introducing the LOBO

Now let's move on to the 'lender option, borrower option'. We'll first discuss a basic LOBO, and then talk about the 'inverse floater' structure.

In case you missed the programme or my blog posts, the key point about a LOBO is:

- it's a fixed rate loan, at a slightly lower rate than normal
- the lender has the option to periodically increase the rate
- the borrower has the option to accept the increase or to repay the money (with no 'tear up' cost)

We get the following picture:

(again, technically there is a lot of evil path dependence missing in this simple picture which I come back to below)

The initial rate is 4.5%, which is 0.50% lower than the long term fixed rate.

If interest rates fall below the initial 5% 'par' line, then the lender won't exercise their option. The LOBO behaves like a fixed rate, albeit one a little cheaper than the vanilla loan would be. Fixed rates are lousy when interest rates have fallen. Unless you know with perfect hindsight that rates are going to rise it isn't a good idea to finance yourself entirely with fixed rates, or with LOBO's for that matter.

What if rates rise? (This is where we deal with borrower option smugness). If interest rates rise slightly then the lender will probably exercise their option to increase rates, but not to the current level (the green line is still below the blue line). This is because the LOBO is still more valuable than what they could get if they lent the money out again at the current rate; they want to keep you as a borrower.

As a borrower you'd almost certainly not exercise your option to cancel. If you did so you'd have to refinance the loan at the current level of interest rates, which would definitely mean paying more interest right now (eithier at a new higher fixed rate, or at the prevailing floating rate with no protection against further rate rises).

As interest rates rise the lender will keep exercising their option, and keep increasing rates but keeping them below the current interest rate. If you do decide at some point to exercise your option to repay you would end up having to refinance at the current interest rate - you'd jump from the green to the blue line.

The borrower option isn't some kind of panacea in an enviroment when interest rates are rising. At best you'll end up paying a higher rate than the initial LOBO rate (or what you could have got with a normal fixed rate loan). At worst you'll end up paying a lot more.

The lender option means that a LOBO doesn't give you the certainty of payments that a fixed rate loan does; and the inclusion of the borrower option doesn't change this one iota.

The nasty bit you don't see

This chart actually makes the LOBO look much better than it really is. Suppose over the 50 year loan rates are at 5% in year one, then rise to 7% over the next four years, and then after a year drop down to 4% for the rest of the loan period. The average interest rate paid over the 50 years will be 4.3%. What will you be paying on the LOBO?

When rates rise to 7% the bank will probably increase the LOBO rate to perhaps 6.8%. The borrower  probably wouldn't cancel the loan - they'd think they were still getting a good deal, 0.2% below current rate levels. However when rates drop back down the rate would stay at 6.8% for the rest of the loan period.

The average LOBO rate over the 50 years will be about 6.7%; 2.4% higher than the average interest rate over the entire period.

I'll ignore this quirk of LOBO's for the rest of the post, but it's worth bearing in mind that even with apparently LOBO's look good on the graphs I've shown, there are plenty of situations in which they will be terrible.

The nasty bit you can see

Note that:

- If interest rates fall then with hindsight you would have been much better doing a floating rate. The LOBO is slightly better than a normal fixed rate.
- If interest rates stay about the same - for the entire period of the loan - then with hindsight the LOBO is slightly cheaper than the alternatives.
- If interest rates rise then with hindsight you would have been much better off doing a normal fixed rate. The LOBO is slightly better than a normal floating rate.

LOBO's are sometimes described as 'heads I (the lending bank) win, tails you lose'. This is slightly unfair (but only slightly). Imagine you are tossing a large coin with a fairly thick edge. About one in ten times it lands on its edge. When this happens you (the borrowing local authority) will win. The rest of the time; whether heads or tails,  the I (the lender) will win.

Note also that the 'win' is generally quite small -  at best it is the 0.5% we save if interest rates remain about the same. Whereas the size of the loss can be very large indeed. If rates went to 9% we'd be paying something close to 4.5% more than we would with a fixed rate (if rates went above 9%... ouch...). If rates went to zero we'd be paying 4.5% more than we would have with a floating rate.

This kind of 'bet' is very dangerous. It has many technical names:

- short gamma
- short volatility
- negative skew
- downright dangerous

The key thing is this the worst kind of bet or trade; one with limited prospects for gains and virtually unlimited downside. It is the kind of trade that smart hedge fund managers and traders lose sleep over and avoid at all costs (Notice that the investment bank traders are on the other side of this deal...). This is the bet that a local authority is putting on when it does a LOBO.

Those huge tear up costs

Let's now think about the tear up value of a LOBO. An important point to note is that the day after the trade is done, if interest rates haven't moved, then:

- The tear up value of a PWLB floating loan will be zero *
- The tear up value of a PWLB fixed loan will be zero (or to be precise, very close to it) *
- The tear up value of a LOBO will be negative; and equal to the banks profit on the deal. Research done by http://debtresistance.uk/ and analysis by http://www.vedantahedging.com/ shows that on say a £20 million pound deal profits of £1 million were common.

* This was true when the majority of LOBO's were taken out. It's my understanding that subsequent to that however the PWLB has also introduced a spread on new loans which means tear up costs are much higher on day one. I've also been told that these have been applied retrospectively. Finally the margin on PWLB loans over the rate that central government can borrow at has risen from 0.18% to 1%. All this makes the PWLB loans look bad. All this amounts to in effect a hidden cut to local authority funding from central government. It doesn't however make the LOBO loans look any better given the information that was available when they were made.


I like to call this latter effect the 'headwind'. A LOBO deal is always fighting against the headwind of the large up front profit that has to be paid out of the deal.

What about the tear up value if interest rates move? I won't show you a picture, since it would be a complex one depending on the length of time that has passed (tear up loans on all kinds of loans reduce as we get closer to the maturity date). However we can say:

- if interest rates are low then the tear up value will be significantly negative for the borrower; usually, although not always, worse than the tear up on a fixed rate loan.
- if interest rates are about the same the tear up value would be negative; initially equal to the 'head wind' day one profit margin.
- if interest rates have gone up then the tear up value will be negative but gradually getting a little smaller as rates rise.

An important point here is that the tear up value is never positive (for the borrower). If at some point the tear up value was positive, and the deal was in the borrowers favor, then the bank would cancel it (by raising interest rates so much the borrower would be forced to repay the money). Since the bank effectively always has this option to cancel it for free the tear up value can't logically ever be positive.

What about the tear up value for the lender? Well as before they have probably hedged the exposure. But whereas before the hedged lender had a fixed zero tear up cost; this time they will have a fixed positive tear up cost - equal to the initial profit they booked on the deal. And to reiterate, these are pretty decent profits.

Rebutting the rebutters

We're now in a position to address some more of the rebuttals at the top of the post:

Unfair hindsight moan: "It isn't fair to look at these in hindsight" 

Perhaps. With perfect hindsight you wouldn't have done any fixed rate borrowing (LOBO or otherwise) if you knew interest rates would fall. If you knew interest rates were going to rise you would have done a standard fixed rate loan. Note that in neithier case, with the benefit of hindsight, would a LOBO have made sense!

However without the benefit of hindsight a LOBO will:

- on average lose money, because it begins with the 'headwind' of a large tear up cost.
- be slightly better than the alternatives if interest rates didn't change very much
- be terrible if interest rates moved too much

LOBO's are an awful prospect with or without the use of hindsight. They only make sense if you have a crystal ball telling you that interest rates will definitely remain within a certain, narrow, range.

Initial rate whinge: "These loans were cheaper than normal fixed rates at the time"

This is correct - it is after all the magic of LOBO's. However as we've seen that cheapness only comes because the LA is taking on a very horrible risky bet. Also LOBO's are more expensive than if that risky 'bet' could have been bought separately for the correct value - the difference being the banks profit margin.

Current rate complaint: "These loans are cheaper than the rates we are currently paying"

That might be correct. If for example your portfolio consists mainly of fixed rate debt, then as the previous (and next) plot shows the LOBO is slightly cheaper once interest rates have fallen than the other fixed rate debt. However all that means in practice is that you have picked the second worse, rather than the worse horse, in the race. It is no reason to be patting yourself on the back.

Notice how the first and third points are contradictory criticisms. In the first point the LA's and banks are saying it's unfair to compare LOBO's and floating rate loan rates, as they couldn't have known interest rates would fall so much. In the last point they're saying it's fair to compare them with their current fixed rates... given that interest rates have fallen so much.

The most charitable thing I can say about LOBO's they are at best slightly better than the absolute worst alternative in a given interest rate scenario.

Future rate hope: "In the long run they definitely will be a good deal"

Again this might be correct; if interest rates return to the happy medium point when LOBO's are slightly better than the alternatives. If rates remain low, then they won't be a good deal. If rates rise too much and end up above the happy medium, then again they won't be a good deal. Worse still if rates rise at any point in the next 40, 50.... 70 years; even if they then fall back again, they will be a terrible deal.

Essentially the local authority is saying 'yes we've put a large dangerous bet on, and our horse is currently in second to last place, but we're confident that it will win'. 

I've never seen convincing evidence that anyone, never mind local authority treasurers, can predict interest rates with such accuracy; particularly over the 40 to 70 year terms that LOBO's cover. Seventy years ago it was 1945. Who then could have predicted that (bank base) rates would go from 2%, to 17% in the late 1970's, then back down to 0.5%?! Yet without that ability to predict interest rates there is no way you'd want to take out a LOBO.

(Some background: I worked as a trader of exotic interest rate derivatives for an investment bank. The models used to price the derivative options within LOBO's assumed that interest rate movements are random.

I subsequently managed a multi billion dollar portfolio of interest rate related assets for a hedge fund. We tried to predict what would happen to the prices of those assets using a large and fairly complex system of forecasting models, for just a few weeks ahead. In a good year we'd get just over half of those predictions right. This was considered a very good performance.)

Some of you may know this quote:

"I am one of the largest investors in America. I know these things."

Robert Citron, treasurer of Orange Country California on making a prediction that interest rates wouldn't rise. A few months later Orange County was bankrupt after losing $1.6 billion on interest rate derivatives)

What should the banks have done?

If I was in the local authorities position, without the benefit of hindsight, then what would I have done?

Well I wouldn't have bought a LOBO:(a) because of the 'headwind', and (b) because of the potential for large losses versus fairly small gains. 

I don't think I can predict interest rates; and I certainly wouldn't have been confident making a forecast that they would remain within the narrow band required to make LOBO's the best deal (and I'm amazed that the 'experts' consulted by local authorities thought they could - of which more below).

Ironically LA's would have been better off if they'd been allowed to buy derivatives outright (had they not been sold with excessive profit margins) rather than hidden inside LOBO's. That would have allowed the imaginary me to hedge against interest rate changes in a safe way, rather than exposing myself to them in the most dangerous way.

Given I didn't know what's going to happen to interest rates, and because LA's can't use derivatives, then a 50:50 mixed portfolio of fixed and floating rates seems to give the best of both worlds:

Notice that if rates fall this is better than a LOBO (and a normal fixed rate), though not as good as pure floating. If rates rise then it is better than a LOBO (and a normal floating rate), but not as good as pure fixed. Only again in the narrow region where rates stay roughly the same does a LOBO beat a mixed portfolio; and the margin of improvement is fairly small.

If you don't have the benefit of hindsight then a mixed portfolio is better than all fixed, all floating, or a LOBO.

Callable inverse floaters

The above is for 'normal' LOBO's. Here is what happens when you have one of the infamous 'inverse floaters':

Again this is a huge simplification, but accurately illustrates the kind of payoffs involved

Here the borrower is paying 8% MINUS the interest rate. As rates fall they pay more (as has happened). If rates rise then they pay less - except they don't because the lender will 'call' (cancel) the loan, leaving the borrower having to pay a normal floating rate.

Like LOBO's these save money when interest rates are stable; but leave you exposed to rising rates; and when interest rates are low (as now) you have to pay much, much more than the going rate.

Inverse floaters are like turbo charged LOBO's. If rates remain the same they look even better. If rates rise enough they are as bad. If rates fall they look much, much, worse.

I will leave inverse floaters there, and for the rest of the post I'll focus on the slightly less toxic normal LOBO's.

Why LOBO's are still bad even in a portfolio

Let's now return to the portfolio excuse: "They (LOBO's) should be looked at in the context of the local authorities overall borrowing portfolio rather than in isolation"

Okay it's difficult to know what kind of portfolio the local authority has. Let's look at two cases. Firstly, the case when the portfolio was originally full of floating rate debt. The LA then take's half of that and puts it into LOBO's. What do we get?

It's true there is a small improvement here, but only (and this won't come as any surprise) if interest rates stay at roughly the same level. If rates increase, then the improvement diminishes as the LOBO rate gets closer to what we've already got on the rest of our portfolio. If rates fall then we won't see the benefit from them, as we're stuck paying a higher rate on our portfolio.

Contrast this with following my advice above and putting half the portfolio into fixed rate debt, so we end up with the mixed 50:50 option.

If rates fall then we'll be slightly worse off than with the LOBO product. However if rates rise we'll be much less exposed to the rising rate then we would be with eithier 100% floating or LOBO's.

(Note the perfect hindsight option - if you knew for sure that rates would fall - would be to keep all your portfolio in floating rate).

What if the starting portfolio was originally stuffed with fixed rate debt? Again we'll first take 50% of it and borrow in the form of LOBO's instead. We get this:

There is a small improvement here if interest rates fall. However if rates rise we end up paying much more than we would have done originally. This would only make sense if we knew in advance that interest rates would fall. To put it another way it only made sense to add LOBO's to a portfolio in hindsight (!)

Again suppose the LA followed my advice, and instead of putting 50% of their existing fixed rate portfolio into a LOBO, they instead took out a floating rate loan?

This gives us the purple (ish) line above. It's very slightly more expensive if rates rise. However if interest rates fall we get a much bigger fall in funding costs than with the LOBO.

(Note the perfect hindsight option - if you knew for sure that rates would rise - would be to keep all your portfolio in a fixed rate).

The conclusions for those with portfolio's are very similar to those when we look at LOBO's in isolation. In both cases turning the portfolio into a mixture of fixed and floating debt is eithier a little worse, or significantly better, than putting half of the portfolio into LOBO's. Overall, without the benefit of hindsight, the LOBO option once again looks bad because of (a) the headwind effect, and (b) because it generates at best a small improvement in return for being much worse if things move against you - the kind of horrible payoff that traders hate.

So someone with a portfolio containing mainly fixed rate debt can say

Didn't I do well using LOBO's, my funding costs have fallen in this low interest rate enviroment?

Yes, but it would have been much better to have put half your portfolio into simple floating debt.

It's very easy to say that with the benefit of hindsight.

Okay, but if we hadn't known in advance where interest rates are going then (a) on average you'd be worse off (headwind effect), (b) you'd eithier have been slightly better off with rates falling, or a lot worse off if rates had risen. That isn't a very responsible thing to do. You've taken a gamble, and ended up backing the horse that came second last only just ahead of the last horse....

Incentive problems in the LOBO market (I get 'commission', you receive 'extra contractual payments', they get 'backhanders')...

Here, in pictures, is how a LOBO gets arranged; or is supposed to be arranged:

Treasury advisors (featured here with interest rate forecasting crystal ball, owned by all treasury advisors) can be people like Sector (owned by Capita and mentioned in the programme) or Butlers. They provide general advice on funding, but for specialist products like LOBO's they will go to brokers. Brokers include ICAP, Eurobrokers, and so on. Incidentally Butlers is owned by ICAP...

The broker arranges a competitive auction, asking several banks to give them the contract terms for their proposed LOBO, given some parameters. The banks then bid, and the broker chooses the best deal for the borrower.

Here is how the fees flow:

Both treasury advisors and brokers (sometimes directly, or indirectly) get paid for their work. The LA is their customer. They are being paid by, and so should represents the best interests of, the customer.

However:

a) I know from my own experience that banks pay commissions to brokers.

b) We know from the butler report that brokers also pay treasury advisors commissions.

I've added these payments in red below. Notice both the broker and the treasury advisor are being paid twice. Once by the borrower (the LA), and then again by the lender (the bank). In the case of the treasury advisor the lender payment comes indirectly from the broker. This is a clear conflict of interest.

It's clear that the larger the banks profit on the deal (so the worse the deal is for the LA), the larger the commission they can pay the broker. The bank is pushed by the broker to pay a larger commission if the want to get the deal.

The broker here is scratching their head. Should they get the best deal for their ultimate customer the LA, or go for the bank paying them the biggest commission, which is likely to be the worst deal for the LA?

Would the LA even know whether they are getting the best deal or not? It isn't always obvious which of a series of proposed loans; with slightly different interest rates, up front teaser rates and maturities; would be the best.

What about the treasury advisors? Are they going to go to brokers who they trust to run a good auction and get the best deal, or to ones who are going to give them the highest commision? And the ones who give them the highest commission, well aren't they probably the ones getting the highest commission from the bank (which again is likely to be a poorer deal for the LA)? Interestingly in the vast majority of LOBO's the same brokers and treasury advisors were consistently working together (maybe they were just good friends); and there does seem to have been a tendency for certain banks and brokers to work together.

Are the treasury advisors correctly calculating the profits the bank is making on these deals, and telling the LA? Are they choosing to recommend LOBO's over and above simpler options, like mixed portfolios of fixed and floating, because they will get commissions from brokers on LOBO's and not on the simpler deals? Have they explained to the LA clearly what a LOBO is, and how dangerous the embedded derivatives within it are if their interest rate forecasts go wrong?

Are they telling the LA that they are being paid twice, and the brokers are as well?

It isn't just the broker who is scratching his head here. 

I am as well.