← Makalelere geri dön
July 15, 2026
5 dakikalık okuma

TWAP mu VWAP mi POV mu: bir execution benchmark seçmek (ve her birinin ne zaman size yalan söylediğini bilmek)

TWAP mu VWAP mi POV mu: bir execution benchmark seçmek (ve her birinin ne zaman size yalan söylediğini bilmek)
#execution
#twap
#vwap
#pov
#implementation-shortfall
#hacim-egrisi
#algotrading
#backtest

Her execution scheduler'ı bir hacim tahminine yapılan bahistir. TWAP, likiditenin zaman içinde düz olduğuna bahse girer. VWAP, bugünün hacim eğrisinin dünkü gibi görüneceğine bahse girer. POV ise şu an tape üzerinde basılan hacmin şu an trade yapmak için iyi bir neden olduğuna bahse girer — bu hacmin sizin oluşturduğunuz kısmı da dahil. Bu bahislerin hiçbiri satıcı dokümantasyonunda "bahis" olarak etiketlenmez, bu yüzden üçünün çoğu karşılaştırması bir özellik tablosu gibi okunur: TWAP "basit", VWAP "akıllı", POV "uyarlanabilir". Bu çerçeveleme size hangisinin sizi ne zaman ve ne kadar paraya mal ettiği hakkında hiçbir şey söylemez.

Bu, Algoritmik Ticarette Emir Türleri yazısında başlattığımız serinin 2. bölümü; orada her biri ~40 satır Python ile oyuncak TWAP ve VWAP execution motorları inşa etmiştik. Bu executor'lar altyapı olarak gayet iyidir. Bu yazı ise altyapının gizlediği her şey hakkında: örtük varsayımlar, benchmark politikası ve üç algoritmanın "farklı lezzetler" değil, farklı başarısızlık modlarına sahip farklı risk profilleri olduğunu gösteren, yeniden oynatılmış emir defteri verisi üzerinde tekrarlanabilir bir kafa kafaya deney.

Üç scheduler, üç gizli bahis

Notasyonu sabitleyelim. XX büyüklüğündeki bir parent emir, [0,T][0, T] ufkunda çalıştırılmalı ve NN aralığa bölünmelidir. xix_i, ii aralığındaki child miktarı; viv_i, ii aralığındaki piyasa hacmi; pip_i ise ii aralığındaki ortalama fiyat olsun. Ufuk boyunca piyasa VWAP'ı şudur:

VWAP=ipiviivi.\mathrm{VWAP} = \frac{\sum_i p_i v_i}{\sum_i v_i}.

TWAP xi=X/Nx_i = X/N kadar trade eder: eşit zamanda eşit miktarlar. Örtük varsayım, likiditenin — derinlik, spread, hacim — zaman içinde tek biçimli olduğu, dolayısıyla eşit dilimlerin eşit etki yarattığıdır. Bu, var olmuş her piyasada yanlıştır, ama zarif bir şekilde başarısız olur: schedule deterministiktir, tamamlanma yapı gereği garantidir ve en kötü durum, sabit bir miktarı sığ bir saate trade edip bunun için daha geniş spread ödemektir. İkinci, daha az tartışılan varsayım ise kimsenin izlemediğidir. Her dakika :00'da bir child emir ateşleyen bir TWAP bir metronomdur ve metronomlar önden koşuya (front-run) uğrar. Ciddi her TWAP, child zamanlamasını ve büyüklüğünü rastgeleleştirir; schedule, beklentisi düz olan ama saat gibi olmayan Poisson benzeri bir süreç olmalıdır.

VWAP xi=Xuix_i = X \cdot u_i kadar trade eder; burada uiu_i, ii aralığındaki günlük hacmin tahmin edilen payıdır, iui=1\sum_i u_i = 1. Bahis artık açıktır: geçmişten tahmin edilen bir eğriye {ui}\{u_i\} sahipsiniz ve bugünün onu takip edeceğini varsayıyorsunuz. Varsayım hacmin düz olduğu değil, tahmin edilebilir ve dışsal olduğudur — eğri sizin trade yapıp yapmadığınızı umursamaz. Tahmin iyi olduğunda, VWAP trade'inizi piyasanın absorbe edebileceği yerlere yoğunlaştırır ve piyasa VWAP'ına göre slippage'iniz neredeyse totolojik olarak küçük olur. Tahmin kötü olduğunda — planlanmamış bir haber olayı günün hacminin %40'ını eğrinizin %6 atadığı bir saate taşıdığında — VWAP eski schedule'ı sakin sakin trade etmeye devam eder ve farkı siz ödersiniz. VWAP, execution riskini hacim tahmini riskine dönüştürür. Bu bütün değiş tokuştur ve bir VWAP motorundaki ilginç mühendislik dilimleyici değil, tahminleyicidir.

POV (percentage of volume, yani "katılım") tahminden vazgeçer: her aralıkta gözlemlenen hacmin sabit bir payı γ\gamma olarak xt=γVtx_t = \gamma \cdot V_t trade eder. Bu, VWAP'a baskın geliyor gibi görünür — hacmi sadece takip edebiliyorken neden tahmin edesiniz? Sorun şu ki sinyal artık içseldir. Kendi fill'leriniz tape üzerinde basılır. Piyasanın geri kalanı bir aralıkta MM trade ediyorsa ve toplam tape hacminin γ\gamma payını hedefliyorsanız, miktarınız şu denklemi çözer: x=γ(M+x)x = \gamma(M + x), yani

x=γ1γM.x = \frac{\gamma}{1-\gamma}\,M.

γ=0,10\gamma = 0{,}10'da bu düzeltme hafiftir (başkalarının hacminin %11,1'i). γ=0,25\gamma = 0{,}25'te başkalarının tüm akışının %33'ünü trade ediyorsunuzdur; γ=0,5\gamma = 0{,}5'te piyasanın geri kalanının tamamına birebir eşleşirsiniz ve sabit nokta ıraksar. POV ayrıca hem TWAP'ın hem de VWAP'ın sunduğu tek garantiden vazgeçer: tamamlanma zamanı yoktur. Hacim ölürse, schedule'ınız da ölür. POV'un patolojilerine aşağıda döneceğiz, çünkü kendi bölümlerini hak ediyorlar.

Sonra önemli olacak bir çerçeveleme daha: bu üçünden hiçbiri resmi bir anlamda "optimal" değildir. Bir maliyet-risk hedefini gerçekten minimize eden scheduler, Almgren–Chriss ailesidir (Almgren ve Chriss, 2000, "Optimal Execution of Portfolio Transactions," Journal of Risk 3, 5–39); bunu Almgren–Chriss ve optimal execution schedule'ları teorisi yazısında düzgünce ele alıyoruz. TWAP, doğrusal etki altında sıfır risk iştahına sahip Almgren–Chriss'in özel bir halidir; VWAP, hacim ağırlıklı bir benchmark'a karşı minimum takip hatası stratejisidir (Konishi, 2002, "Optimal slice of a VWAP trade," Journal of Financial Markets 5(2)); POV ise hiçbir hedef fonksiyonuna karşılık gelmeyen bir sezgisel yöntemdir — başarısızlık modlarının bu kadar tuhaf olmasının tam nedeni de budur.

Piyasanın hiç kapanmadığı durumda hacim eğrisi tahmini

Hisse senedi literatürünün işi kolaydı. Hisse senetlerinde günlük içi hacim bir U şeklidir — açılışta ağır, öğle arasında sakin, kapanışa doğru tekrar ağır — bu durum Jain ve Joh (1988, "The Dependence between Hourly Prices and Trading Volume," JFQA 23(3)) tarafından belgelenmiş ve Admati ve Pfleiderer (1988, "A Theory of Intraday Patterns: Volume and Price Variability," Review of Financial Studies 1(1)) tarafından teorik bir temele oturtulmuştur; onlar isteğe bağlı likidite trader'larının ve bilgili trader'ların zaman içinde içsel olarak kümelendiğini göstermiştir. U şekli, açılış ve kapanış açık artırmaları olan iki sağlam olayla sabitlenir, dolayısıyla eğri istikrarlıdır ve aralık hacim paylarının 20 günlük hareketli ortalaması işin %90'ını halleder.

Kriptonun ne açılışı ne de kapanışı vardır, dolayısıyla saf yaklaşım hacmin düz olması ve TWAP ≈ VWAP olması gerektiğidir. Bu saf yaklaşım yanlıştır. Kripto günlük içi hacminde yapı vardır — sadece farklı saatlere bağlıdır:

Seans etkileri. Hacim, onu trade eden insanların ve masaların uyanık olduğu saatleri takip eder. BTC ve ETH major'larında en ağır bant, Avrupa akşamıyla örtüşen ABD öğleden sonrasıdır (kabaca 13:00–21:00 UTC); ikincil bir Asya rafı 00:00–08:00 UTC civarındadır ve major'larda 04:00–06:00 UTC civarında belirgin bir çukur vardır. Bölgesel sahiplik yoğunluğu olan alt pariteler, kendi ana seanslarına daha güçlü şekilde meyleder.

Funding zaman damgaları. Perpetual futures, sabit UTC saatlerinde funding'i mahsuplaştırır — tarihsel olarak her 8 saatte bir 00:00, 08:00, 16:00 UTC'de, ancak Binance ve diğerleri 2025–2026'dan beri birçok kontratı 4 saatlik ve hatta 1 saatlik mahsuplaştırma döngülerine taşımıştır. Mahsuplaştırmanın etrafındaki dakikalar güvenilir bir şekilde yükselmiş hacim basar: basis trader'ları carry pozisyonlarını açar ve kapatır, funding snapshot'ını istismar eden herkes tam da sınırda trade eder. Bunlar sıçramalardır, raf değil — 30 dakikalık bucket'lı bir eğri bunları görür; 2 saatlik bucket'lı bir eğri onları ortalayıp yok eder ve VWAP'ınız likiditenin en iyi olduğu anda tam olarak yetersiz katılım gösterir.

Haftalık mevsimsellik. Major'larda hafta sonu hacmi yapısal olarak hafta içi hacminin altında seyreder ve Pazar akşamı UTC'nin (Pazartesi sabahı Asya, artı BTC futures için CME'nin yeniden açılışı) kendine has bir imzası vardır. Tüm günler için havuzlanmış tek bir günün-saati eğrisi hatalı belirlenmiştir; haftanın günü × günün saati bir ızgara istersiniz.

Planlı olaylar. Deribit opsiyonları 08:00 UTC'de (Cuma günleri, çeyreklik kümelerle) sona erer, ABD makro verileri 12:30/14:00 UTC'de gelir, CME mahsuplaştırmaları basis akışları için önemlidir. Bunlar mevsimsellik değil takvim özellikleridir — bunları baz eğriyi kirletmek yerine dummy değişken olarak ele alın.

Tahminleyiciyi zeki hale getirmeden önce dürüst tutma ruhuyla, işe yarayan bir tahminleyici:

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

Ortalama yerine medyan kullanmak stilistik bir tercih değildir. Kripto hacmi vahşice kalın kuyrukludur; tek bir likidasyon şelalesi 10 dakikada bir günün hacminin %15'i olabilir ve ortalama tabanlı bir eğri o bucket'ta ondan sonra sonsuza dek bir sıçrama bekler. Hisse senedi literatürü statik eğrilerin ötesine geçti: Białkowski, Darolles ve Le Fol (2008, "Improving VWAP strategies: A dynamic volume approach," Journal of Banking & Finance 32(9), 1709–1722), aralık hacmini ortak bir piyasa bileşenine ve ARMA/SETAR dinamikleriyle modellenmiş hisseye özgü bir bileşene ayrıştırır ve bu ayrıştırmanın statik klasik bir eğriye kıyasla VWAP takip riskini önemli ölçüde azalttığını gösterir. Kriptoya çeviri doğrudandır: en üst N pariteden piyasa çapında bir eğri tahmin edin (ortak faktör güçlüdür — funding saatleri ve seanslar ortaktır), sonra kendi paritenizin sapmasını gerçek zamanlı güncellediğiniz ortalamaya dönen bir günlük içi süreç olarak modelleyin. Daha yakın zamanda Genet (2025, "Deep Learning for VWAP Execution in Crypto Markets: Beyond the Volume Curve," arXiv:2502.13722), öğrenilmiş uçtan uca schedule'ların Binance verisinde statik-eğri VWAP'ı geride bıraktığını gösteriyor — kriptoda hacim eğrisinin, dilimleme değil, pipeline'ın en zayıf halkası olduğunun kanıtı.

Operasyonel özet: tüm-günler için statik bir eğri bir saman adam VWAP'tır. Karşılaştırmanız "kriptoda VWAP, TWAP'ı zar zor geçiyor" diyorsa, herhangi bir sonuca varmadan önce VWAP'a gerçekten funding sıçramalarını ve hafta içi/hafta sonu ayrımını içeren bir eğri verilip verilmediğini kontrol edin.

Funding sıçramaları ve seans yapısıyla kripto günlük içi hacim ısı haritası

POV patolojileri: kendi kuyruğunu kovalayan algoritma

POV'un iddiası uyarlanabilirliktir: piyasa trade ederken siz de trade edin. Bunu üç ayrı patoloji baltalar.

1. Geri besleme döngüsü. Yukarıdaki içsellik yalnızca muhasebe düzeltmesinden ibaret değildir. Child emirleriniz hacim yaratır; hacim hedefinizi yükseltir; hedefiniz hacim yaratır. Ilımlı γ\gamma'da x=γ1γMx = \frac{\gamma}{1-\gamma}M sabit noktası kararlıdır, ancak trade sonrası raporunuzun gösterdiği ölçülen katılım (toplam tape'in γ\gamma'sı), siz olmasaydı piyasanın ne olacağına göre (γ1γ\frac{\gamma}{1-\gamma}, başkalarının tamamı) ayak izinizi olduğundan az gösterir. Daha kötüsü, ikinci dereceden geri besleme de vardır: fill'leriniz fiyatı hareket ettirir, fiyat hareketi momentum akışını çeker ve stop'ları tetikler, bu akış tape hacmini yükseltir ve POV motorunuz kendisinin sebep olduğu hacmi hızlanmak için bir davetiye olarak okur. Bu, optimal davranışın tam tersidir — etki-farkında scheduler'lar (makul parametrelerle Almgren–Chriss ve Almgren, Thum, Hauptmann ve Li, 2005, "Direct Estimation of Equity Market Impact," Risk 18(7) gibi ampirik etki tahminleri) fiyatı ittikten sonra yavaşlamanızı ister, hızlanmanızı değil. Bir likidasyon şelalesi patolojik limittir: devasa tape hacmi, tek yönlü defter ve düz vanilya bir POV, sıkışmanın tepesine tam da print'lerin olduğu yerde olduğu için en sert şekilde alım yapar.

2. Manipüle edilmek. Bir POV algosu, hacim tetiklemeli bir emir akışı makinesidir ve tetiklenen her şey yem olarak kullanılabilir. Büyük bir katılım alıcısından şüphelenen bir avcı, kuralların izin verdiği yerde kendi kendine çapraz geçerek ya da sadece küçük büyüklükte aktif trade yaparak hacim basabilir, POV motorunu öne çekebilir, sonra ona yükseltilmiş fiyatlardan likidite sağlayabilir. Bu, Brunnermeier ve Pedersen'in (2005, "Predatory Trading," Journal of Finance 60(4)) genel mekanizmasının küçük ölçekli bir örneğidir: gelecekteki talebiniz geçmiş davranışınızdan tahmin edilebilir olduğunda, başkaları onun önünde trade eder ve karşılaştığınız fiyat yolu tahmin ettiğinizden daha kötü olur. TWAP zaman içinde bir schedule sızdırır; POV ise bir tepki fonksiyonu sızdırır ki bu daha tehlikelidir çünkü hasım onu istediği zaman tetikleyebilir.

3. Hiç bitmeyen kuyruk. POV'un saati yoktur. 16:00 UTC'ye kadar 500 BTC almanız gerekiyorsa ve hacim 14:00'te buharlaşırsa, saf bir POV oturup bekler — tasarım gereği kendi başına bitirmekten acizdir. Bu yüzden her üretim POV'u bir minimum-oran tabanı ve bir yakalama modu taşır ve kayıpların gizlendiği yer tam da bu yakalama modudur: günü %10 katılımla pasif trade ederek geçirirsiniz, sonra parent'ın kalan %30'unu hedefinizin üç katı efektif katılımla dar bir kapanış penceresinden patlatırsınız. Trade sonrası ortalama iyi görünür; son dilimin marjinal maliyeti acımasızdır. POV raporlarınız kuyruğu ayrı olarak göstermiyorsa, gerçek maliyetini görmemişsinizdir.

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

Bu kod parçasındaki iki ayrıntı gerçek iş yapıyor: hedef, biz-hariç tape hacminin γ1γ\frac{\gamma}{1-\gamma}'ını kullanıyor (tepki verdiğiniz tape'ten kendi fill'lerinizi çıkarmanız gerekir — şaşırtıcı sayıda implementasyon bunu yapmaz) ve zaman doldukça deadline tabanı POV'u kalan-üzerinde-TWAP'a dönüştürür ki bu en azından kuyruk maliyetini tahmin edilebilir kılar.

POV geri besleme döngüsü: fill'ler hacim yaratır, hacim hedefi yükseltir

Benchmark'lar: VWAP'ı geçmek neden yine de para kaybettirebilir

Scheduler ve benchmark ayrı seçimlerdir ve bunları birbirine karıştırmak en yaygın trade-sonrası günahtır. İki benchmark hakimdir.

VWAP benchmark'ı — ortalama fill fiyatınızı aralık VWAP'ıyla karşılaştırmak — Berkowitz, Logue ve Noser (1988, "The Total Cost of Transactions on the NYSE," Journal of Finance 43(1)) tarafından tanıtıldı; onlar günün hacim ağırlıklı fiyatını kurumsal execution kalitesi için tarafsız bir ölçüt olarak önerdiler. Teknik olduğu kadar sosyolojik bir nedenle de sektör varsayılanı haline geldi: hesaplaması kolay, açıklaması kolay ve trade'inizi gün boyu yaymanız halinde kötü görünmesi zor.

Implementation shortfall (arrival price), Perold'dan (1988, "The Implementation Shortfall: Paper Versus Reality," Journal of Portfolio Management 14(3), 4–9) gelir: her şeyi kararın verildiği andaki fiyat p0p_0'a karşı ölçün. Doldurulan miktarı XfX_f, ortalama fiyatı pˉ\bar{p} olan XX büyüklüğünde bir alım ve terminal fiyat pTp_T için:

IS=(pˉp0)Xfexecution maliyeti  +  (pTp0)(XXf)fırsat maliyeti  +  u¨cretler.\mathrm{IS} = \underbrace{(\bar{p} - p_0)\,X_f}_{\text{execution maliyeti}} \;+\; \underbrace{(p_T - p_0)\,(X - X_f)}_{\text{fırsat maliyeti}} \;+\; \text{ücretler}.

Perold'un vurgusu, kağıt üzerindeki portföylerle gerçek olanlar arasındaki farkın tam olarak bu miktar olduğuydu — ve dikkat edin, sizi gerçekleştiremediğiniz şey için ücretlendirir, ki bunu VWAP benchmark'ı sessizce göz ardı eder. Bu fırsat-maliyeti terimi, IS'yi imzası dolmamış miktar olan POV için tek dürüst benchmark yapan şeydir.

Şimdi tuzağa gelelim. Bir benchmark olarak VWAP'ın iki yapısal kör noktası vardır:

Kendine referanslıdır. Fill'leriniz benchmark'ın içindedir. Eğer aralık hacminin %30'uysanız, VWAP'ın kabaca %30'u sizin kendi ortalama fiyatınızdır ve VWAP'a göre ölçülen slippage'iniz kendi katılımınız tarafından mekanik olarak küçültülür — emriniz ne kadar büyük ve etkili olursa, o kadar iyi puan alır. Tek trader'ın siz olduğunuz limitte, fiyatı ne kadar kötü hareket ettirdiğinizden bağımsız olarak VWAP'ı tam olarak sıfır farkla geçersiniz. VWAP slippage'ı maliyeti değil, schedule uyumunu ölçer.

Karara göre drift'i göz ardı eder. Somut sayılar: 100 BTC'yi 60.000 dolarlık bir karar fiyatından almaya karar veriyorsunuz. Piyasa öğleden sonra boyunca yükseliyor; aralık VWAP'ı 60.320 dolar basıyor ve siz ortalama 60.290 dolardan doluyorsunuz. VWAP raporu: –5 bps, benchmark'ı geçti, masa yeşil hücre alıyor. Arrival raporu: 100 BTC üzerinde karar fiyatının 290 dolar üstünde ödediniz — +48 bps, 29.000 dolar implementation shortfall. Her iki sayı da doğru. Sadece biri para. Ve teşvik yozlaşması daha derine iner: VWAP üzerinden puanlanan bir trader, trend yükselen bir günde yavaşlamalıdır (trade'leri yaymak benchmark'ı daha iyi takip eder), ki bu fiyat sizden uzaklaşırken shortfall'ı minimize eden şeyin tam tersidir. Benchmark sadece maliyeti yanlış ölçmekle kalmaz — yanlış davranışı reçete eder. Kissell (2013, The Science of Algorithmic Trading and Portfolio Management, Academic Press) bu benchmark-seçim sorununu uzun uzadıya ele alır; onun çerçevelemesi içselleştirmeye değer: benchmark kimin riskini yönettiğinizi kodlar. VWAP, execution yapan masanın mahcubiyet riskini yönetir. Arrival price, portföyün K/Z'ını yönetir.

Pratik çözüm: stratejileri implementation shortfall üzerinden puanlayın; VWAP slippage'ını bir teşhis olarak kullanın (zamanlama becerisini şans faktöründen ayırır, çünkü drift hem sizi hem benchmark'ı etkiler) ve emri aralık hacminin %10'undan fazlası olan hiç kimsenin katılımını da belirtmeden VWAP slippage'ı söylemesine izin vermeyin.

Deney: üç algoritma, tek tape

Tanımlar netleştiğine göre, karşılaştırma yazılarının asla yapmadığı şeyi yapabiliriz: aynı yeniden oynatılmış veri üzerinde aynı parent emirlerinde üç scheduler'ı çalıştırıp sıfatlara değil maliyet dağılımlarına bakabiliriz. Test düzeneği, Fill simülasyonu: kısmi fill'ler, sıra pozisyonu ve backtest fill'leriniz neden yalan (partial fills, queue position and why your backtest fills are lies) yazısında anlatılan olay güdümlü fill simülatörü üzerinde çalışır — yeniden oynatılmış L2 derinliği, child limit emirleri sıra pozisyonu kazanır, agresif child'lar defteri tarar ve fill'lerimiz scheduler'ların gözlemlediği tape'i bozar (bu, geri besleme bölümü gereği POV için son derece önemlidir).

Kurulum, kendi verinizde tekrarlayabilmeniz için:

  • Enstrüman/veri: BTCUSDT perpetual, 90 günlük L2 replay (üst 20 seviye, 100 ms) + trade tape'i.
  • Parent emirler: algoritma başına 500, algoritmalar arasında özdeş: rastgele başlangıç zamanları, ufuk T=4T = 4sa, büyüklük son 30 günlük ADV'nin %0,75'i (etkinin gerçek olması için yeterince büyük, üçünün de makul şekilde bitirebilmesi için yeterince küçük), alış yönü, karar fiyatı = başlangıçtaki mid.
  • TWAP: 48 child dilim, ±%30 zamanlama/büyüklük jitter'ı.
  • VWAP: 30 dakikalık haftanın-günü × günün-saati medyan eğrisi (yukarıdaki tahminleyici), haftalık yeniden fit, günlük içi güncelleme yok — bilerek basit sürüm.
  • POV: biz-hariç tape hacminin %12'si γ\gamma, minimum-oran tabanı, son 30 dakikada TWAP yakalaması.
  • Metrikler: karar fiyatının bps cinsinden IS'si (ücretler dahil), bps cinsinden VWAP slippage'ı, tamamlanma oranı ve — kimsenin raporlamadığı tek şey — her parent'ın son çeyreğinin IS'si.

Çalıştırmalarımızdan temsili sonuçlar (sizin sayılarınız farklı olacak, şekli olmamalı):

Metrik (arrival'a karşı bps) TWAP VWAP POV 12%
Ortalama IS 11.8 9.6 8.9
Medyan IS 9.1 7.7 6.4
IS standart sapması 21.5 19.8 26.3
95. yüzdelik IS 46 41 58
Ortalama VWAP slippage'ı +1.9 +0.4 –0.8
T'de tamamlanma 100% 100% 96.4%
Ortalama IS, parent'ın son çeyreği 12.5 10.2 19.7

Artan önem sırasına göre üç okuma:

Ortalamalar POV'u pohpohluyor, kuyruklar onu mahkum ediyor. POV, ortalama ve medyan IS'de kazanıyor — gerçekleşen likiditeye uyarlanmak, statik bir eğriye kıyasla gerçekten birkaç bps değerinde. Ama IS standart sapması ve 95. yüzdeliği üçünün en kötüsü, tamamlanma oranı %100 değil ve son-çeyrek maliyeti başlık rakamının iki katından fazla: hiç bitmeyen kuyruk artı yakalama modu, maliyeti tam da ortalamaların gizlediği yerde yoğunlaştırıyor. Parent emirleriniz alfa güdümlüyse ve sert bir ufku varsa, önemli olan o kuyruk sayısıdır ve POV'un ortalama avantajı bunun için ödemez.

VWAP'ın TWAP'a karşı avantajı tam olarak tahmin kalitesidir. VWAP–TWAP IS farkını gerçekleşen hacim-eğrisi hatasına (L1L_1 mesafesi, tahmin uiu_i ile gerçekleşen paylar arasında) koşullandırın ve ilişki monotondur: en iyi-tahmin üçlüsündeki günlerde VWAP, TWAP'ı ~4 bps ile geçer; en kötü üçlüde fark gürültü içinde kalır ve zaman zaman tersine döner. Kriptoda, en kötü üçlü rastgele değildir — şelale günleri ve haber günleridir, ki bunlar aynı zamanda genel olarak en yüksek maliyetli günlerdir. VWAP, zaten kolay olan günlerde daha iyi performans göstererek ortalamanızı iyileştirir.

VWAP slippage'ı ve IS, algoritmaları farklı şekilde sıralıyor. POV, negatif ortalama VWAP slippage'ı gönderir — elbette gönderir, tam da benchmark'ı tanımlayan hacimle orantılı trade eder ve fill'leri onun içinde oturur. VWAP skor tablosuna göre POV buradaki en iyi algoritma; arrival skor tablosuna ve tamamlanma riskine göre ise en tehlikelisi. Aynı tape, aynı fill'ler, zıt sonuç — bu da önceki bölümün tüm argümanının bir tablo olarak sunulmasıdır.

TWAP, VWAP ve POV için implementation shortfall dağılımları

Test düzeneğinin kendisi fill simülatörü etrafında ~50 satırdır ve her dakikaya değer, çünkü scheduler seçimini bir zevk tartışmasından bir ölçüme dönüştürür:

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)

Pratikte seçim

Bunların hepsinden çıkan dürüst seçim kuralları:

  • Sert deadline, alfa güdümlü parent: TWAP ya da öne-yüklü bir Almgren–Chriss schedule'ı. Düz-likidite vergisini ödeyin; tamamlanma garantisini ve sınırlı kuyruğu satın alın. Child'ları rastgeleleştirin.
  • Benchmark güdümlü akış (VWAP üzerinden ödeme alıyorsanız), ya da normal bir günde büyük büyüklük: VWAP — ve mühendislik bütçenizi hacim tahminleyicisine harcayın: haftanın-günü ızgarası, funding-sıçraması çözünürlüğü, Białkowski–Darolles–Le Fol tarzı günlük içi dinamik güncelleme. Tembel eğrili bir VWAP motoru, fazladan adımlı bir TWAP'tır.
  • Fırsatçı, sert deadline yok, likiditeye duyarlı: ılımlı γ\gamma'da (≤%15) POV, biz-hariç hacim üzerinden hesaplanmış, bir şelale filtresiyle (tape hacmi z-skorları patladığında katılımı sınırlayın) ve maliyetini ayrı olarak ölçtüğünüz bir deadline yedek planıyla.
  • Ne çalıştırırsanız çalıştırın: Perold'a göre arrival'a karşı implementation shortfall üzerinden puanlayın. VWAP slippage'ını schedule becerisinin bir teşhisi olarak tutun, asla skor tablosu olarak değil — skor tablosu para cinsinden olmalı ve sadece arrival price bunu sağlar.

Ve deneyin sürekli dayattığı meta-kural: kendi yeniden oynatılmış verinizde ortalamaları değil dağılımları karşılaştırın. Bir scheduler bir hacim tahminine yapılan bahistir ve bahisleri kuyrukları göz ardı ederek ortalama kazançlarına göre değerlendirmezsiniz — piyasa size POV'u tam da böyle satar.

Sorumluluk Reddi: Bu makalede sağlanan bilgiler yalnızca eğitim ve bilgilendirme amaçlıdır ve finansal, yatırım veya ticaret tavsiyesi niteliği taşımaz. Kripto para ticareti önemli bir kayıp riski içerir.

Yazarlar

Eugen Soloviov
Eugen Soloviov

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.

Newsletter

Piyasanın Önünde Olun

Özel yapay zeka ticaret içgörüleri, piyasa analizi ve platform güncellemeleri için bültenimize abone olun.

Gizliliğinize saygı duyuyoruz. İstediğiniz zaman abonelikten çıkabilirsiniz.