Risk simulation · Responsible automation

Bankroll caps under stress: a tilt-prevention simulation

A simulated stress test showing how per-bet, per-event, and rolling daily caps change an automated strategy's worst-path exposure. This is not a return claim and does not describe live customer betting.

Simulation only · 1,000 bankroll paths · daily cap stopped 18% of worst-path exposure

Paths simulated
1,000
Live wagers
0
Worst-path cap cuts
18%
Rules changed
3

Simulation only. This case study describes a synthetic bankroll stress test for automation guardrails. It does not show customer returns, does not involve live wagers, and should not be read as proof that any strategy will be profitable.

The question

Automation removes hesitation. That is useful when the rules are good and dangerous when the rules are too permissive. We wanted to test how much practical protection came from visible bankroll caps before a strategy could be promoted from paper to live.

The setup

We used a synthetic strategy with a realistic distribution of wins, losses, and clustered event exposure. The strategy was intentionally ordinary: no claimed edge, no special model, no promotional return target. The point was to compare bankroll paths with and without guardrails.

Three controls were tested:

  • a maximum stake per bet,
  • a per-event exposure cap,
  • and a rolling 24-hour bankroll cap.

Each path replayed the same sequence with different random settlement outcomes. The worker recorded when a proposed bet was allowed, rejected, or reduced by cap logic.

What happened

The per-bet cap handled obvious oversizing. The per-event cap handled correlated exposure when multiple markets appeared around the same match. The rolling daily cap mattered most during losing clusters. In the worst simulated paths, it stopped the strategy from continuing to fire after the session had already crossed the user’s pre-committed loss boundary.

The cap did not make the strategy profitable. That is not its job. It made the maximum bad day more legible and reduced the chance that automation would keep acting after the user should have paused.

What we changed

The simulation led to three rule-copy changes in the product narrative:

  1. cap configuration should be framed as a first-class part of strategy design,
  2. paper ledgers should show rejected actions, not hide them,
  3. and live promotion should start with lower caps than the user eventually expects to use.

These are small product choices, but they shape behavior.

Operational takeaway

A betting automation platform should make the boring safety path the default. If a strategy only looks good when caps are absent, it is not ready for live use. Paper-first testing is where those uncomfortable facts should appear.