How did open banking come about and how does it work? (2/4)

This is the second part of our four part Open Banking series written by Aaryaman and Lars. You can find part one here.

Before getting into the rise of open banking, it is important to understand the definition of the term. Internationally, the term “Open Banking“ refers to the technique of connecting with a bank account and consuming some of the data that lies within. Like many terms in technology, open banking has become a buzzword and is unfortunately often misunderstood. Especially with the rise of Banking-as-a-Service many people are not sure where to draw the line with open banking. Banking-as-Service describes the method where core banking functionality, such as account or card creation, is made available for third parties. Uber or Grab offering bank accounts and debit cards is built on top of banking-as-a-service providers. To further complicate matters, open banking is not just being used as a term to describe a certain trend but also as the official term in the United Kingdom for a special kind of regulation forcing certain banks to open their infrastructure.

In a nutshell, open banking refers to any technique that enables you to access your bank account without logging into the online or mobile banking interface provided by your bank. You may know this from your Facebook or Twitter account, where you can see posts and tweets embedded in other sites or when you can send posts and tweets from a third provider such as Buffer or Hootsuite without actually being on Facebook or Twitter’s interface. This works in similar ways in banking. Instead of logging into the banking product provided by your very own bank you can use a third party service and do exactly what you would have done in your bank powered product. 

One might ask – why should you use a third party provider instead of the bank product? Well, third party providers are often able to provide a better experience because they can focus on a certain target group or product vertical, as opposed to building a multifunctional platform for the masses like a bank does. More and more, banking and payment activities are becoming part of other services such as loan applications, e-commerce shopping, and insurance claims. This whole trend is described as “embedded finance“, where banking and payment features get embedded into products of other industries. Open banking can be considered the first step of making this a reality, as it allows data from a bank account (such as holder name, account number, average balance, transactions and more) to be accessed and read within other applications.

Now that we are clear on the definitions, we can dive into the story of how open banking unfolded around the world. Probably the first provider of open banking services on a big scale was the US company Yodlee (now part of Envestnet). Yodlee was founded in 1999; since no other technical method of extracting data from banks was available at that time, Yodlee relied on screen scraping to access their customers’ accounts. This means that Yodlee took customer’s electronic banking credentials and used them to log into the customer’s bank portal. Once inside, Yodlee could employ bots to read the data in the account off the screen (not literally, the screen scraping bot would be programmed to read the relevant data out of the HTML code that constituted the actual web page). Obviously, banks did not like the fact that an upstart company was swooping in to take what they felt was their property. Information about a customer’s cash flows, spending habits, salary, and debts were (and still are) extremely valuable to the bank. All those data points are critical in helping a bank underwrite, price, and cross-sell products to customers.

Predictably, the US banks grew fed up and tried to sue Yodlee, but unfortunately for the banks, their legal efforts didn’t bear fruit. Not to be rebuffed, some banks reverted to a cat-and-mouse game; according to industry insiders, these banks started to make many minor changes to the banking frontend that were impossible for the human eye to detect, but were meant to break Yodlee’s screen scrapers (which had to be reprogrammed every time there was a change to the HTML code on a page). This caused great frustration, but did not prevent Yodlee from going on to become a major force in the US banking industry. They helped provide banks, finance companies, hedge funds, and other companies with financial data of consumers at a time when it was difficult to access.

Since then, screen scraping has fallen out of fashion as the main technique for extracting information from banks. Although screen scraping was convenient because it required no permission from or contract with the bank, it also had its own set of problems. The main problem was that bugs or breaks in the scraping algorithm were very difficult to detect until it was reported by users. This is due to the small changes in the code referred to in the previous paragraphs. Another problem with screen scraping was that it was very laborious. In order to build a scraper for a page, you would first need to analyze and break down all the HTML on that page. There can often be a lot of code to parse through until you find the tidbit you want. It is then necessary to do the same thing for every different web page you come across! And all of this can break with just a small code change on the part of the bank! Just look at one example of the HTML code on a Twitter timeline. Screen scrapers need to get through all that code just to extract the name of the Tweeter! No wonder screen scraping fell out of fashion. 

Screen scraping was replaced in some parts of the world by reverse engineering techniques. These two techniques share many similarities: for one thing, both techniques require the users banking credentials. In the case of scraping, the credentials are used to log in to a bank’s internet banking webpage. In the case of mobile reverse engineering, the credentials are used to communicate with the bank’s mobile app APIs. This is only possible in cases wherein the bank has built a mobile app. In order to enable reverse engineering, a company or developer must first decompile and analyze a bank’s mobile banking app. The application itself will contain some kind of certificate used to authenticate the app user with the app server. Once discovered, this certificate can be used to authenticate any request sent to the bank’s mobile banking server. Furthermore, by routing the bank’s mobile app traffic through a proxy, developers are able to further analyze the format and structure of the mobile banking APIs. After deciphering the API format and the app certificate, developers can access the bank’s mobile banking APIs from within their own applications. When given the right parameters, there is no way for the bank to tell that the request is not coming from an actual mobile banking app, so the bank returns all the banking data in a nice, clean format. There is no painful HTML to parse through, all the data just comes out of the API. 

Before the rise of mobile banking – and therefore, reverse engineering of mobile banking APIs- screen scraping was for the longest time the only way to connect to banks. However, in some countries, there were also other technologies available. One country is Germany, that we would like to highlight here. The German banking landscape is very fragmented and the savings bank organisation („Sparkassen“) faced a special challenge with the rise of PCs: the organisation consists of more than 400 local banks and many of them were too small to develop their own software to empower their customers to use computers to manage their bank accounts. The idea for „Home Banking Computer Interface“ (HBCI; now known as FinTS) was born. Every savings bank had to make their bank accounts accessible via HBCI and in return they could outsource the software development to a newly founded tech subsidiary. Other banks in Germany adopted the same approach and since HBCI is an open protocol, this enabled third parties in the year of 2000 to access bank accounts in Germany without using screen scraping. The big rise of this technology happened a few years later, when desktop and mobile banking became even more popular after 2012, and especially, when newly founded account aggregators used the technology to empower various new Fintech services.

All these technologies were available to developers and third party providers in order to access bank accounts, even before the new, regulator-driven Open Banking trend materialized. Now the discerning reader might ask, why do we need more than this if third parties can access bank accounts via screen scraping, reverse engineering and in some countries even by a bank implemented open protocol? We will discuss the answer to this topic and also provide some examples of open banking regulation around the world in the third blog post.

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