We are here at the end of our 1033 analysis! Not even going to bother with the pleasantries, let’s get right to business! We pick up after having covered requirements for data providers and third parties.
Providing financial data processing or services by any means will constitute a financial product or service under CFPA - using provision in original rule to implement this - also “permissible to offer” and “will materially impact consumers”. Definition is basically fintech - “payments and other financial data processing to a consumer by any technological means” - emphasis on “other financial data processing.” Choose to lean into the latter and state this now includes “providing data processing products or services”. After noting that from their POV, this expansion covers both criteria (I.e. “permissible to offer” and “material impact”), they point out that the existing rule has exclusions for certain merchants, retailers or sellers of non-financial products or services engaged solely in initiating payments and for any tech player that just provides the host server for websites. - My thoughts - it seems like quite a bit of an expansion to go from “financial data processing” to “data processing” - although they have a caveat to exclude certain parties, I’m almost positive the expansion is to target the bureaus, namely Experian, Equifax and Transunion. The CFPB has been after them for years and they wouldn’t miss an opportunity to codify their oversight of them even further.
In terms of effective date, the CFPB states the rule will go into effect 60 days after publication in the final register.
So we’ve heard about the background of the state of financial data, we’ve heard the proposals in detail and we’ve heard who is involved. The next section is the most fascinating - the analysis of cost, benefits, and impacts:
“The mission statement” aka “Statement of Need” - Consumers should have control over their financial data, but generally do not, and the end result is data security and privacy risk, amplified by access to this data by third parties (who also don’t have a secure/efficient way of receiving the data anyway) and a general lack of motivation on the part of data providers to improve any of this. When data is available, there’s a lack of consistency between different providers in how/what data is made available, and cost that is incurred when third parties and providers try to get on the same page to bridge the gaps.
In referencing the data and evidence used to come up with the proposal, they reference a lot of sources, including request for comment, public events/“townhalls”, and consultations with various parties. They touch on some of the data they are able to estimate (or presumably directly obtain) based on the sources - namely potential data providers, third parties, and consumers that would be applicable/relevant to the proposal, along with information about the technology and the data in question. They also rely on FFIEC and NCUA call reports, which for each institution give some dollar level information and the number of deposit accounts, but don’t give the number of credit card accounts. Lastly they use SBREFA data to get information relevant to small businesses. - My thought here is that it would have helped immensely for the CFPB to outline the specific big-picture data they are using to underscore the need/importance of the proposal. I get that it would be estimates, but this is a huge missed opportunity to truly underscore the problem they are trying to solve.
As with any assessment of risk, the CFPB considers a state where there is no regulatory action from them and no regulations exist (which in theory would already be attempting to limit the cost of such a proposal) and try to identify the likelihood and impact of whatever they are trying to assess (in this case, cost/benefit). We start with impact, and this is a good excuse for us to hear the numbers they are considering when they came up with this proposal (and although they don’t specify, I will assume they are referring to US based items here):
100 million consumers have used consumer-authorized data access
Between 50-100 billion total consumer-authorized access attempts in 2022 (doubling between 2019 to 2022)
More than 2 billion access attempts to facilitate payment services
More than 1 billion access attempts for identify verification
“Tens of billions” of access attempts for account monitoring and personal financial management
Over 1 billion access attempts facilitating other uses cases (i.e. fraud risk assessments, loan underwriting, asset/income verification)
Use of credential-free APIs has grown from less than 1% in 2019/2020 to 9% in 2021 and 24% in 2022 (of all access attempts).
Share of access attempts using screen scraping has declined from 80% in 2019 to 50% in 2022
Credential-based APIs have seen a slight increase from 20% in 2019 to 27% in 2022.
Between 5-10% of all data providers offered credential free APIs (up from less than 1% in 2021)
Only between 10-20% of depositories with more than $10 billion in assets had credential free APIs at the end of 2022.
They then share some of their assumptions under which they developed the baseline:
Most (if not all) of the largest data providers have adopted or likely will in the future adopt credential-free APIs. Some amount of smaller institutions would adopt credential free APIs over a longer-term horizon - depending on how well integrated they are with a core banking/online banking service provider, or how little complex legacy system infrastructure they have.
All/most data providers/third parties are subject to GLBA, FTC’s Safeguards rule or Federal functional regulators’ interagency guidelines, along with state-specific consumer data privacy legislation (if applicable for 11 states). Some third parties have FCRA obligations.
More on costs:
Data providers’ maintenance of the interfaces (i.e. having to use a vendor to create a developer interface - some acknowledgment of core banking providers who throw in an interface at no additional cost - the rate of $24 per account per year is cited - but also noting that other providers will not) and having to modify their existing systems to comply with the rule, along with adding policies and procedures to govern. It’s estimated that 67% of core banking providers in the market offer a developer interface, but this doesn’t necessarily correlate with how many data providers will have to go to another solution outside their core banking provider. The idea of doing it in-house is raised, and the estimate is given that this could take up to 5200 hours of work (i.e. 3-6 months of work by a team of 5) with a cost of up to $475K staffing-wise. The CFPB has smaller estimates for nondepository data providers. (My thought - but relatively speaking, as a % of total costs, how truly small?) There were some self-reported estimates by data providers that went as high as $47 million to create a developer interface, but the CFPB dismisses this as coming from the most complex of institutions.
On implementation of “policies and procedures,” specifically around disclosures, access, completeness of transfer (i.e. controls around accuracy/completeness), the CFPB states they believe this should be inherent but some providers may want to invest in increasing the robustness of their controls and this could add some additional burden to institutions that choose to invest - with a “one time cost” of up to $11,900 per provider.
There are going to be a lot of lawyers, business relationship folks, management meetings, etc that will need to be involved to build out or create relationships between the data providers and third parties. The CFPB thinks that the rule will actually help reduce this compared to what is already happening (!!!) because relying on the industry standards should eliminate the need for negotiation, and they dismiss the possibility of customization. I don’t think they understand how insistent engineering teams/leaders and product folks are to customize, as an example of demonstrating competitive edge. They give an estimate of $68,000 per large data provider at maximum (which as you can tell above, I disagree with).
Non-financial changes: The CFPB will eliminate the ability for data providers to charge fees to third parties to access the interfaces (Fair enough, and it apparently isn’t super prevalent anyway). They will also allow third parties to make more requests (by doing away with any ability for data providers to implement access caps). The conclusion is that all of this will do away with the “first party” advantage that many data providers have by being the gatekeeper of consumer data. I can get behind this, as the perception of the data providers being the ones entitled to the data does a disservice to the consumer, and the idea is to democratize it at a minimum, or at a maximum put the ownership fully in the camp of the consumers themselves.
On the topic of third parties and costs to them, they’d have to:
Handle revocation requests, track limited authorizations, delete data when required, identify lapsed durations, and retain records. Some of this is already required, so they don’t see a huge lift as compared to what is expected for data providers, but it’s still up to $75,000 (although the small entity representatives say it’s closer to over $90,000).
Deal with annual reauthorizations which might impact the quality of data that third parties have at their disposal (i.e. for creating analytics/insights for consumers). It might also tick off customers according to the small entity reps. There’s also evidence from UK open banking that this might be the case. Interestingly, for seemingly the first time in this document, rather than saying they “seek comment” on whether there’s more insights on whether consumers might attrite/leave/drop third party solutions because of these authorization/re-authorization requirements, the CFPB just says they do “not have data to estimate the costs to third parties of lost customers” and leave it at that. Fascinating.
Disclosures and certifications - up to $91,300.
Record retention - covered in existing costs under reauthorization/etc (not sure I agree)
Development of policies and procedures - up to $8,200.
Moving away from screen scraping - $6,800
General reduction in profitability due to increased restrictions on third party access to data
The addition of UDAAP to the compliance burden, which the CFPB again says they “do not have data to quantify these potential costs.” Feel like that is a bit disingenuous, given the CFPB is the one who enforces UDAAP.
For consumers - the CFPB acknowledges some of these increased costs to data providers and third parties will inevitably get passed on to the customer, with the following notable:
Changes in industry structure - 51 million consumers have accounts currently connected to third parties through credential-free developer interfaces, and the CFPB thinks that this is an undercount - the point being, since they are already connected with third parties, they would bear less of the cost burden given the relationship already exists. But that assumes new third parties wouldn’t innovate or third parties with existing relationships wouldn’t launch new products.
Changes to underwriting decisions - this could impact customers getting higher cost for credit with more information at the disposal of the third parties.
Time cost of reauthorizing third party access annually
Changes in pricing models due to use and retention limitations - as an exchange for not having the data as long, third parties may need to charge customers more to make up for the gap in good analytics that they would have been able to develop with more consumer data available to them for longer.
With all those costs, what are the benefits? We’ll breeze through these, because our newsletter tries to focus on things you should be worried about from a compliance perspective, and we aren’t necessarily finding this proposal to be a net win for any of the parties, but some of the benefits in the view of the CFPB follow:
For data providers
Reduced screen scraping
Reduced per-agreement negotiation costs and more standardized terms of access
Restrictions on third party use and retention of data
Required data security representations by third parties
For third parties
Right to access data through third parties
Prohibition on data access fees
Reduced negotiation costs
More frequent access to data
Improved accuracy of data
Improved service quality due to improved data access
Reduced costs of establishing and maintaining screen scraping systems
Increased standardization
For consumers
Right to third party data access
Credential-free access - increased privacy, reduced data breach risks
Third party limitations on collection, use and retention - ability to be forgotten, increased privacy, more control over use of own data
For all three parties, very few of these items are benefits just for the sake of benefits. Almost all of them are benefits at the expense of one of the other parties. The only ones that stand out are the privacy/security improvements and the reduction in negotiation. Beyond that, all the other benefits are contradicted by a cost/detriment elsewhere. So I’m not sure I’m buying what the CFPB is touting here.
The CFPB dives into the effects of increased data sharing on innovation and competition, claiming that consumers could be equally likely to have improved credit decisioning because of this proposal as they would have reduced opportunities for decisioning, but I find this unlikely given the past approaches of institutions. They cite potential reductions in overdraft given easier access to information that consumers would have, as well as reductions in cost of switching/shopping for institutions, but the key is that the providers would need to play ball to make this a reality. The CFPB cites indirect effects of lower interest rates and improved prices and services, and they cite a potential of $77 million in reduced fees annually.
The CFPB gives some love to small depository institutions and credit unions with less than $10 billion in total assets, and essentially says that a) they will need vendors and b) they don’t have enough data to make an assessment of the impact. Whoops - not feeling the love after all. The same is true for their view on rural consumers, with them essentially using the cop out of the fact that they don’t really use online banking as meaning much of this proposal wouldn’t apply to them.
The proposal closes with an analysis of the applicable regulations and regulatory reporting that would be emphasized or come into play, along with some more of the costs. There is a useful table on Pages 253-255 that details the estimated impacted entitites by NAICS category.
It’s been a number of weeks since we’ve dove into this. The more time I’ve spent diving into this, the less excited I’ve gotten. I am usually a big fan of consumer protection, but the more I read this the more apprehensive I get. I’ll share what I commented with my good friend Jon Zanoff (who has his own rant on this topic that I highly recommend):
“It’s a total slog - there’s a lot of reference to “standardization” and uniformity, but for all that talk there’s only a handful of things they standardize (I.e. response rates, record retention periods, etc) and I suspect the reason for it is that they don’t have the technical literacy to be able to create a truly technical standardized framework. They mask this in the “we’re trying to make it easy for the institutions” cloak, but I suspect that’s not the real story here. It was always super ambitious for them to try and tackle this on their own, and given how much “the CFPB seeks comment” there is in it, I’m not sure why this was something they pursued, other than to try and start a conversation. It almost seems like they have gotten an earful on third party and so they may have scaled back their intentions with this one, but the end result is a bunch of “hey we’re taking a laissez faire approach.” I keep waiting for the punch line as I peruse through this thing, but haven’t found the “aha” moment yet.”
Spoiler alert - I never found the punch line. In any case, I hope the CFPB takes all this feedback to heart and rethinks this - at a minimum, I do hope they don’t try to rush this through.
Phew! Thanks for staying with us through this coverage. We’ll see you next week as we move on from the beast of 1033.