Цифровой кодекс РК: что изменилось для цифровой идентификации

Клиент ввёл ИИН, получил SMS-код и подтвердил операцию селфи. Если назвать весь этот маршрут «идентификацией», при споре окажется непонятно, какой именно факт доказан каждым событием. Цифровой кодекс Республики Казахстан устраняет эту путаницу на уровне закона: идентификатор связывает запись с субъектом, аутентификация подтверждает личность при доступе, а цифровое подтверждение фиксирует волеизъявление после аутентификации. Биометрия при этом является одним из способов аутентификации, а не универсальной заменой подписи.

Цифровой кодекс принят 9 января 2026 года и, согласно статье 106, введён в действие по истечении шести месяцев после первого официального опубликования. Поэтому к сентябрю 2026 года бизнесу уже недостаточно добавить в политику новый термин: требуется разнести события в архитектуре и журнале доказательств.

Коротко

• ИИН или БИН идентифицирует запись, но знание номера не подтверждает личность пользователя.

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

• SMS-код, push или биометрическое подтверждение выражают действие после аутентификации, но не становятся от этого ЭЦП.

• Обязательная биометрия допустима только в случаях, установленных законами.

• Для финансовых и платёжных организаций порядок биометрической аутентификации конкретизируют отраслевые регуляторы.

Кодекс разделил четыре результата одного пользовательского пути

Статья 45 Цифрового кодекса называет ИИН уникальным идентификатором физического лица, а БИН — юридического лица. Идентификатор отвечает на вопрос «к какой записи относится событие». Он не доказывает, кто ввёл номер и имеет ли этот человек право действовать от имени субъекта.

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

Статья 47 вводит цифровое подтверждение — волеизъявление после аутентификации. Код, пароль, одноразовый идентификатор, push и биометрическое подтверждение могут применяться в случаях, установленных законом, или по соглашению сторон. Но пункт 4 прямо отделяет такое подтверждение от ЭЦП: оно не обеспечивает достоверность и неизменность содержания цифровой записи так, как это делает электронная цифровая подпись.

Статья 48 регулирует биометрическую аутентификацию. Биометрические данные признаются персональными данными; обязательная обработка допускается только на основании закона. Для государственных процессов предусмотрена национальная система биометрической аутентификации, а для финансовых и платёжных организаций порядок определяют АРРФР и Национальный Банк.

Почему одного Face Match недостаточно

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

Практическая модель состоит из пяти независимых проверок:

Liveness Biometric.Vision проверяет признаки живого присутствия, а не юридическую личность. Оркестратор может связать результаты документа, живости и сравнения лиц в один процесс, но правовое основание, формулировку действия и правила финального решения определяет сама организация.

Многофакторность нужно доказывать, а не декларировать

Два последовательных экрана ещё не образуют два независимых фактора. Если SMS и восстановление доступа зависят от одного скомпрометированного телефона, второй шаг может не компенсировать захват первого. Аналогично селфи, загруженное из галереи без контроля живости, добавляет изображение, но не сильный фактор присутствия.

Для каждого фактора полезно зафиксировать три свойства:

• Независимость: компрометация одного фактора не должна автоматически раскрывать второй.

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

• Свежесть: доказательство должно относиться к нужной сессии и временному окну, а не переиспользоваться без контроля.

Это редакционная и инженерная рекомендация, а не дословная норма статьи 46. Она нужна, чтобы обещание «многофакторная аутентификация» можно было подтвердить данными системы.

Автоматическое решение требует маршрута пересмотра

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

Для eKYC это меняет проектирование отказа. Статус face_mismatch или liveness_failed не должен бесследно превращаться в окончательное «клиенту отказано». Система должна сохранить причину, версию правила, входные доказательства и допустимый маршрут повторной или ручной проверки. При этом хранить полное селфи бесконечно «на всякий случай» тоже нельзя: срок и состав хранения должны следовать правовому основанию и цели обработки.

Что изменить в системе и документах

Начать стоит не с замены названий экранов, а с карты событий:

• отделить по смыслу Кодекса идентификатор пользователя от доказательства источника идентичности;

• присваивать отдельные результаты проверке документа, liveness и Face Match;

• связывать подтверждение с текстом и версией конкретного действия;

• сохранять время, сессию, версию SDK, порог и причину автоматического решения;

• определить fallback для пользователя, который не может пройти цифровую идентификацию: статья 41 допускает иной законный способ, если цифровая идентификация недоступна;

• проверить специальные требования отрасли до включения обязательной биометрии.

Biometric.Vision не определяет юридическую силу пользовательского действия и не заменяет национальную систему биометрической аутентификации. Его роль — дать технические результаты и связать их в управляемый процесс. Для проектирования такого процесса можно использовать Orchestrator, сохраняя в правилах отдельные статусы для источника данных, живости, сходства, подтверждения и ручного решения.

Итоговая проверка проста: если из журнала нельзя независимо ответить «кого обозначает запись», «кто управлял сессией», «что именно подтвердил пользователь» и «почему принято решение», переход на новую терминологию не состоялся. Цифровой кодекс сделал эти вопросы юридически различимыми; архитектуре осталось сделать их воспроизводимыми.

Источники

• Цифровой кодекс Республики Казахстан № 255-VIII, статьи 41, 43–49 и 106.

• Закон РК «О персональных данных и их защите».