Em palavras simples — Um dataset point-in-time mostra o que o sistema poderia conhecer naquele dia, não a versão corrigida que enxergamos hoje.
Dados point-in-time preservam a informação tal como estava disponível em cada decisão histórica. Eles distinguem a data a que o fato se refere, quando foi publicado, quando chegou ao sistema e qual versão foi usada. Sem essa distinção, revisões, composição atual do universo ou ajustes retrospectivos podem entrar no passado e melhorar artificialmente o backtest.
Quatro datas diferentes
| Data | Pergunta |
|---|---|
| Referência econômica | a qual período ou evento o valor se refere? |
| Publicação | quando a fonte o divulgou pela primeira vez? |
| Disponibilidade | quando o sistema o recebeu e conseguiu processá-lo? |
| Vintage ou versão | qual valor, inclusive revisão, estava válido naquela consulta? |
Um indicador macro de janeiro pode ser divulgado em fevereiro e revisado em março. Uma demonstração financeira encerra em dezembro, mas chega ao EDGAR depois. Usar o valor final com a data econômica antecipa informação. O mesmo vale para correções de trades, preços oficiais e classificações atualizadas.
Universo, identificadores e composição
Um universo histórico é uma função do tempo. Índices anunciam entradas e saídas, empresas mudam ticker, fundem-se, cindem-se ou deixam de negociar. Consultar hoje a lista de componentes e aplicá-la ao passado exclui antecipadamente instrumentos que fracassaram e inclui vencedores antes de sua entrada.
É preciso versionar critérios de elegibilidade, data do anúncio, data efetiva, identificadores permanentes e mapeamentos. O ticker isolado é frágil: pode ser reutilizado. A estratégia deve consultar a composição válida no timestamp da decisão e aplicar somente mudanças então conhecidas.
Eventos corporativos e delistings
Split, dividendo, direitos, fusão e spin-off possuem anúncio, ex-date, pagamento e efeito contábil distintos. Ajustar toda a série por eventos futuros pode ser adequado para calcular retornos, mas o preço ajustado não deve ser confundido com preço negociável ou informação conhecida.
Delistings exigem regra explícita para último preço, pagamento, conversão, retorno de delisting e dados ausentes. Excluir a observação porque ela é difícil de reconstruir cria viés justamente nos casos de pior resultado.
Protocolo point-in-time
- Definir o timestamp da decisão, timezone, calendário e cutoff.
- Registrar fonte, campo, unidade, moeda e condições de revisão.
- Guardar evento, publicação, ingestão e versão de cada dado.
- Versionar universo, identificadores, eventos corporativos e delistings.
- Aplicar transformações apenas com amostras disponíveis até o instante.
- Preservar snapshots imutáveis, hashes e código de transformação.
- Testar consultas “as of” em datas conhecidas e comparar com documentos da época.
- Manter separados dado observado e série posteriormente corrigida.
ALFRED é um exemplo de arquitetura que conserva vintages de séries macroeconômicas. Não resolve automaticamente preços, universos ou eventos corporativos; cada domínio requer seu próprio registro temporal.
Controles rápidos
- Uma revisão posterior muda o resultado histórico sem nova versão do dataset?
- A composição atual do índice aparece antes da data efetiva?
- A transformação foi ajustada usando toda a amostra?
- O sinal consegue usar um filing antes de sua disseminação?
- Tickers são tratados como identificadores permanentes?
- Instrumentos delistados desaparecem sem retorno final?
- Calendários e horário de verão deslocam informações entre sessões?
Cada resposta afirmativa indica uma possível ruptura do contrato temporal.
Consultas “as of” e trilha de auditoria
Guardar versões não basta se a consulta não reproduz o conjunto exato que o modelo podia enxergar. Uma consulta “as of” recebe o instante da decisão e devolve somente registros cujo horário de disponibilidade já passou, usando a versão então válida. Esse contrato deve valer também para tabelas derivadas: normalizações, classificações, universos elegíveis e fatores calculados não podem ser reconstruídos hoje com toda a amostra e depois associados ao passado.
Uma implementação auditável preserva o snapshot de entrada, o código que o transformou, o fuso horário, o calendário e um identificador imutável da execução. Se uma correção do fornecedor chegar amanhã, ela cria uma nova versão; não reescreve silenciosamente o teste publicado ontem. Assim é possível explicar se uma diferença veio do sinal, de uma revisão da fonte ou da própria pipeline.
O controle mais útil é escolher algumas datas históricas difíceis — anúncios fora do horário, mudança de componente, fusão e delisting — e reconstruir a decisão a partir dos documentos disponíveis naquele momento. A comparação não certifica todo o banco, mas revela cedo erros de timestamp, identidade e vigência. Quando o horário original não existe, a regra conservadora adotada deve ser explícita e sua sensibilidade precisa ser testada.
Limites
Point-in-time não significa perfeito. A fonte histórica pode ser incompleta, timestamps podem representar disseminação e não ingestão local, e o dado reconstruído pode não reproduzir latência ou falhas da produção. A solução é declarar lacunas, comparar versões e testar sensibilidade, não rotular o dataset como livre de viés.
Fontes
- Federal Reserve Bank of St. Louis, ALFRED® e Real-Time Periods — valores originalmente publicados, revisões e períodos de validade informativa.
- U.S. Securities and Exchange Commission, EDGAR Application Programming Interfaces — histórico de filings, metadados e atualização das informações divulgadas.
- Center for Research in Security Prices, CRSP Survivor-Bias-Free US Mutual Fund Database Guide — estrutura histórica com fundos ativos e encerrados.
- Tyler Shumway, The Delisting Bias in CRSP Data, The Journal of Finance, 1997 — consequências da omissão dos retornos de delisting.
- S&P Dow Jones Indices, Equity Indices Policies & Practices — anúncios, datas efetivas, rebalanceamentos e correções de composição.