Open Banking Is Moving From Data Access to Payment Authority

Open banking becomes more consequential when permission moves from letting a product see financial data to letting it move money under specific conditions.

Published 2026-06-04 · Updated 2026-06-04

Hand-drawn permission card and recurring payment loop held inside a visible boundary

Why this matters

There is a small but important difference between a product looking at your financial life and a product being allowed to move money through it.

The first version of open banking mostly taught people to think about access. Connect an account. Share transaction history. Let a budgeting app, lender, adviser, or comparison service see enough data to do something useful.

That was already a trust problem.

The next version is sharper because it moves from “let this app look” toward “let this app act”.

That is where commercial variable recurring payments become interesting. They are not exciting because the phrase is elegant. It is not. They matter because they make permission live in time. A person can authorise a product to make recurring bank payments under agreed conditions, rather than treating every payment as a one-off card event or a static direct debit.

That could be useful. It could create cheaper, more flexible, more direct ways to pay.

But it also raises the standard for trust.

Worked example

On 2 June 2026, the FCA said the launch of the UK Payments Initiative was a major step for open banking and commercial variable recurring payments. The statement framed the scheme as a route to more payment choice, more competition, and a stronger long-term framework, with an independent standards-setting body and a regulatory consultation expected by the end of 2026.

That sounds like payments infrastructure. It is also product design.

Because the user question changes as soon as permission can keep acting.

Permission typeThe product questionThe trust risk
Account data accessWhat can this product see?Over-collection, inference, and vague reuse
One-off payment initiationWhat can this product do now?Mistaken action, unclear recipient, weak confirmation
Recurring payment authorityWhat can this product keep doing later?Silent drift, hard revocation, and poor audit trails

A one-off payment can be inspected in the moment. A recurring authority has a longer shadow.

It needs limits. It needs receipts. It needs a way to cancel that does not feel like finding a loose wire behind the wall. It needs to show the difference between a payment that happened, a payment that is scheduled, and a permission that is still sitting there with its hand on the door handle.

The government is already pointing in the same direction. In April 2026, HM Treasury said its payments reform work would include new powers for the FCA over the future of open banking, support for new open banking payments inside commercial schemes, and exploration of how payment regulation should adapt when AI agents conduct payments on behalf of consumers and businesses.

That last point is the clue.

Open banking payments and agentic finance are not the same thing, but they rhyme. Both ask a product to do more than display information. Both move trust from visibility into authority.

That memory should not live only in backend logs, legal language, or support tickets. It should be visible in the product itself.

The person should be able to answer plain questions:

That is not just compliance hygiene. It is the emotional surface of the product.

Where this gets real

The useful metaphor is not handing over the keys. It is lending someone a route.

A route has a start, an end, a purpose, and a boundary. It can be followed more than once, but only while the permission still makes sense. If the destination changes, the route should be reviewed. If the person no longer wants the journey, they should be able to close it without drama.

That is how recurring payment authority should feel.

Not like a hidden tunnel under the product.

More like a marked path the user can inspect.

For wealth-tech, advice, household finance, and personal AI, this matters because payments are where “helpful” starts to become consequential. It is one thing for an assistant to notice that a subscription is expensive. It is another thing for it to cancel, switch, pay, rebalance, or move money in the background.

The better product will not be the one that hides the complexity. It will be the one that makes authority legible without making the user feel they have to become a payments specialist.

That means designing for:

If open banking is becoming a layer of financial action, then the permission layer has to become a product surface in its own right.

Limitations / not a fit

There is a good version of this future.

Direct bank payments could reduce friction, create more competition, lower some merchant costs, and give people alternatives to card-based recurring payments. A better payment rail can be genuinely useful.

The risk is assuming that lower friction automatically means more agency.

Sometimes friction is waste. Sometimes it is a guardrail. Product teams need to know the difference.

The standard should not be “can we make this payment easier?” It should be “can the person understand, limit, review, and stop the authority they have created?”

That is why the open banking story keeps coming back to the same human point. Data access, consent, advice, payments, agents: the technology changes, but the trust question stays stubbornly practical.

Can I see what I have allowed?

Can I change my mind?

Will the product remember the boundary after I have stopped looking at it?

The firms that answer those questions well will make open banking feel less like infrastructure and more like control.

Sources