OPEN API
Проблематика
Для успешного внедрения и повсеместного использования Open API в банковской сфере по спецификациям Центрального Банка, разработанным в рамках инициативы Open Banking, необходимо расширение стандартов и предложения по их использованию, чтобы эти API позволяли удовлетворять широкий спектр клиентских потребностей. Текущая версия спецификаций затрагивает лишь часть функций (информация о счёте, перевод денежных средств, управление продуктами кредитной организации), однако финансовые организации предлагают более широкий список услуг.
Самым простым решением проблемы является перенос всего существующего банковского API прямо в спецификацию Open API, однако это невозможно из-за существенных различий в системах разных финансовых организаций. Поэтому требуется разработать общие унифицированные спецификации методов API, которые будут удовлетворять потребности большинства организаций. Эти спецификации должны быть гибкими и допускающими расширение, так как новые требования могут возникнуть со временем.
Самым простым решением проблемы является перенос всего существующего банковского API прямо в спецификацию Open API, однако это невозможно из-за существенных различий в системах разных финансовых организаций. Поэтому требуется разработать общие унифицированные спецификации методов API, которые будут удовлетворять потребности большинства организаций. Эти спецификации должны быть гибкими и допускающими расширение, так как новые требования могут возникнуть со временем.
Образ решения
В рамках хакатона участникам предстоит создать прототип приложения, позволяющего пользователям получать доступ к услугам или данным банка, предлагаемым финансовой организацией. Желательно, чтобы прототип включал в себя самую разнообразную функциональность, которая может понадобиться потенциальному пользователю.
Помимо создания прототипа приложения, необходимо расширить существующие спецификации Open API с учётом новых функций, которые будут доступны потенциальному пользователю. Так как текущая спецификация методов, предложенная в рамках инициативы Open Banking, содержит лишь малую часть функций, требуется предложить и описать набор новых методов API, которые необходимы для корректной работы прототипа. Описание новых методов должно содержать формат передаваемых данных и операций, необходимых для взаимодействия прототипа приложения с внешними системами, и интеграции с различными банковскими сервисами.
Учтите, что описываемые вами операции должны быть достаточно универсальными и не зависеть от конкретной реализации информационной системы какой-либо финансовой организации. Это важно для того, чтобы данные операции могли быть включены в общий стандарт в рамках инициативы Open Banking.
Участникам будет предоставлен доступ к тестовым стендам с заглушками и существующей спецификацией Open API для тестирования и валидации их решений.
Помимо создания прототипа приложения, необходимо расширить существующие спецификации Open API с учётом новых функций, которые будут доступны потенциальному пользователю. Так как текущая спецификация методов, предложенная в рамках инициативы Open Banking, содержит лишь малую часть функций, требуется предложить и описать набор новых методов API, которые необходимы для корректной работы прототипа. Описание новых методов должно содержать формат передаваемых данных и операций, необходимых для взаимодействия прототипа приложения с внешними системами, и интеграции с различными банковскими сервисами.
Учтите, что описываемые вами операции должны быть достаточно универсальными и не зависеть от конкретной реализации информационной системы какой-либо финансовой организации. Это важно для того, чтобы данные операции могли быть включены в общий стандарт в рамках инициативы Open Banking.
Участникам будет предоставлен доступ к тестовым стендам с заглушками и существующей спецификацией Open API для тестирования и валидации их решений.
Формат загрузки решения
Решение должно быть загружено на платформу не позднее 10 ноября в следующем виде:
- краткое описание решения;
- ссылка на открытый Github;
- ссылка на swagger-спецификацию (на развернутом сервисе или на диск с файлом .json);
- ссылка на презентацию в формате .pdf;
- ссылка на развернутое решение (при наличии).
Обращаем ваше внимание, что если ваше решение имеет кодовую часть — оно в обязательном порядке должно сопровождаться SCA (Static Code Analysis). Детальная инструкция по тому, как это сделать, находится здесь → Инструкция по добавлению SCA.
Оптимальный состав команды
- 2 Backend-специалиста;
- 1 Frontend-специалист;
- 1 аналитик:
- 1 DevRel.*
* Привлекать таких специалистов следует в случае полного формирования команды (5 человек), когда закрыты все необходимые компетенции (Backend-специалист, Frontend-специалист и аналитик).
Критерии оценивания
1. Оценка качества кода.
2. Оценка детализации API.
3. Оценка применимости решения, его инновационности и значимости.
4. Оценка безопасности архитектуры решения.
2. Оценка детализации API.
3. Оценка применимости решения, его инновационности и значимости.
4. Оценка безопасности архитектуры решения.
