Future of Fintech-The Enterprise Architecture

Executive Summary

Looking at the way Fintech has evolved over the past decade, it is appropriate to say that change is the only constant when it comes to the quest for survival in today’s competitive Fintech world. New technologies are introduced in the market often which leads to change in the industry landscape at a faster pace than we could imagine.

Fintech brings some of the innate challenges that are compelling companies to adopt innovative approaches, to avoid sudden breakdowns. Few of these challenges are:

Fintech industry adopted technology in early stages and therefore, has the most outdated systems. These systems are inflexible and prevent changes in the architecture.

Investors and stakeholders apply pressure on Fintech companies for a quick ‘go-to market’ strategy. This leads to unstable foundationto the companies that makes it harder for companies to adapt to enhancements.

There is a constant exchange of large data which is at high risk and needs highly secure systems to protect it.

Considering the challenges, it is essential to develop a strategy which diversifies the risk of never ending changes in the Fintech Industry. A flexible, independent and secure architecture that can adapt seamlessly is of paramount importance.

This whitepaper explains some of the important practices such as Microservices, DevOps and stringent security policies which can help make a Fintech system robust. It also, helps us understand the importance of a system especially in the Fintech industry which constantly changes its operating standards, whether it is due to the increase in competition, customer demands or regulations. Systems built on monolithic architecture as opposed to Microservices, break down if one of its components gets affected. Similarly, if a system is not agile it will not stand the test of time and will break eventually.

Introduction

In order to build a system that can stand the test of time, we need to be aware of the most common problems as well as the solutions.

Technology change and a demanding market often pose challenging situations for Fintech application developers. Whenever we implement a new solution or modernize an existing legacy system, we should ask the following questions:

Is the solution scalable enough? Is the system that is being built monolithic? If yes, then reconsider.

Is the system architecture agile? Will it be able to adapt to the ever changing technology landscape of the Fintech Industry?

Is the system secure enough to handle malicious hackers?

This whitepaper addresses these concerns. These approaches, if adopted early while building the Fintech architecture, can prevent the system from crashing when a new enhancement is introduced.

Best Practices to Build a Robust Fintech Application

This section explains some of the best practices to consider while building a Fintech application.

Microservices

Microservices is composed of multiple modules that represent end-to-end functionality of a particular feature. It segregates the application into small fragments and then ties them together. Each fragment remains independent and any change in one does not affect the others. Let’s see why this approach is instrumental in answering our first question with a real-life scenario.

Is the solution scalable enough? Is the system being built monolithic? If yes, then reconsider.

Problem Statement

An efficient system of a banking giant all of a sudden crashes following a feature enhancement.

WHY did this happen? WHAT caused it? And HOW can it be resolved?

As already stated, Fintech companies are under a lot of pressure to deliver applications quickly. To achieve this, developers often adopt a monolithic architecture. A monolithic application is built as a single unit, thus creating dependencies.

The main problem with such an architecture is that it’s easier to build and faster to implement. However, it creates tight dependencies during feature enhancements. Implementing enhanced features in an application which is built on a monolithic platform is time consuming. It degrades the code quality, therefore introducing bugs and often breaks the application. This is what happened in the scenario mentioned above.

A solution to this is building each feature as a separate unit as stated, while making it as independent as possible. This can be achieved using Microservices.

Benefits of Microservices

Unified Team

Team members do not have to work on a huge code base. Instead, each member can work on his/her own component services which are easier to develop, manage and test. Thus, increasing the team morale and the productivity.

Maintenance

Small projects are easier to maintain. It’s easier to enhance, test and deploy.

Availability

Instead of deploying one huge application on a single server, Microservices allows deploying smaller components across multiple machines. Thus, increasing the availability.

Agility

It’s easier to add/modify things in smaller projects without having to worry about the impact it causes on all other modules in the application. As long as the APIs are not changing, the developers can easily implement new features without impacting other interfacing systems.

Reusability

Various modules can reuse the functionality by invoking the Microservices. Rather than implementing the same functionality in each and every module. Moreover, if the application needs to be integrated with other modes like mobile, web, tablet, etc. the services can be reused across the devices.

Scalability

Microservices enable to scale the components on a need basis. For example, out of ten services, if only one service has high load, then that service alone can be scaled by deploying to multiple servers thereby, increasing performance. Whereas, in case of monolithic services, the entire application will have to be deployed on multiple machines which results in unnecessary cost.

Testability

Microservices increase the testability of the application. As each service is selfcontained, the system can be developed and tested independently. Whenever any change needs to be deployed, only the affected service will have to be modified, tested and deployed. Other services will remain unaffected.

To conclude, monolithic architecture is easier and faster than Microservices for the initial application development because it’s a straight forward/basic/simple one. However, in case of new requirements/application enhancements, which is inevitable, Microservices reduce a substantial amount of time and workload as you could redeploy that particular service. Without making alterations to the entire application.

DevOps

DevOps essentially, has two parts to it. The first is automation, which can be introduced. For instance, when the developer checks in the line of code while pushing it live in a production environment. The second is collaboration, where we move away from the heavyweight bureaucratic processes, such as filling tickets that go to silo teams to systems where people are working together in a hydrous environment, collaborating and pulling everyone in the same direction. Let’s consider the next problem statement in order to understand this better.

Is the system architecture agile? Will it be able to adapt to the ever changing technology landscape of the Fintech industry?

Financial industry used to and at many places, still operate in siloes. If you consider development and operations, they typically work in a very different way, use different tools, use different languages, have different reporting lines and budgets etc.

Problem Statement

Post financial crisis of 2008, the financial companies had to operate in a rather lean structure and cut down the operational costs in terms of manpower, while still maintaining the efficiency and security.

How did they achieve the same amount of productivity with lesser headcount? What approach did they adopt?

The organizations unknowingly started adopting DevOps practices in order to deal with the manpower crisis. All that they were actually doing was getting remaining people to align and collaborate more effectively. By speaking the same language and using aligned processes and tools to improve the speed, agility and efficiency. This is how they moved towards more collaborative and automated model back in 2008. This also, is the idea behind DevOps.

Benefits of DevOps

More efficient pipeline – From developer’s desktop to production.

Cost savings – It lowers cost as the same kind of code is delivered by fewer overheads.

Faster delivery of value (Innovation) – Reduces cycle time from idea stage to production implementation phase.

Security

Fintech companies work with a lot of sensitive data and that too in large quantities. Undoubtedly, the more the data the better the insights but if misused, this can crash the system. Fintech security thus, holds a very important place and can never be ignored while building a new system or introducing enhancements. Thus, the most crucial questions that one should ask when it comes to application security is:

Is the system secure enough to handle malicious hackers?

Before assessing the system, let’s have a look at the probable reasons due to which the data security concerns are growing.

Organizations today try to give an integrated omni-channel experience to the users with the help of a number of banking, wealth management and payment services. Thus, increasing the data vulnerability.

Increase in the use of mobile phones as authentication devices through the use of biometrics, onetime passwords (OTPs) and codegenerating apps (e.g. Google Authenticator) has reduced the reliance on conventional authentication mechanisms such as passwords and PINs. Due to technological innovations, this highly confidential data is in the digital form and rotating in the system. It is possible to misuse the data. To avoid such a situation, we can make use of adaptive authentication or risk-based authentication, which analyses user behavior in making decisions on granting access.

Therefore, it is essential to keep in mind the security concerns even before starting the development of a Fintech application.

In order to achieve this, the developers have to be made aware of the seriousness pertaining to the security. The information at stake can cause major issues, if not dealt with strict security regulations.

There are two types of customer data that has to be dealt with :

Data that is currently part of the system and interacting with it.

Data that was once a part of the system as few customers are likely to have de-subscribed in order to overcome any potential threat.

The system architecture should be built keeping in mind the nuances of a secure system. Some of the practices that need to be followed are:

Data should always be encrypted, when it is housed, accessed, and transferred.

For a device that gets stolen/ lost/ discarded, device inventory controls should be made active along with encryption in place.

3. Always align with the security compliance regulations.

4. Safeguard the security of a Fintech application, post development phase.

The following parameters ensure that the application remains secured.

Penetration testing –This involves a tester that will act like a hacker and attempt to gain access to your service/data.

Outside vendors – We should have control access permission in place for the outside vendors who are a part of our organization. The app should be developed to limit their access to your most sensitive data.

Scaling issues – As the system grows in size, its integration with various other systems also, increases and that leads to vulnerability. The interfaces of various systems through which they interact should be properly protected to avoid any breach of data.

Apart from the architectural changes, there are cyber security concepts that should be considered such as data labelling, selective data sharing and identity-aware data sharing.

Data labelling – As the name suggests, this technique labels the data into classified, confidential etc. This helps the user to know what data they are handling and processing and follow necessary security measures.

Selective data sharing – This allows us to share the data at a particular platform that can be accessed by a certain group of people and not everyone. Data can either be stored at the enterprise, organization, or site levels etc.

Identity-aware data sharing – Sometimes, just sharing the data at enterprise level doesn’t solve the purpose. Depending upon the vulnerability of the data some more checks should be initiated. One such example is identity-aware that only allows access to a certain personnel even when they belong to a larger acceptable group.

Conclusion

The Fintech revolution has left the traditional financial industry with a lot of aspects to contemplate on. How does one stay ahead in the digital age and avoid being history? The answer to it might lie in the fact that organizations need to possess a proper technology infrastructure in this digital disruption era. It is absolutely essential that the Fintech solutions integrate with the existing systems in the financial industry. There is a dire need of structuring a new generation of financial services with agile development strategies. Companies are building an open architecture world after an in-depth understanding of financial services processes. The future of Fintech has a composable infrastructure. Established institutions are re-assessing both the customer experience and their operating model.