BDDK uyum yazılımı seçim kriterleri: satın alma kontrol listesi

BDDK denetimine tabi bir kurumda uyum yazılımı seçimini belirleyen şey, özellik listesinin uzunluğu değil; aracın bir düzenleme değişikliğini uçtan uca taşıyabilmesidir. Yani: değişikliği kendi kendine tespit edecek, neyin değiştiğini ayırt edecek, hangi departmanı etkilediğini çıkaracak, sorumlusu ve son tarihi olan bir göreve çevirecek ve denetim geldiğinde “kim, ne zaman, ne yaptı” sorusuna dışa aktarılabilir bir kayıtla cevap verecek. Bu zincirin kopan her halkası, ekibinizin elle kapatacağı bir açık demektir. Aşağıdaki liste, o zinciri demo sırasında test etmeniz için hazırlandı.

Kısa cevap: bakılacak 5 ana başlık

• Kaynak kapsamı ve genişletilebilirlik — BDDK'nın yanında TCMB, SPK, MASAK, KVKK ve Resmî Gazete aynı panelde mi; listede olmayan bir kurum eklenebiliyor mu?
• Analizin derinliği — “yeni bir şey yayımlandı” bildiriminin ötesine geçip neyin değiştiğini ve kimi etkilediğini söyleyebiliyor mu?
• Sahiplik ve son tarih — her yükümlülüğün adı geçen bir sorumlusu, onaylayanı ve takvimi var mı?
• Denetim izi ve kanıt — aksiyon geçmişi dışa aktarılabiliyor mu, yoksa sadece ekranda mı duruyor?
• Veri yerleşimi, güvenlik ve entegrasyon — veri nerede duruyor, kurum içi kurulum mümkün mü, görevler mevcut araçlarınıza akıyor mu?

Neden genel amaçlı bir mevzuat takip aracı BDDK için yetmiyor

Genel amaçlı takip araçlarının çoğu bildirim katmanında durur: bir şey yayımlandığında haber verir, gerisini kullanıcıya bırakır. BDDK denetimine tabi bir kurumda ise sorulan soru haberdar olup olmadığınız değil, o bilgiyle ne yaptığınızdır.

Bunun somut bir sebebi var. BDDK'nın bankalar için getirdiği yükümlülüklerin bir kısmı tek seferlik bir kurulum değil, güncel tutulması gereken bir kayıt ya da yapı yükümlülüğüdür. Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik, örneğin veri yedekleme tarafında hangi sistem ve verilerin, hangi sıklık ve yöntemle yedeklendiğinin, nerede ve ne tür ortamda tutulduğunun güncel kayıt altına alınmasını istiyor; bilgi sistemleri yönetişimi tarafında görev ve sorumlulukları tanımlı, yönetim kuruluna raporlayan komiteler bekliyor. Bunlar “bir kez dosyalanıp geçilecek” maddeler değil; sistem değiştikçe kaydın da değişmesi gerekiyor.

İkinci sebep, BDDK'nın tek başına gelmemesi. Tek bir ürün ya da süreç değişikliği aynı anda TCMB tarafını, MASAK'ın müşteri tanıma yükümlülüklerini, KVKK boyutunu ve nihayetinde metnin yayımlandığı Resmî Gazete'yi ilgilendirebilir. Sadece BDDK'yı izleyen ya da kurum listesi sabit olan bir araç, bu resmin yarısını gösterir.

Bu sayfa alıcı tarafında hazırlanmış bir değerlendirme rehberidir; hukuki görüş değildir. Yönetmeliğe dair ifadeler yukarıda linklenen rehber sayfasındaki doğrulanmış kısımlarla sınırlıdır — kurumunuza özel her konu için uyum ekibinizin tam metni incelemesi gerekir.

10 satın alma kriteri

1. Kaynak kapsamı: BDDK ve ilişkili kurumlar

Aracın BDDK'yı izlemesi başlangıç noktasıdır, bitiş noktası değil. TCMB, SPK, MASAK, KVKK ve Resmî Gazete aynı akışta mı geliyor, yoksa her biri için ayrı bir e-posta aboneliğine mi dönüyorsunuz? En az bunun kadar önemlisi genişletilebilirlik: listede olmayan bir kurumu eklemek satıcı tarafında bir geliştirme kuyruğuna mı giriyor, yoksa konfigürasyonla mı çözülüyor?

Demoda şunu sorun: “Listenizde olmayan bir kurumu eklememiz gerekirse bu ne kadar sürer, geliştirme gerektirir mi ve ek ücreti var mı?”

2. Değişiklik mi, yeni düzenleme mi

Uyum ekibinin gündemine düşen şey çoğu zaman sıfırdan bir yükümlülük değil, hâlihazırda bildiğiniz bir metnin değişen fıkrasıdır. “Bu mevzuatta bir güncelleme var” bildirimi ile “şu maddedeki şu ifade şöyle oldu” bildirimi arasındaki fark, ekibin metni baştan okuyup okumamasıdır; büyüklüğünü kendi hacminizle görmek için ROI hesaplayıcıya kendi rakamlarınızı girin.

Demoda şunu sorun: “Takip ettiğimiz bir düzenleme değiştiğinde bana önceki metinle farkını gösterebiliyor musunuz?”

3. Etki analizi ve departman eşleştirme

Bir düzenleme hukuku, uyumu, BT'yi, operasyonu ve çağrı merkezini aynı anda ilgilendirebilir. Aracın bunu sizin yerinize çıkarması ile sizin her seferinde elle etiketlemeniz arasında büyük fark var. Ayrıca eşleştirmenin kurumunuza uyarlanabilir olması gerekir: sizdeki departman adları ve sorumluluk dağılımı, satıcının varsayılan şablonuyla birebir aynı olmayacaktır.

Demoda şunu sorun: “Şu düzenlemeyi sisteme verdiğimde etkilenen departmanları otomatik çıkarıyor musunuz, yoksa bu eşleştirmeyi baştan biz mi tanımlıyoruz?”

4. Görev atama ve sorumluluk (RACI)

“Herkesin gördüğü liste” kimsenin sahiplenmediği listedir. Değerlendirdiğiniz araçta bir yükümlülüğün sorumlusu, onaylayanı, danışılanı ve bilgilendirilecek kişileri ayrı ayrı tanımlanabiliyor olmalı; kişi ayrıldığında ya da rol değiştiğinde devir kaydı da izlenebilmeli.

Demoda şunu sorun: “Bir yükümlülük için sorumlu, onaylayan ve bilgilendirilecek kişileri ayrı ayrı tanımlayabiliyor muyum ve rol değiştiğinde bu geçmişte görünüyor mu?”

5. Son tarih ve hatırlatma

Yürürlük tarihi olan bir yükümlülük, takvime bağlanmadığı sürece sadece bir not. Hatırlatmanın hangi kanaldan gittiği (e-posta, mobil bildirim, kurum içi mesajlaşma), yaklaşan ve geçmiş görevlerin ayrı ayrı görünüp görünmediği ve yöneticinin gecikmeleri tek ekranda görüp göremediği sorulmalı.

Demoda şunu sorun: “Son tarihe yaklaşan ve son tarihi geçmiş görevler kime, hangi kanaldan ve hangi sıklıkta hatırlatılıyor?”

6. Denetim izi ve kanıt üretimi

Denetimde sorulan soru “bu düzenlemeden haberiniz var mıydı” değil, “ne yaptınız, kim karar verdi, ne zaman kapattınız”dır. Aracın her aksiyonu, onayı ve eklenen dokümanı zaman damgasıyla tutması yetmez — bunu denetçiye verilebilir bir çıktı hâline getirebilmesi gerekir. Ekranda görünen ama dışa aktarılamayan bir geçmiş, denetim gününde işinize yaramaz.

Demoda şunu sorun: “Bir denetçi geldiğinde şu mevzuata dair tüm aksiyon geçmişini, kim ne zaman ne yaptı bilgisiyle birlikte dışa aktarabiliyor muyum?”

7. Veri yerleşimi, güvenlik ve kurum içi (on-prem) senaryosu

Verinin fiziksel olarak nerede durduğu, aktarımda ve beklemede nasıl şifrelendiği, erişim kayıtlarının tutulup tutulmadığı ve kurum içi ya da özel bulut kurulumun mümkün olup olmadığı — bunlar satın alma sürecinin en geç değil, en erken sorulacak soruları. Hangi seçeneğin sizin için zorunlu olduğu kurumunuzun tabi olduğu düzenlemeye ve iç politikanıza göre değişir; ama satıcının bu sorulara net ve yazılı yanıt verebilmesi her hâlükârda zorunludur.

Demoda şunu sorun: “Verimiz fiziksel olarak hangi ülkede duruyor, kurum içi kurulum mümkün mü ve mümkünse hangi pakette sunuluyor?”

8. Entegrasyon: API ve mevcut görev araçları

Uyum ekibi zaten bir görev aracı kullanıyor. Yeni yazılım bunun yerine geçmeyecekse, en azından ona yazabilmeli — aksi hâlde ekip iki ayrı yerde görev takip etmeye başlar ve ikisi de eksik kalır. API'nin varlığı kadar hangi pakette geldiği ve dokümantasyonunun açık olup olmadığı da sorulmalı.

Demoda şunu sorun: “Oluşan görevleri hâlihazırda kullandığımız araca yazabiliyor musunuz, bu hangi pakette ve API dokümantasyonunuzu görebilir miyiz?”

9. Türkçe mevzuat metnini işleyebilme

Türkçe düzenleme metni, uzun cümle yapısı, kurum kısaltmaları ve atıf zincirleriyle kendine özgü bir alan. Bir aracın “yapay zekâ ile özetliyoruz” demesi yetmez; özetin kaynak metne bağlı olması, atıfların korunması ve çıkarılan yükümlülüklerin uzmanınız tarafından doğrulanabilmesi gerekir. Çok uluslu bir grup yapısındaysanız tersi de geçerli: yabancı regülatörün İngilizce metninin ekibin çalıştığı dilde okunabilir hâle gelmesi.

Demoda şunu sorun: “Kendi seçtiğimiz Türkçe bir yönetmelik metnini canlı verip, üretilen özeti ve çıkarılan yükümlülükleri kaynak metinle karşılaştırabilir miyiz?”

10. Devreye alma süresi

Sözleşme tarihi ile ilk gerçek faydanın alındığı tarih arasındaki fark, bütçe onayında en çok hafife alınan kalemdir. Kurulumun ne kadar sürdüğü kadar, bu sürede sizden ne isteneceği de sorulmalı: departman listesi, kullanıcı tanımları, mevcut yükümlülük envanteri, entegrasyon erişimleri. Bunları kimin çıkaracağı baştan netleşmezse takvim kendiliğinden uzar.

Demoda şunu sorun: “İmzadan sonra ilk gerçek bildirimimizi hangi tarihte alırız ve bu süre içinde bizden tam olarak ne isteniyor?”

Kriter tablosu

Kırmızı bayraklar

Aşağıdakilerden biri çıkıyorsa, değerlendirmeyi uzatmadan sorunun üstüne gidin.

• Kaynak listesi statik. Yeni bir kurum eklemek satıcının geliştirme kuyruğuna giriyor ve tarih verilemiyorsa, kapsam bugünkü listeyle sınırlı demektir.
• Denetim izi dışa aktarılamıyor. Geçmiş sadece ekranda görünüyorsa, denetim gününde ekran görüntüsü toplamakla uğraşırsınız.
• Görev sahipliği tanımlanamıyor. Herkesin aynı listeyi gördüğü, kişiye ve role bağlanmamış bir yapı, sorumluluğu dağıtır.
• Özet var, kaynak yok. Yapay zekânın ürettiği özetten tek tıkla asıl metne gidilemiyorsa, doğrulama imkânınız yok demektir.
• Veri yerleşimine net yanıt gelmiyor. “Bulutta” cevabı yeterli değil; ülke, veri merkezi ve şifreleme yaklaşımı yazılı olarak verilebilmeli.
• Demo hep aynı hazır örnek. Kendi düzenlemenizi canlı olarak sisteme vermenize izin verilmiyorsa, gördüğünüz şey ürün değil sunumdur.

QRegu bu kriterlerde nerede duruyor

Şeffaf olmak adına: bu rehber QRegu tarafından yayımlanıyor, dolayısıyla kendi konumumuzu da açıkça yazalım. QRegu, BDDK'yı TCMB, SPK, MASAK, KVKK ve Resmî Gazete dahil 26+ regülatör ve resmî kaynakla birlikte izler; Keşif Ajanı listede olmayan bir regülatörü 2 dakikadan kısa sürede ekler. Her yeni madde otomatik etki analizinden geçer — önem skorlaması, etkilenen departman eşleştirmesi ve aksiyon önerisi. İş akışı otomasyonu bunu RACI rolleri, son tarihler ve tam denetim iziyle atanmış görevlere çevirir; ekipler iOS ve Android uygulamasından anlık bildirim alır. Türkçe BDDK, SPK, TCMB ve MASAK metinleri özetlenip tercih ettiğiniz dilde sunulur ve metin üzerinde soru-cevap yapılabilir. Entegrasyon tarafında Slack, Microsoft Teams, Jira, ServiceNow ve Salesforce bağlantıları ile Kurumsal pakette RESTful API bulunur. Güvenlik tarafında AES-256 şifreleme, TLS 1.3, AB veri merkezleri, GDPR ve KVKK uyumu ile %99,9 çalışma süresi SLA'sı beyan ediyoruz; SSO/SAML ve kurum içi (on-prem) ya da özel bulut kurulumu Kurumsal pakette sunuluyor.

Kaynaklar

• QRegu — BDDK Bilgi Sistemleri Yönetmeliği: Bankalar için uyum rehberi
• BDDK — Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik (resmî metin)