Open Banking’s Double-Edged Sword: Regulatory Threat or ISO Opportunity?

Open Banking Is Coming — And It Changes Everything About ISO Retention

Open banking is a regulatory mandate that requires financial institutions — including banks — to share consumer and business financial data through standardized, secure APIs. The most advanced version is the UK’s Open Banking Initiative, which forced the UK’s nine largest banks to build and expose APIs. The US version is arriving in waves: CFPB Section 1033, the federal rulemaking that establishes a right to financial data, is working toward implementation, while California, Colorado, and other states have passed their own open banking laws with timelines already in motion.

In payments, the implication is specific and disruptive. When a bank’s account data — including the merchant’s transaction history — must be available via a standardized API, the friction that makes switching processors difficult disappears. A merchant will be able to use a third-party app to move their transaction data to a new processor in one click. The account loader, the data migration workaround, the manual export — all the mechanisms that made switching painful — become irrelevant. An ISO whose retention strategy depends on switching friction faces an existential problem. But an ISO that builds the data layer before the mandate arrives turns the same disruption into a competitive advantage. This article explains what open banking actually requires, what it means for ISO retention, and how the ISO that moves first wins the data layer.

1. What Open Banking Actually Means for Payments

Open banking mandates that banks provide standardized APIs for financial data — and the payments industry is in the first wave: CFPB Section 1033, once implemented, requires banks and financial institutions to make consumer and business financial data available through developer-accessible APIs. In the payments context, this means a merchant’s bank account data, transaction history, and account standing information must be accessible via a standardized API — not just the bank’s own portal, but a third-party API that any authorized provider can use. The goal is consumer choice; the consequence for ISOs is the elimination of the friction that makes switching processors hard.

State-level open banking laws are already in motion — the federal rule is catching up: California, Colorado, and other states have passed open banking laws with specific timelines and requirements. While the federal CFPB 1033 rulemaking works through implementation, the state laws are already creating precedent and forcing banks to build API infrastructure. For ISOs serving merchants in states with active open banking laws, the data portability requirement is not future tense — it is starting to arrive.

2. The Threat: CFPB 1033 and One-Click Processor Switching

When the bank provides the API, switching costs collapse — and the ISO that relied on friction loses its moat: The account loader, the manual transaction export, the migration support — these mechanisms that made switching painful are all workarounds for the absence of a standardized data API. When the bank provides the API, a fintech app can connect to the merchant’s bank account, pull the transaction history, and present a new processor for the merchant to authorize — in one click. The ISO whose retention strategy was built on lock-in rather than value loses the retention tool the moment the API goes live.

The threat is not the switch itself — it is the fintech that uses the data to make the switch easier than a phone call: Open banking does not just make switching technically possible; it enables a new category of fintech aggregators — account switching apps, processor comparison platforms, automated migration services — that use the API data to present switching as a service, not a chore. The merchant who has been vaguely considering a switch will be able to complete it without talking to anyone. An ISO without a data relationship with that merchant will lose them to the cheapest processor on the aggregator’s platform.

3. The Opportunity: ISOs as the Open Banking Hub for Merchants

The ISO that provides the data services merchants need becomes the trusted data partner — not the processor that the merchant might leave: Open banking regulations require that the bank’s API be accessible to any authorized provider. But they do not specify which provider the merchant uses to access and manage that data. The ISO that builds a merchant data platform — one that aggregates the merchant’s bank data, POS data, and transaction history into a single view — becomes the app the merchant uses to manage their financial data. In that role, the ISO is not fighting the open banking mandate; it is delivering what the mandate enables, on its own platform, under its own brand.

The data API strategy converts the open banking threat into a new recurring revenue stream: Once the ISO’s platform is the merchant’s open banking hub — aggregating data from the bank’s API, the ISO’s POS, and the merchant’s other financial accounts — the ISO can offer data analytics, cash flow forecasting, and business intelligence as premium subscription products. This is recurring revenue that is not interchange, not rate-sensitive, and not substitutable by a self-serve aggregator. The data platform is the moat, and the moat is built on value, not friction.

4. Building a Data API Strategy Before the Mandate Arrives

The ISO that builds the data layer before the mandate arrives wins the relationship before the fintechs arrive: Open banking fintechs are already building the aggregator apps that will use the bank APIs to make switching frictionless. The ISO that builds a merchant data platform now — one that merchants already use and trust — will not be displaced by those aggregators. A merchant who already gets their cash flow analytics from the ISO’s platform is not going to use a third-party aggregator for the same data. The ISO that builds the relationship first makes the aggregator irrelevant for retention purposes.

The data API strategy starts with giving merchants what open banking will eventually force banks to provide: Cash flow visibility, transaction analytics, and business intelligence are the data products that merchants actually value — and they are exactly the products the ISO’s POS data enables. The ISO that gives merchants this data first establishes the data relationship before the mandate creates the infrastructure for competitors to offer the same thing. The strategic question is not whether to build a data platform; it is how quickly to build it.

5. The ISO That Moves First Wins the Open Banking Layer

First-mover advantage in the data layer is not about being earliest — it is about being most useful: The ISO that builds the most useful merchant data platform — the one that merchants check first thing in the morning, that gives them the analytics they need to run their business — wins the open banking relationship before the fintechs arrive. The product is not the API infrastructure; it is the merchant experience. The ISO that makes the data platform indispensable becomes the hub, and the hub is the moat.

The open banking mandate is the ISO’s permission structure to build the data business it always should have built: For years, ISOs had a structural reason to avoid giving merchants too much data — data portability enables switching. Open banking eliminates that excuse. The mandate will force data sharing anyway; the ISO that builds the data platform first turns the mandate into an asset. The choice is not whether to be open-banking-ready, but whether to be ready before the mandate forces openness. The ISO that waits is the ISO that loses.