CC BY
1
Концептуальная разработка системы, объединяющей банковские программы
лояльности
Conceptual development of a system uniting bank loyalty programs
Шамурзанов Владислав Артемович
Студент 3 курса
Факультет Институт информатики, математики и робототехники ФГБОУВО «Уфимский Университет Науки и Технологий»
Уфа, Заки Валиди, 32 e-mail: kasaxfa@mail.ru
Shamurzanov Vladislav Artemovich
Student 3 term
Faculty of Institute of Informatics, Mathematics and Robotics FSFEI HE «Ufa University of Science and Technology»
Ufa, Zaki Validi, 32 e-mail: kasaxfa@mail.ru
Арменшин Карим Ильдарович
Студент 3 курса
Факультет Институт информатики, математики и робототехники ФГБОУ ВО «Уфимский Университет Науки и Технологий»
Уфа, Заки Валиди, 32 e-mail: karimarmenshin@yandex.ru
Armenshin Karim Ildarovich
Student 3 term
Faculty of Institute of Informatics, Mathematics and Robotics FSFEI HE «Ufa University of Science and Technology»
Ufa, Zaki Validi, 32 e-mail: karimarmenshin@yandex.ru
Федоров Роман Дмитриевич
Студент 3 курса
Факультет Институт информатики, математики и робототехники ФГБОУ ВО «Уфимский Университет Науки и Технологий»
Уфа, Заки Валиди, 32 e-mail: roman2-03@yandex.ru
Fedorov Roman Dmitrievich
Student 3 term
Faculty of Institute of Informatics, Mathematics and Robotics Institute of Informatics, Mathematics and Robotics
Ufa, Zaki Validi, 32 e-mail: roman2-03@yandex.ru
Аннотация.
Уникальное предложение системы, объединяющей программы лояльности разных банков состоит в том, чтобы предоставить пользователям возможность использовать бонусы и привилегии большого количества банковских карт одновременно без их непосредственного приобретения, затрат на обслуживание, подписания соглашений с банками и прочего, что позволит без особых усилий любому владельцу любой банковской карты подключиться к системе и начать пользоваться всеми ее возможностями. Идея максимально проста и понятна большинству населения и востребована среди него ввиду роста популярности банковских продуктов и программ лояльности. Цель концептуальной разработки состоит в том, чтобы продемонстрировать внутренние устройство и работу системы на базовом уровне.
Annotation.
The unique offer of the system uniting loyalty programs of different banks is to provide users with an opportunity to use bonuses and privileges of a large number of bank cards at the same time without their direct purchase, maintenance costs, signing agreements with banks and other things, which will allow any owner of any bank card to connect to the system and start using all its features without any special efforts. The idea is as simple and understandable as possible for
the majority of the population and is in demand among them due to the growing popularity of banking products and loyalty programs. The purpose of the conceptual design is to demonstrate the internal design and operation of the system at a basic level.
Ключевые слова: программы лояльности, бонусы, акции, скидки, привилегии, банки, концепт, концепция, механизм работы.
Key words: loyalty programs, bonuses, promotions, discounts, privileges, banks, idea, concept, mechanism of
work.
Сегодня на рынке финансовых услуг существует много различных банков, платежных систем, а также иных организаций. Все они так или иначе занимаются с одним и тем же процессом: передвижением денег от покупателя к продавцу, от получателя услуги к ее провайдеру. Этот стандартный процесс достаточно прост, однако с большим разнообразием банков в современном мире его можно выполнить разными способами.
Основной упор системы будет сделан на рассмотрении наиболее распространенного способа перевода денежных средств: через банковские переводы с использованием банковских карт и счетов.
Рассмотрим участников взаимодействия системы и их связь (рис. 1):
1. Пользователь: использует систему, тем самым повышая эффективность ведения личного бюджета. Для других участников сервиса предоставляет возможность пользоваться кешбэками своих карт, а взамен получает аналогичную возможность от других пользователей.
2. Система: выполняет функции по соединению пользователей и обеспечению надежного и выгодного взаимодействия различными программами лояльности. Для других участников система предоставляет возможность поиска и использования оптимального кешбэка в каждой конкретной ситуации. Сама система от этого получает часть комиссии банков или процент от сделки.
3. Банки: в системе они выполняют свою стандартную функцию денежных переводов и финансовых операций. В пользу других участников банки предоставляют свои программы лояльности, а взамен получают комиссию, то есть дополнительную прибыль.
4. Платежная система: выполняет клиринг и авторизацию, реагируя на запросы банков.
5. Сервис RTP (ЗнО): предоставляет пользователю счет на оплату покупки удобным способом, основываясь на предоставленных данных о покупках [1-3].
Рисунок 1. Связь участников взаимодействия Информационные потоки
1. Пользователь-Система: подключает свою карту к системе, предоставляет необходимые для ее работы данные, а также запросы на использования со всеми параметрами;
Платежная система
2. Система-Пользователь: предоставляет по запросам пользователей оптимальные варианты кешбэка в каждой ситуации и обеспечивает возможность его использования;
3. Банки-Пользователь: банки пользователю направляют стандартную информацию обо всех операциях на его картах;
4. Пользователь-Банки: направляет в банк свои деньги для перевода на счёт человека, через которого была оплачена покупка в размере аналогичным утраченным средствам;
5. Банки-Система: банки отдают системе часть своих дополнительных комиссий в качестве платы за дополнительную прибыль;
6. Система-Банки: система направляет в банки информацию о переводах, которые необходимо сделать с карт (в идеальном случае необходимо получить от банков право самостоятельно инициировать необходимые переводы);
7. Банки-Платежная система: отправка запросов на выполнение клиринга и авторизации;
8. Платежная система-Банки: выполнение клиринга и авторизации;
9. Пользователь-Сервис RTP: передача данных о покупках для формирования счета на оплату;
10. Сервис RTP-пользователь: предоставление счета на оплату покупки удобным способом.
Рассмотрение пользовательских сценариев является критически важным этапом в проектировании и
оптимизации систем, а также в их понимании, так как позволяет детализировать и декомпозировать взаимодействие между участниками. Основные пользовательские сценарии на use case диаграмме представлены на рисунке 2 [4-5].
Рисунок 2. Основные пользовательские сценарии в рамках Системы
Рассмотрим некоторые сценарии взаимодействия с помощью диаграмм активностей для use case диаграмм (в диаграммах активностей система именуется All At Once) на рисунках 3-9. 1. Use case: «Регистрация пользователя в сервисе».
Рисунок 3. Диаграмма активности для Use case: "Регистрация пользователя в сервисе"
Краткое описание (Brief Description) - пользователь создает личный кабинет в приложении сервиса или изменяет информацию в существующем (например, ФИО, дату рождения и т. п.).
Участники (Actors) - сервис All At Once, пользователь
Предусловия (Preconditions) - наличие у пользователя электронного устройства для скачивания приложения (телефон, ноутбук...), свободный доступ в интернет.
Триггер (Trigger) - желание пользоваться сервисом
Базовый сценарий (Normal Flow) : пользователь скачивает приложение, открывает его и начинает процесс регистрации и создания личного кабинета. Он предоставляет часть своих личных данных, необходимых для корректной авторизации: номер телефона и адрес электронной почты, а также подключает банковскую карту или несколько карт: для нее создается отдельный внутренний пароль как дополнительная защита. Карта используется
для производства платежных операций в сервисе. В конце он соглашается со всеми условиями работы сервиса и его политики, а также дает свое согласие на использование его карт сервисом в рамках своих функций. Потребителю внутри сервиса открывается счёт с нулевым балансом, который будет пополняться самим пользователем.
Постусловие (Post Conditions) - пользователь получает доступ к функционалу сервиса и может начинать работу в нем.
2. Use case: «Изменение личного кабинета».
Рисунок 4. Диаграмма активностей для Use case: "Изменения личного кабинета"
Краткое описание (Brief Description) - пользователь хочет внести изменения (или удалить) в личный кабинет в приложении сервиса.
Участники (Actors) - сервис All At Once, пользователь
Предусловия (Preconditions) - наличие у пользователя электронного устройства для скачивания приложения (телефон, ноутбук и т. д.) свободный доступ в интернет, наличие авторизованного аккаунта Триггер (Trigger) - желание изменить свой аккаунт или стереть его
Базовый сценарий (Normal Flow) - пользователь авторизуется в личном кабинете в приложении, он может изменить какую-либо информацию (например, поменять номер телефона, почту или ФИО, удалить привязанную карту), удалить ее или удалить личный кабинет полностью. При желании изменения данных в личном кабинете пользователь так же заходит в приложение сервиса на устройстве, затем авторизуется в нем. После этого он добавляет или удаляет необходимую информацию и получает запрашиваемый результат. В конце он подтверждает изменения и сохраняет их в личном кабинете.
Постусловие (Post Conditions) - пользователь получает возможность редактировать свой личный кабинет на свое усмотрение, получает личный кабинет с наиболее удобным для себя содержанием, а также с возможностью редактирования его в дальнейшем.
3. Use case: "Добавление новой карты в сервис".
Рисунок 5. Диаграмма активностей для Use case: "Добавление новой карты в сервис"
Краткое описание (Brief Description) - пользователь хочет добавить в личный кабинет системы дополнительную карту для использования.
Участники (Actors) - сервис All At Once, пользователь, банк-эквайер, банк-эмитент, платежная система.
Предусловия (Preconditions) - наличие у пользователя электронного устройства для скачивания приложения (телефон, ноутбук и т. д.), свободный доступ в интернет, наличие авторизованного аккаунта. Также наличие действующей банковской карты любого банка.
Триггер (Trigger) - желание добавить или удалить карту в приложении сервиса.
Базовый сценарий (Normal Flow) - пользователь авторизуется в сервисе и затем инициирует процесс добавления дополнительной банковской карты. Для этого он предоставляет в личном кабинете сервиса все данные по этой карте и отправляет запрос в сервис. Банк сервиса прикрепляет карту к сервису (для этого он сначала проверяет корректность введенных данных: банк-эквайер сервиса отправляет запрос на авторизацию на сумму в 1 рубль в платежную систему, а та маршрутизирует его банку-эмитенту, который выпустил прикрепляемую карту. При успешном произведении авторизации сумма транзакции возвращается обратно на карту (происходит отмена авторизации), а сама карта получает статус проверена. В противном случае процесс привязки карты останавливается и пользователю приходит уведомление о недействительности введенных данных и просьба о повторной инициации процедуры.
Постусловие (Post Conditions) - пользователь получает возможность пользоваться в сервисе дополнительной картой, а также дает согласие на ее использование со стороны сервиса в рамках условий сотрудничества с сервисом.
4. Use case: "Пополнение кошелька внутри сервиса"
Рисунок 6. Диаграмма активностей для Use case: "Пополнения кошелька внутри сервиса"
Краткое описание (Brief Description) - пользователь хочет внести денежные средства с привязанной карты на ее балансовый счет внутри сервиса.
Участники (Actors) - сервис All At Once, пользователь, банк-эмитент, банк-эквайер, платежная система.
Предусловия (Preconditions) - наличие у пользователя электронного устройства для скачивания приложения (телефон, ноутбук и т. д.), свободный доступ в интернет, наличие авторизованного аккаунта. Наличие свободных денежных средств на привязанной к сервису банковской карте.
Триггер (Trigger) - желание пользоваться картой в сервисе, а для этого внести деньги на ее внутренний счет в сервисе.
Базовый сценарий (Normal Flow) - пользователь инициирует стандартный межбанковский перевод между совей картой и банком-эквайером сервиса. Банк-эмитент пользователя отправляет запрос через платежную систему на перевод денежных средств (поскольку деньги двигаются не мгновенно, то это, по сути, пока обещание будущей оплаты, а не совсем запрос). Банк-эквайер, в свою очередь, через платежную систему проверяет наличие на карте пользователя в банке-эмитенте обещанной к будущему переводу суммы денежных средств. Если все в порядке, то операция производится и внутренний баланс карты пополняется на указанную сумму. Иначе операция отклоняется.
Постусловие (Post Conditions) -пользователь пополняет свой внутренний кошелек карты в сервисе.
5. Use case: "Вывод средств с кошелька внутри сервиса"
Рисунок 7. Диаграмма активностей для Use case: "Вывод средств с кошелька внутри сервиса'
Краткое описание (Brief Description) - пользователь хочет вывести денежные средства с балансового счета внутри сервиса на привязанную карту.
Участники (Actors) - сервис All At Once, пользователь, банк-эмитент, банк-эквайер, платежная система.
Предусловия (Preconditions) - наличие у пользователя электронного устройства для скачивания приложения (телефон, ноутбук...), свободный доступ в интернет, наличие авторизованного аккаунта. Наличие денежных средств на балансовом счете в сервисе.
Триггер (Trigger) - желание завершить пользование конкретной картой в сервисе и вернуть оставшиеся на балансе деньги.
Базовый сценарий (Normal Flow) - пользователь инициирует стандартный межбанковский перевод между совей банком-эквайером сервиса и банком своей карты. Поскольку и банковская карта, и средства счета пользователя внутри сервиса (кошелек карты в сервисе) принадлежат самому пользователю и баланс кошелька ненулевой (иначе операция бессмысленна), то проверка наличия денежных средств в кошельке, а также проверка карты не требуются, поскольку карта уже привязана к сервису и была проверена при подключении. По описанным выше причинам происходящий процесс - простая транзакция средств пользователя. Он через банк-эквайер сервиса отправляет запрос через платежную систему на перевод денежных средств (поскольку деньги двигаются не мгновенно, то это, по сути, пока обещание будущей оплаты, а не совсем запрос). Все проверено, и деньги переводятся без дополнительных процедур.
Постусловие (Post Conditions) -пользователь выводит остаток средств с кошелька на свою карту, привязанную к сервису.
6. Use case: «Оплата удобным способом».
Вопросы студенческой науки
Выпуск №11 (87), ноябрь 2023
Краткое описание (Brief Description) - пользователь ищет наименее затратный вариант оплаты товара или услуги и производит оплату выбранным способом.
Участники (Actors) - сервис All At Once, пользователь, банк-эмитент, банк-эквайер, платежная система, сервис Request To Pay, поставщик услуги (ТСП).
Предусловия (Preconditions) - наличие у пользователя электронного устройства для скачивания приложения (телефон, ноутбук.), свободный доступ в интернет, информация о текущей покупке. Наличие у пользователя банковской карты, привязанной к сервису, а также наличие денежных средств на внутреннем балансе карты (кошельке внутри сервиса).
Триггер (Trigger) - желание воспользоваться сервисом
Базовый сценарий (Normal Flow) - пользователь выбрал канал оплаты и хочет через него произвести оплату. Сначала проверяется наличие необходимой суммы счета в кошельке сервиса карты пользователя. Сначала пользователь выбирает, с какой карты производить оплату. Далее через API проверяем наличие
денежных средств на карте третьей стороны, чтобы можно было произвести перевод или оплату. Сразу после этого с этой карты денежные средства переходят ТСП в качестве оплаты приобретаемого пользователя товара или услуги. После проведения оплаты со счета автоматически происходит списание средств в количестве, равное тому, которое затрачивает третья сторона по итогу оплаты и переводится на использованную карту в качестве возмещения затрат. Внутренние переводы между счетами внутри сервиса происходят без комиссии, так как проводятся внутри счетов одного банка - эквайера сервиса. При переводе на карту, выбранную пользователем, комиссия банком взимается, однако она уже включена в стоимость, которую видит пользователь до начала оплаты.
Постусловие (Post Conditions) - пользователь выбрал нужный ему вариант и подтвердил свой выбор. В итоге оплата произведена.
7. Use case: «Просмотр аналитики по имеющимся в сервисе картам».
Рисунок 9. Диаграмма активностей для Use case: «Просмотр аналитики по имеющимся в сервисе картам»
Краткое описание (Brief Description) - описание всех топовых вариантов оплаты по заданных критериям, а также возможность запросить историю всех своих автоматических списаний третьим лицам в сервисе.
Участники (Actors) - сервис All At Once, пользователь с авторизованным аккаунтом.
Предусловия (Preconditions) - наличие у пользователя критериев поиска, а также доступа в интернет.
Триггер (Trigger) - желание получения необходимой информации
Базовый сценарий (Normal Flow) - пользователь заходит в личный кабинет и инициирует поиск каналов оплаты (других вариантов карт) по заданным критериям: пользователь может сам выбрать критерии в настраиваемом фильтре в приложении сервиса. После задания всех параметров и поиска пользователь получает информацию о наиболее подходящих под критерии картах и условиях их пользования.
Второй вариант базового сценария: в поиске пользователь выбирает пункт история списаний и получает сразу список всех автоматических списаний со всех своих карт в одном месте.
Постусловие (Post Conditions) - пользователь получает всю запрашиваемую им информацию, которая есть у сервиса и которую он может предоставить пользователю.
Список используемой литературы:
1. Б. А. Аюпов, И. Э. Веденяпин Обзор-обоснование сервиса «запрос на оплату» («ЗнО»), актуализирующего возможности отечественного банковского функционала // Вестник Алтайской академии экономики и права. - 2023. - № 5-2. - С. 192-197.
2. Основные показатели развития национальной платежной системы (обновлено III квартал 2022 г.). Банк России. [Электронный ресурс]. URL: https://www.cbr.ru/statistics/nps/psrf/ (дата обращения: 17.02.2023).
3. Н. Н. Анохина, Г. А. Щербич Программы лояльности для потребителей банковских услуг // Глобальные проблемы модернизации национальной экономики : Материалы VIII Международной научно-практической конференции, Тамбов, 2019. - С. 195-203.
4. Е. В. Добролежа, Е. А. Карпова Формирование программ лояльности российских коммерческих банков в условиях цифровизации // Инновационный потенциал банковской деятельности в цифровой экономике : Сборник материалов VI Международной научно-практической конференции, Ростов-на-Дону, 26-28 октября 2021 года.
5. Исаев М.Е. Электронные деньги и регулярные платежи: функционально-институциональный аспект // Известия высших учебных заведений. Серия: Экономика, финансы и управление производством. 2012. № 4(14). С. 3-9.
