What is an API?

Be the first to comment

What is an API?

Contributed

This content is contributed or sourced from third parties but has been subject to Finextra editorial review.

The world of financial services is increasingly connected. This is thanks to the unsung hero of the digital world: application programming interfaces, or APIs – a millennial innovation opened out to the financial sector through a series of open banking regulations, including the first installment of the Payment Services Directives, in 2007.

APIs, in plain English

The term API is used by bank representatives, product teams, and software engineers, but what does it mean?

Simply put, APIs are engine-like technologies that transport requests – in the form of data – from system A to system B. These systems could be devices or applications, but the data moved between them informs the tributary system exactly what a user would like actioned. In practice, this process equates to the delivery of financial products or services to users’ fingertips.

A useful metaphor is that of the restaurant experience. Sat at a table, a guest browses the menu of dishes (analogous to a list of financial products), before informing the waiter (the information-carrying API) of their request. The waiter takes the ticket to the kitchen (the financial service provider) for preparation. Once ready, the waiter returns to the customer with the order.

Like a waiter, APIs move information back and forth – between the user and the provider. As such, APIs are the key deliverers of digital banking services, authentication processes, payments, account data aggregation, information verification, insurance comparisons (which we will come back to), and more. In fact, APIs underpin much of the connectivity of our modern world.

Types of API 

And since there are many uses of API, there are, in turn, many kinds. With respect to web APIs, there are four categories:

  1. Public

Public APIs can be used by any developer or entity that is seeking to share its applications or data. These are otherwise known as open APIs – and are perhaps the most well-known in the financial sector.  

  1. Partner

This type of API is only permitted to be used by licensed developers or consumers. It is usually deployed for B2B activity – such as passing over sensitive bank employee data to a payroll service. Partner APIs, therefore, are rarely themselves monetised, and often come with security mechanisms that are stricter than those of Public APIs’.

  1. Private

Otherwise known as Internal APIs, these engines run data back and forth between systems within the same organisation: between enterprise resource planning (ERP) and customer relationship management (CRM) portals, for example. This means the security measures on Private APIs are either minimal or non-existent – with users relying on the wider company’s defense structures instead.

  1. Composite

As the name would suggest, Composite APIs combine the functionality of two or more types of API. This approach may be taken if sequences of operations need to be actioned – or to boost the speed of a singular API variant.

It should be noted that the use of each of these APIs is governed by one of three categories of protocols or architectures: REST, RPC and SOAP. Each format comes with different characteristics, benefits, and tradeoffs.

Case study: Insurance

To better illustrate the work of APIs, let us return to the real-world example of the insurance comparison site.

Picture for a moment a prospective insurance customer opening their laptop to source quotes. The first port of call is an online price comparison site, which – once the customer’s preferences have been inserted – spits out a list of insurance providers, alongside their prices and offers.

To achieve this, the comparison site – with no direct access to each of the insurer’s prices or specifications – must communicate directly with the third parties, to aggregate the data. This is done via Partner APIs, which interact with the insurers’ APIs; establishing an interface that transmits all the relevant information for display to the customer.

It is the same network of open APIs that enable the customer to select a policy and begin paying for it via direct debit.

Building an API

Web developers go about building APIs by first asking what the goals and intended uses will be. What kind of people will benefit from the API? How will their needs be worked into the API? Are there any tight security requirements? What should the performance, availability and response time be like?

Then comes the design phase. Are there organisation-wide rulebooks on the matter to consider? Will the backend resources which the API connects to be established first, or will the interface? What are the interface’s intended operations?

Then is the development stage: the building of the API. Are there security measures – particularly for Public and Partner APIs – to be put in place? What caching, rate limiting, and other behaviors must be factored in? Which data models should outline the request and response messages? What service description language will be used to capture the interface? Which or the four protocol formats are most appropriate? Fortunately, there are API-building tools available.

Finally, the testing and deployment phase. Did the interface perform well against objectives in the various environments it was deployed? Decisions to make now include how any issues will be resolved; where the API will be hosted; and how adoption will be boosted. Publication in a specialist API developer portal is a popular recourse here, while monitoring and tweaking continues.

The dumb digital waiter

Facilitating almost every interaction between applications, data and devices today – the bedrock of financial services’ connectivity – is that efficient, dutiful waiter: the API.  

But the scope of the digital waiter, at least in the finance diner, may soon broaden further; on the heels of the third installment of the Payment Services Directive (PSD3), which is likely to be implemented in 2026. This seminal regulation will produce even clearer guidelines on API performance, which, once applied, will lead to higher standardisation, less downtime, and increased access to support. For consumers, this means all-out open banking services and embedded finance.

However the regulatory landscape moves, APIs will remain – to serve. 

Channels

Comments: (0)

/devops Long Reads

Hamish Monk

Hamish Monk Reporter at Finextra

What is an API?

/devops

John Barber

John Barber Vice President and Head at Infosys Finacle

Trade finance: Progressive business models to beat the slowdown

/devops

Hamish Monk

Hamish Monk Reporter at Finextra

How to leverage quantum computing

/devops

Contributed

This content is contributed or sourced from third parties but has been subject to Finextra editorial review.