What GDPR and KVKK Mean for Your Returns Data

Every return triggers a small burst of personal data collection that most teams never audit. An order ID and email address, sure — but also, often, a bank account or IBAN for the refund, occasionally a copy of a government ID for a high-value or fraud-flagged return, a shipping address, and a written or selected reason for why the item is coming back. None of that is unusual. All of it is regulated.

The data a return actually touches

Strip a typical return down to its components and you get five categories: identity data (name, order history), payment data (IBAN or card details for the refund), sometimes verification data (an ID copy, requested rarely and usually only above a fraud or value threshold), logistics data (pickup or drop-off address), and behavioral data — the return reason, the frequency, the pattern across a customer's order history. Under GDPR, all five categories count as personal data. Under Türkiye's KVKK (Kişisel Verilerin Korunması Kanunu), the same is true, and the two frameworks overlap more than they diverge on the practical questions that matter to a merchant: what to collect, how long to keep it, and who else gets to see it.

Data minimization: only collect what this return needs

The default instinct in returns tooling is to collect everything up front, in case it's needed later. That instinct runs directly against both GDPR's data minimization principle and KVKK's parallel requirement that processed data be connected, limited, and proportionate to the purpose it serves. A standard exchange doesn't need an ID copy. A refund under a reasonable threshold doesn't need a full bank statement — one IBAN is enough, and it should be requested at the point where a refund is actually due, not collected speculatively the moment a return is opened. Our guide to return rights in 2026 covers how minimization interacts with the broader set of return obligations merchants are now facing.

Retention: an IBAN outlives its purpose fast

The most common compliance gap in returns isn't collection — it's retention. A merchant asks for an IBAN to issue a refund, the refund clears, and the IBAN sits in a database or a support ticket indefinitely because nobody owns the deletion step. Neither GDPR nor KVKK hands you a magic number of days to hold that data; both instead require that you keep it only as long as necessary for the purpose you collected it for, separate from whatever accounting or tax retention obligation may apply on a different legal basis entirely and is usually shorter-lived than teams assume for the payment detail itself. Practically: the IBAN should be purged or tokenized once the refund settles, not kept 'just in case' for the customer's next return.

Legal basis: consent isn't always the answer

Merchants often reach for consent as the legal basis for processing return data, but it's usually the wrong tool. Processing an IBAN to fulfill a refund is necessary for performance of the sales contract — that's your legal basis under GDPR Article 6(1)(b), and KVKK's equivalent ground for processing directly tied to establishing or performing a contract. Consent belongs to the data you don't strictly need for the transaction: using return-reason patterns for marketing segmentation, for instance, or sharing behavioral data with a demand-planning tool outside the immediate refund workflow. Mixing the two up — treating contractual necessity as if it required a consent banner, or treating optional analytics as if the contract already covered it — is where most returns-data audits go wrong.

What changes when a third party handles the return

The moment you hand return data to a returns platform, a 3PL, or a carrier, you've created a processor relationship, and both GDPR and KVKK expect a written agreement governing it — a data processing agreement (DPA) under GDPR, or the equivalent processor undertaking under KVKK — that specifies purpose, retention, sub-processor rules, and security obligations. It's not a formality; regulators in both regimes have penalized merchants for outsourcing fulfillment without one. Cross-border transfer adds another layer: EU personal data leaving the EEA needs a recognized transfer mechanism, standard contractual clauses being the common route, while Turkish data leaving Türkiye faces its own KVKK transfer conditions, distinct from — and in some respects stricter than — the EU regime. If your returns operation spans both markets, our piece on cross-border returns in the EU covers the logistics side of that same boundary.

The safest personal data is the data you never collected. The second safest is the data you already deleted.

Here is how the main data types in a typical return compare on purpose, retention, and legal basis:

How ResReturn handles this by design

We built ResReturn's return flow around the same minimization principle regulators expect: a customer only sees a bank-detail field when a refund — not an exchange or instant credit — is actually the outcome, return reasons are captured as structured, pre-defined categories rather than free text that tends to accumulate more personal detail than necessary, and IBAN data is purged automatically once a refund settles rather than lingering in a support inbox. That same structured-reason data feeds the fit-graph and the return-analytics side of the product — the discipline that keeps a merchant compliant is the same discipline that makes the data actually useful.