Ejecución lenta de órdenes en una pequeña firma de prop trading: a dónde se va el tiempo y quién puede arreglarlo

La ejecución lenta la arregla quien controla el tramo de la ruta de la orden donde se pierde el tiempo, así que lo primero es encontrar ese tramo. Pon una marca de tiempo a cada orden en cada punto que puedas ver, y el intervalo más largo te dice a quién llamar: a tus desarrolladores o a una empresa de ingeniería para los retrasos dentro de tu software, a un proveedor de hosting para la distancia y al bróker para los retrasos de su lado.

¿Qué significa «nuestra ejecución de órdenes es demasiado lenta»?

La queja puede referirse a cuatro problemas, y cada uno tiene un responsable distinto.

• Todas las órdenes son lentas. El retraso es más o menos el mismo en una mañana tranquila y en la apertura. Eso apunta a un coste que paga cada orden, como la distancia, la forma en que te conectas al bróker o un trabajo lento que tu propio software hace antes de que salga cada orden
• Las órdenes van rápidas hasta que sube la actividad del mercado. En la apertura o cuando sale una noticia, el retraso se dispara. Las órdenes esperan en alguna cola, detrás de un programa que no da abasto, de un límite de mensajes o de una máquina ocupada con otro trabajo
• Las órdenes llegan a tiempo, pero se ejecutan tarde. Una orden limitada queda en reposo en el libro hasta que alguien opera contra ella, y en un mercado rápido el precio se aleja. Las marcas de tiempo muestran si la orden llegó tarde. No pueden mostrar qué precio había disponible
• La pantalla va con retraso. Si los precios de la pantalla de trading llegan tarde, los traders hacen clic tarde y culpan a la ejecución. Eso es un problema de datos de mercado, del que trata otro artículo de este blog

Solo las marcas de tiempo de órdenes reales, y de los precios a los que reaccionaron, distinguen estos cuatro casos. Usa las quejas de los traders para elegir qué días revisar.

¿A dónde se van los milisegundos entre nuestro sistema y el exchange?

A la ida, una orden recorre cuatro tramos, y la confirmación vuelve desde el bróker, a veces solo después de que el exchange haya aceptado la orden.

• Tu lado. La estrategia o el trader decide, se construye la orden, se ejecutan tus propios controles y la orden se envía. Los retrasos vienen del trabajo hecho antes del envío, de pausas del programa, de la configuración de red o de una máquina ocupada. Tus desarrolladores o una empresa de ingeniería pueden cambiar esta parte
• La red. La orden viaja desde tu servidor hasta el punto de entrada del bróker. Aquí el retraso lo añaden la distancia, el enrutamiento por internet y los saltos adicionales, como una VPN. Un proveedor de hosting o de colocation, o un ingeniero de redes, puede acortarlo
• El bróker. Su gateway recibe la orden, ejecuta sus controles y la enruta al exchange. Los retrasos vienen de los propios sistemas del bróker y de sus controles obligatorios. Solo el bróker puede cambiarlos; tú eliges cómo te conectas y qué bróker usas
• El exchange. El matching engine acepta la orden y devuelve la confirmación. Aquí se va poco tiempo: Nasdaq declara un viaje de ida y vuelta de la orden a la confirmación de menos de 50 microsegundos en su red de colocation de alta velocidad de 10G. Nadie a quien puedas contratar cambia esta parte; solo puedes acercarte a ella

En Estados Unidos, los controles del bróker no son opcionales. La Regla 15c3-5 de la SEC exige a un bróker con acceso al mercado «impedir la entrada de órdenes que superen los umbrales de crédito o de capital preestablecidos adecuados» y rechazar las órdenes «que superen los parámetros de precio o de tamaño adecuados». La misma regla deja esos controles «bajo el control directo y exclusivo del bróker o dealer». Puedes preguntarle a un bróker cuánto tardan sus controles, pero la regla no le permite desactivarlos.

¿Cómo averiguamos dónde se pierde el tiempo?

Registra cuatro marcas de tiempo para cada orden:

• Decidida: la estrategia o el trader eligió enviarla
• Enviada: la orden salió de tu servidor
• Confirmada: a tu servidor llegó la confirmación del bróker de que aceptó la orden
• Ejecutada: llegó la ejecución

Entre decidida y enviada está tu software. Entre enviada y confirmada están la red y el bróker, a la ida y a la vuelta, más el exchange si el bróker lo espera. Pregúntale al bróker cómo lo hace. Para una orden en reposo en el libro, el tiempo entre confirmada y ejecutada es sobre todo el mercado.

Mide una cifra más: el viaje de ida y vuelta por la red desde tu servidor hasta el punto de entrada del bróker. Te dice qué parte del tramo entre enviada y confirmada es la red.

FIX es un estándar de mensajería para trading que mantiene la FIX Trading Community. Si te conectas por FIX, los mensajes del bróker llevan dos marcas de tiempo: una de cuándo se envió el mensaje y otra de cuándo ocurrió el evento que comunica. La especificación de FIX llama a estos campos SendingTime y TransactTime, y el bróker puede decirte de qué reloj sale cada uno. Junto a tus propias marcas de tiempo, muestran en qué lado ocurrió cada parte del viaje de ida y vuelta.

Comparar tus marcas de tiempo con las del bróker solo funciona si los dos relojes están en hora. La Regla 6820 de FINRA exige a los broker-dealers que reportan al Consolidated Audit Trail que mantengan sus relojes de negocio a menos de 50 milisegundos del reloj atómico del NIST. Según las normas de la UE, si un miembro de un centro de negociación practica trading algorítmico de alta frecuencia, debe mantener sus relojes a menos de 100 microsegundos de UTC. Un reloj que puede desviarse 50 milisegundos no sirve para localizar un retraso de unos pocos milisegundos.

Enviada y confirmada se leen las dos de tu propio reloj, así que el tiempo entre ellas no necesita sincronización. Empieza por ahí. Si ese viaje de ida y vuelta es corto y aun así las órdenes se notan lentas, mira tu propio software. Si es largo, comprueba primero que tu programa no estuviera en pausa u ocupado cuando llegó la respuesta; si no lo estaba, el tiempo se va fuera de tu software.

Después mira las órdenes más lentas. Ordena una semana de órdenes por viaje de ida y vuelta y apunta el tiempo que solo supera una de cada cien órdenes; haz lo mismo con los primeros minutos tras la apertura y en torno a las noticias programadas. Una media esconde los momentos de los que se quejan los traders.

¿Qué puede ralentizar la ejecución en una pequeña prop firm?

Revisa primero estas seis causas.

• La API del bróker pasa por un programa que tienes que ejecutar tú. Interactive Brokers, por ejemplo, describe su TWS API como basada en la «conectividad con Trader Workstation o IB Gateway», así que cada orden pasa primero por uno de esos programas. Su documentación fija un límite por defecto de «50 solicitudes por segundo» por conexión de cliente y advierte de que, en algunos casos, por encima de esa tasa «algunas órdenes pueden quedar en cola y retrasarse». Para ese caso, Interactive Brokers sugiere pasarse a su API FIX. Si este es tu cuello de botella, pregúntale al bróker de qué otra forma puedes conectarte
• El servidor está lejos del destino de las órdenes. Una máquina en la oficina o una región de nube lejana paga la distancia dos veces en cada orden, a la ida y a la vuelta, y ningún cambio de código la elimina. Para la distancia más corta, Nasdaq ofrece a sus clientes la posibilidad de «coubicar sus servidores y equipos dentro del Nasdaq Data Center». Antes de pagar por colocation, mide el viaje de ida y vuelta por la red desde tu servidor hasta el punto de entrada del bróker
• Se ejecuta trabajo lento antes de enviar la orden. Escribir la orden en una base de datos, esperar a que una línea de log llegue al disco o preguntar a otro servicio si la operación está permitida añade una espera a cada orden. Cuando la base de datos o el disco están ocupados, la espera crece. Mantén en memoria lo que la orden necesita y escribe los registros cuando la orden ya haya salido
• La configuración de red retiene los mensajes pequeños. Una orden es un mensaje pequeño. El manual de Linux dice que, salvo que esté activada una opción de socket llamada TCP_NODELAY, los datos salientes se retienen en un buffer «hasta que haya una cantidad suficiente para enviar». Tus desarrolladores pueden comprobar si está activada
• El programa hace pausas. Algunos recolectores de basura detienen todo el programa mientras limpian la memoria. Incluso el recolector de basura de Go, que hace la mayor parte de su trabajo mientras el programa se ejecuta, tiene «breves pausas stop-the-world», y la guía del recolector de basura de Go las cita entre las posibles fuentes de latencia. Si llega una pausa mientras sale una orden, la orden sale tarde. Los gráficos, backtests o informes que corren en la misma máquina tienen un efecto parecido, porque la orden espera al procesador
• La propia ruta del bróker es lenta. Su gateway, sus controles y su enrutamiento están en la ruta de cada orden, y no puedes ver lo que pasa dentro. Puedes preguntar dónde está su punto de entrada, qué tipos de conexión ofrece, qué límites de mensajes se aplican a tu cuenta y si compartirá sus propias marcas de tiempo de tus órdenes

¿Cómo se arregla cada causa y cuánto trabajo supone?

• Entre decidida y enviada pasa mucho tiempo en todas las órdenes. Saca el trabajo lento de la ruta de la orden y revisa la configuración de red. El trabajo es un cambio en tu código, a veces un solo ajuste
• Entre decidida y enviada el tiempo se dispara en los momentos de más actividad. Averigua a qué espera la orden: una pausa, una cola, una máquina compartida. El trabajo es un cambio de código o de hosting, o una reconstrucción de la ruta de la orden si el propio diseño encola
• Entre enviada y confirmada pasa mucho tiempo en todas las órdenes. Acerca el servidor al punto de entrada del bróker o cambia el tipo de conexión. Cuenta con un contrato de hosting y un traslado, o con trabajo de integración para una conexión nueva
• Entre enviada y confirmada el tiempo se dispara con el volumen. Encuentra el límite con el que chocas, en el bróker o en tu propia conexión. Puede bastar con una conversación con el bróker o con enviar menos mensajes desde tu lado
• Entre confirmada y ejecutada pasa mucho tiempo. Mira el tipo de orden y el mercado. Esto no es un trabajo de ingeniería

Arregla primero la causa confirmada más barata y deja la reconstrucción para el final. No reescribas el sistema ni cambies de bróker antes de que alguien haya medido los tiempos de una orden, porque el retraso puede estar en otra parte.

¿Quién puede ayudarnos a arreglar la ejecución lenta de órdenes?

Quién puede ayudar depende de dónde se pierde el tiempo.

• Tu bróker. La única parte que puede ver y cambiar su propio lado. Pídele sus marcas de tiempo de tus órdenes, sus límites y sus opciones de conexión
• Un proveedor de hosting o de colocation, o el equipo de conectividad del exchange. Alquilan espacio cerca del punto de entrada del bróker o del exchange y venden las líneas de red hasta él
• El proveedor de tu plataforma de trading, si operas a través de una que usas bajo licencia. Solo el proveedor puede cambiar su funcionamiento interno, así que llévale tus marcas de tiempo
• Una empresa de ingeniería que trabaja en sistemas de trading. Mide toda la ruta y después cambia o reconstruye las partes de tu lado, como la ruta de la orden, los controles de riesgo y la conexión con el bróker
• Tus propios desarrolladores, si los tienes. Con las cuatro marcas de tiempo, un desarrollador competente puede revisar todas las causas de tu lado de la ruta

Contrates a quien contrates, hazle primero cuatro preguntas:

• ¿Medirán antes de proponer un arreglo, y en qué puntos exactamente pondrán marcas de tiempo?
• ¿El informe separará nuestro lado, la red y el bróker, y mostrará las órdenes más lentas, no solo la media?
• De cada cifra que citen: ¿en qué percentil, con qué carga, en qué fecha?
• Si resulta que el retraso está en el bróker, ¿qué nos dirán?

Si la respuesta a la última pregunta sigue siendo reconstruir tu sistema, sigue buscando.

¿Dónde encaja amBrain?

amBrain es una empresa de ingeniería de software de Ereván, Armenia, que construye plataformas de trading de baja latencia, motores de casación y sistemas de real-time bidding en Rust. amBrain diagnostica sistemas lentos en trading, apuestas y ad tech: la plataforma en funcionamiento se mide de extremo a extremo y el informe indica a dónde se va el tiempo.

amBrain construye infraestructura de trading algorítmico: ejecución de órdenes, datos de mercado y controles de riesgo pre-trade. Su trabajo en trading incluye desarrollo de terminales de trading, sistemas de gestión de órdenes e integración con exchanges por protocolo FIX. amBrain se hace cargo de proyectos que se atascaron con otro equipo y los lleva a producción. Tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo.

Si estás al principio, registra las cuatro marcas de tiempo en un día normal y en uno de mucha actividad. Llévaselas a quien llames, sea amBrain o cualquier otro, para que la primera conversación empiece sabiendo a dónde se va el tiempo.

Preguntas frecuentes

• ¿Reescribir nuestro sistema en Rust hará más rápida la ejecución? Solo si el tiempo se pierde dentro de tu software, y solo en la parte por la que pasa la orden. Rust da garantías de seguridad de memoria «sin necesitar un recolector de basura», lo que elimina las pausas de recolección de basura como causa. No hace nada contra una máquina ocupada, la distancia o el bróker
• ¿Podemos medir sin cambiar nuestro código? Sí, si tu sistema ya registra con su hora las órdenes salientes y las confirmaciones entrantes: el viaje de ida y vuelta entre enviada y confirmada está en esos logs
• ¿Una ejecución más rápida nos dará mejores precios? Nadie puede prometerlo. La velocidad acorta el tiempo entre una decisión y la llegada de la orden; el precio que obtienes depende también de la liquidez, del tipo de orden y de lo que haga el mercado mientras tanto