Banking Foundations · 04
Validasyonda Ne Yapıyoruz?
Bu sayfanın sonunda geliştirme testi ile bağımsız validasyonu, bulgu ile model kararını ve teknik test ile kullanım uygunluğunu ayırabilmelisin.
önce ne olmadığından başlayalım
Bağımsız validasyon, onaylanacak modeli geliştiren veya modelin iş sonucundan sorumlu olan fonksiyon değildir. Kendi testlerini, replikasyonunu ya da challenger/benchmark çalışmasını üretebilir; bunlar onaya sunulan modelin yerine geçen geliştirme faaliyeti değil, bağımsız değerlendirme kanıtıdır.
Validasyon yalnızca model tamamlandıktan sonra başlayan son kontrol de değildir. Çıkar çatışması yaratmadan kapsam, veri erişimi ve validasyon planı erken aşamada netleştirilebilir; model ilk kullanımdan önce ve yaşam döngüsü boyunca risk bazlı biçimde değerlendirilir.
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
Bağımsız kapsam ve test planı oluşturur
Kavramsal doğruluğu bağımsız değerlendirir
Veri, metodoloji ve performansı test eder
Replikasyon ve benchmark çalışması yapar
Bulguları raporlar, şiddetlerini derecelendirir
Yeniden validasyon tetikleyicilerini izler
Validasyon raporu temel çıktıdır; fakat tek çıktı değildir. Bulgu takibi, koşullu onayın izlenmesi, değişiklik değerlendirmesi ve yeniden validasyon görüşü de model risk yönetiminin parçasıdır.
pratik validasyon çerçevesi: 6 boyut
Bu altı başlık öğretim amaçlı bir kontrol çerçevesidir; düzenlemelerde zorunlu ve evrensel bir “altılı liste” değildir. Kapsam ve test derinliği modelin önemliliğine, karmaşıklığına ve kullanımına göre belirlenir.
→
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ş.
→
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).
→
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ş.
→
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? Uygun kalibrasyon grafikleri, oran testleri ve skorlar kullanılmış 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ış.
→
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ı politika eşiğini sürekli aşıyor, belirli segmentlerde yoğunlaşıyor veya gerekçeler kanıtlanamıyor. Tek bir evrensel “iyi/kötü” override yüzdesi yoktur.
→
Modelin kullanıldığı ülke ve yaklaşım için yürürlükteki ulusal düzenlemeler karşılanmış mı? Basel standardı ile yerel uygulama tarihi ve seçenekleri birbirine karıştırılmış mı?→
IFRS 9 / TFRS 9 modelleri için forward-looking bilgi ve makro senaryo entegrasyonu standartlara uygun mu?→
Model dokümantasyonu yeterli ve güncel mi? İlgili yerel mevzuat ile uygulanabilir model risk rehberleri dikkate alınmış mı? ABD'de 2026 kurumlar arası rehber, İngiltere'de güncel PRA SS1/23 buna örnektir.→
Model envanterinde kayıtlı mı? Periyodik gözden geçirme takvimi ve model risk derecelendirmesi 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 model için aynı test listesini aynı yoğunlukta uygulamak doğru değildir. Kapsam risk bazlı ve orantılı olmalıdır. NMD modelinde davranış varsayımları ve faiz duyarlılığı; PD modelinde ayırt etme, kalibrasyon ve temerrüt tanımı daha ağır basabilir.
Türkiye bağlamı. Muhasebe karşılığı modelleri TFRS 9, düzenleyici sermaye modelleri BDDK sermaye ve ilgili yaklaşım düzenlemeleri altında değerlendirilir. Geçerli kriter, yabancı bir rehberi otomatik uygulamak değil; kullanım amacı, yerel mevzuat, banka politikası ve modelin risk düzeyi için uygun bağımsızlık ve kanıt setini kurmaktır.
bulgular nasıl derecelendirilir?
Validasyon sürecinde tespit edilen sorunlar etki, gerçekleşme olasılığı, modelin önemliliği ve mevcut kontroller dikkate alınarak derecelendirilir. Aşağıdaki sınıflar örnektir; adlar, karar yetkisi ve hedef kapatma süreleri bankanın politikasına göre değişir.
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. Kullanımın sınırlandırılması, koşullu onay veya kısa vadeli düzeltme planı gerekebilir.
→ Koşullu onay, eylem planı ve kapatma takvimi bağlayıcıdır.
Orta
Anlamlı iyileştirme noktası. Model kullanımda kalabilir; eylem ve hedef tarih risk bazlı olarak belirlenir.
→ 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ı tek başına modelin durumunu göstermez. Tek bir temel tasarım hatası çok sayıda düşük bulgudan daha önemli olabilir; karar açık riskin büyüklüğü, geçici kontroller ve kullanım bağlamıyla birlikte verilir.
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
geliştirme testi ≠ bağımsız validasyon
Geliştiricinin testleri zorunludur; bağımsız ekip ise farklı teşviklerle kanıtı yeniden değerlendirir. Challenger çalışması yapmak, onaylanan modeli geliştirmekle aynı şey değildir.
kapsam risk bazlıdır
Kavramsal yapı, veri, metodoloji, performans, kullanım ve yönetişim birlikte düşünülür; test derinliği modelin önemine göre değişir.
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?