¶ 1. История изменений
| Версия | Дата | Автор | Комментарий |
|---|---|---|---|
| 1.0.0 | 22.07.2020 | АФТ, Направление открытых API | Создана первая версия документа |
| 1.0.1 | 10.08.2020 | АФТ, Направление открытых API | Внесены изменения по замечаниям Банка России |
| 1.0.2 | 01.09.2020 | АФТ, Направление открытых API | Внесены изменения по замечаниям Банка России |
| 1.0.2 | 01.10.2020 | АФТ, Направление открытых API | Внесены изменения по замечаниям Банка России (Этап согласования 3) |
¶ 2. Введение
Настоящий документ содержит общие для всех Участников среды Открытых банковских интерфейсов требования к проектированию клиентского опыта (далее – Требования). Настоящие Требования созданы с целью помочь Поставщикам платежных услуг (далее – ППУ) и Сторонним поставщикам (далее – СП) наилучшим способом взаимодействовать с Пользователем в процессе предоставления финансовых услуг в рамках среды Открытых банковских интерфейсов.
¶ 2.1 Область применения
Настоящие Требования описывают подходы к проектированию клиентского опыта в части получения согласия о предоставлении информации по банковским счетам и выполнения разовых платежей в среде Открытых банковских интерфейсов.
Настоящие Требования предназначены для разработчиков информационного и программного обеспечения, взаимодействующего со средой Открытых банковских интерфейсов.
Положения настоящих Требований применяются участниками на добровольной основе, если только в отношении конкретных положений обязательность их применения не установлена нормативными актами Банка России.
По предложениям Участников среды Открытых банковских интерфейсов настоящие Требования могут дополняться ролями и сценариями, принятыми в международной практике.
¶ 2.2 Термины и определения
В настоящем документе используются сокращения и определения в соответствии с терминами Соглашения о сертификации и соблюдении Стандартов Открытых банковских интерфейсов (далее – Соглашение), если не указано иное.
Таблица 1 – термины и определения
| API (Application Programming Interface) | Набор процедур, протоколов и инструментов для создания программных приложений. API определяет, как программные компоненты должны взаимодействовать. |
| Многофакторная аутентификация Пользователя | Многофакторная аутентификация Пользователя – это аутентификация, которая основана на использовании двух или более элементов, классифицированных как знания, владение и неотъемлемость. Эти пункты являются независимыми, поскольку нарушение одного не угрожает надежности других. |
| Открытые банковские интерфейсы | Бесплатные и общедоступные интерфейсы прикладного программирования (API), которые предоставляют разработчикам программный доступ к проприетарному программному приложению. |
| Плательщик | Пользователь, осуществляющий перевод денежных средств (либо от имени которого осуществляется перевод денежных средств). |
| Пользователь | Физическое или юридическое лицо, являющееся плательщиком или получателем средств. |
| Получатель средств | Пользователь, в пользу которого осуществляется перевод денежных средств. |
| Поставщик платежных услуг (ППУ) | Кредитная организация или ее филиал, обслуживающая счет Пользователя и публикующая Отрытые банковские интерфейсы. |
| Среда Открытых банковских интерфейсов | Комплекс стандартов Открытых банковских интерфейсов, управление, системы, процессы, безопасность и процедуры, используемые для поддержки участников. |
| Стандарты Открытых банковских интерфейсов | Стандарты, содержащие принципы и рекомендации по обмену данными для осуществления взаимодействия через Открытые банковские интерфейсы, утвержденные Центральным банком Российской Федерации от 23.10.2020. |
| Стандарт ISO 20022 | Международный стандарт обмена электронными сообщениями между организациями финансовой отрасли. |
| Сторонний поставщик | Юридическое лицо, использующее Открытые банковские интерфейсы для доступа к банковскому счету Пользователя в целях предоставления информационных услуг (СПИУ) или для осуществления переводов денежных средств (платежей) (СППУ). |
| СПИУ | Юридическое лицо, предоставляющее Пользователю услугу получения информации о банковском счете (счетах) Пользователя. |
| СППУ | Юридическое лицо, предоставляющее Пользователю услугу по инициированию перевода денежных средств. |
| Участники среды Открытых банковских интерфейсов | Пользователи, банки и прочие организации, которые участвуют в создании и развитии среды Открытых банковских интерфейсов. |
| Строгая аутентификация (SCA) | Многофакторная аутентификация с использованием криптографических протоколов аутентификации (подробнее изложено в ГОСТ Р 58833–2020). |
¶ 2.3 Структура документа
Требования к проектированию клиентского опыта представлены в следующих главах документа:
- Общие требования при управлении согласием (глава 3);
- Базовые модели клиентского пути (глава 4);
- Детализация отдельных элементов пути клиента (глава 5).
Глава 3 документа приводит следующую информацию:
- раздел 3.1 – детализированные требования по предоставлению данных, связь предоставляемых согласием разрешений с кластерами данных;
- раздел 3.2 – требования к доступности данных при создании согласия;
- разделы 3.3 и 3.4 – общие требования к предоставлению и отзыву согласия соответственно.
Глава 4 документа приводит подробное описание базовых моделей клиентского пути:
- раздел 4.1 – получение согласия на доступ к счету;
- раздел 4.2 – проведение платежей.
Обозначенные разделы Главы 4 приводят диаграммы бизнес-процесса клиентского пути, описания процессов клиентского пути, а также примеры реализации интерфейсов (экранных форм) клиентского пути в соответствии с описанными бизнес-процессами.
Описание базовых моделей клиентского пути представлено в документе в табличной форме, содержащей следующие элементы:
- № – порядковый номер процесса
- Участники процесса
- Наименование процесса
- Описание процесса
Таблица 2 - Форма описания процессов клиентского пути
| № | Участник | Наименование процесса | Описание процесса |
|---|
Глава 5 документа приводит детализацию отдельных элементов клиентского пути:
- раздел 5.1 – детализация процесса получения согласия на доступ к счету;
- раздел 5.2 – детализация процесса проведения платежей в зависимости от метода аутентификации.
Дополнительные материалы, являющиеся неотъемлемой частью настоящих Требований, вынесены в приложения к документу.
¶ 3. Общие требования к управлению согласием
Настоящие Требования распространяются на процессы предоставления и авторизации согласия Пользователя, аутентификации Пользователя, отзыва согласия, управления согласиями Пользователя и удаления использованных данных, формат представления данных при управлении согласием Пользователя.
¶ 3.1 Представление данных при управлении согласием
Раздел определяет шаблоны применяемых типов взаимодействия с Пользователем, которые должны использовать Участники среды Открытых банковских интерфейсов при работе с согласием Пользователя. Также раздел описывает состав данных, который должен использоваться Участниками среды Открытых банковских интерфейсов при реализации клиентского пути.
Пример требований по представлению информации о платежной операции представлен на рисунке 1.
Рисунок 1 - Пример требований по представлению данных
Требования по представлению данных в зависимости от детализации представлены в таблице 3 и таблице 4.
Таблица 3 - Требования по представлению данных
| № | Область применения | Требования |
|---|---|---|
| 1 | Используемое представление данных | СПИУ и ППУ используют требования представления данных для описания кластеров данных и разрешений при взаимодействии с Пользователем. Требования по представлению данных применяются, когда данные Пользователя запрашиваются, обрабатываются или доступ к данным отзывается. СПИУ и ППУ используют детализированные требования по представлению данных в соответствии с Таблицей 4. СПИУ и ППУ должны расширять, где это допустимо, предлагаемые представления данных и подробно сообщать Пользователю о том, какие данные передаются. Для этого могут использоваться дополнительные подсказки в пользовательском интерфейсе, дополнительные разрешения (там, где это применимо). |
| 2 | Детализация запрашиваемой области | При необходимости, СПИУ могут объединять и изменять кластеры данных "Basic" и "Detailed" и представления разрешений, чтобы показать, что "Detailed" области включают "Basic" данные. Например: СПИУ представляет кластер "Detailed" данных в запросе данных Пользователю, но не представляет "Basic" кластер данных. Область действия "Detailed" включает "Basic" данные, но это скрыто для Пользователя. |
Таблица 4 - Детализированные требования по представлению данных
| Представление данных | Представление разрешения | Код разрешения |
|---|---|---|
| Идентификатор счета, его тип и валюта | Идентификатор ресурса счета Статус счета Валюта ведения счета Тип счета (физическое или юридическое лицо) Описание продукта, привязанного к счету |
ReadAccountsBasic |
| Номер счета и его свойства | Номер счета Статус счета Валюта ведения счета Тип счета (физическое или юридическое лицо) Описание продукта, привязанного к счету Организация, которая управляет счетом |
ReadAccountsDetail |
| Баланс счета | Идентификатор ресурса счета Сумма баланса ("кредит" (+) или "дебит" (-)) Валюта ведения счета Информация о кредитной линии или овердрафте по счету |
ReadBalances |
| Информация о платежной операции | Идентификатор ресурса счета Идентификатор транзакции Статус транзакции Сумма, валюта и дата транзакции Комиссионные сборы Информация об обмене валюты |
ReadTransactionsBasic Массив разрешений должен также включать одно из разрешений: ReadTransactionsCredits ReadTransactionsDebits |
| Детали платежной операции | Идентификатор ресурса счета Идентификатор транзакции Статус транзакции Сумма, валюта и дата транзакции Комиссионные сборы Информация об обмене валюты Детали продавца, участвующего в сделке Идентификаторы банков Плательщика и Получателя средств Средство платежа (CardInstrument) |
ReadTransactionsDetail Массив разрешений должен также включать одно из разрешений: ReadTransactionsCredits - операции начисления; ReadTransactionsDebits - операции снятия. |
| Выписка информации по счету | Идентификатор ресурса счета Идентификатор выписки Период выписки Детали платежных операций Валюта ведения счета |
ReadTransactionsBasic |
¶ 3.2 Требования к созданию согласия
Контент в пользовательских интерфейсах по получению согласия должен быть простым и доступным для понимания Пользователя. Процесс получения согласия должен быть простым и удобным для всех сторон. Чтобы сделать контент более доступным для широкого круга Пользователей, предлагается использовать "Рекомендации по обеспечению доступности веб-контента" (WCAG). WCAG обеспечивает доступность веб-контента для Пользователя на персональных компьютерах, ноутбуках, планшетах и мобильных устройствах.
Требования по представлению данных представлены в таблице 5.
Таблица 5 - Требования по представлению данных (продолжение)
| № | Область применения | Описание |
|---|---|---|
| 3 | Доступность | Как минимум, все участники среды Открытых банковских интерфейсов должны стремиться к соблюдению следующих требований к доступности при создании согласия: |
| 3.1 | Доступность: Восприимчивость контента |
СПИУ и ППУ должны стремиться к тому, чтобы все аспекты модели согласия соответствовали требованиям WCAG 1.4. Это облегчит просмотр и прослушивание контента, в том числе отдельной информации переднего плана и фона. |
| 3.2 | Доступность: Функциональность клавиатуры |
СПИУ и ППУ должны стремиться к тому, чтобы все аспекты модели согласия соответствовали требованиям WCAG 2.1. Это сделает все функции доступными с клавиатуры. |
| 3.3 | Доступность: Указатели взаимодействия |
СПИУ и ППУ должны стремиться к тому, чтобы все аспекты модели согласия соответствовали требованиям WCAG 2.5. Это облегчит работу с функциями с использованием различных устройств ввода. |
| 3.4 | Доступность: Читабельность |
СПИУ и ППУ должны стремиться к тому, чтобы все аспекты модели согласия соответствовали требованиям WCAG 3.1. Это сделает текстовый контент читабельным и понятным. |
| 3.5 | Доступность: Помощь ввода |
СПИУ и ППУ должны стремиться к тому, чтобы все аспекты модели согласия соответствовали требованиям WCAG 3.3. Это поможет Пользователям избегать ошибок и исправлять их (при появлении). |
¶ 3.3 Требования к получению согласия, аутентификации и авторизации
Требования по представлению данных представлены в таблице 6.
Таблица 6 - Требования по представлению данных (продолжение)
| № | Область применения | Последовательность действий, которые выполняет Пользователь |
|---|---|---|
| 4 | Получение согласия | СПИУ должен уведомить Пользователя о перенаправлении его в ППУ для аутентификации. |
| 5 | Аутентификация: Пароль |
ППУ и СПИУ должны указывать при взаимодействии с Пользователем, что сервисы, использующие данные, не нуждаются в доступе к паролям Пользователя для целей обмена данными. |
| 6 | Аутентификация: Ссылка на пароль |
ППУ не должен включать ссылки по типу «Забыл пароль?» на детали данных Пользователя на экранах перенаправления с целью предотвращения фишинговых атак. |
| 7 | Авторизация: Выбор счета |
ППУ должен позволять выбирать Пользователю счет для доступа к данным, если запрос включает в себя данные, относящиеся к определенному счету, или доступно несколько счетов. В случае отсутствия запрашиваемых данных, относящихся к представленному счету, ППУ может пропустить этот шаг. ППУ может добавить шаг «Выбора профиля» или аналогичный до шага выбора счета, если Пользователь имеет доступ к различным счетам. Например, один Пользователь (например, являясь головной компанией группы компаний) может предоставлять доступ к счетам своих клиентов. Шаг «Выбор профиля» следует добавлять в уже существующий клиентский путь, и он должен быть минимальным, чтобы избежать случаи необоснованного взаимодействия (например, рекламирования о других услугах, не относящихся к непосредственному согласию Пользователя). Если определенные счета недоступны для совместного использования, ППУ должен отображать эти недоступные счета на этапе выбора счета. ППУ должен сообщить, почему эти счета не могут быть выбраны в виде оперативной справки или как модальное окно (чтобы уменьшить содержание лишней информации на экране). ППУ может предоставить инструкции о том, как сделать эти счета доступными для совместного использования в виде встроенных подсказок или как модальное окно (чтобы уменьшить содержание лишней информации на экране). ППУ не следует отображать недоступные совместные счета до того, как будет предоставлено разрешение для их отображения в потоке авторизации (механизм управления совместными счетами осуществляется ППУ). |
| 8 | Авторизация: Подтверждение счета |
ППУ должен отображать, с каких счетов передаются данные до подтверждения авторизации, если запрос данных включает дополнительные данные о счете. ППУ может пропустить эту информацию, если запрашиваемые данные не относятся к выбранному счету. |
¶ 3.4 Требования к отзыву согласия
Требования по представлению данных представлены в таблице 7.
Таблица 7 - Требования по представлению данных (продолжение)
| № | Область применения | Последовательность действий, которые выполняет Пользователь |
|---|---|---|
| 9 | Отзыв согласия | Если у СПИУ нет общей политики удаления использованных данных, использованные данные должны быть удалены с учетом: - СПИУ должен разрешать Пользователю выбирать лишние данные для удаления, как часть процесса отзыва согласия, до наступления последнего шага отзыва. - СПИУ должен предлагать подсказку Пользователю о возможности воспользоваться этим правом в соответствующее время (например, когда бездействие со стороны Пользователя может привести к тому, что он потеряет возможность воспользоваться правом на удаление своих использованных данных). |
| 10 | Отзыв авторизации: Последствия |
В процессе отзыва согласия, прежде чем Пользователь прекратит делиться своими данными, ППУ должен рекомендовать Пользователю рассмотреть возможные последствия отзыва с учетом наличия уже полученных данных. ППУ может использовать или перефразировать следующее сообщение: «Перед тем, как отозвать доступ к данным, Вам рекомендуется узнать у [СПИУ], как изменятся предоставляемые Вам услуги.» |
| 11 | Отзыв авторизации: Использованные данные |
В процессе отзыва ППУ должен информировать Пользователя об обработке использованных данных и праве на их удаление. ППУ может использовать или перефразировать следующие сообщения: «Данные Пользователя удаляются или деперсонализируются после использования». «[СПИУ] удалит Ваши данные после использования». «Если Вы этого еще не сделали, Вы можете попросить [СПИУ] удалить Ваши данные, когда они больше не будут нужны, но Вы должны сделать это прежде, чем Вы отзовете согласие». |
¶ 4. Базовые модели клиентского пути
Настоящие Требования определяют базовые модели клиентского пути на основе бизнес-процессов "Согласие на доступ к счету" и "Платежи" (описаны в разделах 4.1. и 4.2. соответственно). В следующей главе 5 представлена детализация их отдельных элементов при предоставлении согласия на доступ к счету (раздел 5.1.) и при использовании различных способов аутентификации (раздел 5.2.).
¶ 4.1 Согласие на доступ к счету
Данный раздел требований посвящен работе с согласием Пользователя, начиная от этапа «путь Пользователя до принятия решения о согласии» и до процессов, протекающих после авторизации согласия этапа «путь после согласия».
Пользователь, желающий предоставить свои данные СПИУ, проходит 3 основных этапа:
-
Путь до согласия**
-
Путь согласия:
- Согласие
- Аутентификация
- Авторизация
-
Путь после согласия
Основные шаги на пути Пользователя при предоставлении согласия представлены на диаграмме 1. В таблице 8 представлено описание диаграммы 1.
Шаги, указанные в составе каждого из этапов, могут выполняться в других последовательностях, но сами этапы (1-3) должны следовать в строгом порядке друг за другом.
Важно, что согласие на доступ к счету выдается Пользователем сроком не более, чем на 90 календарных дней. По истечении данного срока Пользователь должен пройти повторную аутентификацию на стороне своего ППУ, откуда происходит передача данных Пользователя, и повторно авторизовать согласие или внести в него необходимые изменения. В случае если Пользователь не производит повторную аутентификацию и авторизацию согласия или не вносит в него изменения, действие такого согласия аннулируется.
Диаграмма 1 – Согласие на доступ к счету
Таблица 8 - Описание процесса предоставления согласия на доступ к счету
| № | Участник | Наименование процесса | Описание процесса |
|---|---|---|---|
| Путь до согласия | |||
| 1 | СПИУ | Информирует о цели использования данных | СПИУ должен предоставить Пользователю достаточную информацию, чтобы позволить Пользователю принимать обоснованное решение. Для этого СПИУ подробно указывает цель передачи данных (включая то, будут ли какие-либо другие стороны иметь доступ к информации), период, за который данные будут запрошены, и когда истекает срок действия согласия на доступ к счету (согласие может быть действующим или одноразовым). |
| 2 | СПИУ | Информирует о праве на защиту данных | СПИУ должен предоставить Пользователю информацию о том, как его данные защищены законами РФ, а также что будет предпринято в случае утечки данных Пользователя. СПИУ должен предоставить сведения о своей сертификации. |
| 3 | СПИУ | Информирует о возможности отказа от передачи данных | СПИУ должен уведомить Пользователя о том, что Пользователь может отказаться от передачи своих данных и о последствиях такого отказа с точки зрения предоставления услуги СПИУ. |
| Согласие | |||
| 4 | СПИУ | Предоставляет описание запрашиваемых данных | СПИУ должен предоставить Пользователю описание запрашиваемых данных. При этом должно быть соблюдено условие, что запрос относится только к информации, необходимой для предоставления доступа к счетам Пользователя. СПИУ должен представлять данные на уровне кластера данных и позволять Пользователю расширять уровень детализации для отображения каждого разрешения на данные. СПИУ должен представлять только те кластеры данных, которые имеют отношение к рассматриваемому типу продукта. Если запрос относится к нескольким типам продуктов, то детали, показанные в кластере данных, должны объяснять Пользователю типы продуктов, к которым он применяется, или указывать, что он является общим для нескольких типов продуктов. |
| 5 | СПИУ | Предоставляет возможность выбора ППУ | СПИУ должен предоставить Пользователю возможность выбора ППУ, чтобы запрос на согласие мог быть составлен в соответствии с данными, которые поддерживает ППУ. Как только Пользователь подтверждает свой выбор, он должен быть перенаправлен к ППУ. |
| 6 | СПИУ | Направляет на прохождение аутентификации в ППУ | СПИУ должен проинформировать Пользователя о перенаправлении к ППУ для аутентификации доступа к информации о счетах. |
| Аутентификация | |||
| 7 | Аутентификация | Аутентификация Пользователя требуемым методом. | |
| Авторизация | |||
| 8 | ППУ | Предоставляет на выбор счета для передачи данных | ППУ должен указать наименование Стороннего поставщика, которое было представлено при регистрации в среде Открытых банковских интерфейсов. ППУ выводит перечень счетов, информация о которых может быть предоставлена СПИУ. Пользователь должен иметь возможность выбрать нужный счет (счета). Если ППУ предоставляет Пользователю опцию по просмотру данных, на которые он дал согласие для передачи в СПИУ, то эти сведения должны быть выведены в качестве дополнительной информации. Обозначенная опция не должна быть предоставлена Пользователю по умолчанию. В случае если Пользователь ранее уже дал согласие для данного СПИУ, но внес изменения по доступу к счетам (добавил и/или удалил счет(счета), изменил разрешение), то ППУ должен оповестить Пользователя об обновлении версии согласия и запрашивает его подтверждение. ППУ не должен запрашивать подтверждение согласия, если оно уже было ранее предоставлено Пользователем для данного СПИУ и не было изменено на данном шаге. |
| 9 | ППУ | Предоставляет возможность подтвердить согласие | ППУ должен вывести Пользователю инструмент подтверждения действия. Пользователь должен подтвердить своё согласие с помощью инструмента подтверждения. |
| Путь после согласия | |||
| 10 | СПИУ | Подтверждает успешное предоставление согласия | СПИУ должен отобразить подтверждение успешного инициирования запроса на доступ к счету. |
| 11 | Пользователь | Может ознакомиться с полной версией согласия | Пользователь может ознакомиться с полной версией согласия в панели управления согласиями на стороне СПИУ или в панели управления авторизациями на стороне ППУ. Форма полного согласия Пользователя представлена в Приложении №1 к настоящему документу. |
На рисунке 2 приведены примеры экранных форм основных шагов Пользователя при передаче согласия. Эти экранные формы являются примером того, как может выглядеть взаимодействие с Пользователем.
Рисунок 2 - Пример интерфейса клиентского пути по предоставлению доступа к счету Пользователя
¶ 4.2 Платежи
Пользователи могут инициировать, предоставляя свое согласие СППУ, разовый единичный платеж на обозначенную сумму выбранному Получателю средств. Если вся информация для формирования полного платежного поручения (включая данные счета Пользователя) передается от СППУ в ППУ после того как Пользователь аутентифицирован, он должен быть перенаправлен обратно к СППУ без каких-либо дополнительных шагов на стороне ППУ, за исключением случаев необходимости предоставления Пользователю дополнительной информации.
¶ 4.2.1 Разовый единичный платеж с выбором счета на стороне СППУ
В данной модели клиентского пути представлен процесс проведения разового единичного платежа с выбором счета на стороне СППУ.
Процесс приведен на диаграмме 2, описание его шагов представлено в таблице 9.
Диаграмма 2 – Разовый единичный платеж с выбором счета на стороне СППУ
Таблица 9 - Описание процесса клиентского пути Разового единичного платежа с выбором счета на стороне СППУ
| № | Участник | Процесс | Описание |
|---|---|---|---|
| 1 | СППУ | Предоставляет минимальный набор данных о платеже | СППУ должен предоставлять возможность Пользователю указывать минимальный набор параметров платежа (либо предварительно заполнять их для Пользователя): - Сумма и валюта платежа; - Наименование счета получателя; - Детали счета получателя (например, номер счета); - Референс платежа (рекомендуется); - Любая дополнительная информация, которую ППУ публикует при необходимости. |
| 2 | СППУ | Предоставляет выбор счета для оплаты | При выборе счета Плательщика СППУ должен предоставлять Пользователю одну из следующих опций: - Ввод данных идентификации счета Плательщика; - Выбор деталей идентификации счета Плательщика (предполагается, что они были сохранены ранее); - Выбор ППУ, чтобы выбрать счет позже при взаимодействии. |
| 3 | СППУ | Запрашивает согласие Пользователя о платеже | СППУ должен запрашивать согласие Пользователя на оплату в четкой и конкретной форме с отображением следующей информации на экране согласия о проведении платежа: - Сумма и валюта платежа; - Наименование счета получателя; - Референс платежа и любая дополнительная информация, если она была введена Пользователем или предварительно заполнена СППУ в пункте 1; - Идентификатор счета для платежа, введенный Пользователем и/или выбранный ППУ (на основании параметров пункта 2). Примечание: Идентификатор счета для платежа предоставляется в пункте 2, СППУ может использовать это для идентификации и отображения ППУ без необходимости запрашивать Пользователя. Для деталей идентификации счета получателя: - Если это было предоставлено в пункте 1, то ППУ также должен отображать это на экране согласия, чтобы Пользователь мог проверить корректность; - Если это было предварительно заполнено СППУ (например, в сценарии оплаты электронной коммерции), СППУ может выбрать отображать ли эту информацию или нет. |
| 4 | СППУ | Информирует о перенаправлении к ППУ | СППУ должен информировать Пользователя о последующем перенаправлении к ППУ для аутентификации и авторизации исполнения платежа. |
| 5 | СППУ | Перенаправление к ППУ | СППУ должен отобразить Пользователю экран и сообщение о перенаправлении от СППУ к ППУ (экраны перенаправления представлены в разделе Перенаправления). |
| 6 | ППУ | Предоставляет информацию о платеже для авторизации | В интерфейсе ППУ должна отображаться как минимум сумма платежа, валюта и наименование счета Получателя средств, чтобы Пользователь знал об этих деталях (если не применяется исключение строгой аутентификации). Эти данные должны отображаться без вывода дополнительных экранов подтверждения как часть процесса аутентификации на одном из следующих экранов: - Экран аутентификации (рекомендуется); - Экран перенаправления от ППУ к СППУ. |
| 7 | ППУ | Информирует о процессе авторизации платежа | ППУ должен информировать Пользователя о его «точке невозврата» для осуществления платежа и о том, что оплата будет произведена после того, как произойдет аутентификация. Пример формулировки: «Провести аутентификацию для оплаты». Аутентификация Пользователя на основе биометрических данных должна вызываться посредством оповещения к выполнению действия, чтобы дать Пользователю возможность просмотреть детали. ППУ может отображать остаток платежного счета Пользователя как часть процесса аутентификации на любом из следующих экранов: - Экран аутентификации ППУ; - Экран перенаправления от ППУ к СППУ. Отображение баланса в этом случае не требует дополнительной строгой аутентификации Пользователя. |
| 8 | ППУ | Аутентификация Пользователя в ППУ | Строгая аутентификация (включая "deep link") должна быть единственным требуемым действием со стороны ППУ (если не требуется дополнительная информация). Аутентификация Пользователя в ППУ в данном случае должна проводиться аналогично сценарию прямого доступа Пользователя к ППУ (не требовать большего числа шагов). |
| 9 | ППУ | Указывает состояние запроса и информирует о перенаправлении в СППУ | ППУ отображает на экране перенаправления состояние запроса и информирует Пользователя об автоматическом возвращении к СППУ. |
| 10 | СППУ | Подтверждение успешного инициирования платежа | СППУ должен отображать информацию, полученную от ППУ. Эта информация может включать в себя: - Уникальный идентификатор платежной инструкции, присвоенный ППУ; - Статус платежа (дата и время обновления статуса) - Подтверждение успешного инициирования платежа. В случае получения информации от ППУ, ССПУ должен отображать Пользователю следующую информацию до инициирования и выполнения платежа: - Ожидаемая дата и время исполнения платежа; - Ожидаемая дата валютирования платежа. - Комиссия ППУ (где применимо). |
| 11 | СППУ | Запрос на сохранение деталей платежа | Если Пользователь предоставляет детали счета (согласно пункту 2), СППУ может с согласия Пользователя сохранить данные счета для будущих транзакций (таких, как дальнейшие платежи или инициирование возврата), где это является частью услуги инициирования платежа, запрашиваемой Пользователем. Например, продавец по запросу от Пользователя может инициировать возврат, инструктируя тот же СППУ, который инициировал первоначальную транзакцию, использовать сохраненные идентификационные данные платежного счета Пользователя в качестве данных получателя для возврата. |
| 12 | СППУ | Отслеживание состояние платежа | СППУ должен отслеживать дальнейшее обновление статуса платежа в ППУ, чтобы проверять и извещать Пользователя об актуальной информации, которая может быть получена от ППУ для выполнения платежа. |
Пример реализации интерфейса клиентского пути Разового единичного платежа с выбором счета на стороне СППУ в соответствии с описанным бизнес-процессом приведен на рисунке 3.
Рисунок 3 - Пример интерфейса клиентского пути Разового единичного платежа с выбором счета на стороне СППУ
Дополнительная информация о Разовом единичном платеже
В некоторых сценариях может потребоваться дополнительный шаг Клиентского пути для отображения Пользователю дополнительной информации о Разовом единичном платеже со стороны ППУ.
Такой шаг может возникнуть в ситуации, когда дополнительная информация отдельно не предоставлялась Пользователю при прямом взаимодействии с ППУ (без перенаправления от СППУ).
В таком случае, ППУ должен учитывать поддержание паритета между взаимодействиями Пользователя с ППУ и СППУ. ППУ также должен предоставлять данную информацию таким образом, чтобы она не являлась препятствием к инициированию Разового единичного платежа или не потребовала дополнительной проверки согласия, предоставленного ранее Пользователем для СППУ.
Описание дополнительных шагов клиентского пути Разового единичного платежа с отображением дополнительной информации представлены в Таблице 10.
Таблица 10 – Дополнительная информация о Разовом единичном платеже
| № | Участник | Процесс | Описание |
|---|---|---|---|
| 1. (действие 7) | ППУ | Дополнительная информация | В процессе аутентификации, если это необходимо, ППУ должен иметь возможность сформировать экранную форму для отображения дополнительной информации, связанной с платежом. Если сформирована экранная форма для отображения дополнительной информации, ППУ должен отображать как минимум сумму платежа, валюту и имя счета получателя, чтобы информировать Пользователя о деталях платежной операции. Пользователь может либо подтвердить выполнение платежа, либо отменить его на том же экране, используя варианты с «равным приоритетом». |
Пример реализации интерфейса клиентского пути для представления экрана дополнительной информации (действие 7) приведен на рисунке 4.
Рисунок 4 – Пример интерфейса клиентского пути для вывода дополнительной информации
¶ 4.2.2 Разовый единичный платеж с выбором счета на стороне ППУ
В случае, если платежное поручение, представленное от СППУ к ППУ, является неполным, например, когда выбор счета Пользователя еще не произошел, строгую аутентификацию необходимо выполнить только один раз, как часть начального взаимодействия между ППУ и СППУ. Тот факт, что после аутентификации Пользователь должен выполнить выбор счета или предоставить другую информацию, не делает аутентификацию недействительной. Точно так же отображение ППУ баланса счета, как часть процесса выбора счета в процессе инициации платежа, не должно дополнительно приводить к применению строгой аутентификации.
Описание дополнительных шагов клиентского пути Разового единичного платежа с выбором счета на стороне ППУ представлено в таблице 11.
Таблица 11 – Описание процесса клиентского пути Разового единичного платежа с выбором счета на стороне ППУ
| № | Участник | Процесс | Описание |
|---|---|---|---|
| 1. (действие 9) | ППУ | Предоставляет выбор счета для оплаты | ППУ должен позволять Пользователю выбирать счет для оплаты, чтобы завершить выполнение платежного поручения. |
| 2. (действие 10) | ППУ | Представляет информацию о платеже для авторизации | Как только Пользователь выбрал свой счет, ППУ отображает следующую информацию для Пользователя: - Сумма и валюта платежа; - Наименование счета получателя; - Детали счета получателя (например, номер счета); - Референс платежа (если он был введен Пользователем или предварительно заполнена СППУ в пункте 1); - Любая требуемая дополнительная информация, которую ППУ опубликовал, если она была введена Пользователем или предварительно заполнена СППУ в пункте 1; - Выбранный Пользователем счет для оплаты; - Детали счета Получателя средств (например, номер счета). |
Пример реализации интерфейса клиентского пути для представления экрана Разового единичного платежа с выбором счета на стороне ППУ (действия 9, 10) приведен на рисунке 5.
Рисунок 5 – Пример интерфейса клиентского пути Разового единичного платежа с выбором счета на стороне ППУ
¶ 5. Детализация отдельных элементов клиентского пути
¶ 5.1 Предоставление согласия Пользователем
В настоящем разделе приведено детальное описание шагов Пользователя, предоставляющего согласие на доступ к счету в соответствии с базовой моделью клиентского пути, представленной в разделе 4.1.
¶ 5.1.1 Путь до согласия
Путь Пользователя до согласия, представленный на диаграмме 3, состоит из описания цели предоставления Пользователем данных и уведомления о законодательных нормах, защищающих данные Пользователя. Этот этап важен для формирования доверия со стороны Пользователя.
Описание шагов процесса клиентского пути, выполняемых до предоставления согласия, представлены в таблице 12.
Диаграмма 3 – Предоставление согласия Пользователем: путь до согласия
Таблица 12 – Описание шагов процесса клиентского пути предоставления согласия Пользователем: путь до согласия
| № | Участник | Наименование процесса | Описание процесса |
|---|---|---|---|
| Путь до согласия | |||
| 1 | СПИУ | Информирует о цели использования данных | СПИУ должен предоставить Пользователю достаточную информацию, чтобы позволить ему принимать обоснованное решение. Для этого необходимо подробно указать цель передачи данных (включая, будут ли какие-либо другие стороны иметь доступ к информации), период, за который данные будут запрошены, и когда истекает срок действия согласия на доступ к счету (согласие может быть действующим или разовым). |
| 2 | СПИУ | Информирует о праве на защиту данных | СПИУ должен предоставить Пользователю информацию о том, как его данные защищены законами РФ, а также что будет предпринято в случае утечки данных Пользователя. СПИУ должен предоставить сведения о своей сертификации. |
| 3 | СПИУ | Информирует о возможности отказа от передачи данных | СПИУ должен уведомить Пользователя о том, что Пользователь может отказаться от передачи своих данных и о последствиях такого отказа с точки зрения предоставления услуги СПИУ. |
¶ 5.1.1.1 Цель использования данных
Прежде чем запрашивать данные СПИУ должен проинформировать Пользователя о конечной цели использования запрашиваемых данных. СПИУ не должен запрашивать согласие на использование данных, не связанных с целями предоставляемых услуг.
Пример интерфейса клиентского пути указания цели использования данных Пользователя представлен на рисунке 6.
Рисунок 6 – Пример интерфейса клиентского пути указания цели использования данных Пользователя
¶ 5.1.1.2 Защита данных Пользователя
На этом этапе СПИУ должен предоставлять информацию о законодательстве Российской Федерации, защищающем Пользователя. Пример интерфейса информирования Пользователя о защите данных Пользователя представлен на рисунке 7.
В этом разделе следует отразить:
- Название компании и номер действующего сертификата Участника среды Открытых банковских интерфейсов, а также привести ссылку на описание среды Открытых банковских интерфейсов и применяемой технологии;
- Каким образом данные Пользователя не будут использованы. В качестве примера:
- «Мы не будем распространять Ваши данные без Вашего согласия»;
- «Мы не будем продавать Ваши данные»;
- «Мы не будем использовать Ваши данные с рекламными целями»;
- Ссылку на законодательство Российской Федерации о защите данных клиента.
Рисунок 7 – Пример интерфейса информирования Пользователя о защите данных
Предоставление согласия Пользователем не должно быть обязательным для использования приложения СПИУ. [1]
СПИУ должен предоставить Пользователю ссылку на официальный сайт среды Открытых банковских интерфейсов, на котором можно проверить наличие сертификатов у СПИУ.
СПИУ должен обеспечить Пользователя возможностью вернуться в предыдущее меню, при этом соответствующие кнопки должны быть доступны на всем пути согласия, чтобы обеспечить контроль и свободу интерактивного выбора представляемых типов согласий Пользователя.
СПИУ должен сообщить Пользователю какие меры будут приняты в случае нарушения безопасности данных Пользователя.
СПИУ должен обеспечить доступность прочтения всей информации на экране Пользователя.
[1] здесь и далее под приложением подразумевается любое фронтальное решение, используемое для предоставления услуг Пользователям, включая мобильные и веб-приложения ППУ и СПИУ.
¶ 5.1.1.3 Отказ от предоставления согласия
Требования по отмене предоставления согласия должны выполняться всякий раз, когда опция отмены выбрана Пользователем на любом этапе предоставления согласия.
Пример интерфейса клиентского пути отказа от предоставления данных Пользователя представлен на рисунке 8.
Рисунок 8 – Пример интерфейса клиентского пути отказа от предоставления данных Пользователя
¶ 5.1.2 Путь согласия
Путь согласия, представленный на диаграмме 4, состоит из трех отдельных этапов: согласие, аутентификация и авторизация.
Предоставление согласия
Этап предоставления согласия происходит в пространстве СПИУ.
На этом этапе Пользователь может:
- видеть, что СПИУ сертифицирован;
- просмотреть детали запроса данных;
- выбрать, какие ППУ будут делиться данными Пользователя.
Аутентификация
Этап проверки подлинности происходит в пространстве ППУ. На этом этапе происходит переход Пользователя в пространство ППУ для прохождения аутентификации.
Авторизация
Этап авторизации происходит на стороне ППУ.
На этом этапе Пользователь может:
- выбрать счета, по которым будет производиться обмен информацией;
- просматривать краткое содержание данных, которые будут переданы;
- разрешить передачу своих данных от ППУ к СПИУ.
Диаграмма 4 – Предоставление согласия Пользователем: путь согласия
¶ 5.1.2.1 Предоставление согласия
Этап предоставления согласия, представленный на диаграмме 5, содержит несколько шагов, которые могут включать в себя запрос данных Пользователя, выбор ППУ и этап предварительной аутентификации.
Диаграмма 5 – Предоставление согласия Пользователем: согласие
Запрос данных
На этом шаге Пользователь может просмотреть перечень данных, которые запрашивает СПИУ.
Выбор ППУ
На этом шаге Пользователь может выбрать ППУ, который будет делиться данными Пользователя.
Этап предварительной аутентификации
Этот шаг должен помочь Пользователю сформировать понимание того, что повлечет за собой аутентификация.
Описание шагов процесса клиентского пути, касающихся предоставления согласия, представлены в таблице 13.
Таблица 13 – Описание шагов процесса клиентского пути предоставления согласия Пользователем: предоставление согласия
| № | Участник | Наименование процесса | Описание процесса |
|---|---|---|---|
| Согласие | |||
| 4 | СПИУ | Предоставляет описание запрашиваемых данных | СПИУ предоставляет Пользователю описание запрашиваемых данных. При этом должно быть соблюдено условие, что запрос относится только к информации, необходимой для предоставления доступа к счетам Пользователя. СПИУ должен представлять данные на уровне кластера данных и позволять Пользователю расширять уровень детализации для отображения каждого разрешения на данные. СПИУ должен представлять только те кластеры данных, которые имеют отношение к рассматриваемому типу продукта. Если запрос относится к нескольким типам продуктов, то детали, показанные в кластере данных, должны объяснять Пользователю типы продуктов, к которым он применяется, или указывать, что он является общим для нескольких типов продуктов. |
| 5 | СПИУ | Предоставляет возможность выбора ППУ | СПИУ должен предоставить Пользователю возможность выбора ППУ, чтобы запрос на согласие мог быть составлен в соответствии с данными, которые поддерживает ППУ. Как только Пользователь подтверждает свой выбор, он должен быть перенаправлен к ППУ. |
| 6 | СПИУ | Направляет на прохождение аутентификации в ППУ | СПИУ должен проинформировать Пользователя о перенаправлении к ППУ для аутентификации доступа к информации о счетах. |
¶ 5.1.2.2 Запрос данных
В этом разделе приведены примеры, иллюстрирующие, как может быть реализован запрос данных у Пользователя.
Пример реализации запроса данных представлен на рисунке 9.
Запрашиваются два кластера данных: «Детали транзакции» и «Автоплатежи». Эти кластеры данных представлены на одном экране. Пользователь должен выбрать «Я согласен», чтобы согласиться с передачей этих данных.
Рисунок 9 – Пример интерфейса клиентского пути запроса данных Пользователя
Активное согласие клиента
Когда Пользователь хочет дать согласие на сбор и обработку его данных, СПИУ предоставляет ему эту возможность в явном виде при помощи выбора на экранных формах. СПИУ должен указать название компании и номер сертификата участника среды Открытых банковских интерфейсов.
Кластеры данных и разрешения
СПИУ должен указывать типы данных, для которых запрашивается согласие. Если СПИУ требуется получение нескольких типов данных для предоставления услуги Пользователю, Пользователь должен иметь возможность выбрать, к каким именно типам данных он готов дать согласие, а к каким не готов. Для каждого типа данных СПИУ должен указать цель их использования.
СПИУ должен реализовывать кнопки для согласия специально не преднастроенными для того, чтобы Пользователь самостоятельно мог выбрать и указать, на что он дает согласие, а на что нет. Для удобства Пользователя СПИУ должен выводить краткие инструкции, как предоставлять согласие.
Все кластеры данных должны иметь функцию демонстрации Пользователю подробного перечня данных, которые входят в кластер. Если требуется, СПИУ может объединять и изменять кластеры данных и представления разрешений, чтобы показать Пользователю данные в удобном формате.
Пример интерфейса клиентского пути представления кластерных данных представлен на рисунке 10.
Рисунок 10 – Пример интерфейса клиентского пути представления кластерных данных
Дополнительные способы использования данных
СПИУ не должен запрашивать согласие Пользователя на продажу его данных без деперсонализации. Если СПИУ хочет использовать данные Пользователя в маркетинговых целях, он должен напрямую запросить разрешение Пользователя.
Если СПИУ намерен деперсонализировать данные Пользователя, он должен сообщить Пользователю:
- как происходит процесс деперсонализации;
- с какими целями данные будут деперсонализированы;
- кому деперсонализированные данные будут переданы;
- о возможности удалить деперсонализированные данные в любой момент.
Пример интерфейса клиентского пути дополнительных способов использования данных Пользователя представлен на рисунке 11.
Рисунок 11 – Пример интерфейса клиентского пути дополнительных способов использования данных Пользователя
Сторонние потребители данных
СПИУ должен сообщить Пользователю полный перечень сторонних потребителей данных, для предоставления деперсонализированных данных которым СПИУ просит дать согласие Пользователя.
При этом СПИУ должен обеспечить соблюдение сторонними потребителями данных тех же требований к использованию данных Пользователя, что и у СПИУ, и информировать об этом Пользователя.
Сроки предоставления согласия
СПИУ должен предоставить Пользователю возможность выбрать период, за который данные будут собраны и использованы, сроком не более 12 месяцев от текущей даты.
СПИУ должен указать частоту сбора данных за этот период (например, 1 раз в месяц).
Согласие на сбор и использование данных Пользователя истекает:
- Когда Пользователь отзывает свое согласие;
- Когда ППУ сообщает СПИУ о том, что Пользователь отозвал авторизацию согласия;
- Через 12 месяцев после получения согласия (или меньший срок по согласованию с Пользователем);
- Когда сертификация СПИУ или ППУ как Участника среды Открытых банковских интерфейсов была приостановлена/ остановлена.
Пример интерфейса клиентского пути указания сроков согласия представлен на Рисунке 12.
Рисунок 12 – Пример интерфейса клиентского пути указания сроков согласия
Управление использованными данными
Данные Пользователя, на предоставление доступа, к которым Пользователь ранее дал согласие, становятся использованными после истечения срока согласия.
СПИУ должен сообщить Пользователю о последующих действиях с его использованными данными и уведомить о том, что использованные данные могут быть удалены или деперсонализированны (в соответствии с действующими на территории Российской Федерации требованиями по обезличиванию персональных данных) в любой момент по желанию Пользователя.
Пример интерфейса клиентского пути управления использованными данными представлен на рисунке 13.
Рисунок 13 – Пример интерфейса клиентского пути управления использованными данными
Деперсонализация
Использованные данные Пользователя могут быть деперсонализированны, если Пользователь пожелал оставить их таковыми.
При этом СПИУ должен сообщить Пользователю:
- как происходит процесс деперсонализации;
- что деперсонализированные данные будут использоваться без дальнейшего согласия Пользователя;
- примеры того, как будут использоваться деперсонализированные данные.
Удаление данных
СПИУ должен сообщить, что использованные данные Пользователя будут удалены, если Пользователь определит необходимость удалить свои данные после использования. В случае если Пользователь принял решение об удалении, СПИУ должен удалить их.
Проверка и отмена согласий
СПИУ должен сообщить Пользователю, что согласие Пользователя будет доступно в панели управления согласиями и может быть отозвано в любой момент по усмотрению Пользователя через панель управления согласиями. После того как Пользователь отозвал согласие, СПИУ должен подтвердить прекращение сбора и использования данных Пользователя соответствующим уведомлением.
Пример интерфейса клиентского пути проверки и отмены согласий представлен на рисунке 14.
Рисунок 14 – Пример интерфейса клиентского пути проверки и отмены согласий
Отзыв старых согласий
СПИУ должен обеспечить возможность Пользователю отзывать свои согласия в любой момент времени. Если Пользователь желает предоставить новое согласие, его старое согласие должно быть автоматически отозвано вместе с предоставлением нового.
Перед тем, как согласие Пользователя будет отозвано, Пользователю должна быть предоставлена возможность решить, что ему делать с уже использованными данными.
¶ 5.1.2.3 Выбор ППУ
В этом разделе приведены примеры, иллюстрирующие процесс выбора ППУ.
Возможность выбора ППУ для обмена данными
Выбор ППУ может происходить до или после запроса данных. В этой версии Требований описывается ситуация с выбором только одного ППУ за один раз.
СПИУ должен учитывать последствия предоставления согласия на передачу данных сразу от нескольких ППУ в рамках одного процесса: Пользователь будет вынужден пройти аутентификацию и авторизацию сразу у нескольких ППУ. Такой процесс может быть неудобен для Пользователя и может поставить под угрозу качество выполнения услуги СПИУ при определенных обстоятельствах.
СПИУ должен отображать для удобства Пользователя:
- Строку поиска для поиска нужного ППУ;
- Возможность выбора ППУ из имеющегося списка. ППУ должны быть представлены в алфавитном порядке.
Пример интерфейса клиентского пути выбора ППУ представлен на рисунке 15.
Рисунок 15 – Пример интерфейса клиентского пути выбора ППУ
¶ 5.1.2.4 Пре-аутентификация
На данном этапе Пользователю должно быть выведено уведомление о необходимости дальнейшего прохождения аутентификации у ППУ. В уведомлении рекомендуется дополнительно прокомментировать юридические аспекты процедуры.
Пример интерфейса клиентского пути пре-аутентификации представлен на рисунке 16.
Рисунок 16 – Пример интерфейса клиентского пути пре-аутентификации
¶ 5.1.2.5 Aутентификация
Этап Аутентификации Пользователя на стороне ППУ, представленный на диаграмме 6, может происходить по одному из вариантов, представленных в разделе 5.2. настоящих Требований.
Диаграмма 6 – Аутентификация
¶ 5.1.2.6 Авторизация
ППУ должен запрашивать у Пользователя разрешение на передачу его данных СПИУ. В ходе такого запроса ППУ не добавляет новых требований, новых данных или дополнительных услуг в процессе авторизации, кроме тех, с которыми Пользователь уже был предварительно согласен.
Этап авторизации, представленный на диаграмме 7, состоит из двух шагов:
Выбор счета Пользователя
На этом шаге Пользователь выбирает счет, данными по которому он бы хотел поделиться.
Подтверждение
На этом шаге Пользователь может просмотреть и подтвердить данные, которые будут переданы СПИУ.
Описание шагов приведено в таблице 14.
Диаграмма 7 – Авторизация
Таблица 14 – Описание шагов процесса клиентского пути предоставления согласия Пользователем: авторизация
| № | Участник | Наименование процесса | Описание процесса |
|---|---|---|---|
| Авторизация | |||
| 8 | ППУ | Предоставляет на выбор счета для передачи данных | ППУ должен указать наименование Стороннего поставщика, которое было представлено при регистрации в среде Открытых банковских интерфейсов. ППУ отображает перечень счетов, информация о которых может быть предоставлена СПИУ. Пользователь должен иметь возможность выбрать нужный счет (счета). Если ППУ предоставляет Пользователю опцию по просмотру данных, на которые он дал согласие для передачи в СПИУ, то эти сведения должны быть выведены в качестве дополнительной информации. Обозначенная опция не должна быть предоставлена Пользователю по умолчанию. В случае, если Пользователь ранее уже давал согласие для данного СПИУ, но внес изменения по доступу к счетам (добавил и/или удалил счет(счета), изменил разрешение), то ППУ извещает Пользователя об обновлении версии согласия и запрашивает его подтверждение. ППУ не должен запрашивать подтверждение согласия, если оно уже было ранее предоставлено Пользователем для данного СПИУ и не было изменено на данном шаге. |
| 9 | ППУ | Предоставляет возможность подтвердить согласие | ППУ должен отобразить Пользователю инструмент подтверждения действия. Пользователь должен подтвердить своё согласие с помощью инструмента подтверждения. |
Выбор счета Пользователя
На этом этапе ППУ должен предоставить возможность Пользователю выбрать счет, информация о котором должна быть предоставлена СПИУ, если у Пользователя несколько счетов.
Пример интерфейса клиентского пути выбора счета Пользователя представлен на Рисунке 17.
Рисунок 17 – Пример интерфейса клиентского пути выбора счета Пользователя
ППУ должен обозначить Пользователю, какой СПИУ выполняет запрос, отобразить счета Пользователя, на передачу информации о которых Пользователь может дать согласие. Если какие-то из счетов Пользователя недоступны, ППУ также должен их отобразить, но с пометкой, что они недоступны, и возможностью узнать причину. ППУ может также сообщить Пользователю, как сделать эти счета доступными.
Подтверждение
На этом этапе Пользователь может просмотреть и подтвердить данные, которые будут переданы СПИУ.
Кластеры данных и разрешений
ППУ должен отображать Пользователю кластеры и детальные данные, которые запрашивает СПИУ.
Период
ППУ должен отобразить период, на который Пользователь дает согласие, а также уведомить Пользователя о том, что его согласие может быть отозвано в любой момент, в том числе через панель управления авторизациями Пользователя на стороне ППУ.
Авторизация согласия Пользователя истекает, когда:
- пользователь отзывает авторизацию согласия;
- закончился срок согласия Пользователя или прошло 12 месяцев с момента подачи согласия Пользователя;
- сертификация СПИУ более не действительна.
Последний шаг
Пользователь делает последний шаг к авторизации обмена данными. Последним шагом к авторизации обмена данными является подписание согласия Пользователя в соответствии с разрешенными на территории РФ юридически значимыми механизмами подписания документов.
¶ 5.1.3 Путь после согласия
Путь после согласия, представленный на диаграмме 8, состоит из двух этапов: подтверждение успешного запроса на предоставление согласия, ознакомление с полной версией согласия. Описание шагов приведено в таблице 15.
Диаграмма 8 – Путь после согласия
Таблица 15 – Описание шагов процесса клиентского пути после предоставления согласия
| № | Участник | Наименование процесса | Описание процесса |
|---|---|---|---|
| Путь после согласия | |||
| 10 | СПИУ | Подтверждает успешное предоставление согласия | СПИУ должен отобразить подтверждение успешного инициирования запроса на доступ к счету. |
| 11 | Пользователь | Может ознакомиться с полной версией согласия | Пользователь может ознакомиться с полной версией согласия в панели управления согласиями на стороне СПИУ или в панели управления авторизациями на стороне ППУ. Форма полного согласия Пользователя представлена в Приложении №1 к настоящему документу. |
После того как Пользователь дал согласие на передачу данных, ему должна быть предоставлена возможность скачать полную версию его согласия в PDF формате. Пользователь получает возможность просматривать и управлять своими согласиями через панель управления согласиями на стороне СПИУ и панель управления авторизациями на стороне ППУ.
Пример интерфейса клиентского пути после согласия представлен на рисунке 18.
Рисунок 18 – Пример интерфейса клиентского пути после согласия
¶ 5.1.4 Управление согласием и отзыв согласия
¶ 5.1.4.1 Управление согласием на стороне СПИУ
СПИУ должны предоставлять Пользователю возможность просматривать и отзывать его согласия для каждого счета, к которому был предоставлен доступ.
На диаграмме 9 представлен процесс управление согласием на стороне СПИУ, а описание его шагов в таблице 16.
Диаграмма 9 – Управление согласием на стороне СПИУ
Таблица 16 – Описание процесса клиентского пути управления согласием на стороне СПИУ
| № | Участник | Наименование процесса | Описание процесса |
|---|---|---|---|
| 1 | СПИУ | Предоставляет возможность выбора согласия | СПИУ должен предлагать функциональность (например, поиск, сортировка, фильтрация), чтобы Пользователь мог искать соответствующее согласие. Это становится актуальным по мере увеличения количества согласий для разных ППУ/счетов, предоставляемых Пользователем для СПИУ. |
| 2 | СПИУ | Информирует о цели использования данных | СПИУ должен указать наименование компании ППУ для Пользователя во время установки и отзыва согласия. СПИУ должен предоставить Пользователю достаточную информацию, чтобы позволить Пользователю принимать обоснованное решение. Для этого подробно указывает цель передачи данных (включая то, будут ли какие-либо другие стороны иметь доступ к информации), период, за который данные будут запрошены и когда истекает срок действия согласия на доступ к счету (согласие может быть действующим или разовым). |
| 3 | СПИУ | Предоставляет описание согласия | СПИУ должен описывать данные, предоставляемые через каждое согласие, используя структуру и язык описания данных среды Открытых банковских интерфейсов. СПИУ должен обеспечить, чтобы этот запрос относился только к информации, необходимой для предоставления их сервису доступа к счетам Пользователя. СПИУ должен представлять данные на уровне кластера данных и позволять Пользователю расширять уровень детализации для отображения каждого разрешения на данные. Панель согласия должна содержать следующую информацию: - Описание предоставляемой услуги по информации о счете (включая информацию о том, будут ли какие-либо другие стороны иметь доступ к этой информации); - Если запрос относится к нескольким типам продуктов, в деталях должен быть разъяснен тип продукта, к которому запрос применяется, или указано, что оно является общим для нескольких типов продуктов; - Дата, когда согласие было впервые предоставлено. Рекомендуется также указать дату, когда Пользователь последний раз обновлял свой доступ в рамках 90-дневной повторной аутентификации; - Период времени, в течение которого это согласие является действительным (например, разовое использование, в течение установленного периода времени, например, одного года или без даты окончания и даты истечения срока действия); - Период, за который запрашивалась информация о счете (например, транзакции за последние 12 месяцев). Панель согласия должна позволять Пользователю просматривать или отменять доступ, на который он дал согласие. Функции «Отмена согласия» и «Назад» должны отображаться с равным приоритетом для Пользователя. |
| 4 | СПИУ | Информирует о последствиях отмены согласия | СПИУ должен четко разъяснить Пользователю последствия отмены согласия, сообщив о том, что он больше не сможет предоставлять конкретную услугу Пользователю. |
| 5 | СПИУ | Удаляет согласие в ППУ | СПИУ должен проинформировать ППУ о том, что Пользователь отозвал согласие, сделав вызов для удаления ресурса согласия на доступ к счету. ППУ должны поддерживать процесс удаления. (Это происходит без участия Пользователя, но гарантирует, что ППУ не предоставит дополнительную информацию о счете для СПИУ). |
| 6 | СПИУ | Информирует об отзыве согласия | СПИУ должен проинформировать Пользователя о том, что ППУ в дальнейшем не предоставит СПИУ никакой дополнительной информации о счете, т.к. Пользователь отозвал свой доступ для СПИУ. После того, как СПИУ вызывает конечную точку для удаления ресурса согласия на доступ к счету, ППУ рекомендуется информировать Пользователя через свои собственные каналы (например, через SMS или через уведомление на своем мобильном телефоне), что СПИУ больше не будет иметь доступ к счету. |
Пример интерфейса клиентского пути управления согласием на стороне СПИУ представлен на рисунке 19.
Рисунок 19 – Пример интерфейса клиентского пути управления согласием на стороне СПИУ
¶ 5.1.4.2 Управление доступом на стороне ППУ
ППУ должны предоставлять Пользователю возможность просматривать и отзывать текущий доступ, который они предоставили СПИУ для каждого счета, которым управляет ППУ. На диаграмме 10 представлен процесс управление согласием на стороне ППУ, а описание его шагов в таблице 17.
Диаграмма 10 – Управление согласием на стороне ППУ
Таблица 17 – Описание процесса клиентского пути управления согласием на стороне ППУ
| № | Участник | Наименование процесса | Описание процесса |
|---|---|---|---|
| 1 | ППУ | Указывает наименование Стороннего поставщика | ППУ должен указывать наименование компании СПИУ для Пользователя во время аутентификации на всех экранах интерфейса. |
| 2 | ППУ | Предоставляет возможность выбора согласия | ППУ должен предлагать функциональность (например, поиск, сортировка, фильтрация), чтобы Пользователь мог искать соответствующее согласие. Это становится актуальным по мере увеличения количества согласий, предоставляемых Пользователем Сторонним поставщикам. |
| 3 | ППУ | Предоставляет описание доступа | ППУ должен обозначать данные, к которым осуществляется доступ. ППУ должен представлять данные на уровне кластера данных и позволять Пользователю расширять уровень детализации для отображения каждого разрешения на данные. Панель доступа должна также содержать описание: - Статус доступа, например, активный/неактивный; - Когда истечет срок действия согласия для доступа СПИУ к счету; - Дата предоставления согласия. Так же панель может включать дату последнего доступа. |
| 4 | ППУ | Информирует о статусе доступа | ППУ должен представлять статус доступа Стороннего поставщика явным образом, четко указав, кто из участников предоставил доступ СПИУ в случае нескольких владельцев счетов. |
| 5 | ППУ | Информирует об отзыве согласия | Панель управления доступом должна позволять Пользователю просматривать или отменять доступ, на который он дал согласие. Функции «Отмена согласия» и «Назад» должны отображаться с равным приоритетом для Пользователя. ППУ должны сообщить Пользователю о необходимости связаться с соответствующим СПИУ для информирования об отмене доступа и уточнения последствий отмены. |
Пример интерфейса клиентского пути управления согласием на стороне ППУ представлен на рисунке 20.
Рисунок 20 – Пример интерфейса клиентского пути управления согласием на стороне ППУ
¶ 5.2 Методы аутентификации
В настоящем документе рассматриваются следующие методы выполнения процедуры аутентификации Пользователя:
- Перенаправление - Пользователь перенаправляется для прохождения аутентификации из приложения Стороннего поставщика в ППУ через выделенный интерфейс и, в частности, API-интерфейсы;
- Разъединённая аутентификация - Пользователь использует отдельное вторичное устройство для аутентификации в ППУ.
В процессе взаимодействия участников в среде Открытых банковских интерфейсов при необходимости используется строгая аутентификации клиента в соответствии с ГОСТ Р 58833-2020 «Защита информации. Идентификация и аутентификация. Общие положения». При этом ППУ не должен запрашивать строгую аутентификацию Пользователя более одного раза при одной процедуре доступа к информации о счете или инициировании одного платежа.
¶ 5.2.1 Общие принципы аутентификации
В отношении аутентификации применяются следующие общие принципы:
- Аутентификация Пользователя в ППУ. Пользователь должен пройти многофакторную аутентификацию в своем ППУ для того, чтобы ППУ выполнил запрос Стороннего поставщика (доступ к информации по счету или инициирование платежа).
- Для Пользователя должны быть доступны обычные методы аутентификации. Пользователь должен иметь возможность использовать элементы аутентификации, которые он применяет при прямом взаимодействии с ППУ.
- Сложность процесса. Процесс, доступный для Пользователя при аутентификации через ППУ, должен включать не больше шагов, задержек, взаимодействий, чем эквивалентный процесс прямого взаимодействия с ППУ.
- Строгая аутентификация. Не ожидается, что строгая аутентификация потребуется более одного раза при прохождении аутентификации для получения доступа к информации о счетах или инициирования одного платежа.
- Отсутствие препятствий. ППУ не должны создавать дополнительную задержку или взаимодействие во время аутентификации, включая лишние шаги, атрибуты или нечеткие формулировки (например, реклама продуктов или услуг ППУ) или дополнительные функции.
¶ 5.2.2 Перенаправления
В данном разделе представлены особенности клиентского пути для доступа к информации о счете и авторизации платежей, в зависимости от различных вариантов перенаправления.
¶ 5.2.2.1 Перенаправление в веб-браузере для доступа к счету
Аутентификация Пользователя в ППУ с использованием перенаправления в веб-браузере из СПИУ для авторизации запроса сервиса позволяет Пользователю проходить аутентификацию с помощью своего ППУ, используя тот же метод веб-аутентификации, который использует Пользователь при прямом доступе к ППУ через веб-браузер. Эта модель применяется, когда Пользователь использует сервис СПИУ на устройстве, на котором нет приложения ППУ, или Пользователь не имеет мобильного приложения ППУ.
На диаграмме 11 представлен процесс аутентификации Пользователя в ППУ для авторизации согласия на доступ к счету с использованием перенаправления в веб-браузере из СПИУ, а описание его шагов в таблице 18.
Диаграмма 11 – Перенаправление в веб-браузере для доступа к счету
Таблица 18 – Описание процесса клиентского пути перенаправления в браузере для доступа к счету
| № | Участник | Процесс | Описание |
|---|---|---|---|
| 1 | СПИУ | Предоставляет возможность идентификации ППУ | СПИУ должен предоставить Пользователю возможность идентифицировать ППУ, чтобы запрос на согласие мог быть составлен в соответствии с данными, которые поддерживает ППУ. |
| 2 | СПИУ | Информирует о перенаправлении к ППУ | СПИУ должен проинформировать Пользователя о перенаправлении к ППУ для аутентификации доступа к информации о счетах. |
| 3 | ППУ | Аутентификация | Пользователь перенаправляется на веб-страницу ППУ только в целях аутентификации (без дополнительных действий). Аутентификация должна выполняться в том объеме шагов, что и при прямом доступе к ППУ. |
| 4 | ППУ | Информирует об использовании данных аутентификации | ППУ должен информировать Пользователя о том, что его данные, используемые при аутентификации, не будут доступны в сервисе. |
| 5 | ППУ | Подтверждение счета | Пользователь должен подтвердить счет (счета) на одном экране, без необходимости проходить через дополнительные шаги. |
| 6 | ППУ | Указывает статус состояние запроса и информирует о перенаправлении в СПИУ | ППУ должен отобразить на экране перенаправления статус запроса и проинформировать Пользователя о том, что он будет автоматически возвращен в СПИУ. |
| 7 | ППУ | Извещает о закрытии сессии | ППУ должен оповестить Пользователя о закрытии сессии. |
| 8 | СПИУ | Подтверждение успешного инициирования запроса | СПИУ должен отобразить подтверждение успешного инициирования запроса на доступ к счету. |
Пример реализации интерфейса клиентского пути Перенаправление в браузере для доступа к счету в соответствии с описанным бизнес-процессом приведен на рисунке 21.
Рисунок 21 – Пример интерфейса клиентского пути Перенаправление в браузере для доступа к счету
¶ 5.2.2.2 Перенаправление в веб-браузере для авторизации платежа
Аутентификация Пользователя в ППУ с использованием перенаправления в веб-браузере из СППУ для авторизации запроса сервиса позволяет Пользователю проходить аутентификацию с помощью своего ППУ, используя тот же метод веб-аутентификации, который использует Пользователь при прямом доступе к ППУ через веб-браузер. Эта модель применяется, когда Пользователь использует сервис СППУ на устройстве, на котором нет приложения ППУ, или Пользователь не имеет мобильного приложения ППУ.
На диаграмме 12 представлен процесс аутентификации Пользователя в ППУ для авторизации платежа с использованием перенаправления в веб-браузере из СППУ, а описание его шагов в приведено в таблице 19.
Диаграмма 12 – Перенаправление в веб-браузере для авторизации платежа
Таблица 19 – Описание процесса клиентского пути перенаправления в браузере для авторизации платежа
| № | Участник | Процесс | Описание |
|---|---|---|---|
| 1 | СППУ | Предоставляет выбор счета для оплаты | СППУ должен предоставить Пользователю возможность выбрать (если они были ранее сохранены) или ввести детали счета для оплаты. |
| 2 | СППУ | Запрашивает согласия Пользователя о платеже | СППУ должен предоставить Пользователю детальную информацию для получения согласия на инициацию платежа. |
| 3 | СППУ | Информирует о перенаправлении к ППУ | СППУ должен проинформировать Пользователя о перенаправлении к ППУ для аутентификации и авторизации исполнения платежа и отобразить на экране перенаправления: - Cумму платежа; - Код валюты; - Наименование счета получателя. |
| 4 | СППУ | Перенаправление Пользователя к ППУ | Перенаправление должно перенести Пользователя к веб-странице ППУ (ПК / мобильная) только для целей аутентификации без вывода дополнительных экранов. |
| 5 | ППУ | Представляет информацию о платеже для авторизации | В интерфейсе ППУ должны отображаться как минимум Сумма платежа, Валюта и Имя наименование счета получателя, чтобы Пользователь знал об этих деталях (если не применяется исключение строгой аутентификации). Эти данные должны отображаться без дополнительных экранов подтверждения, как часть процесса аутентификации, на одном из следующих экранов: - Экран аутентификации (рекомендуется); - Экран перенаправления от ППУ к СППУ. |
| 6 | ППУ | Аутентификация Пользователя в ППУ | Веб-аутентификация в ППУ должна состоять из числа шагов, аналогичного числу при совершении платежа напрямую через веб-канал ППУ (ПК / мобильный) |
| 7 | ППУ | Указывает статус состояние запроса и информирует о перенаправлении в СППУ | ППУ должен отображать на экране перенаправления состояние запроса и информировать Пользователя, что он будут автоматически возвращен в СППУ. |
| 8 | ППУ | Извещает о закрытии сессии | ППУ должен сообщить Пользователю о закрытии сессии. |
| 9 | СППУ | Подтверждение успешного инициирования платежа | Пользователь должен быть перенаправлен обратно на веб-сайт / в приложение СППУ на том же устройстве. СППУ должен отображать подтверждение успешного инициирования платежа. |
Пример реализации интерфейса клиентского пути Перенаправление в браузере для авторизации платежа в соответствии с описанным бизнес-процессом приведен на рисунке 22.
Рисунок 22 – Пример интерфейса клиентского пути Перенаправление в браузере для авторизации платежа
¶ 5.2.2.3 Перенаправление в приложение ППУ для доступа к счету
Аутентификация Пользователя в ППУ с использованием перенаправления из приложения СПИУ для авторизации запроса сервиса позволяет Пользователю проходить аутентификацию с помощью собственного приложения ППУ (аутентификация в мобильном приложении). Перенаправление должно напрямую вызывать приложение ППУ для аутентификации Пользователя и не должно требовать от Пользователя предоставлять учетные данные ППУ. Реализация сервиса СПИУ может быть веб-ориентированной или прикладной.
На диаграмме 13 представлен процесс аутентификации Пользователя с помощью мобильного приложения ППУ, установленного на том же устройстве, на котором Пользователь использует сервис СПИУ для авторизации согласия на доступ к счету с использованием перенаправления из СПИУ. В таблице 20 описаны шаги процесса данной модели аутентификации.
Диаграмма 13 – Перенаправление в приложение ППУ для доступа к счету
Таблица 20 – Описание процесса клиентского пути перенаправления в приложение ППУ для доступа к счету
| № | Участник | Процесс | Описание |
|---|---|---|---|
| 1 | СПИУ | Предоставляет возможность идентификации ППУ | СПИУ должен предоставить Пользователю возможность идентифицировать ППУ, чтобы запрос на согласие мог быть составлен в соответствии с данными, которые поддерживает ППУ. |
| 2 | СПИУ | Информирует о перенаправлении к ППУ | СПИУ должен информировать Пользователя о перенаправлении к ППУ для аутентификации доступа к информации о счетах. |
| 3 | СПИУ | Аутентификация Пользователя в ППУ | Если приложения СПИУ и ППУ установлены на одном устройстве, то перенаправление должно вызывать приложение ППУ только в целях аутентификации (без дополнительных экранов интерфейса). Аутентификация Пользователя в приложении ППУ должна осуществляться за аналогичное прямому доступу число шагов и предлагать те же методы аутентификации. |
| 4 | ППУ | Подтверждение счета | После аутентификации Пользователь должен быть связан с приложением ППУ без необходимости проходить какие-либо дополнительные обязательные окна интерфейса для подтверждения счета, к которому он дает доступ СПИУ. |
| 5 | ППУ | Указывает статус состояние запроса и информирует о перенаправлении в СПИУ | ППУ должен показывать на экране перенаправления статус запроса и информировать Пользователя, что он будет автоматически возвращен в СПИУ. |
| 6 | ППУ | Извещает о закрытии сессии | ППУ должен сообщать Пользователю о закрытии сессии. |
| 7 | СПИУ | Подтверждение успешного инициирования запроса | СПИУ должен отображать подтверждение успешного инициирования запроса на доступ к счету. |
Пример реализации интерфейса клиентского пути Перенаправление в приложение ППУ для доступа к счету в соответствии с описанным бизнес-процессом приведен на рисунке 23.
Рисунок 23 – Пример интерфейса клиентского пути Перенаправление в приложение ППУ для доступа к счету
¶ 5.2.2.4 Перенаправление в приложение ППУ для авторизации платежа
Аутентификация Пользователя в ППУ с использованием перенаправления из приложения СППУ для авторизации платежа позволяет Пользователю проходить аутентификацию с помощью собственного приложения ППУ (аутентификация в мобильном приложении). Перенаправление должно напрямую вызывать приложение ППУ для аутентификации Пользователя и не должно требовать от Пользователя предоставлять учетные данные ППУ. Реализация сервиса СППУ может быть веб-ориентированной или прикладной.
На диаграмме 14 представлен процесс аутентификации Пользователя с помощью мобильного приложения ППУ, установленного на том же устройстве, на котором Пользователь использует сервис СППУ для авторизации платежа с использованием перенаправления из СППУ. В таблице 21 описаны шаги процесса данной модели аутентификации.
Диаграмма 14 – Перенаправление в приложение ППУ для авторизации платежа
Таблица 21 – Описание процесса клиентского пути перенаправления в приложение ППУ для авторизации платежа
| № | Участник | Процесс | Описание |
|---|---|---|---|
| 1 | СППУ | Предоставляет выбор счета для оплаты | СППУ должен предоставлять возможность Пользователю выбрать (если счета были ранее сохранены) или ввести детали счета для оплаты. |
| 2 | СППУ | Запрашивает согласие Пользователя о платеже | СППУ должен предоставлять Пользователю детальную информацию для получения согласия на инициацию платежа. |
| 3 | СППУ | Информирует о перенаправлении к ППУ | СППУ должен информировать Пользователя о перенаправлении к ППУ для аутентификации и авторизации исполнения платежа и отображает на экране перенаправления: - Сумму платежа; - Код валюты; - Наименование счета получателя. |
| 4 | СППУ | Перенаправление Пользователя к ППУ | Если приложения СППУ и ППУ установлены на одном устройстве, то перенаправление должно вызывать приложение ППУ только в целях аутентификации (без дополнительных экранов интерфейса). |
| 5 | ППУ | Представляет информацию о платеже для авторизации | В интерфейсе ППУ должны отображаться как минимум Сумма платежа, Валюта и Имя наименование счета получателя, чтобы Пользователь знал об этих деталях (если не применяется исключение строгой аутентификации). Эти данные должны отображаться без введения дополнительных экранов подтверждения, как часть процесса аутентификации, на одном из следующих экранов: - Экран аутентификации (рекомендуется); - Экран перенаправления с ППУ на СППУ. |
| 6 | ППУ | Аутентификация Пользователя в ППУ | Аутентификация Пользователя в приложении ППУ должна осуществляться за аналогичное прямому доступу число шагов и предлагать те же методы аутентификации. После аутентификации Пользователь должен быть связан с приложением ППУ. |
| 7 | ППУ | Указывает статус состояния запроса и информирует о перенаправлении к СППУ | ППУ должен отображать на экране перенаправления состояние запроса и информировать Пользователя, что он будет автоматически возвращен в СППУ. |
| 8 | ППУ | Извещает о закрытии сессии | ППУ должен сообщать Пользователю о закрытии сессии. |
| 9 | СППУ | Подтверждение успешного инициирования платежа | Пользователь должен быть перенаправлен обратно на веб-сайт / в приложение СППУ на том же устройстве. СППУ должен отобразить подтверждение успешного инициирования платежа. |
Пример реализации интерфейса клиентского пути перенаправление в приложение ППУ для авторизации платежа в соответствии с описанным бизнес-процессом приведен на рисунке 24.
Рисунок 24 – Пример интерфейса клиентского пути перенаправление в приложение ППУ для авторизации платежа
¶ 5.2.2.5 Другие виды перенаправлений
Из приложения на веб-браузер ППУ
В случае, если Пользователь использует мобильное устройство, на котором отсутствует мобильное приложения ППУ, или ППУ не предоставляет мобильное приложение, то приложение Стороннего поставщика запускает нативный мобильный браузер для аутентификации Пользователя в ППУ посредством веб-доступа. При этом процессы клиентского пути будут аналогичны процессам перенаправления в приложение ППУ, за исключением того, что на стороне ППУ Пользователь использует аналогичный интерфейс в веб-браузере.
Из веб-браузера в приложение ППУ
В случае доступа к Стороннему поставщику с помощью веб-браузера на мобильном телефоне и наличия на нем приложения ППУ:
- Сторонний поставщик вызывает приложение для аутентификации;
- После аутентификации Пользователь перенаправляется обратно в браузер Стороннего поставщика.
При этом процессы клиентского пути будут аналогичны процессам перенаправления в приложение ППУ, за исключением того, что на стороне Стороннего поставщика Пользователь использует аналогичный интерфейс в веб-браузере.
Если Пользователь использует отдельное устройство для доступа к Стороннему поставщику, то перенаправление Пользователя должно быть завершено на веб-соединении браузера ППУ. В таком случае, Пользователь должен использовать приложение ППУ для разъединённой аутентификации (подробнее в разделе 5.2.3).
¶ 5.2.3 Разъединенная аутентификация
В данном разделе представлены особенности клиентского пути авторизации платежей в зависимости от различных вариантов разъединённой аутентификации.
Метод разъединенной аутентификации Пользователя в ППУ предполагает использование отдельного вторичного устройства для аутентификации. Это позволит Пользователю использовать свой мобильный телефон для аутентификации с помощью биометрии и других методов, в том числе при взаимодействии с СППУ через отдельный терминал, такой как устройство торговой точки.
Данный метод так же может быть использован и при получении согласия доступа к информации о счете, где вместо платежной информации представляется кластер запрашиваемых данных (согласно разделу 3.1).
¶ 5.2.3.1 Разъединённая аутентификация с использованием статического идентификатора
В данной модели клиентского пути представлен процесс разъединённой аутентификации, в котором Пользователь предоставляет Стороннему поставщику свой статический идентификатор (набор данных, по которому ППУ может однозначно идентифицировать Пользователя, например - номер телефона), который Сторонний поставщик передает ППУ для идентификации Пользователя.
На диаграмме 15 представлен процесс разъединённой аутентификации с использованием статического идентификатора, а описание его шагов в таблице 22.
Диаграмма 15 – Разъединённая аутентификация с использованием статического идентификатора
Таблица 22 – Описание процесса клиентского пути Разъединённая аутентификация с использованием статического идентификатора
| № | Участник | Процесс | Описание |
|---|---|---|---|
| 1 | СППУ | Предоставляет выбор счета для оплаты | СППУ должен предоставлять Пользователю возможность выбрать (если счета были ранее сохранены) или ввести детали счета для оплаты. |
| 2 | СППУ | Предоставляет выбор устройства/канала аутентификации | СППУ должен представлять Пользователю поддерживаемые ППУ устройства/каналы для аутентификации (например, только через мобильное приложение ППУ) для определения способа проведения платежа. |
| 3 | СППУ | Запрашивает идентификатор Пользователя для ППУ | СППУ должен запрашивать у Пользователя идентификатор, который поддерживает ППУ. |
| 4 | СППУ | Информирует об использовании идентификатора | СППУ должен уведомить Пользователя, как этот идентификатор будет использоваться. |
| 5 | СППУ | Информирует об аутентификации в приложении ППУ | СППУ должен проинформировать Пользователя о необходимости аутентификации в приложении ППУ и авторизации исполнения платежа и отобразить на экране: - Сумму платежа; - Код валюты; - Наименование счета получателя. |
| 6 | ППУ | Аутентификация Пользователя в ППУ | Аутентификация Пользователя в приложении ППУ должна осуществляться за аналогичное прямому доступу число шагов и предлагать те же методы аутентификации. |
| 7 | ППУ | Извещает о закрытии сессии | После завершения процесса аутентификации мобильное приложение ППУ должно уведомить Пользователя о выходе из приложения, завершить сессию и уведомить Пользователя о необходимости продолжения процесса в приложении СППУ. |
| 8 | СППУ | Подтверждение успешного инициирования платежа | СППУ должен подтвердить успешное инициирование платежа. |
Пример реализации интерфейса клиентского пути Разъединённая аутентификация с использованием статического идентификатора в соответствии с описанным бизнес-процессом приведен на рисунке 25.
Рисунок 25 – Пример интерфейса клиентского пути Разъединённая аутентификация с использованием статического идентификатора
¶ 5.2.3.2 Разъединённая аутентификация с использованием уникального идентификатора, сгенерированного ППУ
В данной модели клиентского пути, на диаграмме 16, представлен процесс разъединённой аутентификации, в котором Пользователь предоставляет сгенерированный ППУ уникальный идентификатор для СППУ, который передается ППУ для идентификации Пользователя. Описание шагов процесса приведено в таблице 23.
Диаграмма 16 – Разъединённая аутентификация с использованием сгенерированного ППУ уникального идентификатора
Таблица 23 – Описание процесса клиентского пути Разъединённая аутентификация с использованием сгенерированного ППУ уникального идентификатора
| № | Участник | Процесс | Описание |
|---|---|---|---|
| 1 | СППУ | Предоставляет выбор счета для оплаты | СППУ должен предоставить Пользователю возможность выбрать (если счета были ранее сохранены) или ввести детали счета для оплаты. |
| 2 | СППУ | Предоставляет выбор устройства/канала аутентификации | СППУ должен представить Пользователю поддерживаемые ППУ устройства/каналы для аутентификации (например, только через мобильное приложение ППУ) для определения способа проведения платежа. |
| 3 | СППУ | Информирует об использовании идентификатора | СППУ должен оповестить Пользователя, как этот идентификатор будет генерироваться и как будет использоваться. |
| 4 | ППУ | Генерация уникального идентификатора | Пользователь должен использовать приложение ППУ для генерации уникального идентификатора, связанного с проводимым платежом. |
| 5 | СППУ | Сканирование идентификатора | Пользователь должен предоставить идентификатор СППУ (например, с помощью сканирования QR-кода) |
| 6 | ППУ | Информирует об авторизации платежа | ППУ должен информировать Пользователя в мобильном приложении в той же сессии, где генерировался код, о текущем запросе на платеж, предоставив информацию о платеже: - Сумму платежа; - Код валюты; - Наименование счета получателя. - Выбранный счет для оплаты |
| 7 | ППУ | Аутентификация Пользователя в ППУ | Аутентификация Пользователя в приложении ППУ должна осуществляться за аналогичное прямому доступу число шагов и предлагать те же методы аутентификации. |
| 8 | ППУ | Извещает о закрытии сессии | После завершения процесса аутентификации мобильное приложение ППУ должно уведомить Пользователя о выходе из приложения, завершить сессию и известить Пользователя о необходимости продолжения процесса в приложении СППУ. |
| 9 | СППУ | Подтверждение успешного инициирования платежа | СППУ должен подтвердить успешное инициирование платежа. |
Пример реализации интерфейса клиентского пути Разъединённая аутентификация с использованием сгенерированного ППУ уникального идентификатора в соответствии с описанным бизнес-процессом приведен на рисунке 26.
Рисунок 26 – Пример интерфейса клиентского пути Разъединённая аутентификация с использованием сгенерированного ППУ уникального идентификатора
¶ 5.2.3.3 Разъединённая аутентификация с использованием уникального идентификатора, сгенерированного Сторонним поставщиком
В данной модели клиентского пути, на диаграмме 17, представлен процесс разъединённой аутентификации, в котором Пользователь предоставляет сгенерированный СППУ уникальный идентификатор для ППУ, который передается ППУ для идентификации Пользователя через приложение ППУ по запросу от СППУ. Описание шагов процесса приведено в таблице 24.
Диаграмма 17 – Разъединённая аутентификация с использованием сгенерированного СППУ уникального идентификатора
Таблица 24 – Описание процесса клиентского пути Разъединённая аутентификация с использованием сгенерированного СППУ уникального идентификатора
| № | Участник | Процесс | Описание |
|---|---|---|---|
| 1 | СППУ | Предоставляет выбор счета для оплаты | СППУ должен предоставлять возможность Пользователю возможность выбрать (если счета были ранее сохранены) или ввести детали счета для оплаты. |
| 2 | СППУ | Предоставляет выбор устройства/канала аутентификации | СППУ должен представлять Пользователю поддерживаемые ППУ устройства/каналы для аутентификации (например, только через мобильное приложение ППУ) для определения способа проведения платежа. |
| 3 | СППУ | Генерация уникального идентификатора | СППУ должен предоставлять Пользователю идентификатор (например, QR-кода), сгенерированный для ППУ касательно данной операции и предоставлять инструкцию как его использовать в приложении ППУ. |
| 4 | ППУ | Сканирование идентификатора | Пользователь должен предоставлять идентификатор ППУ (например, с помощью сканирования QR-кода) |
| 5 | ППУ | Информирует об авторизации платежа | ППУ должен информировать Пользователя в мобильном приложении в той же сессии, где генерировался код, о текущем запросе на платеж, предоставив информацию о платеже: - Сумму платежа; - Код валюты; - Наименование счета получателя. - Выбранный счет для оплаты |
| 6 | ППУ | Аутентификация Пользователя в ППУ | Аутентификация Пользователя в приложении ППУ должна осуществляться за аналогичное прямому доступу число шагов и предлагать те же методы аутентификации. |
| 7 | ППУ | Извещает о закрытии сессии | После завершения процесса аутентификации мобильное приложение ППУ должно уведомить Пользователя о выходе из приложения, завершить сессию и уведомить Пользователя о необходимости продолжения процесса в приложении СППУ. |
| 8 | СППУ | Подтверждение успешного инициирования платежа | СППУ должен подтвердить успешное инициирование платежа. |
Пример реализации интерфейса клиентского пути Разъединённая аутентификация с использованием сгенерированного Сторонним поставщиком уникального идентификатора в соответствии с описанным бизнес-процессом приведен на рисунке 27.
Рисунок 27 – Пример интерфейса клиентского пути Разъединённая аутентификация с использованием сгенерированного CППУ уникального идентификатора
¶ 5.2.3.4 Разъединённая аутентификация с использованием учетных данных Пользователя у Стороннего поставщика
На диаграмме 18 представлен процесс разъединённой аутентификации, в котором Сторонний поставщик предоставляет ППУ сохраненный идентификатор Пользователя, сгенерированный ППУ в предыдущей транзакции Пользователя. Данный идентификатор используется ППУ при уведомлении Пользователя о том, что он может аутентифицироваться с помощью приложения ППУ на отдельном устройстве. Эта модель используется в тех случаях, когда услуги, предлагаемые СППУ, включают платежные терминалы, телефонию, когда взаимодействие Пользователя со Сторонним поставщиком невозможно через графический интерфейс (например - устройства IoT), или когда Пользователь не представлен в потоке взаимодействия со Сторонним поставщиком. Описание шагов процесса приведено в таблице 25.
Диаграмма 18 – Пример интерфейса клиентского пути Разъединённая аутентификация с использованием учетных данных Пользователя у Стороннего поставщика
Таблица 25 – Описание процесса клиентского пути Разъединённая аутентификация с использованием учетных данных Пользователя у Стороннего поставщика
| № | Участник | Процесс | Описание |
|---|---|---|---|
| 1 | СППУ | Использование учетных данных для инициации платежа | СППУ (например - IoT устройство через голос) должен информировать Пользователя о необходимости подтверждения инициированного платежа, используя хранящиеся в нем учетные данные Пользователя (например, номер счета в ППУ для оплаты). После подтверждения со стороны Пользователя СППУ должен использовать учетные данные Пользователя для взаимодействия с ППУ в процессе инициализации платежа. |
| 2 | ППУ | Информирует об авторизации платежа | ППУ должен уведомить Пользователя в мобильном приложении о текущем запросе на платеж, предоставив информацию о платеже: - Сумму платежа; - Код валюты; - Наименование счета получателя. |
| 3 | ППУ | Аутентификация Пользователя в ППУ | Аутентификация Пользователя в приложении ППУ должна осуществляться за аналогичное прямому доступу число шагов и предлагать те же методы аутентификации. |
| 4 | ППУ | Извещает о закрытии сессии | После завершения процесса аутентификации мобильное приложение ППУ должно уведомить Пользователя о выходе из приложения, завершить сессию и известить Пользователя о необходимости продолжения процесса в приложении СППУ. |
| 5 | СППУ | Подтверждение успешного инициирования платежа | СППУ должен подтвердить успешное инициирование платежа. |
Пример реализации интерфейса клиентского пути Разъединённая аутентификация с использованием учетных данных Пользователя у Стороннего поставщика в соответствии с описанным бизнес-процессом приведен на рисунке 28.
Рисунок 28 – Пример интерфейса клиентского пути Разъединённая аутентификация использованием учетных данных Пользователя у Стороннего поставщика
¶ Приложение 1
Пример полного согласия Пользователя
СОГЛАСИЕ КЛИЕНТА НА ПЕРЕДАЧУ ДАННЫХ
Настоящим, (1)________________________(наименование клиента-ЮЛ) (далее - "Клиент") выражает согласие на передачу (2)_____________________________ (наименование кредитной организации), сведений (3)______________________(указывается тип передаваемой информации), а также об операциях по указанному счету за период с даты (4)______________________(указывается дата начала) по текущую дату третьему лицу (5)____________________________, ОГРН_____________ (указать наименование, ОГРН стороннего поставщика, которому предоставляется информация). Согласие дается на (6)_______________________ передачу данных и действует до (7) ______________. ИЛИ (7.1) Согласие на передачу данных действует до момента получения Банком письменного заявления (или отзыва в личном кабинете) клиента об отзыве настоящего согласия.
Согласие может быть отозвано Клиентом _______________________ (указать способ).
Клиент согласен, что Банк не несет ответственности за использование указанным третьим лицом полученной им конфиденциальной информации о счете Клиента и операциях по счету. Клиент принимает на себя все риски, связанные с использованием предоставляемой Банком указанному третьему лицу информации.