Как внедряли удаленную идентификацию для новых клиентов в банке

Привет, меня зовут Михаил Богачевич. Работаю в Luxoft бизнес-аналитиком более трех лет, в основном на площадке заказчика (банк, Украина). Эта статья будет полезна тем, кто интересуется проектами развития банковских технологий.

Как постановление НБУ ускорило прогресс

COVID-19 помог совершенствованию технологий дистанционного обслуживания в банках. С выходом постановления НБУ № 65 банки получили правовые основания идентифицировать клиента удаленно: чтобы стать клиентом, уже не нужно приходить в банк. До того клиенту нужно было обязательно прийти в банк, предъявить свой паспорт, т. е. лично пройти идентификацию. Кроме того, необходимо проходить повторную идентификацию, если вклеено новое фото, если была замена (например, на ID-карту), или раз в три года повторно идентифицироваться... Странно, что все это называлось услугой: доберись до банка, дождись менеджера, подписывай копии документов.

Спасибо НБУ за прогресс — банки получили правовые основания и приступили к проектам внедрения разрешенных технологий. Конечно, не все банки стартанули одновременно, но те, кто хотел быть лидером, участвовали еще в подготовке первых проектов постановления. Собственно, в нашем случае бизнес поставил командам разработки процесса задачу с наивысшим приоритетом.

Процесс онбординга

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

В итоге получился следующий процесс:

  • Потенциальный клиент скачивает мобильное приложение (из маркета или по партнерской ссылке), подтверждает свой мобильный номер OTP, выбирает какой-то из типовых продуктов банка (по умолчанию, цифровая кредитная карта) и переходит к идентификации (допустим, через видеочат, чтобы вживую общаться с оператором контакт-центра).
  • Перед видеочатом приложение активирует фронтальную камеру смартфона, затем в беседе с клиентом оператор КЦ делает стандартные снимки документов (паспорт/ID карта и налоговый код) и заполняет анкету на добрых 70 полей. По итогам клиент просматривает и акцептует свои анкетные данные. Важный нюанс — все общение должно быть в непрерывной видеосессии, т. е. в случае обрывов соединения или сбоев смартфона, придётся начинать заново.
  • Полученная таким образом информация валидируется банком в кредитном бюро, по различным спискам и запретам, а также по внутрибанковским правилам. При успешном завершении, клиенту может быть предложен кредитный лимит, в расчете которого учитываются различные партнерские программы.
  • Клиент просматривает предлагаемые условия договора, паспорт кредита, справку фонда гарантирования вкладов, партнерские условия в виде печатных форм и принимает их, расписываясь пальцем на экране смартфона.
  • Договор практически принят и идет этап внутрибанковской работы: регистрируется клиент, открывается счет и карта к нему (пока блокированная), затем они передаются в процессинговый центр, сотрудники банка подписывают файл печатной формы договора квалифицированной электронной подписью, файл высылается электронной почтой клиенту и складывается в файловое хранилище банка, совместно с видео файлом и сделанными фото. По результатам клиент получает сообщение с поздравлениями.
  • Теперь клиент является полноправным (только если он ФОП, ему придется подождать регистрации счетов в ГНА до трех дней) — карта уже на смартфоне. Остается ее активировать — установить PIN, а также добавить карту к Apple Pay/Google Pay (доступно, если телефон поддерживает услугу бесконтактных платежей NFC).

Схожий процесс, если клиент выбирает предоставление паспорта через «Дія».

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

  • потенциальный клиент дает согласие на получение данных из приложения «Дія» (важно, чтобы приложение «Дія» было установлено заранее и ваши документы подгрузились);
  • банк получает от «Дія» документы (ID-карта или биометрический загранпаспорт) по специализированному API, включающему шифрование и цифровую подпись документов;
  • клиент делает селфи, которое проверяется на «реального человека» (Liveness Detection);
  • полученные из «Дія» паспортные данные и селфи клиента верифицируются автоматически (API Recognition), однако в ряде случаев проводится дополнительная верификация сотрудниками контактного центра. На данном этапе конечно возможны отказы или запрос повторного селфи;
  • параллельно с верификаций клиент самостоятельно заполняет данные анкеты, которая содержит динамический набор полей;
  • в целом, идентификацию можно пройти за 5 минут. К сожалению, из-за законодательных ограничений данный сервис не круглосуточный. Процесс должен начаться и завершиться в одни календарные сутки (дата получения данных из «Дія» с квалифицированной электронной отметкой времени должна соответствовать дате идентификации в банке). Однако, если что-то пошло не так технически, можно переключиться на видеоидентификацию.

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

Что включал проект

С точки зрения решений, в проекте участвовал бек-офис банка (комплексы АБС, эмиссии карт, процессингового центра, а также решения и системы валидаций, расчетов, генерации отчетов, документооборота, финансового мониторинга, BI отчетности), фронт-офис (мобильное решение, CRM) и интеграционные процессные платформы (Camunda, ESB, Informatica).

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

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

О бизнес-анализе в проекте

Фактически, проектные активности потребовали навыков скорее системного аналитика. Большую часть общих бизнес-требований сформировали подразделения розничных операций и юристы. Исходя из них представили видение архитектуры необходимого back office решения и описали сценарии использования, основанные на уже внедренных в банке Enterprise-приложениях. Сжатый срок и высокая интенсивность проекта диктовали прибегать к шаблонным решениям и максимальному использованию имеющихся систем (core systems). Соответственно, командам разработки, в первую очередь, было необходимо решить задачи интеграции новых, существующих и внешних систем/приложений. Новым был функционал мобильного приложения, видеочата, API «Дія», интегрируемым средствами процессного движка.

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

По мере получения готовых реализаций на интеграционной платформе проводили разработку шагов процесса, состоящих из вызовов необходимых методов предоставленных сервисов, логики обработки ответов или полученных ошибок. К сожалению, во время разработки «Дія», ЕГР, БКИ, ЦСК дорабатывали, обновляли и меняли структуры данных. Соответственно получился многоитерационный цикл обновления User Story и специфицирования взаимодействия, в т. ч. изменения модели процесса, структур хранимых данных, маппинга атрибутов, справочной системы.

По готовности настроенного процесса перешли к этапу тестирования, а параллельно с ним разработке вспомогательного функционала: подготовке печатных форм и BI-отчетов (маппингу на параметры процесса).

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

Не смотря на такие стандартные трудности, руководство не меняло запланированный срок запуска. Соответственно, некритичные изменения включили в планы последующих доработок, в т. ч. определили переходные (временные) требования. На первое время после запуска выделили ресурс аналитиков для получения обратной связи по клиентскому опыту и опыту операторов КЦ. Таким образом из технического долга и опытной эксплуатации сформировали скоуп дальнейших работ.

Будущее

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

Функционал удаленной идентификации будет применен и в процессах повторной идентификации с реализаций соответствующей подсистемы информирования клиентов.

Параллельно аналогичное решение будет предложено для сегмента малого бизнеса.

👍НравитсяПонравилось2
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Слу. Внедри еще перевыпуск и отправку карточек по почте

Будущее
Давайте совру, что светлое. В противном случае цензура на DOU выпилит этот коммент, уже потому что допустила эту оголтелую джинсу к публикации. Давайте на минуточку представим ситуацию, что рядом, не попадая в кадр видеочата, лежит труп жены после пыток, и ребёнок с кляпом и удавкой на шее. А добрые и отзывчивые инвестняни помогают пройти видеочат. Либо же тупо нашли приблизительно (очень приблизительно) похожего человека, и прямо из тюрьмы эти видеочаты проходят просто таки пачками ради кредита в швыдко-еното-гроші, разумеется по заказу владельца якобы кредитора. А то и не стали заморачиваться, и менты просто по базе данных собирают и привозят жертв для «интересной беседы», или обилечивают на дому.

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

Угадайте с одного раза, почему не существует юридически значимой процедуры ОТКАЗА участвовать в этом цирке. Зато есть принуждение принять в нём участие и взять на себя риски, хотя НИКТО ИЗ УЧАСТНИКОВ в цепи «доверия» никаких рисков на себя не принимал, жрите AS IS.

В германии есть. У них тоже плохо с правовыми институтами?

Ты, сидя в тюрьме, к примеру в России, можешь оформить кредит на немца?

Удаленная _идентификация_ - это в первую очередь про идентификацию личности, а не про географическое расположение.

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

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

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

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

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

Спасибо, Михаил, интересный опыт.
Какой был самый большой челлендж в этом всём?

во время разработки «Дія», ЕГР, БКИ, ЦСК дорабатывали, обновляли и меняли структуры данных.

вероятно это )) никак не повлиять, и обычно «бесит» )

Подписаться на комментарии