これは特定サービスの批判ではなく、私自身が経験した「送金レールの相性リスク」の記録。
CEXのAML判定ロジックは非公開のため、解釈には推測を含む。

1. 起きたこと（事実のみ）

オンチェーンで保有していたETHを、BaaS/中継型サービスを経由してCEXへ送金。
結果は「着金とほぼ同時にアカウント制限」。

• 送金前：通常利用
• 送金：中継サービス → CEX（ETH）
• 直後：出金・取引が停止
• 理由：具体説明ほぼ無し

取引内容や利用先とは無関係に、入金イベントだけでトリガーされた形。

2. BaaS/中継モデルの構造

多くのBaaS・決済代行は、

• ユーザー個別アドレスではなく
• 共有ホットウォレットでプール管理
• 出金は在庫から「代替送金」
• 内部台帳で残高を管理

という設計が一般的。

「個人の資金」ではなく
「中継事業者名義のウォレットからの資金」
として評価されやすい構造になる。

3. なぜETHは特にセンシティブか

ステーブルよりETHは、

• DeFi・ブリッジ経路が多い
• コントラクト相互作用が複雑
• トレーサビリティ評価が下がりやすい
• ガス支払いで履歴が混在しやすい

という性質を持つ。
中継モデルと組み合わさると「相性が悪い」可能性が高い。

4. 本質はレールの問題

今回のポイントは行き先ではなく、

BaaS/中継経由 × オンチェーンETH × CEX入金

という導線そのもの。
何を取引したか、どのサービスを使ったかは直接の原因ではなさそう、というのが現在の理解。

5. 同じ事故を避けるチェック

避けたいパターン

• オンチェーンETH → BaaS/中継 → CEX
• 中継箱として決済基盤を利用
• 着金後すぐの再送金

比較的無難

• オンチェーン → 直接DEX
• 銀行オンランプ → CEX
• ステーブル主体のホワイト導線

6. 学び

• BaaS経由＝銀行と同等、ではない
• CEXのAMLは「レール単位」で評価されやすい
• ETHは想像以上に扱いがセンシティブ
• 中継構造はトレーサビリティを弱める

7. まとめ

これは誰かの落ち度というより、設計思想の衝突に近い話。
オンチェーン資産をCEXに入れる前には、通すレールそのものを疑う必要がある。

同じミスを繰り返さないための記録として。