ФинТех‑продукт снаружи выглядит как «приложение банка в телефоне», а внутри — как связка нескольких слоёв: фронт, бэк, интеграции и шина, по которой всё это общается. Ниже — разбор по частям.
1. Фронт: то, что видит пользователь
Фронт‑энд — это интерфейс, с которым взаимодействует человек: мобильное приложение, веб‑кабинет, иногда виджеты в чужих сервисах.
Его задачи:
- красиво и понятно показать данные (баланс, операции, лимиты, тарифы);
- безопасно собрать ввод (логин, подтверждения операций, реквизиты);
- не мешать бизнес‑логике и комплаенсу, которые живут на бэке.
Типичные элементы фронта финтех‑продукта:
- Экран авторизации и онбординга, сюда же «упакованы» KYC‑шаги, запрос доступа к камере, СМС/OTP.
- Главный экран: баланс, ключевые действия (оплатить, перевести, пополнить).
- Операционные экраны: переводы, платежи, инвестиции, управление картами.
- Служебные: настройки, профиль, привязка устройств, безопасность (смена PIN, биометрия).
Важно понимать: фронт сам по себе не совершает финансовых операций.
Он лишь отправляет запросы на бэк и показывает ответы. Всё «важное» решается на серверной стороне.
2. Бэк - мозг и правила продукта
Бэк‑энд — это серверная часть, которая знает:
- кто перед ним (идентификация и аутентификация);
- что этому пользователю можно (лимиты, права, продукты);
- что именно нужно сделать (платёж, перевод, выпуск карты, изменение лимита).
Внутри бэка обычно "живут":
- Модули бизнес‑логики:
- платёжный модуль;
- модуль карт и счетов;
- модуль кредитов/инвестиций;
- модуль тарифов и комиссий. - Модули безопасности и комплаенса:
- аутентификация (пароль, OTP, биометрия);
- авторизация (права, роли);
- проверка операций по правилам AML/KYC/санкциям;
- логирование всего происходящего. - Работа с данными:
- собственные БД (профиль клиента, настройки, история действий в интерфейсе);
- кэш (для быстроты);
- очереди задач (для тяжёлых или отложенных операций).
Главный принцип: бэк — источник правды.
Например, если фронт запрашивает «провести перевод 10 000», бэк:
1. Проверяет, что пользователь — это действительно он.
2. Смотрит, есть ли средства и нет ли блокировок.
3. Сравнивает с лимитами и регуляторными правилами.
4. Отправляет команду внешней платёжной системе / банку‑партнёру.
5. Возвращает фронту статус и детали операции.
3. Интеграции: как ФинТех разговаривает с внешним миром
Почти ни один финтех‑сервис не живёт в изоляции. Практически всегда есть связи:
- с банками и платёжными шлюзами;
- с системами проверки личности и мошенничества;
- с маркетинговыми и аналитическими сервисами;
- с гос‑системами (налоги, идентификация, санкционные списки и т.п.).
Интеграции — это набор адаптеров, API‑клиентов и коннекторов, которые:
- переводят внутренний язык системы (один формат запросов/ответов) во внешний;
- учитывают требования по безопасности и надёжности;
- обрабатывают сбои, повторы, дублирование операций.
Например, чтобы отправить перевод через платёжного партнёра, бэк не ходит к нему напрямую «сырым» запросом, а обращается к своему интеграционному слою, который:
- Собирает правильный формат сообщения.
- Подписывает/шифрует его как требует партнёр.
- Отправляет по безопасному каналу (VPN, TLS, выделенная линия).
- Обрабатывает ответ, статусы на свои коды (например, «00» → «успех», «51» → «недостаточно средств»).
- При сбое умеет повторить или поставить в очередь.
Это важно и для масштабирования: если вы меняете платёжного партнёра, вам не нужно переписывать всё ядро, достаточно переключить интеграционный модуль.
4. Шина и события - кровь, по которой всё течёт
Когда модулей и интеграций становится много, их уже нельзя соединять «каждый с каждым» — получится спагетти.
Здесь в игру входит шина (ESB) или её более лёгкие аналоги - брокер сообщений, событийная шина.
Задачи шины:
- передавать сообщения между сервисами (например, «создан новый пользователь», «совершён платёж», «сработало правило антифрода»);
- обеспечивать очереди, ретраи, гарантированную доставку и порядок событий;
- позволять подключать новые сервисы, не ломая старые.
Простейший пример:
- Модуль платежей провёл транзакцию и опубликовал событие «payment.completed».
- Сервис уведомлений, подписанный на это событие, отправил пуш и e‑mail.
- Сервис аналитики зафиксировал транзакцию в витрину данных.
- Антифрод‑система обновила профиль риска клиента.
Все эти действия идут параллельно, без прямых синхронных вызовов между сервисами — их связывает шина.
5. Как всё складывается в продукт
Если собрать воедино, типичный сценарий в финтех‑продукте выглядит так:
- Пользователь в фронте жмёт «Отправить 1000».
- Фронт отправляет запрос на бэк: сумма, реквизиты, токен сессии.
- Бэк:
- проверяет авторизацию, лимиты, баланс;
- сохраняет черновик операции;
- через интеграционный слой дергает внешнюю платёжную систему. - Платёжная система отвечает «успех/отказ».
- Бэк обновляет статус операции и публикует событие в шину.
- Уведомления, аналитика, отчётность, антифрод реагируют на событие.
- Фронт получает ответ и показывает пользователю результат.
С точки зрения пользователя «прошла секунда, деньги ушли», но "под капотом" сработали фронт, бэк, интеграции, шина и система безопасности.
Зачем так усложнять
Такое разделение даёт:
- Масштабируемость: можно отдельно масштабировать фронт (под нагрузку пользователей), бэк (под сложную логику) и интеграции (под внешние лимиты).
- Безопасность: критичная логика и данные не "живут" во фронте, а экранированы слоями на бэке и в интеграциях.
- Гибкость: проще менять партнёров, каналы и даже отдельные куски бизнес‑логики, не переписывая всё приложение.
- Наблюдаемость: события в шине и логах дают чёткую картинку, где что сломалось.