Estimado creador de la estrategia de filtro de nóminas,
Has creado una regla sencilla: después del informe de empleo de EE. UU., tu estrategia mantiene un ETF de renta variable durante cinco sesiones si el crecimiento mensual de las nóminas supera los 175,000. De lo contrario, permanece en efectivo. Has programado la entrada después de la apertura del mercado de renta variable, has incluido los costes de negociación y has mantenido fijo el umbral. Luego descargaste una serie histórica de nóminas y la usaste para reconstruir todas las señales.
El problema que te queda es la descarga. Una serie económica histórica puede contener estimaciones revisadas que no estaban disponibles en las fechas en que, supuestamente, operó tu estrategia. Para hacer un backtest honesto de una señal macroeconómica, necesitas la versión disponible en cada momento de decisión. Retrasar la entrada una barra no corregirá una cifra publicada dos meses después.
Tu observación de enero tiene varios cumpleaños
Considera este historial ficticio de publicaciones. Estas fechas y variaciones de nóminas ilustran la mecánica; no son resultados económicos publicados.
| Publicación | Mes de referencia | Variación de nóminas publicada | Tu regla en esa publicación |
|---|---|---|---|
| 7 de febrero, 08:30 ET | Enero | +150,000 | Permanecer en efectivo |
| 7 de marzo, 08:30 ET | Enero, revisado | +185,000 | No cambia la decisión de febrero |
| 4 de abril, 08:30 ET | Enero, revisado de nuevo | +210,000 | No cambia la decisión de febrero |
Si tu descarga contiene enero como +210,000, la reproducción histórica entra en el ETF en febrero. Tu regla real se habría quedado en efectivo. Todos los precios, las marcas de tiempo de las órdenes y las comisiones pueden ser correctos, y aun así esa operación entera sería ficticia.
No puedes dar por sentado que esta contaminación mejora el rendimiento. Las revisiones pueden generar operaciones ganadoras o perdedoras, o eliminar unas u otras. El defecto es que tu simulación responde a una pregunta que tu estrategia no habría podido plantearse en ese momento.
Y enero es solo el período medido. No es la fecha en que conociste la medición. Una fila etiquetada como 1 de enero no te da permiso para operar con ese dato el 1 de enero.
Registra cuándo estuvo disponible cada valor
Tu tabla de investigación necesita más que un mes y una cifra. Conserva el período de referencia, el valor, la marca de tiempo de publicación, el identificador de la versión y la fuente. Si recopilas datos de forma continua, registra también cuándo recibió tu sistema la publicación. Conserva las versiones anteriores en lugar de sobrescribir sus valores.
En cada marca de tiempo de decisión, selecciona la versión más reciente que cumpla los requisitos de cada observación y cuya marca de tiempo de disponibilidad no sea posterior a esa decisión. Después calcula tus variables a partir de esa instantánea reconstruida.
Tu regla de recuperación: primero limita los registros a los que estaban disponibles, luego selecciona las versiones aplicables y, por último, calcula la señal. Calcular las variables con el historial revisado de hoy y desplazar el resultado después mantiene la filtración.
Que el período de mantenimiento sea de cinco sesiones no hace opcional este registro. Te da más margen para elegir una hora de entrada conservadora; no te da acceso anticipado a las revisiones.
En investigaciones antiguas, quizá tengas pruebas de la hora de publicación, pero ningún registro de cuándo recibiste los datos. Mantén explícita esa distinción. Puedes modelar el acceso a partir de una hora de publicación documentada y aplicar un retraso declarado. No puedes presentar esa suposición como un dato histórico medido de entrega.
También necesitarás una marca de tiempo que tenga en cuenta la zona horaria. Guarda la hora local documentada de la publicación y conviértela correctamente; un desfase UTC fijo para Nueva York fallará con los cambios de horario de verano. Hazle ese pequeño favor a tu yo del futuro. Tu yo de septiembre no debería tener que descifrar una columna de tu yo de marzo llamada date_actual_final2.
Tus variables móviles necesitan el historial completo de versiones
Supongamos que sustituyes el umbral fijo por «el crecimiento de las nóminas supera su promedio de los últimos doce meses». Ahora necesitas las observaciones anteriores tal como estaban en ese momento de decisión, incluidas las revisiones que ya se habían publicado.
Usar para siempre la primera publicación de cada mes define una variable distinta. Puede ser un diseño legítimo si quieres explícitamente un historial de los anuncios iniciales. No reconstruye el historial económico visible en una mañana concreta, porque el conjunto de información disponible esa mañana quizá ya incluya revisiones de meses anteriores.
Si calculas las variaciones mensuales de nóminas a partir de los niveles de empleo, reconstruye primero la serie de niveles correspondiente a esa versión y luego calcula las diferencias. Mezclar un nivel recién publicado con el nivel del mes anterior de una versión más antigua puede generar una variación que no aparecía en ninguna instantánea publicada.
Por tanto, tienes que especificar qué significa tu variable: anuncios iniciales, la imagen económica más reciente o las propias revisiones. «Crecimiento de las nóminas» deja demasiadas cosas sin definir.
Repara una publicación antes de volver a ejecutar diez años de datos
Puedes empezar con ALFRED, que proporciona historiales de versiones para muchas series económicas. Comprueba la cobertura de tu serie y período exactos. La fecha de una versión por sí sola no establece su disponibilidad intradía; combínala con horarios de publicación documentados antes de usarla para una señal del mismo día.
Para tu primera auditoría, elige una publicación y reconstrúyela a mano:
- Encuentra la publicación archivada y registra su marca de tiempo de publicación, el mes de referencia y el valor inicial.
- Reconstruye la instantánea de datos que tu estrategia habría recibido antes de entrar.
- Calcula la señal a mano y compárala con la de tu reproducción histórica.
- Añade una revisión posterior al almacén de datos y verifica que la decisión anterior no cambie.
Esta última comprobación resulta especialmente útil en una canalización automatizada de investigación. Proporciona a tu agente de investigación el límite temporal de la instantánea y los identificadores de las versiones seleccionadas junto con los valores de las variables. Necesitas pruebas suficientes para rastrear una operación hasta una publicación concreta, incluso después de que haya crecido la base de datos subyacente.
Cuando reproduzcas esa decisión individual, vuelve a ejecutar el historial y compara las discrepancias entre señales antes de comparar los rendimientos. Cuenta las entradas que la reparación haya creado, eliminado o desplazado. Aprenderás más de esas decisiones modificadas que de un único Sharpe antes y después.
Tu operación de febrero tiene que sostenerse con la información de febrero. Deja la revisión de abril en abril.
← Todos los artículos


