KVKK (Türkiye)

Under Türkiye's Personal Data Protection Law no. 6698 (KVKK), Lunixi normally acts as a data processor; your organisation is the data controller. The privacy notice, explicit-consent management, VERBİS registration and the final answer to a data-subject request remain your responsibility.

This page offers no legal interpretation. It describes what the platform actually does today: which fields are encrypted, which are not, how long data is retained, and how an erasure request is executed technically.

Who does what

Encryption

Field-level encryption

Identity verification data is encrypted per field with AES-256-GCM. Encryption uses authenticated additional data (AAD) in the form tenantId:columnName, so a ciphertext from one tenant cannot be transplanted into another tenant or another column — decryption fails authentication if it is.

Each tenant has its own data encryption key (DEK). DEKs are never stored in the clear: they are wrapped with a key encryption key (KEK) and only the wrapped form is persisted. DEK rotation defaults to 90 days.

Which fields are encrypted — and which are not

To be straightforward: we do not claim "all personal data is encrypted", because it would not be true. The current position:

Encrypted (identity verification customer record):

For search and de-duplication we additionally keep blind indexes (peppered hashes) for email, phone, TCKN and registry number. A blind index is not plaintext — the original value cannot be recovered from it; only equality comparison is possible.

Stored in plaintext:

Document images and object storage

Identity documents and selfie images are encrypted at the application layer — a per-tenant AES-256-GCM envelope — before they are written to object storage. This is not an option but a boot condition: if server-side encryption is not configured on the storage side, the service refuses to start unless application-layer encryption is enabled. There is no configuration in which an unencrypted document object can be written.

Phone numbers in the wallet

On the wallet side a phone number is never stored in plaintext. Two derivatives are produced at write time:

• A peppered HMAC-SHA256 — for matching and uniqueness; the raw number cannot be recovered
• A mask — for display (leading digits + last two)

The pepper comes from environment configuration and has no insecure default: if it is not set, the service fails to start.

Beneficiary IBANs

For bank dispatches the beneficiary IBAN is encrypted with AES-256-GCM, alongside a masked display value and an HMAC fingerprint. If the encryption key is absent the service will not start — there is no fallback to plaintext.

Redaction in logs and error traces

A shared redaction layer runs across the platform and it is actually wired — into the central log pipeline, the error-tracking (Sentry) pipeline, and inter-service error filters.

It works on two axes:

• Field-name axis — fields whose key contains fragments such as tckn, tcKimlik, nationalId, passport, taxNumber, cardholder, firstName, dateOfBirth are masked
• Content axis — 13–19 digit runs in free text are validated with the Luhn algorithm, and 11 digit runs with the TCKN check-digit algorithm. Only values that pass validation are masked, so arbitrary order numbers are left intact

Retention and destruction

This section covers the identity verification (KYC) and identity/device signal side. Retention windows, end-of-window behaviour and legal-hold rules for the other products live on their own pages: fraud prevention and wallet.

Retention is resolved per jurisdiction:

Periods are overridable per installation via environment configuration.

The destruction engine is saga-based:

1. Every artifact to be destroyed is written to an immutable manifest before any deletion occurs
2. Execution proceeds through progress checkpoints — after a crash it resumes where it stopped rather than restarting
3. On completion a signed destruction certificate is produced (digest + signature + key id) and attached to the destruction record

Biometric images have a separate scheduler with a hard seven-day floor enforced in code — configuration cannot go below it.

Erasure and data-subject requests

The endpoints below are operator endpoints — they require authentication and pass through role-based authorisation.

The export itself is written to the audit trail — so "whose data, when, exported by whom" is on record.

Proof of erasure

• On the identity verification side, proof consists of the signed destruction certificate plus a hash-chained audit log: each row's digest is derived from its own content and the previous row's digest, so insertion of a record or re-linking of the chain is detectable.
• On the identity/device signals side there is additionally an append-only erasure event table; rows cannot be updated or deleted, and this is enforced at database level. That table holds no raw personal data — only pseudonymised selector digests.

Cross-border transfers

Data generated in Türkiye is hosted on our own infrastructure. The storage target and key management are determined by installation configuration, and a region-specific separate installation can be provisioned. For a hosting and transfer statement specific to your installation, request written confirmation from [email protected].

Related pages

• GDPR — processing model and DPA for EU personal data
• MASAK — anti-money-laundering obligations in Türkiye
• PCI DSS — how card data is handled

For the Data Processing Agreement and an installation-specific list of technical measures, email [email protected].