Bilişim Hukuku Açısından Açık Bankacılık

Açık bankacılık ve bankacılıkta API uygulamaları çok yakında Türkiye’ye nüfuz edecek. Bugüne kadar hep idari regülasyon boyutunu blog’umuzda dile getirdik. Ama olayın bilişim hukuku boyutu çok daha önemli. 

Biliyoruz ki açık bankacılığın regülatif kökeni Avrupa Birliği’nin PSD2 düzenlemesi. Bu düzenlemenin 97. maddesi tamamen kimlik doğrulama bölümüne ayrılmış. Bu düzenlemede önemli bir kavram Güçlü Müşteri Kimlik Doğrulaması ele alınıyor. Ve diyor ki müşteri aşağıdakilerden biriyle karşılaştığında güçlü müşteri kimlik doğrulamasına maruz kalmalıdır: 

• Online ödeme hesabına eriştiğinde
• Dinamik linkle belirli bir hesaba erişip ödeme işlemini gerçekleştirdiğinde
• Fraud vb. suistimal içeren riskli işlemler gerçekleştiğinde 

Açık bankacılık için güçlü müşteri kimlik doğrulaması yöntemi ödeme aracını kullanan kimsenin kimliğinin tespit edilmesini ve doğrulanması sürecinde 3 anahtardan en az ikisinin kullanılmasını içerir. Bunlar; müşterinin bildiği (şifre gibi), sahip olduğu (cep telefonu veya app gibi) ve müşteriye ait olan (biyometrik data gibi) bilgilerdir. Bunlardan birinin dâhi uyumsuz olmaması gerekmektedir. 

Bununla birlikte PSD2’ye göre ödeme PISP (ödeme başlatıcı hizmet sağlayıcısı) tarafından yapılması halinde ödemenin doğrulaması işlemi dinamik bir linke gerçekleştirilmelidir. Bu dinamik link her ödeme işlemi için eşsiz olarak üretilen ve ödeme tutarı ve alıcı kimseye ait bilgileri içeren bir araçtır. 

Şimdi müşteri ile finansal kurum arasındaki ilişkiyi kenara bırakıp ödeme dünyasının içindeki doğrulama mekanizmalarına göz atalım. Genel olarak ödeme dünyasına göz attığımızda dört çeşit doğrulama yöntemi görmekteyiz:

1- Yeniden yönlendirme (Redirected): Üçüncü taraf servis sağlayıcısı (Third Party Provider) tarafından kullanıcının internet tarayıcısının yeniden yönlendirildiği ve kimliği bu şekilde banka tarafından doğrulandığı yöntem

2- Ayrıştırılmış (Decoupled): Kimlik bilgilerinin özel bir banka uygulaması tarafından doğrulandığı yöntem

3- Bütünleşik (Integrated): Müşterinin kimliği bankanın API’si vasıtasıyla yönetildiği ve doğrulandığı yöntem

4- oAuth2 (Açık Yetkilendirme 2.0) Web tabanlı uygulama yetkilendirme yöntemidir.Kısaca bir uygulama tarafından doğrulanmış kullanıcıların başka bir uygulama tarafından da doğrulanmış olarak kabul edilmesine dayanır.

Yeniden yönlendirme, ayrıştırma ve oAuth2 yöntemleri kimlik doğrulamasının kullanıcı ile banka arasında doğrudan bir arayüz vasıtasıyla gerçekleşmesini ve sonucun nihayete erdirilmesi için third party provider’a gönderilmesini sağlar. Bazı bankalar bu yöntemlerden birkaçının kullanılmasına imkan sağlar ve müşteriler bu yöntemlerden birini seçebilir. 

Şimdi müşterinin internetten bir alışveriş yaptığını ve burada açık bankacılığı tercih ettiğini baz alan bir senaryo oluşturacağız. Burada 4 taraf var:

1- Müşteri

2- Müşterinin bankası veya ödeme kuruluşu (ASPSP denir bir müşteri için bir ödeme hesabı sağlayan ve bunu sürdüren bir ödeme kuruluşudur-

3- Ödeme Başlatma Hizmet Sağlayıcısı-PISP

4- Üye işyerinin veya eticaret sitesinin bankası

Burada üç aşama söz konusudur:

1- Ödemenin başlaması ve rızanın alınması

2- Ödeme için kimliğin doğrulanması ve yetkilendirilmesi

3- Nihai ödemenin gerçekleşmesi

İşte tüm bu ilişki bize fintech’in büyülü dünyasına girmemizi sağlar 🙂 

Aşağıda gördüğümüz üzere müşteri alışverişi onaylamakta, ödeme bilgileri e-ticaret sitesi vasıtasıyla PISP’e gitmekte o da API vasıtasıyla bankayla iletişime geçmekte, banka olumlu cevap aldığında bu sefer onay süreci başlamakta, dinamik link oluşturulmakta ve şifreler teyit edildikten sonra hem müşterinin bankasından para PISP onayıyla e-ticaret sitesinin/üye işyerinin hesabına aktarılmaktadır. 

Yukarıda detaylarıyla açıkladığımız ödeme zincirinin doğru ve etkin çalışması pek çok tarafın uyumlu çalışmasına bağlıdır. Bunun için yalnızca teknik kuralların standartlaşması yetmez aynı zamanda PISP/AISP ile bankalar arasındaki iletişiminin yürütüldüğü arayüzle ilgili IT protokolünün de sağlanması gerekir. 

IT bakış açısından Avrupalı düzenleyici otoriteler teknolojik tarafsızlığı tercih etmiş ve seçimin riskleri dikkate alınarak en etkin olan üzerinden yapılmasını tavsiye etmiştir. Ancak bu durum ister istemez erişim protokollerinde ciddi bir ayrışmaya neden olmuştur. Bu sorun ülkemiz için de söz konusu olacaktır. Açıkçası bu bir regülasyon sorunu değil piyasa sorunudur. 

Bu bakımdan her bankanın spesifik erişim protokollerinden kaynaklanan riskleri yönetmek için Avrupa’da bazı kurumlar bir birlik oluşturmuş ve bazı kritik kararlar almıştır. Bu özel inisiyatiflere muhtelif isimler verilmiştir (Örneğin Berlin Grup, Luxhub, CBI Globe, Open Banking UK)

Ben bu inisiyatifleri kıyasladım. Teknik olarak hangisinin daha iyi olduğunu anlayabilme imkanım olmasa da Berlin Grubunun perspektifini makul buldum.

Berlin Grubu Perspektifi

AISP	Hesap Bilgisi İçin Rızası Almak Erişilebilir Hesapların Detay Bilgisini Almak Belirli bir hesabın Bakiyesini Öğrenmek Belirli bir hesabın işlem bilgisini almak Erişilebilir Hesapların Listesini Almak ve Gruplamak	Transport	HTTP 1.1.
		Protocol	TLS 1.2 veya daha günceli
		App Protocol	Rest (Hal Desteğiyle)
		Yetkili Protokol	OAuth2/redirect, decoupled, embedded
PISP	Tek Bir İşlemi Başlatmak Gelecekteki Bir Ödeme Başlatma  Toplu Ödeme Başlatmak Tekrar Eden Ödemeler Başlatmak İşlemleri Gruplaştırmak	Veri Formatı	JSON & XML
		Veri Model Orjinali	ISO 20022
		İsimler ve Kavramlar	ISO 20022 Evrakları

 

Yukarıda belirtilen standartlaştırma çabaları, hesaplara erişimin sağlanması (AISP) ve işlemlerin gerçekleştirilmesi (PISP) için önemli avantajlar sağlayacak gelişmelerdir. Ülkemiz bankacılık sektörünün standartlaştırma sorunu çok ciddi boyutta. Umarım açık bankacılık yaygınlaşmaya çalışırken bu engel oluşturmaz, aksine verimli işbirlikleri tesis edilerek kullanıcılara daha iyi hizmet sunulabilir. 

Açık bankacılıkla ilgili hukuki gelişmeler için…