Required Rulemaking on Personal Financial Data Rights
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Issuing agencies
Abstract
The Consumer Financial Protection Bureau (CFPB) is proposing a rule to implement personal financial data rights under the Consumer Financial Protection Act of 2010 (CFPA). The proposed rule would require depository and nondepository entities to make available to consumers and authorized third parties certain data relating to consumers' transactions and accounts; establish obligations for third parties accessing a consumer's data, including important privacy protections for that data; provide basic standards for data access; and promote fair, open, and inclusive industry standards.
Full Text
<html>
<head>
<title>Federal Register, Volume 88 Issue 209 (Tuesday, October 31, 2023)</title>
</head>
<body><pre>
[Federal Register Volume 88, Number 209 (Tuesday, October 31, 2023)]
[Proposed Rules]
[Pages 74796-74875]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2023-23576]
[[Page 74795]]
Vol. 88
Tuesday,
No. 209
October 31, 2023
Part IV
Consumer Financial Protection Bureau
-----------------------------------------------------------------------
12 CFR Parts 1001 and 1033
Required Rulemaking on Personal Financial Data Rights; Proposed Rule
Federal Register / Vol. 88 , No. 209 / Tuesday, October 31, 2023 /
Proposed Rules
[[Page 74796]]
-----------------------------------------------------------------------
CONSUMER FINANCIAL PROTECTION BUREAU
12 CFR Parts 1001 and 1033
[Docket No. CFPB-2023-0052]
RIN 3170-AA78
Required Rulemaking on Personal Financial Data Rights
AGENCY: Consumer Financial Protection Bureau.
ACTION: Proposed rule; request for public comment.
-----------------------------------------------------------------------
SUMMARY: The Consumer Financial Protection Bureau (CFPB) is proposing a
rule to implement personal financial data rights under the Consumer
Financial Protection Act of 2010 (CFPA). The proposed rule would
require depository and nondepository entities to make available to
consumers and authorized third parties certain data relating to
consumers' transactions and accounts; establish obligations for third
parties accessing a consumer's data, including important privacy
protections for that data; provide basic standards for data access; and
promote fair, open, and inclusive industry standards.
DATES: Comments must be received on or before December 29, 2023.
ADDRESSES: You may submit comments, identified by Docket No. CFPB-2023-
0052 or RIN 3170-AA78, by any of the following methods:
<bullet> Federal eRulemaking Portal: <a href="https://www.regulations.gov">https://www.regulations.gov</a>.
Follow the instructions for submitting comments. A brief summary of
this document will be available at <a href="https://www.regulations.gov/docket/CFPB-2023-0052">https://www.regulations.gov/docket/CFPB-2023-0052</a>.
<bullet> Email: <a href="/cdn-cgi/l/email-protection#0d3f3d3f3e20435d5f4020496c796c205f646a65797e4d6e6b7d6f236a627b"><span class="__cf_email__" data-cfemail="8ebcbebcbda3c0dedcc3a3caeffaefa3dce7e9e6fafdceede8feeca0e9e1f8">[email protected]</span></a>. Include Docket No.
CFPB-2023-0052 or RIN 3170-AA78 in the subject line of the message.
<bullet> Mail/Hand Delivery/Courier: Comment Intake--FINANCIAL DATA
RIGHTS, c/o Legal Division Docket Manager, Consumer Financial
Protection Bureau, 1700 G Street NW, Washington, DC 20552.
Instructions: The CFPB encourages the early submission of comments.
All submissions should include the agency name and docket number or
Regulatory Information Number (RIN) for this rulemaking. Commenters are
encouraged to submit comments electronically. In general, all comments
received will be posted without change to <a href="https://www.regulations.gov">https://www.regulations.gov</a>.
All submissions, including attachments and other supporting
materials, will become part of the public record and subject to public
disclosure. Proprietary information or sensitive personal information,
such as account numbers or Social Security numbers, or names of other
individuals, should not be included. Submissions will not be edited to
remove any identifying or contact information.
FOR FURTHER INFORMATION CONTACT: Dave Gettler, Paralegal Specialist;
Anna Boadwee or Vince Mancini, Attorney-Advisors; Briana McLeod,
Counsel; Joseph Baressi, Sarita Frattaroli, David Jacobs, Mark Morelli,
Kristen Phinnessee, Michael Scherzer, Yaritza Velez or Priscilla
Walton-Fein, Senior Counsels, Office of Regulations, at 202-435-7700 or
<a href="https://reginquiries.consumerfinance.gov/">https://reginquiries.consumerfinance.gov/</a>. If you require this document
in an alternative electronic format, please contact
<a href="/cdn-cgi/l/email-protection#15565345574a5476767066667c777c797c616c55767365773b727a63"><span class="__cf_email__" data-cfemail="9ad9dccad8c5dbf9f9ffe9e9f3f8f3f6f3eee3daf9fceaf8b4fdf5ec">[email protected]</span></a>.
SUPPLEMENTARY INFORMATION:
Table of Contents
Abbreviations and Acronyms
I. Background
A. Introduction
B. Electronic Access to Personal Financial Data
C. Challenges in the Open Banking System
D. Overview of Rulemaking Objectives
E. Applicability of Other Laws
II. Legal and Procedural Background
A. Small Business Advisory Review Panel
B. Other Stakeholder Outreach
III. Legal Authority
A. CFPA Section 1033
B. CFPA Sections 1022(b) and 1024(b)(7)
C. CFPA Section 1032
D. CFPA Section 1002
IV. Discussion of the Proposed Rule
12 CFR part 1033
A. Subpart A--General
B. Subpart B--Obligation to Make Covered Data Available
C. Subpart C--Establishing and Maintaining Access
D. Subpart D--Authorized Third Parties
12 CFR part 1001
V. Proposed Effective Date
VI. CFPA Section 1022(b) Analysis
A. Statement of Need
B. Data and Evidence
C. Coverage of the Proposed Rule
D. Baseline for Consideration of Costs and Benefits
E. Potential Benefits and Costs to Consumers and Covered Persons
F. Potential Impacts on Depository Institutions and Credit
Unions With $10 Billion or Less in Total Assets, as Described in
Section 1026
G. Potential Impacts on Consumers in Rural Areas, as Described
in Section 1026
VII. Regulatory Flexibility Act Analysis
A. Small Business Review Panel
B. Initial Regulatory Flexibility Analysis
VIII. Paperwork Reduction Act
IX. Severability
Abbreviations and Acronyms
The following abbreviations and acronyms are used in this
proposed rule:
ACH = Automated Clearing House
ANPR = Advance Notice of Proposed Rulemaking
API = Application programming interface
APR = Annual percent rate
ATO = Account takeover
BLS = Bureau of Labor Statistics
EBT = Electronic benefit transfer
FDIC = Federal Deposit Insurance Corporation
FFIEC = Federal Financial Institutions Examination Council
FRFA = Final regulatory flexibility analysis
FTC = Federal Trade Commission
HHS = Department of Health and Human Services
IRFA = Initial regulatory flexibility analysis
LEI = Legal entity identifier
MSA = Metropolitan statistical area
NAICS = North American Industry Classification System
NCUA = National Credit Union Administration
NPRM = Notice of Proposed Rulemaking
OCC = Office of the Comptroller of the Currency
OMB = Office of Management and Budget
SBA = Small Business Administration
SSN = Social Security number
TAN = Tokenized account number
URL = Uniform resource locator
I. Background
A. Introduction
Digitization and decentralization in consumer finance create new
possibilities for more seamless consumer switching and greater
competitive intensity. For example, when consumers are able to share
their personal financial data, they can share details about their
income and expenses that may give lenders more confidence when
extending credit. When a consumer can switch with less friction, this
will create incentives for superior customer service and more favorable
terms. At the same time, sharing personal financial data can also lead
to misuse and abuse, given its commercial value.
In 2010, Congress explicitly recognized the importance of personal
financial data rights in section 1033 of the Consumer Financial
Protection Act of 2010 (CFPA).\1\ However, to date, the CFPB has not
issued a rule to implement this provision of law.
---------------------------------------------------------------------------
\1\ The CFPA is title X of the Dodd-Frank Wall Street Reform and
Consumer Protection Act, Public Law 111-203, 124 Stat. 1376, 2008
(2010).
---------------------------------------------------------------------------
Many market participants have already sought to develop
technologies and standards to facilitate consumer access to personal
financial data. The CFPB intends to accelerate the shift to a more open
and decentralized system through the issuance of a final rule.
[[Page 74797]]
B. Electronic Access to Personal Financial Data
Development of Electronic Data Access
By 1999, 20 percent of national banks offered online banking,
including all national banks with over $10 billion in assets, and
accounting for over 80 percent of all small deposit accounts held by
national banks.\2\ Adoption grew from 14 million consumers in 2000 to
37 million in 2002, and to 53 million in 2004.\3\ Around this time, the
first wave of online-only financial services providers emerged. In the
late 2000s, smartphones made digital banking still more available.
---------------------------------------------------------------------------
\2\ Alyssa Bentz, First in Online Banking, Wells Fargo Corp.
Archives (Mar. 14, 2019), <a href="https://www.wellsfargohistory.com/first-in-online-banking/">https://www.wellsfargohistory.com/first-in-online-banking/</a>; Karen Furst et al., internet Banking:
Developments and Prospects, Off. of the Comptroller of the Currency
(2000), <a href="https://www.occ.treas.gov/publications-and-resources/publications/economics/working-papers-archived/pub-econ-working-paper-2000-9.pdf">https://www.occ.treas.gov/publications-and-resources/publications/economics/working-papers-archived/pub-econ-working-paper-2000-9.pdf</a>.
\3\ Susannah Fox, Online Banking 2002, Pew Rsch. Ctr. (Nov. 17,
2002), <a href="https://www.pewresearch.org/internet/2002/11/17/online-banking-2002/">https://www.pewresearch.org/internet/2002/11/17/online-banking-2002/</a>; Susannah Fox, Online Banking 2005, Pew Rsch. Ctr.
(Feb. 9, 2005), <a href="https://www.pewresearch.org/internet/2005/02/09/online-banking-2005/">https://www.pewresearch.org/internet/2005/02/09/online-banking-2005/</a>.
---------------------------------------------------------------------------
Today, most consumers with a bank account are enrolled in digital
banking through online banking or mobile applications, and more than
two-thirds use it as their primary method of account access.\4\
Consumer interfaces generally provide free access to information such
as balances, transactions, and at least some terms of service. These
consumer interfaces may provide additional functionality, such as
allowing consumers to move money, manage their accounts, and download
financial data.
---------------------------------------------------------------------------
\4\ Fed. Deposit Ins. Corp., National Survey of Unbanked and
Underbanked Households (2021), <a href="https://www.fdic.gov/analysis/household-survey/2021report.pdf">https://www.fdic.gov/analysis/household-survey/2021report.pdf</a>.
---------------------------------------------------------------------------
Development of Open Banking
Building on these developments, open banking \5\ emerged in the
early 2000s, along with interfaces designed for developers of products
or services to request consumer information, and related industry
standard-setting activity.\6\ These developer interfaces facilitated
consumer-authorized data access that was necessary for many new
products and services. Third parties often outsourced establishing and
maintaining connections with data providers to data aggregators. These
intermediaries largely relied on ``screen scraping,'' which uses
consumer credentials to log in to consumer accounts to retrieve
data.\7\ Widespread screen scraping allowed open banking to grow
quickly in the United States.
---------------------------------------------------------------------------
\5\ This Federal Register notice generally uses the term ``open
banking'' to refer to the network of entities sharing personal
financial data with consumer authorization. Some stakeholders use
the term ``open finance'' because of the role of nondepositories as
important data sources. The CFPB views the two terms as
interchangeable, but generally uses ``open banking'' because that
term is more commonly used in the United States.
\6\ Maria Trombly, Citibank's Aggregation Portal a Big Draw,
Computerworld (Sept. 18, 2000), <a href="https://www.computerworld.com/article/2597099/citibank-s-aggregation-portal-a-big-draw.html">https://www.computerworld.com/article/2597099/citibank-s-aggregation-portal-a-big-draw.html</a>; Off.
of the Comptroller of the Currency, Bank-Provided Account
Aggregation Services: Guidance to Banks (2001), <a href="https://www.occ.treas.gov/news-issuances/bulletins/2001/bulletin-2001-12.html">https://www.occ.treas.gov/news-issuances/bulletins/2001/bulletin-2001-12.html</a>; CNET, Net earnings: E-commerce in 1997 (Dec. 24, 1997),
<a href="https://www.cnet.com/tech/tech-industry/net-earnings-e-commerce-in-1997/">https://www.cnet.com/tech/tech-industry/net-earnings-e-commerce-in-1997/</a>; Microsoft, OFX Consortium Expands with Bank of America,
Citigroup, Corillian, E*TRADE and TD Waterhouse (Oct. 2, 2001),
<a href="https://news.microsoft.com/2001/10/02/ofx-consortium-expands-with-bank-of-america-citigroup-corillian-etrade-and-td-waterhouse/">https://news.microsoft.com/2001/10/02/ofx-consortium-expands-with-bank-of-america-citigroup-corillian-etrade-and-td-waterhouse/</a>.
\7\ Unless otherwise stated, the term ``screen scraping'' in
this document refers to credential-based screen scraping, which is
prevalent in the market today.
---------------------------------------------------------------------------
Screen scraping became a significant point of contention between
third parties and data providers, in part due to its inherent risks,
such as the proliferation of shared consumer credentials and
overcollection of data. Aggregators often declined to seek permission
from financial institutions they ``scraped,'' and some methods
aggregators used to solicit credential sharing led to litigation.\8\ In
late 2015, several large retail banks took actions that disrupted
screen scraping, albeit temporarily.\9\
---------------------------------------------------------------------------
\8\ See, e.g., Plaid, Inc., In re Plaid, Inc. Privacy
Litigation--Frequently Asked Questions, <a href="https://www.plaidsettlement.com/frequently-asked-questions.php">https://www.plaidsettlement.com/frequently-asked-questions.php</a> (last visited
Sept. 18, 2023); TD Bank, TD Bank Files Trademark Counterfeiting and
Infringement Lawsuit Against Plaid in the U.S. (Oct. 14, 2020),
<a href="https://stories.td.com/us/en/article/td-bank-files-trademark-counterfeiting-and-infringement-lawsuit-against-plaid-in-the-u-s">https://stories.td.com/us/en/article/td-bank-files-trademark-counterfeiting-and-infringement-lawsuit-against-plaid-in-the-u-s</a>;
Penny Crosman, PNC sues Plaid for trademark infringement, Am. Banker
(Dec. 23, 2020), <a href="https://www.americanbanker.com/news/pnc-sues-plaid-for-trademark-infringement">https://www.americanbanker.com/news/pnc-sues-plaid-for-trademark-infringement</a>.
\9\ Robin Sidel, Big Banks Lock Horns with Personal-Finance Web
Portals, Wall St. J. (Nov. 4, 2015), <a href="https://www.wsj.com/articles/big-banks-lock-horns-with-personal-finance-web-portals-1446683450">https://www.wsj.com/articles/big-banks-lock-horns-with-personal-finance-web-portals-1446683450</a>;
Peter Rudegeair, J.P. Morgan Warns It Could Unplug Quicken and
Quickbooks Users, Wall St. J. (Nov. 24, 2015), <a href="https://www.wsj.com/articles/j-p-morgan-may-unplug-some-customers-access-to-account-data-1448375950">https://www.wsj.com/articles/j-p-morgan-may-unplug-some-customers-access-to-account-data-1448375950</a>; Daniel Huang & Peter Rudegeair, Bank of America Cut
Off Finance Sites From Its Data, Wall St. J. (Nov. 9, 2015), <a href="https://www.wsj.com/articles/bank-of-america-cut-off-finance-sites-from-its-data-1447115089">https://www.wsj.com/articles/bank-of-america-cut-off-finance-sites-from-its-data-1447115089</a>.
---------------------------------------------------------------------------
Around that same time, efforts accelerated to establish agreements
for third parties to access data via a provider's developer
interface.\10\ While the progress of access agreements has been uneven,
the open banking system has nevertheless grown as consumer reliance on
products and services powered by consumer-authorized data access
expanded. This growth led to further disputes and litigation between
system participants,\11\ and concerns over privacy and harmful uses of
consumer-authorized data increased.\12\
---------------------------------------------------------------------------
\10\ See, e.g., Penny Crosman, Wells Fargo strikes data-sharing
agreement with Plaid, Am. Banker (Sept. 19, 2019), <a href="https://www.americanbanker.com/news/wells-fargo-strikes-data-sharing-agreement-with-plaid">https://www.americanbanker.com/news/wells-fargo-strikes-data-sharing-agreement-with-plaid</a>; Finicity, Enhancing the Data-sharing
Experience at USAA (July 2, 2018), <a href="https://www.finicity.com/blog/data-sharing-usaa-direct-api/">https://www.finicity.com/blog/data-sharing-usaa-direct-api/</a>; Mary Wisniewski, JPMorgan Chase and
Finicity ink data-sharing agreement, Am. Banker (July 11, 2017),
<a href="https://www.americanbanker.com/news/jpmorgan-chase-and-finicity-ink-data-sharing-agreement">https://www.americanbanker.com/news/jpmorgan-chase-and-finicity-ink-data-sharing-agreement</a>.
\11\ Nathan DiCamillo, In data dispute with Capital One, Plaid
stands alone, Am. Banker (July 17, 2018), <a href="https://www.americanbanker.com/news/in-data-dispute-with-capital-one-plaid-stands-alone">https://www.americanbanker.com/news/in-data-dispute-with-capital-one-plaid-stands-alone</a>; Yuka Hayashi, Venmo Glitch Opens Window on War Between
Banks, Fintech Firms, Wall St. J. (Dec. 14, 2019), <a href="https://www.wsj.com/articles/venmo-glitch-opens-window-on-war-between-banks-fintech-firms-11576319402">https://www.wsj.com/articles/venmo-glitch-opens-window-on-war-between-banks-fintech-firms-11576319402</a>; Penny Crosman, PNC sues Plaid for
trademark infringement, Am. Banker (Dec. 23, 2020), <a href="https://www.americanbanker.com/news/pnc-sues-plaid-for-trademark-infringement">https://www.americanbanker.com/news/pnc-sues-plaid-for-trademark-infringement</a>; TD Bank, TD Bank Files Trademark Counterfeiting and
Infringement Lawsuit Against Plaid in the U.S. (Oct. 14, 2020),
<a href="https://stories.td.com/us/en/article/td-bank-files-trademark-counterfeiting-and-infringement-lawsuit-against-plaid-in-the-u-s">https://stories.td.com/us/en/article/td-bank-files-trademark-counterfeiting-and-infringement-lawsuit-against-plaid-in-the-u-s</a>.
\12\ See, e.g., Maeve Allsup, App Users Say Plaid Collects Bank
Logins Without Consent, Bloomberg L. (May 5, 2020), <a href="https://news.bloomberglaw.com/class-action/app-users-say-plaid-collects-bank-logins-without-consent">https://news.bloomberglaw.com/class-action/app-users-say-plaid-collects-bank-logins-without-consent</a>; Ron Wyden, Wyden, Brown, Eshoo Urge FTC
to Investigate Firm Collecting and Selling Americans' Financial Data
(Jan. 17, 2020), <a href="https://www.wyden.senate.gov/news/press-releases/wyden-brown-eshoo-urge-ftc-to-investigate-firm-collecting-and-selling-americans-financial-data">https://www.wyden.senate.gov/news/press-releases/wyden-brown-eshoo-urge-ftc-to-investigate-firm-collecting-and-selling-americans-financial-data</a>.
---------------------------------------------------------------------------
Despite these challenges, financial institutions have begun to
dedicate more resources to develop open banking infrastructure. This
includes multilateral efforts, some of which have been
controversial.\13\ Other incumbents, most notably large payment
networks, have sought to acquire aggregators.\14\
[[Page 74798]]
Most recently, large payments-focused nondepositories have looked to
enter the aggregation space by developing internal business units,
sometimes partnering with incumbent aggregators.\15\ These efforts
indicate the potential for incumbents to mitigate or neutralize
competitive threats from open banking, demonstrating the need for
strong rules to protect the openness of the system.
---------------------------------------------------------------------------
\13\ E.g., OpenID Found., Announcing the Financial API (FAPI)
Working Group (May 23, 2016), <a href="https://openid.net/announcing-the-financial-api-fapi-working-group/">https://openid.net/announcing-the-financial-api-fapi-working-group/</a>; Fin. Data Exch., Financial
Industry Unites to Enhance Data Security, Innovation and Consumer
Control (Oct. 18, 2018), <a href="https://www.financialdataexchange.org/FDX/FDX/News/Press-Releases/Financial_Industry_Unites_Data_Security.aspx">https://www.financialdataexchange.org/FDX/FDX/News/Press-Releases/Financial_Industry_Unites_Data_Security.aspx</a>; E.g., Penny Crosman,
Fidelity data-sharing hub aims to end screen scraping, Am. Banker
(June 11, 2019), <a href="https://www.americanbanker.com/news/fidelity-data-sharing-hub-aims-to-end-screen-scraping">https://www.americanbanker.com/news/fidelity-data-sharing-hub-aims-to-end-screen-scraping</a>; PR Newswire, S&P Global
enhances KY3P[supreg] risk management capabilities with acquisition
of TruSight Solutions LLC (Jan. 9, 2023), <a href="https://www.prnewswire.com/news-releases/sp-global-enhances-ky3p-risk-management-capabilities-with-acquisition-of-trusight-solutions-llc-301715878.html">https://www.prnewswire.com/news-releases/sp-global-enhances-ky3p-risk-management-capabilities-with-acquisition-of-trusight-solutions-llc-301715878.html</a>; Penny Crosman, Fidelity's data-sharing unit Akoya to
be jointly owned with The Clearing House, 11 banks(Feb. 20, 2020),
Am. Banker, <a href="https://www.americanbanker.com/news/fidelitys-data-sharing-unit-akoya-to-be-jointly-owned-with-the-clearing-house-11-banks">https://www.americanbanker.com/news/fidelitys-data-sharing-unit-akoya-to-be-jointly-owned-with-the-clearing-house-11-banks</a>.
\14\ See, e.g., Visa, Visa to Acquire Plaid (Jan. 13, 2020),
<a href="https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.16856.html">https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.16856.html</a>; Visa, Visa Completes Acquisition of
Tink (Mar. 10, 2022), <a href="https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.18881.html">https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.18881.html</a>; Mastercard, Mastercard to
Acquire Finicity to Advance Open Banking Strategy (June 23, 2020),
<a href="https://www.finicity.com/in-the-news/mastercard-to-acquire-finicity-to-advance-open-banking-strategy/">https://www.finicity.com/in-the-news/mastercard-to-acquire-finicity-to-advance-open-banking-strategy/</a>.
\15\ See, e.g., John Adams, Stripe adds tech for Plaid-like
account aggregation, Am. Banker (May 4, 2022), <a href="https://www.americanbanker.com/payments/news/stripe-adds-tech-for-plaid-like-account-aggregation">https://www.americanbanker.com/payments/news/stripe-adds-tech-for-plaid-like-account-aggregation</a>; Klarna, Klarna launches `Klarna Kosma'
sub-brand and business unit to harness rapid growth of Open Banking
platform (Mar. 31, 2022), <a href="https://www.klarna.com/international/press/klarna-launches-klarna-kosma-sub-brand-and-business-unit-to-harness-rapid-growth-of-open-banking-platform/">https://www.klarna.com/international/press/klarna-launches-klarna-kosma-sub-brand-and-business-unit-to-harness-rapid-growth-of-open-banking-platform/</a>.
---------------------------------------------------------------------------
State of the Open Banking System
The CFPB estimates that at least 100 million consumers have
authorized a third party to access their account data. In 2022, the
number of individual instances in which third parties accessed or
attempted to access consumer financial accounts exceeded 50 billion and
may have been as high as 100 billion, figures that vastly exceed the
comparable public figures from some other jurisdictions' open banking
systems, even on a per-capita basis.\16\
---------------------------------------------------------------------------
\16\ See Competition & Mkts. Auth., UK reaches 7 million Open
Banking users milestone (Feb. 20, 2023), <a href="https://www.openbanking.org.uk/news/uk-reaches-7-million-open-banking-users-milestone/">https://www.openbanking.org.uk/news/uk-reaches-7-million-open-banking-users-milestone/</a>, and Bnamericas, Open Finance completes two years with
17.3 million customer consents (Feb. 2, 2023), <a href="https://www.bnamericas.com/en/news/brazil-open-finance-completes-two-years-with-173-million-customer-consents">https://www.bnamericas.com/en/news/brazil-open-finance-completes-two-years-with-173-million-customer-consents</a>.
---------------------------------------------------------------------------
The open banking system also engages a large number of entities.
While loans and deposits in the United States are concentrated among
the largest depositories, there are more than nine thousand banks and
credit unions across the country,\17\ most of which serve as data
providers, as do numerous nondepository financial institutions.\18\ The
number of third parties may total as many as ten thousand, driven by a
large financial technology sector.\19\ A growing number of entities now
serve as both data providers and third parties. For example, many
depositories now offer personal financial management tools, while some
so-called neobank accounts and digital wallets serve as important
transaction accounts for consumers. Most third party access is
effectuated via a small number of aggregators, although some third
parties elect to access at least some data directly.
---------------------------------------------------------------------------
\17\ Fed. Deposit Ins. Corp., Statistics at a Glance--Industry
Trends (Mar. 31, 2023), <a href="https://www.fdic.gov/analysis/quarterly-banking-profile/statistics-at-a-glance/2023mar/industry.pdf">https://www.fdic.gov/analysis/quarterly-banking-profile/statistics-at-a-glance/2023mar/industry.pdf</a>; Nat'l
Credit Union Admin., Quarterly Credit Union Data Summary--2022 Q4
(Mar. 8, 2023), <a href="https://ncua.gov/files/publications/analysis/quarterly-data-summary-2022-Q4.pdf">https://ncua.gov/files/publications/analysis/quarterly-data-summary-2022-Q4.pdf</a>.
\18\ Some aggregators report even more data providers. See,
e.g., <a href="https://plaid.com/">https://plaid.com/</a> (over 12,000 as of Sept. 16, 2023); <a href="https://www.mx.com/">https://www.mx.com/</a>(over 13,000 as of Sept. 16, 2023); <a href="https://docs.finicity.com/search-institutions/">https://docs.finicity.com/search-institutions/</a>(over 16,000 as Sept. 16,
2023); <a href="https://www.yodlee.com/data-aggregation">https://www.yodlee.com/data-aggregation</a> (over 17,000 as of
Sept. 16, 2023).
\19\ In 2022, Plaid indicated that they alone have over 6,000
customers. Plaid, Ushering in Fintech's Next Phase (May 19, 2022),
<a href="https://plaid.com/blog/ushering-in-fintechs-next-phase/">https://plaid.com/blog/ushering-in-fintechs-next-phase/</a>.
---------------------------------------------------------------------------
Third party data access is generally enabled by one of two methods.
In screen scraping, consumers usually share their consumer interface
credentials with a third party or their service provider. That entity
uses (and may store) those credentials to access the consumer's account
to retrieve data for use in the third party's products and services.
The second method is through developer interfaces maintained by data
providers or their service providers. These often take the form of APIs
that can be accessed without consumer credentials, for example, by
using secure tokens. Such interfaces enable the direct transmission of
structured machine-readable data, promote standardization, and reduce
risks of inaccuracies and security breaches, among other benefits. Data
providers also have offered APIs accessed using consumer interface
credentials or deployed tokenized access to their consumer interface,
but most stakeholders agree that such measures are best viewed as a
stopgap, and that credential-free access to developer interfaces is
preferable.
Based on feedback received through public comments and stakeholder
outreach, there is nearly universal consensus that developer interfaces
should supplant screen scraping.\20\ Stakeholders responding to the
SBREFA Outline, including small entity representatives, several data
aggregators, data providers, and a trade association representing third
party data recipients and aggregators, supported a general transition
towards the use of developer interfaces.\21\ However, such a transition
requires certain conditions. First, data providers must commit
resources to develop and maintain developer interfaces. While large
depository and nondepository institutions might have sufficient
information technology budgets to do this themselves, small
institutions tend to rely on a few core service providers, and
frequently report problems with the services that ``cores'' offer.
Second, connecting to a developer interface generally requires a third
party to agree to a data provider's terms of access, a process that has
been impeded as discussed below. Today, the CFPB estimates that about
half of third party data access currently occurs through APIs; scraping
comprises the bulk of the balance. This is a significant shift: as
recently as 2021, most access was via screen scraping. Much of this
progress has been concentrated among the largest data providers.
---------------------------------------------------------------------------
\20\ See, e.g., Consumer Fin. Prot. Bureau, Bureau Symposium:
Consumer Access to Financial Records Report, at 3-4 (July 2020),
<a href="https://s3.amazonaws.com/files.consumerfinance.gov/f/documents/cfpb_bureau-symposium-consumer-access-financial-records_report.pdf">https://s3.amazonaws.com/files.consumerfinance.gov/f/documents/cfpb_bureau-symposium-consumer-access-financial-records_report.pdf</a>.
\21\ See Consumer Fin. Prot. Bureau, Final Report of the Small
Business Review Panel on the CFPB's Proposals and Alternatives Under
Consideration of the Required Rulemaking on Personal Financial Data
Rights, at 30-31 (Mar. 30, 2023), <a href="https://files.consumerfinance.gov/f/documents/cfpb_1033-data-rights-rule-sbrefa-panel-report_2023-03.pdf">https://files.consumerfinance.gov/f/documents/cfpb_1033-data-rights-rule-sbrefa-panel-report_2023-03.pdf</a>.
---------------------------------------------------------------------------
Open banking use cases continue to emerge and develop. Major use
cases, which the CFPB understands generally rely heavily or exclusively
on data from transaction accounts, include personal financial
management tools of all kinds, payment applications and digital
wallets, credit underwriting (including cashflow underwriting), and
identity verification. While many major use cases began as innovative
offerings by third parties, incumbent financial institutions have
adopted many of them in response to consumer demand. Many use cases
also compete with the core offerings of other types of financial
institutions, such as card networks and credit bureaus.\22\
---------------------------------------------------------------------------
\22\ Conversely, data-sharing schemes owned by large
depositories can also compete with open banking-supported products
and services; see, e.g., Early Warning Sys., Verify Identity--Expand
your customer base with confidence, <a href="https://www.earlywarning.com/products/verify-identity">https://www.earlywarning.com/products/verify-identity</a> (last visited Sept. 7, 2023).
---------------------------------------------------------------------------
C. Challenges in the Open Banking System
Despite these developments, commercial actors are able to use their
market power and incumbency to privilege their concerns and interests
above fair competition that could benefit consumers. Divergent
interests in the market with respect to the scope, terms, and mechanics
of data access, and problems with the responsible collection, use, and
retention of data have impeded the negotiation of access agreements and
the development of market-wide standards. This leads to inconsistent
data access for consumers
[[Page 74799]]
and costs for the market. Most notably, these dynamics impel third
parties to rely on intermediaries. The commercial interests of such
intermediaries may not always advance open banking, since they stand to
benefit from protecting private network effects against open standards
that could displace them or lower their rents.
Market participants' interests may diverge due to interrelated
competitive, legal, and regulatory factors. Data providers may minimize
the data they share or refrain from sharing altogether to protect their
market position. Data providers may also have data security, risk
management, and data privacy concerns regarding consumer-authorized
access to their data and systems.\23\ Motivated by their own self-
interest, third parties may use screen scraping to collect more data
than they reasonably need. Diverging self-interests also lead to
disagreements over issues such as the frequency and duration of data
access, the imposition of access caps, the assignment of liability, and
consumer authorization procedures. These dynamics undermine the
efficient functioning of the open banking system for consumers and the
system's ability to move away from screen scraping.
---------------------------------------------------------------------------
\23\ See, e.g., Off. of the Comptroller of the Currency, Third-
Party Relationships: Interagency Guidance on Risk Management (June
6, 2023), <a href="https://www.occ.gov/news-issuances/bulletins/2023/bulletin-2023-17.html">https://www.occ.gov/news-issuances/bulletins/2023/bulletin-2023-17.html</a>.
---------------------------------------------------------------------------
Third parties' data use can also contribute to problems in the
current open banking system. When consumers go into the market to
obtain a product, they do not want third parties to serve their own
commercial interests by collecting, using, or retaining data beyond
what they need to provide that product.\24\ For example, third parties
with surveillance revenue models monetize consumer data by targeting
consumers with unwanted ads or services or selling the consumer data,
undermining consumers' ability to limit data use to providing the
product they sought. Third parties also collect data using methods that
may compromise consumers' data privacy, security, and accuracy, as well
as data provider interests related to security, liability, and risk
management. For example, screen scraping may pose risks to consumers'
data privacy and security by capturing and storing consumer credentials
and potentially capturing more data than are reasonably necessary to
provide the requested product or service. Additionally, because screen
scraping requires a third party to parse through a data provider's
consumer interface and transpose the unstructured information that a
consumer sees into a structured format the third party can use, any
errors in the transposition or any changes a data provider makes to the
consumer interface can increase the risks of data inaccuracy in the
third party's product or service. Screen scraping also presents risks
to data providers because it involves third parties accessing data on
an automated basis from a system not designed for that purpose, leading
some data providers to report that screen scraping puts undue strain on
their information systems. Screen scraping exacerbates data provider
concerns with respect to liability, because it entails giving third
parties a way to access data provider information systems and initiate
payments in a way that can impede data providers' efforts to monitor
them.
---------------------------------------------------------------------------
\24\ Dan Murphy et al., Financial Data--The Consumer
Perspective, at 15, 18, Fin. Health Network (June 30, 2021), <a href="https://finhealthnetwork.org/wp-content/uploads/2021/04/Consumer-Data-Rights-Report_FINAL.pdf">https://finhealthnetwork.org/wp-content/uploads/2021/04/Consumer-Data-Rights-Report_FINAL.pdf</a>; Brooke Auxier, Americans and Privacy:
Concerned, Confused and Feeling Lack of Control Over Their Personal
Information, Pew Rsch. Ctr. (Nov. 15, 2019), <a href="https://www.pewresearch.org/internet/2019/11/15/americans-and-privacy-concerned-confused-and-feeling-lack-of-control-over-their-personal-information/">https://www.pewresearch.org/internet/2019/11/15/americans-and-privacy-concerned-confused-and-feeling-lack-of-control-over-their-personal-information/</a>.
---------------------------------------------------------------------------
Impacts of These Challenges on the Open Banking System
The challenges described above in this part I.C have impeded
progress in negotiating access agreements in several respects. Data
providers may decide not to establish a developer interface in the
first instance, making it difficult for third parties to access data
without resorting to screen scraping. Even where data providers have a
developer interface, conflicting interests may inhibit parties from
reaching access agreements. And even where such agreements are reached,
negotiating them has often proved costly, and their terms often vary in
key respects that undermine the consistency of data access across the
system. For example, the scope of and frequency with which data are
made available vary from agreement to agreement. Attempts to
standardize or streamline negotiations by publishing model agreements
generally have been undertaken only by certain segments of the market,
limiting their effectiveness.\25\
---------------------------------------------------------------------------
\25\ See, e.g., The Clearing House, The Clearing House Releases
Model Agreement to Help Facilitate Safe Sharing of Financial Data
(Nov. 12, 2019), <a href="https://www.theclearinghouse.org/payment-systems/articles/2019/11/model_agreement_press_release_11-12-19">https://www.theclearinghouse.org/payment-systems/articles/2019/11/model_agreement_press_release_11-12-19</a>.
---------------------------------------------------------------------------
These challenges also hamper efforts by industry to establish
standards for open banking. The absence of clarity around the scope of
consumers' data rights and the appropriate role of various parties has
left standard setters to negotiate a thicket of conflicting interests.
The result has been standards limited in their scope, specificity, and
adoption. These dynamics have limited standard setters from taking on
other functions for which they are potentially well-suited, such as
apportioning liability and developing an accreditation system.
Due to the lack of progress on access agreements and the
establishment of open, fair, and inclusive industry standards, the open
banking system has come to depend heavily on a handful of data
aggregators. Aggregators currently function as connectors and, as a
practical matter, standardize how many third parties receive data. As
such, they accrue economic benefits from the system's inability to
scale bilateral access agreements and open industry standards.
Dependency on a handful of data aggregators creates incentives for them
to rent-seek and self-preference. In a more open system where developer
interfaces are appropriately accessible and third parties are easily
verified, third parties and data providers may choose to connect
without intermediaries if they wish, or continue to use them to the
extent they offer compelling value.
When the challenges impeding progress described above in this part
I.C are resolved, consumers should be able to safely exercise their
data access rights in an open system not dominated by the interests of
any one segment of the market.
D. Overview of Rulemaking Objectives
The CFPB is proposing regulations to implement CFPA section 1033.
In addition to ensuring consumers can access covered data in an
electronic form from data providers, the proposed regulations would
address the challenges described above in part I.C with respect to the
open banking system by delineating the scope of data that third parties
can access on a consumer's behalf, the terms on which data are made
available, and the mechanics of data access. The proposed regulations
also would ensure that third parties act on consumers' behalf when
collecting, using, or retaining data.
If finalized as proposed, this rule will foster a data access
framework that is (1) safe, by ensuring third parties are acting on
behalf of consumers when accessing their data, including with respect
to consumers' privacy interests; (2) secure, by applying a consistent
set of security standards across the market; (3) reliable, by promoting
the accurate and consistent transmission of data that are usable by
consumers and authorized
[[Page 74800]]
third parties; and (4) competitive, by promoting standardization and
not entrenching the roles of incumbent data providers, intermediaries,
and third parties whose commercial interests might not align with the
interests of consumers and competition generally. The proposed rule is
intended to foster this kind of framework by direct regulation of
practices in the market and by identifying areas in which fair, open,
and inclusive standards can develop to provide additional guidance to
the market. Consistent with the statutory mandate in CFPA section
1033(d), various provisions in the proposed rule would promote the use
and development of standardized formats.
1. Clarifying Scope of Data Rights
The CFPB is proposing to define key terms, establish which covered
persons would be required to make data available to consumers, and
define which data would need to be made available to consumers. As
discussed in part IV.A, the CFPB is proposing to first apply part 1033
to a subset of covered persons--namely, entities providing asset
accounts subject to the Electronic Fund Transfer Act (EFTA) \26\ and
Regulation E,\27\ credit cards subject to the Truth in Lending Act
(TILA) \28\ and Regulation Z,\29\ and related payment facilitation
products and services. This proposed scope is intended to prioritize
some of the most beneficial use cases for consumers and leverage data
providers' existing capabilities. The proposed definition of covered
data would ensure consumers have access to key pricing terms,
transaction and balance information, payment initiation information,
and terms and conditions. As discussed in part IV.B, this would
facilitate consumer choice, including the ability of consumers to
change providers of products or services. Clarifying the scope of the
data right also would promote consistency in the data made available to
consumers, reduce costs of negotiating the inclusion of such data in
access agreements, and focus the development of technical standards
around such data.
---------------------------------------------------------------------------
\26\ 15 U.S.C. 1693 et seq.
\27\ 12 CFR part 1005.
\28\ 15 U.S.C. 1601 et seq.
\29\ 12 CFR part 1026.
---------------------------------------------------------------------------
2. Establishing Basic Standards for Data Access
As discussed in part IV.C, the proposed rule would require data
providers to establish and maintain a developer interface for third
parties to access consumer-authorized data. Developer interfaces would
need to make available covered data in a standardized format, in a
commercially reasonable manner, without unreasonable access caps, and
pursuant to certain security specifications. In addition, data
providers would need to follow certain procedures to disclose
information about themselves and their developer interfaces, which
would ensure that consumers and authorized third parties have
information necessary to make requests and use the developer interface.
Data providers also would be required to establish and maintain certain
written policies and procedures to promote these objectives.
Altogether, these provisions would ensure data providers make data
available reliably, securely, and in a way that promotes competition.
3. Transitioning the Market From Screen Scraping
The proposed rule would prevent data providers from relying on
screen scraping to comply with the proposal because it is not a viable
long-term method of access for the reasons discussed in part I.C above.
Instead, data providers would be required to establish and maintain
developer interfaces that would make data available in a machine-
readable, standardized format and could not allow a third party to
access the system using consumer interface credentials. These
provisions would help the market move away from screen scraping, even
outside of the product markets covered under the proposed rule. Once
developer interfaces have been established by data providers with
respect to covered data, it will be more efficient for these data
providers to provide access to other data types via the same developer
interface. And, as the infrastructure for establishing and using
developer interfaces embeds itself in the market for accessing consumer
financial data, data providers outside the scope of the proposed rule
will face competitive pressure to adopt and use developer interfaces as
well. During the rule's implementation period, and for data accessed
outside its coverage, the CFPB plans to monitor the market to evaluate
whether data providers are blocking screen scraping without a bona fide
and particularized risk management concern or without making a more
secure and structured method of data access available (e.g., through a
developer interface). If so, the CFPB would consider using the tools at
its disposal to address this topic in advance of the proposed
compliance dates.
4. Clarifying Mechanics of Data Access
As discussed in part IV.C, the CFPB is proposing certain
requirements and clarifications to implement CFPA section 1033 with
respect to when a data provider must make available covered data upon
request to consumers and authorized third parties. These proposed
provisions address how a data provider can manage requests for third
parties to access a developer interface and when a data provider must
respond to requests for information through a consumer and developer
interface. While the CFPB is not proposing amendments to Regulation E
at this time, proposed part 1033 contains multiple provisions that
would reduce fraud and unauthorized access risk in the open banking
system. These provisions include requiring that third party access be
effected through a developer interface (rather than through credential-
based screen scraping); prohibiting a developer interface from
requiring a third party to obtain or possess credentials for the
consumer interface; and allowing data providers to share tokenized
account and routing numbers. The proposed rule would allow data
providers to restrict access to their developer interface when they
have reasonable risk management grounds to do so.
5. Ensuring Third Parties are Acting on Behalf of Consumers
To effectuate consumers' control of access to their data, the
proposed rule contains provisions intended to ensure that when
consumers authorize a third party to access data on their behalf, the
third party is actually doing so. To that end, the proposed rule would
require a third party to certify to consumers that it will only
collect, use, and retain the consumer's data to the extent reasonably
necessary to provide the consumer's requested product or service. The
proposed rule also would aim to improve consumers' understanding of
third parties' data practices by requiring a clear and conspicuous
authorization disclosure including key facts about the third party and
its practices. Other key protections in the proposed rule include
limiting the length of data access authorizations and requiring
deletion of consumer data in many cases when a consumer's authorization
expires or is revoked.
Separately, the proposed rule would exercise the CFPB's authority
to define financial products or services under the CFPA to ensure that
it includes providing financial data processing. Although the CFPB has
tentatively concluded that this activity would
[[Page 74801]]
qualify as a financial product or service without a CFPB rule, this
rule provision would provide additional assurance that financial data
processing by third parties or others is subject to the CFPA and its
prohibition on unfair, deceptive, and abusive acts or practices.
6. Promoting Fair, Open, and Inclusive Industry Standards
Industry standard-setting bodies that operate in a fair, open, and
inclusive manner have a critical role to play in ensuring a safe,
secure, reliable, and competitive data access framework. Accordingly,
indicia of compliance with various provisions in the rule, if finalized
as proposed, would include conformance with standards promulgated by
fair, open, and inclusive standard-setting bodies recognized by the
CFPB.
Comprehensive and detailed technical standards mandated by Federal
regulation could not address the full range of technical issues in the
open banking system in a manner that keeps pace with changes in the
market and technology. A rule with very granular coding and data
requirements risks becoming obsolete almost immediately, which means
the CFPB and regulated entities would experience constant regulatory
amendment, or worse, the rule would lock in 2023 technology, and
associated business practices, potentially for decades. In developing
the proposal, the CFPB is mindful of these limitations and the risk
that they may adversely impact the development and efficient evolution
of technical standards over time. In contrast, industry standards
appropriately developed within the CFPB's proposed data access
framework would not be subject to these limitations.
To help support and maintain a data access framework that enables
consumer access in a consistently safe, reliable, and secure manner
across the market, industry standards must be widely adopted. To
meaningfully scale, standards must reflect a diverse set of interests,
increasing the likelihood that market participants will adopt the
standards and maintain their integrity. Conversely, if standards are
controlled by dominant incumbents or intermediaries, they may enable
rent-extraction and cost increases for smaller participants. Fair,
open, and inclusive standard-setting bodies are vital to promote
standards that can support a data access system that works for
consumers, rather than the interests of dominant firms.
E. Applicability of Other Laws
1. Electronic Fund Transfer Act
This proposed rule would not alter a consumer's statutory right
under EFTA to resolve errors through their financial institution.
Regulation E financial institutions--including digital wallet
providers, entities that refer to themselves as neobanks, and
traditional depository institutions--have and will continue to have
error resolution obligations in the event of a data breach where stolen
account or ACH credentials are used to initiate an unauthorized
transfer from a consumer's account and the consumer provides proper
notice. Consumers are protected from liability from these unauthorized
transfers under EFTA and Regulation E, although the relevant financial
institution may be able to seek reimbursement from other parties
through private network rules, contracts, and commercial law. For
example, although a consumer's financial institution is required to
reimburse the consumer for an unauthorized transfer under Regulation E,
ACH private network rules generally dictate that the receiving
financial institution is entitled to reimbursement from the originating
depository institution that initiated the unauthorized payment.
Various stakeholders have suggested that consumer-authorized data
sharing may create risks to consumers and financial costs to financial
institutions arising from an increased risk of unauthorized
transactions and other errors, especially when data access relies on
screen scraping. In implementing CFPA section 1033, the CFPB is
proposing a variety of measures to mitigate unauthorized transfer and
privacy risks to data providers and consumers, including allowing data
providers to share TANs, not allowing data providers to rely on
credential-based screen scraping to satisfy their obligations under
CFPA section 1033, clarifying that data providers can engage in
reasonable risk management activities, and implementing authorization
procedures for third parties that would require they commit to data
limitations and compliance with the Gramm-Leach-Bliley Act (GLBA) \30\
Safeguards Framework. These provisions are intended to drive market
adoption of safer data sharing practices.
---------------------------------------------------------------------------
\30\ 15 U.S.C. 6801 et seq.
---------------------------------------------------------------------------
2. Fair Credit Reporting Act
As described above, entities engaged in data aggregation activities
play a role in the open banking system by transmitting consumer-
authorized data from data providers to third parties. When the data
bears on a consumer's creditworthiness, credit standing, credit
capacity, character, general reputation, personal characteristics, or
mode of living and is used or expected to be used, or collected, for
``permissible purposes'' as defined by the FCRA, such as when a third
party uses the data to underwrite a loan to a consumer, and when the
entity, for monetary fees, dues, or on a cooperative nonprofit basis,
regularly engages in whole or in part in the practice of assembling or
evaluating such data for the purpose of furnishing reports containing
the data to third parties (and uses any means or facility of interstate
commerce to prepare or furnish such reports), the data aggregator is
regulated as a consumer reporting agency under the FCRA.
II. Legal and Procedural Background
In 2010, Congress passed the CFPA, including section 1033. This is
the first proposed CFPB rule under section 1033.
A. Small Business Advisory Review Panel
Pursuant to the Small Business Regulatory Enforcement Fairness Act
of 1996 (SBREFA),\31\ the CFPB issued its Outline of Proposals and
Alternatives under Consideration for the Required Rulemaking on
Personal Financial Data Rights (Outline or SBREFA Outline).\32\ The
CFPB convened a SBREFA Panel for this proposed rule on February 1,
2023, and held two Panel meetings on February 1 and 2, 2023.\33\
Representatives from 18 small businesses were selected as small entity
representatives for this SBREFA process. These entities represented
small businesses that would likely be directly affected by a CFPA
section 1033 rule. On March 30, 2023, the Panel completed the Final
Report of the Small Business Review Panel on the CFPB's Proposals Under
Consideration for the Required Rulemaking on Personal Financial Data
Rights Rulemaking (Panel Report or SBREFA Panel Report). The CFPB
released the Panel Report on
[[Page 74802]]
April 3, 2023.\34\ The CFPB invited other stakeholders to submit
feedback on the SBREFA Outline by January 25, 2023.\35\ The CFPB has
considered the feedback it received from small entity representatives,
the findings and recommendations of the Panel, and the feedback from
other stakeholders in preparing this proposed rule.
---------------------------------------------------------------------------
\31\ Public Law 104-121, 110 Stat. 857 (1996).
\32\ Consumer Fin. Prot. Bureau, Small Business Advisory Review
Panel for Required Rulemaking on Personal Financial Data Rights,
Outline of Proposals and Alternatives under Consideration (Oct. 27,
2022), <a href="https://files.consumerfinance.gov/f/documents/cfpb_data-rights-rulemaking-1033-SBREFA_outline_2022-10.pdf">https://files.consumerfinance.gov/f/documents/cfpb_data-rights-rulemaking-1033-SBREFA_outline_2022-10.pdf</a>.
\33\ The Panel consists of a representative from the CFPB, the
Chief Counsel for Advocacy of the SBA, and a representative from the
Office of Information and Regulatory Affairs in OMB.
\34\ Consumer Fin. Prot. Bureau, Final Report of the Small
Business Review Panel on the CFPB's Proposals and Alternatives Under
Consideration for the Required Rulemaking on Personal Financial Data
Rights (Mar. 30, 2023), <a href="https://files.consumerfinance.gov/f/documents/cfpb_1033-data-rights-rule-sbrefa-panel-report_2023-03.pdf">https://files.consumerfinance.gov/f/documents/cfpb_1033-data-rights-rule-sbrefa-panel-report_2023-03.pdf</a>. As required under SBREFA, the CFPB considers the Panel's
findings in its IRFA, as set out in part VII below.
\35\ See <a href="https://www.regulations.gov/document/CFPB-2023-0011-0001/comment">https://www.regulations.gov/document/CFPB-2023-0011-0001/comment</a> (last visited Aug. 28, 2023). Feedback from these other
stakeholders was not considered by the Panel and is not reflected in
the Panel Report.
---------------------------------------------------------------------------
B. Other Stakeholder Outreach
In the years leading up to the release of this proposed rule, the
CFPB held a number of outreach meetings with financial institutions,
trade associations, nondepositories, aggregators, community groups,
consumer advocates, researchers, and other stakeholders regarding the
CFPA section 1033 rule, and about the open banking system generally.
Findings from such market monitoring activities inform the CFPB on the
state of the open banking system.
In January 2023, the CFPB issued two sets of CFPA section
1022(c)(4) market monitoring orders to collect information related to
personal financial data rights--one set of orders was sent to a group
of data aggregators (Aggregator Collection); \36\ the second to a group
of large data providers (Provider Collection).\37\ The information
gathered through these orders informs this proposed rule, including the
CFPA section 1022(b) analysis in part VI below.
---------------------------------------------------------------------------
\36\ Consumer Fin. Prot. Bureau, Generic Order for Data
Aggregators, <a href="https://files.consumerfinance.gov/f/documents/cfpb_generic-1022-order-data-aggregator_2023-01.pdf">https://files.consumerfinance.gov/f/documents/cfpb_generic-1022-order-data-aggregator_2023-01.pdf</a> (last visited
Aug. 28, 2023).
\37\ Consumer Fin. Prot. Bureau, Generic Order for Data
Providers, <a href="https://files.consumerfinance.gov/f/documents/cfpb_generic-1022-order-data-provider_2023-01.pdf">https://files.consumerfinance.gov/f/documents/cfpb_generic-1022-order-data-provider_2023-01.pdf</a> (last visited Aug.
28, 2023).
---------------------------------------------------------------------------
The CFPB regularly hears from several advisory committees on
emerging trends and practices in the consumer financial marketplace and
engages with advisory committee members in different formats, including
non-public and public engagements. In November 2022, the CFPB Director
and CFPB staff engaged in a discussion about data privacy in the
context of CFPA section 1033 with members of the Consumer Advisory
Board. Additionally, the CFPB Director and CFPB staff received two
briefings related to the CFPA section 1033 rule--one from the Consumer
Advisory Board and one from the combined Community Bank Advisory
Council and Credit Union Advisory Council.\38\
---------------------------------------------------------------------------
\38\ See Consumer Fin. Prot. Bureau, Consumer Advisory Board
Meeting (Nov. 2, 2022), <a href="https://s3.amazonaws.com/files.consumerfinance.gov/f/documents/cfpb_consumer-advisory-board-meeting_summary_2022-11.pdf">https://s3.amazonaws.com/files.consumerfinance.gov/f/documents/cfpb_consumer-advisory-board-meeting_summary_2022-11.pdf</a>; Consumer Fin. Prot. Bureau, Cmty. Bank
Advisory Council & Credit Union Advisory Council, Combined Advisory
Councils Meeting (Nov. 3, 2022), <a href="https://s3.amazonaws.com/files.consumerfinance.gov/f/documents/cfpb_combined-advisory-board-meeting_summary_2022-11.pdf">https://s3.amazonaws.com/files.consumerfinance.gov/f/documents/cfpb_combined-advisory-board-meeting_summary_2022-11.pdf</a>.
---------------------------------------------------------------------------
Prior to issuing this proposed rule (in accordance with CFPA
sections 1033(e) and 1022(b)(2)(B), and as recommended by the SBREFA
Panel), the CFPB consulted on several occasions with staff from the
prudential regulators and the FTC to discuss various aspects of this
proposed rule. Specifically, the CFPB met with staff from the Board of
Governors of the Federal Reserve System, the OCC, the FDIC, the NCUA,
the FTC, the Department of Treasury's Bureau of the Fiscal Service, the
United States Department of Justice, and the Financial Crimes
Enforcement Network. The CFPB also met with a number of State
regulators and an association of State regulators to discuss the CFPB's
proposals under consideration. The CFPB also met with its foreign
counterparts to discuss open banking frameworks in their respective
countries.
III. Legal Authority
The CFPB is issuing this proposed rule pursuant to its authority
under the CFPA. This part includes a general discussion of several CFPA
provisions on which the CFPB relies in this proposed rule.\39\ As set
forth in section 1021 of the CFPA, Congress established the CFPB to
ensure that ``all consumers have access to markets for consumer
financial products and services and that markets for consumer financial
products and services are fair, transparent, and competitive.''
Congress also authorized the CFPB to exercise its authorities under
Federal consumer financial law, including the CFPA, to ensure that,
with respect to consumer financial products and services, consumers
have ``timely and understandable information to make responsible
decisions about financial transactions,'' ``consumers are protected
from unfair, deceptive, or abusive acts and practices and from
discrimination,'' that ``markets for consumer financial products and
services operate transparently and efficiently to facilitate access and
innovation,'' and that ``Federal consumer financial law is enforced
consistently without regard to the status of a person as a depository
institution in order to promote fair competition.''
---------------------------------------------------------------------------
\39\ Part IV contains additional material on these authorities.
---------------------------------------------------------------------------
A. CFPA Section 1033
CFPA section 1033(a) and (b) provide that, subject to rules
prescribed by the CFPB, a covered person shall make available to a
consumer, upon request, information in the control or possession of the
covered person concerning the consumer financial product or service
that the consumer obtained from such covered person, subject to certain
exceptions. The information must be made available in an electronic
form usable by consumers. Section 1002 of the CFPA defines certain
terms used in CFPA section 1033, including defining consumer as ``an
individual or an agent, trustee, or representative acting on behalf of
an individual.'' In light of these purposes and objectives of section
1033 and the CFPA generally, the CFPB interprets CFPA section 1033 as
authority to establish a framework that readily makes available covered
data in an electronic form usable by consumers and third parties acting
on behalf of consumers, upon request, including authorized third
parties offering competing products and services. In addition, CFPA
section 1033(d) provides that the CFPB, by rule, shall prescribe
standards applicable to covered persons to promote the development and
use of standardized formats for information, including through the use
of machine-readable files, to be made available to consumers under this
section. Moreover, the CFPB interprets CFPA section 1033 as authority
to specify procedures to ensure third parties are truly acting on
behalf of consumers when accessing covered data. These procedures would
help ensure the market for consumer-authorized data operates fairly,
transparently, and competitively.
CFPA section 1033(c) provides that nothing in CFPA section 1033
shall be construed to impose any duty on a covered person to maintain
or keep any information about a consumer. Further, CFPA section 1033(e)
requires that the CFPB consult with the prudential regulators and the
FTC to ensure, to the extent appropriate, that certain objectives are
met.
B. CFPA Sections 1022(b) and 1024(b)(7)
CFPA section 1022(b)(1) authorizes the CFPB to, among other things,
[[Page 74803]]
prescribe rules ``as may be necessary or appropriate to enable the CFPB
to administer and carry out the purposes and objectives of the Federal
consumer financial laws, and to prevent evasions thereof.'' The CFPA is
a Federal consumer financial law.\40\ Accordingly, in issuing the
proposed rule, the CFPB is exercising its authority under CFPA section
1022(b) to prescribe rules that carry out the purposes and objectives
of the CFPA and to prevent evasions thereof. This would include, at
least in part, provisions to require covered persons or service
providers to establish and maintain reasonable policies and procedures,
such as those to create and maintain records that demonstrate
compliance with the rule when final. CFPA section 1024(b)(7) also
grants the CFPB authority to impose record retention requirements on
CFPB-supervised nondepository covered persons ``for the purposes of
facilitating supervision of such persons and assessing and detecting
risks to consumers.''
---------------------------------------------------------------------------
\40\ See 12 U.S.C. 5481(14) (defining ``Federal consumer
financial law'' to include the provisions of the CFPA).
---------------------------------------------------------------------------
CFPA section 1022(b)(3)(A) generally provides that the CFPB, by
rule, may conditionally or unconditionally exempt any class of covered
persons, service providers, or consumer financial products or services,
from any provision of the CFPA, or from any rule issued under the CFPA,
as the CFPB determines necessary or appropriate to carry out the
purposes and objectives of the CFPA, taking into consideration several
factors. For a discussion of the CFPB's proposed use of this authority,
see the discussion in part IV.A. The statutory language indicates that
the CFPB should evaluate the case for creating such an exemption in
light of its general purposes and objectives as Congress articulated
them in section 1021 of the CFPA, as described above.
C. CFPA Section 1032
CFPA section 1032(a) provides that the CFPB may prescribe rules to
ensure that the features of any consumer financial product or service,
both initially and over the term of the product or service, are fully,
accurately, and effectively disclosed to consumers in a manner that
permits consumers to understand the costs, benefits, and risks
associated with the product or service, in light of the facts and
circumstances. Under CFPA section 1032(a), the CFPB is empowered to
prescribe rules regarding the disclosure of the ``features'' of
consumer financial products and services generally. CFPA section
1032(c) provides that, in prescribing rules pursuant to CFPA section
1032, the CFPB shall consider available evidence about consumer
awareness, understanding of, and responses to disclosures or
communications about the risks, costs, and benefits of consumer
financial products or services.
D. CFPA Section 1002
Certain provisions of the CFPA, such as its prohibition on unfair,
deceptive, or abusive acts or practices, apply in connection with a
consumer financial product or service. Under CFPA section 1002(5), this
is generally defined as a financial product or service that is
``offered or provided for use by consumers primarily for personal,
family, or household purposes.'' In turn, CFPA section 1002(15) defines
a financial product or service by reference to a number of categories.
In addition, CFPA section 1002(15)(A)(xi)(II) authorizes the CFPB to
issue a regulation to define as a financial product or service, for
purposes of the CFPA, ``such other financial product or service'' that
the CFPB finds is ``permissible for a bank or for a financial holding
company to offer or to provide under any provision of a Federal law or
regulation applicable to a bank or a financial holding company, and
has, or likely will have, a material impact on consumers.'' The CFPB is
proposing to exercise this authority in proposed Sec. 1001.2(b).
IV. Discussion of the Proposed Rule
12 CFR Part 1033
A. Subpart A--General
1. Overview
Proposed subpart A would establish the coverage and terminology
necessary to implement CFPA section 1033 for this proposed rule,
beginning with proposed Sec. 1033.101, which would describe the
authority, purpose, and organization of the regulation in proposed part
1033. It contains defined terms appearing throughout the regulatory
text, which are described in this part IV.A and elsewhere in part IV
and sets forth tiered compliance dates to provide appropriate
flexibility to smaller institutions in implementing the rule's
requirements.
2. Coverage of Data Providers (Sec. 1033.111(a) Through (c))
Regulation Z Card Issuers, Regulation E Financial Institutions, and
Other Payment Facilitation Providers
In this first proposed rule to implement CFPA section 1033(a), the
CFPB is proposing to define a subset of covered persons and consumer
financial products or services that would be required to make data
available under section 1033(a) of the CFPA. The proposed rule would
cover the following consumer financial products or services, as defined
at proposed Sec. 1033.111(b)(1) through (3)--generally, Regulation E
asset accounts, Regulation Z credit cards, and products or services
that facilitate payments from a Regulation E account or a Regulation Z
credit card. The latter category--products or services that facilitate
payments from a Regulation E account or a Regulation Z credit card--
would be intended to clarify that the proposed rule would cover all
consumer-facing entities involved in facilitating the transactions the
CFPB intends to cover.
Payment data from these products and services support common
beneficial consumer use cases today, including transaction-based
underwriting, payments, deposit account switching, and comparison
shopping for bank and credit card accounts. Credit cards are
increasingly used as payment devices for everyday expenses, and credit
card transaction data have in some cases become interchangeable with
Regulation E account transaction data. In addition, digital wallet
providers hold valuable data that can provide a complete understanding
of a consumer's finances. Today, a digital wallet can initiate payments
from multiple credit cards, prepaid accounts, and checking accounts. A
digital wallet can facilitate payments from accounts that the digital
wallet provider offers through depository institution partners, or from
linked accounts that were originally issued by other institutions
(sometimes referred to as pass-through payments).
The CFPB has preliminarily determined that the marginal burden of
including other payment facilitation products and services would be
minimal given how these providers would generally already be covered as
Regulation E financial institutions. Digital wallet providers and
entities that refer to themselves as neobanks generally qualify as
Regulation E financial institutions and sometimes also may be
Regulation Z card issuers. Adopting a broad definition could help avoid
creating unintentional loopholes as the market evolves.
Covering Regulation E asset accounts, Regulation Z credit cards,
and payment facilitation products and services would have additional
benefits. This coverage would leverage existing infrastructure for
consumer-authorized data sharing, which would facilitate
implementation. Data providers generally share the
[[Page 74804]]
covered data described in this proposed rule on consumer interfaces
today, and some share covered data with third parties. Additionally,
given the current level of data sharing associated with these products
and services, the proposed coverage would prioritize these data for
greater protection compared to what is available today. In particular,
consumers' payment data can be used to access consumer funds or track
household spending. As discussed in part I.D, this proposal would
include a number of measures to foster a safe and secure data access
framework.
The SBREFA Panel recommended that the CFPB consider clarifying the
types of products that would be covered under the proposed rule.\41\ In
addition, the CFPB received feedback from small entity representatives
and other stakeholders indicating confusion about whether the CFPB
intended to cover nondepository data providers and their products, and
whether all credit card products would be included.
---------------------------------------------------------------------------
\41\ SBREFA Panel Report at 42.
---------------------------------------------------------------------------
Consistent with the Panel recommendation and the feedback received,
the proposal would make clear that a data provider generally would have
obligations to make available covered data with respect to a covered
consumer financial product or service. Proposed Sec. 1033.111(b) would
define covered consumer financial product or service to mean (1) a
Regulation E account, a defined term that would have the same meaning
as defined in 12 CFR 1005.2(b); (2) a Regulation Z credit card, a
defined term that would have the same meaning as defined in 12 CFR
1026.2(a)(15)(i); and (3) the facilitation of payments from a
Regulation E account or Regulation Z credit card. Proposed Sec.
1033.111(c) would define data provider to mean (1) a Regulation E
financial institution, as defined in 12 CFR 1005.2(i); (2) a Regulation
Z card issuer as defined in 12 CFR 1026.2(a)(7); or (3) any other
person that controls or possesses information concerning a covered
consumer financial product or service the consumer obtained from that
person. Proposed example 1 to Sec. 1033.111(c) explains that a digital
wallet provider is a data provider. The CFPB requests feedback on the
proposed definitions, including whether any further clarification is
needed to demonstrate that entities that refer to themselves as
neobanks, digital wallet providers, and similar nondepository entities
would qualify as data providers.
Other Consumer Financial Products and Services
Today, covered persons typically share information concerning
financial products and services that would not fall within the
definition of covered data in proposed Sec. 1033.211, such as
mortgage, automobile, and student loans. Similar to the payment data
that would be covered, information about these products is generally
shared through consumer interfaces and supports a variety of beneficial
use cases. A significant difference is that this information does not
typically support transaction-based underwriting across a range of
markets or payment facilitation. Accordingly, the CFPB has
preliminarily concluded that prioritizing Regulation E accounts,
Regulation Z credit cards, and payment facilitation products and
services in this proposed rule could serve to advance competition goals
across a broader range of markets. The CFPB intends to implement CFPA
section 1033 with respect to other covered persons and consumer
financial products or services through supplemental rulemaking.
When distributed electronically, needs-based benefits established
under State or local law or administered by a State or local agency are
primarily issued to consumers via EBT cards. EBT-related data are
mainly accessed directly by the consumer through private entities that
have contracted with State or local governments that administer
programs for Federal government agencies. The CFPB has received
feedback from small entity representatives and other stakeholders that
there can be limitations to the availability of EBT-related data and
that third party access to EBT data could address these issues. EBT
cards are exempt from EFTA coverage by statute; pursuant to the
Consolidated Appropriations Act of 2023, the U.S. Department of
Agriculture has been directed to engage in a rulemaking and issue
guidance on EBT card security practices.\42\
---------------------------------------------------------------------------
\42\ Public Law 117-328, 136 Stat. 5985 (2022).
---------------------------------------------------------------------------
The CFPB is considering whether to add EBT-related data to the
final rule, or whether to reach EBT cards in a subsequent rulemaking.
While EBT cards differ from the current scope of data types included in
the proposed regulation in some ways, they have some significant
similarities, including that they are used by consumers to make regular
purchases. The CFPB requests comment on whether the most appropriate
way to solve issues related to EBT data accessed directly by the
consumer is through section 1033 of the CFPA, and whether it should do
so as part of this first rulemaking related to payments data or a
subsequent rule under section 1033. The CFPB also seeks comment on
third party practices related to consumer-authorized EBT data,
including the interaction between those practices and the limitations
on uses that are not reasonably necessary in proposed Sec. 1033.421(a)
and (c). Finally, the CFPB seeks comment on the benefits and drawbacks
of enabling third party access to EBT-related data, including with
respect to data security.
3. Excluded Data Providers (Sec. 1033.111(d))
Pursuant to CFPA section 1022(b)(3), proposed Sec. 1033.111(d)
generally would exempt data providers (as defined in proposed Sec.
1033.111(c)) from the requirements of the proposed rule if they have
not established a consumer interface as of the applicable compliance
date. Proposed Sec. 1033.131 would define consumer interface as an
interface that a data provider maintains to receive requests for
covered data and make available covered data in an electronic form
usable by consumers in response to the requests. The term is intended
to encompass consumer-facing digital banking interfaces that allow
consumers to make requests for information, as described in part I.A
above.
While the vast majority of banks and credit unions offer consumer
interfaces, such as online banking or mobile banking applications, a
small number of depository institutions do not offer any such service.
For example, among credit unions with fewer than 1,000 deposit
accounts, only 21 percent offer online banking services.\43\ These
institutions tend to be very small and may not have adequate resources
to support or maintain these online or mobile banking systems. They may
also use a relationship banking model and have a more personalized
relationship with their customers.\44\
---------------------------------------------------------------------------
\43\ CFPB calculations based on NCUA data. For details on data
see part VII.B.6.
\44\ See, e.g., Consumer Fin. Prot. Bureau, Request for
Information Regarding Relationship Banking and Customer Service
(June 14, 2022), <a href="https://www.federalregister.gov/documents/2022/07/20/2022-15243/request-for-information-regarding-relationship-banking-and-customer-service">https://www.federalregister.gov/documents/2022/07/20/2022-15243/request-for-information-regarding-relationship-banking-and-customer-service</a>.
---------------------------------------------------------------------------
Some depositories do not offer digital banking in the current
environment, despite the ubiquity of computers and smartphones, broad
consumer utilization of online banking and mobile banking applications,
and the impact of the COVID-19 pandemic, which impeded many consumers'
access to
[[Page 74805]]
traditional banking channels. This suggests that, first, such entities
have not found that the business reasons to provide these services
justify the associated costs; and, second, that their customers have
not switched to institutions that do provide digital banking services,
indicating that such services may not be an important factor for such
customers when choosing where to deposit or borrow money.\45\ The CFPB
notes that it has preliminarily determined to limit this proposed
exclusion to depositories that qualify as financial institutions under
Regulation E or as card issuers under Regulation Z. Not all CFPA-
covered persons will necessarily have the same incentives to facilitate
direct customer service with consumers. For example, there may be
covered persons that do not market to or contract with consumers and
that do not have the same incentives to invest in customer service.
---------------------------------------------------------------------------
\45\ See, e.g., Miriam Cross, Credit Unions Podcast: A tiny
credit union's tall order, Am. Banker (May 25, 2023), <a href="https://www.americanbanker.com/podcast/a-tiny-credit-unions-tall-order">https://www.americanbanker.com/podcast/a-tiny-credit-unions-tall-order</a>
(discussing factors some customers of very small credit unions use
when determining whether to continue to patronize such
institutions).
---------------------------------------------------------------------------
The SBREFA Panel recommended that the CFPB consider whether to
create complete or partial exemptions for data providers, or whether to
delay implementation for certain data providers for certain aspects of
the proposed rule, such as a requirement to establish a developer
interface.\46\ The Panel also recommended that the CFPB seek comment on
how to define potential exemption eligibility requirements or
implementation tiers, such as by establishing a threshold based on
asset size or activity level, or by exempting data providers based on
entity type.\47\ Consistent with these recommendations, the CFPB
considered whether to exempt all data providers, not just certain
depository institutions, that do not provide a consumer interface and,
if so, how to structure such an exemption. However, the complicating
factors that exist for these types of depository institutions may be
less likely to exist for these types of nondepository institutions. For
example, nondepository data providers within the scope of the proposed
rule tend to be institutions whose business models are built upon
providing interfaces to consumers. This is not the case for depository
institutions that do not provide an interface for their customers. The
CFPB requests comment on whether there are nondepositories that do not
provide an interface for their customers, and if so, whether an
exemption should include them. The CFPB also seeks comment on whether
it should require any exempt depositories to make covered data
available in a non-electronic form.
---------------------------------------------------------------------------
\46\ SBREFA Panel Report at 43.
\47\ Id. at 42.
---------------------------------------------------------------------------
As noted in the discussion of the proposed rule's compliance dates,
the CFPB is proposing to provide a longer compliance period for the
smallest depository institution data providers. The CFPB also
considered not proposing an exemption for any data providers, and
instead simply giving some data providers more time to comply. However,
because of the dynamics with respect to depository institutions that do
not provide an interface for their customers, the compliance burden on
these entities would most likely outweigh the marginal benefit of the
rule covering an additional very small set of consumer accounts.
The proposed rule would not provide a grace period for depository
institutions that do not have a consumer interface as of the effective
date but subsequently offer such an interface to their customers. The
CFPB requests comment on whether such depositories should be offered
some grace period to achieve compliance. Proposed Sec. 1033.111(d)
would not exempt depositories that stop providing a customer interface
after the effective date. Such depositories possessed the ability to
provide an interface for their consumers, and so should remain subject
to the rule.
Under CFPA section 1022(b)(3)(A), the CFPB may exercise exemption
authority as it determines necessary or appropriate to carry out the
purposes and objectives of CFPA section 1033, taking into
consideration, as appropriate: (1) the total assets of the class of
covered persons; (2) the volume of transactions involving consumer
financial products or services in which the class of persons engages;
and (3) existing provisions of law which are applicable to the consumer
financial product or service and the extent to which such provisions
provide consumers with adequate protections.
The CFPB has preliminarily determined that the proposed exemption
would promote the CFPB's objectives, discussed in part I above, to
ensure that the markets for consumer financial products and services
operate transparently and efficiently to facilitate access, as well as
its objective to ensure that consumers are provided with timely and
understandable information to make responsible decisions about
financial transactions. The CFPB has also preliminarily determined that
the proposed exemption would promote the CFPA's purpose of ensuring
that markets for consumer financial products and services are
competitive. As noted above, the depository institutions that would be
exempt from the proposed rule's requirements tend to be very small
institutions that may not be as technologically sophisticated as larger
institutions and likely do not have the resources to support or
maintain the interfaces that would be required by the proposed rule.
Subjecting these institutions to the proposal could significantly
disrupt their businesses, potentially threatening access to consumer
financial products and services and reducing competition for consumer
financial products and services--both contrary to carrying out the
objectives of CFPA section 1033.
The CFPB acknowledges that some consumers would not be given the
benefits provided by the proposed rule if these entities were exempt.
However, as noted above, these small depository institutions generally
provide timely and understandable information through ongoing personal
relationships to assist customers in making decisions about financial
transactions. The CFPB seeks comment on whether the exclusion for
depository institutions that do not provide an interface for their
customers should be limited solely to the provision of the interfaces
required by the proposed rule, or whether the rule should still require
such institutions to comply with the general obligations outlined in
proposed Sec. 1033.201(a) and allow flexible compliance with this
section. The CFPB also seeks comment on whether different or additional
criteria, such as an institution's asset size or activity level, should
be taken into consideration when determining what depository
institutions would be exempt from the proposed rule.
As noted above, the CFPB considers, as appropriate, the applicable
statutory factors in CFPA section 1022(b)(3)(A). Because the
requirements of this proposed rule would focus on consumers' data, a
suitable proxy for considering two of the three factors--total assets
of the class of covered persons and the volume of transactions--would
be the number of accounts exempted. The CFPB expects the number of data
requests will be approximately proportional to the number of accounts.
By exempting depository institutions that do not have an interface, the
proposed rule would exempt approximately 0.64 percent of total deposit
accounts, a very small percentage of deposit accounts covered by the
proposed rule.
[[Page 74806]]
This exemption would treat some depository data providers
differently than nondepository ones. However, nondepository data
providers within scope of this proposed rule tend to use business
models built on the ability to innovate with respect to technology and
move quickly to implement technological changes and solutions, in
contrast to depository institutions that have not established a
consumer interface for their customers. Thus, the CFPB preliminarily
concludes that these two groups are not similarly situated for purposes
of this proposed rule. By exempting these depository institutions from
regulations that would be more costly and burdensome for them than it
would be for their peers with greater technological capabilities, the
CFPB would be promoting fair competition.
The CFPB's preliminary determination regarding exempting depository
institution data providers that do not provide a consumer interface to
their customers is specific to this proposed rule and the data that
would be covered by it. Further rulemaking under section 1033 of the
CFPA may make different determinations based upon the types of data
providers and types of data covered.
4. Compliance Dates (Sec. 1033.121)
Proposed Sec. 1033.121 would stagger dates by which data providers
need to comply with proposed Sec. Sec. 1033.201 and 1033.301 (the
obligations to make data available and establish interfaces) into four
distinct tiers to ensure timely compliance with the rule's
requirements. From the SBREFA process and other stakeholder feedback,
the CFPB understands that a number of factors may affect how quickly a
data provider could comply with the proposed rule. These include, for
example, a data provider's size, relative technological sophistication,
use of third party service providers to build and maintain software and
hardware systems, and, in the case of many data providers, the
existence of multiple legacy hardware and software systems that impact
their ability to layer on new technology.\48\ Many smaller depository
data providers will need to rely on cores and other third party service
providers to create interfaces required by the proposed rule.\49\ These
entities may experience significant wait times since many other
entities may be relying on the same providers for the development of
their interfaces.\50\ If a depository institution data provider builds
its own interface without the assistance of a third party service
provider, it may need additional time to do so.
---------------------------------------------------------------------------
\48\ Id. at 36.
\49\ Id. at 36-37.
\50\ Id. at 36.
---------------------------------------------------------------------------
The CFPB preliminarily believes nondepository data providers do not
have the same obstacles with respect to compliance as depository
institutions because they do not have as many vendors and information
technology systems that would need to be connected, and implementation
could occur in-house.\51\ Thus, these data providers would be able to
move more quickly to implement the proposed rule's requirements.
---------------------------------------------------------------------------
\51\ Id. at 38.
---------------------------------------------------------------------------
The SBREFA Panel made several recommendations related to compliance
dates. Generally, the Panel recommended that the CFPB seek comment on
ways to facilitate implementation for small entities, and on
implementation options that reduce impacts on small entities, including
staging implementation based on categories of data to be made
available, entity size, or other factors.\52\ The Panel also
recommended that the CFPB continue to study the time needed for vendors
to establish a data portal on behalf of data providers, as well as the
time needed by data providers, data aggregators, and data recipients to
integrate into data portals at the scale envisioned by the
proposal.\53\ Lastly, the Panel recommended that the CFPB consider
whether to delay implementation for certain data providers for certain
aspects of the rule, such as a requirement to establish a third party
access portal, and should seek comment on how to define implementation
tiers, such as by establishing a threshold based on asset size or
activity level.\54\ (The CFPB is proposing to define and use the term
developer interface in lieu of the SBREFA Outline's ``third-party
access portal.'')
---------------------------------------------------------------------------
\52\ Id. at 46.
\53\ Id.
\54\ Id. at 43.
---------------------------------------------------------------------------
The CFPB considered a number of alternatives to the four tiers
outlined in the proposed rule. One option was to have the same
compliance date for all data providers. For the reasons discussed in
this part IV.A, the CFPB has preliminarily determined that it is
necessary to provide some data providers with a longer compliance
period than others. The CFPB has preliminarily determined that the
proposed exemption combined with the tiered compliance dates based on
asset size or revenue appropriately balances the need to provide relief
to the smallest data providers that may not be as technologically
sophisticated as larger providers while providing a longer timeline for
compliance to entities that may need more time. The CFPB also
considered basing the compliance tiers on an institution's number of
accounts/activity level, rather than asset size or revenue. With
respect to number of accounts, the CFPB has preliminarily determined
that, because of the breadth of types of data providers and services
covered by the proposed rule, it would be difficult to define accounts
to properly segment data providers into appropriate tiers, and asset
size and revenue provide more precise metrics in which to separate
compliance tiers.
Subject to a data provider's ability to deny access, as described
in Sec. 1033.321, and the exclusion for data providers described in
proposed Sec. 1033.111(d), proposed Sec. 1033.121 would require data
providers to grant access to the interfaces required by proposed Sec.
1033.301 to consumers and third parties by four applicable compliance
dates based on asset size or revenue, depending on the type of data
provider. Under proposed Sec. 1033.121(a), the first compliance date
would occur approximately six months after publication of the final
rule in the Federal Register and would apply to depository institutions
that hold at least $500 billion in total assets, and to nondepository
institutions that generate at least $10 billion in revenue in the
preceding calendar year or are projected to generate at least $10
billion in revenue in the current calendar year. The CFPB uses the term
``total assets'' to make clear that this amount is based upon the total
consolidated assets of the institution as reported in published
financial statements, as used by the FFIEC.\55\ Under proposed Sec.
1033.121(b), the second compliance date would occur approximately one
year after Federal Register publication and would apply to depository
institutions that hold at least $50 billion in total assets but less
than $500 billion in total assets, and to nondepository institutions
that generate less than $10 billion in revenue in the preceding
calendar year and are projected to generate less than $10 billion in
revenue in the current calendar year. The CFPB has preliminarily
determined that placing all nondepository data providers in the first
two tiers for compliance appropriately balances the need to provide
data providers enough time for compliance with depository data
[[Page 74807]]
providers potentially needing additional time. Under proposed Sec.
1033.121(c), the third compliance date would occur approximately 2.5
years after Federal Register publication and would apply to depository
institutions that hold at least $850 million but less than $50 billion
in total assets. Finally, under proposed Sec. 1033.121(d), the fourth
and final compliance date would occur approximately four years after
Federal Register publication and would apply to depository institutions
with less than $850 million in total assets.
---------------------------------------------------------------------------
\55\ See, e.g., Fed. Fin. Insts. Examination Council, Large
Holding Companies, <a href="https://www.ffiec.gov/npw/Institution/TopHoldings">https://www.ffiec.gov/npw/Institution/TopHoldings</a>
(last visited Sept. 22, 2023).
---------------------------------------------------------------------------
The CFPB seeks comment on whether different or additional criteria,
such as an institution's number of accounts or other criteria, should
be taken into consideration when determining compliance dates. The CFPB
also seeks comment on the structure of each tier, and whether
nondepository institutions should be included in all four tiers.
The CFPB recognizes that data providers may need to transition
third parties to developer interfaces in a staggered order. Under the
proposed rule, a data provider not excluded from coverage could delay a
third party's access to an interface in accordance with proposed Sec.
1033.321. The CFPB seeks comment on whether the proposed rule provides
data providers sufficient flexibility for such a transition or whether
revisions to the proposed rule or additional guidance is needed. For
example, the CFPB seeks comment on whether the final rule should
include language clarifying that data providers should be granted any
period of time to fully transition third parties to the interfaces that
would be required under proposed Sec. 1033.301 to ensure that data
providers do not impede timely third party access to an interface while
accounting for reasonable risk management concerns.
5. Third Party, Authorized Third Party, Consumer, and Data Aggregator
(Sec. 1033.131)
The CFPB is proposing that a third party acting on behalf of a
consumer would be able to access covered data. Proposed Sec. 1033.131
includes several definitions that are used in describing the proposed
processes and conditions for a third party to access covered data on
behalf of a consumer. The CFPB is proposing these definitions to carry
out the objectives of CFPA section 1033.
The CFPB is proposing to define the term third party as any person
or entity that is not the consumer about whom the covered data pertains
or the data provider that controls or possesses the consumer's covered
data. The proposed rule uses the term third party to refer to entities
seeking access to covered data and to other parties, including data
aggregators.
As discussed in part III above, the CFPB interprets CFPA section
1033(a) to require data providers to make available covered data to
certain third parties ``acting on behalf'' of a consumer. The CFPB is
proposing to define the term authorized third party as a third party
that has complied with the authorization procedures described in
proposed Sec. 1033.401. Proposed Sec. 1033.401, discussed in part
IV.D, specifies what requirements a third party must satisfy to become
an authorized third party that is entitled to access covered data on
behalf of a consumer.
The CFPB is proposing to define the term data aggregator to mean an
entity that is retained by and provides services to the authorized
third party to enable access to covered data. As discussed below, some
third parties retain data aggregators for assistance in obtaining
access to data from data providers. The proposed rule includes certain
provisions in proposed Sec. 1033.431 that specify what role data
aggregators would play in the third party authorization procedures,
what information about data aggregators would have to be included in
the authorization disclosure, and what conditions data aggregators
would have to certify that they agree to as part of the third party
authorization procedures. The CFPB requests comment on whether data
aggregator is an appropriate term for describing third parties that may
provide assistance in accessing covered data or whether there are other
terms, such as ``data intermediary,'' that would be more appropriate.
Proposed Sec. 1033.131 would also define the term consumer for
purposes of part 1033. The CFPB is proposing to define the term
consumer to mean a natural person. The definition would further specify
that trusts established for tax or estate planning purposes are
considered natural persons for purposes of the definition of consumer.
The proposed definition of consumer differs from the definition of
consumer in CFPA section 1002(4), which defines one as ``an individual
or an agent, trustee, or representative acting on behalf of an
individual.'' The CFPB is proposing to define the term consumer to be a
natural person to distinguish the term from the third parties that are
authorized to access covered data on behalf of consumers pursuant to
the proposed procedures in subpart D.
6. Qualified Industry Standard (Sec. Sec. 1033.131 and 1033.141)
As discussed in part I.D, fair, open, and inclusive industry
standards are a critical element in the maintenance of an effective and
efficient data access system. To promote the development of such
external standards, the CFPB is generally proposing throughout part
1033 that indicia of compliance with certain provisions include
conformance to an applicable industry standard issued by a fair, open,
and inclusive standard-setting body. Proposed Sec. Sec. 1033.131 and
1033.141 would carry out the objectives of CFPA section 1033 by
encouraging the development of fair, open, and competitive industry
standards that would satisfy certain provisions of the proposed rule.
The CFPB also is proposing Sec. Sec. 1033.131 and 1033.141 pursuant to
its authority under CFPA sections 1022(b)(1) and 1033(d).
Proposed Sec. 1033.131 would define the term qualified industry
standard to mean a standard that is issued by a standard-setting body
that is fair, open, and inclusive. In turn, proposed Sec. 1033.141
provides that a standard-setting body is fair, open, and inclusive and
is an issuer of qualified industry standards when the body has the
following attributes: (1) openness (sources and processes used are open
to all interested parties, including consumer and other public interest
groups, authorized third parties, data providers, and data
aggregators); (2) balance (decision-making power is balanced across all
interested parties, including consumer and other public interest
groups, with no single interest dominating decision-making); (3) due
process (publicly available policies and procedures, adequate notice of
meetings and standards development, and a fair process for resolving
conflicts); (4) an impartial appeals process; (5) consensus (general
agreement, not unanimity, reached through fair and open processes); (6)
transparency (procedures are transparent to participants and publicly
available); and (7) the body has been recognized by the CFPB within the
last three years as an issuer of qualified industry standards.
Under this proposed rule, indicia of compliance with a particular
rule provision would include conformance to a qualified industry
standard. However, an entity does not have to show adherence to a
qualified industry standard to demonstrate compliance with a provision
of the rule, as long as its conduct meets the requirement of the rule
provision. Conversely, adherence to a qualified industry standard would
not guarantee that the entity has complied
[[Page 74808]]
with the rule provision. There are provisions in the proposed rule that
would not mention qualified industry standards at all, generally
because their terms do not leave the same room for compliance to be
informed by adherence to an external standard.
The one instance in which the proposed rule would take account of
external standards in a manner that differs from that described above
is the proposed requirement in Sec. 1033.311(b) that data providers
use standardized formats. There, the CFPB is proposing that if a data
provider's interface makes covered data available in a format that is
set forth in a qualified industry standard, then the interface is
deemed to satisfy the proposed requirement to use a standardized
format. The CFPB is also proposing that a data provider's developer
interface would be deemed to satisfy the proposed format requirement
if, in the absence of an industry standard, it makes covered data
available in a format that is widely used by the developer interfaces
of other similarly situated data providers. For certain other proposed
requirements, indicia of compliance may include conformance to a
qualified industry standard; for this one alone, however, conformance
with such a standard would be deemed to constitute compliance. CFPA
section 1033(d) requires the CFPB by rule to prescribe standards to
promote the development of standardized data formats. Conformance with
a qualified industry standard with respect to standardized formats
would carry out this objective of CFPA section 1033(d).
To promote a competitive data access framework in which standard-
setting bodies do not inappropriately use their position to benefit a
single set of interests, the CFPB has preliminarily determined they
should reflect a full range of relevant interests--consumers and firms,
incumbents and challengers, and large and small actors. The proposed
definition would respond to the recommendation of the SBREFA Panel that
the CFPB consider to what extent existing external standards for data
sharing should inform the proposed rule.\56\ In line with the Panel
recommendation, the CFPB has preliminarily determined that external
standards would reflect the requisite input from the full range of
relevant interests, and therefore would properly serve as indicia of
compliance with various provisions of proposed part 1033, if the
standards were to achieve the status of being a qualified industry
standard as defined. A qualified industry standard, by definition,
would be developed, adopted, and maintained by a fair, open, and
inclusive standard-setting body, and such a body would, per the
proposed attributes listed above, necessarily be a body that reflects
the full range of relevant interests.
---------------------------------------------------------------------------
\56\ SBREFA Panel Report at 44.
---------------------------------------------------------------------------
The proposed rule would be agnostic about what specific technical
format a data provider must use and would not envision that the CFPB
would develop the infrastructure through which data could be processed,
as was suggested by a small entity representative.\57\ While the CFPB
has not ruled out these types of alternatives, the CFPB has
preliminarily determined that they could inappropriately stifle ongoing
evolution of financial industry data-sharing practices.
---------------------------------------------------------------------------
\57\ Id. at 28.
---------------------------------------------------------------------------
The proposed attributes of the qualified industry standard
definition would be consistent with longstanding OMB Circular A-119,
which addresses Federal participation in the development and use of
standards,\58\ and which is well accepted by standard-setting experts
as setting forth ``a limited set of foundational attributes of
standardization activities.'' \59\ Nonetheless, the CFPB acknowledges
that the open banking system comprises arguably a more diverse and
larger set of participants than many other environments to which
industry standards might apply. Accordingly, the CFPB requests comment
on the adequacy of these proposed attributes for ascertaining whether
an open banking standard-setting body is fair, open, and inclusive. In
this regard, the CFPB emphasizes that it intends the proposed
attributes to pertain only to industry standards and standard-setting
bodies; the attributes would not be pertinent with respect to standards
issued by governmental standard-setting bodies such as the National
Institute of Standards and Technology.
---------------------------------------------------------------------------
\58\ OMB Circular A-119 was originally published in 1996; see
<a href="https://www.govinfo.gov/content/pkg/FR-1996-12-27/html/96-32917.htm">https://www.govinfo.gov/content/pkg/FR-1996-12-27/html/96-32917.htm</a>.
The current Circular, effective January 27, 2016, is available at
<a href="https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf">https://www.whitehouse.gov/wp-content/uploads/2020/07/revised_circular_a-119_as_of_1_22.pdf</a>.
\59\ March 17, 2022 testimony of Dr. James Olthoff, Performing
the Non-Exclusive Functions and Duties of the Under Secretary of
Commerce for Standards and Technology & Director, of the Department
of Commerce's NIST, before the United States House of
Representatives Committee on Science, Space and Technology
Subcommittee on Research and Technology, available at <a href="https://www.nist.gov/speech-testimony/setting-standards-strengthening-us-leadership-technical-standards">https://www.nist.gov/speech-testimony/setting-standards-strengthening-us-leadership-technical-standards</a>.
---------------------------------------------------------------------------
The CFPB's proposed approach to defining qualified industry
standards aligns with the statutory purposes and objectives for the
CFPB established in section 1021 of the CFPA, which include ensuring
that consumer financial markets, such as the market for data sharing,
are fair, transparent, competitive, and efficient, and ensuring that
Federal consumer financial law is enforced consistently, without regard
to the status of a person as a depository institution. Moreover, the
proposed industry standard definition would align with the language of
CFPA section 1033(e)(3) that rules do not inappropriately ``promote the
use of any particular technology.''
CFPB Recognition of Industry Standard-Setting Bodies
Proposed Sec. 1033.141(b) provides that a standard-setting body
may request that the CFPB recognize it as an issuer of qualified
industry standards. The attributes of fairness, openness, and inclusion
listed as factors in proposed Sec. 1033.141(a)(1) through (6) would
inform the CFPB's consideration of the request. CFPB recognition would
help provide clarity to market participants that a standard-setting
body has the necessary attributes of fairness, openness, and inclusion.
It would also incentivize standard-setting bodies to devote the
resources needed to achieve these attributes by providing them with
validation from the CFPB, which would encourage adoption of their
standards. The CFPB requests comment on the procedures it should use to
recognize standard-setting bodies. For example, the CFPB requests
comment on whether it should recognize a given body before, after, or
at about the same time as the body seeks to issue a qualified industry
standard or whether the recognition procedures should be flexible
enough to accommodate all of those possibilities.
The CFPB intends to subsequently provide guidance on the substance
of the standards issued by the qualified industry standard-setting
bodies recognized by the CFPB. The CFPB requests comment on how to
provide guidance and, in particular, on how to ensure that the
substance is consistent with the provisions of this proposed rule, as
finalized.
B. Subpart B--Obligation To Make Covered Data Available
1. Overview
As discussed in part I.C, disagreements around the types of data
that should be available to consumers and authorized third parties have
limited consumers' ability to use their data and imposed costs on data
providers and third parties. Proposed subpart B would seek to resolve
these questions with respect to how CFPA section 1033(a) applies by
establishing a
[[Page 74809]]
framework for the general categories of data that would need to be made
available, including specific data fields that have been significant
sources of disagreement, and exceptions from these requirements.
Proposed subpart B also restates the general requirement in CFPA
section 1033(a) for data providers to make covered data available in an
electronic form usable by consumers.
2. Obligation To Make Covered Data Available (Sec. 1033.201)
Consistent with the general obligation in section 1033(a) of the
CFPA, proposed Sec. 1033.201(a) would require a data provider to make
available to a consumer and an authorized third party, upon request,
covered data in the data provider's control or possession concerning a
covered consumer financial product or service that the consumer
obtained from the data provider. These covered data would need to be
made available in an electronic form usable by consumers and authorized
third parties. Compliance with the requirements in proposed Sec. Sec.
1033.301 and 1033.311 also would be required.
The CFPB interprets CFPA section 1033(a) to set forth a general
obligation to make available data in an electronic form usable by
consumers and authorized third parties that is independent of other
obligations proposed in subpart C. Even if a data provider fully
complied with the requirements of proposed subpart C with respect to
consumer and developer interfaces, they might attempt to circumvent the
objectives of section 1033 by engaging in other conduct that
effectively makes data unavailable or unusable to consumers and
authorized third parties. The CFPB requests comment on whether it would
be clearer to interpret CFPA section 1033(a) to set forth explicit
prohibitions against (1) actions that a data provider knows or should
know are likely to interfere with a consumer's or authorized third
party's ability to request covered data, and (2) making available
information in a form or manner that a data provider knows or should
know is likely to render the covered data unusable. Such a provision
would carry out the objectives of CFPA section 1033, and would prevent
evasion, pursuant to the CFPB's authority under section 1022(b)(1), by
ensuring data providers do not engage in conduct not specifically
addressed by the proposal but that nonetheless could practically
interfere with the exercise of rights under CFPA section 1033(a). The
CFPB also requests comment on whether there are specific practices that
the proposal should identify that might effectively make data
unavailable or unusable to consumers and authorized third parties,
other than those already identified in proposed subpart C, such as fees
for data access, as discussed with respect to proposed Sec.
1033.301(c), or unreasonable access caps, as discussed with respect to
proposed Sec. 1033.311(c)(2).
The CFPB requests comment on whether other language might be
appropriate to achieve this objective. For example, section 3022(a) of
the Public Health Service Act (PHSA) \60\ and implementing regulations
promulgated by HHS \61\ address the practice of ``information
blocking,'' defined, in part, as a practice that ``is likely to
interfere with, prevent, or materially discourage access, exchange, or
use of'' electronic health information, except as required by law or
specified by HHS rule. The CFPB seeks comment on whether this language
would be appropriate to include as a general prohibition implementing
CFPA section 1033, considering that the market for electronic health
information and the applicable legal framework are distinct from the
context and authorities applicable to this proposal.
---------------------------------------------------------------------------
\60\ 42 U.S.C. 300jj-52.
\61\ 45 CFR 171.103; 85 FR 25642 (May 1, 2020).
---------------------------------------------------------------------------
The CFPB also requests comment on whether, instead of proposing to
restate CFPA section 1033(a) as setting forth an obligation independent
of the specific provisions in proposed subpart C, it should instead
interpret CFPA section 1033(a) to mean that a data provider's
obligations under the statute are fully satisfied if the data provider
complies with all of the requirements of proposed subpart C.
With respect to a data provider's obligation to make available data
in its control or possession, proposed Sec. 1033.201(a) would mean a
data provider would have to make a consumer's data available in any
language maintained in records under its control or possession. For
example, a data provider would have to make Spanish and English
language records available if account records were maintained in
Spanish and English.
The CFPB received questions during the SBREFA process about how
current the covered data must be, including whether data providers
could simply provide the last monthly statement rather than being
required to make available recent transactions and the current account
balance. In the facilitation of payment transactions, data providers
regularly refresh covered data, and such data are often necessary to
enable common beneficial use cases, like transaction-based underwriting
and personal financial management. Both depository and nondepository
data providers typically make available recently updated transaction
and account balance data through online or mobile banking applications.
Proposed Sec. 1033.201(b) would interpret section 1033(a) to require
that, in complying with proposed Sec. 1033.201(a), a data provider
would need to make available the most recently updated covered data
that it has in its control or possession at the time of a request. For
example, a data provider would need to make available information
concerning authorized but not yet settled debit card transactions. When
consumers make a request for information concerning a consumer
financial product or service, the most recently updated information in
a data provider's control or possession is likely to be most usable.
However, proposed Sec. 1033.201(b) is not intended to limit a
consumer's right to access historical covered data. The CFPB requests
comment on whether the provision regarding current data would benefit
from additional examples or other clarifications. The CFPB also
requests input on issues in the market today with data providers making
available only older information that is not fully responsive to a
consumer's request.
3. Covered Data (Sec. 1033.211)
CFPA section 1033(a) generally requires data providers to make
available ``information in the control or possession of the covered
person concerning the consumer financial product or service that the
consumer obtained from such covered person, including information
relating to any transaction, series of transactions, or to the account
including costs, charges and usage data.'' Proposed Sec. 1033.211
would implement this broad language to define the information that a
data provider would need to make available under the general obligation
in proposed Sec. 1033.201(a). Proposed Sec. 1033.211 uses the term
covered data instead of the statutory term ``information'' and defines
covered data to mean several categories of information, as applicable:
transaction information (including historical transaction information),
account balance, information to initiate payment to or from a
Regulation E account, terms and conditions, upcoming bill information,
and basic account verification information.
Several small entity representatives and other stakeholders raised
concerns during the SBREFA process with respect to a proposal the CFPB
was considering to require a broader set of data than
[[Page 74810]]
what would be included in this proposed rule, such as certain payment
routing and demographic information that is not typically shared with
consumers or third parties. Commenters stated that requiring that this
information be made available could introduce new fraud and privacy
risks to consumers that do not exist in the market today, would not
support particularly beneficial use cases, and could impose significant
new burden on data providers as some data are held across multiple
information technology systems. Many data provider commenters supported
an approach to require data that are already available through digital
banking, or otherwise supported the inclusion of periodic statement
information.
The SBREFA Panel recommended that the CFPB further consider whether
the proposed rule should require data providers to make available all
six categories of information set forth in the SBREFA Outline.\62\ In
considering the types of information that data providers would need to
make available, the Panel recommended that the CFPB consider the small
entity representatives' feedback on costs to small data providers with
respect to the following: accessing data stored with multiple vendors
or under the control of other third party service providers;
restrictions on data providers' ability to share information; and
whether sharing certain information could expose data providers and
authorized third parties to legal liability or reputational risk.\63\
---------------------------------------------------------------------------
\62\ SBREFA Panel Report at 43.
\63\ Id.
---------------------------------------------------------------------------
The proposed covered data definition would leverage existing
operational and legal infrastructure: data providers generally make
this covered data available through digital account management and
existing laws require most of the proposed categories of information to
be disclosed through periodic statement and account disclosure
requirements. The CFPB preliminarily concludes that requiring data that
is generally made available to consumers today would support most
beneficial consumer use cases, including transaction-based
underwriting, payment credential verification, comparison shopping,
account switching, and personal financial management. The CFPB
understands that certain of the proposed categories of information,
such as upcoming bill information, historical transaction information,
information to initiate a transfer to or from a Regulation E account,
and basic account identity information can support account switching
because it can ease the account opening process, identify recurring
payments that need to be set up at the new account, and transfer funds
out of the old account. The CFPB requests comment on the benefits and
data needs for consumers who are in the process of switching accounts.
The proposed covered data definition also would address several
issues in the consumer-authorized data sharing system today, including
(1) maximizing consumer benefits by clarifying which types of data
would be included in the consumer's CFPA section 1033 right; (2)
addressing potential data provider anti-competitive conduct and
incentives to withhold particular types of data; and (3) promoting
conditions for standardization in the market. Currently, data providers
have different interpretations of the categories of information that
would be included in the proposed covered data definition and provide
authorized third parties with inconsistent access to that data. Pricing
terms, like APR, have been particularly contested. Inconsistent access
to consumer-authorized data may prevent the development of new use
cases and the improvement of existing use cases. In addition,
inconsistent access to consumer-authorized data may be hindering
standardization in the market, and therefore further hindering
competition and innovation, as parties to data access agreements must
negotiate individual categories of information that can be shared.
To address concerns about data providers restricting access to
specific pieces of information, the proposed rule also would give
examples of information that would fall within the covered data
categories. These examples are illustrative and are not an exhaustive
list of data that a data provider would be required to make available
under the proposed rule. A data provider would only have an obligation
to make available applicable covered data; for example, a Regulation E
financial institution providing only a Regulation E account would not
need to make available a credit card APR or billing statement. The CFPB
requests comment on whether additional data fields should be specified
to minimize disputes about whether the information would fall within
the proposed covered data definition. In addition, the proposed rule
would allow flexibility as industry standards develop while minimizing
ambiguity over the types of information that must be made available.
The CFPB also requests comment on whether the proposed categories of
information provide sufficient flexibility to market participants to
develop qualified industry standards.
These provisions would carry out the objectives of CFPA section
1033 of ensuring data are usable by consumers and authorized third
parties by focusing on data that stakeholders report are valuable for
third party use cases and that are generally under the control or
possession of all covered persons. These provisions also would promote
the use and development of standardized formats for carrying out the
objectives of CFPA section 1033(d) by encouraging industry to focus
format standardization efforts around these data categories.
Transaction Information
Transaction information under proposed Sec. 1033.211(a) refers to
information about individual transactions, such as the payment amount,
date, payment type, pending or authorized status, payee or merchant
name, rewards credits, and fees or finance charges. Some bank data
providers have provided feedback suggesting that a rule not cover
pending transactions. These stakeholders have cited concerns about how
the information is subject to change and is not provided on monthly
account statements. Some bank data providers have stated that pending
transaction information is already provided through online or mobile
banking applications today, or otherwise supported including that
information. The CFPB preliminarily concludes that pending transaction
information supports a variety of beneficial use cases, including fraud
detection and personal financial management, and therefore should be
included within the proposed covered data definition.
Transaction information also would include historical transaction
information in the control or possession of the data provider. Proposed
Sec. 1033.211(a) explains that a data provider would be deemed to make
available sufficient historical transaction information if it makes
available at least 24 months of such information. The CFPB is aware
that historical transaction data supports a variety of use cases,
including transaction-based underwriting, account switching, and
personal financial management. However, data providers do not make a
consistent amount of historical transaction information available, so a
consumer's ability to access historical data depends on their provider.
For example, some nondepository data providers appear to make over five
years of historical transaction data available, while some bank data
providers limit historical
[[Page 74811]]
transaction data to 3, 6, 12, 24, or 30 months.
Many stakeholders, including third party small entity
representatives during the SBREFA process, have provided feedback that
24 months of historical transaction data would support the vast
majority of consumer use cases. Some data provider and consumer
advocate stakeholders have explained that 24 months would be consistent
with the recordkeeping requirements in Regulation E and Regulation Z.
The CFPB preliminarily concludes that setting a safe harbor at a
minimum of 24 months would ensure that consumers have access to
sufficient historical transaction data for common beneficial use cases,
while providing compliance certainty to data providers. This amount
would also be consistent with the existing recordkeeping timeframes in
Regulation E, 12 CFR 1005.13, and Regulation Z, 12 CFR 1026.25. The
CFPB also understands that data providers typically control or possess
more than 24 months of historical transaction data and may continue to
make more than 24 months available. In the SBREFA Outline, the CFPB
considered a data parity approach to historical transaction data, where
a data provider would only need to share as much historical transaction
data as it makes available through a consumer interface.\64\ However,
the CFPB is concerned that, in practice, a data parity approach would
be difficult to enforce and would leave some consumers without
sufficient historical transaction data to support transaction-based
underwriting, account switching, and other use cases.
---------------------------------------------------------------------------
\64\ SBREFA Outline at 27.
---------------------------------------------------------------------------
The CFPB requests comment on whether the transaction information
examples are sufficiently detailed and consistent with market
practices. The CFPB also requests comment on whether to retain the safe
harbor for historical transaction data and whether a different amount
of historical transaction data would be more appropriate. The CFPB also
requests comment on whether and how the rule should require that data
providers make available historical data for other categories of
information, such as account terms and conditions, whether such
historical data are kept in the ordinary course of business today, and
the use cases for such data.
Account Balance
The account balance category would include available funds in an
asset account and any credit card balance. The CFPB requests comment on
whether this term is sufficiently defined or whether additional
examples of account balance, such as the remaining credit available on
a credit card, are necessary.
Information To Initiate Payment To or From a Regulation E Account
This category of information would require a data provider to make
available information to initiate a payment to or from the consumer's
Regulation E account. The proposed rule explains that this category
includes a tokenized account and routing number that can be used to
initiate an ACH transaction. In complying with its obligation under
proposed Sec. 1033.201(a), a data provider would be permitted to make
available a tokenized account and routing number instead of, or in
addition to, a non-tokenized account and routing number.
Regulation E account numbers are typically shared through consumer
interfaces and are required to be disclosed under existing Regulation E
periodic statement provisions. Account numbers and routing numbers can
be used to initiate a transfer of funds to or from a Regulation E
account over the ACH network, enabling common use cases like initiating
payments and depositing loan proceeds. Although data providers have
recourse under private contracts, network rules, and commercial law to
recover funds stolen by an unauthorized entity, many data providers
have expressed concern about their Regulation E obligations and urged
the CFPB to allow the sharing of TANs with authorized third parties.
These TANs, which are in use today, may help mitigate fraud risks to
consumers and data providers. TANs allow data providers to identify
compromised points more easily and revoke payment credentials on a
targeted basis (rather than issuing a new account number to the
consumer). However, some third parties have argued that TANs do not
support certain use cases, such as allowing third parties to print
checks to pay vendors, initiating payments by check or wire, and
detecting fraud.
The CFPB preliminarily concludes that TANs allow third parties to
enable most beneficial payment use cases while mitigating fraud risks,
and therefore data providers should have the option of making TANs
available to authorized third parties in lieu of full account and
routing numbers. The CFPB notes that a TAN would only meet this
requirement if it contained sufficient information to initiate payment
to or from a Regulation E account. The CFPB requests comment on whether
to allow TANs in lieu of non-tokenized account and routing numbers,
including whether TANs would mitigate fraud risks and, in contrast,
whether TANs have any limitations that could interfere with beneficial
consumer use cases, and whether and how adoption and use of TANs might
be informed by qualified industry standards. The CFPB also requests
comment on whether data providers should also be required to make
available information to initiate payments from a Regulation Z credit
card.
Terms and Conditions
Terms and conditions generally refer to the contractual terms under
which a data provider provides a covered consumer financial product or
service. The proposed rule would describe several non-exhaustive
examples of information that would constitute terms and conditions.
Certain terms and conditions, such as pricing, reward programs
terms, and whether an arbitration agreement applies to the product,
support beneficial use cases, like comparison shopping and personal
financial management. Authorized third parties could use this
information to help consumers more easily understand and compare the
terms applicable to a covered consumer financial product or service.
Since pricing is a fundamental term that is provided in account opening
disclosures and change in terms disclosures, the CFPB is proposing to
include APR, annualized percentage yield, fees, and other pricing
information in this category. In addition, this provision would benefit
consumers because consumers today may not be able to easily find this
information through their online or mobile banking applications, and
some data providers may not be consistently sharing it with authorized
third parties. The CFPB requests comment on whether the final rule
should include more examples of information that must be made available
under terms and conditions.
Upcoming Bill Information
Upcoming bill information would include bills facilitated through
the data provider, such as payments scheduled through the data provider
and payments due from the consumer to the data provider. For example,
it would include the minimum amount due on the data provider's credit
card billing statement, or a utility payment scheduled through a
depository institution's online bill payment service. The CFPB
preliminarily concludes that this information would be necessary to
support personal financial management
[[Page 74812]]
and consumers who are switching accounts. The CFPB seeks comment on
whether this category is sufficiently detailed to support situations
where a consumer is trying to switch recurring bill payments to a new
asset account, such as transferring a monthly credit card payment to a
new bank.
Basic Account Verification Information
Basic account verification information would be limited to the
name, address, email address, and phone number associated with the
covered consumer financial product or service.
The CFPB is aware that certain pieces of identifying consumer
information are commonly shared with third parties today for beneficial
use cases. For example, a lender may seek to verify that loan funds are
being deposited into an account that belongs to the consumer who is
applying for the loan, or a mortgage underwriter may seek to verify
that funds in a savings account belong to the mortgage applicant. On
the other hand, third parties have raised concerns that data providers
sometimes limit access to this information, and requested that the CFPB
should clarify that account verification information must be shared.
However, many small entity representatives and other stakeholders
raised significant concerns about the proposed rule covering other
identity information that is not typically shared today, such as
demographic data, as the beneficial use cases for such information is
limited compared to the significant privacy and discrimination risks.
The CFPB preliminarily concludes that requiring data providers to
share basic account verification information is necessary to ensure the
usability of the covered data. For example, confirming that funds in a
savings account do, in fact, belong to the consumer applying for a
mortgage loan is necessary to determine whether the mortgage
underwriting can rely on that information. Similarly, a loan provider
is mitigating fraud risks when it ensures that the name, address, email
address, and phone number on a recipient account matches the
information of the loan applicant; matching information helps ensure
that the funds are going to the correct account, and that the account
opening notifications are not going to someone who stole the consumer's
identity. Email addresses and phone numbers are increasingly being used
as substitutes for consumer and account identifiers, particularly in
the payments market where such information can be used to send a
person-to-person payment. Accordingly, the CFPB has preliminarily
determined that limiting basic account verification information to the
name, address, email address, and phone number associated with the
covered consumer financial product or service would facilitate the most
common use cases and is consistent with market practices today.
The CFPB considered whether to include SSNs, as SSNs are shared for
some beneficial consumer use cases, like mortgage underwriting.
However, the sharing of SSNs is not ubiquitous. The CFPB preliminarily
concludes that SSNs may continue to be shared as appropriate but, given
the risks to consumers, the proposed rule would not require data
providers to make them available.
The CFPB requests comment on whether the proposed basic account
verification information category would accommodate or unduly interfere
with beneficial consumer use cases today. Given privacy and security
concerns about unintentionally covering other kinds of information that
are not typically shared today, the CFPB also requests comment on
whether it is appropriate to limit this category to only a few specific
pieces of information.
4. Exceptions (Sec. 1033.221)
The CFPB is proposing in Sec. 1033.221 four exceptions to the
requirement to make data available under the proposed rule, along with
some clarifications of data that do not fall within these exceptions.
These proposed exceptions would implement section 1033(b) of the CFPA
by restating the statutory language and providing certain
interpretations.
The first exception would cover any confidential commercial
information, including an algorithm used to derive credit scores or
other risk scores or predictors. The CFPB is aware that some data
providers have argued that certain account information falls within
this exception because such information is an input or output to a
proprietary model. The CFPB is proposing to clarify that information
would not qualify for this exception merely because it is an input to,
or an output of, an algorithm, risk score, or predictor. For example,
APR and other pricing information are sometimes determined by an
internal algorithm or predictor, but such information would not fall
within this exception.
The second exception would cover any information collected by a
data provider for the purpose of preventing fraud or money laundering,
or detecting, or making any report regarding other unlawful or
potentially unlawful conduct. The CFPB received feedback during the
SBREFA process that at least one data provider cited this exception to
avoid including general account information, such as the name on the
account.\65\ To avoid misuse of this exception where information has
multiple applications, the CFPB is proposing to clarify that
information collected for other purposes does not fall within this
exception. For example, name and other basic account verification
information would not fall within this exception.
---------------------------------------------------------------------------
\65\ SBREFA Panel Report at 25.
---------------------------------------------------------------------------
The third exception would cover information required to be kept
confidential by any other provision of law. Information would not
qualify for this exception merely because a data provider must protect
it for the benefit of the consumer. For example, a data provider cannot
restrict access to the consumer's own information merely because that
information is subject to privacy protections.
The fourth exception would cover any information that a data
provider cannot retrieve in the ordinary course of its business with
respect to that information.
The proposed definition for covered data in proposed Sec. 1033.211
would include information that is made available to consumers and
authorized third parties today or is required to be disclosed under
other existing laws. The exceptions proposed in Sec. 1033.221 are
narrow, and covered data would not typically qualify for any of these
exceptions; note that proposed Sec. 1033.351(b)(1) would require a
data provider to create a record of what covered data are not made
available pursuant to an exception in proposed Sec. 1033.221 and
explain why the exception applies.
During the SBREFA process, small entity representatives and other
stakeholders provided examples of data that could fall within the
exceptions, such as proprietary algorithms or underwriting models, but
the examples would not be considered covered data and accordingly would
not fall within the scope of the proposed rule. The SBREFA Panel
recommended that the CFPB continue to seek feedback on how to interpret
these exceptions, and further consider whether there are specific
pieces of information that should be covered under any of these
exceptions.\66\ Consistent with the Panel recommendation, the CFPB
requests comment on whether it should include additional examples of
data that would or would not fall within the exceptions, and whether
this provision sufficiently mitigates concerns that data providers may
cite these exceptions on a
[[Page 74813]]
pretextual basis. The CFPB intends to monitor the market for pretextual
use of the CFPA section 1033 exceptions.
---------------------------------------------------------------------------
\66\ Id. at 43.
---------------------------------------------------------------------------
C. Subpart C--Establishing and Maintaining Access
1. Overview
The provisions in proposed subpart C would address some of the
significant questions and challenges described in part I.C by
clarifying the terms on which data are made available and the mechanics
of data access, including basic operational, performance and security
standards, and other policies and procedures. In particular, certain
provisions would ensure that data providers make covered data available
to third parties through a developer interface rather than through the
screen scraping of a consumer interface. Other provisions would include
procedures to facilitate the ability of third parties to request data
and ensure data providers are accountable for their obligations in
proposed subpart C. In addition, to prevent data providers from
inhibiting consumers' exercise of this statutory right, the CFPB is
proposing a bright-line prohibition against data providers charging
fees for establishing and maintaining the required interfaces or for
receiving requests and making available covered data in response to
requests. Together, the provisions in proposed subpart C would
contribute to a safe, reliable, secure, and competitive data access
framework.
2. General Requirements (Sec. 1033.301)
Requirement To Establish and Maintain Interfaces (Sec. 1033.301(a))
The CFPB proposes in Sec. 1033.301(a) to require a data provider
subject to the requirements of proposed part 1033 to maintain a
consumer interface and to establish and maintain a developer interface.
A data provider's consumer interface and developer interface would be
required to satisfy the requirements in proposed Sec. 1033.301(b) and
(c). The developer interface would be subject to additional
requirements in proposed Sec. 1033.311. Proposed Sec. 1033.301(a)
would carry out the objectives of CFPA section 1033 by ensuring
consumers and authorized third parties can make requests and receive
timely and reliable access to covered data in a usable electronic form,
and would fulfill other objectives discussed below with respect to
proposed Sec. Sec. 1033.301 and 1033.311, including promoting the
development and use of standardized formats.
The terms consumer interface and developer interface are defined in
proposed Sec. 1033.131 as interfaces through which a data provider
receives requests for covered data and makes covered data available in
an electronic form usable by consumers and authorized third parties in
response to the requests. Proposed Sec. 1033.111(d) would exclude data
providers that do not have a consumer interface from the requirements
of proposed part 1033. Thus, proposed Sec. 1033.301(a) would not
require a data provider to establish a consumer interface, but only to
maintain a consumer interface that the data provider already has.
The CFPB is not aware of significant concerns regarding the ability
of consumers to access covered data from consumer interfaces. The CFPB
intends for the provisions in the proposed rule applicable to consumer
interfaces generally to ensure the continuation of current data
provider practices. Based on its market expertise, the CFPB expects
that data providers' existing consumer interfaces will generally
satisfy the data provider's obligation under proposed Sec. 1033.301(a)
to maintain an interface for making covered data available to
consumers. The CFPB requests comment on the extent, if any, to which
the provisions applicable to consumer interfaces in proposed subpart C
would be inconsistent with current practices.
A consumer interface generally would not satisfy a data provider's
obligation under proposed Sec. 1033.301(a) to establish and maintain a
developer interface, which must satisfy requirements in proposed Sec.
1033.311. These provisions in proposed Sec. 1033.311 are intended, in
part, to ensure that data providers do not rely on the screen scraping
of a consumer interface to satisfy their obligations under CFPA section
1033(a). As recommended by the SBREFA Panel, the CFPB considered
whether screen scraping should be an alternative means of sharing data
with third parties in some circumstances.\67\ The CFPB is not proposing
to require that data providers permit screen scraping as an alternative
method of access, such as to address unavailability when the data
provider's system interface is down for maintenance. As discussed in
part I.C, screen scraping as a whole presents risks to consumers and
the market and relying on credential-based screen scraping would
complicate the mechanics of data access, particularly with respect to
authentication and authorization procedures for data providers. The
proposed requirements in subpart C, such as the performance
specifications for developer interfaces in Sec. 1033.311(c), would
ensure that consumers and authorized third parties have reliable access
to consumers' covered data.
---------------------------------------------------------------------------
\67\ Id. at 44.
---------------------------------------------------------------------------
As also recommended by the SBREFA Panel, the CFPB considered
whether there are forms of screen scraping that would reduce the impact
of developer interface service interruptions on third parties and
minimize costs to data providers and third parties while ensuring data
quality and security.\68\ The CFPB has not identified any such forms of
screen scraping. Tokenized screen scraping, in which third parties use
a tokenized version of a consumer's account credentials, provides data
security and consumer control benefits when compared with screen
scraping that uses a consumer's account credentials. However, it does
not mitigate screen scraping's inherent overcollection, accuracy, and
consumer privacy risks, and it would impose costs on data providers in
addition to the costs of a developer interface. Additionally, because
it would inherently rely on the delivery of unstructured data,
permitting data providers to comply with the proposed rule through
tokenized screen scraping would not meaningfully advance the statutory
mandate to promote the development and use of standardized formats.
---------------------------------------------------------------------------
\68\ Id.
---------------------------------------------------------------------------
In some cases, authorized third parties that are natural persons
might have a need to access information in a human-readable form
because they lack the means of accessing a developer interface. The
CFPB requests comment on how a data provider would make covered data
available in a usable electronic form to such authorized third parties.
The SBREFA Panel recommended that the CFPB clarify whether the
online financial account management portal that the CFPB was
considering with respect to direct access--i.e., a consumer interface--
would include a data provider's mobile banking portal in addition to
its online banking portal.\69\ While both online banking and mobile
banking applications could serve as consumer interfaces, proposed Sec.
1033.301(a) would not require that each of the applications satisfy all
of the proposed requirements that would apply to consumer interfaces,
as long as collectively the two applications satisfy the requirements.
The CFPB requests comment on the extent to which data providers
currently inform consumers using mobile banking applications that
additional information about consumers' accounts may be available
[[Page 74814]]
through the providers' online banking interfaces.
---------------------------------------------------------------------------
\69\ Id. at 43.
---------------------------------------------------------------------------
Machine-Readable Files (Sec. 1033.301(b))
The CFPB proposes in Sec. 1033.301(b) to require a data provider
upon specific request to make covered data available in a machine-
readable file that a consumer or authorized third party can retain and
transfer into a separate information system. This proposed requirement
would apply both to data providers' consumer interfaces and to their
developer interfaces. This proposed provision would implement the
requirement of CFPA section 1033(a) that covered data be made available
in a usable electronic form by ensuring that consumers and authorized
third parties can retain electronic files. In addition, the proposed
provision would directly implement CFPA section 1033(d).
The proposed provision would allow a data provider to offer
additional consumer interfaces that do not satisfy Sec. 1033.301(b)
(for example, a smartphone application that does not provide
information in a readily printable or downloadable format), as long as
the data provider makes covered data available upon request in readily
printable or downloadable formats through one of its other consumer
interfaces, such as its digital banking interface.
The CFPB preliminarily understands that, as a general matter,
existing consumer and developer interfaces typically already provide
covered data in a form that would comply with this requirement and may
be subject to similar requirements by other applicable laws.\70\
---------------------------------------------------------------------------
\70\ See, e.g., Cal. Civ. Code sections 1798.100, 1798.130; Va.
Consumer Data Prot. Act section 59.1-577 (2023); Colo. Priv. Act
section 6-1-1306(1)(e); MRS tit. 10, ch. 1057, section 9607(1)(D);
Mass. Info. Priv. & Sec. Act section 10. However, California exempts
information subject to the GLBA, and Colorado and Virginia exempt
financial institutions subject to the GLBA. Separately, the EU's
GDPR requires data portability (Reg. (EU) 2016/679, art. 20, O.J. (L
119) 1 (Apr. 27, 2016)).
---------------------------------------------------------------------------
The CFPB therefore has preliminarily determined that the proposed
requirement in Sec. 1033.301(b) would impose little or no cost on data
providers beyond the cost to establish and maintain a developer
interface in the first place; i.e., the proposed requirement would
impose little or no cost beyond the cost that would be imposed by
proposed Sec. 1033.301(a) (discussed above). The CFPB has also
preliminarily determined that proposed Sec. 1033.301(b) would provide
important consumer benefits, such as by enabling them to share their
data with others, including providers of competing financial products
and services.\71\
---------------------------------------------------------------------------
\71\ See, e.g., Michael S. Barr et al., Consumer Autonomy and
Pathways to Portability in Banking and Financial Services, Univ. of
Mich. Ctr. on Fin., L. & Policy Working Paper No. 1 (Nov. 1, 2019),
<a href="https://financelawpolicy.umich.edu/sites/cflp/files/2021-07/umich-cflp-working-paper-consumer-autonomy-and-data-portability-pathways-Nov-3.pdf">https://financelawpolicy.umich.edu/sites/cflp/files/2021-07/umich-cflp-working-paper-consumer-autonomy-and-data-portability-pathways-Nov-3.pdf</a>.
---------------------------------------------------------------------------
Fees Prohibited (Sec. 1033.301(c))
The CFPB proposes in Sec. 1033.301(c) to prohibit a data provider
from imposing any fees or charges for establishing or maintaining the
interfaces required by proposed Sec. 1033.301(a) or for receiving
requests or making available covered data through the interfaces. This
provision is proposed pursuant to the CFPB's authority under CFPA
sections 1033(a) and 1022(b)(1). The CFPB has preliminarily determined
that the prohibition would be necessary and appropriate to effectuate
consumers' rights under CFPA section 1033 by ensuring that consumers
and authorized third parties are not impeded from exercising consumers'
statutory rights because of fees, which would be contrary to the
objectives of the statute.
The CFPB notes that proposed Sec. 1033.301(c) would not prohibit a
data provider from charging a fee for specific services, other than
access to covered data, through the consumer interface. For example, a
data provider would not violate the proposed rule if the data provider
were to impose a fee for sending an international remittance transfer,
which a consumer authorizes and consents to through the consumer
interface. Further, the proposed rule would not address account
maintenance fees that a data provider might charge to consumers
regardless of whether they use the interface.
A data provider that does not already have a developer interface
would incur some upfront and ongoing costs to establish and maintain
one, and data providers in general will incur some cost to maintain the
interfaces as well as a marginal cost of providing covered data through
the interfaces. The CFPB has therefore considered whether its proposed
rule should permit a reasonable, cost-based fee to recover the upfront
or fixed costs associated with establishing and maintaining the
interfaces. There also may be some costs associated with providing
covered data through the interfaces. The CFPB has preliminarily
determined, however, that the marginal cost of providing covered data
in response to a request is negligible.
Each data provider is the sole supplier of its customers' financial
data and therefore able to exert market power over the prices or fees
it charges for authorized access to consumers' data. Data providers
have in the past restricted data access for third parties. These
restrictions have anti-competitive effects and, by allowing data
providers to charge prices for access that are in excess of marginal
cost, may harm consumers and third parties. For example, data providers
may have an incentive to charge fees in excess of their marginal cost
to third parties to make certain competing third party products or
services less profitable or less attractive to consumers. In addition,
data providers charging different prices to different third parties may
also result in competitive harm to consumers and third parties,
especially in a market where some data providers have financial
interests in third parties they are affiliated with, or act as third
parties themselves. Even under circumstances where data providers would
not directly gain, price discrimination of this type may distort
competition among third parties and harm consumers. Further, prolonged
negotiations about fees could delay or obstruct third parties being
granted access expeditiously to data providers' developer interfaces,
in turn undermining the core consumer data access right. The CFPB
requests comment on the above analysis with respect to proposed Sec.
1033.301(c). The CFPB also requests comment on whether any clear and
unambiguous set of conditions, limitations, or other parameters exist
or should be created such that, subject to such parameters, data
providers could charge reasonable, standardized fees that neither
obstruct the access right due to cost nor impede third parties' access
to data provider interfaces due to negotiations over fee amounts or
schedules.
During the SBREFA process, data provider small entity
representatives provided feedback that data providers should be
permitted to charge fees to third parties for access to covered
data.\72\ Further, the SBREFA Panel recommended that the CFPB consider
how data providers would need to defray the costs associated with
developing and maintaining a developer interface.\73\ The CFPB will
continue to consider this recommendation as it reviews comments on this
NPRM and proceeds to develop a final rule. In this regard, the CFPB
notes that the proposed rule differs in many respects from the CFPB's
proposals under
[[Page 74815]]
consideration at the time the SBREFA Panel provided the above
recommendation. Most importantly, the CFPB is now proposing to require
data providers to make available a narrower set of covered data than
the CFPB was considering at the SBREFA stage. Small data providers
generally already make the proposed covered data available through
their consumer interfaces. Accordingly, the CFPB expects that it will
be relatively low cost for smaller data providers to make covered data
available through developer interfaces.
---------------------------------------------------------------------------
\72\ SBREFA Panel Report at 30.
\73\ Id. at 44.
---------------------------------------------------------------------------
3. Requirements Applicable To Developer Interfaces (Sec. 1033.311)
As discussed in part I.C, data providers' developer interfaces do
not function according to a consistent set of terms, resulting in data
that may not be readily usable. In addition, credential-based screen
scraping presents security, privacy, and other risks. To foster a safe,
reliable, secure, and competitive data access framework, the CFPB is
proposing in Sec. 1033.311 additional requirements that would apply
specifically to the developer interface described in proposed Sec.
1033.301(a). Proposed Sec. 1033.311(a) would provide that a developer
interface required by Sec. 1033.301(a) must satisfy proposed
provisions at Sec. 1033.311(b) through (d). These provisions would
interpret data providers' obligation to ``make available'' covered data
in a ``usable'' electronic form, fulfill the mandate in CFPA section
1033(d) to prescribe by rule standards to promote the use and
development of standardized formats, and otherwise carry out the
objectives of CFPA section 1033.
Format of Covered Data (Sec. 1033.311(b))
The CFPB proposes in Sec. 1033.311(b) to require a developer
interface to make available covered data in a standardized format. This
requirement would implement the mandate in CFPA section 1033(d) that
the CFPB prescribe standards to promote the use and development of
standardized formats. The interface would be deemed to satisfy this
requirement if it makes covered data available in a format set forth in
a qualified industry standard (as defined in proposed Sec. 1033.131).
In the absence of such a standard, a data provider's interface would be
deemed to satisfy proposed Sec. 1033.311(b) if it makes available
covered data in a format that is widely used by the developer
interfaces of other similarly situated data providers with respect to
similar data and is readily usable by authorized third parties.
This proposed provision would be intended to ensure that developer
interfaces make covered data available in a standardized format that is
readily processable by the information systems of third parties across
the market, including new entrants and small entities. This proposed
provision also is intended to transition the market from relying on
screen scraping unstructured data from consumer interfaces.
Consistent with the objectives discussed in part I.D, this
provision would seek to foster a reliable and competitive data access
framework. Small entity representatives during the SBREFA process
indicated that consistent standards would reduce costs for small third
parties and small data providers, and would promote competition by
reducing integration costs across the market.\74\ The SBREFA Panel
recommended that the CFPB promote consistency in standards for the
availability of information, including the format and transmission of
information that data providers make available to third parties.\75\
Consistent with that feedback, this provision would seek to ensure that
the information systems of, in particular, new-entrant and small-entity
third parties can process covered data from the full range of data
providers across the market by reducing the extent of varied and
idiosyncratic formats that impel reliance on intermediaries to provide
data in a usable format.
---------------------------------------------------------------------------
\74\ Id. at 28.
\75\ Id. at 44.
---------------------------------------------------------------------------
The CFPB has not determined whether qualified industry standards
for data formats presently exist. The proposed rule would seek to
accommodate the potential absence of such standards by stating that, in
their absence, a data provider could rely on proposed Sec.
1033.311(b)(2) if its developer interface uses a format used by other
similarly situated data providers. The CFPB has preliminarily
determined that, consistent with CFPA section 1033(a) and (d),
requiring covered data to be made available in a usable and
standardized format would reduce variation across the market and
promote greater consistency of data formats.
Because proposed Sec. 1033.311(b)(2) would allow data providers
across the market to rely on more than one formatting standard, the
CFPB acknowledges it would not promote the use and development of a
single formatting standard, such as what might be set forth within a
qualified industry standard described under proposed Sec.
1033.311(b)(1). The CFPB requests comment on the extent of variation in
data formats used for consumer-authorized access today, and the
usability of those formats by third parties. The CFPB also requests
comment on whether the implementation timelines discussed in part
IV.A.4 with respect to proposed Sec. 1033.121 should be adjusted to
enable data providers to rely on a standardized format that is set
forth in a qualified industry standard as of the applicable compliance
date. For example, the CFPB requests comment on whether it should allow
for a separate, later compliance date for Sec. 1033.311(b).
Proposed Sec. 1033.311(b)(2) would apply only in the absence of a
qualified industry standard. The CFPB requests comment on whether
proposed Sec. 1033.311(b)(2) should also be available if there is a
qualified industry standard. Alternatively, the CFPB requests comment
on whether it should omit proposed Sec. 1033.311(b)(2), meaning that
in the absence of a qualified standard only the general requirement
under proposed Sec. 1033.311(b) to make available covered data in a
standardized format would apply. The CFPB further requests comment on
whether there are other approaches that it should deem to comply with
Sec. 1033.311(b), instead of or in addition to proposed Sec.
1033.311(b)(1) or (2). Separately, CFPA section 1033(d) does not define
the term ``format'' and proposed Sec. 1033.311(b) would not include a
definition. The CFPB requests comment on whether a definition is needed
and whether format should be defined to mean the specifications for
data fields, status codes, communication protocols, or other elements
to ensure third party systems can communicate with the developer
interface.
Commercially Reasonable Performance for Data Providers' Developer
Interfaces (Sec. 1033.311(c)(1))
The CFPB proposes in Sec. 1033.311(c)(1) to require that a data
provider's developer interface perform at a commercially reasonable
level, and to include provisions regarding what commercially reasonable
means. This provision would carry out the objectives of CFPA section
1033 by clarifying how a data provider would make available covered
data in a usable form to authorized third parties under CFPA section
1033(a).
Information available to the CFPB indicates that the performance of
data providers' developer interfaces is neither uniform nor always on
par with what one would reasonably expect given the state of
technology. Specifically, the state of technology enables consumer
interfaces to operate at consistently high availability, performance,
and data freshness levels,
[[Page 74816]]
which many data providers' developer interfaces do not meet. With
respect to uniformity, data from the Provider Collection indicated that
providers report widely varying uptime and response time or latency
measurements. This non-uniformity persists both across similarly
situated providers and across the various consumer or developer
interfaces a data provider may make available. The CFPB has
preliminarily determined that the performance of data providers'
developer interfaces needs both to improve and to become more
consistent and predictable from where that performance is today. In
that regard, the CFPB has preliminarily determined that a quantitative
minimum performance level would achieve a sufficient level of
consistency and predictability.
The CFPB proposes the requirements for commercially reasonable
performance of data providers' developer interfaces in proposed Sec.
1033.311(c)(1) pursuant to its authority provided by CFPA section
1033(a) and the CFPB's interpretation of how data providers must make
available covered data in an electronic form that is usable by
consumers and authorized third parties. Specifically, the CFPB proposes
the requirements for commercially reasonable performance in proposed
Sec. 1033.311(c)(1) to implement the statutory requirement that
covered data be made available in an electronic form usable by
authorized third parties. This proposed requirement would carry out the
objectives of CFPA section 1033 by ensuring that data providers make
available data on a basis that enables third parties to provide
products and services, including those that compete with products and
services offered by the data provider.
Quantitative Minimum Performance Specification (Sec.
1033.311(c)(1)(i))
The current performance of data providers' developer interfaces is
not always adequate, and whether a developer interface's performance is
commercially reasonable cannot only be based on the performance of a
data provider's peers. Thus, the CFPB has preliminarily determined that
it is necessary to propose a firm quantitative floor to ensure that the
performance improves in the near term.
The quantitative minimum performance specification in proposed
Sec. 1033.331(c)(1)(i) would be a response rate of at least 99.5
percent. That is, the CFPB proposes that the performance of a developer
interface cannot be commercially reasonable unless the interface has a
response rate (defined below) of at least 99.5 percent. The CFPB has
preliminarily determined that this level of response rate would be an
appropriate floor for commercially reasonable performance for several
reasons. The CFPB understands from the Provider Collection that a
number of data providers' extant consumer interfaces generally meet or
exceed this level of performance. Further, the level of performance
data providers can achieve with their consumer interfaces, in which the
amount and variety of data are generally broader than the set of data
the CFPB proposes to define as covered data, suggests this level of
performance should be achievable for developer interfaces. In general,
ensuring parity between consumer interfaces and developer interfaces
will ensure that data providers make available data in a manner that is
usable to consumers. In addition, Australia and the United Kingdom set
their thresholds at 99.5 percent.\76\ Their thresholds are calibrated
from existing endpoints of data providers in both countries and suggest
that data providers generally are able to meet a 99.5 percent
threshold.\77\ Moreover, the substantial preponderance of the
respondents to the Provider Collection meet or exceed that level of
performance. Thus, the CFPB has preliminarily determined that data
provider interfaces cannot perform to commercially reasonable standards
below a quantitative minimum performance specification of 99.5 percent.
The CFPB requests comment specifically on what role qualified industry
standards should have, if any, regarding the quantitative minimum
performance specification set forth in the final rule.
---------------------------------------------------------------------------
\76\ Australia Consumer Data Standards, Availability
Requirements, <a href="https://consumerdatastandardsaustralia.github.io/standards/#availability-requirements">https://consumerdatastandardsaustralia.github.io/standards/#availability-requirements</a> (last visited Sept. 16, 2023);
Open Banking Ltd., Operational Guidelines--Availability, <a href="https://standards.openbanking.org.uk/operational-guidelines/availability-and-performance/key-indicators-for-availability-and-performance-availability/latest/">https://standards.openbanking.org.uk/operational-guidelines/availability-and-performance/key-indicators-for-availability-and-performance-availability/latest/</a> (last visited Sept. 16, 2023).
\77\ In the period from July 2022 to July 2023, UK account
providers had an average weighted Open Banking API availability of
99.66 percent. See Open Banking Ltd., API Performance Stats, <a href="https://www.openbanking.org.uk/api-performance/">https://www.openbanking.org.uk/api-performance/</a> (last visited Sept. 16,
2023). From December 1, 2021, through September 1, 2023, Australian
data holders maintained a platform availability of 96.28 percent.
See Australian Consumer Data Right, Performance, <a href="https://www.cdr.gov.au/performance">https://www.cdr.gov.au/performance</a> (last visited Sept. 16, 2023).
---------------------------------------------------------------------------
Defining Proper Response Rate
The CFPB proposes to specify in Sec. 1033.311(c)(1)(i) how the
proper response rate would be calculated within a given time period,
such as a month: that rate would be the number of proper responses by
the interface divided by the total number of queries to the interface.
A proper response would be a response, other than an error message
during unscheduled downtime, that meets the following three criteria:
(1) the response either fulfills the query or explains why the query
was not fulfilled; (2) the response complies with the requirements of
proposed part 1033; and (3) the response is provided by the interface
within a commercially reasonable amount of time. With respect to the
third criterion, the CFPB proposes that the amount of time cannot be
commercially reasonable if it is more than 3,500 milliseconds. It is
possible under the CFPB's proposed rule that the amount of time for the
response would not be commercially reasonable even if it were less than
3,500 milliseconds. The CFPB requests comment on whether any generally
applicable industry standard sets forth an amount of time that should
be used in lieu of 3,500 milliseconds.
The CFPB proposes that any responses by and queries to the
interface during scheduled downtime for the interface would be excluded
from the calculation of the proper response rate. Further, the CFPB
proposes that any downtime of the interface would qualify as scheduled
downtime only if the data provider has provided reasonable notice of
the downtime to all third parties to which the data provider has
granted access to the interface. The CFPB also proposes that the total
amount of scheduled downtime for the interface must be reasonable.
Adherence to a qualified industry standard would be an indication that
the notice of downtime and the total amount of downtime are reasonable.
The CFPB requests comment on whether it should provide additional
detail on the amount of scheduled downtime that would constitute a
reasonable amount. The CFPB also requests comment on whether it should
provide additional detail on when and how a data provider must provide
notice of scheduled downtime to third parties for the notice to be
reasonable. For example, the Australia Consumer Data Standards state
that normal planned outages should be reported to third parties with at
least one week of lead time, and the UK Open Banking Standards provide
that notice for planned downtime should be given at least five business
days in advance.\78\
---------------------------------------------------------------------------
\78\ See Consumer Data Standards, Availability Requirements,
<a href="https://consumerdatastandardsaustralia.github.io/standards/#session-requirements">https://consumerdatastandardsaustralia.github.io/standards/#session-requirements</a> (last visited Oct. 2, 2023); Open Banking Ltd., Change
and Communication Management--Downtime, <a href="https://standards.openbanking.org.uk/operational-guidelines/change-and-communication-management/downtime/latest/">https://standards.openbanking.org.uk/operational-guidelines/change-and-communication-management/downtime/latest/</a> (last visited Oct. 2,
2023).
---------------------------------------------------------------------------
[[Page 74817]]
Indicia of Commercially Reasonable Performance (Sec.
1033.311(c)(1)(ii))
Proposed Sec. 1033.311(c)(1) would require that the performance of
a data provider's developer interface be commercially reasonable. While
satisfaction of the quantitative minimum of 99.5 percent in proposed
Sec. 1033.311(c)(1)(i) would be necessary for commercially reasonable
performance, it would not be sufficient. That is, under the CFPB's
proposed rule it is possible that the performance of a data provider's
developer interface would not be commercially reasonable
notwithstanding that it does satisfy the quantitative minimum.
To provide a regulatory mechanism and incentive through which the
performance of data providers' developer interfaces would improve in
the future beyond the quantitative minimum, the CFPB is proposing, in
addition to that minimum, two indicia of commercially reasonable
performance in Sec. 1033.311(c)(1)(ii) that can be expected to evolve
over time. The first would be whether the performance of the interface
meets the applicable performance specifications set forth in a
qualified industry standard, as defined in proposed Sec. 1033.131. The
CFPB has preliminarily determined that the recurring process of
developing, adopting, and revising a standard that is a qualified
industry standard under the CFPB's proposed definition of that term
would be probative of whether performance of the developer interface is
commercially reasonable because it would take into account the
interests of a wide variety of stakeholders, as discussed more fully in
proposed Sec. 1033.141.
The second would be whether the performance meets the applicable
performance specifications achieved by the developer interfaces
established and maintained by similarly situated data providers. As the
performance of similarly situated data providers' interfaces improves,
the performance of a given data provider's developer interface also
would have to improve to continue to meet this indicator of commercial
reasonability. Conversely, as the performance of the given data
provider's developer interface improves, that improvement would lead
other similarly situated data providers to improve the performance of
their interfaces to meet the performance of the given data provider.
The CFPB requests comment on whether additional indicia would be
appropriate and what they should be. Currently, agreements and
standards name and describe specifications, such as latency and uptime,
for the performance of data providers' developer interfaces. The CFPB
requests comment on whether the final rule, instead of referring
broadly to ``applicable performance specifications,'' should name and
describe certain specifications. For example, rather than providing
that indicia of compliance include meeting the applicable performance
specifications achieved by the developer interfaces of similarly
situated data providers, the final rule could provide that indicia
include meeting the latency and uptime specifications achieved by the
interfaces of the other data providers.
The CFPB also notes that each data provider would have some
information about the performance of other data providers' interfaces
because (as discussed below) the CFPB is proposing in Sec. 1033.341(c)
to require all data providers to disclose publicly the quantitative
proper response metric for their developer interfaces. The CFPB also
seeks comment on what sources of market information data providers
would use to evaluate the performance of their peers' developer
interfaces.
Access Cap Prohibition for Data Providers' Interfaces (Sec.
1033.311(c)(2))
The CFPB proposes in Sec. 1033.311(c)(2) to prohibit a data
provider from unreasonably restricting the frequency with which it
receives and responds to requests for covered data from an authorized
third party through the data provider's developer interface. Such
restrictions are commonly known as ``access caps'' or ``rate limits.''
CFPA section 1033(a) requires that data providers make available
covered data upon request. The CFPB has preliminarily determined that
this proposed provision would be necessary and appropriate to
effectuate consumers' statutory rights under CFPA section 1033 by
ensuring that consumers and their authorized third parties are not
impeded from exercising consumers' statutory rights, including through
unreasonably frequent data requests by other authorized third parties.
Under proposed Sec. 1033.311(c)(2), a data provider would be
prohibited from unreasonably restricting the frequency with which it
receives and responds to requests for covered data from an authorized
third party through its developer interface, except as set forth in
certain sections. Those sections are proposed Sec. 1033.221, which
restates the statutory exceptions in CFPA section 1033(b); proposed
Sec. 1033.321, which describes the risk management reasons applicable
to denying a third party's access to an interface; proposed Sec.
1033.331(b), which identifies the conditions for when a data provider
must respond to an information request; and proposed Sec. 1033.331(c),
which identifies other reasons a response would not be required.
The CFPB does not intend that proposed Sec. 1033.311(c)(2) would
allow a data provider to impose restrictions that would override a
consumer's authorization, including the frequency with which an
authorized third party requests data. Instead, the proposed provision
would allow restrictions only if they reasonably target a limited set
of circumstances in which a third party requests information in a
manner that poses an unreasonable burden on the data provider's
developer interface and impacts the interface's availability to other
authorized third party requests. To prevent abuse of this provision,
proposed Sec. 1033.311(c)(2) provides that any frequency restrictions
must be applied in a manner that is non-discriminatory and consistent
with the reasonable written policies and procedures that the data
provider establishes pursuant to proposed Sec. 1033.351(a). Indicia
that any frequency restrictions applied are reasonable would include
that they adhere to a qualified industry standard.
The CFPB proposes in Sec. 1033.311(c)(2) to prohibit unreasonable
access caps for developer interfaces pursuant to both its authority
under CFPA sections 1033(a) and 1022(b)(1). A data provider that
imposes an access cap for which it has no reasonable basis would not be
making available covered data upon request by authorized third parties.
Prohibiting unreasonable access caps would ensure consumers and third
parties are not impeded from exercising consumers' rights under the
statute based on unreasonable limits imposed by the data provider.
The CFPB requests comment on whether the proposed provision should
be defined more narrowly to prevent data providers from interfering
with a consumer's authorization or whether additional guidance is
needed to prevent abuse. For example, the CFPB requests comment on
whether the final rule should include a presumption that access caps
are unreasonable unless undertaken for a period only as long as
necessary to ensure a third party request does not interfere with the
receipt of and response to requests from other third parties accessing
the interface.
[[Page 74818]]
The CFPB also requests comment on whether data providers should be
permitted to restrict the total amount of covered data that third
parties request over a given period of time and on whether proposed
part 1033 should treat small versus large data providers differently in
this regard. The CFPB also requests comment on whether there should be
different restrictions on data providers' access caps in cases where
the consumer is actively online with a third party requesting data
access, as opposed to when data are being automatically refreshed
without a consumer present.
Security Specifications (Sec. 1033.311(d))
The CFPB is proposing to require data providers to implement
several data security features in their consumer and developer
interfaces. This provision would implement CFPA section 1033(a) by
clarifying how a data provider would ensure it is making data available
to a consumer, including an authorized third party, in a manner that
would carry out the objectives of CFPA section 1033. Certain provisions
also would promote the use and development of standardized formats,
consistent with CFPA section 1033(d).
Access Credentials
As discussed throughout part I, third parties' credential handling
practices--typically resulting from their reliance on credential-based
screen scraping--can raise significant security, risk management,
privacy, and accuracy risks to the system as a whole. Proposed Sec.
1033.311(d)(1) would seek to prevent data providers from relying on a
third party's use of consumer credentials to access the developer
interface.
When they employ screen scraping, third parties generally must
store consumer account credentials they obtain so they can be reused to
collect data as necessary to support the product or service a consumer
is using. Because third parties collect data from many consumers at
once, they must collect and store many sets of consumer credentials.
This creates security and fraud risks: bad actors might target third
parties and attempt to cause a data breach because these third parties
store large quantities of sensitive consumer information. The longer a
third party stores consumer credentials before deleting them, and the
less rigorous a third party is in employing cybersecurity practices to
protect those credentials, the more likely such a breach will occur. If
a breach occurs--whether because of inadequate cybersecurity or
credential storage practices, or for any other reason--the consumers to
whom the leaked credentials correspond may suffer invasions of privacy
or financial harms. This is especially the case for the kinds of funds-
storing and payment accounts that would be covered by this proposed
rule; a breach which results in the theft of credentials could cause
unauthorized transactions or fraudulent use of consumers' personal
financial data. For data providers, designing developer interfaces that
operate using consumers' access credentials would heighten the risks
described in part I.C and create specific risks to data providers. For
example, a data provider may face greater difficulty ensuring
legitimate access by third parties using a consumer's credentials,
impairing its efforts to prevent truly unauthorized access by criminals
or other bad actors. The widespread use of consumers' access
credentials in a developer interface could also raise risk management
concerns.\79\
---------------------------------------------------------------------------
\79\ See generally Fed. Rsrv. Sys., FDIC, OCC, Interagency
Guidance on Third-Party Relationships: Risk Management (June 6,
2023), <a href="https://occ.gov/news-issuances/news-releases/2023/nr-ia-2023-53a.pdf">https://occ.gov/news-issuances/news-releases/2023/nr-ia-2023-53a.pdf</a>.
---------------------------------------------------------------------------
To avoid these problems from arising because of how a data
provider's developer interface is designed, proposed Sec.
1033.311(d)(1) would prohibit a data provider from allowing a third
party to access the data provider's interface by using any credentials
that a consumer uses to access the consumer interface.
The CFPB understands that in current arrangements between data
providers and third parties for use of data providers' developer
interfaces, the data provider often authenticates the consumer using
that consumer's digital banking credentials. In such cases, the CFPB
understands that the third party itself does not request, access, use,
or retain the consumer's credentials; instead, after procuring a
consumer's authority to access data, the third party `passes' the
consumer directly to the data provider, who authenticates the consumer
using the consumer's digital banking credentials, and then provides the
third party with a secure access token. The CFPB seeks comment on
whether and, if so, how the proposed rule should address this practice.
The CFPB also understands that, in some cases, entities that act as
service providers to data providers may develop, deploy, and maintain
developer interfaces on behalf of those data providers whose technical
specifications and requirements entail those service providers
retaining and using consumers' credentials. Such arrangements can
provide lower-cost routes for smaller data providers to offer developer
interfaces, which benefits all participants in the open banking system
and, ultimately, consumers. The CFPB does not intend for proposed Sec.
1033.311(d)(1) to interfere with such arrangements but seeks comment on
situations where an entity acts as both such a service provider and a
third party.
Security Program
Proposed Sec. 1033.311(d)(2) would address general data security
requirements for the data provider's developer interface. Because the
proposed definition of covered data includes transaction information,
information for initiating payments to or from a consumer's account,
and other sensitive financial information, poor data security measures
would expose consumers to significant harm, such as fraud or identity
theft. As the CFPB noted in a recent circular, information security
weaknesses can result in data breaches, cyberattacks, exploits,
ransomware attacks, and other exposure of consumer data.\80\ To prevent
these harms, the proposed rule would require data providers to apply to
their developer interfaces a data security program that satisfies the
GLBA Safeguards Framework. The proposed rule would require a data
provider that is not a GLBA financial institution to apply the
information security program required by the FTC's Safeguards Rule.\81\
---------------------------------------------------------------------------
\80\ Consumer Fin. Prot. Bureau, Consumer Financial Protection
Circular 2022-04 (Aug. 11, 2022), <a href="https://www.consumerfinance.gov/compliance/circulars/circular-2022-04-insufficient-data-protection-or-security-for-sensitive-consumer-information/">https://www.consumerfinance.gov/compliance/circulars/circular-2022-04-insufficient-data-protection-or-security-for-sensitive-consumer-information/</a>.
\81\ 16 CFR part 314.
---------------------------------------------------------------------------
The CFPB has preliminarily determined that the GLBA Safeguards
Framework appropriately addresses data security risks for developer
interfaces in the market for consumer-authorized financial data. The
GLBA Safeguards Framework generally requires each financial institution
to develop, implement, and maintain a comprehensive written information
security program that contains safeguards that are appropriate to the
institution's size and complexity, the nature and scope of the
institutions' activities, and the sensitivity of the customer
information at issue. These safeguards must address specific elements
set forth in the rule. The framework provides a process for ensuring
that such a program is commensurate with the risks faced by the
financial institution rather than a rigid list of prescriptions. This
flexible,
[[Page 74819]]
risk-based approach allows it to adapt to changing technology and
emerging data security threats.
Requiring data providers to apply the GLBA Safeguards Framework
would also reduce burden by avoiding duplicative or inconsistent data
security requirements. The CFPB understands that all or nearly all data
providers are already subject to the GLBA Safeguards Framework, and
therefore would be able to adapt their information security programs to
the risks created by the developer interface. For example, a State
member bank would apply the information security program that it had
developed pursuant to the Interagency Guidelines Establishing
Information Security Standards issued by the Board of Governors of the
Federal Reserve System.\82\
---------------------------------------------------------------------------
\82\ 12 CFR part 208, app. D-2.
---------------------------------------------------------------------------
The CFPB considered proposing to require data providers to adopt
additional reasonable policies and procedures regarding the data
security of the interfaces for third parties. Such a requirement would
share the GLBA Safeguards Framework's flexibility to accommodate
changing technology and emerging threats while avoiding the potential
uncertainty of applying the GLBA Safeguards Framework's existing
requirements to the open banking system. But a general policies and
procedures requirement would lack the additional detail of the GLBA
Safeguards Framework. Data providers already face a general obligation
to avoid inadequate data security measures under the CFPA's prohibition
on unfair, deceptive, and abusive acts and practices.\83\ Supplying
additional detail to a general policies and procedures requirement has
several potential drawbacks. For example, the CFPB may end up adopting
substantially similar requirements to the GLBA Safeguards Framework,
thus subjecting data providers to duplicative data security
regulations. Or the CFPB might adopt additional clarifications that are
inconsistent with the Federal functional regulators' interpretation of
the GLBA Safeguards Framework. For these reasons, the CFPB declines to
propose a general policies-and-procedures requirement for data security
but seeks comment on such a requirement.
---------------------------------------------------------------------------
\83\ Consumer Fin. Prot. Bureau, Consumer Financial Protection
Circular 2022-04 (Aug. 11, 2022), <a href="https://www.consumerfinance.gov/compliance/circulars/circular-2022-04-insufficient-data-protection-or-security-for-sensitive-consumer-information/">https://www.consumerfinance.gov/compliance/circulars/circular-2022-04-insufficient-data-protection-or-security-for-sensitive-consumer-information/</a>.
---------------------------------------------------------------------------
Although the CFPB understands that the data security of data
providers' interfaces for third parties is generally regulated by
existing law, the proposed definition of data provider is broad enough
to encompass a diverse array of entities. While the CFPB understands
that all or virtually all data providers are GLBA-covered financial
institutions, the proposed rule would remove any uncertainty by making
compliance with the GLBA Safeguards Framework a requirement for any
developer interface. For data providers not subject to the Interagency
Guidelines issued by the Federal functional regulators,\84\ the
proposed rule would require compliance with the FTC's Safeguards Rule.
As the FTC explained in its recent amendments to the Safeguards Rule,
the Safeguards Rule is designed to operate without the benefit of
direct guidance by an examining agency.\85\ For this reason, the CFPB
has preliminarily determined that the FTC's Safeguards Rule is
appropriate for data providers that might not have the direct
supervision of one of the Federal functional regulators that implement
the Interagency Guidelines.
---------------------------------------------------------------------------
\84\ See 12 CFR 1016.3(k) (defining ``Federal functional
regulator'' as the Board of Governors of the Federal Reserve System,
the OCC, the Board of Directors of the FDIC, the NCUA Board, and the
Securities and Exchange Commission).
\85\ 86 FR 70272, 70287 (Dec. 9, 2021).
---------------------------------------------------------------------------
This proposed rule would implement CFPA section 1033(a) by
clarifying how a data provider must make available data upon request to
a consumer, which would include an authorized third party. Establishing
a consistent set of data security requirements to developer interfaces
will help ensure that developer interfaces are only making data
available to consumers and authorized third parties consistent with the
scope of a consumer's request and do not present unreasonable risks to
the security, confidentiality, and integrity of covered data.
4. Interface Access (Sec. 1033.321)
Proposed Sec. 1033.321 would clarify the circumstances under which
a data provider would be permitted to block a consumer's or third
party's access to its consumer or developer interface without violating
the general obligation of CFPA section 1033(a). In particular, a data
provider would not be required to make available covered data to a
person or entity that presents significant risks to the data provider's
data security or risk management program. It would be inconsistent with
CFPA section 1033(a) for a data provider to make available covered data
to persons or entities that present unreasonable risks to the security
of the data provider's safety and soundness, information systems, or
consumers, or where a data provider could not take steps to ensure they
are making available covered data to an actual consumer or authorized
third party.
Risk Management (Sec. 1033.321(a) Through (c))
The CFPB recognizes that data providers have legitimate interests
in making data available only to authenticated consumers and
authenticated authorized third parties and in a way that avoids
unreasonable risks to consumers and protects covered data. CFPA section
1033(a) does not expressly address how a data provider must take risk
management concerns into account when making data available. However,
as discussed in this section below, the CFPB has preliminarily
determined that CFPA section 1033(a) authorizes procedures to clarify
the circumstan
[…truncated; see source link]This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.