Софт из 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 Олегу Терлецкому за помощь в написании статьи.

👍НравитсяПонравилось6
В избранноеВ избранном2
Подписаться на тему «финтех»
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


7 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Для банков ситуация усугубляется проблемой снижения ставок на рынке и существенным снижением маржи бизнеса с одной стороны и ростом "костов«/сильной инфляцией на ресурсы с другой, штаты раздуты под кучу сгенерированных правил, не говоря уже о «внутреннем предпринимательстве» (в негативном ключе). Поэтому до конца дойдут не только лишь все..... И падающее знамя подхватят финтех компании или колаборации Моно/Юниверсал....

Для банков ситуация усугубляется проблемой снижения ставок на рынке

Може й так, але за останній рік, напевне 3+ банки в Україні наче поали проекти по модернізації.

И падающее знамя подхватят финтех компании или колаборации Моно/Юниверсал....

От тут якраз важливо, що Універсал — це «паравозик, який зміг» (моно — це фактично їх продукт).

Нагадало старий анекдот.
Стоять старі байкери косухи, пиво, хеві метал і все таке. А поруч молоді спортивні ганяють вийо..ться. Тут один з молодих підїзжає до старих та питає:
— Хлопці, ми ж такі ж як і ви байкери. Тільки байки швидші та потужніші. Чого б не поговорити та не подружитись?
Старий байкер і каже:
— А чого з вами дружити ви ж кожної весни нові...

Статтю треба перейменувати в
«Ми хороші, вони погані»

Декілька простих моментів

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

Вибір «свої серваки/хмара» робиться на основі нефункціональних вимог. Наприклад, як ви й написали нижче, че можуть бути вимоги регулятора по надійності зберігання інформації. І те що деякі «фінтех стартапи» забивають на ці вимоги дає (бо не всі клієнти про таке задумуються) їм гнучкості.

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

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

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

Зараз у зумерів можно згадувати про «флешбеки», так от мене накрило флешбеками про інтеграцію з криптобіржами, там АПІ часто не надійний і покриває лише «хепіпас». Банальний ФІКС, якщо є то десь дуже окремо і дуже базовий. А ще є використання РЕСТ для асинхронних процесів з втратою «неважливих даних».
Хоча може за 1-2 роки все змінилось і фінтех стартапи пройли весь той шлях, який повільні банки проходили років 30.

Богдане, привіт
релевантні коменти

на рахунок вибору серваки-хмара, проблема якраз в тому, що в більшості випадків саме застарілі вимоги регуляторів не дають можливість зробити економічно зважений вибір. А надійність хмари вже давное переступила співвідношення інвестиції/надійність, коли для організації аналогічної гнучкості, масштабування та відмовостійкості системи на базі on-land інфраструктури робить існування бізнесу нелогічним. Звичайно при обслуговуванні 100+ клієнтів через 2 відділення не потрібні супер технології, але ми розглядаємо кейси масс продуктів заснованих на цифровому підході, куди все активно рухається в світі і Україні.
Розвиваючи ліцензований британським FCA (аналог нашого НБУ в частині повноважень регуляції фінансових компаній) продукт, який працює в хмарі ми побудували і далі продовжуємо працювати над рішеннями, що працють на ринки Європи, Азії та США та відповідає вимогам (в деяких випадках жорсткішим, ніж до банків) на кожному з цих ринків.
В будь-якому разі питання в тому, щоб все таки почати перехід та модернізацю для банків, що відразу відобразиться на швидкості впродвадження фіч, гнучкості сервісів та в результаті на рівні послуг. А деякі регулятори, в т.ч. наш НБУ сильно застаріли в своїх вимогах, в більшості випадків це виглядає як регуляція заради регуляції.

Щодо надійності крипто-компаній, так, в 2017-18 роках, проекти з цифровими валютами тільки розвивалися, виникали питання до стабільності. Ми активно приймали участь в розвитку цієї індустрії і маю сказати, що зараз продукти, які є ліцензованими і працюють в Європі, США, Азії зобов’язані дотримуватися таких же вимог до систем, як і банки. Оскільки в таких юриздикціях криптовалюти в більшості прирівнюються до електронних грошей, де діють такі ж правила ліцензування і слідуючі за цим вимоги до інфраструктури, систем, швидкодії, відмовостійкості і тд.
Дійсно, за 2 роки індустрія пройшла мега апгрейд до рішень корпоративного рівня, що підтверджується роботою, наприклад, Mastercard з продуктами WIirex.

Звичайно при обслуговуванні 100+ клієнтів через 2 відділення не потрібні супер технології,

А завтра Амазон вирішує, що ви є партнерами Парлер і дропає вашу інфраструктуру (бо можуть) :)

Знову ж багато маркетингового тексту, але суттєвої різниці між банками та «фінтех стратапами» я так і не побачив, і що саме банки можуть перенйняти у стартапів поки не зрозуміло.

Основну організаційну проблему — вертикальну бюрократизовану організаційну структуру, банки почали вирішувати вже десь в 2010, хтось вдаліше, хтось менш вдало.
Але тут питання не ідеї (яку можливо перейняти), а саме розмірів оргструктури.

Сценарії, про Амазон дуже поширені в дискусії про хмари, їх також потрібно планувати в побудові інфраструктури. З серверами імо набагато більші ризики, особливо зі сторони відмовостійкості, впливу зовнішнього середовища і тд.
Що цікаво — моживість відновлення роботи системи на базі іншого провайдера критична не тільки для фінансового сектору. Наприклад Netflix заявляє, що можуть відновити роботу своєї платформи на базі будь-якого клауд провайдера за 10-20 хвилин.
Cloud-agnostic — саме той підхід, що повинен завжди бути в рамках корпоративних рішень, де є можливість відновлення сервісів без прив’язки до продвайдера послуг та без втрати даних (ми ж працюємо з грошима). В розробці наших систем ми теж дотримуємося цього принципу та активно працюємо над рішеннями що допомагають масштабуватися, розгортати сервіси в будь-якому середовищі.

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