Почему после внедрения 3DS 2.0 компании начали терять деньги

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

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

Более того, в ряде случаев сам факт перехода на 3DS 2.0 создавал у бизнеса ложное чувство безопасности. Компании начинали считать, что ключевой риск закрыт, и ослабляли внимание к тем зонам, где на самом деле формировались реальные потери: к качеству мерчантов, настройке antifraud-логики, dispute-стратегии, продуктовым ограничениям и поведению клиентов.

Именно поэтому вопрос нужно ставить не так: «Помогает ли 3DS 2.0?» Безусловно, помогает. Правильный вопрос другой: почему даже после внедрения 3DS 2.0 компании продолжают терять деньги. Чтобы ответить на него, нужно смотреть не на сам протокол, а на всю платежную модель целиком.

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

Что такое 3DS 2.0 для бизнеса на практике

Если убрать технические формулировки, 3DS 2.0 — это механизм дополнительной проверки плательщика, который должен снизить риск несанкционированных операций и улучшить распределение ответственности между участниками платежной цепочки. Для банков, эквайеров, PSP и мерчантов это не просто технология подтверждения, а часть общей risk-модели.

На практике бизнес обычно ожидает от 3DS 2.0 сразу несколько эффектов:

• снижение fraud chargeback;
• перенос части ответственности на эмитента в определённых сценариях;
• повышение доверия со стороны банка и платежной системы;
• более высокий уровень контроля над риском;
• возможность масштабировать обороты безопаснее.

Все эти ожидания частично оправданы. Но ключевая проблема в том, что многие компании воспринимают 3DS 2.0 как автономное решение, а не как один из элементов платежной архитектуры. И именно здесь начинается расхождение между ожиданием и реальностью.

Главная иллюзия: 3DS 2.0 не решает проблему сам по себе

Самая частая ошибка бизнеса — ожидание, что после внедрения 3DS 2.0 потери снизятся автоматически. Эта ошибка встречается и у небольших платежных проектов, и у зрелых компаний. Причина в том, что протокол аутентификации часто подменяет собой полноценное понимание риска.

Компания видит только внешнюю логику:

• клиент прошел проверку;
• транзакция подтверждена;
• значит, операция безопасна.

Но в реальной жизни финансовые потери формируются не только из-за классического card fraud. Компании теряют деньги по гораздо более широкой группе причин:

• friendly fraud и клиентские диспуты;
• споры из-за подписок и recurring payments;
• ошибки в onboarding и работе с high-risk мерчантами;
• плохое качество трафика;
• непрозрачный billing descriptor;
• слабая поддержка клиентов;
• некачественная доказательная база по чарджбэкам;
• конфликт между конверсией и безопасностью.

3DS 2.0 влияет только на часть этой картины. Он не исправляет сам бизнес-процесс. Он не делает плохого мерчанта хорошим. Он не устраняет misrepresentation. Он не заменяет dispute strategy. И он точно не отменяет необходимость аудита процессов.

Почему потери могут вырасти именно после внедрения

На первый взгляд это звучит парадоксально. Если защита стала сильнее, почему бизнес может начать терять больше? Ответ в том, что внедрение 3DS 2.0 часто меняет распределение рисков, конверсию, поведение клиентов и внутреннюю логику обработки платежей. Если эти изменения не контролировать, они начинают генерировать новые потери.

1. Падение конверсии и попытка “компенсировать” её рискованным трафиком

После внедрения 3DS 2.0 у некоторых мерчантов действительно снижается approval rate. Особенно это заметно в сегментах:

• импульсных покупок;
• подписок;
• международного трафика;
• high-risk verticals;
• mobile-first сценариев.

Бизнес, видя падение конверсии, начинает компенсировать его не улучшением процессов, а более агрессивной моделью привлечения трафика:

• подключает более сомнительные источники;
• ослабляет antifraud-фильтры;
• увеличивает acceptance на пограничных сегментах;
• снижает порог риска ради объёма.

В этот момент формально 3DS 2.0 уже работает, но реальный риск в портфеле растёт. Потери приходят не потому, что протокол плохой, а потому, что бизнес неправильно отреагировал на изменение конверсии.

2. Ставка только на аутентификацию без развития antifraud

Вторая типовая ошибка — заморозка развития антифрод-системы после внедрения 3DS 2.0. Компания считает, что ключевой вопрос закрыт, и перестаёт инвестировать в:

• поведенческий анализ;
• risk scoring;
• device intelligence;
• BIN analytics;
• merchant monitoring;
• портфельный контроль.

В результате снижается способность видеть сложные паттерны. Это особенно опасно там, где мошенничество развивается не как одиночная атака, а как сеть связанных событий. 3DS 2.0 подтверждает клиента в момент платежа, но не анализирует глубоко саму логику риска на уровне портфеля.

3. Рост friendly fraud и service-related disputes

Одна из самых недооценённых тем: даже если классический fraud снижается, могут расти другие типы потерь. Например:

• клиент не узнает списание;
• не понимает, что подписался на recurring billing;
• считает, что услуга оказана не полностью;
• оспаривает платеж не как fraud, а как consumer dispute.

Для бизнеса это всё равно деньги. И если внутренняя логика строилась вокруг идеи, что 3DS 2.0 “решит проблему чарджбэков”, то последствия оказываются болезненными. Чарджбэков может стать не меньше, просто меняется их природа.

Типовой сценарий потерь №1: 3DS есть, а спор всё равно проигран

Очень распространённая ситуация в e-commerce и digital services. Платёж прошёл через 3DS 2.0, клиент аутентифицировался, операция формально выглядит защищённой. Через некоторое время приходит dispute.

Компания уверена, что раз 3DS был, спор будет выигран автоматически. Но затем оказывается, что в реальности это напрямую связано с процессами работы с чарджбэками и спорами:

• billing descriptor непонятный;
• условия возврата не раскрыты;
• на сайте нет прозрачного описания услуги;
• поддержка клиента не отработала обращение вовремя;
• нет нормального evidence package.

Итог: транзакция была аутентифицирована, но деньги всё равно потеряны. Причина — не в протоколе, а в общем качестве процесса.

Типовой сценарий потерь №2: частичное внедрение 3DS 2.0

На практике далеко не все компании внедряют 3DS 2.0 одинаково качественно. Часто встречаются ситуации, когда:

• часть трафика идёт по новой схеме, а часть остаётся на старой;
• не все рынки покрыты одинаково;
• не все BIN и issuer-сценарии обрабатываются корректно;
• мобильный трафик проходит хуже, чем desktop;
• редкие edge cases вообще не тестировались.

Снаружи кажется, что 3DS 2.0 внедрён. Внутри — появляется фрагментированная система, где часть рисков закрыта, а часть осталась. Это создаёт опасную иллюзию завершённости проекта.

В таких случаях компания не просто недополучает эффект — она теряет деньги, потому что решения по risk appetite уже строятся на предположении, что защита работает везде одинаково.

Типовой сценарий потерь №3: конфликт между UX и risk management

3DS 2.0 всегда находится в точке конфликта между безопасностью и конверсией. С одной стороны, бизнес хочет больше одобрений и меньше friction. С другой — банк, эквайер и risk-команда хотят контролируемый риск.

Когда конверсия проседает, начинается типичный внутренний спор:

• продукт говорит, что нужно меньше шагов;
• маркетинг говорит, что клиенты “отваливаются”;
• risk-команда говорит, что нельзя ослаблять контроль;
• финансы хотят сохранить оборот.

Если решение принимается в пользу краткосрочной конверсии без корректного анализа, компания может начать:

• маршрутизировать часть трафика через более слабые сценарии;
• исключать отдельные сегменты из 3DS;
• повышать tolerance к риску;
• запускать “временные” исключения, которые потом становятся постоянными.

Именно такие “временные уступки” очень часто и становятся источником будущих потерь.

Почему банки и эквайеры смотрят на ситуацию шире, чем сам мерчант

Это важный момент, который многие недооценивают. Банк и эквайер не анализируют отдельную транзакцию в вакууме. Они смотрят на:

• портфель целиком;
• динамику fraud ratio;
• chargeback ratio;
• качество трафика;
• типы диспутов;
• поведение мерчанта во времени.

Поэтому мерчант может считать, что у него “всё нормально, потому что есть 3DS 2.0”, а банк уже видит, что:

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

Именно по этой причине компании часто сталкиваются с неожиданным давлением со стороны партнёров. Для них проблема ещё “не критичная”, а для банка она уже выглядит системной.

Где компании чаще всего теряют деньги после внедрения 3DS 2.0

Если смотреть на практику аудитов и разборов кейсов, основные зоны потерь после внедрения 3DS 2.0 обычно находятся здесь:

• неправильная настройка маршрутизации трафика;
• некачественная интеграция с PSP или acquirer;
• отсутствие единой логики antifraud и 3DS;
• непрозрачные recurring payments;
• слабая работа с customer support;
• неподготовленная dispute-команда;
• непонимание, где заканчивается fraud и начинается customer dissatisfaction.

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

Почему recurring и подписки особенно уязвимы

Отдельно стоит выделить recurring billing. Именно в подписочных и квази-подписочных моделях компании чаще всего сталкиваются с ложным ощущением безопасности.

Транзакция проходит аутентификацию на старте, далее списания продолжаются автоматически. С точки зрения продукта это удобно. Но с точки зрения риска появляются типовые проблемы:

• клиент забывает о подписке;
• не узнаёт descriptor;
• не понимает логику списаний;
• не может быстро отменить услугу;
• идёт не в поддержку, а сразу в банк.

В итоге компания может иметь технически корректно внедренный 3DS 2.0 и одновременно терять значительные суммы на recurring-related disputes.

Как выглядит зрелый подход к 3DS 2.0

Зрелая компания смотрит на 3DS 2.0 не как на функцию, а как на один из модулей общей risk-архитектуры.

Это означает, что параллельно с внедрением протокола компания:

• пересматривает antifraud-логику;
• проверяет dispute-процессы;
• анализирует UX-потери и причины drop-off;
• оценивает прозрачность сайта и billing model;
• отдельно проверяет recurring flows;
• смотрит на реальное распределение риска по сегментам.

Только в этом случае 3DS 2.0 начинает работать как усилитель контроля, а не как формальный “флажок соответствия”.

Практический кейс: когда 3DS внедрили правильно, но всё равно теряли деньги

Один из типовых кейсов в digital services выглядел так: компания качественно внедрила 3DS 2.0, approval rate после стабилизации остался приемлемым, fraud chargeback по части сегментов снизился. На первый взгляд результат был положительным.

Однако через несколько месяцев финансовая картина показала неприятный факт: общие потери не сократились. При разборе оказалось, что:

• часть fraud действительно ушла вниз;
• но выросли customer disputes;
• увеличилось число жалоб на непонятные списания;
• support не справлялся с объемом обращений;
• доказательная база для оспаривания споров была слабой.

То есть компания решила одну задачу, но не увидела другую. Без комплексного аудита она продолжала считать, что проблема находится “где-то в банке или клиентах”, хотя на самом деле деньги терялись внутри собственных процессов.

Почему 3DS 2.0 нужно оценивать через аудит, а не через технический чек-лист

Очень частая ошибка — проверять 3DS 2.0 как чисто техническое внедрение:

• интеграция есть;
• сценарий работает;
• банковская аутентификация проходит;
• значит, проект успешен.

Но для бизнеса этого недостаточно. Аудиторский взгляд нужен именно потому, что он связывает между собой разные уровни:

• техническую интеграцию;
• антифрод-логику;
• UX и конверсию;
• чарджбэки и их причины;
• billing transparency;
• коммуникацию с клиентом;
• отношения с банками и PSP.

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

На что смотреть в первую очередь, если после внедрения 3DS 2.0 деньги всё равно уходят

Если бизнес уже перешел на 3DS 2.0, но при этом продолжает терять деньги, приоритетный порядок анализа должен быть примерно таким:

• структура чарджбэков по reason codes;
• динамика fraud vs non-fraud disputes;
• качество recurring-модели;
• billing descriptor и клиентская узнаваемость списаний;
• качество merchant onboarding;
• источники трафика и риск-сегменты;
• настройки antifraud после внедрения 3DS;
• фактическая полнота покрытия трафика новым протоколом.

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

Главный вывод

3DS 2.0 сам по себе не делает бизнес прибыльнее и безопаснее. Он снижает риск в определённом сегменте и при правильном использовании даёт важные преимущества. Но он не заменяет ни antifraud, ни dispute-стратегию, ни прозрачный продукт, ни корректный onboarding, ни контроль качества трафика.

Компании начали терять деньги после внедрения 3DS 2.0 не потому, что сам протокол плохой. Они начали терять деньги потому, что ожидали от него больше, чем он способен дать, и не пересмотрели остальные элементы платежной модели.

Если смотреть на ситуацию профессионально, то вопрос всегда должен звучать так: не “есть ли у нас 3DS 2.0”, а “как он встроен в нашу общую систему управления рисками и где деньги продолжают утекать после его внедрения”.

Именно на этот вопрос и должен отвечать аудит. Если после перехода на 3DS 2.0 вы не увидели ожидаемого эффекта, либо столкнулись с ростом потерь, споров или давления со стороны банков и партнёров, значит проблема почти наверняка лежит глубже, чем просто техническая интеграция.

Если вы хотите понять, где именно ваша платежная модель продолжает генерировать потери после внедрения 3DS 2.0, имеет смысл провести комплексную проверку процессов, antifraud-логики, dispute-модели и взаимодействия с эквайрингом. Подробнее об этом вы можете узнать на странице аудита.