Привет, меня зовут Александр Зараменских, я менеджер разработки Центра внедрения информационно-технологических решений в Уральском банке реконструкции и развития (УБРиР). Хочу поделиться историей внедрения системы автоматизации скоринга в нашем банке.

Страшные реалии прошлых лет

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

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

Сейчас эти истории используются исключительно как котолампа. Я же расскажу, что изменилось за это время и как технологии помогают узнать о нас быстрее и больше.  

С чего все начиналось

Главный источник информации о клиенте – это сам клиент и та информация, которую он предоставляет банку при заполнении анкеты. Банк проверяет информацию и выносит решение на основе проверенных данных. Что проверяет банк? Доход, стаж работы, паспортные данные и дисциплину клиента. Тут же ещё платежная дисциплина клиента по ранее выданным займам и кредитам, частота займов и своевременности внесения платежей, и в помощь приходит Бюро Кредитных Историй (БКИ), в которое все банки обязаны отчитываться по каждому выданному займу или кредиту. Иными словами это база данных кредитных договоров и клиентов с их историями погашений и информацией о возможных допущенных просрочках и платежах. 

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

Внедрение автоматизации скоринга: первая стадия

Автоматизация тут – ключевое слово, банки делают ставки на автоматизацию скоринга. Первой стадией автоматизации в УБРиР стала система расчета на хранимых процедурах с использованием вручную составленных справочников и взаимодействия пары внутренних учетных банковских систем. Во фронт-систему SAP CRM вносились анкетные данных клиента, и на следующем этапе запускался расчет условий и проверка негатива уже на другой БД Oracle, посредством соединения баз данных DB-link. Время работы процедур на Oracle оставляло желать лучшего из-за большого количества обрабатываемой информации и создаваемой нагрузки при работе через DB-link. Отказаустойчивость тоже была на опасно невысоком уровне из-за монолитной связки этих систем.

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

Внедрение автоматизации скоринга: вторая стадия

Вторая стадия развития автоматизации скоринга затронула внешние источники информации о клиентах – сервисы. Сервисы делают свои скоринг модели на основе BIG DATA. Например, это могут быть данные от мобильных операторов – траты на связь или использование роуминга. Также используются данные различных сервисов, например, агрегаторов такси или сервисов доставки. Может анализироваться, как часто человек пользуется ими, какая средняя сумма покупки и какая у клиента банковская карта и, чем дальше, тем больше узнают о нашей жизни и привычках. Чем больше их становилось, тем востребованнее стали универсальные адаптеры – агрегирующие в себе наборы разных сервисов с абсолютно разными форматами обмена. 

Это позволяло потребителю, в нашем случае банку, не подстраиваться под каждый отдельный сервис. Проблем не было, пока сервисы не стали исчисляться десятками, и обработка данных превратилась в длительную процедуру. Время тратилось на процесс разработки, доработки и сопровождения этих сервисов, в каждом из которых своя логика и форматы. Нужна была программа, чтобы получать от сервисов разнообразных форматов, к примеру json, единый XML. Такой системой у нас стала программа Credit Registry, где были сразу собраны все БКИ и другие важные сервисы, такие как скоринги мобильных операторов. Но кроме этой системы данный подход потребовал оркестрацию процессов интеграции и шину обмена данными, в нашем случае эти вопросы закрыла система SAP PI, использующая протокол SOAP и XML сообщения. Весь этап с учетом написания всей документации и реализации занял порядка 4 месяцев.

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

Системы принятия решений

При росте бизнеса и количества клиентов, изменчивости рынка и других факторов настало время для Систем принятия решений, в которых упор сделан на скорость обработки данных, полученных как от клиента, так и от всех источников внутри банка и сервисов. В нашем случае выбор был сделан в пользу  системы SAS RTDM, которая мы интегрировали со всеми фронтовыми системами (на всякий случай упомяну, что фронт банка – это офисы работы с клиентами, а не фронтенд) банка. 

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

Дополнительными преимуществами стали: 

• возможность деплоя изменений встроенным инструментом CI/CD - это позволило сделать расширенные сервисные окна для установки изменений из-за отсутствия влияния на другие системы;

• настройка параметров стратегии: теперь она заключалась не в изменении справочников и доработках хранимок на ORACLE, а проводилась риск-аналитиками в понятном интерфейсе. 

Всё это сократило время на разработку и внедрение стратегии принятия решения, дало возможность работать с интуитивно понятным графическим интерфейсом пользователя. В результате риск-аналитики смогли визуально проектировать процесс принятия решений вместо того, чтобы программировать. Сами процессы формировались из набора многократно используемых стандартных задач, необходимо только перетащить их в область проектирования в окне программы с использованием технологии drag-and-drop:

1. Слева  – элементы интерфейса;

2. Справа – рабочая зона, где выстраивается последовательность проверок и набора действий, которые необходимо выполнить по тому или иному клиенту.

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

Как мы вставали на эти рельсы

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

Данные события совпали с трансформацией подхода к разработке в организации в целом, с применением методологии Agile. Этот факт позитивно сказался на производственном процессе, так как риск-аналитики и  разработчики были в одной команде. Мы смогли  выстроить конвейер поставок доработок, избегая простоев и ожиданий. 

Избавление от кошмаров

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

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

К чему сейчас стремятся банки?

Еще до коронавируса многие сервисы стали уходить в онлайн, но появление вируса сделало рывок в этом направлении, отправив нас на дистант. Сейчас сделан прицел на удобстве предоставления услуг клиентам «не выходя из дома», и это же касается кредитования. Теперь одобрение по заявке в Интернет-банках и Мобильном приложении также можно получить всего за несколько кликов. При этом не нужно заполнять больших бумажных и даже электронных анкет.