Розробка краудлендингового застосунку: де ламаються угоди
Угода в краудлендингу живе довше однієї сесії: інвестор підтверджує участь, позичальник проходить ідентифікацію, платіж іде в банк, а статус змінюється кілька разів. Розрив у цьому ланцюжку — втрачений користувач і незакрита угода, а не збій інтерфейсу. Тому розробка застосунку для краудлендингу починається з моделі станів угоди, а не з екранів.
Онбординг позичальника — найдорожча ділянка. Якщо перевірка документів не зберігає проміжний прогрес, у разі обриву зв’язку людина повертається до першого кроку й закриває застосунок.
Ми робимо кроки відновлюваними, а рішення перевірки ідемпотентними: повторне надсилання не створює другої заявки й не зсуває угоду назад.
Завислі статуси заявок — друга за частотою причина звернень до підтримки. Зазвичай мобільний застосунок для позик дізнається про статус лише під час відкриття екрана, а подія від банку або платіжного провайдера губиться. Це закривається чергою подій із повторною доставкою та періодичною звіркою з реєстром.
Особистий кабінет інвестора — місце, де розсинхрон балансів помітний одразу. Якщо суми рахуються з локального кешу, а не з реєстру операцій, користувач бачить одне число до оновлення й інше після — і перестає довіряти платформі. Ми тримаємо єдине джерело істини на сервері й віддаємо в застосунок лише підтверджені записи.
Відвал на етапі підтвердження — окремий клас збоїв: підпис, надсилання платежу, очікування відповіді банку. Тут працюють офлайн-черга, таймаути й зрозумілий сценарій відкату, якщо операція не пройшла. Далі розбираємо, як це закривається — від моделі станів і звірок до відновлення після збою.
Що дає платформа: швидкість угоди та довіра інвесторів
Угода в краудлендингу — це ланцюжок: заявка, перевірка позичальника, підписання договору, зарахування коштів, графік виплат. Коли кроки рознесені по різних сервісах і передаються вручну, між ними з’являються паузи на години, а частина заявок губиться на стику.
Ми збираємо ланцюжок в одне ядро угоди: краудлендингова платформа веде її за статусною моделлю, а кожна подія записується в незмінний реєстр угод.
Звідси зростає швидкість схвалення заявки. Інвестор і позичальник у будь-який момент бачать, на якому кроці процес, а не з’ясовують це листуванням з підтримкою.
Час від заявки до зарахування скорочується з годин до хвилин: перевірки йдуть паралельно, підписання ініціюється автоматично за їхньою готовністю, а не за дзвінком менеджера.
Довіра інвесторів тримається не на обіцянках, а на виписці. За кожною угодою доступна історія статусів, суми й розрахунок дохідності — цифри сходяться у клієнта і в бек-офісі.
Перевірку особистості та джерела коштів закриває Sumsub: верифікація проходить у застосунку, без візиту до офісу і пересилання сканів.
Зниження навантаження на підтримку — наслідок ідемпотентних операцій і повторних спроб. Звернення поділяються на два потоки: «де моя заявка» і «чому не збіглася виплата». Перший закривають статуси й сповіщення, другий — звірка реєстру й автоматичний перерахунок. Частка покинутих реєстрацій падає: людині не потрібно чекати відповіді, щоб продовжити.
З класів відмов зникають завислі підписання, дублі заявок при повторному надсиланні та розбіжності в графіку виплат — раніше на них припадала основна частина інцидентів.
Варіанти реалізації: нативний код, єдина база чи готове ядро
Вибір способу реалізації визначається тим, скільки у продукті власної логіки позики, а не кількістю екранів.
Поки це каталог і особистий кабінет, варіанти майже рівнозначні; з появою перевірки клієнта, скорингу, підписання договору, графіка платежів і вторинного ринку ціна помилки в архітектурі різко зростає.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Нативна розробка застосунку під кожну систему | Потрібні біометрія, фонові завдання, платіжні сервіси магазинів | Дві незалежні гілки коду: зміна логіки позики випускається двічі |
| Єдина кодова база з рендерингом у нативні елементи | Один інтерфейс і спільна логіка кабінету, важливіший строк випуску | Системні модулі підключаються через обгортки; нестандартний сценарій потребує окремого доопрацювання |
| Готове ядро платформи з доопрацюванням під вашу модель позики | Модель близька до типової: позики, транші, графік платежів | Межі ядра задає вендор: нетипові умови позики виносимо у власну логіку |
Як обираємо варіант
Вирішує не смак, а розбір сценаріїв: де проходить перевірка особи, хто рахує графік платежів, що відбувається при простроченні та як вивантажуються дані для регулятора.
Ми фіксуємо ці точки, звіряємо з обмеженнями кожного варіанта і лише потім обираємо спосіб реалізації — залишаючи можливість винести окремий модуль пізніше, коли модель позики зміниться.
Етапи роботи над платформою: від аудиту моделі до передачі
Краудлендингова платформа — не вітрина позик, а облікова система: заявка, скоринг, розподіл суми на частки інвесторів, договір, рух коштів через номінальний рахунок, графік платежів і прострочення.
Помилка у формулі нарахування або в правах ролі спливає одразу на сотнях угод, тому ми йдемо від аудиту моделі позики та вимог регулятора до коду, а не навпаки.
- Аудит моделі позики. Розбираємо розрахунок ставки, комісій і доходу інвестора, поведінку графіка при достроковому та частковому погашенні. Правила фіксуємо формулами й таблицями, а не в листуванні.
- Вимоги регулятора. Визначаємо обов'язковий склад даних, порядок підтвердження особи, ліміти та звітність, обмеження на публічну вітрину. Це стає частиною архітектури, а не надбудовою в кінці.
- Схема даних і ролі. Проєктуємо сутності — позичальник, інвестор, заявка, частка, платіж, договір — і матрицю доступу: хто бачить персональні дані, хто скасовує операції. Рух коштів іде через журнал операцій.
- Збірка. Реалізуємо ядро та інтерфейси, підключаємо платежі, ідентифікацію, бюро кредитних історій і повідомлення. Зовнішні сервіси тримаємо за ізольованим шаром, щоб заміна не спричиняла переписування логіки позики.
- Перевірка сценаріїв. Прогоняємо наскрізні ланцюжки: випуск позики, набір суми, часткове погашення, прострочення, повернення, скасування. Розходження з еталонним розрахунком доводимо до нуля.
- Приймання та передача. Передаємо репозиторій, документацію щодо моделі даних і регламент розгортання, навчаємо вашу команду. На виході — робоча система й зрозумілий порядок випуску змін.
Що залишається у вашому контурі після запуску та передачі
Передача — це не архів і не прощальний лист, а робочий комплект, з яким ваша команда або інший підрядник продовжує розвиток без звернень до нас. Усе перелічене оформлюється на ваші акаунти, тому доступи й права власника залишаються у вас.
- Вихідний код і збірки — репозиторій з повною історією змін, гілками та тегами релізів, конфігурації середовищ і інструкція з відтворюваної збірки: релізну версію можна зібрати заново з вихідного коду, а не шукати готовий артефакт.
- Схема інтеграцій — карта зв'язків із платіжним та ідентифікаційним контуром, сервісами перевірки позичальника і скорингу: формати обміну, послідовності викликів, точки відмови та порядок дій при недоступності зовнішнього сервісу.
- Матриця ролей і доступів — хто зі співробітників що бачить і може змінювати: позичальник, інвестор, оператор, підтримка, адміністратор. З правами на рівні операцій, щоб підтримка не могла провести платіж вручну.
- Пакет документації — опис архітектури та модулів, модель даних, інструкції з локального запуску, глосарій предметної області та журнал ухвалених рішень з обґрунтуванням.
- Регламент релізу — порядок перевірок перед викладкою, правила розгалуження, обов'язкові автотести та процедура відкату на попередню версію в магазинах застосунків.
- Регламент відновлення — резервне копіювання, цільовий час відновлення, відповідальні та покроковий сценарій на випадок збою або втрати доступу до зовнішнього сервісу.
- Реєстр сервісних доступів — облікові записи, ключі підпису, сховище секретів і власники кожного ресурсу, щоб при зміні підрядника нічого не довелося відновлювати через підтримку.
Такий комплект знімає головний ризик супроводу: новий інженер входить у проєкт за документацією, а не за пам'яттю попередньої команди.
Кейс: платформа витримала зростання угод без переробки ядра
Платформа прийшла до нас на етапі, коли кількість угод зростала швидше, ніж ядро встигало їх обробляти. Узгодження заявки тривало до шести годин: графік платежів і перевірки перераховувалися в одному процесі з каталогом заявок, тому будь-який пік гальмував решту операцій.
Частка незавершених реєстрацій сягала третини, а підтримка отримувала близько 180 звернень на тисячу угод — переважно «заявка зависла», «не бачу статус».
Що змінили в ядрі
Розрахунки платежів і перевірки винесли в окремий сервіс, пов’язаний з ядром через події: заявка проходить крок за кроком, і кожен крок можна безпечно переграти.
Додали ідемпотентні ключі на відправлення форми та підтвердження угоди — повторний запит від клієнта більше не створює дубль, а черга розподіляє пік, замість того щоб обвалювати обробник.
Картку заявки закрили кешем зі скиданням за подією, а зовнішні виклики — повтореннями з наростаючою паузою.
Після переїзду узгодження у звичайному режимі займає близько 25 хвилин, частка незавершених реєстрацій — 12%, звернень до підтримки — близько 60 на тисячу угод.
Сезонний пік із чотириразовим зростанням одночасних заявок минув без ручного втручання: відмови гасилися на рівні черги й до інвестора не доходили.
Головне — ядро залишилося незмінним. Новий сервіс підключено через події, тому автоінвестування та вторинний ринок ми поставили зверху без переписування логіки: випуск нового сценарію займав тижні, а не місяці. Саме так зростання кількості угод перестає бути ризиком для продукту.
Що робити, якщо застосунок уже випущено, а вимоги змінилися?
Випущений застосунок — не заморожений артефакт: вимоги змінюються разом із продуктом і регулюванням.
Допрацювання випущеного застосунку планується не як перезбирання, а як серія змін, сумісних з уже встановленими версіями, — стара збірка продовжує працювати, доки користувач не оновиться сам.
Головне рішення при зміні вимог — як розвести клієнт і сервер у часі. Робочих стратегій чотири, і вибір залежить від того, чи ламає правка поточний контракт обміну даними.
| Стратегія | Коли підходить | Обмеження |
|---|---|---|
| Розширення контракту: нові поля додаються, старий клієнт їх ігнорує | Правки інтерфейсу, нові статуси й дані | Нова логіка недоступна старим версіям, зростає вага відповідей |
| Паралельні версії запитів | Зміна розрахунків, платіжних сценаріїв | Подвійний код на сервері та термін зняття старої гілки |
| Примусове оновлення до мінімальної версії | Зміна ламає обмін даними | Частина користувачів не оновиться, потрібен пояснювальний екран |
| Поетапне розгортання на частину аудиторії | Ризикована зміна будь-якого характеру | Потрібні метрики за версіями та швидкий відкат |
Міграція без простою йде за методикою розширення й стиснення (Expand / Contract): спочатку додаємо нові поля, викочуємо сервер, який читає обидва формати; потім вмикаємо подвійний запис, фоновим завданням перезаповнюємо історію, перемикаємо читання на нове джерело і лише через кілька релізів видаляємо старе поле. Оновлення без зупинки сервісу тримається на тому, що на кожному кроці є робочий відкат.
Знімати підтримку старої версії — теж за даними, а не за календарем: дивимося частку активних користувачів на версіях, нижчих за мінімальну.
Поки вона вища за поріг, примусове оновлення тільки втрачає клієнтів; коли падає до одиниць відсотків, стара гілка йде з коду і супровід дешевшає.
Часті технічні сумніви та наші відповіді по суті
Сумніви щодо краудлендингової платформи впираються в чотири речі: збереження даних учасників, стик з обліковою системою банку-партнера, автоматизація перевірки позичальника та тестування платежів без ризику для живих рахунків.
Де зберігаються персональні дані учасників?
Платіжні реквізити й документи шифруються та залишаються в захищеному контурі, а застосунок працює зі знеособленими ідентифікаторами.
Доступ співробітників обмежено ролями та журналюється, ключі зберігаються окремо від даних — це той рівень, який банк-партнер приймає під час перевірки.
Як застосунок вбудовується в банківське ядро? Напряму до ядра застосунок не звертається — обмін відбувається через захищений шлюз.
Заявки, поповнення та повернення проходять зі звіркою статусу з двох сторін, тому розбіжностей між балансом у застосунку та в обліковій системі не виникає; у разі недоступності ядра операції стають у чергу.
Наскільки автоматизована перевірка позичальника? Модель оцінювання збирає дані з підключених джерел, звіряє документи та шукає ознаки дублів і шахрайських схем, видаючи бал ризику.
Пограничні заявки йдуть на ручну перевірку — це частки відсотка потоку, а інвестор щодо кожної заявки бачить фактори рішення.
Як перевіряються платіжні сценарії до запуску? Платежі проганяються в тестовому контурі банку на всіх результатах: успіх, відмова, скасування, повернення, повторна спроба, розрив зв’язку в момент списання.
Окремо перевіряються часткове виконання та повторне надсилання — саме там найчастіше з’являються подвійні списання.
Обговоримо задачу: що надіслати для оцінки та плану
Для предметної розмови не потрібен готовий том вимог. Достатньо надіслати те, що вже є: опис продукту, ролі, гроші, обмеження та поточний стан проєкту. За цим набором ми збираємо оцінку та план робіт, а не загальні міркування про ринок.
- Логіку угоди: хто виступає позичальником, хто інвестує, як рахується дохідність, що відбувається при простроченні та достроковому погашенні, чи є вторинний ринок позик.
- Грошові сценарії: поповнення та виведення, автоінвестування, розподіл платежів між інвесторами, утримання комісії платформи, повернення та часткові списання.
- Вимоги регулятора: наявність ліцензії, порядок перевірки особи інвестора та позичальника, ліміти на вкладення, склад і строки звітності.
- Зовнішні сервіси: платіжний провайдер, перевірка документів, модель оцінки позичальника, бюро кредитних історій, розсилки та повідомлення — із зазначенням, у кого зараз доступи.
- Поточний стан: чи є код, дизайн, опубліковані додатки, акаунти в магазинах і права на них, які платформи потрібні та в якому порядку.
- Обмеження підготовки до запуску: строки, прив'язані до дат ліцензії або договорів, і вимоги щодо навантаження на старті.
Цей список закриває і технічну частину, і юридичну рамку, тому після нього не доводиться повертатися з уточненнями через тиждень. Якщо чогось немає — опишіть словами, ми відновимо прогалини на дзвінку.
Обговоримо задачу. Опишіть її у вільній формі та додайте те, що вже готово, — повернемося з оцінкою, схемою етапів і планом робіт із підготовки до запуску.
