От решения Core Banking (CBS) с модулями для различных направлений бизнеса, включающих депозиты, кредитование, платежи и торговлю, которое было интегрировано в конце 1990-х по 2000-е годы, акцент сместился на вытеснение ядра/компонентизацию. От банков до ИТ-поставщиков и аналитиков мантра была одной и той же: разбивать CBS на более мелкие компоненты или создавать меньшие приложения с поддержкой микросервисов, обеспечивающие плавное развертывание и легкое обновление. Управление основным банковским сектором, который стал своего рода гигантом для банков/ИТ-поставщиков с множеством концов, подключенных к CBS, было сложной задачей. Благодаря цифровизации и постоянным изменениям в поведении потребителей число транзакций, попадающих в ядро, резко возросло. Банки продолжают экспериментировать с исправлениями/инструментами и собственными разработками для удовлетворения этих потребностей, хотя этого недостаточно. В результате обновление базовой банковской системы/архитектуры, хотя и является необходимостью, становится немыслимым для технического директора/директора по информационным технологиям банков, учитывая риски/простои/миграцию/интеграцию и тому подобное.

В то время как CBS развивалась, крупные банки использовали разные подходы и начали экспериментировать с управлением несколькими системами/множествами поставщиков для многих направлений бизнеса, таких как кредитование/торговля/казначейство/платежи, зная ограничения с точки зрения функциональности/процессов и отойдя от зависимости от монолитное ядро. Учитывая растущие требования бизнеса и необходимость инноваций, позволяющих получить преимущество над конкурентами, банки изучают более специализированные решения во многих областях. У банков есть несколько вариантов развертывания решений, ориентированных на специализированные области, тем самым обеспечивая лучшее качество обслуживания клиентов. Банки начали использовать разрозненные системы для микрокредитов, розничных кредитов, корпоративных кредитов - от выдачи до управления кредитованием и сбора кредитов по мере расширения бизнеса в течение этого периода. В рамках розничного кредитования существовали возможности изолированных систем для золотых кредитов/ипотечных кредитов/кредитов под залог ценных бумаг из-за сложности обработки этих кредитов, которая была уникальной. Хотя адаптация этих продуктов в рамках более крупной системы розничного кредитования была возможной в краткосрочной перспективе, банки почувствовали необходимость со временем перейти к другим системам/продуктам, отбросив фактор стоимости. Имея разрозненные системы, банки столкнулись с проблемами интеграции с основными данными управления клиентами, справочными мастерами, праздничными мастерами, бухгалтерским учетом и GL для поддержания единого источника достоверной информации, но добились успеха. Как и в случае с розничными кредитами, в случае с корпоративными кредитами банки перешли на несколько систем, поскольку ни одна система не могла удовлетворить различные потребности: срочные кредиты, синдицированные кредиты, структурированные кредиты, строительные кредиты - все с разными процессами и сложностью. Короче говоря, банки уменьшили зависимость от CBS для удовлетворения потребностей в кредитовании и перешли на специализированные системы. Но когда объемы и сложность увеличились, они столкнулись с проблемами в рамках специализированных систем.

Аналогичным образом, в случае платежей, с ужесточением регулирования и необходимостью принятия местных/глобальных стандартов, таких как ISO 20022, RTGS, MT to MX для SWIFT, банки зависели от нескольких подсистем для удовлетворения потребностей платежей в реальном времени, файловых платежей, перекрестных платежей. пограничные платежи – и здесь процессы жизненного цикла/типы сообщений/интерфейсы различаются. Тенденция продолжилась и в сфере услуг торгового финансирования, где банки внедрили различные специализированные системы для обычной торговли, финансирования цепочки поставок и денежных переводов на иностранной валюте. Банки также внедрили различные системы для казначейства - это может быть глобальная ИТ-система, обслуживающая большой набор классов активов - денежный рынок, ценные бумаги, деривативы и т. д., а также локальное программное обеспечение для местных продуктов/требований. За это время банки также внедрили Главную книгу предприятия, уменьшив зависимость от Core для консолидации портфеля бухгалтерского учета.

В то время как Core имел ограниченную функциональность для многих специализированных областей, банки были вынуждены перейти на несколько подсистем для обработки бизнеса для различных функциональных областей, а Core остался только для консолидации бухгалтерского учета и ГК. Значимость и преимущества Core начали спадать после двух десятилетий доминирования. CBS оставалась необходимостью для банков.

В то время как несколько подсистем были обычным явлением для разных направлений бизнеса, банки по-прежнему были тесно связаны с одним основным банковским решением/одним поставщиком. Концепция нескольких подсистем для базовой системы или различных основных банковских систем внутри банка осталась в теории – почти немыслимой. Благодаря возможности компоновки и архитектуре микросервисов поставщик основного банковского обслуживания создал несколько подсистем, чтобы более крупные системы оставались актуальными и дополняли ядро. Появилось множество новых поставщиков CBS с новыми технологиями и современной архитектурой, пытающихся конкурировать с традиционными игроками, но им не хватало функциональности. Поддержание Core Banking было сложной задачей из-за различных правил/процессов/продуктов, которые необходимо было встроить в Core, и обновление до последней версии было не вариантом, а обязательным для банков. Наиболее частым вопросом технического директора банка поставщику CBS в рамках обновления версии был: «Как долго версия будет храниться до следующего обновления?». Чтобы поддерживать изменения в технологии и соответствовать требованиям рынка, поставщик CBS был вынужден выпускать второстепенные версии примерно каждые 6 месяцев. Но все же оставались огромные пробелы в связи с увеличением спроса со стороны клиентов/банков и уменьшением развития функциональности в рамках CBS - несмотря на проблемы с дизайном, проблемы с доменом и совместимостью баз данных. Разработка новой архитектуры и технологий с открытыми системами, открытыми API, открытой базой данных и открытыми платформами была обязательна для ядра, исходя из потребностей рынка, банка, нормативных требований или облака.

Несколько центральных банков в разных странах представили концепцию цифровых банков, которые могут быть либо новым игроком, либо цифровым подразделением существующего банка. Это также открыло тему многоядерных систем в банковской системе, но банки расширили существующее ядро ​​вместо того, чтобы принять новую CBS для этих нужд.
На некоторых рынках, таких как Индия/Южная Азия, объемы транзакций были довольно высокими, и CBS подверглась серьезному стресс-тесту, а новые модели развивались в основном для удовлетворения потребностей в высокой доступности и высокой производительности. Количество процессоров и ядер, необходимых для обработки большого объема, увеличивалось, что приводило к высоким затратам. Большинство регуляторов на этих рынках не были готовы к внедрению облачных технологий, что могло бы способствовать горизонтальному или вертикальному масштабированию приложения.

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

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

• SEO-контент и PR-распределение. Получите усиление сегодня.
• PlatoData.Network Вертикальный генеративный ИИ. Расширьте возможности себя. Доступ здесь.
• ПлатонАйСтрим. Интеллект Web3. Расширение знаний. Доступ здесь.
• ПлатонЭСГ. Углерод, чистые технологии, Энергия, Окружающая среда, Солнечная, Управление отходами. Доступ здесь.
• ПлатонЗдоровье. Биотехнологии и клинические исследования. Доступ здесь.
• Источник: https://www.finextra.com/blogposting/24972/can-a-multi–core-banking-solution-cbs-implementation-can-change-the-conundrum-for-banks?utm_medium=rssfinextra&utm_source=finextrablogs