ВКР. Горынин ВКР 2022. Исследование и анализ объекта автоматизации 4 1 Описание предприятия 4

• Название: Исследование и анализ объекта автоматизации 4 1 Описание предприятия 4
• Дата: 05.07.2022
• Размер: 6.55 Mb.
• Имя файла: Горынин ВКР 2022.docx
• Тип: Исследование; #624999
• страница: 5 из 11

2.2 Описание реализованной доработки по процессу подбора финансового продукта

После реализации доработок экран администратора получил следующий вид.
После реализации доработки у администратора появился удобный интерфейс для добавления банков в систему. Вид списка банков выглядит следующим образом:


Каждому банку администратор может добавлять продукты. Экран управления продуктами банка выглядит следующим образом:


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

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

2.3 Описание процесса предварительного рассмотрения заявки

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

В настоящий момент, оператор кол-центра, получая заявку в работу выполняет следующие действия:

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

Пример табличной формы, выгружаемой из системы, в которой оператор получает информацию о скоринг-балле клиента.

К недостаткам текущего решения можно отнести:

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

2.4 Требования к процессу скоринга заявки

Для реализации нового механизма скоринга заявки был выбран механизм асинхронной REST API интеграции с сервисом оценки заемщика банка ПСБ.

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

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

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

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



Для поиска позитивного опыта были выделены следующие критерии:

• 
  Банк обладает кредитным портфелем более в 1 трлн рублей
  
• 
  Банк наращивает кредитный портфель путем выдачи новых кредитов, а не покупки кредитного портфеля у остальных организаций
  
• 
  Кредитный портфель банка имеет тендецию к росту
  

Отсортировав первые 15 банков по убыванию кредитного портфеля, была получена следующая поисковая выдача.

№	Название	Февраль 2022, тыс	Февраль 2021, тыс	Изменение г/г
1	СберБанк	27 246 939 295	23 090 989 912	4 155 949 383
2	ВТБ	11 819 101 275	10 693 117 100	[phone]
3	Газпромбанк	5 786 245 247	4 949 714 223	[phone]
4	Альфа-Банк	3 905 649 652	3 095 210 312	[phone]
5	Россельхозбанк	2 931 610 624	2 805 607 832	[phone]
6	Московский Кредитный Банк	2 689 770 535	2 335 267 794	[phone]
7	Банк Открытие	1 981 656 341	1 692 784 179	[phone]
9	Совкомбанк	1 347 786 482	723 268 486	[phone]
10	Райффайзенбанк	1 032 574 329	823 130 714	[phone]
11	Траст	942 988 238	1 014 796 642	−71 808 404
12	Росбанк	937 217 486	695 342 938	[phone]
13	ЮниКредит Банк	644 405 863	653 258 418	−8 852 555
14	Тинькофф Банк	638 579 705	417 354 628	[phone]
15	Банк ДОМ.РФ	617 088 275	385 293 060	[phone]

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

Рейтинговое агентство «Эксперт РА» подтвердило рейтинг АО Райффайзенбанк на уровне ruAAA. Как сказано в отчете, около 57% активов банка приходится на кредитный портфель, состоящий на 62% из задолженности ЮЛ и ИП, а 38% представлено кредитами ФЛ (приблизительно в равных пропорциях ипотечные кредиты и необеспеченные потребительские кредиты).

Кредитный портфель имеет высокое качество (в кредитах ЮЛ и ИП доля stage 3 и POCI по МСФО на 01.01.21 составила – 2,7%, в розничном портфеле – 4,7%). Агентство отмечает низкую концентрацию на объектах крупного кредитного риска (крупные кредитные риски составляли менее 17% чистых активов на 01.01.21) и высокую диверсификацию корпоративного кредитного портфеля по отраслям хозяйственной деятельности.

Для проведения дальнейшего исследования попробуем оценить количество минимальное количество входящих заявок. Ранее Райффайзенбанк сообщал, что в июне 2021 года выдал более 12,79 млрд рублей потребительских кредитов. Это рекордный объём месячной выдачи за все время работы банка на российском рынке. Средний чек одного займа составляет более 650 тыс. руб.

Из публикаций Райффайзенбанка следует, что в 2021 году банк трижды ставил личный рекорд по количеству выданных кредитов в месяц. Первый такой рекорд был зафиксирован в июне. Разделив совокупный объем кредитования на средний чек, можно подсчитать, что за месяц банком было выдано около 19 000 кредитов.


По данным с сайта banki.ru средняя конверсия для банков из заявки на кредит в выдачу составляет от 5 до 9 процентов в зависимости от канала поступления. Инфографику от портала по каналам продаж в банковском секторе можно изучить по изображению.



Таким образом, мы можем сделать вывод, что Райффайзенбанк получает около 200 000 заявок на кредиты в месяц.

Таким образом наихудший гарантированно позитивный опыт на рынке был осуществлен на потоке в 600 000 заявок за квартал.

Система GOSOBLAKO ежемесячно обрабатывает до 24 000 тысяч заявок, что эквивалентно 72 000 заявок в квартал. Поскольку альтернативным решением является интеграция с готовой банковской системой принятия решений, а доля GOSOBLAKO в трафике банка ПСБ составляет не более 40%, следует отдать предпочтение банковской системе.

Кроме указанного выше обоснования, преимуществами интеграционного решения над реализацией скорингового механизма на стороне партнера банка является:

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

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

Таким образом, решение было реализовано с применением следующих технологий:

• 
  Серверная часть (бэкенд) – PHP на фреймворке Yii
  
• 
  Серверная часть (база данныз) – Postgres
  
• 
  Клиентская часть (фронтэнд) – TypeScript (Angular)
  

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

• 
  Создание заявки
  
• 
  Ручная проверка клиента
  
• 
  Звонок клиенту для проверки данных и назначения встречи
  
• 
  Встреча с клиентом
  
• 
  Выпуск продукта
  

Далее были выбраны точки процесса для добавления в них обращения к системе оценки рисков:

Точка процесса	Обоснование необходимости
Перед звонком клиенту	В настоящий момент на этапе звонка клиенту оператор предварительно проверяет качество заемщика и отклоняет заявку в случае невозможности выдать ему банковский продукт. После внедрения доработки заявка не будет назначаться на оператора кол-центра, а будет отклоняться автоматически в случае получения соответствующего решения.  Приемуществами выполнения запроса на этом этапе являются: 1) Обспечение ранего отказа клиенту 2) Уменьшение времени операции звонка клиенту, а следовательно и нагрузки на кол-центр
Перед встречей с курьером	На этапе звонку клиенту одной из задач оператора является проверка корректности введеных данных. В случае обнаружения ошибки, оператор исправит данные, что может повлиять на итоговое решение по заявке. В настоящий момент, такие заявки отказываются непосредственно в процессе открытия продукта, что влечет за собой потерю ресурсов на процессинг и клиентский негатив.
Перед выпуском кредитного продукта	Встреча с курьером происходит часто не в день звонка, а иногда между звонком и встречей курьера может проходить до 25 дней.  За 25 дней качество клиента может измениться, а также может закончится квартал, в котором производилась оценка клиента. Поэтому перед зачислением необходимо дополнительно проверить качество клиента и изменить стратегию процессинга в случае необходимости.

Модель TOBE будет выглядеть следующим образом:


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

1. 
   Новый сервис dlpi-rde выполняет запрос в базу данных системы, получает данные о заявке
   
2. 
   Новый сервис dlpi-rde отправляет REST-MQ запрос в контур банка
   
3. 
   Запрос проксируется и проходит Firewall контура банка
   
4. 
   Адаптер сервиса, разработанный банком для интеграции с системой Gosoblako, выполняет запрос в канонический сервис
   
5. 
   Сервис dlpi-rde опрашивает сервис банка на наличие ответа по заранее сгенерированному id запроса
   
6. 
   Адаптер сервиса, разработанный банком для интеграции с системой Gosoblako, адаптирует ответ под контракт и возвращает его
   

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

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

Алгоритм поиска моратория.

Входные параметры для процедуры поиска моратория:

Атрибут	Столбец	Тип	Описание	*
creditType	CREDTYPEID	Integer	Тип кредита	Да
borower.ID	CIF	String	Идентификатор клиента	Нет
borower.INN	CNUM	String	ИНН клиента	Нет
founder[].birthDate	BIRTH_DATE	Date	Дата рождения учредителя	Да
founder[].nameRus.firstName	FIRST_NAME	String	Имя	Да
founder[].nameRus.lastName	LAST_NAME	String	Фамилия	Да
founder[].nameRus.middleName	MIDDLE_NAME	String	Отчество	Да
founder[].previousName.firstName	FIRST_NAME	String	Предыдущее имя	Нет
founder[].previousName.lastName	LAST_NAME	String	Предыдущая фамилия	Нет
founder[].previousName.middleName	LAST_NAME	String	Предыдущее отчество	Нет
founder[].passport.number	PASSPORT_NUMBER	String	Номер паспорта	Да
founder[].passport.serie	PASSPORT_SERIE	String	Серия паспорта	Да

Шаг 1 (поиск по ИНН) 

Осуществляется поиск записи в таблице MORATORIUM удовлетворяющий всем следующим критериям:

1. 
   Значение входного параметра borrower.INNравно значению из поля INN таблицы MORATORIUM.
   
2. 
   Значение из поля CREDTYPEID таблицы MORATORIUM равно 1.
   
3. 
   Текущая дата меньше даты из поля MORATORIUM_EXPIRATION_DATE таблицы MORATORIUM.
   
4. 
   Поле CANCEL_DATE таблицы MORATORIUM не заполнено (пустое).
   

Если мораторий найден, то поиск заканчивается, переходим на Шаг 6. Иначе переходим на Шаг 2.

Шаг 2 (поиск по id)

Осуществляется поиск записи в таблице MORATORIUM удовлетворяющий всем следующим критериям:

1. 
   Значение входного параметра borrower.idравно значению из поля idтаблицы MORATORIUM.
   
2. 
   Значение из поля CREDTYPEID таблицы MORATORIUM равно 1.
   
3. 
   Текущая дата меньше даты из поля MORATORIUM_EXPIRATION_DATE таблицы MORATORIUM.
   
4. 
   Поле CANCEL_DATE таблицы MORATORIUM не заполнено (пустое).
   

Если мораторий найден, то поиск заканчивается, переходим на Шаг 6. Иначе переходим на Шаг 3.

Шаг 3 (поиск по серии и номеру паспорта)

Осуществляется поиск записи в таблице MORATORIUM удовлетворяющий всем следующим критериям:

1. 
   Значение входного параметра каждого элемента массива founder[].passport.number равно значению из поля PASSPORT_NUMBER таблицы MORATORIUM.
   
2. 
   Значение входного параметра каждого элемента массива founder[].passport.serie равно значению из поля PASSPORT_SERIE таблицы MORATORIUM.
   
3. 
   Значение из поля CREDTYPEID таблицы MORATORIUM равно 1.
   
4. 
   Текущая дата меньше даты из поля MORATORIUM_EXPIRATION_DATE таблицы MORATORIUM.
   
5. 
   Поле CANCEL_DATE таблицы MORATORIUM не заполнено (пустое).
   

Если мораторий найден, то поиск заканчивается, переходим на Шаг 6. Иначе переходим на Шаг 4.

Шаг 4 (поиск по ФИО и дате рождения)

Осуществляется поиск записи в таблице MORATORIUM удовлетворяющий всем следующим критериям:

1. 
   Значение входного параметра каждого элемента массива founder[].nameRus.firstName равно значению из поля FIRST_NAME таблицы MORATORIUM.
   
2. 
   Значение входного параметра каждого элемента массива founder[].nameRus.lastName равно значению из поля LAST_NAME таблицы MORATORIUM.
   
3. 
   Значение входного параметра каждого элемента массива founder[].nameRus.middleName равно значению из поля MIDDLE_NAME таблицы MORATORIUM.
   
4. 
   Значение входного параметра каждого элемента массива founder[].birthDate равно значению из поля BIRTH_DATE таблицы MORATORIUM.
   
5. 
   Значение из поля CREDTYPEID таблицы MORATORIUM равно 1.
   
6. 
   Текущая дата меньше даты из поля MORATORIUM_EXPIRATION_DATE таблицы MORATORIUM.
   
7. 
   Поле CANCEL_DATE таблицы MORATORIUM не заполнено (пустое).
   

Если мораторий найден, то поиск заканчивается, переходим на Шаг 6. Иначе переходим на Шаг 5.

Шаг 5 (поиск по предыдущим ФИО и дате рождения)

Если указаны предыдущие ФИО (previousName), то осуществляется поиск, удовлетворяющий всем следующим критериям:

1. 
   Значение входного параметра каждого элемента массива founder[].previousName.firstName равно значению из поля FIRST_NAMEтаблицы MORATORIUM.
   
2. 
   Значение входного параметра каждого элемента массива founder[].previousName.lastName равно значению из поля LAST_NAME таблицы MORATORIUM.
   
3. 
   Значение входного параметра каждого элемента массива founder[].previousName.middleName равно значению из поля MIDDLE_NAME таблицы MORATORIUM.
   
4. 
   Значение входного параметра каждого элемента массива founder[].birthDate равно значению из поля BIRTH_DATE таблицы MORATORIUM.
   
5. 
   Значение из поля CREDTYPEID таблицы MORATORIUM равно 1.
   
6. 
   Текущая дата меньше даты из поля MORATORIUM_EXPIRATION_DATE таблицы MORATORIUM.
   
7. 
   Поле CANCEL_DATE таблицы MORATORIUM не заполнено (пустое).
   

Замечание. Если НЕ указаны предыдущие ФИО, то Шаг 5 пропускается, переходим на Шаг 6.

Шаг 6 (определение причин отказа, по которым выставлен мораторий)

Если мораторий не найден, то процесс по поиску моратория заканчивается.

Также в системе потребуется реализовать следующий алгоритм постановки моратория на клиента:

Предварительные условия выставления моратория

1. 
   Решение по заявке отрицательное (application.decision.value=2)
   

Процесс выставления моратория

1. 
   Проверка, заполнен ли параметр в моделе application.reasonRejection.name
   
   1. 
      Параметр application.reasonRejection.name заполнен
      
      1. 
         Поиск application.reasonRejection.name в справочнике Reason_rejection в поле REJ_REASON
         
   2. 
      Параметр application.reasonRejection.name не заполнен
      
      1. 
         Длякаждого из парамтеров cdsResponse.decisionInfo1.value, ...,  cdaResponse.decisionInfo10.value поиск в справочнике Reason_rejection в поле REJ_REASON
         
2. 
   Определение срока моратория (Period)
   
   1. 
      По всем найденным REJ_REASON в справочнике Reason_rejection находим наибольшее значение в поле MORATORIUM_TERM
      
   2. 
      Если Period = 0, то мораторий не выставляется, процесс заканчивается
      
3. 
   Определение даты истечения моратория (Expiration date)
   
   1. 
      Expiration date = Текущая дата + <количество месяцев, равное Period>
      
      1. 
         Пример: Текущая дата 05.08.2021, Period=4 => Дата истечения моратория = 05.12.2021.
         
   2. 
      Если в месяце не хватает дней после прибавления Period, то Expiration date будет определяться последним днем месяца
      
      1. 
         Пример: Текущая дата равна 31.10.2021, Period=4 => Дата истечения моратория = 28.02.2022.
         
4. 
   Сохранение информации о моратории и его причинах в справочники Moratorium и Moratorium_rej_reason_map
   

Маппинг на справочники выглядит следующим образом:

Параметр в модели DLPI	Допускает пустые значения	Поле в справочнике Moratorium
<Автоматически сгенерированный идентификатор записи>	No	MORATORIUM_ID
applicationData.dlpiApplication.borrower.CNUM	Yes	CNUM
applicationData.dlpiApplication.borrower.CIFID	Yes	CIF
applicationData.dlpiApplication.borrower.nameRus.firstName	No	FIRST_NAME
applicationData.dlpiApplication.borrower.nameRus.lastName	No	LAST_NAME
applicationData.dlpiApplication.borrower.nameRus.middleName	No	MIDDLE_NAME
applicationData.dlpiApplication.borrower.birthDate	No	BIRTH_DATE
<Текущая дата>	No	MORATORIUM_CREATION_DATE
	No	MORATORIUM_EXPIRATION_DATE
applicationData.id	No	APPNUMBER
<Константа "1">	No	CREDTYPEID
applicationData.dlpiApplication.borrower.passport.serie	No	PASSPORT_SERIE
applicationData.dlpiApplication.borrower.passport.number	No	PASSPORT_NUMBER

Проверка наличия моратория осуществляется в соответствии с решением, описанным в пунтке 2.4.

В финальном представлении решение на первом вызове выглядело так:


Как видно, исходя из диаграммы, в случае наличия в базе данных конвейера информации о моратории (ранее полученных отказов) REST запрос не выполняется, и заявка отклоняется.

Последовательность вызовов сервисов на последующих этапах жизненного цикла заявки приведена на диаграмме последовательности ниже.

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

1. 
   На этапе вызова метода /start-process заявка принимается в работу оператором и выполняются экспресс-проверки
   
2. 
   Далее оператор может изменить какие-то из полей анкеты в процессе разговора с клиентом. Вся новая информация будет занесена в заявку путем вызова метода PUT /application/{id}
   
3. 
   Когда модель данных заявки обновлена следует выполнить обращение к сервису RDE (сервис принятия решения в контуре банка), для этого конвейер использует микросервис интеграции
   
4. 
   В ответе рискового сервиса содержится необходимая информация для повторного расчета предложений, которые осуществляется на вызове /recalculate-all-offers
   
5. 
   На этапе вызова /finish-application данные сохраняются в модель, а заявка отправляется дальне по бизнесс-процессу