TWAP vs VWAP vs POV: cómo elegir un benchmark de ejecución (y saber cuándo cada uno te miente)

Todo programador de ejecución es una apuesta sobre un pronóstico de volumen. TWAP apuesta a que la liquidez es plana en el tiempo. VWAP apuesta a que la curva de volumen de hoy se parecerá a la de ayer. POV apuesta a que el volumen que se imprime en la cinta ahora mismo es una buena razón para operar ahora mismo — incluyendo la parte de la cinta que eres tú mismo. Ninguna de estas apuestas aparece etiquetada como apuesta en la documentación de los proveedores, razón por la cual la mayoría de las comparaciones entre los tres se leen como una tabla de características: TWAP es "simple", VWAP es "inteligente", POV es "adaptativo". Ese enfoque no te dice nada sobre cuál te hace perder dinero, cuándo, ni cuánto.

Esta es la segunda parte de un hilo que comenzamos en Tipos de órdenes en trading algorítmico, donde construimos ejecutores de juguete de TWAP y VWAP en ~40 líneas de Python cada uno. Esos ejecutores están bien como plomería. Este artículo trata sobre todo lo que la plomería esconde: los supuestos implícitos, la política de benchmarks y un experimento reproducible cara a cara sobre datos de libro de órdenes replayeados que demuestra que los tres algoritmos no son "sabores diferentes" — son perfiles de riesgo distintos con modos de falla distintos.

Tres programadores, tres apuestas ocultas

Fijemos la notación. Una orden padre de tamaño $X$ debe ejecutarse en el horizonte $[0, T]$, dividido en $N$ intervalos. Sea $x_i$ la cantidad hija en el intervalo $i$, $v_i$ el volumen de mercado en el intervalo $i$, y $p_i$ el precio promedio en el intervalo $i$. El VWAP de mercado sobre el horizonte es

TWAP opera $x_i = X/N$: cantidades iguales en tiempos iguales. El supuesto implícito es que la liquidez —profundidad, spread, volumen— es uniforme en el tiempo, de modo que porciones iguales generan un impacto igual. Esto es falso en cualquier mercado que haya existido jamás, pero falla con elegancia: el programa es determinista, la finalización está garantizada por construcción, y en el peor caso operas un lote fijo en una hora poco líquida y pagas spreads más amplios por ello. El segundo supuesto, menos discutido, es que nadie está mirando. Un TWAP que dispara una orden hija cada 60 segundos en punto es un metrónomo, y a los metrónomos se los adelanta el mercado (front-run). Cualquier TWAP serio aleatoriza el momento y el tamaño de las órdenes hijas; el programa debería ser un proceso tipo Poisson cuya esperanza sea plana, no un reloj.

VWAP opera $x_i = X \cdot u_i$, donde $u_i$ es la fracción pronosticada del volumen diario en el intervalo $i$, con $\sum_i u_i = 1$. Ahora la apuesta es explícita: sostienes una curva $\{u_i\}$ estimada a partir del histórico, y supones que hoy la sigue. El supuesto ya no es que el volumen sea plano, sino que es predecible y exógeno — la curva no le importa si tú operas o no. Cuando el pronóstico es bueno, VWAP concentra tu operativa donde el mercado puede absorberla y tu slippage frente al VWAP de mercado es pequeño de manera casi tautológica. Cuando el pronóstico es malo —un evento noticioso no programado mueve el 40% del volumen del día hacia una hora a la que tu curva asignó un 6%— VWAP sigue operando serenamente según el programa desactualizado y tú pagas la diferencia. VWAP convierte el riesgo de ejecución en riesgo de pronóstico de volumen. Ese es todo el trade-off, y por eso la ingeniería interesante en un motor VWAP está en el pronosticador, no en el trozador.

POV (porcentaje del volumen, también "participación") abandona el pronóstico: opera $x_t = \gamma \cdot V_t$, una fracción fija $\gamma$ del volumen observado en cada intervalo. Esto parece dominar a VWAP — ¿para qué pronosticar el volumen si puedes simplemente seguirlo? El problema es que la señal ahora es endógena. Tus propios fills se imprimen en la cinta. Si el resto del mercado opera $M$ en un intervalo y apuntas a una fracción $\gamma$ del volumen total de la cinta, tu cantidad resuelve $x = \gamma(M + x)$, es decir

Con $\gamma = 0.10$ esa corrección es leve (11.1% del volumen de los demás). Con $\gamma = 0.25$ estás operando el 33% del flujo del resto del mercado; con $\gamma = 0.5$ igualas uno a uno al resto del mercado entero y el punto fijo diverge. POV también renuncia a la única garantía que TWAP y VWAP sí ofrecen: no hay hora de finalización. Si el volumen se muere, también se muere tu programa. Volveremos sobre las patologías de POV más abajo, porque merecen su propia sección.

Un encuadre más que importará después: ninguno de estos tres es "óptimo" en ningún sentido formal. El programador que efectivamente minimiza un objetivo de costo-riesgo es la familia Almgren–Chriss (Almgren and Chriss, 2000, "Optimal Execution of Portfolio Transactions," Journal of Risk 3, 5–39), que tratamos en profundidad en Almgren–Chriss y la teoría de los programas de ejecución óptima. TWAP es el caso especial de Almgren–Chriss con aversión al riesgo nula bajo impacto lineal; VWAP es la estrategia de mínimo error de seguimiento frente a un benchmark ponderado por volumen (Konishi, 2002, "Optimal slice of a VWAP trade," Journal of Financial Markets 5(2)); POV es una heurística que no corresponde a ninguna función objetivo en absoluto, y precisamente por eso sus modos de falla son tan extraños.

Estimando curvas de volumen cuando el mercado nunca cierra

La literatura de renta variable lo tuvo fácil. El volumen intradía en acciones tiene forma de U —pesado en la apertura, tranquilo al mediodía, pesado hacia el cierre— documentado desde Jain and Joh (1988, "The Dependence between Hourly Prices and Trading Volume," JFQA 23(3)) y con fundamento teórico gracias a Admati and Pfleiderer (1988, "A Theory of Intraday Patterns: Volume and Price Variability," Review of Financial Studies 1(1)), quienes mostraron que los traders discrecionales de liquidez y los traders informados se agrupan endógenamente en el tiempo. La forma de U está anclada por dos eventos duros, las subastas de apertura y cierre, así que la curva es estable y un promedio móvil de 20 días de las participaciones de volumen por intervalo te lleva al 90% del camino.

Cripto no tiene apertura ni cierre, así que la lectura ingenua es que el volumen debería ser plano y TWAP ≈ VWAP. Esa lectura ingenua es incorrecta. El volumen intradía de cripto tiene estructura — simplemente está anclado a relojes distintos:

Efectos de sesión. El volumen sigue las horas de vigilia de las personas y mesas que lo operan. En los pares mayores de BTC y ETH, la banda más pesada es la tarde de EE. UU. solapándose con la noche europea (aproximadamente 13:00–21:00 UTC), con una repisa secundaria de Asia entre 00:00–08:00 UTC y un valle pronunciado alrededor de 04:00–06:00 UTC en los mayores. Los pares alt con propiedad regional concentrada sesgan más marcadamente hacia su sesión de origen.

Marcas de tiempo de funding. Los futuros perpetuos liquidan el funding en horarios UTC fijos —históricamente cada 8 horas a las 00:00, 08:00, 16:00 UTC, con Binance y otros migrando muchos contratos a ciclos de liquidación de 4 horas e incluso 1 hora desde 2025–2026. Los minutos alrededor de la liquidación imprimen de forma confiable un volumen elevado: los traders de basis abren y cierran posiciones de carry, y cualquiera que esté jugando con la foto de funding opera justo en el límite. Estos son picos, no repisas — una curva con buckets de 30 minutos los detecta; una curva con buckets de 2 horas los promedia y desaparecen, y tu VWAP participa por debajo de lo debido justo cuando la liquidez es mejor.

Estacionalidad semanal. El volumen de fin de semana en los mayores corre estructuralmente por debajo del volumen entre semana, y el domingo por la noche UTC (lunes por la mañana en Asia, más la reapertura del CME para los futuros de BTC) tiene su propia firma. Una única curva de hora del día agrupada entre todos los días está mal especificada; conviene una grilla de día de la semana × hora del día.

Eventos programados. Las opciones de Deribit expiran a las 08:00 UTC (viernes, con clústeres trimestrales), los datos macro de EE. UU. aterrizan a las 12:30/14:00 UTC, las liquidaciones del CME importan para los flujos de basis. Estas son características de calendario, no estacionalidad — trátalas como variables dummy, no contaminando la curva base.

Un estimador funcional, en el espíritu de mantener honesto al pronosticador antes de hacerlo sofisticado:

import pandas as pd

def volume_curve(trades: pd.DataFrame, bucket="30min") -> pd.Series:
    """day-of-week x time-of-day volume shares from a trades tape."""
    v = trades["qty"].resample(bucket).sum()
    day_total = v.groupby(v.index.date).transform("sum")
    share = v / day_total                      # fraction of that day's volume
    key = [v.index.dayofweek, v.index.time]
    curve = share.groupby(key).median()
    return curve / curve.groupby(level=0).transform("sum")  # renormalize per day

Usar la mediana en lugar de la media no es una cuestión de estilo. El volumen de cripto tiene colas extremadamente pesadas; una sola cascada de liquidaciones puede ser el 15% del volumen del día en 10 minutos, y una curva basada en la media esperará para siempre un pico en ese bucket. La literatura de renta variable fue más allá de las curvas estáticas: Białkowski, Darolles and Le Fol (2008, "Improving VWAP strategies: A dynamic volume approach," Journal of Banking & Finance 32(9), 1709–1722) descomponen el volumen por intervalo en un componente de mercado común y un componente específico de la acción modelado con dinámicas ARMA/SETAR, y muestran que la descomposición reduce materialmente el riesgo de seguimiento de VWAP frente a una curva clásica estática. La traducción a cripto es directa: estima una curva de mercado a partir de los N pares principales (el factor común es fuerte — los relojes de funding y las sesiones son compartidos), y luego modela la desviación de tu par como un proceso intradía de reversión a la media que actualizas en tiempo real. Más recientemente, Genet (2025, "Deep Learning for VWAP Execution in Crypto Markets: Beyond the Volume Curve," arXiv:2502.13722) muestra que programas aprendidos de punta a punta superan al VWAP de curva estática con datos de Binance — evidencia de que en cripto la curva de volumen es el eslabón más débil del pipeline, no el trozado.

El resumen operativo: una curva estática que agrupa todos los días es un VWAP espantapájaros. Si tu comparación muestra que "VWAP apenas le gana a TWAP en cripto", revisa si al VWAP se le dio de comer una curva que realmente contiene los picos de funding y la separación entre semana y fin de semana antes de sacar ninguna conclusión.

Patologías de POV: el algoritmo que persigue su propia cola

La promesa de POV es la adaptabilidad: operar cuando el mercado opera. Tres patologías distintas la socavan.

1. El bucle de retroalimentación. La endogeneidad descrita arriba no es solo una corrección contable. Tus órdenes hijas crean volumen; el volumen eleva tu objetivo; tu objetivo crea volumen. Con $\gamma$ moderado el punto fijo $x = \frac{\gamma}{1-\gamma}M$ es estable, pero la participación medida que muestra tu reporte post-operación ($\gamma$ del total de la cinta) subestima tu huella respecto de lo que habría sido el mercado sin ti ($\frac{\gamma}{1-\gamma}$ del resto). Peor aún, existe retroalimentación de segundo orden: tus fills mueven el precio, el movimiento de precio atrae flujo de momentum y dispara stops, ese flujo eleva el volumen de la cinta, y tu motor POV interpreta el volumen que él mismo causó como una invitación a acelerar. Esto es exactamente lo contrario del comportamiento óptimo — los programadores conscientes del impacto (Almgren–Chriss con parámetros razonables, y estimaciones empíricas de impacto como Almgren, Thum, Hauptmann and Li, 2005, "Direct Estimation of Equity Market Impact," Risk 18(7)) quieren que desaceleres después de empujar el precio, no que aceleres. Una cascada de liquidaciones es el límite patológico: volumen de cinta enorme, libro unilateral, y un POV vainilla compra con más fuerza justo en la cima del apretón porque ahí es donde están los prints.

2. Ser explotado. Un algoritmo POV es una máquina de flujo de órdenes disparada por volumen, y todo lo que se dispara se puede cebar. Un predador que sospecha de un comprador grande de participación puede imprimir volumen —cruzándose consigo mismo donde las reglas lo permiten, o simplemente operando activamente en tamaño pequeño— para adelantar al motor POV, y luego proveerle liquidez a precios inflados. Esta es una instancia a pequeña escala del mecanismo general descrito en Brunnermeier and Pedersen (2005, "Predatory Trading," Journal of Finance 60(4)): cuando tu demanda futura es predecible a partir de tu comportamiento pasado, otros operan por delante de ella y la trayectoria de precio que enfrentas es peor que la que pronosticaste. TWAP filtra un programa en el tiempo; POV filtra una función de respuesta, lo cual es más peligroso porque el adversario puede invocarla a demanda.

3. La cola que nunca termina. POV no tiene reloj. Si debes comprar 500 BTC antes de las 16:00 UTC y el volumen se evapora a las 14:00, un POV puro se queda esperando — es, por diseño, incapaz de terminar por sí solo. Por eso toda implementación de producción de POV lleva un piso de tasa mínima y un modo de recuperación (catch-up), y el modo de recuperación es donde se esconden las pérdidas: pasas el día operando pasivamente al 10% de participación, y luego disparas el 30% residual de la orden padre a través de una ventana de cierre poco líquida a una participación efectiva triple de tu objetivo. El promedio post-operación se ve bien; el costo marginal del último tramo es brutal. Si tus reportes de POV no separan la cola, no has visto su verdadero costo.

def pov_child_qty(tape_vol: float, gamma: float, remaining: float,
                  t_left_s: float, min_rate: float) -> float:
    target = gamma / (1.0 - gamma) * tape_vol   # exclude our own prints
    floor = remaining / max(t_left_s, 1.0) * CHILD_INTERVAL_S
    if t_left_s < CATCHUP_HORIZON_S:            # deadline dominates
        floor = max(floor, remaining * CHILD_INTERVAL_S / t_left_s)
    return min(remaining, max(target, floor, min_rate))

Dos detalles en este fragmento hacen un trabajo real: el objetivo usa $\frac{\gamma}{1-\gamma}$ del volumen de cinta ex-nosotros (debes restar tus propios fills de la cinta a la que reaccionas — sorprendentemente, muchas implementaciones no lo hacen), y el piso de plazo convierte a POV en un TWAP sobre el residual a medida que se agota el tiempo, lo cual al menos hace que el costo de la cola sea predecible.

Benchmarks: por qué ganarle al VWAP igual puede hacerte perder dinero

El programador y el benchmark son elecciones separadas, y confundirlas es el pecado post-operación más común. Dos benchmarks dominan.

El benchmark VWAP —comparar tu precio promedio de fill con el VWAP del intervalo— fue introducido por Berkowitz, Logue and Noser (1988, "The Total Cost of Transactions on the NYSE," Journal of Finance 43(1)), quienes propusieron el precio ponderado por volumen del día como una vara neutral para medir la calidad de ejecución institucional. Se convirtió en el estándar de la industria por una razón tan sociológica como técnica: es fácil de calcular, fácil de explicar, y difícil de que te haga quedar mal si simplemente distribuyes tu operativa a lo largo del día.

El implementation shortfall (precio de llegada) viene de Perold (1988, "The Implementation Shortfall: Paper Versus Reality," Journal of Portfolio Management 14(3), 4–9): mide todo contra el precio $p_0$ en el momento en que se tomó la decisión. Para una compra de $X$ con cantidad ejecutada $X_f$ a precio promedio $\bar{p}$, precio terminal $p_T$:

El planteo de Perold era que la brecha entre carteras de papel y carteras reales es precisamente esta cantidad — y nótese que te cobra por lo que no lograste ejecutar, cosa que el benchmark VWAP ignora silenciosamente. Ese término de costo de oportunidad es lo que hace del IS el único benchmark honesto para POV, cuyo modo de falla característico es la cantidad no ejecutada.

Ahora la trampa. El VWAP como benchmark tiene dos puntos ciegos estructurales:

Es autorreferencial. Tus fills están dentro del benchmark. Si eres el 30% del volumen del intervalo, entonces aproximadamente el 30% del VWAP es tu propio precio promedio, y tu slippage medido frente al VWAP se reduce mecánicamente por tu propia participación — cuanto más grande y más impactante sea tu orden, mejor puntúa. En el límite donde eres el único trader, le ganas al VWAP por exactamente cero, sin importar cuán mal hayas movido el precio. El slippage de VWAP mide adherencia al programa, no costo.

Ignora la deriva relativa a la decisión. Números concretos: decides comprar 100 BTC a un precio de decisión de $60,000. El mercado sube toda la tarde; el VWAP del intervalo imprime $60,320 y tú ejecutas a un promedio de $60,290. Reporte VWAP: –5 bps, superó el benchmark, la mesa recibe una celda verde. Reporte de llegada: pagaste $290 sobre el precio de decisión en 100 BTC — +48 bps, $29,000 de implementation shortfall. Ambos números son correctos. Solo uno de ellos es dinero. Y la corrupción de incentivos va más profundo: un trader calificado por VWAP debería desacelerar en un día con tendencia (distribuir las operaciones sigue mejor al benchmark), lo cual es exactamente lo opuesto de lo que minimiza el shortfall cuando el precio se te está escapando. El benchmark no solo mide mal el costo — prescribe el comportamiento equivocado. Kissell (2013, The Science of Algorithmic Trading and Portfolio Management, Academic Press) trata este problema de selección de benchmark en extenso; su encuadre vale la pena internalizarlo: el benchmark codifica de quién estás gestionando el riesgo. VWAP gestiona el riesgo de vergüenza de la mesa ejecutora. El precio de llegada gestiona el P&L de la cartera.

Resolución práctica: califica las estrategias por implementation shortfall; usa el slippage de VWAP como diagnóstico (aísla la habilidad de programación de la suerte de timing, ya que la deriva te afecta tanto a ti como al benchmark); y nunca dejes que alguien cuya orden fue >10% del volumen del intervalo cite el slippage de VWAP sin también citar la participación.

El experimento: tres algoritmos, una sola cinta

Con las definiciones asentadas, podemos hacer lo que los artículos comparativos nunca hacen: correr los tres programadores sobre órdenes padre idénticas, sobre los mismos datos replayeados, y mirar las distribuciones de costo, no los adjetivos. El harness corre sobre el simulador de fills orientado a eventos descrito en Simulación de fills: fills parciales, posición en cola y por qué los fills de tu backtest mienten — profundidad L2 replayeada, las órdenes límite hijas ganan posición en cola, las órdenes hijas agresivas caminan el libro, y nuestros fills perturban la cinta que observan los programadores (lo cual importa enormemente para POV, según la sección de retroalimentación).

Configuración, para que puedas reproducirlo con tus propios datos:

• Instrumento/datos: BTCUSDT perpetuo, 90 días de replay L2 (20 niveles superiores, 100 ms) + cinta de operaciones.
• Órdenes padre: 500 por algoritmo, idénticas entre algoritmos: horarios de inicio aleatorios, horizonte $T = 4$h, tamaño 0.75% del ADV móvil de 30 días (suficientemente grande para que el impacto sea real, suficientemente pequeño para que los tres puedan plausiblemente terminar), lado comprador, precio de decisión = mid al inicio.
• TWAP: 48 porciones hijas, ±30% de jitter en tiempo/tamaño.
• VWAP: curva de mediana de día de la semana × hora del día en buckets de 30 minutos (el estimador de arriba), reajustada semanalmente, sin actualización intradía — deliberadamente la versión simple.
• POV: $\gamma = 12\%$ del volumen de cinta ex-nosotros, piso de tasa mínima, recuperación tipo TWAP en los últimos 30 min.
• Métricas: IS en bps del precio de decisión (comisiones incluidas), slippage de VWAP en bps, tasa de finalización, y —lo que nadie reporta— el IS del cuartil final de cada orden padre.

Resultados representativos de nuestras corridas (tus números serán distintos; la forma no debería):

Tres lecturas, en orden creciente de importancia:

Las medias favorecen a POV y las colas lo condenan. POV gana en IS medio y mediano — adaptarse a la liquidez realizada realmente vale un par de bps sobre una curva estática. Pero su desviación estándar del IS y su percentil 95 son los peores de los tres, su tasa de finalización no es del 100%, y su costo en el cuartil final más que duplica su cifra titular: la cola que nunca termina más el modo de recuperación concentran el costo justo donde los promedios lo esconden. Si tus órdenes padre están impulsadas por alfa con un horizonte estricto, esa cola es el número que importa, y la ventaja de media de POV no la compensa.

La ventaja de VWAP sobre TWAP es exactamente la calidad de su pronóstico. Si condicionas la brecha de IS entre VWAP y TWAP al error de la curva de volumen realizada (distancia $L_1$ entre el pronóstico $u_i$ y las participaciones realizadas), la relación es monótona: en el tercil de días con mejor pronóstico, VWAP le gana a TWAP por ~4 bps; en el peor tercil la brecha está dentro del ruido y a veces se invierte. En cripto, el peor tercil no es aleatorio — son los días de cascadas y los días de noticias, que también son los días de mayor costo en general. VWAP mejora tu promedio superando en los días que de todas formas eran fáciles.

El slippage de VWAP y el IS clasifican a los algoritmos de forma distinta. POV registra un slippage de VWAP medio negativo — por supuesto que sí, opera proporcionalmente al mismo volumen que define el benchmark, y sus fills están dentro de él. Según el marcador de VWAP, POV es el mejor algoritmo aquí; según el marcador de precio de llegada y el riesgo de finalización, es el más peligroso. La misma cinta, los mismos fills, conclusión opuesta — que es exactamente el argumento de la sección anterior convertido en tabla.

El harness en sí son ~50 líneas alrededor del simulador de fills y vale cada minuto invertido, porque convierte la selección de programador de un debate de gustos en una medición:

for parent in sample_parents(n=500, horizon="4h", adv_frac=0.0075):
    for algo in (twap, vwap, pov):
        sim = ReplaySim(l2_stream(parent.window), fees=TAKER_MAKER)
        fills = sim.run(algo.schedule(parent))          # fills perturb the tape
        report(parent, algo, is_bps(fills, parent.p0),
               vwap_slip_bps(fills, sim.tape), fills.completion)

Cómo elegir, en la práctica

Las reglas de selección honestas que se desprenden de todo esto:

• Plazo estricto, orden padre impulsada por alfa: TWAP o un programa Almgren–Chriss cargado al frente. Paga el impuesto de liquidez plana; compra la garantía de finalización y la cola acotada. Aleatoriza las órdenes hijas.
• Flujo calificado por benchmark (te pagan literalmente por VWAP), o tamaño grande en un día normal: VWAP — y gasta tu presupuesto de ingeniería en el pronosticador de volumen: grilla de día de la semana, resolución de picos de funding, actualización dinámica intradía al estilo Białkowski–Darolles–Le Fol. Un motor VWAP con una curva perezosa es un TWAP con pasos extra.
• Oportunista, sin plazo estricto, sensible a la liquidez: POV con $\gamma$ moderado (≤15%), calculado sobre volumen ex-nosotros, con un filtro de cascadas (limita la participación cuando los z-scores del volumen de cinta se disparan) y un mecanismo de plazo de respaldo cuyo costo mides por separado.
• Lo que sea que corras: califícalo por implementation shortfall contra el precio de llegada, según Perold. Mantén el slippage de VWAP como diagnóstico de habilidad de programación, nunca como marcador — el marcador debe estar denominado en dinero, y solo el precio de llegada lo está.

Y la meta-regla que el experimento sigue reforzando: compara distribuciones, no medias, sobre tus propios datos replayeados. Un programador es una apuesta sobre un pronóstico de volumen, y no se evalúan las apuestas por su pago promedio ignorando las colas — así es como el mercado te vende POV.