This post is the second in a series discussing Open Banking, its implementations, and its implications.
APIs or “Application Programming Interfaces” are everywhere in ecommerce, and they provide the building blocks in the primordial soup of innovations that may stem from open banking.
Among other roles, APIs provide a protocol allowing one computer system to talk with another. For example, The Weather Channel (“TWC”) has invested heavily in providing detailed meteorological information and forecasts by region. TWC could conceivably require people to visit its website as the exclusive way to access this information. Instead, however, TWC permits some of its information to be accessed automatically across apps, websites, and services and in ways third-party developers can predictably map (e.g., certain tagged data reflects values like “75°F” or “Partly Cloudy”). TWC has determined such use advances the TWC business plan. Conversely, the developers of apps, websites, and services have determined using the TWC API is superior to reinventing what TWC has accomplished—or not offering weather information at all.
Without an API, a third party could create a bot to visit the TWC website and automatically “scrape” the information, but such an approach poses risks. First, even a slight change to the TWC website could cause the bot to misunderstand which data it is supposed to scrape. Second, such an approach raises contractual and copyright risks. See, e.g., Ticketmaster L.L.C. v. RMG Technologies, Inc., 507 F. Supp.2d 1096 (C.D. Cal. 2007) (granting injunctive relief on grounds that defendant infringed copyright and terms of use through automated screen-scraping of Ticketmaster’s site in order to facilitate its own large-volume ticket brokerage). Third, this conversion step fails to capture the richer, more reliable, and more on-point data TWC is willing to make available via its API.
An “open” API is one characterized by its free or low-cost availability to third parties and relatively standardized format. Google and Facebook each receive over 5 billion API calls each day, and more than 60% of eBay listings are added via API. Amazon Web Services (AWS) cloud storage capabilities are largely attributable to the ease of API integration and access.
In the same way, financial companies are developing APIs to use data across platforms. Various banks, through access points like those of Bank of America, Citibank, JPMorgan Chase, and Wells Fargo, provide APIs of financial data. Microsoft and Intuit announced the Open Financial Exchange (OFX) standard in 2007 that has been the basis for financial data to be transported from banks to other solutions, including Quicken software. Fintech Stripe’s payment gateway APIs have made it a developer-friendly industry giant. For the recipient of the API data, using APIs avoids the problems posed from scraping data from a financial institution’s customer portal.
In the fintech space, an “API” often refers to an interface to exchange data, yet from a historical standpoint, APIs have also referred to the development of routines by software programmers. In this setting, APIs may be used as part of a software development kit (“SDK”). The Java library is one of the most famous public APIs that allows programmers to use previously established routines, such as opening a data connection, without needing to start from scratch.
The website ProgrammableWeb tracks more than 20,000 publicly available APIs; even more are maintained privately or subject to confidentiality agreements. Most public APIs were developed by their distributor, others were developed by industry groups, and a fraction were developed in response to government requirements. Through these APIs, financial information, federal government data, patient electronic health information, and other information and services can be accessed, pursuant to the terms of use imposed by the licensor.
Using APIs carries risk—almost inherently. Rarely does any meaningful period of time go by in which flaws in APIs expose customer data and/or transaction histories. According to HIMSS, healthcare APIs risk exploitation through denial of service, cookie tampering, and man in the middle attacks. Disputes over API rights have also led to billion dollar claims between corporate giants.
Critically, APIs are merely the building blocks of open banking. The nature of data provided is up to those financial institutions and others who provide the API. How the data will be used is up to the creativity of entrepreneurs and their customers. In our next posts in this series, we will explore the current legal and regulatory implications of open banking innovation.
[View source.]
