Bankacılık Operasyonları & Kredi Yaşam Döngüsü · 06
Veri Nerede Doğar — Sistemlere Genel Bakış
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.
neden sistem bilgisi önemli?
Bir kredi riski modeli için veri hazırlıyorsun. "Temerrüt tarihi" sütununu çekiyorsun — ama hangi sistemden? Core banking'den mi, risk veritabanından mı, yoksa tahsilat sisteminden mi? Ve bu üçü her zaman aynı tarihi gösteriyor mu?
CS geçmişinden bankacılığa geçen birinin ilk büyük sürprizi budur: tek bir veritabanı her alan için mutlak gerçek kaynak değildir. Doğru tasarım, her veri öğesi için yetkili kaynağı, sahibini, kesim zamanını ve dönüşüm lineage’ını açıkça tanımlar. Her sistem farklı bir amaca hizmet için tasarlandı, farklı bir zamanda güncelleniyor ve farklı iş biriminin ownership'inde.
Bu sayfada sistemleri katman katman ele alacağız. Her sistemin ne tuttuğunu, neye beslediğini ve validasyon açısından hangi riski taşıdığını gör.
sistem haritası — bir kartı seç
Her sisteme tıkla — ne tutar, neyi besler ve validasyon açısından hangi riski barındırır?
📋
Kredi Başvuru Sistemi
LOS
🔍
Kimlik Doğrulama & Uyum
KYC / AML
↓ onay sonrası kullandırım
🏦
Core Banking Sistemi
CBS
🏠
Teminat Yönetim Sistemi
CMS
↓ işlem verisi aşağı akar
⚠️
Risk Veri Ambarı
Risk DWH
📒
Genel Muhasebe
GL / ERP
📊
IFRS 9 Hesaplama
ECL Engine
↓ raporlama & düzenleyici
🏛
Düzenleyici Raporlama
BDDK / RegRep
⚖️
Tahsilat Sistemi
Collections
tek işlem — kaç sisteme dokunur?
Senaryo: Kurumsal müşteri 5M TL'lik rotatif limitinin 2M TL'sini çekiyor. Bu tek hareket kaç sisteme yazılıyor, hangi sırayla ve hangi gecikmeyle?
Ne yazılıyor?
2M TL drawn, müşteri hesabı alacaklandırıldı. Limit bakiyesi 5M → 3M undrawn olarak güncellendi. Faiz tahakkuku başladı.
Risk notu
Bu kayıt "source of truth" adayı. Ama tek başına yeterli değil — muhasebe ve risk sistemleri henüz bilmiyor.
Muhasebe kaydı
Kredi alacaklar borçlandırıldı, nakit / fon hesabı alacaklandırıldı. Gross carrying amount güncellendi.
Gerçek hayat
Entegrasyon tam otomatik değilse GL günlük batch ile güncellenir. T+0 değil T+1 — muhasebe gün sonu kapanışına kadar "eski" veriyi gösterir.
Ne oluyor?
Gece ETL süreci CBS'den veri çeker. EAD hesabı güncellenir. Risk portföy raporu yenilenir. Bu an T+1 sabahına kadar risk ekibi eski EAD'ı görür.
Kritik gecikme
Risk ekibi dün akşamın snapshot'ını görüyor. Büyük bir çekim gün içinde olursa risk raporları geride kalır. Timing mismatch'in kaynağı burada.
Tetik
Risk DWH güncellenince ECL motoru yeni kullanım ve taahhüt verisini alır. Olasılık ağırlıklı, iskonto edilmiş nakit açığı ölçümü güncellenir; PD×LGD×EAD bunun yaygın ama basitleştirilmiş uygulama iskeletidir. Karşılık tutarı GL'ye geri beslenir.
Döngüsel akış
ECL → GL → Raporlama zinciri. Zincirin herhangi bir halkasında gecikme veya hata olursa, downstream'in tamamı bozulur.
Ne görünür?
Portföy dashboard, güncel EAD, limit kullanım oranı, RAROC hesabı. Tüm bunlar T+1 sabahı itibariyle güncellendi — 24 saat gecikmeyle.
Karar alma etkisi
Yönetim "bugünkü" portföyü görüyor sandığında dünün verisini görüyor. Limitin dün gece aşılıp aşılmadığını sabah öğreniyor.
Raporlama döngüsü
Aylık dönemde çekilip hesaplanan pozisyon BDDK'ya iletilir. Ay sonu snapshot'ı geçerli — ay içi hareketler sadece ay sonu bakiyede görünür.
Neden önemli?
Regülatör geçmişe dönük sorgu yapabilir. Sistem kayıtlarının izlenebilir ve tutarlı olması zorunlu. Reconciliation burada kritik.
Bu örnek mimaride tek bir 2M TL’lik çekim işlemi 6 farklı sisteme yansıdı — farklı zamanlarda, farklı formatlarda, farklı iş birimlerinin sorumluluğunda. Sayfa 07'de bu sistemler arası farkın nasıl bir "timing mismatch" ürettiğine bakacağız.
dış veri kaynakları
Banka kendi sistemleri dışında da veri besler. Bu dış kaynaklar özellikle PD modelleri ve IFRS 9 makroekonomik overlay'ler için kritik.
Kredi Kayıt Bürosu — borçlunun diğer bankalardaki kredi geçmişi, DPD bilgisi, toplam borçluluk. Bireysel modeller için temel input.
PD modeli girdisi
Makroekonomik veriler: GSYH büyümesi, enflasyon, faiz oranları, işsizlik. IFRS 9 forward-looking overlay ve senaryo ağırlıkları için zorunlu.
Makro overlay
Şirket tescil durumu, sermaye yapısı, ortaklık bilgisi. Gayrimenkul için tapu kayıtları teminat doğrulamasında kullanılır.
Teminat & KYC
Bloomberg, Reuters: faiz kurları, CDS spread'leri, döviz kurları. Piyasa bazlı PD tahmini ve transfer fiyatlaması için kullanılır.
Market-implied PD
Borçlunun diğer bankalarda veya alacaklılarda icra takibi altında olup olmadığı. "Unlikeliness to pay" tespitinde nitel sinyal.
Default detection
Moody's, S&P, Fitch — büyük kurumsal müşteriler için harici rating. Benchmark olarak iç rating modelini kalibre etmede kullanılabilir.
Benchmark / Kalibrasyon
hangi sistem hangi veriyi tutar?
Aynı veri noktasına birden fazla sistemden ulaşabilirsin — ama hepsi aynı kalitede değil. Bu tablo, validasyonda "kaynağa git" kararını verirken rehber olarak kullanılabilir.
| Veri Noktası |
CBS |
Risk DWH |
GL |
ECL Engine |
LOS |
| Drawn bakiye |
● |
◐ |
● |
◐ |
— |
| Limit tutarı |
● |
◐ |
— |
◐ |
● |
| Temerrüt tarihi |
◐ |
● |
— |
◐ |
— |
| DPD (gecikme günü) |
● |
● |
— |
◐ |
— |
| IFRS 9 Stage |
— |
◐ |
◐ |
● |
— |
| PD tahmini |
— |
● |
— |
● |
◐ |
| Teminat değeri |
◐ |
◐ |
— |
◐ |
● |
| Tahsilat tutarları |
◐ |
● |
● |
— |
— |
● Birincil kaynak · ◐ Türetilmiş / kopyalanmış · — Bulunmuyor
Tabloda ◐ gördüğün her hücre bir potansiyel tutarsızlık noktasıdır. Risk DWH'daki DPD CBS'den kopyalandıysa ama kopyalama günlük batch'le yapılıyorsa — gün içi değişimler görünmez. Sayfa 09'da (Mutabakat) bu tabloyu kullanarak reconciliation senaryolarını ele alacağız.
veri lineage — bir model girdisini kaynağına kadar izle
Validasyonun en somut sorusu: "Bu sütun nereden geldi?" Aşağıdaki izleyici, bir model girdisini yetkili kaynaktan (golden source) modele kadar takip ediyor; her hopta hangi BCBS 239 prensibinin risk altında olduğunu ve hangi kontrolün gerektiğini gösteriyor.
BCBS 239 & ECB RDARR — veri yönetişimi neden regülatif?
Yukarıdaki tüm sistem/lineage karmaşası soyut bir IT konusu değil — doğrudan bir denetim alanı. Temel çerçeve BCBS 239 ("Principles for effective risk data aggregation and risk reporting", 11 prensip). AB'de ECB bunu Guide on effective risk data aggregation and risk reporting (Mayıs 2024) ile sıkılaştırdı ve SSM denetim önceliği 2025–2027 ilan etti: 2025'ten itibaren bankalar SREP'te RDARR uyumu üzerinden değerlendiriliyor.
Yönetişim & altyapı (1–2)
- Yönetim kurulu sorumluluğu, net data ownership
- Tek, entegre veri taksonomisi / mimari
- Kriz/stres anında da çalışan altyapı
Toplama yeteneği (3–6)
- Doğruluk & bütünlük — golden source, otomasyon
- Tamlık — tüm maddi risk verisini kapsama
- Zamanındalık — batch gecikmeleri burada vurur
- Uyarlanabilirlik — ad-hoc/stres talepleri karşılama
Raporlama (7–11)
- Doğruluk, kapsam, açıklık, sıklık, dağıtım
- Manuel düzeltmelerin (EUC, Excel) izlenmesi
- Lineage: rapordan kaynağa kadar takip edilebilirlik
Validasyon için anlamı
- Model girdisi = "risk data" → BCBS 239 kapsamında
- Veri kalitesi bulgusu artık model bulgusu kadar ciddi
- Lineage dökümante değilse: SREP bulgusu + sermaye etkisi
Validasyoncu için kritik kayma: eskiden "veri IT'nin işi" sayılırdı. ECB RDARR ile veri kalitesi, lineage ve manuel müdahale kontrolü model riskinin ayrılmaz parçası. "Model doğru ama input yanlış" senaryosu artık ayrı bir denetim başlığı — ve düzeltilmezse Pillar 2 sermaye eklemesiyle sonuçlanabilir.
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.