Open Banking is more than API

20. June 2018 BY Acrea

With the recent implementation of the Revised Payment Service Directive (PSD2) in the EU, the concept of open banking has attracted widespread attention from vested interests and consumers in the European financial industry. Thanks to the capabilities of open APIs in conjunction with the PSD2, third parties including fintech startups are now building their services around core banking functionalities and offering them to clients.

Open banking marks a significant step towards a long-awaited unbundling of banking services, i.e. an approach where companies can provide individual and specialized services and where there is no longer a need to procure all financial services from a single institution.

With this approach, open banking represents a catalyst for the creation of an open and decentralized ecosystem, and a fertile ground for competition and innovation to thrive.

How banks should handle the challenges of open banking

How should traditional financial institutions navigate the challenges of open banking? Let’s look at three insights for banks interested in thriving in this new environment:

Banks will have to open up to stay relevant.
PSD2 of course is a major driver in the EU for banks to open up at the very minimum a small slice of their functionality (i.e. payment). It forces every financial institution in Europe to deploy their respective solutions and provide an API that fulfills PSD2 requirements. Some smaller banks like the German Fidor Bank are already demonstrating quick adaptability as first movers in the industry, and offering APIs for various functionalities, such as those not restricted to payments (https://api-docs.fidor.de/).

Customers will start interacting with banks in a mesh app style.
With an increasingly diversified ecosystem of banking services, customers will ultimately be able to pick and choose from a basket of different service providers and build a package of services that best fits their individual needs. In this ecosystem, APIs are becoming a fundamental enabler, the community aspect is growing in significance and value, and coopetition will need to be accepted as the norm. Because clients will be taking advantage of unbundled services from a range of providers, they will interact with financial institutions in a mesh app style over different channels.

Data is the new gold.
To gain valuable insight from analytics and maintain the highest quality of service through automated interaction, a lot of data is needed -- a lot. So, collecting more data is absolutely key for financial services companies, as is the case in all industries. As a consequence, banking services will have to become platforms or be part of a bigger existing platform. APIs can help financial institutions to become part of a bigger platform. In addition, every API that is used by a third party can also be enacted to collect data and gain valuable insights to increase the quality of the automation value chain.

Of course, banks must cope with this new situation where API users like fintech startups drive innovation and potentially eat into their provider’s cake.

Different coping strategies exist for this:

Integration: Become a platform hub and the centre of an ecosystem --> e.g. BBVA with their API_Market, an open API platform that lets fintechs access BBVAs financial solutions (https://www.bbvaapimarket.com/)

Foundation: Position as a core banking backbone and betting on economies of scale

All three coping strategies have one thing in common: they are largely dependent on APIs. These APIs provided by banks have to be designed for fluid machine-to-machine communication and compatibility, and must be well defined to ease adoption and ensure a painless lifecycle for API consumers. Since an API hides the underlying implementation, it can avoid potentially significant complexities and at the same time protect its consumer from being subject to changes made beneath the facade of the API. As a result, such changes would only impact the API consumer if it addresses the actual business functionality.

API consumers can be implemented by various parties. This means innovation can happen at a speed chosen by the consumers and not by the providers.

How to Design an API

Everybody - including fintech startups, financial analysts and forward-thinking banks - is talking about the massive potential of APIs in banking, and the PSD2 even mandates banks to provide APIs. But how do you model such an API?

PSD2 primarily requires banks to provide open access -- but does not clearly elaborate on the “how”. While there are several rudimentary details on the design, these approaches are limited and far from universal. This means a blueprint for banking APIs is sorely lacking, and implies that every institution might design a brand-new API based on their specific thinking and needs. And maybe, over time, some industry best practices become widely accepted and ultimately lead to a defacto standard albeit only lightly regulated.

Rapid adaptationOne approach might be to start publishing API versions at a regular and rapid pace, to allow for swift adaptation to consumer needs, trends, and insights as the need arises. Typically, this agile process methodology supports a high-paced publication approach. You would keep a lean philosophy in front of mind and start with a very basic version based on some clearly defined use cases. You would think outside-in, i.e., what would consumers expect in terms of functionality and terminology, rather than inside-out, i.e., what your service might offer customers in terms of the same. You would also think about the use-case flows consumers will most likely want to implement, and take these insights to determine how to best support those use cases -- this is where data analytics come in. Also, think about general patterns such as customer consent handling (i.e. customer giving consent that third party may access its data) or API structuring/layering.

Versioned APIPursuing an agile approach means continually monitoring and learning from feedback, then improving your service in increments, and not being afraid to change the APIs if justified or needed from a usage perspective. To assure success with such an approach would be to have a versioned API, since continued and regular API evolution may not always be seamless and could lead to compatibility issues with some users. A versioned API setup will help deal with any potential issues and allow users to adapt over time without inconvenient service interruptions.

Core functionality requires a core resource of skillsDeveloping a good API is challenging and requires significant skills and experience in an array of disciplines:

Banking knowledge

Good architecture and security skills

Experience designing tech APIs

In order to lay the foundation for the best result possible, all three disciplines must be combined in a single individual. This is where the API journey starts. And it’s all about having the right team on board.

Sign-up for our newsletter:

LEGAL INFORMATION

Purpose of this website is to provide information about Acrea and its services and products. The web site does not represent an offer in the strict legal sense.

COPYRIGHT

The contents of this website, specifically the texts and all images and graphic elements (illustrations etc.) are protected by copyright and owned by Acrea or third parties. Any form of use of this content is only permitted if written agreement by Acrea or the third party copyright owners is sought and obtained. Reproduction, broadcasting, modification, linking and using the Acrea website for public or commercial purposes is only permitted with written consent by Acrea.

DISCLAIMER

We accept no liability whatsoever for any direct or indirect damage or consequential damage caused due to the use of software, information or material on our website or by accessing links to other websites.

PRIVACY

When you use Acrea, the service can store cookies on your computer. Cookies are little pieces of information that can help identify your browser and that can store information, e.g. application settings. Acrea uses cookies to track usage and to improve the overall user experience.
Acrea also uses Google Analytics to compile usage statistics. This service is provided by Google, Inc. Its privacy policy can be found at www.google.com/privacy