TWAP बनाम VWAP बनाम POV: एक execution benchmark चुनना (और यह जानना कि हर एक कब आपसे झूठ बोलता है)

हर execution scheduler एक volume forecast पर लगाया गया दांव है। TWAP दांव लगाता है कि liquidity समय में समतल है। VWAP दांव लगाता है कि आज का volume curve कल जैसा ही दिखेगा। POV दांव लगाता है कि tape पर अभी जो volume छप रहा है, वह अभी trade करने का एक अच्छा कारण है — जिसमें tape का वह हिस्सा भी शामिल है जो आप खुद हैं। इनमें से किसी भी दांव को vendor documentation में दांव के रूप में लेबल नहीं किया जाता, और इसीलिए तीनों की ज्यादातर तुलनाएं एक features table जैसी पढ़ी जाती हैं: TWAP "सरल" है, VWAP "स्मार्ट" है, POV "adaptive" है। यह framing आपको यह कुछ नहीं बताती कि कौन-सा आपका पैसा गंवाता है, कब, या कितना।

यह उस thread का भाग 2 है जिसे हमने Order Types in Algorithmic Trading में शुरू किया था, जहां हमने ~40 lines Python में toy TWAP और VWAP executors बनाए थे। वे executors plumbing के रूप में ठीक हैं। यह लेख उस हर चीज के बारे में है जो plumbing छिपा देती है: अंतर्निहित मान्यताएं, benchmark की राजनीति, और replayed order book data पर एक reproducible आमने-सामने का प्रयोग जो दिखाता है कि तीनों algorithms "अलग-अलग स्वाद" नहीं हैं — वे अलग-अलग failure modes वाले अलग-अलग risk profiles हैं।

तीन schedulers, तीन छिपे दांव

Notation तय कर लें। आकार $X$ का एक parent order horizon $[0, T]$ पर execute होना चाहिए, जिसे $N$ intervals में बांटा गया है। मान लें $x_i$ interval $i$ में child quantity है, $v_i$ interval $i$ में market volume है, और $p_i$ interval $i$ में औसत price है। horizon पर market VWAP है

TWAP $x_i = X/N$ trade करता है: बराबर समय में बराबर मात्राएं। अंतर्निहित मान्यता यह है कि liquidity — depth, spread, volume — समय में एकसमान है, इसलिए बराबर slices बराबर impact पैदा करते हैं। यह हर उस market में झूठ है जो कभी अस्तित्व में रही है, पर यह सुंदर तरीके से विफल होता है: schedule deterministic है, completion निर्माण से ही सुनिश्चित है, और सबसे खराब स्थिति यह है कि आप एक तय clip को किसी पतले घंटे में trade करते हैं और उसके लिए चौड़े spreads चुकाते हैं। दूसरी, कम चर्चित मान्यता यह है कि कोई देख नहीं रहा। एक TWAP जो हर 60 seconds पर :00 बजे एक child order फायर करता है, एक metronome है, और metronome front-run हो जाते हैं। कोई भी गंभीर TWAP child timing और size को randomize करता है; schedule एक Poisson-जैसी प्रक्रिया होनी चाहिए जिसकी अपेक्षा समतल हो, न कि एक घड़ी।

VWAP $x_i = X \cdot u_i$ trade करता है, जहां $u_i$ interval $i$ में दैनिक volume का forecast अंश है, $\sum_i u_i = 1$। अब दांव स्पष्ट है: आपके पास इतिहास से अनुमानित एक curve $\{u_i\}$ है, और आप मान लेते हैं कि आज उसी का अनुसरण करता है। मान्यता यह नहीं है कि volume समतल है, बल्कि यह कि वह predictable और exogenous है — curve को इससे मतलब नहीं कि आप trade करते हैं या नहीं। जब forecast अच्छा होता है, VWAP आपके trading को वहां केंद्रित करता है जहां market उसे सोख सके और market VWAP के मुकाबले आपकी slippage लगभग स्वयंसिद्ध रूप से छोटी होती है। जब forecast खराब होता है — कोई अनिर्धारित news event दिन के 40% volume को उस घंटे में ले जाता है जिसे आपके curve ने 6% दिया था — VWAP शांति से stale schedule को trade करता रहता है और आप अंतर भुगतते हैं। VWAP execution risk को volume-forecast risk में बदल देता है। यही पूरा trade-off है, और इसीलिए एक VWAP engine में दिलचस्प engineering forecaster है, slicer नहीं।

POV (percentage of volume, जिसे "participation" भी कहते हैं) forecast को त्याग देता है: $x_t = \gamma \cdot V_t$ trade करो, हर interval में observed volume का एक तय अंश $\gamma$। यह ऐसा दिखता है मानो यह VWAP पर हावी हो जाता है — जब आप बस volume का अनुसरण कर सकते हैं तो उसका forecast क्यों करें? पेच यह है कि signal अब endogenous है। आपके अपने fills tape पर छपते हैं। अगर बाकी market एक interval में $M$ trade करती है और आप कुल tape volume के अंश $\gamma$ को target करते हैं, तो आपकी quantity $x = \gamma(M + x)$ को हल करती है, यानी

$\gamma = 0.10$ पर वह correction हल्का है (दूसरों के volume का 11.1%)। $\gamma = 0.25$ पर आप बाकी सबके flow का 33% trade कर रहे हैं; $\gamma = 0.5$ पर आप बाकी पूरी market के बराबर एक-के-बदले-एक trade करते हैं और fixed point diverge कर जाता है। POV वह एक guarantee भी गिरा देता है जो TWAP और VWAP दोनों देते हैं: कोई completion time नहीं है। अगर volume मर जाए, तो आपका schedule भी मर जाता है। हम POV की विकृतियों पर नीचे लौटेंगे, क्योंकि वे अपने खुद के section के हकदार हैं।

एक और framing जो आगे मायने रखेगी: इनमें से कोई भी तीन किसी औपचारिक अर्थ में "optimal" नहीं है। वह scheduler जो वास्तव में एक cost-risk objective को minimize करता है, वह Almgren–Chriss परिवार है (Almgren and Chriss, 2000, "Optimal Execution of Portfolio Transactions," Journal of Risk 3, 5–39), जिसे हम Almgren–Chriss and the theory of optimal execution schedules में ठीक से देखते हैं। TWAP, linear impact के तहत शून्य risk aversion वाले Almgren–Chriss का विशेष मामला है; VWAP एक volume-weighted benchmark के मुकाबले minimum-tracking-error रणनीति है (Konishi, 2002, "Optimal slice of a VWAP trade," Journal of Financial Markets 5(2)); POV एक heuristic है जो किसी भी objective function से मेल नहीं खाता, और ठीक इसीलिए इसके failure modes इतने विचित्र हैं।

volume curves का अनुमान लगाना जब market कभी बंद ही नहीं होती

Equity literature के पास यह आसान था। equities में intraday volume एक U-आकार है — open पर भारी, lunch पर शांत, close की ओर भारी — जिसे Jain and Joh (1988, "The Dependence between Hourly Prices and Trading Volume," JFQA 23(3)) के बाद से दस्तावेजित किया गया है और Admati and Pfleiderer (1988, "A Theory of Intraday Patterns: Volume and Price Variability," Review of Financial Studies 1(1)) द्वारा सैद्धांतिक आधार दिया गया है, जिन्होंने दिखाया कि discretionary liquidity traders और informed traders समय में endogenously समूहबद्ध हो जाते हैं। U-आकार दो कठोर घटनाओं, opening और closing auctions, से लंगर डाले हुए है, इसलिए curve स्थिर है और interval volume shares का 20-दिन का rolling average आपको 90% रास्ता तय करा देता है।

Crypto में कोई open नहीं और कोई close नहीं, इसलिए भोली धारणा यह है कि volume समतल होना चाहिए और TWAP ≈ VWAP। भोली धारणा गलत है। Crypto intraday volume में संरचना है — बस वह अलग घड़ियों से लंगर डाले हुए है:

Session effects. Volume उन लोगों और desks के जागने के घंटों को track करता है जो इसे trade करते हैं। BTC और ETH majors पर, सबसे भारी band यूरोपीय शाम के साथ overlap होती US दोपहर है (मोटे तौर पर 13:00–21:00 UTC), 00:00–08:00 UTC के आसपास एक द्वितीयक Asia shelf और majors पर 04:00–06:00 UTC के आसपास एक स्पष्ट गर्त के साथ। केंद्रित क्षेत्रीय स्वामित्व वाले Alt pairs अपने home session की ओर ज्यादा झुकते हैं।

Funding timestamps. Perpetual futures तय UTC समयों पर funding settle करते हैं — ऐतिहासिक रूप से हर 8 घंटे में 00:00, 08:00, 16:00 UTC पर, जिसमें Binance और अन्य 2025–2026 से कई contracts को 4-घंटे और यहां तक कि 1-घंटे के settlement cycles पर ले जा रहे हैं। settlement के आसपास के मिनट भरोसेमंद रूप से बढ़ा हुआ volume छापते हैं: basis traders carry positions खोलते और बंद करते हैं, और funding snapshot को game करने वाला कोई भी ठीक सीमा पर trade करता है। ये spikes हैं, shelves नहीं — 30-मिनट के buckets वाला curve इन्हें देखता है; 2-घंटे के buckets वाला curve इन्हें औसत में खपा देता है और आपका VWAP ठीक तब under-participate करता है जब liquidity सबसे अच्छी होती है।

Weekly seasonality. Majors पर weekend volume संरचनात्मक रूप से weekday volume से नीचे चलता है, और रविवार शाम UTC (Monday सुबह Asia, साथ ही BTC futures के लिए CME reopen) की अपनी अलग पहचान है। सभी दिनों में मिलाकर बनाया गया एकल time-of-day curve गलत तरह से specify किया गया है; आपको एक day-of-week × time-of-day grid चाहिए।

Scheduled events. Deribit options 08:00 UTC (शुक्रवार, तिमाही clusters के साथ) पर expire होते हैं, US macro prints 12:30/14:00 UTC पर आते हैं, CME settlements basis flows के लिए मायने रखते हैं। ये calendar features हैं, seasonality नहीं — इन्हें dummies के रूप में संभालें, न कि baseline curve को प्रदूषित करके।

एक काम करने लायक estimator, forecaster को चतुर बनाने से पहले उसे ईमानदार रखने की भावना में:

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

Mean के बजाय median कोई शैलीगत विकल्प नहीं है। Crypto volume अत्यधिक heavy-tailed है; एक अकेला liquidation cascade 10 मिनट में एक दिन के volume का 15% हो सकता है, और एक mean-आधारित curve उसके बाद हमेशा उस bucket में एक spike की अपेक्षा करेगा। Equity literature static curves से आगे गई: Białkowski, Darolles and Le Fol (2008, "Improving VWAP strategies: A dynamic volume approach," Journal of Banking & Finance 32(9), 1709–1722) interval volume को एक common market component और ARMA/SETAR dynamics से model किए गए एक stock-specific component में विघटित करते हैं, और दिखाते हैं कि यह विघटन एक static classical curve की तुलना में VWAP tracking risk को काफी घटा देता है। Crypto में इसका अनुवाद सीधा है: top-N pairs से एक market-wide curve का अनुमान लगाएं (common factor मजबूत है — funding clocks और sessions साझा हैं), फिर अपने pair के विचलन को एक mean-reverting intraday process के रूप में model करें जिसे आप real time में update करते हैं। हाल ही में, Genet (2025, "Deep Learning for VWAP Execution in Crypto Markets: Beyond the Volume Curve," arXiv:2502.13722) दिखाता है कि सीखे गए end-to-end schedules Binance data पर static-curve VWAP को हरा देते हैं — इसका प्रमाण कि crypto में volume curve pipeline की सबसे कमजोर कड़ी है, slicing नहीं।

व्यावहारिक सार: एक static all-days curve एक strawman VWAP है। अगर आपकी तुलना दिखाती है कि "crypto में VWAP मुश्किल से TWAP को हराता है," तो कुछ भी निष्कर्ष निकालने से पहले जांचें कि क्या VWAP को दिया गया curve वास्तव में funding spikes और weekday/weekend विभाजन रखता है।

POV की विकृतियां: वह algorithm जो अपनी ही पूंछ का पीछा करता है

POV की खासियत adaptivity है: trade तब करो जब market trade करती है। तीन अलग-अलग विकृतियां इसे कमजोर करती हैं।

1. Feedback loop. ऊपर बताई गई endogeneity केवल एक bookkeeping correction नहीं है। आपके child orders volume पैदा करते हैं; volume आपका target बढ़ाता है; आपका target volume पैदा करता है। मध्यम $\gamma$ पर fixed point $x = \frac{\gamma}{1-\gamma}M$ स्थिर है, पर आपकी post-trade report में जो मापी गई participation दिखती है (कुल tape का $\gamma$) वह आपके footprint को उस स्थिति के मुकाबले कम आंकती है जो आपके बिना market रही होती (बाकी सबका $\frac{\gamma}{1-\gamma}$)। इससे भी बुरा, second-order feedback मौजूद है: आपके fills price हिलाते हैं, price की गति momentum flow को खींचती है और stops को trigger करती है, वह flow tape volume बढ़ाता है, और आपका POV engine उस volume को जो उसने खुद पैदा किया तेज होने का न्योता समझ लेता है। यह optimal व्यवहार से ठीक उल्टा है — impact-aware schedulers (उचित parameters वाले Almgren–Chriss, और Almgren, Thum, Hauptmann and Li, 2005, "Direct Estimation of Equity Market Impact," Risk 18(7) जैसे empirical impact estimates) चाहते हैं कि आप price धकेलने के बाद धीमे हों, तेज नहीं। एक liquidation cascade इसकी विकृत सीमा है: विशाल tape volume, एकतरफा book, और एक vanilla POV squeeze के शिखर में सबसे जोर से खरीदता है क्योंकि वहीं prints होते हैं।

2. Gamed होना. एक POV algo एक volume-triggered order flow machine है, और जो कुछ भी triggered है वह baitable है। एक predator जो किसी बड़े participation buyer का शक करता है, वह volume छाप सकता है — जहां नियम अनुमति देते हैं वहां self-crossing करके, या बस छोटे size में सक्रिय रूप से trade करके — ताकि POV engine को आगे खींचा जाए, फिर उसे बढ़ी हुई कीमतों पर liquidity मुहैया कराई जाए। यह Brunnermeier and Pedersen (2005, "Predatory Trading," Journal of Finance 60(4)) में बताए गए सामान्य तंत्र का एक छोटे पैमाने का उदाहरण है: जब आपकी भविष्य की demand आपके पिछले व्यवहार से predictable हो, तो दूसरे उसके आगे trade करते हैं और जो price path आप झेलते हैं वह आपके forecast से भी बुरा होता है। TWAP समय में एक schedule leak करता है; POV एक response function leak करता है, जो ज्यादा खतरनाक है क्योंकि विरोधी उसे मांग पर बुला सकता है।

3. कभी न खत्म होने वाली पूंछ. POV के पास कोई घड़ी नहीं है। अगर आपको 16:00 UTC तक 500 BTC खरीदने हैं और volume 14:00 पर सूख जाता है, तो एक शुद्ध POV बैठकर इंतजार करता है — यह डिजाइन से ही अपने आप खत्म होने में असमर्थ है। इसलिए हर production POV एक min-rate floor और एक catch-up mode रखता है, और catch-up mode ही वह जगह है जहां नुकसान छिपे होते हैं: आप दिन भर 10% participation पर passively trade करते हैं, फिर parent का बचा हुआ 30% एक पतली closing window में आपके target से तीन गुना effective participation पर उछाल देते हैं। post-trade average ठीक दिखता है; आखिरी tranche की marginal लागत क्रूर होती है। अगर आपकी POV reports पूंछ को अलग से नहीं दिखातीं, तो आपने इसकी असली लागत नहीं देखी।

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

इस snippet में दो विवरण असली काम करते हैं: target ex-us tape volume का $\frac{\gamma}{1-\gamma}$ उपयोग करता है (जिस tape पर आप react करते हैं उससे आपको अपने खुद के fills घटाने होंगे — हैरानी की बात कि कई implementations ऐसा नहीं करतीं), और deadline floor समय खत्म होते ही POV को TWAP-on-the-residual में बदल देता है, जो कम से कम पूंछ की लागत को predictable बना देता है।

Benchmarks: VWAP को हराना फिर भी पैसा क्यों गंवा सकता है

Scheduler और benchmark अलग-अलग विकल्प हैं, और इन्हें गड्डमड्ड करना सबसे आम post-trade पाप है। दो benchmarks हावी रहते हैं।

VWAP benchmark — अपने औसत fill price की interval VWAP से तुलना करें — को Berkowitz, Logue and Noser (1988, "The Total Cost of Transactions on the NYSE," Journal of Finance 43(1)) ने पेश किया, जिन्होंने institutional execution quality के लिए एक तटस्थ मापदंड के रूप में दिन के volume-weighted price का प्रस्ताव रखा। यह उतने ही सामाजिक कारण से industry default बना जितना तकनीकी: इसे compute करना आसान है, समझाना आसान है, और अगर आप बस अपने trading को दिन भर फैला दें तो इसके सामने बुरा दिखना कठिन है।

Implementation shortfall (arrival price) Perold (1988, "The Implementation Shortfall: Paper Versus Reality," Journal of Portfolio Management 14(3), 4–9) से आता है: हर चीज को उस price $p_0$ के मुकाबले मापें जो निर्णय लिए जाने के क्षण था। $X$ की एक खरीद के लिए, जिसमें औसत price $\bar{p}$ पर filled quantity $X_f$ हो, terminal price $p_T$:

Perold की बात यह थी कि paper portfolios और असली portfolios के बीच की खाई ठीक यही मात्रा है — और ध्यान दें कि यह आपको उसके लिए charge करती है जिसे आप execute करने में विफल रहे, जिसे VWAP benchmark चुपचाप अनदेखा कर देता है। वह opportunity-cost term ही IS को POV के लिए एकमात्र ईमानदार benchmark बनाता है, जिसका खास failure mode unfilled quantity है।

अब जाल। एक benchmark के रूप में VWAP के दो संरचनात्मक अंधे धब्बे हैं:

यह self-referential है. आपके fills benchmark के भीतर हैं। अगर आप interval volume के 30% हैं, तो मोटे तौर पर VWAP का 30% आपका खुद का औसत price है, और VWAP के मुकाबले आपकी मापी गई slippage आपकी अपनी participation से यंत्रवत सिकुड़ जाती है — आपका order जितना बड़ा और जितना impactful होगा, स्कोर उतना ही बेहतर आएगा। उस सीमा में जहां आप ही एकमात्र trader हैं, आप VWAP को ठीक शून्य से हराते हैं चाहे आपने price को कितना ही बुरी तरह हिलाया हो। VWAP slippage schedule का पालन मापती है, लागत नहीं।

यह निर्णय के सापेक्ष drift को अनदेखा करती है. ठोस संख्याएं: आप $60,000 के decision price पर 100 BTC खरीदने का निर्णय लेते हैं। market पूरी दोपहर ऊपर की ओर बढ़ती है; interval VWAP $60,320 छापता है और आप औसत $60,290 पर fill होते हैं। VWAP report: –5 bps, benchmark को हराया, desk को एक हरा cell मिलता है। Arrival report: आपने 100 BTC पर decision price से $290 ऊपर चुकाया — +48 bps, $29,000 का implementation shortfall। दोनों संख्याएं सही हैं। इनमें से केवल एक पैसा है। और incentive का भ्रष्टाचार और गहरा जाता है: VWAP पर आंका गया एक trader एक trending दिन पर धीमा हो जाए (trades फैलाना benchmark को बेहतर track करता है), जो ठीक उसके विपरीत है जो shortfall को minimize करता है जब price आपसे दूर भाग रही हो। Benchmark केवल लागत को गलत नहीं मापती — यह गलत व्यवहार का नुस्खा भी देती है। Kissell (2013, The Science of Algorithmic Trading and Portfolio Management, Academic Press) इस benchmark-selection समस्या को विस्तार से देखता है; उसकी framing आत्मसात करने लायक है: benchmark encode करती है कि आप किसका risk manage कर रहे हैं। VWAP execution desk के शर्मिंदगी वाले risk को manage करता है। Arrival price portfolio के P&L को manage करता है।

व्यावहारिक समाधान: रणनीतियों को implementation shortfall पर आंकें; VWAP slippage को एक diagnostic के रूप में उपयोग करें (यह scheduling की कुशलता को timing के भाग्य से अलग करती है, क्योंकि drift आप और benchmark दोनों को प्रभावित करता है); और कभी भी किसी ऐसे व्यक्ति को, जिसका order interval volume के >10% था, participation बताए बिना VWAP slippage quote न करने दें।

प्रयोग: तीन algorithms, एक tape

परिभाषाएं तय हो गईं, अब हम वह कर सकते हैं जो तुलना वाले लेख कभी नहीं करते: तीनों schedulers को समान parent orders पर उसी replayed data पर चलाएं और विशेषणों के बजाय cost distributions को देखें। यह harness उस event-driven fill simulator पर चलता है जिसका वर्णन Fill simulation: partial fills, queue position and why your backtest fills are lies में है — replayed L2 depth, child limit orders queue position कमाते हैं, aggressive children book को walk करते हैं, और हमारे fills उस tape को विचलित करते हैं जिसे schedulers देखते हैं (जो POV के लिए बेहद मायने रखता है, feedback section के अनुसार)।

Setup, ताकि आप इसे अपने खुद के data पर reproduce कर सकें:

• Instrument/data: BTCUSDT perpetual, 90 दिन का L2 replay (top 20 levels, 100 ms) + trades tape।
• Parent orders: प्रति algorithm 500, algorithms में समान: random start times, horizon $T = 4$h, size trailing 30-day ADV का 0.75% (इतना बड़ा कि impact असली हो, इतना छोटा कि तीनों प्रशंसनीय रूप से खत्म कर सकें), buy side, decision price = शुरुआत पर mid।
• TWAP: 48 child slices, ±30% timing/size jitter।
• VWAP: 30-min day-of-week × time-of-day median curve (ऊपर वाला estimator), साप्ताहिक refit, कोई intraday updating नहीं — जानबूझकर सरल संस्करण।
• POV: ex-us tape volume का $\gamma = 12\%$, min-rate floor, आखिरी 30 min में TWAP catch-up।
• Metrics: decision price के bps में IS (fees सहित), bps में VWAP slippage, completion rate, और — वह जो कोई नहीं बताता — हर parent के अंतिम quartile का IS।

हमारे runs से प्रतिनिधि परिणाम (आपकी संख्याएं भिन्न होंगी; आकार नहीं होना चाहिए):

तीन पाठ, बढ़ते महत्व के क्रम में:

Means POV की चापलूसी करते हैं और tails उसे दोषी ठहराते हैं. POV mean और median IS पर जीतता है — realized liquidity के अनुकूल होना एक static curve के मुकाबले सचमुच कुछ bps लायक है। पर इसका IS standard deviation और 95th percentile तीनों में सबसे खराब हैं, इसका completion rate 100% नहीं है, और इसकी final-quartile लागत इसके headline से दोगुनी से भी अधिक है: कभी न खत्म होने वाली पूंछ और catch-up mode लागत को ठीक वहां केंद्रित करते हैं जहां averages उसे छिपाते हैं। अगर आपके parent orders alpha-driven हैं और एक कठोर horizon के साथ हैं, तो वह पूंछ ही वह संख्या है जो मायने रखती है, और POV का mean लाभ उसकी कीमत नहीं चुकाता।

TWAP पर VWAP की बढ़त ठीक उसकी forecast quality है. VWAP–TWAP IS gap को realized volume-curve error ($L_1$ distance forecast $u_i$ और realized shares के बीच) पर condition करें और संबंध monotone है: दिनों के best-forecast tercile पर VWAP TWAP को ~4 bps से हराता है; worst tercile पर gap noise के भीतर है और कभी-कभी उल्टा हो जाता है। Crypto में, worst tercile random नहीं है — वे cascade days और news days हैं, जो कुल मिलाकर सबसे अधिक लागत वाले दिन भी हैं। VWAP आपके औसत को उन दिनों पर बेहतर प्रदर्शन करके सुधारता है जो वैसे भी आसान थे।

VWAP slippage और IS algorithms को अलग-अलग रैंक करते हैं. POV ऋणात्मक mean VWAP slippage दर्ज करता है — बेशक करता है, यह ठीक उसी volume के अनुपात में trade करता है जो benchmark को परिभाषित करता है, और इसके fills उसके भीतर बैठते हैं। VWAP scoreboard के हिसाब से, POV यहां सबसे अच्छा algorithm है; arrival scoreboard और completion risk के हिसाब से, यह सबसे खतरनाक है। वही tape, वही fills, विपरीत निष्कर्ष — जो पिछले section की पूरी दलील को एक table के रूप में प्रस्तुत करता है।

Harness स्वयं fill simulator के इर्द-गिर्द ~50 lines है और हर मिनट के लायक है, क्योंकि यह scheduler के चयन को एक स्वाद की बहस से एक माप में बदल देता है:

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)

व्यवहार में चुनाव

इस सबसे निकलने वाले ईमानदार चयन नियम:

• कठोर deadline, alpha-driven parent: TWAP या एक front-loaded Almgren–Chriss schedule। flat-liquidity कर चुकाएं; completion guarantee और bounded tail खरीदें। children को randomize करें।
• Benchmark-driven flow (आपको सचमुच VWAP पर भुगतान मिलता है), या एक सामान्य दिन पर बड़ा size: VWAP — और अपना engineering बजट volume forecaster पर खर्च करें: day-of-week grid, funding-spike resolution, Białkowski–Darolles–Le Fol की शैली में intraday dynamic updating। एक आलसी curve वाला VWAP engine अतिरिक्त कदमों वाला TWAP है।
• Opportunistic, कोई कठोर deadline नहीं, liquidity-sensitive: मामूली $\gamma$ (≤15%) पर POV, ex-us volume पर गणना किया गया, एक cascade filter के साथ (जब tape volume z-scores फट पड़ें तो participation cap करें) और एक deadline fallback जिसकी लागत आप अलग से मापें।
• आप जो भी चलाएं: उसे Perold के अनुसार arrival के मुकाबले implementation shortfall पर आंकें। VWAP slippage को scheduling कुशलता के एक diagnostic के रूप में रखें, कभी scoreboard के रूप में नहीं — scoreboard को पैसे में denominate होना चाहिए, और केवल arrival price ही ऐसा है।

और वह meta-rule जिसे प्रयोग बार-बार लागू करता रहता है: अपने खुद के replayed data पर means नहीं, distributions की तुलना करें। एक scheduler एक volume forecast पर लगाया गया दांव है, और आप दांवों का मूल्यांकन उनके औसत payout से करते हुए tails को अनदेखा करके नहीं करते — यही तरीका है जिससे market आपको POV बेचती है।