The banking industry had undergone a transformation due to increased demand for data sharing. Users desire easy access to their banking accounts and effortless financial data sharing. However, increasing demand created enhanced service offers which lacked regulation and customer information safeguarding. Therefore, the European Union (EU) developed relevant legislation to protect end-users from fraud and other risks lurking in the shadows. The regulations included open banking specification and instructions on how to create, access and share users' financial information.
All the data-sharing regulations are known as open banking. The aim of open banking is to standardize Access to Account (X2A) while increasing competitiveness between legacy banks and fintech. It also regulates the stipulation of consumers' financial data and payment control. The general open banking regulation is called The Second Payment Service Directive (PSD2), open banking API specification falls in the scope of PSD2. However, PSD2 allows various interpretations of its Application Programming Interface (API) which led to numerous API incentives being created. For instance, Open Banking UK, STET in France, Polish API and many more.
The idea of collaboration among those API groups was instated, yet, there were challenges ahead that interfered with the integration of unified products across the EU.
Open banking is based on financial data sharing through APIs which leads to innovative solutions to ease the use of banking services for consumers. Yet, the fast innovation and increasing number of parties that have access to that data cause a higher risk for various security breaches.
To adapt to growing demands and the need for higher security, open banking API specification was developed. The following are three main requirements to ensure open banking safety and data security:
In the ecosystem of open banking, these aforementioned requirements establish trust among all the involved parties. It ensures that information can be accessed only after the consent has been acquired and only this way a successful open banking implementation can happen.
However, after meeting these basic requirements, legacy banks should turn to open banking API specifications. API specifications are divided into five well-defined types - Read/Write API Specifications, Open Data API Specifications, Directory Specifications, Dynamic Client Registration Specifications and MI Reporting Specifications.
Read/Write API Specifications mean Representational State Transfer (REST) API that facilitates Third Party Providers (TPPs) data access and allows to initiate transfers for consumers. It functions by creating a secure and efficient connection to Account Servicing Payment Service Providers (ASPSPs) with the provided consumer consent.
Open Data API Specifications provide an opportunity to API providers such as banks or building societies to generate API endpoints that allow third-party developers to access it. It can be further used to develop applications personalised according to financial consumers needs.
Directory specifications refer to comprehensive technical guidelines on the functions of every member in the Directory. It also talks about how Open Banking Directory works and participants' roles.
Dynamic Client Registration (DCR) Specifications determine the APIs for TPPS to present Software Statement Assertions to ASPSPs to generate Open Authorization (OAuth) customers that are enrolled with ASPSPs.
Management Information (MI) Reporting Specifications are there to conduct MI Reporting of ASPSPs to open banking. The term MI specifications consist of a comprehensive Data Dictionary and instances of MI reporting templates. In order to access MI Reporting Specifications permission to access Confluence Collaboration Space is required.
Each Open banking API specification has a purpose and it should be used accordingly.
Open banking specification 3.1 since its first emergence had various updated versions. The latest open banking specification 3.1 version is 3.1.6 and incorporates additional features to aid with enhancing open banking services. This version was announced on 25 June 2020 by the Open Banking Implementation Entity (OBIE). It focused on the Current Account Switching Service (CASS). The CASS is used to shift through banking accounts by the user and has been enabled by the new version of the open banking specification.
These specifications plus novel features were conveyed as updates to the Read/Write API Specification & Customer Experience Guidelines (CEGs). The supplementary features enabled open banking users to further advance open banking. However, this update is just a minor improvement compared to the major update to version 3.1.5 in March 2020.
Yet, after the release of the open banking specification 3.1.5 further clarifications were requested by the financial industries’ participants and, therefore, version 3.1.6 came to life. This version includes explanations of all the previous versions together with added improved functionality and directions to implement new features within the financial ecosystem.
The Technical Design Authority decisions in further detail can be found under the documentation for API specification version control. CASS provided directions aimed at ASPSPs and TPPs that while acting under the CASS TPPs permissions will not change when switching between ASPSPs accounts. The updates to API specifications also included definitions of communication between ASPSPS and TPPs in reference to support data associated with the switch.
The guidelines and updates to open banking specification 3.1 is necessary to establish communication between the authorities and involved parties from the financial industry. Open banking in reality determines the interdependence of enormous amounts of legacy banks and thousands of TPPs. Consequently, numerous issues arise and legislators must respond promptly. All the issues that come from the parties that must implement open banking and its regulations should be handled and required guidelines on how to proceed provided.
On the other hand, since the legislation must remain technologically agnostic it is incapable of providing specific implementations to foretell possible issues. Due to differences among EU member states and their regulating laws API certification body should implement a unified open banking specification that could be processed across all the markets. Otherwise, the investments from legacy banks and fintech on the technology advancements and the development of new services might end up slowing down and the increased costs will leave them leveraging just a part of what open banking has to offer.
We frequently share industry news and Nordigen product updates to our closest friends, fintech innovators and industry experts. Sign up to our newsletter to hear more from us.
By providing your email, you accept