Banking Foundations · 04
Validasyonda Ne Yapıyoruz?

önce ne olmadığından başlayalım

Validasyon ekibi ilk başta model geliştirmez. Tüm kodları yazılmış ve metodolojilerin seçilmiş haliyle alıyor ve baştan sona sorguluyoruz. Fakat model geliştirme esnasında benchmark model üretip, onayımıza sunulan modeli challenge edebiliyoruz.

Bu ayrım kritik. Çünkü birinin yarattığı şeyi kendi eleştirmesi ile başka birinin eleştirmesi arasında nitelik farkı vardır. Model geliştirici metodolojisine inanarak çalışmıştır — tam da bu yüzden gözden kaçırdığı şeyleri biz görmek zorundayız.

Model Geliştirme Ekibi
Problemi tanımlar ve veriyi toplar
Metodoloji seçer ve modeli kurar
İç testleri gerçekleştirir
Sonuçları dokümante eder
Bulgu yanıtlarını hazırlar
Modeli güncel tutar ve izler
Model Validasyon — Biz
Modeli teslim alır, kapsamı netleştirir
Kavramsal doğruluğu bağımsız değerlendirir
Veri, metodoloji ve performansı test eder
Replikasyon ve benchmark çalışması yapar
Bulgular raporlar, şiddet derecelendirir
Yeniden validasyon tetikleyicilerini izler
Validasyonun ürünü bir validasyon raporudur — bağımsız bulguları, değerlendirmelerini ve modelin validasyon sürecine ilişkin tüm teknik detayları içeren resmi bir belgedir.

validasyonun 6 boyutu

Bir modeli değerlendirirken altı farklı perspektiften bakıyoruz. Her boyut farklı sorular sorar ve farklı kırılganlıkları açığa çıkarır. Tıkla — her boyutta ne sorduğumuzu ve hangi red flag'leri aradığımızı gör.

1
Kavramsal Doğruluk
Model tasarımı mantıklı mı, kullanım amacına uygun mu?
+
Modelin teorik temeli sağlam mı? Kullanılan yaklaşım literatürde kabul görmüş mü?
Model amacına uygun kurulmuş mu? PD için tasarlanan model PD hesaplamasında mı kullanılıyor?
Modelin varsayımları açıkça belirtilmiş mi ve gerçekçi mi?
Segmentasyon mantığı savunulabilir mi? Homojenlik sağlanmış mı?
Red flag: "Hep böyle yapılıyor" gerekçesiyle savunulan, teorik temelden yoksun metodoloji seçimleri. Ya da kullanım amacı değişmiş ama model güncellenmemiş.
2
Veri Kalitesi & Uygunluğu
Veri temsil gücüne sahip mi, işlemler doğru mu?
+
Gözlem penceresi ve performans penceresi doğru tanımlanmış mı?
Eğitim verisi mevcut portföyü temsil ediyor mu? Seçim yanlılığı var mı?
Eksik veri işleme yöntemi makul mü? Imputation mantıklı mı?
Bağımlı değişken (temerrüt tanımı vb.) tutarlı ve doğru tanımlanmış mı?
Veri kaynağı güvenilir mi, data lineage izlenebilir mi?
Red flag: Reject inference yapılmamış onaylama verileri. Temerrüt tanımının süreç ortasında değiştirilmesi. Eğitim verisinin çok dar bir dönemden gelmesi (ekonomik döngüyü temsil etmemesi).
3
Metodoloji & İstatistiksel Sağlamlık
Teknikler doğru uygulandı mı, varsayımlar test edildi mi?
+
Seçilen istatistiksel yöntem (lojistik regresyon, survival analizi vb.) probleme uygun mu?
WoE / IV hesaplamaları doğru mu? Monotonluk kısıtları uygulanmış mı?
Multicollinearity, overfitting gibi istatistiksel sorunlar kontrol edilmiş mi?
Model varsayımları (lineerlik, bağımsızlık vb.) test edilmiş mi?
Biz aynı veriyle aynı sonuçlara ulaşabiliyor muyuz? (Replikasyon)
Red flag: Replikasyon yapılamıyor — kodun veya verinin paylaşılmaması. Varsayım testleri hiç yapılmamış. Overfitting işaretleri var ama görmezden gelinmiş.
4
Performans Testleri
Model ayırt ediyor mu, kalibre mi, stabil mi?
+
Discrimination: Gini / AUC / KS yeterli mi? Model riskli ve risksizi ayırt edebiliyor mu?
Calibration: Tahmin edilen PD gerçekleşen temerrüt oranıyla uyumlu mu? Hosmer-Lemeshow veya Brier score bakıldı mı?
Backtesting: Geçmiş dönemde model ne kadar doğru tahmin etmiş? Out-of-time performans hesaplanmış mı?
Stability: PSI (Population Stability Index) kabul edilebilir aralıkta mı? Model zamanla bozuluyor mu?
Benchmark: Alternatif model veya regülatör yaklaşımıyla karşılaştırma yapıldı mı?
Red flag: Sadece in-sample performans gösterilmiş. Out-of-time backtesting yok. PSI hesaplanmamış. Benchmark analizi "çok zaman alır" gerekçesiyle atlanmış.
5
Kullanım Amacı Uyumu (Use Test)
Model gerçekten kullanılıyor mu, override'lar mantıklı mı?
+
Model onaylanan amaç için mi kullanılıyor? Kapsam dışı kullanım var mı?
Model sonuçları karar süreçlerine gerçekten entegre mi? Yoksa "göstermelik" mi kullanılıyor?
Override oranı makul mü? Override gerekçeleri tutarlı ve belgelenmiş mi?
Model çıktısı hangi sistemlere, hangi hesaplamalara besleniyor? Bu akış doğru mu?
Red flag: Override oranı %30'un üzerinde — model güvenilir bulunmuyor demektir. Ya da model onaylandı ama aktif kullanımda değil (portföy kararlarına etki etmiyor).
6
Regülasyon & Yönetişim Uyumu
Düzenleyici gereksinimler karşılanıyor mu?
+
IRB modelleri için Basel III / CRR gereklilikleri karşılanmış mı? (MoC, downturn, uzun vade serisi vb.)
IFRS 9 modelleri için forward-looking bilgi entegrasyonu standartlara uygun mu?
Model dokümantasyonu yeterli ve güncel mi? SR 11-7 / SS3-18 beklentileri karşılanmış mı?
Model inventory'de kayıtlı mı? Periyodik gözden geçirme takvimi var mı?
Red flag: Dokümantasyon eksik veya son kullanım tarihini geçmiş. Regülatör son incelemesinde benzer bulgular işaretlenmiş ama kapatılmamış.
Her modelde altı boyutun hepsine bakılır. Ancak hangi boyutun daha kritik olduğu modele göre değişir. NMD modeli için vade yapısı ve replikasyon porföyü kalibrasyon ön plana çıkarken, PD modeli için backtesting ve calibration öncelik taşır.

bulgular nasıl derecelendirilir?

Validasyon sürecinde tespit edilen sorunlar — bulgular — etkiye göre derecelendirilir. Bu derecelendirme hem komite kararını hem kapatma süresini belirler.

Kritik
Modelin kullanımının derhal durdurulmasını gerektirebilecek temel bir hata veya eksiklik. Finansal tablolara, sermaye hesaplamalarına veya kritik kararlara ciddi etkisi var.
→ Komite acil toplanır, model kullanımı askıya alınabilir.
Yüksek
Ciddi metodoloji, veri veya performans sorunu. Model onaylanabilir ama kısa süre içinde (genellikle 3–6 ay) düzeltme planı şarttır.
→ Koşullu onay, eylem planı ve kapatma takvimi bağlayıcıdır.
Orta
Anlamlı iyileştirme noktası. Model kullanımda kalabilir ancak bir sonraki geliştirme döngüsünde ele alınmalıdır (6–12 ay).
→ Eylem planı istenir, sonraki gözden geçirmede takip edilir.
Düşük
İyileştirme önerisi niteliğinde, modelin temel işleyişini etkilemeyen küçük eksiklikler. Uzun vadeli geliştirme planına alınır.
→ Bilgi amaçlı raporlanır, bağlayıcı eylem planı gerekmeyebilir.

Bulgu sayısı ve şiddet dağılımı modelin genel "sağlık" durumunu özetler. Çok sayıda yüksek bulgu taşıyan bir modeli onaylamak komite için ciddi bir karar sürecidir.

Validasyon Raporunun Tipik Yapısı
1
Yönetici Özeti
Genel değerlendirme ve öneri
2
Model Genel Bilgisi & Kapsam
Nedir, ne için, sınırlılıklar
3
Bulgu Tablosu
Her bulgu: şiddet, açıklama, geliştirici yanıtı
4
Detaylı Testler
Her boyut için ayrıntılı analiz ve sonuçlar
5
Sonuç & Öneri
Onayla / Koşullu onayla / Reddet + koşullar

challenge kültürü nedir?

Validasyonun kalitesi büyük ölçüde "challenge etme" becerisinden gelir. Challenge, geliştirme ekibiyle düşmanlık değil — entelektüel dürüstlüktür. Doğru soruyu sormak, kanıt istemek, alternatif düşünmek.

Kanıt İste
"Bunu test ettin mi?"
Sözlü açıklama yetmez. Test sonucu, grafik veya hesaplama görmek isteriz. "Mantıklı görünüyor" ile "kanıtlandı" farklı şeylerdir.
Alternatif Sor
"Başka yaklaşım denedin mi?"
Neden bu metodoloji seçildi? Alternatif ne verirdi? Benchmark model karşılaştırması yapılmadıysa neden?
Varsayımı Sorgula
"Bu varsayım hep geçerli mi?"
Modelin dayandığı her varsayım bir kırılganlıktır. Hangi koşul altında bu varsayım bozulur? O koşul için test yapıldı mı?
Stres Et
"Senaryo altında ne olur?"
Model normal koşullarda iyi çalışıyor olabilir. Aşırı senaryo altında — ekonomik şok, portföy bileşimi değişimi — ne oluyor?
Challenge etmek agresif olmak değildir. "Neden?" sorusu, saldırmak değil anlamak için sorulur. Geliştirme ekibi bu soruya yanıt verebiliyorsa model daha güçlüdür. Veremiyorsa bulmamız gereken bir şey var demektir.

bu sayfadan götürülecekler

validasyon = bağımsız doğrulama
Yaratmıyoruz, doğruluyoruz. Aynı kişi hem yaratıp hem doğrulayamaz — bu bağımsızlık yönetişimin temelidir.
altı boyut birbirini tamamlar
Kavramsal, veri, metodoloji, performans, kullanım, regülasyon. Birine odaklanıp diğerini atlamak eksik validasyondur.
bulgu = şiddet + eylem
Her bulgu bir önem düzeyine ve kapatma takvimine bağlanır. Bulgu listesi raporu değil, rapor bulgularla anlamlı hale gelir.
challenge bir beceridir
"Neden?" sorusunu doğru yerde, doğru kanıt isteyerek sormak. Bu beceri zamanla gelişir — teknik bilgi bu soruyu daha keskin yapar.
Faz 1 tamamlandı
Büyük resmi gördük.
Banka nasıl çalışır, hangi riskler var, kim ne yapar, validasyon ne demektir — bunların hepsini gördük. Sıradaki faz bu yapının neden bu kadar ciddiye alındığını anlatıyor: regülasyon ve sermaye mantığı. Basel neden var?