Saltar al contenido
ALX Quant
← M0.3 · Cómo funciona un mercado

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 / horizonteMovimiento típicoEn ticksRespecto a una barra de 1 minRespecto a un día
1 ms (colocation)0,011 pts0,040,4 %0,02 %
50 ms (VPS en Chicago)0,078 pts0,312,9 %0,14 %
300 ms (casa, Europa)0,191 pts0,767,1 %0,35 %
2 s (clic manual lento)0,494 pts1,9818 %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 Δt\Delta t es σΔt⋅P\sigma \sqrt{\Delta t} \cdot P, con σ\sigma la volatilidad por unidad de tiempo. La tabla usa σseg=σanual/252⋅6,75⋅3600\sigma_{seg} = \sigma_{anual} / \sqrt{252 \cdot 6{,}75 \cdot 3600}, 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 σΔtlat⋅P\sigma\sqrt{\Delta t_{lat}} \cdot P 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

Gráfico en escala log-log: horizonte en segundos de 1 ms a un día de sesión frente a movimiento típico del precio de ES en ticks. Una recta azul ascendente (pendiente 1/2). Puntos en coral marcan 1 ms (colocation), 300 ms (casa), 1 minuto y 1 hora. Una línea horizontal teal en 0,5 ticks etiquetada 'edge de medio tick por operación' cruza la recta entre 50 y 300 ms.
Donde la recta cruza tu edge es donde la latencia empieza a importar. Para medio tick, eso pasa alrededor de los 100-300 ms: justo la latencia doméstica. Para 50 puntos, no pasa nunca.

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. 1.¿Dónde se casan las órdenes de ES?

  2. 2.Latencia de 300 ms, ES con volatilidad del 16 % anual. Movimiento típico del precio durante la latencia:

  3. 3.Estrategia de barras diarias con resultado medio de 30 puntos por operación. ¿Necesita VPS en Chicago?

  4. 4.Tu plataforma gratuita muestra el precio con 400 ms de retraso. Esto afecta a:

  5. 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

  1. Tu orden viaja a Illinois y vuelve. Desde Europa, 100-300 ms. En ese tiempo ES se mueve menos de un tick.
  2. 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.
  3. 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.