Банк России — главный продакт кредитного конвейера: как банку успевать за регулятором

Регулятор так действует не из прихоти. На него давят четыре устойчивых фактора: рост мошенничества в онлайн-канале, увеличение доли заемщиков с высоким показателем долговой нагрузки (ПДН), массовое завышение доходов клиентами и потребность видеть «реальную картинку» по сектору в разрезе всего рынка. Темп реакций на эти факторы перестал совпадать с возможностями классической разработки: регулятор уже живёт в логике квартальных апдейтов, тогда как IT-команды банков зачастую остаются в логике крупных релизов раз в несколько месяцев.

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

• ежеквартальный пересмотр МПЛ — обновление пороговых значений доли высокорисковых кредитов;
• обновление методики расчёта ПДН — изменение коэффициентов, источников дохода, сроков актуальности данных;
• ужесточение подтверждения доходов при ПДН — только ФНС, справки по форме банка исключаются;
• сведения о рассрочках в кредитной истории — BNPL-обязательства теперь учитываются в ПДН и скоринге;
• обмен с БКИ в режиме реального времени — антифрод, онлайн вместо пакетного;
• уведомление заёмщика через Госуслуги при подписании договора — интеграция со СМЭВ/ЕПГУ.

Показательный пример — подтверждение доходов через цифровой профиль ФНС. У крупных банков с развитой аналитикой по счетам клиента, предрасчётом ПДН и готовыми интеграциями с ФНС есть шанс пройти этот этап относительно безболезненно. Для банка поменьше отсутствие интеграции означает необходимость перестраивать весь онбординг: встроить запрос справки 2-НДФЛ, выделить людей на проверку и перепроверку данных, перенастроить расчёт ПДН и протестировать всё это на исторических данных — и это лишь одна из задач, тогда как на горизонте их уже минимум шесть.

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

По моим наблюдениям, банки платят за каждое регуляторное изменение трижды — временем, деньгами и риском.
По времени классический цикл выглядит так: аналитик пишет техническое задание, формирует задачу, она проходит оценку, попадает в спринт, реализуется, тестируется и только после этого «выкатывается в прод». Даже если все этапы прошли без срывов, средний срок на внедрение одного изменения — 3–6 недель, при том что, например, между публикацией новых лимитов 29 января и обязательным их применением с 1 апреля у банка есть всего около двух месяцев.

Теперь про деньги. Здесь особенно дороги интеграционные изменения: подключение ФНС, настройка онлайн-обмена с БКИ, интеграция со СМЭВ и Госуслугами почти всегда превращаются в отдельные бюджетные проекты с участием внешних вендоров. Ситуацию усугубляет операционная математика: каждый запрос в ФНС и каждый PIN в БКИ стоит денег, поэтому стоимость обработки одной заявки растет, а ее маржинальность снижается, особенно с учетом того, что в случае с физическими лицами прибыль банку приносит лишь примерно каждая пятая обработанная заявка.

Что касается риска, то руководитель кредитного блока оказывается в парадоксальной ситуации. Он отвечает перед регулятором за соблюдение требований и перед руководством банка — за прибыльность направления, но фактический контроль над реализацией правил часто находится в IT-блоке или у вендора. В результате у банка не всегда есть ответ на базовый вопрос: «По той ли сейчас формуле считается ПДН и та ли версия указаний применяется в конвейере?»

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

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

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

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

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

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

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

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

Если разложить год работы банка с регулятором на последовательность из нескольких крупных изменений, классический подход превращает команду в вечный хвост Банка России. При средних сроках 3–6 недель на каждое внедрение только самые существенные изменения выливаются в полгода работы в режиме «догоняем регулятора».

В nocode-конвейере та же последовательность выглядит иначе: благодаря упрощенному процессу интеграции каждое изменение занимает 2–4 рабочих дня. Даже если считать их последовательно, весь массив требований можно закрыть примерно за один календарный месяц. Причём изменения не конфликтуют друг с другом: обновление справочников по лимитам не затрагивает настройки источников данных, а добавление шага уведомлений через Госуслуги не ломает расчёт ПДН.

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

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

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

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