Разработка систем дистанционного банковского обслуживания: история и ситуация сегодня

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

Как развивалась разработка ДБО для физлиц

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

С другой стороны, на ДБО непосредственно влияло развитие самих автоматизированных банковских систем. Чем более развитая АБС была у банка, тем проще и быстрее он мог перейти на ДБО. Далее, в середине 2010-х, многие банки пришли к пониманию важности UI и UX, усовершенствовали дизайн, стали анализировать активности клиентов.

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

Влияние импортозамещения на разработку ДБО в последние 2 года

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

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

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

Основные критерии качества систем ДБО

Верным будет сказать, что самые лучшие системы ДБО – те, которые помогают банку реализовывать его стратегию, отвечают требованиям бизнеса банка, а они могут быть разными. Есть банки, которые нацелены на pos-кредитование, и те, например, кто занимается исключительно ипотекой, наращиванием депозитной части, ведет зарплатные проекты и т.д. Конечно, если задача банка удержать пассивы, а мобильное приложение обслуживает платежи и переводы, то такую систему ДБО надо менять.

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

Что должна включать в себя современная платформа ДБО

Инструменты фиксации условий заключения договора. Банк осуществляет ДБО на основании договора комплексного (дистанционного) обслуживания, который заключает с клиентом при его первичной идентификации в офисе банка (иногда такой тип юридических взаимоотношений называют Правилами комплексного обслуживания). Главное в данном документе: утвердить право банка предоставлять клиенту различного рода сервисы/продукты/услуги в дистанционном виде с одновременным фиксированием в электронном виде волеизъявления клиента на получение данных сервисов/продуктов/услуг; утвердить право клиента получать предлагаемые сервисы/продукты/услуги на условиях банка с фиксацией данных условий в электронном виде.

Как следствие, прежде всего, проектируемая платформа ДБО должна уметь зафиксировать авторство и неизменность волеизъявления клиента, а также авторство и неизменность принятых клиентом условий банка на сервисы/продукты/услуги.

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

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

Платформы ДБО традиционно должны поддерживать:

• работу с банковскими картами, включая поддержку токенизации в каналах;
• интеграцию с СБП по всем возможным бизнес-кейсам (с2с, с2b, b2c etc).
• открытие/закрытие счетов/вкладов;
• получение/погашение/досрочное погашение кредитов – с учетом возможностей реальных бэк-офисов в банках;

• К платформе ДБО можно организовать дополнительный сервис в виде некой «универсальной» конвейерной платформы, построенной на BPM как middle-слой между фронтальным API и проксирующим бэк-офисом. Это нужно, чтобы банки могли реализовывать многофазные транзакции для своих сервисов/продуктов/услуг с минимальными затратами.

Не всем банкам требуется такое разнообразие – как минимум на старте. Но нужно, чтобы платформа изначально позволяла получать подобного рода сервисы/продукты/услуги в виде плагинов. Такую возможность обеспечивает модульность проектируемой платформы ДБО.

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

Развитый универсальный фронтальный API. Хайповое определение омниканальности не потеряло актуальности за 25 лет своего существования. Однако за такой большой срок настоящей омниканальности так ни у кого и не появилось. Считается, что омниканальность – это возможность предоставлять клиенту сервис в едином интерфейсе в любых каналах обслуживания. Но это невозможно по определению, поскольку каждый канал характеризуется своими возможностями как по UI, так и по UX. Не может быть некой «универсальной» web-страницы, встраиваемой, например, в канал чата или мессенджера посредством WebView.

Поэтому проектируемая платформа ДБО должна иметь развитый универсальный фронтальный API, позволяющий реализовать любой функционал на стороне фронта, но при этом не иметь явно выраженных директив по фронтальному UI. Такой API должен иметь «условно общедоступный» репозиторий поддерживаемых на стороне платформы ДБО сервисов/продуктов/услуг. Кроме того, платформа ДБО должна быть органично связана с платформой публикаций и управления сервисами. Лучше, если это будет opensource-решение.

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

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

На каких участках рациональнее использовать сторонние решения

Коммуникационная платформа. ДБО это не просто набор сервисов банка, предоставляемых в виде мобильного приложения, интернет-банка или банкомата. Это, в первую очередь, коммуникации с клиентом, которые позволяют в процессе диалога продать клиенту ту или иную услугу/продукт/сервис. Как следствие, платформа ДБО должна быть интегрирована с коммуникационной платформой. В качестве такого модуля вполне подойдут облачные платформы коммуникаций: например, Edna (раньше МФМ) или ИнфоБИП. Разработчикам остается только провести интеграцию двух платформ. Как вариант, некоторые компании-разработчики находят партнера с таким opensource-решением и предлагают банкам «условно свою» коммуникационную платформу.

Фронт-офис. Разработчик может сам не заниматься написанием фронтов, а рекомендовать сторонних сертифицированных вендоров. За одним исключением: скорее всего, реализация банковских услуг в каналах мессенджеров и соцсетей потребует плотной интеграции с платформой ДБО с использованием непубличных методов фронтального API.

Аутентификация и авторизация клиентов. Для решения этой задачи подходят публичные стандарты Oauth 2.0 & OpenID Connect и новых разработок не требуется. Можно пойти двумя путями: либо взять opensource-решение и пришить его к платформе ДБО, либо воспользоваться апробированным продуктом, например, OpenAM или 3A Systems. Кроме того, обязательно будут нужны различные адаптеры: как минимум, к ЕСИА, ЕБС и Сбер ID.

Различия в подходах к разработке ДБО

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

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

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

Таким образом, выбор в пользу того или иного пути создания системы ДБО напрямую зависит от целесообразности и экономической эффективности для конкретного заказчика в определенной ситуации.