O bot DHCS (Delta-Hedged Convexity Selling)#
Se o bot TRPS vive de janelas de quinze minutos, o bot DHCS tem um único compromisso por dia, mas contas que precisam bater até a casa decimal. A estratégia da página DHCS — puts front-month ATM/−1σ, delta-hedge diário com futuros Micro, roll mensal — traduz-se numa arquitetura mais curta e mais relaxada que a da página O bot TRPS, e a diferença entre os dois bots é, ela mesma, instrutiva: replica, no plano do software, o confronto entre as duas estratégias da página TRPS vs DHCS. Aqui também, todos os horários em America/New_York.
O rito das 15:45#
O coração do bot é um único job de fim de tarde, entre as 15:45 e as 16:00, quando opções e futuros estão ambos líquidos e os preços de fechamento já são representativos. A sequência, na ordem inegociável aprendida na página O bot TRPS: reconciliação (posições e ordens contra o journal, dados frescos, margem), depois a decisão, depois a execução, depois a escrita.
O cálculo do delta. É a etapa matematicamente delicada, e merece o detalhe. O delta da posição em opções pode vir de duas fontes: os greeks de modelo que a API da IBKR fornece com as cotações, ou um cálculo próprio (Black-Scholes com a IV corrente do strike). O bot faz as duas coisas e as compara: a fonte primária são os greeks da corretora — coerentes com o que o sistema de margem enxerga — mas o cálculo independente serve de sanity check, porque os greeks via API têm os seus momentos de fragilidade (valores ausentes ou claramente defasados nos minutos convulsos). Se as duas estimativas divergem além de uma tolerância, ou se uma delas falta, o bot não rebalanceia e notifica: melhor uma noite de hedge levemente sujo do que um ajuste baseado num número inventado. Aqui volta também a sutileza da página DHCS: à cobertura nominal pode-se somar o corretivo para o beta implícito (vega·∂IV/∂S) — no meu caso um simples fator multiplicativo configurável, modesto por padrão, porque precisão decimal sobre um resíduo estimado é elegância desperdiçada.
A banda de rebalanceamento. Calculado o delta da posição em opções e subtraído o da cobertura existente (número de MES vendidos × o delta unitário deles), sobra o descoberto. O bot não o zera a qualquer custo: rebalanceia só se o descoberto exceder uma banda — em delta (ex.: ±0,05 por contrato SPX equivalente) ou, de forma equivalente, em nocional. A banda é o compromisso da página DHCS entre precisão e custos tornado explícito: dentro da banda, o descoberto é ruído de média zero que não vale o spread de uma ordem; fora, ajusta-se. A granularidade dos MES (5 dólares por ponto, página Futuros) torna a aritmética gentil: o número de contratos corretivos é o descoberto em dólares dividido por (5 × nível do índice), arredondado — e o erro máximo de arredondamento, meio Micro, é por construção menor que a banda. Com o ES de 50 dólares por ponto a mesma aritmética produziria ajustes em degraus grosseiros: é por isso que o Micro não é um quebra-galho para contas pequenas, mas a ferramenta certa do ofício.
Um ciclo mensal simulado: o delta descoberto (azul) vagueia dentro da banda até o gamma empurrá-lo para fora; cada seta vermelha é uma ordem MES que o traz de volta a zero. Dentro da banda, o spread economizado vale mais que a precisão.
A execução. As ordens sobre os MES são limit agressivas perto do mid (o book dos Micro nas horas do mercado à vista é profundo e o spread, mínimo); o caso patológico do fill que não chega em poucos minutos degrada para ordem a mercado, porque aqui — ao contrário dos 15 centavos da TRPS — a economia do tick individual é desprezível diante do custo de ficar descoberto. Cada execução atualiza o journal com o novo estado da cobertura, e o resumo do fim do dia registra a decomposição do P&L do dia nas suas componentes estimadas — theta recebido, custo de gamma realizado (½·gamma·ΔS²), efeito vega — que é o painel com que se entende por que a estratégia está ganhando ou perdendo, não só quanto (página DHCS).
O roll mensal#
A 7-10 dias do vencimento (parâmetro configurado), o job de fim de tarde acrescenta um passo: fechar a put corrente, abrir a do mês seguinte no strike que corresponde ao delta alvo (−0,25/−0,40, página DHCS) e recalcular do zero a cobertura. Três notas de implementação. Primeira, a ordem das pernas: fecha-se a put velha antes de abrir a nova — por alguns minutos a carteira fica sobrecoberta (os futuros vendidos permanecem), que é o desequilíbrio na direção prudente; nunca o contrário. Segunda, o sizing se recalcula a cada roll sobre o valor corrente da conta e sobre o orçamento de estresse da página DHCS (a perda simulada no cenário extremo não deve exceder a fração configurada): é o momento natural em que a estratégia se readapta ao capital, sem nunca fazê-lo no meio do ciclo. Terceira, o roll é também a ocasião do controle de regime: o bot registra IV corrente, estrutura a termo e prêmio recebido, alimentando a série histórica com que verifico que a tarifa continua pagando o risco (o termômetro IV/RV das páginas Volatility risk premium e Edge).
Por que este bot pode se dar ao luxo de ser preguiçoso#
Antes do confronto, uma nota sobre como se escolhe a banda — o único parâmetro realmente “ajustável” do bot e, portanto, o único em que vale a pena investir método. O caminho certo não é a otimização no backtest (página Medidas de risco: os parâmetros mágicos são overfitting à espera de se manifestar), mas o replay: reproduzem-se as séries históricas diárias de índice e IV sobre o código de produção — o mesmíssimo código, não uma imitação dele — e mede-se, para bandas diferentes, o trade-off entre custos de transação acumulados e volatilidade do tracking. A curva que sai é plana num intervalo amplo: entre 0,03 e 0,08 de delta muda pouco, abaixo pagam-se spreads à toa, acima o ruído residual começa a pesar. A parte plana é a notícia: onde a curva é plana, a escolha é robusta, e pega-se um valor central e não se mexe mais nele. O replay serve também de teste geral: fazê-lo atravessar o março de 2020 e o agosto de 2024 simulados revela mais bugs que seis meses de paper tranquilo.
O confronto com a página O bot TRPS é o ponto conceitual da página. O bot TRPS tem compromissos críticos: se perde a janela das 16:00, perde o dia; se perde a troca de guarda das 10:00, deixa as posições só com a guarda noturna além do turno dela. O bot DHCS não: se o job de fim de tarde falha — Gateway fora do ar, casa às escuras, bug — a consequência é que a cobertura continua a de ontem, e o descoberto acumulado é o gamma de um dia a mais: tracking error, não emergência (página DHCS: o intervalo entre rebalanceamentos já está no desenho da estratégia). A posição em opções, a 20-30 dias do vencimento, tem um gamma modesto; os stops não são necessários porque o delta está coberto; e o mercado de futuros fica aberto quase 24 horas, então no caso extremo o ajuste faço eu pelo aplicativo a qualquer momento (Princípio 3). Em termos de projeto: o bot TRPS precisa ser pontual, o bot DHCS precisa ser exato — e a exatidão, ao contrário da pontualidade, tolera o adiamento. Disso decorre uma arquitetura sem máquina de estados: um único job idempotente disparado pelo systemd no horário estabelecido, que se falha tenta de novo mais tarde e, se falha de novo, notifica e desiste, sabendo que amanhã o cálculo do delta reabsorverá sozinho o atraso. A reconciliação do Princípio 4 continua sagrada — é o único verdadeiro pré-requisito de toda execução — mas o dead-man switch aqui pode se permitir limiares relaxados: um ping por dia, não um a cada passo.
Os cenários feios, por completude. O fill parcial no roll (fechada a put velha, a nova não executada): o bot permanece no estado sobrecoberto prudente e tenta de novo a abertura no dia seguinte — perde-se um dia de theta, não se acrescenta risco. O vega spike no meio da semana (página DHCS): o bot não tem, de propósito, nenhuma lógica de reação automática — nenhum stop no VIX, nenhuma redução de emergência — porque toda regra de de-risking reativo que testei vendia nas máximas de volatilidade o que devia ser mantido até a normalização; o spike é absorvido pelo sizing feito de antemão sobre o orçamento de estresse, e a eventual decisão extraordinária cabe ao humano, informado por uma notificação no celular quando a perda mark-to-market supera um limiar (o canal, comandos de estado e de parada incluídos, é o mesmo compartilhado com o bot TRPS: páginas Setup e O bot TRPS). E o cenário de margem: aqui também o what-if faz de portão de controle para cada ordem, mas a posição delta-hedged tem a propriedade agradável (página TRPS vs DHCS) de o requisito permanecer relativamente estável justamente porque os futuros compensam as opções nos cenários do modelo — o bot DHCS, na prática, nunca viu uma rejeição por margem em condições em que o TRPS patinava.