Overview

On October 22, 2024, the Consumer Financial Protection Bureau (CFPB) finalized its long-anticipated “Personal Financial Data Rights” rule (and Executive Summary) – more commonly known as the “Open Banking” rule – under Section 1033 of the Dodd-Frank Act. This landmark regulation aims to empower consumers by granting them greater control over their personal financial data, enabling them to access and share this information with third-party providers securely and without charge. According to the CFPB, the rule is designed to foster competition and innovation in the financial services industry by making it easier for consumers to switch financial providers and for new companies to offer innovative products and services.

The final rule requires covered entities – including banks, credit card issuers, digital wallet providers, and other financial institutions – to provide consumers and authorized third parties with access to specified consumer financial data upon request. It also establishes privacy and security protections, limiting third parties use of the data they receive to the purposes expressly authorized by the consumer. While the rule has been lauded for promoting consumer choice and competition, it has also faced criticism and legal challenges from industry stakeholders concerned about data security, compliance burdens, and statutory authority.

What Does the CFPB Open Banking Rule Entail?

The CFPB’s Open Banking rule mandates that covered data providers make available to consumers, or to third parties authorized by consumers, certain data related to covered consumer financial products or services free of charge.

• Covered data – data providers must make available:

• Account Balance and Transaction Information: At least 24 months of transaction history, including amounts, dates, payment types, merchant names, rewards credits, and fees or finance charges.
• Payment Initiation Information: Data necessary to initiate payments from accounts, facilitating services like “pay-by-bank.”
• Terms and Conditions: Details such as fee schedules, interest rates, credit limits, rewards program terms, and whether the consumer has entered into an arbitration agreement.
• Upcoming Bill Information: Information on upcoming payments due, including scheduled payments to third parties.
• Basic Account Verification Information: Names, addresses, email addresses, and phone numbers associated with the accounts.
• Exceptions – data providers do not have to make available:
  • Confidential commercial information.
  • Information collected for the sole purpose of preventing fraud/money laundering.
  • Information required to be kept confidential by law.
  • Information the data provider cannot retrieve in the ordinary course of business.

Entities that are “data providers” under the Rule?

The rule applies to a broad range of financial service providers, referred to as “covered data providers.” This includes:

• Regulation E financial institutions: Banks, saving associations, and credit unions holding consumer asset accounts.
• Regulation Z card issuers.
• Payment Facilitators: “Any other person that controls or possesses information concerning a covered consumer financial product or service that the consumer obtained from that person.” This includes companies that enable transactions from consumer accounts, including digital wallet providers.

Notably, the final rule exempts depository institutions that hold assets of $850 million or less (i.e., equal to or less than the Small Business Administration size standard for such institutions), aiming to alleviate the compliance burden on smaller banks and credit unions.

Consumer and Developer Interfaces

Under the rule, data providers are required to establish and maintain two separate interfaces for accessing covered data: a consumer interface (e.g., online banking portals to allow consumers to access their data directly) and a developer interface for authorized third parties (e.g., APIs, though the rule is technology neutral) to facilitate secure and standardized access to covered data. Data providers must also provide certain information to consumers and authorized third parties, including: (i) its legal name and any assumed names; (ii) a link to its website; (iii) its Legal Entity Identifier (LEI) that is issued by a utility endorsed by the LEI Regulatory Oversight Committee or the Global LEI Foundation; and (iv) contact information for consumers or third parties to ask questions about accessing covered data. Data providers may not charge fees to either consumers or authorized third parties for accessing covered data. The developer interface must meet certain minimum performance standards and may not unreasonably restrict the frequency with which it receives or responses to requests from an authorized third party.

Data providers can deny access to their interfaces to third parties under certain limited circumstances, such as if the third party does not provide sufficient evidence that its security practices are adequate. Data providers may deny access to their developer interface if a third party does not present evidence that its information security practices are adequate to protect covered data or if the third party does not provide: (i) Its legal name (and any assumed names); (ii) a link to its website; (iii) its LEI that is issued by a utility endorsed by the LEI Regulatory Oversight Committee or the Global LEI Foundation; and (iv) contact information a data provider may use to inquire about the third party’s information security and compliance practices.

Like the proposed rule, the final rule does not explicitly prohibit authorized third parties screen scraping; however, the final rule seeks to curtail screen scraping by prohibiting authorized third parties from accessing a data provider’s developer interface by using any credentials that a consumer uses to access the consumer interface.

What Are the Privacy and Security Protections and Restrictions on Third Parties?

To safeguard consumer data, the rule imposes several privacy and security requirements on third parties:

• Purpose Limitation: When a consumer authorizes a third party to access the consumer’s financial data from a data provider, the third party can only use the data for the specific product or service requested by the consumer. Practices like selling the data or using the data for targeted advertising or cross-selling the third party’s other products/services, are prohibited (unless the consumer expressly consents to these purposes).
• Consent and Authorization: Third parties must obtain express consent from consumers through clear authorization disclosures, outlining the data to be accessed and the purpose.
• Limited Duration of Authorization. The authorization from a consumer is valid for one year, after which the third party must obtain new authorization from the consumer. If an authorization expires, the third party may no longer collect covered data and may no longer use or retain covered data collected under the expired or revoked authorization.
• Revocation Rights: Consumers have the right to revoke a third party’s access at any time, and third parties must (1) make revocation easy, (2) cease data collection and delete data unless retention is necessary to provide the requested service, and (3) notify the data provider if it receives a revocation request from the consumer.
• Data Security Programs: Third parties must implement data security measures in line with the Gramm-Leach-Bliley Act (GLBA), or, if not subject to the GLBA, the FTC Standards for Safeguarding Customer Information (i.e., Safeguards Rule).
• Policies and Procedure: Third parties would need to maintain their own internal written policies on procedures to comply with the rule and the rule’s record retention requirements.

What Are the Compliance Deadlines?

Compliance with the rule will be implemented in phases as follows:

Key Takeaways

This significant regulatory development carries several implications for businesses in the financial sector:

• Prepare for Compliance: Covered entities, both data providers and third parties, should begin assessing their data infrastructure, security protocols, compliance procedures, and obtain required LEI identifiers to meet the new requirements within the specified timelines.
• Review Data Sharing Practices: Companies seeking to access covered data must evaluate their data collection, use, and retention policies to ensure they align with the purpose limitations and consent requirements of the rule.
• Enhance Privacy and Security Measures: Robust data security programs compliant with GLBA and other regulations must be implemented to protect consumer data during access and transfer. This is particularly important for third party recipients who may not be as familiar with these requirements (as noted above, if the third party is not subject to the GLBA already, the third party must follow the FTC Safeguards Rule, which sets out detailed security requirements for protecting consumers’ financial information).
• Monitor Legal Developments: Ongoing legal challenges could impact the implementation and enforcement of the rule. Companies should follow these proceedings and be prepared to adapt accordingly.
• Engage with Industry Standards: Participation in recognized standard-setting bodies may aid in compliance and contribute to the development of interoperable systems that benefit the industry as a whole (the CFPB finalized its rule regarding standard-setting bodies earlier this summer).

For more information about these developments and how they may affect your organization, contact your DLA relationship partner, the authors of this blog post, or any member of DLA’s Data Protection, Privacy, and Security team.

In the intervening time, in the European Union put into place the Payment Services Directive 2 (PSD2) which mandated that banks open their data to third parties with consumer consent.  

This post provides a brief overview of the CFPB’s proposal (the public comment period for the proposed rule period closed on December 29, 2023, and the final rule can be expected in the coming months) and compares the rule’s requirements to those in PSD2.

Who is covered

The CFPB’s proposed rule takes a phased approach to making consumer financial data available to both consumers and authorized third parties, applying to a limited set of data providers and covered financial products, services, and information. The proposed rule would apply to the following types of financial products and services: (1) demand deposit (checking), savings, or other consumer asset accounts subject to Regulation E, (2) credit cards subject to Regulation Z, and (3) payment facilitation  from  Regulation E accounts or Regulation Z credit cards (such as  digital wallet services). The proposed rule defines “data providers” as covered persons subject to the CFPA that are financial institutions as defined by Regulation E (e.g., banks, savings associations, credit unions), credit card issuers as defined by Regulation Z, or any other persons that control or possess information concerning a covered consumer financial product or service the consumer obtained from those persons. While the proposal does not cover other types of consumer financial products or services, such as mortgages, student loans, or other closed end lending products, the CFPB intends to conduct supplemental rule-making proceedings to expand the scope of the open banking rule.

For purposes of the proposed rule, a “consumer” means a natural person; the term also includes trusts that are established for tax or estate planning purposes (which notably are not included under current US federal financial privacy law). A “third party” is any person or entity that is not the consumer about whom the covered data pertains or the data provider that controls or possess the consumer’s covered data. A “data aggregator” is an entity that is retained by and provides services to an authorized third party to enable access to covered data.

Requirements for data providers

Under the proposed rule, when a data provider receives a request from a consumer or an authorized third party for “covered data” in the data provider’s possession or control, the data provider must make the covered data available in an electronic machine-readable file that consumers and authorized third parties can retain.

“Covered data” includes:

• Transaction information (including 24 months of historical transaction information):  information about individual transactions, including payment amount, date, payment type, pending or authorized status, payee or merchant name, rewards credits, fees, finance charges.
• Account balance: Available funds in an asset account or credit card balance.
• Information to initiate payment to or from a Reg E account: Actual or Tokenized account and routing numbers used to initiate an ACH transaction.
• Terms and conditions: Contractual terms under which data provider provides financial products or services to the consumer. Includes pricing (APR, APY, fees, other pricing), rewards program terms, and dispute resolution (i.e., arbitration) requirements.
• Upcoming bill information: Payments scheduled through the data provider (e.g., recurring or scheduled online bill pay transactions), payments due to the data provider.
• Basic account verification information: Name, address, email address, phone number associated with the covered financial product or service.

Data providers will need to establish a consumer interface to field consumer requests for covered data and a developer interface for covered data requests from authorized third parties and data aggregators. Notably, data providers will not be able to charge either consumers or authorized third parties fees to provide covered data or for developing or maintaining the respective interfaces. The rule would establish performance requirements for the developer interface (similar to a service level agreement in a contract); the developer interface must “properly respond” to 99.5% of the requests for covered data, and a data provider may not unreasonably restrict the frequency that it receives and responds to requests for covered data. Data providers’ developer interfaces also will need to comply with the Gramm Leach Bliley Act’s (GLBA) information security requirements.

While the proposed rule does not explicitly prohibit authorized third parties from using screen scraping methods to obtain covered data from data providers, the notice of proposed rulemaking discussion clearly describes screen scraping as a disfavored practice. The CFPB refers to screen scraping as a security risk (as it proliferates the use of consumers’ account credentials), a method that can cause over-collection of consumer data and lead to data inaccuracies, and a practice that can overburden data providers’ systems and increase their liability risks. The Bureau’s proposed rule clearly intends for the developer portals to be the primary way third parties and data aggregators access covered data from data providers.

Data providers will need to have reasonable written policies and procedures for complying with the rule and will need to make certain information publicly available, such as developer interface documentation (technical data to help third parties use the interface) and performance data for the developer portal.

Requirements for third parties and data aggregators

To obtain covered data on behalf of a consumer under the proposed rule, a third party must obtain a consumer’s authorization. The authorization must be clear and conspicuous and be separate from other materials or terms. To be valid, the authorization must be signed (electronic or written) by the consumer and include the following information:

• The name of the third party that will be authorized to access covered data.
• 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.
• 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 solely for the purpose of providing that product or service to the consumer.
• The categories of covered data that will be accessed.
• A statement that the third party certifies that it agrees that it will limit its collection, use, and retention of covered data to what is reasonably necessary to provide the consumer’s requested product or service.
• A description of the mechanism a consumer may use to revoke the authorization.
• The name of any data aggregator that will assist the third party with accessing covered data and a brief description of the services the data aggregator will provide.

If a third party uses a data aggregator to obtain covered data, the data aggregator may provide consumers with the authorization notices and obtain consumer’s express consents on behalf of the third party. The data aggregator would need to provide its own certification to the consumer regarding compliance with the rule and the restrictions on the collection, use, and disclosure of the consumer’s covered data. The third party would still be responsible for complying with the rule’s authorization requirements.

A consumer’s authorization, unless revoked earlier, would remain in effect for 12 months. Third parties will need to obtain fresh consumer authorizations every 12 months. When an authorization expires, a third party may no longer collect covered data from a data provider, and the third party may no longer use or retain covered data that was collected pursuant to the expired authorization unless the retention of that covered data remains reasonably necessary to providing the consumer’s requested product or service.

As described in the authorization form requirements above, a third party may only collect, use, and disclose covered data as reasonably necessary to provide a specific product or service that a consumer requested. The proposed rule would not permit covered data to be collected, used, or disclosed for any secondary purposes, and the proposal expressly prohibits collecting, using, or disclosing covered data for targeted advertising purposes, to cross-sell other products or services, or for any sale of covered data.

The systems that a third party uses to collect, use and retain covered data would need to comply with GLBA’s information security requirements; if a third party is not already subject to GLBA’s security requirements, it would need to comply with the prescriptive security requirements of the Federal Trade Commission’s Safeguards Rule, 16 CFR Part 314.

Third parties would need to maintain their own internal written policies on procedures to comply with the rule and the rule’s record retention requirements.

Industry standards and compliance dates

The proposed rule contemplates data providers’ and third parties’ compliance with qualified industry standards issued by a CFPB recognized standard-setting body could be used as indicia of compliance with the rule. However, the proposed rule did not identify or discuss any existing industry standards that could meet the Bureau’s requirements.

The proposed rule sets forth staggered compliance deadlines for data providers; the proposed rule does not include any compliance deadlines for third parties. The data provider compliance dates turn on the size of the respective data provider.

• The largest data providers, depository institutions with at least $500 billion in total assets and nondepository institutions that generated at least $10 billion in revenue in the preceding calendar year or that are projected to do so in the current calendar year, would need to comply with the rule within 6 months after the final rule is published in the Federal Register.
• Depository institutions with at least $50 billion in total assets and non-depository institutions that generated less than $10 billion in revenue in the preceding calendar year or that are projected to generate less than $10 billion in revenue in the current calendar year, would need to comply with the rule within 1 year after the final rule is published.
• Depository institutions with at least $850 million in total assets would need to comply with the rule within 2 1/2 years after the final rule is published in the Federal Register.
• Depository institutions with less than $850 million in total assets would need to comply with the rule within 4 years after the final rule is published.

As the comment period has now closed, the CFPB is in the process of reviewing the comments it received from the public.

Comparison with EU PSD2 Requirements

The EU PSD2 provides rules to ensure legal certainty for consumers, merchants, and companies within the payment chain and modernizes the legal framework for the market for payment services. It introduced several novelties in the payment services field, creating new opportunities for payment service users and enhancing transparency.

In particular, the PSD2 gave Open Banking a stable regulatory framework by regulating new types of payment service providers which play a significant role in the Open Banking process: information service providers (AISPs) and payment initiation service providers (PISPs).

AISPs and PISPs offer value-added services to users by accessing their account data held by banks and other payment account providers, upon users’ request. While PISPs are able to initiate payment orders at the request of a user concerning the user’s payment account held at another payment service provider, AISPs gather and consolidate information on one or more payment accounts held by the user either with another payment service provider or with more than one payment service provider, thus allowing the user to have an overall view of their financial situation at any given moment.

Unlike the CFPB’s proposed rule, which applies to financial data relating to “consumers,” the PSD2 applies to payment service providers which target both individuals and legal entities. However, similar to the CFPB’s proposed rule, the PSD2 excludes some financial product and service providers from its scope, such as services that entail creditworthiness assessments of the payment service user or audit services performed based on the collection of information via an account information service as well as accounts other than payment accounts (e.g., savings, investments).

, The PSD2 states that any processing of personal data, including the provision of information about the processing, for the purposes of the PSD2, shall be carried out in accordance with the General Data Protection Regulation (GDPR). However, the interplay of the GDPR and the PSD2 generated several uncertainties which the European Data Protection Board (EDPB) has partially addressed in its Guidelines 06/2020 on the interplay of the Second Payment Services Directive and the GDPR.

General requirements for AISPs and PISPs under the EU PSD2

The PSD2 regulates the legal conditions under which PISPs and AISPs may access payment accounts to provide their services to users and imposes obligations vis-à-vis banks and other credit institutions holding users’ information.

• User consent and mandatory sharing of user information

The PSD2 provides that the access and use of payment and account information services are rights of the user, meaning that the providers holding such information (usually banks) must share users’ information with PISPs and AISPs, upon users’ explicit consent.

Nonetheless, the PSD2 does not set an “expiration date” on this authorization. It merely provides that payment service providers shall only access, process, and retain personal data necessary to provide their payment services, with the user’s explicit consent.

This explicit consent should be regarded as an additional requirement of a contractual nature about the access to and subsequent processing and storage of personal information to provide payment services and is, therefore, not the same as express consent under the GDPR. When entering into a contract with a payment service provider under the PSD2, users must be made fully aware of the specific categories of personal information that will be processed. Further, they must be made aware of the specific (payment service) purpose for which their personal information will be processed and must explicitly agree to these clauses. Such clauses should be clearly distinguishable from other matters dealt with in the contract and must be explicitly accepted by the users (similar to the CFPB’s proposed requirement that a consumer’s authorization be separate from any other terms).

Further transparency obligations on the purpose for which users’ data is processed arise from the GDPR.

• Secondary use and purpose limitation

Ever since the PSD2 entered into force in 2016, the provision of ancillary value-added service has become the primary business model for the AISPs and PISPs operating on the European market. It is common for PISPs, in addition to enabling payments to merchants on the Internet, to offer ancillary services such as reloading funds to prepaid cards or paying commercial invoices, while AISPs may also offer services aimed at improving customers’ financial habits by planning expenses and savings or supporting credit scoring processes.

However, similar to the prohibition of secondary use envisaged by the CFPB’s proposed rule, the PSD2 considerably restricts how AISPs and PISPs may process data for purposes other than providing the service requested by the user. This limitation must be read in conjunction with the principle of purpose limitation set forth by the GDPR, with the result that the processing for another purpose is not allowed unless the user has given consent under the GDPR or the processing is required by EU or member state law to which the AISP or PISP is subject (e.g., anti-money laundering purposes).

As a result, AISPs and PISPs must collect end-customer consents distinguishing between those required under PSD2 (i.e., consents allowing access to users’ data by intermediaries offering PIS and AIS services) and those necessary under the GDPR (i.e., consents allowing the extracted information to be transferred to other parties or processed to pursue purposes other than those strictly necessary to provide payment services).

Therefore, the PSD2 considerably restricts the possibilities for processing users’ data for other purposes incompatible with the one for which this data is initially collected.

• Data minimization 

The PSD2 considerably restricts the ability of AISPs and PISPs to collect data beyond the minimum necessary to provide the service requested by the user, meaning that data collection and subsequent processing shall be limited to the strictly necessary, consistently with the data minimization principle set forth by the GDPR.

For instance, AISPs’ access is limited to the information from designated payment accounts and associated payment transactions., They shall not use, access, or store any data for purposes other than for performing the account information service explicitly requested by the user, in accordance with the GDPR, which emphasizes that personal data can only be collected for specified, explicit, and legitimate purposes.

Therefore, an AISP should make explicit in the contract the specific purposes for which personal account information will be processed, in the context of its account information service.

• Data retention 

Unlike the CFPB’s proposed rule, PSD2 does not envisage data retention terms but GDPR does. Besides collecting the minimum amount of data possible, the service provider must also envisage limited retention periods: open-ended retention terms or permanent data storage are generally incompatible with the GDPR. As such, personal data should only be stored by the service provider for a period related to the purposes requested by the payment service user.

• Implementation of security measures and identification requirements

The implementation of adequate security measures is directly addressed by the PSD2, which, similar to the CFPB’s proposed rule, relies on standards promulgated by a dedicated body.

Under the PSD2, PISPs and AISPs, on the one hand, and the account servicing payment service provider, on the other hand, should observe the necessary data protection and security requirements established by, or referred to in, the PSD2 or included in the regulatory technical standards.

The latter are included in the Commission Delegated Regulation (EU) 2018/389, which sets forth regulatory technical standards for strong customer authentication and common and secure open communication standards.

Moreover, the GDPR always requires organizations to implement appropriate security measures, considering the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing, as well as the likelihood and severity of risks to the rights and freedoms of natural persons.

The upcoming revision of the EU PSD2

Although the PSD2 has significantly contributed to the development of the European payments market and improved customer protection and the efficiency, transparency, and choice of payment instruments, a few shortcomings have emerged, such as regulatory deficiencies regarding new players and services in the payments market, divergences in implementation across Member States, and unclear alignment with other EU legislation.

To address these issues, the European Parliament has published a proposal to revise PSD2, comprised of a proposal for a directive on payment services and electronic money services (PSD3) and a proposal for a regulation of payment services in the internal market (PSR).

On November 1, 2023, the New York Department of Financial Services (NYDFS) announced extensive amendments to its cybersecurity requirements for financial institutions issued under 23 NYCRR Part 500.  The amendments are intended to address the evolution in the cybersecurity landscape since the regulation was first enacted in 2017, including the increasing sophistication of threat actors and improvements in the tools available for organizations to protect themselves. Covered entities continue to include entities operating under, or required to operate under, a license, registration, charter, certificate, permit, accreditation or similar authorization under NY Banking Law, Insurance Law or Financial Services Law.

Key changes in the amended regulation include:   

• Creating a new class of covered entities (based on revenue and/or employee thresholds) that are subject to heightened requirements;
• Enhancing requirements related to vulnerability management, access controls, and the use of encryption;
• Providing prescriptive requirements related to the use of multi-factor authentication;
• Requiring the implementation of policies and procedures related to business continuity and disaster recovery;
• Requiring additional controls to prevent unauthorized access to information systems;     
• Updating cybersecurity incident notification requirements, including a new requirement to report ransomware payments; and
• Amending the scope of the exemptions and enforcement provisions under the regulation.

The amended requirements will take effect in phases, with some having already come into force on November 1, 2023.

FTC Implements Security Incident Notification Requirement under Safeguards Rule

In other financial services information security developments, the Federal Trade Commission (FTC) issued a final rule creating a security incident notification requirement under its Gramm Leach Bliley Act (GLBA) Safeguards Rule. The FTC’s Safeguards Rule implements GLBA’s security requirements, with the FTC having Safeguards Rule jurisdiction over mortgage lenders, certain non-bank lenders, finance companies, mortgage brokers, account services, check cashers, wire transferors, collection agencies, credit and financial advisors, tax preparation firms, and investment advisors that are not required to register with the Securities and Exchange Commission.

Under the final rule, covered financial institutions must electronically notify the FTC within 30 days of discovering a “notification event” that involves the information of at least 500 consumers. The scope of data and incidents that could be subject to the rule is very broad. A notification event is defined as the “acquisition of unencrypted customer information without the authorization of the individual to which the information pertains.” The Safeguards Rule broadly defines “customer information” as any record containing nonpublic personal information about a [consumer] customer of a financial institution, whether in paper, electronic, or other form.” For example, the fact that a consumer is a financial institution’s customer would itself be customer information subject to the rule. The definition of “notification event” also presumes that customer information was “acquired” if there was unauthorized access to such information; to rebut this presumption, a financial institution must have reliable evidence showing that there has not been or could not reasonably have been unauthorized acquisition. The rule does not include a good faith exception like the U.S. state security breach notification laws for situations where an employee or contractor mistakenly accesses or acquires personal information.

The rule will take effect 180 days after its publication in the Federal Register. The FTC will post the notifications it receives publicly on its website.

For more information, please contact your DLA relationship Partner, the authors of this blog post, or any member of our Data Protection team.