FinTechSep 8, 20268 dk okuma

Emir Yolunun İçinde İşlem Öncesi Risk Kontrolleri

İşlem Öncesi RiskRisk YönetimiTrading AltyapısıEmir Yönetim Sistemi
Görsel yüklenemedi

Pozisyon limitleri, teminat, fat-finger sınırları ve bir kill switch, her emir gateway'den çıkmadan önce yanıt vermek zorundadır. Bu kontroller emir yolunun yanında değil içinde şöyle yaşar: bellekte hangi durum durur, ne artımlı olarak yeniden hesaplanır ve yeniden başlatmadan sonra ne olur. Önce kısıtlar gelir.

Bir emir gateway'e ulaşır. Borsaya çıkmadan önce, hesabın onu göndermeye izinli olup olmadığına bir şeyin karar vermesi gerekir. Bu karar, gayet yolunda olan ezici çoğunluk dahil her emirde çalışır; dolayısıyla maliyetini yalnızca reddedilenler değil, tüm normal trafik öder.

İlk adlandırılması gereken kısıt budur. Emir yoluna yerleştirilen bir risk kontrolü, emir girişine konan bir vergidir. Mühendislik sorusu, kontrolü nasıl akıllı yapacağımız değil; trader'ların hissetmeyeceği kadar küçük ve reddetmesi gerekenleri yine de reddedecek kadar dürüst nasıl yapacağımızdır.

Emir yoluna gerçekte ne aittir

Sıcak yol tam olarak tek bir soruyu yanıtlar: bu hesap hakkında şu an bildiklerimize göre bu emir hemen gönderilebilir mi. Bu soruyu yanıtlayan kontroller içeride kalır. Başka bir soruyu yanıtlayanlar dışarı çıkar.

  • Pozisyon ve risk limitleri - enstrümanda, grupta ve hesapta oluşacak pozisyonun yapılandırılmış sınırlarla karşılaştırılması
  • Teminat ya da alım gücü - mevcut teminat modeli altında hesabın emir için hâlâ yeri olup olmadığı
  • Fat-finger sınırları - emir büyüklüğü, nominal tutar ve bir referanstan fiyat uzaklığı; yazım hatasını borsadan önce yakalar
  • Enstrüman ve hesap durumu - işlemler durdurulmuş, hesap kısıtlı, yalnızca kapanış, ürün bu hesap için açık değil
  • Kill switch durumu - yukarıdaki her şeyi geçersiz kılan tek bir bayrak
  • Borsanın sağlamadığı yerlerde mükerrer emir ve kendi kendine işlem korumaları

Geri kalan her şey yolun yanında, aynı durum üzerinde ve emri tutmadan çalışır. Sıcak yolun uyguladığı limitleri besler, ama trader ile borsanın arasına girmez.

  • Portföy risk analitiği - senaryo çalışmaları, stres testleri, hesaplar arası korelasyonlu risk
  • Parametreler değiştiğinde teminat modelinin yeniden fiyatlanması ve tüm deftere dokunan her yeniden hesaplama
  • Sıcak yolun bilinçli olarak taşımadığı geçmişe ihtiyaç duyan gözetim ve örüntü tespiti
  • Raporlama, mutabakat ve bir veritabanıyla ya da dış servisle konuşan her şey
  • Doğası gereği daha yavaş bir saatle işleyen kredi ve karşı taraf değerlendirmesi

Ayrım çizgisi bir kategori değil, bir sorudur. Yolun içinde: bu emir çıkabilir mi. Yolun yanında: limitler ne olmalı. İkinci soruyu yanıtlayıp yine de emri bloklayan her şey, kontrol ne kadar önemli olursa olsun bir tasarım hatasıdır.

Pozisyon durumu nerede yaşar ve veritabanı neden yolda değildir

İşlem öncesi bir kontrolün ihtiyaç duyduğu durum - güncel pozisyonlar, açık emirler, kullanılan ve kullanılabilir teminat, limit yapılandırması - kararı veren sürecin belleğinde yaşar. Bir veritabanının önündeki önbellekte değil, bir ağ çağrısının ardında değil. Sürecin içinde.

Sebep yalnızca hız değil, gerçi bir sorgu yerel bir dizideki aramadan kat kat pahalıdır. Sebep doğruluktur. Veritabanı pozisyonu yazıldığı haliyle tutar. Risk kontrolünün ihtiyaç duyduğu pozisyon ise, az önce gönderilmiş ama henüz gerçekleşmemiş, onaylanmamış veya kalıcılaştırılmamış emirleri de içerir. Depolamadan okursanız, kendi akışınızın çoktan geride bıraktığı bir geçmişe karşı kontrol yaparsınız.

Pratikte bu, süreci herhangi bir düşük latency bileşeninin şekillendiği gibi şekillendirir:

  • Hesap başına tek yazıcı. Hesaplar risk örnekleri arasında parçalanır; böylece bir hesabın durumu için asla çekişme olmaz ve emir yolunda kilit alınmaz
  • Düz, önceden ayrılmış yapılar - oturum başında çözülen, hesap ve enstrüman id'siyle indekslenen sabit boyutlu diziler; emir başına kurulan string'ler üzerinde hash aramaları değil
  • Karar yolunda bellek ayırma yok, I/O yok ve bloklayan loglama yok; denetim kaydı bir kuyruk üzerinden başka bir iş parçacığına devredilir
  • Yeniden başlatmadan değişen yapılandırma, bütün ve değişmez bir anlık görüntü olarak yerine konur; böylece kontrol asla yarı güncellenmiş bir limiti okumaz

Veritabanı, pozisyonun kaydedildiği yerdir. Pozisyonun bilindiği yer değildir.

Tam geçiş değil, artımlı yeniden hesaplama

Bir hesabın riskinin ve teminatının baştan hesaplanması, her pozisyonu ve her açık emri dolaşır. Bu maliyet defterin büyüklüğüyle birlikte artar; yani risk kontrolü tam da en çok işlem yapan müşteriler için yavaşlar. Bu yüzden sıcak yol yeniden hesaplamaz. Bir delta uygular.

Hesap, işleyen toplamlar taşır - enstrüman ve grup bazında net ve brüt risk, kullanılan teminat, yolda olan nominal tutar. Gelen bir emir bu toplamlarda küçük bir değişiklik üretir, değişen değerler limitlerle karşılaştırılır ve emir kabul ya da reddedilir. İş, portföyle değil emirle orantılıdır.

  • Gönderimde emrin en kötü durum etkisi toplamlara karşı rezerve edilir; böylece yolda olan iki emir aynı kalan boşluğa birlikte sığamaz
  • Ret, iptal veya sona ermede rezervasyon serbest bırakılır; gerçekleşmede rezervasyonun yerini gerçekleşen pozisyon değişimi alır
  • Kısmi gerçekleşmeler bunun her iki tarafını tek adımda ayarlar ve bu tür motorlardaki hataların çoğu aslında burada yaşar
  • Netleştirme ve gruplama kuralları emir başına değil, enstrüman yüklenirken çözülür; böylece delta bir avuç aritmetik işlemden ibarettir

Tam yeniden hesaplama yine de yapılır - belirli aralıklarla, teminat parametreleri değiştiğinde ve artımlı sonuca karşı periyodik bir öz denetim olarak. Yolun dışında, bir kopya üzerinde çalışır ve sonucu ya yerine konur ya da bir tutarsızlık olarak bildirilir. Gerçek durumdan sessizce sapan artımlı bir durum, hiç kontrol olmamasından daha kötüdür; bu yüzden karşılaştırma isteğe bağlı değildir.

Kurduğumuz risk yolunda ölçüldüğünde, işlem öncesi kontrolün kendisi <1 ms içinde tamamlanır. Bu rakam, bellekteki durum üzerindeki kararı kapsar; bir emrin istemciden borsaya gidip geri dönen tüm yolculuğunu değil.

Kill switch ayrı bir yoldur

Bir kill switch tam da bir şeyler zaten ters gittiğinde kullanılır. Bu da onu, kendisi bozuk olabilecek mekanizmanın üzerine kurmayı dışlar. Kendi kuralları olan ayrı bir yoldur.

  • Kontrolün en başında, pozisyon durumuna, teminata ya da enstrüman verisine dokunulmadan önce okunan tek bir atomik bayraktır - böylece bunlar bayat, eksik veya bozuk olsa bile çalışır
  • Birkaç bağımsız tetikleyiciyle kurulur: bir operatör eylemi, otomatik bir koşul, risk durumunun bağlı olduğu piyasa verisi ya da gerçekleşme akışının kesilmesi
  • Kapalı konumda arızalanır. Risk süreci geçerli bir duruma sahip olduğunu doğrulayamazsa, gateway switch devredeymiş gibi davranır
  • Kapsamları vardır - tüm firma, bir masa, bir hesap, bir strateji - çünkü yalnızca her şeyi durdurabilen bir switch çok geç kullanılır
  • Devreye almak tek bir eylem ve tek bir onaydır, bir yapılandırma dağıtımı değil; devreden çıkarmak ise bilinçlidir ve her zaman kayda geçer

Yeni emirleri durdurmak kolay yarısıdır. Zor yarısı, switch'in borsada zaten bekleyen emirlere ne yaptığıdır: gönderim yolu kapalıyken kotasyonları çekmek ve açık emirleri iptal etmek mümkün olmalıdır. Bu iptal yolu kendi testlerini hak eder, çünkü normal bir günde değil en kötü günde çalıştırılır.

Yeniden başlatma ve durumun nasıl geri geldiği

Bellekteki durum, kalıcı bir kaydın türetilmiş bir görünümüdür. Bir yeniden başlatmayı atlatılabilir kılan da budur. Risk durumunu değiştiren her olay - kabul edilen bir emir, serbest bırakılan bir rezervasyon, uygulanan bir gerçekleşme, değiştirilen bir limit, devreye alınan switch - aşağı akışta işlenmeden önce yerel makinedeki bir journal'a eklenir.

  • Başlangıçta süreç, toplamları yeniden kurmak için journal'ı replay eder, ardından pozisyonlar ve açık emirler için borsa ve takas drop copy'siyle mutabakat yapar
  • Mutabakat tamamlanana kadar hesap işleme açık değildir. Pozisyonu hâlâ çözmeye çalışırken emir kabul eden bir risk motoru, risk motoru değildir
  • Replay ile elde edilen durum ile borsanın görünümü arasındaki bir uyuşmazlık o hesabı durdurur ve alarm üretir; asla taraflardan biri sessizce tercih edilerek çözülmez
  • Bir hot standby aynı journal'ı takip eder; böylece failover soğuk bir replay yerine sıcak bir durumu geri getirir ve yedek, teoride değil düzenli olarak devreye alınarak doğrulanır

Kurtarma süresi o zaman defterin büyüklüğüne değil, journal uzunluğuna ve drop copy'nin erişilebilirliğine bağlıdır; her bilinmeyenin hata modu ise aynıdır: hesapta işlem yapmayı reddet.

Bu tasarımın size vermediği şeyler

Dürüst sınırları açıkça söylemeye değer, çünkü bu mimarinin size uyup uymadığını onlar belirler:

  • Kontrol, ancak gerçekleşme akışı kadar doğrudur. Drop copy ya da icra raporları gecikirse risk olduğundan az görünür; doğru tepki, bayat durum üzerinden işleme devam etmek yerine ihtiyatlı limitlere geri çekilmek ya da switch'i devreye almaktır
  • Gerçekten toplanamaz olan portföy teminat modelleri artımlı değerlendirmeye direnir. İşe yarayan, yol üzerinde ihtiyatlı bir artımlı sınır ile yol dışında tam bir modeldir; bedeli ise tam modelin izin vereceği bazı emirlerin reddedilmesidir
  • Switch sizi piyasaya karşı değil, kendi akışınıza karşı korur. Halihazırda tuttuğunuz pozisyonlardaki bir boşluğu ya da kaymayı önleyemez
  • Süreç içi durum, risk motoru ile emir gateway'inin kaderini paylaşması demektir. Bu size latency kazandırır ve ikisini bağımsız ölçekleme imkânına mal olur
  • Hesaba göre tek yazıcılı parçalama, hesaplar arası limitleri zorlaştırır; firma genelindeki kontroller ise kendi bayatlığı olan daha yavaş bir toplama katmanı gerektirir
  • Veritabanına dayalı bir kontrolden daha fazla operasyonel iş demektir: journal'lar, mutabakat, yedeği devreye alma tatbikatları. Emir girişi latency'ye duyarlı değilse, bu karmaşıklığı satın almaya değmez

amBrain, brokerlar ve prop firmalar için bu tür işlem öncesi risk yolları kurar; sıcak yollar Rust ile yazılır. Ekip 2019'dan beri Erivan, Ermenistan'dan trading altyapısı üzerinde çalışıyor.

Bunu kurmak için desteğe mi ihtiyacınız var?

Mühendislik ekibimiz FinTech çözümlerinde uzmanlaşmıştır. Projenizi nasıl hayata geçirebileceğimizi konuşalım.

İlgili Yazılar

Görsel yüklenemedi
FinTech
Sep 8, 20269 dk okuma

Rust'ta Matching Engine Tasarımı: GC Duraklamaları Olmadan Price-Time Priority

Yazıyı oku
Görsel yüklenemedi
FinTech
Apr 27, 202618 dakikalık okuma

Trading Altyapısı Raporu 2026: Kazakistan, Özbekistan, Ermenistan, Gürcistan

Yazıyı oku
Görsel yüklenemedi
FinTech
Mar 14, 202612 dakikalık okuma

Milisaniyeler Neden Önemli: Trading Platformlarında Gecikmeye Basit Bir Rehber

Yazıyı oku