O bot CTA (trend following sobre futuros)#

Se o bot TRPS vive de janelas de quinze minutos e o bot DHCS de um rito de fim de tarde que precisa bater até a casa decimal, o bot CTA tem um único compromisso por dia, no meio da manhã, e a virtude que se pede dele não é nem a pontualidade nem a exatidão: é a constância. A estratégia da página CTA trend following — ensemble dos sinais a 1/3/12 meses, vol scaling, banda de não-trading sobre uns quinze futuros — é a mais lenta das três, e o seu bot é, em consequência, o mais tranquilo: roda agora ao lado dos outros dois, no mesmo mini PC, o mesmo Gateway, o mesmo canal de notificações e o mesmo kill switch da página Setup, e aplica os mesmos quatro princípios da página Execução. O que ele acrescenta é a escala: quinze mercados em vez de um, quatro bolsas, um calendário de vencimentos que nunca coincidem — e é aí que a arquitetura ganha a sua página. Como sempre, todos os horários em America/New_York.

Um ciclo por dia#

O compromisso é às 10:30, um horário escolhido por subtração: longe do sino de abertura e do ciclo dos stops da TRPS, longe das janelas de fim de tarde onde se aglomeram o rito DHCS, a seleção TRPS e os rolls, dentro das horas líquidas de todas as bolsas do universo. O luxo de poder se permitir um horário cômodo vem da lentidão do sinal: os cálculos usam os fechamentos de ontem — um sinal de doze meses aguenta um atraso de um mês quase sem degradação, que dirá meio dia (Hurst e coautores) — então a execução no meio da manhã não persegue nada nem ninguém.

A sequência do ciclo é fixa: dados, sinais, plano, roll, risco, ordens, escrita. O bot atualiza as séries históricas dos contratos, calcula para cada instrumento os três sinais e a volatilidade, produz a posição-alvo quantizada, compara-a com a posição real e deixa passar pela banda de não-trading apenas os desvios que a superam: num dia típico o plano está vazio ou quase, e esse é o comportamento de projeto — a avaliação é diária, o trading efetivo tem frequência quase mensal. As ordens que sobrevivem à banda são limit no mid com passo de um tick rumo ao preço executável, nunca a mercado; uma ordem que ao fim da janela não foi executada é cancelada e ponto final, porque o sinal é lento e perder um dia custa menos que um spread perseguido — amanhã o ciclo recalcula tudo do zero e, se o desvio ainda existir, tenta de novo. No fim do ciclo, um único resumo no Telegram: posições-alvo contra reais, trades executados e trades bloqueados (pela banda, pelos caps, pelo risco), sinais por instrumento, eventuais degradações declaradas. Uma mensagem por dia, não um fluxo: a alert fatigue é um risco operacional como os outros.

O roll, de serviço a motor#

O bot rolava futuros desde antes de esta estratégia existir: o roll trimestral dos contratos da guarda noturna, o roll do hedge da DHCS — funções de serviço, um contrato de cada vez, descritas na página Futuros. A perna CTA promove aquela infraestrutura a motor. Para quinze mercados o bot mantém o calendário dos vencimentos e seleciona o contrato front com um limiar de dias configurável por instrumento; nas commodities físicas — ouro, prata, cobre, WTI, os grãos — o roll acontece taxativamente antes do first notice day, porque além daquela data o contrato deixa de ser uma exposição e vira uma entrega, e um retail não assina por barris. O roll é higiene de posição, não um sinal: não passa pela banda de não-trading, fecha o contrato velho e reabre com o mesmo tamanho e o mesmo sentido no novo. Com uma única exceção de bom senso: o plano de rebalanceamento se calcula antes do roll, e um instrumento que hoje vai de qualquer forma a zero não se rola — fecha-se diretamente no contrato em mãos, uma rodada de spread economizada.

Sob o roll vive a estrutura de dados que torna o sinal possível: as séries contínuas de retornos. Na troca de contrato concatenam-se os retornos — a variação do novo contrato sobre os seus próprios fechamentos — nunca os preços, para que o salto entre velho e novo não entre no sinal e a série meça o que uma posição rolada teria de fato rendido. É o detalhe contábil sobre o qual se apoia todo o resto; errá-lo produz trends fantasmas no roll de cada vencimento, e nenhum gráfico rio abaixo perceberia.

Os guardrails da perna#

O que impede quinze mercados de virarem quinze maneiras diferentes de se machucar? Os guardrails globais do bot — o portão de margem com o what-if, o teto diário de ordens, o circuit breaker sobre o valor da conta, o kill switch — valem para a CTA sem isenções, e os caps dedicados da perna só podem apertar, nunca alargar.

O orçamento de risco, em volatilidade. Cada instrumento tem o seu orçamento (cerca de 2% do capital da perna), cada setor um teto sobre a exposição agregada — a defesa contra a falsa diversificação de uma carteira que parece ampla e é toda uma aposta na energia — e a perna inteira um cap total definido em volatilidade: a soma das vols anualizadas em dólares das posições não supera metade do capital da perna. A definição em vol não é pedantismo: um contrato de Treasuries de dois anos tem um nocional enorme e um risco minúsculo, e um teto sobre o nocional o puniria pelo motivo errado; o teto em vol mede a mesma grandeza com que as posições são dimensionadas, e permanece idêntico se um dia o tamanho dos contratos passar de micro a standard.

O freio de drawdown. Se o P&L da perna cai mais de 15% desde o seu máximo, os orçamentos são cortados pela metade até o drawdown voltar para menos de metade do limiar. É uma regra escrita antes de partir, com um único sentido possível — reduzir — e serve para tirar de mim mesmo a decisão mais perigosa do ofício: aquela tomada no meio de um drawdown, com o histórico dos CTAs fracassados a testemunhar como isso termina.

O vol targeting. Acima de tudo, o multiplicador de carteira da página CTA trend following: vol realizada da perna acima do alvo de 10% → tamanhos para baixo, abaixo → tamanhos para cima, com um teto de 1,5 e um piso de 0,5. É o único automatismo “de regime” concedido pelo design, porque não tem parâmetros livres e só pode amortecer.

Um ano simulado da perna: quando a volatilidade realizada (acima) sobe além do alvo, o multiplicador de alavancagem (abaixo) desce em proporção, até o piso; o teto de 1,5 impede a euforia oposta nos regimes plácidos. De-risking sem parâmetros e sem opiniões. Números ilustrativos.

O kill switch, sem exceções. Vale a pena declará-lo porque a escolha não é óbvia: com o kill switch ativo o bot CTA não coloca nenhuma ordem, nem mesmo as que reduziriam o risco. As posições continuam cobertas pelos caps e o kill é um evento de operador, não de algoritmo; um sistema que se concede exceções “prudentes” à própria parada de emergência tem uma parada de emergência de papel.

Falhar com elegância#

E quando algo quebra? A escala multi-mercado desloca o centro de gravidade das falhas: o risco característico deste bot não é a ordem errada, mas a contabilidade errada. Com três estratégias que mantêm futuros na mesma conta, cada posição precisa ter um dono: o registro interno atribui cada contrato à sua estratégia, e a exclusão de ES e MES do universo CTA — decisão de design, não de gosto — faz com que em cada símbolo da perna o único dono possível seja a própria perna. Toda manhã o bot reconcilia o registro com as posições reais da corretora, símbolo por símbolo: um desvio não explicado produz um alerta crítico e a suspensão das novas ordens naquele símbolo até a discrepância ser entendida — nunca operar sobre um inventário no qual não se confia, que é o Princípio 4 aplicado à escala. Da mesma família é o controle dos metadados: multiplicador e tick de cada contrato declarados na configuração são verificados a cada inicialização contra os da corretora, porque dimensionar uma posição sobre um multiplicador errado é o jeito mais estúpido de perder dinheiro com um sistema no resto correto.

As outras falhas degradam com elegância por construção. A ordem não executada é cancelada e tentada de novo amanhã, como já dito: nenhum estado intermediário a guardar. O ciclo pulado — Gateway fora do ar, casa às escuras — deixa as posições de ontem com a banda servindo de amortecedor, e amanhã se recomeça dos dados atualizados: para um sinal mensal é tracking error, não emergência. O bot parado ou em standby deixa as posições de futuros abertas e não geridas, como as GTC da TRPS: está escrito no runbook, e a resposta no caso extremo sou eu pelo aplicativo, num mercado cotado quase 24 horas. E uma vez por mês, na primeira segunda-feira, chega-me por e-mail a prestação de contas da perna: retorno do mês, do ano e desde o início da atividade, comissões reais contra o orçamento de fricções, margem estimada contra a verdadeira da conta — a série que me diz, com a cadência certa para um sinal lento, se a realidade está respeitando o projeto.

O que continua manual, aqui mais do que em qualquer outro lugar: o universo. Acrescentar ou tirar um mercado, mover um instrumento para desativação (fechamentos permitidos, aberturas não), mudar o tamanho dos contratos — são decisões de prancheta com dupla confirmação, não automatismos; o bot executa a configuração, não a discute. A divisão do trabalho é a de sempre: o sistema faz a constância, eu faço os (poucos) julgamentos — e depois da experiência dos outros dois bots posso dizer que é a constância, não o julgamento, a parte que eu não sabia que não tinha.

O roll, porém, merece mais do que os dois parágrafos que lhe dediquei aqui: as datas que contam de verdade, a janela para onde vai a liquidez, a escada de emergência e o custo real de cada volta. É a página Futures rollover.