The Retail Payments Infrastructure Board (RPIB) published its response on the design of the UK's next-generation retail payments infrastructure on 4 November 2026. It sets out prospective design proposals that will be refined through co-creation before the Blueprint is handed to the industry-led Delivery Company in spring 2027.¹
For chief technology officers, heads of payments and enterprise architects, the immediate task is to turn that direction into a controlled planning boundary. Some capabilities are clear enough to shape architecture and procurement now. Message definitions, shared services, settlement detail, liability and migration choices still need room to change.
The response gives PSPs a planning boundary
The RPIB received 121 responses to its consultation. It reports broad support for the payment journeys, design principles and conceptual architecture, alongside open questions about interoperability, shared services, consumer protection and migration.¹
The proposed direction is a single modular architecture supporting existing and future product-level arrangements. Reusable capabilities would sit beneath products, allowing the core to support current journeys and future forms of money without designing a separate foundation for every proposition.¹
This gives payment service providers (PSPs) a useful level of certainty. Teams can plan around modularity, common access and reusable capabilities. They should record detailed technical and commercial choices as assumptions until the Blueprint and later delivery work settle them.
Asima's earlier analysis of payments infrastructure for the next decade covered the durable qualities raised during the consultation. The response now adds a proposed architecture, identifies the decisions still open and sets a spring 2027 review point.
Common messaging and orchestration are usable assumptions
The response proposes a common access foundation with proportionate connection options and shared technical, security and resilience standards. It also proposes a common ISO 20022 messaging baseline across payment services, which product-level arrangements could extend when their journeys need more data. The detailed choice of messages remains part of future design work.¹
PSPs can use that direction without locking themselves to a message set that has yet to be chosen. A practical architecture keeps the enterprise payment model separate from external message mappings. Customer intent, amount, currency, parties, references, state observations and business decisions can remain stable while adapters translate between current services and future ISO 20022 definitions.
The proposed orchestration layer would validate, route and sequence payments across the core, including batches. It may also support a time-limited transition from legacy Faster Payments and Bacs formats while migration is phased. The RPIB says that option needs further consideration within the wider transition strategy.¹
Procurement teams should ask suppliers to separate existing production capability from future compatibility. Current evidence can cover supported messages, validation, routing, batch handling, change control and mapping ownership. Future claims should identify dependencies on the Blueprint, scheme arrangements and migration plan. The Open Banking provider RFP scorecard provides a method for turning those claims into dated evidence and contract commitments.
Settlement direction is clearer while detail remains open
The proposed core would coordinate onward settlement into central bank money through the Bank of England's real-time gross settlement (RTGS) service. The RPIB says most product-level arrangements currently envisaged for the new infrastructure could continue to use prefunded net settlement. It also identifies the possibility of more frequent settlement cycles and more efficient sharing of a participant's liquidity across the product arrangements in which it participates, subject to further design and analysis.¹
These statements narrow the planning range without defining one settlement model for every product. PSPs can model liquidity, acceptance, clearing and settlement evidence by journey. They should keep settlement frequency, prefunding rules and cross-product liquidity assumptions configurable until the relevant product arrangements and core design are settled.
Internal status models also need to preserve the difference between core acceptance, a commitment to seek settlement, completed settlement and the business evidence used for fulfilment or ledger posting. The payment reconciliation control architecture shows how to join payment intent, external status, beneficiary evidence and accounting action without treating one technical signal as the complete financial outcome.
Shared services and customer protection remain open
Consultation respondents identified fraud prevention, data sharing, directories and alias services as candidates for common provision. Views differed on whether those capabilities should sit within the core or elsewhere in the payments system, so their placement remains part of the Blueprint work.¹
The response also separates the core from wider arrangements for consumer protection, liability, merchant acceptance, commercial sustainability and financial inclusion. Those outcomes depend on product-level schemes, standards, providers and public policy as well as the clearing and messaging infrastructure.¹
Enterprise architecture should reflect that boundary. A PSP can define what fraud signal, directory result, alias resolution or customer-protection decision its service needs. The connection point, provider and governance model should remain replaceable while national arrangements develop.
The same discipline applies to open finance. The open finance infrastructure decision guide separates stable capability requirements from unsettled national topology. Retail payments teams can use that approach for identity, permissions, fraud data, directories and evidence without assuming where each shared function will ultimately sit.
Resilience must cover the complete payment journey
The RPIB proposes a core capable of supporting existing payments, account-to-account payments at the point of sale and regulated new forms of digital money as they emerge. It says capacity will need to scale as payment volumes grow.¹
The response also treats resilience as an end-to-end concern. Critical components would need boundaries that sustain minimum service during severe disruption. The proposed operating model includes live performance insight and failover capability, while connecting PSPs retain responsibility for the resilience of the services they operate around the core.¹
That boundary should shape current testing. A core response cannot prove that the customer channel, PSP gateway, fraud decision, reconciliation process and ledger will reach a safe outcome together. Teams need journey-level objectives, dependency maps, controlled failure tests and evidence that the service recovers without losing or duplicating financial actions.
The current system must remain supported while the next generation is designed and built.¹ Existing operational, regulatory and customer commitments continue throughout co-creation, detailed design, procurement and migration.
Record decisions with a spring 2027 review trigger
The co-creation phase runs from November 2026 until spring 2027. The Delivery Company is then expected to take the Blueprint into detailed design, procurement, build and implementation.¹ The handover starts another delivery phase, so programme plans should avoid treating spring 2027 as an operational launch date.
A useful decision record should identify the source and status of every assumption. Mark the modular core, common access foundation, ISO 20022 baseline, orchestration role, RTGS settlement connection and end-to-end resilience as proposed direction. Mark message definitions, shared-service placement, settlement cycles, liquidity arrangements, liability and migration sequencing as open choices.
Give each open choice an owner and a trigger for review. The spring 2027 Blueprint is the main milestone. Earlier RPIB design publications, product-scheme decisions or migration proposals may require a faster reassessment.
This approach lets PSPs make progress with controlled uncertainty. Teams can build stable internal models, define evidence, test supplier claims and improve resilience now. Replaceable mappings and dated assumptions will let the same architecture absorb the Blueprint's detailed choices when they arrive.
Footnotes
- Bank of England and Retail Payments Infrastructure Board, 4 November 2026. Response to the RPIB consultation on the Design of the Future Retail Payments Infrastructure