O backtest passou. A estratégia em paper falhou 37% das ordens.

O nosso backtest contou 91 execuções em 100 ordens enviadas. Em paper trading, a mesma estratégia obteve 63. O tempo mediano entre o sinal e a confirmação de receção da ordem foi de 84 milissegundos, e 12 das ordens em paper sem execução eram ordens limitadas que o backtest assumiu executadas assim que o preço lhes tocou.

Essa diferença de 28 pontos parecia um problema da estratégia até separarmos as decisões de ordem das decisões de execução. A estratégia escolheu praticamente o mesmo lado, dimensão e preço nas duas execuções. O percurso de execução foi diferente: algumas ordens chegaram tarde, outras ficaram em aberto e outras cruzaram um mercado que já se tinha 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 na mesma informação disponível e, depois, contabilizam explicitamente os diferentes modelos de execução. Não significa que cada execução simulada tenha de corresponder a uma execução em paper. As barras históricas não permitem reconstruir a posição na fila, e uma plataforma de paper pode usar um modelo de correspondência diferente do de uma exchange real.

A pergunta útil é mais específica: para cada ordem que a estratégia pretendia colocar, consegue explicar o que aconteceu a seguir? O número de transações e o retorno final escondem demasiada informação. Mantenha um registo associado a cada decisão, com um ID de decisão da estratégia estável que acompanhe os eventos de sinal, ordem, confirmação de receção, cancelamento e execução.

Porque é que os limites tocados explicaram tantas ordens sem execução?

O nosso backtest usava barras de um minuto. Se o preço limite estivesse dentro do intervalo entre o máximo e o mínimo de uma barra, marcava a ordem como executada. Essa regra indica se o mercado negociou a esse preço em algum momento durante o minuto. Não indica se a nossa ordem já estava ativa, se ocupava o primeiro lugar na fila ou se houve volume suficiente negociado depois de a ordem chegar.

Os registos 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 só chegou ao processo de ordens 31 milissegundos depois. As verificações de risco demoraram mais 22 milissegundos e o simulador da plataforma confirmou a receção da ordem 31 milissegundos depois disso. Num movimento rápido, uma barra histórica pode fazer um preço parecer alcançável, mesmo que o limite só tenha chegado depois de o mercado já o ter ultrapassado.

Havia ainda outra complicação: doze ordens em paper continuavam abertas quando o backtest já tinha avançado. O simulador aceitava um pedido de cancelamento como se a ordem tivesse desaparecido imediatamente. No sistema em paper, a confirmação do cancelamento chegava mais tarde; três ordens foram executadas nesse intervalo. Isso alterou a posição que o sinal seguinte encontrou.

Como posso medir a diferença sem me enganar?

Comece por um pequeno relatório de reconciliação, agrupado por intenção da ordem. Mantenha o denominador visível. «Taxa de execução» pode significar execuções por ordem enviada, quantidade executada dividida pela quantidade pedida ou ordens executadas divididas pelas ordens que chegaram à plataforma. Cada medida responde a uma pergunta diferente.

1. Associe os eventos através de um ID de decisão ou de ordem do cliente, não de um timestamp estimado posteriormente.
2. Comece por comparar as decisões: hora do sinal, lado, quantidade pedida, tipo de ordem e preço limite.
3. Para decisões coincidentes, compare o atraso na confirmação de receção, as rejeições, o tempo em aberto, a hora do cancelamento, a quantidade executada e o preço de execução ponderado pelo volume.
4. Apresente as taxas por tipo de ordem e condição de mercado. Uma taxa de execução global de 63% pode esconder 90% nas ordens a mercado e 35% nos limites passivos.

Mantenha as categorias bem distintas. Uma ordem rejeitada não é uma ordem não executada; uma ordem parcialmente executada não é uma execução total; e uma ordem cancelada depois de uma execução parcial já alterou a posição. Conte tanto as ordens como a quantidade pedida, para que um conjunto 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 com o comportamento pretendido da ordem. Com barras, um limite tocado é indício de uma possível execução, não prova de que ocorreu. 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 seja possível estimar. Cada opção responde a uma pergunta diferente; documente-a e compare o resultado com mais do que uma regra plausível.

Modele também o estado da ordem. Uma ordem continua ativa até o sistema receber um evento terminal, e um pedido de cancelamento não elimina a exposição. Se a estratégia puder enviar uma segunda ordem enquanto a primeira está pendente, o backtest tem de representar essa condição de corrida ou impedi-la por conceção.

Um modelo de execução é uma afirmação sobre o que a sua ordem poderia ter feito. Defina uma regra que consiga explicar e, depois, confronte-a com os registos de paper.

Na nossa diferença de 28 pontos, o mais surpreendente não foi o backtest com barras de um minuto sobrestimar as execuções passivas. Foi a posição da estratégia divergir antes da decisão seguinte porque o timing dos cancelamentos tinha sido omitido. Depois de corrigirmos o modelo de estado das ordens e deixarmos de tratar cada limite tocado como uma execução, a comparação com paper tornou-se menos lisonjeira e mais útil.

Esse é o critério prático de paridade: cada diferença relevante entre o comportamento simulado e o comportamento em paper tem uma causa registada, e o backtest não afirma ter certezas que os seus dados não podem sustentar.