Açık Bankacılık API Mimarisi ve Gömülü Finans (Embedded Finance) Nedir, Nasıl Çalışır?

Finansal hizmetler sektörü, kapalı ana bilgisayar (mainframe) sistemlerinden açık, modüler ve API odaklı ekosistemlere doğru tarihsel bir dönüşüm yaşamaktadır. Kullanıcıların ve işletmelerin finansal işlemlerini gerçekleştirmek için yalnızca banka şubelerine veya bankaların kendi internet/mobil uygulamalarına bağımlı olduğu dönem geride kalmıştır. Günümüzde Açık Bankacılık (Open Banking) standartları ve Gömülü Finans (Embedded Finance) mimarileri sayesinde; e-ticaret pazar yerlerinden turizm rezervasyon platformlarına, kurumsal ERP yazılımlarından lojistik ve tedarik zinciri yönetim sistemlerine kadar finans dışı her türlü dijital platform, kendi arayüzü içerisinden doğrudan hesap sorgulama, anlık transfer, dijital cüzdan yönetimi, otomatik mutabakat ve ticari finansman hizmetleri sunabilmektedir. Özellikle Antalya'nın güçlü turizm, konaklama, tarım ticareti ve sınır ötesi hizmet ihracatı ekosisteminde faaliyet gösteren işletmeler için finansal akışların yazılımsal olarak otomatize edilmesi büyük bir operasyonel verimlilik ve iş gücü tasarrufu sağlamaktadır. Teknoloji Ofis tarafından hazırlanan bu kapsamlı mühendislik rehberinde; açık bankacılık API mimarisini, Türkiye'deki regülasyon ve BKM Geçit (API Gateway) standartlarını, OAuth 2.0 FAPI güvenlik protokollerini, çift kayıtlı muhasebe (Double-Entry Ledger) veri yapılarını ve gömülü finans sistemlerinin uçtan uca nasıl çalıştığını derinlemesine inceliyoruz.

1. Açık Bankacılık (Open Banking) ve Gömülü Finans Nedir?

Fintech ekosisteminin temel taşlarını oluşturan bu iki kavram, sıklıkla birbiriyle karıştırılsa da mimari katmanda birbirini tamamlayan farklı işlevlere sahiptir:

• Açık Bankacılık (Open Banking): Bankalar ve finansal kuruluşların (Hesap Hizmeti Sağlayıcılar - HHS), bireysel veya kurumsal müşterilerinin açık rızası (Explicit Consent) doğrultusunda finansal hesap verilerini ve ödeme başlatma yetkilerini, güvenli ve standartlaştırılmış Uygulama Programlama Arayüzleri (API) üzerinden lisanslı üçüncü taraf sağlayıcılarla (Yetkili Ödeme Hizmeti Sağlayıcılar - YOS) paylaşmasıdır. Açık bankacılıkta veri sahipliği tamamen müşteridedir; banka bu verinin güvenli emanetçisi ve servis sağlayıcısı konumundadır.
• Gömülü Finans (Embedded Finance): Finansal olmayan bir yazılım ürününün (SaaS), e-ticaret sitesinin, mobil uygulamanın veya sektörel bir B2B pazar yerinin, Hizmet Olarak Bankacılık (BaaS - Banking-as-a-Service) altyapılarını ve açık bankacılık API'lerini kullanarak kendi kullanıcı deneyimi (UI/UX) içerisine doğal bir şekilde ödeme alma, alt satıcı hakediş dağıtımı, dijital cüzdan, sanal/fiziksel kart ihracı veya sigorta gibi finansal fonksiyonları entegre etmesidir.

Mimari Vizyon: Açık bankacılık "verinin ve işlem yetkisinin kriptografik olarak korunan standart boru hatlarıyla taşınmasını" sağlarken, gömülü finans bu boru hatlarını ve çekirdek bankacılık servislerini kullanarak "finansal hizmeti kullanıcının ihtiyaç duyduğu iş akışının (context) tam içine görünmez biçimde yerleştirmeyi" ifade eder.

2. Türkiye ve Küresel Ekosistemde Açık Bankacılık Rolleri: HHS, HBHS ve ÖBHS

Avrupa Birliği'ndeki PSD2 (Payment Services Directive 2) direktifi, İngiltere Açık Bankacılık Standartları ve Türkiye Cumhuriyet Merkez Bankası (TCMB) tarafından yürürlüğe konulan Ödeme Hizmetleri ve Elektronik Para Kuruluşları düzenlemeleri ile Bankalararası Kart Merkezi (BKM) API İlkeleri, açık bankacılık ekosistemindeki teknik rolleri ve sorumluluk sınırlarını net bir şekilde tanımlamıştır:

1. Hesap Hizmeti Sağlayıcı (HHS / ASPSP - Account Servicing Payment Service Provider): Müşterinin vadesiz mevduat veya ödeme hesabını bünyesinde bulunduran banka veya elektronik para kuruluşudur. HHS'ler, ulusal standartlara uygun API uç noktalarını açmak, test (Sandbox) ortamlarını sağlamak ve üretim ortamında yüksek erişilebilirlik (SLA) sunmakla yükümlüdür.
2. Hesap Bilgisi Hizmeti Sağlayıcı (HBHS / AISP - Account Information Service Provider): Kullanıcının açık rızasıyla farklı bankalardaki hesap bakiyelerini, IBAN bilgilerini, anlık hesap hareketlerini ve işlem geçmişini güvenli API çağrılarıyla çekerek tek bir konsolide ekranda (örneğin bir kurumsal ERP, hazine yönetimi veya ön muhasebe yazılımında) birleştiren TCMB lisanslı kuruluştur.
3. Ödeme Emri Başlatma Hizmeti Sağlayıcı (ÖBHS / PISP - Payment Initiation Service Provider): Kullanıcının onayıyla, kullanıcının banka hesabından doğrudan alıcı hesabına (FAST - Fonların Anlık ve Sürekli Transferi veya havale/EFT altyapısı üzerinden) ödeme emri başlatan lisanslı kuruluştur. Bu model, geleneksel kartlı ödeme ağlarına güçlü bir alternatif olarak hesaptan hesaba (A2A - Account-to-Account) anında ödeme deneyimi sunar.
4. BKM API Geçidi (GEÇİT): Türkiye'de tüm HHS (bankalar) ve YOS'lerin (fintech ve ödeme kuruluşları) birbirleriyle noktadan noktaya (point-to-point) onlarca farklı entegrasyon yapması yerine, tek bir merkezi, standartlaştırılmış ve yüksek güvenlikli anahtarlama altyapısı üzerinden haberleşmesini sağlayan ulusal API ağ geçididir. Bu mimari, entegrasyon süresini aylardan haftalara indirmiştir.

Hizmet / Mimari Model	Temel İşlev	Teknik Veri Akışı ve Protokol	Kullanıcı Deneyimi ve İşletme Avantajı
HBHS (AISP - Hesap Bilgisi)	Çoklu banka hesap konsolidasyonu ve anlık bakiye/hareket izleme	Salt okunur (Read-Only) GET istekleri, ISO 20022 uyumlu JSON veri modeli	Antalya'daki çok şubeli bir işletmenin 8 farklı bankadaki hesaplarını tek ERP panelinden anlık izlemesi ve otomatik fatura-tahsilat eşleştirmesi.
ÖBHS (PISP - Ödeme Başlatma)	Hesaptan hesaba (A2A) doğrudan ödeme emri tetikleme	JWS imzalı POST istekleri, güçlü kimlik doğrulama (SCA) ve asenkron webhook bildirimi	Sepet adımında kart bilgisi girmeden, doğrudan mobil bankacılık onayıyla saniyeler içinde kesinleşen ödeme akışı.
BaaS (Banking as a Service)	Beyaz etiketli (White-label) hesap, sanal IBAN, cüzdan ve kart ihracı	RESTful/gRPC mikroservisler, olay güdümlü (Event-Driven) çekirdek bankacılık API'leri	Bir turizm, e-ticaret veya lojistik platformunun kendi tedarikçilerine platform içi özel cüzdan ve anlık hakediş dağıtımı sunması.

3. Açık Bankacılık API Güvenlik Mimarisi Nasıl Çalışır?

Finansal verilerin ve para transferi emirlerinin açık internet üzerinden taşınması, standart web API'lerinin çok ötesinde kriptografik güvenlik önlemleri gerektirir. Açık bankacılık sistemleri, OpenID Foundation tarafından geliştirilen FAPI (Financial-grade API) güvenlik profilini temel alır.

mTLS, OAuth 2.0, PKCE ve Güçlü Kimlik Doğrulama (SCA)

Bir YOS (örneğin bir finansal teknoloji uygulaması) ile HHS (banka) arasındaki her bir API çağrısı şu çok katmanlı güvenlik mimarisinden geçer:

• Karşılıklı TLS (Mutual TLS - mTLS 1.3): Standart HTTPS bağlantılarında yalnızca istemci (tarayıcı veya uygulama) sunucunun sertifikasını doğrular. Açık bankacılıkta ise taşıma katmanında (Transport Layer) çift yönlü doğrulama zorunludur. Hem YOS sunucusu hem de API Geçidi / HHS sunucusu, nitelikli elektronik sertifika hizmet sağlayıcıları tarafından üretilmiş X.509 istemci ve sunucu sertifikalarını ibraz ederek birbirlerinin kimliğini kriptografik olarak doğrular ve iletişim kanalını şifreler.
• OAuth 2.0, OpenID Connect ve PKCE: Kullanıcı hiçbir zaman internet bankacılığı şifresini veya PIN kodunu üçüncü taraf uygulamaya (YOS) vermez. Bunun yerine uygulama, arka kanaldan bankaya bir "Rıza Nesnesi" (Consent Object) kaydeder ve kullanıcıyı bankanın kendi mobil uygulamasına veya web doğrulama ekranına yönlendirir (App-to-App Redirection veya Decoupled Flow). PKCE (Proof Key for Code Exchange - RFC 7636) mekanizması kapsamında istemci rastgele bir code_verifier üretir ve bunun SHA-256 özetini (code_challenge) ilk istekte gönderir; yetkilendirme kodu (Authorization Code) jetona dönüştürülürken orijinal değer doğrulanarak araya girme (Man-in-the-Middle) ve kod çalma saldırıları engellenir.
• Güçlü Müşteri Kimlik Doğrulaması (SCA - Strong Customer Authentication): Kullanıcı bankanın kendi güvenli ortamına yönlendirildiğinde; bildiği bir unsur (şifre/PIN), sahip olduğu bir unsur (kriptografik anahtarla eşleştirilmiş mobil cihaz / SIM) ve doğasında olan biyometrik bir unsurdan (yüz tanıma veya parmak izi) en az ikisini kullanarak rızayı onaylar.
• Sertifikaya Bağlı JWT (Certificate-Bound Access Token) ve JWS Mesaj İmzalama: Onay sonrasında üretilen Access Token (Erişim Belirteci) çok kısa ömürlüdür (genellikle 5-15 dakika) ve mTLS istemci sertifikasının parmak izine (Thumbprint) bağlıdır (RFC 8705). Bu sayede token çalınsa dahi aynı özel anahtara ve mTLS sertifikasına sahip olmayan başka bir sunucudan kullanılamaz. Ayrıca gönderilen her ödeme emrinin HTTP gövdesi (JSON Payload), gönderici kurumun HSM (Donanım Güvenlik Modülü) içindeki özel anahtarıyla asimetrik olarak (RS256 veya PS256 algoritmalarıyla) imzalanır ve X-JWS-Signature başlığında (Detached JWS) taşınır. Böylece mesaj yolda değiştirilemez (Data Integrity) ve gönderici işlemi inkar edemez (Non-repudiation).

4. Adım Adım Açık Bankacılık API Çağrı Akışı (Sequence Flow)

Bir e-ticaret veya B2B tahsilat platformunda ÖBHS (Ödeme Başlatma) ve HBHS (Hesap Bilgisi) akışlarının arka planda nasıl çalıştığını adım adım inceleyelim:

1. Adım 1 - Rızanın Hazırlanması (POST /odeme-emri-rizasi veya /hesap-bilgisi-rizasi): YOS sunucusu; işlem tutarı, alıcı IBAN bilgisi (veya HBHS için talep edilen izin türleri: Temel Hesap Bilgisi, Bakiye Bilgisi, İşlem Geçmişi), rıza geçerlilik süresi ve benzersiz bir X-Request-ID ile imzalı rıza isteğini BKM Geçit üzerinden ilgili bankaya (HHS) iletir. Banka, rıza kaydını "Yetkilendirme Bekliyor" statüsünde oluşturur ve benzersiz bir RizaNo döner.
2. Adım 2 - Kullanıcı Yönlendirmesi (App-to-App / Universal Link) ve SCA Onayı: YOS uygulaması, kullanıcıyı RizaNo parametresiyle birlikte doğrudan kullanıcının telefonunda yüklü olan banka mobil uygulamasına yönlendirir. Kullanıcı mobil bankacılıkta biyometrik doğrulamasını yapar, hangi hesabından ne kadar ödeme yapılacağını (veya hangi hesaplarının hangi tarihe kadar paylaşılacağını) şeffaf biçimde görür ve onaylar.
3. Adım 3 - Yetkilendirme Kodu ve Token Rotasyonu: Banka, kullanıcıyı tek kullanımlık Authorization Code ile tekrar YOS uygulamasına yönlendirir. YOS sunucusu arka kanaldan (Back-channel) mTLS bağlantısıyla bu kodu ve code_verifier değerini göndererek Access Token ve Refresh Token alır. HBHS senaryolarında (örneğin 90 veya 180 günlük hesap izleme rızalarında), Access Token süresi doldukça Refresh Token Rotation mekanizması devreye girer: Her yenileme isteğinde eski Refresh Token iptal edilir ve yeni bir çift üretilir.
4. Adım 4 - İşlemin Tetiklenmesi (POST /odeme-emri veya GET /hesaplar): YOS, aldığı Access Token'ı yetkilendirme başlığına (Authorization Header) ekleyerek ödeme emrinin kesinleştirilmesi veya hesap hareketlerinin sayfalandırılmış (Pagination) olarak çekilmesi isteğini gönderir.
5. Adım 5 - Asenkron Webhook Bildirimi ve Otomatik Mutabakat: Banka FAST veya havale işlemini saniyeler içinde gerçekleştirir ve işlemin nihai durumunu ("Gerçekleşti") YOS'un güvenli Webhook uç noktasına JWS imzalı bir olay (Event) bildirimi olarak iletir. Platformdaki sipariş veya fatura insan müdahalesine gerek kalmadan anında kapatılır.

5. Gömülü Finans (Embedded Finance) ve BaaS Mühendisliği

Gömülü finans sistemleri kurulurken arka planda yüksek tutarlılık (Strong Consistency), atomiklik (ACID) ve hataya dayanıklılık (Fault Tolerance) prensipleri işletilmelidir. Mikroservis tabanlı bir gömülü finans mimarisi geliştirirken dikkat edilmesi gereken temel mühendislik kalıpları şunlardır (Detaylı bulut mimarisi için Mikroservis Mimarisi ve Bulut Tabanlı Kurumsal Yazılım Nedir, Nasıl Geliştirilir? rehberimize başvurabilirsiniz):

1. Idempotency (Eş Etkililik) ve Dağıtık Kilit (Distributed Lock) Yönetimi

Mobil ağ kopmaları veya zaman aşımları (timeout) nedeniyle bir ödeme veya para çekme isteği istemci tarafından yanlışlıkla iki kez gönderilebilir veya kullanıcı "Öde" butonuna art arda tıklayabilir. Finansal API'lerde her durum değiştirici (POST/PUT/PATCH) istek başlığında benzersiz bir Idempotency-Key (UUID v4 veya zaman sıralı UUID v7) taşınır:

• Sunucu isteği aldığında önce bu anahtarı atomik bir işlemle kontrol eder.
• Aynı anda paralel gelen mükerrer istekleri engellemek için hesap veya işlem bazında kısa süreli Dağıtık Kilit (Redis Redlock veya PostgreSQL SELECT ... FOR UPDATE satır kilidi) uygulanır.
• İşlem tamamlandığında üretilen HTTP yanıtı, Idempotency-Key ile ilişkilendirilerek saklanır; aynı anahtarla tekrar gelen isteklere işlem yeniden çalıştırılmadan doğrudan kaydedilmiş yanıt dönülür. Böylece mükerrer tahsilat veya bakiye düşümü riski matematiksel olarak sıfırlanır.

2. Değiştirilemez Çift Kayıtlı Muhasebe Defteri (Immutable Double-Entry Ledger)

Gömülü cüzdan, pazar yeri hakediş yönetimi veya BaaS sistemlerinde kullanıcı bakiyesi hiçbir zaman veritabanındaki tek bir users.balance sütununun UPDATE edilmesiyle yönetilmez. Bu yaklaşım hem yarış koşullarına (Race Conditions) açıktır hem de geçmişe dönük denetim (Audit) imkanı vermez. Bunun yerine endüstriyel finans yazılımlarında Çift Kayıtlı Muhasebe (Double-Entry Bookkeeping) veri modeli kullanılır:

• Yalnızca Ekleme Yapılabilen Defter (Append-Only Journal & Ledger Entries): Veritabanındaki defter tablosunda UPDATE ve DELETE yetkileri veritabanı seviyesinde kapatılır. Bir hata düzeltilecekse bile eski kayıt silinmez, ters kayıt (Reversal Entry) atılır.
• Borç ve Alacak Dengesi (Zero-Sum Invariant): Her finansal işlem (Transaction), en az iki defter satırından (Ledger Entry) oluşur: Bir hesaptan çıkan tutar (Debit / Borç) ve diğer hesaba giren tutar (Credit / Alacak). Sistemdeki tüm işlemlerin borç ve alacak toplamı her zaman birbirine eşit olmalı ve net fark sıfır çıkmalıdır.
• Bekleyen ve Kesinleşen Bakiye Ayrımı (Pending vs Settled Balance): Bir transfer başlatıldığında tutar önce "Kullanılabilir Bakiye" hesabından "Blokeli / İşlemdeki Bakiye" alt hesabına aktarılır; bankadan kesinleşme webhook'u geldiğinde ise "Blokeli Bakiye" hesabından düşülerek alıcı hesabına aktarılır.

3. Dağıtık İşlemlerde Saga ve Transactional Outbox Kalıbı

Sipariş mikroservisi, gömülü cüzdan mikroservisi ve dış banka API'si arasındaki işlemlerde iki aşamalı kesinleştirme (2PC) yerine Saga Deseni ve Transactional Outbox kalıbı kullanılır. Defter kaydı ilişkisel veritabanına yazılırken aynı veritabanı işlemi (Transaction) içinde outbox_events tablosuna da olay kaydı eklenir. Bir arka plan işçisi (CDC / Debezium veya Poller) bu olayı okuyup mesaj kuyruğuna (Apache Kafka / RabbitMQ) iletir; herhangi bir dış adımda kalıcı hata oluşursa telafi edici ters işlem (Compensating Transaction) otomatik olarak tetiklenir.

6. Antalya İş Ekosisteminde Açık Bankacılık ve Gömülü Finans Senaryoları

Antalya'daki ticari işletmeler ve teknoloji girişimleri için açık bankacılık ve gömülü finans, E-Ticaret ve kurumsal yönetim süreçlerinde somut rekabet avantajları yaratmaktadır:

• Turizm ve Konaklama Ekosisteminde Otomatik Tedarikçi ve Acente Mutabakatı: Belek, Kemer, Lara, Side ve Alanya'daki otel grupları ve seyahat acenteleri; yüzlerce gıda, tekstil, transfer ve teknik ekipman tedarikçisiyle çalışır. Otelin ERP sistemi, HBHS API'leri sayesinde tüm banka hesaplarındaki hareketleri gerçek zamanlı çeker, gelen ödemeleri rezervasyon (Voucher) veya fatura numaralarıyla otomatik eşleştirir ve tedarikçi hakedişlerini ÖBHS API'leri üzerinden tek tuşla toplu olarak başlatır. Turizmde otomasyonun diğer boyutları için Antalya Turizm ve Otelcilik Sektöründe Yapay Zeka Otomasyonu Nasıl Kurulur? yazımızı inceleyebilirsiniz.
• Sınır Ötesi E-Ticaret ve Çoklu Kanal Satışlarda Gömülü Cüzdan: Antalya'dan dünyaya açılan markalar ve pazar yeri satıcıları, Antalya İşletmeleri İçin Sınır Ötesi E-Ticaret ve E-İhracat Altyapısı Nasıl Kurulur? ve E-Ticarette Çoklu Kanal (Omnichannel) Rehberi içeriklerimizde vurguladığımız üzere farklı satış kanallarından gelen tahsilatları tek bir finansal gösterge panelinde birleştirebilir. Ayrıca doğru altyapı seçimi için E-Ticaret Altyapı Modelleri: Doğru Sistem Seçimi 2026 ve ödeme adımı dönüşüm optimizasyonu için Mobil E-Ticarette UI/UX: Dikkat Edilmesi Gerekenler rehberlerimizden yararlanabilirsiniz.
• Fintech Girişimleri ve Yatırım Hazırlığı: Antalya Teknokent bünyesinde B2B finansal otomasyon, açık bankacılık veri analitiği, tarım tedarik zinciri finansmanı veya gömülü sigorta (Embedded Insurance) çözümleri geliştiren girişimler, yüksek müşteri tutundurma oranına sahip ölçeklenebilir bir iş modeli inşa edebilirler. Bu alandaki girişimcilik ve Yatırım süreçleri için Teknoloji Girişimlerinde Tohum Yatırım Hazırlığı ve Değerleme Analizi Nasıl Yapılır? makalemiz yol gösterici olacaktır.
• Yapay Zeka Destekli Nakit Akışı Tahminlemesi ve Kişiselleştirme: HBHS API'leri üzerinden çekilen geçmiş hesap hareketleri, Hiper-Kişiselleştirme: E-Ticarette Akıllı Dokunuş ve E-Ticarette Üretken Yapay Zeka Ajanları Rehberi yazılarımızda ele alınan yapay zeka modelleriyle analiz edilerek işletmelere proaktif nakit akışı ve likidite önerileri sunulabilir.

7. Açık Bankacılık ve Gömülü Finans Entegrasyon Kontrol Listesi

Platformunuza açık bankacılık veya gömülü finans yetenekleri kazandırırken doğrulamanız gereken teknik adımlar şunlardır:

• TCMB ve BKM Geçit standartlarına uyumlu lisanslı YOS iş ortağı veya doğrudan lisanslama gereksinimleri netleştirildi mi?
• mTLS bağlantı sertifikaları ve JWS mesaj imzalama anahtarları Donanım Güvenlik Modülü (HSM) veya bulut KMS üzerinde güvenli şekilde izole edildi mi?
• Access Token ve Refresh Token rotasyonu (Refresh Token Rotation) ile süresi dolmak üzere olan rızaların kullanıcıya proaktif bildirilmesi akışı kodlandı mı?
• Tüm ödeme başlatma ve transfer uç noktalarında Idempotency-Key doğrulaması, çift kayıtlı muhasebe (Double-Entry Ledger) bütünlük kontrolleri ve devre kesici (Circuit Breaker / Retry with Exponential Backoff) politikaları devreye alındı mı?
• Finansal işlem logları, bilgi güvenliği ve KVKK standartlarına uygun olarak hassas kişisel verilerden arındırılmış (maskelenmiş) şekilde değiştirilemez denetim izi (Audit Trail) veritabanına kaydediliyor mu?

8. Sıkça Sorulan Sorular (SSS)

Açık bankacılık kullanırken banka şifrem üçüncü taraf uygulamayla paylaşılır mı?

Kesinlikle hayır. Modern açık bankacılık mimarisi (OAuth 2.0, PKCE ve FAPI), geçmişte kullanılan ekran kazıma (Screen Scraping) veya kullanıcı adı/şifre paylaşımı yöntemlerini tamamen ortadan kaldırmıştır. Kimlik doğrulama işlemi her zaman doğrudan kendi bankanızın mobil uygulaması veya güvenli doğrulama ortamında biyometrik onayla gerçekleşir; üçüncü taraf uygulama yalnızca sizin izin verdiğiniz kapsamda (Scope) ve sürede geçerli olan kriptografik bir erişim belirteci (Access Token) alır.

Verdiğim açık bankacılık hesap erişim rızasını nasıl iptal edebilirim?

Kullanıcılar, verdikleri hesap bilgisi veya ödeme başlatma rızalarını hem ilgili üçüncü taraf uygulamanın rıza yönetim panelinden hem de doğrudan kendi bankalarının mobil uygulamasındaki "Açık Bankacılık / Verdiğim İzinler" menüsünden diledikleri anda tek dokunuşla iptal edebilirler. İptal işlemi anında merkezi BKM Geçit altyapısına yansır ve erişim belirteci saniyeler içinde geçersiz kılınır.

Bir e-ticaret, ERP veya SaaS şirketi finans lisansı almadan gömülü finans sunabilir mi?

Evet. Finans dışı teknoloji şirketleri, doğrudan kendi başlarına banka veya elektronik para lisansı almak zorunda değildir. TCMB lisanslı bir Elektronik Para Kuruluşu, Ödeme Kuruluşu (YOS) veya BaaS altyapısı sunan bir bankayla teknik iş ortaklığı geliştirerek, onların regüle edilmiş ve denetlenen API altyapılarını kendi yazılımlarına güvenli bir şekilde entegre edebilirler.

Hesaptan hesaba (A2A) açık bankacılık ödemelerinin geleneksel kartlı ödemelerden farkı nedir?

ÖBHS tabanlı hesaptan hesaba ödemelerde kullanıcı 16 haneli kart numarası, son kullanma tarihi veya CVV kodu girmek zorunda kalmaz; mobil bankacılık uygulamasına otomatik yönlendirilerek tek biyometrik onayla ödemeyi tamamlar. Bu durum sepet terk oranlarını düşürür, kart sahtekarlığı (Fraud / Chargeback) riskini ortadan kaldırır ve işletmeye FAST altyapısı üzerinden 7/24 anında nakit akışı ve kesin mutabakat sağlar.