Ana sayfa Yazarlar Devexperts Iceberg, Buzd...

Iceberg, Buzdağı Emirleri Nedir? Nasıl Tespit Edilir?

Buzdağı Emirleri Nedir?

Organize borsalardaki şekliyle Buzdağı emri, herhangi bir zamanda, emrin tamamının ancak çok az bir kısmının emir defterinde ‘göründüğü’ (‘order tranch’), hacmin kalanınınsa emir defterinden saklandığı bir emir tipidir. Görünen emir gerçekleştiğinde, buzdağı emrinin sıradaki parçası emir defterine, yeni bir limit emir olarak yazılır ve bu süreç, buzdağı emrinin tamamı bitene, veya emir iptal edilene kadar, devam eder.

Buzdağı Emirlerinin tespit edilmesi

29 Ağustos 2019 tarihinde dxFeed ekibi olarak bir makale yayınladık. Dmitry Zotikov ve Anton Antonov’un kaleme aldığı bu 16 sayfalık makalede bizler, sadece bir yazılım firması değil aynı zamanda piyasa oyuncularının analitik ve kavramsal ihtiyaçlarını da dikkate alan bir fintek olmanın verdiği bilinçle, piyasada özellikle algoritmik alım-satım yapan müşterilerimiz için büyük önem arz eden ‘buzdağı emirlerinin tespit edilmesi ve tahmin edilmesi’ sorununa ve ihtiyacına odaklandık.

CME (‘Chicago Mercantile Exchange‘) Borsasının verilerinin kullanıldığı ve bu borsanın desteklediği emir tipleri ve emir/ islem defteri kayıtlarının temel alındığı bu makalede, CME emir defteri dinamikleri üzerinden, ‘Açık Buzdağı’’ (‘Native Iceberg’) ve ‘Saklı Buzdağı (‘Syntetic Iceberg’) emirlerinin piyasadaki varlığının tespit edilmesi ve tahmin edilmesine dair yaptığımız çalışmaları özetledik, bu amaçla tasarlanan ve mülki hakları dxFeed’e ait olan algoritmamızın temel prensiplerini sizlerle paylaştık ve bu algoritmanın hesaplama detaylarını ve ilgili literatürü sizler için özetledik. Aynı zamanda siz müşterilerimizin, dxFeed API’leri kullanılarak, bu algoritmayı kendi alım/satım stratejilerine nasıl dahil edebileceklerine dair öneri ve tavsiyelerimizi de, bu makalede sıraladık.

Bir taraftan, ‘CME Iceberg Order Detection and Prediction’ adlı bu makalenin İngilizce olarak kaleme alınmış orijinal metnine, tüm detaylarıyla, buradan ulaşabilirsiniz.(CC BY-NC-SA 4.0 lisansı ile dağıtılmakta olan bu makalenin orijinal metni için lütfen tıklayınız: https://arxiv.org/abs/1909.09495 ).

Diğer taraftan bizler, bu makalenin yalın bir özetini de burada sizlerle paylaşmak istedik. Bu yazıda, makalenin kısa bir versiyonu yanında, dxFeed olarak buzdağlarının tespit edilmesi ile ilgili verdiğimiz API hizmetleri hakkında da detaylı bilgiye ulaşabilir ve paylaştığımız örnekleri inceleyebilirsiniz.

Buzdağı Emirlerinin tespit edilmesi için dxFeed’in önerdiği yaklaşım

Buzdağı emrinin tipine bağlı olarak dxFeed, CME borsasındaki buzdağı emirlerini tespit etmek için, mülkiyeti kendine ait bir algoritma kullanmaktadır.

Hatırlatmak gerekirse CME, iki farklı Buzdağı Emir tipini destekler:

Açık Buzdağları (‘Native Icebergs’)

Açık buzdağları, borsanın kendisi tarafından bir emir tipi olarak kabul edilir ve bu şekilde borsaya iletilen emirler, fiziken borsa tarafından bulundurulan ve yönetilen yazılımlar tarafından yönetilir. Burada önemli olan nokta; Borsanın bu ana emri (‘parent order’, ‘original order’, ‘iceberg order’) yönetirken, ilgili alt emirlerde ana emrin kimlik bilgisini koruyarak (‘ID’) emir defterine iletmesidir. Alt emirlerin her birinde, bu ana emre ait ID’ye ilişkin kayıtlar bulunur ve bu şekilde borsanın emir ve işlem defterinde kayıtları tutulan alt emirlerle bu ana emir, kolaylıkla ilişkilendirilebilir.

Saklı Buzdağları

Saklı buzdağları (‘Synetic Icebergs’, ‘Sentetik buzdağları’), emri yöneten asıl algoritmanın borsa tarafında değil de müşteri tarafında tutulduğu buzdağı tipidir. Buzdağı emri, fiziki olarak müşteri tarafında yüklü bulunan bu yazılım marifetiyle (Independent Software Vendor, ISV) ve burada tasarlanmış bir iceberg emir yönetim algoritmasına uygun olacak şekilde yönetilir. ISV, buzdağı emrini küçük alt emirlere böler, bu emirleri limit emir olarak borsaya iletir, bu alt emirlerin akibedi takip eder ve nihayetinde de ISV, iceberg emrinin tüm sürecini yönetir ve tamamlar.

Burada en önemli husus, bu şekilde yönetilen buzdağı emrinde bahsedilen bu alt emirlerin, emir defteri kayıtlarında, ‘bir büyük buzdağı yapısının birer parçası’ olarak görülmemeleridir. Aksine bu emirler, yeri geldiğinde, müşteri tarafında yönetilen ISV tarafından borsaya ‘herhangi bir limit emir’ gibi iletilir ve bu şekilde kayıt altına alınır (yani bu alt emir parçacıklarında bir ana emre ait bir ID ve/veya benzeri başka bir kayıt bulunmaz). Bu emirler, emir ve işlem defterlerinde herhangi bir limit emir gibi gerçekleştikleri ve bu şekilde kayıt altına alındıkları için, yerli buzdağlarının aksine saklı buzdağlarını tespit etmek daha zordur ve kimi varsayımlar gerektirir.

Gerçekten de Açık Buzdağlarını tespit etmek ve ilgili değişkenleri tahmin etmek, kavramsal olarak çok daha kolaydır, keza:

  1. Bu tip emirlerde asıl buzdağı emrinin IDsi , buzdağı emri tamamıyla gerçekleşene kadar (veya iptal edilene kadar) değişmez ve alt emirlerde de bu emrin bir izi olacağı için Açık Buzdağı emirleri rahat bir şekilde tespit edilebilir,
  2. Açık buzdağlarının, onları tespit etmekte bize yardımcı olan ikinci özelliği de, şaşmaz bir şekilde, ilgili alt emirlerin büyüklüğünün toplamının, emir tamamlandığında, ana emrin orijinal büyüklüğünden (‘original size’) büyük olmasıdır. Veya Açık Buzdağlarında, ana emir henüz bitmemiş ve/veya sistematik olarak yönetilmeye devam ederken bile, herhangi bir anda hesaplanan alt emirler toplamı, o anda ana emir için hesaplanan ‘bekleyen kısım’dan (‘resting portion’) her zaman büyüktür.

Bu iki özelliğinden dolayı Açık Buzdağı emirleri, kesin ve doğru şekilde tespit edilebilir.

Ancak sentetik buzdağları, tahmin edileceği üzere, borsadaki kayıtlara bakılarak tahmin etmesi daha zor emir tiplerindendir. Bu tip buzdağı emirlerini ancak “tahmini olarak” tespit edebiliriz ve bu tespitimiz de bir takım matematiksel matematiksel ‘sezgilere’ (‘heuristic’) ve kesinliği yüzde yüz olmayan kimi varsayımlara dayanır.

dxFeed’in önerdiği yaklaşım

dxfeed, tasarımı ve mülki hakları kendisine ait bir algoritma kullanarak, CME’ye gönderilen Açık veya Saklı tüm buzdağı emirlerinin tespit edilmesi ve tahmin edilmesini kolaylaştıracak kimi araçlar geliştirmiştir ve müşterilerinin kullanımına açmıştır.

Bir iki örnek vermek gerekirse, aşağıdaki tablolarda, dxFeed’in algoritmasının, CME borsasındaki belli bir gün ve saat aralığındaki işlemlere bakarak yaptığı modelleme ve tahminlerin sonuçlarından bazılarını bulabilirsiniz.

Tablo 1’de, bu algoritma tarafından tespit edilmiş buzdağı emirlerinin tüm emirlere oranını bulabilirsiniz.

Tablo 1 – Tespit edilen buzdağı emirlerinin tüm emirlere oranı

Tablo 2’de, tespit edilen bu buzdağı emirlerinin tahmin edilen zirve emirleriyle ilgili adet ve büyüklük tahminlerini bulabilirsiniz.

Tablo 2 – Tespit edilen buzdağı emirlerinin zirve emirleri

Tablo 3’de, dxFeed’in algoritması tarafından tespit edilen buzdağı emirleri arasında hangilerinin Açık Buzdağı, hangilerinin Saklı Buzdağı olabileceğine dair tahminleri bulabilirsiniz.

Tablo 3 – Tespit edilen buzdağı emirlerinin tipleri ile ilgili tahminler

Not: Bu tespitlerin CME’nin hangi gün ve saatteki defter kayıtlarına dayanarak yapıldığına dair detaylı açıklamaları, makalemizin orijinalinde bulabilirsiniz.

 dxFeed API

Burada hatırlatmak istediğimiz bir diğer husus, dxFeed’in geliştirdiği bu algoritmanın, bir buzdağı emrini tespit etmekten ziyade, bu buzdağı ile ilgili kimi önemli parametrelerin tahmini için de kullanılabilmesi olabilir. Bu algoritma, bir buzdağı tespit etmenin ötesinde, bu tespitinin akabinde son kullanıcıya tespit edilen bu buzdağı emriyle ilgili aralarında bu emrin ‘toplam büyüklüğü’ de olmak üzere kimi özellikleri hakkında tahminler de hesaplar ve sunar. Algoritmanın son kullanıcılara sağlayacağı bu tespit ve tahmin yeteneği, son kullanıcının bu emirlerin tespit edebilmesi üzerine kurulu alım/satım stratejilerini hayata geçirebilmesine imkan sağlar ve bu stratejiler üzerinden de piyasadaki arbitraj (veya emir defteri dengesizliği) fırsatlarını birer kar fırsatı olarak kullanmasını mümkün kılar.

Detaylara gelirsek; dxFeed API, eşanlı olsun, veya gecikmeli olsun, veya tarihsel olsun, verinin zamansallığından bağımsız olarak, son kullanıcıya emir defterini analitik olarak yeniden kurmaya yardımcı araçlar sunar. dxFeed Java API’nin ‘OrderBookModel’ ismini verdiğimiz bu özelliği sayesinde dxFeed API, “çeşili piyasa anları ve olaylarını dikkate alarak”, emir defterinin “analitik bir yorumunu” oluşturur. Emir defterinin bu versiyonunda da dxFeed, tespit edilen buzdağı emirlerini birer ’AnalyticOrder’ olarak işaretler ve kullanıcıya gösterir. Bu şekilde işaretlenen emirlerde, ‘normal emiri’  ifade eden nesneye ait özelliklerin yanında  (‘Order’ class and class attributes), ilgili emre ait yeni özellikler de tahmin edilir ve hesaplanır. Bu yeni özellikler:

  • icebergHiddenSize: dxFeed Algoritması tarafından tespit edilen bu buzdağı emrinin tahmin edilen büyüklüğü
  • icebergExecutedSize: dxFeed Algoritması tarafından tespit edilen bu buzdağı emrinin tespit edilen toplam tutarı
  • icebergPeakSize: Tespit edilen buzdağı emrinin zirve emir miktarı

dxFeed’in buzdağı emirlerini nasıl tespit ettiğine ve ilgili parametreleri nasıl tahmin ettiğine dair iki örneği de burada sizler için özetledik.

Açık Buzdağı örneği

ID’si 645752022466 olan bir emri takip ettiğinizi düşünün. Diyelim ki, bu emrin 11 lotluk kısmı tahtaya yazıldı ve bir limit emir olarak işlem defterine kaydedildi. (11 lotluk alt emir “göründü”.)

Diyelim ki aynı emir, girilen limit fiyattan karşılandı ve emir gerçekleşti.

Emir defterindeki kayıtlar şu şekilde görünecektir:

ask LIMIT 11 @ 2890.25

bid TRADE 3 @ 2890.25 (645752022495 ile karşılandı)

bid TRADE 4 @ 2890.25 (645752022505 ile karşılandı)

bid TRADE 4 @ 2890.25 (645752022508 ile karşılandı)

11 lotluk ilk zirve emrin (‘Peak Order’) gerçekleşmesinin ardından, aynı emir ID’si ile bir 11 lotluk kısım daha, emir defterine girer.

İşte bu noktada, dxFeed API’nin sizlere sağlıyor olduğu algoritma, bu emrin aslında bir buzdağı emri olduğunu tespit eder. Bu tespitin akabinde de, bünyesinde takip ettiği analitik emir defterine bu emirle ilgili olarak bir ‘AnalyticOrder’ sınıfı ekler ve bu nesnenin:

  • ‘toplam emir büyüklüğü’
  • ‘Zirve Emir’ büyüklüğü
  • ‘Kalan gizli hacim’
  • ‘Gerçekleşen kısım’
  1. değişkenleri için birer tahmin üretir ve bunları bildirir.

ask MODIFY 11 @ 2890.25

AnalyticOrder(icebergPeakSize = 11, icebergHiddenSize = 33, icebergExecutedSize = 11)

bid TRADE 2 @ 2890.25 (against 645752022518)

bid TRADE 9 @ 2890.25 (against 645752022532)

Akabinde, yeni alt emirler birbirini takip eder. Takip eden yeni alt emirlerin büyüklüğü elbette ki farklılaşabilir. Her şekilde dxFeed Algoritması, her yeni alt emir ve elde ettiği yeni bilgilerle AnalyticOrder’da tutulan istatistik ve tahminlerini günceller ve bu tahminlerini daha kesin rakamlar üzerinden sürekli iyileştirir. Son alt emir parçasının da gönderilmesi ve gerçekleşmesini takiben bu emir, analitik emir defterinden çıkartılır.

ask MODIFY 11 @ 2890.25

AnalyticOrder(icebergPeakSize = 11, icebergHiddenSize = 22, icebergExecutedSize = 22)

bid TRADE 6 @ 2890.25 (against 645752022593)

bid TRADE 3 @ 2890.25 (against 645752022594)

bid TRADE 4 @ 2890.25 (against 645752022602)

(…)

ask MODIFY 1 @ 2890.25

AnalyticOrder(icebergPeakSize = 1, icebergHiddenSize = 3, icebergExecutedSize = 46)

bid TRADE 1 @ 2890.25 (against 645752022639)

ask DELETE 1 @ 2890.25

Yukarıdaki örnekte, Açık buzdağı emri ile ilgili 5 alt emir gönderilmiştir. Bu buzdağı emir için Zirve emir 11 olarak tahmin edilmiştir ve emrin toplam büyüklüğü de 47 olarak tahmin edilmiştir. 

Sentetik Buzdağı Örneği

Daha önce de bahsettiğimiz üzere, Sentetik Buzdağı Emirleri, borsada değil ama borsa dışında tutulan bağımsız yazılımlar (ISV) tarafından yönetilir. Bu sebepten ötürü dxFeed Algoritması, bu tip buzdağı emirlerini tespit etmek ve ilgili parametrelerini tahmin etmek için bir takım matematiksel sezgilere (‘heuristic’) ve kimisi esnetilebilir kimisiyle esnetilemez bir takım varsayımlara ihtiyaç duyar. Bu varsayım ve sezgileri özetlemek gerekirse:

  • ‘dt’: Bu emir tipinde ISV’nin, bir alt emir gönderdikten sonra, belli bir zaman içerisinde (‘dt’) yeni bir alt emri piyasaya limit emir olarak göndereceği varsayılır.
  • ‘Değişken dt’ (‘non-constant dt’): ISV’lerin, bir önceki emir gerçekleştikten sonra bu emrin gerçekleştiğini anlamaları, ve, sıradaki alt emri piyasaya göndermeleri arasında geçen süre, bu yazılımların borsanın dışında olmasından mütevellit, sabit değildir. dxFeed algoritması bu pratik gerçeği dikkate alarak hesaplamalarını yapar.
  • ‘Sabit alt emir’ (‘constant display quantity’): ISV’nin, Sentetik buzdağı emrini işlerken, her seferinde aynı büyüklükte bir alt emri piyasaya gönderdiği varsayılır.
  • ‘Aynı fiyat seviyesi (‘Constant Price Level’): Benzer şekilde dxFeed’in algoritması, “sadece bir seviyede çalışan”, ve bu sabit fiyat seviyesine “sabit büyüklüklerde alt emir gönderen” buzdağlarını tespit eder. Bir başka deyişle, sentetik buzdağının toplam büyüklüğünün, dxFeed tarafından tespit edilebilmesi için, bu büyüklüğün “sabit alt emrin belli bir katı kadar” olması ve piyasaya gönderilecek olan son alt emrin de dahil olmak üzere tüm alt emirlerin, gönderilen ilk alt emirle aynı büyüklükte olması gerekmektedir. Haliyle, dxFeed algoritması, değişken fiyatlarda, veya, değişken alt emir büyüklükleriyle çalışan sentetik buzdağı emirlerini tespit edemez.
  • ‘Gerçekleşen son emir’ varsayımı: dxFeed Algoritması, dt süresi içinde bir başka alt emir iletilmezse, ISV’nin buzdağı emrini bitirdiğini varsayar.
  • ‘İptal edilen son emir’ varsayımı: Aynı şekilde dxFeed algoritması, dt süresi içinde yeni bir alt emir iletildiğini ve ancak bunun iptal edildiğini görürse, ve bu iptal edilen son alt emirden sonra da, dt süresi içinde yeni bir alt emrin gelmediğini fark edince, bu buzdağı emrinin iptal edildğini ve zincirin sonlandığını varsayar.
  • ‘Tek çocuk emir’ varsayımı: dxFeed algoritmasının bir diğer varsayımı da, çocuk emirler (‘Child Order’) ile ilgilidir. dxFeed algoritması, ISV’nin, alt emirleri gönderirken, bu alt emirleri daha küçük parçalara ayırmadığını varsayar. Haliyle dxFeed’e göre bir sentetik buzdağının alt emirleri, tek bir çocuk emirden oluşur (Bir diğer deyişle, dt içerisinde sadece tek bir alt emir gönderilir). Olur ya, borsanın emir iletim hatlarındaki bir gecikme veya başka bir sebepten ötürü aynı dt içinde iki emir borsaya ulaşırsa, dxFeed Algoritması bunları aynı alt emrin iki yavru emri saymaz, iki ayrı alt emir sayar ve hesaplarına bu şekilde dahil eder.

Bu varsayımlar altında dxFeed Algoritması, “dt süresi içinde”, ve “aynı miktarlarda”, ve “aynı fiyat seviyesine gönderilen” bu sıralı limit emirleri değerlendirir ve bunları bir “emir silsilesi” (order chain) şeklinde ele alır. dxFeed algoritmasının, bu aynı dt içinde emir defterinde görünen ve belli bir süre de emir defterinde kalan ve sonra da iptal veya gerçekleşmelere bağlı olarak emir defterinden düşen bu alt emirler için hesapladığı ‘Olası Zincirler Ağacı’ (‘Tree of possible tranches’), Sentetik Buzdağı emrinin tahminlemesinin de özünü oluşturur. Keza bu ağ gösteriminde (‘network graph’), yapraklardan geriye köke doğru giden her bir ‘emir zinciri’, (‘order chain’), muhtemel bir buzdağı tahminini ifade eder.

Bu ağacın çizilmesi ve tespit edilmesi sürecinde, hesaplamaları ve tahminleri zorlaştıran bir önemli husus, özellikle tahtası çok aktif olan borsaların emir defterlerinde, birden fazla alt emrin, henüz ilki iptal, güncelleme veya gerçekleşmeden ikincisinin, “aynı dt aralığı içinde” emir defterine varması gerçeğidir. Yoğunluk ve gecikmelerle alakalı olarak gözlenebilecek bu durum, dxFeed algoritmasının hesaplamalarını ve tahmin yeteneğini zorlayabilmektedir. Bu durumlarda, bahsettiğimiz üzere, bu aynı dt içinde gönderilen emirler, “iki ayrı alt emir” olarak değerlendirilmekte ve ağaç gösterimine bu şekilde dahil edilmektedir.

Hesaplamaları ve tahminleri zorlaştıran bir başka önemli husus da, bu şekilde tahtada aynı anda bulunagelen iki alt emrin, “aynı zamanda” (‘simultaneously’) gerçekleşmesi ve emir defterinden aynı anlarda çıkmalarıdır. Bu durumda, ISV tarafından, dt aralığı içinde gönderilen sıradaki alt emrin, az önce beraber gerçekleşen ve defterden çıkan emirlerden hangisiyle ilişkili olduğu, kolayca tespit edilememektedir. (Ağaç yapısında belirsizlik oluşması).

Bir basit örnekle devam edelim.

Tablo 4’te, dxFeed algoritmasının sentetik buzdağlarını tespit ve tahmin ettiği emir defteri kayıtlarının bir kısmı gösterilmektedir.

Bu emir defteri ve ilgili dinamikler, dxFeed algoritması tarafından, şu şekilde anlaşılır:

dxFeed algoritması, bu örnekte, dt yi 0.3 saniye olarak tespit etmiş olsun.

Limit order#1 emir defterinde karşılanır ve emir defterinden temizlenir.

Akabinde, ISV order2#yi emir defterine gönderir ve bu alt emir, dt süresi içinde deftere kaydedilir. Bu şekliyle de emir zincirinin sıradaki halkasını oluşturur.

Akabinde, gözlemlendiği üzere, limit emir #4 ve limit emir #5, beklendiğinin aksine, dt süresi içinde borsaya varmamışlardır. Bu sebepten ötürü, varsayımlar ışığında bu iki emir “yeni bir buzdağı emrinin başlangıcı” olarak değerlendirilir ve ayrı birer zincir olarak ağaca kaydedilir.

Kayıtlara bakınca, bu iki emrin aynı anda gerçekleştiği görünür.

Akabinde, dt süresi içinde, limit emir #6 tahtaya varır ve hem dt içinde varması hem de emir büyüklüğünün sabit emir kadar olmasından mütevellit, bu limit emir de ağacın bir parçası kabul edilir. dxFeed Algoritması tarafından “sıradaki alt emir” olarak tespit edilen limit emir 6#, figürdeki gösterildiği şekilde agaca eklenir.

Ve bu süreç:

  • “Son emir gerçekleşip de dt süresi içinde yeni bir alt emir gelmeyene” (‘tamamlandı’ tahmini – ‘completed’) ,
  • Veya, “son emir iptal edilip de dt süresi içinde yeni bir alt emir yazılmayana kadar (‘iptal edildi’ tahmini – ‘incomplete’)
  • Ve artık emir defterinden düşmeyen başka bir alt emir kalmayan kadar

devam eder.

Aşağıdaki figürde, dxFeed algoritmasının bu tespitlerinin bir ağ grafiği şeklinde ifadesi yer almaktadır.

Tablo 5 –  dxfeed Algoritmasının tespitleri – Ağ gösterimi

Düğüm (‘Node’): Bahsedilen emir ID’lerini ifade eder. 

Mesafe (‘Edge’): İki alt emir arasında geçen süreyi ifade eder.  

Burada, dikkat edilirse, bu figürde belirtilen süreler ile dt arasında önemli farklar bulunmaktadır. Bunun tek sebebi, ISV tarafından ‘hep aynı = dt’ zaman aralıklarıyla borsaya gönderilen alt emirlerin her birinin, emir defterindeki ömrünün, defterin dinamiklerine bağlı olarak, birbirinden farklı olmalarıdır.

Son tahlilde bu grafikteki her bir zincir, “olası bir buzdağı tahmini”olarak değerlendirilebilir. Birden fazla zincir ve haliyle birden fazla buzdağı tahminini içeren bu süreçte dxFeed Algoritması, bu zincirlerin her biri için hesaplanan zincir büyüklüklerini (‘total chain volume’) dikkate alarak, nihai bir istatistik hesaplar ve bu tahminini de “tespit edilen sentetik buzdağının toplam büyüklüğü” olarak son kullanıcıya gösterir. (icebergExecutedSize)

Iceberg Detection https://www.dxfeed.com/solutions/iceberg-detection-solution/ academic article