Конструкторы правил позволяют пользователям антифрод системы производить ее более тонкую настройку под свои задачи без обращения к вендору (разработчику). Но в разных типах антифрод систем правила используются разными способами, поэтому в этой статье мы рассмотрим применение конструкторов правил отдельно в транзакционных и сессионных антифрод решениях.
Правила в транзакционном антифроде
В транзакционной антифрод системе конструктор правил дает возможность конечному пользователю создать простую и понятную ему логику для сортировки транзакций на легитимные, подозрительные и мошеннические. Поскольку транзакционный антифрод работает в основном с платежами и данными о них, то он использует небольшой набор простых и понятных человеку параметров. Среди них могут быть: сумма платежа, % суммы платежа от общего баланса пользователя, количество платежей за единицу времени и другие.
Обычно вендор транзакционной антифрод системы предоставляет специальный интерфейс, в котором пользователь может создавать и редактировать правила с использованием набора заранее определенных параметров. При поступлении нового платежа антифрод пропустит его через пользовательские правила и в случае совпадения с одним из них отнесет платеж к заранее определенной группе (например, платежи, для которых нужно получить дополнительное подтверждение от клиента).
Интерфейс конструктора правил в антифрод системе FraudWall
В большинстве транзакционных антифрод решений присутствуют специальные списки (блеклисты) с данными мошенников или подозрительных получателей. Например, номера их счетов, ИНН, номера телефонов и другие. Если данные получателя платежа присутствуют в этих списках, такой платеж следует отклонить или отправить на дополнительное подтверждение. Поэтому в конструкторах правил часто используются параметры, которые отвечают за возможность проверить соответствующее поле платежа на наличие в данных списках.
Очевидным преимуществом системы правил является ее понятность для человека, поскольку человек сам ее и составляет. Это позволяет при разборе причин блокировки платежа понять, по каким критериям он был отклонен. Для контраста здесь можно привести алгоритмы машинного обучения, которые также используются в транзакционных антифрод системах, но результаты их работы основаны на статистической вероятности и объяснить логику их решений с точки зрения человека часто бывает невозможно.
Таким образом, наличие конструктора правил в транзакционных антифрод продуктах является неоспоримым преимуществом и повышает гибкость их настройки и общую эффективность при использовании.
Конструктор правил в сессионной антифрод системе
Ситуация с конструкторами правил в сессионных антифрод решениях обстоит несколько иначе. Сессионный антифрод работает с большим количеством технических и поведенческих параметров, многие из которых сложны для понимания пользователем, который не обладает достаточной экспертизой в этой области.
Основные проблемы при реализации правил в сессионном антифроде
1. Обычно (по крайней мере, в банках и финансовых организациях) сессионный антифрод не принимает конечные решения о блокировке платежей, этим занимается транзакционный антифрод. Сессионный антифрод передает ему информацию о выявленных рисках в сессии пользователя, и транзакционный антифрод использует ее для принятия решений. Поэтому логичнее именно в транзакционной системе реализовать конструктор правил с поддержкой параметров из внешних систем (таких, как сессионный антифрод), а не в сессионной системе.
2. Из-за большого количества различных параметров (может достигать нескольких сотен), с которыми работает сессионный антифрод, конструктор с поддержкой широкого набора параметров будет крайне сложным как для создания, так и для восприятия конечным пользователем. В таком конструкторе будет сложнее разобраться, следовательно его будут реже использовать. Также растет вероятность ошибки при создании правил, поскольку при некорректном понимании логики конструктора пользователем он может создать правило, которое будет работать не так, как он задумал.
3. В простом конструкторе правил, который будет понятен конечному пользователю, будет невозможно реализовать более сложные проверки, которые не укладываются полностью в логику конструктора.
Возникает классическая проблема, которую называют ловушкой последних 10%. Ее суть в том, что основную часть запланированного функционала реализовать легко, некоторую часть — сложно, а оставшиеся 10% — практически невозможно при разумных затратах времени и средств. Так и в конструкторах правил: реализовать правила с простой логикой достаточно просто, но существует порог, после которого реализовать требуемую логику правил в рамках конструктора становится неоправданно сложно и дорого.
Пример конструктора правил в BioCatch
Отдельно стоит отметить, что сложные правила в этом случае могут создавать очень высокую нагрузку на систему, которая может кратно или даже на порядки снижать производительность сессионной антифрод системы.
Как Web Antifraud решает проблему правил
В сессионной антифрод системе Web Antifraud вместо конструктора правил используются индивидуальные инциденты. В отличии от общих инцидентов, доступных всем клиентам, индивидуальные создаются специально под запросы конкретного заказчика. Благодаря тому, что такие инциденты реализуются в виде кода, их возможности и гибкость превосходят любой конструктор правил.
Индивидуальные (custom) инциденты в Web Antifraud
Как это работает в Web Antifraud
1. Клиент понимает (сам или на основе наших рекомендаций), что ему необходимо выявлять некоторые специфические сессионные события. Например, случаи, когда пользователь заходит с браузера A, из сети провайдера B, заполняет поля формы в определенной последовательности, использует определенный TCP/IP сетевой отпечаток, не использует курсор мыши и отправляет форму в течение N секунд. Представьте, насколько сложным будет интерфейс конструктора правил для возможности реализации такой логики.
2. Клиент на словах описывает эту логику, которую он хочет реализовать в инциденте.
3. Наши разработчики реализуют необходимую клиенту логику оптимальным с точки зрения производительности способом и добавляют этот индивидуальный инцидент в систему.
4. Клиент начинает получать от Web Antifraud уведомления об инцидентах с необходимой ему логикой.
5. В случае, если клиенту нужны не инциденты, а скоринг модель на их основе, мы также можем ее составить в наиболее гибком виде на основе пожеланий клиента.
Какие преимущества получает клиент
1. Клиенту не нужно разбираться в сложном конструкторе, изучать документацию и рисковать допустить ошибку при составлении правил.
2. Мы можем создавать правила любой сложности, в рамках технических возможностей системы.
3. Клиент просто сообщает нам, как должна работать логика правила. Мы ее реализуем. Клиент получает уведомления об инцидентах с нужной ему логикой.
Если вам нужна сессионная антифрод система с индивидуальными правилами, решающая именно ваши задачи, напишите нам или отправьте заявку на запуск бесплатного пилотного проекта.
