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, escrito com IA, em um mini PC doméstico chinês headless? Esta seção é a resposta longa à brincadeira. Quatro 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 duas estratégias são low frequency por construção — dez minutos por dia a TRPS, um rito de fim de tarde a DHCS — 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 e O bot DHCS 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). Nenhuma das duas 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.

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.