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.

APIs made available for free may be provided pursuant to “licenses” or may alternatively be provided pursuant to a “terms of use” document that sets forth the conditions under which use is permitted. Under either approach, if the user refuses to accept the terms, then use is barred. APIs made available for a fee may also be governed by “terms of use” but these terms may be negotiated as a license or service agreement. There, traditional assumptions about bargaining power often play out, with the dominant players typically demanding conformity.

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:

• Can the API be used for a commercial purpose? Are there other limitations on the use of the data or specific information security requirements?
• Is there a warranty?
• Is there a non-indemnified risk of infringing another’s IP rights?
• Does the user owe indemnity to the API provider?
• Is there a right to track how the API is used?
• What license does the API provider receive in any data given to it?
• Is a severe copy-left license (e.g., AGPL) used that would infect other software?
• Is there an acknowledgment of the provider’s rights to the API and its implementations?

Let’s take a closer look at how these key issues are negotiated in API terms of use or license agreements.

Privacy and Data Security

In our previous post in this series, we noted privacy and data security as key regulatory interests in open banking. Not surprisingly, these provisions are often the most extensive and most heavily contested of current API license terms. Providers may insist on high threshold levels of encryption that exclude widely used technologies as insufficiently secure. Under some scenarios, providers may demand adherence to certain industry standards and the availability of third-party compliance attestations, such as SOC-2 or SOC-3 (and, further, Type I or Type II) reports. Conversely, users, particularly those paying a fee, may insist on certain guarantees if they will be relying on the data in facilitating financial transactions.

From a corporate policy standpoint, the provider may demand guarantees concerning the humans who will interact with the data. For example, although the provider can always block access to the API, the provider may further limit the number of licensed human users to an authorized list or require training of those human users.

A common restriction is that the API be used for non-commercial purposes or only for specific purposes. These restrictions may be driven by regulatory compliance considerations (such as the Gramm-Leach-Bliley Act’s exceptions for service providers) or by the provider’s paid licensing model. Failure to abide by these requirements may subject the user to liability for damages. If the API use was voluminous and/or over an extended period of time, this exposure could be significant. An API provider may seek some way to confirm the true purpose of the use, perhaps through audit rights.

For financial institutions partnering with service providers, these data sharing safeguards are familiar ground as a contracting matter. However, together with evolving privacy considerations, the variety of prospective bank API users presents special challenges for banks seeking to apply traditional vendor management principles to these partnerships. This is because, among other reasons, these users may not be interested in playing a traditional bank service provider role. Instead, even if they do so through the bank, they may want to engage directly with a bank’s consumers using their own brand and product offerings. As a result, contract terms designed for pure service providers are not appropriate and may defeat both parties’ interests in partnering. This tension would be even more pronounced in an environment where consumers themselves are able to direct a bank to share data with third parties.

In addition, whether for compliance or business purposes, bank providers have interests in users’ own data as part of their receipt of an API feed. An API provider will likely log what requests were made for information from its servers and by whom. Sometimes, the terms of use may expressly disclose how such API calls are tracked; in other circumstances, the tracking may be described in a separate privacy policy. In any setup, there is a risk that a user’s confidential information may be exposed in the course of requesting information through an API. For all of these reasons, API providers and users should have a clear understanding of user data sharing rights and responsibilities.

Intellectual Property Ownership and Indemnification

A bank or other provider’s incentive to give a warranty for reliance on an API is reduced when the provider receives nothing for the API. At the same time, API feeds expose users to risks beyond the feed’s interruption or downtime. First and foremost, just because a business receives data through an API does not mean that API was a valid means of transmitting that data. The API could be implemented in a way that (unwittingly) results in a user’s infringement of patent, copyright, trade secret, or other rights, or the API may violate other contractual rights. For example, a photo sharing site may entitle users to download photos via an API, but if a photo’s original poster was infringing another’s copyright, then the subsequent downloading of the photo by another may expose the downloader to infringement liability. This risk makes understanding the assumption of risk critical.

There are also circumstances in which a user’s content or other data will be submitted to an API or where the use of the API will create data. Some API providers may fear a copyright or other claim if the user does not license the submitted content to the provider. Frequently, however, such licenses are broadly written to cover future contingencies, and the language may have broader ramifications than the API provider or user initially intend. For example, if the API facilitates user comments to a website, the API provider’s requesting assurances that it can post those comments without fear of copyright infringement could be reasonable; however, a license extended to all user content generated by the service might produce unintended consequences if a financial strategy or account information is captured.

Given the ambiguity in current case law over whether an API is copyrightable and motivations in some sectors to treat data transferred as a protectable property right, an API provider may seek an acknowledgement that the provider owns the API and the implementation behind it. Further, the API provider may seek to restrict the development of an independent implementation for the API.

As the U.S. “open banking” approach evolves through private innovation, APIs will play a role.  API providers and uses taking care with key licensing terms should be better positioned to navigate this evolving market trend and what the future may hold.

[View source.]