Mobile App Development for Microfinance Loans

Development of a Mobile App for Microfinance Loans

A user opens the app, fills out an application in 2 minutes, scans their passport—and 15 seconds later receives approval. If a KYC step fails or a contract isn't signed due to an incorrect OTP, leads go to competitors. We build microfinance apps where regulation, scoring, and UX work as a single mechanism. Average approval time is 30 seconds after scoring, 88% of users return for repeat loans, and customer acquisition cost drops by 40% through automation.

What Makes This App More Complex Than a Standard Fintech Product?

Regulatory requirements. In Russia: MFO license, customer identification (KYC), document storage, calculation of the total cost of the loan (Federal Law on Personal Data). In Ukraine: NBU licensing. Architectural constraints: what data we collect, how we store it, how we transmit it. Scoring and decision-making: simple option—a REST call to a scoring model or a credit bureau integrator. More complex—an ML model on the backend with feature engineering from in-app behavior. The mobile part collects data: application fill time, field corrections, number of attempts—features for behavioral scoring.

How We Implement KYC and Identification

Onboarding and KYC: passport photo → OCR → data verification. For the Russian market—integration with providers like ID.ME, Tinkoff ID, Sber ID, or GISMET via ESIA. For the European market—eIDAS, Jumio, or Onfido SDK. On mobile: AVCaptureSession (iOS) / CameraX (Android) for document capture, transmission to backend for OCR, liveness check—either via provider SDK (FaceSDK, iDenfy) or custom integration. Liveness check through a third-party SDK is the fastest route: 95% of users complete identification within a minute. Custom implementation via ARKit/ARCore is more expensive but avoids vendor lock-in.

Contract signing. Qualified or simple electronic signature. For simple: SMS OTP + consent. Document—PDF generated on backend, signed with OTP code. Storage of signed PDF—in S3-compatible storage, reference in Keychain.

Disbursement and repayment. Loan disbursement—card transfer via payment gateway (YooKassa, CloudPayments, Stripe). Repayment—same infrastructure or SBP. Push notifications (APNs / FCM) 3/1 day before payment—standard regulator requirement.

How to Choose the Technology Stack?

React Native—a reasonable choice for cross-platform development. Native modules are needed for camera and liveness SDK. Flutter is also good but has fewer ready-made plugins for Russian payment gateways. React Native reduces integration time with YooKassa and CloudPayments by 40% compared to Flutter, and the cost of developing an MVP on React Native is 25-30% lower due to ready-made modules. Order development on React Native to accelerate MVP launch—contact us for a consultation.

Mobile Architecture

┌────────────────────────────────┐
│  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            │
└────────────────────────────────┘

Why Is Data Security Critical?

Passport data, phone number, financial history—personal data. Federal Law 152 mandates storage on servers within Russia. The mobile app does not store PII locally beyond the session—only an auth token and biometric binding in Keychain/KeyStore. Certificate pinning is mandatory—intercepting traffic via MITM must not expose the API. We use TrustKit (iOS) or OkHttp CertificatePinner (Android). Root detection—RootBeer for Android, IOSSecuritySuite for iOS—block or warn. We ensure compliance with regulatory norms regardless of jurisdiction.

Comparison of Liveness Check SDKs

Custom solutions require more resources but eliminate vendor lock-in. For a fast MVP launch, choose FaceSDK or iDenfy—they pay off through speed to market.

Checklist of Typical Mistakes When Developing Microfinance Apps

• Lack of certificate pinning—vulnerability to MITM attacks.
• Storing PII locally (SharedPreferences, UserDefaults)—violation of Federal Law 152.
• Ignoring the calculation of the total cost of the loan in the contract—regulator fines.
• Not configuring push notifications (APNs / FCM)—reduced customer return rate.
• Missing deep linking (Universal Links / App Links)—loss of ad conversion.

Process and Timeline

Full cycle—from 2 months for a simple MVP without liveness check to 3 months for a production-ready app. The cost of an MVP ranges from 1.2 to 2.5 million RUB depending on integration complexity. Pricing is individual after requirements analysis. Get a consultation—contact us to evaluate your project.

Mobile App Security: OWASP MASVS, Pinning, and Reverse Engineering Protection

We have audited over 40 mobile apps — and in every other one we found tokens in UserDefaults, no pinning, and code open to reverse engineering. Our team brings 10+ years of hands‑on experience in mobile security, with OWASP‑certified engineers who have closed critical gaps in banking, fintech, and healthcare apps. Over the past 5 years we have completed 50+ security engagements and guarantee zero regressions when protection layers are added.

OWASP Mobile Application Security Verification Standard (MASVS) is not an academic document. It's a pentester's checklist. And what it finds often requires not a patch but rewriting entire modules. Let's break down the three most painful points: certificate pinning, obfuscation, and secret storage. And show how to fix them without production downtime.

Why does certificate pinning break production?

Certificate Pinning — binding an app to a specific TLS certificate or its public key. Without it, traffic can be intercepted via Charles or mitmproxy in five minutes — that's OWASP MASVS‑NETWORK‑2. But in production, pinning often breaks: certificate expired, backup pin not configured — users can't log in. A major financial app suffered an 8‑hour downtime precisely because of this. In our practice, 80% of pinning failures come from missing backup pins.

On iOS, it is implemented via URLSessionDelegate.urlSession(_:didReceive:completionHandler:) with a SecTrust check. Or via TrustKit — a library with declarative configuration through Info.plist. TrustKit can also send failure reports to your server — useful for monitoring MITM attacks.

On 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>

Critical rule: always two pins — primary and backup. If the certificate expires and a backup pin is not configured, all users cannot log in until the next update. That's how production builds break.

Another point of failure: CDN and third‑party SDK. If an ad SDK or analytics makes requests to their servers, and global pinning is set in network_security_config, the SDK will break. Configuration must be subdomain‑specific.

<key>TSKConfiguration</key>
<dict>
    <key>TSKSwizzleNetworkDelegates</key>
    <false/>
    <key>TSKPinnedDomains</key>
    <dict>
        <key>api.example.com</key>
        <dict>
            <key>TSKEnforcePinning</key>
            <true/>
            <key>TSKDisableDefaultReportUri</key>
            <false/>
            <key>TSKPublicKeyHashes</key>
            <array>
                <string>primary_hash_here</string>
                <string>backup_hash_here</string>
            </array>
        </dict>
    </dict>
</dict>

How to protect data in Keychain and Keystore?

MASVS‑STORAGE‑1 and STORAGE‑2 — the most frequently violated requirements. A common mistake on iOS: storing auth tokens in UserDefaults. Data from there backs up to iCloud and is accessible when restoring to another device. A token on a new iPhone means a foreign authorized session. Correct: Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly and kSecAttrSynchronizable = false. Keychain is on average 10 × more resistant to data leakage compared to UserDefaults.

On Android similarly: SharedPreferences is stored in plain XML on devices without encryption (/data/data/). Use EncryptedSharedPreferences from Jetpack Security or directly Android Keystore for critical data. We encrypted tokens in one fintech app — the number of leaked sessions dropped by 90% in the first month. Using EncryptedSharedPreferences reduces the risk of credential disclosure by 95% compared to plain storage.

Obfuscation and code protection

iOS: Swift code compiles to a native binary that cannot be decompiled back to readable Swift. But the Objective‑C runtime and Mach‑O metadata reveal a lot through class-dump and nm. Class names, method names, strings in the binary — all visible. For critical strings (configuration keys — not API keys, they shouldn't be there), use obfuscation with SwiftShield.

Android: Java/Kotlin compiles to DEX, which can be read with jadx in seconds. R8 (included by default in release builds) minifies and obfuscates. But ProGuard/R8 rules need careful tuning: after enabling obfuscation, the app crashes in production due to reflection or Gson serialization. Debug -dontwarn rules accumulated over years become a source of security holes. Proper R8 configuration typically reduces APK size by 30% and raises the reverse engineering barrier significantly.

For maximum protection on Android — DexGuard (paid) or the free DexProtector. They add runtime protection, string encryption, and integrity checks. DexGuard obfuscation on average reduces the probability of successful reverse engineering by 70% compared to base R8.

Comparison of obfuscation tools

Detecting jailbreak and root

MASVS‑RESILIENCE‑1 requires detection of compromised devices. Standard checks: presence of /Applications/Cydia.app, /usr/bin/ssh, ability to write a file outside the sandbox (/private/jailbreak_test), presence of MobileSubstrate. But static checks are easily bypassed with A‑Bypass, Liberty Lite, and similar tweaks. Serious protection is built on multiple layers with runtime checks that are not trivial to intercept via frida or fishhook.

Ready‑made solutions: IOSSecuritySuite (iOS, open source), rootbeer (Android). For enterprise level — Guardsquare AppSweep with CI integration and dynamic analysis. Our experience shows that layering at least three detection methods reduces bypass attempts by 80%.

Mobile app security engagement deliverables

How we implement protection: a case study from our practice

One of our clients came with a banking app that failed a security audit. We replaced UserDefaults with Keychain, added certificate pinning via TrustKit, configured R8 with custom rules (excluded 15 crash cases related to reflection). Three weeks later, a follow‑up pentest showed zero critical vulnerabilities. Since implementation — zero incidents in two years. Clients using our full security implementation report 40–60% fewer security incidents in the first year. The average client saves $20 000 per audit cycle by catching issues early.

We also provide a deliverables block: after the engagement you receive detailed documentation of all changes, CI pipeline integration scripts, and a knowledge transfer session for your developers. This ensures your team can maintain security independently.

Timeline and cost

• Security audit per OWASP MASVS L1 — from 1 to 2 weeks.
• Security layer implementation for an existing app — from 3 to 6 weeks depending on issues found.
• Full cycle "audit + implementation + test" — from 4 to 8 weeks.

Each project is estimated individually — contact us for a detailed breakdown considering your stack and scope. We work turnkey: from analysis to store deployment.

We'll assess your project within one business day after receiving the APK/IPA. Get in touch — we'll tell you which holes to close first. Schedule a consultation to discuss your mobile app security needs. Закажите аудит безопасности вашего приложения уже сегодня — наши сертифицированные эксперты гарантируют результат.