Demystifying Open Banking- Part 1
Chances are your favorite industry trade publication, newsletter, or blog (we’re glad you are here) has talked about open banking. But the term open banking often gets confused with open finance. For simplicity purposes, open banking is about the “open” sharing of data between financial-based service providers. And that data will likely include balances and transaction history, to name a few. Instead of having disparate transaction histories at multiple financial services providers, opening banking enables all that data to be SECURELY consumed into one presentation. In other words, the user will be able to log into the financial services provider of their choice and get a full 360-degree holistic view of their finances from all their financial services providers. This premise turns the traditional definition of primary financial institution on its head. We are really talking about primary financial “provider,” whether that be a traditional financial institution or a new entrant into the financial services vertical. It is the financial services providers that have data, analytics, and user-friendly presentation layers that will win the business.
If the system is broken, replace it
Before the open banking model, account owners could see some of their financial services information among their various providers. Data sharing was accomplished via “account aggregation.” On the surface, account aggregation and open banking appear similar. But there are some inherent flaws with the account aggregation model. The first flaw is the data access model. Account aggregation uses a process called screen scraping. Think of screen scraping as a cut-and-paste function to get data from one system to the other. For the screen scraping system to work, it needs the end user’s credentials to access the information. This poses a risk to the financial services provider systems’ security since the credentials the end user created to block unauthorized account access are freely provided to the financial services providers scraping the data. And, to make matters worse, those credentials may be stored in the screen scraper’s data systems. Instead of just capturing the data, screen scrapers have to capture the entire screen, which creates a system bandwidth burden on the financial services provider being scraped. Screen scraping can also degrade the financial services provider’s system performance. The only way to keep the aggregated information up to date is to log into the end user’s account continuously.
Additionally, the screen scraping process often breaks. If there are any format changes to the website or access page used by the screen scraper to acquire the data, the link is broken. Finally, there is the issue of who chooses to cooperate. Just because an account owner requests access to their data does not mean the financial services provider is obligated to provide it. In fact, many financial services providers have opted to block requests from other financial services providers as a competitive strategy.
The API direct connection
The answer to thwarting many of the security issues proposed by the screen scraping methodology is the use of application program interfaces, or APIs for short. An API establishes a direct connection between data sources. The API transfers data between the sender and receiver without the need to download any additional page information associated with screen scraping. When an account owner provides their credentials to access another system, their credentials are tokenized, creating an anonymized key used to access that system. The account owner’s credentials are never transferred and never stored. If the account owner’s credentials are compromised, their token can be disabled immediately. And tokenization is beneficial at the institutional level as well. If a data breach occurs at a financial services provider, all the tokens associated with that provider can be summarily terminated. It is better to destroy the hive than swat the bee. The other safety aspect of APIs is that they require coding between the parties. There is no guesswork involved with who is trying to access the data.
Account owner control
All of the technology is fun to discuss (think about how you will amaze them at your next social event). Still, a fundamental reason for open banking is enabling the account owner to have complete control over with whom and precisely what information is being shared. Many aggregation processes follow the all-or-nothing rule. If the account owner gives their credentials to a financial services provider, that provider can access all of their account data by scraping the screens. Take, for example, the typical account balance screen in most digital banking platforms. That page contains all of the accounts/loans and their respective balances. The account owner has no control over what products and their respective balances are given to the requesting financial services provider.
On the other hand, open banking was designed to control data information sharing at the product level. Take, for example, an account owner with a checking, savings, and money market account at provider A. When provider B requests the information, the account owner may decide only to share the information for one product, such as the money market, but not all products. The account owner is in total control of what is being received by the requesting provider.
Are you open to the present in the Future
Open banking, aggregation, screen scraping, and application program interfaces. What a mouthful. And yet, all of this can really be summarized into a few concise thoughts. 1. Account owners want control of their information and decide with whom they will share it. 2. Account owners expect their information to be exchanged using a secure direct provider-to-recipient process. 3. Open banking creates a competitive landscape where financial services providers can compete for the business. Open banking mass adoption is not a question of how but when. Whether or not you participate in open banking may determine your present and future.