How to ascertain/establish certainty of a portfolio rebalancing strategy?
How to ascertain/establish certainty of a portfolio rebalancing strategy?
Loading saved threads...
Stoic · External communityPost link
External question — Quantitative Finance Stack Exchange
Author: Stoic
Original post: https://quant.stackexchange.com/questions/39265
License: CC BY-SA 3.0 — https://creativecommons.org/licenses/by-sa/3.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
I created a portfolio rebalancing strategy, that I am currently paper trading with. It is, primarily, based on mean-reversion principle with a few rules in place, and geared towards cryptocurrencies, in general.
I double the commission to account for slippage as well as when rebalancing I first sell all assets I am holding and then, buy them even if same. This adds a few pips of random slippage as well, at the least.
Here are a few plots I obtained from this strategy in backtesting. I used
1h
as well as
1d
ticks from Bittrex.
1d
timeframe backtesting result with a
0.5%
(0.25% bittrex + 0.25% slippage) commission fee:
1hr
timeframe with
0
fee:
with 0.2% fee (binance 0.1% plus 0.1% slippage):
with 0.5% fee (bittrex 0.25% plus 0.25% slippage):
Now, since the chosen domain does not provide extensive history, I am unable to test this strategy on a longer timeframe.
And, therefore, I would like to know how I can ascertain that the strategy is indeed useful? I, particularly, would like the 1hr timeframe equity curve, but adding commission there ruins everything.
Quote
Report
Valerii Sakara · External communityPost link
External answer — Quantitative Finance Stack Exchange
Author: Valerii Sakara
Original post: https://quant.stackexchange.com/a/85763
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
The pattern in your four charts is a clean signature, not a fluke: at 1h rebalancing, you're trading constantly, so the
number
of round-trips is enormous. The volatility-pumping/rebalancing premium scales roughly with realized variance captured between rebalances, but transaction cost scales linearly with the
number
of rebalances — at 1h that's ~24x more trades than at 1d for capturing much the same total variance. So going from 0% to 0.2% to 0.5% doesn't erode the edge proportionally, it erodes it combinatorially: you're paying the same fee 24x more often against a shrinking per-trade gain.
Two things worth checking before writing this off (or trading the 1d version live):
Compute edge-per-rebalance directly instead of reading the aggregate equity curve. For each rebalance event, log the raw price move captured versus the round-trip cost paid at that event. If the median edge-per-rebalance is smaller than roughly 2x your assumed cost-per-rebalance, the strategy is bleeding on a typical trade and only surviving on tail events — that's a fragile edge, not a real one, regardless of what the cumulative curve looks like.
Switch from scheduled (every-hour) rebalancing to threshold/band rebalancing — only trade when an asset's weight drifts past e.g. ±3-5% of target, instead of on a fixed clock. This is standard in the volatility-pumping literature specifically because it decouples trade frequency from time and ties it to actual drift, which is what you're trying to harvest. You'll capture most of the premium at a fraction of the round-trips, and it'll tell you honestly whether the edge survives realistic costs — instead of comparing several fee assumptions against the same over-frequent schedule.
One more thing worth double-checking: doubling the fee is a clean way to approximate slippage, but on thin alt pairs the real bid-ask can blow well past a flat multiplier during exactly the high-volatility windows a mean-reversion signal is trying to catch. That's usually where a backtest's assumed slippage diverges hardest from what a live order book would have actually given you — worth pulling real historical spread data for your specific pairs rather than assuming a constant.
Quote
Report
Post Reply
Checking account access…