Корпоративный мультибанкинг на Открытых API: от выписки до оплаты

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

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

Меня в Open Banking (открытом банкинге) интересует возможность собрать эту работу в одном сервисе. Клиенту нужен ответ на вполне конкретный вопрос: можем ли мы провести эти платежи и что произойдёт после подтверждения?

Моя гипотеза — привычным местом работы с несколькими банками может стать сервис, в котором компания готовит платежи, согласует их и проверяет исполнение. Его может развивать банк, разработчик учётной системы или независимая компания. Попробую разобраться, что для этого дают общие API банков и какую работу всё равно придётся делать отдельно.

Где клиент будет принимать финансовые решения

В основе Open Banking — обмен банковскими данными с согласия клиента по общим правилам. «Открытые» здесь означает стандартизированное взаимодействие участников. Доступ к сведениям о конкретном клиенте остаётся ограниченным.

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

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

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

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

Что уже есть в России

В сообщении от 24 декабря 2025 года Банк России указал, что крупнейшие участники финансового рынка тестировали стандарты с 2024 года, создавая сервисы для реальных клиентов. Среди примеров — персональный финансовый помощник и корпоративный мультибанкинг.

В отчёте ЦБ за 2025 год говорится о 19 организациях, участвовавших в пилотировании. Там же описан сценарий онлайн-согласования обслуживания по ДМС. То есть работа с Открытыми API уже затрагивает задачи за пределами банковских счетов. Это данные о пилотах за конкретный год; по ним нельзя судить о доступности сервисов для всего рынка.

АФТ в декабре 2025 года сообщила о десяти утверждённых и опубликованных стандартах Открытых API. Они охватывают общие положения, безопасность, технические требования, получение информации о счетах и согласий для физических и юридических лиц. АФТ также указывает, что в её базе знаний размещаются и утверждённые, и проектируемые версии спецификаций.

По назначению документы комплекса делятся на четыре группы.

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

• Безопасность: профили для расширенного режима безопасности. Они опираются на СТО БР ФАПИ.СЕК-1.6-2024 на основе OpenID Connect и СТО БР ФАПИ.ПАОК-1.0-2024 для подтверждения по отдельному каналу. Для российских криптоалгоритмов в OpenID Connect есть методические рекомендации ТК 26.

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

• Данные о счетах: описание и правила взаимодействия, методы для физических и юридических лиц.

Обновлённые стандарты вводятся в действие с 1 октября 2026 года.

Для нашего сценария показательно, чего в перечне нет: инициирования перевода в комплексе 2025 года я не нашёл. Отдельный стандарт на инициирование перевода в рублях Банк России публиковал в 2020 году. Значит, чтение остатков и выписок можно строить на новом комплексе, а отправку поручений придётся отдельно сверять с тем, что поддерживает конкретный банк.

Для команды продукта здесь нужен простой порядок проверки. Сначала выяснить статус нужной версии, затем — какие банки её поддерживают и на каких условиях подключают сервис. После этого проверить весь путь клиента. Документ со спецификацией сам по себе не подтверждает готовность банковского сервиса. В публикации ЦБ от 24 декабря 2025 года использование обновлённого комплекса было названо рекомендательным.

От выписки к оплате

Для нашей компании продукт можно развивать поэтапно.

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

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

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

После отправки поручения работа тоже продолжается. Нужно получить достоверный статус и сопоставить платёж со счётом поставщика. Успешный ответ на API-запрос ещё не означает, что задача бухгалтера завершена.

В Великобритании есть пример более узкого поручения сервису — sweeping VRP (Variable Recurring Payments). Это переводы переменной суммы между счетами одного владельца. Клиент заранее задаёт условия, включая счёт получателя и лимиты. В этих пределах переводы могут выполняться без отдельного подтверждения каждого платежа. В исключительных случаях, например при подозрении на мошенничество, банк может потребовать дополнительную аутентификацию.

В опубликованной Open Banking Limited статистике за июнь 2026 года указано 7,73 млн sweeping VRP-платежей. Это число операций, а не пользователей.

Этот пример показывает, как может работать заранее ограниченное поручение. Он не подтверждает наличие аналогичного режима в России и не описывает оплату счетов поставщиков: у sweeping получатель — тот же владелец денег. Для корпоративного сценария условия придётся прорабатывать отдельно.

Кто за это заплатит

В нашем примере возможный покупатель — компания, которая регулярно тратит время на подготовку платежей и сверку. Но сколько она готова платить, из описания технологии не следует.

Для начала я бы посмотрел, как сотрудники работают сейчас. Сколько времени занимает подготовка платёжного дня? Где приходится переносить данные? Из-за чего платёж возвращается на доработку? Кто разбирается с зависшими поручениями?

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

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

Поэтому в расчёт стоимости одной завершённой задачи должны входить и затраты на неудачные попытки.

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

Отдельный вопрос — рекомендации. Если разработчик получает комиссию от банка, это может влиять на то, какие предложения видит клиент. Я бы прямо показывал основания выбора и коммерческие связи. Для сервиса, который помогает распоряжаться деньгами, скрытый конфликт интересов способен перечеркнуть удобство.

Что добавят общие стандарты

Допустим, учётная система уже получает выписки из трёх банков, готовит платежи и выполняет сверку. Что ей даст переход на Open Banking? Возможно, в текущем процессе почти ничего.

Пользу общих стандартов я бы проверял при подключении следующего банка. Получилось ли повторно использовать существующий код? Сколько заняли согласование доступа и тестирование? Какие особенности пришлось учесть отдельно? Как дорого обходится поддержка после обновления API банка?

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

И ещё: подключить новый банк и сменить обслуживающий банк — разные задачи. Во втором случае остаются договоры, остатки, реквизиты и незавершённые операции. Open Banking может упростить часть технической работы, но не отменяет сам переход.

Что происходит, когда платёж завис

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

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

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

Как это выглядит на уровне API, удобно показать на британской спецификации Open Banking: там инициирование платежей описано подробно. Сервис отправляет поручение с заголовком x-idempotency-key. Ключ формирует сам сервис. Повторный запрос с тем же ключом банк должен вернуть как уже созданное поручение.

POST /domestic-payments

x-idempotency-key: pay-2026-11-06-000417

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

GET /domestic-payments/58923

{  "Data": {    "DomesticPaymentId": "58923",    "Status": "AcceptedSettlementInProcess",    "StatusUpdateDateTime": "2026-11-06T16:42:05+03:00"  }}

Статус AcceptedSettlementInProcess означает, что банк принял поручение и исполнение идёт. Для бухгалтера это «в обработке», и отправлять ту же сумму повторно нельзя. AcceptedSettlementCompleted означает списание со счёта плательщика, AcceptedCreditSettlementCompleted подтверждает зачисление получателю. Rejected означает отказ. Pending означает, что решение ещё не принято.

Повторную отправку через другой банк я бы разрешал только после Rejected. Pending, AcceptedSettlementInProcess и отсутствие ответа для сервиса означают, что результат пока неизвестен. В российском комплексе 2025 года такого раздела нет, поэтому идентификаторы, статусы и правила повтора придётся сверять с каждым банком отдельно.

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

С разрешениями нужна такая же определённость. Доступ приложения к API и право сотрудника подписать платёж проверяются отдельно. Доступ приложения удобно контролировать на уровне API-шлюза. В NEOMSA APIM, которую мы развиваем в Неофлексе, для каждого приложения отдельно настраиваются ключи, лимиты вызовов и журнал обращений, а право подписи остаётся за банком и учётной системой. В интерфейсе должно быть понятно, какие сведения сервис получает, какие действия ему разрешены и кто их подтверждает.

При отзыве разрешения нужно показать, что именно прекращается. Получив от пользователя запрос на отзыв, сервис должен прекратить новые обращения на основании этого разрешения. Отзыв на стороне банка нужно довести до подтверждённого результата. Уже переданные поручения рассматриваются отдельно: сам по себе отзыв не отменяет исполненный платёж, а возможность остановить поручение в обработке зависит от его состояния и правил банка.

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

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

Где пригодится AI

В этом процессе можно попробовать и разговорный интерфейс. Например, финансовый директор спрашивает: «Что мы можем оплатить сегодня, если оставить деньги на зарплату?»

Я бы использовал модель для уточнения запроса и объяснения подготовленного расчёта. Она могла бы спросить, за какой период нужно сохранить резерв, показать причины переноса платежа или собрать понятное описание ошибки из полученных статусов.

Расчёты и проверка разрешений при этом должны выполняться отдельными проверяемыми механизмами. Модель не должна придумывать остаток, менять лимит или сообщать об исполнении без подтверждающих данных. Просьба «оплати всё» не создаёт полномочий, которых нет у пользователя.

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

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

С какого продукта я бы начал

Первой версией я бы сделал подготовку платёжного дня для компаний с несколькими банками (сценарий корпоративного мультибанкинга). Сервис собирает доступные остатки и обязательства, предлагает план и показывает, где не хватает данных или решения сотрудника.

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

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

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

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

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

У кого останется клиент

Я допускаю несколько вариантов. Банк может стать удобным местом работы со счетами из разных организаций. Независимый сервис может занять определённую нишу. Учётная система может встроить банковские действия в уже привычный процесс подготовки платежей.

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

Не факт, что общие стандарты приведут к большему числу поставщиков. Если подключение и сопровождение останутся дорогими, преимущества могут получить крупные участники. Сервис с широким выбором банков также может продвигать преимущественно партнёрские предложения.

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

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

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

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