Bankacılık Operasyonları & Kredi Yaşam Döngüsü · 07
Veri Akışı & Tek Gerçek Kaynak

veri hareket eder ve dönüşür

Önceki sayfada gördün: bir kredi 12 farklı sistemde yaşıyor. Ama bu sistemler birbirleriyle nasıl konuşuyor? CBS'deki bir güncelleme Risk DWH'a nasıl ulaşıyor — ve bu yolculukta ne kayboluyor, ne bozuluyor?

CS geçmişiyle bu sayfayı okursan tanıdık bir alan: ETL pipeline'ları, batch job'lar, schema mapping, data lineage. Ama bankacılık bağlamında bu kavramlar risk ölçümüne, muhasebe kaydına ve regülatör raporlamasına doğrudan bağlı. Pipeline hatası sessizce büyür ve ancak denetimde ya da model backtesting'de ortaya çıkar.

Bu sayfada veri akışının nasıl çalıştığını, nerede kırıldığını ve "doğru" veriyi bulmak için ne sorman gerektiğini ele alacağız.

ETL pipeline — normal mi, hatalı mı?

Aşağıdaki pipeline bir ticari kredinin veri akışını gösteriyor. Normal akış ile farklı hata senaryolarını karşılaştır. Her düğüme tıklayarak detayları gör.

Kaynak sistemler
CBS
✓ Gerçek zamanlı
gece 02:00
ETL / Batch
✓ 02:00'de çalıştı
T+1 sabah
Risk DWH
✓ Güncellendi
T+1 sabah
ECL Engine
✓ Hesaplandı
Çıktı sistemleri
GL / Muhasebe
✓ ECL yansıdı
MIS / Raporlama
✓ Dashboard güncellendi
ay sonu
BDDK Raporu
✓ Ay sonu gönderildi
⚠️
Hata senaryosu modunda ETL'nin başarısız olduğu durumu gör. Downstream sistemlerin hiçbiri güncellenmedi — ama hata sessiz. Risk ekibi sabah eski veriyle çalışmaya başladı, fark etmeden.

batch vs gerçek zamanlı

Bankacılık sistemlerinin büyük çoğunluğu hâlâ batch (toplu) işleme dayanıyor. Gece çalışan ETL, gün sonu kapanışları, aylık snapshot'lar. Gerçek zamanlı entegrasyon istisnai, maliyetli ve karmaşık.

🔄
Batch İşleme
  • Basit, öngörülebilir, debug edilebilir
  • Sistem yüküne göre planlanabilir (gece saatleri)
  • Bütünlük kontrolü kolaylaşır (tam set beklenir)
  • T+1 gecikme — gün içi hareketler görünmez
  • Batch başarısız olursa tüm gün eski veri
  • Büyük veri hacimlerinde pencere daralır
⚡
Gerçek Zamanlı / Streaming
  • Anlık veri — gün içi karar desteği mümkün
  • Limit aşımı anında tespit edilebilir
  • Erken uyarı sinyalleri hızlanır
  • Altyapı maliyeti yüksek (Kafka, event streaming)
  • Kısmi güncelleme riski (partial state sorunları)
  • Hata yönetimi çok daha karmaşık
Çoğu Türk bankasında Risk DWH hâlâ gece batch'i. Sabah 08:00'de çalışmaya başlayan risk analistleri dünün kapanış verisini görüyor. Gün içi büyük bir çekim olursa — limit aşımı dahil — ancak ertesi sabah görünür. Bu "gecikme penceresi" validasyon açısından bir risk modeli tasarım sorusuna dönüşür: model girdileri ne sıklıkla güncellenmeli?

mapping hataları — gerçek senaryolar

ETL'de veri bir sistemden diğerine taşınırken dönüştürülür: sütun isimleri değişir, kodlar çevrilir, agregasyonlar yapılır. Bu dönüşümlerin her adımı potansiyel bir hata noktası. Her senaryoya tıkla.

Temerrüt tanımı uyuşmazlığı
Kritik
+
CBS tanımı
DPD ≥ 90 gün → "gecikmiş"
Temerrüt flag'i ayrı bir alan
≠
Risk DWH tanımı
DPD ≥ 90 → otomatik temerrüt
"Unlikeliness" kriter dahil değil
Model etkisi: PD modelinin eğitim setindeki "default" etiketi yanlış. Bazı temerrütler kaçırılıyor, bazı sağlıklı krediler temerrüt sayılıyor. Gini ve KS metrikleri yanıltıcı görünür.
Sektör kodu çevirme hatası
Kritik
+
CBS kodu
Sektör kodu: "15"
CBS'de: Tekstil üretimi
→
Risk DWH kodu
ETL çevirme tablosu güncel değil
Risk DWH'da: "15" = Gıda sanayi
Model etkisi: Segmentasyon yanlış. Tekstil müşterisi gıda sektörü PD modeliyle değerlendiriliyor. Sektör konsantrasyon raporu yanıltıcı. Regülatör bulgusu riski var.
Para birimi normalizasyon hatası
Orta
+
CBS kaydı
Limit: 500.000 USD
CBS kur: işlem günü kuru
→
Risk DWH kaydı
TL karşılığı: ay sonu kur
Kur farkı: %4 sapma
Model etkisi: EAD TL bazında yanlış hesaplanıyor. Portföy konsantrasyon limitleri TL bazında izleniyorsa limit aşımı yanlış tespit edilebilir. Yüksek enflasyon döneminde kur sapması kritikleşir.
Tarih alanı yorumlama farkı
Orta
+
CBS "temerrüt tarihi"
İlk gecikme tarihi
(DPD sayacının başladığı gün)
≠
Risk DWH "temerrüt tarihi"
90. gün aşıldığında
sistemin flag'i güncellediği tarih
Model etkisi: LGD hesabında başlangıç noktası 90 gün kayıyor. Tüm recovery stream'i 3 ay geride → discounting hesabı sistematik olarak hatalı. Gerçekleşen LGD olduğundan yüksek hesaplanır.
Null / boş değer yorumlama farkı
Düşük-Orta
+
CBS'de boş alan
Teminat değeri: NULL
Anlam: "teminat yok"
→
ETL sonrası
NULL → 0 dönüştürüldü
LGD hesabında: 0 TL teminat
Model etkisi: "Teminat yok" ile "teminat 0 TL" aynı şey değil. Başka sistemlerde teminat bilgisi olabilir ama bulunamıyor. LGD gereksiz yere yüksek hesaplanıyor — karşılık şişiyor.
Mapping hataları genellikle sessizdir — sistem hata vermez, veri akar, hesaplamalar çalışır. Hata ancak backtesting'de ya da reconciliation'da ortaya çıkar. Bu yüzden validasyon metodolojisi veri kalitesi testini ayrı bir başlık olarak ele alır.

"doğru" veriyi bulmak — hangi sisteme güvenilir?

"Source of truth nedir?" sorusu bankacılıkta yanıtı basit olmayan bir sorudur. Cevap veriye ve amaca göre değişir. Aşağıdaki sorular "doğru" kaynağa ulaşmak için rehber olarak kullanılabilir.

1
Veri muhasebe amaçlı mı kullanılacak?
GL / ERP'ye git. IFRS standartlarına göre kayıt altındaki tutarlar burada. ECL karşılığı ve net carrying amount GL'den okunmalı. Risk DWH'dan muhasebe kararı verilmez.
2
Veri risk modeli eğitimi / backtesting için mi?
Risk DWH — ama CBS ile karşılaştır. Risk DWH türetilmiş veri. Temerrüt tarihi, DPD, rating gibi kritik alanlar CBS'den doğrulanmalı. Fark varsa hangisinin doğru olduğu belgelenmiş olmalı.
3
Anlık (gün içi) bakiyeye ihtiyaç var mı?
CBS'den doğrudan sorgu. Risk DWH dünün snapshot'ı. Gerçek zamanlı exposure için CBS'e erişim gerekli. Çoğu analist buna erişemez — bu başlı başına bir yönetim riski.
4
Teminat değeri doğru mu?
Teminat yönetim sistemine git, ekspertiz raporunu gör. Risk DWH'daki teminat değeri CMS'den kopyalanmış — ve güncelleme frekansı düşük olabilir. En güncel değer CMS'de ya da fiziksel ekspertiz raporunda.
5
Gerçekleşen recovery (LGD için) nereden okunur?
Tahsilat sisteminden, GL ile mutabık olarak. Tahsilat sistemi operasyonel — her tahsilatı kaydeder. GL muhasebe kaydını yapar. İkisi tutarlıysa Recovery = GL'deki nakit girişi. Tutarsızlık varsa önce reconciliation.

veri kalitesinin 6 boyutu

Bir veri setinin "iyi" olup olmadığını değerlendirmek için tek bir metrik yok. Aşağıdaki 6 boyut, validasyon sürecinde veri kalitesi değerlendirmesinin standart çerçevesini oluşturuyor.

✅
Eksiksizlik
Kritik alanlar boş mu? Zorunlu sütunlarda null oranı kabul edilebilir mi?
Teminat değeri: %12 null — kabul edilebilir mi?
🎯
Doğruluk
Veri gerçeği yansıtıyor mu? Farklı kaynaklarla çapraz doğrulama yapıldı mı?
DPD: CBS'de 45, Risk DWH'da 38 — hangisi doğru?
🔗
Tutarlılık
Farklı sistemler aynı kavramı aynı şekilde mi tanımlıyor?
Temerrüt tanımı: CBS ≠ Risk DWH ≠ regülatör tanımı
⏱
Güncellik
Veri ne kadar eski? Güncelleme frekansı kullanım amacına uygun mu?
Teminat değeri 18 ay önce güncellendi — gayrimenkul için stale.
🔍
İzlenebilirlik
Veri nereden geldi, nasıl dönüştürüldü? Data lineage belgelenmiş mi?
ETL kodu dokümante değilse → "bu sayı nereden geliyor?" sorulanamaz.
🔒
Bütünlük
Kayıtlar silinmiş ya da duplicate mı? Referans bütünlüğü sağlanmış mı?
Recovery kayıtları tahsilat sisteminde var ama Risk DWH'da yok — silme mi, eşleşme hatası mı?
Sayfa 09 (Mutabakat & Veri Kalitesi), bu 6 boyutu reconciliation süreciyle birleştirerek sistematik bir kontrol çerçevesine dönüştürüyor. Bu sayfayı anladıysan sayfa 09 çok daha kolay oturur.
Mehmet Yığılı · Bankacılık Operasyonları & Kredi Yaşam Döngüsü · 07 / 12 · © 2026