Liquidity, prefunding and access

Why message speed is not enough

An instruction may reach a payment system in a fraction of a second yet wait for the participant to fund its obligation. From the payee's perspective the service is not fast. Liquidity here is the ability to meet an obligation at the required time, not accounting profitability or the value of long-term assets. A bank can own sound assets and still face a short intraday squeeze if it cannot turn them into eligible settlement funds in time. Strategy must separate message-processing capacity from funding capacity. The first determines how many instructions a system can receive and route. The second determines how much value it can settle safely. Increasing one without the other can build a queue and increase exposure instead of improving service.

Prefunding places cash or acceptable collateral ahead of incoming instructions according to system rules. It reduces the risk of promising settlement without resources, but ties up funds that could be used elsewhere. The right level is not a magic percentage of annual sales. Begin with peak intraday obligations, the timing and reliability of inflows and outflows, contractual limits, and a scenario in which one funding source fails. If inflows arrive two hours after outflows, an attractive end-of-day net position can conceal a real peak-hour bottleneck. Plot the position at intervals during normal and stressed days before setting a funding amount.

Three operating patterns and when their ranking changes

Real-time gross settlement handles obligations one by one when funding conditions are met. It can shorten exposure to unsettled obligations but demand more liquidity if many outgoing instructions arrive before incoming ones. Deferred net settlement offsets obligations and settles the net at a specified time. It may economize on liquidity, but creates a waiting period and risks governed by the system's guarantees and failure procedures. Systems can also use queues, frequent net cycles, or guaranteed limits. Calling a design "instant" or "net" is insufficient. Obtain its actual ordering, finality, funding, and exception rules.

Suppose a participant has 20 outgoing instructions worth 1 million each and 18 million of incoming instructions during the day. The final net obligation is 2 million. If all outflows arrive in the morning and inflows in the evening, the participant may need nearly 20 million in morning settlement funds to process all outflows immediately in a gross system without credit or liquidity-saving features. In a deferred net system the assumed net may require less funding, but the provider must explain the payee's position before settlement and the actual point of finality. Earlier inflows or a queue that changes processing order would change the liquidity need. This is a design comparison, not a claim about the requirement of a particular live system.

Who should gain access to the network?

Direct access lets an institution participate under the infrastructure's rules and bear its obligations directly. Indirect access operates through a sponsoring participant that provides some settlement and connectivity functions. Direct access can give more control over state timing, data, and marginal cost at scale. It also demands operational capability, liquidity, risk management, and possibly approvals under local rules. Indirect access can accelerate launch and bundle operating services, yet create dependency on a single sponsor and poorer visibility into exceptions. Do not assume a firm is eligible for either route. Check the specific infrastructure and competent local authority before an implementation decision. The lesson compares conditional strategic alternatives; it does not offer licensing advice for any country.

Imagine a payments company handling 50,000 transactions per day with a contribution margin of 0.12 units per transaction before connectivity cost. Its sponsor charges an additional 0.04 per transaction. Direct connectivity would hypothetically cost 1.2 million units each year in operations and oversight plus 0.01 per transaction. At 18.25 million annual transactions, sponsor cost is 730,000 units. Direct cost is 1.2 million plus 182,500, or 1.3825 million. Under these assumptions direct access does not save money, although it could improve control. If fees and fixed cost remain stable, volume break-even is 1.2 million divided by (0.04 minus 0.01), or 40 million transactions annually, about 109,600 per day. Liquidity cost, switching cost, control value, and sponsor outage risk are excluded. The arithmetic is a first screen, not a final decision.

When a queue becomes an allocation decision

A queue is more than a technical delay. If liquidity cannot cover all instructions, the rule that chooses the next one decides who receives service first. Arrival order sounds neutral, yet a large instruction at the front can block a small urgent one if it cannot be funded. Always favoring small instructions can delay a critical large obligation. Classify instructions by stated commitment, cut-off time, and customer limits, not merely by the merchant's value to the provider. If the system permits resequencing, document each participant's authority to do so and the effect on accepted instructions. Test the design with a stressed sequence: when each instruction arrived, when funding became available, which rule selected one instruction over another, and how long each payee waited. An average queue time that omits cancelled or retried cases is insufficient.

Dynamic limits can help, but require careful definitions. Suppose a participant has a 10 million daily limit, has used 8 million, and submits a 3 million instruction. Whether the system rejects, splits, or waits depends on its rules and the nature of the obligation. Do not split a customer's instruction without authority when the contract requires delivery in full. Perhaps 2 million of settled offsetting obligations releases headroom, creating a 4 million margin and allowing the instruction through. If those inflows are only messages awaiting finality, do not treat them as certain available funds. This is why queue management connects to the earlier finality lesson: liquidity estimated from expected obligations is not the same as cash known to be usable.

Test the sponsor before calculating savings

Indirect access is a shared operating contract. Ask the sponsor which events the customer can see, which only the sponsor sees, how quickly it sends a state change to your app, and whether you can extract records for reconciliation. Imagine the sponsor holds the definitive settlement record but sends your company updates hourly. Settlement itself may be quick while customer complaint resolution is slow because your product cannot see the event. Compare this information gap with the value of direct access or with a contract for real-time state updates. Not every improvement requires changing the access model. Test sponsor failure too: is a second approved route genuinely ready, or will service stop with a clear message? Claiming a fallback without exercising switching and reconciliation can introduce duplicate payments when the original sponsor returns.

Build a four-column decision table for each alternative: fixed and variable cost, liquidity needed, quality of state visibility, and recovery ability. Define each column with observable evidence rather than an impressionistic score. For example, state visibility can be measured as the proportion of instructions linked to a settlement reference within five minutes. Recovery can be measured as time to stop submission, switch safely, and reconcile both records. If one column lacks data, do not award zero or a perfect score. Mark it unverified and specify a trial or contract term that will produce evidence before committing capital. This links access economics to operational safety and prevents a financial break-even calculation from masquerading as a complete decision.

Stress the design before expansion

Do not multiply average daily liquidity by ten and call it a plan for tenfold growth. The timing of payments may change when a new merchant segment joins. A large merchant might send payroll or refunds in one hour, concentrating the peak even if the daily average remains predictable. Build three scenarios: growth spread through the day, growth concentrated in an hour, and delayed inflows during sponsor failure. For each, plot the highest unfunded obligation, time spent queued, incremental funding cost, and value of instructions that could miss their promised window. Compare the outputs with explicit risk limits. An alternative that passes only the average case cannot support an "always available" promise.

Funding tied to expansion creates an option to proceed in stages. Launch with a low value limit for a defined merchant segment, then raise it after several cycles show that inflows arrive as expected and exception time does not worsen with volume. Some payments may remain on a slower, clearly disclosed route if the faster route requires disproportionate funding. The choice is not simply "everything fast" or "everything slow." It is an explicit service policy stating who receives which route and why, with checks that segmentation does not unfairly burden a group without justification. Whenever the customer mix or system rules change, rerun the stress case with new evidence instead of inheriting the pilot's assumptions.