Lección 518 min60 XPGratis
De tu clic al fill: latencia y por qué (casi nunca) te importa
Al terminar sabrás
- Describir el camino de una orden desde tu pantalla hasta el matching engine y vuelta
- Estimar cuánto se mueve el precio durante la latencia y compararlo con el edge de tu estrategia
- Decidir si tu estrategia necesita infraestructura o no
Antes de esta conviene haber hecho Ejecución y slippage: el precio que ves no es el que pagas.
Cuando pulsas comprar, tu orden viaja de tu ordenador al servidor de tu broker, de ahí a la pasarela de CME y de ahí al motor que casa órdenes en un centro de datos en Aurora, Illinois. Ida y vuelta, desde Europa, unos 100-300 milisegundos. En ese tiempo el precio de ES se mueve, de media, menos de un tick. Si tu estrategia opera una vez al día, eso es nada. Si tu edge es medio tick por operación, eso es todo tu edge.
El problema
La latencia se sobrevalora y se infravalora a la vez. Los principiantes creen que necesitan un VPS en Chicago para operar tres veces por semana. Los que copian estrategias de scalping de foros no entienden por qué a ellos no les funciona lo que "funciona" con datos de tick. La respuesta a ambos es la misma cuenta: cuánto se mueve el precio durante tu latencia, comparado con lo que esperas por operación.
Tres capas
Intuición
Pides una pizza por teléfono. Entre que decides el precio que aceptas pagar y que la pizza llega, pasan 30 minutos. Si el precio de la pizza cambiara cada segundo, en 30 minutos podría haber cambiado bastante y te llevarías una sorpresa. Si cambia una vez al mes, da igual que tardes 30 minutos o 3 horas.
La latencia es el tiempo entre tu decisión y su ejecución. Lo que importa no es el tiempo en sí, sino cuánto puede cambiar el precio en ese tiempo comparado con lo que esperas por operación. Para una estrategia que busca 50 puntos por operación y aguanta días, medio tick de movimiento en 300 ms es invisible. Para una que busca medio tick por operación, ese medio tick de movimiento es el 100 % del resultado esperado, y se pierde de forma sistemática porque quien está más cerca del motor se lleva el precio bueno antes que tú.
Ejemplo numérico
ES a 5.400 con volatilidad anual del 16 %. Repartida por los segundos de la sesión regular, eso es un 0,0065 % por segundo. Cuánto se mueve el precio, de forma típica, en distintos horizontes (el movimiento crece con la raíz del tiempo):
| Latencia / horizonte | Movimiento típico | En ticks | Respecto a una barra de 1 min | Respecto a un día |
|---|---|---|---|---|
| 1 ms (colocation) | 0,011 pts | 0,04 | 0,4 % | 0,02 % |
| 50 ms (VPS en Chicago) | 0,078 pts | 0,31 | 2,9 % | 0,14 % |
| 300 ms (casa, Europa) | 0,191 pts | 0,76 | 7,1 % | 0,35 % |
| 2 s (clic manual lento) | 0,494 pts | 1,98 | 18 % | 0,9 % |
Lectura: con la conexión doméstica desde Europa, el precio se mueve unos 0,8 ticks mientras tu orden viaja. Una estrategia de barras diarias vive movimientos típicos de 54 puntos al día; 0,19 puntos de latencia es un 0,35 %, ruido. Una estrategia que busca medio tick por operación no puede existir con 300 ms, porque el movimiento durante la latencia ya es mayor que el edge, y no es simétrico: cuando el precio se mueve a tu favor, alguien más rápido ya se ha llevado la orden que ibas a cruzar.
Formal
El camino. Tu plataforma → internet → servidor del broker (validación de riesgo, margen) → red privada o internet → gateway de CME Globex → matching engine (Aurora, IL) → confirmación de vuelta por el mismo camino → actualización del feed de datos de mercado (que también tiene su propia latencia, distinta de la de ejecución). Componentes típicos: red doméstica y salto transatlántico, 80-150 ms ida y vuelta; procesamiento del broker, 1-50 ms; CME interno, decenas de microsegundos. Colocation es alquilar un rack en el mismo centro de datos que el matching engine: latencias de ida y vuelta por debajo de 100 microsegundos. Es lo que hacen los market makers y los HFT; cuesta miles de dólares al mes y no sirve para nada si tu estrategia no lo necesita.
Movimiento durante la latencia. Bajo un modelo difusivo, el movimiento típico en un intervalo es , con la volatilidad por unidad de tiempo. La tabla usa , que reparte la volatilidad anual uniformemente por los segundos de RTH; en la realidad la volatilidad intradía no es uniforme (mayor en apertura, cierre y publicaciones), así que el movimiento durante la latencia en esos momentos es varias veces el de la tabla. El criterio de decisión: si es una fracción pequeña (digamos < 5 %) del resultado esperado por operación, la latencia es irrelevante; si es comparable, la estrategia no es viable con esa infraestructura.
Dos latencias, no una. La de ejecución (tu orden → fill) y la de datos (el mercado cambia → tú lo ves). Un feed de datos minorista puede ir con 100-500 ms de retraso respecto al feed directo de CME, además de agregado (snapshots en vez de cada cambio). Consecuencia: el precio que "ves" en tu plataforma doméstica ya es viejo cuando lo ves, y el slippage que mides incluye ese retraso. Para barras diarias, irrelevante; para intradía de minutos, tolerable; para segundos, inhabilitante.
Lo que la latencia no arregla. Ningún VPS convierte una estrategia sin edge en una con edge. Y para la inmensa mayoría de estrategias sistemáticas retail (barras de 5 minutos a diarias), la infraestructura correcta es un ordenador estable, una conexión fiable y órdenes bien elegidas. El VPS tiene sentido por fiabilidad (que el bot no se apague porque se fue la luz), no por velocidad.
Ejemplo trabajado con código
# numpy 2.4 — Cuánto se mueve el precio mientras tu orden viaja: latencia frente a horizonte de la estrategia
import numpy as np
vol_anual = 0.16; precio = 5400.0
seg_por_anio = 252 * 6.75 * 3600 # segundos de sesión regular en un año
sigma_seg = vol_anual / np.sqrt(seg_por_anio) # volatilidad por segundo (aprox. difusiva)
print(f"Volatilidad del S&P por segundo de RTH: {sigma_seg:.6%}")
print(f"{'latencia':>12s} {'mov. típico (pts)':>18s} {'en ticks':>9s} {'vs. barra 1 min':>16s} {'vs. barra 1 día':>16s}")
mov_1min = sigma_seg * np.sqrt(60) * precio; mov_1d = vol_anual / np.sqrt(252) * precio
for ms in [1, 50, 300, 2000]:
mov = sigma_seg * np.sqrt(ms / 1000) * precio
print(f"{ms:>9d} ms {mov:>18.3f} {mov/0.25:>9.2f} {mov/mov_1min:>15.1%} {mov/mov_1d:>15.2%}")
print(f"(movimiento típico de una barra de 1 min: {mov_1min:.2f} pts; de un día: {mov_1d:.1f} pts)")
print("Con 300 ms de latencia doméstica el precio se mueve ~0,8 ticks: nada para una estrategia diaria, más que todo el edge para una que gana medio tick por operación.")Volatilidad del S&P por segundo de RTH: 0.006466%
latencia mov. típico (pts) en ticks vs. barra 1 min vs. barra 1 día
1 ms 0.011 0.04 0.4% 0.02%
50 ms 0.078 0.31 2.9% 0.14%
300 ms 0.191 0.76 7.1% 0.35%
2000 ms 0.494 1.98 18.3% 0.91%
(movimiento típico de una barra de 1 min: 2.70 pts; de un día: 54.4 pts)
Con 300 ms de latencia doméstica el precio se mueve ~0,8 ticks: nada para una estrategia diaria, más que todo el edge para una que gana medio tick por operación.Figura

El error típico
Alquilar un VPS en Chicago para una estrategia de barras de una hora "para tener ventaja". La ventaja de 250 ms sobre 300 ms no existe a ese horizonte: el movimiento típico del precio en una hora son 21 puntos, y en 250 ms son 0,17. El error simétrico: copiar de un foro una estrategia de scalping backtesteada con datos de tick y creer que va a funcionar con el feed retrasado de una plataforma gratuita y una conexión doméstica. El backtest asumía que veías el precio y ejecutabas en el mismo instante; tú ves el precio 200 ms tarde y ejecutas 300 ms después. El edge de medio tick que mostraba el backtest se lo llevan, sistemáticamente, los que están a 1 ms.
Quiz
5 preguntas · se aprueba con 60 %
1.¿Dónde se casan las órdenes de ES?
2.Latencia de 300 ms, ES con volatilidad del 16 % anual. Movimiento típico del precio durante la latencia:
3.Estrategia de barras diarias con resultado medio de 30 puntos por operación. ¿Necesita VPS en Chicago?
4.Tu plataforma gratuita muestra el precio con 400 ms de retraso. Esto afecta a:
5.Una estrategia de scalping muestra +0,5 ticks por operación en backtest con datos de tick sin latencia. Con 300 ms de latencia doméstica:
0 de 5 respondidas
Ejercicio
Mide tu latencia de ejecución: en simulado, envía 10 órdenes de mercado en MES y anota, para cada una, la hora de envío (con milisegundos si tu plataforma lo muestra) y la hora de confirmación del fill. Calcula la mediana. Después, con latencia.py, calcula el movimiento típico de ES durante esa latencia y compáralo con el resultado medio por operación de cualquier estrategia que tengas en mente. Escribe en una frase si la latencia importa para esa estrategia y por qué.
Resultado verificable: desde Europa con conexión doméstica, la mediana debería estar entre 100 y 400 ms. Si tu plataforma no muestra milisegundos, la respuesta es "menos de un segundo", que para cualquier estrategia de barras de un minuto o más ya basta para concluir que no importa.
Qué te llevas
- Tu orden viaja a Illinois y vuelve. Desde Europa, 100-300 ms. En ese tiempo ES se mueve menos de un tick.
- La latencia importa solo si el movimiento durante ella es comparable a tu resultado por operación. Para barras de minutos o más, no lo es.
- Un VPS sirve para fiabilidad, no para velocidad. Ninguna infraestructura crea un edge que no existe.
Fin del módulo M0.3. Examen: 15 preguntas de un banco de 32, 80 % para aprobar. Después: M0.4, TradingView desde cero, donde todo lo que has aprendido sobre libro, órdenes y sesiones lo ves en una pantalla real.
