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