Клиенту банка важны одна-единственная точка входа, общая финансовая картина и возможность управления любой частью своих активов вне зависимости от изначальной сервисной потребности или принадлежности к тому или иному пользовательскому сегменту. Решить архитектурно такую задачу, с одной стороны сохранив единую точку входа, а с другой — развивая и формируя каждый сервис по отдельности, можно с помощью децентрализованной концепции service in service, считает Николай Адеев, Борт № 1 Artsofte, визионер фронтальной ДБО-платформы Abanking.
За последние 10 лет дистанционный банкинг в России прошел стремительный путь, подстраиваясь под развивающуюся технологическую реальность и новые форм-факторы, от «толстых клиентов» до мультиплатформенных дистанционных продуктов, насыщенных маркетинговыми механиками. Эта эволюция в оцифровке пользовательского опыта дала толчок в развитии новых продуктовых и архитектурных концепций построения ДБО, самыми свежими и актуальными из которых являются распределенная независимая API-базированная архитектура back и front слоев ДБО, single core реализация с уклоном на mobile first сценарии взаимодействия с клиентом и функциональный fintech open API.
Свежая статья от компании Google наглядно демонстрирует современные тенденции и преимущества single core архитектуры по сравнению с классическим стеком технологий и объясняет, почему Progressive Web Applications (PWA) стирают границы мобильных и браузерных пользовательских приложений. И если с точки зрения функционального развития финансовых приложений тренд понятен — это диджитализация максимального количества текущих офлайн- и «псевдодиджитал»-процессов, LifeStyle банкинг и анализ/предвосхищение пользовательских предпочтений, то архитектурные тренды не так очевидны.
Для того чтобы понять, как будет развиваться дистанционный банковский канал в ближайшие несколько лет, помимо наращивания удобства, функциональности и полноценной оцифровки бизнес-процессов, вынесенных в интерфейс текущих банковских мобильных и интернет-приложений, стоит обратить внимание на логику развития пользовательских сервисов из других отраслей.
Среди уже привычных пользователю программных экосистем от глобальных интернет-компаний мы давно видим подход «одна потребность = один сервис». Все эти сервисы объединяют единая мастер-авторизация, сквозные знания и очень сконцентрированный интерфейсный пользовательский опыт. Нам как потребителям не нужен один всеобъемлющий сервис/приложение от Google или Yandex. Каждый пользователь формирует свой персональный пул сервисов под свои потребности. У кого-то это почта, навигатор и метро, у кого-то погода, поиск и облачный диск. Но все эти сервисы зародились еще в эпоху нативной разработки и являются изолированными по отношению друг к другу.
Плюсов в независимом развитии сервисных приложений много: скорость разработки отдельными командами, асинхронное и независимое развитие. Но и минусов предостаточно, прежде всего в дистрибуции и связанности данных, доступных внутри каждого сервиса.
Некоторые финансовые институты, чьи inhouse лаборатории появились в эпоху исключительно раздельной браузерной и мобильной нативной разработки, уже успели пойти по экспериментальному пути сервисного разделения приложений под отдельные сегменты клиентов с аналогичными веб-кабинетами:
— для детей;
— для private-клиентов;
— для инвестиций;
— для платежей и кошельков;
— и т.п.
Но, в отличие от интернет-гигантов с бесконечными ресурсами разработки по поддержке своих сервисов, эти банки споткнулись о ресурсную проблему поддержки технологического мультистека. Поэтому рискну предположить, что финансовые сервисы будущего могут перескочить данный этап развития и подход в дистрибуции и перейти на кардинально иную эволюционную ступень.
Также важным фактором остается и то, что клиенту банка все-таки важны одна-единственная точка входа, общая финансовая картина и возможность управления любой частью своих активов вне зависимости от изначальной сервисной потребности или принадлежности к тому или иному пользовательскому сегменту. Решить архитектурно такую задачу, с одной стороны сохранив единую точку входа, а с другой — развивая и формируя каждый сервис по отдельности, можно с помощью децентрализованной концепции service in service.
Технологические зачатки подхода service in service уже на практике реализуются при бесшовном whitelabel встраивании в канал ДБО сторонних нефинансовых сервисов. Остается применить данный подход к функциональным сервисным частям самого ДБО как единой технологической основы.
В качестве промежуточного этапа для децентрализованного подхода возможно задействовать технологию deep linking, благодаря которой авторизованный пользователь может перемещаться между разными приложениями в заранее определенные разделы. А для полноценной реализации такой концепции, учитывая динамику и уровень развития технологий, применяемых в PWA, необходимо решить техническую задачу индивидуального серверного рендеринга функционального состава под каждого конкретного пользователя.
Концепт service in service внутри одного банка легко расширяется до еще более значимого для всей отрасли — «ДБО in ДБО». Отчасти регулятор, работая над инфраструктурной платформой маркетплейса Банка России, неосознанно, но уже двигает рынок будущих IT-решений для банков именно в этом направлении. Особенно актуально это может быть для владельцев банковского монопродукта, сопровождение которого влечет за собой необходимость развивать собственный канал ДБО.
Давайте рассмотрим реализацию концепции «ДБО in ДБО» на примере кэптивных банков в автокредитовании. До 50% кредитных сделок при покупке новых автомобилей проходят через кэптивные банки автопроизводителя. Преимущества для клиента в таком кредите очевидны — субсидированная кредитная ставка, существенно ниже чем у коммерческих банков, но обслуживание такого кредита часто осложняется отсутствием удобного ДБО-инструментария и наличием у потребителя другого daily banking приложения. При этом владелец кэптивного автокредита на 100% является daily banking клиентом одного из топ-50 коммерческих банков.
И если платежная дисциплина по графику платежей легко исполняется обычным заведением шаблона платежа в приложении стороннего банка, то визуализация графика, динамический перерасчет, начисленные пени, распоряжения на досрочное погашение находятся вне платежной daily banking среды.
Описанный пример легко расширяется и на ипотечный рынок, в котором также актуален вопрос длительного сопровождения кредита через сторонний daily банк.
В заключение стоит отметить, что новые технологии уже сегодня дают возможность банкам развивать все каналы синхронно и с меньшими трудозатратами, чем раньше, а IT-компании — новаторы на стремительно меняющемся технологическом ландшафте core-систем имеют все больше и больше возможностей для создания “uber-like experience” ДБО-продуктов.
