Scoring an intervention by replaying it

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, which makes it the only party that can tell a merchant who is genuinely short of cash from one who is short because someone upstream was. Keystone is a decision engine built for that difference.

Four questions, in order

1. Where does payment dependence actually live? The network is estimated from transaction history alone — who pays whom, how much passes through, with what lag and what reliability.
2. What breaks when one payment fails? The shock is simulated through that network to see who becomes liquidity-constrained, by how much, and when.
3. Where does one rupee do the most work? Candidate interventions are searched, and each plan is replayed against the same shock.
4. What should be offered, to whom? The selected action becomes a structured liquidity offer, sized to that merchant’s own payment cycle.

The claim lives in the third step

Prediction is the easy part to oversell. What sets Keystone apart is how a recommendation is judged: it is replayed through the simulator, and its score is the difference between the run with the intervention and the run without it. The model that proposes a plan never grades its own work.

What it runs on

A discrete-event liquidity simulator over a 168-hour horizon; intervention search with systemic-importance ranking and counterfactual replay; a synthetic network generator with known ground truth; a FastAPI service; and a React interface of four panels — the network, what breaks, where capital works, and the offer. The default benchmark is a 100-merchant network with 216 estimated relationships and seven analysed shock scenarios.

Three things, stated plainly

• The benchmark is synthetic, and that is the point: the generating process is known, so the model can be scored rather than demonstrated. No claim is made about real-world predictive accuracy.
• Nothing moves money. Razorpay runs in Test Mode for connectivity and capability probing, and every recommendation is recorded as a plan.
• The offers are model output, not credit decisions — amounts, terms and indicative costs computed under stated assumptions.

Keystone builds on “Programmable Repayment: Risk-Sharing and Enforcement Through the Payment Platform” by Kumar Rishabh and Alessandro Di Stefano (2026), which argues that a platform can enforce and share risk in ways an outside lender cannot. Keystone asks the operational question that follows: if the platform can place liquidity anywhere in the network, where should it go? The code is on GitHub.