MongoDB for Financial Services

Traditional relational databases have been a mainstay of financial services companies and their IT infrastructure for decades.

From generating bank statements to storing customer info, banks have traditionally relied on — and been limited by — a reliance on the relational database, SQL server, and other major RDBMS.But the digital economy demands more from a bank and its database system.

Today, a bank database has to be of a distributed nature with the ability to store data locally and in the cloud, handle a huge amount of varied sales information, customer information, debit transactions, multiple processors and more.

That’s why banks turn to NoSQL databases, like MongoDB.

The technology underlying the relational databases in use at many traditional banks was first developed in the 1970s.

Conceived long before the cloud computing era, they were never intended to support the volume, variety, or velocity of data hitting them today. They have not evolved to address the needs of always-on, globally-distributed deployments, and they also are not sufficiently agile to keep pace with modern digital product development and release cycles.

As a result, established banks have struggled to offer the frictionless and personalized digital experiences of fintech startups.

The business implications are sobering. In a survey of banking executives in the loan origination business, conducted by Fintech Futures and MongoDB, 43% of respondents said a poor digital experience was their primary challenge in acquiring and retaining customers, while 34% cited a lack of personalized offerings.

Traditionally, multiple database systems (typically SQL databases like SQL server and other major RDBMS systems) and legacy architectures have created silos that make it impossible to derive true value from data.

A single view of your banking data— especially a customer's account data — across the enterprise, can provide a firmwide view of asset and counterparty exposure or a single view of your customer for fraud detection and Know Your Customer (KYC) requirements.

Database Management Systems (DBMSs) do the critical work of defining how data is structured, accessed, altered, and protected.

A Database Management System (DBMS) is a software program that provides Application Programming Interfaces (APIs) to an underlying physical data store (stored on disk, or even in RAM) for use by client applications.

Any application (with rare exceptions) that stores, access, and manipulates data stored on disk, uses a DBMS to manage that access, rather than directly interacting with the underlying data files.

The DBMS has three core components:

1. Data storage engine
2. Query / Update engine
3. Schema management system

We use database management systems to create centralized, shared, and consistent interfaces to programmatically access data. Database management systems help provide a logical structure to the data with which we’re working, along with efficient storage and distributed access. Using a DBMS is faster, more secure, more powerful, and easier than directly managing data yourself.

In recent years, IT vendors have been trying to develop and offer solutions to address the flood of data that companies face from both inside and outside the business.

Cloud is the new norm, and cloud-native data warehouses are now massively parallel-processed. Data pipelines can handle terabytes of data. Storage has become cheap and fast. AI/ML applications have proliferated everywhere. And data-processing frameworks, like Spark, can handle large volumes of data.

To work with these changes, banks need a cohesive, integrated suite of offerings capable of managing modern data requirements for building applications across even the most sprawling digital estates, without sacrificing speed, security, or the ability to scale. Integration also ensures that operations and security don’t become their own resource-draining Frankenstein projects.

A developer data platform is an integrated set of database and data services that solves these issues. By removing much of the overhead of managing a data infrastructure, a developer data platform can serve as a mission critical database and also help boost developer productivity and innovation.

In theory, there is no limit on the different types of management systems that it is possible to create, but there are a few popular DBMSs worth mentioning.

• Relational (RDBMS)

  • Database management systems that structure data in table form, with predefined relationships between tables, and a Structured Query Language (SQL) for reading and writing data.

• Document (DoDBMS)

  • Database management systems that structure data in JSON-like documents, with a document-oriented query language like MongoDB Query Language (MQL) for reading and writing portions or all of documents.

• Columnar (CDBMS)

  • Database management systems that organize data by column, for certain high-performance and disk-heavy use cases.

In addition to DBMSs that are specialized by schema and query type, there are also database management systems specialized in different storage types, like In-Memory Database Management Systems (IMDBMSs).

There are also cloud database management systems where a SaaS provider is responsible for managing the regular database maintenance tasks (such as updates, etc). MongoDB Atlas (based on MongoDB’s NoSQL database) is an example of this.

A distributed database management system allows programmers and end-users to see a collection of physically separate databases and data as one system image.

Distributing your data across multiple databases gives more manageable scaling and can help with redundancy (depending on how you distribute your data).

MongoDB is the leader in a new generation of mission critical databases that are designed for scalability. With a technique called “sharding,” you are able to easily distribute data and grow your deployment over inexpensive hardware or in the cloud. One of the benefits of scaling with MongoDB is that sharding is automatic and built into the database. This relieves developers of having to build in sharding logic into the application code to scale out the system.