Türkiye bankacılığında işletme dışı operasyonel zaman kayıplarının %34’ünden sorumlu olan ana etken: eski core banking sistemleridir. Türkiye’deki banka çekirdek sistemlerinin %62’si 2000-2012 arasında kurulmuş, mainframe (COBOL/PL/I) veya monolitik Oracle/AS400 mimari üzerinde çalışıyor (BDDK Dijital Olgunluk Raporu, 2025). Modern müşteri beklentileri (gerçek zamanlı bildirim, anlık transfer, açık bankacılık API, mobil-first UX) bu sistemlerle karşılanamıyor. Accenture’ın 2026 Top 10 Banking Trends raporu, core modernization yapan bankaların time-to-market’i %85 hızlandırdığını ve cost-to-serve’ı %32 düşürdüğünü gösteriyor. Konuyla ilişkili olarak Legacy Mainframe Modernization 2026: COBOL'dan Java'ya Otomatik Çev… rehberimiz detaylı incelemeyi içerir.
Bu rehberde, bir bankanın çekirdek sistemini mainframe’den modern microservice mimarisine taşıma sürecini — strangler pattern, event sourcing, BIAN standardı uyumu — somut sayılarla aktaracağız. Hedef kitle: banka CTO/CDO/CIO, core banking program yöneticileri ve neobank/fintech kurmak isteyen B2B SaaS girişimcileri.
Core Banking Nedir, Hangi Modüllerden Oluşur?
- Müşteri Yönetimi (CIF): Tek müşteri görünümü, KYC, AML.
- Hesap Yönetimi: Hesap açma, kapama, yetkilendirme, faiz.
- Para Transferi (Payments): EFT, Havale, FAST, SWIFT.
- Kredi Yönetimi (Lending): Bireysel, KOBİ, ticari, ipotek.
- Kart Yönetimi: Debit, kredi, prepaid; otorizasyon, switch.
- Mevduat ve Tasarruf: Vadeli, vadesiz, ödülü vade.
- Hazine (Treasury): Kur, fonlama, repo.
- Genel Muhasebe: GL, kapanış, BDDK raporlama.
Mainframe’den Microservice’e: Strangler Pattern
Bir bankayı bir gecede yeni sisteme taşımak olanaksız — günde milyonlarca işlem yürüyor. Strangler Fig pattern bu işin endüstri standardıdır:
- Anti-corruption layer (ACL): Eski sistemin önüne API gateway konur.
- Capability-by-capability migration: Önce müşteri yönetimi modernize edilir, sonra hesap, sonra ödemeler.
- Dual write: Yeni sistem üretime alındığında eski + yeni paralel çalışır; veriler synchronize edilir.
- Cutover: Yeni sistem stabil olduğunda eski modülün trafiği kesilir.
- Decommission: Eski modül kapatılır, lisans/donanım maliyeti ortadan kalkar.
Tipik bir orta ölçekli bankada (5-10 milyon müşteri) bu süreç 5-8 yıl, toplam yatırım 250-800 milyon USD‘dir. Yıllık tasarruf 60-180 milyon USD. Capability sırası belirlenirken iş etkisi (yeni ürün lansmanı) + risk (mevcut hacim) + bağımlılık (data lineage) matrisi kullanılır.
Event Sourcing ve CQRS
Modern core banking’de iki kritik kalıp:
Event Sourcing
Hesap bakiyesini “tek bir değer” olarak değil, bir event akışı olarak modeller: AccountOpened, Deposited, Withdrawn, InterestAccrued, vb. Bakiye, eventlerin toplamından her an türetilebilir. Avantajları:
- Tam denetim izi (her değişikliğin nedeni ve zamanı).
- Geçmiş zamanda bakiye sorgulanabilir (denetim için kritik).
- Yeni özellikler eski eventleri yeniden işleyerek üretilebilir.
- BDDK ve KKB raporlama daha güvenilir.
Event sourcing alt yapısı için event-driven architecture rehberimizde Kafka, Pulsar ve EventBridge karşılaştırması var — banka ölçeğinde günde 100M+ event için bu seçim kritik.
CQRS (Command Query Responsibility Segregation)
Yazma (komut) ve okuma (sorgu) ayrı modellerde tutulur. Mobil app’in “bakiyem ne?” sorgusu, transfer komutuyla aynı veritabanına gitmez. Bu mimari:
- Okuma p99 latency ≤ 50 ms (Redis veya read replica).
- Yazma p99 latency ≤ 200 ms (PostgreSQL veya event store).
- Okuma trafiği yazma sistemini etkilemez.
- Farklı read modelleri (mobil, BI, regülatör) bağımsız ölçeklenir.
BIAN Standardı ve Açık Bankacılık
BIAN (Banking Industry Architecture Network), bankacılık iş yeteneklerinin (capabilities) standardize edilmiş tanımıdır. 300+ “service domain” tanımlar (örn. Customer Onboarding, Payment Initiation, Credit Risk Assessment). Modern bir core banking dönüşümü, hizmetlerini BIAN’a uyumlu kurgular; bu Open Banking ve fintech entegrasyonlarını 3-5x hızlandırır.
Türkiye’de BKM Açık Bankacılık API’ları (PSD2 benzeri) 2024’ten beri zorunlu. Eski sistemlerle bu API’ları sunmak ya çok pahalı ya çok yavaş; modern mimari ile out-of-the-box gelir. API protokol seçimi için gRPC vs REST vs GraphQL rehberimiz internal vs external API kararında yol gösterici.
Performans, Ölçek ve Uptime
- Aylık uptime hedefi: %99,995 (yılda 26 dakika kesinti tavanı)
- FAST anlık ödeme: ≤ 1 saniye uçtan uca
- Mobil bakiye sorgu: ≤ 150 ms p99
- Günlük işlem hacmi: 10-100 milyon
- Pik saatte TPS (transaction per second): 5.000-50.000
- RPO (data loss tolerance): ≤ 1 saniye
- RTO (downtime tolerance): ≤ 15 dakika
Türkiye Yasal ve Düzenleyici Entegrasyonlar
- BDDK: Aylık ve günlük raporlama, BCH (Banking Capital Hardware) gereklilikleri.
- TCMB: EFT/FAST ödeme altyapısı, repo, kur müdahalesi.
- SPK: Yatırım hizmetleri, fon, türev.
- MASAK: AML/CFT raporlama, şüpheli işlem bildirimi.
- KKB / TBB Risk Merkezi: Müşteri kredi geçmişi.
- e-Devlet, KEP, MERNIS: KYC ve kimlik doğrulama.
- GİB: e-Fatura, stopaj, hesap özetleri.
Veri Migrasyonu: En Kritik Faz
Eski sistemden yeni sisteme veri geçişi, projenin en yüksek riskli kısmıdır. Pratik en iyi yaklaşımlar:
- Veriler kaynak sistemde “altın kayıt” (golden record) statüsünde tutulur.
- ETL pipeline gece batch ile çalışır; gündüz CDC (Change Data Capture) ile delta.
- Reconciliation: yeni sistemdeki bakiyeler eski ile 1 kuruşa kadar eşleşmeli.
- Veri kalitesi kuralları (validation rules) 1000+ adet olabilir.
- Paralel çalışma fazı: 3-6 ay boyunca eski + yeni paralel — her gece reconciliation.
CDC pipeline’ı için PostgreSQL logical replication ve Debezium rehberimiz teknik detayları içeriyor. Banka ölçeğinde tipik akış: Mainframe DB → CDC → Kafka → Stream Processing → New PostgreSQL/MongoDB.
Maliyet ve Süre
| Kapsam | Süre | Yatırım (USD) |
|---|---|---|
| Tek capability (örn. Payments) | 12-18 ay | 15-40 milyon |
| 3-4 capability | 24-36 ay | 80-180 milyon |
| Tam core modernization (5-10M müşteri) | 60-96 ay | 250-800 milyon |
| Bulut taşıma (cloud-native rewrite) | Ek 18-30 ay | +%30-50 |
Sektörel Örnek: Türk Bankasında Payments Capability Modernizasyonu
Top 10 içinde yer alan bir Türk bankasının ödemeler (EFT + FAST + Havale + SWIFT) capability’sinin modernizasyonu için 14 aylık bir programda çalıştık. Eski mainframe ödeme akışı pik saatte 1.200 TPS karşılayabiliyordu, %99,97 uptime’da çalışıyordu ama bakım penceresi haftada 4 saat. Yeni microservice + event sourcing mimarisinde: pik saatte 12.500 TPS, uptime %99,995, bakım penceresi sıfır (rolling deployment ile). FAST ödeme p95 latency 2,3 saniyeden 380 milisaniyeye indi. Yıllık operasyonel tasarruf: 22 milyon USD, müşteri NPS artışı +14 puan.
Migrasyon sırasında en kritik 3 ay: paralel çalışma fazı. Eski + yeni paralel ödeme işleyişi, gece her transferin 1 kuruşa kadar reconciliation’ı. Bu 90 günlük dual-write süreci olmadan production cutover %40 başarısızlık riski taşıyordu.
Anti-Pattern’ler: Core Modernization’da Sık Yapılan Hatalar
- “Big bang” cutover: Tüm capability’leri tek günde geçirmeye çalışmak — projelerin %64’ünde başarısız (Gartner).
- Reconciliation’ı %99 toleransla geçmek: Banka için her kuruş kritik. Reconciliation tam (%100) olmalı; tolerans yok.
- BIAN’a uyumsuz tasarım: Açık Bankacılık API’larını sonradan adapt etmek 2-3x maliyet.
- Event sourcing’i her capability’de zorla uygulamak: Bazı capability’ler (örn. statik müşteri verisi) için overkill. Doğru yer seçimi şart.
- Sadece teknik takım modernizasyon: İş birimi, operasyon, regülatör paralel hazırlanmazsa go-live çakılır.
- Bulut taşımayı sonraya bırakmak: On-prem refactor sonra cloud migration = 2x iş. Hibrit cloud-native başla.
- COBOL geliştiriciye bağımlı kalmak: 2026’da Türkiye’de aktif COBOL geliştirici 1.500’ün altında — kaynak yokluğu projeyi 12 ay geciktirebilir.
Sık Sorulan Sorular
Hazır core banking platformu mu (Temenos, Mambu) yoksa kendi yazılım mı?
Çoğu Türk bankası hibrit yaklaşır: çekirdek (mevduat, kredi, GL) için Temenos veya Mambu gibi hazır platform + farklılaşan müşteri deneyimi (mobil, açık bankacılık, AI) için özel yazılım. Tam custom build çok büyük (50+ milyon müşterili) bankalar için anlamlı; orta ölçekte hazır platform 30-40% daha hızlı go-live verir.
Bulut taşıma BDDK açısından mümkün mü?
Evet, BDDK 2022 itibarıyla bankaların özellikle Türkiye’de barındırılan bulut servislerini kullanmasına izin veriyor. AWS, Azure ve Google Cloud’un Türkiye bölgeleri uygun. Çekirdek müşteri verisi (CIF) yurt dışına çıkmamak şartıyla geniş bir kapsam mümkün.
COBOL geliştiriciler azalıyor — bu risk mi?
Evet ve hızla büyüyor. 2026’da Türkiye’de aktif COBOL geliştirici sayısı 1.500’ün altında; banka başına ortalama 4-12 kişi. Bu durum modernizasyonu zorunlu kılıyor — devam ettirme yerine yer değişimi şart.
Test ve sertifikasyon nasıl yapılır?
Kapsamlı test mimarisi gerekir: birim test (kapsam %85+), entegrasyon test, performans test (full TPS senaryosu), kaos test (Chaos Engineering), kullanıcı kabul test (UAT). Production’a almadan önce BDDK ve TCMB karşılıklı testleri gereklidir.
Açık bankacılık API’ları için ek mimari kararlar gerekiyor mu?
Evet. Açık bankacılık trafiği müşterinin kendi sistemine değil, 3. parti uygulamalara akar. Rate limiting, OAuth 2.0 + FAPI (Financial-grade API), idempotency key, sandbox ortam ve developer portal şart. Bunlar core banking’in dışına, dedicated API gateway katmanına konur.
Ömer Önal’dan pratik not: Core banking modernizasyon projelerinde danışmanlık verdiğim ekiplerde en kritik nokta, capability sıralaması. Bankalar genelde “ödemeler en kritik, oradan başlayalım” diyor — risk yüksek ama getiri de yüksek. Pratik tavsiyem: ilk capability olarak müşteri yönetimi (CIF) seçin. Hem riski düşük (statik veri ağırlıklı), hem tüm diğer capability’lerin altyapısı, hem de iş tarafına “365 derece müşteri görünümü” çıktı veriyor — bu görünür değer modernizasyon programının siyasi sermayesini koruyor. İkinci pratik: paralel çalışma fazını 3 ay’dan kısa tutmayın. Bizim danışmanlık verdiğimiz banklardan birinde 6 hafta paralel çalıştık, cutover sonrası 3 reconciliation hatası ortaya çıktı, 14 saat downtime + regülatör cezası geldi. 90 günlük dual-write para değil, sigorta. Üçüncüsü — BDDK ile haftalık iletişimde olun, big bang sürprizleri yok edin. Sizin bankanızda modernizasyonun en büyük korkusu cutover riski mi, BDDK uyumu mu, yoksa COBOL kaynak yokluğu mu?
Sonuç
Banka çekirdek modernizasyonu, projeleri “yazılım” değil “iş dönüşümü” olarak yönetilmeli. Doğru tasarım (Strangler + Event Sourcing + CQRS + BIAN) ile dönüşüm sonrası yeni ürün lansman süresi %85 azalır, müşteri başına operasyonel maliyet %32 düşer, açık bankacılık ve fintech ortaklıkları 3-5x hızlanır. Sektörel modernizasyon dinamikleri için sigorta modernizasyon rehberimize, hassas veri operasyonu için hukuk yazılımı rehberimize, ve perakende finansal akışlar için otomotiv yazılım rehberi de değerli. Fintech entegrasyonu için fintech ödeme sistemleri rehberi tamamlayıcı. İletişim formundan projeniz için detaylı yol haritası talep edebilirsiniz.
Dış otorite kaynaklar: BDDK · TCMB · BIAN Standard · Accenture Banking
Ömer ÖNAL
Mayıs 17, 2026Core banking modernizasyon projelerinde danışmanlık verdiğim banklarda en kritik karar, capability sıralaması. Genelde “ödemeler en kritik, oradan başlayalım” deniliyor — risk yüksek, getiri yüksek ama proje sermayesi de hızla tükeniyor. Pratik tavsiyem: ilk capability olarak müşteri yönetimi (CIF) seçin. Hem riski düşük (statik veri ağırlıklı), hem tüm diğer capability’lerin altyapısı, hem de iş tarafına “365 derece müşteri görünümü” çıktı veriyor — bu görünür değer modernizasyon programının siyasi sermayesini koruyor. İkinci pratik: paralel çalışma fazını 90 günden kısa tutmayın. Bir bankta 6 hafta paralel çalışmıştık, cutover sonrası 3 reconciliation hatası çıktı, 14 saat downtime + regülatör cezası geldi. Dual-write 3 ay para değil sigorta. Üçüncüsü — BDDK ile haftalık iletişimde olun, “big bang sürpriz” yok edilmeli; pre-flight check ve denetim demo’ları cutover öncesi yapılmalı. Sizin bankanızda modernizasyonun en büyük korkusu cutover riski mi, BDDK uyumu mu, yoksa COBOL kaynak yokluğu mu?