Цифровая ипотека 2.0

Личные блоги

1Читайте блоги специалистов
2Пишите в собственный блог
3Комментируйте интересные посты
12 марта 2019, 16:31

Цифровой ипотечный конвейер: некоторые выводы по итогам внедрения

Комментарии(0)
Рейтинг публикации
8
2600

Комаров А.Антон Комаров

Заместитель руководителя бизнеса ипотечного кредитования и расчетов по сделкам с недвижимостью

Дирекция кредитно-депозитного бизнеса Банка "Санкт-Петербург"

 

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


Точки оптимизации

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

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

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

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

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


Точки внедрения

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

Подготовка к сделке

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

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

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

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

Возможность интеграции между ПО партнера и сервисом банка по протоколу API — то, что должна уметь любая современная система, must have. Пока представляется, что это закладка на будущее, так как лишь очень крупные игроки рынка недвижимости обладают своим мощным IT-блоком для реализации интеграции. Но там, где есть спрос, будет предложение, и поэтому на рынок недвижимости приходят компании, позволяющие приобретать гибкие коробочные решения, не требующие больших вложений в разработку и поддержку. Интеграция с ними, а также с агрегаторами поможет банку не потратить деньги на сервис, который окажется ненужным. Ведь сервис одного окна нужен не только клиенту, но и каждому участнику рынка.

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

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

Регистрация сделок

Одна из наиболее интересных IT-задач для решения в банковском сервисе (личном кабинете) — электронная регистрация сделок с недвижимостью. Когда банки впервые предложили такую услугу застройщикам, последних охватили сомнения в ее необходимости и эффективности. В числе прочих бытовало мнение, что банки пытаются подчинить себе процесс регистрации в цепочке сделки и таким образом управлять им. Сегодня застройщики и клиенты — физические лица платят деньги за эту услугу. Причины на поверхности: скорость, простота, экономия времени на походах в МФЦ.

С точки зрения реализации это самая сложная составляющая сервиса, что объясняется необходимостью выпуска усиленных квалифицированных электронных подписей всем участникам сделки, создания возможности по настройке визуализации подписываемых клиентом документов. А самая важная часть — передача пакета документов в регистрирующий орган и возврат итога регистрации. Чтобы регистрация сделки успешно прошла все шаги, необходимо правильно интегрироваться с регистрирующим органом. Сегодня банкам проблематично осуществить такую интеграцию самостоятельно ввиду закрытости API и протекающего на федеральном уровне процесса перехода со старой системы на новую. Но есть посредники, обладающие успешным опытом такой интеграции, к услугам которых и прибегают в 100% случаев кредитные учреждения.

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

Маркетплейс

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

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


Будущее сейчас

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

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

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


Итог внедрения сервиса: что удалось сделать и какие возникли проблемы?

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

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

Помимо высвобождения штатной единицы, удалось создать понятный “friendly” интерфейс, работа с которым не требует специализированных знаний. Благодаря проекту в банке появилось IT-решение, способное в дальнейшем с легкостью интегрировать между собой совершенно разные информационные системы, в том числе из других областей бизнеса банка (в дальнейшем его будут использовать корпоративный блок, IT-блок, другие розничные бизнесы). Мы получили прекрасный опыт интеграции с нашими партнерами, помогая им описать API для своих информационных систем, что позволит с успехом совершить интеграцию и принимать заявки от партнеров на уровне CRM–CRM.

Основной проблемой, с которой столкнулся банк, на данный момент является невозможность прямой интеграции с Росреестром. В результате пришлось идти по «протоптанному» другими банками пути — это интеграция такой услуги через поставщиков, коих на рынке всего три. Также мы понимаем, что удобство для клиента обусловлено в первую очередь сокращением времени сделки, количества обращений в банк, ввиду чего невозможно подписывать сделку с использованием УКЭП на стандартном токене — применяется только облачная УКЭП. Но облачная УКЭП не является в полной мере легальной, в этом смысле в законодательстве есть «белые пятна». Фактически, реализовывая такую схему работы, банки несут риск однажды утратить наработки, если облачную УКЭП законодательно запретят. Но банк все-таки принял решение работать с облачными УКЭП.

Какие смелые шаги подсказывал сам ход внедрения и какой прогноз их эффективности можно было бы дать?

Собственно, первым смелым шагом было начать проект: мы понимали, что конкуренция окажется колоссальная, — так и вышло. В прошлом году с десяток банков презентовали такие решения. Это также породило с десяток сторонних обращений IT-компаний, предложивших свои решения. Однако мы этого ожидали, и нас это нисколько не смутило. У нас есть рецепт выживания на рынке. Безусловно, здесь важно все: от способа предоставления сервиса, то есть способа регистрации и аутентификации, до возможностей, которые сервис предоставляет. Наша цель — прийти в СРМ каждого застройщика, у которого она есть, то есть прийти к бесшовной работе «застройщик–банк».

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

 

Комаров А. Цифровой ипотечный конвейер: некоторые выводы по итогам внедрения// Банковское кредитование. 2019. № 1, с. 63-69

Комментировать
Обсуждения
Информер