Mobile Monitoring Solutions

Search
Close this search box.

EXCLUSIVE: “Rebuilding Banks…it’s a team effort!’ – Temenos, Capgemini and MongoDB in …

MMS Founder
MMS RSS

Posted on mongodb google news. Visit mongodb google news

Share this post:

‘Componentisation’, sometimes known as composable banking, has emerged as the alternative to ‘big bang transformation’. By its very nature, it demands compatible solutions, underpinned by strong vendor partnerships, such as that between Temenos, Capgemini and MongoDB

We asked Joerg Schmuecker, director of industry solutions at document database MongoDB, Mark Ashton, senior director at banking IT solutions provider Capgemini Financial Services, and Paul Carr, global head of partner ecosystems at banking-as-a-service giant Temenos, to explain the concept and implementation of ‘componentisation’ and how it shapes their partnership.

THE FINTECH MAGAZINE: What is componentisation and why are banks interested in it?

PAUL CARR: Componentisation is all about breaking down big, monolithic systems into smaller, manageable chunks that are easier to install, implement, run and upgrade. This is especially important with the regulatory requirements we’re seeing around databases, enabling us to have faster, more easy and cost-effective access to data securely, without having to change entire banking systems.

MARK ASHTON: From a business perspective, the need to access data that’s spread across their organisation in real time is one of the most significant drivers of componentisation among banks. The arrival of nimble fintechs which can access data quickly, has led larger organisations to re-evaluate how they can compete using new agile, more iterative approaches, which break complex information down into simpler elements.

For legacy-based organisations, accessing data requires so much navigation and understanding, and regulatory and compliance challenges make it hard to unlock the value within it. Looking at it from a technology perspective, to transform legacy systems you have to decompose them, extract and componentise things to provide the necessary access and reinvigorate established systems.

Then there are the architecture and the ecosystems that support all that. The challenges are causing a lot of organisations to rethink their architecture, like payment systems that don’t meet modern requirements. Componentisation is one way of changing those building blocks.

“The need to access data that’s spread across their organisation in real time is one of the most significant drivers of componentisation among banks”

Mark Ashton, Capgemini Financial Services

In terms of potential benefits, financial institutions are becoming data owners and brokers for their customers, with onboarding a classic example. Historically, a customer might see a product like a loan advertised online, but taking one out meant having paperwork sent out for them to sign and return and getting documents reviewed.

Fintechs can tell them within 30 seconds if they might be eligible and, if they choose to complete the journey, give them an answer in less than two minutes, all driven by integrating their data with that of other organisations, including credit reference and fraud prevention agencies. Componentisation can help incumbents ensure they also have the right data at the right point of need.

JOERG SCHMUECKER: The most important thing to banks that have been around for 30 or 40 years, is their ecosystem of customer data, secured and collated over that time. Bigger, older banks, are very conservative in their approach, so asking them to go big bang and convert everything in one hit is never going to happen. Componentisation, especially with data and databases, enables them to go to the next level of banking solutions without having to build everything in-house and, where you do, being able to switch to another provider’s better implementation of the same thing.

For instance, I might have a payment system at my bank that isn’t SEPA Instant payment compliant. I need a component that I can plug into my platform to make me compliant as quickly as possible. If I have everything handcrafted, that might be very difficult but componentisation makes putting stuff into the right boxes easy, and allows you to change those boxes.

Those boxes also need to be able to share data in an easy format, you need to ship the data around. That’s where componentisation and data touch together, because shared state is the hardest part in software development. Temenos is our customer and partner, and it recently announced that MongoDB will be underpinning its Transact platform. In 2022, Temenos built its platform on Amazon Web Services and ran its high-water mark benchmark with MongoDB, with a now-obsolete database behind it. Now it can do the same on Azure, by simply changing the components underpinning its infrastructure. That’s an example of a componentisation well done.

TFM: How has the changing nature and volume of data driven the case for componentisation?

JS: We used to build systems around disk spaces; now, we are building them around use cases, enabled through better storage platforms, with better development technologies and Cloud providers that can run things in a much more scalable way. When we talk about data, most people think about hard disks spinning. These things used to be incredibly expensive, but now our phones probably have way more space on them than all the disks in the world had in the 1980s.

Because we’ve transitioned to the point where this space is free, it changes the way we handle data. We don’t care about storing redundant information anymore because it’s not expensive, whereas we used to have to save bytes through steps like only referencing years as two digits, not four. That was the situation we came from, and that’s most of the relational database management systems we are dealing with – and a lot of the mindset behind them, too.

With document databases like MongoDB and others, because you have humongous amount of data space available to you, you can aggregate and bring it together on demand, and slice and dice it as needed for the consumer. So, if I pay a hotel bill via a wire transfer in Italy and then, two days later, go to Italy and want to pay with my credit card, I don’t expect my bank to flag that as a potentially fraudulent transaction. It should know I paid the hotel and I’m very likely in Italy, so should take the view that it’s a low risk, especially if I’m only buying an ice cream for €3.50.

“We used to build systems around disk spaces, now, we are building them around use cases, enabled through better storage platforms and Cloud providers”

Joerg Schmuecker, MongoDB

This is what the fintechs have been brilliant at: they have a small domain, a single bucket [of data] and therefore a great overview.

TFM: What are the first steps for organisations thinking of embarking on a componentisation journey?

PC: Banks must have realistic expectations rather than thinking ‘you’re going to transform my entire business in six months if I implement this strategy’. Going from a monolithic, 30-year-old system, to a brand new, composable, componentised solution within six months, doesn’t happen, alas.

This is one of the reasons why our deployment strategy at Temenos involves engaging with partners like Capgemini early on when we start talking to banks, because we don’t know all of our competitors’ offerings, software, etc, whereas our partners do. It’s about understanding what the bank wants to achieve. Does it want to modernise, does it have an old system and wants to keep the same as it has today but on a new platform, or is it looking to do something different?

Lots of banks are looking at banking-as-a-service – not just to satisfy their customers with financial products, but also to consider selling their banking platform to other companies. So it’s understanding where banks are today, where they want to be and how we can get them there, then making sure we’re partnering with the right companies, like Capgemini, like Mongo, to offer a solution.

TFM: How can organisations get ‘componentisation-ready’?

JS: Being clear on how becoming more data-driven can benefit their business – that’s a good starting point, because otherwise they end up with big data lakes that people just pipe information into, hoping they will be able to make sense of it afterwards. It’s easy and cheap to collect large amounts of data, but making sense of it gets expensive.

Once clear what they want to achieve, they can define their data architecture, which might mean having low-latency streaming platforms as with electronic trading platforms. Then, even if their technology is clunky and fragmented, they can use something very low latency to bind their components together.

MA: There’s a lot of hype out there, in terms of what generative AI can do. Data underpins AI and the security and guardrails around it will certainly drive some interesting conversations. I’m optimistic that it will have value as a tool and help with efficiencies. But it’s not going to be a universal panacea.

Meanwhile, the use of data platforms is becoming almost mandatory in this componentised world, with lots of federated data to manage, monitor, track and keep as the core building blocks for any modern architecture. Almost all our banking customers, unless they’re a fintech, are looking at modernising and moving away from legacy systems for their core banking platforms, opening conversations around a modern architecture that leverages technologies like Temenos, AWS and Azure.

“Componentisation is the future but how we, as vendors, align is key to its success “

Paul Carr, Temenos

It also raises questions like ‘how do we define data modelling and ownership when integrating and sharing data with third parties?’. Even with something as simple as an address, we need to ensure information we share is consistent within our own and third-party environments, for seamless integration.

TFM: Banking is a highly regulated industry and banks might be concerned that componentisation introduces risks. How can that be avoided?

PC: We work with the Securities and Exchange Commission in the US, with the General Data Protection Regulation in the UK, and multiple other regulatory requirements to create our ‘Country Model Bank’. This sits above our product, satisfying country regulations.

We would love it if a bank took our entire platform, from digital front end to core banking, financial crime and wealth management, taking care of the regulatory requirements across everything. But we know that doesn’t happen in the real world, so we need to make sure that if we’re satisfying regulatory requirements in one part of the component, other vendors who are fulfilling the others are doing the same.

If we’re going to have multiple solutions componentised into smaller chunks, we have to think about how we ensure the regulatory requirements span all of them. There are certain things you must start with for componentisation – a platform and a baseline. Whether that’s a Cloud or on-prem infrastructure, everything needs to fit across the components you’re going to use.

We need to look at the basics first, and plan, plan, plan before implementing. Regulatory requirements, data sharing and data availability requirements, etc – if you don’t have that basic foundation the rest becomes impossible to manage, upgrade, implement or deploy. Componentisation is the future but how we, as vendors, align is key to its success. It really speaks to a partnership model because no one institution can cover everything, particularly with different data reporting standards and geographies.

For me, the key is having simplicity across the platform and all working together towards the same outcome.

TFM: How can componentisation support an alternative business model for legacy institutions?

PC: All our 3,500 customers are considering how they can generate more business and opportunity than just with current accounts, loans, mortgages, etc. With increasing competition, banks must be agile in offering new services to keep their existing customers and tempt new ones in. Changing their entire banking solution to enable that is not feasible, but componentising it to be able to offer a new loan or loyalty scheme, is.

Componentisation is a real enabler for selling their services, not just to customers but to other businesses, almost becoming fintechs themselves. It’s going to be a very exciting ecosystem, with greater competition, where customers have lots of banks from which to choose the one that offers something they are particularly looking for.

BaaS and SaaS, supported by componentisation, will bring this revolutionary change to a system that’s been around for three or four hundred years.


This article was published in The Fintech Magazine Issue 30, Page 12-14

Article originally posted on mongodb google news. Visit mongodb google news

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.