Fintech Uygulaması Geliştirme: Regülasyondan Canlıya

Fintech uygulaması geliştirmek, sıradan bir yazılım projesine benzemez. Ekranlar aynı görünür, teknoloji stack'i tanıdıktır, ama kurallar farklıdır. Bir e-ticaret uygulamasında bir bug kötü bir kullanıcı deneyimi demektir. Bir ödeme uygulamasında aynı bug, yanlış işlenmiş para, bozulan mutabakat ya da regülatörün sorusu demektir.

Biz bu işi production'da yapıyoruz. Ödeal için üye iş yeri ödeme panelini sıfırdan geliştirdik. Kayaport'un açık bankacılık platformu BulutTahsilat için 2.000'den fazla kurumsal müşterinin kullandığı mobil uygulamayı dört ayda canlıya çıkardık. Multinet'in operasyon platformunu web'e taşıdık, RUUF'un banka entegrasyonlu kirala satın al platformunu sıfırdan kurduk.

Bu yazı, bir fintech ürününü regülasyondan canlıya kadar götürürken CTO'ların vermesi gereken kararları anlatıyor. Teori değil, sahada karşılaştığımız gerçek kararlar.

Fintech uygulaması geliştirmeye nereden başlanır?

Koddan değil, lisans modelinden. Teknik gereksinimlerinizin büyük kısmını, hangi lisansla ve kimin altyapısı üzerinde çalıştığınız belirler.

Üç temel senaryo var:

• Kendi lisansınız var: Ödeme kuruluşu ya da elektronik para kuruluşuysanız TCMB'nin bilgi sistemleri gerekliliklerine doğrudan siz tabisiniz. Denetim, loglama, erişim yönetimi ve veri lokasyonu kararları sizin sorumluluğunuzda.

• Lisanslı bir kurumun altyapısını kullanıyorsunuz: Para hareketi iş ortağınızın lisansı altında gerçekleşiyorsa, gereksinimlerin bir kısmı onların tarafında kalır. Ama entegrasyon sözleşmeniz size de teknik yükümlülükler getirir.

• Bir bankaya ya da lisanslı kuruma yazılım geliştiriyorsunuz: Bu durumda müşterinizin uyum ekibi sizin de müşterinizdir. BDDK ya da TCMB kurallarını onların gözüyle okumanız gerekir.

BulutTahsilat projesinde üçüncü senaryodaydık. Kayaport regülasyona tabi bir kuruluş ve uygulamanın her akışı, kimlik doğrulamadan işlem listelemeye kadar, ilk günden Türk bankacılık uyum standartlarını karşılamak zorundaydı. Bu kararları sonradan eklemek mümkün değildi, mimarinin içine baştan yerleştirdik.

Hangi regülasyonlar yazılımı doğrudan etkiler?

Hukuki detaylar uyum ekibinizin işi. Ama bir CTO'nun şu beş başlığın yazılıma etkisini bilmesi gerekir:

• TCMB: Ödeme ve elektronik para kuruluşlarını düzenler. Bilgi sistemlerinin yönetimi, sistemlerin yurt içinde tutulması, iş sürekliliği ve cloud kullanımı konusunda kurallar koyar. Cloud tercihi yapmadan önce bu kuralları okuyun.

• BDDK: Bankaları düzenler. Bir bankaya entegre oluyorsanız ya da bir banka için yazılım geliştiriyorsanız, bankanın güvenlik ve denetim beklentileri sizin backlog'unuza girer.

• BKM: Kartlı ödeme altyapısının merkezinde yer alır ve açık bankacılık tarafında da önemli bir rol oynar. Kart ve banka entegrasyonlarında BKM standartlarıyla karşılaşırsınız.

• PCI DSS: Kart verisine dokunuyorsanız geçerlidir. En pratik kural: kart verisini mümkün olduğunca hiç tutmayın. Tokenization ve lisanslı bir ödeme sağlayıcısının hosted sayfaları, PCI DSS kapsamını ciddi ölçüde daraltır.

• KVKK: Kişisel veri işleyen her sistemi kapsar. Fintech'te kimlik belgesi, adres ve finansal geçmiş gibi hassas veriler işlendiği için veri minimizasyonu ve saklama süreleri tasarımın parçası olmalı.

Bu başlıkların yazılımdaki karşılığı genellikle aynı listedir: her kritik işlem için değiştirilemez audit log, rol bazlı erişim kontrolü, şifreli veri saklama, oturum yönetimi, düzenli penetrasyon testi ve kimin neye ne zaman eriştiğini gösterebilen bir izleme altyapısı.

Fintech ürününde mimari nasıl kurulmalı?

Fintech'te en pahalı hata, ilk sürümü "sonra düzeltiriz" mantığıyla kurmaktır. Çünkü para taşıyan bir sistemi canlıdayken yeniden yazmak, sıfırdan yazmaktan çok daha risklidir.

Ödeal bize geldiğinde üye iş yeri paneli çalışıyordu ama ölçeklenmiyordu. Yol haritasındaki özelliklerin yaklaşık %70'i yoktu ve yeni bir modül eklemek, ilgisiz kod parçalarına dokunmak anlamına geliyordu. Paneli Next.js ve TypeScript üzerinde micro frontend mimarisiyle yeniden kurduk. İşlemler, mutabakat, itirazlar, hesap yönetimi ve raporlama bağımsız olarak deploy edilebilen birimlere dönüştü. Eksik %70'lik özellik seti tek seferde canlıya çıktı.

Bu projeden çıkardığımız üç ilke:

• Domain sınırlarını baştan çizin. İşlem, mutabakat, kullanıcı ve raporlama farklı hızlarda değişir. Aynı kod tabanında sıkışırlarsa her release bütün sistemi riske atar.

• RBAC'ı ilk günden kurun. Tek terminalli bir fırınla çok şubeli bir perakende zincirinin erişim ihtiyacı aynı değildir. Rol bazlı erişimi sonradan eklemek, her ekranı yeniden elden geçirmek demektir.

• Audit log bir özellik değil, altyapıdır. Hassas her işlemin kim tarafından, ne zaman ve hangi değerlerle yapıldığı kaydedilmeli. Denetim geldiğinde bu kayıtları geriye dönük üretemezsiniz.

Backend tarafında da aynı mantık geçerli. RUUF'ta kirala satın al modelinin işlemsel karmaşıklığını taşımak için .NET, PostgreSQL ve Redis üzerinde bir microservices mimarisi kurduk. Taksit takibi, ödeme işleme ve banka entegrasyonları kendi servislerinde yaşadı. Bu sayede regülasyon tarafında bir kural değiştiğinde, değişiklik tek bir servisle sınırlı kaldı.

Banka ve açık bankacılık entegrasyonları nasıl planlanır?

Banka entegrasyonu, fintech projelerinin takvimini en çok şaşırtan kalemdir. Her bankanın API'si, test ortamı, kimlik doğrulama yöntemi ve hata davranışı farklıdır. Dokümanda yazanla production'da olan da her zaman aynı değildir.

BulutTahsilat Türkiye'deki tüm büyük bankalara bağlanıyor, hesap hareketlerini ve POS işlemlerini gerçek zamanlı topluyor. Mobil uygulamayı bu ölçeğe göre kurarken öğrendiklerimiz:

• Her bankayı ayrı bir entegrasyon olarak planlayın. "Bir bankayı bağladık, diğerleri de benzer" varsayımı takvimi bozar. Her banka için ayrı test, ayrı hata senaryosu ve ayrı izleme gerekir.

• Idempotency zorunludur. Ağ hatası yüzünden tekrarlanan bir istek, ikinci bir ödeme yaratmamalı. Her para hareketi benzersiz bir anahtarla işlenmeli.

• Mutabakatı ilk sprintte tasarlayın. Sizin kayıtlarınızla bankanın kayıtları er ya da geç ayrışacak. Bu farkı otomatik yakalayan bir mutabakat akışı olmadan finans ekibi Excel'e mahkum kalır.

• Açık bankacılık standartlarını takip edin. Türkiye'de açık bankacılık, TCMB'nin ödeme hizmetleri veri paylaşım servisleri çerçevesinde ilerliyor. Hesap bilgisi ve ödeme emri servislerini bu standartlara göre kurmak, her banka için ayrı adaptör yazma yükünü azaltır.

Bu yaklaşımla BulutTahsilat uygulaması dört ayda canlıya çıktı. Bu kapsamdaki bir uygulama için çoğu ekibin tutturamayacağı bir takvim. Hızlı çıkabildik, çünkü bu tür işi daha önce yapmıştık.

Fintech mobil uygulamasında güvenlik nasıl sağlanır?

Mobil tarafta güvenlik, framework seçiminden çok implementasyonla belirlenir. Bir fintech mobil uygulamasında olması gereken minimum liste:

• Biyometrik kimlik doğrulama ve donanım destekli güvenli anahtar saklama (iOS Keychain, Android Keystore)

• SSL pinning ile man-in-the-middle saldırılarına karşı koruma

• Root ve jailbreak tespiti

• Release build'lerde kod obfuscation

• Hassas ekranlarda ekran görüntüsü ve uygulama değiştirici önizlemesinin engellenmesi

• Token süreleri ve cihaz bazlı oturum yönetimi

Fintech mobil projelerinde varsayılanımız React Native. Securitas Alarm'ın iki ayrı native kod tabanını tek bir React Native uygulamasına taşıdık; aynı işi iki geliştirici yerine bir geliştirici yapar hale geldi. Framework kararını detaylı konuştuğumuz Flutter mı React Native mi yazımıza da göz atabilirsiniz.

Store tarafında da fintech'e özel bir detay var: Apple, finansal hizmet sunan uygulamaların hizmeti veren kurumun kendi geliştirici hesabından yayınlanmasını istiyor. Google Play de finansal özellikler için ayrı bir beyan talep ediyor. Bunu son haftaya bırakırsanız lansman tarihiniz kayar.

Fintech ürünü büyürken hız nasıl korunur?

İlk sürümü çıkarmak bir iştir, ürün büyürken hızı korumak başka bir iş. Fintech ürünlerinde ekran sayısı hızla artar: paneller, raporlar, onay akışları, back-office araçları.

Multinet, Türkiye'nin önde gelen yemek kartı ve yan hak şirketlerinden biri. On yıllık masaüstü operasyon platformunu web'e taşırken önce iki temeli kurduk: bir tasarım sistemi ve Vue.js ile TypeScript üzerinde bir frontend component kütüphanesi. Üzerine micro frontend mimarisini oturttuk. Sonuç, geliştirme hızında %81 artış oldu. Daha önce sıfırdan yazılan ekranlar artık test edilmiş ortak parçalardan birleştiriliyor.

Fintech'te component kütüphanesi sadece hız meselesi değildir. Tutar gösterimi, para birimi formatı, onay adımları ve hata mesajları her ekranda aynı davranmalıdır. Bunu tek bir yerde çözmek, hem kullanıcı güvenini hem denetim tutarlılığını korur.

Canlıya çıkmadan önce neler kontrol edilmeli?

Fintech'te lansman bir tarih değil, bir süreçtir. Canlıya çıkmadan önce şu listeyi tamamlamış olmak gerekir:

• Bağımsız bir penetrasyon testi ve bulguların kapatılması

• Production'a birebir benzeyen bir staging ortamında uçtan uca ödeme testleri

• Banka ve ödeme sağlayıcılarının sertifikasyon adımlarının tamamlanması

• Log, metrik ve alert altyapısının kurulması; kimse bakmıyorken bir ödemenin başarısız olduğunu size söyleyecek bir sistem

• Feature flag ile kademeli açılış; yeni bir ödeme akışını önce kullanıcıların küçük bir kısmına açmak

• Geri dönüş planı: bir release sorun çıkarırsa beş dakikada önceki sürüme dönebiliyor musunuz?

Bir fintech uygulaması ne kadar sürede canlıya çıkar?

Kapsama göre değişir, ama gerçekçi referans noktaları var. Odaklı bir fintech MVP'si 90 günden kısa sürede canlıya çıkabilir. Bunun için kapsamın net olması, lisans modelinin belli olması ve ekibin fintech'i daha önce görmüş olması gerekir. BulutTahsilat gibi çok bankalı ve regülasyona tabi bir mobil uygulama dört ayda canlıya çıktı. Mevcut bir platformun modernizasyonu ise genellikle kademeli ilerler; Ödeal ve Multinet'te sistem çalışmaya devam ederken yeni mimariye geçtik.

Takvimi en çok uzatan şey kod değil, belirsizliktir: netleşmemiş lisans modeli, sonradan eklenen uyum gereksinimleri ve banka entegrasyonlarının hafife alınması.

Ekibi içeride mi kurmalı, partnerle mi ilerlemeli?

Uzun vadede fintech ürününüzün kritik bilgisinin şirketinizde kalması gerekir. Ama bu, her şeyi içeride kurmanız gerektiği anlamına gelmez. Kıdemli bir fintech mühendislik ekibi kurmak aylar sürer ve çoğu ürünün o ayları yoktur.

RUUF'un CTO'su da geliştiricisi de yoktu. Ürün ve mühendislik ekibi olarak biz devreye girdik ve platform, RUUF'un yatırım turunu kapatmasına imkan veren bir takvimde canlıya çıktı. Domino's Türkiye'de ise tam tersini yaptık: mevcut ekibe kıdemli bir React Native geliştiricisi kattık ve üç aylık hedef tutturuldu.

Doğru model, ekibinizin bugün nerede olduğuna bağlı. Sıfırdan başlıyorsanız bir ürün ekibi, ekibiniz varsa kapasite desteği, belirli bir darboğazınız varsa 2-4 haftalık odaklı bir Delivery Sprint daha mantıklı olabilir.

Sonuç

Fintech uygulaması geliştirmenin zor kısmı ekranlar değil, ekranların arkasındaki kurallardır. Lisans modelini baştan netleştirin, regülasyonun yazılımdaki karşılığını mimarinin içine yerleştirin, banka entegrasyonlarını ayrı birer proje gibi planlayın ve canlıya çıkışı kademeli yapın.

Bu kararları daha önce production'da vermiş bir ekiple çalışmak, öğrenme maliyetini sizin projenizden çıkarır. Fintech yazılım geliştirme tarafında neler yaptığımıza göz atabilir, ürününüzü konuşmak için bizimle iletişime geçebilirsiniz.