3D-Secure 2.0: конверсия проседает, а фрод как жил, так и жив

3D-Secure 2.0: конверсия проседает, а фрод как жил, так и жив

Потому что большинство команд внедряют 3DS как декоративный слой безопасности, а не как нормальный риск-движок. В итоге банк видит шум, режет трение, и честный клиент упирается в челлендж там, где мог бы пройти frictionless. Документация — это ложь, логи — истина.

Сломанная схема обычно одна и та же:
— отправляют в 3DS всех подряд, включая низкорисковых;
— не передают нормальные данные по девайсу, мерчанту, адресу, истории;
— игнорируют soft decline и не умеют корректно ретраить;
— путают challenge flow с отказом и теряют оплату на ровном месте.

Фрод при этом не исчезает, потому что злоумышленнику плевать на вашу «галочку 3DS». Он бьёт в обход слабых мест: украденные аккаунты, пуш-апрув, серые BIN’ы, abuse на рекуррентах. Если у вас нет поведенческих сигналов, velocity checks и нормальной идемпотентности, то 3DS превращается в дорогой костыль на костыле.

Правильная настройка — это не «включить 3DS», а сегментировать трафик: низкий риск — frictionless, средний — challenge, высокий — блок до авторизации. И отдельно тестировать вебхуки, timeouts и повторные попытки, иначе один кривой редирект сожрёт выручку быстрее, чем любой фрод.

Итог простой: 3DS не лечит плохую антифрод-архитектуру. Он только подсвечивает, где у вас дырки, если не умеете читать логи и строить риск-профиль.