O bug de tempo mais perigoso em um backtest pode passar até por uma auditoria perfeita dos timestamps. Dois eventos podem indicar 10:00:00.000 e, ainda assim, ter ocorrido em uma ordem que o simulador simplesmente presumiu.
Isso importa sempre que uma estratégia reage a algo além de candles fechados: uma atualização de cotação, uma negociação, um aviso de funding, uma mudança no status da exchange ou a confirmação da própria ordem. Um timestamp informa quando um evento foi marcado. Talvez não informe quando sua estratégia poderia agir com base nele.
O que muda com a ordenação dos eventos?
Imagine uma estratégia que compra quando o melhor ask cai abaixo de $100.00. No mesmo milissegundo, o feed registra uma atualização do ask para $99.99 e uma negociação a $99.99. Se o backtest processar primeiro a negociação e depois a cotação, a estratégia verá o novo ask e enviará uma ordem. Processar primeiro a cotação também pode funcionar, desde que o evento já estivesse disponível. Mas, se a negociação consumiu a liquidez exibida antes de a ordem chegar, um fill a $99.99 é ficção.
Ordenar as linhas apenas pelo timestamp deixa o simulador escolher uma sequência para os eventos empatados. A ordem no arquivo, a ordem dos símbolos ou o plano de execução de uma consulta ao banco de dados podem virar regras de execução acidentais. A curva de patrimônio pode mudar mesmo sem nenhuma alteração nos dados subjacentes.
Há uma maneira simples de ver como isso pode ser arbitrário: ordenar eventos com o mesmo horário pelo nome do símbolo, em vez de pela sequência de chegada. Uma estratégia com vários ativos pode então se comportar de outra forma simplesmente porque um ticker vem antes de outro na ordenação.
Quais relógios um backtest deve manter?
Dados de mercado e processamento de ordens costumam envolver vários horários distintos. Mantenha os campos fornecidos pela sua fonte e defina com precisão o que cada um significa. Em muitos feeds, o timestamp da exchange e o timestamp de recebimento local são úteis; nenhum deles representa uma verdade universal sobre o que todos os participantes viram.
| Relógio | O que registra | O que não pode comprovar sozinho |
|---|---|---|
| Horário do evento na exchange | Quando a plataforma diz que o evento ocorreu | A ordem em que outro feed ou seu processo o observou |
| Horário de recebimento | Quando seu coletor recebeu a mensagem | Quando sua estratégia terminou de processá-la |
| Horário da decisão | Quando seu código avaliou o sinal | Que o preço cotado continuava disponível |
| Horário de chegada da ordem | Quando a plataforma poderia agir sobre a ordem | Um fill, a menos que as regras de matching e a liquidez o permitam |
Para dados históricos sem horários de recebimento, deixe claras as suas premissas. Um backtest pode processar os eventos da exchange em sequência e aplicar um atraso fixo de 5 ms entre a decisão e a chegada da ordem. Isso é um modelo, não um registro histórico recuperado. Se você não tem números de sequência para timestamps empatados da exchange, a regra usada para desempatar também é uma premissa.
Como devo modelar eventos empatados?
Primeiro, preserve os números de sequência da fonte quando existirem. Um número de sequência define uma ordem mais confiável dentro do feed do que um timestamp, embora os espaços de sequência possam ser separados entre canais ou produtos.
Depois, deixe explícita a regra de processamento do simulador. Para cada evento, decida se ele pode atualizar as informações da estratégia, alterar a liquidez disponível, disparar uma ordem ou confirmar uma ordem. São ações diferentes; juntá-las em “processar linha” é como fills impossíveis acabam entrando na simulação.
- Aplique apenas informações de mercado que tenham chegado até o horário da decisão da estratégia.
- Gere a ordem e, em seguida, avance até o horário estimado de chegada dela à plataforma.
- Permita a execução apenas contra liquidez elegível após a chegada, de acordo com as premissas de fill para aquele tipo de ordem.
- Registre as entradas, a ordenação dos eventos e o atraso usado em cada fill simulado.
Para uma estratégia baseada em candles, isso pode ser mais complexidade do que a pergunta exige. Se o sinal usa candles de 1 minuto já fechados e as ordens são executadas na abertura do candle seguinte com um modelo de custos conservador, a ordenação em submilissegundos provavelmente não mudará a conclusão da pesquisa. O importante é adequar o nível de detalhe temporal à afirmação que o backtest faz.
Posso confiar em um backtest sem dados do horário de chegada?
Você ainda pode usá-lo, mas deixe essa limitação visível. Se a estratégia opera devagar e tem limites de risco amplos, alguns milissegundos podem ser irrelevantes. Se ela reage a cotações efêmeras, compete por posição na fila ou depende de um sinal de lead-lag entre exchanges, a falta dos horários de chegada pode ser central para o resultado.
Os críticos têm razão ao dizer que a precisão dos horários dos eventos pode criar uma falsa sensação de exatidão. Os feeds históricos são incompletos, os relógios sofrem desvios e os timestamps das plataformas não revelam cada salto pela rede. Um simulador com campos em nanossegundos ainda pode usar uma premissa de fill rudimentar.
Por isso, teste a sensibilidade em vez de alegar certeza: reproduza a simulação com critérios plausíveis para desempatar eventos e atrasos de ordens, depois compare a quantidade de trades, o preço dos fills e quais sinais continuam funcionando. Se o resultado depender de uma sequência que os dados não permitem estabelecer, essa dependência deve constar no relatório da pesquisa. Um backtest pode ser útil mesmo com um relógio imperfeito. Ele só precisa reconhecer quais horários realmente conhece.
← Todos os artigos
