Open Finance is seen as the natural evolution to Open Banking - extending the use of open data beyond traditional payment accounts to encompass an individual’s complete financial landscape, putting control in the hands of the customer and promoting full financial inclusion. Mortgages, credit cards, insurance, consumer credit, foreign exchange, pensions and investments and even cryptocurrency - giving consumers confidence to use ‘open’ digital services and a customer base that is more prepared to shop around whilst boosting market development, fresh brands (without reputational baggage!) and innovation across the financial ecosystem.
Innovation or Legislative Compulsion?
Thinking back to the introduction of Open Banking/ PSD2 and the main driver for this innovation. It could be said that legislation was the main catalyst for this change (European legislation known as the second Payment Services Directive)- banks had to follow suit1 - innovate or be left out. Follow or be left behind.
In many ways, the regulation has forced the industry to modernise its systems, somewhat preparing them in advance for Open Finance - the digital transformation required to deliver these changes and improvements is dependant on the integration of all legacy and latest technology applications in banks, while API management enables banks to develop markets and ecosystems that allows them to meet customer requirements.
This changing financial ecosystem will mean that for many customers, their experience won’t necessarily be with a financial organisation; a creation of services becomes available- buying a vehicle > applying for finance > purchasing insurance - all at the press of a button without having to provide additional information.
Open APIs, PSD2 & The Berlin Group
Open Banking and Open Finance are systems in which banks and financial institutions open up their application programming interfaces (API) to share financial data with each other, typically through a third party provider (TPP) developed application for the purpose of developing new apps and services. They essentially allow different applications to communicate with one another- companies interconnected through open APIs form a true API ecosystem with the ultimate aim of offering excellent customer experience by combining digital services from multiple companies.
In October 2020 (update provided on 27. September 2021 providing ‘first official set of finalized openFinance Services’), The Berlin Group2 announced that they will be commencing work on a full OpenFinance API Framework, leveraging the NextGenPSD2 API Framework technology and infrastructure investments, adding standardised extensions beyond the regulatory PSD2 scope.
The purpose of this revision is due to the necessity of expanding access to customers’ financial data to larger data sources as well as other financial services and account types, providing enhanced perspectives of customers’ finances are provided, with the end goal of offering enhanced services, products and information - placing the customer in the driving seat to choose the functionality/ service and user interface that suits them best, giving consent to the party3 to use specific data present in the ecosystem - empowering them to choose customer-centric (instead of product-oriented), best value products and services and also improving their overall experience.
The announcement on the 24. September 2021, now provides the full document set for the scheme-independent Request to Pay (RTP) Services (with Operational Rules, Implementation Guidelines and Payment Data Model for V2) and the Implementation Guidelines for the Resource Status Notification Service have both been published on the openFinance downloads page (www.berlin-group.org/openfinance-downloads)
Open Finance levels the playing field, allowing all entities to participate in the ecosystem that will either make better, less risky customers and attract more lenders and deposits. Banks see an increased need to enhance their digital services as well as increasing their speed towards innovation, resulting in immense pressure to digitise not only throughout Europe, but across the globe - therefore, agility is paramount.
Combining best-of-breed API services that FinTechs and InsurTechs are able to offer and deliver allow banks and financial institutions to deliver these additional digital services in very short ‘go-to-market’ time frames which can lead to rapid growth and increased revenues. In turn, a shift takes place- financial services providers change from providing end to end ‘solutions’ and become providers of customer centric financial services. In fact, insurance companies are likely to benefit the most since they will have more access to data resulting in more informed underwriting decisions.
Key Characteristics of an OpenFinance API Framework
The Berlin Group has provided Key Characteristics of an Open API framework. In summary;
- Modern “RESTful” API set using HTTP/1.1 with TLS 1.2 (or higher) as transport protocol
- TPP identification by ETSI-defined eIDAS certificates: QWACS mandated (easy measure to protect e.g. against DDOS attacks), QSEALS optional for banks TPP follows instruction by bank (i.e, certificates do not have to be PSD2 compliant eIDAS certificates)
- Building on all NextGenPSD2 AIS, PIS and CoF use cases
- Third Party Provider access beyond PSD2
- GDPR compliant consent model beyond PSD2
- Support of Direct Access for PSUs / Corporates
- eCommerce support
- Discovery service to obtain the specific implementation details
- Multilevel SCA/Corporate Banking support
In order to comply with the Key Characteristics of an OpenFinance API Framework, the following requirements need to be met;
Qualified Electronic Seal
A Qualified Electronic Seal (eIDAS Article 3 (27) & Section 5 (38)) (QESeal) is an advanced electronic seal which provides additional level of assurance on the identity of the creator of the seal and an enhanced protection and level of assurance on the seal creation;
- Is based on a qualified certificate for electronic signatures
- A qualified signature creation device (QsealCD or QSCD) hardware security module (HSM) is required for the creation of QESeals
Qualified certificates for electronic signatures are provided by (public and private) providers which have been granted a qualified status by a national competent authority as indicated in the national 'trusted lists' of the EU Member State. Those lists can be accessed through the Trusted List Browser.
Qualified Website Authentication Certificate (QWAC)
A Qualified Website Authentication Certificate (QWAC) is a type of SSL/TLS Digital Certificate under the trust services defined in the eIDAS Regulation and is used to identify organizations that are in compliance with eIDAS guidelines for encrypting communications
Qualified Signature Creation Devices (QSealCD or QSCD)
The qualified trust service for the management of electronic signature and seal creation devices provides significant security, uniformity, legal certainty and consumer choice benefits both linked to the certification of the qualified signature creation devices and in relation to the requirements to be met by the qualified trust service providers managing such devices. A qualified signature creation device hardware security module (HSM) is required for the creation of QESeals
As development towards Open Finance standards is now taking place across the finance sector, sandbox environments are now underway. This means that first stage testing with synthetic data is likely to run to the first quarter of 2022 after which live customer data will be used in a beta testing phase until mid-year 2022. This represents an important step in bringing Open Finance standards for the sharing of savings, investment and pensions data in line with Open Banking, especially with it comes to security and transparency of data and user experience.
To provide the best security and protection of eIDAS certificates and private keys, Utimaco provides a range of HSMs for the purpose of protecting a certificate issuing infrastructure within an Open Finance environment.
Berlin Group Open Finance (General Introduction Brochure)
1In the UK, the so called ‘CMA9 banks’ were required to participate in and pay for the introduction of Open Banking in the UK, making them the first mandatory ASPSPs as their combined customer bases cover 90% of UK consumers and small business accounts
2 The Berlin Group is a pan-European payments interoperability standards and harmonization initiative, consisting of almost 40 banks and financial service institutions from across the EU, with the primary object of defining open and common scheme- and processor-independant standards in the interbanking domain between Creditor Bank (Acquirer) and Debtor Bank (Issuer), complementing the work carried out by e.g. the European Payments Council. As such, the Berlin Group has been established as a pure technical standardization body, focusing on detailed technical and organizational requirements to achieve this primary objective.
3 Ultimate success will depend on fundamental impediments such as conventional banking cooperation, consent procedures, and concerns around privacy issues.
About the author
Dawn Illing is a product development manager with over 25 years of product management experience in the banking, insurance and cyber security industries. By working internationally across EMEA, this has inspired her interest in cross-border digital identity and cyber security, including the interoperable requirements that necessitate successful delivery of digital product and market solutions.