Building a Portfolio of Trading Sleeves

Abstract

One good backtest is rarely enough. A practical trading system needs a portfolio of sleeves: distinct strategy components that can add return without making the same mistakes on the same days.

For developers, the portfolio step changes the objective. You stop asking whether a strategy is good alone and start asking whether it improves the book.

The Sleeve Test

A sleeve should have its own logic, data needs, risk budget, and failure modes. It might be an opening compression strategy, a VWAP mean reversion strategy, a relative-strength branch, or a residual add-on.

The first test is standalone sanity. The second test is incremental value. A sleeve that looks strong alone can be redundant if it trades the same days and directions as the anchor.

Weight Is A Research Decision

Portfolio construction is not only selecting components. It is selecting weights under drawdown and robustness constraints. A higher weight can improve Sharpe while also breaching a drawdown cap. A slightly smaller operational weight can be the better paper candidate.

This is a developer-friendly problem because it should produce artifacts: weight frontier, selected book trades, selected daily PnL, and the reason the chosen weight passed.

Do Not Hide Correlation

Correlated sleeves are not automatically invalid. They are risky when the research process pretends they are independent. Measure overlap, active days, drawdown contribution, and top-day concentration.

If a correlated sleeve still improves book-level evidence after costs and robustness checks, it can remain. But the report should say that clearly.

Takeaway

A portfolio of trading sleeves is a systems problem. The useful question is not whether each component has a nice chart. It is whether the combined book is more robust, more executable, and easier to monitor than the anchor alone.