<b>Fraud detection ломается не на «ботах», а на плохом первом сигнале</b>

<b>Fraud detection ломается не на «ботах», а на плохом первом сигнале</b>

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

Что обычно выдает фрод:
— одинаковые паузы между действиями;
— слишком ровная навигация без лишних движений;
— один и тот же fingerprint при меняющемся прокси;
— массовые входы с «чистых» устройств без истории;
— заявки, где поля заполняются в одном и том же порядке.

Полезнее всего строить не жесткий бан, а скоринг. Один сигнал редко достаточно плохой, но 4–5 слабых совпадений уже должны уводить сессию в challenge, ручную проверку или задержку выдачи. Так защита меньше режет живой трафик и одновременно усложняет прогрев бота.

<b>Хорошая anti-fraud-схема не ищет идеального бота — она ищет неестественную согласованность.</b> Если у сессии «чистый» IP, но мышление устройства и поведение формы не складываются в одну историю, это и есть точка для дополнительной проверки.