Команды, впервые сталкивающиеся с принятием платёжного решения, часто воспринимают его как ребрендинг фрод-скоринга. Сходство поверхностное. Структурно это разные продукты, делающие разную работу, и обычно нужны оба.
Кратко о фрод-скоринге
Фрод-движки на стороне мерчанта — Signifyd, Riskified, Forter, Sift, Kount, Ravelin, Stripe Radar и аналогичные — берут предложенную карточную транзакцию, оценивают поведенческие, девайсные, сетевые и исторические сигналы и возвращают рисковой скор или рекомендацию: одобрить, отправить на ручную проверку или отклонить. На стороне банка движки от NICE Actimize, FICO, Feedzai и других делают похожую работу на банковских рельсах для AML- и фрод-мониторинга.
Часть этих вендоров добавляет гарантию покрытия чарджбэков: если они одобрили транзакцию, а она оказалась мошеннической, убыток покрывают они. Это продукт переноса ответственности, а не продукт политики.
Кратко о принятии платёжного решения
Слой принятия решения о платеже берёт предложенный платёж от любого инициатора, оценивает его по политике оператора и дополнительному контексту — в том числе по фрод-сигналам — и возвращает финальное решение: allow, hold, block или escalate, с кодом причины и записью для аудита.
В чём они различаются
Измерение Фрод-скоринг Принятие платёжного решения
Время На авторизации по карте, уже после того как запрос дошёл до сети или процессора До того как запрос достиг какой-либо рельсы
Математика Вероятностная — на выходе правдоподобие Детерминированная — на выходе результат применения явных правил к структурированным входам
Входы Поведенческие и девайсные сигналы сессии Мандаты, политика по контрагенту, правила оператора, санкционный статус; фрод-сигналы как один из входов
Выход Скор или рекомендация Обязывающее решение плюс код причины и подписанная запись
Ответственность Вендор может принимать на себя chargeback-риск по одобренным транзакциям Финансовый риск не поглощается; формируются свидетельства того, что требовала политика и что было решено
Область Обычно карточный-специфичный (на стороне мерчанта) или специфичный для банковской рельсы (на стороне банка) Не привязан к рельсам по построению
Операционный владелец Команда fraud / trust & safety Казначейство, риск или финансовый операционный блок
Почему могут быть нужны оба
Они отвечают на разные вопросы. Фрод-скоринг спрашивает: «насколько вероятно, что это платёж-мошенничество?» Принятие решения спрашивает: «разрешает ли политика этот платёж, от этого инициатора, этому контрагенту, в этой сумме, сейчас?»
Платёж может быть низкорисковым с точки зрения мошенничества и при этом нарушать политику — поставщика нет в списке разрешённых, центр затрат превышает бюджет, контрагент попал в санкционный список. И наоборот, платёж может быть разрешён политикой и при этом нести фрод-риск; тогда сигнал фрод-движка становится одним из входов решения.
Как их чисто структурировать
Относитесь к фрод-скорингу как к входу для принятия решения, а не как к параллельному шагу. Слой принятия решения читает фрод-скор в числе других сигналов, применяет политику и возвращает обязывающий исход. Аудит-запись фиксирует и то, и другое.
Антифрод по-прежнему необходим для задач, под которые он создавался. Но он не заменяет политику до исполнения: антифрод сигнализирует о риске, а policy layer отвечает на другой вопрос — можно ли проводить платёж вообще и на каких условиях.