The terms, OpenBanking and PSD-2 (Payment Services Directive-2) are largely used interchangeably nowadays to summarise the very significant challenges that are being experienced by the Global financial and Banking sector today. As a response to global financial crisis of 2006, the European Banking Association, 4000+ member banks were mandated, under the regulation, PSD-2, to empower their customers to be able to selectively share their banking data with third party Fintechs, online retailers, risk-assessment agencies and other member Banks beyond their traditional geo-boundaries. Customers would be able to transact using their bank accounts with online retailers to avoid credit card charges, apply more seamlessly for short-term loans – retailers will in-turn be able to offer cheaper goods due to reduced risk from fraudulent payment, and likely will position themselves to offer Banking services to their consumers. Indeed, some energy providers are also starting to offer Banking services to their millions of subscribers but without the need for maintaining a complex Banking infrastructure.
The overall aim of this Banking initiative is to promote greater competition, and give control of this all-too important customer data back to the consumer such that they themselves, can decide how their data is utilised. Such is the impact of this seismic European initiative, that it is slowly becoming a global necessity. As one might expect with such a mind-shift on how Banking data must be sharable going forward, this is bringing many challenges. Banking institutions, are traditionally not setup to facilitate the open sharing of their customer data and facilitating connectivity to competitor Banks to enable alternative service offerings that are dynamically provided on the fly.
The aim of this article is to summarise some of the key technical challenges being experienced by the Banking sector adopting the OpenBanking paradigm and to shine an experienced light on potential strategies to consider as a way forward.
Open sharing of data
In Europe, the Central Banking Association has mandated the customer-consented sharing of their data but not prescribed the mechanism by which this should be done securely. It is commonly accepted that this is achievable by exposing secured REST APIs, of which several definitions have been development by the various Banking groups in the region.
Two of the most commonly adopted forms are the OpenBanking Group (UK) and the Berlin Group API definition, of which neither are compatible with one another. In addition, there is no common security framework adopted especially when it comes to the sharing of customer account data. Different standards like OAuth 2.0, Open ID Connect coupled with additional extensions are being adopted to address the needs but the financial institutions must be able to cater to all these standards. Core to this is the need for a flexible API management solution that is capable of delivering on the specifics of each standard, to ensure interoperability, without warranting the need for significant one-off solution customisations. Banks also need to be able to publish, via a dedicated Portal, these API specific definitions of how third parties can get access to the customer data and enforce a reliable enrolment process such that this access is controlled.
A Common Consent model
Each of the various API definitions for delivering on this global demand for OpenBanking, whether it is driven by the Federal Data Exchange, European Banking Association, etc. enforce a difference consent management model. Some models require up to 30 Bank Account data points to be managed, especially as the all-to-valuable account transaction history is to shareable. The net effect of this is that the user experience is far from satisfactory. Some implementations simply require the user to consent on the sharing of specific account balance details whereas others allow specific transaction thresholds to be set for a user defined time period. Naturally the user experience will drive the adoption of such capabilities, but there is clear lack of a common consent model, being built into the emerging standards especially when it comes to the type of the data to be shared with a trusted third party. Most institutions are adopting their own in-house approach and providing basic functionality to their customers on being able to provide account-sharing consent but at the same time revoke it on demand – by integration their deployed API Management platform into in-house CRM systems. A key consideration is that the consent management must be user accessible, transparent of understanding and sufficiently flexible to cater for the wide range of potential consuming third-party services. For example, a consumer should able to clearly understand that they are sharing account balance and transaction data to a risk-rating or loan management agency but should not have to do so to transact with an online retailer.
In Part 2, I’ll look at shareability, the need for a common authentication model, and who’s actually paying for all this.