Разработка гибкой платформы для кредитования: от крупных банков к массовому рынку

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

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

Как платформа трансформировалась

Задача платформы — облегчить кредитование. На первом этапе развития крупные партнеры — банки или финансовые организации — приобретали поддержку платформы за значительные суммы, чтобы использовать ее для предоставления кредитов предприятиям малого бизнеса.

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

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

Что такое кредитование

Клиент заходил на сайт (для каждого партнера это были разные интерфейсы), заполнял данные, они сохранялись и отправлялись в ядро системы.

Клиент оформлял заявку на кредит, чтобы, например, получить средства на новое оборудование, купить автомобиль или погасить предыдущий кредит — все это вместе называется application. Затем, когда заявка попадала в ядро решений, проходило несколько этапов. Для заявки создавалось решение на основе данных, введенных клиентом.

Как создавалось это решение? Ядро управляло правилами проверки каждого клиента по различным базам данных. Базы данных — это интеграции со множеством сервисов по кредитной истории, судопроизводству и другим аспектам. Всего было около 30 интеграций.

Для каждого партнера конфигурировался свой набор интеграций. Затем движок проверок настраивался на определенном языке, чтобы выполнять достаточно гибко описанные правила. Например, он мог взять данные из application, созданного пользователем, затем получить сведения о персональных данных клиента из интеграций, чтобы узнать его кредитную историю, судебные дела, проверить, действителен ли его паспорт, есть ли у него водительские права, узнать его возраст, не умер ли он и не является ли его e-mail фишинговым.

Все это описывалось на определенном языке. Если что-то шло не так, запрашивались дополнительные данные. Их должен был предоставить либо сам пользователь, либо банковский сотрудник через UI. Кастомизация происходит как для UI потребителя — того, кто берет кредит, так и для UI кредитной организации — того, кто обрабатывает запрос на кредитование

Для всех решений на основе конфигураций создавался объект, который определял — выдавать кредит или нет. Если требовались какие-то дополнительные действия, создавались задачи для банковского работника. Задачи были разного рода: добавить данные, сравнить их, загрузить файлы. Каждая такая задача также была частью конфигурации — существовали шаблоны, которые отображались на UI именно в том виде, в котором они настроены.

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

В ядре системы также был реализован внутренний поисковый движок. Он мог не только искать данные через UI, его задачей также было находить по определенным параметрам объекты домена, чтобы отправлять письма или аннулировать заявки.

С технической точки зрения поисковые документы находились в Elasticsearch, но при этом мы трансформировали язык движка в запросы GraphQL. 

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

Мультитенантность в действии: как платформа адаптировалась для работы с разными партнерами

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

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

При этом у нас все еще оставалась гибкая конфигурируемая платформа, то есть каждый из партнеров не просто использовал один и тот же ресурс. Например, если кто-то использует S3-хранилище файлов, то оно одинаково для всех. Один и тот же API предоставляет одни и те же возможности. Однако все правила, набор задач, которые банковский работник мог выполнить у себя на UI, рендер этих задач, набор правил кредитования, трансформация данных пользователей в наши внутренние данные — все это было индивидуально для каждого партнера.

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

Что представляли собой конфигурации? Набор различных файлов в формате JSON или XML, а также файлов на языке шаблонов, типа Moustache, JSON-E и JSON Schema с кастомными полями для форм на UI.

Заключение

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