ГРАЖДАНСКОЕ ЗАКОНОДАТЕЛЬСТВО
ЗАКОНЫ КОММЕНТАРИИ СУДЕБНАЯ ПРАКТИКА
Гражданский кодекс часть 1
Гражданский кодекс часть 2

Стандарт Банка России Открытые банковские интерфейсы. Получение публичной информации о кредитной (принят и введен в действие приказом Банка России от 05.07.2021 N ОД-1365)

ЦЕНТРАЛЬНЫЙ БАНК РОССИЙСКОЙ ФЕДЕРАЦИИ
СТАНДАРТ БАНКА РОССИИ
ОТКРЫТЫЕ БАНКОВСКИЕ ИНТЕРФЕЙСЫ
ПОЛУЧЕНИЕ
ПУБЛИЧНОЙ ИНФОРМАЦИИ О КРЕДИТНОЙ ОРГАНИЗАЦИИ И ЕЕ ПРОДУКТАХ
Дата введения: 2021-07-08
Предисловие
ПРИНЯТ И ВВЕДЕН в действие приказом Банка России от 5 июля 2021 года N ОД-1365 "О введении в действие стандарта Банка России СТО БР "Открытые банковские интерфейсы. Получение публичной информации о кредитной организации и ее продуктах".
Настоящий Стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Банка России.
1. История изменений
Версия
Дата
Автор
Комментарий
2. Введение
Стандарт содержит описания модели данных и конечных точек API, предназначенные для передачи публичной информации через Открытые банковские интерфейсы.
2.1. Область применения
Стандарт рекомендован к использованию организациями при обмене сообщениями, связанными с получением:
- списка кредитных организаций;
- списка устройств кредитных организаций и привлеченных банковских платежных агентов (субагентов);
- списка офисов обслуживания кредитных организаций.
Стандарт предназначен:
- для участников получения публичной информации о кредитных организациях (кредитные организации и их клиенты);
- для разработчиков информационного и программного обеспечения, информационных систем.
2.2. Термины и определения
В Стандарте применяются следующие термины и определения:
Наименование
Описание
API (Application Programming Interface)
Набор процедур, протоколов и инструментов для создания программных приложений. API определяет, как программные компоненты должны взаимодействовать
Открытые банковские интерфейсы
Бесплатные и общедоступные интерфейсы прикладного программирования (API), которые предоставляют разработчикам программный доступ к лицензионному программному приложению
Публичные данные, публичная информация
Данные, к которым каждый может получить доступ, использовать их или делиться ими
Пользователь
Физическое или юридическое лицо, являющееся потребителем публичных данных
Хозяйствующий субъект
Коммерческая организация, некоммерческая организация, осуществляющая деятельность, приносящую ей доход, индивидуальный предприниматель, иное физическое лицо, не зарегистрированное в качестве индивидуального предпринимателя, но осуществляющее профессиональную деятельность, приносящую доход, в соответствии с федеральными законами на основании государственной регистрации и (или) лицензии, а также в силу членства в саморегулируемой организации
Сторонний поставщик
Хозяйствующий субъект, использующий Открытые банковские интерфейсы для доступа к публичным данным (при осуществлении роли СППД). Сторонний поставщик отправляет сообщения запроса через Открытые банковские интерфейсы ППД и получает соответствующие ответные сообщения от этого ППД
Поставщик публичных данных (ППД)
Кредитная организация, публикующая Открытые банковские интерфейсы для целей предоставления своих публичных данных
Сторонний поставщик публичных данных (СППД)
Сторонний поставщик, предоставляющий Пользователю услугу по получению публичных данных ППД в режиме реального времени
Среда Открытых банковских интерфейсов
Комплекс стандартов Открытых банковских интерфейсов, управление, системы, процессы, безопасность и процедуры, используемые для поддержки участников
Участники среды Открытых банковских интерфейсов
Пользователи, кредитные организации и иные субъекты финансового рынка, разработчики программного обеспечения, которые участвуют в создании и развитии среды Открытых банковских интерфейсов
Ресурс
Представление любой сущности (например, перевод денежных средств, счет, транзакция) в определенном формате (например, JSON). Каждый ресурс идентифицируется посредством постоянного идентификатора, который не меняется при изменении состояния ресурса
Полезная нагрузка
Часть пакета данных (сообщения) без служебной информации (без заголовка, битов синхронизации и т.п.). Детальное описание структуры полезной нагрузки представлено в разделе 5.2 "Общая структура полезной нагрузки"
3. Общие положения
Информационный обмен между ППД и СППД осуществляется посредством электронных сообщений, формируемых на стороне ППД и на стороне СППД посредством Открытых банковских интерфейсов.
Данный документ используется ППД для разработки интерфейсов, которые предоставляются СППД.
Данный документ используется СППД для реализации взаимодействий с ППД через Открытые банковские интерфейсы.
3.1. Принципы архитектуры
За основу создания среды Открытых банковских интерфейсов взят архитектурный стиль RESTful API <1>, что позволяет создавать простые и понятные для взаимодействия API.
--------------------------------
<1> Детальное описание подхода представлено на сайте https://restfulapi.net/.
3.2. Физический уровень описания сообщений
На физическом уровне при проектировании сообщений используется язык описания интерфейсов OpenAPI 3-й версии <2> в формате YAML <3>.
--------------------------------
<2> Детальное описание подхода представлено на сайте https://swagger.io/specification/.
<3> Детальное описание подхода представлено на сайте https://yaml.org/spec/1.2/spec.html.
3.3. Управление версиями API
Управление версиями API осуществляется согласно подходу Semantic Versioning 2.0.0 <4>.
--------------------------------
<4> Детальное описание подхода представлено на сайте https://semver.org/.
4. Основы
4.1. Предоставление доступа к ресурсу
Доступ к API предоставляется Пользователям посредством протокола HTTPS с использованием криптостойких алгоритмов TLS не ниже версии 1.2 без ограничений и необходимости авторизации.
ППД должен ограничить количество успешных обращений к API в течение определенного периода для защиты от распространенных типов атак безопасности, таких как атаки отказа в обслуживании (DOS), а также регулировать трафик в соответствии с доступностью инфраструктуры.
4.2. Кодировка символов
Запросы и ответы API должны использовать кодировку UTF-8. Это кодировка символов по умолчанию для JSON (RFC 7158, раздел 8.1).
В случае наличия в сообщениях символов, которые не могут быть обработаны, ППД отклоняет сообщение с кодом состояния HTTP 400 (Bad Request).
4.3. Формат даты
ППД должен принимать в запросах все действующие форматы даты стандарта ISO 8601, включая его разрешенные вариации.
Все даты в полезных нагрузках JSON представлены в формате date-time стандарта ISO 8601. Все поля date-time в ответах должны включать часовой пояс. Например:
2019-07-08T11:23:03+00:00
2019-05-03T18:13:23Z
Все даты в параметрах query должны быть в формате date-time стандарта ISO 8601 и должны включать часовой пояс. Например:
2019-07-01T09:23:01+03:00
Все даты в заголовках HTTP представлены как полные даты RFC 7231. Например:
Mon, 26 Aug 2019 14:23:51 GMT +03:00
4.4. URI структура пути ресурса
Путь ресурса URI должен соответствовать следующей структуре:
[participant-path-prefix]/open-banking/[version]/[resource-group]/[resource]/[resource-id].
URI структура пути ресурса состоит из следующих элементов:
- [participant-path-prefix] - необязательный префикс ППД;
- open-banking - постоянное значение "open-banking";
- [version] - версия API, выраженная в виде /v[major-version].[minor-version]/;
- [resource-group] - идентификатор группы конечных точек, в соответствии с ролью участника;
- [resource]/[resource-id] - наименование ресурса и его идентификатор (например, /accounts/1112345678). ППД должен использовать один и тот же participant-path-prefix и host name для всех своих ресурсов.
Примеры:
https://bank.ru/oapi-channel/open-banking/od/v1.1/devices
https://bank.ru/oapi-channel/open-banking/od/v1.1/banks
https://bank.ru/oapi-channel/open-banking/od/v1.1/branches
4.4.1. Заголовки запросов
Таблица 1. Заголовки запросов
Параметр header
Комментарий
GET-запрос
x-fapi-customer-ip-address
IP-адрес Пользователя, если Пользователь в данный момент подключен к СППД (залогинен в приложении СППД)
Необязательно
x-fapi-interaction-id
RFC 4122 UID, используемый в качестве идентификатора корреляции.
Если необходимо, ППД должен передавать обратно значение идентификатора корреляции в заголовке ответа x-fapi-interaction-id
Необязательно
Content-Type
Стандартный заголовок HTTP. Представляет формат полезной нагрузки в запросе. Должно быть установлено значение application/json.
СППД может предоставлять дополнительную информацию.
Если установлено другое значение, ППД должен прислать ответ: 415 Unsupported Media Type
Не используется
Accept
Стандартный HTTP-заголовок, определяющий тип контента, который требуется от сервера.
Если СППД ожидает незашифрованный ответ, он должен указывать явно, что только ответ в формате JSON принимается (передавая значение application/json) в качестве заголовка контента для всех конечных точек, которые отвечают в формате JSON.
Для конечных точек, которые не отвечают в формате JSON, ППД должен указать доступные параметры на своем портале для разработчиков.
СППД может предоставлять дополнительную информацию.
Если установлено недопустимое значение, ППД должен ответить: 406 (Not Acceptable).
Если значение не указано, по умолчанию используется application/json
Необязательно
x-customer-user-agent
В заголовке указывается тип устройства (user-agent), который использует Пользователь.
СППД может заполнить это поле значением типа устройства (user-agent), указанным Пользователем.
Если Пользователь использует мобильное приложение Стороннего поставщика, СППД должен убедиться, что строка типа устройства (user-agent) отличается от строки типа устройства (user-agent) на основе браузера
Необязательно
4.4.2. Заголовки ответов
Таблица 2. Заголовки ответов
Параметр header
Комментарий
Обязательность
Content-Type
Стандартный параметр заголовка HTTP. Представляет формат полезной нагрузки, возвращаемой в ответе.
ППД должен возвращать значение Content-Type, равное application/json
Обязательно
Retry-After
Параметр заголовка, указывающий время (в секундах), в течение которого СППД должен ждать перед повторением операции.
ППД следует включать этот заголовок вместе с ответами с кодом состояния HTTP 429 (Too Many Requests)
Необязательно
x-fapi-interaction-id
RFC 4122 UID, используемый в качестве идентификатора корреляции.
ППД должен заполнять параметр заголовка ответа x-fapi-interaction-id значением, полученным в соответствующем параметре заголовка запроса, или значением UID RFC 4122, если значение не было предоставлено в запросе для отслеживания взаимодействия
Обязательно
4.5. Коды статусов HTTP
Ниже приведены коды ответов HTTP для различных методов HTTP для всех конечных точек API.
Таблица 3. Коды статусов HTTP
Ситуация
Статус HTTP
Комментарий
POST
GET
DELETE
PUT
Запрос успешно выполнен
200 OK
Метод PUT должен быть определен на возврат обновленного ресурса. Следовательно, код 200 должен приходить
Нет
Да
Нет
Да
Операция создания выполнена успешно
201 Created
Результатом операции является создание нового ресурса
Да
Нет
Нет
Нет
Операция удаления успешно завершена
204 No Content
Нет
Нет
Да
Нет
Запрос имеет неверный формат, отсутствующие или несовместимые тело JSON, параметры URL или поля заголовка
400 Bad Request
Запрошенная операция не будет выполнена
Да
Да
Да
Да
СППД пытается получить ресурс, который указан в спецификации, но не реализован на стороне ППД (например, ППД решил не реализовывать конечную точку API-статуса для внутренних запланированных платежей).
СППД пытается получить ресурс, который не определен
404 (Not Found)
Да
Да
Да
Да
СППД попытался получить доступ к ресурсу с помощью метода, который не поддерживается
405 Method Not Allowed
Да
Да
Да
Да
Запрос содержал параметр заголовка Accept, отличный от разрешенных media types, и набор символов, отличный от UTF-8
406 Not Acceptable
Да
Да
Да
Да
Операция была отклонена, поскольку полезная нагрузка находится в формате, не поддерживаемом этим методом на целевом ресурсе
415 Unsupported Media Type
Да
Нет
Нет
Да
Время ожидания истекло
419 Request Timeout
Да
Да
Да
Да
Операция была отклонена, так как слишком много запросов было сделано в течение определенного периода времени
429 Too Many Requests
ППД могут ограничивать запросы, если они сделаны сверх их политики добросовестного использования.
ППД должны документировать свои политики добросовестного использования на своих порталах для разработчиков. ППД должны отвечать этим статусам, если количество запросов в единицу времени было превышено.
ППД следует включать заголовок Retry-After в ответ, указывающий, как долго СППД должен ждать перед повторением операции
Да
Да
Да
Да
Что-то пошло не так на стороне ППД
500 Internal Server Error
Операция не удалась
Да
Да
Да
Да
Устаревшая версия сервиса
503 Service Unavailable
Если API устарел и больше не поддерживается ППД, его путь URI все еще может быть активным и принимать запросы. В этом контексте рекомендуется вернуть 503 Service Unavailable, чтобы СППД знал, что версия API находится в офлайн-режиме
Да
Да
Да
Да
ППД может возвращать другие стандартные коды состояния HTTP (например, от шлюзов и других периферийных устройств), как описано в RFC 7231 (Раздел 6).
ППД должны отвечать на все некорректные запросы общей структурой ошибок Открытых банковских интерфейсов.
4.5.1. 400 (Bad Request) или 404 (Not Found)
Когда СППД пытается запросить URL ресурса с идентификатором ресурса, которого не существует, ППД должен ответить 400 (Bad Request), а не 404 (Not Found).
Например, если СППД пытается выполнить запрос GET/devices/22289, где 22289 не является действительным deviceld, ППД должен ответить 400.
Когда СППД пытается запросить URL ресурса, что приводит к тому, что бизнес-данные не возвращаются, ППД должен ответить 200 (ОК) и установить для массива значение "быть пустым".
Если СППД пытается получить доступ к URL-адресу для ресурса, который не определен этими спецификациями (например, GET/card-accounts), ППД может ответить 404 (Not Found).
Если ППД не реализовал конечную точку API, он должен ответить 404 (Not Found) для запросов к этому URL.
Таблица ниже иллюстрирует некоторые примеры предсказуемого поведения.
Таблица 4. Возможные ситуации для ответов 400 (Bad Request) и 404 (Not Found)
Ситуация
Запрос
Ответ
СППД пытается получить информацию об устройствах с неопределенным идентификатором deviceld
GET/devices/22289
400 (Bad Request)
СППД пытается получить ресурс, который указан в спецификации, но не реализован на стороне ППД. Например, ППД решил не реализовывать конечную точку API Кредитные организации
GET/banks
404 (Not Found)
СППД пытается получить ресурс, который не определен
GET/bulk
404 (Not Found)
4.5.2. 429 (Too Many Requests)
Когда СППД пытается получить доступ к ресурсу слишком часто, ППД может вернуть 429 (Too Many Requests). Это нефункциональное требование, и ППД должны определять метрику запросов в единицу времени.
Ситуация может возникнуть, когда СППД:
- решает реализовать функцию "Устройства в реальном времени" для своих пользователей и делает это некорректно, опрашивая конечную точку методом GET.
4.6. Фильтрация
ППД должен обеспечивать ограниченную поддержку фильтрации для операций GET, которые возвращают множественные записи.
Параметры фильтра всегда разные для конкретного поля (полей) ресурса и следуют правилам/форматам, определенным в справочниках для ресурса.
Для параметров фильтра типа date-time значения должны соответствовать стандарту ISO 8601. Предполагается, что значения фильтра относятся к тому же часовому поясу, что и часовой пояс, в котором поддерживается ресурс.
4.7. Нумерация страниц
ППД может предоставлять постраничный ответ для операций GET, которые возвращают множественные записи.
В такой ситуации:
- если существует следующая страница записей ресурсов, ППД должен предоставить ссылку на следующую страницу ресурсов в поле ответа Links.next. Отсутствие следующей ссылки будет означать, что текущая страница является последней страницей результатов;
- если предыдущая страница записей ресурсов существует, ППД должен предоставить ссылку на предыдущую страницу ресурсов в поле ответа Links.prev. Отсутствие предыдущей ссылки указывает на то, что текущая страница является первой страницей результатов.
Для разбитых на страницы ответов ППД следует гарантировать, что количество записей на странице находится в разумных пределах - минимум 25 записей (кроме последней страницы, где больше нет записей) и максимум 1000 записей.
Дополнительно ППД может предоставлять:
- ссылку на первую страницу результатов в поле Links.first;
- ссылку на последнюю страницу результатов в поле Links.last;
- общее количество страниц в поле Meta.TotalPages.
ППД должен включать ссылку "self" на ресурс в поле Links.self, как описано в разделе "Ссылки".
Этот стандарт не определяет, каким образом параметры перелистывания страниц передаются ППД, и каждый ППД может использовать свои собственные механизмы для разбивки ответа.
Если исходный запрос от Стороннего поставщика включал параметры фильтра, разбитый на страницы ответ должен возвращать только те результаты, которые соответствуют фильтру.
5. Общая модель данных
5.1. Справочники и перечисления
Спецификации Открытых банковских интерфейсов содержат поля со справочными данными.
Справочники бывают двух видов:
- фиксированные;
- гибкие.
В случае использования фиксированных справочников все возможные значения будут задаваться статично в стандарте Открытых банковских интерфейсов.
В случае использования гибких справочников начальные возможные значения будут задаваться в стандарте Открытых банковских интерфейсов, но каждый ППД может динамично управлять ими, расширяя свои значения. Справочные значения, уникальные для ППД, могут в будущем включаться в список начальных возможных значений для гибких справочников.
И фиксированные, и гибкие справочники находятся в разделе "Справочники и перечисления".
5.2. Общая структура полезной нагрузки
В этом разделе дается обзор структуры верхнего уровня для полезных нагрузок Открытых банковских интерфейсов.
Данные, которые содержатся в разделе "Data", документируются для каждой отдельно взятой конечной точки API.
5.2.1. Структура запроса
Структура верхнего уровня для запросов Открытых банковских интерфейсов имеет следующий вид:
{
"Data": {
...
}
}
Data
Раздел "Data" содержит данные запроса для конкретного запроса API.
Структура этого элемента различается для каждой конечной точки API.
5.2.2. Структура ответа
Структура верхнего уровня для ответов Открытых банковских интерфейсов имеет следующий вид:
{
"Data": {
...
},
"Links" {
...
},
"Meta": {
...
}
}
В соответствии с принципом API RESTful полный ресурс должен быть воспроизведен как часть ответа.
В ответ включаются следующие дополнительные разделы высокого уровня:
- Links;
- Meta.
5.2.3. Структура ответа с ошибками
Структура ответов с ошибками Открытых банковских интерфейсов на чтение/запись имеет следующий вид:
{
"Code": "...",
"Id": "...",
"Message": "...",
"Errors": "...", [
{
"ErrorCode": "...",
"Message": "...",
"Path": "...",
"Url" : "..."
}
]
}
Диаграмма UML
Спецификация данных
Таблица 5. Детальное описание элементов ответа с ошибками
Наименование
Кратность
XPath
Подробное описание
Тип данных
Значение
Шаблон
OBErrorResponse
OBRUErrorResponse
Массив подробных кодов ошибок, сообщений и URL-адресов к документации для помощи в исправлении
OBRUErrorResponse
Code
1..1
OBRUErrorResponse/Code
Высокоуровневый текстовый код ошибки, необходимый для классификации
Max40Text
Id
0..1
OBRUErrorResponse/Id
Уникальный идентификатор ошибки для целей аудита в случае неизвестных/неклассифицированных ошибок
Max40Text
Message
1..1
OBRUErrorResponse/Message
Краткое сообщение об ошибке. Например, "Что-то не так с предоставленными параметрами запроса"
Max500Text
Errors
1..n
OBRUErrorResponse/Errors
OBRUError
ErrorCode
1..1
OBRUErrorResponse/Errors/ErrorCode
Низкоуровневое текстовое описание ошибки. Например, RU.SBRF.Field. Missing
OBRUErrorResponseErrorCode
Message
1..1
OBRUErrorResponse/Errors/Message
Описание ошибки. Например, "Обязательное поле не указано"
MaxSOOText
Path
0..1
OBRUErrorResponse/Errors/Path
Путь к элементу с ошибкой в объекте JSON. Рекомендуемое, но не обязательное поле
Max500Text
Url
0..1
OBRUErrorResponse/Errors/Url
URL для помощи в устранении проблемы. Также через URL можно предоставлять дополнительную информацию
xs:anyURI
5.2.4. Необязательные поля
В объектах, где значение для необязательного поля не указано, поле должно быть исключено из полезной нагрузки JSON.
В объектах, где поле массива определено как имеющее значения 0..N, поле массива должно быть включено в полезную нагрузку с пустым массивом.
  {
        "Name": "",              // Неправильно. Поле "Name"
  нужно исключить из полезной нагрузки.
        "Age": 0,                // Неправильно.    Значение
  "0"  не  должно  использоваться для указания неопределенного
  возраста.
        "CreditorAccount": {},   // Неправильно.        Поле
  "CreditorAccount" нужно исключить.
        "Balances": []           // Правильно. Таким образом
  должен передаваться пустой массив.
  }
5.2.5. Ссылки
Раздел "Links" является обязательным и всегда будет содержать абсолютные URI для связанных ресурсов.
Ссылка "self" является обязательной.
"Links": {
"self": "https://api.bank.ru/open-banking/v3.1/payments/58923"
}
При передаче большого количества данных раздел "Links" может также содержать элементы first, prev, next и last.
"Links":
{
"self":
"http://rocks.ru/articles?page[number]=3&page[size]=25",
"first":
"http://rocks.ru/articles?page[number]=1&page[size]=25",
"prev":
"http://rocks.ru/articles?page[number]=2&page[size]=25",
"next":
"http://rocks.ru/articles?page[number]=4&page[size]=25",
"last":
"http://rocks.ru/articles?page[number]=6&page[size]=25"
}
5.2.6. Метаданные
Раздел "Meta" обязателен, но может быть пустым. Необязательный элемент TotalPages указывает на количество передаваемых страниц.
"Meta": {
"TotalPages": 6
}
5.3. Примеры использования
Примеры использования для отдельных API задокументированы на соответствующих страницах.
В этом разделе приведены примеры использования некоторых шаблонов.
5.4. Потоки с нумерацией страниц
Приведенный ниже пример иллюстрирует, как ППД может возвращать многостраничный ответ.
GET /accounts/34566/transactions НТТР/1.1
Authorization: Bearer Az567AOJtyue
x-fapi-auth-date: Mon, 2 Sep 2019 12:33:12 GMT +03:00
x-fapi-customer-ip-address: 10.5.412.45
x-fapi-interaction-id: 11bac543-d5de-3446-b687-880a5018434d
Accept: application/json
HTTP/1.1 200 OK
x-fapi-interaction-id: 11bac543-d5de-3446-b687-880a5018434d
Content-Type: application/json
{
"Data": {
...
},
"Links":
{
"self":
"https://bank.ru/open-banking/v1.0/devices",
"last":
"https://bank.ru/open-banking/v1.0/devices?pg=6",
"first":
"https://bank.ru/open-banking/v1.0/devices",
"next":
"https://bank.ru/open-banking/v1.0/devices?pg=2"
},
"Meta": {
"TotalPages": 6,
}
}
6. Кредитные организации, спецификация API
6.1. Конечные точки
Таблица 6. Конечные точки для ресурса "Кредитные организации"
Ресурс
Метод HTTP
Конечная точка
Параметры
Объект запроса
Объект ответа
banks
GET
GET/banks
BankResponse
6.1.1. GET/banks
Конечная точка должна использоваться для получения списка кредитных организаций участников среды Открытых банковских интерфейсов.
6.2. Модель данных
Объект BankResponse используется в ответах от конечных точек:
GET/banks.
6.2.1. Описание ресурсов
Ресурс представляет собой информацию о кредитных организациях.
Каждый ресурс кредитной организации должен иметь уникальный и неизменный идентификатор bankld.
6.2.2. Диаграмма UML
6.2.3. Состав данных объекта BankResponse
Таблица 7. Состав данных объекта BankResponse
Наименование
Кратность
Путь
Описание
Тип
Значение
Шаблон
BankResponse
BankResponse
BankResponseComplexType
Data
1..1
BankResponse/Data
DataBankResponseComplexType
Bank
0..N
BankResponse/Data/Bank
BankComplexType
bankld
1..1
BankResponse/Data/Bank/bankld
Идентификатор ресурса кредитной организации
Max35Text
bicfi
0..1
BankResponse/Data/Bank/bicfi
SWIFT bic
BICFIIdentifier
[A-Z0-9](4][A-Z]{2][A-Z0-9]{2}([A-Z0-9]{3}){0,1}
bic
0..1
BankResponse/Data/Bank/bic
БИК
BIKStaticType
clearingSystemMemberld
0..1
BankResponse/Data/Bank/clearingSystemMemberld
Идентификатор участника в платежной системе
Max35Text
baseUrl
1..1
BankResponse/Data/Bank/baseUrl
Базовый URL кредитной организации
Max35Text
bankName
1..1
BankResponse/Data/Bank/bankName
Наименование кредитной организации
Max140Text
bankNameEng
0..1
BankResponse/Data/Bank/bankNameEng
Наименование кредитной организации на английском языке
Max140Text
shortBankName
0..1
BankResponse/Data/Bank/shortBankName
Сокращенное наименование кредитной организации
Max35Text
bankDescription
0..1
BankResponse/Data/Bank/bankDescription
Детальное описание кредитной организации
Max255Text
legalEntityld
0..1
BankResponse/Data/Bank/legalEntityld
Код идентификации юридических лиц LEI
Max20Text
PostalAddress
1..1
BankResponse/Data/Bank/PostalAddress
PostalAddressComplexType
streetName
0..1
BankResponse/Data/Bank/PostalAddress/streetName
Название улицы
Max70Text
buildingNumber
0..1
BankResponse/Data/Bank/PostalAddress/buildingNumber
Номер здания
Max16Text
department
0..1
BankResponse/Data/Bank/PostalAddress/department
Номер корпуса здания
Max70Text
postCode
0..1
BankResponse/Data/Bank/PostalAddress/postCode
Почтовый индекс
Max16Text
townName
1..1
BankResponse/Data/Bank/PostalAddress/townName
Название населенного пункта
Max35Text
countrySubDivision
0..1
BankResponse/Data/Bank/PostalAddress/countrySubDivision
Название региона страны (например, область, край, республика)
Max35Text
countryчасовые
1..1
BankResponse/Data/Bank/PostalAddress/country
Название страны в кодированной форме
CountryCode
[A-Z]{2}
addressLine
0..7
BankResponse/Data/Bank/PostalAddress/addressLine
Информация, описывающая местонахождение и конкретный адрес в соответствии с правилами почтовой службы в свободной текстовой форме
Max70Text
7. Устройства, спецификация API
7.1. Конечные точки
Таблица 8. Конечные точки ресурса устройств
Ресурс
Метод HTTP
Конечная точка
Параметры
Объект запроса
Объект ответа
devices
GET
GET/devices
DevicesResponse
7.1.1. GET/devices
Конечная точка должна использоваться для получения списка устройств кредитной организации и привлеченных банковских платежных агентов (субагентов).
7.2. Модель данных
Объект DeviceResponse используется в ответах от конечных точек:
GET/devices.
7.2.1. Описание ресурсов
Ресурс представляет собой информацию о сети устройств кредитной организации и привлеченных банковских платежных агентов (субагентов).
Каждый ресурс устройства должен иметь уникальный и неизменный идентификатор deviceld.
7.2.2. Диаграмма UML
7.2.3. Состав данных объекта DeviceResponse
Таблица 9. Состав данных объекта DeviceResponse
Наименование
Кратность
Путь
Описание
Тип
Значение
Шаблон
DeviceResponse
DeviceResponse
DeviceResponseComplexType
Data
1..1
DeviceResponse/Data
DeviceDataResponseComplexType
Device
0..N
DeviceResponse/Data/Device
DeviceComplexType
deviceld
1..1
DeviceResponse/Data/Device/deviceld
operationType
1..N
DeviceResponse/Data/Device/operationType
Буквенные коды видов операций.
Справочное значение
OperationTypeStaticType
(Max2Text)
deviceType
1..1
DeviceResponse/Data/Device/deviceType
Тип устройства.
Справочное значение
DeviceTypeStaticType
(Max2Text)
nfc
1..1
DeviceResponse/Data/Device/nfc
Использование бесконтактной технологии:
- true - бесконтактные технологии используются;
- false - бесконтактные технологии не используются
xs:boolean
qr
1..1
DeviceResponse/Data/Device/qr
Возможность считывания QR-кодов (штрих-кодов) при совершении операций:
- true - QR-коды (штрих-коды) используются;
- false - QR-коды (штрих-коды) не используются
xs:boolean
recirculation
0..1
DeviceResponse/Data/Device/recirculation
Наличие функции рециркуляции банкнот:
- true - функция рециркуляции банкнот используется;
- false - функция рециркуляции банкнот не используется
xs:boolean
baseCurrency
1..1
DeviceResponse/Data/Device/baseCurrency
Основная валюта устройства.
Справочное значение
ActiveOrHistoricCurrencyCode
currencyln
0..N
DeviceResponse/Data/Device/currencyln
Все доступные валюты устройства при приеме. Справочное значение
ActiveOrHistoricCurrencyCode
banknoteTypeln
0..N
DeviceResponse/Data/Device/banknoteTypeln
Номинал купюр при приеме. Если массив пустой, то ограничений нет
xs:decimal
currencyOut
0..N
DeviceResponse/Data/Device/currencyOut
Все доступные валюты устройства при выдаче. Справочное значение
ActiveOrHistoricCurrencyCode
banknoteTypeOut
0..N
DeviceResponse/Data/Device/banknoteTypeOut
Номинал купюр при выдаче. Если массив пустой, то валюты нет в наличии
xs:decimal
cards
0..N
DeviceResponse/Data/Device/cards
Банковские карты, доступные для использования на данном устройстве.
Справочное значение
CardSchemeNameStaticType
(Max10Text)
currentStatus
1..1
DeviceResponse/Data/Device/currentStatus
Статус работоспособности устройства.
Справочное значение
DeviceCurrentStatusStaticType (Max10Text)
description
0..1
DeviceResponse/Data/Device/description
Дополнительная информация в свободной форме (например, наименование магазина, в котором установлено устройство, указание номера этажа, подъезда)
Max255Text
Address
1..1
DeviceResponse/Data/Device/Address
AddressComplexType
streetName
0..1
DeviceResponse/Data/Device/Address/streetName
Название улицы
Max70Text
buildingNumber
0..1
DeviceResponse/Data/Device/Address/buildingNumber
Номер здания
Max16Text
department
0..1
DeviceResponse/Data/Device/Address/department
Номер корпуса здания
Max70Text
postCode
0..1
DeviceResponse/Data/Device/Address/postCode
Почтовый индекс
Max16Text
townName
1..1
DeviceResponse/Data/Device/Address/townName
Название населенного пункта
Max35Text
countrySubDivision
0..1
DeviceResponse/Data/Device/Address/countrySubDivision
Название региона страны (например, область, край, республика)
Max35Text
country
1..1
DeviceResponse/Data/Device/Address/country
Название страны в кодированной форме
CountryCode
[A-Z]{2}
addressLine
0..7
DeviceResponse/Data/Device/Address/addressLine
Информация, описывающая местонахождение и конкретный адрес в соответствии с правилами почтовой службы в свободной текстовой форме
Max70Text
description
0..1
DeviceResponse/Data/Device/Address/description
Дополнительная информация в свободной форме. Например, место установки банкомата кредитной организации, позволяющее его идентифицировать (наименование магазина, в котором установлено устройство, указание номера этажа, подъезда)
Max255Text
oktmo
1..1
DeviceResponse/Data/Device/Address/oktmo
Цифровой код места нахождения банкомата (11 знаков) в соответствии с Общероссийским классификатором территорий муниципальных образований (ОКТМО).
Для стран - участников ЕАЭС поле заполняется значением константы EAEU
Max11Text
fias
1..1
DeviceResponse/Data/Device/Address/fias
Уникальный номер адреса объекта адресации (объектов недвижимости: земельного участка, здания (сооружения или объекта незавершенного строительства), помещения (расположенного в здании или сооружении) в Государственном адресном реестре федеральной информационной адресной системы (ФИАС). В случае отсутствия в ФИАС уникального номера адреса объекта адресации (при поиске такого номера для всех адресных элементов) в поле указывается уникальный номер адресообразующего элемента для последнего элемента улично-дорожной сети.
Для стран - участников ЕАЭС поле заполняется значением константы EAEU
Max255Text
Geolocation
0..1
DeviceResponse/Data/Device/Address/Geolocation
GeographicCoordinates
1..1
DeviceResponse/Data/Device/Address/Geolocation/GeographicCoordinates
latitude
1..1
DeviceResponse/Data/Device/Address/Geolocation/GeographicCoordinates/latitude
Широта
xs:decimal
longitude
1..1
DeviceResponse/Data/Device/Address/Geolocation/GeographicCoordinates/longitude
Долгота
xs:decimal
Services
1..1
DeviceResponse/Data/Device/Services
ServicesComplexType
Service
1..N
DeviceResponse/Data/Device/Services/Service
ServiceComplexType
serviceType
1..1
DeviceResponse/Data/Device/Services/Service/serviceType
Услуги, доступные на устройстве. Справочное значение
DeviceServiceTypeStaticType
(Max255Text)
description
0..1
DeviceResponse/Data/Device/Services/Service/description
Дополнительная информация в свободной форме
Max255Text
Availability
0..1
DeviceResponse/Data/Device/Availability
availabilitylndicator
1..1
DeviceResponse/Data/Device/Availability/isRestricted
Доступ к объекту ограничен системой пропуска и прочее
availabilitylndicatorStaticType
(Max1Text)
description
0..1
DeviceResponse/Data/Device/Availability/description
Дополнительная информация в свободной форме
Max255Text
StandardAvailability
1..1
DeviceResponse/Data/Device/Availability/StandardAvailability
Day
1..7
DeviceResponse/Data/Device/Availability/StandardAvailability/Day
dayCode
1..1
DeviceResponse/Data/Device/Availability/StandardAvailability/Day/dayCode
День недели. Справочное значение
WeekDayStaticType
openingTime
0..1
DeviceResponse/Data/Device/Availability/StandardAvailability/Day/openingTime
Время начала работы. Значение должно передаваться в формате "hh:mm:ss