Modernizing Core Banking: A Shift Toward Composable Systems

Modernizing core banking systems with MongoDB can bring many benefits such as faster innovation, flexible deployment, and instant scalability. According to McKinsey & Company, it is critical for banks to modernize their core banking platforms with a “flexible back end” in order to stay competitive and adapt to new business models. With the emergence of better data infrastructure based on JSON and the ongoing evolution of software design, the next generation of composable core banking processes can be built on MongoDB's developer data platform, offering greater flexibility and adaptability than traditional systems.

The current market: Potential core banking solutions

Financial disruptors such as fintechs and challenger banks are growing their businesses and attracting customers by building on process-centric core banking systems, while traditional banks struggle with inflexible, legacy systems. As seen in Figure 1 below, two potential solutions are the core banking “platform” and “suite”. The platform solution involves using a single vendor and several closely integrated modules. It also includes a single, large database and a single roadmap. On the other hand, the suite solutions refers to using multiple vendors, multiple loosely integrated modules, multiple databases and roadmaps. However, both of these systems are inflexible and result in vendor lock-in, preventing the adoption of best-of-breed functionalities from other vendors.

Graphic displaying the 3 pillars of core banking solutions: Platform, Suite, and Composable Ecosystem. Under platform, the following specifications are provided: Single vendor; tightly coupled; single, static database of giant proportion and complexity; single roadmap; entire platform sold as one. Under suite, the following specifications are provided: multiple products, often via acquisition; tightly coupled; diverse databases with coordinated schema; multiple, tightly coupled roadmaps; entire suite as
Figure 1: Core banking solutions: platform, suite and composable ecosystem.

A new approach, known as a composable ecosystem as seen on the far right of Figure 1, is being adopted by some financial institutions. This approach consists of distinct independent services and functions, with the ability to incorporate "best of breed" functionality without major integration challenges, multiple loosely coupled roadmaps, and individual component deployment without vendor lock-in. This allows for specialization and the development of advanced individual components that can be combined to deliver the best products and services and is better at adopting new technologies and approaches.

Composable ecosystems with MongoDB's developer data platform

MongoDB’s developer data platform is the best choice for financial institutions to build a composable core banking ecosystem. Such an ecosystem is made up of four key building blocks as seen below in Figure 2: JSON, BIAN, MACH, and data domains. JSON is a widely-used data format in the financial industry, and MongoDB's BSON extension allows for the storage of additional data types. BIAN is a standard that defines a component business blueprint for banking, and MongoDB's technology supports BIAN and embodies MACH principles. MACH is a set of design principles for component-based architectures, and data domains enable the mapping of business capabilities to applications and data. By using MongoDB's developer data platform, financial institutions can implement flexible and scalable core banking systems that can adapt to the ever-changing market demands.

This image presents pillars of the data platform as pieces to a puzzle. The four pieces are as follows. One: BIAN, Business Banking Processes and Structures. Two: JSON, data model. Three: MACH, Architecture patterns (microservices, API-first, cloud-native, headless). Four: Data Domains: Business functions.
Figure 2: MongoDB, the developer data platform for your core banking system.

MongoDB in action: Core banking use cases

Companies such as Temenos and Current have utilized MongoDB's capabilities to deliver innovative services and improve performance. As Tony Coleman, CTO of Temenos, said, "Implementing a good data model is a great start. Implementing a great database technology that uses the data model correctly, is vital. MongoDB is a really great fit for banking." MongoDB and Temenos have worked on a number of new, component-based services to enhance the Temenos product family. Financial institutions can embed Temenos components to deliver new functionality in their existing on-premises environments or through a full banking-as-a-service experience with Temenos T365, powered by MongoDB on various cloud platforms. Temenos has a cloud-first, microservices-based infrastructure built with MongoDB, which gives customers flexibility while improving performance.

Current is a digital bank that was founded with the aim of providing its customers with a modern, convenient, and user-friendly banking experience. To achieve this, the company needed to build a robust, scalable, and flexible technology platform. Current decided to build its core technology ecosystem in-house, using MongoDB as the underlying database technology. "MongoDB gave us the flexibility to be agile with our data design and iterate quickly," said Trevor Marshall, CTO of Current. In addition, MongoDB's strong security features make it a secure choice for handling sensitive financial data. Overall, MongoDB's capabilities make it a powerful choice for driving innovation and simplifying landscapes in the financial sector.

Conclusion

In conclusion, the financial industry is in need of modernizing their core banking systems to stay competitive in the face of rising disruptors and new business models. A composable ecosystem, utilizing a developer data platform like MongoDB, offers greater flexibility and adaptability than traditional legacy systems.

If you’d like to learn more about how MongoDB can optimize your core banking functionalities, take a look at our white paper: Componentized Core Banking: The next generation of composable banking processes built upon MongoDB.

← Previous

5 Ways to Learn MongoDB

MongoDB offers a variety of ways for users to gain product knowledge, get certified, and advance their careers. In this guide, we'll provide an overview of the top five ways to get MongoDB training, resources, and certifications. #1: MongoDB University The best place to go to get MongoDB-certified and improve your technical skills is MongoDB University . At our last MongoDB.local London event, we announced the launch of a brand new, enhanced university experience, with new courses and features, and a seamless path to MongoDB certification to help you take your skills and career to the next level. MongoDB University offers courses, learning paths, and certifications in a variety of content types and programming languages. Some of the key features that MongoDB University offers are: Hands-on labs and quizzes Bite-sized video lectures Badges for certifications earned Study guides and materials Getting certified from MongoDB University is a great way to start your developer journey. Our education offerings also include benefits for students and educators . #2: MongoDB Developer Center For continued self-paced learning, the MongoDB Developer Center is the place to go. The Developer Center houses the latest MongoDB tutorials, videos, community forums , and code examples in your preferred languages and tools. The MongoDB Developer Center is a global community of more than seven million developers. Within the Developer Center, you can code in different languages, get access to integrate technologies you already use, and start building with MongoDB products, including: MongoDB, the original NoSQL database MongoDB Atlas , the cloud document database as a service and the easiest way to deploy, operate, and scale MongoDB MongoDB Atlas App Services , the easy way to get new apps into the hands of your users faster #3: Instructor-led training As an IT leader, you can help your team succeed with MongoDB instructor-led training taught live by expert teachers and consultants. With MongoDB’s instructor-led training offering, you can access courses aimed at various roles. Our Developer and Operations learning paths cover fundamental skills needed to build and manage critical MongoDB deployments. Beyond that, our specialty courses help learners master their skills and explore advanced MongoDB features and products. You can also modify how you want to learn. MongoDB offers public remote courses, which are perfect for individuals or teams who want to send a few learners at a time. If your goal is to upskill your entire team with MongoDB, our courses can be delivered privately, both onsite or remotely. Instructor-led training also provides the opportunity for Q&A, providing answers to your specific questions. #4: Resources Beyond formal training programs, MongoDB is committed to providing thought leadership resources for those looking to dive deeper and learn more about MongoDB and database technologies in general. Our website offers an active blog with ongoing thought leadership and how-to articles, along with additional coding documentation , guides, and drivers. You can also check out the MongoDB Podcast for information about new and emerging technology, MongoDB products, and best practices. #5: Events You can also engage with MongoDB experts at our many events, including MongoDB World, our annual conference for developers and other IT leaders. After MongoDB World, we take our show on the road with MongoDB .local events across the globe. These events give you the opportunity to learn in a hands-on fashion and meet other MongoDB users. MongoDB also hosts MongoDB days in various global regions, focusing on developer workshops and leveling up skills. Beyond that, you can keep up with our webinars and other learning opportunities through our Events page. Build your own MongoDB story Of course, many people like to learn by doing. To get started using MongoDB Atlas in minutes, register for free .

January 20, 2023
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024