A participant walks into a BES call center, or more commonly submits a KVKK başvuru form through the website, and asks that their personal data be deleted. The operator logs the request. Somewhere in the compliance function, a ticket gets created. And then the actual problem begins, because the pipeline that ingests, enriches, and archives BES contribution data was designed under SPK and EGM assumptions that predate any serious thought about erasure as a runtime operation.
The contradiction is not subtle. SPK requires that pension records be retained for at least 10 years after the contractual relationship ends. AML obligations under MASAK extend to identifiers, transaction history, and beneficial ownership documentation. Meanwhile, KVKK Article 7 grants the data subject the right to demand deletion when the legal basis for processing no longer applies. Firms resolve this by invoking the retention exemption and refusing deletion outright. That is not compliance. That is avoidance dressed up as legal opinion.
What Actually Breaks
A BES pipeline in a mid-sized Turkish insurer typically looks like this:
- Source systems: policy admin (BES sözleşme), contribution ledger, government matching (devlet katkısı) reconciliation
- Integration layer: usually a mix of stored procedures, SSIS or Informatica jobs, and increasingly Kafka topics feeding a Snowflake or Exadata warehouse
- Downstream: actuarial models, MIS reporting, marketing segmentation, EGM regulatory reports, fraud detection
When a deletion request lands, the operational team asks a question nobody prepared for: which of these downstream systems still contain a reconstructible copy of the participant's PII, and which of them are legally obligated to keep it?
The honest answer, in most institutions I have worked with, is that nobody knows. The lineage was never mapped at that granularity. The retention policy was written at the table level, not the participant level. Marketing has a five-year-old CSV export sitting on a shared drive. The fraud team built a graph database that ingested customer records in 2021 and has no delete API. The data lake has parquet files partitioned by ingestion date, immutable by design.
The Half-Measures Firms Actually Deploy
What I see in production:
- Soft delete with a flag: an is_deleted column is flipped to 1. The row remains fully readable to anyone with SELECT access. This satisfies nobody and creates the illusion of compliance.
- Anonymization by hashing the TCKN: except the name, address, birth date, and IBAN are still there. Re-identification takes about thirty seconds.
- Deletion from the OLTP only: the warehouse, the backups, the CDC streams, and the archive tapes retain everything. The participant's request is technically honored in the system they can see, and ignored everywhere else.
- Ticket to legal, no action: the request is logged, a template response citing SPK retention is sent, and the participant is told erasure is not possible. Sometimes this is defensible. Usually it is not, because the request could have been partially honored for marketing data, behavioral profiles, and non-regulated derivatives.
What a Correct Architecture Looks Like
Erasure has to be a first-class pipeline operation, not a legal escalation. Concretely:
- Classify every column by legal basis at ingestion. A TCKN stored for MASAK purposes has a different retention clock than the same TCKN stored for a marketing segment. If your schema treats them as one field in one table, you have already lost.
- Segregate regulatory-mandated storage from analytical storage. The 10-year SPK archive should be a locked, minimal, append-only store. It should not be the same warehouse that feeds churn models.
- Build a subject rights service. A single API that, given a TCKN, can enumerate every system holding that participant's data, classify each holding by legal basis, and execute deletion or pseudonymization where erasure is permissible.
- Treat backups as in-scope. Encrypted backups with per-subject key destruction (crypto-shredding) is the only workable pattern for immutable archives. Deleting a row from a Veeam snapshot is not a thing.
- Log the decision, not just the action. For each field not deleted, record the specific regulatory citation that overrides KVKK. When the KVK Kurulu audits, and they have started to, you need to show reasoning per field, per subject.
The Uncomfortable Part
Most of the BES pipelines running in Türkiye today cannot do any of this without a rebuild. The stored procedure that computes devlet katkısı eligibility joins six tables and assumes the participant record is present and complete. Delete the address, and the residency check fails. Delete the birth date, and the vesting calculation returns null. The pipeline was written assuming forever.
The firms that will handle this well over the next three years are the ones treating KVKK erasure not as a legal problem to be deflected but as a data architecture requirement to be engineered. That means budget, that means schema changes, and that means telling the actuarial team that some of their historical joins will need to run against pseudonymized keys.
The firms that will handle this badly will continue flipping is_deleted flags and hoping the regulator does not look closely. Some of them will find out the hard way that KVK Kurulu has, in fact, started looking closely, and the fines are no longer symbolic.
The choice is architectural. The deadline was yesterday.