支払いロジックのブラックリストとブロックリスト

TL；DRについて

ブラックリスト/ブロックリストは、支払いパイプラインでの「ハード」と「ソフト」禁止の管理可能なレイヤーです。その値は、明らかにリスクの高い識別子（カード、IBAN、暗号アドレス、デバイス、IPなど）を高価なチェックや書き込みの試みに素早く剪定することです。効率化の鍵は、明確なデータモデル（有効期間、ソース、理由、管轄権、信頼度）、強力なキャッシュと監査、一貫したTTL/アムネスティポリシー、およびヒットレート↔オーバーブロック指標を備えた孤立したサービスです。

1）利用規約と相違点

Blacklist/Deny-list/Block list-一連の識別子（HARD BLOCK）。
Stop-list （context）-特定のコンテキストでのブロック（たとえば、結論のみ、国Xでのみ、金額>€Yでのみ）。
Watchlist/Greylist-「observation」：操作はすぐに拒否されるのではなく、STEP-UP （3DS/OTP/addに翻訳されます。KYC）またはマニュアルレビュー。
Allow-list/White-list-グレー信号を上回る明示的なアクセス許可（VIP、確認された銀行口座など）。
負のリスト（内部）-内部インシデント（チャージバック、ボーナスの乱用、制裁試合、マルチアカウント）に基づいたリスト。

💡 推奨事項：プラットフォームに関しては、Deny（ハード）、Stop（スコープ付きハード）、Observe（ソフト）、Allow（オーバーライド）を使用します。

2）正確にどのような「葉」： 識別子

お支払いの詳細

カード：PAN トークン/FPANハッシュ、BIN、発行者/国（ジオポリシー用）、用語、メディア名（オプション、ハッシュ/ファジー）。
銀行：IBAN/BIC、アカウント/ルーティング（ACH/SEPA）、所有者名（正規化ハッシュ）。
E-wallet/fintech：ウォレット（PayPal/Skrill/Netellerなど）、UPI/PIX ID、 Open-Banking PISP payer。
暗号：L1/L2アドレス、タグ（ミキサー/制裁/高リスク）、チェーン（ETH/BTC/TONなど）。

コミュニケーションと行動

電子メール/電話（正規化、「one-time」ドメインと再配布番号の会計処理）。
デバイス/ブラウザの指紋、クライアントキー、モバイルID。
ネットワーク：IP （ASN/プロキシ/VPN/データセンター）、/24サブネット、ジオロケーション。

口座・取引先

UserID/CustomerID、パートナー/アフィリエイト、プロモーションソース。
PSP/MID/Acquirer（ルート操作ロック用）。
アドレス/フルネーム（ハッシュ正規化、トークンによるファジーマッチング）。

3）リストの補充源

内部イベント：チャージバック、詐欺アラート、ボーナスの乱用（マルチアカウント、得点「ボーナスを取った-ターンオーバーなしで撤退」）、制裁試合、自己除外/MLROフラグ。
外部ソース：PSP/買収者の否定的なリスト、コンソーシアムベース（共有詐欺情報）、暗号タグプロバイダー、BINベース、リスクモデル。
ルールと手動入力：コンプライアンス/リスクオフィスの決定、インシデントの「凍結」。

4）データモデル（最低十分）

json
{
"key": "card:pan_token:9c4f...e1",
"scope": {
"action": ["deposit","withdrawal","payout"],
"jurisdiction": ["EEA","CA-ON"],
"product": ["casino","sports"]
},
"policy": "deny    stop    observe    allow",
"reason_code": "CHARGEBACK    BONUS_ABUSE    SANCTION_MATCH    MFA_BYPASS    KYC_FAIL    CONSORTIUM_HIT",
"source": "risk_engine    psp_x    mlro    consortium",
"confidence": 0. 92,
"created_at": "2025-10-01T12:30:00Z",
"expiry_at": "2026-01-01T00:00:00Z",
"ttl_days": 90,
"review_after": "2025-12-01T00:00:00Z",
"metadata": {
"case_id": "INC-2025-10344",
"notes": "2 CB in 45 days; bonus cycling through 3 wallets,"
"hash_algorithm": "sha256+salt",
"tenant": "brand_A"
}
}

必須フィールドは'key'、 'policy'、 'reason_code'、 'source'、 'created_at'、 'expiry_at/ttl'です。
グッドプラクティス：スコープ（行動/管轄/製品）と信頼（ソフトポリシー）を維持します。

5）リストサービスアーキテクチャ

専用のListService（すべてのマイクロサービスの真のステータス）。

API：

'GET/v1/list/check？key=……&ctx=……'-同期チェック（p99 <5-10 ms from Redis）。
'POST/v1/list/upsert'-検証と監査を伴う大量/シングルレコード。
'POST/v1/list/bulk'-ドライランからCSV/NDJSONをロードします。
'POST/v1/list/review/： id'-マークアップ/amnesty/extension。
ストレージ：Redis（ホットキャッシュ、TTL）+Postgres（履歴/監査）+DLQ/ログバス（Kafka）でイベントソーシングとレプリケーションを行います。
アクセス：書き込み-リスク/コンプライアンス/MLROは、機密鍵（銀行/暗号）のRBAC+4アイコントロールを介してのみ実行されます。
信頼性：idempotent upsert、バージョニングレコード、イベントパイプラインで正確に一度、KMS/HSM暗号化。

6）どこにチェックを埋め込むか

1.支払い手段の登録/リンク-「燃えた」詳細については早期に拒否します。
2.デポジット（イニシエーション）-明らかに悪いキーで認可を支払わないように、3DS/OTP前に速いDeny/Stop。
3.出金/支払い-支払い詳細（IBAN/暗号アドレス）の個別のリスト。入り口よりも厳しくなることがよくあります。
4.詳細の変更-ステップアップ+チェック；「引き出し前のカウントの変更」に対する保護。
5.ボーナス操作-乱用スキーム（マルチアカウント、デバイスチェーン）に従って監視/停止します。

7）ポリシー（HARD/SOFT）およびTTL

HARD（拒否/停止）が適用される場合：制裁、詐欺の確認、チャージバックの繰り返し、カードの盗難、ラバ。
SOFT （observe/step-up） at：弱い信号（新しいIP/デバイス「、冷たい」電子メールドメイン、高速）「、疑わしい」BIN/ASN。

TTL/expiry：

チャージバック：180-540日（レジメンとリスクに応じて）。
ボーナスボーナス：90-365日（改訂あり）。
制裁：リストの定期的な同期で無期限に。
恩赦：成功したCUS/「純粋な」プレイの履歴の後≥ N日と事件なし-観察または撤退する自動降格。

8）意思決定マトリックス

Signal（	プライバシーポリシー	［アクション］	例：
制裁の正確な一致（名前+dob+アドレス）	DENY（拒否）	拒否、MLROへの通知	そりからIBANへの撤退。国、国
PANトークンによる繰り返しCB	STOP（入金、出金）	入出力ユニット、リスクケース	2 × 45日のCB
疑わしいIP ASN+新しいデバイス	OBSERVE（オブザーブ	3DS ステップアップ/KYC層レイズ	データセンターあたり1000ユーロを入金
確認されたIBANのVIP	ALLOW	Outightsは観察します	高い限界、きれいな歴史

9）オンライン検証の擬似コード

python def is_blocked(keys: list[str], ctx: dict) -> Decision:
keys: ["card:pan_token:..", "ip:..", "device:..", "iban:.."]
ctx: {"action":"withdrawal","jurisdiction":"EEA","product":"casino","amount":1000}
hits = list_service. batch_check(keys, ctx) # из Redis + fallback PG if any(h. policy in ["deny","stop"] for h in hits if h. in_scope(ctx)):
return Decision(block=True, reason=top_reason(hits))
if any(h. policy == "observe" for h in hits if h. in_scope(ctx)):
return Decision(block=False, step_up="3DS_or_KYC", reason="OBS_HIT")
return Decision(block=False)

10）リスクエンジンおよび支払バスとの統合

リスクエンジンは最初にListServiceを読み込み、/ML/rulesをスコアリングします。
パイプラインでの注文：'Pre-auth→ListService （hard/soft）→3DS/OTP→Auth→Clearing'。
ルーティング：PSPルーティングレベルでは、プロバイダのブロックリストに'MID'/'BIN'が含まれている場合は、チャネル/aquiersを「ゼロ」にすることができます。
イベント：各ソリューション（'DENY/STOP/OBSERVE/ALLOW'）は、MLを監査し、さらに訓練するためにカフカに行きます。

11）業務とプロセス

大量ダウンロード：検証とシミュレーションを伴うCSV/NDJSON（影響を受ける操作の数）。
レビュー：毎日の延長/引き出しサンプル；ケース処理のためのSLA。
競合：'ALLOW'と'DENY'の両方が、明示的なVIPオーバーライドを除いて、最も制限されたルールを適用する場合。
バージョン管理：任意の編集-レコードの新しいバージョン；古い状態は調査のために保管されています。
インシデント：reason_codeテンプレート、チケットとの接続（Jira/Case-ID）。

12）品質指標と目標

ヒット率（HR）=任意のリスト上のトランザクションの割合。
ハードヒットレート（HHR）=ハードロックの割合。
Overblock Rate （OBR）=偽ロックの割合（その後の有効な支払者）。
CB-アップリフト（Uplift）：実装後の不正・損失。
入出金の承認率（AR）。
Time-to-Wallet （TTW）支払い速度に対するソフトメジャー（ステップアップ）の影響。
オンラインチェックのためのTime-to-Decision （p95/p99）。

💡 ターゲット：HHRは高く評価できるARの悪化なしで上がります；OBR ≤許容しきい値（例：<0.3%);p99チェック≤ 10ミリ秒。

13）法的およびプライバシー

処理の基礎：正当な利益/法的義務（AML/制裁/詐欺防止）。
最小化：プライマリデータ（PAN/IBAN）、塩、制御アクセスの代わりにハッシュ/トークンを保存します。
保持：TTL+一般保存ポリシー（AML/会計/規制）。
科目の権利：DSAR/削除のプロセス（コンプライアンスの例外を考慮して）。
クロスボーダー：リージョン/テナント間のレプリケーション境界を明確にします。

14）頻繁な間違いとそれらを回避する方法

IP/ASNによるオーバーブロック：データセンター/CGNAT→信号の組み合わせ（IP+デバイス+動作）を使用します。
個人データを貼り付ける：電子メール/電話を正常化し、番号のリサイクルを考慮します。
カードリサイクル（PAN再エミッション）：生データではなく、PANトークン/暗号トークン化によるバインド。
世帯総IBAN：スコープ（ペイアウトのみ）を使用し、グローバル拒否の代わりに監視します。
暗号アドレス：すべてをブロックしないでください。ラベル/コンテキスト（取引所、保管財布）を考慮してください。

15）ボーナスの乱用と制限との接続

ボーナスパターン：1つのウォレット/アドレス→多くのアカウント、売上高なしの迅速な出力-支払いの停止/拒否。
限界とTtW：「observe」は、レビュー前にターンオーバー/延長されたTtWを増やす必要があるかもしれません。

16）キーの例（正規形式）


card:pan_token:<sha256>
iban:<sha256>
wallet:skrill:<normalized_id_hash>
upi:<vpa_hash>
pix:<pix_key_hash>
crypto:eth:<address_lower>
email:<local+domain_hash>
phone:+<E164_hash>
device:<fp_hash>
ip:<ipv4/6 or /24>
asn:<asn_id>
affiliate:<id>
psp:mid:<id>

17）チェックリスト（実装チェックリスト）

1.ポリシーセットの定義：deny/stop/observe/allow+reason_codes。
2.データスキーマ：キー、スコープ、TTL/有効期限、信頼性、監査。
3.アーキテクチャ：Redis+PG+Kafka、 idempotency、 4-eye制御。
4.ストリームへの統合：認証前チェック、ステップアップ、ペイアウト硬化。
5.メトリクス/ダッシュボード：HR/HHR/OBR/AR/TTW、管轄/チャネルによって横断的。
6.プロセス：レビュー/アムネスティ、一括ダウンロード、DSAR、インシデント。
7.チームトレーニング：サポート/リスク/ファイナンス、紛争解決プレイブック。

18）ミニプレイブック

BIN XのCBサージ→BINの一時的な停止（デポジット）：X+他の買収者へのルート変更、48時間後のレビュー。
表示する前の詳細の変更→停止（引き出し）+KYC-step-up+指紋の検証。
コンソーシアムは財布にヒット→預金を観察し、MLROレビューの前に支払いを停止します。
国Yの制裁ニュース→国スコープを更新し、支払い拒否を有効にし、リストを再計算します。

19）管理パネルインターフェイスの例（ロジック）

キー/マスク検索、フィルタ：ポリシー、スコープ、理由、ソース、有効期限<30d。
アムネスティ、拡張TTL、低く観察するには、拒否に変換、許可を追加します。
ドライランでのバルクアクション：新しいルールに該当する操作の数を表示します。

20）サマリー

ブロックリストは単なる「禁止の表」ではなく、明確なデータモデル、強力なキャッシュ、リスニング、有能なTTL、明確なレビュープロセスを備えたプラットフォームレベルのサービスです。適切にリスクエンジンと統合すると、変換を破壊せずに詐欺ファネルを狭め、安全な場所での支払いをスピードアップします。

支払いロジックのブラックリストとブロックリスト

TL；DRについて

コミュニケーションと行動

口座・取引先

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です