Modernizing Banking Technology Architecture with MongoDB and Gravity9

The banking industry has historically relied on legacy, on-premises systems to store critical financial data in a secure and resilient technology fabric. Today, as transactions happen in real-time and customer demands soar, legacy systems fail to support accelerated modernization and restrict innovation. This change has driven banking enterprises to consider transitioning to newer technologies that can plug better capabilities into business-critical systems while preparing them for tomorrow's challenges.

By leveraging MongoDB, Gravity9 enables customers to migrate from legacy systems to more sophisticated technologies in a planned and piecemeal technique. In its effort to modernize technologies that are slowly turning obsolete, Gravity9 recognizes and retains the prominence of legacy systems while migrating with minimal disruption to the status quo.

This article describes how Gravity9 performed a data offload from a core retail banking platform to MongoDB using a digital decoupling approach, as shown in Figure 1.

The challenge

Gravity9's client encountered many performance issues with their core banking platform, Temenos 24, backed by Oracle. Their attempt to offload frequently accessed data from the primary system to the Oracle database failed to give the edge of performance and scalability. The platform was being leveraged for analytical and transactional operations and could not cater to both areas as envisioned. In some instances, this approach resulted in customer transaction rejections.

Additionally, the client faced the following challenges:

• The offload platform proved difficult to manage and extend with most of the logic for business processes written in the stored procedures.

• The data model within the core banking system was not inherently relational, which amplified the complexity of the platform due to the presence of only two columns: RECID for the ID or Unique Key of the record, and XMLRECORD to store the data.

The complexities of the old data source compelled the client to adopt a migration strategy and gradually move into MongoDB, which offered better scalability and a flexible document data model while also migrating the corresponding business logic code. The client expected an improvement in overall performance, maintainability, extensibility, and the potential to deliver better customer experiences.

The approach

Gravity9 leveraged a digital decoupling approach to create message-driven microservices on top of the client's data. The approach was oriented to a continuous migration process executed in parts rather than in one fell swoop. Using this methodology, Gravity9 could help the client move from the old offload system to MongoDB by building fully scalable microservices for each business domain. The biggest advantage to this approach was that the client's legacy systems could continue as usual behind the scenes.

Using a CDC pattern on the underlying Oracle database, the data from the core banking system was gathered, and snapshots modified in the core legacy system were published in real time. An event was generated every time a modification was made in the legacy/core system to keep track of changed data.

Gravity9 built an application to learn about the new changes, transform the raw XML format into a structured message and refine it as necessary while broadcasting it as a message to other customers, who could process it or store it on the new MongoDB datastore. Specific dictionaries were developed for this purpose with clear directions about field markers and object structure for the transformed objects.

The outcome

Although the execution was intended to offload only a part of the data stored on the client's old system, the approach used helped build capabilities to support future migrations of larger volumes.

The use of MongoDB Atlas for the implementation delivered efficiency and security in data offloading and met the desired level of performance. Consequently, it resolved scalability issues that would otherwise have occurred with on-premises systems.

Although the migrated use cases work on MongoDB-based offload, the implementation left the remaining use cases untouched, allowing them to work on the older systems without handicapping the functioning.