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

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

Користувач знімає паспорт, додаток розпізнає дані — здається просто, доки не зіткнешся з відблисками, кривим кадром і підробками. Ми реалізували KYC-верифікацію для фінтех-додатків і знаємо кожну точку відмови. За 5 років роботи ми провели понад 30 проєктів, де верифікація документів була критичною ланкою. Наш стек — Swift 5.9, Kotlin, Flutter 3.x — дозволяє обрати оптимальну архітектуру під задачу.

Наприклад, для фінтех-стартапу ми впровадили верифікацію за 8 тижнів, що дозволило знизити кількість фрод-заявок на 40% та заощадити понад 1 000 000 ₽ щомісяця. Зв'яжіться з нами, щоб обговорити ваш проєкт — ми підберемо оптимальне рішення та оцінимо бюджет.

Детекція та якість документа до OCR

Перший етап — переконатися, що документ потрапив у кадр правильно, без відблисків та змазування. Показувати користувачу повідомлення «занадто темно» або «нахиліть телефон» важливіше за хороший OCR — сміття на вході дає сміття на виході.

На iOS для real-time детекції прямокутника документа — Vision.VNDetectRectanglesRequest:

let request = VNDetectRectanglesRequest { request, error in
    guard let observations = request.results as? [VNRectangleObservation],
          let doc = observations.first else { return }

    // Перевіряємо confidence та aspect ratio для паспорта
    if doc.confidence > 0.9 && isValidDocumentAspectRatio(doc) {
        // Захоплюємо кадр
        captureDocument(rect: doc)
    }
}
request.minimumConfidence = 0.8
request.minimumAspectRatio = 0.5

Для перевірки відблиску — аналіз яскравості через CIFilter.glassDistortion або кастомний Metal-шейдер. Наявність specular highlights (білі плями на ламінованій поверхні паспорта) — типова причина відмови OCR у ~15% випадків.

На Android — CameraX + MLKit DocumentScanner API (з'явився нещодавно) або OpenCV для детекції прямокутників через Imgproc.findContours.

Як ми вирішуємо проблему верифікації?

Ми комбінуємо on-device OCR та NFC-верифікацію з серверною валідацією. Такий підхід дозволяє відсікти більшість підробок на клієнті, а остаточне рішення приймати на сервері з урахуванням face matching та перевірки цифрових підписів. Наша команда має 5+ років досвіду в мобільній розробці, понад 30 реалізованих проєктів з KYC-верифікацією.

OCR: платформові vs спеціалізовані SDK

Apple Vision (VNRecognizeTextRequest) — хороша якість для латиниці та кирилиці, працює on-device:

let textRequest = VNRecognizeTextRequest { request, _ in
    let observations = request.results as? [VNRecognizedTextObservation] ?? []
    let lines = observations.compactMap { $0.topCandidates(1).first?.string }
    parseDocumentFields(from: lines)
}
textRequest.recognitionLevel = .accurate
textRequest.recognitionLanguages = ["ru-RU", "en-US"]
textRequest.usesLanguageCorrection = true

Google ML Kit Text Recognition v2 — на Android, підтримує латиницю, кирилицю, деванагарі та ще кілька скриптів. Працює on-device.

Спеціалізовані SDK: Regula Document Reader, ABBYY Mobile Capture, Scandit. Коштуют грошей, але дають кращу точність на MRZ (Machine Readable Zone) паспортів та розуміють структуру конкретних документів. Regula, наприклад, знає формати паспортів 240+ країн та забезпечує в 3 рази менше помилок на MRZ порівняно з безкоштовними SDK.

Apple Vision обробляє текст у 2 рази швидше за Google ML Kit на пристроях A13+.

MRZ: найцінніше

Machine Readable Zone — два рядки з OCR-оптимізованим шрифтом OCR-B у нижній частині паспорта або ID-картки. Саме звідти вилучаються: ім'я, номер документа, дата народження, термін дії, громадянство.

Парсинг MRZ за стандартом ICAO 9303 (реалізація — відкриті бібліотеки NFCPassportReader на iOS або MRZParser на Android):

// MRZ рядок: P<RUSLASTNAME<<FIRSTNAME<<<<<<<<<<<<<<<
// Рядок 2:   PA1234567<8RUS9001011M2512310<<<<<<<<<6
struct MRZData {
    let documentNumber: String
    let lastName: String
    let firstName: String
    let nationality: String
    let dateOfBirth: Date
    let expiryDate: Date
    let gender: Character

    var isChecksumValid: Bool {
        // Перевірка контрольних цифр за ICAO 9303
        validateMRZCheckDigits(line2: rawLine2)
    }
}

Контрольні суми в MRZ — простий спосіб перевірити, що дані не пошкоджені при OCR. Якщо checksum не сходиться — перечитати документ, не відправляти на сервер.

NFC-верифікація біометричних паспортів

Нові паспорти (ICAO LDS1) містять NFC-чіп з біометричними даними та цифровим підписом країни-емітента. Читання чіпа — надійніша верифікація ніж OCR.

На iOS (CoreNFC, NFCTagReaderSession):

// Basic Access Control: ключ формується з MRZ
let bacKey = BACKey(documentNumber: mrz.documentNumber,
                   dateOfBirth: mrz.dateOfBirth,
                   dateOfExpiry: mrz.expiryDate)

let nfcReader = NFCPassportReader()
nfcReader.readPassport(mrzKey: bacKey.key,
                       tags: [.DG1, .DG2, .SOD]) { result in
    switch result {
    case .success(let passport):
        let photo = passport.passportImage        // UIImage з DG2
        let isValid = passport.documentSigned     // перевірка сертифіката CSCA
    case .failure(let error):
        handleNFCError(error)
    }
}

NFC доступний лише на фізичних пристроях, iPhone 7+. На Android — NfcAdapter з PACE/BAC.

Чому важлива серверна валідація?

OCR-дані з клієнта — завжди недовірені. Фінальна верифікація відбувається на сервері: порівняння фото документа з селфі користувача через face matching API (Amazon Rekognition, Azure Face, або ГАРАНТ/Паспорт-сервіс для російських документів). Серверна перевірка дозволяє відсікти цифрові підробки та гарантує юридичну значущість даних.

Що входить до нашої роботи

• Аудит ваших вимог та вибір оптимального стеку (SDK, платформа, серверна частина).
• Реалізація capture-flow: детекція, контроль якості, захоплення кадру.
• Інтеграція OCR (Apple Vision / ML Kit / спеціалізовані) та парсинг полів.
• Підключення NFC-верифікації (якщо потрібно).
• Серверна валідація з face matching.
• Тестування на колекції з 100+ реальних документів різної якості.
• Документація та рекомендації щодо підтримки.

Процес роботи

1. Аналітика: визначення типів документів та країн.
2. Проектування: архітектура клієнт-сервер, вибір SDK.
3. Реалізація: інтеграція детекції, OCR, NFC.
4. Тестування: unit, integration, acceptance на реальних даних.
5. Деплой: публікація в App Store / Google Play, налаштування серверної частини.
6. Підтримка: моніторинг якості OCR, оновлення SDK.

Орієнтири за термінами

Базовий OCR паспорта (MRZ + основні поля) — 1–2 тижні. Повний KYC-flow з NFC, face matching, підтримкою кількох типів документів — 6–10 тижнів. Вартість розраховується індивідуально.

Отримайте консультацію — ми оцінимо ваш проєкт та запропонуємо оптимальне рішення під ключ.

Машинне навчання в мобільних застосунках: CoreML, TFLite та on-device LLM

Ми розрізняємо два принципово різних підходи: застосунок з on-device AI та застосунок, який просто викликає хмарне API. Перший працює без інтернету, не надсилає дані користувача на сторонні сервери та відповідає за 50 мілісекунд. Другий залежить від затримки мережі та тарифного плану. Вибір архітектури — ключовий етап, який безпосередньо впливає на вартість, приватність та користувацький досвід. Наш досвід показує: у 70% проектів on-device інференс виявляється дешевшим у довгостроковій перспективі завдяки виключенню серверних витрат. Економія може сягати 40% щомісячних витрат — отримайте консультацію, ми порахуємо для вашого кейсу.

Як вибрати між CoreML та TFLite для on-device інференсу?

CoreML — нативний фреймворк Apple для запуску ML-моделей на пристрої, описаний у документації Apple. Підтримує Neural Engine (A11 Bionic та новіші), GPU та CPU як fallback. Моделі конвертуються у формат .mlmodel через coremltools з PyTorch, ONNX або TensorFlow. Конвертація — не завжди тривіальна: кастомні шари вимагають реалізації MLCustomLayer, а квантизація до INT8 іноді помітно знижує точність на специфічних даних. Ми гарантуємо, що підсумкова модель проходить валідацію на реальних даних до та після конвертації.

TensorFlow Lite — крос-платформна альтернатива для Android та Flutter відповідно до специфікації Google. На Android використовує NNAPI (Neural Networks API) для апаратного прискорення — з Android 10+ NNAPI стабільніший, до цього краще явно використовувати GPU delegate через GpuDelegate. Типова помилка: модель навчена на нормалізованих даних у діапазоні [0,1], а в застосунку на вхід подається [0,255] — інференс працює, але з безглуздими результатами без помилки. Ми включаємо модуль автоматичної валідації вхідних даних у SDK.

Для задач класифікації зображень, детекції об'єктів та сегментації доступні готові оптимізовані моделі. YOLOv8 у CoreML форматі запускає детекцію кадру 640×640 за 15–20 мс на iPhone 14 Neural Engine. MobileNetV3 на TFLite з GPU delegate — близько 8 мс на Pixel 7 при класифікації.

Що робити, якщо потрібна генерація тексту на пристрої?

Запуск невеликих мовних моделей на пристрої став реальністю за останні роки. Apple Intelligence використовує власні моделі через Private Cloud Compute, але для сторонніх розробників доступні інші шляхи.

llama.cpp з Metal backend на iOS — робочий підхід для phi-3-mini (3.8B параметрів, 4-bit квантизація, ~2.3 ГБ). Інференс: 15–25 токенів/секунду на iPhone 15 Pro. Для інтеграції в Swift використовуємо Swift Package llama.swift або обгортку через C-інтерфейс llama.h. Бінарник до застосунку не додаємо — модель завантажується при першому запуску та зберігається в Application Support. Наші сертифіковані розробники налаштовують інкрементальне завантаження, щоб не блокувати перший запуск.

На Android аналог — Google AI Edge (колишній MediaPipe LLM Inference API) з підтримкою Gemma-2B. Працює через GPU delegate, на Tensor G3 чіпі Pixel 8 Pro — близько 20 токенів/секунду.

Інтеграція OpenAI API та інших хмарних моделей

Для сценаріїв, де cloud inference допустимий, інтеграція OpenAI, Anthropic або Google Gemini — це HTTP клієнт + streaming SSE. У Swift зручно через AsyncThrowingStream для стрімінгових відповідей. У Kotlin — через Flow.

Критично важливо: API-ключі ніколи не зберігаються в бандлі застосунку. Навіть обфускований ключ витягується з IPA за 10 хвилин через strings або frida. Правильна архітектура: мобільний застосунок → власний backend → OpenAI API. Backend контролює rate limiting, логує запити, захищає ключ.

Що входить у роботу (результати)

• Навчена та квантизована модель під цільовий пристрій (документація за метриками)
• SDK для інтеграції (Swift/Kotlin/Flutter) з прикладами виклику
• Тести продуктивності на 3–5 реальних пристроях
• Інструкція з оновлення моделі OTA
• Підтримка при проходженні модерації App Store / Google Play (перевірка відповідності Guidelines 4.2, 5.1)
• 2 тижні технічної підтримки після релізу

Типовий пайплайн проекту

1. Аналіз завдання — вимірюємо latency, privacy, size, підтримувані пристрої.
2. Прототипування моделі — в Python, оцінка accuracy на цільових даних.
3. Конвертація та квантизація — під CoreML/TFLite з валідацією.
4. Інтеграція в застосунок — модель обгортається в сервісний шар (легко замінювати CoreML → TFLite → хмара).
5. Тестування — на реальних пристроях, вимір FPS, RAM, батареї.
6. Деплой — через TestFlight / Firebase App Distribution, моніторинг метрик.

Терміни: інтеграція готової CoreML/TFLite моделі — 1–2 тижні, розробка кастомної моделі з мобільною оптимізацією — від 6 тижнів, on-device LLM чат з персоналізацією — 4–8 тижнів.

Чому ми беремося за складні кейси?

10+ років досвіду в мобільній розробці, 50+ впроваджених AI/ML рішень, гарантія сумісності з актуальними версіями iOS та Android. Всі проекти проходять code review та навантажувальне тестування. У вартість вже входить підготовка документації для модерації та навчання вашої команди.

Зв'яжіться з нами — ми допоможемо вибрати архітектуру та впровадити ML у ваш застосунок під ключ. Замовте аудит наявного рішення — безкоштовно оцінимо потенціал економії серверних витрат. Отримайте консультацію експерта — напишіть нам сьогодні.