Что считается финтех-продуктом, а что нет
Финтехом называют всё, где на экране есть деньги, — и это сбивает оценку в обе стороны. Практическая граница проходит по одному признаку: отвечает ли ваша система за состояние счёта. Если она только показывает данные, полученные от банка, это интерфейс, и стоит он как обычное веб-приложение. Если она сама решает, сколько у клиента денег и что с ними произошло, — это финтех со всеми вытекающими требованиями.
Из каких слоёв состоит система
Архитектура финтех-продукта почти всегда одинаковая, и это хорошая новость: спорить приходится не о структуре, а о деталях. Слоёв пять, и сквозные требования — аудит, мониторинг, зона PCI — не относятся ни к одному из них по отдельности.
Ядро — это журнал операций, а не таблица «баланс». Баланс всегда вычисляемая величина: сумма проведённых операций. Как только баланс становится колонкой, которую кто-то обновляет, вы получаете два источника правды и вопрос «почему у клиента 1000, а по операциям 980», на который невозможно ответить.
Если баланс нельзя пересчитать из операций, значит, вы не знаете, откуда он взялся.
Что требует регулятор и что из этого касается разработчика
Требований много, но до кода доходят три группы, и путать их дорого.
- PCI DSS — про карточные данные. Ключевая мысль: стандарт дешевле обойти, чем выполнить. Если номер карты никогда не попадает на ваш сервер, а форма ввода принадлежит провайдеру и возвращает вам токен, ваша зона проверки сжимается на порядок. Решение об этом принимается один раз и на всю жизнь продукта.
- KYC/AML — про то, кто клиент и откуда деньги. Для разработчика это не «форма загрузки паспорта», а状 набор состояний пользователя (не верифицирован, на проверке, verified, отклонён, заморожен) и правила, что можно делать в каждом. Состояния проектируются до интерфейса.
- Аудиторский след — про то, кто и когда изменил данные. Требование звучит скучно, а стоит дороже всех: журнал должен быть неизменяемым, а «удалить операцию» — невозможной командой. Сторнирование делается новой записью, а не правкой старой.
Три вещи, которые нельзя добавить потом
- 01
Идемпотентность
Сеть не гарантирует ответа: клиент повторит запрос, и без защиты вы спишете деньги дважды. Как это устроено на уровне таблиц и кода — в отдельном разборе про повторные платежи.
- 02
Неизменяемый журнал
Операции только добавляются. Исправление — это сторно плюс новая запись, а не
update. Иначе вы не сможете ни ответить на претензию, ни пройти аудит. - 03
Сверка с провайдером
Ежедневное сравнение вашего журнала с выпиской банка. Расхождения бывают всегда; вопрос только в том, узнаете вы о них сами через сутки или от клиента через месяц.
Данные, миграции и рост
Финтех-систему нельзя остановить «в ночь на воскресенье» — у денег нет выходных, а у клиентов есть часовые пояса. Поэтому любое изменение схемы данных планируется как поэтапный переход с точкой отката: подробный разбор — как переносят базу под нагрузкой и не теряют записи.
Третье решается ещё раньше и обычно молча: что считается сохранённым. Реплики и автоматическое переключение мастера дают доступность, но не дают сами по себе гарантии, что подтверждённая клиенту запись переживёт отказ узла — это отдельное свойство, и его проверяют отдельно: что происходит с данными, когда падает мастер. Уровень изоляции решает смежный вопрос — что параллельные транзакции вправе увидеть друг у друга: уровни изоляции и аномалии.
Второе, что стоит решить заранее: где заканчивается одна база. Журнал операций растёт линейно и навсегда, поэтому его партиционируют по времени с самого начала — добавить партиционирование к таблице на сто миллионов строк можно, но это отдельный проект.
Команда, сроки и бюджет
Ниже — честные ориентиры, те же, что в калькуляторе на главной. Финтех дороже обычной разработки не из-за «сложного кода», а из-за объёма работ, которых в обычном проекте просто нет: комплаенс, сверка, аудит, тестирование денежных сценариев.
Состав команды на ядро: продуктовый аналитик, который разговаривает с комплаенсом; два-три бэкендера; фронтенд; QA, который умеет писать денежные сценарии; DevOps на инфраструктуру и мониторинг. Дизайнер подключается позже, чем принято думать: пока не описаны состояния операции, рисовать экраны рано.
Чек-лист перед стартом
- Кто отвечает за состояние счёта — вы или банк-партнёр?
- Попадут ли карточные данные на ваш сервер? Если да — почему нельзя обойтись токеном?
- Какие состояния может иметь клиент и что он может делать в каждом?
- Как выглядит сторнирование операции? (Если ответ «удалим запись» — вернитесь к разделу про аудит.)
- С кем и как часто вы сверяетесь и кто увидит расхождение первым?
- Что происходит, когда провайдер не ответил за 30 секунд?
- Кому принадлежат код, данные и ключи после оплаты?
Последний пункт не технический, но он определяет всё остальное. Что должно быть в договоре и как отличить нормального подрядчика — в материале как выбрать подрядчика и не попасть.
Частые вопросы
Нужна ли нам лицензия, чтобы запустить финтех-продукт?
Зависит от того, чьи деньги вы держите. Если средства клиентов лежат на счетах банка-партнёра, а вы предоставляете интерфейс и учёт, лицензия чаще всего нужна партнёру, а не вам. Как только деньги попадают на ваш счёт и вы распоряжаетесь ими от своего имени, разговор становится другим. Это вопрос к юристу в вашей юрисдикции, а не к разработчику — но ответ на него меняет архитектуру, поэтому задавать его нужно до старта.
Можно ли сделать MVP за три месяца?
Можно, если MVP — это приём платежей поверх готового процессинга и учёт заказов: 9–14 недель реалистичны. Собственный журнал операций, лимиты и сверка за три месяца не делаются: не потому, что кода много, а потому что денежные сценарии нужно тестировать, а тестирование здесь занимает столько же, сколько разработка.
Что дешевле: свой процессинг или готовый провайдер?
На горизонте до трёх лет почти всегда провайдер — вы платите процент, но не платите за лицензии, интеграции с банками, сверку и поддержку 24/7. Свой процессинг окупается на объёме, когда процент провайдера начинает превышать стоимость собственной команды. Считать нужно именно так, а не «это же просто API».
Как вы тестируете то, что связано с деньгами?
Отдельным набором сценариев, где проверяется не интерфейс, а инварианты: сумма операций равна балансу, повтор запроса не создаёт вторую операцию, отменённая операция оставляет след, ночная сверка сходится. Такие тесты пишутся до кода — они и есть спецификация.
Вы делали такие системы?
Да — платёжные ядра, банковские дашборды, кошельки. Названий заказчиков мы не публикуем: договоры закрыты NDA, часть проектов идёт по модели white-label, где продукт выходит под брендом клиента. На созвоне под встречный NDA показываем договоры, сами системы в работе и даём контакты для рекомендаций.
Источники
Утверждения из статьи можно проверить: ниже первоисточники, а не пересказ.
- 01PCI Security Standards Council — PCI DSS — официальный текст стандарта и требования к зоне проверки
- 02Stripe API — Idempotent requests — промышленная реализация идемпотентности, на которую удобно ориентироваться
- 03Double-entry bookkeeping — принцип, которому пятьсот лет и который до сих пор лучший способ не потерять деньги в учёте
Материалы пишут инженеры, работающие на проектах, — но без подписи именем. Причина та же, по которой на сайте нет логотипов клиентов: почти все проекты идут под NDA или white-label, и авторство статьи о платёжном ядре указывает на заказчика не хуже логотипа. Взамен мы отвечаем за текст правилами, а не именами — кроме материалов о собственном открытом коде: те подписаны автором.
Как мы пишем и что проверяем