Как стать автором
Обновить

Комментарии 42

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

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

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

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


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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Публикации