Open banking: An introduction to APIs

In order to fully grasp the business potential of open banking, it is useful to have some insights in the technical concepts defining the open banking paradigm. This is meant to be a short introduction to APIs for non-technical people. There are over 12,000 APIs offered by firms today, according to programmableweb. Salesforce.com generates 50% of its revenue through APIs, Expedia.com generates 90%, and eBay, 60%.

An API is in its simplest form a standardized protocol for computer programs to talk to each other and is integral for modern software development. The use of APIs range from web-based APIs, operating systems, databases, hardware, or software libraries.

An API specifies the connection mechanism, the data and functionality that are made available and what rules other pieces of software need to follow to interact with this data and functionality. Although have been used to link software components within an organization a long, the Internet has given rise to the popularity of external web-based or public APIs. An organization can use a public API to allow third parties to access their data or services in a controlled environment. Using an API means that only desired aspects of software functionality are exposed, while the rest of the application remains protected. A Facebook ‘like’ on a third-party website and an embedded Youtube video are typical examples of the use of public APIs.

In addition to the examples mentioned above, companies such as Google, Apple and Facebook has created their digital ecosystems through the use of public APIs. BY allowing third parties to add functionality to their core offering, these companies becomes platforms for third-party innovation. Besides driving revenue, it also shortens time to market through crowdsourcing and co-creation of new products and services as well as service customer needs through customer demand driven development.

EBA has made a useful overview of the contents of common technical standards in todays APIs:

Data Transmission: the way the data is transmitted securely. Almost all APIs use HTTP/HTTPS as a transport layer because it is simple and widely compatible, although there are APIs which can be used over a wider variety of transport protocols.

Data Exchange: the format of the exchanged data. The most common formats are XML and JSON. While XML has slightly more functionality than JSON, the latter is winning in popularity. JSON can be used for most purposes and is less detailed, thus allows for faster exchange and is considered better machinereadable. Some companies offer their APIs in both formats, whilst others only have one format available.

Data Access: access management (who gets access to which data and how is this achieved). There are multiple standards for this, popular ones are SAML and OAuth 2.0. The first is an XML-based framework and is widely used in business-to-business interfacing. OAuth is a framework that originated in the consumer web services world.

API Design: the way APIs are designed. Common standardised design principles for APIs are REST (Representational State Transfer) and SOAP (Simple Object Access Protocol). REST is currently more popular due to its focus on solving issues related to performance, scal- ability, modifiability, portability, and reliability. Although SOAP is still popular in enterprise environments, it is considered more complex to implement.

Source: European Banking Association

APIs  allow technology to evolve exponentially and each company to focus on its own developments, integrating whichever services or data it lacks through the most appropriate API supplier in each case. As an example, about 75% of mobile apps resort to some type of internal API to offer information or features to its users.

When it comes to APIs, the level of openness determines potential reach.

1. Private APIs: Private APIs are closed APIs, and therefore exclusively accessible by parties within the boundaries of the organisation. By definition these are not considered ‘Open APIs’ in this information paper.
2. Partner APIs: APIs that are open to selected partners based on bilateral agreements. Like Private APIs, Partner APIs are exclusively accessible at the discretion of the provider of the APIs. Bilateral agreements on specific data exchanges between for instance a bank and an enterprise resource planning (ERP) software provider is an example of a Partner API.
3. Member APIs: This type of API is open to everyone who is a formal member of a community with a well-defined set of membership rules. When becoming a member of such a community the API provider allows access to the community members who comply with community membership rules and regulations. Future PSD2-mandated Account Information and Payment Initiation Services fall in this category as only authorised or registered Third Party Providers (TPPs) can obtain access.
4. Acquaintance APIs: This type of Open APIs is inclusive, as they are open to every- one complying with a predefined set of requirements. Developer portals distribute this type of API, which also comes with some form of standardised agreements. Merchant access to point-of-sale (POS) APIs is an example in this category.
5. Public APIs: Public APIs are inclusive and can thus be accessed by anyone, typically with some form of registration for identification and authentication purposes.

Source: European Banking Association

As software continues its march to transform all industries, lack of connectivity increasingly equates to being broken. If software developers are the new rock stars, then APIs are the instruments.