Fintech'te Kayıt Tutma Yükümlülükleri: BDDK, TCMB, MASAK ve KVKK Bir Arada

Regüle bir operasyonda müşteri şikayeti sadece çözülmez, kanıtlanır. Dört regülasyonun kayıt tutma beklentisini tek operasyon katmanında karşılamanın yolu.

Regüle bir kurumda müşteri operasyonunun gerçek sınavı, şikayetin çözüldüğü an değil; denetçinin "bu şikayet ne zaman geldi, kim baktı, ne zaman kapandı, neye dayanarak karar verildi" diye sorduğu andır. Bankacılık, ödeme ve elektronik para tarafında müşteriyle her temas aynı zamanda bir kayıt yükümlülüğüdür. Bu yazıda dört ana çerçevenin (BDDK, TCMB, MASAK ve KVKK) müşteri operasyonuna nasıl yansıdığını ve hepsinin tek bir noktada nasıl buluştuğunu ele alıyoruz.

Dört regülasyon, tek operasyon

Çoğu ekip bu yükümlülükleri ayrı ayrı, farklı araçlarda yönetir: şikayet bir yerde, denetim kaydı başka yerde, kişisel veri envanteri bir tabloda. Sorun şu ki denetim geldiğinde bu parçaları elle birleştirmek hem yavaş hem hataya açıktır.

Oysa dördünün ortak paydası tek bir cümlede toplanır: kim, neyi, ne zaman, neye dayanarak yaptı ve bunu sonradan değiştirilemez biçimde gösterebiliyor musun? Aşağıdaki her başlık bu sorunun farklı bir yüzünü düzenler.

BDDK: cevap süresi de bir kayıttır

Bankacılık tarafında müşteri başvurularının belirli sürelerde yanıtlanması beklenir. Genel kural başvuruya en geç bir ay içinde cevap verilmesidir; kredi kartı ve banka kartı ile ilgili başvurularda bu süre yirmi gündür.

Buradaki kritik nokta sürenin kendisi değil, sürenin takip edilebilir olmasıdır. Bir şikayetin ne zaman açıldığı, hangi aşamada beklediği ve süre ihlaline ne kadar kaldığı operasyonel olarak görünmüyorsa, uyum bir tesadüfe bağlı kalır. Bu yüzden cevap süreleri bir SLA gibi tanımlanmalı ve ihlale yaklaşıldığında sistem uyarı üretmelidir.

TCMB: şikayetin izlenebilir bir prosedürü olmalı

Ödeme ve elektronik para kuruluşları için TCMB denetimlerinde aranan şey tek tek şikayetlerin sonucu değil, bütün bir prosedürün varlığıdır. Kuruluşların müşteri şikayetlerinin izlenmesi, ele alınması ve takip edilmesine ilişkin tanımlı bir süreç kurması beklenir.

Pratikte bu şu demektir:

• Her şikayet aynı kapıdan girer ve kategorize edilir.
• Hangi ekibin, hangi adımda sorumlu olduğu bellidir.
• Sürecin her aşaması zaman damgasıyla kayıt altına alınır.
• Geçmişe dönük olarak "şu dönemde gelen şikayetler nasıl yönetildi" sorusu raporla cevaplanabilir.

Denetime hazır olmak, denetimden önce raporu üretebilmektir.

MASAK: kaydı saklamak, sonradan gösterebilmek

5549 sayılı Kanun kapsamında ödeme ve elektronik para kuruluşları MASAK yükümlüsüdür. Bu; müşterini tanı ilkeleri, şüpheli işlem bildirimi ve en önemlisi kayıtların saklanması yükümlülüğünü doğurur.

Müşteri operasyonu açısından bunun anlamı net: bir şikayet veya işlem etrafında oluşan yazışma, not ve karar zinciri silinemez, üzerine yazılamaz olmalı. Bir kaydın sonradan değiştirildiği değil, değiştirilemediği kanıtlanabilmelidir. Operasyon katmanı bu nedenle her değişikliği versiyonlayan bir denetim izi üzerine kurulmalıdır.

KVKK: aynı veriyi hem koru hem gerektiğinde göster

KVKK (6698) tarafında denge inceliklidir. Bir yandan müşteri verisi minimum düzeyde toplanmalı, amaca uygun kullanılmalı ve süresi dolduğunda imha edilmelidir. Öte yandan bankacılık sırrı ve regülasyon, aynı verinin belirli süre saklanmasını zorunlu kılar.

Bu iki beklenti çelişki gibi görünse de aslında aynı şeyi söyler: veriye kimin, hangi yetkiyle eriştiği kayıt altında olmalı. Rol bazlı yetkilendirme ve erişim loglaması, KVKK uyumunun şikayet ekranındaki karşılığıdır.

Ortak payda: kanıtlanabilirlik

Dört çerçeveyi yan yana koyduğunda tek bir operasyonel gereksinim çıkar: kanıtlanabilirlik. Bunu sağlayan dört yapı taşı vardır:

1. Denetim izi: her kaydın kim tarafından, ne zaman, nasıl değiştirildiğinin değiştirilemez geçmişi.
2. SLA: regülasyonun öngördüğü sürelerin operasyonel olarak izlenmesi ve ihlal uyarısı.
3. Eskalasyon: kritik bir şikayetin doğru seviyeye, tanımlı kurallarla yükselmesi.
4. Raporlama: geçmiş kayıtların denetçi sorduğunda dakikalar içinde çıkarılabilmesi.

Bu dördü ayrı araçlara dağıldığında uyum, ekibin disiplinine bağlı kalır. Aynı katmanda toplandığında ise uyum, operasyonun varsayılan davranışı haline gelir.

Peki bu veri nerede duruyor?

Regüle kurumlarda çoğu zaman ilk sorulan soru özellik listesi değildir; "bu veri kurum dışına çıkıyor mu?" sorusudur. Bankacılık sırrı ve KVKK bir araya geldiğinde, müşteri verisinin ve onu işleyen modellerin nerede çalıştığı başlı başına bir karar kriteridir.

Bu nedenle operasyon katmanının kurum içinde (on-premise) çalışabilmesi, gerektiğinde yapay zeka bileşenleri dahil, bir lüks değil regülasyonun doğal sonucudur. Veri kurum sınırının içinde kaldığında, uyumun yarısı en baştan çözülmüş olur.

Regüle bir operasyonda asıl soru "şikayeti çözdük mü" değil, "çözdüğümüzü kanıtlayabiliyor muyuz" sorusudur.

FlowDesk'i tam da bu nedenle bir araç olarak değil, e-posta, çağrı merkezi, WhatsApp ve operasyon ekiplerinden gelen her teması SLA, denetim izi, eskalasyon ve raporlamaya bağlayan bir müşteri operasyonları katmanı olarak tasarladık; istendiğinde verinin kurum dışına hiç çıkmadan kurum içinde çalışacak şekilde. Çünkü fintech'te müşteri operasyonu, aynı zamanda bir uyum operasyonudur.

---

Bu yazı genel bilgilendirme amaçlıdır ve hukuki danışmanlık niteliği taşımaz; süreler ve yükümlülükler mevzuat değişikliklerine göre güncellenebilir. Kurumunuza özel uyum gereksinimleri için ilgili mevzuatın güncel halini ve hukuk/uyum biriminizi esas alın.