Conditional Maximum Loss Limits
This article examines how large Conditional Maximum Loss (CML) problems we can solve on normal-sized servers.
The recently introduced Conditional Maximum Loss (CML) investment risk measure allows us to optimize the tail risk over the entire path between portfolio rebalancing times.
This is usually how investment managers think about “drawdowns” in their daily work, because drawdowns in the strict mathematical sense can lead to unintuitive results by penalizing the upside.
Conditional Maximum Loss (CML) is also feasible to solve for fully general Monte Carlo paths, contrary to Conditional Drawdown-at-Risk (CDaR) that requires an introduction of many auxiliary variables and constraints that quickly lead to excessive memory usage.
CML is still more computationally demanding than Conditional Value-at-Risk (CVaR), which is why the number of paths was limited to S=2500 with a horizon of H=21 trading days for I=10 instruments in the article that introduces Conditional Maximum Loss Portfolio Optimization.
To see which kind of CVaR problems we can solve and at what speed, see this article.
Note that the linear programming problem presented in the original CML article is fairly simple. In this article’s Python case study, we will see what kind of problems we can solve for CML with highly specialized algorithms that are significantly more efficient in relation to both memory usage and computation time.
Python case study
The case study below uses the Investment Analysis module to optimize Conditional Maximum Loss (CML), including CML tracking error constraints.
The investment simulation model is the same as the original Conditional Maximum Loss Portfolio Optimization article, using the Fully Flexible Resampling (FFR) method and VIX as the single state variable.
Note that we specifically focus on the number of instruments I and the horizon length H while fixing the number of simulated paths to S=10000, because this should be sufficient for all practical purposes.
As you will see in the code below, we can easily handle H=260 trading days, representing the next (long) trading year. For horizons above one year, we recommend that you still use all available daily observations in your investment simulation but that you sample paths with a lower frequency. For example, if you want to optimize the path over a five-year period, you can sample weekly data from the simulation. If you want to optimize paths longer than five years, it is probably sufficient to sample monthly observations from the simulated paths.
Similar to the High-Dimensional CVaR Optimization case study, we also increase the number of assets quite significantly from the original I=10. However, note that if we increased the number of instruments to I=2000, as in the high-dimensional CVaR optimization code, this would require 38.7 GiB memory for S=10000 and H=260 just to store the paths, which is more than most usual servers have.
The Python code below first uses the Investment Simulation module to simulate the cumulative P&L H=260 steps into the future. After that, we use the Investment Analysis module to perform the actual CML portfolio optimization, with and without CML tracking error constraints.
We then use the simulated P&L for the original I=10 equity indices to generate a larger number of fictitious stocks, similar to the high-dimensional CVaR optimization code, to examine how large CML problems we can solve on standard servers and at which speed.
In the end of this article, there is a conclusion with other practical recommendations for how to size the CML portfolio optimization problems for your particular use case.
As a paid subscriber, you have access to all the paid content, including the Applied Quantitative Investment Management course, as well as asking me questions through the Substack chat.