ZKP и ончейн-идентичность по турецкому праву: правовой статус доказательств с нулевым разглашением и верификации идентичности в блокчейне

Резюме

Кратко: Утверждение о том, что система «использует ZKP», само по себе не выводит её за рамки законодательства о персональных данных. Решающий критерий — приводят ли ончейн- или офчейн-результаты — сами по себе или в сочетании с другими данными — к установлению или установимому физическому лицу. Доказательства с нулевым разглашением (ZKP) представляют собой сильную техническую меру минимизации данных, так как позволяют верифицировать без раскрытия исходных данных; однако если выходные данные доказательства, записи о статусе или адреса кошельков постоянны и публичны, они по-прежнему могут квалифицироваться как персональные данные по турецкому праву при наличии связуемости. Турецкий прецедент (решение Kurul 2023/570) подтверждает, что верификация идентичности в рамках AML может обосновывать широкий сбор данных при изоляции для целей соответствия — и что ZKP хорошо подходит для удовлетворения как требований минимизации по KVKK, так и требований идентификации по SPK/MASAK. Genesis Hukuk структурирует этот анализ для проектов, сочетающих ZKP, блокчейн и токенизацию, чтобы соответствие по замыслу было достижимо с первого дня.

1. Правовые рамки: турецкое законодательство о персональных данных и блокчейн

1.1 Как турецкое право определяет персональные данные и их обработку

На практике: По Закону № 6698 о защите персональных данных (KVKK) персональные данные — это любая информация, относящаяся к определённому или определяемому физическому лицу. Обработка охватывает очень широкий круг операций: получение, хранение, удержание, раскрытие, передача и др. Это широкое определение не позволяет утверждать, что «в ончейне нет сырых данных об идентичности» как таковому означать отсутствие обработки персональных данных; косвенные идентификаторы, позволяющие определить лицо, по-прежнему могут быть персональными данными.

• Субъект: KVKK (турецкий закон о защите персональных данных).

• Содержание: Определяет персональные данные как информацию, относящуюся к определённому или определяемому физическому лицу, и обработку — как любую операцию с такими данными.

• Объект: Правовой режим, применяемый, когда данные могут — прямо или косвенно — быть связаны с физическим лицом.

Европейская практика защиты данных напрямую влияет на применение KVKK: Турецкий орган по защите персональных данных (Kişisel Verileri Koruma Kurumu, «Kurul») ссылается на материалы ЕС, а стандарт KVKK о том, что данные не должны быть связуемы «даже в сочетании с другими данными», согласуется с идеей Рекатала 26 GDPR об «разумных средствах» установления идентифицируемости. В проекте руководства EDPB по блокчейну 2025 г. указано, что открытые ключи и адреса могут быть персональными данными, когда позволяют идентификацию разумными средствами, а хешированные или «подсоленные» значения во многих архитектурах часто сохраняют характер персональных данных.

1.2 Анонимизация и специальные категории по KVKK

Планка анонимизации: Турецкое право устанавливает высокую планку для анонимизации: данные должны обрабатываться так, чтобы их нельзя было связать с определённым или определяемым лицом даже в сочетании с другими данными. Та же логика присутствует в Регламенте об удалении, уничтожении и анонимизации персональных данных и в руководстве Kurul по рискам повторной идентификации, выделения и вывода.

Для специальных категорий данных (например, биометрических и генетических) порог выше: как правило, они не могут обрабатываться без явного согласия, и орган может потребовать «адекватные меры». Kurul установил, что использование биометрии для контроля доступа при наличии альтернатив может нарушать соразмерность, а привязка услуги к биометрическому согласию может подрывать добровольность такого согласия.

1.3 Турецкий прецедент: решение Kurul 2023/570

Ведущий прецедент: Наиболее авторитетный турецкий прецедент по верификации идентичности в контексте криптоактивов — решение Kurul 2023/570 (11 апреля 2023 г.). Оно подтверждает, что когда обязанности по идентификации в рамках AML по Закону № 5549 вступают в противоречие с общей минимизацией данных, мандат AML может служить законным основанием для широкого сбора данных — и что ZKP хорошо подходит для удовлетворения обоих режимов.

Дело касалось провайдера услуг по криптоактивам (CASP), который требовал от пользователей предоставления сканов удостоверения личности в высоком разрешении (лицевая и оборотная стороны), биометрического селфи с документом и рукописной записки с фразой платформы и датой для перехода с «базового уровня» (фиат и депозит) на «продвинутый уровень» (вывод криптовалюты). Заявитель утверждал, что это избыточно и несоразмерно по KVKK. Kurul оценил CASP как «обязанное лицо» по Регламенту о мерах по противодействию отмыванию доходов и финансированию терроризма (Закон № 5549). Было указано, что верификация того, что вывод инициирован верифицированным владельцем счёта, является фундаментальной мерой безопасности против отмывания денег и финансирования терроризма и что обработка законна по ст. 5(2)(a) KVKK («прямо предусмотрена законами»). Сбор был признан соразмерным рискам анонимного вывода криптовалюты при условии изоляции данных для целей соответствия.

Значение для ZKP и ончейн-идентичности: Решение 2023/570 не формулирует явно механику ZKP, но проясняет пробел, который могут заполнить ZKP и верифицируемые учётные данные (Verifiable Credentials). CASP или dApp, использующий ZKP так, что пользователь доказывает верифицированную идентичность и статус без санкций без многократного раскрытия селфи или документа централизованной базе, может соответствовать ожиданиям MASAK по AML и при этом соблюдать минимизацию данных по KVKK. Существующее руководство Kurul по безопасности и минимизации поддерживает внедрение технологий усиления приватности, обеспечивающих установленную KYC без излишнего раскрытия открытого текста.

2. Соответствие технических решений праву: ZKP, хеши и ончейн-результаты

Как мы это сопоставляем: Нижеприведённое сопоставление сознательно избегает упрощений вроде «ZKP → автоматически анонимно» или «хеш → автоматически персональные данные». По каждому компоненту задаётся вопрос: (i) создаёт ли он идентифицируемость сам по себе или в сочетании с другими данными? (ii) кто определяет цель и средства? (iii) является ли результат юридически анонимным или лишь усиливающим приватность?

2.1 Доказательства с нулевым разглашением (ZKP)

Конкретно для ZKP: ZKP позволяют верификацию без хранения исходных данных в ончейне. Если публичные входы доказательства, протокол верификации или адрес/DID, к которому привязано доказательство, стабильны и связуемы, результат по-прежнему может квалифицироваться как персональные данные.

• Субъект: Доказательство с нулевым разглашением (ZKP).

• Содержание: Криптографический метод, позволяющий одной стороне доказать утверждение другой без раскрытия лежащих в основе данных.

• Объект: Верификация, удовлетворяющая верификатора при минимизации раскрытия.

В проекте EDPB по блокчейну отмечено, что некоторые цепи используют продвинутую криптографию, включая ZKP, для сокрытия идентичности, но суррогатные данные, заменяющие скрытую идентичность, по-прежнему могут быть персональными данными. Чтобы ZKP поддерживала юридически устойчивый нарратив «анонимизации», критична несвязуемость: разные верификации одного и того же лица не должны привязываться к одному и тому же постоянному идентификатору (например, рандомизированные доказательства, одноразовые nullifier’ы, парные идентификаторы). Это согласуется с обсуждениями европейских кошельков цифровой идентичности и «разрыва связи» через рандомизированные доказательства.

2.2 Хеш и хеш-корень (включая корень Merkle)

Когда хеш остаётся персональными данными: Сам по себе хеш может не выглядеть как «информация об идентичности», но если исходный набор данных — персональные данные и хеш используется для сопоставления или удостоверения субъекта данных, в большинстве сценариев он остаётся в сфере персональных данных.

EDPB чётко указывает, что даже в схемах, где подсоленный или ключевой хеш хранится в ончейне, а исходные данные и соль/ключ — офчейн, хеш по-прежнему может быть персональными данными; также отмечено, что неподсоленные/неключевые хеши в публичных цепях, как правило, не обеспечивают достаточной приватности. По KVKK стандарт «даже в сочетании с другими данными» и руководство по анонимизации (отсутствие повторной идентификации при объединении с другими наборами) означают, что трактовка хеша как анонимного зависит от управления солью/ключом, возможности сопоставления и постоянства.

2.3 Ончейн-записи о статусе

Записи о статусе в ончейне: Хранение в ончейне только статуса — например «действителен/недействителен», «KYC-ok», «авторизован/участник» — само по себе не выводит данные за рамки KVKK. Персональные данные — это «любая информация», относящаяся к лицу; записи о результате, оценке или статусе в отношении лица могут быть персональными данными.

Если статус привязан к конкретному адресу, ID учётных данных или маркеру в стиле SBT, идентифицируемость устанавливается быстро. Риск возрастает, если статус подразумевает специальные категории (например, здоровье, членство в профсоюзе, результат биометрической верификации или информация о соответствии/санкциях). EDPB подчёркивает, что ончейн-данные не ограничиваются полезной нагрузкой транзакций; хранилище смарт-контрактов и журналы квитанций также могут содержать персональные данные.

2.4 Публичные доказательства, привязанные к адресу кошелька

Адреса кошельков: Адрес кошелька — стабильный идентификатор. Вместе с историей транзакций он может выделить лицо и в сочетании с другими наборами данных привести к «идентифицируемости» по турецкому праву. Вопрос «Является ли адрес сам по себе персональными данными?» обычно решается контекстом: если субъект может связать адрес с пользователем (например, через KYC, логи или IP), оценка персональных данных усиливается.

EDPB указывает, что открытые ключи могут быть персональными данными, когда позволяют идентификацию разумными средствами.

2.5 Нетранспортируемые маркеры идентичности в стиле Soulbound (например, SBT)

Маркеры в стиле Soulbound: Схемы в стиле Soulbound направлены на создание постоянных, нетранспортируемых маркеров идентичности или репутации. Это увеличивает потенциал долгосрочного профилирования и создаёт напряжение с принципами KVKK об ограничении цели, соразмерности и ограничении хранения.

Фундаментальная литература о soulbound описывает такие токены как кодирующие обязательства, учётные данные или принадлежности, привязанные к кошелькам и выстраивающие сети доверия — что легко даёт «информацию, относящуюся к лицу». Предупреждения EDPB об избежании персональных данных в ончейне и о связуемости напрямую применимы к публичным маркерам в стиле SBT.

2.6 Архитектура эмитент — верификатор — держатель (SSI / верифицируемые учётные данные)

Архитектура SSI: Модель верифицируемых учётных данных W3C описывает экосистему эмитент — держатель — верификатор, где держатель может предъявлять верификатору без раскрытия акта верификации эмитенту. С правовой точки зрения хорошо спроектированный поток может поддерживать минимизацию данных; однако логи и телеметрия верификатора и кошелька/приложения могут создавать отдельный слой обработки персональных данных.

2.7 Гибридные модели: офчейн-сбор + ончейн-верификация/статус

Гибридные модели: Гибридные модели часто хранят данные офчейн и помещают в ончейн только доказательство, привязку или коммитмент, чтобы снизить противоречие между обязанностью удаления по KVKK (ст. 7) и неизменяемостью блокчейна. EDPB обсуждает хранение в ончейне только «доказательства существования» (хеш/коммитмент/указатель) и хранение данных верификации офчейн как предпочтительное направление по сравнению с записью персональных данных в ончейн — при этом отмечая, что это снижение риска, а не гарантия. Чтобы ончейн-маркер считался юридически «анонимным», он не должен позволять идентификацию даже в сочетании с другими наборами данных; руководство KVKK по анонимизации построено на той же идее.

3. SPK и MASAK: верификация идентичности и правило Travel Rule

Регуляторная интеграция: Внедрение цифровой идентичности, токенизации или DeFi в Турции требует единого нарратива, объединяющего KVKK с SPK (рынок капитала) и MASAK (AML). Опора только на KVKK недостаточна; основное регуляторное трение лежит на стыке приватности и финансовой прозрачности. ZKP и верифицируемые учётные данные могут связать строгие требования KYC/Travel Rule и минимизацию данных.

3.1 Коммюнике SPK III-42.1.a: удалённая идентификация и ИИ (2026)

28 февраля 2026 г. Совет по рынку капитала (SPK) изменил Коммюнике III-42.1.a, подведя провайдеров услуг по криптоактивам под те же правила удалённой идентификации и электронного договора, что и регулируемых брокеров и управляющих портфелями. CASP могут использовать удалённую идентификацию на основе ИИ (без обязательного живого оператора) только при соблюдении строгих технических и процедурных условий.

Соответствие MASAK: Удалённая идентификация на ИИ должна соответствовать ст. 4/9 Общего коммюнике MASAK (последовательность № 19). Liveness и безопасность: Сессия должна быть онлайн и в реальном времени; видеоверификация должна использовать защищённую сквозную связь для предотвращения дипфейков и атак представления. Точность биометрии: Алгоритм сравнения лиц должен иметь документированный показатель False Acceptance Rate (FAR) менее 1 на 10 000 000. Сертификация TSE: Соответствие FAR 1/10 000 000 должно подтверждаться отчётом Турецкого института стандартов (TSE), если только поставщик биометрии не имеет эквивалентной международной аккредитации. Риск и бремя доказывания: Клиенты, onboarded через удалённую идентификацию, должны подпадать под дифференцированный, усиленный профиль риска; при спорах бремя доказывания того, что транзактирующая сторона была корректно идентифицирована, лежит на CASP.

Для ончейн-идентичности и SSI: любые верифицируемые учётные данные, используемые для KYC в Турции, должны выдаваться через процесс, соответствующий или превышающий этот стандарт FAR. Учётные данные, выпущенные при верификации ниже стандарта, вряд ли будут приняты регулируемыми CASP.

3.2 Правило Travel Rule MASAK и дизайн, совместимый с ZKP

Обновлённое руководство MASAK для провайдеров услуг по криптоактивам (KVHS) закрепляет правило FATF Travel Rule (Seyahat Kuralı): верифицированная информация об идентичности должна «путешествовать» вместе с переводом выше порога, делая транзакцию прозрачной для властей.

Порог: При переводах от 15 000 TL и выше данные отправителя и получателя должны включаться в сообщения между институтами. Отправитель: Полное имя, фамилия (или торговое наименование), адрес кошелька и уникальный идентификатор (например, номер турецкого удостоверения, паспорт или полный адрес). Идентичность должна быть верифицирована CASP-отправителем до перевода. Получатель: Полное имя, фамилия, адрес кошелька назначения. Неполные данные: CASP-получатель должен попытаться «Tamamlatma» (дозаполнение); если данные получить невозможно, перевод должен быть отклонён и средства возвращены. Кастодиальное хранение: Когда 100% активов клиента хранятся отдельным кастодианом, обязанности по Travel Rule переходят на кастодиана; кастодиан должен хранить лежащие в основе KYC-данные.

ZKP и Travel Rule: MASAK требует передачи и доступности данных об идентичности между обязательными лицами. Классическое соответствие часто передаёт открытый текст через централизованные API вместе с ончейн-транзакцией, создавая концентрационный риск и экспозицию по KVKK. Используя DID и доказательства с нулевым разглашением, CASP может передавать криптографический коммитмент идентичности пользователя — верифицируемый CASP-получателем по реестру или доверенному эмитенту — без рассылки открытого текста по сетям обмена сообщениями. Любой дизайн ZKP для турецкого рынка должен при этом допускать: по законному целевому запросу от MASAK или суда CASP должен иметь возможность собрать и представить лежащие в основе данные идентичности в открытом виде, связанные с доказательством. Система ZKP, навсегда разрывающая связь с идентичностью в реальном мире, противоречила бы обязанностям MASAK по мониторингу и ведению записей и создавала бы риск санкций.

3.3 Соответствие Турции eIDAS 2.0 и европейской цифровой идентичности

Турция и eIDAS 2.0: Турция не связана регламентом ЕС eIDAS 2.0, но Управление цифровой трансформации и национальная инфраструктура выровнены с европейской интероперабельностью для поддержки трансграничной цифровой торговли. Разработка по стандартам европейской цифровой идентичности рассчитана на перспективу для систем ZKP и верифицируемых учётных данных.

eIDAS 2.0 ЕС (в силу с мая 2024 г.) вводит Кошелёк цифровой идентичности ЕС (EUDI Wallet): граждане хранят верифицируемые учётные данные на устройстве и передают их с минимальным раскрытием и ZKP, сохраняя контроль. Крупнейшие онлайн-платформы и ключевые сервисы должны принимать кошелёк EUDI для аутентификации. Турецкий e-Devlet уже выступает централизованным поставщиком идентичности с 2FA, мобильной подписью и квалифицированной электронной подписью, привязанной к биометрическому чипу турецкого удостоверения. Турецкие поставщики доверия используют стандарты ETSI, чтобы квалифицированные электронные подписи оставались на одном уровне с европейскими. Для ZKP и ончейн-идентичности: архитектуры идентичности должны проектироваться с открытыми API и моделями учётных данных, способными к интероперации с экосистемой EUDI; иначе им грозит устаревание по мере сближения турецких систем с рамкой ЕС.

4. Распределение ролей: контролёр и обработчик данных по KVKK

Кто контролирует: По KVKK то, кто является контролёром или обработчиком, определяется тем, кто определяет цель и средства обработки (и кто имеет фактический или нормативный контроль), а не тем, кто эксплуатирует серверы. Решение Kurul 2020/71 резюмирует это в терминах того, кто решает о типах данных, методе сбора, хранении и доступе.

В схемах эмитент — верификатор — держатель эмитенты обычно являются контролёрами, когда собирают данные и выпускают учётные данные для идентичности/KYC/сертификации; верификаторы часто выступают отдельными контролёрами, когда верифицируют и принимают решения (например, онбординг, доступ, проверка возраста). Держатель обычно является субъектом данных; если оператор кошелька или приложения собирает телеметрию, идентификаторы устройства, IP или сигналы мошенничества, этот оператор может быть отдельным контролёром в отношении такой обработки.

В схемах офчейн KYC + ончейн-доказательство/статус важно то, кто управляет контрактом статуса или отзыва: если эмитент (или консорциум) решает, какой ключ обновляет реестр, какие события записывают «отозван/действителен» и какой идентификатор попадает в ончейн, роль этой стороны как контролёра на ончейн-слое усиливается. Когда ончейн-слой обслуживает несколько организаций (например, общий список отзыва или статуса) и они разделяют контроль и выгоду, подход Kurul к совместному контролю (как в решении о «чёрном списке») может применяться: первичные сборщики, те, кто использует и имеет доступ к данным, и ПО/инфраструктура, обеспечивающая обмен, могут оцениваться вместе.

Протоколы или сети, которые «фактически не собирают сырые данные», не избегают ответственности автоматически. Анализ Kurul совместного контроля подчёркивает контроль и выгоду: кто решает, что записывается, кто может изменить или удалить это, кто имеет доминирование и коммерческий интерес к данным. Если управление протоколом определяет маркеры идентичности (например, маркеры SBT, глобальные списки отзыва), что записывается в ончейн, правила доступа и стандартные потоки и извлекает экономическую или институциональную выгоду, в зависимости от конкретной настройки может быть обоснован совместный контроль по крайней мере в части операций обработки.

Роли узлов/валидаторов в KVKK явно не определены. Европейские органы подчёркивают, что роли должны определяться на этапе проектирования и что разные архитектуры дают разные роли; французский орган по защите данных (CNIL) обсуждал разработчиков смарт-контрактов и в ряде случаев майнеров как обработчиков, когда они выполняют техническую верификацию инструкций. Такой функциональный подход согласуется с фокусом KVKK на контроле над целью и средствами.

5. Технические стандарты для соответствия и аудита

Какие стандарты важны: Турецкие регуляторы и аудиторы оценивают «адекватную безопасность» и «надлежащую верификацию» по признанным стандартам, а не по произвольному коду. Сопоставление вашей системы ZKP или цифровой идентичности с названными стандартами (ISO 27001, биометрия TSE, ETSI, W3C VC) усиливает проверяемость и нарративы соответствия.

• ISO/IEC 27001: Базовый уровень для контролёров данных в Турции. Kurul рассматривает действующий независимо проверенный сертификат ISO 27001 как сильный индикатор наличия технических и организационных мер по ст. 12 KVKK. Для CASP и проектов блокчейн-идентичности ISO 27001 охватывает ключевой жизненный цикл, контроль доступа и логирование.

• Сертификация биометрии TSE: По Коммюнике SPK III-42.1.a (2026) удалённая идентификация на основе ИИ должна соответствовать показателю False Acceptance Rate менее 1 на 10 000 000, подтверждённому отчётом TSE (или эквивалентной международной аккредитацией). Это задаёт минимальный уровень уверенности для учётных данных, используемых в регулируемых финансах Турции.

• ETSI (соответствие eIDAS): ETSI EN 319 401 (общая политика для поставщиков доверительных услуг) и ETSI TS 119 461 (доказательство идентичности и онбординг) используются для демонстрации того, что цифровой онбординг имеет эквивалентный правовой вес личной верификации и соответствует eIDAS 2.0.

• Модель данных верифицируемых учётных данных W3C: Пока не упоминается в первичном законодательстве Турции, но де-факто основа для кошелька EUDI и интероперабельного SSI. Использование модели W3C VC поддерживает документированную минимизацию данных и ограничение цели и сохраняет совместимость турецких систем с глобальными разработками SSI и ZKP.

6. Удаление, анонимизация и неизменяемый реестр

Удаление и цепь: Ст. 7 KVKK требует удаления, уничтожения или анонимизации персональных данных при прекращении оснований для обработки; Регламент вновь определяет анонимизацию по стандарту «даже в сочетании с другими данными». Руководство Kurul связывает гарантию анонимизации с рисками повторной идентификации и объединения наборов данных и с обязанностью контролёра учитывать, могут ли получатели или публичные данные нарушить анонимность.

6.1 Инциденты безопасности и уведомление в течение 72 часов

Правило 72 часов: По KVKK «инцидент безопасности» включает несанкционированный доступ к криптографическим ключам или соли, даже если основная база данных не была затронута. Уведомление Kurul и субъектов данных должно быть направлено в течение 72 часов с момента, когда контролёр узнал о нарушении (решение Kurul 2019/10).

Руководство Kurul по безопасности персональных данных указывает, что ключи должны храниться отдельно от зашифрованных данных. При компрометации ключей или соли — или при раскрытии закрытого ключа, обеспечивающего ончейн-коммитмент ZKP — псевдонимизированные данные считаются находящимися под угрозой и подлежат регистрируемому инциденту. Для CASP и платформ цифровой идентичности: компрометация среды горячего кошелька, где админ-ключи связаны с идентичностями пользователей или KYC-данными, или нарушение централизованной базы сопоставления DID–идентичность требует немедленного расследования и детального уведомления о нарушении в Kurul (затронутые записи, риски и меры по смягчению). Если нарушение произошло у обработчика (например, внешнего KYC или облачного провайдера), он должен без задержки уведомить турецкого контролёра данных, чтобы контролёр мог соблюсти срок 72 часов.

Два уровня противоречия с неизменяемыми реестрами: (1) Технический: После записи запись не может быть односторонне удалена; EDPB отмечает отсутствие механизма удаления по умолчанию и необходимость учёта соответствия персональным данным при проектировании. (2) Правовой: Турецкое право не кодифицирует «техническую невозможность» как общее исключение из ст. 7; если конструкция не допускает удаления или анонимизации, ончейн-слой создаёт структурный риск несоответствия.

Три практические стратегии (ни одна из которых не является «автоматической анонимизацией»):

1. Не записывать персональные данные в ончейн: Использовать цепь только для доказательства существования (коммитмент, указатель, ключевой хеш) и хранить данные верификации офчейн. EDPB поддерживает ограничение ончейн-содержимого доказательством/указателем/коммитментом и хранение данных верификации офчейн. Это позволяет удаление в центральной системе, но связуемость того, что остаётся в ончейне, по-прежнему должна оцениваться.

2. Шифрование и управление ключами: EDPB указывает, что зашифрованные персональные данные остаются персональными данными и шифрование не снимает обязанность соответствия; также отмечено, что криптография может ослабнуть со временем при бессрочном хранении цепи. По турецкому праву истинная анонимизация требует необратимости; одного шифрования при существовании ключей недостаточно. Является ли уничтожение ключей «уничтожением» или «анонимизацией», зависит от конкретной модели угроз (невосстановимость ключей, резервные копии, процедуры HSM) и подхода Kurul.

3. Подсоленный/ключевой хеш плюс уничтожение соли/ключа: EDPB указывает, что даже при наличии подсоленных/ключевых хешей в ончейне хеш может быть персональными данными; также отмечено, что при уничтожении соли/ключа хеш может стать несвязуемым в зависимости от алгоритма, выбора соли и утечки ключа. Это может снизить связуемость, но критерий KVKK «даже в сочетании с другими наборами данных» означает, что долгосрочный риск в публичных цепях (новые побочные данные, более совершенный анализ) должен учитываться.

7. Трансграничная передача и публичные блокчейны

Трансграничная передача на практике: Закон № 7499 переработал ст. 9 KVKK так, что трансграничная передача выровнена с GDPR. Передача опирается на адекватность, Типовые договорные положения (SCC) — с цифровым уведомлением Kurul в течение 5 рабочих дней с момента подписания — или иные гарантии. Kurul применяет принцип эффекта: платформы, нацеленные на Турцию, подпадают под KVKK независимо от места учреждения. Для публичных беспермиссионных блокчейнов подписание SCC с тысячами анонимных валидаторов невозможно; персональные данные (сырые, хешированные или обратимо зашифрованные) не должны записываться в публичную цепь. В ончейн должны якориться только необратимые математические артефакты (хеши с уничтоженными ключами, DID, корни Merkle, ZKP), чтобы не запускать трансграничную передачу персональных данных.

Три уровня по обновлённой ст. 9: (1) Адекватность — свободная передача в страны или секторы, объявленные Kurul адекватными (пересмотр в многолетнем цикле). (2) Надлежащие гарантии — SCC или обязательные корпоративные правила, одобренные Kurul; о подписании SCC необходимо уведомить Kurul в течение 5 рабочих дней (несоблюдение может повлечь штрафы от 90 000 TL до 1,8 млн TL). (3) Исключительные передачи — например, согласие или исполнение договора; Kurul рассматривает «исключительное» как единичное, а не систематическое. CASP или платформа идентичности, регулярно передающая KYC-данные на зарубежные серверы или зарубежному поставщику ИИ, должна использовать уровень 2, а не уровень 3.

8. Штрафы и принуждение по KVKK (2026)

Штрафы 2026 г.: По ст. 18 KVKK Kurul налагает административные штрафы, пересматриваемые ежегодно. В 2026 г. максимальные штрафы за нарушения безопасности данных достигают 17 092 242 TL; пропуск 5-дневного уведомления по SCC может повлечь до 1,8 млн TL. Умышленное или системное неправомерное обращение с персональными данными может также повлечь уголовную ответственность по ст. 135–140 Турецкого уголовного кодекса (TCK).

Непредоставление информации (уведомление о конфиденциальности): В 2026 г. минимум 85 437 TL, максимум 1 709 200 TL. Для проектов ZKP и идентичности важно разъяснять в уведомлениях обработку в блокчейне, неизменяемой среде и хеширование. Ненадлежащее обеспечение безопасности данных: Минимум 256 357 TL, максимум 17 092 242 TL. Ключевые области риска — управление ключами, доступ к KYC-базе, утечки метаданных смарт-контрактов и тестирование на проникновение. Нерегистрация в VERBIS: Минимум 341 809 TL, максимум 17 092 242 TL. Техплатформы, услуги токенизации и CASP должны регистрировать обработку в Реестре контролёров данных. Нарушение уведомления о трансграничной передаче (SCC): Kurul необходимо уведомить в течение 5 рабочих дней с момента подписания SCC; за нарушение — минимум 90 000 TL, максимум 1 800 000 TL.

Для CASP и провайдеров цифровой идентичности, обрабатывающих биометрию и финансовые данные, одно серьёзное нарушение может повлечь верхнюю границу этих диапазонов и регуляторную проверку. Затраты на внедрение дизайна с сохранением приватности (включая ZKP), как правило, ниже затрат на несоответствие.

9. Защитимая правовая позиция и уровни риска

Защитимая позиция: По KVKK защитимая общая позиция такова: Даже при отсутствии хранения сырых персональных данных в ончейне ончейн-связи адресов, записи о статусе, хеши/коммитменты или выходные данные криптографических доказательств могут быть персональными данными, если приводят к определённому или определяемому физическому лицу в сочетании с другими данными; роли контролёра/обработчика определяются тем, кто фактически или нормативно контролирует цель и средства обработки этих результатов.

Красные линии и управляемые риски следует проводить по (i) связуемости, (ii) публичности и постоянству, (iii) возможным данным специальных категорий, (iv) соответствию удалению/анонимизации, (v) ясности ролей — а не по названию технического компонента.

• Конструкции у красной линии часто включают: запись биометрических шаблонов или сырого биометрического вывода (или маркера, выделяющего биометрическое совпадение) в ончейн или раскрытие через постоянный ончейн-статус; превращение биометрической верификации в условие услуги при наличии альтернатив; построение долгосрочных графов идентичности/репутации с публичными нетранспортируемыми маркерами (в стиле SBT); оставление неподсоленных/неключевых хешей как ссылок на идентичность в ончейне; или глобальные списки отзыва/статуса, позволяющие отслеживание по ID учётных данных или адресу.

• Конструкции с управляемым риском обычно закладывают технические меры как принципы проектирования: биометрический ввод обрабатывается на устройстве без доступа оператора к шаблонам; держатель доказывает только необходимый атрибут рандомизированным ZKP, так что связь разрывается при каждой верификации; парные идентификаторы, так что одно лицо использует разные адреса/DID по разным сервисам; ончейн ограничен коммитментом/ключевым хешом при хранении данных верификации в контролируемой офчейн-системе; для специальных категорий — полное применение «адекватных мер» Kurul (криптография, разделение ключей, логирование, 2FA и т.д.).

10. Открытые неопределённости

• Псевдонимизация: KVKK явно не определяет «псевдонимизированные данные»; использование Kurul материалов и доктрины ЕС поддерживает трактовку как категории снижения риска, которая часто остаётся персональными данными, особенно в публичных цепях, где «неидентифицированные получатели» затрудняют ограничение теста «даже в сочетании».

• Только адрес кошелька: Является ли адрес персональными данными «сам по себе», в Турции окончательно не решено; EDPB использует контекстный тест (разумные средства идентификации). При отсутствии чёткого прецедента Kurul по адресам в блокчейне более безопасное предположение — что адреса на практике часто связуемы через KYC, устройство/IP или анализ транзакций и должны рассматриваться как риск персональных данных по умолчанию.

• Уничтожение ключа = удаление/анонимизация: EDPB признаёт, что уничтожение ключей может сделать зашифрованные данные нечитаемыми, но подчёркивает, что зашифрованные данные остаются персональными данными и криптография может деградировать со временем. По KVKK анонимизация зависит от необратимости; уничтожение ключей должно быть подлинно необратимым в конкретной настройке, и риск следует переоценивать периодически.

• Роли протокола/DAO/узла/валидатора: Как классифицировать их по KVKK, по-прежнему обсуждается даже в ЕС. EDPB ожидает анализ ролей на этапе проектирования; CNIL обсуждал майнеров/валидаторов как обработчиков в ряде случаев, но признаёт сложности принуждения. Широкое толкование Kurul совместного контроля (например, общий чёрный список) может ослабить голословную защиту «протокол не собирает данные».

11. Три способа сформулировать вывод

В зависимости от аудитории и аппетита к риску Genesis Hukuk формулирует результат следующим образом:

• Клиентоориентированная (агрессивная): «С ZKP и офчейн-хранением мы не храним сырые персональные данные в ончейне; ончейн-записи — исключительно криптографические индикаторы статуса, и мы не храним дополнительных данных, которые позволили бы определить идентичность, поэтому риск обработки персональных данных по KVKK в значительной степени смягчён».

• Сбалансированная (защитимая): «Отсутствие сырых данных в ончейне само по себе недостаточно; ончейн-адрес/статус/выходные данные доказательства могут быть персональными данными в сочетании с другими данными; поэтому роли должны назначаться по контролю и выгоде, а архитектура должна систематически разрывать связуемость (рандомизированные доказательства, парные идентификаторы, офчейн-хранение, минимальное ончейн-доказательство)».

• Строгая (для регулятора): «Ончейн-адрес, запись о статусе, хеш/коммитмент или выходные данные доказательства являются персональными данными по KVKK, когда любой субъект может связать их с определённым или определяемым физическим лицом разумными средствами; поэтому персональные данные не должны записываться в публичные или неизменяемые цепи, специальные категории (включая биометрию) должны обрабатываться только офчейн с соразмерностью, свободным согласием и адекватными мерами Kurul, а жизненный цикл должен быть спроектирован с учётом удаления по ст. 7».

13. Чем может помочь Genesis Hukuk

Genesis Hukuk — студия Law + Tech, сфокусированная на соответствии по замыслу везде, где используются блокчейн и токенизация. Мы сочетаем правовой анализ с технической архитектурой, чтобы ZKP, ончейн-идентичность и токенизация с самого начала строились на защитимой основе KVKK и регуляторных требованиях.

• Zero Knowledge Banking: Privacy, Security, Legal Compliance — KYC/AML, конфиденциальность данных и ZK в финансах; токенизация RWA и консалтинг в финтехе.

• Digital Identity & DID Tokenization Legal Services — SSI, DID, верифицируемые учётные данные, NFT и токенизация; соответствие KVKK, SPK, HMK и рамкам цифровой идентичности.

• Real World Asset (RWA) Tokenization in Turkey — Полная правовая поддержка токенизации реальных активов и связанного лицензирования в Турции.

• Smart Contract Analysis & Auditing — Анализ и аудит контрактов под турецкий рынок, включая логику идентичности и соответствия.

Для технической и правовой оценки вашего дизайна ZKP или ончейн-идентичности по турецкому праву обращайтесь в Genesis Hukuk: info@genesishukuk.com | genesishukuk.com

14. Дополнительные материалы

• Zero-Knowledge Proof: Banking's KVKK & BDDK Solution — ZKP в турецком банкинге, конфиденциальность данных и соответствие регуляторам.

• The Legal Transformation of Digital Identity and Asset Management: Smart Accounts, AI, eIDAS 2.0, and DePIN — SSI, абстракция аккаунтов и цифровая идентичность в праве.

• A Framework for Legally Compliant Smart Contracts: Compliance by Design — MiCA, рикардианские контракты и ZKP в дизайне смарт-контрактов.

• Security Tokenization in Turkey with ERC-3643 Standard — RWA и токенизация ценных бумаг в Турции.

• Crypto Asset Regulation and Compliance Guide in Türkiye — SPK, MASAK, Travel Rule и верификация цифровой идентичности (2025–2026).

Ссылки и дальнейшее чтение

• Решение Kurul 2023/570 (11 апреля 2023 г.), кратко: kvkk.gov.tr

• KVKK (Закон № 6698); Регламент об удалении, уничтожении и анонимизации персональных данных

• Коммюнике SPK III-42.1.a (изменения февр. 2026) — удалённая идентификация и CASP

• Руководство MASAK для провайдеров услуг по криптоактивам (KVHS), обновление 2025 — Travel Rule (Seyahat Kuralı)

• Закон № 5549 — противодействие отмыванию доходов

• Закон № 7499 — изменения в ст. 9 KVKK (трансграничная передача)

• Решение Kurul 2019/10 — уведомление об утечке в течение 72 часов

• Руководство Kurul по безопасности персональных данных; руководство Kurul по трансграничной передаче

• Проект руководства EDPB по блокчейну (2025); eIDAS 2.0 (регламент ЕС, май 2024)

• ISO/IEC 27001; ETSI EN 319 401, ETSI TS 119 461; Модель данных верифицируемых учётных данных W3C