борт №1 в Abanking
Часто ли вы сталкивались с тем, что на сайте вашего банка есть конфигураторы кредитов и депозитов, но в ДБО их нет или они разнофункциональны? Или с тем, что форма выпуска корпоративной карты на сайте кардинально отличается от формы в интернет-банке? Таких примеров масса. Решить эти проблемы и одновременно минимизировать объем вводимых данных при переходе посетителя сайта в статус клиента банка поможет использование сквозного фронтального слоя ДБО, имеющего независимую от бэкэнда архитектуру.
Многие API-ориентированные вендоры усиленно пропагандируют парадигму архитектурной независимости внешнего канала ДБО от транзакционного ядра. И если пару лет назад канал ДБО воспринимался исключительно монолитным и был таковым с точки зрения программной архитектуры, то сейчас все больше банков осознают, что нужны архитектурная автономность и возможность асинхронно развивать каждую среду — бэкэнд и фронт (рис. 1).
К этому пришли как все инхаус-лаборатории, так и банки, занимающиеся диджитализацией процессов с помощью готовых программных решений.
Фронт развивается под задачи бизнеса и маркетинга, а бэк — под требования регулятора и задачи собственной продуктовой политики (в части увеличения быстродействия, безопасности и новых интеграций с core-banking системами, появляющимися в бизнес-процессах банка).
Нефронтальные компоненты фронтального продукта
Для большей автономности от классического транзакционного ядра ДБО при бесшовном интерфейсном внедрении сторонних сервисов может понадобиться отдельный нетранзакционный бэкэнд.
Почему он нужен?
Не все бэк-вендоры имеют хорошие и достаточно атомарные REST API — но почти все имеют какой-либо API-интерфейс и приемлемую проработку методов для реализации обычных транзакционных механик, даже если это не REST.
Встройка нового стороннего продукта, если API и само ядро ДБО недостаточно проработаны, происходит через отдельный интеграционный бэк-модуль, поддерживающий только фронтальную систему и реализованные в ней продуктовые механики. Чем реже при внедрении новых сервисов на фронте затрагивается поставщик транзакционного бэк-модуля обычного ДБО — тем лучше.
В конце концов итог всей пользовательской цепочки действий всегда сводится к процессу транзакции или обмену традиционными платежными данными между системами.
Децентрализация интерфейса
Подход, когда набор конкретных интерфейсных и программных механик присущ только одной системе, в рамках комплекса систем дистанционного взаимодействия уходит в прошлое. В экосистемах части интерфейса должны быть генетически идентичными и могут быть децентрализованными.
Интернет-гиганты уже приучили нас, что все сервисы доступны пользователю под единой авторизацией вне зависимости от точки входа в интерфейс, а компонентная технология позволяет выносить и встраивать части интерфейса одного сервиса в другой.
Концепция фронтальной системы подразумевает не просто реализацию отдельной маркетинговой продуктовой среды, но и распределенную дистрибуцию интерфейсных компонентов этой системы в глобальную инфраструктуру дистанционного взаимодействия.
Такие подходы к построению фронтальных ДБО стирают традиционные границы интернет-банка, которые привычно спрятаны за формой логин-пароль, и позволяют при едином интерфейсном паттерне быть частью как авторизованного мобильного и браузерного пространства, так и частью публичного корпоративного банковского веба.
Как пример: первое соприкосновение пользователя с вашим интернет-банком может начинаться еще в публичной форме выпуска карты на сайте (рис. 2).
Продуктовые веб-сервисы на сайтах
Основная причина несоответствия сервисов на сайте банка и в ДБО кроется в дублировании сервисов в изолированных информационных системах. И чаще всего они существенно лучше выглядят именно на сайте — в силу курирования маркетингом и применения более гибких веб-технологий. Но роль этих сервисов сводится к примитивной лидогенерации, иногда со статусным callback. Они редко умеют использовать имеющиеся знания о клиенте и минимизировать за счет этого объем вводимых данных.
Сквозной фронтальный слой ДБО решает эту проблему. Его суть в отсутствии дублирования кодовой базы продуктовых цепочек продаж, общих алгоритмах и единых источниках данных по конфигурациям финансовых продуктов. Продуктовый сервис как компонент, относящийся к ДБО, может быть внедрен в веб-инфраструктуру, мобильный банк и интернет-банк, предоставлен в неизменном виде как клиенту, так и неклиенту в публичной или авторизованной зоне. Этот подход дает возможность создавать механики продолженного взаимодействия с автозаполняемыми данными в поставторизационном статусе. Клиент должен иметь однотипный интерфейсный паттерн вне зависимости от своего договорного статуса и идентифицированности.
При такой реализации цепочек продаж роль сайтового CMS-бэкэнда сводится исключительно к информационно-контентным задачам вне зависимости от того, что это за платформа или фреймворк.
CMS сайтов не должны быть основой для реализации полноценных продуктовых сервисов — это единая среда для правил редакции и инструментов веб-маркетинга, для управления публичной структурой страниц и текстово-графическим контентом, основа непродуктовых веб-модулей и посадочных страниц. За все остальное должны отвечать компоненты фронтального ДБО, интегрированные с полноценным бэк-ландшафтом.
Нулевая зона ДБО (личные кабинеты)
Роль данного компонента часто недооценивается из-за тупиковой реализации.
С одной стороны, банки хотят автоматизировать взаимодействие с неклиентами/лидами, но не могут это делать на инфраструктуре традиционных вендоров ДБО из-за лицензионных политик (выкупать лицензии ДБО на потенциальных клиентов никто не хочет) и ограничений в реализации, поэтому многие личные кабинеты — это всего лишь части сайтов.
С другой стороны, набор сервисных механик автоматизации в таких кабинетах ограничен изолированностью и возможностями сайтостроителей.
Однако проектируя нулевую зону ДБО, можно рассматривать ее и как полноценный интернет-банк без транзакционных сервисов. При этом все интеграционные возможности фронтального ДБО уже доступны даже клиенту без РКО. У клиента не может быть одновременно и интернет-банка, и личного кабинета — это одна система.
Как только пользователь становится клиентом банка и получает учетную запись в бэкэнде ДБО, интерфейс органично расширяется до полноценного решения интернет- и мобильного банка (рис. 3).
Для розницы роль личного кабинета достаточно проста. Основные бизнес-сценарии, использующиеся в личных кабинетах, — это отслеживание статусов и догрузка данных для заявок, сформированных в публичном вебе, на банковские продукты (чаще всего кредиты). Но с момента получения финансового продукта лид становится клиентом банка и вся дальнейшая работа с банком ведется через ДБО. В этом процессе трансформации кабинета в полноценный интернет-банк следует уделить особое внимание миграции данных, чтобы все, что нам ранее отдавал пользователь, появилось в соответствующих разделах полноценного ДБО.
По сути эта цепочка взаимодействия работает только один раз в процессе подключения любой услуги, приводящей к открытию расчетного счета.
Разумеется, в авторизованной зоне неклиента можно видеть и механики «публичного интернет-банка», завязанного на интернет-эквайринг, и p2p-сервисы для привязки карт сторонних банков, но этот сценарий работы потребителя мало востребован. Поведенческий паттерн потребителя не показывает желания регулярно использовать транзакционную инфраструктуру, не являясь клиентом банка.
Гораздо больше механик можно реализовывать в нулевой зоне ДБО для корпоративных клиентов. Во-первых, существуют услуги, которые не требуют РКО, например выдача банковской гарантии. Во-вторых, любое взаимодействие с потенциальным корпоративным клиентом — это получение заверенных уставных документов и часто финансовой отчетности.
На нулевой фазе ДБО для автоматизации документооборота и минимизации посещений операционных офисов банка мы даем таким клиентам работать в системе с имеющейся у них инфраструктурой квалифицированной электронной подписи (КЭП) от аккредитованных удостоверяющих центров при Минкомсвязи (рис. 4).
Уже сегодня современные инструменты и переосмысление классической архитектуры дистанционных каналов позволяют банку организовать максимально оцифрованные коммуникации с потребителями, а развитие целевого законодательства и инструментов удаленной идентификации будет этот тренд только усиливать.
