Datos point-in-time

Los datos point-in-time conservan la historia tal como podía observarse en cada momento. No basta con la fecha a la que se refiere un valor: hay que registrar cuándo se publicó, cuándo pasó a estar disponible para el sistema, qué versión era entonces válida y durante cuánto tiempo permaneció vigente. Una base de datos correcta y plenamente actualizada hoy puede describir el pasado con precisión y, al mismo tiempo, ser inadecuada para simular una decisión pasada.

Cuatro fechas que no deben confundirse

La marca temporal de disponibilidad es la referencia operativa. Una publicación difundida a las 16:05 de Nueva York no puede generar una orden al cierre de las 16:00. Si el sistema recibe el archivo a las 16:08, la primera decisión admisible también debe respetar esa latencia. Para datos diarios sin una hora fiable, un enfoque prudente consiste en declarar una convención explícita —por ejemplo, «utilizable desde la sesión siguiente»— y documentarla.

Los datos macroeconómicos ilustran el problema del vintage de revisión. Las cifras de producción, empleo y crecimiento pueden corregirse muchas veces. La serie más reciente responde a «¿cuál es hoy la mejor estimación del pasado?». Un test point-in-time pregunta «¿qué estimación era pública en esa fecha?». Son preguntas diferentes.

Universo, identificadores y composición

No se puede proyectar hacia atrás una lista actual de valores, fondos o contratos. El universo debe ser una tabla temporal con intervalos de validez:

Un ticker es una etiqueta, no una identidad estable: puede cambiar o volver a utilizarse. Vincular precios, estados financieros y acciones corporativas exige identificadores persistentes y un mapa con validez temporal. La clasificación sectorial o la pertenencia a un país también pueden cambiar; aplicar a 2010 la clasificación actual introduce información retrospectiva.

Acciones corporativas y exclusiones de cotización

Splits, dividendos, escisiones, fusiones, ofertas, conversiones y cambios de símbolo implican varias fechas: anuncio, ex-date, registro, pago y efectividad. Una serie de cierre ajustado recalculada hoy resulta cómoda para medir rendimientos, pero no sustituye un registro causal de eventos. El factor de ajuste debe ser adecuado al propósito: comparar rendimientos totales no es lo mismo que simular límites, cantidades y órdenes observables antes de un evento.

Una exclusión de cotización o delisting no justifica borrar la última observación. Deben conservarse el motivo, la fecha, cualquier rendimiento de delisting, distribución o valor de recuperación y la regla utilizada cuando faltan datos. Una pérdida eliminada de la base de datos vuelve la muestra más saludable de lo que era y conecta directamente con el sesgo de supervivencia.

Protocolo point-in-time

1. Fijar el momento de decisión. Definir zona horaria, calendario, hora de corte y frecuencia de cada estrategia.
2. Separar evento y disponibilidad. Conservar event_time, published_at, available_at e ingested_at cuando estén disponibles.
3. Archivar los vintages. No sobrescribir una revisión; añadir una versión nueva con inicio y fin de validez.
4. Utilizar identidades persistentes. Vincular tickers y descripciones a identificadores estables con intervalos temporales.
5. Reconstruir el universo. Guardar composición, elegibilidad, anuncios y fechas efectivas; no partir de los supervivientes actuales.
6. Tratar las acciones corporativas como eventos. Conservar términos, fechas y fuentes, y después generar los ajustes necesarios para el propósito declarado.
7. Mantener fallos y ausencias. Delistings, suspensiones, fondos cerrados y valores ausentes forman parte de la historia.
8. Modelar la latencia. Añadir el retraso del proveedor y del procesamiento, además de la siguiente ventana negociable.
9. Hacer repetible la consulta. «Mostrar lo que se sabía a las 10:00 del día X» debe devolver siempre la misma instantánea.
10. Congelar el conjunto de prueba. Conservar versión, suma de comprobación, transformaciones y código junto con los resultados out-of-sample.

Comprobaciones rápidas

Limitaciones

Una base de datos point-in-time reduce el sesgo de anticipación, pero no certifica una estrategia. Los datos tardíos pueden ser incorrectos; una fuente puede tener cobertura selectiva; el flujo puede aplicar transformaciones futuras; el universo puede seguir incompleto. Los datos point-in-time tampoco modelan órdenes, liquidez, capacidad ni costes de transacción en backtests. Todo resultado sigue condicionado por las fuentes, convenciones y disponibilidades documentadas.

Fuentes

• Federal Reserve Bank of St. Louis, ALFRED® y Real-Time Periods — conservación de los valores publicados originalmente, sus revisiones y los periodos de validez de la información.
• U.S. Securities and Exchange Commission, EDGAR Application Programming Interfaces — historial de presentaciones, metadatos y actualizaciones de la información difundida.
• Center for Research in Security Prices, CRSP Survivor-Bias-Free US Mutual Fund Database Guide — estructura histórica que incluye fondos activos y terminados.
• Tyler Shumway, The Delisting Bias in CRSP Data, The Journal of Finance, 1997 — consecuencias de omitir los rendimientos de delisting.
• S&P Dow Jones Indices, Equity Indices Policies & Practices — anuncios, fechas efectivas, rebalanceos y tratamiento de las correcciones de composición.

Enlaces

• Trading sistemático
• Backtest
• Out-of-sample
• Data leakage y sesgo de anticipación
• Sesgo de supervivencia
• Costes de transacción en backtests