The new world of Open Banking
There is a substantial transformation happening in European banking in 2018 and it will inevitably come sooner or later to the rest of the world. The new Payment Service Directive is being widely implemented, it actually opens the door to the precious financial services functionality to the neo-banks, fintech startups and basically any company, interested in providing financial services to it’s customers — all of the mentioned is tremendously important for the banks of European Union primarily, and also beyond — for both mature and emerging markets equally.
Briefly, PSD2 directive enables bank clients to choose the providers to manage their finances. In the closest future, we may be using Facebook or Telegram to access account information, perform bank transfers, pay our bills or sent the money to friends and relatives. At the same time, the money will safely stay within the walls of the properly equipped and licensed banking institution, that would be acting as a platform to the service companies, commonly named in this context as TPP (third-party providers).
One way PSD2 open the banks to the world is through an open API (Application Program Interface), the bank is obliged to provide to the TPP. This will enable TPP’s to build their services and apps on top of bank’s infrastructure, systems and data. By using banks’ APIs TPP’s can concentrate on their primary «front office» activities, and can enter the financial services without the heavy compliance and infrastructure which banks are required to maintain through the licensing system. Technically speaking, the connection of TPP’s is going to look like this:
Figure: Open API high-level scheme
The goal of PSD2 is to improve innovation, open the doors to the financial services world for the new creative class and new generation of fintech entrepreneurs. At the same time, European Commission is aiming to reinforce security and customer protection and facilitate internet payments and online banking control within EU and EEA.
PSD2 poses serious challenges for the banks, including financial and technical. There will be certain cost increase in IT area due to the new security requirements and the need in open API, both are multiplied by pretty much simultaneous GDPR rollout across EU.
Customer expectation, on the other side, are just growing — digitalization of the relationship, online services are becoming gradually a norm of everyday consumer banking and not only. All of the mentioned is also resulting in technical challenges, mostly deriving from the need in embedding the new systems and modules into the legacy infrastructure, getting more open while not jeopardizing security and safety of the client’s finances.
First proposal on PSD2 has been done by EC by June 2013. The plans have been changed and shifted several times since then, and the most recent picture looks like this:
As it is clearly seen from the above timeline, autumn 2018 is going to be hot in terms of project activity in order to address PSD2 compliance. Naturally, it will be more difficult to get the high quality service and solutions at the same time keeping the costs on the reasonable level.
#digitalharbour OnlineBay™ module architecture has been designed with PSD2 requirements in mind on both security and usability for the outside world. It works as a bridge between the backend systems of the bank and the «front» apps of TPP. It can use it’s internal custom authentication service, as well as the standard global authentication services of the bank.
Solution has been developed according to the Service Oriented Architecture principles, therefore it is multidimensionally scalable. All core services have been designed in the form of separate Microservices, featuring REST API to communicate with the other modules of the system and external world.
This approach enables the following benefits:
- Improved scalability, gradual deployment process
- Easier QA – services are smaller and faster to test
- Fault isolation – service failure doesn’t mean the whole system failure (may not be valid for some services like Auth for example)
- Elimination of long-term commitment to a technology stack – microservices can operate and the system expansion can be done with more advanced technologies in the future
The following scheme is showing internal solution architecture of the Online Bay, with 4 main services, that the systems operates on, each of them equipped with REST API:
Figure: OnlineBay™ internal architecture
Client Core: containing the main business logic and consolidating information and atomic-level functionality, received through the integration layer from the backend systems of the enterprise, published on the API gateway later on.
Admin Core: where all administration tasks and tolls are setup. Web user interface for Core-Service business administration like configuring operation rules (allow, deny, commission, limit, alert, authenticate), client profiles, client operations. Admin-UI API can be referred by the enterprise CRM system for the needs of call center, for example.
AUTH Server: our own 2-factor authentication service, responsible for client credentials life-cycle: registering, managing password, activating new roles, describing current roles. This service can be optionally substituted by enterprise standard Gemalto or Vasco, for example. OAUTH standard is supported.
Client API Gateway: full-featured client RESTful API, suitable to satisfy most demanding external application or system. Comprehensive API for all clients needs as authentication, profile management, obtaining contracts, making all type of financial operations, service operations, getting operations history, contracts history, etc.
OS and Databases: the system is database and OS independent, utilization of existing volume licensing contracts of the bank is supported.