Владимир Фролов, доктор экономических наук, профессор, научный руководитель АО «Цифровая Динамика».
Алексей Романчук, генеральный директор АО «Цифровая Динамика», главный ИT-архитектор платформы Banking-as-a-Service
Андрей Дорофеев, BaaS-евангелист АО «Цифровая Динамика», Executive MBA
Очень часто кредитные организации и их клиенты заявляют, что уровень технологичности российских банков выше, чем во многих признанных мировых финансовых центрах. И это правда. Дело в том, что исторически рыночная экономика появилась у нас в стране много позже, что позволило стартовать с более продвинутых технологий, чем, скажем, на Западе. Там созданные зачастую еще несколько веков назад наиболее крупные банки вынуждены поддерживать унаследованное ими достаточно древнее программное обеспечение, а отсюда вытекает и низкий уровень финансовых услуг.
Проблема усугублялась тем, что ничего принципиально нового в софтверной сфере, на что можно было бы перейти, долго не появлялось, а менять «шило на мыло» не было никакого экономического смысла. Конечно, писались новые модули, программисты пытались как-то поспевать за временем, но все это вживлялось в весьма архаичную ИТ-архитектуру. Поэтому это старье приходилось непрерывно «штопать» по примеру известной поговорки о тришкином кафтане, который, чтобы надставить с одного боку, приходилось укорачивать с другого. В результате банки имеют многочисленный штат in-house программистов, полную зависимость от них и постоянные авралы.
В последнее время перед всеми банками встали в полный рост проблемы киберуязвимости, очень высоких расходов на обслуживание клиентов, а также на содержание инфраструктуры с громадным количеством офисов и персонала.
В то же время буквально в последние годы появился новый подход к организации банковского бизнеса, его программного обеспечения — это построение ИТ-архитектуры финансовой организации на базе платформы Banking-as-a-Service (BaaS, Ббанк-как-сервис). Одно из принципиальных достоинств такого подхода является то, что штатным программистам не надо годами «штопать» старый банковский софт, а достаточно в кратчайший срок развернуть BaaS-платформу параллельно. После развертывания к такой BaaS-платформе, развернутой за периметром старой ИТ-архитектуры банка, можно быстро и бесшовно подключать с помощью API уже работающие на рынке клиентские сервисы.
Сделать это можно практически молниеносно — за несколько месяцев. А после – взять и выбросить все накопившееся за многие десятилетия ИТ-старье. Такая новая конфигурация позволит финансовым организациям освободиться от многочисленных офисов и избыточного персонала, буквально на порядки снизить издержки.
Операционные проблемы: старая ИТ-архитектура
Банковская бухгалтерия и расчеты были стандартизированы и автоматизированы достаточно давно. Многие западные банки работают на программных продуктах, развернутых на мейнфреймах еще в 70-е годы прошлого века. Например, очень актуальна проблема специалистов-разработчиков на архаичном языке COBOL.
России в этом смысле повезло чуть больше, поскольку ее банковская система фактически начала развиваться в 1990-е, когда уже появились АБС на более современных платформах, прежде всего на Oracle, хотя длительное время сохранялись и другие, более старые ИТ-решения.
Разработка в таких системах с точки зрения современного программиста выглядит из ряда вон плохо. Приходится писать код на каком-либо достаточно древнем языке, а протестировать готовый продукт возможно, только загрузив его на центральный сервер финансовой организации. Возникают огромные сложности с автоматизацией тестирования, развертывания, а также организации атомарности и непрерывности доставки новых релизов и внесения изменений в работающий софт. Добавим сюда регуляторное давление на банки, когда постоянно нужно готовить какие-то отчеты, выгрузки или новые формы. В итоге мы получаем постоянно замученных банковских программистов, которые занимаются преимущественно текучкой, а не современной цифровизацией финансовой организации.
С начала 2000-х бурно стал развиваться рынок систем ДБО и карточных платежных систем. При этом длительное время РФ была лидером в инновационности подобных сервисов. Однако всегда существовало жесткое разделение труда – основная бизнес-логика продуктов была в АБС, а ДБО выполняло лишь роль внешней оболочки и интерфейса взаимодействия с конечным клиентом. Со стороны ДБО разработчики были вынуждены дублировать многие функции процессов и логики продуктов из-за ограничений АБС, ее неспособностью масштабироваться с ростом нагрузки, выполняя роль буфера для последующей передачи данных в АБС. Часть функций попытались на себя оттянуть карточные системы, однако, их дороговизна и сложность сертификации, а в целом даже более сложные, чем в АБС проблемы разработки не позволили реализовать такой подход.
В результате создаваемый единый (с точки зрения клиента) продукт размыт между несколькими системами (ДБО, АБС, карточный процессинг), часть из которых дублируется по несколько раз. Это еще больше усугубляет сложность вывода нового продукта на рынок, ибо приходится тестировать работоспособность цифровых новинок вручную неоднократно. И часто финальное тестирование продукта возможно только уже на рабочей системе «в боевом режиме».
Добавим сюда и то, что в банках помимо вышеуказанных систем поддерживается обмен с различными внешними финансовыми и нефинансовыми системами. Многие банки повелись на идею нулевых годов, что должна быть еще ESB-система (Enterprise Service Bus, шина данных) с BPM-движком (Business Process Management), которая по замыслу должна была эффективно маршрутизировать внутренние данные, но по факту лишь усугубила их излишнее дублирование и создало лишний центр постоянных расходов.
Что в итоге? Банки каждый день непрерывно латают свой «тришкин кафтан» разрозненных ИТ-систем – то здесь добавят заплатку, то там, то удлиняя его, то укорачивая. Бесконечный процесс, отвлекающий от основной цели — создавать для клиента качественный сервис.
Отсюда и прямые потери для бизнеса – запуск новых продуктов идет неприемлемо долго, на выходе часто получается плохо протестированный продукт, который непрерывно ломается, выглядит крайне уныло и убого на фоне более продвинутых предложений конкурентов.
Проблемы с безопасностью
Дальше – больше. Как ни штопай тришкин кафтан – он все равно остается дырявым. В последние годы процесс обнаружения различных уязвимостей в системах, библиотеках фактически встал на поток. Каждый день мы видим отчеты: то там, то сям появилась новая проблема, и нужно бегом бежать исправлять ее, обновлять свои информационные системы. Особенно учитывая, что для банков это очень серьезная проблема – каждая эксплуатируемая уязвимость чревата потерями средств клиентов, а, следовательно, и утраты доверия к финансовой организации.
Это означает, что в современном мире частота обновлений информационных систем, особенно доступных снаружи, должна быть ежедневной, если не чаще. Необходим целый конвейер анализа разрабатываемых продуктов, быстрого тестирования и внесения изменений. Одними бумажными сертификатами тут уже не отделаешься – нужна реальная безопасность. Но готовы ли банки к такому темпу?
А ведь безопасность, как мы знаем, бывает еще и внутренняя. Многим сотрудникам банка по роду своей деятельности требуется доступ к тем или иным данным клиентов. В результате утечки клиентских данных стали серьезной проблемой. А если данные клиентов размыты по всем системам, то это многократно более серьезная проблема, так как везде необходимо автоматически вести аудит доступа сотрудников к данным, нужны разные уровни, чтобы сотрудники не могли видеть те данные, к которым у них не должно быть доступа, и т. п.
Что делать?
Необходимо устранить фундаментальную причину – выкинуть пресловутый «тришкин кафтан» и кардинально пересмотреть ИТ-архитектуру финансовой организации. Понятно, что сделать это с программным обеспечением работающего банка практически невозможно.
Однако за последние десятилетия мировое банковское сообщество придумало, как это сделать. Необходимо начать строить новый цифровой банк, финансовую экосистему параллельно основному бизнесу как отдельный независимый филиал финансовой организации или даже на отдельной лицензии центрального банка (небанковской кредитной организации или оператора финансовой платформы).
Дальше необходимо пересмотреть архитектурный подход. Одной из основных проблем, которую мы обозначили выше, является излишняя перегрузка АБС продуктовым наполнением. Необходимо оставить в АБС минимальные функции, в идеале только бухгалтерия и специфическая отчетность перед регуляторами. А все продуктовые функции, процессы, транзакции должны быть размещены в специализированном банковском движке – BaaS-платформе.
Идея платформы Банк-как-сервис была реализована в период 2009–2012 гг. как SaaS-решение (Software-as-a-Service), только транслируемое именно на банковские продукты. И изначально решение Banking-as-a-Service эволюционировало из систем ДБО, которые стали «брать на себя» больше самостоятельности. Первоначально задача BaaS-систем заключалась в том, чтобы решить вопросы интеграции банка во внешнюю среду – т. е. создать интеграционный и/или встроенный (embedded) банкинг. Появились даже соответствующие государственные инициативы в части Open API (например, PSD2 в Европе), и в целом, банки стали пытаться открывать API-интерфейсы.
Однако при этом они ничего не меняли в архитектуре, а значит, все осаждавшиеся выше проблемы остались.
Каким же должен быть современный цифровой банк? Авторы настоящей статьи предлагают следующую идеальную формулу:
Банк = АБС + BaaS + UI/UX
Роль АБС, как известно, состоит в организации ведения главной бухгалтерской̆ книги банка для создания корректных проводок и правильного формирования отчетности для регулятора. Для этих целей̆ используют любое оптимальное из имеющихся на локальном рынке решений. Важно и то, что вся продуктовая линейка и разработка бизнес-процессов происходит за пределами АБС — на стороне BaaS. А слой UI/UX (User Interface/User Experience) уже представляет собой мобильные или веб-приложения, чат боты и иные каналы непосредственного взаимодействия с клиентом.
В архитектуре современной финансовой экосистемы BaaS решает задачу движка и оркестратора банковских процессов, правильно сочлененного с главной̆ книгой̆ АБС и доступного вовне в виде API, которое используется в клиентских интерфейсах и/или интеграционных решениях. Такой̆ подход обоснован с точки зрения эволюции банковских сервисов в сторону встраивания их в продукты, мини-экосистемы или полноценные бизнес-экосистемы.
Подобное понимание BaaS-платформы существует и за рубежом, где, как мы описывали выше, проблема стареющих Core Banking (АБС) систем еще более остра. И BaaS-платформа в том числе решает задачу извлечения продуктов из Core Banking систем.
Что получит финансовая организация в такой архитектуре? Давайте перечислим принципиальные моменты:
· BaaS-платформа построена на современных архитектурных подходах, продвинутых технологиях. В результате чего можно будет быстро устанавливать обновления, пропуская все изменения через автоматический конвейер (CI/CD, автоматическое тестирование и анализ на уязвимости) – в итоге можно устанавливать безопасные и протестированные обновления хоть каждый день и не по одному разу;
· можно быстро создавать и запускать «в эфир» новые продукты;
· у финансовой организации появляется мощная платформа для всех внутренних и внешних интеграций;
· финансовая организация получает единое окно для доступа к своим клиентам, операциям с ними с учетом всех необходимых разграничений доступа и его аудита к клиентским данным со стороны сотрудников, а значит, таким образом блокируется утечка персональных данных клиентов;
· у финансовой организации появляются новые источники доходов. Опубликовав свою спецификацию API, она имеет возможность реализовывать новые проекты по интеграционному и встраиваемому банкингу, участвовать в инициативах центрального банка (ЦБ РФ, если речь идет о российском рынке) типа Открытых API, ЦФА или брать под свое крыло финтех-проекты;
· при необходимости появляется более простая возможность выхода на рынки соседних стран – меняем только АБС, отчетность, остальные продукты могут оставаться неизменными;
· повышается отказоустойчивость – BaaS-платформа построена на современных архитектурах, позволяя неограниченное масштабирование.
Пролог вместо эпилога
Итак, как мы уже отмечали в начале статьи, в российских бизнес-кругах принято рассказывать, как стремительно отечественные банки создали в нашей стране современную платежную инфраструктуру, которая во многом превосходит западные с их консерватизмом и архаичной банковской ИТ-архитектурой. Особенно заметно это отставание было в Европе, где банки-динозавры застряли в своих бизнес-процедурах 30–40-летней давности. Будете «в Европах», советуем зайти в какое-нибудь отделение Deutsche Bank в Германии или Banca Intesa в Италии и попробовать обменять евро на доллары, открыть счет или совершить платеж (лучше – трансграничный). У вас сложится впечатление, что вы оказались в отделении почты СССР где-нибудь 70-х годов прошлого века.
Те же эксперты из Boston Consulting Group (BCG) в соавторстве с агентством QED в своем свежем июньском исследовании признают, что в целом финтех-компании преуспели там, где не готовы и не могут успешно работать «аналоговые» банки. Это безусловно дало возможность бурно расцвести финтех-индустрии. Вертикальные SaaS-решения устранили пробелы в удовлетворении потребностей продавцов (например, ресторанов, розничных магазинов), в то время как современные эквайреры упростили многоканальные платежи.
Наши соотечественники в 1990-е годы «с нуля» превзошли западные банковские технологии и создали свою собственную передовую российскую банковскую систему. Тогда собственники бизнеса не тянули кота за хвост, а сами быстро принимали решения, «отвечая за базар», как говорили в те времена. В лихие 90-е промедление в деловой среде было буквально смерти подобно – и для бизнеса, и для его хозяев.
В «жирные» же нулевые годы эта энергетика первопроходцев стала угасать. Поэтому некоторые руководители банков предпочитают отсидеться, а не стремительно меняться, как того требует ситуация в период кризиса. А надо понимать, что кризис — это время гибели устаревших «тормозных» бизнесов и прекрасный шанс для выхода в лидеры новых, дерзких и технологичных.
На Западе уже подули новые ветры. Там финансисты включились в гонку технологий, на которые они не скупятся тратить многие миллиарды долларов, чтобы достичь технологического лидерства. Общий объем инвестиций в 2024 году вырос до 95,6 млрд долларов!
Западные игроки умеют достигать результата стремительно, если уже приняли решение. Из последних новостей не можем не упомянуть инициативу глобальных бигтехов – Google (Alphabet), Facebook (Meta)*, PayPal, Visa, Mastercard, Uber, X (x-Twitter)* – стать альтернативой существующей мировой банковской системе. Для того, чтобы оперативно осуществить этот план «Б», западным бигтехам понадобится встраивать новые финансовые решения через открытые протоколы API.
Они ориентируются на middleware — платформенные решения Banking-as-a-Service, которые активно применяют игроки финансовой индустрии и на Западе, и в России для быстрой и бесшовной интеграции платежных решений.
Есть известная русская пословица: «Семь раз отмерь, один раз отрежь». К сожалению, в нашей стране остаются еще руководители, которые «сидят и меряют», ва процессы отрезания откладывают на потом. А мир между тем уходит в стремительный отрыв. На Западе и Востоке уже начался массовый переход на принципиально новые технологии. Быть лидерами там, особенно у американцев и китайцев, – в крови. Google (Alphabet), Facebook (Meta)*, Microsoft и многие другие бигтехи тому доказательство. В том числе, в тематике искусственного интеллекта они также законодатели мод.
Несомненно, что переход на платформу BaaS они тоже завершат в кратчайшие сроки. Не остановят их и необходимость существенных инвестиций в финансовые технологии.
Надежда умирает последней. Поэтому остается только надеяться, что у нас в стране тоже есть свои многочисленные и решительные форейторы прогресса.
Тем более, что место лидера в этой номинации практически свободно. Несмотря на то, что в России появляются проекты на BaaS-платформах, их функционал пока сильно урезан и ограничен лишь консервативностью мышления бизнесменов. Как правило, в выведенных на рынок проектах речь идет лишь о традиционных банковских операциях в фиатных валютах. А это малая толика возможностей BaaS-платформ. Ранее мы много писали о необходимости строить платформенные решения не только на базе фиатных валют, но и используя имущественные активы, что позволяет многократно расширить функционал банков. Также следует опираться на фундаментальные исследования в сфере математического моделирования при автоматизации столь сложной задачи, как управление ликвидностью в мультивалютных системах. Все это в совокупности в десятки раз снижает издержки, число офисов, количество персонала.
Особо отметим, что реализация платформы Banking-as-a-Service с полным обеспечением имущественными активами и непрерывными переменными особенно актуальна для трансграничных платежей и может быть достаточно быстро выведена на рынок. О такого рода подходе авторы уже неоднократно писали в своих предыдущих статьях.
#FinTech #BankingasaService #BaaS #NeoBank #DigitalBank #DeFi #EmbeddedFinance #MobilePayment #DigitalWallet