Good API, Bad API
In some eyes, the introduction of the Payment Services Directive 2 (PSD2) has sparked an open banking revolution. It has forced banks to relinquish their monopoly on payment services and provide third parties full access to their customers’ accounts.
And application programme interfaces (APIs) are the means by which this ‘treachery’ will be delivered, so to speak, at least in the eyes of some of the incumbent banks that view open APIs as an unnecessary evil.
The more enlightened banks are realizing that the open banking concept presents them with new opportunities - the chance to build partnerships with third parties and the means to develop enhanced customer experiences based on new technology.
APIs will be at the heart of these opportunities having emerged as the de facto means for sharing data between different systems. So-called ‘open’ APIs are already embedded within the numerous challenger banks and the incumbent banks should similarly see APIs as products upon which they can develop their own tools and services.
They should also see APIs as a means to connect to and collaborate with potential fintech partners and to see themselves as both producers and consumers of these tools.
The problem is that, while open APIs are written to common code development principles and are fully documented, the market is still relatively immature and untested and banks could face some significant risk when building a new app on an unknown and unproven API.
For example, a bad API can be among a bank’s most prominent liabilities and result in an unrelenting stream of support calls from irate customers unable to connect to the banks.
So, what can be done to mitigate those risks? What testing can be done and what questions should be asked of a potential API provider? In essence, how do you separate the good APIs from the bad APIs?
At least it is easy enough to define the properties of a good API – from a customer perspective they should be easy to use, hard to misuse; and from a developer perspective they should be easy to extend and to maintain any required code. And in both cases, they should be appropriate to the intended audience.
But in terms of ensuring quality control, banks should establish an operating model that allows them to safely and securely test any external APIs and to manage the distribution of their own APIs to third parties.
Finastra is supporting this process through our FusionFabric.cloud platform. We recognize that providing connectivity to a standard set of pre-built and fully integrated Open APIs is just one of the building blocks necessary to achieve success. A platform-based approach can also dramatically optimize the software developer environment. For example, giving developers the ability to interact with the Open APIs in a sandbox environment will allow them to experiment online in bringing data into their applications and to test the inputs and outputs in a safe environment before they’re deployed to market.
Banks can also appoint a number of API product managers that act as the quality controllers and are able to ensure that their chosen APIs are accessible and useful to their customers and developers alike.
This means banks have to view APIs as products and not as existential threats to their business. There is evidence that this is happening. An audience poll conducted at the 2017 Sibos conference found that 43% of banks already had an API strategy and a similar number (42%) were at least considering one.
The conference also featured a number of suggestions for banks looking to generate value from their APIs. These included setting up a centre of excellence for APIs; recruiting open API experts; creating an API developers’ portal; and using cloud-based services.
The benefit of the cloud and a platform-based approach is that it allows banks to decouple their APIs from their often-incompatible legacy systems and to create the API testing environment necessary for quality control and ease of collaboration with partners and customers. Ultimately, such an approach will allow new apps to be fully tested and delivered to market much faster – helping banks deliver on the potential of open banking for their customers.