Что поможет банковским приложениям остаться на плаву при сбоях в сети?

В 2026 году ограничения мобильного интернета в России стали регулярной практикой. И если в марте массовые отключения фиксировались в основном в Москве и Санкт-Петербурге, то к маю власти официально предупредили о возможных временных блокировках связи, СМС и доступа к части сервисов во время праздничных мероприятий на остальной территории страны. На этом фоне начала формироваться система так называемых «белых списков» – перечней сервисов, доступ к которым сохраняется даже при ограничениях сети. По данным о развитии системы, к марту 2026 года механизм тестировался или использовался более чем в 68 регионах РФ.

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

«Нестабильный интернет – проблема, с которой сегодня сталкиваются все отрасли. Однако в финтехе она превратилась в архитектурный тупик. Оказалось, что текущая инфраструктура банков в большинстве своем не умеет работать без надежной связи», – пояснил директор Nord Clan Алексей Артамонов.

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

«В других (небанковских – Прим. ред.) типах приложений часть функций можно вынести в офлайн: сохранить данные на устройстве, дать пользователю базовый доступ без соединения и синхронизировать все позже. В банкинге такой подход не работает. Локальное хранение данных повышает риски, а проведение операций требует постоянной верификации», – объяснил эксперт.

Действительно, отдельная уязвимость банковских приложений – механизмы авторизации. Вход и подтверждение операций часто завязаны на СМС или пуш-уведомления, которые требуют стабильного соединения с интернетом. При задержках или недоставке кодов в течение короткого времени пользователь теряет доступ к сервису, даже если остальные компоненты системы работают корректно. При этом альтернативные способы подтверждения предусмотрены не всегда либо функционально ограничены.

Дополнительная проблема – отсутствие сценариев деградации (упрощенного режима работы приложения при плохой связи). Большинство приложений не умеют корректно «упрощаться» при ухудшении условий доступа в интернет. Вместо того чтобы ограничить функциональность и сохранить доступ к базовым операциям, система либо работает полностью, либо не работает вовсе. В результате текущая модель мобильного банкинга оказывается неустойчивой к нестабильному интернету. Архитектура, ориентированная на постоянное соединение, не позволяет выполнять даже базовые операций при сбоях, что делает вопрос ее пересмотра критически важным.

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

«Для продуктовых и технических команд это означает необходимость проектировать сервисы с учетом нестабильного соединения и решать задачи управления локальными данными и их консистентностью, предотвращения дублирующих операций и контроля рисков при отложенной обработке. Рекомендуем закладывать fallback-сценарии на этапе планирования и приоритизировать критические функции», – отметил Алексей Артамонов.

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

Ситуацию усложняет и то, что функционал самих банковских приложений продолжает расти. Банки активно развивают супераппы, объединяя в одном интерфейсе платежи, сервисы и сторонние предложения. По данным Boston Consulting Group, уже в 2023 году 27% банков имели высокий уровень вовлеченности в экосистемные модели, показывая более высокие финансовые результаты по сравнению с теми, кто их не развивал. Это увеличивает количество пользовательских сценариев и одновременно – число зависимостей от сети и внешних систем. При этом, согласно исследованию консалтинговой компании Deloitte, 68% банков считают цифровую трансформацию главным направлением для инвестиций, а до 75% всех изменений в банках связаны с цифровизацией. И чем больше таких зависимостей, тем выше риск сбоев. В результате проблема в одном звене приводит к нарушению работы сразу нескольких функций.

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

«Справляться с растущей сложностью помогает модульная архитектура. Многие банки используют системы библиотек, которые позволяют быстро пересобирать приложение под новые задачи. Кроссплатформенная разработка также ускоряет процессы. Технология Kotlin Multiplatform (KMP) позволяет создавать приложения сразу для нескольких операционных систем: Android, iOS, а также десктопных платформ», – указал глава Nord Clan.

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

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

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

«Для продуктовых команд ключевой задачей становится управление логикой решения: четкая модульная архитектура, жесткая приоритизация сценариев, контроль связей между сервисами. Особое внимание мы уделяем онбордингу и навигации, чтобы пользователь за короткое время понимал, как использовать новые сценарии внутри приложения», – заключил Алексей Артамонов.

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