Open Finance 2.0 - simply about the complex

Before PSD2, Open Banking was already in existence within the EU. For a long time TPPs operated in an environment with minimal regulation. In due time PSD2 gave Open Banking a stable regulatory framework with safeguards to protect users' interests. Alongside discussions on the evaluation of PSD2, the review and further preparation of PSD3 (it will be more of a regulatory directive), the key points are highlighted in the report from European Commission:

• One of the key positive impacts of PSD2 emphasized in the report is fraud reduction due to the introduction of SCA (with regard to remote card payments, SCA- authenticated transactions have a 70-80% lower level of fraud than those without).
• A new legislative framework has been Introduced: financial information data access (FIDA), which would outline the obligation to provide access to non-payment account data, i.e., "open finance".
• New minimum requirements for the performance of dedicated interfaces, including a non-exhaustive set of prohibited OB obstacles.
• ASPSPs will be required to offer a dashboard to their users, displaying what data they have granted access to, to which TPPs, and provide an option to revoke the access.

Meanwhile, one of the main Open Banking API standards prepared by Berlin Group was revised, and the new version is ready to be released in July. Therefore, many questions and misunderstandings arise about the new version of the Berlin Group specification for the implementation and development of Open Finance version 2.x. This is primarily since the majority of market participants have already implemented their solutions in accordance with the current version 1.3.x.

While experienced market participants are concerned about the implications of the new version and the changes it may introduce, the question becomes whether it is worth adopting these modifications.

Conversely, new market players face a broader dilemma: should they start implementing immediately with version 2.x, or would it be more prudent to proceed with the latest version 1.3.x?

So what new challenges are waiting for us? Let's find out.

What will be changed?

The authors of the new version of the specification emphasize notable changes in the document structure. In terms of positive enhancements, the documentation has become more readable and transparent. Unlike the previous version, which consists of a single comprehensive document that defines the main services, additional services, and data model structures, the new version separates the content into different documents. Each document provides detailed descriptions of its specific section. Notably, the highlighted ones are Guide to OpenFinance API Framework, Compliance XS2A, Premium Services, Consent API, API Management Functions, Data Dictionary, Security and Protocol Measures, etc.

What's new?

Regarding compliance services (PIS, AIS, PIIS), they have undergone minimal changes, with only a few modifications to specific models, field renaming, and the introduction of new parameters. On the other hand, the Consent flow has undergone a significant transformation by being separated into a distinct API. This has resulted in slight modifications to the data structure, as well as the introduction of new data types, parameters, and variables. Version 2 gives more flexibility with Consent modeling. Additionally, the new version also includes comprehensive descriptions of service implementations for corporate clients. It was built for the future with consent modeling, with data modeling. All the other premium services are based on version 2.x.

What other challenges are waiting for us?

While v.1.x. of the specification was developed with pressure cooking, the development of v.2.x was approached in a more balanced manner. The documents were developed and improved to align with market requirements, taking into account the feedback and comments from market participants without haste and with a strong emphasis on achieving maximum improvements. The Open Finance API is not necessarily requiring the API Client to be a TPP regulated by PSD2, so it can be one of your corporate customers with unsatisfied needs to retrieve and aggregate the financial data.

How to minimize the influence of upcoming changes on your ecosystem?

Migration to a new standard is a cost & time-consuming process that requires the involvement of the development team, add-on communications, and interactions with your ecosystem. At the same time, it brings new opportunities for business expansion, and it is especially beneficial for new Open Finance industry-specific use cases. Having a working sandbox in place is crucial for your efficiency as an API exposer, as it allows you to test new features and API flows on the go. Establishing a well-organized testing environment (ideally, dynamic) that reproduces your production changes will help your team to succeed during the migration process and speed up (accelerate) your partners' efforts. Developer Portal is an important working tool and communication channel with your new “technical customer segment” - API client (previously known as TPP). It gives clear API guidance, promotes new API products, and provides direct & fastest feedback from Fintechs (API consumers) on any changes you deliver within the new API. Moreover, together with the Sandbox, Developer Portal can become a network tool and collaboration environment during the innovation process.

In GD Next, we offer a complete PSD2-compliant product suite for Open Banking and Open Finance APIs implementation on the bank side, including the developer portal as a part of the dynamic sandbox environment. Our company understands the importance of your API consumers' needs to test in real-time, so we are ready to go the extra mile to ease your API-client user experience help you to be efficient with any complex changes implementation, and, finally, benefit from Open Finance.