{"id":14291,"url":"\/distributions\/14291\/click?bit=1&hash=257d5375fbb462be671b713a7a4184bd5d4f9c6ce46e0d204104db0e88eadadd","hash":"257d5375fbb462be671b713a7a4184bd5d4f9c6ce46e0d204104db0e88eadadd","title":"\u0420\u0435\u043a\u043b\u0430\u043c\u0430 \u043d\u0430 Ozon \u0434\u043b\u044f \u0442\u0435\u0445, \u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0442\u0430\u043c \u043d\u0435 \u043f\u0440\u043e\u0434\u0430\u0451\u0442","buttonText":"","imageUuid":""}

Использование предиктивной аналитики для оптимизации рекуррентных списаний

Рекуррентное списание (транзакция, не требующая участия пользователя) сегодня широко применяется участниками финансового рынка. Кредиторы активно используют данную технологию для взимания платежей с заемщиков в автоматическом режиме. И если банки делают это самостоятельно, имея доступ к информации о движении денежных средств по счетам клиентов, то микрофинансовые организации реализуют технологию через внешних вендоров. При таком подходе процесс требует регулярной оптимизации. В целом вопрос актуален не только для МФО, но и всех, кто практикует автоматическое списание оплаты за услуги: телеком-компании, сервисы по подписке и т.д. О том как оптимизировать процесс списания и сделать его более эффективном в своей колонке рассказывает директор по рискам группы IDF Eurasia (бренды Moneyman и Solva) Екатерина Казак.

Используя технологию в IDF Eurasia (бренд Moneyman), мы ставим перед собой задачу оптимизации процесса списания. В нашем случае мы хотели сохранить объемы поступлений, но сократить количество попыток списаний. Количество попыток нужно снижать для экономии — за каждую попытку, вне зависимости от ее результата, сторонний вендор берет вознаграждение, это может быть фиксированная ставка или % от размера списания. Соответственно, нужно «угадывать» не только факт наличия денег на карте клиента, но и сумму. Помимо экономического, есть и репутационный фактор — многократные безуспешные попытки списания раздражают и клиентов, и вендоров.

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

Как было изначально или что мы хотели поменять

Изначально наш алгоритм предполагал четыре попытки списания в день с вариативностью сумм в отношении каждого должника. Первая попытка — полная сумма задолженности. Если результат отрицательный, снижаем сумму на 50%. Если не получилось, в следующий раз запрашиваем уже 25% от полной суммы. Если результат успешный, увеличиваем на 50%. Условно, алгоритм можно отобразить, как -> 0.5X ->0.25X-> 0.375X, где Х — полная сумма задолженности, а а жирным шрифтом и маркером обозначены неуспешные и успешные попытки списания соответственно.

Данная схема имела ряд недостатков. По мере роста портфеля просроченной задолженности сильно увеличивалось количество неудачных списаний, соответственно, росла и стоимость неудачных попыток с фиксированной оплатой. Если вендор брал процент от размера списания, мы ничего не теряли, но в любом случае продолжали нести репутационные риски. (Рис. 1). Мы продолжали делать попытки списания до 60 дней просроченной задолженности, пока сборы находились на внутреннем взыскании, и прекращали их осуществлять после передачи внешним вендорам.

(Рис.1 График соотношения количества попыток (ось Y) и их результативности (ось Х)

Что мы сделали

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

На втором этапе мы посмотрели корреляции между днями в просрочки и результативностью попыток — оказалось, что результативность после 45 дня просрочки очень низкая (мы уже попадали в зарплатные циклы заемщика). От попыток при наличии просроченной задолженности свыше 45 дней мы отказались.

Уже эти два простых действия дали эффект снижения количества неудачных попыток. Теперь нам нужно было научиться лучше «угадывать» сумму списаний и «благоприятные» дни. Мы обратились к предиктивной аналитике: были построены деревья решений, поскольку наблюдалась корреляция между результативностью списаний и рядом факторов (Рис.2).

(Рис. 2 Пример дерева решений на Python)

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

(Рис. 3 Параметры, которые легли в основу предиктивной аналитики, и весомость каждого из них)

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

-- Сегмент 1 – первый день просроченной задолженности.

-- Сегмент 2 – второй и последующие дни просроченной задолженности.

Алгоритмы для Сегмента 2 работают значительно лучше, т.к. у нас уже появилась поведенческая информация о качестве первой попытки списания. В принципе, для упрощения реализации можно было бы и отказаться от модели для Сегмента 1 и делать «сплошное покрытие» попытками списания.

После проведенных тестов мы внедрили технологию в модуль по сбору задолженности (внутренняя разработка IDF Technology). Поскольку для построения моделей использовался Python, мы «прикручивали» движок перед каждой отправкой на списание к вендору.

Какой результат получили

Итогом проделанной работы стало «оздоровление» всей технологии. Разработанные модели в отношении каждого заемщика говорили нам, нужно ли делать попытку взыскания и если да, то на какую сумму — результативность взыскания повысилась с 10% до 40%. Соответственно, удалось сократить издержки на процесс списаний, избежать снижения сумм сборов collection-подразделением, убрать лишний раздражающий фактор для клиентов и spam для вендоров.

0
2 комментария
Dmitry Slepukhov

А можно подробнее про параметры, которые использовались в моделях?

Ответить
Развернуть ветку
Ekaterina Kazak

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

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда