winecapanimated1250x200 optimize

What JPMorgan Charging for Customer Data Access Really Changes

Teams reviewing bank API usage, contracts, and cost models for customer data access
When data access becomes priced, the operational work shifts to contracts, metering, and feature trade-offs.
Reading Time:
5
 minutes
Published February 4, 2026 8:24 AM PST

Explainer

Banks and fintech middlemen have spent years operating on an assumption: if a customer connects an app to a bank account, the data flow is just part of doing business.

JPMorgan’s new contracts flip that assumption into a priced service, with fintech intermediaries paying the bank for the data requests that power popular financial apps.

Attention is focused now because the “free access” expectation was tied to a regulatory direction of travel in 2024—and that direction has been thrown into uncertainty by litigation and an attempted rollback. In practice, this is what organisations feel first: budgeting shifts, contract renegotiations, and product teams discovering that “connected account” features now come with a metered cost.

What is actually being charged for, and who pays it

When people hear “charging for customer data,” they often imagine a bank selling personal information. That is not what this dispute is about. The fight is about the operational cost of data pulls—the automated requests that third-party services send into bank systems to retrieve balances, transactions, and account details after a customer authorises a connection.

The immediate payer in JPMorgan’s announced deals is the fintech “middleman” layer (firms such as Plaid, Yodlee, Morningstar and Akoya, as described in the CNBC report). Those intermediaries typically sit between the bank and the end app, managing authentication, connections, and high-volume request traffic.

A question readers keep asking in practice is: “If I gave consent, why does money change hands at all?” Because consent answers permission, not price. Organisations still decide how an authorised connection is delivered, supported, monitored for fraud, and scaled—and who carries the cost of that infrastructure.

What happens next, step by step, after a bank decides to charge

A pricing shift like this does not land as a single announcement inside companies. It turns into a chain of operational handoffs that can take weeks or months to settle, even when customer-facing features remain unchanged.

First, the bank and the data intermediary move from a “connection” relationship to a “commercial service” relationship. That usually means new terms, pricing schedules, service-level expectations, and dispute clauses, even if the underlying APIs and authentication are unchanged.

Next comes usage definition: what counts as a billable request, what is bundled, and what is excluded. This is where time gets burned, because the billing unit has to match the technical reality—requests can be triggered by background refreshes, fraud monitoring, login retries, and user activity spikes, not just a customer tapping “refresh.”

Then the intermediary has to map those costs to its own clients. Some apps will be on bespoke enterprise contracts; smaller apps may be on standard pricing. The intermediary must decide whether to pass through fees directly, absorb them, or restructure pricing tiers—each option creates different internal approvals and customer negotiations.

After that, risk and reliability terms get renegotiated. If a bank is charging, it often pushes harder on how requests are serviced, throttled, queued, or limited under peak demand. That can force engineering changes, because “same data, same permission” does not guarantee “same speed, same frequency.”

Finally, finance teams model the new cost base and product teams reassess which features can be offered at what margin. The practical timeframe here is not the moment the contract is signed; it is the first full billing cycle where real volumes translate into real costs and someone has to explain the variance.

A second common reader question is: “Will my app stop working?” Usually not immediately. The more realistic change is that some features become less generous—fewer automatic refreshes, slower syncing, more prompts to reconnect, or premium tiers where “real-time” becomes a paid benefit.

A concrete example of how a company gets surprised

Imagine a UK-based expense management platform that serves 8,000 SMEs and relies on a U.S. data aggregator to support American corporate cards and employee reimbursements. Its unit economics assume that connected-bank data is a fixed platform cost, because that has been the industry norm for years.

A regulatory shift and a court-driven pause in the “no fee” expectation changes that overnight. The aggregator informs the platform that new bank-level fees will apply from the next quarter, but the billing will be based on request volume—not on customers or accounts.

The platform’s first surprise is that request volume is not driven mainly by active users. Background syncing and reconciliation features create a steady baseline of calls even when customers are asleep, and finance teams discover they cannot “turn down” the cost without altering core product behaviour.

The second surprise is internal: nobody owns the problem end-to-end. Engineering can reduce calls, finance wants predictable costs, sales has already sold “real-time sync” as a promise, and customer support starts seeing tickets when refresh frequency changes. The outcome is not a dramatic shutdown; it is a quarter of friction where the company learns that “authorised data access” still has a cost structure—and that cost structure can move.

Where the friction and delay usually happens

The first bottleneck is measurement. Companies discover that they do not have clean visibility into what triggers data pulls, how often they occur, and which product behaviours generate the most volume. Until that instrumentation exists, budgeting discussions become guesswork and negotiations become emotional rather than precise.

The second bottleneck is responsibility. When costs sit with an intermediary but are driven by end-app behaviour and end-user expectations, accountability fragments. Legal reviews the contract, engineering owns the traffic, product owns the promise, finance owns the forecast—and no single team can change the outcome alone.

The third friction point is timing. Contracts can be signed while regulatory posture remains unsettled, which means companies may lock into terms before the wider framework stabilises. That uncertainty is not abstract: it shows up as shorter contract durations, review clauses, and contingency language that keeps internal planning provisional.

When people say “regulatory uncertainty,” the useful version is: uncertainty sits at the rule baseline (whether fees are prohibited, permitted, or constrained), it is caused by litigation and policy revision, and it does not change the fact that companies still need working connections and commercially viable contracts right now.

Expectation vs reality for leaders and teams

What leaders often assume is that “open banking” means data access is guaranteed, standardised, and effectively free once a customer consents. They expect the system to behave like an on-ramp: connect once, and it just runs.

The reality is that data access is an ecosystem bargain, not a permanent entitlement. Even when permission is clear, delivery still depends on commercial terms, operational capacity, fraud pressure, and how regulators and courts define the baseline.

A third question that keeps showing up in boardrooms is: “Is this just banks trying to kill fintech?” Sometimes it is framed that way publicly, but operationally the issue is narrower and more measurable: who pays for infrastructure, security, and rising traffic—and how those costs affect competition. Organisations should expect negotiation, metering, and service terms to matter as much as the headline “fee” itself.

Governance and oversight context

Accountability in this area usually sits across three layers. Banks control the systems and can set commercial terms unless constrained by rule or enforcement. Intermediaries control the connection rails and can shape how costs and service limits hit the market. Regulators and courts can define whether certain fee structures are permitted, prohibited, or subject to conditions—but that often happens on timelines that do not match product cycles.

The limits matter. Even with clear regulation, discretion remains in how firms interpret technical definitions, how contracts are written, and how disputes are resolved. Even with aggressive legal arguments, outcomes can hinge on classification and procedural stage rather than broad claims about “consumer control.”

What remains unresolved, and why that pressure persists

The open question is not whether customers will keep connecting accounts—they will. The open question is how the cost and control of those connections gets allocated when the regulatory baseline is contested and large incumbents can move first.

If more banks follow JPMorgan’s model, the pressure point becomes whether smaller fintechs can afford the same quality of access as larger players, and whether consumers experience that as higher prices, fewer features, or slower innovation. If rulemaking reasserts a stronger prohibition on fees, the pressure shifts to how banks recover infrastructure costs and how fraud exposure is managed without pricing leverage.

Either way, the lesson for organisations is uncomfortable but practical: awareness of the system does not produce resolution. It just tells you where the next negotiation, delay, and discretion point is likely to land.

Share this article

Lawyer Monthly Ad
generic banners explore the internet 1500x300
Follow CEO Today
Just for you
    By Andrew PalmerFebruary 4, 2026

    About CEO Today

    CEO Today Online and CEO Today magazine are dedicated to providing CEOs and C-level executives with the latest corporate developments, business news and technological innovations.

    Follow CEO Today