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:
- 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.
- 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’.
- 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.
- 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.