¶ Предисловие
ПРИНЯТ И ВВЕДЕН в действие приказом Банка России от _____ 2025 года
№ _______ «О введении в действие новых редакций стандартов Банка
России и стандарта Банка России».
Настоящий Стандарт не может быть полностью или частично воспроизведен,
тиражирован и распространен в качестве официального издания без
разрешения Банка России.
¶ Введение
Стандарт содержит общее описание элементов, которые являются общими для всех API на получение информации о счете Пользователя третьей стороной.
¶ Область применения
Стандарт рекомендован к использованию организациями при обмене финансовыми сообщениями, связанными с получением информации о банковском счете.
-
Стандарт предназначен для использования организациями при обмене сообщениями, связанными с получением информации о финансовых продуктах, счетах и других финансовых инструментах Пользователя, а также связанной с ними информации.
-
Настоящий стандарт предназначен для:
a. участников обмена информацией о финансовых продуктах, счетах и других финансовых инструментах Пользователя, а также связанной с ними информацией;
b. разработчиков информационного и программного обеспечения.
Положения настоящего стандарта применяются на добровольной основе, если только в отношении конкретных положений обязательность их применения не установлена нормативными актами Банка России или условиями договоров.
Положения настоящего стандарта применяются совместно со следующими документами:
- СТО БР ФАПИ.СЕК-1.6-2024 Стандарт Банка России "Безопасность финансовых (банковских) операций. Прикладные программные интерфейсы обеспечения безопасности финансовых сервисов на основе протокола OpenID" (далее ФАПИ.СЕК).
- СТО БР ФАПИ.ПАОК-1.0-2024 Стандарт Банка России "Безопасность финансовых (банковских) операций. Обеспечения безопасности финансовых сервисов при инициации OpenID Connect клиентом потока аутентификации по отдельному каналу" (далее ФАПИ.ПАОК).
- СТО БР Открытые программные интерфейсы. Общие положения.
- СТО БР Открытые программные интерфейсы. Глоссарий.
- СТО БР Открытые программные интерфейсы. Профили API для расширенного режима безопасности.
- СТО БР Открытые программные интерфейсы. Получение информации о счете Пользователя. Правила взаимодействия.
¶ Термины и определения
В Стандарте применяются термины и определения в соответствии со стандартами ФАПИ.СЕК, ФАПИ.ПАОК, «Открытые программные интерфейсы. Общие положения», «Открытые программные интерфейсы. Глоссарий», а также следующие:
| Наименование | Описание |
|---|---|
| Ресурс согласия | Объект данных, представляющий разрешение, предоставленное Пользователем (или субъектом данных) третьей стороне (СПУ) для доступа к определенным ресурсам или выполнения определенных действий от его имени. В контексте Открытых программных интерфейсов ресурс согласия является основным элементом, который управляет правами доступа и определяет, какие данные или операции разрешены. |
| Разрешение | Текстовая константа, уникально определяющая области данных и операции с этими данными, запрашиваемые СПУ для авторизации доступа. |
Таблица 1 - Термины и определения
¶ Общее описание процесса
В данном разделе описывается взаимодействие при получении информации о счете Пользователя третьей стороной через среду Открытых программных интерфейсов, которые позволяют СПУ:
- инициировать запрос на создание или отзыв ресурса согласия на доступ к счету;
- получать данные, связанные со счетом Пользователя.
¶ Пошаговое описание
Шаг 1 - Запрос информации по счету:
- Начало потока. Пользователь подтверждает СПУ намерение получать информацию о счете через среду Открытых программных интерфейсов и авторизовать согласие СПУ на доступ к своим данным, содержащую информацию о том, к каким данным Пользователь готов предоставить доступ, срок действия согласия и даты начала и окончания периода операций по счету, к которым относится данное согласие.
Шаг 2 - Настройка согласия на доступ к счету:
- Между СПУ и сервером авторизации ПУ устанавливается защищенный канал связи.
- СПУ, используя тип доступа client credentials, получает на сервере авторизации ПУ токен доступа (access token).
- Между СПУ и сервером ресурсов ПУ устанавливается защищенный канал связи.
- СПУ с помощью запроса POST, используя токен доступа для авторизации, инициирует создание на сервере ресурсов ПУ новый ресурс согласия на доступ к счету. Это действие информирует ПУ о том, что один из его Пользователей намерен получать информацию, относящуюся к его счету, через СПУ. ПУ передает в ответе СПУ информацию о создании ресурса согласия на доступ к счету с идентификатором consentId.
- Для одного и того же СПУ может одновременно существовать несколько действующих согласий от одного Пользователя. Каждое такое согласие создается в результате отдельного, независимого процесса авторизации и может иметь разные параметры (например, разный набор счетов или разрешений).
Шаг 3 - Авторизация согласия:
- Для авторизации согласия Пользователь сначала перенаправляется к ПУ. СПУ инициирует процесс авторизации путем перенаправления Пользователя на интерфейс ПУ.
Для этого ПУ может использовать гибридный поток в соответствии с профилем, определенным в документе СТО БР Открытые программные интерфейсы. Профили API для расширенного режима безопасности или созданием потока аутентификации по отдельному каналу (в соответствии с профилем безопасности OpenID API, обозначенному в положениях ФАПИ.ПАОК. - В случае, если СПУ выполняет запрос на авторизацию согласия, используя поток перенаправления для переадресации конечного Пользователя к ПУ:
- в потоке перенаправления СПУ перенаправляет Пользователя в интерфейс ПУ;
- перенаправление содержит consentId, созданный на предыдущем шаге, что позволяет ПУ в последствии идентифицировать согласие на доступ к счету;
- ПУ аутентифицирует Пользователя;
- Пользователь выбирает счета, по которым будет производиться обмен информацией со СПУ;
- Пользователь, пройдя аутентификацию на стороне ПУ, знакомится с параметрами согласия и явно подтверждает (авторизует) его.
- ПУ обновляет статус ресурса согласия на доступ к счету, фиксируя, что согласие было авторизовано;
- По завершению авторизации согласия, Пользователь перенаправляется обратно к СПУ с кодом авторизации (authorization code), а код авторизации передаётся СПУ системой ПУ;
- между СПУ и сервером авторизации ПУ устанавливается защищенный канал связи;
- СПУ использует тип доступа authorization code и обменивает на сервере авторизации ПУ код авторизации (authorization code) на токен доступа (access token), который связан с авторизованным согласием на доступ к счету (разрешение на доступ, связанное с согласием).
- В случае, если ПУ запрашивает аутентификацию у Пользователя на устройстве аутентификации, отличном от устройства потребителя, на котором Пользователь взаимодействует со СПУ (поток аутентификации по отдельному каналу):
- СПУ инициирует аутентификацию Пользователя с помощью запроса аутентификации по отдельному каналу;
- запрос содержит подсказку, которая идентифицирует Пользователя, связанного с авторизуемым согласием;
- ПУ аутентифицирует Пользователя и обновляет статус ресурса согласия на доступ к счету (account-consent), фиксируя, что согласие было авторизовано;
- как только согласие было авторизовано, ПУ может сделать обратный вызов для передачи результатов авторизации (auth_req_id) или использовать режим опроса для получения токена доступа (access-token), который связан с авторизованным согласием на доступ к счету (разрешение на доступ, связанное с согласием).
- В данном потоке предполагается, что управление согласием производится между Пользователем и СПУ, поэтому на этом этапе не могут изменяться детали согласия на доступ к счету. Пользователь может только полностью авторизовать или отклонить данные о согласии на доступ к счету.
- При успешной авторизации Согласия ПУ информирует ПКС (с момента запуска ПКС в промышленную эксплуатацию и принятия необходимых нормативно-правовых актов).
Шаг 4 - Запрос данных:
- Между СПУ и сервером ресурсов ПУ устанавливается защищенный канал связи.
- СПУ, используя для авторизации полученный на шаге 3 токен доступа, при помощи вызова GET /accounts получает идентификаторы счета Пользователя, к которым предоставлен ему доступ (accountId) и выполняет запросы к серверу ресурсов ПУ для получения информации о счете Пользователя.
¶ Диаграмма последовательности
На рисунке 1 представлена диаграмма последовательности потока получения информации о счете
Рисунок 1 - Диаграмма последовательности потока получения информации о счете
¶ Альтернативные потоки и потоки с ошибками
¶ Токен доступа отсутствует или просрочен
Этот поток предполагает, что следующие шаги были успешно выполнены:
- Шаг 1. Запрос информации по счету.
- Шаг 2. Создание согласия на доступ к счету.
- Шаг 3. Авторизация согласия.
В случае предоставления от СПУ в адрес ПУ просроченного или отсутствующего токена доступа в попытке запросить данные, ПУ отвечает ошибкой HTTP 401 (Unauthorized).
Рисунок 2 - Токен доступа отсутствует или просрочен
¶ Неполная или некорректная полезная нагрузка запроса
Этот поток предполагает, что следующие шаги были успешно выполнены:
- Шаг 1. Запрос информации по счету.
- Шаг 2. Создание согласия на доступ к счету.
- Шаг 3. Авторизация согласия.
СПУ предоставляет неверно сформированный запрос или запрос с некорректной полезной нагрузкой к ПУ для согласия на доступ к счету. ПУ отвечает ошибкой HTTP 400 (Bad Request).
Рисунок 3 - Неполная или не корректная полезная нагрузка запроса
¶ Отсутствует или не действительна область применения токена доступа
Этот поток предполагает, что следующие шаги были успешно выполнены:
- Шаг 1. Запрос информации по счету.
- Шаг 2. Создание согласия на доступ к счету.
- Шаг 3. Авторизация согласия.
СПУ предоставляет (действительный) токен доступа, который не имеет допустимой области применения или ссылки на правильные разрешения для запроса данных. ПУ отвечает ошибкой HTTP 403 (Forbidden).
Рисунок 4 - Отсутствует или не действительна область применения токена доступа
¶ Недопустимая множественность вызовов API
Этот поток предполагает, что следующие шаги были успешно выполнены:
- Шаг 1. Запрос информации по счету.
- Шаг 2. Создание согласия на доступ к счету.
- Шаг 3. Авторизация согласия.
СПУ предоставляет (действительный) токен доступа, который используется для генерации пакета из нескольких запросов на получение подробной информации о счете. ПУ возвращает ответ 429 (Too Many Requests).
Рисунок 5 - Недопустимая множественность вызовов API
¶ Ошибка авторизации согласия
Этот поток предполагает, что следующие шаги были успешно выполнены:
- Шаг 1: Запрос информации по счету.
- Шаг 2. Создание согласия на доступ к счету.
- Шаг 3. Авторизация согласия не выполняется из-за того, что Пользователь предоставил недопустимые учетные данные для ПУ или отказался предоставить доступ к счету для СПУ, в результате чего код авторизации не создается.
Рисунок 6 - Ошибка авторизации согласия
¶ Ресурс согласия
¶ Состояние ресурса согласия
Состояние ресурса согласия на доступ к счету определяется кодом его статуса, который может иметь следующие значения:
| Значение | Описание |
|---|---|
| AwaitingAuthorisation | Ресурс согласия ожидает авторизации пользователя |
| Rejected | Ресурс согласия был отклонен |
| Authorised | Ресурс согласия был успешно авторизован |
| Revoked | Ресурс согласия был отозван |
Таблица 2 - Состояния ресурса согласия на доступ к счету
Изменение состояний ресурса согласия на доступ к счету соответствует следующей модели:
Рисунок 7 - Диаграмма изменения состояний Ресурса согласия на доступ к счету
После того, как Пользователь авторизовал согласие, ПУ изменяет статус ресурса на “Authorised”.
При отклонении согласия Пользователем, ПУ изменяет статус ресурса согласия на “Rejected”.
После того, как Пользователь отозвал ресурс согласия, ПУ изменяет статус ресурса на “Revoked”.
¶ Срок действия согласия
expirationDateTime является необязательным полем, которое определяет срок истечения действия согласия для СПУ на доступ к данным Пользователя в ПУ.
expirationDateTime применяется ко всем разрешениям (кластерам данных), которые находятся в массиве ресурса согласия при его авторизации.
expirationDateTime определяет дату и время окончательного истечения срока действия согласия. По наступлении этой даты согласие не может быть возобновлено.
Для осуществления доступа к данным в течение всего срока действия согласия необходимо наличие активной авторизации, которая требует периодического подтверждения со стороны Пользователя.
¶ Начальная/конечная дата доступа к операциям по счету
TransactionToDateTime и TransactionFromDateTime определяют согласие Пользователя на доступ к операциям по счету в определенный период времени. Оба поля являются необязательными, и одно поле может быть указано без другого.
ПУ может ограничить доступ к операциям по счету за рамками указанного временного периода, при запросах к ресурсам, содержащих информацию об операциях по счету.
¶ Авторизация согласия
СПУ создает ресурс согласия на доступ к счету с помощью метода POST и получения доступа client credentials. Этот ресурс определяет разрешения (permissions) к кластерам данных, которые присылает СПУ от имени Пользователя. На начальном этапе согласие не авторизовано, поскольку ПУ еще его не актуализировал и не авторизовал во взаимодействии непосредственно с самим Пользователем.
ПУ отвечает сообщением, которое содержит идентификатор ресурса согласия consentId. Далее этот идентификатор используется при инициации доступа authorization code, который нужен для подтверждения Пользователем разрешений.
Во время получения доступа authorization code:
- ПУ аутентифицирует Пользователя.
- ПУ предоставляет ресурс согласия, полученный от СПУ, Пользователю для непосредственной авторизации его на стороне ПУ. Пользователь может авторизовать или отклонить согласие.
- ПУ предоставляет Пользователю список доступных счетов, для предоставления информации СПУ.
- Пользователь выбирает хотя бы один счет из списка и подтверждает авторизацию предоставления информации СПУ.
Согласие на доступ к счету считается авторизованным, если Пользователь выбрал хотя бы один счет и подтвердил авторизацию согласия.
¶ Повторная авторизация согласия
Повторная авторизация Согласия - опциональный механизм, предназначенный для перевыпуска токенов для действующего Согласия в результате утери или истечения срока токенов. Данный процесс инициируется через повторную аутентифкация Пользователи и не предполагает создание нового Ресурса согласия или изменения его параметров. При этом параметр consentId не изменяется.
¶ Инициация повторной аутентификации Пользователя
СПУ может запросить у Пользователя аутентификацию для повторной авторизации Согласия, находящегося в состоянии «Authorised» в любой момент времени. Это может быть выполнено как до, так и после истечения срока действия базовых токенов. ПУ может принимать данные запросы от СПУ. После успешной повторной аутентификации согласия СПУ не должен использовать токены доступа и токены обновления, которые ранее были выпущены для этого согласия. Когда ПУ выдает новый токен доступа и токен обновления в результате повторной аутентификации согласия, он должен аннулировать ранее выпущенные токен доступа и токены обновления для этого согласия.
¶ Ограничения клиентского пути
При повторной авторизации Согласия Пользователь не должен изменять параметры Согласия (выбранные счета, разрешения и даты), клиентский путь должен быть ограничен только аутентификацией Пользователя и подтверждением Согласия.
¶ Поведение при потерянном токене обновления
Если Согласие уже авторизовано, а токен обновления утерян или более не действителен, то необходимо повторно авторизовать Согласие без создания нового Ресурса согласия.
¶ Отзыв согласия
Пользователь может отозвать согласие на доступ к счету в любой момент времени.
Пользователь может отозвать авторизацию ресурса согласия напрямую на стороне ПУ. Механизмы реализации данного процесса и процессов, связанных с отзывов токенов определяется при разработке сервера авторизации ПУ. Если Пользователь отозвал согласие на доступ к счету на стороне ПУ, то статус ресурса account-consents меняется на «Revoked».
Пользователь может инициировать отзыв согласия на стороне СПУ. Если согласие будет отозвано на стороне СПУ:
- СПУ перестает обращаться к API с этого момента.
- СПУ может выполнить операцию DELETE для ресурса account-consent (до подтверждения отзыва согласия Пользователя), для информирования ПУ об отзыве согласия.
- либо СПУ может осуществить редирект Пользователя к ПУ для отзыва согласия.
Также согласие может быть отозвано на стороне ПУ через редирект к ПУ.
ПУ информирует ПКС об отзыве Согласия (с момента запуска ПКС в промышленную эксплуатацию и принятия необходимых нормативно-правовых актов).
¶ Удаление недоступных счетов из согласия
Пользователь выбирает счета, к которым применяется согласие в момент авторизации согласия.
В случае, если счет, к которому дано согласие, перестает быть доступен для Пользователя, данный счет удаляется из списка предоставления доступа, но при этом ПУ не отменяет доступ СПУ к другим счетам, связанным с тем же авторизированным согласием.
¶ Взаимодействие с ПКС
(Пункт применяется с момента запуска ПКС в промышленную эксплуатацию и принятия необходимых нормативно-правовых актов).
ПУ должен информировать ПКС об изменении статуса согласия в следующих случаях:
- При авторизации Согласия Пользователя на стороне ПУ, когда статус Согласия переходит в состояние «Authorised».
- При отзыве Согласия на стороне ПУ.
- При инициировании отзыва Согласия на стороне СПУ, когда статус Согласия переходит в состояние «Revoked».
ПУ должен получать от ПКС уведомление об инициировании отзыва Согласия и выполнять следующие действия, в том числе:
- устанавливать соответствующий статус для ресурса Согласия;
- удалять ресурс Согласия и связанные токены, если инициирование отзыва Согласия было выполнено на ПКС.
¶ Безопасность и контроль доступа
¶ Требование к профилю безопасности
Все взаимодействия при получении информации о счете Пользователя через среду Открытых программных интерфейсов должны соответствовать требованиям, определенным в стандарте СТО БР «Открытые программные интерфейсы. Профили API для расширенного режима безопасности», а также требованиям расширенного профиля безопасности OpenID API, определенным в ФАПИ.СЕК.
¶ Типы предоставления доступа
¶ Тип доступа client credentials
Для аутентификации клиента (СПУ) и получения токена доступа к Ресурсу согласия используется тип доступа client_credentials.
¶ Тип доступа authorization code
Для получения токена доступа к ресурсам Пользователя в рамках сценария с перенаправлением используется гибридный поток с типом доступа authorization_code.
Примечание: Ресурс согласия на доступ к счету не является ресурсом Пользователя.
¶ Информация для оценки рисков
Информация для оценки рисков будет доступна:
- В HTTP заголовках в соответствии с требованиями положения об обеспечении безопасности доступа к защищенным данным № СТО БР ФАПИ.СЕК-1.6-2024.