Series 1 — Diagnosis · Paper 1
SMTP for Money: Why Payments Need an Open Protocol
Every engineer working in infrastructure knows how email works. SMTP — the open standard that underlies all email — lets any mail server exchange messages with any other mail server on the planet. Nobody owns it. Nobody charges you a percentage of the value of each email you send. The rules are public, and anyone who implements them correctly can participate.
Now consider what happens when that same engineer wants to accept a payment.
They can integrate Stripe — fast, well-documented, excellent developer experience, and 2.9% plus 30 cents on every transaction, forever. They can go direct to Visa or Mastercard — technically possible, commercially brutal, and you’ll spend six months in compliance reviews before you process a single pound. Or they can investigate Open Banking, discover that the regulation exists but the coordination layer doesn’t, and go back to Stripe.
The question I kept asking myself, having spent twenty years building open platforms: why does this problem still exist? The internet solved the equivalent problem for communications in the 1980s. We have open standards for email, for the web, for domain names, for virtually every other form of digital exchange. Payments — arguably the most important form of digital exchange — remain stubbornly, expensively proprietary.
The answer, I think, is not technical. It’s that the incumbents who benefit from the current arrangement have had no particular incentive to change it, and until recently the regulatory environment gave them no particular reason to worry.
That’s changing. And the question now is whether we use the opening well.
The toll road nobody questions
Visa and Mastercard are, at their core, messaging networks. They move payment instructions between banks. The actual money moves separately, through settlement systems that largely predate the card networks themselves.
For this messaging service, they charge merchants somewhere between 1.5% and 3% of every transaction. A restaurant doing £500,000 a year in card sales pays somewhere between £7,500 and £15,000 — not for a product, not for credit risk, not for fraud insurance on most transactions, but for the right to use the network. A retailer at £10 million scale pays six figures annually. These are not fees that reflect the cost of the service. They are economic rent extracted from a captive market.
What makes this particularly interesting from an infrastructure perspective is the contrast with how we handle equivalent coordination problems elsewhere. When your email provider needs to deliver a message to a recipient on a different provider, nobody charges 2% of the email’s “value.” The open standard handles the coordination; the cost is the cost of running the infrastructure, not a percentage skim on every exchange.
The card networks succeeded in making this arrangement feel normal. It is not normal. It is a historical accident that persisted because the technical and regulatory environment never produced a credible alternative.
What Open Banking actually did — and didn’t do
PSD2, the European regulation that underpins Open Banking in the UK, did something genuinely significant. It forced banks to open their payment infrastructure to third parties — to expose interfaces through which authorised providers can initiate payments directly from a customer’s account, bypassing card networks entirely.
This is, in principle, exactly what’s needed. Bank-to-bank payment is cheaper, faster (the UK’s Faster Payments system settles in seconds, not days), and doesn’t require a percentage cut to a network that adds no value to the transaction.
In practice, Open Banking produced a thousand point solutions and no coherent market. Every payment provider built their own proprietary layer on top of the bank interfaces. Different rules, different trust models, different ways of handling disputes, no interoperability between them. The regulation opened the rails but left the coordination problem entirely unsolved.
This is exactly analogous to building a new road network but leaving each logistics company to invent its own traffic rules. The infrastructure exists. The shared framework that makes it useful at scale is missing.
What an open protocol changes
The question is not whether bank-to-bank payment is technically possible. It demonstrably is. The question is what it takes to make it work at the scale and reliability that merchants and consumers actually need.
The answer is a scheme — a set of rules that defines how participants interact, how trust is established, how disputes are resolved, and how payments are routed when payer and merchant use different providers. Card networks provide this, which is why they work. The problem is that their scheme is closed and proprietary, which is why it’s expensive.
An open payment scheme would define the same coordination layer — the rules between participants, the infrastructure for verifying identity and trust, the dispute resolution process, the conventions for routing payments across providers — but publish all of it as an open specification. Any organisation that implements it correctly can participate. No single entity controls the network or extracts rent from it.
This is not a new idea. It is, in fact, the idea that underlies every successful large-scale communications infrastructure ever built. What’s novel is applying it to payments with sufficient rigour that it actually works.
The economics follow directly from the design. A merchant on an open payment scheme pays a flat per-transaction fee to their provider — the cost of operating the infrastructure, not a percentage of transaction value. At any significant volume, the difference is substantial. At £1 million annual revenue, the gap between a 2% card rate and a flat 20p transaction fee is potentially £15,000 or more, annually, dropping straight to margin.
More importantly: because the rules are open, the fee is competitive. Providers compete on price and service quality. No provider can raise fees unilaterally, because the merchant can switch to any other compliant provider without changing their integration. This is how every other commodity infrastructure market works.
The governance question
The objection I hear most often is that payments require central control — that someone needs to be in charge to prevent fraud, enforce compliance, and adjudicate disputes. This is true, but it conflates the governance function with the ownership function.
Open email standards have governance. A standards body defines and evolves the rules. Disputes about implementation are resolved through a defined process. Bad actors can be blocked. None of this requires a single private company to own the network and charge percentage fees for its use.
An open payment scheme requires a Scheme Authority — a governance body that sets the rules, manages the infrastructure for verifying participant identity and trust, and arbitrates disputes that can’t be resolved between participants. What it doesn’t require is that this body be a profit-maximising private company extracting rent from every transaction.
The Scheme Authority in an open payment scheme is more analogous to a standards body than to a network operator. It maintains the rules and the shared trust infrastructure; the commercial value accrues to those who operate on top of it, competing on service quality and price. The governance body itself is funded through membership fees paid by licensed participants — a model that keeps it financially sustainable without giving it any stake in the payment flow it oversees.
This is not theoretical
I want to be precise about what exists and what doesn’t, because this space has a long history of well-specified ideas that never got implemented.
The open payment scheme I’m describing is fully implemented as a reference — a working system that demonstrates every protocol interaction end-to-end. Payment initiation across multiple delivery methods. Routing across multiple providers, with trust verified through a shared infrastructure that any participant can check. Dispute resolution from initial filing through to arbitration. Real settlement against Open Banking interfaces.
What the reference implementation proves is that the technical coordination problems are solved. The gaps that remain are in consumer-facing polish and governance tooling — the infrastructure a Scheme Authority would need to operate at scale. These are real gaps; they’re also well-understood engineering problems rather than fundamental design questions.
The hard problem — defining rules that allow any compliant provider to interoperate with any other, with trust, dispute resolution, and scheme governance built in — that problem has a working solution. It just hasn’t been deployed commercially yet.
The analogy holds, and the timing matters
Open email standards didn’t become ubiquitous the day they were defined. It took infrastructure, adoption, and a regulatory environment that didn’t actively protect proprietary alternatives. The technology preceded the market by years.
The position for open payment infrastructure feels similar. The technology exists. The regulatory environment — post-PSD2, with the Payment Systems Regulator actively interested in reducing the dominance of card networks — is more favourable than it has ever been. The commercial case for merchants is straightforward once the cost of switching to a new scheme falls below their annual card fees.
What’s needed now is the thing that always bridges specification and adoption: someone willing to operate the infrastructure, build the commercial relationships, and demonstrate that the scheme works in production at real scale.
The card networks were built by banks, for banks, and the fee model reflects that. An open payment scheme can be built differently — and in a market where a significant fraction of merchant revenue disappears into network fees for no good reason, “differently” is a compelling pitch.
But the more important point is this: the only reason it hasn’t been built already is that everyone who could have built it had too much to lose from it existing. That constraint no longer applies.
Thomas Larsen is a cloud platform architect and engineering leader with twenty years’ experience building open infrastructure for public-sector and defence organisations. He is currently working on an open payment scheme for the UK market.