In 2010, Congress included a provision in the Consumer Financial Protection Act (CFPA) requiring that the Consumer Financial Protection Bureau (CFPB or Bureau) promulgate rules effectuating what is commonly referred to as “Open Banking.” Specifically, the rules would require any entity that engages in offering or providing a consumer financial product or service to make available information concerning the financial products or services that the consumer received from the entity. However, it was not until October 2023 that the CFPB issued a proposed rule to implement the CFPA’s open banking/consumer financial data right.
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).
