Some concrete API use cases for the financial industry
By Anne-Sophie Morvan.
Open Finance might sound like a “buzzword” – particularly in a country in which most of the financial institutions have not yet embraced the full potential of open application programming interfaces (APIs). But, in some European countries, Open Finance is a reality. Several European financial institutions have already developed APIs around a large number of use cases, which might be an interesting source of inspiration for those wondering where to start.
Why publish APIs?
The 2nd Payment Services Directive (PSD2) obliged banks to open access to their payment account data via APIs, for free, to authorized third parties. At first sight, such an obligation appeared to be more of an additional cost than any kind of opportunity. There were, however, several financial institutions who were able to leverage this opening to innovate and create new business cases.
A number of banks decided, for instance, to offer their customers an aggregated view of their payment accounts held at different banks via their own e-banking interface. This functionality strengthens the end-client’s use of the relevant bank’s e-banking and enables, under certain conditions, the provision of additional services based on the analysis of the retrieved data.
Going beyond the sole consumption of third-party APIs, some financial institutions also decided to publish additional APIs – beyond the imposed PSD2 scope – with a variety of underlying business models. A good example of this strategy is the API program launched by Deutsche Bank back in 2015. Through this program, the German bank currently offers its partners the potential to access around 40 APIs, providing a large range of data and services.
This example evidences the relevance of Open Finance for financial institutions that are willing to promote their products, create new revenue streams and establish partnerships, as well as – and very importantly, given the success of challengers – enhance the customer experience.
In this article, we will concretely address some use cases that banks and insurance companies have explored in their API adoption journey and which have undoubtedly helped to create new business opportunities.
Brand & product promotion
Banks and insurance companies usually promote their brand and their products via a restricted network of partners and through “traditional” marketing channels. APIs offer them the possibility to gain greater visibility and become more accessible to the public.
Many financial institutions, for instance, publish “accessibility APIs”, enabling their partners to display information regarding the location of their branches/brokers and their opening hours, as well as providing the ability to book an appointment online.
Going further, some institutions enable partners to access information about their products, such as loan estimates or credit card rates, in the banking sector, or policy quotes, in the insurance sector.
The combination of such “product APIs” with “accessibility APIs” enables, for instance, the establishment of remunerated partnerships. In this context, partners promote the financial institution’s products, while enabling their customers to easily connect with the relevant institution.
Complementarily with brand and product promotion, financial institutions can use APIs to distribute their products and ensure that clients benefit from the relevant services in the most efficient manner.
The contractual onboarding process can be simplified – and thus accelerated – through subscription APIs, which enable customers to provide all necessary information online via their preferred channel and to get a confirmation of their contractual subscription. Once the contract is executed, financial institutions can provide access to different services available through APIs, such as trading capabilities or guaranteed order generation, in the banking sector, and policy or claims management, in the insurance sector.
Existing products can thus be provided differently via APIs, creating new potential leads and enhancing the customer experience. But new products can also emerge in the context of an API journey, in particular where the financial institution decides to leverage “its” data.
Financial institutions collect and process a large amount of data in the context of contractual performance and due to their legal obligations. Given the strict duties imposed to these financial institutions, the accuracy of these data is essential and high standards are implemented to ensure reliability in this area. These data are typically used solely for internal purposes and not shared with anyone outside the organization, unless mandatory to do so. This can nevertheless change if financial institutions decide to leverage the huge potential of these data.
The first use case that comes to mind after PSD2 is the opening up of other contract-related data, such as savings, securities or loans, in the banking sector, or policy subscription and claims’ data, in the insurance sector.
Beyond these contractual data, financial institutions can also leverage the customer’s identification data, offering third parties the possibility to perform their verification quickly (e.g. identity, age or address verification). Broadening its scope, the financial institution thus becomes a facilitator for the customer, who can fulfil different onboarding processes quickly – hence reinforcing their loyalty towards the relevant bank or insurance company.
Last, but not least, such access can of course be monetized, creating a non-negligible revenue stream if largely adopted by partners and customers.
In order to avoid any mistrust or breach of data protection legislation, financial institutions and third parties must, however, ensure that customers are appropriately informed about “the scope and consequences of the processing”. The processing of data by the financial institution, consisting of the transfer of data to the relevant third party, would in this context most likely be based on the performance of a contract to which the data subject is party (Article 6 (1) (b) of the GDPR), alike what has been clarified in the PSD2 context. Also, to ensure a high level of security, the request of the data subject to share its data with a third party could be materialized towards the financial institution via the performance of strong customer authentication, similar to what is conducted in the PSD2 context.
To avoid data protection related questions, financial institutions can also decide to monetize anonymized data, such a transaction data by city or industry, in the banking sector, or claims’ location data, in the insurance sector. Such data can be hugely valuable in market analysis, for instance.
In conclusion, there is a large diversity of possible use cases, which can be adopted by different institutions, depending on their activities and appetite to develop new products. Many European financial institutions consider Open Finance as the future and have thus already decided to leverage these use cases. Banks have taken the lead, but the insurance sector is following the same path, making out of the Open Finance “buzzword” a successful reality.