Um backtest de opções pode mudar sem que uma linha do código da estratégia seja alterada. Um fornecedor corrige uma cotação incorreta, adiciona uma negociação atrasada, revisa os metadados de um contrato ou muda o filtro para mercados cruzados. Você executa novamente as mesmas datas e obtém um preenchimento diferente, uma posição diferente, talvez um Sharpe diferente. Isso não significa necessariamente que haja um bug na estratégia. Significa que mudou a evidência usada para testá-la.
Para tornar reproduzível um backtest de opções, trate os dados de mercado como uma entrada versionada. Registre qual snapshot você usou, preserve as observações brutas que orientaram cada decisão e compare os resultados alterados no nível do contrato e do timestamp antes de confiar no agregado atualizado.
Por que meu backtest de opções mudou se o código permaneceu igual?
Os registros de opções são especialmente sensíveis a correções porque a aparente possibilidade de negociar um contrato depende de vários campos em conjunto: 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 oportunidade aparente em um 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 está abaixo de $2.00. No primeiro carregamento dos dados, a cotação das 10:14 tem ask de $1.95, bid de $1.90 e quantidade 5. Uma revisão posterior do fornecedor altera o ask para $2.05 após reconciliar uma mensagem atrasada da bolsa. Uma única observação inverte o sinal. Se aquele contrato foi a única operação da estratégia naquele dia, uma correção modesta nos dados pode determinar o retorno do dia.
Os filtros de cotações também importam. Os fornecedores podem descartar cotações desatualizadas, remover mercados cruzados ou normalizar timestamps de outra maneira. Essas 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 é a versão exata das observações históricas disponível para uma determinada execução de pesquisa. Mantenha o nome do fornecedor e do conjunto de dados, o horário de recuperação, o intervalo de datas, a versão do esquema e todas as regras de limpeza ou filtragem. Se o fornecedor disponibilizar IDs de snapshot ou timestamps de revisão, salve-os também.
Para cada decisão simulada, mantenha informações de linhagem suficientes para responder: qual contrato foi considerado, qual cotação foi selecionada, quando essa cotação foi publicada ou recebida e qual regra a tornou elegível? Tanto o registro bruto quanto o 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.
| Registro a preservar | Por que importa | Exemplo |
|---|---|---|
| Snapshot de origem | Identifica o histórico usado na execução | ID da revisão do fornecedor e timestamp de recuperação |
| Procedência da cotação | Explica qual mercado foi selecionado | Bolsa, horário do evento, horário de recebimento, 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 quais observações foram excluídas | Limite de desatualização e tratamento de cotações cruzadas |
Como verifico se uma revisão do fornecedor alterou 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 os preenchimentos: quais sinais surgiram ou desapareceram, qual cotação mudou e se o novo registro alterou o preço de execução modelado.
Não se limite ao retorno total. Acompanhe mudanças no número de operações, nos preços de entrada e saída, nos sinais rejeitados e na proporção do P&L gerada por operações que existem em apenas uma versão dos dados. Uma execução pode manter um Sharpe parecido enquanto operações individuais são substituídas; a estatística principal não revela que o histórico por trás dela mudou.
Para uma auditoria útil, mantenha fixos a estratégia, as taxas e as premissas de execução. Se várias coisas mudarem ao mesmo tempo, você não saberá se a divergência veio da correção do fornecedor ou do seu próprio experimento.
Devo sempre usar o histórico de opções mais recente?
Use o histórico mais recente quando o objetivo for trabalhar com a melhor reconstrução atual do fornecedor. Guarde o snapshot antigo quando precisar reproduzir um resultado anterior ou entender o que seu sistema de pesquisa sabia na época. Essas versões respondem a perguntas diferentes.
Em pesquisas point-in-time, um registro corrigido pode ser mais preciso hoje e ainda assim não estar disponível para a estratégia naquela época. Preserve os horários de publicação e recebimento sempre que possível; caso contrário, deixe a limitação explícita. Uma reconstrução moderna não corresponde automaticamente ao conjunto de informações disponível no passado.
Quando um backtest de opções muda, a primeira pergunta deve ser “Quais observações mudaram?” A pergunta “Qual execução está certa?” vem depois que você puder responder à primeira.
O que devo salvar com cada backtest?
Salve um manifesto compacto junto aos resultados: provedor de dados e snapshot, horário de recuperação, versões do esquema e da limpeza, fonte dos metadados dos contratos, commit da estratégia, premissas de execução e configuração da execução. Mantenha um vínculo entre cada operação e os registros de cotação que a justificaram.
Esse pequeno registro transforma uma nova execução misteriosa em uma comparação que você pode inspecionar. O histórico de opções continuará sendo corrigido. Seu processo de pesquisa deve deixar cada correção visível, para que um arquivo melhor aprimore as evidências sem reescrever silenciosamente o experimento.
← Todos os artigos
