FX・CFD ブローカーの流動性ブリッジ：ブリッジを買うか、トレーディングプラットフォームが提供するものを使うか、自社で作るか

流動性ブリッジとは、MetaTrader 5 や cTrader のようなブローカーのトレーディングプラットフォームを、流動性プロバイダーにつなぐソフトウェアである。流動性プロバイダーとは、ブローカーに価格を提示し、その注文を約定させる銀行やブローカーのことだ。ブリッジは、それらの価格を取り込み、ブローカーのマークアップ、つまり顧客が目にする前にブローカーがプロバイダーの価格に上乗せする額を加える。ブリッジは顧客の注文ごとに、その注文をプロバイダーに流すか、ブローカー自身のブックに残してブローカーが相手方になるかを決める。ブリッジは、買うことも、プラットフォームの開発元が提供するツールを使うことも、自社で作ることもできる。どれを選ぶかは、運用するプラットフォームとプロバイダーの数、そしてルーティングルールが自社の売り物の一部なのかどうかで決まる。どの道を選んでも、自社が負う義務は同じである。

流動性ブリッジは、ブローカーのために何をするのか

プラットフォームが顧客の注文をチェックし終えると、そこからはブリッジが引き継ぐ。ブリッジの仕事は五つある：

• 各プロバイダーの価格を取り込み、たとえばプロバイダー全体での最良価格に自社のマークアップを加えるといった形で、顧客が目にする価格を組み立てる
• ルーティングルールを適用する：どの注文を外に出し、どのプロバイダーに送り、どの注文を自社のブックに残すか
• 外に出す注文を一つずつ送り、約定、つまり実際に取引された価格と数量か、または拒否を受け取る
• エクスポージャー、つまり顧客に対して自社が抱えるポジションを追跡し、それにリスク上限を適用する
• すべての価格、注文、約定、拒否を、時刻とともにログに記録する

各プロバイダーとの接続には、銀行、ブローカー、取引施設が使う共通のメッセージ形式である FIX がよく使われる。FIX を管理する FIX Trading Community によれば、FIX は「注文、執行、マーケットデータ」といったメッセージを扱う。

ブリッジがしないことは何か

次の四つは、ブリッジではなく、事業のほかの部分が担う：

• 流動性。各プロバイダーとの口座と契約は、引き続き必要になる。MetaTrader 5 の開発元である MetaQuotes は、プロバイダーを接続する手順の一つとして「契約を締結する」を挙げている
• トレーディングプラットフォームが管理する、顧客の口座、残高、証拠金
• 執行方針、つまり顧客の注文の扱い方を定めた書面のルールと、リスク上限。これらは自社のスタッフが決め、ブリッジはそれを適用する
• 自社の側の誰かが引き続き行う、自社の記録と各プロバイダーの取引明細との照合

A-book、B-book、ハイブリッドのルールはどこにあるのか

ブリッジの中か、プラットフォームのうちブリッジの役割を果たす部分にある。それぞれの用語は、顧客の取引がどこに行くかを表している：

• A-book：顧客の取引をプロバイダーに流す。市場リスクはプロバイダーが負い、自社はマークアップと、あれば手数料を得る
• B-book：取引を自社のブックに残し、自社がその相手方になる。顧客が損をすれば自社が得をし、その逆もまた同じである
• ハイブリッド：顧客グループ、銘柄、注文サイズ、あるいは自社のオープンポジションに応じて、各取引をどちらに回すかをルールが決める。一つのルールで、取引の一部を外に流し、残りを自社に残すこともできる

MetaQuotes は、MetaTrader 5 向けのマッチングエンジンである Ultency について、こう述べている：「A-Book、B-Book、部分ヘッジ執行のあいだで、注文のルーティングを管理できる。」どの製品を選ぶにしても、その前に、各ルールを平易な言葉で、注文の例とともに書き出しておく。そのうえで、製品がそれを正確に適用するかを確かめる。

ルールは、プロバイダーが拒否した注文にどう対応するかも決めていなければならない。プロバイダーの中には、注文が届いたあとでそれを断れるラストルックという仕組みを使うところもある。FX Global Code は、Global Foreign Exchange Committee が管理する、外国為替のホールセール市場における望ましい慣行の原則をまとめたものである。同コードはラストルックを、取引の依頼を受けた側が「提示した価格に照らして、その依頼を受け入れるか拒否するかの最終的な機会を持つ」慣行だと説明している。同コードの原則17は、ラストルックを使う業者は「その使用について透明性を保ち、顧客に適切な開示を行うべきである」としている。同コードは任意のものであり、市場参加者に「法的または規制上の義務を課すものではない」と述べている。

拒否された注文をブリッジがどう扱うかを決めておく：次のプロバイダーに送るか、自社のブックから約定させるか、拒否するかである。どれを選ぶかによって、自社のリスクも、顧客の目に映るものも変わる。

規制当局は、ブリッジの中のルールに何を求めているのか

EU では、MiFID II の第27条が、投資サービス業者に対し、「注文を執行する際に、顧客にとって可能な限り最良の結果を得るための十分なあらゆる措置」を講じることを求めている。同条が挙げる要素は、「価格、コスト、スピード、執行と決済の可能性」から始まる。

業者の注文執行方針には、「投資サービス業者が顧客の注文を執行するさまざまな執行場所と、執行場所の選択に影響を与える要因」についての情報が含まれていなければならない。ブローカーの場合、その選択はブリッジの中で行われるので、方針とルーティングルールは一致していなければならない。業者はまた、注文執行の体制と方針の「有効性を監視」しなければならない。実際には、ブリッジの記録をプロバイダーごとに見直すということだ。

取引所やその他の取引施設で取引されない商品は、店頭（OTC）商品と呼ばれる。EU の市場監督当局である ESMA は、公表している Q&A の一つでこれを扱っている。そこでは、MiFID II 委任規則の第64条が、業者に「顧客に提示する価格の公正さを確認する」ことを求めていると説明している。この回答は2016年のもので、いまも ESMA のウェブサイトに掲載されている。さらに、その狙いは業者が「価格設定の判断を正当化できるようにする」ことにあると付け加えている。マークアップを加えたり、取引を自社のブックに残したりするなら、各プロバイダーの価格を、顧客が受け取った価格と並べて保存しておく。

この記事の出典はすべて2026年11月3日に閲覧した。規制については、EU のルールと ESMA のガイダンスだけを引用している。ほかの国にはそれぞれ独自のルールがある。

どの道を選んでも変わらないものは何か

こうした仕事は、どの道にも存在する。変わるのは、誰がソフトウェアを書き、運用するかだ：

• 価格フィードとマークアップ：各顧客グループにどのプロバイダーの価格を流し、それに何を上乗せするのか
• ルーティングルール：A-book、B-book、ハイブリッドのどれにするのか、そしてプロバイダーが注文を拒否したときにどうなるのか
• リスク上限：各銘柄について、どれだけのエクスポージャーを手元に残してから外に流すのか
• 各プロバイダーとの FIX セッション。どのセッションも、そのプロバイダーと一緒に設定し、テストする
• 記録と照合：すべての注文と約定を、各プロバイダーの取引明細と毎日突き合わせる
• フェイルオーバー：あるプロバイダーとの接続が切れたときに、価格と注文を別のプロバイダーに移すこと

フェイルオーバーは、最も入念にテストすべき部分である。注文の途中で接続が切れたら、ブリッジは、さらに注文を送る前に、その注文が約定したかどうかを確かめなければならない。FIX Trading Community のセッション標準によれば、FIX のセッション層は「電子取引のための、信頼性が高く復旧可能なメッセージングを提供する」ために使われる。メッセージには番号が振られており、欠番に気づいた側は、欠けたメッセージをもう一度送るよう求める。

ベンダーやプラットフォームがこの仕事の一部を代わりに担うことはできるが、そのすべてについて責任を負うのは、やはり自社である。

ブローカーがブリッジ製品を買うべきなのはどんなときか

自社のニーズがベンダーのほかの顧客のものと似ているなら、買う。典型的な兆候は次のとおり：

• 複数のトレーディングプラットフォームを運用している、またはその予定があり、それらにまたがって共通のルーティングルールを使いたい
• 複数のプロバイダーがすぐに必要で、ベンダーがすでにほかのブローカーのためにそれらと接続している
• チームが小さく、仕様が変わったときにプロバイダーとの接続を保つ作業は、ほかの誰かに任せたい

その代わりに手放すのは、主導権である。自社のルールは製品の設定に合わせなければならず、足りない機能はベンダーの計画を待つことになる。ホスティング型のブリッジでは、顧客の注文が、自社が運用していないサーバーを通ることにもなる。

トレーディングプラットフォームのツールで足りるのはどんなときか

顧客の大半が一つのプラットフォームで取引していて、使いたいプロバイダーがすでにそのプラットフォームに接続しているときである。MetaQuotes は、「MetaTrader 5 には、Ultency による流動性アグリゲーションと注文マッチングのための組み込みのソリューションが含まれている」と述べている。アグリゲーションとは、複数のプロバイダーの価格をまとめて、顧客が目にする価格にすることだ。MetaQuotes は、「Ultency とのネイティブな接続」を持つプロバイダーを自社のサイトで一覧にしており、プロバイダーや取引所へのコネクターを指す同社の呼び名であるゲートウェイも提供している。

cTrader の開発元である Spotware は、ブローカーを新しいプロバイダーと FIX で接続できる。流動性のための FIX についての同社のページによれば、Spotware はプロバイダーの FIX 仕様を入手し、「専用のサーバーアダプターを構築する」。

この道は、運用する部品が最も少ない。MetaQuotes は、Ultency では主な銘柄と取引セッションの設定が「MetaTrader 5 で一度だけ設定される」と述べている。限界は、ルールが一つのプラットフォームの中にあることだ。プラットフォームの開発元がまだ対応していないプロバイダーは、開発元の計画を待つことになる。二つ目のプラットフォームを加えるなら、ルールを設定し直すか、両方に対応するブリッジに移ることになる。

自社でブリッジを作る価値があるのはどんなときか

次のうち少なくとも一つが当てはまるときである：

• ルーティング、価格設定、ヘッジのルールが自社の売り物の一部であり、試した製品ではそれを書かれたとおりに適用できない
• 取引量に応じて増えるブリッジの料金が、いまでは自社のシステムを運用するチームのコストを上回っている
• すべての価格、注文、約定を、自社が選んだ構造で、自社が管理するサーバーに置きたい

すべてを置き換える必要はない。多くの場合、それは、購入したブリッジやプラットフォームのツールと並べて置く一つの部品で、たとえば独自のヘッジのルールや記録である。MetaTrader 5 では、自社のブリッジはプラットフォームのインターフェースを通じて接続される。MetaQuotes は、同社の「Gateway API は、MetaTrader 5 をほかの取引システムと統合し、独自のデータフィードを作成するために使われる」と述べている。Spotware は自らについて「プラットフォーム・アズ・ア・サービスを提供している」と述べ、ブローカー向けのページでは、cTrader の「完全なテクノロジースタック」がロンドンとニューヨークのデータセンターでホストされているとしている。だから、自社のブリッジがどのインターフェースを使うことになるのかを Spotware に尋ねる。

ローンチの後は、顧客が取引できるすべての時間帯にアラートに対応し、各プロバイダーとの接続が変わるたびにテストし直す人が必要になる。その担当者がいないなら、購入したブリッジかプラットフォームのツールから始める。

ブリッジの契約に署名する前に、何を確認すべきか

• 自社の注文フロー、つまり顧客の注文を見られるのは誰か。サーバーはどこで動いていて、ベンダーの誰がアクセスでき、ベンダーのグループ内に流動性プロバイダーやブローカーを兼ねる会社はあるのか
• すべての価格、注文、約定、拒否、ルールの変更を、文書化された形式で、契約を終えたあとも含めていつでもエクスポートできるのか
• 契約終了の条件はどうなっているのか。通知期間、ルーティングルールと銘柄設定のエクスポート、別のブリッジへの移行の支援はどうか
• 取引量が2倍になると、料金はどう変わるのか。MetaQuotes は Ultency の料金体系を「取引量ベース」と説明している。Spotware は、自社のブリッジ製品である cBridge の料金は「関係するサーバーと接続の数に基づく」としている。
• どのプロバイダーが、いまほかのブローカーのもとで稼働しているのか。どれがまだ計画段階にすぎないのか
• 自社のディーラーが、ルーティングルールとマークアップを自分たちで変更でき、その変更がすべてログに記録されるのか
• プロバイダーが注文を拒否したときや、プロバイダーとの接続が切れたときにどうなるのか。そのルールは誰が選ぶのか
• ベンダーのサポート時間は、自社の顧客が取引できるすべての時間帯をカバーしているか

コード、ルーティングルール、取引の記録は誰のものか

ブリッジのコードはベンダーのものであり、プラットフォームはその開発元のものである。ルーティングルールとマークアップは自社のビジネスロジックだが、製品の中ではベンダーの形式で保存されている。自社で読める形式のエクスポートを求め、すべてのルールについて、書面の控えを自社で持っておく。

取引の記録は二つに分かれている。プラットフォームが持つのは顧客側、つまり口座、注文、ポジションである。ブリッジが持つのはプロバイダー側、つまりどのプロバイダーがどの注文を、いつ、どの価格とマークアップで受け取り、何が返ってきたかである。顧客や規制当局に答えるには、その両方が必要だ。たとえば MetaQuotes は、Ultency のログには「ブローカーだけがアクセスできる」と述べている。同じ答えを、すべてのベンダーから書面で得ておく。

自社で作れば、コードも所有できる。契約にはそう明記し、開発会社が保持するコンポーネントを、それらを自社が使い続けられるライセンスとともに列挙しておくべきだ。

ブリッジの構築を任せる会社に何を聞くべきか

• ブリッジはどのプラットフォームに接続し、それぞれのどのインターフェースを使うのか
• どのプロバイダーに、どの FIX バージョンで最初に接続するのか。それぞれとの接続テストは誰が手配するのか
• 自社のディーラーは、開発者に頼らずにルーティングルールとマークアップをどう変更し、変更の一つひとつはどうログに記録されるのか
• 注文の途中で接続が切れたら、取引を再開する前に、ブリッジはその注文がどうなったかをプロバイダーにどうやって確認するのか
• 別のプロバイダーへのフェイルオーバーはどう機能し、そのあいだ顧客には何が見えるのか
• 各顧客価格がどう決まったのかをあとで示せるように、プロバイダーの価格を顧客価格と並べて、どのように保存するのか
• 各プロバイダーの取引明細との毎日の照合はどう行われ、差異があれば誰に知らされるのか
• いま稼働しているシステムで、これが動いているところを見せてもらえるか

amBrain はどこに位置づけられるか

このブログを発行しているのは amBrain である。amBrain は、仕事のこの分野を一行でこう説明している:「amBrain はアルゴリズム取引の基盤を構築する:注文執行、マーケットデータ、プレトレードのリスク管理。」amBrain のウェブサイトには、もう一行こうある:「トレーディングターミナルの開発、注文管理システム、FIX プロトコルによる取引所連携。」

amBrain は2019年からソフトウェアを作っている。顧客との仕事の進め方については、こう述べている:「三つの形態:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。」所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」署名の前に、そのコンポーネントを名前で列挙した一覧を求めること。

この記事は事例紹介ではなく、顧客のための仕事についても述べていない。amBrain がいずれかの顧客のために流動性ブリッジを構築、購入、接続したとは述べていない。MetaQuotes、Spotware、FIX Trading Community、Global Foreign Exchange Committee、ESMA は、それぞれが公開しているページから引用しており、この記事は、amBrain とそれらのいずれかとのあいだに何らかの関係があるとは主張しない。amBrain の価格や期間も示さない。

この記事は法的助言でもない。自社に適用されるルールは弁護士に確認する。amBrain が候補リストに入っているなら、ほかのどの会社とも同じ質問をすること。