Más de 1.300 estrategias entraron al laboratorio. Sobrevivieron menos de 50.
Cinco estrategias técnicas clásicas y todas sus combinaciones posibles, evaluadas sobre 48 activos — cripto, ETFs, acciones de EE.UU., ADRs latinoamericanos y divisas — con comisiones, slippage y sin mirar el futuro. Cada variante se entrena en el 70% de la historia y se juzga en el 30% que nunca vio. Esto no es un curso de trading: es la medición honesta de cuánto sobrevive el análisis técnico al contacto con la realidad.
datos: pipeline propio (API → PostgreSQL → dbt → backtester) · actualización diaria automática · código abierto
explorador de backtests
cargando datos del pipeline…
Las reglas que hacen creíbles los números
Un backtest sin estas reglas es marketing. Cada una existe porque su ausencia infla resultados — y varias las aprendimos encontrando bugs reales, documentados en el repositorio.
sin mirar el futuro
La señal calculada al cierre del día t se ejecuta a la apertura del día t+1. Nunca se opera con información que aún no existía — el error clásico que infla backtests.
costos reales
10 pb de comisión por lado + 5 pb de slippage adverso en cada ejecución. La razón nº1 por la que estrategias "perfectas" en papel pierden dinero real.
validación 70/30
Cada variante se entrena en el 70% de la historia y se juzga en el 30% restante, que nunca influyó en su selección. Con más de 1.300 variantes, sin ventana ciega el resultado sería data dredging.
calentamiento simétrico
Los indicadores necesitan historia antes de dar señal. El corte 70/30 se toma después de ese calentamiento, para que ambas ventanas comparen regímenes equivalentes.
ganar exige operar
Una combinación que nunca entra al mercado rinde 0% y "le ganaría" a un mercado en caída. No cuenta: vencer a buy & hold requiere haber operado.
datos auditables
Más de 58.000 velas de Tiingo, Tiingo FX, Coinbase y Kraken en un warehouse PostgreSQL con arquitectura medallion, 89 tests de calidad de datos en dbt, 171 pruebas unitarias en Python y reconciliación entre fuentes. Todo reproducible desde el repo.
Las 89 pruebas, una por una
Qué se revisa antes de publicar una sola cifra
Esta es la lista completa, contada contra el manifiesto compilado de dbt. Si una falla, el pipeline se detiene y la página conserva los datos del día anterior en vez de publicar algo roto.
- 47
- not_null
- Ninguna columna que entra en un cálculo puede llegar vacía. Fue la prueba que destapó el fallo de Kraken, cuando el 100% de una fuente llegaba en NULL.
- 21
- accepted_values
- Un campo de categoría solo admite los valores del catálogo. Una clase de activo mal escrita deja de ser un dato nuevo y pasa a ser un error.
- 7
- unique_combination
- No puede existir la misma vela dos veces para el mismo activo y la misma fecha. Es lo que vuelve inofensivo reingerir.
- 6
- SQL propio
- Reglas que ninguna prueba genérica cubre: que el exceso de retorno cuadre con sus componentes, o que una combinación que nunca operó no pueda contar como ganadora.
- 4
- relationships
- Todo símbolo que aparece en un resultado tiene que existir en el catálogo de activos. Un activo huérfano falla en vez de desaparecer.
- 3
- unique
- Las llaves primarias son únicas de verdad, no por convención.
- 1
- ohlc_consistency
- El máximo del día no puede quedar por debajo del mínimo, ni la apertura fuera del rango. Detecta una fuente corrupta antes que cualquier métrica.
Encima de estas corren 171 pruebas unitarias en Python sobre el motor de backtesting, las estrategias y el cliente de cada API.