От фрагментации к линии разлома: недостающий стандарт API корпоративного банкинга в эпоху агентов

TL;DR. Розничный банкинг получил свой стандарт API десятилетие назад. Корпоративный — так и не получил, и теперь, когда ИИ-агенты и Model Context Protocol превратили интеграцию в решение времени исполнения, этот разрыв стал линией разлома.

Points clés

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

Розничный банкинг получил свой стандарт API десятилетие назад. Корпоративный — так и не получил, и в 2026 году это упущение перестало быть досадной помехой и стало линией разлома. ISO 20022 дал отрасли общую грамматику; он так и не дал ей общего, готового к работе с агентами интерфейса. Теперь вызывающая сторона изменилась. Это уже не разработчик, готовый потратить квартал на интеграцию, а модель, обнаруживающая инструменты во время исполнения и перемещающая деньги в пределах политических коридоров. Двусмысленность, которую корпоративные казначеи молча поглощали двадцать лет, вот-вот будет передана программному обеспечению, которое поглотить её не может, — тогда как лежащий ниже уровень данных принудительно приводится к структурированному виду, нравится это банкам или нет. Вот во что обходится недостающее направление, почему агенты делают сегодняшнюю фрагментацию небезопасной, а не просто неэффективной, и что стандарт API корпоративного банкинга обязан предписать, прежде чем автономное казначейство сможет масштабироваться.

Краткое резюме

У корпоративного банкинга есть грамматика, но нет интерфейса. ISO 20022 стандартизировал данные; API не стандартизировал никто. Это было терпимо, пока двусмысленность поглощал человек-интегратор, — модель во время исполнения не может.

Вызывающая сторона изменилась. MCP превратил обнаружение инструментов в решение времени исполнения. Агент, который должен был упразднить проблему интеграции M×N, снова встречает её на границе банка, где каждое учреждение — это индивидуальный сервер со своей семантикой.

Фрагментация теперь перемещает деньги неверно, на машинной скорости. Один тайм-аут, три банка, три противоречащие друг другу истины — дубликат в A, застрявшее поручение в B, безмолвный отказ в C. Идемпотентность и детерминированная грамматика ошибок становятся несущими элементами.

Обёртывание каждого банка в MCP-сервер лишь перемещает болото. Сорок серверов, сорок семантик, ни единого общего нефункционального минимума — и недетерминированная модель с правом записи в платёжные каналы, что прямо укладывается в проблематику SR 11-7 / DORA / EU AI Act.

Стандартизируйте собственный интерфейс — или станьте товаром. Банки, которые публикуют нативный для ISO 20022, готовый к работе с агентами API сейчас, становятся контрагентами по умолчанию для автономного казначейства; остальные сдают свои отношения с клиентом в аренду тому, кто владеет адаптером.

Два банковских мира, один из которых стандартизирован

Взгляните на розницу — картина запутанная, но проходимая. В Европе есть UK Open Banking и NextGenPSD2 от Berlin Group, причём последний принят более чем тремя четвертями европейских банков и на практике рассматривается как де-факто стандарт. В США есть Financial Data Exchange, охватывающий теперь более шестидесяти миллионов потребительских счетов. В Австралии есть Consumer Data Right. Ни один из них не глобален, и ни один вряд ли станет глобальным, — но каждый является реальным, версионируемым, проверяемым машиной контрактом, а там, где контракты заканчиваются, агрегаторы (Plaid, Tink, TrueLayer, Salt Edge) поглощают разницу за единым интерфейсом. Розничная фрагментация — это налог. Это не стена.

У корпоративного и оптового банкинга эквивалента нет. Казначейство транснациональной корпорации выходит на свои банки через каналы передачи файлов host-to-host, десяток индивидуальных порталов, систему управления казначейством или агрегатор — обычно всё четыре одновременно. Это не выдуманный аргумент: собственные исследования McKinsey по транзакционному банкингу годами каталогизировали то же наследие, описывая, как банки опираются на передачу файлов host-to-host и SFTP, перечисляя хорошо известные режимы отказа файловой интеграции — громоздкие форматы ERP, которые приходится настраивать под каждую корпорацию, неспособность обрабатывать условную маршрутизацию — и сообщая, что свыше 85% руководителей транзакционного банкинга намерены инвестировать в API управления денежными средствами. Спрос на API не вызывает сомнений. Недостаёт того общего контракта, на который они указывают.

Ведь обычные кандидаты им не являются. ISO 20022 регулярно принимают за недостающий стандарт, но это грамматика данных, а не контракт API: pain.001 говорит вам, как сформулировать кредитовый перевод, а не какая конечная точка его создаёт, как он аутентифицируется, как разбивается на страницы или как сообщает вам об отказе. BIAN даёт отрасли общую семантическую эталонную модель, а не принудительно применяемый интерфейс. API Payment Initiation и Instant Cash Reporting от Swift — это подлинное движение к стандартизации, но они ориентированы на сеть и всё ещё находятся в становлении, а не являются универсальным интерфейсом. Фреймворк openFinance от Berlin Group тянется к корпоративным сценариям — открытие счёта, торговое финансирование, динамические регулярные платежи, — но он европейский, ранний и премиальный по соглашению. Соберите всё это вместе, и вы всё равно не получите обязательного, глобального стандарта API корпоративного банкинга. У вас есть строительные материалы, но нет чертежа.

Почему фрагментация выживала — и почему этому приходит конец

Двадцать лет это было терпимо, потому что интегратор был человеком и был терпелив. Корпорация подключала горстку банковских соединений за месяцы, иногда за кварталы. Каждое было проектом: обмен сертификатами, проведение тестового платежа на грош, спор над документом соответствия. Издержки были реальными, но оплачивались один раз на отношения и амортизировались годами последующих платежей. Когда API банка был недостаточно специфицирован — когда стандарт «оставлял остальное на усмотрение внедряющего учреждения», как жалуются на это сами банки, — инженер-человек читал портал, выводил намерение и заклеивал пробел. Двусмысленность была терпимой, потому что рядом был человек, чтобы её разрешить.

Она выживала и по причинам, о которых говорят вслух реже. Инфраструктуру внизу подлинно трудно менять: окна пакетного расчёта, ночные циклы и мейнфреймовые ядра, которые никогда не проектировались для ответа на вопрос в реальном времени. И фрагментация — не только случайность; это, негласно, форма привязки. Каждый индивидуальный канал host-to-host, который выстраивает казначей, — это издержки переключения, накапливающиеся в пользу действующего игрока. Банк, который трудно интегрировать, — это, на грани, банк, который трудно покинуть. Ничего конспирологического в этом нет; это обычная мотивация. Но это объясняет, почему отрасль, согласившаяся по поводу грамматики данных, так и не согласилась по поводу интерфейса, — и почему интерфейс остаётся последним нестандартизированным уровнем. Причина, по которой это больше не может держаться, в том, что лежащий ниже уровень принудительно приводится к структурированному виду в срок, а уровень над ним только что обзавёлся новым, нетерпеливым пользователем.

Вызывающая сторона изменилась

Этот пользователь появился за восемнадцать месяцев. Model Context Protocol, который Anthropic открыл в ноябре 2024 года и передал Agentic AI Foundation при Linux Foundation в декабре 2025 года вместе с Block и OpenAI, стал способом по умолчанию, которым ИИ-системы обращаются к инструментам и данным. К началу 2026 года он показывал примерно девяносто семь миллионов загрузок SDK в месяц; к середине года, по одной направленной отраслевой оценке, около семидесяти восьми процентов корпоративных ИИ-команд эксплуатировали агентов на базе MCP в промышленной среде, а более четверти компаний из списка Fortune 500 обслуживали MCP-серверы, защищённые через стандартный уровень авторизации OAuth 2.1. Его рутинно и точно описывают как USB-C для ИИ: он схлопывает кошмар интеграции M×N — каждая модель вручную подключена к каждому инструменту — в M+N. Его собственное резюме о себе — это та строка, что имеет значение для банков: API — для программ; MCP — для агентов. REST API ожидает, что вызывающая сторона заранее знает, к какой конечной точке обратиться и с какими параметрами. Агент ожидает, что обнаружит доступные инструменты во время исполнения и сам решит, как и когда их использовать.

Для казначейства это не гипотеза. Этот паттерн уже устойчив в казначействах корпоративных и инвестиционных банков в 2026 году: агент читает кассовые данные ISO 20022, вызывает ограниченный набор инструментов и перебалансирует ликвидность в пределах политических коридоров, с обёрнутыми вокруг него контролями SR 11-7, DORA и EU AI Act. Грамматика данных к этому готова. Интерфейс API — нет.

Несоответствие, если точно

Сведите агента к тому, что ему на деле нужно от банковского контрагента, и список окажется коротким и неумолимым:

Машиночитаемый контракт — описание OpenAPI или манифест инструментов, который агент может прочитать во время исполнения, а не PDF, который человек читает единожды.
Одна модель аутентификации — профиль OAuth2/mTLS финансового уровня (FAPI — очевидная опора), а не отдельное рукопожатие для каждого банка.
Идемпотентность как гарантия — уникальная ссылка на поручение, которая делает повторно отправленный платёж холостой операцией, потому что агент будет повторять.
Детерминированная грамматика ошибок — один и тот же отказ означает одно и то же повсюду, чтобы модель могла о нём рассуждать.
Семантическое версионирование и обнаружение возможностей — чтобы агент мог определить, что контрагент способен делать в этом квартале, без человеческих примечаний к выпуску.
Структурированные полезные нагрузки ISO 20022, согласие и права доступа, а также защищённый от подделки след аудита — суть, разрешение и доказательство.

Сопоставьте это с корпоративным банкингом, каков он есть, и каждая строка распадается на N диалектов — по одному на банк. Агент, который должен был упразднить проблему M×N, снова встречает её на границе банка, потому что каждое учреждение по сути является индивидуальным сервером со своей грамматикой «баланса», своим понятием «статуса платежа», своим танцем аутентификации и своим представлением о том, что такое ошибка. Протокол стандартизировал сторону провода, принадлежащую агенту. Сторону банка не стандартизировал никто.

Режим отказа, сделанный конкретным

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

Банк A трактует тайм-аут как неизвестно — безопасно повторить, поэтому агент повторяет, и исходное поручение тоже исполняется: дублирующий платёж. Банк B трактует тот же тайм-аут как отправлено — не повторять, но так и не выдаёт подтверждения, которое агент мог бы разобрать, поэтому поручение зависает в неопределённости, пока агент, не видя успеха, эскалирует или перенаправляет: застрявший платёж и дважды учтённая позиция. Банк C возвращает жизнерадостный HTTP 200 с отказом, погребённым в теле полезной нагрузки; агент читает код статуса, помечает сметание как завершённое и идёт дальше: безмолвный отказ, который всплывёт лишь наутро как расхождение при сверке, которое никто не может объяснить.

Три банка, одно условие, три противоречащие друг другу истины — дублирующие средства ушли за дверь в A, замороженное поручение в B, фантомный успех в C. Казначей-человек обзвонил бы трёх менеджеров по работе с клиентами и уладил бы всё к обеду. Агент не может никому позвонить. Именно поэтому «идемпотентность как гарантия» и «детерминированная грамматика ошибок» — не архитектурные излишества: без них та самая фрагментация, что лишь стоила человеко-часов, теперь перемещает реальные деньги неверно, на машинной скорости, через всех контрагентов разом.

Почему «обернуть каждый банк в MCP-сервер» — это не решение

Рефлекторный ответ — дать каждому банку MCP-сервер и на том успокоиться. Он не выдерживает критики, потому что перемещает фрагментацию, а не устраняет её. Сорок банков превращаются в сорок серверов с сорока семантиками, сорока потоками аутентификации и без общего смысла — и, что критично, без общего нефункционального минимума: ни общего бюджета задержки, ни согласованного уровня доступности, ни сопоставимой гарантии идемпотентности. Описанный выше режим отказа переживает обёртку в целости. Хуже того, вызывающая сторона теперь — недетерминированная модель с правом записи в платёжные каналы, что является не просто вопросом интеграции, а вопросом модельного риска и операционной устойчивости, который прямо ложится на SR 11-7, DORA и EU AI Act. Примитивы «человек в контуре» у MCP — запрос уточнения для подтверждения, сэмплинг для рассуждения — необходимы и желанны, но диалог подтверждения не заменяет контрагента, который ведёт себя предсказуемо. Нельзя управлять в масштабе тем, что нельзя единообразно описать. Тысяча индивидуальных серверов — это не стандарт; это то же самое болото с фасадом JSON-RPC.

Два будущих и стратегический выбор

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

В первом банки стандартизируют собственные интерфейсы. Они публикуют готовые к работе с агентами API, сохраняют прямую связь с казначеем и остаются тем контрагентом, которого агент обнаруживает и вызывает. Во втором агрегаторы стандартизируют это за них. Горстка платформ определяет де-факто агентный контракт, а банки становятся взаимозаменяемыми конечными точками за ним — достижимыми лишь через чужую абстракцию. Это не домысел; это розничная история, прокрученная на один сегмент вперёд. Собственная работа McKinsey по транзакционному банкингу за 2025 год описывает платформы управления казначейством, такие как Kyriba и GTreasury, и платформы офиса финансового директора, такие как Bill.com, которые встраиваются между клиентами и банками с единым, независимым от банка представлением о позиции. Это ровно тот уровень, который в рознице негласно упрятал длинный хвост за Plaid и Tink. Те же исследования отмечают, что корпоративные казначеи теперь предъявляют своим банкам требования на уровне их потребительских приложений и будут переходить, когда подключение, права доступа и интеграция API их разочаруют.

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

Что стандарт обязан предписать

Недостающее направление не является экзотическим. Каждый компонент уже существует в открытом доступе — ISO 20022 для данных, API Payment Initiation и Instant Cash Reporting от Swift для эталонных операций, BIAN для семантики, openFinance от Berlin Group для паттерна согласия-и-каталога, FAPI для аутентификации финансового уровня, MCP для экспонирования инструментов, A2A для оркестрации между агентами. Отсутствует акт сборки их в обязательный контракт для корпоративного пространства — и дисциплина специфицировать два минимума, а не один. Существующая литература по B2B-API, включая McKinsey, трактует API главным образом как возможность роста и улучшения опыта. Она мало говорит о детерминизме, обнаружении возможностей во время исполнения или стандартизированных нефункциональных характеристиках — ровно то упущение, которого агенты не терпят. Поэтому стандарт должен быть явным как в том, чем интерфейс является, так и в том, как он ведёт себя под управлением.

Технический минимум

Контракт по принципу OpenAPI-first с каноническим манифестом инструментов MCP, сгенерированным из него, — а не написанным вручную рядом с ним, чтобы инструменты, которые видит агент, никогда не могли разойтись с API, который эксплуатирует банк.
Аутентификация и согласие уровня FAPI как единое рукопожатие по всему интерфейсу.
Идемпотентность и детерминированная таксономия ошибок — стабильные коды, одно значение на каждый отказ, задокументированные в самом контракте.
Нативные полезные нагрузки ISO 20022, структурированные и готовые к гибридному адресу.
Семантическое версионирование с обнаружением возможностей во время исполнения — агент может спросить, что этот контрагент способен делать сегодня, и получить машинный ответ.

Минимум управления и устойчивости

Опубликованные, принудительно применяемые нефункциональные SLO — задержка, доступность, пропускная способность, сквозная обработка и человеческие трудозатраты — выраженные как реальные числа хронометража, а не маркетинговый язык.
Права доступа, согласие и защищённый от подделки след аудита, привязанные к пути исполнения, а не болтающиеся во внеполосном портале.
Контроли модельного риска и операционной устойчивости, согласованные с SR 11-7, DORA и EU AI Act, чтобы вызовы агента были управляемыми событиями с ответственным, а не экзотическими краевыми случаями.

Здесь в розничном опыте зарыт суровый урок. Стандарт, который исполняет машина, должен быть точнее того, что человек-интегратор может негласно починить; недостаточная спецификация — уже не мягкие издержки, оплаченные человеко-часами разработчиков, а жёсткий режим отказа, оплаченный ошибочно отправленными платежами. Показательно, что наиболее авторитетное усилие отрасли по гармонизации — гармонизированные требования к данным ISO 20022 от CPMI и PMPG, которые платёжные системы по всему миру призывают принять к концу 2027 года в рамках программы G20 по трансграничным платежам, чтобы бороться именно с этой фрагментацией, — по собственному описанию не является ни регулированием, ни стандартом API. Оно гармонизирует данные. Интерфейс по-прежнему ничья задача.

Целевая картина

Построение менее пугающе, чем диагноз, потому что это три уровня, а не программа. Канонический API корпоративного банкинга экспонирует платежи и кассовую отчётность через REST и OpenAPI, с нативными полезными нагрузками ISO 20022 и аутентификацией уровня FAPI — один контракт, одна грамматика, одно рукопожатие. Мост MCP располагается над ним и генерирует обращённый к агенту манифест инструментов напрямую из этого контракта OpenAPI, так что обнаружение, схемы и разрешения выводятся из интерфейса, а не поддерживаются параллельно с ним. А уровень политик и устойчивости оборачивает каждый вызов агента контролями, которые делают автономию безопасной: лимиты по транзакциям и контрагентам, сегментация, триггеры «человек в контуре» (запрос уточнения при высокорисковых действиях), живой мониторинг SLO и жёсткий аварийный выключатель. Никаких диаграмм для понимания сути не требуется — стандарт не является новым каналом, это дисциплинированная компоновка каналов, которые уже существуют, с путём агента и путём управления, встроенными с первого коммита, а не прикрученными после инцидента.

Что делают заслуживающие доверия банки в ближайшие 24 месяца

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

Опубликуйте нативный для ISO 20022 интерфейс по принципу OpenAPI-first. Возьмите один высокоценный коридор — как правило, трансграничные платежи и кассовую отчётность — и экспонируйте его через единое, версионируемое определение OpenAPI с полезными нагрузками ISO 20022, согласованное с вашими существующими схемами CBPR+, а не пятой выдуманной грамматикой. Сделайте его публичным для клиентов и внутренних агентов, с песочницей, и относитесь к изменениям как к выпускам продукта. Успех первого года — не полное покрытие; это доказательство, что один коридор можно сделать адресуемым для агента из конца в конец.
Стандартизируйте аутентификацию и идемпотентность по нему. Примите один профиль уровня FAPI как единственное рукопожатие, обяжите использовать ключи идемпотентности при каждой записи и сделайте «повтор того же поручения» задокументированной гарантией в контракте — превращая «агенты будут повторять» из риска в безопасное допущение.
Определите детерминированную грамматику ошибок и обнаружение возможностей. Дайте каждому отказу стабильный код и согласованную семантику, добавьте семантическое версионирование и экспонируйте каталог возможностей, который агент может запросить во время исполнения, с явными флагами для частичной поддержки, устаревания и «пока недоступно».
Привяжите права доступа, согласие и аудит к тому же интерфейсу. Переведите потоки согласия и одобрения на путь API, выпускайте защищённый от подделки след для каждого инициированного агентом поручения — кто, что, когда, в пределах какого политического коридора — и согласуйте его явно с SR 11-7, DORA и EU AI Act, чтобы вторая линия могла его подписать.
Опубликуйте нефункциональные минимумы, затем запустите контролируемый пилот с агентом. Обязуйтесь по целевым показателям задержки, доступности, пропускной способности и STP для коридора и инструментируйте их; затем поднимите контролируемого агента ликвидности или сметания денежных средств, использующего только этот интерфейс, с жёсткими лимитами, контрольными точками «человек в контуре» и полным аудитом, на срок от шести до двенадцати месяцев. Это принуждающая функция, которую вы контролируете сами, — она доказывает, что агент может перемещать деньги безопасно в пределах политических коридоров, когда интерфейс предсказуем, и она быстро говорит вам, где ваш стандарт всё ещё чаяние, а не факт.

Принуждающая функция

Отрасль только что доказала, что способна двигаться, когда что-то её принуждает. Переход Swift на структурированный адрес в ноябре 2026 года — после которого неструктурированные адреса в трансграничных платежах попросту отвергаются, без резервного преобразования, — потащил неохотный рынок к структурированным данным ISO 20022 в фиксированный срок, подкреплённый нажимом CPMI к концу 2027 года на гармонизированные требования к данным в рамках программы G20 по платежам. Обратите внимание, что стандартизируют оба усилия: данные, а не интерфейс. Грамматику принуждают к чистоте. Интерфейс оставили на усмотрение каждого банка — а это ровно то усмотрение, с которым агенты не могут работать. Для агента это означает, что полезные нагрузки наконец станут согласованными, тогда как поведение за ними останется расходящимся, — инверсия того, что на деле нужно машине, а ей нужно предсказуемое поведение в первую очередь и чистые данные во вторую.

Итак, вот неспровоцированная ошибка, которой следует избежать: ждать, пока глобальный комитет благословит стандарт API корпоративного банкинга, прежде чем действовать. Банки, которые публикуют нативный для ISO 20022, готовый к работе с агентами интерфейс сейчас — контракт OpenAPI, манифест MCP, сгенерированный из него, аутентификацию финансового уровня и нефункциональные минимумы, за которыми они действительно готовы стоять, — станут контрагентами по умолчанию для автономного казначейства. Их инструменты будут теми, которые агенты смогут обнаружить, которым смогут доверять и которые смогут вызвать без человека посередине. Банки, которые выждут, будут достижимы лишь через абстракцию агрегатора, сдавая свои собственные отношения с клиентом в аренду тому, кто владеет адаптером.

Грамматика без направления — это не стандарт. ISO 20022 сказал корпоративному банкингу, как говорить. Он так и не сказал ему, куда идти. Агенты прибыли — беглые и нетерпеливые, — а карты по-прежнему нет. Начертить её — теперь самая значимая часть инфраструктурной работы в транзакционном банкинге, и, впервые, срок задаёт не регулятор, а машины, уже ожидающие у интерфейса.

Часто задаваемые вопросы

Разве ISO 20022 не является недостающим стандартом? Нет. ISO 20022 — это грамматика данных, а не контракт API. pain.001 говорит системе, как сформулировать кредитовый перевод; он не говорит, какая конечная точка его создаёт, как он аутентифицируется, как разбивается на страницы или как сообщает об отказе. Грамматика готова для агентов. Интерфейс — машиночитаемый, единообразно ведущий себя интерфейс, который агент на деле вызывает, — нет.

Почему бы просто не обернуть каждый банк в MCP-сервер? Потому что это перемещает фрагментацию, а не устраняет её. Сорок банков превращаются в сорок серверов с сорока семантиками, сорока потоками аутентификации и — что критично — без общего нефункционального минимума: ни общего бюджета задержки, ни согласованного уровня доступности, ни сопоставимой гарантии идемпотентности. Вызывающая сторона теперь — недетерминированная модель с правом записи в платёжные каналы, что является проблемой модельного риска и операционной устойчивости в рамках SR 11-7, DORA и EU AI Act. Тысяча индивидуальных серверов — это не стандарт.

Какой единственный самый полезный первый шаг для банка? Опубликовать один нативный для ISO 20022 коридор по принципу OpenAPI-first — как правило, трансграничные платежи и кассовую отчётность — с рукопожатием уровня FAPI, идемпотентностью как задокументированной гарантией и детерминированной грамматикой ошибок. Затем запустить контролируемый пилот с агентом против только этого интерфейса, с жёсткими лимитами, контрольными точками «человек в контуре» и полным аудитом. Доказательство одного коридора из конца в конец превосходит дорожную карту, которая покрывает всё и не предписывает ничего.

Кто разрешит это, если не банки? Агрегаторы. Горстка платформ управления казначейством и офиса финансового директора определит де-факто агентный контракт, а банки станут взаимозаменяемыми конечными точками за ним — отдав маржу, владение клиентом и сквозные данные разом. Это розничная история, где Plaid и Tink поглотили длинный хвост, прокрученная на один сегмент вперёд в корпоративный банкинг.

Источники

Model Context Protocol — официальная документация ⧉. [MCP открыт в ноябре 2024 года и передан Agentic AI Foundation при Linux Foundation в декабре 2025 года вместе с Block и OpenAI; уровень обнаружения инструментов во время исполнения, на котором строится анализ. Цифры внедрения в тексте — направленные отраслевые оценки и помечены как таковые.]
Berlin Group — NextGenPSD2 и openFinance ⧉. [Де-факто европейский розничный стандарт API и его движение к корпоративным сценариям — цитируется для паттерна согласия-и-каталога и контраста между розницей и корпоративным сегментом.]
Financial Data Exchange (FDX) ⧉. [Розничный стандарт обмена данными США, цитируется для масштаба стандартизированных розничных контрактов, которому у корпоративного банкинга нет эквивалента.]
McKinsey & Company — аналитика по финансовым услугам ⧉. [Исследования API транзакционного банкинга: наследие host-to-host / SFTP, намерение инвестировать в API управления денежными средствами (~85%) и посредничество казначейских платформ. Цитируется для рыночного диагноза; рамка и выводы здесь принадлежат автору.]
Банк международных расчётов (CPMI) — гармонизированные требования к данным ISO 20022 ⧉. [Нажим к концу 2027 года на гармонизацию платёжных данных — по собственному описанию не являющийся ни регулированием, ни стандартом API — цитируется для тезиса «грамматика без интерфейса».]
Swift — ISO 20022 для финансовых учреждений ⧉. [CBPR+ и веха структурированного адреса ноября 2026 года; API Payment Initiation и Instant Cash Reporting цитируются как эталонные операции, а не универсальный интерфейс.]

Последняя проверка: июль 2026 года. Оригинальный анализ; источники цитируются, а не воспроизводятся. Цифры внедрения и рыночные показатели — направленные отраслевые оценки; сверьте с первичными источниками перед повторной публикацией. Лицензировано на условиях CC-BY-4.0.

Последняя проверка 2026-07-08.

Опубликовать заново

От фрагментации к линии разлома: недостающий стандарт API корпоративного банкинга в эпоху агентов — Sebastien Rousseau

Розничный банкинг получил свой стандарт API десятилетие назад. Корпоративный — так и не получил, и теперь, когда ИИ-агенты и Model Context Protocol превратили интеграцию в решение времени исполнения, этот разрыв стал линией разлома.

Эта статья распространяется по лицензии Creative Commons Attribution 4.0 International. При повторной публикации требуется указание канонической ссылки.

От фрагментации к линии разлома: недостающий стандарт API корпоративного банкинга в эпоху агентов — Sebastien Rousseau

Розничный банкинг получил свой стандарт API десятилетие назад. Корпоративный — так и не получил, и теперь, когда ИИ-агенты и Model Context Protocol превратили интеграцию в решение времени исполнения, этот разрыв стал линией разлома.

Originally published at https://sebastienrousseau.com/ru/2026-07-07-corporate-banking-api-standard-agentic-mcp-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER