İade Sürecinde Kişisel Veri: GDPR ve KVKK Rehberi

Bir iade talebi göründüğünden çok daha fazla kişisel veri toplar. Sipariş numarası ve e-posta elbette, ama çoğu zaman para iadesi için bir IBAN, yüksek tutarlı ya da şüpheli iadelerde bazen bir kimlik fotokopisi, teslimat adresi ve müşterinin ürünü neden geri gönderdiğine dair yazılı ya da seçilmiş bir neden de bu sürece dahil olur. Bunların hiçbiri sıra dışı değil — ama hepsi mevzuata tabi.

Bir iadede aslında hangi veriler dolaşır

Tipik bir iadeyi bileşenlerine ayırdığınızda beş kategori ortaya çıkar: kimlik verisi (ad, sipariş geçmişi), ödeme verisi (para iadesi için IBAN ya da kart bilgisi), bazen doğrulama verisi (yalnızca belirli bir tutarın üzerinde ya da dolandırıcılık şüphesi olan iadelerde istenen kimlik fotokopisi), lojistik verisi (teslim alma ya da gönderim adresi) ve davranışsal veri — iade nedeni, sıklığı, müşterinin sipariş geçmişindeki örüntü. AB'de GDPR kapsamında bunların tamamı kişisel veridir; Türkiye'de 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) açısından da durum farklı değildir. İki çerçeve, bir tüccarın gerçekte önemsediği sorularda — ne toplanmalı, ne kadar süre saklanmalı, kiminle paylaşılabilir — birbirinden sanıldığından çok daha az ayrışır.

Veri minimizasyonu: sadece o iade için gerekeni topla

İade araçlarının varsayılan refleksi, ileride lazım olur diye baştan her şeyi toplamaktır. Bu refleks, hem GDPR'ın veri minimizasyonu ilkesiyle hem de KVKK'nın işlenen veriyle amaç arasında bağlantılı, sınırlı ve ölçülü olma şartıyla taban tabana zıttır. Standart bir değişim işleminde kimlik fotokopisine gerek yoktur. Belirli bir eşiğin altındaki bir iadede tam banka ekstresi gerekmez — tek bir IBAN yeterlidir ve bu bilgi iade başlatılır başlatılmaz değil, para iadesinin gerçekten gerekli olduğu adımda istenmelidir. Minimizasyonun iade süreçlerindeki diğer yükümlülüklerle nasıl kesiştiğini iade süreci SLA karşılaştırmamızda daha detaylı ele aldık.

Saklama süresi: bir IBAN amacını hızla aşar

İade süreçlerindeki en yaygın uyum açığı toplama aşamasında değil, saklama aşamasında ortaya çıkar. Tüccar para iadesi için bir IBAN ister, iade tamamlanır, ama kimse silme adımını sahiplenmediği için o IBAN bir veritabanında ya da destek talebinde süresiz kalır. Ne GDPR ne de KVKK bu veri için size sihirli bir gün sayısı vermez; ikisi de veriyi yalnızca toplandığı amaç için gerekli olduğu sürece saklamanızı ister — muhasebe ya da vergi kayıtları için ayrı bir saklama yükümlülüğü olabilir, ama bu tamamen farklı bir hukuki dayanaktır ve genelde ekiplerin sandığından daha kısa sürelidir. Pratikte: IBAN, para iadesi tamamlanır tamamlanmaz silinmeli ya da tokenize edilmeli, 'bir dahaki iade için dursun' mantığıyla tutulmamalıdır.

Hukuki dayanak: her zaman rıza gerekmez

Tüccarlar iade verisini işlemek için genelde rızayı hukuki dayanak olarak seçer, ama çoğu zaman bu yanlış araçtır. Bir IBAN'ı para iadesini gerçekleştirmek için işlemek, satış sözleşmesinin ifası için gereklidir — GDPR'da Madde 6(1)(b), KVKK'da ise sözleşmenin kurulması veya ifasıyla doğrudan ilgili olma şartı buna karşılık gelir. Rıza, işlem için zorunlu olmayan veriler içindir: örneğin iade nedeni verisini pazarlama segmentasyonunda kullanmak ya da davranışsal veriyi talep planlama aracı gibi iade sürecinin dışındaki bir sistemle paylaşmak. İkisini karıştırmak — sözleşmesel zorunluluğu rıza bannerı gerektiriyormuş gibi ele almak ya da isteğe bağlı bir analitik kullanımını sözleşme zaten kapsıyormuş gibi varsaymak — iade verisi denetimlerinin çoğunun çıkış noktasıdır.

İşin içine üçüncü bir taraf girince ne değişir

İade verisini bir iade platformuna, 3PL'e ya da kargo firmasına aktardığınız an bir veri işleyen ilişkisi kurmuş olursunuz ve hem GDPR hem KVKK bunu düzenleyen yazılı bir sözleşme bekler — GDPR'da veri işleme sözleşmesi (DPA), KVKK'da ise buna karşılık gelen veri işleyen taahhüdü; amaç, saklama süresi, alt işleyen kuralları ve güvenlik yükümlülükleri bu sözleşmede tanımlanmalıdır. Bu bir formalite değildir; her iki rejimde de düzenleyiciler, yazılı sözleşmesi olmadan dış kaynak kullanan tüccarlara yaptırım uygulamıştır. Sınır ötesi aktarım ayrı bir katmandır: AB'den çıkan kişisel veri için tanınan bir aktarım mekanizması gerekir (standart sözleşme hükümleri en yaygın yoldur), Türkiye'den yurt dışına çıkan veri ise kendi KVKK aktarım şartlarına tabidir ve bu şartlar bazı yönlerden AB rejiminden daha katıdır. Operasyonunuz her iki pazarı da kapsıyorsa, çok kanallı pazaryeri iadeleri yazımız bu sınırın lojistik tarafını ele alıyor.

En güvenli kişisel veri, hiç toplanmayan veridir. İkinci en güvenlisi, zaten silinmiş olandır.

Tipik bir iadede karşınıza çıkan veri türlerini amaç, saklama süresi ve hukuki dayanak açısından karşılaştıralım:

ResReturn bunu nasıl tasarım gereği çözüyor

ResReturn'ün iade akışını, düzenleyicilerin beklediği aynı minimizasyon ilkesi üzerine kurduk: müşteri banka bilgisi alanını yalnızca sonuç gerçekten bir para iadesiyse görür — değişim ya da anında kredi durumunda görmez — iade nedenleri serbest metin yerine önceden tanımlı, yapılandırılmış kategoriler olarak toplanır ve bu da ihtiyaçtan fazla kişisel ayrıntı birikmesini önler, IBAN verisi ise para iadesi tamamlanır tamamlanmaz otomatik olarak silinir, bir destek kutusunda unutulmaz. Bu yapılandırılmış neden verisi aynı zamanda fit-graph'ı ve iade analitiği tarafını da besler; bir tüccarı uyumlu tutan disiplin, veriyi gerçekten kullanışlı kılan disiplinle aynıdır.