How APIs are used in Open Banking
What is an API? APIs use cases
When you think of Open Banking technologies, APIs are most likely to come to your mind. And you are right to do so. APIs are enabling the development of Open Banking and in this article, we will be explaining what is an API and what are the benefits and use cases of APIs in Open Banking.
What is an API?
API is short for Application Programming Interface. An API is an interface through which a computer program interacts with another computer program.
What is a REST API?
Representational state transfer or REST services are one way to architect APIs and the most common ways to define and implement them in Open Banking.
REST focuses on resources and their state. In our context, a resource can be a bank account and its state may be the balance. Each resource has a unique identifier, like an account number.
A REST API lets the client read information from a resource, update the information in the resource, or even create or delete a resource. So, the name REST comes from the idea that representations of the resource state are transferred between the client and the server.
Like in a browser, resources are addressed through a universal resource locator (URL). This is the string you enter in the browser to access a webpage. REST services are typically accessed via an HTTP, the Hypertext Transfer Protocol. Again, this is the same protocol used to access webpages.
Unlike in remote procedure calls, REST only uses the four procedures, or verbs, as they are called in HTTP: GET, POST, PUT, and DELETE. GET retrieves the information from a resource, POST creates a resource, PUT updates a resource, and DELETE deletes a resource.
When you browse the web, you send GET requests with a certain URL to a web server, and
receive the content of the web page and render it in the browser. This close resemblance to the most widely used protocol in the web has made REST a very popular choice to implement APIs. For example, the UK open banking APIs are defined as REST services, where the API to retrieve account balances looks like this.
Open Banking APIs: 7 Benefits of APIs in Open Banking
These are 7 benefits of open banking APIs:
- Avoiding screen scraping, which is a practice that puts customer privacy and security at risk, and may yield inaccurate or incomplete data.
- Faster and lower cost integrations, compared to legacy and custom service-oriented architecture based APIs, reducing the cost to experiment and implement with customers and partners, and accelerating time to revenue.
- Ability to meet customers and partners development capacity and sophistication where they are, either with only APIs, or with APIs supported with webhooks and SDKs, or with APIs that come with their cloud ERP solutions.
- Ability to co-create custom solutions with partners in co-branded or private label businesses.
- Supporting real-time processes and payments in ways that legacy batch systems or user interfaces cannot support.
- Development of new services or capabilities that wouldn’t have been possible without data aggregation or real-time payments.
- Accelerating innovation not just by spurring new product development internally, but by leveraging the capabilities and incentives of a wide network of ecosystem players that participate in open banking.
Monetising APIs in Open Banking
These benefits enable open banking APIs to be monetised in five different ways. Note that local market dynamics and regulations may impact the applicability and attractiveness of these business models.
- The first way to monetize open banking APIs is by License or subscription revenue for data calls
- The second is via Channel extension of the legacy way of realizing bank product income (such as through transaction fees for payments, data or image retrieval, interest income for loans, benefit of new deposit balances from account opens, etc.)
- The third way is by revenue sharing across partners
- Fourth is through new product or service revenue
- Five is through monetising transaction data, for example, enriched information around a payment, while respecting customer data privacy restrictions
Use Cases of APIs in Open Banking
Use Case 1: Data Aggregation
The data in question here include account detail and transaction data, customer profile data and customer account onboarding data. With or without a push from regulators, the most common use case for customer account data aggregation has been to allow consumers and businesses to be able to view account information across multiple accounts and banking providers, to create a 360-degree view of their cash position, receivables, income and expenses.
Personal financial tools for consumers, as well as small business accounting and bank reconciliation platforms, offer the ability to collect, consolidate and analyze account and transaction information from multiple sources.
The ability to see and to act on finances from a single location puts customers in better control of their finances, improving their ability to manage cash flow and optimize savings and investing decisions.
Historically, for consumer use cases, these data aggregators were screen scraping the information from online banking websites. Screen scraping required customers to provide their online banking access credentials to the aggregator, and for the aggregator to log in on behalf of the customer, utilize an automated script to read the information online. As login requirements would change, or as site designs would change, these connections would break and need to be fixed by receiving new credentials from the customer and updating scripts.
Screen scraping meant the customers’ login credentials were shared with many third parties who may not have as high a cybersecurity management bar as a bank would, creating privacy, security and financial loss risks for the customer, and, for regions and segments where banks provide guarantees for online transactions, for the banks.
With open banking APIs for account aggregation, banks can provide a safer and more reliable way to provide customer account information to a set of aggregators they trust or are in turn trusted by a regulatory agency. They can also increase the type and details of data provided, making the aggregation services more useful for the end customer.
This API based model has to incorporate customer consent, whether for a one-time transaction, such as for a loan application, or for the duration of a service, such as for financial management apps.
Use Case 2: Payments
Payment networks across the globe have always relied on standards, but banks have built their internal payments processes and controls on proprietary systems and siloed technology stacks.
Historically, many banks have offered SOA based API payment processing and reporting integration solutions to their large corporate customers who needed to manage a large volume of payments across multiple payment rails. As these were custom integrations that required a technical project for both the bank and the corporate customer, they were more costly and could take months of development and testing.
The modern JSON based APIs reduce the cost and time to integration barrier dramatically, making it possible for much smaller businesses to take advantage of payment integrations with their banks, provided their bank is able to provide multiple payment initiation rails and all related services including account validation, payment status, returns, and reporting.
When most payment processing happened in batch, real-time payment APIs were less interesting. As of the last decade, there has been a global movement towards real-time payments. In 2019, there were 54 countries with real-time payment systems, which was an impressive increase of four times since 2014.
The advent of real payments will facilitate improved experiences for person-to-person payments, business-to-consumer and business-to-business disbursements, bill payments, and cross border payments.
They will spur innovation in instant credit applications, insurance and health care benefits reimbursements, emergency disbursements, cash on delivery use cases, daily payroll applications, and instant cross border payments.
Open banking payment APIs, in addition to ISO 20022 global payments standards, will spur migration of payments from cash to electronic, and from slower payment methods to real-time. In payments use cases, banks can generate transaction fee revenue through increased payment volumes.
Use Case 3: Value-Added Services
In the business and corporate customer segments, many customers have relationships with more than one financial institution. For receivables, disbursements, treasury and accounting applications, even in the age of modern APIs, integrating API based services from multiple banks is still very challenging for many businesses.
This recognition has created the need for an ecosystem to emerge that would facilitate easier connectivity between commercial customers, their banks, and their Enterprise Resource Planning (ERP) software providers. New integrators have emerged to facilitate bank and ERP integrations.
Imagine the efficiency for a business whereby adopting a single ERP system, they can manage all their bank relationships, run their cash management and get insights from their banks through one ERP system, with mostly automated payment flows.
Open banking APIs can facilitate such ERP integrations. This would change the nature of competition among banks (and among ERP systems), and it would force everyone to differentiate their offerings. As a result, economic benefits would accrue to all parties, especially, to the end customers.
In this model, banks can create incremental fee revenue from getting a larger share of the market, or a larger share of the customer wallet for transaction services. Conversely, incumbents may risk losing wallet share to fintech or other bank competitors who are more successful in signing partnerships.