Um backtest de opções pode mudar sem que se altere uma única linha do código da estratégia. Um fornecedor corrige uma cotação errada, acrescenta uma transação comunicada com atraso, revê os metadados de um contrato ou altera o filtro para mercados cruzados. Volta a executar o backtest para as mesmas datas e obtém uma execução diferente, uma posição diferente, talvez um Sharpe diferente. Isso não significa necessariamente que haja um erro na estratégia. Significa que mudou a evidência com base na qual a estratégia foi testada.
Para tornar reproduzível um backtest de opções, trate os dados de mercado como uma entrada versionada. Registe o snapshot utilizado, preserve as observações em bruto que determinaram cada decisão e compare os resultados alterados ao nível do contrato e do timestamp antes de confiar no agregado mais recente.
Porque é que o meu backtest de opções mudou se o código se manteve igual?
Os registos de opções são especialmente sensíveis a correções, porque a aparente negociabilidade de um contrato depende de vários campos em simultâneo: bid, ask, quantidades, preço do ativo subjacente, vencimento, strike e multiplicador ou ativo entregável do contrato. Uma cotação corrigida pode transformar uma aparente oportunidade num mercado cruzado. Uma correção de metadados pode alterar o significado do multiplicador de uma posição.
Imagine uma estratégia que compra uma call quando o ask é inferior a $2.00. Na primeira carga de dados, a cotação das 10:14 apresenta ask de $1.95, bid de $1.90 e quantidade 5. Numa revisão posterior, o fornecedor altera o ask para $2.05, após reconciliar uma mensagem atrasada da bolsa. Uma observação faz o sinal inverter-se. Se esse contrato foi a única transação da estratégia nesse dia, uma pequena correção dos dados pode dominar o retorno diário.
Os filtros de cotações também importam. Os fornecedores podem eliminar cotações desatualizadas, remover mercados cruzados ou normalizar os timestamps de outra forma. Estas políticas podem fazer sentido, mas fazem parte da identidade do conjunto de dados. “Opções de SPY, de janeiro a março” não define um histórico reproduzível.
O que é uma versão dos dados de opções?
Uma versão dos dados é o conjunto exato de observações históricas disponível para determinada execução de investigação. Guarde o nome do fornecedor e do conjunto de dados, a hora de obtenção, o intervalo de datas, a versão do esquema e quaisquer regras de limpeza ou filtragem. Se o fornecedor disponibilizar IDs de snapshots ou timestamps de revisão, guarde-os também.
Para cada decisão simulada, conserve informação suficiente para responder a estas perguntas: que contrato foi considerado, que cotação foi selecionada, quando foi publicada ou recebida e que regra a tornou elegível? Tanto o registo em bruto como o registo derivado são importantes. Um NBBO limpo sem os timestamps de origem pode ocultar se uma cotação estava desatualizada ou chegou depois da decisão simulada.
| Registo a preservar | Por que é importante | Exemplo |
|---|---|---|
| Snapshot de origem | Identifica o histórico utilizado na execução | ID da revisão do fornecedor e timestamp de obtenção |
| Proveniência da cotação | Explica o mercado selecionado | Bolsa, hora do evento, hora de receção, bid/ask e quantidades |
| Termos do contrato | Define o que a opção representava | Strike, vencimento, multiplicador e ativo entregável |
| Política de limpeza | Mostra que observações foram excluídas | Limite de desatualização e tratamento de cotações cruzadas |
Como posso verificar se uma revisão do fornecedor alterou os meus resultados?
Execute a mesma estratégia e configuração nos dois snapshots. Primeiro, compare por data o número de observações e contratos elegíveis. Depois, compare as decisões e execuções: que sinais surgiram ou desapareceram, que cotação mudou e se o novo registo alterou o preço de execução modelado.
Não se fique pelo retorno total. Acompanhe as alterações no número de transações, nos preços de entrada e saída, nos sinais rejeitados e na proporção dos ganhos e perdas provenientes de transações que existem apenas numa das versões. Uma execução pode manter um Sharpe semelhante enquanto transações individuais são substituídas; a estatística principal não lhe dirá que o histórico subjacente mudou.
Para uma auditoria útil, mantenha fixos a estratégia, as comissões e os pressupostos de execução. Se alterar várias coisas ao mesmo tempo, não saberá se a divergência se deveu à correção do fornecedor ou à sua própria experiência.
Devo usar sempre o histórico de opções mais recente?
Use o histórico mais recente quando o objetivo for trabalhar com a reconstrução atual mais completa do fornecedor. Guarde o snapshot antigo quando precisar de reproduzir um resultado anterior ou perceber que informação o seu sistema de investigação tinha na altura. São perguntas diferentes.
Na investigação point-in-time, um registo corrigido pode ser mais preciso agora e, ainda assim, não estar disponível para a estratégia naquela altura. Sempre que possível, preserve as horas de publicação e receção; caso contrário, indique claramente essa limitação. Uma reconstrução atual não corresponde automaticamente ao conjunto de informação histórico.
Quando um backtest de opções muda, a primeira pergunta deve ser: “Que observações mudaram?” A pergunta “Que execução está correta?” vem depois de conseguir responder à primeira.
O que devo guardar com cada backtest?
Guarde um manifesto conciso junto dos resultados: fornecedor e snapshot dos dados, hora de obtenção, versões do esquema e da limpeza, origem dos metadados dos contratos, commit da estratégia, pressupostos de execução e configuração da execução. Associe cada transação aos registos de cotações que a justificaram.
Este pequeno registo transforma uma nova execução misteriosa numa diferença que pode inspecionar. O histórico de opções continuará a ser corrigido. O seu processo de investigação deve tornar visível cada correção, para que um arquivo melhor aperfeiçoe a evidência sem reescrever silenciosamente a experiência.
← Todos os artigos
