Una orden enviada no es una orden ejecutada

Enviar una orden y conseguir que se ejecute son dos hechos distintos, separados en el tiempo y a veces por un rechazo. El estado de una orden pasa por varias etapas, y confundirlas —dar por aceptado lo enviado, por rechazado lo pendiente, por cancelado lo solicitado o por completo lo parcial— es una de las fuentes más habituales de posiciones equivocadas en la operativa automatizada.

Enviada no es aceptada

En el protocolo FIX, cada informe de ejecución lleva dos campos con papeles diferentes: uno indica el motivo por el que se envió el mensaje y el otro refleja el estado actual de la orden después de ese evento [1]. Muchos intermediarios traducen esa distinción a su propia nomenclatura: existe un estado que significa que la orden se ha transmitido pero todavía no se ha recibido confirmación de que el destino la haya aceptado, y otro que significa que ha sido aceptada y está trabajando [3]. El intervalo entre enviar y aceptar es real, y durante él no puede darse por hecho nada sobre la orden.

Pendiente no es rechazada y pedir cancelación no es cancelar

Los estados intermedios son los que más se malinterpretan. Una solicitud de cancelación pendiente confirma la recepción de la petición, pero no indica que la orden haya sido cancelada [1]. Lo mismo vale para una solicitud de modificación pendiente [1]. Un intermediario describe el estado de cancelación pendiente como aquel en el que la orden no está confirmada como cancelada y en el que todavía puede llegar una ejecución mientras la petición está en curso [3]. Solo cuando el saldo de la orden ha quedado confirmado como cancelado por el sistema puede afirmarse que la orden está cancelada, y esa confirmación puede incluso llegar de forma inesperada cuando el destino rechaza la orden [3]. Pedir una cancelación y tenerla confirmada son, por tanto, dos eventos distintos que deben registrarse por separado.

No todas las órdenes esperan igual

Que una orden permanezca pendiente depende de su tipo. Algunas órdenes se cancelan en el sistema del intermediario cuando se cumplen sus condiciones de vigencia temporal, mientras que las de ejecución inmediata o todo o nada terminan en estado cancelado en lugar de quedarse esperando [1]. Un estado pendiente no es, entonces, una propiedad universal: debe interpretarse según el tipo de orden y sus instrucciones de validez. Dar por hecho que cualquier orden puede quedarse descansando en el libro lleva a esperar confirmaciones que nunca van a llegar para ciertos tipos. Además, una ejecución parcial no completa una orden: la cantidad restante sigue viva y puede seguir recibiendo ejecuciones, de modo que una orden solo está completa cuando lo está por entero [3].

Estados que llegan tarde

Las actualizaciones de estado pueden llegar después de que la orden parezca resuelta. Un mercado puede generar un reenvío del estado cuando una orden regresa de un encaminador externo, reemitiendo la situación de la orden y poniendo a cero los detalles de la última ejecución mientras conserva las cantidades acumuladas [2]. El rechazo tampoco es solo un estado inicial: una orden puede pasar de estar reconocida a ser rechazada [1]. Cualquier diseño que trate el primer acuse de recibo como definitivo acabará separándose del estado real que mantiene el intermediario.

Reenvíos y duplicados

Un tiempo de espera agotado no se distingue de un éxito, así que toda escritura de una orden debe poder repetirse con seguridad [4]. El mecanismo habitual es un identificador de orden generado por el cliente: si la respuesta se pierde, se busca la orden por ese identificador antes de reintentar, en lugar de enviarla otra vez [4]. En FIX el manejo de reenvíos es explícito: si la orden ya se había recibido, el sistema confirma de vuelta el estado actual en vez de crear una nueva; si no se había recibido, la trata como nueva; y un duplicado auténtico se rechaza indicando que la orden está repetida [1]. Un reintento ciego sin clave de idempotencia es una vía documentada hacia posiciones duplicadas [4].

Conciliación y comprobaciones concretas

Como el estado puede cambiar tarde y las correcciones pueden generar identificadores nuevos, el diseño fiable consiste en tratar al intermediario como fuente de verdad y volver a leer el estado autorizado de forma periódica, actualizando los registros por el identificador del intermediario y no por un valor local provisional [4]. Que una respuesta signifique "aceptada" no significa "liquidada": la confirmación debe venir del evento final o de una conciliación, no de la respuesta inicial de creación [4]. Antes de confiar en el registro de órdenes, conviene revisar:

• Registrar una línea temporal completa por orden: envío, aceptación, ejecuciones parciales, petición de cancelación y confirmación de cancelación.
• No dar por efectiva una cancelación hasta que esté confirmada [1][3].
• Usar un identificador de orden estable en cada envío y consultarlo antes de reenviar [4].
• Comprobar que el número de ejecuciones confirmadas cuadra con el del intermediario y conciliar posiciones al cierre de la sesión [4].
• Clasificar los estados como finales o no finales según el tipo de orden, y dejar de procesar los finales [4].
• En FIX, leer juntos los dos campos del informe de ejecución y no por separado [1].

Un caso hipotético, sin cifras: el sistema envía una orden, la conexión se corta antes de la respuesta y el proceso la reenvía al reiniciarse. Sin un identificador estable que permita reconocer que ya había sido aceptada, quedan dos órdenes donde debía haber una. El problema no fue la ejecución: fue confundir "sin respuesta" con "no enviada" [4].

Fuentes

[1] FIX Trading Community. FIX Application Layer: Order State Changes. https://www.fixtrading.org/wp-content/uploads/download-manager-files/Order-State-Changes.pdf

[2] Cboe. Cboe Titanium U.S. Options FIX Specification: State Change Tracking. https://www.cboe.com/document/tech-spec/content/technical-specifications/cboe-titanium-u.s.-options-fix-specification/fix-messages/order-protocol---cboe-to-member/execution-report-message-fields/state-change-tracking

[3] Interactive Brokers. Understanding Order Status Message (TWS API). https://www.interactivebrokers.com/docs/tws-api/doc/order-management/order-status/understanding-order-status-message.md

[4] Alpaca Broker API. Reconciliation & Idempotency. https://raw.githubusercontent.com/alpacahq/alpaca-skills/main/skills/broker-api/reconciliation-idempotency/SKILL.md

Nota de riesgo: Este contenido es educativo y no constituye asesoramiento financiero personalizado ni una recomendación de inversión. Operar en mercados financieros implica riesgo de pérdida; ningún método garantiza resultados futuros.