Setup (corretora, margem, produtos)#

Esta página é a lista de materiais do sistema: o que é preciso, por que exatamente aquilo, e onde estão os pontos de ruptura. Divido-a em três camadas: a conta na corretora, o hardware em casa, e o software que roda em cima. Aviso logo: é a página que vai envelhecer mais rápido do site inteiro — os modelos e preços citados valem hoje — mas os critérios de escolha permanecem.

A conta: corretora, margem, produtos#

A corretora de referência para estas estratégias é a Interactive Brokers, por três razões inegociáveis: é das poucas que concedem ao retail o portfolio margin e a venda de opções naked sobre índice; tem uma API documentada e madura sobre a qual construir; e aplica margens e taxas entre as mais competitivas do mercado. A conta se configura assim: tipo IBKR Pro (o plano Lite não tem API), regime portfolio margin — que exige um patrimônio mínimo de 110.000 dólares e um questionário de experiência (página Capital efficiency) — e permissões de trading em opções no nível que autoriza as vendas descobertas, mais futuros e opções sobre futuros se você quiser os ES/MES para coberturas (páginas Futuros e O bot DHCS). Os produtos a habilitar: opções sobre índices americanos (para as SPX/SPXW) e futuros CME. É preciso ainda a assinatura dos dados de mercado em tempo real: o pacote OPRA para as opções e os dados CME para os futuros — poucos dólares por mês, muitas vezes zerados pelas comissões geradas, e indispensáveis: um bot que decide sobre dados atrasados 15 minutos é um bot que vende strikes errados. Por fim, dois cuidados de segurança: a lista de IPs confiáveis para as sessões de API, e sobretudo a conta paper gêmea, que a IBKR fornece de graça e que é o ambiente onde o bot viverá os seus primeiros meses (página Execução).

Uma nota sobre a margem que retoma a página Capital efficiency, mas em chave operacional: a API expõe a função what-if, que devolve o impacto de margem de uma ordem antes de enviá-la. O bot a usa como portão de controle: nenhuma ordem sai se a margem pós-operação supera o limiar configurado (eu uso uma fração prudente da excess liquidity, porque — página Capital efficiency — o requisito dobra sozinho nos dias ruins). É o limite de alavancagem da página Ergodicidade transformado numa linha de código que não dá para esquecer.

O hardware: pequeno, dedicado, ao alcance da mão#

Primeira pergunta: por que um computador em casa e não um VPS em datacenter? Para estratégias low frequency a latência é irrelevante (Princípio 1: as ordens críticas descansam de todo modo nos servidores da corretora), então o VPS não compra velocidade; compra confiabilidade de energia e de rede, e a paga com uma mensalidade perpétua, com a gestão de chaves e credenciais da conta numa máquina alheia, e com um ambiente que você não pode tocar fisicamente quando algo trava de verdade. A minha escolha é a máquina doméstica dedicada — nada de usos duplos, nada de navegador, só o bot — com as fraquezas de casa (energia, internet) mitigadas uma a uma. É também a escolha mais econômica: o rack inteiro que descrevo custa o mesmo que um ano de um VPS decente. Não descarto migrar para um VPS no futuro, mas por enquanto me atenho ao princípio: “se não está quebrado, não conserte”.

O mini PC. O candidato que escolhi é o GMKtec NucBox G11, em torno de 250 euros: processador AMD Ryzen Embedded R2514 (quatro núcleos, oito threads), plataforma embedded pensada para uso industrial contínuo, porta Ethernet dupla de 2,5 Gb e consumo de lâmpada. Como processador é coisa datada — e está ótimo assim: o IB Gateway mais um processo Python que trabalha dez minutos por dia ocupam uma fração de uma máquina dessas, e o requisito de verdade não é a potência, mas a capacidade de ficar ligado 24/7 por anos sem drama. Único senão: tem uma ventoinha, ou seja, uma peça móvel que mais cedo ou mais tarde pode morrer — é a peça de reposição para ter na gaveta.

A alimentação. Um nobreak (UPS) a montante do mini PC e do roteador, conectado via USB ao mini PC com o daemon NUT (Network UPS Tools): assim o bot sabe que está na bateria, pode me avisar e, se a carga cair abaixo do limiar com posições abertas, executar o procedimento de desligamento limpo depois de escrever o estado no journal. Repare na coerência com o Princípio 2: o apagão com a TRPS em posição não é uma emergência — as proteções, sejam os stops diurnos ou a guarda noturna, já estão nos servidores de corretora e bolsa, ou eu as insiro pelo celular — mas o bot que morre sujo, no meio de uma escrita no banco de dados, é o tipo de falha que custa uma manhã de reconciliação.

A rede. É o verdadeiro single point of failure de toda a engenhoca, e merece o maior gasto: conexão primária de fibra mais um failover LTE/5G (roteador com chip de dados que assume sozinho), porque a janela das 16:00 não espera o técnico. E uma regra de segurança inegociável: nenhuma porta aberta para a internet no roteador de casa, para não expor a máquina.

A lista do rack: saída dupla para a internet, nobreak monitorado via NUT, o canal de mensagens bidirecional para o celular, e nenhuma porta aberta no roteador.

O software: poucas peças, bem vigiadas#

A camada de software, de baixo para cima: Ubuntu Server estável, headless, atualizações de segurança automáticas e nada mais que se atualize sozinho. IB Gateway, a versão sem interface da plataforma da IBKR que expõe a API: é o componente mais caprichoso do sistema inteiro — sessões que expiram, reinicializações semanais obrigatórias, janelas de autenticação — e por isso precisa ser domado com o IBC, o utilitário que gerencia o seu login automático e as suas reinicializações programadas. A regra prática: a reinicialização noturna do Gateway se agenda num horário em que por construção nada acontece (para a TRPS, o início da tarde de Nova York, longe tanto da abertura quanto da janela do fim do dia). Acima do Gateway, o bot propriamente dito: Python com a biblioteca ib_async (a evolução comunitária da histórica ib_insync), que encapsula a API num modelo de eventos limpo. O estado vive num banco de dados SQLite — o journal do Princípio 4: cada intenção escrita antes da ordem, cada desfecho depois, de modo que a cada reinicialização o bot saiba exatamente onde tinha parado. Tudo orquestrado pelo systemd: serviços com reinício automático, dependências explícitas (o bot só sobe se o Gateway responde), logs centralizados.

A vigilância é em camadas, da mais boba à mais paranoica: o watchdog do systemd que reinicia o processo morto; o controle interno do bot, que verifica a conexão ao Gateway e o frescor dos dados antes de cada ação; e o dead-man switch externo — um serviço como o healthchecks.io que espera um ping do bot a cada passo do dia e me manda uma notificação se o ping não chega. O ponto conceitual: a vigilância interna não pode anunciar a morte de quem a hospeda; é preciso sempre um observador fora da máquina.

A peça que liga tudo ao celular é o canal de mensagens, bidirecional por design. Na saída: cada operação executada pelos bots de trading — ordem enviada, fill recebido, stop disparado, roll completado, rebalanceamento MES, transição de estado, erro — vira uma mensagem no celular no instante em que acontece, com os números necessários para julgar (strike, prêmio, preço de execução, margem restante). Na entrada: pelo mesmo canal dou comandos — o comando de estado devolve posições, ordens vivas e o último heartbeat; o comando de parada é o kill switch: para a máquina de estados, cancela as ordens pendentes não protetivas e congela toda nova operação, deixando intocados os stops nos servidores da corretora (desligar o bot nunca deve significar desligar as proteções — é o Princípio 1 aplicado também à coleira); e só se retoma depois de uma reconciliação limpa. A implementação é banal (a API de um serviço de mensagens mais uma biblioteca Python; o processo de mensagens roda separado do bot de trading, assim sobrevive aos crashes dele e pode reportá-los), mas dois cuidados de segurança são obrigatórios: o bot responde somente ao meu usuário — qualquer outro que escreva é ignorado e registrado no log — e o conjunto de comandos respeita a assimetria da página Execução: do celular dá para parar, consultar, nunca abrir posições ou aumentar a size. O celular é um freio, não um acelerador.

Última implicância que vale ouro: o relógio. NTP ativo, e todo o agendamento expresso no fuso America/New_York, nunca em hora local — o meu país não observa o horário de verão, os Estados Unidos sim, e um bot que vende as 1DTE uma hora depois do fechamento duas vezes por ano é um bot demitido.