Capital allocation is not a one-time decision. The moment bots start trading, their allocations drift. A bot that doubles its capital now controls a larger share of the portfolio than intended. A bot that loses half its capital controls less. Without rebalancing, the portfolio gradually concentrates capital in whatever strategies happened to perform best recently, which is a form of momentum chasing at the portfolio level. Rebalancing is the discipline that prevents the portfolio from becoming something you did not design.
Fixed Allocation: The Starting Point
Our current paper trading deployment uses fixed equal allocation: 1,000 dollars per bot, 45,000 dollars total. When a bot generates profit, the profit stays in that bot's account. When a bot takes a loss, the loss reduces that bot's available capital. We do not redistribute capital between bots during the paper trading phase.
This sounds like we are ignoring the rebalancing problem, and during paper trading we deliberately are. The purpose of paper trading is to measure each bot's performance with identical starting conditions. Rebalancing during this phase would contaminate the data. A bot that lost money early would receive a capital injection, artificially improving its subsequent absolute returns. A bot that profited early would have capital withdrawn, artificially dampening its subsequent returns. Clean performance data requires fixed allocation without rebalancing.
The downside is allocation drift. After a few weeks of trading, bots are no longer equally weighted. A bot that made 200 dollars now has 1,200 dollars, controlling 2.7 percent of the portfolio instead of 2.2 percent. A bot that lost 300 dollars has 700 dollars, controlling 1.6 percent. These drifts are small in the short term but accumulate. Over months, the portfolio composition can diverge significantly from the intended allocation.
Calendar Rebalancing: Simple but Suboptimal
The simplest rebalancing approach is calendar-based: every week or every month, reset all bots to their target allocation. Take profits from winners, add capital to losers, and start the next period with a clean slate.
Calendar rebalancing has one major advantage: simplicity. There is no logic to implement beyond a scheduled transfer. But it has two disadvantages for automated trading.
First, the rebalancing frequency is arbitrary. Weekly rebalancing might be too frequent during low-volatility periods (you are paying transaction costs to rebalance allocations that have barely drifted) and too infrequent during high-volatility periods (a single bad week can create enormous drift before the next rebalance date).
Second, it fights the market. Rebalancing mechanically moves capital from winners to losers. In trending markets, this consistently takes money out of the strategies that are capturing the trend and puts it into the strategies that are not. Over a multi-week trend, calendar rebalancing repeatedly punishes the right strategies.
Threshold-Based Rebalancing: The Better Approach
Threshold-based rebalancing triggers only when an allocation drifts beyond a defined band. If the target allocation for each bot is 2.22 percent (1/45) of the portfolio, set a band of plus or minus 0.5 percentage points. Rebalancing triggers only when a bot's allocation drifts above 2.72 percent or below 1.72 percent.
This approach has three advantages over calendar rebalancing. It does not rebalance during calm periods when drift is minimal, saving transaction costs. It rebalances quickly during volatile periods when drift accelerates. And it allows some degree of allocation momentum, letting winners run until their drift hits the upper band.
The threshold width is a tuning parameter. Narrow bands (0.25 percentage points) rebalance frequently and keep allocations tight. Wide bands (1.0 percentage point) rebalance rarely and allow more drift. For a 45-bot portfolio, we plan to use a 0.5 percentage point band for live trading, which means a bot needs to grow or shrink by roughly 22 percent of its initial allocation before rebalancing triggers.
The implementation checks allocation drift after every bot tick cycle. When a bot's allocation exceeds the upper band, the excess capital is withdrawn and placed in a rebalancing pool. When a bot's allocation falls below the lower band, capital is added from the pool. If the pool has insufficient capital (more bots below band than above), the withdrawal from over-allocated bots is increased proportionally.
Risk Parity Rebalancing: The Dynamic Target
Fixed allocation assumes all bots should have equal capital. Risk parity allocation assumes all bots should contribute equal risk. The target allocation for each bot is its inverse-volatility weight: bots with lower return volatility get more capital, bots with higher volatility get less.
This means the target itself changes over time as bot volatilities evolve. A bot whose volatility increases sees its target allocation decrease. A bot whose volatility decreases sees its target increase. The rebalancing mechanism does not just correct drift from a static target; it adjusts the target based on recent risk characteristics.
Our capital allocator calculates inverse-volatility weights using 30-day rolling return volatility for each bot. The weights are recalculated daily. The single-bot cap of 40 percent prevents any bot from receiving an extreme allocation even if its volatility is unusually low. When the cap clips a bot's allocation, the surplus distributes to uncapped bots using the same inverse-volatility weights.
The combination of risk parity targets with threshold-based rebalancing is our planned live trading approach. The targets shift daily based on volatility. Rebalancing triggers only when actual allocations drift beyond the threshold band around the current target. This means the system adjusts both to changing risk characteristics (via the moving target) and to PnL-driven drift (via the threshold triggers).
Surplus Redistribution Logic
When a bot hits the 40 percent cap, the surplus capital needs somewhere to go. The redistribution algorithm works in two passes.
First pass: calculate each uncapped bot's inverse-volatility weight and normalize them to sum to the surplus amount. Each uncapped bot receives its proportional share of the surplus. If any of these receive enough to hit the 40 percent cap themselves, they are capped and their excess joins the surplus for a second pass.
Second pass: repeat the redistribution among still-uncapped bots. In practice, with 45 bots and a 40 percent cap, it is nearly impossible for more than one bot to hit the cap simultaneously. The second pass is a safety mechanism, not a regular occurrence.
The constraint that all capital must be deployed means the algorithm always terminates with total allocation equal to total capital. No capital sits idle in a rebalancing buffer. Cash drag is zero outside of the brief rebalancing calculation.
Transaction Costs of Rebalancing
Rebalancing has a direct cost: the PnL realized when closing or reducing positions, plus any trading fees on the rebalancing trades themselves. In perpetual futures, there are no explicit closing costs beyond the maker/taker fee (typically 0.02 to 0.04 percent per side on Binance). But rebalancing forces position adjustments at market-determined prices rather than strategy-determined prices. A mean reversion bot that has a 150 dollar profit in an open position might be asked to reduce that position for rebalancing purposes, crystallizing the profit at a suboptimal time from the strategy's perspective.
We mitigate this by rebalancing capital, not positions. When a bot's allocation is reduced, we do not close its positions. We reduce its available capital for new trades. Existing positions run to their natural exit (stop loss, take profit, or strategy signal). Only the next trade uses the reduced capital. This avoids the forced liquidation problem entirely at the cost of slower rebalancing convergence.
What We Run Today vs What We Plan
Today during paper trading: fixed equal allocation at 1,000 dollars per bot, no rebalancing. The allocations will drift and that is acceptable because we are collecting performance data, not optimizing capital efficiency.
For live trading: risk parity targets with threshold-based rebalancing, capital-level adjustment (not position-level), 40 percent single-bot cap with surplus redistribution. The transition will happen when we have enough paper trading data to calculate stable volatility estimates for each bot, likely after 60 to 90 days of live paper trading.
The most important principle across all rebalancing approaches is that rebalancing is a risk management operation, not a return optimization operation. Its purpose is to keep the portfolio aligned with the intended risk budget. Whether that budget is equal weight (paper trading) or risk parity (live trading), rebalancing ensures the portfolio does not gradually morph into something the operator did not design.