Liquidity-aware portfolio optimisation: incorporating tradeable size into the construction problem
The standard mean-variance framework treats every asset as available in any quantity at the quoted price. In practice, the size of a position changes both its execution cost and its feasibility: a 1% portfolio weight in a thinly-traded micro-cap may be impossible to enter without moving the price, while the same weight in a large-cap ETF is trivial. Liquidity-aware optimisation extends the standard framework to account for these realities.
What liquidity-aware optimisation is
The basic construction adds a liquidity penalty or constraint to the standard mean-variance objective. The penalty can take several forms: a transaction-cost term that scales with position size relative to average daily volume; a constraint that caps any single-asset weight as a multiple of available liquidity; a slippage model that estimates the price impact of executing the optimal portfolio over a defined trading horizon.
The mathematical structure depends on the chosen approach. Linear penalties produce convex optimisations that solve quickly. Non-linear slippage models (square-root market impact) produce more complex optimisations that may require iterative or stochastic solution methods. The choice trades off realism against tractability.
How it works
The simplest implementation uses a liquidity score for each asset—typically based on average daily dollar volume, bid-ask spread, and market depth—and penalises positions that exceed a multiple of that score. An asset with a 50,000,000 USD average daily volume might be capped at 1,000,000 USD per day of trade activity, with the optimisation then solving for the best portfolio under that constraint.
More sophisticated implementations model the price impact of execution explicitly. Almgren and Chriss (2001) developed the canonical model: market impact scales with the square root of executed volume relative to ADV, with a permanent component (which moves the price) and a temporary component (which reverses). The optimisation then trades off expected return against the present-value cost of executing the resulting portfolio.
What the evidence shows
Empirical studies of liquidity-aware optimisation (Engle & Ferstenberg, 2007; Almgren, Thum, Hauptmann & Li, 2005) find that the resulting portfolios are typically less concentrated in small-cap names, more concentrated in liquid large-caps and ETFs, and produce smoother returns over the execution horizon. The improvement in realised performance is largest for institutional portfolios where positions are large enough to move prices materially.
For institutional execution and rebalancing, liquidity-aware methods have become standard. The development of TCA (transaction cost analysis) frameworks across the industry reflects the same underlying recognition that ignoring liquidity in optimisation produces unrealistic portfolios.
Limitations and trade-offs
Liquidity-aware optimisation requires liquidity inputs that are themselves estimates. Average daily volume varies over time, and historical ADV is a noisy guide to future tradeable size. Bid-ask spreads change with volatility and market regime. Market-impact coefficients are typically calibrated from historical execution data, which may not apply to a future execution under different conditions.
The framework also adds complexity to a process that is already estimation-heavy. For portfolios where liquidity is not binding—most retail and self-directed accounts—the additional machinery produces little improvement and obscures the basic optimisation. Liquidity-aware methods are most valuable where they are most needed: large portfolios in less-liquid instruments.
Liquidity-aware optimisation in pfolio
Liquidity constraints are not a binding factor in pfolio's instrument universe—the selected ETFs and futures all trade with sufficient depth for the position sizes typical of self-directed portfolios. Liquidity-aware optimisation matters more for institutional sizing; for self-directed use, the standard construction framework is appropriate.
Related articles
Disclaimer
Get started now
