Facebook Pixel
Русский военный корабль, иди нах*й.
Пожертвовать на армию
×

Любить финтех и технологии: как мы развивали проект, интегрированный Microsoft

Роман Дуда
BA/PO department manager в Levi9
Что такое экосистема банкинга BackBase. Фото: Pixabay

Что такое экосистема банкинга BackBase. Фото: Pixabay

Рынок финансовых IT-разработок велик, и каждый продукт или его часть может решать задачи для разных категорий пользователей. Уже более 3 лет команда Levi9 развивает в Украине экосистему банкинга BackBase для 80 стран мира, работает над центральной системой платформы и отвечает за то, чтобы банковская среда, приложение или онлайн-кабинет были защищены от утечки или повреждений и облегчали управление средствами бизнесу и обычным пользователям.

В этом материале Роман (BA/PO department manager в Levi9) с senior-разработчиком Дмитрием Ковальчуком исходя из своего опыта рассказывают, что нужно учитывать при работе с банковскими продуктами и как развить систему так, чтобы запартнериться с Microsoft.

Пользователям нужны не банки, а банкинг

Задача современных банковских разработок – быть удобными, функциональными и быстро работать. И тенденция последних лет – давать больше свободы и доступа к операциям пользователям банкинга. Самообслуживание (self-servece) позволяет клиентам свободно управлять деньгами и решать проблемы. Нам не нравится часами ждать своей очереди и еще раз слышать в трубке, что мы важные компании. Удобнее зайти в приложение и в несколько кликов совершить операцию. Это выгодно и банкам — чем клиенты более независимы, тем меньше учреждения тратят средств и имеют больше ресурсов для улучшения своего продукта и сервиса.

Присоединяйтесь к нам в соцсетях!

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

Проект родился в начале 2000-х в Нидерландах, а украинская команда присоединилась к нему в 2014 году. Backend-разработка построена на Java, и это традиционно для банковской сферы – этот язык действен в разных средах, может обрабатывать большие объемы данных и имеет жесткие функции безопасности. Благодаря принципу «написать раз, использовать где угодно» Java до сих пор в топ-3 языков программирования в финтех, время от времени меняясь местами с Python. При этом ее хорошо дополняют другие инструменты. С BackBase мы прошли много технологических изменений. К примеру, начинали строить микросервисы на DropWizard и перешли на Spring, а в работе с данными сменили Application Servers на Kubernetes. Мы постоянно обновляем инструменты и увеличиваем производительность системы, используя новейшие технологии. А поскольку у нас много вспомогательных проектов и в frontend, и в DevOps, то успеваем работать и на Scala, Groovy, TypeScript. Часть написанных решений отдаем в open-source.

Подписывайтесь на нас в Google News!

Внутри проекта: принципы работы

Описывая строение проекта изнутри, есть два больших отдела — R&D, которые занимаются созданием продукта с нуля, его развитием, усовершенствованием и поддержкой, и Customer Success Team (CST), отвечающий за интеграцию, подстройку и расширение функционала под потребности клиента. В Украине к проекту привлечено более 10 команд, работающих в обоих направлениях — всего 107 левинайнеров. Мы сотрудничаем с коллегами в 6 странах мира — это некий Вавилон в миниатюре. Команда Levi9 в Украине полностью вовлечена в wealth-менеджмент, операции с инвестициями и ссудами. Мы также разрабатываем почти все сервисы коммуникаций с клиентами. Например, если нужно показать историю переписки или прислать push-сообщение на телефон, это делает украинская команда.

В частности, мы отвечаем за доступы — кто и к чему имеет, в каком объеме, что можно с ними делать и какие дополнительные ограничения устанавливать. Эта функция важна, ведь пользователям нужно:

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

Представим, что вы ФОП или компания с несколькими счетами, которые хотите передать на ведение бухгалтеру. Благодаря нашему сервису вы можете позволить ему/ей смотреть на первый счет и формировать выписки для подачи отчетности, а с другого — осуществлять платежи в рамках определенной платежной системы, определять, на какие счета можно отправить средства (например, только на зарплатные счета определенных получателей), и установить максимальный лимит транзакций по этим платежам. А приятным бонусом будет возможность назначить другого пользователя ответственным за одобрение этих операций, чтобы он их согласовывал или отклонял.

Другой большой сегмент нашей работы – это лимиты. Они позволяют ограничить объем транзакций за день, месяц или год, что помогает планировать расходы и уберечься от мошенников. Однако BackBase имеет больше возможностей и позволяет подстроить лимиты под разные ситуации и пользователей. Например, вы заказали ребенку карту и не хотите, чтобы он оплачивал компьютерные игры более чем на 10 тыс. грн. Вы также можете установить для определенного региона сумму, выше которой списание средств нужно будет дополнительно подтверждать. Кроме того, есть лимиты, которыми могут управлять только работники банков. К примеру, ограничивать транзакции и согласование определенных операций.

Залог успеха – четкая оценка результата

Банковские разработки многослойны и должны удовлетворять потребности молодой семьи и бизнеса с командой в тысячу специалистов. Новый или улучшенный функционал должен решать реальную проблему пользователя или открывать новые возможности для работы — «вау, а так можно было?!» В противном случае внедрять его не будет смысла.

Понимая потребности клиента, мы должны учитывать и требования, которым должен отвечать высококачественный конечный продукт. Это означает, например, что система защищена от уязвимостей, быстро реагирует, имеет простой дизайн и доступность (accessibility) согласно ААА, ее можно изменять и масштабировать. Большинство таких требований проговариваются еще перед началом работы над разработкой, а в процессе этот список можно расширять и просматривать.

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

Легкое пользование – сложная разработка

Пользоваться сложным продуктом должно быть легко – вместо 10 действий лучше сделать 3 и получить желаемый результат. Как следствие, клиенты заинтересованы упрощать внешний и внутренний интерфейсы. В нашей практике с этим связаны 80% запросов по усовершенствованию уже интегрированных продуктов.

Но есть обратная сторона якобы простых систем — они сложны в разработке, что бросает дополнительные профессиональные вызовы при их совершенствовании и внедрении. Каждый раз мы должны найти золотую середину между возможностями, которые клиент хочет иметь в продукте, и понятным интерфейсом. И когда мы добавляем функции в приложение пользователя или кабинет банковского работника, мы должны представлять путь, который они будут проходить при настройке и использовании. При этом много интересных вещей о работе продукта мы узнаем от интеграторов. Бывает, что обычная операция с данными оказывается сложной при перенесении в систему определенного банка.

Понравиться всем – путь в никуда

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

Одно из направлений — модерация банковских операций. Представим, вы — работник банка и должны проверить и подтвердить изменения в настройках, прежде чем проанализировать транзакции по нескольким счетам. Если переключаться между 10 экранами, можно допустить ошибку, и, чтобы уменьшить риски, лучше видеть все на одном экране.

Пользователи любят лимиты, а разработчики ломают над ними голову. Прежде всего из-за работы с большими объемами данных и «плавающими» периодами анализа. Предположим, вы установили предел по расходам в год. Когда вы рассчитываетесь в интернете, система должна каждый раз проанализировать транзакции за период, подытожить и показать, вы еще в определенных пределах. При этом следует учитывать, что большинство банков имеют rolling-limit, то есть когда год считается от текущего момента. И мы должны выдать результат за 5 секунд и не можем отложить, сосчитать позже и через несколько часов отправить отчет. Все делаем быстро, безопасно, четко.

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

Когда многофункциональность не в плюс

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

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

Бывают и технические факапы. И здесь следует отметить спокойное поведение и культуру фидбека в голландских компаниях. Они проводят работу над ошибками, определяют причину и находят решение, чтобы это не повторялось. Кстати, и Levi9, и BackBase родились в Нидерландах.

Постоянная реновация финансовых технологий

Банкинг — достаточно консервативная сфера. Обычно продукты, стремительно масштабируемые и завоевавшие репутацию на рынке, останавливаются в технологическом развитии и придерживаются определенного выбранного направления. В то же время мы на проекте не стоим на месте, постоянно пробуем что-то новое и стремимся делиться наработками с рынком. Мы слишком сильно любим технологии. Это запоминается и клиентам. В результате когда Microsoft искали банковские решения для своей облачной среды, они выбрали BackBase. Сначала их заинтересовала опция привлечения и облегчения работы с системой (engagement), позволяющая в несколько действий получить банковские услуги: как открыть карту или счет, брать ссуды. И в целом решение показалось им удобным, поэтому они решили взять его за основу и при необходимости дополнять своими разработками. Таким образом, Microsoft отвечает за техническое обеспечение клиентов средствами для cloud-банкинга и предоставляет инструменты для анализа и прогнозирования, а Backbase делает систему удобной, быстрой и функциональной.

The Page Logo
У вас есть интересная колонка для The Page?
Пишите нам: [email protected]

Комментарии

Все новости