A quién va dirigido — A quien gestione una estrategia autorizada y deba distinguir un incidente técnico, un problema de ejecución, un posible deterioro del modelo, un cambio de régimen y la variabilidad normal antes de decidir si limitarla o suspenderla.
La monitorización de una estrategia compara continuamente el comportamiento observado, los supuestos validados y los límites operativos. La suspensión es una de las posibles medidas de control: impide nuevas exposiciones o limita partes del proceso mientras se protege el capital y continúa el diagnóstico. No es una conclusión automática sobre el valor económico del modelo.
Una alerta indica que una medida ha superado una condición predefinida; por sí sola no identifica la causa. El mismo drawdown puede proceder de variabilidad normal, precios corruptos, órdenes duplicadas, cambios en el slippage o una relación predictiva debilitada. Detener una estrategia tras un número fijo de pérdidas consecutivas confunde una secuencia observada con un diagnóstico y puede producir paradas y reinicios procíclicos.
Taxonomía de desviaciones
| Clase | Señales observables | Primera pregunta | Posible respuesta |
|---|---|---|---|
| Incidente de datos u operativo | Feed obsoleto, valores imposibles, proceso detenido, posición sin conciliar | ¿Tiene el sistema un estado fiable? | Bloquear, conciliar, corregir o hacer rollback |
| Deriva de ejecución | Más rechazos, peores ejecuciones, latencia, impacto o préstamo modificado | ¿Se ha alejado la implementación de sus supuestos? | Reducir tamaño, cambiar enrutamiento, recalibrar capacidad |
| Deterioro del modelo | Errores de previsión o payoffs persistentes fuera de lo esperado | ¿Sigue siendo compatible con los datos la relación modelizada? | Revisión independiente y revalidación |
| Cambio de régimen | Cambio amplio en volatilidad, liquidez, correlaciones o estructura | ¿Ha cambiado el proceso externo pertinente? | Límites por régimen, reducción o suspensión razonada |
| Variabilidad normal | Fluctuaciones dentro de la incertidumbre prevista | ¿Era plausible el evento bajo el modelo validado? | Continuar bajo vigilancia, sin ajustes impulsivos |
Las clases pueden coexistir. Un cambio de liquidez puede producir una deriva de ejecución y reducir el rendimiento neto sin invalidar la señal bruta. Por ello, el diagnóstico debería descomponer datos, señal, cartera, órdenes y economía de la ejecución.
Umbrales justificados, no números mágicos
Un umbral útil nace de una distribución de referencia, de la materialidad económica y de la capacidad para intervenir. Debe especificar métrica, ventana, frecuencia, calidad de los datos, dirección, gravedad y acción. Una tolerancia casi nula puede ser adecuada para un control operativo —por ejemplo, órdenes duplicadas o incumplimiento de un límite absoluto—, mientras que una métrica estadística exige intervalos y persistencia coherentes con su variabilidad.
El drawdown es una medida importante de la trayectoria, no un diagnóstico autónomo. Una secuencia de pérdidas depende del porcentaje de aciertos, la dependencia, la asimetría y los regímenes; ningún número universal dicta cuándo debe detenerse una estrategia. Los umbrales calibrados sobre el mismo backtest pueden estar también sobreajustados.
Un diseño multinivel reduce la ambigüedad:
- advertencia, que aumenta la frecuencia y profundidad de los controles;
- limitación, que reduce el riesgo, el universo o la funcionalidad bajo reglas autorizadas;
- suspensión, que impide nuevas exposiciones mientras las existentes se gestionan según un plan;
- kill switch, que interrumpe rápidamente funciones definidas cuando la seguridad lo exige.
Las acciones no deberían depender únicamente del P&L. La integridad de los datos, la posición, los límites de riesgo, las órdenes anómalas y la capacidad de conciliar pueden tener prioridad.
Protocolo de monitorización y escalado
- Definir el perímetro validado. Versión, datos, mercados, tamaño, horarios, bróker, costes, benchmark, dependencias y condiciones de uso permitidas.
- Mapear controles y responsables. Asignar a cada métrica una fuente, frecuencia, umbral, gravedad, destinatario, autoridad para intervenir y alternativa de respaldo.
- Separar indicadores. Distinguir integridad de datos, salud operativa, ejecución, exposiciones, rendimiento y variables de régimen.
- Predefinir el escalado. Establecer quién puede limitar, suspender, cancelar órdenes, cerrar posiciones o activar el kill switch y cómo se informa a las funciones afectadas.
- Conservar el estado. Guardar feeds, señales, órdenes, ejecuciones, posiciones, logs, configuración e intervenciones antes de que reinicios o correcciones borren evidencia.
- Contener antes de diagnosticar cuando sea necesario. La incertidumbre sobre la causa no justifica continuar si la posición o el control no son fiables.
- Realizar un análisis de causa raíz. Clasificar incidente, deriva de ejecución, deterioro, régimen o variabilidad normal y buscar causas concurrentes.
- Documentar la decisión y las condiciones de salida. Responsable, plazo, riesgo residual, comunicaciones y evidencia exigida deben ser explícitos.
Kill switch, rollback y suspensión
Un kill switch es un mecanismo de contención rápida. Puede detener el envío de órdenes nuevas, cancelar órdenes abiertas o activar un procedimiento definido para las posiciones; no significa necesariamente liquidarlo todo de inmediato, algo que podría aumentar el riesgo en mercados ilíquidos.
Un rollback restaura una versión técnica previamente autorizada cuando el problema es atribuible a una versión o configuración. Requiere datos, estado y posiciones compatibles y no siempre es seguro ni posible. La suspensión del modelo, en cambio, se refiere al uso de la estrategia y puede mantenerse tras la restauración técnica hasta completar el diagnóstico.
Reactivación, revalidación y versión nueva
La gestión de versiones (versioning) debe conservar qué configuración estaba autorizada, qué evidencia motivó el cambio y desde cuándo es efectiva.
La reactivación no debería seguir a la primera operación favorable ni a un plazo arbitrario. Tras un incidente puramente operativo, la misma versión puede reanudar finalmente su actividad si se concilian estado y controles y las pruebas de recuperación tienen resultados documentados. Un cambio material en variables, parámetros, universo, dimensionamiento, costes o lógica de órdenes crea, en cambio, una versión nueva.
La revalidación debe ser proporcional al cambio y al daño potencial: análisis de causa raíz, pruebas de regresión, comprobaciones de robustez, revisión independiente y un nuevo forward test cuando proceda. El periodo que guio la modificación pertenece al desarrollo de la nueva versión y no sigue siendo una prueba OOS pura.
Ejemplo ilustrativo
Ejemplo expresamente ilustrativo — Una alerta informa de precios sin cambios y de un aumento de órdenes rechazadas. El control suspende órdenes nuevas, conserva logs y posiciones e inicia la conciliación. La causa resulta ser un feed obsoleto después de una versión: el sistema vuelve a la versión autorizada, verifica datos y estado y somete la corrección a pruebas de regresión. El evento no se etiqueta como «cambio de régimen» basándose en el P&L observado, y la intervención no espera a un número predeterminado de pérdidas.
Si datos y operaciones están íntegros, pero las métricas se alejan de las expectativas, el escalado puede comenzar con mayor vigilancia y límites reducidos. La alerta sigue siendo evidencia que debe diagnosticarse, no una prueba inmediata de que la ventaja ha desaparecido.
Limitaciones
- Las distribuciones históricas pueden infravalorar eventos nuevos o cambios estructurales.
- Demasiadas alertas aumentan el ruido y el riesgo de insensibilización; muy pocas dejan puntos materiales sin cubrir.
- Reducir o detener una estrategia puede generar costes, impacto y riesgo residual.
- Una monitorización sofisticada no corrige un backtest contaminado ni una gobernanza sin autoridad efectiva.
- Los requisitos regulatorios dependen de la jurisdicción, la entidad y la actividad; esta página no determina obligaciones legales individuales.
Fuentes
- Joseph Simonian, CFA Institute Research Foundation, Investment Model Validation: A Guide for Practitioners, 2024 — validación proactiva, monitorización y fiabilidad de los modelos de inversión.
- Board of Governors of the Federal Reserve System, SR 26-2: Model Risk Management, 2026 — gobernanza, validación, límites de uso y monitorización; se aplica a las organizaciones bancarias dentro de su ámbito de supervisión y se cita aquí únicamente como referencia de gobernanza.
- Comisión Europea, Reglamento Delegado (UE) 2017/589, RTS 6 — controles, pruebas, límites y funcionalidad operativa dentro del ámbito de trading algorítmico de la UE al que se aplica.
- Autoridad Europea de Valores y Mercados, Supervisory Briefing on Algorithmic Trading in the EU, 2026 — gobernanza, pruebas, externalización y controles pre-trade; orientación supervisora no vinculante dentro de su ámbito.
- U.S. Securities and Exchange Commission, Staff Report on Algorithmic Trading in U.S. Capital Markets, 2020 — automatización, riesgos operativos e interacción de los algoritmos con la estructura del mercado estadounidense.