Крупнейшие американские банки начали блокировать ИИ‑агентов, которые входят в интернет‑банкинг под учётными записями клиентов. Об этом написали примерно СМИ, обычно не упомянув «мелкую» подробность: пользователи передавали программам не специальные токены с ограниченными полномочиями, а полноценные банковские логины и пароли. Получив такой доступ, агент потенциально способен делать почти всё, что может сам владелец счёта, включая проведение платежей и изменение настроек. Причём передача учётных данных сторонним программам нередко прямо противоречит договору с банком.
На первый взгляд банки поступают совершенно разумно. Но возникает другой вопрос: почему клиенту вообще приходится отдавать программе полный доступ, если современные банковские системы давно умеют разграничивать полномочия? Оказывается, в США такие механизмы существуют, но далеко не каждый клиент может самостоятельно выдать произвольному агенту отдельные права. А за технической проблемой обнаруживается старый конфликт между банками и независимыми финансовыми сервисами — конфликт, в котором на кону не только безопасность, но и довольно большие деньги.
Посмотрим, что произошло, как американские банки организуют доступ сторонних программ, почему некоторые из них уже перекладывают ответственность за действия ИИ на пользователей и при чём здесь российский ЦБ, который ещё в 2024 году обещал обязательное внедрение Open Banking с 2026-го.
Что произошло
По данным Axios, с проблемой столкнулись JPMorgan Chase, Morgan Stanley, Bank of America, Citi и Wells Fargo. Пользователи добровольно предоставляли ИИ‑ассистентам доступ к своим банковским кабинетам, после чего те начинали выполнять порученные финансовые задачи. В некоторых случаях агенты обращались в контакт‑центры и предпринимали действия, которые, по наблюдениям банков, выглядели выходящими за пределы первоначальных поручений клиентов.
Инциденты привели к блокировкам сторонних агентов и пересмотру правил доступа. При этом пока нет публично подтверждённых случаев хищения средств такими агентами. Morgan Stanley отдельно заявил, что не обнаруживал на своих платформах агентов, самостоятельно вышедших из‑под контроля пользователей. Масштаб происходящего также неизвестен: банки не раскрывают ни количества подобных подключений, ни числа потенциально опасных операций.
Но самая важная деталь заключается в характере доступа. Это не взломанные аккаунты и не похищенные пароли, а случаи, когда пользователи сознательно предоставляют свои реквизиты сторонним программам. С точки зрения большинства банков подобное использование уже нарушает установленные правила, независимо от того, совершал ли агент какие‑либо нежелательные действия.
Например, действующий договор Wells Fargo предусматривает, что клиент не должен раскрывать свои учётные данные посторонним лицам, а также запрещает определённые виды автоматизированного сбора информации. В соглашении Bank of America отдельно запрещена передача реквизитов третьим лицам для использования платёжного сервиса Zelle, кроме предусмотренных юридических исключений.
Таким образом, проблема возникает ещё до первого банковского перевода: клиент допускает программу к системе способом, которого банк не разрешал. Это нарушение договорных условий не обязательно означает совершение преступления или отсутствие согласия самого клиента, но даёт банку основания ограничить доступ.
А банки умеют выдавать ограниченные права?
Да, и довольно давно. Причём именно американские банки активно развивали подобные механизмы, пытаясь избавиться от прежней практики, когда сторонние приложения для финансового учёта получали полный пользовательский пароль и самостоятельно извлекали информацию из интернет‑банка.
Например, у JPMorgan Chase есть система защищённого подключения внешних приложений. Пользователь выбирает нужный сервис, переходит на страницу самого банка, проходит аутентификацию и определяет, к каким счетам разрешено обращаться. Можно предоставить доступ к текущему счёту, но не к сберегательному, а впоследствии отозвать согласие. Разработчик приложения не видит банковского пароля, а клиент управляет подключениями через раздел Linked Apps and Websites.
Аналогичный механизм предлагает Bank of America. Вместо передачи реквизитов пользователь подтверждает разрешение непосредственно в банке, после чего сторонний сервис получает доступ к согласованным данным. Более того, у Wells Fargo предусмотрено делегирование прав другим пользователям с отдельными учётными данными. В зависимости от доступных функций это может быть режим просмотра информации без права совершать операции либо более широкие полномочия.
Казалось бы, достаточно создать для агента отдельный аккаунт и назначить ему нужные разрешения. Но здесь обнаруживается разница между существующими возможностями и тем, что требуется обычному пользователю.
У американских банков есть механизмы подключения одобренных сторонних приложений, а иногда и делегирования доступа другим людям. Однако это не означает, что любой клиент может открыть настройки, создать API‑токен для собственного скрипта и выставить произвольные права: читать выписки, готовить платежи, переводить не более тысячи долларов в сутки, запрещать новых получателей и так далее. Подобные операции зависят от конкретного банка, доступных API и категории подключаемого сервиса.
С точки зрения клиента ситуация получается довольно забавная. Человек хочет поручить ассистенту простую задачу, например разобраться с комиссиями по кредитной карте. Но для безопасной автоматизации ему предлагается разбираться в сторонних интеграциях, согласиях, разрешённых продуктах и доступных операциях. Ещё немного — и владелец обычного банковского счёта превратится в системного администратора собственного интернет‑банкинга.
А пароль у него уже есть. Его можно просто ввести в агент, который обещает самостоятельно сделать всю работу.
Впрочем, даже для независимых разработчиков ситуация в США не настолько безнадёжна. С апреля 2026 года Plaid предоставляет бесплатный Trial‑план, позволяющий работать с реальными банковскими данными, подключив до десяти финансовых учреждений. Поддерживаются в том числе OAuth‑интеграции с Chase, Bank of America и Wells Fargo. Это уже вполне практический инструмент для создания персонального финансового приложения, хотя он требует регистрации разработчика, а доступные операции ограничены соответствующими продуктами Plaid.
Получается, безопасная альтернатива передаче пароля существует. Но она далеко не всегда доступна непосредственно из банковского кабинета и не превращает произвольного агента в полноценного представителя клиента.
А если клиент сам разрешил агенту переводить деньги?
Здесь стоит разделить две ситуации. Если пользователь передал программе свой основной пароль, банк не имеет надёжного способа проверить, какие именно полномочия были предоставлены. Для него это обычная аутентифицированная сессия, внутри которой может действовать человек, скрипт, агент или злоумышленник, получивший доступ к программе. Внешне операции могут выглядеть одинаково, хотя их происхождение совершенно различно.
Если же банк сам выдал агенту ограниченный токен, ситуация становится намного понятнее. Клиент разрешил программе определённый набор действий, банк зафиксировал полномочия и технически запрещает всё остальное. Например, агент может читать выписки и переводить до тысячи долларов между собственными счетами. Попытка отправить деньги неизвестному получателю или превысить лимит должна быть отклонена независимо от того, что по этому поводу думает языковая модель.
Конечно, остаются обычные банковские обязанности: антифрод, проверка получателей, соблюдение санкционных и иных регуляторных требований, обработка отозванных разрешений. Однако не требуется угадывать намерения пользователя по поведению агента. Клиент заранее согласился на определённые полномочия, а банк проверяет их выполнение.
И самое интересное — некоторые банки уже идут именно по пути договорного признания агентских действий.
Wells Fargo опубликовал новую редакцию договора, которая должна вступить в силу 24 ноября 2026 года. В ней появился специальный раздел Third‑Party Artificial Intelligence Agents or Agentic AI. Банк предусматривает, что, если пользователь предоставил агенту доступ к счёту или иным способом уполномочил его действовать от своего имени, операции агента могут считаться совершёнными и разрешёнными самим клиентом.
Причём ответственность предполагается и за нежелательные результаты: неправильную интерпретацию задания, ошибочные действия и превышение агентом выданных полномочий. Разумеется, договор содержит оговорку о приоритете обязательных требований законодательства, поэтому банк не может просто отменить предусмотренные законом права потребителя.
Одновременно Wells Fargo сохраняет за собой право ограничивать, приостанавливать и полностью запрещать агентам доступ, а также менять правила использования API.
Получается довольно своеобразная конструкция: банк заранее определяет, что клиент может отвечать за действия своего агента, но оставляет за собой решение о том, разрешать ли этому агенту вообще работать со счётом. Это не столько техническая невозможность делегирования, сколько поиск удобной договорной и операционной модели.
Почему банкам невыгоден независимый финансовый помощник
Соображения безопасности реальны и заслуживают внимания. Банк обязан защищать клиентские средства и выполнять требования регуляторов. Непроверенный агент с полным пользовательским паролем действительно создаёт существенные риски, особенно если может самостоятельно изменять настройки, создавать платёжные поручения и обращаться в поддержку.
Но есть и экономическая сторона вопроса. В апреле 2026 года McKinsey опубликовала исследование How gen AI agents threaten retail banks’ customer relationships, посвящённое угрозам традиционному банковскому бизнесу со стороны автономных финансовых помощников.
Представим клиента, который больше не открывает банковские приложения. Его агент регулярно сравнивает тарифы, ставки по депозитам, условия кредитования и комиссии. Если где‑то можно заработать больше или платить меньше, программа предлагает изменить финансовый продукт либо выполняет разрешённую операцию самостоятельно.
Для клиента это удобно. Для банка — не обязательно.
Значительная часть депозитных средств находится на текущих и сберегательных счетах с низкой доходностью. Клиенты не переводят деньги постоянно между финансовыми учреждениями, поскольку это неудобно и требует времени. McKinsey оценивает, что перемещение всего 5–10% остатков с текущих счетов на более доходные продукты способно снизить совокупную прибыль банков от депозитного бизнеса на 20% и более. Это сценарная оценка, но она объясняет, насколько серьёзным может оказаться экономический эффект массового распространения агентов.
Есть и другие направления. Независимая программа способна выявлять комиссии, рекомендовать рефинансирование, выбирать наиболее выгодную карту для покупки, отслеживать подписки и заменять часть банковских информационных сервисов. Например, вместо платного пакета уведомлений клиент может использовать собственную систему мониторинга операций, получая сообщения по установленным им правилам.
В перспективе интереснее даже не уведомления, а возможность задавать собственные условия безопасности. Например, разрешать обычные расходы, но требовать дополнительного подтверждения при покупке дороже определённой суммы. Важно, однако, различать уведомление о совершённом платеже и его предотвращение: последнее требует доступа к механизму авторизации операции, а не просто к истории транзакций.
Банку выгодно развивать собственного ассистента, который будет обслуживать клиента и предлагать банковские продукты. Независимый агент, сравнивающий предложения конкурентов и стремящийся минимизировать расходы пользователя, создаёт совершенно другую экономику отношений.
Это не доказывает, что блокировки, описанные Axios, продиктованы желанием защитить доходы: прямых свидетельств такого мотива нет. Но конфликт интересов существует, и представители банковской отрасли обсуждают его вполне открыто.
ИИ уже подключают к банкам. Но по правилам банков
Сам по себе доступ ИИ к финансовой информации перестал быть чем‑то необычным. С мая 2026 года ChatGPT Finances позволяет американским пользователям подключать банковские счета через Plaid, анализировать расходы, искать регулярные платежи, оценивать накопления и задавать вопросы о личных финансах на естественном языке.
Всё это работает через согласованные интеграции, без передачи основного банковского пароля самому ChatGPT. Однако возможности сервиса ограничены чтением: он не может самостоятельно переводить деньги, оплачивать счета, заключать сделки или менять настройки банковских продуктов.
Это важное различие. Банки уже допускают независимые системы к данным клиентов, но полноценное делегирование финансовых действий остаётся существенно более сложной задачей.
Исторически подобные споры начались задолго до ИИ. Сервисы управления личными финансами десятилетиями получали информацию из банков через screen scraping, то есть входили под пользовательскими реквизитами и разбирали содержимое страниц. Затем банки начали переводить интеграции на защищённые API. Вместо передачи полного пароля клиент получил возможность разрешать конкретным сервисам доступ к нужным данным.
Со временем возник вопрос стоимости такого доступа. В сентябре 2025 года JPMorgan Chase и Plaid заключили соглашение, предусматривающее платную модель обмена клиентскими данными. Банки объясняют подобные решения необходимостью финансировать инфраструктуру и безопасность, а финтех‑компании опасаются, что коммерческие условия подключения превратятся в барьер для независимых конкурентов.
Попытка закрепить доступ на законодательном уровне тоже встретила сопротивление. Раздел 1033 американского закона Додда — Франка ещё в 2010 году предусмотрел право потребителей получать свои финансовые данные. В октябре 2024 года регулятор CFPB утвердил подробные правила Personal Financial Data Rights, но затем банковская отрасль оспорила их. В октябре 2025 года суд приостановил сроки обязательного исполнения, а регулятор приступил к пересмотру правил, включая вопросы оплаты доступа и полномочий сторонних организаций.
Таким образом, американский рынок уже располагает развитой коммерческой инфраструктурой Open Banking, но вопрос обязательного и равноправного доступа к ней остаётся предметом спора.
В России история очень похожая
Российский Банк России тоже развивает Open Banking, причём ещё 2 сентября 2024 года было объявлено, что с 2026 года использование открытых API станет обязательным для крупнейших банков, брокеров и страховых компаний. Предполагалось, что клиенты смогут разрешать сторонним сервисам получать информацию о своих финансовых продуктах и управлять согласиями через единую инфраструктуру.
Однако первоначальные сроки изменились. В проекте Основных направлений развития финансового рынка на 2027–2029 годы, опубликованном в сентябре 2026 года, обязательное применение стандартов Open API для системно значимых кредитных организаций планируется уже на 2027 год. Пока это не вступившая в силу всеобщая обязанность.
При этом технические возможности у российских банков есть. Например, тот же Альфа-Банк предлагает развитый Alfa API — но только для бизнеса: выписки, платежи, отслеживание операций и другие функции, но у обычного «физика»‑владельца личного счёта пока нет универсальной возможности самостоятельно подключить произвольную программу к своим банковским данным через стандартизированный API.
Это не значит, что Банк России намерен ограничить Open Banking исключительно юридическими лицами. Напротив, опубликованные стандарты предусматривают передачу информации о счетах физических лиц, а механизм согласий ориентирован и на граждан. Однако модель построена вокруг взаимодействия допущенных организаций, а не самостоятельной выдачи API‑ключа любому желающему.
Почему сроки переносятся? Официально речь идёт о подготовке инфраструктуры, пилотировании и доработке регулирования. Коммерческая заинтересованность банков в сохранении контроля над клиентскими сервисами тоже представляется возможным фактором, но доказательств её влияния на конкретные решения ЦБ нет.
Впрочем, даже наличие API не решает автоматически вопрос ответственности за ошибочные распоряжения. Российская судебная практика по делам о мошеннических переводах и дистанционно оформленных кредитах показывает, насколько неоднозначной бывает оценка действительной воли клиента, если технически операция выполнена с его устройства и подтверждена предусмотренным способом. В отношении автономных агентов подобных вопросов может стать ещё больше.
Что должно прийти на смену паролю
Решение проблемы выглядит довольно очевидным: агенту не нужен пароль владельца счёта, ему нужны отдельно выданные полномочия. Причём не обязательно разрешать ему совершать платежи. Для множества задач достаточно чтения выписок, остатков и условий обслуживания, а для финансовых действий — возможности подготовить операцию и передать её человеку на подтверждение.
Технически подобные механизмы уже развиваются. В сентябре 2025 года Google представила Agent Payments Protocol, предусматривающий криптографически проверяемые поручения. Visa работает над Trusted Agent Protocol, позволяющим участникам платёжной инфраструктуры проверять подлинность агентов и их полномочия. Эти решения ориентированы преимущественно на покупки и взаимодействие с продавцами, но демонстрируют общий принцип: вместо передачи универсальных реквизитов программа получает ограниченное разрешение на определённые действия.
В идеальном случае владелец счёта сможет назначить собственному агенту такие же понятные права, какие системный администратор назначает сервисному аккаунту: разрешить получение выписок, запретить изменение настроек, ограничить суммы и получателей платежей, установить срок действия доступа и иметь возможность немедленно его отозвать.
Причём пользователю совершенно необязательно разбираться в OAuth, токенах и API. Достаточно привычного интерфейса: выбрать приложение, указать счета и разрешённые действия. Именно так уже организовано подключение некоторых финансовых сервисов через банковские страницы авторизации. Расширение этой модели на полноценные агентские операции выглядит естественным следующим шагом.
Вопрос лишь в том, насколько охотно банки будут открывать новые возможности независимым разработчикам. Пока передача пароля противоречит их правилам, а официальные интеграции работают только в пределах согласованных сценариев, банк сохраняет значительный контроль над тем, какие услуги клиент может получать через стороннюю программу.
И здесь мы возвращаемя к исходной новости. Пользователи передают агентам полные банковские пароли не обязательно потому, что не понимают опасности, а потому, что это самый прямой способ заставить программу выполнить нужную работу. Банки блокируют такие подключения, и с точки зрения безопасности у них есть веские основания. Но полноценной альтернативой блокировкам станет не новая разновидность CAPTCHA и не очередной запрет в пользовательском соглашении.
Если клиент вправе самостоятельно распоряжаться своими деньгами, то у него должна быть возможность безопасно передать часть этих полномочий выбранной им программе. Без необходимости отдавать ей полный доступ ко всему банковскому кабинету.
Технически отрасль уже умеет это делать. Главный вопрос теперь не в том, как отличить человека от агента, а в том, кто будет определять границы делегирования: сам клиент, банк или регулятор. И насколько независимым останется финансовый помощник, если право работать с деньгами клиента ему будет выдавать организация, чьи доходы он способен сократить.
