Verificaciones de riesgo pre-trade dentro de la ruta de la orden

Una orden llega al gateway. Antes de salir hacia el venue, algo tiene que decidir si la cuenta puede enviarla. Esa decisión corre en cada orden, incluida la inmensa mayoría que están perfectamente bien, así que su coste lo paga todo el tráfico normal y no solo los rechazos.

Esa es la restricción que hay que nombrar primero. Una verificación de riesgo colocada en la ruta de la orden es un impuesto sobre la entrada de órdenes. La pregunta de ingeniería no es cómo hacer la verificación inteligente, sino cómo hacerla lo bastante pequeña como para que los traders no la noten, y lo bastante honesta como para que siga rechazando las órdenes que debe rechazar.

Qué pertenece realmente a la ruta de la orden

El hot path responde exactamente a una pregunta: ¿puede enviarse esta orden ahora mismo, dado lo que sabemos actualmente de esta cuenta? Las verificaciones que responden a esa pregunta se quedan. Las que responden a otra pregunta salen.

• Límites de posición y exposición: la posición resultante en el instrumento, el grupo y la cuenta, comparada con los límites configurados
• Margen o poder de compra: si la cuenta todavía tiene espacio para la orden bajo el modelo de margen actual
• Límites fat-finger: tamaño de la orden, nocional y distancia de precio respecto a una referencia, para atrapar la errata antes que el venue
• Estado del instrumento y de la cuenta: negociación detenida, cuenta restringida, close-only, producto no habilitado para esta cuenta
• Estado del kill switch: un único flag que anula todo lo anterior
• Controles de duplicados y de self-trade allí donde el venue no los ofrece

Todo lo demás corre al lado de la ruta, sobre el mismo estado, sin retener la orden. Alimenta los límites que el hot path aplica, pero no se interpone entre el trader y el venue.

• Analítica de riesgo de cartera: escenarios, pruebas de estrés, exposición correlacionada entre cuentas
• La revaloración del modelo de margen cuando cambian los parámetros, y cualquier recálculo que toque todo el libro
• La vigilancia y la detección de patrones, que necesitan un histórico que el hot path deliberadamente no lleva
• Informes, reconciliación y cualquier cosa que hable con una base de datos o un servicio externo
• La revisión de crédito y de contraparte, que por naturaleza opera en un reloj más lento

Dónde vive el estado de posiciones y por qué la base de datos no está en la ruta

El estado que necesita una verificación pre-trade - posiciones actuales, órdenes activas, margen usado y disponible, configuración de límites - vive en la memoria del proceso que toma la decisión. No en una caché delante de una base de datos, ni detrás de una llamada de red. En el proceso.

La razón no es solo la velocidad, aunque una consulta es órdenes de magnitud más cara que una búsqueda en un array local. La razón es la corrección. Una base de datos guarda la posición tal como se escribió. La verificación de riesgo necesita la posición incluyendo las órdenes enviadas hace un momento que aún no se han ejecutado, confirmado ni persistido. Si lees del almacenamiento, compruebas contra un pasado que tu propio flujo ya ha dejado atrás.

En la práctica, eso moldea el proceso como se moldea cualquier componente de baja latencia:

• Un solo escritor por cuenta. Las cuentas se reparten en shards entre instancias de riesgo para que el estado de una cuenta nunca tenga contención, y no se toma ningún lock en la ruta de órdenes
• Estructuras planas y preasignadas: arrays de tamaño fijo indexados por id de cuenta e instrumento, resueltos al inicio de la sesión, no búsquedas hash sobre cadenas construidas por orden
• Sin asignación de memoria, sin I/O y sin logging que bloquee en la ruta de decisión; el registro de auditoría se pasa a otro hilo a través de una cola
• La configuración que cambia sin reinicio se sustituye como un snapshot inmutable completo, de modo que la verificación nunca lee un límite a medio actualizar

La base de datos es donde se registra la posición. No es donde se conoce la posición.

Recálculo incremental, no una pasada completa

Un recálculo completo de la exposición y el margen de una cuenta recorre cada posición y cada orden activa. Ese coste crece con el tamaño del libro, lo que significa que la verificación de riesgo se volvería más lenta justo para los clientes que más operan. Por eso el hot path no recalcula. Aplica un delta.

La cuenta lleva agregados corrientes: exposición neta y bruta por instrumento y por grupo, margen usado, nocional en vuelo. Una orden entrante produce un pequeño cambio en esos agregados, los valores cambiados se comparan con los límites y la orden se acepta o se rechaza. El trabajo es proporcional a la orden, no a la cartera.

• Al enviar, el efecto en el peor caso de la orden se reserva contra los agregados, de modo que dos órdenes en vuelo no pueden caber ambas en el mismo margen restante
• En caso de rechazo, cancelación o expiración, la reserva se libera; en caso de ejecución, la reserva se sustituye por el cambio de posición realizado
• Las ejecuciones parciales ajustan ambos lados de eso en un solo paso, y ahí es donde viven realmente la mayoría de los bugs de este tipo de engine
• Las reglas de neteo y agrupación se resuelven al cargar el instrumento, no por orden, así que el delta son un puñado de operaciones aritméticas

El recálculo completo sigue existiendo: de forma programada, cuando cambian los parámetros de margen y como autocomprobación periódica frente al resultado incremental. Corre fuera de la ruta, sobre una copia, y su resultado o bien se sustituye o bien se levanta como discrepancia. Un estado incremental que se desvía en silencio del estado real es peor que no tener verificación, así que la comparación no es opcional.

El kill switch es una ruta aparte

Un kill switch se usa precisamente cuando algo ya va mal. Eso descarta construirlo sobre la maquinaria que puede ser justamente lo que falla. Es una ruta aparte, con sus propias reglas.

• Es un único flag atómico leído al principio de la verificación, antes de tocar el estado de posiciones, el margen o los datos del instrumento, así que funciona incluso cuando esos están obsoletos, ausentes o rotos
• Se activa desde varios disparadores independientes: una acción de operador, una condición automática, la pérdida del feed de datos de mercado o de ejecuciones del que depende el estado de riesgo
• Falla en cerrado. Si el proceso de riesgo no puede establecer que tiene un estado válido, el gateway se comporta como si el switch estuviera activado
• Tiene alcances - toda la firma, una mesa, una cuenta, una estrategia - porque un switch que solo puede pararlo todo se usa demasiado tarde
• Activarlo es una acción y una confirmación, no un despliegue de configuración; desactivarlo es deliberado y queda siempre registrado

Parar las órdenes nuevas es la mitad fácil. La mitad difícil es lo que el switch hace con las órdenes que ya están en reposo en el venue: retirar cotizaciones y cancelar órdenes activas tiene que ser posible mientras la ruta de envío está deshabilitada. Esa ruta de cancelación merece sus propias pruebas, porque se ejercita en el peor día y no en uno normal.

El reinicio y cómo vuelve el estado

El estado en memoria es una vista derivada de un registro duradero. Eso es lo que hace sobrevivible un reinicio. Todo evento que cambia el estado de riesgo - una orden aceptada, una reserva liberada, una ejecución aplicada, un límite cambiado, el switch activado - se añade a un journal en la máquina local antes de actuarse aguas abajo.

• Al arrancar, el proceso reproduce el journal para reconstruir los agregados y luego reconcilia contra el venue y el drop copy de compensación para posiciones y órdenes activas
• Hasta que la reconciliación termina, la cuenta no está abierta para operar. Un motor de riesgo que acepta órdenes mientras todavía está averiguando la posición no es un motor de riesgo
• Una discrepancia entre el estado reproducido y la visión del venue detiene esa cuenta y levanta una alerta; nunca se resuelve prefiriendo en silencio a una de las partes
• Un hot standby sigue el mismo journal, así que un failover restaura un estado caliente en lugar de una reproducción en frío, y el standby se verifica promoviéndolo con regularidad y no sobre el papel

El tiempo de recuperación depende entonces de la longitud del journal y de la disponibilidad del drop copy, no del tamaño del libro, y el modo de fallo ante cualquier incógnita es el mismo: negarse a operar la cuenta.

Qué no te da este diseño

Vale la pena enunciar los límites honestos con claridad, porque deciden si esta arquitectura encaja siquiera:

• La verificación es tan correcta como el feed de ejecuciones. Si el drop copy o los reportes de ejecución se retrasan, la exposición queda subestimada, y la respuesta correcta es degradar a límites conservadores o activar el switch, no seguir operando sobre un estado obsoleto
• Los modelos de margen de cartera que son genuinamente no aditivos se resisten a la evaluación incremental. Lo que funciona es una cota incremental conservadora en la ruta más un modelo completo fuera de ella; el precio es que se rechazan algunas órdenes que un modelo completo habría permitido
• El switch protege contra tu propio flujo, no contra el mercado. No puede evitar un gap o un slippage en posiciones que ya tienes
• El estado en proceso hace que el motor de riesgo y el gateway de órdenes compartan destino. Eso compra latencia y cuesta la capacidad de escalarlos por separado
• El sharding de un solo escritor por cuenta dificulta los límites entre cuentas, y las verificaciones a nivel de firma necesitan una capa de agregación más lenta con su propio desfase
• Supone más trabajo operativo que una verificación apoyada en base de datos: journals, reconciliación, simulacros de promoción del standby. Si la entrada de órdenes no es sensible a la latencia, esta complejidad no compensa

amBrain construye este tipo de ruta de riesgo pre-trade para brókers y prop firms, con los hot paths escritos en Rust. El equipo trabaja en infraestructura de trading desde Ereván, Armenia, desde 2019.