CFPB’s 1033 rule won't change much

The rule largely codifies & standardizes industry practice, with key downsides

This post will walk through the verbatim CFPB press release on its Personal Financial Data Rights final rule (1033). I will highlight what is new versus what simply codifies industry practice. Everything I quote is verbatim, but I did trim some filler that doesn’t really address the rule.

The CFPB helpfully reminds us that the rule implements a Congressional mandate:

“Today’s rule is part of the CFPB’s efforts to finally activate Section 1033 of the Consumer Financial Protection Act, a dormant legal authority enacted by Congress in 2010.”

This has been coming for a long time, and early versions have been available for over a year. Lawsuits have already been filed to block the rule, but we will assume for this post that 1033 gets implemented as is.

How we got here

I was at JPM when aggregators first started ramping up. It triggered an arms race between the banks and the Aggregators: The banks tried to block access, while the Aggregators innovated around the blocks.

Banks were concerned about cybersecurity, data security, and the costly demands on their digital infrastructure. But the industry eventually came around to the view that the data was the customer’s property not our own – we just needed to safeguard that property, both to protect the customer and avoid liability. The bigger banks negotiated contracts with the aggregators that gave API access in return for mitigating the worst risks. In other words, détente.

We have lived under that regime for almost 10 years and the sky has not fallen. No major cyber events at Financial Institutions or Fintechs. Fintechs have grown rapidly, but generally as adjacencies to banks, not replacements. The Neobanks did gain share of low-balance DDAs, but these accounts are not material to bank profits.

The CFPB rule generally translates current practice into mandates, with an associated compliance burden. With a few exceptions, this doesn’t change much for end customers of larger banks. Standardization extends the contract concessions gained by the large banks to the full industry. However, it will increase costs for the banking industry and is strangely silent on liability.

The rule is more restrictive on aggregators than the current regime and may commoditize some of their services.

The press release

The intro summarizes what the CFPB are hoping to achieve in Open Banking:

“The Consumer Financial Protection Bureau (CFPB) finalized a rule that will give consumers greater rights, privacy, and security over their personal financial data. The rule requires financial institutions, credit card issuers, and other financial providers to unlock an individual’s personal financial data and transfer it to another provider at the consumer’s request for free. Consumers will be able to more easily switch to providers with superior rates and services. By fueling competition and consumer choice, the rule will help lower prices on loans and improve customer service across payments, credit, and banking markets.”

To me, this overstates the case. The banking industry is hyper-competitive with 6,000+ depositories where the top 10 have only ~50% share. The 10% national deposit cap keeps the biggest banks from growing inorganically. Neobanks have grabbed millions of accounts in just the last 10 years, mostly low-balance checking. Savings have flowed to the highest APYs, often from the remote arms of large consumer lenders.

Despite the wide availability of online origination, most consumers typically pick their checking bank based on physical proximity – which this rule doesn’t impact. While online savings accounts are already common and compete on APY, online checking accounts are relatively rare.

The Card business is more concentrated, with the top 10 having 80%+ share — but it is easy to switch credit cards: Just get a new one and stop using the old one.

The Apple Card took only five years to grow from zero to the 10^th biggest card program, so barriers to entry can’t be that high. Further, online installment loans have emerged as an alternative to revolving credit, and are widely available with instant approval.

The rule will reduce account opening friction, but not the KYC burden. Bank B can’t rely on Bank A’s KYC, so even if transferring data from A to B gets easier, the receiving bank still needs to perform the same KYC activities it does today.

“Consumers will be able to access, or authorize a third party to access, data such as transaction information, account balance information, information needed to initiate payments, upcoming bill information, and basic account verification information. Financial providers must make this information available without charging fees.”

This is a good summary of what commercial terms already provide; the incremental benefit from 1033 is standardization. No bank I am aware of charges aggregators or end-Fintechs for data or access. It is worth noting two things about their list:

1. “Information needed to initiate payments” likely means the routing number and account number so a Fintech can initiate ACH payments. It does not mean that the Fintech can initiate a payment from inside the incumbent bank, using Instant payments or Zelle for example. This is common in Europe where it is called PISP (Payment Initiation Service Provider). The CFPB is not authorizing PISP here and doesn’t suggest it will in the future

2. “Upcoming bill information” is not typically held by the depository. Most recurring bill payment is initiated by the biller without notifying the consumer’s bank — both for ACH and card on file. Some bank bill pay models include bill presentment but this has less than 20% adoption by consumers and that rate is declining. Even those who sign up are reducing the number of bills they pay that way. There is no Open Telco, Open Utilities or Open Streaming initiatives that could port billing data to a new account. Recurring payments like these will remain a barrier to exit on Checking

“… the CFPB will be developing additional rules to address more products, services, and use cases. The rules will boost competition by giving people more freedom to switch banks or providers and shop around for the best deal. This increased choice will incentivize financial institutions to offer improved products that help them attract new customers and retain old customers.”

Unless the CFPB is considering PISP rules, this is exaggerated. The market already offers dozens of services that compare bank accounts or card offers. Credit Karma is an example on the credit card side and BankRate.com on the deposit side. On both sites you can originate a new account digitally, often using Open Banking.

In DDA, most banks offer free checking with a relatively modest minimum balance plus direct deposit. Nuisance fees differ across banks but, the core service is already free for a high percentage of consumers. Neobanks have added millions of accounts by offering free checking to lower-balance customers.

Open Banking may reduce account-opening friction, but consumers already open accounts online in high numbers.

“Today’s rule also establishes strong privacy protections, requiring that personal financial data can only be used for the purposes requested by the consumer. It ensures that third parties cannot use consumer data for other purposes that benefit the third party, but that consumers do not want.“

This provision limits aggregator activities. I have spoken to aggregators in the past who wanted to use the data they gathered to create new credit scores or sell aggregated data for marketing. The contract model limited that activity, but not all banks have such contracts.

“It also helps move the industry away from “screen scraping,” a still common but risky practice that typically involves consumers providing their account passwords to third parties who use them to access data indiscriminately through online banking portals.”

This is mischaracterization about the risk of screen scraping. Screen scraping captures data in the absence of API aggregation. In both cases, the aggregator gets access via the consumer’s online banking credentials. But in screen scraping it has a bot navigate the banking site to get data while in API aggregation the data is transmitted digitally, in a structured format.

In the contract model, credentials are usually exchanged for a sign-on token and then deleted. Perhaps, what the CFPB means is that more banks will move to the token model, which reduces the risk from holding credentials.

It is also true that banks without contracts can’t limit what aggregators scrape. The 1033 rule gives non-contract banks the same protections that contract banks have today, whether they are screen-scraped or have APIs. The rule levels the playing field.

“… the Personal Financial Data Rights final rule will spur greater choice and increase competition by enabling people to:

• Fire fintechs and banks that provide lousy service: ….

This point repeats an argument they make earlier in the document

• Shop for better rates on products and credit ... It can also help people—including consumers with shorter credit histories, like young people—gain access to credit or obtain credit on better terms, by allowing lenders to make loans using data held by other institutions, such as information on income and expenses.

This is important, but not new. The industry has long wanted to deploy on-time bill payment history as an indicator of creditworthiness in new-to-credit households. Today’s contractual arrangements support that use case, but the rule will make it more universal. Customers of exempt banks are out of luck.

• Make secure payments, including with “pay-by-bank”: The rule ensures consumers are able to securely share payments information, which can help enable what is sometimes referred to as pay-by-bank. Such products enable consumers to pay merchants, peers, and others, as well as move money between their own accounts. The rule will help bring greater competition to payments markets, which have long been an area of anti-competitive practices.”

This is odd. All the use cases they mention are either addressed today or not limited by the easy availability of the account number:

• “Payments information” means DDA account number. Aggregators commonly get that today to set up services like PayPal & Venmo. This is not new

• “Peers, and others”. Zelle offers a superior solution by replacing account numbers with email or mobile number. Zelle is free and almost universal

• “Pay merchants”. A2A faces a Reg E barrier: Neither ACH nor Instant Payments have chargeback and return processes, and therefore, neither does A2A. Zelle has faced a DC firestorm on this topic

• “Move money between their own accounts”. Why does a consumer need an aggregator to tell them their own account numbers? The aggregator logon is as much work as typing in the account number yourself. This Me-to-Me use case is one of the first ones banks themselves are deploying for RTP & FedNow

If you buy all that, the new rule does not really facilitate more use of “pay-by-bank”.

“The final rule strengthens protections for consumers’ data by:

Banning bait-and-switch data harvesting: Third parties can only collect, use, or retain data to deliver the product the consumer requested. They cannot secretly collect, use, or retain consumers’ data for their own unrelated business reasons – for example, by offering consumers a loan using consumer data that they also use for targeted advertising. The rule does not prohibit any particular uses of data, but it requires that all use be driven by what is necessary to deliver the product sought by the consumer.”

This is a limitation on Aggregators and Fintechs. These practices were common in the pre-contract age. I recall watching a transaction where the Fintech told the consumer they were just going to lift the DDA account number. In fact, we watched as the Aggregator stripped every shred of data from the account. With contracts, this behavior went away – at least at banks with contracts.

Now that the Aggregator or Fintech needs separate consent for on-us use cases, these tactics are more difficult. Some people simply won’t consent.

“Creating revocation and deletion rights: When a person revokes access, the rule requires that data access end immediately, and deletion would be the default practice. Access can be maintained for no more than one year, absent express reauthorization. To prevent “dark patterns” from emerging, the process to revoke access must be simple and straightforward.”

This is not a direct function of Open Banking and is more in line with other efforts by regulators to make closing an account as easy as opening one. The data deletion rule is in many bank contracts today.

“Compliance with the rule will be implemented in phases, with larger providers subject to the rule sooner than smaller ones. Financial firms will be required to comply based on their size; the largest institutions will have to comply by April 1, 2026, while the smallest covered institutions will have until April 1, 2030. Certain small banks and credit unions are not subject to this rule.”

Apparently, the CFPB thinks small bank customers don’t need protection from high APRs, low APYs, and high fees and they can continue to be exposed to screen scraping. One perverse outcome could be that consumers move to larger banks where they can easily share their data. If I were a small bank, I would comply voluntarily.

In the rule, but not the press release

The press release is an excellent summary of the actual rule, but it misses a few points that will be operationally important:

Frequency restrictions

“… a data provider must not unreasonably restrict the frequency with which it receives or responds to request for covered data from an authorized third party through its develop 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 … Indicia that any frequency restrictions applied are reasonable include that they conform to a consensus standard.”

This caught my eye because of analysis I did at JPM. I was examining our Card app to see how often cardholders used it. I was skeptical that anyone would use a card app more than a couple of times a month, but our average was 2+ times. Assuming a normal distribution, half of customers seemed to use it more. To find out why, I quintiled the data to see if it was in fact a normal distribution or whether a few power users were driving up the average.

What I found was that 95% of activity was in the fifth quintile. We had a lot of low-frequency users, as I expected, and 20% power users, which seemed high to me. I then quintiled the top quintile and got the same distribution – 95% of activity in the top 4% overall. I kept doing this until it emerged that a tiny slice at the top were doing 1000+ transactions per month. And virtually all other users were 1 or less.

It seems obvious today, but Aggregators were hitting our mobile API many times each day to get the most recent information. Virtually 100% of our API server cost was to support the fraction of customers using aggregators. The later Aggregator contracts limited access frequency and timing to address this cost problem – but we never charged aggregators for the capacity.

The word “reasonable” and “consensus standard” appear in the text, but the definition of those terms is left to a “standards body” that will balance all interests. I don’t think it is important for account opening activities as these are rare. But for transaction activity the definition matters a great deal.

One possibility is to set the standard at the highest frequency of an actual human. In my example, that would be set it at 2-3 transactions per month for a pure card application. But I doubt that will satisfy Fintechs.

Another way to deal with it is for banks to have a “push” API. In that model, Fintechs could specify what transactions they need and the bank would push out the data as those transactions occur. For example, an average active Debit Card does 30-40 transactions per month. So the bank would push out each auth or settlement in real time instead of having the Fintechs ping the account many times per day. Apple Pay does this today. This lowers the server burden while improving Fintech capabilities. Not all banks may like that trade-off.

Compliance burden

This is a regulation, so you expect paperwork. 1033 creates lots of it with no associated revenue. In fact, if the CFPB gets its wish, banks will compete away revenues they have today. Bank tech costs will also go up as more fintechs extract bank data.

The industry could reduce the paperwork burden through a utility. If you read my post on Utilities, this counts as a “network effects” utility. The utility would certify all the Aggregators and provide them with a common integration point. On the bank side, it reduces the number of integrations to one. It does not reduce a bank’s server demand as they still need to respond to every request, but, every request and response goes through the utility rather than hundreds of independent connections to Aggregators or Fintechs.

The regulation explicitly allows banks to use a third-party as a “service provider”, so long as that service provider is held to the same performance standard as the bank itself (1033.311). That allows each Aggregator and Fintech to go through fewer certifications and still reach many banks. The utility manages many (but not all) compliance burdens on the bank side.

Fortuitously, such a utility already exists as Akoya. They already provide the single integration point for many large banks that chose to use it. These banks represent a material share of industry accounts. This is not an area of competition between banks, so the cost-savings logic is compelling.

Liability

Mystery novels have a concept called “the dog that didn’t bark”; In other words, something didn’t happen that should have. In the rule, the “bark” is liability, which is not mentioned in the text. However, liability is a major issue.

Before the contract era, banks worried that sign-on credentials and PII might leak from Aggregators or end-Fintechs. Sharing sign-on credentials was a violation of bank terms-of-service, but the Aggregators were encouraging it. If a criminal got sign-on credentials they could empty the account.

The Aggregators responded that they were using major cloud providers that had at least as good data security as the banks themselves. But that didn’t address the insider problem. If an employee takes the data they have the keys to the kingdom.

The technical solution was to replace in-the-clear sign-on credentials with tokens which won’t work outside the specific Aggregator or Fintech. That works at API banks but not at screen-scrape banks. And the insider problem remains.

If PII or credentials leak to criminals, how would we know where the leak came from? When the customer demands their money back, who pays? It may be impossible to find the culpable party, but regulators are likely to make the banks responsible. This has already happened at Zelle, where even when the account owner willingly sends money to a scam artist, the regulators want banks to make the account whole. Perhaps the standards body can address this issue, or some technical solution will emerge. For now it is a red flag on the entire initiative.

Implications for each role in the value chain

1033 largely codifies the status quo established via commercial contracts. But, there are winners and losers on the margin. Those largely align with whether standardization improves access and performance or whether it commoditizes certain roles.

Banks (data providers)

Banks are neutral strategically, but losers on cost and liability.

• Big banks already provided most of the what the rule requires, but now incur a compliance overhead to prove it. A utility like Akoya can reduce those costs

• The smallest banks were screen-scraped previously, and these exempt banks will continue to be. Nothing changes for them

• Banks in the middle need to develop or contract for the necessary APIs – raising their costs but not their revenues. Their core systems may not be modern enough to support the “consensus standards”, requiring them to either upgrade, outsource to a more modern core processor, or sell-out to a larger bank that can comply economically

The middle group faces similar challenges in supporting Zelle & Instant Payments. All these innovations add third-party cost but not revenue. Collectively, all these extra costs may push some to sell out.

Bigger banks will build a largely fixed cost infrastructure to support 1033, but small banks will rely on their service providers who charge by the transaction. While all size banks will see higher average costs, big banks will still have low marginal costs, while smaller banks won’t.

Some parts of banks will benefit from the new capabilities. Onboarding will be easier as the basic customer demographics can be extracted from the incumbent bank. PFM solutions will be easier in wealth management units. And the banks themselves can innovate new services that consolidate fragmented relationships.

But it is worth emphasizing that the lion’s share of new accounts are still opened in branches. Branches may use open banking themselves, to reduce account opening friction. CSRs can accelerate paperwork while refocusing on cross-sell & up-sell.

Banks also need to keep their digital assets current. Since most attractive checking accounts are free to the higher-balance customer, branch proximity and digital channels are what will differentiate. Neobanks took low-balance accounts because they were free, while entry level bank accounts charged fees. Neobanks also had CX’s tailored to the low balance segment. I see no new challenges for higher-balance customers due to the rule. Banks like Schwab were already competitive in the segment.

Finally, banks lose if the liability issue isn’t solved via subsequent rule revisions or stronger security standards. Banks have the deep pockets that victims will target.

Fintechs

Fintechs could be big winners here, but I don’t think that is quite right. They already had extensive data access through the contracts model, but now face legal limits on what data they can ask for and how they can use it. Many of them had stealth strategies to cross-sell or upsell using that extra data. That will be hard to come by going forward. They may benefit from reduced Aggregator fees as standardization commoditizes that role in the value chain.

Data Aggregators

Be careful what you wish for! Aggregators now have guaranteed, free access to bank data; but, they can’t use any of the data for their own purposes. The standardization inherent in 1033 reduces the differentiation among them, and will likely squeeze pricing.

Aggregators can still differentiate along at least two dimensions: screen scraping the long tail and integrating with non-1033 entities.

• Small, exempt banks hold as much as 20-30% of bank accounts and a smaller percentage of card accounts. If Fintechs want to reach them, Aggregators will need to scrape them

• 1033 only covers financial institutions. Data from telcos, utilities, streaming services and other providers can be valuable supplements to bank data as we saw in recurring payments. As one example, Earned Wage Access providers need payroll data. There is no legislative driver like 1033 for these industries so it remains white space for Aggregators.

A2A providers

I don’t see much of an A2A tailwind from this rule. Most A2A remains on ACH and 1033 does not make ACH any faster or deal with its Reg E compliance challenges. Only if the CFPB expands to the EU-style PISP model will that happen. In the meantime, Zelle is also an A2A method that is already free, real-time, and email/mobile driven. A2A via ACH isn’t competitive in P2P.

1033 does expand the universe of API-driven banks, making it easier to extract onboarding information, particularly account number and transaction histories.

Key insights

• 1033 codifies market practices established by the biggest banks via Aggregator contracts. It standardizes those practices across all regulated banks. In this sense, it levels the playing field for the end consumer

• 1033 does not deliver most of the benefits the press release claims, either because those benefits are already available or because they are not impacted by Open Banking, for example:

  • In most APY- or APR-driven products, the market already has price-comparison marketplaces with on-site origination

  • For DDA, Open Banking makes in-branch origination more efficient and does not help remote banks overcome the branch banks’ proximity advantage

  • For recurring payments, depositories and card issuers don’t control payment origination, billers do. This remains a barrier to DDA account portability

  • For A2A, data access is not the only obstacle, for example:

    • Many use cases have ubiquitous, low-cost solutions, especially P2P (Zelle)

    • Commerce (C2B) needs returns & chargebacks to be Reg E compliant

• 1033 raises bank costs and risks:

  • Compliance will be administratively expensive

  • Banks must provide free technology infrastructure to support the Aggregators. The magnitude of that cost depends on a consensus-driven standards body

  • Liability is not addressed, leaving banks vulnerable to security failures by Aggregators and Fintechs

• Industry utilities, like Akoya, can mitigate these issues but not eliminate them

• For smaller regulated banks, 1033 is one of several new, table-stakes services that add cost, without an associated revenue stream. The other two are Zelle and FedNow/RTP. At some margin, these collective costs may prompt consolidation

• For the smallest exempt banks, the exemption leaves their customers exposed to the security and accessibility risks of screen scraping