Кредитный конвейер что это
Обновлено: 07.05.2024
- Операционная работа и международные операции
- Денежные переводы
- Переводы в рублях
- Переводы в иностранной валюте
- Электронные денежные переводы
- Платежные карты
- Безопасность денежных переводов
- Документарные операции
- Расчеты по аккредитивам
- Банковские гарантии
- Расчеты инкассовыми поручениями и чеками
- Торговое финансирование
- Риски документарных операций
- Валютный контроль
- Валютный контроль за операциями физлиц
- Валютный контроль за операциями юрлиц
- Нарушение валютного законодательства
- Журналы по расчетам и операционной работе
- Методические пособия (Операционная работа и международные операции)
- Статьи из пособий (Операционная работа и международные операции
- Риски портфелей (продуктов)
- Риски розничного портфеля
- Риски корпоративного портфеля
- Риски портфеля ценных бумаг
- Риски платежных систем
- Виды рисков
- Кредитный риск
- Рыночный риск
- Риск ликвидности
- Операционный риск
- Нефинансовые риски
- Журналы по управлению рисками
- Методические пособия (Риск-менеджмент)
- Статьи из пособий (Риск-менеджмент)
- Розничные продукты
- Розничные кредиты
- Банковские карты
- Наличность и чеки
- Вклады и драгметаллы
- Микрофинансирование
- Private Banking
- Розничные технологии
- Технологии продаж
- Мобильный банкинг
- Интернет банкинг
- Платежные терминалы и банкоматы
- Бизнес-процессы
- Взаимодействие с контрагентами
- Обслуживание клиентов
- Персонал и кадры
- Кредитный анализ
- Оценка финансового состояния заемщика
- Отраслевой анализ
- Оценка риска заемщика
- Лимиты кредитования
- Формирование резервов
- Оценка кредитного портфеля
- Кредитные продукты
- Корпоративные кредиты
- Кредиты МСБ
- Кредиты физлицам
- Долгосрочное финансирование
- Синдицированное кредитование
- Обеспечение кредита
- Залог
- Гарантия
- Поручительство
- Обслуживание кредита
- Мониторинг выданных кредитов
- Внесудебное взыскание просроченной задолженности
- Судебное взыскание просроченной задолженности
- Кредитное мошенничество
- Журналы по кредитованию и рознице
- Методические пособия (Банковское кредитование и ритейл)
- Статьи из пособий (Банковское кредитование и ритейл)
- Внутренний контроль и аудит
- Аудит бизнес-процессов
- Аудит банковских операций
- Контроль банковских рисков
- Контроль за банковскими рисками
- Обеспечение непрерывности банковской деятельности
- Финансовый мониторинг
- Идентификация клиентов и выгодоприобретателей
- Выявление подозрительных операций
- Риск вовлечения банка в процессы легализации ПД/ФТ
- Информационная безопасность
- Безопасность персональных данных
- Защита от угроз
- Риски электронного банкинга
- Комплаенс - контроль
- Договорная политика
- Финансовый контроль
- Налоговый риск
- Журналы по внутреннему контролю, аудиту и комплаенс
- Методические пособия (Внутренний контроль & комплаенс)
- Статьи из пособий (Внутренний контроль & комплаенс)
- Бухучет и отчетность
- Организация бухучета и документооборот
- Порядок учета банковских операций
- Отчетность по РПБУ
- Налогообложение
- Налог на прибыль
- Налог на добавленную стоимость
- Налог на доходы физических лиц
- Имущественные налоги
- Трансфертное ценообразование
- Налоговая отчетность
- Международная отчетность
- Международные стандарты отчетности
- Трансформация отчетности
- Раскрытие информации
- Аудит международной отчетности
- Журналы по бухучету и налогобложению
- Методические пособия (Бухучет и налогообложение)
- Статьи из пособий (Бухучет и налогообложение)
- Правовое регулирование деятельности банка
- Банковский надзор
- Правоотношения с контрагентами
- Административная ответственность
- Юридическое сопровождение банковских операций
- Кредитные договоры
- Обеспечение сделок
- Уступка прав требования
- Ценные бумаги; вклады и депозиты
- Переводы и документарные операции
- Арбитражная практика
- Взыскание просроченной и проблемной задолженности
- Обращение взыскания на залоги
- Банкротство и исполнительное производство
- Банковский счет и комиссии
- Налоговые споры
- Журналы по юридической работе
- Методические пособия (Юридическая работа)
- Статьи из пособий (Юридическая работа)
- Управление капиталом банка
- Регулирование и надзор (БКБН + ЦБ РФ)
- Управление банковскими рисками
- Финансовый анализ
- Слияния и поглощения
- Стратегический менеджмент
- Стратегическое планирование
- Управление качеством
- Построение и развитие филиальной сети
- Инвестиционный банкинг
- Корпоративное управление
- Взаимодействие с учредителями и акционерами
- Финансовое планирование
- Управление персоналом
- Журналы по вопросам управления
- Методические пособия (Управление банком)
- Статьи из пособий (Управление банком)
![]()
Кредитный конвейер: на какие решения ориентироваться банкам
Алексей Северов ИТ-архитектор, эксперт в области цифровой трансформации и корпоративной архитектуры, к.э.н.
Кристина Котельникова компания Neoflex, ведущий консультант бизнес-направления «Фронт-офисные решения»
Александр Кульвинский компания Neoflex, ведущий консультант бизнес-направления «Фронт-офисные решения»Кредитный конвейер был «на острие» технологий 10–15 лет назад. Сейчас на первый план выходят цифровые двойники объектов предметной области и тонкая обработка данных для проактивного взаимодействия. Если BPM уже стали нормой, то что обсуждать: Low-Code, реализацию конвейеров на основе микросервисов или замещение «тяжелых» вендорских BPM-движков «легкими»? Мы объединили обзор технологий, включая опыт КБ «Ренессанс Кредит», с мнением экспертов одной из ведущих компаний-разработчиков.
Требования банка к инструментам работы с кредитами любого типа: — омниканальность взаимодействия с потенциальным клиентом; — поддержка всех особенностей организации процессов банка; — возможность организации поточной работы с разными типами кредитов — как для физических, так и для юридических лиц; — максимально доступная скорость обработки заявки на кредит и снижение риска человеческой ошибки при этом; —.
Материал в полном объеме доступен только подписчикам.
Если вы являетесь подписчиком, войдите на сайт, или узнайте, как получить доступ.Внимание, Акция!
Получите эту + еще 2 любых статьи из журналов бесплатно, зарегистрировавшись на сайте и заполнив полную информацию о себе.Почему Московская биржа занимается маркетплейсом для «физиков», мы немного говорили здесь. Если коротко: мы давно больше, чем биржа, и успешно работаем на внебиржевых рынках — для этого у нас хватает и знаний, и технологий. Плюс к тому, одна из наших задач — развивать финансовую культуру страны. Вот мы и развиваем — создавая продукты, которые меняют представление об управлении личными финансами. Иметь несколько вкладов на разные цели, между которыми можно перекладывать деньги в пару кликов, а если хочется инвестировать, тут же можно прикупить облигаций регионов — круто же?
Но мы отвлеклись. Сегодняшний материал будет о продукте «Кредиты». О том, как создавались кредиты на Финуслугах, с какими вызовами мы столкнулись и как с ними справились, рассказывают ребята из продуктовой команды: Андрей Кителёв (тимлид команды), Алёна Садовская (лидер разработки продукта) и Павел Кряженков (директор департамента разработки электронных платформ). Спойлер: будет и про командную работу, и про knowledge-management, и про чистую архитектуру.
Выбор продукта
Из всей линейки кредитных продуктов первым мы выбрали именно потребительский кредит, и вот почему:
у каждого банка уже есть такой продукт;
потребительский кредит максимально понятен клиентам;
потребительские кредиты популярны, и на их основе можно будет быстрее внедрять новые продукты: кредитные карты, рефинансирование, кредиты под залог.
Преимущества потребительского кредита на Финуслугах:
могут обслуживать клиентов из любого региона России;
не тратятся на физическое обслуживание клиентов (например, во время подписания документов в офисе);
могут сосредоточиться на предложении лучших условий по продукту вместо разработки креатива и концепции продвижения;
могут получить большой поток клиентов, которые генерирует сам маркетплейс.
могут получить кредит не в том банке, который рядом, а в том, в котором выгодно;
могут получить сумму кредита на счёт в любом банке.
Начало проекта
Старт работ по кредитам на Финуслугах совпал у нас с переходом от монопродуктовой к мультипродуктовой разработке и с созданием продуктовых команд. Проект был амбициозным, необходимо было из одной большой команды, разрабатывавшей депозиты на Финуслугах, выделить:
отдельную продуктовую команду для разработки линейки «Сбережения»;
сервисные команды для работы над кросс-продуктовой функциональностью;
а также создать новую команду, которая менее чем за год смогла бы запустить MVP, позволивший бы оформлять кредит в любом банке через сайт Финуслуг.
Первой ключевой задачей команды было определение функций MVP. Мы собрали рабочую группу из различных участников и партнёров проекта Финуслуги, и по результатам её деятельности команда «Кредиты» разработала универсальный процесс онлайн-кредитования, который учитывает все потребности каждого клиента, соответствует законодательной базе РФ и подстраивается под особенности любых банков. Сначала проанализировали процессы получения кредитов у банков из рабочей группы, после чего провели исследования первых прототипов на реальных клиентах и коридорные исследования с работниками смежных подразделений Московской биржи. В результате сформулировали основные этапы процесса:
заполнение короткой анкеты;
получение нескольких предварительных предложений от банков;
выбор лучшего предложения и заполнение полной анкеты для его подтверждения;
получение финального предложения от понравившегося банка;
подтверждение финального предложения;
выдача денежных средств и отправка отчёта в РФТ (Регистратор Финансовых Транзакций).
Попытка купить готовое решение (кредитный конвейер)
Сначала мы делали ставку на приобретение готового кредитного конвейера и встраивание его в архитектуру Финуслуг. Изучили рынок, но решения, которое полностью удовлетворило бы нашим нуждам, просто не существует, потому что каждое из них адаптировано под свои определённые цели и не позволяет создать тот универсальный продукт, который был в наших планах. В итоге решили делать самостоятельно — это позволило нам разработать универсальный сервис и не зависеть ни от кого при его дальнейшем развитии. Мы сами принимаем решения по его доработке, в том числе по запросам партнёров и пользователей
Технические решения по ходу разработки
Для нового продукта нам понадобилось разработать несколько новых микросервисов:
Обработка кредитных заявок клиента и банковских предложений.
Обработка кредитных договоров.
Интеграционный шлюз для работы с банками.
API для UI-приложения.
Также внесли небольшие доработки в общие платформенные сервисы маркетплейса (уведомления, словари, продуктовый каталог и прочее).
![]()
О технологическом стеке проекта Финуслуги мы писали год назад, и с тех пор он существенно не изменился. Использование того же стека помогло минимизировать затраты на поддержку нового продукта, а также позволило применить практики InnerSource для кросс-командной разработки общих платформенных сервисов и тем самым ускорить внедрение новых фич.
Для разработки кредитных микросервисов старались использовать best practices проектирования ПО, а также опирались на опыт разработки существующих сервисов внутри экосистемы Финуслуг, чтобы поддерживать общую целостность и придерживаться единых стандартов в проекте.
Разработка
Мы ставили перед собой цель обеспечить не только высокое качество продукта, но и простоту его поддержки. Большую роль в этом сыграл подход к написанию документации. Мы уделили ей особое внимание с самого начала проекта. В вики описывалось всё — от верхнеуровневого представления процессов до правил маппинга полей при обработке каждой конечной точки. Периодически мы сомневались, целесообразно ли тратить столько сил на документацию, но по мере усложнения процессов приходило понимание, что оно того стоило:
Низкий порог входа для новых участников команды, которые быстрее разбирались в продукте и начинали приносить пользу.
Более качественная реализация задач.
Минимизация ошибок и оперативное их устранение.
Упрощение межкомандного взаимодействия за счёт описанных процессов.
А сейчас, на этапе поддержки продукта, в пользе документации мы убеждаемся ещё больше.
Также разработчики придерживались принципа коллективной ответственности за кодовую базу. Все merge request’ы (МРы) в обязательном порядке проходили код-ревью, и только после получения минимум двух одобрений код заливали в основную ветку. На проверку каждый день выделяли по полчаса утром и вечером. При выявлении ошибок программирования мы не искали виноватых на основании истории изменения исходного кода, потому что влитый код означал, что команда приняла эти изменения коллективно. Такой принцип стимулировал разработчиков старательно проверять код и не одобрять его просто так.
1. Техтолки
Большую роль в повышении качества кодовой базы сыграла и практика регулярных встреч-техтолков командой разработчиков. На встречах обсуждали любые вопросы и сложности, возникающие при работе с кодовой базой, а также принципы написания кодовых конструкций, минимизирующие вероятность ошибок за счёт улучшения читаемости и поддерживаемости.
Правила именования и внутренней структуры тестовых методов.
Принципы работы с null-объектами, использование класса java.util.Optional .
Способы написания миграционных скриптов БД (Liquibase DSL или SQL).
Выбор фреймворка для маппинга DTO.
Все договоренности мы записывали в вики на отдельной странице, которая служила разработчикам хорошим руководством при написании кода и значительно уменьшала когнитивную нагрузку, не относящуюся напрямую к решению бизнес-проблемы.
2. Проба чистой архитектуры
Кроме вопросов написания конкретных фрагментов кода на техтолках обсуждалась также и архитектура сервисов. Изначально все сервисы мы писали по стандартному принципу создания веб-приложений из трёх условных слоёв: веб, сервисы и доменная модель. Но по мере усложнения бизнес-логики стало всё труднее расширять существующую функциональность. На помощь пришла концепция чистой архитектуры, о которой написан не один десяток книг. Она нам очень понравилась, хотя опыта работы с ней практически не было.
Посовещавшись, решили испробовать новую концепцию на свежем микросервисе для работы с контрактами. В качестве руководства использовали книгу "Get Your Hands Dirty on Clean Architecture" — пожалуй, самое практическое руководство по чистой архитектуре. Автор не настаивает на конкретном способе реализации архитектуры и не позиционирует его серебряной пулей, которая решит все проблемы. Вместо этого он призывает сохранять баланс между архитектурной сложностью и гибкостью решения в зависимости от поставленной задачи.
На создание основы сервиса по новому подходу ушло больше времени, чем обычно. Для сервисов со старой парадигмой мы используем Maven-архетип, который позволяет за пару минут создавать заготовку сервиса. А с чистой архитектурой так уже не получалось: доработка под новую концепцию заняла бы ещё больше времени, чем создание сервиса с нуля. Также необходимо было определиться с модульной структурой сервиса, выбрать наиболее подходящую стратегию маппинга и понять, как это всё сочетается с использованием ORM-фреймворка. Не будем сейчас углубляться в подробности, иначе статья превратится в отчёт об использовании clean architecture вместо обзора проделанной нами работы, но с удовольствием ответим на все вопросы в комментариях 😉
![]()
Однако в сравнении со стандартным архитектурным подходом у чистой архитектуры выше порог вхождения (особенно для разработчиков с небольшим опытом работы), но это решается проведением митапов внутри команды и совместным обсуждением всех принимаемых решений.
Тестирование
Основным принципом было тестирование не сервисов или отдельных фич, а продукта в целом. Большое внимание мы обращали на пользовательский опыт. Проверяли функциональность, максимально имитируя эксплуатационную среду: к изменению БД и сбросу состояния клиента приходилось прибегать только в случае крайней необходимости. В тестировании принимала участие вся команда, от разработчиков до владельца продукта, что способствовало большой вовлечённости в процесс создания.
Бизнес-мониторинг
Так как мы планировали выпустить продукт, который будет целевым в ближайшие годы, то уже к моменту его запуска сформировали требования к мониторингу.
Первая задача — своевременное отслеживание и реагирование на возможные ошибки со стороны системы для контроля качества её работы с точки зрения клиентов. Мы в любой момент времени видим на дашбордах состояние системы, получаем оповещения при технических сбоях и узнаем о проблемах клиента чаще всего ещё до того, как он обратится в поддержку.
![]()
В качестве одного из основных инструментов для бизнес-мониторинга мы используем Grafana. Она помогает нам визуализировать показатели системы в различных бизнес-процессах, наличие отклонений в воронке и прочую важную для поддержания качества информацию.
Также мы с самого начала стали изучать сильные и слабые стороны нашего бизнес-процесса с помощью детального анализа действий наших клиентов на сайте, результатов их заявок и причин выбора тех или иных продуктов. Это позволяет нам строить дальнейшие планы по развитию.
Еще одной важной задачей мониторинга является контроль выполнения SLA — времени ответа со стороны наших партнёров на различных этапах бизнес-процесса. Ведь под капотом оформления заявки происходит взаимодействие с подключенными к маркетплейсу банками, благодаря чему система в онлайне позволяет получить несколько реальных кредитных предложений в рамках одного кредитного продукта каждого банка.
Планы по развитию
Мы двигаемся итерационно: формируем гипотезы, проверяем их с помощью различных инструментов, и в случае положительного решения ставим в бэклог разработки.
В ближайших планах:
оптимизировать клиентский путь, минимизировав требуемые от клиента действия и ввод данных;
подключить Цифровой профиль, который позволит повысить уровень одобрения и качества предложений от банков;
расширить совместно с банками перечень потребительских кредитов;
расширить линейку неплатформенных продуктов: предоставить клиенту ещё больше вариантов возможных кредитов.
В списке долгосрочных задач — запустить новые типы кредитных продуктов, создать собственный кредитный рейтинг пользователей, разработать подборщик продукта, наиболее точно отвечающий потребностям клиента, и многое другое.
![]()
«Успешные люди вырываются вперёд, используя то время, которые остальные используют впустую», — говорил (так пишут в интернете) изобретатель конвейера Генри Форд. Как микросервисы и графовая платформа помогают экономить время в новом кредитном конвейере ВТБ, читайте под катом.
Почему конвейер
Процесс формирования предложений по кредитам и одобрения заявок клиентов включает несколько стадий. Банку нужно проанализировать потребности клиента, кредитную историю, риски, оценить, нужен ли клиенту продукт, справится ли он с кредитной нагрузкой, какую сумму и какие условия можно ему предложить.
За каждую стадию отвечает определённый модуль, вместе они образуют кредитный конвейер.
оценку кредитной истории (основные источники: БКИ, внутренние данные банка);
оценку платёжеспособности (зарплатные зачисления, транзакционные и иные внутренние данные);
определение уровня риска (вероятности дефолта);
расчёт лимита кредитования;
определение ценовых условий;
выбор продукта для клиента с использованием моделей склонности (в случае формирования предодобренных предложений).
Основной кирпичик в построении архитектуры кредитного конвейера — статистические модели, использующие для оценки всю доступную информацию. На первом этапе запуска конвейера ВТБ внедрил модели оценки кредитного риска клиента и модели склонности к кредитному продукту.
Уникальность кредитного конвейера ВТБ в том, что модели обрабатываются с помощью обращения к централизованной платформе исполнения моделей.
Платформа исполнения моделей
В кредитном конвейере ВТБ мы реализовали платформу исполнения моделей на микросервисах, она позволяет предоставлять различным потребителям модель-как-сервис (MaaS) с использованием различных фреймворков обработки данных как в режиме онлайн с малым временем ответа и высокой нагрузкой, так и в пакетном режиме для обработки практически любых объёмов данных.
Описывающие бизнес-процесс модели обращаются к единой платформе, в ней осуществляются необходимые расчёты и предоставляются результаты для дальнейшего использования в процессе.
С кредитным конвейером платформа связана через набор интеграционных адаптеров, что даёт возможность гибко настраивать процессы конвейера и взаимодействовать с ней на различных этапах обработки заявки.
В процессе работы платформы все данные о работе системы сохраняются, что позволяет их использовать в дальнейшем для мониторинга работы и обучения моделей.
Вскоре мы дополним её централизованной системой управления моделями, которая позволит вести полный независимый реестр используемых в банке моделей, их версий, оперативно поставлять обновлённые модели и даже автоматически переобучать их без участия человека.
Платформа исполнения дополняется новыми специализированными компонентами — графовой платформой и геоплатформой.
Графовая платформа
Графовая платформа служит для выявления и предупреждения мошенничества. Она состоит из графовой СУБД и удобного интерфейса для работы пользователей. СУБД интегрирована с хранилищем данных на базе Hadoop и служит для построения связей (рёбер) между различными вершинами. Интерфейс используется для дополнительного анализа построенных пользователями графов.
Выявление потенциального кредитного мошенничества может производиться как в режиме реального времени, так и в рамках offline-мониторинга (выявление и расследование реализованных случаев кредитного мошенничества, анализ концентраций уровня риска на предмет возможного кредитного мошенничества и т. д.).
Выявление, расследование и противодействие кредитному мошенничеству осуществляется с применением методов графовой аналитики, анализа связей и установления противоречий. Результаты расследования признаков кредитного мошенничества могут влиять на маршрутизацию кредитной заявки и уровень принятия кредитного решения.
Геоплатформа
Удобным инструментом для анализа потребностей и интересов клиента в процессах банка выступает геоплатформа. Она представляет собой совокупность геослоёв различных обезличенных данных, на основе анализа которых с применением методов автоматического машинного обучения (Auto ML) можно прогнозировать спрос, потоки клиентов и другие факторы для принятия решений. Продукты геоплатформы служат для оценки и прогноза потока покупателей и для размещения таргетированной рекламы.
Собранные в единую геосетку данные позволяют использовать методы Аuto ML, что ускоряет процесс вывода продуктов на рынок. Геоплатформа вмещает 170 слоёв обезличенных данных из банковской сферы, телекома и digital-сервисов. Такой модуль позволяет учитывать в моделях оценки клиентов широчайший спектр географических особенностей — от уровня региона и ситуационной конфигурации расположения офисов до локаций проживания и работы отдельного клиента.
Модель оценки дохода
При выдаче кредита одной из главных задач является определение платёжеспособности клиента. В современных банках эта задача чаще всего решается вручную, в то время как в кредитном конвейере на помощь снова приходят статистические модели. Модели оценки дохода позволяют оценить потенциальный доход клиента по всей доступной по нему информации:
информация о ранее поданных заявках на кредитные и некредитные продукты;
информация по депозитам и счетам;
платёжная дисциплина по ранее выданным кредитам и т. д.
Использование этой модели в процессе кредитования позволяет формировать полноценные предодобренные предложения и определять оптимальную кредитную нагрузку, как если бы клиент обратился в банк сам, без запроса дополнительной информации на момент оценки.
Технологический стек под капотом
Для реализации расчётного кредитного конвейера мы использовали микросервисную архитектуру с оркестрацией посредством bpm-движка Camunda. Camunda представляет собой набор библиотек, которые позволяют выполнять описанные процессы. Такой подход позволил разработать гибкую и масштабируемую архитектуру и помимо этого имел следующие плюсы:
возможность восстановления процесса ровно с того места, где произошел сбой, причём это доступно из коробки;
наличие GUI, позволяющего увидеть, что происходит с процессом;
возможность написания юнит-тестов не только на логику и интеграцию, но и на сам процесс.
Микросервисы, осуществляющие этапы работы конвейера, реализованы как java-компоненты с использованием каркаса Spring и конфигурируются при помощи Spring Boot. Компоненты имеют собственные источники данных, построенные на базе СУБД PostgreSQL. Поскольку конвейер должен принимать решение за несколько минут, доступ к БД осуществляется посредством Spring ORM с оптимизацией для быстрых и высоконагруженных запросов. Взаимодействие между компонентами системы асинхронное и реализовано посредством Apache Kafka.
Кроме этого, микросервисы интегрируются с внешними системами, используя различные технологии и протоколы, такие как REST API, IBM MQ, Apache Kafka.
Для чего всё это нужно
На данный момент кредитный конвейер уже формирует предодобренные предложения по кредитам наличными и кредитным картам, это начальный этап его внедрения.
В 2022 году он позволит нам принимать 95 % решений о выдаче кредитов розничным клиентам за 1–3 минуты. Что касается остальных 5 % заявок, они приходятся на те случаи, когда к проверке заявки необходимо подключать андеррайтера. Полностью исключать сотрудников банка из процесса андеррайтинга мы не планируем, поскольку их участие крайне важно для выявления новых схем мошенничества.
Кроме того, с 20 до 5 % снизится доля клиентов, которые для получения кредита предоставляют подтверждающую доход и занятость справку.
Новый конвейер позволит оперативно подключать новые источники информации о клиентах, что сделает точнее оценку рисков и позволит предложить лояльным клиентам более низкую ставку.
В постковидный период в банковской сфере, находящейся под пристальным надзором регулятора, особенно актуальным становится совершенствование механизма кредитования юридических и физических лиц.
Галина Бахметьева, генеральный директор компании «Брейнисофт» (резидент Технопарка «Сколково»)
За поддержкой обращается с трудом переживший локдаун бизнес. Растет поток уличных клиентов, и банк тратит на их обслуживание все больше ресурсов. Однако в силу специфики направления (проведение большого количества однотипных операций) финансовые организации могут сократить расходы на найм дополнительных сотрудников с помощью кредитного конвейера (КК), который упрощает процедуру заключения и ведения кредитных договоров.
Кредитный конвейер – это организационно-технологическое решение для непрерывного обслуживания важнейших банковских процессов, связанных с продажей, оформлением, выдачей и последующим обслуживанием кредитных продуктов для физических и юридических лиц. Цели такого конвейера, как и на любом другом предприятии, - увеличить объемы производства при снижении издержек на единицу выпускаемой продукции (то есть выдаваемый кредит). И если при кредитовании корпоративного бизнеса можно обойтись без КК, поскольку каждому клиенту предлагаются индивидуальные условия, то при работе с МСБ и физлицами КК поможет автоматизировать рутину и обеспечит качество принимаемого решения. В этом сегменте получить качественный субъективный опыт оценки очень сложно, а так человеческий фактор будет исключен.
Еще 10 лет назад, когда рынок потребительского кредитования только разворачивался, банки гасили риски за счет высоких процентных ставок. Из четырех кредитов не возвращались три, но процентов с одного хватало, чтобы возместить убытки. Решение о выдаче кредита принималось около недели, ведь для того, чтобы подготовленные параметры однозначно интерпретировать (при нелинейности связей между ними), банки опирались на накопленный субъективный опыт сотрудников-экспертов, и окончательные решения принимали кредитные комитеты с ограниченными ресурсами. Сейчас на это времени нет.
Поэтому в рамках КК автоматизируются такие функции, как: подбор кредитного продукта, подача заявки, первичная классификация заемщика и присвоение ему определенного статуса, формирование и отправка запросов в Бюро кредитных историй, принятие решения согласно скоринговой системе оценки с возможностью использования ручного анализа в спорных моментах, оформление и выдача кредита, ведение досье и т.п. Система скоринговых карт должна очень точно ранжировать все входящие сделки по уменьшению или увеличению вероятности дефолта. Насколько модуль будет точно прогнозировать дефолт – настолько точным будет конвейер. Но первым этапом внедрения кредитного конвейера остается запуск системы сопровождения кредитных договоров (рассылка уведомлений, прием платежей, учет и взыскание проблемной задолженности), без которой в банке случится коллапс.
В процессе кредитования используется структурированная и агрегированная информация на основе big data с применением технологий Business Intelligence и Advanced Analytics, вся информация о заемщике перемещается по конвейеру вместе с задачей, вся процедура стандартизирована и регламентирована.
КК адаптируется под запросы каждой финансовой организации, так как требуется согласованность взаимодействия всех этапов заключения кредитного договора между несколькими ИС и различными группами исполнителей. А в банках используются различные ИС, различаются кредитные продукты и т.п. Если банк - монолайнер с одним кредитным продуктом, который пользуется высоким спросом и не меняет условия, достаточно простого решения с прописанной заранее бизнес-логикой. Если добавляются новые продукты, меняются ставки и т.п., ИТ механизм КК будет очень сложным, и его интеграция с существующими банковскими системами -также сложный и долгий процесс.
С внедрением КК организационные риски заменяются технологическими, причем последние должны в перспективе сократиться. Автоматизированное решение исключает ошибку оператора, качественная интеграция с банковскими системами снижает риск искажения данных, система не позволит пропускать шаги, необязательные с точки зрения человека, журналирование позволит отследить ошибку на любом этапе операции по выдаче кредита, если это потребуется.
Окупаемость КК зависит общего количества и регулярности потока кредитных заявок в разрезе продуктовой линейки банка, а также от степени стандартизации самих заявок. Для банка без развитого розничного бизнеса стоимость КК будет высокой.
Свой облачный конвейер для финансового сектора предложила компания "Брейнисофт", резидент Технопарка "Сколково". Компания разрабатывает ПО для микрофинансовых и микрокредитных организаций, лизинговых компаний, кредитных кооперативов, банков и ломбардов.
Кредитный конвейер полного цикла (то есть от заявки на кредит до отчетности в контролирующие органы) автоматизирует процессы по выдаче займов удаленно и в офисе, обратному лизингу, POS-кредитованию, продуктам по подписке, исламскому банкингу. Важно отметить, что российским кредитным организациям, работающим в нескольких часовых поясах, необходимо в короткий технологический перерыв до начала следующего операционного дня уложить все начисления процентов по займам и рассчитать кэшбек. В условиях онлайн-кредитования и онлайн-погашений обработка начислений и расчетов во время технологического перерыва не должна блокировать возможность приема платежей в реальном времени.
Кредитный конвейер «Брейнисофт» состоит из 3 этапов: лидогенерация (получение заявки от потенциального клиента), заполнение анкеты-заявки и оценка благонадежности заемщика, по итогам которой принимается решение о выдаче займа. Процесс оценки заемщика протекает с помощью «Системы принятия решений» (СПР) через запросы во внешние базы данных. Вместе с тем для каждой заявки система предполагает индивидуальную настройку параметров — как ручную, когда решения принимаются специалистами компании, так и автоматическую, в режиме которой робот по настроенному алгоритму за несколько секунд выдает ответ. К платформе можно подключить практически любую внешнюю базу данных через API. Возможно более 60 интеграций с внешними сервисами.
Для корректного сопровождения сделки система позволяет настроить кредитование по 134 доступным параметрам и вести учет практически любого кредитного продукта — краткосрочные и долгосрочные займы, кредиты наличными, лизинг, ипотека и POS-кредиты.
Бэкенд системы «Брейнисофт» построен на основе сервис-ориентированной архитектуры, ключевым компонентом которой является ядро — в нем сосредоточена основная бизнес-логика и основные механизмы расчета. Совместно с ядром работают периферийные сервисы, в которые выносится вспомогательная функциональность. Отдельная категория сервисов в бэкенде — это шлюзовые сервисы, в которых реализуются механизмы интеграции с внешними системами.
Для обеспечения отказоустойчивости и высокой доступности сервисы бэкенда организовываются в виде кластеров. В кластере одновременно работает несколько инстансов сервиса. Отдельные инстансы развертываются таким образом, чтобы отказ на любом уровне не приводил к отказу в обслуживании сервиса в целом.
Запросы к сервису приходят через входящий балансировщик, который затем распределяет их по отдельным инстансам в кластере. Балансировщик также резервируется, чтобы не стать единой точкой отказа.
Мультитенантность сервиса обеспечивается за счет выделения данных разных тенантов в разные базы данных.
Мощность конвейера позволяет проводить ежедневную обработку 3 млн кредитных контрактов за 3 часа, и это далеко не предел. Безопасность сделки обеспечивается посредством идентификации клиента во время видеозвонка.
При этом входная стоимость конвейера в 2 раза ниже, чем у европейцев. Внедряется он за 2 месяца.
На сегодняшний день «Брейнисофт» работает в 5 странах: России, Казахстане, Молдове, Польше и Румынии. В портфеле - 260 B2B клиентов, в числе которых: AlHilal Bank, Toyota Finance, «Сбербанк», Home Credit. За год экспортная выручка компании выросла более чем в 3 раза. В ближайшем будущем «Брейнисофт» намерен освоить рынки США, Индии, Индонезии, ОАЭ, Саудовской Аравии.
Не знакомые с внутренней банковской кухней люди могут представить процесс кредитования рутинным: море сотрудников банка — андеррайтеров вручную рассматривают поступающие от клиента заявки и обращаются во всевозможные инстанции, чтобы подтвердить правдивость данных. На деле все выглядит совсем не так. Больше 90% заявок рассматривает машина. Так называемый кредитный конвейер. Технология, конечно, не какое-то ноу-хау Банка «Санкт-Петербург». Она внедрена в большинстве крупных финансовых организаций, но её логика, внутренние фичи и технологический стек разнятся в зависимости от уникальных идей команды, работающей над ней.
Кредитный конвейер — это полностью автоматизированный процесс принятия решений по всем видам кредитов с возможностью создавать достаточно сложные логические цепочки, чтобы повышать уровень одобрения кредитов при минимизации рисков. В нашем случае машинного обучения внутри кредитного конвейера нет. В его основе лежит импликация — логика «если…, то…». Машина получает клиентскую заявку, затем обращается за информацией в Бюро кредитных историй и другие внешние сервисы, поставляющие данные о заемщиках, анализирует и, в зависимости от риск-стратегии банка, одобряет или не одобряет кредит.
Кредитный конвейер — это инструмент, благодаря которому можно не только отказаться от ручного труда, повысить доходность кредитных продуктов, но и увеличить скорость принятия решений и улучшить клиентский опыт.
Прежний конвейер был построен на базе Microsoft Dynamics CRM. То есть СРМ-система выполняла нетипичную для себя роль. На ПО для управления взаимоотношениями с клиентами нанизывалась логика принятия решения по кредитным заявкам. Если с простыми алгоритмами она справлялась, то, когда у Банка появились идеи, как улучшить процесс кредитования, как сделать новые продукты, оказалось, что мы упираемся в потолок возможностей этой системы. Невозможно было поддержать сложную логику или построить скоринговые модели с большим количеством факторов. Работала прежняя система (по сегодняшним стандартам) довольно медленно: скорость принятия решения исчислялась десятками минут. И кроме того, потихоньку технологически устаревала.
Поэтому было принято решение о переносе кредитного конвейера на новые рельсы. Банку нужна была новая платформа, чтобы иметь возможность реализовывать любые идеи бизнеса, которые могут принести доход, и соответствовать требованиям регулятора, которые с каждым годом усложняются. Новый кредитный конвейер Банка «Санкт-Петербург» построен на базе трех IT-платформ. Движение кредитной заявки полностью реализовано на low-code платформе WF Core, которая является самостоятельной разработкой российской компании CSBI. Решение SAS RTDM (SAS Real-Time Decision Manager) по факту стало мировым стандартом в области принятия решений, поэтому для реализации сложной логики принятия решения по кредитам и построения стратегий (алгоритмов кредитного процесса) была выбрана именно эта система. И, наконец, АБС «ЦФТ-Банк», в которой, собственно, и выдается сам кредит и ведется учет. Для онлайн-кредитования у нас подключается интернет-банк и мобильное приложение. Компоненты системы мы связали между собой шиной IBM.
Для реализации этого сложного проекта, помимо сотрудников Банка, были приглашены компании CSBI и GlowByte. Компания GlowByte давно зарекомендовала себя на рынке как передовой партнер по внедрению программного обеспечения, включая продукты компании SAS. Компания CSBI в этом проекте отвечала за комплексную автоматизацию кредитного процесса и за разработку пользовательских интерфейсов на базе платформы WFCore. Партнером также выступила компания «Неофлекс», отвечавшая за внедрение шины.
Платформа WF Core — яркий представитель low-code. Если no-code — это вообще конструктор (например, для создания сайтов), с которым разберется практически любой человек, то low-code подход заключается в том, что используется набор готовых инструментов, позволяющих реализовать сложную логику, быстро модифицировать, улучшать и расширять работу с бизнес-процессами и аналитикой. Нас это заинтересовало, поскольку с WF Core мы получали возможность гибко настраивать процессы, бизнес-логику и пользовательские интерфейсы с минимальным участием программистов. Кроме того, WF Core в нашем банке уже использовали для замены старого CRM. А любой бизнес старается минимизировать «зоопарк» программного обеспечения, чтобы не раздувать штат обслуживающих его специалистов.
Создание кредитных конвейеров на базе интеллектуальных систем принятия решений SAS, и в частности – SAS RTDM, уже стало на рынке лучшей практикой, причем для самых разных кредитных продуктов. SAS RTDM с использованием методов глубокой аналитики помогает быстро и точно рассчитать любые индивидуальные предложения с учетом целей маркетинга и рисковой политики. С ним мы получали еще большую гибкость в работе с клиентами: возможность предложить альтернативные варианты размера, срока и ставки кредита. С учетом желания Банка повышать технологичность процессов розничного банкинга и оптимизировать процессы управления кредитными рисками этот выбор был самым подходящим.
Во многом команда проекта в Банке стала первопроходцем. Именно с ее помощью Банк получил бесценный опыт запуска и ведения сложных технологических проектов с одновременным внедрением нескольких платформ и участием нескольких подрядчиков. Когда запускался новый кредитный конвейер, архитекторов в Банке не было в принципе. Архитектурой занимались опытные сотрудники и руководители IT-подразделений, которые обладали компетенцией в этом вопросе. Они и составляли Архитектурный совет. Глобально архитектуру мы проработали и утвердили на Архитектурном совете, а конкретные точечные вопросы решали с теми людьми, которые могли дать свои рекомендации. И это был первый вызов. Потому что смотреть на задачу глобально и разбираться в деталях – это, как говорится, две большие разницы. Истина рождалась в жарких межплатформенных спорах. Зато теперь, во многом благодаря проекту, в Банке есть выделенные архитекторы платформ, что заметно облегчает жизнь нашим последователям. Но первый урок, который мы вынесли, если решение многоплатформенное, должен быть архитектурный надзор на всем ходе проекта. А у команды должен быть в доступе ресурс архитекторов для решения сложных вопросов из серии: «а эту функциональность лучше запилить на этой платформе или на той?». Далеко не всегда это очевидно.
Проект мы вели по всем правилам. До старта был проведен предпроект с выработкой требований к будущей системе, оценена целесообразность и экономический эффект. Одна беда – мы наивно полагали, что вся основная нагрузка ляжет на систему принятия решений, то есть на SAS RTDM. Поэтому и предпроект был ориентирован в основном на нее. Как показала практика, в межплатформенных проектах недальновидно надеяться на то, что изменения одной системы не затронут другую. А уж тем более внедрение новой системы. Урок номер два – в предпроект или аналитическую фазу проекта вовлекай активно все участвующие стороны. На эти грабли мы, кстати, умудрились наступить дважды. Второй раз — когда не смогли подключить действующее решение в онлайн-каналах (интернет-банк и мобильный банк) к новому кредитному конвейеру без доработок. К аналитике мы коллег не привлекали, а потом оказалось, что процессы подачи заявки в онлайне и оффлайне кардинально отличаются. Причем не только по клиентским сценариям, но и по атрибутному составу тоже. Отсюда еще одно правило: если проектируемая система затрагивает разные каналы входа: онлайн (интернет-банк, мобильное приложение, сайт) и оффлайн (офисы), то даже если они реализуются поэтапно, в аналитике надо прорабатывать сразу все. Иначе какую-то работу придется проделать дважды, а что-то даже кардинально переделать.
Урок номер три. Если решение многоплатформенное, то возникает интеграция. Интеграция = всегда что-то пойдет не так. Требуется закладываться на риски по деньгам и срокам. Финансисты – люди прижимистые, бюджеты верстаются с ювелирной точностью. А когда опыта в подобного рода сложных технологических проектах немного, то точность получается не совсем ювелирная. В общем, конечно же, много что пошло не так (на первых этапах — примерно всё). И вроде бы это аксиома управления проектами – учитывать риски, но пока сам не ошибешься и не набьешь шишки, вся эта теория в практику переходить не спешит.
Интересных и поучительных моментов в проекте было еще очень много. Но мы со всеми вызовами достойно справились. Во многом потому, что, как минимум, самого главного принципа реализации крупных проектов и модного нынче Agile-подхода мы придерживались: главное – люди. Команда сложилась сильная, сплоченная, прорывная, готовая к изменениям. И это помогло довести все идеи до реализации, создать отличный работающий продукт.
Сейчас над кредитным конвейером тоже трудится большая кросс-функциональная команда: это банковские аналитики, разработчики, тестировщики, администраторы платформ, риск-менеджеры и продуктовики. Кто-то из них участвовал во внедрении, другие подключились уже позже. Поскольку жизненный цикл проекта достаточно длинный, команда меняется по составу, но основной костяк сохраняется, включая и ряд подрядчиков. Например, GlowByte реализует необходимые для сервиса доработки по SAS RTDM. CSBI продолжает помогать Банку развивать WF Core. Тогда как, компетенция «Неофлекс», которая помогала нам запустить интеграционную шину, в полном объеме нам больше не требуется. Сейчас её специалисты занимаются сложными вопросами поддержки.
Внедрение основной части конвейера заняло один год. В мае прошлого года в нашем Банке началась промышленная эксплуатация нового кредитного конвейера, а уже к сентябрю старый конвейер был полностью отключен.
На сегодняшний день вся проделанная работа в промышленной эксплуатации показывает себя успешно. Автоматизация рассмотрения кредитных заявок внедрена по основным направлениям кредитования Банка: потребительские кредиты, кредитные карты, кредиты на покупку автомобиля. Завершаем внедрение ипотеки. Самое важное — у нас сейчас нет предела полета фантазии. Теперь мы можем реализовать практически любую идею, которая зарождается в головах владельцев продуктов. Если мы в нее верим, и экономически она тоже интересна, нововведение будет реализовано благодаря гибкости новой платформы.
На новых технологиях мы смогли реализовать сложную логику, когда машина подбирает для клиента максимально релевантное предложение, которое формируется в зависимости от его профиля, долговой нагрузки и желаний. Мы также реализовали стратегии изменения и пролонгации кредитных лимитов. Это позволяет эффективно управлять портфелем кредитных карт. Стратегий несколько для разных вариантов клиентского опыта, они работают на постоянной основе в полностью автоматическом режиме.
Новая логика и технологический стек значительно увеличили скорость принятия решения. Если в старом конвейере скорость принятия решения исчислялась десятками минут, то в новом — около одной минуты. При этом в принятии решения теперь задействованы дополнительные информационные источники для более точного расчета кредитного риска и оценки платежеспособности потенциальных заемщиков.
Использование глубокого анализа риск-профилей потенциальных заемщиков дает возможность сократить количество «плохих» кредитов.Скорость принятия решений позволяет клиенту в онлайне получить кредит в рамках одной сессии. Автоматизация практически исключила необходимость вовлечения андеррайтеров. По потребительским кредитам зарплатным клиентам более 90% решений сегодня принимается полностью автоматически. Всё это положительно влияет на конверсию, на уровень одобрения и, с другой стороны, — на качество принимаемых решений.
Кредитный конвейер работает в разы быстрее человека и может обработать гораздо большее количество заявок, чем штат персонала, который может позволить себе Банк. Рассмотрение одной заявки становится гораздо дешевле. В нашем автоматизированном процессе в типовых случаях человек не привносит в процесс принятия решения по кредиту дополнительной ценности. Только в случае нестандартных заявок, очень крупных сумм или при сработавших в процессе триггерах мы подключаем андеррайтера. Он составляет более полное представление о клиенте, тщательно изучает документы клиента, проводит дополнительные проверки. Тем самым мы лучше понимаем профиль клиента и принимаем более взвешенное решение. Но доля таких заявок невелика, и она с каждым годом уменьшается, потому что всё больше вещей, которые делает человек, мы можем заложить в логику машины.
Из Roadmap по внедрению нового кредитного конвейера командой Банка «Санкт-Петербург» в этом году решено больше 100 задач. Полученный эффект полностью оправдал внедрение нового кредитного конвейера и окупил его с лихвой. Завершаем 2021-й переносом на новый конвейер направления ипотечного кредитования.
Многие финансовые организации используют SAS RTDM для автоматизации принятия решения, но дальше все зависит от идей, которые команда заложит в систему.
Одна из реализованных идей, которыми мы гордимся, это подбор предложения при отказе клиенту в запрошенном продукте. В нашем кредитном конвейере реализована сложная логика с предложением рефинансирования при высокой закредитованности клиента.
Например, вы хотите взять миллион рублей, но проанализировав вашу историю, машина понимает, что не может одобрить вам эту сумму из-за большого объема кредитов, открытых вами в других банках. Дохода на обслуживание обязательств недостаточно. Но дополнительный анализ показывает, что вам можно предложить снизить долговую нагрузку путем консолидации всех имеющихся долгов в один по выгодной ставке. Тогда мы можем сказать клиенту: «к сожалению, мы вынуждены отказать в запрошенном кредите, но вот вам одобренное решение на рефинансирование ваших кредитов». Это одна из тех идей, которые невозможно было реализовать на старом кредитном конвейере. Мы дали ей жизнь на новом, и она пользуется большим успехом у клиентов.
Мы создали работающую инфраструктуру, которую можно развивать. На следующий год у кросс-функциональной команды запланирована непрерывная работа по улучшению. Мы готовимся выполнять новые требования ЦБ, а также больше времени посвятить клиентскому опыту, сценариям поведения клиента в интернет-банке, упрощению взаимодействия с интернет-банком, чтобы клиент прилагал минимальное количество усилий для получения кредита. Также в 2022 году мы хотим реализовать систему предодобренных кредитов, которая в банке существует, но живет по старой логике, на стеке технологий, который уже не позволяет показать высокую эффективность.
Автор статьи
Читайте также:
- Автокредит кто владелец автомобиля
- Можно ли пенсионера признать банкротом по кредиту
- Почему банки предварительно одобряют кредит а потом отказывают
- Ипотечный кредит может быть предоставлен для покупки строящегося жилья без предоставления залога
- Доходы в виде процентов полученных по договорам займа кредита банковского счета банковского вклада
- Денежные переводы
