APIs in Banking: Benefits and Challenges

Why should banks use APIs?

Banks can benefit from using APIs in a number of ways, such as integrating internal applications to allow quick and efficient application development, as well as expanding the company’s reach by offering a programmatic way to use its services. Customers today expect applications to be smart, connected, and integrate with other services and devices. APIs provide the glue to make such experiences possible. And there are of course opportunities to create revenue from APIs in their own right.

By providing well-defined interfaces through APIs, system-to-system interactions can be enabled while hiding the internal workings of the programs. APIs often employ simple yet powerful technologies. In the case of popular REST services, the relatively simple text-based JSON format over the ubiquitous HTTP protocol is typically used. Using these common standards also helps when augmenting older software with new capabilities: Basically any software capable of communicating over the Internet could potentially be an API consumer. Diverse programs running on different platforms built on different technologies - be it Java, .NET, Node.js, or something completely different - can utilize APIs to bridge the gap.

One company building their business around APIs is the payment provider Stripe, which apart from ready-made applications, also offers a cloud-based API ecosystem of financial services. Leveraging the platform, other companies can build tailor-made applications for their customers to use. Shopify, the popular ecommerce platform, is one company that builds on Stripe APIs to offer payment options, as well as banking solutions for merchants. In turn, Stripe typically charges a fee for the use of the APIs.

Looking at the intended audience, APIs can be roughly divided into three groups: Internal, partner, and public.

‍

Internal APIs

A large number of APIs that businesses have developed are internal, meaning the primary consumers of the APIs are developers within the organization itself. This makes perfect sense, as businesses often struggle with communication between their systems, which may be based on different technologies. APIs provide a fast and versatile way to enable otherwise incompatible systems to integrate with one another, helping data to be shared and avoiding silos of isolated systems. APIs help developers to quickly build new, relevant applications securely. The API provides a layer of abstraction that hides complex business code and the technical details of the system providing it, reducing costs.

Famously, Amazon founder Jeff Bezos recognized the need of using APIs to allow for communication between departments within Amazon back in 2002 and issued a mandate stating all teams must expose their data and functionality through externalized service interfaces, and all teams must communicate with each other only through these interfaces. The original source of the mandate is lost to history, but the concepts live on in the tech space and helped form the basis around the principles of APIs. It shaped Amazon’s cloud service offering AWS, their externalized infrastructure, and business-to-business functionality.

‍

Partner APIs

While internal APIs are only accessible from within the business, a partner API can be used by select third parties to facilitate business-to-business communication. One such scenario could be to share data on stocks with another company, which the partner can request on demand for further processing. Gone are the days when such information was sent as files using SFTP or email!

Taking this idea further, Banking as a Service (BaaS) and embedded finance are concepts where third parties use partner APIs to offer banking services. This means that the services offered by a traditional bank - such as money transfer, and electronic invoice management - are made available using APIs, and partners can build services on top of the APIs, effectively acting as a bank in some aspects. This allows the bank to focus on developing their backend services and APIs, while partners focus on the end-users.

An example is the Lyft debit card issued to its drivers. While the user might get the impression that the card is issued by Lyft alone, behind the scenes is actually a traditional bank, doing the heavy lifting of providing the card, handling transactions and ensuring regulatory compliance. APIs offered by the bank allows Lyft to further build on those services, to provide improved user experience and a rewards program.

‍

Public APIs

APIs targeted towards external developers to build applications and services on, further expands the potential. An example of one such API is the PayPal REST API, allowing practically any developer to build apps and widgets that use functionality for payments, invoicing, transaction history, and so on. Unlike a partner API, the consumer of the API does not have to be in close relationship with PayPal to access it. The developer can register for an account to use the API, and use a secret to authenticate and perform requests.

‍

‍

Technical challenges with APIs

Implementing useful APIs must be done with much care. Apart from their core purpose - giving access to a system - they must be fast, secure, and easy to use, among other things.

‍

Performance and scalability

To provide a good experience to as many consumers as possible, high performance is essential. An API not able to handle the requests at the rate they arrive will gradually respond slower, eventually grinding to a halt, throwing errors. To avoid this, there are several techniques commonly used. Some examples include:

Flexible queries: Naive implementations may suffer from the so-called n+1 problem, where several requests against an API are needed to retrieve all necessary data. For example, using Stripe’s API, all payments for a customer can be retrieved as a list. But to get the payment method for each of these - which contains information such as which credit card was used - another API call needs to be made for every single payment. So if a customer has made 100 payments, this means we have to make 100 additional requests! To avoid this, the Stripe API allows for such information to be “expanded” to include the payment methods along with the payments in a single call. This means less hassle when consuming the API, and improved performance as performing many calls generally creating more load than a single call.
Horizontal scaling: Depending on the load, most cloud providers allow more servers to be dynamically provisioned at runtime. This enables a large number of requests to be handled during peak hours by scaling up, and keeping costs down by scaling down once less processing power is needed. One such example is the Norwegian payment provider Vipps, who built their services on Microsoft Azure to take advantage of the possibility to scale up the infrastructure to support the increasing number of users and transactions. Similarly, the Swedish payment service Swish is moving from a legacy system to a scalable microsystem cloud-based architecture to keep up with demand.
Asynchronous processing: Some API operations will be inherently slow. Such time-consuming operations can be dealt with asynchronously by accepting the request, starting the processing once resources in the backend are available, and informing the client once the process is ready. The PayPal API uses webhooks for this purpose, which act as callbacks to the consuming application, allowing for event-driven development. One use case is payments: Once a payment has been authorized, an event is sent from the API that the consumer can act upon in real time.
Rate limiting: If resources are scarce, it might be necessary to limit the number of requests a client can make. This can mean setting the maximum allowed calls per second to an API to a fixed number - for instance, 1000 requests per second. Rate limiting helps avoid overwhelming the system, which provides some level of protection against denial of service attacks, where an attacker sends a large number of requests to the API, making it unresponsive. Preventing such attacks can be critical for banks, as otherwise an attacker could render the API useless for legitimate customers.

‍

API Security in the Financial Sector

While some APIs lack any form of authentication, others - if not most - live and die by it. Securing an API to prevent unauthorized access to data can be absolutely essential, especially in the financial sector. As an example, the EU revised directive on payment services (PSD2) recently came into effect, which requires that banks allow third parties to access their services using APIs, something that banks have been hesitant to do in the past, partially because of the risk of such APIs being compromised. Payment services are of course extremely sensitive, and cybersecurity has top priority when offering such APIs. It should come as no surprise that PSD2 comes with security requirements as well, referred to as Strong Customer Authentication (SCA), requiring multi-factor authentication on the customer end.

Security is a complex topic and here are just a few points to consider when providing APIs:

Understanding authentication: Many APIs are vulnerable to attacks simply because of broken authentication. Tools to detect such exploits exist, and a successful attack could be devastating. Fully understanding the complexities of authentication is required to properly implement a secure API.
Defense-in-depth: Implementing multi-layered protection against each potential risk. In the case of protecting against a hacker attack, instead of just relying on a single measure, such as a firewall, measures need to be set up on several layers, each serving as a protection net for the preceding one. An example could be a firewall on the network layer, then an application firewall, then conducting server hardening on the operating system level, and so on.
Least privilege principle: Every user, as well as technical component, should have only the minimum access permissions possible. If a user account or component is compromised, this limits the potential damage the attacker can cause. Also, strict separation of IT systems is needed for similar reasons, especially between development, testing, and production environments.
Monitoring: There should be systems in place to monitor activity, and thresholds defined for classifying events as security incidents. In the case of such an event, the owner of the API should be alerted so that appropriate actions can be taken.

‍

Crafting Superior Developer Experience: The Competitive Edge in Financial Sector APIs

Just like user interfaces are built to provide a good user experience, APIs should be built to provide the best possible developer experience as the primary users of your APIs will be developers. Making your API easy - maybe even fun! - to use helps accelerate adoption and increase developer productivity. Attracting developers to use your APIs is important, and in the case of partner APIs in the financial sector, there is a lot of competition - to give you an edge, you want to offer great developer experience to encourage fintech startups to use your APIs and build their business on your services.

There are several factors to consider when building APIs with good usability:

Functionality: First and foremost, the API should do what it says in the tin. It needs to be flexible enough to provide both the basics as well as more advanced scenarios when needed. Therefore, engineers should go beyond simply solving a specific problem at hand, and instead try to take a step back and solve more general problems. The API should have a clear goal, but still be designed for multi-purpose use. This should make the APIs usable in a large number of situations and avoid several other redundant APIs being developed to solve a similar, but slightly different, problem.
Consistency: The API should adhere to common industry conventions, and exhibit consistent behavior. For example, a typical REST service should clearly define when and which HTTP codes are returned, how queries to the API should be built, which HTTP verb is used and when, and so on. Always knowing what to expect lessens friction when working, and staying consistent and avoiding surprising the consumer is key.
Discoverability and documentation: As the number of APIs grow, companies risk what is often known as API sprawl: New APIs are developed at a quick pace, often hosted in many different locations, while old APIs are left unmaintained. Documentation is lacking or missing, and finding the right API quickly is increasingly difficult. Using an API catalog software to organize and document all APIs in the company can help combat such issues by making finding the right API easier, and providing documentation for each API.
Dependability: As discussed earlier, APIs should be fast and stable. No developer wants to work with an API that constantly crashes and processes requests slowly.

‍

Banking in the Digital Era: Navigating the EU's Open Finance Regulation and Harnessing the Power of APIs

The digital evolution continues at a fast pace and is showing no signs of slowing down. The EU is currently pushing for regulation within open finance, which could help standardize API formats and enable a range of services tailored to the end customer, such as offering better access to financing or creditworthiness assessment by utilizing shared customer data. Companies need to be ready to accelerate their investments in APIs to fully maximize the new business opportunities open finance will bring.

As the landscape is changing quickly in the banking sector, companies need to implement a comprehensive API strategy to keep up. They need to consider what APIs they can consume from other providers to improve their own services, and what APIs they themselves should offer - internally or externally - to build an efficient, discoverable and well-documented API ecosystem. A good strategy that captures the benefits of APIs helps companies expand their service offering, drive revenue, and stay competitive today and in the future.

While the possibilities are indeed endless, companies will face many challenges when building an API ecosystem. Having a clear understanding of the problems APIs can solve, what business value they provide, as well as potential obstacles involved, is key. It goes without saying that acquiring the right talent for your business is crucial for successfully implementing your API strategy.

‍

APIs in Banking: Benefits and Challenges

Unlocking Banking's Future: Navigating APIs for Growth and Security

Why should banks use APIs?

Internal APIs

Partner APIs

Public APIs

Technical challenges with APIs

Performance and scalability

API Security in the Financial Sector

Crafting Superior Developer Experience: The Competitive Edge in Financial Sector APIs

Banking in the Digital Era: Navigating the EU's Open Finance Regulation and Harnessing the Power of APIs

Further reading

Authors

What we do

Resources

Join us

Follow us

Subscribe to our newsletter!

Request a consultation