O que fazer quando o bot envia uma ordem que você não reconhece?

Às 6h12, a tela mostra uma ordem que você não reconhece. O primeiro passo é bloquear novas execuções e preservar todos os registros disponíveis. Pausar reduz a chance de ampliar a perda; manter logs, sinais, parâmetros e horários permite descobrir o que aconteceu sem apagar a evidência.

A reação instintiva costuma ser abrir configurações, corrigir regras e reiniciar o sistema. Isso altera justamente o ambiente que precisa ser examinado. Antes de procurar a causa, preserve o estado encontrado.

Quando cada nova ordem aumenta o problema

Em 1º de agosto de 2012, a Knight Capital começou a enviar ordens erradas ao mercado acionário dos Estados Unidos. Segundo a ordem administrativa publicada pela Securities and Exchange Commission, a empresa havia implantado um novo código em seus servidores, mas um deles ficou sem a atualização correta.

Um componente antigo voltou a funcionar. Durante aproximadamente 45 minutos, o sistema enviou milhões de ordens e acumulou posições indesejadas. Quando a Knight conseguiu interromper a atividade, o prejuízo superava US$ 460 milhões. Thomas Joyce, então CEO da empresa, conduziu uma organização cuja sobrevivência passou a depender de financiamento emergencial.

O caso ficou conhecido pelo tamanho da perda, mas a lição operacional começa antes do valor final. Enquanto o sistema continuava executando, o problema também continuava mudando. Cada ordem acrescentava exposição, dados e novas consequências. Diagnosticar com o mecanismo ainda ativo era tentar medir um vazamento enquanto a torneira permanecia aberta.

Um bot de varejo opera em outra escala, mas a sequência correta é a mesma: interromper a capacidade de criar novas posições, preservar o que já aconteceu e só então investigar.

O que deve permanecer intacto depois da pausa

Pausar novas execuções não significa encerrar posições às pressas ou apagar ordens pendentes sem avaliação. Cada ação pode alterar risco, preço médio, margem ou o material necessário para reconstruir a falha.

Comece registrando o estado da conta:

• posições abertas, tamanho e preço médio;
• ordens abertas, rejeitadas, canceladas e executadas;
• horário de cada evento;
• saldo, margem e exposição por ativo;
• estratégia, versão e parâmetros ativos;
• sinal produzido e dados usados na decisão;
• resposta da corretora ou da bolsa;
• alterações recentes em código, credenciais ou configuração.

Exporte o que puder antes de editar. Faça capturas das telas relevantes. Registre os horários com o fuso indicado. Se houver identificadores de ordens, preserve-os. Uma anotação como “o bot comprou errado” não permite separar falha de estratégia, erro de integração, duplicação de ordem ou intervenção humana.

O histórico também impede que a memória reorganize os fatos depois do susto. Às 6h12, uma ordem pode parecer inexplicável. Às 9h, depois de três alterações nas configurações, já não existe certeza sobre qual regra estava ativa no momento da execução.

O registro que faltava em 347 operações mostra o custo dessa lacuna: sem contexto suficiente, uma sequência de resultados não explica quais decisões produziram cada resultado.

Investigue em uma cópia, não na conta ativa

Com novas execuções bloqueadas, reconstrua a cadeia completa:

1. Qual dado entrou?
2. Qual regra foi acionada?
3. Qual sinal foi produzido?
4. Houve aprovação humana?
5. Qual ordem foi enviada?
6. O que a corretora confirmou?
7. O estado interno foi atualizado corretamente?

Teste hipóteses em ambiente separado, com uma cópia das configurações e dos dados preservados. Alterar uma variável por vez ajuda a distinguir causa de coincidência. Se a falha não puder ser reproduzida, isso precisa constar no diagnóstico.

O reinício exige critérios definidos antes do teste. Por exemplo: nenhuma ordem pode sair sem aprovação; ordens repetidas devem ser recusadas; limites de posição precisam ser verificados antes do envio; perda de conexão deve bloquear a execução. Um único teste bem-sucedido não demonstra que o problema desapareceu.

Uma arquitetura com aprovação humana cria uma barreira adicional. A IA pode gerar e enfileirar uma proposta, mas a decisão final permanece com a pessoa. Essa barreira perde valor quando a aprovação vira reflexo. Antes de aceitar qualquer ordem, confira exposição total, tamanho da posição, stop planejado e impacto no limite de risco. O caso em que Caio pausou o bot após a segunda posição ilustra por que o risco precisa ser observado no conjunto da conta.

A evidência é parte do controle

A Knight Capital não perdeu centenas de milhões porque faltava velocidade de execução. O sistema já era rápido. Faltaram controles de implantação, verificação e interrupção capazes de limitar o alcance de uma falha, como registrou a SEC.

Para o trader, controle significa conseguir responder quem autorizou uma ordem, qual regra a produziu e qual exposição existia naquele instante. Se essas respostas desaparecem após uma alteração ou reinício, a conta pode voltar a operar, mas o problema continua sem diagnóstico.

Às 6h12, a prioridade não é recuperar a sensação de normalidade. É impedir a próxima ordem, preservar o estado encontrado e reconstruir a sequência com fatos. Só depois disso existe base para decidir se o sistema pode voltar.

Conteúdo educacional, não constitui recomendação financeira.