Most BES operators in Turkey have quietly accepted a comfortable fiction: that KVKK portability requests are rare, narrow, and satisfiable with a PDF export of the current participant record. That fiction holds until the first participant — usually one advised by a lawyer, a competitor, or a journalist — asks for their complete personal data across the full lifecycle of their policy, in a structured, machine-readable format, as Article 11 permits.
At that moment, the request stops being a compliance ticket and becomes an architecture audit.
What Portability Actually Demands That Reporting Doesn't
BES pipelines were designed around a specific set of consumers: SPK/EGM regulatory files, tax authority reconciliations, actuarial reserves, and internal MIS dashboards. Every one of these outputs shares two properties that make life easy:
- They are point-in-time aggregates, not per-subject histories.
- They tolerate retroactive corrections silently — a fixed contribution amount from three months ago just shows up correctly in this month's file.
A KVKK portability extract inverts both properties. It is per-subject, and it must be temporally honest. The participant is entitled to know what data you held about them, when you held it, what changed, and why. "We recomputed it" is not a lawful answer when the participant is asking for the record as it existed.
Concretely, a compliant portability response for a 12-year BES policy needs to include:
- Every contribution event with its as-recorded amount, date, and source channel — not the current reconciled value.
- Every fund allocation change, including the ones the participant made through a call center agent who transcribed them into a legacy screen that no longer exists.
- Every consent artifact — KVKK aydınlatma metni versions accepted, marketing consents given and withdrawn, with timestamps.
- Every communication sent (SMS, email, mektup) with delivery status.
- Every state devlet katkısı calculation and any subsequent corrections, both values visible.
Most pipelines cannot produce this. Not because the data was deleted, but because it was overwritten, denormalized, or migrated into a schema that no longer preserves the original shape.
The Three Failure Modes
1. Schema Migration Amnesia
Every BES operator has been through at least two core system migrations in the last decade. Each migration mapped old fields to new ones, and in every mapping, something was lost or reinterpreted. The classic case: a legacy system that stored fund allocation percentages as integers (0–100) migrated into a new system expecting basis points, with a conversion that quietly rounded. The current record shows 33%. The historical truth was 33.33%. Which one do you return?
If you return the current value, you are lying about history. If you return the legacy value, you must have preserved it — and almost no one did, because ETL jobs were built to produce clean current-state tables, not audit trails.
2. Retroactive Correction Without Bitemporality
BES data corrects itself constantly. A contribution posted on the 15th gets reversed and reposted on the 18th because the employer's file had an error. Devlet katkısı is recalculated when SGK reports a status change six months later. Vergi kesintisi changes when the participant's tax residency is updated.
A reporting pipeline handles this by rewriting the past. A portability extract cannot. The participant is entitled to see both the original record and the correction, with the timestamp of when each became true in your system. This requires bitemporal storage — valid time and transaction time — which almost no BES operational system implements below the ledger layer.
3. Unversioned Reference Data
This is the quietest killer. Fund codes, kesinti oranları, mortality tables, İK segment classifications — all of it changes over time, and almost none of it is versioned in a way that lets you reconstruct what a specific value meant on a specific date.
A participant asks: "What was fund BES-042 in March 2019?" Your reference table has one row for BES-042, updated last week. The fund was renamed twice, merged once, and had its risk classification changed by SPK in 2021. Your portability extract will say the fund is what it is today. That is a factually incorrect statement about the participant's historical position.
The Strip-Safety Problem
Even if you solve the temporal problems, you have a second layer: the extract must contain the participant's personal data and only the participant's personal data. Not their spouse's TCKN that appears in the beneficiary field. Not the agent's sicil numarası that appears in the transaction log. Not the free-text note from a call center agent that mentions another participant by name.
Most operational tables are joined-wide for query performance. Stripping them safely for a single subject is not a SELECT — it is a schema-aware redaction pipeline that has to know which fields are the subject's, which are third-party PII, and which are internal identifiers that cannot be exposed under other regulatory constraints.
Building this after the request arrives is not feasible. The KVKK 30-day clock does not care about your sprint capacity.
What Actually Needs to Change
The uncomfortable answer: portability is not a reporting problem, it is a data model problem. If your BES platform does not have the following, you are one request away from a demonstrable KVKK violation:
- Bitemporal event storage at the participant level for contributions, allocations, and consent artifacts. Not just in the ledger — in every system that touches participant-facing data.
- Versioned reference data with effective-dated joins. Every fund code, rate, and classification must be resolvable as of any historical date.
- A subject-scoped extraction service that walks the participant graph, applies third-party redaction rules, and produces a structured output (JSON or XML with a documented schema) — not a PDF.
- A migration policy that requires every future schema change to preserve the pre-migration shape in an accessible archive, not a backup tape.
None of this is cheap. All of it is cheaper than the first ceza from Kişisel Verileri Koruma Kurulu that cites your inability to honor Article 11, followed by the second one when the finding becomes public and other participants file the same request.
The Timing Question
The reason this has not exploded yet is that Turkish participants have not, in aggregate, exercised portability aggressively. That will not hold. The pattern in every jurisdiction with similar rights — GDPR being the obvious reference — is that portability requests start slow, then spike when a triggering event happens: a data breach, a competitor offering easier account transfers, a consumer advocacy campaign, or a regulatory guidance document that clarifies what "structured and machine-readable" actually means.
BES operators have a narrow window to fix the pipeline before the request volume forces them to fix it under a 30-day statutory clock, with a regulator watching. The ones who treat portability as a data architecture problem now will handle the wave. The ones treating it as a compliance checklist will be explaining to the Kurul why their extracts are temporally incoherent and full of other people's data.