GH GambleHub

付款制裁合規性

1)為什麼需要它(風險框架)

法律風險:違反制裁制度的罰款/吊銷許可證。
財務風險:凍結走廊上的資金/賬戶(記者/PSP/計劃)。
操作風險:不可抗力退款,掛起交易,手動檢查的增加。
聲譽:「制裁」事件打擊了合作夥伴銀行和進入走廊的通道。


2)制度和原則

列表包括:OFAC(SDN/SSI),EU,UK(OFSI),CA,AU,UN,本地。
地理禁運:國家/地區的全面禁令。
部門:行業限制/融資期限(SSI/Directive)。
「50%規則」:如果一個或多個的SDN合計擁有≥50%,則即使未命名,該主題也被視為被阻止。
出口/管制/雙重用途:違禁貨物/服務的付款(重要的是A2A/SWIFT安排)。
加密/旅行規則:跨境轉移中VASP之間的KYC屬性的轉移。


3)在何處以及如何篩選(付款回路)

3.1.存款

付款人:姓名/地址/出生日期(如果可用),地圖(BIN-geo),錢包,IP/ASN,設備。
提供者:PSP/MID及其管轄權;檢查路線的「純度」。
事件:創建配置文件(L0),第一存款(L1),異常(velocity/地理沖突)。

3.2.四.結論

受益人:IBAN/BIC/名稱/地址,卡/錢包,加密地址(VASP)。
路線:same-method/return-to-source,接收銀行,可能的通訊員。
旅行規則(加密):交換起源/beneficiary數據,檢查VASP狀態。

3.3.路由/走廊

A2A/SEPA/FPS/PIX/RTP:接受銀行及其國家/銀行風險。
推到卡:發卡銀行(BIN國家/銀行)。
SWIFT:代理銀行(鏈條的所有環節)。
電子錢包:錢包發行人/運營商的管轄權。


4)篩選類型和信號

名稱/alias/音譯(fazzi匹配,變音符號還原)。
地址/城市/郵政編碼(地理觸發器,「制裁」位置)。
出生日期/護照/MRN(可從KYC獲得)。
組織/受益人(UBO):高級盡職調查。
IBAN/BIC和接收銀行:國家,「制裁銀行」或UBO子組合。
BIN/發卡人:國家/銀行,帶有雪橇清單的交叉檢查。
IP/ASN/VPN/托管:地理,代理/影子ASN。
Device-graph/household:與先前鎖定的交叉點。
加密地址:區塊鏈提供商的「制裁/混合器/風險集群」標簽。
地理沖突:KYC國家≠ IP ≠ SIM ≠ BIN地質。


5)篩選編排: 「嵌入的地方」

1.登船:名為/DR,鄉村風險的輕松篩選。
2.付款原件:同步命中檢查付款人/受益人,IBAN/BIN, IP/ASN。
3.在發送到走廊之前進行預路由:deny/hold/step-up (SoF/documents)。
4.飛行中:監視PSP/銀行的狀態(返回/持有)。
5.事件後:更新列表(backfill)時的回顧性重新映射。


6)決策策略(基於風險)

AUTO-PASS: 沒有熱門歌曲;國家/銀行風險低;same-method;ND≥0.

MANUAL REVIEW: fuzzy命中率低於高閾值;新受益人;地質沖突;高的國家/部門風險。
DENY/BLOCK:精確的SDN命中,「50%規則」,GEO禁運,制裁銀行/走廊。
STEP-UP:SoF/SoW查詢,受益人地址/名稱的確認,「名稱/IBAN」(可用)。


7)減少誤報(precision)

FIO正常化(名稱/姓氏排列,中間名,大小寫,粒子)。
上下文屬性:出生日期/城市降低FPR。
白名單:經驗證的受益人/銀行/IBAN(具有TTL和重新認證)。
ASN/VPN黑名單:在IP上減少噪音點擊。
分段閾值:高風險GEO/走廊更嚴格,低風險更溫和。
手動APPROVE後自動分辨率,具有相同的fingerprint (設備/IBAN)。
可解釋性日誌:為什麼拒絕/允許(score,規則,匹配字段)。


8) UX和通信

透明的原因: 「由於銀行/國家/地區,需要對接收者進行驗證。」

時間:手動檢查/SoF的誠實ETA。
退款:自動重新裝入遊戲錢包,鏈接「選擇不同的方法/收件人」。
本地化:法律文本,指制裁政策/支持。


9)工程: 數據模型(最小值)

sql sanctions.watchlists (
source TEXT,      -- OFAC, EU, UK, UN, etc.
entity_id TEXT,    -- уникальный ID записи entity_type TEXT,   -- person    org    vessel    bank name TEXT, aliases TEXT[], dob DATE, country TEXT,
programs TEXT[],    -- санкционные программы ownership_json JSONB, -- связи для "50% правила"
updated_at TIMESTAMP
);

sanctions.hits (
hit_id PK, user_id, payout_id, deposit_tx_id,
entity_id, source, match_score NUMERIC, match_fields JSONB,
status TEXT,      -- OPEN    APPROVED    DENIED    ESCALATED    FALSE_POSITIVE reviewer TEXT, decided_at TIMESTAMP, created_at TIMESTAMP
);

payments.endpoints (
beneficiary_id PK, user_id, type, -- IBAN    CARD    WALLET    CRYPTO iban TEXT, bic TEXT, bin TEXT, wallet_ref TEXT, crypto_addr TEXT,
bank_country TEXT, bank_name TEXT, verified BOOLEAN,
last_screened_at TIMESTAMP, risk_tags TEXT[]
);

risk.context (
user_id, ip INET, asn INT, device_hash TEXT,
geo_ip TEXT, geo_kyc TEXT, geo_sim TEXT, updated_at TIMESTAMP
);

10)Pseudo-DSL政策

yaml policy: "sanctions_payments_v4"
lists:
sources: [OFAC, EU, UK, UN, CA]
refresh_interval_hours: 6 screening:
on_user_create: true on_deposit_init: true on_payout_init: true on_new_beneficiary: true rescreen_on_list_update: true thresholds:
name_fuzzy_pass: 0.72 name_fuzzy_manual: 0.62 org_fuzzy_pass: 0.80 crypto_risk_max: "MEDIUM"
routing_guards:
deny_if:
- geo in [EMBARGOED]
- bank_sanctioned == true
- ownership_sdn_agg >= 0.5  # "50% правило"
manual_review_triggers:
- fuzzy_hit == true
- new_beneficiary == true AND amount > 1000 EUR
- geo_conflict_score >= 2
- vasp_untrusted == true stepups:
- if: payout_amount > 2000 EUR then: ["name_check_iban"]
- if: crypto == true then: ["travel_rule", "beneficiary_vasp_check"]
audit:
store_feature_snapshot: true store_decision_tree: true exceptions:
whitelist_beneficiary_ttl_days: 180

11) SQL模板

11.1.按名稱/aliasam進行的fazzi搜索

sql
SELECT w.entity_id, w.source, w.name,
similarity(unaccent(lower(:full_name)), unaccent(lower(w.name))) AS score
FROM sanctions.watchlists w
WHERE w.entity_type='person'
AND (unaccent(lower(:full_name)) % unaccent(lower(w.name))
OR EXISTS (SELECT 1 FROM unnest(w.aliases) a
WHERE unaccent(lower(:full_name)) % unaccent(lower(a))))
ORDER BY score DESC LIMIT 20;

11.2.檢查占有「50%規則」

sql
SELECT entity_id
FROM sanctions.watchlists
WHERE entity_type='org'
AND (ownership_json->>'sdn_agg_share')::numeric >= 0.5;

11.3.更新列表時重新映射觸發器

sql
INSERT INTO sanctions.hits (user_id, entity_id, source, match_score, status, created_at)
SELECT u.user_id, w.entity_id, w.source, 0.0, 'OPEN', now()
FROM users u
JOIN sanctions.watchlists w ON w.updated_at >:last_run
WHERE u.country IN (:risk_geos);

11.4.IBAN/接受銀行:風險誇德

sql
SELECT e.beneficiary_id,
(e.bank_country = ANY(:embargo_geos)) AS embargo_hit,
(e.bic IN (SELECT bic FROM ref.sanctioned_banks)) AS bank_hit
FROM payments.endpoints e
WHERE e.beneficiary_id=:bid;

11.5.加密旅行規則(簡化控制)

sql
SELECT v.vasp_id, v.trust_level, tx.crypto_addr
FROM crypto.transfers tx
JOIN ref.vasps v ON v.domain = tx.beneficiary_vasp
WHERE tx.payout_id =:pid;

12) KPI和dashbords

False Positive % и Manual Approve %.

命中率:具有制裁命中率的交易/受益人份額。
手動TAT p 50/p95(解決時間)。
按模式/地理/走廊/銀行評定百分比。
更新列表後,Rescreen backlog。
PSP/銀行的雪橇代碼返還/持有人百分比。
旅行規則覆蓋%(加密)。
Whitelisted TTL breach%(未重新驗證的「可信」突破)。


13)Alerta

List Update Spike:更新列表後點擊量急劇增加。
FPR Surge: False Positive%> d/d閾值。
Manual Backlog:開放案例>限制或p95 TAT> SLA。
Embargo Route Hit:試圖向被禁止的地球/銀行付款。
旅行規則丟失:不使用VASP數據交換的加密翻譯。
Policy Drift:沒有規則/解決方案快照的交易。


14)事件花花公子

A. OFAC/EU更新後的巨大打擊

1.凍結風險走廊上的自動漫遊→ MANUAL。
2.總和優先級/ETA,對新alias/拼寫操作員進行快速培訓。
3.PSP/銀行通信:警告手動的暫時增長。

B.代理銀行的退款

1.規範原因代碼,收集樣本(BIC,走廊)。
2.暫時從級聯reroute中排除銀行/走廊。
3.Mortem:更新「sank-bank」手冊,加強預處理。

C.沒有旅行規則的Crypto

1.阻止未經驗證的VASP上的推斷,請求數據。
2.在修復集成之前啟用「僅受信任的VASP」。
3.必要時向監管機構轉發和報告。


15)最佳實踐(簡稱)

1.具有特質/解決方案版本和快照的策略代碼。
2.多點篩選(配置文件,init, pre-route, post)。
3.考慮到50%的規則和UBO鏈接,而不僅僅是唱名記錄。
4.名稱規範化和上下文(DR/City)以降低FPR。
5.經驗證的受益人/銀行白名單,具有TTL和重新認證。
6.通過GEO/方法/走廊劃分閾值。
7.可解釋性日誌和審計跟蹤:「誰/何時/為什麼」。
8.與PSP/銀行協商退貨代碼和 SLA手動。
9.旅行規則和VASP信任加密註冊表。
10.定期的事件後和規則調整。


16)實施支票

  • 清單來源和刷新率(OFAC/EU/UK/UN/本地)。
  • 「50%」政策和UBO圖。
  • 在onboarding/deposit/payout/new beneficiary/rescreen上進行篩選。
  • 整合:PSP/銀行/wasps,退貨代碼。
  • 閾值矩陣(pass/manual/deny),GEO/方法段。
  • 帶有TTL的白色/黑色列表(beneficiary/bank/ASN/IP)。
  • 可解釋性,特征/解決方案快照,許可證報告。
  • KPI和Alerta的Dashbords;SLA手動。
  • 花花公子(列表更新,退貨,旅行規則)。
  • 操作員培訓(alias/音譯,鄉村稀有)。

二.總結

對付款的制裁合規性是規則,數據和路線的編排,而不僅僅是「打破名單」。將篩選嵌入支付路徑的關鍵點,考慮UBO和50%的規則,管理走廊/銀行,通過正常化和上下文減少誤報,將可解釋的決策和策略版本存儲為代碼。因此,您可以保留走廊的訪問權限,降低交易成本,並滿足許可證要求而不會殺死轉換。

Contact

與我們聯繫

如有任何問題或支援需求,歡迎隨時聯絡我們。我們隨時樂意提供協助!

開始整合

Email 為 必填。Telegram 或 WhatsApp 為 選填

您的姓名 選填
Email 選填
主旨 選填
訊息內容 選填
Telegram 選填
@
若您填寫 Telegram,我們將在 Email 之外,同步於 Telegram 回覆您。
WhatsApp 選填
格式:國碼 + 電話號碼(例如:+886XXXXXXXXX)。

按下此按鈕即表示您同意我們處理您的資料。