金融情報交換

金融情報交換( FIX ) プロトコルは、証券取引および市場に関連する国際的なリアルタイム情報交換のために 1992 年に開始された電子通信プロトコルです。NASDAQだけでも年間数兆ドルの取引が行われており、金融サービス企業は金融市場へのスピードを上げるためにダイレクト マーケット アクセス (DMA) を採用しています。取引アプリケーションの配信を管理し、待ち時間を低く抑えるには、FIX プロトコルの理解がますます必要になっています。

FIX プロトコル仕様は、もともと 1992 年に Robert "Bob" Lamoureux と Chris Morstatt によって作成され、Fidelity InvestmentsとSalomon Brothers間の株式取引データの電子通信を可能にしました。FIX は当初、ブローカー ディーラーとその機関投資家間の情報を対象としていました。当時、この情報は電話で口頭で伝達されていました。Fidelity は、ブローカー ディーラーからの情報が間違ったトレーダーにルーティングされたり、当事者が電話を切ったときに単に失われたりすることがあることに気付きました。Fidelity は、そのような通信を機械可読データに置き換え、トレーダー間で共有、分析、対応、および保存できるようにしたいと考えました。たとえば、ブローカー ディーラーは、株式のブロックを購入または売却するために、関心の表明 ( IOI ) を電話で伝えます。FIX イニシアチブにより、IOIなどの新しいメッセージが作成されました。

FIXトレーディングコミュニティによると、FIXは世界の株式市場における取引前および取引時の通信の事実上のメッセージング標準となっており、ストレートスループロセッシングをサポートするために取引後の領域に拡大しているほか、外国為替、債券、デリバティブ市場への拡大を続けています。^[1]

FIXトレーディングコミュニティは、非営利の業界主導の標準化団体であり、FIXプロトコルメッセージング言語を含む標準の使用を増やし、運用効率、透明性の向上、すべての市場参加者のコストとリスクの削減を実現することで、世界の金融市場におけるマルチアセット取引に影響を与えるビジネスおよび規制の問題に対処することを使命としています。^[2]

FIX は、金融市場の買い側(機関投資家) と売り側(ブローカー/ディーラー)の両方で広く使用されています。そのユーザーには、投資信託、投資銀行、ブローカー、証券取引所、ECN などがあります。

FIX は、取引前通信および取引実行の標準電子プロトコルになりました。主にフロント オフィス領域の株式取引に使用されますが、債券デリバティブや FX 取引も可能です。SWIFTがバック オフィスメッセージングの標準であるのに対し、FIX はフロント オフィス メッセージングの標準であると言えます。ただし、現在、FIX Protocol Ltd. のメンバーは、あらゆる市場、ほぼすべての資産クラスにおいて、ブロック取引の割り当てや取引プロセスの他の段階に FIX を拡張しています。

もともと、FIX 標準はモノリシックであり、アプリケーション層のセマンティクス、メッセージ エンコーディング、セッション層が 1 つの技術仕様に含まれていました。FIX バージョン 4.2 までモノリシックのままでした。^[3]その後、メッセージ エンコーディングとセッション層の仕様は別々のドキュメントに分割され始め、最終的に FIX は関連する技術標準のファミリーに進化しました。^[4]

オープンシステム相互接続モデル (OSI モデル) のプレゼンテーション層と呼ばれるメッセージエンコーディングは、メッセージのワイヤ形式を担当します。

オリジナルの FIX メッセージ エンコーディングは、タグ値エンコーディングと呼ばれます。各フィールドは、一意の数値タグと値で構成されます。タグはフィールドを意味的に識別します。したがって、メッセージは自己記述的です。タグ値エンコーディングは、ASCIIコードを使用した文字ベースです。

メッセージは、ヘッダー、本文、トレーラーで構成されます。メッセージ フィールドは、見出しの開始 (SOH)文字 ( ASCII 0x01) によって区切られます。

FIX.4.4までは、ヘッダーには8（BeginString）、9（BodyLength）、35（MsgType）の3つのフィールドが含まれていました。

FIXT.1.1 / FIX.5.0 以降、ヘッダーには 8 ( BeginString)、9 ( BodyLength)、35 ( MsgType)、49 ( SenderCompID)、56 ( TargetCompID)、およびオプションの 1128 ( ApplVerID) の 5 つまたは 6 つのフィールドが含まれます。

メッセージ本文の内容は、MsgTypeヘッダー内のメッセージタイプ（35）によって定義されます。

トレーラーには、メッセージの最後のフィールド 10 ( Checksum) が含まれており、常に 3 桁の数字 (例10=002) として表されます。

35=8パイプ文字 ( |) が SOH 文字を表す FIX メッセージ、実行レポート ( ) の例:

8=FIX.4.2 | 9=178 | 35=8 | 49=PHLX | 56=PERS | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 20=3 | 150=E | 39=E | 55=MSFT | 167=CS | 54=1 | 38=15 | 40=2 | 44=15 | 58=PHLX EQUITY TESTING | 59=0 | 47=C | 32=0 | 31=0 | 151=15 | 14=0 | 6=0 | 10=128 |

FIX メッセージは複数のフィールドから構成されます。各フィールドにはタグ値のペアがあり、次のフィールドとは区切り文字SOH (0x01) で区切られています。タグはフィールドの意味を示す整数です。値は特定のタグに固有の意味を持つバイト配列です (例: タグ 48 は SecurityID で、セキュリティを識別する文字列です。タグ 22 は IDSource で、使用されている識別子クラスを示す整数です)。値はプレーン テキストまたは純粋なバイナリとしてエンコードできます (この場合、値の前に長さフィールドが付きます)。FIX プロトコルはほとんどのタグの意味を定義しますが、同意した当事者間のプライベート使用のためにタグの範囲を予約しておきます。

FIX プロトコルは、特定のメッセージを構成するフィールドのセットも定義します。フィールドのセットには、必須のものもあればオプションのものもあります。メッセージ内のフィールドの順序は一般に重要ではありませんが、繰り返しグループの前にはカウントが、暗号化されたフィールドにはその長さが先行します。メッセージは、先頭、本文、末尾の 3 つのセクションに分かれています。フィールドは正しいセクション内に収まっている必要があり、各セクション内では、フィールドが区切り文字として機能して、1 つのメッセージが次のメッセージに続くのを防ぐことができるため、位置が重要になる場合があります。すべての FIX メッセージの最後のフィールドはタグ 10 (チェックサム) です。

メッセージには、管理とアプリケーションの 2 つの主要なグループがあります。管理メッセージは、FIX セッションの基本を処理します。これにより、セッションの開始と終了、および失われたメッセージの回復が可能になります。アプリケーション メッセージは、注文リクエストや、その注文の現在の状態とその後の実行に関する情報など、取引関連情報の送受信を処理します。

本文の長さは、末尾の SOH 区切り文字を含め、タグ 35 (含む) からタグ 10 (含まない) までの文字数です。
以下の例 (SOH 区切り文字が '|' として表示) の本文の長さは 65 です。

8=FIX.4.2|9=65|35=A|49=サーバー|56=クライアント|34=177|52=20090107-18:15:16|98=0|108=30|10=062|
              ^ 5 + 10 + 10 + 7 + 21 + 5 + 7 ^ = 65

FIXメッセージのチェックサムは、常にメッセージの最後のフィールドで、タグ10と3文字の値で構成されます。[ ^5]これは、メッセージ内のすべての文字のASCII値（チェックサムフィールド自体は除く）を合計し、 256を法として計算することで求められます。 ^[6]たとえば、上記のメッセージでは、すべてのASCII値（ASCII値1のSOH文字を含む）の合計は4158になります。モジュロ演算を実行すると、値62が得られます。チェックサムは3文字で構成されているため、結果は になります10=062。

FIXML ^[7] はFIXメッセージ用のXMLスキーマです。意味的にはタグ値でエンコードされたメッセージと同等ですが、XMLパーサー技術を活用しています。FIXMLは取引よりもバックオフィスや決済アプリケーションでよく使用されます。

シンプルバイナリエンコーディング^[8]は、コンピュータシステムに固有のプリミティブデータ型を使用してワイヤフォーマットを定義します。そのため、コンピュータが使用できる形式にデータを配置するための変換が不要なため、メッセージのエンコードとデコードは、文字ベースのプロトコルよりもレイテンシが大幅に低くなります。レイテンシの利点とは別に、SBEメッセージはテンプレートによって制約され、固定長のデータ要素が優先されるため、パフォーマンスはより決定論的です。もう1つの結果は、フィールドが一般に固定位置にあるため、メッセージフィルターとルーターがキーフィールドにアクセスするためにメッセージ全体を解読する必要がなくなることです。

SBE は、高性能取引をサポートするために FIX 高性能ワーキング グループによって開発されました。タグ値のエンコーディングは、バイナリではなく文字ベースであり、可変長のフィールドとメッセージによってパフォーマンスが非決定的になるため、目的に適さなくなったと判断されました。

tagvalue や FIXML とは異なり、SBE メッセージは自己記述的ではありません。メッセージを制御するテンプレートを識別するための最小限のヘッダーとともに、データのみがネットワーク上で送信されます。メッセージ レイアウトを記述するメタデータは、ピア間で 帯域外で交換されます。

FIX Trading Community は、SBE メッセージ スキーマ用の XML スキーマを公開しています。メッセージ スキーマには、任意の数のメッセージ テンプレートを含めることができます。テンプレートは、メッセージを構成するフィールドを記述します。さらに、スキーマは、任意の数のフィールドで再利用できる単純データ型と複合データ型のリストを提供します。

実用的な観点から、C/C++ 実装を想定し、エンディアンネスを調整すると、メッセージ内のほとんどの非複合型は、言語内の同じ型に直接マップされます。たとえば、32 ビット整数は にマップされuint32_t、固定文字列は にマップされconst char *、浮動小数点は にマップされますfloat。スキーマ定義から C/C++ を生成できますstruct。次に、メッセージ バッファーへのポインターが指定されている場合、メッセージの非複合フィールドにアクセスすることは、構造体へのポインターに型キャストし、構造体のメンバーに直接アクセスすることと同じです。

/* スキーマから生成された構造体 */ 
struct Message { ... uint32_t qty ; ... const char * symbol ; ... };  
  
   
  
    
  


void consumer_message ( void * incoming_message ) { const struct Message * msg = ( const struct Message * ) incoming_message ; printf ( "%s のうち %u が取引されました\n " , msg -> qty , msg -> symbol ); ... }   
          
    
  

FIX トレーディング コミュニティは、FIX と他のメッセージ プロトコル間の標準マッピングも開発しました。これには以下が含まれます。

• Google プロトコル バッファ
• 1.1 言語
• 翻訳

セッション層は、チェックポイント回復メカニズムを含むメッセージ交換を担当します。

オリジナルの FIX セッション プロトコルは、アプリケーション レイヤーのセマンティクスとメッセージ エンコーディングもカバーするモノリシック仕様の一部であったため、独自の名前がありませんでした。しかし、FIX バージョン 5.0 以降、セッション レイヤーは FIXT の導入により独立した仕様として分離されました。^[9] FIXT は、バージョン 4.x のオリジナルの無名のセッション レイヤーとほぼ同じでしたが、1 つの重要な革新を提供しました。共通のセッション バージョン上で FIX アプリケーション レイヤー バージョンを混在させるメカニズムを提供したのです。現在の FIXT バージョンは 1.1 です。

理論的には、FIXT はトランスポートに依存しません。ただし、通常はTransmission Control Protocol (TCP) 上で使用されます。

FIXT はポイントツーポイント プロトコルです。双方向のメッセージ配信を保証します。各方向に送信されるメッセージには、メッセージ ヘッダーにメッセージ シーケンス番号が含まれます。通信障害が発生した場合、ピアは失われたメッセージの再送信を要求することができます。セッションが切断され、その後再確立された場合でも、メッセージ配信はサポートされます。

セッションの確立と配信の保証を実装するために、FIXT と従来の FIX 4.x では次のセッション メッセージ タイプが定義されています。

• ハートビート
• テストリクエスト
• 再送リクエスト
• 拒否する
• シーケンスリセット
• ログアウト
• ログオン
• XML非FIX

FIXP ^[10]は、高性能取引のニーズを満たすために FIX高性能ワーキンググループ^{[11]によって開発されました。主なニーズは、低遅延のメッセージエンコードとデコード、およびメッセージ配信保証の制御です。}

低レイテンシを実現するために、セッション層とアプリケーション メッセージの両方でバイナリ メッセージ エンコーディングがサポートされています。実際のワイヤ フォーマットは FIXP 仕様で抽象化されているため、ピアが使用するプロトコルに同意する限り、ユーザーは任意の FIX エンコーディングを選択できます。初期の開発では、シンプル バイナリ エンコーディングが使用されていました。

FIXP は、共通のプリミティブを使用して、ポイントツーポイントとマルチキャストの両方のユースケースをカバーします。

ポイントツーポイント セッションが確立されると、ピアは次の選択肢の中から配信保証をネゴシエートします。

• 回復可能: 1 回だけのメッセージ配信。ギャップが検出された場合、失われたメッセージは再送信によって回復される可能性があります。
• べき等性: 最大 1 回の配信。ギャップが検出されると送信者に通知されますが、回復が行われるかどうかはアプリケーションの制御下にあります。
• シーケンスなし: 配信の保証はありません。保証が不要な場合、またはアプリケーション層または別の通信チャネルを通じて回復が提供される場合は、この選択が適切です。
• 注意: セッションの一方向にアプリケーション メッセージを送信しないでください。

配信保証は非対称になる場合があります。たとえば、トレーダーは、注文をべき等フローで入力する一方で、実行は回復可能なフローで返される場合があります。動きの速い市場では、再送信に伴う遅延は望ましくないことが多く、機会を逃したり、取引がうまくいかなかったりすることになります。

以下は、バイサイド/顧客とセルサイド/サプライヤー間のメッセージングの外観を修正する方法を示した図です。^[12]

FIX プロトコルの最新バージョンでは、複数のバージョンのアプリケーション メッセージを単一バージョンのトランスポート独立 FIX セッション (FIXT.1.1 以降) で伝送できるようにすることで、「トランスポート独立性」を実装しています。

トランスポート独立性により、従来の FIX over TCP の代わりに、メッセージ キューやWeb サービスなどのトランスポート プロトコルを使用すること も可能になります。

FIX は、 FIX アルゴリズム取引定義言語FIXatdlの使用により、アルゴリズム取引をサポートするようになりました。

2005 年、FIX トレーディング コミュニティはFIX Adapted for Streaming の略であるFAST プロトコルをリリースしました。FASTはバイナリ プロトコルであり、主に UDP 接続を介してマルチキャスト 市場データを送信するために使用されます。

さらに、2020年にFIXトレーディングコミュニティは、既存のFASTエンコーディングを補完することを目的とした、シンプルバイナリエンコーディング（SBE）に基づく新しいFIXバイナリエンコーディングをリリースしました。^[13]

• 修正
• SWIFT:メッセージの種類
• 電子取引プロトコルのリスト

• FIXプロトコル株式会社 - この公式FIXトレーディングコミュニティウェブサイトにはFIX標準が含まれています
• FIXimate FIX辞書 FIX旧バージョン FIX最新
• FIXwiki - FIX専用のWiki。FIXimateのような仕様参照ツールですが、Wikiなのでユーザーのメモやフィードバックも可能です。
• B2BITS FIX Antenna .NET Core - オープン ソースの .NET FIX エンジン実装。
• Esprow FIX Tools - FIXメッセージパーサーを含むすべてのFIXバージョン用のオンラインFIX辞書ブラウザ
• Onixs の完全な FIX プロトコル辞書 - FIX プロトコル (バージョン 4.0、4.1、4.2、4.3、4.4、5.0、5.0.SP1、5.0.SP2、FIXT1.1) の最新の辞書をすばやく簡単に使用できます。
• FixSpec FIX 4.0 2015-11-07 にWayback Machineにアーカイブされました FIX 4.1 2015-11-07 にWayback Machineにアーカイブされました FIX 4.2 2015-11-07 にWayback Machineにアーカイブされました FIX 4.3 2015-11-07に Wayback Machineにアーカイブされました FIX 4.4 2015-11-07 にWayback Machineにアーカイブされました FIX 5.0 2015-11-07に Wayback Machineにアーカイブされました FIX 5.0 SP1 2019-07-01 にWayback MachineにアーカイブされましたFIX 5.0 SP2 2016-03-04 にWayback Machineにアーカイブされました FIXT 2019-07-01 にWayback Machineにアーカイブされました
• FIXSIM - FIX メッセージ パーサー、サンプル メッセージ、テスト サポート。
• Rapid Addition の使用上の注意を含むオンライン リソース - 使用上の詳細な注意を含むオンライン FIX リソース (バージョン 4.0、4.2、5.0 SP2)。
• FIXGlobal - 無料のグローバル取引ジャーナルおよび FIX プロトコルの公式マガジン。
• FIX プロトコルとは何ですか? - FIX プロトコルの非技術的な概要。
• sed を使用してシェル スクリプトで記述されたシンプルな FIX デコーダー。Unix/Linux 上でネイティブに高速に実行され、最新の FIX バージョンに更新する必要があります。
• Fix Parser - オンライン FIX メッセージ パーサー