This post is the fourth and final in a series discussing Open Banking, its implementations, and its implications. The start of the series is here, and all of the posts in the series are available here.
In the United States, “open banking” does not yet mean that bank account and transaction data can be freely accessed on standardized terms—though it may in the future. For now, those who allow financial data to be accessed through APIs can impose their own conditions on that access. As we have described in this blog series, without further regulatory invention, in the U.S. API access is principally a contractual matter. For these purposes, we will refer to “providers” as those making API data available and “users” as those intermediaries accessing that data in order to deliver services to consumers or other clients. Although bank partnerships are subject to established contract standards, we will focus in this post on key issues that arise specifically in the course of the API licensing and access process.
Gating Considerations for API Access Terms
Particularly when the API license is presented as a take-it-or-leave-it agreement, the terms are often written to protect the provider from any liability for an offering from which the provider derives no or limited direct financial benefit. Users that will be paying for access may do so on a “per transaction,” “per user,” or some other basis; when the user pays money, the user understandably has more leverage over other contract terms. Either way, prospective users need to consider at least the following: