💰 quantitative finance

Your SaaS Is an Insurance Product: A Modeling Framework

यह शोध पत्र एक ऐसा मॉडलिंग ढांचा प्रस्तावित करता है जो कैप-यूजेज (capped-usage) वाले SaaS उत्पादों को बीमा उपकरणों के रूप में मानता है, जो निश्चित प्रीमियम और स्टोकेस्टिक (stochastic), हेवी-टेल्ड (heavy-tailed) खपत वाली सेवाओं के लिए मूल्य निर्धारण को अनुकूलित करने और टेल रिस्क (tail risk) को प्रबंधित करने हेतु फ्रीक्वेंसी-सेवेरिटी डिकंपोजिशन (frequency-severity decomposition) और मोंटे कार्लो रिज़र्व पर्याप्तता (Monte Carlo reserve adequacy) जैसे बीमांकिक विज्ञान (actuarial science) के सिद्धांतों को लागू करता है।

मूल लेखक: Caio Gomes (Magalu)

प्रकाशित 2026-05-19

📖 8 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Caio Gomes (Magalu)

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

यहाँ इस पेपर "Your SaaS Is an Insurance Product" का सरल भाषा और रोज़मर्रा के उदाहरणों के साथ हिंदी अनुवाद दिया गया है।

मुख्य विचार: आप एक बीमा कंपनी चला रहे हैं (भले ही आपको लगता हो कि आप सॉफ़्टवेयर बेच रहे हैं)

कल्पना कीजिए कि आप एक जिम चलाते हैं। आप $50 में मासिक सदस्यता (membership) बेचते हैं। आप लोगों से कहते हैं, "जितनी बार चाहें आ सकते हैं!"

लेकिन यहाँ एक पेच है: यदि कोई सदस्य हर दिन आता है और 12 घंटे तक सबसे महंगे उपकरणों का उपयोग करता है, तो आपके जिम को उस पर नुकसान हो सकता है। यदि 100 सदस्य ऐसा करते हैं, तो आपका जिम दिवालिया हो जाएगा।

इस पेपर का लेखक तर्क देता है कि सॉफ्टवेयर-एज़-ए-सर्विस (SaaS) कंपनियाँ (जैसे AI चैटबॉट्स, क्लाउड होस्टिंग, या जिम ऐप्स) वास्तव में बीमा कंपनियाँ (insurance companies) चला रही हैं, भले ही वे खुद को ऐसा न कहें।

वे एक "पॉलिसी" बेच रहे हैं जहाँ:

प्रीमियम (The Premium): ग्राहक एक निश्चित मासिक शुल्क देता है (जैसे, $20/माह)।
कवरेज (The Coverage): ग्राहक को उपयोग की एक निश्चित मात्रा मिलती है (जैसे, 500 AI संदेश)।
सीमा (The Limit): यदि वे बहुत अधिक उपयोग करते हैं, तो सेवा रुक जाती है या धीमी हो जाती है। कंपनी अतिरिक्त उपयोग के लिए भुगतान करने से मना कर देती है।
जोखिम (The Risk): कंपनी इस बात पर दांव लगाती है कि अधिकांश लोग सीमा से कम उपयोग करेंगे, जिससे उनसे बचा हुआ पैसा उन कुछ भारी उपयोगकर्ताओं की भरपाई करेगा जो सीमा तक पहुँच जाते हैं।

मुख्य समस्या: "हैवी टेल" (The Heavy Tail)

सॉफ्टवेयर की दुनिया में, लोग अक्सर सरल गणित करके कीमतों का अनुमान लगाते हैं: "यदि एक संदेश चलाने में मेरी लागत $0.01 है, और एक उपयोगकर्ता 1,000 संदेश भेजता है, तो मैं उनसे$ 20 लूँगा।"

पेपर कहता है कि यह खतरनाक है। यह जोखिम को अनदेखा करता है।

हल्का उपयोगकर्ता (The Light User): 10 संदेश भेजता है। आप भारी मुनाफा कमाते हैं।
भारी उपयोगकर्ता (The Heavy User): 1,00,000 संदेश भेजता है। आप बहुत बड़ा नुकसान उठाते हैं।

बीमा में, इसे "हैवी टेल" (heavy tail) कहा जाता है। अधिकांश लोग सामान्य होते हैं, लेकिन कुछ लोग चरम (extreme) होते हैं। यदि आप चरम उपयोगकर्ताओं की योजना नहीं बनाते हैं, तो आप बर्बाद हो जाएंगे।

समाधान: एक्चुरियल साइंस (Actuarial Science - "जोखिम का गणित")

पेपर सुझाव देता है कि सॉफ्टवेयर इंजीनियरों को केवल "यूनिट इकोनॉमिक्स" का उपयोग करना बंद कर देना चाहिए और एक्चुरियल साइंस (Actuarial Science) का उपयोग करना शुरू करना चाहिए। यह वह गणित है जिसका उपयोग बीमा कंपनियाँ 100 वर्षों से कार बीमा, स्वास्थ्य बीमा और जीवन बीमा की कीमतें तय करने के लिए करती आई हैं।

यहाँ चार मुख्य उपकरण दिए गए हैं जिनकी आवश्यकता पेपर के अनुसार सॉफ्टवेयर कंपनियों को है:

1. फ्रीक्वेंसी बनाम सेवेरिटी (Frequency vs. Severity - कितनी बार और कितना बुरा?)

केवल कुल उपयोग का अनुमान लगाने के बजाय, इसे विभाजित करें:

फ्रीक्वेंसी (Frequency): उपयोगकर्ता कितनी बार बटन क्लिक करता है? (जैसे कि एक ड्राइवर कितनी बार छोटी-मोटी टक्करों में फंसता है)।
सेवेरिटी (Severity): प्रत्येक क्लिक की आपको कितनी लागत आती है? (जैसे कि एक छोटी टक्कर को ठीक करने में कितना खर्च आता है)।
उदाहरण: एक ड्राइवर साल में 10 बार दुर्घटनाग्रस्त हो सकता है (उच्च फ्रीक्वेंसी) लेकिन केवल बंपर को खरोंच सकता है (कम सेवेरिटी)। दूसरा ड्राइवर एक बार दुर्घटनाग्रस्त हो सकता है (कम फ्रीक्वेंसी) लेकिन पूरी कार को नष्ट कर सकता है (उच्च सेवेरिटी)। सॉफ्टवेयर कंपनियों को दोनों को मॉडल करने की आवश्यकता है ताकि वे अपने वास्तविक जोखिम को जान सकें।

2. "कैप" (Cap) एक पॉलिसी लिमिट है

जब एक सॉफ्टवेयर कंपनी कहती है, "आपको 500 संदेश मिलते हैं, फिर हम रुक जाते हैं," तो यह बिल्कुल एक बीमा पॉलिसी की तरह है जिसमें $5,000 के भुगतान की सीमा होती है।

यदि उपयोगकर्ता को 600 संदेशों की आवश्यकता है, तो कंपनी केवल पहले 500 के लिए भुगतान करती है।
उपयोगकर्ता को बाकी के लिए भुगतान करना होगा (या सेवा का उपयोग बंद करना होगा)।
यह क्यों मायने रखता है: यह "कैप" कंपनी को दिवालिया होने से बचाता है। यह असीमित जोखिम को एक प्रबंधनीय जोखिम में बदल देता है।

3. रिजर्व (Reserves - "आपातकालीन निधि")

बीमा कंपनियाँ केवल लाभ नहीं रखतीं; वे बैंक में नकदी का एक बड़ा ढेर रखती हैं जिसे रिजर्व (Reserve) कहा जाता है। वे ऐसा इसलिए करती हैं क्योंकि वे जानते हैं कि कभी-कभी, सभी लोगों का एक ही समय में बुरा महीना चल सकता है।

पेपर का दावा: सॉफ्टवेयर कंपनियों को यह गणना करने की आवश्यकता है कि एक "बुरे महीने" में जीवित रहने के लिए उन्हें बैंक में कितनी नकदी रखनी चाहिए, जहाँ भारी उपयोगकर्ता पागल हो जाते हैं।
गणित: वे मोंटे कार्लो सिमुलेशन (Monte Carlo simulation) नामक विधि का उपयोग करते हैं। कल्पना कीजिए कि सबसे खराब स्थिति क्या हो सकती है, यह देखने के लिए 10,000 बार पासा (dice) फेंकना। यदि गणित कहता है कि एक बुरे महीने में जीवित रहने के लिए आपको $1 मिलियन की आवश्यकता है, तो आप$ 1 मिलियन रखते हैं। यदि आप केवल $100,000 रखते हैं, तो आप अपनी कंपनी के जीवन के साथ जुआ खेल रहे हैं।

4. मानवीय व्यवहार (Human Behavior - "महीने के अंत की भागदौड़")

पेपर एक मजेदार मानवीय व्यवहार की ओर इशारा करता है।

स्वास्थ्य बीमा का उदाहरण: स्वास्थ्य बीमा में, यदि आपके पास "डिडक्टिबल" (आप पहले $1,000 का भुगतान करते हैं) है, तो लोग साल के अंत में अपनी कवरेज का उपयोग करने के लिए डॉक्टर के पास भागते हैं ताकि रिसेट होने से पहले इसका लाभ उठा सकें।
सॉफ्टवेयर का उदाहरण: यदि आपके पास मासिक सीमा 500 संदेशों की है, और आपने 490 संदेशों का उपयोग कर लिया है, तो आप महीने के अंतिम कुछ दिनों में अपनी "पैसे वसूलने" के लिए अचानक बहुत अधिक उपयोग करना शुरू कर देंगे।
जोखिम: यह रिसेट होने से ठीक पहले उपयोग में एक "स्पाइक" (अचानक उछाल) पैदा करता है। कंपनियों को इस व्यवहार को मॉडल करने की आवश्यकता है, अन्यथा वे अचानक लागत में वृद्धि से हैरान रह जाएंगे।

पेपर से वास्तविक दुनिया के उदाहरण

पेपर इस बात को सिद्ध करने के लिए वास्तविक कंपनियों को देखता है:

Claude Code / ChatGPT: उनके पास सीमाओं के साथ "प्रो" और "मैक्स" स्तर हैं। यदि आप सीमा तक पहुँचते हैं, तो सेवा रुक जाती है। यह एक "हार्ड कैप" (Hard Cap) बीमा पॉलिसी है।
Vercel / Cloudflare: उनके पास एक सीमा है, लेकिन यदि आप इससे ऊपर जाते हैं, तो वे आपसे अतिरिक्त शुल्क लेते हैं। यह "डिडक्टिबल" और "को-पे" वाले बीमा की तरह है।
कॉर्पोरेट जिम बेनिफिट्स: कंपनियाँ कर्मचारियों को जिम ऐप का उपयोग करने के लिए एक निश्चित शुल्क देती हैं। यदि हर कोई हर दिन जिम जाता है, तो ऐप प्रदाता को नुकसान होता है। उन्हें "भारी जिम जाने वालों" के जोखिम को मॉडल करने की आवश्यकता है।

"गॉटचा" (The Gotcha): साधारण गणित क्यों विफल होता है

पेपर दो तरीकों से मूल्य निर्धारण (pricing) की तुलना करते हुए एक सिमुलेशन चलाता है:

नाइव तरीका (The Naive Way): "हम उम्मीद करते हैं कि 100 उपयोगकर्ता 100 टोकन प्रत्येक का उपयोग करेंगे। कुल लागत = 10,000 टोकन। हम $500 चार्ज करेंगे।"
- परिणाम: वे सोचते हैं कि वे सुरक्षित हैं।
एक्चुरियल तरीका (The Actuarial Way): "हम जानते हैं कि 10% उपयोगकर्ता पागल हो जाएंगे और 10,000 टोकन का उपयोग करेंगे। हमें सुरक्षा जाल के रूप में अतिरिक्त नकदी रखने की आवश्यकता है।"
- परिणाम: वे महसूस करते हैं कि "नाइव तरीका" उन्हें बिना किसी सुरक्षा तंत्र के छोड़ देता है। यदि भारी उपयोगकर्ता आते हैं, तो कंपनी को नुकसान होगा।

सारांश

पेपर यह नहीं कह रहा है कि सॉफ्टवेयर कंपनियों को कानूनी बीमा कंपनियाँ बनने की आवश्यकता है। यह कह रहा है कि उन्हें बीमा कंपनियों की तरह सोचना चाहिए।

औसत उपयोग के आधार पर कीमतों का अनुमान लगाना बंद करें।
"सबसे खराब स्थिति के परिदृश्य" (worst-case scenario) के जोखिम की गणना करना शुरू करें।
अपनी देनदारी को सीमित करने के लिए "कैप" (Cap) का उपयोग करें।
बुरे महीनों में जीवित रहने के लिए एक "रिजर्व" (नकदी बफर) रखें।
रिसेट होने से ठीक पहले अपनी सीमा का उपयोग करने के लिए भागते हुए मनुष्यों पर नज़र रखें।

इन पुराने स्कूल के बीमा गणित उपकरणों का उपयोग करके, सॉफ्टवेयर कंपनियाँ भारी उपयोगकर्ताओं से हैरान होना बंद कर सकती हैं और अनजाने में अपने व्यवसाय को बर्बाद करना बंद कर सकती हैं।

तकनीकी सारांश: "आपका SaaS एक बीमा उत्पाद है: एक मॉडलिंग फ्रेमवर्क"

समस्या विवरण
यह शोध पत्र कैप किए गए उपयोग (capped-usage) वाले सॉफ़्टवेयर-एज़-ए-सर्विस (SaaS) उत्पादों के मॉडलिंग में एक संरचनात्मक अंतराल को संबोधित करता है, जिसमें LLM सब्सक्रिप्शन (जैसे, Claude Code, ChatGPT), क्लाउड प्लेटफॉर्म (जैसे, Vercel, Cloudflare Workers), और कॉर्पोरेट बेनिफिट प्लेटफॉर्म शामिल हैं। वर्तमान इंजीनियरिंग और डेटा-साइंस पद्धतियां आमतौर पर इन उत्पादों को सरल 'यूनिट इकोनॉमिक्स' का उपयोग करके मॉडल करती हैं: अपेक्षित वॉल्यूम (expected volume) गुणा प्रति-इकाई लागत (cost-per-unit)। लेखक का तर्क है कि यह दृष्टिकोण खपत की स्टोकेस्टिक प्रकृति (stochastic nature), हेवी-टेल्ड सेवेरिटी डिस्ट्रीब्यूशन (heavy-tailed severity distributions), और उन विशिष्ट जोखिम पूलिंग डायनेमिक्स को समझने में विफल रहता है जो उन अनुबंधों में निहित होते हैं जहाँ एक निश्चित प्रीमियम, वास्तविक खपत से अलग (decouple) हो जाता है।

मुख्य समस्या यह है कि कैप किए गए उपयोग वाले SaaS अनुबंध संरचनात्मक रूप से पॉलिसी-लिमिट इंश्योरेंस उत्पादों के समान हैं। दोनों मामलों में, विक्रेता एक निश्चित प्रीमियम प्राप्त करता है, स्टोकेस्टिक एग्रीगेट डिमांड का सामना करता है, और एक टेल रिस्क (tail risk) के प्रति संवेदनशील होता है जो एक संविदात्मक सीमा ( $K_i$ ) पर सीमित होता है, जबकि खरीदार उस कैप से परे किसी भी खपत का भार वहन करता है। पेपर का तर्क है कि इन्हें मानक यूनिट-इकोनॉमिक्स समस्याओं के रूप में मानना अपर्याप्त रिजर्व डायमेंशनिंग और टेल रिस्क के गलत मूल्य निर्धारण (mispricing) की ओर ले जाता है।

कार्यप्रणाली (Methodology)
यह पेपर सीधे गैर-जीवन बीमा (non-life insurance) से अनुकूलित एक मॉडलिंग फ्रेमवर्क प्रस्तावित करता है, ताकि SaaS मूल्य निर्धारण समस्या को पुनर्गठित किया जा सके। यह फ्रेमवर्क तीन परिचालन स्तंभों पर आधारित है:

फ्रीक्वेंसी-सेवेरिटी डिकम्पोजिशन विद सेंसरिंग (Frequency–Severity Decomposition with Censoring):
- फ्रीक्वेंसी ( $N_i$ ): इसे केवल एक साधारण पॉइसन प्रोसेस (Poisson process) के रूप में नहीं, बल्कि उन डिस्ट्रीब्यूशन्स का उपयोग करके मॉडल किया गया है जो ओवरडिस्पर्शन (overdispersion) और ज़ीरो-इन्फ्लेशन (zero-inflation) को ध्यान में रखते हैं (जैसे, नेगेटिव बाइनोमियल, ज़ीरो-इन्फ्लेटेड नेगेटिव बाइनोमियल, या हर्डल मॉडल्स), ताकि उपयोगकर्ता जुड़ाव की बाइमोडल प्रकृति (हल्के बनाम भारी उपयोगकर्ताओं) को कैप किया जा सके।
- सेवेरिटी ( $S_{ij}$ ): इसे प्रति घटना लागत (जैसे, टोकन, बैंडविड्थ, फंक्शन इन्वोकेशन) के रूप में मॉडल किया गया है। पेपर इस बात पर प्रकाश डालता है कि LLM सेवेरिटी को योगात्मक रूप से (additively) विघटित किया जा सकता है (इनपुट टोकन + आउटपुट टोकन $\times$ मॉडल मल्टीप्लायर + टूल लागत), जो पारंपरिक बीमा दावों की तुलना में एक संरचनात्मक लाभ है।
- सेंसिंग (Censoring): प्रति उपयोगकर्ता कुल लागत ( $C_i$ ) को $C_i = \min(K_i, \sum S_{ij})$ के रूप में परिभाषित किया गया है। कैप $K_i$ एक राइट-सेंसर्ड (right-censored) डिस्ट्रीब्यूशन बनाता है। पेपर का तर्क है कि साधारण मैक्सिमम लाइकलीहुड एस्टीमेशन (MLE) देखे गए डेटा पर वास्तविक टेल पैरामीटर्स का कम आकलन करता है; इसके बजाय, यह अंतर्निहित सेवेरिटी डिस्ट्रीब्यूशन को पुनः प्राप्त करने के लिए टोबिट-शैली के सेंसरड MLE (Tobit-style censored MLE) या सर्वाइवल-एनालिसिस तकनीकों की वकालत करता है।
पोर्टफोलियो एग्रीगेट लॉस और रिजर्व पर्याप्तता (Portfolio Aggregate Loss and Reserve Adequacy):
- पोर्टफोलियो लॉस $L = \sum C_i$ को स्वतंत्र (प्रारंभिक रूप से) सेंसरड कंपाउंड रैंडम वेरिएबल्स के योग के रूप में माना जाता है।
- प्रीमियम पर्याप्तता (Premium Adequacy): कुल प्रीमियम को अपेक्षित हानि प्लस एक सेफ्टी लोडिंग ( $\eta$ ) को कवर करना चाहिए।
- रिजर्व पर्याप्तता (Reserve Adequacy): पेपर यह परिभाषित करता है कि आवश्यक रिजर्व $R$ केवल एक ह्यूरिस्टिक बफर नहीं है, बल्कि एग्रीगेट लॉस डिस्ट्रीब्यूशन का एक क्वांटाइल है। विशेष रूप से, $R = \text{VaR}_{1-\alpha}(L) - \sum P_i$ या, हेवी टेल्स के लिए अधिक सुसंगत रूप से, टेल-वैल्यू-एट-रिस्क (TVaR) का उपयोग करता है। यह "एक बुरे महीने के खिलाफ कितनी मार्जिन रखनी है" का एक सिद्धांत-आधारित उत्तर प्रदान करता है।
व्यवहार संबंधी और संरचनात्मक विस्तार (Behavioral and Structural Extensions):
- प्रेरित मांग (Induced Demand): फ्रेमवर्क व्यवहारिक अर्थशास्त्र को शामिल करता है, यह नोट करते हुए कि उपयोगकर्ता कैप के करीब पहुँचते ही खपत तेज कर देते हैं (जैसे स्वास्थ्य बीमा में आउट-ऑफ-पॉकेट मैक्सिमम तक पहुँचना) या रीसेट तिथि के करीब आते ही (संक-कॉस्ट रीजनिंग के कारण)।
- रेजीम भिन्नताएं (Regime Variations): मॉडल को तीन अनुबंध व्यवस्थाओं के लिए अनुकूलित किया गया है:
  - हार्ड कैप (Hard Cap): सेवा $K_i$ पर रुक जाती है (जैसे, Claude Code Max)।
  - सॉफ्ट डिग्रेडेशन (Soft Degradation): सेवा एक निचले स्तर/लागत अनुपात $\rho$ पर जारी रहती है।
  - इन्क्लूडेड-प्लस-ओवरेज (Included-Plus-Overage): $K_i$ से ऊपर का उपयोग एक मार्जिनल दर पर बिल किया जाता है (जैसे, Vercel Pro), जिससे ध्यान रिजर्व पर्याप्तता से हटकर ओवरेज-प्राइसिंग पर्याप्तता पर केंद्रित हो जाता है।

प्रमुख परिणाम और चित्रण
पेपर वास्तविक दुनिया के उत्पादों और मोंटे कार्लो सिमुलेशन के माध्यम से फ्रेमवर्क को मान्य करता है:

वास्तविक दुनिया का मैपिंग: टेबल 1 क्लॉड कोड, चैटजीपीटी, वर्सेल और सुपबेस जैसे उत्पादों को एक्चुरियल प्रिमिटिव्स ( $P, N, S, K, T$ ) में मैप करता है, जो दर्शाता है कि इनका संरचनात्मक सिग्नेचर सार्वभौमिक है।
मोंटे कार्लो वर्क उदाहरण:
- बेसलाइन परिदृश्य: एक "नाइव" यूनिट-इकोनॉमिक्स मॉडल बनाम कंपाउंड डिस्ट्रीब्यूशन्स (पॉइसन-गामा और NB-लॉग-नॉर्मल) की तुलना। नाइव मॉडल वेरिएंस को अनदेखा करता है, जिससे परिचालन मार्जिन का अतिरंजित आकलन होता है। कंपाउंड मॉडल प्रकट करते हैं कि कैप के बावजूद, टेल रिस्क विशिष्ट पोर्टफोलियो आकार ( $n=10,000$ ) पर मार्जिन को 2-6% तक कम कर देता है।
- तनाव परिदृश्य (Stress Scenario): भारी उपभोक्ताओं (अपेक्षित अनकैप्ड उपयोग प्रीमियम का 15 गुना) की एक आबादी को चार पॉलिसी व्यवस्थाओं के तहत सिम्युलेट किया गया। परिणाम दिखाते हैं कि "नो-कैप" व्यवस्था संरचनात्मक रूप से दिवालिया है, जबकि "हार्ड कैप" अनबाउंडेड लायबिलिटी को बाउंडेड लायबिलिटी में बदल देता है, जिससे मूल्य निर्धारण समायोजन के माध्यम से सॉल्वेंसी प्राप्त करना संभव हो जाता है।
- विषमता (Heterogeneity): मिश्रित आबादी (हल्के बनाम पावर यूजर्स) के सिमुलेशन दिखाते हैं कि जबकि एडवर्स सिलेक्शन जोखिम को केंद्रित करता है, हार्ड कैप व्यक्तिगत एक्सपोजर को प्रभावी ढंग से ट्रंकेट (truncate) करता है, जिससे पोर्टफोलियो-स्तर के रिजर्व (TVaR) पर प्रभाव पारंपरिक बीमा लाइनों की तुलना में कम हो जाता है, बशर्ते कि कैप सख्त हो।
बायस क्वांटिफिकेशन (Bias Quantification): सेंसरिंग बायस पर एक अध्ययन दर्शाता है कि पैरामीटर फिटिंग के दौरान कैप को अनदेखा करने से सेवेरिटी पैरामीटर्स का महत्वपूर्ण कम आकलन होता है (जैसे, 20% सेंसरिंग दर लॉग-नॉर्मल मॉडल में स्टैंडर्ड डेविएशन का ~35% कम आकलन कर सकती है)।

प्रमुख योगदान
पेपर स्पष्ट रूप से अपने योगदान को सैद्धांतिक के बजाय परिचालन (operational) के रूप में फ्रेम करता है। यह नए प्रमेय प्रस्तावित नहीं करता है, बल्कि:

शब्दावली और उपकरण: यह SaaS इंजीनियरिंग समुदाय में एक्चुरियल शब्दावली (फ्रीक्वेंसी-सेवेरिटी, सेंसरड कंपाउंड डिस्ट्रीब्यूशन, IBNR, TVaR के माध्यम से रिजर्व पर्याप्तता) पेश करता है, और तर्क देता है कि ये उपकरण वर्तमान में cs.LG और stat.ML प्रथाओं में अनुपस्थित हैं।
संरचनात्मक पहचान: यह स्थापित करता है कि कैप किया गया उपयोग वाला SaaS केवल बीमा के समान नहीं है, बल्कि परिचालन जोखिम प्रबंधन के मामले में एक बीमा उत्पाद है, चाहे उसका कानूनी वर्गीकरण कुछ भी हो।
सही प्रिमिटिव (Correct Primitive): यह तर्क देता है कि कैप-जागरूक सेंसरिंग के साथ फ्रीक्वेंसी-सेवेरिटी डिकम्पोजिशन सही प्रिमिटिव है, जो कि नाइव एक्सपेक्टेड-कॉस्ट-टाइम्स-वॉल्यूम से बेहतर है।
व्यवहार संबंधी मॉडलिंग: यह मूल्य अनुसूची में "किंक" (किक/मोड़) को प्रेरित मांग को पकड़ने के लिए एक स्रोत के रूप में पहचानता है, जो विशिष्ट मॉडलिंग फीचर्स (टाइम-टू-रीसेट कोवेरिएट्स) का प्रस्ताव करता है।

महत्व और दावे
पेपर दावा करता है कि SaaS उद्योग वर्तमान में इन उपकरणों को एड-हॉक ह्यूरिस्टिक्स और अंतर्ज्ञान (gut feel) के माध्यम से "पुनः आविष्कार" कर रहा है, जिससे उप-इष्टतम मूल्य निर्धारण और रिजर्व प्रबंधन हो रहा है। एक्चुरियल विज्ञान के स्थापित तंत्र को अपनाकर:

रिजवेल डायमेंशनिंग: फर्में मनमाने सुरक्षा मार्जिन से हटकर टेल रिस्क (VaR/TVaR) पर आधारित गणितीय रूप से ठोस पूंजी आवश्यकताओं की ओर बढ़ सकती हैं।
मूल्य निर्धारण रणनीति: फ्रेमवर्क हार्ड कैप (उपयोगकर्ता को जोखिम हस्तांतरण) और ओवरेज प्राइसिंग (विक्रेता द्वारा जोखिम प्रतिधारण) के बीच के ट्रेड-ऑफ को स्पष्ट करता है, जिससे यह दिखाया जा सकता है कि भारी-उपयोगकर्ता समूहों में सीमांत लागत को कवर करने के लिए ओवरेज दरों को कैसे कैलिब्रेट किया जाए।
दक्षता: यह सुझाव देता है कि मॉडलिंग प्रयास को यूनिट इकोनॉमिक्स से हटाकर फ्रीक्वेंसी-सेवेरिटी डिकम्पोजिशन की ओर ले जाने से 2025-2026 में देखी जा रही मूल्य निर्धारण रणनीतियों (जैसे, एंथ्रोपिक की साप्ताहिक सीमाएं, ओपनएआई की टियर गेटिंग) के "री-इन्वेंशन साइकिल" को कम किया जा सकता है।

पेपर निष्कर्ष निकालता है कि जबकि मैकेनिज्म डिजाइन (कीमतों और कैप के मेनू सेट करना) एक अलग आर्थिक समस्या है, पोर्टफोलियो प्रबंधन (वास्तविक खपत के तहत सॉल्वेंसी सुनिश्चित करना) एक एक्चुरियल समस्या है जिसे उद्योग वर्तमान में इन विशिष्ट उपकरणों के बिना हल करने में असमर्थ है। पहचाने गए खुले प्रश्न—कैप-जागरूक सेवेरिटी एस्टीमेशन, टियर्स के बीच एडवर्स सिलेक्शन, रीसेट के पास व्यवहारिक प्रतिक्रिया, और सहसंबद्ध कैटास्ट्रोफी रिस्क—मौजूदा एक्चुरियल विधियों का उपयोग करके हल करने योग्य प्रस्तुत किए गए हैं।