Your SaaS Is an Insurance Product: A Modeling Framework

This paper proposes a modeling framework that treats capped-usage SaaS products as insurance instruments, applying actuarial science principles like frequency-severity decomposition and Monte Carlo reserve adequacy to optimize pricing and manage tail risk for services with fixed premiums and stochastic, heavy-tailed consumption.

The Gist

The Big Idea: You Are Running an Insurance Company (Even If You Think You're Selling Software)

Imagine you run a gym. You sell a monthly membership for $50. You tell people, "Come as often as you want!"

But here's the catch: If a member comes every single day and uses the most expensive equipment for 12 hours straight, your gym might lose money on them. If 100 members do this, your gym goes bankrupt.

The author of this paper argues that Software-as-a-Service (SaaS) companies (like AI chatbots, cloud hosting, or gym apps) are actually running insurance companies, even though they don't call themselves that.

They are selling a "policy" where:

1. The Premium: The customer pays a fixed monthly fee (e.g., $20/month).
2. The Coverage: The customer gets a certain amount of usage (e.g., 500 AI messages).
3. The Limit: If they use too much, the service stops or slows down. The company refuses to pay for the extra usage.
4. The Risk: The company is betting that most people will use less than the limit, so the money they save on light users will pay for the few heavy users who hit the limit.

The Core Problem: The "Heavy Tail"

In the software world, people often guess prices by doing simple math: "If one message costs me $0.01 to run, and a user sends 1,000 messages, I'll charge them $20."

The paper says this is dangerous. It ignores risk.

• The Light User: Sends 10 messages. You make a huge profit.
• The Heavy User: Sends 100,000 messages. You lose a fortune.

In insurance, this is called the "heavy tail." Most people are normal, but a few people are extreme. If you don't plan for the extreme users, you go bust.

The Solution: Actuarial Science (The "Math of Risk")

The paper suggests that software engineers should stop using simple "unit economics" and start using Actuarial Science. This is the math insurance companies have used for 100 years to price car insurance, health insurance, and life insurance.

Here are the four main tools the paper says software companies need:

1. Frequency vs. Severity (How often and How bad?)

Instead of just guessing total usage, break it down:

• Frequency: How many times does a user click the button? (Like how many times a driver gets into a fender bender).
• Severity: How much does each click cost you? (Like how much a fender bender costs to fix).
• The Analogy: A driver might crash 10 times a year (high frequency) but only scratch the bumper (low severity). Another driver might crash once (low frequency) but total the car (high severity). Software companies need to model both to know their true risk.

2. The "Cap" is a Policy Limit

When a software company says, "You get 500 messages, then we stop," that is exactly like an insurance policy with a $5,000 payout limit.

• If the user needs 600 messages, the company only pays for the first 500.
• The user has to pay for the rest (or stop using the service).
• Why this matters: This "cap" protects the company from going bankrupt. It turns an unlimited risk into a manageable one.

3. Reserves (The "Emergency Fund")

Insurance companies don't just keep the profit; they keep a huge pile of cash in the bank called a Reserve. They do this because they know that sometimes, everyone will have a bad month at the same time.

• The Paper's Claim: Software companies need to calculate exactly how much cash they need to keep in the bank to survive a "bad month" where heavy users go crazy.
• The Math: They use a method called Monte Carlo simulation. Imagine rolling dice 10,000 times to see what the worst-case scenario looks like. If the math says you need $1 million to survive a bad month, you keep $1 million. If you only keep $100,000, you are gambling with your company's life.

4. Human Behavior (The "End-of-Month Rush")

The paper points out a funny human behavior.

• Health Insurance Analogy: In health insurance, if you have a "deductible" (you pay the first $1,000), people rush to the doctor at the end of the year to use up their coverage before it resets.
• Software Analogy: If you have a monthly limit of 500 messages, and you've used 490, you will suddenly start using the service way more in the last few days of the month just to "get your money's worth."
• The Risk: This creates a "spike" in usage right before the reset. Companies need to model this behavior, or they will be surprised by a sudden surge in costs.

Real-World Examples from the Paper

The paper looks at real companies to prove this point:

• Claude Code / ChatGPT: They have "Pro" and "Max" tiers with limits. If you hit the limit, the service stops. This is a "Hard Cap" insurance policy.
• Vercel / Cloudflare: They have a limit, but if you go over, they charge you extra. This is like insurance with a "deductible" and "co-pay."
• Corporate Gym Benefits: Companies pay a flat fee for employees to use a gym app. If everyone goes to the gym every day, the app provider loses money. They need to model the risk of "heavy gym-goers."

The "Gotcha": Why Simple Math Fails

The paper runs a simulation comparing two ways of pricing:

1. The Naive Way: "We expect 100 users to use 100 tokens each. Total cost = 10,000 tokens. We charge $500."
   • Result: They think they are safe.
2. The Actuarial Way: "We know 10% of users will go crazy and use 10,000 tokens. We need to hold extra cash just in case."
   • Result: They realize the "Naive Way" leaves them with no safety net. If the heavy users show up, the company loses money.

Summary

The paper isn't saying software companies need to become legal insurance companies. It's saying they need to think like insurance companies.

• Stop guessing prices based on average usage.
• Start calculating the risk of the "worst-case scenario."
• Use the "Cap" to limit your liability.
• Keep a "Reserve" (cash buffer) to survive bad months.
• Watch out for humans rushing to use their limit right before it resets.

By using these old-school insurance math tools, software companies can stop getting surprised by heavy users and stop accidentally running their businesses into the ground.

Technical Summary

Technical Summary: "Your SaaS Is an Insurance Product: A Modeling Framework"

Problem Statement
The paper addresses a structural gap in the modeling of capped-usage Software-as-a-Service (SaaS) products, including LLM subscriptions (e.g., Claude Code, ChatGPT), cloud platforms (e.g., Vercel, Cloudflare Workers), and corporate benefit platforms. Current engineering and data-science practices typically model these products using naive unit economics: expected volume multiplied by cost-per-unit. The author argues this approach fails to account for the stochastic nature of consumption, heavy-tailed severity distributions, and the specific risk pooling dynamics inherent in contracts where a fixed premium decouples from realized consumption.

The core problem is that capped-usage SaaS contracts structurally mirror policy-limit insurance products. In both cases, the seller receives a fixed premium, faces stochastic aggregate demand, and is exposed to a tail risk that is capped at a contractual ceiling ($K_i$), while the buyer absorbs any consumption beyond that cap. The paper posits that treating these as standard unit-economics problems leads to inadequate reserve dimensioning and mispricing of tail risk.

Methodology
The paper proposes a modeling framework adapted directly from actuarial science, specifically non-life insurance, to restate the SaaS pricing problem. The framework relies on three operational pillars:

1. Frequency–Severity Decomposition with Censoring:

   • Frequency ($N_i$): Modeled not as a simple Poisson process, but using distributions that account for overdispersion and zero-inflation (e.g., Negative Binomial, Zero-Inflated Negative Binomial, or Hurdle models) to capture the bimodal nature of user engagement (light vs. heavy users).
   • Severity ($S_{ij}$): Modeled as the cost per event (e.g., tokens, bandwidth, function invocations). The paper highlights that LLM severity can be decomposed additively (input tokens + output tokens $\times$ model multiplier + tool costs), a structural advantage over traditional insurance claims.
   • Censoring: The aggregate cost per user ($C_i$) is defined as $C_i = \min(K_i, \sum S_{ij})$. The cap $K_i$ creates a right-censored distribution. The paper argues that naive Maximum Likelihood Estimation (MLE) on observed data underestimates the true tail parameters; instead, it advocates for Tobit-style censored MLE or survival-analysis techniques to recover the underlying severity distribution.

2. Portfolio Aggregate Loss and Reserve Adequacy:

   • The portfolio loss $L = \sum C_i$ is treated as a sum of independent (initially) censored compound random variables.
   • Premium Adequacy: Total premiums must cover expected loss plus a safety loading ($\eta$).
   • Reserve Adequacy: The paper defines the required reserve $R$ not as a heuristic buffer, but as a quantile of the aggregate loss distribution. Specifically, $R = \text{VaR}_{1-\alpha}(L) - \sum P_i$ or, more coherently for heavy tails, using Tail-Value-at-Risk (TVaR). This provides a principled answer to "how much margin to hold against a bad month."

3. Behavioral and Structural Extensions:

   • Induced Demand: The framework incorporates behavioral economics, noting that users accelerate consumption as they approach the cap (similar to hitting an out-of-pocket maximum in health insurance) or as the reset date approaches (sunk-cost reasoning).
   • Regime Variations: The model is adapted for three contract regimes:
     • Hard Cap: Service halts at $K_i$ (e.g., Claude Code Max).
     • Soft Degradation: Service continues at a lower tier/cost ratio $\rho$.
     • Included-Plus-Overage: Usage above $K_i$ is billed at a marginal rate (e.g., Vercel Pro), shifting the focus from reserve adequacy to overage-pricing adequacy.

Key Results and Illustrations
The paper validates the framework through mapping real-world products and Monte Carlo simulations:

• Real-World Mapping: Table 1 maps products like Claude Code, ChatGPT, Vercel, and Supabase to the actuarial primitives ($P, N, S, K, T$), demonstrating that the structural signature is universal across domains.
• Monte Carlo Worked Examples:
  • Baseline Scenario: Comparing a "naive" unit-economics model against compound distributions (Poisson-Gamma and NB-LogNormal). The naive model ignores variance, overstating the operational margin. The compound models reveal that even with a cap, tail risk erodes the margin by 2–6% at typical portfolio sizes ($n=10,000$).
  • Stress Scenario: A population of heavy consumers (expected uncapped usage 15x the premium) is simulated under four policy regimes. The results show that a "no-cap" regime is structurally insolvent, while a "hard cap" converts unbounded liability into bounded liability, allowing solvency to be achieved through pricing adjustments rather than absorbing infinite tail risk.
  • Heterogeneity: Simulations of mixed populations (light vs. power users) show that while adverse selection concentrates risk, the hard cap effectively truncates individual exposure, making the impact on portfolio-level reserves (TVaR) smaller than in traditional insurance lines, provided the cap is tight.
• Bias Quantification: A study on censoring bias demonstrates that ignoring the cap during parameter fitting leads to significant underestimation of severity parameters (e.g., a 20% censoring rate can lead to a ~35% underestimation of the standard deviation in a LogNormal model).

Key Contributions
The paper explicitly frames its contribution as operational rather than theoretical. It does not propose new theorems but rather:

1. Vocabulary and Tools: It introduces actuarial vocabulary (frequency-severity, censored compound distributions, IBNR, reserve adequacy via TVaR) to the SaaS engineering community, arguing these tools are currently absent from cs.LG and stat.ML practices.
2. Structural Identity: It establishes that capped-usage SaaS is not merely analogous to insurance but is an insurance product in terms of operational risk management, regardless of legal classification.
3. Correct Primitive: It argues that frequency-severity decomposition with cap-aware censoring is the correct primitive for cost modeling, superior to naive expected-cost-times-volume.
4. Behavioral Modeling: It identifies the "kink" in the price schedule (the cap and the reset) as a source of intertemporal substitution, proposing specific modeling features (time-to-reset covariates) to capture induced demand.

Significance and Claims
The paper claims that the SaaS industry is currently "reinventing" these tools through ad-hoc heuristics and gut feel, leading to suboptimal pricing and reserve management. By adopting the established machinery of actuarial science:

• Reserve Dimensioning: Firms can move from arbitrary safety margins to mathematically grounded capital requirements based on tail risk (VaR/TVaR).
• Pricing Strategy: The framework clarifies the trade-off between hard caps (risk transfer to the user) and overage pricing (risk retention by the seller), showing how to calibrate overage rates to cover marginal costs in heavy-user cohorts.
• Efficiency: It suggests that routing modeling effort from unit economics toward frequency-severity decomposition would compress the "reinvention cycle" of pricing strategies seen in 2025–2026 (e.g., Anthropic's weekly limits, OpenAI's tier gating).

The paper concludes that while the mechanism design (setting the menu of prices and caps) is a separate economic problem, the portfolio management (ensuring solvency under realized consumption) is an actuarial problem that the industry is currently ill-equipped to solve without these specific tools. The open problems identified—cap-aware severity estimation, adverse selection across tiers, behavioral responses near reset, and correlated catastrophe risk—are presented as tractable using existing actuarial methods.