Qué significa realmente tener buenos datos históricos
Un buen histórico no tiene que ser perfecto. En muchos mercados eso ni siquiera es una expectativa realista.
Lo que necesitas es un dataset suficientemente fiable para la pregunta que estás intentando responder.
Yo revisaría seis cosas:
| Criterio | Qué debes comprobar |
|---|---|
| Procedencia | De dónde vienen los precios y qué mercado, exchange, broker o feed representan |
| Cobertura | Qué fechas incluye y si faltan periodos que deberían existir |
| Consistencia | Duplicados, timestamps desordenados, precios imposibles o registros corruptos |
| Tiempo | Zona horaria, sesiones, cierres de mercado y cambios de horario |
| Granularidad | Si necesitas velas diarias, minutos, segundos o ticks |
| Ejecución | Si tienes la información necesaria para representar spread, bid/ask y otros costes relevantes |
Hay una diferencia importante entre datos limpios y datos adecuados.
Un CSV puede estar impecablemente ordenado y seguir siendo inadecuado para tu sistema.
Imagina que quieres probar un scalping con stops de dos o tres ticks, pero solo tienes velas de cinco minutos. Puede no faltar una sola vela y, aun así, el dataset no te permite reconstruir con suficiente precisión qué ocurrió dentro de cada barra.
Antes de buscar más datos, asegúrate de que tu sistema de trading está definido con suficiente claridad. Si todavía cambian la entrada, la salida o el horario según miras el gráfico, el problema no es el histórico.
Define qué datos necesitas antes de descargarlos
Uno de los errores más frecuentes es hacerlo al revés: descargar lo que encuentras y después adaptar el backtest a esas columnas.
Yo prefiero crear primero una especie de contrato de datos.
Antes de tocar el archivo, deberías poder responder:
- ¿Qué instrumento estoy probando exactamente?
- ¿En qué mercado, exchange, venue, broker o feed?
- ¿Qué periodo necesito?
- ¿Cuál es la temporalidad de decisión de mi sistema?
- ¿Necesito conocer lo ocurrido dentro de cada vela?
- ¿Uso market orders, limits, stops o una combinación?
- ¿Necesito bid y ask separados?
- ¿Necesito volumen? ¿Qué representa ese volumen?
- ¿En qué zona horaria vienen los datos?
- ¿Qué sesión considera cada vela?
- ¿Los precios están ajustados?
- ¿Hay vencimientos o rolls?
- ¿Qué costes de ejecución necesitaré modelar?
Esto exige haber hecho antes el trabajo de definir las reglas del sistema.
Por ejemplo, no pide lo mismo un sistema que compra una acción al cierre mensual que otro que intenta capturar cinco puntos en un índice intradía.
Una referencia aproximada sería esta:
| Tipo de sistema | Datos que normalmente cobran más importancia |
|---|---|
| Swing en acciones con velas diarias | OHLCV, eventos corporativos y universo histórico |
| Intradía en Forex o CFDs | Datos intradía, horario correcto y spread |
| Scalping | Tick o resolución muy fina, bid/ask y costes de ejecución |
| Futuros | Contratos individuales, vencimientos, roll y volumen/open interest si se utilizan |
| Cripto | Exchange concreto, datos 24/7 y características específicas del producto |
No es una regla universal. La pregunta correcta es otra:
¿Qué nivel de información necesita mi sistema para que el simulador pueda reproducir sus reglas sin inventarse lo que ocurrió?
La fuente importa tanto como el archivo
No existe una única fuente de datos históricos que sea “la mejor” para todo.
En un mercado centralizado, obtener datos del propio exchange o de un proveedor que documente claramente esa procedencia puede tener mucho sentido.
Forex spot es distinto. El BIS describe el mercado FX como un mercado principalmente OTC, descentralizado y fragmentado, con distintos dealers y venues. Eso significa que dos feeds de EUR/USD pueden diferir ligeramente sin que uno de ellos tenga que estar necesariamente “mal”.
Para un trader esto tiene una consecuencia práctica: si pretendes ejecutar el sistema con un broker concreto, merece la pena comprobar cómo se parece el histórico utilizado a los precios y condiciones que realmente encontrarás allí.
MetaTrader 5, por ejemplo, sincroniza desde el servidor de trading los datos históricos M1 y los ticks disponibles para el símbolo antes de ejecutar una prueba. Si existen ticks reales, el Strategy Tester puede utilizarlos directamente; su disponibilidad depende del histórico que tenga el servidor.
Eso también explica por qué correr aparentemente “el mismo” robot contra históricos procedentes de servidores diferentes puede producir resultados distintos.
Dónde encaja Pepperstone aquí
Pepperstone permite trabajar con MT4, MT5, TradingView y cTrader, además de su propia plataforma, y ofrece acceso a cuentas demo.
Para esta parte del curso, MT5 resulta especialmente interesante por su Strategy Tester y por la posibilidad de trabajar con históricos y ticks. Eso no convierte automáticamente el dato en bueno: sigues teniendo que inspeccionar qué histórico tienes y si encaja con tu sistema.
Si quieres montar este flujo en un entorno de práctica, puedes revisar Pepperstone y consultar la promoción disponible mediante nuestro enlace. Yo empezaría en demo mientras verificas datos, reglas y funcionamiento del tester. La disponibilidad y las condiciones de cualquier promoción pueden variar.
Y una precisión necesaria: Pepperstone ofrece, entre otros productos, CFDs apalancados. Su propia documentación advierte del alto riesgo asociado a estos instrumentos. Una herramienta útil para probar un sistema no elimina el riesgo del producto que después decidas operar.
¿Velas o ticks? Depende de lo que haga tu sistema dentro de la vela
Más resolución no significa automáticamente mejor backtest.
Significa más información.
Y esa información solo aporta valor si cambia alguna decisión de tu estrategia.
Supongamos una vela de cinco minutos totalmente hipotética:
- apertura: 100
- máximo: 105
- mínimo: 95
- cierre: 102
Entras largo en 100.
Tu stop está en 97 y tu objetivo en 104.
Con esos cuatro datos sabemos que durante la vela se alcanzaron tanto el stop como el objetivo.
Lo que no sabemos es el orden.
¿El precio subió primero a 104 y después cayó a 95?
¿O cayó primero a 97, cerró tu operación y posteriormente subió?
La misma vela puede representar una ganancia o una pérdida dependiendo de la trayectoria intrabar.
Si tu backtester simplemente elige una secuencia conveniente, acaba de inventar una operación.
Aquí el dato de tick o una temporalidad inferior sí puede cambiar materialmente la calidad de la prueba.
En cambio, si tu sistema solo calcula una señal después del cierre diario y siempre ejecuta en la apertura siguiente, conocer cada tick del día quizá añada enormes cantidades de información sin modificar la decisión que estás estudiando.
Utiliza la resolución mínima que represente correctamente la lógica del sistema.
Esta distinción también importa al utilizar plataformas. TradingView indica que la profundidad histórica disponible puede variar según símbolo y temporalidad; en su modo Deep Backtesting existe además un límite de hasta dos millones de barras por cálculo.
Tener dos millones de barras no hace fiable por sí solo un backtest. La calidad de esas barras y su relación con tus reglas siguen importando más que el número bonito.
Cómo limpiar y validar un histórico antes del backtesting
Aquí es donde yo dejaría de pensar como trader durante unos minutos y empezaría a pensar como auditor.
No preguntes todavía si la estrategia gana.
Pregunta si el archivo tiene sentido.
Comprueba primero la estructura
Empieza por cosas aparentemente aburridas:
- timestamps ordenados;
- ningún registro duplicado sin explicación;
- columnas completas;
- precios en unidades coherentes;
- ausencia de valores nulos inesperados;
- ninguna cotización negativa cuando el instrumento no puede tenerla;
- formatos numéricos consistentes.
En datos OHLC hay además relaciones básicas que deberían cumplirse.
El máximo de una vela no puede ser inferior simultáneamente a su apertura o a su cierre. De la misma manera, el mínimo no debería encontrarse por encima de ellos.
Una comprobación sencilla es:
High ≥ Open, Close y Low
y
Low ≤ Open, Close y High
No necesitas saber todavía si la estrategia funciona para detectar que una fila viola esas relaciones.
Busca duplicados y registros fuera de orden
Un timestamp repetido puede contar dos veces un movimiento.
Pero tampoco conviene borrar automáticamente cualquier duplicado que veas. Primero debes entender por qué existe.
¿Es realmente un registro repetido?
¿Son dos ticks distintos ocurridos exactamente en la misma marca temporal?
¿El timestamp original tiene suficiente precisión para diferenciarlos?
Limpiar datos no significa aplicar un botón de “eliminar duplicados”. Significa comprender el esquema que estás procesando.
Distingue un gap real de un dato perdido
Esta parte da bastantes problemas.
Si faltan doce horas un sábado en un mercado que estaba cerrado, no tienes doce horas de datos defectuosos.
Tampoco puedes exigir que una serie intradía de una acción cotizada tenga velas durante periodos en los que su mercado no estaba negociando.
Por eso, detectar gaps correctamente exige comparar los timestamps con el calendario y la sesión que deberían existir.
Ahora supongamos que faltan veinte minutos en mitad de una sesión normal.
Ahí sí tienes algo que investigar.
Yo evitaría rellenar automáticamente ese hueco copiando el último precio o interpolando entre dos valores. Estarías creando precios sintéticos que quizá nunca existieron.
Primero:
- identifica el hueco;
- comprueba si existió una interrupción real de negociación;
- contrasta otra fuente cuando sea posible;
- decide qué tratamiento utilizar;
- documenta la decisión.
Un dataset imperfecto pero correctamente documentado puede ser más útil que otro que parece perfecto porque alguien ocultó sus huecos.
Investiga los spikes antes de borrarlos
Ves una vela enorme.
El resto del mercado apenas se movió.
¿Error?
Quizá.
Pero también podría ser una noticia, falta de liquidez, un flash move o un precio realmente negociado.
Borrar cualquier outlier porque “se ve raro” es peligroso.
Peor todavía: borrarlo porque estropea el resultado de tu estrategia.
En ese momento ya no estás limpiando los datos; estás adaptando el pasado al resultado que quieres obtener.
Yo marcaría esos valores, compararía con una segunda fuente y dejaría registro de cualquier corrección.
Y, cuando el problema sea que estás modificando información después de haber visto su efecto sobre el sistema, entramos en un terreno que más adelante conecta con el overfitting.
El timestamp puede arruinarte el backtest sin tocar ningún precio
Un precio puede ser correcto y estar colocado en la hora incorrecta.
Y eso basta.
Imagina un sistema que opera la apertura de Nueva York.
El histórico está en UTC, pero tu código interpreta la hora como si fuera la hora local del mercado.
Ahora todas las señales están desplazadas.
Puedes tener:
- los precios correctos;
- todas las velas;
- cero duplicados;
- cero valores nulos;
y seguir probando otro sistema distinto del que crees.
Por eso necesitas conocer:
Zona horaria del dataset
No asumas que porque una columna diga 09:30 sabes qué significa.
Convención del timestamp
¿La hora corresponde al inicio o al final de la vela?
Una vela M5 etiquetada 10:00 puede representar 10:00–10:05 en una plataforma y tener otra convención de almacenamiento en otra fuente.
Horario de verano
Si una estrategia depende de sesiones de Londres o Nueva York, utilizar simplemente un desplazamiento fijo como UTC-5 durante todo el año puede provocar errores cuando cambia el horario de verano.
Cuando trabajo conceptualmente con datos de varias fuentes, prefiero normalizar internamente a una referencia horaria clara —frecuentemente UTC— y convertir a la zona de la sesión únicamente cuando la lógica del sistema lo necesita.
Lo importante no es que uses mi convención. Es que tengas una y sea consistente.
No todos los mercados necesitan el mismo tratamiento
Preparar un buen histórico de acciones no es exactamente lo mismo que preparar Forex, futuros o cripto.
Forex y CFDs: importa el feed
En FX spot no existe una única cinta centralizada que contenga cada transacción mundial. El mercado está fragmentado entre distintos participantes y venues.
Por eso tendrías cuidado con tres cosas:
Feed de precios. Dos proveedores pueden construir velas ligeramente diferentes.
Bid y ask. Un gráfico basado únicamente en un precio puede esconder el coste y las condiciones que realmente determinan si una orden se activa.
Horario del servidor. La construcción de velas H4 o diarias puede cambiar cuando cambia el corte horario.
Si utilizas CFDs, además estás simulando el instrumento ofrecido por ese proveedor, no necesariamente el mercado subyacente directamente.
Si tu objetivo es terminar ejecutando el sistema en ese entorno, puedes probar Pepperstone y comparar su histórico y funcionamiento en demo antes de comprometer capital. La prueba útil aquí no es “¿se ve bonito el gráfico?”, sino “¿el dato y la plataforma representan correctamente las reglas que quiero testear?”.
Acciones y ETFs: cuidado con splits, dividendos y empresas desaparecidas
Imagina una acción que cotiza a 100 y realiza un split 2:1.
Su precio pasa aproximadamente a 50 por una decisión corporativa, no porque la empresa haya perdido la mitad de su valor de mercado durante la noche.
Si utilizas una serie sin tratar correctamente ese evento, algunos indicadores pueden interpretar el movimiento como una caída gigantesca.
Exchanges como NYSE mantienen información de eventos corporativos que incluye dividendos, splits, nuevas cotizaciones, suspensiones y delistings.
Por eso tienes que saber si tus datos son:
- sin ajustar;
- ajustados por splits;
- ajustados por dividendos;
- ajustados por ambos;
- o transformados con otra metodología.
No mezcles series ajustadas y sin ajustar sin entender qué estás haciendo.
Y hay otra trampa distinta: probar una estrategia únicamente sobre las empresas que hoy siguen existiendo.
Las compañías que quebraron, fueron excluidas o desaparecieron también formaban parte del mercado histórico. Si las eliminas de forma retrospectiva, puedes estar construyendo una muestra artificialmente favorable.
Ese problema merece su explicación completa, así que lo desarrollamos en la lección sobre survivorship bias en trading.
Futuros: una serie continua no es lo mismo que un contrato negociable
Los futuros vencen.
Por tanto, cuando ves un gráfico de diez años de un futuro, probablemente alguien ha tenido que construir una serie enlazando distintos vencimientos.
Aquí necesitas saber:
- qué contrato se selecciona;
- cuándo se cambia al siguiente;
- si se utiliza el contrato frontal o el más líquido;
- cómo se tratan las diferencias de precio entre vencimientos;
- si la serie ha sido ajustada;
- qué ocurre con volumen y open interest.
CME, por ejemplo, ofrece sus propias Continuous Price Series y distingue entre el contrato activo y el contrato frontal, documentando sus reglas de cambio y la forma en que mapea volumen y open interest.
Una serie continua puede ser estupenda para determinados análisis.
Pero si quieres simular ejecución real, tarde o temprano tienes que responder:
¿Qué contrato habría estado operando ese día?
y
¿Cómo habría tratado el roll?
Ese detalle puede ser irrelevante para una idea y decisivo para otra.
Cripto: especifica también el exchange y el producto
“BTC/USD” no define por completo el dataset.
Puede tratarse de:
- spot en un exchange;
- spot en otro;
- un índice;
- un CFD;
- un futuro;
- un perpetuo.
Incluso cuando dos mercados siguen al mismo activo, sus precios, liquidez y microestructura pueden ser diferentes.
En criptomonedas tampoco asumiría que “24/7” significa “dataset sin interrupciones”. Un exchange puede tener mantenimientos, incidencias o periodos sin determinados datos.
De nuevo: no necesitas un dataset abstractamente perfecto.
Necesitas saber qué representa.
El precio histórico no es lo mismo que la ejecución histórica
Este es uno de los puntos que más fácilmente infla un backtest.
Un archivo OHLC puede decirte por dónde pasó aproximadamente el mercado.
No necesariamente te dice a qué precio habrías comprado o vendido.
Supongamos este ejemplo hipotético:
Tu estrategia busca ganar 3 puntos por operación y perder 3.
En un backtest ingenuo:
- entrada: 100;
- salida ganadora: 103;
- beneficio bruto: +3.
Pero imagina que entre spread, comisión y slippage medio de ese escenario pierdes 1 punto efectivo entre entrada y salida.
Ya no ganas 3.
Ganas 2 antes de cualquier otra fricción.
Ahora imagina que tu ventaja estadística era muy pequeña. Una diferencia así puede transformar completamente el resultado.
Cuanto más corta sea la duración de las operaciones y menor el beneficio esperado por trade, más importancia suelen tener estas fricciones.
MetaTrader 5 documenta otra diferencia relevante: cuando el tester trabaja con ticks reales, el spread puede cambiar dentro de una misma vela de un minuto; al generar ticks a partir de datos de minuto, la simulación no contiene exactamente la misma información.
Esto no significa que todos los backtests necesiten un modelo de microestructura sofisticado.
Significa que debes preguntarte:
¿Qué parte de mi resultado depende de una ejecución que los datos disponibles no pueden representar?
Un ejemplo de cómo tres pequeños errores pueden cambiar un sistema
Imagina un sistema hipotético de breakout en velas M5.
El histórico parece normal, pero contiene tres problemas.
Primero, falta una vela a las 10:10.
Segundo, la vela de las 11:35 aparece dos veces.
Tercero, a las 14:20 existe un máximo un 8% superior a los precios de las velas inmediatamente anteriores y posteriores.
¿Qué puede ocurrir?
La vela que falta modifica cualquier indicador calculado sobre una ventana reciente.
El duplicado añade una observación que nunca debería estar ahí.
El spike puede activar un breakout que quizá nunca existió.
Lo interesante es que el backtest puede ejecutarse perfectamente.
No sale ningún mensaje de error.
Obtienes win rate, profit factor, drawdown y una equity curve.
Todo parece profesional.
Pero estás calculando estadísticas sobre una secuencia de mercado que no coincide con la que realmente ocurrió.
Yo no intentaría decidir inmediatamente qué filas borrar.
Haría esto:
- marcar las tres anomalías;
- comprobar la sesión y el calendario;
- contrastar el periodo con otra fuente;
- entender el origen de cada problema;
- aplicar una regla de tratamiento definida;
- guardar qué se modificó;
- volver a ejecutar todas las validaciones.
La limpieza correcta debería ser reproducible, no artesanal.
Cuidado con arreglar el pasado utilizando información del futuro
Hay un límite que conviene dejar muy claro.
Preparar datos no debe introducir información que en aquel momento todavía no estaba disponible.
Por ejemplo, si tu sistema utiliza componentes de un índice, necesitas saber cuáles pertenecían al índice en cada fecha, no simplemente aplicar la composición actual hacia atrás.
Si empleas información fundamental, la fecha importante puede no ser el periodo contable al que pertenece el dato, sino cuándo habría podido conocerlo realmente el trader.
Si una variable fue revisada posteriormente, tampoco deberías asumir automáticamente que la versión final estaba disponible desde el principio.
Aquí aparece el look-ahead bias. Lo menciono porque nace muchas veces durante la preparación del dataset, pero no voy a desarrollar todo el sesgo aquí: tiene su propia lección dentro de este módulo.
Más adelante también separaremos correctamente In-Sample y Out-of-Sample. En esta etapa basta con no manipular todavía los datos de una forma que haga imposible esa separación.
Mi checklist antes de permitir que un backtest toque los datos
Si tuviera que convertir toda esta lección en un proceso operativo, utilizaría algo parecido a esto:
| Revisión | Pregunta |
|---|---|
| 1. Identidad | ¿Sé exactamente qué instrumento y mercado representa? |
| 2. Fuente | ¿Conozco el proveedor, servidor o exchange del que procede? |
| 3. Cobertura | ¿Tengo las fechas y sesiones que esperaba encontrar? |
| 4. Granularidad | ¿La resolución permite reproducir mis reglas? |
| 5. Orden | ¿Los timestamps están ordenados correctamente? |
| 6. Duplicados | ¿Existen registros repetidos o conflictos? |
| 7. Gaps | ¿Los huecos son cierres normales o datos inesperadamente ausentes? |
| 8. Precios | ¿OHLC y demás campos cumplen relaciones lógicas? |
| 9. Outliers | ¿He revisado movimientos extremos en lugar de borrarlos a ciegas? |
| 10. Tiempo | ¿Zona horaria, horario de verano y sesiones están normalizados? |
| 11. Ajustes | ¿Splits, dividendos, vencimientos o rolls están tratados correctamente? |
| 12. Ejecución | ¿Tengo spread, bid/ask y costes suficientes para mi tipo de sistema? |
| 13. Sesgos | ¿La información disponible es realmente la que habría existido entonces? |
| 14. Reproducibilidad | ¿Podría reconstruir mañana exactamente el mismo dataset? |
Si alguna respuesta importante es “no sé”, yo no optimizaría todavía ni un solo parámetro.
Primero arreglaría eso.
Guarda los datos originales: nunca trabajes sobre tu única copia
Una práctica sencilla evita bastantes problemas.
Mantén al menos dos capas:
Raw data
El archivo original tal como llegó de la fuente.
No lo modifies.
Processed data
La versión que utilizas para el backtest después de ordenar, normalizar y corregir lo que haya sido necesario.
Así puedes saber si una anomalía venía de origen o apareció durante tu transformación.
Si el proyecto empieza a ser serio, guardaría también un pequeño manifiesto:
- fuente;
- instrumento;
- mercado o servidor;
- fechas;
- temporalidad;
- timezone;
- campos disponibles;
- ajuste de precios;
- tratamiento de corporate actions;
- regla de roll si existen futuros;
- criterio aplicado a gaps;
- criterio aplicado a outliers;
- fecha o versión de descarga;
- versión del proceso de limpieza.
No hace falta construir una infraestructura institucional para hacer esto.
Un archivo de texto bien mantenido ya es muchísimo mejor que intentar recordar tres meses después qué cambiaste en aquel CSV.
Y tiene otra ventaja: si el resultado cambia, puedes investigar si cambió el sistema o cambiaron los datos.
Haz una prueba cruzada antes de confiar en el histórico
Cuando el sistema lo justifique, una comparación sencilla con otra fuente puede revelar bastante.
No necesitas que ambas series sean idénticas tick por tick.
Eso sería especialmente absurdo en mercados fragmentados.
Busca diferencias estructurales:
- largos periodos ausentes;
- horarios desplazados;
- spikes que solo existen en una fuente;
- diferente número de barras;
- cierres diarios construidos a horas distintas;
- spreads radicalmente distintos;
- corporate actions sin tratar.
Si un sistema pasa de espectacular a mediocre únicamente porque cambias a otro histórico razonable del mismo mercado, no significa automáticamente que uno de los datasets sea malo.
Puede significar que tu ventaja depende demasiado de pequeños detalles del dato.
Esa sensibilidad es información útil.
Más adelante en el curso iremos mucho más lejos al estudiar robustez. Aquí basta con detectar la señal de alarma.
Tres cosas que yo no haría con los datos históricos
No rellenaría huecos automáticamente para que la gráfica quede bonita.
Una serie continua visualmente no es necesariamente una representación más verdadera del mercado.
No eliminaría movimientos extremos porque perjudican el backtest.
Primero demostraría que son errores.
No mezclaría fuentes sin registrar exactamente dónde cambia una por otra.
Si siete años proceden de un proveedor y los tres siguientes de otro, un cambio aparentemente económico del sistema podría deberse únicamente al feed.
Hay una idea de fondo: preparar datos también consiste en limitar las decisiones que puedes reinterpretar después de haber visto el resultado.
Ese mismo principio será importante cuando estudiemos sesgos y sobreoptimización.
¿Y si utilizas una plataforma que ya trae los históricos?
Aprovecha esa comodidad.
Pero no confundas comodidad con validación.
Que MetaTrader, TradingView o cualquier otra plataforma cargue automáticamente un gráfico no responde por sí solo:
- cuánto histórico existe;
- de qué fuente concreta procede;
- qué resolución real tiene;
- si incluye bid y ask;
- cómo se construyen las velas;
- qué ajustes se han realizado;
- qué ocurre con los gaps;
- ni si esos datos son suficientes para tus reglas.
Tu obligación no es desconfiar obsesivamente de todo.
Es saber qué estás usando.
En Pepperstone, por ejemplo, puedes acceder a varias plataformas con histórico y funciones de backtesting. Eso puede hacer muy cómodo el trabajo práctico, pero yo mantendría exactamente el mismo criterio: revisar feed, periodo, granularidad y supuestos antes de interpretar cualquier estadística.
Si quieres practicar esta preparación antes de pasar al análisis de resultados, puedes abrir una demo o consultar las condiciones disponibles de Pepperstone desde nuestro enlace. Si más adelante decides operar con capital real, revisa antes qué entidad te presta el servicio, costes, producto y riesgos aplicables a tu cuenta.
Cuándo puedes considerar el dataset listo
Para mí, un histórico está listo para empezar a testear cuando puedo explicar de forma sencilla:
Qué representa.
Sé qué instrumento, mercado y fuente estoy midiendo.
Qué no representa.
Conozco sus principales limitaciones.
Cómo está construido.
Entiendo timestamps, sesiones, ajustes y resolución.
Qué he modificado.
Cualquier limpieza o transformación está documentada.
Cómo simularé la ejecución.
He decidido qué haré con bid/ask, spread, comisiones y cualquier fricción relevante para la estrategia.
Cómo puedo reproducirlo.
No depende de que recuerde manualmente veinte cambios que hice una tarde.
Solo entonces tiene sentido preguntar si el sistema funciona.
Antes, todavía estás comprobando si el experimento está bien montado.
El siguiente paso no es conseguir más datos
Aquí suele aparecer una tentación: “Perfecto, entonces voy a descargar veinte años”.
No necesariamente.
Una vez tienes datos suficientemente buenos, aparece otra pregunta diferente:
¿Cuánta evidencia necesitas para que el resultado empiece a decir algo útil?
Eso no depende únicamente de cuántos años tengas. Depende también de la frecuencia del sistema, el número de operaciones, su distribución y lo que estés intentando estimar.
Por eso, el siguiente paso del curso es cuántas operaciones necesita un backtest.
Primero aseguramos que la muestra no esté contaminada.
Después discutimos cuánto debería medir.
Ese orden importa.
Preguntas frecuentes sobre datos históricos para backtesting
¿Cuántos años de datos históricos necesito?
No existe un número universal.
Cinco años pueden contener miles de operaciones para un sistema intradía y apenas unas decenas para una estrategia muy selectiva. Además, importa qué condiciones de mercado están representadas.
La pregunta correcta no es únicamente “¿cuántos años?”, sino cuántas observaciones útiles y qué variedad de condiciones contiene el periodo. La parte estadística la desarrollamos en la siguiente lección sobre tamaño de muestra.
¿Los datos de tick siempre son mejores?
Tienen mayor resolución, pero no siempre aportan información necesaria.
Si tu sistema depende del orden exacto de movimientos intrabar, stops pequeños o ejecución muy sensible al spread, pueden ser importantes.
Si solo toma una decisión al cierre mensual, procesar cada tick probablemente sea innecesario.
Más datos no sustituyen a elegir los datos adecuados.
¿Puedo rellenar las velas que faltan?
No lo haría de forma automática.
Primero debes saber por qué falta la vela.
Puede corresponder a un cierre normal, una interrupción del mercado, falta de actividad o un problema del proveedor. Inventar un precio mediante interpolación o forward fill puede introducir operaciones que nunca habrían sido posibles.
¿Es mejor utilizar los datos de mi broker?
Si vas a operar un mercado OTC o un CFD con ese broker, su histórico puede ser especialmente relevante porque se aproxima al entorno de precios que pretendes utilizar.
Pero eso no lo vuelve infalible.
También debes comprobar cobertura, calidad, resolución y condiciones de ejecución. En mercados centralizados, los datos procedentes del exchange o de proveedores especializados pueden cumplir otra función.
¿Debo utilizar precios ajustados o sin ajustar?
Depende del instrumento y de lo que estés midiendo.
En acciones, ignorar un split puede crear un movimiento ficticio enorme. Pero tampoco deberías mezclar precios ajustados con datos de ejecución sin entender la transformación realizada.
La regla útil es sencilla: averigua exactamente qué ha ajustado tu proveedor antes de construir las señales y el P&L sobre esos precios.
