Геймификация в банковской сфере. Кейс «Мониторинг делового кредитного портфеля банка с помощью трехмерной визуализации Повысить активности пользователей и предложить новые услуги

Продвижение банковских продуктов и формирование потребности в них.

“ Геймификация – один из самых популярных на данный момент в маркетинге трендов. И нам, как банку с активной и продвинутой аудиторией, было логично его поддержать, предложив клиентам акцию, где игровая механика реализована на должном технологическом уровне и в значительной степени персонифицирована.”

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

Косвенным результатом также является регулярное использование пользователем онлайн-банка, так как только там можно увидеть свой прогресс.

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

“ Геймификация - это супер тема. Это всё - вовлечение. Скучно делать транзакции в банке, скучно пользоваться банковскими продуктами. А люди любят конкурировать, люди любят соперничать. Это сидит внутри и очень глубоко. И можно эксплуатировать эти качества людей. Как это сделать в банке? Кейсов мало. Но моё глубокое убеждение - тот, кто научится активно вовлекать своих клиентов, в том числе используя геймификацию, тот cможет заработать много денег.”

Типичные подходы:

1. Программы лояльности с начислением баллов, миль и кеш-бека в качестве наград.
2. Интерактивное контекстное обучение новым функциям. Велком-сценарии.
3. Квесты и конкурсы для клиентов.
4. Создание простых полезных сервисов с элементами игры: PFM, накопление на цели.
5. Вирусные промо-игры, сообщающие о новых продуктах в развлекающей форме.

В марте 2017 года к нам обратился, наверное, самый трудный клиент за все время существования нашего сервиса, который представлял интересы одного крупного банка, который имеет немалую сеть отделений по всей России. Мы всегда рады любым клиентам, но в этот раз нашим специалистам пришлось столкнуться с типичной банковской бюрократией, каковой, ни у одного нашего клиента нам встречать доселе не приходилось. Впрочем, нельзя не отметить тот факт, что трудности, которые мы испытали при работе с этим банком имели своё объяснение – такая серьезная организация не могла вносить изменения на своем сайте, не обдумав каждое из предложенных нами.

Ниже мы подробнее распишем все трудности, с которыми мы столкнулись при сотрудничестве с айтишниками и менеджментом банка и то, как мы подняли трафик сайта в более чем два раза за 7 месяцев.

Первое знакомство

Первое знакомство с сайтом (и сотрудниками PR-отдела банка) у нас состоялось в марте 2017 года. На тот момент сайт имел весьма неплохую посещаемость из поисковиков, благодаря тому, что сам банк и домен на тот момент существовали уже около 10 лет и всё это время пиарщики этого финучреждения активно работали с целевыми интернет-площадками и оффлайн рекламой, что дало сайту траст и в будущем очень помогло нам при раскрутке.

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

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

Работа над сайтом

SEO-аудит сайта

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

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

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

Последним пунктом в списке ошибок у нас был пункт про плохую внутреннюю перелинковку между страницами. Несмотря на то, что некоторые страницы так и просились, чтобы их соединили ссылками друг с другом, на деле, ничего подобного контент-менеджерами банка проделано не было.

На этом с ошибками SEO-оптимизации на сайте мы закончили.

Технический аудит

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

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

Второй момент, на который обратили внимание наши сеошники – это отсутствие файлов robots.txt и sitemap.xml в корневой директории сайта. После некоторых уточнений у админов банка, оказалось, что их нет вообще. Что же, добавляем еще один пункт в рабочий файл для последующей беседы с клиентами.

Третий пункт – это поиск всех исходящих ссылок со страниц сайта и анализ каждой из них. В основном, найдены были битые ссылки (как на внутренние страницы сайта, так и на внешние сайты).

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

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

На этих пяти пунктах проблемы технического характера были исчерпаны, и мы перешли к составлению семантического ядра.

Семантическое ядро

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

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

Работы по внутренней оптимизации

Проведя два аудита и составив семантическое ядро сайта, наши специалисты в связке с айтишниками и менеджерами банка приступили к работам над сайтом.

Первое, над чем мы вместе поработали – это исправление технических ошибок. Легче всего далось увеличение скорости загрузки сайта. Объемные изображения были нами оптимизированы в Photoshop, что в почти два раза снизило их итоговый размер, а тормозящие работу сайта модули были частично убраны, частично переписаны самими айтишниками банка. В итоге, клиентский сайт по скорости загрузки стал равняться сайтам крупнейших российских банков. Так же быстро мы решили проблему отсутствия файла robots.txt и карты сайта: инструкции для поисковых ботов мы в виде файла отправили айтишникам банка по почте и в тот же день увидели этот файл на сайте. От написания отдельного модуля для карты сайта в банке отказались, предпочтя бесплатное решение от одного из онлайн-сервисов.

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

Таким образом, за две недели нам удалось разобраться с техническими проблемами сайта и перейти непосредственно к работе над контентом.

Работа над контентом началась с того, что клиент наотрез отказался от создания новых страниц на сайте, предпочтя оставить старую структуру. Поэтому нам оставалось только составить детальные рекомендации для PR-менеджеров банка, следуя которым, они должны были бы менять контент на каждой из страниц или удалять дубли страниц. По сути, все рекомендации свелись к тому, какие ключевики и в каком количестве надо было прописать в самом тексте и обсуждению того, как должны были выглядеть мета-теги Title и Description (мы выше писали, что они дублировались) и теги H1-H3.

По той же схеме мы действовали и в случае с ручной перелинковкой страниц сайта между собой – просто отправляли рекомендации по тому, на какой странице нужно поставить ссылку и анкор с URL для ссылки.

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

Коммерческие факторы

Отдельно от всего остального, нами были проанализированы коммерческие факторы на сайте банка. Из плюсов – на сайте уже была встроена функция обратного звонка и чата с оператором службы поддержки, а также для каждого депозитного и кредитного предложения имелся собственный калькулятор. Из минусов – с операторами службы поддержки невозможно было связаться при помощи популярных мессенджеров, а на странице «Контакты» не было встроенной карты от Яндекс или Google с расположением банка. Большей частью эти минусы были устранены уже после выполнения основных работ по сайту.

Также, с нашей подачи, сотрудниками банка была убрана устаревшая информация про это финучреждение в Яндекс.Справочнике и Google Мой бизнес и внесена актуальная.

Заключение

На скриншоте Яндекс.Метрики ниже видно, насколько нам удалось поднять посещаемость сайта и за какое время.

Изначально счетчик метрики был установлен админами сайта в декабре 2016 года (на скриншоте этого не видно). Далее, 2,5 месяца метрика просто считала статистику, и уже с конца марта (как мы и написали выше) наша команда взялась за работу над сайтом. На наш взгляд, результат мог быть куда лучше, если бы не постоянные согласования всех наших действий с менеджерами банка, работа сотрудников банка над исправлением ошибок, согласования сделанного ими с нашими сотрудниками и тому подобное. В итоге, процесс, который мог занять от силы две недели, растянулся на полтора месяца (если не больше). С другой стороны, понять топ-менеджеров банка тоже можно – они просто не имеют права допустить для работы над сайтом посторонних людей, предпочтя довериться своим айтишникам.

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

Приложение, про которое, собственно, буду писать ниже, выполнено на базе платформы iDVP (Interactive Data Visualization Platform).

Итак, начнем!

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

1. Руководство хочет тратить минимум усилий на работу с приложением, на трактовку визуальной информации, на анализ данных.
2. Руководство хочет видеть состояние кредитного портфеля сразу, просто открыв приложение, не совершая ни одного клика мышью.
3. Информация должна быть представлена «максимально» - на одном экране, без необходимости скроллинга. Уже на первом экране пользователь должен увидеть, какие заемщики «проблемные», насколько «проблемные» и какова их доля в портфеле в количественном и стоимостном выражении.
4. Инструменты фильтрации и группировки данных должны быть удобными и интуитивно понятными.
5. Экраны приложения должны быть «красивыми», чтобы руководство с помощью него могло «эффектно» презентовать свои отчеты перед учредителями и акционерами.

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

Основные тезисы этой статьи

1. При обследовании заказчика мы всегда стараемся выявить ту боль (проблему) заказчика, которую можно решить с помощью анализа данных. И создаем такое приложение, которое полностью решает эту проблему.
2. Для анализа данных мы используем не «обычные» BI-отчеты, а трехмерные приложения. В этих приложениях визуализация аналитической информации выполняется в виде 3D-объектов, объединенных в тематические интерактивные сцены (экранные формы), связанные между собой логическими переходами.
3. Создаваемые нами решения имеют в своем фундаменте три принципа:

• Наглядное представление картины бизнеса заказчика. Уже при первом знакомстве с приложением, на первом же экране, пользователь должен увидеть все интересующие его части своего бизнеса.
• Раскрытие причин проблемы. Выбрав проблемную точку, пользователь должен иметь возможность воспользоваться функцией drill down, которая позволяет провалиться глубже в проблемную зону, и на следующих экранных формах увидеть причины возникновения проблем.
• Техническая эстетика. Приложение должно вызывать wow-эффект, т.е. должно быть привлекательным, интуитивно понятным и удобным.

Напомню наши этапы проектирования приложений:

1. Постановка задачи и начало работы;
2. Обследование заказчика и работа с открытыми источниками;
3. Анализ, формирование требований и документирование;
4. Формирование итогового документа «Описание приложения».

Постановка задачи и начало работы

Естественно, приложение должно удовлетворять всем специфическим требованиям руководства банка, перечисленным выше.

Обследование заказчика и работа с открытыми источниками

Основной заработок большинства банков состоит в предоставлении кредитов компаниям и населению.

Некоторые банки специализируется на кредитовании населения, другие на кредитовании юридических лиц.

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

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

Аналитики банка также собирают информацию о движение денежных средств (cash flow) заемщика и другие показатели, строят cash flow – модели. Информация собирается из нескольких информационных систем банка.

По итогам анализа собранной информации производится выявление проблем у заемщика и отнесение заемщика к одной из 5-ти «зон проблемности», используемых в банке для группировки заемщиков:

1. Зеленая зона – к этой зоне относят заемщика, у которого не выявлено проблем, которые могут повлиять на возврат кредита;
2. Желтая зона – у заемщика выявлены некоторые проблемы;
3. Красная зона – у заемщика выявлены существенные проблемы;
4. Черная зона – заемщик с вероятностью, близкой к 100 процентам, не выплатит кредит;
5. Белая зона – проблемность заемщика еще не рассчитана.

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

Также аналитики банка выполняют анализ просроченной задолженности заемщика (NPL – Non-performing loans). По итогам анализа заемщика относят к одной из 4-х зон NPL:

1. Зеленая зона - выплаты по кредиту заемщиком не просрочены или просрочены на срок до 4-х дней;
2. Желтая зона – просрочка составляет от 5 до 29 дней;
3. Красная зона - от 30 до 89 дней;
4. Черная зона - от 90 дней и выше.

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

По каждому кредиту отслеживается своевременность платежей и выполнение других условий кредитного договора.

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

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

Анализ, формирование требований и документирование

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

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

Также, чтобы приложение было удобным для руководства банка, мы решили сделать не только десктопную версию для Windows, но и для Mac OS, iOS и Android. Тем более, что платформа, на которой мы разрабатываем эти приложения, позволяет это делать, что называется, «в одно касание».

По итогам анализа были определены следующие показатели, которые необходимо отслеживать по каждому заемщику:

1. Объем задолженности
2. Зона проблемности
3. Зона NPL
4. Сумма резерва
5. Рейтинг заемщика

1. Увидеть всех заемщиков на одном экране; при этом необходимо помнить, что одновременно банк обслуживает до 1000 крупных заемщиков;
2. Отфильтровать заемщиков по объему задолженности;
3. Отфильтровать заемщиков по зонам проблемности;
4. Отфильтровать заемщиков по зонам NPL;
5. Отфильтровать заемщиков по филиалам банка, выдавшим им кредиты;
6. Отфильтровать заемщиков по отраслям промышленности;
7. Отфильтровать заемщиков по проблемностям, выявленным у них.

Как я уже говорил выше, удобству и красоте приложения у нас отводится очень большое значение. Поэтому к работе над экранами приложения привлекаются не только аналитики, но и 3D-дизайнеры, и юзабилисты.

В результате у нас получился вот такой главный экран приложения iDVP.Банки.Кредитные процессы (см. рисунок ниже).

С первого взгляда экран кажется довольно насыщенным, но при этом вся информация распределена по зонам, что облегчает восприятие. Какие же зоны получились в итоге?

В этой зоне в виде разноцветных планет (шаров) представлены заемщики банка. Размер планеты соответствует объему задолженности по кредиту у данного заемщика. Цвет планеты соответствует зоне проблемности заемщика. При этом заемщики одного цвета сгруппированы вместе, чтобы можно было визуально оценить их долю (количественно и по сумме задолженности) в кредитном портфеле. Таким образом, мы решили задачу «увидеть всех заемщиков на одном экране».

В этой же зоне присутствует фильтр по размеру планет (обратите внимание на шкалу и круг, расположенные справа от планет). С помощью этого фильтра можно указать минимальный и максимальный размер задолженности для отображаемых заемщиков. Можно оставить на экране только крупных заемщиков, например. Задача «отфильтровать заемщиков по объему задолженности» решена.

При клике на любой планете происходит переход к экрану «Карточка заемщика» (см. картинку ниже), на нем представлена детальная информация по показателям, характеризующим этого заемщика и его кредит.

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

В начальном состоянии экрана планеты малого размера не всегда удобно кликать – в них просто трудно попасть мышью илив случае с touch-интерфейсами - пальцем. Чтобы компенсировать эту трудность, в центральной зоне имеется возможность приблизить и отдалить (zoom-in и zoom-out) любую часть планетной системы. Это делается либо с помощью колеса мыши, либо, если используется touch-экран, с помощью действия «pinch».

В этой зоне содержится фильтр по цветовым зонам проблемности заемщиков. Можно нащелкать/отщелкать нужные/ненужные зоны проблемности. В результате в центральной зоне останутся только планеты-заемщики нужных пользователю цветов. Задача «отфильтровать заемщиков по зонам проблемности», «отфильтровать заемщиков по зонам NPL» решена. Внимательный читатель наверняка спросит, как мы фильтруем заемщиков по зонам NPL с помощью этого инструмента, ведь он фильтрует только зоны проблемности. Все просто: в верхней левой части экрана присутствует текст «ОСТАТОК ЗАДОЛЖЕННОСТИ» – это, на самом деле, выпадающий список выбора режимов отображения заемщиков. Для выбора доступны следующие режимы:

1. ОСТАТОК ЗАДОЛЖЕННОСТИ – в этом режиме размер планет определяется размером задолженности, а цвет планет – зоной проблемности;
2. ОБЪЕМ NPL – в этом режиме размер планет определяется размером просроченной задолженности, а цвет планет – зоной NPL;
3. РЕЗЕРВ – в этом режиме размер планет определяется размером резерва, а цвет планет – зоной проблемности;
4. РЕЙТИНГ – в этом режиме размер планет определяется значением рейтинга, а цвет планет – зоной проблемности.

Зона фильтров справа

В этой зоне содержится элемент фильтрации «аккордеон», в котором содержится три фильтра:

1. ЦА+ТБ (центальный аппарат + территориальные банки) – с помощь этого фильтра можно оставить на экране только заемщиков, кредиты которым выдал центральный аппарат (головной офис банка) или территориальные банки (филиалы).
2. ОТРАСЛИ – позволяет фильтровать заемщиков определенных отраслей промышленности.
3. ПРОБЛЕМНОСТИ – этот фильтр позволяет оставить на экране только тех заемщиков, у которых аналитиками банка были выявлены те или иные проблемности.

Задача «отфильтровать заемщиков по филиалам банка, по отраслям промышленности, по проблемностям» решена.

Зона нижнего графика

В этой зоне размещен график, в котором отображается изменение соотношения зон проблемности или зон NPL во времени. Для этого используется тип графика «линейный график с накоплением». Цвета графика соответствуют зонам проблемности или зонам NPL.

Пользователь имеет возможность установить ползунок на любую дату на графике, и в центральной зоне отобразятся только те заемщики, которые были у банка на тот момент. Размеры планет и их цвета будут соответствовать тому объему задолженности и той зоне проблемности, которые были у каждого заемщика на выбранную дату.

Ниже прикрепляю остальные экраны приложения: эскизы и названия. А у вас будет возможность их изучить, проанализировать самостоятельно. Если будут вопросы по содержимому – задавайте их в комментариях, обязательно отвечу.

Главный экран с включенным отображением круговой диаграммы распределения цветовых зон проблемности

Главный экран с отфильтрованными по объему задолженности заемщиками (на шкале слева от планет нижняя граница отображения установлена на уровне 20% от максимума)

Главный экран. Приближение планет (zoom-in)

Карточка заемщика

На прошедшем в пятницу первом форуме FinMachine директор департамента моделирования рисков Сбербанка Максим Еременко и глава R&D в области Data Science Андрей Черток рассказали как в крупнейшем банке страны с помощью машинного обучения среди прочего генерируют исковые заявления и находят бизнес-парнеров своим клиентам.

Андрей Черток : В рамках участия в одном из проектов банка мы детектируем паттерны поведения клиентов банка по его транзакциям. Первые модели были связаны с дескриптивным анализом транзакционного поведения. Например, у клиента не было покупок, связанных с авто - они появились. Значит, он купил машину, и теперь можно, например, предлагать такому клиенту продукты или услуги, полезные для автовладельцев.

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

На слайде мы видим три достаточно понятных кейса: покупка авто, ремонт в квартире/покупка мебели и затраты на лечение. Особенно ценно, если от клиента возможна обратная связь по предлагаемым ему продуктам. Потому необходимо делать модели, способные учитывать эту обратную связь. Во многом это тот же принцип, что лежит в основе моделей reinforcement learning, которые мы сейчас начинаем разрабатывать.

Reinforcement learning или обучение с подкреплением, которое сейчас развивают, в том числе, OpenAI и DeepMind - это предвестник ИИ, каким его хотят видеть. В систему заранее не закладывают какой-либо модели мира, и о нем система фактически ничего не знает. Система начинает взаимодействовать с миром, получать обратную связь, так называемые reward’ы. После чего система корректирует свое поведение на основании того, насколько хорошие или плохие reward’ы получены. В случае с банковскими продутками reward - это, например, то, насколько интересным или неинтересным для клиентов оказывается то или иное предложение банка.

Используя методы с определенными свойствами, обеспечивающими применение reinforcement learning, мы можем адаптировать эти алгоритмы в режиме реального времени. Из новых подходов можно ещё отметить, что буквально недавно в Nature выходила статья того же DeepMind, где они рассказывают о том, как в нейросеть внедрили элементы машины Тьюринга. В результате нейросеть получила возможность обладать памятью, которой нейросетям на данном этапе не хватает.

Кейс 2. Оптимизация воронки продаж
Андрей Черток : В этом кейсе мы анализируем транзакционную активность, ищем кластеры клиентов с определенными паттернами поведения. Но в этом случае не связываем их с предсказанием каких-либо событий. Мы, например, можем найти клиентов, которые часто совершают перелеты, поездки за границу и часто конвертируют валюты. Исходя из этого, эффективнее делаем предложения таким клиентам.

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

Кейс 3. Оптимизация наличного денежного обращения
Андрей Черток :Сбербанк имеет широкую сеть банкоматов, отделений, и схему по работе с корпоративными клиентами. Соответственно, возникает задача спрогнозировать завтрашний спрос на наличность. Чем точнее мы сделаем этот прогноз, тем, скажем так, аккуратнее сможем распределить эти деньги. С одной стороны, важно, чтобы деньги не лежали без дела в банкоматах, а вместо этого мы могли разместить их на краткосрочном депозите. С другой стороны, мы стремимся избежать репутационных потерь - деньги заканчиваются раньше, чем планировалось, и банкомат перестает работать, а клиент остается недовольным.

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

Кейс 4. Моделирование вероятности дефолта для малого бизнеса в режиме реального времени
Максим Еременко : В 2014 году все говорили по Big Data. В 2015 году disruptive и on the edge стало машинное обучение. В этом году главным трендом было глубинное обучение. В следующем году, очевидно, будут говорить про reinforcement learning.

В отличие от трех предыдущих трендов, reinforcement learning легко попробовать на открытых платформах. Open artificial intelligence, финансируемая Элоном Маском, и платформа DeepMind обучаются на компьютерных играх с помощью открытыго API по которому можно влезть в код игры.

Мы получаем битву двух алгоритмов. Если в 80-90-х мы играли в Пакмена, то теперь машина управляет им и этот алгоритм можно модифицировать. DeepMind по этому пути пошли несколько дальше и совместно с Blizzard построили алгоритм для StarCraft.яя

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

Подобные задачи - это основа движка Google Word2vec, осуществляющий перевод из текстовой информации в вектор, поиск и весь семантический разбор текста, на котором он базируется.

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

В результате выяснилось, что модель, базирующаяся на кредитном скоринге, ранжирующем клиентов по вероятности дефолта, практически ничем не отличается по количественной метрике точности от классических моделей. Gini у нее практически такой же на уровне 60-65%. Но если собственную информацию банка обогатить внешними данными, скажем, из соцсетей и использовать их для ранжирования, то можно дополнительно повысить точность.

На практике это означает, что не надо тратить время на оценку рисков с точки зрения классического анализа. Можно обработать те данные, которые есть в системе, и получить статистически столь же релевантную метрику качества.

Такую модель сейчас можно использовать только для формирования перечня предодобренных предложений. Если же клиент говорит: «ок, я согласен», - то процесс более сложный. Со временем, если мы увидим, что качество потока сохранялось на текущем или более высоком уровне, а модель покажет более предсказательную точность, то ее можно будет использовать как некую альтернативу.

Кейс 5. Natural Language Processing алгоритмы для анализа и генерации исковых заявлений
Максим Еременко : В рамках применения инструментов работы с текстом или Natural Language Processing мы столкнулись с тем, что Сбербанк достаточно большое количество человеческих и временных ресурсов тратит на анализ исковых заявлений и подготовку ответной части. Вместе с тем разбор большей часть информации истцов, и самих исковых заявлений в адрес Сбербанка, можно автоматизировать. Не использовать труд людей, которые вбивают информацию о паспортных данных в резолютивной части искового заявления, а можно все это: дату рождения, паспортные данные, реквизиты и резолютивную часть экстрагировать. На втором этапе, для подготовки ответной части исков, в качестве оптимизации мы предложили использовать определенный шаблон.

Кейс 6. Определение B2 B- и B2 B-цепочек
Максим Еременко : Для активных B2B-пользователей можно делать не только оценку кредитного риска, но и подбирать типовые паттерны его партнера. Если мы видим в портфеле компании со схожей профилем экономической деятельности, при этом обе относятся примерно к одной и той же когорте, то есть это не крупный инвестиционный и малый бизнесы, то мы, основываясь на этих паттернах, подбираем партнеров и рекомендуем какие именно отношения могут быть им интересны.

Кейс 7. Алгоритмы для чатбота @SberbankML_Bot
Максим Еременко : Наш чат-бот пока только учится, но какие-то вещи, которые уже многие умеют делать, например, проброс через API, к открытым источникам типа «Википедии», он также выполняет. Если вы спросите его, кто такой Греф или Путин, он ответит.

У нас есть внутреннее обязательство перед нашими боссами, что к лету 2017 года бот будет в состоянии вести беседу на банковскую тематику, плюс будет иметь базовые когнитивные способности и сможет поддерживать общение на отвлеченные темы. На данный момент бот базируется в Telegram, но мы уже ведем разработку собственного мессенджера [куда он будет перемещен].

Кейс 8. Наши алгоритмы могут не только самообучаться, но и писать стихи
Максим Еременко: Это более развлекательный проект. Мы взяли рекуррентную нейронную сеть, основанную на стихах Пушкина, Лермонтова и немного на Jira-чате самих разработчиков, и обучили систему писать стихи. Сначала она не хорошо справлялась даже с четырехстопным ямбом, но потом даже рифма стала появляться есть. Сейчас ему удается писать стихи даже про Сбербанк.