Um backtest de mercado de previsão pode usar um ticker aparentemente certo, o histórico de preços certo e o contrato errado. É fácil não detetar esse erro: os nomes dos mercados são curtos, as páginas dos eventos são atualizadas e uma participação YES parece sempre ter um preço entre zero e um.
Consideremos um mercado hipotético com o título «A Lei dos Transportes Limpos será aprovada?». Uma estratégia compra YES a 0.42 após um sinal noticioso. Mais tarde, o backtest avalia a posição em 1.00. Antes de confiar nesse ganho, quero saber exatamente o que o contrato prometia: de que lei se tratava, o que contava como «aprovação», qual era o prazo e que fonte determinou o resultado.
O título: «A Lei dos Transportes Limpos será aprovada?»
Um título é uma cadeia de texto para apresentação, não um identificador estável do instrumento. Dois mercados podem ter uma formulação quase igual e referir-se a legislaturas diferentes, a projetos de lei alterados ou a prazos distintos. Uma plataforma também pode alterar um título para tornar o mercado mais claro sem mudar os termos subjacentes.
Por isso, o backtest deve associar a posição ao ID imutável do mercado ou contrato da plataforma e guardar o texto integral das regras e a respetiva versão. Se os dados históricos contiverem apenas um título e um ticker, não é possível confirmar que a série de preços corresponde ao contrato que a estratégia pretendia negociar.
| Campo de identificação | O que identifica | Falha se for omitido |
|---|---|---|
| Plataforma e ID do mercado | O mercado específico cotado | Títulos semelhantes são agrupados |
| Versão das regras | Os termos aceites pelos participantes | Uma alteração posterior é aplicada a negociações anteriores |
| ID do token de resultado | A posição YES ou NO negociada | Os preços YES e NO são trocados ou combinados |
| Fonte de resolução | A prova usada para determinar o resultado | O backtest pressupõe uma autoridade diferente |
As regras: o que significa «aprovação»?
Suponhamos que as regras exigem que a lei seja aprovada pela Câmara dos Representantes e pelo Senado até 30 de junho e, depois, assinada pelo presidente. Um backtest que considere suficiente a aprovação por qualquer uma das câmaras alterou a aposta. O mesmo acontece se contar uma lei com o mesmo nome na legislatura seguinte.
Leia os critérios efetivos de resolução como condições executáveis. Registe o prazo e o fuso horário, o evento que conta, quaisquer exceções e a fonte de resolução indicada. A ambiguidade também importa: se as regras da plataforma não resolverem um cenário plausível, não escolha discretamente a interpretação que coincide com o resultado histórico.
Há uma parte pouco glamorosa, mas essencial, deste trabalho: guardar a página das regras antes de acontecer algo interessante. Uma página capturada apenas após a resolução pode mostrar a redação final, embora a estratégia tenha entrado com uma versão anterior.
A cronologia: quando é que a estratégia podia saber?
Suponhamos agora que as regras são sólidas e que o sinal noticioso foi ativado às 14:05 UTC. O feed histórico indica uma negociação às 14:05, ao preço de 0.42. Só esse carimbo temporal não permite saber se a informação estava disponível antes da negociação, se o preço registado era executável depois desse momento ou se a barra representa uma cotação, uma negociação ou um resumo do intervalo.
Mantenha separado o momento em que o sinal ficou disponível e o momento do evento de mercado. Depois, coloque a ordem apenas quando a estratégia já a podia calcular e enviar. Num mercado com pouca liquidez, a negociação registada seguinte pode ocorrer minutos depois; isso não prova que a sua ordem teria sido executada àquele preço.
O preço: uma cotação não é uma execução
Um preço YES de 0.42 equivale a 42 cêntimos por participação, mas uma série de últimas negociações oculta o spread e a quantidade disponível. Se a melhor oferta de venda for 0.45 para 20 participações, uma compra simulada de 100 participações não pode ser executada na totalidade a 0.42. A ordem pode consumir vários níveis do livro, ficar à espera ou não ser executada.
Os preços dos mercados de previsão também convidam a um atalho contabilístico: tratar 0.42 como uma probabilidade de 42% e esquecer que esse é também o montante pago na entrada. Uma posição de 100 participações YES custa $42 antes das comissões. Se liquidar a $1, o valor bruto recebido é $100; se liquidar a $0, é zero. As comissões, as execuções parciais e quaisquer mecanismos de liquidação específicos da plataforma devem constar do registo.
A liquidação: o que encerra a negociação?
Muitas vezes, um backtest encerra a posição ao preço final de mercado. Mas um contrato mantido até à resolução paga de acordo com as regras, e a última cotação pode estar desatualizada, ter um spread elevado ou ficar longe do pagamento final. Modele a resolução como um evento próprio: o resultado, o momento da liquidação e o movimento de dinheiro devem vir do registo do contrato.
Tenha também em conta um mercado cuja resolução seja inválida ou contestada, se as regras da plataforma definirem essa possibilidade. Nesse caso, a aposta pode ser devolvida, o pagamento pode ser diferente ou pode haver um atraso. O pressuposto de um pagamento binário não representa todos os percursos de resolução.
Conclusão sobre o backtest
Neste exemplo, só aceitaria o ganho comunicado depois de confirmar o ID imutável do mercado, a versão das regras em vigor no momento da entrada, o token YES, o momento em que o sinal ficou disponível, as ofertas de venda executáveis e respetivas quantidades, as comissões e a liquidação registada. Se o arquivo de preços não permitir estas verificações, o resultado honesto é um intervalo de cenários ou um resultado não verificado.
Pode parecer um critério exigente para uma única negociação pequena. Mas, se o mesmo erro de associação se repetir em milhares de mercados, o backtest pode acabar por medir cuidadosamente contratos que a estratégia nunca negociou.
← Todos os artigos
