A settlement engine for instant payment rails: ledger, liquidity and risk design

1Context and motivation

Traditional retail payment services credit the payee one or more days after the payer is debited, and they can be initiated only at certain places and times. Fast payment services remove both limits: funds are available to the payee immediately, around the clock, every day of the year¹. For a commerce platform that collects from buyers and pays out to sellers, this changes more than the payment method list. The overnight batch used to be where reconciliation ran, where risk analysts reviewed flagged payouts, and where treasury moved money between accounts. On an instant rail there is no such window.

This paper describes the architecture we propose for settling commerce payments and payouts on instant rails. We call it a settlement engine. It sits between external rails (domestic instant schemes, card networks, bank transfers, wallets) and the platform's internal balances, ledger and risk services. We describe the design and the reasons for each part; we do not report its effects, because we have not measured them.

2Settlement as an economic and a computing problem

Two bodies of work frame the design.

The first is the economics of settlement. Gross settlement moves each payment individually; net settlement offsets obligations and moves only the balance. Net settlement can avoid gridlock that gross settlement can fall into when payments wait on each other, and it can economise on collateral, while gross settlement removes the exposure that builds up between settlement points². In a real-time gross settlement system, participants that face liquidity shocks trade off the cost of delaying a payment against the cost of borrowing liquidity, and the design of mechanisms that offset queued payments affects whether participants are better or worse off³. A platform that pays sellers instantly faces the same trade-off on a small scale: every instant payout needs prefunded liquidity now, where a deferred payout can be netted against later collections.

The second is distributed computing. A system spread across machines cannot be consistent, available and tolerant of network partitions at the same time⁴. A settlement engine that must run continuously therefore has to choose, per operation, what it gives up during a partition. Messages between the engine and a rail may be lost or delivered twice, so every operation must be safe to retry⁵. A payout that touches several balances (buyer, platform fee, seller) cannot hold locks across a slow external call, so it is written as a sequence of local steps, each with a compensating step that undoes it if a later step fails⁶.

3Design principles

• Money moves only after the ledger records intent. Every external transfer is preceded by a ledger entry in a pending state, and completed or compensated when the rail answers.
• Every operation is idempotent. Each request carries a key; a repeated request with the same key returns the original result instead of moving money twice⁵.
• Consistency over availability for balances. When the engine cannot confirm a balance, it declines the instant path and falls back to deferred settlement. This is our design choice, made because an unavailable instant option is recoverable and a double payout often is not.
• Liquidity is a constraint, not an assumption. No routing decision assumes an account can cover a payout without checking its balance.
• Risk decisions happen before funds leave. Instant transfers are hard to recall, so the risk gate runs before commitment, not after.
• Every decision is traceable. Each settlement records the route, the risk score, the policy version and the liquidity state that produced it.

4Architecture

The engine has six components plus a monitoring plane.

4.1Rail-independent payment interface

Product services call a small set of operations ("collect", "pay out now", "pay out at the next cycle", "refund") that do not name a rail. Adapters translate each operation into the message format and limits of a specific scheme. Per-scheme limits (transaction caps, daily caps, operating hours where they apply) live in configuration owned by the adapter, so adding a rail does not change the callers.

4.2Internal real-time ledger

The ledger holds every balance the platform manages in double-entry form: each posting debits one account and credits another, and the sum over a transaction is zero. A multi-leg operation such as "collect from buyer, take platform fee, pay seller" is a saga: a sequence of local postings, each with a defined compensation, so that either all legs complete or the completed ones are reversed⁶. Postings are appended, never edited; corrections are new postings. External callbacks are deduplicated by key, and the ledger reconciles its pending entries against rail statements continuously rather than at day end⁷.

4.3Liquidity module

For each rail and settlement account, the module tracks the current balance, the pending outflows and the expected inflows. It forecasts outflows by hour with time-series models that capture trend and seasonality, such as weekly and payday cycles⁸, and it sizes a prefunded buffer from those forecasts (Table 2). When a forecast shows the buffer falling below its floor, the module schedules a rebalancing transfer. When the buffer is exhausted, the routing layer stops offering the instant path on that account until it is replenished.

4.4Risk and compliance gate

Before an instant transfer is committed, the gate scores it for fraud and checks scheme and regulatory limits. Fraudsters adapt to prevention measures, which is why statistical detection has to keep running after controls are in place⁹. Fraud detection on payment streams faces concept drift, class imbalance and verification latency, since only a small share of transactions is checked by investigators in time¹⁰. The gate therefore retrains on a schedule, weights the rare fraud class explicitly, and treats the absence of a fraud label as provisional. Its outputs are not just approve and decline: it can downgrade a payout to deferred settlement, split it into an instant part and a held part, or ask for additional verification.

4.5Routing layer

For each payout, the routing layer chooses between instant and deferred settlement. Inputs are the fee of each path, the liquidity state of the relevant account, the risk gate's output, the payee's stated preference and any fee the payee has agreed to pay for speed. Deferred settlement is also the path on which payouts can be netted against later collections, which reduces the liquidity drawn². The rule set is explicit and versioned; we leave learned routing policies to a later stage, once logged decisions exist to evaluate them against.

4.6Monitoring and fallback

The monitoring plane tracks rail latency, error rates by response code, ledger pending age, reconciliation breaks and buffer levels. When a rail's errors or latency exceed a threshold, a circuit breaker stops new instant requests on that rail and routes them to deferred settlement; requests already sent are resolved by reconciliation, not by retrying blindly. Each rail and region has its own breaker, so a fault on one does not spread.

Table 1 summarises the components, the problem each addresses and the evidence behind it.

Component	Problem it addresses	Evidence
Instant path as an option, not the default	Funds are available at once and around the clock, removing the batch window	1
Netting on the deferred path	Gross settlement draws liquidity per payment; net settlement economises on it	2
Explicit cost of delay versus cost of liquidity	Participants trade off delaying payments against borrowing liquidity	3
Fallback to deferred settlement in a partition	A distributed system cannot be consistent, available and partition tolerant at once	4
Idempotency keys on every operation	Retried or duplicated messages could move money twice	5
Multi-leg postings as sagas with compensation	Long transactions cannot hold locks across slow external calls	6
Continuous reconciliation and deduplication	Duplicate and late callbacks corrupt balances	7
Buffer sizing from arrival rate and lag	Prefunded accounts run dry or tie up idle capital	11
Outflow forecasting with seasonal models	Payday and weekly cycles change liquidity demand	8
Pre-commitment fraud scoring with retraining	Fraudsters adapt; labels arrive late and are rare	9, 10

Source: our design, with the works cited in the table.

5A worked model of buffer sizing

A prefunded settlement account must hold enough to cover instant payouts until the next replenishment arrives. Little's law states that, for a stationary process, the mean number of items in a system equals the arrival rate times the mean time each item spends in it¹¹. Treating each paid-out unit of currency as an item that stays "in the system" from payout until it is replenished, the mean drawn balance equals the outflow rate times the replenishment lag. Table 2 works this through. All inputs are hypothetical.

Quantity	Value	Basis
Instant payouts per hour	40	Input (hypothetical)
Mean payout value	120 currency units	Input (hypothetical)
Outflow rate	4,800 currency units per hour	Computed: 40 × 120
Replenishment lag	6 hours	Input (hypothetical)
Mean drawn balance	28,800 currency units	Computed: 4,800 × 6 (Little's law)
Peak factor	2.0	Input (hypothetical)
Buffer floor	57,600 currency units	Computed: 28,800 × 2.0
Buffer floor with a 2-hour lag	19,200 currency units	Computed: 4,800 × 2 × 2.0

Source: Worked model; inputs in the table.

The model makes two things visible. First, the buffer scales linearly with the replenishment lag, so shortening the lag (for example by rebalancing over an instant rail rather than a batch transfer) reduces the capital tied up by the same proportion as shortening the payout rate would. Second, Little's law gives a mean under stationarity. Payout demand on paydays or during a sales event is not stationary, so the peak factor is a placeholder for a forecast distribution of outflows⁸, and the floor should be set from a quantile of that forecast, not from the mean.

6Illustrative scenarios

The scenarios below are hypothetical. They show how the components would interact; they are not results.

Instant seller payouts. A seller with a long history and a low risk score completes an order. The routing layer offers an instant payout because the account buffer is above its floor. A new seller with a high risk score completing a similar order would receive part of the payout instantly and the rest at the next cycle, with the held part released when the order's dispute window closes.

Rail outage. If an instant scheme began returning timeouts, the circuit breaker for that rail would open. New payouts would go to deferred settlement with a notice to the payee stating when funds would arrive. Payouts already sent with no answer would remain pending in the ledger until reconciliation against the scheme's records resolved them, so that no payout is sent twice.

Payday demand. Before a known payday, the outflow forecast would rise, the buffer floor would rise with it, and the liquidity module would schedule a rebalancing transfer early enough to arrive before the peak. If the forecast were wrong and the buffer were exhausted, the routing layer would stop offering instant payouts on that account rather than fail them.

7Evaluation protocol

Before any outcome claim about this engine could be made, each part would need to be measured.

• Correctness. Fault-injection tests that drop, duplicate and reorder rail messages, with the invariant that ledger balances sum to zero and no payout key settles twice.
• Liquidity. Backtests of the buffer rule on historical outflows: how often the buffer would have been exhausted, and how much capital it would have held idle.
• Risk. Fraud-model evaluation with delayed labels and measures suited to rare classes¹⁰.
• Payee outcomes. Randomised comparison of offering instant payout against not offering it, on seller retention, support contacts and losses, with guardrails on loss rate.

We do not propose target values for these measures. Targets should be set from measured baselines, which we do not have.

8Fairness, transparency and privacy

The risk gate and the routing layer decide who receives money quickly. If those decisions rest on features that proxy for region or bank, some groups of payees could be held back systematically. The design reports instant-path eligibility and hold rates by region, bank and seller cohort, and any large gap is reviewed. Payees see whether a payout is instant or deferred, why, and any fee before they confirm it. Settlement data reveals behaviour (when and how much a seller earns), so the engine keeps only the fields that settlement, risk and reconciliation need, and keeps records in their region.

9Limitations

• No measurements. We have not measured the effect of this design on payout speed, losses, liquidity cost or payee behaviour. Every implied benefit is a hypothesis.
• Scheme detail. Each instant scheme has its own limits, message formats, finality rules and recall procedures. The interface abstracts them; the abstraction has not been tested against a full set of schemes.
• Buffer model. Table 2 rests on stationarity, which payout demand violates. It is a planning device; the floor needs a forecast distribution and a backtest.
• Consistency trade-off. Preferring consistency means instant payouts become unavailable during partitions. How often that happens, and what it costs payees, is unmeasured.
• Risk models. Fraud labels arrive late and are incomplete, so the gate's error rates are uncertain, and adversaries adapt to it.
• Scope. The design addresses retail and small-business commerce. Corporate treasury, cross-border linking of domestic schemes and intraday credit from banks are out of scope.

10Conclusion

We have described a settlement engine for instant rails: a rail-independent interface, an idempotent, saga-based ledger, a liquidity module that sizes buffers from forecasts, a risk gate that decides before funds leave, explicit routing between instant and deferred settlement, and per-rail fallback. Each part rests on published work, summarised in Table 1, and the buffer rule is worked through in Table 2. What the design lacks is evidence of its own effect. The next step is to run the correctness and liquidity backtests on historical payout data and report what is measured.