В 2026 году антифрод для PSP и эквайеров окончательно перестал быть внутренней функцией по снижению потерь. Теперь это часть обязательств перед платёжными системами, партнёрами и регуляторами. Для рынка Центральной Азии это особенно заметно: Казахстан и Узбекистан одновременно растут по онлайн-платежам, числу новых финтех-игроков и сложности регуляторной среды. При этом значительная часть местных PSP и эквайеров всё ещё живёт в логике прошлых лет: есть транзакционный мониторинг, правила и команда разбора инцидентов — значит, антифрод «есть». На практике этого уже недостаточно.
Платёжные системы всё чаще оценивают не только уровень прямых потерь, но и то, как именно компания управляет риском: как считает метрики, насколько быстро реагирует, как контролирует мерчантов, как документирует нарушения и где хранит данные. И именно здесь для многих игроков начинается главный разрыв между привычной моделью работы и новыми требованиями.
Когда антифрод превращается в KPI
Лучше всего этот сдвиг виден на примере Visa VAMP. Для платёжной системы fraud и disputes — это уже не разные задачи разных подразделений, а единый риск-профиль эквайера. Если проблемный мерчант стабильно генерирует спорный или мошеннический поток, вопрос уже не в том, «хорошая» ли у вас антифрод-модель. Вопрос в том, готовы ли вы объяснить, почему этот риск оказался в вашем портфеле и почему вы не остановили его раньше.
Это важный сдвиг, который на практике часто недооценивают. Раньше многие PSP мысленно разделяли антифрод и dispute-management: первое — задача риск-команды, второе — операционного блока. VAMP фактически говорит обратное. Для схемы это один и тот же показатель качества управления риском.
Проблема в том, что многие компании умеют отклонять плохие транзакции, но не умеют смотреть на риск тем языком, которым его измеряет платёжная система. Пока вы считаете fraud rate «по-своему», а схема считает риск «по-своему», можно искренне считать, что всё под контролем, хотя на уровне VAMP вы уже движетесь к проблемному статусу.
Enumeration: когда «мы всё отклонили» уже не считается защитой
Ещё нагляднее это видно в части enumeration — атак перебора карт и реквизитов. Для PSP часто работает логика: «деньги не ушли, транзакции отклонили, значит ущерба нет». Но для платёжной системы это не оправдание. Если через ваш контур проходит массовый поток попыток перебора, это уже не «фон», а признак того, что атаку не распознали как процесс и не остановили достаточно рано.
Именно здесь начинается разговор об архитектуре антифрода. Транзакционный мониторинг такие атаки, как правило, видит и часто действительно отклоняет значительную часть попыток. Ошибка не в том, что он «слеп». Ошибка в том, что его используют как единственный слой защиты. Enumeration — это не одна плохая транзакция, а поток событий: частота, сценарий, поведение, распределение по BIN, устройствам и сессиям. Если смотреть только на решение по отдельной операции, можно видеть рост отказов и всё равно слишком поздно понять, что это уже системная атака.
Вывод здесь простой: защита должна начинаться до авторизации, а не только в момент скоринга платежа.
Mastercard: проблема уже не только в транзакции, но и в мерчанте
Если Visa жёстко формализует fraud, disputes и enumeration, то Mastercard в 2026 году особенно сильно подсвечивает merchant monitoring. Для новых мерчантов требуется проверка до первой транзакции, а затем — регулярный непрерывный контроль. При выявлении нарушений должны соблюдаться сроки уведомления, расследования и отчётности.
На словах это звучит просто: «нужно мониторить мерчантов». На практике это означает, что кто-то должен проверить URL до запуска, понимать, что именно продаёт мерчант, фиксировать доказательную базу, сопоставлять контент с MCC и профилем бизнеса, отслеживать изменения, вести процесс расследования и готовить отчётность в нужной структуре.
Большинство PSP исторически так не работают. Их процессы построены вокруг онбординга, KYC/KYB, транзакций и chargeback-разборов. Постоянный контентный и поведенческий контроль мерчанта — это уже отдельная дисциплина. Но ответственность при этом всё равно лежит на PSP и эквайере.
BIN-attacks: не невидимы, а слишком поздно классифицируются
Отдельно стоит тема BIN-attacks. Здесь часто возникает ложное ощущение, что транзакционный мониторинг «не видит» проблему. На самом деле видит: фиксирует всплеск отказов, подозрительные операции, паттерны авторизаций. Более того, именно он часто принимает решение об отклонении значительной части трафика.
Но для схемы этого недостаточно. Её интересует не то, что вы «отклонили много плохих транзакций», а то, что вы распознали атаку как поток и остановили её как процесс. На практике слабое место не в детекции отдельной операции, а в оркестрации. Если у вас нет раннего слоя анализа поведения и механики, которая быстро отличает «шумный» поток отказов от автоматизированного перебора, можно несколько часов жить в режиме «система справляется», а потом обнаружить, что метрики уже испорчены.
Поэтому транзакционный мониторинг необходим, но его недостаточно использовать в одиночку. Для BIN-attacks нужен ранний слой, который работает до платёжного решения и позволяет остановить поток ещё на уровне поведения, устройства, частоты и структуры запроса.
Почему для Казахстана и Узбекистана это сложнее
Для Центральной Азии это не просто импорт международной повестки. В Казахстане и Узбекистане требования платёжных систем накладываются на более жёсткие правила по локализации данных и взаимодействию с национальной инфраструктурой. Это уже не «юридическая оговорка», а конкретные инженерные последствия: где хранятся события, где считаются признаки, где находится доказательная база, как организован доступ и кто отвечает за контуры обработки.
В результате PSP оказывается сразу в двух системах координат: международные схемы требуют современного управления жизненным циклом риска, а локальная регуляторика — хранения данных внутри страны и формализованных процедур. Это означает, что «лёгких» архитектурных решений здесь просто нет.
Типичная ошибка рынка: улучшать модель там, где проблема в архитектуре
Когда ухудшаются метрики, естественная реакция — улучшать скоринг: добавить признаки, обновить правила, переобучить модель, подкрутить пороги. Иногда это помогает, но всё реже даёт системный эффект.
Проблема в том, что новые требования Visa и Mastercard адресованы не только качеству предсказания. Они адресованы всему процессу: как рано вы видите атаку, как быстро распознаёте её как атаку, видите ли не только клиента, но и мерчанта, умеете ли формировать отчётность в логике схемы и можете ли доказать, что контролировали ситуацию, а не просто реагировали на последствия.
Именно поэтому сегодня можно иметь сильную команду транзакционного мониторинга, хороший ML и низкий прямой fraud-loss, но всё равно не соответствовать реальным ожиданиям схемы.
Какая архитектура действительно закрывает требования
Если убрать маркетинг, для PSP и эквайеров в Казахстане и Узбекистане сегодня нужна архитектура, которая соединяет три уровня.
Первый — сессионный слой. Он нужен потому, что enumeration, card testing, автоматизированные сценарии и часть BIN-атак должны обнаруживаться до авторизации.
Второй — транзакционный слой. Здесь считается риск операции, строится кросс-канальный скоринг, выдаются рекомендации по адаптивной аутентификации и считаются метрики в логике платёжных систем.
Третий — merchant monitoring. Он закрывает ту часть compliance, которую чаще всего пытаются «размазать» по ручным процессам: проверка до запуска, регулярный мониторинг, доказательная база, процессы уведомлений и расследований, регулярная отчётность.
На практике такой подход уже реализован в КБ ТехноСкор: компания объединила сессионный антифрод, транзакционный антифрод и мониторинг мерчантов в единую антифрод-платформу. Для PSP и эквайеров это важно не только как технологическое удобство, но и как способ перейти от разрозненных точечных решений к целостному управлению риском в логике требований международных платёжных систем и локальной регуляторики.
Если у вас есть только один из этих слоёв, вы закрываете лишь часть задачи. Если есть все три, появляется шанс говорить со схемами и регулятором на языке доказуемого контроля риска, а не на языке внутренних предположений, что «наши модели в целом хорошие».
Вместо вывода
Для PSP и эквайеров Центральной Азии главный вопрос ближайших лет звучит уже не так: «нужен ли нам антифрод». Он звучит иначе: «соответствует ли наша архитектура тем требованиям, по которым нас на самом деле будут оценивать?»
Visa задала язык VAMP с точными метриками. Mastercard задала язык merchant monitoring с конкретными сроками, процессами и отчётностью. Казахстан и Узбекистан добавляют к этому требования по локализации данных и взаимодействию с национальной инфраструктурой.
В сумме это означает, что антифрод окончательно вышел из категории nice-to-have и превратился в часть обязательной платёжной инфраструктуры. И сегодня важно уже не просто «улучшать скоринг», а честно ответить на взрослый вопрос: если завтра платёжная система, партнёр или регулятор спросит, как именно вы контролируете жизненный цикл риска — от поведения пользователя до поведения мерчанта, — сможете ли вы показать не презентацию, а работающий процесс, метрики и доказательную базу?