Keystone.
A liquidity shock at one merchant, followed through the payment network to the capital that stops it.

- 168 h
- Simulation horizon
- 100
- Merchants in the benchmark
- 216
- Estimated relationships
- 7
- Shock scenarios
The problem
Merchants on a payment platform do not fail independently. A supplier who is paid late pays their own suppliers late, and the delay travels along the same edges the money does.
The platform processes both sides of every transaction, so it is the only party that can tell a merchant who is genuinely short of cash from one who is short because someone upstream was.
Four questions, in order
- 1Where does payment dependence actually live? The network is estimated from transaction history alone — who pays whom, how much, with what lag and reliability.
- 2What breaks when one payment fails? The shock is simulated through that network over a 168-hour horizon.
- 3Where does one rupee do the most work? Candidate interventions are searched and each plan is replayed against the same shock.
- 4What should be offered, to whom? The chosen action becomes a structured liquidity offer sized to that merchant’s own payment cycle.
Scored, not predicted
Most systems predict which merchants are at risk. Keystone measures what an intervention achieved by replaying it: the recommendation is scored by the simulator, not by the model that proposed it.
Stated plainly
The benchmark is synthetic — networks whose generating process is known, so the model can be scored rather than demonstrated. Nothing moves money: Razorpay runs in Test Mode and every recommendation is recorded as a plan. The offers are model output under stated assumptions, not credit decisions.
It builds on “Programmable Repayment: Risk-Sharing and Enforcement Through the Payment Platform” (Rishabh & Di Stefano, 2026).

Agentic Software Engineering & 3D Synthesis