Re-published with permission from Alex John, Fintech Takes Newsletter. Click here to subscribe.

Everyone talking about open banking right now is laser-focused on the fight over fees and cost recovery. However, there’s another fight that is getting less attention, but is (perhaps) more important — the fight over liability and third-party risk management. We’ve made tremendous progress over the last decade in moving the open banking ecosystem away from screen scraping and towards APIs, with much of the heavy lifting being done by the technical standard-setting organization FDX. APIs reduce credential sharing, but a larger and thornier problem remains: when a consumer grants access to a third party, who’s actually responsible when something breaks?

In today’s podcast, I am joined by Steve Smith (Co-founder & CEO of Invela; former Co-founder of Finicity and of FDX), Todd Taylor (Co-head of Intellectual Property, Commercial & Technology Transactions at Moore & Van Allen), and Dan Murphy (Founder of Sunset Park Advisors; former CFPB Open Banking Program Manager). Tune in for the full conversation here. And read below for my three big ideas… 

#1: Data Rights for Consumers, Risk and Liability for Banks – There’s a contradiction at the heart of Section 1033. Consumers have the right to share their financial data wherever they want, yet when something goes wrong, it’s still the bank that is on the hook for it. That leaves banks in the strange position of having their customers bring them third-party “vendors” they’ve never heard of and insisting they work together. Under Reg E (the implementing regulation for the Electronic Fund Transfer Act), banks must reimburse customers for unauthorized transactions even if the transactions are facilitated by a fintech company or data aggregator. And the rulebook they’re told to use — OCC Bulletin 2013-29 and the later Interagency Guidance on Third-Party Risk Management (June 2023) — was written for a different world, when a “third-party vendor” meant FIS or Jack Henry (versus a fintech app connecting to a bank’s systems through APIs because a customer granted it access).  The prudential regulators’ FAQs explicitly clarified that data-sharing relationships in open banking count as third-party relationships, pulling banks under the full third-party risk management framework even when the consumer (not the bank) selects the third party. So, banks are told to enable open access, but they are judged by risk management standards that were designed for fundamentally different types of relationships.

#2: The Infrastructure of Trust – Under Section 1033 of Dodd-Frank, the CFPB’s rulemaking aims to cement consumers’ right to access and share their financial data. This is consistent with the agency’s mandate to spur competition that benefits consumers. However, it’s important to note that the CFPB is not responsible for ensuring that open banking doesn’t jeopardize the safety and soundness of the U.S. financial system. That responsibility falls on the prudential bank regulators (the OCC, Federal Reserve, and FDIC), which haven’t historically been interested in harmonizing their efforts with the CFPB (there’s a big brother-little brother dynamic at work here).  Given that, it may make more sense to place some of the responsibility for integrating banks’ open banking and risk management requirements on the banks themselves. We wouldn’t want this to be done on a bank-by-bank basis. Rather, we would want to facilitate this through the development of new, industry-wide standards and accreditation processes. There is plenty of precedent to guide us here. When card-data breaches surged in the early 2000s, the card networks didn’t make every bank and merchant invent its own rules.  Instead, they created a shared standard (PCI DSS) that applied to anyone handling card data. Independent Qualified Security Assessors (QSAs) verify compliance, and those uniform controls have become the connective tissue that lets millions of merchants plug in securely. The big question: could the open banking ecosystem do the same?   Steve and the team at Invela think so. They are trying to create a single, transparent accreditation process for data recipients, a public registry of approved participants, and a dynamic risk score updated in real time. That means if and when a fintech company’s risk profile changes, a bank can throw a breaker and pause access (all while staying within a prudentially acceptable safe-harbor framework). It worked for payments; it could work for open banking. The question is whether the U.S. ecosystem will align on a standard approach before a major breach or breakdown forces it to.

#3: Sharing the Risk – Under Reg E and Reg Z, banks have to make the customer whole even when a failure by a third party (chosen by the customer) is what triggers the loss. To put it mildly, banks don’t love this.  One solution that Invela is pursuing: what if accredited third parties could back their data access with a warranty-based risk-sharing product, essentially an insurance-style mechanism that covers losses their systems create? That coverage would give banks some assurance when things go wrong. The question, of course, is would the third parties (or the aggregators they use to access the data) be willing to pay for this? As we have seen with the debate over fees, the fintech side of the market is very accustomed to getting customers’ data for free, and getting them onboard with paying for insurance (in addition to paying for access to the data itself) may be a tough sell.