Опасна ли тестовая среда в современных антифрод системах?

В платежной индустрии тестовая среда воспринимается как обязательный и безопасный этап перед запуском продукта. Это логично: невозможно подключить мерчанта, не проверив интеграцию, не протестировав маршруты платежей и не убедившись в том, что система работает корректно. На уровне бизнеса тест — это инструмент контроля качества.

Однако в реальности тестовая среда — это не просто технический этап. Это зона, где сознательно ослабляются защитные механизмы. Снижаются лимиты, добавляются исключения, используются whitelist-правила, отключаются отдельные фильтры. Всё это делается для удобства и скорости, но именно здесь возникает фундаментальная проблема, связанная с тем, какие именно процессы допустимо автоматизировать в риск-менеджменте, а какие требуют строгого контроля, как показано в статье о том, нужно ли автоматизировать процессы риск-менеджмента.

Любое ослабление системы — это потенциальная точка входа для злоупотреблений. И если бизнес воспринимает тест как “безопасную зону”, злоумышленники воспринимают его как возможность. Причём часто они используют тестирование гораздо более системно, чем сами компании.

На практике большинство серьёзных проблем не возникает внезапно. Они готовятся. И этап тестирования — это идеальное время для подготовки. Именно здесь можно проверить систему, понять её ограничения и найти слабые места без серьёзных последствий.

Поэтому тестовая среда — это не просто часть разработки. Это часть risk management. И от того, как она выстроена, напрямую зависит устойчивость всей платёжной инфраструктуры.

Почему тестовая среда становится уязвимостью

Во время тестирования система начинает работать иначе. Она перестаёт быть “жёсткой” и становится “гибкой”. Это выражается в следующих вещах:

• появляются исключения из правил;
• часть транзакций проходит без полной проверки;
• ограничения ослабляются;
• контроль переносится на уровень “доверия”.

Именно этот переход от контроля к доверию и создаёт уязвимость.

С точки зрения антифрода тестовая среда — это не отдельная зона. Это просто ранний этап поведения клиента. И если на этом этапе появляются аномалии, их нельзя игнорировать.

Как на самом деле выглядит “тестирование”

Типичный сценарий тестирования:

• мерчант запускает транзакции на небольшие суммы;
• использует разные карты;
• проверяет разные страны;
• повторяет операции с небольшими изменениями;
• просит whitelist для “удобства”.

С точки зрения бизнеса — это нормальный процесс. С точки зрения антифрода — это поведенческий паттерн, который может указывать на подготовку к атаке.

Практический кейс: BIN testing под видом тестирования

Один из самых распространённых сценариев — это BIN testing, который напрямую связан с моделями злоупотреблений в платежах и последующими потерями, подробно разобранными в материале про потери в платежах и роль 3DS 2.0.

Как это происходит:

• запускаются небольшие транзакции;
• используются разные карты;
• проверяется успешность операций;
• фиксируются “рабочие” BIN;
• после этого запускается массовая атака.

На этапе тестирования это выглядит как обычная проверка. Но фактически это разведка системы.

Если антифрод не реагирует на этот этап — дальнейшая атака становится неизбежной.

Whitelist: главный источник ошибок

Whitelist — необходимый инструмент, но при неправильном использовании он становится одним из главных рисков.

Основные проблемы:

• отключение фильтров;
• потеря контроля над транзакциями;
• использование whitelist в production;
• передача доступа третьим лицам.

Реальный кейс:

Мерчант получил whitelist для тестирования. После запуска доступ не был отключён. Через него начали проходить реальные транзакции. Антифрод их не видел. Через несколько недель система получила рост фрода и давление от банка.

Скрытые схемы под видом тестирования

Тестовая среда часто используется для маскировки реальных операций.

На практике встречаются:

• продажи запрещённых товаров под видом тестов;
• реальные транзакции, оформленные как тестовые;
• использование тестов для отмывания средств;
• смешивание тестового и реального трафика.

Классический пример — фиксированные суммы (например, 99 долларов), которые заявляются как тестовые, но фактически являются оплатой услуг.

Дроп-схемы и тестирование

Во многих случаях тестирование сопровождается использованием дроп-аккаунтов.

Сценарий:

• создаются аккаунты на подставных лиц;
• используются разные карты;
• проверяются сценарии;
• после этого запускается масштабирование.

На этапе тестирования это выглядит как хаотичная активность. Но на самом деле это подготовка структуры.

Криптовалюты как усилитель риска

Если в тестовой среде присутствуют криптовалюты, риск увеличивается.

Причины:

• анонимность;
• невозможность возврата средств;
• использование в схемах отмывания;
• сложность отслеживания потоков.

Даже небольшие тестовые операции могут быть частью более сложной схемы.

Почему лимиты критичны

Лимиты — один из самых эффективных инструментов контроля.

Они позволяют:

• ограничить ущерб;
• контролировать поведение;
• замедлить тестирование системы злоумышленниками.

Практика показывает:

• до 3 долларов за транзакцию;
• до 100 долларов в месяц;
• ограничение количества операций.

Эти ограничения не мешают тестированию, но резко снижают риск.

Практический кейс: как лимиты остановили атаку

В одном проекте злоумышленники начали тестирование через множество мелких транзакций.

Система имела лимиты:

• ограничение суммы;
• ограничение количества операций;
• контроль частоты.

В результате злоумышленники не смогли масштабировать схему. Потери были минимальными.

Без лимитов ущерб мог бы быть значительным.

Ошибки антифрод-команд

Основные ошибки:

• игнорирование тестовых транзакций;
• разделение onboarding и antifraud;
• отсутствие анализа поведения;
• доверие к мерчанту без проверки;
• отсутствие лимитов.

Эти ошибки повторяются системно.

Как думают банки и платёжные системы

Важно понимать, что банки и платёжные системы не разделяют “тест” и “реал”.

Для них важны:

• fraud ratio;
• chargeback;
• поведение трафика;
• стабильность показателей.

Если проблема началась в тестовой среде, но проявилась позже — ответственность остаётся на стороне компании.

Как правильно выстраивать тестовую среду

Правильный подход:

• тест = часть production;
• все транзакции анализируются;
• whitelist строго ограничен;
• лимиты обязательны;
• поведение отслеживается;
• антифрод участвует в процессе.

Финальный вывод

Тестовая среда не является безопасной по умолчанию.

Она становится безопасной только при наличии контроля.

Если контроль отсутствует — тест превращается в подготовку атаки.

Если контроль есть — тест становится инструментом защиты.

Именно поэтому тестирование должно рассматриваться не как технический этап, а как часть стратегии управления рисками.

Если вы хотите глубже разобраться в antifraud, тестировании платежей и управлении рисками, изучите программы Академии Riskscenter.