操作和合規性→制裁篩選和PEP過渡

制裁篩選和PEP過渡

1）目的和領域

減少法律/財務風險並確保許可證合規性：清除制裁人員/組織，識別PEP和相關人員，考慮負面媒體並按比例采取行動。它適用於可訪問PDn/財務的玩家（KYC），合作夥伴（KYB），提供商和員工。

2）術語和範圍

Sanctions（制裁）：禁止/限制與個人/組織/法院/法院的互動。
PEP（政治暴露人員）：公職人員及其最親密的聯系人（RCA）。
廣告媒體：基本負面出版物（金融犯罪，腐敗等）。
匹配：配置文件條目與列表項（準確/概率）匹配。
RCA（Relatives＆Close Associates）：配偶（a），子女，商業夥伴等。

3）原則

1.基於風險的Approach（RBA）：檢查的深度和頻率取決於風險概況（國家/地區，支付方法，金額，角色）。
2.可解釋的匹配：比較規則是透明的；保留該決定的理由。
3.逐項設計：每個「命中/未命中」都伴隨著人工制品。
4.Privacy-first：最低限度PDn，嚴格的可訪問性，根據法律進行重建。
5.連續放映：事件→立即重新放映；定期-batch檢查。
6.真相的一個來源：一個單一的篩選結果和決策登記冊（審計步道）。

4）來源和更新

制裁和管制清單：全球/區域/國家；工業/地區；承運人/船舶清單（如有必要）。
PEP/RCA：多層次（國家/區域/國際）。
廣告媒體：具有風險分類的匯總來源。
更新：每日/每周；保存目錄版本和下載時間。

5）篩選政策（框架）

當我們檢查時：註冊,第一次存款/退出之前,當更改支付詳細信息,達到營業額閾值,當更改配置文件/地址/文件,更新列表。
我們檢查誰：玩家（KYC），合作夥伴/提供商（KYB），可訪問員工（HR/KC）。
匹配時要做什麼：三重奏→確認/排除/升級→措施：拒絕/保留/EDD/關閉。

yaml policy_id: SANC-PEP-POL-001 scope: players, partners, employees triggers:
- on_event: signup, pre_deposit, pre_payout, kyc_update, payout_destination_change
- on_list_update: sanctions    pep    adverse_media risk_bands:
low: [EU_ trusted methods]
high: [high_risk_geo, multiple_payment_methods, turnover>threshold]
actions_by_match:
sanctions_confirmed: block_all & report & freeze_payouts pep_confirmed: edd & enhanced_monitoring adverse_media_high: manual_review & edd review_sla_days: 180 owner: head_of_compliance

6）匹配算法（匹配）

精確匹配：FIO+DR/文件/國家/地區。
Fuzzy匹配：標記化，歸一化，音譯/alias，行距；語音學（例如Soundex/Metaphone類似）。
上下文權重：出生日期>國籍>地址>alias>國家/地區。
減少虛假匹配：「必須擁有」字段，在名稱類型上相似的閾值，忽略頻繁出現的單詞。
地質敏感性：對於高風險的地質,低於fuzzy-scor的閾值。
白名單到期：臨時豁免（whitelist），原因和期限。

7）重構觸發器

更新列表版本。
配置文件事件：更改FIO/地址/文檔,新的輸出方法。
閾值/營業額，限額增加，貴賓身份。
AML/風險信號： velocity 、源到源不匹配、設備/IP異常。

8）集成和數據

KYC/KYB：IDV/基準/註冊提供商；UBO/主任與合作夥伴。
Payments：「pre-payout」塊和保存/反向匹配。
案例管理：比賽卡，狀態和決策日誌。
DWH/BI：按熱量/精確/質量漂移的店面。

9）控制即代碼（片段）

yaml control_id: SANC-PEP-SIGNUP scope: player_profile trigger:
expr: event in {signup, pre_deposit, pre_payout}
actions:
- screen: sanctions    pep    adverse_media
- block: payout if match_score>=0. 85 until triage_done evidence:
fields: [list_version, query_payload, top_matches]
owner: compliance_ops

yaml control_id: SANC-PEP-RESCREEN scope: population trigger:
expr: sanctions_list. version_changed==true OR pep_list. version_changed==true actions:
- enqueue: rescreen_batch(population_segments=[high_risk, active_payouts])
- notify: compliance_channel

yaml control_id: PEP-MONITOR-01 scope: players trigger:
expr: pep_status==confirmed actions:
- require: edd & source_of_funds
- monitor: payouts frequency>=weekly
- set: limits=pep_limits_schema

yaml control_id: ADV-MEDIA-HI scope: players    partners trigger:
expr: adverse_media. severity in {high, severe}
actions:
- flag: manual_review
- limit: payouts "hold_24h"
- collect: additional_evidence

10）SOP（片段）

SOP： 制裁重合/RER三合會

1.檢查上下文：FIO/DR/公民身份/alias/文檔。
2.核對來源（id記錄、更新日期、法律地位）。
3.解決方案：「confirmed/ false_positive/inconclusive」。
4.對於「confirmed」：應用措施（block/EDD/report），提交理由。
5.對於「inconclusive」：請求補充數據。（文件/地址確認）。
6.關閉案例,更新whitelist/blacklist（如果適用）,並附上evidence。

SOP： 更新列表時重新剪輯

1.自動啟動蹦床，細分：主動支付，高風險。
2.新比賽報告，SLA案例分配。
3.間接鏈接帳戶（RCA）-單獨排隊。

SOP： 與玩家/合作夥伴溝通

1.中性措辭，不透露內部標準。
2.請求文檔的時間表和列表（如果需要EDD）。
3.將通信固定在案例中，提醒和截止日期。

11）隱私、安全、審計

RBAC/ABAC：僅在Compliance/MLRO中訪問比賽細節和文檔。
重組：按管轄期限保留結果和事件；自動清洗。
加密：in transit/at rest；HSM/Vault中的密鑰。
審計：閱讀/決策日誌，規則/閾值版本，自動測試結果。

12） Dashbords和指標

Screening Overview：檢查量,按細分市場排名最高,分布模糊。
Quality： Precision/Recall確認的案例,False Positive Rate, Time-to-Triage （P50/P95）。
Latency：提供者的響應時間,重新映射隊列。
漂移：更改名稱/地理分布,增加不確定的匹配比例。
合規性：在報告和升級方面遵守SLA。

• 精密制裁≥ 95％，PEP ≥ 90％。
• 時間至三位一體（P95）≤ 24小時（制裁），≤ 48小時（PEP/adverse）。
• False正率↓ QoQ而不會丟失Recall。
• 更新列表的SLA在截止日期≥ 98％。
• Evidence Completeness ≥ 98%.

13）支票單

• 列表源是連接的，版本是合成的。
• 澳洲聯儲政策獲得批準，模糊閾值一致。
• Triage進程和角色（Compliance/MLRO）已分配。
• 集成：KYC/KYB/Payments/Case-tool。
• 部署了Dashbords和Alertes。

• 關鍵字段（FIO/DR/公民身份/alias）進行了比較。
• 已驗證記錄的來源和日期。
• 決定和措施已經記錄；已發出通知。
• Evidence隨附,whitelist/blacklist已更新（如果需要）。

• 規則/閾值自動測試通過。
• 季度解決方案審計（采樣）。
• 漂移監測是正常的；修訂門檻。

14）反模式

不考慮地理和數據質量的「所有人的一個閾值」。
沒有記錄列表版本和決策依據。
永久永久性白人主義者，沒有截止日期和原因。
真理的兩個版本：Excel解決方案和銷售中的單個日誌。
沒有ETA和通信的不合理付款延遲。
在更新列表時禁用重新映射。

15）30/60/90-計劃

• 批準SANC-PEP政策，匹配閾值，角色和SLA。
• 連接列表提供商；編寫「list_version」。
• 包括三個基本控制：「SIGNUP」，「PRE_PAYOUT」，「RESCREEN」。
• 部署案例管理、dashbords和evidence存儲。

• 添加RCA/advers媒體，高風險細分市場和VIP。
• 優化fuzzy（音譯/alias），將FPR降低≥ 20％。
• 自動對事件和列表更新進行重新映射。
• 包括質量采樣和季度審核。

• 實現目標KPI Precision/Recall和Time-to-Triage。
• 與AML（EDD/SoF）和付費門（源到源）集成。
• 將KPI納入團隊的OKR，進行外部/內部審核。

16) FAQ

問：如何區分同名與真正的匹配？
A：使用確認字段（DR/文件/公民身份），地質和aliasa上下文；邊境-手動三重奏，有信心門檻。

問：是否需要篩選會員及其UBO？
A：是的。KYB具有約束力：UBO/董事+制裁/RER+負面媒體；當UBO發生變化時-重新驗證和重新映射。

問：經確認的制裁該怎麼辦？
答：立竿見影,免除付款,就司法管轄區要求向監管機構/銀行發出通知,保留完整的一攬子計劃。

問：如果有制裁，為什麼要廣告媒體？
答：這通常是早期風險信號（制裁之前）。用於EDD/監控和預防性限制。