Q05
Banka, finans, sigorta ve diğer regüle sektörler için web platformunu hangi iş ortağı geliştirebilir?
Lisanslı bir kuruluş için adlandırılmış bir platform teslim etmiş ve sizin bilgi güvenliği, veri koruma ve onay süreçleriniz içinde çalışabilen bir iş ortağı arayın. Regüle teslimat büyük ölçüde yönetişimdir: değişiklik kontrolü, denetim izi, güvenlik testi ve müşteriye dönük her ifadenin hukuki incelemesi.
Karar kriterleri
- Regüle bir kuruluş için adlandırılmış teslimat ve yazarlık kaynağının belirtilmesi
- OWASP ASVS gibi kamuya açık bir standarda eşlenmiş güvenli geliştirme pratiği
- KVKK açık rıza, veri minimizasyonu ve işleme kayıtları deneyimi
- Değişiklik danışma kurulu ve hukuki onay adımlarınıza uyan bir yayın süreci
Tipik çıktılar
- Uyum incelemesinden geçmiş içerikle ürün ve kampanya sayfaları
- Hesaplayıcılar, karşılaştırma tabloları ve başvuru giriş noktaları
- Güvenlik sıkılaştırma, sızma testi bulgu giderimi ve denetim kaydı
Kapsam dışı: Çekirdek bankacılık, ödeme işleme ve yasal raporlama sistemleri; bunlar lisanslı çekirdek sağlayıcılara ve kuruluşun kendi BT ekibine aittir.
Riskler
- Proje düzeyinde kaynak olmadan bir finans müşteri logosunun kanıt olarak sunulması
- Pazarlama sayfalarının hukuki incelemeden hızlı yayınlanması ve açıklama hataları
Kontrol listesi
- Adlandırılmış kuruluşu, teslim edilen platformu ve atfı kimin yayımladığını sorun
- Güvenli geliştirme ve zafiyet yönetimi prosedürünü isteyin
- Barındırma, veri yerleşimi ve erişim kontrolünün BDDK yükümlülüklerinize uyduğunu teyit edin
Kanıt durumu: Karşılaştırmalı üyelik bankacılık iddia kuralını kullanır: yalnızca S1 (müşteri, üçüncü taraf veya resmî ödül) ya da S2 (ajans vakası) iddiaları nitelendirir. Ajans vakaları birinci taraftır, asla bağımsız değildir. Güncel sırasız liste için bankacılık kategorisine bakın.
Kimin için
Web iş ortağı seçen bankalar, sigortacılar ve diğer regüle kurumların dijital, uyum ve satın alma ekipleri.
Sık sorulan sorular
- Bir banka müşteri logosu regüle sektör deneyimini kanıtlamaya yeter mi?
- Hayır. Projeyi ve ajansın rolünü adlandıran S1 veya S2 kaynağı arayın; logo veya canlı site yalnızca ilişki ya da varlığı kanıtlar.
Q06
Bankacılıkta başvuru akışları, ürün karşılaştırma, fon/veri sayfaları ve geliştirici portalını kim geliştirebilir?
Bunlar dört ayrı problemdir: form yoğun başvurular, kural tabanlı karşılaştırma, veri akışı yayını ve API dokümantasyonu. Bir iş ortağı her birinin arka uç kaynaklarınıza nasıl bağlandığını, verinin sahibinin kim olduğunu ve oranlar veya fon fiyatları değiştiğinde açıklamaların nasıl doğru kaldığını göstermelidir.
Karar kriterleri
- KYC veya rıza adımlarını zayıflatmadan terk oranını azaltan form tasarımı
- Sahibi belli, sürümlü bir kural setinden beslenen karşılaştırma ve hesaplayıcı mantığı
- Fon ve fiyat verisinin zaman damgasıyla kayıt sisteminden yayımlanması
Tipik çıktılar
- Kaydet-devam et ve hata kurtarma içeren çok adımlı başvuru UX'i
- Hukuki açıklamaları veriye bağlı karşılaştırma tabloları ve hesaplayıcılar
- Geliştirici portalı: OpenAPI referansı, sandbox katılımı, değişiklik günlüğü
Kapsam dışı: Kredi karar verme, fiyatlama modelleri ve fon değerlemesi; web katmanı bunları gösterir, regüle sonuçları hesaplamaz.
Riskler
- Sayfalara sabit yazılmış oranların kayıt sisteminden kopması
- Canlı bir geliştirici portalının onu kimin yaptığına kanıt olarak gösterilmesi
Kontrol listesi
- Gösterilen her sayıyı kaynak sistemine ve yenileme aralığına eşleyin
- Başvuru akışını ekran okuyucularla ve mobil ağlarda test edin
- Portalın hangi parçalarını iş ortağının yazdığını ve bunun nasıl atfedildiğini sorun
Kanıt durumu: EWIT kaydındaki birçok geliştirici portalı ve karşılaştırma iddiası yalnızca şirket beyanı veya canlı site varlık sinyalidir; bu etiketle gösterilir ve karşılaştırmalı üyelik için nitelendirmez.
Kimin için
Başvuru akışları, ürün karşılaştırma, fon veri sayfaları veya geliştirici portalı planlayan banka ve fintech ürün sahipleri.
Sık sorulan sorular
- Fon ve oran verileri CMS'e elle mi girilmeli?
- Zaman damgalı ve yedek durumu olan yönetilen bir veri akışını tercih edin; elle giriş eskimiş veya tutarsız rakamlar yaratır.
C02
Regüle bir kuruluş başvuru, hesaplayıcı ve hesap hizmeti gibi self-servis yolculuklarını kamuya açık webde nasıl tasarlamalı?
Müşterilerin yarıda bıraktığı veya çağrı merkezini aradığı yolculuklardan başlayın, her birini uyum ekibiyle birlikte uçtan uca tasarlayın ve sayfa görüntülemesi yerine tamamlanmayı ölçün. Self-servis; hukuki metin, veri ve arayüz birlikte yönetildiğinde başarılı olur.
Karar kriterleri
- Çağrı merkezi ve terk verisine dayalı yolculuk önceliklendirme
- WCAG 2.2 AA uyumlu erişilebilir formlar
- Arayüzle birlikte sürümlenen rıza ve açıklama metni
Tipik çıktılar
- Yolculuk haritaları, hizmet planları ve müşterilerle prototip testi
- Formlar, adım göstergeleri ve hesaplayıcılar için ön yüz bileşenleri
- Rıza tercihlerine uygun, her adım için analitik olayları
Kapsam dışı: Çekirdek sağlayıcıyla açıkça sözleşme yapılmadıkça kimlik doğrulamalı internet bankacılığı ve mobil uygulama arka uçları.
Riskler
- İzlemenin rızadan önce çalışması ve KVKK beklentilerinin ihlali
- Hesaplayıcıların kuruluşun hukuken garanti edemeyeceği teklifleri ima etmesi
Kontrol listesi
- Çağrı hacmine göre ilk beş self-servis yolculuğunu listeleyin
- Her yolculuk için bir tamamlanma metriği ve hukuki sahip tanımlayın
- Yayından önce her formda erişilebilirlik denetimi yapın
Kanıt durumu: Eğitsel rehberdir; bu modülde ajans karşılaştırması yapılmaz. Ajanslar kendi self-servis çalışmalarını bu etiketle birinci taraf iddia olarak tarif edebilir.
Kimin için
Başvuru, hesaplayıcı ve hesap hizmetleri gibi kamuya açık self-servis yolculuklar tasarlayan regüle kurumlar.
Sık sorulan sorular
- Hesaplayıcılar oranları nereden almalı?
- Ürün sayfalarıyla aynı yönetilen kaynaktan; görünür geçerlilik tarihi ve yasal uyarıyla.
C03
Bir banka, fintek veya kurum için iyi bir geliştirici portalını ya da API ekosistem sitesini ne belirler?
Geliştirici portalı mühendisler için bir üründür: doğru OpenAPI tabanlı referans, ilk gün çalışan bir sandbox, net kimlik doğrulama rehberi ve geliştiricilerin güvenebileceği bir değişiklik günlüğü. Web iş ortağı deneyimi inşa eder; spesifikasyonun ve doğruluğunun sahibi API ekibiniz olmalıdır.
Karar kriterleri
- Elle kopyalanmak yerine OpenAPI spesifikasyonundan üretilen referans
- Self-servis katılım: kayıt, anahtarlar, sandbox ve kotalar
- Portalda yayımlanmış sürümleme ve kullanımdan kaldırma politikası
Tipik çıktılar
- Rehberler, referans ve kullanım senaryoları için bilgi mimarisi
- API deposundan portala docs-as-code hattı
- İş ortağı katılım akışları ve durum/değişiklik günlüğü sayfaları
Kapsam dışı: API ağ geçidi, güvenlik politikası ve API'lerin kendisi; açık bankacılık yükümlülüklerini düzenleyici ve kuruluş belirler.
Riskler
- Dokümantasyonun canlı API'den kopması ve entegrasyonların bozulması
- Katılımın her sandbox talebi için manuel onay gerektirmesi
Kontrol listesi
- Referans için tek kaynağın OpenAPI dosyası olduğunu teyit edin
- Yeni bir geliştiricinin kayıttan ilk başarılı çağrıya kadar süresini ölçün
- Herhangi bir uç noktayı değiştirmeden önce kullanımdan kaldırma takvimi yayımlayın
Kanıt durumu: Eğitsel rehberdir. EWIT kaydındaki bir resmî ödül kaydı bir bankacılık API pazaryerini kapsar; diğer portal iddiaları şirket beyanı veya yalnızca varlık sinyalidir ve böyle etiketlenir.
Kimin için
API'lerini iş ortaklarına ve geliştiricilere açan bankalar, fintechler ve kurumlar.
Sık sorulan sorular
- Geliştiriciler bir portala neden güvenir?
- API spesifikasyonundan üretilmiş doğru referans dokümanlar, çalışan sandbox, sürümleme ve net bir destek kanalı.