CEXのホットウォレットに午前3時14分に入金があった。送金額は小さく、プラットフォームの報告閾値を下回っており、送信元アドレスにはローカルの制裁ファイルにフラグがない。システムはユーザーのアカウントに入金を反映させる。20分後、外部インテリジェンスフィードが同じ送信元アドレスを制裁対象エンティティとして更新する。取引所は現在不正資金を保有しており、オンボーディングは誰も介入できないうちに完了し、監査ログにはクリーンな承認が記録されている。これが、仮想資産サービスプロバイダーに対する執行措置において規制当局が一貫して指摘する、入金スクリーニングの失敗パターンである。
原因は構造的なものだ。入金は外部資金がプラットフォーム管理のウォレットに最初に触れる瞬間であり、取引所のマネーロンダリング阻止チェーンにおいて最もエクスポージャーの高いノードとなる。金融活動作業部会（FATF）はVASPがすべての着信送金にリスクベースのアプローチを適用することを求めており、FinCENの銀行秘密保護法（BSA）上の義務は、その期待を米国登録プラットフォームにまで拡張している。本記事では、入金フローのマッピングから防御可能な監査証跡の構築まで、入金側のAMLスクリーニングを4つのステップで実装する方法を解説する。
入金側AMLスクリーニングがなぜ最初の防衛ラインとなるのか
一般的な執行パターンを考えてみよう。デジタル資産会社を審査する検査官が、着信入金に対する承認決定に送信元アドレスのスクリーニングに関する文書が一切ないことを発見する。この指摘は、同社が別途対処していた本人確認に関するものではなかった。それは、資金が入金反映されて取引所の統合ホットウォレットに移動される前に、送金元ウォレットを評価するコントロールが存在しないことについてのものだった。
入金スクリーニングはそのギャップを埋めるコントロールであり、IDレイヤーではなくアドレスおよびトランザクションレイヤーで機能する。KYCはオンボーディング時に顧客を確認する。KYA（Know Your Address）は、実際にプラットフォームに価値を届けているブロックチェーンアドレスを評価する。KYT（Know Your Transaction）は、確認時点での資金移動を監視する。入金のAMLスクリーニングはKYAとKYTの上に構築されており、プラットフォームがすでに完了しているかもしれない本人確認に基づくものではない。
入金が最初の防衛ラインとなる理由はタイミングにある。資金が入金反映されて共有ホットウォレットに統合されてしまうと、特定の送信元を遡って追跡することは著しく困難になる。クリーンな入金と混合された制裁資金は下流の出金を汚染する可能性があり、入金段階での見落とし1件が数週間後に規制上の指摘として浮上することがある。
ステップ1：入金フローをマッピングしてスクリーニングのトリガーポイントを特定する
ユーザーが入金アドレスを生成する瞬間から、資金が入金反映されてトレードに利用可能になる瞬間まで、入金フローをエンドツーエンドで描くことから始める。ほとんどのCEXパイプラインは、スクリーニングを展開できる4つの明確なコントロールポイントを経由し、それぞれが異なるリスクプロファイルを持つ。
4つのトリガーポイントは明確だ。第一に、プラットフォームが不正活動に関連するウォレットに入金アドレスを渡す前の、アドレス生成時のスクリーニング。第二に、実際の送金を評価する、最初のオンチェーン確認時のスクリーニング。第三に、資金がホットウォレットに統合される前のプリスイープチェックであり、これは混合前の最後の技術的チェックポイントとなる。第四に、自動チェックを通過したものの人間が確認すべきパターンを示す、大規模または異常な入金に対する閾値ベースのレビュー。
ビジネスモデルが異なれば、これらのコントロールの配置も異なる。リテールフローを持つスポット取引所は、確認時に自動スクリーニングを展開し、大規模な入金には手動レビューを設けることがある。OTCデスクは、価格を提示する前に取引前スクリーニングを要求することがある。入金と出金の両方を処理する決済機関は、入金スクリーニングレイヤーをより広範なコンプライアンスパイプラインの中の1つのモジュールとして扱うことがある。このマッピング作業により、統合コードを書く前に、各コントロールが既存のコードベースのどこに実際に存在し、誰がそれを担当するのかをチームが決定することが求められる。
ステップ2：アドレススクリーニングAPIを入金パイプラインに統合する
トリガーポイントのマッピングが完了したら、次のステップはスクリーニングAPIを各ポイントに組み込むことだ。コールがどこに位置するかにかかわらず、統合シーケンスは一貫している。まず、アドレス形式を正規化する。次に、KYAエンジンに送信する。そして、カテゴリコンテキストとともにリスクレベルを受信する。最後に、そのレベルに応じて入金ワークフローを分岐させる。
正規化は見た目以上に重要だ。Ethereumアドレスはチェックサム付き、小文字、またはEVMエイリアス形式で表示されることがあり、TronアドレスはHexではなくbase58を使用する。スクリーニングコールは、エンジンがそのチェーンに対して期待する形式でアドレスを渡す必要があり、そうでなければ判定がサイレントに失敗する。正規化後、エンジンはアドレスを事前構築されたラベルグラフに対して照合し、リスクレベルとそれを導いたラベルカテゴリを返す。BlockSecのKYAエンジンは、6億以上の事前構築ラベルおよび200以上のリスクシグナルに対してミリ秒レベルの応答速度で照合を行う（Phalcon Compliance ドキュメント）。その応答は入金パイプラインの許可・レビュー・ブロックの分岐に直接フィードされる。
パイプライン自体は、ほとんどの実装で漏れが生じる部分だ。スクリーニングコールがトランザクション確認とアカウント入金反映の間の同期パス上にある場合、レイテンシはユーザー体験に直接影響する。バッチ処理する非同期キュー上にある場合、バッチ間に発行された制裁指定によってプラットフォームが危険にさらされる。本番環境の展開では、通常、初期判定のための同期プリクレジットチェックと、後から届くラベル更新のための非同期の再スクリーニングパスを組み合わせて使用する。
ステップ3：リスク閾値とレスポンスアクションを定義する
スクリーニングが統合されたら、プラットフォームは各リスクレベルを具体的なアクションにマッピングするポリシーが必要だ。閾値がなければ、スクリーニング出力はアクション不能となり、閾値があれば、執行可能なコントロールとなる。
Phalcon Complianceはスクリーニングされた各入金に対して、クリティカル・高・中・低・リスクなしの5つのリスクレベルのいずれかを返す。各組織は、自組織のコンプライアンスポリシーとリスク許容度に照らして、各ティアの意味を設定する。入金に対する一般的なマッピングは、クリティカルは自動ブロックおよび即時調査にルーティング、高・中は手動レビューまたは保留にルーティング、低は継続的モニタリングで継続、リスクなしは自動入金反映、というものだ。
| リスクレベル | 典型的なシステムアクション | アナリストのアクション | 保持される証跡 | 規制上のトリガー |
|---|---|---|---|---|
| クリティカル | 自動ブロック、エスカレーション | 即時調査、必要に応じてSTRを提出 | 完全なスクリーニング証跡、決定チェーン | 不審取引報告 |
| 高 | 入金反映保留、キューにルーティング | ラベルコンテキストをレビューし、SLA内で決定 | アナリストID、決定の根拠 | 強化デューデリジェンスファイル |
| 中 | 入金反映保留、キューにルーティング | ラベルコンテキストをレビューし、決定 | アナリストID、決定の根拠 | 強化デューデリジェンスファイル |
| 低 | 自動入金反映、継続的モニタリング | 不要 | レベル、カテゴリ、タイムスタンプ | 標準的な記録保持 |
| リスクなし | 自動入金反映 | 不要 | レベル、タイムスタンプ | 標準的な記録保持 |
執行上の指摘を支配する2つの閾値の落とし穴がある。1つ目は、脅威パターンの変化に対して調整されることのない静的な設定であり、制裁の急増によってクリティカルまたは高のバンドの一時的な引き締めが必要になることがある。2つ目は、すべての曖昧な入金をチームがこなせないキューに流し込む中バンドであり、アナリストが決定をゴム印のように押すことを強制し、手動レビューの目的を損なう。Phalcon Complianceは設定可能なリスクポリシーをサポートしており、各ティアのマッピングをプラットフォームのリスクプロファイルに合わせてチューニングし、エクスポージャーの変化に応じて調整できる。
ステップ4：入金スクリーニングのためのコンプライアンス監査証跡を構築する
最終ステップは、規制当局が最初に調査するもの、すなわち監査証跡だ。数か月後に再現できないスクリーニング決定は、審査目的上、行われなかったスクリーニング決定と同じだ。
すべてのスクリーニングイベントは、スクリーニングされたアドレス、タイムスタンプ、返されたリスクレベル、評価を導いたラベルカテゴリ、および結果として取られた決定とともに記録されなければならない。ログは改ざん防止されており、オンデマンドでエクスポートできなければならない。検査官が特定の日付に特定の入金がなぜ通過したのかを問い合わせた場合、応答は説明文ではなく、そのタイムスタンプのスクリーニング記録をそのまま再現したものとなる。Phalcon Complianceのプラットフォームは各判定をコンプライアンスログに書き込み、審査用にエクスポート可能であり、主要な規制管轄に沿ったワンクリックSTR生成をサポートしている（Phalcon Compliance ドキュメント、リスクレベル）。
監査証跡は縦断的なレビューも可能にする。1回スクリーニングされた単一の入金は、ある時点での決定だ。そのライフタイム全体にわたって継続的にスクリーニングされた入金アドレスは、リスク履歴となる。ラベル更新がプラットフォームと以前に関わったアドレスを指定した場合、監査証跡はその以前の関係を露わにする。コンプライアンスチームはそのソースからのすべての入金を再構築し、遡及的なアクションが必要かどうかを判断できる。
取引所およびVASPの完全なAMLコンプライアンスプログラムにおける入金スクリーニングの位置付けについてのより広い説明は、Crypto AML Complianceを参照。Phalcon Complianceプラットフォームは上記のステップを本番環境で実行する。
よくある質問
入金側AMLスクリーニングはKYCとどう違うのか？ KYCはオンボーディング時に顧客のIDを確認し、文書レイヤーで機能する。入金側AMLスクリーニングはアドレスおよびトランザクションレイヤーで動作し、それを開始した人物ではなく、各着信送金のブロックチェーン上の送信元を評価する。この2つは完全なAMLプログラムにおける補完的なコントロールだ。
入金フローのどの時点でスクリーニングを実行すべきか？ スクリーニングは少なくともトランザクション確認時に1回、ユーザーのアカウントに資金が入金反映される前に実行すべきだ。多くのプラットフォームは、ホットウォレットへの統合前のプリスイープチェックと、大規模または構造的に異常な入金に対する閾値ベースのレビューを追加している。
入金がすでに入金反映された後にリスクレベルが更新された場合はどうなるか？ 監査証跡によってコンプライアンスチームが同じアドレスからの過去の入金を特定し、遡及的なアクションを評価できる。入金時スクリーニングと並行して動作する継続的モニタリングレイヤーが、初期判定後に届くラベル更新を検知し、再評価のために提示する。
入金スクリーニングはユーザー体験を遅くするか？ ミリ秒レベルの応答を返すスクリーニングエンジンは、入金パスに知覚できるレイテンシを発生させない。ボトルネックは通常、スクリーニングコールではなくブロックチェーンの確認時間であり、スクリーニングコールは確認ポーリングと並行して実行される。
各入金の監査証跡には何を含めるべきか？ 最低限として、スクリーニングされたアドレス、タイムスタンプ、リスクレベル、評価を導いたリスクカテゴリ、取られた決定、および適用されたポリシーバージョンが必要だ。中・高バンドについては、アナリストのIDと決定の根拠も保持すべきだ。
