Jun 30, 2020 7 min read

How Is Open Banking Being Implemented Around The World? (3/4)

Table of Contents

This is the third part of our four part Open Banking series written by Aaryaman and Lars. You can find the other parts here: one and two.

As discussed in the previous segment, there are many ways a developer or service provider can access a user’s banking data. The two most popular and frictionless ways to do this are via screen scraping and reverse engineering of a bank’s mobile APIs. Plaid built its $5bn data aggregation business on the back of these two technologies, while newer competitors like Tink and Teller have raised lots of money to innovate on reverse engineering of APIs. All of this points to a great future for these data aggregation methods, but the truth is that both of these techniques share some drawbacks. 

Screen scraping, in particular, requires a developer to build a separate HTML scraper for each webpage of a bank’s website. This can be a painful and laborious process. In contrast, reverse engineering of mobile APIs returns data to the developer in a neat, structured format that doesn’t need much processing or cleaning. That being said, reverse engineering APIs is also a hacky technique that exploits a bank’s interface in unintended ways. This makes it prone to breaking often. If a bank changes the authentication certificate inside its app, the reverse engineered APIs won’t work until the corresponding certificate is also updated. Similarly, any changes to the bank’s mobile banking API specifications will also cause the data fetch to fail or behave erratically. This means that companies that employ these techniques must spend a lot of time maintaining and checking their systems; they are “out of the loop”, so they will never get a warning from the banks about an imminent HTML or API update. 

In addition to the maintenance overheads of these techniques, there are also concerns around performance. Scraping through all of a webpage’s HTML just to get a few relevant tidbits of data can be an inefficient and time consuming process. Similarly, a bank’s mobile banking APIs are not necessarily designed for data aggregation: they are designed to show data on a user’s mobile phone. This means that the APIs will have characteristics such as small pagination – basically the API will return data in bite-sized packets optimized for a mobile phone screen, requiring the developer to make multiple requests or adjustments in order to piece together an aggregated view of the data suitable for something like a loan application. 

HTML code can be painful to parse through and process

Beyond just reliability and performance, the biggest issue with these methods of data aggregation is privacy. In order for these techniques to work, the user must share their banking login and password with the data aggregator! The data aggregator then uses these credentials to basically impersonate the user. This is a deeply uncomfortable idea for many individuals who would rather not give various data aggregation companies access to their life savings.

In contrast, “official” open banking flows can lead to a more secure end-user experience (official flow meaning something in which the bank is in the loop and offers built-for-purpose APIs, as opposed to an aggregator cutting out the bank by finding hacks to get the data off the bank’s user interface). Consider the case of India, which is implementing a system known as the Account Aggregator framework (AA). As per the flows specified by this framework, users are not required to share their banking credentials. Instead, users must create accounts with specially certified Account Aggregators (these could be mobile apps or web apps). These licensed AAs, as they are known, allow users to discover their existing financial accounts (be they bank accounts, stock trading accounts, insurance accounts, or taxpayer profiles). The account linking flow in the AA system is illustrated in the diagram below (for a detailed explanation of the Account Aggregator in India, including a breakdown of its potential, users can read Aaryaman’s blog on the topic).

AA users can link their accounts and get access to their data without revealing banking passwords

As shown in the diagram, users are able to link with and access their financial accounts without revealing their netbanking credentials to anybody. Similarly, the user authentication flows in Europe’s PSD2 open banking regulation allow for i) service providers to redirect the user to a bank webpage for authentication ii) the bank to embed a secure authentication module inside a third party app’s interface iii) a licensed entity to collect the user’s credentials and securely pass them to a user’s bank for authentication (which is not too dissimilar to the process in scraping, except in this case the credentials are shared with a licensed entity and the bank gives the data back via official APIs).

 The Account Aggregator approach in India (Source: Sahamati)

In addition to increased security for users, the use of official APIs can also result in more convenience and reliability for consumers of data. For one thing, the data itself comes from the source, oftentimes with a verifiable digital signature. This brings down the cost and burden of verifying the data. Secondly, the official APIs come with documentation and maintenance from the banks, so consumers of the data are in the loop about changes or outages to the APIs (although one must concede that some of the bank APIs in the EU and UK are unreliable and uninspiring). Lastly, the APIs might allow for richer functionality than what scraping or mobile APIs allow. For instance, the AA framework in India specifies standardized schemas for more than 23 kinds of financial assets including bank accounts, credit cards, equities, bonds, mutual funds, insurance policies, tax returns, and electronic invoices. The consumers of these APIs know exactly the format in which they will receive the data; what’s more, the AA API specifications allow for data consumers to ‘query’ the original data. This means that users can instruct their bank to only share select information with the data consumer, rather than just sharing it however it is presented on the current mobile/web banking interface. Some examples of this query functionality include “confirm whether average balance over the last 6 months < 5000” and “share only transactions made with Domino’s Pizza”.

Ultimately, official open banking APIs speak to the idea that the data lying inside the user’s bank account belongs to the user herself. The user gets direct access to her data, rather than having to use some hacky workaround. Furthermore, regulatory clarity and licensing programs can actually help drive up the trust-factor and legitimacy of data aggregators; users feel secure knowing that there is some legal oversight and dispute redressal mechanism for them to rely on in case things go wrong. For all these reasons, one can argue that official standards and regulations for open banking result in better outcomes for both users and service providers.

Having said that, enforcing open banking regulations can sometimes result in chaotic and unhappy market conditions. In Europe, for example, the regulator’s attempts to get all banks on board a common open banking standard seem to be failing. Multiple banks have completely missed the deadline to offer official APIs, and some of the banks who have implemented the necessary APIs have done a terrible job. As a result of this patchy and inconsistent enforcement of the regulation, many data consumers and account aggregators are still using old interfaces as the APIs do not provide the same depth of data or have other limitations.

Although the inconsistent implementation of official APIs is currently causing some problems in the EU and the UK, there are some positive signs. In January 2020, authorities in the UK announced that the number of Open Banking users in the country had passed the 1million mark, doubling in a period of 6 months. As time passes, this number is expected to rise significantly. In tandem, one hopes that the convenience, security, and ease of using the official APIs rises as well.

Status of Open Banking around the world (Source: Open Banking report from Platformable)

Just as Open Banking is taking off in the UK, it is also being implemented in several other countries. As stated earlier, India is implementing an ambitious open banking initiative called the Account Aggregator framework. This initiative will unlock all kinds of financial data, not just payments accounts data (as is the case in the EU and UK regulations). In similar fashion, the central banks of Brazil and Australia are also enacting innovative and progressive open banking reforms. This graphic illustrates some of the efforts underway in various countries.

Progress of different countries in Open Banking regulations (Source: Open Banking report from Platformable)

Given the momentum of this banking movement, and the truly groundbreaking potential of opening up critical data that has hitherto not been properly harnessed for users’ benefit, don’t be surprised to see open banking regulation come to your jurisdiction soon! In the meantime, in the absence of official APIs, one could always use other data aggregation methods to access users’ financial data. In the next and final segment in this blog series, we will talk about all the different business models and use cases that can be built using open banking data!


This series consists of four parts:

Part 1: Data Empowerment, Data Protection, and the Need for Open Banking

Part 2: How Did Open Banking Come About And How Does It Work?

Part 3: How Is Open Banking Being Implemented Around The World?

Part 4: Use Cases And Business Opportunities Stemming From Open Banking

Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Lars Markull.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.