Opening Doors with API Oriented Banking
By: Pannerselvam D, AVP, Intellect Design Arena
Cloud-based services like SaaS (Software as a Service), PaaS (Platform as a Service), IaaS (Infrastructure as a Service) and NaaS (Network as a Service) have become buzzwords in the market. As per a report, the global Cloud computing market was estimated to be a whopping $219 Billion in 2020, and is likely to grow to $791 Billion by 20281. While the pandemic played a key role in enterprises moving towards the Cloud, there were other factors that helped in this shift. Some of them were lower maintenance, cost, higher adoption of technologies like AI and ML and increased funding in Cloud by developed countries.
While it makes sense for banks to shift to the Cloud to improve scalability, reduce maintenance hassles and cost, just Cloud migration might not always be the solution. As the bank grows, so do its products and the applications supporting those products. What might happen is that these applications will continue to function in silos. By default, that means that the bank does not have the full picture. It’s not just this, there is more.
How should a bank prepare itself for continuous scale? Can APIs be the answer?
As mentioned earlier, one of the major problems faced by banks is the management of various kinds of applications in its IT landscape. When there are a greater number of applications, then the interfacing of these applications becomes a cumbersome task. Let’s take an example of a leading diversified financial institution in APAC region that provides a full range of financial products and services to both institutional and individual customers. The bank had 300+ applications implemented with different technologies, all at various stages. Due to this, the bank faced several difficulties in interfacing these systems. Some of them were:
1. Maintaining multiple interface systems: Each system required its own interface functions to connect to various other downstream systems. That led to the implementation of similar kinds of interface functions in all systems.
2. Huge cost and time for any change request: As there was a change in the interface of the downstream system, all interface functions of impacted applications had to be changed. These interface changes were expensive and required longer implementation periods.
3. Difficulties in maintaining interface documents: As there were many applications, the bank struggled to maintain interface documents for all these applications.
4. Difficulties in impact analysis: The bank struggled to perform impact analysis of interface changes and there were instances of production outages due to improper impact analysis.
5. High license cost: Some applications had their interface functions deployed in specific middleware like JBOSS, which led to additional license costs to the bank, apart from application- related cost.
APIs can be the answer to these problems. An API is a set of rules that guide computers or applications to communicate with one another. APIs act as an intermediary layer between the application and web server, processing data transfer between systems2.
External API hub: This layer includes API containers for each frontend system offered by the bank, its subsidiaries and other Fintech companies. The purpose of this layer is to implement the functional requirements of the frontend system and avoid any logic in the frontend system. This can also be termed as Backend for Frontend System.
The functions of External API hub include:
Authorization: Authorizing API access of each frontend system with Red Hat Single Sign-On.
Aggregation: Invoking multiple internal APIs and aggregating results for the frontend system.
Transformation: Transformation of request and response messages as per the need of the frontend system like filter, formatting of data, message conversion, etc.
Cache: Serving parameter or static data to the frontend system.
2. Internal API Hub: This layer includes API containers for each product processor or backend systems. The purpose of this layer is to serve standard APIs through transformation. For example, in the case of an ATM, messages are converted from ISO format to JSON format for standardization purposes.
This new API Hub design helps the bank with:
Standardization of API Interfaces: API Hub ensured that all API interfaces are of JSON format and that they followed standard API Design. This helped the developers to easily understand the specification and use of the API.
Record maintenance: Specifications of all APIs were consolidated and maintained as a part of API Hub and readily available for reference by everybody.
Reduction in license cost: APIs were developed in Apache Camel framework and deployed as Microservices in RH OpenShift container platform. This helped to reduce the license cost of individual JBOSS instances required for the interface function of the application.
Impact analysis and change requests: As per the API Hub design, applications were connected to one system (API Hub) instead of being connected to multiple downstream systems. Hence impact analysis and change requests were handled smoothly.
Performance improvement: The API Hub design helped to reduce the TAT of the frontend functions, instead of invoking multiple APIs from the frontend system. Let’s take the example of fund transfer, various validations, AML checks, account limits and OTP were checked through parallel API calls and then actual fund transfer was initiated. Parallel API calls helped to reduce the processing time for each activity.
Conclusion
Future banks would not just cater to our banking and investment needs but act as a one stop shop for all needs involving money. Like the Cloud, an API too is not a universal pill for digital transformation. Banks should invest in cloud-native platforms which are comprehensive, future resilient, scalable and agile.
Sources
1. https://www.fortunebusinessinsights.com/cloud-computing-market-102697
2. https://www.ibm.com/cloud/learn/api
Share
