Как мы фрод из избы выносили
Меня зовут Никита, я backend-разработчик из команды антифрода в Ситимобил. Сегодня я поделюсь с вами историей о том, как мы выносили наш сервис из монолита в отдельный сервис, как вообще пришли к этому решению и с какими проблемами столкнулись.
Для начала немного расскажу о нашем сервисе.
Антифрод 101
Наш антифрод — это набор правил для выявления заказов, содержащих признаки мошенничества, фродовые паттерны.
Водители, которые пользуются сервисами агрегаторов такси, имеют возможность получить бонусы за короткие поездки, на чём водители-мошенники пытаются нечестно заработать. Например, мы видим у одного водителя n заказов подряд с одним и тем же клиентом. Чем они там занимались, нам не ясно, но с большой уверенностью можно заявить, что это фрод и аннулировать эти заказы.
Клиентам начисляются бонусы в случае приглашения ими новых клиентов в приложение. Клиенты-фродеры регистрируют несколько новых клиентов на своем девайсе, за что могут потерять все начисленные бонусы.
Чтобы проверить водителя на мошенничество, мы запускаем все проверки и в результате получаем события, каждое из которых говорит о наличии искомого паттерна в поданных на вход заказах.
Проверки можно разделить на несколько типов:
Для настройки правил есть web-интерфейс — «админка». И для визуального контроля за сработавшими правилами мы создали web-страницу с разными отчетами с большим набором фильтров.
Добавление новой проверки происходит следующим образом: описали фродовый паттерн, закодировали его в сервисе, запустили новое правило в тестовом режиме, и наблюдаем. При необходимости корректируем правило и включаем.
Проблемы прежней архитектуры
Раньше компания-партнер могла получить деньги только при проверке всех своих водителей на фрод.
Антифрод работал внутри PHP на одном потоке. Не масштабировался без костылей, в пиковые часы возникали очереди на проверку. Сами проверки никак не распараллеливались, и добавление каждого нового правила неизбежно увеличивало время обработки.
Старый антифрод «перерос» свою модель БД, работать с базой стало невозможно: периодически клали базу при работе, что в условиях монолитной архитектуры приводило не только к проблемам антифрода, но и всего бизнеса в целом.
Отчёты строились медленно. Чтобы посмотреть, казалось бы, простые вещи руками в базе, иногда приходилось JOIN-ить по пять и более таблиц, не говоря уже о более сложных вещах.
Бизнес рос, и эти проблемы требовали скорого решения. Также хотелось проверять водителей на фрод «на лету» (после каждой поездки).
Какие у нас были варианты:
Выбор пал на уход антифрода в отдельный сервис. В качестве основного инструмента распараллеливания был выбран Golang, по которому в компании есть хорошая экспертиза.
Решено было переезжать в два этапа.
Первый этап: перенос на новый язык
Остались на старой модели данных (да, скрипит, но пока работает). Стали делать сервис с нуля, за пару месяцев перенесли основной функционал и большинство проверок. Добились полной работоспособности сервиса.
Теперь каждая проверка по одному заказу может запускаться параллельно, что значительно уменьшает время обработки.
Сравнительные характеристики по скорости обработки: ранее на анализ всех водителей уходило 6 часов, теперь 25 минут.
Второй этап: выбор модели хранения
Для текущей работы нужна была как OLTP-подобная база данных для анализа на фрод, так и OLAP-база для построения отчетов. Текущая схема данных не поддерживала сценарии антифрода, от слова «никак».
Мы выбрали Elastic. Он легко масштабируется, в нём «из коробки» есть индексы по любому полю, что позволяет настраивать фильтры в отчетах как душе угодно. Денормализовали модель, чтобы не приходилось делать JOIN’ы между индексами Elastic’а.
Если вы тоже решили выбрать Elastic в качестве базы данных, то будьте бдительны. При настройках по умолчанию Elastic под нагрузкой может начинать отдавать частичный результат поиска. Например запрос стаймаутится на нескольких шардах при этом код ответа будет 2xx. Если вас не устраивает такое поведение и вам лучше получить ошибку поиска (например, чтобы потом заретраить), то вы можете отрегулировать это поведение через параметр allow_partial_search_results.
Текущая схема работы антифрода
Напомню, что основная логика, связанная с поездками, живет в монолите, а вся информация по заказам всё еще лежит в MySQL. При завершении поездки монолит переносит заказ из таблицы активных заказов в таблицу закрытых и отправляет сообщение в наш сервис через RabbitMQ, чтобы мы проверили конкретный заказ.
Получая сообщение из RabbitMQ, можно было бы сразу порождать горутину для обработки сообщения и переходить к получению следующего сообщения, но при таком подходе никак не контролируется количество горутин. Поэтому в сервисе количество обработчиков регулируется динамически с помощью пула воркеров.
Приступая к обработке сообщения, сервис антифрода идет на слейв MySQL, считывает все нужные нам данные по заказу из разных таблиц, записывает их к себе в Elastic, а потом посылает сам себе сообщение проверить этот же заказ. При проверке захватывает распределенный lock на Redise, чтобы предотвратить параллельную обработку объекта при особо интенсивных запросах, например, при частом обновлении водителя или клиента. В случае нахождения фрода сервис отправляет сообщение об этом монолиту.
При построении отчетов в админке сервис вызывается через REST API.
Всё это позволяет оказывать на монолит минимальное влияние.
Теперь подробнее
Читатель мог заметить парочку проблем:
Начнем с решения второй проблемы.
Наш RabbitMQ внутри состоит не просто из двух очередей (входящей и исходящей), но еще и третьей — очереди повторных попыток (retry).
У этой очереди есть producer, но нет consumer’а. На ней настроена политика dead-letter: по истечении своего TTL сообщение попадает обратно во входящую очередь, и мы обработаем это сообщение.
Иными словами, если мы получили сообщение на проверку заказа, но на слейве этого заказа еще нет, то мы просто будем помещать это сообщение каждый раз в retry-очередь, пока заказ не появится. С помощью этого подхода можно ретраить временные ошибки, а при превышении количества попыток на обработку этого сообщения отбрасывать его с записью об ошибке в лог.
А теперь вернемся к первой проблеме.
Самый быстрый и самый плохой вариант — делать refresh индекса при любой операции записи. Разработчики Elasticsearch советуют быть крайне осторожными с таким подходом, это может привести к снижению производительности.
Есть другой вариант: сразу передавать в сообщении всю информацию о заказе, а не считывать его со слейва. Но тогда размер сообщения вырастет на несколько порядков, что увеличит нагрузку на наш кролик, а мы его стараемся беречь. К тому же структура считываемых данных меняется достаточно часто, и изменения модели как в монолите, так и в сервисе хотелось бы избежать.
Может быть, проверять заказ сразу, как только прочитали его со слейва? Можно, только вот большинство наших проверок всё-таки делают вывод на основе нескольких заказов, то есть в базу лезть всё равно придется за остальными заказами. Зачем усложнять логику, если можно воспользоваться тем же механизмом retry-очереди?
Выставляя TTL сообщений в retry-очереди больше интервала обновления индекса Elastic, мы забудем о первой проблеме раз и навсегда.
Подробнее про механизм dead-letter можете почитать например тут.
Немного про наши тесты
Ошибки в логике правил антифрода совершать опасно: это может привести к массовым денежным списаниям. Именно для этого мы стремимся к 100% покрытию важных участков кода. Для этого мы используем библиотеку testify, mock’ая внешние зависимости и проверяя правила на работоспособность. Также у нас есть функциональные тесты, проверяющие основной флоу обработки и проверки заказа.
Вместо выводов
Переписав весь антифрод, на выходе мы обеспечили себе уверенность в нашем сервисе при дальнейшем росте бизнеса в течение следующих нескольких лет. Решили важную бизнес-задачу, благодаря которой честный водитель уверен в получении своих честных денег сразу после выполненной поездки.
Безусловно, некоторые задачи, которые выполняет наш сервис, остались за занавесом NDA. А некоторые задачи просто не влезли бы в одну статью.
Быть может, в следующий раз я вернусь с рассказом о том, как мы анализируем на фрод действия пользователей, где нагрузки на порядки выше.
Про Такси
Всем привет! Сегодня мы разберемся, что такое Фрод, какие виды фрода бывают, как его можно выявить и бороться с ним.
Оглавление
Фрод (от англ. fraud, «мошенничество») — вид мошенничества в области информационных технологий, в частности, несанкционированные действия и неправомочное пользование ресурсами и услугами.
Мошенничество с платежными картами, кардинг (от англ. carding) — вид мошенничества, при котором производится операция с использованием платежной карты или её реквизитов, не инициированная или не подтверждённая её держателем.
Реквизиты платежных карт, как правило, берут со взломанных серверов интернет-магазинов, платежных и расчётных систем, а также с персональных компьютеров (либо непосредственно, либо через программы удаленного доступа: «трояны», «боты» с функцией формграббера).
Типы фрода такси
На данный момент мы установили несколько типов фрода в такси:
Фрод с купонами
Это достаточно простой способ для клиентов совершить несколько бесплатных поездок за счет промо-тарифов агрегатора, вовлекающего новых пассажиров в систему. Для такого мошеннику нужно 2 телефона и возможность установить на них приложения
Работает следующим образом:
Ну сколько можно так прокатиться? У меня всего 2 друга, кто мне будет говорить смс-коды для активации новых аккаунтов?
Кардинг и «заливы» на водителей
Что такое кардинг, вы уже знаете. Но между тем, чтобы украсть данные карты и получить кеш, существует большая пропасть. У злоумышленников стоит задача заполучить деньги с карт, для этого им подходят водители такси. Возможно, вы слышали или сталкивались с таким предложением. Как правило, услышать его можно в такси бизнес-класса, клиент говорит водителю:
«Все поездки на такси мне компенсирует Газпром, могу ездить сколько угодно. Если хочешь, можешь ездить по своим делам, а тебя буду заказывать, все полученные деньги поделим пополам. Тебе же все равно нужно ездить, а так двух зайцев: ты и по делам съездишь и половину от тарифа получишь. »
Далее такие клиенты заказывают водителя, обычно с разных аккаунтов, бывает что иностранных, водитель выводит деньги и делится со злоумышленником. Рано или поздно такого водителя блокируют. Так же возможно, что выставят счет за поездки, которые не были оплачены.
Работа с ломанным GPS (Таксометр)
ТАКСОМЕТР ДЛЯ РАБОТЫ:
• Увеличенное время принятия заказа;
• Подмена координат (fakeGPS) (Возможность поставить себя в очередь в аэропорту физически там не находясь);
• Подмена фотоконтроля (возможность вставить свои фотографии во время фотоконтроля для получения приоритета);
• Отклонение от заказа без потери активности;
• Инфоокно с категорией заказа и расстоянием до клиента;
• Для установки нужны root права на телефоне и установленный xposed (Что это такое ищите на 4pda.ru);
• Обновления редкие, но платные.
Платформа Android допускает большую гибкость в плане настройки и прав доступа со стороны пользователя. Благодаря стараниям энтузиастов на просторах интернета существуют такие предложения.
Само по себе использование такого софта нарушает правила сервиса ЯТ и ведет за собой блокировку. Но в случае с комбинированием данного инструмента с кардерами и получается самая опасная связка. В такой схеме водители по чужим документам регистрируются в автопарках удаленно. Как правило, выбираются автопарки с моментальным выводом средств. После регистрации они начинают усиленно «катать» и выводить заработанное.
Вскоре антифрод-система Яндекс распознает таких «водителей» и блокирует их, списывая в минус всё заработанное. Только вот проблема в том, что автопарк уже выплатил эти деньги, получается обманут автопарк. За большое количество фрондеров в парке может последовать блокировка самого парка, так что инструмент антифрода актуален, как никогда. В следующей статье мы расскажем, какой результат дает наш антифрод при выявлении таких мошенников.
Удлинение поездок без ведома клиента
Самый глупый из всех видов фрода, глупее только обманывать клиентов и просить оплатить наличными поездку с оплатой по карте. Суть заключается в том, что водитель, при получении безналичного заказа, не завершает поездку на месте высадки клиента, а начинает кружить со включенным счетчиком. У клиента списывается сумма, превышающая стоимость поездки, водитель выводит деньги ДО того, как поступит жалоба клиента и по ней сделают возврат. К сожалению от таких джентльменов не застрахован никакой парк. Но к счастью, сумма ущерба по такому фроду не может быть большой, так как:
Редакция не рекомендует использовать Фрод, Фрод для слабаков, зарабатывать надо головой.
Создание системы антифрода в такси с нуля
Добрый день. Меня зовут Никита Башун, работаю дата-аналитиком в группе компаний «Везёт». Мой рассказ будет о том, как мы командой из трёх человек с нуля создавали систему антифрода для сервиса заказа поездок.
Введение
Кто раз умеет обмануть, тот много раз еще обманет.
Лопе де Вега
Фрод в нашем случае — это ситуация, когда водитель обманывает компанию. Мошенничество с целью получения денег.
Первый код в компании был написан еще в те времена, когда о мобильных приложениях никто не слышал, доллар был по 25, а в университетах изучали Delphi. Все ловили такси на улице или заказывали по телефону. Менеджеры и кураторы городов вручную искали поездки, похожие на фрод. Процент успеха был крайне низким, и безнаказанные водители продолжали свою криминальную деятельность. Но всему в этом мире рано или поздно приходит конец…
Постановка задачи и паттерны поведения
Первоначальная цель — создать MVP, который за минимум времени разработки даст максимальный результат.
После консультаций с директорами городов, кураторами и менеджерами были выявлены самые частые схемы мошенничества:
Функции в нашей команде распределены так:
Сложности
Процесс
Основную задачу выполняет SQL-запрос в DWH, который возвращает подозрительные поездки и водителей. Те должны обладать набором заранее рассчитанных признаков. Вот, например, как выглядит фильтрация по паттерну «Бонусы»:
Признаки определяются статистически на основании исторических данных, а также путём консультаций с опытными управленцами на местах.
Еще пример. В паттерне «Воровство комиссии» ключевую роль играют координаты водителя. Отменил заказ, но отметился на всём его протяжении? Ну-ну. Считаем расстояния, добавляем ещё несколько важных фильтров и выгружаем такие поездки.
Далее в работу вступает скрипт на python. Он оборачивает выгрузку в pandas, сохраняет ее в postgres, преобразует в нужный вид и выгружает на проверку в листы Google (о них мы еще поговорим подробнее). Часть скрипта, выгружающая поездки, запускается автоматически дважды в день с помощью Apache Airflow.
Рассмотрим работу с API на примере.
Считываем креды и коннектимся:
Добавляем данные на лист:
В самой postgres для каждого паттерна реализовано две таблицы:
Менеджеры на местах проверяют поездки на наличие ошибок первого рода (казнить нельзя, помиловать).
Пример того, как выглядит работа менеджера с листом:
Иногда по всем признакам сразу видно — водитель фродил.
Иногда приходится копать глубже: смотреть трекинг, вызывать водителя в офис, созваниваться с пассажиром.
И так для каждого паттерна.
К сожалению, без ручной проверки на данный момент никак не обойтись. Очень часто встречаются две идентичные поездки, но одна из них оказывается фродом, а вторая — нет. Для максимизации доли «пойманного» фрода приходится идти на жертвы и подозревать честных водителей.
На картинке справа наша FP-ошибка будет равна нулю, но мы не поймаем многих мошенников.
На картинке слева — поймаем всех, но нужна дополнительная проверка, чтобы определить невиновных. Это наш выбор.
После подтверждения факта фрода в игру вступает «карательная машина правосудия». В зависимости от степени тяжести, рецедивов и общей ситуации в городе, водителя:
На данном этапе мы лишь наблюдаем и логируем информацию.
Отмечу, что результат работы зависит от населённого пункта. Города различаются по населению, площади, уровню конкуренции, условиям для водителей, менеджменту. Для примера сравним кол-во подозрений и фрода за последние недели:
Как видите, подобрать универсальные правила и для Новосибирска, и для Магнитогорска — нетривиальная задача.
Важную роль во всей системе играют Google Spreadsheets. Они выступают интерфейсом между бэкэндом и конечными пользователями. Несколько лет назад я скептически относился к их использованию в проектах, но на практике они показывают себя очень хорошо:
Самая большая проблема
Ручная проверка является важной частью системы антифрода. А там, где люди — там ищи проблемы:
Для борьбы с подобным отношением мы, вместе с кураторами, разрабатываем уголовный кодекс строгий набор правил. Он будет обязательным для всех, оставляя минимум возможностей для «творчества».
Описанное выше — стандартный рабочий процесс, рутина. Все без исключения наши коллеги — ответственные профессионалы, которые качественно выполняют свой этап работы и помогают нам совершенствовать систему. Спасибо им за это!
Развитие и первые результаты
Как мы совершенствуем алгоритмы, то есть снижаем ошибки?
В начале нашего пути ошибка по самому масштабному паттерну (воровство комиссии) в среднем составляла около 35%. Сейчас — меньше 25%. В то же время, по другому паттерну — бонусам — удалось не только свести ошибку к нулю, но и в десятки раз уменьшить количество таких случаев. Выдвинем гипотезу: водители поняли, что теперь за подобное наказывают, и решили, что риск не стоит свеч. И придумали другие схемы.
За первые месяцы работы удалось достичь следующих результатов:
Но самый главный успех — это постепенное снижение самих случаев подозрения во многих городах. Ведь, в идеале, мы не хотим ловить больше, мы хотим, чтобы ловить было нечего.
Заключение
Я постарался описать основной функционал и принципы работы системы антифрода, а также сложности, с которыми мы столкнулись. В планах: использование ML для оптимизации поиска, создание системы мониторинга санкций (сейчас она на начальном этапе), улучшение интерфейса для работы менеджеров, создание динамической отчетности, разработка новых паттернов и многое другое.
10 способов мошенничества, которые используют таксисты
Олег Чанчиков из петербургской компании «Доступный город» — партнёра крупных такси-сервисов — рассказал vc.ru о способах фрода, которые могут применять таксисты, и объяснил, как пассажирам их избежать.
Привет, я Олег, и иногда я рассказываю о том, как устроено такси изнутри. Вот здесьписали про девушку, пытавшуюся обмануть Uber. Сегодня я расскажу о том, как и кого еще фродят таксисты.
Моя компания придумывает и реализует интеграционные решения для водителей такси — от аренды автомобилей до финансовых инструментов для выплаты денег за безналичные заказы. Мы находимся между провайдерами заказов и водителями такси. Это на наш счет приходят деньги от Uber, и это мы выплачиваем их дальше — тому, кто вас везет.
Один из продуктов нашей компании — моментальные выплаты. Мы умеем выплачивать деньги водителям сразу после выполнения заказа — при том, что деньги от провайдеров приходят с задержкой от трех дней до месяца. Любая попытка обмана со стороны водителя — наш риск не получить деньги от провайдера. Так появился проект «Антифрод», который нужен нам, чтобы быстрее провайдеров узнавать о том, как еще водитель такси может обмануть пассажира или провайдера.
Что-то мы рассказываем провайдерам — когда фрод угрожает нашему бизнесу. Что-то не рассказываем совсем — когда дырка очевидна всем (и самому провайдеру в том числе). С чем-то работаем самостоятельно и не выносим сор из избы — как правило, с новичками, решившими, что уж их-то точно никто не заметит.
Жизнь богаче фантазии и то, с каким фродом мы столкнемся завтра, наверняка удивит нас еще больше, чем эта статья.
Как любой нормальный человек, водитель хочет денег. Не всегда больше, но всегда — легче. Ему не важно, кто именно эти деньги заплатит — пассажир или провайдер. Главное, чтобы никто не заметил и все остались довольны.
1. Дублер
«Яндекс.Таксометр» (софт для водителей «Яндекс.Такси») позволяет водителю, помимо заказов самого провайдера, работать с заказами «от борта» — пойманными на улице. Водитель может создать для таких заказов любой тариф, который его устроит.
В начале поездки по такому тарифу софт произнесет ровно те же слова, что и при заказе от «Яндекс.Такси»: «Добро пожаловать. В целях безопасности просим вас пристегнуться». И интерфейс ничем не будет отличаться от того, который и вы, и водитель видите, когда едете по заказу от «Яндекс.Такси».
Алгоритм обмана вас не слишком сложный:
Этот способ безопасно использовать, если разница в финальной стоимости поездки не будет превышать 50% от оригинальной — ее все еще можно обосновать пробками, маршрутом и ошибками «Яндекса».
На ваш аргумент «А вот у меня в приложении другая сумма написана» ответят, что в приложении указана примерная стоимость поездки (это не так), а в реальности были пробки, навигатор повел иначе и вообще «Яндекс» считает поездку по прямой от точки А в точку Б, а машина ездит по дорогам (и это тоже не так). В реальности «Яндекс.Такси» по завершении поездки показывает вам точную стоимость этой поездки.
Вы расплачиваетесь, выходите из машины, и у водителя начинается следующий этап магии: надо сделать так, чтобы суммы на устройствах А и Б совпали. Это нужно для того, чтобы ваше приложение показало вам ту же стоимость поездки, что и сумма, которую вы в реальности заплатили.
Самый крутой случай из нашей практики — пассажир ехал из Пулково на Московский вокзал и трижды проехал через Кронштадт. Поездка по КАД через Кронштадт по желанию клиента — платная услуга в «Яндекс.Такси», она стоит 400 рублей.
Удивительно, но этот способ работал почти без сбоев. Ключевая задача водителя — сделать так, чтобы пассажир был доволен поездкой настолько, чтобы ему не хотелось разбираться, почему суммы разнятся настолько сильно. Я уже писал о том, что среди водителей такси невероятно высокая доля людей с судимостью за мошенничество: с даром убеждения у коллег все тоже неплохо.
2. Подмена таксометра
Провайдеры, безусловно, хотят, чтобы водители не фродили пассажиров. Каждая новая версия софта для водителей оставляет все меньше и меньше дырок. Но голь на выдумку хитра. В этот способ фрода довольно сложно поверить: настолько он абсурден. Однако я делал это своими руками, и это работало.
Осенью 2015 года «Яндекс.Такси» обновило «Таксометр» с версии 6.37 до версии 6.39, в которой не было функции платного ожидания пассажира (как использовать для фрода — смотрите выше). При выходе обновления старая версия, естественно, перестает работать.
Вы уже догадались, да, что фейковая сборка заработала, сохранив функциональность оригинальной? Сейчас это, впрочем, уже не работает: «Яндекс» научился бороться с подобным фродом.
3. Другой пассажир
Представьте: вы вызвали автомобиль с оплатой поездки пластиковой картой. И почему-то не вышли вовремя: передумали, уехали на другой машине, задержались в душе. И не отменили заказ — так часто бывает, потому что вы считаете, что это проблема водителя.
Водитель подает автомобиль, ждет пассажира и честно едет из точки А в точку Б, которую вы заботливо указали, когда заказывали машину. Затем водитель закрывает заказ, и с вашей карты списывается стоимость поездки.
Вы, естественно, получаете SMS от банка и пишете провайдеру, что никуда не ездили. А водитель говорит: «Вышел человек, сел в машину. Я его спросил: «В аэропорт» (ну, допустим)? Он сказал: «В аэропорт». Откуда мне знать, что это не тот пассажир?».
Доказать правоту или, наоборот, фрод невозможно — что со стороны водителя, что со стороны пассажира (вам же тоже никто не мешает так фродить). Обычно провайдеры встают на сторону пассажира, возвращают деньги, а водителя блокируют. А наша задача — разобраться с тем, что произошло на самом деле. Фрод по отношению к пассажиру автоматически снижает рейтинг водителя в нашем антифроде, потому что в следующий раз на деньги можем влететь и мы.
4. Подменная координата
Это один из тех фродов, в которые мы не вмешиваемся совсем. Во-первых, они не ведут к прямым финансовым потерям ни с какой стороны. Во-вторых, мы считаем технические дырки провайдеров недоработкой и уверены, что на стороне любого оператора из «большой тройки» больше одного человека отвечает за отсутствие таких дырок.
Чаще всего этот способ используется около вокзалов и аэропортов — там, где парковка платная, заказы есть почти всегда, и их цена сильно выше средней.
Алгоритмы распределения заказов у провайдеров учитывают расстояние от автомобиля до точки подачи и время, необходимое для подачи (факторов в действительности значительно больше). Следовательно, чтобы с большей вероятностью получить заказ как можно быстрее, нужно оказаться как можно ближе к точке подачи.
Водители используют Fake GPS — софт, который подменяет координаты вашего устройства. Вы с его помощью можете, например, свайпить в Tinder в Нью-Йорке без премиум-аккаунта, а таксисты паркуют автомобили на первой линии зоны прилета или на взлетно-посадочной полосе аэропорта.
Выделяются на фоне этого относительно безобидного фрода те, кто нашел и использует Mock Location. Этот софт позволяет достаточно правдоподобно имитировать движение автомобиля по дороге: он будто бы останавливается на светофорах, снижает скорость на поворотах и может выдерживать среднюю скорость на маршруте из точки А в точку Б.
Схема фрода ничем не отличается от фрода с поездками по картам, кроме того что автомобиль не трогается с места совсем.
5. Пустая карта
Провайдеры списывают деньги с вашей карты либо несколькими небольшими частями, либо одним платежом после окончания поездки. Для пассажира это способ обмануть провайдера: некоторые из них оплачивают поездку водителю, даже если не смогли списать деньги с карты пассажира.
Этот же способ работает и для водителей. Главное — создать историю использования карты пассажиром и фродить того провайдера, который точно заплатит.
6. Докат
Вы же наверняка пользовались промокодами на такси? Провайдеры сжигают безумные миллионы денег на привлечение новых пассажиров и удержание старых.
Как правило, один пассажир может использовать один промо-код один раз. То есть даже если у вас промо-код на 500 рублей, а поездка — на 200, вы не сможете использовать оставшиеся 300 рублей. А водитель сможет. Ему для этого достаточно просто не закрывать заказ — либо не предупреждая пассажира (в этом случае есть риск получить плохую оценку), либо просто спросить: «Можно я промокод на максимум закрою?». Пассажиры редко отказывают: чужие деньги мало кто считает.
7. Самокат
Мало кто из пассажиров знает, что все провайдеры доплачивают водителям за существенную часть поездок — ту, где пассажир платит меньше суммы, за которую водители готовы выполнять заказы провайдеров.
Например, в Петербурге у Gett минимальная стоимость поездки для пассажира — 50 рублей, а для водителя — 220; у «Яндекса» — 50 и 130 рублей, у Uber — 50 и 99 рублей, соответственно.
Технически в биллинге доплата мало чем отличается от безналичного заказа: она так же поступает на баланс водителя. А дальше дело везения: как быстро провайдер или партнер поймают водителя на фроде. Если партнер выплатил водителю эти деньги, а провайдер признал поездку фродовой и не оплатил ее, деньги теряет партнер.
Прошлой весной мы потеряли на таком мошенничестве около 60 тысяч рублей за две недели. Самой увлекательной из историй про резко выросшее количество коротких заказов была вот такая (от первого лица):
Стою я на отстое. Подходит бабулька из соседнего дома. Ей дети подарили смартфон и поставили туда «Яндекс.Такси», чтобы она из магазина сумки не таскала, а на машине ездила. А как пользоваться, не объяснили.
Вот она приходит ко мне и просит помочь. Я ей показываю, заказ делаю, а он мне прилетает. Ну, я и везу: магазин в соседнем доме. И бабулек таких в нашем районе — пруд пруди. Все узнали, как за копейки на такси можно ездить.
Я, признаться, попробовал представить себе таксиста-отстойщика (это те, у которых посадка в машину начинается от 300 рублей), к которому массово ходят бабушки и который, вместо того чтобы бабушек радостно окучивать, помогает им разобраться с ненавистным этому таксисту «Яндексом», а потом еще и везет этих бабушек. Мыши плакали, кололись, но продолжали жрать кактус.
Особняком стоят водители, которые сами создают короткий заказ на одном устройстве и дожидаются, когда он достанется им на втором устройстве.
У нас работал водитель, который через наши моментальные выплаты так получал деньги на сигареты: ловил заказ, выходил из дома, проходил пешком вокруг квартала, закрывал заказ на 70 рублей, в течение пяти минут получал оплату и оплачивал картой сигареты в соседнем магазине. Круче него, наверное, был только водитель из Краснодара, который даже не выходил из дома.
8. Много SIM-карт
Основной идентификатор вас как пассажира — номер вашего телефона. Именно на него в первую очередь смотрят любые антифрод-алгоритмы. Только после этого идут IMEI устройства, GPS-координаты и все остальное.
Чтобы начать пользоваться приложением, надо получить SMS. Я не настоящий таксист, но у меня есть около 10 SIM-карт, зарегистрированных на меня, и еще столько же — на Санта Клауса. Ну и, конечно, всем нам помогут сервисы аренды номеров.
Коллега из Казани могла не просить пассажира заказать ее еще и по Uber, а сделать это самой. Как правило, алгоритм выполнения заказа позволяет потратить на это пару минут. За исключением случая, когда конечная точка маршрута неизвестна.
Когда провайдер доплачивает за заказ при условии выполнения Х заказов в день, у таксистов включается профессиональная солидарность: сегодня ты закажешь меня, потому что у меня не хватает двух заказов до нормы, а завтра — я тебя.
9. Закрыть заказ раньше
Провайдер и партнеры живут на комиссии — проценте, который они получают с каждого выполненного заказа. Win-win-модель фрода очевидна: водитель предлагает пассажиру заплатить меньше (допустим, 250 рублей вместо 300) и закрывает заказ на как можно меньшую сумму (допустим, на 70 рублей).
В этом случае деньги недополучают провайдер и партнер. Для водителя важны стоимость, после которой ему становится невыгодно мошенничать, и оплата поездки наличными: с картой этот способ работает, только если у водителя есть mPOS-терминал.
10. Отменить заказ
Водитель подает автомобиль и звонит вам: машина ждет. После того как вы подтвердили, что скоро выйдете, водитель отменяет заказ. На ваши вопросы, скорее всего, ответят, что это баг у провайдера.
Даже если с водителя удержат комиссию за отмененный заказ, у него уже есть пассажир, готовый ехать именно с ним, и — это важно — у него больше нет цены, установленной провайдером.
Этот способ редко работает в отрыве от дублера. Справедливости ради, используется он нечасто, и такие случаи, как правило, быстро отлавливаются на стороне провайдеров.
После каждой статьи на vc.ru находится человек, спрашивающий «Ну и зачем это все?». Вот зачем:
Ключевое сообщение каждого из моих рассказов про такси, конечно, другое. Локомотивы-провайдеры тянут этот рынок в будущее. Чем лучше мы (или любой другой партнер) понимает это будущее, провайдеров и сам рынок, тем больше у нас возможностей оказаться в будущем теми, без кого оно невозможно. А дальше вы додумаете сами.
