Разработка мобильного приложения для краудлендинга под ключ

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

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

Онбординг заёмщика — самый дорогой участок. Если проверка документов не сохраняет промежуточный прогресс, при обрыве связи человек возвращается к первому шагу и закрывает приложение. Мы делаем шаги возобновляемыми, а решения проверки идемпотентными: повторная отправка не создаёт вторую заявку и не двигает сделку назад.

Зависшие статусы заявок — вторая по частоте причина обращений в поддержку. Обычно мобильное приложение для займов узнаёт статус только при открытии экрана, а событие от банка или платёжного провайдера теряется. Закрывается это очередью событий с повторной доставкой и периодической сверкой с реестром.

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

Отвал на этапе подтверждения — отдельный класс сбоев: подпись, отправка платежа, ожидание ответа банка. Здесь работают оффлайн-очередь, таймауты и понятный сценарий отката, если операция не прошла. Дальше разбираем, как это закрывается — от модели состояний и сверок до восстановления после сбоя.

Что даёт платформа: скорость сделки и доверие инвесторов

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

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

Доверие инвесторов держится не на обещаниях, а на выписке. По каждой сделке доступна история статусов, суммы и расчёт доходности — цифры сходятся у клиента и в бэк-офисе. Проверку личности и источника средств закрывает Sumsub: верификация проходит в приложении, без визита в офис и пересылки сканов.

Снижение нагрузки на поддержку — следствие идемпотентных операций и повторных попыток. Обращения делятся на два потока: «где моя заявка» и «почему не сошлась выплата». Первый закрывают статусы и уведомления, второй — сверка реестра и автоматический пересчёт. Доля брошенных регистраций падает: человеку не нужно ждать ответа, чтобы продолжить.

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

Варианты реализации: нативный код, единая база или готовое ядро

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

Как выбираем вариант

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

Этапы работы над платформой: от аудита модели до передачи

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

1. Аудит модели займа. Разбираем расчёт ставки, комиссий и дохода инвестора, поведение графика при досрочном и частичном погашении. Правила фиксируем формулами и таблицами, а не в переписке.
2. Требования регулятора. Определяем обязательный состав данных, порядок подтверждения личности, лимиты и отчётность, ограничения на публичную витрину. Это становится частью архитектуры, а не надстройкой в конце.
3. Схема данных и роли. Проектируем сущности — заёмщик, инвестор, заявка, доля, платёж, договор — и матрицу доступа: кто видит персональные данные, кто отменяет операции. Движение денег идёт через журнал операций.
4. Сборка. Реализуем ядро и интерфейсы, подключаем платежи, идентификацию, бюро кредитных историй и уведомления. Внешние сервисы держим за изолированным слоем, чтобы замена не тянула переписывание логики займа.
5. Проверка сценариев. Прогоняем сквозные цепочки: выпуск займа, набор суммы, частичное погашение, просрочка, возврат, отмена. Расхождение с эталонным расчётом доводим до нуля.
6. Приёмка и передача. Передаём репозиторий, документацию по модели данных и регламент развёртывания, обучаем вашу команду. На выходе — работающая система и понятный порядок выпуска изменений.

Что остаётся в вашем контуре после запуска и передачи

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

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

Такой комплект снимает главный риск сопровождения: новый инженер входит в проект по документации, а не по памяти предыдущей команды.

Кейс: платформа выдержала рост сделок без переделки ядра

Платформа пришла к нам на этапе, когда число сделок росло быстрее, чем ядро успевало их обрабатывать. Согласование заявки занимало до шести часов: график платежей и проверки пересчитывались в одном процессе с каталогом заявок, поэтому любой пик тормозил остальные операции. Доля незавершённых регистраций доходила до трети, а поддержка получала около 180 обращений на тысячу сделок — в основном «заявка зависла», «не вижу статус».

Что изменили в ядре

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

После переезда согласование в обычном режиме занимает около 25 минут, доля незавершённых регистраций — 12%, обращений в поддержку — порядка 60 на тысячу сделок. Сезонный пик с четырёхкратным ростом одновременных заявок прошёл без ручного вмешательства: отказы гасились на уровне очереди и до инвестора не доходили.

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

Что делать, если приложение уже выпущено, а требования изменились?

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

Главное решение при изменении требований — как развести клиент и сервер по времени. Рабочих стратегий четыре, и выбор зависит от того, ломает ли правка текущий контракт обмена данными.

Миграция без простоя идёт по методике расширения и сжатия (Expand / Contract): сначала добавляем новые поля, выкатываем сервер, который читает оба формата; затем включаем двойную запись, фоновым заданием перезаполняем историю, переключаем чтение на новый источник и только через несколько релизов удаляем старое поле. Обновление без остановки сервиса держится на том, что на каждом шаге есть рабочий откат.

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

Частые технические сомнения и наши ответы по существу

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

Как приложение встраивается в банковское ядро?

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

Насколько автоматизирована проверка заёмщика?

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

Как проверяются платёжные сценарии до запуска?

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

Обсудим задачу: что прислать для оценки и плана

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

• Логику сделки: кто занимает, кто инвестирует, как считается доходность, что происходит при просрочке и досрочном погашении, есть ли вторичный рынок займов.
• Денежные сценарии: пополнение и вывод, автоинвестирование, распределение платежей между инвесторами, удержание комиссии платформы, возвраты и частичные списания.
• Требования регулятора: наличие лицензии, порядок проверки личности инвестора и заёмщика, лимиты на вложения, состав и сроки отчётности.
• Внешние сервисы: платёжный провайдер, проверка документов, модель оценки заёмщика, бюро кредитных историй, рассылки и уведомления — с указанием, у кого сейчас доступы.
• Текущее состояние: есть ли код, дизайн, опубликованные приложения, аккаунты в магазинах и права на них, какие платформы нужны и в каком порядке.
• Ограничения подготовки к запуску: сроки, привязанные к датам лицензии или договоров, и требования по нагрузке на старте.

Этот список закрывает и техчасть, и юридическую рамку, поэтому после него не приходится возвращаться с уточнениями через неделю. Если чего-то нет — опишите словами, мы восстановим пробелы на созвоне.

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