Привет!

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

Со стороны платежной системы

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

Существуют такие показатели как fraud to sale и chargeback to translation ratio. Лимит fraud to sale у Visa составляет 0,9% от общего оборота или 75 000 долларов). То есть если на 1000 продаж у тебя 90 случаев фрода — это очень и очень громкий звоночек. Плюс в том, что Visa ставит такой лимит именно для кросбордерных транзакций, игнорируя случаи, в которых все участники платежа находятся в одном регионе. А минус в том, что в нашем случае достичь такого лимита как два байта переслать, у нас кроссбордерных операций очень много.

У MasterCard правила более жесткие, она считает все операции, ей без разницы, кроссбордер это или domestic (в одном регионе). Фрод есть фрод. Санкции в случае с MC представляют собой приезд аудиторов, которые будут лично внимательно следить за тем, как в компании ведется борьба с фродом. Конечно, компания может отказаться от визита аудиторов, мол, нет, извините, не пустим. В ответ на что представители MC пожмут плечами и просто отключат компанию от своей системы.

В общем, когда fraud to sale или chargeback to translation ratio начинает перешагивать установленный лимит, платежная система начинает медленно обращать на тебя свой тяжелый усталый взор, сулящий мало приятного. Тебе начинают приходить нотификации, прилетают штрафы, тебе дают возможность (тот самый случай, когда возможность = обязанность) пофиксить такое положение дел, приходится заполнять кучу бумаг, документации и remediation-планов. Мало приятного и много сложного.

И кроме всей этой официозной волокиты идут и финансовые потери — компания платит за это штрафы. Может открыться так называемое “чарджбэчное окно”, в которое начинают бодро прилетать все чарджбэки, заявленные в системе мониторинга платежных систем. Банк-эквайер не может оспорить такие операции, поэтому он перекладывает ответственность на своего payment-фасилитатора (то есть на нас). Мы пытаемся отбиваться от этого, взыскивая средства с наших мерчантов, возникает дебиторская задолженность, а это снова напряги и время.

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

Идеальный антифрод

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

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

А ещё должен быть полноценный sandbox. Антифрод же работает на правилах (на огромном количестве правил), и надо понимать, насколько корректно будут работать те или иные новые правила, будут ли конфликтовать с имеющимися, или нет. Именно в Песочнице это и можно будет обкатывать. Многие антифроды строятся на стандартной логике IF THEN, что тоже не совсем правильно. Уже сейчас есть много дополнительных параметров, которые позволяют неслабо прокачать привычные правила антифродов. Например, можно сделать адаптивный 3DS. Можно собирать данные плательщика и хранить их у себя, после чего проводить полную аутентификацию и получать от эквайеров результат платежа.Такие платежи будут делиться на успешные и неуспешные, по каждым из них будут собираться исторические данные, о чем я уже писал выше.

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

Про адаптивность

Антифрод должен работать на адаптивных функциях, которые будут адаптироваться под характер каждого плательщика, а не просто бездумно прогонять по списку условных операторов.

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

Да, подозрительно. Но сразу записывать такой платеж в “левый” не стоит, потому что ситуации могут быть разными. Например, это сотрудник в командировке, который платит за что-то бизнес-картой. И тут даже 3DS особо не спасет, потому что бизнес-карты не всегда привязаны к номеру телефона сотрудника, у которого она сейчас при себе. И чего делать, если человек пытается заплатить с такой карты, система посылает его на дополнительную верификацию, а SMS с кодом радостно уходит куда-то на корпоративный телефон сотрудника? Такие штуки мешают бизнес-клиентам сильнее, чем кажется.

Вот тут-то и пригождаются исторические данные. Мы сможем понимать, характерна ли в принципе такая оплата или нет, был ли ранее такой плательщик, видели ли мы эту карту в системе ранее, может, аутентификации уже бывали. Или наоборот, именно с этой карты подобные действия мы уже когда-то оценивали как фрод, и транзакция размечена в процессинге, чтобы на нее точно обратили внимание, ибо маркер “ФРОД” заметный. Далее, по совокупности признаков, можем не авторизовать такую транзакцию, а сначала “предавторизовать” и закинуть на обработку специально обученному человеку, который ручками уже посмотрит все и примет решение.

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

Достижим ли такой идеал в принципе

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

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

RBKmoney Public Contributions

Напоминаю, что RBKmoney Fraudbusters — это один из первых (или вообще первый?) в мире продуктов подобного уровня, выложенных в публичный доступ в виде открытых исходников. Вы можете пользоваться им свободно, по лицензии Apache 2.0.

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

• https://github.com/rbkmoney/fraudbusters — сама машина антифрода
• https://github.com/rbkmoney/fraudo — DSL правил
• https://github.com/rbkmoney/fraudbusters-management — API интерфейса управления

По всем вопросам на эту тему можете писать мне в телеграм https://t.me/anton_lva.