Bankacılık Operasyonları & Kredi Yaşam Döngüsü · 09
Mutabakat & Veri Kalitesi
bankacılığın görünmeyen kalbi
Her ay sonunda aynı sahne: muhasebe GL'den bir rakam üretiyor, risk ekibi DWH'dan başka bir rakam üretiyor. İkisi tutmuyor. "Hangisi doğru?" sorusu masaya geliyor — ve cevabı bulmak bazen günler sürüyor.
Mutabakat (reconciliation), iki sistemin aynı gerçekliği farklı gösterdiğini tespit edip farkı açıklamak ve kapatmak sürecidir. Önemsiz görünebilir — ama kapatılmayan fark, mali tablolarda hata, regülatör baskısı ve model input kalitesi sorununa dönüşür.
Bu sayfa Blok 2'nin son halkası. Önce gerçek bir recon sürecini adım adım walkthrough ediyoruz. Sonra yaygın "recon fail" senaryolarını inceliyoruz. Son olarak validasyon ekibinin veri kalitesi kontrol listesini sunuyoruz.
recon walkthrough — fark nerede?
Senaryo: Ay sonu kapanışında GL ve Risk DWH aynı portföyü farklı gösteriyor. 847.000 TL fark var. Adım adım izle — farkı bul.
Kaynak
GL / Muhasebe
284,6
Milyon TL · Gross carrying amount
ECL karşılığı dahil değil
≠
Kaynak
Risk DWH
283,8
Milyon TL · Drawn exposure (EAD dahil değil)
Undrawn hesaba katılmamış
1
Kontrol
Kapsam farkı — aynı portföyü mi bakıyorlar?
2
Kontrol
Timing — aynı referans tarihini mi kullanıyorlar?
3
Kontrol
Tanım farkı — aynı tutarı mı ölçüyorlar?
4
Kontrol
Kur farkı — döviz krediler aynı kura çevrildi mi?
5
Sonuç
Farkın özeti — açıklanan vs açıklanamayan
Bu walkthrough'da fark tamamen açıklandı — iyi senaryo. Gerçek hayatta "açıklanamayan" kalan fark olduğunda denetim sorusu başlar. Kalan farkın 0 olmaması regülatör bulgusu riskini taşır.
recon fail senaryoları
Mutabakatın başarısız olduğu — yani farkın açıklanamadığı veya kapatılamadığı — yaygın senaryolar. Her birine tıkla.
Write-off muhasebeleşti ama Risk DWH güncellenmedi
Kritik
+
Ne oluyor?
3 kredi write-off edildi, GL'den çıkarıldı. Ama ETL'nin temerrüt ve recovery kayıtlarıyla eşleştirme mantığı write-off event'ini yakalamıyor.
Risk DWH'da ne görünür?
Krediler hâlâ Stage 3 NPL olarak görünüyor, ECL karşılığı duruyor. GL'de bu krediler yok. Portföy tutarı Risk DWH'da olduğundan büyük çıkıyor.
Düzeltme
ETL'ye write-off event handler eklenmeli. Write-off tarihinden itibaren ilgili kayıtlar Risk DWH'da da portföyden çıkarılmalı ve recovery tracking'e alınmalı.
Model etkisi: LGD backtesting'de write-off sonrası recovery'ler doğru eşleştirilemiyor → gerçekleşen LGD hesabı hatalı.
Yeniden yapılandırılan kredilerin Stage güncellenmemesi
Önemli
+
Ne oluyor?
Yeniden yapılandırma manuel olarak işlendi, ama CBS'deki forborne flag'i ECL Engine'e zamanında iletilmedi. Stage 2'ye geçiş bir ay gecikti.
Etki
Bu sürede 12-aylık ECL uygulandı, lifetime ECL uygulanması gerekirdi. Bir ay boyunca karşılık eksik — P&L geçmiş dönem düzeltmesi gerekiyor.
Düzeltme
Forborne flag'i CBS'den ECL Engine'e direkt event bazlı iletilmeli. Manuel işlem gerektiren süreçlerde kontrol mekanizması zorunlu.
Validasyon sorusu: Forborne kredi adedi GL'deki ile Risk DWH'daki eşleşiyor mu? Eşleşmiyorsa staging sistematik olarak hatalı demektir.
Teminat satışı tahsilat sistemine girildi ama GL'ye yansımadı
Kritik
+
Ne oluyor?
Gayrimenkul satışı gerçekleşti, tahsilat sistemi recovery kaydetti. Ama GL entegrasyonu çift onay gerektiriyor — muhasebe henüz onaylamadı.
Etki
Risk DWH recovery görüyor, LGD hesabı güncellendi. GL hâlâ full Stage 3 karşılığı tutuyor. İki sistem zıt yönde — biri artık iyi diyor, diğeri hâlâ kötü.
Düzeltme
Teminat realize işleminin GL onay süreci hızlandırılmalı. Ya da tahsilat sistemi → GL entegrasyonu otomatize edilmeli.
Model etkisi: LGD modelinin backtesting'i için recovery verisi tahsilat sisteminden mi, GL'den mi alınıyor? Hangisi daha geç güncelleniyor? Bu seçim gerçekleşen LGD hesabını doğrudan etkiliyor.
Grup şirketi konsolidasyonu tek taraflı yapıldı
Önemli
+
Ne oluyor?
A şirketi ve bağlı B şirketi konsolide edilmesi gerekirken GL ikisini ayrı izliyor, Risk DWH sadece A'yı takip ediyor. B şirketinin 2.4M TL'lik kredisi Risk DWH'da görünmüyor.
Etki
Grup EAD eksik — konsantrasyon limiti yanlış hesaplanıyor. A şirketi temerrüde düşerse B de etkilenecek ama model bunu görmüyor. PD modeli grup riskini yakalayamıyor.
Düzeltme
Grup ilişkisi veri tabanı Risk DWH'a entegre edilmeli. Konsolidasyon mantığı ETL'de uygulanmalı — manüel değil sistematik.
Konsantrasyon riski analizi için kritik. Validasyon, grup riskleri için Risk DWH'ın GL ile tutarlı olup olmadığını mutlaka sorgular.
ECL karşılığı GL'ye yansıdı ama Risk DWH provizyon tablosu güncellenmedi
Kritik
+
Ne oluyor?
Management overlay nedeniyle ECL el ile artırıldı ve GL'ye işlendi. ECL Engine'in bu override'ı Risk DWH'a geri beslemesi yapılmadı.
Etki
Risk DWH'daki ECL verisi artık GL'deki gerçek karşılıktan küçük. Risk ekibinin coverage ratio hesabı yanlış — gerçekte daha yüksek korumalı görünüyor.
Düzeltme
Management overlay her uygulandığında hem GL hem Risk DWH eş zamanlı güncellenmeli. Override kayıtları data lineage'ın parçası olmalı.
Bu senaryo validasyon için önemli: model çıktısı (ECL Engine) ile muhasebe kaydı (GL) arasındaki fark overlay miktarına eşit olmalı. Eşit değilse belgelenmemiş müdahale var demektir.
validasyon veri kalitesi kontrol listesi
Bir modeli validate ederken veri kalitesi değerlendirmesi ayrı bir adım olmalı. Aşağıdaki kontroller EBA/GL ve SR 11-7 kapsamında standart hale gelmiş. Tıklayarak işaretle.
0 / 0 kontrol tamamlandı
Kaynak & Kapsam
✓
Model girdilerinin kaynağı tanımlanmış ve belgelenmiş (data lineage mevcut).
Yüksek
✓
Kapsam: hangi portföy dahil, hangi segmentler dışarıda bırakılmış? Gerekçe belgelenmiş mi?
Yüksek
✓
Referans tarih uyumu: tüm değişkenler aynı tarih itibarıyla mı alınıyor?
Yüksek
Eksiksizlik & Doğruluk
✓
Kritik değişkenlerde null / boş değer oranı kabul edilebilir eşiğin altında.
Yüksek
✓
Temerrüt tarihi, recovery tutarı ve tarihi CBS / tahsilat sistemi ile çapraz doğrulandı.
Yüksek
✓
Aykırı değerler (outlier) tespit edildi — gerçek mi, veri hatası mı? Karar belgelendi.
Orta
✓
Duplicate kayıt kontrolü yapıldı — aynı kredinin birden fazla görünmesi yok.
Orta
Tanım Tutarlılığı
✓
Temerrüt tanımı: IRB/IFRS 9 / BDDK tanımları arasındaki farklar belgelenmiş ve model belgelerine yansıtılmış.
Yüksek
✓
EAD tanımı: drawn only mu, drawn + undrawn × CCF mi? Açıkça belirtilmiş.
Yüksek
✓
Forborne, cured, yeniden temerrüt tanımları tutarlı ve sistematik olarak uygulanmış.
Orta
Reconciliation
✓
Model eğitim seti tutarı Risk DWH ile mutabık — kapsam, tarih, tutar uyumu sağlandı.
Yüksek
✓
Temerrüt sayısı ve tutarı GL ile Risk DWH arasında mutabık — fark varsa açıklanmış.
Yüksek
✓
Recovery tutarları tahsilat sistemi ve GL arasında mutabık.
Yüksek
✓
Management overlay miktarı: GL ile ECL Engine çıktısı arasındaki fark belgelenmiş.
Orta
İzlenebilirlik & Güncelleme
✓
ETL süreci ve mapping kuralları belgelenmiş — kim değiştirirse ne değişiyor açık.
Orta
✓
Teminat değerleme tarihleri: son güncelleme 12 aydan eski olan teminatlar işaretlenmiş.
Düşük
✓
Model girdileri yeniden üretilebilir: aynı veri seti ile aynı model çıktısı elde edilebiliyor.
Yüksek
Bu kontrol listesi Blok 2'nin özeti gibi çalışıyor. Sistemleri, veri akışını, tanım farklarını ve reconciliation'ı anlamadan bu listenin her maddesinin neden önemli olduğunu kavramak zorlaşır — tam bu yüzden 06→07→08→09 sırası önemli.