Март 20

Софт из 90-х VS микросервисы: что банки могут перенять у финтех-компаний

Всем привет! Меня зовут Руслан Колодяжный, я CTO британской финтех-компании Wirex. До того как возглавить R&D-центр, я около 8 лет проработал в украинском банковском секторе. В этой статье я хочу рассказать о принципах организации IT-инфраструктуры, особенностях построения процессов работы финтех-компаний, их отличиях от классических банков, а также о том, что именно финансовые компании должны максимально быстро внедрять в своих организациях для повышения конкурентоспособности.

В этой статье я буду сравнивать финтех-игроков с банками в общей своей массе, где клиентам для получения услуги все еще нужно идти в отделение, а в худшем случае — отправляться туда, где они получали свою карточку (да, у нас тоже такое есть). Таких банков на рынке все еще подавляющее большинство, а Европа и США — не исключение.

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

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

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

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

программное обеспечение;
аппаратное обеспечение;
команда;
процессы;
интеграциях всего со всем.

Software

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

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

Достаточно вспомнить опыт британского банка TSB. В 2018 году финучреждение попыталось перевести своих клиентов на новую банковскую платформу Lloyds Banking Group. Однако в ходе миграции пользователи потеряли доступ к своим счетам, у некоторых появилась информация о чужих аккаунтах или высвечивался неверный баланс. В итоге Пол Пестер, генеральный директор TSB, был вынужден уйти в отставку, а сама ошибка обошлась банку в £300 млн, не считая потери доверия клиентов.

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

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

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

Решение всех этих проблем давно известно — облачная инфраструктура. Именно на ней строят свою IT-систему финтех-компании, на нее постепенно переходят и классические банки.

Команда разработчиков: In-House решение vs сторонний продукт

Банки в большинстве случаев используют софт сторонних поставщиков. В то время как финтех-компании, как правило, имеют собственное решение, часто на базе адаптированного внешнего продукта.

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

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

В банках же, в случае необходимости расширения функционала, нужно обращение к внешнему поставщику. И запускается длительный процесс: согласование требований, иногда с написанием подробного ТЗ (несколько дней — месяцев), временная и финансовая оценка на стороне поставщика (несколько недель), согласование сроков и стоимости в банке (несколько дней — недель), подписание договора и оплата (тоже недели). И только после этого начинается разработка решения. В итоге мелкая фича, которая у нас делается за 2-3 дня, в банках растягивается на 2-3 месяца, и по стоимости, как правило, она тоже выходит несоизмеримо дороже.

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

Внутреннее устройство программных решений

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

И это довольно распространенная проблема. Согласно отчету Accenture, 39% банковских руководителей назвали устаревшую IT-инфраструктуру самым серьезным препятствием на пути к цифровой трансформации, а затраты на модернизацию основных банковских систем — наиболее существенной преградой для внедрения новых технологий.

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

Эти проблемы и перспективы можно увидеть даже в рамках Wirex. Сам продукт начинался с так называемого монолитного куска кода, который сейчас делится на части. И происходит это по той простой причине, что работать с ним было неудобно, медленно, затратно, и при этом возникало множество багов. Решением этой ситуации является микросервисная архитектура, или в случае других компаний — отдельное программное решение, которое легко между собой интегрируется по API.

Схемы интеграции, или «дайте нам API»

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

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

Но есть один нюанс — готовность собственной системы и стороннего решения к быстрой интеграции. И он закрывается наличием простого и удобного API, который оперирует правильно организованными абстрактными сущностями (а не особенностями внутренней реализации) и использует современные подходы для взаимодействия (к примеру, REST). При наличии такого API интеграция происходит очень просто.

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

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

А у старых банков с учетом монолитного кода и соответствующих ограничений интеграция происходит очень медленно. И на рынке вроде есть готовые решения — бери да подключайся, но финтех это сделает за два месяца, а банку понадобится год-два. Хоть при этом не нужно забывать, что Национальный банк Украины уже установил стандарт индустрии (PSD2) для финучреждений — Open Banking — интеграцию через API, но именно с банками.

Итоги

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

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

Поскольку API — это уже стандарт индустрии, который поддерживается регулятором, банкам пора задуматься о перестройке своей архитектуры. Потому что с точки зрения регулятора, это сейчас так же важно, как и выполнение финансовых нормативов.

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

Особая благодарность Wirex Lead System Product Owner Олегу Терлецкому за помощь в написании статьи.