Ödeme Kuruluşları İçin Müşteri Şikayet Operasyonu: TCMB Denetimine Hazır Olmak

Ödeme ve elektronik para kuruluşlarında müşteri şikayeti, aynı zamanda bir denetim kaydıdır. TCMB denetimine sürekli hazır bir şikayet operasyonu nasıl kurulur?

Bir ödeme kuruluşu için müşteri şikayeti yalnızca bir memnuniyet meselesi değildir; TCMB denetiminde "bu süreci nasıl yönetiyorsunuz, kanıtı nerede" sorusunun da cevabıdır. Ödeme ve elektronik para kuruluşları, hızla büyüyen işlem hacimleri ile sıkı regülasyon arasında, şikayet operasyonunu hem ölçeklenebilir hem denetlenebilir biçimde kurmak zorundadır. Bu yazıda, TCMB denetimine sürekli hazır bir müşteri şikayet operasyonunun nasıl tasarlanacağını ele alıyoruz.

TCMB denetimde tam olarak neye bakar

TCMB, ödeme ve elektronik para kuruluşlarını izlerken tek tek şikayetlerin sonucundan çok, tanımlı ve işleyen bir sürecin varlığına bakar. Beklenen; kuruluşun müşteri şikayetlerini izleyen, ele alan ve takip eden yazılı bir prosedüre sahip olması ve bu prosedürün gerçekten uygulandığını gösterebilmesidir.

Pratikte denetçinin görmek istedikleri şunlardır:

• Şikayetin hangi kanaldan ve ne zaman geldiği
• Hangi kategoriye atandığı ve kimin sorumlu olduğu
• Hangi sürede, hangi adımlarla ve nasıl sonuçlandığı
• Sürecin her aşamasının kaydı

Bu bilgiler, denetim öncesinde elle toplanması gereken bir veri yığını değil, sistemin doğal bir çıktısı olmalıdır.

Şikayet operasyonunun beş yapı taşı

Regülasyona uyumlu bir şikayet operasyonu, kanaldan bağımsız olarak aynı çatı altında kurulur. Beş temel yapı taşı vardır:

1. Tek kapıdan giriş. E-posta, WhatsApp, IVR, webhook ve API üzerinden gelen her temas, aynı müşteri kaydına bağlı tek bir şikayet haline gelir.
2. Kategori ve risk. Cihaz arızası, ödeme itirazı ve yetkisiz işlem gibi sınıflar ayrılır; tutar ve dolandırıcılık şüphesine göre risk seviyesi belirlenir.
3. SLA. Her şikayete yasal ve içsel yanıt süresi atanır; ihlale yaklaşıldığında sistem uyarı üretir.
4. Eskalasyon. Kritik vakalar, önceden tanımlı kurallarla doğru seviyeye otomatik taşınır.
5. Denetim izi ve raporlama. Her adım değiştirilemez biçimde kaydedilir; dönemsel raporlar talep edildiğinde anında üretilebilir.

Bu beş taşın değeri, hiçbirinin temsilcinin kişisel disiplinine bırakılmamasındadır. Süreç, operasyonun varsayılan davranışı haline gelir.

Bir şikayetin uçtan uca yolculuğu

Somutlaştıralım. Bir üye iş yeri WhatsApp'tan yazıyor: "Dünkü tahsilatım hesabıma geçmedi." Regülasyona uyumlu bir operasyonda bu temas şu yolu izler:

1. Mesaj, mevcut müşteri kaydına bağlanır ve tek bir şikayet kaydı açılır.
2. Sistem talebi "mutabakat / ödeme akışı" kategorisine atar ve tutara göre risk seviyesini belirler.
3. Kategoriye uygun bir SLA başlar; ilgili operasyon ekibinin ekranına düşer.
4. İnceleme sırasında konunun bir başka müşteride de tekrarladığı görülürse, vaka otomatik olarak eskale edilir.
5. Çözüm uygulanır, müşteriye dönülür ve kayıt kapatılır.
6. Tüm bu adımlar, zaman damgalarıyla ve değiştirilemez biçimde denetim izine yazılır.

Denetçi aylar sonra "bu tür şikayetler nasıl yönetiliyor" diye sorduğunda, cevap tek bir kaydın geçmişinde hazırdır. Önemli olan, bu yolculuğun her seferinde aynı biçimde işlemesidir.

MASAK ile kesişim

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

Şikayet operasyonu bu yükümlülükle sık sık kesişir. Bir "yetkisiz işlem" şikayeti, aynı zamanda bir şüpheli işlem sinyali taşıyabilir. Bu nedenle şikayet operasyonu, ilgili uyum akışlarıyla konuşabilmeli ve etrafında oluşan tüm kayıtlar silinemez, üzerine yazılamaz biçimde tutulmalıdır. Bir kaydın sonradan değiştirilmediğini kanıtlayabilmek, MASAK saklama yükümlülüğünün operasyonel karşılığıdır.

Denetime "sürekli" hazır olmak

Çoğu kuruluşta denetim, haftalar süren bir veri derleme telaşına dönüşür. Oysa hedef, raporun her an üretilebilmesidir.

"Geçen çeyrekte gelen şikayetlerin yüzde kaçı süresinde kapandı, kritik olanlar nasıl eskale edildi, hangileri hala açık" sorusu, günler süren bir çalışma değil, birkaç dakikalık bir raporlama olmalıdır. Denetime hazır olmak, denetimden önce raporu üretebilmektir; bu da ancak verinin baştan yapılandırılmış biçimde biriktiği bir operasyonla mümkündür.

Excel ve gelen kutusu neden ölçeklenmez

Düşük hacimde işe yarar görünen tablolar ve paylaşılan gelen kutuları, işlem hacmi büyüdükçe sessizce çöker:

• Süre takibi kopar; ihlaller ancak müşteri tekrar yazınca fark edilir.
• Denetim izi parçalanır; "kim, ne zaman, neye dayanarak" sorusu cevapsız kalır.
• Kategori ve raporlama tutarsızlaşır; aynı konu farklı isimlerle kaydedilir.
• Veriye kimin eriştiği loglanamaz; bu da KVKK açısından ayrı bir risktir.

Regülasyonun beklediği tutarlılık, manuel araçların yapısal olarak sağlayamayacağı bir şeydir.

Kategori ve raporlama: denetimin ortak dili

Denetime hazırlığın çoğu, daha şikayet kaydedilirken, doğru kategoriyle başlar. Tutarlı bir kategori yapısı olmadan üretilen rapor, regülatöre anlamlı bir resim sunmaz.

İyi bir kategori tasarımı; ödeme itirazı, yetkisiz işlem, mutabakat farkı, cihaz veya kurulum, ücret ve komisyon gibi sınıfları net biçimde ayırır. Bu ayrım üç işe yarar: doğru ekibe yönlendirme, doğru SLA ataması ve denetimde anlamlı raporlama. "Geçen çeyrekte ödeme itirazlarının ortalama çözüm süresi neydi" gibi bir soruya ancak böyle bir yapı net cevap verir.

Aynı kategori disiplini, kuruluşun kendi içinde de tekrar eden sorunları görünür kılar; tek tek çözülen şikayetler, kök neden analizine dönüşebilir.

Bu veri nerede işleniyor

Ödeme ve müşteri verisi, sektörün en hassas veri sınıflarından biridir. Bankacılık sırrı, KVKK ve ödeme regülasyonları bir araya geldiğinde, verinin ve onu işleyen bileşenlerin nerede çalıştığı başlı başına bir karar kriterine dönüşür.

Bu nedenle şikayet operasyonunu yöneten katmanın kurum içinde (on-premise), verinin sınır dışına hiç çıkmadan çalışabilmesi, ödeme kuruluşları için bir tercih değil çoğu zaman bir önkoşuldur.

TCMB denetimine hazır olmak, denetim geldiğinde değil, daha şikayet açıldığı an başlar.

FlowDesk'i tam da bu nedenle bir araç olarak değil; e-posta, WhatsApp, IVR ve webhook'tan gelen her şikayeti kategori, risk, SLA, eskalasyon ve değiştirilemez denetim izine bağlayan bir müşteri operasyonları katmanı olarak tasarladık. Ve yalnızca on-premise çalışacak şekilde. Çünkü ödeme tarafında 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.