MyID в Узбекистане: как работает идентификация для бизнеса

Успешный ответ MyID подтверждает, что человек прошёл предусмотренную биометрическую процедуру и его данные сопоставлены с государственными источниками. Но он не отвечает за бизнес на три других вопроса: можно ли открыть именно этот продукт, соответствует ли клиент риск-политике и какое действие он затем подтвердил. Если сохранить только статус success, при споре эти решения окажутся смешаны.

MyID — система биометрической идентификации UZINFOCOM. По официальному описанию она использует распознавание лица и проверку живости, получает биографические и биометрические сведения из государственных информационных систем и применяется в банках, платёжных сервисах, страховании, связи и других отраслях. Для компании это доверенный слой проверки личности, но не готовое решение всего KYC.

Коротко

• MyID связывает предъявителя с данными государственных источников через биометрическую процедуру.

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

• Интеграция может использовать App, Mobile SDK, Web SDK, Server SDK или Cloud в зависимости от официально доступного сценария.

• Успешная идентификация не заменяет AML-проверку, оценку продукта и антифрод.

• Для аудита нужно сохранять идентификатор сессии, состав переданных данных, результат и правило финального решения.

Какие факты может подтвердить MyID

Официальная страница описывает MyID как систему идентификации и аутентификации физических лиц по уникальным биометрическим параметрам лица. Основные данные поступают из информационных систем Центра персонализации и Министерства внутренних дел. В политике конфиденциальности перечислены, в частности, цифровой фотопортрет, персональный идентификационный номер физического лица (ПИНФЛ), реквизиты паспорта или ID-карты, срок действия, ФИО, гражданство и сведения о регистрации.

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

Пять событий вместо одного статуса

1. Компания создаёт идентификационную сессию

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

2. Пользователь видит, кому и какие данные передаются

Согласие — не декоративная галочка. В журнале полезно хранить версию текста, получателя, перечень полей, дату и способ выражения согласия. Это рекомендуемая evidence-модель; конкретный состав документа определяется применимым законодательством и договорной схемой.

3. MyID проверяет предъявителя и возвращает результат

Внутри сервиса используются биометрическое сравнение и liveness. Бизнес должен получить машинно проверяемый ответ, связанный с той же сессией, а не скриншот экрана клиента. Необходимо различать техническую ошибку, отказ пользователя, неуспешную биометрию и успешное подтверждение.

4. Компания выполняет собственные проверки

Для банка или платёжного сервиса остаются надлежащая проверка клиента, санкционные и PEP-проверки, оценка мошеннических признаков, допустимость продукта и лимиты. MyID подтверждает личность, но не определяет источник средств и не разрешает совпадение со списком.

5. Правило принимает и объясняет решение

Финальный статус должен ссылаться на входные результаты: myid_verified, screening_reviewed, risk_approved. Единый KYC passed скрывает, что именно было проверено и какой компонент вызвал отказ.

Что остаётся ответственностью бизнеса

Такое разделение предотвращает две противоположные ошибки. Первая — считать MyID простой камерой и повторно собирать уже подтверждённые сведения. Вторая — считать положительный ответ разрешением на любую услугу.

Где появляется дополнительная биометрия

Если компания использует собственный захват документа или отдельный риск-сценарий, ей могут понадобиться Document Verification, Face Match или повторный liveness. Но дублировать проверку без причины не следует: каждый дополнительный биометрический шаг увеличивает трение и объём обработки данных.

Полезный критерий — новый вопрос. Если MyID уже подтвердил личность, дополнительный Face Match оправдан, когда нужно связать другое изображение или новую высокорисковую сессию с эталоном. Если вопрос тот же, следует сначала проверить, нельзя ли использовать существующий результат и его свежесть.

Orchestrator Biometric.Vision может объединить внешнее подтверждение личности, проверку документа, Face Match, liveness и AML-сигналы в один маршрут. Biometric.Vision не является оператором MyID и не заявляет на продуктовой странице готовое подключение к государственному контуру Узбекистана; интеграция с MyID выполняется по его официальным условиям.

Минимальный журнал интеграции

Для каждой попытки стоит сохранять:

• внутренний и внешний идентификаторы сессии;

• время создания, завершения и истечения;

• версию согласия и переданный набор полей;

• тип канала и версию интеграции;

• результат MyID с кодом ошибки без подмены его общим fail;

• результаты последующих AML- и антифрод-проверок;

• версию правила, финальное решение и ответственную роль;

• маршрут повторной или ручной проверки.

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

MyID сокращает расстояние между государственными данными и цифровой услугой. Экспертная интеграция использует это преимущество, не перекладывая на один ответ решения, которых сервис не принимает: риск клиента, допустимость продукта и доказательство конкретного волеизъявления.

Источники

• MyID: политика конфиденциальности и состав данных.

• MyID: политика конфиденциальности.

• MyID: пользовательское соглашение.

• Центральный банк Узбекистана: Положение о порядке цифровой идентификации клиентов.