Запрос на предложение по реализации Кредитного конвейера для ВТБ24 Оглавление Оглавление 21.Общие положения 51.1. Термины и сокращения 51.2. Введение 71.3. Ограничение ответственности 71.4. Цели и рамки внедрения 72.Общая информация о Банке 72.1. Стратегия Банка 82.2. Планируемый объем бизнеса 82.3. Информация об используемых Банком системах 92.4. Функциональная архитектура данных 92.5. Состав Кредитного Конвейера в разрезе выполняемых функций. 102.6. Описание запроса 113.Кредитный конвейер. Функциональные требования 143.1. Общие функциональные требования 143.2. Этапы системы и их настройка 143.2.1.Этапы 143.2.2.Настройка стратегий (маршрутов) проверки 143.3. Логирование 153.4. Обогащение данных из прочих систем 153.4.1.ГСЗ 153.4.2.Работа с внешними по отношению к Кредитному Конвейеру системами 163.4.3.Взаимодействие с БКИ 163.4.4.Оценка истории (в т.ч. кредитной) внутри и вне Банка. 163.5. Обращение к внешним системам 173.5.1.Проверка заёмщиков 173.5.2.Скоринговые системы 173.6. Логические и математические процедуры в системе 183.7. Матрица принятия кредитного решения 183.8. Лимиты на кредитный риск 183.9. Нетиповые условия 193.10. Проверка моратория 193.11. Принятие кредитного решения 203.12. Определение характеристик резервирования на этапе принятия решения 203.13. Работа риск менеджера с заявкой 203.13.1.Очередь заявок 213.13.2.Формирование печатных форм 213.14. Распределение прав в Систему 213.15. Работа по залоговым рискам 223.16. Обработка некредитных заявок 234.Технологические требования 234.1. Требования к программному обеспечению 234.2. Требования к масштабируемости и гибкости 244.3. Требования к составу аппаратно-программного комплекса 244.4. Требования к производительности 254.5. Требования к обеспечению надёжности 254.6. Требования к интеграционным процессам 254.7. Требования к обеспечению безопасности 264.8. Требования к кастомизации, настройкам, инструментам развития Системы 284.9. Архивирование данных 294.10. Требования к технической поддержке 29 C 22:00 субботы до 02:00 воскресенья (время приведено по Москве). 295.Основные вопросы, которые должны быть отражены в предложении поставщика 305.1. Информация о поставщике 305.2. Обзор предлагаемого решения 315.3. Предложение по плану и команде внедрения 325.4. Консультационные услуги 335.5. Сопровождение 345.6. Условие договора 356.Вопросы по коммерческой части 356.1. Базовая стоимость 356.2. Контрольные точки и платежи 376.3. Сопровождение 376.4. Доработки и развитие системы после окончания внедрения 37 ^ Общие положения Термины и сокращения Таблица 1 - Список принятых сокращений Сокращение Комментарий ADWH Analytical Data Ware House API Application interface ATM Automated teller machine CIF Customer Information File ESB Enterprise service bus IVR Interactive Voice Response PDS Avaya Predictive Dialing System PKI Public key infrastructure АРМ Автоматизированное рабочее место АУ ДАР Аналитическое управления Департамента анализа рисков БКИ Бюро кредитных историй БКО Банк-клиент онлайн ГСЗ Группа связанных заёмщиков ДО Дополнительный офис ИП Индивидуальный предприниматель ИС Информационная система МСБ Малый и средний бизнес ПО Программное обеспечение ПОС Портфель однородных ссуд ПФ РФ Пенсионный фонд Российской Федерации РВПС Резервы на возможные потери по ссудам СПЗ Система проверки заёмщиков СРК Средство резервного копирования СУБД Система управления базами данных ТП Точка продаж УЗИ ДАР Управление по работе с залоговым имуществом Департамента анализа рисков УЛ Уполномоченное лицо ФЛ Физическое лицо ХКАИ Хранилище клиентской аналитической информации ЭФ Экранная форма ЮЛ Юридическое лицо ЮУ Юридическое управление ^ Таблица 2 - Список принятых терминов Термин Комментарий CIF Единая база карточек клиентов MDM Master Data Management NBSM Скорринговая система компании Experian NDA Non-disclosure agreement Банк Банк ВТБ24 (ЗАО) Система Кредитный конвейер (Score Engine) СПЗ Служба проверки заёмщиков Введение Настоящий документ представляет собой запрос на предложение (далее – Запрос) для поставщиков относительно их возможности поставить и внедрить программное обеспечение для реализации Кредитного конвейера.^ Ограничение ответственности Информация, содержащаяся в настоящем документе, предоставляется исключительно для возможности формулирования ответа поставщиками. Банк не предоставляет гарантий точности предоставленной информации. Банк может изменить содержание предоставленной информации по своему усмотрению; в таком случае Вы будете проинформированы о внесённых изменениях. Возложение каких-либо обязательств на Банк не может быть установлено ни содержанием настоящего документа, ни возможными ответами на него. Банк не берёт на себя никаких обязательств относительно действий в соответствии с предложениями, содержащимися в ответах. Данное ограничение ответственности действует несмотря на какие-либо представления о противоположном, обозначенные от имени Банка. Никакие расходы либо платежи не могут быть истребованы с Банка. Настоящий документ не может быть истолкован как запрос либо предоставление права на выполнение каких-либо работ или оказания услуг за счёт Банка. Любые действия, предпринимаемые поставщиком, производятся по собственному усмотрению и за свой счёт. Настоящий Запрос не представляет собой обязательства по приобретению либо аренде (лизинге) чего-либо. Отправка ответа на данный Запрос вводит в силу признание того, что поставщик ознакомлен и согласен с выполнением вышеуказанных положений.^ Цели и рамки внедрения В настоящее время существуют следующие недостатки кредитной процедуры Банка: механизм кредитной процедуры находится в АБС Бисквит, что приводит к дополнительной нагрузке на АБС Банка; счетоориентированность процесса; отсутствие срока жизни этапов заявки; трудоемкий процесс изменения кредитных карт; длительные сроки доработки функционала. Целями внедрения Кредитного конвейера (далее Система) является исправление вышеописанной ситуации.^ Общая информация о Банке Банк ВТБ 24 (ЗАО) является одним из крупнейших участников российского рынка банковских услуг, входит в международную банковскую группу ВТБ и специализируется на обслуживании физических лиц, индивидуальных предпринимателей и предприятий малого бизнеса. Сеть Банка формируют более 530 офисов в 69 регионах страны. Уставный капитал ВТБ24 составляет 50,7 млрд рублей, размер собственных средств (капитала) — 96,6 млрд рублей. Банк ВТБ 24 (ЗАО) предлагает клиентам основные банковские продукты и услуги, принятые в международной финансовой практике. Часть услуг Банка доступна клиентам в круглосуточном режиме, для чего используются телекоммуникационные технологии и дистанционные каналы банковского обслуживания. В настоящее время в Банке действую следующие каналы: Call-center; IVR; ATM; Web: Telebank (интернет банк для физических лиц); Wap: Telebank (интернет банк для физических лиц); Sms: Telebank (интернет банк для физических лиц); Web: Bank-Client-Online (банк-клиент для юридических лиц); Web: Online-broker (интернет банк для клиентов брокерского обслуживания).В 2011 году будут введены в эксплуатацию новее каналы ДБО: мобильный банк; инфо-киоски. Коллектив Банка придерживается ценностей и принципов международной банковской группы ВТБ. Одна из главных задач группы – поддержание и совершенствование развитой финансовой системы России. Деятельность Банка осуществляется в соответствии с генеральной лицензией Банка России № 1623 от 13 июля 2000 года.^ Стратегия Банка ВТБ 24 непрерывно занимается развитием системы розничного обслуживания. Это выражается в расширении линейки предоставляемых продуктов, совершенствовании удобства работы в различных каналах банковского обслуживания и переход от продажи отдельных продуктов к комплексному обслуживанию клиентов. Банк не только заинтересован в экстенсивном росте клиентской базы, но и в развитии отношений с существующими клиентами, в увеличении числа продуктов, приходящихся на одного клиента, во «взращивании» собственных высокодоходных клиентов. ^ Планируемый объем бизнеса Система должна обеспечивать поддержку следующего сценария роста объемов в разрезе доменов данных.Таблица 3 – Каталог клиентов Показатель 2011 2012 2013 Общее количество клиентов ВТБ24 (млн. ед.) 10 15 20 ^ Общее количество продуктов на одного клиента 3 5 8 Таблица 4 – Каталог продуктов Показатель 2011 2012 2013 Ориентировочное общее количество продуктов 30 40 70 ^ Таблица 5 – Общие справочники Показатель 2011 2012 2013 Общее количество справочников 400 600 900 ^ Общее количество записей в справочниках 200 000 400 000 800 000 Таблица 6 – Заявки на кредит Показатель 2010 2016 Общее количество заявок 3 500 000 9 000 000 ^ Количество заявок обрабатываемых в день ~14 000 ~40 000 ^ Информация об используемых Банком системах Перечень систем, используемых в Банке представлен в Приложении №1. Функциональная архитектура данных Функциональная архитектура представлена в Приложении №2.^ Состав Кредитного Конвейера в разрезе выполняемых функций. На Рисунок 1представлен состав Кредитного Конвейера в разрезе выполняемых функций.Рисунок 1 - Функциональный состав Кредитного Конвейера^ Описание запроса Общие положения Банк готов рассмотреть предложения поставщиков программного обеспечения и услуг по поставке и внедрению Системы, отвечающей требованиям по функциональности и техническим требованиям, указанным в настоящем документе. От поставщика требуется оказание высококвалифицированных консультационных услуг в части реализации и настройки Системы для бизнес-процессов Банка. От поставщика требуется возможность предоставления качественной поддержки, обучения и сопровождения как в ходе стадии внедрения, так и после её окончания. При этом работы по разработке, внедрению и сопровождению должны быть предложены Банку по разумной цене.График проведения конкурса Дата Событие 02.08.2011 Объявление об открытом тендере опубликовано 08.08.2011 Крайняя дата подтверждения участия поставщиками (сообщением по электронной почте) 11.08.2011 Окончание вводных встреч с участниками тендера 15.08.2011 Формирование короткого списка претендентов (шорт-листа) – не более 5 участников 18.08.2011 Подписание участниками соглашений о конфиденциальности с Банком (при отсутствии действующих договорных отношений или соглашений о конфиденциальности) 19.08.2011 Рассылка участникам анкет претендента и бизнес-кейсов для демонстраций 31.08.2011 Крайняя дата предоставления участниками заполненных анкет претендента 05.09.2011 Крайняя дата предоставления участниками коммерческих предложений 01.09.2011 – 09.09.2011 Презентации коммерческих предложений 01.09.2011 – 16.09.2011 Презентации решений с демонстрацией бизнес-кейсов и встречи по вопросам технологических требований 16.09.2011 Крайняя дата предоставления участниками резюме команд внедрения 19.09.2011 – 14.10.2011 Референс-визиты по реализованным проектам и собеседования специалистов Банка с командами внедрения 29.09.2011 – 14.10.2011 Детальные обсуждения коммерческих предложений 18.10.2011 Крайняя дата предоставления участниками финальных коммерческих предложений 20.10.2011 – 15.11.2011 Подведение итогов конкурса Контакты со стороны Банка^ Таблица 7 - Контактные лица № ФИО Должность Раб. телефон Моб. телефон Email Шаблыгин Максим Маратович Эксперт, Проект внедрения АБС 9602424 доб.5731 89688248026 Shablygin.MM@vtb24.ru Уваров Василий Александрович Руководитель проекта, Управление банковских технологий, Департамент банковских технологий 9602424 доб.5773 89636552272 Uvarov.VA@vtb24.ru Референс-визиты Участники конкурса могут организовать референс-визиты по уже реализованным проектам внедрения Системы для демонстрации решения в продуктивной среде, а так же для возможности получения отзывов пользователей: как о Системе, так и о процессе внедрения.^ Proof of Concept Участники конкурса должны представить прототип своих моделей и концепцию своего решения, построенные на данных, предоставленных Банком.Презентации На завершающем этапе конкурса участники должны провести презентации своего предложения в Банке. Целью этих презентаций является представление команде проекта со стороны Банка набора работ и услуг, предлагаемых поставщиком Банку. Во время презентации поставщик должен подробно описать, каким образом он предполагает обеспечить создание в Банке Системы, отвечающей требованиям Банка. Длительность презентаций – не более 4-х часов с учётом ответов на вопросы. Все презентации должны пройти в период с 01.09.2011-16.09.2011.На презентации должна быть представлена следующая информация: опыт аналогичных проектов; основные тезисы, на которые поставщик будет опираться при разработке моделей по данному проекту; физическая структура: развертывание компонентов по узлам сети, какие сервера и СПО на них, количество лицензий; план внедрения: этапы, цель, сроки, ресурсы; команда проекта со стороны поставщика; стоимость проекта для Банка (работы и услуги, лицензии, оборудование, поддержка) и совокупная стоимость владения системой; предложения по финансовой ответственности сторон по проекту, в частности, предложения по ответственности поставщика за сроки и результат проекта.Проводить презентацию должен предполагаемый менеджер проекта со стороны поставщика. Кредитный конвейер. Функциональные требования Общие функциональные требования Система должна предоставлять функционал настройки кредитного конвейера как процедуры принятия кредитного решения от момента формирования кредитной заявки до момента принятия окончательного решения по заявке. После выдачи заявка хранится в ADWH. Этапы системы и их настройка Этапы Заявка может проходить различные этапы обработки, включая, но не ограничиваясь: автоматические расчеты параметров кредита; автоматические проверки по внутренним и внешним базам; взаимодействие с другими программными продуктами Банка; ручные проверки; ручное принятие решения (Работа с заявкой риск менеджера); возврат заявки на доведение/корректировку данных с повторным полным или частичным прохождением процедуры принятия решения; запрос информации из внешних источников в асинхронном и синхронном режимах; повторное прохождение этапов проверки при необходимости как с прежними (сохраненными), так и с новыми параметрами; Общая схема взаимодействия этапов в Системе представлена в Приложении №3. Настройка стратегий (маршрутов) проверки Функциональность Системы должна позволять настраивать логику и последовательность переходов на уровне пользовательского интерфейса (редактор workflow). Система также должна обеспечивать следующую базовую функциональность: Версионность: возможность отслеживания изменений в стратегиях принятия решений; сохранение версии стратегии, по которой обрабатывалась заявка; повторное прохождение заявки как по старой (работавшей на момент предыдущего прохождения), так и по новой (текущей) стратегии; Вариативность: стратегия для конкретной заявки определяется по ходу выполнения этапов, т.е. есть после каждого этапа возможно ветвление и переход на этап, определённый с учётом результата, полученного на прошедших этапах; возможность продолжения стратегии без получения ответа от внешней системы и возможность повторного или первичного прохождения этапов после получения ответа от внешней системы; Настраиваемость: использование как уже реализованных модулей для создания стратегий, так и перенастроенных и созданных пользователем модулей, использование преднастроенных подпроцессов; части стратегий могут быть объединены в блоки и перенесены в другую стратегию; пользователь может настраивать сколь угодно сложные стратегии с переходами, ветвлениями и повторным прохождением частей стратегии. Распределение уровня доступа на разработку (бизнес-подразделение – риск-менеджеры), администрирование, поддержку (ИТ-специалисты), тестирование на логику работы системы (бизнес-подразделения). Возврат заявки на фронт с любого этапа. В данном случае после доввода заявка попадает в Кредитный конвейер, и он определяет путь прохождения с учётом результатов предыдущей обработки и довведённой/скорректированной информации. Переходы между этапами должны осуществляться: автоматически по заданным алгоритмам; в ручном режиме при наличии у пользователя соответствующих прав и допустимости таких переходов для данного этапа. Указанный список требований является минимально желательным. Дополнительные функциональные возможности системы, способные упростить, автоматизировать, сделать более гибкими настройку и работу кредитного конвейера, послужат дополнительным преимуществом при подведении итогов тендера. Логирование Система должна обеспечивать хранение до конечной точки обработки заявки истории следующих изменений, связей и атрибутов: изменений информации по всем параметрам кредитной заявки клиента и связям с другими объектами Системы; изменения, добавления или удаления информации по любому объекту и его атрибуту; взаимоотношений карточек клиентов с учётом времени установки и типов взаимоотношений клиентов и ролей клиентов во взаимоотношениях (ГСЗ); связей кредитной заявки клиента с различными автоматизированными системами: фронт, учётная система, электронный документооборот, ADWH и т.д. Обогащение данных из прочих систем ГСЗ Формирование группы связанных заёмщиков по определённым критериям: Тип 1 «Ближайшие родственники» – супруг/супруга, дети старше 16 лет, родители; Тип 2 «Действующий поручитель/залогодатель по действующим кредитным договорам»; Тип 3 «ЮЛ» – Учредители, генеральные директора, связанные с Заёмщиком, ЮЛ с учётом новых критериев (см. п.1); Необходимо наличие механизма создания ГСЗ и расформирования ГСЗ . Система должна рассчитывать лимит на ГСЗ, например, в соответствии со следующим правилом: "Лимит на ГСЗ = сумма обязательств Заёмщика и лиц, входящих в ГСЗ с типом связи 1, 2 или 3. Работа с внешними по отношению к Кредитному Конвейеру системами Под внешними базами следует понимать любой сторонний источник информации, с которым можно обмениваться стандартными протоколами (например, в стандартном согласованном xml-формате, формате файлового обмена). При этом пользователи с отдельной ролью (отличной от роли риск-менеджера) должны настраивать правила проверки. Взаимодействие с БКИ Система должна позволять настраивать перечень БКИ, в которые необходимо направлять запрос: в зависимости от параметров сделки; в разрезе каждого участника сделки.Система должна позволять отображать полученный результат из БКИ в виде отчёта, также все параметры ответа должны сохраняться в БД Системы.Взаимодействие с Партнёрами. Система должна позволять настраивать перечень Партнёров, в которые необходимо направлять запрос в согласованном формате.Обмен информацией посредством xml c ПО Банка.Под ПО Банка следует понимать внутренние банковские программные продукты, с которыми возможно осуществить обмен через xml или с помощью файлов обмена согласованного формата. Оценка истории (в т.ч. кредитной) внутри и вне Банка. Система должна учитывать обязательства клиента по кредитам, информация о котором получена из различных источников: БКИ; данные заявки; данные, хранящиеся в Системе, в т.ч. по заявкам, по которым принято, но не реализовано решение; АБС Банка, в т.ч. по заявкам, по которым принято, но не реализовано решение – на переходный период; данные внесистемного учета; дополнительно Система должна распознавать тип продукта и наличие признака реструктуризации; данные о депозитах; внутренняя кредитная история; данные по расчётным счетам; и т.д.; Обращение к внешним системам Проверка заёмщиков 1 Проверка ФЛ/ЮЛ осуществляется в нескольких вариантах: автоматическая проверка на минимальные требования; анализ СПЗ (анализ сотрудником) без выезда; выездная проверка2.В СПЗ должен передаваться следующий набор данных: общая информация по заявке (в т.ч. технология продажи, тип подтверждения дохода); анкетные данные по участникам сделки и участникам ГСЗ; визуальная оценка по участникам сделки; уровень необходимой проверки; данные о начислениях на з/пл карту; данные о депозитах; ссылка на хранилище документов (документы, фотографии); данные по расчётным счетам ЮЛ; данные по залогам; и т.д.Из СПЗ возвращается ответ, содержащий формализованные признаки, которые в последующем могут быть использованы в Системе при принятии итогового решения по заявке. Скоринговые системы В Системе должна быть реализована возможность встраивания скоринговых карт или вызов внешних модулей скоринга на различных этапах работы, например: оценка кредитной истории; минимальные требования; стоп-условия; прескоринг; скоринг; балльная модель; и т.д. Если реализация Скоринговых карт возможна в самой системе, то необходимо наличие следующего функционала: отслеживание версий скоринговой карты и привязка её к заявке; возможность «горячей» (т.е. без остановки работы Cистемы) замены скоринговых карт и уровней отсечения; возможность использования одной карты в различных стратегиях, т.е. при изменении карты эти изменения должны применяться для всех стратегий, где она используется. Логические и математические процедуры в системе Система должна уметь самостоятельно обрабатывать набор информации при помощи логических и математических процедур. Например, система должна обладать набором функция для: расчета усреднённого уровня дохода по основному месту работы (/по совместительству) на основании введённых анкетных данных в соответствии с алгоритмом, выбранным вручную из заданных в Системе; анализа минимальных требований; анализа стоп условий; использования внутренних или внешних скоринговых карт. Матрица принятия кредитного решения Система должна позволять создавать и поддерживать матрицу принятия решений по кредитной заявке. Матрица определяет роли и/или совокупности ролей, которые имеют право проголосовать по заявке. Каждая роль может проставлять следующие резолюции: ЗА;^ ЗА ПРИ УСЛОВИИ; ПОВЫШЕНИЕ УРОВНЯ КОМПЕТЕНЦИИ ДЛЯ ПРИНЯТИЯ ОКОНЧАТЕЛЬНОГО РЕШЕНИЯ; ПРОТИВ. В зависимости от настроек матрицы окончательное решение определяется либо голосом одной роли, либо большинством голосов нескольких ролей. У различных ролей могут быть разные веса при голосовании. При принятии решения по заявке голосованием необходимо проверять лимит на принятие решения как одной ролью, так и совокупный лимит ролей. В ходе принятия решения заявка может быть отправлена на фронт на доввод или на доработку. Лимиты на кредитный риск Система должна позволять настраивать различные типы лимитов непосредственно бизнес-аналитиком. Также необходимо логирование истории изменения лимитов. Типы лимитов: лимит на заёмщика/ группу связанных заёмщиков (ГСЗ); лимиты по продукту/группе однородных продуктов/субпродуктам/ промоакциям и т.п.; лимиты на контрагентов: застройщиков, страховые компании и т.д.; лимиты на отрасль; лимиты на подразделение продаж (РОО, ДО, филиал и т.п.); лимит на субъект оценки залога (по сотрудникам банка); лимит на субъект оценки залога (по оценочной компании).Варианты использования лимитов: лимиты на объём выдач (разовый лимит) – лимит используется по мере предоставления новых продуктов и не возобновляется в ходе погашений.; лимиты на текущий объём использования кредитных средств; лимит по заявкам – максимальное использование лимита при выдаче утвержденных заявок; лимит на процент заявок во входящем потоке заявок; нулевой лимит – запрет кредитования в ТП по продукту/субпродукту и т.д..Тип контроля: online – контроль до момента принятия кредитного решения, в случае превышения лимита кредит не может быть выдан; offline – последконтроль, отчётность по использованию лимитов.Действия с лимитами: добавление, закрытие, изменение. Нетиповые условия На этапе «Анализа заявки на входе» заявки могут быть определены как: нетиповые (в т.ч. заявки по VIP-Клиентам или индивидуальные заявки); стандартные.По нетиповым заявкам Система должна обладать следующим функционалом: выявлять параметры и условия заявки (рассчитанные автоматически и введённые вручную), отличные от стандартных по продукту / субпродукту, отражая данную информацию в интерфейсе и печатных отчётных формах; позволять на разных этапах обработки заявки (ввод / анализ / формирование проекта решения / корректировка принятого решения) отправлять (в мастер-систему) на корректировку анкету, при этом набор полей для корректировки может быть различным на каждом этапе, в т.ч. в зависимости от продукта; должна быть возможность ручного отнесения заявки к классу «Нетиповая» с указанием причин в поле «Комментарий»; должна быть возможность настройки ранжирования нетиповых условий на классы по степени значимости; осуществлять обработку заявки и расчет лимита платежеспособности с учётом рассчитанных или введенных вручную нетиповых условий; устанавливать для заявки уровень принятия решения с учётом наличия нетиповых условий и их класса. Проверка моратория Целью продуктового моратория является предотвращение повторного инициирования кредитных заявок по клиенту, получившему в течение последних n дней отказ по заявке из этой же продуктовой группы. Система должна проверять продуктовый мораторий по клиенту, например: наличие у заёмщика заявок в статусах, соответствующих отказу по инициативе Банка, проставленных автоматически Системой в рамках той же продуктовой группы, что и анализируемая заявка; Система должна учитывать только заявки, в которых отказ проставлен по заёмщику; срок, в рамках которого действует продуктовый мораторий, должен быть настраиваемым параметром. Принятие кредитного решения Система должна иметь следующий функционал: возможность проведения различных сценариев принятия решения: автомат, экспертно (в рамках персонального и совместного лимита компетенции); возможность настройки перечня типов сделок в зависимости от условий сделок, влияющих на уровень принятия решения; возможность расчёта достаточности обеспечения по заявке с учётом нескольких типов обеспечения; формирование Решения и Отчета/Заключения о провёденном анализе по заявке, формирование отчёта достаточности обеспечения по заявке; контроль срока действия. Определение характеристик резервирования на этапе принятия решения При принятии решения по каждой новой заявке на кредит определять оценку финансового состояния клиента в соответствии с заданным алгоритмом (например: на основании набранного скорингового балла /в зависимости от результата прохождения заявкой определенных этапов обработки). Оценка финансового состояния должна определяться в т.ч. с учетом заданного перечня хранящихся данных о заёмщике и его кредитных договорах. Позволять ручную корректировку автоматически присвоенной оценки финансового состояния и категории качества ссуды. При принятии решения по каждой новой заявке на кредит проставлять признак индивидуальной ссуды; Отражать в интерфейсе и печатных отчётных формах по каждой отдельной заявке по кредиту определённые (автоматически и вручную) характеристики резервирования и категорию качества ссуды, а так же формировать отчёты (специальные печатные формы) по оценке ссуды и финансового состояния заёмщика. Работа риск менеджера с заявкой Получение риск-менеджером заявки для рассмотрения и автоматический переход к назначенной заявке в Системе. Заявка назначается по нажатию соответствующей кнопки на рабочем месте, случайным образом с учётом настроенных правил отбора заявок.Функционал, необходимый для работы с заявкой (серая зона – заявки, обязательно попадающие на решение риск менеджера): вариативное настраивание набора полей в форме риск менеджера; поиск клиента по запросу из внешних систем Банка; поиск информации о других кредитных и некредитных продуктах клиента; анализ нескольких участников сделки;возможность внесения информации в новые поля анкеты с передачей на фронт. Например, корректировка доп. данных, корректировка собственности; при этом необходима возможность четкого определения полей, которые могут изменяться;после принятия решения по заявке заявка помечается как обработанная; в системе фиксируются принятое решение, условия, на которых принято решение, и комментарии риск-менеджера, которые должны быть доступны для просмотра только риск-менеджерам и администратору.В Системе должна сохранять история запросов на снятие решений по заявкам;В случае если по заявке инициируется повторная процедура снятия принятого решения, при этом предыдущий запрос еще не обработан риск-менеджером, Система должна группировать такие запросы и уведомлять об этом пользователей, работающих с заявкой. Очередь заявок Параметры формирования очереди формируются отдельным администратором. В рамках управления очередью заявки должны сортироваться, приоритизироваться администратором очереди по любым признакам. Распределение очереди осуществляется в автоматическом режиме с возможностью предоставления прав распределения в ручном режиме администратору. В рамках управления очередью необходимо формирование отчётности по всем признакам заявок и по времени рассмотрения. Формирование печатных форм Список необходимых форм: Прохождение заявки по этапам Решение о предоставлении кредита Заключение о предоставлении кредита Результат проверки СПЗ (будет предоставлена позднее) Оценка финансового состояния Отчет БКИ ^ Распределение прав в Систему Предполагается участие следующих подразделений Банка, на основании которых необходимо разработать соответствующие роли: Администратор системы. Функции: осуществление настройки бизнес-параметров системы, руководство очередью заявок, распределение нагрузки на бизнес-подразделения. Разработчик. Функции: дизайн стратегий, разработка (Workflow, экранные формы, печатные формы т.д.) Администратор доступа. Функции: заведение пользователей, распределение ролей. Support. Функции: поддержка работоспособности системы, функции отправки на следующие этапы заявок в случае системных сбоев, загрузка списочных реестров. Администратор безопасности. Риск-менеджеры с различным уровнем компетенции. Функции: принятие решений, просмотр результатов анализа, выдача заключений. Риск-менеджер по работе с обеспечением/залогами. Функции: работа по залогам. Администратор системы по настройкам правил проверки по «чёрным» спискам.^ Работа по залоговым рискам Система должна позволять настраивать различные типы контролей на залоговые риски сотрудником управления по работе с залогами. Кредитное решение с определением лимита кредита (подбор альтернативы) одобряется в зависимости от результатов анализа залогового обеспечения и соответствующих лимитов на залоговые риски. ^ Типы залоговых ограничений:Ограничение по составу обеспечения. Необходимо реализовать настраиваемый справочник – матрицу залогов согласно ОРД Банка, на основе которого Система будет анализировать соответствие предлагаемого в залог имущества требованиям Банка к обеспечению для определенного кредитного продукта, в том числе субпродукта, промо-акции. Если имущество является предметом последующего залога, то необходимо реализовать проверку выполнения мониторинга залога в соответствии с графиком мониторинга.^ Ограничение по составу предоставляемых клиентом документов по залогу. Необходимо реализовать контроль необходимых документов в зависимости от типа залога (недвижимость, автотранспорт, оборудование, товарно-материальные ценности, др.). Справочник документов должен быть настраиваемым по типам залогов, по обязательности: обязательные / рекомендательные, по типу предоставления: до выдачи / после выдачи кредита.^ Ограничение по субъекту оценки. Необходимо реализовать контроль по субъекту оценки по точке продаж, лимиту ответственности, наличию данных. Необходимо реализовать Справочник субъектов оценки (Риск менеджер, Рекомендованный оценщик, Не рекомендованный оценщик, Сотрудник бизнес-подразделения) с возможностью настройки определенных субъектов оценки в разрезе точки продаж Банка. Для субъекта оценки «Рекомендованный оценщик» необходимо реализовать Справочник наименований рекомендованных Банком Оценочных организаций. Для субъекта оценки «не рекомендованный оценщик» необходимо реализовать Справочник с перечнем оценщиков, не рекомендованных Банком.^ Ограничение по залоговой стоимости. Система должна автоматически будет определять величину залоговой стоимости имущества с учетом заводимых в справочнике дисконтов. Справочник должен быть настраиваемым.Контроль:Контроль по составу предоставляемых клиентом документов по залогу – при несоответствии состава документов, предоставленных клиентом, пакету обязательной документации в соответствии с таблицей необходимых документов по разным типам залогов либо невыполнении отлагательных условий по результатам залоговой экспертизы решение не одобряется.^ Контроль по субъекту оценки – в зависимости от субъекта оценки и его лимита ответственности определяется способ оценки кредитных и залоговых рисков.К