For the complete documentation index, see llms.txt. This page is also available as Markdown.

Сервис управления согласиями (СУС)

Сервис управления согласиями (СУС) - инфраструктурный сервис Национальной цифровой финансовой инфраструктуры (НЦФИ) для регистрации, хранения и учёта согласий клиентов на сбор, обработку и передачу данных при оказании финансовых и платёжных цифровых услуг.

СУС создан на базе Центра обмена идентификационными данными (ЦОИД) в соответствии с требованиями к обязательной регистрации согласий клиентов, установленными изменениями в Закон РК «О платежах и платёжных системах» и Постановление Правления НБРК №212 от 31.08.2016.

Роли

  • Клиент - просматривает согласия и инициирует их отзыв через ЛК ЦОИД и (или) приложение Участника.

  • Участники (банк, МФО, платёжная организация и др.) - получает согласие клиента и регистрирует его в СУС, рассматривает запросы на отзыв в течение 15 календарных дней.

  • СУС - регистрирует согласия, хранит согласия и их статусы, фиксирует отзыв, проверяет статус согласия. СУС не проверяет договорные обязательства и не оценивает правомерность обработки данных Участником.

  • ЦОИД - предоставляет клиенту интерфейс ЛК ЦОИД, передаёт согласия и запросы на отзыв в СУС.

СУС - единственный источник актуального статуса согласия. Участники обязаны синхронизировать статусы в своих системах на основании ответов СУС.

Код
Согласие
Обязателен для

CT_01

Сбор, обработка и хранение персональных данных, включая биометрических

Всех услуг

CT_02

Биометрическая аутентификация с использованием ЦОИД

Всех услуг

CT_03

Получение услуги в электронном формате

ESIGN_ISSUANCE

CT_04

Передача и обработка банковских данных (банковская тайна)

OB_SERVICE

Реестр услуг

Согласие не может быть зарегистрировано в СУС без service_code, существующего в Едином реестре услуг.

service_code
Услуга
Обязательный состав consent_types

ACCOUNT_OPEN

Открытие банковского счёта

CT_01, CT_02

CLIENT_REG

Регистрация в системе

CT_01, CT_02

CLIENT_UPD

Изменение данных существующего клиента

CT_01, CT_02

LOAN_ISSUE

Выдача займа

CT_01, CT_02

AML_UPDATE

Обновление данных (по требованию законодательства РК)

CT_01, CT_02

INTERNAL_CONTROL

Иные случаи (в рамках внутренних требований организации)

CT_01, CT_02

ESIGN_ISSUANCE

Создание ЭЦП

ESIGN_DOCUMENT

Подписание документа(-ов) с применением ЭЦП

CT_01, CT_02

OB_SERVICE

Доступ к информации о банковских счетах

CT_01, CT_02, CT_04

Обязательные поля согласия: consent_id, service_code, iin, consent_types, participant_bin, data_scope, consent_channel, consent_given_at, consent_expires_at, consent_status, data_retention_period.

Данные согласия не редактируются после регистрации - допускается только изменение статуса.

Каналы получения согласия

Канал определяется не услугой, а тем, какой сервис ЦОИД используется в конкретном процессе. Регистрация в СУС происходит только при успешном завершении операции - неуспешные сценарии не фиксируются.

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

COID

ЦОИД (на своей странице)

ЦОИД

Клиент перенаправляется в OAuth-флоу ЦОИД (generateUserUrl)

PARTICIPANT

Участник (в своём интерфейсе)

Участник

Участник сам проводит верификацию и передаёт согласие (фотосопоставление v2)

PARTICIPANT_DIRECT

Участник (в своём интерфейсе)

Участник

Данный сценарий используется только для сервис-кода ESIGN_ISSUANCE. При этом в параметре consent_types необходимо указывать CT_01 и CT_03. Значение CT_02 не указывается, так как биометрическая аутентификация при выпуске ЭЦП на стороне УЦ Участника не используется.

Канал ЦОИД (согласие формируется ЦОИД)

Применяется для услуг: ACCOUNT_OPEN, LOAN_ISSUE, CLIENT_REG, AML_UPDATE, INTERNAL_CONTROL, ESIGN_DOCUMENT, ESIGN_ISSUANCE (УЦ АО НПК), OB_SERVICE.

Схема создания согласия

Отображение согласий

В ЛК id.npck.kz клиент может:

  • просматривать все свои согласия и их статусы

  • просматривать выданные токены доступа (Open Banking)

  • инициировать отзыв согласия

Отображаются: consent_id, наименование и service_code, consent_types, участник-получатель, data_scope, дата выдачи, срок действия, статус (ACTIVE / REVOKED / EXPIRED).

Отзыв согласия

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

Код
Причина

REJ_01_ACTIVE_SERVICE

Активная услуга

REJ_02_CONTRACTUAL_OBLIGATIONS

Договорные обязательства

REJ_03_LEGISLATIVE_REQUIREMENTS

Требования законодательства

REJ_04_DATA_RETENTION_REQUIRED

Необходимость хранения данных

REJ_05_PENDING_OPERATION

Незавершённая операция

REJ_06_SECURITY_RESTRICTIONS

Ограничения по безопасности

REJ_07_OTHER

Прочее (требует текстового описания)

REJ_08_REQUEST_TIMEOUT

Участник не ответил в установленный срок

Для ESIGN_ISSUANCE через УЦ Участника ЛК ЦОИД не показывает кнопку «Отозвать» - вместо неё отображается инструкция для перехода в приложение Участника.

Схема отзыва согласия

Отображение согласий

Все согласия клиента отображаются в ЛК ЦОИД независимо от канала получения: consent_id, наименование и service_code, consent_types, участник-получатель, data_scope, дата выдачи, срок действия, статус (ACTIVE / REVOKED / EXPIRED).

Реализация просмотра и отзыва согласий в приложении банка не является обязательным требованием - остаётся на усмотрение Участника.

Срок действия согласия и срок хранения данных

Это разные параметры. Срок действия согласия (consent_expires_at) - период, в течение которого действует разрешение клиента; определяется Участником. Срок хранения данных (data_retention_period) - отдельный период, на который Участник может хранить уже полученные данные.

После истечения срока действия СУС автоматически переводит статус согласия в EXPIRED.

Как СУС встраивается в сервисы ЦОИД

С появлением СУС два сервиса ЦОИД изменились: теперь они могут регистрировать согласие автоматически в момент успешной операции - не нужно отдельно вызывать API СУС.

POST /v2/identity/sync/verify

Появилась новая версия метода синхронной верификации. Отличие от старого v1: при успешном сличении фото автоматически регистрируется согласие в СУС и в ответе возвращается consentId.

Что нужно передать дополнительно (по сравнению с v1):

Поле
Описание

serviceCode

Код услуги из реестра СУС

dataScope

Категории данных, на которые клиент даёт согласие

consentTypes

Типы согласия (CT_01, CT_02 и др.)

consentGivenAt

Момент, когда клиент подтвердил согласие на стороне Участника

consentExpiresAt

Срок действия согласия

dataRetentionPeriod

Срок хранения данных (в днях)

Канал фиксируется как PARTICIPANT - согласие получено на стороне Участника, регистрация в СУС происходит через ЦОИД автоматически после успешного сличения.

POST /v1/auth/generate-user-url

В существующий метод добавлены три новых параметра:

Поле
Обязательное
Описание

serviceCode

"Условно обязательное" (после полного перехода участников поля станут обязательными)

Код услуги из реестра СУС

consentExpiresAt

"Условно обязательное" (после полного перехода участников поля станут обязательными)

Срок действия согласия

dataRetentionPeriod

"Условно обязательное" (после полного перехода участников поля станут обязательными)

Срок хранения данных (в днях)

Если serviceCode передан - после того как клиент подтверждает согласие в OAuth-флоу, система автоматически регистрирует запись в СУС с consent_channel = COID. Если serviceCode не передан - поведение прежнее, СУС не задействуется.

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

Краткое описание методов

Метод
Эндпоинт
Описание

POST

/v1/consents

Регистрация согласия, полученного на стороне Участника (PARTICIPANT_DIRECT)

GET

/v1/consents

Список согласий участника с фильтрацией по iin и status

GET

/v1/consents/{consentId}

Получить согласие по идентификатору

PUT

/v1/consents/{consentId}/revoke

Подтвердить отзыв согласия

PUT

/v1/consents/{consentId}/revoke-reject

Отклонить запрос на отзыв с указанием причины

Last updated