English
Deutsch
日本語
العربية
한국어
Português
Indonesia
Tiếng Việt
中文
<
BJF TRADING GROUP · SHARPTRADER OPTIMIZER
La mayoría de los backtests publicados de arbitraje de latencia se ven espectaculares sobre el papel y colapsan en cuanto pasan a operar en vivo. La razón no es una mala lógica de estrategia — es que los backtesters minoristas estándar asumen silenciosamente ejecuciones con latencia cero. Esta guía desglosa exactamente cómo el tiempo de ejecución a nivel de milisegundos cambia las matemáticas, y qué debe modelar tu backtest para producir resultados que realmente puedas operar.
La rentabilidad del arbitraje de latencia vive dentro de una ventana de 50–200 milisegundos. Ese es el tiempo durante el cual la discrepancia de precio entre un feed rápido y un broker lento normalmente permanece abierta antes de que la cotización del broker lento se actualice. Si tu tiempo real de ejecución de ida y vuelta — desde la detección de la señal hasta la confirmación de la ejecución — consume la mayor parte de esa ventana, casi no te queda margen. Los backtesters minoristas estándar asumen que las órdenes se ejecutan instantáneamente al precio mostrado, lo que elimina todo este problema de la simulación. El resultado: un backtest que parece imprimir dinero y un despliegue en vivo que pierde en cada operación después del spread.
Este artículo cuantifica la brecha, desglosa adónde van realmente los milisegundos y explica cómo modelar el tiempo de ejecución dentro de un backtest para que las cifras que entregas coincidan con las cifras que verás en una cuenta real.
Ver: cómo el tiempo de ejecución cambia un backtest de arbitraje de latencia — la misma estrategia con 0 ms, 50 ms y 150 ms de latencia de ejecución, explicada tick por tick.
En un sistema de arbitraje de latencia, la estrategia compara dos feeds de precios — un feed rápido (normalmente un agregador tier-1 o un feed de LP) y un feed lento (el broker contra el que operas). Cuando el feed rápido se adelanta al lento por más que el spread más un umbral configurado, la estrategia dispara una orden en el lado lento, esperando que el precio lento converja.
La oportunidad existe solo mientras los dos precios están desalineados. En el momento en que el motor de cotización del broker se pone al día — normalmente en un plazo de 50 a 200 milisegundos — la ventaja desaparece. Tu orden tiene que estar en el mercado antes de que eso ocurra.
“Tiempo de ejecución” en este contexto no es un único número. Es una pila de latencias, cada una aportando algunos milisegundos:
Para una estrategia que corre en un VPS estándar en un centro de datos distinto al del broker, el ida y vuelta realista rara vez está por debajo de 80–100ms. Para una estrategia co-ubicada con el broker mediante cross-connect, puede bajar a 1–5ms. Esa diferencia de orden de magnitud es todo el juego.
Imagina una señal limpia: el feed rápido salta 1.5 pips. El broker lento todavía no se ha actualizado. Tienes, en promedio, entre 80 y 150 milisegundos antes de que el motor de cotización del broker lento refleje el nuevo precio. Dentro de esa ventana, ocurren dos cosas simultáneamente:
Si tu ida y vuelta consume 50ms, llegas cuando la discrepancia sigue intacta en ~70% y capturas la mayor parte. Si tu ida y vuelta consume 150ms, llegas cuando la discrepancia ya colapsó hasta ~10% — y después de spread + slippage probablemente estás perdiendo.
La relación entre la latencia de ida y vuelta y el PnL de arbitraje no es lineal. Por debajo de la ventana de ejecución, la rentabilidad es alta y estable. Por encima de ella, la rentabilidad colapsa a cero o a negativo. La mayoría de los traders minoristas están del lado equivocado de ese precipicio y no lo saben porque su backtest lo oculta.
Aquí está la misma señal teórica de arbitraje de latencia con una ventaja de 1.5 pips, simulada con cuatro latencias de ejecución de ida y vuelta distintas. Los números de abajo son típicos de lo que verás en EUR/USD durante una sesión de Londres con liquidez normal y un spread de 0.6–0.9 pip.
| Ejecución de ida y vuelta | Ventaja capturada | Slippage en entrada | PnL neto por operación | Veredicto |
|---|---|---|---|---|
| ~5ms (co-ubicado) | ~95% de la señal | 0.0–0.2 pip | +0.6 a +1.0 pip | Rentable |
| ~50ms (VPS cercano) | ~70% de la señal | 0.2–0.5 pip | +0.2 a +0.6 pip | Rentable, más ajustado |
| ~120ms (distancia media) | ~30% de la señal | 0.5–1.0 pip | −0.3 a +0.1 pip | Marginal / perdedor |
| ~200ms (larga distancia) | ~10% de la señal | 1.0–1.8 pip | −1.0 a −0.5 pip | Pierde cada operación |
Observa el patrón: de 5ms a 50ms, la rentabilidad cae moderadamente. De 50ms a 120ms, cae por un precipicio. Más allá de 150ms, la estrategia es un cara o cruz con expectativa negativa después de costes. Este precipicio es invisible para un backtester que asume ejecuciones instantáneas.
Los backtesters minoristas estándar fueron creados para sistemas de seguimiento de tendencia y basados en indicadores — estrategias donde los periodos de tenencia son de minutos a días, y unos segundos de slippage de ejecución son un error de redondeo. Su arquitectura refleja eso:
Para una estrategia que mantiene posiciones durante horas, esto está bien — el coste de estas simplificaciones está muy por debajo del 1% del PnL. Para una estrategia de arbitraje de latencia que gana 1–3 pips por operación y vive o muere dentro de una ventana de 100ms, cada una de esas simplificaciones es fatal:
Una discrepancia de precio de 100ms es invisible dentro de una vela M1 — la vela muestra OHLC, no el flujo de ticks intravela. Los backtesters de reproducción de velas ni siquiera pueden detectar correctamente señales de arbitraje de latencia.
Si las órdenes se ejecutan al precio mostrado en el momento en que se envían, toda la ventana de ejecución de 50–200ms colapsa a cero. El backtest captura el 100% de cada señal, siempre. La realidad captura entre 30% y 95% según la infraestructura.
Las oportunidades reales de arbitraje se concentran alrededor de noticias, rollover y ventanas de baja liquidez — exactamente cuando el spread se amplía 3–5x. Los backtests con spread fijo cuentan beneficios que no existirían en condiciones reales.
El arbitraje de latencia cierra posiciones tan rápido como las abre. Los backtesters estándar o ignoran por completo el slippage del lado de cierre o aplican el mismo spread fijo, duplicando el optimismo irrealista.
Para producir un backtest que sobreviva al contacto con un broker en vivo, el simulador tiene que modelar explícitamente cada tramo del ida y vuelta. Este es el desglose que necesita un backtest serio de arbitraje de latencia:
| Componente | Rango típico | Qué representa |
|---|---|---|
| 1. Latencia de señal a envío | 0.5–20 ms | Tiempo desde recibir el tick disparador hasta emitir una orden. Depende del lenguaje, la ruta de código y la CPU. C++ compilado <1ms; scripts de alto nivel 5–20ms. |
| 2. Ida y vuelta de red (salida) | 1–80 ms | Tiempo de transmisión desde tu host de trading hasta el broker. Co-ubicado = 1–3ms; misma área metropolitana = 5–15ms; entre regiones = 30–80ms. |
| 3. Latencia de matching del broker | 3–100 ms | Tiempo dentro del sistema de gestión de órdenes y motor de matching del broker. Brokers ECN tier-1: 3–15ms. Brokers minoristas estándar: 30–100ms. Brokers STP con gestión manual: 100ms+. |
| 4. Ida y vuelta de confirmación (regreso) | 1–80 ms | Refleja el tramo de red saliente. Hasta que recibes la confirmación de ejecución, no conoces tu precio de ejecución — relevante para gestión de riesgo y timing del lado de cierre. |
Para un despliegue típico de arbitraje de latencia minorista desde un VPS genérico a través de un broker minorista estándar, los cuatro componentes suman aproximadamente 80–180ms — justo dentro de la zona de peligro donde la captura de señal cae por debajo del 50%. Para un despliegue co-ubicado a través de un broker ECN rápido, los mismos componentes suman 5–20ms — muy por debajo del precipicio.
Todo backtest honesto de una estrategia de arbitraje de latencia debería permitir al trader configurar estas latencias y ver el impacto. SharpTrader Optimizer modela la latencia de ejecución como un único parámetro configurable (en milisegundos) que se aplica a cada orden en tiempo de simulación, sobre datos históricos de ticks reales.
Deben existir tres cosas. Cada una es necesaria; ninguna es suficiente por sí sola.
Los backtesters minoristas estándar rellenan datos de “ticks” interpolando entre valores OHLC de velas. Los ticks sintéticos que producen alcanzan el máximo y mínimo de la vela en puntos aleatorios de la vela, suavemente entre la apertura y el cierre. Los mercados reales no se mueven así — saltan. La señal de arbitraje de latencia de 1.5 pips que intentas capturar es un salto que los datos de ticks interpolados suavizan hasta hacerlo desaparecer.
Un backtest serio reproduce ticks bid/ask reales registrados desde el motor de matching del broker (o un feed de referencia limpio como datos institucionales con origen en Londres). Cada tick tiene una marca temporal, un bid y un ask. La estrategia los ve en el mismo orden y con el mismo timing que vería un despliegue en vivo.
El trader configura el tiempo de ejecución de ida y vuelta T (en milisegundos) que espera ver en vivo. Cuando la estrategia emite una orden, el simulador avanza el reloj por la parte del tramo de solicitud — normalmente T/2, ya que solo el tiempo entre la señal y el matching del lado del broker afecta al precio de ejecución (el tramo de respuesta solo le dice a la estrategia lo que ya ocurrió). Si T = 80ms, el simulador mira el flujo de ticks 40ms después de la señal y usa el bid/ask de ese tick — no el tick que disparó la señal — como precio de ejecución.
Este único cambio — avanzar el reloj entre señal y ejecución — reproduce el precipicio con latencias realistas. También hace que el backtest sea determinista: la misma estrategia con T = 50ms frente a T = 150ms sobre el mismo flujo de ticks produce resultados mediblemente distintos, y el trader puede ver exactamente dónde deja de funcionar la estrategia.
El slippage realizado en cada ejecución es lo que produjo el recorrido de ticks — es una salida de la simulación, no un número que el trader tenga que adivinar. Algunas ejecuciones caen favorablemente (slippage positivo), otras caen peor (negativo), y la magnitud sigue la volatilidad real de ticks durante esos milisegundos. Esta es la distribución realista que falta en todos los backtesters minoristas estándar.
El arbitraje de latencia cierra tan rápido como abre. La salida ocurre 200–800ms después de la entrada, contra un precio que converge. Si el simulador aplica el mismo spread fijo a entrada y salida, se pierde dos cosas: (1) slippage de entrada desde la ventana de latencia, y (2) slippage de salida por el precio derivando de vuelta durante el ida y vuelta del lado de cierre. Un modelo real permite configurar el tiempo de ejecución de forma independiente para apertura y cierre — reflejando el comportamiento real del broker, donde las salidas a menudo pasan por una ruta de enrutamiento más lenta — y resuelve automáticamente el slippage de cada tramo a partir del flujo de ticks.
Este es un resultado representativo de una estrategia de arbitraje de latencia de SharpTrader backtesteada sobre 30 días de datos de ticks de EUR/USD, con los mismos parámetros pero tres configuraciones distintas de latencia de ejecución. Los números son típicos de lo que vemos en backtests de BJF Feed (London / Tokyo / NY).
| Métrica | 0ms (ficticio) | 50ms (VPS cercano) | 150ms (larga distancia) |
|---|---|---|---|
| Señales disparadas | 2,847 | 2,847 | 2,847 |
| Señales ejecutadas en la ventaja | 2,847 (100%) | 1,983 (70%) | 854 (30%) |
| Pip promedio capturado | 1.42 | 0.98 | 0.21 |
| Slippage realizado en entrada (salida del recorrido de ticks) | 0.0 pip | 0.3 pip | 0.9 pip |
| PnL neto por operación | +0.82 pip | +0.48 pip | −0.31 pip |
| Retorno mensual (1 lote) | +233% | +137% | −88% |
La columna de 0ms es la “fantasía de backtest” que producen las herramientas estándar. La columna de 50ms es cómo se ve realmente una estrategia de arbitraje de latencia bien desplegada. La columna de 150ms es lo que la mayoría de los traders minoristas ejecutan accidentalmente cuando levantan una estrategia en un VPS genérico y operan a través de un broker estándar sin darse cuenta de dónde cae su ida y vuelta en el precipicio.
La misma estrategia puede ser enormemente rentable, marginalmente rentable o una pérdida garantizada — dependiendo solo de un número que ningún backtester estándar modela.
La latencia de ejecución es la variable menos modelada en los backtests minoristas de arbitraje de latencia, pero no es la única. Un backtest confiable combina tres cosas, y cada una amplifica a las demás:
Revela el precipicio. Te dice qué infraestructura necesita realmente la estrategia para ser rentable, y en qué punto desaparece tu ventaja.
Captura el hecho de que las oportunidades de arb se concentran precisamente cuando el spread se amplía. Un backtest con spread fijo cuenta beneficios que físicamente no pueden existir en esos momentos.
Detecta estrategias que se ven bien in-sample porque el optimizador encontró un conjunto de parámetros que se ajusta al ruido del periodo in-sample. Sin walk-forward, tu backtest es un currículum retrospectivo.
Una operación de arbitraje de latencia tiene dos eventos de slippage — apertura y cierre. La mayoría de los backtests modelan uno (o cero) y duplican el optimismo.
Cuando los cuatro están presentes, el backtest deja de ser una herramienta de marketing y se convierte en una herramienta de previsión. Las cifras que produce dejan de divergir 50–200% de los resultados en vivo y empiezan a caer dentro de 10–20% — lo bastante cerca como para que el dimensionamiento de riesgo, la asignación de capital y las decisiones de selección de broker puedan basarse realmente en el backtest.
Regla práctica de la industria: espera que el drawdown en vivo sea de 1.5x a 2x el drawdown del backtest. Para estrategias de arbitraje de latencia ejecutadas en backtesters estándar, esa relación se acerca más a 5x a 10x — porque el backtest no ha modelado latencia de ejecución, spread variable o slippage en ambos lados. Una vez incluidos, se aplica la regla 1.5–2x; antes de incluirlos, el backtest no tiene ningún valor predictivo.
Ejecuta la optimización con al menos tres configuraciones de latencia: 10ms (mejor caso co-ubicado), 50ms (VPS cercano) y 150ms (VPS genérico, broker distante). Si la estrategia solo es rentable a 10ms, tienes un problema de despliegue — necesitas un plan de co-ubicación antes de poder operarla. Si es rentable a 50ms pero no a 150ms, la elección del VPS y del broker se convierten en todo el juego.
Tres capas: (1) haz ping al endpoint de entrada de órdenes de tu broker desde tu host de trading — esto te da el ida y vuelta de red bruto; (2) envía una pequeña orden de prueba durante un periodo tranquilo y marca el tiempo entre emisión de señal y confirmación de ejecución — la diferencia incluye la latencia de matching del broker; (3) repite en múltiples sesiones — la latencia varía con la carga del broker, la hora del día y la ruta. La cifra realista para tu despliegue es la mediana de muchas mediciones, no el mejor ping posible.
Sí — con ventanas aún más estrechas. Las ventanas de trading de noticias pueden tener 10–50ms de ancho. El problema de la brecha de tiempo de ejecución es idéntico, solo comprimido en una ventana más pequeña. Se requiere la misma infraestructura de backtest (ticks reales, latencia de ejecución configurable, spread variable), y la tolerancia a la latencia es aún menos indulgente.
Ambos fenómenos tienen la misma causa: los proveedores de liquidez se vuelven inciertos sobre el precio y retiran cotizaciones. Cuando el feed rápido salta, los LP que suministran al broker lento amplían brevemente sus cotizaciones para protegerse de ser explotados. Así que el momento en que se abre la discrepancia también es el momento en que se amplía el spread para capturarla. Un backtest con spread fijo no ve esto y sobreestima la ventaja neta en 30–50%.
Para arbitraje de latencia de estilo institucional contra brokers ECN tier-1, sí — el campo de juego se ha movido a ida y vuelta sub-5ms y eso requiere cross-connect o proximity hosting. Para arbitraje de latencia de estilo minorista contra brokers minoristas más lentos, no — idas y vueltas de 30–80ms aún pueden producir ventaja, porque la ventana del broker lento es más amplia. La pregunta correcta no es “¿se requiere co-ubicación?”, sino “¿mi ida y vuelta cabe dentro de la ventana del broker contra el que estoy operando?”. Eso es exactamente lo que responde el backtesting consciente de la latencia de ejecución.
Para estrategias de seguimiento de tendencia que mantienen posiciones durante horas o días, unos cientos de milisegundos de latencia de ejecución son un error de redondeo. Para arbitraje de latencia, esos mismos milisegundos son toda la señal. La infraestructura normal de backtesting de forex está diseñada para el primer caso y producirá silenciosamente resultados inútiles para el segundo. Por eso existen herramientas dedicadas de backtesting de arbitraje como categoría separada.
Cambian la estrategia óptima, no el análisis. Los brokers que ejecutan plugins anti-arbitraje (ejecución retrasada, last-look, requote en beneficio, hold-then-fill) introducen efectivamente latencia de ejecución artificial además de la natural. Un backtest con latencia de ejecución configurable te permite simular el comportamiento anti-arb del broker y decidir si la estrategia sigue siendo viable contra ese broker — o si necesitas cambiar de venue.
Para una estrategia de arbitraje de latencia con 5–8 parámetros, una grilla típica es de 30,000–100,000 combinaciones — incluyendo 3–5 configuraciones de tiempo de ejecución como una de las dimensiones barridas. El objetivo es encontrar clústeres de rentabilidad — rangos donde la estrategia es rentable en muchos valores de parámetros, no picos “afortunados” aislados. Los picos aislados son curve-fitting; los clústeres son robustez. Como referencia realista en una estación de trabajo minorista típica, una grilla de 30,000 combinaciones contra 1 semana de datos de ticks de XAUUSD en una CPU de 4 núcleos termina en unas 12 horas; la misma grilla tarda unas 3 horas en 16 núcleos. SharpTrader Optimizer gestiona 100,000+ combinaciones por ejecución en hardware multi-core.
Es una observación empírica en el trading algorítmico institucional: incluso un backtest bien modelado subestima el drawdown en vivo en aproximadamente 50–100%, porque algunas fricciones del mundo real (rechazos del broker, gaps de fin de semana, cambios de régimen) no pueden modelarse limpiamente. La regla asume que el backtest ya incluye latencia de ejecución realista, spread variable y slippage en ambos lados. Si faltan esos elementos, el multiplicador es mucho mayor — de 5x a 10x específicamente para arbitraje de latencia.
Conceptualmente es idéntico. La ventana de tiempo de ejecución en el arbitraje cripto entre exchanges suele ser de 200ms–2s (más lenta que en forex porque los exchanges están más separados y los libros de órdenes son más profundos pero más lentos en actualizarse). Los mismos tres ingredientes — reproducción de ticks, latencia de ejecución configurable, spread variable — producen backtests honestos. Las herramientas de crypto arbitrage de BJF usan la misma arquitectura adaptada a APIs de exchanges y profundidad de libro de órdenes.
SharpTrader Optimizer es el único backtester accesible para minoristas que modela tiempo de ejecución configurable, reproducción de ticks reales, spread variable por tick y slippage resuelto por tick en ambos lados — las cuatro variables que deciden si una estrategia de arbitraje de latencia es real o ficticia. La optimización de grilla multi-core sobre 100,000+ combinaciones de parámetros termina en horas, no días.