Разработка мобильного приложения для банкинга (FinTech)
Мобильный банк — приложение, которое не прощает ошибок. Неправильно отображённый баланс, завершённый перевод без подтверждения, потеря сессии в момент транзакции — каждый из этих сценариев стоит доверия пользователя и потенциально денег. Архитектурные решения здесь диктует безопасность, а не удобство разработки.
Аутентификация и биометрия
Начнём с того, что происходит при каждом запуске приложения. Классика: JWT в Keychain (iOS, .whenUnlockedThisDeviceOnly) / EncryptedSharedPreferences через Android Keystore. При старте — BiometricPrompt (Android) / LAContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics) (iOS).
Биометрия разблокирует ключ шифрования, который защищает refresh token — не сам токен. Если украсть encrypted blob из Keychain без приватного ключа из Secure Enclave — расшифровать невозможно. Это важно для сертификации по требованиям банков.
PIN-код как fallback: хранить hash от PIN в Keychain. Не хранить сам PIN. Не передавать PIN на сервер. Серверная аутентификация — по токену, биометрия и PIN — только локальная разблокировка сессии.
Jailbreak/Root detection — требование большинства банков. iOS: проверка наличия cydia://, mobile substrate, write access к /, fork() успешен. Android: RootBeer library или SafetyNet Attestation API / Play Integrity API (актуальный). При обнаружении root — приложение не запускается или работает в ограниченном режиме.
Переводы и транзакции
Форма перевода — технически простая, но UX-критичная. После ввода суммы и получателя — экран подтверждения с полными деталями перед отправкой. Кнопка подтверждения — с искусственной задержкой 1–2 секунды (prevents accidental double-tap). Повторная биометрическая/PIN авторизация для крупных сумм.
Идемпотентность переводов: каждый запрос перевода содержит уникальный idempotency_key (UUID, генерируется на клиенте). При потере сети и повторе запроса сервер вернёт результат первого, не создаст дубликат. Это критично — без idempotency пользователь с нестабильным интернетом может отправить перевод дважды.
История транзакций — пагинированный список, cursor-based. Группировка по дате. Поиск по описанию, сумме, получателю. Детальная страница транзакции: все детали, статус, квитанция в PDF (генерация на сервере, download на устройство).
PCI DSS и защита данных
Мобильное банковское приложение не хранит PAN карт в открытом виде нигде. Даже маскированный номер (**** 1234) — только для отображения, не для логирования. Firebase Crashlytics и Analytics — с отключённым сбором PII: FirebaseCrashlytics.crashlytics().setCrashlyticsCollectionEnabled(false) до получения явного согласия.
Network traffic — Certificate Pinning. На iOS: NSURLSession с URLSessionDelegate.urlSession(_:didReceive:completionHandler:), сравниваем SHA256 публичного ключа сертификата. На Android: OkHttp CertificatePinner. Защищает от MITM-атак даже при скомпрометированном CA.
SSL pinning обновляем при rotation сертификата через OTA-обновление конфигурации (Firebase Remote Config или собственный endpoint) — не через обновление приложения в Store. Иначе после истечения сертификата все старые версии приложения перестанут работать.
Уведомления о транзакциях
Push при каждой операции — стандарт. Требования: доставка в течение секунд, не минут. FCM с priority: high для Android, APNs с apns-priority: 10 для iOS. Критично: если push не доставлен (устройство оффлайн), при следующем открытии приложения — sync неподтверждённых транзакций.
Rich push notification: сумма, тип операции, последние 4 цифры карты. На iOS — UNNotificationServiceExtension для расшифровки end-to-end зашифрованного payload push-уведомления (банки часто шифруют sensitive данные в push).
Счета и карты
Экран главного дашборда: список счетов с балансами. Виджет карты (физическое или визуальное представление). Управление картой: блокировка, лимиты, просмотр реквизитов (CVV — только после биометрии, не хранится в памяти приложения дольше 30 секунд).
Apple Pay / Google Pay токенизация: для добавления карты в Wallet — PKAddPaymentPassViewController (iOS) / PushProvisioningActivity (Android). Это не стандартная платёжная интеграция — требует специального agreement с Visa/Mastercard и сертификации. Процесс занимает месяцы, начинать заранее.
Чат с поддержкой
In-app chat с сотрудником банка. Stream Chat SDK или Sendbird — enterprise-ready решения с историей, поиском, push при новом сообщении. Сообщения шифруются в транзите и хранятся на серверах провайдера — уточняем соответствие требованиям регулятора.
Архитектура
Нативный Swift (iOS) + Kotlin (Android) — предпочтительно для финтеха. Причина: максимальный контроль над security, нативный доступ к Secure Enclave, BiometricPrompt, Apple Pay provisioning. Дополнительно — проще проходить security audit.
Clean Architecture: Domain (Use Cases) / Data (Repository, API) / Presentation (MVVM, ViewModels). Тестируемость каждого слоя обязательна — unit tests на Use Cases, integration tests на Repository.
Flutter — приемлем для финтеха при наличии хороших Flutter-разработчиков. Ограничения: flutter_secure_storage использует Keychain/Keystore, но через уровень абстракции, который нужно аудировать. local_auth для биометрии работает корректно.
Процесс
Security architecture review → дизайн → аутентификация и biometrics → счета и баланс → переводы с idempotency → история транзакций → карты и Apple/Google Pay → push-уведомления → security audit → регуляторное согласование → публикация.
Ориентиры по срокам
MVP финтех-приложения (аутентификация, счета, переводы, история): 8–12 недель. Полноценный мобильный банк с картами, Apple/Google Pay provisioning, чатом поддержки, инвестиционным модулем: 4–8 месяцев. Стоимость — после анализа требований и security scope.