驗證玩家的財務可用性
驗證玩家的財務可用性（Affordability）
1）目的和領域
確保遊戲符合玩家的財務能力，降低傷害風險並遵守許可要求。Affordability補充了RG和AML：我們評估玩家在不損害的情況下承擔遊戲成本的能力（不要與資金來源檢查相混淆，盡管案例經常重疊）。
覆蓋範圍：產品（web/mobile），錢包/PSP，Risk/RG，CS，Compliance/Legal/DPO，遊戲提供商，報告。
2）原則
比例性：檢查深度對應於風險水平和市場。
最起碼所需的信息：我們只要求提供解決方案所需的信息。
透明度和尊重：可理解的請求原因和預期文件/時間表。
沒有AML：在措辭中，我們避免暗示懷疑。
可證明性：所有步驟和決定都被記錄下來，文物被卡住了。
按設計保密：GDPR/本地對應項，RBAC存儲和訪問。
3）角色和RACI
Affordability Owner（RG Lead/Risk Lead）-政策，閾值，升級。(A)
Risk Analysts（第一線/第二線）-驗證，證據請求，解決方案。(R)
CS/CRM-通訊，玩家護送，SLA響應。(R)
Payments/Finance是檢查期間存款/結算的塊/限制。(R)
法規遵從性/法律性/DPO-市場合規性、隱私性、模板。(C)
Data/Engineering-事件/邏輯、集成（銀行API、驗證器）。(R)
內部審核是對實踐和樣本的獨立評估。(C)
Exec Sponsor（COO/CEO）-「tone from the top」資源。(I/A)
4）觸發啟動檢查（骨架）
財務：- 大型一次性存款（市場門檻）。
- 短期內存款/損失數額迅速增加。
- 經常取消調查結果；轉向「杠桿」支付方法。
- 夜間/長時間，加速投註，多個RC不間斷。
- 玩家關於財務困難的報告。
- 通過市場/許可證達到需要EDD/affordability的閾值。
- 風險等級增加（RG/AML scores）。
5）數據和證據（級別）
A級-易於驗證（最低限度）：- 自我公布娛樂/收入預算（產品中的形式）。
- 匯總銀行/金融科技對賬單（無額外細節）或收益證明。
- 就業證明/身份證明（根據市場要求）。
- 90天的銀行對賬單（塗抹了不相關的字段）。
- 收入文件：雇主證明，稅單，合同/發票（自營職業者）。
- 按主要類別分列的支出申報（住房/貸款/贍養費）。
- 確認資金/資產來源（出售財產、股息等）。
- 開放銀行API（開放銀行）是償付能力的集合度量（同意和允許性）。
- Dop。按市場/監管機構要求提供的文件。
6）估計值和閾值
Net Disposable Income （NDI）：基本支出後估計的「免費」收入。
Affordable Loss/Budget：允許娛樂的NDI份額（內部政策+本地規範）。
- 綠色-沒有限制或預算寬松。
- 琥珀色-存款/損失限制，監控。
- 紅色-故障/硬限制/超時/SE。
- 損失>Amber → 30天估計的NDI的X%。
- 損失>Y% NDI或有毒標記→紅色。
7）過程（從信號到解決方案）
步驟1-信號和預刮板。事實收集（總和/時間，RG標記），優先權分配（S1.. S3），案例系統中的固定。
步驟2-請求證據。級別選擇（A/B/C），可理解的文檔列表，截止日期（通常為7-14天），必要時臨時限制/暫停。
步驟3-分析。NDI/預算計算，收入/支出可持續性檢查，行為交叉檢查。
步驟4-解決方案。Green/Amber/Red，設置限制/鎖定，修改時間表。
步驟5-溝通。無壓力的中性文本，沒有AML潛臺詞。
步驟6-文檔。工件，計算，屬地，策略引用/本地規範。
步驟7-修訂。在N天後或在風險發生變化時重新審查。
8） UX和正確的文本
文件查詢（中性）：避免使用懷疑語言/AML；使用中立的「成本安全/舒適性檢查」。
9）與RG和AML的互動
RG：傷害標記增強了輔助性，解決方案→ 限制/超時/SE的優先級。
AML：如果在流程中出現資金來源風險，則打開並行AML案例（在關聯通信中不加壓）。
Payments：在檢查期間重復存款/營銷塊。
10）隱私，權利和寬容
處理依據：法律義務/合法利益（球員的安全和執照）。
最小化和掩蔽：僅收集必需品,刪除EXIF,關閉敏感字段。
訪問：RBAC/ABAC，讀/更改日誌，WORM文物存儲。
Retentia：通常為5-7年或市場/許可；過期後-安全刪除。
主體權利：通過DPO進行DSAR；不透露防凍技術/得分和第三方數據。
11） Dashbord和指標
時間到決策（TTD）：從信號到解決方案的中位數。
Completion Rate：按時收到的文檔的百分比案例。
Amber/Red Rate：按細分/市場劃分的解決方案份額。
Repeat Harm Markers：決定後30/90天的傷害標記。
Limit Uptake/Adherence：遵守限制的比例。
Complaints&Resolution：投訴/截止日期。
Data Sufficiency：收集最小證據的案例百分比。
Auditability：具有完整工件包和NDI計算的案例份額。
12）支票單
在啟動策略之前
- 市場閾值與Legal/Compliance保持一致。
- 電子郵件模板已本地化並經過中性驗證。
- 與文檔存儲庫，開放銀行（可用），案例系統集成。
- EXIF偽裝/刪除程序，格式驗證。
- CS/FAQ腳本；培訓已完成。
在操作中
- 每個案例都有優先級、所需文檔列表和截止日期。
- 時間限制/鎖定將自動激活。
- 解決方案記錄在計算和政策參考中。
- 包括相鄰的RG/AML/營銷支持標誌。
審核和改進
- 按決定的完整性/合乎邏輯性對案件進行季度抽樣（≥ 30）。
- 將事件日誌與錢包/GL核對。
- CAPA關於重復的言論。
13）模板（快速插入）
A）文件清單（B級）
B）截止日期提醒
C）限額解決方案
D）無文檔關閉
14）技術實現（骨架）
События: `affordability_triggered`, `docs_requested`, `docs_received`, `affordability_decision{green|amber|red}`, `rg_limits_set`, `marketing_suppressed`.
API кейс-системы: `POST /affordability/case`, `PATCH /case/{id}/status`, `POST /case/{id}/decision`.
文檔存儲：加密；自動偽裝，EXIF脫衣舞；校驗和和WORM日誌。
規則（政策引擎）：市場閾值、SLA、檢查期間的自動聚合物。
報告：CSV/JSON卸載沒有PII的單元。
15）頻繁的錯誤以及如何避免錯誤
冗余文檔請求。→ A/B/C級別，最小化，解釋「原因」。
未采取臨時措施的延遲。在打開案件時→自動石。
模糊文本.→現成的模板,可理解性測試.
在信件中與AML混合。→中性表述，必要時單獨的AML案例。
無計算.→標準化NDI/預算方法並存儲計算。
不完全同步.→將解決方案鏈接到CRM/PSP/遊戲提供商 （suppress/blocks）。
16）區域配置文件（要填充的框架）
每個市場記錄：強制閾值、數據源、開放銀行允許性、反應時間表、報告格式、存儲/本地化要求。
Profile [Market]
Thresholds:...
Sources: self-declaration banking API docs
Terms: ack ≤...; decision ≤ …
Solutions: green/amber/red - parameters
Reporting: Frequency/Format
Privacy: local requirements17）30天實施計劃
第一周
1.批準相關政策和市場門檻。
2.協調通信模板（RU/EN+locales）和FAQ。
3.特定事件/數據和集成模型（案例、存儲、開放銀行可用）。
第二周
4.實現案例流、驗證期的自動解碼、文檔下載/偽裝。
5.在活動情況下連接營銷支持/PSP。
6.培訓Risk/CS；發行1頁和宏。
第3周
7.試點（5-10%）： TTD/Completion/Complaints,手動修訂解決方案。
8.調整閾值/文本,調試集成。
第四周
9.完整發行；每日KPI監控和選擇性咆哮。
10.向管理層報告；CAPA的失敗和投訴。
11.計劃v1。1：擴大市場概況，增加開放銀行/計分，自動計算NDI。
- 負責任的遊戲和限制
- 自我排斥和帳戶鎖定
- 現實檢查和遊戲提醒
- 事件花花公子和腳本（RG/AML）
- AML培訓和員工培訓/員工合規意識
- 違規通知和報告時限
- 監管報告和數據格式
- 內部審計和外部審計/審計清單