TWAP vs VWAP vs POV: scegliere un benchmark di esecuzione (e sapere quando ciascuno ti inganna)

Ogni scheduler di esecuzione è una scommessa su una previsione di volume. TWAP scommette che la liquidità sia costante nel tempo. VWAP scommette che la curva di volume di oggi assomiglierà a quella di ieri. POV scommette che il volume che sta stampando sul tape proprio adesso sia un buon motivo per operare proprio adesso — inclusa la parte del tape che sei tu stesso. Nessuna di queste scommesse viene etichettata come scommessa nella documentazione dei fornitori, ed è per questo che la maggior parte dei confronti tra i tre si legge come una tabella di funzionalità: TWAP è "semplice", VWAP è "intelligente", POV è "adattivo". Quella narrazione non ti dice nulla su quale ti fa perdere denaro, quando, o quanto.

Questa è la parte 2 di un filone che abbiamo iniziato in Tipi di ordine nel trading algoritmico, dove abbiamo costruito degli executor giocattolo TWAP e VWAP in ~40 righe di Python ciascuno. Quegli executor vanno benissimo come infrastruttura di base. Questo articolo riguarda tutto ciò che l'infrastruttura nasconde: le ipotesi implicite, le politiche del benchmark e un esperimento riproducibile a confronto diretto su dati di order book riprodotti che mostra come i tre algoritmi non siano "gusti diversi" — sono profili di rischio diversi con modalità di fallimento diverse.

Tre scheduler, tre scommesse nascoste

Fissiamo la notazione. Un ordine parent di dimensione $X$ deve essere eseguito su un orizzonte $[0, T]$, suddiviso in $N$ intervalli. Sia $x_i$ la quantità child nell'intervallo $i$, $v_i$ il volume di mercato nell'intervallo $i$, e $p_i$ il prezzo medio nell'intervallo $i$. Il VWAP di mercato sull'orizzonte è

TWAP opera $x_i = X/N$: quantità uguali in tempi uguali. L'ipotesi implicita è che la liquidità — profondità, spread, volume — sia uniforme nel tempo, così che fette uguali comportino un impatto uguale. Questo è falso in ogni mercato che sia mai esistito, ma fallisce con grazia: lo schedule è deterministico, il completamento è garantito per costruzione, e il caso peggiore è che tu operi una fetta fissa in un'ora sottile e paghi spread più ampi per farlo. La seconda ipotesi, meno discussa, è che nessuno ti stia guardando. Un TWAP che spara un ordine child ogni 60 secondi allo scoccare del :00 è un metronomo, e i metronomi vengono anticipati. Qualsiasi TWAP serio randomizza tempistica e dimensione dei child; lo schedule dovrebbe essere un processo quasi poissoniano la cui aspettativa è piatta, non un orologio.

VWAP opera $x_i = X \cdot u_i$, dove $u_i$ è la frazione prevista di volume giornaliero nell'intervallo $i$, $\sum_i u_i = 1$. La scommessa ora è esplicita: tieni una curva $\{u_i\}$ stimata dallo storico e assumi che oggi la segua. L'ipotesi non è che il volume sia piatto ma che sia prevedibile ed esogeno — alla curva non importa se operi tu. Quando la previsione è buona, VWAP concentra le tue operazioni dove il mercato può assorbirle e il tuo slippage rispetto al VWAP di mercato è piccolo quasi per tautologia. Quando la previsione è sbagliata — una notizia non programmata sposta il 40% del volume della giornata in un'ora a cui la tua curva aveva assegnato il 6% — VWAP continua serenamente a operare lo schedule ormai obsoleto e ti mangi la differenza. VWAP converte il rischio di esecuzione in rischio di previsione del volume. È tutto qui il compromesso, ed è per questo che l'ingegneria interessante in un motore VWAP è il forecaster, non lo slicer.

POV (percentage of volume, detto anche "participation") abbandona la previsione: opera $x_t = \gamma \cdot V_t$, una frazione fissa $\gamma$ del volume osservato in ogni intervallo. Sembra dominare VWAP — perché prevedere il volume quando puoi semplicemente seguirlo? La fregatura è che il segnale ora è endogeno. I tuoi stessi fill si stampano sul tape. Se il resto del mercato opera $M$ in un intervallo e tu punti a una frazione $\gamma$ del volume totale del tape, la tua quantità risolve $x = \gamma(M + x)$, ovvero

A $\gamma = 0.10$ quella correzione è lieve (11,1% del volume altrui). A $\gamma = 0.25$ stai operando il 33% del flusso di tutti gli altri; a $\gamma = 0.5$ eguagli uno a uno l'intero resto del mercato e il punto fisso diverge. POV inoltre rinuncia all'unica garanzia che sia TWAP sia VWAP offrono: non c'è un tempo di completamento. Se il volume muore, muore anche il tuo schedule. Torneremo sulle patologie di POV più avanti, perché meritano una sezione a sé.

Un'ultima cornice che conterà più avanti: nessuno di questi tre è "ottimale" in alcun senso formale. Lo scheduler che effettivamente minimizza un obiettivo costo-rischio è la famiglia Almgren–Chriss (Almgren and Chriss, 2000, "Optimal Execution of Portfolio Transactions," Journal of Risk 3, 5–39), che trattiamo come si deve in Almgren–Chriss e la teoria degli schedule di esecuzione ottimale. TWAP è il caso speciale di Almgren–Chriss con avversione al rischio nulla sotto impatto lineare; VWAP è la strategia a minimo tracking error contro un benchmark ponderato per il volume (Konishi, 2002, "Optimal slice of a VWAP trade," Journal of Financial Markets 5(2)); POV è un'euristica che non corrisponde ad alcuna funzione obiettivo, il che è precisamente il motivo per cui le sue modalità di fallimento sono così strane.

Stimare le curve di volume quando il mercato non chiude mai

La letteratura sull'azionario aveva vita facile. Il volume intraday nell'azionario ha una forma a U — intenso all'apertura, tranquillo a pranzo, intenso verso la chiusura — documentato fin da Jain and Joh (1988, "The Dependence between Hourly Prices and Trading Volume," JFQA 23(3)) e con fondamento teorico dato da Admati and Pfleiderer (1988, "A Theory of Intraday Patterns: Volume and Price Variability," Review of Financial Studies 1(1)), che hanno mostrato come i trader di liquidità discrezionali e i trader informati si raggruppino endogenamente nel tempo. La forma a U è ancorata da due eventi netti, le aste di apertura e di chiusura, quindi la curva è stabile e una media mobile a 20 giorni delle quote di volume per intervallo ti porta al 90% del risultato.

Le cripto non hanno né apertura né chiusura, quindi la lettura ingenua è che il volume dovrebbe essere piatto e TWAP ≈ VWAP. La lettura ingenua è sbagliata. Il volume intraday delle cripto ha struttura — è semplicemente ancorato a orologi diversi:

Effetti di sessione. Il volume segue le ore di veglia delle persone e dei desk che lo scambiano. Sui major BTC ed ETH, la fascia più intensa è il pomeriggio statunitense sovrapposto alla sera europea (all'incirca 13:00–21:00 UTC), con una mensola secondaria asiatica intorno alle 00:00–08:00 UTC e un avvallamento pronunciato intorno alle 04:00–06:00 UTC sui major. Le coppie alt con proprietà concentrata a livello regionale sono più sbilanciate verso la loro sessione domestica.

Timestamp del funding. I perpetual futures regolano il funding a orari UTC fissi — storicamente ogni 8 ore alle 00:00, 08:00, 16:00 UTC, con Binance e altri che dal 2025–2026 hanno spostato molti contratti a cicli di regolamento a 4 ore e persino a 1 ora. I minuti attorno al settlement stampano in modo affidabile volume elevato: i basis trader aprono e chiudono posizioni di carry, e chiunque cerchi di sfruttare lo snapshot del funding opera proprio al confine. Questi sono picchi, non mensole — una curva con bucket da 30 minuti li vede; una curva con bucket da 2 ore li media via e il tuo VWAP sotto-partecipa esattamente quando la liquidità è al meglio.

Stagionalità settimanale. Il volume del weekend sui major è strutturalmente inferiore a quello dei giorni feriali, e la domenica sera UTC (lunedì mattina in Asia, più la riapertura del CME per i futures su BTC) ha la sua firma. Una singola curva time-of-day accorpata su tutti i giorni è mal specificata; ti serve una griglia day-of-week × time-of-day.

Eventi programmati. Le opzioni Deribit scadono alle 08:00 UTC (il venerdì, con cluster trimestrali), i dati macro USA arrivano alle 12:30/14:00 UTC, i settlement del CME contano per i flussi di basis. Queste sono feature di calendario, non stagionalità — gestiscile come dummy, non inquinando la curva di base.

Uno stimatore utilizzabile, nello spirito di mantenere onesto il forecaster prima di renderlo furbo:

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

La mediana al posto della media non è una scelta stilistica. Il volume delle cripto ha code estremamente pesanti; una singola cascata di liquidazioni può valere il 15% del volume di una giornata in 10 minuti, e una curva basata sulla media si aspetterà per sempre un picco in quel bucket. La letteratura sull'azionario è andata oltre le curve statiche: Białkowski, Darolles and Le Fol (2008, "Improving VWAP strategies: A dynamic volume approach," Journal of Banking & Finance 32(9), 1709–1722) scompongono il volume per intervallo in una componente di mercato comune e una componente specifica del titolo modellata con dinamiche ARMA/SETAR, e mostrano che la scomposizione riduce in modo sostanziale il rischio di tracking del VWAP rispetto a una curva classica statica. La traduzione in ambito cripto è diretta: stima una curva a livello di mercato dalle prime N coppie (il fattore comune è forte — gli orologi del funding e le sessioni sono condivisi), poi modella la deviazione della tua coppia come un processo intraday mean-reverting che aggiorni in tempo reale. Più di recente, Genet (2025, "Deep Learning for VWAP Execution in Crypto Markets: Beyond the Volume Curve," arXiv:2502.13722) mostra che schedule end-to-end appresi battono il VWAP a curva statica sui dati di Binance — evidenza che nelle cripto la curva di volume è l'anello più debole della pipeline, non lo slicing.

Il riassunto operativo: una curva statica su tutti i giorni è un VWAP fantoccio. Se il tuo confronto mostra che "nelle cripto VWAP batte a malapena TWAP", verifica se al VWAP sia stata data una curva che contiene davvero i picchi di funding e la distinzione feriale/weekend prima di concludere qualsiasi cosa.

Patologie di POV: l'algoritmo che rincorre la propria coda

Il pitch di POV è l'adattività: opera quando il mercato opera. Tre patologie distinte lo minano.

1. Il ciclo di feedback. L'endogeneità di cui sopra non è solo una correzione contabile. I tuoi ordini child creano volume; il volume alza il tuo target; il tuo target crea volume. A $\gamma$ moderato il punto fisso $x = \frac{\gamma}{1-\gamma}M$ è stabile, ma la partecipazione misurata che il tuo report post-trade mostra ($\gamma$ del tape totale) sottostima la tua impronta rispetto a quello che il mercato sarebbe stato senza di te ($\frac{\gamma}{1-\gamma}$ di tutti gli altri). Peggio, esiste un feedback di secondo ordine: i tuoi fill muovono il prezzo, il movimento di prezzo attira flusso di momentum e innesca gli stop, quel flusso alza il volume del tape, e il tuo motore POV legge il volume che ha causato lui stesso come un invito ad accelerare. Questo è esattamente l'opposto del comportamento ottimale — gli scheduler consapevoli dell'impatto (Almgren–Chriss con parametri ragionevoli, e stime empiriche dell'impatto come Almgren, Thum, Hauptmann and Li, 2005, "Direct Estimation of Equity Market Impact," Risk 18(7)) vogliono che tu rallenti dopo aver spinto il prezzo, non che acceleri. Una cascata di liquidazioni è il limite patologico: volume del tape enorme, book a senso unico, e un POV vaniglia compra con più forza proprio in cima allo squeeze perché è lì che ci sono le stampe.

2. Essere raggirato. Un algo POV è una macchina di order flow innescata dal volume, e qualsiasi cosa innescata è adescabile. Un predatore che sospetta la presenza di un grosso compratore in participation può stampare volume — self-crossing dove le regole lo permettono, o semplicemente operando attivamente in piccola taglia — per tirare avanti il motore POV, e poi fornirgli liquidità a prezzi maggiorati. Questa è un'istanza in piccola scala del meccanismo generale in Brunnermeier and Pedersen (2005, "Predatory Trading," Journal of Finance 60(4)): quando la tua domanda futura è prevedibile dal tuo comportamento passato, altri operano davanti a te e il percorso di prezzo che affronti è peggiore di quello che avevi previsto. TWAP fa trapelare uno schedule nel tempo; POV fa trapelare una funzione di risposta, che è più pericolosa perché l'avversario può invocarla a comando.

3. La coda che non finisce mai. POV non ha orologio. Se devi comprare 500 BTC entro le 16:00 UTC e il volume evapora alle 14:00, un POV puro si siede e aspetta — è, per progettazione, incapace di finire da solo. Ogni POV di produzione porta quindi con sé un min-rate floor e una modalità catch-up, ed è nella modalità catch-up che si nascondono le perdite: passi la giornata operando passivamente al 10% di participation, poi scarichi il residuo 30% del parent attraverso una finestra di chiusura sottile a una participation effettiva pari al triplo del tuo target. La media post-trade sembra a posto; il costo marginale dell'ultima tranche è brutale. Se i tuoi report POV non isolano la coda separatamente, non hai visto il suo costo reale.

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))

Due dettagli in questo snippet fanno davvero il lavoro: il target usa $\frac{\gamma}{1-\gamma}$ del volume del tape al netto di noi (devi sottrarre i tuoi stessi fill dal tape a cui reagisci — un numero sorprendente di implementazioni non lo fa), e il floor della deadline trasforma POV in un TWAP-sul-residuo man mano che il tempo scade, il che almeno rende prevedibile il costo della coda.

Benchmark: perché battere il VWAP può comunque farti perdere denaro

Lo scheduler e il benchmark sono scelte separate, e confonderli è il peccato post-trade più comune. Due benchmark dominano.

Il benchmark VWAP — confronta il tuo prezzo medio di fill con il VWAP dell'intervallo — è stato introdotto da Berkowitz, Logue and Noser (1988, "The Total Cost of Transactions on the NYSE," Journal of Finance 43(1)), che proposero il prezzo ponderato per il volume della giornata come metro neutro per la qualità di esecuzione istituzionale. È diventato lo standard di settore per un motivo sociologico tanto quanto tecnico: è facile da calcolare, facile da spiegare e difficile da sfigurare se semplicemente distribuisci le tue operazioni durante la giornata.

L'implementation shortfall (prezzo di arrivo) viene da Perold (1988, "The Implementation Shortfall: Paper Versus Reality," Journal of Portfolio Management 14(3), 4–9): misura tutto rispetto al prezzo $p_0$ nel momento in cui è stata presa la decisione. Per un acquisto di $X$ con quantità eseguita $X_f$ a prezzo medio $\bar{p}$, prezzo terminale $p_T$:

Il punto di Perold era che il divario tra portafogli sulla carta e portafogli reali è precisamente questa quantità — e nota che ti addebita ciò che non sei riuscito a eseguire, cosa che il benchmark VWAP ignora silenziosamente. È quel termine di costo-opportunità a rendere l'IS l'unico benchmark onesto per POV, la cui modalità di fallimento caratteristica è la quantità non eseguita.

Ora la trappola. Il VWAP come benchmark ha due punti ciechi strutturali:

È auto-referenziale. I tuoi fill sono dentro il benchmark. Se sei il 30% del volume dell'intervallo, allora circa il 30% del VWAP è il tuo stesso prezzo medio, e il tuo slippage misurato rispetto al VWAP è meccanicamente ridotto dalla tua stessa participation — più grande e impattante è il tuo ordine, meglio va nel punteggio. Nel limite in cui sei l'unico trader, batti il VWAP esattamente di zero indipendentemente da quanto male hai mosso il prezzo. Lo slippage sul VWAP misura l'aderenza allo schedule, non il costo.

Ignora il drift rispetto alla decisione. Numeri concreti: decidi di comprare 100 BTC a un prezzo di decisione di $60.000. Il mercato è in trend rialzista per tutto il pomeriggio; il VWAP dell'intervallo stampa $60.320 e tu esegui a una media di $60.290. Report VWAP: –5 bps, battuto il benchmark, il desk ottiene una cella verde. Report arrival: hai pagato $290 sopra il prezzo di decisione su 100 BTC — +48 bps, $29.000 di implementation shortfall. Entrambi i numeri sono corretti. Solo uno di essi è denaro. E la distorsione degli incentivi è ancora più profonda: un trader valutato sul VWAP dovrebbe rallentare in una giornata di trend (distribuire le operazioni segue meglio il benchmark), che è esattamente l'opposto di ciò che minimizza lo shortfall quando il prezzo ti sta scappando. Il benchmark non solo misura male il costo — prescrive il comportamento sbagliato. Kissell (2013, The Science of Algorithmic Trading and Portfolio Management, Academic Press) tratta a lungo questo problema di selezione del benchmark; la sua impostazione vale la pena interiorizzarla: il benchmark codifica di chi stai gestendo il rischio. Il VWAP gestisce il rischio di imbarazzo del desk esecutore. Il prezzo di arrivo gestisce il P&L del portafoglio.

Risoluzione pratica: valuta le strategie sull'implementation shortfall; usa lo slippage sul VWAP come diagnostica (isola l'abilità di scheduling dalla fortuna di timing, dato che il drift colpisce sia te sia il benchmark); e non lasciare mai che qualcuno il cui ordine era >10% del volume dell'intervallo citi lo slippage sul VWAP senza citare anche la participation.

L'esperimento: tre algoritmi, un tape

Definizioni sistemate, possiamo fare ciò che gli articoli di confronto non fanno mai: eseguire i tre scheduler su ordini parent identici sugli stessi dati riprodotti e guardare le distribuzioni di costo, non gli aggettivi. Il harness gira sul simulatore di fill event-driven descritto in Simulazione dei fill: fill parziali, posizione in coda e perché i fill del tuo backtest sono bugie — profondità L2 riprodotta, gli ordini limit child guadagnano posizione in coda, i child aggressivi camminano il book, e i nostri fill perturbano il tape che gli scheduler osservano (il che conta enormemente per POV, come da sezione sul feedback).

Setup, così puoi riprodurlo sui tuoi dati:

• Strumento/dati: perpetual BTCUSDT, 90 giorni di replay L2 (primi 20 livelli, 100 ms) + trades tape.
• Ordini parent: 500 per algoritmo, identici tra gli algoritmi: orari di inizio casuali, orizzonte $T = 4$h, dimensione pari allo 0,75% dell'ADV trailing a 30 giorni (abbastanza grande perché l'impatto sia reale, abbastanza piccola perché tutti e tre possano plausibilmente finire), lato buy, prezzo di decisione = mid all'avvio.
• TWAP: 48 fette child, jitter ±30% su tempistica/dimensione.
• VWAP: curva mediana a 30 min day-of-week × time-of-day (stimatore sopra), ricalibrata settimanalmente, nessun aggiornamento intraday — deliberatamente la versione semplice.
• POV: $\gamma = 12\%$ del volume del tape al netto di noi, min-rate floor, catch-up TWAP negli ultimi 30 min.
• Metriche: IS in bps del prezzo di decisione (commissioni incluse), slippage sul VWAP in bps, tasso di completamento e — quella che nessuno riporta — IS dell'ultimo quartile di ciascun parent.

Risultati rappresentativi delle nostre esecuzioni (i tuoi numeri saranno diversi; la forma non dovrebbe esserlo):

Tre letture, in ordine crescente di importanza:

Le medie lusingano POV e le code lo condannano. POV vince su IS medio e mediano — adattarsi alla liquidità realizzata vale genuinamente un paio di bps rispetto a una curva statica. Ma la sua deviazione standard dell'IS e il 95° percentile sono i peggiori dei tre, il suo tasso di completamento non è al 100%, e il suo costo sull'ultimo quartile è più del doppio del suo dato di testa: la coda che non finisce mai più la modalità catch-up concentrano il costo esattamente dove le medie lo nascondono. Se i tuoi ordini parent sono guidati da alpha con un orizzonte rigido, quella coda è il numero che conta, e il vantaggio medio di POV non la ripaga.

Il vantaggio del VWAP sul TWAP è esattamente la sua qualità di previsione. Condiziona il gap di IS VWAP–TWAP all'errore realizzato della curva di volume (distanza $L_1$ tra le quote previste $u_i$ e quelle realizzate) e la relazione è monotona: nel terzile dei giorni con miglior previsione VWAP batte TWAP di ~4 bps; nel terzile peggiore il gap è dentro il rumore e occasionalmente si inverte. Nelle cripto, il terzile peggiore non è casuale — sono giorni di cascata e giorni di notizie, che sono anche i giorni a costo più alto in assoluto. VWAP migliora la tua media sovraperformando nei giorni che erano comunque facili.

Lo slippage sul VWAP e l'IS classificano gli algoritmi in modo diverso. POV registra uno slippage medio sul VWAP negativo — ovviamente, opera in proporzione proprio al volume che definisce il benchmark, e i suoi fill stanno al suo interno. Secondo il tabellone VWAP, POV è il miglior algoritmo qui; secondo il tabellone arrival e il rischio di completamento, è il più pericoloso. Stesso tape, stessi fill, conclusione opposta — che è l'intero argomento della sezione precedente reso sotto forma di tabella.

Il harness in sé è ~50 righe attorno al simulatore di fill e vale ogni minuto, perché converte la scelta dello scheduler da un dibattito di gusti a una misurazione:

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)

Scegliere, nella pratica

Le regole di selezione oneste che emergono da tutto questo:

• Deadline rigida, parent guidato da alpha: TWAP o uno schedule Almgren–Chriss caricato in testa. Paga la tassa della liquidità piatta; compra la garanzia di completamento e la coda limitata. Randomizza i child.
• Flusso guidato dal benchmark (sei letteralmente pagato sul VWAP), o taglia grande in una giornata normale: VWAP — e spendi il tuo budget di ingegneria sul forecaster del volume: griglia day-of-week, risoluzione dei picchi di funding, aggiornamento dinamico intraday alla Białkowski–Darolles–Le Fol. Un motore VWAP con una curva pigra è un TWAP con passaggi in più.
• Opportunistico, nessuna deadline rigida, sensibile alla liquidità: POV a $\gamma$ modesto (≤15%), calcolato sul volume al netto di noi, con un filtro anti-cascata (limita la participation quando gli z-score del volume del tape esplodono) e un fallback di deadline il cui costo misuri separatamente.
• Qualunque cosa tu esegua: valutala sull'implementation shortfall contro arrival, alla Perold. Tieni lo slippage sul VWAP come diagnostica dell'abilità di scheduling, mai come tabellone — il tabellone deve essere denominato in denaro, e solo il prezzo di arrivo lo è.

E la meta-regola che l'esperimento continua a imporre: confronta distribuzioni, non medie, sui tuoi dati riprodotti. Uno scheduler è una scommessa su una previsione di volume, e non valuti le scommesse dal loro payout medio ignorando le code — è così che il mercato ti vende POV.