Founder
March 15, 2026
25 min read
In brief: Saying that a system "uses ZKP" does not automatically place it outside personal data law. The decisive test is whether on-chain or off-chain outputs—alone or when matched with other data—lead to an identified or identifiable natural person. Zero-knowledge proofs are a strong technical measure for data minimisation because they allow verification without disclosing raw data; but if proof outputs, status records, or wallet addresses are persistent and public, they can still qualify as personal data under Turkish law when linkability exists. Turkish precedent (Kurul Decision 2023/570) confirms that AML-mandated identity verification can justify extensive collection when ring-fenced for compliance—and that ZKP is well placed to satisfy both KVKK minimisation and SPK/MASAK identification demands. Genesis Hukuk structures this analysis for projects combining ZKP, blockchain, and tokenisation so that compliance by design is achievable from day one.
In practice: Under Law No. 6698 on the Protection of Personal Data (KVKK), personal data means any information relating to an identified or identifiable natural person. Processing covers a very broad set of operations—obtaining, storing, retaining, disclosing, transferring, and more. That broad definition prevents the claim "there is no raw identity data on-chain" from alone implying that no personal data is processed; indirect identifiers that make a person determinable can still be personal data.
Subject: KVKK (Turkish Personal Data Protection Law).
Predicate: Defines personal data as information relating to an identified or identifiable natural person and processing as any operation performed on that data.
Object: A legal regime that applies whenever data can—directly or indirectly—be linked to a natural person.
European data protection practice directly influences KVKK application: the Turkish Data Protection Authority (Kişisel Verileri Koruma Kurumu, "Kurul") cites EU materials, and the KVKK standard that data must not be linkable "even when matched with other data" aligns with the GDPR Recital 26 idea of "reasonable means" for identifiability. The European Data Protection Board (EDPB) 2025 draft blockchain guidance states that public keys and addresses can be personal data when they allow identification by reasonable means, and that hashed or salted values often retain personal data character in many architectures.
The bar for anonymisation: Turkish law sets a high bar for anonymisation: data must be processed so that it cannot be associated with an identified or identifiable person even when combined with other data. The same logic appears in the Regulation on Deletion, Destruction and Anonymisation of Personal Data and in Kurul guidance on re-identification, singling out, and inference risks.
For special categories of data (e.g. biometric and genetic data), the threshold is higher: as a rule they may not be processed without explicit consent, and the Authority may require "adequate measures." Kurul has found that using biometrics for access control when alternatives exist can breach proportionality, and tying a service to biometric consent can undermine the voluntariness of that consent.
Leading precedent: The most authoritative Turkey-specific precedent on crypto-asset identity verification is Kurul Decision 2023/570 (11 April 2023). It confirms that when AML identification duties under Law No. 5549 conflict with general data minimisation, the AML mandate can provide a lawful basis for extensive data collection—and that ZKP is well positioned to satisfy both regimes.
The case concerned a Crypto Asset Service Provider (CASP) that required users to submit high-resolution scans of ID (front and back), a biometric selfie holding the ID and a handwritten note with a platform phrase and date, to move from "Basic Level" (fiat and deposit) to "Advanced Level" (crypto withdrawal). The complainant argued this was excessive and disproportionate under KVKK. The Board evaluated the CASP as an "Obliged Party" under the Regulation on Measures to Prevent Laundering Proceeds of Crime and Financing of Terrorism (Law No. 5549). It held that verifying the withdrawal is initiated by the verified account holder is a fundamental security measure against money laundering and terrorist financing, and that the processing was lawful under KVKK Article 5(2)(a) ("clearly foreseen in laws"). The collection was deemed proportionate to the risks of anonymous crypto withdrawals, provided data is ring-fenced for compliance.
Implication for ZKP and on-chain identity: Decision 2023/570 does not rule on ZKP mechanics explicitly, but it clarifies the gap ZKP and Verifiable Credentials can fill. A CASP or dApp that uses ZKP so the user proves verified identity and non-sanctioned status without repeatedly exposing selfie or ID to a central database can meet MASAK’s AML expectations while honouring KVKK data minimisation. Existing Kurul guidance on security and minimisation supports adopting privacy-enhancing technologies that meet statutory KYC without unnecessary plaintext exposure.
How we map it: The mapping below deliberately avoids shortcuts such as "ZKP → automatically anonymous" or "hash → automatically personal data." For each component we ask: (i) does it create identifiability alone or when combined with other data? (ii) who controls purpose and means? (iii) is the output legally anonymous or only privacy-enhancing?
For ZKP specifically: ZKPs can enable verification without storing raw data on-chain. If the proof’s public inputs, verification transcript, or the address/DID to which the proof is bound are stable and linkable, the output can still qualify as personal data.
Subject: A zero-knowledge proof (ZKP).
Predicate: Is a cryptographic method that allows one party to prove a statement to another without revealing the underlying data.
Object: Verification that satisfies the verifier while minimising disclosure.
The EDPB blockchain draft notes that some chains use advanced cryptography, including ZKP, to hide identity, but that surrogate data replacing the hidden identity may still be personal data. For ZKP to support a legally robust "anonymisation" narrative, unlinkability is critical: the same person’s different verifications must not tie to the same persistent identifier (e.g. randomised proofs, one-time nullifiers, pairwise identifiers). This aligns with discussions on European digital identity wallets and "breaking the link" via randomised proofs.
When a hash is still personal data: A hash alone may not look like "identity information," but if the underlying dataset is personal data and the hash is used to match or attest to the data subject, in most scenarios it remains within the scope of personal data.
The EDPB states clearly that even in designs where a salted or keyed hash is stored on-chain and raw data and salt/key are kept off-chain, the hash can still be personal data; it also notes that unsalted/unkeyed hashes on public chains generally do not provide sufficient privacy. Under KVKK, the "even when matched with other data" standard and guidance on anonymisation (no re-identification when combined with other datasets) mean that whether a hash is treated as anonymous turns on salt/key management, matching capability, and persistence.
Status records on-chain: Storing only a status on-chain—e.g. "valid/invalid," "KYC-ok," "authorised/member"—does not automatically take the data outside KVKK. Personal data is "any information" relating to a person; outcome, score, or status records about a person can be personal data.
If the status is tied to a specific address, credential ID, or SBT-style marker, identifiability is quickly established. Risk increases if the status implies special categories (e.g. health, union membership, biometric verification result, or compliance/sanctions information). The EDPB stresses that on-chain data is not limited to transaction payloads; smart contract storage and receipt logs can also contain personal data.
Wallet addresses: A wallet address is a stable identifier. Together with transaction history it can single out a person and, when combined with other datasets, trigger "identifiability" under Turkish law. The question "Is an address alone personal data?" is usually answered by context: if an entity can link the address to a user (e.g. via KYC, logs, or IP), the personal data assessment strengthens.
The EDPB states that public keys can be personal data when they allow identification by reasonable means.
Soulbound-style markers: Soulbound-style designs aim to create persistent, non-transferable identity or reputation markers. That increases the potential for long-term profiling and creates tension with KVKK principles of purpose limitation, proportionality, and storage limitation.
Foundational soulbound literature describes such tokens as encoding commitments, credentials, or affiliations tied to wallets and building webs of trust—which readily produces "information relating to a person." The EDPB’s warnings on avoiding personal data on-chain and on linkability apply directly to SBT-like public markers.
SSI architecture: The W3C verifiable credentials model describes an issuer–holder–verifier ecosystem where the holder can present to the verifier without disclosing the verification act to the issuer. Legally, a well-designed flow can support data minimisation; however, verifier and wallet/application logs and telemetry can create a separate layer of personal data processing.
Hybrid models: Hybrid models often keep data off-chain and put only a proof, binding, or commitment on-chain to reduce the clash between KVKK’s deletion obligation (Art. 7) and blockchain immutability. The EDPB discusses storing only "proof of existence" (hash/commitment/pointer) on-chain and keeping verification data off-chain as a preferable direction compared with writing personal data on-chain—while noting this is risk reduction, not a guarantee. For the on-chain marker to count as legally "anonymous," it must not allow identification even when combined with other datasets; KVKK anonymisation guidance is built on that same idea.
Regulatory integration: Implementing digital identity, tokenisation, or DeFi in Turkey requires a single narrative that integrates KVKK with SPK (capital markets) and MASAK (AML). Relying on KVKK alone is insufficient; the main regulatory friction lies at the intersection of privacy and financial transparency. ZKP and Verifiable Credentials can bridge strict KYC/Travel Rule demands and data minimisation.
On 28 February 2026, the Capital Markets Board (SPK) amended Communiqué III-42.1.a, bringing Crypto Asset Service Providers under the same remote identification and electronic contract rules as regulated brokers and portfolio managers. CASPs may use AI-driven remote identification (no mandatory live human agent) only if they meet strict technical and procedural conditions.
MASAK alignment: AI remote identification must comply with MASAK General Communiqué (Sequence No. 19) Article 4/9. Liveness and security: The session must be online and real-time; video verification must use secure, end-to-end communication to prevent deepfakes and presentation attacks. Biometric accuracy: The face comparison algorithm must have a documented False Acceptance Rate (FAR) of less than 1 in 10,000,000. TSE certification: Compliance with the 1/10,000,000 FAR must be evidenced by a report from the Turkish Standards Institute (TSE), unless the biometric provider has equivalent international accreditation. Risk and burden of proof: Customers onboarded via remote ID must be subject to a differentiated, higher-scrutiny risk profile; in disputes, the burden of proof that the transacting party was correctly identified lies with the CASP.
For on-chain identity and SSI: any verifiable credential used for KYC in Turkey should be issued via a process that meets or exceeds this FAR standard. Credentials minted with sub-standard verification are unlikely to be relied on by regulated CASPs.
MASAK’s updated Guide for Crypto Asset Service Providers (KVHS) enforces the FATF Travel Rule (Seyahat Kuralı): verified identity information must "travel" with the transfer above a threshold, making the transaction transparent to authorities.
Threshold: For transfers of 15,000 TL or more, sender and recipient data must be included in messages between institutions. Sender: Full name, surname (or trade name), wallet address, and a unique identifier (e.g. Turkish ID number, passport, or full address). Identity must be verified by the originating CASP before the transfer. Receiver: Full name, surname, and destination wallet address. Incomplete data: The receiving CASP must attempt "Tamamlatma" (completion); if data cannot be obtained, the transfer must be rejected and funds returned. Custody: Where 100% of customer assets are custodied by a separate custodian, Travel Rule obligations fall on the custodian; the custodian must hold the underlying KYC data.
ZKP and the Travel Rule: MASAK requires transmission and availability of identity data between Obliged Parties. Legacy compliance often sends plaintext via central APIs alongside the on-chain transaction, creating concentration risk and KVKK exposure. Using DIDs and zero-knowledge proofs, a CASP can transmit a cryptographic commitment of the user’s identity—verifiable by the receiving CASP against a registry or trusted issuer—without broadcasting plaintext across messaging networks. Any ZKP design for the Turkish market must still allow: on lawful, targeted request from MASAK or the judiciary, the CASP must be able to assemble and produce the underlying plaintext identity linked to the proof. A ZKP system that permanently severs the link to real-world identity would conflict with MASAK’s monitoring and record-keeping duties and risk sanctions.
Turkey and eIDAS 2.0: Turkey is not bound by the EU’s eIDAS 2.0 regulation, but the Digital Transformation Office and national infrastructure align with European interoperability to support cross-border digital trade. Building to EU digital identity standards future-proofs ZKP and verifiable credential systems.
The EU’s eIDAS 2.0 (in force May 2024) mandates the EU Digital Identity (EUDI) Wallet: citizens store verifiable credentials on-device and share them with minimal disclosure and ZKP, retaining control. Very Large Online Platforms and core services must accept the EUDI wallet for authentication. Turkey’s e-Devlet already acts as a central identity provider with 2FA, mobile signatures, and qualified electronic signatures tied to the biometric chip of the Turkish ID card. Turkish trust providers use ETSI standards so that Qualified Electronic Signatures stay on a par with European ones. For ZKP and on-chain identity: identity architectures should be designed with open APIs and credential models that can interoperate with the EUDI ecosystem; otherwise they risk obsolescence as Turkish systems converge with the EU framework.
Be the first to be informed about our new articles, opinions and case studies in the field of Blockchain.
Who is in control: Under KVKK, who is controller or processor is driven by who determines the purpose and means of processing (and who has factual or normative control), not by who runs the servers. Kurul Decision 2020/71 summarises this in terms of who decides on data types, collection method, retention, and access.
In issuer–verifier–holder setups, issuers are typically controllers when they collect data and issue credentials for identity/KYC/certification; verifiers are often separate controllers when they verify and make decisions (e.g. onboarding, access, age checks). The holder is usually the data subject; if the wallet or app operator collects telemetry, device identifiers, IP, or fraud signals, that operator can be a separate controller for that processing.
In off-chain KYC + on-chain proof/status designs, who operates the status or revocation contract matters: if the issuer (or a consortium) decides which key updates the registry, which events write "revoked/valid," and which identifier goes on-chain, that party’s controller role on the on-chain layer strengthens. Where an on-chain layer serves multiple organisations (e.g. a shared revocation or status list) and they share control and benefit, Kurul’s approach to joint controllership (as in its "blacklist" decision) can apply: the initial collectors, those who use and can access the data, and the software/infrastructure enabling sharing may be assessed together.
Protocols or networks that do not "actually collect raw data" do not automatically escape responsibility. Kurul’s joint-controller analysis emphasises control and benefit: who decides what is recorded, who can change or delete it, and who has dominance and commercial interest over the data. If a protocol governance defines identity markers (e.g. SBT markers, global revocation lists), what is written on-chain, access rules, and standard flows, and derives economic or institutional benefit, a case for joint controllership in at least some processing operations can be made, depending on the concrete setup.
Node/validator roles are not explicitly defined in KVKK. European authorities stress that roles should be determined at design stage and that different architectures yield different roles; the French DPA (CNIL) has discussed smart contract developers and in some cases miners as processors where they perform technical verification on instructions. That functional approach is consistent with KVKK’s focus on control over purpose and means.
Standards that count: Turkish regulators and auditors assess "adequate security" and "appropriate verification" by reference to recognised standards, not custom code. Mapping your ZKP or digital identity system to named standards (ISO 27001, TSE biometrics, ETSI, W3C VC) strengthens auditability and compliance narratives.
ISO/IEC 27001: The baseline for data controllers in Turkey. Kurul treats an active, independently audited ISO 27001 certificate as a strong indicator that technical and organisational measures under KVKK Article 12 are in place. For CASPs and blockchain identity projects, ISO 27001 covers key lifecycle, access control, and logging.
TSE biometric certification: Under SPK Communiqué III-42.1.a (2026), AI-driven remote identification must meet a False Acceptance Rate of less than 1 in 10,000,000, evidenced by a TSE report (or equivalent international accreditation). This defines the minimum assurance level for credentials used in Turkish regulated finance.
ETSI (eIDAS alignment): ETSI EN 319 401 (general policy for trust service providers) and ETSI TS 119 461 (identity proofing and onboarding) are used to show that digital onboarding has equivalent legal weight to in-person verification and aligns with eIDAS 2.0.
W3C Verifiable Credentials Data Model: Not yet cited in Turkish primary legislation, but the de facto basis for the EUDI wallet and interoperable SSI. Using the W3C VC model supports documented data minimisation and purpose limitation and keeps Turkish systems compatible with global SSI and ZKP developments.
Deletion and the chain: KVKK Art. 7 requires personal data to be deleted, destroyed, or anonymised when the grounds for processing cease; the Regulation defines anonymisation again by the "even when matched with other data" standard. Kurul guidance ties the anonymisation guarantee to re-identification and dataset-combination risks and to the controller’s duty to consider whether recipients or public data can break anonymity.
72-hour rule: Under KVKK, a "security incident" includes unauthorised access to cryptographic keys or salt, even if the main database was not accessed. Notification to the Board and to data subjects must be made within 72 hours of the controller becoming aware of the breach (Kurul Decision 2019/10).
Kurul’s Personal Data Security Guide states that keys must be stored separately from the encrypted data. If keys or salt are compromised—or the private key backing an on-chain ZKP commitment is exposed—the pseudonymised data is considered at risk and a reportable incident is triggered. For CASPs and digital identity platforms: compromise of a hot wallet environment where admin keys link to user identities or KYC data, or breach of a central DID–identity mapping database, requires immediate investigation and a detailed breach notification to Kurul (affected records, risks, and mitigating measures). If a processor (e.g. external KYC or cloud provider) suffers the breach, it must notify the Turkish data controller without delay so the controller can meet the 72-hour deadline.
Two layers of tension with immutable ledgers: (1) Technical: Once written, a record cannot be unilaterally removed; the EDPB notes the absence of a default deletion mechanism and that design must account for personal data compliance. (2) Legal: Turkish law does not codify "technical impossibility" as a general exemption from Art. 7; if the design does not allow deletion or anonymisation, the chain layer creates a structural compliance risk.
Three practical strategies (none of which is "automatic anonymisation"):
Avoid writing personal data on-chain: Use the chain only for proof-of-existence (commitment, pointer, keyed hash) and keep verification data off-chain. The EDPB supports limiting on-chain content to proof/pointer/commitment and keeping verification data off-chain. That allows deletion in the central system, but the linkability of what remains on-chain must still be assessed.
Encryption and key management: The EDPB states that encrypted personal data remains personal data and that encryption does not remove the need for compliance; it also notes that cryptography can weaken over time if the chain is retained indefinitely. Under Turkish law, true anonymisation requires irreversibility; encryption alone, while keys exist, does not suffice. Whether key destruction counts as "destruction" or "anonymisation" depends on the concrete threat model (irrecoverability of keys, backups, HSM procedures) and Kurul’s approach.
Salted/keyed hash plus salt/key destruction: The EDPB states that even where salted/keyed hashes are on-chain, the hash can be personal data; it also notes that if salt/key are destroyed, the hash may become unlinkable, subject to algorithm, salt choice, and key leakage. That can reduce linkability, but KVKK’s "even when combined with other datasets" criterion means long-term risk on public chains (new side-channel data, better analysis) must be considered.
Cross-border in practice: Law No. 7499 overhauled KVKK Article 9 so that cross-border transfer aligns more closely with the GDPR. Transfers rely on adequacy, Standard Contractual Clauses (SCCs)—with digital notification to the Board within 5 business days of signing—or other safeguards. Kurul applies an effect principle: platforms that target Turkey are subject to KVKK regardless of where they are established. For public, permissionless blockchains, signing SCCs with thousands of anonymous validators is impossible; personal data (raw, hashed, or reversibly encrypted) must not be written to the public chain. Only non-reversible mathematical artefacts (hashes with destroyed keys, DIDs, Merkle roots, ZKPs) should be anchored on-chain to avoid triggering a cross-border transfer of personal data.
Three tiers under the updated Article 9: (1) Adequacy — free transfer to countries or sectors the Board has declared adequate (reviewed on a multi-year cycle). (2) Appropriate safeguards — Board-approved SCCs or Binding Corporate Rules; SCCs must be notified to the Board within 5 business days of signing (failure can attract fines from 90,000 TL up to 1.8 million TL). (3) Exceptional transfers — e.g. consent or contract performance; the Board treats "exceptional" as occasional, not systematic. A CASP or identity platform that routinely sends KYC data to foreign servers or a foreign AI vendor must use Tier 2, not Tier 3.
2026 penalties: Under KVKK Article 18, the Board imposes administrative fines that are updated annually. In 2026, maximum fines for data security failures reach 17,092,242 TL; missing the 5-day SCC notification can incur up to 1.8 million TL. Willful or systemic mishandling of personal data can also trigger criminal liability under the Turkish Penal Code (TCK) Articles 135–140.
Failure to inform (privacy notice): In 2026 the minimum is 85,437 TL and the maximum 1,709,200 TL. For ZKP and identity projects, explaining blockchain, immutable processing, and hashing in privacy notices is essential. Failure to ensure data security: Minimum 256,357 TL, maximum 17,092,242 TL. Key risk areas are key management, KYC database access, smart contract metadata leaks, and penetration testing. Failure to register with VERBIS: Minimum 341,809 TL, maximum 17,092,242 TL. Technology platforms, tokenisation services, and CASPs must register their processing in the Data Controllers’ Registry. Breach of cross-border notification (SCC): The Board must be notified within 5 business days of signing an SCC; breach carries a minimum of 90,000 TL and a maximum of 1,800,000 TL.
For CASPs and digital identity providers handling biometrics and financial data, a single serious breach can attract the upper end of these ranges and regulatory scrutiny. The cost of implementing privacy-preserving design (including ZKP) is typically lower than the cost of non-compliance.
Defensible position: Under KVKK, a defensible general position is: Even when raw personal data is not stored on-chain, on-chain address links, status records, hashes/commitments, or cryptographic proof outputs can be personal data if they lead to an identified or identifiable natural person when combined with other data; controller/processor roles follow who factually or normatively controls the purpose and means of processing these outputs.
Red lines vs manageable risks should be drawn by (i) linkability, (ii) publicity and persistence, (iii) possible special-category data, (iv) compliance with deletion/anonymisation, and (v) clarity of roles—not by the name of the technical component.
Near red-line designs often include: writing biometric templates or raw biometric output (or a marker that singles out biometric matching) on-chain or exposing it via persistent on-chain status; making biometric verification a condition of service when alternatives exist; building long-term identity/reputation graphs with public, non-transferable markers (SBT-like); leaving unsalted/unkeyed hashes as identity references on-chain; or global revocation/status lists that allow tracking via credential ID or address.
Manageable-risk designs typically embed technical measures as design principles: biometric input processed on-device with no operator access to templates; holder proving only the necessary attribute with randomised ZKP so the link breaks per verification; pairwise identifiers so the same person uses different addresses/DIDs per service; on-chain limited to commitment/keyed hash with verification data in a controlled off-chain system; and for special categories, full application of Kurul’s "adequate measures" (cryptography, key separation, logging, 2FA, etc.).
Pseudonymisation: KVKK does not explicitly define "pseudonymised data"; Kurul’s use of EU materials and doctrine supports treating it as a risk-reduction category that often remains personal data, especially on public chains where "unidentified recipients" make the "even when matched" test harder to bound.
Wallet address alone: Whether an address is personal data "alone" is not fully settled in Turkey; the EDPB uses a context-based test (reasonable means to identify). In the absence of clear Kurul precedent on blockchain addresses, the safer assumption is that addresses are in practice often linkable via KYC, device/IP, or transaction analysis and should be treated as default personal data risk.
Key destruction = deletion/anonymisation: The EDPB accepts that destroying keys can make encrypted data unreadable but stresses that encrypted data remains personal data and that cryptography can degrade over time. Under KVKK, anonymisation hinges on irreversibility; key destruction must be genuinely irreversible in the concrete setup, and risk should be reassessed periodically.
Protocol/DAO/node/validator roles: How to classify these under KVKK is still debated even in the EU. The EDPB expects role analysis at design time; CNIL has discussed miners/validators as processors in some cases but acknowledges enforceability challenges. Kurul’s broad reading of joint controllership (e.g. shared blacklist) could weaken a bare "the protocol does not collect data" defence.
Depending on audience and risk appetite, Genesis Hukuk frames the outcome as follows:
Client-oriented (aggressive): "With ZKP and off-chain storage we do not keep raw personal data on-chain; on-chain records are purely cryptographic status indicators and we do not hold additional data that would make identity determinable, so personal data processing risk under KVKK is largely mitigated."
Balanced (defensible): "Absence of raw data on-chain is not sufficient by itself; on-chain address/status/proof outputs can be personal data when combined with other data; therefore roles should be assigned by control and benefit, and the architecture should systematically break linkability (randomised proofs, pairwise identifiers, off-chain storage, minimal on-chain proof)."
Strict (regulator-facing): "On-chain address, status record, hash/commitment or proof output is personal data under KVKK whenever any actor can link it to an identified or identifiable natural person by reasonable means; therefore personal data should not be written to public or immutable chains, special categories (including biometrics) should only be processed off-chain with proportionality, free consent, and Kurul’s adequate measures, and a lifecycle compatible with Art. 7 deletion must be designed."
No. ZKP allows verification without disclosing raw data and supports data minimisation, but if the proof’s public inputs, verification transcript, or the bound address/DID are stable and linkable, the output can still be personal data. The test is identifiability, alone or with other data, not the presence of ZKP.
Not defined in KVKK in so many words. In practice, addresses are often linkable via KYC, logs, or transaction analysis. The EDPB treats public keys as personal data when they allow identification by reasonable means. The safer stance for projects is to assume addresses carry personal data risk unless the opposite is clearly justified.
Typically the issuer is controller for collection and credential issuance; the verifier is controller for its own verification and decisions. If the wallet or app operator collects telemetry or identifiers, that operator can be a separate controller. Joint controllership can arise where several parties share control and benefit (e.g. shared status or revocation lists).
Hashes derived from personal data are often still personal data under KVKK and EDPB guidance, especially if they can be used to match or attest to a person. Salted/keyed hashes with salt/key destroyed can reduce linkability, but the "even when matched with other data" standard and long-term re-identification risk on public chains must be considered. Design should minimise and, where possible, avoid personal data on-chain.
Art. 7 requires deletion, destruction, or anonymisation when processing grounds cease. Immutability means on-chain data cannot be simply "deleted." The most defensible approach is not to write personal data on-chain (use commitments/hashes/pointers only) and keep verification data off-chain so that deletion can be performed in the off-chain system. Key destruction may count as anonymisation only if it is truly irreversible in the specific setup.
Map all on-chain and off-chain outputs against identifiability (alone and with other data), assign controller/processor roles by purpose and means, design to break linkability (e.g. randomised ZKP, pairwise identifiers, minimal on-chain proof), and ensure special-category data is processed only with a lawful basis, consent where required, and Kurul’s adequate measures. Align with SPK remote-ID and MASAK Travel Rule where you are a CASP; use recognised standards (ISO 27001, TSE, ETSI, W3C VC) for audits. Genesis Hukuk advises on architecture and compliance by design for ZKP, digital identity, and tokenisation in Turkey.
Kurul Decision 2023/570 (11 April 2023) held that a CASP’s collection of ID scans and biometric selfies to upgrade users to "Advanced Level" (crypto withdrawal) was lawful under KVKK Article 5(2)(a), because the CASP is an Obliged Party under AML rules (Law No. 5549) and verifying the account holder is necessary to prevent money laundering and terrorist financing. The Board found the processing proportionate given the risks of anonymous withdrawals. The decision does not mention ZKP explicitly but supports the use of privacy-enhancing verification (e.g. ZKP) that meets AML requirements while minimising stored plaintext data.
For crypto transfers of 15,000 TL or more, MASAK requires sender and recipient identity data to be transmitted between CASPs. ZKP and DIDs can allow a cryptographic commitment of identity to be sent instead of plaintext, verifiable by the receiving CASP, reducing KVKK exposure. Any such design must still allow the CASP to produce the underlying identity data on lawful request from MASAK or the judiciary; otherwise it conflicts with continuous monitoring and record-keeping duties.
If personal data is obtained by unauthorised parties, the data controller must notify the Board and data subjects within the shortest time. Kurul Decision 2019/10 interprets this as 72 hours from when the controller becomes aware of the breach. Unauthorised access to cryptographic keys or salt (even without access to the main database) can constitute a reportable security incident. Processors must notify the controller immediately so the controller can meet the 72-hour deadline.
Under the updated KVKK Article 9, cross-border transfer of personal data requires an identifiable data exporter and importer and a legal tool (e.g. SCC) to protect the data. Public blockchains replicate data across many anonymous validators in multiple countries; it is not possible to sign SCCs with all of them. Therefore, to comply with Turkish cross-border rules, personal data—including hashed or reversibly encrypted data that remains personal data—should not be written to public, permissionless ledgers. Only non-reversible artefacts (e.g. hashes with destroyed keys, DIDs, Merkle roots, ZKP outputs) should be anchored on-chain.
Under Article 18 KVKK, 2026 administrative fines include: failure to inform (up to 1,709,200 TL), failure to ensure data security (up to 17,092,242 TL), failure to register with VERBIS (up to 17,092,242 TL), and breach of cross-border notification (e.g. missing the 5-day SCC notification to the Board, up to 1,800,000 TL). Serious or willful mishandling of personal data can also lead to criminal liability under the Turkish Penal Code (Articles 135–140).
Genesis Hukuk is a Law + Tech studio focused on compliance by design wherever blockchain and tokenisation are used. We combine legal analysis with technical architecture so that ZKP, on-chain identity, and tokenisation are built on a defensible KVKK and regulatory footing from the start.
Zero Knowledge Banking: Privacy, Security, Legal Compliance — KYC/AML, data privacy, and ZK in finance; RWA tokenisation and fintech consulting.
Digital Identity & DID Tokenization Legal Services — SSI, DID, verifiable credentials, NFT and tokenisation; compliance with KVKK, SPK, HMK and digital identity frameworks.
Real World Asset (RWA) Tokenization in Turkey — End-to-end legal support for tokenisation of real-world assets and related licensing in Turkey.
Smart Contract Analysis & Auditing — Contract review and auditing tailored to Turkey’s market, including identity and compliance logic.
For a technical and legal review of your ZKP or on-chain identity design under Turkish law, contact Genesis Hukuk: info@genesishukuk.com | genesishukuk.com
Zero-Knowledge Proof: Banking's KVKK & BDDK Solution — ZKP in Turkish banking, data privacy and regulator compliance.
The Legal Transformation of Digital Identity and Asset Management: Smart Accounts, AI, eIDAS 2.0, and DePIN — SSI, account abstraction and digital identity under law.
A Framework for Legally Compliant Smart Contracts: Compliance by Design — MiCA, Ricardian contracts and ZKP in smart contract design.
Security Tokenization in Turkey with ERC-3643 Standard — RWA and security tokenisation in Turkey.
Crypto Asset Regulation and Compliance Guide in Türkiye — SPK, MASAK, Travel Rule and digital identity verification (2025–2026).
Kurul Decision 2023/570 (11 April 2023), summary: kvkk.gov.tr
KVKK (Law No. 6698); Regulation on Deletion, Destruction and Anonymisation of Personal Data
SPK Communiqué III-42.1.a (amendments Feb 2026) — remote identification and CASPs
MASAK Guide for Crypto Asset Service Providers (KVHS), updated 2025 — Travel Rule (Seyahat Kuralı)
Law No. 5549 — Prevention of Laundering Proceeds of Crime
Law No. 7499 — amendments to KVKK Article 9 (cross-border transfer)
Kurul Decision 2019/10 — 72-hour breach notification
KVKK Board Personal Data Security Guide; Kurul cross-border transfer guide
EDPB draft blockchain guidance (2025); eIDAS 2.0 (EU Regulation, May 2024)
ISO/IEC 27001; ETSI EN 319 401, ETSI TS 119 461; W3C Verifiable Credentials Data Model
This publication is for informational purposes only and does not constitute legal advice. Consult qualified counsel for your specific situation. Last updated: March 2026.
