Drawdown como acelerador, não freio

A faixa-alvo de drawdown do long sleeve é -10 a -15%. O throttle de drawdown dispara em -8%. A primeira coisa que todo operador nota ao ler a especificação é que esses dois números não combinam, e eles querem saber por que cortaríamos risco antes de chegar na própria tolerância.

A resposta é que a faixa é o que estamos dispostos a aceitar ao longo do ciclo; o throttle é o que fazemos a cada momento para manter a faixa intacta. Agir na faixa em si é agir tarde demais. O throttle é o que torna a faixa atingível - sem ele, a faixa é uma esperança, não um orçamento.

Nosso primeiro throttle foi um interruptor duro, e funcionou lindamente em backtest. Patrimônio abaixo de -12% do pico móvel significava: cortar sleeves de risco para meio-peso, manter ali até o drawdown fechar de volta para -6%, e re-engajar. O problema é que backtest não tem path-dependence, e produção tem. Uma erosão lenta de -9% para -12%, onde o regime está realmente deteriorando, era tratada identicamente a uma única perna brusca para baixo, onde o regime de fato não mudou e mean-reversion é mais provável que continuação. O primeiro caso quer cortar risco. O segundo quer segurar - possivelmente adicionar. Um interruptor binário no nível não consegue distinguir.

O timing de re-engajamento foi a segunda coisa a quebrar. Cortar em -12% e re-engajar em -6% significa que o sleeve fica meio-tamanho durante toda a transição bear-para-bull, que é exatamente onde a maior parte da recuperação acontece. Medimos o custo em três anos de dados live + backtest; foram cerca de 220bps de retorno anual esperado sentados no chão por uma quirk de onde o limiar estava posto.

A terceira coisa foi um problema de descontinuidade que deveríamos ter visto vindo. Um interruptor binário cria uma descontinuidade na alocação no gatilho. Perto do limiar, ruído de preço minúsculo gera flips de sleeve inteiro. O turnover disparou, os custos de transação comeram a economia, e o sleeve começou a parecer trêmulo de um jeito que nenhuma garantia de operador conseguia consertar.

O throttle atual substitui os três modos de falha pelo mesmo movimento: torna a resposta contínua. O gatilho lê uma média móvel exponencialmente ponderada de 7 dias da distância pico-até-fundo em vez do drawdown spot, o que mata a path-dependence - uma única perna rápida não dispara o throttle até o drawdown se sustentar. O corte em si escala linearmente: assim que o drawdown suavizado fura -8%, os sleeves de risco (BTC, SPY, GLD) escalam para o piso bear conforme o drawdown suavizado se aprofunda. Em -8% você cortou ~25%. Em -12%, ~75%. Em -15% - a borda da faixa - você está no piso. SHY, o piso de renda fixa, absorve o deslocamento. O re-engajamento é a mesma função ao contrário: conforme o drawdown suavizado fecha de volta para zero, o corte se desenrola no mesmo gradiente. Não existe gate de “esperar -6%”.

A coisa toda é uma única função diferenciável que mapeia drawdown suavizado para um throttle multiplier entre 0.0 (piso bear total) e 1.0 (sem corte). O multiplier é aplicado ao peso de sleeve condicional ao regime depois que o gate de regime já o definiu, então o throttle compõe com o regime em vez de brigar com ele. Regime bear mais drawdown profundo termina no piso bear; regime bear mais drawdown raso fica no peso de regime bear, porque o multiplier do throttle fica perto de 1 acima de -8%.

A escolha de -8% merece seu próprio parágrafo porque é o pedaço mais questionado. O throttle precisa disparar antes da faixa, não nela; se dispara na faixa, o orçamento de tolerância já foi gasto. Pegamos -8% porque um drawdown suavizado dessa profundidade historicamente (1990 em diante, ao longo do histórico composto de BTC e SPY) foi o nível além do qual a probabilidade condicional do próximo movimento de 5% ser ainda mais para baixo passa de 50%. Acima de -8% o próximo 5% é mais ou menos cara-coroa. Abaixo de -8% inclina para mais para baixo em 4-7 pontos percentuais dependendo do regime. Agir num desbalanço é para o que o throttle existe. O limiar exato é recalibrado anualmente; tem ficado entre -7 e -9% todo ano na última década e a gente não espera que isso pare de ser verdade tão cedo.

Algumas escolhas de design em torno do throttle não eram óbvias no começo. Uma é que quando o throttle corta, o peso liberado vai para SHY em vez de cash. SHY tem retorno esperado não-zero, e botar o sleeve de volta em risco a partir de cash carrega uma função-degrau de custo de transação que dá para evitar parqueando o peso rotacionado num proxy líquido de bond. Cash parece mais seguro; nesse tipo de sistema é na verdade pior. Outra é que o throttle é estritamente reativo - lê o que já aconteceu. Testamos throttles preditivos (“preveja um drawdown, corte antes”) por dois trimestres. Cortavam demais, perdiam as recuperações, e o erro de previsão sobrepujava o drawdown poupado. Um throttle reativo bom ganha de um preditivo ruim por uma margem larga.

O throttle também não sobrepõe o modelo de regime - compõe com ele, multiplicativamente. Se o regime está em bear, os pesos já estão baixos; o throttle então multiplica esses pesos baixos para baixo em direção ao piso bear. Não há cenário onde o throttle puxa o sleeve acima do teto de regime, e não há cenário onde o regime força o sleeve acima do piso do throttle. Os dois sistemas são comutativos nesse sentido, e isso não é acidente - precisou de uma reescrita para chegar lá, depois de um trimestre em que regime e throttle brigavam um com o outro.

O que ainda queremos consertar é a simetria entre sleeves. O throttle atual trata drawdowns de BTC e SPY como um composto único, o que está mais ou menos ok quando os dois estão correlacionados e bem errado quando um deles está liderando. Um drawdown liderado por BTC deveria cortar BTC mais forte e deixar SPY mais perto da faixa; um drawdown liderado por SPY é o contrário. A implementação é direta - um multiplier condicional ao sleeve - mas a calibração é a parte difícil, porque distribuições históricas de drawdown sleeve-específicas são mais ralas que a composta. Estamos coletando mais um trimestre de dados e publicaremos os resultados quando a calibração convergir.

• inite team