Блог
Среди множества стеклянных бусин выделяется повторяющийся фиолетовый узор.

4 октября 2026 г.3 минуты чтенияАдминистратор

Adyen описала защиту от распределенного card testing

Компания анализирует состояние групп платежного трафика. В центре метода — атаки, которые трудно заметить по одному IP или покупателю.

4 октября 2026 года Adyen опубликовала технический разбор модели Bot Attack. Компания сообщает о среднем увеличении числа блокируемых атак card testing на 28% без ухудшения результата для легитимных покупателей в своей оценке. Это заявленный результат провайдера; независимая проверка и подробные границы теста в статье не представлены.

Card testing — проверка пригодности карточных данных через платежные попытки. Когда атака распределена между множеством идентификаторов, отдельный покупатель или IP может не выглядеть аномальным. Adyen описывает анализ агрегированных групп трафика и их состояния в реальном времени: модель ищет общую картину там, где индивидуальные счетчики дают разрозненные события.

Почему блокировок недостаточно для оценки

Рост числа остановленных попыток полезен только вместе с пониманием того, что именно было остановлено. Если правило просто стало жестче, показатель блокировок тоже вырастет, но вместе с ним может увеличиться потеря настоящих покупок. Поэтому важно, что в публикации отдельно заявлен результат для добросовестного трафика. Воспроизводимость этого утверждения требует собственной проверки на конкретном платежном портфеле.

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

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

Описанная архитектура дает понятный предмет для обсуждения с антифрод-командой. Заявленные 28% не следует переносить в прогноз собственной экономии: число заблокированных попыток не равно сумме предотвращенного финансового ущерба.

Что это значит для мерчантов и PSP

Для мерчанта главный вывод не в выборе конкретного вендора, а в том, как устроена собственная оценка антифрода. Атаки перебором бьют сразу по нескольким статьям: комиссии за авторизационные попытки, нагрузка на шлюз, рост доли отказов в глазах эмитентов и, как следствие, возможное ухудшение одобрений для обычных покупателей. Поэтому разговор о защите стоит вести в терминах затрат и потерь, а не только количества остановленных запросов.

PSP и платёжные оркестраторы, вероятно, получат больше вопросов от клиентов о том, как их собственные правила видят распределённые атаки. Полезно заранее подготовить понятный ответ: на каком уровне агрегируются сигналы, как быстро меняется решение и как клиент узнаёт о срабатывании.

Что проверить у себя

  • Разделены ли в отчётности подозрительные серии попыток и обычные отказы, или всё сводится в одну метрику конверсии.
  • Какие признаки используются для группировки трафика: BIN, устройство, сессия, сумма, точка входа в checkout.
  • Совпадает ли расчёт признаков в тестовой среде и в рабочей системе, есть ли мониторинг дрейфа данных.
  • Сколько стоят отклонённые попытки по договору с эквайрером и учтены ли они в экономике защиты.
  • Есть ли у команды план на случай ложных блокировок: кто снимает ограничение и за какое время.
  • Какие вопросы задать провайдеру: как измерялся эффект для легитимного трафика, на каком периоде и с какими сегментами мерчантов.

Такой список помогает сравнивать решения по сути. Заявленный процент у одного провайдера и фактический результат на конкретном портфеле могут заметно различаться, и это нормальная часть внедрения, а не повод отказываться от проверки.

Источники: Adyen engineering disclosure; Adyen Protect product description; Stripe documentation on card-testing effects

Источники

  1. 1.adyen.com/knowledge-hub/catching-card-testing-at-scale
  2. 2.adyen.com/uplift/protect
  3. 3.docs.stripe.com/disputes/prevention/card-testing

Комментарии · 0

Комментариев пока нет — будьте первым.

Войти · войдите, чтобы оставить комментарий.