Bankacılık Operasyonları & Kredi Yaşam Döngüsü · 07
Veri Akışı & Tek Gerçek Kaynak
Gözden geçirme: 14 Temmuz 2026Kapsam: Kavramsal banka mimarisi; sistem adları ve çalışma saatleri kuruma göre değişir.Okuma kuralı: Simülatörler öğretici sadeleştirmedir; düzenleyici hesap değildir.
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.
aynı pozisyon, farklı saat
Timing mismatch'i en somut gören yer burası. Senaryo: bir müşterinin çekilmiş bakiyesi 1,0M TL. Bugün saat 14:00'te 2,0M daha çekti → gerçek bakiye artık 3,0M. Aşağıdaki saati ilerlet — her sistem bu gerçeği kendi yenileme ritmiyle ne zaman gösteriyor?
RDARR / zamanındalık bağlantısı: Aynı krediye aynı anda bakan altı sistemden bazıları "3,0M", bazıları hâlâ "1,0M" diyor — hiçbiri yalan söylemiyor, sadece as-of tarihleri farklı. BCBS 239'un timeliness prensibi ve ECB RDARR kılavuzu tam da bu farkın bilinçli yönetilmesini ister: hangi raporun hangi kesim saatiyle üretildiği belgeli olmalı. "Bugünkü EAD" derken hangi sistemin saatini kastettiğini bilmiyorsan, mutabakat (Modül 09) baştan kayıptır.
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?" sorusu yanıtlanamaz.
🔒
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.
Birincil kaynaklar ve kapsam
Metin bu kaynaklar üzerinden 14 Temmuz 2026 tarihinde kontrol edildi. AB kuralları Türkiye’de doğrudan uygulanan BDDK kuralları gibi okunmamalıdır.