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

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

Користувач відкриває додаток, заповнює анкету за 2 хвилини, прикладає паспорт — і через 15 секунд отримує схвалення. Якщо на етапі KYC стався збій або договір не підписується через некоректний OTP, ліди йдуть до конкурентів. Ми будуємо додатки для мікрокредитів, де регуляторика, скоринг і UX працюють як єдиний механізм. Середній час схвалення — 30 секунд після скорингу, 88% користувачів повертаються для повторної позики, а вартість залучення клієнта знижується на 40% за рахунок автоматизації.

Що робить цей додаток складнішим за звичайний фінтех-продукт?

Регуляторні вимоги. В Україні — ліцензія НБУ, ідентифікація клієнта (KYC), зберігання документів, розрахунок ПСК. Архітектурні обмеження: які дані збираємо, як зберігаємо, як передаємо. Скоринг і прийняття рішень: простий варіант — REST-виклик до скорингової моделі або БКІ-інтегратору. Складніше — ML-модель на бекенді з feature engineering за поведінкою в додатку. Мобільна частина відповідає за збір даних: час заповнення заявки, правки в полях, кількість спроб — фічі для поведінкового скорингу.

Як ми реалізуємо KYC та ідентифікацію?

Онбординг і KYC. Фотографія паспорта → OCR → верифікація даних. Для українського ринку — інтеграція з провайдерами BankID НБУ, ПриватБанк ID, SenseID або іншими. Для європейського — eIDAS, Jumio або Onfido SDK. На мобільному: AVCaptureSession (iOS) / CameraX (Android) для захоплення документа, передача на бекенд для OCR, liveness check — або SDK від провайдера (FaceSDK, iDenfy), або кастомна інтеграція. Liveness check через стороннє SDK — найшвидший шлях: 95% користувачів проходять ідентифікацію за хвилину. Кастомна реалізація через ARKit / ARCore — дорожче, але без vendor lock-in.

Підписання договору. Кваліфікований або простий ЕП. Для простого — SMS OTP + згода. Документ — PDF, генерується на бекенді, підписується OTP-кодом. Зберігання підписаного PDF — в S3-сумісному сховищі, посилання в Keychain.

Disbursement та погашення. Виплата позики — переказ на картку через платіжний шлюз (LiqPay, Fondy, Stripe). Погашення — та сама інфраструктура або СЕП. Push-сповіщення (APNs / FCM) за 3/1 день до платежу — стандартна вимога регулятора.

Як обрати технологічний стек?

React Native — розумний вибір для кроссплатформенності. Нативні модулі потрібні для камери та liveness SDK. Flutter — теж хороший, але менше готових плагінів для українських платіжних шлюзів. React Native скорочує час інтеграції з LiqPay та Fondy на 40% порівняно з Flutter, а вартість розробки MVP на React Native нижча на 25-30% за рахунок готових модулів. Замовте розробку на React Native, щоб прискорити запуск MVP — зв'яжіться з нами для консультації.

Архітектура мобільної частини

┌────────────────────────────────┐
│  Onboarding Flow               │
│  ├── Phone verification (OTP)  │
│  ├── Document scan (CameraX)   │
│  ├── Liveness check (SDK)      │
│  └── KYC status polling        │
├────────────────────────────────┤
│  Loan Application              │
│  ├── Amount/term selector      │
│  ├── Scoring request           │
│  ├── Decision screen           │
│  └── Contract signing (OTP)    │
├────────────────────────────────┤
│  Account / Repayment           │
│  ├── Active loans list         │
│  ├── Payment schedule          │
│  ├── Repayment (card / SBP)    │
│  └── Push reminders            │
└────────────────────────────────┘

Чому безпека даних — критичний аспект?

Паспортні дані, номер телефону, фінансова історія — персональні дані. Закон України «Про захист персональних даних» зобов'язує зберігати їх на серверах у країні. Мобільний додаток не зберігає PII локально довше сесії — тільки токен авторизації та біометрична прив'язка в Keychain / KeyStore. Certificate pinning обов'язковий — перехоплення трафіку через MITM не повинно давати доступ до API. Використовуємо TrustKit (iOS) або OkHttp CertificatePinner (Android). Root detection — RootBeer для Android, IOSSecuritySuite для iOS — блокуємо або попереджаємо. Гарантуємо дотримання регуляторних норм при будь-якій юрисдикції.

Порівняння SDK для liveness check

Кастомне рішення потребує більше ресурсів, але виключає vendor lock-in. Для MVP з швидким запуском обирайте FaceSDK або iDenfy — окупається за рахунок швидкості виходу на ринок.

Чек-лист типових помилок при розробці додатків для мікрокредитів

• Відсутність certificate pinning — вразливість до MITM-атак.
• Зберігання PII локально (SharedPreferences, UserDefaults) — порушення закону про захист даних.
• Ігнорування розрахунку ПСК в договорі — штрафи регулятора.
• Не налаштовані push-сповіщення (APNs / FCM) — зниження повернення клієнтів.
• Відсутність deep linking (Universal Links / App Links) — втрата конверсії з реклами.

Процес роботи та терміни

Повний цикл — від 2 місяців для простого MVP без liveness check до 3 місяців для продакшн-додатку. Бюджет MVP варіюється від 400 000 до 800 000 ₴ залежно від складності інтеграцій. Вартість розраховується індивідуально після аналізу вимог. Отримайте консультацію — зв'яжіться з нами, щоб оцінити ваш проект.

Чому шифрування мобільних додатків — це не просто 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.