Банки передают облачным и программным компаниям все больше операций: хранение и обработку данных, проверку клиентов, выявление мошенничества, связь с платежными системами и работу отдельных моделей искусственного интеллекта. Это снижает затраты и ускоряет внедрение технологий, но создает новую зависимость. Один подрядчик может обслуживать одновременно десятки банков и ключевые элементы рыночной инфраструктуры.
Международный валютный фонд включил кибератаки в число трех главных угроз мировой финансовой стабильности наряду с переоценкой активов, связанных с ИИ, и скачком доходности государственных облигаций. Риск возникает не только из-за возможной кражи данных. Сбой у общего поставщика способен одновременно ограничить платежи, торговлю, доступ к депозитам и выдачу кредита.
Экономия на масштабе создает общий узел отказа
Крупный облачный или программный подрядчик распределяет расходы на центры обработки данных, защиту и разработку между многими клиентами. Отдельному банку трудно воспроизвести такой масштаб самостоятельно. Передача операций специализированной компании может повысить надежность каждого участника, если поставщик инвестирует в защиту больше, чем мог бы один банк.
Но та же экономия концентрирует риск. Если множество организаций использует одну платформу или одинаковый программный компонент, уязвимость становится общей. В отчете МВФ отмечается, что более чем в 70% выявленных случаев в 2026 году разработчики программ почти не имели времени установить исправление до начала эксплуатации уязвимости. Это примерно на 20 процентных пунктов больше, чем годом ранее.
Финансовая компания может не знать всей цепочки зависимости. Ее непосредственный подрядчик использует облако другого поставщика, библиотеку третьего разработчика и внешнюю систему идентификации. Такой участник второго или последующего уровня не всегда указан в основном договоре, хотя от него может зависеть критическая операция.
Операционный сбой становится финансовым через ликвидность и доверие
Первый ущерб обычно операционный: клиент не может войти в приложение, банк — провести платеж, биржа — обработать сделку. Затем возникают финансовые последствия. Компаниям приходится держать больше наличности, участники рынка не видят подтверждения позиций, а клиенты пытаются перевести средства в другую организацию.
Если сбой затрагивает платежную или клиринговую инфраструктуру, обязательства продолжают накапливаться, хотя расчет задерживается. После восстановления системе нужно обработать очередь операций. Ошибки и расхождения в этот момент могут увеличить потребность в ликвидности и залоге.
Особенно опасен одновременный сбой у нескольких формально независимых банков. В обычном кризисном плане предполагается, что клиент или платеж можно перенаправить к другому участнику. Если этот участник зависит от того же облака или программного обеспечения, резервный маршрут не работает. Техническая концентрация превращает отдельный инцидент в общий отказ.
Резервная копия не заменяет независимую инфраструктуру
Хранение копии данных необходимо, но недостаточно. Банку нужно проверить, может ли он восстановить критическую услугу без недоступного подрядчика, сколько времени займет переход и сохранятся ли полномочия сотрудников, ключи шифрования и актуальные записи об операциях.
Использование нескольких облаков также не гарантирует независимости. Два внешне разных сервиса могут опираться на общую сеть, систему идентификации или программную библиотеку. Регуляторам и банкам необходимо картировать зависимости до уровня участников, отказ которых одновременно затронет множество организаций.
Комитет по платежам и рыночным инфраструктурам Банка международных расчетов и Международная организация комиссий по ценным бумагам в сентябре начали консультацию о зависимости финансовой инфраструктуры от внешних поставщиков. Они предлагают оценивать не только надежность отдельного договора, но и концентрацию критических услуг на уровне всего рынка.
Расходы на устойчивость придется распределить заранее
Полная независимость от внешних технологий была бы слишком дорогой и лишила бы банки преимуществ специализации. Практическая задача состоит в том, чтобы определить функции, для которых допустим длительный простой, и операции, требующие отдельного резервного контура.
Для критических услуг нужны проверяемые сроки восстановления, регулярные совместные учения, переносимые данные и заранее согласованный порядок действий между банком, поставщиком и регулятором. Контракт должен объяснять, кто сообщает об инциденте, кто финансирует восстановление и какие права получает банк при прекращении работы подрядчика.
Киберстрахование может возместить часть прямых убытков, но не создаст новый платежный канал и не вернет доверие клиентов. Более того, общий инцидент у крупного поставщика способен вызвать множество требований одновременно, что ограничивает возможность страховщиков принимать такой риск.
Для бизнеса главным показателем становится не число предотвращенных атак, которое невозможно наблюдать, а время восстановления критических операций и доля процессов, которые можно перенести без потери данных. Именно эти показатели показывают, останется ли технический сбой расходом одного банка или превратится в проблему финансовой системы.
Источники
- Международный валютный фонд — киберриски и общие технологические зависимости финансового сектора.
- Банк международных расчетов — зависимость рыночной инфраструктуры от внешних поставщиков.
- Европейские надзорные органы — внешние технологические зависимости и киберугрозы.
