O erro de temporização mais perigoso num backtest pode passar despercebido mesmo após uma auditoria perfeita dos timestamps. Dois eventos podem indicar ambos 10:00:00.000 e, ainda assim, ter ocorrido numa ordem que o seu simulador adivinhou.
Isto importa sempre que uma estratégia reage a algo mais do que barras concluídas: uma atualização de cotação, uma transação, um aviso de funding, uma alteração do estado da exchange ou a confirmação da própria ordem. Um timestamp indica quando um evento está marcado. Pode não indicar quando a sua estratégia podia agir com base nele.
O que muda com a ordenação dos eventos?
Imagine uma estratégia que compra quando o melhor ask desce abaixo de $100.00. No mesmo milissegundo, o feed regista uma atualização do ask para $99.99 e uma transação a $99.99. Se o backtest processar primeiro a transação e depois a cotação, a estratégia vê o novo ask e envia uma ordem. Processar primeiro a cotação também pode estar certo, desde que o evento estivesse realmente disponível. Mas, se a transação consumiu a liquidez apresentada antes de a ordem chegar, uma execução a $99.99 é fictícia.
Ordenar linhas apenas pelo timestamp deixa o simulador escolher uma sequência para os eventos empatados. A ordem no ficheiro, a ordem dos símbolos ou o plano de execução de uma consulta à base de dados podem tornar-se, por acaso, regras de execução. A curva de capital pode mudar mesmo que os dados subjacentes não tenham mudado.
Há uma forma simples de perceber como isto pode ser arbitrário: ordenar eventos com a mesma hora pelo nome do símbolo, em vez de pela sequência de chegada. Assim, uma estratégia com vários ativos pode comportar-se de forma diferente só porque um ticker aparece antes de outro na ordenação.
Que relógios deve um backtest manter?
Os dados de mercado e o processamento de ordens envolvem muitas vezes vários momentos distintos. Mantenha os campos que a sua fonte fornece e defina com precisão o que significam. Em muitos feeds, tanto o timestamp da exchange como o timestamp de receção local são úteis; nenhum deles representa uma verdade universal sobre o que todos os participantes viram.
| Relógio | O que regista | O que não consegue provar por si só |
|---|---|---|
| Hora do evento na exchange | Quando a plataforma diz que o evento ocorreu | A ordem em que outro feed ou o seu processo o observou |
| Hora de receção | Quando o seu coletor recebeu a mensagem | Quando a sua estratégia terminou de a processar |
| Hora da decisão | Quando o seu código avaliou o sinal | Que o preço cotado continuava disponível |
| Hora de chegada da ordem | Quando a plataforma podia atuar sobre a ordem | Uma execução, a menos que as regras de matching e a liquidez a permitam |
Se os dados históricos não incluírem horas de receção, indique o que assume. Um backtest pode processar os eventos da exchange por ordem e aplicar um atraso fixo de 5 ms entre a decisão e a chegada da ordem à plataforma. Isso é um modelo, não um registo histórico recuperado. Se não tiver números de sequência para timestamps coincidentes da exchange, a regra que usar para desempatar também é uma suposição.
Como devo modelar eventos empatados?
Primeiro, preserve os números de sequência da fonte, quando existirem. Um número de sequência permite estabelecer uma ordem mais fiável dentro do feed do que um timestamp, embora os espaços de sequência possam ser diferentes entre canais ou produtos.
Depois, torne explícita a regra de processamento do simulador. Para cada evento, decida se pode atualizar a informação da estratégia, alterar a liquidez disponível, acionar uma ordem ou confirmar uma ordem. São ações distintas; reduzi-las a «processar linha» é como se infiltram execuções impossíveis.
- Aplique apenas informação de mercado que tenha chegado até à hora da decisão da estratégia.
- Gere a ordem e, em seguida, avance até à hora modelada de chegada à plataforma.
- Permita a execução apenas contra liquidez elegível após a chegada, segundo os pressupostos de execução para esse tipo de ordem.
- Registe os dados de entrada, a ordenação dos eventos e o atraso usados em cada execução simulada.
Para uma estratégia baseada em barras, isto pode ser mais complexidade do que a pergunta exige. Se o sinal usar barras de 1 minuto já concluídas e as ordens forem executadas na abertura da barra seguinte com um modelo de custos conservador, é pouco provável que a ordenação submilissegundo altere a conclusão da investigação. O importante é adequar o detalhe temporal à afirmação que o backtest faz.
Posso confiar num backtest sem dados sobre a hora de chegada?
Pode continuar a usá-lo, mas deixe clara essa limitação. Se a estratégia negociar devagar e tiver limites de risco amplos, alguns milissegundos podem ser irrelevantes. Se reagir a cotações fugazes, competir por posição na fila ou depender de um sinal de lead-lag entre exchanges, a falta de dados sobre a hora de chegada pode ser determinante para o resultado.
Os críticos têm razão ao dizer que a precisão temporal dos eventos pode criar uma falsa sensação de exatidão. Os feeds históricos são incompletos, os relógios desviam-se e os timestamps das plataformas não revelam cada salto na rede. Um simulador com campos em nanossegundos pode continuar a usar um pressuposto de execução grosseiro.
Por isso, teste a sensibilidade em vez de alegar certeza: reproduza a simulação com critérios plausíveis para desempatar eventos e com vários atrasos de ordem; depois, compare o número de transações, o preço de execução e os sinais que se mantêm. Se o resultado depender de uma sequência que os dados não permitem determinar, essa dependência deve constar do relatório de investigação. Um backtest pode ser útil mesmo com um relógio imperfeito. Só tem de reconhecer que horas consegue realmente conhecer.
← Todos os artigos
