Positioning
OpenPISP — An Open Payment Scheme for the UK Market
Five-page overview
The open protocol
OpenPISP is an open protocol that defines how Payment Initiation Service Providers interoperate — with merchants, with payers, and with each other. A merchant connects to a PISP. A payer connects to theirs. The two PISPs coordinate to move money directly from the payer’s bank to the merchant’s via Faster Payments and Open Banking. No funds are held. No intermediary sits in the middle.
What has been missing until now is the layer above those rails: a shared framework governing how payment firms interoperate across their respective customer bases. OpenPISP is that framework.
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.
How the protocol works
When a merchant’s PISP receives a payment request, it needs to route it to the payer’s PISP — a firm it may have no prior relationship with. The Scheme Authority maintains a directory of all scheme members and operates the public key infrastructure that allows PISPs to verify each other’s identity and sign their messages. A PISP that is not in the directory, or whose credentials have been revoked, cannot participate. Trust in the network is anchored to the Scheme Authority, not to bilateral agreements between individual PISPs.
The payment flow itself is straightforward. The merchant’s PISP sends a signed payment request to the payer’s PISP. The payer approves it through their PISP’s interface. The payer’s PISP initiates the payment via Open Banking, instructing the payer’s bank to transfer funds to the merchant’s bank via Faster Payments. Settlement is confirmed back through the same chain. End to end, the flow takes seconds.
Disputes follow a defined escalation path. A payer files a dispute with their PISP, which forwards it to the merchant. If the merchant does not resolve it directly, the dispute escalates to PISP-level arbitration. If that fails, the Scheme Authority arbitrates and its decision is binding. The mechanism is asymmetric by design: merchants bear financial penalties for lost escalations; payers bear reputational ones. This reflects the structural difference in accountability between a regulated business and a consumer.
A working reference implementation demonstrates all of this today — PISP coordination, the full dispute escalation path, the Scheme Authority directory and trust infrastructure — tested against a live Open Banking sandbox. It is a demonstrator and a foundation for implementation, not a production deployment.
The commercial model
A PISP earns revenue in three ways.
A flat per-transaction fee charged to the merchant. Unlike card interchange, which scales with transaction value, this is a fixed pence amount — materially cheaper for merchants at any meaningful volume, and straightforward to justify on that basis alone.
A monthly platform fee for API access, reporting, webhook delivery, and portal access. These are the scheme-defined components. PISPs are free to offer additional services to their merchants — sector-specific tooling, reporting, integration support — and price accordingly. The payment transaction is the primary driver; the platform is the commercial relationship.
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. Where the merchant and payer are on the same PISP, the inter-PISP fee does not apply — the PISP retains the full transaction revenue. The cross-PISP fee is a floor, not a ceiling.
The inter-PISP fee creates a viable revenue model for whoever manages payers — a bank, a consumer fintech, or an independent payment firm — without requiring them to also acquire merchants. A payer-facing PISP earns on every transaction its payers make, regardless of which merchant PISP initiated it. That revenue line exists from the first transaction. It does not depend on reaching merchant volume thresholds.
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 risks, named directly
The consent redirect is the critical friction point. Open Banking payments currently require the payer to leave the payment flow, authenticate with their bank, and return. On mobile, that redirect adds steps that a card tap does not have. Abandonment at this stage is the single metric most likely to determine whether the scheme is commercially viable in its early phase. The strategy accounts for this: the first client categories are ones where the payer has a strong reason to complete the flow. But it is a known risk and not a solved one.
Banks have a structural disincentive to promote card bypass on the merchant side. On the payer side, the calculation is different: a bank operating as a payer-heavy PISP earns inter-PISP fees on every transaction its customers make, without needing to acquire a single merchant. The commercial model is designed to make that an attractive position.
The regulatory timeline is fixed. FCA authorisation takes nine to fifteen months for a well-prepared applicant. That timeline cannot be compressed materially. It is a known constraint and the programme is sequenced around it, but it sets a hard boundary on when live payments can begin.
Network bootstrap remains the central execution challenge. The commercial model and the client strategy address it structurally. They do not eliminate it.
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. Housing associations, schools, closed membership organisations, and subscription businesses with known customer bases all fit this pattern. The payer does not need to discover the scheme independently. They encounter it through a relationship they already have.
The second category is sectors where payer demand is strong enough that enrollment friction is not a barrier. These are harder to identify in advance but more powerful when the conditions are right.
In both cases the go-to-market route is through platforms that already aggregate merchants within a sector. Property management software, school payments platforms, membership management systems — each represents a cohort of merchants accessible through a single integration. The platform’s existing distribution becomes the scheme’s distribution. Merchant acquisition at scale does not require individual sales effort; it requires platform partnerships.
This approach also concentrates the scheme’s early transaction volume in sectors where the payment relationship is recurring and the amounts are material. That profile is more valuable for proving commercial viability than dispersed low-value transactions across many unrelated merchants.
The build and regulatory pathway
The Scheme Authority can be constituted immediately. It requires no FCA authorisation. Its formation — as a company limited by guarantee, with a defined membership structure and governance rules — is a legal and organisational task, not a regulatory one. Early formation establishes the governance framework before commercial activity begins and signals to potential PISP partners that the scheme’s neutrality is structural rather than promised.
FCA authorisation as a Payment Institution is required before a PISP can process live payments. PISPs do not hold funds; the regulatory perimeter is correspondingly limited. A well-prepared first-time applicant should expect nine to fifteen months from submission to authorisation. The process is demanding but not opaque.
A second and third PISP are required for the inter-PISP protocol to have commercial meaning. Those organisations should begin their own authorisation processes in parallel, so their timelines converge with the pilot phase. Identifying and supporting those candidates is a near-term priority. The scheme is more credible to platform partners and early merchants if more than one PISP is visible on the horizon.
Protocol development, platform partnerships, commercial conversations, and further paper development can all proceed before the authorisation gate is reached. The programme does not wait for FCA authorisation to make progress.