[Federal Register Volume 89, Number 222 (Monday, November 18, 2024)]
[Rules and Regulations]
[Pages 90838-90998]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2024-25079]
[[Page 90837]]
Vol. 89
Monday,
No. 222
November 18, 2024
Part II
Consumer Financial Protection Bureau
-----------------------------------------------------------------------
12 CFR Parts 1001 and 1033
Required Rulemaking on Personal Financial Data Rights; Final Rule
Federal Register / Vol. 89 , No. 222 / Monday, November 18, 2024 /
Rules and Regulations
[[Page 90838]]
-----------------------------------------------------------------------
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: Final rule.
-----------------------------------------------------------------------
SUMMARY: The Consumer Financial Protection Bureau (CFPB) is issuing a
final rule to carry out the personal financial data rights established
by the Consumer Financial Protection Act of 2010 (CFPA). The final rule
requires banks, credit unions, and other financial service providers to
make consumers' data available upon request to consumers and authorized
third parties in a secure and reliable manner; defines obligations for
third parties accessing consumers' data, including important privacy
protections; and promotes fair, open, and inclusive industry standards.
DATES: This final rule is effective January 17, 2025.
Compliance dates: Data providers must comply with the requirements
in 12 CFR part 1033, subparts B and C beginning April 1, 2026; April 1,
2027; April 1, 2028; April 1, 2029; or April 1, 2030, pursuant to the
criteria set forth in Sec. 1033.121(c).
FOR FURTHER INFORMATION CONTACT: George Karithanom, Regulatory
Implementation and Guidance Program Analyst, Office of Regulations, at
202-435-7700 or https://reginquiries.consumerfinance.gov/. If you
require this document in an alternative electronic format, please
contact [email protected].
SUPPLEMENTARY INFORMATION:
Table of Contents
Abbreviations and Acronyms
I. Overview
A. Summary of the Final Rule
B. Market Background
II. The Proposal and Other Procedural Background
A. Outreach
B. Summary of the Proposed Rule
C. 2024 Industry Standard-Setting Final Rule
III. Legal Authority
A. CFPA Section 1033
B. CFPA Sections 1022(b) and 1024(b)(7)
C. CFPA Section 1002
IV. Discussion of the Final Rule
12 CFR part 1033
General Comments Received on the Proposal
A. Subpart A--General
B. Subpart B--Making Covered Data Available
C. Subpart C--Data Provider Interfaces; Responding to Requests
D. Subpart D--Authorized Third Parties
12 CFR part 1001
V. Effective and Compliance Dates
VI. CFPA Section 1022(b) Analysis
A. Statement of Need
B. Data and Evidence
C. Coverage of the Rule
D. Baseline for Consideration of Costs and Benefits
E. Potential Benefits and Costs to Consumers and Covered Persons
F. Potential Impacts on Insured Depository Institutions and
Insured 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. Final Regulatory Flexibility Analysis
VIII. Paperwork Reduction Act
IX. Congressional Review Act
X. Severability
Abbreviations and Acronyms
ACH = Automated Clearing House
ANPR = Advance Notice of Proposed Rulemaking
API = Application programming interface
APR = Annual percentage rate
APY = Annual percentage yield
ATO = Account takeover
BLS = U.S. Bureau of Labor Statistics
BNPL = Buy Now Pay Later
EBT = Electronic benefit transfer
FDIC = Federal Deposit Insurance Corporation
FFIEC = Federal Financial Institutions Examination Council
FRFA = Final regulatory flexibility analysis
FTC = Federal Trade Commission
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 (U.S. Department of
the Treasury)
OFAC = Office of Foreign Assets Control (U.S. Department of the
Treasury)
OMB = Office of Management and Budget (Executive Office of the
President)
RFI = Request for Information
SBA = U.S. Small Business Administration
SBA Advocacy = U.S. Small Business Administration Office of Advocacy
SNAP = Supplemental Nutrition Assistance Program
SSN = Social Security number
TAN = Tokenized account number
URL = Uniform resource locator
USDA = U.S. Department of Agriculture
I. Overview
A. Summary of the Final Rule
When Congress established the Consumer Financial Protection Bureau
in the Consumer Financial Protection Act (CFPA), it sought to ensure
that markets for consumer financial products and services are fair,
transparent, and competitive.\1\ CFPA section 1033 lets consumers take
action by giving them a right to access their account information and
authorize certain third parties acting on their behalf to access that
information. This right enables consumers to evaluate their account
relationships and switch providers that are not benefiting them, and
allows consumers to authorize third parties to access data on their
behalf to provide valuable products and services they request.
Increased competition can lead to innovation, attractive rates, quality
service, and other benefits.
---------------------------------------------------------------------------
\1\ 12 U.S.C. 5511(a). 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).
---------------------------------------------------------------------------
Specifically, 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. In addition, Congress mandated in section
1033(d) that the CFPB prescribe standards to promote the development
and use of standardized formats for data made available under section
1033.
This final rule carries out these objectives by empowering
consumers to access account data controlled by providers of certain
consumer financial products or services in a safe, secure, reliable,
and competitive manner. When implemented, consumers will be able to
access their own data and authorize third parties to access their data
safely and with confidence that the third party is acting on their
behalf, which means not collecting, using, or retaining consumer data
for the benefit of entities other than the consumer. Consumers and
authorized third parties will be able access data securely, ensuring
that a baseline set of security standards apply across the market. They
also will be able to access data reliably, promoting the accurate and
consistent transmission of usable data. Consumer-authorized data access
under the final rule also will occur in a manner that promotes
competition through standardization and other measures to avoid
entrenching incumbent data providers, intermediaries, and third parties
that
[[Page 90839]]
have commercial interests not always aligned with the interests of
consumers and competition generally.
Coverage
In general, the final rule requires a ``data provider'' to make
``covered data'' about ``covered financial products and services''
available in electronic form to consumers and to certain ``authorized
third parties.'' For this purpose, an authorized third party is a third
party that has complied with the authorization procedures set forth in
subpart D of part 1033.
A ``data provider'' includes depository institutions (including
credit unions) and nondepository institutions that issue credit cards,
hold transaction accounts, issue devices to access an account, or
provide other types of payment facilitation products or services. The
final rule does not apply to certain small depository institutions as
defined in the rule. In general, ``covered data'' includes information
about transactions, costs, charges, and usage. This coverage is
intended to prioritize some of the most beneficial use cases for
consumers and leverage data providers' existing capabilities.
Clarifying the scope of the data access right will also promote
consistency in the data made available to consumers, reduce costs of
arranging for access to such data, and focus the development of
technical standards around such data.
Access Requirements
The final rule generally requires a data provider to make covered
data available to consumers and authorized third parties upon request.
The rule includes a number of functional requirements intended to
ensure data providers make covered data available reliably, securely,
and in a way that promotes competition. A data provider must make
covered data available to authorized third parties in a standardized
and machine-readable format and in a commercially reasonable manner,
including by meeting a minimum response rate with respect to requests
for covered data. A data provider must not unreasonably restrict the
frequency with which it receives or responds to requests for covered
data from an authorized third party. In addition, the data provider
cannot comply with the requirement to make data available to authorized
third parties by allowing the third party to engage in ``screen
scraping,'' an access method that uses consumer credentials to log in
to consumer accounts to retrieve data.\2\ The final rule also prohibits
fees or charges related to consumer and third party data access. The
final rule also requires a data provider to publicly disclose certain
information about itself to facilitate access to covered data and to
promote accountability.
---------------------------------------------------------------------------
\2\ Unless otherwise stated, the term ``screen scraping'' in
this final rule refers to credential-based screen scraping, which is
prevalent in the market today.
---------------------------------------------------------------------------
The rule uses the term ``developer interface'' to refer to the
functionality through which a data provider receives requests for
covered data and makes the data available in electronic form usable by
authorized third parties. Similarly, the rule uses the term ``consumer
interface'' as a label for the functionality with respect to consumer
access. In neither case does the rule require the use of any particular
technology.
Authorized Third Parties
To become an authorized third party, a third party must seek access
to covered data on behalf of a consumer to provide a product or service
that the consumer requested and: (1) provide the consumer with an
authorization disclosure containing certain key terms of the data
access; (2) provide a statement to the consumer in the authorization
disclosure certifying that the third party agrees to certain
obligations set forth in the final rule; and (3) obtain the consumer's
express informed consent to access covered data on behalf of the
consumer by obtaining an authorization disclosure that is signed by the
consumer electronically or in writing.
Under the final rule, a third party must certify to limit its
collection, use, and retention of covered data to what is reasonably
necessary to provide the consumer's requested product or service. For
purposes of this certification, targeted advertising, cross-selling,
and the sale of covered data are not part of, or reasonably necessary
to provide, any other product or service. The final rule includes
examples of uses that are considered reasonably necessary to provide
consumer requested products or services.
In addition to this general limit on collection, use, and retention
of covered data, the third party also must certify to limit the
duration of collection of covered data pursuant to a given
authorization to a maximum period of one year. To continue collection,
the third party must obtain a new authorization from the consumer no
later than the anniversary of the most recent authorization. If a
consumer does not provide a new authorization or if a consumer revokes
authorization, the third party will cease its collection of covered
data and cease its use and retention of covered data that was
previously collected unless use or retention of that covered data
remains reasonably necessary to provide the consumer's requested
product or service.
Under the final rule, a third party must also certify to:
Have written policies and procedures that are reasonably
designed to ensure that covered data are accurately received from a
data provider and, if applicable, accurately provided to other third
parties.
Apply an information security program to its systems for
the collection, use, and retention of covered data. Generally, the
program must satisfy the applicable rules issued pursuant to the
Safeguards Framework of the Gramm-Leach-Bliley Act (GLBA), 15 U.S.C.
6801 et seq. (GLBA Safeguards Framework).\3\
---------------------------------------------------------------------------
\3\ The GLBA Safeguards Framework in this final rule refers the
rules issued by the FTC and the guidelines issued by the prudential
regulators that generally implement the GLBA's data security
safeguards framework, pursuant to sections 501 (15 U.S.C. 6801) and
505 (15 U.S.C. 6805) of the GLBA. See Safeguards Rule, 16 CFR part
314; Interagency Guidelines Establishing Standards for Safety and
Soundness, 12 CFR part 30, app. A (OCC); 12 CFR part 208, app. D-1
(Bd. of Governors of the Fed. Rsrv. Sys.); 12 CFR part 364, app. A
(FDIC); and 12 CFR 748, app. A (NCUA). The GLBA Safeguards Framework
sets forth standards for administrative, technical, and physical
safeguards with respect to financial institutions' customer
information. These standards generally apply to the security and
confidentiality of customer records and information, anticipated
threats or hazards to the security or integrity of such records, and
unauthorized access to or use of such records or information that
could result in substantial harm or inconvenience to any customer.
---------------------------------------------------------------------------
Provide the consumer with a copy of the authorization
disclosure that the consumer has signed electronically or in writing
and contact information that enables a consumer to receive answers to
questions about the third party's access to the consumer's covered
data.
Have reasonable written policies and procedures designed
to ensure that the third party provides to the consumer, upon request,
certain information about the third party's access to the consumer's
covered data.
Provide the consumer with a method to revoke the third
party's authorization. Additionally, the third party will certify that
it will notify the data provider, any data aggregator, and other third
parties to which it has provided the consumer's covered data when the
third party receives a consumer's revocation request.
[[Page 90840]]
Require other third parties, by contract, to comply with
specified third party obligations before providing covered data to
them.
Data Aggregators
The final rule permits data aggregators to perform the
authorization procedures described in the final rule on behalf of the
third party seeking the consumer's authorization. The third party
seeking the consumer's authorization remains responsible for compliance
with the authorization procedures even if it uses a data aggregator to
perform the authorization procedures. If the third party will use a
data aggregator to assist with accessing covered data, the data
aggregator must certify to the consumer that it will satisfy the third
party obligations discussed above (except the obligation to ensure
consumers are informed, including the obligation to provide a copy of
the authorization disclosure and contact information, and the
obligation to provide a revocation mechanism), and this certification
must be provided to the consumer. The third party may include this
certification in the authorization disclosure or the data aggregator
may provide it separately. Additionally, the third party's
authorization disclosure must include the data aggregator's name and a
description of the services that the data aggregator will provide in
connection with accessing the consumer's covered data.
Policies and Procedures, and Recordkeeping for Data Providers and Third
Parties
The final rule requires a data provider to have written policies
and procedures that are reasonably designed to achieve certain
objectives, including those related to what covered data are generally
made available, how a data provider responds to requests for developer
interface access and requests for information, the accuracy of data
transmitted through an interface, and record retention.
A third party that is a covered person or service provider as
defined in the CFPA (12 U.S.C. 5481(6) and (26)), must establish and
maintain written policies and procedures that are reasonably designed
to ensure retention of records that are evidence of compliance for a
reasonable period of time, not less than three years after a third
party obtains the consumer's most recent authorization.
Financial Products or Services (Part 1001)
The final rule defines financial products or services under the
CFPA to ensure that it includes providing financial data processing.
This provides 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.
B. Market Background
Digitization in consumer finance has the potential to facilitate
more seamless consumer switching and greater competition. Consumers'
ability to easily switch providers of consumer financial products and
services creates strong competitive incentives that result in superior
customer service and more favorable terms for consumers. Consumer-
authorized sharing of personal financial data can produce positive
market outcomes, but without appropriate safeguards it can also lead to
misuse and abuse of consumer data.
Development of Electronic Data Access and Open Banking
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.\5\ Building on these developments, open banking \6\
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.\7\ Third parties, such as
personal financial advisors, often outsourced establishing and
maintaining connections with data providers to data aggregators. These
intermediaries largely relied on ``screen scraping.'' Widespread screen
scraping allowed open banking to grow quickly in the U.S. 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.\8\
---------------------------------------------------------------------------
\4\ Fed. Deposit Ins. Corp., National Survey of Unbanked and
Underbanked Households (2021), https://www.fdic.gov/analysis/household-survey/2021report.pdf.
\5\ For a more detailed discussion of the history of digital
banking, see the NPRM, 88 FR 74796, 74797-98 (Oct. 31, 2023).
\6\ This final rule 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 U.S.
\7\ Maria Trombly, Citibank's Aggregation Portal a Big Draw,
Computerworld (Sept. 18, 2000), https://www.computerworld.com/article/2597099/citibank-s-aggregation-portal-a-big-draw.html; Off.
of the Comptroller of the Currency, Bank-Provided Account
Aggregation Services: Guidance to Banks (2001), https://www.occ.treas.gov/news-issuances/bulletins/2001/bulletin-2001-12.html; CNET, Net earnings: E-commerce in 1997 (Dec. 24, 1997),
https://www.cnet.com/tech/tech-industry/net-earnings-e-commerce-in-1997/; Microsoft, OFX Consortium Expands with Bank of America,
Citigroup, Corillian, E*TRADE and TD Waterhouse (Oct. 2, 2001),
https://news.microsoft.com/2001/10/02/ofx-consortium-expands-with-bank-of-america-citigroup-corillian-etrade-and-td-waterhouse/.
\8\ For a more detailed discussion of the history of screen
scraping, see NPRM, 88 FR 74796, 74797-99 (Oct. 31, 2023).
---------------------------------------------------------------------------
In recent years, the open banking system has continued to grow as
consumer reliance on products and services powered by consumer-
authorized data access has expanded. However, this growth has been
uneven, with various disputes among system participants continuing to
arise. Despite these challenges, financial institutions are dedicating
more resources to developing open banking infrastructure, indicating
significant consumer demand for open banking use cases, as well as
interest among incumbents in maintaining some control over the system.
State of the Open Banking System
The CFPB estimates that, as of 2022, at least 100 million consumers
had 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 is estimated to have
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.\9\
These figures are likely to grow as consumer engagement continues and
use cases expand.
---------------------------------------------------------------------------
\9\ See Press Release, Open Banking Ltd., Open banking marks
major milestone of 10 million users (July 23, 2024), https://www.openbanking.org.uk/news/open-banking-marks-major-milestone-of-10-million-users/; and Consumer Data Right, Performance, Overview,
API Invocations, https://www.cdr.gov.au/performance (scroll down to
``Overview'' dashboard; then, near the top right of dashboard,
select ``Date Slider''; then update date range from ``1/1/2022'' to
``12/31/2022''; then view updated ``API Invocations'' data on the
bottom left of dashboard) (last visited Oct. 16, 2024).
---------------------------------------------------------------------------
The open banking system also engages a large number of entities,
including thousands of depository institutions and third parties. A
growing number of entities now serve as both data
[[Page 90841]]
providers and third parties. For example, many depositories now act as
third parties by offering personal financial management tools, while
some entities offering so-called neobank accounts and digital wallets
act as data providers. Most third party access is effectuated via a
small number of aggregators, although some third parties elect to
access at least some data directly.\10\
---------------------------------------------------------------------------
\10\ For a more detailed discussion of the makeup of the market,
see NPRM, 88 FR 74796, 74798 (Oct. 31, 2023).
---------------------------------------------------------------------------
Third party data access is generally enabled via screen scraping or
developer interfaces.\11\ Based on feedback received through public
comments and stakeholder outreach, there is nearly universal consensus
that safer forms of data access should supplant screen scraping.\12\
However, to this point, such a transition has required data providers
to choose to develop and maintain safer forms of data access, and
required agreement between such providers and third parties on the
resulting terms of data access, both of which have proved to be
challenging propositions.\13\ In spite of these challenges, open
banking use cases continue to emerge and develop. Major use cases
include personal financial management tools, 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.
---------------------------------------------------------------------------
\11\ For a more detailed discussion of these methods, see id.
\12\ See, e.g., Consumer Fin. Prot. Bureau, Bureau Symposium:
Consumer Access to Financial Records Report, at 3-4 (July 2020),
https://files.consumerfinance.gov/f/documents/cfpb_bureau-symposium-consumer-access-financial-records_report.pdf.
\13\ For a more detailed discussion of this transition, see
NPRM, 88 FR 74796, 74798-99 (Oct. 31, 2023).
---------------------------------------------------------------------------
Challenges in the Open Banking System
Though the open banking system in the U.S. has grown considerably,
significant challenges remain to achieving safe, secure, reliable, and
competitive open banking. 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 transition to safer forms of data access and the
development of market-wide standards. This leads to inconsistent data
access for consumers and market inefficiencies. These dynamics also
impel third parties to rely on intermediaries, which have interests
that may not always advance open banking since they stand to benefit
from existing private network effects.
Market participants' interests may diverge due to interrelated
competitive, legal, and regulatory factors. For example, data providers
may limit the data they share or refrain from sharing altogether to
protect their market position, while third parties may collect more
data than they reasonably need to provide the products or services
sought by the consumer.\14\ Such unnecessary collection, use, and
retention of consumer data by third parties does not benefit consumers
and needlessly encroaches on consumers' privacy interests.
---------------------------------------------------------------------------
\14\ For a more detailed discussion of divergent interests
present in the market and the risks created by particular practices,
including screen scraping, see id. at 74798-99.
---------------------------------------------------------------------------
Impacts of These Challenges on the Open Banking System
The challenges described above have impeded progress on safer forms
of data access and hampered multilateral efforts by industry to
establish open banking standards.\15\ This stasis has forced the open
banking system to depend heavily on a handful of data aggregators that
accrue economic benefits from the system's inability to scale safer
forms of data access 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 safer forms of data
access 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.
---------------------------------------------------------------------------
\15\ For a more detailed discussion of how such progress has
been hampered, see id. at 74799.
---------------------------------------------------------------------------
When the challenges impeding progress described above are resolved,
consumers should be able to safely, securely, and reliably exercise
their data access rights in a competitive open banking system not
dominated by the interests of any one segment of the market.
II. The Proposal and Other Procedural Background
A. Outreach
In addition to the industry and community outreach described in the
proposal,\16\ in 2016, the CFPB published in the Federal Register an
RFI Regarding Consumer Access to Financial Information on topics
including consumer-authorized data access \17\ and in 2020 held a
symposium with stakeholders \18\ and published an ANPR in the Federal
Register.\19\ Pursuant to the Small Business Regulatory Enforcement
Fairness Act of 1996 (SBREFA),\20\ the CFPB in 2022 issued its Outline
of Proposals and Alternatives under Consideration for the Required
Rulemaking on Personal Financial Data Rights (Outline or SBREFA
Outline) \21\ and in 2023 convened a SBREFA Panel,\22\ which issued a
report (Panel Report or SBREFA Panel Report).\23\ In December 2023,
CFPB staff met with the Consumer Advisory Board, the Community Bank
Advisory Council, and the Credit Union Advisory Council to receive
feedback on the proposed rule.\24\
---------------------------------------------------------------------------
\16\ See 88 FR 74796, 74799 (Oct. 31, 2023). This outreach
included the issuance of two sets of market monitoring orders under
CFPA section 1022(c)(4) (described in the proposed rule as the
``Provider Collection'' and ``Aggregator Collection''), and
engagement with CFPB advisory boards and committees.
\17\ See 81 FR 83806 (Nov. 22, 2016). In 2017, the CFPB
published a summary of comments received in response to the RFI and
other stakeholder meetings. See Consumer Fin. Prot. Bureau,
Consumer-authorized financial data sharing and aggregation:
Stakeholder insights that inform the Consumer Protection Principles
(Oct. 18, 2017), https://www.consumerfinance.gov/data-research/research-reports/consumer-protection-principles-consumer-authorized-financial-data-sharing-and-aggregation/.
\18\ See Consumer Fin. Prot. Bureau, Bureau Symposium: Consumer
Access to Financial Records: A summary of the proceedings (July
2020), https://files.consumerfinance.gov/f/documents/cfpb_bureau-symposium-consumer-access-financial-records_report.pdf.
\19\ See 85 FR 71003 (Nov. 6, 2020).
\20\ Public Law 104-121, 110 Stat. 857 (1996).
\21\ 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), https://files.consumerfinance.gov/f/documents/cfpb_data-rights-rulemaking-1033-SBREFA_outline_2022-10.pdf.
\22\ The Panel consisted of a representative from the CFPB, the
Chief Counsel for Advocacy of the Small Business Administration, and
a representative from the Office of Information and Regulatory
Affairs in OMB.
\23\ 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), https://files.consumerfinance.gov/f/documents/cfpb_1033-data-rights-rule-sbrefa-panel-report_2023-03.pdf. As required under the Regulatory Flexibility Act, the CFPB
considered the Panel's findings in its IRFA, as set out in the NPRM.
See 88 FR 74796, 74862 (Oct. 31, 2023). The CFPB considered the
feedback it received from small entity representatives and the
findings and recommendations of the Panel. The CFPB invited other
stakeholders to submit feedback on the SBREFA Outline, which was not
considered by the Panel and is not reflected in the Panel Report.
See https://www.regulations.gov/document/CFPB-2023-0011-0001/comment.
\24\ This feedback was submitted to the rulemaking docket. See
https://www.regulations.gov/comment/CFPB-2023-0052-11086 (Community
Bank Advisory Council); https://www.regulations.gov/comment/CFPB-2023-0052-11087 (Credit Union Advisory Council); https://www.regulations.gov/comment/CFPB-2023-0052-11088 (Consumer Advisory
Board).
---------------------------------------------------------------------------
[[Page 90842]]
Before and after issuing the proposal, CFPB staff met on numerous
occasions to obtain feedback from staff from the Board of Governors of
the Federal Reserve System, OCC, FDIC, NCUA, and FTC, including on the
subjects in CFPA sections 1022(b)(2)(B) and 1033(e). CFPB staff has
also met with staff from other Federal agencies, including staff from
the USDA, the U.S. Department of the Treasury, the U.S. Department of
Justice, the U.S. Department of Commerce, the Federal Housing Finance
Agency, as well as staff from State agencies.
B. Summary of the Proposed Rule
On October 19, 2023, the CFPB released the notice of proposed
rulemaking for the Required Rulemaking on Personal Financial Data
Rights. The proposal was published in the Federal Register on October
31, 2023, and the public comment period closed on December 29, 2023.
See 88 FR 74796 (Oct. 31, 2023).
Part 1033
The proposal would have implemented CFPA section 1033 by ensuring
consumers and third parties who are authorized to access covered data
on behalf of consumers can access covered data in an electronic form
from data providers. In general, the proposal sought to foster a data
access framework that is safe, by ensuring third parties are acting on
behalf of consumers when accessing their data, including with respect
to consumers' privacy interests; secure, by applying a consistent set
of security standards across the market; reliable, by promoting the
accurate and consistent transmission of data that are usable by
consumers and authorized third parties; and 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 sought 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 sought to promote the use and development of standardized formats.
The proposal identified six general objectives to be achieved by its
various provisions.
First, the proposal would have clarified the scope of data access
rights under CFPA section 1033 by defining key terms, establishing
which covered persons would be required to make data available to
consumers, and defining which data would need to be made available to
consumers. Second, the proposal would have established basic standards
for data access by requiring data providers to maintain a consumer
interface for consumers and a developer interface for third parties to
access consumer-authorized data under CFPA section 1033. Data providers
would have been required to make available covered data to authorized
third parties in a standardized format, in a commercially reasonable
manner, without unreasonable access caps, and pursuant to certain
security specifications. In addition, data providers would have had to
follow certain procedures to disclose information about themselves and
their developer interfaces, and to establish and maintain certain
written policies and procedures to ensure compliance with the
provisions of the rule and promote the objectives of CFPA section 1033.
Third, the proposal would have prevented data providers from allowing a
third party to access the system using consumer interface credentials.
This and the proposals described above were intended to transition the
market from screen scraping towards an access method that complies with
CFPA section 1033. Fourth, the proposal would have defined the
mechanics of data access by proposing certain requirements and
clarifications with respect to when a data provider must make available
covered data upon request to consumers and authorized third parties.
Fifth, the proposal sought to ensure third parties are acting on behalf
of consumers through requirements that a third party 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 sought 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 would have included 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. Sixth, the
proposal sought to promote fair, open, and inclusive industry standards
by proposing that conformance with ``qualified industry standards''
issued by standard-setting bodies recognized by the CFPB would provide
some indicia of compliance with various rule provisions.
Part 1001
Separately, the proposed rule would have defined financial products
or services under the CFPA in 12 CFR part 1001 to ensure that the
definition includes providing financial data processing. The proposal
explained that this 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.
Comments
The CFPB received approximately 11,120 public comments on the
proposal during the comment period.\25\ Approximately 290 of these
comments were unique, detailed comment letters. These commenters
included data providers and third parties, including banks of different
sizes, credit unions, a variety of nondepository entities, and data
aggregators; \26\ trade associations representing a diverse array of
interests; standard-setting bodies; \27\ consumer advocates; \28\
researchers and a variety of research institutes; members of Congress;
government agencies; law firms; and individual commenters not
affiliated with or representing any organization.
---------------------------------------------------------------------------
\25\ See https://www.regulations.gov/docket/CFPB-2023-0052/comments.
\26\ Depending on the context and its activities, a particular
entity might be a data provider, a third party, a data aggregator
acting on behalf of a third party, or some combination thereof. The
description of commenters in this final rule attempts to
characterize the commenter based on the expressed or inferred
capacity in which they provided feedback.
\27\ As used in this final rule, this term refers to nonprofit
entities that described themselves principally as an industry
standard-setting body. The CFPB recognizes, however, that a variety
of other commenters might be involved in standard-setting
activities.
\28\ As used in this final rule, this term refers broadly to all
types of consumer advocates, including privacy advocates and
community groups.
---------------------------------------------------------------------------
In addition, the CFPB considered comments received after the
comment period closed via approximately 60 ex parte submissions and
meetings.\29\ These materials, including all ex parte submissions and
summaries of ex parte meetings, will be available on the public docket
for this rulemaking.\30\
---------------------------------------------------------------------------
\29\ See Consumer Fin. Prot. Bureau, Policy on Ex Parte
Presentations in Rulemaking Proceedings, 82 FR 18687 (Apr. 21,
2017).
\30\ See https://www.regulations.gov/docket/CFPB-2023-0052.
---------------------------------------------------------------------------
[[Page 90843]]
The remaining comments included some duplicate submissions (i.e.,
letters with the same content from the same commenter submitted through
multiple channels, or letters with the same content submitted by
multiple people on behalf of the same commenting organization) as well
as comments that appeared to be part of several comment submission
campaigns. Such comment campaigns typically advocated for or against
particular provisions in the proposal and urged additional changes.
These comments were considered by the CFPB along with all other
comments received, including any additional remarks included in
otherwise identical comment letters.
The CFPB received comments on nearly all aspects of the proposed
rule, and on its analyses of the proposed rule's impacts. Relevant
information received via comment letters, as well as ex parte
submissions, is discussed below in subsequent parts of this document,
as applicable. The CFPB considered all the comments it received
regarding the proposal, made certain modifications, and is adopting the
final rule as described in part IV below.
C. 2024 Industry Standard-Setting Final Rule
In June 2024, the CFPB finalized the proposal in part, establishing
attributes a standard-setting body must possess to receive CFPB
recognition for purposes of issuing standards that provide some indicia
of compliance with certain substantive provisions of part 1033, as well
as establishing the application process for CFPB recognition. See 89 FR
49084 (June 11, 2024) (Industry Standard-Setting Final Rule).
III. Legal Authority
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 ensures data providers
readily make available to consumers and third parties acting on behalf
of consumers (including authorized third parties offering competing
products and services), upon request, covered data in a usable
electronic form. 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 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,
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.\31\ 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 after the applicable compliance
date. 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.''
---------------------------------------------------------------------------
\31\ See 12 U.S.C. 5481(14) (defining ``Federal consumer
financial law'' to include the provisions of the CFPA).
---------------------------------------------------------------------------
C. 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
exercising this authority in finalizing Sec. 1001.2(b).
IV. Discussion of the Final Rule
12 CFR Part 1033
General Comments Received on the Proposal
High-level and general comments received on the CFPB's proposed
rule to implement CFPA section 1033 are discussed here, followed by a
discussion of comments specifically addressing the rulemaking process,
liability among commercial entities, and overlaps with other consumer
financial laws and CFPB rulemaking activity. Comments received on
specific aspects of the CFPB's proposed rule, as well as regarding the
CFPB's legal authority to adopt specific aspects of the rule, and the
anticipated effects of particular provisions, are discussed in turn in
the sections that follow in this part IV. Comments regarding the CFPB's
analysis of impacts are discussed in parts VI through VIII.
1. High-Level and General Comments on the Proposal
General Support
Most commenters, including data providers, third parties, data
aggregators, trade associations, consumer advocates, and others,
supported the overall goals of the rulemaking articulated in the
proposal. Many commenters supported implementing the data access rights
in CFPA section 1033 to include direct
[[Page 90844]]
consumer and third party access that would allow consumers and
authorized third parties to access data more reliably and securely
compared to current market practices. A research institute commenter
stated that the proposal would assure a robust regime of third party
access with respect to its coverage, while building in flexibility to
allow the regime to evolve along with changes in market standards and
technology.
Many third party commenters, consumer advocates, and others stated
consumer-authorized access would help consumers, including those
underserved by their existing account providers, manage their financial
lives and access new and competing products and services. A community
bank commenter indicated the proposal would help ensure community banks
remain vital in the areas they serve.
Many commenters, including third parties, data providers, consumer
advocates, and others also stated that the rule would generally
increase competition overall by reducing barriers to entry and other
impediments for market participants to compete with incumbent
depository and nondepository institutions. For example, a credit union
commenter stated that the standardization of third party data access
would allow smaller institutions to rely on the same technology as
larger institutions, decreasing incumbents' market power. Other
commenters believed that the proposal's approach to standard-setting
would reduce the influence of incumbents and increase consumers'
bargaining power and access to services offered by different providers.
Some data provider commenters stated that the proposal would support
competition by limiting third party secondary use of consumer-
authorized data and ensuring third parties are subject to a basic
standard for data security.
Some commenters specifically indicated that the rule would have
competitive benefits in certain markets. For example, a trade
association for certain third parties stated that open banking can spur
competition in the payments sector, lowering transaction costs and
mitigating the durable market power of certain incumbents. The
commenter noted that the proposal's prohibition on fees for third party
access would allow cost-sensitive merchants to accept lower-cost
payments.
Commenters also emphasized the benefits of informed consent and
consumer control when sharing data with third parties and the need for
consumer protection in consumer-authorized access. Many data providers,
third parties, consumer advocates, and others also supported the rule's
efforts to protect consumers by enabling them to control their data
effectively. For example, a consumer advocate expressed general support
for the proposal, characterizing it as a strong, protective rule that
would ensure that consumers can share account data free of misuse or
exploitation. This commenter also stated the consumer protections in
the rule should serve as a model for how to safeguard consumer control
and privacy when a consumer grants permission to a business to use
their data.
General Opposition
While many commenters supported the proposal overall, some data
providers, third parties, and others were critical of some or all
aspects of the proposal. A number of data provider commenters,
particularly credit unions and community banks, expressed opposition to
the proposal as a whole, and questioned whether a rule was necessary or
appropriate to achieve the CFPB's stated goals, including with respect
to competition, and questioned the CFPB's legal authority to issue
rules for open banking.
In addition, a wide variety of commenters, including data providers
and third parties, raised what they described as significant concerns
about the costs of the proposal, often with respect to specific
provisions. In particular, data providers were most concerned with
potential compliance costs related to the Fair Credit Reporting Act
(FCRA), 15 U.S.C. 1681 et seq., the costs of providing access to third
parties in compliance with the rule as proposed (including the
prohibition on charging fees for access), the costs associated with
managing third party risk, and how liability would be allocated for
third party breaches or fraud. A number of entities--mainly though not
exclusively third parties that use consumer-authorized data--asserted
that the proposed third party limitation on collection, use, and
retention of covered data would foundationally undermine the rule and
restrict consumers' ability to share their data. A large number of
smaller financial institutions and related trade associations expressed
concern that the proposal would disadvantage small entities.
A variety of commenters suggested that the proposal would undermine
competition in various ways. Some commenters, including research
institutes, third parties, and data providers asserted that the
proposal's coverage was too narrow to support competition. For example,
a data aggregator stated that the proposal's limited coverage of
products and data types would reduce third party innovation, and a
research institute stated that the limited coverage of data providers
would give them an incentive to block data access outside of the rule's
coverage, further limiting third party access to data. A research
institute and a data provider commenter stated that the proposal would
undermine competition by limiting the role of industry standard-setting
bodies that are not recognized by the CFPB.
Some credit union and community bank commenters stated that the
rule as a whole would unfairly force data providers to maintain data
access systems and bear other costs, effectively subsidizing
competition from third parties, particularly as a result of the
proposed fee prohibition for third party data access. Several of these
commenters noted that this result would benefit nondepositories that
are excluded from the data provider definition and would come at the
expense of depository institutions, which would disproportionately
disadvantage credit unions and community banks. Data providers
expressed concern that they would unfairly bear the burden of managing
liability risks presented by nondepository third parties that are not
subject to the same regulatory oversight. Several data provider
commenters expressed concern that third parties would use consumer data
to harm data providers, such as by reverse-engineering sensitive
commercial information. A data aggregator commenter stated that the
proposal would consolidate the market of data aggregators by forcing
data providers to grant access to third parties, ultimately stifling
innovation.
Credit union and community bank commenters also expressed concern
that the proposal would disadvantage them relative to larger and better
resourced data providers. These commenters stated that the proposal
would impose disproportionate and unsustainable costs on smaller data
providers and would force some to exit the market or otherwise
consolidate the banking industry, reducing consumer access to products
and services. A number of commenters stated that smaller depository
institutions that rely on core service providers would be less able to
manage the costs of a prohibition on fees for third party access. One
data provider commenter stated that the proposed rule would force less-
resourced data providers to adhere to standards established by the
largest data providers, which would reduce their profitability. Another
data provider
[[Page 90845]]
commenter stated that forcing some data providers to make data
available to third parties while exempting community banks would put
community banks at a competitive disadvantage relative to large data
providers.
As discussed in part IV.D.4, a variety of third party commenters
expressed concern that the proposed limitation on collection, use, and
retention of covered data would restrict innovation by third parties or
limit the ability of new entrants and providers of new products and
services to provide innovative products. For example, a trade
association representing nondepository institutions argued that the
final rule should allow broader use of covered data for advertising
purposes to support competition, while numerous commenters, including
research institutes and others, expressed concern about the limitation
on use of de-identified data, including for research purposes. Other
commenters argued the proposed limitation on collection, use, and
retention of covered data would not only disadvantage third parties
relative to other market participants, but also reduce the
competitiveness of the U.S. overall. Some commenters also asserted that
the proposed third party obligations, including the limit on
collection, use, and retention of covered data, would put third parties
at a significant competitive disadvantage to data providers that are
unrestricted by the limitations. For example, some commenters stated
that the proposed limitation on a third party's duration of
authorization would disadvantage third parties engaged in payments
relative to incumbents that do not rely on consumer-authorized data.
Some third party commenters also stated that the proposal's allowance
of tokenized account numbers would result in anticompetitive conduct by
data providers.
Several commenters argued that the market for consumer-authorized
data is already competitive and that a rulemaking to increase
competition among data providers, intermediaries, and third parties,
would be unnecessary or would yield few benefits. As evidence of the
level of competition in the U.S., commenters noted that third parties
access (or attempt to access) consumer-authorized data more frequently
in the U.S. than in other countries; noted that the market is already
moving toward the use of APIs and away from screen scraping; and
asserted that the market for data provider products and services
(including for credit card and deposit accounts) is robust and provides
high levels of customer service. Some commenters representing community
banks asserted that consumers are not demanding third party data
access, but that community banks would provide it if consumers did
demand it.
Some commenters, particularly community banks and credit unions
stated that the proposal would not meet its objectives related to
privacy and security for various reasons. Some commenters suggested
this would be the case because of a lack of regular examinations of
third parties. Others took issue more generally with the obligation to
make data available to third parties, which they said would open the
door to fraud and security breaches of personally identifiable data.
Many data providers expressed concern that they would be obligated to
ensure the data security of third parties.
Some data provider and third party commenters also raised concerns
about the CFPB's legal authority for parts of the proposal. Some
commenters also suggested that the CFPB consider consumer data sharing
rules in other jurisdictions in drafting the final rule, but without
clear consensus on what did or did not work in other jurisdictions.
Response to Comments
The CFPB agrees with the general comments about implementing CFPA
section 1033 to ensure data providers not only provide data access to
consumers directly but also provide access for consumers' authorized
third party representatives. As discussed in part III and part IV.C.2,
this aspect of the rule is consistent with the plain language and
objectives of section 1033 and the CFPA more broadly. In addition, the
CFPB agrees that this aspect of the rule will increase opportunities
for both depository and nondepository institutions to provide better
products or services to consumers and enable consumers to manage their
financial lives using data under the control or possession of data
providers.
The CFPB also agrees with commenters that supported the general
approach to third party access. As discussed in part IV.D, the third
party access provisions of the final rule are designed to ensure,
consistent with carrying out the objectives of CFPA section 1033, that
consumers provide informed consent to third parties that access covered
data pursuant to the final rule's framework, that consumers retain
control over third parties' access, and that third parties act on
behalf of consumers when collecting, using, and retaining covered data.
With respect to comments opposing the proposal, including due to
concerns about the impact on competition, the final rule carries out
Congress' objectives in CFPA section 1033(a) and the mandate at CFPA
section 1033(d) to prescribe standards to promote the development and
use of standardized formats. As discussed further in part IV.D.1,
Congress intended for consumers to be able to authorize third parties
to access data under the statute on their behalf. Congress also
directed the CFPB to prescribe standards to promote the development and
use of standardized formats of information. The final rule carries out
those objectives. For more discussion on the costs and benefits of the
final rule, including impacts on competition, see parts VI and VII
below.
The final rule will help ensure that markets for consumer financial
products and services are competitive overall. Consumers will have even
greater ability to take advantage of the many products or services
already available, and data providers will have stronger incentives to
enhance their products and services to retain their customers. The CFPB
disagrees with arguments that consumers are not interested in third
party data access, and notes that many consumers of institutions both
large and small share data with third parties. But even where data
providers already make data available voluntarily, the CFPB has
determined the rulemaking is needed to address the challenges that have
arisen in open banking, as discussed in the proposal. See 88 FR 74796,
74798-99 (Oct. 31, 2023).
As discussed further in part IV.A.3, the CFPB has determined it is
appropriate to implement the product coverage of CFPA section 1033 in a
staged manner. With respect to concerns about data provider incentives
to block screen scraping, those incentives exist independent of the
final rule. As safer forms of data access become functional, the CFPB
expects that parties will move away from screen scraping. However, as
discussed further in part IV.C.3, data providers must exercise caution
when blocking screen scraping outside the rule's coverage.
With respect to the impact on the market for data aggregation, in
the current market, and in the absence of implementing CFPA section
1033, open banking activity has already consolidated to data
aggregators for the reasons discussed in the proposal. See 88 FR 74796,
74798-99 (Oct. 31, 2023). The impact of the rule on the value of
intermediation arises from carrying out congressional intent to make
consumer data more portable, including as a result of the
interoperability objective inherent in CFPA section 1033(d)'s mandate
to
[[Page 90846]]
promote standardized formats. Additionally, whether an authorized third
party relies on an aggregator is a business decision of the authorized
third party. The final rule will reduce costs for authorized third
parties generally, including the cost of using an aggregator, and
should make it easier to access data directly from data providers over
time, due to various aspects of the final rule including the
requirements related to standardized formats, the prohibition on fees,
and the rule's recognition of industry standard-setting as an important
aspect of an effective and efficient open banking system.
With respect to concerns about competitive disadvantages for
smaller data providers, the CFPB is not finalizing the rule with
respect to depository institutions under the coverage threshold at
Sec. 1033.111(d) and is providing smaller data providers that are
covered additional time to comply, as discussed in part IV.A.5. The
rule also presents opportunities for small data providers to better
compete by offering products and services to a wider range of
consumers. One commenter expressed concern that excluding smaller data
providers would disadvantage small data providers relative to large
data providers that continued to have the obligation, but for which
they would not offer developer interfaces. The CFPB disagrees with this
premise and notes that many large data providers are already offering
developer interfaces and that small data providers can participate in
open banking voluntarily.
Some commenters expressed concern that the rule would force small
data providers to rely on standards developed by large data providers
with more resources. During the SBREFA process, the CFPB received
feedback that standardization can reduce costs for small entities,
including data providers and third parties.\32\ Consistent with the
mandate in CFPA section 1033(d), the final rule includes various
provisions to promote the development and use of standardized data
formats. Further, consensus standards (discussed in part IV.A.6 below)
that can serve as indicia of compliance with various rule provisions,
must be issued by a recognized standard setter that demonstrates
balance, as discussed further in the Industry Standard-Setting Final
Rule.
---------------------------------------------------------------------------
\32\ See, e.g., SBREFA Panel Report at 28, 44.
---------------------------------------------------------------------------
With respect to commenters that expressed concerns about
obligations for authorized third parties, including the limitation on
third party collection, use, and retention of covered data, the CFPB
notes that those provisions ensure that consumers provide express
informed consent to third parties that access covered data, that
consumers retain control over third parties' access, and that third
parties act on behalf of consumers when accessing covered data. The
CFPB's responses to commenter concerns related to the third party
authorization procedures and obligations are discussed below in part
IV.D. Further, and as discussed in part IV.D.4, the CFPB disagrees with
commenters' assertions that the rule would competitively disadvantage
third parties relative to data providers. Data providers and third
parties may use data that result from direct consumer relationships
without adhering to the third party authorization procedures and
obligations, and the final rule also does not treat covered data
providers differently than other third parties when they act as
authorized third parties themselves. With respect to comments about the
competitiveness of the U.S. generally, the purpose of this rule is to
ensure that third parties are acting on behalf of consumers. With
respect to comments about third party oversight and data security, see
the discussion below in part IV.3, IV.5, IV.C.4-5, and IV.D.4.
2. Comments Regarding the Rulemaking Process
The CFPB issued the proposed rule on its website on October 19,
2023, and published it in the Federal Register on October 31, 2023,
with comments due by December 29, 2023. Some commenters asserted that
the CFPB's comment period should have been longer. One commenter
disagreed and suggested that requests to extend the comment period were
pretextual efforts to delay implementation.
The Administrative Procedure Act does not specify a particular
period of time for a public comment period,\33\ and the comment period
in this rulemaking was sufficient. This is illustrated by, among other
things, the many detailed comments the CFPB received from stakeholders
of all types, sizes, and viewpoints. Additionally, as noted above in
part II, the CFPB has engaged in extensive public outreach since 2016
related to consumer-authorized data sharing, including through an RFI,
an ANPR, and the SBREFA process. The CFPB also has taken various steps
in response to the specific concerns raised with respect to the
substantive provisions of the proposal. In particular, as discussed in
part IV.A.4, the CFPB has determined to not finalize the rule with
respect to small depository institution data providers.
---------------------------------------------------------------------------
\33\ See 5 U.S.C. 553(c).
---------------------------------------------------------------------------
3. Comments Regarding Liability Among Commercial Entities
Comments Received
Many commenters addressed the general topic of liability. A number
of data provider commenters, academic researchers, and research
institute commenters predicted that the final rule would increase the
volume of sensitive financial data accessed by third parties,
particularly sensitive information to initiate a payment (under
proposed Sec. 1033.211(c)), which they viewed as increasing the risk
of unauthorized transactions or other harms arising from the compromise
of a data provider's or third party's information systems, such as the
risk of inaccurate data transmission. A number of data provider
commenters noted that consumers might seek to hold data providers
responsible for damages, or that data providers would face increased
costs related to reimbursing consumers for a third party having
fraudulently induced the consumer's authorization to access covered
data. These commenters expressed concern that this would subject data
providers to losses arising from liability and other compliance
obligations, such as costs due to Regulation E and Z error
investigations, preventing monetary losses to accounts, seeking
reimbursement from third parties, and safety and soundness standards.
Commenters also noted other laws, including State laws, related to
``fraud,'' ``negligence,'' ``privacy,'' ``identity theft,'' and ``data
security,'' but did not otherwise identify sources of liability.
Several commenters also raised questions about the applicability of the
FCRA, which are described separately below in part IV.4.
Many data provider commenters asserted that the proposal had not
accounted for data providers' potential exposure to liability-related
costs or ensured third parties had incentives to manage liability and
otherwise demonstrate capacity to cover losses directly caused by third
parties. Some of these commenters stated that the proposal had
incorrectly assumed that liability could be allocated adequately
through private agreements (including private payment network rules and
bilateral contracts), the Electronic Fund Transfer Act (EFTA), 15
U.S.C. 1691 et seq., the Truth in Lending Act (TILA), 15 U.S.C. 1601 et
seq., and their implementing regulations. Commenters generally
suggested the CFPB address liability by mandating a comprehensive
approach to assigning liability or safe
[[Page 90847]]
harbors for data providers, clarifying the role of bilateral data
access agreements to allocate liability, or take other steps to reduce
harms that might create liability risk. By contrast, a trade
association representing third parties and a data aggregator stated
that the liability allocation under EFTA and TILA, combined with the
third party data security and privacy obligations under the proposal,
would be adequate to address liability concerns, although these
commenters also expressed concern about relying on bilateral contracts
to allocate liability. One commenter stated that liability should flow
with the data, but that data providers and authorized third parties
should be permitted to allocate liability amongst themselves by
contract.
In particular, a data provider commenter expressed criticisms of
private network rules, stating that they do not give data providers
sufficient ability to recoup losses among multiple third parties, some
of which might not be financially viable or be downstream of the
authorized third party and outside of contractual privity; they do not
provide for a clear liability framework or sufficient fraud or data
security protections for higher-risk ``pay-by-bank'' transactions; and
they do not fully address the costs of error investigations or other
customer service particularly where consumers expect data providers to
make them whole following a data breach.
With respect to bilateral contracts, several data provider and
third party commenters stated that they are costly to negotiate and
enforce (including against third parties that might not be financially
viable), would result in uneven liability allocations across the
market, and would generally protect the interests of the largest data
providers. Several third party commenters also expressed concern that
they might include unnecessary terms based on an overbroad
interpretation of third party risk management obligations or be used to
deny access pretextually.
Data provider commenters also asserted that third party compliance
with GLBA Safeguards Framework, as contemplated under the proposal,
would be insufficient to protect consumers or data providers from
liability risk because third parties would lack incentives to manage
their data security if they were not financially liable for their
conduct, and because they are not subject to supervision. A consumer
advocate commenter also stated that clear expectations for liability
would provide third parties greater incentive to manage data security
risks.
To address these concerns, a wide range of data provider
commenters, a trade association representing third parties, an academic
researcher, and a consumer advocate recommended that the regulatory
text include a comprehensive liability-allocation provision for any
losses arising from the third party's misuse of a consumer's payment
credentials to conduct a fraudulent transaction, losses arising from
the unauthorized access of payment credentials due to a data breach, or
other losses arising from harms occurring from data in that party's
possession. Several data provider commenters and academic researcher
commenters noted that other open banking regimes around the world take
a similar approach. One trade association noted that, while liability
is traditionally determined based on which party has possession of the
data, the rule does not indicate that this is the case. Other data
provider commenters, including a number of credit union commenters,
recommended that the final rule establish a ``safe harbor'' for data
providers required to make data available under the final rule that
protects the data provider from claims from consumers and third
parties. Some commenters presented different versions of such an
approach, such as by conditioning the absence of liability on whether
the data provider had actual knowledge of the third party's data
security risk, or the third party making representations about its data
security practices, or on the third party's possession of a
certification or credential.
While some data provider and third party commenters expressed
concern with reliance on bilateral data access agreements to allocate
liability, some of these data provider commenters stated that they
could be used to address liability concerns. Several data provider
commenters recommended that the final rule address liability by
clarifying that data providers are not precluded from exercising
discretion to comply with prudential safety and soundness obligations,
including third party risk management expectations. Several of these
commenters recommended that data providers be permitted to deny third
parties, including data aggregators, access to a developer interface if
they did not accept contractual terms related to liability, such as
indemnification and insurance obligations. Several data provider
commenters and related trade associations recommended that third
parties be required to have or certify that they have adequate capital
or insurance to cover losses. However, a data aggregator commenter
stated that the rule should affirm the adequacy of the existing
liability framework under EFTA and Regulation E and TILA and Regulation
Z to help limit liability disputes during negotiations of bilateral
data access agreements. Comments related to the role of such agreements
in managing third party risk are discussed in greater detail in part
IV.C.4 below.
Data provider commenters also recommended that the rule address
liability by subjecting third parties to additional data security
obligations, such as the FFIEC information security handbook appliable
to depository institutions (discussed further below in part IV.D) or
CFPB supervision. A research institute commenter also supported
clarifying the CFPB's intent to supervise third parties as a way to
reduce concerns related to liability.
A data provider commenter requested that the final rule clarify
whether the data provider has any liability in the context of specific
provisions of the proposal: (1) if a third party collects more
information than is necessary to offer a specific product or service;
and (2) if a data breach occurs because an authorized third party does
not delete data after a consumer revokes its authorization or does not
timely communicate the revocation to a data aggregator.
Response to Comments
The CFPB has determined it would not be appropriate for this rule
to impose a comprehensive approach to assigning liability among
commercial entities or safe harbors from the requirements of EFTA and
Regulation E or TILA and Regulation Z. The ability of payees to
initiate electronic payments has existed for decades and the Regulation
E concerns raised by commenters are not specific to CFPA section 1033.
Although this rule facilitates sharing of payment initiation
information with third parties so that they can initiate electronic
payments, the rule does not require account write access or otherwise
require payment initiation. Applicable payment authorization
requirements continue to separately apply. As noted in the proposal,
consumers have a statutory right under EFTA to resolve errors through
their financial institution, while private network rules, contracts,
and other laws address which payment market participant is ultimately
liable for unauthorized transfers and other payment errors. As
discussed further below, the U.S. payment system allows non-bank payees
to initiate payments through their depository institution, and those
partner depository institutions
[[Page 90848]]
also bear responsibility for who is allowed to access the payment
networks.
The CFPB is aware that it is common for non-bank payees, such as
utility companies, charities, non-bank lenders, community
organizations, and other billers, to initiate payments through their
depository institution. The payee's depository institution, referred to
as an originating depository financial institution in the context of
ACH payments, is responsible for ensuring that any payments it
initiates on the payee's behalf are correct and authorized, as they are
subject to private network rules and safety and soundness requirements
related to risk management.\34\ Data providers that are Regulation E
financial institutions will continue to have error resolution
obligations for transfers initiated using payment information shared
under this rule, just as they do today when a consumer shares
information with a payee or a consumer's payment credentials are
compromised, and can seek reimbursement from an originating depository
financial institution according to 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 depository financial institution is entitled
to reimbursement from the originating depository financial institution
that initiated the unauthorized payment. Similarly, data providers that
are Regulation Z credit card issuers will continue to have error
resolution obligations under TILA. Commenters did not identify a
plausible method through which the proposal would increase the risk of
credit card fraud. The final rule does not require data providers to
make available credit card payment information. For both Regulation E
accounts and Regulation Z credit cards, because the final rule only
requires data providers to share information and does not require that
they allow third parties to initiate payments using that information,
any costs arising from error investigations and the recoupment of
losses by data providers are a function of how private network rules
operate. The final rule does not impinge on such private arrangements.
---------------------------------------------------------------------------
\34\ See, e.g., OCC Bulletin 2006-39, Automated Clearing House
Activities: Risk Management Guidance (Sept. 1, 2006), https://www.occ.gov/news-issuances/bulletins/2006/bulletin-2006-39.html;
NACHA Operating Rules Section 2.2: Warranties and Liabilities of
Originating Depository Financial Institutions; NACHA Operating Rules
Subsection 2.2.3 Liability for Breach of Warranty (``Each ODFI
breaching any of the preceding warranties shall indemnify each RDFI,
ACH Operator, and Association from and against any and all claim,
demand, loss, liability, or expense, including attorney's fees and
costs, that result directly or indirectly from the breach of
warranty or the debiting or crediting of the entry to the Receiver's
account. This indemnity includes, without limitation, any claim,
demand, loss, liability, or expense based on the ground that the
debiting of an entry to an account resulted, either directly or
indirectly, in the return of one or more items or entries of the
Receiver due to insufficient funds. This indemnity also includes, in
the case of a Consumer Account, without limitation, any claim,
demand, loss, liability, or expense based on the ground that the
failure of the ODFI to comply with any provision of these rules
resulted, either directly or indirectly, in the violation by an RDFI
of the Federal Electronic Fund Transfer Act or Federal Reserve Board
Regulation E.'').
---------------------------------------------------------------------------
Commenters 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 finalizing 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; implementing authorization procedures for third parties
that would require they commit to data access, use, and retention
limitations; implementing policies and procedures regarding data
accuracy; and requiring compliance with the GLBA Safeguards Framework.
These provisions are intended to drive market adoption of safer data
sharing practices. With respect to commenters' suggestions to reduce
costs associated with liability through data access agreements or other
conditions for third parties attempting to access consumer data, see
parts IV.C.4 and IV.D.4. With respect to the suggestion that authorized
third parties certify to consumers as to capital adequacy or insurance,
see part IV.D.1 for discussion of comments.
Finally, the CFPB does not believe it would be appropriate to
attempt to establish a comprehensive approach to addressing liability
(including through safe harbors) for laws it does not administer, such
as State laws dealing with data security, privacy, identity theft,
negligence, and fraud. The extent of data providers' liability for
failure to comply with their obligations under this final rule is
provided for under the CFPA.
The CFPB also notes that commenters did not provide legal analysis
or factual evidence about the likelihood that data providers would
actually incur legal liability under these laws when consumers request,
or Federal law requires, they make data available to a third party that
subsequently misuses or mishandles the data. While some commenters
stated that consumers would be likely to seek to recoup from the data
provider losses arising from third party conduct, it is not clear to
what extent that is likely to occur when losses arise from a third
party to which the consumer requested the data provider make
information available. To the contrary, a trade association commenter
indicated that liability typically resides with the party that
experiences a data breach. Nor did commenters provide evidence of the
extent to which data providers actually defend against claims of such
liability, despite data providers' long-standing practice of consumer-
authorized third party data sharing. To the extent there are complex
factual or legal questions about a data provider's liability for
directly contributing to consumer harm, commenters did not identify
particular scenarios, and the CFPB does not believe it would be
appropriate to make statements about a data provider's liability in
this final rule. As an additional and independent reason, commenters
did not identify the legal authority the CFPB could rely on to modify
laws it does not administer.
4. Comments Regarding Potential Overlaps With Other Consumer Financial
Laws and CFPB Rulemaking Activity
Electronic Fund Transfer Act and Regulation E
Comments
In addition to the liability comments discussed above, some data
provider commenters specifically commented on the applicability of EFTA
and Regulation E. Some data provider commenters asked the CFPB to apply
Regulation E error investigation requirements to all third parties. A
few data provider commenters stated that the CFPB should clarify that
data aggregators are Regulation E service providers, asserting that the
data aggregator is in the best position to control for risks related to
the transactions it permits a consumer to conduct through its system. A
trade association representing data providers asked the CFPB to clarify
that a data access agreement between an aggregator and data provider is
an ``agreement'' for purposes of the Regulation E service
[[Page 90849]]
provider provision. A data provider commenter asked the CFPB to clarify
that, if a third party is a Regulation E financial institution, such as
a digital wallet provider that obtains permissioned data access under
CFPA section 1033, it would have error resolution responsibilities for
payments initiated using data obtained from the developer interface and
that such digital wallet providers should be required to provide their
contact information to consumers.
Response to Comments
The CFPB has determined that it is not appropriate or practical to
deny consumers their statutory right to resolve errors through their
financial institution and this final rule does not change such rights
under EFTA and Regulation E. The Regulation E definition of financial
institution means a bank, savings association, credit union, or any
other person that directly or indirectly holds an account belonging to
a consumer, or that issues an access device and agrees with a consumer
to provide electronic fund transfer services.\35\ The CFPB declines to
expand the scope of the Regulation E service provider provision to data
aggregators, because doing so would limit consumers' ability to resolve
errors and unauthorized transactions through their account-holding
financial institution. Whether a given entity is a service provider for
a given electronic fund transfer will depend on the relationship
between the entities involved in making that individual transfer, not
whether the payee used payment credentials shared under this final rule
to initiate the payment. Negating a consumer's statutory right to go to
their financial institution to resolve errors also would result in an
illogical and harmful error resolution regime. From the consumer's
perspective, they may not know whether an error is related to data that
was shared under CFPA section 1033. The CFPB is aware that some
financial institutions attempted to have consumers enter into
agreements to waive EFTA rights in situations where they shared account
credentials or other information with a third party, even though such
agreements violated the EFTA anti-waiver provision in 15 U.S.C.
1693l.\36\ It was unclear at the time how exactly the depository
institutions intended to enforce this waiver language. One concern was
that it would be used to deny all Regulation E error resolutions rights
to consumers who had shared any information with a data aggregator,
even if the financial institution did not know whether the error was
related to that shared information. It also would be burdensome and
likely infeasible for the consumer to sort out when they should go to
their financial institution for help versus a third party versus
another entity for a transaction that they do not recognize.
---------------------------------------------------------------------------
\35\ 12 CFR 1005.2(i).
\36\ See Consumer Fin. Prot. Bureau, Regulation E FAQs, Error
Resolution: Unauthorized EFTs #8, https://www.consumerfinance.gov/compliance/compliance-resources/deposit-accounts-resources/electronic-fund-transfers/electronic-fund-transfers-faqs/ (last
updated June 4, 2021).
---------------------------------------------------------------------------
Data providers and third parties that are Regulation E financial
institutions--including digital wallet providers, person-to-person
payment 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. These error resolution obligations include requirements on the
financial institution to provide consumers with the financial
institution's contact information.
Fair Credit Reporting Act and Regulation V
The proposal noted that a third party engaged in data aggregation
activities could be a consumer reporting agency under the FCRA if it
met the elements of the FCRA's definition of ``consumer reporting
agency.''
Comments
Some commenters addressed the applicability of the FCRA. Many data
providers and data provider trade association commenters stated that
the final rule should provide that data providers are not furnishers
when they provide data pursuant to consumer authorization. These
commenters asserted that the compliance burden of being a furnisher is
significant and could overwhelm smaller financial institutions. They
also argued that, unlike traditional furnishing, data providers sharing
data under CFPA section 1033 are simply facilitating consumers'
requests to access their data.
Other commenters, primarily data aggregators, stated that data
aggregators should not be considered consumer reporting agencies when
they transfer data pursuant to consumer authorization. These commenters
argued that consumer-authorized data sharing is different from the
provision of consumer reports because consumers have control over the
sharing of their data, because data aggregators act as mere conduits
for transmission of the data, and because consumers have direct
relationships with data aggregators. One data aggregator commenter
predicted that if data aggregators could be consumer reporting
agencies, then data providers that are FCRA-covered furnishers would
deny access unless the aggregators agreed to data access agreements
with terms related to indemnification for FCRA liability. A third party
trade association commenter contended that data providers that are
FCRA-covered furnishers could deny access to data aggregators in the
absence of a data access agreement. Other commenters stated that
treating data aggregators as consumer reporting agencies would result
in unintended consequences. For example, a third party trade
association commenter asserted that compliance with the FCRA could
require data aggregators to access and retain more data than they do
currently. And a data aggregator commenter stated that consumers might
be confused if they attempt to correct the accuracy of any information
transferred by a data aggregator, because data aggregators do not hold
the underlying data; therefore, the data held by the data aggregator
may differ from the versions held by the data provider and other third
parties.
Some commenters requested that the final rule exclude FCRA-covered
entities and data from the rule's coverage. Several consumer reporting
agency commenters and a consumer reporting agency trade association
commenter asserted that consumer reporting agencies should be excluded
from coverage because they are already subject to extensive regulation
under the FCRA. A data aggregator commenter suggested that the CFPB
rely on existing authorities and not impose new regulations on the
collection, use, and retention of covered data where such collection,
use, and retention may be addressed by other laws, such as the FCRA.
And a consumer reporting agency commenter stated that consumer reports
should be excluded from the definition of ``covered data'' because
otherwise the limited purposes that authorize consumer reporting
agencies to share consumer reports might conflict with the purposes for
which consumers might authorize sharing of their covered data. The
consumer reporting agency trade association commenter stated that the
proposed limitations on use and retention of covered data might
complicate FCRA compliance by entities offering products that rely on
indefinite consumer authorization, including products that allow
[[Page 90850]]
consumers to self-report rental and utility payment information to
their credit file to enhance their credit histories. Data aggregator
commenters and a third party trade association commenter claimed that
the FCRA's framework is complex and confusing when applied in the
context of consumer-authorized data access. And a data aggregator
commenter asserted that the proposed rule's consumer protections would
be more appropriate for consumer-authorized data access than FCRA
requirements.
Several commenters raised questions about the intersection of the
final rule and the FCRA, including the extent of overlap, duplication,
or conflict between the final rule and the FCRA. These commenters asked
for clarification on various specific questions, including: which
activities would make a data provider an FCRA-covered furnisher; which
use limitation standard applies if consumer-authorized data are subject
to both the final rule and the FCRA; which activities would make a data
aggregator a consumer reporting agency; whether data aggregators that
are consumer reporting agencies would have to provide consumer reports
to consumers at their request; how data aggregators that are consumer
reporting agencies would comply with their FCRA dispute obligations if
data providers are not FCRA-covered furnishers; how data aggregators
that are consumer reporting agencies could maintain accurate consumer
reports given the proposed limits on retention; which uses of covered
data constitute permissible purposes under the FCRA; whether third
parties can be both data aggregators under the final rule and consumer
reporting agencies under the FCRA; whether financial institutions may
combine disclosures and consent forms required by the final rule and
the FCRA; whether specialty consumer reporting agencies may collect and
retain consumer-authorized transaction data to comply with the FCRA;
and whether information from de-identified consumer reports used for
research purposes could also be covered data subject to the proposed
restrictions on secondary use.
Finally, some commenters stated that the CFPB should coordinate the
FCRA and Personal Financial Data Rights rulemakings.\37\ A bank trade
association and credit union trade association stated that until one of
these rules had been finalized, they could not fully understand the
impacts of one rule on the other. A data provider/third party trade
association commenter suggested pausing the FCRA rulemaking until the
Personal Financial Data Rights rulemaking is finalized to fully
understand each rule's impact. A consumer reporting agency commenter,
an industry trade association commenter, and a financial holding
company commenter requested that the Personal Financial Data Rights
final rule be issued before the FCRA proposed rule. The industry trade
association commenter and financial holding company commenter asserted
that concurrent rulemaking adversely impacts the public's ability to
meaningfully comment on each proposal. A bank trade association
commenter recommended postponing compliance with this final rule until
after an FCRA rule is finalized, while a data aggregator commenter
asked the CFPB to wait until after this rule is finalized to address
the applicability of the FCRA to data aggregators. And a research
institute commenter suggested that certain definitions, such as those
relating to data aggregators and FCRA-covered furnishers, be harmonized
between the final rule and the FCRA rulemaking.
---------------------------------------------------------------------------
\37\ The CFPB assumes commenters were contemplating an FCRA
rulemaking with a scope similar to what was described in the CFPB's
FCRA 2023 SBREFA Outline, which included proposals under
consideration related to data broker activities and medical debt
information. See Consumer Fin. Prot. Bureau, Small Business Advisory
Review Panel for Consumer Reporting Rulemaking Outline of Proposals
and Alternatives Under Consideration (Sept. 15, 2023), https://files.consumerfinance.gov/f/documents/cfpb_consumer-reporting-rule-sbrefa_outline-of-proposals.pdf.
---------------------------------------------------------------------------
Response to Comments
As an initial matter, the CFPB has determined that this final rule
does not affect a person's obligations or duties under the FCRA. The
final rule does not alter the types of data, parties, or permissible
purposes covered by the FCRA. Because the final rule does not change
substantive requirements under the FCRA or Regulation V, the commenters
that raised questions about the intersection of the FCRA with CFPA
section 1033 and how to comply with FCRA obligations and duties must
look to the FCRA and Regulation V to determine how to comply with a
particular FCRA requirement. For example, whether a third party, such
as a data aggregator, is a consumer reporting agency under the FCRA
depends on whether the third party falls within the definition of
``consumer reporting agency'' in the FCRA.\38\ Similarly, whether a
certain use of covered data constitutes a permissible purpose is
determined by looking to the FCRA.\39\ This is true with respect to any
question about what a person subject to this final rule must do to
comply with the FCRA and Regulation V.
---------------------------------------------------------------------------
\38\ See 15 U.S.C. 1681a(f) (defining consumer reporting
agency).
\39\ See 15 U.S.C. 1681b (identifying permissible purposes).
---------------------------------------------------------------------------
The CFPB also has determined that the requirements of this final
rule are not inconsistent with the FCRA or Regulation V. Some
commenters noted that certain uses of data might be permitted by the
FCRA but not authorized by the Personal Financial Data Rights rule as
proposed. Compliance with this final rule does not, however, require a
person to violate the FCRA or Regulation V. Therefore, a person that is
subject to this final rule and the FCRA/Regulation V must comply with
both. This is no different than for any person who is subject to
several overlapping laws and regulations. For example, a third party
may have to contemporaneously provide disclosures relating to
Regulation E accounts, Regulation Z credit cards, and the GLBA and
Regulation P. When applicable, a third party subject to all these laws
must satisfy their respective requirements. Complying with CFPA section
1033 and the final rule is no different. Thus, it is unnecessary to
exclude certain parties, such as consumer reporting agencies, or FCRA-
covered uses from the rule's coverage.
The CFPB also received comments about whether data providers are
furnishers under the FCRA. The CFPB would not consider data providers
under this final rule to be furnishers solely by virtue of permitting
data access pursuant to an authorization that is consistent with the
final rule. This is the case even assuming data are provided to a data
aggregator that qualifies as a consumer reporting agency. In these
unique circumstances, the consumer, and not the data provider, would be
the party that is furnishing data to the consumer reporting agency.
This is the case because of a particular combination of circumstances,
including that the data are only shared with the aggregator after the
data provider is asked to do so by the consumer; the data are shared
pursuant to a written authorization designed to ensure that the
consumer has meaningful control of the uses of the specific data that
are shared; the data are further protected by use restrictions to
ensure they continue to be used for the benefit of the consumer; and
the data provider is not exercising its own agency or control or
benefiting from the arrangement, but rather is simply
[[Page 90851]]
facilitating the consumer's decision to furnish.\40\
---------------------------------------------------------------------------
\40\ See, e.g., 12 CFR 1022.41(c)(3) (Under the Furnisher Rule
in Regulation V, when the consumer furnishes information to a CRA
about themselves, the consumer is not considered a ``furnisher.'').
---------------------------------------------------------------------------
The CFPB received comments seeking clarification about whether data
aggregators are consumer reporting agencies under the FCRA. However,
this final rule does not cause data aggregators to incur legal
liability under the FCRA that they would not otherwise assume through
their ordinary operations. Addressing this topic is not necessary to
finalize this rulemaking because whether a data aggregator is a
consumer reporting agency under the FCRA requires a fact-specific
inquiry of considerations beyond the scope of this final rule. Data
aggregators may engage in a variety of activities and have multiple
business models, and whether a data aggregator is a consumer reporting
agency will depend on the satisfaction of all components of the
statutory definition in the FCRA--a determination not affected by this
final rule.
The CFPB disagrees that the sequencing of the Personal Financial
Data Rights and FCRA rulemakings adversely impacted the public's
ability to comment on the Personal Financial Data Rights proposed rule.
After issuing the Personal Financial Data Rights proposed rule, the
CFPB published a proposed rule regarding medical information under the
FCRA. See 89 FR 51682 (June 18, 2024) (Medical Debt Proposed Rule). The
Medical Debt Proposed Rule would remove a regulatory exception in
Regulation V from the limitation in the FCRA on creditors obtaining or
using information on medical debts for credit eligibility
determinations and would limit the circumstances under which consumer
reporting agencies are permitted to furnish consumer reports containing
medical debt information to creditors when making credit eligibility
determinations. The CFPB is also engaged in a rulemaking focused on
data broker activities (Data Broker Rulemaking).
With respect to the sequencing of the Personal Financial Data
Rights and the Medical Debt and Data Broker rulemakings, the fact that
this final rule does not change what a person would need to do to
comply with its existing obligations under the FCRA means that
completing the Medical Debt and Data Broker rulemakings is not
necessary to finalize this rulemaking. The CFPB will consider feedback
received in the course of the Medical Debt and Data Broker rulemakings,
evaluate the further steps it may take in those rulemakings, and will
respond to comments as appropriate.
The CFPB acknowledges that the potential applicability of the FCRA
to uses of covered data under the final rule presents operational
complexity, and the CFPB is taking steps to coordinate the final rule
with the ongoing FCRA rulemakings. As described in part IV.A.5, the
CFPB is substantially revising the compliance deadlines for data
providers under the final rule. The CFPB has determined that the
extension of the compliance deadlines strikes the appropriate balance
between carrying out the objectives of the statute while also providing
an entity covered by the final rule with more time to work through
these operational challenges and understand the entity's compliance
obligations under the final rule in light of the FCRA.
Gramm-Leach-Bliley Act and Regulation P
A few commenters addressed the general applicability of the GLBA
and Regulation P, 12 CFR part 1016. Several commenters asked for
clarity about how financial institutions should comply when data are
subject to both the GLBA and the Personal Financial Data Rights rule.
For example, a bank commenter and a bank trade association commenter
asked which use limitation standard would apply. A third party
commenter suggested that the CFPB rely on existing authorities and not
impose new regulations on the collection, use, and retention of covered
data where the collection, use, and retention of the data may be
addressed by other laws, including the GLBA. A research institute
commenter asserted that consumers might be confused if they received
multiple disclosures.
Response to Comments
The CFPB has determined that the final rule does not affect a
person's obligations or duties under the GLBA. In addition, the CFPB
has determined that the final rule is not inconsistent with the GLBA or
Regulation P. As with the FCRA, some commenters sought clarification
about how a person would comply when data are subject to the GLBA and
CFPA section 1033, including whether the limitations on collection,
use, and retention of data under the final rule would apply where such
limitations are not imposed under the GLBA and Regulation P. While the
GLBA and Regulation P may permit some uses of information that may not
be permitted under the final rule, compliance with the final rule does
not require a person to violate the GLBA or Regulation P. Moreover, the
CFPB expects that a person covered by the final rule is experienced
with managing the respective requirements of applicable State and
Federal laws, including the implementation of overlapping disclosure
requirements.
Other commenters raised broader issues. For example, a data
aggregator commenter suggested that the CFPB should encourage Congress
to amend GLBA or pass a Federal data privacy law. This commenter also
suggested that the CFPB undertake a GLBA rulemaking. These comments are
outside the scope of this rulemaking.
The CFPB declines to rely on existing legal frameworks, including
the GLBA and Regulation P, to regulate consumer privacy. The purposes
and objectives of CFPA section 1033, which are described in part III.A,
differ in certain respects from the purposes and objectives of other
laws (such as the GLBA). The requirements set forth in the final rule
are better suited to the open banking context, and could not be
substituted by applying existing authorities to consumer-authorized
access of covered data.
Comments addressing the GLBA in relation to a specific proposed
provision, such as comments recommending the final rule adopt
Regulation P's privacy protections for third parties, are addressed in
part IV.C and D.4.
CFPA Section 1034(c)
Section 1034(c) of the CFPA generally requires large financial
institutions to comply with consumer requests for information
concerning their accounts in a timely manner, subject to certain
statutory exceptions.\41\ In October 2023, prior to the proposal, the
CFPB issued an advisory opinion on CFPA section 1034(c) that interprets
this provision for the purpose of highlighting the obligations it
imposes upon large financial institutions.\42\ One commenter asked the
CFPB to clarify the extent to which the scope of data covered by CFPA
section 1033 and by the CFPA section 1034(c) advisory opinion overlap,
and how that may impact obligations for data providers.
---------------------------------------------------------------------------
\41\ Specifically, CFPA section 1034(c) applies to insured
depository institutions (including credit unions) that offer or
provide consumer financial products or services and that have total
assets of more than $10 billion, as well as their affiliates.
\42\ Consumer Fin. Prot. Bureau, Consumer Information Requests
to Large Banks and Credit Unions, 88 FR 71279 (Oct. 16, 2023).
---------------------------------------------------------------------------
CFPA sections 1033(b) and 1034(c)(2) both generally apply to
``information in the control or possession'' of a covered
[[Page 90852]]
person ``concerning the consumer financial product or service that the
consumer obtained from such covered person.'' However, the statutes
differ in several respects, including the types of covered persons
subject to, the exceptions to information covered by, and the form in
which information must be provided pursuant to the statutes.
The statutes impose separate obligations on large depository
institutions (including credit unions), and how the statutes impact
institutions' obligations will depend on the facts.\43\ As noted in the
advisory opinion:
---------------------------------------------------------------------------
\43\ As noted in the advisory opinion, the CFPB does not
interpret section 1034(c) to preempt or otherwise supersede the
requirements of other Federal or State laws and regulations designed
to protect privacy and data security, including, for example, any
restrictions that may be imposed in the CFPB's upcoming rule
implementing section 1033. See 88 FR 71279, 71279 n.27 (Oct. 16,
2023).
[S]ection 1033 governs consumer authorized third-party access to
data made available in electronic form in connection with third-
party provision of other products or services--including for
example, the provision of a potentially competing account offering.
This is why, for example, section 1033 is limited to data available
in the normal course, and why section 1033 requires data to be `made
available . . . in electronic form.'\44\
---------------------------------------------------------------------------
\44\ See id. at 71279 n.23.
See also part IV.C regarding a comparison between CFPA sections
1034(c) and 1033 with respect to the final rule's prohibition on fees
for data access.
5. Other Comments
A number of commenters sought information on how the CFPB will
conduct oversight of third parties. Commenters stated that many
authorized third parties are outside the CFPB's enforcement or
supervisory jurisdiction, and asserted that data aggregators pose
relatively greater risks to consumers than authorized third parties.
Some commenters also asked whether the CFPB would consider complaints
from industry participants when setting supervision and enforcement
priorities, and asked that the CFPB encourage consumers to submit
complaints to its consumer complaint program.\45\ Several commenters
sought information on how the CFPB would provide guidance after the
final rule is issued. In addition, a consumer advocate recommended that
the CFPB engage in a consumer education campaign to inform consumers of
their rights under the rule. The commenter explained that improved
consumer understanding of consumer-authorized data sharing would
increase consumer confidence in sharing data and protect them from bad
actors.
---------------------------------------------------------------------------
\45\ See generally Consumer Fin. Prot. Bureau, Submit a
complaint about a financial product or service, https://www.consumerfinance.gov/complaint/ (last visited Oct. 17, 2024).
---------------------------------------------------------------------------
SBA Advocacy requested that the CFPB determine whether the final
rule is necessary in light of current State law (citing the California
Consumer Privacy Act as an example) and whether the final rule
conflicts with State laws. Other commenters questioned whether the CFPB
had taken proper account of international open banking regimes in
developing the proposal.
With respect to questions about how the CFPB intends to enforce and
supervise for the requirements that apply to third parties, Sec.
1001.2(b) of the final rule provides additional assurance that
financial data processing by third parties, among others, is subject to
the CFPA. This includes enforcement and, where appropriate,
supervision, by the CFPB. In addition, the CFPB and FTC coordinate law
enforcement activities regarding the offering or provision of consumer
financial products and services by covered persons within the FTC's
jurisdiction under the FTC Act, including conducting joint
investigations where appropriate, to minimize duplication of efforts
and burden on FTC-covered industry participants. This may include
coordination on enforcement activities regarding the CFPA prohibition
on unfair, deceptive, or abusive acts or practices and the FTC
Safeguards Rule. The CFPB also coordinates with State attorneys general
and State regulators. With respect to questions about the role of
consumer complaints in establishing supervision and enforcement
priorities, the CFPB prioritizes supervisory and enforcement activity
on the basis of risk, taking into account, among other factors, the
size of each entity, the volume of its transactions involving consumer
financial products or services, the size and risk presented by the
markets in which it is a participant, the extent of relevant State
oversight, and any field and market information that the CFPB has on
the entity. Such field and market information can include, for example,
information from complaints and any other information the CFPB has
about risks to consumers and to markets posed by a particular entity.
In response to comments advocating for CFPB supervision of third
parties, including data aggregators, the CFPB's supervisory authority
is defined by the CFPA. The CFPB agrees that supervision of data
aggregators is important. Supervisory examinations over one or more
data aggregators, including larger participants in the consumer
reporting market, are scheduled or ongoing,\46\ and the CFPB will
continue to engage in this supervision as necessary.
---------------------------------------------------------------------------
\46\ See Supervisory Highlights, Issue 30, Summer 2023, 88 FR
52131, 52142 (Aug. 7, 2023).
---------------------------------------------------------------------------
With respect to guidance after the final rule is issued, the CFPB
plans to make available a range of resources to assist with effective
implementation of the rule, including a small entity compliance guide.
The CFPB also has a regulatory support program that can provide
assistance. With respect to comments about improving consumer awareness
of their rights under this rule, the CFPB notes that the consumer
protections in this rule are intended to ensure that consumers can
access their own data and can authorize access by third parties that
are acting on their behalf. For more discussion of consumer awareness
of third party access, see part IV.D below. The CFPB intends to further
consider how to increase consumer awareness of and confidence in
authorized third party data access.
The CFPB has considered State law and international legal
frameworks to inform the final rule's approach to data providers'
obligations to make data available upon request and third parties'
obligations to act on behalf of consumers in order to access such data.
Several States impose obligations on businesses to make information
available to consumers in a portable, structured format, where
technologically feasible.\47\ Several States also impose privacy
obligations on businesses. However, these State laws differ in terms of
their scope and substantive requirements. In addition, a number of
States include exemptions for businesses or data covered by certain
Federal consumer financial laws, like the GLBA.\48\ The CFPB believes
it is appropriate to carry out congressional intent to issue Federal
regulations pursuant to CFPA section 1033, including the
interoperability objectives of CFPA section 1033(d), by issuing
requirements applicable nationwide to promote safe, secure, reliable,
and competitive data access. The CFPB is not aware of conflicts between
State law and the final rule. See parts VI and VII for further
discussion of the impacts of State law.
---------------------------------------------------------------------------
\47\ See, e.g., Cal. Consumer Privacy Act of 2018 section
1798.130(a)(3)(B)(i)-(iii).
\48\ See, e.g., id. section 1798.145(e). See also SBREFA Outline
at 46 n.50.
---------------------------------------------------------------------------
As part of this rulemaking, the CFPB has considered international
open banking models, as discussed in the proposed rule and further
below. The CFPB's authority and policy approach
[[Page 90853]]
in this final rule are not identical to those of other jurisdictions.
In particular, as discussed in part IV.3, IV.C.2, and elsewhere in part
IV, the final rule does not require data providers to initiate
payments, unlike some other open banking regimes. The final rule
instead implements CFPA section 1033 with respect to a data provider's
obligation to make available covered data to consumers and third
parties authorized to access such data on their behalf. The CFPB has
taken account of the experience of international jurisdictions in
developing the final rule generally and as discussed in part IV.C.2
with respect to the prohibition on fees for third party access, part
IV.C.3 with respect to commercially reasonable performance standards,
and the final rule's approach to screen scraping, as discussed in part
IV.D.1. The CFPB believes any differences between the approach of this
final rule and those of other jurisdictions are appropriate in light of
the particular market and regulatory frameworks applicable to the U.S.
See parts VI and VII for further discussion of international
jurisdictions.
A. Subpart A--General
1. Overview
Subpart A of the final rule establishes the coverage and
terminology necessary to implement CFPA section 1033 for this rule,
beginning with Sec. 1033.101, which describes the authority, purpose,
and organization of the regulation in part 1033. Subpart A defines the
coverage of the final rule, sets forth tiered compliance dates, defines
terms appearing throughout the regulatory text, and, as finalized in
the Industry Standard-Setting Final Rule, sets forth criteria for
recognized standard setters.
2. Authority, Purpose, and Organization (Sec. 1033.101)
In the proposed rule, the CFPB proposed Sec. 1033.101(a) to
describe the CFPB's legal authority to issue the rule for the purposes
described in proposed Sec. 1033.101(b). Proposed Sec. 1033.101(c)
described the organization of the proposed rule within part 1033. The
Industry Standard-Setting Final Rule finalized the language in proposed
Sec. 1033.101(a) and a more limited version of proposed Sec.
1033.101(b) and (c), to reflect the limited purpose and organization of
the Industry Standard-Setting Final Rule. The CFPB did not receive
comment on the proposed rule's proposed language in Sec. 1033.101.
In this final rule, the CFPB is not making changes to the legal
authority language in Sec. 1033.101(a) that was finalized by the
Industry Standard-Setting Final Rule. The CFPB is amending the language
finalized by the Industry Standard-Setting Final Rule at Sec.
1033.101(b) and (c), as originally proposed by the proposed rule, to
reflect the purpose and organization of this final rule. Final Sec.
1033.101(c) also refers to the appendix containing standard setter
recognition procedures that was finalized as part of the Industry
Standard-Setting Final Rule. Other than with respect to Sec. 1033.101,
the final rule published in this Federal Register document does not
amend any of the provisions of the Industry Standard-Setting Final
Rule. The regulatory text published in this Federal Register document
restates the regulatory text finalized in the Industry Standard-Setting
Final Rule (other than with respect to Sec. 1033.101) for clarity and
ease of reading.
3. Coverage of Data Providers (Sec. 1033.111(a) Through (c))
Proposal
Section 1033(a) applies to ``covered persons,'' as defined in the
CFPA. In the proposal, the CFPB explained its intent to implement the
broad coverage of CFPA section 1033 through this and supplemental
rulemaking. For this first rule to implement coverage and other
substantive provisions of CFPA section 1033(a), the CFPB proposed to
define a subset of covered persons that would be required to make data
available with respect to certain consumer financial products or
services: 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 CFPB explained that the last
of these categories would clarify that the proposed rule would cover
all consumer-facing entities involved in facilitating Regulation E
account and Regulation Z credit card transactions.
In the proposed rule, the CFPB discussed how payment data from
these products and services support common beneficial consumer use
cases today, including transaction-based underwriting and payment
initiation. Specifically, the CFPB proposed in Sec. 1033.111(b) to
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. The CFPB proposed in
Sec. 1033.111(c) to define data provider to mean a covered person, as
defined in 12 U.S.C. 5481(6), that is (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. In
example 1 to Sec. 1033.111(c), the CFPB proposed to provide an example
that a digital wallet provider is a data provider. The CFPB requested
comment on the proposed definitions.
The proposed rule also explained that the CFPB was considering
adding EBT-related data to the final rule, or reaching EBT cards in a
subsequent rulemaking. State and local administered needs-tested
benefits are exempt from EFTA coverage by statute. 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 requested 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 CFPA section 1033. The CFPB also requested
comment on third party practices related to consumer-authorized EBT
data, and the benefits and drawbacks of enabling third party access to
EBT-related data, including with respect to data security.
Comments
Many commenters, including third parties and consumer advocates,
stated that the proposed coverage was too narrow. Advocated additions
included all covered persons and financial products and services under
the CFPA, all Regulation Z creditors (such as mortgage, auto, and
payday lenders), payroll providers, holders of tax records, electronic
bill presentment providers, investment products, retirement accounts,
and small business lenders. Some third party commenters asserted that
data providers will otherwise restrict or fail to offer access to these
data. One bank data provider commenter stated that the narrow scope of
coverage could cause consumer confusion. A non-bank data provider that
also acts as a third party stated that
[[Page 90854]]
coverage should be broader because much or all of the covered data are
already made available by banks today.
Conversely, many data provider commenters requested narrower
coverage, and that the CFPB clarify the rule's applicability,
particularly with regard to pass-through payments and payment
facilitation providers. Some commenters asked for specific exclusions
for products or entities that they asserted are excluded from the
CFPB's authority under the CFPA, such as corporate credit cards and
merchants. Several third party and trade association commenters asked
the CFPB to clarify that the rule does not cover other entities that
initiate payments on the payee's behalf, such as embedded payment
service providers that provide payment processing services exclusively
for merchants, third party marketplaces operated prominently in the
name of their affiliate company, and loan servicers. One non-bank data
provider that also acts as a third party asked the CFPB to exclude
online marketplaces and ride sharing apps. Two data provider trade
associations asked the CFPB to exclude inactive or closed accounts.
Two trade associations commenting on the CFPB's TILA interpretive
rule regarding credit products marketed as BNPL,\49\ along with a
provider of BNPL products, stated that the Personal Financial Data
Rights rule should not apply to BNPL providers because they lacked
notice that such providers are card issuers under Regulation Z and that
the proposal did not adequately account for the impact on BNPL
providers. A third party trade association supported coverage of BNPL
providers as data providers, explaining in a comment on the CFPB's TILA
interpretative rule that it supports the consumer right to share their
balance and transaction information for any and all of their credit
accounts. A few bank data provider trade associations commenting on the
TILA interpretive rule recommended that the CFPB clarify that nonbank
BNPL providers are held to the same standards as banks with regard to
consumer protections generally.
---------------------------------------------------------------------------
\49\ Truth in Lending (Regulation Z); Use of Digital User
Accounts To Access Buy Now, Pay Later Loans, 89 FR 47068 (May 31,
2024).
---------------------------------------------------------------------------
With regards to pass-through payments, bank data providers, a large
nondepository data provider, and trades representing bank and
nondepository data providers stated that data related to those products
would be duplicative, introduce errors, provide limited consumer
benefit relative to the increased burden on digital wallet providers,
and conflict with their belief that the account-holding bank should
control access to that data. One data provider trade association
asserted that data providers should only be permitted to share data
that is unique to them. The commenter stated that banks cannot conduct
due diligence on the authorized third party that is requesting data
access through the digital wallet provider, and this could lead to
consumer confusion and other risks. The commenter asserted that these
digital wallets do not possess data pertaining to a consumer financial
product or service that the consumer obtained from the data provider.
Some bank data provider commenters cited security and liability
concerns about allowing pass-through payment providers to share data
with third parties, rather than requiring the third parties to go to
the underlying bank.
A few commenters stated that the proposal was unclear as to whether
any entity that controls or possesses covered data would have
obligations under the rule, even if a consumer did not obtain a covered
consumer financial product or service from the data provider and even
if the data do not concern a covered consumer financial product or
service. A few trade associations and other commenters asserted that
the CFPB needed to clarify whether point of sale terminal providers and
other payment service providers are covered under Sec. 1033.111(c).
One bank trade association asked the CFPB to clarify that the
obligation to make available covered data would not apply to consumers
who are domiciled outside of the U.S., stating that without this
clarification foreign requirements for data protection and privacy will
be triggered, impacting data handling and protection that vary widely
across countries.
The CFPB received many comments from individual consumers, consumer
groups, other nonprofit organizations, third parties, and Members of
Congress in support of covering EBT providers in this stage of the
rulemaking. Their reasons were similar to those raised during the
SBREFA process, including how consumers would benefit from increased
access to their EBT data and how such access could help identify fraud.
Some of these commenters also asserted that excluding EBT providers
from this rulemaking could worsen existing issues related to data
access and service. A few commenters supported a subsequent rulemaking
to cover EBT providers if they are not covered under this rule.
Some commenters, including industry trade associations and a Member
of Congress, cautioned against including EBT providers in this or any
future rulemaking. Although these commenters raised concerns the CFPB
considered in the proposed rule, like the potential for fraud to
increase and the lack of EFTA protections, some commenters also
asserted that the CFPB is not the right agency to address EBT data
access. These commenters asserted that Congress specifically excluded
EBT from being regulated as demand deposit accounts and instead largely
granted authority to regulate EBT to USDA. A payments trade association
commenter cautioned that agencies that administer EBT will not have
contractual relationships with entities involved with third party
access and therefore these entities will not need to comply with
certain restrictions put in place by the governing agencies.
Final Rule
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.111(a) through (c) as proposed, with some clarifying changes to
the definition of covered consumer financial product or service in
Sec. 1033.111(b)(3). This facilitation of payments prong in Sec.
1033.111(b)(3) is finalized to include facilitation of payments from a
Regulation E account or Regulation Z credit card, excluding products or
services that merely facilitate first party payments. For purposes of
part 1033, a first party payment is a transfer initiated by the payee
or an agent acting on behalf of the underlying payee. First party
payments include payments initiated by loan servicers.
As in the proposal, Sec. 1033.111(c) defines data provider to mean
a covered person, as defined in 12 U.S.C. 5481(6), that is: (1) A
financial institution, as defined in Regulation E, 12 CFR 1005.2(i);
(2) A card issuer, as defined in Regulation Z, 12 CFR 1026.2(a)(7); or
(3) Any other person that controls or possesses information concerning
a covered consumer financial product or service that the consumer
obtained from that person. Example 1 to paragraph (c) states that a
digital wallet provider is a data provider.
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. Data from checking
accounts, savings accounts, and other Regulation E accounts allow a
consumer or third party to view a consumer's income, expenses, fees,
and spending. Digital wallet providers hold similar valuable data that
can provide a complete understanding of a consumer's
[[Page 90855]]
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
issued by other institutions (sometimes referred to as pass-through
payments). Regulation Z 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. Given the foreign applicability provisions of Regulation E and
Regulation Z, covered consumer financial products and services in this
rule are limited to products and services obtained by consumers who
reside in the U.S. See Regulation E comment 3(a)-3 and Regulation Z
comment 1(c)-1 for a discussion of foreign applicability.
Covering Regulation E accounts, Regulation Z credit cards, and
payment facilitation products and services leverage existing
infrastructure for consumer-authorized data sharing, thus facilitating
implementation. Data providers generally share these covered data on
consumer interfaces today, and some share covered data with third
parties. Given how consumers' payment data are commonly shared and can
be used to access consumer funds or track household spending, it is
appropriate to prioritize these data for greater protection under this
rule. As discussed in part IV.C and D, the CFPB is also finalizing a
number of measures to foster a safe and secure data access framework.
In addition, consumers benefit from being able to permission access
to digital wallet pass-through data and the marginal burden on digital
wallet providers is generally limited. Digital wallet providers and
entities that refer to themselves as neobanks generally qualify as
Regulation E financial institutions; some also may be Regulation Z card
issuers. Digital wallet providers that facilitate pass-through payments
typically also provide a funds-holding asset account or credit card, so
would already be subject to the requirements of this rule, including
the requirement to maintain interfaces under Sec. 1033.301. The few
digital wallet providers who do not yet offer these products in
conjunction with their pass-through products tend to be very large,
sophisticated technology companies that commonly access and use data as
third parties. Although digital wallet providers today typically
qualify as Regulation E financial institutions under Sec.
1033.111(c)(1), including Sec. 1033.111(c)(3) provides clarity that
all digital wallet providers are data providers and ensures coverage as
payment products evolve. This provision makes clear that the rule
covers consumer-facing entities involved in facilitating Regulation E
account and Regulation Z credit card transactions, except, as discussed
below, products or services that merely facilitate first party
payments. Given that digital wallet providers--including pass-through
providers--typically are Regulation E financial institutions, the
marginal compliance burden of including the payment facilitation prong
is limited.
Moreover, the potential consumer benefit is clear. Digital wallets
are ubiquitous today, with both remote and point of sale acceptance.
Some companies that originated as non-financial providers, such as
search engines, social media companies, and retail merchants, are
steadily offering asset accounts and credit cards themselves--sometimes
leveraging data they have obtained from depository institutions for
underwriting or other purposes. As consumers increasingly connect
multiple financial products to these non-bank providers, and these
providers increasingly offer asset accounts and credit cards in
conjunction with other services, non-bank providers may control or
possess different or more robust covered data than the underlying
depository institution. Consumers may also find it more convenient to
permission access through the digital wallet provider or other payment
facilitation provider, and may expect to be able to do so. Accordingly,
requiring digital wallet data providers to make available data for both
pass through and non-pass through accounts may best align the rule with
consumer expectations, ease sharing for consumers who connect multiple
payment methods to their digital wallets or otherwise frequently use
their digital wallets, and provide consumers with access to more robust
payment transaction data. The CFPB agrees with commenters that pass-
through data providers should not be required to make available
information to initiate payment to or from a Regulation E account under
Sec. 1033.211(c); changes to the covered data provision are discussed
below in connection with subpart B.
The CFPB is clarifying the definition of covered consumer financial
product or service in Sec. 1033.111(b)(3) to exclude situations where
an entity is solely facilitating first party payments, such as a
merchant or mortgage loan servicer initiating a payment from the
consumer's account to itself. First party payments are distinct from
payment facilitation products. Accordingly, the CFPB is finalizing
Sec. 1033.111(b)(3) with language to explicitly exclude products or
services that merely facilitate first party payments. For purposes of
this definition, a first party payment is a transfer initiated by the
payee or an agent on behalf of the underlying payee. First party
payments include payments initiated by a loan servicer.
Situations where an entity is merely initiating a payment to itself
for a product or service it provided to the consumer would not be
enough to qualify as a covered consumer financial product or service.
For example, a mortgage servicer that merely initiates a payment to
fulfill the consumer's mortgage obligation would not qualify as
facilitation of payments under Sec. 1033.111(b)(3), as the mortgage
servicer is initiating a payment to itself or is otherwise acting an
agent to the underlying mortgage holder. Similarly, an online merchant
initiating a payment to itself for goods it sold directly to the
consumer, or a utility company initiating payment to satisfy a
consumer's electric bill, would not qualify as facilitation of payments
under Sec. 1033.111(b)(3). However, some first party payments continue
to fall within the definition of covered consumer financial product or
service, such as situations where the data provider is initiating a
transfer to itself in conjunction with a product that facilitates
payments to other payees, or the data provider is otherwise providing a
Regulation E or Regulation Z account. For example, Sec. 1033.111(b)
includes a digital wallet provider initiating a transfer from an
external bank account to the consumer's digital wallet held by that
same provider, a digital wallet provider initiating a pass through
transfer from the consumer's Regulation E or Regulation Z account to
another payee that participates in the debit or credit card network,
and a credit card provider initiating a credit card payment from the
consumer's external bank account to itself.
As stated in Sec. 1033.201(a)(1), a data provider's obligation to
make available data is limited to 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, in an
electronic form usable by consumers and authorized third parties. For
clarity, the CFPB is adding language to Sec. 1033.111(a) to reiterate
that a data provider's obligations are limited to covered data
concerning a covered consumer financial product or
[[Page 90856]]
service that the consumer obtained from the data provider.
With regard to excluding products that are not subject to the
CFPB's authority, any such exclusions would be superfluous, potentially
confusing, and create risk that they would be misused to undermine
coverage of payment facilitation products that do fall within the
CFPB's authority. The Sec. 1033.111(b) definition of covered consumer
financial product or service is expressly limited to a consumer
financial product or service as defined in 12 U.S.C. 5481(5). The CFPB
has decided not to add exclusions, such as an exclusion for online
marketplaces that are not otherwise subject to the CFPB's authority,
because that may create detrimental loopholes for products that also
provide a payment facilitation or other Regulation E access device
function. For example, an online marketplace may involve payments to
the data provider for products or services sold by that same data
provider, but also facilitate payments to other merchants.
The CFPB intends to implement CFPA section 1033 with respect to
other covered persons and consumer financial products or services
through future rulemaking. The CFPB declines to expand the scope of
covered data and consumer financial products and services in this final
rule. Prioritizing Regulation E accounts, Regulation Z credit cards,
and payment facilitation products and services advances competition
goals across a broader range of markets while addressing pressing
consumer use cases and risks. The CFPB also has considered that the
marginal risks to consumers of including these covered consumer
financial products and services is limited by Regulation E and
Regulation Z error protections applying to all the products covered by
this final rule; in addition, most (if not all) such covered data are
shared with third parties to some extent today. The CFPB has considered
that EBT cards are exempt from EFTA coverage by statute, but that
pursuant to the Consolidated Appropriations Act of 2023, the USDA has
been directed to engage in a rulemaking and issue guidance on EBT card
security practices. The Spring 2024 Unified Agenda shows that this USDA
rulemaking is in the proposed rulemaking stage, indicating that
completion of a final rule remains some period away.
In order to determine coverage, entities need to determine whether
they control or possess covered data concerning a covered consumer
financial product or service that the consumer obtained from that
entity, and whether they otherwise meet the definition of data provider
in Sec. 1033.111(c). This coverage determination is the same for all
entities, including those that in providing BNPL products may qualify
as card issuers under Regulation Z. BNPL providers had sufficient
notice of their potential inclusion in the rule because they received
notice that the CFPB proposed to cover Regulation Z card issuers and
credit cards under CFPA section 1033.
4. Coverage Threshold for Depository Institution Data Providers (Sec.
1033.111(d))
Proposal
In Sec. 1033.111(d), the CFPB proposed to exclude from the
requirements of this rule data providers that are depository
institutions without a consumer interface. The CFPB noted that such
institutions tend to be very small, may not have resources to support
or maintain online or mobile banking systems, and may use a
relationship banking model that provides a more personalized
relationship with their customers. The CFPB also proposed to limit the
exclusion to depository institutions, preliminarily determining that
the complicating factors that exist for depository institutions are
less likely to exist for nondepository institutions. The proposed rule
also noted that nondepository institution data providers within the
scope of the proposed rule tend to use business models built on the
ability to innovate using technology and to move quickly to implement
technological solutions. The CFPB sought comment on various issues,
including 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
covered by the rule.
Comments Received
Though a few commenters stated that all institutions should be
required to comply with the rule, the vast majority of those who
commented on this provision stated that some institutions should not.
Many credit union, bank, and credit union and bank trade associations
commenters stated that the proposed exemption was too limited. Many of
these commenters also stated that coverage should be based on asset
size, instead of the presence of a consumer interface, and suggested
thresholds ranging from $850 million to $10 billion in total assets.
Others stated that number of deposit accounts or customers should be
relevant to coverage, or that depository institutions under a certain
size should be able to ``opt out'' of the rule's requirements. A few
credit union trade association commenters and one credit union
commenter stated that there should be tiered exemptions where different
tiers of depository institutions would not need to comply with various
requirements of the rule: data providers with no consumer interface
should be completely excluded, depository institutions that meet the
SBA definition of a small business should only be required to provide a
consumer interface, and minimum technical specifications should not
apply to developer interfaces of depository institutions holding less
than $50 billion in assets.
Several nondepository entity trade association commenters and one
technology service provider commenter stated that nondepository
institutions that do not have digital banking should be exempt from the
rule. One nondepository institution trade association commenter stated
that there are many nondepository institutions that do not have a
consumer interface, including debt collectors.
While one bank commenter stated that depository institutions that
elect to eliminate their consumer interfaces after the rule's effective
date should not remain subject to the rule, a nondepository entity
trade association commenter stated that they should. One nondepository
entity trade association commenter stated that depository institutions
should be given a grace period to comply with the rule's requirements
when establishing a consumer interface while another stated that they
should not. Finally, SBA Advocacy stated that the CFPB should consider
third party exemptions that will not compromise data security and
privacy.
Final Rule
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.111(d) with modifications. Unlike the proposed rule, final Sec.
1033.111(d) bases coverage on a depository institution data provider's
total assets, not on the presence of a consumer interface. As in the
proposed rule, all nondepository institution data providers are covered
by the rule.
Final Sec. 1033.111(d) states that the requirements of subparts B
and C do not apply to data providers defined under Sec. 1033.111(c)(1)
through (3) that are depository institutions that hold total assets
equal to or less than the SBA size standard for the data provider's
appropriate NAICS code for commercial
[[Page 90857]]
banking, credit unions, savings institutions and other depository
credit intermediation, or credit card issuing, as codified in 13 CFR
121.201. The current size standard for all the relevant NAICS codes is
$850 million. Section 1033.111(d) also states that, if at any point, a
depository institution that held total assets greater than that SBA
size standard as of the final rule's effective date, subsequently holds
total assets below that amount, the requirements of subparts B and C
continue to apply. Section 1033.111(d)(1) provides information on how
to determine the SBA standard based on specific NAICS codes. Section
1033.111(d)(2) explains that total assets held by a depository
institution are determined by averaging the assets reported on its four
preceding quarterly call report data submissions to the FFIEC or NCUA,
as applicable, or its submissions to the appropriate oversight body to
the extent it does not submit such reports to the FFIEC or NCUA.
Relatedly, and as more fully discussed in the discussion of compliance
dates, Sec. 1033.121(c) addresses how to determine compliance dates
for depository institutions that hold total assets at or below the SBA
size standard but that subsequently cross that threshold.
Unlike the proposed rule, the final rule bases coverage on the
total assets held by a depository institution data provider and
provides those entities a reasonable amount of time to comply with the
part's requirements upon reaching the coverage floor. Asset size is a
more accurate proxy than the mere existence of a consumer interface to
help approximate a depository institution's resources and ability to
comply with the rule's requirements. An institution that may offer a
basic consumer interface may nevertheless not possess the resources or
technological sophistication to upgrade that interface and create a
compliant developer interface. A depository institution's total asset
size, however, provides information about an institution's size,
sophistication, and relative resources to comply with the rule because
an institution's size measured by assets will generally correlate with
its resources. In addition, the CFPB does not have information to
indicate that any depository institution data provider over the current
$850 million size standard lacks a consumer interface.\50\
---------------------------------------------------------------------------
\50\ If there were hypothetically such depository institutions,
their number would be very small and creating an exemption solely
for such institutions would add complexity to the regulatory regime
and not be proportionate.
---------------------------------------------------------------------------
Under the final rule, to streamline compliance, the specified
depository institution data providers are not subject to any
requirement to make data available through an interface. However, most
depository institution data providers with total assets at or below the
current $850 million size standards already have some form of consumer
interface, and the CFPB expects that such institutions will continue to
provide their customers with that service. The CFPB also understands
that many depository institution data providers with total assets at or
below the current $850 million size standards make at least some
covered data available to consumer-authorized third parties, and
expects that such institutions will continue doing so, including by
offering developer interfaces when the benefits of doing so are
commensurate with the institution's resources.
As with the proposed rule, the final rule covers all nondepository
institution data providers. Though a few commenters stated that
nondepository institution data providers without consumer interfaces
should not be covered by the rule's requirements, they did not offer
grounds to rebut the proposed rule's determination that nondepository
institution data providers lack the same complicating factors that
exist for their depository institution counterparts. Nondepository
institution data providers within the scope of the final 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.
As explained, the final rule does not cover depository institution
data providers that hold total assets below the SBA size standard for
the specific NAICS code that encompasses each depository institution
data provider subject to this rule. The size standard for each of the
named NAICS codes, currently $850 million, is re-evaluated by the SBA
at least once every five years. In theory, the size standards of the
named NAICS codes could diverge during that re-evaluation. The CFPB has
determined that, given the historical standards, the likelihood of that
occurring is minimal.
The CFPB believes the SBA size standard is an appropriate threshold
to determine depository institution data provider coverage at this
time. Several credit union trade associations and a trade association
of community banks stated that an $850 million threshold would address
concerns about the costs of providing data access to third parties
under the terms of the rule. In particular, a credit union trade
association believed such a threshold would be appropriate to address
concerns about the ability of smaller credit unions to remain
competitive, noting that those below the threshold might discontinue
services if they had to comply with the rule. As discussed further in
part VI.E.1, many community banks, credit unions, and trade
associations commented that they expect the costs for small depository
institutions of providing required data access to be much higher than
those estimated by the CFPB in the proposal. Though they did not
provide additional data or information that would allow the CFPB to
precisely update the cost estimates, the CFPB acknowledges that small
depository institutions might face additional challenges in
implementing the rule at this time. The CFPB believes that the SBA size
standard is an appropriate metric to ensure the rule does not unduly
burden entities that are not dominant in their field and may have
difficulty competing under the rule without sacrificing products or
services.
At least one bank trade association commenter recommended generally
that the coverage threshold be $10 billion in total assets, although
the commenter stated that if the threshold is not set at $10 billion,
then an asset threshold of $850 million would be appropriate.\51\ This
commenter did not provide reasoning for this position, and based on
other comments received, the CFPB believes depository institutions with
assets above the SBA size standard in the final rule will not face the
same types of constraints as those below. For example, a credit union
trade association recommended that credit unions with assets between
$850 million and $50 billion should be subject to the data provider
requirements of the rule, with the exception of minimum technical
performance requirements. As discussed in part IV.C.3, the CFPB has
made the minimum response rate requirement in Sec. 1033.311(c) more
flexible relative to the proposal and has lengthened the compliance
timelines for all data providers. Further, not covering depository
institutions with total assets of $10 billion and under would not cover
a large share of total accounts, at approximately 31 percent of covered
accounts. In contrast, setting the threshold at depository institutions
with more than $850 million in total assets
[[Page 90858]]
excludes approximately 10 percent of covered accounts.
---------------------------------------------------------------------------
\51\ The CFPB also received one comment from a software
developer stating that, until an accreditation process has been
developed, financial institutions with less than $10 billion in
assets should not be required to comply with the rule.
---------------------------------------------------------------------------
For now, in light of the reasons herein, the CFPB is not extending
coverage to depository institutions with assets of $850 million or
below. However, the CFPB anticipates that, as the process of building
out systems capable of complying with the rule's requirements plays out
and data providers, core providers, and other vendors work to
streamline the resources and processes necessary to comply, the costs
of compliance will go down, potentially making coverage for smaller
depository institutions more appropriate. Relative to the alternative
of a higher coverage threshold such as $10 billion in assets, covering
a larger share of depository institution data providers with this
rule--and, in particular, covering depository institution data
providers that use the same vendors and core providers as smaller
depository institutions--increases the likelihood that resources to
facilitate third party access will be available for smaller depository
institution data providers that seek to integrate them in the future.
The CFPB will continue to monitor market conditions and engage with
relevant vendors and other service providers to determine if changes to
the rule's coverage are warranted.
Section 1033.111(d)(2) states that a depository institution data
provider's total assets are calculated by averaging its assets reported
on its four preceding quarterly call report submissions to the FFIEC or
NCUA, as applicable. Averaging total assets over a year provides a more
accurate financial picture than using the total assets at one point in
time. Additionally, the SBA calculates whether a specific institution
meets its size standards by averaging the assets reported on its four
quarterly financial statements for the preceding year. See 13 CFR
121.201 n.8.
Section 1033.111(d)(3) outlines the process by which a depository
institution data provider determines total assets when there is a
merger or acquisition where the surviving depository institution does
not have four quarterly call report submissions. The surviving
depository institution shall use the combined assets reported on the
quarterly call report submissions by all predecessor depository
institutions for quarterly assets prior to the merger. For quarterly
assets after the merger or acquisition, quarterly assets shall be
determined by using the assets reported on the quarterly call report
submissions by the surviving depository institution. Total assets shall
be determined by using the average of the quarterly assets for the four
preceding quarters, whether the quarterly assets are the combined
assets of the predecessor depository institutions or from the surviving
depository institution. The rule does not include explicit instructions
on how newly formed depository institution data providers with no
predecessor depository institutions determine total assets. The
regulatory text is clear that four quarterly call report submissions
are necessary to determine total assets and thus, a newly formed
depository institution data provider with no predecessor depository
institutions will determine total assets once it has four of its
quarterly call report submissions available to make that determination.
As of the rule's effective date, depository institution data
providers must determine their total assets by averaging their assets
on the four preceding call report data submissions. If that total falls
under the coverage threshold, the institution is not then subject to
the rule's requirements, but it must continue to calculate total assets
going forward based on the formula laid out in Sec. 1033.111(d)(2) to
determine if its assets have increased enough such that it becomes
covered by the rule.\52\
---------------------------------------------------------------------------
\52\ Section 1033.121(c) describes compliance dates for
depository institution data providers that hold total assets less
than the SBA size standard as of the effective date but subsequently
cross that threshold.
---------------------------------------------------------------------------
The final rule does not allow depository institution data providers
to fall out of coverage because their asset holdings dip from above to
below the threshold. Once a depository institution data provider has
become capable of building and maintaining data access in accordance
with the rule's requirements, it will need to meet the data access
requirements of the rule; ongoing costs of compliance will be minimal,
even if their total assets held have diminished.
5. Compliance Dates (Sec. 1033.121)
Proposal
The CFPB proposed in Sec. 1033.121 to stagger data provider
compliance dates into four tiers, so as to ensure timely compliance
based on asset size or revenue, depending on the type of data provider.
A number of factors might affect how quickly a data provider could
comply with the rule, including, 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 increase cost or otherwise impact
their ability to layer on new technology. Nondepository institution
data providers do not face these same obstacles. They do not have as
many vendors and information technology systems that would need to be
connected, and implementation could generally occur in-house. Thus,
they could move faster to implement the rule's requirements. In
preamble, the CFPB noted that data providers might need to transition
third parties to developer interfaces in a staggered order; proposed
Sec. 1033.321 provided flexibility in that respect.
Subject to the limitations of proposed Sec. Sec. 1033.321 and
1033.111(d), proposed Sec. 1033.121 would have required data providers
to make data access available by four compliance dates, all tied to
publication of the final rule in the Federal Register: (1) depository
institutions with $500 billion in total assets and nondepository
institutions that generate $10 billion in revenue in the preceding
calendar year or that are projected to generate $10 billion in revenue
in the current calendar year would have been required to comply
approximately six months after Federal Register publication; (2)
depository institutions with between $50 billion and $500 billion in
total assets and nondepository institutions that generate less than $10
billion in the preceding calendar year and are projected to generate
less than $10 billion in the current calendar year would have been
required to comply approximately one year after Federal Register
publication; (3) depository institutions with between $850 million and
$50 billion in total assets would have been required to comply
approximately 2.5 years after Federal Register publication; and (4)
depository institutions with under $850 million in total assets would
have been required to comply approximately four years after Federal
Register publication.
The CFPB sought comment on a number of issues, including whether
different or additional criteria should be taken into consideration
when determining compliance dates, on the structure of each tier, and
whether nondepository institutions should be included in all tiers. The
CFPB also sought comment on whether the final rule should include
language clarifying the time allowed to fully transition third parties
to data access, so as to ensure that data providers do not impede
timely third party access to an interface while also accounting for
reasonable risk management.
[[Page 90859]]
Comments Received
Most commenters that addressed this section stated that a tiered
implementation schedule was appropriate, while a few nondepository
entity trade association, consumer advocate, and bank trade association
and bank commenters stated that such implementation would incentivize
data aggregators and third parties to prioritize and work with larger
entities and would temporarily create gaps in consumer data access
across the market. One consumer advocate commenter also stated that
tiered compliance may inadvertently disadvantage smaller institutions
because the current speed of digital transformation can benefit larger,
more resourced providers who will have a head start on developing norms
for interfaces while less resourced providers will have less of a say
in how those interfaces are developed. A nondepository entity trade
association and a research institute commenter suggested that the CFPB
should allow transition time once an API is available to move access
gradually to the API and provide for a transition period rather than
final compliance dates. Commenters did not specify how the final rule
should structure a transition period without final compliance dates. A
data aggregator and a third party nondepository entity commenter also
suggested that the final rule impose different compliance dates on
different requirements in the final rule. One data aggregator commenter
suggested specific API endpoints by which to set different deadlines
for specific separate requirements.
Most commenters who addressed this section recommended that
compliance dates account for the timeline for development of consensus
standards (with some specific suggestions regarding standard file
format and developer interface standardized format) and occur after the
CFPB's recognition of a standard-setting body, occur after the issuance
of a qualified industry standard, or some combination of the above. See
the discussion of Sec. 1033.311(b) in part IV.C.3 below regarding the
timing of the issuance of consensus standards by recognized standard
setters.
Though a consumer advocate and a couple third party nondepository
commenters saw the proposed compliance dates as appropriate, the
majority of commenters, including banks, credit unions, credit union
and bank trade associations, and nondepository entity trade
associations, on this section described them as too short. Commenters
explained that data providers would need to work with third parties,
taking care not to put existing consumer account connections at risk
when migrating and onboarding third parties to compliant data access,
and would also need to ensure compliance with other rules, including
any FCRA rules issued by the CFPB. Bank, credit union, and bank and
credit union trade association commenters also noted many other actions
data providers would have to engage in to comply, including updating
public-facing websites to meet disclosure requirements, generating and
publishing performance metrics, ensuring data are provided in a
standardized format, ensuring support for required data elements that
are not currently shared, build new functionality pertaining to
machine-readable files accessible for consumers, and managing new
access duration requirements, among other actions. Credit union trade
association commenters described the potential for a bottleneck in the
proposed third tier because it would cover over 1,000 banks and credit
unions, and requested an additional tier that would allow five years
for implementation. One bank commenter stated that banks with less than
$10 billion in total assets exclusively rely on third parties to
provide digital banking, including bill payment portals, and core
processing systems. One law firm commenter stated that nondepository
institution data providers would have the most burden in complying
because they are less likely to already have interfaces and policies in
place to timely receive and respond to requests for data. Different
commenters offered various time periods for how long compliance should
be. Suggestions ranged from allowing an additional six to 18 months for
all tiers, 24 months for the largest data providers, four to six years
for small providers, and at least 10 years for all data providers.
Some bank, bank trade association, third party nondepository
entity, and nondepository entity trade association commenters requested
compliance dates for third parties and aggregators. One stated that the
CFPB should ensure that the compliance date for the largest data
providers is feasible not only for the relevant data providers but also
for data recipients. Another stated that there should be a 12-month
compliance period for aggregators and merchants that use aggregators,
and a six-month grace period thereafter for aggregators to cure any
technical violations that do not result in direct instances of consumer
harm.
Finally, one bank trade association commenter asked for
clarification as to how ownership structure influences which tier an
entity falls into as some entities are comprised of multiple types of
companies.
Final Rule
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.121 with revisions to increase the number of compliance date
tiers, redefine the types of depository institutions included in each
tier, change the metrics used to define the types of data providers
included in each tier, extend compliance deadlines for all tiers, and
provide clarification for how depository institution data providers
determine compliance deadlines when their total assets do not meet the
threshold for coverage as of the effective date but subsequently cross
that threshold. Specifically, Sec. 1033.121(b) provides that, in the
first tier, depository institution data providers that hold at least
$250 billion in total assets and nondepository institution data
providers that generated at least $10 billion in total receipts in
either calendar year 2023 or calendar year 2024 must comply by April 1,
2026. In the second tier, depository institution data providers that
hold at least $10 billion in total assets but less than $250 billion in
total assets and nondepository institution data providers that
generated less than $10 billion in total receipts in both calendar year
2023 and calendar year 2024 must comply by April 1, 2027. In the third
tier, depository institution data providers that hold at least $3
billion in total assets but less than $10 billion in total assets must
comply by April 1, 2028. In the fourth tier, depository institution
data providers that hold at least $1.5 billion in total assets but less
than $3 billion in total assets must comply by April 1, 2029. In the
final tier, depository institution data providers that hold less than
$1.5 billion in total assets but more than $850 million in total assets
must comply by April 1, 2030.
Data providers must have established functioning developer and
consumer interfaces required under Sec. 1033.301(a) that are
technically capable of complying with the requirements in subparts B
and C of part 1033 by their compliance deadline. For example, developer
interfaces must be able to make available all covered data (as defined
in Sec. 1033.211) in a standardized format (Sec. 1033.311(b)) and be
capable of performing in a commercially reasonable manner (Sec.
1033.311(c)). Some data providers will be able to receive requests from
authorized third parties for covered data through their developer
interface by then. However, the CFPB recognizes that other data
[[Page 90860]]
providers may need to transition existing third party access
arrangements or otherwise onboard new third parties after their
compliance deadline as necessary to avoid violating other legal
obligations and to manage the technical integration process.
The CFPB recognizes that data providers may need time to onboard
third parties in a staggered manner in accordance with sound risk
management. It is permissible under the final rule to manage the
onboarding process a staged manner, to the extent permitted under Sec.
1033.321. As discussed further in part IV.C.4 below, a data provider
could rely on Sec. 1033.321 to deny a third party access to the
developer interface temporarily, consistent with policies and
procedures reasonably designed to comply with safety and soundness
standards of a prudential regulator (among other legal obligations),
and if the denial complies with Sec. 1033.321(b). Once a third party
has access to the developer interface, a data provider must respond to
requests for covered data in accordance with the rule.
It will raise significant concerns if a data provider seeks to rely
on Sec. 1033.321 to justify noncompliance with the technical
requirements of subparts B and C of the final rule, such as those
impacting functionality, commercially reasonable performance, or
security of the developer interface. Such requirements are independent
of whether a data provider can deny a third party access under Sec.
1033.321. For example, it likely would be impermissible for a data
provider to deny a third party access under Sec. 1033.321 temporarily,
in connection with onboarding, solely because the data provider's
developer interface could not scale to achieve the 99.5 percent
response rate required under Sec. 1033.311(c)(1) for periods with a
high volume of requests.
To be clear, Sec. 1033.321 does not allow data providers to delay
access during the onboarding process unreasonably. For example, a data
provider could not manage the onboarding process in an inconsistent or
discriminatory manner. Establishing policies and procedures to manage
the onboarding process as expeditiously as possible in a way that
properly accounts for relevant risk management considerations will help
ensure data providers do not unlawfully avoid their obligations to
implement CFPA section 1033. In managing the onboarding process, data
providers are also subject to the rule's anti-evasion provision in
Sec. 1033.201(a)(2) and other applicable consumer financial laws,
including the prohibition on unfair, deceptive, or abusive acts or
practices.
Section 1033.121(a) provides that a data provider's compliance date
is based upon the calculation of total assets or total receipts, as
appropriate. Section 1033.121(a)(1) also provides that, for depository
institution data providers, total assets are determined by averaging
the assets reported on its 2023 third quarter, 2023 fourth quarter,
2024 first quarter, and 2024 second quarter call report data
submissions to the FFIEC or NCUA, as applicable, or its submissions to
the appropriate oversight body to the extent it does not submit such
reports to the FFIEC or NCUA. With respect a commenter's request to
clarify how ownership structure influences which tier a depository
institution falls into for compliance purposes, the regulatory text
makes clear that a depository institution data provider looks to the
total assets it reports on its call report data submissions. Section
1033.121(a)(2) provides that, for nondepository institution data
providers, total receipts are calculated based on the SBA definition of
receipts, as codified in 13 CFR 121.104(a). Section 1033.121(c) states
compliance timelines for depository institution data providers that do
not meet the coverage threshold as of the rule's effective date, but
that subsequently cross that threshold. It provides that a depository
institution data provider has a reasonable amount of time to comply
with the rule after exceeding the size standard, and that the
reasonable amount of time shall not exceed five years. This period is
counted from the submission of a data provider's fourth call report
described in the asset size calculation in Sec. 1033.111(d)(2), the
analysis of which, under such calculation, results in an asset size
that crosses the size threshold.
The compliance periods for each tier in the final rule will ensure
that data providers of different sizes and resources will have the
appropriate amount of time to comply, in part, because the largest,
most resourced data providers will be complying first and smaller
depository institution data providers who are most likely to be relying
on core providers and other third parties will be split into
additional, smaller, more manageable tiers. The largest data providers,
many of which already have the required interfaces in development, have
until April 1, 2026, to comply, which will provide them with sufficient
time to meet the rule's requirements. Comments received from the
largest depository institution data providers, as well as data provider
trade associations and a few smaller banks and credit unions, requested
24 months for the largest depository institution data providers to
comply, but also noted that many of the largest depository institution
data providers already have interfaces that could be adapted to comply
with the final rule's requirements when issued and did not specify why
24 months would be necessary to build the developer interface required
by the rule. In addition, some commenters requesting 24 months
identified aspects of implementation related to onboarding third
parties onto a developer interface and processing requests. As
discussed above, data providers must have established functioning
interfaces by their compliance dates and are permitted to manage
granting third parties access to the developer interface, consistent
with Sec. 1033.321.
The second tier of data providers will have more than two years to
comply, which will allow them to learn from the experience coming into
compliance of the first tier of data providers; the same is true for
the third tier of data providers with more than three years for
compliance. The fourth and fifth tiers, which constitute the smallest
depository institution data providers by asset size and the entities
most likely to depend on core processors or other third parties to
assist with compliance, will be able to learn from the experiences of
the data providers that had to comply earlier and should have a
smoother transition than they might otherwise. These periods balance
the need for effective compliance with the provision of sufficient time
to ensure a smooth transition and minimize time between tier compliance
to ensure that any temporary data access gaps will be short lived. The
CFPB has revised the compliance date tiers in response to comments, to
reduce the total number of depository institutions in each tier. This
should reduce the burden on core processors and other third parties,
easing overall compliance efforts.
Consistent with the proposed rule, nondepository institution data
providers must comply with the final rule's requirements as part of the
first or second tiers. But these tiers now have more time to achieve
compliance. Further, though one law firm commenter stated that
nondepository institution data providers are most likely not to already
have interfaces and policies in place to timely receive and respond to
requests for data, this assertion does not negate the CFPB's finding,
through the SBREFA process and ongoing market monitoring, that such
data providers do not have as many vendors and information
[[Page 90861]]
technology systems that will need to be connected and that
implementation by nondepository institution data providers can occur
in-house without the need to engage core processors or other third
party vendors. These data providers also tend to have business models
that are based on the ability to adopt to technological innovations
relatively quickly. Thus, these data providers will be able to move
more quickly to implement the rule's requirements.
The final rule clarifies that, for purposes of determining an
institution's compliance date, a depository institution data provider
must look at the average total assets over a defined year of call
report data. Averaging total assets over the course of one year
provides a more accurate picture of asset holdings than just using
assets as of the end of a single calendar quarter. A nondepository
institution data provider must look at its total receipts, as
calculated based on the SBA definition of receipts in 13 CFR
121.104(a). The SBA definition of receipts is widely used in many
regulations and provides a comprehensive, consistent definition for
nondepository institution data providers to benchmark their revenue.
These provisions will ensure that all institutions are using consistent
metrics to determine compliance periods.
Section 1033.111(d) addresses asset limitations to coverage for
depository institution data providers and specifies asset calculation
methods. Section 1033.121(c) discusses compliance timing for depository
institution data providers that are at or below the asset threshold at
the effective date but later exceed the applicable threshold. This
provision allows such institutions a reasonable time to comply after
they exceed the applicable threshold, not to exceed five years. The
smallest depository institution data providers subject to the rule's
requirements as of the rule's effective date will have approximately
five years to comply, making this a logical ceiling for compliance
timing for depository institution data providers that subsequently
become subject to the rule's requirements. However, as more time passes
and more institutions implement the rule's requirements, compliance
will become less onerous, less expensive and require less time. Thus,
what constitutes a reasonable amount of time for compliance may evolve
downward with time.
The final rule does not set explicit compliance dates for third
parties because they are unnecessary. The CFPB is providing additional
time for the largest data providers to come into compliance with the
rule, which will give third parties and aggregators additional time to
prepare for implementation of the rule. In addition, transitioning the
market from screen scraping will further incentivize third parties and
aggregators to meet the requirements to request proper access under the
terms of the rule. See part IV.4 above for a discussion of whether data
providers complying with this rule are furnishers under the FCRA.
6. Definitions (Sec. 1033.131)
Card Issuer, Covered Consumer Financial Product or Service, Covered
Data, Data Provider, Financial Institution, Recognized Standard Setter,
Regulation E Account, and Regulation Z Credit Card
Consistent with the proposed rule, the coverage-related terms--card
issuer, covered consumer financial product or service, covered data,
data provider, financial institution, Regulation E account, and
Regulation Z credit card--are listed under Sec. 1033.131 with cross-
references to the full definitions in Sec. Sec. 1033.111 and 1033.211
(covered data).
The term recognized standard setter, which was finalized in the
Industry Standard-Setting Final Rule, is also listed under Sec.
1033.131 with a cross-reference to the full definition in Sec.
1033.141. As finalized in that rule, the term refers to a standard-
setting body with certain attributes listed in Sec. 1033.141(a)
(finalized as part of the Industry Standard-Setting Final Rule),
including recognition by the CFPB pursuant to certain application
procedures. The CFPB began accepting applications from standard-setting
bodies seeking recognition in the summer of 2024.
Authorized Third Party
The CFPB proposed under section 1033(a) to require data providers
to make available covered data to certain third parties ``acting on
behalf'' of a consumer. The CFPB proposed in Sec. 1033.131 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 specified what requirements a third party would
have to satisfy to become an authorized third party, and thus be
entitled to access covered data on behalf of a consumer.
Few commenters addressed the proposed definition of authorized
third party. A third party commenter stated that data aggregators
sometimes function as authorized third parties. The commenter
recommended that the rule clarify how the definition applies to a data
aggregator that follows the authorization procedures, stating that the
definitions of authorized third party and data aggregator could be
modified to note that an entity could be both. More generally, several
commenters raised concerns about the scope of third parties that should
be permitted under the rule to access covered data on behalf of
consumers. These comments are addressed in part IV.D.1 below.
For the reasons discussed herein, the CFPB is adopting the
definition of authorized third party as proposed to mean a third party
that has complied with the authorization procedures in Sec. 1033.401.
As discussed in more detail in part IV.D, the authorization procedures
are designed to ensure that third parties accessing covered data under
section 1033(a) of the CFPA pursuant to the rule's framework are
``acting on behalf'' of a consumer, and therefore consistent with the
definition of consumer in CFPA section 1002(4). This definition of an
authorized third party provides a term to designate which third parties
are entitled to access consumer information, on the consumer's behalf,
pursuant to the rule's framework.
It is not necessary for the definition of authorized third party to
specify that a data aggregator may also function as an authorized third
party in other circumstances. A third party may play different roles in
different circumstances. However, for a particular request for access
to covered data, an entity would play only one role. The definition of
authorized third party (like the definitions of data aggregator and
data provider) is designed only to identify what role an entity plays
for that particular request for access to covered data.
Consensus Standard
The CFPB proposed in Sec. 1033.131 to define the term qualified
industry standard to mean a standard issued by a standard-setting body
that is fair, open, and inclusive in accordance with Sec. 1033.141(a),
which includes CFPB recognition. In the Industry Standard-Setting Final
Rule, the CFPB addressed comments regarding the proposed qualified
industry standard definition, the attributes of a standard-setting
body, and the process for CFPB recognition. The Industry Standard-
Setting Final Rule revised the definition of qualified industry
standard in proposed Sec. 1033.131 and renamed it a ``consensus
standard.''
While the Industry Standard-Setting Final Rule adopted this term,
it did not
[[Page 90862]]
address the role consensus standards would play in this final rule. The
CFPB generally proposed that conformance to a qualified industry
standard would provide ``indicia,'' or partial evidence, of data
providers' and third parties' compliance with specified provisions.
Generally, conformance to a qualified industry standard would not be
required to comply nor would it constitute compliance with a specified
provision.\53\ No provision in the proposal would have required a data
provider or third party to comply with a qualified industry standard.
---------------------------------------------------------------------------
\53\ The one exception to that approach was with respect to the
proposed requirement that a data provider's developer interface make
covered data available in a ``standardized format'' in proposed
Sec. 1033.311(b). In that case, adherence to a qualified industry
standard would have been deemed to satisfy the requirement. The
final rule instead uses the indicia-of-compliance approach in that
context, for the reasons explained in the discussion of final Sec.
1033.311 below.
---------------------------------------------------------------------------
Many commenters addressed the role consensus standards should play
in the implementation of the final rule. Generally, commenters
supported inclusion of standards set by voluntary standard-setting
bodies, and focused on whether the standards should be indicia of
compliance or something else, such as a safe harbor. Some commenters
believed consensus standards should play no role in the final
rulemaking and should rather be wholly determined by private standard-
setting bodies.
One civil rights group commenter supported the proposal's approach
to weighing standards as indicia of compliance. Further, data provider
commenters preferred to consider compliance with consensus standards as
an indicator of compliance rather than a requirement for compliance.
Some data provider and third party commenters recommended that
consensus standards provide a legal safe harbor for compliance with
various provisions of the final rule. These commenters suggested that a
safe harbor would provide certainty and clarity to market participants
and would encourage participants to invest in the setting of and
compliance with appropriate standards. Further, commenters expressed
concern that some participants may not expend the resources to conform
to consensus standards if doing so could still result in noncompliance
with regulatory requirements. Additionally, some bank commenters
recommended that if the rule does not employ consensus standards as
safe harbors, it should instead use a ``commercially reasonable''
standard. These commenters expressed concern that the ``indicia of
compliance'' terminology could receive excessive weight by market
participants, and effectively become the implicit compliance regime of
the rule.
A variety of commenters opposed the framework for recognizing
standard-setting bodies. Some commenters stated that CFPA section 1033
does not address the CFPB's authority to recognize standard-setting
bodies as capable of issuing consensus standards for data providers and
third parties, and that the proposed standards framework could conflict
with prudential requirements imposed on data providers. One research
institute commenter opposed the consensus standards framework on the
grounds that the Federal Government should not interfere with the
internal governance of private standard-setting bodies.
Generally, the CFPB has determined that consensus standards can
usefully serve as indicia of compliance for various provisions stated
throughout the final rule. If the final rule provided safe harbors, as
some commenters suggested, recognized standard setters could play a
regulatory role, rather than a consensus standard-setting one. Such an
approach would also ignore the fact that a standard may be insufficient
in some respect (for example, for incompleteness given the rule
requirement on point) or in particular, idiosyncratic circumstances.
The indicia of compliance framework maintains part 1033 as the
applicable legal standard while giving due weight to a fair, open, and
inclusive consensus standard as evidence of compliance with the
rule.\54\ Consensus standards can assist entities in fulfilling their
legal obligations but do not relieve an entity from its duty to confirm
that it is complying with the rule.\55\ By the same token, consensus
standards are not mandates.
---------------------------------------------------------------------------
\54\ In this respect, the CFPB encourages recognized standard
setters to ensure a consensus standard complies with the final rule
and that they maintain procedures that allow regulated entities to
straightforwardly evidence their conformance to a consensus standard
at negligible cost.
\55\ The CFPB may be able to provide additional guidance about
particular consensus standards, especially if market participants
seek that in particular cases. However, that is different from
providing a safe harbor for all the consensus standards that may
have some bearing on rule compliance, as requested by some
commenters.
---------------------------------------------------------------------------
While some commenters advocated for a ``commercially reasonable''
test as a substitute for consensus standards, the CFPB believes that
looking exclusively at commercial reasonableness would ignore the
potential benefits of more specific consensus standards developed
through a fair, open, and inclusive process involving all stakeholders.
As discussed below, in the context of Sec. 1033.311(c)(1), a developer
interface must provide a response within a commercially reasonable
amount of time and indicia of such a response includes conformance to
an applicable consensus standard.
Regarding the comment opposing Federal Government involvement in
the governance of private standard-setting bodies, the CFPB notes that
it has a legitimate interest in ensuring that standard-setting bodies
follow an appropriate process when issuing standards as to which
conformance carries some indicia of compliance with a CFPB rule.
Moreover, no existing or future private entity is required to become a
CFPB-recognized standard-setting body, and a range of external
standards may continue to be of utility and value to regulated entities
even if they are not consensus standards adopted by recognized standard
setters. The CFPB is finalizing the provisions of the final rule that
cite consensus standards using its rulemaking authority under CFPA
section 1033(a) and (d) and section 1022(b)(1). These provisions carry
out the objectives of section 1033 by encouraging the development of
fair, open, and inclusive industry standards that will facilitate
implementation of the final rule.
Regarding some commenters' concern that consensus standards could
conflict with prudential requirements, CFPA section 1033(e) requires
that the CFPB consult with the prudential regulators and the FTC so
that certain objectives are met. In compliance with this provision,
prior to issuing the Industry Standard-Setting Final Rule the CFPB
consulted on several occasions with staff from the prudential
regulators and the FTC to discuss various aspects of the rule,
including criteria for and processes with respect to standard-setting
bodies. Such discussions were, in part, to achieve effective alignment
between the Industry Standard-Setting Final Rule and prudential
requirements. The CFPB has conducted further consultations after the
release of the Industry Standard-Setting Final Rule and is not aware of
conflicts with prudential requirements. In addition, because consensus
standards serve as indicia, nothing in a consensus standard could
legally override a Federal legal obligation, prudential or otherwise. A
hypothesized conflict, accordingly, could not be meaningful.
Details about the role of consensus standards with regard to
particular requirements of the final rule can be found in the
discussion below.
[[Page 90863]]
Consumer
The CFPB proposed in Sec. 1033.131 to define the term consumer for
purposes of part 1033 to mean a natural person. The proposed definition
specified that trusts established for tax or estate planning purposes
would be considered natural persons. The preamble to the proposal
explained that the proposed definition differs from the definition of
consumer in CFPA section 1002(4), which defines a consumer as ``an
individual or an agent, trustee, or representative acting on behalf of
an individual.'' The preamble explained the proposed definition was
designed to distinguish the term consumer from third parties that are
authorized to access covered data on behalf of a consumer pursuant to
the proposed procedures in subpart D.
A bank and some trade associations for banks supported the proposed
approach not to refer to ``agents'' in the definition of consumer,
because they said including agents could cause significant confusion or
complication as there are numerous parties which could act as the
consumer's agent and would have access to covered data pursuant to the
third party authorization procedures in subpart D. Some commenters,
including third parties and data aggregators, noted what they described
as potential confusion related to the proposed definition being
different from the statutory definition. Others, like data aggregators
and third parties, stated that the final rule should align the
definition of consumer to the statutory definition.
Commenters also asked for additional changes and clarifications
related to the definition of consumer. For example, a data provider and
trade associations for banks requested clarification around the
proposed rule's inclusion of trusts established for tax or estate
planning purposes as natural persons, and how a trust could authorize a
third party to access the trust's data. Trade associations for third
parties suggested the definition of consumer should be narrowed to
include only consumers with at least one current account with the data
provider. Additionally, a consumer advocate stated that the final rule
should include in the definition of consumer small businesses seeking
access to their financial data.
Finally, some banks, trade associations for data providers, third
parties, and data aggregators focused on how smaller commercial third
parties, or parties that traditionally would not require authorization
through section 1033 to access consumer data, might be impacted by the
rule (e.g., how a small broker-dealer might be treated if they are not
considered a consumer; and how custodians, guardians, and other
authorized agents may authorize third parties).
For the reasons discussed herein, the CFPB is finalizing the
definition of ``consumer'' in the rule as proposed with a modification
to specify that the term includes guardians, trustees, custodians, or
similar natural persons acting on behalf of a consumer pursuant to
State law.
The term consumer is commonly used in various consumer finance-
related contexts to refer to individuals, i.e., natural persons. See,
e.g., Regulation E, 12 CFR 1005.2(e). The final rule accounts for the
CFPA's definition, which also includes ``an agent, trustee, or
representative acting on behalf of an individual,'' by establishing
third party authorization procedures described in subpart D to ensure
all relevant parties may access covered data. Accordingly, the
substance of the rule aligns with the CFPA's definition of consumer,
and nothing in the CFPA prevents the CFPB from using different
vocabulary within such a rule.
Further, as described above, some commenters requested
clarification regarding the inclusion of trusts as natural persons for
purposes of the definition of consumer. Trusts are referred to as
natural persons in other consumer finance-related contexts. See, e.g.,
Regulation Z comment 3(a)-10 (``Credit extended for consumer purposes
to certain trusts is considered to be credit extended to a natural
person rather than credit extended to an organization.''). In the
context of CFPA section 1033, a data provider would control or possess
the covered data concerning a consumer financial product or service
that the trust obtained from the data provider. As such, trusts
established for estate or tax planning purposes are appropriately
considered consumers in the context of CFPA section 1033.
In the proposed rule, the CFPB requested comment on how individuals
who are not account owners currently use existing legal mechanisms to
directly access covered data. As described above, some commenters
sought clarification on how parties that traditionally would not
require authorization through CFPA section 1033 to access consumer data
might be impacted by the rule. For example, some commenters cited
guardians and custodians as examples of natural persons who might
manage certain accounts and therefore attempt to authorize third
parties to access covered data. After considering these comments, the
CFPB is including in the definition of consumer a statement that
consumers include guardians, trustees, custodians, or similar natural
persons acting on behalf of a consumer pursuant to State law. In these
circumstances, natural persons who manage consumer accounts through
legal instrumentation are granted authority to manage those assets.
Custodial accounts, for example, may be established by financial
institutions under the Uniform Gifts to Minors Act (see generally 8A
U.L.A. 405 (1983)) or the Uniform Transfers to Minors Act (see
generally 8A U.L.A. 153 (Supp. 1987)), and are set up and managed by an
adult for the benefit of a minor until the minor reaches the age of
majority. Guardianships, trusts, and custodian accounts function
similarly: existing legal processes, unrelated to CFPA section 1033's
data access rights, establish rights for a natural person to manage the
assets and income for another natural person. In these cases, it would
be appropriate for the natural person duly authorized to manage another
natural person's covered financial products or services to also
authorize third parties to access the covered data related to those
products or services pursuant to section 1033. Further, the State
statutory and common law protections in place that cover these persons
are sufficient such that these persons can be considered consumers when
acting in those capacities for another person, and it is not necessary
to apply the provisions of subpart D to them.
The CFPB is aware that some corporate terms and conditions contain
provisions by which consumers purportedly appear to consent, upon
acceptance, to the corporate entities' limited powers of attorney to
act as agents for the consumers. These circumstances would not position
such corporate entities as consumers under the revised definition in
final Sec. 1033.131 of the rule because they are factually and legally
different from those circumstances addressed by the final rule's
definition of consumer. The natural persons considered consumers under
the final rule have broad authority established through State law
mechanisms to stand directly in the shoes of the consumer with respect
to the covered financial product or service associated with the
consumer.
Finally, as described above, some commenters suggested the CFPB
narrow the final rule to include only consumers with at least one
current account with the data provider. The CFPB has determined that
Sec. Sec. 1033.201(a) and 1033.331 and the authorization procedures
described in Sec. 1033.401
[[Page 90864]]
sufficiently ensure that consumers who have covered data and accounts
with the data provider can authorize third parties to access covered
data, while the exceptions in CFPA section 1033(b) and Sec. 1033.221
ensure that data providers are not required to provide information that
they cannot provide in the ordinary course of business. A commenter
also suggested the final rule include small businesses in the
definition of consumer. However, CFPA section 1033 applies only to
``consumer financial products and services'' as defined in CFPA section
1002(5). Accordingly, expanding the final rule to include small
business accounts would be inconsistent with the statutory text.
However, the CFPB expects that small business account providers may
find the framework of part 1033 to be a useful model for enabling small
businesses to share data about their accounts, and therefore may choose
to use their developer interfaces to facilitate that access.
Consumer Interface
The CFPB proposed in Sec. 1033.131 to define consumer interface as
an interface through which a data provider receives requests for
covered data and makes available covered data in an electronic form
usable by consumers in response to the requests.
No commenters objected to the proposal's general approach of a
framework under which authorized third parties would not be entitled
under part 1033 to access individual consumers' covered data through
providers' functionality designed for consumers. Depository
institutions and depository institution trade associations stated,
however, that the proposed definition was insufficiently clear because
under the proposal a depository institution data provider would have
been exempt from part 1033 if it did not have a consumer interface.
They said that a data provider with relatively basic online banking
functionality for its consumer account holders would not be able to
determine with sufficient certainty whether that functionality
qualified as a ``consumer interface'' thereby subjecting the data
provider to the requirements of part 1033.
Under the final rule, the application or non-application of part
1033 to a depository institution data provider does not depend in whole
or in part on whether or not the data provider has functionality for
providing covered data to individual consumers. Instead, as discussed
elsewhere, it is determined by whether the data provider is above a
certain asset size. As a result, a data provider above that asset size
and thus subject to part 1033 does not need to determine whether the
functionality through which it makes covered data available to
individual consumers meets the definition, but instead must ensure that
it offers functionality for making covered data available that meets
the requirements of subparts B and C of part 1033.\56\ Accordingly, the
rule's label for that functionality--the ``consumer interface''
definition--does not need modification and the CFPB adopts the
definition as proposed for the reasons discussed herein.
---------------------------------------------------------------------------
\56\ If a data provider has more than one mechanism through
which it makes available covered data to consumers, each of the
mechanisms does not individually need to satisfy the requirements of
part 1033. Collectively, the mechanisms must do so.
---------------------------------------------------------------------------
Data Aggregator
The CFPB proposed in Sec. 1033.131 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. The
proposed rule noted that some third parties retain data aggregators for
assistance in obtaining access to data from data providers. Certain
provisions in proposed Sec. 1033.431 specified 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 requested 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.
Some commenters stated that the proposed definition was too broad.
A research institute commenter stated that the proposed definition
would sweep in any service provider or subcontractor that contributes
in any way to a third party being able to access consumer data from a
data provider. The commenter recommended narrowing the definition to
avoid imposing burdens on service providers that have no direct
relationship to consumers or their data. A nondepository entity
commenter stated that data aggregator is a generic term that could lead
to confusion and recommended that the rule provide more granular
definitions of the different types of services provided, with the term
data aggregator applying only to entities that aggregate all types of
financial data. A data aggregator commenter stated that the rule should
use the term data access platform instead of data aggregator because
the term data aggregator does not fully reflect the role that such
entities play and that data access platform is a market standard term.
In contrast, a bank and a bank trade association commenter stated
that the proposed definition of data aggregator was too narrow. The
bank commenter requested that the definition of data aggregator be
expanded to include data aggregators that assist non-authorized third
parties in accessing consumer data.
Several commenters recommended that the CFPB clarify the proposed
definition of data aggregator. A research institute commenter stated
that the CFPB should clarify whether a data aggregator can be an
authorized third party. Two credit union trade associations recommended
that the rule clarify what ``retained by'' means in the context of a
third party that uses a wholly owned subsidiary as a data aggregator,
and also what ``enable access to covered data'' means for a
credentialing service that facilitates a data provider's risk
management and data security review. Finally, they stated that the rule
should clarify whether ``enabling access'' requires a data aggregator
to be the party connected to a developer interface.
For the reasons discussed herein, the CFPB is finalizing the
definition of data aggregator with a minor change from the proposal.
The proposal defined data aggregator to mean an entity that is retained
by and provides services to the authorized third party to enable access
to covered data. The term ``person'' as used elsewhere in the rule and
in the CFPA includes both natural persons and entities. In most
situations, a data aggregator will be an entity rather than a natural
person. However, to account for the situation in which a data
aggregator is not an entity and for consistency with other definitions,
such as third party, the CFPB is revising the definition to change
``entity'' to ``person,'' so that data aggregator means a person that
is retained by and provides services to the authorized third party to
enable access to covered data. This definition of data aggregator
strikes an appropriate balance. It is broad enough to include persons
that provide various types of services to authorized third parties that
enable access to covered data, ensuring that the consumer protections
related to data aggregators will apply to persons involved in accessing
and collecting covered data. It is not limited to persons that are
connected to a developer
[[Page 90865]]
interface, as it also covers persons collecting, processing, or
combining covered data.
However, by limiting the scope of the definition to persons that
provide services to the authorized third party to enable access to
covered data, the definition avoids sweeping in persons that are
providing services that are only incidentally connected to data access.
Contrary to the concerns raised by one commenter, the definition does
not cover a person that contributes in any way to accessing covered
data; the person must provide services that enable access to covered
data in order to meet the definition of a data aggregator. The CFPB has
determined that it would not be appropriate to adopt more granular
definitions based on the specific services that entities provide. The
purpose of the data aggregator definition is to identify persons that,
regardless of the specific services they provide, are subject to
various consumer protections in the rule because of their involvement
with and proximity to covered data.
As noted above in connection with the discussion of the definition
of authorized third party, the CFPB recognizes that persons may play
different roles in different transactions and that an entity may be a
data aggregator in some transactions and an authorized third party in
others. The definitions of data aggregator and authorized third party
are intended to identify what role an entity is playing with respect to
a particular request for covered data and are not fixed terms.
Regarding the comment about whether a wholly owned subsidiary of a
third party could be a data aggregator, the CFPB notes that, assuming
the subsidiary is a separate person from the third party, the
subsidiary could be a data aggregator.
The CFPB declines to expand the scope of the data aggregator
definition to include data aggregators that serve non-authorized third
parties. The data aggregator definition, and the provisions related to
data aggregators in Sec. 1033.431, are designed to specify what
obligations data aggregators must satisfy when they assist authorized
third parties that access covered data on a consumer's behalf pursuant
to the rule's framework. Expanding the definition of data aggregator to
include persons that provide data aggregation services to non-
authorized third parties would go beyond the scope of the consumer-
authorized data access framework described in the rule.
The CFPB also declines to further expand upon what ``enable access
to covered data'' means in specific contexts, as requested by some
commenters. The definition is designed to capture a variety of
different arrangements and accordingly is sufficiently clear. Finally,
the CFPB declines to adopt a term other than data aggregator. Only one
commenter recommended using a different term, and data aggregator is a
widely used and understood term.
Depository Institution
The CFPB is adding a definition of depository institution to the
final rule for clarity and to facilitate compliance with the rule. The
definition of depository institution is any depository institution as
defined in the Federal Deposit Insurance Act, 12 U.S.C. 1813(c)(1), or
any credit union as defined in the NCUA's regulation at 12 CFR 700.2.
This definition provides additional clarity that all depository
institutions, not just bank entities, are included when the rule refers
to depository institutions.
Developer Interface
The CFPB proposed in Sec. 1033.131 to define developer interface
as an interface through which a data provider receives requests for
covered data and makes available covered data in an electronic form
usable by authorized third parties in response to the requests.
Commenters generally did not express concern with the proposed
definition. A few blockchain-related nondepository and individual
consumer commenters, however, stated that the CFPB should require data
providers to grant developer interface access to individual consumers
upon the consumers' submission of sufficient information to the data
providers (i.e., sufficient to enable the providers to comply with
their interface access and risk assessment obligations under part 1033
and other laws). These commenters said that such a requirement would
help empower consumers to serve as their own personal financial data
custodians if they so desire.
The final rule does not require data providers to grant developer
interface access to individual consumers (though it also does not bar
them from doing so). Such a requirement could burden data providers in
ways the CFPB has not adequately evaluated by necessitating that they
consider a high number of requests for consumer access to their
developer interfaces. In addition, consumers may obtain their financial
data--including in machine-readable form--through consumer interfaces.
For the reasons discussed herein, the CFPB is finalizing the
definition of developer interface as proposed. The definition does not
require use of any particular technology. Instead, it facilitates the
readability of part 1033 by establishing a brief label--``developer
interface''--by which other provisions in part 1033 may refer to the
functionality through which a data provider receives and responds to
requests for covered data from authorized third parties in accordance
with the requirements of the rule. The very limited comments on this
definition indicate that relevant industry participants do not object
to the utility of the term for these purposes.
Third Party
The CFPB proposed in Sec. 1033.131 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 used the term third party to
refer to entities seeking access to covered data and to other parties,
including data aggregators.
A trade association for nondepository entities stated that the
definitions of third party and data provider (addressed in Sec.
1033.111(c)) were unclear. The commenter stated that an entity could be
construed as either, such as when a fintech partners with a bank.
For the reasons discussed herein, the CFPB is finalizing the
definition of third party with a minor change from the proposal. The
proposed definition referred to ``any person or entity.'' The term
``person'' as used elsewhere in this rule and in the CFPA includes both
natural persons and entities, so the phrase ``or entity'' in the
definition of third party is unnecessary. Accordingly, the final rule
defines third party to mean any person that is not the consumer about
whom the covered data pertains or the data provider that controls or
possesses the consumer's covered data.
As discussed above in connection with the definitions of authorized
third party and data aggregator, an entity may play different roles in
different transactions and may serve as a data provider in one
transaction and a third party in another transaction. The definitions
are intended to identify what roles the parties are playing in a
particular request for access to covered data. The CFPB concludes that
additional clarifications in the definitions are not necessary.
[[Page 90866]]
B. Subpart B--Making Covered Data Available
1. Overview
Disagreements around the 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.
Subpart B of part 1033 addresses these obstacles by establishing a
framework for the general categories of data that must be made
available, including specific data fields that have been significant
sources of disagreement, and exceptions from these requirements.
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 and includes a prohibition against evasion.
2. Availability and Anti-Evasion (Sec. 1033.201)
General Obligation (Sec. 1033.201(a)(1))
Consistent with the general obligation in CFPA section 1033(a), the
CFPB proposed in Sec. 1033.201(a) to 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, in an electronic form usable by
consumers and authorized third parties. It also stated that compliance
with the requirements in Sec. Sec. 1033.301 and 1033.311 is also
required.
The CFPB received only a few comments addressing the restatement of
the statutory obligation in proposed Sec. 1033.201(a). Of those, none
objected to it and some, including consumer advocates in particular,
supported the restatement. They argued that specific regulatory
provisions could become outdated as technology evolves and that
restating data providers' general statutory obligation in part 1033
would help make clear that the general obligation to make consumers'
data available to them and to their authorized third party
representatives stands nonetheless. A few data provider commenters
requested that the rule be explicit that the ``electronic form'' of
covered data may differ as between the consumer interface and the
developer interface.\57\
---------------------------------------------------------------------------
\57\ The CFPB also received comments requesting that it
undertake a consumer education campaign to ensure that consumers are
aware of their rights under CFPA section 1033. While the CFPB
continues to consider these suggestions, they are outside the scope
of this rulemaking and the CFPB does not address them here.
---------------------------------------------------------------------------
For the reasons discussed herein, the CFPB is finalizing its
restatement of CFPA's section 1033(a) general statutory obligation as
Sec. 1033.201(a)(1). The CFPB has removed the proposed additional
sentence that referred to Sec. Sec. 1033.301 and 1033.311, as it is
unnecessary to state here that data provider obligations under Sec.
1033.201(a)(1) are in addition to the data provider obligations under
other provisions of subparts B and C. (Final Sec. 1033.201(a)(2),
regarding anti-evasion, is discussed below.)
The restatement in Sec. 1033.201(a)(1) of the general obligation
under CFPA section 1033(a) to make covered data available establishes
the core obligation of data providers in part 1033. This obligation is
in addition to the other requirements established by part 1033. As
commenters observed, technology and business practices will continue to
evolve over time. As they do, data providers' general statutory
obligation to make covered data available will remain in place,
implemented by Sec. 1033.201(a)(1), as will data providers'
obligations to comply with the other requirements of the rule set forth
in subparts B and C of part 1033. To be clear, there may be overlap as
to the substance of the requirements established by Sec.
1033.201(a)(1) and the substance of the other requirements in subparts
B and C, but that does not affect data providers' obligation to comply
with the entirety of subparts B and C including Sec. 1033.201(a)(1).
There may also be obligations under Sec. 1033.201(a)(1) that do not
overlap with other requirements in subparts B and C; this likewise does
not affect data providers' obligation to comply with Sec.
1033.201(a)(1). Similarly, there may be requirements under the other
provisions of subparts B and C that do not overlap with Sec.
1033.201(a)(1); that does not affect data providers' obligation to
comply with the other provisions of subparts B and C.
Under current industry practice, it is typical for the electronic
form of data made available through data providers' consumer interfaces
to differ from the electronic form of data made available through their
developer interfaces. Nothing in Sec. 1033.201(a)(1) or any other
provision of part 1033 requires that aspect of current industry
practice to change. Section 1033.201(a)(1) requires data providers to
make covered data available in an electronic form usable by consumers
and authorized third parties, but the electronic form usable by
consumers need not be the same as the electronic form usable by
authorized third parties.
Covered Data in Natural Language
In the proposal, the CFPB stated that statutory requirement set
forth in Sec. 1033.201(a) that a data provider make available covered
data in its control or possession obligates the data provider to make a
consumer's covered data available in Spanish or English (or any other
language) if that is the language in which the data provider maintains
the consumer's covered data. A few data provider commenters argued that
the requirement should not apply to the developer interface.
That statement from the proposal remains an accurate description of
data providers' obligations under Sec. 1033.201(a); accordingly, the
CFPB reaffirms it here. Some elements of covered data, discussed in
more detail under Sec. 1033.211, are non-numeric--that is, they
include natural language. When a data provider controls or possesses
covered data that includes natural language, the data provider must
make available the data in the language in which the data provider
controls or possesses the covered data (whether that language is
Spanish, English, or any other language). Further, this obligation
applies to both consumer and developer interfaces.
Anti-Evasion Provision (Sec. 1033.201(a)(2))
The CFPB requested comment on whether part 1033 should set forth an
explicit prohibition against data provider conduct that would evade the
objectives of CFPA section 1033, pursuant to the authority provided to
the CFPB by CFPA section 1022(b)(1). More specifically, the CFPB
requested comment on whether it should 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, or (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. The CFPB also requested comment on
whether it should prohibit practices that might effectively make data
unavailable or unusable to consumers and authorized third parties.
The CFPB received only a few comments addressing whether its final
rule should include a prohibition against evasion. Data provider
commenters that addressed the issue opposed such a prohibition on the
grounds that it would be premature because actual evasive activity
remains
[[Page 90867]]
speculative. In contrast, third party commenters that addressed the
issue supported inclusion of a prohibition against evasion. These
commenters asserted that the proposed rule did not do enough to prevent
data providers from interfering with access, such as by varying the
performance of their interfaces, by implementing systems in non-
standard ways that limit interoperability, or by imposing excessive
burdens or procedures that restrict or delay access to covered data
depending on which third party is requesting access. They also asserted
that there is a history of data provider efforts to delay or interfere
with data access by authorized third parties.
The CFPB has determined that is necessary and appropriate to
include in part 1033 a prohibition against evasion, pursuant to the
CFPB's authority under CFPA section 1022(b)(1). Accordingly, the CFPB
is adopting Sec. 1033.201(a)(2) for the reasons discussed herein,
which states that a data provider must not take any action (1) with the
intent of evading the requirements of subparts B and C of part 1033;
(2) that the data provider knows or should know is likely to render
unusable the covered data that the data provider makes available; or
(3) that the data provider knows or should know is likely to prevent,
interfere with, or materially discourage a consumer or authorized third
party from accessing covered data consistent with part 1033.
The anti-evasion provision in Sec. 1033.201(a)(2) prohibits data
provider conduct that is taken to evade the requirements of this final
rule but which the CFPB may not, or could not, have fully anticipated
in developing the rule. Part 1033 contains certain requirements that
are targeted at potential data provider evasion and which rely in part
on the CFPB's authority to prevent evasion under CFPA section
1022(b)(1). However, the CFPB cannot anticipate every possible way in
which data providers might seek to evade the requirements of part 1033.
The CFPB has determined that Sec. 1033.201(a)(2) provides flexibility
to address future data provider conduct taken to evade part 1033. The
CFPB has also determined that the evasion prohibition will enhance the
effectiveness of the final rule's specific, substantive requirements,
and thereby preserve the consumer rights provided by part 1033. In
adopting the evasion prohibition, the CFPB's judgment is informed by
concerns that commercial actors might be able to use their market power
and incumbency to privilege their concerns and interests above fair
competition that could benefit consumers.
Current Data (Sec. 1033.201(b))
Proposal
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.
However, the CFPB received questions during the SBREFA process about
whether data providers could simply provide the last monthly statement
rather than being required to make available recent transactions and
current account balance. Proposed Sec. 1033.201(b) interpreted CFPA
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. It also specified that a data provider would
need to make available information concerning authorized but not yet
settled debit card transactions. The preamble discussed how this debit
card transaction situation was an example and asked for comment on
whether the provision regarding current data would benefit from
additional examples or other clarifications.
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, the proposal explained that Sec. 1033.201(b) was not intended
to limit a consumer's right to access historical covered data. The CFPB
requested comment on whether the provision regarding current data would
benefit from additional examples or other clarifications. The CFPB also
requested 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.
Comments
Commenters did not object to a general requirement to make
available the most recently updated covered data in the data provider's
control or possession at the time of the request. One large data
aggregator stated that the proposed data requirement is sufficiently
clear, especially because it explains that pending transaction
information must be made available. Some data provider commenters
asserted that the CFPB should not require information concerning
authorized but not yet settled debit card transactions. One data
provider commenter stated that requiring pending transaction
information is like asking financial institutions to look into a
crystal ball to predict the future. The commenter asserted that some
merchants, such as gas stations and hotels, send pre-authorizations for
dollar amounts higher than the actual transaction amounts to ensure
funds are available. Data provider commenters raised similar concerns
about pending transaction information with regards to covered data
under Sec. 1033.211(a); those comments are discussed further below.
Final Rule
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.201(b) as proposed with an edit to clarify the example of
authorized but not yet settled transactions. The current data provision
in Sec. 1033.201(b) requires that, in complying with paragraph (a) of
this section, a data provider must make available the most recently
updated covered data that it has in its control or possession at the
time of a request. A data provider must make available information
concerning authorized but not yet settled transactions. The CFPB notes
that Sec. 1033.201(b) does not limit a consumer's right to access
historical covered data.
Finalizing this current data requirement helps ensure that data
providers make available the most current data in their control or
possession. Current data includes information regarding pending
transactions that have not yet settled, including but not limited to
pending debit card, credit card, and bill payment transactions. As
discussed below with regards to transaction data in Sec. 1033.211(a),
pending transaction information can be helpful for a variety of use
cases, including personal financial management. Although such
information may ultimately change, consumers and third parties may need
access to pending transaction information in order to plan for imminent
withdrawals. Such information may also be necessary for a consumer or
third party to determine whether a consumer needs to deposit additional
funds into an account or is approaching a credit limit and thus should
delay additional purchases. Data providers could limit funds or credit
availability in response to pending transactions, and a consumer may
need to know about pending transactions to understand any associated
changes in
[[Page 90868]]
available funds or credit. Given how authorized but not yet settled
transactions may encompass a variety of payment types now and in the
future, including credit card and certain bill pay transactions, and
the risk that the debit card example might be misinterpreted to narrow
the scope of this current data requirement, the final rule text removes
the term ``debit card'' to more generally explain that a data provider
must make available information concerning authorized but not yet
settled transactions.
3. Covered Data (Sec. 1033.211)
In General
Proposal
CFPA section 1033(a) generally requires data providers to make
available, 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, including
information relating to any transaction, series of transactions, or to
the account including costs, charges and usage data.'' The CFPB
proposed in Sec. 1033.211 to implement this by defining the
information that a data provider would need to make available under the
general obligation to make covered data available in proposed Sec.
1033.201(a). Proposed Sec. 1033.211 used the term covered data instead
of the statutory term ``information'' and defined covered data to
encompass 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.
The proposal explained that this covered data definition would
leverage existing operational and legal infrastructure and that
requiring data that are generally made available to consumers today
would support most beneficial consumer use cases. The CFPB noted that
certain proposed categories of data, 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 requested comment on the benefits and data needs for consumers
who are in the process of switching accounts.
The CFPB preliminarily concluded that the covered data definition
also would address several issues in the consumer-authorized data
sharing system today, including clarifying which data must be made
available under the consumer's CFPA section 1033 right. Currently, data
providers provide authorized third parties with inconsistent access to
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 must negotiate
individual categories of information to be made available.
To address concerns about data providers restricting access to
specific pieces of information, the proposed rule also gave examples of
information that would fall within the covered data categories. The
CFPB explained that these examples were illustrative and were not an
exhaustive list of data that a data provider would be required to make
available under the proposed rule. 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 requested comment on
whether additional data fields should be specified to minimize disputes
about whether the information would fall within the covered data
definition. The CFPB explained that, as proposed, the rule would allow
flexibility as industry standards develop while minimizing ambiguity
over the types of information that must be made available. The CFPB
also requested comment on whether the proposed categories of
information provide sufficient flexibility to market participants to
develop qualified industry standards.
The CFPB explained that 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.
Comments
Data providers, third parties, and other commenters generally
supported the CFPB's categories and examples approach to defining
covered data, noting that the categories-plus-examples approach allows
market flexibility. Commenters also stated that the proposed categories
of covered data would leverage existing legal and operational
infrastructure, and that these covered data are generally available on
consumer interfaces today. However, some commenters requested
additional clarity or narrowing of the covered data categories, such as
explaining that the covered data obligations only apply with regards to
the covered consumer financial product or service. A few data provider
commenters stated that the data categories should be narrowed
significantly because they asserted that covering categories like
pending transactions, terms and conditions, and upcoming bill
information would exceed the CFPB's CFPA section 1033 authority. A few
data provider commenters requested more specificity, such as defining
all required data fields.
Some third party, consumer advocate, and other commenters requested
that the CFPB expand the scope of covered data. For example, one
consumer advocate commenter stated that covered data should include
login usernames and passwords, challenge question responses, and
customer service history. As another example, a third party commenter
asked the CFPB to include a consumer identification number that could
be linked to all consumer accounts, a consumer's date of birth, the
date an account was opened, an account's transferability status, and
other account status information. A large data aggregator asked the
CFPB to specifically require data providers to provide the consumer's
periodic statements as PDF documents. One commenter asked for
clarification that, where a data provider is obligated to make
available licensed information pursuant to the rule, the data provider
does not provide a license to the authorized third party.
Final Rule
For the reasons discussed herein, the CFPB is finalizing the
proposed approach to covered data--that is, defining a list of
categories of data that data providers must make available together
with non-exhaustive examples of data fields that fall within those
[[Page 90869]]
categories. The categories and examples approach to covered data
appropriately balances resolving areas of market disagreement with
avoiding detailed specifications, such as defining all individual data
fields, that could interfere with efficiency and innovation.
The CFPB declines to expand the scope of covered data in this first
rule to implement the substantive provisions of CFPA section 1033. The
covered data definition in this final rule leverages existing
operational and legal infrastructure: data providers generally make
this covered data available through consumer interfaces, and existing
laws require most of the categories of information to be disclosed
through periodic statement and account disclosure requirements.
Requiring data that are generally made available to consumers today
supports most beneficial consumer use cases, including transaction-
based underwriting, payment credential verification, comparison
shopping, account switching, and personal financial management. This
covered data definition addresses several issues in the consumer-
authorized data sharing system today, including (1) maximizing consumer
benefits by clarifying which data must be made available under the
consumer's CFPA section 1033 right; (2) addressing potential data
provider anticompetitive conduct and incentives to withhold particular
data fields; and (3) promoting conditions for standardization in the
market. These covered data fall within the CFPB's authority under
section 1033 as they are 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. With respect to
whether the data provider necessarily provides a license to authorized
third parties to licensed information required to be made available
under the rule, the rule does not require data providers to do so.
Authorized third parties are subject to the limitations on collection,
use, and retention under Sec. 1033.421. At the same time, the rule
requires covered data to be made available upon request, subject to the
exceptions at Sec. 1033.221, including an exception for confidential
commercial information. The commenter did not specify what type of
information might be subject to a license, but it is unlikely that the
covered data defined at Sec. 1033.211 would be subject to a license;
and such information is generally made available to consumers today.
Comments received on the proposed categories and examples, and
changes made in the final rule, are discussed below.
Transaction Information (Sec. 1033.211(a))
The CFPB proposed in Sec. 1033.211(a) to make available
transaction information as covered data, providing examples of amount,
date, payment type, pending or authorized status, payee or merchant
name, rewards credits, and fees or finance charges. The CFPB explained
that this category would refer to information about individual
transactions, and discussed SBREFA feedback from bank data providers to
exclude pending transactions. The CFPB preliminarily concluded that
pending transaction information would support a variety of beneficial
use cases.
The CFPB also proposed to include historical transaction
information in the control or possession of the data provider. Proposed
Sec. 1033.211(a) explained that a data provider would be deemed to
make available sufficient historical transaction information for
purposes of Sec. 1033.201(a) if it makes available at least 24 months
of such information. The CFPB explained that historical transaction
data supports a variety of use cases, including transaction-based
underwriting, account switching, and personal financial management, but
also observed that data providers do not make a consistent amount of
historical transaction information available.
The CFPB discussed how 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 concluded 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
length of time 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 noted 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.
The CFPB requested comment on whether the transaction information
examples were sufficiently detailed and consistent with market
practices, 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 requested 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.
Comments
Commenters generally did not oppose inclusion of transaction
information within the scope of covered data, with some data provider
commenters asserting that this information is clearly required under
CFPA section 1033. A few data provider commenters asked for additional
clarification, such as whether the merchant name field refers to the
merchant shown in the transaction description in the periodic statement
or other sources like a web-based search about the merchant. Many data
provider commenters opposed covering pending transaction information
and reiterated concerns raised during the SBREFA process, including
arguments that such information is not provided on monthly account
statements, falls outside the CFPB's 1033 authority as it is not
concerning a product that the consumer ``obtained'' from the data
provider, is confusing for consumers, and could change at settlement so
introduces error risk.
Some commenters opposed the rewards credits example, stating that
this information is proprietary, difficult to disclose, subject to
misinterpretation, not disclosed today, and could erode the incentives
of data providers to invest in merchant categorization tools. A few of
these commenters asked the CFPB to limit the information to rewards
balance, which they explained is typically made available today.
Third party commenters generally supported the 24-month safe harbor
for historical transaction data, stating that 24 months would support
most use cases and is consistent with market practices today. A
consumer advocate commenter supported the consistency between this
period and Regulation Z, 12 CFR 1026.25(a) and Regulation E, 12 CFR
1005.13(b), as both require retention of records for two years to
document compliance with their requirements. One third party commenter
asked the CFPB to require seven years of historical transaction data
and a consumer advocate commenter suggested a period of three years.
Some
[[Page 90870]]
data provider commenters and SBA Advocacy recommended that the safe
harbor should be narrowed to a shorter period, such as six or 12
months. A trade association representing data providers stated that the
historical data provision would be inconsistent with section 1033(c),
which states, ``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.'' 12 U.S.C. 5533(c).
Final Rule
For the reasons discussed herein, the CFPB is finalizing the
transaction information requirement as proposed, including the
requirement to provide historical transaction information and the 24-
month safe harbor, with a minor edit to clarify that the example is
referring to transaction date. The CFPB has determined that this
pending transaction information is beneficial to consumers given how it
supports use cases like personal financial management and fraud
prevention, and is generally made available to consumers and third
parties today. The CFPB has determined that a 24-month safe harbor
period will support most use cases, will encourage more consistent data
access across institutions, is consistent with market practices today,
aligns with existing record retention requirements in Regulation E and
Regulation Z, and appropriately balances providing compliance certainty
and encouraging standard market practices with allowing flexibility in
case there are data providers who do not control or possess 24 months
of historical transaction information notwithstanding their other
regulatory obligations. A shorter safe harbor, such as 6 months, would
not sufficiently support common use cases like personal financial
management and loan underwriting, which typically require more
historical transaction information and may be particularly reliant on
more data when a consumer's income has seasonal variations. Given that
data providers can determine how much historical transaction
information to make available according to how much is in the data
provider's control or possession rather than by taking advantage of
this safe harbor, this provision is consistent with CFPA section
1033(c), which states that nothing in this section shall be construed
to impose any duty on a covered person to maintain or keep any
information about a consumer. However, the CFPB expects that data
providers generally will have at least 24-months of historical
transaction information in their control or possession given the
existing Regulation E and Z record retention requirements.
Account Balance (Sec. 1033.211(b))
The CFPB proposed in Sec. 1033.211(b) to require data providers to
make available account balance. The CFPB explained that in preamble
that this category would include available funds in an asset account
and any credit card balance. The CFPB requested 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.
A few data provider and third party commenters asked for specific
clarifications related to account balance, such as stating that account
balance means ``current balance and statement balance,'' balance for
credit cards means ``total balance owed,'' and that the CFPB should
require currency information. One data provider commenter requested
that the CFPB require detailed account balance specifications based on
payment type given differences in how various payment networks
determine the available balance, ledger balance, and settlement.
For the reasons discussed herein, the CFPB is finalizing the
requirement to provide account balance information as covered data. The
CFPB has determined that account balance is not a commonly disputed
category and that the market will benefit from flexibility in
determining how to break down various account balances that apply to an
account. However, the CFPB recognizes that a variety of account
balances can apply to a product and use case--such as cash advance
balance, statement balance, and current balance--and will monitor the
market to ensure that data providers are making available this
information in a manner usable by consumers and third parties.
Information To Initiate Payment to or From a Regulation E Account
(Sec. 1033.211(c))
In Sec. 1033.211(c), the CFPB proposed to require a data provider
to make available information to initiate a payment to or from the
consumer's Regulation E account. An example would have explained that
this category includes a tokenized account and routing number that can
be used to initiate an ACH transaction. It also explained that 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.
The CFPB discussed how 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, private
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. The CFPB discussed how 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 asserted 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 concluded 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 noted 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 requested 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
requested comment on whether data providers should also be required to
make available information to initiate payments from a Regulation Z
credit card.
Comments
Some data providers and trade associations opposed the proposed
requirement to make available information to initiate payment to or
from a Regulation E account, stating that sharing such information
would
[[Page 90871]]
introduce liability risks to data providers and consumers and asserting
that payment initiation falls outside the CFPB's authority under CFPA
section 1033. In contrast, a few other commenters stated that requiring
account number would be appropriate and that they generally make this
information available to consumers and third parties today. Some data
provider commenters expressed their opposition to the growing usage of
``pay-by-bank,'' a phrase sometimes used to describe consumer-to-
merchant payment alternatives to the debit and credit card networks.
These commenters asserted that the ACH network is not appropriate for
third party payments and therefore the CFPB should not require data
providers to make available ACH payment initiation information. One
trade association representing bank data providers asked the CFPB to
clarify that this category does not include the ability to of a third
party to initiate credit-push payments from a consumer's account.
A few data provider commenters asked the CFPB to clarify the scope
of the required information and whether account and routing number
would satisfy the obligation. Data provider commenters also raised
ambiguity and overbreadth concerns, asserting that this provision could
be read to require wire transfer information and other payment
information within the data provider's control or possession. Several
data provider commenters opposed adding a requirement to make available
information to initiate payment from a credit card account, asserting
that requiring credit card number would introduce significant risks to
consumers and data providers and that the CFPB had not sufficiently
considered the risks of requiring such data. Some third party and data
provider commenters stated that some account information is necessary
to allow consumers and third parties to differentiate accounts,
including situations where a consumer needs to identify which account
they are permissioning access to, or when a third party is verifying a
consumer's assets for loan underwriting.
Many third party commenters supported including information to
initiate payment, with some asking the CFPB to clarify that it includes
other payment types beyond ACH. For example, one data provider
commenter that is also a third party asserted that the category should
be expanded to include all means to initiate payments, including debit
card information and FedNow information.
The CFPB received mixed comments on the allowance for TANs.
Although some data providers focused their comments on concerns related
to providing payment initiation information generally, others noted the
potential security benefits of TANs and supported the proposed
approach. Commenters supporting use of TANs stated that they enable
data providers to identify the point of compromise in case of a breach;
enable consumers and data providers to revoke compromised payment
credentials on a targeted basis; enable data providers and consumers to
limit risks of bank account fraud, as they can be restricted to a
particular third party; and offer simple implementation and reliable
technology given that they exist in the market today and can be easily
adopted. One commenter stated that TANs would allow a data provider to
create a token for a specific third party, so that any transactions on
that token can be attributed to the third party. Commenters also stated
that consumers can more easily revoke TANs when a payee is misusing the
token or the consumer otherwise wants to revoke authorization, rather
than needing to completely close an account and disrupt other account
payment activity. Tokens also enable data providers to better identify
the source of a cybersecurity incident or fraud, and would allow data
providers to quickly stop fraud on a compromised token by restricting
the ability to transact with that token. One large data aggregator
stated that allowing TANs in lieu of non-tokenized account numbers
could encourage further development of pay-by-bank functionality. This
commenter also requested several significant modifications to the TAN
option, such as allowing the third party to obtain the non-tokenized
account and routing number if a TAN does not meet the third party's
particular use case, and requiring data providers who share a TAN to
also make available a unique user identifier. A payment network
governance organization supporting TANs stated that industry does not
tokenize routing numbers.
Some third parties opposed allowing data providers to make
available TANs in lieu of non-tokenized account and routing numbers as
proposed. These commenters asked the CFPB to remove the allowance for
TANs and only allow non-tokenized account and routing numbers,
asserting that the ability to revoke TANs introduces risks of fraud
perpetrated by consumers, TAN payments are more likely to fail, there
is potential for data providers to issue TANs in an anticompetitive
manner, TANs should be addressed in a separate rulemaking, and TANs do
not support some consumer and third party use cases like generating
paper checks, assessing the likelihood of payment failure, and
interfering with fraud controls that track a particular account's
payment activity. A few third parties also asserted that there is no
market-wide standard for TANs and that TANs are not interoperable among
the payment networks used today, including FedNow, Real-Time Payments
(RTP), and ACH. These commenters differed on whether it would be
appropriate to defer to a standard-setting body to determine the
specifications for TANs. Some shared concerns that if the CFPB
finalized the TAN option, the rule should adopt specific TAN revocation
and expiration provisions. One trade association commenter and a third
party commenter stated that non-tokenized account and routing number
information is not that sensitive because it is printed on paper checks
and already needs to be encrypted according to private network rules. A
third party commenter asserted that industry-wide controls serve as
better protective tools than optional use of TANs, as the ACH network
already monitors for high returns rates in order to identify fraudsters
running unauthorized debits against stolen ACH numbers, banks who
sponsor third party senders into the ACH system are required to perform
due diligence on those senders, consumers have rights under Regulation
E to have their bank reverse an unauthorized payment, and banks
regularly honor consumer claims of unauthorized account activity even
if there is no evidence that the account activity was unauthorized.
Final Rule
For the reasons discussed herein, the CFPB is finalizing the Sec.
1033.211(c) category of information to initiate payment to or from a
Regulation E account, including language allowing data providers to
make available TANs in lieu of non-tokenized account numbers, with some
clarifications.
The CFPB has determined that information to initiate payment to or
from a Regulation E account supports many essential consumer use cases
such as account switching and making payments. The CFPB understands
that consumers use account and routing numbers today to support use
cases like signing up for direct deposit, making bill payments, and
designating an account to accept loan proceeds. Consumers can provide
this information directly to third parties, but making it available
through a data provider has a variety of benefits, including accuracy
[[Page 90872]]
of the number sequence, ensuring that a correct and valid account is
being accessed, and reduced friction in how quickly and easily that
information shared. This information falls within the CFPB's authority
under section 1033 as it is 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. As discussed above
in part IV.3, the rule does not require account write access or
otherwise require payment initiation. Part IV.3 includes additional
discussion of comments related to concerns about liability.
Some data provider and trade association commenters asked the CFPB
to clarify that pre-existing payment authorization requirements
continue to apply. The CFPB agrees with commenters that regardless of
whether a third party obtains information to initiate payment from a
consumer or from an authorized third party, that third party would need
to obtain appropriate payment authorization from the consumer. If the
third party is not a depository institution, it would need to go
through an originating depository institution to access the ACH payment
network, and that originating depository institution continues to have
due diligence, Know-Your-Customer, and private network obligations in
terms of warranting that the third party's payment order is valid. The
consumer's receiving depository financial institution and any other
financial institutions in the transaction would also have Regulation E
obligations, including error resolution obligations for any
unauthorized payments. However, according to private network rules, the
receiving depository financial institution can seek remediation for
errors from the originating depository financial institution and third
party that facilitate the erroneous payment.
Given the benefits of making this information available, how it is
required to be disclosed under Regulation E periodic statement
requirements, how it is generally made available to consumers and third
parties today, applicable Regulation E error protections for consumers
in the event the information is misused, existing private network and
safety and soundness obligations of originating depository institutions
that facilitate a third party's payment, and the ability of the
depository data providers to seek redress from originating depository
institutions for erroneous payments, the CFPB has determined that data
providers must make available information to initiate payment to or
from a Regulation E account held by the data provider.
Instead of using the term ``account and routing number'' to define
this covered data category, the CFPB is finalizing the broader proposed
``information to initiate payment'' language for two forward-looking
reasons. First, the payments market may start to shift away from
account and routing number as security and data practices evolve, and
this broader language provides the market with flexibility to share
data in accordance with those shifts. Second, since third parties
typically use account and routing number to complete ACH payments
today, using the ``account and routing number'' term may be
misinterpreted to limit the types of payments that the information can
be used to initiate. As the payment market evolves and more broadly
adopts alternatives to the ACH network, such as RTP and FedNow, data
providers may control or possess other payment initiation information
that can be retrieved in the ordinary course of business--and
accordingly such information would need to be made available. This
information could include information sufficient to submit a request
for payment. However, this provision is limited to information sharing
and accordingly does not include the ability of a third party to access
and push payment out of a consumer's account, also referred to as
``write'' access.
To clarify the scope of this information and address commenters'
concerns about ambiguity, the CFPB is finalizing a clarification that
this category is limited to information to initiate payment to or from
a Regulation E account held directly or indirectly by the data
provider. The final rule also explains that the requirement to make
available this information does not apply to data providers who do not
directly or indirectly hold the underlying Regulation E account. For
example, a data provider that merely facilitates pass-through payments
to third parties would not be required to make available account and
routing number for the underlying Regulation E account.
The CFPB notes that CFPA section 1033(b)(4) and the final rule at
Sec. Sec. 1033.211(c) and 1033.221(d) only require data providers to
share payment initiation information that they can retrieve in the
ordinary course of business. In the current market, account number is
clearly retrievable in the ordinary course of business given that it is
typically shared through consumer and developer interfaces today and is
required to be disclosed on the Regulation E periodic statement. The
CFPB is not requiring payment initiation information that is not
retrievable in the ordinary course of business. For purposes of this
rule, the CFPB is making the determination that debit card numbers are
data that are not retrievable in the ordinary course because of a
unique historically-driven combination of factors that together suffice
to put this data outside the scope of the rule, including the physical
way--plastic cards--in which providers have typically chosen to make
debit card credentials available to consumers, and the specific nature
of how longstanding private payment network rules govern which entities
can issue and control debit card payment credentials. As noted above,
as the payment market adopts alternatives to the ACH network, such as
RTP and FedNow, data providers may control or possess other payment
initiation information that data providers can retrieve in the ordinary
course of business--and accordingly such information would need to be
made available.
This provision does not impact other requirements for initiating
payment or accessing the payment networks. Section 1033.211(c) requires
that data providers make available information to initiate payment to
or from a Regulation E account; payment authorization requirements
continue to separately apply. The CFPB confirms that, in order to
initiate payment, third parties would need proper payment authorization
from the consumer subject to, without limitation, Regulation E
preauthorized electronic fund transfer provisions and private network
rule authorization requirements. The CFPB notes that, in order to
access the payment network and initiate an ACH or similar payment, a
third party would need an originating depository financial institution
relationship. With regards to payment initiation, this provision does
not alter due diligence and network requirements that apply to
originating depository financial institutions providing access to the
ACH payment network.
The CFPB is also finalizing, with modifications, the proposed
example that would allow data providers to share a tokenized account
number instead of, or in addition to, a non-tokenized account number.
This clarification is now moved into the rule text paragraph and no
longer is labeled as an example. To address commenters' concerns about
anticompetitive issuance of TANs, the rule text also now states that
such tokenization is appropriate so long as it is not used as a pretext
to restrict
[[Page 90873]]
competitive use of payment initiation information; the reference to
``routing number'' has been removed in light of comments that routing
number is not typically tokenized. TANs, used appropriately, can meet
consumer use cases for electronic payments. The CFPB notes that use of
TANs in conformance with applicable consensus standards can serve to
indicate appropriate use. In addition, data providers have legitimate
reasons to use TANs because they can protect the security of the
relevant payment system and thus benefit its participants, including
the consumer. In particular, TANs lower the risk of unauthorized
transactions by limiting the potential for payment credentials to be
misused for purposes the consumer did not intend or authorize, by
helping to identify the source of a data breach, and by causing less
disruption to consumers and the payment system when a credential is
appropriately replaced. These benefits apply even though non-tokenized
account numbers appear on paper checks and may need to be stored in an
encrypted form according to private network rules. The CFPB notes that
a data provider's provision of a TAN in lieu of non-tokenized account
number is optional and that sometimes consumers share non-tokenized
account and routing numbers directly with third parties.
With regard to concerns from some third party commenters that TANs
can interfere with fraud controls that track an account's payment
history, third parties can use the account identifier described under
Sec. 1033.211(f) to distinguish consumer accounts. However, the CFPB
cautions that Sec. 1033.421(a) limits authorized third party use of
covered data, including TANs, to what is reasonably necessary to
provide the consumer's requested product or service. The general
limitation standard, including uses that are reasonably necessary to
protect against actual or potential fraud, is discussed below regarding
Sec. 1033.421(a) and (c). TANs do allow consumers to more easily
revoke their payment authorizations, but ease of revocation is a
consumer benefit of TANs as it allows consumers to exercise more
precise and immediate control over their account in the event that they
have concerns about a payee. The interaction between TANs and
revocation is discussed further in Sec. 1033.331(e). In response to a
third party commenter's statement that industry controls are more
effective than TANs, the CFPB notes that unauthorized payment fraud
exists in the market today and the CFPB has taken public action against
financial institutions that do not comply with their error resolution
requirements.
This final rule does not require data providers to grant access to,
or facilitate payments on, any particular payment network. Accordingly,
the CFPB does not require that TANs be interoperable across multiple
payment networks. However, to the extent that data providers
pretextually use TANs to frustrate consumers' ability to provide
functioning payment initiation information to authorized third parties
of their choice, such pretextual use would violate the anti-evasion
provision at Sec. 1033.201(a)(2). The CFPB intends to monitor the
market for any such pretextual use of the allowance for TANs, and will
issue future guidance about the use of TANs in lieu of a full account
number if needed.
Terms and Conditions (Sec. 1033.211(d))
The CFPB proposed to require terms and conditions be made available
as covered data in Sec. 1033.211(d). The CFPB explained that 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 included several non-exhaustive examples of information
that would constitute terms and conditions.
The CFPB discussed how 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
proposed to include APR, APY, fees, and other pricing information in
this category. The CFPB also discussed how this provision would benefit
consumers because they may not be able to easily find this information
through a consumer interface today, and some data providers may not be
consistently sharing it with third parties. The CFPB requested comment
on whether the final rule should include more examples of information
that must be made available under terms and conditions.
Comments
Data provider commenters generally did not dispute including APR
and APY as examples of covered data, although a few opposed sharing
that information. Some bank data provider and related trade association
commenters opposed including information other than realized fees, such
as applicable fee schedule. Some data provider commenters opposed
including other examples in the final rule, such as rewards program
terms, overdraft opt-in status, and whether an account was subject to
an arbitration agreement, arguing that such information falls within
the exceptions in Sec. 1033.221 or otherwise falls outside the CFPB's
1033 authority as it is not related to the covered consumer financial
product or service and is not cost, charges, or usage data. One credit
union trade association stated that arbitration information will make
consumers targets for predatory attorneys and contradicts statements in
a separate CFPB rulemaking regarding covered form contracts used by
nonbanks.
Many data provider commenters raised technical and burden concerns
about this category, stating that terms and conditions are not well
suited to developer interfaces, as some terms cannot be reduced to
numerical or binary data fields. Other stated concerns included: (1)
lack of clarity over whether the rule is requiring a PDF of an entire
terms and conditions document; (2) the number of terms and conditions
documents applicable to an account, and whether all of them must be
made available; (3) full terms and conditions documents are not useful
or desirable for third parties to receive; (4) sharing full terms and
conditions documents entails sharing of extraneous information; and (5)
sharing current terms and conditions documents is overly burdensome and
infeasible. A data aggregator commenter asserted that full terms and
conditions contain some substantial legal terms that are neither
supportive of any existing use cases nor easily transformed into a
machine-readable format. This commenter requested that the CFPB
identify the data elements that may be maintained in the terms and
conditions and require that those elements--rather than the full terms
and conditions--be made available in a machine-readable format.
One bank trade association commenter asked the CFPB to allow data
providers to share a PDF of the complete terms and conditions rather
than through data fields, and another suggested allowing data providers
to post terms on their website rather than making them available
through the developer portal. A large data aggregator commenter
explained that some third party interfaces allow PDF documents to be
shared today.
[[Page 90874]]
Final Rule
For the reasons discussed herein, the CFPB is finalizing the
requirement to make available terms and conditions as covered data,
with some additional limitations. The CFPB is aware that a variety of
terms and conditions may impact a covered consumer financial product or
service and some of those terms may not support current consumer use
cases. The CFPB agrees with commenters that terms and conditions can be
defined to provide compliance clarity to data providers and limit the
extent of information they need to make available, while supporting
current and potential use cases. Accordingly, the CFPB is finalizing a
definition of the terms and conditions category limited to data in
agreements evidencing the terms of the legal obligation between a data
provider and a consumer for a covered consumer financial product or
service, such as data in the account opening agreement and any
amendments or additions to that agreement, including pricing
information.
The CFPB has determined that the proposed non-exhaustive examples
of terms and conditions are helpful to clarify the terms and conditions
category and minimize market disagreements about whether certain pieces
of information must be made available. The applicable fee schedule is
important information for comparison shopping and personal financial
management as consumers need to anticipate what fees can be charged in
order to evaluate a product's true cost and plan spending. Rewards
programs are an important factor to a consumer's decision to obtain and
use a consumer financial product or service, and the CFPB has
determined that it is appropriate to require that these rewards program
terms be made available under Sec. 1033.201(a)(1). Similarly, whether
a consumer has opted into overdraft coverage or is subject to an
arbitration agreement is relevant to how a consumer may decide to use
or comparison shop for a product or service, including determining
applicable fees and their rights with respect to that product or
service. All of these non-exhaustive examples reflect the terms and
conditions of the legal obligation between a data provider and a
consumer for a covered consumer financial product or service. In
response to a comment that arbitration information will be used to
target consumers or otherwise relates to other CFPB policies related to
form contracts, this information is not being collected by the CFPB and
will not be shared unless the consumer chooses to do so.
The CFPB has added credit limit to the list of non-exhaustive
examples of terms and conditions. Credit limit is a key term that is
typically determined and disclosed when a consumer obtains a Regulation
Z credit card, and account agreements generally permit the provider to
make changes to the credit limit. Although the CFPB asked for comment
on credit availability with regard to account balance in Sec.
1033.211(b), the CFPB has determined that it would be clearer to
include credit limit as an example under this terms and conditions
category. The CFPB is finalizing example 2 to Sec. 1033.211(d) to
state that this category includes the applicable fee schedule, any APR
or APY, credit limit, rewards program terms, whether a consumer has
opted into overdraft coverage, and whether a consumer has entered into
an arbitration agreement.
In the current market, certain terms and conditions are commonly
requested and made available as discrete data fields in developer
interfaces. For example, discrete data fields for applicable APRs and
APYs are typically shared in third party interfaces to support
comparison shopping and personal account management. The CFPB expects
that such commonly requested terms and conditions will continue to be
made available as discrete callable data fields, as Sec. 1033.311
requires developer interfaces to make data available in a standardized
and machine-readable format that is widely used by other data providers
and designed to be readily usable by authorized third parties.
As use cases develop, third parties may seek access to terms and
conditions that are not commonly used today. For example, a third party
may need a specific term from the account opening agreement to provide
a product or service requested by the consumer. If that term falls
within terms and conditions as defined in Sec. 1033.211(d), the term
is covered data and the provider's developer interface must make that
data available. However, the data provider's developer interface would
not necessarily need to make that specific term available as a discrete
``callable'' data field. Instead, it could make it available within a
broader section of the agreement or by making available the full
account opening agreement, subject to the standardized and machine-
readable format requirements in Sec. 1033.311(b). As discussed in
Sec. 1033.421(b), the general limitation on use and retention of
covered data in Sec. 1033.421(a) would apply to that data. The CFPB
concludes that given how some account agreement terms are not
translatable to discrete numerical or binary data fields, it is
appropriate for data providers to have flexibility in how they share
terms and conditions information through the developer interface in a
machine-readable format. (See part IV.C.2 for a discussion of the
machine-readability requirement applicable to the developer interface.)
Some data providers already appear to be sharing longer documents, such
as statements, through developer interfaces today.\58\ The CFPB also
concludes that because (1) most account agreement terms are publicly
available, broadly applicable and not specific to a particular
consumer, and (2) third parties are restricted in terms of what
information they can use and retain under Sec. 1033.421(a), the
privacy concerns are limited in this particular situation.
---------------------------------------------------------------------------
\58\ See, e.g., Plaid, Statements, https://plaid.com/docs/statements/ (last visited Oct. 16, 2024).
---------------------------------------------------------------------------
Upcoming Bill Information (Sec. 1033.211(e))
The CFPB proposed in Sec. 1033.211(e) to require upcoming bill
information to be made available as covered data. An example explained
that upcoming bill information would include information about third
party bill payments scheduled through the data provider and any
upcoming 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 concluded that this information would be necessary to
support personal financial management and consumers who are switching
accounts. The CFPB requested comment on whether this category was
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.
Comments
Some data provider commenters stated that upcoming bill information
should not be included or should be significantly narrowed. These
commenters asserted that this information is outside the CFPB's section
1033 statutory authority, is burdensome to collect and share, is
unrelated to the covered consumer financial product or service, is
sensitive
[[Page 90875]]
because it contains payee data, is subject to change, and would not
support account switching. A few data providers stated that it is
unclear whether this information also includes payments scheduled
through a third party, rather than being limited to bill payments
scheduled through the data provider's platform. One data provider
commenter stated that this information should be excluded as
confidential commercial information because contracts with billers and
bill service provider prohibit its disclosure. One commenter stated
that this information should be limited to bills related to financial
products, like mortgage bills.
Final Rule
For the reasons discussed herein, the CFPB is finalizing this
provision as proposed, including the example discussing information
about third party bill payments scheduled through the data provider and
any upcoming payments due from the consumer to the data provider.
Upcoming bill information will support several important consumer use
cases, including personal financial management and account switching.
In response to comments regarding whether payments scheduled through a
third party are also meant to be covered, the CFPB confirms that data
providers are not required to make available information that is not in
the control or possession of the data provider, and upcoming bill
payments scheduled outside of the data provider's bill payment platform
may not be in their control or possession and thus are not considered
covered data. For example, when a consumer uses a cell phone company's
website to schedule a bill payment from their bank account, the
consumer's bank may not control or possess that information unless the
cell phone company is sharing that preauthorization information with
the bank. In contrast, a bank does control or possess information about
a cell phone payment a consumer scheduled through the bank's consumer
interface, and so is required to make available that bill payment
information under Sec. 1033.201(a)(1). Contrary to commenters'
assertions about the scope of the data access right, information about
scheduled bill payments is squarely within the scope of CFPA section
1033(a); specifically, upcoming bill payments relate directly to a
``series of transactions''--i.e., the consumer's pattern of paying
bills through the data provider. As discussed in the context of the
general limitation standard in subpart D, third parties will be limited
to collecting, using, and retaining covered data only to the extent it
is reasonably necessary to provide the consumer's requested product or
service, and therefore sharing of covered data will be limited to what
is reasonably necessary. The CFPB notes that the general exceptions
under CFPA section 1033(b) continue to apply, subject to the anti-
evasion provision in Sec. 1033.201(a)(2).
Basic Account Verification Information (Sec. 1033.211(f))
The CFPB proposed in Sec. 1033.211(f) to require basic account
verification information be made available as covered data, which would
be limited to the name, address, email address, and phone number
associated with the covered consumer financial product or service.
The CFPB discussed how certain pieces of identifying consumer
information are commonly shared with third parties today to support
several beneficial use cases. For example, a lender may seek to verify
that loan disbursements will be 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 during the SBREFA process that data providers sometimes limit
access to this information, and requested that the CFPB require that
account verification information be shared.
The CFPB preliminarily concluded 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
underwriter 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 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 part of basic
account verification information, as SSNs are shared for some
beneficial consumer use cases, like mortgage underwriting. However, the
sharing of SSNs is not ubiquitous. The CFPB preliminarily concluded
that SSNs may continue to be shared as appropriate but, given the risks
to consumers, the proposed rule did not require data providers to make
them available.
The CFPB requested comment on whether the proposed basic account
verification information category would accommodate or unduly interfere
with beneficial consumer use cases. Given privacy and security concerns
about unintentionally covering other kinds of information that are not
typically shared today, the CFPB also requested comment on whether it
is appropriate to limit this category to only a few specific pieces of
information.
Comments
Both consumer advocate and bank data providers generally supported
the CFPB's approach to allowing some basic account verification
information but limiting the category to specified data fields. These
commenters agreed that this approach would appropriately balance
supporting common beneficial use cases with limiting consumer privacy
risks and data provider implementation costs. Many of these commenters
also specifically requested that the CFPB not expand the category to
include SSN or other personally identifiable information. A trade
association representing data providers asked that the CFPB not expand
this category to any information a data provider uses to securely
authenticate the identity of its customer as part of a payment
initiation process, such as a one-time verification code, as such
information would pose significant risks to the integrity of various
payment security standards and would conflict with the FFIEC's guidance
on Authentication and Access to Financial Institution Services and
Systems. Some data provider commenters opposed sharing any basic
account verification information, asserting that such information
presents fraud risks, has no benefit, and can be obtained directly from
consumers. A trade association representing large depository data
providers stated that additional account information could help
consumers identify which account data they would
[[Page 90876]]
like to share. This commenter asserted that the CFPB could add ``number
of the account'' to this category, with an allowance for use of tokens
or truncated account numbers, and that it is common practice today for
truncated account numbers to be used for this purpose. A third party
commenter stated that account identification is necessary for
underwriting so that a third party knows whether a consumer's assets
have already been accounted for. Another third party commenter asked
the CFPB to include a consumer identification number that could be
linked to all consumer accounts, a consumer's date of birth, the date
an account was opened, an account's transferability status, and other
account status information.
Final Rule
For the reasons discussed herein, the CFPB is finalizing basic
account verification information as proposed, with the addition of
certain account-identifier information for situations where a data
provider directly or indirectly holds a Regulation E or Regulation Z
account.
The CFPB has determined that this approach sufficiently enables
beneficial consumer use cases in the market today and avoids
introducing risks from adding account verification information that is
not commonly made available. The information specified in Sec.
1033.211(f) supports a variety of use cases and thus is appropriate to
require, including ensuring that loan proceeds are being deposited into
an account belonging to the consumer, confirming that the consumer
applying for credit does hold the asset accounts being used for
underwriting, and reducing friction during account opening. In order to
verify an account, third parties often need to match the information
provided by the consumer with the identification information held by
the data provider. Consumers and third parties may need to identify an
account in order to permission access and differentiate a consumer's
assets.
In response to comments about the need to differentiate accounts,
the CFPB is adding language to require that if a data provider directly
or indirectly holds a Regulation E or Regulation Z account belonging to
the consumer, the data provider must also make available a truncated
account number or other identifier for that account. Given the more
sensitive nature of other personally identifiable information requested
by some commenters, such as SSN, at this time the CFPB is limiting this
category to name, address, email address, and phone number associated
with the covered consumer financial product or service, and, as
applicable, account identifier. Data providers are permitted to provide
additional information as appropriate and the CFPB will monitor whether
to expand the scope of required information as account verification
practices evolve.
4. Exceptions (Sec. 1033.221)
Proposal
The CFPB proposed, in Sec. 1033.221, four exceptions to the
requirement that data providers make data available under the proposed
rule, along with some clarifications of data that do not fall within
these exceptions. The exceptions would implement section 1033(b) of the
CFPA by restating the statutory language and providing certain
interpretations. The first exception was for any confidential
commercial information, including an algorithm used to derive credit
scores or other risk scores or predictors. Some data providers have
asserted that certain account information falls within this statutory
exception because such information is an input or output to a
proprietary model. The CFPB proposed to clarify that such 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 was for 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. During the SBREFA process, a third party stated that
at least one data provider has cited this exception when declining to
provide general account information, such as the name on the account.
To avoid misuse of this exception where information has multiple
applications, the CFPB proposed 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.
The third exception was for information required to be kept
confidential by any other provision of law. Information would not
qualify for this exception merely because the data provider must
protect it for the benefit of the consumer. The proposed example to
this exception stated that the data provider cannot restrict access to
the consumer's own information merely because that information is
subject to privacy protections.
The final exception was for any information that a data provider
cannot retrieve in the ordinary course of its business with respect to
that information.
The CFPB explained that the definition of covered data in Sec.
1033.211 would generally include information made available to
consumers and authorized third parties today or that is required to be
disclosed under other laws. The CFPB noted that the exceptions proposed
in Sec. 1033.221 were narrow, and the information specified as covered
data would not typically qualify for any of these exceptions.
The CFPB requested 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 pretextual basis.
Comments
Comments on the exceptions took a variety of positions. With
respect to the CFPB's implementation of the statutory exceptions
overall, some data provider and related trade association commenters
asked the CFPB to add more examples of excepted information and expand
the exception provisions. These commenters stated that the statutory
exceptions should be interpreted broadly to allow data providers
discretion in denying access to covered data. One commenter stated that
it is premature to have concerns about data provider abuse of the
exceptions. A bank trade association commenter asked the CFPB to except
any data that is not available in the consumer interface, explaining
that such data pose an undue burden on financial institutions and
introduce data security risks and operational challenges. In contrast,
many third party commenters asserted that the CFPB should interpret the
exceptions narrowly as they are vulnerable to pretextual use by data
providers. One large bank trade association commenter asked the CFPB to
finalize the exceptions as exemptions to make clear that data described
under the statutory exceptions are not covered by the rule.
On the first proposed exception for confidential commercial
information, many data provider commenters asserted that rewards
programs terms and credits are proprietary and should fall under this
exception, and that the rule should prohibit reverse engineering. A
large data aggregator also
[[Page 90877]]
requested that the rule prohibit reverse engineering of confidential
commercial information, suggesting that such a prohibition could be
incorporated into the data privacy protections. A trade association
representing data providers asked that the CFPB distinguish between
data that might be useful for a consumer for consumer purposes versus
data that would be of primarily commercial value (such as metadata
regarding the exact time and place of transactions), and stated that
data providers should not be required to reveal analytically enriched
data if the consumer does not ordinarily see such data and cannot be
said to substantially rely upon it when making decisions about the
selection of consumer products or services. This commenter asserted
that the exception must make clear that it also extends to information
that cannot be shared for contractual reasons and attorney work product
related to an account and any active litigation.
A large data aggregator commenter supported the proposed examples
for the first exception as sufficient and appropriate, stating that the
proposed clarification that the exception for proprietary algorithms
only applies to the algorithm itself, and not to the covered data that
goes into or is an output from the algorithm, appropriately balances a
data provider's right to protect its trade secrets and intellectual
property with a consumer's right to data access and portability. Absent
this clarification, the commenter cautioned that the exception could
swallow the rule, explaining that today myriad terms, conditions,
rates, fees, and features of an account are the result of some
proprietary algorithmic decision making by the financial institution. A
few consumer advocate commenters asked the CFPB to narrow this
exception to clarify that credit scores and other risk scores are not
considered confidential commercial information, and therefore must be
made available.
On the second proposed exception for 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, a bank trade association commenter
asserted that it was too narrow and should be revised to remove the
term ``sole.'' This commenter explained that very limited information
is collected solely for fraud prevention. Another data provider trade
association offered examples of information it believes fall within the
statutory exception, such as information related to security incidents
and internal account flags, and requested that the CFPB reconsider its
approach to this exception.
On the third exception for information required to be kept
confidential by any other provision of law, a few data provider
commenters requested that the exception be expanded. One asked for
examples of laws that would require a data provider to withhold
information from a consumer, and a few urged the CFPB to add a good
faith compliance standard for data providers to withhold information if
they reasonably believe that the information must be kept confidential
by law.
On the fourth exception regarding information that a data provider
cannot retrieve in the ordinary course of its business, one research
institute commenter requested that it be narrowed as it may allow data
providers to find loopholes or shield themselves from disclosing
information that they should be required to provide to consumers. A
data aggregator commenter requested changes so that data providers
cannot evade their obligations to provide covered data by deliberately
making it difficult to retrieve data in the ordinary course of
business. The commenter suggested adding a presumption that all covered
data are retrievable in the ordinary course at least for a period
stretching from the present back at least 24 months and adopt an
interpretation of the phrase ``in the ordinary course'' that relies on
an objective industry standard and would not permit a data provider to
adopt an unreasonable policy to evade data access obligations. A data
provider commenter asked the CFPB to add examples of information that
are within the scope of this exception, explaining that it believes
terms and conditions and payments scheduled through third parties would
be excepted. Another data provider commenter stated that 24 months of
historical transaction data are not retrievable in the ordinary course
of business, and that a shorter safe harbor of six months would be more
appropriate.
One Member of Congress commenter cited the discussion in the
proposal of how the exceptions proposed in Sec. 1033.221 are narrow
and 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. This commenter asserted that proposed Sec. 1033.221 and the
interaction with proposed Sec. 1033.351(b)(1) will ensure that
consumer data are not withheld for anticompetitive reasons.
Final Rule
For the reasons discussed herein, the CFPB is finalizing the
exceptions, including the examples of data that do not fall within the
exceptions, as proposed. The CFPB has concluded that additional
examples of information that fall within the exceptions, as requested
by some commenters, are not necessary at this time. The CFPB intends to
monitor the market for pretextual use of the CFPA section 1033
exceptions and more generally for violations of the prohibition against
evasion in Sec. 1033.201(a)(2).With respect to a commenter's request
to use rulemaking authority to reclassify the statutory term
``exceptions'' to ``exemptions,'' the commenter did not explain why
this change from the statute was necessary to clarify that these data
types are not covered by the rule. The CFPB is thus finalizing the
heading for Sec. 1033.221 using the statutory language.
Confidential Commercial Information
Final Sec. 1033.221(a) restates the exception at section
1033(b)(1) for any confidential commercial information, including an
algorithm used to derive credit scores or other risk scores or
predictors. Final Sec. 1033.221(a) further clarifies that information
does not qualify for this exception merely because it is an input to,
or an output of, an algorithm, risk score, or predictor. Final Sec.
1033.221(a) includes an example of APR and other pricing terms as data
that are sometimes determined by an internal algorithm or predictor but
do not fall within this exception.
With respect to comments that rewards programs terms, rewards
credits, and terms and conditions are proprietary and should fall under
the first exception for confidential commercial information, the CFPB
has determined that these data do not fall within the definition of
confidential commercial information. Today, rewards program terms are a
factor in how consumers decide to use and select credit cards. They
concern the covered consumer financial product or service obtained from
the data provider, and they support important consumer use cases like
comparison shopping, personal financial management, and account
switching. These terms are commonly shared with consumers, just like
general terms and conditions for an account--similarly, the credits
that a consumer has in a rewards program are shared with the consumer,
and are necessary in order for the consumer to be able to use those
rewards. Because
[[Page 90878]]
these data are shared with consumers, must be shared for rewards
programs and products to function, and are necessary for consumers to
comparison shop and make informed choices about how to use their
account, they are not confidential commercial information.
With respect to a commenter that suggested the CFPB should further
define confidential commercial information on the basis of data's
utility to a consumer relative to its commercial value to a data
provider, the CFPB has determined that this suggested additional
restriction of data availability is inconsistent with Congress's
delineation of limited exceptions to the consumer access data right.
Congress did not include an additional balancing test in CFPA section
1033, and imposing one in this final rule would risk subverting
consumers' right to access data. However, the CFPB notes that the Sec.
1033.421(a) general limitation standard limits third parties'
collection, use, and retention of covered data to that which is
reasonably necessary to provide the product or service that the
consumer requested. If particular data points are not relevant to any
product or service that a consumer might request, then a third party
would generally not be able to request those data points. In this way,
the final rule already accommodates the commercial usefulness of
covered data without the inclusion of an explicit balancing test.
With respect to information that cannot be shared for contractual
reasons and attorney work product related to an account and any active
litigation, commenters did not identify specific items of covered data
that would potentially fall under these conditions. A data provider
cannot limit a consumer's access to data simply because the consumer
and the data provider are engaged in a legal dispute. While there is a
separate exception for data that must be kept confidential by any other
provision of law, as discussed later in this section this exception
does not apply merely because the data provider must protect it for the
consumer. Furthermore, if a data provider were to structure legal
arrangements with the intent of subjecting covered data to this
exclusion with the likely effect of frustrating consumers' data access
rights, such behavior could violate the anti-evasion provision in final
Sec. 1033.201(a)(2).
For a discussion of comments related to reverse engineering of
covered data, see part IV.D.3.
Information Collected for the Sole Purpose of Preventing Fraud and
Certain Other Unlawful Activities
Final Sec. 1033.221(b) restates the exception at section
1033(b)(2) any for information collected by the data provider for the
``sole'' purpose of preventing fraud or money laundering, or detecting,
or making any report regarding other unlawful or potentially unlawful
conduct. Final Sec. 1033.221(b) further clarifies that information
collected for other purposes does not fall within this exception, and
states that, for example, name and other basic account verification
information do not fall within this exception. The final rule retains
the word ``sole'' because the CFPB understands that data providers use
a variety of data in the context of identifying and preventing unlawful
activity, and therefore expanding the exception to cover all
information used for these purposes would create an exception that
risks swallowing the rule.
Similarly, basic account verification information is necessary to
support a variety of use cases for which the third party needs to
ensure that the name on the account matches the name of the consumer.
Expanding the exception to cover this kind of basic data--which is
collected by data providers for a variety of reasons unrelated to
preventing unlawful activity--would frustrate consumers' data access
right in a way that would conflict with Congress's intent.
Information Required To Be Kept Confidential
Final Sec. 1033.221(c) restates the exception at section
1033(b)(3) for any information required to be kept confidential by any
other provision of law. Final Sec. 1033.221(c) further clarifies that
information does not qualify for this exception merely because the data
provider must protect it for the consumer. Final Sec. 1033.221(c) also
states, as an example, that the data provider cannot restrict access to
the consumer's own information merely because that information is
subject to privacy protections. In response to comments requesting that
the CFPB identify laws that might require information to be kept
confidential, the final rule does not include specific examples,
because of the potential for both over- and under-inclusiveness.
However, the CFPB notes that, as an example, financial institutions are
prohibited from notifying an individual that a suspicious activity
report has been filed against them, and this might constitute an
example of when a data provider would be required to keep that specific
information confidential.
In response to comments requesting a good faith compliance standard
for data providers to withhold information if they reasonably believe
that the information must be kept confidential by law, the CFPB notes
that, under final Sec. 1033.351(b)(1), indicia of whether a data
provider's record of data fields it makes available complies with the
policies and procedures requirement of final Sec. 1033.351(b) include
whether that record conforms to a consensus standard. Thus, to the
extent that a data provider conforms with a consensus standard in
making particular data fields available (and not making other data
fields available), conformance with the consensus standard would carry
some indication of compliance.
Information That Cannot Be Retrieved in the Ordinary Course of Business
Final Sec. 1033.221(d) restates the exception at CFPA section
1033(b)(4) for any information that the data provider cannot retrieve
in the ordinary course of its business with respect to that
information.
Terms and conditions information is typically retrievable in the
ordinary course of business as data providers are required to disclose
and make available such information under other laws, including but not
limited to Regulation E and Regulation Z.\59\ The other suggestions
raised by commenters--such as security incident information and one-
time verification codes--generally do not fall within the covered data
definition in Sec. 1033.221 or otherwise are not in the control or
possession of the data provider. For example, as discussed above in
part IV.B.3 with respect to upcoming bill information, bill payments
scheduled directly with merchants or other payees--and not on the data
provider's bill payment platform--are not typically in the control or
possession of the data provider. Generally, a data provider would not
be permitted to categorically refuse access to data specifically
included in the definition of covered data under this exception, absent
some additional showing that the data were
[[Page 90879]]
not retrievable in the ordinary course of its business with respect to
that information. The CFPB understands from comments that historical
terms and conditions information may sometimes be stored as image
files. If it would require extraordinary, manual effort to collect and
translate this information into a machine-readable, electronic form,
that information may not be retrievable in a data provider's ordinary
course of business with respect to that information. However, the CFPB
does not expect current terms and conditions to be subject to any such
exception given the legal requirements noted above.
---------------------------------------------------------------------------
\59\ For example, 12 U.S.C. 4303(a) of the Truth in Savings Act
(TISA), 12 U.S.C. 4301 et seq. states: ``Each depository institution
shall maintain a schedule of fees, charges, interest rates, and
terms and conditions applicable to each class of accounts offered by
the depository institution, in accordance with the requirements of
this section and regulations which the [CFPB] shall prescribe.''
Further, 12 U.S.C. 4305(a) requires a depository institution to make
the required schedule available to any person upon request. TISA is
implemented in the CFPB's Regulation DD (12 CFR part 1030) and the
NCUA's 12 CFR part 707.
---------------------------------------------------------------------------
One commenter asked the CFPB to lower the historical transaction
data safe harbor in Sec. 1033.211(a) from 24 months to 6 months
because it does not believe that 24 months of transaction data are
retrievable in the ordinary course of business. As discussed above in
Sec. 1033.211(a), the CFPB understands that data providers generally
retain 24 months of transaction data according to their record
retention requirements in Regulation E and Regulation Z. If a data
provider cannot retrieve 24 months of data in the ordinary course of
business notwithstanding its other compliance obligations, it cannot
take advantage of the safe harbor but would be able to make available
less information. With regard to comments requesting that this section
include a prohibition on reverse engineering, such a prohibition would
not be appropriate for exceptions to the requirement to make available
covered data. However, third party use of data for reverse engineering
of proprietary algorithms is addressed in the discussion of Sec.
1033.421(a)(2).
In response to the comments suggesting that the final rule narrow
this exception to avoid evasion of the final rule, this concern is
addressed in the anti-evasion provision in final Sec. 1033.201(a)(2).
A data provider that designs its systems to make data less available to
access, with the intent of evading the requirements of subparts B and C
of part 1033, or that the data provider knows or should know is likely
to render unusable covered data or is likely to prevent, interfere
with, or materially discourage a consumer or authorized third party
from accessing covered data, would violate the anti-evasion provision.
C. Subpart C--Data Provider Interfaces; Responding to Requests
1. Overview
Subpart C establishes how covered data are to be made available and
the mechanics of data access, including basic operational, performance,
and security standards, and other policies and procedures. In
particular, certain provisions ensure that data providers make covered
data available to authorized third parties through functionality fit
for that purpose--labeled a ``developer interface''--rather than
through screen scraping of a consumer interface. Other provisions
require data providers to disclose information that helps third parties
request data and to establish and maintain written policies and
procedures reasonably designed to achieve the objectives of subparts B
and C. In addition, to prevent data providers from inhibiting
consumers' exercise of their statutory data access right, subpart C
prohibits data providers from charging fees for establishing or
maintaining the required interfaces or for receiving requests or making
available covered data in response to requests.
2. General Requirements (Sec. 1033.301)
Requirement To Maintain Interfaces (Sec. 1033.301(a))
The CFPB proposed in Sec. 1033.301(a) to require a data provider
subject to the requirements of part 1033 to maintain a consumer
interface and to establish and maintain a developer interface. The CFPB
preliminarily determined that the requirement would carry out the
objectives of CFPA section 1033 by ensuring consumers and authorized
third parties can make requests for and receive timely and reliable
access to covered data in a usable electronic form. Proposed Sec.
1033.301(a) also stated that the consumer interface and the developer
interface must satisfy the requirements set forth in Sec. 1033.301
(i.e., Sec. 1033.301(b) and (c), discussed in this part IV.C.2 below)
and that the developer interface must satisfy the additional
requirements set forth in Sec. 1033.311 (discussed in part IV.C.3
below).
Requirement To Maintain Consumer Interface
Under the CFPB's proposal, not every interface that a data provider
might offer--such as a mobile banking portal and an online banking
portal--would have been required to satisfy all of the proposed
requirements that would apply to consumer interfaces (discussed below),
as long as collectively the provider's interfaces satisfy the
requirements. The CFPB requested comment on whether data providers
inform consumers using mobile banking applications that additional
information might be available through providers' online banking
applications.
All commenters, including data providers, third parties, and
consumer advocate commenters, who addressed the requirement to maintain
a consumer interface supported it. Data providers stated that they
maintain those interfaces today. Consumer advocates suggested that the
CFPB adopt additional requirements for consumer interfaces, such as
being intuitive or user friendly. They also suggested that the rule
require a data provider to disclose in the consumer interface the third
parties accessing a consumer's covered data and, if the data provider
provides a mechanism for the consumer to revoke such access, how the
consumer can revoke such access. They argued that these disclosures are
important to facilitate consumer awareness of the third parties with
which they have shared their data and consumer action if they do not
want the data sharing to continue. In response to the CFPB's request
for comment, they requested that the CFPB require a data provider to
provide through its mobile application the same information as through
a desktop application, because many low- and moderate-income consumers
only have a mobile phone for internet access.
For the reasons discussed herein, final Sec. 1033.301(a) requires
a data provider to maintain a consumer interface. This is necessary and
appropriate to implement the statutory requirement in CFPA section
1033(a) that data providers make covered data available to consumers in
a usable electronic form. The requirement will impose limited cost on
data providers because they generally maintain these interfaces today.
It will ensure that consumers benefit from ready access to their own
financial data.
The CFPB declines to adopt the additional requirements for the
interfaces suggested by consumer advocates. Under the final rule, as
under the proposal, not every data provider consumer interface must
satisfy the requirements of part 1033, as long as collectively the
provider's consumer interfaces satisfy the requirements. Competition
among data providers for customers will continue to appropriately
incentivize them to invest in and improve the various consumer
interfaces they make available to consumers. In contrast, the CFPB is
adopting more prescriptive requirements for developer interfaces in
Sec. 1033.311 (discussed below) because consumers are unlikely to
comparison shop among data providers based on the performance of those
interfaces.
[[Page 90880]]
Requirement To Maintain Developer Interface
The CFPB received numerous comments related to its proposal in
Sec. 1033.301(a) to require data providers to establish and maintain a
developer interface. Third party commenters requested clarification as
to how the provision would apply to a service provider that the data
provider employs to establish and maintain the data provider's
developer interface. More specifically, they requested that the rule
clarify that, in such a situation, the data provider's service provider
may not impose any conditions or restrictions on interface access that
the data provider itself may not impose and must comply with all rule
provisions applicable to developer interfaces. Commenters of all
types--including third parties, consumer advocates, research and
academic institutions, data providers and associations thereof--
expressed general support for the CFPB's framework in part 1033 of
moving away from screen scraping for data access, but requested
technological neutrality for how a data provider may implement the
required interface. Some commenters, including both data providers and
third parties, stated that implementing APIs would be overly difficult
or costly for some data providers such as small depository
institutions. These commenters requested that the rule allow data
providers the choice of implementing a developer interface, permitting
screen scraping of the consumer interface, or prohibiting access to
covered data by all third parties.
Some data provider commenters and a data aggregator questioned or
objected to the CFPB's proposal to require data providers to establish
a developer interface. These commenters asserted that the requirement
is beyond the authority CFPA section 1033 provides to the CFPB and that
it is in their view not appropriate for a regulation, as opposed to a
statute, to require entities to implement what they characterized as a
new financial product such as a developer interface. In particular,
these commenters asserted that the CFPB had incorrectly interpreted the
term ``consumer'' to include consumers' third party representatives.
They also asserted that the CFPB lacked authority to require data
providers to enable ``open banking,'' which they described as a matter
of vast economic and political significance subject to the ``major
questions'' doctrine.
One commenter stated that Congress could not have intended this
broad result because in 2010, when Congress adopted the CFPA, the data
sharing market did not include the wide variety of third party fintech
firms that the CFPB proposed to include as consumers. The commenter
also stated that the proposal was inconsistent with the structure of
CFPA section 1033 because it would require a developer interface that
is exclusively accessible to third parties and a consumer interface
that is exclusively accessible by consumers. The commenter also
maintained that Congress would not have intended section 1033 to
authorize the CFPB to launch open banking unilaterally without
providing for a greater role for other agencies, beyond what it
described as a narrow degree of consultation about certain topics. The
commenter did not believe the CFPB had given those agencies a
meaningful role in the process. Finally, the commenter stated that
efforts to create an open banking system would restrict technological
innovation and consolidate the number of incumbent data aggregators in
the market.
For the reasons discussed herein, the CFPB is finalizing the
requirement in Sec. 1033.301(a) that a data provider maintain a
developer interface. No change in substance from the proposal is
intended or effected by simplifying the proposed rule's ``establish and
maintain'' to ``maintain'' in final Sec. 1033.301(a). Under the
proposed rule, a data provider was exempt from the proposal if it did
not have a consumer interface. The CFPB proposed that a data provider
with a consumer interface but without a developer interface would be
required to ``maintain'' the consumer interface and to ``establish and
maintain'' a developer interface. Under final part 1033, the question
of whether a data provider has a consumer interface is not relevant to
determining whether the data provider is subject to part 1033. A data
provider subject to part 1033 must have functionality for making
covered data available to consumers (a consumer interface) and
functionality for making covered data available to authorized third
parties (a developer interface). If a data provider subject to part
1033 does not currently have such functionality for authorized third
parties, the part 1033 requirement that the data provider maintain such
functionality--a ``developer interface''--includes and incorporates the
proposed requirement that the provider establish the developer
interface.
The requirement is necessary and appropriate to ensure data
providers make available covered data upon request in a usable
electronic form to third parties that are authorized to access covered
data on behalf of consumers. The developer interface requirements in
the rule, including the requirement that the interface not allow third
parties to access covered data using consumer credentials, are not a
requirement to use any specific technology to enable data access. As
discussed under the definitions above, the term ``developer interface''
is simply a label of convenience for data access functionality that
meets rule requirements. The technological means by which data
providers choose to achieve that functionality is entirely up to
providers.
The requirements and prohibitions in subparts B and C of part 1033
apply to data providers. A data provider may not by contract transfer
its legal obligation to comply with the part 1033 requirements and
prohibitions to a vendor. A data provider may enter into a contract
with a vendor under the terms of which the vendor agrees to perform
activities that satisfy the data provider's compliance obligations
under part 1033, but in that situation it remains the data provider's
legal responsibility to comply with the requirements and prohibitions
of subparts B and C of part 1033, and the data provider violates part
1033 if its vendor fails to fully fulfill the relevant compliance
obligations. For example, if the data provider and its vendor
collectively fail to fully fulfill one or more of the data provider's
obligations under part 1033, the CFPB (or other regulator) may
supervise and enforce that compliance failure against the data
provider.
In final part 1033, the CFPB has taken steps to ensure the
feasibility and technological neutrality of the Sec. 1033.301(a)
requirement that a data provider maintain a developer interface,
including for small data providers. The final rule does not require the
use of any specific technology in order to comply. Specifically, in
Sec. 1033.311(e) (discussed in part IV.C.3 below), the CFPB is
incorporating an example that makes explicit that a data provider may
satisfy its obligation to maintain the required data access by entering
into a contract with its service provider (for example, a core
processor) pursuant to which the service provider screen scrapes
covered data from the data provider's consumer interface and makes the
covered data available to authorized third parties through a developer
interface that the service provider maintains on behalf of the data
provider. The CFPB believes that this ``self-scraping'' approach will
meaningfully reduce the burden of the developer interface requirement
through economies of scale: a small number of larger service providers
will be able to
[[Page 90881]]
maintain developer interfaces on behalf of a large number of smaller
data providers. In this situation, as discussed above, the obligation
for the developer interface to satisfy the requirements and
prohibitions of part 1033 nonetheless continues to rest with the data
provider.
The CFPB has determined that the CFPA provides the CFPB with
authority to require data providers to maintain developer interfaces
and that the rule does not run afoul of the major questions doctrine.
As proposed (and as discussed above), Sec. 1033.131 defines
``developer interface'' as functionality through which a data provider
receives requests for covered data from authorized third parties and
makes covered data available electronically in response to the
requests. Requiring data providers to maintain this functionality does
not constitute requiring them to provide a new consumer financial
product or service; instead, it merely requires them to maintain a
secure mechanism through which they make consumers' covered data
available to consumers' authorized third party representatives.
Elsewhere in this document, the CFPB estimates the costs part 1033 will
impose on data providers (including but not limited to the developer
interface requirement). The costs are orders of magnitude lower than
any level that would implicate the major questions doctrine. There is
also no political controversy on the topic of developer interfaces of
the magnitude that suggests it is a major question.
To the extent that commenters meant to argue that requiring data
providers to provide covered data to consumers' authorized third party
representatives implicates the major questions doctrine, the CFPB
disagrees. As noted above, the costs of providing covered data to third
parties are orders of magnitude lower than any level that would
implicate the major questions doctrine, and there is also no political
controversy of the kind that has supported a finding that there is a
major question. Moreover, the plain meaning of CFPA section 1033, in
combination with the CFPA's definition of consumer in CFPA section
1002(4), requires data providers to make covered data available to
consumers' authorized third party representatives. Thus, any
purportedly ``major'' consequences from that requirement flow from
Congress' decision to enact 1033, not the CFPB's rule. This is not a
situation where an agency discovers in a long-extant statute an
unheralded power. Instead, this is simply the first CFPB rule to
execute Congress' instructions on the topic, after a multiyear
rulemaking process.
The CFPB notes that the U.S. consumer data sharing market
encompassed consumers' authorized third party representatives at the
time Congress enacted the CFPA in 2010. For example, many consumer-
authorized third party representatives were providing personal
financial management use cases well before 2010.\60\ Thus, Congress in
fact did intend that the 2010 CFPA and the CFPB's rule implementing it
(as expressly authorized by CFPA section 1033(a)) would broaden and
deepen the consumer-permissioned data sharing market that existed at
that time by requiring data providers to share financial data with
consumers' authorized third party representatives. And nothing in the
language of CFPA section 1033 limits it to the use cases that existed
in 2010.\61\
---------------------------------------------------------------------------
\60\ Pre-2010 providers of these use cases include Mint,
Mvelopes, Quicken, Wesabe, and Yodlee.
\61\ To the contrary, Congress intended for the CFPB to have
``enough flexibility to address future problems as they arise,'' and
that ``[e]xperience has shown that consumer protections must adapt
to new practices and new industries.'' S. Rep. 111-176 at 11 (2010).
---------------------------------------------------------------------------
This view of congressional intent is fully consistent with the
plain meaning of CFPA sections 1033 and 1002(4) described above, the
interoperability objectives of CFPA section 1033(d), and the ongoing
evolution of the U.S. data sharing market. That is, a rule requiring
only that data providers make financial information available to
individual consumers, as opposed to also requiring them to make the
information available to third parties authorized by consumers, would
significantly impair the uses to which consumers, through authorized
third parties, are actually putting their financial data today. In sum,
therefore, the CFPB can discern no textual, historical, or consumer-
protection basis for limiting part 1033 in the artificially cramped way
that these commenters suggest.
Similarly, ``open banking'' as the CFPB uses that term (which is
not legally defined) already exists in the U.S. The proposed rule noted
that the CFPB ``uses the term `open banking' to refer to the network of
entities sharing personal financial data with consumer authorization.''
88 FR 74796, 74797 (Oct. 31, 2023). U.S. data providers already do
that. Further, such sharing is what CFPA section 1033 mandates and what
part 1033 requires. Of course, other jurisdictions might use the term
``open banking'' differently. For example, part 1033 does not require
data providers to permit authorized third parties to make changes
(commonly referred to as ``write access'') to consumers' financial data
or to transfer funds to or from consumers' financial accounts. In
contrast, other ``open banking'' frameworks around the world, such as
the European Union Payment Services Directive and the United Kingdom's
Open Banking framework, address write access. While these limitations
might be in contrast to other jurisdictions' use of the term ``open
banking,'' such semantics do not change the fact that part 1033 adheres
closely and appropriately to the open-banking framework Congress
enacted in CFPA section 1033.
The CFPB also finds that the part 1033 developer interface
requirement is justified by the factual record and will not stifle
innovation nor result in anti-consumer consolidation. Specifically, the
rulemaking record provides ample evidence that a CFPB regulation
condoning or requiring data provider provision of consumers' data to
authorized third parties through the mechanism of screen scraping of
data providers' consumer interfaces would present inappropriate data
security and data accuracy risks to consumers, as well as to data
providers, and would reduce consumers' control over the portion of
their financial data that they share. The CFPB finds that the permitted
self-scraping approach described above does not entail these risks
because data providers contractually govern and are responsible for the
``self scraping'' that data providers' service providers, such as core
processors, will conduct under that approach.
The CFPB considered a form of screen scraping known as
``tokenized'' screen scraping, which is more secure than regular screen
scraping. However, even tokenized scraping results in third parties
accessing a larger portion of consumers' financial data than they need
to provide the financial services that consumers are requesting. Like
non-tokenized screen scraping, it also requires third parties to parse
and transpose financial information from human-readable form. The CFPB
received feedback that this activity risks inaccuracy and undermines
the interoperability benefit of standardized data formats, which CFPA
section 1033(d) requires the CFPB to promote. Such data would not be
usable to consumers or authorized third parties, as required by CFPA
section 1033(a). The CFPB therefore is not adopting that alternative.
In light of the risks and imprecision of screen scraping, and
within the bounds of the rulemaking discretion granted to it by CFPA
section 1033(a), the CFPB has determined that the best way to
effectuate the CFPA requirement that data providers make covered data
[[Page 90882]]
electronically available to consumers' authorized third party
representatives, and also make the data available securely and
accurately, is to require data providers to maintain a ``developer
interface,'' i.e., to maintain functionality fit for purpose through
which they electronically receive and respond to requests for covered
data from authorized third parties in accordance with the requirements
of part 1033. As noted, CFPA section 1033(a), in combination with the
CFPA's consumer definition, makes clear that the CFPA requires data
providers to make covered data available to consumers' authorized third
party representatives. The CFPB therefore declines to permit a data
provider to comply with CFPA section 1033(a) by blocking all third
party access to covered data.
Some commenters asserted that this approach would restrict
technological innovation or result in consolidation of the data
aggregation market. As noted above, the rule implements Congress'
decision for data providers to make available consumer data to third
parties directly. Further, the rule will foster competition and
innovation, as many commenters believed it would. In particular, the
standardization and machine-readability of data types and formats and
communications protocols across data providers that is enabled by
developer interface functionality, as opposed to screen scraping, will
facilitate, not restrict, direct access to consumers' financial data by
authorized third parties, including new entrants and those providing
products and services that compete with those offered by the consumer's
existing account provider. That is, it will reduce authorized third
parties' reliance on data aggregators for accessing consumers'
financial data from data providers. This is because screen scraping--
the data ingestion, parsing, and mapping it entails (let alone all its
risks and inaccuracies)--is not easy, which is why many smaller
authorized third parties today rely on data aggregators to do it.
Because the standardization enabled by developer interfaces will
facilitate direct access by authorized third parties, the number of
authorized third parties should increase (the opposite of
consolidation) and the variety of products and services they offer
should also increase (the opposite of restricting innovation). Further,
competition among data aggregators for the business of authorized third
parties should increase too.
It is also not true, in contrast to commenters' assertions, that
part 1033 requires a data provider to maintain developer interface
functionality that is exclusively accessible by authorized third
parties and a consumer interface that is exclusively accessible by
individual consumers. Instead, part 1033 permits (but does not require)
data providers to grant developer interface access to individual
consumers and to grant consumer interface access to authorized third
parties. Further, part 1033 does not require that a data provider's
consumer interface and its developer interface be separate and distinct
from each other. Instead, part 1033 permits (but does not require) a
data provider to provide its developer interface and its consumer
interface through the same mechanism (or set of mechanisms), provided
that the mechanism satisfies the part 1033 requirements applicable to
developer interfaces and the requirements applicable to consumer
interfaces.
The CFPB discusses elsewhere in this final rule the consultation
processes that it has engaged in with Federal and State regulators. In
contrast to commenters' assertions, the CFPB in fact gave other
agencies a very meaningful role in the process and, in any event, has
complied with the consultation obligations that the law places on the
CFPB.
Machine-Readable Files (Sec. 1033.301(b))
The CFPB proposed in Sec. 1033.301(b) to require a data provider
to make available, upon specific request, covered data in a machine-
readable file that can be retained by a consumer or an authorized third
party and transferred for processing into a separate information system
that is reasonably available to and in the control of the consumer or
authorized third party. The CFPB also proposed an example of how data
providers could make available covered data in a machine-readable file
that can be retained. The CFPB preliminarily determined that Sec.
1033.301(b) would provide important benefits to consumers, such as by
enabling them to share their data with others, including providers of
competing financial products and services.\62\
---------------------------------------------------------------------------
\62\ 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),
https://financelawpolicy.umich.edu/sites/cflp/files/2021-07/umich-cflp-working-paper-consumer-autonomy-and-data-portability-pathways-Nov-3.pdf.
---------------------------------------------------------------------------
Consumer advocate and third party commenters generally did not
address the proposed Sec. 1033.301(b) requirement.\63\ Data provider
commenters did not object to it, but suggested modifications and
clarifications. They requested that the provision differentiate more
clearly between developer and consumer interfaces, arguing that their
file formats are, and should remain, different from each other. They
also requested that the rule define ``machine-readable,'' particularly
with respect to the consumer interface. They noted that the proposed
rule preamble stated the CFPB's view that today's consumer interfaces
generally perform in an acceptable manner and that the CFPB did not
intend its proposal to result in material changes to consumer
interfaces. Some commenters asserted, however, that the proposed
provision could be interpreted to include burdensome requirements for
the consumer interface. They stated that data providers' consumer
interfaces today typically make covered data available in PDF files
that consumers can print and download, but do not make all covered data
available in a single file, nor do they make all covered data available
in files that are machine-readable (such as CSV, XLS, or XML files) but
instead only make transaction history available in such files. They
asserted that if proposed Sec. 1033.301(b) were interpreted to include
such requirements--e.g., that all of a consumer's covered data be made
available in a single machine-readable file through the consumer
interface--the provision would result in costly modifications to data
providers' consumer interfaces when only few consumers actually request
machine-readable files through consumer interfaces. One commenter
expressed fraud concerns with respect to making machine-readable files
available through the consumer interface but did not elaborate.
---------------------------------------------------------------------------
\63\ One third party stated that machine-readable formats would
advance self-sovereign-identity principles.
---------------------------------------------------------------------------
The CFPB is finalizing Sec. 1033.301(b) with certain changes.
Except as discussed below, the provision requires that upon request for
covered data in a machine-readable file, a data provider must make
available to a consumer or an authorized third party covered data in a
file that is machine-readable and that the consumer or authorized third
party can retain and transfer for processing into a separate
information system that is reasonably available to and in the control
of the consumer or authorized third party. These requirements will
provide important benefits to consumers, such as by ensuring that they
continue to be able to share their data with others, including
providers of competing financial products and services. However, to
ensure these benefits without imposing inappropriate burden on data
providers,
[[Page 90883]]
particularly with respect to their consumer interfaces, it is necessary
and appropriate to differentiate between the consumer interface and the
developer interface, to not apply certain requirements to the consumer
interface, and to provide clarity regarding how the developer interface
satisfies the requirements, as follows.
Data providers' consumer interfaces generally provide covered data
to consumers in an acceptable manner. The CFPB intends and expects that
its final rule will not require material changes to data providers'
existing consumer interfaces. Unlike the proposal, the final rule for
consumer interfaces, as set forth in Sec. 1033.301(b)(1)(i), does not
apply the machine-readability requirements of Sec. 1033.301(b) to
payment initiation information (described in Sec. 1033.211(c)) or to
account verification information (described in Sec. 1033.211(f)).
Nonetheless, the consumer interface is required to make that
information available in an electronic form usable by consumers, such
as a human-readable form, pursuant to the general availability
requirement in Sec. 1033.201(a). In contrast to how this information
must be made available to third parties through the developer
interface, requiring this information be made available directly to
consumers in machine-readable files would provide limited additional
utility to consumers relative to their ability to access this
information in human-readable form.
Moreover, and also unlike the proposal, pursuant to Sec.
1033.301(b)(1)(ii), the final rule does not require consumer interfaces
to make available the account terms and conditions (described in Sec.
1033.211(d)) in machine-readable form. Instead, that information need
only be made available in a retainable form. Many data providers make
terms and conditions available to consumers, as well as the general
public, in retainable form. The CFPB understands that data providers
generally also make certain important terms and conditions--such as the
rates and fees applicable to accounts and balances--available in human-
readable form in the consumer interface; additionally, many terms and
conditions applicable to accounts are restated in periodic statement
communications, which are also generally made available through
consumer interfaces. The CFPB intends and expects that these changes
from its proposed rule will mean that the requirements of Sec.
1033.301(b) for consumer interfaces do not result in material burden
for data providers; i.e., do not result in material changes from data
providers' current consumer interface systems and practices.
For consumer interfaces, the covered data that remains subject to
Sec. 1033.301(b) is the following: transaction information (described
in Sec. 1033.211(a)), account balances (described in Sec.
1033.211(b)), and upcoming bill information (described in Sec.
1033.211(e)). Data providers' consumer interfaces today generally make
that portion of covered data available to consumers in machine-readable
files. Accordingly, applying the requirements of Sec. 1033.301(b) to
that portion of covered data will not require material changes to data
providers' existing consumer interfaces.
In final Sec. 1033.301(b), the CFPB has deleted the word
``specific'' (i.e., has deleted it from the proposal's phrase ``upon
specific request''). The CFPB neither intends nor effectuates any
change of substance by this revision. It remains the case, as under the
proposal, that the consumer must explicitly request covered data in a
machine-readable file in order for the requirements of Sec.
1033.301(b) to be triggered. While the rule does not specify the
functionality (or functionalities) that a data provider must supply to
consumers through which they may request covered data in machine-
readable form, the data provider must supply at least one readily
discoverable mechanism through which consumers may do so. It is
acceptable for a data provider to supply the mechanism only to
consumers who have ``logged in.'' It is also acceptable for the data
provider to guide consumers to the mechanism. For example, if a
consumer calls the data provider, the provider may verbally guide the
consumer to the mechanism. Similarly, if a consumer emails the data
provider, the provider may reply by email with a link to or
instructions for how to access the mechanism. Further, the data
provider's mechanism should not require a consumer to say ``magic
words'' in order for the data provider to deem the consumer to have
requested data in machine-readable form. For example, if a consumer
were to request ``a spreadsheet'' of transactions, the data provider
should consider the consumer to have requested a machine-readable file.
Like the proposal, final Sec. 1033.301(b) does not require a data
provider to make all covered data available to a consumer in a single
file--for example, the entirety of the consumer's transaction history
with the data provider in one file. It does (like the proposal) require
the provider to make the data available to the consumer in one or more
files. Section 1033.211(a) provides that a data provider is deemed to
make available sufficient historical transaction information if it
makes available at least 24 months of such information. It is feasible
for the provider to make available that amount of historical
information in one file. The provider could also make the information
available in multiple files if it chooses to do so.
The requirement to make portions of covered data available in
machine-readable files through the consumer interface, as described
above, will not result in inappropriate fraud risk. As noted, the
requirement is consistent with data providers' existing practices for
making data available through their consumer interfaces. Further, the
requirements in part 1033 to make covered data available (whether in
machine-readable files or otherwise) do not include any requirement to
permit consumers or authorized third parties to initiate payments
through the consumer interface. Instead, it remains up to a data
provider's discretion--as opposed to a requirement of part 1033 or any
other CFPB rule--whether to grant consumers permission to initiate
payments through the data provider's consumer interface.
With respect to the requirement in proposed Sec. 1033.301(b) that
a data provider make covered data available through its developer
interface in machine-readable form, the CFPB has determined that the
requirement in Sec. 1033.311(b) (discussed below) that the developer
interface make the covered data available in a standardized and
machine-readable format is sufficient. Section 1033.301(a) requires a
data provider to maintain a developer interface, which Sec. 1033.131
defines as an interface through which a data provider receives requests
for covered data and makes available covered data in an electronic form
usable by authorized third parties in response to the requests.
Further, Sec. 1033.311(b)(2) requires the developer interface to make
available covered data in a standardized and machine-readable format. A
data provider that maintains a developer interface, as required by
Sec. 1033.301(a) and defined by Sec. 1033.131, that complies with
Sec. 1033.311(b) thereby makes available to authorized third parties
covered data in a machine-readable form that the authorized third
parties can retain and process in separate information systems
reasonably available to them. Accordingly, Sec. 1033.301(b)(2) states
that a data provider's developer interface satisfies the requirements
of Sec. 1033.301(b) if the interface makes available covered data
[[Page 90884]]
in a form that satisfies the requirements of Sec. 1033.311(b).
Fees Prohibited (Sec. 1033.301(c))
The CFPB proposed in Sec. 1033.301(c) to prohibit a data provider
from imposing any fees or charges on a consumer or authorized third
party for establishing or maintaining the interfaces required by Sec.
1033.301(a) or for receiving requests or making available covered data
in response to requests as required by part 1033. The CFPB
preliminarily determined that the proposed prohibition was necessary
and appropriate to ensure that fees do not impede consumers and
authorized third parties from exercising consumers' statutory rights.
The CFPB requested comment on whether any clear parameters exist 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.
Few commenters addressed the prohibition of fees for providing
covered data to individual consumers through the consumer interface.
Those commenters who addressed this issue did not object and stated
that data providers do not charge fees today for providing covered data
through their consumer interfaces.
Many commenters addressed fees for providing covered data to
authorized third parties through the developer interface. Third party
and consumer advocate commenters generally supported the proposed fee
prohibition on the grounds that covered data belongs to consumers and
that the statute gives consumers the right to access and share the data
with the authorized third parties that they choose. These commenters
also suggested modifications to the prohibition to ensure that data
providers do not evade it by, for example, charging higher fees for
other financial products and services to consumers and authorized third
parties for exercising their section 1033 data access rights. Third
party commenters suggested that the CFPB make clear that the fee
prohibition applies to data providers' service providers, in addition
to applying to data providers themselves.
SBA Advocacy compared data providers' provision of covered data to
Federal agencies' provision of information in response to Freedom of
Information Act (FOIA), 5 U.S.C. 552, requests and stated that it seems
inconsistent that agencies are permitted to charge for providing
information whereas data providers are prohibited from doing so.
Data provider commenters opposed the developer interface fee
prohibition. They asserted that the CFPB lacks authority to prohibit
fees under CFPA section 1033. They also stated (as noted above) that
they would incur costs to implement the developer interface and that,
in light of those costs, the fee prohibition is an impermissible taking
because it commandeers data providers' infrastructure and resources for
the benefit of third parties, which may access covered data without
paying a fee and then charge fees to other third parties for the data.
These commenters also stated that the prohibition is inconsistent with
the CFPB's 1034(c) advisory opinion, which permits large institutions
to charge fees for providing data in some limited circumstances, such
as where a consumer had already repeatedly requested and received the
same information regarding their account. It is also inconsistent, they
stated, with OCC regulations (12 CFR 7.4002), which according to the
commenters give national banks discretion to set prices for the banking
services they provide. No commenters provided any information regarding
possible parameters for standardized fees.
For the reasons discussed herein, consistent with the proposal,
final Sec. 1033.301(c) prohibits a data provider from imposing any
fees or charges on a consumer or authorized third party for
establishing or maintaining the interfaces required by part 1033 or for
receiving requests or making covered data in response to requests as
required by part 1033. This prohibition ensures that data providers do
not inhibit consumers' ability to access their data, authorize third
parties to access their data, or choose which third parties to
authorize to access their data.
The CFPB is issuing Sec. 1033.301(c) pursuant to its authorities
under sections 1033(a) and 1022(b)(1) of the CFPA. Section 1033(a)
states that data providers ``shall'' make covered data available to
consumers ``upon request,'' ``[s]ubject to rules prescribed by the
Bureau,'' subject to certain statutory exemptions in section 1033(b),
and without any other condition. Congress did not authorize fees. In
fact, it specified in section 1033(b)(4) that a data provider need not
make available information it ``cannot retrieve in the ordinary course
of its business,'' which weighs against an argument that Congress
intended data providers to be able to decide to condition data access
on payment of a fee. Congress dealt with the policy issue of potential
burden on data providers by cabining the information they are required
to retrieve, rather than through compensation. Even assuming Congress
did not foreclose fees when consumers exercise their statutory rights
under section 1033, in exercising the CFFB's rulemaking authority to
regulate the specifics of data sharing under section 1033, the CFPB is
not permitting fees. In particular, the CFPB is concerned that allowing
them would obstruct the data access right that Congress contemplated.
As discussed later, the CFPB has not identified, and no commenter has
put forward, a suitable alternative that protects the data access
right.
The fee prohibition is also independently authorized by section
1022(b)(1) of the CFPA in order to prevent evasion of Federal consumer
financial law. CFPA section 1033 and this final rule are both Federal
consumer financial laws. If data providers could decide what fee to
charge, they could limit or eliminate the right that CFPA section 1033
confers. Congress would not have enacted CFPA section 1033 if it
trusted data providers to be fully forthcoming with covered data. And,
in the CFPB's assessment, those data providers that perceive CFPA
section 1033 to be a threat to their competitive positions have strong
incentives to withhold information. The CFPB has not identified a
suitable alternative that would prevent such evasion of the data access
right.
The CFPB notes that the fee prohibition is far from a novel use of
rulemaking authority. Other longstanding consumer financial regulations
prohibit fees when consumers seek to exercise statutory rights under
Federal consumer financial laws that are otherwise silent on whether an
entity may charge fees. For example, Regulation E (12 CFR part 1005)
and Regulation Z (12 CFR part 1026) both prohibit fees for error
resolution when an error has occurred and require avoidance of ``any
chilling effect on the good-faith assertion of errors that might result
if charges are assessed when no billing error has occurred.'' \64\
---------------------------------------------------------------------------
\64\ Regulation E comment 11(c)-3; Regulation Z comment 13-2.
---------------------------------------------------------------------------
The CFPB also notes that the fee prohibition is not inconsistent
with FOIA. There, the applicable statute expressly permits fees,
whereas here it does not. Further, the information agencies provide
through FOIA typically does not pertain directly to the requestors of
the information, whereas under CFPA section 1033 the information
provided by data providers
[[Page 90885]]
pertains directly to the requestor--the consumer--because it is
information about the financial product or service the consumer
obtained from the data provider. Finally, FOIA addresses information
that may not be readily available for agencies to find and disclose,
whereas CFPA section 1033 addresses information that data providers can
retrieve in the ordinary course of business.
The fee prohibition does not make this rule a taking. The addition
of the fee prohibition does not make the rule a permanent physical
invasion of property, nor does it limit data providers' control or
discretion to the point that they are deprived of all economically
beneficial use of property. Further, data providers do not generally
charge consumers or third parties for data access today, indicating
that the economic impact of the prohibition, along with any potential
interference with investment-backed expectations, is not so large as to
be considered a taking. Any hypothetical investment-backed expectations
are further attenuated by the fact that Congress enacted section 1033
over fourteen years ago, and the CFPB has been engaged in a lengthy
rulemaking process which will be followed by staggered compliance dates
over a period of years. Data providers have long been on notice that a
CFPB rulemaking will impact data sharing. The character of this rule is
also far removed from a taking. The rule adjusts the benefits and
burdens of economic life, specifically by providing consumers with
greater access to data about their financial accounts, in some cases
with the assistance of companies acting as their representatives.
The fee prohibition is not inconsistent with CFPA section 1034(c)
which, as noted in the CFPB's advisory opinion, permits fees in certain
limited circumstances, such as when a large bank or credit union
charges a fee to a consumer who repeatedly requested and received the
same information regarding their account. See 88 FR 71279, 71282 (Oct.
16, 2023). Section 1034(c) imposes an obligation to ``comply'' with a
consumer request for information, and the CFPB explained that, in the
context of repeated requests, the large bank or credit union would have
already met its obligation under section 1034(c) by ``comply[ing]''
with the consumer's earlier requests. Id. By contrast, section 1033
imposes an obligation to ``make available'' information upon the
consumer's request. 12 U.S.C. 5533(a). By referring to information
being made ``available,'' section 1033 contemplates an ongoing
obligation to grant consumers access to information, rather than an
obligation that could be satisfied by providing information a single
time.
Moreover, the CFPB did not promulgate the CFPA section 1034(c)
opinion through the notice-and-comment rulemaking process. As such, the
opinion was and is limited to setting forth the CFPB's interpretation
of existing law. In contrast, the CFPB is establishing part 1033 in
accordance with the Administrative Procedure Act's notice-and-comment
rulemaking procedures. The CFPB's promulgation of part 1033 may
therefore establish new requirements, including by limiting fees more
strictly than does section 1034(c), if the CFPB determines that is
warranted using the discretionary rulemaking authority that Congress
has delegated.
The fee prohibition is also not inconsistent with the OCC
regulation cited by commenters. The OCC regulation, 12 CFR 7.4002,
generally provides that national banks have authority to charge their
customers non-interest charges and fees but does not override other
Federal laws or regulations that expressly bar specific charges and
fees. For example, as noted above, when an error has occurred the
CFPB's Regulation E and Regulation Z prohibit fees for resolving the
error and the OCC's regulation does not override those prohibitions.
Data provider commenters additionally argued that part 1033 should
permit them to charge fees because data providers' systems are key to
making covered data available and establishing and maintaining those
systems requires resources. They argued that a rule prohibiting them
from offsetting those costs by charging fees to third parties could
necessitate recoupment of the costs through fees to their consumer
account holders for other banking services. They also argued that the
fee prohibition would discourage data providers from implementing and
investing in data sharing systems that exceed the minimum legal
requirements. In contrast, they argued, permitting reasonable fees
would incentivize both data provider investment and third party data
minimization. That is, they argued, third parties accessing more data
through developer interfaces would impose more burden on those
interfaces and therefore should incur greater fees than those accessing
less data. Data provider commenters also asserted that in other
jurisdictions, such as the E.U., fee prohibitions have led to
underinvestment and suboptimal open finance ecosystems. They further
argued that in light of these considerations, E.U. rules proposed in
November 2023 would permit data providers to request reasonable
compensation when providing data to other businesses.
As part of the rulemaking process, the CFPB has taken steps to
reduce data providers' data access costs, as reflected in the final
rule. First, the CFPB proposed and is finalizing that data providers
must make available a narrower set of covered data than the CFPB was
considering at the SBREFA stage. Second, in contrast to the proposed
rule, the final rule does not apply to depository institutions that are
small businesses as defined in SBA's regulations (irrespective of
whether those institutions have a consumer interface). These
institutions therefore will not incur any data access costs under the
final rule. Third, many depository institutions that are not small
businesses, and are therefore subject to part 1033, already have
developer interfaces and therefore should be able to bring those
interfaces into compliance with part 1033 at reasonable cost. Fourth,
the final rule adopts a substantially more extended implementation
timeframe than the CFPB proposed. Fifth, the CFPB continues to develop
guidance materials and to work with industry standard setters to foster
appropriate standards. These steps will give data providers more
certainty regarding how to come into compliance with the rule in the
extended implementation timeframe, thereby reducing their costs. And
sixth, Sec. 1033.311(e) (discussed in part IV.C.3 below) makes clear
that a data provider's developer interface may function by permitting
the data provider's service provider (such as a core processor) to
screen scrape the data provider's consumer interface and to make the
data available through a developer interface that the service provider
establishes and maintains on the data provider's behalf. This approach
offers data providers a low-cost path to providing a developer
interface and is widely used in the market today.
The CFPB does not expect that the fee prohibition will discourage
data providers from implementing and investing in their data sharing
systems. The CFPB is not aware that regulatory requirements or
prohibitions in other areas, such as Regulation E and Regulation Z
error resolution, inappropriately discourage investment in systems in
those areas. To the contrary, regulatory requirements and prohibitions
encourage robust systems and make it less likely that an industry
participant with such systems will be driven from the market by
participants without them. Additionally, data
[[Page 90886]]
providers generally invest significantly in continually improving their
consumer interfaces, which data providers generally do not charge any
kind of fees to access. The CFPB is also aware, including from the
Provider Collection, that some data providers and service providers
(such as core providers) made significant investments to develop,
implement, and maintain developer interfaces even prior to this
rulemaking, and, as noted above, data providers do not generally charge
fees to third parties for accessing developer interfaces.
Data provider fees are not the appropriate means by which third
parties' data minimization is incentivized and accomplished. Instead,
third parties themselves must and should comply with part 1033's data
minimization requirements. Section 1033.311(d) (discussed below)
permits data providers to impose reasonable access caps, further
undermining the appropriateness of permitting data providers to charge
fees to third parties in order to achieve data minimization or, more
broadly, to incentivize third parties to comply with part 1033.
By its terms, the Sec. 1033.301(c) fee prohibition applies to data
providers and will be supervised and enforced against data providers
(just like all of the other provisions in subparts B and C). But the
fee prohibition encompasses a data provider's vendor, in addition to
the data provider itself. For example, assume a data provider asserts
that it is complying with part 1033 because it makes covered data
available to authorized third parties through a developer interface
that the data provider's vendor maintains on behalf of the data
provider. The data provider would not comply with the fee prohibition
in Sec. 1033.301(c) if its vendor charged (or sought to charge) fees
to authorized third parties in connection with making covered data
available to them through the developer interface that the vendor
maintains on behalf of the data provider.
Data sharing in the U.S. is distinguishable in relevant respects
from the E.U. American consumers already expect third party data access
capabilities, and the U.S. market consists of a higher number of
depository institutions (and card issuers) than most other
jurisdictions. Further, the E.U. proposal to permit fees is only a
proposal and, if adopted, would permit only limited, standardized fees.
As a result, the CFPB believes it is premature to conclude that any
difficulties that might have resulted from prohibiting fees for data
access in the E.U. will be replicated here. As noted, the CFPB
requested comment on parameters for reasonable, standardized fees that
neither obstruct the access right nor impede access to interfaces. No
commenters provided information in response to that request, and the
CFPB does not currently have information to suggest it would be
appropriate or feasible to use a standardized fee schedule to account
for the wide variety of circumstances in the open banking system. The
CFPB will continue to actively monitor and engage with open banking
stakeholders. As the CFPB proceeds to implement this first rule under
CFPA section 1033, and to ensure consumers' data rights are respected
across consumer financial markets, it invites continuing input if
entities believe that a regime of standardized fees along the lines of
those described above is appropriate and feasible.
Data provider commenters also opposed the fee prohibition on the
grounds that it would unfairly disadvantage them relative to data
aggregators, which are not prohibited from charging fees to other third
parties in connection with providing data they obtained through
providers' developer interfaces. A few data providers, in addition to
opposing it, asserted that if kept the prohibition must be accompanied
by restrictions on third parties' secondary uses of covered data to
ensure that the benefits of data sharing accrue to consumers, as
opposed to data aggregators. These commenters argued that if the CFPB
were to loosen such restrictions in the final rule then this ``consumer
benefit'' principle would no longer apply and data provider fees to
third parties should be permitted.
The fee prohibition does not unfairly advantage data aggregators
relative to data providers. CFPA section 1033 describes a consumer
right to access data from data providers--and gives no indication that
providers may properly impinge on that right by charging for its
exercise. In contrast, CFPA section 1033 does not include a right for
consumers to require data aggregators to provide covered data. Instead,
the data aggregators' participation in the data-sharing process is
voluntary. Fundamentally, an authorized third party's choice to use a
service provider, such as a data aggregator, and a consumer's exercise
of a statutory right, are entirely different things--there is no
equivalence and accordingly no unfairness. Moreover, a data provider
controls consumers' covered data concerning the financial product or
service that the consumer obtained from the data provider, such that
competitive pressures do not readily limit the data access fees that
data providers might seek to charge. In contrast, data aggregators are
service providers chosen by authorized third parties, who can select a
different aggregator for price reasons--or connect to the data provider
directly. As a result, competition should naturally put downward
pressure on fees that aggregators charge third party clients.
For reasons discussed under subpart D below, the final rule does
not materially increase third parties' permissible secondary uses of
covered data relative to the proposal. Accordingly, it is not necessary
or appropriate to permit data providers to charge fees in light of
possible secondary uses that the CFPB did not propose to permit and is
not permitting in this final rule. In any event, the breadth (or
narrowness) of data aggregators' and other third parties' potential
uses of covered data does not logically control the issue of whether
data providers should be prohibited from charging fees. Competitive
pressure between third parties will naturally put downward pressure on
fees they are able to charge. In light of this competitive pressure,
permitting data providers to charge fees would not cause the benefits
of data sharing to ``shift'' from third parties to consumers; instead,
it would cause the benefits to shift from consumers to the data
providers that hold and control consumers' financial data.
Allowing cost-based fees, regardless of whether or not they are
charged on a per-request basis, would not better effectuate the
consumer data access right described in section 1033. The CFPB received
feedback during the SBREFA process that allowing data providers to
charge fees, including fees to integrate with a developer interface,
could pose a barrier to consumers' use of their data through smaller
authorized third parties. See SBREFA Panel Report at 28. Data providers
have the ability and incentive to restrict third party data access
through fees and allowing data providers to charge different fees to
different third parties also is likely to result in harm to consumers
and third parties. See 88 FR 74796, 74814 (Oct. 31, 2023). In light of
this, allowing data providers to charge what they see as commercially
reasonable fees is likely to obstruct consumers' ability to use their
data, particularly through smaller authorized third parties. In
addition, as noted above, no stakeholder offered any concrete
indication of a workable and administrable standard for ``reasonable
[[Page 90887]]
fees'' despite the CFPB's solicitation of comment on point.\65\
---------------------------------------------------------------------------
\65\ It is not just the fact or level of fees that impedes
consumers' exercise of statutory rights, but their potential
variance as well. For example, variation in fees across data
providers and variation in fees at one data provider across third
parties would likely introduce material negotiating costs to third
parties, thereby further impeding consumers' ability to use their
data.
---------------------------------------------------------------------------
3. Requirements Applicable to Developer Interfaces (Sec. 1033.311)
General (Sec. 1033.311(a))
Proposed Sec. 1033.311(a) stated that a developer interface
required by Sec. 1033.301(a) must satisfy the requirements set forth
in Sec. 1033.311. The CFPB received no comments objecting to this
provision and the CFPB adopts it as proposed.
Standardized Format (Sec. 1033.311(b))
Proposal
The CFPB proposed in Sec. 1033.311(b) to require a developer
interface to make available covered data in a standardized format. The
CFPB proposed that 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, or, in the absence of such a standard,
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. The CFPB preliminarily determined that this proposed
requirement and accompanying safe harbors were necessary and
appropriate to implement the mandate in CFPA section 1033(d) that the
CFPB prescribe standards to promote the use and development of
standardized formats. More specifically, the CFPB preliminarily
determined that, consistent with CFPA section 1033(a) and (d), the
proposal to require 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. In particular, the
proposed provision sought to ensure that the information systems of
new-entrant and small-third parties can process covered data from the
full range of data providers across the market by reducing varied
formats that impel reliance on intermediaries to provide data in a
usable format.
The CFPB did not propose a definition of ``format,'' requesting
comment on whether one is needed and whether the term 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. The CFPB also requested
comment on the above safe harbors that it proposed.
Comments
All commenters, including data providers, third parties, and
consumer advocates, that addressed the proposed requirement that the
developer interface make available covered data in a standardized
format supported it. Further, all commenters that addressed the CFPB's
request for comment stated that the rule should include a definition of
format and that the definition should include, in addition to data
field specifications, a data model and communication protocol for
requests and responses for covered data to be exchanged.\66\ Commenters
stated that this broader approach to the standardized format
requirement would help effectuate interoperability to support data
sharing. Several data provider commenters stated that the rule should
also apply its standardized format requirement to data aggregators.
They argued that doing so would encourage competition and benefit
consumers by facilitating the ability of an authorized third party to
switch data aggregators.
---------------------------------------------------------------------------
\66\ One commenter stated that the rule's standardized format
requirement should include security standards applicable to
authenticating and reviewing authorization of third parties. This
comment is discussed in the preamble to Sec. 1033.331(b), which
addresses how those procedures factor into the final rule.
---------------------------------------------------------------------------
Commenters' views were mixed on the CFPB's proposed approach to
safe harbors for standardized formats. Commenters generally supported
the proposed safe harbor for use of a standardized format set forth in
a qualified industry standard, but were uncertain that one would exist
by the time of the applicable compliance date for part 1033. Because of
that uncertainty, commenters generally did not object to the proposed
safe harbor for a widely used format, although views were mixed on that
point. Specifically, some commenters expressed concern that a safe
harbor for a widely used format could lead to more than one widely used
format, which might not be an improvement over format differences in
place today. Further, many commenters expressed concern with the CFPB's
proposal that a widely used format would receive a safe harbor only in
the absence of a qualified industry standard. These commenters
expressed concern that this approach could make data providers
reluctant to implement their developer interfaces now with a widely
used format because, were they to do so and were a qualified industry
standard later to adopt a different format, the providers with the
widely used format would lose their safe harbor status and could feel
compelled to redo their interfaces using the qualified industry
standard formats. These commenters stated that the CFPB could reduce
issues of multiple formats and incentivize faster deployment of
developer interfaces--thereby increasing data quality and consumer
safety relative to screen scraping--by working with industry
participants to establish a consensus standard for data formats as soon
as possible.
Final Rule
For the reasons discussed herein, the CFPB is adopting final Sec.
1033.311(b) to require a data provider's developer interface to make
available covered data in a standardized and machine-readable format.
The final rule also provides that indicia that the format satisfies
this requirement include that it conforms to a consensus standard. The
final rule defines both ``format'' and ``standardized.'' Format is
defined in Sec. 1033.311(b)(1) to include structures and definitions
of covered data and requirements and protocols for communicating
requests and responses for covered data. Standardized is defined in
Sec. 1033.311(b)(2) to mean that it conforms to a format widely used
by other data providers and designed to be readily usable by authorized
third parties.
The CFPB is not providing examples of ``machine-readable'' file
types because technology regarding automated, digital ingestion of data
may evolve such that any such examples could become outdated. Section
1033.211, discussed above, defines covered data for purposes of part
1033. Section 1033.301(b), also discussed above, provides that a data
provider's developer interface complies with part 1033's machine-
readability requirement if it makes covered data available in a form
that satisfies the requirements of Sec. 1033.311(b). Further, as
noted, Sec. 1033.311(b) requires the developer interface to make
covered data available in a format that is standardized and machine-
readable and provides that indicia that the format satisfies this
requirement include that the format conforms to a consensus standard.
The format definition that the CFPB is adopting gives a data
provider some flexibility as to the structures and definitions of
covered data made available via its developer interface so it can adapt
over time to new and evolving use cases. Nonetheless, in all cases, the
[[Page 90888]]
format must be standardized, i.e., it must be widely used by other data
providers and designed to be readily usable by authorized third
parties. The CFPB believes that this level of flexibility is necessary
and appropriate, both because, as noted, technology is rapidly
evolving, and because there will inevitably be new use cases for which
authorized third parties request covered data. As new uses cases
develop, the best and most readily usable format for a given set of
covered data could change.
For example, under Sec. 1033.211(d) covered data includes account
terms and conditions (as defined in that section), and terms and
conditions include many components, some of which may be numerical and
some of which may be natural language. As authorized third parties' use
cases for covered data change over time, the best standardized and
machine-readable format, or formats, for data providers' developer
interfaces to use in making available the many components of terms and
conditions will also likely change. More specifically, as authorized
third parties' use cases change, the components of terms and conditions
that are made available as machine-readable, discrete ``callable'' data
fields will likely increase, and those components made available as
machine-readable, lengthier ``text'' data fields will likely
decrease.\67\ Over the course of these ongoing changes in authorized
third parties' use cases and pursuant to the ``readily usable by
authorized third parties'' prong of the definition of ``standardized''
in Sec. 1033.311(b), the CFPB expects that data providers will in good
faith take reasonable steps to make the appropriate components of terms
and conditions available through their developer interfaces as discrete
callable data fields.
---------------------------------------------------------------------------
\67\ If it is necessary for a data provider to make available a
PDF file for the purpose of complying with Sec. 1033.311(b), the
PDF file should be machine-readable. While this may be possible for
some PDF files, other PDF files, such as those that include covered
data as images, would generally not be considered machine-readable.
Section 1033.221(d), which restates the statutory exception for any
information that the data provider cannot retrieve in the ordinary
course of its business with respect to that information, might apply
in limited circumstances when historical terms and conditions are
stored as image files, as discussed in part IV.B.4 above. However,
the CFPB does not expect current terms and conditions to be subject
to any such exception given applicable legal requirements, as
discussed with respect to Sec. 1033.221(d) above.
---------------------------------------------------------------------------
Defining format to include structures and definitions of covered
data and requirements and protocols for communicating requests and
responses for covered data will facilitate interoperability across data
providers and third parties, including new-entrant third parties that
wish to access covered data directly from data providers' developer
interfaces, as opposed to through data aggregators. Interoperability is
also facilitated by the two-pronged definition of standardized, under
which format, to be standardized, must be both widely used by other
data providers and designed to be readily usable by authorized third
parties. The final rule includes a non-exhaustive list of components of
format because whether a standard includes any particular component of
format will depend to some degree on the standard selected.
The final rule's definition of format is necessary and appropriate
to implement CFPA section 1033(a) and (d). Standardized structures and
definitions of covered data and requirements and protocols for
communicating requests and responses will help ensure covered data are
readily made available in a usable electronic form to a wide array of
authorized third parties. This facilitation of interoperability also
implements the mandate of CFPA section 1033(d) that the CFPB by rule
promote standardized formats for information, including through the use
of machine-readable files. Without standard protocols for communicating
requests and responses, data providers would forfeit the economies of
scale they can achieve by making covered data available in common ways
through their service providers, such as core processors, and
authorized third parties would incur costs to build custom integrations
to access covered data from various data providers. These costs would
undermine the benefits of requiring data providers to make available
covered data in the first place. Accordingly, the Sec. 1033.311(b)
requirement to use standard protocols for communicating requests and
responses for covered data is necessary and appropriate to promote the
development and use of standardized formats for covered data.
The CFPB proposed that a developer interface would be deemed to
satisfy the standardized format requirement if it made covered data
available in a format widely used by other data providers and readily
usable by authorized third parties. The CFPB believes that those
attributes of a format--that it is widely used by other data providers
and designed to be readily usable by authorized third parties--go
directly to what it means for a format to be ``standardized'' and best
effectuate the statute's objectives of promoting interoperability of
systems to process covered data and ensuring data providers make
available covered data in a usable electronic form upon request.
Accordingly, the final rule adopts those attributes as components of
the definition of standardized in Sec. 1033.311(b)(2). The CFPB
emphasizes that, under the definition of standardized in Sec.
1033.311(b)(2), wide use by other data providers of a format is
necessary but not sufficient for the format to qualify as standardized.
For the format to qualify as standardized, the format must also be one
that is designed to be readily usable by authorized third parties. This
two-pronged approach--widely used by data providers and readily usable
by authorized third parties--is necessary and appropriate to ensure
that third parties, including in particular new-entrant and small third
parties, can process covered data from a wide range of data providers
across the market.
Final Sec. 1033.311(b) makes several changes from the text of
proposed Sec. 1033.311(b)(2) to address concerns from commenters that
the proposed regulatory text could have resulted in fragmentation of
data formats, and for additional clarity. The proposed provision would
have deemed a format standardized in the absence of a qualified
industry standard if the format is widely used by the ``developer
interfaces of similarly situated data providers with respect to similar
data'' and is readily usable by authorized third parties. The final
rule replaces the phrase ``similarly situated data providers,'' with
``other data providers.'' This is intended to further promote the
development and use of standardized data, whereas the proposed approach
could have resulted in fragmentation of format standards. The final
rule also omits the phrase ``with respect to similar data'' as
superfluous because both the proposed and final regulatory text apply
the standardized format requirement to ``covered data.'' In addition,
the phrase ``with respect to similar data'' contained in the proposed
text might have inadvertently resulted in fragmentation of data
formats. The final rule also omits the phrase ``developer interface''
as superfluous, with no change in meaning intended.
The CFPB proposed that a data provider would be deemed to satisfy
the standardized format requirement if it makes covered data available
in a format set forth in a qualified industry standard. In contrast,
under the final rule, indicia that the standardized format requirement
is satisfied include that it makes covered data available in a format
set forth in a consensus standard. The CFPB is making this change--from
safe harbor of compliance
[[Page 90889]]
to indicia of compliance--because, as described above, the CFPB is
defining format (which the proposal did not) to include communications
protocols and requirements, as opposed to only data structures and
definitions. As noted, all commenters who addressed this issue--
including data providers, third parties, and consumer advocates--
supported defining format and defining it in this broader way.
Nonetheless, in light of this broader definition, the CFPB believes
that it is possible or even likely that a given consensus standard will
address only certain aspects of format as defined. As a result, a data
provider may reasonably seek to incorporate more than one consensus
standard into its developer interface's systems and processes. For
example, at a high level, the data provider might incorporate one
standard for data structures and another for communication protocols.
In addition, a given standard might have components within it that are
not geared toward interoperability and therefore do not warrant safe
harbor status. Accordingly, the CFPB has determined that it is more
appropriate for conformance to a consensus standard to serve as indicia
that the data provider's developer interface meets the standardized
format requirement, rather than to serve as a safe harbor.
The change from the proposal's safe harbor approach to the final
rule's indicia approach to consensus standards within Sec. 1033.311(b)
does not change the CFPB's determination that the objective of both
CFPA section 1033(d) and the standardized format requirement in Sec.
1033.311(b) is interoperability, i.e., is to ensure that (1) a data
provider's developer interface can expect and use a standardized data
structure and communication protocol for receiving requests from and
making covered data available to all third parties that request covered
data through the interface \68\ and (2) a third party can use and
expect a standardized data structure and communication protocol for
submitting requests to and receiving covered data from all data
providers' developer interfaces. The CFPB does not anticipate taking
action against data providers' and third parties' approach to achieving
interoperability, so long as entities comply with the standardized
format requirement of Sec. 1033.311(b).
---------------------------------------------------------------------------
\68\ Consistent with Sec. 1033.311(b), data providers may
reasonably require authorized third parties to use standardized and
machine-readable formats when submitting requests for covered data.
---------------------------------------------------------------------------
Incorporating ``widely used'' into the meaning of ``standardized''
and shifting to an approach in which a consensus standard serves as
indicia of compliance (rather than a safe harbor) also addresses
commenters' concerns that data providers might have responded to the
rule as proposed by ``waiting'' to build their developer interfaces
until a consensus standard format was adopted. Of course, the
lengthening of compliance periods in the final rule provides more
assurance that consensus standards will be available before compliance
begins. But in any event a data provider will have certainty that its
developer interface format complies with the requirement to be
standardized, so long as the format is widely used by other data
providers and designed to be readily usable by authorized third
parties. In the event that an applicable consensus standard becomes
available after the relevant compliance date, data providers can be
assured of their continued compliance. They will not need to effectuate
some instantaneous ``redo'' of the developer interface to match the
consensus standard format, but, as appropriate, can simply take steps
to transition to the consensus standard format in an orderly fashion.
Commercially Reasonable Performance (Sec. 1033.311(c))
The CFPB proposed in Sec. 1033.311(c)(1) to require that
performance of the interface must be commercially reasonable. All
commenters who addressed the proposed requirement supported it. The
CFPB has determined that the commercially reasonable performance
requirement for the developer interface carries out CFPA section
1033(a) by establishing how a data provider satisfies the requirement
in CFPA section 1033(a) that the data provider make covered data
available in an electronic form usable by authorized third parties. The
CFPB adopts the requirement, renumbered as Sec. 1033.311(c), with
technical non-substantive edits.
Response Rate; Quantitative Minimum Performance Specification (Sec.
1033.311(c)(1))
Proposal
The CFPB proposed in Sec. 1033.311(c)(1)(i) a quantitative minimum
performance specification for a data provider's developer interface
beneath which the performance of the interface could not be
commercially reasonable. Specifically, the proposed quantitative
minimum performance specification was a response rate of at least 99.5
percent. The CFPB proposed to calculate the response rate as the number
of proper responses by the interface divided by the total number of
queries for covered data to the interface. For clarity and consistency
with other provisions in part 1033, final Sec. 1033.311(c)(1) uses
``request'' in lieu of ``query.'' The CFPB neither intends nor
effectuates any change to the substance of the provision as a result.
The CFPB proposed in Sec. 1033.311(c)(1)(i)(D) to define a proper
response as a response, other than any message such as an error message
provided during unscheduled downtime of the interface, that meets the
following three criteria: (1) the response either fulfills the query or
explains why the query was not fulfilled; (2) the response is
consistent with the reasonable written policies and procedures the data
provider establishes and maintains pursuant to Sec. 1033.351(a); and
(3) the response is provided by the interface within a commercially
reasonable amount of time. The CFPB proposed that the amount of time
cannot be commercially reasonable if it is more than 3,500
milliseconds.
The CFPB proposed in Sec. 1033.311(c)(1)(i)(A) that responses by
and queries to the interface during scheduled downtime for the
interface must be excluded from the calculation of the proper response
rate. The CFPB also proposed in Sec. 1033.311(c)(1)(i)(C) that the
total amount of scheduled downtime for the interface in the relevant
time period, such as a month, must be reasonable and in Sec.
1033.311(c)(1)(i)(B) that in order for any downtime of the interface to
qualify as scheduled downtime, the data provider must have provided
reasonable notice of the downtime to all third parties to which the
data provider has granted access to the interface. Finally, the CFPB
proposed for both Sec. 1033.311(c)(1)(i)(B) and (C), that adherence to
a consensus standard would be an indication that the amount and notice
of downtime were reasonable.
Comments
Both third party and data provider commenters expressed certain
concerns about the CFPB's proposed quantitative minimum requirements.
Third party commenters generally supported the adoption of minimum
quantitative performance requirements, but they saw the proposed rule
as not including a broad enough set of such requirements. Those
requirements it did include they described as too lax because they were
below the performance levels actually being achieved in the market
under third parties' extant data access agreements with data providers.
They
[[Page 90890]]
argued that the rule as proposed could unintentionally cause a race to
the bottom in performance levels. More specifically, they argued that
the proposed 3,500 millisecond response time was too slow and too
vague. They suggested a better requirement would take the form ``less
than x milliseconds at least x percent of the time'' and should be
stricter for certain data request types, such as for authorization or
account balance. Third parties also wanted quantified maximum scheduled
downtimes and minimum advance notice of such downtimes.
Data provider commenters opposed the CFPB's adoption of minimum
quantitative performance requirements. While not addressing current
actual interface performance under their extant data access agreements,
they asserted that the proposed 99.5 percent response rate would be too
onerous and would impose costs without commensurate consumer benefit,
particularly with respect to smaller providers that have fewer consumer
account holders and that today do not have any developer interfaces.
They also asserted that the proposed provisions underlying the response
rate--such as downtimes, notices thereof, and 3,500 millisecond
response times--were unclear and that the CFPB did not provide a
sufficient factual justification for them. They argued, for example,
that the CFPB needed to provide more specificity on how to measure an
interface's response time (e.g., when and how to calculate the
beginning and end of the response period) and on whether and how the
timeframe would apply to requests for large amounts of data where
transmission might take longer than the proposed 3,500 milliseconds.
They argued that to the extent the CFPB purported to justify the
measurements it proposed by pointing to other jurisdictions, those
other jurisdictions have different factual situations and are not
properly comparable for these purposes. In addition, they argued that
consensus standards should have no role in interface performance
requirements because standards' role has traditionally been achieving
interoperability, whereas the performance requirements do not pertain
to interoperability. One argued that the CFPB is effectively promoting
particular technologies, in contravention of CFPA section 1033(e), by
requiring specific performance standards for the developer interface.
Finally, they argued that the CFPA does not provide authority to adopt
the proposed quantitative specifications.
Final Rule
For the reasons discussed herein, the CFPB is finalizing the
quantitative minimum performance specification in proposed Sec.
1033.311(c)(1)(i), renumbered as Sec. 1033.311(c)(1), with certain
modifications. First, the final rule does not include a numeric
threshold for the time within which the interface must provide a
response in order for the time to be commercially reasonable. Instead,
the final rule (in Sec. 1033.311(c)(1)(iv)(C)) requires that a proper
response be provided within a commercially reasonable amount of time
and that indicia that the response time is commercially reasonable
include conformance to an applicable consensus standard. The CFPB
adopts this approach in the final rule because the proposed 3,500
millisecond response time may not adequately take into account the
variety of types and sizes of requests for covered data that data
providers' developer interfaces will receive. In addition, final Sec.
1033.311(c)(1) requires that the response rate be equal to or greater
than 99.5 percent ``in each calendar month,'' as opposed to the
proposed ``relevant time period, such as a month.'' The CFPB makes this
change for two reasons: first, to prevent a data provider from
calculating its developer interface's response rate over some other
time period, or varying the time period, to make appear better its
interface's response rate; and second, to align the calculation time
period with the calendar month disclosure time period in Sec.
1033.341(d).
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, which many data providers' developer
interfaces do not meet. With respect to uniformity, data from the
Provider Collection indicates 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. See 88 FR 74796, 74815-16 (Oct. 31, 2023). Accordingly, the
performance of data providers' developer interfaces needs both to
improve and to become more consistent and predictable from where that
performance is today.
The quantitative minimum 99.5 percent response rate requirement in
final Sec. 1033.311(c)(1) reflects the CFPB's determination that
developer interface performance beneath that level cannot constitute
commercially reasonable performance. The requirement ensures that data
providers' developer interfaces perform at a sufficiently consistent
and predictable level. The requirement implements CFPA section 1033(a),
which requires data providers to make covered data available in an
electronic form usable by authorized third parties, and ensures
consistent availability of covered data, while contemplating that
limited, unscheduled downtimes may occur.
The CFPB has determined that the quantitative minimum 99.5 percent
response rate is not too onerous. The minimum is in line with the
results reported to the CFPB through the Provider Collection. See 88 FR
74796, 74816 (Oct. 31, 2023). Further, based on public comments from
third parties and results reported to the CFPB through the Provider
Collection and the Aggregator Collection, the minimum is below levels
being achieved by larger data providers' developer interfaces today
pursuant to their data access agreements with third parties. That is
significant evidence that where a given data provider today has a
developer interface in place, it will be reasonably feasible for the
data provider's interface to continue to meet the quantitative minimum
performance requirement established by Sec. 1033.311(c)(1). It is
possible over time that part 1033 going into effect will itself lead to
an increased volume of data requests to larger data providers' extant
developer interfaces. Nonetheless, in the CFPB's assessment, it is
reasonably feasible for data providers to invest in and maintain their
developer interfaces in a manner such that the increased volume does
not degrade the interfaces' performance from their current levels,
which, as noted, are above the quantitative minimum established in
Sec. 1033.311(c)(1). The CFPB's establishment of the 99.5 percent
minimum response rate is based on the rulemaking record before it and
does not rely on required performance levels in other jurisdictions. As
the record demonstrates, the CFPB did consider other jurisdictions'
requirements and factual situations. However, the U.S. data sharing
market is differentiable from other jurisdictions (for example, the
U.S. has more depository institutions than is typical in other
jurisdictions) and the CFPB's legal authorities are of course specific
to U.S.
[[Page 90891]]
law. The CFPB's determination that interface performance beneath the
99.5 percent minimum cannot be commercially reasonable appropriately
reflects the rulemaking record, the U.S. data sharing market, and the
CFPB's authority.
The 99.5 percent response rate minimum is below levels commonly
achieved by data providers' consumer interfaces today, even for
consumer interfaces maintained by data providers with no developer
interface. As the CFPB noted in the proposed rule, data providers
through their consumer interfaces commonly make available an amount and
variety of data broader than the set of covered data that is subject to
part 1033. See 88 FR 74796, 74816 (Oct. 31, 2023). These facts indicate
that where a given data provider today has a consumer interface but
does not have a developer interface, it will be reasonable for the data
provider to implement a developer interface that meets the minimum
performance level required by Sec. 1033.311(c)(1). Moreover, the
minimum will not apply to small depository institution data providers,
because the final rule does not cover such depositories. All depository
institutions subject to the final rule appear to maintain a consumer
interface already and can reasonably implement a developer interface
that meets the final rule's minimum performance requirements. In that
regard, the final rule makes explicit that a data provider may be able
to satisfy its developer interface obligation, including the 99.5
percent response rate requirement, through contract with its service
provider under which the service provider screen scrapes covered data
from the data provider's consumer interface and makes the covered data
available to authorized third parties through a developer interface
that the service provider maintains on behalf of the data provider.
This type of approach can meaningfully reduce the burden of performance
requirements--including the quantitative minimum--through economies of
scale achieved by service providers.
The proper response definition in final Sec. 1033.311(c)(1)(iv)
underlies the required 99.5 percent response rate. The CFPB proposed
(in Sec. 1033.311(c)(1)(i)(D)) a proper response definition that
excluded ``any message such as an error message provided during
unscheduled downtime of the interface.'' The final rule (in Sec.
1033.311(c)(1)(iv)) excludes from the proper response definition ``any
message provided during unscheduled downtime of the interface.'' The
CFPB neither intends nor effectuates any change to the substance of the
proposed provision by omitting the clause ``such as an error message.''
Under the final rule, as under the proposal, the proper response
definition excludes any message provided during unscheduled downtime of
the interface.
The proper response definition does not require in every case that
covered data be returned. For example, assume a data provider has in
place reasonable access caps, which comply with Sec. 1033.311(d),
limiting the frequency with which the data provider receives and
responds to requests for covered data from an authorized third party
through its developer interface. Assume also the data provider has in
place reasonable written policies and procedures, which comply with
Sec. 1033.351(a), setting forth and describing such frequency
restrictions and setting forth and describing the explanations the data
provider's interface may provide for why a request to the interface was
not fulfilled. Further, assume that the interface receives a request in
excess of the documented reasonable frequency restrictions. Finally,
assume that the interface provides a response to that request that (1)
explains why the request was not fulfilled (in accord with Sec.
1033.311(c)(1)(iv)(A)), (2) is consistent with the reasonable Sec.
1033.351(a) policies and procedures (in accord with Sec.
1033.311(c)(1)(iv)(B)), and (3) is provided within a commercially
reasonable amount of time (in accord with Sec. 1033.311(c)(1)(iv)(C)).
That response is a proper response under Sec. 1033.311(c)(1)(iv) and
counts favorably toward the 99.5 percent response rate set forth in
Sec. 1033.311(c)(1).
The CFPB has determined that the quantitative minimum 99.5 percent
response rate in Sec. 1033.311(c)(1) is sufficiently robust and will
not result in a race to the bottom. Many smaller data providers that
today do not have a developer interface will be required by the final
rule to establish one. Section 1033.311(c)(1) establishes a necessary
and appropriate floor for developer interface performance in these
circumstances, beneath which interface performance cannot be
commercially reasonable. At the same time, and particularly with
respect to larger data providers, the CFPB emphasizes that the
quantitative minimum is not a safe harbor. That is, it does not follow
from a data provider's developer interface having met the quantitative
minimum that the interface has satisfied the requirement of
commercially reasonable performance established in Sec. 1033.311(c).
In addition to the quantitative minimum, Sec. 1033.311(c)(2),
discussed below, establishes indicia of what constitutes commercially
reasonable performance. Those indicia include comparisons of a data
provider's developer interface performance to consensus standards; to
the developer interface performance of other similarly situated data
providers, such as other larger data providers when the data provider
is a larger data provider; and, to the performance of the data
provider's consumer interface. These comparisons could indicate that a
data provider's developer interface performance, and particularly a
larger data provider's developer interface performance, is not
commercially reasonable even if the performance meets the quantitative
minimum. In other words, consideration of the indicia in Sec.
1033.311(c)(2) could result in a determination, by an examiner for
example, that a data provider's interface has not complied with the
commercially reasonable performance requirement established in Sec.
1033.311(c) notwithstanding that the interface met the quantitative
minimum in Sec. 1033.311(c)(1).
CFPA section 1021(b) states that the CFPA's objectives include,
among other things, authorizing the CFPB to exercise its authorities
under Federal consumer financial law, which includes CFPA section 1033,
to ensure that consumers, defined in CFPA section 1002(4) to include
consumers' authorized third party representatives, are provided with
timely and understandable information. In addition, the title of CFPA
section 1033 indicates that its objective is to establish a consumer
right to access information. The requirements of Sec. 1033.311(c)(1)
carry out these CFPA objectives by ensuring data providers respond to
consumers' authorized third party representatives upon request in a
manner that is commercially reasonable and that enables the
representatives to access covered data in a usable electronic form. The
requirements are consistent with the objective stated in CFPA section
1033(e) of not requiring or promoting a particular technology; a data
provider may use any technology or technologies it wishes so long as
its systems perform at the required level. Further, the rulemaking
record described in part II.A establishes that data providers'
competitive incentives do not align with those of authorized third
parties. In light of those differing incentives, the quantitative
minimum performance requirement in Sec. 1033.311(c)(1) is necessary
and appropriate to ensure covered persons do not avoid the requirement
to make
[[Page 90892]]
covered data available to authorized third parties through their
developer interfaces. Beneath that minimum, performance levels would
not be sufficient to enable effective realization of the CFPA's goals.
Indicia of Compliance (Sec. 1033.311(c)(2))
Proposal
The CFPB proposed in Sec. 1033.311(c)(1)(ii) two indicia of
whether performance of the interface is commercially reasonable. The
first was whether performance meets the applicable performance
specifications set forth in a qualified industry standard. The second
was whether the interface's performance meets the applicable
performance specifications achieved by the developer interfaces
established and maintained by similarly situated data providers. As
with the quantitative minimum discussed above, the CFPB proposed these
indicia pursuant to its preliminary determination that the performance
of data providers' developer interfaces should improve over time and
become more consistent and predictable. The CFPB requested comment on
whether additional indicia would be appropriate and, if so, what they
should be. The CFPB also requested comment on whether the final rule,
instead of referring broadly to ``applicable performance
specifications,'' should name and describe certain specifications, such
as the latency and uptime.
Comments
Data provider commenters opposed the indicia. They stated that the
requirement of commercially reasonable performance is sufficient and
appropriate in and of itself. They further argued that qualified
industry standards should not serve as indicia of commercially
reasonable performance because the general purpose of standards has
traditionally been interoperability and the level of developer
interface performance does not relate to interoperability. If qualified
industry standards were to serve for measuring commercially reasonable
performance, however, many data providers thought they should serve as
a safe harbor to give providers greater compliance certainty. They also
argued that the performance of similarly situated providers' interfaces
should not be among the indicia, because that would result in an ever-
spiraling-upward level of required performance. Moreover, they argued
that under the CFPB's proposed rule they would have no way to ascertain
the performance levels of similarly situated data providers' developer
interfaces because there would be no public source for that
information.
Third party commenters supported the indicia. They argued that the
indicia should reflect all metrics incorporated in the quantitative
minimum specification in proposed Sec. 1033.311(c)(1)(i) (discussed
above), such as response rate, response time, total downtime, total
scheduled downtime, and notice of downtime. They also argued that the
indicia of whether the interface meets the performance level of the
interfaces of other providers should be supported by a regulatory
disclosure mechanism for publicly reporting all of the metrics. This
disclosure requirement is discussed under Sec. 1033.341(d) below.
Final Rule
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.311(c)(1)(ii), renumbered as Sec. 1033.311(c)(2), with
modifications. Final Sec. 1033.311(c)(2)(i) adds a third indicia:
comparison to the performance of the data provider's consumer
interface. As a result, under final Sec. 1033.311(c)(2)(i), indicia
that a developer interface's performance is commercially reasonable as
required by Sec. 1033.311(c) include (1) whether the interface's
performance conforms to a consensus standard that is applicable to the
data provider; (2) how the interface's performance compares to the
performance levels achieved by the developer interfaces of similarly
situated data providers; and (3) how the interface's performance
compares to the performance levels achieved by the data provider's
consumer interface.
The CFPB proposed in Sec. 1033.311(c)(1)(ii) that these indicia
would be based on ``applicable performance specifications.'' In lieu of
the general reference to applicable performance specifications, final
Sec. 1033.311(c)(2)(ii) states that, for each of the above three
indicia, relevant performance specifications include: (1) the
interface's response rate as defined in Sec. 1033.311(c)(1) through
(c)(1)(iv) (discussed above); (2) the interface's total amount of
scheduled downtime; (3) the amount of time in advance of any scheduled
downtime by which notice of the downtime is provided; (4) the
interface's total amount of unscheduled downtime; and (5) the
interface's response time.\69\
---------------------------------------------------------------------------
\69\ Section 1033.341(d) (discussed below) requires data
providers to disclose each calendar month the response rates of
their developer interfaces; nothing in part 1033 precludes data
providers from reviewing such data to help them assess the
commercial reasonableness of their own performance.
---------------------------------------------------------------------------
The CFPB has determined that the specificity of final Sec.
1033.311(c)(2), relative to the proposed rule, gives sufficient clarity
to data providers for how commercial reasonability of developer
interface performance will be assessed. So long as developer interfaces
meet the quantitative minimum performance requirement in Sec.
1033.311(c)(1), it is necessary and appropriate for commercial
reasonability to be assessed against indicia that can take account of
changing technological advancements and other factors that may bear on
reasonableness in this context. By the same token, removing these
indicia references altogether would result in an insufficiently robust
and overly vague requirement.
It is appropriate for a consensus standard applicable to the data
provider to serve as one of the three indicia of whether the
performance of the data provider's developer interface is commercially
reasonable. Standards bodies and the participants therein have
expertise relevant to open banking issues, including but not limited to
developer interface performance. The CFPB fully expects there will be
give and take across industry participants in developing consensus
standards for commercially reasonable developer interface performance.
Consensus standards will serve as indicia, as relevant indicators,
thereof, but will not be determinative. The CFPB believes it is
appropriate for consensus standards to play this role.
It is also appropriate for the developer interface performance of
similarly situated data providers to serve as the second of the three
indicia. The CFPB believes that comparing interface performance to the
interfaces of other providers will not result in too onerous (or
unstable) a standard. Such performance is among other indicia, and does
not create a requirement to be better than peer performance. But to the
extent that performance lies outside that norm, that can fairly serve
as indicia that performance may lack commercial reasonableness. Black's
Law Dictionary defines ``commercially reasonable'' as ``conducted in
good faith and in accordance with commonly accepted commercial
practice.'' \70\ Article 4A of the Uniform Commercial Code states that
the commercial reasonableness of a security procedure is to be
determined by considering, among other things, ``security procedures in
general use by
[[Page 90893]]
customers and receiving banks similarly situated.'' UCC 4A-202(c).
---------------------------------------------------------------------------
\70\ Commercially reasonable, Black's Law Dictionary (12th ed.
2024).
---------------------------------------------------------------------------
The performance of the data provider's consumer interface also
serves appropriately as indicia of compliance. Data providers' consumer
interfaces today generally achieve a level of performance that is on a
par with the standards of commercial reasonability set forth in Sec.
1033.311(c). In light of the functionality of consumer interfaces,
their performance indicates that it is reasonable to expect developer
interfaces to perform at similar levels. In addition, as the
performance of consumer interfaces improves over time due to ongoing
technological advancements, that improvement and those advancements
will also indicate that it is reasonable for the performance of
providers' developer interfaces to improve similarly. With these
indicia, competitive pressure on consumer interface performance can
also help ensure that data providers appropriately maintain the
performance of developer interfaces, and do not allow that to revert to
some mean below the level of commercially reasonable performance.
Access Caps (Sec. 1033.311(d))
The CFPB proposed 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 its developer interface. In other words, the CFPB
proposed to permit a data provider to employ reasonable ``access
caps.'' The CFPB preliminarily determined that this would appropriately
effectuate data access rights by permitting the data provider to
prevent an authorized third party from unduly burdening the data
provider's interface and thereby negatively impacting its ability to
respond to requests from other authorized third parties. At the same
time, by prohibiting unreasonable caps, the proposed rule would have
prevented the data provider from unduly impeding the data access of
that authorized third party. The CFPB also proposed that access caps
must be applied in a non-discriminatory manner and consistent with the
reasonable written policies and procedures that the data provider
establishes and maintains pursuant to Sec. 1033.351(a). Finally, the
CFPB proposed that indicia that access caps are reasonable include that
they adhere to a qualified industry standard. The CFPB requested
comment on whether the final rule should differentiate between
``consumer present'' data requests, where the consumer is online with
the third party at the time of the request, versus other requests,
where the third party is refreshing the consumer's data without the
consumer being online at that time.
Many commenters addressed the proposed treatment of access caps.
Third party commenters generally opposed it as insufficient to prevent
data providers from using such caps for pretextual reasons. They argued
that a consumer is the one requesting data through an authorized third
party and that applying an access cap thereby harms the consumer. In
their view, the final rule should prohibit access caps by default and
require data providers to demonstrate the reasonableness of any
departure from that default.
Data provider commenters generally supported the CFPB's proposal.
One association representing small depository institutions argued that
the CFPB should finalize the provision as proposed. Some argued,
however, that data providers should have greater or total discretion to
impose access caps. One questioned the CFPB's authority to impose any
limit on such caps, asserting that automated batch requests from third
parties do not count as consumer ``requests'' under CFPA section
1033(a). A few argued that qualified industry standards should have no
bearing on the reasonability of an access cap, because standards to
date have not played such a role.
Some third party and some data provider commenters stated that it
would be appropriate for the CFPB's rule to distinguish between
consumer-present requests versus other requests. These commenters
stated that it would generally not be reasonable for a data provider to
impose any cap on consumer-present data requests, whereas it would, or
at least could, be reasonable in some circumstances for a data provider
to impose such limits on other requests. Some also noted that third
parties can and do address restrictions on consumer-not-present
requests by, for example, submitting requests at off-peak times.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.311(c)(2), renumbered as Sec. 1033.311(d), as proposed, but with
technical non-substantive edits for additional clarity. Reasonable
access caps help ensure that requests from one authorized third party
do not unduly burden the data provider's developer interface and
thereby impede its ability to respond to requests from other authorized
third parties. Barring unreasonable caps remains necessary to help
ensure that caps do not unduly impede an authorized third party's data
access.
Under the final rule, indicia of reasonableness include adherence
to a consensus standard on point. The CFPB believes that this provision
will appropriately incentivize industry participants--data providers
and third parties, including data aggregators--to work together towards
workable standards that can take account of evolving data access
technology and thereby provide a useful and enduring compliance
resource. At the same time, such standards do not unduly restrict data
providers because they do not represent regulatory requirements.
On the basis of its own expertise and feedback from commenters of
all types that access caps on consumer-present data requests would be
detrimental to consumers and to the financial products and services
that consumers are using or seek to use, the CFPB observes that access
caps on consumer-present data requests generally will be unreasonable
and that reasonable access caps will be confined to other requests such
as ``batch'' requests--although that confinement is not enough, alone,
to make them reasonable.\71\ Consumer presence indicates that the
failure to provide a response promptly would have an immediate harmful
effect on the consumer, especially if a consumer were enrolling in a
new product or service for the first time, such that access caps would
be unreasonable for this type of request, at least in the absence of
some exceptional justification specific to the facts at hand. Industry
participants continue to work to ensure interface availability for
consumer-present requests by implementing adjustments on consumer-not-
present requests. Accordingly, permitting reasonable access caps, with
consensus standards being indicia thereof, will encourage continued
industry progress toward appropriate differentiation between consumer-
present and consumer-not-present requests.
---------------------------------------------------------------------------
\71\ Contrary to some commenter assertions, the CFPB has the
statutory authority to address access caps imposed on consumer-not-
present requests, such as batch requests. The CFPA defines
``consumer'' to include consumers' representatives, such as
authorized third parties. That a data request comes from an
authorized third party, as opposed to from an individual consumer,
accordingly has no bearing on whether the submission qualifies as a
``request'' as that term is used in CFPA section 1033. Similarly,
that section does not differentiate between batched and non-batched
consumer requests for data.
---------------------------------------------------------------------------
Security Specifications (Sec. 1033.311(e))
Access Credentials (Sec. 1033.311(e)(1))
The CFPB proposed in Sec. 1033.311(d)(1) to prohibit a data
provider from allowing third parties to access its developer interface
by using any credentials that a consumer uses to access the consumer
interface. The
[[Page 90894]]
proposal explained that the possession and use of consumer credentials
by third parties, such as through credential-based screen scraping,
raises significant security, privacy, and accuracy risks to consumers
and to the market for consumer-authorized data access. For example,
consumers whose credentials are exposed in a third party data breach
might suffer invasions of privacy or financial harms. The proposal
covered funds-storing and payment accounts, so stolen credentials could
enable bad actors to cause unauthorized transactions or fraudulent use
of consumers' personal financial data. The proposal also explained that
credential-based screen scraping posed challenges to risk-management,
including the difficulty of distinguishing legitimate from illegitimate
access attempts.
The CFPB requested feedback on two specific issues. First, the CFPB
asked about arrangements in which a third party procures the consumer's
authority to access data, then ``passes'' the consumer directly to the
data provider, which then authenticates the consumer using the
consumer's digital banking credentials, before ultimately providing the
third party with a secure access token. Second, the CFPB asked about
situations in which a third party acts as both a third party and a
service provider that develops and maintains a developer interface on
behalf of a data provider.
Although the proposal would have prevented data providers from
using credential-based screen scraping to comply with their developer
interface requirements, the proposal did not explicitly state whether
data providers could block screen scraping. The proposal noted that
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.
The CFPB received several comments on proposed Sec.
1033.311(d)(1). Numerous commenters compared APIs to screen scraping in
discussing proposed Sec. 1033.311(d)(1). These commenters were nearly
unanimous in stating that APIs have advantages over screen scraping in
accuracy, consumer privacy, and data security. For example, a trade
association commenter stated that APIs are created to limit access to
specifically authorized consumer data, which prevents third parties
from accessing unnecessary consumer data. Other commenters stated that
high-volume screen scraping can impact the availability of financial
institution consumer-facing websites. However, a few credit union
commenters stated that APIs introduced security risks that could allow
bad actors to compromise consumers' accounts. And a community bank
trade association commenter said that discouraging screen scraping in
favor of developer interface requirements could violate CFPA section
1033(e)'s provision regarding ``require[ing] or promot[ing] the use of
any particular technology in order to develop systems for compliance.''
A data aggregator commenter asked for confirmation that consumer
credentials may be used in access portals that redirect consumers to
enter credentials on the data provider's website. Another data
aggregator commenter asked the CFPB to allow arrangements in which
third parties provide information sufficient for the data provider to
authenticate the consumer rather than having data providers directly
authenticate the consumer themselves. Another data aggregator commenter
said that existing data access agreements that allow for credential-
based access should be permitted while data providers establish their
developer interfaces. A group of industry commenters and an academic
institution requested clarity on whether existing data access
connections would need to be re-established.
Several data providers and data provider trade association
commenters asked the CFPB to authorize data providers to block screen
scraping. One commenter stated that data providers should be required
to take reasonable steps to prevent screen scraping once they have
established developer interfaces. These commenters echoed many of the
security, privacy, and accuracy risks of screen scraping discussed in
the proposal. A few of these commenters asked whether data providers
were obligated to permit screen scraping if their developer interfaces
failed to meet the final rule's performance standards. One data
provider commenter asked how data providers should treat screen
scraping of non-covered data.
The CFPB is renumbering proposed Sec. 1033.311(d)(1) as Sec.
1033.311(e)(1) and finalizing the substance of the provision largely as
proposed for the reasons discussed herein, with additional clarity
regarding service providers. Final Sec. 1033.311(e)(1) provides that a
data provider must not allow a third party to access the data
provider's developer interface by using any credentials that a consumer
uses to access the consumer interface. Final Sec. 1033.311(e)(1) also
provides that a contract between a data provider and the data
provider's service provider, pursuant to which the service provider
establishes or maintains the data provider's developer interface, does
not violate Sec. 1033.311(e)(1) if the contract provides that the
service provider will make covered data available, in a form and manner
that satisfies the requirements of part 1033, to authorized third
parties through the developer interface by means of the service
provider using a consumer's credentials to access the data from the
data provider's consumer interface.
As discussed in the proposal, credential-based screen scraping
creates risks to consumer privacy, accuracy, and data security, and
poses challenges to data providers' systems. A core objective of the
final rule is to transition the market away from using screen scraping
to access covered data. Final Sec. 1033.311(e)(1) supports this goal
by preventing data providers from relying on a third party's use of
consumer credentials to access the developer interface.
The CFPB disagrees with the suggestion that final Sec.
1033.311(e)(1) risks inappropriately promoting any particular
technology. Final Sec. 1033.311(e)(1) sets forth a requirement
regarding the use of consumer credentials to access the developer
interface, but it allows data providers to use any technology in
designing their developer interfaces.
Entities that act as service providers to data providers may, on
behalf of those data providers, develop, deploy, and maintain developer
interfaces whose technical specifications and requirements entail those
service providers retaining and using consumers' credentials. Final
Sec. 1033.311(e)(1) does not restrict a data provider from allowing
its own service provider that develops, deploys, or maintains the data
provider's developer interface to use or possess consumer credentials
to facilitate the provision of covered data to a consumer, even if the
data provider's service provider also operates as an authorized third
party. The final rule clarifies this point by stating in Sec.
1033.311(e)(1) that a contract between a data provider and the data
provider's service provider, pursuant to which the service provider
maintains the data provider's developer interface, does not violate
Sec. 1033.311(e)(1) if the contract provides that the service provider
will make covered data available, in a form and manner that satisfies
the requirements of part 1033, to authorized third parties through the
developer interface by means of the service provider using a consumer's
[[Page 90895]]
credentials to access the data from the data provider's consumer
interface.
The central factor in analyzing various arrangements between data
provider and third party for providing access through the developer
interface is whether the third party uses consumer credentials to
access the developer interface. For example, a third party might
procure the consumer's authority to access data, then ``pass'' the
consumer directly to the data provider, which then authenticates the
consumer using the consumer's consumer interface credentials. This
arrangement would not violate final Sec. 1033.311(e)(1) because the
authorized third party itself never accesses, uses, or retains the
consumer's credentials. But if a third party such as a data aggregator
sought to access or retain consumer credentials as a service to support
access to consumer permissioned data by a variety of additional third
parties, such an arrangement would violate final Sec. 1033.311(e)(1)
because the third party itself accesses and retains the consumer's
credentials.
Nothing in the proposal would have precluded data providers from
blocking screen scraping, and nothing in the final rule does so.
However, data providers may act improperly if they attempt to block
screen scraping across the board without making the requested data
available through a more secure alternative. Depending on the facts and
circumstances, such interference with the consumer's ability to share
their personal financial data may violate the CFPA's prohibition on
acts or practices that are unfair, deceptive, or abusive. However, if a
data provider has established a developer interface that complies
with--or in markets not yet covered by this final rule, conforms to--
the requirements of this final rule, then blocking screen scraping may
further consumer privacy and data security while ensuring that
consumers are able to authorize access to their financial data in a
manner that is safe, secure, reliable and promoting of competition.
Regarding third parties with prior arrangements that relied on
credential-based access, once data providers have enabled the safe,
secure, and reliable forms of data access envisioned in this rule, the
CFPB cautions that screen scraping attempts by third parties to reach
data covered by such arrangements could well be limited by the CFPA's
prohibition on unfair, deceptive, or abusive acts or practices. 12
U.S.C. 5531.
Security Program (Sec. 1033.311(e)(2))
Proposed Sec. 1033.311(d)(2)(i) would have required data providers
to apply to their developer interfaces an information security program
that satisfies the applicable rules issued pursuant to section 501 of
the GLBA, 15 U.S.C. 6801. Under proposed Sec. 1033.311(d)(2)(ii), a
data provider that is not subject to section 501 of the GLBA would have
been required to apply to its developer interface the information
security program required by the FTC's Standards for Safeguarding
Customer Information, 16 CFR part 314. The CFPB preliminarily
determined that the GLBA Safeguards Framework appropriately addresses
data security risks for developer interfaces in the market for
consumer-authorized financial data. The CFPB requested comment as to
whether a general policies-and-procedures requirement would be more
appropriate than the GLBA Safeguards Framework.
In the proposal, the CFPB noted that 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 GLBA Safeguards
Framework. The CFPB noted the GLBA Safeguards 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. The proposal noted that this flexible, risk-based
approach allows the GLBA Safeguards Framework to adapt to changing
technology and emerging data security threats.
Many commenters from different interest groups supported this use
of the GLBA Safeguards Framework. One data provider commenter stated
that the GLBA Safeguards Framework would ensure consistent data
security standards for all ecosystem participants. Additionally, one
consumer advocate commenter said the proposed rule would close gaps in
data security coverage. On the other hand, some data provider
commenters opposed the use of the GLBA Safeguards Framework on the
grounds that the data providers are already subject to data security
requirements. Additionally, some commenters pointed out that the FTC's
Safeguards Rule was not identical to prudential regulators' Safeguards
Guidelines and is not subject to FTC supervision. Specifically,
commenters were concerned that the FTC lacks supervisory authority and
cannot examine institutions under its jurisdiction for compliance with
its Safeguards Rule.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.311(e)(2) as proposed. As such, under Sec. 1033.311(e)(2)(i), a
data provider must apply to the developer interface an information
security program that satisfies the applicable rules issued pursuant to
section 501 of the GLBA, 15 U.S.C. 6801. Alternatively, under Sec.
1033.311(e)(2)(ii), if the data provider is not subject to section 501
of the GLBA, the data provider must apply to its developer interface
the information security program required by the FTC's Standards for
Safeguarding Customer Information, 16 CFR part 314.
The CFPB has determined that the GLBA Safeguards Framework will
best mitigate information security weaknesses within open banking
transactions. The flexible nature of the Safeguards approach allows
data providers some discretion in how they protect customers from
emerging threats to their data. As noted in the proposal, the FTC's
Safeguards Rule includes slightly more prescriptive requirements, such
as encryption, for certain elements, because the Safeguards Rule must
be usable by a financial institution to determine appropriate data
security measures without regular interaction with an examiner from a
supervising agency.
Additionally, subjecting data providers to the GLBA Safeguards
Framework is not a duplicative requirement on data providers. The
Safeguards Framework allows information security programs to adapt to
risks specific to the developer interface. Without this provision and
its specific application to the developer interface, it is not clear
consumers would have the same protection over their data across
different types of data provider entities. Further, the CFPB needs to
be able to adequately supervise data providers for their data security
compliance. Private rules such as NACHA data security requirements or
Payment Card Industry Data Security Standards require a private entity
to determine what conduct complies with the rule without oversight from
the CFPB. Conversely, the GLBA Safeguards Framework provides a
consistent, yet flexible approach that is not dictated by a private
entity.
Section 1033.311(e)(2) implements CFPA section 1033(a) by
clarifying how a data provider must make available data upon request to
a consumer, including an authorized third party. Establishing a
consistent set of data security requirements will help ensure that
developer interfaces are only
[[Page 90896]]
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)
The CFPB proposed in Sec. 1033.321 to 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). The proposal
explained that 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.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.321 with several changes designed to clarify the operation of each
paragraph, reduce the risk of unjustified denials, and reduce the
burden on data providers of assessing third party risks. As discussed
in greater detail below, final Sec. 1033.321(a) generally provides
that a data provider does not violate the general obligation in Sec.
1033.201(a)(1) by denying a consumer or third party access to all
elements of the interface described in Sec. 1033.301(a) if granting
access would be inconsistent with policies and procedures reasonably
designed to comply with legal requirements described in Sec.
1033.321(a)(1)(i) through (iii), and if the denial is reasonable
pursuant to Sec. 1033.321(b). Final Sec. 1033.321(b) describes
requirements that a denial must meet to be reasonable. Final Sec.
1033.321(c) lists indicia bearing on the reasonableness of a denial
pursuant to Sec. 1033.321(b). And final Sec. 1033.321(d) provides
conditions that are each a sufficient basis for denying access to a
third party.
Denials Related to Risk Management (Sec. 1033.321(a))
Proposal
Proposed Sec. 1033.321(a) generally would have provided that a
data provider could deny a consumer or third party access to its
consumer or developer interface based on risk management concerns.
Specifically, the proposal provided that, subject to a reasonableness
standard described in proposed Sec. 1033.321(b), a denial is not
unreasonable if it is necessary to comply with the section 39 of the
Federal Deposit Insurance Act or section 501 of the GLBA.
In proposing to allow data providers to deny access based on risk
management concerns, the CFPB recognized that depository institutions
have legal obligations to operate in a safe and sound manner, and both
depository and nondepository institutions have other information
security-related obligations.\72\ The prudential regulators have issued
supervisory guidance that sets forth risk management principles and
other considerations that depository institutions can leverage when
developing and implementing risk management practices. For example, in
2023 the prudential regulators issued the Interagency Guidance on
Third-Party Relationships: Risk Management.\73\ The proposal also
recognized that consumers might suffer harm if the final rule did not
allow data providers to deny a third party access to the data
provider's developer interface where the data provider has legitimate
risk management concerns. Indeed, the proposal stated that 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 safety and soundness or information security. At the same
time, the CFPB expressed concern about risk management being used to
frustrate a consumer's right to access data under CFPA section 1033,
and about incentives that data providers might have to deny access.
Proposed Sec. 1033.321 was intended to accommodate these
considerations.
---------------------------------------------------------------------------
\72\ See, e.g., 12 U.S.C. 1831p-1; Interagency Guidelines
Establishing Standards for Safety and Soundness, 12 CFR part 30,
app. A (OCC), 12 CFR part 208, app. D-1 (Bd. of Governors of the
Fed. Rsrv. Sys.); and 12 CFR part 364, app. A (FDIC).
\73\ 88 FR 37920 (June 9, 2023). See also Bd. of Governors of
the Fed. Rsrv. Sys., FDIC, OCC, Third-Party Relationships: A Guide
for Community Banks (May 2024), https://occ.gov/news-issuances/news-releases/2024/pub-third-party-risk-management-guide-for-community-banks.pdf; Bd. of Governors of the Fed. Rsrv. Sys, FDIC, OCC,
Conducting Due Diligence on Financial Technology Companies A Guide
for Community Banks, (Aug. 2021), https://www.occ.gov/news-issuances/news-releases/2021/nr-ia-2021-85a.pdf.
---------------------------------------------------------------------------
The proposal also sought to illuminate various aspects of proposed
Sec. 1033.321's operation. For example, the CFPB generally described
denials of access as applicable to third parties or consumers, rather
than to specific data fields requested by third parties or consumers.
This was because, in the CFPB's view, third parties are in the best
position to determine what covered data are reasonably necessary to
provide the consumer's requested product or service. See 88 FR 74796,
74823 (Oct. 31, 2023). And the CFPB explained that the exceptions under
CFPA section 1033, set forth in proposed Sec. 1033.221, generally
would not be appropriate for data providers to use to address risk
management concerns. See 88 FR 74796, 74820 (Oct. 31, 2023).
The CFPB requested comment on additional ways to harmonize the risk
management obligations of data providers with CFPA section 1033's data
access right for consumers and authorized third parties. The CFPB also
requested comment on the extent to which CFPB rules or guidance, or
other sources, should address whether a data provider's denial of third
party access to a developer interface under Sec. 1033.321(a) would be
reasonable with respect to any particular risk management practices.
Comments
The CFPB received numerous comments on this proposed provision.
Several commenters, mostly data providers and data provider
associations, said the proposal properly incorporates third party risk
management principles to third party access. Many data provider
commenters asserted that their prudential regulators expect a
relatively high degree of vetting of third parties accessing data with
consumer authorization. Several data provider commenters, and a
research institute commenter, stated that third party risk management
obligations applied even to third party relationships not initiated by
the data provider.
Although these commenters generally supported allowing data
providers to deny access to third parties, most were concerned that the
proposed grounds for reasonable denials might be too narrow. For
example, several data provider trade association commenters sought
clarification that reasonable grounds for denying access would include
concerns over fraud, reputational risk, or safety and soundness.
Some of these commenters stated that safety and soundness risks
might be raised by the volume of data requested by a third party, by an
unmanageable pace in onboarding third parties, or by third parties with
insufficient financial resources to reimburse the data provider for
unauthorized transfers. Several data providers and trade association
commenters said that data providers reasonably should be able to deny
access consistent with interagency guidance on third party risk
management. Several commenters stated that data providers should be
able to
[[Page 90897]]
deny access based on the conduct of the third party, such as its data
minimization practices, its compliance with EFTA and Regulation E, the
content of its privacy policies, and its ability to manage downstream
data recipients. Several commenters asked the CFPB to provide that a
third party's refusal to agree to reasonable risk-related contractual
terms would justify denying access. A group of data provider trade
association commenters asked for guidance related to international
third parties, and one trade association commenter stated that
communicating denial reasons to a third party on an OFAC sanctions list
might require a data provider to violate the law. A trade association
commenter asked for general examples of reasonable and unreasonable
denials, and a bank commenter asked for clarification that data
providers may deny access to data aggregators. A bank commenter stated
that the rule should clarify that the obligation on data providers to
make covered data available to authorized third parties would apply
only for authorized third parties domiciled in the U.S. The commenter
stated that third parties that are not domiciled in the U.S. may be
subject to different privacy or data protection laws and that sharing
data with such entities could undermine consumer protections and
complicate risk management and liability.
Many data providers and data provider trade association commenters
stated that the proposed rule appeared to contemplate a level of
vetting of third parties that is infeasible. These commenters stated
that data providers could be overwhelmed by the number of third parties
attempting to access consumer data and would lack the resources to vet
each third party to the degree required for service providers.
These commenters recommended that the final rule include various
changes to reduce the burden of vetting third parties. Several data
providers and data provider trade association commenters stated that
the rule should provide a safe harbor for data providers who grant
access to third parties making representations of their data security
practices. Other data provider commenters requested safe harbor from
liability for any harm caused by third parties. A few commenters stated
that data providers should be allowed to negotiate data access
agreements with provisions governing indemnification, insurance, and
other risk-related terms. Two commenters stated that data providers
should be given a reasonable period of time to vet third parties.
Finally, several commenters said that the CFPB should supervise data
aggregators and third parties, which would reduce the perceived risk of
third parties.
In contrast, other commenters, including many third parties, and a
few consumer advocates and research organizations, stated that the
proposal improperly suggests that data providers should vet third
parties as if they were service providers. Unlike other third party
relationships, these commenters said, in the context of consumer-
authorized data sharing, a third party is operating as the consumer
rather than providing services to the data provider. A data aggregator
commenter stated that data providers' interests were often opposed to
the interests of third parties, which incentivized denying access.
These commenters requested the final rule include additional
changes designed to reduce the risk that data providers deny access on
illegitimate grounds or otherwise impair consumer-authorized data
access. Specifically, a research institute commenter stated that the
rule should accommodate existing data access methods that are similar
to the final rule's requirements so that data providers do not block
them once the final rule takes effect. A few commenters recommended
requiring data providers to use a standardized risk assessment method.
One third party commenter stated that denials should be justified by
policies and procedures that have been approved by the data provider's
prudential regulator. A few of these commenters recommended prohibiting
data access agreements between data providers and third parties
because, they said, such agreements increase transaction costs and
create inconsistent demands on third parties. Some of these commenters
recommended changes related to the transparency of denials, such as
requiring data providers to disclose information about their denials or
the performance of their developer interfaces. Some commenters
recommended changes to the process of onboarding, such as requiring
data providers to operate in good faith, creating a presumption that
delays in granting access of greater than two months violate the final
rule, and requiring data providers to grant access once a third party
has established a remediation plan for any risk identified by a data
provider. Finally, a few commenters said that third parties and
consumer advocates should be allowed to formally dispute any denials of
access by reporting them to the CFPB.
Many types of commenters, including third parties and data
providers, asked the CFPB to coordinate with the prudential regulators
on risk management issues. Some of these commenters asked for guidance
specific to consumer-authorized data access, while others offered
specific suggestions. Several third parties and research institute
commenters stated that the CFPB and prudential regulators should
clarify that risk management for authorized third parties is limited to
data security or that the agencies' third party risk management
guidance is inapplicable. A data provider and a trade association
commenter stated that the FFIEC should identify an accreditation
standard for third party information security. One bank commenter
stated that the CFPB should provide guidance on risk management for
data providers not subject to prudential regulation. Two commenters
recommended that the agencies provide guidance stating that Regulations
E and Z sufficiently address liability for any harms resulting from
third party data access. Two commenters asked the CFPB and the
prudential regulators to develop a process for resolving any potential
conflicts between the final rule and prudential standards.
Final Rule
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.321(a) with certain substantive, clarifying, and organizational
changes. Final Sec. 1033.321(a) provides that a data provider does not
violate the general obligation in Sec. 1033.201(a)(1) by denying a
consumer or third party \74\ access to all elements of the interface
described in Sec. 1033.301(a) if: (1) granting access would be
inconsistent with policies and procedures reasonably designed to comply
with: (i) safety and soundness standards of a prudential regulator, as
defined at 12 U.S.C. 5481(24), of the data provider; (ii) information
security standards required by section 501 of the GLBA, 15 U.S.C. 6801;
or (iii) other applicable laws and regulations regarding risk
management; and (2) the denial is reasonable pursuant to Sec.
1033.321(b).
---------------------------------------------------------------------------
\74\ Regarding comments asking whether a data provider may deny
access to a data aggregator, the term ``third party'' is defined in
the final rule to include data aggregators.
---------------------------------------------------------------------------
As discussed in the proposal, the CFPB recognizes that data
providers have obligations regarding risk management. For example,
depository institutions must operate in a safe and sound manner in
compliance with applicable laws and regulations. And depository
institutions and other data providers subject to the GLBA must ensure
the security of the customer
[[Page 90898]]
information that they collect and maintain. A final rule that compels
data access regardless of these other legal obligations would create
risks to data providers and consumers. But the CFPB also understands
that data providers face some competitive incentives to deny access to
third parties in ways that could threaten a consumer's right to access
their data under CFPA section 1033.
The CFPB has made several changes to clarify the operation of the
different elements in Sec. 1033.321(a). First, the CFPB has revised
aspects of the general standard proposed in Sec. 1033.321(a).
Specifically, the proposed rule referred to denials ``based on risk
management concerns'' but did not specify the nature of these concerns
or the meaning of denying access ``based on'' these concerns.
Commenters also sought clarity about the relationship between the
authorities cited in proposed Sec. 1033.321(a) and the section's
general term for risk management obligations.
Final Sec. 1033.321(a) has been restructured to clarify that
safety and soundness standards and information security standards are
two legal requirements that might justify denying access, rather than
specify an exhaustive list of grounds for denial. The CFPB has modified
the proposed description of safety and soundness by removing the
reference to section 39 of the Federal Deposit Insurance Act. This
change reflects the fact that safety and soundness standards originate
from a broader array of legal authorities and avoids implying that
banks and savings associations are the only depository institutions
with safety and soundness obligations. The final rule provides these
specific examples because the CFPB understands that they are especially
relevant to decisions regarding third party access. But final Sec.
1033.321(a)(2)(iii) also provides a catchall provision for other
applicable laws and regulations regarding risk management to make clear
that obligations regarding risk management may be found in other
sources, including those raised by commenters. For example, denials may
be justified by a third party's presence on a list released by OFAC,
such as the Specially Designated Nationals and Blocked Persons
list,\75\ or by requirements to prevent money laundering and terrorist
financing under the Bank Secrecy Act and the Corporate Transparency
Act. See 31 U.S.C. 5311, 5336. This catchall provision also ensures
that data providers that are not supervised by the prudential
regulators are able to deny access when warranted under the rule.
---------------------------------------------------------------------------
\75\ Off. of Foreign Asset Control, U.S. Dep't of Treas.,
Sanctions List Service, https://ofac.treasury.gov/sanctions-list-service (last visited Oct. 16, 2024).
---------------------------------------------------------------------------
In response to commenters who requested the ability to deny access
using guidance issued by the prudential regulators, the CFPB has
determined that denials must ultimately be grounded in legal
requirements. The final rule implements consumers' data access rights
in a binding, enforceable regulation. Failure to ground a denial in
another legal obligation could allow non-binding, unenforceable
guidance to override the final rule, which would frustrate Congress's
purposes in enacting CFPA section 1033. The obligations enumerated in
Sec. 1033.321(a)(1)--safety and soundness standards, information
security standards, and other laws and regulations regarding risk
management--are all binding, enforceable legal requirements. However,
the CFPB understands that data providers develop and apply risk
management policies and procedures to support their compliance with
underlying statutes and regulations, an exercise that may be informed
by non-binding guidance, among other sources. To reflect the role of
policies and procedures and avoid excessively restricting the sources
of information relevant to compliance, final Sec. 1033.321(a)(1)
refers to ``policies and procedures reasonably designed to comply
with'' legal requirements. The CFPB assesses that these changes answer
many of the questions raised by commenters regarding the types of risks
covered by Sec. 1033.321(a), whether specific references to
authorities are illustrative or exhaustive, and how agency guidance
relates to denial decisions.
Final Sec. 1033.321(a)(1) also provides that a denial is justified
if granting access would be ``inconsistent'' with policies and
procedures ``reasonably designed'' to comply with the enumerated legal
requirements. In using the term ``necessary'' in reference to specific
statutory obligations, the proposed rule could have been read to apply
a strict necessity standard to risk management obligations that a data
provider might use to justify a denial. The CFPB has determined that a
different approach is more appropriate to the nature of risk
management. The CFPB understands that requirements to avoid unsafe or
unsound practices and threats to the security of customer information
generally are not defined with precision. Instead, they are evaluated
based on constantly changing factual circumstances and managed by
programs that are flexible enough to consider various factors.
The final rule's approach is intended to account for the
flexibility and discretion that data providers exercise in designing
and implementing policies and procedures regarding risk management. In
the context of consumers' data access rights, the CFPB has determined
that it is appropriate for data providers to exercise this discretion
by attempting to grant access unless doing so would be inconsistent
with reasonably designed policies and procedures. Whether a denial is
the result of policies and procedures that are ``reasonably designed''
will depend on the circumstances. If a data provider identifies a risk
that might call for denying access to a third party, it must
effectively consider how those policies and procedures can tailor any
restriction on data access to the risk presented. In analyzing the
extent of the risks presented by the third party, the data provider
should take into account the fact that a consumer will have authorized
the third party to access data, or that certain risks are mitigated by
operation of part 1033. Policies and procedures would not be reasonably
designed, for instance if they do not account for the protections of
subpart D of this rule that address a third party's potential use of
consumer-authorized data. In evaluating for whether policies and
procedures are reasonably designed, the CFPB will closely evaluate
whether the data provider has effectively considered how to avoid
burdening the CFPA section 1033 access right while also complying with
applicable laws and regulations regarding risk management. Policies and
procedures will not be ``reasonably designed'' for purposes of Sec.
1033.321(a)(1) if their design does not take account of whether
alternative practices would be comparably effective but less burdensome
to the CFPA section 1033 access right.
The final rule also separately enumerates the reasonableness
element of a denial from the other requirements justifying the denial.
Under final Sec. 1033.321, a denial would have to be justified by at
least one of three legal requirements provided in Sec. 1033.321(a)(1)
and would have to be reasonable pursuant to Sec. 1033.321(a)(2). The
reasonableness element in Sec. 1033.321(a)(2) is elaborated on in
Sec. 1033.321(b), which provides requirements for reasonable denials.
Final Sec. 1033.321(a) also adds the new phrase ``all elements of ''
the interface described in Sec. 1033.301(a). This change better
reflects the fact that denials of access under Sec. 1033.321 involve a
[[Page 90899]]
denial of access in its entirety. A denial would not be appropriate if
it applied only to certain aspects of the developer interface, or only
to certain data fields, because it would not affect ``all elements'' of
the interface. As stated in the proposal, the CFPB has determined that
consumers and third parties are in the best position to know which
covered data fields are reasonably necessary to provide a requested
product or service. Similarly, a denial would not be reasonable if it
were based on the volume of data a third party requested to provide the
consumer's requested product or service. Concerns over the volume of
data requested are appropriately addressed by final Sec. 1033.311(d),
which provides data providers flexibility regarding the frequency with
which they receive or respond to requests for covered data, subject to
certain limitations.
Final Sec. 1033.321 does not require data providers to vet third
parties. Instead, it recognizes that data providers will need to take
account of their risk management obligations in this context. Several
comments seemed premised on the existence of tension between granting
third parties access to data with consumer authorization and managing
risk. In general, the CFPB views data providers' risk management
practices as fundamentally compatible with CFPA section 1033's data
access obligations. Indeed, the final rule is designed to enable data
access in a safe and secure manner, which will align the final rule
with prudential imperatives. But in cases where a data provider's legal
requirements regarding risk management would call for denying access,
final Sec. 1033.321 prevents data providers from having to choose
between conflicting legal responsibilities.
The CFPB offers several additional points in response to comments
regarding situations that might justify a denial. First, denials would
be unjustified if they are based solely on a data provider's policies
and procedures that override the substantive protections found in the
final rule, such as asserting that the authorization procedures and
obligations for third parties seeking to access covered data on
consumers' behalf are insufficient. See part IV.D below. Depending on
the circumstances, such a denial could be the result of policies and
procedures that are not reasonably designed under Sec. 1033.321(a)(1),
or it could be unreasonable under Sec. 1033.321(a)(2). The final rule
provides a means for consumers to effectuate their right under CFPA
section 1033 to authorize access to their covered data. And the final
rule contains numerous provisions that the CFPB has determined will
allow consumers to realize the benefits of data access while ensuring
that third parties are acting on behalf of consumers. Denying access
because a third party intends to follow the final rule's protections
rather than a data provider's alternative protections would infringe on
a consumer's data access rights. For example, it would be unreasonable
for a data provider to deny access because a third party refuses to
comply with a secondary use limitation that forbids the third party
from using covered data to improve the product or service the consumer
requested, as permitted under final Sec. 1033.421(c). Similarly, it
would be unreasonable for a data provider to deny access because a
third party's certification statement reflects the fact that it is
subject to the GLBA Safeguards Rule rather than the interagency
Safeguards Guidelines.
Second, the CFPB intends for final Sec. 1033.321 to give data
providers sufficient flexibility to manage the onboarding of third
parties. The CFPB understands that data providers may need to onboard
third parties in a staggered manner, and that failure to manage this
process could incapacitate data providers' systems and the security of
consumers' data. Accordingly, denying access to a third party until it
can be properly onboarded may be necessary to comply with a data
provider's legal obligations regarding risk management. Moreover, as
described in part I, most third party access is currently achieved
through the use of data aggregators. The CFPB anticipates that this
arrangement will continue for the immediate future, which should reduce
any implementation burden on data providers associated with the volume
of third party requests. Regarding onboarding third parties that are
not domiciled in the U.S., final Sec. 1033.321 gives data providers
appropriate flexibility to deny access based on risk management
obligations.
Regarding data access agreements, the final rule does not prohibit
specific contractual arrangements. A blanket prohibition on such
agreements would be unjustified because they may be a valid tool for
managing risk. But denials based on failure to agree to certain
arrangements would need to satisfy the requirements of final Sec.
1033.321. For the same reason, the CFPB declines to create either
express regulatory authorization for or prohibition against onboarding
arrangements that seek third parties' assumption of particular
allocations of liability. Similarly, the CFPB declines to create
regulatory authorization for or prohibition against similar terms
seeking specific warranties of insurance associated with such
allocations. The same principles regarding denials under final Sec.
1033.321 apply to denials in this context as well. If ``required''
onboarding arrangements are impermissible under final Sec. 1033.321, a
refusal to enable interface access would be improper. If such
arrangements are permissible under final Sec. 1033.321, a refusal to
accept them can justify a denial of access.
Given the range of situations involving consumer-authorized data
access, these principles do not yield simple one-size-fits-all
requirements such as ``all liabilities run with the data'' or ``no
liability allocation can be reached in onboarding agreements.'' In
response to the range of comments provided, however, the CFPB is
providing additional guidance here as to onboarding arrangements that
it considers more likely to raise concerns under Sec. 1033.321.
First, a data provider seeking to onboard a third party to a
developer interface in accordance with obligations under this rule and
under applicable risk management requirements is not engaged in an
arms-length commercial transaction. As a result, any exertion of market
power in seeking particular terms in an onboarding arrangement will
raise significant concerns about the permissibility of a denial under
Sec. 1033.321. In this context, any arrangements not related to the
effective implementation of this rule and associated risk management
requirements would need to ensure they do not violate CFPA section 1033
or the anti-evasion provision of Sec. 1033.201(a)(2).
Second, the CFPB also would have concerns under Sec. 1033.321 if
data providers demand arrangements that would effectively relieve them
of their own obligations to follow the law. Such arrangements may
indicate the data provider is not motivated by legal compliance, and
such arrangements are likely not directly related to a specific risk
presented by the third party. The potential liabilities that commenters
raised, as a general matter, are provided for under applicable law,
including existing law on how such liabilities may be allocated. To the
extent that data providers and third parties are seeking to use
onboarding arrangements to reduce the transaction costs associated with
such back-end allocations, thereby lowering the systemic costs of open
banking, such arrangements are less likely to raise concerns under
Sec. 1033.321. Permissibility in this context is likely to depend on
whether
[[Page 90900]]
parties are mutually attempting to reduce transaction costs, or whether
one party is instead seeking to undo or change the substantive
allocative outcomes that existing legal regimes would otherwise produce
for the parties involved, both in terms of where law would put the loss
initially and where the loss would be allocated under law.
By the same token, wholesale indemnification or ``hold harmless''
terms, which a number of commenters requested be imposed by or given
safe harbor status under the rule, also will raise significant concerns
under Sec. 1033.321. To the extent that an indemnity seeks,
effectively, to recast one party's potential liability as another's, it
almost inevitably seeks to undo the substantive outcome that existing
law would otherwise realize.
Third, the CFPB is particularly skeptical of, and as a result
intends to carefully scrutinize for reasonableness, data provider
insistence on onboarding arrangements that would allocate to third
parties liability for losses associated with unauthorized transactions
from accounts maintained by that data provider and where that liability
arises under Regulation E.\76\ Under Regulation E, financial
institutions have an obligation to protect their customers against
unauthorized transactions. Private network rules provide a means for
financial institutions to allocate that liability. Financial
institutions should continue to manage liability through appropriately
developed private network rules, not one-off agreements that may
manifest some improper, unilateral exertion of market power.
Depositories should not use the final rule's recognition that data
access onboarding needs to proceed in accordance with risk management
obligations as grounds to negate the effect of their own Regulation E
obligations or the need to manage liability through private network
rules.
---------------------------------------------------------------------------
\76\ The CFPB has the same view with respect to comments raising
concerns about the allocation of any liability under Regulation Z.
---------------------------------------------------------------------------
Finally, the CFPB observes that onboarding arrangements that adhere
to consensus standards will carry indicia of reasonableness under Sec.
1033.321(b).\77\ For example, their development by recognized standard
setters means they are likely to be directly related to a specific
risk, rather than an overbroad product of a data provider's or third
party's market power. The use of standard form onboarding arrangements
that have been developed through the kind of processes that recognized
standard setters maintain can provide an efficient model for data
providers and third parties.
---------------------------------------------------------------------------
\77\ The presence of such onboarding arrangements might also
suggest that a data provider's policies and procedures are
``reasonably designed'' under Sec. 1033.321(a)(1).
---------------------------------------------------------------------------
Regarding comments about the potential burden on data providers of
vetting third parties, the CFPB notes that final Sec. 1033.321 does
not require data providers to vet third parties. Any requirements
regarding vetting are the result of data providers' existing
requirements regarding risk management, such as the GLBA Safeguards
Framework or safety and soundness standards. To be clear, acting on the
authorization of a consumer to access their personal financial data
pursuant to this final rule does not, in any way, make a third party a
service provider to a data provider; and the same holds true for an
aggregator with respect to its use by that third party. Authorized
third parties interact with data providers for the limited purpose of
accessing a consumer's covered data at the consumer's express
direction, and do so within the final rule's procedural and substantive
protections regarding the features of the developer interface and the
collection, use, and retention of that data. This context differs from
other contexts in which data providers are choosing third party
business partners or service providers, or are providing data outside
the safe, secure, and reliable framework that the final rule is
intended to establish.
Additionally, the final rule includes various provisions designed
to reduce the burden of vetting. In particular, final Sec. 1033.321(c)
allows for conformance with certain consensus standards and
certifications to serve as indicia bearing on the reasonableness of a
denial under Sec. 1033.321(b), and final Sec. 1033.321(d) lists
conditions sufficient to justify a denial without the need for any
further evaluation by the data provider. With respect to comments
advocating CFPB supervision of data aggregators and third parties, as
noted in part IV.5 above the CFPB intends to exercise its supervisory
authorities in circumstances where that is appropriate. However, the
CFPB's confidential supervisory process is distinct from any vetting
that a data provider undertakes for its own risk management purposes.
The CFPB declines to make certain burden-related changes suggested
by some commenters. Specifically, final Sec. 1033.321 does not
prescribe timing requirements applicable to denials. New timing
standards would not be appropriate because final Sec. 1033.321 is
intended to work within data providers' existing processes for risk
management. And the CFPB understands that risk management is an ongoing
process that is difficult to reduce to a single decision point to which
a deadline could be attached. Regarding liability, the CFPB declines to
change the existing frameworks under Regulation E and Regulation Z for
the reasons described in part IV.5 above. And the CFPB cannot create a
safe harbor from data providers' existing legal obligations regarding
risk management because those obligations are implemented and enforced
by other agencies.
Regarding comments requesting additional changes designed to reduce
the risk of improper denials, the CFPB has adopted several new indicia
of reasonableness in final Sec. 1033.321(c) that will help ensure that
any denials are justified, as discussed below. These indicia, combined
with the other requirements of final Sec. 1033.321, will provide an
appropriate check against improper denials. The CFPB believes that
certain other suggestions are unnecessary because they are provided for
elsewhere in the final rule. For example, nothing in the final rule
prevents third parties, consumer advocates, or consumers from reporting
denials to the CFPB or other appropriate officials, such as prudential
regulators or State attorneys general. And as discussed in the analysis
of final Sec. 1033.351(b)(2), the final rule provides for transparency
in denials by requiring data providers to adopt policies and procedures
recording the basis for denial and communicating this basis to third
parties. For commenters concerned about data providers blocking
existing methods of data access before making developer interfaces
available, the CFPB has explained in the discussion of final Sec.
1033.311(e)(1) that such attempts could constitute unfair, deceptive,
or abusive acts or practices under the CFPA.
Finally, the CFPB agrees with commenters that interagency
coordination is essential to the successful operation of an open
banking system. Such coordination is especially important here because
data providers' legal obligations regarding risk management are
generally implemented and enforced by other agencies such as the
prudential regulators. Accordingly, the CFPB anticipates that it will
continue to work closely with other regulators to implement the rule
and provide additional guidance applicable to the consumer-authorized
data sharing context.
Requirements for Reasonable Denials (Sec. 1033.321(b))
Proposed Sec. 1033.321(b) would have provided that any denials
under
[[Page 90901]]
Sec. 1033.321 would be subject to a reasonableness standard. The
proposed rule stated that to be reasonable pursuant to Sec.
1033.321(a), a denial must, at a minimum, be directly related to a
specific risk of which the data provider is aware, such as a failure of
a third party to maintain adequate data security, and must be applied
in a consistent and non-discriminatory manner.
A few commenters responded to proposed Sec. 1033.321(b)'s
requirement that a denial must, at a minimum, be directly related to a
specific risk of which the data provider is aware. A bank and a trade
association commenter asserted this condition was too narrow because,
they said, data providers must anticipate potential risks that have yet
to materialize. However, a data aggregator commenter said that the term
``specific risk'' might be overbroad if it encompasses concerns like
reputational risk. A research organization requested more detail on the
meaning of specific risk.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.321(b) with certain changes for clarity about the role of this
provision. Final Sec. 1033.321(b) provides that a denial is reasonable
pursuant to Sec. 1033.321(a)(2) if it is: (1) directly related to a
specific risk of which the data provider is aware, such as a failure of
a third party to maintain adequate data security; and (2) applied in a
consistent and non-discriminatory manner.
Final Sec. 1033.321(b) describes these paragraphs as requirements
for reasonableness rather than minimum conditions because satisfying
both conditions is sufficient for a denial to be reasonable under this
provision. Further guidance about the application of these requirements
is found in the indicia of reasonableness are described in connection
with Sec. 1033.321(c).
The CFPB has determined that this approach provides greater clarity
than the proposed use of the phrase ``at a minimum,'' which could have
implied the existence of an unknown number of unstated additional
conditions. The requirements in Sec. 1033.321(b) are designed to
ensure that data providers are making denial decisions in a principled
manner. The CFPB has determined that denials made in violation of these
procedures carry a significant risk of being pretextual or otherwise
infringing consumers' access rights under CFPA section 1033.
Final Sec. 1033.321(b)(1) provides that a denial must be directly
related to a specific risk of which the data provider is aware, such as
a failure of a third party to maintain adequate data security. This
requirement is designed to ensure that the concerns motivating a denial
are appropriately tailored and concrete to justify denying access to a
third party. The CFPB disagrees with commenters who stated that
requiring data providers to articulate a specific risk would prevent
them from addressing risks that have yet to materialize. Final Sec.
1033.321(b)(1) does not require that a given harm have actually
occurred before a denial is justified; only that it be articulable with
specificity and based on circumstances that the data provider is aware
of.
The CFPB declines to state that certain safety and soundness risks
can never be stated with specificity. Final Sec. 1033.321(b)(1)
provides a procedural limit on denials of access but does not
substantively restrict the risks that a data provider may articulate.
However, any denial must also be necessary to avoid being inconsistent
with policies and procedures reasonably designed to comply with the
legal requirements described in Sec. 1033.321(a)(1). And final Sec.
1033.321(c) lists indicia that can assist entities in complying with
Sec. 1033.321(b). Similarly, in response to concerns that the
``specific risk'' standard is insufficiently clear, the CFPB notes that
it is designed to operate alongside the other provisions of this
section.
Final Sec. 1033.321(b)(1) provides that a denial must be
``directly related'' to a specific risk. In general, a denial is
directly related to a risk if it is appropriately tailored to that
risk. For example, if a data provider denies access to a third party
during the onboarding process because it is missing information about
that third party's information security practices, then it should grant
access once it receives information that establishes the sufficiency of
those practices. Under these circumstances, an indefinite denial would
not be directly related to the risk justifying the denial.
Final Sec. 1033.321(b)(2) also provides that a denial must be
applied in a consistent and non-discriminatory manner. This provision
is intended to ensure that data providers make similar denial decisions
across third parties that present materially similar risk management
concerns. As noted in the proposal, the term ``non-discriminatory'' in
this provision carries its ordinary meaning and is not intended to
refer to discrimination on a prohibited basis under Federal fair
lending law.
Regarding comments recommending that the final rule require denials
to be based on existing policies and procedures approved by a data
provider's regulator, the CFPB believes that this comment relates to
the consistency element of reasonableness. Specifically, denials based
on previously adopted written policies and procedures may be more
likely to be genuinely responsive to the risks described in those
policies and procedures, while denials based on newly announced
concerns raise heightened risks of being unreasonable under final Sec.
1033.321(b).
Indicia Bearing on Reasonableness ((Sec. 1033.321(c))
Proposed Sec. 1033.321(c) provided that indicia that a denial
pursuant to Sec. 1033.321(a) is reasonable would include whether
access is denied to adhere to a qualified industry standard related to
data security or third party risk management. The proposal explained
that conformance with an industry standard alone would not necessarily
settle the question of reasonableness.
Many commenters addressed the role of standard-setting bodies or
credentialing bodies. Several commenters recommended that the CFPB
itself develop, or encourage the development of, an accreditation
process for third parties that entitles them to data access, while
others supported a registry created by a standard-setting body or by
the CFPB. However, data providers and data provider trade association
commenters stated that any credentialing process or consensus standard
should not be dispositive. These commenters stated that risk management
is specific to each third party relationship and were concerned that
industry standards might conflict with the prudential regulators'
standards. A few commenters stated that no standard-setting body
currently has plans to issue standards related to risk management or
data security. A standard-setting body commented that they do not plan
to pursue authentication and data security specifications, or liability
determinations.
Other commenters recommended that the final rule include additional
factors relevant to a denial of access. One data aggregator commenter
recommended creating a presumption in favor of access for third parties
that attest to following appropriate data security standards. This
commenter also suggested including indicia of unreasonable denials for
denials made despite a third party certifying to the adequacy of its
security measures or conforming to an accreditation developed by the
CFPB or a standard-setting body. A trade association commenter
recommended that the final
[[Page 90902]]
rule give conclusive weight to similar factors related to unreasonable
denials, such as certification by the third party, conformance to an
industry standard, or supervision by a regulatory agency.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.321(c) with several new indicia bearing on the reasonableness of a
denial under Sec. 1033.321(b). Final Sec. 1033.321(c) states that
indicia bearing on the reasonableness of a denial under Sec.
1033.321(b) include: (1) whether the denial adheres to a consensus
standard related to risk management; (2) whether the denial proceeds
from standardized risk management criteria that are available to the
third party upon request; and (3) whether the third party has a
certification or other identification of fitness to access covered data
that is maintained or recognized by a recognized standard setter or the
CFPB.
The indicia listed in final Sec. 1033.321(c) include factors that
the can further guide compliance with Sec. 1033.321(b). The indicia do
not serve as conclusive evidence or presumptions of compliance because
the CFPB understands that the circumstances surrounding a denial may
render it unreasonable or reasonable for purposes of Sec. 1033.321(b)
despite the presence or absence of these indicia. For example, a third
party might possess a certification regarding the adequacy of its
information security program, but a data provider might nevertheless
reasonably deny access if it discovers deficiencies in that program
such that providing access would be inconsistent with policies and
procedures reasonably designed to comply with a legal requirement
regarding risk management.
Final Sec. 1033.321(c)(1) largely restates the proposal's indicia
related to qualified industry standards, with changes to conform to the
final rule's use of the term ``consensus standard'' and Sec.
1033.321's use of the term ``risk management'' to capture various legal
obligations related to safe and sound practices, information security,
and similar applicable statutory or regulatory obligations. A denial
made according to a consensus standard may be likely to be reasonable
because it reflects a consistent set of standards developed with the
participation of a variety of stakeholders, including data providers
and third parties. The CFPB believes this provision will promote safe
and competitive third party access.
Final Sec. 1033.321(c)(2) relates to whether the denial proceeds
from standardized criteria regarding risk management available to the
third party upon request. The CFPB agrees with commenters about the
value of a standardized risk assessment method. Denials made according
to standardized, knowable criteria may be likely to be reasonable
because they are the product of a principled decision-making process.
At the same time, the CFPB recognizes that in rare cases a data
provider might face an unanticipated risk that justifies denying
access. Additionally, there may be aspects of a risk management policy
that would undermine the policy's effectiveness if disclosed to a third
party. For that reason, final Sec. 1033.321(c)(2) is among the indicia
of reasonableness rather than a requirement of reasonableness.
Final Sec. 1033.321(c)(3) relates to credentials or other
identifications of fitness to access covered data. The CFPB agrees with
commenters who stated that a credentialing or registry system could
serve a useful role in the open banking system. But the CFPB also
recognizes that such a credential could not supplant data providers'
risk management obligations. Such credentials would reduce both the
burden of vetting and the risk of unreasonable denials under Sec.
1033.321(b). A denial of a credentialed third party may be likely to be
unreasonable under Sec. 1033.321(b) because, among other things, the
third party has presented evidence of its fitness to access covered
data, supported either directly or indirectly by a relevant regulator.
Conversely, a denial of a noncredentialled third party may be likely to
be reasonable under Sec. 1033.321(b) if such credential were customary
among third parties. Final Sec. 1033.321(c)(3) allows for a broad
range of credentials to serve as indicia, including lists of approved
third parties, and for a broad range of entities that may produce or
validate such a credential.
The CFPB acknowledges comments stating that no consensus standard
or credentialing entity relevant to denials is likely to exist in the
immediate future. Regarding comments requesting standards or entities
directly approved by the CFPB, the CFPB believes that these measures
would be most effective and efficient if done on a coordinated basis
with other regulators. Final Sec. 1033.321(c)(3) does not commit the
CFPB (or other regulators) to recognizing such a credential or
credentialing entity. But given the interest commenters expressed in
this type of accreditation, the CFPB believes that developments in this
direction would promote consistent and non-discriminatory practices
with respect to managing third party data access. Therefore, final
Sec. 1033.321(c)(3) accommodates the creation of such standards or
entities.
The CFPB believes the indicia provided in final Sec. 1033.321(c)
incorporate many of the suggestions made by commenters for improving
the efficiency of third party data access. The CFPB declines to adopt
all suggested indicia because the final rule prioritizes indicia the
CFPB believes are likely to be most relevant and impactful to
evaluating the reasonableness of a data provider's denial under Sec.
1033.321(b). Final Sec. 1033.321(c) is not an exhaustive list of
factors that can guide compliance with Sec. 1033.321(b).
Conditions Sufficient To Justify a Denial (Sec. 1033.321(d))
The CFPB proposed in Sec. 1033.321(d)(1) to clarify that a data
provider would have a reasonable basis for denying access to a third
party under Sec. 1033.321(a) if the third party does not present
evidence that its data security practices are adequate to safeguard the
covered data, provided the denial of access is not otherwise
unreasonable. The CFPB explained that this provision was intended to
alleviate the concerns related to the potential burden of vetting on
smaller data providers because if the third party does not present such
evidence, the data provider may deny access without vetting the third
party.
The CFPB proposed in Sec. 1033.321(d)(2) to clarify that a data
provider would have a reasonable basis for denying a third party access
if the third party does not make public certain information about
itself. This information consisted of data that the CFPB believed would
benefit the efficiency of the open banking system, such as the third
party's legal name and any assumed name it is using when doing business
with the consumer, a link to its website, and its LEI. Proposed Sec.
1033.321(d)(2) would have also permitted the data provider to deny
access if the information was not made available in both human-readable
and machine-readable formats, and if the information is not readily
identifiable to members of the public (meaning the information must be
at least as available as it would be on a public website).
The CFPB requested comment on whether to specify the types of
evidence a third party would need to present about its data security
practices that would give a data provider a reasonable basis to deny
access, and what types of evidence might provide such a basis. The CFPB
also requested comment on whether developing an accreditation system
could reduce diligence costs for both data providers and third parties
and increase compliance certainty for
[[Page 90903]]
data providers, and on the steps necessary to develop such a credential
and how the CFPB or other regulators could support such efforts.
The CFPB also requested comment on whether it should indicate that
conformance to a specific standard or a qualified industry standard
would be relevant indicia for a third party's machine-readability
compliance; whether it should issue regulations or guidance that would
make it easier for data providers and other members of the public to
identify a particular third party's information; whether it should
provide that a data provider is permitted to deny access if the third
party does not submit to the CFPB the link to the website on which this
information is disclosed; and whether data providers should have to
provide information or notice to the CFPB regarding their procedures
and decisions to approve or deny third parties for access to their
developer interfaces.
Several commenters addressed proposed Sec. 1033.321(d)(1). Several
commenters, including third parties, research organizations, and
consumer advocates, commented that the final rule should identify the
types of evidence that would establish the adequacy of a third party's
data security practices. Types of evidence suggested by these
commenters typically included a credential issued by an independent
entity or an industry standard provided by a standard-setting body.
These commenters differed on whether such evidence should be
dispositive. One trade association said that the CFPB should not
specify the types of evidence that would establish that a third party's
data security practices are adequate.
The CFPB also received several comments on proposed Sec.
1033.321(d)(2). A bank commenter stated that the rule should not
require a third party to provide a phone number that any outside party
could use to inquire about security practices because doing so might
compromise the third party's security. A consumer advocate commenter
said that any directory should include only approved third parties to
prevent public confusion. Regarding the LEI, one commenter stated that
the LEI could be used to identify a third party's legal name, while
another commenter said that an LEI was useful but not sufficient for
verifying a third party's identity. A data aggregator commenter
asserted that because many third parties currently lack LEIs and the
process for obtaining one was difficult, the final rule should also
permit third parties to use alternative identifiers such as a tax
identification number or employer identification number.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.321(d) with certain organizational and clarifying changes to
improve the function of this provision in the broader context of Sec.
1033.321. Final Sec. 1033.321(d)(1) provides that each of the
following is a sufficient basis for denying access to a third party:
(1) The third party does not present any evidence that its information
security practices are adequate to safeguard the covered data; or (2)
The third party does not make the following information available in
both human-readable and machine-readable formats, and readily
identifiable to members of the public, meaning the information must be
at least as available as it would be on a public website: (i) Its legal
name and, if applicable, any assumed name it is using while doing
business with the consumer; (ii) A link to its website; (iii) Its LEI
that is issued by: (A) A utility endorsed by the LEI Regulatory
Oversight Committee, or (B) A utility endorsed or otherwise governed by
the Global LEI Foundation (or any successor thereof) after the Global
LEI Foundation assumes operational governance of the global LEI system;
and (iv) Contact information a data provider can use to inquire about
the third party's information security and compliance practices.
Final Sec. 1033.321(d) is intended to reduce burden on data
providers by listing conditions that, if met, justify denying access
without expending any further resources on vetting a third party.
Accordingly, final Sec. 1033.321(d)(1) clarifies that a denial is
justified if a third party does not present ``any'' evidence of the
adequacy of its information security practices. As proposed, the CFPB
believes that this provision could have been read to require third
parties to present a certain type of evidence regarding their
information security practices that would entitle the third party to
access consumer data. Understandably, many commenters focused on the
kinds of evidence that could satisfy such a requirement. Many of these
commenters discussed credentialling functions and consensus standards,
and the CFPB has reflected this feedback in finalizing indicia related
to this evidence in Sec. 1033.321(c)(1) and (3). But the CFPB's intent
for final Sec. 1033.321(d)(1) is more limited. It is designed as a
means of streamlining the vetting process by clarifying that data
providers may deny third parties that failed to clear the minimum bar
necessary for data providers to evaluate the third party's practices.
Such evidence might take different forms, including a third party's
policies and procedures, or audits or reports. But if a third party
cannot present any evidence that its information security practices are
adequate, then a data provider may deny access without additional
investigation.
Final Sec. 1033.321(d)(2) lists certain information that a third
party must make available. As explained in the proposal, the CFPB finds
that this information will aid the efficiency of the open banking
system by helping data providers authenticate the identities of third
parties and facilitating any outreach to the third party that may be
required as part of the data provider's due diligence. The information
required by final Sec. 1033.321(d)(2) is largely the same as the
information the CFPB proposed, with a minor change. Specifically, to
avoid implying that data providers absolutely may not inquire about
topics other than information security, final Sec. 1033.321(d)(2)(iv)
describes a third party's contact information as information a data
provider can use to inquire about the third party's information
security ``and compliance'' practices. The CFPB disagrees that such
disclosing such contact information might compromise a third party's
security. The final rule does not require disclosing any substantive
information about a third party's information security program.
The CFPB declines to add alternative identifying information other
than the LEI, such as tax identification number or employer
identification number. An LEI allows users to link an entity to its
corporate family, which improves data providers' ability to identify
the third party seeking access. Additionally, the CFPB has not found
that LEIs are unduly burdensome to obtain in its experience
administering the Home Mortgage Disclosure Act and Small Business
Lending rules, both of which require financial institutions to report
an LEI.
5. Responding to Requests for Information (Sec. 1033.331)
Responding to Requests--Access by Consumers (Sec. 1033.331(a))
The CFPB proposed in Sec. 1033.331(a) to prescribe the conditions
that apply when consumers are seeking covered data. Under proposed
Sec. 1033.331(a), to comply with proposed Sec. 1033.201(a), upon
request from a consumer, a data provider would be required to make
available covered data when it receives information sufficient to: (1)
authenticate the consumer's identity and (2) identify the scope of the
data
[[Page 90904]]
requested. The CFPB explained that proposed Sec. 1033.331(a) is not a
requirement to authenticate the consumer's identity and identify the
scope of the data requested. Rather, proposed Sec. 1033.331(a)
identifies the point in time that a data provider must respond to the
request. The CFPB received limited comments on this provision. Several
commenters asked that the CFPB clarify how data providers may verify
consumers' identities when consumers access information under the rule.
For the reasons herein, the CFPB is finalizing Sec. 1033.331(a) as
proposed with an updated cross-reference. Section 1033.331(a) carries
out the objective of CFPA section 1033(a) for data providers to make
covered data available upon request to a consumer by defining what
information triggers a data provider's obligation to make covered data
available to a consumer. As noted in the proposal, these conditions
would be satisfied through procedures in use by most consumer
interfaces today. With regard to the comments requesting clarification
on how a data provider may verify a consumer's identity for purposes of
Sec. 1033.331(a), the CFPB notes that the only requirement in the rule
related to how a data provider must authenticate a consumer's identity
is the requirement at Sec. 1033.311(e)(2) with respect to the GLBA
Safeguards Framework.
Responding to Requests--Access by Third Parties (Sec. 1033.331(b))
Conditions That Apply to Requests From Third Parties (Sec.
1033.331(b)(1))
Proposal
Under proposed Sec. 1033.331(b)(1), a data provider would have
been required under Sec. 1033.201(a) to make available covered data to
a third party, when it receives certain information described in Sec.
1033.311(b)(i) through (iv). The CFPB proposed in Sec.
1033.331(b)(1)(i) that a data provider would need to receive
information sufficient to authenticate the consumer's identity. The
CFPB explained that before a data provider grants a third party access
to covered data today, the consumer is typically redirected from a
third party's interface to the data provider's interface to
authenticate the consumer's identity, usually by providing account
credentials. Where consumers provide their credentials directly to the
data provider through such an interface, the data provider would
generally receive information sufficient to authenticate the consumer's
identity for purposes of proposed Sec. 1033.331(b)(1)(i).
Under proposed Sec. 1033.331(b)(1)(ii), the data provider would
need to receive information sufficient to authenticate the third
party's identity. The CFPB explained that an example of such
information would include an access token obtained by the third party
that has been approved to access the data provider's interface. Under
proposed Sec. 1033.331(b)(1)(iii), a data provider would need to
receive information sufficient to confirm the third party has followed
the authorization procedures in proposed Sec. 1033.401. The CFPB
explained that this step would generally be satisfied where the data
provider receives a copy of the authorization disclosure the third
party provided to the consumer and that the consumer has signed.
Finally, under proposed Sec. 1033.331(b)(1)(iv), a data provider
would need to receive information sufficient to identify the scope of
the data requested. The CFPB explained that in certain situations, the
scope of information requested by an authorized third party might be
ambiguous. In these situations, under proposed Sec.
1033.331(b)(1)(iv), a data provider could seek to clarify the scope of
an authorized third party's request with a consumer. For example, the
CFPB explained that there might be circumstances in which a data
provider could seek to clarify whether a consumer intended to consent
to share information from particular accounts or particular types of
information not specified in the consumer's third party authorization.
The CFPB requested comment on the potential for technology to
evolve such that a data provider could satisfy appropriate data
security and other risk management standards without receiving a
consumer's account credentials directly from the consumer. The CFPB
also requested comment on whether clarifications are needed regarding
what information would be sufficient to confirm the third party has
followed the authorization procedures in the context of automated
requests received through a developer interface. Finally, the CFPB
requested comment on whether additional clarifications or procedures
are needed to ensure a data provider does not design its developer
interface to receive information sufficient to satisfy the conditions
set forth in proposed Sec. 1033.331(b)(1) but in a way that frustrates
the ability of authorized third parties to receive timely responses to
requests for covered data.
Comments
A consumer advocate commenter supported the proposed conditions in
Sec. 1033.331(b)(1) for data providers to verify a third party's
authorization to access consumer data and authenticate the identity of
third parties before they make available covered data. However, this
commenter, along with others, seemed to interpret proposed Sec.
1033.331(b)(1) as setting forth strict requirements, as opposed to
conditions that define the trigger for when a request must be responded
to by a data provider, which data provider commenters were concerned
would be overly burdensome with respect to confirming a third party's
authorization. This concern was twofold: (1) data providers would not
have actual knowledge of how the third party received authorization,
which they suggested could have been gathered through unfair, deceptive
or abusive third party authorization procedures; and (2) confirming
that every authorized third party complied with the authorization
procedures would be resource-intensive. Further, bank commenters that
interpreted the provision to be an obligation were generally unclear as
to what was required of them to authenticate the consumer or third
party or to confirm the third party followed the proposed Sec.
1033.401 authorization procedures.
Bank commenters offered a number of suggestions for revisions. Some
bank commenters recommended that the CFPB modify the regulatory text in
proposed Sec. 1033.331(b)(1)(iii) to clarify that a data provider has
the right but not the obligation to ``confirm the third party has
followed the authorization procedures in Sec. 1033.401.'' One bank
trade association commenter recommended that the CFPB change the
``confirm'' language in proposed Sec. 1033.331(b)(1)(iii) to
``reasonably confirm,'' arguing that this would give data providers
more discretion to determine whether the third party authorization
actually represents the ``consumer's express informed consent'' as
required by proposed Sec. 1033.401(c). At least one bank commenter
understood proposed Sec. 1033.331(b) as setting forth requirements
applicable every time a third party requests data from the developer
interface, even where the consumer had authorized the third party to
access data multiple times within an extended duration. In such cases,
one data provider trade association commenter recommended that the CFPB
distinguish between initial requests in which an authorization is first
presented to the
[[Page 90905]]
data provider, and subsequent requests that were authorized under the
initial request. The commenter stated that this would give data
providers more flexibility with respect to reviewing subsequent
requests. Specifically, the commenter suggested that data requests by
authorized third parties relying on an existing, unchanged
authorization should not require additional authentication by the data
provider.
Third party commenters were generally concerned that data providers
could unduly delay the processing of requests to promote the data
provider's own product or service. One third party commenter suggested
the final rule state that a data provider should provide a prompt
response to legitimate requests by third parties. This commenter
explained that some data providers have purposefully frustrated request
procedures by ignoring requests to discuss API access or by
misconstruing their direct data connection.
Final Rule
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.331(b)(1) with a minor change for clarity and an updated cross-
reference. Section 1033.331(b)(1) carries out the objective of CFPA
section 1033(a) for data providers to make covered data available upon
request to a consumer by defining what information triggers a data
provider's obligation to make covered data available to a third party
purporting to be authorized to act on behalf of a consumer. Under Sec.
1033.331(b)(1), to comply with the requirements in Sec.
1033.201(a)(1), upon request from an authorized third party, a data
provider must make available covered data when it receives certain
information. This information consists of: information sufficient to
authenticate the consumer's identity under Sec. 1033.331(b)(1)(i);
information sufficient to authenticate the third party's identity under
Sec. 1033.331(b)(1)(ii); information sufficient to document the third
party has followed the Sec. 1033.401 authorization procedures under
Sec. 1033.331(b)(1)(iii); and information sufficient to identify the
scope of the data requested under Sec. 1033.331(b)(1)(iv).
Consistent with the proposal, Sec. 1033.331(b)(1) does not impose
obligations on data providers to obtain certain information prior to
responding to a request for covered data. Rather, Sec. 1033.331(b)(1)
sets forth the trigger for when a data provider is obligated to make
covered data available to an authorized third party pursuant to the
rule. Section 1033.331(b)(1) does not by its terms require a data
provider to authenticate consumers or third parties, or confirm
authorizations of third parties. However, the CFPB expects data
providers generally will do so to ensure they are responding to
consumers' requests and to comply with the GLBA Safeguards Framework
(consistent with Sec. 1033.311(e)(2)), any safety and soundness
requirements, and other legal obligations, such as the CFPA prohibition
against unfair, deceptive, or abusive acts or practices, as applicable.
In particular, the CFPB does not believe Sec. 1033.331(b)(1)(iii)
imposes significant burden with respect to how a data provider
processes information about a third party's compliance with the rule's
authorization procedures. The CFPB has determined that data providers
should not be responsible for obtaining a consumer's authorization for
a third party because third parties are in the best position to
determine what data elements are reasonably necessary. However, Sec.
1033.331(b)(1)(iii) does not require a data provider to independently
verify the third party has followed each of the Sec. 1033.401
authorization procedures, but instead describes a condition in which
the data provider receives information sufficient to document such
authorization. As discussed in the proposal, receipt of a copy of the
signed authorization disclosure should constitute information
sufficient to confirm third party authorization, absent facts to the
contrary. However, in light of comments, the CFPB appreciates that the
use of ``confirm'' in proposed Sec. 1033.331(b)(1)(iii) could suggest
a rigorous due diligence obligation. Accordingly, the final rule uses
``document'' rather than ``confirm'' to clarify the nature of Sec.
1033.331(b)(1)(iii).
In response to bank commenter questions about whether any
particular method of authentication is necessary or sufficient, the
final rule does not so specify. The final rule only requires data
providers to satisfy the data security requirements in Sec.
1033.311(e) regarding the use of consumer credentials and compliance
with the Safeguards Framework. The CFPB believes the Safeguards
Framework is sufficiently clear that data providers must take some
reasonable steps to authenticate who is accessing the data, and the
CFPB does not believe it is necessary to prescribe a single means of
authentication in the final rule. The final rule does not preclude a
data provider from applying different treatment to initial and
subsequent data requests covered by the same authorization, if
otherwise permissible under Sec. 1033.311(e). The CFPB notes that
standard-setting bodies have created standards in this space and
consensus standards could be useful to demonstrating whether a trigger
has been met. Accordingly, indicia that bear on whether a trigger in
Sec. 1033.331(b) has been met include conformance to a consensus
standard.
Third party commenters affirmed the concern identified by the CFPB
in its request for comment that a data provider could frustrate the
ability of authorized third parties to receive timely responses to
requests. As discussed in detail above, final Sec. 1033.201(a)(2)
includes an anti-evasion provision limiting data providers' ability to
frustrate an authorized third party's receipt of covered data. To
illustrate how Sec. 1033.201(a)(2) applies to Sec. 1033.331(b), the
rule includes an example of conduct that violates the anti-evasion
provision in the context of requests, as discussed below with respect
to Sec. 1033.331(b)(2) below. The CFPB has determined the anti-evasion
provision can more flexibly address the variety of conduct that could
interfere with requests than more detailed procedural requirements.
A third party's authorization could extend to multiple requests,
depending on the duration and frequency of access authorized by the
consumer. As noted in the proposal, data providers today often issue
third parties accessing their systems a token that can be presented for
subsequent requests covered by a single authorization. If the data
provider adequately designs its developer interface, review of the
initial request by the third party should give the data provider
adequate opportunity to obtain evidence of the third party's
authorization including, if appropriate, confirmation by the consumer.
In general, it should not be necessary to keep confirming the third
party's authorization with the consumer in connection with each
previously authorized request. If a data provider continues to request
this information, then the data provider will raise concerns about
interfering with the access right, in violation of the anti-evasion
provision in Sec. 1033.201(a)(2).
Confirmation of Third Party Authorization (Sec. 1033.331(b)(2))
The CFPB proposed in Sec. 1033.331(b)(2) that a data provider
would be permitted to confirm the scope of a third party's
authorization to access the consumer's data by asking the consumer to
confirm (1) the account(s) to which the third party is seeking access
and (2) the categories of covered data the third party is requesting to
[[Page 90906]]
access, as disclosed by the third party pursuant to proposed Sec.
1033.411(b)(4). The proposed rule explained that data providers might
need to confirm the account(s) to which the third party is seeking
access because that information might not be clear from the
authorization disclosure, such as where a consumer has multiple
accounts. Additionally, the proposed rule explained that permitting the
data provider to confirm the categories of covered data would give the
consumer an opportunity to review what data they would be authorizing
and give data providers greater certainty that the consumer has
authorized the request. The proposed rule requested comment on whether
the final rule should instead permit data providers to confirm Sec.
1033.331(b)(2) information with the consumer only where reasonably
necessary.
In general, bank commenters supported proposed Sec.
1033.331(b)(2). One consumer advocate commenter said the CFPB should
require, rather than permit, the data provider to send a confirmation
to the consumer when it receives a third party request. Third party
commenters opposed proposed Sec. 1033.331(b)(2) on the grounds that it
would cause undue friction in the data access process and suggested
certain revisions. For example, one third party commenter recommended
that data providers not be allowed to confirm an authorization if the
third party transmits a record of the consumer's account selection.
Another commenter noted that the proposal did not set forth a
requirement for how or how quickly the data provider confirm third
party authorization, and noted that an anticompetitive data provider
could decide to confirm each request via certified mail. Additionally,
some third party commenters recommended that the CFPB revise proposed
Sec. 1033.331(b)(2) to require data providers to collect account
confirmation via the developer interface and not from the consumer.
The CFPB is finalizing Sec. 1033.331(b)(2) as proposed and has
added an example to address concerns raised by commenters about
interference by data providers, as discussed below. Section
1033.331(b)(2) carries out the objective of CFPA section 1033(a) by
clarifying that data provider is permitted to take certain steps to
confirm the scope of information requested by a third party purporting
to be authorized to act on behalf of a consumer. Allowing data
providers to confirm authorizations directly with the consumer, as
described in Sec. 1033.331(b)(2)(i) and (ii), can reduce the risk of
unintended or fraudulent authorizations and may be a necessary part of
data providers' risk management program. However, requiring data
providers to obtain consumer confirmation in every case could impose an
undue burden on the data provider and the access right, especially in
light of the protections in Sec. 1033.311(e)(2) and data providers'
other applicable legal obligations. In response to third party
commenters' suggestions for alternative procedures to obviate the need
for data providers to confirm authorization, it is not clear that it
would be feasible to require data providers to transmit records of
consumers' accounts to third parties before a third party has initially
requested access to covered data.
While data providers are permitted to confirm authorizations with
consumers pursuant to Sec. 1033.331(b)(2)(i) and (ii), data providers
must avoid interfering with the statutory access right pursuant to
Sec. 1033.201(a)(2). As discussed above with respect to Sec.
1033.331(b)(1), a data provider will create risks of violating the
anti-evasion provision at Sec. 1033.201(a)(2) if it seeks
reconfirmation with consumers after it has already documented the third
party's authorization to access covered data. In response to commenter
concerns about undue friction introduce by data providers, the final
rule includes an example that illustrates how a data provider would
violate Sec. 1033.201(a)(2) if a data provider knows or should know
its confirmation procedures would be likely to prevent, interfere with,
or materially discourage access to covered data.
Covered Data Not Required To Be Made Available (Sec. 1033.331(c))
Proposed Sec. 1033.331(c) stated that, notwithstanding Sec.
1033.331(a) and (b) (i.e., the general triggers for making covered data
available in response to consumer or third party requests), a data
provider is not required to make covered data available in response to
a request in four circumstances: if the data are withheld because an
exception described in Sec. 1033.221 applies (Sec. 1033.331(c)(1));
if the data provider has a basis to deny access pursuant to risk
management concerns in accordance with Sec. 1033.321(a) (Sec.
1033.331(c)(2)); if its interface is not available when the data
provider receives a request, although the performance specifications at
Sec. 1033.311 would still apply (Sec. 1033.331(c)(3)); or if the
request is for access by a third party but the consumer's authorization
is not valid for one of three reasons: (1) the consumer has revoked the
third party's authorization pursuant to proposed Sec. 1033.331(e); (2)
the data provider has received notice that the consumer has revoked the
third party's authorization pursuant to proposed Sec. 1033.421(h)(2);
or (3) the consumer has not provided a new authorization to the third
party after the maximum duration period, as described in proposed Sec.
1033.421(b)(2) (Sec. 1033.331(c)(4)). The CFPB requested comment on
whether additional clarification was needed to reduce the opportunity
for data providers to deny requests without justification under the
proposed provision.
One consumer advocate suggested limiting the scope of Sec.
1033.331(c)(1) by narrowing the scope of the exceptions under Sec.
1033.221(a) and (d), discussed above in part IV.B.4. The commenter
asserted fewer exceptions to the requirement that data providers make
information available make it more transparent to consumers how data
providers use their data. Several data provider commenters recommended
that final Sec. 1033.331(c) clarify that failure to meet the
conditions in Sec. 1033.331(a) and (b) does not require a data
provider to make covered data available in response to a request.
Further, some bank commenters suggested that small data providers would
be overburdened by what they interpreted as a requirement under
proposed Sec. 1033.331(c) to track all individual authorization and
access requests.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.331(c) with certain revisions. Final Sec. 1033.331(c) lists five
circumstances under which a data provider is not required to make
covered data available in response to a request. The final rule adopts
Sec. 1033.331(c)(1), (3), and (4) as proposed. As discussed below,
final Sec. 1033.331(c)(2) now lists the circumstance in which data are
not in the data provider's control or possession, consistent with the
requirement in Sec. 1033.201(a)(1). Also as discussed below, the final
rule also includes new Sec. 1033.331(c)(5), which describes the
circumstance in which the data provider has not received information
sufficient to satisfy the conditions in Sec. 1033.331(a) or (b), with
conforming changes to the first sentence of Sec. 1033.331(c). The
final rule also revises the heading to paragraph Sec. 1033.331(c),
from ``Response not required,'' to ``Covered data not required to be
made available.'' The final language more accurately reflects the
operation of the rule because certain responses are required even if
covered data are not available, pursuant to policies and procedures
required under
[[Page 90907]]
Sec. 1033.351(b). Section 1033.331(c) carries out the objective of
CFPA section 1033(a) for data providers to make covered data available
``upon request'' by clarifying when a data provider is not required to
make data available in response to a request.
Proposed Sec. 1033.331(c)(2) would have stated that a data
provider is not required to respond to a request when the data provider
has a basis to deny access pursuant to risk management concerns in
accordance with proposed Sec. 1033.321(a). As discussed in the
proposal, proposed Sec. 1033.321 was intended to apply to a consumer's
or third party's access to the interface as a whole, rather than access
to specific data fields requested. In terms of the operation of Sec.
1033.331, where a third party that previously had been granted access
to an interface is subsequently denied access pursuant to Sec.
1033.321, the data provider would be denying the request because it
could not authenticate the third party's identity pursuant to Sec.
1033.331(b)(1)(ii). Consistent with the purpose of the clarification in
final Sec. 1033.321(a) that data providers can deny a consumer or a
third party access to ``all elements'' of the interface, the CFPB is
revising final Sec. 1033.331(c) to treat a denial by operation of
Sec. 1033.321 as a failure to authenticate under Sec. 1033.331(a) or
(b). For these reasons, the CFPB is not adopting Sec. 1033.331(c)(2)
as proposed. This change does not alter the operation of Sec. 1033.321
that was intended by the proposal. In place of the text in proposed
Sec. 1033.331(c)(2) regarding Sec. 1033.321, the final rule includes
new Sec. 1033.331(c)(2) to specify a circumstance that had not been
identified in the proposal but that nonetheless would justify a denial
of information requested: when the data are not in the data provider's
control or possession, consistent with the general requirement in Sec.
1033.201(a)(1). This change is intended to clarify the operation of the
rule as a whole, rather than identify a new basis that a data provider
could deny a request.
Additionally, the final rule includes new Sec. 1033.331(c)(5) in
response to comments requesting clarification that Sec. 1033.331(a)
and (b) do not require a data provider to make covered data available
in response to a request. The CFPB agrees with commenters that this
addition would facilitate compliance by clarifying the operation of the
rule. The general conditions that trigger a data provider's obligation
to make covered data available are set forth in Sec. 1033.331(a) with
respect to consumer requests and Sec. 1033.331(b) with respect to
third party requests. A data provider would not be required to make
information available if those conditions were not met. The proposed
rule did not list those explicitly as bases under Sec. 1033.331(c),
but generally explained that a data provider would not be required to
make covered data available in response to a request as set forth in
paragraphs (c)(1) through (4) ``[n]otwithstanding the general rules in
Sec. 1033.331(a) and (b).'' The CFPB believes that identifying these
bases more directly will better facilitate compliance with the rule,
including with respect to Sec. 1033.351(b)(3), discussed below in part
IV.C.7. Thus, final Sec. 1033.331(c) no longer includes the
introductory clause, ``[n]otwithstanding the general rules in
paragraphs (a) and (b) of this section.''
Responses to comments regarding the exceptions in Sec. 1033.221
are discussed in part IV.B.4. Regarding commenters' concern that small
data providers would be overburdened by what they interpreted as a
requirement under proposed Sec. 1033.331(c) to track all
authorizations and data access requests of their customers, Sec.
1033.331(c) does not require recordkeeping. With respect to concerns
regarding the burden of policies and procedures requirements in Sec.
1033.351(b) and (d) regarding responses to denials and record
retention, the CFPB believes these requirements will not overburden
data provider, as discussed more fully below in part IV.C.7 below.
Additionally, as discussed in part IV.A.4, the final rule does not
cover small depository institution data providers.
Jointly Held Accounts (Sec. 1033.331(d))
CFPA section 1033(a) generally requires data providers to 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.'' The statute does not
directly address how this obligation applies with respect to jointly
held accounts. The CFPB proposed in Sec. 1033.331(d) to require a data
provider that receives a request for covered data from a consumer that
jointly holds an account or from an authorized third party acting on
behalf of such a consumer to make available covered data to that
consumer or authorized third party, subject to the other requirements
of Sec. 1033.331. The CFPB noted that this provision would not affect
data providers' existing obligations to provide information directly to
consumers under other Federal consumer financial laws, such as EFTA,
TISA, and TILA, and their implementing regulations. Those regulations
generally permit data providers to satisfy the relevant information
disclosure requirements by providing the information to any one of the
consumers on the account.\78\ The CFPB requested comment on whether
other account holders should receive authorization disclosures or
otherwise be notified, or should have an opportunity to object, when an
account holder authorizes access to consumer information. The CFPB also
requested comment on whether the rule should specifically address
whether authorized users of credit cards should have similar access,
even if they are not a joint holder of the credit card account.
---------------------------------------------------------------------------
\78\ See 12 CFR 1005.4(c), 1030.3(d), 1026.5(d).
---------------------------------------------------------------------------
A nondepository commenter requested that the CFPB clarify that
authorization from a single account holder is sufficient and that there
is no requirement to notify other account holders. The commenter stated
that this approach is consistent with other activity by an account
holder, such as writing a check or accessing the account through a
consumer interface, and that providing other account holders with
notice and an opportunity to object would create legal questions and
consumer friction for data access. A trade association for
nondepository entities recommended that other account holders not be
required to approve when an account holder authorizes access but that
they should be notified and receive authorization disclosures. Another
trade association for nondepository entities stated that the rule
should require all account holders to provide authorization for access
to covered data. The commenter stated that if the rule does not require
authorization from all account holders, the other account holders
should be notified and have an opportunity to object and prevent the
authorization. A consumer advocate commenter stated that other account
holders should not have the right to object but that they should
receive notice unless the consumer authorizing access actively
indicates that such notice would be harmful because it poses a risk to
their safety.
For the reasons discussed herein, the CFPB is adopting Sec.
1033.331(d) as proposed with one minor change. As finalized, Sec.
1033.331(d) provides that a data provider that receives a request for
covered data from a consumer that jointly holds an account or from an
authorized third party acting on behalf of such a consumer must make
available covered data to that consumer or authorized third party,
subject to the other provisions of Sec. 1033.331. The final rule
changes ``requirements'' to
[[Page 90908]]
``provisions'' in the last phrase in Sec. 1033.331(d) because the
other parts of the rule that identify circumstances in which a data
provider may not be obligated to make available covered data are more
accurately described as ``provisions'' than ``requirements.'' Section
1033.331(d) carries out the objectives of CFPA section 1033(a) by
clarifying whether a data provider must make available covered data in
response to a request by one consumer with respect to covered data
concerning a jointly held account.
Allowing a single account holder to request covered data or to
authorize a third party to access covered data on behalf of the account
holders is consistent with the broad authority that joint account
owners have over the account. Given that broad authority, the CFPB
concludes it would be unnecessarily burdensome at this time to require
that other account holders approve in advance a request for covered
data or authorize a third party to access covered data on behalf of a
joint account holder. Likewise, the data provider or authorized third
party is not required to provide notice or a copy of the authorization
disclosure to other account holders. While a notice or authorization
disclosure would inform the other account holders that account
information is being accessed, the benefits of such a disclosure or
notice are unclear and would depend on the circumstances, including the
terms of the account and the relationship of the account holders. Each
joint account holder already has significant authority over the
account, including the ability to provide account information or expend
funds. Moreover, when a joint account holder authorizes a third party
to access covered data, the consumer protections in Sec. 1033.421,
including the limitations on collection, retention and use by
authorized third parties, impose boundaries on the data that can be
accessed by third parties and how that data can be used. Accordingly,
the data provider is not required to provide a notice or copy of the
disclosure to all joint account holders, though nothing in the rule
prohibits data providers from doing so if they see fit.
Data Provider Revocation (Sec. 1033.331(e))
Proposed Rule
The CFPB proposed in Sec. 1033.331(e) to permit a data provider to
make available to the consumer a reasonable method by which the
consumer could revoke any third party's authorization to access all of
the consumer's covered data. Under the proposed rule, to be reasonable,
the revocation method would need to be, at a minimum, unlikely to
interfere with, prevent, or materially discourage consumers' access to
or use of the data, including access to and use of the data by an
authorized third party. Indicia that the data provider's revocation
method was reasonable would include its conformance to a qualified
industry standard. Finally, under the proposed rule, a data provider
that received a revocation request from consumers through a revocation
method would be required to notify the authorized third party of the
request.
The proposal stated that this provision, along with the proposed
third party revocation requirements in Sec. 1033.421(h), were intended
to ensure consumers would have multiple outlets through which they
could revoke third party authorization to access covered data. But the
CFPB preliminarily determined that requiring data providers to make a
revocation method available might burden smaller entities. The proposed
rule also noted that stakeholders had expressed concerns during SBREFA
about anticompetitive behaviors from data providers. Accordingly, the
proposed rule would not have permitted data providers to make available
a method through which the consumer could partially revoke a third
party's access to covered data, as this would be inconsistent with
proposed Sec. 1033.201(a), requiring data providers to make covered
data available upon request based on the terms of the consumer's
authorization. The proposed rule stated that partial revocations could
result in consumers losing utility of data access for certain use
cases. To further account for anticompetitive concerns, proposed Sec.
1033.331(e) included a list of non-exhaustive requirements to ensure
the optional revocation method would be reasonable, which were drawn
from the definition of ``information blocking'' in section 3022(a) of
the Public Health Service Act. The proposed rule stated that this
language would promote consumers' ability to access and share their
data by ensuring data providers do not impose obstacles that
effectively evade their obligations to make available covered data
under CFPA section 1033. Regarding the proposed notification
requirement, the proposed rule explained that a third party whose
authorization to access data is revoked by a consumer would need to
understand that the consumer has chosen to end their authorization, and
that the data provider did not terminate the access for another reason.
Comments Received
The concept of revocation, including permitting data providers to
provide consumers with a revocation method, received general support
from commenters, with many agreeing that consumers benefit
significantly from multiple opportunities to revoke third party
authorizations. Some commenters, including a consumer advocate, a trade
association for banks, and a third party commenter, stated that the
CFPB should require, rather than permit, revocation through a data
provider. A trade association for data providers stated that requiring
revocation through data providers would not be a burden for smaller
entities because core processors can supply interfaces that include
revocation methods.
Some banks and consumer advocates expressed concerns about
qualified industry standards related to revocation, stating that
qualified industry standards are inappropriate for revocation and could
conflict with federally supervised entities' regulatory obligations.
Additionally, some data provider, third party, and data aggregator
commenters expressed concern about the proposed notification
requirement, and suggested the following changes: require notification
in as close to real-time as possible; require data providers to provide
24-hour notice to the third party before terminating access in case of
pending transactions or fraud attempts; require consumers to notify all
parties of their revocation and free data providers from possible
liability that results from revocation; and ensure data providers do
not have to furnish notification to any third party but the authorized
third party. Third party commenters suggested that without more
guardrails around the notification requirement, or around data
providers' ability to solicit revocations from consumers, the rule
would not adequately account for the potential for anticompetitive
activities from data providers. In contrast, a trade association for
banks requested that the CFPB make clear that a reasonable revocation
method would allow the data provider to provide clear disclosures about
data access to their customers.
Commenters also provided feedback on whether the permitted
revocation method should allow partial revocations. Some data providers
and data provider trade associations stated that the final rule should
allow for partial revocations through the data provider for the
consumer's added control. They also stated that the proposed rule
overstated concerns about consumers not realizing the impacts of
revocation on data access, commenting
[[Page 90909]]
that consumers making post-authorization decisions to revoke reflect
intention to control and terminate third party authorizations. Other
data provider and credit union trade association commenters stated that
partial revocation is costly and burdensome and could result in unfair
competition.
A trade association for third parties and other stakeholders raised
concerns about consumer revocation through the data provider in
relation to TANs. Several third parties stated that consumer revocation
could result in the consumer, intentionally or unintentionally, causing
the data provider to revoke the consumer's TAN after the consumer
obtains the third party product or service but before the payment
settles. Commenters suggested that the proposed rule's strict all-or-
nothing revocation method for data providers could contribute to the
unintended consequence of third party payment failure when a consumer
had authorized a third party to access a TAN and other covered data.
Finally, commenters suggested that the CFPB: clarify that data
providers must recognize revocation requests in joint accounts if one
account holder makes the request; clarify the ``all or nothing''
requirement and how revocation works for joint account holders; clarify
what constitutes a ``reasonable method'' and provide examples of when
revocation mechanisms are likely to interfere with, prevent, or
materially discourage consumers and how deceptive design might manifest
in revocation mechanisms.
Final Rule
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.331(e) with certain changes and one technical correction described
below, to provide that a data provider does not violate the general
obligation in Sec. 1033.201(a)(1) by making available to the consumer
a reasonable method to revoke any third party's authorization to access
all of the consumer's data, provided that such method does not violate
Sec. 1033.201(a)(2). Indicia that the data provider's revocation
method is reasonable include its conformance to a consensus standard. A
data provider that receives a revocation request from a consumer
through a revocation method it makes available must revoke the
authorized third party's access and notify the authorized third party
of the request in a timely manner. Section 1033.331(e) carries out the
objectives of CFPA section 1033(a) by clarifying that a data provider
is permitted to establish certain procedures allowing a consumer to
communicate efficiently and directly with the data provider when a
third party is no longer authorized to act on the consumer's behalf to
access covered data.
While consumers benefit from multiple methods of revoking third
party authorization to access covered data, the CFPB has determined
that requiring data providers to make available a revocation method
would not be necessary and could be burdensome for some data providers.
The CFPB expects that consumers seeking to revoke access to a requested
product or service are most likely to do so from the third party with
whom they have the ongoing customer relationship. As discussed above,
while one commenter stated that requiring revocation through data
providers would not be burdensome because entities could request core
processors to include a method as part of their consumer interfaces,
other commenters raised concerns about the burdens associated with
maintaining an optional revocation method that adheres to the rule's
requirements. Though providing a revocation method itself could be
relatively straightforward, the CFPB acknowledges commenters' concerns
that ongoing costs associated with maintaining it could be burdensome.
As such, the final rule permits, but does not require, data providers
to provide a revocation method to consumers.
The proposed rule stated that, to be reasonable, the revocation
method would, at a minimum, need to be unlikely to interfere with,
prevent, or materially discourage consumers' access to or use of the
data, including access to and use of the data by an authorized third
party. This language was intended to ensure data providers offering an
optional revocation method did not impose obstacles that evade their
obligations to make available covered data under CFPA section 1033. The
final rule instead states that data providers do not violate their
general obligation in the rule by making available to the consumer a
reasonable method to revoke any third party's authorization to access
all of the consumer's covered data, provided that such method does not
violate Sec. 1033.201(a)(2). This change is meant to ensure that any
revocation method a data provider offers to consumers adheres to the
prohibition against evasion, which applies to all other data provider
activities, and is meant to achieve the same effect behind the proposed
rule's language: data providers must not violate their general
obligation to make available covered data through the offering of the
optional revocation method. Potential examples of actions that might
violate the prohibition against evasion in providing an optional method
for consumers to revoke third party authorizations are intentionally
soliciting consumers to revoke authorizations based on misleading
statements about the third parties' collection, use, or retention of
covered data, or providing granular revocations or disabling a TAN
without the consumer's consent, discussed further below.
As discussed above, some commenters were concerned that consensus
standards could be inappropriate for revocation and could conflict with
federally supervised entities' regulatory obligations. The CFPB notes
that consensus standards are indicia of compliance, not mandatory for
compliance, and the revocation method itself is optional. Without
suggesting that any such conflict exists, the CFPB is accordingly
confident that data providers can avoid any hypothesized conflict with
other obligations.
The CFPB remains concerned that data providers are likely to have
commercial interests contrary to those of authorized third parties
offering competing products or services. As such, the final rule
requires data providers that provide consumers a revocation method to
make available a method through which the consumer can revoke access to
all of the consumer's covered data, adhere to the final rule's anti-
evasion provision in Sec. 1033.201(a)(2) and notify the authorized
third party of the request in a timely manner. This language will
ensure that any revocation method provided to consumers is provided in
accordance with the anti-evasion provision in Sec. 1033.201(a)(2).
While some commenters argued that data providers should be allowed
to provide consumers the option to request partial revocations through
the data provider, the final rule only allows for all-or-nothing
revocations. Commenters did not describe in detail data providers' view
into the functionality of products or services, and therefore it
remains unclear how a data provider could effectively determine how to
provide partial revocations that do not result in harms to consumers or
authorized third parties as they continue to access covered data for
products and services for which the authorization is intended to remain
in place. As discussed above regarding data providers responding to
requests under Sec. 1033.331(b)(1), some data provider commenters
expressed concern that data providers were not positioned
[[Page 90910]]
to have actual knowledge of third parties' receipt of authorization
from consumers. The CFPB has determined that, just as data providers
are not in the best position to manage third party authorizations, data
providers are likewise not in the best position to allow consumers to
seek partial revocations, a consequence of which would be termination
of third parties' access to potentially reasonably necessary data
elements. Further, data providers' incentives to provide partial
revocations are unclear, and may not be aligned with consumers'
incentives to control the authorizations they provide to third parties
in order to receive products or services. As discussed above regarding
data providers responding to requests under Sec. 1033.331(b)(1), data
providers may have strong incentives to limit the scope of data
available to third parties, especially those providing a competing
product or service. These potentially competing incentives may result
in competition harms or consumer harms if data providers are permitted
to provide consumers with the ability to only partially revoke third
party authorizations to access covered data.
Additionally, as described above, some commenters suggested that
the proposal's all-or-nothing revocation method for data providers
could contribute to the unintended consequence of third party payment
failure when a consumer had authorized a third party to access a TAN
and other covered data and the consumer subsequently requests
revocation of that information. Commenters expressed concern that a
consumer's revocation of TAN information would also result in a data
provider disabling a TAN's functionality. However, there are multiple
reasons a consumer might revoke a third party's access to TAN
information. A consumer may revoke access to the TAN information
because they do in fact want to stop a third party's ability to
initiate payments--therefore, the revocation would be intended for both
the information and the functionality. Sometimes the consumer may just
intend to revoke the third party's ability to access information, but
intend for the TAN to remain functional. To avoid violating the anti-
evasion provision in Sec. 1033.201(a)(2), data providers must be aware
that disabling a TAN without the consumer's consent might render
unusable the covered data that the data provider makes available or
prevent, interfere with, or materially discourage a consumer in
accessing covered data. Whether revocation of TAN information or TAN
functionality following a consumer's revocation request is a material
interference with the third party's access to covered data will depend
on the facts. However, general awareness of the possibility of
unintended consequences of revocation, without more, will not be enough
to violate this standard.
Further, the CFPB agrees with commenters that Sec. 1033.331(e)
should specify that revocation must occur in a timely manner and thus
has included language to that effect in the final rule. Failure to
timely revoke data access is likely to interfere with a consumer's
express desire to revoke a third party's authority to access covered
data. Similarly, failure to notify third parties of consumers'
revocation requests in a timely manner could result in the third party
continuing to seek access to covered data and receiving denials to
those requests. As such, to ensure revocation is timely following a
revocation request, and that notification is provided to the authorized
third party in a timely manner, the final rule requires that: (1) the
third party's access to the data must be revoked in a timely manner;
and (2) a data provider that receives a revocation request from a
consumer through a revocation method it makes available must notify the
authorized third party of the request in a timely manner. While
commenters suggested other specific changes to the notification
requirements, described above, the CFPB has determined that additional
changes are unnecessary.
Finally, a data provider commenter and trade associations for banks
asked that the final rule provide information about how revocation
works for joint account holders. As discussed related to Sec.
1033.331(d), a consumer that jointly holds an account may request
access to covered data or may authorize third party access to covered
data. Likewise, the revocation method described in Sec. 1033.331(e)
pertains to a consumer that jointly holds an account. Any consumer that
jointly holds an account may revoke third party authorization to access
covered data related to that account, if provided for under the terms
of the account. The CFPB has made a technical correction to the last
sentence in proposed Sec. 1033.331(e) to refer to revocation requests
received from ``a consumer,'' instead of the plural ``consumers,''
which could have otherwise implied both joint account holders always
need to provide the revocation request.
6. Public Disclosure Requirements (Sec. 1033.341)
Public Disclosure and Human- and Machine-Readability Requirements
(Sec. 1033.341(a))
Proposed Sec. 1033.341(a) would have required data providers to
make the information described in proposed Sec. 1033.341(b) through
(d)--which address identifying information about the data provider,
developer interface documentation, and performance specification--
readily identifiable to members of the public. Proposed Sec.
1033.341(a)(1) defined this to mean that the information must be at
least as available as it would be on a public website. Under proposed
Sec. 1033.341(a)(2), the information would have been required to be
available in both human- and machine-readable formats. The CFPB
preliminarily determined that making the data available in a machine-
readable format could enable third parties and other stakeholders to
use automated processes to ingest the relevant information into their
systems for processing and review, which will make the process of
obtaining this information more efficient. The CFPB requested comment
on whether it should indicate that conformance to a specific standard
or a qualified industry standard would be relevant indicia for a data
provider's compliance with the machine-readability requirement in
proposed Sec. 1033.341(a)(2). Additionally, the CFPB requested comment
on whether it should issue rules or guidance that would make it easier
for third parties and other members of the public to identify a
particular data provider's information.
Commenters generally supported the requirement to make information
about the data provider readily identifiable. Some commenters
recommended the rule go further regarding public disclosure
requirements. One bank commenter recommended that the rule allow for
multiple data providers to publish their required disclosures in one
location. The commenter suggested that this may be more efficient for
data providers and might reduce search costs for members of the public
seeking to access disclosures from multiple data providers. Further,
one standard-setting body commenter suggested that an already-existing
registry where data providers self-report data to help third parties
connect to their data might also function as a repository for
disclosures of developer interface documentation.
Regarding the proposed requirement to make information available in
both human-readable and machine-readable
[[Page 90911]]
formats, a research institute and a trade association suggested that
data provider disclosures should meet the proposed machine-readability
requirement if a data provider makes the information available in a
format that consumers can print or retain. In response to the request
for comment, one industry commenter recommended that the CFPB should
either provide a standard for machine-readability or make conformance
with a consensus standard indicia of compliance.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.341(a) as proposed. The CFPB agrees with the commenters that a
central repository could benefit the public by reducing search costs. A
data provider could comply with Sec. 1033.341(a) by publishing on its
website a link, readily identifiable to members of the public, that
redirects consumers to the disclosures required in Sec. 1033.341(b)
through (d), published on a publicly available central repository,
provided the data provider does not otherwise impede the public's
ability to readily locate the disclosures.
In response to comments, information that is only available in a
human-readable format that a consumer can print or retain, but that is
not also available in a machine-readable format, would not comply with
Sec. 1033.341(a). As explained in the proposal, making the data
available in a machine-readable format enables third parties and other
stakeholders to use automated processes to ingest the relevant
information into their systems for processing and review, which will
make the process of obtaining this information more efficient.
Final Sec. 1033.341(a), as well as final Sec. 1033.341(b) through
(c), will carry out the objectives of CFPA section 1033 by ensuring
that third parties can efficiently access information necessary to make
requests for covered data and use a developer interface. By enabling
third parties to obtain information about how to use the developer
interface, Sec. 1033.341(a) through (c) also promotes the use and
development of standardized formats available through the developer
interface.
Disclosure of Identity Information and Contact Information (Sec.
1033.341(b))
The CFPB proposed in Sec. 1033.341(b) to require data providers to
disclose certain identifying information in the manner described in
proposed Sec. 1033.341(a). Specifically, proposed Sec. 1033.341(b)(1)
through (3) would require data providers to publicly disclose certain
identifying information: their legal name and, if applicable, any
assumed name they are using when doing business with the consumer; a
link to their website; and an LEI issued by a utility endorsed by the
LEI Regulatory Oversight Committee or a utility endorsed or otherwise
governed by the Global LEI Foundation (or any successor thereof) after
the Global LEI Foundation assumes operational governance of the global
LEI system. Proposed Sec. 1033.341(b)(4) would have required data
providers to disclose contact information that enables a consumer or
third party to receive answers to questions about accessing covered
data under part 1033.
Commenters provided little feedback about proposed Sec.
1033.341(b). One LEI nondepository entity commenter supported the
requirement for data providers to disclose their LEI, noting that
consistent use of these identifiers will enable a more efficient data
sharing process. Two credit union trade association commenters
suggested that smaller data providers that use a separate vendor to
maintain their developer interface should be able to provide that
vendor's contact information for inquiries related to the interface.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.341(b) as proposed. A data provider is permitted to provide the
contact information for the vendor that maintains the developer
interface for inquiries related to the developer interface. The rule
does not require that a data provider itself respond to inquiries
related to its developer interface. The rule does not require that a
data provider itself respond to such inquiries. Rather, it requires
that data providers provide contact information that enables a consumer
or third party to receive answers to questions about accessing covered
data, which reasonably allows a data provider to direct such inquiries
to a vendor that develops and maintains the interface.
Disclosure of Developer Interface Documentation and Access Location
(Sec. 1033.341(c))
The CFPB proposed to require in Sec. 1033.341(c) that a data
provider disclose for its developer interface, in the manner described
in proposed Sec. 1033.341(a), documentation, including metadata
describing all covered data and their corresponding data fields, and
other documentation sufficient for a third party to access and use the
interface. Under proposed Sec. 1033.341(c), a data provider would need
to maintain and update documentation as the developer interface is
updated. The CFPB also proposed that the documentation include
information on how third parties can get technical support and report
issues with the interface. Finally, the CFPB generally proposed to
require that developer interface documentation must be easy to
understand and use. The CFPB preliminarily determined that it is common
practice for data providers that have interfaces to disclose such
metadata and documentation. Additionally, the CFPB preliminarily
determined that a requirement to publicly disclose documentation and
metadata would not materially increase the cost of compliance and would
substantially enhance the usability of the interface.
One commenter that provides services to data providers highlighted
generally the types of challenges industry participants might have in
accessing data from a data provider. The commenter did not identify any
particular challenges stemming from the proposal but emphasized the
importance of industry alignment on the type of information needed to
access and use APIs effectively. The commenter focused on the
challenges of accessing and using a production API when its
specifications are not publicly available and regularly maintained.\79\
Another industry commenter supported the proposed requirement that data
providers disclose information sufficient for a third party to access
and use the interface.
---------------------------------------------------------------------------
\79\ See, e.g., Dr. Paul M. Cray, Open API Specifications in the
Real World, at 5-15 (APIContext, White Paper, Aug. 2024), https://www.regulations.gov/comment/CFPB-2023-0052-11139 (noting, generally,
that public disclosure of performance specifications poses some
challenges for data providers, but overall is the correct approach
for industry).
---------------------------------------------------------------------------
However, several data provider commenters and a research institute
commenter were critical of the proposed requirement that data providers
disclose developer interface documentation and metadata sufficient for
a third party to access and use the interface. These commenters stated
that it is not common practice for data providers to make developer
interface metadata and documentation available to the public and would
subject data providers to security risks. These commenters recommended
that the information required to be disclosed publicly should not be
sufficient, on its own, for a third party to access and use the
interface.
A bank commenter, research institute commenter, and bank trade
association commenter opposed the requirement in proposed Sec.
1033.341(c)(1) to update documentation as the developer interface is
updated. These commenters
[[Page 90912]]
explained that this requirement would be unduly burdensome to data
providers. These commenters noted that a developer interface typically
requires frequent, minor changes that do not significantly affect
access or use, and the proposed requirement would be costly to
implement. These commenters suggested instead that data providers be
required to reasonably cooperate with authorized third parties to make
available documentation in a timely manner that enables the
connectivity requirements provided in part 1033.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.341(c) with certain revisions to address commenters' concerns
about the information security risks and burden. Specifically, final
Sec. 1033.341(c) requires a data provider to disclose in the manner
required by Sec. 1033.341(a) documentation about its developer
interface, including metadata describing all covered data and their
corresponding data fields, and other documentation sufficient for a
third party to access and use the interface. Final Sec. 1033.341(c)
provides that a data provider is not required to make publicly
available information that would impede the data provider's ability to
deny a third party access to its developer interface, consistent with
Sec. 1033.321. Indicia that documentation is sufficient for a third
party to access and use a developer interface include conformance to a
consensus standard.
Final Sec. 1033.341(c) also provides that the documentation must
be maintained and updated as reasonably necessary for third parties to
access and use the interface in accordance with the terms to which data
providers are subject under part 1033. Further, the documentation must
include how third parties can get technical support and report issues
with the interface. In addition, the documentation must be easy to
understand and use, similar to data providers' documentation for other
commercially available products. Publishing information about how third
parties can access and use the developer interface, including metadata
describing all covered data and their corresponding data fields, will
promote the development and use of standardized formats of information,
consistent with CFPA section 1033(d).
In proposing Sec. 1033.341(c), the CFPB did not intend for data
providers to make publicly available access keys to the developer
interface or other information that would undermine the purpose of
Sec. 1033.321. To address commenters' concerns that the proposal might
interfere with their ability to engage in appropriate risk management,
the final rule clarifies that a data provider is not required to make
publicly available information that would impede its ability to
reasonably deny a third party access to its developer interface,
consistent with Sec. 1033.321. The final rule's inclusion of a
consensus standard as indicia for what documentation is sufficient to
access and use a developer interface is intended to promote
standardization with respect to the type of documentation that
facilitates third parties' access to and use of covered data, while
accounting for information security risks to data providers.
The proposal would have required documentation to be updated ``as
the developer interface is updated.'' To address concerns regarding the
potential burden of documenting frequent minor updates to developer
interfaces, final Sec. 1033.341(c)(1) provides that such documentation
must be maintained and updated ``as reasonably necessary for third
parties to access and use the interface in accordance with the terms to
which data providers are subject'' under part 1033. This change from
the proposal provides flexibility for data providers to make minor
updates to their interfaces without requiring an update to the
corresponding documentation, as long as third parties can still access
and use the interface as required by the final rule.
The CFPB declines to adopt commenters' recommendation to require
data providers to cooperate with third parties to make documentation
available in a timely manner. The CFPB is concerned this could imply
that third parties engage in some affirmative conduct to obtain updated
documentation, which could undermine the rule's affirmative requirement
to make the information publicly available, which could create
inefficiencies for many third parties. Further, the CFPB does not
believe this change is necessary in light of revisions to Sec.
1033.341(c)(1).
Performance Disclosure (Sec. 1033.341(d))
Proposed Sec. 1033.341(d) would have required that a data provider
disclose, in the manner described in proposed Sec. 1033.341(a),
information about the performance of its developer interface for each
month. Specifically, the CFPB proposed that on or before the 10th
calendar day of each month, the data provider would disclose the
quantitative minimum performance specification in proposed Sec.
1033.311(c)(1)(i) achieved in the previous calendar month. The CFPB
proposed to require that the data provider's disclosure include at
least a rolling 13 months of the required monthly figure, except that
the disclosure need not include the monthly figure for months prior to
the compliance date applicable to the data provider. The CFPB proposed
to require that the data provider disclose the metric as a percentage
rounded to four decimal places, such as ``99.9999 percent.''
The CFPB requested comment on whether the final rule should require
data providers to disclose additional performance metrics, including
those required to be disclosed in other jurisdictions' open banking
systems, such as the volume of requests, the number of accounts and/or
consumers with active authorizations, uptime, planned and unplanned
downtime, and response time.
One data aggregator commenter recommended that a final rule include
additional performance metrics. Specifically, this commenter suggested
the disclosures include information about when access caps were put in
place and how long they lasted, uptime, latency, days of planned and
unplanned downtime, and days of notice for unplanned downtime. This
commenter stated that disclosure of these metrics would help the CFPB
determine whether consumers benefit from their data access rights and
identify areas where further guidance or action is advisable. Finally,
this commenter stated that these additional metrics would help third
parties determine if they were being treated in a discriminatory manner
compared to other third parties.
A bank commenter, a research institute commenter, and a bank trade
association commenter stated that ten calendar days after the end of a
month is not enough time to publish performance data for that month on
the grounds that more time is necessary for the data provider to ensure
the accuracy of the data being transmitted. These commenters stated
that it can take more than a week for data providers' internal
databases to populate the required information for the performance
metrics. These commenters suggested that the period for data providers
to disclose performance statistics should be 45 days or, at a minimum,
ten business days after the close of the month. A data provider trade
association also recommended that data providers be able to make these
disclosures on a quarterly basis. By contrast, a data aggregator
commenter suggested that performance data should be available in real
time and on demand on the grounds that real-time availability would
help data providers discover and address security
[[Page 90913]]
vulnerabilities in their developer interfaces.
A bank trade association commenter suggested that the CFPB use more
precise language in Sec. 1033.341(d) as to which disclosures are
intended to be visible to the public, as opposed to disclosures that
should be available only for third parties seeking access to the
developer interface. A bank research institute commenter and a bank
trade association commenter stated that the final rule should allow for
multiple data providers to publish their disclosures of developer
interface performance data in one location. These commenters suggested
that a single location may be more cost-effective for data providers
and might reduce search costs for members of the public seeking to
access disclosures from multiple data providers. Additionally, these
commenters recommended that the CFPB clarify that data providers would
meet the requirements to make performance metrics readily identifiable
to the public if multiple data providers published their metrics in one
location. A bank trade association commenter stated that the proposed
requirement to disclose performance metrics would not result in any
consumer benefit. This commenter further stated that such a requirement
would increase costs for data providers but that consumers cannot
benefit from knowledge of metrics about a process in which consumers do
not directly participate.
For the reasons discussed herein, the CFPB is finalizing the
requirement in Sec. 1033.341(d), with minor modifications. Publicly
available performance data will inform consumers and authorized third
parties about whether a data provider is maintaining commercially
reasonable performance, which will promote data provider
accountability. Contrary to some commenters' belief, performance
metrics will also help consumers who struggle to connect a third party
mobile banking application to their account with a data provider to
understand the source of the issue. As an additional benefit,
consistent with the CFPA's objective under section 1021 that markets
for consumer financial products and services operate transparently and
efficiently to facilitate access and innovation, availability of
performance metrics should also help consumers select a data provider
by allowing them to shop and select a data provider based on their
developer interface performance.
Final Sec. 1033.341(d) requires a data provider to disclose, on or
before the final day of each calendar month, in the manner required by
Sec. 1033.341(a), the quantitative minimum performance specification
for the response rate described in Sec. 1033.311(c)(1)(i) through (iv)
that the data provider's developer interface achieved in the previous
calendar month. The data provider's disclosure must include at least a
rolling 13 months of the required monthly figure, except that the
disclosure need not include the monthly figure for months prior to the
compliance date applicable to the data provider. The data provider must
disclose the metric as a percentage rounded to four decimal places,
such as ``99.9999 percent.'' The final rule also modifies the heading
of Sec. 1033.341(d) to ``Performance disclosure'' to more accurately
reflect the requirement.
Final Sec. 1033.341(d) does not require disclosure of developer
interface performance metrics other than proper response, as defined in
final Sec. 1033.311(c)(1)(i) through (iv). Regarding a commenter's
request that the CFPB require disclosure of additional performance
metrics, the CFPB notes that it did not propose specific definitions
for latency, uptime, or downtime, nor did the commenter provide
definitions. The CFPB believes such metrics would benefit from further
analysis to ensure disclosures are made consistently to enable
meaningful comparisons and analysis of commercially reasonable
performance. The CFPB likewise declines to add disclosures about data
access caps to the final Sec. 1033.341(d). Data access caps must be
reasonable under final Sec. 1033.311(d), but this requirement is not
part of the quantitative minimum performance specification of Sec.
1033.311(c). Access caps may vary based on a number of factors,
including the threshold metric, the type of request, and the period of
time they are in place The proposal did not define how an access cap
(or caps) could be disclosed and the CFPB is concerned such a
disclosure would be complex and disclosed inconsistently, and thus
would not provide meaningful information to the public.
To address commenters' concerns regarding the timing for
disclosures, final Sec. 1033.341(d) provides that data providers must
make their disclosures by the final day of each calendar month, rather
than by the tenth calendar day as proposed. Requiring disclosure by the
end of the next month should give data providers a reasonable amount of
time to run and audit the required reports to calculate the
quantitative minimum performance specification, as this is longer than
the ten business days some commenters suggested as the minimum time
needed to perform these analyses. A full month to disclose the required
performance metrics should promote quality control of the data and will
ensure that the information will be made publicly available on a
predictable basis. Requiring data providers make these disclosures less
frequently, such as on a quarterly basis, would reduce the incentive
for data providers to remedy performance deficiencies in a timely
manner.
Requiring real-time reporting of the quantitative minimum
performance specification as suggested by one commenter, however, is
unlikely to assist in the identification of security vulnerabilities.
This metric merely tracks the rate at which the developer interface
gives proper responses to requests and would likely provide little
insight into whether an update to the interface had introduced a
security vulnerability. The CFPB is thus not adopting a real-time
reporting requirement.
Final Sec. 1033.341(d) carries out the objectives of CFPA
section1033(a).\80\ Publicly available performance data are relevant
for consumers and authorized third parties seeking reliable access to
consumer-authorized data. As an additional benefit, consistent with the
CFPA's objective under section 1021 that markets for consumer financial
products and services operate transparently and efficiently to
facilitate access and innovation, availability of performance metrics
should also help consumers select a data provider by allowing them to
shop and select a data provider based on their developer interface
performance.
---------------------------------------------------------------------------
\80\ The proposal preliminarily relied on section 1032 of the
CFPA, but it is not necessary to rely on that authority in this
final rule.
---------------------------------------------------------------------------
7. Policies and Procedures (Sec. 1033.351)
Reasonable Written Policies and Procedures (Sec. 1033.351(a))
The CFPB proposed in Sec. 1033.351(a) to set forth a general
obligation that data providers establish and maintain written policies
and procedures that are reasonably designed to achieve the objectives
set forth in proposed subparts B and C of the rule, including proposed
Sec. 1033.351(b) through (d). Under the proposal, a data provider
would need to periodically review the policies and procedures required
by proposed Sec. 1033.351 and update them as appropriate to ensure
their continued effectiveness. The CFPB explained that, to minimize
impacts on data providers, including avoiding conflicts with any
overlapping compliance obligations, proposed Sec. 1033.351(a) required
data providers to tailor these policies and
[[Page 90914]]
procedures to the size, nature, and complexity of their activities.
Commenters including banks, third parties, and consumer advocacy
groups, generally supported the proposed requirements for data provider
policies and procedures. One data provider industry commenter
specifically supported the statement that data provider policies and
procedures be appropriate to the size, nature, and complexity of the
data provider's activities. Some commenters recommended revisions to
specific policies and procedures provisions or challenged the CFPB's
authority to issue a particular policies and procedures requirement.
These comments are discussed in more detail in this section below.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.351(a) generally as proposed, with one clarification. Under the
final rule, as proposed, a data provider must establish and maintain
written policies and procedures that are reasonably designed to achieve
the objectives set forth in subparts B and C of the final rule.
Policies and procedures must be appropriate to the size, nature, and
complexity of the data provider's activities. Further, as proposed, a
data provider must periodically review the policies and procedures
required by this section and update them as appropriate to ensure their
continued effectiveness.
In light of comments, the final rule includes new language stating
that a data provider has flexibility to design policies and procedures
to avoid acting inconsistently with its other legal obligations or in a
way that could reasonably hinder enforcement against unlawful or
potentially unlawful conduct. This revision is discussed in more detail
in the discussion of Sec. 1033.351(b)(2), below.
Policies and Procedures for Making Covered Data Available and
Responding to Requests (Sec. 1033.351(b))
Making Covered Data Available (Sec. 1033.351(b)(1))
Proposed Sec. 1033.351(b) would have required data providers to
establish policies and procedures reasonably designed to make covered
data available. Proposed Sec. 1033.351(b)(1) would have required that
the policies and procedures required by proposed Sec. 1033.351(a) are
reasonably designed to ensure that data providers create a record of
the data fields that are covered data in the data provider's control or
possession, what covered data are not made available through a consumer
or developer interface pursuant to an exception in Sec. 1033.221, and
the reasons the exception applies. The CFPB explained that
documentation of the fields that are made available in accordance with
the covered data definition could help the CFPB identify compliance
gaps in what the data provider makes available, streamline negotiations
between data providers and third parties by establishing the available
data fields, and encourage the market to adopt more consistent data
sharing practices.
Under the proposal, a data provider would have been permitted to
comply with the proposed Sec. 1033.351(b)(1) requirement by
incorporating the data fields defined by a qualified industry standard,
provided doing so is appropriate to the size, nature, and complexity of
the data provider's activities. However, exclusive reliance on data
fields defined by such a standard would not be appropriate if such data
fields failed to identify all the covered data in the data provider's
control or possession. The CFPB preliminarily concluded that allowing a
data provider to cite data fields defined by a qualified industry
standard, to the extent that standard identifies covered data in the
data provider's control or possession, could ease the compliance burden
on data providers and promote market standardization according to CFPA
section 1033(d). The CFPB proposed these requirements to facilitate
compliance with and enforcement of the general obligation in proposed
Sec. 1033.201.
The CFPB received some support for the provisions in proposed Sec.
1033.351(b)(1). One Member of Congress supported this requirement,
stating that it would help ensure that consumer data are not withheld
for anticompetitive reasons. Some data provider commenters expressed
concern that the provision's reference to qualified industry standards
would be of little utility to data providers, on the grounds that data
providers would not be able to rely on the qualified industry standard
to demonstrate compliance because such standard likely would not define
all the data in the control or possession of the data provider. One
data provider trade association stated that neither the statutory text
nor the congressional intent of CFPA section 1033 calls for data
providers to create and maintain the enumerated records. This commenter
suggested that data providers already have supervisory obligations and
that the CFPB does not have the authority for streamlining the
negotiations of private commercial actors.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.351(b)(1) with modifications to further clarify what data fields
are required to be made available. Final Sec. 1033.351(b)(1) states
that indicia that a data provider's record of applicable data fields
complies with the requirements of Sec. 1033.351(b)(1) include listing
data fields that conform to those published by a consensus standard.
The final rule does not include the proposed regulatory text that would
have stipulated that exclusive reliance on data fields defined by a
qualified industry standard would not be appropriate if such data
fields failed to identify all the covered data in the data provider's
control or possession. This change conforms Sec. 1033.351(b)(1) to
other parts of the rule that utilize consensus standards as indicia of
compliance. Additionally, the indicia approach addresses commenters'
concerns that such standards may not reflect all of the data in control
or possession of a data provider, while signaling to data providers
that they may have additional data fields beyond the consensus standard
that must be disclosed under the rule. For example, some of the terms
and condition examples in Sec. 1033.211(d) might be data fields that
are not included in a consensus standard but would still be required
under Sec. 1033.351(b)(1).\81\
---------------------------------------------------------------------------
\81\ As discussed in part IV.A.6 (definition of consensus
standard), as a general matter, the indicia of compliance framework
maintains the final rule as the applicable legal standard while
giving due weight to a fair, open, and inclusive consensus standard
as evidence of compliance with the rule.
---------------------------------------------------------------------------
The CFPB is finalizing the other provisions in Sec. 1033.351(b)(1)
largely as proposed. As such, under Sec. 1033.351(b)(1) a data
provider is required to maintain policies and procedures reasonably
designed to ensure that the data provider creates a record of the data
fields of covered data in the data provider's control or possession.
Section 1033.351(b)(1) also requires a data provider to record what
covered data are not made available through a consumer or developer
interface pursuant to an exception in Sec. 1033.221, and the reason(s)
the exception applies.
The CFPB is finalizing Sec. 1033.351(b)(1) pursuant to its
authority provided by CFPA sections 1033(a) and 1022(b)(1). The
policies and procedures in Sec. 1033.351(b) will carry out the
objectives of CFPA section 1033(a) to make available information upon
request by ensuring data providers are accountable for their decisions
to make available covered data in response to requests, and in granting
third parties access to the developer interface.
[[Page 90915]]
Importantly, the policies and procedures required in Sec.
1033.351(b)(1) are intended to ensure ongoing, consistent availability
of the consumer's covered data fields. While data providers may be
subject to supervisory requests for information related to their
current data [filig]elds, as one commenter suggested, such a
supervisory inquiry would likely occur after a consumer is harmed.
Conversely, with proposed Sec. 1033.351(b)(1), the consumer or the
consumer's authorized third party have the opportunity to understand
why covered data was not made available and potentially raise an issue
with the data provider, or alternatively to adjust their own future
requests for covered data to avoid repeated denials.
Efficiencies in onboarding third parties onto data providers'
developer interfaces will enable the CFPB to administer and carry out
the objectives of CFPA section 1033(a) to make available information
upon request as well as the standardization objectives of CFPA section
1033(d). Creating a record of what data fields are covered data in the
control or possession of the data provider will further the objectives
of CFPA section 1033(a) and Sec. 1033.211, by defining what
constitutes ``covered data'' with respect to the data provider under
the rule. Further, the record of data fields required under Sec.
1033.351(b)(1) will ensure that data providers carry out their
obligation to make ``covered data'' available, and that data providers
do so in a consistent, objective manner, that can be reviewed and
compared with data providers' actual practices by regulators in the
course of supervisory and enforcement activities. This will ensure data
providers are consistently making data available to all third parties
and will reduce the costs of the onboarding process, which has been a
problem in the past. This standardization is consistent with the
objectives of CFPA section 1033(d).
Denials of Requests for Developer Interface Access and Requests for
Information (Sec. 1033.351(b)(2) and (3))
Proposed Sec. 1033.351(b)(2) would have required data providers to
have policies and procedures that are reasonably designed to ensure
that when a data provider denies a third party access to a developer
interface pursuant to Sec. 1033.321, the data provider: (1) creates a
record explaining the basis for denial; and (2) communicates to the
third party, electronically or in writing, the reason(s) for the
denial, and that the communication occurs as quickly as is practicable.
Additionally, under proposed Sec. 1033.351(b)(3) a data provider would
have been required to reasonably design its policies and procedures to
ensure that when it denies a request for information pursuant to Sec.
1033.331, the data provider: (1) creates a record explaining the basis
for denial; and (2) communicates to the consumer or the third party,
electronically or in writing, the type(s) of information denied and the
reason(s) for the denial, and that the communication occurs as quickly
as is practicable. The CFPB requested comment on whether the final rule
should provide examples or further clarify how data providers could
reasonably design policies and procedures to account for data security
or risk management concerns.
A third party commenter and a consumer advocacy group commenter
recommended that the data provider be required to explain what actions
or steps a consumer or third party must take to address a denial under
proposed Sec. 1033.351(b)(2) and (3). A bank trade association
suggested that some third parties may be on a sanctions list \82\ and
asked the CFPB to clarify that the data provider does not need to
engage with these third parties or inform them of the reason for the
denial. Additionally, one bank commenter suggested that under proposed
Sec. 1033.351(b)(3) it would be difficult for a data provider to
communicate to a consumer why a Sec. 1033.331 denial occurred, on the
grounds that this denial would typically happen before the data
provider authenticated the consumer's identity. Finally, a bank trade
association commenter suggested that the CFPB clarify that records
explaining why a data provider denied a particular request do not need
to include the data provider's specific risk management conclusions, on
the grounds that divulging specific risk management information could
present additional security risks to the data provider.
---------------------------------------------------------------------------
\82\ For example, a list released by the OFAC, such as the
Specially Designated Nationals and Blocked Persons list.
---------------------------------------------------------------------------
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.351(b)(2) and (3) with certain revisions discussed below. Section
1033.351(b)(2) and (3) will carry out the objectives of CFPA section
1033 by enabling consumers and prospective authorized third parties to
understand and satisfy data provider conditions necessary to make
requests. Additionally, these provisions will prevent evasion by
ensuring data providers do not avoid their obligations under CFPA
section 1033 by denying developer interface access or information
requests for unstated impermissible reasons.
Under final Sec. 1033.351(b)(2) a data provider is required to
reasonably design its policies and procedures to ensure that when the
data provider denies a third party access to a developer interface
pursuant to Sec. 1033.321, the data provider: (1) creates a record
substantiating the basis for denial; and (2) communicates in a timely
manner to the third party, electronically or in writing, the reason(s)
for the denial. Likewise, under final Sec. 1033.351(b)(3), a data
provider is required to reasonably design its policies and procedures
to ensure that when the data provider denies a request for information
pursuant to Sec. 1033.331, to the extent the communication of the
denial is not required to be standardized by Sec. 1033.311(b), the
data provider: (1) creates a record substantiating the basis for
denial; and (2) communicates in a timely manner to the consumer or
third party, electronically or in writing, the type(s) of information
denied, if applicable, and the reason(s) for the denial.
The final rule revises the ``as quickly as practicable'' language
from proposed Sec. 1033.351(b)(2) and (3) to ``in a timely manner'' to
conform to similar language about timeliness used in the regulation in
the example to Sec. 1033.331(b) and in Sec. 1033.331(e), and is not
intended as a substantive change. For clarity, the final rule clarifies
that the requirement for policies and procedures to be designed to
communicate the reasons for denials applies to when a denial occurs for
a reason described in Sec. 1033.331(c), as discussed in part IV.C.5
above, Sec. 1033.331(c) cross-references the provisions of the rule
that allow a data provider to deny a request for information.
Additionally, the final rule requires policies and procedures to
provide information when information is denied pursuant to a consumer
or third party request ``if applicable.'' A request for information
will not always be denied for reasons related to specific information
requested. For example, a denial under Sec. 1033.331 could occur due
to the data provider not having sufficient information to authenticate
or confirm authorization under Sec. 1033.331(a) and (b), or because
the interface is unavailable, and thus there would be no specific
information to be specified in those cases.
Section 1033.351(b)(2) and (3) will provide data providers rule
with appropriate flexibility to allow them to comply with other
regulatory obligations, while still generally enabling consumers and
third parties to understand reasons for denials in a
[[Page 90916]]
timely manner and reduce the potential for pretextual denials. Without
these policies and procedures requirements, compliance obligations with
Sec. Sec. 1033.321 and 1033.331 would be difficult to administer,
ultimately harming the consumer as a result.
Revisions in Sec. 1033.351(b)(3) are intended to distinguish
denials from the standardized format requirement in Sec. 1033.311(b).
The text in Sec. 1033.351(b)(3) retains the ability of the data
provider to have flexible policies and procedures governing denials of
information requests. These denials differ, somewhat, from Sec.
1033.311(b) error codes, because the conditions of Sec. 1033.331(b)
are not intended to impose specific expectations as to how the data
provider considers these conditions, whereas Sec. 1033.311(b) error
codes have more prescriptive requirements, as discussed in this section
below.
For purposes of Sec. 1033.351(b)(3), a denial of an information
request occurs when the data provider does not make data available
pursuant to Sec. 1033.331(c). Such a denial might be communicated
pursuant to standardized communication protocols under Sec.
1033.311(b), such as through an error code. These communication
protocols might also include communications of other responses that are
not denials but are relevant to fulfilling the request. For example,
when an authorized third party requests a nonexistent data field, under
Sec. 1033.311(b) a standardized response is required to be given to
the requestor, informing them of the deficient request. Conversely,
under a Sec. 1033.351(b)(3) denial, a data provider is informing the
requestor that they are not being granted access to particular
information in the developer interface pursuant to Sec. 1033.331.
After this communication, the data provider's obligations to the
consumer or third party are satisfied, save for the records to be
retained under Sec. 1033.351(d). Under Sec. 1033.351(d)(2)(i) and
(ii), discussed below, a data provider must establish and maintain
policies and procedures to retain records of, among other things,
requests for a third party's access to an interface and records of
requests for information. Additionally, under final Sec.
1033.351(d)(2)(v), a data provider must establish and maintain policies
and procedures to retain records of Sec. 1033.311(c)(2) commercially
reasonable performance specifications. Accordingly, records of both
standardized error code denials pursuant to Sec. 1033.311(c)(2) and
denials of information requests under Sec. 1033.351(b)(3) must be
retained.
For clarity, final Sec. 1033.351(b)(2)(i) and (3)(i) uses
``substantiating'' in place of ``explaining.'' The proposed rule used
the terms interchangeably. The use of ``substantiate'' in the final
rule clarifies that associated evidence for the denial should be
retained as part of the data provider's required policies and
procedures. Additionally, this change will not create a substantial
documentation burden for data providers, given that these records are
already being kept. Including a requirement for data providers to
explain the process for the consumer or third party to remedy a reason
for denial, as suggested by some commenters, would be an unnecessary
addition to the final rule. The CFPB did not propose these appeal
processes, and, if there were a denial under Sec. 1033.351(b)(3), the
process would be for the consumer or third party to again request
access to the covered data after correcting the deficiency explained
under Sec. 1033.351(b)(3)(ii). If the data provider denied a valid
request, then the data provider would likely be in violation of the
prohibition against evasion in Sec. 1033.201(a)(2).
One commenter was concerned that it would be difficult for a data
provider to communicate to a consumer why a Sec. 1033.331 denial
occurred when the denial occurs before the data provider has
authenticated the consumer's identity. Proposed Sec. 1033.351(b)(3)
would not have required a data provider to communicate why a denial has
occurred before the data provider has authenticated a consumer's
identity. If a data provider denies a request because the data provider
has not authenticated the consumer, Sec. 1033.351(d)(3)(ii) would
simply require that, pursuant to reasonable policies and procedures,
the data provider communicate that the data provider had not
authenticated the consumer.
The CFPB understands that in limited cases, disclosure of the
specific reason for a denial of access to an interface or for
information on an interface might be prohibited by law or otherwise be
inconsistent with compliance obligations or hinder law enforcement.
Proposed Sec. 1033.351(a) sought to provide flexibility to data
providers in designing their policies and procedures regarding denials
of information or interface access by providing in Sec. 1033.351(a)
that policies and procedures must be ``appropriate to the size, nature,
and complexity of the data provider's activities.''
The CFPB believes this language alone would have been sufficient to
provide data providers flexibility to avoid acting in a manner
inconsistent with legal obligations or effective law enforcement.
However, given the nature of concerns in this context, the CFPB
believes it will facilitate compliance to more clearly state in final
Sec. 1033.351(a) that a data provider has flexibility to design
policies and procedures to avoid acting inconsistently with its other
legal obligations, or in a way that could reasonably hinder enforcement
against unlawful or potentially unlawful conduct. A reasonable policy
and procedure designed to communicate the reasons for a denial of
information or access would not mandate communication or disclosure of
material that would require a data provider to violate the law or
hinder law enforcement. For example, Sec. 1033.351(b)(2) does not
require a data provider to inform a third party that a ``Suspicious
Activity Report'' was involved in a decision to deny information or
interface access, because including such information could undermine
ongoing and future law enforcement investigations by tipping off
suspects or present other risks.
However, even if data providers have a legitimate basis not to
communicate the reason for a denial, under Sec. 1033.351(b)(2)(i) and
(b)(3)(i) the data provider must create a record substantiating the
basis for denial. For example, a data provider that denies a third
party access pursuant to safety and soundness concerns, must create a
record that substantiates the basis for the denial under Sec.
1033.321(a). Under Sec. 1033.351(d), the data provider's policies and
procedures must account for retention of that record, but the final
rule does not require that this record be disclosed to consumers or
third parties. Denials of access or information present significant
risks of frustrating congressional intent, and Sec. 1033.351(b)(2)(i)
and (3)(i) helps ensure compliance with data providers' core obligation
under the rule to make covered data available.
Policies and Procedures for Ensuring Accuracy (Sec. 1033.351(c))
Under proposed Sec. 1033.351(c)(1), the policies and procedures
data providers would be required to establish and maintain by proposed
Sec. 1033.351(a) must be reasonably designed to ensure that covered
data are accurately made available. Proposed Sec. 1033.351(c)(2)
listed elements that data providers would need to consider when
designing their policies and procedures regarding accuracy, for
example: (1) implementing the format requirements of proposed Sec.
1033.311(b); and (2) addressing information provided by a consumer or a
third party regarding inaccuracies in
[[Page 90917]]
the covered data made available through its developer interface. Under
proposed Sec. 1033.351(c)(3), indicia that a data provider's policies
and procedures regarding accuracy are reasonable would include whether
they conform to a qualified industry standard regarding accuracy. The
proposed rule explained that a qualified industry standard regarding
accuracy is relevant to the reasonableness of a data provider's
policies and procedures because it reflects the openness, balance,
consensus, transparency, and other requirements of proposed Sec.
1033.141.
The CFPB preliminarily determined that a data provider's policies
and procedures should focus on the accuracy of transmission rather than
the underlying accuracy of the information in the data provider's
systems. The CFPB clarified that this means the policies and procedures
should be designed to ensure that the covered data that a data provider
makes available through its developer interface matches the information
that it possesses in its systems. The CFPB explained that it was likely
the data provider was already subject to several legal requirements
regarding accuracy, such as Regulation E's protection of consumers
against errors, and Regulation Z's protection of consumers against
billing errors. See 12 CFR part 1005; 12 CFR 1026.13. The CFPB sought
comment on whether the final rule should include additional elements
bearing on the reasonableness of a third party's policies and
procedures regarding accuracy.
Few commenters expressed concerns regarding proposed Sec.
1033.351(c). At least one bank trade association commenter, one
research institute commenter and one Member of Congress supported the
proposed rule's focus on the accuracy of transmission rather than the
underlying accuracy of the information in the data provider's systems.
The research institute commenter went further to say the CFPB should
consider adding ``accuracy testing'' as an element of reasonableness
for purposes of Sec. 1033.351(c). A consumer advocacy group commenter
recommended that the CFPB include dispute resolution requirements in
Sec. 1033.351(c), explaining that some regulatory regimes, such as the
regulations enumerated in the proposal, have strict time limits for
exercise of their dispute rights. Finally, a bank commenter opposed the
reference to qualified industry standards in proposed Sec.
1033.351(c)(3), stating that industry standard-setting organizations
are not well positioned to weigh in on the adequacy of accuracy
policies and procedures, and generally have not done so to date.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.351(c) as proposed with one terminology change. Section
1033.351(c) is authorized under CFPA section 1033(a) for the reasons
stated above in the discussion of Sec. 1033.351(a) as well as under
CFPA section 1033(d). Policies and procedures for accuracy will promote
the use and development of standardized formats by ensuring data
providers are taking reasonable measures to share covered data in
standardized formats. The CFPB has determined the mechanisms in part
1033, including the requirements in Sec. 1033.311(b) with respect to
standardized formats (discussed in part IV.C.3), are sufficient to
ensure data providers transmit information accurately. There is
insufficient information in the current rulemaking record that
establishes that more detailed procedures are necessary to resolve
disputes regarding inaccurately transmitted covered data. The CFPB will
monitor the market and engage in future rulemaking, as necessary.
With respect to the role of consensus standards in Sec.
1033.351(c), recognized standard setters are well-suited to address the
adequacy of accuracy policies and procedures. A consensus standard (as
revised from the term qualified industry standard used in the proposal)
regarding accuracy may be relevant to the reasonableness of a data
provider's policies and procedures because it is produced through a
process that takes into account the perspectives of all parties making
available, receiving, and using covered data, consistent with the
openness, balance, consensus, transparency, and other requirements of
Sec. 1033.141. Such standards, used in connection with accuracy
policies and procedures, may indicate that covered data transmitted
pursuant to an applicable consensus standard will be usable by
authorized third parties.
Policies and Procedures for Record Retention (Sec. 1033.351(d))
Proposed Sec. 1033.351(d) would have provided that the policies
and procedures required by Sec. 1033.351(a) must be reasonably
designed to ensure retention of records that are evidence of compliance
with proposed subparts B and C of part 1033. The proposal's preamble
explained that these requirements would give data providers flexibility
to craft policies and procedures that are appropriate to the ``size,
nature, and complexity'' of the individual data provider's activities,
as required by proposed Sec. 1033.351(a). The CFPB explained that this
flexibility was intended to help data providers avoid conflicts with
other legal obligations, manage data security risks, and minimize
unnecessary impacts, consistent with the SBREFA Panel's recommendation.
Additionally, under proposed Sec. 1033.351(d)(1), records related
to a data provider's response to a consumer's or third party's request
for information or a third party's request to access a developer
interface would have had to be retained for at least three years after
a data provider has responded to the request. The CFPB explained that
this duration would provide sufficient time to administer enforcement
of proposed subparts B and C. The proposed rule also stated that all
other records that are evidence of compliance with subparts B and C of
part 1033 would need to be retained for a reasonable period of time.
To mitigate the risk that the flexibility of the record retention
policies and procedures proposal might result in the absence of
critical evidence of compliance, proposed Sec. 1033.351(d)(2)
identified examples records that would need to be retained. Proposed
Sec. 1033.351(d)(2) would have required that records retained pursuant
to policies and procedures under proposed Sec. 1033.351(a) include,
without limitation: (1) records of requests for a third party's access
to an interface, actions taken in response to such requests, and
reasons for denying access, if applicable; (2) records of requests for
information, actions taken in response to such requests, and reasons
for not making the information available, if applicable; (3) copies of
a third party's authorization to access data on behalf of a consumer;
and (4) records of actions taken by a consumer and a data provider to
revoke a third party's access pursuant to any revocation mechanism made
available by a data provider. The CFPB requested comment on the types
of records that should be retained, the length of the retention period,
and the date from which the retention obligation should be measured.
Commenters generally supported the proposal. Some bank trade
association commenters supported proposed Sec. 1033.351(d)'s measuring
of the retention period from the time of response, and at least one
such commenter supported the proposed three-year retention period. Some
data provider commenters suggested that the retention period be for a
shorter duration, such as two years, which they stated would be similar
to the record retention requirements of Regulations E and Z and would
reduce the amount of
[[Page 90918]]
time records could be exposed to security risks. One trade association
recommended that the final rule reduce the retention period applicable
to responses to requests made through the developer interface. Some
third party commenters recommended that the final rule include records
of data providers' limitations of third party access, and that all
communications of denials be submitted to the CFPB on a rolling basis.
A trade association stated that retaining records on all third party
requests would be unduly burdensome for data providers. Data provider
commenters recommended that the final rule clarify that the provision
does not require the retention of every login to the consumer interface
or copies of data made available through the developer interface,
explaining that such a retention would lead to significant costs. One
bank commenter suggested that the final rule clarify what is meant by
``copies of a third party's authorization'' in proposed Sec.
1033.351(d)(2)(iii). The commenter stated this could be interpreted by
some data providers as a requirement to obtain and retain a copy of the
full authorization disclosure provided by the third party to the
consumer on the third party's own website or mobile application, which
would be very hard for data providers to operationalize. Additionally,
one trade association recommended that retaining records on all third
party requests would be unduly burdensome for data providers. Further,
some data provider commenters asserted that proposed Sec. 1033.351(d)
conflicts with CFPA section 1033(c), which provides that ``[n]othing in
[CFPA section 1033] shall be construed to impose any duty on a covered
person to maintain or keep any information about a consumer.''
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.351(d) with revisions to conform terminology and clarify the types
of records to be retained, as well as revisions to specify the duration
for which records should be retained pursuant to policies and
procedures.
Retention Period (Sec. 1033.351(d)(1))
Final Sec. 1033.351(d)(1) provides that records that are evidence
of a data provider's actions in response to a consumer's or third
party's request for information or a third party's request to access a
developer interface must be retained for at least three years after a
data provider has responded to the request. All other records that are
evidence of compliance with subparts B and C of part 1033 must be
retained for a reasonable period of time of at least three years from
the date of the action required under subparts B and C of part 1033.
Final Sec. 1033.351(d)(1) revises the proposed language to the
general obligation to clarify the nature of records to be retained
pursuant to policies and procedures. The proposal described records
``related to'' a data provider's response to a consumer's or third
party's request for information or a third party's request to access a
developer interface. The final rule contains new language clarifying
that data providers must retain records ``that are evidence of'' a data
provider's ``actions in response to'' a consumer's or third party's
request for information or access to a developer interface.'' Including
the phrase ``evidence of'' in the first sentence of Sec.
1033.351(d)(1) is more consistent with the language used in the second
sentence of that paragraph. For purposes of Sec. 1033.351(d), relevant
records are those that demonstrate overall fulfillment of requests for
information. The final rule does not require retention of metadata
related to individual consumer logins or activity on the consumer
interface. Similarly, data providers do not need to retain copies of
every request to the developer interface, or copies of data elements
made available in response to each request, to the extent requests are
fulfilled.
Section 1033.351(d)(1) must be read together with Sec.
1033.351(a), which states, ``[p]olicies and procedures must be
appropriate to the size, nature, and complexity of the data provider's
activities.'' For example, to the extent data providers fulfill
consumer or third party requests, accurate aggregate data evidencing
fulfillment, such as evidence of general availability of a consumer
interface or a developer interface, would comply with Sec.
1033.351(d). Of course, additional records would be necessary to the
extent data providers do not make data available to consumers or third
parties. For instance, if all or part of a consumer or developer
interface is unavailable for a period of time to all consumers and
third parties, data providers could retain records of the general
unavailability of the interface. More detailed records will need to be
retained to demonstrate maintenance of other policies and procedures
requiring the creation of records, such as Sec. 1033.351(b)(2)(i) and
(b)(3)(i) with respect to records of denials of interface access and
information requests. A data provider also might need to retain
detailed information for some period of time as part of other policies
and procedures required under Sec. 1033.351. For instance, data
providers might need to retain some information about responses to
third party requests as part of maintaining accuracy-related policies
and procedures pursuant to Sec. 1033.351(c)(2)(ii).
Section 1033.351(d)(1) requires that records providing evidence of
a data provider's actions in response to a consumer's or third party's
requests for information and records of a third party's request to
access a developer interface must be retained for at least three years
after a data provider has responded to the request. The nature of the
records retained will determine the most appropriate method of
demonstrating compliance with this retention period.
In response to requests for clarity of the phrase ``reasonable
period of time'' in the second sentence of Sec. 1033.351(d)(1), final
Sec. 1033.351(d) includes new language specifying a more concrete
period. Final Sec. 1033.351(d) states, ``[a]ll other records that are
evidence of compliance with subparts B and C of this part must be
retained for a reasonable period of time of at least three years from
the date of the action required under subparts B and C of this part.''
This aligns with the time period referenced in the first sentence with
respect to responses to requests for information and access.
The CFPB believes a three-year record retention period set forth in
Sec. 1033.351(d)(1) is an appropriate duration to ensure retention of
records that evidence compliance with data provider obligations under
subparts B and C. Regulations E and Z, as codified in 12 CFR part 1005
and 12 CFR part 1026, respectively, implement EFTA and TILA, and the
record retention requirements under Regulations E and Z offered for
comparison by commenters are substantively different from that under
Sec. 1033.351(d). Records required under Regulation E and Regulation Z
relate to regulated entities' disclosures to consumers pertaining to
electronic fund transfers and consumer credit, respectively. Such
disclosures to individual consumers are likely to be stale after a
period of two years. Three years of records will allow for analysis of
the patterns in a data provider's compliance with part 1033 over time.
Moreover, based on the CFPB's supervisory and enforcement experience, a
three-year retention period is an appropriate amount of time to enable
the CFPB and other enforcement agencies to examine or conduct
enforcement investigations. A shorter record retention period would
make it more difficult to ensure that the necessary records are
available.
[[Page 90919]]
The CFPB is issuing final Sec. 1033.351(d) pursuant to CFPA
section 1022(b)(1), which authorizes the CFPB to 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,
including carrying out the objectives of CFPA section 1033, and to
prevent evasions thereof. Section 1033.351(d) will assist the CFPB and
other enforcement agencies with administering CFPA section 1033 by
ensuring records are available to evaluate compliance with data
providers' obligations under the rule. CFPA section 1033(c) does not
indicate otherwise, for two independent reasons. First, Sec.
1033.351(d) is a rule issued pursuant to CFPA section 1022(b)(1), while
section 1033(c) is a rule of construction concerning ``this section,''
i.e., CFPA section 1033. Second, Sec. 1033.351(d) does not require
data providers to keep records ``about a consumer.'' Rather, it
requires data providers to establish policies and procedures to
maintain records related to their compliance with part 1033.
Final Sec. 1033.351(d) does not override congressional intent with
respect to CFPA section 1033(b)(4) or (c). Final Sec. 1033.351(d) only
requires records providing evidence of compliance with subparts B and C
of part 1033, and pursuant to Sec. 1033.221, data providers are not
required to make available any covered data that falls under the
statutory exceptions at CFPA section 1033(b). Nor does Sec.
1033.351(d) require data providers to maintain the underlying covered
data that must be made available pursuant to CFPA section 1033(a).
Certain Records Retained Pursuant to Policies and Procedures (Sec.
1033.351(d)(2))
As proposed, final Sec. 1033.351(d)(2) provides, ``Records
retained pursuant to policies and procedures required under paragraph
(a) of this section must include'' categories enumerated in subsequent
paragraphs, ``without limitation.'' The CFPB is finalizing the
enumerated categories under Sec. 1033.351(d)(2) with revisions to
clarify the types of records to be retained, and other revisions to
clarify how the three-year period in Sec. 1033.351(d)(1) applies to
those records. In response to questions about the types of records
required and to conform to language in final Sec. 1033.351(d)(1), some
provisions refer to requiring records ``providing evidence of'' certain
activity, discussed below. To provide greater clarity on how the three-
year time period applies to the requirements of subparts B and C, final
Sec. 1033.351(d) includes additional categories of records that a data
provider's policies and procedures must include and how the three-year
period applies, as discussed below.
Final Sec. 1033.351(d)(2)(i) specifies records documenting
requests for a third party's access to an interface, actions taken in
response to such requests, and reasons for denying access, if
applicable, for at least three years after the data provider has
responded to the request. Proposed Sec. 1033.351(d)(2)(i) specified
that data provider policies and procedures must include ``records of''
requests for a third party's access to an interface, actions taken in
response to such requests, and reasons for denying access, if
applicable; and did not specify a retention period.
Final Sec. 1033.351(d)(2)(i) revises this language to clarify that
data providers' policies and procedures must include records
``documenting'' requests for third party access, actions taken, and
reasons for denying access, if applicable. The term ``documenting'' is
intended to clarify that policies and procedures must be designed to
capture documentary evidence of requests to access the interface, and
can include but does not require retention of actual copies of
information. The CFPB is making this revision in light of how
consequential granting access to a third party is, with respect to the
number of consumers potentially affected by the decision, the risks of
pretextual denials, and the complex factors involved in granting
access, as discussed in part IV.C.4 with respect to Sec. 1033.321. The
final rule also includes new language clarifying how the three-year
period applies to these records. Records documenting decisions around
onboarding will be particularly important for enforcement of Sec. Sec.
1033.201 and 1033.321.
Final Sec. 1033.351(d)(2)(ii) specifies records providing evidence
of fulfillment of requests for information, actions taken in response
to such requests, and reasons for not making the information available,
if applicable, for at least three years after the data provider has
responded to the request. Proposed Sec. 1033.351(d)(2)(ii) would have
required a data provider's policies and procedures to include ``records
of'' requests for information, actions taken in response to such
requests, and reasons for not making the information available, if
applicable; and did not specify a retention period. The final rule
revises the language with respect to requests for information to
records ``providing evidence of fulfillment of requests.'' This
revision is intended to clarify the scope of records required, as
discussed above with respect to Sec. 1033.351(d)(1).
Final Sec. 1033.351(d)(2)(iii) specifies records documenting that
the third party has followed the authorization procedures in Sec.
1033.401 to access data on behalf of a consumer, for at least three
years after such records are generated. Proposed Sec.
1033.351(d)(2)(iii) would have required data provider policies and
procedures to include ``[c]opies of a third party's authorization to
access data on behalf of a consumer,'' and would not have specified a
retention period. The final rule revises that language to refer to
``[r]ecords documenting that the third party has followed the
authorization procedures,'' to conform to the language in Sec.
1033.331(b)(1)(iii). The final rule recognizes that, by virtue of its
transmission to the data provider through the developer interface, the
authorization disclosure received by the data provider might not be
identical to the form received by the third party.
Final Sec. 1033.351(d)(2)(iv) specifies records providing evidence
of actions taken by a consumer and a data provider to revoke a third
party's access pursuant to any revocation method made available by a
data provider, for at least three years after the revocation. Proposed
Sec. 1033.351(d)(2)(iv) would have required data provider policies and
procedures to include ``records of'' actions taken by a consumer and a
data provider to revoke a third party's access pursuant to any
revocation ``mechanism'' made available by a data provider; and would
not have specified a retention period. Final Sec. 1033.351(d)(2)(iv)
uses the phrase ``records providing evidence of'' to clarify that
identical records are not required. In addition, Sec.
1033.351(d)(2)(iv) uses the term ``method'' rather than ``mechanism,''
to conform this provision to final Sec. 1033.331(e).
The final rule also specifies in Sec. 1033.351(d)(2) three
categories of records that would need to be retained for a three-year
period: evidence of commercially reasonable performance specifications
(Sec. 1033.351(d)(2)(v)), written policies and procedures required
under Sec. 1033.351 (Sec. 1033.351(d)(vi)), and disclosures made
under proposed Sec. 1033.341 (Sec. 1033.351(d)(2)(vii)). Although the
proposal did not specify that data providers' policies and procedures
regarding recordkeeping include these records, proposed Sec.
1033.351(d)(2) indicated that the records specified were not
exhaustive. As noted above, proposed Sec. 1033.351(d) stated that
``[t]he policies and procedures required
[[Page 90920]]
by paragraph (a) of this section must be reasonably designed to ensure
retention of records that are evidence of compliance with subparts B
and C of this part.'' Proposed Sec. 1033.351(d)(2) stated that records
retained pursuant to policies and procedures required under paragraph
(a) of this section must include, ``without limitation,'' certain
categories of records.
Final Sec. 1033.351(d)(2)(v) specifies records of commercially
reasonable performance described in Sec. 1033.311(c)(2)(ii), for at
least three years after the period recorded, which will enable
enforcement and supervision of final Sec. 1033.311(c). Final Sec.
1033.351(d)(2)(vi) specifies written policies and procedures required
under Sec. 1033.351 for three years from the time such material was
last applicable. And final Sec. 1033.351(d)(2)(vii) specifies
disclosures required under Sec. 1033.341, for three years from the
time such material was disclosed to the public.
A commenter's suggestion to explicitly require data providers to
keep records that demonstrate justification for limiting third party
access is already covered in the rule. As proposed, final Sec.
1033.351(d)(2)(ii) requires policies and procedure to create
``[r]ecords of requests for information,'' as well as the ``actions
taken in response to such requests.'' The final rule does not require
data providers to report access denials monthly. Such a requirement
would be burdensome without significant additional benefit. Data
providers must have policies and procedures to substantiate reasons for
denying access under Sec. 1033.351(b) and the CFPB believes
administrative enforcement and supervision will be sufficient to
monitor compliance.
D. Subpart D--Authorized Third Parties
1. Overview
Subpart D establishes authorization procedures and obligations for
third parties seeking to access covered data from data providers
pursuant to the final rule's framework. The authorization procedures
require a third party to obtain the consumer's express informed consent
to the third party's access of the consumer's covered data. The third
party must provide the consumer with an authorization disclosure that
meets certain content and other requirements set forth in subpart D.
Among other things, the authorization disclosure must include a
statement whereby the third party certifies that it will meet the third
party obligations set forth in subpart D, including limits on the third
party's collection, use, and retention of the consumer's covered data.
Subpart D also includes specific requirements that apply when the third
party is using a data aggregator, and policy and procedure requirements
related to record retention that apply if the third party is also a
covered person or service provider pursuant to the CFPA.
Similar to the final rule, the proposed rule would have included
authorization procedures and third party obligations designed to ensure
that third parties accessing covered data pursuant to the rule's
framework are acting on behalf of the consumer whose covered data are
being accessed. It would have also included specific requirements that
apply when a third party is using a data aggregator and policy and
procedure requirements related to retaining evidence of compliance. A
wide variety of commenters, including data providers, third parties,
research institutes, consumer advocates, and a Member of Congress,
generally supported the proposed approach to authorized third party
data access in subpart D. As discussed below, other commenters
expressed concerns about the proposed approach, including concerns
related to the CFPB's legal authority.
Legal Authority
Some commenters asserted that the CFPB lacks the legal authority
for some or all of the provisions in proposed subpart D. Specifically,
a law firm commenter described authorized third parties as consumers'
agents and asserted that the CFPB lacks authority to prescribe how
consumers authorize agents to access data or how agents later use that
data. A trade association for nondepositories argued that the third
party obligations should not limit a third party's collection and use
of covered data. This commenter argued that the proposed rule
conflicted with traditional agency law, which permits an agent to take
an action that does not necessarily benefit the principal.\83\ They
further contended that the proposed rule would impermissibly override
consumers' choices regarding how third parties authorized to receive
data may later use that data.
---------------------------------------------------------------------------
\83\ This commenter cited the Restatement (Third) of Agency
(2006).
---------------------------------------------------------------------------
Other commenters criticized subpart D but for opposite reasons.
Specifically, these commenters argued that the proposed approach
exceeded the CFPB's authority because it would give an overly broad set
of third parties access to covered data. According to one third party
commenter, the term ``representative'' should be read as similar to,
and connected with, ``agent'' and ``trustee'' in accordance with the
interpretive canon that ``a word is known by the company it keeps'' and
the canon that when ``a more general term follows more specific terms
in a list, the general term is usually understood to embrace only
objects similar in nature to those objects enumerated by the preceding
specific words.'' \84\ According to this commenter, representatives
must have a fiduciary relationship with the consumer similar to a
principal-agent and trustor-trustee relationship.\85\ The commenter
argued that it would be inappropriate to allow entities that deal with
consumers at arm's length in the marketplace and are not in a fiduciary
relationship with the consumer to act as authorized third parties.
Similarly, two trade associations for credit unions asserted that third
party access on behalf of a consumer should be limited to situations
where the third party and consumer have a legal relationship that
necessitates the access.
---------------------------------------------------------------------------
\84\ The commenter quoted Dubin v. United States, 599 U.S. 110
(2023), and Epic Sys. Corp. v. Lewis, 584 U.S. 497 (2018).
\85\ The commenter cited the Restatement (Third) of Agency
(2006) and also the Restatement (Third) of Trusts (2003).
---------------------------------------------------------------------------
As discussed in more detail below in part IV.D.4 regarding third
party obligations, some commenters asserted that the CFPB lacked
authority regarding certain proposed limits on an authorized third
party's use of covered data.
After considering the comments discussed above as well as other
relevant comments discussed throughout part IV.D, the CFPB has
determined that the provisions in subpart D align with congressional
intent and are within the CFPB's rulemaking authority. The plain
language of CFPA section 1033(a) provides that, subject to rules
prescribed by the CFPB, a covered person shall make available to a
``consumer,'' upon request, certain information in the control or
possession of the covered person. CFPA section 1002(4) defines
``consumer'' as ``an individual or an agent, trustee, or representative
acting on behalf of an individual.'' \86\ For convenience, part 1033
generally refers to the individual as the ``consumer'' and an agent,
trustee, or representative acting on behalf of that individual as an
``authorized third party.'' As noted elsewhere, the substance of the
rule aligns with the CFPA's definition of
[[Page 90921]]
consumer, and nothing in the CFPA prevents the CFPB from using
different vocabulary within the rule.
---------------------------------------------------------------------------
\86\ For example, Merriam Webster defines ``on behalf of'' to
mean ``in the interest of.'' https://www.merriam-webster.com/dictionary/on%20behalf%20of.
---------------------------------------------------------------------------
The provisions in subpart D are designed to ensure that, consistent
with carrying out the objectives of CFPA section 1033, consumers
provide informed consent to third parties that access covered data
pursuant to the final rule's framework, that consumers retain control
over third parties' access, and that third parties act on behalf of
consumers when collecting, using, and retaining covered data pursuant
the final rule's framework. Accordingly, the final rule requires third
parties accessing covered data pursuant to the final rule's framework
to adhere to the authorization procedures and third party obligations
in subpart D, including the specific requirements for data aggregators
(as applicable). These authorization procedures and third party
obligations ensure that third parties accessing a consumer's covered
data are acting on the consumer's behalf. They ensure the consumer is
effectively informed about and has provided meaningful consent for the
third party's collection, use, and retention of the consumer's covered
data, and that the consumer retains the ability to control access to
that covered data. The authorization procedures and third party
obligations also ensure that the third party's access to covered data
accords with the consumer's intent and reasonable expectations and is
for the consumer's benefit.
As noted above, commenters relied upon an analogy between the
definition of ``consumer'' in CFPA section 1002(4) and agency law, but
they drew opposite conclusions from that analogy. The final rule
establishes that a third party has a duty to act for the principal's
benefit in its collection, use, and retention of data, which is in line
with well-established principles of agency law. Under agency law, an
agent is required to subordinate the agent's interests to those of the
principal and to place the principal's interests first on all matters
connected with the agency relationship.\87\ Similarly, here, the final
rule limits third party collection, use, and retention of covered data
to what is reasonably necessary to provide the consumer's requested
product or service. Furthermore, as a commenter indicated, agency law
does sometimes permit a principal to consent to conduct by an agent
that would otherwise breach the agent's duties to the principal, but
only if the consent is the product of an adequately informed judgment
by the principal.\88\ Likewise, as explained below, the final rule
permits third parties to access covered data for certain purposes,
including targeted advertising, cross-selling of other products or
services, and data sales, if data access for these purposes are
separately authorized as a standalone product or service. Including
those purposes as part of an authorization for the consumer's requested
product or service would run contrary to the third party's obligations
to the consumer. However, where the consumer affirmatively requests
targeted advertising, cross-selling of other products and services, or
data sales, the third party can obtain meaningful consent through a
separate authorization for a standalone product or service. Thus, the
final rule is consistent with common law agency principles.
---------------------------------------------------------------------------
\87\ See Restatement (Third) of Agency section 8.01 (2006).
\88\ See id. section 8.06 and section 8.06 cmt. b.
---------------------------------------------------------------------------
The CFPB does not agree with some commenters that the effect of
subpart D is to override consumers' choices. Instead, subpart D
establishes a framework to ensure that consumers have a meaningful
opportunity to understand and consent to uses of data on their behalf.
The evident congressional purpose of CFPA section 1033(a) is to give
consumers greater control of data concerning their financial accounts,
and this purpose would be fatally undermined if third parties could use
the data in ways that consumers would not expect and would reject if
given an unobstructed choice. As part of its rulemaking role assigned
by Congress, the CFPB has crafted a framework in subpart D to ensure
that consumers are able to make informed choices.
The CFPB does not agree with other commenters that suggest that
only a narrow class of certain fiduciaries should be recognized as
authorized third parties. The CFPB has framed subpart D precisely to
ensure that covered data are available only to agents, trustees, and
representatives acting on behalf of the consumer. Regardless of whether
entities engaged in the current open banking system would qualify for
that category, if an entity satisfies the final rule's conditions--
including the obligations to act on behalf of the consumer--it is
appropriate to recognize it as an authorized third party.
Accordingly, subpart D is consistent with CFPA section 1033 and
with the definition of ``consumer'' in CFPA section 1002(4). Moreover,
even assuming for the sake of argument that commenters' narrower or
broader readings of CFPA section 1002(4) were accepted, the CFPB notes
that Congress has conferred express rulemaking authority on the CFPB in
CFPA section 1033(a) and has done so in broad terms. Because all data
sharing under section 1033 of the CFPA is ``[s]ubject to rules
prescribed by the Bureau,'' the CFPB has authority to place conditions
on data access in order to carry out CFPA section 1033 and realize its
objective of meaningful consumer control of the data that is shared
pursuant to the statute.
Finally, although commenters did not specifically challenge the
basis for the proposed provision requiring certain third parties to
establish and maintain policies and procedures for record retention,
this provision is authorized under CFPA sections 1022(b)(1) and
1024(b)(7), as discussed in part IV.D.6.
Other Concerns Related to the Proposed Approach to Authorizing Third
Party Data Access
Some commenters raised concerns with the general approach to third
party access to covered data in proposed subpart D. As further
discussed elsewhere in this part IV.D, the CFPB concludes that the
general approach to third party access to covered data in subpart D of
the final rule, including the authorization procedures and third party
obligations, best aligns with congressional intent to ensure that third
parties accessing covered data are acting on behalf of consumers.
Additional discussion of these comments and the rationale for the
CFPB's determination can be found in the remainder of this part IV.D as
well as in the General Comments Received on the Proposal discussion of
part IV and in part IV.C.5.
Some data providers and trade associations for data providers
stated that the rule should mandate that third parties certify that
they accept liability in certain circumstances, are adequately
capitalized, and carry sufficient indemnity insurance to fulfill their
liability obligations. However, the purpose of the third party
obligations in subpart D is to ensure that third parties accessing
covered data are doing so on the consumer's behalf. Content related to
the allocation of liability between data providers and third parties
would be outside the scope of this purpose. This is also the case for
capitalization and indemnity insurance requirements.
A bank commenter suggested that once the rule becomes effective, it
should apply to covered data currently held by third parties, to ensure
that data are uniformly and consistently protected. However, the third
party authorization procedures in subpart D provide procedures and
obligations for
[[Page 90922]]
third parties seeking to access covered data pursuant to the final
rule's framework. As such, the final rule does not apply to covered
data accessed by third parties prior to the final rule's effective
date.
Third Party Access Outside the Subpart D Framework
Two trade associations representing nondepository entities
commented that the CFPB should clarify that the rule does not prohibit
third parties from accessing covered data outside the rule's data
access framework. One of these trade association commenters stated that
the scope of CFPA section 1033 is limited and does not authorize the
rule to prohibit third parties from obtaining a consumer's financial
information outside the rule's framework. The commenter requested that
the CFPB clarify that the rule does not establish the exclusive means
for a third party to obtain covered data and does not impose
restrictions on third parties that access such data without relying on
the CFPA section 1033 access right. Another bank commenter stated the
rule does not address how it affects existing contracts providing for
access to consumer financial data and recommended that the CFPB provide
for the grandfathering of such contracts.
Several bank commenters and bank trade association commenters
stated that the rule's protections should apply to third parties
attempting to access covered data, even if those third parties do not
attempt to become authorized third parties and rely on the rule's
framework to obtain access to covered data. They stated that third
parties could evade the rule's protections by declining to become
authorized third parties, by not trying to access covered data through
the rule's framework, and by relying on other methods to access covered
data.
CFPA section 1033 provides consumers, and third parties acting on
behalf of consumers, with a right to access their data, and the rule
creates a framework to implement that right. The CFPB expects that
third parties and covered data providers will employ the rule's
framework for arranging third party access to covered data authorized
by the consumer. The CFPB has determined that the rule's framework will
provide significant benefits to data providers, third parties, and
consumers. Data providers will receive assurance that third parties
have authorization from the consumer to access data and a commitment
from third parties that they will comply with certain consumer
protections and other obligations, which will promote data minimization
and sound risk management. Moreover, as noted above, the CFPB would not
consider data providers under this final rule to be furnishers solely
by virtue of permitting data access pursuant to an authorization that
is consistent with the final rule. Third parties seeking to access
covered data on behalf of consumers to provide products or services
generally will receive that access if they comply with the
authorization procedures and other conditions of the rule. Most
importantly, the rule will provide significant protections to consumers
by ensuring that third parties are accessing covered data on behalf of
consumers--as the CFPA envisions--and are taking appropriate steps to
protect their covered data. The rule does not address the topic of any
data sharing outside the rule's framework, including through existing
contracts. However, the prohibitions in the CFPA against unfair,
deceptive, or abusive acts or practices will bear on any claimed effort
to proceed outside of the safe, secure, reliable and competitive open
banking framework that is enabled by this final rule. The CFPB will
closely monitor the market to determine whether attempts to arrange for
consumer authorized access to covered data outside the framework
constitute unfair, deceptive, or abusive acts or practices.
Screen Scraping by Third Parties
In the proposal, the CFPB expressed the goal of transitioning the
market away from screen scraping and noted the nearly universal
consensus that developer interfaces should supplant screen scraping.
The proposed rule also discussed the overcollection, data security,
accuracy, and infrastructural burden concerns related to screen
scraping. As discussed in part IV.C.3 above, to facilitate a
transition, the CFPB proposed to prevent data providers from relying on
screen scraping as a means of enabling third parties to access consumer
data, even though it did not formally prohibit screen scraping. The
CFPB did not propose requiring 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. The proposed rule explained that screen scraping generally
presents risks to consumers and the market and that relying on
credential-based screen scraping would complicate the mechanics of data
access, particularly with respect to authentication and authorization
procedures.
Several commenters addressed screen scraping by third parties. Some
data provider and data provider trade association commenters asked the
CFPB to prohibit third parties from screen scraping or to require third
parties to include commitments to avoid screen scraping in their
certification statements. These commenters generally stated that screen
scraping can be difficult for data providers to identify and prevent.
According to these commenters, detecting and preventing screen scraping
requires significant resources even for large banks, and cannot be
accomplished with certainty. Given the risks involved in screen
scraping, these commenters stated, the obligation to prevent it should
rest with the third party, which is most directly able to control the
practice.
Several commenters tied their concerns regarding screen scraping to
the coverage of the rule. For example, several data providers and trade
associations for data providers stated that because the proposal would
not require all third parties to access data through the developer
interface, and would apply only to covered data, some third parties
could still attempt to screen scrape outside the scope of the rule. One
bank commenter stated that third parties that scrape non-covered data
could easily scrape covered data at the same time. A data aggregator
commenter asked for clarity on the use of screen scraping for non-
covered data or when developer interfaces are unavailable.
Several other commenters suggested that the incentive to access
data through a developer interface might be insufficient to channel
data flows through the framework in the proposed rule. For example, a
researcher and a service provider commenter stated that screen scraping
persisted in Australia and Europe despite the development of API
access. One of these commenters asserted that poor API quality caused
the persistence of screen scraping in Australia, while the other
claimed that the lack of a ban on screen scraping was responsible for
the continuation of the practice in Europe.
In contrast, several commenters, mainly third parties and nonprofit
organizations, recommended that the final rule expressly permit screen
scraping in limited circumstances. These commenters generally suggested
two circumstances to permit screen scraping: (1) when developer
interfaces are unavailable; and (2) when data made available through
developer interfaces is unreliable. A few commenters recommended
allowing screen scraping until data providers have established
[[Page 90923]]
developer interfaces. A nonprofit organization commenter suggested that
the possibility of screen scraping would serve as a check on
anticompetitive conduct by data providers and a way of incentivizing
developer interface quality. Another nonprofit organization commenter
recommended allowing tokenized screen scraping as a more secure
alternative to traditional screen scraping. A researcher commenter
stated that any prohibition on third parties using consumer credentials
to access developer interfaces risked leaving third parties without
means of accessing data if the interface is unavailable. A nonprofit
organization commenter stated that screen scraping might be the only
means of accessing non-covered data from some data providers. Finally,
some community banks, credit unions, and related trade association
commenters also requested that the final rule permit screen scraping.
These commenters generally believed that data providers should have the
flexibility to permit screen scraping by trusted third parties instead
of enabling access through developer interfaces.
Conversely, many large data providers and trade associations for
data providers opposed any screen scraping exception. These commenters
generally stated that any fallback option for screen scraping would
create the same consumer transparency, control, security, and privacy
risks the proposal was trying to avoid. Finally, some community banks,
credit unions, and related trade association commenters also requested
that the final rule permit screen scraping. These commenters generally
believed that data providers should have the flexibility to permit
screen scraping by trusted third parties or build developer interfaces.
The CFPB has determined that specifically prohibiting third parties
from screen scraping when they obtain covered data through the final
rule, or requiring them to make a certification to that effect, is
unnecessary. The final rule's authorization and authentication
requirements do not accommodate data access arrangements in which a
third party retains consumers' access credentials. And the final rule
imposes limitations on the collection, use, and retention of covered
data that third parties could not feasibly meet through screen
scraping.
Once data providers have enabled the safe, secure, and reliable
forms of data access envisioned in this rule, the CFPB cautions that
screen scraping attempts by third parties to reach data covered by such
arrangements could well be limited by the CFPA's prohibition on unfair,
deceptive, and abusive acts or practices.\89\ As discussed throughout
this document, screen scraping poses risks to consumer privacy and data
security. The CFPB understands that in some circumstances, screen
scraping may be the only practical means by which third parties can
access consumer data. For example, a third party might seek to access
non-covered data or data held by a financial institution that has not
established a developer interface. But if a third party attempts to
screen scrape consumer data when a more secure, structured alternative
means of access is available, such as the developer interface or a
substantially similar interface, then the third party would be
needlessly exposing consumers to harm. Depending on the facts and
circumstances, such activity might well constitute an unfair,
deceptive, or abusive act or practice.
---------------------------------------------------------------------------
\89\ See 12 U.S.C. 5531.
---------------------------------------------------------------------------
Finally, the CFPB has decided against providing for screen scraping
as a fallback means of third party access under the final rule. The
final rule attempts to reduce the risks of screen scraping by
facilitating the market's transition toward more secure methods of
consumer-authorized data access. Providing for screen scraping as an
alternative method of data access would undermine this important goal.
Certain technologies, such as tokenized screen scraping, could mitigate
some of the risks of credential-based screen scraping. But even
tokenized screen scraping would not alleviate the risks to privacy and
accuracy, or meaningfully advance the statutory mandate to promote the
development and use of standardized formats.
Regarding concerns that the absence of a screen scraping
alternative might leave consumers without a means of authorizing access
to their covered data, the CFPB has determined that the performance
standards for developer interfaces will ensure that consumers and third
parties have reliable access to covered data. To the extent that such
access is interrupted by maintenance or reliability issues, it is not
clear that screen scraping would serve as a practical alternative. If
third parties collected consumer credentials in advance of a potential
availability issue, the resulting mass accumulation of consumer
credentials by third parties would effectively undermine the final
rule's efforts to encourage safer and more structured means of data
access. But waiting until the developer interface is unavailable might
also be impractical because the sudden request for credentials might
confuse consumers, and the unavailability might extend to the interface
the third party seeks to screen scrape.
To the extent that small data provider commenters viewed screen
scraping as a way to alleviate the burden of implementation, the CFPB
has provided alternative means of reducing burden on small entities.
For example, part IV.C.3 discusses how data providers may use service
providers that rely on screen scraping to facilitate access to the
developer interface. And part IV.A.5 discusses the tiered compliance
dates designed to ease the burden on smaller data providers.
2. Third Party Authorization Procedures (Sec. 1033.401)
Proposed Sec. 1033.401 specified what requirements a third party
would have to satisfy to become an authorized third party entitled to
access covered data on behalf of a consumer. The CFPB preliminarily
determined that these proposed requirements would, among other things,
help ensure that a consumer understands and would be able to exercise
control over what covered data the third party would collect and how it
would be used. The CFPB also preliminarily determined that the proposed
procedures would help ensure that the third party would take
appropriate steps to protect the consumer's data and that the consumer
would provide express informed consent for the third party to collect,
use, and retain the covered data. The CFPB preliminarily determined
that these requirements would help ensure that a third party accessing
covered data is doing so on behalf of a consumer and not for the third
party's own benefit, consistent with the definition of consumer in CFPA
section 1002(4) and as used in section 1033.
Proposed Sec. 1033.401 would have provided that, to become an
authorized third party, the third party must seek access to covered
data from a data provider on behalf of a consumer to provide a product
or service the consumer requested. This proposed requirement was
intended to ensure that the third party is acting on behalf of the
consumer--by accessing covered data to provide the product or service
requested by the consumer--and is not seeking access to covered data
for its own purposes.
Proposed Sec. 1033.401 also provided that a third party would have
to satisfy the prescribed authorization procedures to become an
authorized third party. Under proposed Sec. 1033.401, the three-part
authorization procedures would require a third party to: (a) provide
the consumer with an authorization disclosure as described in proposed
[[Page 90924]]
Sec. 1033.411; (b) provide a statement to the consumer in the
authorization disclosure, as provided in proposed Sec. 1033.411(b)(5),
certifying that the third party agrees to the obligations described in
proposed Sec. 1033.421; and (c) obtain the consumer's express informed
consent to access covered data on behalf of the consumer by obtaining
an authorization disclosure that is signed by the consumer
electronically or in writing.
The proposed requirement in Sec. 1033.401(a) that a third party
provide an authorization disclosure to the consumer was intended to
help ensure that the consumer understands the key terms of access and
can make an informed decision about whether to grant the third party
access to the consumer's financial data. The proposed requirement in
Sec. 1033.401(b) that a third party provide a statement to the
consumer certifying that the third party will comply with certain
obligations would help ensure that the third party is acting on behalf
of the consumer in accessing the covered data. The proposed requirement
in Sec. 1033.401(c) that the third party obtain the consumer's express
informed consent to access covered data would ensure that the consumer
has agreed to allow the third party to access that data on the
consumer's behalf.
As discussed above in connection with Sec. 1033.331(d), the CFPB
proposed that a data provider that receives a request for covered data
from a consumer that jointly holds an account or from an authorized
third party acting on behalf of such a consumer must provide covered
data to that consumer or authorized third party. Consistent with that
proposed approach, for a jointly held account, a third party would have
to comply with the third party authorization procedures in proposed
Sec. 1033.401 for the joint account holder on whose behalf the third
party is requesting access. The CFPB requested comment on whether other
account holders should receive authorization disclosures or otherwise
be notified, or should have an opportunity to object, when an account
holder authorizes a third party to access covered data from a jointly
held account.
The CFPB also requested comment on whether the authorization
procedures in proposed Sec. 1033.401 would be sufficient to ensure
that a third party is acting on behalf of a consumer in obtaining
access to covered data or whether the CFPB should consider alternative
procedures. The CFPB additionally requested comment on whether the
authorization disclosure, including the statement that the third party
will comply with certain third party obligations, would be sufficient
to ensure that the consumer would be able provide express informed
consent for the third party to access covered data on behalf of the
consumer. The CFPB requested comment on whether the rule should include
other protections or clarifications, such as express prohibitions on
false or misleading representations or omissions to induce the consumer
to consent to the third party's access to covered data.
Additionally, the CFPB proposed in Sec. 1033.401 to apply a
consistent set of procedures to all third parties attempting to access
covered data. The CFPB requested comment about whether there are
certain third parties, such as smaller or non-commercial parties, for
which proposed Sec. 1033.401 would not be appropriate. The CFPB also
requested comment about whether the authorization procedures described
in proposed Sec. 1033.401 should be streamlined for certain third
parties. In addition, the CFPB requested comment on whether there are
certain circumstances involving the transmission of data to third
parties for which proposed Sec. 1033.401 would not be appropriate.
Finally, to help the CFPB assess the need for potential exemptions to
proposed Sec. 1033.401, the CFPB requested comment on how individuals
who are not account owners currently use existing legal mechanisms to
directly access covered data.
Several nondepository entity commenters supported the proposed
authorization procedures. One stated that the proposed authorization
procedures will help consumers understand and consent to third parties
accessing their data and that the procedures are sufficiently clear and
flexible.
Commenters generally did not oppose the three-step authorization
procedures, but some commenters recommended certain revisions or
clarifications. One nondepository entity commenter urged the CFPB to
consider streamlined authorization procedures when the consumer already
has authorized access and is seeking to change the authorization by,
for example, giving access to more or less data or permissioning data
to additional parties. A bank trade association commenter recommended
that the CFPB clarify the third party authorization procedures when
material terms in the authorization change, such as when aspects of the
requested product change, additional data are needed, or the service
provider or data aggregator changes. This commenter urged the CFPB to
require new disclosures and a new authorization when material terms in
the authorization change. A trade association commenter stated that it
was unclear whether third parties are required to comply with the
proposed certification, disclosure, and use limitation requirements for
non-covered data.
Several commenters stated that data providers should play a more
significant role in the third party authorization process. Several
commenters, including banks and a trade association, maintained that
data providers, rather than third parties, are best positioned to
obtain consumers' authorizations. A trade association commenter stated
that data providers hold consumers' accounts and have account
verification and access procedures to verify consumers' requests.
Several commenters addressed whether, as part of the authorization
procedures, the rule should impose regulatory obligations directly on
third parties, including data aggregators. Several bank and bank trade
association commenters recommended that the rule impose obligations
directly on third parties, rather than requiring them to certify that
they will abide by certain obligations as a condition for becoming
authorized to access covered data. These commenters raised concerns
about how the obligations would be enforced against third parties. They
also stated that the CFPB should supervise third parties, particularly
data aggregators, to ensure that they comply with the third party
obligations in the rule.
Several commenters recommended that the rule include additional
consumer protections. A consumer advocate commenter requested that the
CFPB consider additional provisions to ensure that consumers provide
express informed consent for third parties accessing covered data. That
commenter recommended that the rule include prohibitions on false or
misleading representations to induce the consumer to provide consent to
the third party's access to the consumer's covered data. Another
consumer advocate commenter recommended additional consumer
protections, including requiring privacy impact statements and
authorizing private rights of action for consumers to pursue penalties
that violate third party obligations. A consumer advocate commenter and
a data aggregator commenter recommended that the privacy protections
apply to any parties subject to the rule. Finally, a consumer advocate
commenter suggested that the CFPB require a waiting period of fourteen
days before allowing third parties to solicit any additional products
or services or at least before requesting
[[Page 90925]]
authorization for certain additional uses, like debt collection,
marketing for harmful high-cost credit products, and others.
A bank trade association requested that the rule clarify that a
consumer's electronic signature on an authorization disclosure is
intended to comport with the ESIGN Act. One commenter suggested that
the rule should permit ``clear affirmative consent.'' This commenter
asked that the rule clarify that a clear affirmative action that a
consumer takes on a digital interface, such as clicking ``Agree'' or
``Continue,'' after being presented with the authorization disclosure,
would satisfy the requirement that an authorization disclosure be
signed electronically. The commenter suggested that ``full electronic
signatures'' are an unusual method of obtaining express informed
consent on a digital interface, such as an internet browser or
application, would be inconsistent with seeking innovative products and
services, and could create a barrier for consumers. Another commenter
requested that the rule confirm a third party may rely on ``click
through acceptance'' of the authorization disclosure and suggested that
clicking ``agree'' or ``proceed'' should satisfy the express informed
consent requirement. Conversely, a consumer advocate commenter
suggested that the rule not permit the use of click through boxes and
suggested toggles for ``on/off'' authorization.
Several commenters addressed how the authorization procedures
should function for joint accounts. These comments are described in
part IV.C in connection with the discussion of Sec. 1033.331(d).
Several commenters addressed whether the authorization procedures
should apply to all third parties or whether there should be exceptions
for certain third parties, such as smaller third parties or non-
commercial third parties. A bank trade association commenter stated
that data providers already have procedures for providing information
to natural third parties, such as agents, attorneys, accountants, and
guardians. This commenter argued that such individuals should not be
required to go through a developer interface, and that the rule should
exempt natural third parties. A consumer advocate commenter stated that
the CFPB should consider whether there should be exceptions for
verified non-commercial third parties, such as family members or
nonprofit counselors, that may need read-only access to data to help
consumers manage their finances. Another consumer advocate commenter
and a bank commenter recommended that the rule not provide any
exceptions for third parties. The consumer advocate commenter stated
that there may be situations in which non-commercial users, such as
executors or guardians, should be able to access covered data through a
consumer interface.
For the reasons discussed herein, the CFPB is finalizing the three-
step authorization procedures as proposed. To become an authorized
third party, under proposed Sec. 1033.401, a third party must: (a)
provide the consumer with an authorization disclosure as described in
Sec. 1033.411; (b) provide a statement to the consumer in the
authorization disclosure certifying that the third party agrees to
certain obligations described in Sec. 1033.421; and (c) obtain the
consumer's express informed consent to access covered data on behalf of
the consumer by obtaining an authorization disclosure that is signed by
the consumer electronically or in writing.
The CFPB has determined that the authorization procedures, as
described in more detail below, appropriately ensure that a third party
accessing covered data pursuant to the rule is doing so on behalf of a
consumer and not for the third party's own benefit, consistent with the
definition of consumer in CFPA section 1002(4) and used in section
1033. The authorization procedures will help ensure that a consumer
understands and can exercise full control over what covered data the
third party collects and how that data will be used. The authorization
procedures also will help ensure that consumers are not unknowingly or
reluctantly acquiescing to forms of data access that they do not want.
In addition, the authorization procedures will help ensure that the
third party will take appropriate steps to protect the consumer's data
and that the consumer provides express informed consent for the third
party to collect, use, and retain the covered data. The authorization
procedures clearly apply only to third parties that are attempting to
access covered data through the rule's framework and the CFPB has
concluded that additional clarification is not needed to specify that
the authorization procedures do not apply when entities are attempting
to access non-covered data.
As noted above, some commenters recommended that data providers
play a larger role in the authorization process and have primary
responsibility for consumer authorizations. The CFPB has determined
that it is appropriate for third parties to obtain consumer
authorization for third party access to covered data. The third party
is providing the product or service to the consumer and understands
what covered data are reasonably necessary for providing that product
or service. Assigning responsibility for consumer authorization to the
data provider could create friction and impair access to covered data
by authorized third parties. The third party authorization procedures
ensure that third parties are acting on behalf of consumers and that
consumers understand and maintain control over third party access to
their covered data. While the third party is responsible for obtaining
the consumer's authorization, as discussed in part IV.C.5, a data
provider must make available covered data when it receives certain
information, including, as provided in Sec. 1033.331(b)(1)(iii),
information sufficient to document the third party has followed the
Sec. 1033.401 authorization procedures.
The CFPB has concluded that streamlined authorization procedures
would not be appropriate when the consumer or authorized third party
seek to change the terms of the authorization, such as to expand or
narrow the scope of access to covered data. When the parties seek to
change the terms of the authorization, the authorized third party must
obtain a new authorization to ensure that the consumer understands and
provides express informed consent for new terms for the authorized
third party's access to covered data.
The CFPB also has concluded that the approach in Sec. 1033.401(b)
to require third parties to certify to abide by certain obligations
related to the data access is appropriate. As part of the authorization
procedures, third parties must certify to consumers that they will
comply with certain obligations as condition of becoming authorized
third parties entitled to access covered data on behalf of consumers.
Similarly, data aggregators also must certify to consumers that they
will comply with certain obligations. The CFPB concludes that this
certification-based approach is the appropriate approach for ensuring
that third parties are acting on behalf of consumers when they are
accessing covered data. Some commenters had urged the CFPB to impose
obligations directly on third parties, including data aggregators, and
to supervise third parties, including data aggregators, to ensure
compliance. They raised concerns about how the obligations could be
enforced under a certification-based approach if the authorized third
party or data aggregator fails to comply with their obligations. The
CFPB has concluded that these obligations can be
[[Page 90926]]
enforced effectively under the certification-based approach in various
ways, including by the CFPB using its authority to prevent unfair,
deceptive, or abusive acts or practices; by other regulators; and
potentially by consumers under other applicable statutes or common law.
With respect to supervision of third parties, as discussed in part
IV.5, the CFPB's supervisory authority is defined by the CFPA. The CFPB
will continue to monitor the market, including by using its supervisory
authority, and will consider whether additional rulemakings are
appropriate to expand the scope of the CFPB's supervision with respect
to part 1033.
The CFPB declines to include in the final rule additional
protections requested by commenters. The authorization procedures
provide significant protections for consumers to ensure that third
parties accessing covered data are acting on behalf of the consumers.
The CFPB has concluded that it is unnecessary to include in the rule
specific prohibitions on false or misleading representations or
omissions to induce consumers to consent to third party access to
covered data. Other provisions of law, including the protections of the
CFPA against unfair, deceptive, or abusive acts or practices, already
would address such conduct. The CFPB also declines to impose a waiting
period before a third party can solicit additional authorizations. The
limitation on a consumer's requested product or service is intended to
be flexible for consumers to determine for themselves if they want
multiple products or services, which they can authorize separately
through the authorization procedures. The CFPB also notes that the rule
includes a clear limitation that third parties must not expand
collection, use, or retention of covered data beyond the scope of the
product or service described in the consumer's authorization.
To avoid being overly prescriptive, and in light of CFPA section
1033(e)'s objective of technological neutrality, the final rule does
not specify methods or mechanisms that third parties must use to obtain
express informed consent electronically. Regardless of the method or
mechanism used, the third party must obtain a written or electronic
signature that the consumer executes or adopts with the intent to sign
the authorization disclosure. When determining the method or mechanism
that it will use to obtain an authorization disclosure signed in
writing or electronically by the consumer, a third party must consider
all of the final rule's provisions related to the authorization
disclosure as well as the CFPA's prohibition on unfair, deceptive, or
abusive acts or practices and other applicable law. For example, under
final Sec. 1033.411(a), the third party must provide the authorization
disclosure electronically or in writing. Under final Sec. 1033.421(g),
a third party must certify that it will provide a consumer with a copy
of the authorization disclosure that has been signed by the consumer
electronically or in writing and that reflects the date of the
consumer's electronic or written signature. Certain third parties also
must establish and maintain written policies and procedures that are
reasonably designed to ensure retention of records that are evidence of
compliance with the requirements of subpart D. A third party may not be
able to satisfy these requirements if it obtains a consumer's
electronic signature by certain methods or mechanisms. For example, the
CFPB expects that in order to ensure accuracy, record integrity, and to
preserve the ability to access the signed authorization disclosure, the
authorization disclosure and the electronic signature establishing
consumer consent cannot as a matter of regular course be provided
orally and still satisfy all of the final rule's requirements.\90\
---------------------------------------------------------------------------
\90\ Programs, goods, and services provided to the general
public must be accessible to consumers with disabilities. Third
parties should ensure that their authorization and consent
procedures enable, when appropriate, the use of assistive
technologies that may be warranted under the ADA or other applicable
law.
---------------------------------------------------------------------------
The final rule has adopted the proposed approach to authorization
by joint account holders. As provided in Sec. 1033.331(d), a data
provider that receives a request for a covered data from a consumer
that jointly holds an account or from an authorized third party acting
on behalf of that consumer must provide covered data to that consumer
or authorized third party. When a third party is seeking covered data
on behalf of a consumer that jointly holds an account, the third party
must comply with the authorization procedures for the joint account
holder on whose behalf the third party is requesting access. Consistent
with the discussion in part IV.C.5 in connection with Sec.
1033.331(d), an authorization from a single account holder is
sufficient for an authorized third party to access covered data, and
the CFPB declines to require that other joint account holders be
notified or receive copies of the authorization disclosure.
Finally, the CFPB declines to establish any exceptions to the
authorization procedures for certain third parties, such as smaller
third parties or non-commercial third parties. The CFPB has concluded
that it would be difficult to define the appropriate scope of any such
exceptions at this time and is concerned that such exceptions could
create loopholes. The CFPB has designed the authorization procedures so
that they should not be overly difficult for third parties to navigate.
Moreover, the rule does not prohibit persons such as attorneys or
accountants from making arrangements for the consumer to provide
financial information, included covered data.
3. Authorization Disclosure (Sec. 1033.411)
Proposed Sec. 1033.411 specified format and content requirements
for the authorization disclosure that third parties would provide to
consumers in order to be authorized to access covered data on behalf of
the consumer, as set forth in proposed Sec. 1033.401. As discussed
below, the final rule maintains format and content requirements for the
authorization disclosure with several adjustments.
General Requirements (Sec. 1033.411(a))
Proposed Sec. 1033.411(a) would have required that, to comply with
proposed Sec. 1033.401(a), a third party must provide the consumer
with an authorization disclosure electronically or in writing. It also
would have set forth general format requirements for the authorization
disclosure. Specifically, the CFPB proposed that the authorization
disclosure must be clear, conspicuous, and segregated from other
material. The CFPB preliminarily determined that these requirements
would facilitate consumer understanding of the authorization
disclosure. The CFPB also preliminarily determined that requiring the
authorization disclosure to appear segregated from other material would
help ensure consumers read and understand the authorization disclosure
by avoiding overwhelming consumers with extraneous information and
diluting the informational value of the authorization disclosure.
The CFPB sought comment on whether these formatting requirements
would aid consumer understanding and whether additional requirements
should be included in the rule. Specifically, the CFPB sought comment
on whether the rule should contain more prescriptive requirements, such
as specifying a word count or setting a reading level. The CFPB also
sought comment on whether the rule should include a timing requirement,
such as a requirement that the authorization disclosure be provided
close in time to when the third party
[[Page 90927]]
would need consumer data to provide the product or service.
Additionally, the CFPB sought comment on whether indicia that the
authorization disclosure is clear, conspicuous, and segregated from
other material should include utilizing a format or sample form that is
set forth in a qualified industry standard.
As stated in the proposed rule, the CFPB considered proposing
specific guidance for accessibility of the authorization disclosure for
individuals with disabilities but preliminarily determined that the
Americans with Disabilities Act (ADA) and its implementing regulations
\91\ would already require that the authorization disclosure be
provided in an accessible format. The CFPB sought comment on whether
the rule should contain requirements relating to the accessibility of
the authorization disclosure.
---------------------------------------------------------------------------
\91\ See 42 U.S.C. 12132, 12182(a); 28 CFR 35.130, 35.160(a),
36.201, 36.303(c).
---------------------------------------------------------------------------
The CFPB received a number of comments on the authorization
disclosure's general requirements. A variety of commenters, including
data providers and trade associations for certain data providers, some
third parties and trade associations for certain third parties, and a
research institute, supported the proposed formatting requirements
because the commenters thought that the proposed requirements are
clear, straightforward, and meaningful. A commenter suggested that the
proposed provisions related to written authorization disclosures should
be removed because they are unnecessary.
A variety of commenters, including data providers and trade
associations for certain data providers, some third parties, consumer
advocates, and a research institute, supported adding various
requirements for the authorization disclosure, including plain
language, reading level, or understandability requirements. One
consumer advocate commenter supported a word count limit for consumer
understandability, but a research institute commenter opposed a word
count limit. This commenter said that a word count limit would not be
feasible based on the amount of information that may need to be
included in the authorization disclosure.
A consumer advocate commenter and two data provider commenters
supported adding authorization disclosure timing requirements to the
rule. The consumer advocate commenter suggested that the rule specify
that the authorization disclosure be provided no earlier than 14 days
prior to the time that the third party begins providing the product or
service to the consumer. One of the data provider commenters suggested
that the authorization disclosure should be provided close in time to
when the third party would need covered data to provide a product or
service, and the other data provider commenter similarly suggested that
the authorization disclosure be provided close in time to when the
third party first accesses covered data. The consumer advocate
commenter and two data provider commenters suggested that timing
standards could increase the chances that a consumer is making an
informed choice to authorize a third party to access covered data and
reduce the risk that a consumer forgets that they previously authorized
a third party to access covered data.
A variety of commenters, including data providers, third parties, a
consumer advocate, and a research institute, suggested adding other
formatting requirements to increase consumer understanding. Some data
providers, trade associations for certain data providers, and a third
party commenter requested additional clarity on the meaning of ``clear
and conspicuous.'' A trade association for data providers requested
that the final rule prohibit extraneous language that could cause
consumer confusion or obscure key terms of access. One third party
commenter expressed concern that the proposed requirement to segregate
the disclosure from other material would cause consumers to over-focus
on the authorization disclosure. This commenter supported allowing the
authorization disclosure to be combined with other materials, including
disclosures required under Regulation E or Regulation Z. However,
several commenters supported requiring that the authorization
disclosure be segregated from other material.
A standard-setting body commenter asserted that the use of
qualified industry standards regarding the authorization disclosure
would not be appropriate for establishing regulatory compliance or as
indicia of compliance, but stated that specifications and best
practices might evolve to match the final rule and be used as
suggestive tools. Some trade association commenters and a credit union
commenter supported a role for industry standards in authorization
disclosure formatting because, they said, it would improve consistency
in the disclosures. A third party commenter stated that when consumers
have multiple accounts, the rule should ensure that consumers check a
box or similarly identify the accounts to which consumers are granting
access, noting that this requirement could be defined by industry
standards.
Commenters also provided feedback on whether the CFPB should
provide model forms for the authorization disclosure in addition to
setting forth general formatting requirements in the rule. A variety of
commenters, including data providers, consumer advocates, and a
research institute, suggested that the CFPB provide model forms or
clauses for all or part of the authorization disclosure to save time
and resources and ensure effectiveness, consistency, and compliance.
Two consumer advocate commenters and a bank commenter suggested that
model forms would be beneficial for consumers. A bank trade association
commenter and a data aggregator commenter suggested that use of model
forms should provide a safe harbor. Conversely, one trade association
commenter specifically opposed model forms. This commenter opposed
over-engineered and overly prescriptive requirements for the
authorization disclosure. One third party commenter preferred flexible
standards that would allow authorization disclosures to shift with
market innovations and new technologies.
A consumer advocate commenter requested a disability accessibility
requirement to prevent any ambiguity in case there is a disagreement
about the applicability of the ADA.
For the reasons discussed herein, the CFPB is finalizing the
language of Sec. 1033.411(a) as proposed, with an additional
requirement. Specifically, the CFPB is adding to final Sec.
1033.411(a) a requirement that the names included in the authorization
disclosure, as required by Sec. Sec. 1033.411(b)(1) and (2) and by
Sec. 1033.431(b), must be readily understandable to the consumer. The
CFPB has determined that this requirement will help ensure that
consumers are able to easily identify the entities in the authorization
disclosure. Unlike a legal or trade name which may or may not be
familiar to a consumer depending on the particular entity, the
``readily understandable'' requirement directly addresses consumer
understanding to facilitate informed consent.
The CFPB is not eliminating the option for third parties to provide
the authorization disclosure in writing as suggested by a commenter.
Retaining this option permits flexibility in circumstances that may
necessitate the authorization disclosure to be provided in a non-
electronic form.
[[Page 90928]]
The CFPB is not including the additional formatting requirements
requested by commenters, including plain language or reading level
requirements or word count limits, because ``clear and conspicuous'' is
a common standard that is flexible enough to cover a variety of
circumstances and ensure consumer understanding of the authorization
disclosure. The meaning of ``clear and conspicuous'' in this final rule
should be informed by how the standard has been interpreted in other
contexts, including by the FTC in assessing whether disclosures in
advertisements are clear and conspicuous.\92\
---------------------------------------------------------------------------
\92\ The FTC has articulated the ``4 Ps''--prominence,
presentation, placement, and proximity--as a way of evaluating
whether disclosures are clear and conspicuous. Lesley Fair, Full
Disclosure, FTC Bus. Blog (Sept. 23, 2014), https://www.ftc.gov/business-guidance/blog/2014/09/full-disclosure.
---------------------------------------------------------------------------
The CFPB is not including timing requirements, as suggested by some
commenters, in order to maintain flexibility in light of the variety of
products and services for which third parties may seek to access
covered data. For example, a third party may need to access covered
data periodically, may only need to access covered data at or near the
time that the consumer obtains the product or service, or may only need
to access covered data at a later time. Additionally, the final rule's
duration and reauthorization requirements act as added protections
against potential harms related to third parties accessing covered data
based on long-term authorizations.
The CFPB is maintaining the proposed segregation requirement for
the authorization disclosure. Combining disclosures or other materials
that serve varying purposes in the manner that a third party commenter
suggested could result in consumer confusion. Although Regulation E and
Regulation Z disclosures provide important consumer protections, they
do not serve the same purposes as the authorization disclosure, which
is to ensure that third parties are acting on behalf of consumers when
accessing covered data. Simply placing the authorization disclosure at
the top of a combined disclosure form would not sufficiently alleviate
the risk of consumer confusion. Moreover, segregating the authorization
disclosure from other material, including other important disclosures,
allows the consumer to consider the content of each disclosure or other
document in turn.
The CFPB is not providing model forms or clauses for the
authorization disclosure. The final rule provides flexibility in how
third parties meet the disclosure requirements given the range of
potential third parties that may seek authorization to access covered
data pursuant to the final rule's framework and the potential for
innovation and the development of new technologies. As one research
institute commenter noted when discussing a word count limit, there may
be feasibility issues with providing a model disclosure because it
potentially would need to be useable for multiple different types of
products and services, multiple data providers, and multiple third
parties. The CFPB will monitor the market and consider developing model
forms or clauses in the future, as appropriate.
The final rule does not reference a consensus standard regarding
authorization disclosure format because the clear and conspicuous
standard is well established in Federal consumer financial law, as well
as other consumer protection frameworks in both State and Federal law.
Additionally, the CFPB encourages third parties and other interested
stakeholders to apply to test authorization disclosures through the
CFPB's Trial Disclosure Policy.\93\
---------------------------------------------------------------------------
\93\ Consumer Fin. Prot. Bureau, Competition and innovation at
CFPB, https://www.consumerfinance.gov/rules-policy/competition-innovation/ (last visited Oct. 16, 2024). Under this policy,
companies can obtain a safe harbor for testing disclosures that
improve upon existing disclosures for a limited period of time while
sharing data with the CFPB.
---------------------------------------------------------------------------
The CFPB is not including disability accessibility requirements in
the final rule because the ADA addresses these requirements, and the
CFPB does not want to create potentially conflicting requirements.
Authorization Disclosure Content (Sec. 1033.411(b))
Proposed Sec. 1033.411(b) would have required inclusion of the
following key terms of access in the authorization disclosure: (1) the
name of the third party that will be authorized to access covered data
pursuant to the third party authorization procedures in proposed Sec.
1033.401; (2) the name of the data provider that controls or possesses
the covered data that the third party seeks to access on the consumer's
behalf; (3) a brief description of the product or service that the
consumer has requested the third party provide and a statement that the
third party will collect, use, and retain the consumer's data only for
the purpose of providing that product or service to the consumer; (4)
the categories of covered data that will be accessed; (5) the
certification statement described in proposed Sec. 1033.401(b); and
(6) a description of the revocation mechanism described in proposed
Sec. 1033.421(h)(1). Additionally, proposed Sec. 1033.431(b) would
have required the authorization disclosure to include the name of any
data aggregator that would assist the third party with accessing
covered data and a brief description of the services the data
aggregator would provide.
The proposed content requirements for the authorization disclosure
aimed to strike a balance between providing consumers with sufficient
information to enable informed consent to data access and keeping the
disclosure sufficiently short to increase the likelihood that consumers
will read and understand it. The CFPB preliminarily concluded that the
proposed requirements would be important for consumers to understand
the terms of data access and would help ensure that third parties
accessing covered data are acting on behalf of consumers by enabling
informed consent.
The CFPB sought comment on any obstacles to including the proposed
authorization disclosure content and on whether additional content was
needed to ensure consumers have enough information to provide informed
consent. Specifically, the CFPB sought comment on whether the rule
should include any additional requirements to ensure: (1) the consumer
can identify the third party and data aggregator, such as by requiring
inclusion of legal names, trade names, or both; (2) the description of
the consumer's requested product or service is narrowly tailored and
specific such that it accurately describes the particular product or
service that the consumer has requested; (3) the consumer can locate
the third party obligations, such as by requiring a link to the text of
proposed Sec. 1033.421; and (4) the consumer can readily understand
what types of data will be accessed, such as by requiring third parties
to refer to the covered data they will access using the categories in
proposed Sec. 1033.211. The CFPB also sought comment on whether the
authorization disclosure should include additional content such as the
names of other parties with whom data may be shared, the third party's
contact information, or how frequently data will be collected from the
consumer's account(s).
A variety of commenters supported the authorization disclosure
content included in the proposed rule on the grounds that it would
provide consumers with information that would enable informed consent.
A variety of commenters also stressed the importance of keeping the
authorization disclosure short to avoid information overload for
consumers. One research
[[Page 90929]]
institute commenter requested harmonization of the authorization
disclosure with other privacy laws to reduce compliance challenges and
consumer confusion.
A variety of commenters suggested that additional content be
included in the authorization disclosure.\94\ A bank, bank trade
association, and a consumer advocate also recommended that additional
content be included through a hyperlink on the authorization
disclosure.
---------------------------------------------------------------------------
\94\ One or more commenters requested that one or more of the
following be included in the authorization disclosure: the legal and
trade name of the third party; a description of the data security
and privacy standards to which the third party will adhere in
relation to the consumer's data; contact information for the third
party, aggregator, and/or the CFPB; a link to the third party's
website; information about the frequency (how often data are
accessed), recurrence (such as one time data access or recurring
access), and duration of data access or retention (time period when
data are accessed or retained); a description of any alternatives to
sharing covered data that would allow a consumer to access the
product or service (for example, providing a credit score for credit
underwriting or microtransfers to the consumer's bank account to
verify the account); the names of other third parties with whom data
may be shared; a brief explanation of the ways in which data that
identifies the consumer can be used by the third party accessing the
data; and the specific purposes for which the third party collects
and uses the consumer's data.
---------------------------------------------------------------------------
Other commenters, including a data aggregator, a trade association
for certain third parties, a data provider, a consumer advocate, and a
research institute, suggested that the content should be limited. Two
of these commenters expressed concern about information overload, and
two commenters expressed concern about the burden of including
additional information in the authorization disclosure. A data provider
commenter requested that the final rule remove the requirement to
include the data provider's name in the authorization disclosure.
Some commenters, including a credit union commenter, trade
association commenters, and a consumer advocate commenter, supported
additional requirements to ensure the description of the consumer's
requested product or service is narrowly tailored and specific. One
data aggregator commenter requested clarification on the description
needed to identify the categories of data that will be accessed. This
commenter suggested that it should be sufficient to use categories such
as ``transactional history'' or ``account balance'' and that it should
not be necessary to describe more specific data fields.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.411(b) with modifications. First, the final rule adds a
requirement, as Sec. 1033.411(b)(6), that the authorization disclosure
include a brief description of the expected duration of data collection
and a statement that collection will not last longer than one year
after the consumer's most recent reauthorization. The content of
proposed Sec. 1033.411(b)(6) is finalized as Sec. 1033.411(b)(7).
Second, the final rule removes the word ``covered'' from Sec.
1033.411(b)(4) and specifies that the disclosure for categories of data
that will be accessed must have a substantially similar level of
specificity as the categories in Sec. 1033.211. The other
modifications are non-substantive adjustments for clarity and
consistency.
The CFPB is finalizing in Sec. 1033.411(b)(6) a requirement that
third parties include a description of the expected duration of data
access because this requirement is important for consumers to
understand the terms of data access. In particular, including
information about the revocation method in the authorization disclosure
without information about the duration of collection could leave
consumers under the mistaken impression that the only way for data
access to end is through utilizing the revocation method. Duration is
also a key term that may help consumers decide whether to consent to
third party data access. In the case of a one-time data pull, this
additional information lets consumers know the data sharing will not
continue. In the case of authorizing data access without a set
duration, this additional information ensures consumers know about the
one-year reauthorization requirement.
By removing the word ``covered'' from Sec. 1033.411(b)(4), the
final rule allows the authorization disclosure to include categories of
non-covered data. This gives third parties the flexibility to utilize
the authorization procedures to access non-covered data in addition to
covered data. The additional requirement that the categories used in
the authorization disclosure must have a substantially similar level of
specificity as the categories in Sec. 1033.211 will help ensure that
consumers have enough information about what types of data are being
accessed while also ensuring that the authorization disclosure does not
become too lengthy due to a long list of very specific data types.
Beyond these modifications, the CFPB is not adding or eliminating
content requirements for the authorization disclosure in the final
rule, as requested by some commenters. The content requirements strike
an appropriate balance between providing consumers with sufficient
information to enable informed consent to data access and keeping the
disclosure sufficiently short to increase the likelihood that consumers
will read and understand it. Regarding the commenter suggesting
clarification on the description of the categories of data to be
accessed, the CFPB notes that the categories of data that will be
accessed must have a substantially similar level of specificity as the
categories in Sec. 1033.211. Finally, the CFPB has determined that
third parties can comply with the authorization disclosure content
requirements in Sec. 1033.411(b) while also complying with other
applicable privacy laws.
Language Access (Sec. 1033.411(c))
Proposed Sec. 1033.411(c)(1) would have required that the
authorization disclosure be provided in the same language as the
communication in which the third party conveys the authorization
disclosure to the consumer. It also would have required any translation
of the authorization disclosure to be complete and accurate. Proposed
Sec. 1033.411(c)(2) stated that if the authorization disclosure is in
a language other than English, it must include a link to an English-
language translation. Additionally, proposed Sec. 1033.411(c)(2)
stated that, if the authorization disclosure is in English, it would be
permitted to include links to translations in other languages.
The proposed rule stated that consumers with limited English
proficiency may benefit from receiving a complete and accurate
translation of the authorization disclosure, and some third parties may
want to respond to the needs of consumers with limited English
proficiency using translated disclosures. At the same time, the CFPB
preliminarily determined that requiring third parties to identify such
consumers and provide complete and accurate translations in the myriad
languages that consumers speak may impose a significant burden on third
parties.
The proposed rule stated that some consumers who receive translated
disclosures may also want to receive English-language disclosures,
either because they are fluent in English, or because they wish to
share the disclosures with an English-speaking family member or
assistance provider. It also stated that English-language disclosures
may also allow consumers to confirm the accuracy of the translation.
The CFPB received few comments on the proposed language access
provisions. One trade association for nondepositories indicated that
the
[[Page 90930]]
language access provision is satisfactory. A consumer advocate
commenter requested that the CFPB require the authorization disclosure
to be translated into languages used in marketing. Another consumer
advocate commenter requested a Spanish language disclosure and stated
that the rule should require third parties to automatically provide the
authorization disclosure and other documents in Spanish to all
consumers. This commenter also suggested that the rule improve language
access throughout the entirety of the data gathering process and hold
data aggregators and lenders to comparable standards. A bank trade
association commenter suggested that the language access provision in
the proposed rule necessitated additional discussion or clarity
regarding how principles regarding unfair, deceptive, or abusive acts
or practices apply more generally to financial products and services on
an end-to-end basis.
For the reasons discussed herein, the CFPB is finalizing the
language access provisions in Sec. 1033.411(c) as proposed, with
nonsubstantive clarifying changes. The final rule's language access
requirement applies to the authorization disclosure and, where
applicable, the data aggregator certification. The language access
provisions in the final rule ensure that a consumer understands and is
able to exercise control over what covered data the third party would
collect, use, and retain. The CFPB has determined that it would not be
appropriate to require authorization disclosures to be provided to all
consumers in Spanish, as requested by one commenter. The requirement in
Sec. 1033.411(c)(1) to provide the authorization disclosure in the
same language as the communication in which the authorization
disclosure is conveyed to the consumer should help ensure that
consumers receive the disclosure in a language they understand, without
a broad requirement that all authorization disclosures be provided in
Spanish, which would result in additional burden on third parties. A
broad statement about the interaction of principles regarding unfair,
deceptive, or abusive acts or practices and language access more
generally is outside the scope of this rulemaking.
4. Third Party Obligations (Sec. 1033.421)
Proposed Sec. 1033.421 described obligations to which third
parties would be required to certify in order to be authorized to
access covered data. The proposed third party obligations included: a
limit on third party collection, use, and retention of covered data to
what is reasonably necessary to provide the consumer's requested
product or service; a maximum duration of collection of one year after
the consumer's most recent authorization unless the consumer provides a
new authorization; and certifications that the third party would
provide consumers a simple way to revoke access, maintain certain
accuracy and data security obligations, and ensure consumers have
access to information about the third party's authorization to access
data. The CFPB stated that it was proposing these certification
requirements to ensure that third parties accessing covered data are
acting on behalf of the consumer.
The proposed third party obligations received a range of feedback
from commenters, with some commenters offering general support for the
proposed approach to requiring third parties to certify to the
obligations in proposed Sec. 1033.421, while other commenters
expressed concern with the proposed obligations and the associated
privacy protections.\95\ Some commenters suggested that aspects of the
proposed obligations do not accord with congressional intent to ensure
consumers can use their own data for their own preferences, and that
the CFPB lacks authority to prescribe the proposed obligations. Other
commenters said the obligations are not strong enough to protect
consumers' privacy. Specific comments are discussed in more detail in
the sections regarding third party obligations, below.
---------------------------------------------------------------------------
\95\ A research institute commenter stated that the final rule
should clarify that data generated by a third party in the course of
providing the consumer's requested product or service is not subject
to the third party obligations. Use of generated data is discussed
below related to Sec. 1033.421(c).
---------------------------------------------------------------------------
The CFPB is prescribing the third party obligations in Sec.
1033.421 to ensure that third parties accessing covered data are acting
on behalf of consumers, consistent with CFPA section 1033. As explained
above in the legal authority discussion in part IV.D.1, the plain
language of CFPA section 1033(a) provides that, subject to rules
prescribed by the CFPB, a covered person shall make available to a
``consumer,'' upon request, certain information in the control or
possession of the covered person. CFPA section 1002(4) defines
``consumer'' as ``an individual or an agent, trustee, or representative
acting on behalf of an individual.'' For convenience, part 1033
generally refers to the individual as the ``consumer'' and an agent,
trustee, or representative acting on behalf of that individual as an
``authorized third party.'' Congress intended, through CFPA section
1033, that the consumer would have the right to access their covered
data for their own benefit, and would be able to authorize
representatives to act on their behalf to that end. As such, the final
rule requires third parties accessing covered data to adhere to the
procedures and obligations in subpart D, including certifying to limit
collection, use, and retention of covered data to what is reasonably
necessary to provide the consumer's requested product or service, so as
to ensure that the third party is accessing data as a representative
acting on behalf of the consumer and that the consumer is the primary
beneficiary of that data access. In addition, as noted above, the CFPB
has rulemaking authority to adopt Sec. 1033.421 to carry out the
objectives of CFPA section 1033.
By adhering to the obligations in Sec. 1033.421, a third party, as
a representative acting on behalf of the consumer, ensures consumers
are best positioned to understand the data access they are authorizing
and accordingly are best positioned to exercise meaningful control with
respect to such access. As such, the obligations in Sec. 1033.421
ensure the consumer is effectively informed about the scope of the
third party's access to covered data and ensure that the third party's
access accords with the intent and reasonable expectations of the
consumer. For example, the third party's adherence to Sec. 1033.421(a)
ensures the consumer understands and clearly directs how and for what
purposes their data will be collected, used, and retained.
For the reasons discussed herein, final Sec. 1033.421 generally
adopts the proposed third party obligations. Changes related to
specific aspects of the proposed obligations are described in detail
below.
General Standard To Limit Collection, Use, and Retention (Sec.
1033.421(a))
Under proposed Sec. 1033.421(a)(1), third parties would have been
required to limit collection, use, and retention of covered data to
what is reasonably necessary to provide the consumer's requested
product or service. Proposed Sec. 1033.421(a)(2) would have provided
that, for purposes of the limitation in proposed Sec. 1033.421(a)(1),
certain listed activities would not be part of, or reasonably necessary
to provide, any other product or service. Under these proposed
provisions, third parties would seek and obtain consumer authorization
to access covered data only as reasonably necessary for the provision
of the product or service that the consumer requested, and not for uses
that are secondary to that purpose.
[[Page 90931]]
The proposed rule explained that the limit on collection, use, and
retention of covered data in Sec. 1033.421(a) was designed to ensure
that, consistent with carrying out the objectives of CFPA section 1033,
third parties that access covered data would act on behalf of
consumers, and that third party collection, use, and retention of
covered data would proceed in alignment with consumer control and truly
informed consent. Specifically, proposed Sec. 1033.421(a) was aimed at
ensuring that third parties access covered data for the consumer's
benefit, that consumers retain meaningful control over their data when
authorizing third party access to that data, and that consumers are
best positioned to understand the scope of that authorization. In
addition, proposed Sec. 1033.421(a) was aimed at ensuring consumers do
not unknowingly or reluctantly acquiesce to data collection, use, and
retention that they do not want. Further, the proposed rule noted that
covered data that third parties would collect, use, and retain pursuant
to consumer authorization would include sensitive financial data that
might subject consumers to fraud or identity theft if it were
exposed.\96\ The proposed rule stated that the limitation in Sec.
1033.421(a) was designed to ensure that third parties would act on
behalf of consumers when accessing that sensitive data.
---------------------------------------------------------------------------
\96\ These sensitive data also could impact persons or entities
besides the consumer from whom they are sourced, especially when
collected, used, and retained in large amounts, such as where the
data are matched with other consumer data sets.
---------------------------------------------------------------------------
The CFPB is generally finalizing Sec. 1033.421(a) as proposed.
Feedback from commenters, and the CFPB's approach in the final rule,
are discussed further below related to each aspect of the general data
limitation standard.
In General (Sec. 1033.421(a)(1))
The CFPB is finalizing Sec. 1033.421(a)(1) as proposed. Under
final Sec. 1033.421(a)(1), third parties must certify to limit
collection, use, and retention of covered data to what is reasonably
necessary to provide the consumer's requested product or service.
Specific aspects of the standard in Sec. 1033.421(a)(1), including
comments received and rationale for the final provisions, are discussed
below.
Reasonably Necessary
As described in the proposed rule, the reasonably necessary
standard was designed to ensure that the consumer is the primary
beneficiary of any authorized data access, and that the resulting
collection, use, and retention of covered data align with consumer
control and informed consent. The CFPB considered a range of
alternatives to this standard, including evaluating limitation
standards in other data privacy regimes.\97\ For example, the CFPB
considered whether data collection, use, and retention should be
limited to what is ``strictly necessary,'' ``adequate,'' ``relevant,''
or ``legitimate.'' The CFPB preliminarily determined that a reasonably
necessary standard would be flexible enough that third parties could
use data for a variety of purposes to provide the product or service
the consumer requested, but would still sufficiently minimize third
party collection, use, and retention to ensure third parties accessing
covered data are acting on behalf of the consumer.
---------------------------------------------------------------------------
\97\ The proposed rule stated that the reasonably necessary
standard in proposed Sec. 1033.421(a)(1) would be similar to
standards in several data privacy frameworks that minimize third
parties' collection, use, and retention of data. See, e.g.,
Competition and Consumer (Consumer Data Right) Rules 2020, div. 1.3
(Austl.) (minimizing consumer data requests to what is ``reasonably
needed''); Reg. 2016/679, art. 5(1)(c), 2016 O.J. (L 119) 7 (EU)
(``Personal data shall be . . . limited to what is necessary in
relation to the purposes for which they are processed.'').
---------------------------------------------------------------------------
The reasonably necessary standard received general support from
many commenters, including data providers, consumer advocates, third
parties, data aggregators, Members of Congress, trade associations for
data providers, and others. These commenters expressed support for
third parties generally limiting their collection, use, and retention
of data based on what is reasonably necessary. Some commenters who
supported the reasonably necessary standard offered for consideration
various clarifications or feedback on other aspects of the rule, like
how the standard might apply to collection, use, or retention
separately. These comments are discussed below related to those
provisions.
Some commenters--mostly third parties and related trade
associations, but also some banks, trade associations for data
providers, and consumer advocates--expressed concerns about the
proposed reasonably necessary standard. Some of these commenters
posited that the proposed standard is stricter than other privacy
regimes, might result in unintended consequences for consumers, does
not give consumers meaningful control, or would result in an unlevel
playing field between data providers and third parties. Other
commenters suggested that the reasonably necessary standard does not go
far enough to constrain downstream data uses not requested by consumers
or to curb activities by data aggregators that would not be necessary
for the provision of the product or service. Other commenters suggested
alternative standards, either from industry or from other privacy laws,
regulations, and principles. Some commenters suggested that collection,
use, and retention each should be governed by different standards. In
contrast, some third party commenters stated that the reasonably
necessary standard for collection is too rigid and impractical for some
products and services. Comments related to the application of the
general limitation standard to collection, use, and retention are
discussed separately below in more detail.
For the reasons discussed herein, the CFPB is finalizing the
reasonably necessary standard in Sec. 1033.421(a) as proposed. The
CFPB considered whether a stricter standard should apply to more
sensitive types of data, and generally whether other standards would be
more consumer protective. After considering comments received and the
CFPB's evaluation of alternatives, the CFPB has determined that the
reasonably necessary standard is sufficiently flexible for third
parties to collect, use, and retain covered data for a variety of
purposes to provide the product or service the consumer requested, but
will still sufficiently minimize third party collection, use, and
retention to ensure third parties accessing covered data are acting on
behalf of the consumer. The CFPB disagrees with commenters that
suggested the standard is too rigid or impractical, or too permissive
for third parties such that it would not protect consumers from
downstream uses or result in other unintended consequences. The
reasonably necessary standard will protect consumers from unwanted data
collection, use, and retention while giving third parties sufficient
flexibility to collect, use, and retain data to provide consumers the
products or services they request. As such, the CFPB declines to make
commenters' suggested changes to the proposed standard.
As described further below, the CFPB has determined that
collection, use, and retention of covered data beyond what is
reasonably necessary for the product or service the consumer requested
would undermine the consumer's understanding of the authorizations they
provided and would thus undermine a consumer's ability to control their
data. The third party obligations, including the limit on collection,
use, and retention of covered data, are designed to ensure that the
third party is accessing covered data for the consumer and that
accordingly the
[[Page 90932]]
consumer is the primary beneficiary of that data access. Third parties
can benefit from access to covered data, but only by collecting, using,
and retaining data as reasonably necessary to provide the consumer's
requested product or service.\98\ A third party that collects, uses, or
retains data in a manner that benefits the third party but that is not
reasonably necessary for the product or service the consumer requested
would not be acting on behalf of the consumer. In that situation, the
third party would be advancing their own the interests, and not the
interests of the consumer, and as such would not be acting as a
representative acting on behalf of the consumer within the meaning of
CFPA section 1002(4).
---------------------------------------------------------------------------
\98\ Consumers benefit by authorizing third parties to collect,
use, or retain their data for the product or service they request,
and from having confidence third parties will not do so other
purposes. The third party's obligations to the consumer do not
prevent the third party from benefiting from access to covered data.
As noted above, third parties can benefit from such access by
collecting, using, and retaining data as reasonably necessary to
provide the consumer's requested product or service. In other words,
the way a third party can benefit is through the opportunity to
provide the consumer the product or service that they are
requesting.
---------------------------------------------------------------------------
Consumer's Requested Product or Service
Under proposed Sec. 1033.421(a)(1), third parties would have been
required to limit collection, use, and retention of covered data to
what is reasonably necessary to provide the consumer's requested
product or service. The second aspect of this standard, ``the
consumer's requested product or service,'' was designed to carry out
the objectives of CFPA section 1033. The proposed rule explained that
consumers generally go into the market seeking the core function of a
product or service and, when authorizing data access, intend for their
data to be accessed for that purpose. The proposed rule explained
further that third parties can significantly benefit from accessing
consumers' covered data, and consumers often do not know about various
data uses, do not want companies to use their data broadly, and also
generally lack bargaining power to adequately protect their data
privacy. The proposed rule stated that, as a result of this imbalance,
third parties often broadly collect, use, and retain covered data for
their own benefit. The CFPB preliminarily determined that the proposed
standard being grounded in the ``consumer's requested product or
service'' would ensure third parties only collect, use, and retain
covered data on consumers' behalf, pursuant to informed consent.
To avoid circumvention of this standard, the CFPB proposed to treat
the product or service as the core function that the consumer sought in
the market and that accrues to the consumer's benefit. The preamble to
the proposed rule explained that the scope of the product or service
would not be defined by disclosures, and the CFPB noted its concern
that disclosures could be used to create technical loopholes by
expanding the scope of the product or service the consumer requested to
include any activity the company would choose, including those that
would benefit the third party, not the consumer. As such, proposed
Sec. 1033.421(a)(1) was intended to help ensure that third parties act
for the benefit of consumers, that consumers retain control over their
authorizations for data access, and that consumers are best positioned
to provide meaningfully informed consent to third party collection,
use, and retention of their covered data.
Some commenters requested clarifications or suggested that the
proposed general standard should be changed with respect to its
approach to the consumer's requested product or service. A data
aggregator commenter stated that the final rule should rely on
``reasonably necessary'' only, and should not limit collection, use, or
retention by the consumer's requested product or service. This
commenter stated that this change would allow third parties to use
previously collected data as reasonably necessary to provide additional
products or services the consumer requests at a later time. Other
commenters requested clarifications about the proposal's approach to
the consumer's requested product or service. For example, a trade
association for data providers, a data provider, and a third party
requested that the phrase ``consumer's requested product or service''
be defined or clarified. A trade association for data providers further
stated that the description of the consumer's requested product or
service in the preamble to the proposed rule gave the impression that
the CFPB intended to decide on a case-by-case basis, based on specific
consumer understanding, what the scope of a requested product or
service is and then determine whether data access based on that scope
was reasonably necessary. A third party stated that the scope of a
consumer's requested product or service would be unclear in light of
how products or services are currently offered to consumers in the
market, as the preamble to the proposed rule potentially would have
divided a product or service by its core functions or component parts.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.421(a) as proposed. Under final Sec. 1033.421(a), a third party's
collection, use, and retention of covered data must be reasonably
necessary to provide the ``consumer's requested product or service.''
By limiting third party collection, use, and retention of covered data
based on ``the consumer's requested product of service,'' the final
rule ensures that such collection, use, and retention is for the
consumer's benefit, that consumers retain control over their
authorizations for data access, and that consumers are best positioned
to providing meaningfully informed consent to third party collection,
use, and retention of covered data. As such, the CFPB declines to adopt
commenters' suggestions to finalize the general limitation standard
without reference to the ``consumer's requested product or service,''
or to otherwise expand the general limitation standard in ways that
would allow for covered data to be used for additional products or
services or other purposes.
To address commenters' concerns about potential confusion, the CFPB
notes that ``the consumer's requested product or service'' in Sec.
1033.421(a) is not intended to result in a case-by-case inquiry into a
specific consumer's understanding of the requested product or service.
Rather, what constitutes a consumer's requested product or service is
informed by context, such as general public understanding of what
attributes a given product or service has or how the product or service
functions in the market. The third party cannot rely on disclosures to
expand the scope of a consumer's requested product or service or use
disclosures to create technical loopholes and include any purposes the
company chooses. The CFPB notes that, in the course of seeking
authorization to access covered data, some third parties might attempt
to expand the scope of products or services offered to consumers in an
effort to access covered data for purposes that do not primarily
benefit consumers. Along those same lines, some third parties might
purport to offer a product or service to a consumer that is merely a
pretext for collecting, using, and retaining covered data from the
consumer.\99\ Where third parties seek to use data to advance their own
interests, rather than to act for the consumer, such actions would not
be on
[[Page 90933]]
behalf of the consumer, and thus would not be in accordance with the
text of sections 1002 and 1033 of the CFPA.
---------------------------------------------------------------------------
\99\ The CFPB notes that such a practice would be inconsistent
with Sec. 1033.401, which provides that third parties must seek
access to covered data on behalf of the consumer to provide a
product or service the consumer requested.
---------------------------------------------------------------------------
Additionally, the CFPB notes that the discussion in the proposal's
preamble related to the product or service's core function was not
intended to suggest that each product or service would necessarily have
only a single attribute. As described above, if a consumer requests a
product or service with a commonly understood set of attributes, the
third party cannot expand the scope of the product or service for
purposes of Sec. 1033.421(a) by including in its disclosures to
consumers attributes that are not consistent with the general public
understanding of that product or service or how that product or service
functions in the market. Whether attributes are associated with a
product or service could be indicated if those attributes are widely
available as, or generally compose, those products or services. While a
third party might offer to a consumer, even within a single mobile
application, two products or services for which a consumer might
authorize data access, like a budgeting service and a payments service,
these services are sufficiently different as to necessitate two
separate authorizations for the purposes of Sec. 1033.421(a).
Similarly, while a credit card and a prepaid card share many
attributes, they are, and are commonly understood to be, different
types of products. Accordingly, authorization for data access to
provide a credit card would not be sufficient authorization for data
access to provide a prepaid card.
Specific Purposes (Sec. 1033.421(a)(2))
Proposed Rule
In addition to the general limitation on collection, use, and
retention of covered data in Sec. 1033.421(a)(1), proposed Sec.
1033.421(a)(2) stated that targeted advertising, cross-selling of other
products or services, or the sale of covered data would not be part of,
or reasonably necessary to provide, any other product or service.
Relying on stakeholder feedback and research, the proposed rule
described that third parties generally do not include these activities
in products or services for consumers' benefit, but instead do so for
their own benefit.\100\ These activities are pervasive in the market,
consumers often lack choices about whether their data can be used for
these purposes, and consumers often do not expect their data to be used
for them. In addition, the CFPB stated that consumers often do not
understand these activities' potential for harm, while also noting that
third parties can greatly benefit from these activities. For all these
reasons, the CFPB preliminarily determined that when a third party
combines targeted advertising, cross-selling, and data sales with any
other consumer requested products or services, it is generally doing so
for its own benefit, and that such combination would interfere with
consumer control and understanding. The CFPB also preliminarily
determined that it would not be consistent with carrying out the
objectives of CFPA section 1033 for a third party to consider
collection, use, or retention of data for these purposes to be within
the scope of the consumer's requested product or service for purposes
of proposed Sec. 1033.421(a)(1).
---------------------------------------------------------------------------
\100\ See, e.g., Rodney John Garratt & Michael Junho Lee,
Monetizing Privacy, at 4, Fed. Rsrv. Bank of N.Y. Staff Rep. No. 958
(Jan. 2021), https://www.newyorkfed.org/medialibrary/media/research/staff_reports/sr958.pdf (``Most of the gains from consumer data do
not go to consumers.''); Raheel A. Chaudhry & Paul D. Berger, Ethics
in Data Collection and Advertising, 2 GPH Int'l J. of Bus. Mgmt. 1,
5-6 (2019), http://www.gphjournal.org/index.php/bm/article/view/240/110 (stating that targeted advertising and data monetization allow
companies to collect, use, and retain ``consumer data without the
user being any the wiser,'' and that targeted advertising and data
monetization elevate ``the risk involved in data breaches and
malicious parties buying consumer data on the secondary data
market'').
---------------------------------------------------------------------------
The CFPB explained that proposed Sec. 1033.421(a)(2) would not
prevent third parties from engaging in the specified activities as
standalone products. To the extent the core function that the consumer
seeks out in the market is such an activity, a third party could
potentially provide that core function to the consumer consistent with,
and subject to, the terms of the proposed rule. Any such offering would
be subject to other applicable laws, including the CFPA's prohibition
on unfair, deceptive, and abusive practices.
Comments Received
Commenter feedback on the proposed limitation on targeted
advertising, cross-selling of other products or services, and data
sales was varied. Some consumer advocates, data providers, and trade
associations representing data providers expressed support for the
proposed limitation in Sec. 1033.431(a)(2). For example, some trade
associations representing data providers stated that dark patterns or
other deceptive practices from third parties result in consumers giving
consent to activities consumers are not aware of, especially related to
data sales and targeted marketing, and that requiring third parties to
separately follow the authorization procedures to obtain consumer
authorizations for these activities would be beneficial to consumers.
An individual commenter similarly stated that consumers should not
become subject to ``surveillance capitalism'' through authorization of
third parties' use of covered data.
Various commenters, including trade associations for data
providers, data providers, trade associations for nondepositories, data
aggregators, consumer advocates, and others, appeared to have different
understandings about whether the proposed limitation in Sec.
1033.421(a)(2) would prohibit consumers from authorizing their data to
be accessed for these purposes. Some commenters appeared to interpret
the proposal as a prohibition on such authorization. Others appeared to
understand the proposal as permitting third parties, using covered data
pursuant to consumer authorization, to engage in targeted advertising,
cross-selling, and data sales as standalone products the consumer seeks
out in the market. At least one trade association for data providers
appeared unsure if the proposal would prohibit these activities,
stating that the meaning of the phrase in the rule ``any other product
or service'' is unclear.
Various commenters, including data providers, trade associations
for data providers, consumer advocates, and other trade associations,
asked for definitions of targeted advertising, cross-selling, and data
sales. A consumer advocate and a trade association representing data
providers proffered potential definitions. These commenters suggested
that, without clarity on the bounds of these terms, the rule would lack
sufficient clarity because the terms have broad and varied meaning in
the market. For example, these commenters said the term targeted
advertising is potentially broad and could cover advertising that uses
consumers' personal characteristics and could also potentially include
other concepts like contextual marketing that does not require precise
identifiers. These commenters were also concerned about the definition
of cross-selling because, as described by these commenters, the term
could include some traditional attributes of personal financial
management services that offer recommendations to consumers. A data
provider commenter noted that the CFPB has not previously defined
cross-selling of other products or services or data sales. A consumer
advocate commenter suggested that the CFPB define data sales as the
``sale, rental, exchange, or other transfer or use not otherwise
authorized.'' Finally, two trade associations representing data
[[Page 90934]]
providers requested that the CFPB develop a clear concept or definition
of what ``any other product or service,'' means, and what ``standalone
product'' means, as these terms may not have been clear in the proposed
rule.
Some commenters, including research organizations and third
parties, expressed concern that proposed Sec. 1033.421(a)(2) might
result in a prohibition on targeted ads, cross-selling, and data sales
because, at least in some circumstances, they may not be traditionally
offered as standalone products or services. A research organization and
a third party commenter stated that the proposal might preclude third
parties from using covered data for these purposes where they are
traditionally a component of a product or service and are not
standalone products or services. These commenters offered examples of
products or services that might benefit consumers and might include
targeted advertising or cross-selling. Some commenters, like trade
associations for nondepositories, third parties, research institutes,
consumer advocates, and data aggregators, asserted that proposed Sec.
1033.421(a)(2) could result in consumer harms, such as higher prices,
hindered choice, and others. These commenters expressed concerns about
competition harms, like increased barriers to market entry for new
companies who would traditionally rely on targeted advertising and
cross-selling to generate growth, decreased innovation of new products,
services, or business models, and increased consolidation in existing
market players. These commenters stated that the CFPB did not account
for the benefits to consumers through targeted advertising and cross-
selling, and overstated potential harms. For example, some of these
commenters cited studies they characterize as showing that consumers
consistently authorize targeted advertising when given choices,
significantly benefit from targeted advertising, and benefit from the
competition that targeted advertising generates within the market.\101\
---------------------------------------------------------------------------
\101\ See, e.g., J. Howard Beales & Andrew Stivers, An
Information Economy Without Data, at 15-16 (Nov. 2022); Patrick
Grieve, Personalized Customer Service: What It Is and How to Provide
It, ZenDesk (Feb. 2023), https://www.zendesk.com/blog/start-providing-personalized-customer-service/; Holly Pauzer, 71% of
Consumers Prefer Personalized Ads, Adlucent (2016), https://www.adlucent.com/resources/blog/71-of-consumers-prefer-personalized-ads/; Yan Lau, A Brief Primer on the Economics of Targeted
Advertising, FTC 11-12 (Jan. 2020), https://www.ftc.gov/system/files/documents/reports/brief-primer-economics-targeted-advertising/economic_issues_paper_-_economics_of_targeted_advertising.pdf; Bus.
Wire, ICSC's Small Business Consumer Survey Reveals the Ongoing
Importance of Small Businesses in the Lives of Consumers and
Communities in the U.S. (May 2, 2022), https://bwnews.pr/3rZ2KF3.
---------------------------------------------------------------------------
Some trade associations and third parties stated that the proposed
limitation on targeted advertising, cross-selling of other products and
services, and data sales would not ensure consumers are able to consent
to third party products or services consumers might want and would
therefore be a restriction on consumer choice. A trade association for
nondepositories also stated that, if a consumer consents to third party
collection of covered data for certain uses, like targeted advertising,
then a prohibition on that use would run afoul of the First Amendment.
Finally, some commenters, including trade associations for
nondepositories, a law firm, third party commenters, and data
aggregators suggested that proposed Sec. 1033.421(a)(2) is contrary to
the congressional intent of CFPA section 1033 to ensure consumers can
access data to use for their own preferences. These commenters stated
that the CFPB generally lacks authority to prescribe limitations on the
use of covered data, especially as it relates to targeted advertising,
cross-selling of other products and services, and data sales. These
commenters also objected to the CFPB's rationale for these proposed
provisions and stated that the proposed rule did not evidence reasoned
decision making or meaningful consideration of the consequences of
intrusion into private, consent-based consumer relationships with third
parties. Specifically, a trade association and law firm stated that
CFPA section 1033 provides consumers an affirmative right to access
their financial data but does not permit the CFPB to limit a third
party's collection, use, and retention of covered data if the consumer
has agreed to it. These commenters also stated that Congress intended
that representatives acting on behalf of consumers would adhere to
principles of agency law, which they said would result in
authorizations from consumers to third parties that would carry
regardless of whether the consumer benefits from the authorization.
These commenters stated that if the consumer agrees to terms of data
access, then the third party is acting on the consumer's behalf.
Final Rule
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.421(a)(2) with minor modifications. Final Sec. 1033.421(a)(2)
provides that, for the purposes of the general limitation standard
Sec. 1033.421(a)(1), the following are not part of, or reasonably
necessary to provide, any other product or service: (i) targeted
advertising; (ii) cross-selling of other products or services; or (iii)
the sale of covered data. For clarity, the CFPB is removing the term
``activities'' from the text of final Sec. 1033.421(a)(2) and
replacing the term with ``purposes'' in that provision's heading.
With respect to commenter concerns regarding consumer authorization
for the purposes listed in Sec. 1033.421(a)(2), the CFPB notes that
Sec. 1033.421(a)(2) does not prevent third parties from obtaining
authorizations from a consumer to collect, use, and retain their
covered data for any one of these specified purposes if offered as a
standalone product or service. To the extent that the consumer seeks a
product or service in the market which functions as targeted
advertising, cross-selling of other products or services, or the sale
of covered data, a third party could obtain a consumer's authorization
to collect, use, and retain their covered data to provide that product
or service to the consumer consistent with, and subject to, the terms
of subpart D of part 1033.\102\ Collection, use, and retention of
covered data to provide such a product or service would be subject to
other applicable laws, including the CFPA's prohibition on unfair,
deceptive, and abusive practices.
---------------------------------------------------------------------------
\102\ The CFPB has previously issued guidance related to
commingling of targeting and delivery of advertisements to
consumers. See generally Consumer Fin. Prot. Bureau, Limited
Applicability of Consumer Financial Protection Act's `Time or Space'
Exception With Respect to Digital Marketing Providers, 87 FR 50556
(Aug. 17, 2022).
---------------------------------------------------------------------------
To be a ``standalone'' product or service, it must be clear that
the targeted advertising, cross-selling, or sale of covered data is a
distinct product or service the consumer could obtain in the market
without obtaining other products or services.\103\ As such, one
provider could offer multiple products to a consumer, including
targeted advertising, cross-selling, or sale of covered data as
standalone products, obtain separate authorizations for consumer's data
to be used for those
[[Page 90935]]
products or services, and provide those products or services to the
consumer. This would be similar to a bank that may offer checking
accounts, savings accounts, and credit cards to a consumer, even while
allowing those services to be managed on one banking app.
---------------------------------------------------------------------------
\103\ As described above related to the consumer's requested
product or service, the CFPB does not intend to suggest a
``standalone product or service'' would necessarily have only a
single attribute. While many standalone products or services might
have only one attribute, as in cases where third parties sell
covered data, others may have more than one attribute. A third party
might provide to consumers a standalone product or service of
targeted advertising, which could have multiple attributes to ensure
the consumer is receiving the product or service they would expect.
For example, a ``standalone product'' that involves targeted
advertising might both evaluate a consumer's data for the purpose of
identifying lower cost credit cards for a particular consumer and
send that consumer advertisements for such lower cost credit cards.
---------------------------------------------------------------------------
Further, as described in the proposed rule, the CFPB is concerned
that consumers do not seek in the market targeted advertising, cross-
selling of other products and services, and data sales.\104\ Commenters
suggested that consumers can significantly benefit specifically from,
and continue to sign up for, targeted advertising and cross-selling in
various contexts. As described above, commenters provided some evidence
that consumers sign up for targeted advertising and cross-selling and
receive certain benefits from them. Other research suggests that any
such benefits are uncertain at best and may be difficult to quantify.
Regardless, the CFPB recognizes that consumers might continue to sign
up for, and in some cases can benefit from, targeted advertising,
cross-selling, and data sales. However, this does not indicate that
consumers understand the consequences of third parties using data for
these purposes,\105\ are the primary beneficiary of collection, use,
and retention for these purposes,\106\ or that consumers specifically
sought them out.\107\ Instead, this might indicate that consumers have
little choice but to sign up for, or unknowingly or reluctantly
acquiesce to, targeted advertising and cross-selling to receive more
preferable or free services.\108\
---------------------------------------------------------------------------
\104\ See, e.g., Rodney John Garratt & Michael Junho Lee,
Monetizing Privacy, at 4, Fed. Rsrv. Bank of N.Y. Staff Rep. No. 958
(Jan. 2021), https://www.newyorkfed.org/medialibrary/media/research/staff_reports/sr958.pdf (stating that ``[m]ost of the gains from
consumer data do not go to consumers''); Raheel A. Chaudhry & Paul
D. Berger, Ethics in Data Collection and Advertising, 2 GPH Int'l J.
Bus. Mgmt. 1, 5-6 (2019), http://www.gphjournal.org/index.php/bm/article/view/240/110 (stating that targeted advertising and data
monetization allow companies to collect, use, and retain ``consumer
data without the user being any the wiser,'' and that targeted
advertising and data monetization elevate ``the risk involved in
data breaches and malicious parties buying consumer data on the
secondary data market''); Yan Lau, A Brief Primer on the Economics
of Targeted Advertising, Bureau of Econ., Fed. Trade Comm'n, at 9-10
(2020), https://www.ftc.gov/system/files/documents/reports/brief-primer-economics-targeted-advertising/economic_issues_paper_-_economics_of_targeted_advertising.pdf (describing that, while
consumers can benefit from targeted advertising, there are multiple
consumer harms that result from targeted advertising, such as:
consumers may underestimate the ``degree and consequence of the
personal data collection websites carry out in exchange for
providing free digital goods and services''; consumers may feel the
benefits of targeted advertising do not outweigh the ``perceived
intrusiveness of the advertising''; and consumers may experience
harms related to data breaches or misuse of their data).
\105\ See generally Brooke Auxier et al., Americans and Privacy:
Concerned, Confused and Feeling Lack of Control Over Their Personal
Information, Pew Rsch. Ctr. (Nov. 15, 2019), https://www.pewresearch.org/internet/2019/11/15/americans-and-privacy-concerned-confused-and-feeling-lack-of-control-over-their-personal-information/ (describing findings that only ``one-in-five adults
overall say they always (9 percent) or often (13 percent) read a
company's privacy policy before agreeing to it'' and that 59 percent
say ``they understand very little or nothing about'' what companies
do with data they collect); Neil Richards & Woodrow Hartzog, The
Pathologies of Digital Consent, 96 Wash. U.L. Rev. 1461, 1479
(2019), https://openscholarship.wustl.edu/cgi/viewcontent.cgi?article=6460&context=law_lawreview (``[F]ar too
often, far too many people in the digital environment have little to
no idea about what data practices or exposure that they are
consenting to.'').
\106\ See generally Eduardo Abraham et al., Behavioral
Advertising and Consumer Welfare: An Empirical Investigation, SSRN
Elec. J., at 2 (2023), https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4398428 (``[L]ittle is known about the manner
and extent to which targeted ads affect consumers' welfare. In fact,
the relationship between a product being associated with targeted
ads and its price, quality, or novelty . . . has not been explored.
Some models suggest that, if consumers had to make a voluntary
decision to provide personal information to advertisers, only those
who benefit from it would do so, and therefore targeted advertising
should be strictly beneficial to them.'').
\107\ See generally Charlotte A. Tschider, Meaningful Choice: A
History of Consent and Alternatives to the Consent Myth, 22 N.C.
J.L. & Tech. 617, 635-37, 639 (2021) (explaining that while
consumers might consent to certain activities presented to them,
their consent might not reflect autonomous choice from the consumer
or the consumer's desires).
\108\ See April Falcon Doss, Cyber Privacy, at 54 (BenBella
Books, Inc. 2020) (explaining that the business model of companies
that monetize consumer data are able to exploit information
asymmetries and bargaining power imbalances such that, even if a
consumer has a higher risk tolerance and is willing to share more
data for the purposes of monetization of that data, digital
platforms offer consumers very little choice to exercise those
preferences); Charlotte A. Tschider, Meaningful Choice: A History of
Consent and Alternatives to the Consent Myth, 22 N.C. J.L. & Tech.
617, 637 (2021) (positing that consumers who consent to products or
services might struggle to understand the differences of primary
uses from secondary uses where the two are bundled into contracts of
adhesion, of which consumers might only want some aspects but not
all of what they authorized).
---------------------------------------------------------------------------
The CFPB understands that it is possible for consumers to benefit
from targeted advertising, cross-selling, and data sales and the final
rule ensures that consumers can authorize their covered data to be
collected, used, and retained for these purposes, with provisions to
ensure consumers are able to make a meaningful choice to do so.\109\
The final rule recognizes that consumers should not have to unknowingly
or reluctantly acquiesce to their covered data being collected, used,
and retained for these purposes in order to receive a product or
service they have sought in the market. As such, the CFPB affirms that,
under the final rule, consumers can authorize their data to be
collected, used, and retained for targeted advertising, cross-selling,
or data sales if offered as standalone products or services--this
authorization simply cannot be combined in one authorization for data
access for other products or services.
---------------------------------------------------------------------------
\109\ See generally Alessandro Acquisti et al., Behavioral
Advertising and Consumer Welfare, at 16 (2023), https://dx.doi.org/10.2139/ssrn.4398428 (``The results suggest that a search will, on
average, make consumers who are price focused and have low search
costs (relative to the price of the product) better off. These
results also highlight that display advertisements may be a useful
channel for smaller vendors to reach consumers: some of these
vendors may seldom (if ever) appear in organic search. Such results
highlight the complex nature of consumer welfare effects from
targeted advertising. If search costs are sufficiently low and
consumers are generally aware of the product categories which
interest them, targeted ads are unlikely to improve their surplus.
Surplus gains are even less likely to accrue to consumers if they
need to vet the lesser known vendors that appear in display
advertising. More than likely, this additional effort is better used
seeking out relevant products via traditional search.'').
---------------------------------------------------------------------------
As noted above, some commenters stated that proposed Sec.
1033.421(a)(2) was contrary to the congressional intent of CFPA section
1033 to ensure consumers can access their own data for their own
preferences. These commenters also stated that the proposed rule would
otherwise result in a restriction of consumer choice. However, Sec.
1033.421(a)(2) does not restrict consumer choice or inhibit consumers
from accessing their data for their own preferences. Under the final
rule, third parties can, pursuant to consumer authorization, collect,
use, and retain covered data to provide, targeted advertising, cross-
selling of other products or services, or data sales as standalone
products or services.
As described above, a trade association for nondepositories argued
that the provision related to cross-selling, targeted advertising, and
data sales would violate the First Amendment's protections on
commercial speech if it prohibited data to be collected, used, and
retained by third parties for these purposes when a consumer otherwise
consents. However, the final rule does not infringe on any First
Amendment rights. Even assuming the final rule could be construed to
restrain speech, it would readily survive the applicable standard of
scrutiny for commercial speech. Under the Supreme Court's commercial
speech framework, if the speech is not misleading and relates to lawful
activity, the government may impose restrictions that advance a
substantial government interest and are no more extensive than is
necessary to serve that interest. As explained elsewhere, the final
rule advances several substantial interests,
[[Page 90936]]
including the need for consumer control of personal financial data and
privacy protections. The requirements set forth in the rule are also
appropriately tailored to achieve these interests. As previously noted,
the CFPB affirms that collection of covered data for certain uses,
including cross-selling, targeted ads, and data sales, may be
separately authorized as a standalone product or service. This
regulatory structure provides the appropriate balance to ensure
consumers are given a meaningful choice before engaging in targeted
advertising, cross-selling, and data sales, and that they are shielded
from signing up for purposes that they do not understand or do not
request.
Additionally, as described above, commenters asked for and
suggested definitions for targeted advertising, cross-selling of other
products or services, and data sales. For the purposes of Sec.
1033.421(a)(2), the CFPB intends to take the position that targeted
advertising is advertising that comprises the identification or
selection of prospective customers or the selection or placement of
content to affect consumer engagement, including purchase or adoption
behavior. Cross-selling of other products and services is the
advertising, sale, or referral of the third party's own products or
services to the third party's existing customers. Data sales is
selling, renting, releasing, disclosing, disseminating, making
available, transferring, or otherwise communicating personal
information for monetary or other valuable consideration.
Limitations on Collection of Covered Data (Sec. 1033.421(b))
Proposed Sec. 1033.421(b) contained third party obligations
related to collection of covered data. Under proposed Sec.
1033.421(b), as a condition of being authorized to access covered data
on a consumer's behalf, the third party would be required to (1) limit
its collection of covered data, including the scope of covered data, to
what is reasonably necessary to provide the consumer's requested
product or service, consistent with Sec. 1033.421(a); (2) limit the
duration of collection of covered data to the maximum durational
period; (3) obtain a new authorization from the consumer, in a
reasonable manner, to collect covered data beyond the maximum
durational period; and (4) abide by certain limitations on collection,
use, and retention of covered data beyond the maximum durational period
if the third party does not obtain a new authorization from the
consumer.
The specific provisions of Sec. 1033.421(b) are discussed below.
In General (Sec. 1033.421(b)(1))
Proposed Sec. 1033.421(b)(1) stated that, for purposes of the
general limitation on collection, use, and retention of covered data in
proposed Sec. 1033.421(a), collection of covered data would include
the scope of covered data collected and the duration and frequency of
collection of covered data.
Some commenters, including consumer advocates, data providers,
trade associations for data providers, and research organizations,
stated general support for the proposed limitations on collection. Some
commenters, including consumer advocates and third parties, suggested
that consumers should have more control than what the proposed rule
would have required over how long and how often third parties collect
covered data, and that the proposed standard to limit collection might
not adequately account for third parties' ongoing relationships with
consumers. Other commenters, particularly data providers and third
parties, suggested that data providers should have a role in ending
third party access if collection exceeds the scope of the consumer's
authorization.
For the reasons discussed herein, the CFPB is generally finalizing
Sec. 1033.421(b) as proposed, with one modification. The CFPB has
determined that third parties are the commercial actors in the best
position to understand the covered data they need to collect from the
data provider to facilitate provision of products or services, and to
therefore limit that collection to only what is reasonably necessary to
provide the consumer's requested product or service. The CFPB has also
determined that the standard to limit collection to what is reasonably
necessary provides third parties with sufficient flexibility to account
for the needs of the requested product or service.
The CFPB is revising the language of proposed Sec. 1033.421(b)(1)
to state that collection includes the scope of covered data
``requested,'' instead of the proposed ``collected.'' This clarifies
that, in certifying to limit the collection of covered data pursuant to
Sec. 1033.421(a), third parties must tailor their request for covered
data to only what is reasonably necessary to provide the consumer's
requested product or service.
The CFPB notes that, in some circumstances, the third party might
receive from the data provider more data than the third party requests.
For example, this could happen when, pursuant to Sec. 1033.211(d), the
third party requests terms and conditions data from the data provider
and the data provider provides more data elements than the third party
requested, or more than is reasonably necessary to provide the
consumer's requested product or service consistent with Sec.
1033.421(a). Additionally, third parties could receive data after a
consumer has revoked the third party's access to the data pursuant to
Sec. 1033.421(h), before the data provider has processed the request.
In circumstances where the third party receives more data than they
request, the general limitation on use and retention in Sec.
1033.421(a) would not allow third parties to use that data if such use
is not reasonably necessary. Section 1033.421(a) would allow a third
party to retain covered data for as long as reasonably necessary to
locate and delete the data.
Further, pursuant to the certifications related to collection in
Sec. 1033.421(a) and (b), if a third party receives information that
indicates the consumer may no longer expect to receive the product or
service, the third party should confirm collection of covered data
remains reasonably necessary.
Maximum Duration (Sec. 1033.421(b)(2))
Under proposed Sec. 1033.421(b)(2), third parties would be
required to certify to limit the duration of collection of covered data
to a maximum period of one year after the consumer's most recent
authorization. The proposed rule described this as the maximum
durational limit.
Regarding the maximum durational limit, the proposed rule noted
that some products or services, like bill pay, overdraft prevention, or
personal financial management, require long-term access. For such
products or services, the proposed rule stated that the general
limitation standard may not be sufficient to ensure that third parties
act on behalf of consumers when collecting data longer term. The
proposed rule stated that consumer needs or expectations may change in
ways that may not be apparent to the third party, as could happen when
a consumer stops using a product or service and forgets that they
authorized third party data access. The proposed rule stated that, in
other cases, consumers may have attempted to end third party access
without actually doing so, such as when a consumer deletes an
application from a device with the intent of stopping data collection,
use and retention. At the same time, the proposed rule also
acknowledged that there are other cases where consumers request
products or
[[Page 90937]]
services that require long-term data collection and want to authorize
ongoing third party data access. In those cases, the CFPB preliminarily
determined that it would frustrate consumer intent and burden third
parties to terminate third party access or require frequent
reauthorizations. The proposed rule stated that a maximum durational
limitation would provide a helpful backstop on the duration of third
party authorization for these consumers.
Comments were mixed between supporting the proposed provision and
recommending changes. Commenters that supported a maximum durational
limitation, mostly banks, credit unions, community banks, trade
associations for data providers, and research institutes, stated that
such a limit promotes consumer control by requiring third parties to
seek periodic reauthorization. Commenters that were critical of the
proposal to impose a maximum durational period, mostly third parties,
trade associations for third parties, and consumer advocates, stated
that, if implemented, a maximum duration requirement would ultimately
result in consumer harms, like: increased and unhelpful friction
because of required reauthorization; disruption of valuable products
and services that require ongoing collection, use, and retention in
cases where consumers do not reauthorize; and disruption to the user
experience if consumers utilize a product or service continually but
must still reauthorize.
Commenters who supported a one-year maximum duration limitation
commended the provision for reducing friction as compared to other
privacy regimes that require shorter durational periods and therefore
increased requests for reauthorization. In contrast, a trade
association for third parties stated the CFPB did not provide adequate
support for the proposed one-year maximum durational period and would
not be consistent with the consumer's consent for the third party to
continually collect their data. A data aggregator suggested amending
the maximum durational period to 13 months, rather than 12, to better
account for products and services that may have a slightly longer cycle
of relevance for consumers, like tax preparation software. Further,
various third parties and trade associations for nondepository
commenters suggested the CFPB account for payments products or services
through more narrow or more flexible durational limits, including by
incorporating flexibilities based on the consumer's use of the product
or service. These commenters suggested consumer authorization should
last as long as consumers actively use the product or service, or
suggested other activity-based flexibilities or restrictions. Finally,
a trade association for community banks stated that the final rule
should make clear that the general limitation standard of reasonable
necessity would mean many short-term products and services would end
before the maximum durational period ends.
For the reasons discussed herein, the CFPB is finalizing in Sec.
1033.421(b)(2) a maximum durational limit of one year after the
consumer's most recent authorization. This approach protects consumers
by helping prevent unwanted, long term data collection, and also
ensures consumers are able to periodically revisit the authorizations
they have provided to third parties and ensure third party data access
reflects consumers' wishes. Specifically, the one-year durational limit
provides a helpful backstop to consumers who sign up for products or
services that include ongoing data collection. For these reasons, the
CFPB declines to allow for authorizations longer than 12 months when a
consumer is actively using a product or service, as requested by some
commenters. While, as described above, some commenters raised concerns
about added friction for consumers related to a maximum durational
limit, some of this friction is a necessary and helpful aspect of the
consumer's relationship with the authorized third parties, as it
provides consumers opportunities to carefully consider their choices.
The maximum durational limit and the general obligation to limit
collection to what is reasonably necessary to provide the consumers'
requested product or service account for the wide variety of products
or services the consumer might seek. For products or services that
necessitate shorter durations of collection, like traditional
underwriting and identity verification, the general data limitation
standard will result in collection of covered data for a shorter period
than one year. And, as noted above and in the proposed rule, consumers
benefit from a one-year maximum durational period in cases where the
general limitation standard may not be sufficient to ensure that third
parties act on behalf of consumers when collecting data longer term.
Reauthorization After Maximum Duration (Sec. 1033.421(b)(3))
Under proposed Sec. 1033.421(b)(3), the third party would certify
that, to collect covered data beyond the one-year maximum durational
period, the third party would obtain a new authorization from the
consumer no later than the anniversary of the most recent authorization
from the consumer. Under the proposed rule, the third party would be
permitted to ask the consumer for a new authorization in a reasonable
manner. The proposed rule stated that indicia that a new authorization
request would be reasonable would include its conformance to a
qualified industry standard.
The proposed rule stated that consumers would benefit from the
combination of a maximum durational limit of one year and from the
control that reauthorization requirements might provide. The proposed
rule further stated that the CFPB preliminarily determined that third
parties might need to seek new authorizations multiple times or
otherwise explain to consumers why they are seeking new authorizations,
but that this might unnecessarily burden consumers if they receive too
many requests, or requests for products or services they no longer
want. The proposed rule stated that the CFPB sought to strike a balance
between these competing considerations. The proposed rule also
acknowledged that additional guidelines regarding reauthorization
requests might facilitate compliance. As such, the proposed rule stated
that indicia that a new authorization request is reasonable include its
conformance with a qualified industry standard.
Some commenters--including banks, trade associations for credit
unions, and third parties--offered support for the proposed
reauthorization provision, stating that consumers often forget about
their connections and could benefit from opportunities to reauthorize.
Some data aggregators, trade associations for banks, consumer
advocates, and research organizations did not clearly oppose the
proposed rule but offered narrow critiques or suggested changes,
discussed below.
Some trade associations for third parties and data aggregators
expressed concern that consumers would not provide a new authorization
at the end of a maximum duration limit when they might otherwise want
their authorizations to continue, which could result in harm to
consumers. For example, one third party suggested that if a consumer
never reauthorizes, the consumer might be directly harmed by the cut-
off of the maximum durational period before the consumer accrues the
benefits of long-term data collection.
[[Page 90938]]
Commenters' suggested modifications, clarifications, or additions
to the implementation of reauthorization include: specify in the rule
that a consumer's most recent authorization includes when a consumer
requests a third party to refresh their data, or every time a payment
goes through; finalize more specific limitations for requesting
reauthorization, including limiting pop-ups and notices, the number of
requests, or requests that could be threatening, misleading, or
otherwise negatively impact consumers; allow the consumer to provide
more streamlined reauthorizations as compared the initial
authorization, or fewer reauthorization for certain products or
services with which consumers regularly interact, like peer-to-peer or
periodic payment products; allow flexibility for reasonable
reauthorization methods, including directly to consumers via electronic
means; allow third parties to simply notify the consumer of ongoing
collection, use, and retention; and clarify the reasonable manner
requirement related to reauthorization.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.421(b)(3) as proposed with a terminology change to conform to the
final rule's use of the term ``consensus standard.'' Specifically,
final Sec. 1033.421(b)(3) provides that, to collect covered data
beyond the one-year maximum period described in Sec. 1033.421(b)(2),
the third party will obtain a new authorization from the consumer
pursuant to Sec. 1033.401 no later than the anniversary of the most
recent authorization from the consumer. Final Sec. 1033.421(b)(3)
further provides that the third party is permitted to ask the consumer
for a new authorization pursuant to Sec. 1033.401 in a reasonable
manner. Final Sec. 1033.421(b)(3) further provides that indicia that a
new authorization request is reasonable include its conformance to a
consensus standard.
The CFPB acknowledges that this approach may result in some
increased friction for consumers, but it will also allow consumers to
periodically confirm their previous choices, including that they
continue to want the third party to access their data for the requested
product or service. Commenters appeared to assume that consumers
generally will not reauthorize at the end of one year, but did not
provide evidence that consumers, on the whole, will not reauthorize
after a maximum duration period of one year, at least in circumstances
in which they want data access to continue. As such, after considering
this feedback, the CFPB is not making changes to the proposed
reauthorization requirement.
Some commenters suggested the final rule should allow third parties
to provide streamlined reauthorization requests to consumers, including
suggesting that facilitated payments could serve as periodic
reauthorizations for consumers. The CFPB has determined that consumers
could benefit significantly from the authorization procedures as
described in Sec. 1033.401, including the authorization disclosure,
and that streamlined reauthorization procedures would not effectively
ensure consumers remain informed and in appropriate control of data
access. The CFPB is thus not adopting commenters' suggested
modifications to streamline reauthorization requests.
Effects of Maximum Duration (Sec. 1033.421(b)(4))
Proposed Sec. 1033.421(b)(4) would have required the third party
to certify that, if a consumer does not provide a new authorization
before the maximum durational periods, the third party would (1) no
longer collect covered data pursuant to the most recent authorization,
and (2) no longer use or retain covered data that was previously
collected pursuant to the most recent authorization unless use or
retention of that covered data remains reasonably necessary to provide
the consumer's requested product or service under proposed Sec.
1033.421(a). The CFPB is finalizing these provisions, without
substantive change, in Sec. 1033.421(i), discussed below. Comments
regarding proposed Sec. 1033.421(b)(4) are discussed in detail below
related to Sec. 1033.421(i).
Limitations on Use of Covered Data (Sec. 1033.421(c))
Proposed Rule
As discussed above, the CFPB proposed in Sec. 1033.421(a) that, to
be authorized to access covered data, a third party must certify to
using covered data only as reasonably necessary to provide the
consumer's requested product or service. Preamble to the proposed rule
explained that use of covered data that is not reasonably necessary to
provide the consumer's requested product or service would be
``secondary use,'' and would not be permitted as part of the third
party's authorization to access the consumer's covered data. The
proposed rule specified in Sec. 1033.421(c) that, in addition to
limiting the third party's own use of covered data, third parties would
not be able to provide covered data to other third parties unless doing
so would be reasonably necessary to provide the consumer's requested
product or service.
Further, for clarity, proposed Sec. 1033.421(c) provided the
following examples of uses of covered data that would be permitted as
reasonably necessary under proposed Sec. 1033.421(a): (1) uses that
are specifically required under other provisions of law, including to
comply with a properly authorized subpoena or summons or to respond to
a judicial process or government regulatory authority; (2) uses that
are reasonably necessary to protect against or prevent actual or
potential fraud, unauthorized transactions, claims, or other liability;
and (3) servicing or processing the product or service the consumer
requested. The proposed rule stated that these examples would provide
third parties with additional clarity on how the limitation standard
would apply with respect to certain business activities. The CFPB
sought feedback on whether it should include in the final rule other
examples of business activities that are reasonably necessary to
provide consumer requested products or services.
The proposed rule also sought feedback on whether the final rule
should permit third parties to solicit consumers' opt-in consent to
some secondary uses of consumer data to provide flexibility to third
parties while maintaining important consumer protections. For example,
the proposed rule sought feedback on whether the final rule should
permit third parties to solicit consumers' opt-in consent to secondary
uses as part of a third party's authorization to access covered data,
while requiring third parties to certify not to use covered data for
certain higher-risk secondary uses. The proposed rule also sought
feedback on whether the final rule should permit third parties to
solicit a consumer's opt-in consent to engage in secondary uses with
de-identified data, and if so, what de-identification standard the rule
should provide. The proposed rule sought feedback on how any opt-in
approach could be structured to ensure that consumers are providing
express informed consent to any secondary data uses, and whether the
proposed authorization disclosure would be an appropriate vehicle for
soliciting granular consumer choices about data use, such as through a
secondary use opt-in mechanism. Finally, the proposed rule sought
feedback on how opt-in mechanisms could be implemented to prevent third
parties from using ``dark patterns'' or deceptive practices aimed at
soliciting consumer consent.
[[Page 90939]]
Comments Received
Commenter feedback on the proposed limitation on use was varied.
Regarding the examples in proposed Sec. 1033.421(c), many commenters,
including third parties and third party trade associations, privacy
organizations, Members of Congress, and data aggregators, requested
that the CFPB specify additional uses that would be permissible under
the final rule. Other examples of additional uses that commenters
requested the CFPB specify in the final rule included product
improvement, new product development, prevention of crime or
illegality, offering beneficial products or services to consumers,
supplemental primary uses, reporting of data, and internal and external
research. Some research institutes, a third party, and a trade
association raised concerns about the proposed examples of reasonably
necessary uses set forth in proposed Sec. 1033.421(c), and
specifically raised concerns that the example for servicing or
processing the consumer's requested product or service was too narrow.
These commenters suggested additions that would broaden that example,
like ``assessing the consumer's eligibility for or delivering,
servicing, or processing the product or service the consumer
requested,'' allowing third parties to service or process products or
services on which the consumer's requested product or service relies,
or providing more elaboration or clarification about the meaning of
servicing or processing.
Regarding the proposed limitation on secondary uses, a wide range
of commenters, including data providers, consumer groups, and research
organizations, were generally supportive of strong restrictions on
secondary use, but most commenters asserted that the proposed secondary
use limitation would be overly restrictive. Many commenters stated that
a prohibition on secondary use, without modification and limited
exceptions, would negatively affect product innovation, overly restrict
consumer choices for potentially beneficial products, and put third
parties at a significant competitive disadvantage to data providers
that are unrestricted by the limitation. Some of these commenters
suggested alternative approaches, including categories of permissible
uses that are not primary or secondary. Some third parties, Members of
Congress, and research institutes raised concerns about how a strict
limitation on secondary uses might impact beneficial products or
services for consumers, like cash-flow underwriting. Some third party
commenters requested that the final rule permit more expansive uses
related to fraud prevention. And many third parties asserted that the
proposed secondary use restrictions would harm consumers and raise
costs or reduce revenues for third parties. They stated that such
restrictions would reduce competition and innovation, limit their
ability to detect and prevent fraud, and prevent third parties from
improving their products and services. Some commenters asserted that
the prohibition on secondary use would be an outlier among existing
privacy regimes. A few third party commenters recommended that the
final rule allow uses that are also permitted by the GLBA and
Regulation P because, these commenters claimed, different use
limitations would unfairly disadvantage third parties and confuse
consumers.
Commenters suggested a range of revisions to address these concerns
in the final rule, including that the CFPB permit some secondary uses,
like those listed above, and should more strictly prohibit some
specific uses. For example, some commenters, like data providers and
trade associations for data providers, stated that the CFPB should
specifically prohibit certain uses, like uses of data for reverse
engineering of proprietary algorithms.
Some commenters, including third parties, third party trade
associations, and some privacy organizations, advocated for the final
rule to permit consumers to opt into secondary data uses. These
commenters stated that opt-in consents would benefit consumers and
could increase consumer control over the uses of their data. Some of
these commenters identified certain high-risk uses to which consumers
should not be permitted to opt in. For example, consumer advocates and
trade associations stated that certain types of loans that have
resulted in enforcement actions, targeted marketing for predatory
products, uses of wealth indicators that result in discriminatory
algorithms, and behavioral insights derived from location, among
others, are high risk uses that should not be permitted under the final
rule, even through opt-in consent. And one trade association for data
providers also stated that financial institutions, when acting as third
parties, should be permitted to solicit opt-ins from consumers for some
secondary uses of covered data, because such institutions must adhere
to regulations to maintain sensitive data.
Other commenters, including third parties, data aggregators, trade
associations, and research institutes, offered support for an opt-out
option for consumers, citing examples from other privacy regimes that
rely on opt-out mechanisms. These commenters stated that third parties
should permit consumers to opt out of secondary uses that would be
allowed in certain contexts, like when compatible with the product or
service or through streamlined consent frameworks that benefit
consumers. A data aggregator provided an example of a third party
cross-selling a savings account to a consumer who already has a
checking account with the third party, and stated that consumers should
be able to opt out from these kinds of secondary uses.
In contrast, some commenters, including research institutes and
third parties, expressed caution about an opt-in or opt-out approach.
For example, a research institute stated that consumers presented with
granular choice options would experience choice overload and decision
paralysis and elect not to proceed with a transaction.\110\ A third
party stated that authorizations for any secondary uses should include
enhanced disclosure requirements and should prohibit other parties from
additional secondary uses, and suggested that these kinds of
protections are not compatible with opt-in methods. A research
institute stated that evidence shows opt-in consents result in
significantly reduced participation rates.\111\ Some commenters
recommended that the final rule address concerns about the secondary
use proposal being overly restrictive through additional clarifications
of reasonably necessary uses and exceptions for certain secondary uses.
Further, commenters stated that there might be significant limits to
the benefits of opt-in approaches. For example, as described in more
detail below, a group of academic researchers and consumer advocates
stated their concerns that employing opt-ins for
[[Page 90940]]
research might significantly degrade the quality of the data.
---------------------------------------------------------------------------
\110\ See generally Alexander Chernev et al., Choice Overload: A
Conceptual Review and Meta Analysis (2015); Choice Overload, https://www.researchgate.net/publication/265170803_Choice_Overload_A_Conceptual_Review_and_Meta-Analysis.
\111\ See generally Joseph W. Sakshaug et al., Evaluating Active
(Opt-In) and Passive (Opt-Out) Consent Bias in the Transfer of
Federal Contact Data to a Third-Party Survey Agency, 4 (3) J. Survey
Stats. & Methodology, at 382-416 (Sept. 2016), https://www.researchgate.net/publication/307625870_Evaluating_Active_Opt-In_and_Passive_Opt-Out_Consent_Bias_in_the_Transfer_of_Federal_Contact_Data_to_a_Third-Party_Survey_Agency; and Yvonne de Man, Ph.D. et al., Opt-In and
Opt-Out Consent Procedures for the Reuse of Routinely Recorded
Health Data in Scientific Research and Their Consequences for
Consent Rate and Consent Bias: Systematic Review, J. Med. Internet
Rsch. (Feb. 2023), https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10015347/ PMC10015347/.
---------------------------------------------------------------------------
Many commenters addressed the use of de-identified data by third
parties. Numerous commenters, including research organizations,
consumer advocates, and third parties, supported allowing third parties
to use de-identified data for secondary purposes. These commenters
stated that de-identified data enables a variety of uses that benefit
consumers. For example, commenters said that de-identified data allows
businesses to develop new products and services, improve existing
products and services, and improve account security and fraud
prevention. Commenters also said that de-identified data allows for
research that serves the public interest. For example, a third party
and a data aggregator commenter said that third parties had shared de-
identified data with government agencies to improve policymaking. A
research institute commenter stated that the CFPB's Consumer Credit
Panel and credit card agreement database use de-identified data.
However, a consumer advocate commenter stated that even de-identified
data could be exploited for commercial ends like marketing, and
therefore recommended limiting the use of de-identified data to
research purposes.
Some commenters addressed the consent standard that should apply to
uses of de-identified data. Academic, research institute, and consumer
advocate commenters stated that opt-in consent would impair the value
of any de-identified data used for research purposes. These commenters
stated that frequent opt-in requests could overwhelm consumers and that
consumers who opt in to sharing their data are non-representative of
the general population, which undermines the validity of any research
based on such consumers. However, a government commenter and a consumer
advocate commenter said that opt-out frameworks have been shown to
minimize sample biases and preserve the utility of data in other
research contexts. A data provider commenter said that opt-in consent
should be required for any use of de-identified data.
Some third party commenters were concerned about what they
described as anticompetitive effects of the proposed limitation on
using de-identified data. For example, a research institute and several
third party commenters said that new market entrants need access to de-
identified data to train machine learning models or otherwise ensure
that their products function properly. Third party commenters also said
that the proposed rule would limit their use of covered data in ways
that existing law does not limit data providers' use of the same data.
One third party commenter stated that it was not fair that a bank could
use de-identified data for nearly any purpose if obtained directly from
a customer, but a third party could not use the same data for any
secondary purposes if obtained under the rule as proposed.
Commenters also stated that allowing third parties to use de-
identified data would also create consistency between the final rule to
implement CFPA section 1033 and various State, Federal, and
international privacy regimes. One research institute commenter stated
that GLBA and FCRA allow greater flexibility in using de-identified
data. Several commenters believed that U.S. businesses would face a
competitive disadvantage if the final rule were more restrictive than
the E.U. General Data Protection Regulation (GDPR).
However, a few data providers and trade associations for data
providers opposed allowing third parties to use de-identified data for
secondary purposes. Two bank commenters asserted that de-identified
data could be re-identified, which would invade consumer privacy. In
contrast, a research institute commenter stated that most high-profile
examples of re-identification involved data that was never properly de-
identified initially. This commenter also said that risks of re-
identification were low if the data was limited to internal use and not
shared with other third parties.
Final Rule
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.421(c) with an additional example of reasonably necessary uses.
Final Sec. 1033.421(c) states that use of covered data for purposes of
Sec. 1033.421(a) includes both the third party's own use of covered
data and provision of covered data by that third party to other third
parties. Final Sec. 1033.421(c) further states that examples of uses
of covered data that are permitted under Sec. 1033.421(a) include:
uses that are specifically required under other provisions of law,
including to comply with a properly authorized subpoena or summons or
to respond to a judicial process or government regulatory authority;
uses that are reasonably necessary to protect against or prevent actual
or potential fraud, unauthorized transactions, claims, or other
liability; servicing or processing the product or service the consumer
requested; and uses that are reasonably necessary to improve the
product or service the consumer requested. The CFPB has determined
that, generally, consumers expect covered data might be used for these
purposes and that third parties will benefit from additional clarity,
provided by these examples, on uses that are reasonably necessary to
provide the consumer's requested product or service under the standard
in Sec. 1033.421(a). The examples in Sec. 1033.421(c) are
illustrative and are not comprehensive of uses of covered data that
will be reasonably necessary under the general limitation standard.
The CFPB is aware that third parties might need to use covered data
to comply with legal requirements or to protect against fraud,
unauthorized transactions, and similar purposes. The final rule is not
intended to restrict uses of covered data that effect compliance with
applicable laws, like anti-money laundering laws or other applicable
rules or regulations, or to block criminal law enforcement activity.
For example, in many cases, it would be reasonably necessary for third
parties to use basic account verification information to confirm that
the consumer is authorizing information from an account that does in
fact belong to that particular consumer. One third party commenter
explained that third parties might use covered data to determine the
likelihood of consumers' future payments failing by monitoring past
instances of consumers freezing their accounts or inability to transfer
funds, describing those uses of data as being for fraud prevention
purposes. The CFPB cautions that the example in Sec. 1033.421(c)(2) is
limited to uses to protect against or prevent actual or potential
fraud, unauthorized transactions, claims, or other liability if such
uses are reasonably necessary. The examples in Sec. 1033.421(c) do not
expand the scope the general limitation standard in Sec. 1033.421(a)
and, to be permissible, the uses described in the examples in Sec.
1033.421(c) must be reasonably necessary in a given context.
After considering comments, the CFPB is finalizing in Sec.
1033.421(c) an additional example of permitted uses of covered data:
uses that are reasonably necessary to allow for improvement of the
consumer's requested product or service. The CFPB agrees with
commenters that the reasonably necessary standard of Sec. 1033.421(a)
would generally permit third parties to use covered data to improve the
requested product or service. Generally, consumers expect that products
or services they have requested that rely on consumer-permissioned data
will be improved over time and, as such, the CFPB is finalizing this
additional
[[Page 90941]]
example in Sec. 1033.421(c)(4) to provide clarity, which will assist
third parties providing products and services that consumers request.
The CFPB considered commenters' suggestions to add other examples
of uses that are permissible under the general standard in Sec.
1033.421(a) but declines to do at this time. The CFPB believes the
examples in the final rule provide sufficient guidance to third parties
on uses that are permissible as reasonably necessary to provide the
consumer's requested product or service. The examples provided in the
final rule are non-exhaustive, and other uses are permissible as
reasonably necessary to provide the consumer's requested product or
service.
The CFPB considered comments suggesting additional prohibitions
related to certain uses, like uses of data for reverse engineering of
proprietary algorithms, price discovery in capital markets, or
behavioral monitoring and algorithm development. As stated in the
proposed rule, uses that are not reasonably necessary to provide the
consumer's requested product or service are secondary uses, and are not
permitted as part of the third party's authorization to access the
consumer's covered data for purposes of providing that product or
service. Many of commenters' suggested additions would generally be
considered secondary uses in as much as they would not be reasonably
necessary to provide the consumer's requested product or service.\112\
And other uses of covered data for the purposes of targeted
advertising, cross-selling of other products or services, and data
sales are sufficiently limited by the requirement in Sec.
1033.421(a)(2) that those purposes are not part of, or reasonably
necessary for, any other product or service and therefore must be
offered as a standalone product.
---------------------------------------------------------------------------
\112\ With respect to the comment suggesting the CFPB prohibit
uses of data for reverse engineering of proprietary algorithms, the
CFPB expects that such uses would not be reasonably necessary for a
consumer's requested product or service. The CFPB will closely
monitor the market to determine whether third parties are using
covered data for these purposes.
---------------------------------------------------------------------------
The CFPB considered additional flexibilities, like providing
consumers an opt-in to certain secondary uses or permitting secondary
uses through the use of de-identified data. The CFPB agrees with
commenters who described opt-in, or opt-out, approaches as not
sufficiently protective to consumers. The CFPB declines to allow third
parties, including financial institutions acting as third parties under
this rule, to solicit opt-in or opt-out consents from consumers to use
covered data obtained pursuant to consumer authorization for secondary
uses. The CFPB is concerned that consumers might not receive adequate
information through granular choice mechanisms that would result in
meaningful consent.\113\ The CFPB is also concerned that if offered too
many opt-in choices in the course of a single authorization process,
consumers might experience decision fatigue or choice paralysis, and
therefore might agree to terms they have not considered or instead
might not complete authorization.\114\ The CFPB also agrees with
commenters' concerns regarding opt-in or other granular choice options
for consumers, particularly related to de-identified data, as these
choices might result in selection bias issues that make the use of the
data consumers opted into sharing unhelpful for research purposes.
Additionally, the CFPB is concerned that when consumers experience
decision fatigue or choice paralysis, an opt-in or opt-out approach
might result in greater data sharing than they would choose if in a
position to make a considered choice. Generally, the authorization
procedures pursuant to Sec. 1033.401 are designed to ensure both that
consumers understand the scope of a requested product or service and
that third parties do not impermissibly expand the scope of their
collection, use, and retention beyond what is reasonably necessary to
provide that product or service. In addition, the rule does not prevent
third parties from offering consumers more than one product by means of
additional, separate authorizations that comply with subpart D. The
CFPB determines that separate authorizations pursuant to the procedures
in Sec. 1033.401 will afford consumers with more meaningful consent to
data access than consumers would have through traditional opt-in
requests, which the CFPB understands to combine requests for data
access for a product or service the consumer is seeking with requests
for consumer consent for data access for additional purposes. Such
combined requests might not allow consumers to make considered choices
to the same degree as separate authorizations, and therefore the
procedures in Sec. 1033.401 will provide consumers more control over
their data access authorizations.
---------------------------------------------------------------------------
\113\ See Neil Richards & Woodrow Hartzog, The Pathologies of
Digital Consent, 96 Wash. U.L. Rev. 1461, 1479-1486 (2019), https://openscholarship.wustl.edu/cgi/viewcontent.cgi?article=6460&context=law_lawreview (describing
numerous ways in which a consumer might consent to choice options
without understanding what they are authorizing); Woodrow Hartzog &
Neil Richards, Privacy's Constitutional Moment and the Limits of
Data Protection, 61 B.C. L. Rev. 1687, 1734 (2020) (stating that
even when the consumer is functioning under ideal circumstances when
giving consent, consumers' ability to give informed and meaningful
consent is finite and cannot scale to all the privacy choices a
consumer must make).
\114\ See Neil Richards & Woodrow Hartzog, The Pathologies of
Digital Consent, 96 Wash. U.L. Rev. 1461, 1484, 1486 (2019), https://openscholarship.wustl.edu/cgi/viewcontent.cgi?article=6460&context=law_lawreview (describing how a
consumer might experience decision fatigue if presented with detail
to provide sufficient information to make granular choices).
---------------------------------------------------------------------------
At this time, the CFPB is not including a provision that would
allow third parties to use de-identified data for purposes that are not
reasonably necessary to provide the consumer's requested product or
service. As discussed with regard to the general limitation standard in
final Sec. 1033.421(a), limiting third parties to using covered data
only as reasonably necessary for the provision of the product or
service that the consumer requested ensures that consumers understand
the scope of their authorization and retain control over their data.
The CFPB is concerned, based on the current rulemaking record, that an
exception to the secondary use prohibition for de-identified data would
be inconsistent with the kind of meaningful consumer control that the
final rule seeks to achieve, and might enable third parties to offer
products and services that are primarily designed to accumulate large
amounts of de-identified consumer data. Additionally, the CFPB notes
that, as with identifiable covered data, the final rule does not
prohibit third parties from using de-identified data as reasonably
necessary to provide the consumer's requested product or service, or
from seeking a separate authorization to use de-identified data for
other purposes that the consumer may choose. Indeed, to the extent that
covered data can be de-identified and still used to provide the product
or service, the CFPB expects that third parties may take that step
because it will provide a better means of safeguarding data.
Importantly, many of the beneficial purposes for which commenters
seek to use de-identified data typically would not be secondary uses
under the general limitation standard provided in Sec. 1033.421(a).
For example, Sec. 1033.421(c) includes as an example that covered
data--whether identifiable or de-identified--could be used as
reasonably necessary to prevent fraud, service or process the
consumer's requested product or service, and to improve the consumer's
requested product or service. These examples of uses that are
reasonably necessary to
[[Page 90942]]
provide the consumer's requested product or service pursuant to Sec.
1033.421(a) generally address the data uses described by commenters.
For example, with appropriate safeguards pursuant to their third party
obligations, third parties are generally permitted to use data,
including de-identified data, to train a fraud detection algorithm or
to improve the budgeting recommendation attribute of a personal
financial management service.\115\
---------------------------------------------------------------------------
\115\ Additionally, as described elsewhere, the general standard
to retain covered data as reasonably necessary would allow third
parties to retain covered data used for these purposes for as long
as reasonably necessary to locate the data and delete it. The CFPB
is aware that it could be practically infeasible for third parties
to delete data in certain circumstances, and as such, it would be
consistent with the general limitation standard for the third
parties to retain the data. In one such circumstance, for example,
it might be practically infeasible for a third party using covered
data in fraud prevention and product improvement models to extract
from those models data no longer connected to a consumer who
requests revocation.
---------------------------------------------------------------------------
The CFPB acknowledges commenters' representations regarding the
value of de-identified data for research purposes. Indeed, the CFPB
uses de-identified data itself for research and market monitoring. But
the use limitations in Sec. 1033.421(a) and (c) operate in a
particular context, where it is necessary to ensure that third parties
that represent that they are acting on a specific consumer's behalf are
actually doing so. Importantly, nothing prohibits a third party from
seeking the consumer's separate authorization to use de-identified data
for research purposes if that purpose is properly presented as an
authorization for data access for a standalone product or service.
Nonetheless, the CFPB recognizes that public interest research may
present unique considerations not developed in the current rulemaking
record. Accordingly, the CFPB will consider whether a follow-on
rulemaking would be appropriate to allow for public interest research
uses of de-identified data outside of the general standard finalized in
this rule.
The CFPB disagrees with commenters' assertions that the
restrictions on secondary use would harm competition and therefore
consumers by overly limiting potentially beneficial data uses. Under
the final rule, third parties can use covered data as reasonably
necessary to provide consumer-requested products and services,
including uses that are reasonably necessary to improve those products
and services. The CFPB expects that this will result in robust
competition with respect to consumer-requested products and services.
Further, the CFPB notes that the final rule does not restrict a third
party's ability to obtain or use data in other ways unrelated to the
final rule's data-access procedures, nor does the final rule prevent
third parties from obtaining authorization from consumers to use
covered data for additional products and services, including for
research purposes. In addition, to the extent it is reasonably
necessary to provide the consumer's requested product or service, third
parties may use covered data as one input to the generation of new data
that is not subject to the requirements of subpart D, including the
limitations on secondary use (although other State and Federal laws may
impose applicable restrictions).
For these same reasons, the CFPB also disagrees with comments
suggesting that the rule, including not adopting the GLBA's privacy
standard, creates an illogical or unfair distinction between data
providers and third parties. Both data providers and third parties may
use data that result from direct consumer relationships without
adhering to the general limitation standard in Sec. 1033.421(a), such
as by using it as permitted under the GLBA and Regulation P, to the
extent applicable. The final rule also does not treat covered data
providers differently than other third parties when they act as
authorized third parties themselves--while they may use the data they
generate in the course of providing their products or services in any
manner allowable by law, they are still subject to the prohibition on
secondary uses when accessing data from other data providers pursuant
to the rule's procedures. The CFPB considers the final rule's approach
to the use of generated data to be straightforward, but to the extent
parties seek any additional guidance, the CFPB may publish responsive
guidance as appropriate.
Accuracy (Sec. 1033.421(d))
Proposed Sec. 1033.421(d) would have required third parties to
establish and maintain written policies and procedures that are
reasonably designed to ensure that covered data are accurately received
from a data provider and accurately provided to another third party, if
applicable. Under the proposed rule, a third party would have
flexibility to determine its policies and procedures in light of the
size, nature, and complexity of its activities, but the third party
would be required to periodically review its policies and procedures
and update them as appropriate to ensure their continued effectiveness.
The proposed rule provided two examples of elements in Sec.
1033.421(d)(3) that third parties would have been required to consider
when developing their policies and procedures regarding accuracy: (1)
accepting covered data in the format required by the standards for
developer interfaces in Sec. 1033.311(b) and (2) addressing
information provided by a consumer, data provider, or another third
party regarding inaccuracies in the covered data. Finally, the proposed
rule stated that indicia that a third party's policies and procedures
are reasonable would include whether the policies and procedures
conform to a qualified industry standard regarding accuracy.
The CFPB explained that proposed Sec. 1033.421(d) would limit the
scope of a third party's required policies and procedures to the
accuracy of transmission--that is, receiving covered data from a data
provider and, if applicable, subsequently providing it to another third
party. The CFPB provided several reasons for limiting this scope.
First, existing Federal law already protects consumers against some of
the most harmful inaccuracies in the use of financial data.\116\
Second, the CFPB noted that most SBREFA comments addressing accuracy
focused on transmission of data from data providers to third parties as
the source of accuracy issues. In adopting a similar focus, proposed
Sec. 1033.421(d) reflected this feedback. Finally, the CFPB explained
many third parties are small entities, and accuracy requirements
covering all aspects of the collection, use, and provision of consumer
data might be overly burdensome.
---------------------------------------------------------------------------
\116\ For example, Regulation E protects consumers against
unauthorized electronic fund transfers and other errors, and
Regulation Z protects consumers against certain billing and
servicing errors. See 12 CFR part 1005; 12 CFR part 1026.
---------------------------------------------------------------------------
The CFPB sought comment on whether any additional elements bearing
on the reasonableness of a third party's policies and procedures
regarding accuracy should be included.
One Member of Congress expressed support for the proposed accuracy
requirements. This commenter stated that inaccuracies would limit the
ability of covered data to serve consumers and the financial system. On
the other hand, some commenters opposed the inclusion of certain
requirements. Some commenters believed that industry standards would be
poorly suited to accuracy requirements. For example, a bank trade
association stated that standardizing accuracy across the diverse
universe of third parties may not be possible, given the broad array of
interests.
Additionally, while not opposing the proposed requirement, a number
of data provider and data provider trade association commenters
recommended
[[Page 90943]]
that the final rule do more to account for the fact that most third
parties will receive data from data aggregators using proprietary
formats rather than directly from data providers. Specifically, a few
commenters recommended that the CFPB either prescribe a standardized
format or remove the provision requiring third parties to consider
accepting data in the format required for data providers' developer
interfaces. One research organization commented that the CFPB might
want to more clearly distinguish the obligations of third party data
recipients and third party data aggregators.
Further, some third party commenters and one consumer advocate
group commenter recommended the final rule contain a more robust
dispute process. In particular, the consumer advocate group recommended
a dispute process similar to that provided under the FCRA, wherein the
consumer can dispute inaccuracies and require that a reasonable
investigation is conducted.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.421(d) as proposed, with one clarifying change to conform to the
final rule's use of the term ``consensus standard.''
Accurate transmission of covered data is important for the
effective functioning of the market for consumer-authorized data
sharing. Inaccuracies in covered data impair third parties' ability to
use that data for innovative purposes, undermining the benefits of data
sharing for consumers. Accuracy standards also help ensure that
authorized third parties are acting on behalf of consumers. Third
parties that fail to take reasonable steps to ensure accuracy when
receiving or transmitting covered data would not be acting in the
interests of the consumers to whom the data relates. The specific
arrangement that a third party makes to receive covered data affects
the reasonableness of its policies and procedures regarding accuracy.
For example, the CFPB understands that third parties frequently use
data aggregators to obtain access to consumers' covered data. Such
third parties should account for the involvement of a data aggregator
by ensuring that their policies and procedures include measures to
reduce inaccuracies that might be introduced by using an intermediary.
Standard-setting bodies can facilitate a comprehensive set of
policies and procedures for accuracy that may be used by third parties
throughout the consumer-authorized data sharing market. In particular,
standard-setting bodies are likely to develop standards that are
relevant to reasonable policies and procedures for accuracy--such as
standardized data formats--that will increase the interoperability of
the final rule. Further, recognized standard setters will need to
consider input from both data providers and third parties, and as part
of the balance attribute of Sec. 1033.141(a), will specifically need
to consider the input of small entity data providers. Accordingly, a
recognized standard setter can--contrary to the suggestion of one
commenter--issue consensus standards flexible enough to accommodate the
wide array of third party data recipients.
Regarding comments concerning transmission of standardized formats,
accepting data in the format in which it is transferred is relevant to
ensuring accuracy. Section 1033.421(d)(3) does not preclude third
parties from accepting covered data from a data aggregator in a
standardized format. The flexibility provided by the policies and
procedures allows the third party to accept covered data in a way that
is best for the size and nature of the third party.
Additionally, CFPA section 1033(d) requires the CFPB to prescribe
standards applicable to covered persons to promote the development and
use of standardized formats for information. As discussed in more
detail under Sec. 1001.2(b) below, CFPA section 1002(15)(A)(vii)
defines as a financial product or service ``providing payments and
other financial data processing to a consumer by any technological
means'' and data aggregators are therefore covered persons under the
CFPA.\117\ The CFPB intends to monitor the market to evaluate whether
data aggregators and authorized third parties are using standardized
and machine-readable formats for covered data.
---------------------------------------------------------------------------
\117\ CFPA section 1002(4) defines ``consumer'' to include ``an
agent, trustee, or representative acting on behalf of'' a consumer.
Therefore, when a data aggregator provides financial data processing
to an authorized third party, the aggregator is also necessarily
providing financial data processing to a consumer.
---------------------------------------------------------------------------
Regarding comments for a more robust dispute process, the CFPB has
determined that forgoing overly prescriptive dispute requirements can
facilitate consistency with robust accuracy requirements.\118\ As the
CFPB has noted, third parties are likely to be highly diverse in size
and sophistication. The dispute requirement attempts to ensure that the
burden of considering disputes is appropriate to the role that a third
party played in the ecosystem. All third parties will need to consider
``addressing information provided by a consumer, data provider, or
another third party regarding inaccuracies in the covered data,'' but
what is ``reasonable'' will depend on the size and sophistication of
the third party. For example, data aggregators will likely have more
extensive dispute processes than third parties that merely receive
data. Further, the overall flexible nature of the policies and
procedures accuracy requirement will allow third parties leverage
existing systems for addressing disputes to the extent that such
disputes also relate to the transfer of covered data.
---------------------------------------------------------------------------
\118\ As discussed above in part IV.4, certain entities, such as
data aggregators, may have dispute resolution obligations under
other statutes, such as the FCRA. The analysis for this provision is
limited to obligations arising under part 1033 and does not supplant
other accuracy dispute requirements.
---------------------------------------------------------------------------
The CFPB has determined that consumers will benefit from accuracy
requirements for third parties. Third parties that fail to accurately
receive data from a data provider, or fail to accurately provide data
to another third party (when that is appropriate under the general
limitation on data use), limit the effectiveness of the data access
right fundamental to CFPA section 1033. Such inaccuracies also impair
the development of an innovative, competitive market for alternative
consumer financial products and services. Third party accuracy
requirements also benefit third parties that rely on intermediaries to
facilitate consumer-authorized access.
Data Security (Sec. 1033.421(e))
Proposed Sec. 1033.421(e)(1) would have required a third party to
certify that it will apply to its systems for the collection, use, and
retention of covered data an information security program that
satisfies the applicable rules issued pursuant to section 501 of the
GLBA (15 U.S.C. 6801). Under proposed Sec. 1033.421(e)(2), if the
third party is not subject to section 501 of the GLBA, the third party
will apply to its systems for the collection, use, and retention of
covered data the information security program required by the FTC's
Standards for Safeguarding Customer Information, 16 CFR part 314. The
CFPB preliminarily determined that the GLBA Safeguards Framework could
be used by third parties to appropriately protect consumer-authorized
financial data.
A range of commenters supported the use of the GLBA Safeguards
Framework for third party data security. One bank commenter stated that
the GLBA Safeguards Framework would ensure consistent data security
standards for all ecosystem participants. Additionally, one consumer
advocate group commenter said the proposed rule would close gaps in
data security coverage. Another bank commenter stated that third
parties should, at a
[[Page 90944]]
minimum, follow the GLBA Safeguards Framework.
On the other hand, one third party commenter argued that the
Safeguards Framework should not be applied to third parties, because
compliance would be overly burdensome for third parties. Additionally,
some commenters believed the final rule should add more specificity to
the Safeguards requirements, for example, by creating a presumption of
compliance for previously utilized standards, or consensus standards.
A number of bank commenters argued that the final rule should apply
the same GLBA Safeguards Framework guidelines used by the Federal
functional regulators \119\ to supervise financial institutions. In
particular, some data providers and trade associations for data
providers stated that the FTC Safeguards rule was less prescriptive and
not supported by regular supervision. Similarly, a few commenters
requested that the final rule address liability by subjecting third
parties to additional data security obligations, such as the FFIEC
Information Technology Examination Handbook because, they said, it was
more detailed than the FTC Safeguards Rule.
---------------------------------------------------------------------------
\119\ The term ``functional regulators'' is the term that the
GLBA uses to identify applicable agencies.
---------------------------------------------------------------------------
Additionally, one third party merchant commenter and one third
party commenter argued that the final rule should not require third
parties that are merchants to certify to follow the GLBA framework when
they use consumer-permissioned data to facilitate payments for services
provided by the merchant. These commenters' concern was threefold.
First, the commenters argued that the proposed rule was inconsistent
with the CFPA's limits on the CFPB's authority with respect to
merchants. Second, the commenters stated that merchants are already
subject to data security requirements under the National Automated
Clearing House Association (NACHA) and the payment card industry data
security standards (PCI DSS), and, given these previous compliance
obligations, adding the safeguards condition would be overly burdensome
for the merchant third party. Finally, the commenters stated that,
under the proposed rule, merchants could be incentivized to avoid GLBA
Safeguards Rule standards by asking the consumer to go around the open
banking transaction, for example, by requiring the consumer to type in
their ACH account and routing number, or by asking the consumer for a
payment card rather than using an open finance application.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.421(e) as proposed. Final Sec. 1033.421(e)(1) requires a third
party to apply to its systems for the collection, use, and retention of
covered data an information security program that satisfies the
applicable rules issued pursuant to section 501 of the Gramm-Leach-
Bliley Act (15 U.S.C. 6801). Under Sec. 1033.421(e)(2), if the third
party is not subject to section 501 of the Gramm-Leach-Bliley Act, the
third party will apply to its systems for the collection, use, and
retention of covered data the information security program required by
the Federal Trade Commission's Standards for Safeguarding Customer
Information, 16 CFR part 314.
Requiring third parties to certify that they will comply with the
GLBA Safeguards Framework will appropriately protect covered data. The
rule's requirement for third parties to certify that they will follow
the GLBA Safeguards Framework ensures consistency in protection as
covered data moves from a data provider to one or more third parties
because all or substantially all data providers are already subject to
the GLBA Safeguards Framework,\120\ most likely the Interagency
Guidelines Establishing Information Security Standards issued by the
Federal functional regulators.
---------------------------------------------------------------------------
\120\ Section 501 of the GLBA (15 U.S.C. 6801) applies to
financial institutions, which are defined as companies that offer
consumers financial products or services like loans, financial or
investment advice, or insurance.
---------------------------------------------------------------------------
The CFPB declines to include greater specificity in the data
security certification for third parties, as requested by some
commenters. Regarding comments requesting incorporation of industry
standards into third party data security provisions, the CFPB notes
that changing the security framework beyond the proposed approach would
create a new, CFPA section 1033-specific data security standard, which
could add complexity for third parties. The CFPB has determined that by
not incorporating industry standards or overly prescriptive standards
relating specifically to data security, the rule better facilitates
compliance with CFPA section 1033.
Regarding comments on the inadequacy of the FTC Safeguards Rule
compared to the Safeguards Guidelines, for reasons stated in the
proposed rule, the CFPB has determined the FTC Safeguards Rule provides
adequate protection. The commenters failed to engage with the proposed
rule's explanation that the FTC's Safeguards Rule includes slightly
more prescriptive requirements, such as encryption, for certain
elements, because the Safeguards Rule must be usable by a financial
institution to determine appropriate data security measures without
regular interaction with an examiner from a supervising agency.
Additionally, concerning third party liability, the CFPB finds that the
final rule's data security requirements will help protect against data
breaches and any ensuing losses that third parties or data providers
might suffer.
The CFPB has determined merchant third parties that are authorized
third parties under the rule should be required to certify to comply
with the same data security obligations as other third parties.
Although merchant commenters expressed concern that merchants are
already subject to data security requirements through NACHA and PCI
rules, the CFPB has determined the relative similarities between these
rules and the FTC Safeguards Rule suggests that the burden imposed on
the merchants by the final rule would be minor. The FTC Safeguards Rule
requires financial institutions to design an information security
program that addresses several elements, including designating a
qualified individual, performing a risk assessment, implementing
controls such as encryption and multi-factor authentication, and
testing or monitoring the effectiveness of the program's controls.
Similarly, NACHA and PCI rules requires covered financial institutions
to develop, implement, and maintain an information security program
with administrative, technical, and physical safeguards designed to
protect customer information.
Further, contrary to one merchant commenter's concern with what it
felt was a one-size-fits-all approach in the proposed rule, the
flexibility of the Safeguards Rule would allow for some discretion in
how the merchant third parties structure their data security systems.
Additionally, treating NACHA or PCI standards as sufficient for
purposes of a third party's data security certification would allow a
private entity to determine the substance of the final rule's data
security standards. This approach creates a risk that future NACHA or
PCI standards might diverge from the CFPB's views about the proper data
security obligations for authorized third parties.
Regarding comments stating that the CFPB does not have the
authority over merchant third parties to require those third parties to
certify to comply with the FTC Safeguards rule, the CFPB notes
[[Page 90945]]
that the certification requirement in Sec. 1033.421(e), for merchants
and all third parties, is a condition to access covered data and not a
freestanding requirement.
Provision of Covered Data to Other Third Parties (Sec. 1033.421(f))
The CFPB proposed in Sec. 1033.421(f) to require a third party to
certify that, before providing covered data to another third party, it
will require that other third party by contract to comply with certain
obligations. The proposed rule noted that, in some circumstances, third
parties that are authorized to access covered data from a data provider
on behalf of a consumer would need to share that data with another
third party. The authorized third party's ability to share covered data
would be limited by the conditions in proposed Sec. 1033.421(a) and
(c), under which the authorized third party would limit its use of
covered data, including sharing data with other third parties, to what
is reasonably necessary to provide the consumer's requested product or
service. Subject to that limitation, the authorized third party would
be permitted to provide the data to another third party.
The CFPB proposed that the consumer protections provided by the
third party obligations in proposed Sec. 1033.421 generally would
apply when the covered data are provided by the authorized third party
to another third party. The CFPB noted that, otherwise, the third party
that receives the data from the authorized third party would not be
subject to, for example, the limitations on use or the requirements for
data privacy and data security that apply to the authorized third
party, and the consumer would lose these important protections for the
covered data, which ensure that data are used on their behalf.
Accordingly, the CFPB proposed in Sec. 1033.421(f) that, before
providing the covered data to another third party, the authorized third
party would certify that it will require the other third party by
contract to comply with the third party obligations in proposed Sec.
1033.421(a) through (g) and the condition in proposed Sec.
1033.421(h)(3), upon receipt of the notice described in proposed Sec.
1033.421(h)(2). Proposed Sec. 1033.421(f) stated that any provision of
covered data to another third party would be subject to the restriction
in proposed Sec. 1033.421(c), which specifies that provision of data
to other third parties is a type of use of covered data that would be
limited by proposed Sec. 1033.421(a) to what is reasonably necessary
to provide the consumer's requested product or service requested.
Proposed Sec. 1033.421(f) did not require the authorized third party
to certify that it will bind the other third party by contract to
comply with all of the third party obligations in proposed Sec.
1033.421. The CFPB preliminarily determined that certain of the third
party obligations would be of limited applicability to the other third
party, including the obligation to provide certain information to the
consumer in proposed Sec. 1033.421(g) and the revocation obligation in
proposed Sec. 1033.421(h). The CFPB requested comment on whether the
approach in proposed Sec. 1033.421(f) would provide sufficient
protection to consumers and their covered data when an authorized third
party provides that data to another third party. The CFPB also
requested comment on which third party obligations in proposed Sec.
1033.421 should be included in this approach.
A number of commenters addressed the proposed approach in Sec.
1033.421(f). A bank trade association commenter and a trade association
representing nonbank entities both supported the proposed rule's
approach to applying third party obligations when third parties provide
covered data to downstream parties. Other commenters, including a bank
trade association, a bank, and a consumer advocate, maintained that the
proposed approach in Sec. 1033.421(f) would not provide sufficient
protections for consumers' covered data when an authorized third party
provided that data to downstream parties. The bank and bank trade
association commenters and the bank commenter stated that the proposed
approach of requiring the authorized third party to certify that it
will include contractual provisions obligating downstream parties to
comply with certain obligations in proposed Sec. 1033.421 would be
insufficient and that the rule should impose those obligations directly
on downstream parties. The trade association commenter recommended
that, at a minimum, the rule should provide that, in addition to
including contractual provisions requiring a downstream party to comply
with the obligations, the authorized party must also ensure that the
downstream parties comply with the obligations. The bank trade
association commenter and a bank commenter also recommended that the
rule should require the authorized third party to disclose to the
consumer and the data provider which other third parties will be
provided with the covered data. The bank trade association commenter
stated that disclosing this information would provide consumers with
transparency and control over their data and would allow data providers
to conduct risk assessments of downstream parties.
Some commenters, including a bank, a bank trade association, and a
consumer advocate, recommended that the rule clarify when an authorized
third party may share covered data with a downstream party. They noted
that an authorized third party would be permitted to access covered
data only for the purpose of providing the consumer's requested product
or service, so they stated that it is not clear when it would be
permissible for the authorized third party to share the covered data
with additional third parties. A research institute commenter stated
that proposed Sec. 1033.421(f) would not appear to be flexible enough
to permit sharing with a downstream third party when the authorized
third party accesses the covered data for certain products that involve
the sharing of covered data. For example, the research institute
commenter stated that it was not clear if the proposed approach would
permit an authorized third party to access covered data to identify
rent, cell phone, and utility payments and share that information by
reporting those payments to CRAs to help build the consumer's credit.
For the reasons discussed herein, the CFPB is adopting Sec.
1033.421(f) as proposed with two minor changes. As finalized, Sec.
1033.421(f) provides that, before providing covered data to another
third party, subject to the limitation described in Sec. 1033.421(a)
and (c), the third party must certify that it will require the other
third party by contract to comply with the third party obligations in
Sec. 1033.421(a) through (f) and the condition in Sec. 1033.421(i)
upon receipt of the notice described Sec. 1033.421(h)(2).
Under the proposed rule, third parties also would have been
required to certify that they would require downstream parties to
comply with the provisions in Sec. 1033.421(g) (related to keeping
consumers informed). However, the provisions in Sec. 1033.421(g) would
be of limited relevance for downstream parties and the CFPB concludes
that an authorized third party therefore should not be required to
certify that it will include them in contracts with downstream parties
with which it will share covered data. Section 1033.421(g)(1) requires
a third party to provide the consumer with a copy of the authorization
disclosure. The downstream third party would be receiving the covered
data for the purpose of providing the product or
[[Page 90946]]
service requested by the consumer from the authorized third party, and
the authorized third party, not the downstream party would have
provided the authorization disclosure to the consumer. Section
1033.421(g)(2) also requires a third party to provide contact
information that enables a consumer to receive answers to questions
about the third party's access to the consumer's covered data. The
authorized third party, not a downstream party, is more likely to have
a relationship with the consumer and the consumer is more likely to
attempt to contact the authorized third party with questions about
access to the consumer's covered data. Section 1033.421(g)(3) requires
the third party to establish and maintain reasonable policies and
procedures to ensure that the third party, upon request, provides
certain information to the consumer. Again, the consumer is more likely
to contact the authorized third party to obtain information and the
information listed in Sec. 1033.421(g)(3) is primarily information
possessed by the authorized third party. Accordingly, the final rule
does not require an authorized third party to include the obligations
in Sec. 1033.421(g) in contractual provisions with downstream parties.
In addition, the final rule changes the reference from Sec.
1033.421(h)(3) to Sec. 1033.421(i) because, as described below, the
final rule includes a new Sec. 1033.421(i) that includes provisions
from proposed Sec. 1033.421(b)(4) and (h)(3).
The CFPB has determined that requiring a third party to certify
that it will include contract provisions requiring downstream parties
to abide by the specified obligations will provide sufficient
protections, including protections that impose limitations on use and
requirements for data security. As discussed above in connection with
the authorization procedures in Sec. 1033.401, requiring a third party
to certify that it will include contractual provisions requiring
downstream parties to abide by the specified obligations will provide
sufficient protection. If a downstream party breaches the obligation,
the CFPB could enforce those obligations using its authority to prevent
unfair, deceptive, or abusive acts or practices, and other regulators,
the consumer, and the data provider also may be able to enforce those
provisions.
The CFPB has concluded that further clarification of when an
authorized third party may share covered data with downstream parties
is not necessary. Section 1033.421(f) specifically references the
limitations in Sec. 1033.421(a) and (c), so the authorized third party
is able to share data with other third parties only as reasonably
necessary to provide the product or service requested by the consumer
from the authorized third party. Accordingly, downstream parties will
be able to use the data only to assist the authorized third party with
providing the requested product or service and not for their own
purposes. The CFPB also has determined that the approach in Sec.
1033.421(f) is sufficiently flexible to accommodate products like those
suggested by the research institute commenter for which sharing of data
is part of the product. Sharing the data in those circumstances would
be reasonably necessary to provide the product requested by the
consumer.
The CFPB declines to require that the authorized third party
certify that it will disclose the identity of any third parties with
which it will share the consumer's covered data. With respect to data
aggregators, Sec. 1033.431(b) requires the authorization disclosure to
include the name of any data aggregator that will assist the third
party seeking authorization with accessing covered data and a brief
description of the services the data provider will provide. However, at
the time of the authorization, the third party seeking authorization
may not know if it will be sharing covered data with other third
parties and, if it will, the identity of those third parties. Moreover,
the limitations in Sec. 1033.421(a) and (c) restrict the circumstances
in which an authorized third party is permitted to share covered data
with other third parties. Finally, a consumer that wants to obtain
additional information from the authorized third party about such data
sharing may do so, as provided in Sec. 1033.421(g). Accordingly, the
CFPB has determined that it is not necessary to provide information
during authorization about sharing covered data with downstream
parties.
As noted above, a bank trade association recommended that Sec.
1033.421(f) require the authorized third party to certify that it also
will ensure that any downstream parties that they provide with covered
data are abiding by their contractual obligations. The CFPB expects
that, in addition to certifying that they will include contract
provisions obligating downstream parties with which they share data to
comply with certain obligations, authorized third parties will take
reasonable steps to ensure that those downstream parties are complying
with those obligations. Authorized third parties are permitted to share
covered data with downstream parties only as reasonably necessary to
provide the consumer's requested product or service. The CFPB expects
that authorized third parties will, in the interest of maintaining
relationships with consumers and avoiding potential liability for
violating their own certifications to consumers, including the
certification that covered data will only be collected, used, and
retained as reasonably necessary to provide the consumer's requested
product or service, perform due diligence in determining which
downstream parties they select to assist in providing the consumer's
requested product or service and take reasonable steps to monitor those
downstream parties.
Ensuring Consumers Are Informed (Sec. 1033.421(g))
The CFPB proposed in Sec. 1033.421(g) to require a third party to
certify that it agrees to certain obligations designed to ensure that
consumers can obtain information about the third party's access to
their data.
Under proposed Sec. 1033.421(g)(1), a third party would have been
required to certify that it would provide the consumer with a copy of
the authorization disclosure that is signed or otherwise agreed to by
the consumer and reflects the date of the consumer's signature or other
written or electronic consent. Upon obtaining authorization to access
covered data on the consumer's behalf, the third party would deliver a
copy to the consumer or make it available in a location that is readily
accessible to the consumer, such as the third party's interface. The
proposed rule specified that, if the third party made the authorization
disclosure available in such a location, the third party also would
have been required to certify that it would ensure it is accessible to
the consumer until the third party's access to the consumer's covered
data terminates. The CFPB sought comment on whether this is the right
time period. The CFPB proposed Sec. 1033.421(g)(1) because it
preliminarily determined that consumers would benefit from being able
to access authorization disclosures they have previously signed. For
example, the consumer may not recall which third parties are accessing
their data, what data are being accessed, and for what reasons. Without
this information, it would be difficult for a consumer to decide
whether to continue authorizing data access.
Under proposed Sec. 1033.421(g)(2), a third party would have been
required to certify that it would provide readily identifiable contact
information that enables a consumer to receive answers to questions
about the third party's
[[Page 90947]]
access to the consumer's covered data. The proposal stated that a third
party could satisfy proposed Sec. 1033.421(g)(2) through its existing
customer service functions, provided that this function is equipped to
handle the relevant questions. The CFPB proposed Sec. 1033.421(g)(2)
because it preliminarily determined that the consumer should be able to
contact the third party to receive answers to questions about the third
party's access to the consumer's covered data. The proposed rule stated
that the authorization disclosure would contain a limited amount of
information pursuant to proposed Sec. 1033.411(b), so it may not
address every question the consumer has about the third party's data
access. The CFPB sought comment on additional requirements regarding
the nature of the contact that the consumer can access through the
contact information provided by the third party, such as whether the
consumer must be able to access a human contact or whether the consumer
must receive a response within a specified timeframe.
Under proposed Sec. 1033.421(g)(3), third parties would have been
required to certify that they would establish and maintain reasonable
written policies and procedures designed to ensure that the third party
provides to the consumer, upon request, the following information about
the third party's access to the consumer's covered data: (1) categories
of covered data collected; (2) reasons for collecting the covered data;
(3) names of parties with which the covered data was shared; (4)
reasons for sharing the covered data; (5) status of the third party's
authorization; and (6) how the consumer can revoke the third party's
authorization to access the consumer's covered data and verification
the third party has adhered to requests for revocation. Proposed Sec.
1033.421(g)(3) stated that the third party had flexibility to determine
its policies and procedures in light of the size, nature, and
complexity of its activities, and the third party would periodically
review its policies and procedures and update them as appropriate to
ensure their continued effectiveness. The CFPB proposed Sec.
1033.421(g)(3) because it preliminarily determined that, at any time
during the third party's access to the consumer's data, the consumer
should be able to obtain this information from the third party. The
CFPB proposed to require a third party to certify that it would provide
the names of parties with whom the covered data are shared because the
CFPB preliminarily determined that this information would be valuable
for consumers to know to protect their privacy, exercise control over
which parties are accessing their covered data, and evaluate whether to
continue sharing data with the third party. The CFPB proposed to
require a third party to certify that it would provide information
about the status of the third party's authorization because it may not
be apparent to the consumer whether the third party's authorization is
still active or whether the third party is currently collecting data.
With respect to the information about the categories of covered
data the third party is collecting, the reasons for collecting the
covered data, and information about how the consumer can revoke the
third party's access to the consumer's data, the proposed rule stated
that some consumers may want to obtain this information by contacting
the third party. The CFPB preliminarily determined that it would be
appropriate to require the third party to certify that it would provide
this information on request given that the third party originally
provided this information on the authorization disclosure. The CFPB
sought comment on whether the list in proposed Sec. 1033.421(g)(3)
should be modified, including whether additional categories of
information should be added.
The CFPB received a few comments on proposed Sec. 1033.421(g). A
bank trade association commenter, a Member of Congress, and a consumer
advocate commenter supported the proposed rule's general approach to
requiring third parties to keep consumers informed because it would
allow consumers to make decisions with respect to their sensitive
financial data.
The bank trade association commenter requested that the method for
accessing this information be easy and intuitive and that information
on the duration of data sharing be made available to consumers. The
Congressmember's comment supported information about data security
being made available to consumers.
A different bank trade association commenter requested that any
separate data aggregator certification be available to the consumer
upon request from either the third party or the data aggregator. A
consumer advocate commenter requested more formal requirements for
transparency into downstream data flows, detailing each onward transfer
as well as the purposes of the transfer to allow consumers visibility
and control on how financial information would get subsequently
utilized. Another consumer advocate commenter and an individual
commenter asserted that third parties should be required to provide
information on how the third party makes decisions using data,
including what data are used. A data provider commenter requested that
the data provider name be made available on a platform such as a
consumer revocation dashboard rather than on the authorization
disclosure.
For the reasons described herein, the CFPB is finalizing Sec.
1033.421(g) with modifications. First, the CFPB is finalizing in Sec.
1033.421(g)(3)(vii) an additional requirement that the third party
certify to maintain policies and procedures to provide to consumers,
upon request, a copy of any data aggregator certification statement
that was provided to the consumer separate from the authorization
disclosure, pursuant to Sec. 1033.431(c)(2). The CFPB is finalizing
Sec. 1033.421(g)(3)(vii) to ensure that consumers have access to the
same information regardless of whether a data aggregator certification
was included in the authorization disclosure or in a separate data
aggregator certification. Second, the CFPB is modifying the language of
proposed Sec. 1033.421(g)(3)(iii) to specify that names of any parties
with which covered data was shared must be made available in a form
that is readily understandable to consumers for consistency with the
authorization disclosure. Third, the CFPB is modifying the language of
proposed Sec. 1033.421(g)(3)(iii) to better align with the
requirements in Sec. Sec. 1033.401(c) and 1033.411(a). Final Sec.
1033.401(c) does not include language stating that a third party can
obtain a consumer's express informed consent by having the consumer
``otherwise agree'' to the authorization disclosure. Finally, the final
rule makes non-substantive changes to the language of proposed Sec.
1033.421(g)(3).
The CFPB is not modifying its approach regarding downstream data
flows or notification of sharing with downstream parties because the
proposed rule required third parties to provide the ``names of parties
with which the covered data was shared.'' The CFPB is not adding a
requirement to provide information about how the third party uses data
to make decisions because doing so would be outside the intended scope
of a provision regarding providing information about data access.
Additionally, such information may be, in whole or in part, proprietary
information. The CFPB is not modifying Sec. 1033.421(c) to include the
data provider's name or information about duration of data access
because the consumer will have this information in the authorization
disclosure. Finally,
[[Page 90948]]
the CFPB is not adding a requirement to include information about data
security because this information may be highly technical and is
unlikely to be useful to consumers.
Revocation of Authorization (Sec. 1033.421(h))
Proposed Sec. 1033.421(h) included three components related to the
third party's certification to provide the consumer with a mechanism to
revoke the third party's authorization to access the consumer's covered
data. These components are discussed below.
Provision of Revocation Method (Sec. 1033.421(h)(1))
Under proposed Sec. 1033.421(h)(1), the third party would certify
to provide the consumer with a mechanism to revoke the third party's
authorization to access the consumer's covered data that is as easy to
access and operate as the initial authorization. Proposed Sec.
1033.421(h)(1) also stated that the third party would also ensure the
consumer is not subject to costs or penalties for revoking the third
party's authorization.
The proposed rule stated that the CFPB preliminarily determined
that for the consumer's authorization for third party data access to be
meaningful, consumers need to be able revoke that authorization at any
time. The proposed rule also stated that a mechanism being as easy as
the initial authorization would ensure third parties would not bury the
revocation mechanism or otherwise obfuscate consumers' ability to
utilize it. Additionally, the proposed rule stated that, for revocation
of authorization to be free of cost or penalties to the consumer,
consumers should be able to revoke their authorization to data access
for purposes of one product or service but maintain that same third
party's data access for purposes of another product or service.
Therefore, as part of proposed Sec. 1033.421(h)(1), third parties
would certify to allow consumers to revoke consent to data access for a
particular product or service and maintain consent to data access for
any others.
Comments about this aspect of the proposed rule from a Member of
Congress, consumer advocates, research organizations, trade
associations for credit unions and banks, third parties, data
aggregators, and individuals were generally supportive of the proposed
approach to requiring third parties to provide consumers with a method
to revoke third party authorizations to access covered data.
Commenters' suggested amendments, clarifications, or additions to the
proposed rule included: consumers' ability to revoke should be
nonwaivable and the mechanism should be provided ``without friction or
delay;'' the mechanism should allow revocations at the granular level,
including allowing consumers to expressly select the account for which
authorization is revoked; the mechanism should allow the consumer to
revoke authorization for any entity involved with the data sharing
transaction; the final rule should specify a time limit by which third
parties must notify other parties of the revocation request; and data
aggregators should be required to provide consumers with a revocation
request.
After considering comments, and for the reasons discussed herein,
the CFPB is finalizing proposed Sec. 1033.421(h)(1) without
substantive change. The CFPB is making a non-substantive modification
to change ``mechanism to revoke'' to ``method to revoke'' for
consistency with the provision that allows data providers to provide a
revocation method to consumers. As described above, some commenters
suggested the CFPB should state that revocation is nonwaivable and
should be provided without friction or delay, or should allow for more
granular choices. The CFPB declines to make these changes because Sec.
1033.421(h)(1) sufficiently ensures consumers may revoke third party
authorizations at any point. Further, the CFPB has determined that
third parties are in the best position to understand the covered data
they need to collect to facilitate provision of a consumer's requested
product or service. Offering consumers granular revocations might
confuse consumers or frustrate the third parties' ability to provide
that product or service.
The CFPB affirms that, for revocation of authorization to be free
of cost or penalties to the consumer, consumers should be able to
revoke their authorization to data access for purposes of one product
or service but maintain that same third party's data access for
purposes of another product or service they are receiving from the
third party. In other words, third parties conditioning the provision
of one product or service on the consumer providing consent to data
access for another product or service is a cost or penalty on the
consumer. Therefore, as part of Sec. 1033.421(h)(1), third parties
must certify that they will allow consumers to revoke consent to data
access for a particular product or service and maintain consent to data
access for any others.
For the consumer's authorization for third party data access to be
meaningful, consumers need to be able revoke that authorization at any
time. For this reason, Sec. 1033.421(h)(1) is designed to ensure
consumers can provide meaningful authorization to third party data
access and can easily and effectively revoke that authorization
whenever they choose. Ensuring the revocation method is as easy to
access and operate as the initial authorization ensures third parties
do not bury the revocation mechanism or otherwise obfuscate, block, or
interfere with consumers' ability to utilize it.
Notice of Revocation (Sec. 1033.421(h)(2))
Under proposed Sec. 1033.421(h)(2), the third party would certify
to notify the data provider, any data aggregator, and other third
parties to whom it has provided the consumer's covered data when the
third party receives a revocation request from the consumer. The CFPB
proposed to require authorized third parties to certify that they will
notify other third parties of the consumer's revocation to ensure that
those third parties that receive covered data from the authorized third
party are aware of the status of the consumer's authorization and can,
accordingly, meet applicable certifications related to use and
retention of that data. The CFPB also proposed in Sec. 1033.421(h)(2)
to require authorized third parties to notify data providers of the
consumer's revocation to ensure data providers are aware of the status
of the consumer's authorization.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.421(h)(2) as proposed. As described above, some commenters
suggested that the final rule specify a time limit by which third
parties must notify other parties of the revocation request. The CFPB
has considered these comments but concludes that Sec. 1033.421(h)(1)
sufficiently addresses the timing of the third party's notice of
consumer revocation to other third parties, since it requires such
notification when the third party receives the consumer's revocation
request.
Effect of Revocation
Proposed Sec. 1033.421(h)(3) would have required the third party
to certify that, upon receipt of a consumer's revocation request or
notice of a revocation request pursuant to proposed Sec. 1033.331(e),
the third party will (1) no longer collect covered data pursuant to the
most recent authorization, and (2) no longer use or retain covered data
that was previously collected pursuant to the most recent authorization
unless use or retention of that covered data remains reasonably
necessary to provide the consumer's requested product or service
[[Page 90949]]
under proposed Sec. 1033.421(a). The CFPB is finalizing these
provisions without substantive change in Sec. 1033.421(i), discussed
below. Comments regarding proposed Sec. 1033.421(h)(3) are discussed
in detail below related to Sec. 1033.421(i).
Effects of Maximum Duration and Revocation on Collection, Use, and
Retention (Sec. 1033.421(i))
Proposed Rule
As described above, proposed Sec. 1033.421(b)(4) and (h)(3)
addressed the effects of maximum duration and receipt of a revocation
notice on collection, use, and retention of consumers' covered data.
With respect to the effect of maximum duration and revocation on use
and retention, proposed Sec. 1033.421(b)(4)(ii) and (h)(3)(ii) would
have specified, consistent with the general limitation in proposed
Sec. 1033.421(a), that when the maximum durational period ends and the
consumer does not provide a new authorization, or upon receipt of a
consumer's revocation request or notice of a revocation request
pursuant to proposed Sec. 1033.331(e), the third party may no longer
use or retain covered data that was previously collected unless use or
retention remains reasonably necessary to provide the consumer's
requested product or service under proposed Sec. 1033.421(a). The
proposed rule stated that, in the current market, third parties use and
retain consumer data for reasons unrelated to providing a consumer-
requested product or service, including after a consumer no longer
receives the product or service from the third party. The proposed rule
further stated that such residual use and retention, which seldom
occurs with consumer awareness, can result in significant privacy and
security risks to consumers and can undermine the consumer's ability to
control access to their covered data. Proposed Sec. 1033.421(b)(4)(ii)
and (h)(3)(ii) would address this concern by making clear that the
general limitation on use and retention in proposed Sec. 1033.421(a)
applies to use and retention of covered data after a one-year maximum
durational period ends and the consumer does not provide a new
authorization, or when a consumer requests revocation pursuant to
proposed Sec. 1033.421(h) or Sec. 1033.331(e).
The proposed rule stated that, while use and retention of covered
data will not be reasonably necessary for most purposes after the third
party's authorization ends, it may continue in some circumstances. The
proposed rule provided the following examples for when use and
retention might continue: a subpoena could require the retention,
beyond the maximum period, of specific data collected in that period;
meeting such legal requirements can continue to remain reasonably
necessary even if only in connection with providing the product prior
to the expiration of the maximum period. The proposed rule also stated
that the consumer could provide a clear, affirmative indication that
they want to continue to use the product beyond the maximum period in a
manner supported by the use and retention of data collected prior to
expiration of that period. In that context, use and retention of some
or all of the data could meet the general standard in proposed Sec.
1033.421(a) even as the consumer no longer makes use of the product in
any manner that would require continued data collection.
The proposed rule explained that the CFPB preliminarily determined
that proposed Sec. 1033.421(b)(4)(ii) and (h)(3)(ii) would provide
third parties with sufficient flexibility to address circumstances in
which continued use or retention of previously collected data might be
permitted under the general standard in proposed Sec. 1033.421(a),
while ensuring that consumer data are not used and retained in a manner
that does not properly reflect the control afforded the consumer under
that same general standard.
Comments Received
Support for the standard in proposed Sec. 1033.421(a) included
support for the general limitation principles as they would apply to
third party retention of covered data. For example, a Member of
Congress, a third party, and a trade association for data providers
supported the general standard as it applies to retention. The third
party stated that data should not be retained except to fulfill the
service requested, while the trade association said cybersecurity risks
increase when third parties can accumulate and store data.
Feedback on this aspect of the proposed rule fell into various
categories, most notably: (1) seeking an exception to, or variation of,
the general limitation standard related to retention; (2) asserting
that consumers should have a role in determining how long data are
retained; (3) asserting that the general limitation standard and the
proposed rule's explanation do not provide enough clarity as to when
third parties must no longer retain covered data; and (4) asserting
that the retention standard is too general and not strong enough.
Commenters who requested an exception or variation on the
limitation standard in the context of retention, mostly trade
associations for third parties and research organizations, suggested
that the proposed rule on retention is too restrictive. Commenters with
this view stated that the final rule should allow retention of de-
identified or pseudonymized data for specific purposes, like
supplemental primary uses, public secondary uses, or research, or allow
retention of historical data for some period so the product, service,
or tool remains populated if a consumer reauthorizes shortly after the
durational period expires. Commenters also stated that a restrictive
retention limit would be harmful to beneficial products and services
that rely on historical data, like cash-flow underwriting. A trade
association for banks asked that the final rule allow third parties to
retain data as long as necessary to defend themselves from consumer
complaints. Finally, a research organization suggested the final rule
should implement affirmative data deletion deadlines and require that
data retention beyond three years be supported by documentation that
the data continues to be reasonably necessary for the provision of the
consumer's requested products or services, unless retention is required
for compliance with other laws.
Commenters that suggested that consumers should have a role in
determining how long data are retained--mostly trade associations for
banks and research organizations--stated that consumers should be able
to consent to how long data are retained or should be able to opt in to
retention of de-identified data. The same commenters suggested that the
proposed rule was too vague for consumers to understand what will be
retained or for third parties to know how to comply. Some commenters in
this category suggested finalizing an explicit requirement to delete
upon the expiration of duration or when a consumer revokes.
Some commenters, including research organizations and trade
associations for banks, asserted that the retention standard is too
general and not strong enough. One commenter stated that the proposed
rule would only discourage indefinite retention and that the final rule
should be more prohibitive. Another suggested the final rule should
implement mandatory time periods by which third parties must delete all
data.
Finally, one third party commenter asked that the final rule
clarify what happens to ``copied data'' held by authorized third
parties and data aggregators.
[[Page 90950]]
Final Rule
For the reasons described herein, the CFPB is finalizing in Sec.
1033.421(i) the provision related to the effect of maximum duration on
collection, use, and retention in proposed Sec. 1033.421(c)(4) and
consumers' revocation requests in proposed Sec. 1033.421(h)(3). As
such, under Sec. 1033.421(i), if a consumer does not provide a new
authorization as described in Sec. 1033.421(b)(3), or if a third party
receives a revocation request as described in Sec. 1033.421(h)(1) or
notice of a consumer's revocation request as described in Sec.
1033.331(e), a third party will: (1) no longer collect covered data
pursuant to the most recent authorization; and (2) no longer use or
retain covered data that was previously collected pursuant to the most
recent authorization unless use or retention of that covered data
remains reasonably necessary to provide the consumer's requested
product or service under Sec. 1033.421(a).
With respect to Sec. 1033.421(i)(1), the CFPB has determined that
the general limitation in Sec. 1033.421(a) will require third parties
to stop collecting covered data when the maximum durational period ends
and the consumer has not provided a new authorization or when the
consumer requests revocation. In those circumstances, collection would
no longer be reasonably necessary to provide the consumer's requested
product or service. Ensuring that collection stops at these points
affords consumers control over the collection of covered data.
With respect to Sec. 1033.421(i)(2), the CFPB has determined that
the general limitation in Sec. 1033.421(a) will, in most
circumstances, require the third party to no longer use or retain
covered data when the maximum durational period ends and the consumer
has not provided a new authorization or when the consumer requests
revocation. The consumer revoking third party authorization or not
providing a new authorization after one year, all other things being
equal, indicates that the existing authorization, without more, no
longer supports use or retention of covered data that has been
collected under its terms. However, specific circumstances may justify
departure from this normal course and, consistent with the general
standard in Sec. 1033.421(a), allow continued use or retention of some
or all previously collected covered data, even when collection of new
covered data has stopped.\121\
---------------------------------------------------------------------------
\121\ A third party commenter suggested that the proposed rule
contained a technical error that would not provide sufficient
flexibility for third parties to retain previously collected data
for permissible uses. However, as noted, the final rule contains
flexibility when circumstances justify such continued retention.
---------------------------------------------------------------------------
As described above, one commenter asked that the final rule clarify
what happens to ``copied data'' that third parties might have following
revocation. The commenter did not elaborate on the meaning of ``copied
data,'' but assuming copied data refers to copies of covered data that
third parties receive or make, the CFPB notes that the general
limitation under Sec. 1033.421(a) would apply and such copied data
could only be used or retained as reasonably necessary to provide the
consumer's requested product or service.
Additionally, as described related to Sec. 1033.421(b), in unusual
circumstances a data provider might provide a third party more data
than the third party requested. This may result in the third party
involuntarily collecting more data than is reasonably necessary to
provide the consumer's requested product or service. The CFPB notes
that, in those circumstances, the general limitation on use and
retention in Sec. 1033.421(a) would apply to that data. While use of
that data would not be reasonably necessary to provide the consumer's
requested product or service, the general limitation standard would
allow third parties to retain covered data for as long as reasonably
necessary to locate and delete that data.
Finally, as noted above in Sec. 1033.421(b) regarding collection,
when the third party receives information that indicates the consumer
may no longer expect to receive the product or service, the third party
should confirm collection of covered data remains reasonably necessary.
In those circumstances, use and retention of covered data may no longer
be reasonably necessary. The CFPB has determined that Sec.
1033.421(i)(2) provides third parties with sufficient flexibility to
address circumstances in which continued use or retention of previously
collected data might be justified under the general limitation. The
certification in Sec. 1033.421(i)(2) also ensures that covered data
are not used and retained in a manner that does not properly reflect
the control afforded the consumer when they do not provide a new
authorization after a maximum durational period has ended or when they
request revocation.
5. Use of Data Aggregator (Sec. 1033.431)
The CFPB proposed certain requirements for the third party
authorization procedures when a third party uses a data aggregator to
assist with accessing covered data on behalf of a consumer. Currently,
many third parties rely on data aggregators to assist with accessing
and processing consumer financial data. The CFPB proposed in Sec.
1033.431 to assign certain responsibilities for the authorization
procedures and impose certain conditions on the third party and the
data aggregator.
A number of commenters addressed how the rule generally should
treat data aggregators. Several commenters, including bank and bank
trade association commenters stated that the rule should impose strong
limitations on data aggregators. One bank trade association commenter
stated that data aggregators often possess far greater bargaining power
than third parties, so they can dictate terms, and that the final rule
should provide that data aggregators are jointly and severally liable
for issues that occur at the third party to which it is providing
services. A bank commenter stated that the proposal underestimates the
systemic risks posed by data aggregators, noting that they likely have
more consumer data than the largest banks and will continue to control
vast amounts of data after the rule takes effect. Another bank trade
association commenter and a credit union commenter stated that data
aggregator should face even more stringent controls on their use of
covered data because consumers have no meaningful choice over the
aggregator that is used. Two bank trade association commenters
recommended that the rule prohibit data aggregators from using covered
data for their own purposes. Several commenters, including bank and
bank trade association commenters, maintained that the rule should
impose obligations directly on data aggregators, stating that the CFPB
should be responsible for enforcing those obligations, rather than
relying on the certification-based approach and relying on authorized
third parties, consumers or data providers to ensure that data
aggregators comply with the obligations. Several commenters, including
bank and bank trade association commenters, requested that the CFPB
exercise supervisory authority over data aggregators to ensure that
they comply with the rule.
For the reasons discussed herein, the CFPB is generally adopting
the approach to data aggregators as proposed, with certain changes in
Sec. 1033.431(c) regarding data aggregator certification. Those
provisions are described in more detail below.
As finalized, Sec. 1033.431 imposes various obligations on data
aggregators, including the requirement in
[[Page 90951]]
Sec. 1033.431(c) that data aggregators must certify to the consumer
that they will comply with specified obligations. The CFPB declines to
provide that data aggregators are jointly and severally liable for
issues that occur at the third party to which the data aggregator is
providing services. Depending on the context, those issues could arise
from conduct unrelated to the services provided by the data aggregator,
so the CFPB has determined that generally imposing joint and several
liability would not be appropriate. The rule does, however, require
data aggregators to certify to the consumer that they will comply with
specified obligations, and in the event that data aggregators breach
those obligations, the CFPB can use its authority to prevent unfair,
deceptive, or abusive acts or practices, as appropriate, to enforce
those obligations against data aggregators. For the reasons discussed
in part IV.D.2, the CFPB has determined that the certification-based
approach is appropriate for third parties, including data aggregators,
and declines to impose additional obligations on third parties in this
rule.
As noted above, some commenters urged the CFPB to impose additional
restrictions on data aggregator use of covered data. The obligations in
Sec. 1033.421(a) and (c) limit the circumstances in which third
parties can collect, use and retain covered data, and data aggregators
must certify to consumers that they will comply with those obligations.
Among other things, the covered data can only be used as reasonably
necessary to provide the product or service requested by the consumer
from the authorized third party. Accordingly, these provisions will
prevent a data aggregator from using the covered data for its own
purposes, and the CFPB has determined that additional restrictions on
data aggregator use of covered data are unnecessary. With respect to
supervision of data aggregators, as discussed in part IV.5, the CFPB's
supervisory authority is defined by the CFPA. The CFPB will continue to
monitor the market, including by using its supervisory authority, and
will consider whether additional rulemakings are appropriate to expand
the scope of the CFPB's supervision with respect to part 1033.
Responsibility for Authorization Procedures (Sec. 1033.431(a))
The CFPB proposed in Sec. 1033.431(a) to allow, but not require, a
data aggregator to perform the third party authorization procedures on
behalf of the third party. Proposed Sec. 1033.431(a) also provided
that the third party would remain responsible for compliance with the
third party authorization procedures and that data aggregators would
have to comply with the data aggregator certification requirements in
proposed Sec. 1033.431(c).
The CFPB preliminarily determined that the third party should be
responsible for compliance with the third party authorization
procedures. The CFPB noted that the third party is providing a product
or service to the consumer and is likely to have the primary
relationship with the consumer, so the consumer may be more comfortable
receiving and responding to communications from the third party. The
third party also likely would be more involved in using and retaining
covered data and therefore may play a greater role than the data
aggregator. Moreover, the data aggregator is assisting the third party
in accessing covered data, so the CFPB preliminarily determined that
the third party should be responsible for compliance with the third
party authorization procedures.
The CFPB noted, however, that some third parties may want to rely
on data aggregators to perform the authorization procedures on their
behalf and that, in some circumstances, it may be more efficient for
data aggregators to do so. Therefore, the CFPB proposed to allow, but
not require, a data aggregator to perform the authorization procedures
on behalf of a third party. The CFPB noted that if a data aggregator
performs the authorization procedures on behalf of the third party, the
consumer's authorization would grant authority to the third party to
access covered data on behalf of the consumer. The third party would
retain the flexibility to discontinue using the data aggregator or
switch to a different aggregator.
Several commenters addressed how to allocate responsibility for the
authorization procedures when a data aggregator is involved. Commenters
including a bank, a bank trade association, and a nondepository entity
all supported the proposed approach of assigning responsibility for the
authorization procedures to the third party seeking authorization but
permitting the data aggregator to perform the authorization procedures
on behalf of the third party.
A number of commenters recommended that the CFPB revise or clarify
how the authorization procedures can be performed when an authorized
third party retains a data aggregator. A bank commenter stated that the
CFPB should clarify which authorization procedures may be performed by
a data aggregator and which ones must be performed by the authorized
third party. The bank commenter stated that the authorized third party
should be responsible for describing the product or service to the
consumer and providing a certification statement. The bank commenter
also urged the CFPB to clarify that the requested product or service is
referring to the product or service offered by the authorized third
party and not a product or service offered by the data aggregator. The
bank commenter also stated that the CFPB should clarify that when a
data aggregator performs the authorization procedures on behalf of the
authorized third party, the authorized third party remains responsible
for its own compliance with the specified obligations. The bank
commenter also urged the CFPB to distinguish the data aggregator's role
when it is acting as an intermediary on behalf of an authorized third
party from when it is attempting to become an authorized third party.
The bank commenter also recommended that when a data aggregator is
acting on behalf of an authorized third party, the data aggregator must
fulfill all of its obligations under the rule independent of other
connections the data aggregator may have fulfilled for the same
consumer on behalf of a different third party. A credit union commenter
recommended that the CFPB remove all references to data aggregators
from the rule and instead require data aggregators to comply with all
of the requirements of an authorized third party. A third party
commenter stated that the rule should clarify that data aggregators may
perform the authorization procedures on their own behalf when they are
operating as authorized third parties. A research institute commenter
stated that the rule should encourage data aggregators to take on
additional roles and responsibilities to support open banking and
provide better experiences to consumers. The research institute
commenter urged the CFPB to clarify when data aggregators can become
authorized third parties.
For the reasons discussed herein, the CFPB is adopting Sec.
1033.431(a) as proposed. Section 1033.431(a) allows, but does not
require, a data aggregator to perform the third party authorization
procedures described in Sec. 1033.401 on behalf of the third party
seeking authorization under Sec. 1033.401 to access covered data.
Under Sec. 1033.431(a), the third party seeking authorization remains
responsible for compliance with the third party authorization
procedures described in Sec. 1033.401. Data aggregators must comply
with the data aggregator certification requirements in Sec.
1033.431(c).
[[Page 90952]]
As indicated in Sec. 1033.431(a), the authorized third party
remains responsible for complying with the authorization procedures,
including certifying to the consumer that it will comply with the
obligations in Sec. 1033.421. However, the data aggregator may perform
the certification procedures on behalf of the authorized third party.
If the data aggregator performs the authorization procedures on behalf
of the authorized third party, the data aggregator must complete the
authorization procedures for the authorized third party and provide the
authorization disclosure with the content required in Sec.
1033.411(b). The data aggregator must also obtain the consumer's
express informed consent for the authorized third party to access
covered data on behalf of the consumer as required in Sec.
1033.401(c). As discussed below in connection with Sec. 1033.431(c),
the data aggregator must also certify that it will comply with the
certification requirements specified in Sec. 1033.431(c).
The CFPB recognizes that third parties may play different roles in
different transactions. A third party may be a data aggregator in one
transaction and an authorized third party in a different transaction.
However, a third party cannot perform both roles in the same
transaction. If a third party is serving as a data aggregator, it
cannot collect, use, and retain the consumer's covered data for its own
purposes. It is limited to accessing the information only as reasonably
necessary for providing the product or service requested by the
consumer from the authorized third party. When a data aggregator
performs the authorization procedures on behalf of an authorized third
party, those authorization procedures apply only to that authorized
third party. If the data aggregator is assisting a second authorized
third party in accessing covered data from the same consumer, the
second authorized third party or the data aggregator acting on behalf
of that second authorized third party must perform the authorization
procedures separately for that second authorized third party.
The CFPB concludes that it is appropriate to identify and adopt
specific provisions applicable for data aggregators separately from
authorized third parties. Data aggregators perform a different role
than authorized third parties, and the CFPB has determined that the
rule should highlight that the authorized third party is responsible
for obtaining the consumer's authorization to access the consumer's
data.
Disclosure of the Name of the Aggregator (Sec. 1033.431(b))
The CFPB proposed in Sec. 1033.431(b) to require that the
authorization disclosure include the name of any data aggregator that
will assist the third party seeking authorization under proposed Sec.
1033.401 with accessing covered data and a brief description of the
services the data aggregator will provide. The proposed rule stated
that, unlike other downstream parties that may access a consumer's
covered data after a third party has completed the authorization
procedures, a data aggregator is typically known to the third party at
the time of authorization and a consumer may directly interact with a
data aggregator when the data aggregator performs the authorization
procedures on behalf of the third party. Therefore, the CFPB
preliminarily determined that identifying and describing the services
of a data aggregator would reduce consumer confusion and better equip
consumers to provide informed consent when authorizing data access. The
proposed rule requested comment on any obstacles to including a data
aggregator's name in the authorization disclosure.
A consumer advocate commenter and a credit union commenter
supported including information about the data aggregator in the
authorization disclosure to provide sufficient transparency. The credit
union commenter requested that both the legal and trade names of the
data aggregator be included in the authorization disclosure.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.431(b) as proposed. Including the data aggregator name and a
description of the data aggregator's services in the authorization
disclosure provides consumers with a key term of access that may reduce
consumer confusion and better equip consumers to provide informed
consent. Commenters did not raise concerns with this approach.
The CFPB is not modifying Sec. 1033.431(b) to require the
inclusion of a data aggregator's legal and trade names, as suggested by
one commenter. The final rule does not require authorized third parties
to include their own legal and trade names, and it would be
inconsistent to require authorized third parties to provide the legal
and trade names of data aggregators. Additionally, including multiple
names for a single data aggregator would make the authorization
disclosure longer, and it is not clear that this added information
would make a significant impact on a consumer's ability to identify the
data aggregator. Finally, as discussed above, the CFPB is finalizing a
requirement that the name of the data aggregator must be ``readily
understandable'' to consumers, which will help ensure that consumers
are able to identify the data aggregator.
Aggregator Certification (Sec. 1033.431(c))
The CFPB proposed in Sec. 1033.431(c) that when a third party
seeking authorization under Sec. 1033.401 will use a data aggregator
to assist with accessing covered data on behalf of a consumer, the data
aggregator must certify to the consumer that it agrees to the
conditions on accessing the consumer's data in proposed Sec.
1033.421(a) through (f) and the condition in proposed Sec.
1033.421(h)(3) upon receipt of the notice described in proposed Sec.
1033.421(h)(2) before accessing the consumer's data. However, the data
aggregator would not have been required to certify that it would
provide a revocation method or certify to the requirements related to
ensuring consumers informed.
The CFPB explained it was proposing to require data aggregators to
certify that they agree to these conditions because, when a third party
uses a data aggregator, the aggregator may play a significant role in
accessing the consumer's data. Data aggregators may, among other
things, process the consumer's login credentials, obtain the consumer's
data from the data provider, and transmit the consumer's data to the
third party. The CFPB stated that, if data aggregators were not
required to agree to these conditions, there could be a significant gap
in the protections afforded to consumers.
In addition, as with the third party's certification statement, the
CFPB wanted the consumer to receive a clear statement of the conditions
that the data aggregator must follow. The certification statement to
the consumer would help consumers, the CFPB, and other regulators to
enforce the obligations to which data aggregators would be required to
certify. The CFPB stated that these considerations are equally
applicable to data aggregators that are retained by the authorized
third party after the consumer has completed the authorization
procedures, so proposed Sec. 1033.431(c) would require those data
aggregators to also provide a certification to the consumer.
The CFPB also proposed in Sec. 1033.431(c) that any data
aggregator that is retained by the authorized third party after the
consumer has completed the authorization procedures must also satisfy
this aggregator certification
[[Page 90953]]
requirement. For this requirement to be satisfied, either (1) the third
party seeking authorization under proposed Sec. 1033.401 must include
this aggregator certification in the authorization disclosure described
in proposed Sec. 1033.411 it provides the consumer, or (2) the data
aggregator must provide to the consumer a separate certification. The
CFPB stated that, for example, the aggregator certification requirement
in proposed Sec. 1033.431(c) would be satisfied where the
authorization disclosure includes a statement that both the third party
and the data aggregator agree to the applicable third party obligations
described in proposed Sec. 1033.421. The CFPB further stated that this
requirement would also be satisfied where the data aggregator provides
the certification to the consumer in a separate communication. When a
data aggregator is retained by the authorized third party after the
consumer has completed the authorization procedures, proposed Sec.
1033.431(c) would not require the consumer to receive a new
authorization disclosure or provide consent. The CFPB sought comment on
whether to include formatting or language access requirements for an
aggregator certification that is provided in a separate communication
from the authorization disclosure.
Regarding the format of the separate data aggregator certification,
a consumer advocate commenter requested that the CFPB include the
following formatting and language access requirements in the final
rule: require model forms, including mobile-friendly versions; require
provision in any language that the authorization was required to be
provided in; set a maximum reading level; and specify timing.
Regarding content of the data aggregator certification, several
bank commenters and a consumer advocate commenter requested that data
aggregators provide a revocation mechanism to ensure that consumers
have the ability to revoke authorization with any entity involved in
the data sharing transaction. Several bank commenters and a consumer
advocate commenter also requested that data aggregators comply with the
requirements related to ensuring consumers are informed in Sec.
1033.421(g) given data aggregators' significant involvement in the
handling of consumer data. These commenters stated that, because of
data aggregators' significant role, consumers may want to contact data
aggregators with questions about the services the data aggregator
provides.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.431(c) with certain modifications. The CFPB is finalizing the
required content of the aggregator certification in the introductory
text of Sec. 1033.431(c) with non-substantive changes. Consistent with
the proposal, the CFPB is not requiring data aggregators to certify to
comply with Sec. 1033.421(g) (the certification related to ensuring
consumers are informed) because this would require the data aggregator
to significantly increase coordination with the third party, such as by
finding out with which downstream parties the third party has shared
the consumer's covered data. This would result in little benefit to
consumers because consumers would already receive this information from
third parties. Requiring data aggregators to certify to comply with the
Sec. 1033.421(g) requirements could also result in consumers receiving
unwanted duplicative information, such as two copies of the
authorization disclosure (one from the third party and one from the
data aggregator). The CFPB is also not requiring a data aggregator to
certify that it will provide consumers with a revocation mechanism
because a data aggregator would potentially have to create a consumer-
facing interface to create a revocation mechanism which is not
otherwise required by final rule. However, data aggregators are
permitted to provide a revocation mechanism if they choose to do so.
The final rule includes non-substantive changes to the introductory
text to Sec. 1033.431(c), including, in the list of provisions that
must be included in the certification, changing the reference from
Sec. 1033.421(h)(3) to Sec. 1033.421(i) because, as described above,
the final rule includes a new Sec. 1033.421(i) that includes
provisions from proposed Sec. 1033.421(b)(4) and (h)(3). The
introductory text of proposed Sec. 1033.431(c) stated that any data
aggregator that is retained by the authorized third party after the
consumer has completed the authorization procedures must also satisfy
this requirement. This substantive requirement is moved to final Sec.
1033.431(c)(2) to clarify that the certification for a data aggregator
retained by an authorized third party after the consumer has completed
the authorization procedures would have to be provided pursuant to
Sec. 1033.431(c)(2).
The CFPB is finalizing as proposed Sec. 1033.431(c)(1), requiring
that if the data aggregator does not provide its certification to the
consumer as set forth in Sec. 1033.431(c)(2), the third party seeking
authorization under Sec. 1033.401 must include the data aggregator's
certification in the authorization disclosure described in Sec.
1033.411.
Final Sec. 1033.431(c)(2) provides that, consistent with the
general requirements for the authorization disclosure, the data
aggregator must provide its certification to the consumer,
electronically or in writing, separate from the authorization
disclosure. As is also consistent with the requirements for the
authorization disclosure and for the reasons explained above in part
IV.D.3 in connection with the requirements for the authorization
disclosure, the certification must be in the same language as the
authorization disclosure and must be clear, conspicuous, and segregated
from other material. The final rule does not require model forms,
reading level, or timing requirements for the aggregator certification,
consistent with the final rule's approach to the authorization
disclosure in Sec. 1033.411(a), described above.
Final Sec. 1033.431(c)(2) also provides that the name of any data
aggregator in the certification must be readily understandable to the
consumer. As explained above in the discussion of Sec. 1033.411(a),
this requirement will help ensure that consumers are able to easily
identify the entities in the certification. As noted above, final Sec.
1033.431(c)(2) also provides that if, after the consumer has completed
the authorization procedures, the authorized third party retains a data
aggregator to assist with accessing covered data on behalf of the
consumer, this data aggregator must provide its certification in
accordance with Sec. 1033.431(c)(2).
6. Policies and Procedures for Third Party Record Retention (Sec.
1033.441)
Proposed Sec. 1033.441(a) would have required a third party that
is a covered person or service provider, as defined in 12 U.S.C.
5481(6) and (26), to establish and maintain written policies and
procedures that are reasonably designed to ensure retention of records
that are evidence of compliance with the requirements of proposed
subpart D. Under proposed Sec. 1033.441(b), records required under
proposed Sec. 1033.441(a) would have to be retained for a reasonable
period of time, not less than three years after a third party obtains
the consumer's most recent authorization under proposed Sec.
1033.401(a).
Proposed Sec. 1033.441(b) based the retention period on the date
of the consumer's most recent authorization because that event would
determine when compliance with proposed subpart D would begin to be
required. The CFPB explained that the minimum three-year period should
be sufficient
[[Page 90954]]
for the CFPB and others to evaluate compliance with respect to any
given authorization because proposed Sec. 1033.421(b)(3) would require
third parties to obtain a new authorization each year. The CFPB
clarified that proposed Sec. 1033.421(b)(4) and (h)(3) were not
designed to impact the requirement for a third party to maintain
policies and procedures to retain records for a reasonable period
proposed in Sec. 1033.441, noting that proposed Sec. 1033.441 covered
records that evidence compliance with proposed subpart D. In contrast,
proposed Sec. 1033.421(b)(4) and (h)(3) covered data collected from
data providers to provide a requested product or service.
Under proposed Sec. 1033.441(c), a third party covered under
proposed Sec. 1033.441(a) would have flexibility to determine its
policies and procedures in light of the size, nature, and complexity of
its activities. The CFPB explained that this flexibility would help
third parties avoid conflicts with other legal obligations (including
other record retention and data security obligations), manage data
security risks, and minimize unnecessary impacts.
To mitigate the risk that the flexibility of proposed Sec.
1033.441(c) might result in the absence of critical evidence, proposed
Sec. 1033.441(e)(1) and (2) would have identified examples of records
that would need to be retained. Specifically, proposed Sec.
1033.441(e) would have provided that records retained pursuant to
policies and procedures required under proposed Sec. 1033.441 must
include, without limitation (1) a copy of the authorization disclosure
that is signed or otherwise agreed to by the consumer and reflects the
date of the consumer's signature or other written or electronic consent
and a record of actions taken by the consumer, including actions taken
through a data provider, to revoke the third party's authorization; and
(2) with respect to a data aggregator covered under proposed Sec.
1033.441(a), a copy of any data aggregator certification statement
provided to the consumer separate from the authorization disclosure
pursuant to proposed Sec. 1033.431(c)(2).
Proposed Sec. 1033.441(d) would have required a third party
covered under proposed Sec. 1033.441(a) to periodically review its
policies and procedures and update them as appropriate to ensure their
continued effectiveness to evidence compliance with the requirements of
proposed subpart D.
The CFPB explained that the flexible policies and procedures
approach of proposed Sec. 1033.441 would be consistent with the SBREFA
Panel's recommendation that the CFPB evaluate record retention
requirements for consistency with other requirements and the avoidance
of unnecessary data security risks, while still ensuring all evidence
of compliance by a third party is retained.
The CFPB requested comment on the proposed length of the retention
period and whether it should be based on another event, such as the
termination of a third party's authorization or a third party's request
for information from a data provider. The CFPB also requested comment
on whether the final rule should identify other examples of records to
be retained. Additionally, the CFPB requested comment on whether
additional guidance was needed on the potential intersections of the
record retention requirements in proposed Sec. 1033.441 and
limitations on retention in proposed Sec. 1033.421(b)(4) and (h)(3).
Commenters generally supported the proposed requirement for third
parties to establish and maintain policies and procedures reasonably
designed to ensure retention of records that evidence compliance with
proposed subpart D. One bank industry group supported measuring the
retention period beginning at the time the third party obtains the
consumer's most recent authorization. Another such group supported the
three-year record retention requirement. On the other hand, some bank
industry commenters suggested that the retention period should be two
years. These commenters stated that this would make the retention
requirement consistent with similar requirements to which data
providers are already subject under Regulation E and Regulation Z.
Further, they stated that the additional year does not pose any benefit
to consumers and that the additional length to retain presents
unnecessary security risks.
For the reasons discussed herein, the CFPB is finalizing Sec.
1033.441(a) through (d) as proposed. The CFPB is finalizing Sec.
1033.441(e) generally as proposed, with minor non-substantive edits for
consistency with other revisions elsewhere in the final rule.
Specifically, records retained pursuant to policies and procedures
required under Sec. 1033.441 must include, without limitation: (1) a
copy of the authorization disclosure that is signed by the consumer
electronically or in writing and reflects the date of the consumer's
signature and a record of actions taken by the consumer, including
actions taken through a data provider or another third party, to revoke
the third party's authorization; and (2) with respect to a data
aggregator covered under Sec. 1033.441(a), a copy of any data
aggregator certification statement that was provided to the consumer
pursuant to Sec. 1033.431(c)(2). The CFPB expects that in order to
ensure accuracy, record integrity, and to preserve the ability to
access the signed authorization disclosure, the authorization
disclosure and the electronic signature establishing consumer consent
cannot as a matter of regular course be provided orally and still
satisfy all of the final rule's requirements.
Section 1033.441 is authorized under CFPA section 1022(b)(1)
because it will enable the CFPB and others to evaluate a third party's
compliance with subpart D and would prevent evasion. To the extent that
Sec. 1033.441 applies to CFPB-supervised nondepository covered
persons, it is additionally authorized by CFPA section 1024(b)(7)
because it will facilitate supervision of such persons and enable the
CFPB to assess and detect risks to consumers.
The CFPB determines that the three-year length of the retention
requirement in Sec. 1033.441(b) is appropriate and the CFPB declines
to align it with the retention requirements in Regulation E and
Regulation Z, as requested by some commenters. The retention
requirements under Regulation E and Regulation Z are substantively
different from those in Sec. 1033.441. Records required under
Regulation E and Regulation Z relate to regulated entities' disclosures
to consumers pertaining to electronic fund transfers and consumer
credit, respectively. Such disclosures to individual consumers are
likely to be stale after a period of two years. Three years of records
contemplated by Sec. 1033.441 will allow for analysis of a third
party's compliance with part 1033, including patterns in third party
actions in requesting access to a data provider's interface and the
authorizing consumer's data over time. Moreover, based on the CFPB's
supervisory and enforcement experience, a three-year retention period
is an appropriate amount of time to enable the CFPB and other
enforcement agencies to examine or conduct enforcement investigations.
12 CFR Part 1001
Providing Financial Data Processing Products or Services (Sec.
1001.2(b))
Proposed Sec. 1001.2(b) would have defined providing financial
data processing products or services by any technological means,
including processing, storing, aggregating, or transmitting financial
or banking data, alone or in connection with another product or
service, as a financial
[[Page 90955]]
product or service under the CFPA. The proposed provision included
certain limited exclusions. After considering public comments, the CFPB
is finalizing the provision as proposed.
Statutory Framework
Under CFPA section 1002(15)(A)(xi)(II), the CFPB may issue a
regulation to define as a financial product or service ``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 issuing Sec. 1001.2(b) pursuant to
this authority. In turn, under the CFPA, a financial product or service
under Sec. 1001.2(b) would qualify as a ``consumer financial product
or service'' under CFPA section 1002(5)(A) if it ``is offered or
provided for use by consumers primarily for personal, family, or
household purposes.''
As the CFPB explained in the proposal, the activities in Sec.
1001.2(b) would have already been within scope of the CFPA's definition
of financial product or service. Specifically, CFPA section
1002(15)(A)(vii) defines as a financial product or service ``providing
payments and other financial data processing to a consumer by any
technological means.'' The language of this provision extends beyond
payment processing to broadly include other forms of financial data
processing. Accordingly, consumers already receive the protections of
the CFPA when entities process their potentially sensitive data,
whether payments or any other category of financial or banking
data.\122\ On this issue, a trade association of the nonbank money
services industry submitted a comment agreeing that the activities in
Sec. 1001.2(b) are already within the scope of the CFPA. Consistent
with the proposed rule, the CFPB is using its rulemaking authority
under CFPA section 1002(15)(A)(xi)(II) to provide even greater
certainty regarding CFPA coverage.\123\
---------------------------------------------------------------------------
\122\ Many of these activities could also fall within other
categories of financial product or service. E.g., CFPA section
1002(15)(A)(ix), 12 U.S.C. 5481(15)(A)(ix) (``collecting, analyzing,
maintaining, or providing consumer report information or other
account information'' under specified circumstances).
\123\ Accordingly, the scope of Sec. 1001.2(b) is independent
of how CFPA section 1002(15)(A)(xi)(II) is construed.
---------------------------------------------------------------------------
Overview of Sec. 1001.2(b)
By conferring authority on the CFPB to define additional financial
products or services, the CFPA accounts for the possibility that the
enumerated list of financial products and services in CFPA section
1002(15)(A)(i) through (x) may not completely capture the markets for
financial products or services that are significant for consumers,
especially as market developments lead to emerging concerns for
consumers. As already noted, the final rule has the potential to expand
access to personal financial data and subject such data to a wider
variety of data processing activities. The CFPB is adding to the
definition of financial product or service the category of ``providing
financial data processing products or services'' to ensure that
activities involving consumers' potentially sensitive personal
financial information are subject to the CFPA and its prohibition on
unfair, deceptive, or abusive acts or practices to the full extent
authorized by Congress.\124\ The definition includes examples to
illustrate the activities that fall within the term financial data
processing. Section 1001.2(b) clarifies that the financial data
processing products or services that are covered by the definition
could be offered either alone or in connection with another financial
or nonfinancial product or service, and so it does not cease to be
covered simply because it is offered in connection with the
latter.\125\
---------------------------------------------------------------------------
\124\ 12 U.S.C. 5531, 5536.
\125\ The CFPB notes that the scope of a ``covered consumer
financial product or service,'' as defined under Sec. 1033.111(b)
for purposes of part 1033, is not dependent on adopting Sec.
1001.2(b). The products and services listed in Sec. 1033.111(b) are
already covered by existing statutory provisions such as CFPA
sections 1002(15)(A)(i), (iv), (v), and (vii).
---------------------------------------------------------------------------
Statutory Factors
Consistent with the proposal, the CFPB has determined that Sec.
1001.2(b) meets the two factors set forth in CFPA section
1002(15)(A)(xi)(II). First, these activities are permissible for
financial holding companies under the Federal Reserve Board's
Regulation Y and for national banks under OCC regulations.\126\ Both
financial holding companies and national banks are permitted to engage,
among other things, in data processing, data storage, and data
transmission services by any technological means, so long as the data
to be processed are financial, banking, or economic.\127\
---------------------------------------------------------------------------
\126\ 12 CFR 225.28(b)(14), 7.5006(a); see also 68 FR 68493,
68495-96 (Dec. 9, 2003) (explaining that 12 CFR 225.28(b)(14)
permits bank holding companies to engage in a ``wide range'' of data
processing activities, including bill pay services, financial data
processing for marketing purposes, and delivering financial products
or services over the internet, among other activities).
\127\ Id.
---------------------------------------------------------------------------
No commenter disputed that the defined activities satisfy the first
CFPA factor of being permissible for financial holding companies or
banks. A research institute commenter did express concern that the
definition could encompass activities that, in the commenter's view,
are not financial. This commenter advocated that the CFPB borrow a test
for financial activities from certain FTC regulations implementing the
GLBA. However, this commenter did not argue that the financial data
processing products or services covered by Sec. 1001.2(b) are not
permissible for financial holding companies or banks, which is the
standard selected by Congress in the context of the CFPA. The commenter
did not explain why the CFPB should use a test from a different
regulatory framework instead of the CFPA standard, and accordingly the
CFPB is relying on the CFPA standard.
With respect to the second CFPA factor, the processing of personal
financial information has, or is likely to have, a material impact on
consumers. As already discussed in the proposal and above in part I,
use of personal financial data has become an even more important part
of consumer finance than it was at the time that the CFPA was enacted
in 2010. The processing of personal financial data, including storing,
aggregating, and transmitting such data, has the potential to provide
benefits to consumers but also expose them to a number of substantial
risks. Financial data processing activities that are provided to
consumers, assuming they are not already included within the definition
of a financial product or service under CFPA section 1002(15)(A)(vii),
raise the same type of consumer protection concerns as activities that
do fall within this definition.
No commenter disputed the material impact of the activities covered
by Sec. 1001.2(b) on consumers. A bank expressed support for Sec.
1001.2(b) as regulating nonbanks in a like manner as banks. A bank
trade association argued that the provision should do more to cover
data aggregators. However, the CFPB notes that Sec. 1001.2(b) includes
aggregating financial or banking data as an example of a financial data
processing product or service.
Exclusions
Section 1001.2(b) states that it does not apply where the financial
data processing is offered or provided by a
[[Page 90956]]
person who, by operation of CFPA section 1002(15)(A)(vii)(I) or (II),
is not a covered person. As background, CFPA section 1002(15)(A)(vii)
provides that a person shall not be deemed to be a covered person with
respect to financial data processing solely because the person engages
in certain narrowly prescribed processing activities. CFPA section
1002(15)(A)(vii)(I) excludes from coverage certain merchants, retailers
or sellers of non-financial products or services that are solely
engaged in certain activities related to initiating payment
instructions, whereas CFPA section 1002(15)(A)(vii)(II) excludes
persons that solely provide access to a host server for websites. The
CFPB is paralleling these exclusions in Sec. 1001.2(b).
A research institute commenter argued that Sec. 1001.2(b) should
be amended to reflect CFPA section 1002(15)(C)(ii), which excludes
``electronic conduit services'' (as further defined in CFPA section
1002(11)) from the statutory definition of ``financial product or
service.'' However, it is unnecessary to specifically amend Sec.
1001.2(b) along these lines, because, like other categories of
financial product or service, Sec. 1001.2(b) remains subject to the
exclusion for electronic conduit services in CFPA section
1002(15)(C)(ii).\128\ A trade association generally supported
clarifying that financial data processing is a financial product or
service under the CFPA. But it argued that ``transmitting'' financial
data should be excluded from Sec. 1001.2(b), because the trade
association viewed it as distinct from financial data processing.
However, financial data transmission is expressly covered by the
applicable longstanding provisions of Regulation Y and OCC regulations,
and it is within the scope of the CFPB's statutory authority if it is
not an electronic conduit service as defined in CFPA section 1002(11).
---------------------------------------------------------------------------
\128\ See 12 CFR 1001.2 (introductory language stating that
definitions apply except ``as otherwise provided in [the CFPA]'').
This commenter also argued that Sec. 1001.2(b) should be amended to
exclude certain persons who are excluded from the definition of
``service provider'' under CFPA section 1002(26)(a)(ii). That
exclusion from the definition of ``service provider'' has
similarities to the exclusion of electronic conduit services from
the definition of ``financial product or service.'' However, the
commenter did not explain why the exclusion from the distinct
statutory definition of ``service provider'' should be imported into
the definition of ``financial product or service,'' and the CFPB is
not aware of a reason to do so. If the ``service provider''
exclusion applies to an entity, it would not be a service provider
under the terms of the statute.
---------------------------------------------------------------------------
Another trade association supported covering certain ``retail''
financial data services that are ``consumer facing,'' but it advocated
excluding what it described as ``non-retail'' services. The trade
association argued that covering ``non-retail'' entities would reduce
competition by limiting those entities' ability to efficiently use
data. However, the CFPB cannot discern from the comment why the
commenter believes this to be the case. The CFPB notes that Congress
has already established a boundary for a ``consumer financial product
or service'' based on whether the product or service is ``offered or
provided for use by consumers primarily for personal, family, or
household purposes'' under CFPA section 1002(5)(A). Within that
boundary, assuming a given financial data processing product or service
would not have already been covered by CFPA section 1002(15)(A)(vii),
the principal consequence of Sec. 1001.2(b) is to protect consumers
from unfair, deceptive, or abusive acts or practices under the CFPA.
The CFPB does not agree that Congress's prohibition on subjecting
consumers to unfair, deceptive, or abusive acts or practices interferes
with fair competition.\129\
---------------------------------------------------------------------------
\129\ E.g., CFPA section 1031(c)(1)(B) (citing countervailing
benefits to consumers and to competition as a factor when
identifying unfair acts or practices).
---------------------------------------------------------------------------
Finally, a consumer advocate commenter requested that the CFPB
clarify that when an entity is covered by the CFPA through Sec.
1001.2(b), that does not imply the entity is not covered by the Fair
Credit Reporting Act. However, CFPA coverage does not foreclose an
entity from being covered by other laws the CFPB administers, so the
CFPB does not see a need to amend Sec. 1001.2(b) to address the stated
concern.
V. Effective and Compliance Dates
The effective date of the final rule is 60 days after the rule is
published in the Federal Register. The CFPB proposed this effective
date and did not receive any comments. As set forth in 12 CFR 1033.121,
data providers must comply with the requirements in subparts B and C
beginning April 1, 2026; April 1, 2027; April 1, 2028; April 1, 2029;
or April 1, 2030, depending on the criteria set forth in Sec.
1033.121(c). See part IV.A.5 for a discussion of the comments received
with respect to compliance dates. In the case of the amendment to part
1001, the proposal explained that the activities covered by the
amendment are already within the scope of the CFPA's definition of
financial product or service, and it stated that no compliance date is
necessary.\130\ The CFPB received no comments on the implementation
period for the amendment to part 1001, and accordingly it is finalizing
the 60-day effective date as proposed.
---------------------------------------------------------------------------
\130\ Even assuming the activities covered by the amendment to
part 1001 were not already within the scope of the CFPA's definition
of financial product or service, the CFPB notes that it has no
reason to believe a 60-day implementation period would be
insufficient.
---------------------------------------------------------------------------
VI. CFPA Section 1022(b) Analysis
A. Statement of Need
In section 1033 of the CFPA, Congress authorized and directed the
CFPB to adopt regulations governing consumers' data access rights. The
CFPB is issuing this final rule to implement CFPA section 1033 with
respect to certain covered persons under the CFPA. The CFPB is also
relying on other CFPA authorities for specific aspects of the rule.
Because the primary purpose of this rule is to implement section
1033 of the CFPA, the role of this CFPA section 1022(b) analysis is to
evaluate the benefits, costs, and impacts of the specific policies
within the rule and potential alternatives to those policies. This
Statement of Need summarizes the CFPB's understanding of the gaps
between Congress's intended outcome for consumers' financial data
access rights and current practices, and describes the overall goals of
the rule in closing those gaps. The remainder of the CFPA section
1022(b) analysis discusses the benefits, costs, and impacts of the
specific provisions, and potential alternatives.
CFPA section 1033 requires data providers to make financial data
available in electronic form upon request to consumers and third
parties authorized to act on their behalf. Today, consumer financial
data may be accessed by third parties through methods that raise data
security and privacy risks, and consumers may have little to no
knowledge of or control over how the data are used by third parties
that have access to it. In addition, the market has been slow to
implement secure and efficient methods for sharing data with third
parties, and data providers may not be motivated to provide in a timely
and readily usable manner all the data fields that consumers may want
to access. The result is that access to consumer financial data can be
unreliable, or that financial data held by some providers may be
unavailable to some consumers or their authorized third parties.
When data are made available, there is a general lack of
consistency across data providers in the terms and conditions for
access and the technical specifications used. This creates
[[Page 90957]]
inefficiencies for market participants, and often entails substantial
levels of cost.
This rule aims to (1) expand consumers' access to their financial
data across a wide range of financial institutions, (2) ensure privacy
and data security for consumers by limiting the collection, use, and
retention of data that are not needed to provide the consumer's
requested service, and (3) push for greater efficiency and reliability
of data access across the industry to reduce industry costs, facilitate
competition, and support the development of new products and services
beneficial to consumers.
B. Data and Evidence
The CFPB's analysis of costs, benefits, and impacts is informed by
data from a range of sources. These include data collected in the
Provider Collection and Aggregator Collection,\131\ as well as data
obtained from other regulatory agencies \132\ and publicly available
sources.\133\
---------------------------------------------------------------------------
\131\ For information about the data collected in the Provider
Collection and Aggregator Collection, respectively, see Consumer
Fin. Prot. Bureau, Generic Order for Data Providers, https://files.consumerfinance.gov/f/documents/cfpb_generic-1022-order-data-provider_2023-01.pdf; and Consumer Fin. Prot. Bureau, Generic Order
for Data Aggregators, https://files.consumerfinance.gov/f/documents/cfpb_generic-1022-order-data-aggregator_2023-01.pdf (both last
visited Oct. 16, 2024). Because data providers and data aggregators
vary substantially in size and business practices, the data from
these collections are likely not representative of the market as a
whole. The data are informative about the practices of some large
data providers and a selection of data aggregators and third
parties.
\132\ In particular, these include entity-level FFIEC and NCUA
data on characteristics of depository institutions.
\133\ The analysis is informed by academic research papers,
reports on research by industry and trade groups, practitioner
studies, and comment letters received by the CFPB. Where used, these
specific sources are cited in this analysis.
---------------------------------------------------------------------------
In 2016, the CFPB released and received comments on an RFI on
consumer rights to access financial data. In 2020, the CFPB held a
symposium titled ``Consumer Access to Financial Records'' and released
a summary of the proceedings. Later in 2020, the CFPB released and
received comments on an ANPR. In 2023, the CFPB convened a SBREFA Panel
to gather input from small businesses and the Panel issued the SBREFA
Panel Report.\134\ The CFPB also solicited and received comments from
other industry participants on the SBREFA Outline.\135\ Later in 2023,
the CFPB issued its proposed rule, and received comments from the
public in response.\136\ In addition to these sources of information,
these impact analyses are informed by consultations with other
regulatory agencies, industry, consumer advocates, and researchers.
Part II.A further describes the CFPB's outreach.
---------------------------------------------------------------------------
\134\ 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), https://files.consumerfinance.gov/f/documents/cfpb_1033-data-rights-rule-sbrefa-panel-report_2023-03.pdf.
\135\ Consumer Fin. Prot. Bureau, CFPB Kicks Off Personal
Financial Data Rights Rulemaking (Oct. 27, 2022), https://www.consumerfinance.gov/about-us/newsroom/cfpb-kicks-off-personal-financial-data-rights-rulemaking/.
\136\ See 88 FR 74796 (Oct. 31, 2023).
---------------------------------------------------------------------------
For the types of financial data and access generally covered by
this rule, the information obtained through the Provider Collection and
Aggregator Collection allow the CFPB to estimate: the number of data
providers consumer-authorized data are accessed from; the number of
third parties accessing or using consumer-authorized data; the number
of consumers granting third parties permission to access data on their
behalf; the total number of permissioned access attempts; and
information about the technologies used and the purposes of the
permissioned data access. The Provider Collection and Aggregator
Collection also allow the CFPB to estimate the operational costs of
providing direct and third party data access, and the costs of
establishing data access agreements. To maintain the confidentiality of
the respondents to these data collections, the CFPB provides
approximate or bounded estimates derived from these data, rather than
precise totals or figures specific to any one respondent.\137\
---------------------------------------------------------------------------
\137\ The CFPB treats the information received in the Provider
Collection and the Aggregator Collection in accordance with its
confidentiality regulations at 12 CFR 1070.40 et seq.
---------------------------------------------------------------------------
In the proposal, the CFPB requested additional information or data
that could refine these estimates. Where commenters provided such
information, it is discussed in the relevant part and incorporated into
the analysis and estimates.
For data on the number and characteristics of covered depository
institutions, the CFPB relies on data from FFIEC and NCUA Call
Reports.\138\ These sources provide quarterly information on the number
of institutions, dollar amount of institution-level assets, number of
deposit accounts, dollar volume of credit card lending, and other
characteristics. Notably, these data provide information on the number
of deposit accounts insured by the FDIC or NCUA, which are imperfect,
but nonetheless the best available proxy for the number of covered
financial accounts held by depositories. While this measure includes
covered depository accounts, it also includes business accounts and
other accounts that are not covered by the rule. It also does not
include certain covered financial accounts, such as credit card
accounts and non-bank products. The FFIEC data also provide information
on the websites and digital banking capabilities for banks. The CFPB
supplemented this information with comparable information in NCUA
Profile (Form 4501A) data for credit unions.\139\
---------------------------------------------------------------------------
\138\ See Fed. Fin. Insts. Examination Council, Central Data
Repository's Public Data Distribution, https://cdr.ffiec.gov/ (last
visited Oct. 16, 2024); and Nat'l Credit Union Admin., Credit Union
and Corporate Call Report Data, https://ncua.gov/analysis/credit-union-corporate-call-report-data (last updated Sept. 5, 2024).
\139\ See Nat'l Credit Union Admin., CUOnline, https://ncua.gov/regulation-supervision/regulatory-reporting/cuonline (last updated
Sept. 18, 2024).
---------------------------------------------------------------------------
To estimate costs to small entities of the provisions, the CFPB
relies on information gathered from the SBREFA process and from
comments on the proposal. This includes written feedback on the SBREFA
Outline submitted by small entity representatives, the discussions at
the SBREFA Panel summarized in the SBREFA Panel Report, and comments on
the proposal.
C. Coverage of the Rule
Part VII.B.4 provides a discussion of the number and types of
entities affected by the rule. Relative to the proposal, the most
substantial change in coverage is that depositories with assets below
specified size standards defined by the SBA are not covered as data
providers under the rule.
D. Baseline for Consideration of Costs and Benefits
In evaluating the rule's benefits, costs, and impacts, the CFPB
considers the impacts against a baseline in which the CFPB takes no
regulatory action. This baseline includes existing regulations, State
laws, and the current state of the market. In addition, because the
market is still developing rapidly, the analysis assumes that the
market trends toward greater data access and increased adoption of
developer interfaces would continue under the baseline, but assumes no
change in the State laws and regulations currently in effect that are
related to consumers' data access rights for either direct access or
access through third parties.
A large and growing number of consumers currently access their
financial data through consumer-
[[Page 90958]]
authorized third parties. This access is provided by a range of
technologies, including credential-free APIs, APIs that require third
parties to retain consumer credentials (credential-based APIs), and
credential-based access through consumer-facing digital banking
interfaces such as online banking websites or mobile applications
(screen scraping). As discussed in part I.B, with respect to the state
of the open banking system, the CFPB estimates that more than 100
million consumers have used consumer-authorized data access,
authorizing thousands of third parties to access their financial data
at thousands of data providers, often through intermediaries such as
data aggregators.\140\
---------------------------------------------------------------------------
\140\ Unless described otherwise, the estimates in this part
VI.D are derived from the total numbers of consumers, connections,
and access attempts reported by data providers in the Provider
Collection and third parties in the Aggregator Collection. These
estimates are necessarily approximate, as the CFPB aims to protect
the confidentiality of the respondents, account for the substantial
share of consumer-authorized data sharing that is not captured by
the respondents, and account for the likely potential overlap in
counts for consumers, connections, and access attempts that involve
respondents to both the Provider Collection and the Aggregator
Collection.
---------------------------------------------------------------------------
In total, the CFPB estimates that there were between 50 billion and
100 billion total consumer-authorized access attempts in 2022.\141\
Usage has grown substantially in recent years, as the annual number of
consumer-authorized access attempts approximately doubled from 2019 to
2022, and usage has continued to grow since 2022.\142\
---------------------------------------------------------------------------
\141\ An access attempt is defined here as an individual
instance in which a single consumer-authorized third party requests
or attempts to pull data about a single consumer's accounts from a
single data provider's systems. Not all attempts will lead to a
successful data transfer, but the number of access attempts is used
as an indicator for the overall size and growth of the open banking
system.
\142\ See Fin. Data Exch., Financial Data Exchange (FDX) Reports
76 Million Consumer Accounts Use FDX API (Mar. 13, 2024), https://www.financialdataexchange.org/FDX/News/Press-Releases/Financial_Data_Exchange__FDX__Reports_76_Million_Consumers_Use_FDX_API.aspx.
---------------------------------------------------------------------------
This third party financial data access enables numerous use cases
for consumers. In 2022, data available to the CFPB show that there were
more than two billion access attempts to facilitate payment services,
more than one billion access attempts for the purpose of identity
verification (typically for opening new accounts), tens of billions of
access attempts for account monitoring and personal financial
management use cases, and over one billion access attempts facilitating
other use cases, including fraud risk assessments, loan underwriting,
and asset and income verification.
While the share of consumer-authorized data accessed through
dedicated credential-free APIs has grown sharply, many access attempts
still rely on either credential-based APIs or screen scraping. As a
share of all access attempts made by firms in the Aggregator
Collection, the use of credential-free APIs grew from less than 1
percent in 2019 and 2020 to 9 percent in 2021 and 24 percent in 2022.
At the same time, the share of access attempts using screen scraping
declined from 80 percent in 2019 to 50 percent in 2022. Credential-
based APIs saw a slight increase from 20 percent in 2019 to 27 percent
in 2022.
The recent growth in traffic through credential-free APIs reflects
the adoption of this technology by some of the largest data providers,
covering tens of millions of covered accounts. All depository data
providers with more than $500 billion in assets have established, or in
the near future will establish, a credential-free API. However, despite
recent growth, the total share of data providers offering credential-
free access methods remains limited. At the end of 2022, an estimated 5
to 10 percent of all data providers offered credential-free APIs, up
from less than 1 percent in 2021. The adoption of credential-free APIs
by core banking service providers and other vendors that serve hundreds
of smaller depository institutions contributed to this growth.\143\
While adoption is relatively high for the largest depository data
providers, the CFPB estimates that only 10 to 20 percent of
depositories with more than $10 billion in assets had credential-free
APIs at the end of 2022.
---------------------------------------------------------------------------
\143\ For example, see Press Release, Jack Henry & Assocs.,
Inc., Jack Henry Partners with Open Banking Providers to Enhance
Digital Platform (Oct. 12, 2021), https://ir.jackhenry.com/news-releases/news-release-details/jack-henry-partners-open-banking-providers-enhance-digital.
---------------------------------------------------------------------------
The future evolution of the marketplace enabled by the exchange of
consumer financial data is uncertain. Based on the data and market
trends available, the CFPB makes the following assumptions for the
baseline in this impact analysis. The analysis assumes that most of the
largest data providers have adopted or likely would in the near future
adopt credential-free APIs, which would meet many--but likely not all--
requirements contained in the rule. Awareness of CFPA section 1033 may
have contributed to this, though adoption is also influenced by data
providers' desire to shift third party access away from screen scraping
and towards more secure and efficient technologies, as well as the
demand for third party access from data providers' customers. The
analysis also assumes that some share of smaller institutions would
adopt credential-free APIs, depending on their technology and business
models, over a longer-term horizon. Based on past trends, larger
institutions would be more likely to adopt such interfaces sooner.
However, adoption may be easier for (1) depositories whose systems are
already well integrated in-house or with large core banking or online
banking service providers and (2) nondepositories and newer
depositories that do not have complex legacy systems, irrespective of
the sizes of these types of institutions. In addition, in the current
market some data providers block screen scraping access under certain
circumstances, including for third party risk management, and the CFPB
expects this would continue under the baseline.
The CFPB understands that all or most third parties seeking to
access consumer-authorized information and data providers are subject
to the GLBA, specifically either the FTC's Safeguards Rule or the
prudential regulators' Safeguards Guidelines. Additionally, third
parties that operate in one of the at least 11 States with consumer
data privacy legislation may be subject to other data security
requirements and data usage restrictions. These State laws have all
been passed since 2018. Depository data providers also have third party
risk management obligations required by their prudential regulators,
which will impose data security requirements on third parties seeking
to access consumer-authorized data. As a result, at baseline, the CFPB
expects that many third parties are already subject to statutory and
regulatory data privacy and security obligations, and third parties
have adopted or would adopt some basic standards related to risk
management, data security, and data use. These standards likely have
some degree of overlap with the requirements in the rule, though
individual company systems or policies will depend on the size,
location, practices, and other circumstances of each third party.
Several commenters expressed concerns about how the rule may
interact with other existing or future regulations. A credit union and
a bank trade association asserted that the CFPB estimated costs in
isolation of other regulations, including those from prudential
regulators. Two data aggregators commented that data providers will
invoke third party risk management obligations to deny access in
anticompetitive ways. SBA Advocacy and a trade association commented
that the CFPB should consider current or
[[Page 90959]]
future State laws that may have similar requirements.
The CFPB has considered existing regulations and laws that interact
with the rule, as these are part of the baseline for this impact
analysis. Any costs of complying with existing regulations and laws are
thus included in the baseline, and this analysis is of changes in costs
relative to that baseline. The impact analysis does not consider the
effects of potential future laws or regulations that may interact with
the rule, as this would be overly speculative given the uncertainty
around them.
The impact analysis generally includes the major elements of costs
to firms of complying with the rule. It also includes a discussion of
how some of these costs likely would have been borne under the baseline
as data providers either would have adopted or already have adopted
systems or policies similar to those required by the rule. For example,
where data providers have adopted some form of credential-free third
party access under the baseline, the analysis discusses how the rule
will impact the terms, costs, and features of such functionality.
Finally, in the context of direct access, the proposal assumed for
its baseline that all covered data providers offer consumers some
digital banking interface and that these interfaces typically provide
all or nearly all data fields required to be made available by the
proposal. The CFPB maintains this assumption in the final rule, as the
CFPB understands that all or nearly all data providers within the
rule's revised coverage offer consumer interfaces. Comments related to
the costs of building and maintaining such interfaces for direct access
from data providers are discussed in part VI.E.1. The analysis
considers how the rule will impact the costs and features of data
providers' consumer interfaces.
E. Potential Benefits and Costs to Consumers and Covered Persons
The analysis below describes the potential benefits and costs to
consumers and covered persons in the following order: costs to data
providers, costs to third parties, costs to consumers, benefits to data
providers, benefits to third parties, benefits to consumers, and
alternatives considered.
A service provider for credit unions asserted that the CFPB should
engage in a more thorough cost-benefit analysis and that the CFPB did
not gather enough input or data from core providers. Trade associations
for credit unions and businesses claimed that the proposal's analysis
was incomplete, some elements had not been justified, and that the CFPB
had failed to engage in a thorough and accurate analysis. The CFPB
considered all of the data and evidence described in part VI.B,
including all comments on the proposal, in analyzing the potential
benefits and costs of the rule. The CFPB does not have the data to
precisely determine every potential benefit and cost of the rule, but
requested comment on the proposal for additional data or evidence that
could refine the estimates of benefits and costs. The CFPB has
reasonably evaluated all such evidence provided, and updated its
estimates where appropriate.
Where commenters stated that the CFPB had failed to justify or
address the benefits and costs of particular provisions of the
proposal, those comments are discussed in this part.
1. Costs to Covered Persons
Costs to Data Providers
As a result of the rule, covered data providers may face increased
costs related to maintaining consumer interfaces and establishing and
maintaining developer interfaces, including modifying their existing
systems to comply with the rule. The CFPB expects the largest costs to
data providers to come from establishing and maintaining data access
for authorized third parties in accordance with rule requirements.
Covered data providers will also incur costs related to developing and
implementing policies and procedures governing those systems. The rule
may have additional costs to covered data providers related to changes
in the frequency, scope, or method of consumer-authorized data access
relative to the baseline. These changes may have secondary effects on
the profitability of certain business models or practices, including by
facilitating competition and enabling new products and services. The
estimation of data providers' costs described in this section broadly
uses the same methodology that the CFPB used in the proposal unless
otherwise noted. The primary differences are adjustments to the costs
of developing policies and procedures that are informed by comments.
Maintaining Direct Consumer Access
The rule requires covered data providers to make covered data
available through consumer interfaces and to allow consumers to export
certain information in machine-readable formats. As discussed in part
IV.A.2, small depository institutions are not required to comply with
the final rule's requirements applicable to data providers. During the
SBREFA Panel meetings, the CFPB received feedback that certain
categories of information under consideration in the SBREFA Outline are
not typically made available directly to consumers, and thus would be
costly to provide.\144\ Based on this feedback, the rule covers a more
limited set of information, which the CFPB understands is currently
provided through existing consumer interfaces by all or nearly all data
providers. Therefore, for most data providers, the CFPB expects limited
additional costs due to the rule's direct consumer access requirements.
For those data providers that do not provide all required information
under the baseline, the CFPB expects that such information could be
added at relatively low cost because the required information is
generally already necessary for compliance with other regulatory
requirements, like providing account opening disclosures. The CFPB does
not have sufficient data to quantify the levels of these costs.
---------------------------------------------------------------------------
\144\ SBREFA Panel Report at 24.
---------------------------------------------------------------------------
In the proposed rule, the CFPB sought comment or information on the
costs of adding data fields to the consumer interfaces but did not
receive any. A trade association for nondepository service providers
commented that the costs would be high to create a consumer interface
for nondepository institutions that do not have one already but did not
provide additional information on the magnitude of the cost. A few
other commenters asserted that the rule will raise costs and barriers
to entry for retailers to develop and use pass-through digital wallets,
if those products are covered as data providers. The CFPB expects that
few nondepository data providers that are covered by the rule do not
already have a consumer interface. The CFPB acknowledges that those few
nondepository data providers could incur additional costs associated
with creating a consumer interface but does not have sufficient data to
determine the magnitude of these costs.
Maintaining Third Party Access
The rule requires data providers to maintain data access through a
compliant developer interface. Although many data providers already
maintain similar functionality, others would need to establish new
interfaces, likely integrated with existing infrastructure that
supports their consumer interfaces. However, unlike the proposal, the
rule does not require small depositories to maintain data access for
authorized third parties, meaning many fewer
[[Page 90960]]
institutions than estimated in the proposal will need to provide data
access functionality under the rule. The CFPB expects that the costs of
modifying existing infrastructure to ensure compliance with the rule
will depend on the scope and nature of the necessary modifications but
would generally be lower than the cost of establishing a new
interface.\145\
---------------------------------------------------------------------------
\145\ For example, some data providers with existing interfaces
may need to provide additional data fields, change the way their
data are formatted, or make additional investments to ensure their
interfaces meet the performance specifications required by the
proposed rule.
---------------------------------------------------------------------------
In general, data providers must either contract with a vendor for
the required functionality or develop and maintain it in-house. The
analysis below estimates compliance costs under these two approaches.
Some data providers may comply with the rule through a combination of
contracted services and in-house development. Because data providers
will generally choose the lowest-cost approach, their costs will
generally be at or below the lower of the costs of the two feasible
alternatives analyzed here.
The CFPB understands that data providers' costs depend on many
factors and the extent to which they vary is impossible to fully
capture. To produce cost estimates that are practical, meaningful, and
transparent, where feasible, the CFPB estimates initial upfront costs
and annual costs that generally scale with the size of the data
provider for each of the contracted services and in-house approaches.
All else equal, a data provider's annual cost per account or per
customer is likely to decrease with a greater number of accounts or
customers due to economies of scale. During the SBREFA process and in
the Provider Collection, some data providers provided cost estimates
per account while others estimated costs per customer. Therefore, the
analysis below discusses estimates of the annual cost per account or
per customer of operating a compliant developer interface that are
likely to be appropriate for data providers of different sizes.
Under the contracted services approach, data providers would
primarily contract with a vendor for the necessary functionality. At
baseline, many covered data providers contract with core banking
providers or other vendors for transaction processing, online banking
systems, or other key banking functions. Some core banking providers
currently offer services to enable developer interfaces for data
providers. The CFPB understands that some large core banking providers
provide their clients with a basic developer interface at no additional
cost.\146\ Based on comments received during the SBREFA process and
market research, the CFPB understands that other core banking providers
charge flat monthly fees or per-account fees.\147\ The CFPB understands
that these fees vary but generally estimates that fees can be up to $24
per account per year.\148\
---------------------------------------------------------------------------
\146\ For example, see Jack Henry & Assocs., Inc., Secure Data
Connection: take back control of account connection, https://banno.com/data-aggregators/ (last visited Oct. 16, 2024).
\147\ SBREFA Panel Report at 37.
\148\ Id. at 38.
---------------------------------------------------------------------------
Data providers taking this approach will generally have minimal
upfront costs to enable the required third party access. However, some
data providers use service providers that do not currently offer this
kind of functionality. Although other options exist and the CFPB
expects service providers would face strong competitive pressure to
offer compliant developer interfaces to their clients, the lowest cost
option for some data providers may involve changing their core banking
provider. The fixed costs of changing core banking providers can be
high. Several small entity representatives stated that the upfront
costs at a new core banking provider can range from $50,000 to $350,000
depending on the scale and complexity of the system, with up to
$200,000 in additional decommissioning costs to retrieve information
from the old core banking provider. While small depository institutions
are not required to comply with this final rule, many medium-sized
depository institutions also rely on core providers. The CFPB expects
that the medium-sized depository institutions may pay closer to
$350,000 due to scale and complexity if they need to switch to a new
core provider that offers a compliant developer interface. Based on its
market research, the CFPB understands that core banking providers that
offer a developer interface have a combined market share exceeding 67
percent.\149\ Therefore, at most, 33 percent of depository data
providers would need to change core banking providers to obtain a
compliant interface that is bundled with their other core banking
services. However, the CFPB expects that the true share of covered
depository data providers that pay these costs will be much lower than
33 percent. Data aggregators and other software vendors offer developer
interfaces and the CFPB expects that some data providers will obtain
the necessary functionality through these channels and will not need to
change their core banking provider. Furthermore, core banking providers
will face strong competitive pressure to offer compliant developer
interfaces to retain their clients and potentially capture additional
market share. The CFPB expects that these forces are likely to cause
the cost of obtaining compliant interfaces to decline over time, which
may reduce compliance costs most substantially for smaller covered
depository data providers, given that they have the latest compliance
date.
---------------------------------------------------------------------------
\149\ See Press Release, Fiserv, Finicity and Fiserv Offer More
Consumer Choice Through Secure Data Access (Mar. 30, 2022), https://newsroom.fiserv.com/news-releases/news-release-details/finicity-and-fiserv-offer-more-consumer-choice-through-secure.
---------------------------------------------------------------------------
The CFPB requested information related to the developer interfaces
offered by core banking providers and other vendors and how such
interfaces are priced. The CFPB received several comments on the costs
associated with the contracted services approach. Several banks and
credit unions confirmed that depository institutions will depend on
core banking providers to obtain the necessary functionality. A credit
union trade association and two banks asserted that these core
providers are likely to charge additional fees to provide these
services. A credit union suggested that an API could cost between
$50,000 and $125,000 from a core provider. A bank commented that they
may also incur associated personnel costs but did not provide
additional information on the magnitude of the costs. A credit union
asserted that, if a depository institution is required to switch to a
new core provider to obtain a developer interface, the waiting period
to switch is about two years and thus the depository would not be able
to comply by the mandatory compliance dates. Another credit union,
however, commented that core providers would be implementing solutions
for all depositories and, thus, expects costs per data provider to be
manageable. Similarly, a consumer advocate commented that they expect
industry utilities and cloud providers could keep costs manageable.
Finally, a service provider for credit unions commented that the CFPB
did not gather enough input from core providers in estimating these
costs.
The CFPB acknowledges that core providers may charge data providers
to provide the required functionality. The CFPB developed its cost
estimates in the proposal based in part on feedback from small entity
representatives received through the SBREFA process, and considers the
information provided by commenters about core providers to be broadly
consistent with the CFPB's estimated costs. Furthermore, the
[[Page 90961]]
commenters most concerned about the costs of contracting with core
providers to enable the required third party access were small
depository institutions that will not be required to comply with the
data provider requirements of this final rule.
Under the in-house approach, data providers would primarily employ
software developers or similar staff to build and operate the necessary
functionality. The estimates below are based on a fully in-house
approach for developing of a compliant developer interface. Some data
providers may instead contract with software providers for the initial
development of their in-house developer interface. The CFPB anticipates
that data providers would purchase their systems only if they could do
so at a lower cost than the estimate of building a compliant interface
provided here.
The CFPB expects that most data providers that have already
developed and have been maintaining consumer interfaces in-house would
also develop and maintain the required developer functionality in-
house.\150\ In the proposal, the CFPB estimated that for smaller data
providers, developing a compliant interface for third party access
would likely require between 2,600 and 5,200 hours of work by software
developers or similar staff, equivalent to five full-time employees
over a period of three to six months, resulting in an estimated total
upfront staffing cost of $237,000 to $475,000, which the CFPB has
updated to $247,000 to $494,000 for the final rule based on more recent
labor cost data.\151\ However, these estimates strongly depend on the
needs and capabilities of specific entities. For example, based on
feedback from nondepository small entity representatives, the CFPB
estimated in the proposal that nondepository data providers may require
only 480 hours of work by software developers at a total cost of
$44,000, which the CFPB has updated to $46,000 based on more recent
labor cost data.\152\
---------------------------------------------------------------------------
\150\ As discussed below, large depository data providers have
generally indicated that the resources required to maintain the
required third party access in-house are a small fraction of the
resources required to maintain consumer interfaces in-house.
Therefore, the CFPB expects that data providers that have already
invested in the capacity to operate a consumer interface in-house
will take a similar approach to providing the required third party
access. However, it is likely that some data providers will find it
less costly to contract with service providers. As the industry
develops, it is possible that it will become more common for data
providers to enable third party access through service providers.
\151\ This estimate was derived from BLS data showing a mean
hourly wage for software developers of $66.40. BLS data also show
that wages account for 70 percent of total compensation for private
industry workers, leading to a $94.86 estimate for total hourly
compensation, which was multiplied by the expected total number of
hours of work required.
\152\ Costs for depository and nondepository data providers are
likely to differ for several reasons, including that depository data
providers are generally more likely to have multiple legacy
information technology systems that are more technically difficult
to integrate with a developer interface.
---------------------------------------------------------------------------
In addition to these upfront costs, the CFPB estimated that data
providers taking the in-house approach would incur ongoing costs. In
the proposal, the CFPB estimated that small data providers (both
depository and nondepository) would incur ongoing annual technology
costs of $20,000 as well as ongoing staffing costs of $45,000 to
$91,000, which the CFPB has updated to $48,000 to $95,000 based on more
recent labor cost data.\153\ Under the final rule, small depositories
will not have costs for complying with the data provider requirements
of the rule. For medium-sized data providers with more accounts, the
CFPB estimated ongoing costs of $5 per account per year to maintain the
required functionality in-house, based on evidence from the Provider
Collection described below.
---------------------------------------------------------------------------
\153\ The CFPB estimates that small data providers choosing the
in-house approach would require 500 to 1,000 hours per year of staff
time by software developers. BLS data from May 2023 shows a mean
hourly wage for software developers of $66.40. BLS data also show
that wages account for 70 percent of total compensation for private
industry workers, leading to a $94.86 estimate for total hourly
compensation, which was multiplied by the expected total number of
hours of work required.
---------------------------------------------------------------------------
The Provider Collection contains information on costs for a sample
of large depository data providers. This complements the information on
costs for small data providers gathered through the SBREFA process. For
context, data provider small entity representatives generally may have
up to a few tens of thousands of accounts, while data providers in the
Provider Collection have millions of accounts.
In the Provider Collection, several data providers stated that it
was difficult to disaggregate the costs of developer interfaces from
their consumer interfaces and other information technology systems.
These data providers also generally provided estimates of ongoing
annual costs or total costs since the deployment of their developer
interfaces, rather than upfront costs to build an interface. Reported
estimates of the cost of establishing and maintaining a developer
interface varied widely, from $2 million to $47 million per year, with
a median of $21 million per year. Of the data providers providing
disaggregated estimates, the median cost of developer interfaces as a
share of the cost of their consumer interfaces was 2.3 percent. An
additional data provider did not provide a disaggregated estimate but
reported their developer interface constituted a ``small portion of the
total consumer-portal costs.''
These data providers are larger and more complex than most data
providers. Therefore, the CFPB adopts the cost of a compliant developer
interface per account as the relevant metric for estimating the costs
for data providers generally. The reported cost of an in-house
developer interface per customer or account ranges from $0.25 to $8 per
year, with a median of $3.37 per year, substantially lower than the $24
per year reported by small entity representatives as the potential cost
for the contracted services approach. Within the sample, the per
account cost generally declined as the number of accounts
increased.\154\ Based on this evidence, the CFPB estimates that annual
costs per account to maintain an in-house developer interface are
likely to be approximately $3 for large depository data providers and
$5 for medium-sized depository data providers. Although the Provider
Collection sample is relatively limited, the pattern of per-account
costs declining with the number of accounts suggests that--relative to
the alternative of contracting for a developer interface--data
providers developing and maintaining interfaces in-house likely have
larger upfront fixed costs but smaller ongoing per account costs. These
estimated costs are generally for depository institutions rather than
nondepositories. Given feedback from small entity representatives of
nondepository institutions that would qualify as data providers under
the rule, the CFPB expects that nondepository data providers would
generally have less need to integrate across multiple systems and would
be less likely to have legacy software that is difficult to update,
resulting in lower costs on average.
---------------------------------------------------------------------------
\154\ For the data providers in the Provider Collection that
provided both cost estimates and numbers of accounts, there was a
negative correlation coefficient of approximately -0.6 between per
account costs and number of accounts.
---------------------------------------------------------------------------
The estimates above relate to the costs of developing and
maintaining a developer interface for data providers without such
existing interfaces. Covered data providers with existing developer
interfaces that are not fully compliant with the proposed rule would
incur smaller costs to modify their interfaces and existing third party
access agreements to align with the
[[Page 90962]]
requirements of the rule. The cost for such covered data providers
would depend on the extent to which their developer interfaces do not
comply with the requirements of the proposed rule. Without granular
data on the nature of partially compliant interfaces, the CFPB cannot
provide a precise estimate of the cost of bringing such systems into
compliance with the rule. However, that cost will generally be a
fraction of the cost of developing and maintaining a new interface.
In the proposal, the CFPB sought comment or additional data on the
costs associated with modifying an existing developer interface or
establishing a new compliant developer interface, including how those
costs compare to contracting with a service provider. Many community
banks, credit unions, and related trade associations commented that
they expect the costs of the required functionality to be much higher
for small depository institutions than those estimated by the CFPB.
These commenters did not provide additional data or information that
would allow the CFPB to precisely update the costs for small
depositories estimated in the proposal. The CFPB acknowledges that
small depository institutions may have faced additional challenges to
implement the rule at this time and is not requiring small depository
institutions to comply with the final rule's requirements on data
providers. Accordingly, the CFPB has not updated the estimates for
small depository institution data providers.
Several banks, credit unions, and their respective trade
associations asserted that the CFPB underestimated compliance costs for
data providers, failed to consider all costs, and underestimated the
technical challenges associated with the proposal. A bank and a credit
union asserted that the incremental costs associated with the increased
number of data requests will not be minimal on a per-account basis. A
credit union and several credit union trade associations asserted that
the CFPB's per-account cost estimates were not appropriate for smaller
depository institutions because those estimates were primarily derived
from information provided by large data providers. These commenters
generally did not provide additional data or information that the CFPB
could use to modify the cost estimates and instead requested additional
study before finalizing the rule. One bank requested that the CFPB
estimate expected transaction volumes, customer service staffing, IT
systems and security protocols, and how these may depend on the size of
the data provider.
The CFPB acknowledges that some data providers may incur larger
costs than those discussed in this section. The costs associated with
implementing the rule will be data provider-specific and the estimated
costs discussed here should be considered the average expected costs
for a data provider. Had small depositories been required to comply
with the final rule's requirements on data providers, the CFPB
acknowledges that they may have faced higher or more uncertain costs
than discussed here to comply with the final rule. The CFPB has
considered the information from the comments, together with the
Provider Collection and SBREFA panel, and has determined that the
estimates discussed in this section are appropriate for the data
providers that are covered by the rule.
Commenters representing bank trade associations stated that some
data providers would incur significant costs to comply with the rule,
even if they already have an existing interface for third party access.
Several bank trade associations noted that banks have already spent
hundreds of hours assessing compliance and designing potential
solutions and modifications that may be needed to comply with the rule.
One trade association asserted that the rule could cost as much as $100
million in the first year and an additional $15 million each year to
update and maintain a compliant developer interface, although the trade
association did not specify how they obtained these estimates. The CFPB
acknowledges that data providers that already have a third party
interface may incur costs to update and maintain that interface to
comply with the rule and notes that $15 million in annual ongoing costs
is consistent with the CFPB's estimates for large data providers with
millions of accounts. However, given the information contained in the
comment, the CFPB considers the magnitude of the provided estimate of
costs for the first year to be overstated, particularly given the
rule's extended compliance timelines for large data providers relative
to the proposal.
A bank commented that the CFPB failed to account for compliance
costs of reviewing requests and monitoring consumer authorizations. In
this analysis, these costs are accounted for in the ongoing costs
associated with maintaining a developer interface, but the CFPB
acknowledges that some data providers may incur higher levels of cost
than others.
Two credit unions commented that the CFPB underestimated costs of
the revocation mechanism. Data providers are permitted but not required
to offer a developer interface that lets consumers revoke third party
access. The CFPB does not include costs associated with an optional
feature.
Many data providers and SBA Advocacy commented that the lack of
clarity on what the proposal had referred to as a ``qualified industry
standard'' would create confusion and increase compliance costs,
particularly for smaller data providers, and requested additional
guidelines for the consensus standards and standard-setting bodies. As
discussed in part II.C, the Industry Standard-Setting Final Rule
finalized in June 2024 specifies the attributes standard-setting bodies
must satisfy to receive CFPB recognition as a recognized standard
setter capable of adopting consensus standards (referred to under the
proposal as a qualified industry standard). Under the final rule,
conformance with consensus standards serve as indicia of compliance for
various provisions of the final rule. The CFPB has determined that the
Industry Standard-Setting Final Rule and the references to consensus
standards in this rule will mitigate the cost concerns of these
commenters (assuming the consensus standards comply with the final
rule), particularly given the extended compliance timelines in the
final rule.
Developing and Implementing Policies and Procedures
The rule includes disclosure and recordkeeping requirements for all
covered data providers related to consumer-authorized data access. The
rule requires data providers to calculate and disclose the response
rate for third party data access on a monthly basis. The CFPB
understands that a variety of performance metrics, including the
response rate, may be calculated in the normal course of operating an
API or other digital interface for diagnostic purposes. Therefore, the
cost of this provision is included in the cost of developing and
maintaining a compliant developer interface estimated above. Data
providers may incur an additional upfront cost of developing and
testing a system to regularly disclose required performance metrics on
their website. The CFPB estimates that this process would take less
than 80 hours of staff time at an estimated cost of $7,600 per data
provider.\155\ The CFPB expects that
[[Page 90963]]
once the disclosure system is implemented it would be maintained at
minimal incremental cost as part of the overall cost of operating data
providers' websites.
---------------------------------------------------------------------------
\155\ This estimate was derived from BLS data showing a mean
hourly wage for software developers of $66.40. BLS data also show
that wages account for 70 percent of total compensation for private
industry workers, leading to a $94.86 estimate for total hourly
compensation, which was multiplied by the expected total number of
hours of work required.
---------------------------------------------------------------------------
The rule requires data providers to have policies and procedures
such that the developer interface is reasonably designed to ensure that
data are accurately transferred to third parties. The CFPB expects that
data providers would comply with this requirement as part of
establishing and maintaining a compliant developer interface.
Therefore, the costs of ensuring that the developer interface is
reasonably designed to transfer data accurately are included in the
analysis above.
The rule also requires data providers to have policies and
procedures reasonably designed to ensure that the reason for the
decision to decline a third party's request to access its interface is
communicated to the third party. The requirements to inform third
parties when and why access was not permitted would generally be
satisfied as part of the onboarding process in cases of reasonable
denials related to risk management or built into a data provider's
developer interface, as automated responses to third party data access
requests. Similarly, the requirements to retain records to demonstrate
compliance with certain requirements of the proposal would generally be
built into a data provider's developer interface. As a result, the CFPB
considers the costs of complying with these requirements as part of the
overall costs of the onboarding process or implementing a compliant
developer interface, as described elsewhere. The CFPB has previously
estimated that, to comply with a rule of similar complexity, a data
provider will require several categories of one-time costs.\156\ The
CFPB has added several categories of one-time costs relative to the
proposal in response to the comments discussed below. The CFPB has also
adjusted the estimates to account for inflation. Each covered data
provider is expected to incur the following costs: $9,000 to $25,000
for preparation and planning; $3,100 to $5,200 for developing policies
and procedures; $3,700 to $8,900 for legal and compliance review;
$3,900 to $5,600 for developing forms and disclosures; and $3,800 to
$6,500 for training staff and vendors on the new policies and
procedures.\157\ The CFPB estimates a total one-time cost of developing
and implementing policies and procedures as required by the proposed
rule of $23,500 to $51,200 per data provider.
---------------------------------------------------------------------------
\156\ 88 FR 35150, 35497 (May 31, 2023).
\157\ Id. at 35150.
---------------------------------------------------------------------------
A nondepository entity trade association commented that the
proposal's cost estimates for updating policies and procedures were too
low. A bank requested that the CFPB determine the costs associated with
developing disclosures and account agreement changes. The CFPB has
adjusted the costs associated with developing policies, procedures,
disclosures, and agreements in the final rule. A bank commented that it
was not practical to provide some information, such as terms and
conditions, in a machine-readable format. As discussed in part IV.C.2.,
the rule does not apply the machine-readability requirements to terms
and conditions and some other consumer information provided through the
consumer interface. However, the CFPB has determined that it is
necessary to make that information available in a machine-readable form
through the developer interface.
Two trade associations for depositories asserted that the proposed
record retention requirements for data providers would require
providers to keep track of, and report on, all data collected about
consumers, which would create large costs. The rule does not require
that data providers keep records about all data collected about
consumers. Instead, the rule requires that data providers retain
records related to third party requests for access to its interface,
requests for information, third party authorizations, revocation
requests made through the data provider, and performance
specifications, as discussed in part IV.C.7. Additionally, some bank
commenters suggested a shorter retention period than three years for
information related to data accessed through the developer interface,
though at least one bank trade association commenter supported the
three-year retention period. The CFPB has determined that the record
retention requirements will provide the data necessary to facilitate
effective supervision and enforcement of compliance with the rule.
Indirect Costs
In addition to the direct costs described above, data providers are
likely to incur indirect costs as a result of the rule. The CFPB
expects costs related to onboarding additional third parties relative
to baseline as well as changes in the frequency, scope, or method of
consumer-authorized data access relative to the baseline. These changes
may have secondary effects on the profitability of certain business
models or practices, including by facilitating competition and enabling
new products and services.
Costs From Onboarding Additional Third Parties
The rule generally requires data providers to grant access to their
developer interface, except for reasonable denials related to risk
management or the absence of certain information about themselves.
Although the rule does not require formal data access agreements, the
CFPB expects the rule to lead to more third parties requesting and
being granted access to data providers' developer interfaces relative
to the baseline. The CFPB expects that this is likely to require data
providers to enter into more onboarding arrangements with third
parties. In the Aggregator Collection responses, which reflect costs
applicable under the baseline, aggregators reported that negotiating a
data access agreement with a data provider could take between 50 and
4,950 staff hours for business relationship managers, software
developers, lawyers, compliance professionals, and senior management,
depending on the complexity of the negotiation. The median estimated
time was 385 staff hours per agreement. The CFPB expects that data
providers currently spend roughly equivalent time and resources
negotiating and signing data access agreements at baseline.
These costs are likely to decrease under the rule relative to the
baseline because many features of interface onboarding arrangements are
now regulated by the rule and not subject to negotiation, including
requirements for interface reliability, fees, the scope of data
accessible via the interface, authorization procedures, and the
duration of access to consumers' covered data. One firm in the
Aggregator Collection stated that in cases where data providers agree
to use existing industry-defined standards there is essentially no need
for negotiation. The CFPB expects that under the rule nearly all data
providers will use standardized onboarding arrangements and the costs
of establishing data access will generally be limited to ensuring third
party risk management standards are satisfied and performing any
administrative tasks to provide third parties with access to the
developer interface. In the proposal, the CFPB estimated that this
process would require 80 staff hours on average, representing
approximately $6,800. These costs may be further reduced if industry
accreditations or consensus standards develop to streamline data
providers' required efforts on third party risk management, or to the
extent that
[[Page 90964]]
prudential regulators provide further guidance applicable to sound risk
management in the specific context of consumer-authorized data access.
While some data providers and third parties may choose to use a
customized arrangement that respects the terms of the rule, they will
generally only do so when both parties perceive that the benefits
exceed the costs. Because the choice to negotiate a costly but more
customized arrangement is a business decision not required by the rule,
the additional costs of doing so are voluntarily acceded to and are
generally outside the scope of this analysis.\158\
---------------------------------------------------------------------------
\158\ To the extent that data providers choose to voluntarily
enter into additional customized arrangements in response to the
rule, the CFPB expects the benefits to data providers of such
arrangements to exceed any additional upfront costs from
establishing the arrangements.
---------------------------------------------------------------------------
The total cost of entering into onboarding arrangements will depend
on the difference between the number of agreements that would be
negotiated under the baseline and the number of onboarding arrangements
that would be entered into under the rule. Because the consumer-
authorized data access system is developing rapidly, it is not possible
to precisely estimate the number of additional connections that would
be established by the rule. However, in the near term, the CFPB
anticipates that most data providers will continue to provide third
parties access to consumer-authorized data through specialized
intermediaries like data aggregators, as they would have under the
baseline. As a result, the CFPB estimated in the proposal that, on
average, large data providers would need to enter into 10 or fewer
additional onboarding arrangements in the years immediately following
implementation of the rule, at a maximum cost of $68,000 per large data
provider.\159\ In contrast, medium sized entities are likely to rely on
core banking providers or other vendors to facilitate onboarding on
their behalf at minimal incremental cost. Over time, data providers are
likely to enter into additional onboarding arrangements due to entry by
new third parties and other changes in the market.\160\
---------------------------------------------------------------------------
\159\ This estimate was derived from the $6,800 estimate from
the proposal for the cost of establishing a data access agreement
multiplied by the up to 10 additional agreements that may need to be
established due to the rule.
\160\ For example, this final rule and the Industry Standard-
Setting Final Rule aim to accelerate the development and adoption of
consensus standards covering myriad aspects of open banking. This
would likely reduce the frictions and costs associated with
establishing and maintaining connections between data providers and
third parties, potentially increasing the number of access
agreements negotiated by data providers but reducing the costs of
each agreement.
---------------------------------------------------------------------------
The CFPB requested comment on how the proposed rule would change
both the cost of onboarding third parties and the number of data access
arrangements between data providers and third parties. A bank, a credit
union, and two research institutes commented that the costs to vet
third parties will be substantial, with the bank and credit union
further asserting the CFPB has underestimated those costs. A
nondepository entity trade association commented that there will be an
increase in costs stemming from the increase in the number of data
agreements caused by the rule. Another credit union asserted that small
credit unions do not have the necessary legal resources to vet third
parties. Two banks asserted that the CFPB underestimated the costs of
negotiating connection agreements. In contrast, a data aggregator
estimated that the rule will reduce the cost of these agreements by at
least 30 percent.
The CFPB acknowledges that data providers may incur costs
associated with vetting third parties but expects that consensus
standards will eventually develop around the rule's requirements and
the ways that third parties can demonstrate compliance, which will
mitigate costs for data providers by putting the onus on third parties
to show they are credible and secure. Furthermore, the CFPB expects
that data aggregators will continue to act as intermediaries between
data providers and third parties over the short to medium term, which
will reduce the costs to data providers of onboarding additional third
parties to compliant developer interfaces. However, based on the
information provided by commenters, the CFPB is increasing its estimate
of the number of hours required to finalize an onboarding arrangement
from 80 hours to 120 hours on average, representing an average cost per
agreement of $10,800.\161\ Given the CFPB's expectation that large data
providers would need to enter into 10 or fewer additional onboarding
arrangements in the years immediately following implementation of the
rule, the CFPB estimates a maximum cost of $108,000 per large data
provider.\162\
---------------------------------------------------------------------------
\161\ This estimate was derived from BLS data showing a mean
hourly wage for compliance officers ($38.55), general and operations
managers ($62.18), lawyers ($84.84), and software developers
($66.40), for an average hourly wage of $62.99. BLS data also show
that wages account for 70 percent of total compensation for private
industry workers, leading to an $89.99 estimate for total hourly
compensation, which was multiplied by the expected total number of
hours of work required.
\162\ This estimate was derived from the $10,800 estimate for
the cost of establishing a data access agreement multiplied by the
up to 10 additional agreements that may need to be established due
to the rule.
---------------------------------------------------------------------------
Prohibition on Fees for Access
The rule does not permit data providers to charge fees for access
to covered data through their interfaces. To the limited extent that
data providers are currently charging such fees, the rule would
eliminate these revenues. Based on the Aggregator Collection, the
Provider Collection, and its market research, the CFPB understands that
fees for consumer and third party access are currently rare.
The CFPB understands that third parties have in some cases made
payments to data providers to incentivize data providers that are
reluctant or unable to provide a developer interface of sufficient
quality sufficiently quickly. While rare in the current market, the
rule eliminates such fees that might have been charged in the future
under the baseline.
The CFPB does not have representative data on the prevalence or
size of payments to data providers and therefore cannot precisely
estimate the cost of eliminating them. However, as described above, the
information available to the CFPB indicates that few data providers
currently charge third parties for access and that the total cost to
data providers of eliminating such charges would be minimal.
The CFPB received many comments on the costs associated with the
prohibition of fees. Many banks, credit unions, and bank or credit
union trade associations commented that the prohibition of fees means
that data providers will not be able to recoup the costs of complying
with the rule. One trade association and a bank asserted that the CFPB
has failed to fully consider the costs associated with a prohibition of
fees but did not provide additional information upon which to base
updated estimates. SBA Advocacy suggested that the CFPB could allow
small entities to charge fees to recoup costs.
The CFPB acknowledges that covered data providers that would charge
fees for receiving requests or making available consumer-authorized
covered data to third parties under the baseline will not be able to do
so under the rule, including to establish or maintain interfaces
required under the rule. The prohibition on fees for data access would
be costly for such covered data providers. The information available to
the CFPB indicates that few, if any, covered data providers currently
charge these fees or would charge these fees in the future under the
baseline.
[[Page 90965]]
The CFPB acknowledges that covered data providers will incur costs
associated with the rule and may seek new sources of revenue to offset
those costs. The prohibition on fees for data access forecloses one
possible new source of revenue. However, to the extent that covered
data providers would charge these fees in order to pass some compliance
costs through to other market participants, these costs are
appropriately accounted for in the discussion of these costs. Under an
alternative where there is no fee prohibition, some covered data
providers would likely require third parties or consumers to pay fees
in order to access consumer-authorized covered data. As few, if any,
covered data providers currently charge these fees, the CFPB cannot
anticipate with certainty how common fees would be if permitted, which
data providers would be most likely to charge fees, or how these fees
would be set in equilibrium. In general, covered data providers would
benefit from the option to charge fees. If fees were charged directly
to consumers, consumers would incur the cost of paying the fees or the
cost of forgoing the benefits of products and services enabled by
consumer-authorized covered data. To the extent that consumers would
not exercise their right to access their covered data due to fees,
third parties would also incur costs related to a smaller potential
market for their products and services. If fees were instead charged to
third parties, third parties would incur the direct cost of paying the
fees. Third parties would likely pass through some of those fees on to
consumers. Depending on how they were structured, fees would change
third parties' incentives in ways that might limit consumers ability to
access third party products and services or degrade the quality of
products and services. For example, if data providers charged fees
based on the number of consumer accounts accessed, third parties would
have an incentive to deter or deny less profitable consumers from using
their product or service. As another example, if data providers charged
fees for each access attempt, third parties would have an incentive to
reduce the frequency with which they update consumer-authorized covered
data, which would diminish the benefits to consumers of products and
services that rely on real-time consumer data.
As discussed in part IV.C.2, the CFPB considered allowing fees for
data access, but determined that the potential for data providers to
set fees that are not reasonable and that inhibit consumers' access
posed too great of a risk to the benefits of the rule as a whole.
Further, small depositories, the institutions currently least able to
absorb these costs and therefore potentially most likely to seek to
offset them with new fees, are not required to comply with the rule's
requirements on data providers.
More Frequent Access by Third Parties
Based on responses to the Provider Collection, the CFPB is aware
that covered data providers sometimes impose access caps, such as
limiting the number of allowable data requests or the frequency with
which authorized third parties can access consumer data. For example,
the CFPB is aware that some data providers cap the number of data
requests per day per connection. The CFPB understands that in some
cases access caps prevent third parties from accessing consumer data as
often as is reasonably necessary to provide the requested service. For
example, one firm in the Aggregator Collection reported spending
``significant resources'' to manage its traffic in order to avoid
access cap limits. Another firm in the Aggregator Collection reported
spending resources to persuade large financial institutions to raise or
eliminate access caps. Therefore, the prohibition on unreasonably
limiting the frequency of third party requests for covered data or
delaying responses to those requests is likely to increase total data
requests for some covered data providers and may therefore increase
digital infrastructure costs for those data providers relative to the
baseline.\163\ This increase is likely to be larger for data providers
with more restrictive access caps at baseline, if such access caps are
not reasonable under the rule. The CFPB expects that for most data
providers, any increase in traffic due to such increases in the number
of data requests will generally be more than offset by declines in
screen scraping, which the CFPB understands to typically involve
heavier traffic loads per request than requests through a developer
interface. A small number of large data providers have already
restricted screen scraping under the baseline and may experience net
increases in developer interface traffic.
---------------------------------------------------------------------------
\163\ As discussed in the section on Benefits to data providers
in part VI.E.3, other features of the proposed rule are likely to
decrease the frequency and scope of data requests and therefore
digital infrastructure costs for covered data providers.
---------------------------------------------------------------------------
A bank trade association commented that a lack of access caps for
developer interfaces would increase compliance costs and potentially
degrade interface performance. As discussed in part IV.C.3., the CFPB
has determined that data providers are permitted to impose reasonable
access caps, to ensure that requests from one authorized third party do
not unduly burden the data provider's developer interface. Given this
determination, the CFPB expects that incremental costs from any
increased data requests are likely to be minimal on a per-account
basis.
Reduced Information Advantages
Through their role in providing financial products and services,
data providers possess ``first party'' data on the accounts held by
their customers. These data are a valuable source of information for
data providers in developing, pricing, and marketing products and
services, but authorized data access may reduce this information
advantage. The CFPB expects that the rule will generally increase third
party access relative to the baseline and thus diminish data providers'
informational advantages from first party data. This may enable third
parties to more effectively compete with products or services offered
by data providers, potentially limiting the prices data providers can
charge for their own products and services or reducing data providers'
market shares or data providers' profits. For example, the CFPB
understands that an important use case for consumer-authorized
financial data is transaction-based underwriting. At baseline, many
data providers sell credit products to their depositors. To the extent
that the rule facilitates entry into the lending market or improves the
quality of the products and services offered by nondepository lenders
or other depository lenders that use consumer-authorized data, data
providers that enjoyed informational advantages relative to their peers
may lose market share and therefore profits. As another example,
consumer-authorized data sharing is likely to facilitate faster new
account openings. As it becomes easier for consumers to compare account
terms, transfer recurring payments, move funds, and have their identity
verified, depository data providers may face pressure to pay higher
deposit rates or make costly investments in service quality in order to
retain deposits, as discussed in the section on Benefits to consumers
in part VI.E.4.
In general, accurately predicting how changes in the availability
of consumer-authorized financial data will change the structure of the
market for consumer financial services or how changes in market
structure will impact the profitability of individual firms or
industries is very difficult, in large part because firms that are data
providers in some cases also operate as third parties accessing data
from other data
[[Page 90966]]
providers, and the CFPB expects more data providers to act as third
parties over time. As a result, the CFPB is not able to quantify the
impacts of reduced informational advantages that stem from the
proposal.
The rule is likely to increase the quality of services that use
consumer-authorized financial data to facilitate competition, including
by comparing or recommending products or services to consumers. This
may impact data providers. For example, a consumer might use a
comparison shopping service that would recommend credit cards likely to
minimize their costs from interest and fees or maximize their benefits
from rewards programs given their historical spending patterns. The
CFPB is not able to accurately predict how many firms would develop
services that facilitate competition in this way, how many consumers
would use such services, or how the availability of such services would
impact individual firms or industries.
Many data providers and bank or credit union trade associations
expressed concern that the rule would advantage third parties at the
expense of data providers. A credit union trade association asserted
that the CFPB did not properly assess the risks from the growth of non-
bank lenders.
The CFPB notes that data providers may also act as third parties.
Furthermore, the rule places substantial restrictions on how third
parties can use and retain these data, relative to the baseline of
screen scraping and no restrictions on the use or retention of the
data. The CFPB acknowledges that there may be growth in nondepository
lending but has determined that the rule's restrictions and existing
regulations that apply to nondepository lenders under the baseline will
mitigate the risks associated with this growth.
Potential Costs Related to Liability or Fraud
Several data providers and bank or credit union trade associations
commented on the high costs of resolving disputes, dealing with third
parties lacking appropriate security, and the costs of liability
falling disproportionately on data providers. Two credit union trade
associations expressed concern that, even when a third party is
responsible for a data breach, data providers will face reputational
risk, losses due to fraud, and costs to resolve the breach. The SBA
Office of Advocacy commented that the lack of clarity in the rule
regarding liability could lead to confusion and expensive litigation. A
few data providers and a bank trade association asserted that the CFPB
did not fully account for the costs associated with security breaches
and liability. A few bank trade associations and data providers
asserted that the absence of a ban on screen scraping will create costs
for data providers to block screen scraping. The CFPB notes that these
risks exist under the baseline and are likely worse in the current
marketplace, as discussed in the Benefits to data providers part,
because of the widespread storage of credentials, the lack of rules on
data retention, and downstream data sharing or sales by third parties.
A credit union commented that they have already spent resources on
increasing security and blocking screen scraping under the baseline.
The CFPB expects that the allowance for reasonable denials in the rule
and the role of consensus standards related to third party data
security will also mitigate these risks by allowing data providers to
deny access for third parties that have not established sufficient
security protocols. The CFPB acknowledges that some institutions,
especially those without developer interfaces, may face higher costs to
develop and maintain data security systems, but the CFPB expects that
the majority of data providers will see a net decrease in fraud risks
and reputational risks relative to the baseline with widespread screen
scraping and no restrictions on data collection, retention, and use.
Potential Costs From Increased Account Switching
In general, consumers prefer financial institutions that provide
better prices or customer experiences. As discussed in the section on
Effects of increased data sharing on innovation and competition in part
VI.E.4, the CFPB expects that the rule will improve consumers' ability
to switch financial institutions. As a result, financial institutions
that offer covered products with less competitive prices and customer
experiences may lose market share due to the rule. In addition, if
greater competition on price leads to lower margins on covered
accounts, profits for data providers that lower their margins in
response to the rule will be decreased.
Costs to Third Parties
Third parties accessing data under the rule will be required to
modify existing procedures, so they are consistent with the proposal's
authorization procedures for accessing covered data on behalf of a
consumer, such as providing the authorization disclosure; implementing
the limitations on data collection, use, and retention; developing
mechanisms for revocation of authorization; providing the annual
reauthorization of access; and executing record retention requirements.
In addition to these upfront and ongoing compliance costs, the rule may
impose further costs on third parties through the transition away from
screen scraping access, increased data interface onboarding costs with
data aggregators and data providers, restrictions on data use and
retention. Potential effects of the new financial data processing
products or services definition are also discussed.
Implementing Mechanisms for Data Deletion and Record Retention
The rule requires third parties to establish and maintain systems
that receive data access revocation requests, track duration-limited
authorizations, and delete data when required due to revoked
authorizations, durational periods ending, or because retaining the
data is no longer reasonably necessary. Third parties will also need to
retain records as required by the rule. Many of these requirements
overlap with the requirements of other State or international data
privacy laws. For example, third parties that operate in the State of
California and have gross annual revenues greater than $25 million may
already have similar systems if they are subject to the California
Consumer Privacy Act (CCPA),\164\ which requires that businesses delete
consumer personal data upon consumer request. Though many State privacy
laws exclude businesses or data covered by the GLBA, third parties that
are regulated by State privacy laws may need to modify their systems,
incorporate authorization duration limits, and process more revocation
requests, but they will likely have lower costs than third parties that
must establish such a system from scratch. The CFPB estimated in the
SBREFA Panel Report, and described in the proposal, that establishing
and maintaining an appropriate data system would cost up to $75,000
based on analysis of the Standardized Regulatory Impact Assessment for
the CCPA.\165\
[[Page 90967]]
The CFPB understands that some third parties already retain records
related to consumer data access requests. The rule will require third
parties to retain records that demonstrate compliance with the rule,
including a copy of the authorization disclosure and, if a data
aggregator accessed consumer-authorized data, a copy of the
certification statement. The CFPB expects that the costs of
implementing record retention requirements would be small relative to
the costs of implementing deletion requirements.
---------------------------------------------------------------------------
\164\ Cal. Civ. Code section 1798.198(a) (2018).
\165\ The Standardized Regulatory Impact Assessment for the CCPA
estimated that the average technology cost would be $75,000.
However, the CFPB estimates that the cost for many third parties
would be lower, as the CCPA figure was based on a survey of the top
one percent of California businesses by size (those with more than
500 employees), and the CCPA has more requirements than the proposed
rule. See Off. of the Att'y Gen., Cal. Dep't of Just., Standardized
Regulatory Impact Assessment: California Consumer Privacy Act of
2018 Regulations (Aug. 2019), https://dof.ca.gov/wp-content/uploads/sites/352/Forecasting/Economics/Documents/CCPA_Regulations-SRIA-DOF.pdf.
---------------------------------------------------------------------------
As described in the SBREFA Panel Report, several small entity
representatives provided cost estimates of implementing data retention
limits. At the low end, one third party small entity representative
that had implemented de-identification and deletion systems stated that
it took between 240 and 480 hours of staff time,\166\ and another third
party small entity representative stated that it developed a system to
comply with the CCPA in about 480 hours. At the high end, one third
party small entity representative estimated that building a system to
comply with retention limits would take 1,000 hours. If a third party
chose not to establish a system to implement the retention limits of
the rule and instead chose to manually delete data to comply with the
retention limits, the CFPB understands that the time cost would be
substantially higher: one third party small entity representative
explained that, as an organization of fewer than 50 people, complying
with a single deletion request could require 480 hours. Based on this
feedback, the CFPB estimates that the one-time cost of implementing
data retention limits and retaining relevant records will be between
$22,800 and $94,900.\167\ The three-year record retention requirement
of the rule will impose limited additional electronic storage costs
annually.
---------------------------------------------------------------------------
\166\ The small entity representative reported that the task
took its team two to four weeks. Based on other small entity
representative team sizes, the CFPB assumes that the team included
three people.
\167\ The CFPB assumes that implementing deletion requirements
would require between 240 and 1,000 hours of work by a software
developer. The cost estimate was derived from BLS data showing a
mean hourly wage for software developers of $66.40. BLS data also
show that wages account for 70 percent of total compensation for
private industry workers, leading to a $94.86 estimate for total
hourly compensation.
---------------------------------------------------------------------------
One nondepository entity trade association commented that record
retention requirements on third parties will impose far higher annual
costs than estimated in the proposed rule, especially for smaller
entities. The CFPB requested additional data or other information to
further refine its estimates but did not receive cost estimates
specific to revocation of authorization systems, implementing data
retention limits, or record retention. The CFPB expects that the cost
will be lower for third parties that already comply with existing data
privacy laws. Third parties that do not retain any consumer-authorized
data will be unaffected by data retention limits but will still need to
follow record retention policies under the rule. The CFPB has
determined that these record retention requirements are necessary to
ensure compliance with the other components of the rule.
Annual Reauthorization Process
The rule limits the duration of third party collection of covered
data to no more than one year after a consumer's most recent
authorization. Third parties will be required to obtain a new
authorization from the consumer before the first anniversary of the
consumer's most recent authorization to continue to collect the
consumer's covered data without disruption. Because this new
authorization will have the same legal requirements as the first
authorization, most of its implementation costs would be captured by
the costs described for the initial authorization and data retention
systems. The CFPB expects that reauthorization reminders will typically
be delivered electronically--such as a within-app notification or an
email--at minimal additional direct cost.
The reauthorization and retention limits may limit the quantity of
data available for product improvement or other permissible uses of
data. Some third parties may experience indirect costs due to service
disruptions if they do not obtain a new authorization from the consumer
before the anniversary of the consumer's most recent authorization, as
they would not be able to request the consumer's data from data
providers until the new authorization was obtained if more than one
year has passed since the most recent authorization. If the consumer
provides a new authorization after one year, any gaps in the scope of
data collected would likely be filled, as the third party could then
access two years of retrospective data.
The costs associated with the reauthorization requirement will
depend on the third party's business model. Two small entity
representatives suggested in the SBREFA process that periodic
reauthorization requirements on third parties could lead to reduced
customer retention. One small entity representative stated that this
would ``frustrate'' consumers, and another stated that only 0.32
percent of its users prompted to reconnect to their bank account ever
did so. A nondepository entity trade association commented that annual
reauthorization would limit the value of pay-by-bank use cases,
especially for recurring payments, and noted that card payments are not
subject to reauthorization requirements. However, the CFPB understands
that consumers are often required to reenter their card information for
reoccurring payments after a card is lost, stolen, or expired, so
consumers are not unfamiliar with reauthorizing payment methods.
Studies indicate that onerous reauthorization requirements have
impacted open banking usage and attrition in other countries.
Reauthorization requirements created friction for third parties in the
United Kingdom's open banking regime after the implementation of a 90-
day reauthorization requirement. One United Kingdom trade association
estimated an attrition rate between 20 percent and 40 percent, while
another trade association found an attrition rate between 35 percent
and 87 percent.\168\ These attrition rates are likely to be different
than those expected under the rule both because a 90-day
reauthorization requirement is more burdensome than an annual
reauthorization requirement and because more consumers may still be
actively using a product or service after 90 days than after one year.
The CFPB expects that, while some third parties would incur costs from
consumer attrition, third parties will be more likely to obtain a new
authorization from a consumer when that relationship is more valuable,
and the reauthorization process will be relatively easy for consumers
who wish to continue the relationship. These factors will generally
limit the cost of disruptions due to the reauthorization requirements,
particularly for third parties providing the most valuable services.
The CFPB does not have data to estimate the costs to third parties of
lost customers due to the annual reauthorization requirements.
---------------------------------------------------------------------------
\168\ See Fin. Conduct Auth., Changes to the SCA-RTS and to the
guidance in `Payment Services and Electronic Money--Our Approach'
and the Perimeter Guidance Manual (Nov. 2021), https://www.fca.org.uk/publication/policy/ps21-19.pdf.
---------------------------------------------------------------------------
Providing Authorization Disclosure and Certification Statement
The rule requires third parties to provide the authorization
disclosure and certification statement when seeking to access covered
data. When a
[[Page 90968]]
third party seeking authorization uses a data aggregator to assist with
accessing covered data on behalf of a consumer, the rule requires the
data aggregator to make its own certification statement to the
consumer, though both the aggregator and third party certifications
will be permitted to be made in the same disclosure. The CFPB expects
that some data aggregators will provide the required authorization
disclosure and certification statement on behalf of third parties
seeking authorization. However, some third parties seeking
authorization, including those that do not partner with data
aggregators, may instead provide the authorization disclosure and
certification statement through their own systems.
For data aggregators and other third parties that choose to provide
the authorization disclosure and certification statement through their
own systems, and have not previously provided any disclosure statements
to consumers, the CFPB estimates that building such a system would
require approximately 1,000 hours of work by software developers or
similar staff. This estimate is based on cost estimates in other
consumer financial markets related to requirements for tailored
disclosures provided at service initiation.\169\ The CFPB estimates
that this will result in a one-time cost for a third party of
$94,900.\170\ However, if third parties already provide disclosures at
authorization under the baseline, the costs of modifying these
disclosures to satisfy the proposal's requirements may be reduced. One
data aggregator stakeholder stated that modifying the content of its
existing disclosures would involve 30 to 40 hours of employee time,
representing an equivalent cost for a third party of between $2,900 and
$3,800.\171\
---------------------------------------------------------------------------
\169\ 82 FR 54472, 54823 (Nov. 17, 2017).
\170\ This estimate was derived from BLS data showing a mean
hourly wage for software developers of $66.40. BLS data also show
that wages account for 70 percent of total compensation for private
industry workers, leading to a $94.86 estimate for total hourly
compensation, which was multiplied by the expected total number of
hours of work required.
\171\ This estimate was derived from BLS data showing a mean
hourly wage for software developers of $66.40. BLS data also show
that wages account for 70 percent of total compensation for private
industry workers, leading to a $94.86 estimate for total hourly
compensation, which was multiplied by the expected total number of
hours of work required.
---------------------------------------------------------------------------
Data aggregators may pass through these costs to third parties that
contract with them. One data aggregator stated in its response to the
Aggregator Collection that disclosures for third parties that contract
with data aggregators would be largely uniform and easily adapted, and
the CFPB anticipates that this will be the case under the rule. The
CFPB does not have data to estimate these disclosure costs. However,
because data aggregators' disclosure costs would be spread across many
third parties, the CFPB expects the burden of these requirements on any
single third party that contracts with data aggregators to be small.
Policies and Procedures
To implement the requirements of the rule, third parties will need
to develop and maintain policies and procedures in several distinct
areas to ensure compliance with the rule. These include: applying
existing information security programs to their systems for the
collection, use, and retention of covered data; ensuring the accuracy
of the information that they collect; governing the limits on
collection, use, and retention of consumer-authorized information; and
record retention requirements. The CFPB understands that most
authorized third parties and data aggregators are currently subject to
the GLBA Safeguards Framework and so they already have policies and
procedures regarding information security programs and will have lower
costs for developing and maintaining similar requirements of the rule.
However, a small portion of third parties may need to develop new GLBA-
compliant systems and would face greater costs. In other consumer
financial markets, the CFPB has estimated that nondepository
institutions would face a one-time cost of $5,300 to develop new
policies and procedures and a one-time cost of $4,800 for a legal/
compliance review.\172\ Assuming comparable costs for the requirements
of the rule yields a total cost of roughly $10,100 for developing and
implementing policies and procedures. Maintaining these policies and
procedures once they are implemented is likely to involve limited
ongoing costs for third parties.\173\
---------------------------------------------------------------------------
\172\ Inflation-adjusted estimates from 88 FR 35150 (May 31,
2023).
\173\ SBREFA Panel Report at 12.
---------------------------------------------------------------------------
Transition Away From Screen Scraping
The CFPB expects that third parties may face costs from the
transition away from screen scraping. At baseline, screen scraping is a
frequently used method of accessing consumer data: in 2022, roughly
half of data access attempts by third parties in the Aggregator
Collection were made through screen scraping. However, the share of
access attempts made through screen scraping declined by approximately
one-third between 2019 and 2022. The CFPB expects that screen scraping
will continue to decline for non-covered financial products as data
providers and third parties generally transition to data access under
the terms of the rule. The CFPB expects that third parties will have
strong incentives to avoid using screen scraping to access covered data
from data providers that have compliant interfaces for third parties.
In the SBREFA process, multiple small entity representatives expressed
that the transition away from screen scraping would limit data
accessibility. Relative to the baseline, the CFPB does not expect the
transition away from screen scraping to negatively impact data
availability for most data fields. The CFPB expects that data providers
that provide third party access in compliance with rule requirements
will block screen scraping for covered accounts, so third parties may
not be able to access non-covered data fields from covered accounts.
The CFPB requested comment on any specific data fields that may be less
available due to the transition away from screen scraping, and the
specific impacts of those changes, but did not receive relevant
comments. The CFPB expects that the rule will not directly impact how
third parties access non-covered data.
At baseline, some third parties use screen scraping as a back-up
access method when other data access systems are inoperable. The need
for a back-up access method may be reduced under the rule because the
rule imposes performance requirements for third party access. However,
nondepository entity and researcher commenters expressed concern that
these requirements could still reduce the quality of information
provided and drive a market-wide race to the bottom, contending that
data providers would have little incentive to drive performance higher.
These commenters asserted that the proposal's performance requirements
might permit lower performance than in their extant data access
agreements with data providers. However, the rule would impose a
general reasonableness requirement in addition to minimum performance
requirements. Because data providers cannot only meet the minimum
performance requirements, and instead must additionally demonstrate
reasonable performance, indicia of which include performance comparable
to other data providers, the CFPB expects there would be upward
pressure on performance levels over time. Additionally, a third party
small entity
[[Page 90969]]
representative stated in the SBREFA process that its customers lose
access to services when data providers' interfaces are unavailable. The
CFPB expects that consensus standards regarding performance, which also
can serve as indicia of commercially reasonable performance, will also
help improve the reliability of access over time. Furthermore, the
value of screen scraping as an alternative option may be limited by its
relatively low success rates: in the Aggregator Collection, 40 percent
of initial account connection attempts made through screen scraping
were successful in 2022, compared to 51 percent of initial account
connection attempts made through interfaces for third parties. The CFPB
does not have data to quantify any net change in data access
reliability stemming from the combination of reduced screen scraping
and increased availability of interfaces for third parties. However,
with respect to nondepository entity comments that the proposed 3,500
millisecond response time was too slow and vague, the final rule
instead requires a proper response within a commercially reasonable
time. The CFPB did not change other performance standards outlined in
the proposed rule after considering nondepository entity comments in
conjunction with those from data provider commenters, detailed in the
section on Costs to data providers in part VI.E.1.
Cost of Onboarding Arrangements With Authorized Third Parties and Data
Providers
Third parties that previously accessed covered data through screen
scraping without negotiating the terms of their access with data
providers will now need to arrange for onboarding to the newly required
developer interfaces. The CFPB expects that many of these arrangements
will be established between data aggregators and data providers, though
some would occur between authorized third parties that do not contract
with data aggregators and data providers. As described in the section
on Costs to data providers in part VI.E.1, the CFPB has updated its
estimate of the average cost of this process between data aggregators
and data providers to $10,800.
Third parties may be denied data access based on risk management
concerns or other permissible grounds, such as, for example, if the
requested information is not covered data or falls into an exception.
The CFPB expects that third parties may incur costs from responding to
data providers' risk management information requests. Two research
institutes stated that third parties would incur costs from responding
to data providers' due diligence requests. Because prudential
regulators require banks to follow certain risk management practices in
contracting with third parties, the CFPB understands that authorized
third parties that contract with either a data aggregator or a data
provider at baseline provide due diligence information and will not
face increased costs under the proposed rule. Third parties that comply
with the GLBA Safeguards Framework are also unlikely to face increased
costs. Though third parties that access consumer data solely through
screen scraping at baseline will need to begin providing this
information to the entities with which they contract, the CFPB expects
that future consensus standards may limit the costs for third parties.
The CFPB expects that third parties that comply with data providers'
due diligence requirements will not be denied access to data providers'
interfaces and so very few third parties would incur costs related to
the loss of access entirely.
Use of TANs
Under the rule, data providers will be permitted to make available
a TAN instead of, or in addition to, a non-tokenized account number.
Several nondepository entity and data aggregator commenters provided
examples of TANs enabling consumer payment revocation and stated that
the use of TANs could increase costs for merchants and processers,
which could be at least in part passed through to consumers. One
nondepository entity estimated that the payments industry could face
cumulative annual losses in the hundreds of millions of dollars if TANs
were permitted under the rule. However, other data provider commenters
described how TANs can mitigate fraud risk, including the ability for
data providers to identify the point of compromise in case of a breach,
the ability to revoke compromised payment credentials without
disrupting other payment account activity, and limited risk of bank
fraud because TANs are restricted to a particular third party.
Restrictions on Use and Retention
The rule limits certain existing uses of both identifiable and de-
identified consumer data by third parties, including for the sale of
covered data, cross-selling of other products or services, and targeted
advertising, by specifying that these activities are not part of, or
reasonably necessary to provide, any other product or service.
Therefore, consumers must separately authorize third parties to
collect, use, and retain covered data for these activities. This
limitation may eliminate or lessen the profitability of certain
business models. Third parties that generate revenue from sharing
covered data with fourth parties--such as firms with no authorization
to access data from the consumer--may lose much of that source of
revenue. The CFPB does not have data on the number of third parties
that share covered data, or the amount of revenue generated by sharing
covered data. However, the CFPB notes that a survey of German app
developers after the European General Data Protection Regulation (GDPR)
was implemented found that while the share of app developers selling
data was small, nearly all the developers that sold data experienced a
decline in revenue post-GDPR.\174\ This finding may imply reductions in
revenue for third parties that sell covered data under the rule.
Several nondepository entity trade association commenters stated that
small and mid-size businesses rely on targeted advertising and will
lose revenue due to the proposed rule. Third parties that use covered
data for the marketing of other products and services may also lose a
source of revenue. Commenters did not provide quantitative data on the
expected scope of potential revenue losses. The CFPB acknowledges that
third parties may incur costs from altering business practices, or may
lose revenue, as a result of these limitations. The CFPB does not have
the necessary information to quantify this impact, but expects the
overall impact on third parties will be small, as most third parties'
revenue streams are not dependent on using covered data for these
activities. Furthermore, third parties can still seek consumer
authorization for covered data to be used for these activities as
standalone products or services, or first party data could be used.
---------------------------------------------------------------------------
\174\ Rebecca Jan[szlig]en et al., GDPR and the Lost Generation
of Innovative Apps, Nat'l Bureau of Econ. Rsch. Working Paper No.
30028 (May 2022), https://www.nber.org/papers/w30028.
---------------------------------------------------------------------------
In addition to these specific requirements, third parties will be
required to collect, use, and retain covered data only as reasonably
necessary to provide the consumer's requested product or service under
the rule. The limits on retention of consumer data when consumers
submit a revocation request or do not provide a new authorization
within 12 months may reduce the data available for product improvement.
Several third party small entity representatives highlighted through
the SBREFA process how consumer data can enable
[[Page 90970]]
the development of new products and services and can inform research
and public policy, even when only de-identified data are used for these
secondary purposes. A nondepository entity trade association stated
that there would be substantial costs to rework algorithms and product
operations, which could not be used in their current form without de-
identified consumer data. Firms in the Aggregator Collection also
reported using consumer data for functions other than transmitting data
to data recipients, including the improvement of existing products, the
development of new products, and risk management assessments. One
nondepository entity commented that using properly de-identified or
aggregated data for modeling or developing new products leads to no
harm to consumers. Several commenters, including nondepository
entities, nondepository entity trade associations, research institutes,
data aggregators, and data providers commented that secondary use
restrictions would reduce competition and innovation under the proposed
rule. One research institute commented that current models and
algorithms would become stagnant and could not be further improved
without the use of covered data. Multiple research institutes and a
consumer advocate commented that disallowing the use of de-identified
data for product development would result in more expensive and less
innovative products. Additionally, multiple data aggregators commented
that the inability to use de-identified data would limit the ability to
detect fraud.
Though the rule may limit third parties' use of consumers' covered
data for some extant purposes, the CFPB does not have data that would
allow it to estimate the size of any costs due to the limitations on
use, but notes that the rule permits uses that have separate product
authorizations, and permits uses that are reasonably necessary to
protect against or prevent fraud. The rule also allows the use of
covered data for servicing or processing the product or service
authorized by the consumer, or uses that are reasonably necessary for
the improvement of the consumer's requested product or service, without
a separate product authorization.
Costs may be mitigated because third parties can continue to use
data that they generate in providing their products and services. One
bank trade association commented that there would be costs to tracking
which data are subject to secondary use restrictions and which data are
not. The CFPB acknowledges there could be such costs, but expects that
these tracking costs would be small given that all consumer-authorized
covered data would be subject to secondary use restrictions, and all
first party data would not be subject to secondary use restrictions
under the final rule. The cost estimates in the section on Implementing
mechanisms for data deletion and record retention in part VI.E.1 would
include such costs.
New Financial Data Processing Products or Services Definition
The CFPB expects that the activities covered by the new financial
data processing products or services definition in 12 CFR part 1001 are
already within the scope of the CFPA's definition of financial product
or service. As a result, the CFPB does not expect the new definition to
impose costs on covered persons. However, to the extent that there are
firms offering products or services that are within the new definition
but outside of the existing financial product or service definition,
the new definition could impose some potential costs. Such firms would
be subject to the CFPA and its prohibition on unfair, deceptive, or
abusive acts or practices, including potential enforcement by the CFPB.
Under the baseline, the CFPB expects that such firms would already be
subject to a prohibition on unfair or deceptive acts or practices under
section 5 the Federal Trade Commission Act.\175\ Relative to the
baseline, the new definition would add potential enforcement against
unfair and deceptive acts or practices by the CFPB and require firms to
be compliant with the prohibition on abusive acts or practices. Given
the overlap with existing prohibitions, the CFPB expects the potential
costs would be limited, and would include developing and maintaining
policies and procedures to ensure compliance with the prohibition on
abusive practices for firms that are not compliant with the CFPA at
baseline. The CFPB does not have data to quantify these potential
costs. The CFPB requested comment on whether any firms offer products
or services that would be covered by the new definition but fall
outside the definition of financial product or service, and if so, what
potential costs those firms may face, but the CFPB did not receive any
comments with this information.
---------------------------------------------------------------------------
\175\ 15 U.S.C. 45.
---------------------------------------------------------------------------
2. Costs to Consumers
The rule may increase costs for data providers and third parties,
potentially leading to higher prices for consumers or reduced access to
certain products or services. The rule is likely to increase the
availability of consumer-authorized data overall. While this may
benefit many consumers, it could lead to higher credit costs for some
consumers with data indicative of higher risk if the use of this data
becomes standard for underwriting purposes. The rule would also require
consumers to reauthorize access to their financial data annually, which
involves relatively minor costs. In addition, consumers may incur small
costs because of unintentional lapses in authorization. Finally,
restrictions on secondary use of data may reduce revenues for some
third parties, leading to changes in product offerings or pricing, and
limiting not-for-profit research analyses that may benefit consumers.
Changes in Industry Structure
Data providers will face additional compliance costs as a result of
the rule. Some of these costs may be passed on to consumers in the form
of higher prices for credit, lower deposit rates, or higher account
fees. The CFPB does not have the data necessary to determine the extent
to which additional compliance costs may be passed through to
consumers, which depends on a number of factors including market
competition.
The rule does not require depository data providers that have
assets below size standards specified by the Small Business
Administration, which are currently set at $850 million, to comply with
subparts B and C. Several data provider commenters and trade
associations representing them, along with a nondepository entity trade
association and a consumer advocate commented that the rule may lead to
consolidation among depository institutions, which may lead to higher
prices and less choice for consumers. One credit union commented that
costs relative to net income would force about half of credit unions to
cease operations. The CFPB expects that the noncoverage of depository
entities with assets below $850 million addresses the concern that
small depository institutions would be unable to operate profitably and
in compliance with the rule. For example, the median credit union in
2024 had $57 million in assets and would thus not be covered by the
data provider provisions of the rule, and overall, 89 percent of credit
unions are below the coverage threshold. While it is possible that the
rule could influence decisions about consolidation for some
institutions above the coverage threshold, the CFPB expects any effect
to be small given the relatively large size of covered institutions.
The CFPB did
[[Page 90971]]
not receive any other data in comments that allows for a more precise
estimation of whether institutions would choose to consolidate as a
result of the rule.
Many of the largest depository data providers either already offer
third party data access that meets many of the requirements of the rule
or are developing such functionality, and thus their additional costs
of complying with the rule will be more limited. While the CFPB does
not have information to precisely estimate the number of consumers with
accounts at such data providers, the available data suggest that the
number is large. The Provider Collection indicates that, as of 2022, at
least 51 million consumers had connected accounts to third parties
through credential-free interfaces. This count of 51 million consumers
likely understates the true number of consumers who have such access
for two reasons. First, it does not include the consumers at
institutions in the Provider Collection who have access to, but have
not yet connected to, this type of access functionality. Second, it
does not include consumers at other institutions--not included in the
Provider Collection--that have established interfaces for third party
access that meet many of the requirements of the proposal. It could,
however, count consumers more than once if they have an account at more
than one institution included in the Provider Collection. Overall, the
CFPB expects that substantially more than 51 million consumers already
have accounts at institutions that will face more limited costs of
complying with the provisions. Consumers who only have accounts at
these institutions are likely to incur minimal costs passed on by data
providers due to the rule because the institutions where they have
accounts will face smaller costs. One credit union trade association
commenter stated that the rule will accelerate a transition to digital
services and reduce the number of branches, which some populations,
such as older consumers, rely on. The CFPB does not have data to
precisely analyze this claim but finds it unlikely that the rule will
result in many branch closures. In 2023, only 9 percent of Americans
said that they most often managed their bank account by visiting a
branch.\176\ Thus, the industry has already experienced a dramatic
shift toward online services, and the margin for consumers to
transition toward digital banking and cease visiting bank branches,
leading to branch closures that affect older consumers, is small. Since
the CFPB expects that all or nearly all covered data providers already
have a consumer interface, it is likely that consumers interested in
online services already conduct much of their banking online. Despite
few consumers preferring to manage an account by visiting a branch, the
number of bank branches nationwide has declined only 16 percent from
its peak in 2012 and actually grew slightly between 2022 and 2023.\177\
Further, branches serve small businesses in addition to consumers, so
are not supported by consumers alone.\178\ A credit union trade
association commented that financial institutions could be discouraged
from adopting a consumer interface if they do not already have one
because of the costs associated with the proposed rule. As discussed in
part IV.A.3., the CFPB has determined that all or nearly all
depositories that do not currently have a consumer interface are small
depository institutions and therefore will not be required to comply
with the final rule's requirements for data providers. In addition,
coverage in the final rule is no longer determined by the presence of a
consumer interface, and thus there is no disincentive to adopt a
consumer interface created by the final rule.
---------------------------------------------------------------------------
\176\ Press Release, Am. Bankers Ass'n, National Survey: Bank
Customers Use Mobile Apps More Than Any Other Channel to Manage
Their Accounts (Oct. 26, 2023), https://www.aba.com/about-us/press-room/press-releases/consumer-survey-banking-methods-2023.
\177\ See Fed. Deposit Ins. Corp., BankFind Suite: Find Annual
Historical Bank Data, https://banks.data.fdic.gov/explore/historical/?displayFields=STNAME%2CTOTAL%2CBRANCHES%2CNew_Char&selectedEndDate=2023&selectedReport=CBS&selectedStartDate=1934&selectedStates=0&sortField=YEAR&sortOrder=desc (last visited Oct. 16, 2024).
\178\ For example, Community Reinvestment Act data suggests that
branches are important in small business lending. Elliot Anenberg et
al., The Branch Puzzle: Why Are there Still Bank Branches?, FEDS
Notes (Aug. 20, 2018), https://www.federalreserve.gov/econres/notes/feds-notes/why-are-there-still-bank-branches-20180820.html.
---------------------------------------------------------------------------
Effects of Greater Information Sharing
The rule will enhance third party access to consumers' financial
data, which may be used in third parties' credit underwriting
decisions. The ability for firms to screen customers using information
generally increases total value in the market but may transfer value
from some consumers to firms. Some consumers will likely benefit, but
other consumers may be worse off. While the CFPB understands that,
currently, lenders do not commonly use cash-flow data in underwriting
to identify consumers who are a higher risk than the information on
traditional credit reports would predict, it is possible that the
market will evolve to use cash-flow data in this way as it becomes more
accessible. As a benefit, increased information about consumers could
lead lenders to offer some consumers cheaper credit, if, for example,
the information accessed from data providers is viewed by third party
lenders as indicating that the consumer is a lower credit risk than a
traditional credit report would reveal. More information, however,
could result in some consumers being charged higher prices or not being
offered credit if the cash-flow information reveals what a lender views
as a signal that a consumer is a higher credit risk than the lender
would have assessed without the consumer-authorized information.\179\
Even though it will be the consumer's choice whether to authorize
access to their covered data, it is possible that a lender may view a
consumer's decision not to authorize the sharing of their data as a
negative signal of credit risk and raise the price of credit or refuse
to offer a loan.\180\
---------------------------------------------------------------------------
\179\ For example, Jansen et al. (2022) study an opposite
shock--the removal of information, instead of the addition--and find
that removing bankruptcy information from credit reports
redistributes consumer surplus from consumers who have never
experienced bankruptcy to consumers with a previous bankruptcy. Mark
Jansen et al., Data and Welfare in Credit Markets (Jan. 28, 2022),
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4015958. Nelson
(2023) finds that limiting the information that credit card issuers
were able to use decreased prices for some high-risk borrowers and
increased prices for some low-risk borrowers, but on aggregate
raised consumer surplus. These are two examples of how the removal
of information that can be used in crediting decisions may shift
surplus towards consumers who appear to have lower repayment risk
after the information removal. Scott T. Nelson, Private Information
and Price Regulation in the US Credit Card Market, Univ. of Chic.
Booth Sch. of Bus. (Aug. 4, 2023), https://faculty.chicagobooth.edu/-/media/faculty/scott-nelson/research/private-information-and-price-regulation-in-the-us.pdf. The CFPB expects that the following
effects would occur under the rule: third parties will have access
to more information which will increase total surplus and will
likely increase surplus for those who appear to have lower repayment
risk with the additional information relative to those who appear to
have higher repayment risk with the additional information.
\180\ He, Huang and Zhou (2023) develop a model in which
consumers who choose not to share data are worse off under an open
banking system due to lenders taking opting out of data sharing as a
sign that a consumer is a high credit risk. Zhiguo He et al., Open
banking: Credit market competition when borrowers own the data, 147
J. Fin. Econ. 449 (2023), https://doi.org/10.1016/j.jfineco.2022.12.003. Similarly, Babina et al. (2023) develop a
model showing that when open banking policies enable the addition of
banking data to screening or pricing decisions, higher-cost
consumers can be worse off even if they opt out of sharing
information because opting out sends a negative signal to lenders.
Tania Babina et al., Customer Data Access and Fintech Entry: Early
Evidence from Open Banking, Stanford Univ. Graduate Sch. of Bus.
Rsch. Paper (Sept. 7, 2023), https://dx.doi.org/10.2139/ssrn.4071214.
---------------------------------------------------------------------------
[[Page 90972]]
Overall, the increased availability of consumer-authorized data
will allow lenders to underwrite and price more efficiently. This will
likely lead to greater credit access overall, with relatively greater
access or lower prices for lower risk borrowers who share data, but
relatively less credit access or higher prices for borrowers who are
higher risk or choose not to share data. The CFPB does not have the
data necessary to quantify these effects.
Time Cost of Reauthorizing Third Party Access Annually
Under the rule, a third party will need to limit the duration of
collection of covered data to a maximum period of one year after the
consumer's most recent authorization. To collect covered data beyond
the one-year period, the third party will need to obtain a new
authorization from the consumer no later than the anniversary of the
consumer's most recent authorization. The reauthorization process
should not be more burdensome than the initial authorization
certification, but consumers will incur a small time cost to
reauthorize the collection of their data. As discussed in the section
on Costs to third parties in part VI.E.1 above, existing evidence
suggests that many consumers may choose not to reauthorize a third
party's access to their covered data. The CFPB interprets this evidence
as suggesting that many consumers do not value the continued use of the
third party product or service enough to continue authorizing the
access of their covered data by the third party or that, given the
quickly evolving market of third party products and services, consumers
decide to access products or services through a different third party.
One nondepository entity trade association commenter stated that the
annual reauthorization limits the utility of pay-by-bank use cases for
consumers. Instead, the CFPB interprets a consumer's decision to not
provide a new authorization as evidence that they do not value the
service more than the relatively small time cost incurred to
reauthorize access. Further, consumers who currently pay by credit or
debit card may face a similar reauthorization cost when a card expires
or is replaced due to fraud, so these types of costs are not unique to
the pay-by-bank model.
Potential Changes in Pricing Models Due To Use and Retention
Limitations
Changes that third parties make to their business models as a
result of the rule may be passed on to consumers through higher prices
for services provided by third parties. For example, the CFPB
understands that some third parties obtain revenue by selling data that
consumers provide to them with other third parties or, more commonly,
by selling marketing information derived from such data. This may allow
third parties to provide services to consumers free of charge. As
discussed in the Costs to third parties part, there is evidence that
firms in Europe that were sharing customers' data experienced a decline
in revenue after data protection laws were enacted, suggesting that
they may need to seek alternative sources of revenue.\181\
---------------------------------------------------------------------------
\181\ Rebecca Jan[szlig]en et al., GDPR and the Lost Generation
of Innovative Apps, Nat'l Bureau of Econ. Rsch. Working Paper No.
30028 (May 2022), https://www.nber.org/papers/w30028.
---------------------------------------------------------------------------
The CFPB expects that the rule will reduce the amount of targeted
advertising using covered data. Several nondepository entity trade
association commenters stated that consumers benefit from targeted
advertising and prefer ad-supported services to fee-based services, and
so the prohibition of the use of covered data for targeted advertising
under the rule will harm consumers. But this overlooks that the rule
does not prohibit targeted advertising. Providers can still use other
forms of data for this purpose. And they can use covered data for this
purpose, so long as they do so in the form of a standalone product or
service, consistent with the terms of the rule. To the extent consumers
benefit from targeted advertising, the rule provides means to realize
such benefits.
To the extent that the rule leads to third parties changing their
business models, it is possible that some third parties will charge
consumers directly for services that used to be free. The CFPB does not
have data to estimate the share of consumers impacted or the magnitude
of any corresponding price increases.
Reduction in Not-for-Profit Research Analyses
Multiple research institutes and researchers commented that
restrictions on secondary uses of consumer data would eliminate the use
of open banking data in not-for-profit research analyses, which may
harm consumers. Research institutes and researchers considered the
possibility of an ``opt-in'' option for consumers to choose to share
their covered data for the purpose of not-for-profit research, but
expressed that research limited to this population would not generally
be representative and therefore would be of limited value. These
commenters requested an exception that would permit non-commercial
secondary uses for de-identified data. The CFPB acknowledges that the
rule will likely reduce the availability of consumer-permissioned data
for nonprofit research purposes, and that this could have some indirect
costs for consumers. The CFPB does not have data or evidence that would
allow it to quantify these potential indirect costs.
3. Benefits to Covered Persons
Benefits to Data Providers
At baseline, many third parties use screen scraping to access
consumer data. The CFPB expects that screen scraping will decline under
the rule. This is likely to benefit data providers because screen
scraping involves security risks and heavy web traffic. By
standardizing the terms of access and reducing the scope of
negotiation, the rule is also likely to decrease the per-arrangement
cost of enabling access to the developer interface. Finally, data
providers that provide competitive service offerings, including
potentially community banks and credit unions, could benefit from
increased account switching by consumers.
Reduced Screen Scraping
The CFPB understands that credential-based screen scraping creates
data security, fraud, and liability risks for data providers,
particularly because the credentials shared to facilitate data access
also typically can be used to move funds. Furthermore, screen scraping
can be used to gather data without data providers establishing a
relationship with third parties or assessing data security risks. The
CFPB cannot disaggregate fraud costs resulting from credential-based
screen scraping from general costs of fraud, including measures to
prevent fraud or insure against fraud-related damages. However,
depository data providers have reported extensive costs related to
preventing fraud and unauthorized transactions generally, and
reimbursing consumers when such fraud occurs. During the SBREFA
process, one small depository institution reported debit card fraud
losses of 28 percent of their total revenue. Small entity
representatives also noted that data providers typically pay premiums
for insurance against catastrophic fraud losses, with plans typically
covering losses in excess of $25,000, subject to certain restrictions.
Through conversations with industry participants, the CFPB understands
that account takeover fraud is the most likely
[[Page 90973]]
fraud risk that could be exacerbated by credential-based data access
methods such as screen scraping.\182\ In this form of fraud, the bad
actor gains access to the consumer's account and transfers funds, makes
purchases, or opens accounts without authorization. The CFPB expects
that the reduction in credential-based access due to the rule would
lower the risk of account takeover fraud, providing a benefit to data
providers through reductions in direct liability and decreased fraud
insurance premiums, although it is unclear how much account takeover
fraud is attributed to credential-based screen scraping. The CFPB does
not have sufficient data to estimate how much the rule will lower
account takeover fraud risk. However, even a small reduction would have
large benefits for data providers.\183\
---------------------------------------------------------------------------
\182\ For example, consumers' account credentials may not be
securely stored by third parties or fraudsters may induce consumers
to share their credentials by impersonating a legitimate third
party.
\183\ For example, a 3 percent reduction in ATO fraud risks
would generate an expected annual benefit of $330 million for data
providers, based on industry research finding ATO fraud risks of
approximately $11 billion annually. See PaymentsJournal, Javelin's
Identity Fraud Study Highlights the Changing Nature of Fraud (May
24, 2023), https://www.paymentsjournal.com/javelins-identity-fraud-study-highlights-the-changing-nature-of-fraud/.
---------------------------------------------------------------------------
Along with the requirements to access only the data fields
necessary to provide the specific product or service, the shift away
from credential-based screen scraping will also tend to reduce overall
traffic loads on the consumer-facing system and may reduce traffic
loads overall. The CFPB does not have systematic data with which to
estimate the net change in web traffic and the resulting decrease in
necessary expenditures on digital infrastructure. The CFPB understands
that the incremental cost of additional web traffic is small, and that
reasonably anticipated reductions in traffic are likely to provide
minimal benefits to data providers. In a comment, a data aggregator
concurred with the CFPB that transitioning to developer interfaces
should generally reduce the number of data requests and traffic
relative to screen scraping, thus reducing costs for data providers.
Reduced Onboarding Costs and More Standardized Terms of Access
The CFPB understands that onboarding third parties is often
resource intensive for data providers. In the Aggregator Collection
responses, aggregators reported that negotiating an access agreement
with a data provider could take between 50 and 4,950 staff hours of
business relationship managers, software developers, lawyers,
compliance professionals, and senior management, depending on the
complexity of the negotiation. The median estimated time was 385 staff
hours per agreement. Based on these responses, under the baseline the
CFPB estimated a total cost of between $4,260 and $422,000, which
varies depending on the complexity of the negotiation, with a median
cost of around $32,825. Although these estimates were provided by data
aggregators, the CFPB expects that these costs are also representative
for data providers at baseline.
For contract negotiations that would have occurred under the
baseline, the CFPB expects that onboarding costs will decrease under
the rule because many features of access agreements would be regulated
by the rule and not subject to commercial negotiation, including
requirements for interface reliability, interface queries, and the
scope of data accessible via the interface. One market participant
stated that in cases where data providers agree to use existing
industry-defined standards there is essentially no need for negotiation
and data providers can immediately begin updating their developer
interfaces in line with the standard specifications. The CFPB expects
that consensus standards will reduce onboarding costs in this way. The
CFPB expects that under the rule nearly all data providers will use
standardized onboarding arrangements that meet rule terms and the costs
of establishing data access will be limited to ensuring third party
risk management standards are satisfied and reviewing the arrangements.
A non-small entity representative third party commenter stated that
concluding this type of onboarding arrangement represents approximately
20 percent of total negotiation time under the baseline.\184\ Based on
this, the CFPB estimated in the proposal that negotiations under the
rule would require roughly 80 staff hours on average. The required time
to onboard third parties to developer interfaces may decline
substantially over time as consensus standards are developed for
certifying compliance with third party risk management standards. While
some data providers and third parties may choose to enter into
customized access arrangements that respect the terms of the rule, they
will generally only do so when the perceived benefits exceed the costs
described here. As discussed in the section on Costs to data providers
in part VI.E.1 above, commenters stated that the CFPB had
underestimated the costs of establishing data access arrangements. In
response to the information in these comments, the CFPB is updating its
estimate to 120 staff hours on average to onboard a third party to a
developer interface. Therefore, the CFPB estimates that the rule is
likely to reduce the cost of onboarding arrangements by $24,000 on
average.\185\ Under the baseline, data providers would have continued
to negotiate commercial access agreements with third parties and these
benefits would not have applied to those agreements. As discussed in
the section on Costs to data providers in part VI.E.1 above, the CFPB
expects that the rule will cause data providers to onboard additional
third parties relative to baseline. The cost of additional onboarding
arrangements is analyzed in that part.
---------------------------------------------------------------------------
\184\ See https://www.regulations.gov/comment/CFPB-2023-0011-0042.
\185\ This estimate is based on estimated total hourly
compensation of $89.99 multiplied by the difference between the
median expected hours required at baseline, 385 hours, and the
expected hours required under the rule, 120 hours.
---------------------------------------------------------------------------
Restrictions on Third Parties' Use and Retention of Data
The rule will also have some indirect effects on the value of first
party data held by data providers. Under the baseline, third and first
party data are both used for marketing and new product
development.\186\ The rule will limit third party collection of
consumer-authorized data to what is reasonably necessary to provide the
consumer's requested product or service. Third party use and retention
of covered data will also be subject to that limitation, which will
limit the availability of covered data for marketing and for the
development of new products outside the scope of the original
authorization, to the extent that third parties cannot obtain or use
data for these purposes through other means. While the CFPB does not
have data to quantify the benefits to data providers, all else equal,
this is likely to increase the value of first party covered data held
by data providers, which generally does not have these restrictions.
---------------------------------------------------------------------------
\186\ For example, a firm might target advertising towards
consumers who qualify for a particular credit product or who are
likely to be particularly profitable customers or develop new
products based on insights from a dataset of consumer transaction
histories.
---------------------------------------------------------------------------
Required Data Security Representations by Third Parties
The rule will require authorized third parties to represent that
they have reasonable security practices, in particular by representing
that they implement the GLBA Safeguards
[[Page 90974]]
Framework. These practices are likely to benefit data providers by
increasing certainty regarding their potential third party risks, and
generally will require minimum data security standards among third
parties. The CFPB expects this to generally reduce the likelihood of
data security breaches or other incidents, but the CFPB does not have
data to quantify the size of this benefit.
Potential Benefits From Increased Account Switching
In general, consumers prefer financial institutions that provide
better prices or customer experiences. As discussed in the section on
Effects of increased data sharing on innovation and competition in part
VI.E.4, the CFPB expects that the rule will improve consumers' ability
to switch financial institutions. As a result, financial institutions
that offer covered products with competitive prices and customer
experiences may increase their market share due to the rule. This could
particularly benefit community banks or credit unions that operate at a
smaller scale and thus would have had comparatively smaller
informational advantages relative to larger data providers under the
baseline, as discussed in the section on Reduced informational
advantages in part VI.E.1.
Benefits to Third Parties
Right to Access Data on Behalf of Consumers
Under the rule, covered data providers are required to provide data
to authorized third parties. Third parties will be able to access data
from data providers that had not made data available under the
baseline. Further, the rule's data reliability requirements will ensure
that data access is consistently available across all data providers.
The CFPB understands that, at baseline, connectivity failure rates
between third parties and data providers are high, in part because many
data providers do not facilitate data sharing with many third parties,
so these requirements may lead to large increases in the proportion of
consumers who are successfully able to share their data under the rule.
Firms in the Aggregator Collection reported initial connectivity
failure rates ranging from 28 percent up to 60 percent. The CFPB
understands that some of these initial connectivity failure rates occur
because the data provider denies the third party's request for data
access, rather than because of low interface reliability, and so third
parties will be able to reach more consumers under the rule's
requirement that authorized third parties have access to covered data.
Prohibition on Data Access Fees
The rule prohibits data providers from imposing fees on third
parties for costs associated with covered data provision. Firms in the
Aggregator Collection generally did not report paying fees to data
providers for access to covered data per customer or per interface
call, though a small number of annual or one-time payments were
reported. Though these costs are currently limited, the provisions will
ensure that the absence of fees under the baseline continues in the
future, providing more certainty to third parties about their costs of
accessing covered data. The CFPB does not have data to estimate the
benefit to third parties of this prohibition on fees because of the
uncertainty in how fees might have evolved under the baseline.
Reduced Negotiation Costs
As described in the Benefits to data providers part, based on data
and comments provided by third parties, the CFPB estimates that
negotiation costs will fall by 70 percent under the rule, or an average
savings of $24,000 per negotiated connection agreement. This will bring
about substantial savings for third parties, particularly data
aggregators. The reduction in negotiation costs may also allow
additional third parties to enter into access agreements with data
providers directly, potentially saving on expenses paid to aggregators
under the baseline.
More Frequent Access to Data
The rule prohibits covered data providers from unreasonably
limiting the frequency of third party requests for covered data and
from delaying responses to those requests. Based on responses to the
Provider Collection and conversations with industry participants, the
CFPB is aware that some large covered data providers that offer
developer interfaces currently impose access caps. Third parties would
benefit from the ability to access consumer data as often as is
reasonably necessary to provide the requested service. One firm in the
Aggregator Collection reported spending ``significant resources'' to
manage its traffic in order to avoid access cap limits. Additionally,
an aggregator in the Aggregator Collection reported spending resources
to persuade large financial institutions to raise or eliminate access
caps.
In addition to reducing costs associated with managing and limiting
traffic, third party services may become more valuable to consumers
when third parties can access consumer data more often.\187\ As a
result, the CFPB expects that third party revenue will increase from
the removal of unreasonable access caps under the rule. The CFPB does
not have data to quantify these benefits for third parties.
---------------------------------------------------------------------------
\187\ For example, an app that warns consumers when the funds in
their checking account fall below a predetermined threshold is
generally more valuable to consumers when it can access data about
their checking accounts more often.
---------------------------------------------------------------------------
Improved Accuracy of Data
The rule will require that data providers have policies and
procedures reasonably designed to ensure the accuracy of data
transmitted through their interfaces. In addition, the rule provides a
consensus standards framework for several factors that third party
small entity representatives reported as reducing accuracy, including
data access reliability, inconsistencies in data field availability and
formatting, and inaccuracies in screen scraped data.
The CFPB understands from the Aggregator Collection that access
caps can prevent consumers from obtaining their most up-to-date data
when a third party has surpassed its data limit. The removal of
unreasonable access caps under the rule will reduce such issues. The
rule will also require that a data provider make available the most
recently updated covered data that it has in its control or possession
at the time of a request, further ensuring that third parties will be
more likely to have up-to-date data than under the baseline.
The transition away from screen scraping will lead to more
consistency in the data fields that are available across all data
providers and in data field formatting, and may reduce costs associated
with ensuring that consumer data are accurate, particularly once
consensus standards are established. One data aggregator reported more
frequent inaccuracies for data accessed through screen scraping, as
well as the need to allocate more resources to meet accuracy standards
for screen scraped data. The CFPB understands that once compliant
developer interfaces are established, third parties will need to
transition away from screen scraping, which will reduce the costs
associated with maintaining accuracy in screen scraped data.
Costs associated with maintaining accuracy in consumer data will
not be eliminated altogether, as the rule will require that third
parties ensure that covered data are accurately received from data
providers, and accurately provided to other third parties, if
applicable. The CFPB expects that the increased accuracy of data
received
[[Page 90975]]
from data providers will simplify third party procedures for meeting
data accuracy standards. Third party products and services are likely
to become more valuable to consumers when data received from data
providers is more accurate and reliable. The CFPB expects that this
will increase third party revenue.
Improved Service Quality Due To Improved Data Access
As discussed in the Benefits to third parties: Prohibition on data
access fees part, the rule will prevent data providers from charging
fees to consumers or third parties for access to covered data, provide
third party access to data from all covered data providers through
compliant developer interfaces that meet reliability standards,
eliminate unreasonable access caps, and improve the accuracy of
received data. Furthermore, the rule clarifies that third parties are
required to obtain authorization from consumers to access covered data,
while data providers are permitted to confirm the scope of the third
party's authorization. This will allow third parties to request the
information that is reasonably necessary to deliver their product or
service. These effects reduce third party costs of providing services
to consumers and improve the quality of the services that they can
provide. The CFPB expects that the ability to provide more valuable
services to consumers at a lower cost would, over the short- to medium-
term increase profits for existing third parties and lead to increased
entry into the market for third parties' services.\188\
---------------------------------------------------------------------------
\188\ Third parties may experience an increase in investment
under the proposed rule, in addition to a reduction in costs and
improvement in service quality. Babina et al. (2023) study open
banking polices adopted across 49 countries and find that fintechs,
which include third party recipients of data, raised significantly
more funding from venture capital following the implementation of
open banking policies that require banks to share data with third
parties. See Tania Babina et al., Customer Data Access and Fintech
Entry: Early Evidence from Open Banking, Stanford Univ. Graduate
Sch. of Bus. Rsch. Paper (rev. Sept. 2023), https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4071214.
---------------------------------------------------------------------------
The rule is likely to enhance third party access to consumers'
financial data, which could be used in third parties' credit
underwriting decisions. Access to this data is likely to allow lenders
to better differentiate between borrowers with different likelihoods of
repayment and charge prices that are more aligned with potential
borrowers' repayment risk, increasing underwriting profitability. As an
example, the CFPB understands that access to consumer financial data
enables some third party lenders to incorporate information about
consumers' cash flow (i.e., depository account inflows and outflows)
into their underwriting models. Industry research has shown that cash
flow is predictive of serious delinquency, and that models including
cash flow can distinguish between the repayment risks of consumers with
similar traditional credit profiles.\189\ The CFPB expects that some
third party lenders will be able to identify and reach more consumers
with low repayment risk under the rule, and may therefore experience an
increase in profits. The CFPB does not have data to quantify these
benefits for third parties.
---------------------------------------------------------------------------
\189\ One credit scoring company found that adding cash flow
data to its traditional model improved predictiveness by 5 percent
for consumers with thin or new credit profiles. Supporting this
finding, FinRegLab studied six non-bank lenders in the current
system and found the cash flow variables in their underwriting
models were predictive of serious delinquency. See Can Arkali, Icing
on the Cake: How the FICO Score and alternative data work best
together, FICO Blog (June 2023), https://www.fico.com/blogs/icing-cake-how-fico-score-and-alternative-data-work-best-together;
FinRegLab, The Use of Cash-Flow Data in Underwriting Credit:
Empirical Research Findings (July 2019), https://finreglab.org/wp-content/uploads/2019/07/FRL_Research-Report_Final.pdf.
---------------------------------------------------------------------------
Reduced Costs of Establishing and Maintaining Screen Scraping Systems
The CFPB expects that third parties will cease screen scraping for
covered data from covered data providers under the final rule. Based on
the Aggregator Collection, the CFPB understands that maintaining screen
scraping systems is more costly than maintaining developer interface
connections. The reported ratio of staff hours spent on maintaining
screen scraping data access to staff hours spent on maintaining
interface data access ranged between 2.5 and 12. For aggregators that
separately reported costs of maintaining data provider connections
through both screen scraping and developer interfaces, the dollar cost
of screen scraping ranged between $1.6 million and $7 million, or
between $0.0005 and $0.0216 per access attempt; for developer
interfaces, the reported dollar cost was between $1.5 million and $1.6
million, or between $0.0001 and $0.0194 per access attempt. Each
request made through a developer interface rather than through screen
scraping leads to expected savings between $0.0004 and $0.0022.
Cumulatively, the firms in the Aggregator Collection reported nearly 16
billion screen scraping attempts in 2022. Under the rule, these screen
scraping attempts would instead be made through requests to developer
interfaces, leading to at least $6.4 million to $35.9 million worth of
annual savings for data aggregators, based only on information supplied
by firms in the Aggregator Collection. Aggregators' savings may be
passed on to data recipient third parties through lower prices for
aggregator services. The CFPB expects that third parties' cost per
access attempt will fall under the rule because screen scraping is more
costly for third parties than accessing data through developer
interfaces, and third parties will transition to only accessing covered
financial data through interfaces.
Increased Standardization
The CFPB expects that the cost of accessing consumer data will
decrease not only through reductions in onboarding arrangement costs
and screen scraping costs, but also because the rule incentivizes the
industry to adopt consensus standards and requires standardized
formats, including formats of data and communication protocol formats.
The rule also clarifies which party is responsible for obtaining
authorization from the consumer. The CFPB expects that increased
standardization will be facilitated by one or more standard-setting
bodies recognized by the CFPB, as outlined in the Industry Standard-
Setting Final Rule.\190\ One nondepository entity commenter expressed
an expectation that this standardization will lead to increased market
consolidation for data aggregator services. However, in order to deny
covered data access to a third party, data providers will need to meet
the rule's requirements for reasonable denials. Data providers will
also need to apply their covered data access denial standards in a
consistent and non-discriminatory manner under the rule. This will
limit the scope for data providers to partner with only a small number
of dominant data aggregators if other data aggregators seek to access
covered data and meet the requirements for covered data access.
Additionally, the data provider will need to provide covered data in a
standardized and machine-readable format and use standardized
communication protocols to confirm with consumers the scope of a third
party's authorization to the consumer's covered data. This increased
standardization of data access will reduce the cost of providing data
aggregator services under the rule, further reducing barriers to entry
and increasing competition for data aggregator services. The CFPB
further expects that increased standardization of data access may
reduce the costs for third parties integrating with data providers and
allow some third parties that provide services to consumers to bypass
data aggregators. An increase in
[[Page 90976]]
the share of third parties accessing data under access agreements with
data providers would tend to reduce any degree of market power that
data aggregators would enjoy under the baseline and will tend to reduce
access prices for third parties. One small entity representative shared
in the SBREFA process that aggregator costs represent its single
largest budgetary line item, at approximately 10 percent of monthly
expenditures. Data aggregators in the Aggregator Collection reported a
wide range in fees charged to data recipient third parties depending on
the recipient's size, minimum commitments, and access volume. Reported
median annualized fees ranged between $2,000 and $6,000. Average
annualized fees ranged between $40,000 and $70,000, demonstrating that
a small number of data recipients pay substantially more fees than
average.\191\
---------------------------------------------------------------------------
\190\ 89 FR 49084 (June 11, 2024).
\191\ For example, responses in the Aggregator Collection
suggested that a smaller number of data recipients may pay
annualized fees totaling several million dollars.
---------------------------------------------------------------------------
The rule may make it comparatively less expensive for third parties
to connect directly with data providers, rather than contracting with
one or more data aggregators. Because a direct connection with a data
provider is a substitute for aggregator services, a decrease in the
cost of direct connections would likely decrease the price of
aggregator services. However, because aggregators spread the costs of
establishing data access agreements with each data provider across many
authorized third parties, aggregators are likely to retain an advantage
from scale in providing access. This advantage may decline over time
with consensus standard development, which may reduce friction and cost
associated with establishing and maintaining bespoke connections to
each data provider. The CFPB does not have data to estimate the net
benefits to data aggregators or data recipients due to increased
standardization of data access.
4. Benefits to Consumers
The rule will likely increase consumers' ability to access their
covered data through third parties as desired. This increase may result
in more third party products and services that consumers find useful in
the marketplace. The use of credential-free data access will make this
sharing possible without consumers revealing their credentials to third
parties, reducing the potential harms that consumers may experience due
to data breaches or similar incidents. Consumers will also have
increased control over how third parties use their data, since third
parties will no longer have indefinite authorization to use a
consumer's covered data or to use it for reasons other than what is
reasonably necessary to provide the product or service. The rule will
likely have important secondary benefits for consumers as well, for
example through the development of new underwriting methods or
increasing competition among data providers or third parties. Finally,
the potential effects of the new financial data processing product or
service definition are discussed below.
Right to Third Party Data Access
The rule will require data providers to facilitate consumer
instructions to provide authorized third parties with covered data. As
discussed in the section on Benefits to third parties in part VI.E.3,
consumers' initial account connection attempts through authorized third
parties experience high failure rates, and the rule benefits both
consumers and third parties by guaranteeing authorized third parties
the right to access covered data. Under the rule, data providers will
be required to offer a developer interface with commercially reasonable
performance, including a proper response rate in excess of 99.5
percent. This will benefit consumers by increasing the quality of third
party products and services as well as the likelihood that consumers
are able to use them at all. As discussed in the section on Benefits to
third parties in part VI.E.3, the CFPB expects that third parties'
costs of establishing connections with data providers will decline as a
result of the rule, and this may benefit consumers to the extent that
lower costs are passed through to them.
Further, guaranteed access to consumer authorized covered data will
likely increase investment in third parties that request that data,
providing consumers with more options in the marketplace and increasing
competition.\192\ As evidenced by the estimated 100 million consumers
who have authorized third party data access discussed in the section on
Baseline in part VI.D above, consumers have substantial demand for
financial products and services offered by third parties, which may
feature more convenient and automated means of gathering and using
consumers' financial data relative to legacy financial service
providers.\193\ The CFPB expects that an expanded range of third party
products and services will increase competition and innovation,
offering important secondary benefits to consumers, including improved
credit access and lower prices, discussed below.
---------------------------------------------------------------------------
\192\ For example, Babina et al. (2023) find that after other
countries implemented open banking policies, venture capital
investment in fintech companies increased significantly on average
and the number of new entrants in the financial advice and mortgage
markets increased. Tania Babina et al., Customer Data Access and
Fintech Entry: Early Evidence from Open Banking, Stanford Univ.
Graduate Sch. of Bus. Rsch. Paper (rev. Jan. 22, 2024), https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4071214.
\193\ As an example of how this can potentially increase access
to credit for underserved populations, Howell et al. (2022) find
that automation of underwriting processes for small business lending
are associated with a higher share of loans being made to Black
borrowers. Sabrina T. Howell et al., Lender Automation and Racial
Disparities in Credit Access, Nat'l Bureau of Econ. Rsch. Working
Paper No. 29364 (Nov. 2022), https://www.nber.org/papers/w29364.
---------------------------------------------------------------------------
Several bank commenters argued that the costs of the rule exceed
the consumer benefits, and a bank and bank trade association argued
that the costs of the developer interface exceed consumer benefits,
especially for small data providers. The CFPB acknowledges, as
discussed in the section on Costs to data providers in part VI.E.1
above, that data providers will incur costs associated with meeting
developer interface requirements. The CFPB expects consumers to enjoy
substantial benefits as a result of the ability to share consumer-
authorized data with third parties as provided by the rule, such as the
benefits described in the effects of increased data sharing on
innovation and competition part. These benefits could reach over $1
billion annually even with relatively small increases in competition
and account switching, as discussed in a more detailed analysis in this
part. In addition, the non-coverage of depository institutions with
assets below $850 million described in the rule alleviates the
compliance costs for small depository institutions and substantially
reduces the costs of the rule as a whole.
Commenters questioned the coverage of many data elements, but the
CFPB expects that all data elements required by the rule provide
consumer benefit. One bank argued that the costs of providing certain
data elements, such as whether a borrower entered into an arbitration
agreement as contained in account terms and conditions, is not
outweighed by the benefits. Additionally, bank trade association,
research institute, and credit union commenters stated that the
consumer benefits of the requirement to provide terms and conditions do
not outweigh the costs. The CFPB expects that as a general matter the
provision of terms and conditions will benefit consumers
[[Page 90977]]
by, for example, facilitating comparison shopping. Consumer knowledge
of whether or not they are subject to an arbitration agreement will aid
consumers in understanding their legal rights, which is a benefit in
itself. The same commenters also argued against the inclusion of
pending transactions stating that, for example, pending transactions
may change in amount once settled. The CFPB expects that providing
information about pending transactions can benefit consumers by, for
example, alerting them about potential fraudulent charges, alerting
them if they might be close to overdrafting, or allowing them to view
their remaining credit limit on credit cards. These features have clear
use cases in, for example, account monitoring and personal financial
management. Based on the Aggregator Collection, tens of millions of
inquiries were submitted for personal financial management and account
monitoring in 2022. A bank trade association commented that providing
data on rewards credit per transaction would be costly and that no
evidence of benefits was provided. The CFPB expects that rewards
programs information will help consumers comparison shop, and use any
awards they accrue optimally. The CFPB does not have the data to
perform a quantitative analysis, but the benefits from providing this
information accrue to consumers over the long run, whereas the marginal
cost of providing this information is limited and mostly incurred as a
one-off, or fixed, expense. Accordingly, the CFPB has determined that
the potential consumer benefits can be significant in relation to
costs, warranting the inclusion of this information. Some nondepository
entity trade association, bank, and research institute commenters
stated that the risks of requiring information to initiate payments
outweighs the benefits to consumers. While the CFPB does not have data
to perform a quantitative analysis, the CFPB has determined that
requiring information to initiate payments supports highly beneficial
consumer use cases such as account switching and making payments.
A credit union trade association commented that the CFPB should
analyze whether data on non-covered products like mortgages is less
beneficial to consumers than included data like credit card rewards,
scheduled bill payments, and terms and conditions. The CFPB expects
access to these types of covered data will benefit consumers. For
example, information on scheduled bill payments has a clear personal
financial planning benefit. The CFPB may pursue another rule in the
future to cover other products, and has determined that the products
and data covered by the current rule benefit consumers, as described in
this part and in part IV.A.2.
One bank trade association argued that there is no consumer benefit
to the requirement that data providers provide public quantitative
performance metrics. The CFPB expects that this requirement will enable
consumers and others to verify that data access is being provided
consistently with the rule's requirements, and that consumers will
benefit indirectly as the metrics will facilitate supervision and
improve compliance with the rule. A commenter also stated that there is
no consumer benefit to requiring three years of record retention
instead of two. The CFPB has determined that a three-year record
retention period provides sufficient information to conduct its exams
and investigations, which, by enhancing compliance, benefit consumers.
One nondepository entity and two nondepository trade organizations
argued that there is no benefit to covering digital wallets because
transaction information is available more directly from bank account or
credit card providers. As described in part IV.A.2, the CFPB expects
that consumers will benefit from the rule's coverage of digital wallets
because digital wallets may possess data from several depository
institutions and account types, and because a digital wallet may offer
a more convenient method for some consumers to provide third parties
with consumer-authorized data. Further, a digital wallet may include
information not available to the account-holding data provider, such as
the time and location of the payment.
One community bank trade association commented that there is no
evidence of significant demand among community bank customers for
sharing data with third parties. The rule does not cover small
depository institutions, and given the substantial demand for data
sharing demonstrated in the Aggregator Collection and Provider
Collection and the increasing availability of third party services, the
CFPB finds it unlikely that there are institutions covered under the
rule with little or no demand for data sharing among its customers.
Credential-Free Access--Increased Privacy, Reduced Data Breach Risks
Under the rule, data providers will be required to create an
interface that can be used to share covered data with third parties
without consumers' credentials being held by the third party. Many
third parties currently use screen scraping techniques or credential-
based APIs to access consumer information, which requires the consumer
to provide the third party with their username and password for the
data provider's website. This current practice may expose consumers to
greater risk if a third party experiences a data breach. Such data
breaches can be very costly for consumers. While the CFPB does not have
data to estimate the resulting consumer benefits of credential-free
access, the academic and practitioner literature indicates that the
associated benefits can be substantial.\194\ Courts have approved large
settlements in cases where data breaches affected financial service
providers.\195\ It is common for consumers to have their personal
information compromised. For example, a 2019 Pew Research Center survey
found that in the past 12 months, 28 percent of respondents reported
having someone make fraudulent charges on their debit or credit card,
take over a social media or email account without permission, or
attempt to open a credit account in their name.\196\ Under the rule,
consumers would benefit from a reduced likelihood that third party data
breaches would expose their account login information, since they would
no
[[Page 90978]]
longer have to give third parties their account credentials in order
for the third party to access covered data. If the third party
experienced a data breach it would be less likely to compromise the
consumer's account since the breach would no longer potentially include
the consumer's account access credentials. This in turn may reduce the
risks of unauthorized transfers or other fraudulent account activity.
---------------------------------------------------------------------------
\194\ Albon et al. (2016) surveyed more than 6,000 consumers and
found that in the previous year, 26 percent reported receiving a
data breach notification. When asked about the costs that the data
breach imposed on them, 68 percent of consumers whose data was
breached estimated a nonzero financial loss, with a median value of
$500. Lillian Ablon et al., Consumer Attitudes Toward Data Breach
Notifications and Loss of Personal Information, RAND Corp. (2016),
https://www.rand.org/content/dam/rand/pubs/research_reports/RR1100/RR1187/RAND_RR1187.pdf. A study of identity fraud by Javelin
Strategy found that the average consumer who identified as a victim
of identity fraud lost $1,551 and spent nine hours resolving the
issue. Javelin Strategy, Identity Fraud Losses Total $52 Billion in
2021, Impacting 42 Million U.S. Adults (Mar. 29, 2022), https://javelinstrategy.com/press-release/identity-fraud-losses-total-52-billion-2021-impacting-42-million-us-adults. Consumers' liability
for ATO fraud may be limited under Regulation E, but it is possible
that not all consumers can or do successfully exercise their rights
to limited liability.
\195\ In 2019, a settlement for $190 million was approved in a
data breach at Capital One that affected approximately 100 million
consumers. Capital One, Information on the Capital One cyber
incident (Apr. 22, 2022), https://www.capitalone.com/digital/facts2019/. A settlement of $425 million for consumers was reached
in the 2017 Equifax data breach, which affected approximately 147
million consumers. Fed. Trade Comm'n, Equifax Data Breach Settlement
(Dec. 2022), https://www.ftc.gov/enforcement/refunds/equifax-data-breach-settlement.
\196\ Brooke Auxier et al., Americans and Privacy: Concerned,
Confused and Feeling Lack of Control Over Their Personal
Information, Pew Rsch. Ctr. (Nov. 15, 2019), https://www.pewresearch.org/internet/2019/11/15/how-americans-think-about-privacy-and-the-vulnerability-of-their-personal-data/.
---------------------------------------------------------------------------
One nondepository entity commenter argued that since the market is
already shifting towards APIs, the added benefit of the rule does not
outweigh the costs. As discussed in this part, the CFPB has determined
that there are large potential benefits to consumers as a result of
providers transitioning to credential-free access, and to the extent
that data providers have already implemented interfaces meeting the
requirements of the rule, the CFPB expects that these data providers
will have lower costs of compliance. Further, the popularity of third
party services and APIs highlights the need for safeguards to ensure
consumer privacy. Another nondepository entity commenter stated that
because some developer interfaces provide worse performance than legacy
connection methods, shifting away from those legacy connection methods
harms consumers. The CFPB has determined that the privacy and data
security benefits of shifting to credential-free access outweigh any
potential performance advantages of legacy methods under the baseline.
Further, the CFPB expects the rule's performance standards for
developer interfaces to improve the reliability of data access relative
to screen scraping under the baseline. One third party and one consumer
advocate commentator expressed concern that disallowing PII-based
authentication methods could harm consumers without online accounts or
credentials. The CFPB expects that all or nearly all consumers who wish
to share consumer-authorized covered data with third parties either
have an online account or the ability to create one. One data
aggregator commentator expressed a concern that the transition away
from screen scraping would harm consumers' ability to access accounts
not covered by the rule, like mortgage and student loan accounts.
However, the final rule does not affect screen scraping for accounts
not covered by the final rule. Whether or not such screen scraping is
permissible depends on other laws, such as the prohibition on unfair,
deceptive, or abusive acts or practices, that form part of the
baseline.
In addition, for a range of reasons, as this final rule takes
operational effect, the CFPB expects some data providers and third
parties to have compelling incentives to transition voluntarily to
credential-free interfaces for non-covered products that would have
been accessed using credentials under the baseline. This would yield
additional data security benefits to consumers.
Several commenters expressed concern about potential fraud risks
that may occur even under credential-free authorization of third
parties. One consumer advocate commenter and one credit union commenter
said that if data are more readily available as a result of the rule,
it could increase the risk of financial abuse and fraud, particularly
for older consumers. Two consumer advocate commenters also expressed
concern that the rule could increase availability of joint account
information to domestic abusers. Two research entity commenters and a
bank commenter stated that consumers might particularly be vulnerable
to fraudulent pay-by-bank transactions. The CFPB acknowledges that a
bad actor could potentially gain fraudulent access to consumer-
permissioned data, but this risk exists under the baseline. The rule
mitigates these risks through its authentication requirements and
requirements for credential-free third party access. Practically, the
CFPB expects that in order to connect a bank account to a new third
party service, a bad actor would need access to the consumer's
credentials for their covered account and potentially access to
additional information or devices required for authorization, such as
codes issued as part of two-factor authentication. These risks exist
under the baseline, and the CFPB expects that any increased risks from
greater use of consumer-permissioned data access are outweighed by the
data security and privacy benefits of the rule.
Third Party Limitations on Collection, Use, and Retention--Ability To
Be Forgotten, Increased Privacy, More Control Over Use of Own Data
The rule will increase consumers' control over how their covered
data are used by third parties. There is strong evidence that consumers
value meaningful control over how their personal information is used
and thus consumers will benefit from the rule. In a 2015 survey, the
Pew Research Center found that 93 percent of Americans said that it was
very or somewhat important to be ``in control of who can get
information about you.'' \197\ One consumer advocacy stakeholder stated
that under the baseline, consumers may not understand how third parties
share their data due to difficult-to-understand disclosures and may
also not understand the rights they may have to limit how their data
are shared. The Pew Research Center found in another study that 70
percent of Americans feel that their personal information is less
secure than it was five years ago, 79 percent are very or somewhat
concerned about how their personal information is being used by
companies, and only 18 percent feel that they have a great deal of or
some control over the data that companies collect about them.\198\
Eighty-one percent feel that the potential risks of personal data
collection by companies outweigh the benefits. This evidence suggests
consumers have a strong desire for meaningful control over how their
personal information is used and thus consumers will benefit
substantially from the rule. The CFPB does not have sufficient data to
provide a quantitative estimate of these benefits to consumers.
---------------------------------------------------------------------------
\197\ Pew Rsch. Ctr., Americans Hold Strong Views About Privacy
in Everyday Life (May 19, 2015), https://www.pewresearch.org/internet/2015/05/20/americans-attitudes-about-privacy-security-and-surveillance/pi_15-05-20_privacysecurityattd00/.
\198\ Brooke Auxier et al., Americans and Privacy: Concerned,
Confused and Feeling Lack of Control Over Their Personal
Information, Pew Rsch. Ctr. (Nov. 2019), https://www.pewresearch.org/internet/2019/11/15/how-americans-think-about-privacy-and-the-vulnerability-of-their-personal-data/.
---------------------------------------------------------------------------
Effects of Increased Data Sharing on Innovation and Competition
Increased availability of consumer-authorized data to third parties
could have a number of other indirect--but potentially large--benefits
for consumers. For example, as discussed in the section on Costs to
consumers in part VI.E.2 above, while increased availability of data
could result in lenders assessing some consumers as higher credit risk
than they would be otherwise and charging them higher prices, it is
also likely to result in lenders assessing some consumers as lower
credit risk and charging them lower prices. It is possible that a
consumer could be denied a loan that they would have been granted in
the absence of the use of consumer-authorized data in underwriting. If
the loan was not affordable for the consumer, then this denial could
benefit the consumer in the long term.
Consumer-authorized data may be particularly useful for consumers
who have a limited credit history or do not have a credit file with a
nationwide consumer reporting company. Among consumers who do have
credit scores, a study by FinRegLab found that cash-flow underwriting
can help identify consumers who have low traditional credit scores but
are actually a low
[[Page 90979]]
credit risk for lenders.\199\ It is possible that many consumers will
experience increased access to credit or lower prices under the rule,
to the extent that they are less able to share covered data with third
parties under the baseline.\200\ Even without the rule, the Aggregator
Collection shows that in 2022, tens of millions of data requests were
made through those data aggregators for consumer data to be used for
underwriting purposes.\201\
---------------------------------------------------------------------------
\199\ FinRegLab, The Use of Cash-Flow Data in Underwriting
Credit (July 2019), https://finreglab.org/wp-content/uploads/2019/07/FRL_Research-Report_Final.pdf.
\200\ For example, using data from a German fintech lender, Nam
(2024) finds that borrowers across the credit score distribution
benefit on average when they choose to share data with the lender,
with lower credit score borrowers experiencing a larger increase in
acceptance rates and higher credit score borrowers experiencing a
larger decrease in interest rates. See Rachel J. Nam, Open Banking
and Customer Data Sharing: Implications for Fintech Borrowers, SAFE
Working Paper No. 364 (Mar. 20, 2024), https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4278803. One credit union trade association
commenter stated that the CFPB did not consider data the effects of
open banking in Europe. While the CFPB does not have primary data to
analyze the effects of open banking on firms and consumers in other
countries, it considered studies such as this one in its analysis.
\201\ These requests include requests for information relating
to existing accounts, like credit card limit increases, as well as
the underwriting of new loans.
---------------------------------------------------------------------------
The use of consumer-authorized covered data by third parties may
also benefit consumers through increased availability and quality of
payment services. The availability of consumer-authorized covered data
may improve payment services by, for example, making it easier to sign
up for such services and allowing the service to verify a consumer's
balance before initiating a payment to ensure that they are not
overdrafting the consumer's account. In 2022, the Aggregator Collection
shows nearly two billion requests for consumer data for facilitating
payment services. Increased use of payment services is likely to
benefit consumers.\202\ Easier person-to-person payments may help
consumers send or receive money from friends and family to avoid
overdrafting their bank accounts or incurring fees through other forms
of borrowing. In addition to providing benefits for person-to-person
payments, consumer-authorized data are increasingly used to facilitate
consumer-to-business ``pay-by-bank'' purchases, with lower fees
relative to some alternatives, some of which may be passed through as
benefits to consumers. One consumer advocate commenter expressed a
concern that consumer-authorized covered data could be used to
determine eligibility for government benefits, and that inaccuracy in
the data could harm consumers. The CFPB expects that if widespread
inaccuracies were a problem with an application using consumer-
permissioned data to determine an eligibility for a program, it is
unlikely that such an application would be used. A bank commenter
raised a concern that covered data could be used to offer less
competitive products by third parties. The CFPB acknowledges that third
parties learn more about consumers though covered data, but notes that
third parties' use of this data is limited by the rule to what is
reasonably necessary to provide the consumer's requested service or
product.
---------------------------------------------------------------------------
\202\ For example, Balyuk and Williams (2023) find that low-
income consumers with increased exposure to a person-to-person
payment platform are less likely to overdraft their bank accounts
and more likely to borrow from family and friends using the platform
if they have a low balance relative to their needs. See Tetyana
Balyuk & Emily Williams, Friends and Family Money: P2P Transfers and
Financially Fragile Consumers (Dec. 12, 2023), https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3974749.
---------------------------------------------------------------------------
Increased availability of consumer-authorized covered data may also
lower the costs for a consumer switching financial institutions in
search of higher deposit rates, lower fees, better service, or lower
rates on credit products. Recent research has found that digital
banking technology affects the movement of deposits into and out of
banks in response to market pressures.\203\ The provisions may make it
easier for a consumer to move to a new institution by easing the
transfer of funds and account information from the old institution to
the new institution.
---------------------------------------------------------------------------
\203\ Koont, Santos and Zingales (2023) find that in response to
Federal Funds rate changes, deposits flow out of banks with an
online platform more quickly. Naz Koont et al., Destabilizing
Digital Bank Walls (Oct. 2023), https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4443273. Erel, Liebersohn, Yannelis, and
Earnest (2024) found that primarily online banks saw larger inflows
of interest-bearing deposits when Federal Funds rates increased.
Isil Erel et al., Monetary Policy Transmission Through Online Banks,
Fisher Coll. of Bus. Working Paper No. 2023-03-015 & Charles A. Dice
Ctr. Working Paper No. 2023-15 (June 3, 2024), https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4459621.
---------------------------------------------------------------------------
Even marginal improvements in consumers' ability to shop for and
transfer deposits could have large potential benefits for consumers,
given the substantial size of the deposit market and the dispersion in
prices across institutions. Consumers with sizeable savings may benefit
most from accounts offering higher interest rates, while consumers with
limited funds may benefit most from accounts with low or no fees.
Recent studies suggest there is potential for substantial gains on both
measures. On interest rates, researchers have documented high average
savings interest rates available from large online banks, substantially
above average savings interest rates.\204\ On fees, the CFPB has found
that although deposit account fees are trending lower since 2019, banks
with over $1 billion in assets collectively earned $7.7 billion in
revenue from overdraft and insufficient funds (NSF) fees in 2022.\205\
This is despite the availability of at least 397 deposit account
products with zero overdraft and NSF fees, with options available in
every state.\206\
---------------------------------------------------------------------------
\204\ Erel, Liebersohn, Yannelis, and Earnest (2023) found that
in April 2023, there were at least 15 large online banks offering an
average savings interest rate of 2.17 percent, compared to 0.28
percent at other banks. Similarly, FDIC data from April 2023 show
that, weighted by share of deposits, average savings interest rates
were 0.39 percent. The authors also find that the online banks offer
substantially higher rates for other products like certificates of
deposit, individual retirement accounts, and money market deposit
accounts. Isil Erel et al., Monetary Policy Transmission Through
Online Banks, Fisher Coll. of Bus. Working Paper No. 2023-03-015 &
Charles A. Dice Ctr. Working Paper No. 2023-15 (May 26, 2023),
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4459621; Fed.
Deposit Ins. Corp., FDIC National Rates and Rate Caps (Apr. 17,
2023), https://www.fdic.gov/resources/bankers/national-rates/2023-04-17.html.
\205\ Off. of Consumer Populations & Mkts., Consumer Fin. Prot.
Bureau, Overdraft/NSF revenue down nearly 50% versus pre-pandemic
levels (May 24, 2023), https://www.consumerfinance.gov/data-research/research-reports/data-spotlight-overdraft-nsf-revenue-in-q4-2022-down-nearly-50-versus-pre-pandemic-levels/full-report/.
\206\ These accounts are certified as meeting the Bank On
National Account Standards established by the Cities for Financial
Empowerment Fund. See list of certified accounts at https://joinbankon.org/accounts/ (last visited Oct. 16, 2024), and current
account standards, https://bankon.wpenginepowered.com/wp-content/uploads/2022/08/Bank-On-National-Account-Standards-2023-2024.pdf
(last visited Oct. 16, 2024).
---------------------------------------------------------------------------
The rule will likely improve consumers' ability to switch
providers. As a result, the rule will have two benefits. First, those
consumers who switch may earn higher interest rates or pay lower fees.
To estimate the potential size of this benefit, the CFPB assumes for
this analysis that of the approximately $19 trillion \207\ in domestic
deposits at FDIC- and NCUA-insured institutions, a little under a third
($6 trillion) are interest-bearing deposits held by consumers, as
opposed to accounts held by businesses or noninterest-bearing
accounts.\208\ If, due
[[Page 90980]]
to the rule, even one percent of consumer deposits were shifted from
lower earning deposit accounts to those with interest rates one
percentage point (100 basis points) higher, consumers would earn an
additional $600 million annually in interest. Similarly, if due to the
rule, consumers were able to switch accounts and thereby avoid even one
percent of the overdraft and NSF fees they currently pay, they would
pay at least $77 million less in fees per year.\209\
---------------------------------------------------------------------------
\207\ Fed. Deposit Ins. Corp., Insured Institution Performance,
17(2) FDIC Quarterly (2023) https://www.fdic.gov/analysis/quarterly-banking-profile/qbp/2023mar/qbp.pdf, and Nat'l Credit Union Admin.,
Quarterly Credit Union Data Summary (2022 Q4), https://ncua.gov/files/publications/analysis/quarterly-data-summary-2022-Q4.pdf.
\208\ Derived from several data sources, the assumption that
slightly under one third of total deposits are interest-bearing
deposits held by consumers is based on assuming slightly under half
of all deposits are held by consumers, and about 70 percent of
consumers' deposits are interest bearing. First, in the most recent
available 2019 data from the Survey of Consumer Finances,
households' mean savings in transaction accounts and certificates of
deposit was $48,803; see Bd. of Governors of the Fed. Rsrv. Sys.,
Survey of Consumer Finances (SCF), https://www.federalreserve.gov/econres/scfindex.htm (last updated Apr. 5, 2024). The 2020 Census
estimates that there were 127 million U.S. households, and the
product of these two numbers yields an estimate of $6.2 trillion in
deposits held by consumers; see Thomas Gryn et al., Married Couple
Households Made Up Most of Family Households, America Counts:
Stories, https://www.census.gov/library/stories/2023/05/family-households-still-the-majority.html. This is slightly under half of
the $14 trillion in deposits based on Call Report data for 2019;
Fed. Deposit Ins. Corp., 2019 Summary of Deposits Highlights, 14(1)
FDIC Quarterly (2020), https://www.fdic.gov/analysis/quarterly-banking-profile/fdic-quarterly/2020-vol14-1/fdic-v14n1-4q2019-article.pdf, Nat'l Credit Union Admin., Quarterly Credit Union Data
Summary (2019 Q4), https://ncua.gov/files/publications/analysis/quarterly-data-summary-2019-Q4.pdf. The estimate for share of
deposits that are interest bearing is derived from Figure A.3 in
Erel, Liebersohn, Yannelis, and Earnest (2023). Isil Erel et al.,
Monetary Policy Transmission Through Online Banks, Fisher Coll. of
Bus. Working Paper No. 2023-03-015 & Charles A. Dice Ctr. Working
Paper No. 2023-15 (May 26, 2023), https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4459621.
\209\ Survey evidence suggests that a small share of consumers
value overdraft as a form of borrowing while a majority would prefer
that the transactions were declined; see The Pew Ctr. on the States,
Overdraft America: Confusion an Concerns about Bank Practices (May
2012), https://www.pewtrusts.org/~/media/legacy/uploadedfiles/
pcs_assets/2012/sciboverdraft20america1pdf. In addition, the CFPB
has found that some overdraft practices can be unfair, if they could
not be reasonably anticipated; Consumer Fin. Prot. Bureau,
Unanticipated overdraft fee assessment practices, Consumer Financial
Protection Circular (Oct. 26, 2022), https://www.consumerfinance.gov/compliance/circulars/consumer-financial-protection-circular-2022-06-unanticipated-overdraft-fee-assessment-practices/. This analysis assumes that those consumers who prefer
overdraft would stay with institutions offering these services,
while those switching would prefer accounts without overdraft fees.
---------------------------------------------------------------------------
The second potential way consumers could benefit is through
improved prices and service even for consumers who do not switch
providers, due to the rule's effects on competition. Increased
competition from improved online banking services and open banking
services under the baseline may have already contributed to consumers
receiving higher interest rates on deposits and paying lower fees in
recent years.\210\ To estimate the scale of potential benefits from the
provisions, if the rule further increases these competitive pressures
such that average offered interest rates on deposits increase by even
one basis point (0.01 percentage points), consumers would accrue an
additional $600 million in annual benefits from interest even without
moving their deposits. Similarly, if increased competitive pressures
due to the rule caused banks to lower overdraft and NSF fees by one
percent on average, consumers would benefit from at least $77 million
in reduced fees annually.
---------------------------------------------------------------------------
\210\ Kang-Landsberg, Luck and Plosser (2023) find that the
pass-through of the Federal Funds rate to deposit rates is
increasing and nearing the levels seen in the early 2000s. Alena
Kang-Landsberg et al., Deposit Betas: Up, Up, and Away?, Liberty St.
Econ. (Apr. 11, 2023), https://libertystreeteconomics.newyorkfed.org/2023/04/deposit-betas-up-up-and-away.
---------------------------------------------------------------------------
In addition to the effects in the deposit market, under the rule, a
consumer's depository institution will no longer have a potential
advantage in underwriting a loan based on the consumer's transaction
data, which may increase competition and potentially lower interest
rates on loan products for consumers. While these potential impacts are
difficult to quantify, even marginal improvements in the interest rates
or fees paid by consumers could have substantial benefits, given the
size of consumer lending markets.
The provisions will also make it easier for consumers to access
their data through personal financial management platforms. This
increased ability to access and monitor information about their
personal finances could benefit consumers.\211\ The CFPB does not have
data to quantify the resulting consumer benefit.
---------------------------------------------------------------------------
\211\ Carlin, Olafsson, and Pagel (2023) find that increased
access to a personal financial management platform substantially
lowers overdraft fees. Bruce Carlin et al., Mobile Apps and
Financial Decision-Making, 27 Rev. Fin. 977 (2023), https://academic.oup.com/rof/article/27/3/977/6619575. The evidence on this
subject is mixed, however, as Medina (2021) finds that reminders to
consumers to make credit card payments in a personal financial
management platform increased the probability that consumers
incurred overdraft fees and slightly increased overall net fees paid
by consumers, since consumers were more likely to overdraft their
bank account to pay their credit card bill. Paolina C Medina, Side
Effects of Nudging: Evidence from a Randomized Intervention in the
Credit Card Market, 34 Rev. Fin. Stud. 2580 (2021), https://academic.oup.com/rfs/article/34/5/2580/5903746.
---------------------------------------------------------------------------
New Financial Data Processing Products or Services Definition
The CFPB expects that activities covered by the new financial data
processing products or services definition are already within the scope
of the CFPA's definition of financial product or service. As a result,
the CFPB does not expect the new definition to have benefits to
consumers. However, to the extent that there are firms offering
products or services that are within the new definition but outside of
the financial product or service definition, the new definition would
benefit consumers by increasing protections against unfair, deceptive,
or abusive acts or practices. The CFPB does not have data to quantify
these potential benefits. The CFPB requested comment on whether any
firms offer products or services that would be covered by the new
definition but fall outside the definition of financial product or
service, and if so, what potential benefits to consumers could result
from the new definition but did not receive any such comments.
5. Alternatives Considered
The CFPB considered the impacts of several alternatives to the
rule. These include alternatives that would allow secondary use of data
by third parties in certain circumstances (i.e., through an opt-in
mechanism allowing the consumer to consent to specific uses, while
retaining a prohibition on certain high-risk secondary uses) or allow
retention and use of de-identified data as an exception to the general
limitation standard that otherwise limits retention.\212\ The CFPB
considered covering Electronic Benefit Transfer accounts in the rule.
The CFPB also considered alternatives specific to small entities, such
as exemptions or longer compliance timelines, which are discussed in
part VII.B.
---------------------------------------------------------------------------
\212\ Some additional alternatives are considered and discussed
in part IV. For example, alternatives to the prohibition on fees for
establishing and maintaining interfaces and for accessing data
through interfaces are discussed in part IV.C.2.
---------------------------------------------------------------------------
Rather than prohibiting secondary uses, the CFPB considered
allowing some secondary uses through an opt-in mechanism while
prohibiting certain high-risk secondary uses. Relative to the proposal,
this alternative would generally benefit third parties by allowing
additional uses of data and potentially impose costs on consumers by
reducing their privacy and their control of how their data are used. If
these secondary uses lead to new beneficial products and services
offered by third parties, this alternative could benefit consumers
relative to the proposal. If, however, the additional secondary uses
are detrimental to consumers despite the consumer's opt-in consent,
allowing such uses could harm consumers relative to the baseline.
[[Page 90981]]
The CFPB requested comment on whether any secondary uses should be
allowed through an opt-in mechanism. The CFPB also requested comment on
how potentially harmful secondary uses could be defined and prohibited
under this alternative.
Comments on whether any secondary uses should be allowed through an
opt-in mechanism and on how potentially harmful secondary uses could be
defined and prohibited are discussed in parts IV.D.4, VI.E.1, and
VI.E.2. In general, commenters' arguments about the benefits, costs,
and impacts of allowing some secondary uses were in line with the
CFPB's analysis of the benefits, costs, and impacts of this
alternative, with data provider commenters generally opposed to
allowing secondary uses, third party commenters generally in favor of
allowing some secondary uses, and with varied support for this
alternative from consumer advocate and research organization
commenters. For the reasons discussed in parts IV.D.4, VI.E.1, VI.E.2,
VI.E.3, and VI.E.4, the CFPB has determined that the rule as finalized
better achieves the intended outcome of section 1033 of the CFPA than
this alternative.
The CFPB also considered an exception to the general limitation
standard for retention and use of de-identified data. Relative to the
proposal, this alternative would generally benefit third parties by
allowing the continued retention and use of de-identified consumer data
after the general limitation standard would normally require the
deletion of identified data. For example, de-identified data could
potentially be used for product development, which would benefit third
parties. These uses could also potentially benefit consumers through
improved or new products. However, if the risk of reidentification
remains for the consumers in de-identified data, the retention of such
data creates a potential cost to consumers in privacy and fraud risks
in the case of a data breach or misuse of data. In the proposal, the
CFPB requested comment on whether there should be an exception to the
general limitation standard for de-identified data, and if so, how de-
identification should be defined to limit risks to consumers.
Comments on whether there should be an exception to the general
limitation standard for de-identified data, and if so, how de-
identification should be defined are discussed in parts IV.D.4, VI.E.1,
and VI.E.2. In general, commenters' arguments about the benefits,
costs, and impacts of an exception for de-identified data were in line
with the CFPB's analysis of the benefits, costs, and impacts of this
alternative, with data provider commenters generally opposed to an
exception, third party commenters and research organization commenters
generally in favor of an exception, and with varied support for this
alternative from consumer advocate commenters. For the reasons
discussed in parts IV.D.4, VI.E.1, VI.E.2, VI.E.3, and VI.E.4, the CFPB
has determined that the rule as finalized better achieves the intended
outcome of section 1033 of the CFPA than this alternative.
Finally, the CFPB considered including EBT accounts as covered
accounts under the rule. Commenters stated that the impact analyses in
the proposal did not consider the impact on EBT accountholders of not
including EBT accounts in the rule. The CFPB considered the impacts of
covering EBT accounts in the proposal, but found that several factors
weighed against covering EBT accounts at this time. The CFPB
acknowledges that many consumers use EBT accounts, and may not have
reliable, convenient access to their account data provided by data
providers. One nondepository entity commenter that provides third party
data access to EBT accounts provided data on the prevalence and
reliability of data sharing under their existing account connections.
These data show that, under the baseline, rates of successfully
accessing EBT data via existing third party connection methods range
from 92 to 99 percent across EBT technology providers. Under the
alternative in which such accounts were covered, consumers with EBT
accounts would likely benefit from improved access through consumer
interfaces, and improved third party access through developer
interfaces. This improved access would benefit consumers by making it
easier to monitor their account balances and transactions. However,
improved data access for EBT accounts would generally not provide the
type of account switching and competition benefits quantified in the
rule for deposit and credit card accounts, as EBT accounts are
generally provided by government agencies, rather than through
competing private firms. Based on these considerations and those
described in part IV.A.3, the CFPB declines to expand coverage to EBT
accounts at this time.
F. Potential Impacts on Insured Depository Institutions and Insured
Credit Unions With $10 Billion or Less in Total Assets, as Described in
Section 1026
Under the final rule, depository institutions (including credit
unions, and including both federally insured and non-federally insured
institutions) that satisfy the SBA definition of a small entity will
not be required to maintain a consumer interface or developer
interface. This is a change from the proposal. The final rule will
require depository institutions with $10 billion or less in total
assets (community banks and credit unions) but that do not satisfy the
SBA definition of a small entity to maintain a consumer interface and a
developer interface through which they receive requests for covered
data and make that data available in an electronic form usable by
consumers and authorized third parties. Compared to larger data
providers, these institutions likely are more reliant on core banking
providers and other service providers to comply, have fewer consumers
and thus reduced efficiencies of scale, and may be less likely to act
as data recipients in addition to being data providers. Compared to
nondepository data providers of all sizes, these institutions may have
more legacy systems that may be costly to modify to come into
compliance with the proposal.
As discussed in part VI.E.1, the CFPB expects that most
depositories of this size will contract with a vendor for their
interfaces for consumers and third parties. To examine the types of
vendors used by covered institutions with $10 billion or less in total
assets, the CFPB uses a data field in the NCUA Profile data which asks
credit unions to indicate ``the name of the primary share and loan
information processing vendor.'' \213\ While the vendor that provides
core banking services to a credit union is not always the same vendor
that provides digital banking services to the credit union, the CFPB
expects that in many cases the same vendor provides both services.
Based on the reported information for credit unions with between $850
million and $10 billion in assets, the CFPB estimates that at least 83
percent of such covered credit unions already use a vendor that offers
interfaces for third parties. To measure the size of vendors used, the
CFPB estimates that 97 percent of credit unions with between $850
million and $10 billion in assets use a vendor with
[[Page 90982]]
at least 100 credit union clients, and 99 percent of such credit unions
use a vendor with at least 50 credit union clients. The CFPB expects
that many of these vendors would likely offer interfaces for third
parties by the compliance date applicable for community banks and
credit unions. However, the 1 percent of credit unions using smaller
vendors are more likely to need to either switch vendors or build a
developer interface in house. This could lead to higher costs, as the
costs of switching to a new vendor may be larger as a proportion of
total assets or revenues for smaller depositories relative to larger
depositories.
---------------------------------------------------------------------------
\213\ A ``share'' denotes a deposit account held by a credit
union, and thus will include the Regulation E covered accounts under
the proposal.
---------------------------------------------------------------------------
The CFPB does not have data on the vendors used by community banks,
but expects that they may have a similar distribution of vendors as the
comparably sized credit unions, and thus will face comparable costs to
establish a developer interface.
The CFPB requested comment on its analysis in the proposal of the
potential impact on depository institutions and credit unions with $10
billion or less in total assets. The CFPB did not receive comments
specifically on its analysis of potential impacts on insured
depositories and insured credit unions with less than $10 billion in
assets, but comments that addressed impacts on small depositories,
credit unions, and community banks are discussed in parts VI.E.1,
VI.E.3, and VII.B.
G. Potential Impacts on Consumers in Rural Areas, as Described in
Section 1026
Relative to the proposal, the CFPB expects that the change in
coverage for depositories that satisfy the SBA definition of small
entities and the extended compliance timelines will substantially
reduce the impacts of the rule on consumers in rural areas.
Under the baseline, smaller banks hold a larger share of deposits
in rural areas. For example, analysis by the Federal Reserve Board in
2017 found that the market share of community banks (defined as assets
of less than $10 billion) in rural areas is nearly 80 percent on
average, compared with nearly 40 percent in urban areas.\214\
---------------------------------------------------------------------------
\214\ Bd. of Governors of the Fed. Rsrv. Sys., Trends in Urban
and Rural Community Banks (Oct. 4, 2018), https://www.federalreserve.gov/newsevents/speech/quarles20181004a.htm.
---------------------------------------------------------------------------
Rural consumers are substantially less likely to use online banking
than those who live in urban areas, defined to include all MSAs. For
example, Benson et al. (2020) find that 56 percent of consumers in
rural areas use online banking compared to 75 percent in large
MSAs.\215\ This may generally mean that rural consumers could
experience less of both the costs and the benefits of the rule. Some of
the difference in online banking use may be explained by differences in
access to high-speed internet, since as of 2018 consumers in rural
areas were 20.8 percentage points less likely to have the option of
subscribing to high-speed internet.\216\ Given that rural consumers are
less likely to use online banking, they may also be less likely to use
third party online services. The CFPB does not have comprehensive data
on the geographic distribution of the use of third party products and
services, though since rural consumers are less likely to have high-
speed internet access, they may be less likely to use third party
products and services. The 2021 FDIC National Survey of Unbanked and
Underbanked Households found that 68.7 percent of consumers with bank
accounts outside of MSAs had linked their bank account to a third party
online payment service, compared with 72.3 percent in MSAs, showing
that rural consumers are slightly less likely to use at least one type
of third party product.\217\
---------------------------------------------------------------------------
\215\ David Benson et al., How do Rural and Urban Retail Banking
Customers Differ?, FEDS Notes (June 12, 2020), https://www.federalreserve.gov/econres/notes/feds-notes/how-do-rural-and-urban-retail-banking-customers-differ-20200612.html.
\216\ Fed. Commc'ns Comm'n, 2020 Broadband Deployment Report
(released Apr. 24, 2020), https://docs.fcc.gov/public/attachments/FCC-20-50A1.pdf.
\217\ Fed. Deposit Ins. Corp., 2021 National Survey of Unbanked
and Underbanked Households, https://www.fdic.gov/analysis/household-survey/index.html (last updated July 24, 2023).
---------------------------------------------------------------------------
The CFPB requested comment on its analysis in the proposal of
potential impacts on consumers in rural areas. One consumer advocate
commenter noted that consumers in rural areas may be more likely to
live in banking deserts and thus more reliant on online financial
services like those offered by third parties. The CFPB expects that the
final rule will increase the availability of such online services for
consumers in rural areas who bank at covered data providers. The rule
also implements additional protections for consumers using third party
services. For consumers who bank at data providers not covered by the
rule, the CFPB expects that data access will generally continue to
improve as it has under the baseline, through voluntary adoption of new
methods of third party data access.
More general comments on impacts on consumers, including consumers
who bank at community banks or credit unions, are discussed in parts
VI.E.2 and VI.E.4.
VII. Regulatory Flexibility Act Analysis
The Regulatory Flexibility Act (RFA) \218\ generally requires an
agency to conduct an IRFA and a FRFA of any rule subject to notice-and-
comment requirements. These analyses must ``describe the impact of the
proposed rule on small entities.'' \219\ An IRFA or FRFA is not
required if the agency certifies that the rule will not have a
significant economic impact on a substantial number of small
entities.\220\ The CFPB also is subject to certain additional
procedures under the RFA involving the convening of a panel to consult
with small business representatives prior to proposing a rule for which
an IRFA is required.\221\ The CFPB did not certify that the proposed
rule would not have a significant economic impact on a substantial
number of small entities within the meaning of the RFA. Accordingly,
the CFPB convened and chaired a Small Business Review Panel under
SBREFA to consider the impact of the proposed rule on small entities
that would be subject to that rule and to obtain feedback from
representatives of such small entities. The Small Business Review Panel
for the proposal is discussed in part VII.A. The CFPB is also
publishing a FRFA. Among other things, the FRFA estimates the number of
small entities that will be subject to the rule and describes the
impact of that rule on those entities. The FRFA for this rule is set
forth in part VII.B.
---------------------------------------------------------------------------
\218\ 5 U.S.C. 601 et seq.
\219\ 5 U.S.C. 603(a). For purposes of assessing the impacts of
the proposed rule on small entities, the term ``small entities'' is
defined in the RFA to include small businesses, small not-for-profit
organizations, and small government jurisdictions. 5 U.S.C. 601(6).
A ``small business'' is determined by application of SBA regulations
and reference to the NAICS classifications and size standards. 5
U.S.C. 601(3). A ``small organization'' is any ``not-for-profit
enterprise which is independently owned and operated and is not
dominant in its field.'' 5 U.S.C. 601(4). A ``small governmental
jurisdiction'' is the government of a city, county, town, township,
village, school district, or special district with a population of
less than 50,000. 5 U.S.C. 601(5).
\220\ 5 U.S.C. 605(b).
\221\ 5 U.S.C. 609.
---------------------------------------------------------------------------
A. Small Business Review Panel
Under section 609(b) of the RFA, as amended by SBREFA and the CFPA,
the CFPB must seek, prior to conducting the IRFA, information from
representatives of small entities that may potentially be affected by
its proposed rules to assess the potential impacts of that rule on such
small entities.
The CFPB complied with this requirement. Details on the SBREFA
Panel and SBREFA Panel Report for the proposal are described in part
II.A.
[[Page 90983]]
B. Final Regulatory Flexibility Analysis
1. Statement of the Need for, and Objectives of, the Rule
In section 1033 of the CFPA, Congress authorized and directed the
CFPB to adopt regulations governing consumers' data access rights. The
CFPB is issuing this rule primarily to implement CFPA section 1033 with
respect to certain covered persons under the CFPA, although the CFPB is
also relying on other CFPA authorities for specific aspects of the
rule. This rule aims to (1) expand consumers' access to their financial
data across a wide range of financial institutions, (2) ensure privacy
and data security for consumers by limiting the collection, use, and
retention of data that is not needed to provide the consumer's
requested service, and (3) push for greater efficiency and reliability
of data access across the industry to reduce industry costs, facilitate
competition, and support the development of beneficial products and
services. The CFPB is issuing this rule pursuant to its authority under
the CFPA. The specific CFPA provisions relied upon are discussed in
part III. See part VI.A for additional discussion of the objectives of
the rule.
2. Significant Issues Raised by Public Comments in Response to the
IRFA, a Statement of the Assessment of the Agency of Such Issues, and a
Statement of Any Changes Made in the Proposed Rule as a Result of Such
Comments
Trade associations representing small depository institutions
requested that the CFPB provide flexibilities or less costly
alternatives for small entities. Comments from such organizations and
from small depository data providers themselves stated that the CFPB
conducted an incomplete analysis of the disproportionate costs of the
proposal on smaller entities. Data provider commenters also stated that
the costs from the rule would work against small and mid-sized banks,
since larger banks already have the functionality and are able to take
advantage of scale. A data provider industry association commenter
stated that the CFPB did not take into account the feedback received
through the SBREFA process, and that the CFPB should consider how
increased competition from fintechs will impact credit unions. A credit
union industry association commented that the RFA analysis in the
proposal was flawed in how it approached credit union's costs as data
providers because it did not take into account the cumulative
regulatory impact of different rulemakings on credit unions.
The CFPB has determined that it is appropriate to not finalize the
proposed coverage of the rule, such that small entity depositories are
not covered as data providers. As a result, under the final rule, small
entity depositories will not face any costs to maintain a consumer or
developer interface due to the rule.
The CFPB expects that this change will address the concerns of
small entity commenters, but notes that the impact analyses in the
proposal did account for feedback received through the SBREFA process
and did provide a complete analysis of the differential costs to small
entities. Based on its analysis and the feedback received during that
process, the proposal reduced the number and complexity of required
data fields in the proposal relative to the SBREFA Outline, and
established longer compliance timelines for small entities. These
provisions of the proposal were an acknowledgement of the reliance of
small depository data providers on service providers to comply with the
rule and the scale advantages of large data providers. Regarding
increased competition from fintechs, the proposal acknowledged that
there would likely be increased competition for covered accounts, due
to easier account switching and enhanced services offered by third
parties under the rule. The trend of greater competition from third
parties is likely heightened under the rule, although it is present
under the baseline as well; this trend also stands to benefit small
data providers with competitive account offerings. The CFPB expects
that many small entity data providers will adopt developer interfaces
voluntarily due to competitive pressures, as they have done prior to
the rule, but the change in coverage will allow small data providers to
forgo or delay the deployment of a developer interface if it is
especially costly for them based on the characteristics of their
institution. Regarding the comment asserting there is a cumulative
impact of different rulemakings on credit unions, small entities that
are credit unions are not data providers under the final rule.
3. Response of the Agency to Any Comments Filed by the Chief Counsel
for Advocacy of the Small Business Administration in Response to the
Proposed Rule, and a Detailed Statement of Any Change Made to the
Proposed Rule in the Final Rule as a Result of the Comments
The Chief Counsel for Advocacy of the Small Business Association
(Advocacy) provided comments on several aspects of the proposal.
Advocacy stated that the exemptions in the proposal were too narrow,
and that the CFPB should consider exemptions for small third parties in
addition to any exemptions for data providers. Advocacy commented that
implementation timelines should be longer. Advocacy also commented that
the CFPB did not discuss the possibility that firms may reduce their
offerings to customers rather than comply, and that the CFPB should
analyze the impact if small entities decide to exit rather than comply
with the rule. Advocacy stated that the CFPB should consider State laws
that have similar requirements, and evaluate if the rule is necessary
or creates additional burden. Advocacy commented that the CFPB should
clarify the role of industry standards and the responsibility or
liability for data security issues or misuse of data. Advocacy
commented that small entities should be permitted to charge fees for
making covered data available, and that the CFPB should reduce the
definition of covered data for transaction information to 12 months,
rather than the ``safe harbor'' of 24 months in the proposal.
In the final rule, the CFPB has revised the proposed coverage such
that small entity depositories are not covered as data providers. With
regards to small depository data providers, this change also addresses
Advocacy's comments about the possibility that firms may reduce their
service offerings or decide to exit the market in response to the rule.
The CFPB considered exemptions for small nondepository data
providers, but generally understands that these firms do not have the
technological complexities that make complying with the data provider
requirements as burdensome as for depositories. Rather than exempt some
small nondepository data providers, the CFPB has instead extended the
compliance deadlines for such entities from one year in the proposal to
approximately 2.5 years in the final rule. The CFPB expects this change
to substantially mitigate the burden of compliance for small
nondepository data providers.
The CFPB considered exemptions for small third parties in the
proposal, but remains concerned that allowing third parties to access
covered data via the rule without requiring the data security, data
privacy, and secondary use restrictions in the rule would significantly
reduce the benefits to consumers and would create risks for data
providers--including small entity data providers. In addition, unlike
covered data providers, small entities that are potential third parties
have a
[[Page 90984]]
choice over whether to access covered data, and can choose not to
access such data if they find that complying with the rule's
authorization requirements and secondary use restrictions are too
costly. As described in part VI.E, the CFPB expects that compliance
costs for third parties will be less burdensome than costs for data
providers and that benefits to third parties will outweigh the costs.
As a result, the CFPB does not expect the rule's requirements on third
parties to deter the development of beneficial third party products and
services.
Regarding the consideration of State laws that have similar
requirements, the CFPB considered such laws, as described in part VI.D.
These primarily include State-level data privacy and data security
laws, which are closest in effect to some of the rule's requirements on
third parties. The CFPB expects the rule's requirements on third
parties to be complementary to these State laws, and necessary to
impose on all third parties, regardless of where they operate or where
their consumers are located, to limit data privacy and security risks
to consumers. In addition, State laws generally do not require data
providers to provide consumers with access to their financial data,
which is the core objective of CFPA section 1033 and this rule.
Regarding the clarity of industry standards, as discussed in part
II.C, the CFPB published the Industry Standard-Setting Final Rule in
June 2024 to try to provide clarity on industry standards sooner and to
ease compliance burden for industry participants, including small
entities.
The potential costs related to liability or fraud for data
providers are discussed in part VI.E.1. As discussed in that part, the
CFPB expects that the majority of data providers will see a net
decrease in fraud risks and reputational risks relative to the baseline
of current market practices, in which screen scraping is widespread and
there are no restrictions on data collection, retention, and use by
third parties. Small depository entities are not covered as data
providers under the final rule, and the CFPB generally expects that
liability and fraud risks will be reduced for the majority of small
nondepository data providers, based on the evidence discussed in part
VI.E.1.
Regarding permitting small data providers to charge fees for
access, the CFPB has declined to permit such fees for the reasons
discussed in parts IV.C.2 and VI.E.1. The CFPB has also declined to
change the definition of covered data for transaction information held
by small entity data providers, for the reasons discussed in part
IV.B.3. The CFPB has instead addressed burden on small entities through
revisions to coverage, compliance timelines, and other revisions
relative to the proposal as discussed in this part.
4. Description of and an Estimate of the Number of Small Entities to
Which the Rule Will Apply or an Explanation of Why No Such Estimate Is
Available
The small entities affected by the rule will be those that meet the
definitions of data provider, third party, or data aggregator. Data
providers include depository institutions and nondepository
institutions, although, as discussed above, small depository
institutions are not covered. The new financial data processing product
or service definition will apply to third parties, data aggregators, or
others that provide financial data processing products or services for
consumer purposes.
Nondepository financial institutions and entities outside of the
financial industry may also be affected, though it is important to note
that entities within these industries will only be subject to the rule
if they meet the definitions of data provider, third party, or data
aggregator. Examples of potentially affected small third parties
include entities using consumer-authorized data to underwrite loans,
offer budgeting or personal financial management services, or
facilitate payments.
For the purposes of assessing the impacts of the rule on small
entities, ``small entities'' are defined in the RFA to include small
businesses, small nonprofit organizations, and small government
jurisdictions. A ``small business'' is defined by the SBA's Office of
Size Standards for all industries in the NAICS. The CFPB has identified
several categories of small entities that may be subject to the
proposals under consideration. These include depository institutions
(such as commercial banks, savings associations, and credit unions),
credit card issuing nondepositories, sales financing companies,
consumer lending companies, real estate credit companies, firms that
engage in financial transactions processing, reserve, and clearinghouse
activities, firms that engage in other activities related to credit
intermediation, investment banking and securities dealing companies,
securities brokerage companies, and commodities contracts brokerage
companies. Other potentially affected small entities include software
publishers, firms that provide data processing and hosting services,
firms that provide payroll services, firms that provide custom computer
programming services, and credit bureaus. According to the SBA's Office
of Size Standards, depository institutions are small if they have less
than $850 million in assets. Nondepository firms that may be subject to
the rule have a maximum size of $47 million in receipts, but the
threshold is lower for some NAICS categories.\222\ Table 1 shows the
number of small businesses within NAICS categories that may be subject
to the rule based on December 2023 NCUA and FFIEC Call Report data and
2017 Economic Census data from the U.S. Census Bureau. Entity counts
are not provided for the specific revenue amounts that the SBA uses to
define small entities and are instead usually provided at multiples of
five or ten million dollars. Table 1 includes the closest upper and
lower estimates for each revenue limit (e.g., a NAICS category with a
maximum size of $47 million in receipts has both the count of entities
with less than $50 million in revenue and the count of entities with
less than $40 million in revenue). Not all small entities within each
included NAICS category will be subject to the rule.
---------------------------------------------------------------------------
\222\ SBA regularly updates its size thresholds to account for
inflation and other factors. The SBA Size Standards described here
reflect the thresholds in effect at the publication date of this
final rule. The 2017 Economic Census data are the most recently
available data with entity counts by annual revenue. See Small Bus.
Admin., SBA Size Standards (effective Mar. 17, 2023), https://www.sba.gov/sites/sbagov/files/2023-06/Table%20of%20Size%20Standards_Effective%20March%2017%2C%202023%20%282%29.pdf.
---------------------------------------------------------------------------
BILLING CODE 4810-AM-P
[[Page 90985]]
[GRAPHIC] [TIFF OMITTED] TR18NO24.000
Table 2 provides the CFPB's estimate of the actual number of
affected entities within the categories of depositories, nondepository
data providers, and third parties, and the NAICS codes these entities
may fall within. As described in
[[Page 90986]]
part VII.B.6, with regard to the requirements of the rule applicable to
data providers, the final rule does not cover depositories that are
small entities based on SBA's definition. As a result, there will be no
small entity depositories covered by the rule, in their capacity as
data providers. If any of these entities operate as third parties, they
will be covered and counted as third parties. The CFPB is not able to
estimate with precision the number of small nondepository entities that
will be subject to the rule, but expects that approximately 100 small
nondepository institutions will be data providers under the rule. In
addition, based on data from the Provider Collection and Aggregator
Collection, the CFPB estimates that between 6,800 and 9,500 small
entities are third parties that access consumer-authorized data.
[GRAPHIC] [TIFF OMITTED] TR18NO24.001
[GRAPHIC] [TIFF OMITTED] TR18NO24.002
[[Page 90987]]
BILLING CODE 4810-AM-C
5. Projected Reporting, Recordkeeping, and Other Compliance
Requirements of the Rule, Including an Estimate of the Classes of Small
Entities Which Will Be Subject to the Requirement and the Type of
Professional Skills Necessary for the Preparation of the Report or
Record
The rule will impose new reporting, recordkeeping, and other
compliance requirements on small entities subject to the rule, which
excludes small depository data providers. These requirements generally
differ for small entities in two classes: nondepository data providers
and third parties. Part VI.E provides a detailed description of the
requirements and estimated compliance costs that will be faced by
affected small entities under the rule. These requirements will be
imposed on an estimated 100 small nondepository data providers and
between 6,800 and 9,500 small third parties, as shown in table 2. The
requirements and their costs are summarized in this section.
Requirements for Nondepository Data Providers
The rule will require nondepository data providers to calculate and
disclose the response rate for third party data access on a monthly
basis. The CFPB estimates that data providers may face a $7,600 cost of
developing and testing a system to regularly disclose this information
on their websites. The CFPB expects these reports will generally be
automated and will have minimal ongoing costs after the system is
implemented.
The rule will require nondepository data providers to have policies
and procedures to retain records to demonstrate compliance with certain
other requirements of the rule. Data providers will also be required to
have policies and procedures designed to ensure that the reason for the
decision to decline a third party's request to access its developer
interface is communicated to the third party. The CFPB expects that
these recordkeeping requirements will likely be built into a data
provider's developer interface and the cost methodology described in
part IV.E.1 includes these in the overall cost of establishing and
maintaining a compliant developer interface. Incremental costs of these
requirements are limited to developing and implementing reasonable
policies and procedures, which the CFPB estimates will cost $23,500 to
$51,200 per data provider.
The rule requires nondepository data providers to maintain a
consumer interface that allows consumers to directly access their data.
As discussed in part VI.E.1, the CFPB expects that data providers
subject to this requirement generally already provide the required
information under the baseline and estimates that the incremental costs
of this requirement will be minimal.
The rule requires nondepository data providers to maintain a
developer interface. As described in part VI.E.1, the CFPB expects that
most nondepository data providers will develop and maintain their
developer interfaces in-house. For small nondepository data providers
that choose to build their developer interface in-house, the estimated
upfront cost is $46,000. Estimated annual costs for in-house developer
interfaces include technology costs of $20,000 as well as ongoing
staffing costs of $48,000 to $95,000.
The rule requires data providers to have policies and procedures to
ensure that data are accurately transferred to third parties. In the
cost methodology described in part IV.E.1, the CFPB includes these
costs in the estimate for establishing and maintaining a compliant
developer interface.
Satisfying these requirements for data providers would generally
involve professional skills related to software development, general
and operational management, legal expertise, compliance, and customer
support.
Requirements for Third Parties
Third parties are not subject to reporting requirements but will be
required to retain records of consumer data access requests and actions
taken in response to these requests, reasons for not making the data
available, and data access denials under the rule. The CFPB understands
that most third parties maintain similar records and costs will be
limited to a one-time change to existing systems and small storage
costs. The CFPB estimates a one-time cost of $10,100 for third parties
to develop and implement appropriate policies and procedures, with
minimal ongoing costs.
The rule requires third parties to establish and maintain systems
that receive data access revocation requests, track duration-limited
authorizations, delete data when required due to revoked or lapsed
authorizations, and retain the relevant records. The CFPB estimates
that the one-time cost to establish these systems will be between
$22,800 and $94,900, with minimal ongoing costs.
The rule requires third parties to provide authorization disclosure
and certification statements. The CFPB estimates that the one-time cost
to third parties of establishing an automated system to provide these
disclosures would be $94,000. However, the CFPB expects that small
third parties will generally use another third party to provide these
disclosures and this cost will not be incurred. If third parties
currently provide disclosures, modifying the content to comply with the
proposed rule is estimated to cost between $2,900 and $3,800.
Satisfying these requirements for data providers will generally
involve professional skills related to software development, general
and operational management, legal expertise, compliance, and customer
support.
As discussed in part VI.E.1, the CFPB does not expect the new
financial data processing products or services definition to impose
costs on small entities.
6. Description of Steps the Agency Has Taken To Minimize the
Significant Economic Impact on Small Entities Consistent With the
Stated Objectives of Applicable Statutes, Including a Statement of the
Factual, Policy, and Legal Reasons for Selecting the Alternative
Adopted in the Final Rule and Why Each One of the Other Significant
Alternatives to the Rule Considered by the Agency Which Affect the
Impact on Small Entities Was Rejected
In the proposal, the CFPB considered several alternatives to the
proposal that would minimize economic impacts on small entities. These
alternatives generally fell into four categories: (1) limiting coverage
of small data providers, (2) permitting small data providers to charge
fees for making covered data available, (3) exemptions from the
proposed rule for small third parties, or (4) alternative compliance
dates for small depository data providers.
In the final rule, small depositories are not covered data
providers. While the CFPB considered more limited alternatives for
excluding depository data providers from coverage in the proposal,
comments from the SBA Office of Advocacy and data provider commenters
nearly universally favored coverage definitions that would reduce
burden for a larger number of small depository data providers. The CFPB
has revised the coverage of depository data providers in the final rule
to reduce the burden on small depository data providers, thereby
addressing these comments.
The CFPB considered not covering small nondepository data
providers.
[[Page 90988]]
However, as discussed in part VII.B.3, the CFPB has determined that
compliance burdens are likely to be lower for these small entities as
compared to small depositories, and that extended compliance timelines
would better address burden on small nondepositories while still
accomplishing the goals of the rulemaking.
The CFPB also considered the alternative of permitting small data
providers to charge fees for making covered data available through
developer interfaces. Given the change in coverage in the final rule,
this alternative would only affect small nondepository data providers.
The CFPB has determined that a data provider charging such fees would
be inconsistent with the data provider's statutory obligation under
CFPA section 1033 to make covered data available to consumers and to
their authorized third party representatives. Further, consumers at
covered small data providers could be harmed through reduced access to
third parties' products and services if the CFPB were to permit only
small data providers to charge fees.
The CFPB also considered exemptions as a means to reduce burden for
small entity third parties. Based on data from the Aggregator
Collection, the CFPB estimates that there are approximately 6,800 to
9,500 third parties with fewer than 100,000 connected accounts, many of
which may be small entities. However, exempting third parties from
certain conditions of access under the rule, such as the requirements
on collection, use, and retention, would likely create risks of harm
for consumers on data security and privacy grounds, provide unfair
competitive advantages for exempt versus non-exempt third parties, and
increase the risks of losses from data security incidents for consumers
and data providers.
Finally, the CFPB considered alternative compliance dates for small
entities to reduce burden. The proposed rule had a compliance date of
approximately four years after the final rule is published in the
Federal Register for depository data providers with less than $850
million in assets. In the final rule, small depositories are not
covered as data providers. For small nondepository data providers, the
CFPB has extended the compliance date from approximately one year after
the final rule is published in the Federal Register to approximately
2.5 years after publication. The CFPB expects this will substantially
reduce compliance burden on small nondepository data providers.
Regarding potential burden for small third parties, the CFPB has also
extended the earliest compliance dates that apply to the largest data
providers from six months to approximately 1.5 years and published the
Industry Standard-Setting Final Rule in June 2024 to encourage the
establishment of consensus standards in the near future. The CFPB
expects these changes to effectively increase the amount of time small
third parties have to come into compliance with the rule, reducing
their compliance burden.
7. Description of the Steps the Agency Has Taken To Minimize Any
Additional Cost of Credit for Small Entities
The CFPB expects that the rule may have some limited impact on the
cost or availability of credit for small entities but does not expect
that the impact will be substantial. The CFPB expects there are several
ways the rule could potentially impact the cost or availability of
credit to small entities. First, the provisions of the rule could
impact the availability of credit to small entities if small businesses
are using loans from lenders (either data providers or third parties)
affected by the provisions and the provisions lead to a contraction of
the offered services. Second, the rule could potentially increase the
cost of credit for small businesses if the costs of implementing the
rule are passed through in the form of higher prices on loans from
lenders. Third, for small business owners that use consumer-authorized
data to qualify for or access credit, the provisions could potentially
increase credit availability or lower costs for small entities by
facilitating increased data access.\223\ Small entity representatives
did not provide feedback on this topic during the SBREFA process.\224\
The CFPB did not have data to quantify these potential impacts in the
proposal.
---------------------------------------------------------------------------
\223\ As an example, Howell et al. found that more automated
fintech lenders facilitated a higher share of Paycheck Protection
Program loans to small, Black-owned firms relative to traditional
lenders. Sabrina T. Howell et al., Lender Automation and Racial
Disparities in Credit Access, 79 J. Fin. 1457-1512 (202), https://doi.org/10.1111/jofi.13303.
\224\ SBREFA Panel Report at 40.
---------------------------------------------------------------------------
The CFPB requested comment on its analysis of the proposal's impact
on the cost of credit for small entities, and requested data or
evidence on these potential impacts. One consumer advocate commenter
stated that open banking and access to online providers give small
businesses access to new services, but cited a study finding that
surveyed small businesses had lower satisfaction with online lenders
than with small banks.\225\ The CFPB expects that the rule will
generally improve small businesses' ability to use online financial
services, increasing their options for credit. The CFPB also expects
that the final rule's coverage and extended implementation periods will
reduce compliance burden on small depositories relative to the
proposal, mitigating negative effects on credit access.
---------------------------------------------------------------------------
\225\ Fed. Rsrv. Banks, 2023 Report on Employer Firms: Findings
from the 2022 Small Business Credit Survey (Mar. 2023), https://doi.org/10.55350/sbcs-20230308.
---------------------------------------------------------------------------
VIII. Paperwork Reduction Act
Under the Paperwork Reduction Act of 1995 (PRA),\226\ Federal
agencies are generally required to seek, prior to implementation,
approval from OMB for information collection requirements. Under the
PRA, the CFPB may not conduct or sponsor, and, notwithstanding any
other provision of law, a person is not required to respond to, an
information collection unless the information collection displays a
valid control number assigned by OMB.
---------------------------------------------------------------------------
\226\ 44 U.S.C. 3501 et seq.
---------------------------------------------------------------------------
As part of its continuing effort to reduce paperwork and respondent
burden, the CFPB conducted a preclearance consultation program to
provide the general public and Federal agencies with an opportunity to
comment on the information collection requirements in accordance with
the PRA. This helps ensure that the public understands the CFPB's
requirements or instructions, respondents can provide the requested
data in the desired format, reporting burden (time and financial
resources) is minimized, information collection instruments are clearly
understood, and the CFPB can properly assess the impact of information
collection requirements on respondents.
The rule amends and adds to 12 CFR part 1033 and amends 12 CFR part
1001. The rule contains seven new information collection requirements.
1. Obligation to make covered data available (Sec. 1033.201),
including general requirements (Sec. 1033.301) and requirements
applicable to developer interface (Sec. 1033.311).
2. Information about the data provider (Sec. 1033.341).
3. Policies and procedures for data providers (Sec. 1033.351).
4. Third party authorization; general (Sec. 1033.401), including
the authorization disclosure (Sec. 1033.411).
5. Third party obligations (Sec. 1033.421).
6. Use of data aggregator (Sec. 1033.431).
7. Policies and procedures for third party record retention (Sec.
1033.441).
The information collection requirements in this final rule are
mandatory.
[[Page 90989]]
The collections of information contained in this rule, and
identified as such, have been submitted to OMB for review under section
3507(d) of the PRA. A complete description of the information
collection requirements (including the burden estimate methods) is
provided in the information collection request (ICR) that the CFPB has
submitted to OMB under the requirements of the PRA. The ICR submitted
to OMB requesting approval under the PRA for the information collection
requirements contained herein is available at www.regulations.gov as
well as on OMB's public-facing docket at www.reginfo.gov.
Title of Collection: 12 CFR part 1033.
OMB Control Number: 3170-XXXX.
Type of Review: New collection.
Affected Public: Private sector.
Estimated Number of Respondents: 10,285.
Estimated Total Annual Burden Hours: 1,435,650 annually and
5,664,085 one-time.
The CFPB will publish a separate Federal Register notice once OMB
concludes its review announcing OMB approval of the information
collections contained in this final rule.
In the proposal, the CFPB invited comments on: (1) Whether the
collection of information is necessary for the proper performance of
the functions of the CFPB, including whether the information will have
practical utility; (2) the accuracy of the CFPB's estimate of the
burden of the collection of information, including the validity of the
methods and the assumptions used; (3) ways to enhance the quality,
utility, and clarity of the information to be collected; and (4) ways
to minimize the burden of the collection of information on respondents,
including through the use of automated collection techniques or other
forms of information technology.
An industry association representing nondepositories commented that
the PRA analysis in the proposal underestimated the burden of the
information collection, particularly the costs estimated for policies
and procedures for data providers and third party record retention, and
the costs for data providers' obligations to make data available to
third parties. The commenter stated that the cost and burden of the
information collection would exceed the CFPB's estimate of 120 hours
annually per entity and would be prohibitively expensive for smaller
entities, and encouraged the CFPB to reconsider its estimate of the
burden from the information collection.
As discussed in part VI.E.1, the CFPB has increased its estimates
for the costs of developing policies and procedures for data providers;
these costs are estimated to be between $23,500 and $51,200 per data
provider. Regarding the estimated annual burden per entity of the
information collection, the CFPB expects that most burdens related to
record retention and making data available will be one-time costs to
develop and implement compliant systems. This is reflected in the
CFPB's estimate of larger one-time costs from the information
collection as compared to annual costs. Comments related to the one-
time and annual costs of record retention, making data available, and
policies and procedures are discussed in part VI.E.1. The CFPB did not
receive data or evidence that would allow it to further refine its
estimates of per entity annual costs, but notes that the overall costs
of the information collection have been reduced due to changes in the
coverage of the final rule.
The other comments on the rule generally are summarized above.
IX. Congressional Review Act
Pursuant to the Congressional Review Act (5 U.S.C. 801 et seq.),
the CFPB will submit a report containing this rule and other required
information to the U.S. Senate, the U.S. House of Representatives, and
the Comptroller General of the United States at least 60 days prior to
the rule's published effective date. The Office of Information and
Regulatory Affairs has designated this rule as a ``major rule'' as
defined by 5 U.S.C. 804(2).
X. Severability
The CFPB intends that, if any provision of the final rule, or any
application of a provision, is stayed or determined to be invalid, the
remaining provisions or applications are severable and shall continue
in effect.\227\
---------------------------------------------------------------------------
\227\ As non-exhaustive examples to illustrate the above, the
following are severable from the remainder of the rule: the
applicability of the rule to any type of data provider; the
applicability of the rule to any type of covered consumer financial
product or service; the applicability of the rule to any type of
covered data; the reference in any provision of the rule to
consensus standards; the fee prohibition in Sec. 1033.301(c); any
of the requirements for a developer interface under Sec. 1033.311;
and the applicability of Sec. 1001.2(b) to any activity. Moreover,
part 1033 and Sec. 1001.2(b) are each severable from the other.
---------------------------------------------------------------------------
However, this is subject to the following significant exception.
The CFPB considers data providers' obligations to provide data under 12
CFR part 1033 to authorized third parties to be inseparable from the
protections the CFPB is establishing in subpart D to ensure that
authorized third parties are acting on behalf of consumers.
Accordingly, if any of the provisions in subpart D were stayed or
determined to be invalid, the CFPB intends that subpart D, together
with references to third parties and authorized third parties elsewhere
in part 1033, shall not continue in effect. This would not affect
direct access by consumers to covered data under the remainder of part
1033, and it would also not affect the definition of financial product
or service under Sec. 1001.2(b).
The CFPB did not receive any comments opposing its approach to
severability.\228\
---------------------------------------------------------------------------
\228\ The CFPB notes that this severability clause is not
codified but forms an operative part of the rule.
---------------------------------------------------------------------------
List of Subjects
12 CFR Part 1001
Consumer protection, Credit.
12 CFR Part 1033
Banks, banking, Consumer protection, Credit, Credit Unions,
Electronic funds transfers, National banks, Privacy, Reporting and
recordkeeping requirements, Savings associations, Voluntary standards.
Authority and Issuance
For the reasons set forth in the preamble, the CFPB amends 12 CFR
parts 1001 and 1033 as set forth below:
PART 1001--FINANCIAL PRODUCTS OR SERVICES
0
1. The authority citation for Part 1001 continues to read as follows:
Authority: 12 U.S.C. 5481(15)(A)(XI); AND 12 U.S.C. 5512(B)(1).
0
2. Amend Sec. 1001.2 by adding paragraphs (b) and (c) to read as
follows:
Sec. 1001.2 Definitions.
* * * * *
(b) Providing financial data processing products or services by any
technological means, including processing, storing, aggregating, or
transmitting financial or banking data, alone or in connection with
another product or service, where the financial data processing is not
offered or provided by a person who, by operation of 12 U.S.C.
5481(15)(A)(vii)(I) or (II), is not a covered person.
(c) [Reserved]
0
3. Revise part 1033 to read as follows:
PART 1033--PERSONAL FINANCIAL DATA RIGHTS
Subpart A--General
Sec.
[[Page 90990]]
1033.101 Authority, purpose, and organization.
1033.111 Coverage of data providers.
1033.121 Compliance dates.
1033.131 Definitions.
1033.141 Standard-setting bodies.
Subpart B--Making Covered Data Available
1033.201 Availability and prohibition against evasion.
1033.211 Covered data.
1033.221 Exceptions.
Subpart C--Data Provider Interfaces; Responding to Requests
1033.301 General requirements.
1033.311 Requirements applicable to developer interface.
1033.321 Interface access.
1033.331 Responding to requests for information.
1033.341 Information about the data provider.
1033.351 Policies and procedures.
Subpart D--Authorized Third Parties
1033.401 Third party authorization; General.
1033.411 Authorization disclosure.
1033.421 Third party obligations.
1033.431 Use of data aggregator.
1033.441 Policies and procedures for third party record retention.
Appendix A to Part 1033--Personal Financial Data Rights Rule: How To
Apply for Recognition as a Standard Setter
Authority: 12 U.S.C. 5512; 12 U.S.C. 5514; 12 U.S.C. 5533.
Subpart A--General
Sec. 1033.101 Authority, purpose, and organization.
(a) Authority. The regulation in this part is issued by the
Consumer Financial Protection Bureau (CFPB) pursuant to the Consumer
Financial Protection Act of 2010 (CFPA), Pub. L. 111-203, tit. X, 124
Stat. 1955.
(b) Purpose. This part implements the provisions of section 1033 of
the CFPA by requiring data providers to make available to consumers and
authorized third parties, upon request, covered data in the data
provider's control or possession concerning a covered consumer
financial product or service, in an electronic form usable by consumers
and authorized third parties; and by prescribing standards to promote
the development and use of standardized formats for covered data,
including through industry standards developed by standard-setting
bodies recognized by the CFPB. This part also sets forth obligations of
third parties that would access covered data on a consumer's behalf,
including limitations on their collection, use, and retention of
covered data.
(c) Organization. This part is divided into subparts as follows:
(1) Subpart A establishes the authority, purpose, organization,
coverage of data providers, compliance dates, and definitions
applicable to this part.
(2) Subpart B provides the general obligation of data providers to
make covered data available upon the request of a consumer or
authorized third party, including what types of information must be
made available.
(3) Subpart C provides the requirements for data providers to
establish and maintain interfaces to receive and respond to requests
for covered data.
(4) Subpart D provides the obligations of third parties that would
access covered data on behalf of a consumer.
(5) Appendix A to this part provides instructions for how a
standard-setting body would apply for CFPB recognition.
Sec. 1033.111 Coverage of data providers.
(a) Coverage of data providers. A data provider has obligations
under this part if it controls or possesses covered data concerning a
covered consumer financial product or service that the consumer
obtained from the data provider, subject to the exclusion in paragraph
(d) of this section.
(b) Definition of covered consumer financial product or service.
Covered consumer financial product or service means a consumer
financial product or service, as defined in 12 U.S.C. 5481(5), that is:
(1) A Regulation E account, which means an account, as defined in
Regulation E, 12 CFR 1005.2(b);
(2) A Regulation Z credit card, which means a credit card, as
defined in Regulation Z, 12 CFR 1026.2(a)(15)(i); or
(3) Facilitation of payments from a Regulation E account or
Regulation Z credit card, excluding products or services that merely
facilitate first party payments. For purposes of this part, a first
party payment is a transfer initiated by the payee or an agent acting
on behalf of the underlying payee. First party payments include
payments initiated by loan servicers.
(c) Definition of data provider. Data provider means a covered
person, as defined in 12 U.S.C. 5481(6), that is:
(1) A financial institution, as defined in Regulation E, 12 CFR
1005.2(i);
(2) A card issuer, as defined in Regulation Z, 12 CFR 1026.2(a)(7);
or
(3) Any other person that controls or possesses information
concerning a covered consumer financial product or service that the
consumer obtained from that person.
Example 1 to paragraph (c): A digital wallet provider is a data
provider.
(d) Coverage threshold--Certain depository institutions. The
requirements of subparts B and C of this part do not apply to data
providers defined under paragraphs (c)(1) through (3) of this section
that are depository institutions that hold total assets equal to or
less than the Small Business Administration (SBA) size standard, as
determined in accordance with this paragraph (d). If at any point a
depository institution that held total assets greater than that SBA
size standard as of or at any point after January 17, 2025 subsequently
holds total assets below that amount, the requirements of subparts B
and C of this part continue to apply.
(1) Determining SBA size standard. For purposes of paragraph (d) of
this section, the SBA size standard is the SBA size standard for the
data provider's appropriate North American Industry Classification
System (NAICS) code for commercial banking, credit unions, savings
institutions and other depository credit intermediation, or credit card
issuing, as codified in 13 CFR 121.201.
(2) Calculating total assets. For purposes of paragraph (d) of this
section, total assets held by a depository institution are determined
by averaging the assets reported on its own four preceding quarterly
call report submissions to the Federal Financial Institutions
Examination Council or National Credit Union Association, as
applicable, or its submissions to the appropriate oversight body to the
extent it does not submit such reports to the Federal Financial
Examination Council or National Credit Union Administration.
(3) Merger or acquisition--coverage of surviving depository
institution when there are not four quarterly call report submissions.
After a merger or acquisition the surviving depository institution
shall determine quarterly assets prior to the merger or acquisition by
using the combined assets reported on the quarterly call report
submissions by all predecessor depository institutions. The surviving
depository institution shall determine quarterly assets after the
merger or acquisition by using the assets reported on the quarterly
call report submissions by the surviving depository institution. The
surviving depository institution shall determine total assets by using
the average of the quarterly assets for the four preceding quarters,
whether the quarterly assets are the combined assets of the predecessor
depository institutions or from the surviving depository institution.
[[Page 90991]]
Sec. 1033.121 Compliance dates.
(a) Determining assets and revenue for purposes of initial
compliance dates. A data provider's compliance date in paragraph (b) of
this section is based on the calculation of total assets or total
receipts, as appropriate, described in paragraphs (a)(1) and (2) of
this section.
(1) With respect to a depository institution data provider, total
assets are determined by averaging the assets reported on its 2023
third quarter, 2023 fourth quarter, 2024 first quarter, and 2024 second
quarter call report submissions to the Federal Financial Institutions
Examination Council or National Credit Union Administration, as
applicable, or its submissions to the appropriate oversight body to the
extent it does not submit such reports to the Federal Financial
Examination Council or National Credit Union Administration. If, as a
result of a merger or acquisition, a depository institution data
provider does not have the named four quarterly call report
submissions, the depository institution data provider shall use the
process set out in Sec. 1033.111(d)(3) to determine total assets for
the time period named in this paragraph (a)(1).
(2) With respect to a nondepository institution data provider,
total receipts are calculated based on the SBA definition of receipts,
as codified in 13 CFR 121.104(a).
(b) Initial compliance dates. A data provider defined under Sec.
1033.111(c)(1) through (3) must comply with the requirements in
subparts B and C of this part beginning on:
(1) April 1, 2026, for depository institution data providers that
hold at least $250 billion in total assets and nondepository
institution data providers that generated at least $10 billion in total
receipts in either calendar year 2023 or calendar year 2024.
(2) April 1, 2027, for data providers that are:
(i) Depository institutions that hold at least $10 billion in total
assets but less than $250 billion in total assets; or
(ii) Nondepository institutions that did not generate $10 billion
or more in total receipts in both calendar year 2023 and calendar year
2024.
(3) April 1, 2028, for depository institution data providers that
hold at least $3 billion in total assets but less than $10 billion in
total assets.
(4) April 1, 2029, for depository institution data providers that
hold at least $1.5 billion in total assets but less than $3 billion in
total assets.
(5) April 1, 2030, for depository institution data providers that
hold less than $1.5 billion in total assets but more than $850 million
in total assets.
(c) Compliance dates for depository institution data providers that
subsequently cross coverage threshold. A depository institution data
provider under Sec. 1033.111(c)(1) through (3) that has total assets
as calculated in Sec. 1033.111(d)(2) equal to or less than the SBA
size standard as determined in accordance with Sec. 1033.111(d)(1),
but that subsequently holds total assets that exceed that SBA size
standard, as measured in Sec. 1033.111(d)(2), must comply with the
requirements in subparts B and C of this part within a reasonable
amount of time after exceeding the size standard, not to exceed five
years.
Sec. 1033.131 Definitions.
For purposes of this part, the following definitions apply:
Authorized third party means a third party that has complied with
the authorization procedures described in Sec. 1033.401.
Card issuer is defined at Sec. 1033.111(c)(2).
Consensus standard means a standard that is adopted by a recognized
standard setter and that continues to be maintained by that recognized
standard setter.
Consumer means a natural person. Trusts established for tax or
estate planning purposes are considered natural persons for purposes of
this definition. Consumer also includes guardians, trustees,
custodians, or other similar natural persons acting on behalf of a
consumer pursuant to State law.
Consumer interface means an interface through which a data provider
receives requests for covered data and makes available covered data in
an electronic form usable by consumers in response to the requests.
Covered consumer financial product or service is defined at Sec.
1033.111(b).
Covered data is defined at Sec. 1033.211.
Data aggregator means a person that is retained by and provides
services to the authorized third party to enable access to covered
data.
Data provider is defined at Sec. 1033.111(c).
Depository institution means any depository institution as defined
by the Federal Deposit Insurance Act, 12 U.S.C. 1813(c)(1), or any
credit union as defined by 12 CFR 700.2.
Developer interface means an interface through which a data
provider receives requests for covered data and makes available covered
data in an electronic form usable by authorized third parties in
response to the requests.
Financial institution is defined at Sec. 1033.111(c)(1).
Recognized standard setter means a standard-setting body that has
been recognized by the CFPB under Sec. 1033.141.
Regulation E account is defined at Sec. 1033.111(b)(1).
Regulation Z credit card is defined at Sec. 1033.111(b)(2).
Third party means any person that is not the consumer about whom
the covered data pertains or the data provider that controls or
possesses the consumer's covered data.
Sec. 1033.141 Standard-setting bodies.
(a) Recognition of a standard-setting body. A standard-setting body
may request CFPB recognition. Recognition will last up to five years,
absent revocation. The CFPB will not recognize a standard-setting body
unless it demonstrates that it satisfies the following attributes:
(1) Openness. The sources, procedures, and processes used are open
to all interested parties, including: consumer and other public
interest groups with expertise in consumer protection, financial
services, community development, fair lending, and civil rights;
authorized third parties; data providers; data recipients; data
aggregators and other providers of services to authorized third
parties; and relevant trade associations. Parties can meaningfully
participate in standards development on a non-discriminatory basis.
(2) Balance. The decision-making power is balanced across all
interested parties, including consumer and other public interest
groups, and is reflected at all levels of the standard-setting body.
There is meaningful representation for large and small commercial
entities within these categories. No single interest or set of
interests dominates decision-making. Achieving balance requires
recognition that, even when a participant may play multiple roles, such
as data provider and authorized third party, the weight of that
participant's commercial concerns may align primarily with one set of
interests. The ownership of participants is considered in achieving
balance.
(3) Due process and appeals. The standard-setting body uses
documented and publicly available policies and procedures, and it
provides adequate notice of meetings and standards development,
sufficient time to review drafts and prepare views and objections,
access to views and objections of other participants, and a fair and
impartial process for resolving conflicting views. An appeals process
is available for the impartial handling of procedural appeals.
(4) Consensus. Standards development proceeds by consensus,
[[Page 90992]]
which is defined as general agreement, though not necessarily
unanimity. During the development of consensus, comments and objections
are considered using fair, impartial, open, and transparent processes.
(5) Transparency. Procedures or processes for participating in
standards development and for developing standards are transparent to
participants and publicly available.
Subpart B--Making Covered Data Available
Sec. 1033.201 Availability and prohibition against evasion.
(a) Obligation to make covered data available--(1) General. A data
provider must 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, in an electronic
form usable by consumers and authorized third parties.
(2) Prohibition against evasion. A data provider must not take any
action:
(i) With the intent of evading the requirements of subparts B and C
of this part;
(ii) That the data provider knows or should know is likely to
render unusable the covered data that the data provider makes
available; or
(iii) That the data provider knows or should know is likely to
prevent, interfere with, or materially discourage a consumer or
authorized third party from accessing covered data consistent with this
part.
(b) Current data. In complying with paragraph (a) of this section,
a data provider must make available the most recently updated covered
data that it has in its control or possession at the time of a request.
A data provider must make available information concerning authorized
but not yet settled transactions.
Sec. 1033.211 Covered data.
Covered data in this part means, as applicable:
(a) Transaction information, including historical transaction
information in the control or possession of the data provider. A data
provider is deemed to make available sufficient historical transaction
information for purposes of Sec. 1033.201(a)(1) if it makes available
at least 24 months of such information.
Example 1 to paragraph (a): This category includes amount,
transaction date, payment type, pending or authorized status, payee or
merchant name, rewards credits, and fees or finance charges.
(b) Account balance information.
(c) Information to initiate payment to or from a Regulation E
account directly or indirectly held by the data provider. This category
includes an account and routing number that can be used to initiate an
Automated Clearing House transaction.
(1) In complying with its obligation under Sec. 1033.201(a)(1), a
data provider is permitted to make available a tokenized account number
instead of, or in addition to, a non-tokenized account number, as long
as the tokenization is not used as a pretext to restrict competitive
use of payment initiation information.
(2) This paragraph (c) does not apply to data providers who do not
directly or indirectly hold the underlying Regulation E account. For
example, a data provider that merely facilitates pass-through payments
would not be required to make available account and routing number for
the underlying Regulation E account.
(d) Terms and conditions. For purposes of this section, terms and
conditions are limited to data in agreements evidencing the terms of
the legal obligation between a data provider and a consumer for a
covered consumer financial product or service, such data in the account
opening agreement and any amendments or additions to that agreement,
including pricing information.
Example 2 to paragraph (d): This category includes the applicable
fee schedule, any annual percentage rate or annual percentage yield,
credit limit, rewards program terms, whether a consumer has opted into
overdraft coverage, and whether a consumer has entered into an
arbitration agreement.
(e) Upcoming bill information.
Example 3 to paragraph (e): This category includes information
about third party bill payments scheduled through the data provider and
any upcoming payments due from the consumer to the data provider.
(f) Basic account verification information, which is limited to the
name, address, email address, and phone number associated with the
covered consumer financial product or service. If a data provider
directly or indirectly holds a Regulation E or Regulation Z account
belonging to the consumer, the data provider must also make available a
truncated account number or other identifier for that account.
Sec. 1033.221 Exceptions.
A data provider is not required to make available the following
covered data to a consumer or authorized third party:
(a) Any confidential commercial information, including an algorithm
used to derive credit scores or other risk scores or predictors.
Information does not qualify for this exception merely because it is an
input to, or an output of, an algorithm, risk score, or predictor. For
example, annual percentage rate and other pricing terms are sometimes
determined by an internal algorithm or predictor but do not fall within
this exception.
(b) Any information collected by the data provider for the sole
purpose of preventing fraud or money laundering, or detecting, or
making any report regarding other unlawful or potentially unlawful
conduct. Information collected for other purposes does not fall within
this exception. For example, name and other basic account verification
information do not fall within this exception.
(c) Any information required to be kept confidential by any other
provision of law. Information does not qualify for this exception
merely because the data provider must protect it for the consumer. For
example, the data provider cannot restrict access to the consumer's own
information merely because that information is subject to privacy
protections.
(d) Any information that the data provider cannot retrieve in the
ordinary course of its business with respect to that information.
Subpart C--Data Provider Interfaces; Responding to Requests
Sec. 1033.301 General requirements.
(a) Requirement to maintain interfaces. A data provider subject to
the requirements of this part must maintain a consumer interface and a
developer interface. The consumer interface and the developer interface
must satisfy the requirements set forth in this section. The developer
interface must satisfy the additional requirements set forth in Sec.
1033.311.
(b) Machine-readable files upon request. Upon request for covered
data in a machine-readable file, and subject to paragraphs (b)(1) and
(2) of this section, a data provider must make available to a consumer
or an authorized third party covered data in a file that is machine-
readable and that the consumer or authorized third party can retain and
transfer for processing into a separate information system that is
reasonably available to and in the control of the consumer or
authorized third party.
[[Page 90993]]
(1) Consumer interface. With respect to covered data provided
through its consumer interface, a data provider is not required to
comply with:
(i) The requirements of this paragraph (b) for the covered data
described in Sec. 1033.211(c) (payment initiation information) and (f)
(account verification information); and
(ii) The requirement of this paragraph (b) to provide in a file
that is machine-readable the covered data described in Sec.
1033.211(d) (terms and conditions).
(2) Developer interface. With respect to covered data provided
through its developer interface, a data provider satisfies the
requirements of this paragraph (b) if it makes available covered data
in a form that satisfies the requirements of Sec. 1033.311(b).
(c) Fees prohibited. A data provider must not impose any fees or
charges on a consumer or an authorized third party in connection with:
(1) Interfaces. Establishing or maintaining the interfaces required
by paragraph (a) of this section; or
(2) Requests. Receiving requests or making available covered data
in response to requests as required by this part.
Sec. 1033.311 Requirements applicable to developer interface.
(a) General. A developer interface required by Sec. 1033.301(a)
must satisfy the requirements set forth in this section.
(b) Standardized format. The developer interface must make
available covered data in a standardized and machine-readable format.
Indicia that the format satisfies this requirement include that it
conforms to a consensus standard.
(1) Meaning of format. For purposes of this section, format
includes structures and definitions of covered data and requirements
and protocols for communicating requests and responses for covered
data.
(2) Meaning of standardized. For purposes of this section,
standardized means conforms to a format widely used by other data
providers and designed to be readily usable by authorized third
parties.
(c) Commercially reasonable performance. A developer interface's
performance must be commercially reasonable.
(1) Response rate; quantitative minimum performance specification.
The performance of the interface cannot be commercially reasonable if
it does not meet the following quantitative minimum performance
specification regarding its response rate: The number of proper
responses by the interface divided by the total number of requests for
covered data to the interface must be equal to or greater than 99.5
percent in each calendar month. For purposes of this paragraph (c)(1),
all of the following requirements apply:
(i) Any responses by and requests to the interface during scheduled
downtime for the interface must be excluded respectively from the
numerator and the denominator of the calculation.
(ii) In order for any downtime of the interface to qualify as
scheduled downtime, the data provider must have provided reasonable
notice of the downtime to all third parties to which the data provider
has granted access to the interface. Indicia that the data provider's
notice of the downtime may be reasonable include that the notice
conforms to a consensus standard.
(iii) The total amount of scheduled downtime for the interface in a
calendar month must be reasonable. Indicia that the total amount of
scheduled downtime may be reasonable include that the amount conforms
to a consensus standard.
(iv) A proper response is a response, other than any message
provided during unscheduled downtime of the interface, that meets all
of the following criteria:
(A) The response either fulfills the request or explains why the
request was not fulfilled;
(B) The response is consistent with the reasonable written policies
and procedures that the data provider establishes and maintains
pursuant to Sec. 1033.351(a); and
(C) The response is provided by the interface within a commercially
reasonable amount of time. Indicia that a response is provided in a
commercially reasonable amount of time include conformance to an
applicable consensus standard.
(2) Indicia of compliance--(i) Indicia. Indicia that a developer
interface's performance is commercially reasonable as required by
paragraph (c) of this section include:
(A) Whether the interface's performance conforms to a consensus
standard that is applicable to the data provider;
(B) How the interface's performance compares to the performance
levels achieved by the developer interfaces of similarly situated data
providers; and
(C) How the interface's performance compares to the performance
levels achieved by the data provider's consumer interface.
(ii) Performance specifications. For each of the three indicia set
forth in paragraph (c)(2)(i) of this section, relevant performance
specifications include:
(A) The interface's response rate as defined in paragraphs (c)(1)
through (iv) of this section;
(B) The interface's total amount of scheduled downtime;
(C) The amount of time in advance of any scheduled downtime by
which notice of the downtime is provided;
(D) The interface's total amount of unscheduled downtime; and
(E) The interface's response time.
(d) Access caps. Except as otherwise permitted by Sec. Sec.
1033.221, 1033.321, and 1033.331(b) and (c), a data provider must not
unreasonably restrict the frequency with which it receives or responds
to requests for covered data from an authorized third party through its
developer interface. 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 and
maintains pursuant to Sec. 1033.351(a). Indicia that any frequency
restrictions applied are reasonable include that they conform to a
consensus standard.
(e) Security specifications--(1) Access credentials. A data
provider must not allow a third party to access the data provider's
developer interface by using any credentials that a consumer uses to
access the consumer interface. A contract between a data provider and
the data provider's service provider, pursuant to which the service
provider establishes or maintains the data provider's developer
interface, does not violate this paragraph (e)(1) if the contract
provides that the service provider will make covered data available, in
a form and manner that satisfies the requirements of this part, to
authorized third parties through the developer interface by means of
the service provider using a consumer's credentials to access the data
from the data provider's consumer interface.
(2) Security program. (i) A data provider must apply to the
developer interface an information security program that satisfies the
applicable rules issued pursuant to section 501 of the Gramm-Leach-
Bliley Act, 15 U.S.C. 6801; or
(ii) If the data provider is not subject to section 501 of the
Gramm-Leach-Bliley Act, the data provider must apply to its developer
interface the information security program required by the Federal
Trade Commission's Standards for Safeguarding Customer Information, 16
CFR part 314.
[[Page 90994]]
Sec. 1033.321 Interface access.
(a) Denials related to risk management. A data provider does not
violate the general obligation in Sec. 1033.201(a)(1) by denying a
consumer or third party access to all elements of the interface
described in Sec. 1033.301(a) if:
(1) Granting access would be inconsistent with policies and
procedures reasonably designed to comply with:
(i) Safety and soundness standards of a prudential regulator, as
defined at 12 U.S.C. 5481(24), of the data provider;
(ii) Information security standards required by section 501 of the
Gramm-Leach-Bliley Act, 15 U.S.C. 6801; or
(iii) Other applicable laws and regulations regarding risk
management; and
(2) The denial is reasonable pursuant to paragraph (b) of this
section.
(b) Requirements for reasonable denials. A denial is reasonable
pursuant to paragraph (a)(2) of this section if it is:
(1) Directly related to a specific risk of which the data provider
is aware, such as a failure of a third party to maintain adequate data
security; and
(2) Applied in a consistent and non-discriminatory manner.
(c) Indicia bearing on reasonable denials. Indicia bearing on the
reasonableness of a denial pursuant to paragraph (b) of this section
include:
(1) Whether the denial adheres to a consensus standard related to
risk management;
(2) Whether the denial proceeds from standardized risk management
criteria that are available to the third party upon request; and
(3) Whether the third party has a certification or other
identification of fitness to access covered data that is issued or
recognized by a recognized standard setter or the CFPB.
(d) Conditions sufficient to justify a denial. Each of the
following is a sufficient basis for denying access to a third party:
(1) The third party does not present any evidence that its
information security practices are adequate to safeguard the covered
data; or
(2) The third party does not make the following information
available in both human-readable and machine-readable formats, and
readily identifiable to members of the public, meaning the information
must be at least as available as it would be on a public website:
(i) Its legal name and, if applicable, any assumed name it is using
while doing business with the consumer;
(ii) A link to its website;
(iii) Its Legal Entity Identifier (LEI) that is issued by:
(A) A utility endorsed by the LEI Regulatory Oversight Committee,
or
(B) A utility endorsed or otherwise governed by the Global LEI
Foundation (or any successor thereof) after the Global LEI Foundation
assumes operational governance of the global LEI system; and
(iv) Contact information a data provider can use to inquire about
the third party's information security and compliance practices.
Sec. 1033.331 Responding to requests for information.
(a) Responding to requests--access by consumers. To comply with the
requirements in Sec. 1033.201(a)(1), upon request from a consumer, a
data provider must make available covered data when it receives
information sufficient to:
(1) Authenticate the consumer's identity; and
(2) Identify the scope of the data requested.
(b) Responding to requests--access by third parties. (1) To comply
with the requirements in Sec. 1033.201(a)(1), upon request from an
authorized third party, a data provider must make available covered
data when it receives information sufficient to:
(i) Authenticate the consumer's identity;
(ii) Authenticate the third party's identity;
(iii) Document the third party has followed the authorization
procedures in Sec. 1033.401; and
(iv) Identify the scope of the data requested.
(2) The data provider is permitted to confirm the scope of a third
party's authorization to access the consumer's data by asking the
consumer to confirm:
(i) The account(s) to which the third party is seeking access; and
(ii) The categories of covered data the third party is requesting
to access, as disclosed by the third party pursuant to Sec.
1033.411(b)(4).
Example 1 to paragraph (b): An authorized third party that a data
provider has authenticated requests covered data on behalf of an
authenticated consumer through the data provider's developer interface.
The data provider asks the consumer to confirm the scope of the third
party's authorization using a means of communication that the consumer
is not accustomed to using with the data provider and that the data
provider knows or should know will take a long period of time to reach
the consumer and allow the consumer to respond with the confirmation.
As a result of the long wait time, the consumer cannot provide a timely
confirmation, delaying the third party's access to the covered data.
This data provider has violated the Sec. 1033.201(a)(2) prohibition
against evasion by taking an action that the data provider knows or
should know is likely to interfere with an authorized third party's
access to covered data.
(c) Covered data not required to be made available. A data provider
is not required to make covered data available in response to a request
when:
(1) The data are withheld because an exception described in Sec.
1033.221 applies;
(2) The data are not in the data provider's control or possession,
consistent with the requirement in Sec. 1033.201(a)(1).
(3) The data provider's interface is not available when the data
provider receives a request requiring a response under this section.
However, the data provider is subject to the performance specifications
in Sec. 1033.311(c);
(4) The request is for access by a third party; and
(i) The consumer has revoked the third party's authorization
pursuant to paragraph (e) of this section;
(ii) The data provider has received notice that the consumer has
revoked the third party's authorization pursuant to Sec.
1033.421(h)(2); or
(iii) The consumer has not provided a new authorization to the
third party after the maximum duration period, as described in Sec.
1033.421(b)(2).
(5) The data provider has not received information sufficient to
satisfy the conditions in paragraph(a) or (b) of this section.
(d) Jointly held accounts. A data provider that receives a request
for covered data from a consumer that jointly holds an account or from
an authorized third party acting on behalf of such a consumer must make
available covered data to that consumer or authorized third party,
subject to the other provisions of this section.
(e) Method to revoke third party authorization to access covered
data. A data provider does not violate the general obligation in Sec.
1033.201(a)(1) by making available to the consumer a reasonable method
to revoke any third party's authorization to access all of the
consumer's covered data, provided that such method does not violate
Sec. 1033.201(a)(2). Indicia that the data provider's revocation
method is reasonable include its conformance to a consensus standard. A
data provider that receives a revocation request from a consumer
through a revocation method it makes available must revoke the
authorized third party's access and
[[Page 90995]]
notify the authorized third party of the request in a timely manner.
Sec. 1033.341 Information about the data provider.
(a) Requirement to make information about the data provider readily
identifiable. A data provider must make the information described in
paragraphs (b) through (d) of this section:
(1) Readily identifiable to members of the public, meaning the
information must be at least as available as it would be on a public
website; and
(2) Available in both human-readable and machine-readable formats.
(b) Identifying information. A data provider must disclose in the
manner required by paragraph (a) of this section:
(1) Its legal name and, if applicable, any assumed name it is using
while doing business with the consumer;
(2) A link to its website;
(3) Its LEI that is issued by:
(i) A utility endorsed by the LEI Regulatory Oversight Committee,
or
(ii) A utility endorsed or otherwise governed by the Global LEI
Foundation (or any successor thereof) after the Global LEI Foundation
assumes operational governance of the global LEI system; and
(4) Contact information that enables a consumer or third party to
receive answers to questions about accessing covered data under this
part.
(c) Developer interface documentation. For its developer interface,
a data provider must disclose in the manner required by paragraph (a)
of this section documentation, including metadata describing all
covered data and their corresponding data fields, and other
documentation sufficient for a third party to access and use the
interface. A data provider is not required to make publicly available
information that would impede its ability to deny a third party access
to its developer interface, consistent with Sec. 1033.321. Indicia
that documentation is sufficient for a third party to access and use a
developer interface include conformance to a consensus standard. The
documentation must:
(1) Be maintained and updated as reasonably necessary for third
parties to access and use the interface in accordance with the terms to
which data providers are subject under this part;
(2) Include how third parties can get technical support and report
issues with the interface; and
(3) Be easy to understand and use, similar to data providers'
documentation for other commercially available products.
(d) Performance disclosure. On or before the final day of each
calendar month, a data provider must disclose in the manner required by
paragraph (a) of this section the quantitative minimum performance
specification for the response rate described in Sec.
1033.311(c)(1)(i) through (iv) that the data provider's developer
interface achieved in the previous calendar month. The data provider's
disclosure must include at least a rolling 13 months of the required
monthly figure, except that the disclosure need not include the monthly
figure for months prior to the compliance date applicable to the data
provider. The data provider must disclose the metric as a percentage
rounded to four decimal places, such as ``99.9999 percent.''
Sec. 1033.351 Policies and procedures.
(a) Reasonable written policies and procedures. A data provider
must establish and maintain written policies and procedures that are
reasonably designed to achieve the objectives set forth in subparts B
and C of this part, including paragraphs (b) through (d) of this
section. Policies and procedures must be appropriate to the size,
nature, and complexity of the data provider's activities. A data
provider has flexibility to design policies and procedures to avoid
acting inconsistently with its other legal obligations, or in a way
that could reasonably hinder enforcement against unlawful or
potentially unlawful conduct. A data provider must periodically review
the policies and procedures required by this section and update them as
appropriate to ensure their continued effectiveness.
(b) Policies and procedures for making covered data available. The
policies and procedures required by paragraph (a) of this section must
be reasonably designed to ensure that:
(1) Making available covered data. A data provider creates a record
of the data fields of covered data in the data provider's control or
possession, what covered data are not made available through a consumer
or developer interface pursuant to an exception in Sec. 1033.221, and
the reasons the exception applies. Indicia that a data provider's
record of such data fields complies with the requirements of this
paragraph (b)(1) include listing data fields that conform to those
published by a consensus standard.
(2) Denials of developer interface access. When a data provider
denies a third party access to a developer interface pursuant to Sec.
1033.321, the data provider:
(i) Creates a record substantiating the basis for denial; and
(ii) Communicates in a timely manner to the third party,
electronically or in writing, the reason(s) for the denial.
(3) Denials of information requests. When a data provider denies a
request for information for a reason described in Sec. 1033.331(c), to
the extent the communication of the denial is not required to be
standardized by Sec. 1033.311(b), the data provider:
(i) Creates a record substantiating the basis for the denial; and
(ii) Communicates in a timely manner to the consumer or third
party, electronically or in writing, the type(s) of information denied,
if applicable, and the reason(s) for the denial.
(c) Policies and procedures for ensuring accuracy--(1) In general.
The policies and procedures required by paragraph (a) of this section
must be reasonably designed to ensure that covered data are accurately
made available through the data provider's developer interface.
(2) Elements. In developing its policies and procedures regarding
accuracy, a data provider must consider, for example:
(i) Implementing the format requirements of Sec. 1033.311(b); and
(ii) Addressing information provided by a consumer or a third party
regarding inaccuracies in the covered data made available through its
developer interface.
(3) Indicia of compliance. Indicia that a data provider's policies
and procedures regarding accuracy are reasonable include whether the
policies and procedures conform to a consensus standard regarding
accuracy.
(d) Policies and procedures for record retention. The policies and
procedures required by paragraph (a) of this section must be reasonably
designed to ensure retention of records that are evidence of compliance
with subparts B and C of this part.
(1) Retention period. Records that are evidence of a data
provider's actions in response to a consumer's or third party's request
for information or a third party's request to access a developer
interface must be retained for at least three years after a data
provider has responded to the request. All other records that are
evidence of compliance with subparts B and C of this part must be
retained for a reasonable period of time of at least three years from
the date of the action required under subparts B and C of this part.
(2) Certain records retained pursuant to policies and procedures.
Records retained pursuant to policies and procedures required under
paragraph (a) of this section must include, without limitation:
[[Page 90996]]
(i) Records documenting requests for a third party's access to an
interface, actions taken in response to such requests, and reasons for
denying access, if applicable, for at least three years after the data
provider has responded to the request;
(ii) Records providing evidence of fulfillment of requests for
information, actions taken in response to such requests, and reasons
for not making the information available, if applicable, for at least
three years after the data provider has responded to the request;
(iii) Records documenting that the third party has followed the
authorization procedures in Sec. 1033.401 to access data on behalf of
a consumer, for at least three years after such records are generated;
(iv) Records providing evidence of actions taken by a consumer and
a data provider to revoke a third party's access pursuant to any
revocation method made available by a data provider, for at least three
years after the revocation;
(v) Records providing evidence of commercially reasonable
performance described in Sec. 1033.311(c)(2)(ii), for at least three
years after the period recorded;
(vi) Written policies and procedures required under this section
for three years from the time such material was last applicable; and
(vii) Disclosures required under Sec. 1033.341, for three years
from the time such material was disclosed to the public.
Subpart D--Authorized Third Parties
Sec. 1033.401 Third party authorization; general.
To become an authorized third party, the third party must seek
access to covered data from a data provider on behalf of a consumer to
provide a product or service the consumer requested and:
(a) Provide the consumer with an authorization disclosure as
described in Sec. 1033.411;
(b) Provide a statement to the consumer in the authorization
disclosure, as provided in Sec. 1033.411(b)(5), certifying that the
third party agrees to the obligations described in Sec. 1033.421; and
(c) Obtain the consumer's express informed consent to access
covered data on behalf of the consumer by obtaining an authorization
disclosure that is signed by the consumer electronically or in writing.
Sec. 1033.411 Authorization disclosure.
(a) In general. To comply with Sec. 1033.401(a), a third party
must provide the consumer with an authorization disclosure
electronically or in writing. The authorization disclosure must be
clear, conspicuous, and segregated from other material. The names
included in the authorization disclosure as required by paragraphs
(b)(1) and (2) of this section and by Sec. 1033.431(b) must be readily
understandable to the consumer.
(b) Content. The authorization disclosure must include:
(1) The name of the third party that will be authorized to access
covered data pursuant to the third party authorization procedures in
Sec. 1033.401.
(2) The name of the data provider that controls or possesses the
covered data that the third party identified in paragraph (b)(1) of
this section seeks to access on the consumer's behalf.
(3) A brief description of the product or service the consumer has
requested from the third party identified in paragraph (b)(1) of this
section and a statement that the third party will collect, use, and
retain the consumer's data only as reasonably necessary to provide that
product or service to the consumer.
(4) The categories of data that will be accessed. Categories must
have a substantially similar level of specificity as the categories in
Sec. 1033.211.
(5) The certification statement described in Sec. 1033.401(b).
(6) A brief description of the expected duration of data collection
and a statement that collection will not last longer than one year
after the consumer's most recent reauthorization.
(7) A description of the revocation method described in Sec.
1033.421(h)(1).
(c) Language access--(1) In general. The authorization disclosure
must be in the same language as the communication in which the
authorization disclosure is conveyed to the consumer. Any translation
of the authorization disclosure provided to the consumer must be
complete and accurate.
(2) Additional languages. If the authorization disclosure is in a
language other than English, it must include a link to an English-
language translation, and it is permitted to include links to
translations in other languages. If the authorization disclosure is in
English, it is permitted to include links to translations in other
languages.
Sec. 1033.421 Third party obligations.
(a) General limitation on collection, use, and retention of
consumer data--(1) In general. The third party will limit its
collection, use, and retention of covered data to what is reasonably
necessary to provide the consumer's requested product or service.
(2) Specific purposes. For purposes of paragraph (a)(1) of this
section, the following are not part of, or reasonably necessary to
provide, any other product or service:
(i) Targeted advertising;
(ii) Cross-selling of other products or services; or
(iii) The sale of covered data.
(b) Collection of covered data--(1) In general. Collection of
covered data for purposes of paragraph (a) of this section includes the
scope of covered data requested and the duration and frequency of
collection of covered data.
(2) Maximum duration. In addition to the limitation described in
paragraph (a) of this section, the third party will limit the duration
of collection of covered data to a maximum period of one year after the
consumer's most recent authorization.
(3) Reauthorization after maximum duration. To collect covered data
beyond the one-year maximum period described in paragraph (b)(2) of
this section, the third party will obtain a new authorization from the
consumer pursuant to Sec. 1033.401 no later than the anniversary of
the most recent authorization from the consumer. The third party is
permitted to ask the consumer for a new authorization pursuant to Sec.
1033.401 in a reasonable manner. Indicia that a new authorization
request is reasonable include its conformance to a consensus standard.
(c) Use of covered data. Use of covered data for purposes of
paragraph (a) of this section includes both the third party's own use
of covered data and provision of covered data by that third party to
other third parties. Examples of uses of covered data that are
permitted under paragraph (a) of this section include:
(1) Uses that are specifically required under other provisions of
law, including to comply with a properly authorized subpoena or summons
or to respond to a judicial process or government regulatory authority;
(2) Uses that are reasonably necessary to protect against or
prevent actual or potential fraud, unauthorized transactions, claims,
or other liability;
(3) Servicing or processing the product or service the consumer
requested; and
(4) Uses that are reasonably necessary to improve the product or
service the consumer requested.
(d) Accuracy. A third party will establish and maintain written
policies and procedures that are reasonably designed to ensure that
covered data are
[[Page 90997]]
accurately received from a data provider and accurately provided to
another third party, if applicable.
(1) Flexibility. A third party has flexibility to determine its
policies and procedures in light of the size, nature, and complexity of
its activities.
(2) Periodic review. A third party will periodically review its
policies and procedures and update them as appropriate to ensure their
continued effectiveness.
(3) Elements. In developing its policies and procedures regarding
accuracy, a third party must consider, for example:
(i) Accepting covered data in a format required by Sec.
1033.311(b); and
(ii) Addressing information provided by a consumer, data provider,
or another third party regarding inaccuracies in the covered data.
(4) Indicia of compliance. Indicia that a third party's policies
and procedures are reasonable include whether the policies and
procedures conform to a consensus standard regarding accuracy.
(e) Data security. (1) A third party will apply to its systems for
the collection, use, and retention of covered data an information
security program that satisfies the applicable rules issued pursuant to
section 501 of the Gramm-Leach-Bliley Act (15 U.S.C. 6801); or
(2) If the third party is not subject to section 501 of the Gramm-
Leach-Bliley Act, the third party will apply to its systems for the
collection, use, and retention of covered data the information security
program required by the Federal Trade Commission's Standards for
Safeguarding Customer Information, 16 CFR part 314.
(f) Provision of covered data to other third parties. Before
providing covered data to another third party, subject to the
limitation described in paragraphs (a) and (c) of this section, the
third party will require the other third party by contract to comply
with the third party obligations in paragraphs (a) through (f) of this
section and the condition in paragraph (i) of this section upon receipt
of the notice described in paragraph (h)(2) of this section.
(g) Ensuring consumers are informed. (1) Upon obtaining
authorization to access covered data on the consumer's behalf, the
third party will provide the consumer with a copy of the authorization
disclosure that the consumer has signed electronically or in writing
and that reflects the date of the consumer's electronic or written
signature. The third party will deliver that copy of the authorization
disclosure to the consumer or make it available in a location that is
readily accessible to the consumer, such as the third party's
interface. If the third party makes the authorization disclosure
available in such a location, the third party will ensure it is
accessible to the consumer until the third party's access to the
consumer's covered data terminates.
(2) The third party will provide contact information that enables a
consumer to receive answers to questions about the third party's access
to the consumer's covered data. The contact information must be readily
identifiable to the consumer.
(3) The third party will establish and maintain reasonable written
policies and procedures designed to ensure that the third party
provides to the consumer, upon request, the information listed in this
paragraph (g)(3) about the third party's access to the consumer's
covered data. The third party has flexibility to determine its policies
and procedures in light of the size, nature, and complexity of its
activities, and the third party will periodically review its policies
and procedures and update them as appropriate to ensure their continued
effectiveness. The policies and procedures must be designed to ensure
that the third party provides the following to the consumer, upon
request:
(i) Categories of covered data collected;
(ii) Reasons for collecting the covered data;
(iii) Names of parties with which the covered data was shared. The
names must be readily understandable to the consumer;
(iv) Reasons for sharing the covered data;
(v) Status of the third party's authorization;
(vi) How the consumer can revoke the third party's authorization to
access the consumer's covered data and verification the third party has
adhered to requests for revocation; and
(vii) A copy of any data aggregator certification statement that
was provided to the consumer pursuant to Sec. 1033.431(c)(2).
(h) Revocation of third party authorization--(1) Provision of
revocation method. The third party will provide the consumer with a
method to revoke the third party's authorization to access the
consumer's covered data that is as easy to access and operate as the
initial authorization. The third party will also ensure the consumer is
not subject to costs or penalties for revoking the third party's
authorization.
(2) Notice of revocation. The third party will notify the data
provider, any data aggregator, and other third parties to whom it has
provided the consumer's covered data when the third party receives a
revocation request from the consumer.
(i) Effect of maximum duration and revocation on collection, use,
and retention. If a consumer does not provide a new authorization as
described in paragraph (b)(3) of this section, or if a third party
receives a revocation request as described in paragraph (h)(1) of this
section or notice of a consumer's revocation request as described in
Sec. 1033.331(e), a third party will:
(1) No longer collect covered data pursuant to the most recent
authorization; and
(2) No longer use or retain covered data that was previously
collected pursuant to the most recent authorization unless use or
retention of that covered data remains reasonably necessary to provide
the consumer's requested product or service under paragraph (a) of this
section.
Sec. 1033.431 Use of data aggregator.
(a) Responsibility for authorization procedures when the third
party will use a data aggregator. A data aggregator is permitted to
perform the authorization procedures described in Sec. 1033.401 on
behalf of the third party seeking authorization under Sec. 1033.401 to
access covered data. However, the third party seeking authorization
remains responsible for compliance with the authorization procedures
described in Sec. 1033.401, and the data aggregator must comply with
paragraph (c) of this section.
(b) Disclosure of the name of the data aggregator. The
authorization disclosure must include the name of any data aggregator
that will assist the third party seeking authorization under Sec.
1033.401 with accessing covered data and a brief description of the
services the data aggregator will provide.
(c) Data aggregator certification. When the third party seeking
authorization under Sec. 1033.401 will use a data aggregator to assist
with accessing covered data on behalf of a consumer, the data
aggregator must certify to the consumer that it agrees to the
conditions on accessing the consumer's data in Sec. 1033.421(a)
through (f) and the condition in Sec. 1033.421(i) upon receipt of the
notice described in Sec. 1033.421(h)(2) before accessing the
consumer's data. For this requirement to be satisfied:
(1) The third party seeking authorization under Sec. 1033.401 must
include the data aggregator's certification in the authorization
disclosure described in Sec. 1033.411; or
[[Page 90998]]
(2) The data aggregator must provide its certification to the
consumer, electronically or in writing, separate from the authorization
disclosure. The certification must be in the same language as the
authorization disclosure and must be clear, conspicuous, and segregated
from other material. The name of any data aggregator in the
certification must be readily understandable to the consumer. If, after
the consumer has completed the authorization procedures, the authorized
third party retains a data aggregator to assist with accessing covered
data on behalf of the consumer, this data aggregator must provide its
certification in accordance with this paragraph (c)(2).
Sec. 1033.441 Policies and procedures for third party record
retention.
(a) General requirement. A third party that is a covered person or
service provider, as defined in 12 U.S.C. 5481(6) and (26), must
establish and maintain written policies and procedures that are
reasonably designed to ensure retention of records that are evidence of
compliance with the requirements of subpart D of this part.
(b) Retention period. Records required under paragraph (a) of this
section must be retained for a reasonable period of time, not less than
three years after a third party obtains the consumer's most recent
authorization under Sec. 1033.401(a).
(c) Flexibility. A third party covered under paragraph (a) of this
section has flexibility to determine its policies and procedures in
light of the size, nature, and complexity of its activities.
(d) Periodic review. A third party covered under paragraph (a) of
this section must periodically review its policies and procedures and
update them as appropriate to ensure their continued effectiveness to
evidence compliance with the requirements of subpart D of this part.
(e) Certain records retained pursuant to policies and procedures.
Records retained pursuant to policies and procedures required under
this section must include, without limitation:
(1) A copy of the authorization disclosure that is signed by the
consumer electronically or in writing and reflects the date of the
consumer's signature and a record of actions taken by the consumer,
including actions taken through a data provider or another third party,
to revoke the third party's authorization; and
(2) With respect to a data aggregator covered under paragraph (a)
of this section, a copy of any data aggregator certification statement
that was provided to the consumer pursuant to Sec. 1033.431(c)(2).
Appendix A to Part 1033--Personal Financial Data Rights Rule: How to
Apply for Recognition as a Standard Setter
If you want the CFPB to designate your organization as a
recognized standard setter, you should follow the steps described
below.
We may amend this process from time to time.
Step One: Requesting Recognition
Submit a written request for recognition.\1\
---------------------------------------------------------------------------
\1\ Sensitive personal information should not be provided.
---------------------------------------------------------------------------
This should include key contact information, evidence of your
organization's policies and practices,\2\ and an explanation of how
your organization satisfies each of the requirements in the Personal
Financial Data Rights rule to be a recognized standard setter.\3\
Your request should also describe how current and/or anticipated
standards issued by your organization relate to open banking.
---------------------------------------------------------------------------
\2\ Evidence may include (but is not limited to) charters,
bylaws, policies, procedures, fee schedules, meeting minutes,
membership lists, financial statements/disclosures, publicly
available materials, and issued standards.
\3\ Relevant legal requirements are described at 12 CFR
1033.141. When explaining how your organization meets these
requirements, you should reference relevant elements of the evidence
you submit in support of your application.
---------------------------------------------------------------------------
In advance of filing your request, you can seek a pre-filing
meeting with us. We can walk you through the application process and
help you make a complete submission.
Send formal submissions, as well as requests for pre-filing
meetings, to: [email protected].
Step Two: Additional Information and Public Comment
After reviewing your submission, we may request additional
information to ensure that your application is complete.
We may publish your application.
We may also seek public input on your application and invite
your responses to any information we receive on that basis.
Step Three: Our Review
When reviewing your application, we consider whether your
policies and practices meet all the requirements for recognition. We
also evaluate whether your application is accurate and complete.
We prioritize and review applications based on the extent to
which recognizing your organization helps us to implement open
banking.\4\
---------------------------------------------------------------------------
\4\ Section 1033 of the Consumer Financial Protection Act, 12
U.S.C. 5533, describes the CFPB's role in implementing open banking.
---------------------------------------------------------------------------
Step Four: Application Decision
CFPB recognition will be publicly disclosed on our website,
along with the applicable terms and conditions of such recognition,
such as its duration.
If the CFPB declines to recognize your organization, we will
notify you.
You may withdraw your application at any time or for any reason.
If we determine that your organization is close to meeting, but
does not yet meet, the requirements for CFPB recognition, we may ask
you to provide a written plan specifying how and when you will take
the steps required for full recognition. If that plan is
satisfactory, we may state on our website that your organization has
received contingent recognition. Once you provide us with evidence
that you have successfully executed on that plan (or otherwise
addressed the relevant contingences), the CFPB may extend full
recognition.
Step Five: Recognition
There are several points to keep in mind about recognition.
As a recognized standard setter, you agree that the CFPB may
monitor your organization and that you will provide information that
we request.
You must also provide us, within 10 days, written explanation of
any material change to information that was submitted with your
application or during recognition, as well as any reason your
organization may no longer meet underlying requirements for
recognition.
In addition, you must meet any other specified terms and
conditions of your recognition, which may include our reserving the
right to observe or participate in standard setting.
If your recognition is set to expire, you can apply for re-
recognition by re-starting at Step One at least 180 days before
expiration. We may temporarily extend your recognition while we
consider your request for re-recognition.
We may modify or revoke your recognition. The CFPB expects to
notify you of the reasons it intends to revoke or modify
recognition, and to provide your organization with an opportunity to
address the CFPB's concerns.
Rohit Chopra,
Director, Consumer Financial Protection Bureau.
[FR Doc. 2024-25079 Filed 11-15-24; 8:45 am]
BILLING CODE 4810-AM-P