- Konu sahibi
- #1
Bankacılıkta API, bir uygulamanın banka sistemleriyle güvenli ve kurallı biçimde veri alışverişi yapmasını sağlayan programlama arayüzüdür. Bir mobil uygulama hesap bakiyesini gösteriyor, ödeme başlatıyor veya işlem geçmişini listeliyorsa, bu işlemler çoğunlukla bankanın API uç noktaları üzerinden gerçekleştirilir. API, bankanın iç veritabanına doğrudan erişim vermez; hangi verinin, hangi kullanıcı veya kurum adına, hangi koşullarda alınabileceğini ve değiştirilebileceğini sınırlar.
Bankanın kendi mobil uygulamasının kullandığı API ile üçüncü taraflara sunulan açık bankacılık API'si aynı erişim modeli değildir. Açık bankacılıkta hesap bilgisi ve ödeme emri başlatma gibi hizmetler, ilgili katılım ve izin koşullarıyla sunulur. Müşteri onayı tek başına herhangi bir geliştiriciye banka sistemine erişim sağlamaz.
Tipik akışta mobil uygulama, web uygulaması veya fintech servisi bir API isteği gönderir. Bankanın API geçidi isteği karşılar, istemciyi ve yetkileri kontrol eder, ilgili servise yönlendirir ve sonucu standart bir veri biçiminde döndürür. İstek genellikle HTTPS üzerinden yapılır ve erişim belirteci, istemci kimliği, kapsam ve işlem bilgileriyle birlikte değerlendirilir.
Burada iki kavramı ayırmak gerekir:
Kimlik doğrulama, isteği gönderen uygulamanın veya kullanıcının gerçekten kim olduğunu kontrol eder. Yetkilendirme ise kimliği doğrulanmış tarafın hangi hesaba ve hangi işleme erişebileceğini belirler. Kullanıcının giriş yapmış olması, tüm hesaplara erişebileceği veya para transferi başlatabileceği anlamına gelmez.
Bankacılık API’lerinde OAuth 2.0 benzeri yetkilendirme akışları, erişim belirteçleri ve sınırlı izin kapsamları kullanılabilir. Örneğin bir uygulamaya yalnızca bakiye okuma izni verilebilir; para transferi başlatma yetkisi ayrıca istenebilir. Hassas işlemlerde ek kullanıcı onayı, tek kullanımlık doğrulama veya bankanın işlem politikaları devreye girebilir.
Bir finans uygulamasının kullanıcının banka bakiyesini göstermesi gerektiğini varsayalım. Uygulama aşağıdaki mantıkla çalışır:
İlk olarak API’nin yalnızca hangi iş ihtiyacını karşılayacağını belirleyin. Gereksiz hesap, müşteri veya işlem verisini döndürmeyin. Ardından her uç nokta için kimlik doğrulama, yetki kapsamı, veri alanları, hata yanıtları ve denetim kayıtlarını tanımlayın.
Aşağıdaki ayrım, API’nin görevini netleştirmeye yardımcı olur:
Para hareketi oluşturan uç noktalarda aynı isteğin ağ sorunu nedeniyle iki kez işlenmesini önlemek için belgelenmiş işlem referansı veya destekleniyorsa idempotency anahtarı gibi bir tekilleştirme mekanizması tasarlanmalıdır. Rastgele bir başlık eklemek, banka onu desteklemiyorsa çift işlemi önlemez. Ayrıca yalnızca istemcide yapılan kontrole güvenilmemeli; hesap sahipliği, işlem tutarı ve yetki kontrolleri sunucu tarafında tekrar yapılmalıdır.
API anahtarını kullanıcı parolası sanmak: API anahtarı veya erişim belirteci, kapsamı ve kullanım amacı belirlenmiş bir erişim bilgisidir. Kaynak koduna, tarayıcı çıktısına veya herkese açık depoya sabitlenmemelidir.
Kimlik doğrulamayı yetki kontrolü yerine kullanmak: Kullanıcının tanınması, istenen hesabı veya işlemi kullanmaya yetkili olduğu anlamına gelmez. Her nesne ve işlem için sunucu tarafında yetki kontrolü yapılmalıdır.
Tüm hesap verisini tek yanıtta döndürmek: Gereksiz alanlar veri sızıntısının etkisini büyütür. API yanıtlarını ihtiyaç duyulan alanlarla sınırlayın ve hassas bilgileri maskeleyin.
Uç noktaları takip etmemek: Eski sürümler, test uç noktaları ve unutulmuş servisler saldırı yüzeyi oluşturabilir. Kullanılan API envanterini, sürümleri ve erişim sahiplerini düzenli olarak gözden geçirin.
Genellikle hayır. Uygulama, bankanın desteklediği yetkilendirme akışını kullanmalı; kullanıcı parolasını kendi sunucusuna almamalıdır. Banka tarafından verilen erişim izni ve belirteçler, tanımlı kapsamla sınırlı kullanılmalıdır.
Standartlaştırılmış açık bankacılık çerçeveleri bulunabilir; ancak bütün bankacılık API'lerinin birebir aynı olduğunu varsaymayın. Desteklenen standart/sürüm, uç noktalar, veri alanları ve işlem koşulları doğrulanmalıdır. Birden fazla entegrasyonda ortak veri modeli ve gerektiğinde ayrı adaptörler kullanılabilir.
Hayır. Uygulama, iptal edilmiş veya süresi dolmuş izin ve belirteçleri kullanmaya devam etmemelidir. Yetkilendirme hatası alındığında bankanın desteklediği yeniden izin alma akışı uygulanmalı; kullanıcıya ait eski belirteci tekrar tekrar denemek çözüm sayılmamalıdır.
Bankanın kendi mobil uygulamasının kullandığı API ile üçüncü taraflara sunulan açık bankacılık API'si aynı erişim modeli değildir. Açık bankacılıkta hesap bilgisi ve ödeme emri başlatma gibi hizmetler, ilgili katılım ve izin koşullarıyla sunulur. Müşteri onayı tek başına herhangi bir geliştiriciye banka sistemine erişim sağlamaz.
Bankacılık API’si nasıl çalışır?
Tipik akışta mobil uygulama, web uygulaması veya fintech servisi bir API isteği gönderir. Bankanın API geçidi isteği karşılar, istemciyi ve yetkileri kontrol eder, ilgili servise yönlendirir ve sonucu standart bir veri biçiminde döndürür. İstek genellikle HTTPS üzerinden yapılır ve erişim belirteci, istemci kimliği, kapsam ve işlem bilgileriyle birlikte değerlendirilir.
Burada iki kavramı ayırmak gerekir:
Kimlik doğrulama, isteği gönderen uygulamanın veya kullanıcının gerçekten kim olduğunu kontrol eder. Yetkilendirme ise kimliği doğrulanmış tarafın hangi hesaba ve hangi işleme erişebileceğini belirler. Kullanıcının giriş yapmış olması, tüm hesaplara erişebileceği veya para transferi başlatabileceği anlamına gelmez.
Bankacılık API’lerinde OAuth 2.0 benzeri yetkilendirme akışları, erişim belirteçleri ve sınırlı izin kapsamları kullanılabilir. Örneğin bir uygulamaya yalnızca bakiye okuma izni verilebilir; para transferi başlatma yetkisi ayrıca istenebilir. Hassas işlemlerde ek kullanıcı onayı, tek kullanımlık doğrulama veya bankanın işlem politikaları devreye girebilir.
Somut örnek: Finans uygulamasında bakiye gösterme
Bir finans uygulamasının kullanıcının banka bakiyesini göstermesi gerektiğini varsayalım. Uygulama aşağıdaki mantıkla çalışır:
- Kullanıcı, finans uygulamasında banka hesabını bağlama seçeneğini başlatır.
- Kullanıcı banka tarafından sunulan yetkilendirme ekranında hangi izinlerin verileceğini görür ve onaylar.
- Banka, uygulamaya doğrudan kullanıcı parolasını vermek yerine sınırlı kapsamlı bir erişim belirteci sağlar.
- Uygulama bu belirteçle bakiye API’sine istek gönderir.
- Banka, belirtecin geçerliliğini, kapsamını ve kullanıcının ilgili hesaba erişim hakkını kontrol eder.
- Kontroller başarılıysa bakiye verisi uygulamaya döner; başarısızsa uygulama hatayı kullanıcıya açıklanabilir biçimde gösterir.
API tasarlarken hangi kararlar alınmalı?
İlk olarak API’nin yalnızca hangi iş ihtiyacını karşılayacağını belirleyin. Gereksiz hesap, müşteri veya işlem verisini döndürmeyin. Ardından her uç nokta için kimlik doğrulama, yetki kapsamı, veri alanları, hata yanıtları ve denetim kayıtlarını tanımlayın.
Aşağıdaki ayrım, API’nin görevini netleştirmeye yardımcı olur:
| API işlevi | Örnek işlem | Genellikle değiştirir mi? | Ek dikkat noktası |
|---|---|---|---|
| Hesap bilgisi | Bakiye veya hesap adı alma | Hayır | Veri kapsamı ve kullanıcı yetkisi |
| İşlem geçmişi | Son hareketleri listeleme | Hayır | Sayfalama ve hassas veri maskeleme |
| Ödeme başlatma | Alıcıya para gönderme | Evet | Ek onay, tekrar gönderim ve işlem limiti |
| Bildirim veya doğrulama | İşlem durumunu bildirme | Bazen | Mesajın kaynağını doğrulama |
Sık yapılan hatalar
API anahtarını kullanıcı parolası sanmak: API anahtarı veya erişim belirteci, kapsamı ve kullanım amacı belirlenmiş bir erişim bilgisidir. Kaynak koduna, tarayıcı çıktısına veya herkese açık depoya sabitlenmemelidir.
Kimlik doğrulamayı yetki kontrolü yerine kullanmak: Kullanıcının tanınması, istenen hesabı veya işlemi kullanmaya yetkili olduğu anlamına gelmez. Her nesne ve işlem için sunucu tarafında yetki kontrolü yapılmalıdır.
Tüm hesap verisini tek yanıtta döndürmek: Gereksiz alanlar veri sızıntısının etkisini büyütür. API yanıtlarını ihtiyaç duyulan alanlarla sınırlayın ve hassas bilgileri maskeleyin.
Uç noktaları takip etmemek: Eski sürümler, test uç noktaları ve unutulmuş servisler saldırı yüzeyi oluşturabilir. Kullanılan API envanterini, sürümleri ve erişim sahiplerini düzenli olarak gözden geçirin.
Sık sorulan sorular
Bankacılık API’si kullanmak için banka müşterisinin parolasını saklamak gerekir mi?
Genellikle hayır. Uygulama, bankanın desteklediği yetkilendirme akışını kullanmalı; kullanıcı parolasını kendi sunucusuna almamalıdır. Banka tarafından verilen erişim izni ve belirteçler, tanımlı kapsamla sınırlı kullanılmalıdır.
Her banka için aynı API kullanılabilir mi?
Standartlaştırılmış açık bankacılık çerçeveleri bulunabilir; ancak bütün bankacılık API'lerinin birebir aynı olduğunu varsaymayın. Desteklenen standart/sürüm, uç noktalar, veri alanları ve işlem koşulları doğrulanmalıdır. Birden fazla entegrasyonda ortak veri modeli ve gerektiğinde ayrı adaptörler kullanılabilir.
Kullanıcı hesabın bağlantısını kaldırınca erişim otomatik olarak sürer mi?
Hayır. Uygulama, iptal edilmiş veya süresi dolmuş izin ve belirteçleri kullanmaya devam etmemelidir. Yetkilendirme hatası alındığında bankanın desteklediği yeniden izin alma akışı uygulanmalı; kullanıcıya ait eski belirteci tekrar tekrar denemek çözüm sayılmamalıdır.
