The break-even script cannot print the number it tells you to look for

This week a payments engineer posted a break-even model for bank API pricing, and the instinct is right. HM Treasury is asking whether open banking access stays free. If you build on that rail, the question is not whether banks start charging. It is whether your margin survives if they do.

So he wrote a script. A few lines, ten minutes, everyone can put their own numbers in. The post is worth reading.

The script asks one question: at what access fee does your margin hit zero?

Read it again. It cannot answer that.

const monthlyTxns = 20_000;
const yourFeePence = 25;
const otherCostsPence = 6;

for (const accessFeePence of [0, 1, 5, 10]) {
  const marginPence = yourFeePence - otherCostsPence - accessFeePence;
  console.log(`${accessFeePence}p: ${marginPence}p/txn`);
}

Margin is linear in the access fee, and the array stops at 10. With 25p in and 6p of other costs, every row is positive: 19, 18, 14, 9. There is no zero in that list. The one output the post calls the only one that matters is the one output the code cannot print.

That is not a silly mistake. It is the most common shape a pricing model takes. Someone filled a spreadsheet in once, read an answer off the bottom row, and never asked whether the bottom row was the answer. Scanning a list of guesses is not solving for the variable.

Solve for it, do not scan for it

Break-even access fee is fee minus other costs. 25 − 6 = 19p per payment. One line, exact at any volume.

And volume drops out entirely, which is the good property here: break-even is a ratio, so the 20,000 never enters it. Volume sizes the monthly damage, not the cliff. The invented volume in a model like this is harmless. The invented cost line is not, because that one moves the cliff.

Except volume does come back, in a second place, and that is where models like this usually go wrong.

The denominator

Three things in that script are quoted per payment, and none of them are actually per payment once money moves.

The unit of charge. If access is billed per call rather than per payment, a payment is several calls: create the consent, redirect and return, then poll until it settles. Eight calls at 1p is 8p per payment before you look at the headline rate. Break-even stays 19p. How much of it a "1p" fee eats does not.

The completion rate. Charge per initiation and 70% of them complete, so the cost per completed payment is fee / 0.7. A 5p fee is 7.1p. The cliff moves to 13.3p per initiation, not 19p.

Fixed cost, and this is the half people forget. £2,000 a month of support, monitoring, permissions and safeguarding is 10p per initiation across 20,000. Across 14,000 completions it is 14.3p. Same money, same month, and the difference is larger than the access fees most people are arguing about.

Now run the 5p row through it, access charged per initiation:

line	per completed payment
revenue	25.00p
other costs	6.00p
access, 5p / 0.7	7.14p
fixed, £2,000 / 14,000	14.29p
margin	−2.43p

The post's own output for that row is +14p. Same inputs, opposite sign. The difference is not a fee change. It is which denominator sits under the fixed cost. Charge the access fee per completed payment instead of per initiation and the row is −0.29p: still negative. The direction survives either reading.

The comparison is not zero

One more line the script leaves out: the alternative rail. A UK card on a £25 basket costs roughly 1.5% plus 20p, so 57.5p. Nineteen pence of headroom looks like a bargain next to that, and that is the real argument for account-to-account.

Then shrink the basket. The same card on a £4 payment is about 26p. A per-call access fee does not get cheaper when the basket shrinks. A percentage fee does not notice the basket at all. One rail scales with the amount, one does not, and the crossover sits wherever your average order happens to be.

Four lines under the headline

Every break-even model in this space has the same four lines under the headline number:

1. What you are charged per: payment, call, initiation, VRP.
2. What you divide it by: completion, retries, success.
3. What is fixed, and which denominator carries it.
4. What the alternative costs on your real basket.

Line one is the one everyone argues about in public. Lines two and three decide the sign, and they do not make it into the title.

I will take the correction on my own inputs: the eight-calls figure and the 70% completion rate are assumptions, not measurements from that post or from my own book. The arithmetic downstream of them is exact, and the per-initiation denominator came out of that post's comment thread, not from me.

Which of the four lines have you watched a real pricing model miss? I am collecting the cases.