Сегодня многие уже забыли о том, что такое очередь в кассу банка. «Виновниками» такой забывчивости не в последнюю очередь являются новые сервисы, внедряемые финансовыми организациями, в том числе платежные системы. Они позволяют осуществлять дистанционную оплату различных услуг (интернета, мобильного телефона, коммунальных услуг и т.д.) через каналы банка. Как показывает статистика, клиентам намного удобнее использовать одну систему, чем несколько, и банк в этом месте может выступать как единый центр платежей. Для этого он должен обеспечить прием платежей через разные каналы (отделения, интернет- и мобильный банк, точки самообслуживания и т.д.) и различными способами (с помощью карточного, текущего счета, наличных средств). Кроме того, должно быть обеспечено уведомление клиентов посредством SMS, e-mail, а также организована претензионная работа.
Реализация подобного типа услуг в разы увеличивает количество транзакций, обрабатываемых банком. Эффективное решение подобных задач невозможно без автоматизации. В первую очередь необходимо автоматизировать деятельность сотрудников банка по приему и обработке платежей и ведению претензионной работы, связанной с такими операциями. Одним словом, необходима система приема платежей. Они могут быть:
- онлайн-платежами. Чтобы информирование о платеже происходило в режиме реального времени, необходимо выполнить интеграцию банковской системы с системой поставщика услуг или агрегатора;
- офлайн-платежами. Сводные отчетные материалы по платежам направляются поставщикам услуг/агрегаторам в электронном виде.
Система приема платежей в ИТ-архитектуре банка.
При построении ИТ-ландшафта для внедрения платежной системы необходимо учитывать ее будущие взаимодействия со смежными бизнес-приложениями:
- с CRM – для идентификации клиента;
- с ДБО – для обеспечения удаленной оплаты услуг;
- с системами поставщиков услуг и агрегаторов – для онлайн-оплаты услуг;
- с процессингом – для холдирования и снятия денег с карты;
- с АБС – для проведения операций и бухгалтерских проводок.
Наш опыт показывает, что при внедрении системы приема платежей может возникнуть ряд далеко не очевидных проблем. Например, источником головной боли может стать наличие различных схем взаиморасчетов между банком, поставщиком услуг и агрегатором. Схемы взаиморасчетов во многом зависят от того, чья сторона ответственна за расчет перед агрегатором, с какой суммы берется процент комиссии банка или агрегатора, через какие счета выполняется ее взимание и т.д. Нюансов огромное количество. Несмотря на то, что число участников схем взаиморасчетов фиксировано, схемы могут меняться и расширяться, поэтому для снятия ограничений система должна обеспечивать их гибкую настройку. Кроме того, она должна гарантировать гибкую передачу данных в АБС банка для создания платежных документов и соответствующих проводок. Это влечет за собой необходимость дополнительной настройки или включения в схему взаиморасчетов новых атрибутов.
Еще одна проблема связана с внешним процессингом. Для сокращения расходов на взаимоотношения с внешними контрагентами процессинг, проверка карт и карточных счетов клиента, запрос остатков и т.д. могут выполняться через внутреннюю карточную систему банка. Таким образом, до начала реализации интеграции со смежными системами необходимо проработать различные варианты взаимодействия между внешним процессингом и бизнес-приложениями банка для выявления самого оптимального решения.
Нередко при обработке платежей возникают «технические» конфликты. При сверке платежей может выясниться, что платеж не оплачен у поставщиков услуг, не проведен в АБС банка и т.д. Для нивелирования подобных ситуаций при сверке платежей необходим как автоматизированный, так и «ручной» механизм разрешения конфликтов. Для их устранения на ранней стадии в системе должен быть гибко настроен процесс проведения платежа соответственно политике банка. Также должна быть настроена обработка ошибок от смежных систем. Она позволит в зависимости от типа ошибки прекращать работу с платежом с уведомлением пользователя или выполнять допроведение платежа, скрытое от глаз клиента.
Основные проблемы, возникающие при внедрении системы приема платежей
- Наличие различных схем взаиморасчетов между банком, поставщиком услуг и агрегатором
- Дополнительные затраты на взаимодействие с внешним процессингом
- Бизнес и технические конфликты при обработке платежа в различных системах как внутри Банка, так и со стороны поставщика/агрегатора
После того как процессы налажены, возникает вопрос о том, как удержать существующих клиентов. В части дистанционной оплаты услуг это достигается за счет предложения большего количества сервисов по сравнению с конкурентами, а также упрощения их использования. Так, оплата услуг нередко происходит на регулярной основе и в один и тот же промежуток времени (коммуналку чаще всего оплачивают с 3-го по 10-е число). Существует несколько вариантов того, как в этом месте можно упростить клиенту жизнь. Многие банки посредством SMS, e-mail и других каналов связи регулярно напоминают о необходимости оплаты услуги. Но более эффективный способ – выполнять платежи без постоянного привлечения клиента, позволить ему максимально дистанцироваться от подобных «многоразовых», рутинных операций. Это позволяет сделать система автоплатежей. Необходима минимальная первоначальная настройка – суммы, периода оплаты – для того, чтобы в дальнейшем обеспечить автоматическое списание денежных средств. Другой вопрос – как правильно внедрить и в дальнейшем модернизировать эту систему.
Автоматом
Итак, система автоплатежей осуществляет управление регулярными списаниями денежных средств со счетов клиентов, которые автоматически инициируются банком. Последние несколько лет ведущие российские банки непрерывно совершенствуют свои сервисы ДБО, в том числе расширяя спектр возможностей услуги «Автоплатеж». Так, в этом году мы участвовали в реализации дополнительной функциональности автопереводов в системе автоплатежей российского банка, входящего в ТОП 50. Она позволила осуществить миграцию длительных поручений (формы № 190) из систем учета вкладов в систему автоплатежей. Ранее процесс списания денежных средств по форме № 190 не включал в себя взаимодействие с клиентом в ходе исполнения автоплатежа. Теперь клиент в курсе происходящего и имеет возможность вносить корректировки в процесс.
Кроме того, в результате проекта добавлена возможность регулярных перечислений денежных средств с карты на карту или на другой счет клиента. Имеются ввиду 2 типа автопереводов:
- «С карты на карту» – для подключения автоперевода клиенту достаточно знать номер карты другого клиента банка.
- «Копилка» – позволяет совершать автоматические переводы с карты клиента на его счета по расписанию или по событию. Событием является факт зачисления или списания денежных средств.
Стоит подробнее остановиться на сложностях проекта. Основными из них были значительное количество интеграционных взаимодействий дорабатываемой системы, а также параллельно происходившее развитие смежных систем. Сложности реализации интеграционных решений и рецепты их устранения описаны в статье «Интеграционные проекты – работа над ошибками».
Также нужно было реализовать гибкое, интеллектуальное взаимодействие системы автоплатежей с клиентом. Нам необходимо было предусмотреть различные варианты развития событий при управлении подпиской на автоплатеж, а также при его непосредственном исполнении. В результате проекта клиенты получили возможность принимать решение при возникновении ситуаций, требующих их вмешательства.
В «погоне» за новыми клиентами банки стремятся стать для них единой системой платежей, тем самым упростив их жизнь «до одного клика». Но при этом нельзя забывать об огромном количестве нюансов, возникающих при разработке платежных систем. В нашей статье мы рассмотрели самые большие камни преткновения, но на этом их список не исчерпывается.