Positioning
OpenPISP — An Open Payment Scheme for the UK Market
Three-page summary
The open protocol
The rails for direct bank-to-bank payments already exist. Faster Payments moves money between UK bank accounts in seconds. Open Banking gives licensed payment firms the regulatory permission to initiate those payments. What remains is the layer above: a shared framework governing how payment firms interoperate across their respective customer bases. OpenPISP is that framework.
A merchant connects to a Payment Initiation Service Provider. A payer connects to theirs. The two PISPs coordinate over an open, published protocol to move money directly from the payer’s bank to the merchant’s. No funds are held. No intermediary sits in the middle. The protocol defines how any two PISPs communicate — which means any merchant and any payer, on any compliant PISP, can transact with each other.
That last point is what changes the dynamics. Every new PISP that joins expands the network for every existing one. A new entrant brings new merchants and new payers into a scheme where they can immediately reach everyone already on it. The network’s value accrues to its participants, not to whoever runs it.
The protocol is governed by the Scheme Authority — a non-commercial body whose funding comes from membership fees, not transaction volume. It has no stake in who wins commercially. That neutrality is not incidental. It is the thing that makes genuine openness possible — and the thing that previous attempts did not have.
The commercial model
A PISP operating on the scheme earns revenue in three ways. A flat per-transaction fee charged to the merchant, calibrated to be materially below card interchange at any meaningful volume. A monthly platform fee for API connectivity, reporting, and portal access. And an inter-PISP service fee: when a payment crosses the boundary between a merchant’s PISP and a payer’s PISP, the payer-side PISP earns a fee on that transaction.
The third component is structurally important. It creates a viable revenue model for whoever manages payers — independently of merchant volume. A bank, a consumer fintech, or an independent payment firm can build a payer-facing business with a clear revenue line without waiting for merchant adoption to reach scale. The scheme does not depend on banks moving first. It creates conditions in which moving first is commercially attractive.
The Scheme Authority is funded by annual PISP membership fees. Its financial model is independent of transaction volume, which preserves its structural neutrality.
The founding team intends to operate a PISP under the scheme, competing on the same terms as any other participant.
The first client strategy
The enrollment challenge on both sides of a two-sided network is real. The strategy targets contexts where it largely solves itself.
The more reliable category is merchants who already have a defined payer relationship. When the merchant adopts the scheme, their payers follow — enrollment is a consequence of the commercial relationship, not a separate challenge.
The second category is sectors where payer demand is strong enough that enrollment friction is not a barrier.
In both cases the go-to-market route is through platforms that already aggregate merchants within a sector. A single platform integration brings a cohort of merchants rather than requiring individual acquisition, and the platform’s existing distribution becomes the scheme’s distribution.
Next steps
A working reference implementation demonstrates the protocol end-to-end today — PISP coordination, dispute resolution through all escalation stages, a Scheme Authority service, merchant and payer portals — tested against a live Open Banking sandbox. It is a demonstrator of protocol behaviour and a foundation for PISP implementation, not a production deployment. The protocol is proven. The build path is defined.
FCA authorisation as a Payment Institution under the Payment Services Regulations 2017 is required before live payments can be processed. PISPs do not hold funds; the regulatory perimeter is correspondingly limited. The authorisation process is a known programme step with a known timeline.
The Scheme Authority can be constituted and the protocol developed in parallel with that process. A second and third PISP — necessary for the inter-PISP protocol to have commercial meaning — should begin their own authorisation processes early, so their timelines converge with the pilot phase rather than following it. Commercial conversations, platform partnerships, and further protocol development can all proceed before the authorisation gate is reached.