The OpenPISP Protocol

The OpenPISP protocol defines how independent Payment Initiation Service Providers (PISPs) coordinate to move a payment between bank accounts. It is a coordination layer only — funds always move over existing bank rails (Faster Payments in the UK). The protocol is deliberately narrow: it specifies exactly what is needed for any conforming PISP to interoperate with any other, and nothing more.

The protocol surface

The OpenPISP protocol consists of exactly three things:

Component	Role
psp:// URI format	The wire-level contract. A requester PISP generates a psp:// URI; any conforming payer PISP can resolve and act on it.
Inter-PISP Protocol	PISP ↔ PISP coordination: URI resolution, payment progression, Stage 1 and Stage 2 disputes.
Scheme Authority Protocol	PISP ↔ SA coordination: governance and onboarding, fee-plan registration, settlement-window reporting, Stage 3 dispute escalation, and any future scheme-mediated function.

The Scheme Authority Protocol has endpoints on both sides of the wire — some are implemented by the SA and called by PISPs, others are implemented by PISPs and called (or polled) by the SA. The OpenPISP specification naturally emphasises the PISP side, because the SA is a single scheme-operated implementation rather than a class of conforming implementations. But the protocol as a whole defines both sides.

What this protocol is not

Everything below the PISP boundary is bilateral — a private relationship between a PISP and one of its counterparties — and is out of scope for the OpenPISP protocol:

Boundary	Status	Notes
Requester ↔ PISP	Out of scope	The protocol requires only that a requester PISP can produce a valid psp:// URI. How it does so is a private matter between the requester and its PISP. May become a family of optional reference standards (terminal protocols), but is not OpenPISP.
Payer app ↔ PISP	Out of scope	Tight coupling between a PISP and its branded payer app is expected. This is the PISP's product surface, not a standardisation target.
PISP ↔ Bank	Out of scope	Delegated to Open Banking (OBIE, TrueLayer, or future APIs). A PISP integrates with banks as a private matter.
Bank ↔ Bank	Out of scope	Existing settlement rail (Faster Payments). Not the scheme's to define.

The reference implementation publishes reference patterns for the requester and payer-app boundaries under reference-profiles/. These are documentation of how this implementation does it, not standards that other PISPs must follow.

Three invariants

These principles are load-bearing — they explain why the scope line is drawn where it is, and they should be preserved when extending the protocol in future.

1. The psp:// URI is the wire contract

A requester PISP generates the URI. Any conforming payer PISP can resolve it via the SA directory and act on it. The URI format is the single shared artefact that crosses PISP boundaries; everything else — how the URI got produced, how the payer presented it to their PISP, how either PISP talks to a bank — is internal.

2. Bilateral relationships are out of protocol

The OpenPISP protocol crosses only the boundaries between parties that don't already have a private relationship. PISP ↔ requester, PISP ↔ payer app, and PISP ↔ bank are all bilateral and can be negotiated privately. Standardising them would expand scope without improving interoperability.

3. Payment URI resolution is internal to the requester PISP

A payment URI is an opaque handle. The requester PISP resolves it into a concrete, immutable payment request before presenting it to the payer PISP. Once presented, the payment request cannot change. How the requester PISP manages URIs — single-use or multi-use, fixed or open amount, expiring or persistent, payer-locked or open — is entirely its own business and invisible to the protocol.

This invariant is what keeps the inter-PISP protocol simple: by the time a PAYMENT_REQUEST message is sent, all ambiguity has been resolved on one side of the boundary. The payer PISP and payer always see a single, specific, immutable payment to approve or decline.

4. The SA never sees a transaction, payer, requester, or terminal

The Scheme Authority has exactly three responsibilities:

1. Govern PISPs — onboarding, identity, keys, suspension, exit
2. Redistribute inter-PISP fees — window aggregation, netting
3. Resolve Stage 3 disputes — when bilateral resolution between PISPs fails

It does not route payments, authorise them, see counterparty identities, or hold transactional state. These boundaries are deliberate: they keep the SA thin, keep privacy proportionate, and rule out a class of "let's have the SA do X" extensions that would centralise the network.

Where to read next

Document	What it covers
psp-uri.md	The psp:// URI format — the wire contract
sa-uri.md	The sa:// identity scheme used by the Scheme Authority
inter-pisp-protocol.md	PISP ↔ PISP messages, payment lifecycle, Stage 1/2 disputes
scheme-authority-protocol.md	PISP ↔ SA messages: governance, fees, reporting, Stage 3 escalation
pisp-discovery.md	How PISPs resolve each other via the SA directory
../reference-profiles/	Non-normative reference patterns for the requester and payer-app boundaries

Operational detail — message sequences, retries and timeouts, error catalogues, conformance criteria — lives in the PISP development guide rather than in the protocol spec. The spec defines what must be true on the wire; the development guide defines what a PISP must do to comply.