An Introduction to Open Banking APIs

Written by: Francis Limousy

January 2, 2017 - An introduction into APIs, intended to people who do not come from a software development background.

What’s an API exactly?

Just about everything is … so let’s separate the theory from the application in the payment domain.
An Application Programming Interface, or API, is a software concept representing an interface rather than a function. It allows two programs to talk to each other (exchange information, request processing …).
Every time a program communicates with another, it uses an API. For instance:

  • When the Facebook mobile application want to send you notification, it uses an API in the mobile operating system (android, iOS …), which in turn will display the notification on your screen according to your preferences.
  • When you open the weather app, it uses an API to retrieve local weather data from weather.com

It is noteworthy that other type of interfaces allowing programs to communicate existed before what we call APIs, such as batch files, message queues …
APIs have two main components:

  • The API implementation; running on the program exposing it
  • A documentation; defining how to use the API for programs wishing to access it

We then talk about open APIs when:

  • The documentation is publicly available
  • The implementation is accessible outside the organization.

The term can then sound a bit tricky in a banking environment - where “openness” is not really part of the culture – but open does not mean unsecure. APIs, open or not, often embed a security profile (e.g: require authentication …).

To re-use the example above, the weather.com API is an open API; its documentation will define for any external developer how to request for weather data:

  • Input: one location information (e.g: ZIP code, GPS coordinates, City name)
  • Output: Multiple weather data (temperature, barometric pressure, chance of rainfall …)

It is up to the developer of an external application to implement the correct API and choose how to display the results.

SOAP, REST?

The concept of APIs is not new; however in the actual payment context, what we are generally talking about is a type of APIs called Web Services, which appeared in the late 90s with the popularization of Internet.
Web Services are the external interfaces (APIs) published by an application server.
The two most common implementation of Web Services today are:

  • SOAP (technically, SOAP/XML; mature and syntax-strict specification, standardized by the W3C)
  • REST (technically JSON/REST; newer/lighter industry standard, not based on strict syntax)

When we hear about RESTful APIs, we are then referring to a faster/low-constraint way to implement these Web Services. It was popularized by tech companies such as Google or Facebook as their main development paradigm. This allowed such companies to create or change these APIs at a fast pace, increasing their market responsiveness.

Application in the banking domain

The banking domain, for many reasons, is not the first one to adopt new technologies. A lot of core banking services still run on technology from the 70s (mainframe, COBOL …). Maintaining or updating such infrastructure is very costly. Replacing it has become almost an impossible task. This is a concept called technical debt; the upfront investment cost to replace this infrastructure is so large – both in time and money - that it’s difficult to justify.
Financial institutions are then stuck in a maintenance strategy for this large infrastructure and become increasingly challenged by lighter / more adaptive players in the market.
A good example of dis-intermediation is mint.com, a personal finance website and in the US (now part of Intuit):

By getting information from multiple financial institutions via APIs, Mint creates clear value-added for the end-user (consolidation in one place of multiple personal finance data, reporting …), while gathering a unique perspective about him (aka Customer Profile); allowing to advertise new products more efficiently.
Interestingly, Mint uses a “crowd” approach to convince Financial Institutions to expose their APIs. If for instance your issuer does not support Mint, the site will redirect you to the customer complaint page of your issuer with a pre-prepared message asking to connect to Mint.
The popularity of the site, alongside this “customer complaint” approach, put issuers in a delicate situation where they are bullied into adopting the system or face the consequences (customer unhappiness, loss of comparative competitiveness …)
Another example would be the emergence of new payment processors, adapting to payment technology innovation much faster (e.g: Bitcoin acceptance, multi-currency, mPOS …).
Because they don’t carry this technical debt, newer processors (Stripe, Square, Adyen …) have a better operational efficiency and can evolve faster than traditional processors (First Data, TSYS …).

Open Banking

One possible application of these development paradigms is external.
Financial institutions might want to re-take the control on how their data and capabilities are used, as opposed to try to prevent new services from fintech or over-the-top players (if you cannot fight them, lead them).
We see an increasing number of Financial Institutions putting in place this open banking strategy; Citibank, Visa, Mastercard …
Aside from the embracing the fintech revolution, this also allow them to monetize some of their internal services (Risk management, mobile wallet services …).

Service-oriented architecture

Another potential application is internal.
Web Services have often been used in software architecture to create a paradigm called a Service Oriented Architecture (SOA).
SOA design consists in separating functions of a system in many services, all communicating throughout the infrastructure using a shared medium. A common implementation pattern for SOA uses a central communication channel called an ESB (Enterprise Service Bus). On this ESB are published – you guessed it - APIs.
A unitary service can then be replaced or upgraded without impacting the rest of the infrastructure.

 

One of the key success factor for implementing SOA being to have properly designed, validated and maintained APIs.

Disclaimer

These are the personal opinions of UL’s employees and its guests and should not be misunderstood as representing the opinion of UL's clients, suppliers or other relations.