Separating Positions from Allocations

Most trading models I see are missing an important concept. It’s not a terribly difficult concept, but it is an important one. It’s not at all strange that most traders, in particular on the retail side, are missing this point. Most trading books skip over it. Most books gloss over it, or just don’t mention it at all. My books included.

The Traditional Way

Here’s how a regular type of trading model works. The kind that most of you out there are likely working with. Regardless of your trading style, asset class or software of choice, this part tends to be more or less the same.

Your code iterates through the data, day by day, minute by minute or whatever frequency you’re operating on. On each day, you check some conditions for some time series. If they fulfill certain criteria, you calculate a trade size and buy or sell. This is a very simplistic description of course.

Take a very simple model as an example. If the price moves above a 200 day moving average, you buy. When it moves back down the same average, you exit. In the simplest of examples, let’s assume you trade a 10% notional trade size on each position.

Will these rules work? Probably not, but that’s not at all my point. The point is that a model like that is quite unaware of it’s own portfolio level risk. And why is that? Because these rules are all on the position level.

Let’s say you apply these rules on a universe of thirty markets. Depending on how many of these markets are above their 200 day moving average, your overall exposure may vary from the extremes 0% and 300%. Your trading logic is unaware of overall exposure or risk.

Even if we make that moving average model more realistic, making better entry and exit rules and adding a volatility based allocation, you won’t get away from this issue. It’s still a position level model.

All That Matters is the Portfolio

The position level, by itself, is meaningless. That is, as long as the portfolio behaves well, we don’t care about positions. Therefore, you need a portfolio level guidance mechanism.

Take the same simple moving average model above. Now apply it on thirty futures markets and run a simulation. No, we still don’t care about the results per se. The interesting thing that you should notice is how the portfolio risk moves up and down quite dramatically at times.

After all, the allocation mechanism doesn’t care about how many positions you have open. It will just buy a 10% block in each position. Sometimes we have four position on, sometimes 20. And now our actual risk has become quite random.

Again, all we care about here is the portfolio. If the portfolio itself makes money, that’s all we need. Therefore, keeping track of allocations on a portfolio level makes more sense.

A Different Way of Thinking

Here’s a different way of approaching it. One which is particularly well suited to my favorite software for building trading strategies. In RightEdge, it’s easy to build logic on both instrument level and portfolio level. This may not be the case in all simulation environments, of course.

Try to think of the decision of whether or not to hold a specific asset as a very different decision from how much to allocate to it. Write your usual code for finding entry and exit points. But don’t let this code trade. It’s just for keeping track of which markets you want to be long, short or flat.

In RightEdge terminology, which admittedly is a little unfortunate, this code would go in the MySymbolScript class. This is where most people write all their code. But this code isn’t aware of anything outside of the current symbol. A symbol in this context is the same as a market, or an instrument.

But the other of the two most important RightEdge classes, MySystem, is aware of all markets. This is where the allocation logic needs to go. First you run through all the instrument level logic. Now you know what to be long or short. Then, when knowing this, you can calculate what portfolio allocation you want. Then, and only then, should you start placing orders.

Conceptual Model Example

Let’s take slightly more complex model example than the one above. Here’s the conceptual model:

This sounds easy on the surface. It’s pretty much standard stuff. But if you implement this the simple way, on the instrument by instrument level, you will have a somewhat random overall risk.

Look at that inverse volatility ticket. That’s quite a common concept, but it can be implemented many different ways. Nothing particularly novel. In Following the Trend, I used a simplistic ATR based method. It’s an ok method which is neither great nor horrible. It does the job, and has proven quite useful over time. But it has a weakness. The same weakness as described above. We don’t know anything about the other positions.

Triggering Portfolio Rebalance

Now approach model construction from a different point of view. Build your entry and exit rules. But don’t let them trade. Instead, whenever your rules dictate that a position should be entered or exited, trigger a rebalance event.

For the conceptual model above, a rebalance event would be triggered on the breakouts, where you would normally just do a trade. They would also be triggered on at the trailing stop points, when you would normally just exit a position. Now the entire portfolio will be rebalanced at these points.

The rebalance logic is on the portfolio level. Above the instrument level. On the portfolio level, you know everything about all positions. Now you can build a proper rebalance logic.

In its simplest form, a rebalance might just distribute capital equally to all markets. Rebalance is triggered, you see that 15 positions are held and you want to allocate equal notional. So the rebalance logic simply does 1/15 calculation, ending up allocating 6.7% to each position.

Or if you want to have a volatility parity basis, you can easily perform that logic too. If you have a cash equity model where you want to allocate 100% of capital, but at a vola parity basis, that’s simple. Add up all the inverse volas and divide each instrument’s inverse vola by the sum, and you’ve got your weight.

If you’re looking to have an overall vola target, you could divide your vola factor by the annualized vola and divide by open positions.

If you want to do something more complex, like incorporate a covariance matrix and size positions based on this, you can implement that as well.

The rebalance event will reset weights according to your logic. Should your model not trade often enough, you could also trigger the rebalance event periodically to ensure that weights stay in line.