A 1033 Implementation Breakdown (Part 3)

Continuing the deep dive into Section 1033, specifically on making covered data available

Hope everyone who celebrates had a nice Thanksgiving! Although we are a day late, today we’ll be continuing our deep dive into Section 1033, focusing on SubPart B “Obligation to Make Covered Data Available.” We’ll get to the weekly roundup tomorrow (sorry for the delay!) With that said, let’s jump in:

• The CFPB sets out the topic of making covered data available by declaring their goal of resolving contradictions in data availability across the industry and stating that they will be responsible for bringing everyone on the same page (how quickly will they react to ambigious questions in this space? To be determined).

• Assuming that the requirement is that data providers have to make “covered data” available to consumers or authorized third parties related to a product or service the consumer obtained from that provider; the CFPB acknowledges that many data providers claim they are doing this but then create obstacles for consumers to actually obtain this data. One solution being considered is whether they should outline specific scenarios that data providers cannot engage in that would effectively prevent consumers access to data, using “information blocking” as an example of a phrase from the healthcare regulation space.

• A few other points are raised about the data - it should be understood by the consumer, meaning that if the consumer doesn’t speak a certain language, the data needs to be in something they can actually interpret (otherwise making it useless to them). This also includes the data being current; what good is out of date information? (unless specifically requested). Some references are made to the fact that providers are working to refresh data and provide real-time balances; using data about authorized but unsettled credit card transactions as an example.

• Next, the CFPB gets to defining what exactly they mean by “covered data.” To put it succinctly, they mean transaction information (historical and current), account balance, information to initiate payment to and from Reg E accounts (aka deposits), terms and conditions, upcoming bill information, and basic account verification information.

• There were several concerns raised by the “SBREFA (Small Business Regulatory Enforcement Fairness Act) Panel” which is comprised of a number of small business entity representatives. One of the main ones was the potential privacy and fraud risk by making more data available, and another was that this data could create more of a burden.

• Regarding being efficient, the CFPB notes that its aim is to try and leverage as much existing infrastructure as possible to implement the goals of making covered data available; namely through existing processes like transaction based underwriting, comparison shopping, account switching, and more. The CFPB acknowledged the power of account switching in a number of use cases that currently exist today, including transferring funds to and from accounts.

• The CFPB then sought to tout the negative consumer experiences that the future covered data state would resolve, including fighting anti-competitive “data hoarding” so to speak, as well as the aforementioned possibility of standardization in the industry. They cite APRs as an example of something that has been contested.

• They then make sure to note that the prospect of data providers making information available would only be relevant to whichever covered product they provide accounts for (i.e. Regulation E institution not having to provide a credit card APR or billing statement.

• Regarding transaction information:

  • This refers to information about individual transactions (i.e. payment amount, date, type, pending/authorized status, payee/merchant name, rewards credits, fees, finance charges). Apparently there has been some pushback in providing pending transaction information, but the CFPB notes this won’t be a consideration for them (and I think that makes sense).

  • There’s some discussion about the right amount of historical information to make available. Some providers give up to 60 months of information, while others give less. The CFPB feels that 24 months is the right amount to seek as a baseline to standardize.

• Regarding account balance:

  • The only concern the CFPB has here is whether the term is clear enough to be seen as referring to “available funds in an asset account and any credit card balance.”

• Referring to information to initiate payment to or from a Regulation E account

  • The type of information the CFPB expects providers to make available includes a tokenized account and routing number to initiate an ACH transaction.

  • There is some discussion about TANs (Transaction Authentication Numbers) and from the providers’ perspective, the need for this to be something that should be allowed to be shared to third parties (in lieu of tokenized account numbers and routing numbers) primarily to better track down fraud. The CFPB notes some parties have called out the fact that these TANs don’t support consumer use cases including printing checks to pay vendors, initiating payments by check/wire, and detecting fraud (likely in a different way than what TANs support).

  • The conclusion for now the CFPB reaches is that TANs seem to have great value in terms of fraud detection, but opens it up to comment as to whether they are an acceptable substitute for tokenized account numbers/routing numbers.

• Referring to terms and conditions:

  • The CFPB refers to the power of including pricing, rewards terms, and applicability of arbitration agreements in the framework, as points that could help consumers with comparison shopping.

• Referring to upcoming bill information:

  • Specifically noted - minimum payment due on credit card statements or utility bills.

• Referring to basic account verification information:

  • The CFPB lays this out as being limited to name, address, email address, and phone number associated with the covered product.

  • There was some pushback around making available certain types of identifying information, including other demographic data, as it would open up consumers to privacy and discrimination risks.

  • The CFPB decided that in order for the framework to work effectively, they needed to have some sort of identifier(s) in place, and have settled on the above. They did briefly consider SSNs being part of the framework but decided the privacy/security risks would be too significant to make it worthwhile to include this as an identifier.

• There are several exceptions to the rule that are mentioned:

  • No sharing/revealing of confidential/proprietary information like algorithms that derive credit scores/risk scores/predictors.

  • No need to provide information collected solely for the purpose of preventing fraud or money laundering (i.e. information on SARs or CTRs).

  • No need to provide information that would be required to be kept confidential due to any other provision of law.

  • No providing information that could not be retrieved in the ordinary course of business.

The next SubPart (C) is a huge one. Hope you’ll stick with us as we progress through this massive proposal. Thanks and see you tomorrow for our fintech compliance event roundup!