Антифрод. Функциональные и нефункциональные требования (часть 2)

    В первой части эксперимента было описано, почему проблема мошеннических платежей (fraud) стоит остро перед всеми участниками рынка online-платежей, какие сложности на пути создания собственной системы мониторинга мошеннических платежей (antifraud-системы) предстоит преодолеть, и почему для большинства мерчантов такие системы – дорогое удовольствие, за которое они не всегда готовы платить.

    Еще одно, усложняющее разработку подобных систем, обстоятельство — то, что antifraud-система является business-critical системой и ее простой будет вести либо к остановке бизнес-процесса (приема оплаты), либо при некорректной работе системы к увеличению рисков финансовых и репутационных потерь для компании (интернет-магазина, банка).

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

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


    Нефункциональные требования


    Атрибуты качества


    Про выбор атрибутов качества
    Не буду растягивать описание объяснением, почему я включил те иные атрибуты качества, так как такое объяснение носит очевидный характер, если принять во внимание тип проектируемой системы – business critical.

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

    Атрибуты качества:
    • распределенность;
    • отказоустойчивость;
    • высокая масштабируемость;
    • надежность.

    Законодательные ограничения


    Законодательные ограничения, являются одним из важных факторов, определяющих программную архитектуру антифрод-системы.
    Так, согласно требованиям стандарта PCI DSS, нельзя хранить полный номер карты (PAN)* или код безопасности (CVV). Разрешено хранить первые шесть и последние четыре цифры карты. Также ничто не запрещает генерировать внутренний уникальный идентификатор для карт клиентов. Имя держателя и срок экспирации карты разрешено передать только по защищенным каналам.

    * О хранении номера PAN
    На самом деле на высоком уровне (где-то на 80-ом :) сертификации стандарта PCI DSS разрешается хранить PAN в зашифрованном виде.

    Кроме требования стандарта PCI DSS необходимо выполнять положения закона «О персональных данных» (152-ФЗ).
    Обсуждение всего многообразия технико-бюрократических процедур (с вытекающими юридическими тонкостями), необходимых просто для хранения, обработки фамилии, имени клиента, скорее всего, займет 10 листов инструкций и 1,5 месяца работы на реализацию этих инструкций (шутка, но отчасти). Поэтому лучший способ не создавать себе лишней работы соблюдать положения 152-ФЗ – не попадать под его действие.

    В проектируемой антифрод-системе все программные модули будут работать с деперсонифицированными данными.

    Подытожив, ограничения, носящие юридический характер, добавим к системе следующие требования:
    • не хранить PAN и CVV карты в любом виде;
    • другие платежные данные хранить только в защищенном виде;
    • передать информацию между мерчантом (программным клиентом) и антифрод-системой только по защищенным каналам связи;
    • работать только с деперсонифицированными данными.

    Функциональные требования


    Требование к API


    Для начала рассмотрим требования к системе с точки зрения внешнего мира, т.е. программных клиентов (мерчантов). Программные клиенты взаимодействует с антифрод-системой в соответствии со следующими требованиями к API:

    Функциональные:
    • Предоставить клиенту API для отправки данных о платеже;
    • Вернуть клиенту результат предсказания является ли платеж мошенническим;
    • Предоставить клиенту API для корректировки результатов проведения платежа.

    Нефункциональные:
    • Предоставить общедоступный протокол взаимодействия с клиентом;
    • Вести взаимодействие с клиентом только по защищенным каналам связи.

    Бизнес-требования


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

    Проверка корректности введения платежных данных


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

    Необходимо проверить содержит ли имя держателя карты хотя бы 2 буквы (тире и цифры в имени приемлемы), является ли карта действующей (у карты есть срок действия), проходит ли номер карты проверку алгоритмом Луна.

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

    Проверка является ли транзакция мошеннической


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

    Поэтому перечислю лишь основные и, в общем случае, наиболее эффективные эвристики:
    • одна карта – много IP, и обратный случай: один IP – много карт;
    • одна карта – много покупок/неудачных попыток;
    • один клиент – много карт (особенно эмитированных различными банками);
    • один клиент – много индексов, email'ов;
    • имя клиента не совпадает с именем владельца эккаунта на сайте мерчанта (если есть);
    • страна клиента не совпадает со страной владельца эккаунта на сайте мерчанта (если есть);
    • оплата происходит ночь (по локальному времени клиента).

    Но «много» это сколько? За какой период времени (5 секунд или 2 недели)? Как обойти проблему, что вес фильтра x1 в не равен весу фильтра x2, а величины их весов должны динамически меняться в процессе работы приложения?

    Часто основным подходом является наивное присвоение фиксированного значения для какого-то из фильтров и последующая обработка этих условий в конструкциях типа (это псевдокод, а не 1С):

    if (количество_карт_с_одного_ip > 4) {
    	статус_платежа = отклонен;
    	return;
    }
    else {
    	if (количество_покупок_с_карты_за_1_час > 5) {
    		статус_платежа = отклонен;
    		return;
    	}
    	else {
    		// continuation magic…
    	}
    }
    
    // проведение платежа…                

    Даже не хочу начинать перечислять недостатки такого подхода и конечную стоимость такого кода, которая сложится из потерь от ложных срабатываний на отклонение «порядочных» платежей и пропуск фрода при небольшой смене стратегии мошенниками.

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

    Глобальные фильтры


    Глобальными фильтрами я называю списки, при наличии плательщика в которых, проводить все остальные проверки – валидность платежных данных, проверка на фрод – бессмысленно. К таким спискам я отношу блэклисты банковских карт, IP, стран, мерчантов.

    Глобальные фильтры могут быть как статическими, так и динамическими, могут быть связанны как с бизнес-правилами (мерчант не принимает платежи из Арктики), так и с детектированием аномальной активности (IP адрес).

    Заключение 2-ой части


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

    Мы собираемся создать отказоустойчивый высокомасштабируемый надежный antifraud-сервис, который «снаружи» будет открыт для программных клиентов через REST API (https), а «внутри» – содержать логику, основанную на методах машинного обучения. Для придания еще большей интриги скажу, что сервис будет работать на одной из публичных облачных платформ.

    В следующей части мы, наконец, займемся делом рассмотрим программную архитектуру antifraud-сервиса, его модульную структуру и ключевые детали реализации такого сервиса.
    Share post

    Comments 42

      +1
      Мда… Какое многообещающее начало было в первой части и какое разочарование по прочтению 2-й.
      Я надеялся услышать хотя бы рекламу нового продукта. А получил рассуждения на уровне обзора по верхам.
      Хотя для хаббра этого достаточно. Обычно такой информацией (более глубокой) никто не делится. Только в разговорах на всяких специализированных тусовках.

      К слову:
      «Вернуть клиенту результат предсказания является ли платеж мошенническим;» обычно не так однозначно 1/0. и не одним критерием…
      «одна карта – много IP, и обратный случай: один IP – много карт;» так не делают. Весь мир пока еще в рамках IP4 и почти все IP клиентов серые. Типичная проверка не по IP а по территориальной градации (информация по IP) и dT между транзакциями.
      Совсем не назвали важные критерии по типам покупок (ювелирка и пр. высоколиквидные)

      В общем, лично у меня, сложилось впечатления, что «в живую» Вы с этими системами не работали. А так слышали около + свои мысли на эту тему. Я прав?

      — Вдогонку…
      «срок экспирации» ну что за жаргонизм. Либо по «Срок действия» либо «expiration date»
        0
        «Вернуть клиенту результат предсказания является ли платеж мошенническим;» обычно не так однозначно 1/0. и не одним критерием…
        Вы выдаете желаемое за действительное: где написано, что на основе одного критерия вернется является ли транзакция мошеннической или нет?
          0
          Функциональные:
          •Вернуть клиенту результат предсказания является ли платеж мошенническим;


          Сказано однозначно. одна из функций сервиса — «результат предсказания».

          Лично я эту фразу воспринят, что «результат предсказания» это 1/0.
          Может не правильно интерпретировал фразу.
          Обычно дается рекомендация (вероятностная и по нескольким критериям). А принятие решение возлагается на «продавца».
          Сервис же (если опять же правильно понял) outsource?
          Такие сервисы у себя могут потянуть только крупные «продавцы».

            0
            Может не правильно интерпретировал фразу.
            Я понял. Конечно, я это неудачно выразился: возвращается вероятность того, что платеж окажется мошенническим — число от 0 до 1.
            Рекомендации для клиентов сервиса еще будут описаны в 4-ой заключительной части статьи.
        0
        Дмитрий, присоединяюсь к первому комментатору с вопросом: проектируемая антифрод-система может по результату анализа транзакции отвечать только «да» или «нет» (разрешить или пропустить транзакцию)? Какие-то ещё ответы в неё заложены?
          0
          По идее это может быть «да», «нет» и «подозрительная» (для ручной проверки) или вместо «подозрительная» число от 0 до 1 с вероятностью того что транзакция фродовая.
            0
            Зависит от выбранного алгоритма машинного обучения — Two Class или Multiclass. Я реализовал Two Class — возвращает число в диапозоне от 0 до 1, где единица — фрод.
              +1
              О! так Вы еще и обучение машинное хотите впихнуть! Или вообще нейросети…

              Очень советую, заранее завести специальную службу, которая будет отвечать на звонки и объяснять почему то или это произошло, и как вернуть все к понятным человеку критериям/условиям проверок.

              Не работают нейросети в таких задачах. У них основная проблема: решение есть, а объяснения ему нет.
              А объяснение понадобится.
                0
                Спасибо за совет про саппорт. В контексте статьи и моего комментария (где не говорил, какой конкретно алгоритм будет использоваться) — ему цены нет.
                  0
                  Зависит от выбранного алгоритма машинного обучения


                  В контексте статьи и моего комментария (где не говорил, какой конкретно алгоритм будет использоваться)


                  Ирония… это хорошо. Только зря обижаетесь.
                  Вопрос: а вы хоть этим занимались когда ни будь живьем?
                  0
                  Ну отчего же… сами по себе нейросети на таких задачах очень неплохо работают :)
                  А вот с вытекающей проблемой согласен — они как «чёрные ящики» при этом.
                    +1
                    «Не работают» я имел в виду, что объяснить разгневанному VIP клиенту (а затем и его другу в правлении… одному из топов) почему у него/его жены/любовницы «не получилось».
                    Фраза «потому что нейросеть так решила» приведет к увольнению сотрудника сразу.

                    А если сотрудник сможет объяснить:
                    «Ой! у нас тут стоит проверка, что если человек в течении 2 часов делает покупки в разных странах ювелирки на более чем $10000, то мы считаем, что это подозрительно. Ща поправим для этого клиента!»
                    Тут обойдется без увольнения. Даже польстит это VIP, что за него беспокоятся.

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

                      0
                      Правда я сужу со стороны банка эмитента…

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

                          Это до тех пор, пока мерчант не предоставляет уникальные услуги (примеры: ж/д-билеты на конкретную линию, билеты на конкретный спектакль и так далее). Вот тут приходится экспериментировать с картами (я как-то раз перепробовал четыре прежде чем мне-таки продали нужное), звонить в поддержку банка и так далее.
                    0
                    Если нейро-сеть будет обучена правильно и будет реально ловить мошенничество + адаптироваться к новым тенденциям фрода, то такой вопрос решится быстро. Мой антифрод ловит мошенников больше, чем отпугивает клиентов. Профит.
                    Потом не обязательно транзакцию сразу отклонять. Давайте сделаем её подозрительной и отправим на 3DS, перенесем ответственность на эмитента и все. Не прошли 3DS это веская причина для клиента чтобы отклонить транзакцию.
                0
                Следующий вопрос, опять же извиняюсь, если забегаю вперёд.
                Вот например антифрод-система отклонила транзакцию на основе логики модели внутри неё. А есть ли механизм для того, чтобы понять конкретную причину такого решения? Грубо говоря, как понять, что именно с операцией не так? Какие признаки и параметры операции оказались наиболее значимыми в процессе принятия решения о её запрете?
                  0
                  Предполагаю, что Вы именно забегаете вперед. Я участвовал в свое время в разработке антифрод-системы. Там был реализован функционал получения причины отклонения транзакции. Более того, это musthave функционал. Ибо рассерженный клиент может позвонить в техподдержку, и ему надо как то объяснить, почему у него не получилось оплатить товар/услугу.
                    0
                    Да-да, в первую очередь это нужно как раз для спасения клиентов (не говорю уже про аналитику работы системы в целом).
                    Ну тогда я надеюсь, что автор в следующих двух частях этот механизм опишет.
                      0
                      Откуда знаете, что будет еще две части? ;)
                    0
                    Возможность узнать причину отклонения зависит от выбранного алгоритма: для дерева решений — возможно, для нейросети — нет.
                      0
                      Так-то оно так, но это свойства алгоритмов :)
                      А вопрос был в реализации вашей системы — будут ли в ней механизмы для получения статистики по запретам транзакций?
                        0
                        Статистики по каким признакам было запрещено или отношение разрешенных/запрещенных? По первому — нет, по второму — да (лог транзакций будет храниться в NoSQL-хранилище).
                          0
                          Я имел в виду получение ответа на вопрос «Почему/по каким признакам была запрещена конкретная транзакция?» (в случае, если алгоритм принципиально позволяет получить такие данные). Понятно, спасибо.
                        0
                        (В качестве оффтопика. Я сам не пробовал, но вообще существуют механизмы для извлечения правил из нейронной сети: "Fraud Detection Model Based on the Discovery Symbolic Classification Rules Extracted from a Neural Network". Если есть интерес, могу лично поделиться полным текстом статьи.)
                    0
                    И главный вопрос, раз уж интрига раскрыта.

                    Вы пишете про «business-critical» и «отказоустойчивость», и в общем-то и так понятно, что риалтаймовая система такого плана должна иметь достаточно жёсткий SLA. А потом вдруг — «публичная облачная платформа». Как одно с другим вообще вяжется? Или подразумевается, что вы у той платформы покупаете гарантированный минимум ресурсов и подписываете соответствующие SLA по производительности и отказоустойчивости? А как же тогда заявленная стоимость сервиса «на порядки дешевле»?

                    И другое. Как вы собираетесь уговорить мерчантов отдавать данные о своей платёжной истории куда-то в публичный облачный сервис? Всё понятно, что данные неперсонифицированные, 152-ФЗ соблюдается и так далее, но поверьте, мерчанты даже в таком случае особо не разбегаются отдавать наружу такие данные, там как минимум интересная финансовая информация в цифрах. Для мерчанта идеально, когда такие данные вообще не покидают его собственную эко-систему (то есть антифрод работает внутри неё, например на их же мощностях), возможно некоторые пойдут на то, чтобы отдавать такие данные на ваши серверы как провайдера антифрод-системы, и то при соответствующих NDA-соглашениях и т.д. Но в публичное облако?! Этот вопрос в первую очередь не о надёжности облачных сервисов, а о психологии мерчантов и агрегаторов.
                      0
                      У облачной платформы есть SLA (у различныхсерсисов различный, но ниже 99.95% он не опускается). Вореры работают в кластере, для сетевых подключений используется retry-policy. Поэтому, будьте уверены, при правильном выборе архитектуры — это крайне отказаоустойчивое решение.
                        0
                        Вопрос в том, как посчитать конкретный SLA вашего решения, и что делать, если облачная платформа свой SLA провалила, и вследствие этого вы провалили свой.
                          0
                          Я не сомневаюсь в надёжности и отказоустойчивости современных облачных сервисов. Но всё равно, к первому предложению хорошо бы добавить «как правило» :)

                          Ну в итоге я правильно понял, что вы это облако используете полностью как публичный бесплатный сервис? Или всё таки у вас с провайдером облака какие-то договорные отношения есть?
                          0
                          мерчанты даже в таком случае особо не разбегаются отдавать наружу такие данные
                          Все дело в мотивации — сначала надо узнать, во сколько конкретному мерчанту обходиться фрод.
                            +1
                            Эту информацию даже под пытками никто не раскроет.
                            Особенно кому попало.
                              0
                              Я тут не бизнес-план описываю, а набор подходов и методик для создания эффективного (в плане стоимости разработки и владения) антифрод-сервиса. Не путайте, пожалуйста.
                            0
                            Ну, знаете, в некоторых странах такое с безопасностью творится… диву даешься. Что-то типа одного криптографического ключа на все страну. Или своеобразных реализаций методов шифрования. Так что может и пойдут. Впрочем, это не я не про Россию, а ваш проект, как можно понять, ориентирован в основном на нашу страну?
                            0
                            codezombie, вы используете Machine Learning? Или в вашем случае — это неэффективно?
                              +1
                              Machine Learning — это вы про машенное обучение или про облачный сервис в Azure?
                              И то и другое must have и будет описано в следующих частях статьи.
                              0
                              codezombie, давайте вы в следующих частях сделаете картинки для описания мат. модели или других алгоритмов, если таковые будут.
                              Надо лучше прорабатывать материал, основных эвристик намного больше. Вы рассматриваете методики защиты от фрода и забываете про fingerprint'ы, proxy, AVS, проверки IP и другие.

                              Вы посчитали косты системы на основе правил и сказали, что дорого. А обучать нейросеть бесплатно что ли? Допустим даст она обнаружение на 5% меньше ошибок 1 рода, а покроет это затраты на разработку? Там проблем больше чем кажется. Нужна тестовая среда. Её постоянно надо актуализировать, и проверять эту нейросеть. Ввод новых правил в систему, это пересмотреть веса всех остальных правил. Настройка пороговых значений при принятии решения. Это все not easy — not so cheap.

                              Я в целом поддерживаю вашу идею и мне кажется она рабочей, но сделайте достойный анализ, опишите подробнее.
                                0
                                и забываете про fingerprint'ы, proxy, AVS, проверки IP и другие.
                                Что вы имеете под терминов AVS я не понял. Про остальное не забываю: fingerprintы — это зона ответственности клиента, а не антифрод-сервиса, proxy — не вижу смысла, про списки IP писал в этой статье.
                                Комментарий ко второй части вашего коментария — где вы видите, чтобы я писал, что в рамках статьи собираюсь обсуждать бизнес план? No money, only IT!)
                                +1
                                Машинное обучение не только теоретически, но и практически реально и более того, оно используется для защиты от мошенничества. Да, есть много нюансов, и вопрос производительности является одним из самых острых. Но современные Big Data системы очень сильно с этим помогают, вот например статья: Real Time Fraud Detection with Sequence Mining

                                Что касается 1 и 0 (мошенничество или нет) — такой подход не особо гибкий. В общем случае система может передавать клиенту число (пусть будет 0-100%), и клиент уже решает что с этим делать. Например (выдуманный пример), если это 80%, то транзакция помечается как требующая подтверждения покупки телефонным звонком, если это 60% то включается дополнительная аутентификация (скажем, подтверждение покупки через электронную почту) и т.д. Но для ознакомительных целей разделение да/нет вполне подходит.
                                  0
                                  то касается 1 и 0 (мошенничество или нет) — такой подход не особо гибкий.
                                  Подождите, где прочитали про 1 или 0? Я писал про диапазон числовых значений от 0 до 1 (что представляет собой вероятность того, что транзакция является мошеннической).
                                  Более подробно алгоритм машиного обучения еще будет описан в заключительной чевертой части статьи.
                                  0
                                  Я по этому списку пролетаю со скоростью ветра.

                                  Заказываю в интернетах чаще всего ночью, карточки у меня пяти разных банков, адреса доставки — три штуки в двух разных странах, страна доставки не совпадает со страной-эмитентом и не совпадает по валюте ни со страной доставки, ни со страной эмитентом, IP'шники меняю как попало и часто забываю выйти из VPN'а и могу один заказ сделать с одного IP, а через 3 минуты — с другого, который примерно на 4 т.км. западнее первого.

                                  Однако, работает. И, кстати, cvv спокойно сохраняют и пользуют для подписки без каких-либо проблем.
                                    0
                                    Вот кстати, да. Я хотел аналогичное написать — у меня разве что с адресами доставки не так, но у меня вообще последнее время нет никаких адресов доставки, я разные не очень материальные вещи покупаю.

                                  Only users with full accounts can post comments. Log in, please.