ИТ-шаманизм в банках: как легаси и 58 тысяч таблиц тормозят цифровой рубль 2026

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Для SMB это сигнал: закрытые АБС и «незаменимые» админы-легаси превращают обязательный проект цифрового рубля в бюджет 180–220 млн, а открытые альтернативы дают шанс зайти в корпоративный сегмент.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Сначала цифра, потом всё остальное

Пятьдесят восемь тысяч таблиц. Столько лежит в базе действующей АБС одного российского банка. В новой инсталляции, которую разработчик собрал с нуля, — меньше шестидесяти. Не тысяч. Шесть десятков.

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

История появилась не из отчёта консалтинга, а из технического поста разработчика из h3llo.cloud, который зашёл в банк с предложением новой банковской системы. И вышел с пониманием, что техническая часть проекта — самая простая. Потому что дедлайн уже назначен законом, а сопротивление внутри банка оказалось крепче любого легаси.

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

Что вообще произошло

Над банками навис цифровой рубль. Поддержка обязательна: системно значимые банки обязаны работать с ним с 1 сентября 2026 года, банки с универсальной лицензией — с 2027-го, остальные — с 2028-го. Для кредитной организации это означает доработку АБС, доработку дистанционного обслуживания, криптографию и сертификацию.

Публичные оценки такого проекта — от 100 до 300 млн рублей на банк. Предложения вендоров, которые видел разработчик, лежали в диапазоне 180–220 млн. Правление посмотрело на бюджеты и задало нормальный вопрос: а можно как-то иначе?

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

Проект новой АБС при этом существует. Система на стейджинге, базовый функционал работает, впереди ещё минимум полгода. То есть спор идёт не о фантазии в презентации, а о работающем коде.

ИТ-шаман разговаривает с бизнесом так же, только вместо духов у него легаси, которое он не документировал.

Масштаб проблемы в цифрах

Соберём то, что видно снаружи, без интерпретаций.

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

За действующую АБС банк заплатил очень много. Очень. Но одна из важнейших для банка фичей — интеграция с системой дистанционного обслуживания — за прошедшие годы так и не случилась.

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

Откуда берутся 58 тысяч таблиц

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

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

Классический сценарий с отчётами описан без прикрас. Нужен новый отчёт — специалист, пришедший когда-то от вендора АБС, пишет запрос вендору. Вендор делает отчёт. Банк платит. Специалист подключает результат и просит премию. Цикл замкнут и устойчив. Любой внешний разработчик, который сделает тот же отчёт сам, ломает не технологию, а поток благ.

Чем это отличается от предыдущих волн

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

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

Второй фронт — с 1 сентября 2026 года у банков появляется обязанность отвечать Соцфонду через систему межведомственного электронного взаимодействия: справки о счетах, остатках, выписки по счетам организаций и предпринимателей в электронном виде. Для этого нужны данные из АБС в стабильном виде, чтобы разные сотрудники не доставали их разными способами. Правильное решение — два отчёта в системе. Простое. Пока за него не берутся люди, для которых каждый отчёт — повод для нового запроса вендору.

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

Кому это нужно и что с этим делать

Владельцу SMB-бизнеса вся эта банковская драма интересна с трёх сторон.

Первая — вы клиент такого банка. Если ваш расчётный счёт живёт в организации, где интеграция АБС и клиент-банка держится на вечерних скриптах одного человека, вы это почувствуете на сверках, на возвратах, на зарплатных реестрах. Не в теории, а в конкретный день, когда платёж уйдёт дважды. Проверять просто: спросите у своего бухгалтера, сколько раз за последний год приходилось звонить в банк из-за расхождений в выписке.

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

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

Что делать по третьему пункту без бюджета в сотни миллионов:

• Выпишите список процессов, которые держатся на одном человеке. Не на отделе — на человеке.
• Проверьте, можно ли выгрузить свои данные из учётной системы в открытом формате. Если нет — вы арендуете не систему, а зависимость.
• Посмотрите договор на сопровождение: сколько вы платите за сам факт наличия системы и сколько за каждую доработку.
• Заведите правило: любая новая интеграция документируется в тот же день. Без исключений для «срочных задач».

Где подвох в этой истории

Разработчик честно оговаривает: он сторона заинтересованная, предлагал банку свою инфраструктуру и новую систему, а люди, о которых идёт речь, этому сопротивлялись. Значит, любая оценка их мотивов — версия одной стороны.

Часть возражений ИТ-департамента, скорее всего, вполне рабочая. В банке есть требования регулятора, есть меры безопасности, есть риск, что новая система не пройдёт сертификацию, и отвечать за это будет не автор поста. Переезд ядра банка — не миграция сайта. Здесь скепсис уместен.

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

В базе данных действующей АБС 58 тысяч таблиц. Тысяч, Карл!

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

Брать или подождать: вердикт за 30 секунд

Если вы банк с дедлайном 1 сентября 2026. Ждать нечего. Бюджет 180–220 млн — это не цена технологии, это цена пятнадцати лет накопленных компромиссов. Торгуйтесь не за скидку к смете, а за доступ к своей же базе и за право делать интеграции без посредника.

Если вы банк из второй или третьей волны (2027–2028). У вас есть год-два, чтобы разобрать завалы. Это дешевле, чем повторять историю с 58 тысячами таблиц.

Если вы SMB. Не ждите. Проведите ревизию зависимостей на этой неделе — она стоит ноль рублей и один вечер. Начните с вопроса: что случится с моим бизнесом, если завтра не выйдет один конкретный человек.

Если вы подрядчик. Заходите к корпоративным заказчикам с работающим стендом и фиксированной ценой пилота. Пока конкуренты несут презентации на 200 млн, стенд говорит громче.

Вердикт

Цифровой рубль не создал проблему. Он выставил счёт за неё.

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

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

Разница только в цене вопроса. У банка 180–220 млн. У вас — время собственника, которое уходит на разбор чужих недоделок.

FAQ

58 тысяч таблиц — это реально много?

Для сравнения: в новой инсталляции того же назначения — меньше 60. Справочники, история и отчётность в старой архитектуре добавляют ещё несколько сотен. Остальные десятки тысяч появились за пятнадцать лет доработок.

Почему ИБ и ИТ сопротивлялись, если проект обязательный?

Автор объясняет это личными мотивами: завершённый проект меняет расстановку сил внутри банка. Публично прозвучавших технических причин он не услышал. Утверждать, что других причин не было, нельзя — история рассказана одной стороной.

Можно ли в такой ситуации уложиться в меньший бюджет?

Публичные оценки проекта — 100–300 млн рублей на банк, предложения вендоров — 180–220 млн. Это вилка рынка, а не приговор конкретному банку. Ответ зависит от состояния своей системы, а не от прайса поставщика.

Что из этого применимо к небольшой компании?

Механика та же, масштаб другой. Закрытый формат данных, единственный носитель знаний о системе, плата за факт наличия софта и отдельная такса за каждую доработку — всё это есть и в SMB.

Цифровой рубль для SMB-банков — когда?

Системно значимые — с 1 сентября 2026 года. Банки с универсальной лицензией — с 2027-го. Остальные — с 2028-го.

Что сделать на этой неделе

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

Если дат нет — у вас есть свой дедлайн. Просто он пока не прописан в законе, и поэтому кажется, что времени много. Проблема в том, что у банков из этой истории тоже так казалось — ровно до 1 сентября 2026 года.