Three API-led Strategies to Woo First-Class Fintechs

Photo by Piotr Chrobot on Unsplash

The need for regulatory compliance aside, the slow march towards banks buying into the necessity for “doing open banking” is now picking up the pace to a canter. APIs to allow sharing customer data and open banking consumer products and business use cases built around this concept will soon become the norm. 

In every regulated open banking ecosystem, all banks will eventually have the same mandated APIs. Even in non-regulated countries, market forces will mean most banks will end up opening up a minimum set of open banking-style standardized APIs. 

In this space, having the standard open banking APIs alone won’t benefit the bank, and it will only deliver minimal benefits to end consumers and third-party providers (TPPs). If you are just another bank, you would neither be able to build value for consumers nor capture some of that value for yourself in terms of goodwill and profits. So, how can banks look to benefit more from this new ecosystem? 

“Collaborate, collaborate, collaborate” 

More and more banks are looking to answer this question, and the formula that is emerging is to look to collaborate much more deeply and proactively with fintechs. Fintechs are recognized as possessing the consumer-centric and agile culture required to rapidly prototype and take to market innovative new solutions that deliver more personalized value for today’s growing base of digital-native consumers. 

There are several strategies and tactics proposed and talked about at length to help banks succeed in working with startups. These range from programs to instill an entrepreneurial agile culture within banks, building and engaging extensively with developer communities, and building internal developer capacity. My intention is not to cover all of these, but to discuss how banks could look to capitalize more on the API technology layer and supporting open banking technology infrastructure they have invested in to attract and fast-track collaboration with fintech firms, and even innovative startups from other industry verticals. 

Proactive differentiation

These three points are based on establishing a stronger differentiator for the best developers and the most promising TPPs to choose you as their preferred partner and become the cogwheels of your innovation engine. These same differentiators could just the same attract other banks, including neobanks, who are also shopping around for new data streams and services to bundle into their own offerings and innovative products.

1. Ensure fintechs have to do less when they work with you

With the solutions they build for open banking, banks now 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. The algorithm that takes into account all these data, outputs a single credit score per customer that may now be exposed as an API.

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, these developers would have had to collect data (near impossible to do at the scale now possible via open banking), correlate this data, and calculate creditworthiness by themselves. Even where the actual credit scoring was to be 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 will require app developers to follow additional security practices, privacy regulations, and other regulatory requirements on information exchange. All this data collection, processing, and R&D is not only time-consuming, but it is also expensive, especially for cash-strapped startups with good ideas.

But now, these same developers have available to them highly refined credit ratings via a simple one-time API integration, delivering considerable savings and enabling a much quicker time-to-market—all extremely attractive value propositions. Offering such APIs would help the bank to stand out from the rest that only offer standard open banking APIs. This represents an important win for progressive banks looking to build long-term strategic relationships with a community of strong developers. 

While the bank can make this API available for free for all users, naturally, it will need to be enforced with rate-limiting policies for invocation limitations to ensure fair usage. A premium monetized version of the same API can also be made available, which doesn’t have any such invocation limitations.

Figure 1: Using an ESB to integrate with Open APIs at other banks

From a technical perspective, a bank can use an integration product such as an enterprise service bus (ESB) to integrate with other banks. Example scenarios include sharing and viewing accounts and payment information and credit scores calculated by other banks. The aggregation logic and submitting the collected data to the credit scoring system is implemented within the integration component. The credit score API is exposed through the API management component and the request is routed to the credit scoring system through the integration component after performing the necessary message transformations. 

2. Provide higher-quality enriched data

Along with the information that is mandatorily made available under regulated open banking APIs, banks have the ability to enrich the data being offered and to monetize these through additional APIs. This enrichment can be added using additional information from other internal systems at the bank, or through collaborations with external services.

To illustrate how this may be done, and going back to the previous example, the bank could integrate with an external service that uses AI and natural language processing (NLP) techniques to calculate credit scores. The bank submits certain information to this service and the further 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 potentially shared with external app developers through a monetized 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 monetized and charged back to the consumer per usage or absorbed by the third-party developer as per their business models.

Figure 2: Integrating with an external AI-based credit scoring service

From a technical point of view, integration components in the bank’s portfolio may be used to integrate with the external AI-based credit scoring service. The integration component can collate the necessary data and submit inputs as well as obtain outputs from the system using its APIs. The output can be fed back into the bank's own credit scoring system for internal use. Similarly, the enriched output from the bank’s credit scoring system as well as the output from the external system can be both made available through the API management layer. The usage of this new API can be tracked within the API management layer and usage information be passed on to a billing system. Invoices generated for the usage can be shared with developers through the developer portals within the API management product.

Let’s discuss another example of such data enrichment that may also be monetized. Banks will have information on funds or payments received into an account as well as debits that have been paid out to various merchants. Banks would also have additional information about these merchants and the type of payments that happened—for example, payments to charities, educational expenses, and utility payments. This additional information can be used to provide quality enriched data to app developers where recommendations can be made by the bank on how some of these funds can be used to receive tax benefits and rebates and automatically flag transactions that qualify for such benefits. Correlating this data can be done through data analytics capabilities that may be part of the bank's open banking solution. The information can be sourced and updated in real-time from these systems and made available as enriched data streams to app developers through the API management layer.

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

The new technical capabilities banks acquire as part of an open banking platform, may also act as avenues for revenue generation. Banks could provide these technical capabilities as a service to other organizations that don't want to invest heavily in deploying, maintaining, and updating such systems but may want that feature as part of an existing integration with a bank's capabilities. 

Important capabilities acquired by banks as part of open banking would be strong customer authentication capabilities and consumer consent management. Banks can extend these capabilities to third-party app developers as a service. Many third-party apps would require user authentication capabilities. They can integrate with the bank’s identity and access management service for this and pay by the number of users they have. The apps benefit from not having to invest in a product and maintaining it on their own and also by the knock-on effect of the trust consumers already place in the bank’s brand—trust is a key factor in the consumer-adoption of technology relating to sensitive personal information.

Similarly, together with authentication features, consent management could be made use of 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. More information on a person’s medical history would naturally help insurance companies assess real risks more effectively and set more personalized premiums. This immediately delivers a better deal for the end-consumers who opt to share their medical history held by the clinic and for the insurance company, who can now attract more consumers by providing a more relevant and personalized service. 

Figure 3: A sample consent management-as-a-service flow

From a technical point of view, 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; this minimizes risk. 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. A bank can monetize this usage based on the number of consents it maintains for an insurance provider.

Banks are inherently seen as trustworthy companies and customers engage with them based on complete trust. Similarly, banks can act as trusted providers of these services to third-party app developers and other organizations enriching new verticals with the consumer and business benefits now being proven in the open banking space.

Conclusion

I have outlined three API-led strategies built around proven use cases that deliver value to consumers by utilizing existing capabilities of open banking solutions. These strategies are set against the reality that APIs are already a baseline requirement of banking. A “build it and they will come” approach will no longer cut it. To stand out, proactive experimentation, similar to what is described above, and building the technical and HR capabilities along with the right partnerships to execute that experimentation have become core elements of delivering personalized and timely value to consumers—the holy grail of building a competitive growth strategy in today’s digital banking world. 

To learn more about how the API management, integration and API monetization capabilities of a strong open banking solution could enable banks to secure business benefits through more effective collaboration with fintech firms, register for Vidura’s webinar to be held on July 21, 2020, at 2 pm GMT.

Vidura is Senior Director—Solutions Architecture at WSO2. In his role he provides technical guidance to customers in architecting solutions based on their current and future needs, using the WSO2 platform. Prior to joining Solutions Architecture, he was Senior Director—Engineering and led the analytics, integration, platform, and financial solutions teams. He is an experienced technologist and an executive with over 15 years of global experience in the software industry covering many domains such as finance, logistics, aviation, and energy. He led the technical advisory for open banking projects in the EU and the UK and has also worked in the US and Australia.