存款和損失限額

1）為什麼需要限制

限制是響應遊戲（RG）的關鍵工具，允許玩家控制成本和時間，並允許運營商通過減少投訴，charjbacks和運營風險來履行許可和道德義務。

• 防止傷害和沖動支出。
• 成本透明和可預測性。
• 符合監管機構/支付合作夥伴的要求。

2）限制類型和術語

註：在許多法域，存款和/或損失限額最低限度是有約束力的。

3）「冷卻」法規和限制變更

降低限制-立即生效。
加薪-僅在「冷卻」期間（24-168小時，取決於政策/管轄權）之後。
取消限制=提高到「無限制」→也通過「冷卻」。
更改歷史記錄存儲在未更改的日誌中（時間、IP/設備、通道）。

4）誠實計算公式

4.1存款限額

跟蹤指定期間成功補貨的金額。
取消/退還的存款不會增加實際支出，但要考慮當地規範（當取消計為嘗試時）。

allowed_today = daily_deposit_limit - sum(successful_deposits[today])
allowed_today = max(0, allowed_today)

4.2損失限額（Net Loss）

Net Loss=（Σ期存款）− （Σ期結算）−（期初資產負債表−期末資產負債表）−（現金等價獎金註銷）

考慮貨幣兌換和時間限制（本地TZ）。
門檻控制：達到80％/100％時-阻止新利率/存款（按政策）。

4.3營業額限制

我們總結所有利率（包括現金等價物，如果政策中有這樣的規定）。
退款/取消費率扣除。

5）UX模式和成品文本

可用性：限制在配置文件（1-2點擊）中可見,在onbording上可見,軟建議設置限制。

• "選擇限制以控制成本。在48小時（冷卻期）後立即減少，增加"

• "今天你貢獻了200歐元中的120歐元（60％）。剩下80歐元"

• "白天達到極限。您明天可以在00：00補充帳戶"

• "將每日限額提高到300歐元將在48小時後生效。確認嗎？"

• "你已經達到白天損失限額的80%。考慮暫停24小時或設置限制"

反模式：沒有「黑暗」模式，在極限屏幕上沒有促銷，選項可見度相同。

6）與其他RG工具的連接

超時和自我體驗：可從限制屏幕直接訪問。
現實檢查：顯示限制方面的進展；超過時-軟/硬暫停。
Suppression Marketing：一段時間限制已用盡的玩家不應獲得獎勵。

7）與支付、獎金和賭場核心集成

付款：在嘗試註銷之前適用限額；我們顯示可用的余額。
Bonus Engine：確定獎金存款和freebet是否包括在計算中（我們建議計算現金等價物而不是「免費」指標）。
Game Server：在達到極限（idempotent, reason code）時鎖定API投註。
多種貨幣：以賬戶的參考貨幣進行結算；四舍五入-有利於玩家。

8）體系結構（參考）

極限服務：存儲極限，時期，殘余；重新計算事件。

Event Bus: `deposit.succeeded`, `withdrawal.completed`, `bet.placed`, `bet.settled`, `bonus.applied`.

策略引擎：「冷卻」、升級（超時）規則。
網關衛隊：存款/投註前的謂詞。
UI/通知：討價還價，限制中心，現實檢查。
Audit/WORM：不變的安裝/更改/鎖日誌。

失敗安全：如果無法訪問限制服務-默認情況下,禁止需要增加風險的操作（費率/存款）,或根據嚴格的政策應用最後記錄的余額。

9）限制政策（維基的骨架）

1.區域：適用於誰，哪些產品/渠道。
2.限制類型和時期；定義和公式。
3.更改限制：立即降低；升級為「冷卻」。
4.計算透明度：示例，時區，多種貨幣。
5.例外（區域規範，帶有強化檢查的VIP程序）。
6.數據和私有性：最小化，歷史存儲，用於分析的DPIA。
7.上訴：輪廓人，響應時間，理性代碼。

10）計算示例（說明性）

日存款限額為200歐元。
早上：+120歐元→余額80歐元。
晚上：嘗試+100歐元→拒絕，提供+80歐元（可用余額）。
每天100歐元的損失限額。
存款：150歐元；結論：20歐元；資產負債表00：00-50歐元；現在的資產負債表-40歐元。
Net Loss=150 − 20 −（50 − 40）=120 − 10=110歐元→超過限額，投註塊。

11）度量標準和SLO

選擇率限制（目標：≥30 -50％的活躍玩家）。
極限突破預防：達到極限後避免嘗試的比例（→ ~ 100％）。
時間到強制：從事件到鎖定（<1-2秒）。
Increase Cool-off Adherence： 100%遵守延遲。
Harm Reduction：在30天內減少重復的「有害」模式。
Complaint/Chargeback Rate：實施後下降。
System Availability (Limits): ≥99.9％的降解量。

12） RACI（角色和責任）

13）支票清單（運營）

發射前

• 確定限制類型和期限；公式已記錄下來。
• 已配置「冷卻」；A/B文本和onbording準備就緒。
• 與Payments/Game/CRM/Bonus的集成通過了QA。
• 包括WORM審核、SLO/度量標準。

在運行中

• 每周審核結算正確性和時間表。
• 監視false declines/false allows。
• 檢查限額已用盡的玩家的競選活動。

事件

• 退化計劃（僅讀取,pre-proved limits）。
• 在失敗時與玩家進行通信，調整余額。

14）常見錯誤以及如何避免錯誤

不誠實的net loss（不考慮結論/平衡）→捕獲公式並發布示例。
通過總線和同步謂詞在遊戲中緩慢應用→事件。
上升時缺乏「冷卻」→高監管風險。
隱藏的極限屏幕→放置在配置文件、腳踏板、邊框上。
用盡限度的促銷在CRM/ads中→嚴格的支持。
沒有日誌→無法證明合規性（包括WORM）。

15）實施路線圖（6個步驟）

1.策略和DPIA：定義限制類型、公式、「冷卻」。

2.體系結構： 極限服務,活動巴士,guards, idempotency.

3.整合：Payments/Game/Bonus/CRM；多元貨幣。
4.UX和文本：提取，限制中心，現實檢查。
5.可觀察性：SLO，Alerta，WORM審核指標。
6.改進：A/B報告，閾值校準，投訴/事件分析。

結果

存款和損失限制不是設置中的「勾選」，而是端到端的控制輪廓：清晰的公式，快速可靠的鎖定，沒有黑暗模式的誠實UX，超時/自我體驗的鏈接以及嚴格的可觀察性。這種方法可以保護玩家，增強合規性並增強業務可持續性。