В последнюю неделю декабря Банк России утвердил и опубликовал десять стандартов, описывающих взаимодействие через Открытые API для участников финансового рынка [1]. Документы охватывают общие положения и глоссарий, профили безопасности, прикладные спецификации для обмена информацией о счетах и согласиями на доступ к ней — как для физических, так и для юридических лиц [2].
Утвержденные стандарты пропилотированы на практике и на их основе уже работают новые клиентские сервисы в ряде крупнейших банков России [3]. На текущем этапе стандарты Открытых API носят рекомендательный характер, однако Банк России указывает на их роль как основы для дальнейшего развития нормативной и технологической базы Открытых API и прорабатывает законодательную базу для перехода к их обязательному применению [4].
Переход участников пилотных проектов на обновленные версии спецификаций запланирован с 1 октября 2026 года. Согласно «дорожной карте» Банка России к этому же времени также начнется промышленная эксплуатация платформы коммерческих согласий [5]. Ожидается, что инфраструктура Открытых API приблизится к тому, чтобы стать одним из ключевых элементов цифровых сервисов, требующих стандартизированного безопасного обмена данными между банками, финтех-компаниями и поставщиками сервисов.
Такой обмен обещает придать существенное ускорение разработке и выводу на рынок разнообразных инновационных решений, с помощью которых клиенты смогут бесшовно управлять своими финансами.
Тем не менее подключение к среде открытого информационного взаимодействия остается нетривиальной инженерной задачей: требования к безопасности, криптографии, процедурам регистрации участников и обработке согласий конечного пользователя услуг формируют высокую точку входа. Эти факторы влияют на сроки реализации проектов и стоимость их обслуживания.
В конце 2024 года Банк России предложил разработать типовое ПО, которое обеспечило бы участникам рынка единообразную архитектуру подключения к открытому информационному обмену без необходимости создавать собственную систему с нуля. Проработку проекта создания бесплатного «коробочного решения» регулятор поручил Ассоциации ФинТех (АФТ) [6].
В сентябре 2025 года на площадке Ассоциации ФинТех прошла первая публичная демонстрация решения, разработанного при поддержке финтех-компании eKassir, ранее уже сотрудничавшей с АФТ при создании Сертификационного стенда Открытых API. Были продемонстрированы архитектура, функциональные модули ПО и сценарии взаимодействия участников среды Открытых API.
Почему внедрение Открытых API — дорогой и трудоемкий процесс
На момент публикации статьи единые стандарты Открытых API на площадке АФТ тестируют два десятка крупных банков, страховых компаний и медицинских организаций. К настоящему времени сформирована эмпирическая база, показывающая комплексность задач по внедрению Открытых API и необходимость актуализировать их под изменяющиеся регуляторные положения. [7]
У организаций есть два формальных пути подключения к открытому информационному обмену с клиентами и партнерами: самостоятельная интеграция и типовое решение. Первый вариант предполагает полный цикл реализации требований по безопасности и протоколам обмена, поддержку спецификаций и прохождение оценки влияния программного обеспечения на СКЗИ. Фактически команда разработки участника, самостоятельно занимающегося внедрением, должна разработать и поддержать несколько узловых систем:
Чтобы сэкономить время и стоимость владения таким решением, необходимо распараллелить эти задачи, однако в этом случае неизбежно усложнение планирования цикла разработки и, как следствие, увеличение нагрузки на инхаус-команду.
Подход типового решения: единая архитектура, снижение порога входа
Типовое программное решение, разрабатываемое под патронажем Ассоциации ФинТех, закрывает ключевые требования по принципу базовой доступности — когда функциональность реализуется «из коробки» и исключает необходимость ручной реализации критически важных компонентов.
Такое ПО поддерживает стандарты безопасности Банка России ФАПИ.СЕК и ФАПИ.ПАОК, обладает заключением ФСБ РФ о категории уровня влияния и сопрягается с различными криптопровайдерами СКЗИ, например, «Янтарь L» и «КриптоПро» [8]. Благодаря этому снижается зависимость от конкретной реализации системы криптографии и позволяет финансовым организациям гибко интегрироваться с инфраструктурой Открытых API.
Функциональная структура решения включает:
Типовое решение реализует базовые процессы информационного обмена, включая регистрацию участников, оркестрацию взаимодействия, управление жизненным циклом согласий пользователей и синхронизацию прикладных алгоритмов.
Архитектура типового решения и контур безопасности
Архитектура типового решения построена на структурированном разделении ролей между компонентами. Вся бизнес-логика сосредоточена в сервисных нодах, тогда как криптография, хранилища данных, проксирование трафика и СКЗИ вынесены в отдельный инфраструктурный контур. Такой подход позволяет масштабировать систему за счет добавления сервисных нод и перераспределения нагрузки по хостам, не затрагивая криптографию и базовые механизмы обмена данными между его участниками.
Сетевой шлюз (Network Gateway) обеспечивает криптографическую защиту и терминацию ГОСТ-трафика. Взаимодействие компонентов построено на mTLS с взаимной аутентификацией, а для токенов и подписей задействованы Удостоверяющий центр и хранилище ключей JWKS, входящие в контур доверенной среды Открытых API.
При подобном подходе снижаются риски ошибок при реализации криптографических протоколов, что упрощает эксплуатацию открытого информационного обмена и регуляторного аудита.
Как создается ресурс согласия пользователя на обмен его данными
Напомним, что краеугольным камнем информационного обмена через Открытые API являются согласия клиентов на использование, хранение и обработку бизнес-данных, которые они передают поставщикам услуг. И основным сценарием при массовом переходе рынка к применению Открытых API будет создание ресурса согласия. Процесс выглядит следующим образом:
Запрос и получение ресурса согласия при сценарии работы с типовым решением полностью соответствует протоколам безопасности среды Открытых API, а изолированный контур с криптографией обеспечивает реализацию информационного обмена без необходимости разворачивать собственную инфраструктуру шифрования и токенизации.
Прикладная ценность типового решения
В практическом смысле типовое решение переводит подключение к Открытым API из сложного инженерного проекта в управляемый инфраструктурный процесс. Оно снимает необходимость самостоятельно проектировать защищенный контур обмена, реализовывать криптографию и поддерживать соответствие требованиям по безопасности передачи данных. Эти задачи решены на уровне разработки и не требуют повторной реализации со стороны участников.
За счет этого интеграция становится воспроизводимой и предсказуемой. Единый подход к протоколам и механизмам взаимодействия снижает количество технических согласований и устраняет расхождения в реализации стандартов. Поддержка ГОСТ-трафика и нескольких вендоров СКЗИ упрощает эксплуатацию в регламентированной среде, а архитектурное разделение компонентов позволяет масштабировать решение и развивать его без вмешательства в базовый инфраструктурный контур.
Для российского финансового рынка развитие среды Открытых API — не столько эксперимент, сколько попытка сформировать технологически и организационно управляемую модель взаимодействия участников. Предложение типового решения позволяет снизить фрагментацию инфраструктурных моделей, сократить количество индивидуальных реализаций и, как следствие, уменьшить совокупные операционные и регуляторные риски в экосистеме [9].
Отдельного внимания заслуживает модель распространения решения. Оно предоставляется на безвозмездной основе, что снимает коммерческий порог входа и делает его доступным не только для крупных банков, но и для небольших финансовых организаций и финтех-компаний. В такой конфигурации фокус естественным образом смещается с конкуренции инфраструктур на развитие сервисов, пользовательских сценариев и прикладных продуктов, что соответствует логике дальнейшей эволюции Открытых API.
Типовое решение может стать универсальным практическим инструментом применения утвержденных стандартов Открытых API, позволяя всем участникам нового информационного обмена работать в едином технологическом контуре, без необходимости самостоятельно интерпретировать и реализовывать требования новых документов, а переключить освободившиеся ресурсы на создание новых клиентских решений для управления финансами.
[1] «Банк России обновил комплекс стандартов Открытых API»
[2] https://www.cbr.ru/Content/Document/File/185561/20251219_od_2888.pdf
[3] https://frankmedia.ru/224334
[4] https://cbr.ru/press/event/?id=28214
[5] «Основные принципы и этапы внедрения Открытых API на финансовом рынке»
[6] https://bosfera.ru/bo/open-api-vnedrit-i-ispolzovat
[7] https://frankmedia.ru/224334
[8] «Защищая API, нужно сократить расходы на ИБ»
- Стоимость медиауслуг (открыть PDF) -
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
