• IP address — классика, но легко обходится через VPN/прокси. Поэтому часто смотрят не на чистый IP, а на определение реального IP за прокси.
• Device fingerprint — уникальный идентификатор устройства на основе отпечатка браузера, OS, железа, установленных шрифтов, разрешения экрана, часового пояса и т.д. Даже в режиме инкогнито fingerprint остаётся стабильным.
• User ID / Email / Phone — если аккаунт уже создан, можно считать его активность.
• Card number (первые 6 + последние 4) — BIN + последние цифры, чтобы не хранить полный номер.
• Geographic location — если вдруг один и тот же пользователь за 10 минут залогинился из Москвы и из Лос-Анджелеса (impossible travel).
• Session ID — чтобы отследить действия в рамках одной сессии.

Часто используют комбинированные ключи: IP + device ID, почтовый домен + IP, card BIN + IP геолокация. Это снижает количество ложных срабатываний.

Проблема ложных срабатываний и как с ней бороться

Главная боль velocity checks — ложные срабатывания. Легитимный пользователь может попытаться залогиниться 3 раза подряд, потому что забыл пароль. Семья из четырёх человек может использовать один домашний IP и делать несколько покупок в день. Корпоративная сеть может дать 50 регистраций с одного IP, и это нормально.

Чтобы минимизировать ложные срабатывания можно соблюдать следующие правила:

• Гибкие настройки тригеров: не жёсткое «5 неверных попыток = бан», а градация: 3 попытки = ничего, 5 = CAPTCHA, 10 = временная блокировка на 15 минут, 20 = полная блокировка.
• Контекстные данные: не смотреть только на IP, а учитывать device fingerprint, историю пользователя, время суток. Если это знакомое устройство, но много попыток, то скорее всего, человек просто забыл пароль. Если новое устройство + VPN + серия неудачных попыток это скорее всего бот.
• Machine learning поверх velocity: классические правила дополняются ML-моделью, которая смотрит на совокупность признаков и даёт оценку риска. Velocity anomaly — это один из признаков.
• Белый список для доверенных источников: если компания знает, что у неё есть корпоративные клиенты с общим IP, можно добавить их в исключения.
• Временные окна разной длины: считать не только за последние 10 минут, но и за час, за день. Если человек сделал 3 попытки за 10 минут, но за день их всего 5 — это одно. Если за день 50 — совсем другое.

Интеграция в архитектуру

Velocity checks живут максимально близко к точке принятия решения, обычно это промежуточный слой антифрода, который стоит между фронтом и бэкенд-логикой. Когда приходит событие (попытка логина, запрос платежа, регистрация), оно сначала идёт в движок velocity, который:

1. Извлекает ключевые атрибуты (IP, device ID, user ID, карта). 2. Увеличивает счётчики в Redis по всем релевантным ключам. 3. Проверяет, не превышены ли лимиты. 4. Возвращает решение: разрешить / требовать проверку (дополнительный шаг) / заблокировать.

Если решение это блокировка, запрос даже не доходит до основной бизнес-логики. Если требуется проверка — пользователь получает CAPTCHA, одноразовый пароль, биометрический запрос. Если разрешено, то запрос проходит дальше, но событие логируется для последующего анализа.

Важно, чтобы движок velocity работал в реальном времени с задержкой <50ms, иначе это убьёт пользовательский опыт. Поэтому Redis/Memcached и операции в памяти это стандарт. Velocity + graph analysis = мощная связка

Velocity rules эффективны против одиночных атак, но организованные группы с распределённой инфраструктурой умеют обходить простые velocity checks, распределяя активность по множеству IP и устройств. Тут помогает обнаружение фрода на основе графов: построение графа связей между аккаунтами, устройствами, IP, email, телефонами.

Если velocity показывает, что с одного device ID создано 3 аккаунта (формально ниже порога в 5), но анализ графов обнаруживает, что эти 3 аккаунта связаны через общий телефон с ещё 10 аккаунтами, созданными с других устройств — это уже патерн. Velocity даёт первичный сигнал, граф выявляет структуру.

Эволюция velocity checks: от статики к динамике