負責任的遊戲和限制

1）目的和領域

創建一個防止對玩家造成傷害並降低監管/聲譽風險的系統：透明的限制，及時的幹預，正確的溝通，決策記錄和合規證據基礎。覆蓋範圍：Web/mobile產品，CRM/營銷，CS，付款/結算，遊戲提供商，向市場報告。

2） RG原則

預防比反應更重要。早期信號和在傷害發生之前進行軟幹預。
玩家自治。極限設置簡單，僅可逆於收緊（冷卻）。
透明度。清晰的規則說明、時間/總和截止、限制進度可見性。
沒有壓力。禁止對弱勢球員進行激進的upsell/重新激活。
可證明性。所有步驟都在帶有時間表和來源的雜誌上。
隱私。通過RBAC/DPO最小化PII，存儲和訪問。

3）角色和RACI

RG Lead（策略所有者）-策略，度量，UX/copirait批準，升級。(A)

風險/AML-傷害標記，風險評估，「affordability」驗證。(R)

CS/CRM-溝通，約束/自我體驗的伴隨。(R)

Payments/Finance-在RG/AML檢查中凍結調查結果,根據政策退款。(R)

產品/UX/工程-限制，正念橫幅，現實支票，計數器，與註冊表的集成。(R)

法律/DPO-法規遵從性/本地性，隱私性。(C)

Internal Audit-獨立檢查和追回CAPA。(C)

Exec Sponsor（COO/CEO）-「tone from the top」，資源。(I/A)

4）限制和力學類型

4.1財務限額

存款/充值（日/周/月）。
損失（loss limit）-期間凈損失。
利率/周轉（wager cap）是總和。
獲勝/輸出的限制-可選用於行為曲線。

4.2時間限制

每天/每周時間，會議時間，強制休息時間。
現實檢查：帶有時間/損耗和退出按鈕的彈出窗口。

4.3自我限制

超時（冷靜）：24小時/7/30天。
自我排斥：6-12個月或無限期；取消-僅通過冷卻和確認。

4.4行為「軟」工具

支出歷史和純結果與視覺圖表。
預算滑翔機（每月娛樂預算的輸入）。
提醒您已設定的限額（70/90%）。
單擊關閉營銷通訊。

規則：緊縮-立即；緩解-冷卻期後（例如24-168小時）。

5）危害標記（Harm標記）和風險評估

金融：存款/損失增加，事件頻發「接近上限」，撤銷，借貸/借貸方法。
行為：夜間會議，投註速度增加，許多並發遊戲，損失後迅速回歸。
通訊：聊天/CS中的侵略，要求取消限制，抱怨財務困難。
社會：自我定位為「擺脫債務」，提到成癮。
監管：與自我審查/年齡限制登記冊不兼容。

評分：規則等級（閾值）+ML信號（在確認的案例中學習）。
風險類別：低/中等/高→適當的幹預水平。

6）幹預和情景

0級（啟蒙）：橫幅、現實檢查、「如何設置限制」提示。
Level 1（軟聯系人）：e-mail/in-app消息提供限制/中斷。
Level 2 （CS聯系人）：個性化對話、健康檢查、超時報價。
第3級（限制）：強制降低限制,暫時阻止營銷/獎金。
第4級（嚴格措施）：自我排序/鎖定帳戶,必要時通知註冊表。

• "我們註意到活動表明存在風險。想設置限制還是休息一下？"
• 「我們將暫停促銷優惠，讓你有時間做出明智的決定。」
• "根據負責任的遊戲規則，我們將暫時限制訪問。這是尋求幫助的方法"

7） UX和復印機

極限-從頭部/輪廓單擊；可見的進展指標。
沒有遊戲化和操縱的文本；避免綠色「輕推」繼續。
在負面趨勢下重新存款之前的「摩擦」屏幕。
幫助頁面包含簡單的解釋和本地支持資源。

8）償付能力檢查（Affordability）

風險觸發器→查詢更多信息：資金/收入來源（在法律範圍內），大型/頻繁存款驗證。
在檢查期間部分/完全暫停遊戲。
決定記錄在案；沒有關於AML懷疑的提示。

9）集成和提供商

自我評估登記冊（區域）：實時同步或T+1；登入/存款前的單位。
遊戲提供商：「freeze」的API，限制/中斷狀態的傳輸；一個事件"session_stop"。
付款/PSP：反欺詐的RG標誌，活躍限制下的軟存款偏差。

10）數據、隱私和保密

Модель данных: `user_id, limit_type, value, period, set_at, effective_at, cooldown_until, changed_by, reason, evidence_id`.

幹預日誌：「risk_score_before/after, channel, script_id, outcome」。
PII最小化：僅存儲必需品；在報告中掩蓋。
回避：限制/幹預-不少於監管期限（通常為5-7年）；訪問-RBAC，僅通過需要知道來查看。

11）報告和dashboard RG

KPI/KRI:

Coverage：設置限制的活躍玩家百分比。
時間到幹預：從傷害標記到接觸的中位數。
極限更新：→設定極限報價的轉換。
Recurrence：30/90天的重復傷害標記。
冷卻期後自我釋放率及退貨。
Marketing Suppression：在支持列表下易受傷害的百分比。
Complaints/Disputes：在X天≤解決的投訴比例。
Compliance SLA：與註冊表同步,通知及時。

12）監管義務（骨架）

自我排序/登記冊：註冊/同步，時間表。
通訊：禁止對弱勢群體進行積極的營銷/獎金。
報告：頻率和格式（事件，限制，SE）。
RG事件：及時通知監管機構，文物。
本地化：接口語言和市場幫助。

13）支票單

啟動限制之前

• UX流簡化（≤ 3次點擊）。
• 減弱時的冷卻已調整。
• SE/CR集成註冊表已測試（正值/負值）。
• 多用戶環境中的時間/損耗計數器是正確的。
• CS腳本與Legal/RG Lead協調。
• Logi/日誌不變，報告與GL/錢包收斂。

幹擾

• 有觸發器和反應水平的量表。
• 沒有壓力/操作的消息模板。
• suppression list已連接到CRM/大炮/郵件。
• 必須記錄原因和結果。

報告和審計

• Dashboard RG每天更新。
• 案例樣本由IA每季度檢查一次。
• CAPA按時間重復發現（SLA）。

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

很難找到限制，→拿到頭版/個人資料/現實支票。

無冷卻的軟化.→總是有力冷卻.

在弱勢群體中進行營銷。在競選活動中→強制性的支持標誌。

沒有證據基礎.→結構化的邏輯,ID引用到工件.

只有「紙質」措施.→定期A/B-pruf用於極限轉換和減少危害標記。

15）模板（快速插入）

A）標語「設置限制」

B）給玩家的消息（級別1）

C） CS關於延遲輸出（不拖拉）的響應)

D）自我體驗信

16）技術實現（骨架）

RG限制服務（idempotent API）：「POST/limits」，「GET/limits」，「POST/self-exclusion」，「POST/cooloff」。

Реестр событий: `limit_threshold_reached`, `reality_check`, `rg_intervention`, `marketing_suppressed`.

策略引擎： 觸發規則,cooldown, suppression.

數據質量：GL/錢包 vs RG報告，電路驗證器。
按設計保密：PII字段分離；所有卸載-帶有口罩。

17）實施計劃（30天）

第一周

1.批準RG政策（限制、冷卻、幹預級別）。
2.專門介紹數據/事件模型和RACI。
3.準備UX布局和文本（RU/EN+關鍵位置）。

第二周

4.實施限制和現實檢查服務,與提供商/PSP集成。
5.在CRM和營銷單元中配置支持路徑。
6.培訓CS/CRM，發布腳本和1頁。

第3周

7.5-10%流量的飛行員：檢查日誌,冷卻,SE。
8.危害標記的表格測試，案件的手動驗證。
9.收集支架,更新規則和文本。

第四周

10.完整發行；KPI和RG事件的每日監視。
11.向管理層報告；CAPA偏差。
12.計劃v1。1：區域一體化，ML信號，附加限制。

• 道德和行為守則
• AML培訓和員工培訓
• 員工對合規性的認識
• 事件花花公子和劇本
• 違規通知和報告時限
• 監管報告和數據格式
• 內部審計和外部審計
• 審計清單和評論
• 許可證續簽和檢查
• 各區域監管規章的變化