TL;DR — The financial industry spent fourteen years fighting over §1033 only to cover basic bank accounts and credit cards. The data required to understand a complete financial picture — brokerages, retirements, and mortgages — was completely left out. Meanwhile, the access consumers do grant comes with zero guardrails: no declared scope, no committed duration, no guarantee that revoking access actually works. Regulators keep missing the mark, and the rest of the industry quietly capitalizes on the gap.

After more than two decades in fintech, I recently began building a product that relies on aggregated bank, card, and investment data. I have a horse in this race, and you deserve to know my bias upfront before reading any further.

Going into this, I expected the hard part to be the modeling. It wasn't. The modeling is the easy part — and surprisingly, so is the basic data access everyone spent a decade and a half arguing about.

The code is commodity. The permission isn't.

SaaS is cheap. Today, one person can ship a consumer finance app. That Monte Carlo regression that looks so impressive from the outside? It's a commodity. Every tool in the category uses the exact same approach, sitting in open-source libraries that anyone can pull down.

So if the code isn't the moat, what is?

Three things, and none of them is engineering: getting to a customer, getting that customer's data, and being allowed to say anything useful about it. Permission to reach someone, permission to see their information, permission to advise them.

This piece is about the middle one.

Banks share plenty. They just share what's easiest.

First, let's kill a lazy idea that banks refuse to share data. They share enormously. FDX-standardized connections grew straight through the litigation — hitting roughly 76 million in 2024, 114 million by spring 2025, and north of 130 million in early 2026. Plaid's own docs claim over 10,000 institutions across the US and Canada. (Though it's worth noting that number is inflated by brokerages, card issuers, crypto exchanges, payroll providers, and multiple entries per brand.) Either way, data is moving constantly, at a scale most people would find surprising.

But what's moving isn't a consumer right. It's a pile of bespoke deals, negotiated bilaterally, institution by institution, non-standard by construction. At the commercial layer, data access is a gradient: how much, how often, and on what terms, renegotiated whenever leverage shifts. But at the consumer layer — where a person is approving one specific thing — it collapses into a binary switch. Approve the checking account, and you hand over far more than just the checking account. No consumer would design it this way.

I don't think anyone sat down and decided to over-grant, though. Scoping access narrowly is work — you have to model what the consumer actually approved, carry it through every downstream call, and maintain it. Handing over everything behind the login is simply less to build. Nobody was required to do the harder version, so in places it didn't get done. That's the whole explanation, and it's somehow less comforting than malice.

The level of access your consent grants is negotiated between two companies

Plaid's OAuth documentation says the flow "can provide the ability for end users to configure granular permissions on their Items." Their own example: a user might allow access to a checking account but not the credit card sitting behind the same login.

Can. Not does. Not must.

That one word is carrying an enormous amount of weight, and if you've spent any time around these integrations, you know exactly what it's covering. Granularity is a capability the standard makes available, and the implementing institution decides whether to honor it — how narrow the scope actually is, how long the grant lasts, what happens to the other channels sitting behind the same credential. FDX, the standards body, says the quiet part in its own framing: authorization, revocation and reauthorization are "left to market participants."

So consent looks like a switch to the person clicking it. What it actually reaches is a negotiated position between two companies, and the consumer isn't in the room for that conversation.

§1033 would have put an outer limit on exactly this — no access beyond one year without reauthorization. That died with the rule.

Revocation is the same story from the other end. Turning it off in an app is a request that has to propagate through every downstream system that ever received the data — a well-documented weak point in any architecture where consent is stored centrally but enforced locally. Every system downstream is an independent interpreter of a record it received once. When you revoke, you are trusting a chain you cannot see and nobody audits.

Every institution sets its own terms, and none of them are published

Here is what surprised me most, all pulled straight from Plaid's own engineering documentation:

Sit with that list for a second. If these were security decisions, or cost decisions, they'd converge — these institutions face similar threats and similar economics. They don't converge. Which tells you they aren't engineering positions at all. They're negotiating positions, frozen at whatever moment the last deal was struck.

Expiry is correct. Nobody asks you at renewal.

There's an obvious reply here, and it's a good one. A credential that never lapses is a security defect. Expiry is correct. Any engineer would tell you the same, and so would I.

So the existence of a clock isn't the problem. The real question is what happens when the clock runs out, and who gets asked.

Everywhere else in software, expiry routes back to the person. GitHub makes you re-authorize. Claude makes you re-authorize. You're shown what you're granting, again, in plain language, and you get to decide again. It's mildly annoying, and it is exactly right, because the friction is the feature — it's the moment a human being gets to reconsider.

In this corner of the world, re-authorization is treated as friction to be engineered down. Not as a consumer's opportunity to re-decide. That framing tells you who the system is built for, and it isn't the person whose money it is.

Coverage is partial, and product quality is decided upstream

Let me put the builder's complaint in one place, so you can weigh it and move on.

Aggregators don't reach everyone, and the rule wouldn't have either. There are 8,528 insured depositories in the US — roughly 4,278 banks and 4,250 credit unions as of Q1 2026, down about 47% from around 16,111 in 2008. The common assumption is that the top 50 institutions cover ninety-something percent of people. They don't: the top 50 is roughly 58–61% of consumer deposit accounts, the top 100 gets you to 65–68%, and the curve collapses fast after that. The gaps aren't randomly scattered, either — small credit unions are gated at the core processor layer, so entire classes of institutions drop out at once. And Kansas City Fed research finds community banks are the sole commercial banking presence in about a quarter of US counties. Set that against the rule's exemption for institutions under $850 million in assets: in a quarter of American counties, the only bank available is one the rule never required to build a data interface.

And the things that define your product's quality aren't yours to decide. Uptime, latency, how often a connection silently breaks, how often a customer gets bounced back to re-authenticate — all of it is determined upstream, by institutions you don't have a relationship with. Plaid's /institutions/get_by_id endpoint returns a field called error_institution — "the percentage of logins that are failing due to an issue in the institution's system." It cleanly separates bank-caused failure from aggregator-caused failure. The data exists. It's collected continuously. Nobody publishes it. Plaid's status page covers only Plaid's own systems; Akoya's status subdomain doesn't resolve at all. §1033 would have required banks to publish interface performance monthly, to four decimal places, on a rolling thirteen-month basis; that died with the rule. One company does it voluntarily — Monarch publishes per-institution success and longevity data, broken out by data provider and refreshed daily. A competitor giving away the best public reliability dataset in the industry, because someone there decided it should exist.

But my inconvenience isn't the interesting part, and I'd rather not pretend otherwise. Both of these land on the consumer, just quietly. Whether a person is well served by any of these products depends on where they happen to bank — a thing nobody chooses with data portability in mind. And when a connection breaks, the app looks broken, so they blame the app, churn, leave the review, switch. The institution whose interface actually failed pays nothing, because nobody can see it was them.

This genuinely costs the banks money

I don't want to hand-wave the other side of it.

A large French bank self-reported €21 million to the European Commission. Large US banks self-reported a median of $21 million to the CFPB — a range of $2 to $47 million a year to establish and maintain a developer interface. Two regulators, two continents, the same order of magnitude. That's the closest thing to corroboration the banks' cost claim has, and it's real money for real work.

Regulators also have a documented habit of lowballing this. The UK's CMA estimated £20 million to stand up the Open Banking Implementation Entity; the net cash cost came to £148 million, more than seven times the estimate, in the CMA's own lessons-learned review. The European Commission's contractor study put PSD2 API development at roughly €2.2 billion one-off across 1,125 credit institutions, while describing its own evidence base as "limited," "quite divergent," and "very limited data."

So the objection isn't stupid, and anyone arguing this should all be free isn't arguing seriously.

But there's one more number in that same CFPB submission, and it's the one nobody quotes.

The banks reported that the developer interface costs a median of 2.3% of what they spend on their own consumer-facing interface.

Their app. The one they built for themselves.

Two point three percent. That's the figure at the center of a fourteen-year fight.

It was never really about whether this costs money. It's about who pays, what they get for it, and whether the terms are ones anyone can plan around.

Investments, retirement, and mortgages were never in the rule

Here's the part that reframed all of it for me.

Plaid's Investments product covers roughly 2,400 institutions, against something like 10,000 for checking. About 24% — and that's the vendor's own optimistic self-report.

The entire brokerage universe sits outside FDIC and NCUA, so none of those coverage numbers include Fidelity, Schwab, Vanguard, or any 401k recordkeeper. Brokerage is more concentrated than banking, but access is worse, because brokerages have both the incentive and the means to cut aggregators off whenever they choose.

And §1033 never covered investment accounts at all. Reg E deposits and Reg Z credit cards, full stop. Brokerage, retirement, mortgages, auto loans, student loans — all out of scope, with a phase-in on the rest that ran top-down.

Fourteen years of argument. A rule finalized in October 2024 and sued the same day. The Bureau moving for summary judgment against its own rule. A preliminary injunction in October 2025 — enjoined, not struck down, still sitting there. All of it over checking accounts and credit cards.

Everything you'd actually need to see someone's whole financial picture was never on the table.

Which leaves the discipline voluntary

You can build the app. What you can't do is underwrite a business on an input your counterparty can reprice the moment leverage shifts. That's not a complaint about cost. It's a statement about what's safe to build on.

But the builder's problem is the smaller half of this.

Every unstated boundary in this piece is unstated in the same direction. A person granted access to solve a problem for themselves, and every party downstream (the aggregator, the bank, the app) has some incentive to read that grant as generously as possible. Nobody in the chain is required to be specific about it. And the one person whose data it is has the least ability to find out what they actually gave away.

Including me. That's the uncomfortable part. When a grant comes back broader than what the consumer thought they approved, the party receiving it has very little incentive to bring it up, and I'm the party receiving it. I know exactly how that argument goes in your own head: the data is right there, it would make the product better, and they did click approve. There's a great deal that financial data can tell you, and nearly all of it is monetizable by someone.

Which is precisely why the boundary can't be left to whoever benefits from reading it generously. The rule that would have set an outer limit is enjoined; it isn't coming back quickly, and it wouldn't have covered most of what matters anyway. That leaves the discipline voluntary.

Take what you were given. When you want more, ask.

If code isn't the moat, permission is. And right now, the industry is quietly digging that moat as wide as it possibly can.

Further Reading

This extends an argument I made in Billing Is Not a Standalone App — that durable value sits with whoever owns the data underneath — into regulated territory. And none of it touches the question of who's liable when an agent moves the money, which is the first piece in this series.

Sources

Links to primary sources where they exist.

Data sharing volumes

Consent, scope and revocation

Institution-specific terms

Coverage and cost

The rule and the litigation