Finans Sektörü HPC: Risk ve Quant Hesaplama
/ Sektörler

Finans Sektörü HPC: Risk ve Quant Hesaplama

Düşük gecikmeli Monte Carlo simülasyonu, risk hesaplama ve algoritmik trading altyapısı.

Bankacılık, portföy yönetimi ve sigortacılık alanlarında hesaplama kapasitesi rekabet avantajına doğrudan dönüşür. Piyasa riski ölçümü, türev fiyatlama, kredi skoru modellemesi ve düzenleyici stres testleri; standart sunucu altyapısını saniyelerce değil, saatlerce meşgul eder. Bu gecikme hem iş kararlarını yavaşlatır hem de düzenleyici son tarihlerle çatışır. Yüksek başarımlı hesaplama (HPC), finans kurumlarına bu hesapları gerçek zamana yakın çözme kapasitesi sunar.

Finansta HPC Neden Gerekli?

Finans sektörünün hesaplama ihtiyaçları üç temel baskıdan kaynaklanır:

  1. Düzenleyici gereksinimler: Basel IV, FRTB (Fundamental Review of the Trading Book) ve BDDK stres testi gereksinimleri kapsamında bankalar günlük bazda on binlerce senaryo hesaplamak zorundadır. Hesaplamanın denetim saatine yetişmesi yasal zorunluluktur.
  2. Piyasa riski yönetimi: Volatilite rejim değişimleri sırasında risk metriklerinin saatlik — hatta anlık — güncellenmesi gerekir. Gece batch’ına kalan hesaplamalar bir sonraki gün sabahı geçerliliğini yitirmiş olur.
  3. Alpha üretimi: Algoritmik trading ve kuantitatif strateji geliştirmede model backtesting döngüsünü hızlandırmak, daha fazla strateji denemek ve piyasaya daha erken girmek anlamına gelir.

Bu üç baskının kesiştiği noktada HPC altyapısı iş sonucuna doğrudan etki eden bir teknoloji haline gelir.

Finans HPC’nin Temel İş Yükleri

Monte Carlo Simülasyonları

Türev fiyatlama ve piyasa riski (VaR, CVA, XVA) hesaplamalarının büyük çoğunluğu Monte Carlo yöntemine dayanır. Tipik bir banka gece batch’ında 1 milyon ile 100 milyon arası yol (path) simüle eder. Bu iş yükleri aşırı derecede paralel (embarrassingly parallel) yapıdadır: her path bağımsız hesaplanır ve GPU mimarisi bu hesaplama modeline mükemmel uyum sağlar.

Yaygın araçlar:

  • QuantLib: Açık kaynak türev fiyatlama kütüphanesi; CPU çok çekirdekli ve GPU desteği mevcut
  • NVIDIA cuQuantLib / cuFFI: CUDA ile GPU hızlandırmalı Monte Carlo
  • OpenCL / SYCL tabanlı özel motorlar: Kurumsal bankaların geliştirdiği in-house fiyatlama motorları
  • Python ekosistemi: NumPy, CuPy, JAX — prototipleme ve araştırma için

Portföy Optimizasyonu ve Risk Faktörü Modelleme

Modern portföy teorisi uygulamaları büyük kovaryans matrislerinin ters çözümünü gerektirir. 10.000+ varlıklı portföylerde bu işlem matris boyutuyla kübik ölçeklenir ve tek bir sunucuda saatler sürer. LAPACK/ScaLAPACK tabanlı doğrusal cebir kütüphaneleri çok düğümlü (multi-node) dağıtık hesaplamayla bu süreyi dakikalara düşürür.

  • BLAS/LAPACK/ScaLAPACK: Doğrusal cebir; InfiniBand üzerinde düğümler arası paralel çözüm
  • MOSEK / Gurobi: Kısıtlı portföy optimizasyonu (ikinci dereceden programlama)
  • cuBLAS / cuSOLVER: GPU tabanlı matris işlemleri; büyük kovaryans çözümü

Kredi Riski ve Makine Öğrenmesi Modelleri

Kredi skoru, temerrüt olasılığı (PD) ve kayıp tahmini (LGD) modellerinde makine öğrenmesi yöntemlerinin kullanımı artmaktadır. XGBoost, LightGBM ve sinir ağı tabanlı modellerin eğitimi GPU ile 10–50× hızlanır. Aynı zamanda stres testi senaryolarında bu modellerin milyonlarca kredi için toplu çıktı üretmesi gerekmektedir.

  • XGBoost / LightGBM: GPU destekli gradient boosting; kredi ve sahtecilik tespiti
  • TensorFlow / PyTorch: Derin öğrenme modelleri; CUDA zorunlu
  • RAPIDS cuML: GPU tabanlı scikit-learn uyumlu kütüphane; büyük veri seti üzerinde ML

Algoritmik Trading ve Backtesting

Kuantitatif strateji ekipleri yeni bir faktör keşfettiğinde onu önce tarihsel veriye karşı test etmek ister. 5–10 yıllık tick veri üzerinde binlerce parametre kombinasyonunun taranması (parametre optimizasyonu / grid search) CPU kümesiyle gün alırken GPU destekli paralel backtesting çerçeveleri bu süreyi saatlere düşürür.

  • Backtrader / Zipline: Python tabanlı backtesting; çok çekirdekli paralel çalıştırma
  • Vectorbt: GPU/NumPy hızlandırmalı vektörel backtesting; büyük ölçekli parametre taraması
  • Kafka + Spark Streaming: Gerçek zamanlı piyasa verisi işleme ve sinyal üretimi

Düzenleyici Raporlama: FRTB ve Stres Testleri

FRTB kapsamındaki Internal Models Approach (IMA) ve Standardised Approach (SA) hesaplamaları yüz binlerce senaryo içerir. BDDK ve SPK’nın zorunlu kıldığı düzenleyici stres testlerinde tüm portföyün belirlenen kötü senaryo altında yeniden fiyatlanması gerekir. Bu iş yükleri hem hesaplama yoğun hem de zaman kısıtlıdır.

Tipik Finans HPC Yapılandırması

Login / Risk Yönetim Sunucuları (2× yedekli)
├── CPU Hesaplama Düğümleri (8–24 adet)
│   └── 2× AMD EPYC 9654 (96 çekirdek), 512 GB DDR5
│       (Portföy optimizasyonu, stres testi batch, FRTB)
│       Ağ: HDR InfiniBand 200 Gb/s (düşük gecikme MPI)
│
├── GPU Hesaplama Düğümleri (4–8 adet)
│   └── 2× Intel Xeon Gold + 4× NVIDIA A100 80 GB
│       (Monte Carlo, ML model eğitimi, backtesting)
│       (veya NVIDIA H100 SXM5 — maksimum performans)
│
├── Yüksek Bellek Düğümleri (2 adet)
│   └── 2 TB DDR5 — büyük kovaryans matrisleri, in-memory veri
│
└── Depolama Katmanı
    ├── NVMe All-Flash (scratch): BeeGFS — tick veri I/O
    ├── SAS/SATA Paralel FS: Tarihsel piyasa verisi
    └── Şifreli Yedekleme: KVKK kapsamında müşteri verisi arşivi

Ağ gecikmesi: Risk hesaplama iş yüklerinde düğümler arası gecikme kritik değildir ancak gerçek zamanlı trading altyapısında kernel bypass (RDMA, DPDK) ile mikrosaniye mertebesinde gecikme mümkündür.

Veri Güvenliği, KVKK Uyumu ve Lokasyon

Finansal veriler hem rekabetçi değer hem de düzenleyici kısıtlar açısından özel kategori verilerdir.

KVKK ve BDDK gereksinimleri:

  • Müşteri finansal verilerinin Türkiye sınırları içinde işlenmesi ve saklanması zorunludur. Yurt dışı bulut sağlayıcılara aktarım ek hukuki risk ve BDDK onay süreci gerektirir.
  • Mevasis altyapısı Türkiye’de konumlandırılmış; veri hiçbir noktada yurt dışı aktarımına tabi tutulmaz.
  • Depolama katmanında AES-256 şifreleme varsayılan standarttır.
  • Erişim denetim logları (audit trail) düzenleyici denetim gereksinimlerini karşılayacak biçimde tutulur.

İzolasyon ve çok kiracılı mimari: Farklı departmanlar veya bağlı kuruluşlar arasında proje bazlı ağ izolasyonu (VLAN), kaynak kotaları ve ayrı depolama namespace’leri ile veri sızıntısı riski en aza indirilir.

Performans Karşılaştırması: Tipik İş Yükü Örnekleri

İş YüküStandart Sunucu16× CPU Düğümü4× A100 GPU
10 M path Black-Scholes MC~45 dak~4 dak~25 sn
5.000 varlık kovaryans tersi~3 saat~18 dak~6 dak
FRTB SA tam portföy yeniden fiyatlama~8 saat~40 dak~15 dak
XGBoost kredi modeli eğitimi (10 M kayıt)~2 saat~20 dak~4 dak
5 yıllık tick veri backtesting (1.000 param)~12 saat~55 dak~18 dak

Değerler temsili referans hesaplamalarına dayanmaktadır; gerçek performans iş yükü yapısına ve yapılandırmaya göre değişir.

İş Scheduler ve Orkestrasyon

Finans HPC ortamlarında batch iş yönetimi kritik önem taşır. Gece kapanış batch’ının sırası, önceliği ve kaynak tahsisi düzenleyici son tarihlere uyumu doğrudan etkiler.

  • Slurm Workload Manager: Finans HPC’sinde standart; öncelik kuyrukları ve SLA tabanlı zamanlama
  • Platform LSF: Kurumsal bankacılık ortamlarında yaygın; IBM destekli
  • Apache Airflow: Python iş akışı orkestrasyonu; backtesting ve model eğitim pipeline’ları için

Mevasis Slurm kurulumu, konfigürasyonu ve finansal iş yüklerine özel kuyruk tasarımı konusunda uzmanlık sağlar.

Mevasis Finans HPC Hizmetleri

Mevasis, finans kurumlarına yönelik anahtar teslim HPC altyapısı tasarımı, kurulumu ve yönetimi hizmetleri sunar. Risk hesaplama pipeline’larının HPC’ye taşınması, Monte Carlo motorlarının GPU’ya uyarlanması ve Slurm tabanlı batch zamanlaması konularında danışmanlık kapsamımız içindedir.

Finans sektörüne özgü hesaplama gereksinimlerinizi değerlendirmek için uzman ekibimizle görüşün.

İletişime Geçin →


Sıkça Sorulan Sorular

Monte Carlo simülasyonları için GPU mu CPU mu kullanılmalı? Path sayısı 1 milyon ve üzerindeyse GPU açık ara daha verimlidir. NVIDIA A100 üzerinde Black-Scholes Monte Carlo, eşdeğer CPU kümesine kıyasla 20–50× hızlanma sağlayabilir. CPU kümesi yine de portföy optimizasyonu ve MPI tabanlı dağıtık hesaplamalar için gereklidir; hibrit mimari optimum sonuç verir.

FRTB hesaplamaları için altyapı nasıl boyutlandırılmalı? Portföy büyüklüğü ve senaryo sayısı belirleyicidir. Tipik bir orta ölçekli banka için 8–16 CPU düğümü ve 4× GPU düğüm, gece batch’ını 4–6 saatte tamamlamak için yeterlidir. Kesin boyutlandırma için mevcut hesaplama sürelerinizi ve hedef pencereyi paylaşmanız yeterli; Mevasis ekibi ayrıntılı analiz yapar.

Müşteri verisi yurt dışı buluta çıkabilir mi? BDDK’nın “Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri” yönetmeliği kapsamında bankacılık verilerinin kritik bölümünün yurt içinde tutulması esastır. KVKK ise müşteri finansal verilerinin yurt dışı aktarımı için açık rıza veya KVKK Kurulu kararı şartı getirir. On-premise ya da Türkiye’de konumlu yönetilen altyapı bu riskleri ortadan kaldırır.

Algoritmik trading altyapısında gecikme ne kadar önemli? İstatistiksel arbitraj ve yüksek frekanslı stratejiler için mikrosaniye gecikme kritiktir; bu tür sistemler özel ko-lokasyon ve FPGA çözümleri gerektirir. Orta frekanslı stratejiler ve backtesting altyapısı için standart HPC gecikmesi yeterlidir. Mevasis ikinci kategori için optimize çözümler sunar.

Hesaplama altyapısı olmayan bir ekip nereden başlamalı? Öncelikle mevcut batch hesaplamalarınızın süre ve kaynak profilini çıkarmanızı öneririz. Mevasis iş yükü değerlendirme hizmeti ile hangi hesaplamaların GPU’ya, hangilerinin CPU kümesine, hangilerinin hafıza optimizasyonuna ihtiyaç duyduğunu analiz eder; ardından aşamalı geçiş planı oluşturur.

← Tüm Sektörler