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

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

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

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

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

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

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

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

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

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

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

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

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