Решение для оценки платежеспособности клиентов (Risk Management System, RMS) для финансовых компаний

Всем привет! Меня зовут Петрович и я лид команды Java разработки в softwarecats.dev. Мы занимаемся заказной разработкой, а также активно развиваем продуктовое направление.

Сегодня я хочу поделиться историей о том, как мы решили разработать и вывести на рынок собственное решение для оценки платежеспособности клиентов (в народе risk management system или коротко - RMS) для финансовых компаний.

Начать, думаю, следует с предыстории. В топ- и миддл- менеджменте нашей компании собрались люди, чей опыт либо явно выходит из финтеха, либо неразрывно с ним связан. Для любой финансовой компании, будь то МФО, банк или НКО (небанковская кредитная организация), выдающего деньги под проценты, оценка платежеспособности клиентов - ключевой показатель, на базе которого порой строится весь бизнес компании. Суть оценки проста - выдавать хорошим клиентам, а плохим не выдавать. А что, собственно, представляет из себя хороший клиент или плохой? Хороший клиент это такой клиент, который вовремя и в полном объеме возвращает выданные ему деньги, не допуская дефолта - просрочки по графику платежей. Соответственно, плохой клиент тот, который не собирается платить либо изначально, либо уже в процессе пользования выданными ему деньгами. Система оценки платежеспособности клиентов (далее я буду ее называть просто RMS) должна решать одну задачу - предсказывать насколько велика вероятность, что клиент будет платить хорошо. Чем лучше (точнее) RMS оценивает клиентов, тем она больше ценится и тем больше людей хочет ее внедрить у себя.

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

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

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

Спустя 2 месяца проектирования и прототипирования мы сумели сформировать требования к будущей системе. Итак, она должна

1. Быть быстрой. Настолько быстрой, насколько это возможно. Прежде всего скорость принятия решения влияет на все остальные части системы и в конечном счете на имидж компании для клиента.
2. Помимо того что система должна быть быстрой, она должна быть достаточно гибкой для изменений. Очень часто в нашей практике мы сталкивались с тем, что самые небольшие изменения на первый взгляд требуют, без шуток, недель работ программистов. Такого лучше избегать еще на старте, при проектировании системы.
3. Система должна позволять проводить А/Б тесты на клиентах и собирать статистику. Например, вы хотите проверить как считаются новый набор правил, но не хотите чтобы решение по новому набору правил принималось сразу. Именно это должна позволять делать хорошая RMS система.
4. Система должна обладать высокой переносимостью, в том числе между странами. Очень часто особенно в последнее время встает вопрос переносимости решения между странами, который можно свести всего к одному вопросу - как долго и дорого будет развернуть это решение в новой стране? Ведь помимо работы инженеров над инфраструктурой важно еще учитывать, что нужен человек со стороны бизнеса, который разработает новые наборы правил и проверит их работу на новых данных.
5. Система не должна содержать вендор-локов. То есть мы не должны зависеть от вендоров при проектировании и реализации системы. В идеале все технологии должны быть с открытым исходным кодом.
6. Наша RMS должна обладать средствами аналитики причем сразу с веб-интерфейсом, чтобы профильный сотрудник могу сразу одним взглядом на графики понять что происходит со процессом и в каком месте проблема. И также сформировать отчеты по прошедшим периодами, чтобы в любой момент под рукой иметь все данные необходимые для аналитики.
7. И последнее, но не самое последнее по важности - наша будущая RMS должна предоставлять возможности для гибкой настройки кэширования запросов к интеграциям, в том числе и для кредитных бюро.
8. Система не должна быть дорогой. Промышленные решения могут стоить десятки миллионов рублей за лицензию и сотни тысяч ежемесячно за поддержку. Для нашего будущего продукта это слишком непомерная величина - ведь с такой стоимостью мы не сможем охватить наибольший сегмент рынка.
9. Все промышленные системы обладают очень существенным недостатком - они либо вообще не подстраиваются под потребителя, либо за очень большие деньги. Мы встречали оценки доработок в системах и оценки разнятся - от 600 тысяч до 1,5 миллионов
10. 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 миллионов рублей взамен на свободу от вендоров, гибкую, надежную и расширяемую через интерфейс систему оценки платежеспособности клиента на наш взгляд весьма и весьма хорошая инвестиция времени и денег для компании любого уровня.

Наша команда уже более пяти лет занимается реализацией проектов на Java и усилением команд по направлениям

• DevOps;
• Java разработка;
• Тестирование.

За время существования компании, мы принимали участие в работе над более чем 100 проектами различного объема и длительности.

Если перед вами стоят вызовы, при которых вам может пригодится наша экспертиза, просто напишите нам,

• client@softwarecats.dev,
• https://t.me/alex_zarubin,
• или через любую форму на сайте.

Мы договоримся с вами об онлайн-встрече, чтобы подробнее обсудить ваш проект и вашу проблему.