Bankacılık Operasyonları & Kredi Yaşam Döngüsü · 09

Mutabakat & Veri Kalitesi

Gözden geçirme: 14 Temmuz 2026Kapsam: Türkiye/TFRS ana eksen; FINREP, COREP ve CRR backstop bölümleri AB karşılaştırmasıdır.Okuma kuralı: Simülatörler öğretici sadeleştirmedir; düzenleyici hesap değildir.

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ış
🔍
Fark: 847.000 TL — açıklanamayan
Bu fark tek bir sebepten kaynaklanmıyor olabilir. Adım adım araştırmak gerekiyor. Sırayla her kontrol noktasını aç.
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.

FINREP ↔ COREP — muhasebe ve sermaye birbirini tutmalı

Mutabakat yalnızca iç sistemler arasında değildir. AB düzenleyici raporlama kapsamındaki bankalar iki ana rapor ailesi üretir: FINREP (IFRS bazlı finansal raporlama) ve COREP (Basel/CRR bazlı sermaye raporlaması). Denetçi bu ikisinin tutarlı olmasını bekler — örneğin FINREP'teki brüt kredi ve karşılıklar ile COREP'teki exposure ve provizyon kalemleri uzlaşmalı. EBA bunun için resmi FINREP–COREP reconciliation / map'leri yayımlar.

FINREP — muhasebe görünümü
  • Gross carrying amount (IFRS 9)
  • ECL karşılıkları (Stage 1/2/3)
  • Forborne & NPE açıklamaları
  • Net defter değeri
COREP — sermaye görünümü
  • Exposure value (EAD, CCF sonrası)
  • RWA, IRB EL ve provizyon karşılaştırması
  • NPE prudential backstop (Madde 47a-c)
  • CET1 düşümleri (EL shortfall, NPE coverage)

İki rapor aynı portföye bakar ama farklı tanımlarla (Modül 08). Aralarındaki köprü kalemler belgeli olmalı; aksi halde denetçi "neden FINREP karşılığı ile COREP provizyonu tutmuyor?" diye sorar. İşin kalbinde tek bir soru var: aynı kredi için ayrılan karşılık, üç farklı ölçünün hangisini tatmin ediyor?

NPE brüt tutarı teminatsız varsay
10 M
IFRS 9 karşılık (ECL) muhasebe — FINREP
%40
CRR backstop min. NPE yaşına göre — COREP
%100
IRB bankası mı?
IRB — regülatif EL ekle
Ayrılan karşılık (ECL)
CRR backstop minimum
Validasyonun büyük resmi: Muhasebe karşılığı ECL’dir; IRB EL karşılaştırması ve AB CRR backstop ise ayrı sermaye testleridir. Bu çıtalar aynı amaçla hesaplanmaz; ilgili düzeltmeler exposure bazında, mahsup ve çifte sayımı önleyen kurallarla birlikte uygulanır. “Karşılık yeterli mi?” sorusunun ölçütü hangi çerçevenin sorulduğuna göre açıkça belirtilmelidir.

validasyon veri kalitesi kontrol listesi

Bir modeli validate ederken veri kalitesi değerlendirmesi ayrı bir adım olmalı. Aşağıdaki kontroller EBA/GL, SR 11-7 ve ECB RDARR (BCBS 239) kapsamında standart hale gelmiş — RDARR ile artık dökümante mutabakat, tolerans eşikleri ve break-aging de denetleniyor. 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 kurum politikası ve geçerli düzenlemedeki sıklık/eşiklerle karşılaştırılmış; süresi aşanlar 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.

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.

Mehmet Yığılı · Bankacılık Operasyonları & Kredi Yaşam Döngüsü · 09 / 12 · © 2026