Решение для оценки платежеспособности клиентов ( Risk Management System, RMS) для финансовых компаний
Всем привет! Меня зовут Петрович и я лид команды Java разработки в softwarecats.dev. Мы занимаемся заказной разработкой, а также активно развиваем продуктовое направление.
Сегодня я хочу поделиться историей о том, как мы решили разработать и вывести на рынок собственное решение для оценки платежеспособности клиентов (в народе risk management system или коротко - RMS) для финансовых компаний.
Начать, думаю, следует с предыстории. В топ- и миддл- менеджменте нашей компании собрались люди, чей опыт либо явно выходит из финтеха, либо неразрывно с ним связан. Для любой финансовой компании, будь то МФО, банк или НКО (небанковская кредитная организация), выдающего деньги под проценты, оценка платежеспособности клиентов - ключевой показатель, на базе которого порой строится весь бизнес компании. Суть оценки проста - выдавать хорошим клиентам, а плохим не выдавать. А что, собственно, представляет из себя хороший клиент или плохой? Хороший клиент это такой клиент, который вовремя и в полном объеме возвращает выданные ему деньги, не допуская дефолта - просрочки по графику платежей. Соответственно, плохой клиент тот, который не собирается платить либо изначально, либо уже в процессе пользования выданными ему деньгами. Система оценки платежеспособности клиентов (далее я буду ее называть просто RMS) должна решать одну задачу - предсказывать насколько велика вероятность, что клиент будет платить хорошо. Чем лучше (точнее) RMS оценивает клиентов, тем она больше ценится и тем больше людей хочет ее внедрить у себя.
Каким способом можно точно оценить клиента, который только что пришел в компанию и все, что мы о нем известно это анкетные данные, оставленные на сайте при оформлении заявки на кредит/займ? Существует множество сервисов, но главный источник данных это кредитная история. Только кредитная история может предоставить наиболее обширную и достоверную историю платежей клиента.
К счастью, у нас уже был обширный опыт интеграции как с кредитными бюро - основными и единственными поставщиками информации по кредитным историям клиентов, - так и с прочими сервисами, предоставляющими более узкоспециализированные оценки (от аналитики биллинга счетов сотовых операторов до аналитики соцсетей). Многие члены команды работали в микрофинансовых компаниях и мы хорошо понимали боли и слабые места данного рода бизнеса, как и места, которые хорошо автоматизируются. Поэтому первой идеей было разработать и внедрить прототип у одного из наших клиентов - микрофинансовой компании.
В процессе проектирования прототипа мы поняли, что можно не ограничиваться только микрофинансовыми компаниями - можно предложить платформу, которая будет применима к любой компании и не только финансовой. Любая сфера, где требуется провести проверку клиента на соответствие списку критериев сможет использовать у себя наше решение.
Сегодня я хочу поделиться историей о том, как мы решили разработать и вывести на рынок собственное решение для оценки платежеспособности клиентов (в народе risk management system или коротко - RMS) для финансовых компаний.
Начать, думаю, следует с предыстории. В топ- и миддл- менеджменте нашей компании собрались люди, чей опыт либо явно выходит из финтеха, либо неразрывно с ним связан. Для любой финансовой компании, будь то МФО, банк или НКО (небанковская кредитная организация), выдающего деньги под проценты, оценка платежеспособности клиентов - ключевой показатель, на базе которого порой строится весь бизнес компании. Суть оценки проста - выдавать хорошим клиентам, а плохим не выдавать. А что, собственно, представляет из себя хороший клиент или плохой? Хороший клиент это такой клиент, который вовремя и в полном объеме возвращает выданные ему деньги, не допуская дефолта - просрочки по графику платежей. Соответственно, плохой клиент тот, который не собирается платить либо изначально, либо уже в процессе пользования выданными ему деньгами. Система оценки платежеспособности клиентов (далее я буду ее называть просто RMS) должна решать одну задачу - предсказывать насколько велика вероятность, что клиент будет платить хорошо. Чем лучше (точнее) RMS оценивает клиентов, тем она больше ценится и тем больше людей хочет ее внедрить у себя.
Каким способом можно точно оценить клиента, который только что пришел в компанию и все, что мы о нем известно это анкетные данные, оставленные на сайте при оформлении заявки на кредит/займ? Существует множество сервисов, но главный источник данных это кредитная история. Только кредитная история может предоставить наиболее обширную и достоверную историю платежей клиента.
К счастью, у нас уже был обширный опыт интеграции как с кредитными бюро - основными и единственными поставщиками информации по кредитным историям клиентов, - так и с прочими сервисами, предоставляющими более узкоспециализированные оценки (от аналитики биллинга счетов сотовых операторов до аналитики соцсетей). Многие члены команды работали в микрофинансовых компаниях и мы хорошо понимали боли и слабые места данного рода бизнеса, как и места, которые хорошо автоматизируются. Поэтому первой идеей было разработать и внедрить прототип у одного из наших клиентов - микрофинансовой компании.
В процессе проектирования прототипа мы поняли, что можно не ограничиваться только микрофинансовыми компаниями - можно предложить платформу, которая будет применима к любой компании и не только финансовой. Любая сфера, где требуется провести проверку клиента на соответствие списку критериев сможет использовать у себя наше решение.
Спустя 2 месяца проектирования и прототипирования мы сумели сформировать требования к будущей системе. Итак, она должна
После завершения процесса сбора требований мы приступили к отрисовке будущей архитектуры. Хотелось с одной стороны сделать максимально гибкий процесс, а с другой не утонуть в многочисленных настройках будущей системы. Стек решили взять привычный для разработчиков в команде - микросервисы на Java и Spring Boot, PostgreSQL для длительного хранения, Elasticsearch для аналитики и быстрых поисковых запросов, BPMN для оркестрации процессов, REST или gRPC для общения модулей друг с другом. По итогам проектирования родилась следующая архитектурная диаграмма:
- Быть быстрой. Настолько быстрой, насколько это возможно. Прежде всего скорость принятия решения влияет на все остальные части системы и в конечном счете на имидж компании для клиента.
- Помимо того что система должна быть быстрой, она должна быть достаточно гибкой для изменений. Очень часто в нашей практике мы сталкивались с тем, что самые небольшие изменения на первый взгляд требуют, без шуток, недель работ программистов. Такого лучше избегать еще на старте, при проектировании системы.
- Система должна позволять проводить А/Б тесты на клиентах и собирать статистику. Например, вы хотите проверить как считаются новый набор правил, но не хотите чтобы решение по новому набору правил принималось сразу. Именно это должна позволять делать хорошая RMS система.
- Система должна обладать высокой переносимостью, в том числе между странами. Очень часто особенно в последнее время встает вопрос переносимости решения между странами, который можно свести всего к одному вопросу - как долго и дорого будет развернуть это решение в новой стране? Ведь помимо работы инженеров над инфраструктурой важно еще учитывать, что нужен человек со стороны бизнеса, который разработает новые наборы правил и проверит их работу на новых данных.
- Система не должна содержать вендор-локов. То есть мы не должны зависеть от вендоров при проектировании и реализации системы. В идеале все технологии должны быть с открытым исходным кодом.
- Наша RMS должна обладать средствами аналитики причем сразу с веб-интерфейсом, чтобы профильный сотрудник могу сразу одним взглядом на графики понять что происходит со процессом и в каком месте проблема. И также сформировать отчеты по прошедшим периодами, чтобы в любой момент под рукой иметь все данные необходимые для аналитики.
- И последнее, но не самое последнее по важности - наша будущая RMS должна предоставлять возможности для гибкой настройки кэширования запросов к интеграциям, в том числе и для кредитных бюро.
- Система не должна быть дорогой. Промышленные решения могут стоить десятки миллионов рублей за лицензию и сотни тысяч ежемесячно за поддержку. Для нашего будущего продукта это слишком непомерная величина - ведь с такой стоимостью мы не сможем охватить наибольший сегмент рынка.
- Все промышленные системы обладают очень существенным недостатком - они либо вообще не подстраиваются под потребителя, либо за очень большие деньги. Мы встречали оценки доработок в системах и оценки разнятся - от 600 тысяч до 1,5 миллионов
- RMS должна быть рассчитана на большой поток данных. На некоторых системах мы тестировали пропускную способность и она была плачевной - от 2-5 запросов в минуту до 2 в секунду. То есть одновременно могут проходить процесс оценки только два клиента. Если процесс предполагает длину в 20 и более секунд, то это не позволит масштабироваться.
После завершения процесса сбора требований мы приступили к отрисовке будущей архитектуры. Хотелось с одной стороны сделать максимально гибкий процесс, а с другой не утонуть в многочисленных настройках будущей системы. Стек решили взять привычный для разработчиков в команде - микросервисы на Java и Spring Boot, PostgreSQL для длительного хранения, Elasticsearch для аналитики и быстрых поисковых запросов, BPMN для оркестрации процессов, REST или gRPC для общения модулей друг с другом. По итогам проектирования родилась следующая архитектурная диаграмма:
Мы решили сделать монолитным только ядро, а все остальные части должны быть подключаемыми на уровне модулей исходного кода. Подобное решение позволит при переносе из страны в страну не переносить лишние интеграции и разворачивать только необходимые модули. Обращение к RMS сделать через единый API-шлюз. Там же сделать проверку доступа, авторизации, ролей и т.д. BPMN-движок позволит гибко настраивать через веб-интерфейс управление процессом принятия решения. Стандартизация главных аспектов проекта, как то: переменные процессов, маппинг из общей модели данных в модель источников данных - на старте потребует большего количества времени на разработку, но на дистанции позволит сократить время запуска новых интеграций и уменьшить время необходимое для замены сотрудников на проекте.
Самая большая проблема и потенциальное узкое место в системах подобного рода - внутренняя модель данных. Необходимость постоянно изменять модель и распространять изменения на всю систему, что доставляет немало проблем. Зачастую изменения во внутренней модели могут противоречить друг другу и могут возникать конфликты при активной разработке нескольких интеграций одновременно. Мы решили использовать в качестве основы json и сделать модель максимально гибкой - отказаться от жесткой фиксации тела запроса и ответа в конкретный источник данных, а взамен использовать объект общего типа с неограниченным набором полей, внутри которого, с помощью удобно настраиваемого через веб-интерфейс набора преобразований, мы будем хранить все необходимое для получения запроса и ответа. Все преобразования будут храниться в базе данных, иметь версии и доступны для восстановления и изменения в любой момент по желанию заказчика через веб-интерфейс. Нашим девизом при проектировании было: если что-то можно дать настроить пользователю - нужно дать возможность ему настроить это.
Вместе с системой мы решили поставлять и собственный сервер авторизации на базе Keycloak. Наличие надежного Oauth2 и множества интеграций со сторонними системами (active directory) как уже написанных за нас, так и потенциально возможных, на наш взгляд должно было выгодно отличать наше решение от решений прочих вендоров. Ведь гораздо проще найти специалиста на рынке на какую-либо технологию с открытым исходным кодом, нежели на проприетарную.
На основе выбранных технологий, помножив на собственный опыт в разработке систем принятия решений мы решились выходить на рынок. И теперь я хочу дать цифры, чтобы было понимание насколько долго, сложно и дорого реализовать систему подобного масштаба. В процессе реализации:
Будут задействованы 3 человека (1 бэкенд разработчик, 1 фронтент, 1 девопс). Для ядра обработки процессов и модуля запроса КИ в НБКИ - полтора месяца на каждый модуль. Модуль проверки паспортов половина месяца. Модуль расчета факторов - 1 месяц. Веб-интерфейс ко всей системе - 3 месяца. И еще месяц на инфраструктуру. И три на тестирование. Итого 5,5-6 месяцев работы 3-4 человек и в итоге вы получаете работающий RMS.
В деньгах это примерно 6 миллионов рублей.
Полгода и 6 миллионов рублей взамен на свободу от вендоров, гибкую, надежную и расширяемую через интерфейс систему оценки платежеспособности клиента на наш взгляд весьма и весьма хорошая инвестиция времени и денег для компании любого уровня.
Самая большая проблема и потенциальное узкое место в системах подобного рода - внутренняя модель данных. Необходимость постоянно изменять модель и распространять изменения на всю систему, что доставляет немало проблем. Зачастую изменения во внутренней модели могут противоречить друг другу и могут возникать конфликты при активной разработке нескольких интеграций одновременно. Мы решили использовать в качестве основы json и сделать модель максимально гибкой - отказаться от жесткой фиксации тела запроса и ответа в конкретный источник данных, а взамен использовать объект общего типа с неограниченным набором полей, внутри которого, с помощью удобно настраиваемого через веб-интерфейс набора преобразований, мы будем хранить все необходимое для получения запроса и ответа. Все преобразования будут храниться в базе данных, иметь версии и доступны для восстановления и изменения в любой момент по желанию заказчика через веб-интерфейс. Нашим девизом при проектировании было: если что-то можно дать настроить пользователю - нужно дать возможность ему настроить это.
Вместе с системой мы решили поставлять и собственный сервер авторизации на базе Keycloak. Наличие надежного Oauth2 и множества интеграций со сторонними системами (active directory) как уже написанных за нас, так и потенциально возможных, на наш взгляд должно было выгодно отличать наше решение от решений прочих вендоров. Ведь гораздо проще найти специалиста на рынке на какую-либо технологию с открытым исходным кодом, нежели на проприетарную.
На основе выбранных технологий, помножив на собственный опыт в разработке систем принятия решений мы решились выходить на рынок. И теперь я хочу дать цифры, чтобы было понимание насколько долго, сложно и дорого реализовать систему подобного масштаба. В процессе реализации:
Будут задействованы 3 человека (1 бэкенд разработчик, 1 фронтент, 1 девопс). Для ядра обработки процессов и модуля запроса КИ в НБКИ - полтора месяца на каждый модуль. Модуль проверки паспортов половина месяца. Модуль расчета факторов - 1 месяц. Веб-интерфейс ко всей системе - 3 месяца. И еще месяц на инфраструктуру. И три на тестирование. Итого 5,5-6 месяцев работы 3-4 человек и в итоге вы получаете работающий RMS.
В деньгах это примерно 6 миллионов рублей.
Полгода и 6 миллионов рублей взамен на свободу от вендоров, гибкую, надежную и расширяемую через интерфейс систему оценки платежеспособности клиента на наш взгляд весьма и весьма хорошая инвестиция времени и денег для компании любого уровня.
Senior Java-разработчик Software Cats