O conselho habitual é: se quer um backtest fiável, obtenha dados tick. Acho que esse conselho está errado para a maioria das estratégias e que segui-lo costuma piorar o backtest, em vez de o melhorar. Não porque os dados tick sejam imprecisos — são os dados mais precisos que se podem obter —, mas porque a forma como a maioria das pessoas os usa substitui rigor por resolução, e não são a mesma coisa.
Eis como isto corre mal. Um investigador cria uma estratégia com barras de 1 minuto, obtém um Sharpe de que gosta, e alguém — um mentor, uma publicação num fórum, ou a dúvida persistente que sente — diz-lhe que o backtest não é fiável porque foi feito com barras. Então reconstrói todo o pipeline com dados tick: cada transação, cada atualização de cotação, com registo temporal ao microssegundo. O backtest fica mais lento, o código torna-se três vezes mais complexo e o Sharpe... mal se mexe, ou muda numa direção que ninguém consegue explicar. Mesmo assim, avançam com a estratégia, porque os dados tick parecem mais rigorosos, e a sensação de rigor não é o mesmo que rigor.
O que a resolução tick realmente permite
Os dados tick indicam a sequência e o preço de cada transação e, se pagar por isso, de cada atualização do livro de ordens. São informações reais. Permitem reconstruir a posição na fila, estimar a probabilidade de execução a um dado nível de preço e detetar seleção adversa — perceber se o mercado se move contra si logo após a execução hipotética. Tudo isto é crucial se o período de detenção se mede em segundos e a sua vantagem, em frações de tick.
Mas a maioria das estratégias que vemos na Stratmill — e a maioria das estratégias que os investigadores de retalho e semiprofissionais realmente executam — mantém posições durante minutos ou dias. Nesse horizonte, o que determina se o backtest é fiável não é ter modelado a 40.ª transação de um determinado minuto. É ter modelado o spread, a taxa de financiamento, a curva de slippage e o facto de a sua ordem limitada ficar atrás das ordens de outras pessoas na fila. Pode errar nos quatro aspetos usando dados tick e acertar em todos com barras de 1 minuto. Resolução e fiabilidade são dimensões independentes.
Este último número é o que as pessoas tendem a desvalorizar. Um backtest ao nível tick não é apenas «o mesmo backtest com mais linhas». Nas transações da maioria das exchanges, a ordem de chegada difere da ordem dos respetivos registos temporais na ingestão; podem ser corrigidas retroativamente, divididas por vários shards dos motores de correspondência e, em várias plataformas cujos dados ingerimos, ocasionalmente duplicadas ou perdidas por completo durante uma reconexão. Criar um pipeline tick realmente mais correto do que um pipeline de barras bem concebido, em vez de apenas mais granular, é um verdadeiro projeto de sistemas. A maioria das equipas não o faz. Aponta um backtester para o ficheiro tick de um fornecedor e dá o trabalho por concluído, o que significa trocar um conjunto conhecido e documentado de aproximações (OHLCV) por um conjunto desconhecido e não documentado (o que quer que a lógica de reconciliação tick do fornecedor faça num dia mau).
O ruído que está a comprar
Há um segundo custo que tem menos que ver com engenharia e mais com estatística. As transações individuais alternam entre o bid e o ask — é o bid-ask bounce, um efeito conhecido na literatura sobre microestrutura de mercado desde a década de 1980. Se o seu sinal opera numa escala inferior a alguns segundos, o backtesting com dados tick pode levá-lo a ver estrutura onde existe apenas o bounce. Vi um investigador descobrir um padrão de reversão à média belíssimo em dados transação a transação, que desapareceu assim que agregou os dados em barras de apenas 5 segundos, porque o padrão era o bounce.
Um quant que conheço — antigo profissional de market making, agora à frente de um pequeno portefólio de cripto — explicou-mo assim: «Os dados tick são uma lupa. Se a apontar para a sua vantagem, ótimo. Se a apontar para o seu ruído, vai passar seis meses a modelar lindamente o seu ruído.» Agora faz o backtest de quase tudo com barras de 1 segundo ou 1 minuto e só recorre a dados tick para responder à pergunta específica «esta ordem limitada teria sido realmente executada?». É uma questão de probabilidade de execução, não uma questão sobre o sinal.
Essa distinção é a abordagem certa, e é precisamente o que a maioria dos defensores dos dados tick ignora. Usá-los de forma fiável não significa executar toda a estratégia com eles: significa usá-los cirurgicamente para responder às 1 ou 2 perguntas a que os dados em barras não conseguem realmente responder.
Quando os críticos têm razão
Dito isto, há estratégias em que os dados tick são indispensáveis, e estaria a exagerar se fingisse o contrário. Se executa algo que se assemelha a market making — apresenta cotações de compra e venda, gere o inventário tick a tick e se preocupa com a sua posição na fila a um nível de preço específico —, os dados em barras não conseguem representar o seu problema. Toda a economia dessa estratégia acontece dentro do minuto, não ao longo de vários minutos. O mesmo se aplica à arbitragem estatística sensível à latência entre plataformas, em que a pergunta é literalmente «qual foi a transação primeiro?», e ao market making de opções com ordens de grande dimensão, em que alguns centos de milissegundos de seleção adversa após uma transação são determinantes. Nestes casos, fazer backtesting com barras não é uma simplificação, é um erro de categoria: não está a testar uma versão da sua estratégia com menor resolução, mas sim uma estratégia diferente que, por acaso, tem o mesmo nome da original.
| Horizonte da estratégia | O que os dados em barras ocultam | Dados tick necessários? |
|---|---|---|
| Market making / baseado na fila | Probabilidade de execução, seleção adversa, posição na fila | Sim — indispensáveis |
| Latência / arbitragem entre plataformas | Sequência das transações, qual plataforma se moveu primeiro | Sim |
| Momentum intradiário, reversão à média (minutos–horas) | Momento de execução dentro da barra, custo do spread | Só para responder à questão da probabilidade de execução, não à do sinal |
| Swing / vários dias, opções direcionais | Quase nada de relevante | Não — as barras são suficientes e muitas vezes mais claras |
A ideia não é dizer que «os dados tick são maus». É que recorrer a eles é muitas vezes uma forma de evitar uma pergunta mais difícil e menos vistosa: o meu modelo de custos está correto? Os meus pressupostos de execução estão certos? Esta ordem teria sido realmente executada, ou estou a presumir uma execução a um preço que o livro nunca me ofereceu de facto? É possível responder a estas perguntas com barras de 1 minuto ou até de 1 segundo, desde que tenha em conta a posição na fila e o spread. Os dados tick permitem respostas mais precisas, mas com um custo de engenharia várias vezes superior, e para estratégias em que essa precisão adicional não altera a conclusão. Invista o esforço adicional nos casos em que o horizonte realmente o exige e, nos restantes, dispense-o. É uma forma melhor de usar o tempo de uma equipa de investigação do que optar por defeito pelos dados mais granulares disponíveis só porque maior granularidade parece mais rigorosa.
← Todos os artigos


