TWAP กับ VWAP กับ POV: การเลือก execution benchmark (และรู้ว่าเมื่อไหร่แต่ละตัวจะหลอกคุณ)
execution scheduler ทุกตัวคือการเดิมพันกับการพยากรณ์วอลุ่ม TWAP เดิมพันว่าสภาพคล่องจะราบเรียบตลอดเวลา VWAP เดิมพันว่าเส้นวอลุ่มของวันนี้จะหน้าตาเหมือนเมื่อวาน POV เดิมพันว่าวอลุ่มที่กำลังพิมพ์อยู่บนเทปตอนนี้เป็นเหตุผลที่ดีพอที่จะเทรดตอนนี้ — รวมถึงส่วนของเทปที่เป็นตัวคุณเองด้วย ไม่มีการเดิมพันไหนที่ถูกระบุว่าเป็น "การเดิมพัน" ในเอกสารของเวนเดอร์ นั่นคือเหตุผลที่การเปรียบเทียบทั้งสามตัวส่วนใหญ่อ่านเหมือนตารางฟีเจอร์: TWAP คือ "เรียบง่าย" VWAP คือ "ฉลาด" POV คือ "ปรับตัวได้" กรอบแบบนี้ไม่ได้บอกอะไรเลยว่าตัวไหนทำให้คุณเสียเงิน เมื่อไหร่ และเสียเท่าไหร่
นี่คือภาคที่ 2 ของซีรีส์ที่เราเริ่มไว้ใน Order Types in Algorithmic Trading ซึ่งเราสร้าง toy TWAP และ VWAP executor ด้วย Python ประมาณ 40 บรรทัดต่อตัว executor พวกนั้นใช้ได้ดีในฐานะโครงสร้างพื้นฐาน บทความนี้พูดถึงทุกอย่างที่โครงสร้างพื้นฐานนั้นซ่อนไว้: สมมติฐานโดยนัย การเมืองเรื่อง benchmark และการทดลองเปรียบเทียบแบบทำซ้ำได้บนข้อมูล order book ที่ replay ซึ่งแสดงให้เห็นว่าทั้งสามอัลกอริทึมไม่ใช่ "รสชาติที่ต่างกัน" — แต่เป็นโปรไฟล์ความเสี่ยงที่ต่างกัน ที่มีรูปแบบความล้มเหลวต่างกัน
Scheduler สามตัว การเดิมพันที่ซ่อนอยู่สามแบบ
กำหนดสัญกรณ์ให้ชัดเจน parent order ขนาด ต้องถูก execute ภายในช่วงเวลา แบ่งเป็น ช่วง ให้ เป็นปริมาณ child ในช่วง , เป็นวอลุ่มตลาดในช่วง และ เป็นราคาเฉลี่ยในช่วง VWAP ของตลาดตลอดช่วงเวลาคือ
TWAP เทรด : ปริมาณเท่ากันในเวลาที่เท่ากัน สมมติฐานโดยนัยคือสภาพคล่อง — ความลึก, สเปรด, วอลุ่ม — สม่ำเสมอตลอดเวลา ดังนั้นการแบ่งชิ้นเท่ากันจึงทำให้เกิด impact เท่ากัน สิ่งนี้เป็นเท็จในทุกตลาดที่เคยมีอยู่ แต่มันล้มเหลวอย่าง สง่างาม: ตารางเวลาเป็น deterministic การ complete รับประกันโดยโครงสร้าง และกรณีเลวร้ายที่สุดคือคุณเทรด clip ขนาดคงที่เข้าไปในชั่วโมงที่บาง แล้วจ่ายสเปรดที่กว้างขึ้น สมมติฐานที่สอง ที่พูดถึงน้อยกว่าคือ ไม่มีใครกำลังจับตาดู TWAP ที่ยิง child order ทุก 60 วินาทีที่วินาที :00 คือนาฬิกาเมโทรนอม และเมโทรนอมมักโดน front-run TWAP ที่ทำอย่างจริงจังจะสุ่ม timing และขนาดของ child order ตารางควรเป็นกระบวนการแบบ Poisson ที่ ค่าคาดหวัง ราบเรียบ ไม่ใช่นาฬิกาที่เดินตรงเวลา
VWAP เทรด โดยที่ คือสัดส่วน พยากรณ์ ของวอลุ่มรายวันในช่วง , ตอนนี้การเดิมพันชัดเจนแล้ว: คุณถือเส้นโค้ง ที่ประมาณจากประวัติศาสตร์ และสมมติว่าวันนี้จะเป็นไปตามนั้น สมมติฐานไม่ใช่ว่าวอลุ่มราบเรียบ แต่เป็นว่ามัน พยากรณ์ได้และเป็นปัจจัยภายนอก — เส้นโค้งไม่สนใจว่าคุณเทรดหรือไม่ เมื่อการพยากรณ์ดี VWAP จะรวมศูนย์การเทรดของคุณไว้ในจุดที่ตลาดดูดซับได้ และ slippage ของคุณเทียบกับ market VWAP จะเล็กเกือบจะโดยนิยาม เมื่อการพยากรณ์แย่ — เหตุการณ์ข่าวที่ไม่ได้กำหนดไว้ล่วงหน้าดันวอลุ่ม 40% ของวันเข้าไปในชั่วโมงที่เส้นโค้งของคุณกำหนดไว้แค่ 6% — VWAP ก็ยังคงเทรดตามตารางเก่าอย่างสงบ และคุณต้องรับผลต่างนั้นไป VWAP แปลงความเสี่ยงในการ execute ให้กลายเป็น ความเสี่ยงจากการพยากรณ์วอลุ่ม นั่นคือ trade-off ทั้งหมด และเป็นเหตุผลว่าทำไม engineering ที่น่าสนใจในเครื่องยนต์ VWAP คือตัวพยากรณ์ ไม่ใช่ตัวแบ่งชิ้น
POV (percentage of volume หรือเรียกอีกอย่างว่า "participation") ละทิ้งการพยากรณ์: เทรด ซึ่งเป็นสัดส่วนคงที่ ของวอลุ่มที่ สังเกตได้ ในแต่ละช่วง ดูเหมือนว่าวิธีนี้จะเหนือกว่า VWAP — จะพยากรณ์วอลุ่มไปทำไมในเมื่อคุณสามารถแค่ตามมันได้เลย? ปัญหาคือตอนนี้สัญญาณกลายเป็น ภายใน (endogenous) fill ของคุณเองก็พิมพ์อยู่บนเทปด้วย ถ้าส่วนที่เหลือของตลาดเทรด ในช่วงหนึ่ง และคุณตั้งเป้าสัดส่วน ของวอลุ่มเทปทั้งหมด ปริมาณของคุณต้องแก้สมการ นั่นคือ
ที่ การแก้ไขนั้นค่อนข้างน้อย (11.1% ของวอลุ่มคนอื่น) ที่ คุณกำลังเทรด 33% ของ flow คนอื่นทั้งหมด ที่ คุณจับคู่กับส่วนที่เหลือของตลาดทั้งหมดแบบหนึ่งต่อหนึ่ง และ fixed point ก็ diverge POV ยังทิ้งการรับประกันเดียวที่ทั้ง TWAP และ VWAP มีให้: ไม่มีเวลา complete ที่แน่นอน ถ้าวอลุ่มตาย ตารางของคุณก็ตายไปด้วย เราจะกลับมาที่พยาธิสภาพของ POV ด้านล่าง เพราะมันสมควรมีหัวข้อของตัวเอง
อีกกรอบหนึ่งที่จะสำคัญในภายหลัง: ไม่มีตัวไหนในสามตัวนี้ที่ "optimal" ในความหมายที่เป็นทางการ scheduler ที่ minimize objective ของ cost-risk จริงๆ คือตระกูล 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 เป็นกรณีพิเศษของ Almgren–Chriss ที่มี risk aversion เป็นศูนย์ภายใต้ linear impact; VWAP คือกลยุทธ์ minimum-tracking-error เทียบกับ benchmark ที่ถ่วงน้ำหนักด้วยวอลุ่ม (Konishi, 2002, "Optimal slice of a VWAP trade," Journal of Financial Markets 5(2)); POV คือ heuristic ที่ไม่สอดคล้องกับ objective function ใดๆ เลย ซึ่งนั่นคือเหตุผลที่รูปแบบความล้มเหลวของมันแปลกประหลาดขนาดนี้
การประมาณเส้นโค้งวอลุ่มเมื่อตลาดไม่เคยปิด
วงการวรรณกรรมด้าน equity มีเรื่องง่ายกว่า วอลุ่ม intraday ในตลาดหุ้นเป็นรูปตัว U — หนักตอนเปิด เงียบตอนพักเที่ยง หนักอีกครั้งช่วงใกล้ปิด — ซึ่งถูกบันทึกไว้ตั้งแต่ 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) รวมกลุ่มกันตามเวลาโดยธรรมชาติ รูปตัว U นี้ถูกยึดโยงด้วยเหตุการณ์ที่แน่นอนสองอย่าง คือ auction ตอนเปิดและตอนปิด ดังนั้นเส้นโค้งจึงเสถียร และค่าเฉลี่ยเคลื่อนที่ 20 วันของสัดส่วนวอลุ่มแต่ละช่วงก็พาคุณไปถึง 90% ของทางแล้ว
Crypto ไม่มีเวลาเปิดและไม่มีเวลาปิด ดังนั้นความคิดแบบไร้เดียงสาคือวอลุ่มควรจะราบเรียบและ TWAP ≈ VWAP ความคิดแบบไร้เดียงสานี้ผิด วอลุ่ม intraday ของ crypto มีโครงสร้าง — เพียงแต่ถูกยึดโยงกับนาฬิกาที่ต่างออกไป:
ผลจาก session วอลุ่มตามชั่วโมงตื่นของคนและ desk ที่เทรดมัน สำหรับคู่หลักอย่าง BTC และ ETH ช่วงที่หนักที่สุดคือช่วงบ่ายของสหรัฐฯ ที่ทับซ้อนกับช่วงเย็นของยุโรป (ประมาณ 13:00–21:00 UTC) พร้อมกับ shelf รองในช่วงเอเชียราว 00:00–08:00 UTC และมีร่องลึกชัดเจนราว 04:00–06:00 UTC ในคู่หลัก คู่ altcoin ที่มีเจ้าของกระจุกตัวตามภูมิภาคจะเอียงไปทาง session บ้านเกิดของตัวเองหนักกว่า
เวลา funding perpetual futures จ่าย funding ตามเวลา UTC ที่กำหนดตายตัว — ในอดีตทุก 8 ชั่วโมงที่ 00:00, 08:00, 16:00 UTC โดย Binance และเจ้าอื่นๆ ได้ย้าย contract จำนวนมากไปสู่รอบ settlement 4 ชั่วโมงและแม้กระทั่ง 1 ชั่วโมงตั้งแต่ปี 2025–2026 นาทีรอบๆ การ settlement มักพิมพ์วอลุ่มที่สูงขึ้นอย่างสม่ำเสมอ: basis trader เปิดและปิด carry position และใครก็ตามที่เล่นเกมกับ funding snapshot จะเทรดตรงเส้นขอบพอดี นี่คือ spike ไม่ใช่ shelf — เส้นโค้งที่มี bucket 30 นาทีจะมองเห็นมัน; เส้นโค้งที่มี bucket 2 ชั่วโมงจะเฉลี่ยมันจนหายไป และ VWAP ของคุณจะ under-participate ในตอนที่สภาพคล่องดีที่สุดพอดี
ฤดูกาลรายสัปดาห์ วอลุ่มวันหยุดสุดสัปดาห์ในคู่หลักอยู่ต่ำกว่าวอลุ่มวันธรรมดาโดยโครงสร้าง และคืนวันอาทิตย์ตามเวลา UTC (เช้าวันจันทร์ของเอเชีย บวกกับการเปิด CME อีกครั้งสำหรับ futures BTC) มีลายเซ็นของตัวเอง เส้นโค้ง time-of-day เดี่ยวที่รวมทุกวันเข้าด้วยกันคือการระบุที่ผิดพลาด คุณต้องการตาราง day-of-week × time-of-day
เหตุการณ์ตามกำหนดการ ออปชัน Deribit หมดอายุ 08:00 UTC (วันศุกร์ พร้อมกลุ่มรายไตรมาส) ตัวเลขเศรษฐกิจมหภาคของสหรัฐฯ ออกเวลา 12:30/14:00 UTC การ settlement ของ CME สำคัญต่อ basis flow นี่คือฟีเจอร์ตามปฏิทิน ไม่ใช่ฤดูกาล จัดการมันเป็น dummy ไม่ใช่ปล่อยให้มันปนเปื้อนเส้นโค้งพื้นฐาน
ตัวประมาณค่าที่ใช้งานได้จริง ในจิตวิญญาณของการรักษาความซื่อสัตย์ของตัวพยากรณ์ก่อนที่จะทำให้มันฉลาดขึ้น:
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
การใช้ median แทน mean ไม่ใช่ทางเลือกเชิงสไตล์ วอลุ่ม crypto มี tail ที่หนักมาก liquidation cascade เดียวอาจเป็น 15% ของวอลุ่มทั้งวันภายใน 10 นาที และเส้นโค้งที่ใช้ mean จะคาดหวัง spike ใน bucket นั้นไปตลอดกาล วรรณกรรมด้าน equity ไปไกลกว่าเส้นโค้งแบบ static: Białkowski, Darolles และ Le Fol (2008, "Improving VWAP strategies: A dynamic volume approach," Journal of Banking & Finance 32(9), 1709–1722) แยกวอลุ่มในแต่ละช่วงออกเป็นองค์ประกอบตลาดร่วม และองค์ประกอบเฉพาะหุ้นที่โมเดลด้วยพลวัต ARMA/SETAR และแสดงให้เห็นว่าการแยกส่วนนี้ลดความเสี่ยงในการ track VWAP ได้อย่างมีนัยสำคัญเทียบกับเส้นโค้งคลาสสิกแบบ static การแปลเป็นบริบท crypto ตรงไปตรงมา: ประมาณเส้นโค้งระดับตลาดจากคู่เทรด top-N (ปัจจัยร่วมแข็งแรง — นาฬิกา funding และ session ถูกใช้ร่วมกัน) แล้วโมเดลความเบี่ยงเบนของคู่เทรดคุณเป็นกระบวนการ intraday แบบ mean-reverting ที่อัปเดตแบบเรียลไทม์ เมื่อไม่นานมานี้ Genet (2025, "Deep Learning for VWAP Execution in Crypto Markets: Beyond the Volume Curve," arXiv:2502.13722) แสดงให้เห็นว่าตารางแบบ learned end-to-end เอาชนะ static-curve VWAP บนข้อมูล Binance ได้ — เป็นหลักฐานว่าใน crypto เส้นโค้งวอลุ่มคือจุดอ่อนที่สุดของ pipeline ไม่ใช่การแบ่งชิ้น
สรุปในเชิงปฏิบัติการ: เส้นโค้งแบบ static รวมทุกวันคือ VWAP แบบ หุ่นฟาง ถ้าการเปรียบเทียบของคุณแสดงว่า "VWAP แทบไม่ชนะ TWAP เลยใน crypto" ให้ตรวจสอบก่อนว่า VWAP นั้นได้รับเส้นโค้งที่มี funding spike และการแบ่งวันธรรมดา/วันหยุดสุดสัปดาห์อยู่จริงๆ ก่อนที่จะสรุปอะไร

พยาธิสภาพของ POV: อัลกอริทึมที่ไล่ตามหางของตัวเอง
จุดขายของ POV คือความสามารถในการปรับตัว: เทรดเมื่อตลาดเทรด พยาธิสภาพสามอย่างที่แตกต่างกันบั่นทอนมัน
1. วงจร feedback ความเป็นภายใน (endogeneity) ข้างต้นไม่ใช่แค่การแก้ไขทางบัญชี child order ของคุณสร้างวอลุ่ม; วอลุ่มเพิ่มเป้าหมายของคุณ; เป้าหมายของคุณสร้างวอลุ่ม ที่ ปานกลาง fixed point มีเสถียรภาพ แต่ participation ที่ วัดได้ ซึ่งรายงาน post-trade ของคุณแสดง ( ของเทปทั้งหมด) ประเมินรอยเท้าของคุณต่ำเกินไปเมื่อเทียบกับสิ่งที่ตลาดจะเป็นถ้าไม่มีคุณ ( ของทุกคนอื่น) ที่แย่กว่านั้น มี feedback ลำดับที่สองอยู่: fill ของคุณขยับราคา การขยับราคาดึงดูด momentum flow และกระตุ้น stop วอลุ่มนั้นเพิ่มวอลุ่มบนเทป และเครื่องยนต์ POV ของคุณอ่านวอลุ่มที่ ตัวมันเองก่อขึ้น ว่าเป็นคำเชิญให้เร่งความเร็ว นี่ตรงกันข้ามกับพฤติกรรมที่เหมาะสมโดยสิ้นเชิง scheduler ที่ตระหนักถึง impact (Almgren–Chriss ด้วยพารามิเตอร์ที่สมเหตุสมผล และการประมาณ impact เชิงประจักษ์อย่าง Almgren, Thum, Hauptmann and Li, 2005, "Direct Estimation of Equity Market Impact," Risk 18(7)) ต้องการให้คุณชะลอตัวลงหลังจากดันราคา ไม่ใช่เร่งความเร็ว liquidation cascade คือขีดจำกัดพยาธิสภาพ: วอลุ่มบนเทปมหาศาล book ด้านเดียว และ POV ธรรมดาจะซื้อหนักที่สุดเข้าไปในจุดสูงสุดของการบีบ เพราะนั่นคือจุดที่มี prints มากที่สุด
2. การถูกเล่นเกม อัลกอริทึม POV คือเครื่องจักร order flow ที่ถูกกระตุ้นด้วยวอลุ่ม และสิ่งใดก็ตามที่ถูกกระตุ้นได้ก็ล่อได้ นักล่าที่สงสัยว่ามีผู้ซื้อ participation ขนาดใหญ่สามารถพิมพ์วอลุ่ม — self-crossing ในที่ที่กฎอนุญาต หรือเพียงแค่เทรดอย่างขยันขันแข็งในขนาดเล็ก — เพื่อดึงเครื่องยนต์ POV ให้เดินหน้าเร็วขึ้น แล้วจึงจัดหาสภาพคล่องให้ในราคาที่บวกเพิ่ม นี่คือตัวอย่างขนาดเล็กของกลไกทั่วไปใน Brunnermeier and Pedersen (2005, "Predatory Trading," Journal of Finance 60(4)): เมื่อดีมานด์ในอนาคตของคุณพยากรณ์ได้จากพฤติกรรมในอดีตของคุณ คนอื่นจะเทรดล่วงหน้าก่อนมัน และเส้นทางราคาที่คุณเผชิญจะแย่กว่าที่คุณพยากรณ์ไว้ TWAP รั่วไหลตารางเวลาออกไปตามเวลา; POV รั่วไหล ฟังก์ชันตอบสนอง ซึ่งอันตรายกว่า เพราะฝ่ายตรงข้ามสามารถเรียกใช้มันได้ตามต้องการ
3. หางที่ไม่มีวันจบ POV ไม่มีนาฬิกา ถ้าคุณต้องซื้อ 500 BTC ภายใน 16:00 UTC และวอลุ่มระเหยไปที่ 14:00 POV แบบบริสุทธิ์จะนั่งรอ — มันถูกออกแบบมาให้ไม่สามารถ complete ได้ด้วยตัวเอง ด้วยเหตุนี้ POV ระดับ production ทุกตัวจึงมี min-rate floor และ catch-up mode และ catch-up mode คือจุดที่การขาดทุนซ่อนอยู่: คุณใช้เวลาทั้งวันเทรดแบบ passive ที่ participation 10% แล้วก็ยิงส่วนที่เหลือ 30% ของ parent ผ่านหน้าต่างปิดที่บางลงในอัตรา participation จริงที่สูงกว่าเป้าหมายถึงสามเท่า ค่าเฉลี่ย post-trade ดูดี แต่ ต้นทุนส่วนเพิ่ม ของชิ้นสุดท้ายนั้นโหดร้ายมาก ถ้ารายงาน POV ของคุณไม่แยกหางออกมาต่างหาก คุณยังไม่เห็นต้นทุนที่แท้จริงของมัน
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))
รายละเอียดสองอย่างในโค้ดนี้ทำหน้าที่จริง: เป้าหมายใช้ ของวอลุ่มเทป ex-us (คุณต้องหักลบ fill ของคุณเองออกจากเทปที่คุณตอบสนอง — implementation จำนวนน่าประหลาดใจไม่ทำแบบนี้) และ deadline floor เปลี่ยน POV ให้กลายเป็น TWAP-on-the-residual เมื่อเวลาใกล้หมด ซึ่งอย่างน้อยก็ทำให้ต้นทุนของหางพยากรณ์ได้

Benchmark: ทำไมการเอาชนะ VWAP ยังทำให้เสียเงินได้
scheduler และ benchmark เป็นทางเลือกที่แยกจากกัน และการปนกันสองสิ่งนี้คือบาปหลัง post-trade ที่พบบ่อยที่สุด benchmark สองตัวครองสนาม
VWAP benchmark — เปรียบเทียบราคา fill เฉลี่ยของคุณกับ interval VWAP — ถูกนำเสนอโดย Berkowitz, Logue and Noser (1988, "The Total Cost of Transactions on the NYSE," Journal of Finance 43(1)) ซึ่งเสนอราคาที่ถ่วงน้ำหนักด้วยวอลุ่มของวันเป็นไม้บรรทัดกลางสำหรับคุณภาพการ execute ของสถาบัน มันกลายเป็นค่าเริ่มต้นของอุตสาหกรรมด้วยเหตุผลทางสังคมวิทยาพอๆ กับเหตุผลทางเทคนิค: มันคำนวณง่าย อธิบายง่าย และยากที่จะดูแย่ถ้าคุณเพียงแค่กระจายการเทรดตลอดทั้งวัน
Implementation shortfall (arrival price) มาจาก Perold (1988, "The Implementation Shortfall: Paper Versus Reality," Journal of Portfolio Management 14(3), 4–9): วัดทุกอย่างเทียบกับราคา ณ ขณะที่ตัดสินใจ สำหรับการซื้อ ที่มีปริมาณ fill ที่ราคาเฉลี่ย ราคาสิ้นสุด :
ประเด็นของ Perold คือช่องว่างระหว่างพอร์ตกระดาษกับพอร์ตจริงคือปริมาณนี้เป๊ะๆ — และสังเกตว่ามันเรียกเก็บเงินจากคุณสำหรับสิ่งที่คุณ execute ไม่สำเร็จ ซึ่ง VWAP benchmark เพิกเฉยโดยเงียบๆ เทอม opportunity-cost นั้นคือสิ่งที่ทำให้ IS เป็น benchmark เดียวที่ซื่อสัตย์สำหรับ POV ซึ่งมีรูปแบบความล้มเหลวเป็นเอกลักษณ์คือปริมาณที่ไม่ถูก fill
ทีนี้มาถึงกับดัก VWAP ในฐานะ benchmark มีจุดบอดเชิงโครงสร้างสองอย่าง:
มันอ้างอิงตัวเอง fill ของคุณอยู่ ข้างใน benchmark ถ้าคุณคือ 30% ของวอลุ่มในช่วงนั้น แล้วประมาณ 30% ของ VWAP คือราคาเฉลี่ยของคุณเอง และ slippage ที่วัดได้ของคุณเทียบกับ VWAP จะถูกหดโดยกลไกจาก participation ของคุณเอง — ยิ่งออร์เดอร์ของคุณใหญ่และมี impact มากเท่าไหร่ มันก็ยิ่งได้คะแนนดีขึ้นเท่านั้น ในกรณีจำกัดที่คุณเป็นผู้เทรดคนเดียว คุณเอาชนะ VWAP ด้วยศูนย์พอดี ไม่ว่าคุณจะขยับราคาแย่แค่ไหนก็ตาม slippage ของ VWAP วัดการปฏิบัติตามตารางเวลา ไม่ใช่ต้นทุน
มันเพิกเฉยต่อ drift เทียบกับการตัดสินใจ ตัวเลขที่เป็นรูปธรรม: คุณตัดสินใจซื้อ 100 BTC ที่ราคาตัดสินใจ $60,000 ตลาดมีแนวโน้มขึ้นตลอดบ่าย interval VWAP พิมพ์ $60,320 และคุณ fill เฉลี่ยที่ $60,290 รายงาน VWAP: –5 bps ชนะ benchmark โต๊ะเทรดได้ช่องสีเขียว รายงาน arrival: คุณจ่ายเกิน $290 เหนือราคาตัดสินใจสำหรับ 100 BTC — +48 bps, $29,000 ของ implementation shortfall ตัวเลขทั้งสองถูกต้อง มีแค่ตัวเดียวเท่านั้นที่เป็นเงิน และการบิดเบือนแรงจูงใจยังลึกกว่านั้น: เทรดเดอร์ที่ถูกให้คะแนนด้วย VWAP ควร ชะลอตัวลง ในวันที่มีแนวโน้ม (การกระจายการเทรดจะ track benchmark ได้ดีกว่า) ซึ่งตรงกันข้ามกับสิ่งที่ minimize shortfall เมื่อราคากำลังวิ่งหนีจากคุณโดยสิ้นเชิง benchmark ไม่เพียงแค่วัดต้นทุนผิด — มันยังกำหนดพฤติกรรมที่ผิดด้วย Kissell (2013, The Science of Algorithmic Trading and Portfolio Management, Academic Press) พูดถึงปัญหาการเลือก benchmark นี้อย่างละเอียด กรอบของเขาคุ้มค่าที่จะซึมซับ: benchmark เข้ารหัสว่า คุณกำลังจัดการความเสี่ยงของใคร VWAP จัดการความเสี่ยงความอับอายของ desk ที่ execute Arrival price จัดการ P&L ของพอร์ต
การแก้ไขในเชิงปฏิบัติ: ให้คะแนนกลยุทธ์ด้วย implementation shortfall; ใช้ VWAP slippage เป็น เครื่องมือวินิจฉัย (มันแยกทักษะการจัดตารางออกจากโชคด้านจังหวะเวลา เพราะ drift ส่งผลต่อทั้งคุณและ benchmark); และอย่าให้ใครก็ตามที่ออร์เดอร์เกิน 10% ของวอลุ่มในช่วงนั้นอ้าง VWAP slippage โดยไม่พูดถึง participation ด้วย
การทดลอง: สามอัลกอริทึม เทปเดียว
เมื่อนิยามลงตัวแล้ว เราสามารถทำสิ่งที่บทความเปรียบเทียบไม่เคยทำ: รัน scheduler ทั้งสามตัวบน parent order เดียวกันทุกประการบนข้อมูลที่ replay ซ้ำ และดู การกระจายตัว ของต้นทุน ไม่ใช่คำคุณศัพท์ harness นี้รันบน event-driven fill simulator ที่อธิบายไว้ใน Fill simulation: partial fills, queue position and why your backtest fills are lies — L2 depth ที่ replay child limit order ได้ queue position, aggressive child เดินไปตาม book และ fill ของเรารบกวนเทปที่ scheduler สังเกต (ซึ่งสำคัญมากสำหรับ POV ตามหัวข้อ feedback ด้านบน)
การตั้งค่า เพื่อให้คุณทำซ้ำได้บนข้อมูลของคุณเอง:
- เครื่องมือ/ข้อมูล: BTCUSDT perpetual, replay L2 90 วัน (20 level บนสุด, 100 ms) + เทปการเทรด
- Parent order: 500 รายการต่ออัลกอริทึม เหมือนกันทุกประการข้ามอัลกอริทึม: เวลาเริ่มสุ่ม, horizon ชั่วโมง, ขนาด 0.75% ของ ADV 30 วันย้อนหลัง (ใหญ่พอที่ impact จะเป็นจริง เล็กพอที่ทั้งสามตัวจะ complete ได้อย่างสมเหตุสมผล), ฝั่งซื้อ, ราคาตัดสินใจ = mid ณ จุดเริ่มต้น
- TWAP: child slice 48 ชิ้น, jitter timing/ขนาด ±30%
- VWAP: เส้นโค้ง median day-of-week × time-of-day แบบ 30 นาที (ตัวประมาณด้านบน) refit รายสัปดาห์ ไม่มีการอัปเดตแบบ intraday — เจตนาให้เป็นเวอร์ชัน ธรรมดา
- POV: ของวอลุ่มเทป ex-us, min-rate floor, TWAP catch-up ใน 30 นาทีสุดท้าย
- Metric: IS เป็น bps ของราคาตัดสินใจ (รวมค่าธรรมเนียม), VWAP slippage เป็น bps, อัตรา completion และ — สิ่งที่ไม่มีใครรายงาน — IS ของควอไทล์สุดท้ายของแต่ละ parent
ผลลัพธ์ตัวแทนจากการรันของเรา (ตัวเลขของคุณจะต่างออกไป แต่ รูปทรง ไม่ควรต่าง):
| Metric (bps vs arrival) | TWAP | VWAP | POV 12% |
|---|---|---|---|
| Mean IS | 11.8 | 9.6 | 8.9 |
| Median IS | 9.1 | 7.7 | 6.4 |
| Std of IS | 21.5 | 19.8 | 26.3 |
| 95th percentile IS | 46 | 41 | 58 |
| Mean VWAP slippage | +1.9 | +0.4 | –0.8 |
| Completion at T | 100% | 100% | 96.4% |
| Mean IS, final quartile of parent | 12.5 | 10.2 | 19.7 |
การอ่านค่าสามแบบ เรียงตามความสำคัญที่เพิ่มขึ้น:
ค่าเฉลี่ยยกยอ POV แต่หางกล่าวโทษมัน POV ชนะทั้ง IS mean และ median — การปรับตัวตามสภาพคล่องที่เกิดขึ้นจริงคุ้มค่าจริงๆ สองสาม bps เหนือเส้นโค้งแบบ static แต่ standard deviation ของ IS และ percentile ที่ 95 ของมันแย่ที่สุดในสามตัว อัตรา completion ของมันไม่ถึง 100% และต้นทุนควอไทล์สุดท้ายของมันมากกว่าตัวเลขหลักสองเท่า: หางที่ไม่มีวันจบบวกกับ catch-up mode รวมศูนย์ต้นทุนไว้ตรงจุดที่ค่าเฉลี่ยซ่อนมันพอดี ถ้า parent order ของคุณขับเคลื่อนด้วย alpha และมี horizon ตายตัว หางนั้นคือตัวเลขที่สำคัญ และข้อได้เปรียบด้านค่าเฉลี่ยของ POV ไม่คุ้มที่จะจ่ายให้มัน
ความได้เปรียบของ VWAP เหนือ TWAP คือคุณภาพการพยากรณ์ของมันเป๊ะๆ เมื่อ condition ช่องว่าง IS ระหว่าง VWAP–TWAP กับ error ของเส้นโค้งวอลุ่มที่เกิดขึ้นจริง (ระยะทาง ระหว่างการพยากรณ์ กับสัดส่วนที่เกิดขึ้นจริง) ความสัมพันธ์เป็นแบบ monotone: ในเทอร์ไซล์ของวันที่พยากรณ์ดีที่สุด VWAP ชนะ TWAP ประมาณ 4 bps; ในเทอร์ไซล์ที่แย่ที่สุด ช่องว่างอยู่ในระดับ noise และบางครั้งกลับด้าน ใน crypto เทอร์ไซล์ที่แย่ที่สุดไม่ใช่แบบสุ่ม — มันคือวันที่มี cascade และวันที่มีข่าว ซึ่งก็เป็นวันที่มีต้นทุนสูงที่สุดโดยรวมด้วย VWAP ปรับปรุงค่าเฉลี่ยของคุณโดยการทำผลงานดีขึ้นในวันที่ง่ายอยู่แล้ว
VWAP slippage และ IS จัดอันดับอัลกอริทึมต่างกัน POV แสดง mean VWAP slippage เป็น ลบ — แน่นอนอยู่แล้ว มันเทรดตามสัดส่วนของวอลุ่มที่นิยาม benchmark นั้นเอง และ fill ของมันอยู่ข้างในนั้น ตาม scoreboard ของ VWAP POV คืออัลกอริทึมที่ดีที่สุดในที่นี้; ตาม scoreboard ของ arrival และความเสี่ยงด้าน completion มันคืออัลกอริทึมที่อันตรายที่สุด เทปเดียวกัน fill เดียวกัน ข้อสรุปตรงกันข้าม — ซึ่งคือข้อโต้แย้งทั้งหมดของหัวข้อก่อนหน้าที่ปรากฏในรูปแบบตาราง

ตัว harness เองมีประมาณ 50 บรรทัดรอบๆ fill simulator และคุ้มค่าทุกนาที เพราะมันเปลี่ยนการเลือก 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 ตายตัว, parent ขับเคลื่อนด้วย alpha: TWAP หรือตาราง Almgren–Chriss แบบ front-loaded จ่ายภาษีสภาพคล่องราบเรียบ; ซื้อการรับประกัน completion และหางที่มีขอบเขต สุ่ม child order
- flow ขับเคลื่อนด้วย benchmark (คุณถูกจ่ายเงินตาม VWAP จริงๆ) หรือขนาดใหญ่ในวันปกติ: VWAP — และใช้งบประมาณ engineering ของคุณไปกับตัวพยากรณ์วอลุ่ม: ตาราง day-of-week, การแก้ปัญหา funding-spike, การอัปเดตแบบ intraday dynamic ตามแนวทาง Białkowski–Darolles–Le Fol เครื่องยนต์ VWAP ที่มีเส้นโค้งขี้เกียจก็คือ TWAP ที่มีขั้นตอนเพิ่มเติมเท่านั้น
- แบบฉวยโอกาส, ไม่มี deadline ตายตัว, ไวต่อสภาพคล่อง: POV ที่ พอประมาณ (≤15%) คำนวณบนวอลุ่ม ex-us พร้อม cascade filter (จำกัด participation เมื่อ z-score ของวอลุ่มบนเทปพุ่งกระฉูด) และ deadline fallback ที่คุณวัดต้นทุน แยกต่างหาก
- ไม่ว่าคุณจะรันอะไร: ให้คะแนนมันด้วย implementation shortfall เทียบกับ arrival ตามแนวทางของ Perold เก็บ VWAP slippage ไว้เป็นเครื่องมือวินิจฉัยทักษะการจัดตารางเท่านั้น อย่าใช้มันเป็น scoreboard — scoreboard ต้องระบุหน่วยเป็นเงิน และมีแค่ arrival price เท่านั้นที่เป็นแบบนั้น
และกฎ meta ที่การทดลองนี้ยืนยันซ้ำแล้วซ้ำเล่า: เปรียบเทียบการกระจายตัว ไม่ใช่ค่าเฉลี่ย บนข้อมูลที่ replay ของคุณเอง scheduler คือการเดิมพันกับการพยากรณ์วอลุ่ม และคุณไม่ประเมินการเดิมพันด้วยผลตอบแทนเฉลี่ยของมันในขณะที่เพิกเฉยต่อหาง — นั่นคือวิธีที่ตลาดขาย POV ให้คุณ
ผู้เขียน
Trading-systems engineer
Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.