暗号資産の出金をいつ止めるか｜交換所の詐欺対策と止めた後の解除の決め方

ある暗号資産交換所のサポート窓口に、同じ日に2つの問い合わせが届きました。

1つめは、投資詐欺にあった利用者の家族からです。本人は、投資話を持ちかけてきた相手の指示どおりにアプリを操作し、追加の認証も自分で済ませて、資産を外部のアドレスへ送っていました。「ご自身の意思ですか」という確認にも「はい」と答えています。

2つめは、長く使っている利用者からの苦情です。いつもの自分のウォレットへ送ろうとしたのに、出庫が止まって何日も待たされている。理由の説明もない、という内容です。

出庫の不正対策は、この2つのあいだで設計します。止めなければ、乗っ取りや詐欺で資産が抜かれます。一律に止めれば、正当な利用者の問い合わせと手動の解除が増えます。

答えは、止める理由ごとに止め方を変えることです。追加の認証、待機、手動の審査、拒否を使い分けます。そして「なぜ止めたか」と「何を確かめたら解除するか」を必ず対にして記録します。申請から署名までのあいだには、宛先や数量がすり替えられるおそれもあります。そのため、署名の直前にもう一度確かめます。

以下では、この交換所のプロダクト、セキュリティ、AML、バックエンドの責任者が決める順に見ていきます。

この記事でわかること

• 止め方の段階と、判定に使う信号
• 止める理由と解除の条件の対応表、待機中に利用者へ見せること
• 手動審査の解除のしかた、測る指標、導入前に試す場面

全部を一律に止めず、理由ごとに止め方を変える

一定期間の出庫制限は、有効な手段です。ただ、すべての残高・利用者・理由に同じ待機時間を当てると、冒頭の2つめの問い合わせのようなことが起きます。知っているアドレスへの普段の出庫まで止まるからです。

逆に追加認証だけでは、攻撃者がログイン中の状態や認証器まで握っていれば、正規の操作のように通ってしまいます。そこで、少なくとも次の4段を組み合わせます。

1. 事前：送付先アドレスの登録、登録・変更の後の冷却期間、1日の上限、フィッシングに強い認証
2. 申請のとき：端末、ログイン中の状態、顧客の行動、資金の動き、送付先のリスクを評価する
3. 実行のとき：承認した資産・ネットワーク・アドレス・数量が変わっていないかを確かめ直し、1回だけ署名・送信する
4. 事後：チェーン上の監視、顧客からの通報、誤検知・見逃しの計測、ルールの見直し

実例があります。BITPOINTは2026年7月27日から、銀行振込・インスタント入金で日本円を入れた後の7日間、直近の入金額に当たる暗号資産の出金を制限しています。期間は入金日を含み、8日目の0:00に解けます。

出金できるのは、次の2つの低い方に当たる数量です（BITPOINT公式告知、2026年7月24日告知）。

• 保有する暗号資産の評価額
• 移動上限額（純資産額 − 直近7日間の日本円入金相当額の合計）

これは、「入金の直後」という特定のリスクに、制限する金額を結びつけた例です。ほかの事業者の期間や計算式をそのまま採用するのではありません。自社の詐欺の型、入金が取り消されるリスク、補償の方針、顧客層から、何を止め、どうなったら解除するかを決めます。

何を見て判定するか

金融庁の「疑わしい取引の参考事例」は、次のような例を挙げています（金融庁「疑わしい取引の参考事例」）。

• 非対面の取引で、認証方法などが同時に変わった。過去と違う接続環境から操作している
• 多数のアドレスへの頻繁な出庫、入金直後の大口の出庫
• 不審なアドレスとの一致・関連、速すぎる入力、何度ものログインの失敗

同時に、形の上で当てはまるだけで疑わしい取引と決まるわけではない、とも明記しています。顧客の属性や取引の状況を、総合的に判断するよう求めています。

そのため信号は「詐欺の証明」ではありません。追加の確認へ進める根拠として扱います。出庫の申請のときには、次の4つのまとまりを、同じ時点の記録（snapshot）として保存します。

• 本人・認証：パスワード、電話番号、メール、認証器、本人確認情報、APIキーを変えた時刻。アカウントの復旧、失敗の回数
• 端末・ログイン中の状態：新しい端末。過去と違うIP・地域・時刻。ログインしてからの時間、Cookieや端末との紐付け、Botのような操作の速さ
• 資金・行動：円・暗号資産の入金時刻、売買の直後か。金額・頻度・送付先の数、普段の行動からのずれ、1日の累計
• 送付先：新しい・変更したアドレス、ネットワークとtag・memo、過去に成功した履歴、他の顧客との共有。詐欺・盗難・制裁・ミキサー・個人間取引などとの直接・間接の関連

チェーン上の分析には、限界があります。持ち主の取り違え、データの遅れ、アドレスのまとまり（クラスタ）の更新、チェーンごとの差です。

金融庁が2026年7月に公表したFinTech実証実験ハブの結果も、同じ見方です。疑わしいアドレスとの一致、詐欺に関するスコア、取引行動の似かたなどは、出庫時の評価に使えます。一方で、アラートだけでは取引制限などの判断に足りない場合があるとしています。資金の流れ、公開情報、関連アドレスなどの追加の調査が要ります（金融庁の実証結果）。

分析事業者のスコアを、ずっと変わらない事実として保存してはいけません。提供元、スコア、分類、関連の深さ、取得した時刻、データの版と、社内の判断を分けて持ちます。業者どうしでアドレスの情報を共有する仕組みは、暗号資産AMLの情報共有とトラベルルール実装で詳しく扱います。

止める理由と、解除の条件を対にする

モデルの出力を、そのまま「許可/拒否」にしません。説明できる対応に置き換えます。次は最初の設計の例です。閾値と期間は、自社のデータで確かめます。

合計のスコアだけでは、同じ80点でも区別がつきません。「認証器を変えた直後」なのか、「古い間接的なアドレスの関連」なのかが分からないからです。対応を決める入力には、合計値に加えて必ず理由コード（reason code）を残します。

理由の種類も分けます。法令・規則による制限、アカウントを守るための制限、入金取消などへの対策、サービス上の上限は、それぞれ別の理由コードにします。解除できる権限と、顧客への通知も種類ごとに分けます。

送付先の登録と追加認証で、承認した中身を固定する

送付先の許可リストは、登録したアドレス以外への出庫を止める事前の手段です。Coinbase Exchangeでは、許可リストを有効にすると、登録済みのアドレスにだけ出庫できます。新しく足したアドレスは、48時間の保留の後に使えるようになります（Coinbase Help）。

ただし、許可リストを変える権限を攻撃者が取れば、回避されます。登録、削除、機能をオフにする操作にも、追加認証、通知、冷却期間をかけます。

送付先は、アドレスの文字列だけでは決まりません。ネットワーク、トークンのコントラクト、必要なtag・memoまで合わせて、初めて特定できます。そこでnetwork、asset_contract、address、必要なtag/memo、持ち主・相手の事業者の区分、登録の根拠を一組で持ちます。画面にも工夫が要ります。

• 似たアドレスへのすり替えに気づける表示
• アドレス全体、または十分な長さの先頭・末尾の表示
• QRを読み取った後の、ネットワークの再確認

ホワイトリストという名前でも、送付先の安全や受取人の正しさをずっと保証するわけではありません。

追加認証では、利用者に資産、ネットワーク、アドレス、数量、手数料を見せます。認証の問いかけ（チャレンジ）を、その中身に暗号で結びつけます。OWASPのTransaction Authorizationのガイドも、次のことを勧めています（OWASP Transaction Authorization）。

• 大事な取引データを、利用者が見分けて承認できる
• 承認をサーバー側で順番どおりに強制し、中身が変わったら承認を無効にする
• 実行の直前に、承認済みかを確かめ直す

認証の方式は、リスクに合わせます。NIST SP 800-63B-4は、IP、位置、時刻、ブラウザの情報などを使う適応型の認証を、補助の手段として挙げています。手で入力するOTPは、確かめる側（検証者）に暗号で結びつかないので、フィッシングに強くないと説明しています。WebAuthnは、検証者の名前に結びつける仕組み（verifier name binding）を持つ例です（NIST SP 800-63B-4 Authenticator Requirements）。

SMSやTOTPをやめられない場合も、それだけでリスクの高い出庫をすぐに許可してはいけません。パスキーなどのフィッシングに強い方式、知っている端末、冷却期間を組み合わせます。

申請から送信まで、どこで何を確かめるか

出庫APIが申請を受けてすぐにウォレットの署名まで進むと、困ったことになります。判定の仕組み（risk engine）や手動審査の遅れ、タイムアウト、二重の要求を安全に扱えないからです。

そこで、出庫を次の段階に分けます。許された順番の移り方だけを、サーバー側で強制します。

受付 → 判定 → 追加認証／待機／手動審査 → 承認 → 署名 → 送信 → 確定（または拒否・取消）

各段階で、禁じる動きがあります。主なものは次のとおりです。

• 受け付けた時点では、まだ署名しない
• 中身を変えた後に、古い認証を使い回さない
• 待機の時刻だけを書き換えて、早く解除しない
• 審査の待ち行列に溜まっていることを、暗黙の許可にしない
• 承認の後に、アドレスや数量を変えない
• タイムアウトだけを理由に、別の署名要求を作らない。同じ出庫を送り直さない

承認から署名へ進む直前に、もう一度確かめます。残高、制裁・禁止リスト、送付先の状態、判定ルールの期限切れです。ただし、確かめ直した結果で中身を黙って変えてはいけません。判定が変われば、手動審査か再申請へ戻します。承認した後で宛先や数量をすり替えられないようにするためです。

署名の仕組みの側も、「判定の仕組みが安全と言った」ことを信じるだけでは足りません。許されたネットワーク、トークンのコントラクト、数量の上限、送付先、承認IDを、独自に確かめます。

鍵の管理と業務の承認では、3つの権限を分けます。署名する権限、判定ルールを変える権限、例外を承認する権限です。複数の承認者のうち誰が欠けても、緊急時に復旧できる手順も用意します。署名鍵の保管と署名ルールの組み方は、本番署名鍵のHSM・MPC設計で扱っています。

待っている間、利用者に何を見せるか

冷却期間があると、正当な利用者は、身に覚えのない出庫に気づいて止めることができます。冷却期間は、ただの遅れではなく、そのための時間です。待機が始まったら、前から信頼している連絡先に知らせます。少なくとも次のことを示します。

• 資産、数量、ネットワーク、送付先
• 申請の時刻、解除の予定
• 取消・凍結の方法

状態の確認や解除は、メールの中のリンクからではなく、正規のアプリや公式サイトで行ってもらいます。

冒頭の2つめの問い合わせは、理由が見えなかったことから生まれていました。止めた理由ごとに、画面で示すことを変えます。

画面には「審査中」だけでなく、開示できる範囲で次のことも出します。

• 制限の対象：その出庫、対象の金額、または出庫の機能全体
• 理由の種類：新しい送付先、大事な設定の変更、入金の直後、追加の確認、法令・規則など
• 次にすること：待つ、本人確認、資料の提出、サポートへの異議申し立て
• 時刻：申請、最後の更新、解除の予定か次の連絡の目安
• 安全のための手段：覚えがないときの即時凍結、ログイン中の状態・APIキーの失効

冒頭の1つめの問い合わせのように、投資詐欺では本人が攻撃者の指示どおりに認証を済ませてしまうことがあります。「ご自身の意思ですか」と聞くだけでは防げません。送付の目的や相手との関係を聞く場合も、答えだけで自動的に解除しないことです。知られている詐欺の型、送付先、資金の動き、通報の情報と合わせて判断します。

質問の中身と正解の条件を決めて公開すると、すり抜けられます。顧客に対して透明であることと、検知の仕組みを伏せておくことは、分けて考えます。

手動審査の解除を、いちばん厳しく確かめる

自動では決められない出庫は、審査の待ち行列へケースとして送ります。チャットや表計算シートだけで解除すると、記録の抜け、権限を超えた操作、二重の処理が起きます。ケースには、次の情報を保存します。

• 出庫ID、顧客と取引の申請時点の記録、すべての理由コード
• アドレス情報を取った時点、問い合わせの履歴
• 担当者、期限、判断、承認者

解除は、「アラートを閉じる」操作とは別にします。次の条件を、サーバー側で確かめ直します。

1. 審査した資産、ネットワーク、アドレス、tag・memo、数量が、申請のときから変わっていない。
2. 必要な本人確認と取引の承認が有効期限内で、その中身に結びついている。
3. 新しい高リスクの信号、禁止リストの更新、顧客からの凍結の依頼がない。
4. 理由の種類ごとに必要な権限者が承認している。高額・例外の解除では、2人の承認が済んでいる。
5. 承認には短い有効期限があり、切れたら評価し直す。

金融庁の2026年の実証結果は、疑わしいアドレス情報の共有について、検討すべき点も示しています。データの品質、管理の責任者、保存期間、訂正・削除、アクセス制御、監査ログ、苦情・異議申し立ての手順です。間違ったアドレスのラベルや、本人の取り違えを直せる審査案件の管理（case management）を、検知の仕組みと同じ重さで作ります。

止めた件数だけでなく、何を測るか

制限を強くすれば、見かけの「阻止した件数」は増えます。けれど、正当な利用者を止めた件数と時間を測らなければ、改善できません。日次・週次で、少なくとも次を確かめます。分け方は、理由コード、顧客層、資産、ネットワーク、金額帯です。

• 確かめられた不正を止めた率と、出庫の後に分かった見逃しの率・損失額
• 手動審査の率、誤検知の率、異議申し立ての率、解除・判断を変えた率
• すぐに許可した率、冷却期間と審査にかかった時間（p50・p95。半分が収まる時間と95%が収まる時間）、約束した対応時間の超過
• 追加認証の成功と離脱、本人の「覚えがない」という通報までの時間
• ルール・モデル・アドレス情報の提供元ごとの適合率（止めたうち本当に不正だった割合）、再現率（不正のうち止められた割合）、データの欠けの率
• 審査担当者ごとの判断のばらつき、例外の解除、2人の承認からの外れ

新しいルールは、まず過去の確定したケースで確かめます（バックテスト）。次に、今の処理を止めずに裏で並べて動かし（シャドー運用）、誤検知と待ち行列の量を測ります。そのうえで、段階的に入れます。

FATFの暗号資産のレッドフラッグ指標も、同じ考え方です。異常な取引の型、金額・頻度、匿名性、地理、送受信者、資金の出どころを指標に挙げています。一方で、1つの指標がそのまま犯罪を意味するわけではないとしています（FATF Virtual Assets Red Flag Indicators）。見逃しと誤検知の両方に正解のラベルを付け、判断の理由を追える範囲でモデルを使います。

導入の前に、解除と二重送信を壊してみる

PoCやリリースの判定では、少額の正常な出庫だけでは足りません。次の場面を試します。

• アドレスの登録、認証器の変更、アカウントの復旧、円の入金が、想定と違う順番で重なる
• 申請の後に数量・ネットワーク・tag・memoを書き換え、古い追加認証が無効になる
• 判定の仕組み、アドレス情報の提供元、本人確認APIのタイムアウト・古いキャッシュ・応答の食い違い
• 審査中の顧客による取消、緊急凍結、禁止リストの更新、2人目の承認者の不在
• 署名要求がタイムアウトした後の再照会、Webhookの重複、Workerの再起動、同じ冪等キー（何度送っても1回分だけ処理させる番号）での再送
• 送信の前後でのノードの障害、トランザクションハッシュが取れない、nonce（取引の通し番号）の競合、手数料の引き上げ、チェーンの再編（reorg）
• 間違ったアドレスのラベルの訂正、異議申し立て、監査ログと顧客への通知の再現
• 幅390pxの画面での、アドレスの確認、警告、取消・凍結・異議申し立てへの道筋

障害の試験では、依存するサービスが止まったときの動きも決めます。全部止めれば、冒頭の2つめの問い合わせのような正当な利用者まで止まります。そのため「安全のために止める」を、全部止めることと同じにはしません。依存するサービスごとに決めておきます。低リスクの知っているアドレスへの出庫も止めるのか、追加認証へ上げるのか、高リスクだけを手動審査へ送るのかです。

出庫を全部止めた後に、機能ごとに戻す判断は暗号資産交換所のサービス再開設計で扱っています。脅威の分析や鍵の管理を含む共通の観点は、Web3セキュリティの基礎も参考にしてください。

実装する人向けの詳細

ここからは、この交換所のバックエンドの担当者が作る部分です。

出庫の状態と、次へ進むための記録

顧客の要求、判定ルールによる判定、承認、署名、ブロードキャスト、確定を別々の状態にし、許した遷移だけをサーバー側で強制します。

APPROVEDからSIGNINGへ進む直前の再確認で判定が変わった場合は、MANUAL_REVIEWか再申請へ戻します。申請時と署名時のあいだに宛先や数量がすり替わるTOCTOU（確認時点と利用時点のずれ）を防ぐためです。

判定を後から再現するための最小のデータ

{
  "withdrawal_id": "wd_...",
  "request": {
    "customer_id": "...",
    "asset": "...",
    "network": "...",
    "asset_contract": "...",
    "address": "...",
    "tag_or_memo": "...",
    "amount": "...",
    "fee": "...",
    "requested_at": "..."
  },
  "risk_snapshot": {
    "policy_version": "...",
    "signals": [{"code": "AUTHENTICATOR_CHANGED", "observed_at": "..."}],
    "address_provider": "...",
    "address_data_version": "...",
    "decision": "COOLING_OFF",
    "reason_codes": ["NEW_ADDRESS", "AUTH_CHANGE_RECENT"]
  },
  "authorization": {
    "transaction_hash": "...",
    "method": "webauthn",
    "verified_at": "...",
    "expires_at": "..."
  },
  "execution": {
    "idempotency_key": "...",
    "signing_request_id": null,
    "tx_hash": null
  }
}

審査ケースにはwithdrawal_idを必ず持たせます。個人情報、端末の計測情報、チェーン上の情報を、期限なく集めないようにします。項目ごとに、目的、使える権限、保持期間、削除・訂正の手順を決めます。監査ログには本人確認書類の原本を写しません。誰が何を見て、どのルールの版でどの遷移を実行したかを、改ざんを検知できる形で残します。

関連する記事

• 業者間の疑わしいアドレスの共有：暗号資産AMLの情報共有とトラベルルール実装
• インシデントの後の機能ごとの再開：サービス再開設計
• ハードフォーク時の入出庫の停止と再開：ハードフォーク時の取引所対応
• 制度改正に合わせたシステムの準備：暗号資産の金商法改正と事業者の実装準備

XTELAができること

私たちは、出庫の流れと脅威の整理から、状態機械、判定時点の記録、審査ケースの管理、署名APIの設計、オンチェーン監視、監査ログまでを、障害シナリオを含むPoCとして設計・開発します。貴社の審査担当者が解除の根拠を後から説明できる画面と記録の形を一緒に作り、運用開始後の誤検知の計測と見直しまで続けます。取引制限や届出が法令上適切かの判断は弁護士と連携して進めます。出庫制限の設計を相談したい場合はお問い合わせください。

主要参考資料

• 金融庁：「FinTech実証実験ハブ」支援決定案件の実験結果について（2026年7月24日）
• 金融庁：疑わしい取引の参考事例（2026年8月12日確認）
• デジタル庁：令和7年度web3分野におけるアンホステッド・ウォレットに係る整理・検討に関する調査 最終報告書（2026年7月）
• BITPOINT：日本円入金後の暗号資産出金ルール変更のお知らせ（2026年7月24日、2026年9月24日確認）
• Coinbase Exchange：Address book and crypto withdrawal address whitelisting（2026年8月12日確認）
• NIST SP 800-63B-4：Authenticator and Verifier Requirements（2025年7月）
• OWASP：Transaction Authorization Cheat Sheet（2026年8月12日確認）
• FATF：Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing（2020年9月14日）

資料の確認日と注意

一次資料は2026年8月12日に確認しました。BITPOINTの告知と金融庁の実証結果は、2026年9月24日に確かめ直しています。ここに書いたのは、その資料にもとづく技術・業務の設計の整理です。制限・凍結・解除や届出の判断は、法域や個別の事情で違います。最新の公式資料をもとに、社内のコンプライアンス担当者や弁護士と確かめてください。