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

Материал подготовлен в партнерстве с PayForce

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

Главный Telegram-канал банкиров

Подписаться

Бюджет уходит на поддержку того, что уже есть

Технологический долг редко виден в финансовой отчетности как отдельная статья расходов. Он распределен между поддержкой инфраструктуры, работой IT-команд, исправлением ошибок и доработками, без которых не обходится ни один запуск новой функции.

Масштаб проблемы показывают исследования финансового сектора. KPMG Global Tech Report 2026: Financial Services основывается на опросе 760 технологических руководителей финансовых организаций. По его данным, третья часть из них направляет более 40% технологического бюджета на поддержку существующих систем. Аналогичную долю на развитие закладывают лишь 23% респондентов, а на трансформацию — 9%. 45% опрошенных признают, что из-за давления расходов упускают возможности инвестировать в новые технологии, а 43% — что стоимость устранения технологического долга мешает финансировать новые программы.

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

Схожую тенденцию фиксирует Европейский банковский орган (EBA). В отчете по оценке рисков за июнь 2026 года указано, что в 2025-м расходы на IT составили 32,1% других административных расходов банков против 31,2% годом ранее. 72% банков назвали основные банковские системы и платежную инфраструктуру среди ключевых источников IT-расходов.

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

Самые дорогие изменения — те, которых не видит клиент

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

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

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

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

Когда IT-ограничения становятся бизнес-проблемой

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

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

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

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

С чего начинать модернизацию

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

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

Модернизация без нового долга

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

В этом направлении работает и PayForce — украинская технологическая компания с более чем 20-летней банковской экспертизой, которая более 10 лет разрабатывает решения дистанционного банкинга. Ее платформа iBank — единая архитектура из более чем 20 модулей для обслуживания физических лиц, физических лиц-предпринимателей и юридических лиц, на которой уже работают более 10 банков. Модули подключаются или обновляются отдельно, без остановки существующих сервисов и без одновременной перестройки всей системы. Открытые API уменьшают потребность в обходных решениях, из которых и накапливается технологический долг.

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

Для банков-партнеров новое регуляторное измерение стало не срочным IT-проектом с риском сорвать сроки, а плановым шагом с предсказуемым результатом.

Расходы, которые стоит считать заранее

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

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

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