Checklist de incidentes de trading

Empiece con una cronología reconstruible

Una revisión de incidente debe conservar evidencia suficiente para que un lector posterior responda una pregunta simple: ¿qué sabía, decidió, envió, recibió e hizo después el sistema en cada momento significativo? Construya el registro alrededor de una sola cronología, usando marcas de tiempo coherentes, información de zona horaria y una fuente de reloj identificada. Incluya el inicio del comportamiento anómalo, la detección, cualquier salvaguarda automatizada, intervención humana, confirmaciones del centro de ejecución, pasos de recuperación y el momento en que se confirmaron condiciones operativas normales.

Mantenga los eventos sin procesar separados de la interpretación del revisor. Una cronología puede contener una interrupción de datos de mercado, un envío de orden, una solicitud rechazada, un evento de límite de riesgo y una acción de operador. El análisis posterior puede conectar esos eventos, pero conservar la secuencia original permite revisar los supuestos a medida que surge nueva evidencia.

Cuando los sistemas se comunican de forma asíncrona, conserve identificadores de correlación que vinculen una decisión con su entrada, una orden con la respuesta del centro de ejecución y una alerta con el proceso o la persona que la gestionó. Sin esos vínculos, los registros pueden ser abundantes pero aun así no explicar relaciones causales.

• Registre marcas de tiempo con el contexto de zona horaria y fuente de reloj.
• Conserve identificadores de solicitudes, órdenes, ejecuciones, alertas e intervenciones.
• Diferencie la evidencia de eventos sin procesar de las anotaciones posteriores.

Conserve el contexto de decisión, no solo las órdenes

Los registros de órdenes y ejecuciones son esenciales, pero rara vez explican por qué ocurrió una acción. Conserve el contexto de decisión disponible para el sistema en ese momento: estado relevante de datos de mercado, configuración de instrumentos y centros de ejecución, versión de estrategia o flujo de trabajo, parámetros vigentes, restricciones de cuenta o enrutamiento y códigos de motivo producidos por la lógica de decisión cuando estén disponibles.

Para un incidente que implique exposición inesperada o intentos de ejecución repetidos, la revisión debe poder determinar si el comportamiento siguió las reglas configuradas, fue resultado de entradas desactualizadas o incompletas, o se produjo después de un cambio de configuración. Eso requiere copias inmutables o referencias de versión para la configuración exacta y el artefacto de código o despliegue implicado.

Aquí también deben documentarse límites de riesgo explícitos. Conserve los límites configurados en ese momento, su alcance, utilización inmediatamente antes y durante el incidente, cualquier anulación y la acción que cada umbral incumplido debía activar. Un control de riesgo no puede evaluarse solo por la aparición de una alerta; la revisión debe mostrar si el control estaba activo, era observable y resultó eficaz dentro de su límite previsto.

Capture ejecución observable en todos los centros de ejecución

La ejecución multivenido crea múltiples registros de una misma historia operativa. Conserve mensajes salientes de órdenes, confirmaciones de centros de ejecución, rechazos, cancelaciones, modificaciones, informes de ejecución y resultados de conciliación. Registre la ruta prevista y la utilizada realmente, incluidos comportamientos de respaldo o decisiones de enrutamiento que cambiaron durante el incidente.

La evidencia debe permitir comparaciones entre estado interno y estado externo. Si un sistema interno marcó una orden como cancelada mientras un centro de ejecución informó más tarde una ejecución, la revisión necesita los mensajes y marcas de tiempo que muestran cuándo divergieron esos estados. De forma similar, conserve información de conectividad y sesión cuando pueda explicar confirmaciones retrasadas, envíos duplicados o actualizaciones de estado incompletas.

Evite reducir la evidencia de ejecución a una instantánea de posición final. Los resultados finales pueden ocultar riesgos intermedios importantes, como exposición temporalmente abierta, reintentos repetidos, gestión de cancelación incompleta o monitorización retrasada. La ejecución observable significa conservar suficiente detalle para inspeccionar el camino desde la instrucción hasta el resultado externo confirmado.

• Conserve tanto el estado interno de la orden como el estado informado por el centro de ejecución.
• Retenga decisiones de enrutamiento, rutas de respaldo y mensajes de respuesta del centro de ejecución.
• Incluya salidas de conciliación y desajustes sin resolver.

Documente la supervisión humana y las acciones de control

Un registro de incidente útil hace visible la supervisión humana. Conserve quién recibió una alerta, cuándo la confirmó, qué información estaba disponible, qué acción se tomó y qué autoridad o procedimiento respaldaba esa acción. No se trata de asignar culpas; se trata de comprender cómo funcionaron los controles operativos bajo presión.

Registre salvaguardas automatizadas junto con acciones humanas. Algunos ejemplos son un bloqueo por límite de riesgo, una pausa de trading, un evento de limitación de frecuencia, una respuesta de cortacircuito o una notificación de escalamiento. Para cada una, indique la expectativa configurada y el resultado observado. Si un operador anuló, pausó, reanudó o cambió un control, conserve el motivo, la ruta de aprobación cuando corresponda y el cambio exacto de configuración.

Las comunicaciones pueden ser evidencia relevante cuando afectan a la ejecución o recuperación. Conserve notas concisas del canal de incidentes, registros de relevo y resúmenes de decisiones, aplicando controles de acceso y prácticas de retención adecuados. Una revisión no necesita cada conversación; necesita las decisiones que cambiaron el estado operativo del sistema.

• Registre entrega, confirmación y escalamiento de alertas.
• Registre pausas, anulaciones, reanudaciones y cambios de configuración.
• Capture la justificación y autoridad de las intervenciones materiales.

Mantenga la revisión reproducible

El análisis posterior es más sólido cuando otro revisor puede reproducir la ruta de investigación sin reconstruirla de memoria. Conserve el conjunto de datos del incidente con sumas de verificación u otras referencias de integridad, documente lagunas conocidas e identifique las herramientas, consultas, paneles y transformaciones usados para elaborar la revisión. Si los datos se filtraron, agregaron, normalizaron o corrigieron manualmente, registre ese hecho y la regla aplicada.

La evaluación reproducible no exige una repetición perfecta de cada condición de producción. Exige un registro claro de qué evidencia se utilizó, qué no estuvo disponible y cómo se derivaron las conclusiones. Cuando se use una repetición o simulación para examinar comportamiento, etiquétela como ejercicio analítico y conserve las entradas, supuestos y entorno versionado necesarios para repetirla.

Separe hallazgos confirmados de hipótesis y propuestas de corrección. Una revisión práctica puede indicar que una secuencia de mensajes está confirmada, que una explicación causal sigue bajo investigación y que se propone un cambio de control. Esta disciplina evita que lectores posteriores traten una teoría inicial como hecho establecido.

Ejemplo: una ayuda compacta para decidir sobre evidencia

Ejemplo únicamente: suponga que la monitorización identifica un breve período de reintentos inesperados de órdenes después de que un centro de ejecución deje de confirmar solicitudes. La revisión del incidente no debe empezar decidiendo que el centro de ejecución, la lógica de estrategia o el operador causaron el problema. Primero debe conservar la evidencia necesaria para distinguir entre esas posibilidades.

Use la siguiente ayuda de decisión para determinar si un registro está lo suficientemente completo para un análisis posterior. Si alguna respuesta es no, registre explícitamente la laguna e identifique al responsable y el riesgo de retención antes de continuar la investigación.

IMRYN presenta infraestructura de trading sistemático y ejecución multivenido, con autonomía con límites, controles de riesgo y monitorización continua como conceptos públicos de producto. En ese contexto, este ejemplo es una guía educativa para documentar eventos de infraestructura y riesgo operativo. No describe un despliegue específico de IMRYN, no afirma ningún resultado ni proporciona asesoramiento de inversión.

• ¿Puede vincularse cada reintento con su entrada desencadenante, decisión interna y respuesta del centro de ejecución o ausencia de respuesta?
• ¿Se conservaron los ajustes de reintento activos, límites de riesgo, reglas de enrutamiento y versión de despliegue?
• ¿Puede la revisión mostrar cuándo alertó la monitorización, si se activó una salvaguarda y qué hizo un operador humano?
• ¿Puede conciliarse el estado interno de la orden con los mensajes posteriores y registros finales del centro de ejecución?
• ¿Puede otro revisor volver a ejecutar las consultas documentadas y llegar a la misma cronología factual?