Use existing banking technology for API-led strategies that attract fintechs

Written by Vidura Gamini Abhaya, Senior Director of Solutions Architecture at WSO2 

Putting regulatory compliance to one side, banks are starting to buy into the necessity for genuinely “doing open banking”. Yet strategies to capitalise on already available technology to achieve this doesn’t receive the same attention as operational and community engagement. Open banking APIs enable the secure sharing of customer data (with customer consent), and consumer products built around this will soon become the norm as seen with the popularity of open banking-based credit alternatives like Creditspring and personal finance management apps like Cleo.  

In every regulated open banking ecosystem, all banks will eventually have the same mandated APIs. Even in non-regulated countries, market forces mean that most banks will end up using open banking-style standardised APIs.  However, standard open banking APIs won’t really benefit the bank in the long run because they only deliver minimal benefits for consumers and third-party providers (TPPs).  

So, how can banks look to benefit more from this new ecosystem with their existing technology capabilities?  

The power of collaboration and proactive differentiation 

Many banks are looking to collaborate more proactively with fintechs. Fintechs possess the consumer-centric, agile culture required to rapidly prototype and bring to market innovative new solutions that deliver value to today’s savvy consumers.  

Banks can adopt several strategies when working with fintechs. Those most commonly discussed range from programmes to instill an entrepreneurial agile culture within banks, building and engaging extensively with developer communities, and building internal developer capacity.   

This article will look at 3 key areas on how banks can capitalise more on the API technology layer and support the open banking technology infrastructure they have already invested in to attract and fast-track collaboration with fintechs. Adopting such approaches will help banks establish stronger differentiators to ensure that the best developers and most promising TPPs will work with them. Similarly, these approaches can also help attract partnerships with other banks with complementary goals.  

1.      Ensuring fintechs do less when they work with you 

With open banking, banks have the capability to share, receive, and produce data using the same interfaces. For instance, a bank may already have a credit scoring system internally. With the API aggregation capabilities of their open banking platform, the bank can now receive and make use of account, transaction, and credit data from other banks as inputs to fine-tune and produce more accurate outputs using their own credit scoring system.  

Third parties developing either B2B or B2C apps for providing consumers new avenues to access personal loans, property rentals, long-term vehicle hires, and leasing services would find this data extremely useful. Previously, their developers would have to collect, correlate and calculate creditworthiness by themselves. Even where credit scoring is done by a third-party service, this still requires additional work such as collating the information and integrating with another system to submit this information and obtain the credit score. Passing data to different systems requires app developers to follow additional security practices, privacy regulations, and other regulatory requirements. All this is time-consuming and expensive. 

Now, developers can access highly refined credit ratings via a simple one-time API integration, delivering considerable savings and much faster time-to-market. Offering such APIs would help the bank to differentiate and build long-term strategic relationships with TPPs.  

While the bank can make this API available for free to all users, it will need to be enforced with rate-limiting policies to ensure fair usage. A premium monetised version of the same API can also be made available. 

From a technical perspective, the bank can use an integration product such as an enterprise service bus (ESB) to integrate with other banks, for example, to share and view accounts and payment information and credit scores. 

2.      Providing higher-quality enriched data 

 Aside from mandatory information being made available under regulated open banking APIs, banks can enrich the data offered and monetise it through additional APIs. This enrichment can be achieved by using additional information from other internal systems at the bank, or by collaborating with external services. 

For example, a bank could integrate with an external service that uses AI and natural language processing (NLP) techniques to calculate credit scores. The bank submits information to this service and the processed output provided by the service is used by the bank in its own credit-worthiness checks. This is an enrichment to the bank’s own credit check and this data can be shared with external app developers through a monetised premium API. The bank can create a new API product through which consumers could obtain standard credit scores as well as the AI-enriched credit scores. Usage of this new API can be monetised and charged back to the consumer per usage or absorbed by the third-party developer. 

3. Taking open banking functionality to other industries “as-a-service” 

The new technical capabilities banks acquire as part of an open banking platform could be provided “as a service” to organisations that don’t want to invest heavily in deploying, maintaining, and updating such systems. 

An example is strong customer authentication capabilities and consumer consent management. Banks can extend these capabilities as a service to third-party app developers who can integrate with the bank’s identity and access management service for authentication and pay per number of users. Customers, including incumbent businesses and startups, benefit from not having to invest in a product and maintaining it on their own and by the knock-on effect of the trust consumers already place in the bank’s brand. 

Similarly, together with authentication features, consent management could be used by businesses where they require customer consent to share information with third parties. Hypothetically, a medical clinic with customer medical records in partnership with an insurance provider could use consent management features offered as a service by a bank to share those records, subject to consumer consent, with the insurance provider.  The consent management system at the bank would only need to maintain an identifier to the customer record at the medical clinic (data holder) and a reference to the insurance policy (data recipient). The bank’s system does not need to store any personally identifiable information about the customer giving consent. The insurance app needs to redirect to the bank’s consent management system when it requires to grab consent and verify from the user, just as with open banking scenarios. This service would come inbuilt with the same consent management flows that allow consumers to manage their consent preferences. 

I have outlined three API-led strategies that deliver value to consumers by utilising existing capabilities of open banking solutions. These strategies are set against the reality that APIs are already a baseline requirement in banking. To stand out, proactive experimentation and building the technical capabilities along with the right partnerships are core elements for delivering personalised and timely value to consumers, which in turn builds a bank’s competitive growth strategy in today’s fast-paced digital world.