banka

Banka denildiğinde çoğu kişi şubeleri, kredi kartlarını ve hesap bakiyelerini düşünür. Oysa bir yazılım mühendisi için banka, dağıtık bir sistemin en zorlu sınavıdır. Hesap hareketlerinin tutarlılığı, milisaniyelik yetkilendirme akışları, düzenleyici denetimler ve kesintisiz hizmet beklentisi aynı anda karşılanmak zorundadır. Bu metin, bankayı finansal bir kurum olarak değil; eş zamanlılık, veri bütünlüğü, güvenlik ve gözlemlenebilirlik problemleriyle dolu bir yazılım platformu olarak ele alıyor.

Bir banka backend'inde yaşanan tek bir hatalı güncelleme, ulusal ödeme ağındaki tüm POS terminallerini saniyeler içinde etkisiz hale getirebilir. Üretim ortamlarında karşılaştığımız bu tür riskler, bankacılık mühendisliğini sıradan CRUD uygulamalarından keskin biçimde ayırır. Aşağıda, modern bir banka platformunu inşa ederken ve işletirken öne çıkan teknik katmanları, gerçek dünya kısıtlarıyla birlikte inceliyoruz.

Banka Terimi Teknoloji Dünyasında Neden Yeniden Tanımlanıyor?

Geleneksel anaçatı (mainframe) sistemleri hâlâ birçok bankanın çekirdeğini oluşturur; COBOL, CICS ve DB2 üzerinde çalışan hesap modülleri onlarca yıldır güvenilirliğini kanıtlamıştır. Ancak bulut bilişim, API ekonomisi ve gerçek zamanlı ödeme talepleri, bankayı çift hızlı bir mimariye zorluyor. Bir yanda yavaş değişen kayıt sistemleri, diğer yanda hızla evrilen müşteri deneyimi katmanları bulunur.

Bu ayrım, bankanın yalnızca bir "defter" olmadığını gösterir. Banka; hesap açılışından kredi tahsisine, anlık bildirimden dolandırıcılık skorlamasına kadar yüzlerce servisin orkestre edildiği bir platformdur. Mühendisler artık bir banka uygulamasını monolit olarak değil; sınırları iyi çizilmiş, sözleşmelerle konuşan modüler servisler bütünü olarak tasarlamak zorundadır.

Çekirdek Bankacılık Sistemlerinde Gerçek Zamanlı Mutabakat Mimarisi

Bir banka hesabındaki bakiye, ikiden fazla servis aynı anda güncelleme yaparsa hızla bozulabilir. Örneğin kartlı ödeme, ATM çekimi ve EFT girişi aynı milisaniyede işlenirse, iyimser kilitleme veya dağıtık kilit mekanizmaları devreye girmedikçe kayıp güncelleme yaşanır. Üretim ortamlarımızda PostgreSQL'in SELECT. FOR UPDATE satır kilidini, Redis tabanlı dağıtık kilitleri ve bazen Kafka'nın log-compacted topic'lerini birlikte kullanıyoruz.

Mutabakat yalnızca veri tabanı seviyesinde değil, iş akışı seviyesinde de tasarlanmalıdır. Bir transfer; rezervasyon, borçlandırma, alacaklandırma ve bildirim adımlarından oluşur. Bu adımlardan biri başarısız olursa, banka operasyon ekibi ters işlem başlatmak yerine otomatik dengeleyici saga desenini çalıştırmalıdır. Temporal veya Camunda gibi iş akışı motorları, uzun süren para transferlerini durum makinesi olarak yönetmek için güçlü araçlardır.

ISO 8583 ve Ödeme Mesajlaşma Protokollerinin Teknik Evrimi

Kartlı ödemelerin omurgası hâlâ büyük ölçüde ISO 8583 mesajlaşma standardına dayanır. Bu standart; işlem kodu, PAN, işlem tutarı ve yanıt kodu gibi alanları bit düzeyinde tanımlar. Yıllar içinde ISO 20022'ye geçiş konuşulsa da ATM ve POS ağlarında ISO 8583'ün türevleri yaygın olarak kullanılmaya devam ediyor. Geliştiriciler için asıl zorluk, bu ikili formatı modern JSON tabanlı API'lerle uyumlu hale getirmektir.

Pratikte bir ödeme anahtarlama servisi, gelen ISO 8583 mesajını parse eder, risk motoruna sorar, hesap bakiyesini kontrol eder ve yanıt kodunu 100 ms'nin altında döndürmek zorundadır. JPos, jPOS-CMF veya özel Netty tabanlı codec'ler bu dönüşümde sıklıkla tercih edilir. Performans testlerinde JMeter veya Gatling ile saniyede binlerce mesaj üretmek, banka altyapısının kapasite sınırlarını anlamak için kritik önem taşır.

• ISO 8583: Kartlı işlemler için ikili mesaj formatı
• ISO 20022: Yeni nesil zengin verili ödeme mesajları
• Netty: Yüksek verimli ağ çerçevesi
• Gatling: Gerçekçi yük testi senaryoları

Dağıtık Banka Platformlarında Veri Tutarlılığı ve İdempotensi

Ağ çağrıları tekrar edebilir. Bir mobil banka uygulaması, kullanıcı transfer butonuna iki kez basarsa veya ödeme ağ geçidi zaman aşımı sonrası aynı isteği tekrar gönderirse, banka sunucusu aynı işlemi iki kez gerçekleştirmemelidir. İdempotensi, banka API'lerinin olmazsa olmazıdır. Her finansal istek, istemci tarafından üretilen benzersiz bir Idempotency-Key başlığı taşımalı ve sunucu bu anahtarı belirli bir süre saklamalıdır.

Veri tutarlılığı için çift yazma (dual-write) deseninden kaçınmak gerekir. Bunun yerine transactional outbox deseni, veri tabanı işlemi ile mesaj kuyruğuna yazmayı atomik hale getirir. Örneğin bir banka transferi tamamlandığında, outbox tablosuna bir kayıt eklenir; Debezium veya benzeri bir CDC aracı bu kaydı Kafka'ya taşır. Böylece hesap servisi ile bildirim servisi arasındaki tutarlılık, dağıtık işlem olmadan sağlanır.

Banka Uygulamalarında Kimlik Doğrulama ve Erişim Kontrolü

Bir banka mobil uygulamasına giriş yapmak, çoğu zaman kullanıcı adı ve paroladan fazlasını gerektirir. OAuth 2. 0 ve OpenID Connect, RFC 6749 çerçevesinde erişim belirteçlerini standartlaştırır. Yenileme belirteçleri ise istemci cihazda güvenli depolama gerektirir; Android Keystore ve iOS Keychain bu noktada devreye girer.

Erişim kontrolü yalnızca oturum açmayı değil, hassas işlemler için adım adım doğrulamayı da kapsar. Yüksek tutarlı transferler, yeni alıcı ekleme veya limit artırma gibi aksiyonlar ikinci faktörle onaylanmalıdır. OWASP API Security Top 10 listesindeki BOLA ve kırık nesne düzeyi yetkilendirme riskleri, banka API'lerinde düzenli güvenlik denetimleriyle taranmalıdır. bankacılık API güvenliği rehberi yazımızda bu denetimlerin detaylarını bulabilirsiniz

Banka Mobil Uygulamalarında Kullanıcı Deneyimini Korumak

Kullanıcılar bir banka uygulamasından yalnızca güvenli değil, hızlı da olmasını bekler. Ekran geçişleri 200 ms'yi aştığında algılanan performans düşer. Bu nedenle API yanıt süreleri kadar istemci tarafı önbellekleme, istek birleştirme ve grafik optimizasyonu da banka mobil ekiplerinin sorumluluğundadır.

Çevrimdışı destek artık bir lüks değildir. Uçak modunda bakiye görüntüleme veya son işlemleri listeleme, yerel veritabanında tutulan güvenli kopyalarla mümkün olur. Burada dikkat edilmesi gereken, hassas verilerin cihazda şifreli tutulmasıdır. SQLCipher veya Realm Encryption gibi kütüphaneler, disk üzerinde açık metin veri bırakılmasını engeller. Banka uygulamalarında her yerel kayıt, banka bilgi güvenliği politikalarıyla uyumlu olmalıdır.

Banka Verileri İçin Gözlemlenebilirlik ve Anomali Tespiti

Bir banka platformunda hata yalnızca istisna loglarıyla yakalanamaz. Yavaşlayan bir ödeme servisi, artan gecikme yüzdeleri veya ani başarısız işlem oranı; kesinti başlamadan önce sinyal verir. OpenTelemetry ile otomatik enstrümantasyon, Prometheus metrikleri ve Grafana panoları, bu sinyalleri görünür kılar. SRE ekipleri, altın sinyaller olan gecikme, trafik, hata ve doygunluk metriklerini banka servislerinin tamamında izlemelidir.

Anomali tespiti yalnızca altyapı için değil, işlem davranışları için de gereklidir. Bir hesaptan kısa sürede çok sayıda küçük transfer yapılması, kara para aklama veya hesap ele geçirme işareti olabilir. Kafka akışları üzerinde çalışan Flink veya ksqlDB sorguları, bu desenleri gerçek zamanlı yakalayabilir. Üretim ortamlarımızda, işlem başına risk skoru hesaplayan bir banka servisini, ortalamanın üç standart sapma üzerine çıkan davranışları otomatik dondurmak için yapılandırdık.

Banka Dolandırıcılık Önleme Sistemlerinde Makine Öğrenmesi

Kural tabanlı sistemler tek başına yeterli değildir. Dolandırıcılar sürekli değişen teknikler kullanır; model tabanlı yaklaşımlar, bu değişime daha hızlı uyum sağlar. Bankalar, özellik gradyan artırma (XGBoost, LightGBM) veya derin öğrenme modelleriyle işlemleri puanlar. Ancak önemli olan yalnızca model doğruluğu değil, yanlış pozitif oranının düşük tutulmasıdır; çünkü müşterinin normal işlemini engellemek güven kaybı yaratır.

Model eğitimi için etiketli veri her zaman temiz değildir. Geçmiş dolandırıcılık kayıtları az olabilir; bu yüzden denetimsiz öğrenme veya izolasyon ormanı gibi anomali algoritmaları devreye girer. Ayrıca modelin açıklanabilirliği, düzenleyici denetimler için kritik önemdedir. SHAP değerleri, hangi özelliklerin red kararına yol açtığını göstererek banka iç denetim ekiplerine şeffaf bir açıklama sunar fintech altyapı mimarisi yazımızda model sunum altyapısını inceledik

Banka Altyapısında Dayanıklılık ve Felaket Kurtarma Testleri

Banka sistemleri için yüksek erişilebilirlik hedefi genellikle %99,99 veya daha yukarısıdır. Bu hedef, tek bölge dağıtımıyla karşılanamaz. Kubernetes üzerinde çalışan servisler, birden çok kullanılabilirlik bölgesine yayılmalı; veri tabanları ise senkron replikasyonla korunmalıdır. Kubernetes'in dayanıklılık kavramları, pod anti-affinity ve topology spread constraints gibi özelliklerle bu dağıtımı kolaylaştırır.

Felaket kurtarma yalnızca yedek almaktan ibaret değildir. Düzenli kaos mühendisliği deneyleri, bağımlılık kaybına karşı sistemi test eder. Chaos Mesh veya Litmus gibi araçlarla ağ gecikmesi, pod silme ve veri tabanı yük devri senaryoları simüle edilir. Bir banka için kurtarma hedefi yalnızca dakikalarla ölçülür; RTO ve RPO metrikleri, iş sürekliliği planının teknik temelini oluşturur.

Açık Bankacılık ve API Güvenliği: Banka Kaynaklarına Erişim

Açık bankacılık, üçüncü taraf finansal uygulamaların müşteri izniyle hesap verilerine erişmesini sağlar. Bu model, banka kaynaklarını dış dünyaya açarken sıkı yetkilendirme gerektirir. OAuth 2. 0 yetkilendirme kodu akışı, PSD2 ve BDDK düzenlemeleri kapsamında yaygın olarak kullanılır. Sertifika tabanlı istemci doğrulaması, eIDAS uyumlu imzalar ve dinamik kullanıcı onayı bu akışın ayrılmaz parçalarıdır.

API trafiği arttıkça oran sınırlama, kota yönetimi ve geri çekilme stratejileri hayati hale gelir. Bir üçüncü taraf, banka API'sini aşırı sorgulayarak çekirdek sistemi yavaşlatabilir. API ağ geçitleri; Kong, APISIX veya AWS API Gateway, bu trafiği merkezi olarak yönetir. Her banka API anahtarı, izin verilen uç noktalarla ve çağrı limitleriyle ilişkilendirilmelidir. SRE için gözlemlenebilirlik yazımızda API metriklerinin nasıl izleneceğini anlattık

Banka Yazılımında Sık Sorulan Sorular

Aşağıda, banka teknolojileri hakkında mühendis ekiplerinden en sık gelen soruları derledik. Bu yanıtlar, üretim ortamı deneyimlerine ve açık standartlara dayanır.

Banka sistemlerinde en kritik teknik risk nedir?

Dağıtık işlemlerde veri tutarsızlığı en büyük risktir. Bir transferin yarısı işlenip diğer yarısı başarısız olursa hesap bakiyeleri bozulur. Saga deseni, outbox pattern ve idempotency anahtarları bu riski azaltır.

Banka API'lerinde hangi kimlik doğrulama standardı önerilir?

OAuth 2. 0 ve OpenID Connect, sektör standardıdır. Kullanıcı girişi için yetkilendirme kodu akışı, sunucular arası iletişim için client credentials akışı kullanılır. JWT belirteçleri yalnızca kısa ömürlü erişim için uygunken, yenileme belirteçleri güvenli cihaz deposunda saklanmalıdır.

Banka dolandırıcılık tespitinde makine öğrenmesi nasıl devreye alınır?

Önce kural tabanlı filtrelerle temiz bir veri kümesi oluşturulur, ardından XGBoost veya benzeri bir model eğitilir. Model, Kafka üzerinden akan işlemleri gerçek zamanlı puanlar; yüksek riskli işlemler ek doğrulamaya yönlendirilir. Yanlış pozitif oranını izlemek, müşteri deneyimi için kritik önemdedir,

Banka uygulamaları çevrimdışı çalışabilir mi

Evet, sınırlı işlevler çevrimdışı çalışabilir. Bakiye ve son işlemler gibi salt okunur veriler, şifreli yerel veritabanında önbelleğe alınabilir. Ancak para transferi gibi yazma işlemleri, ağ bağlantısı olmadan asla tamamlanmamalıdır.

Açık bankacılık API'leri nasıl güvence altına alınır,

OAuth 20 yetkilendirmesine ek olarak mTLS, API anahtarı yönetimi, oran sınırlama ve kullanıcı onayı kayıtları gereklidir. BDDK ve PSD2 gibi düzenlemeler, üçüncü taraf erişimlerinin denetlenebilir olmasını zorunlu kılar.

Sonuç: Banka Platformunu Mühendislik Disipliniyle Ele Almak

Banka, finansal bir kavram olmanın ötesinde; yüksek tutarlılık, düşük gecikme, güçlü güvenlik ve sürekli denetim gerektiren bir yazılım ekosistemidir. Bu metinde ele aldığımız mutabakat, idempotensi, gözlemlenebilirlik ve kimlik doğrulama başlıkları, yalnızca banka mühendisleri için değil, herhangi bir yüksek güvenilirlikli sistem inşa eden ekip için geçerlidir.

Teknik ekipler, banka altyapısını bir bütün olarak görmeli; veri tabanından mobil arayüze kadar her katmanı aynı disiplinle test etmelidir. Gerçek dünya kısıtları altında çalışan bir banka platformu, kağıt üzerinde mükemmel görünen mimarilerin cesaretini kırar. Bu yüzden deneyimlerinizi paylaşmak, sektördeki iyi pratikleri ileriye taşır.

Bu konudaki görüşlerinizi ve üretim ortamı deneyimlerinizi bekliyoruz. Eğer bankacılık altyapıları, dağıtık sistemler veya güvenlik denetimleri üzerine derinlemesine teknik içerikler ilginizi çekiyorsa, bültenimize abone olabilir veya fintech altyapı mimarisi yazımızı okuyabilirsiniz.

What do you think?

Banka çekirdek sistemlerinde ISO 20022'ye geçiş, kısa vadede maliyet ve karmaşıklık artırsa da uzun vadede API tabanlı ödeme ekosistemini hızlandırır mı, yoksa mevcut ISO 8583 altyapısı yeterince verimli mi?

Dağıtık banka sistemlerinde veri tutarlılığı için saga deseni mi, yoksa merkezi işlem koordinatörü mü daha iyi ölçeklenir ve operasyonel olarak yönetilebilir kalır?

Bankalarda makine öğrenmesi tabanlı dolandırıcılık tespiti, yanlış pozitifleri azaltmak için kural motorlarıyla birleştirilmeli mi, yoksa tamamen model otonomisine mi bırakılmalı?