英國財政部正徵詢銀行 API 是否應繼續免費：現在就計算成本

Every open banking pitch has a line in it that nobody reads twice: the bank APIs are free.

That's true today. It's also the biggest assumption in most open banking business plans, and HM Treasury has now asked, in writing, whether it should stay true.

What the Treasury actually said

In July, HM Treasury put out a consultation on modernising the Payment Services Regulations. It closed on 6 October. The open banking bits, as I read them:

• A new statutory right of access for VRPs.
• A worry that free access gives banks little reason to invest in their APIs.
• FCA oversight of open banking pricing, with the door open to charging for some kinds of access.
• A future framework where the FCA has a say over standards, participation, pricing, funding and disputes.

It also asks whether the rules on authentication, consent and liability still work when an AI agent is the one initiating the payment.

Two caveats before anyone panics. Nothing is in force, and the legislation isn't expected until 2027 or 2028. And I'm working from public summaries, so read the consultation itself before you quote me.

The newest rail already has a price attached, though. In January the FCA and PSR said they wouldn't prioritise a competition investigation into the central access fee that UKPI is building for commercial VRP. That position runs until legislation arrives or July 2027, whichever is sooner. So "free" is already only half the story.

Why I care

We're a payment initiation provider, so I'm not a neutral observer. Bank API access sits underneath everything we do. If the cost of it moves, we feel it first and our merchants feel it second.

If you build on open banking, the useful question isn't whether banks will charge. It's whether your margin survives if they do.

That takes about ten minutes to answer. This is the script I'd start with:

// Does the product still work if bank API access stops being free?
const monthlyTxns = 20_000;
const yourFeePence = 25;     // what you charge per payment
const otherCostsPence = 6;   // infra, support, fraud ops. Use your real numbers.

for (const accessFeePence of [0, 1, 5, 10]) {
  const marginPence = yourFeePence - otherCostsPence - accessFeePence;
  const monthly = (marginPence * monthlyTxns) / 100;
  console.log(`${accessFeePence}p access fee: ${marginPence}p/txn, £${monthly}/month`);
}

Those numbers are made up. They aren't Atoa's. The only output that matters is the access fee at which your margin hits zero. Know that number before a regulator or a bank tells you theirs.

What I'd do

Find your break-even fee, and work it out per payment, per API call, and per VRP if you do recurring.

Give bank API cost its own line in your pricing model. Burying it in "infra" is how you miss it.

Be wary of pricing as a percentage of the basket. If access charges arrive, I'd guess they're per call or per payment, not per pound. A fee that's trivial on a £4,000 order can wipe out a £4 one.

And if you're building anything agentic, start logging the consent and authentication evidence for each payment now. If liability rules change, that's the record you'll be asked for.

The other side of it

Charging isn't automatically bad. Free access is part of why some bank APIs are patchy, and a paid API with a real SLA might be a better thing to build on. Cards carry fees too, so the honest comparison is all-in cost against interchange and scheme fees, not against zero.

I still think account-to-account stays cheaper than cards. But "cheaper than cards" and "free" are different claims, and only one of them belongs in a business plan.

If you want to see the payment flow end to end, the Atoa sandbox is free: docs.atoa.me

So, what does your margin look like at 5p a payment?