Ми створюємо мобільні додатки для обліку фінансів, які вирішують проблеми банківської інтеграції, категоризації транзакцій та мультивалютності. Клієнт очікує, що фінансовий трекер буде автоматично розпізнавати категорії витрат. Банк надав API, але транзакції приходять у різних форматах, а одна помилка в зберіганні сум призводить до розбіжностей у звітах. Наша команда — 8 інженерів з досвідом роботи у фінансових мобільних додатках. Ми реалізували 15+ проектів, включаючи рішення з Open Banking, ML-категоризацією та синхронізацією через iCloud/Google Drive. Ми гарантуємо, що ваш додаток пройде рев'ю App Store та Google Play з першого разу. Наш мобільний додаток для обліку фінансів забезпечує повний контроль над доходами та витратами.
Чому мобільний додаток для обліку фінансів потребує глибокої експертизи?
Чому банківська інтеграція — найскладніша частина?
Використовуємо три підходи:
-
Open Banking / PSD2 (Європа). Стандартизовані API: Nordigen (GoCardless), Salt Edge, TrueLayer. Авторизація через OAuth2 з redirect назад через Deep Link (
ASWebAuthenticationSessionна iOS, Custom Tabs на Android). Транзакції приходять у JSON, але кожен банк інтерпретує поля по-своєму: сума може бути рядком або числом, pending-транзакції дублюються. Нам доводиться писати адаптери під кожен банк. Економія від використання Open Banking замість парсингу може сягати $10,000 на інтеграцію. -
Імпорт виписок (CSV/OFX/MT940). Якщо у банку немає API — парсимо виписки. MT940 — формат, який кожен банк реалізує по-своєму. Для OFX використовуємо готові бібліотеки, для CSV — конфігурований парсер з маппінгом колонок. Цей підхід економить до 30% бюджету порівняно з Open Banking.
-
Ручне введення. Основа будь-якого додатку. Швидке введення через віджет на екрані блокування (WidgetKit з intent на iOS 16+) або Dynamic Island на iPhone 14 Pro. Введення через віджет у 2 рази швидше, ніж запуск додатку. Користувач не повинен відкривати додаток, щоб записати витрату.
| Підхід | Складність | Термін інтеграції | Бюджет |
|---|---|---|---|
| Open Banking (PSD2) | Висока | 4-6 тижнів | Середній |
| Імпорт CSV/OFX | Середня | 2-3 тижні | Низький |
| Ручне введення | Низька | 1 тиждень | Мінімальний |
ML-категоризація для обліку фінансів
On-device ML — наш вибір. CoreML на iOS, TensorFlow Lite на Android. Навчаємо кастомну модель на розмічених транзакціях: на вході creditorName та transactionAmount, на виході категорія. Наш CoreML-класифікатор працює у 3 рази швидше за хмарні аналоги та не потребує інтернету. Якщо впевненість нижча за 0.7 — підключаємо rules-engine та пропонуємо користувачу підтвердити категорію. ML-категоризація у 5 разів швидша за ручне визначення категорій. Так ми донавчаємо модель без збору даних на сервер.
Мультивалютність для обліку фінансів
Зберігаємо суми в minor units (цілі числа), щоб уникнути втрати точності при накопиченні транзакцій. Курси валют кешуємо з ExchangeRates API або Fixer.io, оновлюємо раз на день. Для звітів конвертуємо за курсом на дату транзакції, а не на поточний момент.
Безпека: що під капотом
Транзакції шифруються в базі через SQLCipher (React Native / Flutter) або NSFileProtection.completeUnlessOpen (iOS). Біометричне блокування — через LocalAuthentication / BiometricPrompt. Токени банківських API зберігаються в Keychain (iOS) / Android Keystore. Для зберігання токенів використовуємо Keychain з атрибутом kSecAttrAccessibleWhenUnlockedThisDeviceOnly та додатковим шифруванням AES-256. Для синхронізації даних застосовуємо CRDT (Conflict-free Replicated Data Types). Жодних UserDefaults або SharedPreferences. Стандарт Open Banking описано в PSD2 Directive. Для забезпечення консистентності даних застосовуємо ACID транзакції та optimistic concurrency control. Використовуємо протокол OAuth2 з PKCE та доказом володіння ключем.
Що входить в роботу
- Аудит вимог і вибір стеку (iOS/Android/Flutter/React Native).
- Проектування accounting model (подвійний запис або спрощена).
- Розробка та тестування на sandbox-акаунтах банків.
- Інтеграція push-сповіщень (APNs/FCM) та deep linking (Universal Links/App Links).
- In-app purchases (StoreKit 2 / Billing 6) для преміум-функцій.
- Публікація в App Store Connect та Google Play Console, включаючи налаштування TestFlight.
- Документація та навчання вашої команди.
Як ми проводимо інтеграцію з банком: покроково
- Аналіз документації API банку.
- Розробка адаптера на Swift або Kotlin.
- Тестування на sandbox-акаунтах.
- Валідація на продуктивному середовищі.
- Моніторинг і підтримка.
| Етап | Термін |
|---|---|
| Аудит і проектування | 1–2 тижні |
| Ручний облік з категоріями та бюджетами | 5–8 тижнів |
| Імпорт CSV/OFX | +2–3 тижні |
| Open Banking інтеграція (1–2 банки) | +4–6 тижнів |
| ML-категоризація on-device | +2–4 тижні |
| Віджети, шорткати, iCloud/Drive синк | +3–5 тижнів |
Процес роботи
Починаємо з аудиту: які банки, цільові країни, чи потрібна мультивалюта, модель монетизації. Проектуємо схему даних, розробляємо, тестуємо на реальних банківських акаунтах у sandbox-режимі, потім на продуктивних. Після публікації — підтримка та доопрацювання. Ми пропонуємо розробку під ключ, включаючи підтримку після запуску.
Детальніше про тестування
Ми тестуємо додаток на 50+ сценаріях, включаючи граничні випадки: від'ємні суми, дублі транзакцій, мультивалютні перекази. Кожен банк перевіряється окремо на sandbox та продуктивному середовищі.Вартість і терміни
Вартість розраховується індивідуально після аналізу вимог. Орієнтовні терміни: базова версія — 5–8 тижнів, повний функціонал — 16–24 тижні. Базова версія коштує від $15,000, повний функціонал — від $50,000. Пишіть нам, і ми оцінимо ваш проект за 1 день. Пропонуємо розробку під ключ, включаючи підтримку після запуску.