
香港の仮想資産取引プラットフォームに関する新規制の詳細解説:「仮想資産取引プラットフォームにおける流動性共有に関する通達」
TechFlow厳選深潮セレクト

香港の仮想資産取引プラットフォームに関する新規制の詳細解説:「仮想資産取引プラットフォームにおける流動性共有に関する通達」
規制には一体どのような新しい変化があるのか?
執筆:暗号資産サラダ
金融テクノロジー週間の追い風を受けて、香港証券先物委員会(SFC)が発した二つの声明は、突如として小さな波紋を広げた。誰もが知っている通り、現在の香港における仮想資産取引所が直面する最大の課題は利益が出ないことである。規制の城壁はあまりにも高く、堅固に築かれているため、「不正なモノ」は確かに遮断されているが、自らの市場も循環しなくなり、かつてはまるで死水と化していたような状態だった。
SFCもこの問題に気づいており、仲介機関部執行ディレクターの葉志衡氏が述べたように、デジタル資産の規制は「小刻みにすばやく進む」原則に従い、小さな試行錯誤を通じて動的規制を行うべきである。この表現は非常に的確であり、二通の「通達」もその本質を見事に体現している。
本日、暗号資産サラダは専門弁護士の視点から、規制には一体どのような新変化があるのか?またそれが取引所の今後への発展にどう影響するのか?を深く分析する。
『仮想資産取引所間の流動性共有に関する通達』について

一、初めて仮想資産取引所に対して海外関連取引所との注文帳簿の共有を許可
まず、「注文帳簿の共有(Shared Order Book)」とは、二つ以上の仮想資産取引所が共同で管理・共有する統一された注文帳簿(Order Book)を指す。これにより、異なる取引所の注文を同一のマッチングシステムに集約し、プラットフォーム横断的な流動性プール(Liquidity Pool)を形成できる。
従来のモデルでは、各取引所がそれぞれ独立した注文帳簿を内部で維持しており、ユーザーが注文または指値を行うと、取引所が内部システム内で登録・成立させる仕組みになっている。このプロセスを「約定(Order Matching)」と呼ぶ。注文帳簿の共有メカニズムを導入することで、異なる国や地域の関連取引所が売買注文を同一の「取引プール」に投入し、取引のマッチングを行うことが可能となり、これが流動性向上の源となる。
多くの人が最初に思い浮かべるのは、HashKeyが今すぐバイナンスと接続できるのか?という疑問だろう。流動性の共有は想像力を掻き立てるが、どこまで共有できるのか? 暗号資産サラダは、この通達を見る限り、当面はまだ不可能だと考える。
第一に、通達は明確に、注文帳簿は香港ライセンスを持つ取引所とその「グローバル関連」取引所との間でのみ共有できると規定している。つまり、Haskey ExchangeはHashKey Globalと同じグループに属する他の地域の取引所とのみ流動性を共有でき、非グループの取引所(例:バイナンス)とは接続できない。
第二に、同じグループ内であっても、すべての取引所が条件を満たすわけではない。SFCは海外取引所が所在する国(地域)に対して二重の制限を設けている。
1)VATPおよび海外取引所双方が、それぞれの管轄区域で合法的にライセンスを保有している必要がある。
2)海外取引所の所在国は「信頼できる」必要があり、しかも香港が定義する「信頼できる」状態でなければならない。
海外取引所は国際的に認められ、規制が整備された国または地域に位置していなければならない。具体的には以下を満たす必要がある。
-
金融アクションタスクフォース(FATF)または類似組織の加盟国であること。
-
監督政策を有しており、その内容がFATFのマネーロンダリング防止規定およびIOSCO(国際証券監督者機構)による暗号資産市場に関する政策提言に概ね合致していること。
まず、海外取引所の所在国は香港が認める国・地域でなければならない。具体的にはどう判断するか? FATFの加盟国(地域)であれば、明らかに要件を満たす。(2025年11月9日時点、FATF公式サイトに掲載されている加盟国/地域は40カ国。詳細は https://www.fatf-gafi.org/en/countries.html で確認可能。)
身分のハード条件を満たすだけでなく、ソフト面でも対応が必要:国際基準に適合する取引所監督制度を備えていなければならない。 日本など規制が整備された地域に既に展開している取引所にとっては、この要件は容易に達成できる。なぜなら、もともと厳しいマネーロンダリング防止および市場監督体制下にあり、同様のライセンス要件を持っているからである。しかし、インド、トルコ、メキシコなど、適切な監督制度を持たない国では、あるVATPが現地に取引所を設立していても、違法ではない(規制がないため)が、流動性接続の条件を満たさず、香港のテーブルには乗れない。
法的根拠:
通達第7条は次のように規定している。「注文帳簿の共有は、プラットフォーム運営者と、関連管轄区域で活動を行うためにライセンスを取得した海外プラットフォーム運営者が共同で管理しなければならない。海外プラットフォーム運営者が運営する管轄区域は以下の条件を満たさなければならない。
-
(a) 財務行動特別作業部隊(特別作業部隊)または特別作業部隊と同様の機能を果たす地域組織1のメンバーであること。
-
(b) 特別作業部隊の勧告および国際証券監督者機構(IOSCO)による『暗号資産及びデジタル資産市場に関する政策提言』(Policy Recommendations for Crypto and Digital Asset Markets)に概ね一致する有効な監督制度を有していること。
二、取引および決済におけるリスク回避措置を明確化
通達第8条は明確に、香港のプラットフォームと海外プラットフォームが注文帳簿を共有しても、決済に用いる資産が同一の管理体制下に保管されていない場合、決済遅延や決済失敗といったさまざまな決済リスクが生じ得ると指摘している。
これは極めて現実的な問題である。伝統的な証券取引では、ユーザー資産は全て同一のクリアリング機関(CCP:中央相手方)に預けられているが、仮想資産取引所では、資産が異なるカストディアンに分散され、それぞれが独立して運営されている。ちょうど、全員のお金が一つの袋に入っている状態なら取引はその中でやり取りできるが、今は他人の財布からお金を出す必要がある。空っぽかどうか、遅すぎないか、数量が正しいか――こうしたリスクが取引に新たに加わることになる。
もちろんこれは極端な例であり、大多数の正規ライセンス取得済み取引所のカストディ体制は十分な専門性と安全性を備えている。だが、香港はより安定したクロスボーダー流動性共有を実現するために、以下の要求を定めている。
-
統一ルールにより、取引の公正性・秩序・責任追及可能性を確保: 通達第9条は、注文帳簿の共有には、すべての参加プラットフォームが取引全体を通して共有注文帳簿を使用する手続きおよび操作を明示する包括的なルールを策定することを義務付けている。これらのルールは、香港および海外のプラットフォーム、カストディアン、ユーザーを含むすべての関係者に対して拘束力を持ち、強制執行可能でなければならない。前払いの方法、注文の発出、取引の執行、決済方法、違反処理、責任変更の取り扱い(該当する場合)、各参加者の役割、権利、義務、責任などを含む。
-
全額前払いの強制と自動検証により、資産の引き渡しが可能であることを保証: 通達第10条は、取引所が自動化された事前検証メカニズムを構築し、リアルタイムで取引指示が以下の条件を満たしているか自動的に検証しなければならないと規定している:全額前払い、資産がすでにカストディされている、数量が十分である。
-
引渡し対決済(Delivery-Versus-Payment, DVP)決済メカニズムを構築: DVPは金融決済メカニズムの一種で、多くの伝統的証券市場で広く使用されている。DVPを採用することで、資産の引渡しと支払いが同時に発生する場合のみ決済が成立し、買い手が商品を受け取る瞬間が売り手が代金を受け取る瞬間となる。そうでなければ決済は行われない。これが時系列リスクを回避する最も効果的な方法である。実現方法としては、買い手と売り手がまずそれぞれの資産を準備し、クリアリングシステムが双方の条件を確認してから移転を完了する。これは典型的な中心化取引所の手法である。香港は仮想資産領域においても、伝統的証券クリアリング機関レベルのDVP相当の安全性を実現し、「決済失敗」リスクを解決しようとしている。
-
毎日の清算および日内決済を保証: 通達第14条および第15条は、香港のプラットフォームが毎日少なくとも一度は海外プラットフォームと取引を決済し、日内決済を行い、「未決済取引上限」を設定して、クロスボーダー未決済取引が雪だるま式に膨らむことを防ぐよう規定している。
-
補償措置: 通達はプラットフォームの補償措置を規定しており、核心はクロスボーダー決済リスクを取引所自身が負担することである。つまり、香港のプラットフォームは全責任を独自に負い、リスクを海外プラットフォームに転嫁できない。海外ユーザーの違約、海外プラットフォームの決済失敗などがあった場合でも、香港プラットフォームは顧客に賠償しなければならない。
法的根拠:
通達第16条は次のように規定している。「注文帳簿の共有を提供するプラットフォーム運営者は、共有注文帳簿の管理に必要な堅牢な財務能力を有していることを証明しなければならず、共有注文帳簿を通じて実行された取引に関して、あたかもその取引が自らの注文帳簿上で実行されたかのように、顧客に対して全責任を負うものとする。」
また、補償準備金はプラットフォーム資産とは別に独立して保有され、信託形態で明確に管理され、補償専用とされなければならない。さらに、補償準備金の規模は未決済取引上限以上でなければならず、プラットフォームが行うクロスボーダー取引が増えれば増えるほど、準備金もそれに応じて多く用意しなければならない。
法的根拠:
通達第17条は次のように規定している。「プラットフォーム運営者は香港に補償基金を設立し、これを信託形態で保有し、顧客補償に指定しなければならない。これは決済失敗により生じた顧客の損失を補填するためのものである。補償基金の規模は未決済取引上限以下であってはならず、予想される未決済取引リスクに応じて調整されなければならない。」
通達第18条は次のように規定している。「『仮想資産取引所ガイドライン』第10.22項に基づき、プラットフォーム運営者は、カストディ中の顧客仮想資産の潜在的損失に対する補償措置を設けなければならない。決済資産の引渡しに関しても、プラットフォーム運営者の顧客は同等の保護を享受すべきである。したがって、プラットフォーム運営者は、保険4への加入または補償措置の設置を通じて、盗難、詐欺、横領などによる損失を含む決済資産の潜在的損失に対する保護を提供しなければならず、その金額は『仮想資産取引所ガイドライン』第10.22項が求める金額以上でなければならない。」
三、規制の背後にある技術的課題
業界の観点から見ると、香港政府が取引所の流動性を高めたいのは明らかであるが、同時に高いハードルも設けており、香港特有の「足かせをはめたダンス」スタイルを反映している。これはSFCの「小刻みにすばやく進む」という発展原則にも合致している。背景には、香港の政治的・金融的地位の特殊性はもちろんあるが、暗号資産サラダは、技術的課題も規制の潜在的な推進要因だと考える。
実際、VATPがクロスボーダー流動性共有を実現する際の最大の難点は、規制要件を満たすことや資金準備の金額に達することではなく、むしろ技術的な問題である。通達は「共同管理」「接続」といった抽象的な言葉でプラットフォーム間の技術協働を説明しているが、実際には取引経路、マッチングシステム、決済プロセス、リスク管理モジュール間の技術的相互運用性という問題に直面しなければならない。専門技術チームにとって、真の技術的難関は「接続できるか」「どう接続するか」ではなく、「コンプライアンス枠組みの中で安全に接続し、安定的に稼働させ、責任追及可能な形で決済を完了するか」なのである。
さらに、コンプライアンスの観点からは、各国・地域における越境データ保護基準が一様ではない。どのデータが越境・共有可能なのか、誰が責任を負うのか? 「関連プラットフォーム」にはより明確な定義があるのか? 例えば、OSLとBybitの間に隠れた株式関係があれば、彼らは関連プラットフォームに該当し、流動性を共有できるのか? 同一グループの海外法人であっても、ITシステムやリスク管理モジュールが全く異なる場合、これは「関連プラットフォーム」に該当しないのか? これらは法律家が注目するほんの一握りの細部に過ぎない。
越境流動性共有は、一見すると単に二つのシステムを接続するだけに見えるが、実際には大規模M&A並みの深い統合プロジェクトである。関連プラットフォーム間の接続を限定するのは一時的な対応にすぎず、完全に開放された状況で、すべてのコンプライアンス細部を正確に実行できるようになることが、業界が直面する真の課題なのである。
四、暗号資産サラダの評論
この通達は、再び香港の規制姿勢を示している:解放しないわけではないが、コンプライアンスのもとでのみ解放する。規制基準が弱い、またはコンプライアンス能力が不足する海外プラットフォームは、この体制に参加することは難しい。国際的なプラットフォームが香港の共有注文帳簿に接続したい場合は、自らの監視システムを強化しなければならない。
実務の観点から見ると、香港の市場に十分な魅力があるのか? 海外取引所に自らの一部を再構築させ、香港のピースに合わせさせるほどのインパクトを与えることができるのか? サラダは、影響はあると考えるが、それはすでにグローバル規模でのコンプライアンス事業を目指しているプラットフォームにしか影響しない。規制の空白に依存して生き延びている個人向けプラットフォームにとっては、今の時点で香港市場に参入するのはまだ適切なタイミングではない。
TechFlow公式コミュニティへようこそ
Telegram購読グループ:https://t.me/TechFlowDaily
Twitter公式アカウント:https://x.com/TechFlowPost
Twitter英語アカウント:https://x.com/BlockFlow_News














