O backtest foi aprovado. A estratégia em paper perdeu 37% das ordens.

Nosso backtest contabilizou 91 execuções entre 100 ordens enviadas. No paper trading, a mesma estratégia conseguiu 63. O tempo mediano entre o sinal e a confirmação de recebimento da ordem foi de 84 milissegundos, e 12 das execuções que faltaram no paper eram ordens limitadas que o backtest presumiu executadas assim que o preço as tocou.

Essa diferença de 28 pontos parecia um problema da estratégia até separarmos as decisões de envio das ordens das decisões de execução. A estratégia escolheu praticamente o mesmo lado, tamanho e preço nas duas execuções. O caminho de execução foi diferente: algumas ordens chegaram atrasadas, outras continuaram abertas e algumas cruzaram um mercado que já havia se movido.

O que significa paridade de ordens entre backtest e paper?

Paridade significa que o backtest e o sistema em paper tomam decisões comparáveis com base nas mesmas informações disponíveis e, em seguida, contabilizam explicitamente os diferentes modelos de execução. Isso não significa que toda execução simulada deva corresponder a uma execução em paper. Barras históricas não permitem reconstruir a posição na fila, e uma plataforma de paper pode usar um modelo de matching diferente do de uma exchange ao vivo.

A pergunta útil é mais específica: para cada ordem que a estratégia pretendia enviar, você consegue explicar o que aconteceu em seguida? A contagem de trades e o retorno final escondem detalhes demais. Mantenha um registro vinculado para cada decisão, com um ID estável da decisão da estratégia que acompanhe os eventos de sinal, ordem, confirmação, cancelamento e execução.

Por que as ordens limitadas tocadas explicaram tantas execuções ausentes?

Nosso backtest usava candles de 1 minuto. Se o preço limite ficasse dentro da faixa entre a máxima e a mínima de um candle, ele marcava a ordem como executada. Essa regra responde se o mercado negociou naquele preço em algum momento durante o minuto. Ela não responde se nossa ordem já estava ativa, se era a primeira na fila ou se houve volume suficiente depois da chegada dela.

Os logs de paper revelaram o problema de timing. A estratégia calculou um sinal às 12:03:00.000, mas o evento de dados de mercado chegou ao processo de ordens 31 milissegundos depois. As verificações de risco levaram mais 22 milissegundos, e o simulador da plataforma confirmou o recebimento da ordem 31 milissegundos depois disso. Em um movimento rápido, uma barra histórica pode fazer um preço parecer alcançável, mesmo que a ordem limitada tenha chegado depois que o mercado já o havia deixado para trás.

Havia outro complicador: 12 ordens em paper ainda estavam abertas quando o backtest já havia seguido adiante. O simulador aceitava uma solicitação de cancelamento como se a ordem desaparecesse imediatamente. No sistema em paper, a confirmação do cancelamento chegava depois; 3 ordens foram executadas nesse intervalo. Isso alterou a posição considerada pelo sinal seguinte.

Como medir a diferença sem me enganar?

Comece com um relatório simples de conciliação, agrupado por intenção da ordem. Deixe o denominador visível. “Taxa de execução” pode significar execuções por ordem enviada, quantidade executada dividida pela quantidade solicitada ou ordens executadas divididas pelas ordens que chegaram à plataforma. Cada métrica responde a uma pergunta diferente.

1. Vincule os eventos usando um ID de decisão ou de ordem do cliente, não um horário estimado depois do ocorrido.
2. Compare primeiro as decisões: horário do sinal, lado, quantidade solicitada, tipo de ordem e preço limite.
3. Para decisões correspondentes, compare o atraso até a confirmação, as rejeições, o tempo em aberto, o horário do cancelamento, a quantidade executada e o preço médio de execução ponderado por volume.
4. Informe as taxas por tipo de ordem e condição de mercado. Uma taxa geral de execução de 63% pode esconder 90% para ordens a mercado e 35% para ordens limitadas passivas.

Mantenha as categorias claramente separadas. Uma ordem rejeitada não é uma ordem sem execução; uma ordem parcialmente executada não é uma execução total; e uma ordem cancelada depois de uma execução parcial ainda alterou a posição. Conte tanto o número de ordens quanto a quantidade solicitada para que um grupo de ordens pequenas não faça o resultado parecer melhor do que é.

O que deve mudar no backtest?

Use uma regra de execução compatível com a resolução dos dados e o comportamento pretendido da ordem. Com candles, tocar o preço limite é indício de uma possível execução, não prova. Você pode modelar execuções parciais de forma conservadora, exigir que o preço ultrapasse o limite ou excluir ordens passivas cuja posição na fila não possa ser estimada. Cada escolha responde a uma pergunta diferente; documente-a e compare o resultado com mais de uma regra plausível.

Modele também o estado da ordem. Ela continua ativa até que o sistema receba um evento terminal, e uma solicitação de cancelamento não elimina a exposição. Se a estratégia puder enviar uma segunda ordem enquanto a primeira estiver pendente, o backtest precisa representar essa corrida ou impedi-la por projeto.

Um modelo de execução afirma o que sua ordem poderia ter feito. Defina uma regra que você consiga explicar e depois compare-a com os logs de paper.

Na nossa diferença de 28 pontos, o mais surpreendente não foi o backtest com candles de 1 minuto superestimar as execuções passivas. Foi a posição da estratégia divergir antes da decisão seguinte porque o timing dos cancelamentos havia sido omitido. Depois que corrigimos o modelo de estado das ordens e deixamos de tratar toda ordem limitada tocada como executada, a comparação com paper ficou menos favorável, mas mais útil.

Esse é o critério prático de paridade: toda diferença relevante entre o comportamento simulado e o comportamento em paper tem uma causa registrada, e o backtest não afirma ter certeza quando os dados não permitem isso.