Bankacılık Operasyonları & Kredi Yaşam Döngüsü · 06
Veri Nerede Doğar — Sistemlere Genel Bakış
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: aynı veri noktasına ulaşmanın onlarca yolu var ve hiçbiri tam anlamıyla "tek gerçek kaynak" değil. 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 EAD'ı alır. PD × LGD × EAD yeniden hesaplanır. 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.
Tek bir 2M TL'lik çekim işlemi en az 6 farklı sisteme yazıldı — 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 / Kalibrason
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.