In this video, Eyal Sivan, the head of the strategic platforms with CIBC() talks about building the optimal architecture for open banking. At 1:20, he begins by stating that all the banks have evolved into technology companies.
This evolution has been prominently happening in payments, mortgages, and retail. At 2:27 he emphasizes the fact that APIs are the pipelines that power open banking. Partner APIs are when there is a one-to-one agreement with other companies to get their APIs hooked. He adds that Open APIs are those APIs that are posted on some publicly accessible side that can be used by other people.
At 3:32, Mr.Eyal explains that open banking is when the open APIs can be used by the third-party developers to build different applications and services around the service. Open banking has gained momentum in the last few years in most countries. The evolution of open banking has been very steady and successful. At 7:17, the speaker states that a complete open banking solution must have both API management and Continuous Improvement and Continuous Delivery (CICD). At 10:04, he mentions that a centralized API gateway makes it impossible to maintain as it’s a single point of failure and doesn’t scale. This is where distributed API gateway comes into the picture. He adds that API are contracts that define the incoming and outgoing data while microservices are the implementation.
The effectiveness of service mesh architecture model for open banking
At 14:55, the speaker talks about the evolution of microservices architecture. It all started with a monolithic architecture, followed by microservices and service mesh. The latest microservice architecture is serverless. The major tech companies in today’s world follow the serverless architecture model. At 18:06 he states that service mesh architecture is best suitable for open-banking. The major reason for choosing service-mesh architecture for open banking is that one can get the micro-services isolation and there is no need to embed a library to each of the micro-services. The ‘sidecars’ get automatically injected and deployed when the micro-services get deployed to Kubernetes.
At 18:55, Mr. Eyal briefs that the sidecars are managed using a ‘Control Plane’. The service mesh can be described as a centralized interface for managing the operations going on the proxies and deploying the policies in an asynchronous fashion.
By this, it is ensured that we don’t miss the incoming traffic by not adding any extra load. At 19:11, the presenter describes the ‘Perimeter API Gateway’ as an ingress/egress end-point between a trusted and an untrusted network. At 20:12, he states that the east-west traffic should never be treated the same way as that of the north-south traffic. The service-mesh architecture model effectively provides the control to manage all traffic in a completely microservices native way and in a completely user-friendly way.
Bank of the Future
At 21:08, the presenter begins to talk about how the service mesh architecture can lead to the bank of the future. The API regulation, open banking regulation typically addressed only the API strategy and platform. The four pillars that will lead to the bank of the future include APIs, agile development, DevOps, and cloud management. The most important aspect to remember is all the four processes must be done all at once as they are interdependent. At 23:12, Mr.Eyal talks about the technology perspective that will lead to a very optimal bank of the future.
He stresses the point that one should always begin by coding a small amount of functionality before adding more complicated functionalities. This will ensure that the design aspect of banking is not compromised. At 24:42, he states that innovation is all about addressing the real issues that the customer faces with regard to banking and delivering useful features that would satisfy the needs of the customers. Innovations are highly appreciable by the customers only when those innovations have reduced their workload and provide benefits.
At 28:15, Mr.Eyal answers a question related to the need of building architectures for banking. He clearly mentions that there is no need to have an API gateway to power a developer portal. He adds that there are a good number of developer portal solutions that refer to service mesh control planes. Developer portals are responsible for managing APIs. There is no requirement for a developer portal to plug into a run-time environment unless there is a need for sandboxing. At 29:57 he concludes that in real-time scenarios, there is no guaranteed portion of embedding a fancy microservice module inside a legacy application.
In those cases, we can create a proxy that would act as an adapter. This video covers the concepts of open APIs, open banking, the differences between a centralized and a distributed API gateway, and the different micro-services architecture model. In addition, Mr.Eyal also discussed how the banks could function easily and effectively without much work required from the developer.