<b>Fraud_detection ломается не в модели, а в том, что ей подают на вход</b>

<b>Fraud_detection ломается не в модели, а в том, что ей подают на вход</b>

Если антифрод смотрит только на IP, user-agent и гео, его можно обойти пачкой “чистых” сессий. Если он видит только device-id, его можно заново собрать из правдоподобных кусков. Слабое место почти всегда не в одном сигнале, а в их стыковке: когда поведение, сетевой слой и браузерный отпечаток не совпадают.

Хорошая схема проверки строится в три уровня:
— транспорт: прокси, ASN, частота смены IP, повторы по подсетям;
— отпечаток: canvas, WebGL, timezone, language, media devices;
— поведение: скорость заполнения, траектория кликов, паузы, повторяемость маршрута.

Красный флаг — не один “плохой” параметр, а слишком аккуратная комбинация. Например, у сессии чистый fingerprint, но одинаковый ритм действий, одинаковые задержки между шагами и слишком ровная навигация. Для defenses это повод поднимать score. Для арба — сигнал не переиспользовать один шаблон и не тащить одинаковые паттерны на весь пул.

Полезнее всего строить антифрод как систему несоответствий: одно поведение должно подтверждать другое, а не просто выглядеть “нормально”. Тогда даже хороший эмулятор начинает шуметь на стыках.

Если нужен быстрый аудит, проверяйте не “видит ли система бот”, а “сколько независимых признаков она требует до решения”. Чем меньше связей, тем дешевле обход.