Estrategias quant Q01–Q10¶
Las diez recetas Q del catálogo (catalog/strategy_catalog.json, versión 1.0.0) son estrategias de cartera: miran varios activos a la vez, estiman algo (una volatilidad, una regresión, un filtro, una covarianza, un modelo de predicción) y producen pesos objetivo que el ledger convierte en cantidades enteras. Son el puente natural entre el banco de backtesting y los motores de modelos de la plataforma: Ridge, CatBoost, ARIMA/ETS/GARCH, NHITS, Chronos-2, TimesFM 2.5, Ledoit-Wolf, ERC y CP-SAT.
Qué vas a aprender¶
- Qué hace cada una de las diez recetas en una frase y a qué familia pertenece.
- Qué está implementado y verificado hoy (Q01–Q03) y qué está especificado pero no implementado (Q04–Q10).
- Qué motor de la plataforma cubre cada pieza de cada receta: features, modelo de predicción, riesgo, asignación, discretización a lotes, validación y ejecución.
- En qué orden conviene leer las fichas.
Estado del catálogo, sin adornos
- Q01, Q02 y Q03 están implementadas en
finazbench/policy/y tienen paridad entre el ledger de cartera y los tres carriles Nautilus de pesos: 9 PASS enruns/parity/summary_weights.json. El carril Nautilus nativo esUNSUPPORTEDpor diseño (decisión D-14): Nautilus no tiene panel, ranking transversal ni OLS de formación nativos. - Q03 tiene además un walk-forward B10 con 14 pliegues sobre NVDA/AMZN (
results/walk_forward/Q03-NVDA-AMZN-B10/summary.json). - Q04–Q10 tienen estado
specified_not_implementeden el catálogo (Q08B:optional_dependency_missing). La matriz de capacidades de la API de backtesting las declaraUNSUPPORTEDcon el motivoNOT_IMPLEMENTED_YET: H5 (Q04-Q10) is outside the current scope (D-15). Sus fichas explican la teoría, el diseño previsto y qué motores de la plataforma ya resuelven sus piezas; no hay resultados de backtest de Q04–Q10 y este manual no los inventa.
Las diez de un vistazo¶
| Id | Nombre | Familia | Estado | Motores de la plataforma implicados | Ficha |
|---|---|---|---|---|---|
| Q01 | Time-series momentum con objetivo de volatilidad | Momentum temporal + sizing por volatilidad | Implementada · paridad 3/3 PASS | finazbench/policy/q01_tsmom.py, ledger de cartera, carriles nt_weight_*; finaz_risk (volatilidad) como pieza reutilizable |
Q01 |
| Q02 | Momentum transversal 12−1, long/short | Momentum de sección cruzada | Implementada · paridad 3/3 PASS | finazbench/policy/q02_cross_sectional.py, ledger de cartera |
Q02 |
| Q03 | Pairs trading: OLS y cointegración | Reversión a la media de un par | Implementada · paridad 3/3 PASS · walk-forward B10 (14 pliegues) | finazbench/policy/q03_pairs.py, finazbench/bench/walk_forward.py; finaz_models_statistics (statsmodels) |
Q03 |
| Q04 | Pairs trading con hedge ratio de Kalman | Pares con filtro de estado | Especificada, no implementada | Filtro 2×2 propio previsto; finaz_models_statistics como familia de modelos estadísticos |
Q04 |
| Q05 | Arbitraje estadístico de residuos PCA | Stat-arb factorial | Especificada, no implementada | finaz_risk (covarianza Ledoit-Wolf, exposiciones factoriales), finaz_constraints |
Q05 |
| Q06 | Risk parity ERC con covarianza regularizada | Asignación por riesgo | Especificada, no implementada | finaz_risk.covarianza_ledoit_wolf, finaz_allocation.resolver_erc, finaz_discrete.proyectar_cpsat (G5/G6 PASS) |
Q06 |
| Q07 | HMM causal de regímenes | Cambio de régimen | Especificada, no implementada | Filtro forward previsto; finaz_models_statistics (GARCH) como alternativa de volatilidad |
Q07 |
| Q08 | Predicción walk-forward CPU: Ridge | Aprendizaje supervisado | Especificada, no implementada | finaz_models_tabular Ridge exacto (G4 PASS), finaz_training (labels, splits) |
Q08 |
| Q08B | Predicción walk-forward CPU: CatBoost | Aprendizaje supervisado (challenger) | optional_dependency_missing en el banco |
finaz_models_tabular.AdaptadorCatBoost (corre en la imagen quant, G4) |
Q08 |
| Q09 | Carry de futuros por estructura temporal | Carry | Especificada, no implementada (MISSING_DATA) |
Ninguno cubre curvas de futuros; sizing reutilizable de Q01 | Q09 |
| Q10 | Order Flow Imbalance L1 | Microestructura | Especificada, no implementada (MISSING_DATA) |
Runtime stream (finaz_runtime/stream) y reloj de eventos como base prevista |
Q10 |
El mapa quant¶
Toda estrategia de cartera sigue la misma cadena: datos → features → un modelo que estima algo → un paso de riesgo → una asignación de pesos → la conversión a lotes enteros → un validador independiente → la ejecución en el ledger. Lo que cambia entre recetas es qué caja hace el trabajo interesante.
flowchart LR
D["Datos point-in-time<br/>panel con watermark"] --> F["Features causales<br/>retornos, momentum, vol"]
F --> M["Modelos de predicción<br/>Ridge · CatBoost · ARIMA/ETS/GARCH<br/>NHITS · Chronos-2 · TimesFM 2.5"]
F --> R["Riesgo<br/>Ledoit-Wolf · VaR/ES<br/>finaz_risk"]
M --> R
R --> A["Allocation<br/>ERC · mín. varianza · máx. diversificación<br/>finaz_allocation"]
A --> X["Discreto<br/>largest-remainder · greedy · CP-SAT<br/>finaz_discrete"]
X --> V["Validador<br/>finaz_constraints<br/>ApprovedTarget"]
V --> E["Ejecución<br/>ledger SIM-S · carriles Nautilus"]
Q01(["Q01 · Q02"]) -.-> F
Q03(["Q03 · Q04"]) -.-> M
Q05(["Q05"]) -.-> R
Q06(["Q06"]) -.-> A
Q07(["Q07"]) -.-> M
Q08(["Q08 · Q08B"]) -.-> M
Q09(["Q09"]) -.-> D
Q10(["Q10"]) -.-> D
Cómo leer el mapa:
- Q01 y Q02 hacen casi todo su trabajo en las features (momentum, volatilidad, ranking) y en una fórmula de pesos cerrada; no necesitan un modelo entrenado.
- Q03 y Q04 estiman un modelo del par: una regresión OLS con test de cointegración (Q03) o un filtro de Kalman (Q04).
- Q05 vive en la caja de riesgo: PCA sobre el panel y neutralización de factores.
- Q06 vive en la caja de allocation: es un problema de optimización (ERC) y la plataforma ya lo resuelve con
finaz_allocation. - Q07 y Q08 son modelos de predicción: un HMM de regímenes y una regresión Ridge (o CatBoost) con validación walk-forward.
- Q09 y Q10 dependen sobre todo de datos que la plataforma aún no tiene: curvas de futuros por vencimiento (Q09) y cotizaciones BBO L1 (Q10).
Dos tipos de "motor"¶
Conviene separar dos cosas que en el manual aparecen juntas:
- El banco de backtesting (API de backtesting en el puerto 8000, rutas
/v1/...): ejecuta una receta del catálogo contra el ledger SIM-S y contra NautilusTrader y compara. Aquí viven Q01–Q03. - Los motores de modelos (imágenes
quant,opt,neural,chronos,timesfm25): cada uno ejecuta una operación real de su familia como job S7 (python -m finaz_runtime.jobs.runner --rol …) y deja un artefacto con hashes. Aquí viven Ridge, CatBoost, ARIMA/ETS/GARCH, Ledoit-Wolf, ERC, mínima varianza, CP-SAT, NHITS, Chronos-2 y TimesFM 2.5. La API de plataforma (puerto 18300,/platform/v1/...) es su puerta de control.
Las fichas Q04–Q10 muestran cómo las piezas de (2) encajarían en una receta de (1). Eso es diseño, no una integración ya hecha.
Cifras reales que aparecen en las fichas¶
| Evidencia | Fichero | Qué dice |
|---|---|---|
| Paridad de cartera | runs/parity/summary_weights.json |
12 casos: 9 PASS, 3 UNSUPPORTED (nativo). Q01/Q02 sobre 34 valores US diarios (2690 barras), Q03 sobre NVDA/AMZN (2941 barras) |
| Walk-forward Q03 | results/walk_forward/Q03-NVDA-AMZN-B10/summary.json |
14 pliegues 24/24/6/12 meses, 20 bloques admitidos de 168 |
Job G4 quant |
qa_reports/v2/runs/2026-09-20/g4-quant-001.result.json |
Ridge PASS (RMSE 0,0169 sobre sintético 200×4), CatBoost 1.2.8 PASS, ARIMA/ETS |
Job G5 opt |
qa_reports/v2/runs/2026-09-20/g5-opt-001.result.json |
ERC 50/50 OPTIMAL, mín. varianza OPTIMAL (Clarabel), CP-SAT OPTIMAL lotes [5, 1, 4] |
Job G7 neural |
qa_reports/v2/runs/2026-09-22/g7/g7-neural-002.result.json |
NHITS: MAE 0,709 frente a 1,415 del baseline (skill 0,499) |
| Jobs G8 | qa_reports/v2/runs/2026-09-20/g8-*.result.json |
Chronos-2 y TimesFM 2.5: inferencia real con pesos verificados por SHA |
Todos los datos de los jobs G4–G8 son sintéticos y deterministas (semilla fija): prueban que el motor funciona, no que una estrategia gane dinero.
Guía de lectura¶
- Empieza por Q01: es la más sencilla y presenta el vocabulario común (rebalanceo,
frozen_equity,decision_price = close[t], fill enopen[t+1], truncado hacia cero). - Sigue con Q02 (ranking transversal y desempates) y Q03 (modelo por bloques, máquina de estados, walk-forward).
- Lee Q06 y Q08 a continuación: son las dos recetas no implementadas cuyo motor ya corre en la plataforma (ERC + CP-SAT; Ridge + CatBoost).
- Q04 y Q05 extienden Q03 (filtro de Kalman; PCA de muchos activos).
- Q07, Q09 y Q10 son las más especializadas: regímenes, futuros y microestructura.
Para el contexto: Estrategias de cartera Q01–Q03, Walk-forward, Catálogo de motores y Modelos: jobs S7.
Cada ficha tiene la misma estructura¶
| Sección | Qué encontrarás |
|---|---|
| Tabla de identidad | Familia, datos, features, parámetros con sus defaults, estado y motores implicados |
| Qué vas a aprender / La idea en una frase | El objetivo de la ficha y la receta resumida |
| Intuición y evidencia académica | Por qué podría funcionar y cuándo falla, sin citas inventadas |
| El modelo matemático | Fórmulas en notación de texto y pseudocódigo causal |
| Cómo lo hace la plataforma | Qué paquete calcula cada pieza, con un diagrama |
| Ejemplo numérico | Del fixture de la especificación, de la evidencia de paridad, de un job real o didáctico y declarado como tal |
| Cómo lanzarla | Petición a la API o job S7 del motor subyacente |
| Riesgos, Resumen, Para practicar | Límites honestos y ejercicios |
Notación
Las fórmulas se escriben en bloques de código con notación de texto (sum, sqrt, ln, x' para traspuesta). Los índices t son barras (sesiones en diario); S es el número de activos; w son pesos sobre el capital; q son cantidades enteras.
Resumen¶
- Diez recetas, once templates (Q08 se desdobla en Q08 Ridge y Q08B CatBoost).
- Tres implementadas con paridad (Q01–Q03), siete especificadas y fuera del alcance vigente (Q04–Q10).
- La plataforma ya tiene motores reales para varias piezas de las no implementadas: Ridge y CatBoost (Q08), Ledoit-Wolf, ERC y CP-SAT (Q06), estadísticos (Q03/Q04/Q07).
Para practicar¶
- Para cada Q, señala en el mapa quant la caja que hace el trabajo principal. ¿Coincide con la tabla?
- Consulta
GET /v1/capabilitiesen la API de backtesting y localiza la razónunsupported_reasonde Q08B, Q09 y Q10. ¿Por qué son distintas de la de Q04? - ¿Qué receta no implementada estaría más cerca de poder ejecutarse si mañana se conectasen los motores al banco? Justifícalo con los jobs G4/G5.