Çoklu borsa kripto arbitraj izleme altyapısı: örnek senaryo

Bu sayfa gerçek bir müşteri projesini değil, Fincode'un bu tür bir projede izlediği yaklaşımı gösteren örnek bir senaryoyu anlatır. Teknik ayrıntılar resmi kaynaklara dayanır; kapsam, süre ve fiyat her projede ayrıca belirlenir.

İhtiyaç

Ekranda görülen fiyat farkı çoğu zaman fırsat değildir. Her iki taraftaki işlem ücreti, hedef miktarın emir defterinde yarattığı kayma, platformlar arası transferin ücreti ve süresi ile bu süre içinde fiyatın değişme riski farkı eritebilir. Senaryodaki ekip bu nedenle ham fiyatları değil, tüm maliyetler düşüldükten sonra kalan farkı izlemek istiyor. Maliyet kalemleri arbitraj yazısında genel olarak anlatılıyor.

Tasarımı mevzuat da belirler. Kullanılabilecek platformlar ekibin yerleşik olduğu ülkenin mevzuatına ve platformların koşullarına bağlıdır; 6362 sayılı Kanun'un 99/A maddesine göre yurt dışında yerleşik platformların Türkiye'de yerleşik kişilere yönelik faaliyeti izinsiz kripto varlık hizmet sağlayıcılığı sayılır. Türkiye'de yerleşik bir ekip için senaryo bu yüzden SPK'nın Faaliyette Bulunanlar Listesi (yeni sekmede açılır)'ndeki ve API sunan platformları esas alır; listede yer almak yetkilendirme anlamına gelmez. Aşağıda geçen BtcTurk ve Paribu ayrıntıları, bu listedeki iki platformun resmi dokümanlarından alınmış örneklerdir; platform önerisi değildir. Türkiye'de faaliyet gösteren platformlarda ise III-35/B.2 sayılı Tebliğ'in 14. maddesine göre listelenen kripto varlıklar kaldıraçlı alınıp satılamaz, açığa satış ve ödünç işlemlerine konu edilemez. Bu yüzden senaryodaki model, iki platformda önceden tutulan envanterle çalışır: ucuz platformda alım, pahalı platformda eldeki varlığın satışı.

Çözüm mimarisi

Emir defterinin doğru tutulması

Her platformun senkronizasyon kuralı farklıdır ve bağlayıcılar bunları birebir uygular. Paribu dokümanı yöntemi adım adım yazar: önce orderbook-diff:btc_tl kanalına abone olunup fark mesajları tamponlanır, sonra GET /orderbook?market=btc_tl ile anlık görüntü alınır; seq değeri anlık görüntününkinden büyük olmayan mesajlar atılır, miktarı 0 gelen fiyat seviyesi silinir. seq bir artarak ilerlemiyorsa mesaj kaçırılmıştır ve defter yeni anlık görüntüyle yeniden kurulur. BtcTurk'te tam defter orderbook, değişiklikler obdiff kanalından gelir; CS alanı ardışık bir değişiklik numarasıdır ve doküman bu numara için şu anda bir denetim yapılmadığını yazar. Başka platformlarda sıra numarası yerine sağlama toplamı (checksum) kullanılabilir veya yeni bir anlık görüntü geldiğinde yerel defterin sıfırlanması istenebilir; bağlayıcı her platformun kendi kuralına göre yazılır ve testlerle sınanır. Defterin yapısı emir defteri yazısında anlatılıyor.

Bağlantı yaşam döngüsü de platforma göre yönetilir. 5 Kasım 2026 itibarıyla Paribu'nun beta durumundaki WebSocket API'sinde sunucu 20 saniyede bir ping gönderir, 30 saniye içinde pong gelmezse bağlantıyı kapatır ve doküman her kopmayı yeniden bağlanıp abone olma işareti saymayı ister. BtcTurk dakikada en fazla 15 bağlantı isteği kabul eder; aşımda yeni bağlantılar 60 saniye engellenir. Bağlayıcı kopmada defteri yeniden kurar; bağlantı ömrü sınırı olan platformlarda süre dolmadan yeni bağlantıyı açıp ardından eskisini kapatır.

Maliyet yığını nasıl hesaplanır?

Fırsat motoru en iyi alış ve satış fiyatına değil, hedef miktarın emir defterinde gerçekleşeceği hacim ağırlıklı ortalama fiyata (VWAP) bakar; kaymanın etkisi slippage yazısında anlatılıyor. Ücretler koda sabit olarak yazılmaz: hesaba özel komisyon oranları, ağ bazında çekim ücreti, çekim ve yatırmanın açık olup olmadığı ve gereken onay sayısı platform API'si sunuyorsa oradan okunur, sunmuyorsa yapılandırma dosyasında tutulup platformun ücret sayfasıyla düzenli olarak karşılaştırılır. BtcTurk'te yatırma ve çekmenin açık olup olmadığı /api/v2/server/exchangeinfo yanıtındaki depositDisabled ve withdrawalDisabled alanlarında görülür.

net = satış_VWAP × (1 − ücret_B) − alış_VWAP × (1 + ücret_A) − dengeleme_payı − güvenlik_payı

Varsayımsal örnekte görünen 0,40'lık farkın yaklaşık 0,05'i kalır; ekibin belirlediği eşik bunun üzerindeyse alarm üretilmez. Fırsatın birkaç ardışık güncelleme boyunca sürmesi ve iki defterin de güncel olması ayrıca şart koşulur. Transfer süresince fiyat riski taşındığı için dengeleme transferleri anlık fırsat hesabına değil, envanter planına girer.

Risk ve güvenlik kontrolleri

• Para çekme yetkisi yok: API anahtarları yalnızca okuma ve işlem yetkisiyle açılır ve sunucu IP'leriyle sınırlandırılır. Envanteri dengeleyen transferleri sistem önerir, ekip platform arayüzünden kendisi yapar.
• İstek limitleri: BtcTurk ve Paribu limit aşımında HTTP 429 ile Retry-After başlığını döndürür; bu süre dolmadan yeni istek gönderilmez. Paribu kalan ağırlığı X-Quota-Remaining başlığında bildirir. Bağlayıcılar bu bilgileri izler ve piyasa verisini REST yerine WebSocket'ten alır.
• Bayat veri koruması: Bir defter belirlenen süreden uzun güncellenmezse o platform fırsat hesabından çıkarılır.
• Bacak riski: İki emirden biri kısmen gerçekleşirse açık kalan miktar raporlanır ve müşterinin tanımladığı kapatma kuralı uygulanır. Sunucu hatası veya zaman aşımı yüzünden yürütme durumu belirsizse emir yeniden gönderilmez, durumu sorgulanır.
• Limitler ve acil durdurma: Platform başına envanter alt ve üst sınırı, emir başına azami tutar, günlük zarar limiti ve tüm yeni emirleri tek adımda kesen acil durdurma tanımlanır.
• Piyasa bütünlüğü: Sistem yalnızca gerçekleşmesi amaçlanan alım ve satım emirleri gönderir. Kendi kendine işlem (wash trading), iptal edilmek üzere emir girerek fiyatı yanıltma (spoofing) ve hacim şişirme piyasa bozucu eylemlerdir ve tasarımın dışındadır; III-35/B.2 sayılı Tebliğ'in 18. maddesi platformlardan bu tür eylemleri tespit edip önleyecek işlem esasları belirlemelerini ister.

Test ve canlıya geçiş

1. Kayıt ve yeniden oynatma: Canlı WebSocket akışları ham hâliyle kaydedilir ve yeniden oynatılarak defter mantığı sınanır; sıra boşlukları, bağlantı kopmaları ve checksum uyuşmazlıkları yapay olarak üretilir.
2. Yalnızca izleme: Sistem önce emir göndermeden çalışır; maliyet sonrası alarmların ne sıklıkla oluştuğu ve ne kadar sürdüğü raporlanır.
3. Test ortamı: Emir modülü, platformun test ortamı varsa orada, yoksa platformun belgelediği yanıtları taklit eden yerel bir sahte API ile sınanır. Bu ortamlarda bakiyeler sanaldır; ağ ve çekim bilgisi gibi veriler test edilemeyebilir.
4. Kontrollü canlıya geçiş: Küçük envanter ve düşük tutar limitleriyle başlanır; limitler kayıtlar incelendikten sonra ve müşteri onayıyla artırılır.

Teslim edilenler

• Platform bağlayıcıları ve normalleştirilmiş emir defteri servisi
• Ücret, transfer ve envanter parametrelerini içeren maliyet modeli
• Fırsat motoru, alarm kuralları ve izleme paneli
• İsteğe bağlı emir modülü, risk limitleri ve acil durdurma
• Ham akış kayıtları, yeniden oynatma test seti ve test raporu
• Anahtar yenileme, platform ekleme ve olay müdahalesi adımlarını içeren işletim kılavuzu

Hesap bakiyelerini ve pozisyonları tek ekranda izleme ihtiyacı için kripto portföy risk paneli senaryosuna bakılabilir.

Başarı nasıl ölçülür?

Başarı kârla değil, sistemin doğruluğu ve kontrol edilebilirliğiyle değerlendirilir; arbitraj işlemleri de zararla sonuçlanabilir ve hiçbir yazılım kazanç garantisi veremez. Ölçütler şunlardır:

• Yeniden oynatma testlerinde tüm sıra boşluklarının tespit edilmesi ve defterin yeniden kurulması
• Olay zamanı ile alarm zamanı arasındaki gecikmenin ölçülüp dağılım olarak raporlanması
• Alarmların, kayıtlı veriden hesaplanan maliyet sonrası farkla tutarlı olması
• Envanter ve tutar limitlerinin hiçbir test senaryosunda aşılmaması
• Acil durdurmanın tüm platformlarda yeni emirleri kestiğinin test edilmiş olması

Sık sorulan sorular

Arbitraj izleme sistemi kazanç garantisi verir mi?

Hayır. Sistem fiyat farklarını maliyetlerle birlikte hesaplar ve tanımlı kurallara göre alarm üretir. Strateji ve işlem kararları müşteriye aittir; işlemler zararla sonuçlanabilir.

Platformlar arası transferleri sistem mi yapar?

Hayır. Fincode para çekme yetkisi talep etmez; API anahtarları okuma ve işlem yetkisiyle sınırlıdır. Sistem envanter dengesizliğini raporlar ve transfer önerir, transferi ekip kendisi yapar.

Ekranda görülen fiyat farkı neden her zaman fırsat değildir?

İki bacağın işlem ücretleri, hedef miktarın defterde yarattığı kayma, transfer ücreti ve süresi ile gecikme riski düşüldüğünde fark çoğu zaman küçülür veya kaybolur.

Türkiye'de yerleşik bir ekip hangi platformlarla çalışabilir?

Bu, mevzuata ve platformun koşullarına bağlıdır. 6362 sayılı Kanun'un 99/A maddesine göre yurt dışında yerleşik platformların Türkiye'de yerleşik kişilere yönelik faaliyeti izinsiz sayılır; bu nedenle SPK'nın Faaliyette Bulunanlar Listesi'ndeki platformlar esas alınır ve seçim proje başında hukuki değerlendirmeyle birlikte yapılır. Listede yer almak yetkilendirme anlamına gelmez.

Kaynaklar

• Paribu API dokümanı: Orderbook Sync via Streams (seq, anlık görüntü ve fark akışı) (yeni sekmede açılır)
• Paribu API dokümanı: WebSocket API Overview (ping, yeniden bağlanma, beta) (yeni sekmede açılır)
• Paribu API dokümanı: Rate Limiting (ağırlık, 429, Retry-After) (yeni sekmede açılır)
• BtcTurk API dokümanı: WebSocket Models (orderbook, obdiff, CS) (yeni sekmede açılır)
• BtcTurk API dokümanı: Rate Limits (429, Retry-After, WebSocket bağlantı sınırı) (yeni sekmede açılır)
• BtcTurk API dokümanı: Get Exchange Info (yatırma ve çekme durumu) (yeni sekmede açılır)
• SPK: Faaliyette Bulunanlar Listesi (5 Kasım 2026'da kontrol edildi) (yeni sekmede açılır)
• 6362 sayılı Sermaye Piyasası Kanunu, md. 99/A (yeni sekmede açılır)
• Resmî Gazete: III-35/B.2 sayılı Kripto Varlık Hizmet Sağlayıcıların Çalışma Usul ve Esasları ile Sermaye Yeterliliği Hakkında Tebliğ (md. 14, 18) (yeni sekmede açılır)