O stop de Marcus dispara a US$ 98. Três segundos somam US$ 160 à perda.

Um stop define o preço que dispara uma saída, mas não garante execução naquele preço. Entre a cotação tocar US$ 98 e a ordem chegar ao mercado, três segundos de latência podem transformar uma perda planejada em mais US$ 160 de prejuízo.

Marcus é um personagem composto, criado para ilustrar esse risco. Às 10h17, diante de dois monitores em um apartamento em Curitiba, ele segurava uma caneca de café já frio quando o preço encostou em US$ 98. O bot deveria encerrar a posição. A tela continuou mostrando a operação aberta.

Um segundo. Dois. Três.

Quando a ordem finalmente saiu, a perda havia aumentado US$ 160. Naquele intervalo, Marcus não sabia se perderia mais alguns dólares ou se uma queda rápida atravessaria o livro de ofertas antes da execução. O stop existia. A proteção que ele esperava, naquele instante, não.

O que aconteceu em cada segundo

No instante inicial, a fonte de preços registrou uma negociação a US$ 98. Esse evento ainda precisava percorrer uma cadeia: chegar ao sistema, ser processado pela regra do bot, gerar uma ordem, passar pelas verificações da corretora e alcançar o mercado.

No primeiro segundo, o preço recebido pelo bot podia estar atrasado em relação ao mercado. Uma conexão congestionada, uma atualização enviada em intervalos ou uma fila interna de mensagens já seria suficiente para consumir parte desse tempo.

No segundo seguinte, a regra de saída foi avaliada. O sistema confirmou que o preço havia atingido o stop e preparou a ordem. Mesmo uma lógica simples disputa recursos com registros, cálculos e outras tarefas quando a infraestrutura está sob carga.

No terceiro segundo, a ordem seguiu para a corretora. Ainda faltava aceitação, roteamento e correspondência com uma oferta disponível. Nesse ponto, US$ 98 era um registro do passado. A execução dependia do preço e da liquidez existentes quando a ordem chegasse.

Os US$ 160 adicionais deste exemplo não representam uma taxa de latência nem um resultado típico. Eles mostram a diferença entre o risco calculado com base no gatilho e o resultado obtido no mercado.

Stop acionado não significa preço garantido

Marcus havia calculado a operação como se o stop em US$ 98 fosse uma parede. Na prática, era um alarme. O alarme dizia “saia agora”, mas não reservava compradores naquele preço.

Uma ordem a mercado prioriza a saída, aceitando os preços disponíveis. Em um movimento rápido ou com pouca liquidez, isso pode gerar slippage. Uma ordem limitada controla o pior preço aceito, mas pode ficar sem execução enquanto a posição continua aberta.

Essa escolha precisa ser feita antes da entrada. Quando a queda já começou, trocar o tipo de ordem, alterar o stop ou clicar repetidamente costuma substituir um risco conhecido por uma decisão improvisada.

A velocidade também muda conforme o caminho percorrido pela ordem. Dados de mercado, servidor do bot, conexão, API da corretora e ambiente de execução formam uma corrente. Medir apenas o tempo entre o clique e a confirmação esconde onde o atraso nasceu.

Como dimensionar uma posição para a execução real

Depois daquela manhã, Marcus mudou a pergunta. Em vez de “quanto perco se o preço tocar US$ 98?”, passou a calcular “quanto posso perder se a execução ocorrer abaixo de US$ 98?”.

Esse ajuste começa com três números: preço de entrada, stop planejado e slippage admissível no cenário de estresse. O tamanho da posição deve caber no risco total, incluindo custos e uma execução pior que a cotação de gatilho.

Também vale registrar quatro horários separados no diário de trading:

1. quando o mercado atingiu o preço de stop;
2. quando o sistema recebeu essa atualização;
3. quando a ordem foi criada;
4. quando a corretora confirmou a execução.

A diferença entre esses registros revela se o atraso veio dos dados, da decisão, do envio ou do preenchimento. Sem essa separação, “o bot demorou” continua sendo uma conclusão vaga, impossível de corrigir.

O mesmo princípio aparece em A coluna vermelha do diário de trading e a velocidade que a colocou ali: velocidade sem contexto pode esconder uma falha de processo.

O controle começa antes do gatilho

Uma etapa de aprovação humana ajuda a impedir que uma automação execute decisões sem supervisão. Ela também acrescenta tempo. Em estratégias que dependem de milissegundos, essa pausa pode tornar a abordagem incompatível com o mercado escolhido.

A resposta não é fingir que a latência desapareceu. É definir quais decisões exigem aprovação, quais condições invalidam a operação e quanto atraso a estratégia suporta. Backtests também precisam refletir slippage, custos e atrasos plausíveis. Um teste que executa sempre no preço exato do stop descreve uma mecânica que o mercado não deve ao trader.

Marcus terminou o dia com uma linha vermelha de US$ 160 além do planejado. Na sessão seguinte, havia algo diferente na mesa: ao lado da caneca, um registro com quatro horários e um limite de risco calculado para uma saída imperfeita. O stop continuava sendo necessário. A ilusão de preço garantido havia saído do plano.

Conteúdo educacional, não constitui aconselhamento financeiro.