According to a global survey on application programming interfaces (APIs) by McKinsey, 81% of respondents
said APIs are a priority for business and IT functions. “Large banks are launching API programs and allocating about 14% of their IT budget to APIs, on average,” claims the survey. So what exactly are APIs, and how should institutions be using them?
Simply put, APIs are engine-like technologies that transport requests – in the form of data – from system A to system B. These systems can be devices or applications, but the data moved between them
informs the tributary system exactly what a user would like actioned. In practice, the process equates to the delivery of financial products or services to users’ fingertips.
The use of APIs within the financial services sector has been on the rise ever since the first installment of the Payment Services Directives, in 2007, which sought to increase competition on Europe’s payments landscape. In point of further refinement, the
regulator has since issued a second Payment Services Directive (PSD2), in January 2016 – which will soon be replaced with the third installment,
PSD3.
For the institutions looking to deploy APIs, or even fine-tune their current stock ahead of the PSD3 deadline – which is predicted to fall in 2026/27 – this short read considers the processes and challenges around the technology’s use.
The four flavours of API
Broadly speaking, APIs can be used in four ways:
1. Public
Public APIs, also known as open APIs, can be used by any developer looking to share its applications or data – and are very common in financial services.
2. Partner
This type of API is only permitted to be used by licensed developers or consumers. It is usually deployed for business-to-business (B2B) activities – such as passing sensitive bank employee data to payroll services. The security mechanisms for partner APIs
are stricter than those that come with open APIs.
3. Private
These engines run data back and forth between systems within the same organisation, for instance between enterprise resource planning (ERP) and customer relationship management (CRM) portals. Security measures for private APIs are therefore negligible.
4. Composite
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.
What do banking APIs provide?
By building API-enabled communication into software systems, financial institutions can benefit from:
- Integration, scalability, and agility: If a bank’s infrastructure is comprised of various modules and microservices, private APIs can be deployed to ensure all functions share information efficiently. What’s
more, by implementing well-defined APIs, services can be decoupled and scaled according to demand. This allows systems to evolve over time – removing the need to overhaul entire infrastructures.
- Modernisation: Thanks to APIs, third parties can build upon existing platforms, and create new applications and software solutions. This means a more level playing field and, for consumers, improved financial
services. According to
McKinsey, banks plan to increase “the share of APIs available for partners and the public to almost 50% over the next three years, laying the technical foundation for wider ecosystems.” There are budgetary efficiencies too, with APIs enabling the re-use
of services and components – thus slashing development costs.
- Accessibility and automation: By facilitating the rapid flow of information between systems, APIs can help banks to pivot to real-time, which has innumerable benefits, across fraud prevention, sales, personalisation,
and more. In addition, some manual or administrative tasks can be automated with APIs – thus driving operational efficiency and reducing human error.
- Compliance: Not only does the use of APIs help institutions comply with Europe’s Payment Services Directives, but it also supports internal standardisation – harmonising the way systems interact.
- Security: While public or composite APIs can come with security risks, a well-designed, robust API can act as a gatekeeper of sensitive information. Rather than giving individuals multiple access points, a
single API can be inserted to manage data access securely.
Case study: Emirates NBD
With these benefits in mind, Emirates NBD started a program back in 2017 that put APIs at the core of its IT architecture.
With this approach, explains McKinsey’s
report, “the institution was able to develop a flexible architecture that significantly boosted the speed and efficiency of new product delivery, in part through a decrease in integration efforts. Repetitive development work fell significantly through the
modularisation and reuse of functionalities.”
Upscaling the entire value chain
If APIs are fit-for-purpose and used correctly, they can render banks’ composite infrastructures interoperable, agile, automated, and secure.
But the benefits of APIs extend to customers too – expediting data transmission, integrating services, reducing touchpoints, delivering innovative products, and, in general, upscaling the entire banking experience.
Once again, the message for late adopters is to leverage PSD3 to drive service and product opportunities. This can only be achieved through close collaboration between IT leaders and the business, by aligning on priorities, and carefully tracking performance.