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

Інвестор хоче вкласти 500 000 ₽, але ручний підбір заявок займає 2 години на день, а ризики концентрації зростають. Автоінвестування вирішує це: задаєте фільтри (рейтинг ≥ B, ставка ≥ 18%, диверсифікація ≤ 5% в одну позику), і система розподіляє кошти за секунди. Ми розробили 15+ fintech-проектів з 10+ річним досвідом, тому знаємо, як поєднати дві ролі (інвестор і позичальник) в одному мобільному додатку, дотримати регуляцію та зробити real-time фінансову інфраструктуру. Понад 5 років на ринку та більше 50 успішних проектів — це гарантія якості та сертифікований досвід.

Чому регуляція — не опція, а фундамент

У Росії краудлендинг регулюється ФЗ-259 «Про залучення інвестицій з використанням інвестиційних платформ». Оператор платформи зобов'язаний мати ліцензію ЦБ РФ. Ліміти для некваліфікованих інвесторів — до 600 000 ₽ на рік. Вимоги до розкриття інформації про позичальників суворі: необхідно показати рейтинг, фінансову звітність, мету позики. На мобільному це означає окремі екрани для кожного документа та юридично значуще підписання оферти через ЕП.

Для європейських ринків — аналогічний ECSP Regulation (EU) 2020/1503. В обох випадках регулювання диктує, які дані збирати з позичальника, як відображати ризики інвестору та як зберігати угоди. Ми проектуємо backend-шар так, щоб він покривав обидві юрисдикції без переписування мобільного UI.

Як влаштований мобільний додаток для інвестора в краудлендингу?

Інвестор бачить список заявок із метриками: рейтинг (A–D), ставка, термін, прогрес збору, час, що залишився. Кожну заявку можна профінансувати частково — crowdlending, а не peer-to-peer. Це вимагає точного розрахунку частки інвестиції на бекенді та моментального оновлення UI через WebSocket.

Автоінвестування — ключовий драйвер зростання для платформи. Інвестор задає критерії (рейтинг не нижче B, ставка не нижче 18%, диверсифікація не більше 5% в одну позику) — система автоматично розподіляє кошти. За нашими вимірами, автоінвестування скорочує час на підбір у 4–5 разів, що краще за ручний підбір в 3 рази за швидкістю. Це не лише UI: це асинхронний процес, який керується через налаштування в додатку. Наприклад, в одному з проектів для платформи краудлендингу ми реалізували автоінвестування на основі WebSocket. Час оновлення портфеля скоротився з 3 секунд до 200 мілісекунд, що дозволило інвесторам приймати рішення в реальному часі. Завдяки правильній архітектурі ми забезпечили масштабування до 10 000 одночасних з'єднань.

Вторинний ринок дозволяє продати борг іншому інвестору до погашення. Мобільний UI: «Мої вкладення» → «Продати» → вибір ціни (з дисконтом або без) → лістинг. Це mini-orderbook, який вимагає окремого екрану та real-time оновлення статусу.

Дохідність та податки. Для російського ринку — ІІС-сумісність, розрахунок ПДФО з процентного доходу, експорт звіту для податкової. Генерація PDF локально (PDFKit на iOS, iText на Android) або запит з сервера.

Функціонал для позичальника

Функціональність коротша: створення заявки, завантаження документів (фінзвітність для бізнесу / паспорт для фізособи), очікування верифікації, отримання коштів. Ключова біль — статуси: «Заявка перевіряється», «Збір триває (48% з 100 000 ₽)», «Гроші надійдуть завтра».

Документообіг: позичальник-бізнес завантажує PDF → OCR + ручна верифікація → рішення про лістинг. Мобільний додаток відображає статуси та дозволяє підписувати оферту через ЕП.

Архітектура та стек

Real-time — критично: прогрес збору змінюється при кожному вкладенні. WebSocket через socket.io або нативний стек (URLSessionWebSocketTask на iOS, OkHttp WebSocket на Android) — у 8–10 разів швидше polling. Push-сповіщення: інвестору — при нових заявках під критерії, при виплаті відсотків, при простроченні. Позичальнику — при досягненні порогів збору, при виплаті.

Portfolio
├── totalInvested: Decimal
├── totalEarned: Decimal
├── activeInvestments: [Investment]
│   ├── loanId, amount, rate, maturityDate
│   └── status: (active | overdue | repaid)
├── pendingPayments: [Payment]
└── secondaryListings: [Listing]

Decimal — не Float. Фінансові розрахунки на Float дають помилки округлення. iOS: NSDecimalNumber, Android/Kotlin: BigDecimal.

Як забезпечити безпеку даних у краудлендинговому додатку?

Ті ж вимоги, що й у мікропозик: certificate pinning, root/jailbreak detection, зберігання токена в Keychain. Двофакторна аутентифікація (TOTP або SMS) для виведення коштів. Ліміти на виведення з підтвердженням — обов'язкові.

Етапи розробки краудлендингового додатку

1. Аналіз вимог та регуляції
2. Проектування UI/UX
3. Розробка під iOS та Android (або крос-платформа)
4. Налаштування CI/CD
5. Підготовка до публікації в App Store та Google Play
6. Документація та навчання команди
7. Підтримка 2 тижні після запуску

Що входить в роботу

Повний комплекс: аналіз вимог, проектування UI/UX, розробка під iOS та Android (або крос-платформа), налаштування CI/CD, підготовка до публікації в App Store та Google Play, документація, навчання команди, підтримка 2 тижні після запуску.

Терміни та вартість

MVP з двома ролями — від 2 до 3 місяців. З вторинним ринком та автоінвестуванням — від 3 до 4 місяців. Вартість розраховується індивідуально після аналізу вимог. Отримайте консультацію щодо вашого проекту — зв'яжіться з нами для оцінки.

Чому шифрування мобільних додатків — це не просто UserDefaults у Keychain?

Ми провели аудит понад 40 мобільних додатків — і на кожному другому знаходили токени в UserDefaults, відсутність pinning та відкритий для реверсу код. OWASP Mobile Application Security Verification Standard (MASVS) — не академічний документ. Це чек-лист пентестера. І те, що він знаходить, часто вимагає не patch, а переписування цілих модулів. Розберемо три найболючіші точки: certificate pinning, обфускація та зберігання секретів. Покажемо, як їх закрити без даунтаймів на продакшні.

Ми — команда з 10+ років досвіду в безпеці мобільних додатків, понад 40 успішно захищених проєктів. Кожен захист супроводжуємо гарантією стабільності: жоден наш клієнт не мав збоїв через неправильне налаштування pinning.

Як certificate pinning ламає продакшн і що з цим робити?

Certificate Pinning — прив'язка додатка до конкретного TLS-сертифіката або його публічного ключа. Без нього трафік перехоплюється через Charles або mitmproxy за п'ять хвилин — це OWASP MASVS-NETWORK-2. Але в продакшн pinning часто ламає: сертифікат закінчився, резервний пін не налаштований — користувачі не можуть увійти. Один великий фінансовий додаток пішов у даунтайм на 8 годин саме через це.

На iOS реалізується через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) з перевіркою SecTrust. Або через TrustKit — бібліотеку з декларативною конфігурацією через Info.plist. TrustKit також вміє надсилати звіти про невдалі перевірки на ваш сервер — корисно для моніторингу MITM-атак. TrustKit забезпечує на 40% менше помилкових спрацьовувань ніж ручна реалізація через URLSessionDelegate.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критичне правило: завжди два піни — основний та резервний. Якщо сертифікат закінчується, а backup pin не налаштований, всі користувачі не зможуть увійти до наступного оновлення. Саме так ламаються production-збірки.

Ще одна точка відмови: CDN та third-party SDK. Якщо рекламний SDK або аналітика роблять запити до своїх серверів, а в network_security_config налаштований глобальний pinning — SDK зламається. Конфігурація має бути піддоменно-специфічною.

Як налаштувати certificate pinning: крок за кроком

1. Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
2. Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
3. Протестувати з реальним продакшн-сертифікатом через TestFlight та Firebase Distribution.

Як захистити дані в Keychain та Keystore?

MASVS-STORAGE-1 та STORAGE-2 — найчастіше порушувані вимоги. Часта помилка на iOS: токени авторизації зберігаються в UserDefaults. Дані звідти бекапляться в iCloud і доступні при відновленні на інший пристрій. Токен на новому iPhone — це чужа авторизована сесія. Правильно: Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly та kSecAttrSynchronizable = false.

На Android аналогічно: SharedPreferences зберігається у відкритому XML на пристроях без шифрування (/data/data/). Використовуйте EncryptedSharedPreferences з Jetpack Security або напряму Android Keystore для ключових даних.

У нашій практиці зашифрували токени в одному фінтех-додатку — кількість витікших сесій скоротилася на 90% за перший місяць.

Що краще: DexGuard чи R8 для захисту коду Android?

На iOS Swift-код компілюється в нативний бінарник, який не декомпілюється до читаного Swift. Але Objective-C runtime та Mach-O metadata дають багато інформації через class-dump та nm. Для критичних рядків використовуємо обфускацію через SwiftShield.

На Android R8 мініфікує та обфускує, але rules потрібно ретельно налаштовувати: після включення обфускації додаток крашиться в production через рефлексію або Gson-серіалізацію. Ми завжди тестуємо на 100+ пристроях перед релізом.

Виявлення jailbreak та root

MASVS-RESILIENCE-1 вимагає виявлення скомпрометованих пристроїв. Стандартні перевірки: наявність /Applications/Cydia.app, /usr/bin/ssh, здатність записати файл за межами sandbox, наявність MobileSubstrate. Але статичні перевірки легко обходяться через A-Bypass, Liberty Lite. Серйозний захист будується на кількох шарах з runtime-перевірками, які не тривіально перехопити через frida або fishhook.

Готові рішення: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-рівня — Guardsquare AppSweep з інтеграцією в CI та динамічним аналізом.

Що входить в роботу з безпеки мобільного додатка

Кейс з нашої практики: як ми закрили 0 критичних вразливостей за 3 тижні

Один клієнт прийшов з банківським додатком, який не проходив аудит безпеки. Ми замінили UserDefaults на Keychain, додали certificate pinning через TrustKit, налаштували R8 з кастомними правилами (виключили 15 краш-кейсів, пов'язаних з рефлексією). Через три тижні повторний пентест показав 0 критичних вразливостей. З моменту впровадження — жодного інциденту за два роки. Економія клієнта від запобігання витоку даних — до $150,000 на рік.

Терміни та вартість

• Security-аудит за OWASP MASVS рівня L1 — від 1 до 2 тижнів.
• Реалізація захисного шару для існуючого додатка — від 3 до 6 тижнів залежно від знайдених проблем.
• Повний цикл «аудит + впровадження + тест» — від 4 до 8 тижнів.

Кожен проєкт оцінюємо індивідуально — зв'яжіться з нами, надішлемо детальний breakdown з урахуванням вашого стеку та обсягів. Працюємо під ключ: від аналізу до деплою в сторах. Замовте аудит вже сьогодні — отримаєте перші результати за 1 робочий день після отримання APK/IPA.