Bir Bankayı Entegre Etmek Kolay. Kırk Bankayı Çalışır Tutmak Değil.

💡 Özet: Ana Çıkarımlar

• Tek bir banka entegrasyonu teknik olarak zor bir iş olmayabilir. Zorluk, birbirinden farklı 30-40 bağlantıyı kurmak ve değişikliklere rağmen çalışır tutmaktır.
• Regüle açık bankacılık servisleri ile bankaların kurumsal müşterilerine sunduğu doğrudan API ve web servislerini ayırmak gerekir. İlki için ortak standartlar var; bizim karşılaştığımız parçalı yapı ikincisiydi.
• Bir entegrasyon sağlayıcısından yalnızca API satın almıyoruz. Banka bazındaki farklılıkları izleme, normalleştirme ve bakım sorumluluğunun önemli bir bölümünü de devrediyoruz.
• Bu tercih teknik yükü azaltırken yeni bir güven sınırı yaratıyor. Erişim yetkileri, verinin nerede tutulduğu, olay yönetimi ve sağlayıcıdan çıkış planı kararın parçası olmalı.

Şirket içinde kullandığımız bir finans panelimiz var. Çeşitli ödeme servislerinden ve finansal sistemlerden gelen bilgileri burada topluyoruz.

Bir süre önce banka hesaplarındaki hareketleri de aynı panelde görüp göremeyeceğimiz soruldu. İlk tepkimiz oldukça iyimserdi: Artık açık bankacılık var. Bu işin bir standardı vardır, bankaları benzer biçimde entegre ederiz. Olmazsa da hazır bir servis kullanırız.

Birkaç bankanın dokümantasyonuna baktıktan sonra doğrudan entegrasyon cenderesine girmemeye karar verdik. Bir banka entegrasyon sağlayıcısı üzerinden bağlantıları kurduk. Veriyi sağlayıcıdan alıyor, kendi ihtiyacımıza göre hazırladığımız panelde görselleştiriyoruz.

Asıl sürprizi daha sonra, banka bağlantılarının tanımlandığı ayarlar ekranında gördüm.

Bir banka kullanıcı adı ve şifre istiyor. Bir başkası token veriyor. Kimisi OAuth benzeri bir akış kullanıyor, kimisi belirli IP adreslerinin tanımlanmasını bekliyor. Mobil bankacılıktan aktivasyon isteyen de var. Bir bankanın formunda iki alan bulunurken diğerinde on farklı alanla karşılaşıyorsunuz.

Hepsinden almak istediğimiz bilgi ise aşağı yukarı aynı: Hesaplar, bakiyeler ve hesap hareketleri.

Önce iki farklı dünyayı ayıralım

Burada önemli bir kavram ayrımı var. “Açık bankacılıkta standart yok” demek doğru değil.

Türkiye'de ödeme emri başlatma ve hesap bilgisi hizmetleri, yani ÖHVPS, regüle bir alan. TCMB'nin yayımladığı API standardı; hesap, bakiye ve hesap hareketi bilgilerinin alınması ile ödeme emri başlatılması için ortak bir teknik çerçeve tanımlıyor. Bu servisler BKM tarafından geliştirilen GEÇİT altyapısı üzerinden sunuluyor. Üstelik ÖHVPS 2.0.0 Mart 2026'da devreye alındı ve standardın kapsamı genişlemeye devam ediyor.

Bizim karşılaştığımız yapı bu standart servislerden farklıydı. Bankaların kurumsal müşterilerine doğrudan sunduğu hesap hareketi API'leri ve web servisleriyle çalışıyorduk. İncelediğimiz bu servislerde bankalar kendi ürünlerini, erişim yöntemlerini ve teknik sözleşmelerini ayrı ayrı tasarlamıştı. Örneğin Ziraat Bankası hesap hareketlerini XML web servisiyle sunarken, DenizBank kendi API portalında hesap ve kurumsal hesap hareketleri için ayrı API'ler yayımlıyor.

Bu ayrımın hukuki tarafı da yalnızca kullanılan teknolojiye bakılarak yapılamıyor. TCMB'nin ÖHVPS rehberi, banka ile müşterinin doğrudan sözleşme yaptığı ve üçüncü tarafın yalnızca teknik hizmet verdiği senaryo ile üçüncü tarafın bankalarla sözleşme yaparak müşteriye hesap bilgisi sunduğu senaryoyu farklı değerlendiriyor. Bu nedenle bir entegrasyonun kapsamını, sözleşmedeki muhataplık ve verinin izlediği yol belirliyor.

Yazının geri kalanında ele aldığım sorun, regüle açık bankacılık standardının yokluğu değil. Kurumların kendi hesap hareketlerine erişmek için kullandığı doğrudan banka servislerinde karşılaştığımız parçalı yapı.

Bir banka entegrasyonu neden kolay görünüyor?

Tek bir bankayı ele aldığınızda iş yönetilebilir.

Dokümantasyonu okursunuz. Test erişimini alırsınız. Kimlik doğrulama ve erişim düzenini kurarsınız. Hesap, bakiye ve hareket modellerini kendi veri modelinize eşlersiniz. Hata durumlarını ele alır, testleri tamamlar ve bağlantıyı üretime alırsınız.

Bankanın kullandığı yöntem eski veya alışılmadık olabilir. Bu, entegrasyonu otomatik olarak zor bir mühendislik problemi yapmaz. Yetkin bir ekip, kapsamı belli tek bir entegrasyonu makul sürede tamamlayabilir.

Fakat banka sayısı arttığında aynı işi yalnızca tekrar etmiyorsunuz. Her bağlantının kendine özgü küçük kararlarını ve istisnalarını da sisteminize taşıyorsunuz.

Birinde erişim bilgisi yenilenir. Birinde IP değişikliği için yeniden tanım gerekir. Bunlar yalnızca ilk görünen farklardır. Alan adları, hata kodları, sayfalama, bakım pencereleri, geriye dönük veri sınırları, tarih ve tutar gösterimleri ile mükerrer kayıtların nasıl ayırt edileceği de her banka için ayrıca doğrulanmalıdır.

İlk geliştirme bittiğinde iş bitmez. Banka servisindeki değişikliği fark etmek, bağlantının neden durduğunu bulmak, güncellemeyi yapmak, geriye dönük veride boşluk oluşup oluşmadığını kontrol etmek ve bütün bunları diğer bankaları bozmadan yayımlamak gerekir.

Tek bir banka için küçük görünen bakım maliyeti, 30-40 banka için sürekli bir operasyon işine dönüşür. Teknik güçlükten çok koordinasyon, takip ve sahiplik yükü büyür.

Sağlayıcıdan satın aldığımız şey yalnızca tek API değil

Tek noktadan banka entegrasyonu sunan firmaların yaptığı işe tekil bir bağlantı üzerinden bakınca “bunu biz de yaparız” demek kolay. Muhtemelen gerçekten de yaparız.

Ancak satın aldığımız şey yalnızca hesap hareketlerini döndüren bir uç nokta değil. Bankalarla ayrı ayrı bağlantı kurma, farklı veri modellerini ortak bir yapıya dönüştürme, erişim yöntemlerini izleme ve değişiklik çıktığında bağlantıyı yeniden çalışır hâle getirme sorumluluğunun önemli bir bölümünü de satın alıyoruz.

İncelediğimiz firmaların kendi rapor ekranları vardı. Biz bu ekranları kullanmak yerine yalnızca veriyi alıp kendi panelimizde göstermeyi tercih ettik. Çünkü bizim için değer, başka bir finans ekranına sahip olmak değil; banka verisini zaten kullandığımız operasyonel görünümün içine katmaktı.

Bu tercih, aracı katmanın işini basit veya değersiz yapmıyor. Tam tersine, değerinin nerede oluştuğunu daha iyi gösteriyor. Bir banka için yazılan adaptörde değil, bütün adaptörlerin sürekli çalışmasını sağlayan bakım kapasitesinde.

Ortak bir kurumsal erişim standardı neyi değiştirirdi?

Bankaların tüm ürünlerini ve iç sistemlerini aynı biçimde tasarlamasını beklemek gerçekçi değil. Yine de doğrudan kurumsal erişim servislerinde ortak bir taban sözleşme önemli bir fark yaratabilirdi.

En azından şu alanlarda ortak bir sektör profili düşünülebilir:

• Müşterinin ve uygulamanın tanımlanması
• Salt okunur hesap erişimi için yetkilendirme
• Hesap, bakiye ve hareket veri modelleri
• Hata kodları ve yeniden deneme davranışı
• Sürümleme, değişiklik bildirimi ve eski sürüm desteği
• Test ortamı ve bağlantı sağlığı kontrolleri

Böyle bir standart her bankayı içeride aynı teknolojiye zorlamaz. Dışarıya sundukları temel sözleşmeyi ortaklaştırır. Bankalar farklılaşmak istedikleri ürünlerde yine farklılaşabilir; aynı hesap hareketini almak için her defasında yeni bir erişim ve veri modeli öğrenme ihtiyacı azalır.

Regüle ÖHVPS tarafında ortak standardın mümkün olduğunu zaten görüyoruz. Benzer bir yaklaşımın kurumsal müşterilere sunulan doğrudan servislerde de yaygınlaşması, yalnızca geliştiricilerin işini kolaylaştırmaz. Entegrasyon maliyetini, sağlayıcı bağımlılığını ve pazara giriş eşiğini de düşürür.

Aracı katman yükü azaltırken yeni bir güven sınırı yaratıyor

Doğrudan entegrasyon yapmamak, güvenlik sorumluluğunu ortadan kaldırmıyor. Banka ile sistemimizin arasına yeni bir taraf ekliyor.

Bu durum, entegrasyon sağlayıcısının peşinen güvensiz olduğu anlamına gelmez. Fakat artık banka ve kendi sistemlerimizin yanında sağlayıcının erişim kontrollerine, veri işleme biçimine ve operasyonel sürekliliğine de güveniyoruz. Kararı yalnızca “kaç bankayı destekliyor?” ve “aylık fiyatı ne?” sorularıyla vermek bu yüzden yetersiz kalır.

En azından şu soruların açık cevapları olmalı:

• Banka erişim bilgilerini kim, nerede ve ne kadar süreyle saklıyor?
• Yetkiler yalnızca hesap okumayla sınırlandırılabiliyor mu?
• Finansal veri hangi ülkede tutuluyor, ne zaman siliniyor ve kimler erişebiliyor?
• Erişimler ve veri aktarımları için denetlenebilir kayıtlar var mı?
• Bir güvenlik olayı veya bağlantı kesintisi nasıl bildiriliyor?
• Sağlayıcıyla çalışmayı bıraktığımızda veriyi ve bağlantıları nasıl taşıyoruz?

Sağlayıcının kapalı kaynak olması bu sorulara kendiliğinden iyi cevap verdiği anlamına gelmez. Aynı şekilde açık kaynak bir adaptör koleksiyonu da kendiliğinden güvensiz değildir.

Açık kaynak kod, entegrasyonların nasıl çalıştığını görmemizi ve gerektiğinde değiştirmemizi sağlayabilir. Fakat 30-40 bankadaki değişiklikleri kimin izleyeceği, güvenlik güncellemelerini kimin yayımlayacağı ve bağlantı bozulduğunda kimin sorumluluk alacağı sorularını tek başına çözmez. Kod bulunabilir; sürdürülebilir sahiplik ayrıca kurulmalıdır.

Yapmak mı, satın almak mı?

Bir veya iki bankayla çalışan, kapsamı salt okunur erişimle sınırlı ve değişim sıklığı düşük bir sistem için doğrudan entegrasyon gayet makul olabilir. Ekip teknik ve operasyonel sahipliği üstlenebiliyorsa aracı katmana gerek kalmayabilir.

Banka sayısı büyüdükçe kararın ekonomisi değişiyor. Çok sayıda bağlantıyı izlemek şirketin ayırt edici yetkinliği değilse, bu sorumluluğu uzman bir sağlayıcıya devretmek daha rasyonel hâle geliyor. Burada ödenen bedeli yalnızca API ücreti olarak değil, sürekli bakım ve normalleştirme hizmetinin maliyeti olarak görmek gerekiyor.

Biz birkaç bankanın dokümantasyonunu gördükten sonra bu işi içeride büyütmemeyi seçtik. Bu karar entegrasyonun teknik olarak yapılamaz olmasından kaynaklanmadı. Yapılabilir bir işin, ihtiyaç duyduğumuz banka sayısında gereksiz bir bakım ürününe dönüşeceğini düşündük.

Yine de keşke doğrudan kurumsal banka servislerinde ortak bir taban daha yaygın olsaydı. O zaman şirketler kendi entegrasyonlarını yapma ile aracı kullanma arasında daha dengeli bir seçim yapabilirdi. Bugünkü parçalı yapı, teknik maliyetin yanında bankayla şirket arasına üçüncü bir taraf koymayı da çoğu kurum için varsayılan çözüm hâline getiriyor.

Tek bir bankayı entegre etmek zor olmayabilir. Asıl ürün, kırk bankayı bugün de yarın da çalışır tutabilmektir.

Bankacılık sektöründe çalışanların, özellikle kurumsal hesap hareketleri için bizim gözden kaçırdığımız ortak bir yöntem veya farklı bir uygulama varsa düzeltmelerini duymak isterim.