Open Banking and Financial APIs: How to Integrate Your Company with the Digital Financial Ecosystem
The financial services industry is one of the most regulated sectors of the world economy. Bank secrecy, security terms, the lack of trust in technology, and strict regulations slow down industry development from the tech perspective. As result, the industry with its broad potential for digital development significantly underutilizes its opportunities, especially in terms of customer experience and data sharing. The open banking concept zeroes in on disrupting the current status of banking and improving nearly all aspects related to ownership, sharing, and utilization of customer data.
What is open banking and how is it related to bank APIs
The concept of open banking supposes that banks provide access to user financial data to players in other industries to 1) foster a competitive environment between larger and smaller companies and 2) improve customer experience. As users consent to share their personal financial data, banking institutions can distribute information via open application programming interfaces, or APIs for short, allowing third parties to leverage this data and create personalized services with a seamless user experience. For instance, users can integrate their existing bank accounts with third-party apps to conveniently track their expenses and follow their individual savings plans.
As we mentioned, the technology behind open banking is using APIs. An API is a set of functions which allow for sharing data and requests between systems, usually, in a controlled, secure manner. There are three types of APIs currently applied in finance:
- Internal APIs used for sharing data across internal systems and users.
- Private APIs that let banks exchange data with their partners.
- Open APIs (public APIs) that allow for sharing data with a wide group of users while providing limited access to information.
The open banking concept gained significant popularity after 2015 when the European Parliament adopted a new payment services directive known as PSD2. It obligates EU banks and the 9 largest banks in the UK to provide developers with access to customer data via open APIs. However, the general idea isn’t anything new. Such providers as Mint, Personal Capital, and Numbrs had been leveraging data from customer bank accounts before PSD2. These aggregators combined information from several user’ accounts to store all information in one place. Unsurprisingly, customers had to share usernames and passwords for each account with these aggregators making the whole system vulnerable to privacy risks. Early “open banking” projects were scraping data from shared sources, but the records were often incomplete and provided only a partial picture. These projects were difficult and expensive to support: If a bank decided to redesign its application, scraping became impossible. Open banking APIs solve that problem by providing access to standardized data in a secure manner.
Payment Services Directive Explained
So, what is PSD2? The Second Payment Services Directive (PSD2) is a legal framework that regulates payment services through the EU and EEA (European Economic Area). The directive supports innovation and development of an integrated payment market across Europe. The new regulatory document was adopted in October 2015. It was a logical extension of the original PSD, which was designed in 2007 to increase competition across the payment industry. The new directive is focused on making cross-border payments easy and secure.
PSD2 integrates open banking and APIs with the financial business industry ecosystem. Third parties can access customer bank account data, based on customer approval. It allows non-bank institutions to build value-added services on top of the banking data and ecosystem. The regulation adds two new roles to the industry landscape:
AIS or account information service: an online aggregator which consolidates data from several customer accounts.
PIS or payment initiation service: a system that allows for managing funds and initiating payments on a customer’s behalf.
This way, providers can receive holistic user data and initiate financial operations after a user consents to such actions.
PSD2 came into force in January 2016. In November 2017, the European Banking Authority released the final version of Regulatory Technical Standards (RTS), which defined general requirements for APIs and guided the implementation method of PSD2. Each country in the EU had to integrate the directive into local legislation by January 2018. By now, two important milestones are yet to be reached:
- Banks must suggest open APIs to third-party providers for integration and testing in March 2019.
- All open banking APIs must be ready for implementation and meet the RST by September 2019.
Neither banks nor third parties are fully satisfied with the current process. There are many challenges for implementation such as security issues, usability, and access to data. If the merchants fail to prepare APIs in time, they will have to consider an alternative way to access customer data.
Open banking has both positive and negative possible implications for banks
Tight deadlines force banks to work faster on API preparation and innovation in customer-facing technologies. And slow movers risk losing their market shares in Europe. Another potential threat is losing interaction points with end customers. In this case, traditional banks may transform into faceless utility providers. However, those bankers that successfully meet the requirements will eventually improve user experience in customer apps and gain competitive advantage.
Open banking opportunities and benefits
Ultimately, all parties in the financial value chain can benefit from digital transformation opportunities offered by open banking. Someone may disagree and argue that open banking is a threat to traditional industry incumbents because traditional institutions have to share customer data and lose the exclusive right to it, despite the fact that this information was gathered and stored for decades. This is definitely a great risk for brick and mortar players, but at the same time, it encourages them to innovate. Let’s have a look at how the major stakeholders will benefit from the open banking initiative.
Better user experience. The banks will improve customer experience and enhance distribution across digital channels. Open APIs let banks easily integrate their services with third-party platforms, apps, and products. Open banking also makes cross-border expansion easier.
Lower operational costs. Another benefit is cutting operational costs, as banks can spend less time supporting foreign subsidiaries providing some services directly from the home market.
Higher competition. Customers will benefit from increased competition in the financial industry as prices will go down and service quality will go up. For example, customers will be able to use financial services aggregators to compare offers from banks and other institutions. They’ll also get remote access to a number of products that used to be available in branches only.
Added value from third parties. Third parties can access banking data, allowing them to design new products, innovate, and create additional value for bank customers. As trust in non-bank payment providers grows, open banking provides such companies with a number of opportunities in the financial services market.
Agile organizations will enjoy the major benefits of open banking (PSD2) implementation across the EU. The biggest potential winners are fintechs, according to McKinsey assumptions. An important implication is that IT service and telecommunication companies will also be among the winners. Bankers are ready to engage with external service providers to reach open banking compliance, as developing sophisticated transformation projects within tight deadlines will likely require external expertise.
Open banking API standards and specifications
Standardization and specification are critical for the development of public bank APIs. (a common tech standard for APIs) provide developers with relevant guidance on this topic. Though developers usually follow the general REST practices, they still may introduce quite different implementations for the same type of APIs. This lack of standardization will require customizing interfaces and systems for each API independently. This inconsistency can be eliminated by applying the guidelines from bank organizations and consortiums such as in Germany. Deep standardization reduces entrance barriers for fintechs and others.
How to implement public APIs in bank operations
Implementation of the open data concept requires a lot of engineering work. We’ve considered several recommendations on open banking strategy implementation:
The environment is highly competitive; the right strategy will allow for a timely turnabout
- Identify a strategic goal of open banking implementation. There are multiple service domains (e.g. payments, finance tracking) and finding the one to focus on will allow for incremental and gradual development with minimal risks.
- Prepare to be in both roles – that of early adopter and follower. The environment is very competitive: Banks develop different sets of APIs that may or may not turn out to be demanded by the market. You should prepare a mechanism for fast hypothesis testing and scaling up successful projects while killing the rest. This means pioneering in some implementations and following a well-worn trail in others.
- Clarify the goals. Evaluate the impact of each open banking API implementation in your institution. These may be additional revenue, increase in market share, geographical expansion, etc.
- Assess the data reserves across the organization. A financial institution should conduct a data audit to determine which types of customer data is available for internal and external utilization. The bank should also assess the data potential for machine learning and other analytic approaches to improve fraud detection, credit scoring, pricing, and cross-selling.
- Prepare the product development strategy for each open API. Banks should prepare a data management system, make appropriate changes to enterprise software architecture of internal systems, check compliance with legislation (e.g. PSD2 for the EU banks), etc.
- Choose the right means for project delivery. A financial institution can build a completely custom API or utilize a semi-ready solution by such providers as Open banking project. Even the implementation of a semi-ready solution requires a lot of engineering work, so it might be reasonable to choose a reliable technology consulting partner to support the software engineering part of the project.
- Prepare to build a partnership ecosystem. Cooperation with third parties allows banks to create value-added services, increase customer retention, and gather additional customer data.
Examples of open banking and other fintech APIs
Nearly each bank in the EU will have a set of open APIs by 2019. Currently, there are 529 results for query “bank API” on the ProgrammableWeb. But the real number is much larger and it isn’t limited to EU-based institutions. There are numerous financial API providers, so we won’t pretend that we show the most comprehensive list of bank APIs that comply with the open banking concept. Some banks fail to provide well-prepared documentation and information about pricing, which made the selection of examples more difficult. So, we’ve curated some of the most relevant examples.
Payment and Account Data APIs
Bank of Cyprus APIs. Bank of Cyprus (BOC) is the largest merchant group in Cyprus and operates over 120 branches across Europe.
- Geography: Cyprus, Russia, UK, Romania, Greece etc.
- Audience: N/A
- Functionality. BOC APIs provide access to account information, allow making personal payments through SEPA/SWIFT, grant access to corporate payment, and create subscriptions with customer approval.
Barclays APIs. Barclays is one of the largest and oldest banks in the UK. It operates via 4,750 branches worldwide. The bank targets four core segments: retail banking, corporate banking, wealth management, and investment management. Barclays provides a wide set of APIs for developers. Additionally, the company launched Barclays API Labs, which facilitates the testing of innovative APIs in the products and provide feedback to Barclays.
- Geography: 55 countries (UK, USA, France, Brazil, India, China etc.)
- Audience: N/A
- Functionality. Barclays APIs allow managing authorization, initiating payments, retrieving account and transaction information, resaving customer card information, sourcing product details, checking ATMs and branch location.
BBVA APIs. Banco Bilbao Vizcaya Argentaria (BBVA) is the second largest merchant group in Spain, which operates across the EU, UK, and USA.
- Geography: 30 countries (EU. Argentina, USA, etc.)
- Audience: 15 million clients
- Functionality: The bank provides access to customer profiles, accounts, and card data. BBVA APIs allows initiating payments, customer and corporate notifications, getting access to business account information.
Deutsche Bank APIs. Deutsche Bank is one of the largest universal banks in the EU. The company offers a wide range of payment-related APIs. Nevertheless, currently, they are focused only on informational functions only. Deutsche Bank APIs are free at the development phase and charged after the launch with startup and corporate pricing plans.
- Geography: 58 countries (EU, USA etc.)
- Audience: 27 million private and business clients
- Functionality: Deutsche Bank provides developers account information, customer profile data, customer transaction notifications, and credit card details via the following APIs
Lloyds Bank APIs: Lloyds, Bank of Scotland and Halifax. Lloyds Bank is one of the four largest banks in the UK, which operates in both the retail and corporate sectors. Lloyds Bank owns two large banking brands – Bank of Scotland and Halifax. Three of these institutions provide the same API offerings:
- Geography: operating in over 58 countries.
- Audience: 21 million clients
- Functionality: Banks provide third parties with account information, allow making payments, and retrieve ATM and branches locations.
Citi APIs. Citibank is a consumer-oriented division of Citigroup. The bank operates via 2,700 branches globally. The core service portfolio includes credit cards, personal loans, mortgages, and commercial loans. Though the bank is widely established beyond Europe, it actively adopts open banking concept in its operations. The Citibank APIs have already become an important part of Intuit, Qantas, and MoneySmart products. Note that different APIs are available for different regions.
- Geography: 19 countries (USA, Mexico, UK, China etc.)
- Audience: 200 million customers
- Functionality: Citibank provides developers with authorization features, retrieves customer cards and customer information, allows money to be moved across accounts, resets ATM PINs, makes payments for Citi customer reward points, and grants access to the set of valid values, field properties, and validations applied in specific countries (It makes the multimarket development of the apps easier).
Nordea APIs. Nordea is one of the largest bank groups in Europe and operates around 1,400 branches.
- Geography: Nordic and Baltic countries
- Audience: 11 million private customers
- Functionality: The bank APIs retrieve customer account information and allow initiating payments.
Starling Bank API. Starling is a young, mobile-only bank, established in 2014.
- Geography: the UK
- Audience: 200,000 current accounts
- Functionality: The Starling Bank API retrieves information about cards, accounts, saving goals, and transactions; allows making payments; and manages joint accounts etc.
Danske Bank APIs. Danske Bank is one of the major banks in Northern Europe. The API services are free within the default plan, which is limited to 100 payments per hour. The institution supports quite a limited set of payment APIs.
- Geography: Northern Europe
- Audience: 5 million customers
- Functionality: Danske Bank APIs allow for managing customer subscriptions, sending invoices directly to Danske Bank customers, and testing connection and authentication with Danske Bank services.
Banks gradually expand beyond mainstream open APIs, such as payments and accounts. Lending APIs allow for making express credit scoring, retrieving loan pricing, applying for a loan, sending files, sharing credit history, making payments etc. For example, eCommerce platforms can support sales with consumer credit. Here are several institutions providing such APIs:
Deutsche Bank provides developers with 2 APIs: CustomerSolvency and TransactionCertificate. The former shares a customer’s credit score, checking the customer’s creditworthiness; the latter retrieves a salary certificate if approved by the customer.
BBVA offers two lending APIs. The Loan API allows for remote processing for loan pre-approval. Third parties can get information about a customer’s ability to borrow money from BBVA. The service is currently available on the Spanish market only. The Auto Loan API automates applying for an auto loan on the Mexican market.
The onboarding API from Citibank lets third parties integrate account opening functions with the application products, send applications for screening, submit a new application for products, provide supporting documents, and check the application status. Currently, it allows for applying for an unsecured loan via a third-party application.
Investment and Wealth Management APIs
Large bank groups usually provide a wide range of financial services aiming to be a one-stop-shop for their customers. As a result, a number of bank groups work on developing APIs for investment operations.
Saxo APIs. Saxo is a Danish investment bank with a strong focus on internet trading. Saxo provides third-party developers with access to the functionality of its own trading platform, which allows for integrating investment features. Currently, developers can use four APIs to:
- make direct market orders on 20 futures exchanges and over 33 stock exchanges.
- get notification of order creation, order filling, order canceling, margin calls, etc.connect with third-party software and applications to the Saxo platform to perform cash transfers, retrieve customer data, and create scope reports.
- automate filing and end of day reporting. For example, the customer can access the account status (contains Cash Balance, Value-Dated Cash Balance, unrealized P/L, the value of positions, margins) report via the third-party application.
Deutsche Bank announced an upcoming Investment API, which lets developers retrieve data about the current performance of a customer’s investment portfolio.
The group of APIs provided by fintech companies, which operate on the alternative market of paуment, lending, credit scoring, etc. A good example of such services is customer data aggregators. Such companies source data from several banks and provide it to developers on the basis of the open banking concept. Here are several examples of such information in the lending domain:
The most common financial institution offerings are payment related APIs, which facilitate initiating payments and receiving basic customer information like account and profile data. Currently, the widest spectrum of integration options is available on the European market as EU legislation obligates banks to comply with PSD2. While Asia and North America lag behind, local players also provide some open banking options for developers.
Lending and Wealth management APIs are less widespread. There are several reasons for it:
- such options are not obligatory for banks, according to PSD2
- lending and wealth management are more sophisticated and less frequently used services than payments
The situation may change dramatically in the foreseeable future as more banks will add these services to the value proposition. These offerings provide banks with an opportunity to upscale and significantly enhance distribution. For instance, we should expect banks to offer consumer loans directly at eCommerce marketplaces soon.
Other financial APIs might be a good option for developers who need to retrieve customer data from a group of banks or integrate with a bank that doesn’t provide an open API. This way, developers benefit from the one-stop-shopping experience provided by such consolidators, requiring them to integrate one API instead of ten.
How to choose the right financial APIs for integration
We’ve covered only a few examples of financial APIs available for developers. According to PSD2, nearly all banks in the EU will have to provide access to customer data via APIs. The open banking concept is also gaining popularity in Asia and North America, so the number of providers is growing fast. In addition, fintechs and non-bank financial institutions have also prepared a number of end-points for integration with third-party services. Developers have a wide range of options for integration. How to select the right financial APIs for integration with your software product? Our team prepared several tips on this topic:
- Determine the strategic goal of integration: improvement of customer experience, cross-selling, acquisition of additional customer insights, enhancement of fraud detection capabilities or something else.
- Make an audit of your CRM, select the most popular banks among your customers, then research which banking institutions are most popular among your target customers. It’ll help you shortlist financial institutions for further research.
- Evaluate the documentation. Look for elaborate documentation with FAQs. Some of the open APIs might be paid or have tech limitations, for example, the number of queries per hour.
- Check and analyze offerings from each provider in the shortlist. This will tell you if you can solve the problem by integrating several APIs. For example, if you want to get a transaction history to optimize your advertisement campaigns, check whether any shortlisted institutions provide such capabilities.
- Verify standard and legal compliance. Your developers should confirm the security standards of the selected API. The legal department should determine whether the process of data sharing meets the legislative requirements and prepare the process for getting permissions from the users.
- Consider several alternative scenarios for implementation. Your research may show that selected providers don’t have the appropriate API, so you have to consider alternative APIs or other features for implementation.