Разработка финтех-продукта: требования к безопасности и надёжности

Финтех-продукт отличается от обычного веб-сервиса ценой ошибки: потерянный или задвоенный платёж, утечка данных или несколько часов простоя стоят денег клиентов и доверия, а иногда и лицензии. Поэтому в разработку сразу закладывают точный учёт денег, аудит всех операций, строгий контроль доступа, отказоустойчивость и соответствие отраслевым требованиям — от стандарта PCI DSS до требований регулятора.

Разберём, какие требования предъявляются к финтех-продуктам и как их учесть в архитектуре и процессе.

Чем разработка финтеха отличается от обычного продукта?

Разработка финтеха отличается тем, что надёжность и безопасность становятся не качеством «на потом», а основными требованиями с первого дня. Каждая операция с деньгами должна быть точной, отслеживаемой и воспроизводимой, а система — продолжать работать при сбоях отдельных компонентов.

Область	Обычный продукт	Финтех-продукт
Учёт денег	Сумма в заказе	Двойная запись, баланс сходится до копейки
Журнал операций	Логи для отладки	Неизменяемый журнал для аудита
Доступ сотрудников	Роли в админке	Минимальные права, подтверждение критичных действий
Доступность	Простой нежелателен	Простой измеряется деньгами и штрафами
Изменения в продакшене	Выкладка по готовности	Контроль изменений, ревью, возможность отката
Регулирование	Общие требования к данным	Отраслевые стандарты и требования регулятора

Как правильно хранить и считать деньги?

Деньги хранят в целых минимальных единицах валюты или точных десятичных типах, а не в числах с плавающей точкой, и учитывают по принципу двойной записи: каждая операция — это проводка, которая списывает сумму с одного счёта и зачисляет на другой. Баланс не хранится как изменяемое число, а считается из проводок или сверяется с ними.

CREATE TABLE ledger_entries (
    id             bigserial PRIMARY KEY,
    transaction_id uuid        NOT NULL,
    account_id     bigint      NOT NULL REFERENCES accounts(id),
    amount         bigint      NOT NULL,  -- в копейках; списание — отрицательное
    currency       char(3)     NOT NULL,
    created_at     timestamptz NOT NULL DEFAULT now()
);

-- Проверка: сумма проводок каждой транзакции равна нулю
SELECT transaction_id FROM ledger_entries
GROUP BY transaction_id HAVING sum(amount) <> 0;

Правила работы с операциями

1. Каждая операция идемпотентна — повторный запрос не создаёт вторую проводку.
2. Записи журнала не изменяются и не удаляются; ошибку исправляет обратная проводка.
3. Операции над балансом выполняются в транзакциях с блокировками, чтобы исключить гонки.
4. Ежедневная сверка с банками и платёжными провайдерами.

Как защититься от двойных списаний на уровне API и вебхуков, мы подробно разбирали в статье идемпотентность платежей и вебхуков.

Фото: Unsplash

Какие требования безопасности предъявляются к финтеху?

К финтеху предъявляют требования по защите данных, контролю доступа и журналированию, а часть из них закреплена в отраслевых стандартах. Если продукт хранит или обрабатывает данные банковских карт, применяется стандарт PCI DSS; в России финансовые организации выполняют требования Банка России, в Евросоюзе действует регламент DORA о цифровой операционной устойчивости.

Базовые меры, которые нужны почти любому финтех-продукту:

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

Общие уязвимости веб-приложений и их защита — в статье OWASP Top 10 простыми словами. Конкретный набор обязательных требований зависит от лицензии и юрисдикции, поэтому его стоит определять вместе с юристами и специалистами по комплаенсу до начала разработки.

Как обеспечить надёжность и доступность?

Надёжность финтех-продукта обеспечивают резервированием всех критичных компонентов, продуманным поведением при сбоях внешних сервисов и наблюдаемостью: команда узнаёт о проблеме раньше клиентов. Для каждого сервиса заранее определяют допустимое время простоя и допустимую потерю данных.

Что закладывают в архитектуру:

1. Реплики базы данных и автоматическое переключение при отказе основной.
2. Бэкапы с регулярной проверкой восстановления.
3. Очереди и повторы для вызовов банков и провайдеров, которые бывают недоступны.
4. Мониторинг бизнес-метрик — числа успешных платежей в минуту, — а не только серверов.
5. План действий при инцидентах и учения по нему.

Как организовать процесс разработки финтеха?

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

Что обычно входит в процесс:

• обязательное код-ревью, для денежной логики — двумя разработчиками;
• автотесты на все денежные сценарии, включая ошибки и повторы;
• раздельные окружения и данные: разработчики не работают с реальными данными клиентов;
• автоматическая проверка зависимостей и секретов в CI;
• документированные релизы и возможность отката.

Коротко

• В финтехе цена ошибки — деньги клиентов и доверие, поэтому надёжность и безопасность закладываются с первого дня.
• Деньги храните в целых минимальных единицах, учитывайте двойной записью и не изменяйте журнал операций.
• Данные карт отдавайте сертифицированному провайдеру, требования PCI DSS и регулятора определяйте заранее.
• Резервирование, бэкапы с проверкой, очереди для внешних вызовов и мониторинг бизнес-метрик обязательны.
• Процесс строится вокруг контроля изменений: ревью, тесты, проверки безопасности и возможность отката.