ブローカー、ファンド、トレーディング会社のためのFIX接続：ホスティング型ネットワーク、ライセンス型エンジン、自社開発のゲートウェイ

FIXはFinancial Information Exchangeの略で、トレーディング会社が注文を送り、約定を受け取るための標準のメッセージ形式です。FIX接続とは、各ブローカーや取引所への実際の接続のことで、ログインしたままのセッションが維持され、中断のあとにメッセージを一つも失わずに復旧するものです。この接続は、ホスティング型ネットワークから借りることも、FIXエンジンをライセンスして自社で運用することも、自社でゲートウェイを作ることもできます。どれを選んでも、人員、すべてのカウンターパーティーとのテスト、誰かが対応しなければならない時間帯の確保を見込んでおく必要があります。

FIXとは何で、誰が保守していますか？

FIX Trading Communityは、自らを「FIXプロトコルの管理者」と称しています。標準については「電子取引と取引処理のための、オープンで技術に依存しない仕様」と説明しています。このプロトコルは「どのような業務情報が交換され、それが何を意味するかを定義する」もので、株式、債券、通貨、デリバティブにまたがる注文、約定、気配値、マーケットデータを扱います。

実務では二つの層が重要です。アプリケーション層は、新規注文や約定報告といった業務メッセージを運びます。セッション層は、接続を維持します。FIX Trading Communityの技術標準のページは、このプロトコルが「セッションを通じて、二者間の信頼できる双方向の通信を可能にする」と述べており、メッセージの順序と連続したシーケンス番号がその前提です。

2026年に重要なFIXのバージョンはどれですか？

FIX Trading Communityはこう述べています。「FIX Latestの使用を強く推奨します」。従来の実装を持つ会社については、「FIXプロトコルのバージョン4.2と4.4は、FIX Trading Communityが引き続きサポートしている」とし、それ以外のバージョンはもうサポートされていないと付け加えています。どのバージョンで話すかは、カウンターパーティーが決めます。4.2を使っているブローカーは、御社が新しいほうを好んでも移行しません。どの製品を選ぶ前にも、各カウンターパーティーが提供するバージョンを一覧にしてください。

ホスティング型のFIXネットワークや接続プロバイダーは何をしますか？

御社はプロバイダーに1回接続するだけで、先方のブローカー、取引所、顧客へのセッションはプロバイダーが保持します。以下は各プロバイダー自身の説明で、2026年11月10日に閲覧したものです。

• Broadridgeは「ウェブベースのインターフェースを通じて、FIXカウンターパーティーのオンボーディングと即時の認定を自動で実施する」としており、「完全または一部のマネージドソリューションとして導入できる」と述べています。
• Iressは、同社のFIX Hubを「ロータッチのオンボーディングとFIXの加工を備えた、エンドツーエンドの完全マネージドサービス」と説明し、カウンターパーティーへは「一つの接続パートナー、接続、認定を通じて」アクセスできるとしています。
• Rapid AdditionのRA Hubは「オンプレミス、クラウド、ハイブリッドの各デプロイメントに対応する」とあるため、セッションを誰が保持するのかを確認してください。同社は、カウンターパーティーとの接続サービスについて、「顧客のオンボーディングを簡素化・迅速化し、顧客体験を改善し、取引開始までの時間を短縮すること」を目指していると述べています。

主張はそれぞれ、自社のカウンターパーティーでテストしてください。三つのページのいずれにも、価格は書かれていませんでした。

ホスティング型のプロバイダーで手放すものは何ですか？

注文が通る経路と、変更のタイミングについての制御を手放すことになります。注文は他社のサーバーを通ります。Iressは「FIXの加工」に触れ、Broadridgeのマネージドサービスは「正規化サービス」を使っています。私たちはどちらも、プロバイダーが転送中にメッセージを変更することだと読みましたが、どのフィールドをどう変更するのかは、どちらのページにも書かれていません。変更するフィールドを具体的に確認し、元のメッセージと変更後のメッセージを並べて見られるかを尋ねてください。

プロバイダーが停止した場合に、取引所で約定待ちの注文を取り消す別の経路が必要です。その手順は書面でもらってください。

ライセンス型またはオープンソースのFIXエンジンを運用するには何が必要ですか？

エンジンは、FIXのセッション層を代わりに扱うライブラリです。OnixSは、自社のエンジンを、.NET、C++、Javaで書かれた「金融情報交換（FIX）プロトコルの高速な実装」と説明しています。「差し替え可能なセッション状態とメッセージストレージ」のサンプルコードが付属し、「低コストで十分なサポートを受けられるサブスクリプション方式」で提供されます。同社のページに価格はなく、30日間の無料評価版が用意されています。オープンソースのエンジンにはライセンス料がかかりません。QuickFIX/Jのページは、質問用にメーリングリストとStack Overflowのタグを案内しています。QuickFIXプロジェクトのサイトには商用サポートも載っているので、サポートを購入するか、自社のスタッフで対応するかのどちらかになります。

エンジンは、仕事のうちの小さな部分です。次の作業は引き続き自社で行います。

• カウンターパーティーごとのセッション管理：接続時間、認証情報、シーケンス番号のリセット。
• メッセージの保存。再起動のあとに再送要求（カウンターパーティーが受け取れなかったメッセージを求めてくること）に応じるためです。
• 各取引所やブローカーとの認定。接続やメッセージに影響しうる変更があるたびに、やり直します。
• セッションが切れたことを、担当者にすばやく知らせる監視。
• 取引する市場が開いているすべての時間帯を担うスタッフ、またはローテーション。

認定とは何で、どれくらい有効ですか？

認定とは、ソフトウェアが本番で取引する前に、取引所やブローカーが課すテストです。ASXはこう述べています。「すべての顧客アプリケーションは、本番市場にアクセスする前に、ASXの適合性確認プロセスに合格しなければならない」。テストを予約する前に、ソフトウェアが「本番稼働可能な状態」であることを求めています。さらに、「基準を満たさないソフトウェアによる本番システムへのアクセスを遮断する権利」も留保しています。

このテストは一度きりではありません。ASXは、顧客がやり直さなければならない場合を挙げており、その一つが、ソフトウェアが「ASXとの接続またはメッセージに影響しうる、あるいは直接影響するかたちで変更された」ときです。ホスティング型のプロバイダーが取引所と過去に行ったテストが、御社の注文にも通用するのか、それとも自社でテストを行う必要があるのかを確認してください。

プロトコルの範囲はどこまでで、自社の作業はどこから始まりますか？

FIXは標準ですが、カウンターパーティーはそれぞれ独自のルールを加えます。FIX Trading CommunityがFIX Orchestraを作ったのは、このためです。それは「カウンターパーティー間の、機械可読な取り決めルールとして考案」されたもので、新しい取引相手を稼働させるまでの時間を短くすることを狙っています。ルールブックが役立つのは、カウンターパーティーがそれを公開している場合だけです。ASXとロンドン金属取引所は、PDF文書で公開しています。

公開されている取引所とブローカーの文書二つを見ると、ルールがどれほど違うかが分かります。Paxosは、暗号資産ブローカレッジのドキュメントで、こう述べています。「Cancel on Disconnectは、デフォルトで有効」。また、「すべてのセッションで、毎週、強制的に切断し、シーケンス番号をリセットする」とも書いています。ロンドン金属取引所の仕様は、ログアウトの扱いが異なります。「ゲートウェイは、ユーザーの非永続の注文を自動では取り消さない」。ユーザーは、各注文につけるフラグで、接続が失われたときの取消しを求めることができます。

自社の作業とは、注文の状態です。つまり、各注文について自社のシステムが何を把握しているか、そしてカウンターパーティーと食い違ったときにどうするかです。カウンターパーティーごとに、そのメッセージから自社の状態への対応表が必要で、拒否、部分約定、約定後に届く取消し、訂正までを網羅します。これは自社の業務ルールに依存するため、エンジンもホスティング型ネットワークも代わりに書くことはできません。

レイテンシーが重要になるのはどんなときですか？

収益が、価格に最初にたどり着けるかどうかで決まるときです。顧客の注文をルーティングするブローカーや、数時間かけて注文を執行するファンドにとっては、通常、信頼性のほうが重要です。OnixSは、自社のエンジンを「ミッションクリティカルで超低レイテンシーの、高頻度取引のインフラ向けに特別に設計されている」と説明しています。これはベンダーの主張であり、同社のページに数値は示されていません。

自分で測ってください。取引が活発な日に、自社のシステムが注文を送った時刻と、対応する約定報告が届いた時刻を記録します。ホスティング型ネットワークでは、プロバイダーのシステムがその経路に入ります。それが自社にとって問題かどうかは、自社の数字だけが示します。取引でミリ秒が重要な理由と、取引所のコロケーションについての記事もご覧ください。

注文の途中でセッションが切れたら、どうなりますか？

考えられる状況は四つあります。注文が取引所に届いていなかった。まだ取引所で約定待ちである。全部または一部が約定したが、その報告が戻る途中で失われた。あるいは、取引所が切断を検知して取り消した。システムは、注文を二重に送らずに、どれなのかを突き止めなければなりません。

セッション層が助けになります。セッション中の欠落について、LMEの仕様には「クライアントは、失われたメッセージを復旧するために、再送要求（35=2）メッセージを使用できる」とあります。中断後のログオン時には、欠落は自動的に埋められるはずで、「どちら側も、受信したログオンメッセージのMsgSeqNum（34）に基づいて再送要求（35=2）を生成してはならない」としています。また、ゲートウェイは「クライアントが開始したメッセージの再送の可能性を処理しない」とも述べています。さらに「ClOrdID（11）が重複するメッセージは、クライアント注文IDの一意性チェックに基づいて拒否される」と付け加えています。つまり、ゲートウェイは同じ識別子を繰り返す再送を拒否し、新しい識別子で送られたものは通常の注文として処理します。最初の注文がどうなったかを確認してから、新しい識別子で再送してください。

契約する前に、ベンダーとこのテストを行ってください。注文が約定待ちの状態で接続を落とし、再接続して、双方が把握している内容を突き合わせます。自社開発するチームは、これをスクリプト化し、リリースのたびに繰り返すべきです。

市場に接続するとき、どんな義務が適用されますか？

ルールは国と、会社の種類によって異なります。そのため、この節は弁護士と話すときの地図として使ってください。引用は、各制度の全体ではありません。

• EU。EUの金融商品市場に関する指令であるMiFID IIの第17条は、EUの市場規制当局であるESMAが、オンラインのルールブックで公開しています。アルゴリズム取引を行う投資会社は、システムが「回復力を持ち、十分な処理能力を備える」ように、「効果的なシステムとリスク管理を整備しなければならない」と定めています。高頻度の手法を使う会社は、「注文の取消しを含め、発注したすべての注文の、正確で時系列に沿った記録」を保存しなければなりません。
• EUのテスト。委任規則2017/589の第6条は、通称RTS 6で、アルゴリズム取引を行う投資会社を対象としており、会社は取引所との間で「アルゴリズム取引システムと取引アルゴリズムの適合性をテストしなければならない」と定めています。これには「スポンサードアクセスの取り決めを通じて、その取引所に初めて接続するとき」が含まれます。スポンサードアクセスとは、他社の取引コードのもとで、その会社のインフラを使わずに、取引所へ直接注文を送ることです。第12条は、会社が接続しているすべての取引所で、未執行の注文を「緊急措置として直ちに取り消す」能力を求めています。
• 米国。SEC規則15c3-5は、市場アクセスを持つブローカー・ディーラーに、「リスク管理の統制と監督手続のシステムを確立し、文書化し、維持する」ことを求めています。統制は「合理的に設計されている」ことが必要で、「適切な価格または数量のパラメータを超える注文を拒否することで、誤発注を防止する」ものでなければなりません。また、「ブローカーまたはディーラーの直接かつ排他的な管理下」になければなりません。例外が一つあり、特定の規制上の統制を、登録ブローカー・ディーラーである顧客に、書面の契約で割り当てることができます。最高経営責任者は、それらを「毎年、証明しなければならない」。
• FINRA。2015年3月26日に公表されたRegulatory Notice 15-09は、アルゴリズム取引を行う会社に向けて、推奨される効果的な実務を挙げています。その中に「テストは、コード開発から独立して行う」ことや、「会社がアルゴリズムまたはそれを支えるプラットフォームをすばやく無効にできる仕組み」があります。

英国については、2025年8月21日に公表されたFCAのレビューが、アルゴリズム取引を行う会社は「RTS 6の第6条に従い、アルゴリズムと取引所またはダイレクト・マーケット・アクセス提供者のシステムとの適合性をテストしなければならない」と述べています。また、その手続が「取引所ごとに大きく異なる」と述べた会社があったことも報告しています。この記事はFCAハンドブックを引用していないため、アルゴリズム取引に関する章について弁護士に確認してください。

制度と会社の取引の仕方によっては、これらのルールが、すべての取引所のすべての注文を取り消す手段、時刻を付した注文記録、テストの証拠を意味することがあります。ホスティング型のプロバイダーが、その一部を提供できる場合があります。

自社開発のゲートウェイが妥当なのは、どんなときですか？

収益に結び付く要件が、試したどの製品でも満たせないときに開発してください。目安となる兆候は次のとおりです。

• 注文の状態ロジックが戦略の中核で、メッセージを編集したり滞留させたりするプロバイダーが邪魔になる。
• 各注文の前に、それを送るのと同じプロセスの中でリスクチェックを走らせる必要がある。プレトレードリスクのホットパスについての記事で扱っているとおりです。
• ホスティング型ネットワークの費用を、数年にわたりすべてのセッションで合計すると、自社運用のチームの費用を上回る。

エンジンのライセンス料が高く見えるからといって、開発してはいけません。認定、監視、市場の時間帯のローテーションは、どの経路でも自社に残ります。当社のターミナルの記事では、自社保有のFIXコアの一般的な設計を説明しています。

プロバイダーとの契約を終えたとき、何が手元に残りますか？

それは契約次第なので、始める前に決めておいてください。認定がプロバイダーのセッションに紐づいていて、経路を変えるとテストがやり直しになるのかを確認します。メッセージ履歴がどこにあるか、そして、認証情報とネットワークアドレスについて、各カウンターパーティーが誰の名前で登録しているかも確認してください。

契約する前に、すべてのメッセージを読める形式でエクスポートしてもらえるかを確認してください。カウンターパーティーの同意を得てセッションを引き継ぐ権利と、再テストに足りる長さの通知期間も求めてください。エンジンの場合は、セッションと履歴が自社に残り、自社開発の場合は、契約で定めていれば、コードも自社のものになります。

ベンダーや、開発を請け負う会社には、何を質問しますか？

• 当社のカウンターパーティーのうち、すでに接続しているのはどこですか。また、どのFIXバージョンと認定日を示せますか？
• 転送中に変更するフィールドはどれですか。また、各メッセージの変更前と変更後の両方を確認できますか？
• 当社のセッションまたは貴社のセッションが切れたとき、約定待ちの注文はどうなりますか。実際に動かして見せていただけますか？
• 当社のスタッフだけで、貴社に連絡せずに、すべての取引所のすべての注文を取り消せますか？
• メッセージ履歴はどこに、どれだけの期間保管され、どの形式でエクスポートできますか？
• 当社がソフトウェアを変更したとき、あるいは取引所がルールを変えたとき、認定のやり直しは誰が行いますか？
• 各市場の時間帯に、誰が待機していますか。また、応答時間を書面で示していただけますか？

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

amBrainはこのブログを公開しています。同社はトレーディング関連の仕事の一部を、次のように説明しています。「amBrainは、アルゴリズム取引のインフラを構築します。注文執行、マーケットデータ、プレトレードのリスク管理です。」トレーディングとフィンテック向けのサービスカードには、「トレーディングターミナル開発、注文管理システム、FIXプロトコルによる取引所連携。」とあります。これはサービスの説明にすぎません。

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

この記事は事例紹介ではなく、顧客の仕事を述べるものでもありません。amBrainが、いずれかの顧客のためにFIXゲートウェイ、接続製品、ホスティング型ネットワークを構築したことを示す記述は、この記事にはありません。引用は、FIX Trading Community、上に挙げたベンダーと取引所、ESMA、FINRA、FCA、米国連邦規則集、legislation.gov.ukが公開しているページによるものです。この記事は、amBrainとこれらの各者との間に関係があるとは主張せず、いずれの製品も推奨せず、amBrainの価格や期間も示していません。

これは法律や投資に関する助言でもありません。御社に適用される規則は、取引を行う各市場の弁護士に確認してください。amBrainを候補に入れる場合は、他の会社と同じ質問をしてください。