Где fintech использует OTP
В финансовом продукте одноразовый код может подтверждать доступ пользователя к каналу, но не должен самостоятельно определять, безопасна ли операция.
| Сценарий | Роль OTP | Дополнительная проверка |
|---|---|---|
| Вход | Подтвердить доступ перед созданием сессии | Устройство, история входов, риск |
| Восстановление | Разрешить ограниченный возврат доступа | Завершение старых сессий, уведомление |
| Новый получатель | Добавить подтверждение изменения | Получатель, сумма, поведение |
| Платёж или перевод | Подтвердить намерение пользователя | Баланс, лимиты, антифрод, права |
| Смена реквизитов | Подтвердить чувствительное изменение | Недавняя аутентификация, сессия |
| Выпуск API-ключа | Добавить step-up проверку | Роль, область доступа, аудит |
Финальное решение принимает ваша система после проверки всех условий. Cascade отвечает за доставку и проверку OTP, а не за финансовый риск-скоринг.
Связь кода с операцией
Не принимайте код только по номеру телефона. Используйте отдельный purpose, например login, new_beneficiary или payment_confirmation, и храните серверный challenge, связанный с конкретной операцией.
Сумму, получателя и другие чувствительные параметры не следует помещать в purpose или клиентский запрос как единственный источник истины. Берите их из защищённого состояния на сервере и перепроверяйте перед завершением действия.
Серверный поток
- Пользователь проходит первичную аутентификацию.
- Бэкенд оценивает риск и решает, нужен ли OTP.
- Сервер создаёт ограниченный challenge операции.
- Cascade получает
phone,purposeи доступный канал. - Пользователь вводит код.
- Бэкенд вызывает verify с теми же phone и purpose.
- После
success: trueсистема заново проверяет состояние операции и только затем выполняет её.
Такой повторный контроль защищает от ситуации, когда сумма, получатель или права изменились между отправкой и вводом кода.
Каналы и стоимость
WhatsApp и Telegram публично доступны и списывают по 3 кредита за успешную доставку. Новый аккаунт получает 1000 стартовых кредитов. SMS предусмотрен технически по отдельной цене после запуска, но публичный провайдер пока не работает.
Не показывайте SMS как активный резерв до его фактического включения. Пользователь должен видеть только реально доступный канал.
Лимиты и защита
Для fintech-сценария особенно важны:
- отдельные лимиты send и verify;
- ограничения по номеру, аккаунту, IP, устройству и API-ключу;
- короткий TTL и запрет повторного использования;
- cooldown resend;
- нейтральные ответы без раскрытия аккаунта;
- маскирование OTP и токенов в логах;
- алерты на всплеск отправок и неуспешных проверок;
- быстрая ротация скомпрометированного ключа.
Подробности собраны в материалах о безопасности и rate limits.
Аудит и наблюдаемость
Сохраняйте request ID, внутренний идентификатор challenge, purpose, технический результат, время и канал. Не записывайте открытый OTP или Bearer-токен.
Для воронки измеряйте send, доставку, verify и завершение операции отдельно. Высокая доставка не означает успешную или безопасную операцию.
План пилота
Начните с сценария низкого или среднего риска, например входа тестовых пользователей. Проверьте успешный код, неверный код, истечение TTL, повторную отправку, лимиты и отзыв API-ключа. Затем отдельно моделируйте изменение операции между send и verify.
Перед продакшеном проведите внутренний security review и определите, для каких операций одного OTP недостаточно.