Think Like A PM: Add Turnover In Your Portfolio Optimiser Objective

Introduction

For some PMs, they will treat transaction costs as something to be solved outside of their optimisers. They throw their expected returns and covariance matrices into a mean-variance optimiser, take what comes out of them, and feed them into an execution algorithm to handle transaction costs.

If you’re doing this, I bet you’re wincing at the turnover produced by your optimiser, and then you have to throttle your execution algorithm really hard to deal with this. Here’s an idea, build transaction costs directly into your optimisation objective. If you frame it this way, firstly, you stop getting fisted by your optimiser trying to chase sharpe even at the cost of costly turnover, MORE IMPORTANTLY, you actually get benefits of regularizing your covariance matrix, that is to say, you actually implicit end up with a shrunk covariance matrix.

For those of you who don’t know what that means, it means you say that your covariance matrix is actually a lot more noisy than what it seems, and “shrinking” your covariance matrix is actually a fancy way of saying “I want to actually treat my instruments as though they actually have close to equal variance, because I think my estimation of the covariance matrix is bad.” This has many nice properties - one of them is that it makes any optimisation more stable.

You get what I’m saying here? Including transaction costs not only gives you a portfolio that better reflects reality, but it even makes your optimisation more stable. What gives?!