Networks look resilient on average days. The real test is a shock: a large participant expected to fund in the morning moves its payment to the afternoon, or not at all. If the network assumes its biggest members will behave on time, it is testing optimism, not liquidity.
Design the shock, not the average
Start with the timing of participants, not just their size. A scenario worth running: your largest payer is late by several hours; a second participant also delays; a corridor's cut-off passes while a payment is in flight. Then ask what happens to the net position, which payments depend on the delayed inflow, and where the shortfall lands. Vary severity and sequence so the exercise covers partial failure, not only total default.
Where resilience actually sits
A netted network absorbs more of a shock than a chain of bilateral links. When offsetting flows cancel internally, fewer external payments have to settle, so a single late participant does not stall everything downstream. A single order book concentrates the matching, and routing can send the remainder along alternative paths — hub participants, card networks, local instant payments, SWIFT, stablecoins, agent protocols — choosing by cost, settlement time, reliability and regulatory fit.
Controls that contain the shock
Resilience is built from rules set in advance:
- Per-participant limits and approved counterparties, applied below the model.
- Over-limit operations becoming a human approval request rather than a rejection.
- Selective audit, suspension and exclusion written into the multilateral reliance agreement.
- Every operation traceable to a principal, an agent and a policy version.
In short
- Test participant timings, not just their balances.
- A late payer is the most common real-world stress.
- Netting and routing localise the impact of a delay.
- Pre-agreed limits and consequences do the containing.
See how the reliance agreement sets the rules → /institutions/