The Role of API Portals in Digital Banking

By Olaf van Gorp, Perforce Software

Until recently, the majority of APIs were implemented by financial services organisations internally, or to a fairly limited external audience, but that is changing fast, particularly in regions that have introduced open banking standards. Increasingly, APIs are exposed to the outside world, and are an important part of digital transformation in this market, connecting systems, organisations and consumers in a theoretically seamlessly way.

However, the explosion of APIs being introduced brings many challenges. Managing APIs can be challenging even for an experienced developer, let alone the growing number of often non-technical stakeholders — such as marketing departments — involved. APIs are essentially a ‘product’. It is hard to know how an API will perform until it is published, plus APIs that are released containing vulnerabilities can rapidly escalate into security risks.

API management systems are already widely available and adopted. Though they often included an API portal function, such portals were typically addressing API developer needs and were primarily meant for internal usage. With APIs now increasingly being published to external audiences, the need for API portals that are consumer-oriented has become much more apparent.

Typically, API portals are front-facing collections of existing, published API products, providing a safe place to test, review, and share APIs, as well as to discover and search for other APIs. An API portal can be called a ‘sandbox’, in other words, a safe place in which to experiment and see how an API will perform once published. It can also be a place to promote API products and seek inspiration from other API owners.

It is important to note that for a consumer-oriented API portal, the user requirements are very different to those of an API management system or API developer environment.  Business stakeholders, for example, may be interested in the actual value that the use of a particular API may offer. Application developers, on the other hand, will be more focused on  technical API details. Security architects will want to scrutinise the API’s security policies. Consequently, an API portal should be accessible and understandable by both technical and less-technical stakeholders, provide technical as well as contextual information. It should also support means to interact with the API from both a functional and a security perspective.

Perhaps the best way to illustrate the requirements is by looking at an example user journey. A licensed payment service provider (PISP) might want to integrate with as many banks as possible within their scope — for instance, their geographical focus — so they can facilitate payments for a user regardless of the bank with which he or she holds an account. To integrate a particular bank’s payment service, the PISP’s team visits that bank’s developer portal to review available APIs.

Olaf van Gorp

The product owner responsible for the development of the PISP app will be interested in the contextual information around the API, including: a general overview of its capabilities, any constraints that may apply (such as whether or not the provider is licensed by relevant national authorities); and any associated costs.

Assuming the product owner is happy with what he or she finds, the next step is to point the PISP’s developers to the portal to check the API’s technical details. They will expect to find all the information they need to actually integrate the API into their application. A great starting point is testing the API in the safe ‘sandbox’ environment, to become familiar with the API’s performance. In addition, developers will need to understand what security measures have been put in place, so to have an intelligent test client available within the sandbox that generates sample ‘values’ that will satisfy API security requirements is helpful. This will also assist the developer in knowing what needs to be implemented into the client application to satisfy those API security requirements.

What to look for in an API portal

Given the variety of stakeholders involved in APIs, it is vital that an API portal ‘talks to’ audiences at different levels. Ideally, there should be a ‘wrapper’ or introduction to the API that the user is considering connecting to, including a profile of the organisation behind that API. Look-and-feel matters: a marketing manager probably is not going to feel comfortable looking at something that has the appearance of a development portal. Icon-driven actions can help to simplify processes. Clearly, developers are going to need access to deeper levels of information, so the portal needs to provide both technical and non-technical user experiences.

APIs that give access to sensitive financial data should have rigorous API security applied, the details of which may have been specified in the open banking standards that apply to the geography at hand. One upcoming standard is the Financial-Grade API specification (FAPI) that is already underpinning the UK Open Banking security profile. It has been speculated that it may also be adopted by the Berlin Group, as part of its imminent Open Finance Framework. Comprehensive financial-grade API security is quite sophisticated and will typically involve various technology standards like mutual TLS, OAuth2.0, OpenID Connect, the use of JWT for various data exchange scenarios, and more. Having the API portal provide the means to explore and interact with such features becomes increasingly indispensable.

Finally, an API portal should also provide access to operational metrics and analytics, including performance. Having access to this information in the sandbox improves the app development process by enabling enhancements to be made before release, then metrics once the API is in production provides helpful feedback, a means of troubleshooting, and identify areas for improvement.

When done well, API portals create a great place for financial services organisations to share, collaborate, promote and discover APIs, helping to propagate better quality APIs, more choice, and keep up-to-date in the fast-paced API world.