Ядро — это не проблема наследия. Это проблема стратегии.

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

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

Рассмотрим задачу по очередности (sequencing), с которой сталкивается большинство организаций в 2026 году. Наблюдательные советы утверждают программы агентного ИИ. Технологические команды движутся в сторону токенизированной инфраструктуры. Идет модернизация платежей. Функции по рискам и комплаенсу просят работать в реальном времени, а не в пакетных циклах. У каждой из этих программ есть весомое бизнес-обоснование. Но у каждой из них, в какой-то момент, требуется от «ядра» сделать то, для чего оно не было предназначено.

Агентные ИИ-рабочие процессы, которые выполняются автономно, нуждаются в подтверждении расчетов в реальном времени. Токенизированные депозиты требуют программируемой логики транзакций, которую монолитные «ядра» пакетной обработки не могут поддерживать нативно. Платежи в реальном времени требуют непрерывной сверки, а не обработки по итогам дня. Мониторинг комплаенса для программируемых денежных потоков 24/7 не может опираться на контрольные точки, которые закрываются в полночь.

«Ядро» было разработано для мира, где транзакции группировались в пакеты, окончательность откладывалась, а «ночное окно» было особенностью. Этот мир заканчивается быстрее, чем предполагают большинство дорожных карт модернизации.

Уровень неудач в программах модернизации основного банковского обслуживания делает срочность действовать не легче, а труднее. Большинство программ, пытающихся полностью заменить «ядро», идут долго, стоят дороже, чем прогнозировалось, и дают меньше, чем обещали. Исследование IBM показало, что 94% программ модернизации «ядра» пропускали свои первоначальные сроки. Организации, обжегшиеся на этих историях, вполне понятным образом осторожны в следующей попытке. Но осторожность в модернизации «ядра» — это не то же самое, что безопасность. Это выбор принять ограничения, а не устранить их, и со временем этот выбор только усиливается: расстояние между тем, что «ядро» может делать, и тем, что нужно бизнесу, становится все шире.

Те организации, которые проходят этот путь наиболее эффективно, не пытаются делать полную замену. Они внедряют sidecar-архитектуры: современные «ядра» работают параллельно с наследственными системами, обрабатывая конкретные продукты, клиентские сегменты или типы транзакций, где наследственное ограничение наиболее остро. IDC прогнозирует, что к 2026 году 40% глобальных банков будут применять этот подход. Логика здравая: доказать, что новое «ядро» работает в ограниченном контуре, показать, что миграция не ломает то, от чего зависит бизнес, и расширять решение инкрементально. Это медленнее, чем замена. Зато вероятность успеха существенно выше.

Однако более важный переосмыслитель заключается не в том, какой именно подход к модернизации выбрать. Речь о том, где «ядро» находится в стратегической очередности (sequencing) внутри организации.

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

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

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

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