Loading article…
金融情報交換（FIX）プロトコルは、証券取引および市場に関する情報を国際的にリアルタイムで交換するために1992年に開発された電子通信プロトコルです。NASDAQだけでも年間数兆ドルが取引されており、金融サービス企業は金融市場へのアクセス速度を向上させるためにダイレクト・マーケット・アクセス（DMA）を採用しています。取引アプリケーションの配信を管理し、レイテンシを低く抑えるには、FIXプロトコルの理解がますます重要になっています。
FIXプロトコル仕様は、もともと1992年にロバート・「ボブ」・ラムルーとクリス・モースタットによって、フィデリティ・インベストメンツとソロモン・ブラザーズの間で株式取引データを電子的に通信できるようにするために作成されました。FIXは当初、ブローカーディーラーとその機関投資家顧客間の情報を対象としていました。当時、この情報は電話で口頭で伝えられていました。フィデリティは、ブローカーディーラーからの情報が間違ったトレーダーにルーティングされたり、電話を切ったときに単に失われたりする可能性があることに気づきました。同社は、このような通信を、トレーダー間で共有、分析、実行、保存できる機械可読データに置き換えたいと考えました。たとえば、ブローカーディーラーは、株式のブロックを売買するための関心表明（IOI）を電話で伝えます。FIXイニシアチブは、IOIなどの新しいメッセージを作成しました。
FIXトレーディングコミュニティによると、FIXは世界の株式市場における取引前および取引中のコミュニケーションの事実上のメッセージング標準となっており、ストレートスルー処理をサポートするために取引後の領域に拡大しているほか、外国為替、債券、デリバティブ市場にも拡大を続けている。[ 1 ]
FIXトレーディングコミュニティは、非営利の業界主導の標準化団体であり、FIXプロトコルメッセージング言語を含む標準規格の利用拡大を通じて、世界の金融市場におけるマルチアセット取引に影響を与えるビジネスおよび規制上の問題に対処し、すべての市場参加者に対して運用効率の向上、透明性の向上、コストとリスクの削減を実現することをミッションとしています。[ 2 ]
FIXは、金融市場の買い手側（機関投資家）と売り手側（ブローカー／ディーラー）の両方で広く利用されています。利用者には、投資信託、投資銀行、ブローカー、証券取引所、ECNなどが含まれます。
FIXは、取引前通信および取引執行における標準的な電子プロトコルとなっています。主にフロントオフィスにおける株式取引に利用されていますが、債券デリバティブや外国為替取引にも利用可能です。SWIFTがバックオフィスにおけるメッセージングの標準規格であるのに対し、FIXはフロントオフィスにおけるメッセージングの標準規格と言えるでしょう。しかし現在、FIX Protocol Ltd.の加盟により、FIXはあらゆる市場、ほぼすべての資産クラスにおいて、ブロック取引の割り当てやその他の取引プロセスの段階へと拡張されています。
当初、FIX 標準は単一の技術仕様にアプリケーション層のセマンティクス、メッセージエンコーディング、セッション層を含めたモノリシックなものでした。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) で表されます。
FIXメッセージの実行レポート（35=8）の例。パイプ文字（|）はSOH文字を表します。
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 つのセクションに分かれています。フィールドは正しいセクション内に留まる必要があり、各セクション内では、フィールドが区切り文字として機能し、あるメッセージが次のメッセージに続いてしまうのを防ぐことができるため、位置が重要になる場合があります。FIX メッセージの最後のフィールドは、タグ 10 (チェックサム) です。
メッセージは大きく分けて、管理メッセージとアプリケーションメッセージの2種類に分類されます。管理メッセージはFIXセッションの基本処理を担います。セッションの開始と終了、および受信できなかったメッセージの復旧を可能にします。アプリケーションメッセージは、注文依頼や注文の現在の状態、その後の実行状況など、取引関連情報の送受信を扱います。
本体の長さは、タグ35（含む）からタグ10（含まない）までの文字数で、末尾のSOH区切り文字も含まれます。 以下の例（SOH区切り文字を「|」として表示）の本体の長さは65です。
8=FIX.4.2|9=65|35=A|49=SERVER|56=CLIENT|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トレーディングコミュニティは、SBEメッセージスキーマ用のXMLスキーマを公開しています。メッセージスキーマには、任意の数のメッセージテンプレートを含めることができます。テンプレートは、メッセージを構成するフィールドを記述します。さらに、スキーマは、任意の数のフィールドで再利用できる単純データ型と複合データ型のリストを提供します。
実用的な観点から、C/C++ 実装を想定し、エンディアンを調整すると、メッセージ内のほとんどの非複合型は、言語内の同じ型に直接マッピングされます。たとえば、32 ビット整数は にuint32_t、固定長文字列はにconst char *、浮動小数点数は にマッピングされますfloat。スキーマ定義から C/C++ を生成できますstruct。その後、メッセージ バッファへのポインタが与えられた場合、メッセージの非複合フィールドにアクセスするには、それを構造体へのポインタに型キャストし、構造体メンバーに直接アクセスする必要があります。
/* スキーマから生成された構造体 */ struct Message { ... uint32_t qty ; ... const char * symbol ; ... };void consume_message ( void * incoming_message ) { const struct Message * msg = ( const struct Message * ) incoming_message ; printf ( "Traded %u of %s \n " , msg -> qty , msg -> symbol ); ... }FIXトレーディングコミュニティは、FIXと他のメッセージプロトコル間の標準マッピングも開発しており、これには以下が含まれます。
セッション層は、チェックポイント回復メカニズムを含むメッセージ交換を担当します。
元の FIX セッション プロトコルは、アプリケーション レイヤーのセマンティクスとメッセージ エンコーディングも含むモノリシックな仕様の一部であったため、独自の名前を持っていませんでした。しかし、FIX バージョン 5.0 以降、セッション レイヤーは FIXT の導入により独立した仕様として分離されました。[ 9 ] FIXT は、バージョン 4.x の元の無名のセッション レイヤーとほぼ同じでしたが、重要な革新が 1 つありました。それは、共通のセッション バージョン上で FIX アプリケーション レイヤー バージョンを混在させるメカニズムを提供したことです。現在の FIXT バージョンは 1.1 です。
理論的には、FIXTはトランスポートに依存しない。しかし、通常は伝送制御プロトコル（TCP）上で用いられる。
FIXTはポイントツーポイントプロトコルです。双方向のメッセージ配信を保証します。各方向で送信されるメッセージには、メッセージヘッダーにメッセージシーケンス番号が含まれています。通信障害が発生した場合、ピアは受信できなかったメッセージの再送信を要求できます。セッションが切断され、その後再確立された場合でも、メッセージ配信はサポートされます。
セッション確立と確実な配信を実現するために、FIXTおよび従来のFIX 4.xでは、以下のセッションメッセージタイプが定義されています。
FIXP [ 10 ]は、高性能トレーディングのニーズを満たすためにFIX 高性能ワーキンググループ[ 11 ]によって開発されました。主なニーズは、低遅延のメッセージエンコードとデコード、およびメッセージ配信保証の制御です。
低遅延を実現するため、セッション層メッセージとアプリケーションメッセージの両方でバイナリメッセージエンコーディングがサポートされています。実際のワイヤフォーマットはFIXP仕様で抽象化されているため、ピア間でプロトコルが合意されていれば、ユーザーは任意のFIXエンコーディングを選択できます。初期開発では、シンプルバイナリエンコーディングが使用されていました。
FIXPは、共通の基本要素を用いて、ポイントツーポイントとマルチキャストの両方のユースケースに対応しています。
ポイントツーポイントセッションが確立されると、ピアは以下のいずれかから配信保証を交渉します。
デリバリー保証は非対称になる場合があります。例えば、トレーダーは冪等フローで注文を出し、執行結果は回復可能なフローで返されるといったケースです。変動の激しい市場では、再送信に伴う遅延はしばしば望ましくなく、機会損失や不利な取引につながる可能性があります。
以下は、購買側/顧客と販売側/サプライヤー間のメッセージングの外観を修正する方法の図です。[ 12 ]
FIXプロトコルの最新バージョンでは、アプリケーションメッセージの複数のバージョンを単一のトランスポート独立FIXセッション（FIXT.1.1以降）上で伝送できるようにすることで、「トランスポート独立性」を実現しています。
トランスポートの独立性により、従来のTCP上のFIXプロトコルの代わりに、メッセージキューやWebサービスなどのトランスポートプロトコルを使用できるようになります。
FIXは、 FIXアルゴリズム取引定義言語FIXatdlを使用することで、アルゴリズム取引をサポートするようになりました。
2005年、FIXトレーディングコミュニティはFASTプロトコル（ FIX Adapted for Streamingの略）をリリースしました。FASTはバイナリプロトコルであり、主にUDP接続を介してマルチキャスト市場データを送信するために使用されます。
さらに、2020年にFIXトレーディングコミュニティは、既存のFASTエンコーディングを補完することを目的とした、シンプルバイナリエンコーディング（SBE）に基づく新しいFIXバイナリエンコーディングをリリースしました。[ 13 ]