FIX, REST y WebSocket para el flujo de órdenes de brokers

En casi todas las configuraciones, la ruta de órdenes es mixta

En casi todas las configuraciones de brokers o prop firms, el flujo de órdenes cruza al menos dos interfaces antes de llegar a un centro de negociación. Una aplicación de cliente puede enviar una orden mediante REST, recibir actualizaciones por WebSocket y luego transmitir las órdenes a un proveedor de liquidez o una bolsa mediante FIX.

Rara vez se trata de elegir un solo protocolo para todo. La decisión es qué interfaz se encarga de cada acción y cómo se comporta el sistema cuando se pierde una confirmación o una actualización.

Empiece por el ciclo de vida de la orden, no por una preferencia de protocolo. Trace el envío, la confirmación, la modificación, la cancelación, el rechazo, la ejecución parcial, la ejecución y la corrección.

Para cada transición, registre el sistema de registro, el identificador del mensaje y la vía de recuperación. Esto permite detectar brechas, como un tiempo de espera agotado en REST después de que el servidor haya aceptado una orden, o una desconexión de WebSocket durante una ejecución parcial.

Los equipos que comparan diseños de plataformas pueden consultar la cobertura de infraestructura de Trading Technology's como contexto, pero la decisión debe basarse en el comportamiento medido en la ruta real.

Trate las interfaces como contratos distintos

FIX es un protocolo de sesión con tipos de mensaje definidos, números de secuencia, mensajes de actividad y mecanismos de recuperación. Es adecuado para el flujo de órdenes persistente y con estado entre empresas y centros de negociación.

Aun así, las implementaciones varían según la contraparte, la versión de FIX y los campos admitidos. La certificación, la configuración de la sesión y la gestión cuidadosa de los reinicios de secuencia son parte del trabajo, no un perfeccionamiento opcional.

REST es un modelo de solicitud y respuesta sobre HTTP. Es sencillo de integrar, inspeccionar y operar, y resulta adecuado para operaciones de cuenta, envío de órdenes a ritmos moderados y acciones administrativas.

El caso difícil es un resultado ambiguo: el cliente agota el tiempo de espera, pero puede que el servidor haya aceptado la orden. Reintentar un POST sin un ID de orden de cliente estable y un comportamiento de idempotencia documentado puede generar un duplicado.

WebSocket es un transporte persistente, no un estándar de mensajes de trading. Los proveedores suelen utilizarlo para enviar eventos de órdenes y ejecuciones, datos de mercado o actualizaciones de cuenta.

Algunos también aceptan órdenes a través de este protocolo. La reconexión por sí sola no recupera los eventos perdidos, por lo que la API debe ofrecer números de secuencia, repetición de eventos, una nueva instantánea u otra vía de conciliación.

• Para FIX, pruebe el inicio de sesión, la pérdida de mensajes de actividad, las solicitudes de retransmisión, los informes de ejecución duplicados y la conmutación por error entre sesiones.
• Para REST, pruebe los límites de solicitudes, el comportamiento ante tiempos de espera agotados, la idempotencia, la paginación y si se puede consultar una orden mediante el ID de cliente.
• Para WebSocket, pruebe la gestión de mensajes de actividad, las brechas de secuencia, la espera progresiva antes de reconectar y la coherencia entre la instantánea y el flujo.

En los tres casos, conserve un ID de orden interno duradero y relaciónelo con los identificadores del cliente, el broker y el centro de negociación. Los reportajes de Trading Technology's sobre infraestructura de brokers cubren el contexto más amplio de las plataformas; aun así, el contrato de integración debe verificarse con las especificaciones de cada proveedor.

Calcule el costo de integración y el de los fallos

La elección del protocolo afecta el esfuerzo de ingeniería, la certificación y el soporte continuo. Las cifras siguientes son rangos habituales del mercado para una integración entre un broker y un proveedor. Los cargos directos varían según el proveedor y el modelo de conectividad; estos rangos no incluyen salarios, comisiones de trading de los centros de negociación ni colocación en centros de datos.

Son rangos para la planificación, no cotizaciones. Un proveedor puede incluir el acceso a WebSocket junto con REST, cobrar por separado los datos de mercado o exigir una línea FIX de pago y certificación. Solicite el calendario completo de tarifas y las condiciones del entorno de pruebas antes de comparar propuestas.

La latencia también requiere un punto de medición definido. Registre por separado la hora de envío del cliente, la recepción en la pasarela, la confirmación del centro de negociación y el evento de ejecución. Las rutas por internet pública suelen producir tiempos de ida y vuelta de decenas de milisegundos, mientras que una ruta bien configurada con colocación en centros de datos puede situarse en unos pocos milisegundos o menos. Son rangos habituales del mercado, no un compromiso de servicio. El proveedor, la geografía, la ruta de red y la carga del motor de casación son factores relevantes.

Diseñe la recuperación en torno al estado de la orden

Un socket activo no demuestra que el libro de órdenes de la aplicación sea correcto. Mantenga una máquina de estados que procese confirmaciones e informes de ejecución, elimine eventos duplicados y concilie las órdenes abiertas y las ejecuciones con una fuente autorizada. En FIX, MsgSeqNum y la gestión de retransmisiones restauran los mensajes de sesión, pero por sí solos no demuestran que la aplicación haya procesado correctamente todos los eventos de negocio.

Defina y documente el comportamiento esperado para cuatro casos ambiguos: se agotó el tiempo de espera del envío, se agotó el tiempo de espera de la cancelación, se desconectó el flujo después de una ejecución parcial y se reinició el proceso con órdenes aún activas. En cada caso, identifique si el sistema consulta por ID de orden de cliente, solicita una instantánea de órdenes abiertas, reproduce eventos o escala el caso a un operador. No vuelva a enviar una orden simplemente porque haya vencido el temporizador local de confirmación.

Establezca umbrales a partir de las distribuciones observadas en producción. Haga seguimiento de la latencia de confirmación p50, p95 y p99, la tasa de rechazos, el retraso de eventos, la cantidad de reconexiones, las brechas de secuencia y las diferencias de conciliación. Un primer objetivo útil es generar una alerta por cualquier orden sin conciliar, no solo cuando aumenta un percentil de latencia. Conserve los mensajes de protocolo sin procesar el tiempo suficiente para explicar disputas y reproducir un defecto en un entorno controlado.

Aplique esta lista de comprobación durante cinco días laborables

Limite el alcance a una ruta representativa y un tipo de cuenta. El objetivo de esta semana es reunir evidencia que permita tomar una decisión, no realizar una reescritura amplia.

1. Día uno: trace el ciclo de vida. Represente cada transición de la orden, desde el envío del cliente hasta el informe de ejecución final. Indique dónde se crean, transforman y conservan los identificadores.
2. Día uno: lea el contrato del proveedor. Confirme los tipos de órdenes admitidos, los límites de solicitudes, las reglas de idempotencia, los reinicios de sesión, la repetición de eventos y las diferencias del entorno de pruebas. Anote las preguntas pendientes para el proveedor.
3. Día dos: instrumente las marcas de tiempo. Capture las horas de envío, recepción en la pasarela, confirmación y evento de ejecución con relojes sincronizados. Compruebe el desfase de los relojes y almacene mediciones tanto de reloj de pared como monotónicas.
4. Día dos: establezca una línea de base. Ejecute volúmenes de órdenes representativos y registre la latencia p50, p95 y p99, los rechazos, las limitaciones de solicitudes, el retraso de eventos y las reconexiones. Separe el tiempo de red del procesamiento de la aplicación.
5. Día tres: introduzca fallos. Interrumpa una conexión después del envío, retrase una respuesta, reinicie un consumidor y fuerce una brecha de secuencia cuando el entorno de pruebas lo permita. Verifique que cada caso produzca un único estado correcto de la orden.
6. Día cuatro: pruebe la conciliación. Compare las órdenes abiertas y las ejecuciones internas con la instantánea o los resultados de consulta del proveedor. Incluya ejecuciones parciales, condiciones de carrera entre cancelación y modificación, eventos duplicados e informes tardíos.
7. Día cuatro: calcule el costo operativo total. Sume el soporte de ingeniería, la certificación, la conectividad, la supervisión y la carga de guardia a los cargos directos del proveedor. Registre qué costos cambian con el volumen de órdenes o la incorporación de otros centros de negociación.
8. Día cinco: decida sobre la ruta. Elija la interfaz según la acción y el comportamiento ante fallos, y documente los objetivos de latencia, los pasos de recuperación, quién se encarga de la escalación y qué evidencia motivaría una revisión.

Elija según la ruta, no por moda

REST puede ser una buena opción para enviar órdenes cuando los ritmos de solicitud son moderados, se dispone de una idempotencia documentada y la plataforma puede conciliar resultados inciertos. WebSocket suele ser adecuado para actualizaciones en tiempo real, siempre que el flujo permita detectar y recuperar brechas de forma fiable. FIX suele justificarse cuando las contrapartes lo exigen, los ritmos de órdenes o los controles de sesión lo requieren, o el modelo operativo depende de una conectividad institucional persistente.

Los diseños híbridos son habituales. Un broker puede usar REST para operaciones de cuenta, WebSocket para actualizaciones dirigidas a clientes y FIX para la ejecución en centros de negociación. Mantenga explícitos los límites: un componente debe encargarse del estado de las órdenes, los reintentos deben ser deliberados y cada evento debe poder rastrearse mediante sus identificadores.

Si esta fuera mi operación, primero rastrearía una orden real desde el envío del cliente hasta la confirmación, la ejecución y la conciliación; luego introduciría un tiempo de espera agotado en cada límite. Solo elegiría la interfaz después de que esa prueba mostrara cómo demuestra el sistema que una orden existe.

#infraestructura del broker #API REST de trading #API WebSocket de trading #recuperación de sesiones FIX #Protocolo FIX #flujo de órdenes del broker #integración de ejecución de órdenes #latencia de API de trading