Open banking after the first wave

Open banking’s most commercially useful UK models are now the ones embedded in a repeated task: moving money, reconciling an invoice, assessing affordability, verifying information or managing several accounts. Basic account aggregation can still support a product, but a connection alone is not value. Product teams should measure whether data or payment access removes a step customers care about and whether they return after the initial consent.

The market has moved beyond experimentation in volume, particularly for payments, but it has not solved every business-model problem. Consent can expire or be abandoned, bank journeys vary, fraud controls add friction and the economics depend on what the provider can charge. London supplies many providers and financial customers, while the underlying infrastructure and usage data are UK-wide.

Usage has scaled, but the measures need careful reading

Open Banking Limited reported 351 million open-banking payments during 2025, up 57 per cent on 2024, alongside 24 billion API calls. Its year-end analysis recorded 16.5 million user connections in December 2025 and weighted availability above 99.50 per cent throughout the year.

Those figures show infrastructure being used at material scale. They do not show 16.5 million unique people: OBL explicitly says its connection measure is counted by bank brand and is not deduplicated across brands. API calls also include technical activity that should not be interpreted as customer value.

The commercial test remains use-case specific. A payment product should track completed payments, repeat payers, failures, refunds, fraud and merchant cost. A data product should track successful connections, useful categorisation, customer decisions and continued permission. Top-line ecosystem growth cannot replace those measures.

Pay by bank works where it removes payment and reconciliation friction

Payment initiation allows a customer to approve a bank payment without a merchant collecting card details or asking the customer to copy account information. The strongest use cases tend to involve high-value or account-based payments, invoice reconciliation, wallet funding, tax or bill payment, where pre-populated references and immediate confirmation can remove manual work.

The route can lower some card-related cost and reduce errors, but the customer still has to recognise the option, trust the provider and authenticate with their bank. Conversion depends on the placement, wording, device hand-off and quality of the return journey. A lower processing price has little value if more customers abandon checkout or support contacts increase.

Provider case studies supply useful hypotheses but require independent checking. OBL’s case-study library includes merchant payments, charitable donations, debt support, lending and small-business administration. It should be read as selected evidence, not a representative performance dataset. Product teams should request denominator data, the observation period and comparison with the previous journey.

Account information earns repeat use through an action

The first open-banking wave made account aggregation familiar: a user could connect accounts and view balances or transactions together. Aggregation becomes durable when the product converts information into an action the customer values. That may be cash-flow forecasting, bookkeeping reconciliation, subscription management, affordability assessment, debt support or a better lending decision.

Each model has a different customer and payer. A consumer budgeting app may rely on subscription or product distribution. An accounting product may charge the business. A lender may pay for enriched data that improves decision-making. A public or charitable service may fund the workflow because it saves staff time or improves support.

Data enrichment is not neutral. Categories can be wrong, joint-account context can be missing and a transaction rarely explains a person’s whole financial position. Decisions that affect credit, price or support need error handling, explainability and a route for correction. The product should expose uncertainty rather than turn a noisy categorisation into false precision.

Recurring payments are promising where mandates need flexibility

Sweeping Variable Recurring Payments allow movement between accounts held by the same customer within agreed parameters. OBL reported strong growth in sweeping VRP during 2025. Broader commercial recurring payments could support bills and subscriptions where amounts or dates vary, combining customer-set limits with account-to-account payment.

The attraction is not simply replacing Direct Debit. A useful recurring-payment model needs a clear mandate, revocation, notifications, exception handling, refunds and protection when something goes wrong. Merchants need reliable reconciliation and confidence that payment will be collected. Customers need to understand who can initiate what amount and when.

The regulatory and commercial framework is still developing. The May 2026 Regulatory Initiatives Grid referred to first live Variable Recurring Payments under an industry-led scheme in the first quarter of 2026. Product plans should therefore distinguish capabilities available today from proposed expansion.

The next framework is intended to outlast the original order

UK open banking began through the Competition and Markets Authority’s order to the largest current-account providers. Long-term governance, funding and expansion beyond that foundation have remained important policy questions.

The Data (Use and Access) Act 2025 created powers for Smart Data schemes and supports a future framework for open banking and open finance. Its explanatory material describes secure, customer-requested data sharing and the potential extension of this model. Detailed rules and implementation still determine what products can actually do.

For strategy teams, open finance is not current open banking with more logos. Savings, investments, mortgages, insurance and pensions have different data, permissions, liabilities and customer risks. A business case should identify the exact data holder, customer right, technical standard and revenue model rather than assume a universal API will arrive.

Product teams should optimise the complete journey

The most useful open-banking metric is usually not connections. It is completion of the customer’s job. Map every step from recognising the option to consent, bank selection, authentication, return, confirmation and any later reconnection or dispute. Compare it with the existing journey on success, time, cost, customer understanding and support demand.

Reliability should be measured at the end-to-end level. High bank API availability does not guarantee that the fintech’s enrichment, identity match, orchestration or merchant integration works. Teams need failure codes they can act on, sensible fallbacks and communication that tells the customer what happened without exposing unnecessary technical detail.

Commercially, the provider must be paid for more than access to a regulated interface. Durable value comes from workflow, risk insight, reconciliation, distribution, support or a specialised customer outcome. Pure connectivity can become a low-margin dependency as standards mature.

Limits of the evidence

OBL data covers reporting participants and uses measures that change over time. Active users, connections, API calls and payments are not interchangeable. Published case studies are selected by ecosystem participants and may omit weak results, implementation cost or customers who abandoned the journey. National data cannot establish London-specific adoption.

Before publication, this article needs independent product testing, current performance data and customer or merchant interviews. Any claim about lower cost, higher conversion or better credit outcomes should be tied to a named method and period. The evidence supports growing use, not a claim that every open-banking model has achieved durable economics.