Как мы разрабатываем финтех-приложения: от требований до релиза

Почему финтех — это отдельная категория разработки

Разработать приложение для записи в салон и разработать финтех-продукт — это принципиально разные задачи. Не по технологиям. По цене ошибки.

В обычном приложении баг — это неудобство. В финтехе баг — это потерянные деньги пользователя, регуляторный штраф или утечка персональных данных. Именно поэтому стандарты, процессы и архитектурные решения в финтехе принципиально отличаются от любой другой категории продуктов.

Рынок финтех-услуг в Центральной Азии растёт быстро. Только в Узбекистане объём безналичных платежей в 2024 году превысил 600 трлн сумов, а число пользователей мобильного банкинга выросло до 18 млн человек. Click, Payme, Humo, UZCARD — это уже не стартапы, это инфраструктура. И вокруг неё строятся сотни новых продуктов.

Мы разрабатываем финтех-решения с 2019 года. За это время прошли путь от платёжных виджетов до полноценных необанков. В этой статье — честный разбор того, как выглядит этот процесс изнутри.

Этап 1: сбор требований и анализ

Финтех-проект начинается не с дизайна и не с кода. Он начинается с вопросов, ответы на которые определяют всё остальное.

Регуляторные вопросы первыми. Прежде чем проектировать функционал, нужно понять: какую лицензию требует продукт? Если приложение работает с деньгами пользователей — это одна история. Если только отображает баланс из банковского API — другая. В Узбекистане регулятором является Центральный банк, и его требования определяют архитектуру на самом раннем этапе.

Бизнес-модель определяет архитектуру. P2P-переводы, кредитный скоринг, управление инвестициями, страховые продукты — у каждого сценария своя логика, свои интеграции и свои требования к безопасности.

На этом этапе мы проводим:

Один вопрос, который мы задаём на каждом вводном совещании: «Что произойдёт, если транзакция завершится на полпути?» Ответ на него определяет 30% архитектурных решений.

Этап 2: архитектура и выбор стека

Финтех не прощает монолитов, которые росли без плана. Архитектура закладывается один раз — и потом с ней живут годами.

Микросервисы или монолит? Для MVP и небольших финтех-продуктов мы часто выбираем модульный монолит — это быстрее и дешевле при старте, но с чёткими границами модулей. Для нагрузочных продуктов с тысячами транзакций в минуту — микросервисы с независимым масштабированием критичных сервисов: платежи, авторизация, уведомления.

Стек для финтех-проектов, который работает:

Отдельное решение — где хранить данные. В Узбекистане персональные данные граждан по закону должны храниться на серверах внутри страны. Это требование влияет на выбор облачного провайдера или физического размещения серверов.

Этап 3: безопасность как основа, а не надстройка

В большинстве проектов безопасность добавляют в конце — «прикрутим перед релизом». В финтехе это недопустимо. Безопасность проектируется с первого дня.

Аутентификация и авторизация. Минимальный стандарт для финтеха — JWT + refresh token с коротким временем жизни, двухфакторная аутентификация по SMS или TOTP, биометрия через Face ID / Touch ID на мобильных устройствах. Для корпоративных продуктов — RBAC с детальными правами на каждое действие.

Шифрование данных. Персональные данные и финансовая информация шифруются в покое (AES-256) и при передаче (TLS 1.3). Ключи хранятся отдельно от данных — в HSM или vault-решениях.

Защита транзакций. Каждая финансовая операция проходит через:

• Идемпотентность — повторный запрос не создаёт дублирующую транзакцию
• Атомарность — транзакция либо выполняется полностью, либо откатывается
• Аудит-лог — неизменяемая запись каждого действия с пользователем, временем и IP

Защита от мошенничества. Rate limiting на все критичные эндпоинты, детектирование аномальных паттернов поведения, блокировка после N неудачных попыток авторизации.

Penetration testing — не опция. Перед каждым крупным релизом мы проводим внешний пентест. Это не бюрократия — это страховка, которая стоит $1 000–3 000 и предотвращает инциденты ценой на порядок дороже.

Этап 4: интеграции с банками и платёжными системами

Финтех без интеграций — это просто красивый интерфейс. Реальная ценность продукта создаётся на стыке с банковской и платёжной инфраструктурой.

Платёжные системы Узбекистана. Click, Payme и Humo — три основных шлюза для операций в сумах. У каждого своя документация, своя модель подключения и свои требования к верификации продавца. Стандартный срок подключения — 2–4 недели с учётом юридических согласований.

UZCARD и UzPayNet — инфраструктура межбанковских переводов. Подключение к ней требует отдельного договора и технической интеграции через защищённые каналы.

Open Banking API. Банки Узбекистана постепенно открывают API в рамках инициатив ЦБ. Это позволяет финтех-продуктам получать баланс счёта, историю транзакций и инициировать переводы — с согласия пользователя.

Каждую интеграцию мы проходим по одному алгоритму:

1. Изучение документации и sandbox-окружения
2. Реализация в тестовой среде с mock-данными
3. Интеграционное тестирование в sandbox провайдера
4. Нагрузочное тестирование на граничных сценариях
5. Выход в прод с мониторингом первых транзакций

Типичная ошибка: пропустить пункты 3 и 4 ради скорости. Это почти всегда означает инцидент в первую неделю после запуска.

Этап 5: тестирование в финтехе

В обычном приложении баг — это тикет в Jira. В финтехе баг — это претензия от пользователя, потерявшего деньги.

Тестирование в финтехе многоуровневое:

Юнит-тесты покрывают каждую функцию бизнес-логики — округление сумм, конвертация валют, начисление процентов. Покрытие ниже 80% — неприемлемо.

Интеграционные тесты проверяют взаимодействие сервисов между собой и с внешними API. Каждый платёжный сценарий — happy path и все граничные случаи.

End-to-end тесты воспроизводят реальный пользовательский путь: регистрация → верификация → пополнение → перевод → вывод. Автоматизированы через Appium или Detox для мобильных.

Нагрузочное тестирование обязательно для любого продукта с финансовыми транзакциями. Инструменты: k6, Locust, JMeter. Цель — убедиться, что система выдерживает пиковую нагрузку без деградации и потери транзакций.

Тестирование безопасности — отдельный трек: SQL-инъекции, IDOR, broken auth, открытые эндпоинты. Проводится как командой, так и внешним пентестером.

Соотношение, которое мы придерживаемся: на каждые 3 разработчика — 1 QA-инженер. Это не роскошь. В финтехе это минимум.

Этап 6: релиз и работа после запуска

Финтех-продукт не «запускается» в классическом смысле. Он вводится в эксплуатацию поэтапно — чтобы контролировать риски на каждом шаге.

Стратегия релиза:

• Closed beta — 50–200 доверенных пользователей, ручной онбординг, максимальная обратная связь
• Open beta — расширенная группа, реальные транзакции с лимитами, мониторинг аномалий
• General availability — полный запуск с поддержкой на первые 72 часа в усиленном режиме

Мониторинг после запуска. В первые недели после релиза команда работает с боевыми метриками в режиме реального времени:

• Время ответа API по каждому эндпоинту
• Процент ошибок на платёжных операциях
• Количество неуспешных авторизаций
• Нестандартные паттерны транзакций

SLA и инцидент-менеджмент. Для финтех-продуктов мы устанавливаем SLA с временем реакции на критические инциденты не более 15 минут. Дежурный инженер на первые 30 дней после запуска — обязательно.

Обновления и релизный цикл. После запуска — двухнедельные спринты. Мажорные обновления с финансовой логикой проходят полный цикл тестирования заново. Патчи безопасности — вне очереди, с приоритетом выше любой фичи.

Итог

Финтех — это не страшно. Но это серьёзно. Разница между хорошим финтех-продуктом и плохим — не в дизайне и не в маркетинге. Она в том, насколько команда понимает цену каждого архитектурного решения.

Шесть этапов, которые мы проходим на каждом проекте:

• Требования и регуляторика — прежде чем проектировать, понять ограничения
• Архитектура — заложить масштабирование и надёжность с первого дня
• Безопасность — не надстройка, а фундамент
• Интеграции — банки и платёжные системы требуют отдельного трека
• Тестирование — многоуровневое, с нагрузочными и security-тестами
• Релиз — поэтапный, с мониторингом и дежурной командой

Финтех-рынок Узбекистана растёт. Пространство для новых продуктов — есть. Но войти в него с «быстро и дёшево» не получится. Здесь работает только «правильно и надёжно».