EXECUÇÃO#

Na página introdutória eu tinha fechado com uma brincadeira: o que poderia dar errado ao deixar uma conta de trading real ser operada por um bot que vende puts na margem e rola futuros em seis setores, escrito com IA, em um mini PC doméstico chinês headless? Esta seção é a resposta longa à brincadeira. Seis páginas em que desço do plano das estratégias para o dos cabos, dos logs e das ordens que saem às 16:01, horário de Nova York, enquanto eu, no meu fuso sul-americano, estou fazendo outra coisa completamente diferente. É a seção mais pessoal do site — descrevo o meu setup, não o setup — e também a mais perecível: hardware, bibliotecas e API envelhecem mais rápido que os prêmios de risco. Os princípios, porém, não, e são os princípios que quero fixar antes dos detalhes.

Por que automatizar (e por que não)#

Começo pelo equívoco a desmontar: o bot não serve para ganhar mais. As três estratégias são low frequency por construção — dez minutos por dia a TRPS, um rito de fim de tarde a DHCS, um ciclo de meio de manhã a CTA — e nenhum milissegundo a menos de latência acrescenta um centavo de alfa: o edge (página Edge) é um prêmio pelo risco carregado, não pela velocidade. O bot serve para três coisas diferentes.

Primeiro: codificar a disciplina. Escrevi isso na página TRPS: o assassino de longo prazo da TRPS não é o crash, é a tentação de “otimizar” — o strike um pouco mais próximo depois de um mês bom, o contrato a mais depois de um trimestre tranquilo. Um bot executa a regra escrita, idêntica, na noite do dia 1 e na noite do dia 1.000, inclusive na noite seguinte a um stop engolido, quando a versão humana de mim iria querer “recuperar”. A automação é a ergodicidade (página Ergodicidade) aplicada à psicologia: remove o operador da cadeia das decisões repetitivas, que é exatamente o ponto em que o operador quebra as estratégias.

Segundo: cobrir horários incômodos. A janela crítica da TRPS — os 15 minutos depois do fechamento da NYSE, a montagem da guarda noturna logo depois do fill, a troca de guarda meia hora depois da abertura — cai quando cai, feriados americanos e compromissos meus incluídos. Um processo que precisa acontecer 252 vezes por ano em horário fixo é a definição operacional de “trabalho de máquina”.

Terceiro: produzir um arquivo. Cada ordem, cada fill, cada rejeição da corretora acaba num journal em banco de dados: é a matéria-prima do PCR (página Medidas de risco), do painel de risco semanal e, não menos importante, da declaração de imposto de renda. A versão manual desse arquivo se chama “eu faço no fim de semana” e dura três semanas.

E o porquê não, igualmente honesto: a automação converte risco psicológico em risco operacional. O bot não entra em pânico, mas pode travar às 16:02 com metade das ordens enviadas; não corre atrás das perdas, mas executa ao pé da letra um bug. A página Risk management já dizia: o bot é um funcionário júnior com acesso à conta — vigilância, limites rígidos, kill switch. No meu sistema a coleira tem a forma de um canal de mensagens bidirecional (página Setup): cada operação executada pelos bots de trading chega ao celular em tempo real, e do celular um comando pode pará-los no mesmo instante — o funcionário júnior trabalha com o chefe na linha, sempre. Esta seção é, em grande parte, o manual de como se vigia esse funcionário.

Há ainda um risco que a automação cria do nada e que precisa ser nomeado logo: a segurança. Uma máquina sempre ligada com uma sessão autenticada na minha conta é um alvo, e a superfície de ataque precisa ser reduzida com a mesma seriedade com que se dimensiona a alavancagem. As regras que sigo: nenhuma porta aberta para a internet no roteador de casa; a API da corretora restrita a aceitar conexões apenas da máquina local; as credenciais nunca no código, mas num cofre criptografado, e de todo modo um usuário de API que não pode sacar fundos — a separação entre “pode operar” e “pode tocar no dinheiro” é a versão informática da distinção entre perda e ruína da página Ergodicidade; atualizações de segurança automáticas e nada mais automático; e a disciplina mais banal e mais negligenciada, a autenticação em dois fatores em tudo o que importa. Um atacante que entre no mini PC pode, no pior dos casos, me fazer vender puts mal por uma noite; não deve poder fazer mais que isso.

Os quatro princípios de projeto#

Todo o desenho que segue decorre de quatro princípios. Eu os enuncio aqui porque nas páginas O bot TRPS, O bot DHCS e O bot CTA você vai encontrá-los aplicados em toda parte, e porque valem seja qual for o seu stack.

Princípio 1: os servidores da corretora são parte do sistema. A intuição mais importante da seção inteira: as ordens stop-limit (página TRPS) não vivem no mini PC — uma vez transmitidas, residem nos servidores da IBKR e são executadas mesmo que a minha casa esteja às escuras, o roteador torrado e o bot morto. O projeto correto explora esse fato até o fim: o bot coloca as proteções primeiro, e a partir desse momento a sua sobrevivência se torna desejável, mas não necessária. A parte crítica do sistema roda num datacenter com uma redundância que eu jamais poderia pagar; o mini PC é só o secretário que entrega os envelopes.

Princípio 2: fail-static, não fail-operational. Não pretendo que o sistema continue operando durante uma falha (isso custa o que custa uma infraestrutura de hedge fund): pretendo que uma falha o deixe num estado seguro sem nenhuma ação adicional. E é aqui que a escolha das estratégias paga duas vezes: uma TRPS com o bot morto é um conjunto de puts 1DTE com a sua guarda noturna já nos servidores de corretora e bolsa, que no máximo expiram sem valor no dia seguinte; uma DHCS que pula um rebalanceamento acumula um pouco de tracking error, não uma catástrofe (página O bot DHCS); e uma perna CTA que perde um ciclo simplesmente mantém as posições de ontem, o que para um sinal de frequência quase mensal é a própria definição de fail-static — dos três bots é o mais indiferente à própria ausência (página O bot CTA). Nenhuma das três exige que o bot esteja vivo para estar segura. Compare com uma estratégia intradiária que precisa fechar as posições até o fim do pregão: lá um crash do processo é uma emergência; aqui é um aborrecimento.

Princípio 3: o humano é o backup, e precisa ser equipado. Quando o fail-static não basta — o gap noturno com posições abertas, a ordem parcialmente executada, a margem gritando — a última linha sou eu com o aplicativo móvel da IBKR, que fala diretamente com os servidores da corretora passando por cima de toda a minha infraestrutura doméstica. Mas para intervir é preciso saber, e aqui entra o canal de notificação: cada fill, cada rejeição, cada mudança de estado me alcança no celular no momento em que acontece, e o mesmo canal aceita comandos na outra direção — consultar o estado, ou desligar o bot. O runbook da página Risk management aqui se torna literal: uma página plastificada com os casos (bot mudo há N minutos, posição órfã, stop executado a um preço absurdo) e as ações, escrita com o mar calmo.

Princípio 4: a verdade está na corretora, não no banco de dados. A cada inicialização e em horários fixos, o bot reconcilia: consulta a IBKR sobre posições e ordens reais e as compara com o próprio journal. Toda discrepância congela a operação e me avisa — nunca, em nenhum caso, o bot “corrige” sozinho uma diferença que não entende. O journal é a memória; a corretora é a realidade; quando divergem, decide o humano.

A hierarquia das responsabilidades: as proteções vivem na corretora, a rotina no mini PC, e o humano — equipado — pode passar por cima de tudo falando diretamente com os servidores da IBKR. Esse único princípio elimina a classe de incidentes mais insidiosa da automação retail: o bot convencido de ter posições que não tem (ou o contrário) que “arruma” as coisas dobrando o dano.

O que continua manual#

Nem tudo se automatiza, e a linha de fronteira é conceitual, não técnica. Automatiza-se o que é regra: a rotina diária da TRPS (seleção do strike a prêmio fixo, envio, stop), o rebalanceamento e o roll da DHCS, a vigilância, o journaling. Continua manual o que é julgamento: a perna tática das puts compradas com VIX alto (página TRPS), discricionária por natureza; a decisão da manhã seguinte a uma noite em que a guarda de futuros disparou — fechar puts e futuros juntos ou manter o hedge até o vencimento — que o bot sinaliza com uma notificação crítica e nunca toma sozinho (página O bot TRPS); toda mudança de alavancagem ou de parâmetros, que passa por um arquivo de configuração versionado e nunca por uma ideia das 23:40; e toda intervenção sobre as exceções apontadas pela reconciliação. A regra que me dei: o bot só pode fazer menos do que o previsto (pular uma venda se uma condição de segurança não for satisfeita), nunca mais. A assimetria é proposital: uma oportunidade perdida custa 15 centavos por contrato; uma iniciativa a mais pode custar a conta.

O mapa da seção#

A página Setup descreve o setup: a conta e as permissões do lado da corretora, o hardware (o mini PC embedded, o nobreak, a rede com failover), o software de base (sistema operacional, IB Gateway e o seu domador IBC, a biblioteca de API, os serviços de vigilância) e uma nota sobre dados de mercado e a parte fiscal do journal. A página O bot TRPS é a arquitetura do bot TRPS: uma máquina de estados que vive no fuso de Nova York, com a reconciliação das 9:25, a troca de guarda das 10:00, a janela de venda das 16:00, a guarda noturna nas suas duas variantes — recompra condicionada e hedge com futuros — e os seus modos de falhar com elegância. A página O bot DHCS é o bot DHCS: mais simples no ritmo (um único compromisso no fim do dia), mais delicado na matemática (de onde você tira o delta, quando rebalanceia, como arredonda os Micro), e estruturalmente mais tolerante a falhas — a comparação entre os dois é também uma comparação entre filosofias de automação, e fecha a conversa aberta na página TRPS vs DHCS. A página O bot CTA é o bot da terceira estratégia: um ciclo por dia no meio da manhã sobre uns quinze futuros, o calendário dos rolls multi-mercado, a contabilidade das posições de três estratégias e os guardrails da perna trend — o mais tranquilo dos três no ritmo, e o que tem mais mercados para vigiar. A página Futures rollover é dedicada ao roll: os quatro regimes de liquidação e as datas que contam de verdade, a janela para onde migra a liquidez, a escada de emergência do bot e quanto custa cada volta — com a tabela dos contratos lado a lado.

Uma última advertência, a mesma da página Estratégias, mas ao quadrado: tudo o que segue se testa em paper trading por meses, na conta simulada que a IBKR fornece exatamente para isso, antes que um único contrato de verdade saia de um script. O paper não testa o edge — esse ficou estabelecido nas seções Derivativos e Estratégias — testa você e o seu código: os timeouts, os fusos, os feriados, os erros do Gateway às 16:01. É o período de experiência do funcionário júnior. Começo pelo escritório que construí em volta dele.