The RPIB has designs on your future: act now or pay later!

A striking lack of dates

The consultation includes a Figure 3, which purports to be an "indicative roadmap" of four phases for the core infrastructure; this consultation being a core element of "phase 1 – conceptual architecture and design principles". However, the following phases set out in the paper tell us very little – once the consultation responses have been analysed, there will be further design development, and then a high-level design handover to the Delivery Company (phase 2), followed by a phase 3 of a "detailed design and build" (plus testing), concluding with a phase 4 of a migration (from the retail payment schemes, interestingly including cheques, operated by Pay.UK today) and run -  which will presumably overlap. There are, however, absolutely no dates offered.

This may reflect a key lesson learned from the 2017 Payments Strategy Forum documents on the NPA. It is quite odd, re-reading those papers, to see the things that were meant to have been delivered in 2021-2023, for example. Be that as it may, we are not sure how this roadmap could help firms (including Delivery Company) think about committing resources in a meaningful way at this point. This has been something of a recurring theme on the NPV and the PFP, but we hope that we are getting closer to where the sector needs to be. 

Core payment journeys  

Sensibly, the RPIB has adopted, as its starting point, an approach looking first at the end-user "payment journeys" that the core needs to be able to support. These are divided in Section 2 of the paper into existing and new/emerging payment journeys:

• Single immediate payments (existing)
  
  
• Batch payments (existing)
  
  
• Recurring or scheduled payments (existing)
  
  
• Cross-border payments (existing)
  
  
• Account to account (A2A) payments at point of sale (new and emerging)
  
  
• Interoperable payments (i.e. payments across different forms of money, including regulated stablecoins, tokenised deposits and a digital pound) (new and emerging)
  
  
• Instant payments to aliases (described as "new and emerging" in the consultation, although we would note that routing payments via mobile phone numbers was the functionality offered by both Pingit and PayM, among others, in the past)
  
  
• Programmable payments (new and emerging)
  
  
• Advanced delegated payments (this could include agentic AI) (new and emerging)
  
  
• Deferred payments (i.e. those authorised offline that are actually made later once connectivity is restored) (new and emerging).

The consultation makes the point that this list is inherently not exhaustive or future-proof, and perhaps the first question that respondents should consider is whether this is the correct set of journeys, described at the right level? For example, any one of "cross-border payments", "interoperable payments", and "programmable payments" could cover a wide range of individual, differentiated circumstances and use cases.

In addition, distinguishing in this way between "advanced delegated payments" and "programmable payments" might be seen as focusing excessively on the technology, which brings the spotlight to "Alice". 

Alice is a character used in the consultation paper to demonstrate a small set of payment journey examples. Two of these cover programmability (preset parameters allow for the greater automation of and flexibility in payments in Alice's business) and agentic commerce (an AI agent is used to buy something online following preset instructions).  

Our immediate reaction to these two examples of Alice's payment needs is that this could be confusing different technology with different journeys – it seems possible to us that the technology in each scenario could, in principle, have been switched. Perhaps then the focus should in fact be on the use of programmability and AI agents to achieve greater automation and flexibility, rather than seeing them as conceptually distinct payment journeys.

Having set out its view of the payment journeys that the core needs to support (as a minimum), the RPIB turns in Section 3 of the paper to its six key "design principles" that the core infrastructure should meet:

• To be a platform for innovation and competition
• Be designed to facilitate open access
• Embed or support common utilities and common standards for direct participants and, where appropriate, the wider ecosystem (although, as we have noted above, the actual role that is possible, and appropriate, for the operator of the core layer to set standards for non-direct participants and beyond its scheme rules is a matter on which respondents may have strong views)
• Meet high standards of security and resilience
• Support high standards of performance and scalability
• Be designed to enable and support a greater level of protection from fraud and wider financial crime.

In broad terms, we see the force behind espousing these principles, although several of them (innovation and competition, security and resilience, performance and scalability, for example) instantly prompt the question: "How is this to be funded?". Many of these principles will require complex and expensive tech build and, at this stage, the RPIB has quietly deferred consideration of that for a future step in the process. We can understand that the scope of this consultation has been drawn so as to exclude issues and considerations of cost, but it is a fundamental point that must be resolved at the earliest opportunity (whether by the Design Authority, as a sub-committee of the RPIB, and/or the Delivery Company itself).  

This is the term given in Section 4 of the consultation paper to a high-level description of the different 'layers' of the payments ecosystem, covering:

• End-user layer (payers and payees)
• Access layer (channels)
• Product layer (payment journeys)
• Core infrastructure clearing and messaging layer (the principal subject of the consultation)
• Settlement infrastructure layer (i.e. RTGS, whether on a gross or deferred net settlement basis)
• Services layer (essentially, overlays)
• Scheme and standards layer (scheme rules or other common technical, operational or service standards adopted outside of the core layer's rulebook).

It is this where the echoes of the July 2017 Payment Strategy Forum document are heard most closely – that document included a "conceptual model" that is strikingly similar to this "conceptual architecture".

The consultation paper does cover, as we have said, interoperability with stablecoins and tokenised deposits (as well as dutifully repeating that no decision has been made on a central bank digital currency, but that if one was introduced, it would require interoperability too) - as well as open banking and agentic AI. However, we feel compelled to question  whether the 2017 conceptual model is still (implicitly) the best starting point for this new framework, given all that has happened since, especially on digital payments after the pandemic.

The other point surfaced by the discussion of the conceptual model is the ultimate need to tie together, and co-ordinate, the layers and the various, multiple organisations participating in the wider payment ecosystem. Although the consultation is expressed to focus on the core layer, there is a very brief recognition of the importance of settlement, and that there will need to be discussions about whether existing settlement models (e.g. the deferred net settlement in current schemes) remain appropriate in the design of the future retail payments infrastructure.

As noted above, the deadline for responses is 11 September 2026. It is also abundantly clear to us that the RPIB is open to almost any relevant feedback – a theme running through the actual consultation questions amounts to "what might we have missed?".

Non-bank PSPs, in particular, should give serious thought to their use of, and relationship, with the key retail payment infrastructures, look to international comparisons (especially for A2A) and make sure their voices are heard as this design phase proceeds.

The Travers Smith team has supported financial market infrastructures, including systemically important payment system operators (PSOs), for decades from design, through implementation to operation. The fundamental  role of PSOs in the wider payment ecosystem makes them unique, and very distinct from an end-user-facing firm. Alice's journey through this particular looking glass, in that sense, has barely begun.