Национальный банк Кыргызской Республики

Дата создания: 2025-08-04

Проект

Рекомендации по использованию единых стандартов

Открытых API

Глава 1. Общие положения

1. Настоящее рекомендации по использованию единых стандартов Открытых API (далее - рекомендации) разработаны с целью предоставления руководства рекомендательного характера для использования единых стандартов Открытых API.

2. Рекомендации определяют минимальные нормы в части безопасного обмена данными через Открытые API. Данные рекомендации могут быть использованы банками, операторами платежных системы, платежных организаций и другие небанковские финансовые организации, поднадзорные Национальному банку (далее - банк) в своей деятельности при использовании единых стандартов Открытых API для предоставления банковских и платежных услуг.

3. Для целей настоящих Рекомендаций используются следующие термины:

API (Application programming interfaces) – это набор процедур, протоколов и инструментов для создания программных приложений. API определяет, как должны взаимодействовать программные компоненты.

Многофакторная аутентификация – аутентификация, которая основана на использовании двух или более элементов, классифицированных как знания, владение и неотъемлемость. Эти пункты являются независимыми, поскольку нарушение одного не угрожает надежности других.

Открытые API – программные интерфейсы, предоставляющие возможность цифрового обмена данными на основе унифицированного стандарта API.

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

Поставщик платежных услуг по обслуживанию счетов (ASPSP) - это коммерческий банк, обслуживающий счет пользователя и публикующая Открытые API.

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

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

Согласие – согласие клиента на стороне поставщика API на обработку и передачу данных по банковским счетам между пользователем API и поставщиком API.

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

4. Участники Открытых API, указанные в пункте 2 настоящего Рекомендации осуществляют свою деятельность в системе в соответствии c требованиями законодательства, нормативных правовых актов Национального банка, настоящего Рекомендации, и в соответствии со следующими руководящими принципами:

- прозрачность и защита прав потребителей;

- безопасность и конфиденциальность данных пользователей;

- целостность данных;

- качество предоставляемых услуг через Открытых API;

- операционная совместимость между всеми участниками Открытых API.

Глава 2. Общие правила

5. Банки должны при внедрении Открытых API использовать единые стандарты API, предусмотренные приложением 1 и 2 настоящей Рекомендации, с уведомлением Национальный банк.

6. Платежные организации, операторы платежных систем и небанковские финансово-кредитные организации, поднадзорные Национальному банку, могут добровольно участвовать в использовании Открытых API при условии уведомления Национального банка.

7. Уведомление на использования единых стандартов Открытых API должен быть направлен Национальный банк за 15 дней до начала использования, и должно содержать следующие сведения:

- перечень услуг в рамках Открытых API, которые банк намерен предлагать;

- описание технических, операционных, управленческих механизмов и механизмов безопасности, связанных с предоставлением услуг в рамках Открытых API.

8. Участники Открытых API, являющиеся держателями данных должны предоставлять доступ к своим данным и счетам всем другим участникам на основе договорных условиях в соответствии с требованиями законодательства Кыргызской Республики.

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

Глава 3. Данные и услуги

10. В рамках использования единых стандартов Открытых API банк может включить доступность и обмен данными, касающиеся:

- банковские и другие расчетные счета, включая остатки и транзакции;

- местонахождение филиалов, сберегательных касс, банкоматов, POS-терминалов и других платежных и сервисных терминалов участников;

- банковские и платежные продукты и услуги.

11. В рамках использования единых стандартов Открытых API предусмотрены следующие услуги:

- 1) услуга инициирования платежа;

- 2) служба информации о счетах;

- 3) услуги сравнительной информации для банковских и финансовых продуктов и услуг;

- 4) услуги по поиску отделений, банкоматов, POS-терминалов и др.

12. Участники Открытых API не обязаны предоставлять информацию, не подлежащую раскрытию в соответствии законодательством или нормативными правовыми актами Национального банка.

13. Участники Открытых API при внедрение открытых банковских услуг должны внедрять стандарты Открытых API в соответствии с приложением 1 и 2 настоящей Рекомендации.

Глава 4. Обмен данными

14. Все запросы на обмен данными должны осуществляться через выделенные единых стандартов Открытых API, в соответствии с приложением 1 и 2 настоящей Рекомендации. Соответствующий участник Открытых API должен подтвердить свое согласие на обмен данными с запрашивающим участником. Это подтверждение должно включать согласие на обмен данными или отказ в обмене данными c обоснованием данного решения.

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

- исключительно для заявленных целей, связанных с предоставлением конкретной открытой банковской услуги;

- не включать в себя какие-либо данные или информацию, выходящие за рамки строго необходимых для предоставления соответствующей открытой банковской услуги;

- ограничено по сроку в соответствии с предоставлением соответствующей открытой банковской услуги. В случае, если конкретная открытая банковская услуга, такая как информация о счете, не ограничена по времени, согласие должно возобновляться не реже одного раза в 6 месяцев;

- пользователи могут отозвать и/или изменить свое согласие в любое время без необходимости дополнительного согласования с участником Открытых API.

16. Банк-получатель данных должен передать согласие пользователя, полученное в соответствии с пунктами 14 и 15 Рекомендации 2, соответствующему банку по передаче данных безопасным способом через интерфейсы.

17. Банк по передаче данных или, в случае услуги по инициированию платежа, учреждение по обслуживанию счетов должно применять процедуры и средства контроля для аутентификации:

- пользователь;

- банк, получающее данные, где это применимо, в том числе в случае услуг открытой банковской информации;

- участник, осуществляющий инициирование платежа.

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

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

20. Банк, осуществляющее передачу данных или обслуживающее счет, в зависимости от обстоятельств, обязано запросить у пользователя подтверждение перед передачей данных или инициированием платежа.

1) Подтверждение пользователя должно:

- происходить после процедур аутентификации;

- предоставить пользователю возможность отказаться от выполнения обмена данными или инициирования платежа;

2) В случаях обмена данными запрос на подтверждение со стороны банка, передающего данные, должен включать следующее:

- идентификация банка-получателя данных;

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

- тип запрашиваемых/предназначенных для совместного использования данных.

3) В случае инициирования платежа запрос на подтверждение со стороны обслуживающего счет банк должен включать следующее:

- размер платежа;

- информация, позволяющая идентифицировать получателя платежа; и

- дата исполнения платежа.

4) Подтверждение пользователем, как указано в настоящем разделе, может осуществляться совместно с аутентификацией пользователя.

Глава 5. Ответственность и урегулирование споров

21. Участники Открытых API несут ответственность перед своими пользователями за защиту персональных данных и предоставление услуг в соответствии требованиями законодательства и нормативных правовых актов Национального банка.

22. Процедуры и механизмы разрешения споров между участниками регулируется в соответствии с договором.

23. Все участники Открытых API должны создать соответствующие механизмы рассмотрения жалоб пользователей и разрешения споров между участниками и пользователями, возникающих в связи с предоставлением открытых банковских услуг.

Проект

Приложение 1 к рекомендации

по использованию единых

стандартов Открытых API

Единый стандарт API при инициировании платежей

1. Управление версиями

Версия	Дата	Описание
0.1	__	Первоначальный проект

2. Введение

В настоящем документе представлен стандарты API инициирования платежей, основанные на Руководстве по реализации, разработанном Берлинской группой [BGIG], а также OAuth 2.0, использующий взаимную проверку подлинности по TLS.

Основные принципы этого подхода изложены в приведенной далее таблице.

Принцип	Обоснование
Использование [BGIG] в случаях, когда это целесообразно и возможно	· Позволяет использовать существующие материалы стандартов из экосистемы открытого банкинга. · Эффективно используется существующая поддержка поставщикам и инструментальным средствам с открытым исходным кодом. · Обеспечивается поддержка рынка через онлайн-инструменты, обучающие программы и знания на основе искусственного интеллекта.
Использование потока кода авторизации OAuth 2.0	· Предоставляется привязанный к протоколу механизм для выполнения потоков авторизации. · Устраняются расхождения при внедрении на рынке. · Предоставляется структурная основа для будущей разработки Руководства по безопасности API [APISG], в идеале – для перехода к профилю безопасности FAPI 2.0 [FAPI2SP].
Упрощение существующего описания API и стандартов [BGIG] до минимума, необходимого для поддержки стандартов	· Обеспечивается фиксированное представление о требованиях к передаче данных.
Использование базовых стандартов у источника, где это возможно	· Эффективнее поддерживается адаптация на рынке. · Снижаются затраты на сопровождение этого документа по стандартам

3. Термины и определения

Акроним	Определение	Описание
ASPSP	Поставщик платежных услуг по обслуживанию счетов	Коммерческий банк, обслуживающий счет пользователя и публикующая Открытые API у себя на сайте и подключение к своей системе
PISP	Поставщик услуг по инициированию платежей	Юридическое лицо, предоставляющее пользователю услугу по инициированию перевода денежных средств.
TPP	Сторонний поставщик	Юридическое лицо, использующее Открытые API для доступа к банковскому счету пользователя для осуществления переводов денежных средств (платежей) (PISP)
PSU	Пользователь платежных услуг	Клиент-держатель счета, владеющий счетом и способный частично или полностью авторизовать доступ.
SCA	Надежная аутентификация (проверка подлинности) клиентов	Нормативное требование PSD2, используемое в настоящих стандартах для описания процесса проверки подлинности PSU в соответствии с правилами, определенными в настоящих стандартах.
TLS	Безопасность транспортного уровня	Распространенный механизм безопасности для защиты HTTP-соединений, используемый в открытых банковских экосистемах в качестве основы для защиты API.

4. Параметры

В приведенной далее таблице перечислены параметры высокого уровня, включенные в эти на верхнем уровне стандарты.

#	Параметры	Описание
	Инициирование разового платежа	Отправка разового платежа для немедленного исполнения по данному платежному средству, поддерживаемому экосистемой рынка. Перед исполнением платежа пользователь должен авторизовать его с помощью SCA. Координация запроса на инициирование платежа осуществляется ASPSP, который отвечает за подтверждение статуса авторизации SCA и исполнение платежа после получения информации о правильности статуса авторизации.
	Инициирование разового будущего платежа.	Отправка платежа с будущей датой, который должен быть исполнен в определенную дату ASPSP по определенному платежному средству, поддерживаемому экосистемой рынка. Платеж должен быть авторизован пользователем с помощью SCA, прежде чем он будет исполнен. Координация запроса на осуществление платежа возлагается на ASPSP, который отвечает за подтверждение статуса авторизации SCA и исполнение платежа после получения информации о правильности статуса авторизации.
	Инициирование периодического платежного поручения.	Создание периодического платежного поручения, по которому платежи будут исполняться в заданную дату ASPSP по заданному платежному средству, поддерживаемому экосистемой рынка. Перед исполнением платежа пользователь должен авторизовать его с помощью SCA. Координация запроса на исполнение периодического платежа возлагается на ASPSP, который отвечает за подтверждение статуса авторизации SCA и исполнение платежей после получения информации о правильности статуса авторизации

5. Поддерживаемые потоки

В настоящем стандарте приняты два потока, описанные в [BGIG], а именно перенаправленные и разделенные потоки.

Важно

· В этой версии OAuth 2.0 применяется ко всем операциям с использованием API. Потоки отражают требование о необходимости токена доступа, выданного на основе «Учетных данных клиента», для активирования операций по созданию платежа.

· В случае принятия [FAPI2SP] эти потоки будут изменены, чтобы включить в них запрос авторизации с широкими функциональными возможностями / Rich Authorization Request, осуществляемый с помощью отправляемого запроса авторизации / Pushed Authorization Request (PAR). Использование PAR отражает существенное изменение в подходе к безопасности API. Поэтому в данной версии поток показан без PAR.

5.1. Перенаправленный поток

Перенаправленный поток обеспечивает средствами для проверки подлинности PSU и авторизации доступа PSU к счету посредством перенаправления потока от PISP к ASPSP.

На приведенной ниже диаграмме представлен обзор этих потоков для разового платежа.

На шаге 1 согласие на данное платежное поручение согласовывается между PSU и PISP на основе требуемого платежного поручения и параметров платежа, который будет передан PISP.

Ответственность распределяется между PSU и PISP.

PSU должен:

· По выбору предоставить информацию о счете дебитора, с которого он хочет произвести платеж. Если информация о счете дебитора не указана, счет дебитора должен быть выбран в ASPSP.

· Предоставить информацию о кредиторе для таких случаев, как платежи от одного лица другому или иные аналогичные случаи использования, когда кредитор заранее не указан PISP.

· Там, где это необходимо, указываются суммы, даты и периодичность осуществления платежных поручений.

· Для случаев использования, когда допускается использование ссылки на платеж, установленной PSU, задать информацию о денежном переводе.

· Выбрать ASPSP, в котором будет исполняться платежное поручение и в котором будет открыт соответствующий счет.

PISP должен:

· Предоставить информацию о кредиторе для корпоративных платежей для таких случаев использования, как платежи продавцам за операции электронной торговли.

· При необходимости указывать суммы, даты и периодичность выполнения платежных поручений.

· Устанавливать информацию о денежном переводе для случаев использования, когда PISP предоставляет ссылку на платеж.

· Представить согласованные данные платежных поручений PSU для подтверждения.

· Разрешить PSU выбрать ASPSP, в котором будет исполняться платежное поручение.

· Позволить PSU подтвердить правильность платежных поручений перед выполнением последующих шагов.

5.1.2. Получение информации

PISP отвечает за извлечение информации для поиска целевого ASPSP до активирования операции `post /payments/{payment-product}`

PISP должен:

· Запросить информацию для поиска ASPSP по URL, опубликованному в реестре участников (для краткости не показан на схеме).

ASPSP должен:

· Отвечать корректной информацией для поиска, которая описывает информацию о сервере OAuth, включая такую информацию, как конечная точка авторизации, конечная точка токена и поддерживаемые диапазоны.

5.1.3. Создание платежного поручения

PISP будет выполнять действия с учетом информации для поиска и активировать операцию `post /payments/{payment-product}` в целевом ASPSP.

PISP должен:

· Создать платежное поручение, параметры которого совпадают с платежными реквизитами, согласованными с PSU на шаге 1.

· Запросить токен доступа у конечной точки токена ASPSP, используя вид разрешения «Учетные данные клиента».

· Отправить платежное поручение в ASPSP, выполнив команду `post /payments/{payment-product}`

ASPSP должен:

· Проверить клиента PISP OAuth:

o Проверить сертификат MTLS клиента.

· Проверить представленный идентификатор клиента и сопоставить его с представленным сертификатом MTLS клиента.

· Предоставить токен доступа авторизованным PISP, которые авторизованы в соответствии с открытой банковской системой НБКР.

· Проверить PISP OAuth и токен доступа клиента:

o Проверить сертификат MTLS клиента.

o Проверить, что токен доступа был предоставлен клиенту PISP OAuth на основе представленного сертификата MTLS клиента.

· Проверить параметры платежного поручения:

o Если указано, сравнить данные счета дебитора, чтобы убедиться, что счет действителен, активен и что по нему можно совершать платежи.

o Убедиться, что запрашиваемая информация о счете кредитора полная и что платеж может быть отправлен через запрашиваемый {payment-product}.

· Подразумеваемым образом создать `/{payment-service}/{payment-product}/{paymentId}/authorisations` на основе запрошенного платежного поручения.

· Ответить PISP соответствующим кодом отклика HTTP, указывающим на то, что платежное поручение было размещено в ASPSP.

5.1.4 Авторизация платежа

Авторизация платежа осуществляется через поток кода авторизации OAuth 2.0, в котором PISP перенаправляет PSU у ASPSP. ASPSP проводит проверку подлинности PSU, отображает платежное поручение и позволяет PSU подтвердить, что платежная информация верна и соответствует первоначальному поручению, согласованному между PSU и PISP.

Ответственность за этот этап разделяется между всеми сторонами.

PISP должен:

· Получить URL конечной точки авторизации из информации для поиска ASPSP.

· Создать URL-адрес перенаправления, совместимый с OAuth 2.0.

o Включить правильную область действия для обновления разрешения на проведение транзакции.

· Перенаправить PSU к ASPSP, чтобы запустить поток кода авторизации.

· Получить от ASPSP перенаправленный поток PSU, содержащий код авторизации.

ASPSP должен:

· Проверить перенаправление от PISP, убедившись в корректности параметров PISP OAuth 2.0 и запроса клиента.

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

· Получить платежное поручение, ранее отправленное PISP.

· Передать платёжное поручение в соответствии с Руководством по работе с клиентами [CXG].

· По желанию PSU может выбрать счет дебитора, если счет дебитора не был включен в платежное поручение.

· Позволить PSU подтвердить правильность платежного поручения в соответствии с рекомендациями, предписанными [CXG].

PSU должен:

· Следовать подсказкам для проверки подлинности в ASPSP с использованием соответствующих учетных данных.

· Проверить информацию о платеже, представленную ASPSP, чтобы убедиться, что она соответствует значениям, согласованным с PISP.

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

· Подтвердить ASPSP, что платежное поручение составлено правильно.

5.1.5 Исполнение и статус платежа

Платеж исполняется после завершения всех последующих шагов. Исполнение организовывается ASPSP на основе его интеграции с целевой платежной платформой. PISP будет сообщать о любых обновлениях.

ASPSP должен:

· Исполнить платежное поручение, подтвержденное PSU.

· Проверить OAuth PISP клиента:

o Проверить сертификат MTLS клиента.

o Проверить представленный идентификатор клиента и сравнить его с представленным сертификатом MTLS клиента.

· Проверить код авторизации и убедиться, что он был выдан запрашивающему PISP.

· Выдать токен доступа с правильной областью действия для проверки статуса платежа.

· Сделать информацию о статусе платежа доступной для получения PISP.

· По запросу статуса платежа от PISP проверить OAuth-PISP клиента и токен доступа:

o Проверить сертификат MTLS клиента.

o Проверить, что токен доступа был предоставлен OAuth PISP клиента на основе представленного сертификата MTLS клиента.

· Вернуть PISP информацию о статусе платежа.

PISP должен:

· Получить код авторизации из URL-адреса перенаправленного потока, отправленного ASPSP.

· Запросить токен доступа у ASPSP, используя код авторизации.

· Периодически узнавать статус платежа, выполнив API-операцию get /{payment-service}/{payment-product}/{paymentId}/status.

· При необходимости передавать информацию о статусе платежа PSU.

5.2. Разделенный поток

Разделенный поток позволяет PSU авторизовать платеж посредством потока, организованного ASPSP. Этот поток во многом повторяет перенаправленный поток, за исключением шага 4 «Авторизация платежа».

Важно

Инициируемая клиентом проверка подлинности по обратному каналу [CIBA] используется во многих открытых банковских экосистемах для реализации «Разделенного потока».

Если «Разделенный поток» будет сохранен в версии 1.0 стандартов, настоятельно рекомендуется использовать [CIBA], чтобы обеспечить механизм реализации, соответствующему протоколу.

Эти шаги представлены в приведенной ниже диаграмме.

Шаги изложены в следующих разделах.

5.2.1 Согласие на платежное поручение

Смотрите руководство по перенаправленному потоку.

5.2.2 Получение информации для поиска

Смотрите руководство по перенаправленному потоку.

5.2.3 Создание платежного поручения

Смотрите руководство по перенаправленному потоку.

5.2.4 Авторизация платежа

ASPSP уведомит PSU о том, что PSU должен разрешить платеж.

ASPSP должен:

· Уведомить PSU о том, что необходимо авторизовать платёжное поручение.

· Проверить подлинность перенаправленного потока PSU, используя его учетные данные для интернет- или мобильного банкинга, в соответствии с руководством по SCA.

· Получить платежное поручение, ранее отправленное PISP.

Передать платежное поручение в соответствии с рекомендациями, изложенными в Руководстве по работе с клиентами [CXG].

· По желанию разрешить PSU выбрать счет дебитора, если счет дебитора не был указан в платежном поручении.

· Разрешить PSU подтвердить правильность платежного поручения в соответствии с рекомендациями, предписанными [CXG].

· Обновить ресурс `/{payment-service}/{payment-product}/{paymentId}/ authorisations{authorisationId}` для отображения авторизации со стороны PSU и предоставления кода авторизации.

PSU должен:

· Следуя подсказкам, пройти аутентификацию в ASPSP, используя соответствующие учетные данные.

· Просматривать информацию о платеже, представленную ASPSP, чтобы убедиться в ее соответствии значениям, согласованным с PISP.

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

· Подтвердить ASPSP, что платежное поручение составлено правильно.

5.2.5 Исполнение и статус платежа

Платеж исполняется после завершения всех последующих шагов. Исполнение организовывается ASPSP на основе его интеграции с целевой платежной платформой.

PISP будет информировать PSU о состоянии платежа. Для получения информации о статусе платежа у PISP должен быть токен доступа, предоставленный с использованием кода авторизации, доступного посредством ресурса авторизации.

ASPSP должен:

· Исполнить платежное поручение, подтвержденное PSU.

· Проверить OAuth PISP клиента:

o Проверить сертификат MTLS клиента.

o Проверить представленный идентификатор клиента и сравнить его с представленным сертификатом MTLS клиента.

· Проверить код авторизации и убедиться, что он был выдан запрашивающему PISP.

· Выдать токен доступа с правильной областью действия для проверки статуса платежа.

· Подготовить информацию о статусе платежа для получения PISP.

· При запросе статуса платежа со стороны PISP проверить OAuth PISP клиента и токен доступа:

o Проверить сертификат MTLS клиента.

o Проверить, что токен доступа был предоставлен OAuth PISP клиенту на основе представленного сертификата MTLS клиента.

· Вернуть информацию о статусе платежа PISP.

PISP должен:

· Запросить операцию по авторизации PSU для завершения авторизации со стороны PSU.

· Получить код авторизации, выполнив операцию по авторизации PSU.

· Запросить токен доступа у ASPSP, используя код авторизации.

· Периодически запрашивать статус платежа, активируя операцию о статусе платежа.

· При необходимости передавать информацию о статусе платежа PSU.

6.1. Поддерживаемые операции API

В следующей таблице представлены операции, которые входят в сферу действия Стандартов по инициированию платежей для открытого банковского обслуживания, с дополнительными пояснениями по реализации в Кыргызской Республике. Каждая версия API помечается уникальным префиксом. Любые изменения, влияющие на совместимость (изменения структуры запроса/ответа, логики аутентификации и пр.), должны сопровождаться выпуском новой мажорной версии. Обязателен переходный период не менее 6 месяцев, в течение которого ASPSP обязан поддерживать обе версии.

Важно

· Оригинальное руководство из [BGIG] выделено курсивом для справки.

· Если условие отличается от [BGIG], то его значение выделено жирным шрифтом.

· Все поддерживаемые операции представлены отдельно в документе с описанием OpenAPI.

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

· Если значение заключено в фигурные скобки, например, {payment-service}, оно обозначает параметр, являющийся элементом URL. Определения этих значений приведены в документе с описанием OpenAPI.

· Если параметр обозначает идентификатор, например, {paymentId}, то ожидается, что это будет уникальный, непрозрачный идентификатор. Использование таких идентификаторов является обычным явлением в открытом банкинге и в REST API в целом.

№	Операция	Условие	Описание
	post/v1/{payment-service}/{payment-product}	Обязательное	Создает ресурс инициирования платежа, адресуемый по {paymentId}, со всеми данными, относящимися к соответствующему платежному продукту. Поддерживаются следующие значения {payment-service}: платеж и периодический платеж. Групповые платежи не поддерживаются. Единственным поддерживаемым значением {payment-product} будет {Элкарт} в версии 1.0. Все платежи отправляются с помощью платежной платформы Элкарт. В этих стандартах не поддерживается функция отклика scaOAuth. Информация об участниках будет извлекаться с помощью реестра участников, так как весь поток будет защищен с помощью OAuth 2.0 с взаимным TLS (mTLS), как указано выше.
2	get /v1/{payment-service}/{payment-product}/{paymentId}	Обязательное	Считывание данных об инициированном платеже
3	get /v1/{payment-service} /{payment-product}/{paymentId}/status	Обязательное	Считывание данных о статусе транзакции по осуществлению платежа
4	get /v1/{payment-service}/{payment-product}/{paymentId}/authorisations	Обязательное	Считывание списка всех созданных идентификаторов субресурсов авторизации.
5	get /v1/{payment-service}/{payment-product}/{paymentId}/authorisations/ {authorisationId}	Обязательное	Считывание SCA-статуса авторизации.
6	delete /v1/{payment-service}/{payment-product}/{paymentId}	Условное	Отмена адресованного платежа, если это применимо к платежной услуге и продукту. Эта операция поддерживается для тех видов платежей, для которых возможна отмена, а именно: · Разовый платеж, который не был авторизован. · Будущий платеж, который еще не осуществлен. · Периодический платеж. Эта операция не поддерживается для разовых платежей, которые уже авторизованы.
7	post /v1/{payment-service}/{payment-product}/{paymentId}/cancellation-authorisations	Не поддерживается	Запуск авторизации для отмены платежа. Эта операция не поддерживается, так как SCA не требуется для отмены платежа в этих стандартах. PISP может выступать от имени PSU для отмены платежа без дополнительной авторизации.
8	get /v1/{payment-service}/{payment-product}/{paymentId}/cancellation-authorisations	Не поддерживается	Получение списка всех созданных подресурсов для авторизации отмены. В соответствии с приведенным выше руководством эта операция не поддерживается.
9	get /v1/{payment-service}/{payment-product}/{paymentId}/cancellation-authorisations/{authorisationId}	Не поддерживается	Считывание информации о статусе SCA для выдачи разрешения на отмену. В соответствии с приведенным выше руководством эта операция не поддерживается.
10	delete /v1/consents/{consentsId}	Не поддерживается	Пользователь PSU может в любой момент отозвать согласие на доступ, предоставленное PISP. После отзыва PISP теряет доступ ко всем связанным операциям и не может инициировать платежи. ASPSP Обязан прекратить обработку по соответствующему consentId.

6.2 Параметры операции API

В [BGIG] содержится установленный список параметров запроса и отклика.

В приведенных ниже таблицах представлен обзор каждой операции API на верхнем уровне.

Важно

· Описания в этом разделе приведены для того, чтобы обеспечить ясность для пользователей, не обладающих техническими знаниями, в отношении требуемых элементов данных. Об использовании параметров запроса и отклика смотрите описание OpenAPI.

· Словарь параметров запроса и отклика, заданных операцией API, также предоставляется отдельно в формате Excel.

· Поддерживается только полезная нагрузка в формате JSON. Поддержка XML была удалена из оригинального описания API [BGIG].

· Обязательные и необязательные параметры указаны в описании OpenAPI и перечислены в электронной таблице Excel, которая обеспечивает экспорт описания OpenAPI.

· Если текстовая часть запроса или отклика не реализована, раздел помечается как Н/П.

6.2.1 post /v1/{payment-service}/{payment-product}

6.2.1.1 Запрос

Путь передачи данных	Вид	Описание
$.creditorAccount	объект	Счет кредитора, на который будет осуществлен платеж.
$.creditorAccount.bban	строка	Идентификатор номера основного банковского счета (BANK1). Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.creditorAccount.cashAccountВид	строка	ExternalCashAccountType1Code из ISO 20022.
$.creditorAccount.currency	строка	Код валюты ISO 4217 Альфа 3
$.creditorAccount.iban	строка	IBAN счета
$.creditorAccount.maskedPan	строка	Маскированный основной номер счета. Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.creditorAccount.msisdn	строка	Номер мобильного телефона. Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.creditorAccount.other	объект	В случаях, когда специально определенные критерии (BANK1) не предоставляются для идентификации соответствующего вида счета (например, сберегательного счета), ASPSP должен включить собственный идентификатор соответствующего счета, который однозначно идентифицирует счет для данного ASPSP.
$.creditorAccount.other.identification	строка	Собственный идентификатор счета.
$.creditorAccount.other.issuer	строка	Эмитент идентификации.
$.creditorAccount.other.schemeNameCode	строка	Запись, предоставленная внешним списком кодов ISO.
$.creditorAccount.other.schemeNameProprietary	строка	Название схемы, определенное собственным способом.
$.creditorAccount.pan	строка	Номер основного счета в соответствии с ISO/IEC 7812. Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.creditorAddress	объект	Подробная информация об адресе кредитора на основе объекта «Почтовый адрес» ISO 20022.
$.creditorAddress.buildingNumber	строка	Номер дома.
$.creditorAddress.country	строка	Код страны ISO 3166 альфа 2.
$.creditorAddress.postCode	строка	Почтовый индекс адреса.
$.creditorAddress.streetName	строка	Название улицы.
$.creditorAddress.townName	строка	Название города.
$.creditorAgent	строка	Агент, действующий от имени кредитора для осуществления платежа.
$.creditorAgentName	строка	Имя агента кредитора.
$.creditorName	строка	Имя кредитора.
$.dayOfExecution	строка	День исполнения в виде строки. Эта строка состоит не более чем из двух символов. Ведущие нули не допускаются. 31 считается последним числом месяца.
$.debtorAccount	объект	Счет дебитора, с которого будет осуществляться платеж.
$.debtorAccount.bban	строка	Идентификатор номера основного банковского счета (BANK1). Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.debtorAccount.cashAccountВид	строка	ExternalCashAccountВид1Code из ISO 20022.
$.debtorAccount.currency	строка	Код валюты ISO 4217 Альфа 3.
$.debtorAccount.iban	строка	BANK счета.
$.debtorAccount.maskedPan	строка	Маскированный основной номер счета. Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.debtorAccount.msisdn	строка	Номер мобильного телефона. Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.debtorAccount.other	объект	В случаях, когда специально определенные критерии (BANK1) не предоставляются для идентификации соответствующего вида счета (например, сберегательного счета), ASPSP должен включать собственный идентификатор соответствующего счета, который однозначно идентифицирует счет для данного ASPSP.
$.debtorAccount.other.identification	строка	Собственный идентификатор счета.
$.debtorAccount.other.issuer	строка	Эмитент идентификации.
$.debtorAccount.other.schemeNameCode	строка	Запись, предоставленная внешним списком кодов ISO.
$.debtorAccount.other.schemeNameProprietary	строка	Название схемы, определенное собственным способом.
$.debtorAccount.pan	строка	Номер основного счета в соответствии с ISO/IEC 7812. Поддержка данного параметра будет проверена при анализе участвующими в работе
$.endДата	строка	Последний применимый день исполнения. Если он не указан, то это бессрочное постоянное поручение. Если дата окончания совпадает с датой начала, то он будет рассматриваться как платеж с будущей датой. Значение периодичности игнорируется, и производится только разовый платеж.
$.endToEndIdentification	строка	Уникальный идентификатор платежного поручения, передаваемый вместе с платежным поручением. Поддержка данного параметра будет проверена при анализе участвующими в работе
$.executionRule	строка	Определяется порядок действий, когда даты повторяющихся платежей выпадают на выходные или праздничные дни в банке. Для получения информации о принимаемых значениях смотрите описание OpenAPI.
$.frequency	строка	Периодичность, с которой должен осуществляться периодический платеж. Для получения информации о принимаемых значениях смотрите описание OpenAPI.
$.instructedAmount	объект	Сведения о сумме платежа.
$.instructedAmount.amount	строка	Сумма, указанная с дробными числами, где дроби должны соответствовать определению валюты.
$.instructedAmount.currency	строка	Код валюты ISO 4217 Альфа 3.
$.monthsOfExecution	строка	Используется для периодических платежей. Месяцы, в которые должен быть осуществлен платеж
$.remittanceInformationUnstructured	строка	Неструктурированная информация о денежном переводе.
$.startДата	строка	Первый применимый день исполнения, начиная с этой даты, считается первым платежом.

Таблица 3 – Параметры запроса post /v1/{payment-service}/{payment-product}

6.2.1.2 Отклик

Путь передачи данных	Вид	Описание
$.currencyConversionFee	объект	Сведения о комиссионных за конвертацию, если они применимы.
$.currencyConversionFee.amount	строка	Сумма, указанная с дробными числами, где дроби должны соответствовать определению валюты. До 14 значимых чисел. Отрицательные суммы обозначаются знаком минус. В качестве десятичного разделителя используется точка.
$.currencyConversionFee.currency	строка	Код валюты ISO 4217 Альфа 3.
$.estimatedInterbankSettlementAmount	объект	Подробная информация о предполагаемой сумме межбанковских расчетов, если применимо.
$.estimatedInterbankSettlementAmount.amount	строка	Сумма, указанная с дробными числами, где дроби должны соответствовать определению валюты. До 14 значимых чисел. Отрицательные суммы обозначаются знаком минус. В качестве десятичного разделителя используется точка.
$.estimatedInterbankSettlementAmount.currency	строка	Код валюты ISO 4217 Альфа 3.
$.estimatedTotalAmount	объект	Сведения об общей сумме транзакции.
$.estimatedTotalAmount.amount	строка	Сумма, указанная с дробными числами, где дроби должны соответствовать определению валюты. До 14 значимых чисел. Отрицательные суммы обозначаются знаком минус. В качестве десятичного разделителя используется точка
$.estimatedTotalAmount.currency	строка	Код валюты ISO 4217 Альфа 3.
$.paymentId	строка	Идентификатор сгенерированного ресурса инициирования платежа.
$.psuMessage	строка	Необязательное сообщение для отображения PSU.
$.tppMessages	массив данных	Необязательные сообщения для отображения в PISP.
$.tppMessages[*].category	строка	Категория сообщения TPP.
$.tppMessages[*].code	строка	Коды сообщений для HTTP-кода 201 к запросу на инициирование платежа.
$.tppMessages[*].path	строка
$.tppMessages[*].text	строка	Дополнительный поясняющий текст к TPP.
$.transactionFeeIndicator	булева переменная	Индикатор комиссии за транзакцию.
$.transactionFees	объект	Сведения о комиссиях, связанных с платежом.
$.transactionFees.amount	строка	Сумма, указанная с дробными числами, где дроби должны соответствовать определению валюты. До 14 значимых чисел. Отрицательные суммы обозначаются знаком минус. В качестве десятичного разделителя используется точка
$.transactionFees.currency	строка	Код валюты ISO 4217 Альфа 3.
$.transactionStatus	строка	Статус транзакции. Для получения указаний смотрите следующую таблицу «Статус транзакции».

Таблица 4 – Параметры отклика post /v1/{payment-service}/{payment-product}

6.2.2 get /{payment-service}/{payment-product}/{paymentId}

6.2.2.1 Запрос

Н/П.

6.2.2.2 Отклик

Путь передачи данных	Вид	Описание
$.creditorAccount	объект	Счет кредитора, на который будет осуществлен платеж.
$.creditorAccount.bban	строка	Идентификатор номера основного банковского счета (BANK1). Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.creditorAccount.cashAccountВид	строка	ExternalCashAccountВид1Code из ISO 20022.
$.creditorAccount.currency	строка	Код валюты ISO 4217 Альфа 3.
$.creditorAccount.iban	строка	BANK счета.
$.creditorAccount.maskedPan	строка	Маскированный основной номер счета. Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.creditorAccount.msisdn	строка	Номер мобильного телефона. Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.creditorAccount.other	объект	В случаях, когда специально определенные критерии (BANK1) не предоставляются для идентификации экземпляра соответствующего вида счета (например, сберегательного счета), ASPSP должен включать собственный идентификатор соответствующего счета, который однозначно идентифицирует счет для данного ASPSP.
$.creditorAccount.other.identification	строка	Собственный идентификатор счета.
$.creditorAccount.other.issuer	строка	Эмитент идентификации.
$.creditorAccount.other.schemeNameCode	строка	Запись, предоставленная внешним списком кодов ISO.
$.creditorAccount.other.schemeName Proprietary	строка	Название схемы, определенное собственным способом.
$.creditorAccount.pan	строка	Номер основного счета в соответствии с ISO/IEC 7812. Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.creditorAddress	объект	Подробная информация об адресе кредитора на основе объекта «Почтовый адрес» ISO 20022.
$.creditorAddress.buildingNumber	строка	Номер здания.
$.creditorAddress.country	строка	Код страны ISO 3166 альфа 2.
$.creditorAddress.postCode	строка	Почтовый индекс адреса.
$.creditorAddress.streetName	строка	Название улицы.
$.creditorAddress.townName	строка	Название города.
$.creditorAgent	строка	Агент, выступающий от имени кредитора для осуществления платежа.
$.creditorAgentName	строка	Имя агента кредитора.
$.creditorName	строка	Имя кредитора.
$.dayOfExecution	строка	День исполнения в виде строки. Эта строка состоит не более чем из двух символов. Ведущие нули не допускаются. 31 считается последним числом месяца.
$.debtorAccount	объект	Счет дебитора, с которого будет осуществляться платеж.
$.debtorAccount.bban	строка	Идентификатор номера основного банковского счета (BANK1). Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.debtorAccount.cashAccountВид	строка	ExternalCashAccountВид1Code из ISO 20022.
$.debtorAccount.currency	строка	Код валюты ISO 4217 Альфа 3.
$.debtorAccount.iban	строка	BANK счета.
$.debtorAccount.maskedPan	строка	Маскированный основной номер счета. Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.debtorAccount.msisdn	строка	Номер мобильного телефона. Поддержка данного параметра будет проверена в следующей предварительной версии стандартов.
$.debtorAccount.other	объект	В случаях, когда специально определенные критерии (BANK1) не предоставляются для идентификации соответствующего вида счета (например, сберегательного счета), ASPSP должен включать собственный идентификатор соответствующего счета, который однозначно идентифицирует счет для данного ASPSP.
$.debtorAccount.other.identification	строка	Собственный идентификатор счета.
$.debtorAccount.other.issuer	строка	Эмитент идентификации.
$.debtorAccount.other.schemeNameCode	строка	Запись, предоставленная внешним списком кодов ISO.
$.debtorAccount.other.schemeName Proprietary	строка	Название схемы, определенное собственным способом.
$.debtorAccount.pan	строка	Номер основного счета в соответствии с ISO/IEC 7812. Поддержка данного параметра будет проверена при анализе участвующими в работе
$.endДата	строка	Последний применимый день исполнения. Если он не указан, то это бессрочное постоянное поручение. Если дата окончания совпадает с датой начала, то он будет рассматриваться как платеж с будущей датой. Значение периодичности игнорируется, и производится только разовый платеж.
$.endToEndIdentification	строка	Уникальный идентификатор платежного поручения, передаваемый вместе с платежным поручением. Поддержка данного параметра будет проверена при анализе участвующими в работе.
$.executionRule	строка	Определяется порядок действий, когда даты повторяющихся платежей выпадают на выходные или праздничные дни в банке. Для получения информации о принимаемых значениях смотрите описание OpenAPI.
$.frequency	строка	Периодичность, с которой должен осуществляться периодический платеж. Для получения информации о принимаемых значениях смотрите описание OpenAPI.
$.instructedAmount	объект	Сведения о сумме платежа.
$.instructedAmount.amount	строка	Сумма, указанная с дробными числами, где дроби должны соответствовать определению валюты.
$.instructedAmount.currency	строка	Код валюты ISO 4217 Альфа 3.
$.monthsOfExecution	строка	Используется для периодических платежей. Месяцы, в которые должен быть осуществлен платеж
$.remittanceInformationUnstructured	строка	Неструктурированная информация о денежном переводе.
$.startДата	строка	Первый применимый день исполнения, начиная с этой даты, считается первым платежом.
$.tppMessages	массив данных	Необязательные сообщения для отображения в PISP.
$.tppMessages[*].category	строка	Категория сообщения TPP.
$.tppMessages[*].code	строка	Коды сообщений для HTTP-кода 201 к запросу на инициирование платежа.
$.tppMessages[*].path	строка
$.tppMessages[*].text	строка	Дополнительный поясняющий текст к TPP.
$.transactionStatus	строка	Статус транзакции. Для получения указаний смотрите следующую таблицу «Статус транзакции».

Таблица 5 – Параметры отклика post /v1/{payment-service}/{payment-product}/{paymentId}

6.2.3 get /{payment-service}/{payment-product}/{paymentId}/status

6.2.3.1 Запрос

Н/П

6.2.3.2 Отклик

Путь передачи данных	Вид	Описание
$._links	объект	Должна содержаться ссылка на последующие шаги, если проблема может быть решена посредством интерфейса, например, для повторной отправки учетных данных.
$._links.href	строка	Ссылка на ресурс.
$.fundsAvailable	булева переменная	Истинно, если на момент запроса имеется достаточно средств, в противном случае – ложно.
$.ownerNames	массив данных	Список имен владельцев. Должен предоставляться только после успешной SCA. Может быть ограничен текущим PSU со стороны ASPSP.
$.ownerNames[*].name	строка	Имя владельца счета
$.ownerNames[*].role	строка	Используются следующие собственные коды: owner, legalRepresentative, и authorisedUser.
$.psuMessage	строка	Текст, который будет отображаться для PSU.
$.psuName	строка	Имя PSU. В случае корпоративного счета это может быть лицо, действующее от имени компании.
$.tppMessage	массив данных	Сообщения для TPP по операционным вопросам.
$.tppMessage[*].category	строка	Категория сообщения TPP.
$.tppMessage[*].code	строка	Код категории сообщений TPP.
$.tppMessage[*].path	строка
$.tppMessage[*].text	строка	Дополнительный поясняющий текст к TPP.
$.transactionStatus	строка	Статус транзакции. Для получения указаний смотрите следующую таблицу «Статус транзакции».

Таблица 6 – Параметры отклика get /v1/{payment-service}/{payment-product}/{paymentId}/status

6.2.4 get /v1/{payment-service}/{payment-product}/{paymentId}/authorisations

6.2.4.1 Запрос

Н/П

6.2.4.2 Отклик

Путь передачи данных	Вид	Описание
$.authorisationIds	массив данных	Массив данных всех идентификаторов authorisationIds, посредством которых можно получить ресурс авторизации.

Таблица 7 – Параметры отклика get /v1/{payment-service}/{payment-product}/{paymentId}/authorisations

6.2.5 get /v1/{payment-service}/{payment-product}/{paymentId}/authorisations/{authorisationId}

6.2.5.1 Запрос

Н/П

6.2.5.2 Отклик

Путь передачи данных	Вид	Описание
$.authorizationOrder	целое	В случае многоуровневой SCA определяется порядок, в котором должна быть проведена авторизация.
$.psuMessage	строка	Текст, который будет отображаться для PSU.
$.psuName	строка	Имя PSU. В случае корпоративного счета это может быть лицо, выступающее от имени компании.
$.scaStatus	строка	Этот элемент данных содержит информацию о статусе примененного метода SCA, основанную на следующих кодах: · received: Ресурс авторизации был успешно создан. · psuIdentified: PSU, связанный с ресурсом авторизации, был идентифицирован. · psuAuthenticated: PSU, связанный с ресурсом авторизации, был идентифицирован и прошел проверку подлинности. · started: Запущена адресная процедура SCA. · finalised: Процедура SCA успешно завершена. Это окончательный статус ресурса авторизации. · failed: Процедура SCA не выполнена. Это окончательный статус ресурса авторизации. · exempted: SCA для соответствующей транзакции пропущена, и соответствующая авторизация прошла успешно. Это окончательный статус ресурса авторизации.
$.tppMessage	массив данных	Сообщения для TPP по операционным вопросам.
$.tppMessage[*].category	строка	Категория сообщения TPP.
$.tppMessage[*].code	строка	Код категории сообщения TPP
$.tppMessage[*].path	строка
$.tppMessage[*].text	строка	Дополнительный поясняющий текст к TPP.

Таблица 8 - Параметры отклика get /{payment-service}/{payment-product}/{paymentId}/authorisations/{authorisationId}

6.2.6 delete /v1/{payment-service}/{payment-product}/{paymentId}

6.2.6.1 Запрос

Н/П.

6.2.6.2 Отклик

Н/П (Тело отклика пустое по причине того, что для отмены платежа авторизация не требуется).

6.3 Поля заголовков

Поля заголовка являются одним из элементов HTTP-запроса и образуют часть заголовка сообщения для запроса или отклика.

В [BGIG] приводится список полей заголовков, которые используются во всех операциях API. В этом разделе дается краткое описание полей заголовков, чтобы прояснить их использование в разных стандартах.

Важно

· Оригинальное руководство из [BGIG] выделено курсивом для справки.

· Значение условия выделено жирным шрифтом в тех случаях, когда оно отличается от исходного [BGIG].

· Описания в этом разделе приводятся один раз, чтобы обеспечить ясность использования и избежать повторения в документе стандартов.

· Поля заголовков, которые в настоящее время не поддерживаются [BGIG], включены для обеспечения возможности проверки исходных стандартов.

· О применении полей заголовка смотрите в описании OpenAPI.

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

#	Поле заголовка	Вид	Условие	Описание
1	X-Request-ID	UUID	Обязательное	Идентификатор запроса, уникальный для данного запроса, определяемый инициирующей стороной. Указания: · Должен быть уникальным для PISP. · В качестве варианта исполнения рекомендуется использовать UUID v4.
2	PSU-ID	Строка	Условное	Идентификатор клиента PSU в клиентском интерфейсе ASPSP
3	PSU-ID-Вид	Строка	Условное	Вид PSU-ID, необходим в сценариях, где PSU имеют несколько PSU-ID.
4	PSU-Corporate-ID	Строка	Не поддерживается	Используется в случае компаний. Может быть обязательным в документации ASPSP. Не поддерживается в данной версии стандартов. Для уточнения читайте раздел «Проектные решения»..
5	PSU-Corporate-ID-Вид	Строка	Не поддерживается	Вид для PSU-Corporate-ID. Может быть обязательным в документации ASPSP. Не поддерживается в данной версии стандартов. Для уточнения читайте раздел «Проектные решения»..
6	PSU-IP-Address	Строка	Обязательное	IP-адрес PSU, как его видит TPP.
7	Authorization	Строка	Обязательное	OAuth2-токен, если OAuth2 был выбран в качестве предварительного шага для проверки подлинности PSU. Поле заголовка «Авторизация» в настоящем стандарте необходимо, так как OAuth 2.0 является обязательным.
8	Digest	Строка	Условное	Часть HTTP-подписи, содержит в себе случайные данные тела сообщения. Необходим для платежных операций, где подпись обязательна.
9	TPP-Signature-Certificate	Строка	Условное	Содержит сертификат, используемый TPP для подписания запроса. Необходим для платежных операций, где подпись обязательна.
10	Signature	Строка	Условное	Фактическая цифровая подпись запроса. Необходим для платежных операций, где подпись обязательна. Исполнителям следует ознакомиться с разделом 12 [BGIG] для получения указаний по формированию подписи сообщений для платежных операций. Обратите внимание, что срок действия упомянутого стандарта по HTTP -подписи истек, поэтому вместо него используйте заменяющий его RFC 9421.
11	TPP-Redirect-Preferred	Булева переменная	Опциональное	Предпочтение TPP при SCA в случае перенаправленных потоков. Сохранено, но необходимо достичь консенсуса участников рынка по его использованию.
12	TPP-Decoupled-Preferred	Булева переменная	Опциональное	Предпочтение TPP при SCA в случае разделённых потоков. Сохранено, но необходимо достичь консенсуса участников рынка по его использованию.
13	TPP-Redirect-URI	Строка	Условное	URI, на который должен быть перенаправлен PSU после SCA в случае перенаправленных потоков. Сохранено, но может быть заменено соглашениями [FAPI2SP] после завершения работы над [APISG].
14	TPP-Nok-Redirect-URI	Строка	Опциональное	Альтернативный URI для перенаправления в случае сбоя. Сохранено, но может быть заменено соглашениями [FAPI2SP] после завершения работы над [APISG].
15	TPP-Explicit-Authorisation-Preferred	Булева переменная	Не поддерживается	Предпочтение TPP для однозначной авторизации (например, при использовании корзин для подписи). Не поддерживается, так как требуется однозначная авторизация данного платежного поручения, которая будет включена в будущие руководства по управлению согласием
16	TPP-Rejection-NoFunds- Preferred	Булева переменная	Опциональное	В случае, когда значение «истинно», TPP предпочитает отклонить платеж, если средств недостаточно. Сохранено, но необходимо подтверждение того, что средства могут быть проверены по всем платежным продуктам.
17	TPP-Notification-URI	Строка	Опциональное	URI для уведомлений об обратном вызове.
18	TPP-Notification-Content- Preferred	Строка	Опциональное	Предпочтение видов уведомлений, например, об изменении статуса.
19	TPP-Brand-Logging- Information	Строка	Опциональное	Информация о коммерческом обозначении TPP, отображаемая для PSU.

Таблица 9 - Поддерживаемые поля заголовка

6.4 Коды

Далее приводятся коды ISO 20022, упоминаемые в описании OpenAPI.

Статус транзакции

#	Код	Определение	Описание
1	ACCC	AcceptedSettlementCompleted	Расчеты по счету кредиторов завершены.
2	ACCP	AcceptedCustomerProfile	Предшествующая проверка по технической валидации прошла успешно. Проверка профиля клиента также прошла успешно.
3	ACSC	AcceptedSettlementCompleted	Расчеты по счету дебитора завершены. Использование: этот статус может быть использован первым агентом для сообщения дебитору о завершении операции. Внимание: этот статус предоставляется для обозначения статуса транзакции, а не для финансовой информации. Его можно использовать только после согласования обеими сторонами.
4	ACSP	AcceptedSettlementInProcess	Все предшествующие проверки, такие как техническая валидация и профиль клиента, прошли успешно, поэтому инициирование платежа принято к исполнению.
5	ACTC	AcceptedTechnicalValidation	Аутентификация, синтаксическая и семантическая проверка прошли успешно.
6	ACWC	AcceptedWithChange	Платежное поручение принято, но в него будут внесены изменения, например, дата или не отправленный денежный перевод.
7	ACWP	AcceptedWithoutPosting	Платежное поручение, включенное в безналичный перевод, принято без проводки по счету клиента-кредитора.
8	RCVD	Received	Платежное поручение получено агентом-получателем.
9	PDNG	Pending	Инициированный платеж или отдельная транзакция, включенная в инициированный платеж, находится на рассмотрении. Будет проведена дополнительная проверка и обновлен статус.
10	RJCT	Rejected	Инициированный платеж или отдельная транзакция, включенная в инициированный платеж, отклонена.
11	CANC	Cancelled	Инициированный платеж был отменен до его исполнения
12	ACFC	AcceptedFundsChecked	Предшествующая проверка по технической валидации и профиля клиента была успешной, а автоматическая проверка средств была положительной.
13	PATC	PartiallyAcceptedTechnicalCorrect	Для инициирования платежа необходимо пройти несколько проверок подлинности, причем некоторые, но еще не все, уже выполнены. Синтаксическая и семантическая проверки прошли успешно.

7 Обработка ошибок

Сведения об обработке ошибок и статусе передаются с помощью кодов статуса HTTP и предопределенных кодов ошибок.

7.1 Коды ошибок HTTP, зависящие от конкретной службы

Код сообщения	HTTP Код ответа	Описание
CERTIFICATE_INVALID	401	Содержимое сертификата подписи/корпоративной печати не соответствует общим требованиям или требованиям к атрибутам.
ROLE_INVALID	401	У TPP нет соответствующей роли для доступа к этой службе.
CERTIFICATE_EXPIRED	401	Срок действия сертификата подписи/корпоративной печати истек.
CERTIFICATE_BLOCKED	401	Сертификат подписи/корпоративной печати был заблокирован ASPSP или соответствующим NCA.
CERTIFICATE_REVOKED	401	Сертификат подписи/корпоративной печати был отозван QSTP.
CERTIFICATE_MISSING	401	Сертификат подписи/корпоративной печати не был доступен в запросе, но требуется для соответствующего сертификата.
SIGNATURE_INVALID	401	Неверна подпись прикладного уровня для аутентификации TPP.
SIGNATURE_MISSING	401	ASP требует подписи на прикладном уровне для аутентификации TPP, но она отсутствует.
ROLE_INVALID	401	У TPP нет соответствующей роли для доступа к этой службе
FORMAT_ERROR	400	Формат некоторых полей запроса не соответствует требованиям XS2A. В ответном сообщении может быть указан явный путь к соответствующему полю. Это относится к заголовкам и основным записям. Это также относится к случаям, когда эти записи ссылаются на ошибочные или несуществующие экземпляры данных, например, неправильно сформированный BANK1.

PARAMETER_NOT_CONSISTENT	400	Параметры, представленные TPP, не согласованы. Это относится только к параметрам запроса.
PARAMETER_NOT_SUPPORTED	400	Этот параметр не поддерживается поставщиком API. Этот код следует использовать только для параметров, которые описаны как "необязательные, если они поддерживаются поставщиком API".
PSU_CREDENTIALS_INVALID	401	Идентификатор блока питания не совпадает с адресом ASAP или заблокирован, или, соответственно, указан пароль. OTP был введен неверно. Возможно, будет добавлена дополнительная информация.
SERVICE_INVALID	400 (если полезная нагрузка) 405 (если HTTP -метод)	Адресованная услуга недействительна для адресованных ресурсов или отправленных данных.
SERVICE_BLOCKED	403	Эта служба недоступна для указанного PSU из-за блокировки канала, независимой от ASPSP. Дополнительная информация может быть предоставлена ASPSP.
CORPORATE_ID_INVALID	401	PSU-Corporate-ID не может быть сопоставлен с указанным ASPSP.
CONSENT_UNKNOWN	403 (если путь) 400 (если заголовка)	Идентификатор согласия не может быть сопоставлен ASPSP с TPP.
CONSENT_INVALID	401	Согласие было создано этой TPP, но недействительно для указанной услуги/ресурса.
CONSENT_EXPIRED	401	Согласие было создано этой TPP, но срок его действия истек, и его необходимо продлить.
TOKEN_UNKNOWN	401	Токен OAuth2 не может быть сопоставлен ASPSP с TPP.
TOKEN_INVALID	401	Токен OAuth2 связан с TPP, но недействителен для адресованной службы/ресурса.
TOKEN_EXPIRED	401	Токен OAuth2 связан с TPP, но срок его действия истек, и его необходимо обновить.
RESOURCE_UNKNOWN	404 (если account-id в пути) 403 (если ресурс в пути) 400 (если полезная нагрузка)	Адресованный ресурс неизвестен относительно TPP. Примером ссылки на полезную нагрузку является создание корзины подписи с неизвестной идентификацией ресурса.
RESOURCE_EXPIRED	403 (если в пути) 400 (если полезная нагрузка)	Адресованный ресурс связан с TPP, но срок его действия истек, и к нему больше нельзя получить доступ.
RESOURCE_BLOCKED	400	Указанный ресурс не может быть адресован данным запросом, поскольку он заблокирован, например, группировкой в корзине подписи.
TIMESTAMP_INVALID	400	Временная метка не соответствует принятому периоду времени.
PERIOD_INVALID	400	Запрошенный период времени выходит за рамки допустимого.
SCA_METHOD_UNKNOWN	400	Указанный метод SCA в запросе выбора метода аутентификации неизвестен или не может быть сопоставлен ASPSP с PSU.
SCA_INVALID	400	Применение метода к ресурсу авторизации (например, запрос подтверждения) заблокировано, поскольку статус SCA ресурса равен «не удалось».
STATUS_INVALID	409	Указанный ресурс не допускает дополнительной авторизации.

7.2 Конкретные коды ошибок HTTP PISP

Код сообщения	HTTP Код ответа	Описание
PRODUCT_INVALID	403	Адресный платежный продукт недоступен для PSU.
PRODUCT_UNKNOWN	404	Адресный платежный продукт не поддерживается ASPSP.
PAYMENT_FAILED	400	Запрос POST инициации платежа не удался во время начального процесса. Дополнительная информация может быть предоставлена ASPSP.
EXECUTION_DATE_INVALID	400	Запрошенная дата исполнения не является допустимой датой исполнения ASPSP.
CANCELLATION_INVALID	405	Адресный платеж не подлежит отмене, например, из-за истечения срока оплаты или юридических ограничений.
BENEFICIARY_WHITELISTING_REQUIRED	201	Используется только в ответах на запрос на инициирование платежа. Указывает, что для выполнения платежа PSU необходимо явно добавить бенефициара в белый список кредитных переводов через банковский канал.
FUNDS_NOT_AVAILABLE	200	Используется только в ответах на запрос Get Transaction Status Request (см. Раздел 5.4) или Get Payment Request (см. Раздел 5.4) в случае "transactionStatus"= "RJCT". Указывает, что причиной отклонения платежа является то, что требуемые средства оказались недоступными для определенного (например, из-за отсутствия средств или из-за настроенных лимитов) во время обработки после первоначального принятия инициирования платежа.
CONTENT_INVALID	200	Используется только в ответах на запрос Get Transaction Status Request (см. Раздел 5.4) или Get Payment Request (см. Раздел 5.4) в случае "transactionStatus"= "RJCT". Указывает, что причиной отклонения платежа является то, что содержимое инициирования платежа было признано недействительным во время обработки после первоначального принятия инициирования платежа.

Проект

Приложение 2 к рекомендации

по использованию единых

стандартов Открытых API

Единый стандарт

API для обмена и доступа к информации

банковских и платежных услуг

1. Управление версиями

Версия	Дата	Описание
0.1	__	Первоначальный проект

1. Общие положение

1. Настоящий Стандарт содержит руководящие принципы и стандарты API для обмена данными в рамках взаимодействия через открытые банковские интерфейсы. Основная цель Стандарта – создать единый подход к взаимодействию участников среды Открытых API, обеспечивая прозрачность, безопасность и доступность данных.

2. Настоящий Стандарт рекомендован к использованию коммерческими банками, платежными организациями, операторами платежных систем и других участников среды Открытых API, действующими на территории Кыргызской Республики.

3. В настоящем Стандарте используются следующие термины и их определения:

API (Application programming interfaces) – это набор процедур, протоколов и инструментов для создания программных приложений. API определяет, взаимодействие программных компонентов.

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

Среда Открытых API – комплекс стандартов открытых банковских интерфейсов, управление, системы, процессы, безопасность и процедуры, используемые для поддержки участников.

4. Информационный обмен между ASPSP и TPP осуществляется посредством электронных сообщений, формируемых на стороне ASPSP Открытых API.

2. Принципы и дизайн API

5. Принципы архитектуры среды Открытых API соответствует концепции RESTful API.

6. На физическом уровне при проектировании сообщений используется язык описания интерфейсов OpenAPI третьей версии в формате YAML.

3. Защита прав потребителей

7. Участники среды Открытых API обеспечивают раскрытие минимального объема информации пользователям, которая включает, дополнительно следующую информацию:

- полное и (или) сокращенное (при наличии) фирменное наименование участника среды Открытых API, адрес в пределах места нахождения, адрес электронной почты, контактный телефон, адрес официального интернет сайта (при наличии);

- порядок получения услуги (сервиса) пользователям, возможные риски пользователя;

- права пользователя и порядок действий при возникновении технических неполадок на стороне участника среды Открытых API;

- способы и адреса направления обращений (жалоб) пользователем;

- способы защиты прав пользователя;

- порядок и срок предоставления по требованию пользователя документов (в т.ч. в форме электронного документа), связанных с оказанием услуг (предоставлением сервиса) участником среды Открытых API;

- порядок предоставления пользователю экземпляра договора и (или) иного документа, подтверждающего оказание услуги (предоставление сервиса) участником среды Открытых API в письменной форме (в т.ч. в форме электронного документа);

- способы направления информации пользователю в связи с оказанием услуги (предоставления сервиса) участником среды Открытых API;

- сведения о распределении ответственности между участниками среды Открытых API, а также третьими лицами, привлекаемыми участниками среды Открытых API, для оказания услуги (сервиса) за неисполнение либо ненадлежащее исполнение обязанностей в рамках оказания услуг (предоставления сервиса) пользователю;

- ограничения (при наличии), условия и способы использования услуг (сервиса) участника среды Открытых API, изменения условий и отказа от услуг (сервиса) пользователем;

- порядок возмещения убытков, понесенных пользователем;

- сведения о предполагаемых сроках восстановления режима оказания услуг (предоставления сервиса) в случае возникновения технических неполадок;

- требований, предъявляемых участником среды Открытых API к иным участникам среды Открытых API, во взаимодействии с которыми осуществляется оказание услуги (предоставление сервиса) пользователю.

8. Участник среды Открытых API обеспечивает соответствие порядка раскрытия информации пользователю следующим критериям:

- обеспечение возможности доступа к информации пользователем на равных правах и в равном объеме;

- исключение раскрытия информации, которая может повлечь неоднозначное толкование свойств услуги (сервиса);

- обеспечение изложения информации на государственном или официальном языке в доступной форме (с использованием удобночитаемых шрифтов, форматов предоставления);

- обеспечение возможности пользователя получать уведомление о совершении операции / оказании услуги в порядке и на условиях, установленных договором, но не позднее одного дня со дня совершения операции / оказания услуги;

- обеспечение возможности получения по требованию пользователя документов (в т.ч. в форме электронного документа), связанных с оказанием услуги (предоставлением сервиса);

- обеспечение возможности получения экземпляра договора и (или) иного документа, подтверждающего оказание услуги (предоставления сервиса) пользователем.

9. Участник среды Открытых API обеспечивает:

- конфиденциальность и защиту персональных данных пользователя в случае, если получателем услуги (сервиса) выступает физическое лицо;

- защиту имущественных интересов пользователя в части несанкционированного совершения операций с денежными средствами и электронными денежными средствами пользователя;

- уведомление пользователя о распределении ответственности между участниками среды Открытых API, а также иными третьими лицами за неисполнение либо ненадлежащее исполнение обязанностей в рамках оказания услуги (предоставления сервиса);

- использование только целевой необходимой и достаточной информации при совершении операций (предоставлении сервиса) посредством Открытых API;

- исключение неавторизованных пользователем операций;

- исключение использования для целей формирования предложения пользователю информации, на обработку которой явным образом не получено согласие от пользователя;

- исключение возможности обуславливать предоставление одной услуги (сервиса) в зависимости от предоставления другой услуги (сервиса);

- исключение возможности потери контроля над данными, переданными пользователем участникам среды Открытых API для целей оказания услуги (предоставления сервиса);

- возможность пользователя осуществлять оплату услуги (сервиса) в доступной для пользователя форме;

- исключение навязывания заведомо невыгодных условий оказания услуг (сервиса) пользователю (с соблюдением требований законодательства и нормативных правовых актов Национального банка).

4. Роли и участники процесса

10. Среда Открытых API определяет следующих участников и их роли:

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

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

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

Поставщик платежных услуг по обслуживанию счетов (ASPSP) — коммерческий банк, обслуживающий банковский счет пользователя и публикующий Открытые API.

11. Открытые API регламентируют взаимодействие только между следующими участниками:

ASPSP предоставляет Открытые API для стороннего поставщика (TPP), получает сообщения запросов через свои Открытые API и отправляет соответствующие ответные сообщения TPP.

TPP может получить доступ к счету пользователя, управляемому ASPSP через Открытые API, при согласии пользователя. TPP отправляет сообщения запроса через Открытые API ASPSP и получает соответствующие ответные сообщения от этого ASPSP.

5. Принципы построение взаимодействия

12. Схема логического месторасположение Открытых API в создаваемой среде:

13. Между участниками среды Открытых API возможны следующие взаимодействия:

1. Предоставление пользователем долгосрочного согласия на использование его данных TPP.

2. Предоставление пользователем ASPSP краткосрочного согласия на инициирование перевода денежных средств TPP.

3. Обмен данными между TPP и ASPSP с согласия пользователя.

6. Предоставление пользователем согласия

14. Долгосрочное согласие дается пользователем на стороне ASPSP для осуществления обмена данными между TPP и ASPSP на длительный срок без непосредственного участия пользователя. После предоставления такого согласия взаимодействие происходит следующим образом: Пользователь – TPP – ASPSP.

В любой момент пользователь может отозвать долгосрочное согласие как через Открытые API, так и через предоставляемые средства ASPSP.

Долгосрочное согласие на получение данных о банковском счете схематически можно показать следующим образом:

15. Краткосрочное согласие дается пользователем при необходимости для перевода денежных средств с его банковского счета. Краткосрочное согласие является подтверждением инициирования перевода денежных средств TPP.

Краткосрочное согласие на инициирование платежной услуги схематически можно показать следующим образом:

16. Обмен данными между TPP и ASPSP происходит после предоставления пользователем ASPSP краткосрочного или долгосрочного согласия. На следующем рисунке показано взаимодействие TPP и ASPSP через Открытые API:

ASPSP может также выступать в одной из ролей TPP (AISP и/или PISP) и может получать доступ к Открытым API других ASPSP.

7. Взаимодействие участников процесса предоставления данных

17. Открытые API поддерживают следующие сценарии использования обмена данными:

- создание долгосрочного согласия на получение информации о счете;

- получение списка счетов, к которым получен доступ;

- получение детальной информации о счете, к которому получен доступ;

- получение баланса по счету, к которому получен доступ;

- получение списка транзакций по счету, к которому получен доступ.

7.1. Создание долгосрочного согласия на получение информации о счете

TPP выполняет этот сценарий использования, чтобы получить доступ на получение данных в соответствии с другими сценариями использования, доступными для роли AISP. Если TPP невозможно идентифицировать корректно через Открытые API, то ASPSP отклонит запрос.

Если у TPP нет роли AISP, то PISP отклонит запрос. С согласия пользователя AISP может получить доступ к следующим сценариям:

- получение списка счетов;

- получение детальной информации о счете;

- получение баланса по счету;

- получение списка транзакций по счету.

7.2. Получение списка счетов, к которым получен доступ

В этом сценарии использования TPP получает с ранее предоставленного долгосрочного согласия пользователя список счетов пользователя. Если TPP невозможно идентифицировать корректно через Открытые API, то ASPSP отклонит запрос. Если у TPP нет роли AISP, то ASPSP отклонит запрос. На следующей схеме показаны высокоуровневые информационные потоки для получения списка счетов:

7.3. Получение детальной информации о счете, к которому получен доступ

В этом сценарии использования TPP получает с ранее предоставленного долгосрочного согласия пользователя детали счета пользователя. Если TPP невозможно идентифицировать корректно через Открытые API, то ASPSP отклонит запрос. Если у TPP нет роли AISP, то ASPSP отклонит запрос.

На следующей схеме показаны высокоуровневые информационные потоки для получения детальной информации о счете:

7.4. Получение баланса по счету, к которому получен доступ

В этом сценарии использования TPP получает с ранее предоставленного долгосрочного согласия пользователя баланс счета пользователя. Если TPP невозможно идентифицировать корректно через Открытые API, то ASPSP отклонит запрос.

Если у TPP нет роли AISP, то ASPSP отклонит запрос. На следующей схеме показаны высокоуровневые информационные потоки для получения баланса по счету:

7.5. Получение списка транзакций по счету

В этом сценарии использования TPP получает с ранее предоставленного долгосрочного согласия пользователя транзакции по счету пользователя. Если TPP невозможно идентифицировать корректно через Открытые API, то ASPSP отклонит запрос.

Если у TPP нет роли AISP, то ASPSP отклонит запрос. На следующей схеме показаны высокоуровневые информационные потоки для получения списка транзакций по счету:

8. Методы доступа к API

В следующих таблицах представлен обзор методов HTTP-доступа, поддерживаемых конечными точками API, и ресурсов, созданных с помощью данного API.

Например:

Конечные точки счетов

Конечные точки/Ресурс	Метод	Условия	Описание
accounts	GET	Обязательно	Прочитать все идентификаторы счетов, доступ к которым был предоставлен пользователем через конечные точки/ согласие. Кроме того, соответствующая информация о счетах и гиперссылки на соответствующие информационные ресурсы счетов предоставляются, если соответствующее согласие уже было предоставлено. Примечание: Обратите внимание, что стандарт предоставляет AISP возможность предоставлять доступ к списку всех текущих счетов пользователя. В этом случае эта конечная точка предоставит список всех адресуемых текущих счетов пользователя как можно скорее.
accounts?withBalance	GET	Необязательно	Считывание идентификаторов банковского счета, неявно указанных в соответствующем согласии, вместе с информацией о балансе, в зависимости от предоставленного согласия.
accounts/{account-id}	GET	Обязательно	Предоставьте подробную информацию об указанном счете.
ccounts/{account-id}?withBalance	GET	Необязательно	Предоставьте подробную информацию об указанном счете вместе с информацией о балансе
accounts/{account-id}/balance	GET	Обязательно	Предоставьте подробную информацию о балансе указанного счета
accounts/{account-id}/transaction	GET	Обязательно	Просмотр списков транзакций заданного счета. Для заданного счета дополнительными параметрами являются, например, атрибуты «dateFrom» и «dateTo». ASPSP может добавить информацию о балансе, если списки транзакций без балансов не поддерживаются.
accounts/{account-id}/transactions?withBalance	GET	Необязательно	Просмотр списков транзакций по указанному счету в зависимости от управляющего параметра «bookingStatus» вместе с остатками.
accounts/{account-id}/transactions/{transaction Id}	GET	Необязательно	Прочитайте подробности указанной транзакции.

Примечание: Для всех методов доступа к API сначала требуются механизмы технического согласия.

Примечание: Обратите внимание, что параметры {account-id} являются идентификаторами ресурсов и, следовательно, могут быть маркированы AISP таким образом, что фактические номера учетных записей, такие как bankc, не являются частью определений путей API по соображениям защиты данных. Эта токенизация управляется AISP. В данной спецификации настоятельно рекомендуется использовать UUID для идентификации ресурсов.

Конечные точки банковских платежных картах

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

Примечание: Способы доступа к банковским платежным картам менее детализированы по сравнению со способами доступа к счетам из-за ограниченной функциональности по сравнению с обычными банковскими счетами.

Конечные точки/Ресурс	Метод	Условия	Описание
card-accounts	GET	Необязательно	Прочитать все идентификаторы банковских платежных карт, к которым был предоставлен доступ через конечную точку /согласие пользователя. Кроме того, предоставляется соответствующая информация о счетах и гиперссылки на соответствующие информационные ресурсы счетов, если соответствующее согласие уже было предоставлено.
card-accounts/{account-id}	GET	Необязательно	Подробная информация о счете указанной карты.
card-accounts/{account-id}/balances	GET	Необязательно	Предоставьте подробную информацию о балансе по адресуемому счету карты.
card-accounts/{account-id}/transactions	GET	Обязательно	Просмотр списков транзакций, связанных с указанным счетом карты. Для указанного счета дополнительными параметрами являются, например, атрибуты «dateFrom» и «dateTo».

Примечание: Для всех методов доступа к API accounts сначала требуются механизмы технического согласия.

Примечание: Обратите внимание, что параметры {account-id} являются идентификаторами ресурсов и, следовательно, могут быть маркированы ASPSP таким образом, что фактические номера учетных записей, такие как bankc, не являются частью определений путей API по соображениям защиты данных. Эта токенизация управляется ASPSP. В данной спецификации настоятельно рекомендуется использовать UUID для идентификации ресурсов.

Информация о статусе для AISP в рамках процесса получения согласия

Как описано выше, ASPSP требуется технический токен согласия для доступа к информации, связанной с банковскими счетами.

9. Коды ответов HTTP

Код ответа HTTP сообщает об успешности или неудаче сообщения запроса. Коды ответа HTTP 4XX следует указывать только в том случае, если текущий запрос не может быть выполнен, например, инициирование платежа не может быть отправлено или транзакции по счету не могут быть получены. Запрос на получение статуса существующего платежа или согласия обычно возвращает код ответа HTTP 200, поскольку фактический запрос на получение статуса был успешным, независимо от того, установлено ли состояние платежа или согласия на неудачу или нет.

Эта спецификация поддерживает следующие коды ответа HTTP:

	Статус кода		Описание
200 OK		Коды ответов PUT, GET Этот код возврата разрешен, если запрос был повторен из-за тайм-аута. Ответом в этом случае может быть код 200 или 201 в зависимости от реализации ASPSP. POST для запроса средств также вернет 200, поскольку он не создает новый ресурс. Код ответа DELETE, когда платежный ресурс был успешно отменен и не требуется дальнейшего разрешения на отмену.
201 Created		Код ответа POST, в котором инициирование платежа или запрос согласия были выполнены правильно.
202 Accepted		Код ответа DELETE, в котором платежный ресурс может быть отменен в целом, но для отмены требуется дополнительное разрешение.
204 No Content		Код ответа DELETE, где ресурс согласия был успешно удален. Код указывает, что запрос был выполнен, но контент не был возвращен.
400 Bad Request		Произошла ошибка проверки. Этот код будет охватывать неверный синтаксис в запросе или неверные данные в полезной нагрузке.
401 Unauthorized		Построенные участники или пользователь не авторизованы для выполнения запроса. Повторите запрос с правильной информацией аутентификации.
403 Forbidden		Возвращается, если ресурс, на который ссылались в пути, существует, но к нему не может получить доступ участников или пользователей. Этот код следует использовать только для нечувствительных ссылок на идентификаторы, поскольку он покажет, что ресурс существует, даже если к нему нельзя получить доступ.
404 Not found		Возвращается, если ресурс или конечная точка, на которые ссылался путь, не существует или на них не может ссылаться участникам или пользователем. Если вы сомневаетесь, является ли определенный идентификатор в пути конфиденциальным или нет, используйте код ответа HTTP 404 вместо кода ответа HTTP 403.
405 Method Not Allowed		Этот код отправляется только в том случае, если метод HTTP (PUT, POST, DELETE, GET и т. д.) не поддерживается на определенной конечной точке. Он не имеет ничего общего с моделью данных согласия, платежа или информации об учетной записи. Код ответа DELETE в случае отмены инициирования платежа, когда инициирование платежа не может быть отменено по юридическим или другим операционным причинам.
406 Not Acceptable		ASPSP не может сгенерировать содержимое, указанное участников в заголовке Accept.
408 Request Timeout		Сервер по-прежнему работает правильно, но время ожидания отдельного запроса истекло.
409 Conflict		Запрос не может быть выполнен из-за конфликта с текущим состоянием целевого ресурса.
415 Unsupported Media Type		Посторонний участник предоставил тип носителя, который не поддерживается ASPSP.
429 Too Many Requests		Посторонний участник превысила количество запросов, разрешенных согласием или RTS.
500 Internal Server Error		Произошла внутренняя ошибка сервера.
503 Service Unavailable		В настоящее время сервер ASPSP недоступен. Как правило, это временное состояние.

10. Услуга информации по счетам

Поддержка суб-услуг

Данная спецификация предусматривает различные типы информационных услуг по счетам:

• балансы на данном счете,

• список адресуемых счетов,

• данные счетов данного аккаунта или списка всех доступных счетов, относящихся к предоставленному согласию, и

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

Ниже приводится определение списка адресуемых и доступных счетов:

Определение: Список адресуемых счетов в ASPSP, связанных с пользователем, – это список счетов пользователя, которые открыты для доступа через API.

Определение: Список доступных счетов в ASPSP, связанных с согласием пользователя, – это список счетов, для которых пользователь предоставил согласие по крайней мере на один из определенных типов информации о счете.

Примечание: Запрос на чтение данных для списка адресуемых счетов и сведений о счете данного счета синтаксически идентичен. Разница заключается только в базовом ресурсе согласия, на который ссылаются через параметр заголовка HTTP «Consent-ID».

Пример: ASPSP предоставляет Bankc1 и Bankc2 для пользователя. Пользователь предоставил TPP согласие на доступ к транзакциям и остаткам средств только на Bankc1. В этом случае адресуемыми счетами являются Bankc1 и Bankc2, список доступных счетов состоит только из Bankc1.

Получение согласия и чтение данных счетов

В рамках этой спецификации услуга информации о счетах разделена на два этапа:

1 этап: дать согласие на использование информации о счетах

В рамках этого этапа предоставление информационной услуги по счетам пользователя дает согласие AISP на:

- счета, доступные для услуги информации о счетах,

- тип информационной услуги счетов, к которой предоставляется доступ,

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

- в последнем случае – срок действия согласия в днях или максимальный срок, предлагаемый пользователем. AISP и при необходимости частота повторяющихся запросов.

Далее пользователь авторизует это согласие для ASPSP с помощью SCA.

Результатом этого процесса является ресурс контента. В рамках этого процесса AISP возвращает ссылку на этот ресурс. TPP может получить объект контента, отправив метод GET для этого ресурса. Этот объект содержит подробные сведения о правах доступа, текущем сроке действия и токен Content-ID.

2 этап: считывание данных счетов

На этом этапе AISP получает доступ к данным счетам, как это определено в согласии пользователя. Запрос на чтение данных счетов направляется на соответствующий ресурс для получения согласия, используя вышеупомянутую ссылку на этот ресурс.

В запросе на чтение данных счетов будет указано:

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

- идентификатор счетов, к которой обращается пользователь, если это применимо,

- инициировал ли пользователь запрос непосредственно в режиме реального времени,

- следует ли дополнительно указывать балансы, если это применимо,

- в случае списков транзакций в качестве информации о счете введите дополнительно

- идентификатор адресованного счета и

- период действия списка транзакций

- если это применимо, необязательно, дельта-флаг, указывающий на запрос дельта-отчета относительно последнего запроса с дополнительными данными.

- предпочтительные форматы списков транзакций.

Для доступа к счетам банковские счета и банковские платежные карты разделены на конечные точки, поскольку данные обычно разделяются в серверной части ASPSP.

В случае получения разового согласия в доступе может быть отказано, если AISP запрашивает данные более одного раза или если срок действия согласия истек, например, через 20 минут после завершения работы механизма получения согласия в зависимости от реализации TPP.

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

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

10.1 Считывание потока данных счетов

Для считывания данных счета сначала требуется поток для получения соответствующего согласия в API-интерфейсах. В этом случае фактический поток данных счета для считывания не зависит от соответствующего потока управления согласием. Это простой процесс запроса/ответа, который заключается в следующем:

10.2 Обзор данных информации о счетах

В следующей таблице приведено техническое описание абстрактной модели данных для AISP о счетах. В следующих столбцах представлен обзор протоколов API:

- в столбце «Элемент данных» используются абстрактные элементы данных, чтобы обеспечить связь с правилами и определениями ролей в этом документе.

- «кодировка атрибута» дает фактическое определение кодировки в API, как определено в этом документе.

- столбцы «Локация» определяют, куда соответствующие элементы данных передаются в качестве параметров HTTP, соответственно, они взяты из сертификатов eIDAS. Для параметров HTTP «путь» включает в себя хост, порт и базовый путь API.

- в столбце «Использование» приведен обзор использования элементов данных в различных вызовах API. Эти вызовы будут технически реализованы в виде HTTP-команд POST, PUT, DELETE и GET в виде следующего вызова:

- запрос на чтение данных – это запрос на получение информации о счете, который адресуется разным конечными точками с разными параметрами.

Примечание: Для получения информации о счетах сначала требуется техническое согласие на доступ к счетам, подтвержденное SCA от пользователя.

Определено следующее использование сокращений в столбцах «Локация» и «Использование».

• x: Этот элемент данных передается на соответствующем уровне.

• m: Обязательный

• o: Необязательный для использования TPP

• c: Условный. Условие описано в вызовах API, условие определено TPP.

В следующей таблице определены требования не только к сообщениям-запросам, но и к элементам данных для ответных сообщений. Эти требования применяются только к положительным ответам (т.е. к коду ответа HTTP 2xx). В случае ошибки предоставляется общая информация об ошибке, вместе с кодом ответа HTTP 40x.

Примечание: Более технические функции, такие как GET .../{consentId} и GET .../{authorisationId}, а также запрос на отмену, не представлены в данном документе.

	Элементы данных	Кодировка атрибутов	Локация					Использование
			Путь	Параметры запроса	Заголовка	Тело	Сертификат	Читать запрос данных	Читать ответ данных
	Идентификация TPP		x					m
	Регистрационный номер						x	m
	Название						x	m
	Роль TPP						x	m
	Национальный банк						x	m
	Идентификация запроса	X-Request-ID			x			m	m
	ID согласия	Consent-ID			x			m
	Токен доступа (из опциона OAuth2)	Authorization			x			c
	Клиент API подписывает электронную подпись	x-jws-signature			x			c
	Дополнительные данные, связанные с подписью	Digest			x			c
	Информация о сообщении пользователя	psuMessage				x			o
	Информация о сообщении API клиента	apiClientMessages				x			o
	IP адрес пользователя	PSU-IP-Address			x			c
	IP порт пользователя	PSU-IP-Port			x			o
Информация пользователя		PSU-Accept			x			o
		PSU-Accept-Charset			x			o
		PSU-Accept-Encoding			x			o
		PSU-Accept-Language			x			o
		PSU-Http-Method			x			o
		PSU-Device-ID			x			o
Пользовательский агент пользователя		PSU-User-Agent			x			o
GEO информация		PSU-Geo-Location			x			o
ID счета пользователя		accountId	x					c
Счет пользователя		Account				x			m
Дата начала		dateFrom		x				c
Дата окончания		dateTo		x				c
Транзакции		entryReferenceFrom		x				o
Статус бронирования		bookingStatus		x				o
Дельта-индикатор		deltaList		x				o
Флажок с балансом		withBalance		x				o
Перечень счетов пользователя		Array of accountDetails				x			c
Детали счета пользователя		accountDetails				x			c
Остаток счета		balances				x			c
Транзакции		transactions				x			c
Счет карты пользователя		accountDetails				x			c
Транзакции карты		cardTransactions				x			c

IP-адрес/порт пользователя и дополнительная информация, связанная с пользователем

В приведенной выше таблице приведены некоторые контекстные данные, связанные с пользователем. Они больше не упоминаются в следующих подробных определениях для удобства чтения, если их использование не является обязательным.

10.3. Особенности мультивалютного счета для информации по счету

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

Мультивалютные счета при чтении счетов или сведений о счетах

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

Мультивалютные счета при чтении балансов на уровне агрегации

Следствием этой функции является то, что возвращается массив балансов всех субсчетов, если мультивалютный счет адресуется на уровне агрегации. Валюта соответствующего субсчета неявно предоставляется как валюта элемента balanceAmount в балансе.

Мультивалютные счета при чтении транзакций на уровне агрегации

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

10.4 Чтение запросов данных счетов

В следующих разделах описывается доступ к чтению в текущих счетов.

1) Прочитывание список счетов

Вызов (call)

GET /v2/accounts {query-parameters}

Считывает список текущих счетов с указанием остатков средств, где это необходимо. Предполагается, что согласие пользователя на этот доступ уже получено и хранится в системе ASPSP. Таким образом, список адресованных счетов зависит от идентификатора пользователя и сохраненного согласия, адресованного consentId, соответственно, от токена доступа OAuth2.

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

Примечание: Если сведений, возвращенных в этом вызове с правами доступа «accountDetails», «balances», «transactions» или «ais», недостаточно, то дополнительные сведения можно получить, обратившись к конечной точке /accounts/{account-id}.

Параметры запроса

Атрибут	Тип	Условие	Описание
withBalance	Boolean	Необязательно	Если содержится, эта функция считывает список доступных платежных счетов, включая баланс, если это предоставлено пользователем в соответствующем согласии и доступно ASPSP. Этот параметр может быть проигнорирован ASPSP.

Заголовок запроса

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.
Consent-ID	Max70Text	Обязательно	в результате «Установления согласия на информацию об учетной записи», выполненного ранее через этот API.
PSU-IP-Address	String	Условно	Поле заголовка пересылаемого IP-адреса состоит из соответствующего поля IP-адреса HTTP-запроса между пользователем и TPP. Оно должно содержаться только в том случае, если этот запрос был активно инициирован пользователем.
Authorization	String	Условно	Содержится только в том случае, если на предварительном этапе была выполнена аутентификация на основе OAuth2 или при соответствующей авторизации согласия была выполнена аутентификация SCA на основе OAuth2.

Запрос тело

Отсутствует запроса тело.

Код ответа

Код ответа HTTP равен 200.

Заголовок ответа

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.

Тело ответа

Атрибут

Тип

Условие

Описание

accounts

Array of

Account Details

Обязательно

В случае, если ни один счет недоступен, ASPSP вернет пустой массив. Поскольку это также считается положительным ответом, код ответа по-прежнему должен быть 200.

2) Просмотр сведений о счете

Вызов

GET /v2/accounts/{account-id} {query-parameters}

Этот процесс позволяет получать сведения о текущем счёте, включая балансы, если это требуется. Предполагается, что согласие пользователя платёжных услуг на доступ уже получено и сохранено в системе ASPSP. Получаемые данные о счёте зависят от сохранённого согласия, связанного с идентификатором согласия (consentId) или, соответственно, токеном доступа OAuth2.

Примечание: Идентификатор счёта (account-id) может быть токенизирован для обеспечения защиты данных, так как информация о пути может записываться на промежуточных серверах в инфраструктуре ASPSP. Такой идентификатор счёта можно получить с помощью вызова метода «GET Account List» или из связанного ресурса согласия.

Примечание: Идентификатор счёта (account-id) может представлять мультивалютный счёт. В таком случае код валюты будет установлен как «XXX» в цифровом формате.

Параметры пути

Атрибут	Тип	Описание
account-id	Max70Text	Эта идентификация обозначает указанную счет. Account-id извлекается с помощью вызова «Read Account List». Account-id является атрибутом «resourceId» структуры счета. Его значение постоянно, по крайней мере, на протяжении всего жизненного цикла данного согласия.

Параметры запроса

Атрибут	Тип	Условие	Описание
withBalance	Boolean	Необязательно	Если содержится, эта функция считывает данные адресованного счета, включая баланс, если это предоставлено согласием пользователя, и если поддерживается ASPSP. Этот элемент данных может быть проигнорирован ASPSP.

Заголовок запроса

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.
Consent-ID	Max70Text	Обязательно
PSU-IP-Address	String	Условно	Поле заголовка пересылаемого IP-адреса состоит из соответствующего поля IP-адреса HTTP-запроса между пользователем и TPP. Оно должно содержаться только в том случае, если этот запрос был активно инициирован пользователем.
Authorization	String	Условно	Содержится только в том случае, если на предварительном этапе была выполнена аутентификация на основе OAuth2 или при соответствующей авторизации согласия была выполнена аутентификация SCA на основе OAuth2.

Тело ответа

Атрибут	Тип	Условие	Описание
account	Account Details	Обязательно

3) Чтение данных о балансе

Вызов

GET /v2/accounts/{account-id}/balances

Чтение данных о балансе для указанного счета, идентифицированного с помощью параметра «account-id».

Параметры пути

Атрибут	Тип	Описание
account-id	Max70Text	Эта идентификация обозначает адресованную счет. Account-id извлекается с помощью вызова «Read Account List». Account-id является атрибутом «resourceId» структуры счета. Его значение постоянно, по крайней мере, на протяжении всего жизненного цикла данного согласия.

Параметры запроса

Конкретных параметров запроса нет.

Код ответа

Код ответа HTTP равен 200.

Заголовок запроса

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.
PSU-IP-Address	String	Условно	Поле заголовка пересылаемого IP-адреса состоит из соответствующего поля IP-адреса HTTP-запроса между пользователем и TPP. Оно должно содержаться только в том случае, если этот запрос был активно инициирован пользователем.
Consent-ID	String	Обязательно
Authorization	String	Условно	Содержится только в том случае, если на предварительном этапе была выполнена аутентификация на основе OAuth2 или при соответствующей авторизации согласия была выполнена аутентификация SCA на основе OAuth2.

Запрос тело

Запроса тело нет.

Заголовок ответа

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.

Тело ответа

Атрибут	Тип	Условие	Описание
account	Account Reference	Обязательно	Идентификатор адресуемого счета.
balances	Array of Balance	Обязательно	Список остатков по данному счету, например, текущий остаток, последний зачисленный остаток.

4) Прочитать список транзакций

Вызов

GET /v2/accounts/{account-id}/transactions {query-parameters}

Запрашивает данные о транзакциях по указанному счёту, идентифицированному параметром «account-id». Это могут быть как проведённые (booked), так и ожидающие обработки (pending) транзакции, а также список постоянных платёжных поручений и другая дополнительная информация о транзакциях.

Примечание: ASPSP может использовать стандартные методы сжатия данных на уровне приложения для ответа, что указывается в заголовке content-encoding. В случае возврата форматов camt.05x, в одном ответе может содержаться несколько файлов camt.05x. Некоторые ASPSP, например, могут разделять файлы camt.05x по дням бухгалтерской записи — аналогично практике, применяемой в онлайн-каналах.

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

Примечание: Обратите внимание, что все параметры пути могут быть уже детально указаны неявно в ответе вызова «Прочитать список счетов» (Read Account List) в подполе _links.

Параметры пути

Атрибут	Тип	Описание
account-id	String	Эта идентификация обозначает адресованную счет. Account-id извлекается с помощью вызова «Read Account List». Account-id является атрибутом «resourceId» структуры учетной записи. Его значение постоянно, по крайней мере, на протяжении всего жизненного цикла данного согласия.

Параметры запроса

Атрибут	Тип	Условие	Описание
dateFrom	ISODate	Условно	Начальная дата (включая дату dateFrom) списка транзакций, обязательная, если не требуется доступ к дельте и если bookingStatus не равен «information». Может игнорироваться, если используется функция дельты или если bookingStatus равен «information». Для забронированных транзакций соответствующей датой является дата бронирования. Для ожидающих транзакций соответствующей датой является дата входа, которая может быть непрозрачной ни в этом API, ни в других каналах ASPSP. Если bookingStatus равен «all», эта дата может игнорироваться для всех транзакций, на которые ссылается bookingStatus «information».
dateTo	ISODate	Необязательно	Дата окончания (включая дату dateTo) списка транзакций, по умолчанию «сегодня», если не указано. Может игнорироваться, если используется дельта-функция. Для забронированных транзакций соответствующей датой является дата бронирования. Для ожидающих транзакций соответствующей датой является дата входа, которая может быть непрозрачной ни в этом API, ни в других каналах ASPSP. Если bookingStatus равен «all», эта дата может игнорироваться для всех транзакций, на которые ссылается bookingStatus «information».
entryReferenceFrom	Max35Text	Необязательно, если поддерживается поставщиком API	Этот атрибут данных указывает, что AISP выступает за получение всех транзакций после транзакции с идентификацией entryReference entryReferenceFrom в качестве альтернативы определенному выше периоду. Это реализация дельта-доступа. Если этот элемент данных содержится, записи «dateFrom» и «dateTo» могут быть проигнорированы ASPSP, если поддерживается дельта-отчет.
pageSize	Integer	Необязательно если поддерживается поставщиком API	Этот параметр запроса определяет записи транзакций на вызов, которые необходимо извлечь для расширенных служб. Если не поддерживается, то вызов отклоняется. Если поддерживается ASPSP и если значение превышает maxPageSize, как определено ASPSP в его документации, то вызов отклоняется.
bookingStatus	Max35Text	Обязательно	Разрешенные коды: «booked», «pending», «both», «information» и «all». «booked» должно поддерживаться ASPSP. Поддержка функции «pending» является условием для ASPSP. Она обязательна, если онлайн-каналы ASPSP предоставляют ожидающие транзакции пользователю. Если не поддерживается отображается код ошибки. Поддержка функции «both» является необязательной для ASPSP, если не поддерживается отображается код ошибки. Если поддерживается, «both» означает запрос списков транзакций bookingStatus либо «pending», либо «booked». Поддержка функции «information» является необязательной для ASPSP. Если не поддерживается отображается код ошибки. Поддержка функции «all» является необязательной для ASPSP, если не поддерживается отображается код ошибки. Если поддерживается, «all» означает запрос списков транзакций любого bookingStatus («pending», «booked» или «information»).
deltaList	Boolean	Необязательно если поддерживается поставщиком API	Этот атрибут данных указывает, что AISP поддерживает получение всех транзакций после последнего отчета доступа для этого пользователя на адресованном счете. Это еще одна реализация отчета о доступе с разницей. Этот индикатор разности может быть отклонен ASPSP, если эта функция не поддерживается. Если этот элемент данных содержится, записи «dateFrom» и «dateTo» могут быть проигнорированы ASPSP, если поддерживается отчет с разницей.
withBalance	Boolean	Необязательно	Если содержится, эта функция считывает список транзакций, включая баланс бронирования, если это предоставлено пользователем соответствующего согласие и доступно ASPSP. Этот параметр может быть проигнорирован ASPSP.

Примечание: В случае, если bookingStatus имеет значение «information», параметры запроса dateFrom, dateTo, withBalance, deltaList и entryReferenceFrom будут игнорироваться и не окажут влияния на результат.

Заголовок запроса

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.
PSU-IP-Address	String	Условно	Поле заголовка пересылаемого IP-адреса состоит из соответствующего поля IP-адреса HTTP-запроса между пользователем и TPP. Оно должно содержаться только в том случае, если этот запрос был активно инициирован пользователем.
Consent-ID	Max70Text	Обязательно
Authorization	String	Условно	Содержится только в том случае, если на предварительном этапе была выполнена аутентификация на основе OAuth2 или при соответствующей авторизации согласия была выполнена аутентификация SCA на основе OAuth2.
Accept	String	Необязательно	TPP может указывать поддерживаемые форматы отчетов по счетам вместе с приоритетом после определения заголовка HTTP. Форматы, поддерживаемые этой спецификацией: • xml; • JSON; • text.

Примечание: Планируется применение значения vnd-entries в атрибуте accept для форматов camt.05x и MT94x, чтобы учитывать различные форматы отчетов по счетам, доступные для пользователя, например, в корпоративном контексте. В этом случае сторонний поставщик услуг может, например, указать: «Я предпочитаю camt.054, но возьму camt.053, если он недоступен.» Это решение рекомендуется в качестве лучшей практики до его полной спецификации.

Запрос тело

Отсутствует запрос тело.

Код ответа

Код ответа HTTP равен 200.

Заголовок запроса

Атрибут

Тип

Условие

Описание

Content-Type

String

Обязательно

Возможные значения:

• application/json

• application/xml

• text/plain

X-Request-ID

UUID

Обязательно

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

Тело ответа

Если ASPSP возвращает XML-структуру формата camt.05x, то ответ тело состоит либо из формата camt.052, либо camt.053. Формат camt.052 может содержать ожидающие (не проведенные) платежи. Выбор формата зависит от ASPSP на основании выбранных параметров, в частности, дат, указанных относительно времени запроса. Кроме того, ASPSP может предложить структуру camt.054x, например, в корпоративной среде.

Если ASPSP возвращает содержимое формата MT94x, то тело ответа состоит из формата MT940 или MT942 в текстовой структуре. Формат MT942 может включать ожидающие (не проведенные) платежи. Выбор формата также зависит от ASPSP на основании выбранных параметров, в частности, дат, указанных относительно времени запроса.

Ответ в формате JSON определяется следующим образом:

	Атрибут		Тип		Условие		Описание
	account		Account Reference		Обязательно		Идентификатор адресуемого счета.
transactions		Account Report		Необязательно		Отчет по счету на основе JSON. Этот отчет по счету содержит транзакции, полученные в результате параметров запроса. Примечание: рекомендуется предоставить атрибуты информации о переводе уже здесь, а не только в деталях транзакции. Такая реализация позволяет избежать слишком частого использования деталей транзакции клиентами API.
	balances		Array of Balance		Необязательно		Список остатков по данному счету, который может быть ограничен текущим остатком.
	_links		Links		Необязательно		Список гиперссылок, которые должен распознать TPP. Тип ссылок, разрешенных в этом ответе: «download»: ссылка на ресурс, откуда может быть загружен список транзакций в случае, если списки транзакций имеют огромный размер. Примечание: эта функция должна использоваться только в случае, если запрашиваются camt-data, которые имеют огромный размер.

5) Вызов для чтения деталей транзакции

Вызов

GET /v2/accounts/{account-id}/transactions/{transactionId}

Запрашивает детали транзакции, идентифицированной параметром «transactionId», по заданному счёту, идентифицированному параметром «account-id». Этот вызов доступен только для транзакций, представленных в формате JSON.

Примечание: Обратите внимание, что все параметры пути могут быть уже указаны неявно в соответствующей записи ответа вызова «Чтение списка транзакций» (Read Transaction List) в подполе _links.

Параметры пути:

Атрибут	Тип	Описание
account-id	String	Данная идентификация обозначает адрес счета, на который была совершена транзакция.
transactionId	String	Эта идентификация задается атрибутом transactionId соответствующей записи списка транзакций.

Параметры запроса

Параметров запроса нет

Заголовка запроса

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.
PSU-IP-Address	String	Условно	Поле заголовка пересылаемого IP-адреса состоит из соответствующего поля IP-адреса HTTP-запроса между пользователем и TPP. Оно должно содержаться только в том случае, если этот запрос был активно инициирован пользователем.
Consent-ID	String	Обязательно
Authorization	String	Условно	Содержится только в том случае, если на предварительном этапе была выполнена аутентификация на основе OAuth2 или при соответствующей авторизации согласия была выполнена аутентификация SCA на основе OAuth2.

Запрос тело

Запроса тело нет.

Код ответа

Код ответа HTTP равен 200.

Заголовок ответа

Атрибут

Тип

Условие

Описание

Content-Type

String

Обязательно

Возможные значения:

• application/json

X-Request-ID

UUID

Обязательно

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

Тело ответа

Атрибут	Тип	Условие	Описание
transactionsDetails	Transactions	Необязательно

10.5. Запросы данных о банковских платежных картах

1) Вызов для чтения списка счетов карт

GET /v2/card-accounts

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

Параметры запроса

Поддержка параметров запроса отсутствует.

Заголовок запроса

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.
PSU-IP-Address	String	Условно	Поле заголовка пересылаемого IP-адреса состоит из красных полей IP-адреса HTTP-запроса между пользователем и TPP. Оно должно сохраняться только в том случае, если этот запрос был активно инициирован пользователем.
Consent-ID	String	Обязательно	В результате «Установить согласие на транзакцию с данными счетов», выполненной ранее через этот API.
Authorization	String	Условно	Содержится только в том случае, если на предварительном этапе была выполнена аутентификация на основе OAuth2 или при соответствующей авторизации согласия была выполнена аутентификация SCA на основе OAuth2.

Запрос тело

Запроса тело нет.

Ответ кода

Ответ кода HTTP равен 200.

Заголовка ответа

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.

Тело ответа

Атрибут	Тип	Условие	Описание
cardAccounts	Array of Card Account Details	Обязательно	В случае, если ни один счет карты не доступен, ASPSP должен вернуть пустой массив. Поскольку это также считается положительным ответом, код ответа должен быть по-прежнему 200.

2) Вызов для просмотра деталей счёта карты

GET /v2/card-accounts/{account-id}

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

Параметры пути:

Атрибут	Тип	Описание
account-id	String	Эта идентификация обозначает адресованный счет карты. Account-id извлекается с помощью вызова «Read Card Account List». Account-id — это атрибут «resourceId» структуры счета. Его значение постоянно, по крайней мере, на протяжении всего жизненного цикла данного согласия.

Параметры запроса

Параметры запроса не определены.

Заголовка запроса

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.
PSU-IP-Address	String	Условно	Поле заголовка пересылаемого IP-адреса состоит из соответствующего поля IP-адреса HTTP-запроса между пользователем и TPP. Оно должно содержаться только в том случае, если этот запрос был активно инициирован пользователем.
Consent-ID	String	Обязательно	Идентификация согласия на доступ, предоставленного пользователя.
Authorization	String	Условно	Содержится только в том случае, если на предварительном этапе была выполнена аутентификация на основе OAuth2 или при соответствующей авторизации согласия была выполнена аутентификация SCA на основе OAuth2.

Запрос тело

Запроса тело нет

Код ответа

Код ответа HTTP равен 200.

Заголовка ответа

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.

Ответ тело

Атрибут	Тип	Условие	Описание
cardAccount	Card Account Details	Обязательно

3) Вызов для просмотра баланса счета по банковским платежным картам

GET /v2/card-accounts/{account-id}/balances

Запрашивает данные о балансе для указанного счёта карты, идентифицированного параметром «account-id».

Примечание: Для защиты данных account-id может быть токенизированным идентификатором, поскольку информация пути может быть зарегистрирована на промежуточных серверах в пределах сферы ASPSP. Этот account-id можно получить с помощью вызова «GET Card Account List» или из связанного ресурса согласия.

Параметры пути:

· account-id: Идентификатор счёта карты, для которого запрашиваются данные о балансе.

Атрибут	Тип	Описание
account-id	String	Эта идентификация обозначает адресованный счет карты. Account-id извлекается с помощью вызова «Read Account List». Account-id — это атрибут «resourceId» структуры счета. Его значение постоянно, по крайней мере, на протяжении всего жизненного цикла данного согласия.

Параметры запроса

Конкретных параметров запроса нет.

Код ответа

Код ответа HTTP равен 200.

Заголовок запроса

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.
PSU-IP-Address	String	Условно	Поле заголовка пересылаемого IP-адреса состоит из соответствующего поля IP-адреса HTTP-запроса между пользователем и TPP. Оно должно содержаться только в том случае, если этот запрос был активно инициирован пользователем.
Consent-ID	String	Обязательно	Указание соответствующего согласия, предоставленного пользователем.
Authorization	String	Условно	Содержится только в том случае, если на предварительном этапе была выполнена аутентификация на основе OAuth2 или при соответствующей авторизации согласия была выполнена аутентификация SCA на основе OAuth2.

Запрос тело

Запроса тело нет.

Заголовка ответа

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.

Ответ тело

Атрибут	Тип	Условие	Описание
cardAccount	Account Reference	Обязательно	Идентификатор счета адресованной карты.
debitAccounting	Boolean	Необязательно	Если true, суммы дебетов в отчетах указываются как положительные с соответствующими последствиями для остатков. Если false, суммы дебетов в отчетах указываются как отрицательные.
balances	Array of Balance	Обязательно	Список остатков по этому карточному счету, например, текущий остаток, последний зарезервированный остаток.

4) Вызов для просмотра списка транзакций по счёту банковских платежных карт

GET /v2/card-accounts/{account-id}/transactions {query-parameters}

Запрашивает данные о транзакциях для указанного счёта карты, идентифицированного параметром «account-id».

Примечание: Для защиты данных account-id является токенизированным идентификатором, поскольку информация пути может быть зарегистрирована на промежуточных серверах в пределах сферы ASPSP. Этот account-id можно получить с помощью вызова «GET Card Account List».

Примечание: ASPSP может использовать стандартные методы сжатия данных на уровне приложения для ответа, что указывается в заголовке content-encoding.

Примечание: Обратите внимание, что все параметры пути могут быть уже указаны неявно в ответе вызова «Чтение списка счетов карт» (Read Card Account List) в подполе _links.

Параметры пути:

Атрибут	Тип	Описание
account-id	String	Эта идентификация обозначает адресованный счет карты. Account-id извлекается с помощью вызова «Read Card Account List». Account-id — это атрибут «resourceId» структуры счета. Его значение постоянно, по крайней мере, на протяжении всего жизненного цикла данного согласия.

Параметры запроса

Атрибут	Тип	Условие	Описание
dateFrom	ISODate	Условно	Начальная дата (включая дату dateFrom) списка транзакций, обязательна, если не требуется дельта-доступ
dateTo	ISODate	Необязательно	Дата окончания (включая дату dateTo) списка транзакций, по умолчанию «сегодня», если не указано иное.
pageSize	Integer	Необязательно если поддерживается API поставщиком	Этот параметр запроса определяет записи транзакций на вызов, которые необходимо извлечь для расширенных служб. Если не поддерживается, то вызов отклоняется. Если поддерживается ASPSP и если значение превышает maxPageSize, как определено ASPSP в его документации, то вызов отклоняется.
bookingStatus	String	Обязательно	Разрешенные коды — «booked», «pending», «both» и «booked» должно поддерживаться ASPSP. Поддержка функций «pending» и «both» является необязательной для ASPSP, код ошибки, если он не поддерживается в интерфейсе онлайн-банкинга.
deltaList	Boolean	Необязательно если поддерживается API поставщиком	Этот атрибут данных указывает, что AISP выступает за получение всех транзакций после последнего отчета доступа для этого пользователя на адресованном счете. Этот индикатор дельты может быть отклонен ASPSP, если эта функция не поддерживается.

Заголовок запроса

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.
PSU-IP-Address	String	Условно	Поле заголовка пересылаемого IP-адреса состоит из соответствующего поля IP-адреса HTTP-запроса между пользователем и TPP. Оно должно содержаться только в том случае, если этот запрос был активно инициирован пользователем.
Consent-ID	String	Обязательно	Идентификация согласия на этот доступ, предоставленного пользователем.
Authorization	String	Условно	Содержится только в том случае, если на предварительном этапе была выполнена аутентификация на основе OAuth2 или при соответствующей авторизации согласия была выполнена аутентификация SCA на основе OAuth2.

Запрос тело

Запрос тело нет.

Код ответа

Код ответа HTTP равен 200.

Заголовка ответа

Атрибут	Тип	Условие	Описание
X-Request-ID	UUID	Обязательно	Идентификатор запроса, уникальный для вызова, определяемый инициирующей стороной.

Ответ тело

Атрибут	Тип	Условие	Описание
cardAccount	Account Reference	Обязательно	Идентификатор счета адресованной карты.
debitAccounting	Boolean	Необязательно	Если true, суммы дебетов в отчетах указываются положительными с соответствующими последствиями для остатков. Если false, суммы дебетов в отчетах указываются отрицательными.
cardTransactions	Card Account Report	Необязательно	Отчет по счету на основе JSON.
balances	Array of Balance	Необязательно	Список остатков по данному счету, который может быть ограничен текущим остатком.
_links	Links	Необязательно	Список гиперссылок, которые должен распознать TPP. Тип ссылок, разрешенных в этом ответе: «download»: ссылка на ресурс, откуда можно загрузить список транзакций в случае, если списки транзакций имеют огромный размер.

Контакты

Быстрые ссылки