自我排斥和帳戶鎖定
1）目的和領域
提供安全，透明和法律上正確的自我排斥和鎖定機制，以保護玩家，減少傷害並遵守許可要求。覆蓋範圍包括：web/mobile，遊戲提供商，付款/PSP，CRM/營銷，sapport（CS），Risk/AML，Legal/DPO，向監管機構報告。
2）原則
玩家安全優先級。任何對SE的請求都會立即處理。
沒有壓力。禁止在SE期間嘗試過度緩解/重新激活。
期間不可逆轉。取出或放寬-僅在冷卻和確認期之後。
鎖定的完整性。遊戲/存款/營銷/獎金/PSP-支持。
可證明性。決策記錄，文物，發送到註冊表的收據。
隱私。PII被最小化，通過RBAC訪問，通過恢復存儲。
3）角色和RACI
RG Lead（流程所有者）-策略/度量,升級。(A)
CS/CRM-接受申請，正確溝通，啟動支持。(R)
風險/AML-風險強制鎖定/傷害/制裁標記。(R)
產品/UX/工程-UX流，SE/鎖定 API，與註冊表/提供商/PSP集成。(R)
法律/DPO-需求本地化，隱私/隱私。(C)
Payments/Finance-保留/取消存款/政策結論。(R)
內部審計-獨立檢查和CAPA。(C)
Exec Sponsor (COO/CEO) — «tone from the top».(I/A)
4）限制類型
4.1自願人員
超時（冷靜）：24小時/7/30天。
自我排斥（SE）：6-12個月或無限期；只能通過程序（冷卻+確認）重新激活。
4.2強制執行
RG鎖定：確診危害/不當行為標記。
法律阻止：應監管/法院/登記處的要求。
AML/制裁鎖定：根據AML/制裁政策（無止境）。
一般：在任何活動限制下-完整的遊戲溢價/存款/營銷/獎金。
5）UX流和復印件
5.1啟動
摘自個人資料和頭條新聞：「休息一下」/「自我隔離」。≤ 3次點擊。
可理解的時間表和後果（遊戲/存款/獎金/通訊）。
5.2確認
清晰的類型/期限/結束日期/將禁用的屏幕。
Checkbox「我理解後果」和CTA：「確認自我排斥」。
5.3激活後
接口塊，屏幕上的「在［日期］之前主動自我體驗」。
援助和支持資源的鏈接。
5.4寬松/退貨
僅在最後期限+冷卻期（例如24-168小時）之後才可用,並附有解決方案確認。
無壓力的文本（示例）：- 「我們將暫停遊戲訪問［日期］，以便您暫停。」
- "營銷消息被禁用。您可以在期滿後將其包括在內"
6）集成和鎖定路徑
自我排斥登記冊（編號/reg）入境和存款前的登記/檢查；realtime或T +1同步。
遊戲提供商：「session_stop」事件，禁止新會議；SE狀態廣播到aggregator。
PSP/付款：新存款/風險偏差；SE標誌在反弗羅德語中。
CRM/市場營銷： 用於電子郵件/SMS/推送/重新發布活動的支持列表。
附屬關系：禁止定向/重新激活的SE狀態通知。
7）數據、期刊和推理
數據模型（最小）：- `user_id, restriction_type{cooloff|SE|RG|AML|legal}, start_at, end_at, source{self|rg|aml|reg}, reason_code, evidence_id, set_by, effective_at, cooldown_until, suppression_flags{games|deposits|crm|psp}, registry_case_id`.
- 操作審核：誰/何時/什麼設置,在SE期間嘗試遊戲/存款。
- 確認：登記處的登記收據，個案ID。
回避：不少於監管機構規定的期限（通常為5-7年）；嚴格使用RBAC/ABAC訪問。
8）傷害標記和執法措施
金融：損失/存款快速增長，撤銷，貸款方法。
行為：夜間馬拉松，投註速度上升，重復「接近極限」。
通訊：要求取消限制，財政困難的跡象。
社會線索：「玩弄結清債務」。
升級：從軟接觸→時間限制→ RG鎖定→（如有必要）通知監管機構/註冊表。
9）付款和調查結果
任何主動限制都禁止新存款。
結論：按策略處理（誠實收回資產負債表，AML/RG驗證，不進行分流）。
Chargeback/disputs-根據合同和法律；文檔是強制性的。
10）通訊（無壓力和拉開）
SE確認： "在［日期］之前，您的自我排斥是活躍的。我們已經關閉了遊戲和郵件的訪問，以便您暫停"
嘗試登錄到SE： "帳戶限制為［日期］。以下是支持資源和時間表信息"
提前退貨請求： 「只有在冷卻期之後才能放寬限制。」
AML鎖定：使用中性語言「標準安全檢查」，沒有懷疑的跡象。
11）報告和合規性
事件/註冊表發送截止日期日歷；核實收據。
報告格式（CSV/XML/JSON/XLSX）和模式控制（驗證器）。
數據核對：錢包/GL ↔ RG 報告/SE註冊表；差異>X%是事件。
存儲監管機構接收報告的確認。
12）Dashbord和KPI/KRI
SE Coverage：活動SE/超時比例。
時間到塊：從玩家請求到實際鎖定的中位數（目標是瞬間）。
Suppression Integrity：所有營銷/存款渠道都已關閉的SE玩家百分比。
Attempts During SE：入場/存款嘗試次數-UX控制和通知。
回歸After Cooldown：SE結束後的回報份額及其行為。
Registry Sync SLA：同步/確認的及時性。
Complaints/Disputes：通過SE的上訴,在X天≤解決的比例。
審計發現/重復：重復性缺陷。
13）支票單
發射前
- UX流「超時/SE/重新激活」 ≤ 3次點擊；案文已經商定。
- 集成：SE註冊表、遊戲提供商、PSP、CRM支持。
- Logi是不可改變的，CI報告計劃的驗證者。
- CS和FAQ腳本已發布；團隊訓練有素。
- 保留/隱私政策（DPO）已獲得批準。
操作
- 任何SE請求都是即時申請和收據。
- 緩解-僅在冷卻和確認之後。
- 投訴/上訴-及時記錄和答復。
- 市場營銷/PSP的支持檢查-按計劃進行。
審核和控制
- SE/鎖定案例及其工件的季度樣本。
- GL/錢包/CRM對賬；差異-CAPA。
- 通過策略更新對RG事件進行復古。
14）模板（快速插入）
A）超時確認
B）自我體驗確認
C）對提前撤回請求的答復
D）通知附屬機構
E）在SE期間嘗試存款時的消息
15）法律和隱私
處理理由：RG/SE的合法利益/法律義務；報告的文件流程。
DSAR：在不影響第三方調查/保護的情況下提供信息；SE數據-考慮本地規範。
跨界性：合同保障和最小化。
可用性和本地化：市場語言接口和信件，可用格式。
16）技術實現（骨架）
API RG/SE: `POST /cooloff`, `POST /self-exclusion`, `GET /restrictions`, `POST /reactivation-request`.
События: `se_activated`, `se_registry_synced`, `deposit_blocked`, `marketing_suppressed`, `reactivation_cooldown_passed`.
策略引擎：冷卻規則,suppression, PSP/遊戲單元。
DQ/驗證：多用戶環境中的狀態完整性；報告的一致性。
監視：不同步時的變量（註冊表/aggregator/PSP/CRM）。
17）頻繁的錯誤以及如何避免錯誤
復雜的SE線程。→減少步驟，帶入頭部/配置文件。
取消限制而無需冷卻.在策略引擎中→強制.
市場營銷正在「滲出」。→單個支持標誌和夜間檢查。
沒有文物。在註冊表ID上→強制性收據和鏈接。
提供商/PSP的不同狀態。→定期對賬和自動還原。
18）相互關系
負責任的遊戲和限制-政治和傷害標記。
事件花花公子和腳本-RG事件/通知。
監管報告和格式-上載和收據。
道德和行為準則是正確的溝通。
員工對合規性/AML培訓的認識-CS/CRM/風險培訓。
反腐敗政策-與登記處/機構的互動。
19）實施計劃（30天）
第一周
1.批準SE/鎖定策略（類型、時間表、冷卻、通信）。
2.專門介紹數據/事件模型和RACI。
3.準備UX布局和文本（關鍵位置）。
第二周
4.實現約束和支持輪廓API （遊戲/PSP/CRM）。
5.連接SE註冊表；配置格式/收據驗證器。
6.培訓CS/CRM；發布腳本和常見問題解答。
第3周
7.飛行員（5-10％）：檢查鎖定，嘗試存款，分步。
8.冷藏/重新激活測試，手動案例驗證。
9.收集支架,更新文本/規則。
第四周
10.完整發行；監視KPI和辛卡變量。
11.向管理層報告；CAPA偏差。
12.計劃v1。1：擴大本地集成/註冊表，增加情景。
Shpargalka「明天該怎麼做」（用於CS/CRM）
對於任何自我排除請求，→立即激活SE並發送確認。
從不建議「改變主意」；不要給獎金/折扣。
檢查營銷和存款單位。
對於延遲結論的任何問題，請中立回答（「安全檢查」）。
所有活動均以ID文物/收據記錄。