Design the Bank Before the New UK Payments Rail
The UK is defining the outcomes and design principles for its next retail payments core. Banks should use the consultation window to convert customer journeys, control obligations and migration realities into an evidence-led response - and a disciplined investment plan.
What has changed - and why the consultation matters now
The Retail Payments Infrastructure Board opened its consultation on 25 June 2026 and will accept responses until 11 September. It asks what journeys the future core should support, which design principles should govern it and where the core should sit in the wider ecosystem. The eventual high-level design is intended to be taken forward by a new industry-owned and industry-led Delivery Company.[Bank of England]
This is not yet a technical specification or a settled migration timetable. That is precisely why bank participation matters. Choices about what belongs in the common core, what remains in schemes and products, and how transition is staged will influence future unit economics, customer propositions, control ownership and operational risk. The best response will therefore look less like a policy comment letter and more like a concise business architecture backed by evidence.
The policy direction is already clear. The Payments Vision Delivery Committee has set five outcomes: greater choice, interoperability across forms of money, protection from fraud and financial crime, fair access, and operational and financial resilience. HM Treasury describes the strategy as the guide for the next generation of UK retail payments infrastructure.[HM Treasury]
Start with journeys, not system features
The consultation retains essential journeys such as immediate, batch, scheduled and cross-border payments while proposing account-to-account payments at physical and online points of sale, alias-based payments, delegated payments, programmability, deferred payments and interoperability across forms of digital money.[Bank of England]
A bank should rank these journeys through four lenses: customer value, economic value, control complexity and dependency on shared infrastructure. A2A at point of sale may support merchant choice, but its viability depends on acceptance, dispute handling, confirmation, refunds, fraud allocation and a commercial model. Alias payments reduce input friction, yet require directory governance, consent, lifecycle controls and reliable resolution. Delegated payments need explicit mandates, limits, revocation and customer-visible accountability.
Each priority journey should be documented as an end-to-end service blueprint. Record the initiating party, authentication method, messages, decision points, funds state, confirmation, exception routes, dispute path and data retained as evidence. This exposes which capabilities genuinely need common infrastructure and which can remain competitive bank services. It also stops attractive front-end concepts from concealing unresolved liability or service-continuity questions.
Answer the core-versus-edge question explicitly
The consultation focuses on central clearing and messaging while recognising that schemes, access, settlement, regulation, standards and user-facing products must evolve around it. It proposes modularity, extensibility, open access, common utilities and standards, security, resilience, performance, scalability and protection from fraud.[Bank of England]
Banks should test every proposed common utility against a simple rule: centralise only where shared provision creates a material network benefit, stronger system control or lower duplication than federated delivery. An alias directory may meet that test because reach and consistent resolution matter. Shared fraud signals may also create value, provided data permissions, contribution duties, model governance and redress are clear. Product pricing, customer experience and risk appetite generally belong closer to the competitive edge.
For every capability, the response should name the accountable layer, the minimum service level, the data controller or steward, access conditions, change authority and failure fallback. This makes trade-offs visible. A large core can simplify participation but concentrate change and operational risk. A narrow core preserves flexibility but can leave essential coordination to fragmented bilateral arrangements. Neither choice is automatically superior; the evidence should follow the journey.
Make bank economics part of infrastructure design
A new rail does not create adoption by itself. Banks need a transparent value model covering build cost, parallel-run cost, scheme and infrastructure charges, fraud losses, disputes, liquidity, operational support and revenue displacement. The Bank of England's launch announcement says the future infrastructure is expected to support choices such as A2A at point of sale and enhanced cross-border payments, while existing Pay.UK systems continue to operate during development.[Bank of England]
Model three adoption cases rather than one forecast: a utility case in which the bank mainly meets participation obligations; a targeted-growth case focused on selected merchant or business segments; and a scaled-substitution case where A2A gains meaningful share from other methods. For each, calculate cost per successful payment, cost per exception, incremental fraud and dispute expense, customer acquisition or retention value, and the time required to recover fixed investment.
Funding design matters too. Shared infrastructure needs a sustainable model that does not lock smaller participants out or reward volume without regard to risk. Banks should ask how fixed and variable charges, onboarding costs, common-service usage and future upgrades will be allocated. A response that identifies distributional effects and proposes measurable access safeguards will be more useful than a generic call for competition.
Treat fraud, disputes and identity as one control system
The RPIB identifies verified payee credentials, strong authentication, fraud prevention, shared data and time-bounded digital dispute resolution as possible ecosystem enablers.[Bank of England] These elements must be designed together. Faster confirmation is not the same as safer payment, and richer data has limited value if decision rights and redress remain unclear.
A bank response should describe a common transaction evidence package: payer authority, payee credential status, authentication context, alias resolution, risk signals used, decision outcome, confirmation timestamps, exceptions and any post-transaction changes. The package must be retrievable across operations, complaints, fraud investigation and assurance. Controls should specify when a payment is paused, rejected, recalled or escalated, and how customers are informed.
For delegated or programmable payments, mandates should be machine-readable and human-comprehensible. Scope, amount, frequency, expiry, merchant or purpose restrictions, override rights and revocation must be explicit. A bank should also define the degraded mode: what happens when a directory, risk utility, external provider or connectivity path is unavailable. Resilience is a customer outcome, not only a platform uptime measure.
Build migration evidence before dates are fixed
The consultation says migration may be staged and could include a defined, time-limited period of dual running, while detailed transition planning will follow later. It also stresses orderly migration and coordination among operators, schemes and participants.[Bank of England] Banks should use this early stage to measure their estate, not wait for final milestones.
Create a payment dependency register covering channels, payment engines, customer files and APIs, sanctions and fraud controls, ledgers, reconciliation, liquidity, notifications, archives, vendors and downstream reporting. For every dependency, record the current message or file format, peak load, recovery objective, test environment, data owner, contract constraint and feasible cutover pattern. This converts migration debate into quantified exposure.
Dual running should have entry and exit criteria. Entry requires reconciliation at transaction and value level, matched control outcomes, operational capacity and a tested rollback. Exit requires stable exception rates, proven customer servicing, closed material defects and independent sign-off. Without those gates, parallel operation can become an expensive permanent state rather than a risk-reduction tool.
Put governance around decisions that are still reversible
A consultation response is most valuable when it records the bank's assumptions and identifies which choices remain open. Establish a decision register for scope, access, settlement dependencies, common utilities, liability, data use, service levels, migration and funding. Each entry should show the current position, evidence, owner, external dependency, review trigger and the cost of changing course later.
Use a small executive forum to resolve cross-functional trade-offs. Payments product may favour rapid feature reach, technology may prefer a narrow stable core, fraud teams may seek shared signals, and finance may focus on investment recovery. The forum should decide against the agreed journeys and outcomes, rather than allowing any single function's metric to dominate. Decisions with material customer, prudential or conduct consequences should receive independent risk review.
Vendor and partner strategy also needs an early boundary. Identify which capabilities are strategic bank competencies, which can use interchangeable components and which may rely on shared market utilities. For external components, require portability of data, test access, incident evidence, version discipline, recovery commitments and a credible exit path. A modular architecture delivers little benefit if contracts or proprietary data make modules impossible to replace.
The board does not need to approve every design detail. It should approve appetite and investment logic: the priority journeys, maximum parallel-run exposure, critical service outcomes, conditions for using shared utilities, material outsourcing boundaries and capital gates. Management reporting should show benefit readiness alongside delivery readiness. A technically connected bank has not achieved the outcome if customers cannot use the journey safely, operations cannot resolve exceptions or the economics remain structurally negative.
Finally, treat the consultation as the first cycle of a continuing capability. Maintain the journey blueprints, dependency register, economic model and control evidence after submission. Update them when the blueprint, scheme responsibilities, funding approach or migration plan changes. This avoids rebuilding the case from presentation slides at each programme stage and gives internal audit, risk and executives a durable line of sight from public-policy outcome to bank implementation.
A 90-day management agenda
Days 1-30: appoint one accountable executive; select five to eight priority journeys; map the core-versus-edge position; inventory material dependencies; and capture baseline volumes, costs, losses, exceptions and service levels. Agree which claims in the consultation response require quantitative support.
Days 31-60: run cross-functional design sessions with product, payments, operations, fraud, technology, treasury, legal, compliance and finance. Produce service blueprints, control narratives, economic scenarios and migration constraints. Test proposals with merchant, consumer and corporate-banking teams so that the response represents end users as well as infrastructure specialists.
Days 61-90: approve the response through a bank-level forum, identify no-regret investments and place uncertain spend behind gates. No-regret work may include data lineage, dependency mapping, API discipline, transaction evidence and test automation. Architecture commitments that depend on unresolved scheme, liability or funding decisions should remain conditional. The output should be a consultation response, a decision register and an investment roadmap sharing the same evidence base.
FAQ: UK retail payments infrastructure
Q1. Is the consultation a final technical design? No. It seeks views on journeys, principles and the core's ecosystem role. Detailed delivery and migration decisions will follow.
Q2. What should a bank submit before 11 September 2026? A prioritised, evidence-backed position on journeys, capability placement, access, controls, economics and migration considerations.
Q3. Which proposed journey deserves early attention? A2A at point of sale is strategically important, but banks should assess it alongside alias resolution, dispute handling, fraud allocation and merchant acceptance.
Q4. What is a no-regret investment? Work that improves multiple future designs, such as dependency mapping, clean payment data lineage, reusable APIs, control telemetry and automated reconciliation.
Q5. How should success be measured? Use customer completion, acceptance, fraud and loss, dispute resolution, exception cost, availability, recovery, access and unit-economics measures - not migration completion alone.
Conclusion
The consultation is an opportunity to shape the UK's next retail payments foundation before technical choices harden. Banks should respond with operational evidence and explicit trade-offs: which journeys matter, which utilities belong in common, how customers are protected, how the economics work and how migration risk will be controlled. That discipline also creates an internal advantage. A bank that can connect policy outcomes to service blueprints, control evidence and investment gates will be ready to move when the blueprint becomes a programme.