支払い制裁の遵守
1)なぜ必要なのか(リスクボックス)
法的リスク:制裁制度の違反のための罰金/ライセンスの取り消し。
財務リスク:通路上の資金/口座の凍結(特派員/PSP/スキーム)。
オペレーショナルリスク:不可抗力の返品、取引の停止、手動チェックの増加。
評判:「認可された」事件はパートナーバンクと廊下へのアクセスを襲いました。
2)モードと原則
リスト:OFAC (SDN/SSI)、 EU、イギリス(OFSI)、 CA、 AU、国連、ローカル。
Geo-embargo:国/地域による総禁止。
セクター別:業界/期間制限(SSI/指令)。
「50%ルール」:1つ以上のSDNが合計≥ 50%を所有している場合、名前が付けられていなくてもエンティティはブロックされていると見なされます。
輸出管理/二重目的:禁止されている製品/サービスの支払い(A2A/SWIFT送金で重要)。
Crypto/Travel Rule:クロスボーダー転送におけるVASP間のKYC属性の転送。
3)どこで、どのように画面に(支払いループ)
3.1.デポジット(預金)
支払者:名前/住所/生年月日(利用可能な場合)、カード(BIN-geo)、ウォレット、IP/ASN、デバイス。
提供者:PSP/MIDおよびその管轄;ルートの「清潔さ」のチェック。
イベント:プロファイル作成(L0)、最初の預金(L1)、異常(速度/ジオコンフリクト)。
3.2.結論は次のとおりです
受益者:IBAN/BIC/名前/アドレス、カード/ウォレット、暗号アドレス(VASP)。
ルート:同じ方法/リターンツーソース、受信者銀行、可能な特派員。
旅行ルール(暗号):発信者/有益なデータの交換、VASPステータスのチェック。
3.3.ルーティング/通路
A2A/SEPA/FPS/PIX/RTP:受取銀行とその国/リスク。
プッシュツーカード:カード発行銀行(BINカントリー/銀行)。
SWIFT:対応銀行(すべてのチェーンリンク)。
Eウォレット:発行者/財布オペレーターの管轄。
4)スクリーニングのタイプおよび信号
名前/エイリアス/転写(ファジーマッチ、ダイアクリティクスの減少)。
住所/都市/郵便番号(ジオトリガー、「認可された」場所)。
生年月日/パスポート/MRN (KYCから入手可能な場合)。
組織/受益者(UBO):拡張デューデリジェンス。
IBAN/BICと受信銀行:国、「制裁銀行」またはサブ制裁UBO。
BIN/カード発行者:国/銀行、そりリストとのクロスチェック。
IP/ASN/VPN/hosting: sank geo、 proxy/shadow ASN。
デバイスグラフ/世帯:以前にロックされていたとの干渉。
暗号アドレス:ブロックチェーンプロバイダーのタグ「制裁/ミキサー/リスククラスター」。
Geo-conflict: KYC country ≠ IP ≠ SIM ≠ BIN geo。
5)スクリーニングオーケストレーション: 「埋め込む場所」
1.オンボーディング:名前/DRによる簡単なスクリーニング、カントリーリスク。
2.支払のinit:同期ヒットチェックの支払者/受益者、IBAN/BIN、 IP/ASN。
3.プリルーティング:廊下に送信する前にdeny/hold/step-up (SoF/documents)。
4.機内:PSP/バンクからのステータス監視(返品/保留)。
5.Post-event:リストを更新するときに再検討する(backfill)。
6)意思決定方針(リスクベース)
AUTO-PASS:ヒットなし;低カントリー/銀行リスク。same-method;ND ≥ 0。
マニュアルレビュー:高しきい値の下にファジーヒット。新しい受益者;geo-conflict;高い国およびセクターの危険。
DENY/BLOCK:正確なSDNヒット、「50%ルール」、GEO禁輸、制裁銀行/回廊。
STEP-UP: SoF/SoWリクエスト、受益者アドレス/名前確認、「name check/IBAN」(利用可能な場合)。
7)偽陽性の低減(精度)
フルネームの正規化(名前/姓の順列、後援、ケース、粒子)。
コンテキスト属性:生年月日/都市はFPRを削減します。
ホワイトリスト:検証された受益者/銀行/IBAN (TTLと再検証)。
ASN/VPNブラックリスト:IP上のノイズが少ない。
セグメントのしきい値:高リスクのGEO/廊下ではより厳しく、低リスクではより柔らかい。
手動で同じ指紋(デバイス/IBAN)でAPPROVEした後の自動解像度。
説明可能性ログ:拒否/許可された理由(速度、ルール、一致フィールド)。
8) UXとコミュニケーション
透明な理由: 「銀行/国のために受信者の検証が必要です。」
タイムライン:マニュアルレビュー/SoFのための正直なETA。
戻り値:ゲームウォレットへの自動リファンド、リンク「choose another method/recipient」。
ローカライズ:法的テキスト、制裁政策/サポートへのリンク。
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)疑似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.Fuzzy名前/エイリアスで検索
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.Crypto Travel Rule(簡易制御)
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とダッシュボード
ヒット率:認可されたヒットを持つトランザクション/受益者の割合。
False Positive%;マニュアル承認%。
手動TAT p50/p95(決定時間)。
Modes/Geo/Corridors/Banksによって%が拒否されました。
リストを更新した後、バックログを再表示します。
PSP/バンクからのサンカコードの%を返す/保持します。
Travel Ruleカバレッジ%(暗号)。
ホワイトリストTTL違反%(再検証なしで「信頼される」腐った)。
13)アラート
リストアップデートスパイク: リストアップデート後にヒットする
FPRサージ:偽陽性%>しきい値d/d。
手動バックログ:オープンケース>limitまたはp95 TAT> SLA。
エンバーゴルートヒット:禁止された地理/銀行で支払いをしようとします。
Travel Rule Missing: VASPデータ交換なしの暗号翻訳。
ポリシードリフト:ルール/ソリューションのスナップショットなしのトランザクション。
14)インシデントプレイブック
A。 OFAC/EUアップデート後の大規模なヒット
1.リスクコリドアの自動ルーティングをフリーズ→マニュアル。
2.量/ETAによる優先度、新しいエイリアス/スペルの演算子のための迅速なトレーニング。
3.PSP/バンクコミュニケーション:マニュアルの一時的な成長を警告します。
B。 Correspondent Bankによる返品
1.原因コードを正規化し、サンプル(BIC、回廊)を収集します。
2.一時的にカスケード、再ルーティングから銀行/廊下を除外します。
3.Post-mortem: 「sledge banks」のディレクトリを更新し、precheckを強化します。
旅行ルールのないC。 Crypto
1.検証されていないVASPのピンをブロックし、データを要求します。
2.統合が固定されるまで「信頼できるVASPのみ」を有効にします。
3.必要に応じて規制当局に再試行して報告する。
15)ベストプラクティス(短い)
1.バージョンと機能/ソリューションのスナップショットを含むポリシー・アズ・コード。
2.複数ポイントのスクリーニング(プロフィール、init、事前ルート、post)。
3.名前のエントリだけでなく、50%ルールとUBOリンクを考慮してください。
4.FPRを削減するための名前正規化とコンテキスト(DR/city)。
5.TTLと再検証で検証された受益者/銀行のホワイトリスト。
6.GEO/method/corridorによるセグメントしきい値。
7.説明可能性ログと監査証跡:「who/when/why」。
8.PSP/バンクで手動のリターンコードとSLAをネゴシエーションします。
9.トラベルルールと暗号のための信頼できるVASPのレジストリ。
10.定期的なポストインシデントとルールチューニング。
16)実装チェックリスト
- ソースとリフレッシュレートを一覧表示(OFAC/EU/UK/UN/local)。
- 50%ポリシーとUBOグラフ。
- オンボーディング/デポジット/ペイアウト/新しい有益/再作成のためのスクリーニング。
- 統合:PSP/バンク/スズメバチ、リターンコード。
- 閾値行列(pass/manual/deny)、 GEO/メソッドセグメント。
- ホワイト/ブラックリスト(有益/銀行/ASN/IP)とTTL。
- 説明可能性ログ、機能/ソリューションのスナップショット、ライセンスレポート。
- KPIダッシュボードとアラート;手動SLA。
- プレイブック(リストアップデート、リターン、トラベルルール)。
- オペレータートレーニング(別名/転写、country-rarities)。
履歴書のサマリー
支払いの制裁遵守は、ルール、データ、ルートのオーケストレーションであり、単に「リストを突破する」だけではありません。"主要な支払いパスポイントへのスクリーニングを構築し、UBOと50%ルールを考慮し、通路/銀行を管理し、正規化とコンテキストを通じて偽陽性を低減し、説明可能な意思決定とポリシーのバージョンをコードとして保存します。この方法では、回廊へのアクセスを維持し、トランザクションコストを削減し、変換を実行せずにライセンス要件に耐えることができます。