Insights / Financial Services Law Advisor
Open Banking, APIs, and Liability Issues
12.18.19
The concept of open banking has been around for much of the 21st century and has been instrumental in creating a host of new banking services. Open banking relationships provide consumers with more control of their financial data and allow traditional financial institutions to collaborate with fintech companies to provide greater access to innovative financial tools.
As summarized below, the method of enacting an open banking model for much of the century, however, has proven to be flawed. Fortunately, new regulatory guidance and technologies have allowed for the creation of new open banking models that provide far greater protections for consumer data and prove far more efficient for the financial industry.
However, implementing these new technologies is not without legal ramifications, which we explore further below.
This method involved a number of legal and compliance issues.
For one, this relationship method posed risks from a privacy and data security perspective. Consumers were asked to turn over financial institution login credentials, effectively placing the entirety of their sensitive financial records at the disposal of the data aggregator.
In addition to the privacy and data security concerns, this model likely violated financial institutions’ terms of service – namely consumers agreeing to not share their login credentials with third parties. This model of open banking was also resource-intensive and unreliable from a data freshness perspective.
That information will generally be shared with the aggregator through the financial institution’s generation of a secure token that provides the aggregator with a specific set of financial data. The token does not contain the consumer’s login credentials and is, therefore, much more secure than the screen scraping method.
In addition, the use of APIs allows access to only specific assets rather than the entirety of a consumer’s financial profile. Moreover, the generation of a token and the sharing of financial information in this manner does not appear to violate the terms of any financial institution participating in this relationship model.
Finally, this model is far less resource-intensive for the data aggregator and allows for the real-time updating of financial information, in contrast to the batch process utilized during the screen-scraping method.
In October of 2017, the CFPB expressed its own support for the use of API models by outlining a set of Consumer Protection Principles for “Consumer-Authorized Financial Data Sharing and Aggregation.” In publishing these principles, the Bureau pointed to the strong potential for data privacy and control gains for consumers in moving toward an API model.
These principles also recognized the need for continued focus on the potential for data security and privacy issues inherent to the development of any data sharing functionality. One of the potential issues discussed by the Bureau related to unauthorized access concerns triggered by a consumer’s sharing of financial services account credentials.
As discussed further below, unauthorized use triggers provisions of the Electronic Fund Transfer Act and Regulation E. Nonetheless, the Bureau used its 2017 Principles to bless the growth of API systems as a means of mitigating this and other issues. The use of APIs has skyrocketed in the financial sector in the past few years since the publication of these Principles, and the current administration of the CFPB has shown no desire to slow the growth.
One area of difficulty, however, has been the inclusion of smaller financial institutions into this new data-sharing model. Traditionally, only the largest of financial institutions have had the resources to implement new API functionality to work with aggregator and other partners to more safely share consumer data.
Fortunately, the increased popularity of API modeling has led to the creation of a more open-sourced approach to its development. For example, there now exists a “Model Data Access Agreement,” developed by The Clearing House, that helps to facilitate the implementation of API modeling for those institutions that have not yet built API relationships.
The Access Agreement is a standardized bilateral data agreement template that may be utilized by smaller firms to bypass some of the legal and compliance efforts required to negotiate such agreements from the ground up. Such innovations continue to drive financial institution, aggregator, and user preference for data sharing according to the principles of API and open banking.
Though the API model has led to gains in consumer privacy and the efficiency of open banking relationships, there remain important legal and compliance considerations for any financial institution implementing such a model. Below are two such considerations.
When the consumer provided an aggregator with her login credentials pursuant to the “screen-scraping” method, those credentials would have represented an “access device” under Regulation E – in other words, a “means to access a consumer’s account … that may be used by the consumer to initiate electronic fund transfers.”1 Where the consumer provided an access device to a third party, as when the consumer has provided credentials to the aggregator, Regulation E sharply limits the liability of the financial institution for unauthorized transfers. Specifically, a transaction conducted by a person who was given an access device by the consumer is only treated as “unauthorized” if the “consumer has notified the financial institution that transfers by that person are no longer authorized.”2
Using the API model wherein a financial institution provides an identification token to the aggregator, the financial institution would likely not be able to rely on the Regulation E carve-out noted above. A token would not be considered an “access device” under Regulation E as it cannot be used by the consumer or aggregator to initiate electronic funds. Liability, therefore, would be guided by Regulation E’s standard liability rules.3
Although tokens cannot be used to initiate funds transfers, and therefore there is a low likelihood of a related unauthorized transaction, further developments in API relationships may implicate liability rules. Many aggregators are now seeking to obtain access devices through API relationships with financial institutions in order to enable bill pay features and other functionality.
It is unclear in such a scenario whether a financial institution would be subject to the same liability carve-out that applies when the consumer herself provides an access device to an aggregator. Financial institutions would likely take the position that a consumer has provided an access device to the aggregator where she instructed the financial institution to provide login credentials to the aggregator on the consumer’s behalf.
Regulators, however, have not yet taken a position on this matter, and the situation is not contemplated by a 2017 ABA letter on the topic of Regulation E liability.
As summarized below, the method of enacting an open banking model for much of the century, however, has proven to be flawed. Fortunately, new regulatory guidance and technologies have allowed for the creation of new open banking models that provide far greater protections for consumer data and prove far more efficient for the financial industry.
However, implementing these new technologies is not without legal ramifications, which we explore further below.
Screen Scraping
The original method for implementing open banking relationships between financial institutions and data aggregators involved “screen scraping.” Using screen scraping, a consumer would be asked to provide her financial institution login credentials to a data aggregator, which would then use those credentials to log in to the consumer’s financial institution account on a periodic basis in order to obtain financial data that would ultimately be displayed on the consumer’s data aggregator account page.This method involved a number of legal and compliance issues.
For one, this relationship method posed risks from a privacy and data security perspective. Consumers were asked to turn over financial institution login credentials, effectively placing the entirety of their sensitive financial records at the disposal of the data aggregator.
In addition to the privacy and data security concerns, this model likely violated financial institutions’ terms of service – namely consumers agreeing to not share their login credentials with third parties. This model of open banking was also resource-intensive and unreliable from a data freshness perspective.
APIs
The newer method of conducting open banking relationships involves the use of APIs, or application programming interfaces. Using APIs, a consumer can give her financial institution the rights to share her information with a data aggregator.That information will generally be shared with the aggregator through the financial institution’s generation of a secure token that provides the aggregator with a specific set of financial data. The token does not contain the consumer’s login credentials and is, therefore, much more secure than the screen scraping method.
In addition, the use of APIs allows access to only specific assets rather than the entirety of a consumer’s financial profile. Moreover, the generation of a token and the sharing of financial information in this manner does not appear to violate the terms of any financial institution participating in this relationship model.
Finally, this model is far less resource-intensive for the data aggregator and allows for the real-time updating of financial information, in contrast to the batch process utilized during the screen-scraping method.
In October of 2017, the CFPB expressed its own support for the use of API models by outlining a set of Consumer Protection Principles for “Consumer-Authorized Financial Data Sharing and Aggregation.” In publishing these principles, the Bureau pointed to the strong potential for data privacy and control gains for consumers in moving toward an API model.
These principles also recognized the need for continued focus on the potential for data security and privacy issues inherent to the development of any data sharing functionality. One of the potential issues discussed by the Bureau related to unauthorized access concerns triggered by a consumer’s sharing of financial services account credentials.
As discussed further below, unauthorized use triggers provisions of the Electronic Fund Transfer Act and Regulation E. Nonetheless, the Bureau used its 2017 Principles to bless the growth of API systems as a means of mitigating this and other issues. The use of APIs has skyrocketed in the financial sector in the past few years since the publication of these Principles, and the current administration of the CFPB has shown no desire to slow the growth.
One area of difficulty, however, has been the inclusion of smaller financial institutions into this new data-sharing model. Traditionally, only the largest of financial institutions have had the resources to implement new API functionality to work with aggregator and other partners to more safely share consumer data.
Fortunately, the increased popularity of API modeling has led to the creation of a more open-sourced approach to its development. For example, there now exists a “Model Data Access Agreement,” developed by The Clearing House, that helps to facilitate the implementation of API modeling for those institutions that have not yet built API relationships.
The Access Agreement is a standardized bilateral data agreement template that may be utilized by smaller firms to bypass some of the legal and compliance efforts required to negotiate such agreements from the ground up. Such innovations continue to drive financial institution, aggregator, and user preference for data sharing according to the principles of API and open banking.
Though the API model has led to gains in consumer privacy and the efficiency of open banking relationships, there remain important legal and compliance considerations for any financial institution implementing such a model. Below are two such considerations.
Unauthorized Use Liability Issues
One of the key questions for financial institutions moving to an API model relationship with aggregator partners is where liability lies for unauthorized transactions. Under previous relationship models, wherein a consumer provides an aggregator with financial institution login credentials, the consumer was responsible for losses arising in the context of unauthorized transfers.When the consumer provided an aggregator with her login credentials pursuant to the “screen-scraping” method, those credentials would have represented an “access device” under Regulation E – in other words, a “means to access a consumer’s account … that may be used by the consumer to initiate electronic fund transfers.”1 Where the consumer provided an access device to a third party, as when the consumer has provided credentials to the aggregator, Regulation E sharply limits the liability of the financial institution for unauthorized transfers. Specifically, a transaction conducted by a person who was given an access device by the consumer is only treated as “unauthorized” if the “consumer has notified the financial institution that transfers by that person are no longer authorized.”2
Using the API model wherein a financial institution provides an identification token to the aggregator, the financial institution would likely not be able to rely on the Regulation E carve-out noted above. A token would not be considered an “access device” under Regulation E as it cannot be used by the consumer or aggregator to initiate electronic funds. Liability, therefore, would be guided by Regulation E’s standard liability rules.3
Although tokens cannot be used to initiate funds transfers, and therefore there is a low likelihood of a related unauthorized transaction, further developments in API relationships may implicate liability rules. Many aggregators are now seeking to obtain access devices through API relationships with financial institutions in order to enable bill pay features and other functionality.
It is unclear in such a scenario whether a financial institution would be subject to the same liability carve-out that applies when the consumer herself provides an access device to an aggregator. Financial institutions would likely take the position that a consumer has provided an access device to the aggregator where she instructed the financial institution to provide login credentials to the aggregator on the consumer’s behalf.
Regulators, however, have not yet taken a position on this matter, and the situation is not contemplated by a 2017 ABA letter on the topic of Regulation E liability.
Data Liability Issues
Though the API model allows for the much more secure transfer of consumer data, the act of sharing that data at all continues to necessitate strong data sharing and data accuracy policies. Though financial institutions would likely take the position that they would not be subject to the Fair Credit Reporting Act’s (FCRA) data accuracy requirements, it might behoove such institutions to adopt a policy based on these requirements.
In sharing data through an API model, the reliance on FCRA-compliant policies and procedures would send a strong signal to regulators that the financial institution has in place strong data security protocols. Additionally, data aggregators themselves often provide credit reports to lenders and may ultimately direct consumers to contact the financial institution about the accuracy of that information (which was provided by the financial institution to the data aggregator).
In such instances, having policies in place related to the furnishing of information with known errors or inaccuracies, the furnishing of information related to identity theft, the furnishing of information related to disputes, and policies related to investigative measures and accuracy standards would go a long way toward establishing compliance with federal law related to data sharing.