Коммерческие банки, как правило, разрабатывали системы автоматизации кредитного процесса с использованием low-code-инструментов — конструкторов, которые позволяют достаточно быстро в визуальном редакторе выстраивать бизнес-процесс. Однако сейчас банки переходят к разработке решений на базе микросервисной архитектуры с применением BPM-движков для оркестрации процессов, таких, например, как Camunda. Сдвиг в сторону использования систем собственной разработки на микросервисной архитектуре для запуска кредитного конвейера обусловлен несколькими факторами.

Во-первых, 5–10 лет назад, когда кредитные процессы включали значительную долю ручных операций, low-code-платформы были удобным и популярным инструментом для быстрой разработки пользовательского интерфейса. Сегодня же до 90% шагов в розничном кредитовании — это автоматические проверки и интеграции с внешними источниками данных: цифровой профиль на портале «Госуслуги», бюро кредитных историй (БКИ) и другие источники. В таких условиях преимущества low-code-систем теряют актуальность из-за недостаточной гибкости и производительности.

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

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

Успешные примеры реализации подобных проектов уже есть на рынке: ВТБ внедрил розничный кредитный конвейер (РКК 2.0) на микросервисной архитектуре с Camunda, Газпромбанк разработал собственное решение с использованием Kubernetes, а банк «ДОМ.РФ» создал кредитный конвейер из более чем 60 взаимодействующих сервисов.

Как построить правильную архитектуру кредитного конвейера

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

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

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

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

Подводные камни при внедрении кредитного конвейера

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

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

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

Это особенно актуально для банков, переходящих на расчет достаточности капитала на основе внутренних рейтингов (ПВР), так как одно из основных требований ПВР — применение одинаковых моделей при принятии решений по новым сделкам и при расчете требований к капиталу.

Как ускорить разработку кредитного конвейера «с нуля»

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

Подобные решения сочетают в себе преимущества коробочного решения (быстрый запуск) и заказной разработки (передача исходных кодов банку и отсутствие vendor-lock). Они включают в себя базовую архитектуру, модель данных, платформенные сервисы (уведомления, справочники, авторизация и другие), а также адаптеры для интеграции с типовыми источниками данных, например БКИ, цифровой профиль клиента на портале «Госуслуги» или антифрод-системы. В совокупности это позволяет банкам сократить затраты на старте и быстро адаптировать кредитный конвейер под уникальные задачи бизнеса.

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