Before listening to anyone on this topic its important to get a feeling for experience. I’ve been fortunate to run two of the largest online banks: Citi and Wachovia. Wachovia was the very first customer of Yodlee (1999), a service our customers loved. My banks were also scraped endlessly, representing over 30% of our traffic and 20% of our call center complaints. We were also the largest PFM bank (think MS Money and Quicken), keeping our OFX servers up and running was key. After my banking life I spent time rearchitecting payment data flows from point of sale to payment at Google. Then spent 8 years creating Commerce Signals, a payment data business. 
CPFB’s Proposed Rule

300 pages is quite a bit to get through and I haven’t finished yet. Here is my quick take

1. This rule will happen. It makes logical sense the consumers own their data and have a right to send it to whomever they want.
2. Most banks make the information available directly to consumers today (ex download your transactions). Plaid, MX, Yodlee and other aggregators have also built developer APIs based on screen scraping that has evolved SLOWLY (ie last 18 mo) into modernized OFX feeds with tokenized credentials (see blog Open Banking, Open Payments and Trust Networks)
3. The “new” requirement is for all banks to provide developer API access. Standardization here makes sense both in tech and inthe structure of agreements (ex data use, consumer consent, regulatory enforcement). While banks are regulated, data requestors are the wild west. Banks will likely be able to charge developers connection fees to cover costs of building and maintaining the developer interface (Section VI D page 197) “Reported estimates of the cost of establishing and maintaining a developer interface varied widely, from $2 million to $47 million per year, with a median of $21 million per year”.
4. A KEY technical element missing from the CPFB’s cost analysis is the allocation of infrastructure costs based on usage. For high availability systems, fault-tolerant infrastructure, network, fraud controls, authentication, customer notification, and people are needed to operate. Online/Mobile banking are allocated that cost based upon the number of transactions. Adding a new channel can result in INCREASED transactions incremental to current behavior which requires infrastructure investment. To be clear these costs do no scale toward 0. The CPFB looks only at the IMPLEMENTATION and development costs of the APIs, not the operational costs to maintain the 98% availability. 
5. There are also 4 key data ownership gaps in the CPFB’s proposal. 1) I would propose adding a core rule: Customer owns the data, and all derivative data, at all times and the permissions to use the data must be held and maintained by the data requestor. 2) define the responsibilities of a data requestor (a term not defined) and their explicit requirements under the rule (safeguarding data, restrictions on use), 3) Derivative data. This is the slippery slope of all 3rd party data managers. They talk about the controls and permissions around the consumer data, but their derivative data products are their own property that they can sell (ie anonymized and aggregated spend for xx). 4) Data requestor penalties and monitoring of data requestors. Fraudulent actors must incur both fines and restrictions on access. The industry needs a regulatory framework here to make this work. 
6. Bank Switching. CPFB’s goals are similar to UK, EU and Australia. Enable competition and “switching”. The average US consumer keeps their bank account for 14 yrs and the bottom 40% of most retail banking customers are unprofitable. This means many bank CEOs would love to see the bottom 40% leave. While bank customers will instantly switch if savings rates differ by 0.05% in the UK (my Citi team bought Egg in 2007), US customers won’t switch for 5%. It makes no sense. 
7. Biggest impact – Cross Sell. The driver of retail banking profitability is cross sell, and the online/mobile channel is the primary point of interaction. Retail banking customer log in, check balance and pay bills about 6 times per week, Zelle users can move that up to almost 12. Each of these interactions are a cross sell opportunity. Taking away balance inquiries could lead to a drastic reduction of cross sell.  For example, Apple and Google will now be able to show any bank balance in the “wallet” (see Apple UK). Banks will thus be highly dependent on new “unique” bank services (ie Zelle, Paze, RTP, …etc). This is why we are seeing such urgency by banks to construct new services that require direct interaction (ie can’t be aggregated). 
8. Banks – Minimal impact in 5 yr view. After the finalization of the rule and implementation (2026), I expect very little impact to retail banks, as they already provide “open banking” like access directly and through 3rd parties. Today big banks are winning on “flight to safety”, scale and brand, but also because US consumers are a mix of satisfied, apathetic, loyal, and unprofitable (w/o cross sell – blog Future of Retail Banking). 
9. Payments  – No impact to V/MA. Does this enable expansion of A2A? Perhaps. It will provide PSPs with ubiquitous access to balance information. But merchants aren’t exactly keen on running everything like a check, as they hold responsibility for collections and fraud with no network tools (see blog). I don’t see this impacting Visa Direct/MA Send either.  Their interfaces provide the economic model. 
10. Fintech/Big Tech. A win for them in creating great new customer experiences. This data will be an ingredient in great things. If Google can learn your preferences it can better market to you. If small FIntechs gain consistent ubiquitous access to all banks, customer can move to smaller banks without concern for losing key services. 
11. Plaid/MX. Why go to an aggregator when you can go directly to the banks themselves? It would seem this will impact aggregation in a 3-4 yr view.