Установить единые правила управления версиями спецификаций и стандартов Открытых API, включая классификацию изменений, порядок их включения в версии, а также прекращение и продолжение поддержки версий. Политика направлена на обеспечение прозрачности, управляемости и предсказуемости в работе с версиями для всех участников пилота.
Документ распространяется на все спецификации и стандарты, разрабатываемые в рамках пилотных инициатив Open API. Политика применяется при планировании, выпуске, согласовании и сопровождении версий, а также при взаимодействии с участниками и регулятором (включая выполнение требований пункта 4.2.6 Общих Положений).
Политика версионирования не регулирует оценку и приоритезацию отдельных запросов на изменения, процедуры согласования с регулятором, вопросы внутренней реализации и релизного цикла на стороне участников, а также нестандартизированные решения, реализуемые вне рамок утверждённых версий спецификаций. В таких случаях участники договариваются между собой и информируют АФТ о принятом решении.
Подробная и всегда актуальная информация по всем версиям и их статусам будет вестись в отдельном документе «Реестр версий стандартов» (ссылка будет добавлена позднее).
Текущий контекст (на сентябрь 2025) на примере Рабочей группы Стандартов по счетам физических лиц:
|
Версия |
Назначение |
Статус |
| v1.3.6(7) | Историческая, все интеграции участников построены на ней | Поддержка ограничена, изменения не вносятся |
| v2.0 | Централизованная версия для согласования с Банком России | Согласована на Экспертном Совете, направлена в Банк России на утверждение |
| v2.1 | Вариант v2.0 с расширением под депозиты | Ограниченное применение только для желающих пилотировать депозиты, частный случай v2.0 |
| v2.2. | Вариант v2.0 с расширением под обезличенные металлические счета (и учетом депозитов) | Ограниченное применение только для желающих пилотировать обезличенные металлические счета, также внесены изменения по маскированному и PАN. Форк-версия от v.2.1. |
Текущий контекст (на сентябрь 2025) на примере Рабочей группы Стандартов по счетам юридических лиц
|
Версия |
Назначение |
Статус |
| V1.3.3 | Историческая, все интеграции участников построены на ней | Поддержка ограничена, изменения не вносятся |
| v.2.0. | Промежуточная версия | Размещена на БЗ, не требует проведения интеграций по ней |
| v3.0 | Централизованная версия для согласования с Банком России | Согласована на Экспертном Совете, направлена в Банк России, изменения были внесены по истории операций после направления в Банк России |
Дополняют раздел 4.2.6 Общих Положений.
| ТИП ИЗМЕНЕНИЯ | КРИТЕРИИ | ПРИМЕРЫ | ПРОЦЕДУРА СОГЛАСОВАНИЯ |
| МАЖОРНОЕ | Нарушает обратную совместимость | Изменение обязательности поля, смена структуры, архитектурный рефакторинг | Банк России |
| МИНОРНОЕ | Добавляет совместимый функционал | Новый endpoint, продукты, необязательные поля | Банк России |
| ПАТЧ | Исправления без изменения логики и обратной совместимости | Опечатки в документации, исправления в описании, схемах, примерах, не влияющие на API-контракт | Экспертный совет |
Примеры:
• Мажорное изменение (например, из 0..1 в 1..1): в будущую v3.0
• Новая сущность или endpoint: в минорную (v2.3)
• Уточнение логики (описание, схемы, примеры): в патч
• Изменения в v1.3: не принимаются, только критические багфиксы в исключительных случаях
• Коммерчески мотивированные: только при архитектурной совместимости и наличии консенсуса между участниками, АФТ и регулятором
Новые минорные и мажорные версии стандартов формируются и выпускаются не чаще одного раза в квартал. Данный цикл не распространяется на выпуск патч-версий, которые выпускаются по мере необходимости для исправления критических багфиксов.
Критический багфикс - исправление, устраняющее ошибку, которая:
1. В версии, уже направленные в Банк России, изменения не вносятся. Обновления оформляются отдельной новой версией (например, v2.2).
2. Патчи (X.Y.Z) допускаются при:
3. Минорные изменения (X.Y) вносятся в активные версии, если не нарушают совместимость и не затрагивают архитектуру.
1. Снятие версии с поддержки означает, что АФТ прекращают ее техническое сопровождение: перестают выпускать исправления (патчи), не вносит изменений и не оказывают консультации по ее интеграции. Участники среды не гарантируют работоспособность версии. Устаревшие версии исключаются из активной поддержки по решению АФТ при отсутствии внедрений или переходе участников на более актуальные версии.
2. Поддержка мажорных версий:
3. Поддержка минорных версий
4. Использование неподдерживаемых версий
Приложение 1. Матрица определения версий спецификаций Открытых API
(на примере пилота по счетам физических лиц)
| Тип изменения | Описание | Версия | Условия принятия |
|---|---|---|---|
| Критические багфиксы | Исправления ошибок, влияющих на работу, без изменения логики | v1.3.x (исключительно), все остальные версии | Только если критично для участников или по требованию Банка России |
| Уточнение описаний, примеров | Правки текстов, разделов, наименований, уточнение формулировок | v2.0.1 (или патч к текущей версии) | Не влияет на поведение API |
| Добавление необязательных атрибутов, enum, новых методов | Расширение функционала без изменений в существующих контрактах | v2.1 и далее | Не требует изменений на стороне действующих интеграций |
| Изменение обязательности атрибута (был необязательный атрибут, стал обязательный) | Меняет поведение API, может вызвать ошибки у текущих интеграций | Только v3.0 | Требует согласия всех участников, фиксируется как изменение, влияющее на совместимость |
| Изменение логики фильтрации, сортировки, паттернов валидации | Меняет правила поведения, возможны расхождения с действующими реализациями | v2.1 и далее | Обсуждается и принимается только после голосования, технического анализа и согласования с участниками |
| Новые архитектурные подходы (например, кэш, маркеры, алгоритмы) | Логика обработки вне контракта, связанная с внутренней реализацией банка | Не включается в спецификацию/ стандарт | Оформляется как рекомендация (best practices) или отдельный методический документ |
| Изменения в версии, уже направленной в Банк России | Любые изменения после фиксации версии | Не включается в спецификацию/ стандарт | Не принимается. Создаётся отдельная версия (например, v2.2) для актуализации |
| Изменения по UX и вспомогательные сервисы (например, сортировка по убыванию, группировка, визуальные предпочтения, сервисы генерации документов, иконки карт) | Необязательны для интеграции, влияют на удобство потребителя | Не включается в спецификацию/ стандарт | Описываются в приложении "Примеры реализации" или в рекомендациях/сохраняются как best practices |
| Маркетинговая детализация продуктов (например, наименование карт, тарифов и пакетов услуг, видов счетов по способу использования и прочее) | Внутренние классификации и названия банковских продуктов, используемые для клиентского интерфейса и продвижения услуг. Не входят в стандарты Open Banking и не влияют на унификацию API | Не включается в спецификацию/ стандарт | Не принимается. Может быть реализовано банком в рамках своего интерфейса |
| Отображение продукта в интерфейсе | Слой визуализации на стороне клиента (приложения, мобильного банка). Не влияет на структуру, формат или содержание методов API, а лишь на отображение | Не включается в спецификацию/ стандарт | Не принимается. Это задача интерфейса пользователя, вне скоупа Open Banking стандартов |
| Механизмы расчётов, логика лимитов, схемы зачислений и списаний (порядок списания комиссий, схемы зачисления бонусов, кешбэка, льготных периодов и т. д.) | Внутренние правила и бизнес-логика банков. Такие процессы чаще всего уникальны, зависят от внутренних регламентов организаций | Не включается в спецификацию/ стандарт | Не принимается и не стандартизируется в скоупе Open Banking |
| Нестандартизированные решения в пилотах | Локальные договорённости участников вне стандарта | Не включается в спецификацию/ стандарт | Участники согласуют между собой, информируя АФТ |