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:
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.
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:
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.
This section explains some of the best practices to consider while building a Fintech application.
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.
An efficient system of a banking giant all of a sudden crashes following a feature enhancement.
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.
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.
Small projects are easier to maintain. It’s easier to enhance, test and deploy.
Instead of deploying one huge application on a single server, Microservices allows deploying smaller components across multiple machines. Thus, increasing the availability.
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.
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.
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.
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 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.
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.
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.
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:
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 :
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:
Following are few areas that would require attention:
Following points are worth considering.
The following parameters ensure that the application remains secured.
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.
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.
https://www.fortinet.com/blog/industrytrends/ why-securing-fintech-is-necessaryfor- financial-startups-and-industry-leaders. html
https://www.enterpriseinnovation.net/article/ banks-must-architect-constant-change- 630533299?r=23