Gartner defines Open Banking as the provision of services in the context of users through API platforms; app stores and apps. In simpler words, it means utilisation of open source technology which can allow third party developers to build applications and services so as to enable end customers with more control over their finances.

Open Banking bears potential of taking customer experience to a higher level, while allowing banks to connect with emerging services like wearable and IoT. Even today, a subset of banking activities are being performed on various social media channels including Facebook, Twitter and now Gmail. Similarly, there are various Fintechs which offer various innovation possibilities for banks and banking. Open Banking involves a collaborative approach wherein banks expose banking data and services in form of APIs, which can be consumed by fintechs towards building a superior digital experience for the customers.

But why should banking facilities be opened?

Other than loan interest, the main components of bank's income include product fees and product cross-selling. The latter two automatically come to banks due to customer inertia i.e. customers do not switch to another bank because of lengthy onboarding process and KYC checks. However, with changing technology and simpler onboarding processes, the customers can now open new accounts quickly, and are in constant search for better banking features and services.

The customers now want power to choose relevant products so as to remain in control of financial decisions. Such rising expectations cannot be met by bank's IT team alone. Besides, many customer experience solutions and features have already been developed by fintechs who have recognised that there is a lot that can be offered even without a banking license. It thus makes more business sense for banks to enter into partnership mode with such fintechs rather than incurring high IT costs to develop indigenous offerings. Moreover, this will open a new revenue stream for banks wherein they can charge fintechs based on API utilisation.

Open Banking helps in creation of plug-and-play banking components, instead of tightly coupled services. This allows banks to become assemblers of financial management solutions, which can be hyper-personalised to suit each customer's preferences. Such innovative experiences can lead to a growing customer base at a reduced cost. Furthermore, right product delivery to right customer segment can improve bank's risk management scores as well.

While banks still contemplate upon the idea of Open Banking, regulators are apparently more comfortable in embracing the concept. With OBWG, the UK has created nationwide API standardisation. Furthermore, EU's PSDII directive has also forced banks to build an open API platform anyway. In India, regulatory compliance for UPI has caused banks to rethink on their approach towards app based financial transactions.

Ok, but what banking facilities should be opened?

Just because banking services are available for conversion to open APIs, it does not mean going all out and converting each and every service into an API. Such an approach will exhaust time as well as money. A sound business approach is to identify the top business needs and build RESTful APIs accordingly. This would help in saving IT costs and building a customer centric approach.  Some salient banking capabilities which can be considered for conversion are outlined below:

Identity Management: Since banks already possess KYC/AML compliant record of customers (often empowered with a credit rating score), the identity validation API can be consumed towards utilisation / purchase of more products. The use-case is similar to federated identity management; an aspect which is utilised by public websites for performing customer login by using popular sites’ (like Facebook and Google) authentication credentials.

Locations Management: An API responsible for providing branches, ATMs and other important location information.

Analytical Dashboard: The API can consolidate various financial data points, which can then be dissected by developer for representation in form of dashboards like Personal Financial Management and other advisory services

Accounts Balance Management: This is already becoming a basic expectation, even by the regulators' standards. The API can be utilised towards display of balance in visually appealing and simplified formats for various product types including cards.

Counterparty Management: Creation and management of beneficiary information in an omni-channel manner so that any changes made via the API channel are also represented in other channels like internet and mobile

Payments Management: The API can be utilised for performing transactions and payments in innovative transaction types such as crowd-funding and P2P lending.

Metadata Management: This means enrichment of data associated with accounts, counterparties and transactions. For example, authorised users can be allowed to write associated information for a transaction such as geo-location, friends and additional remarks

Loyalty Management: Corresponding API can be programmed so that merchants can manage reward points

Once a bank has defined its API strategy and worked upon availability of relevant APIs for the developer community; the popular APIs can then be monetised.  This means that the developers and partners can be charged based on API usage. Alternatively, the partners and bank can enter into revenue-sharing agreements. API monetisation requires a comprehensive API management platform which can take care of various API related aspects including traffic control, scalability and reporting. Furthermore, the platform would allow control over all interactions inside (ESBs and applications) as well as outside organisation.

So, how can banking facilities be opened?

APIs can be hosted easily if bank's core Solutions and applications are built with microservices. It is because each microservice component is developed separately and the application then becomes sum of constituent components. This obviously has an edge over monolithic applications which are developed in one go. Each microservice provides an API endpoint, usually in form of REST API which can be accessed over HTTP(S). Accessing these REST APIs is quite simple. One may compare invocation of REST APIs to accessing internet URLs. Such loosely coupled components convert bank into an API marketplace which in itself acts as a banking channel.

This channel can then be made available to developer community, in a secure manner via OAuth system. OAauth is an industry standard system which allows bank to remain the gate-keeper of authentication. OAuth style authorisation ensures legitimacy of the customer connecting to the API and also allows banks with facility to shut down the connection at any point of time, if fraud is detected. This is better for security because there is no copy of passwords outside the bank and hence, no developer has access to the end customer credentials.

However, greater proportion of banks are based on monolithic SOA based applications, often with more than 1 ESB and several point-to-point connections. Most banking services are based on SOAP, but the SOAP messages are embedded with business logic. Thus, other than the information needed for invoking the required banking service, the SOAP message also contains a lot of junk which can make work difficult for a third party developer. All this makes movement from SOA to open IT environment a big challenge. At a high level, there can be 3 approaches to tackle this challenge

Exact replication from SOAP to RESTful: This means wrapping existing SOAP services and exposing them in REST format. While this would be the quickest approach, consumption of such APIs would be difficult for third party developers leading to difficulty in quick rollout of services.

Establish an API layer: An API layer brings consistency in all API interactions. Thus, if the API consumer understands 1 API, others can also be comprehended. However, this approach would also involve unwanted exposure of backend logic.

Create new REST API: As part of new REST API creation, there would be higher speed to market as well as no dependence on legacy systems.

Even though the abovementioned transformation may appear difficult, the technological transition challenge appears easier when compared to the mind-set transition challenge. In an Open Banking world, the banks would need to lose control over 'customer ownership', which means that they would not be allowed to hold customer's data close to the chest. Ironically, the real owner of data would then be the customer himself, who would be allowed to choose the set of data and information to be shared with the world (this is similar to what happens today when a newly installed mobile app asks for permissions to read texts, contacts, photos etc.). This raises risk for bank if customer's data is leaked or fraudulent transactions occur due to negligence of fintech partner.

This is where the regulators need to step in, and create an environment which is conducive for everyone by assigning accountability standards. Open Banking can only happen when regulators, banks and fintechs open up and engage in healthy discussions. This can cause positive disruptions in existing business processes and bring much needed revamp in bank's technological architecture. The new and componentised banking service model may witness fast fails, but each fail would lead to innovations which will succeed faster.