mcpField
E
exchange-connectivity

exchange-connectivity

github.com/joellewis開発218679 回インストール15 週間前に更新
リポジトリ

exchange-connectivity について

取引インフラを構築するチーム向けに、取引所接続、FIXセッション管理、市場データフィードを解説するスキルです。ダイレクトアクセスや独自プロトコル、冗長化とフェイルオーバーも扱います。

主な機能

  1. 01ダイレクトアクセスとスポンサードアクセス
  2. 02FIXセッションメッセージとシーケンス管理
  3. 03取引所独自プロトコルの概要
  4. 04市場データの深度レベル
  5. 05接続の冗長化とフェイルオーバー

活用シーン

  1. 01取引所接続アーキテクチャの計画
  2. 02FIXセッションのシーケンス欠落の調査
  3. 03市場データの深度レベルの選択
  4. 04バックアップ接続と復旧手順の設計

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/joellewis/finance_skills --skill exchange-connectivity

インストール後、Claude Code で/exchange-connectivityを入力して読み込まれたか確認します。

同梱ファイルreferences/examples.md

詳細

取引所接続

基本概念

取引所接続アーキテクチャ

取引所は、ブローカー・ディーラー、マーケットメーカー、機関投資家が注文を送信し、約定レポートを受信するための電子インターフェースを提供しています。企業と執行取引所の間の接続アーキテクチャは、取引インフラの基盤となる要素です。

ダイレクト・マーケット・アクセス(DMA): DMA を利用すると、企業は他のブローカーの注文管理システムを介さずに、取引所のマッチングエンジンへ直接注文を送信できます。企業は取引所との独自の FIX セッション(または独自プロトコルの接続)を維持し、取引前のリスク管理を担います。DMA は、取引所の会員資格を持つブローカー・ディーラーや自己勘定取引会社が利用します。

スポンサー付きアクセス: スポンサー付きアクセスでは、非会員企業がスポンサーとなるブローカー・ディーラーの市場参加者識別子(MPID)を通じて、取引所へ注文をルーティングします。スポンサーとなるブローカーは、SEC 規則 15c3-5(マーケットアクセス規則)に基づき、取引前のリスク管理を担います。スポンサー付きアクセスには、「フィルター付き」(注文が取引所に到達する前に、スポンサーのリスクチェックを通過する)と「フィルターなし」(注文がスポンサーのシステムを迂回して取引所へ直接送られ、スポンサーは取引所レベルのリスク管理に依存する)があります。SEC は規則 15c3-5 により、フィルターなしのスポンサー付きアクセスを事実上禁止しました。この規則では、市場アクセスを提供するブローカー・ディーラーに対し、誤った注文の入力を防止するよう合理的に設計されたリスク管理統制と監督手順の実施が求められています。

FIX プロトコル接続: Financial Information eXchange(FIX)プロトコルは、株式、オプション、債券、外国為替市場における注文ルーティングと約定報告の主要な標準です。FIX はタグと値で構成されるメッセージ形式です(例:新規注文単一の場合はタグ 35=D、約定レポートの場合はタグ 35=8)。米国の株式取引所の大半は注文入力に FIX を受け入れており、FIX はブローカー間およびブローカーとバイサイド間の接続における標準インターフェースです。一般的に使用される FIX バージョンには、FIX 4.2(広くサポートされ、多くの取引所で現在も使用)、FIX 4.4(複数レッグ商品や配分指示へのサポートを追加)、FIX 5.0/FIXT 1.1(トランスポート層とアプリケーション層を分離)があります。

独自の取引所プロトコル: いくつかの取引所は、よりコンパクトなメッセージエンコードと解析オーバーヘッドの削減により、FIX より低レイテンシーを実現する独自のバイナリプロトコルを提供しています。

  • OUCH — Nasdaq の注文入力プロトコルです。バイナリ形式で、注文の送信、取消、訂正に対応しています。Nasdaq およびその関連取引所で、高頻度取引や低レイテンシーを重視する参加者によく使用されています。
  • ITCH — Nasdaq のマーケットデータ配信プロトコルです。Nasdaq の注文板について、すべての注文の追加、変更、取消、約定イベントを含む、注文単位の完全な(レベル 3)情報を提供します。ITCH は Nasdaq の TotalView データ製品の基盤です。
  • PITCH — BZX、BYX、EDGX、EDGA 取引所向けの Cboe のマーケットデータプロトコルです。ITCH と同様に、PITCH は注文単位の板情報を提供します。
  • Pillar — NYSE の統合取引テクノロジープラットフォームで、NYSE、NYSE Arca、NYSE American、NYSE National 全体の注文入力とマーケットデータに対応しています。Pillar はゲートウェイ接続にバイナリプロトコルを使用します。
  • BOE(Binary Order Entry) — Cboe 独自の注文入力プロトコルで、Cboe の株式取引所において FIX より低レイテンシーの注文送信を提供します。 コロケーションと近接ホスティング: 取引所は、企業が取引サーバーを取引所のマッチングエンジンと同じデータセンターに設置できるコロケーションサービスを提供しています。コロケーションでは、企業のサーバーと取引所の物理的な距離を縮めることで、ネットワーク遅延(マイクロ秒単位で測定)を最小限に抑えます。近接ホスティングとは、取引所の施設内ではなく、その近くのデータセンターにサーバーを設置することです。コロケーションより遅延はやや大きくなりますが、多くの場合、コストを抑えられます。米国の主要な取引所データセンターには、ニュージャージー州マーワーにあるNYSEのデータセンターと、ニュージャージー州カーテレットにあるNasdaqのデータセンターがあります。

接続プロバイダーとエクストラネット: 金融エクストラネットは、単一の物理接続を通じて、複数の取引所や取引所施設に市場参加者を接続するプライベートネットワークです。主なエクストラネットは次のとおりです。

  • TNS(Transaction Network Services) — 世界各地の取引所や取引所施設へのマネージド接続を提供しています。
  • IPC(現在はAtosの一部) — 取引会社を取引所、市場データプロバイダー、サービスビューローに接続する金融エクストラネット、Connexus Cloudを運営しています。
  • BSO(Boldon Smart Operations) — 金融市場向けに低遅延のネットワークインフラを提供しています。
  • Options Technology — 取引会社向けに接続サービスとマネージドインフラを提供しています。 エクストラネットを利用すると、各取引所施設への個別のポイントツーポイント接続を維持する運用負担を軽減できますが、共有ネットワークへの依存が生じます。

冗長化とフェイルオーバー: 本番環境の取引所接続には、冗長経路が必要です。標準的な方法には、各取引所施設へのプライマリおよびバックアップのFIXセッション(通常は別々の物理ネットワーク経路を使用)、異なるエクストラネットまたは通信事業者を経由するプライマリおよびセカンダリのネットワーク接続、コロケーション施設内のクロスコネクトの冗長化、そして取引を再開できる災害復旧サイトを企業が維持する地理的冗長化が含まれます。

FIXセッション管理

FIXプロトコルでは、接続の確立、メッセージの順序管理、ハートビート、復旧を処理するセッション層が定義されています。信頼性の高い注文フローには、適切なセッション管理が不可欠です。 セッションレベルのメッセージ:

  • Logon(MsgType=A): FIX セッションを開始します。SenderCompID、TargetCompID、および合意したハートビート間隔が含まれます。取引所またはカウンターパーティは、セッションを確認するために独自の Logon メッセージを返します。会場によっては、Logon メッセージに暗号化または認証トークンが必要です。
  • Logout(MsgType=5): FIX セッションを正常に終了します。どちら側からでも開始できます。適切に動作する実装では、Logout を送信し、TCP 接続を閉じる前にカウンターパーティからの Logout 応答を待ちます。
  • Heartbeat(MsgType=0): 他のメッセージが交換されていない場合、合意した間隔(通常は 30 秒)で送信されます。セッションが稼働していることを確認します。想定される間隔(許容時間を含む)内に Heartbeat を受信できない場合、カウンターパーティは TestRequest を送信する必要があります。
  • TestRequest(MsgType=1): Heartbeat の期限が過ぎた場合に送信されます。受信側は、TestRequest の TestReqID を含む Heartbeat で応答する必要があります。応答がない場合、接続が切断されていることを示します。
  • ResendRequest(MsgType=2): シーケンス番号の範囲内にあるメッセージの再送を要求します。シーケンス番号の欠落が検出された場合に使用します。たとえば、受信側がシーケンス番号 100 を想定しているのに 105 を受信した場合、メッセージ 100~104 が欠落したことを示します。
  • SequenceReset(MsgType=4): 2 つのモードで使用されます。ギャップフィルモード(GapFillFlag=Y)では、再送の必要がない管理メッセージを飛ばして、想定されるシーケンス番号を進めます。リセットモード(GapFillFlag=N)では、シーケンス番号を新しい値に強制的に設定します。通常、セッションの初期化時またはエラーからの復旧時にのみ使用します。リセットモードを不適切に使用すると、メッセージが失われる可能性があるため危険です。
  • Reject(MsgType=3): メッセージがセッションレベルの検証に失敗した場合(不正なタグ、無効なデータ型、必須フィールドの欠落)に送信されます。Reject はビジネスレベルで拒否されたことを示すものではなく、メッセージを解析できなかったことを意味します。

セッション設定:

  • SenderCompID / TargetCompID: FIX セッションの両側を識別する一意の識別子です。取引所から割り当てられるか、カウンターパーティ間で合意します。通常、企業は維持する FIX セッションごとに異なる SenderCompID を使用します。
  • ハートビート間隔: Logon の際に合意します。一般的な値は、注文セッションでは 30 秒、市場データセッションでは 10~30 秒です。
  • ResetOnLogon: Logon ごとにシーケンス番号を 1 にリセットする実装もあります。シーケンス番号をセッション間で保持し、ギャップの復旧に ResendRequest/SequenceReset を使用する実装もあります。どちらの方法が必要かは、取引所固有のドキュメントに従います。
  • メッセージエンコーディング: 標準の FIX では、SOH(0x01)区切り文字で区切られた ASCII のタグ=値のペアを使用します。市場データ向けに FAST(FIX Adapted for Streaming)エンコーディングをサポートする会場もあります。この方式では、バイナリ圧縮を使用して帯域幅を削減します。

シーケンス番号の管理: FIX セッションの各側では、2 つのシーケンス番号カウンターを管理します。送信シーケンス番号(メッセージを送信するたびに増加)と、受信時に想定されるシーケンス番号(メッセージを受信するたびに増加)です。受信メッセージのシーケンス番号が想定値を超えている場合、ギャップが検出されており、ResendRequest を発行する必要があります。受信シーケンス番号が想定値より小さい場合(かつ、メッセージに PossDup のフラグが設定されていない場合)、セッションは復旧不可能な状態にあるため、切断する必要があります。通常、シーケンス番号はディスクに保存されるため、リセットせずにセッションを再起動後に復旧できます。 ギャップ検出とリカバリー: シーケンス番号のギャップを検出すると、受信側は欠落したシーケンス番号の範囲を指定する ResendRequest(BeginSeqNo から EndSeqNo まで。EndSeqNo=0 は「無限」または「最新まで」を意味します)を送信します。送信側は、重複している可能性があることを示す PossDupFlag=Y を付けて、欠落したメッセージを再送します。受信側は PossDup メッセージを冪等に処理する必要があります。たとえば、約定レポートを PossDup として受信した場合、元のメッセージがすでに処理済みなら、OMS で二度目の約定を発生させてはいけません。

セッションのスケジュール: 取引所の FIX セッションは、市場の取引時間に合わせて定められたスケジュールで運用されます。

  • プレマーケットセッション: 多くの取引所では、7:00 または 8:00 ET から注文を受け付けます(時間外取引では、早いところで 4:00 ET から受け付ける取引所もあります)。注文の入力開始前に、ログオン、シーケンス番号の同期、寄り付き前のメッセージ送信を行えるよう、FIX セッションを確立しておく必要がある場合があります。
  • 取引時間: 米国株式市場では 9:30~16:00 ET です。FIX セッションは、寄り付きオークションの前に完全に稼働している必要があります。
  • ポストマーケットセッション: 取引所によっては、17:00 または 20:00 ET まで注文を入力できます。時間外取引には別のセッションパラメーターが必要な取引所もあります。
  • 一日の終わり: 取引日の終わりにセッションをログアウトし、シーケンス番号をリセット(または永続化)する場合があります。一日の終わりの具体的な手順は、取引所によって異なります。
マーケットデータフィード

マーケットデータフィードは、取引所から市場参加者へ、価格、出来高、板情報を配信します。マーケットデータインフラのアーキテクチャは、証券の価格評価、取引判断、最良執行義務の遵守に関する企業の能力に直接影響します。

データの深度階層: レベル1(最良気配 — NBBO と直近約定価格)は、ほとんどのポートフォリオおよびコンプライアンスのワークフローに十分です。レベル2(取引所ごとの板の深度)は、市場インパクトの推定や板の不均衡を利用する戦略を支えます。レベル3(Nasdaq ITCH や Cboe PITCH などの注文単位のフィード)は、マーケットメーカーやレイテンシに敏感な戦略向けに、板全体の再構築を可能にします。アーキテクチャ上の判断では、各データ利用アプリケーションが実際に必要とする階層を見極めます。フィードのコスト、帯域幅、フィードハンドラーの複雑さは、深度に応じて急激に増大します。

統合フィード(SIP): Securities Information Processor(SIP)は、米国の全株式取引所における気配と取引を統合した情報を生成する規制上の仕組みです。次の2つのSIPプランが運用されています。

  • CTA/CQS(Consolidated Tape Association/Consolidated Quotation System): NYSE、NYSE Arca、NYSE American、およびその他の取引所に上場する証券の取引と気配を統合します。CTAは統合テープ(直近約定データ)を生成し、CQSは統合気配(NBBO)を生成します。
  • UTP(Unlisted Trading Privileges Plan): Nasdaq上場証券の取引と気配を、すべての取引所にわたって統合します。 SIPフィードは「公式」なNBBOを示し、Regulation NMSの取引価格保護における参照情報として使用されます。統合処理が必要なため、SIPデータは従来、取引所のダイレクトフィードより遅く、レイテンシの差は規制上の議論の対象となってきました。

ダイレクトフィード(取引所独自): 各取引所は、自らのマーケットデータを加入者に直接配信します。ダイレクトフィードが提供するデータは特定の取引所での取引に限られますが、統合処理を経ないため、統合SIPより速く届きます。最小のレイテンシを必要とする企業(マーケットメーカー、統計的裁定取引、レイテンシに敏感なアルゴリズムなど)は通常、各取引所のダイレクトフィードを購読し、個々の取引所フィードから社内独自のNBBOを構築します。これは「合成NBBO」または「ダイレクトNBBO」と呼ばれることもあります。

マーケットデータの正規化: 複数のソース(SIP、複数のダイレクトフィード、ベンダーフィード)からデータを受け取る企業は、データを統一された社内フォーマットに正規化する必要があります。正規化には、取引所固有のシンボル体系を企業の社内証券マスターに対応付けること、取引所固有のメッセージ形式を共通スキーマに変換すること、取引所のタイムスタンプに基づいて異なるソースのメッセージを順序付けること、異なる価格形式(小数、債券の分数表記)に対応すること、統合フィードとダイレクトフィードの両方に現れるイベントを重複排除することが含まれます。

データベンダーとの統合: 大手データベンダーは、集約・拡充したマーケットデータを提供します。

  • Bloomberg — Bloomberg Terminal と Bloomberg B-PIPE は、リアルタイムおよび過去のマーケットデータ、参照データ、分析機能を提供します。Bloombergは独自のシンボル体系(Bloombergティッカー、FIGI)とデータ配信API(BLPAPI)を使用します。
  • Refinitiv(LSEG) — Refinitiv Elektronはリアルタイムのマーケットデータを提供し、Refinitiv Eikonターミナルは分析機能を提供します。RefinitivはRIC(Reuters Instrument Code)のシンボル体系を使用します。
  • ICE Data Services — 複数の資産クラスにわたって、リアルタイムデータ、参照データ、評価価格を提供します。 ベンダーフィードは、数百の取引所のデータに単一のインターフェースで接続できるため、接続を簡素化します。一方で、ベンダー固有のレイテンシやシンボル体系のレイヤー、契約上の義務(取引所データの再配布契約、ユーザーごとのライセンス)が生じます。
取引停止とサーキットブレーカー

取引停止とサーキットブレーカーは、極端なボラティリティが発生した際や重要情報の発表が控えている際に、市場の健全性を守るために取引を停止する仕組みです。取引所の注文フローと連携するシステムは、取引停止を正しく検知し、遵守して対応する必要があります。

市場全体のサーキットブレーカー(MWCB): 市場全体のサーキットブレーカーは、S&P 500 指数の下落幅に基づき、米国の全株式取引所で取引を停止します。しきい値は、前日の S&P 500 の終値を基準に毎日算出されます。

  • レベル 1(7%の下落): 東部時間午後 3 時 25 分より前に発動した場合、取引は 15 分間停止します。午後 3 時 25 分以降に発動した場合、取引は継続します。
  • レベル 2(13%の下落): 東部時間午後 3 時 25 分より前に発動した場合、取引は 15 分間停止します。午後 3 時 25 分以降に発動した場合、取引は継続します。
  • レベル 3(20%の下落): 発動時刻にかかわらず、その日の残りの取引時間中、取引を停止します。 各レベルは 1 日に 1 回のみ発動できます。取引再開後も市場が下落し続けた場合、レベル 1 の停止によって、その後のレベル 2 またはレベル 3 の停止が妨げられることはありません。

リミット・アップ/リミット・ダウン(LULD): LULD は、個別の NMS 証券について、指定された価格帯の範囲外での取引を防ぎます。仕組みは次のとおりです。

  • 基準価格: 直前 5 分間に報告された取引価格の算術平均で、通常取引時間中は 30 秒ごとに更新されます。
  • 価格帯: 基準価格の上下に一定の割合を適用して算出します。この割合は証券の区分によって異なり、ティア 1 証券(S&P 500、Russell 1000、および一部の ETP)は 5%、ティア 2 証券(その他すべての NMS 証券)は 10%です。取引日の最初の 15 分間と最後の 25 分間は、より広い価格帯(20%)が適用されます。
  • リミット状態: NBBO が上限または下限の価格帯に達した場合(つまり、最良売気配が下限価格帯と等しい場合、または最良買気配が上限価格帯と等しい場合)、その証券は「リミット状態」に入ります。取引は継続しますが、価格帯の範囲外で約定する注文は認められません。
  • 取引一時停止: リミット状態が 15 秒間続くと、主上場取引所は 5 分間の取引一時停止を宣言します。一時停止後、再開オークションを通じて取引が再開されます。 システムは LULD の価格帯をリアルタイムで監視し、価格帯に違反する注文の送信を防ぐ必要があります。

規制当局による取引停止:

  • ニュース発表待ち(T1 停止): 重要なニュースが予想される場合(例:業績の事前発表、合併の発表、その他市場を動かす開示)、主上場取引所は取引を停止することがあります。ニュースが配信され、取引所が市場に情報を消化する十分な時間が経過したと判断した後、取引が再開されます。
  • ニュース配信(T2 停止): 重要なニュースの発表後に発令され、市場が情報を処理するための追加時間を確保します。
  • SEC による取引停止(Section 12(k)): 投資家と公共の利益を守るために停止が必要と判断した場合、SEC はあらゆる証券の取引を最長 10 営業日間停止できます。SEC による停止は通常、公開情報の正確性、インサイダー取引、または市場操作に関する懸念を理由に発動されます。
  • IPO/直接上場の取引停止: 新規上場証券を対象とする寄り付き前の取引停止で、寄り付きオークションによって公正な価格が決まるまで継続します。

取引所固有の取引停止: 個別の取引所は、独自の取引停止の仕組み(例:ボラティリティによる中断、マッチングエンジンの問題)を導入することがあります。これらは、取引所固有のマーケットデータメッセージや管理通知を通じて伝達されます。 取引停止となった証券のシステム対応: 取引停止を検知した場合、システムは次の対応を行う必要があります:(1)停止となった証券について、影響を受ける取引所への新規注文の送信を直ちに停止する、(2)未約定注文の扱いを判断する。一部の取引停止の種類では取引所がすべての板上注文を取り消しますが、別の種類では注文が板に残ります、(3)トレーダーとポートフォリオマネージャーに通知する、(4)新しい注文リクエストを取引再開時の送信に備えてキューに入れるか、拒否するかを決定する、(5)取引再開の通知と再開時のオークションを監視する、(6)規制当局への報告に備えて取引停止イベントを記録する(CAT報告には、取引停止に関連する注文イベントが含まれます)。

シンボル体系と証券の識別

取引システムは、取引所、データソース、社内システムをまたいで証券を正しく識別する必要があります。複数の識別方式があり、通常、1つの証券でも状況に応じて異なる識別子が使われます。

識別子の概要: ティッカーシンボルは取引所が割り当てるもので、コーポレートアクションに伴い変更され、世界共通ではありません。CUSIPは(米国/カナダで使われる)プロプライエタリな識別子で、CUSIP Global Servicesからライセンスを取得する必要があります。ISINは米国証券のCUSIPを包摂したもので、クロスボーダー決済や規制当局への報告に必要です。SEDOLは英国およびアイルランド上場銘柄を対象とします。FIGIはBloombergのオープンライセンス識別子で、コンポジット(グローバル)とシェアクラス(取引所レベル)の粒度があります。運用上の課題は、識別子の形式そのものではなく、ライセンス、変更管理、マッピングです。

シンボル体系のマッピング: 識別子の種類を相互に変換するには、証券マスターまたはシンボル体系のマッピングサービスが必要です。たとえば、Apple Inc.の普通株式には、ティッカーAAPL(Nasdaq)、CUSIP 037833100、ISIN US0378331005、FIGI BBG000B9XRY4があります。注文を取引所にルーティングする際、システムは取引所が想定するシンボル体系を使用する必要があります。ベンダーから市場データを受信する際は、ベンダーの識別子を自社の内部識別子にマッピングする必要があります。シンボル体系のマッピングでは、次のケースに対応する必要があります。1対多の関係(1つの企業が複数の上場証券を持つ場合があります。普通株式、優先株式、新株予約権、権利など)、経時的な変更(ティッカーの変更、コーポレートアクションによるCUSIPの変更)、取引所固有の接尾辞や拡張子。

コーポレートアクションによるシンボル体系への影響: コーポレートアクションによって識別子が変更されることは少なくありません。ティッカーの変更(ブランド変更)により、取引シンボルが置き換わります。証券の基本的な条件が変更されると、CUSIPも変更されます(新株を伴う株式分割、合併による新しい企業の設立、株式クラスの転換など)。シンボル体系を最新の状態に保つには、システムが参照データの更新情報を取り込む必要があります。こうした情報は通常、取引所やデータベンダーから夜間に配信され、ときには日中にも配信されます。

特殊なシンボル: 特定の接尾辞や識別子は、特殊な取引条件を示します。「WI」(when-issued。証券が正式に発行される前の取引)、「RT」(権利)、「WS」(新株予約権)、「U」(ユニット)、および異なる株式クラスを示す取引所固有の接尾辞(デュアルクラス構造における「A」と「B」など)です。

市場時間と取引セッション

米国の株式市場は、明確に定められたスケジュールに従って運営され、取引セッションも区分されています。取引システムでは、注文種別、価格設定、ルーティングに関するセッション固有のルールを適用する必要があります。

プレマーケットセッション(東部時間 午前4:00~午前9:30): 一部の取引所やECNでは、東部時間の午前4:00から注文を受け付けています。プレマーケット取引では、通常、流動性が低く、スプレッドが広がり、一部の注文種別が制限される場合があります(例:指値注文のみ可能で、成行注文は不可)。すべての証券がプレマーケット取引に対応しているわけではありません。

通常取引セッション(東部時間 午前9:30~午後4:00): 主要な取引セッションであり、この時間帯にはすべてのNMS保護規則が適用されます(Reg NMSの取引通過ルール、LULDバンド、市場全体のサーキットブレーカー)。セッションは寄り付きオークションで始まり、大引けオークションで終了します。

ポストマーケットセッション(東部時間 午後4:00~午後8:00): 通常取引セッション終了後の時間外取引です。プレマーケットと同様の制限があり、流動性が低く、多くの取引市場では指値注文のみが可能で、スプレッドも広がります。

寄り付きオークション(オープニング・クロス): 取引所は寄り付き価格を決定するために寄り付きオークションを実施します。プレオープン時間帯には注文が蓄積され、取引所は想定約定価格と数量を公表します。東部時間の午前9:30に、約定可能数量が最大となる単一の清算価格で、蓄積された注文を照合します。Nasdaqでは「オープニング・クロス」と呼ばれ、NYSEでは指定マーケットメーカー(DMM)制度を通じて寄り付きを支援します。

大引けオークション(クロージング・クロス): 大引けオークションでは、公式終値を決定します。終値は、NAVの計算、指数のリバランス、ベンチマーク設定に使用されます。Nasdaqでは、クロージング・クロスで成行引け(MOC)注文と指値引け(LOC)注文を受け付けます。NYSEでは、DMMが大引けを支援します。大引けオークションの出来高は大幅に増加しており、多くの日で、1日の総出来高の5~10%以上が大引けオークションで約定します。

半日取引セッション: 米国市場は、独立記念日の前日(7月3日。7月3日が週末の場合は7月2日)、感謝祭の翌日(ブラックフライデー)、クリスマスイブ(12月24日。12月24日が週末の場合は12月23日)に、東部時間の午後1:00に早じまいします。システムには、セッション時間と早じまいへの対応を調整する祝日カレンダーが必要です。

祝日カレンダーの管理: 取引システムでは、市場の祝日(元日、マーティン・ルーサー・キング・ジュニア・デー、プレジデンツ・デー、聖金曜日、メモリアルデー、ジューンティーンス、独立記念日、レイバーデー、感謝祭、クリスマス)と半日取引セッションのカレンダーを維持する必要があります。取引所がスケジュールを公表するたびに、カレンダーを毎年更新する必要があります。祝日カレンダーに誤りがあると、休場中の市場に注文が送信されて拒否されたり、市場が開いているのに注文が送信されなかったりする可能性があります。

接続のレジリエンス

取引所への接続は、高可用性を実現できるよう設計する必要があります。接続障害は、注文の送信を妨げ、約定の見逃しを招き、コンプライアンス上および財務上のリスクを生じさせる可能性があります。

プライマリ接続/バックアップ接続: 本番環境のすべての FIX セッションまたはデータフィードにバックアップを用意する必要があります。共通要因による障害を避けるため、プライマリ接続とバックアップ接続では、異なる物理ネットワーク経路(異なるスイッチ、異なるエクストラネット、異なる ISP)を使用してください。単一プロバイダーの停止ですべての取引所接続が停止しないよう、一方のエクストラネット(例:TNS)をプライマリ接続に、別のエクストラネット(例:IPC)をバックアップに使用する企業もあります。

フェイルオーバーのテスト: プライマリ接続からバックアップ接続へのフェイルオーバーは、定期的にテストする必要があります。年次の DR(災害復旧)訓練だけでなく、本番取引中に定期的かつ計画的なフェイルオーバーを実施してください。テストされていないフェイルオーバー手順は、実際の障害時に必要となっても機能しないことがよくあります。

ハートビートの監視: FIX セッションレベルでは、ハートビートによって接続の切断を検知します。インフラストラクチャレベルでは、通常、企業は追加の監視を実施します。具体的には、ネットワークレベルのヘルスチェック(ping、TCP 接続)、アプリケーションレベルのヘルスチェック(定期的なテストメッセージ、またはデータフィードのスループットのタイミングチェック)、および性能の低下を通知するレイテンシ監視(例:往復時間がしきい値を超えた場合)です。接続の性能が低下または停止した際に、監視システムから技術担当者とトレーディングデスクの両方にアラートが届くようにしてください。

セッション復旧手順: FIX セッションが予期せず切断された場合、復旧手順は次のとおりです:(1)切断を検知する(ハートビートのタイムアウトまたは TCP リセット)、(2)取引所ゲートウェイへの過剰な負荷を避けるため、指数バックオフを使用して再接続を試みる、(3)永続化されたシーケンス番号を使用してセッションを再確立する、(4)ResendRequest/SequenceReset によるギャップリカバリーを実施して状態を同期する、(5)未完了注文の状態を照合する。切断前に送信された注文は、障害中に約定、一部約定、またはキャンセルされている可能性があるため、再接続時に企業は各注文の現在の状態を確認する必要があります。

災害復旧とクロスリージョン接続: プライマリサイトに障害が発生した場合に、セカンダリサイトから取引を再開できる体制を維持する必要があります。通常、DR サイトは独自の取引所接続(FIX セッション、市場データフィード、ネットワークインフラストラクチャ)を備えており、スタンバイまたはウォームスタンバイの状態に保たれます。重要な設計上の判断には、RTO(目標復旧時間)— プライマリサイトの障害後、どれだけ早く取引を再開する必要があるか、RPO(目標復旧時点)— どれだけの注文/ポジションの状態が失われてもよいか、そして DR サイトで同じ SenderCompID を使用するか、異なる SenderCompID を使用するかが含まれます(同じ CompID ならシームレスに継続できますが、異なる CompID では取引所との調整が必要です)。

パフォーマンスの監視: 接続パフォーマンスの継続的な監視には、ネットワークレイテンシ(アプリケーション層で測定する片道および往復の遅延)、メッセージスループット(ピーク時の毎秒メッセージ数)、パケット損失率、注文確認のレイテンシ(注文送信から取引所による確認までの時間)、および市場データの適時性(取引所のタイムスタンプと企業での受信タイムスタンプとの差)が含まれます。レイテンシの急増やスループットの低下は、ネットワークの輻輳、ハードウェアの問題、または取引所ゲートウェイの問題を示している可能性があります。

規制要件

取引所や取引施設に接続する企業には、システム、管理体制、報告を規定する特定の規制要件が適用されます。

Regulation SCI(システムのコンプライアンスと完全性): SEC Regulation SCI(2014年採択、2015年11月施行)は、「SCI 対象事業者」—取引所、取引量の基準(NMS 取引量のおよそ5%)を満たす一部の ATS、清算機関、SIP プロセッサー、および一部の免除対象清算機関—に適用されます。SCI 対象事業者は、システムに十分な容量、完全性、耐障害性、可用性、セキュリティを確保するために合理的に設計されたポリシーと手順を定めること、これらのシステムの定期的なレビューとテスト(事業継続テストを含む)を実施すること、「SCI イベント」(システム障害、システム侵入、重大なシステムコンプライアンス上の問題)を速やかに SEC に通知すること、年次 SCI レビューを SEC に提出することが求められます。Reg SCI は取引所や大規模 ATS に直接適用されます(それらに接続するブローカー・ディーラーには適用されません)が、取引所のシステム障害は接続に影響するため、ブローカー・ディーラーは Reg SCI を理解しておく必要があります。また、大規模 ATS を運営するブローカー・ディーラー自身が SCI 対象事業者となる場合もあります。

Consolidated Audit Trail(CAT): CAT は、SRO に代わって FINRA が運営する包括的な注文追跡システムです。CAT では、ブローカー・ディーラーと取引所に対し、NMS 証券および OTC 株式証券のすべての注文について、注文の発生からルーティング、変更、取消、執行に至る全ライフサイクルの報告が求められます。CAT の報告には、顧客の識別(FDID — Firm Designated Identifier による)、注文の受領および発生のタイムスタンプ、注文のルーティングイベント(送信先の取引施設を含む)、注文の変更および取消、執行の詳細(価格、数量、取引施設)が含まれます。企業は CAT Reporter ID を割り当て、顧客口座を FDID に対応付け、CAT プロセッサーに日次報告を提出する必要があります。取引所接続インフラストラクチャでは、CAT コンプライアンスに必要なタイムスタンプとルーティングの詳細を記録する必要があります。

マーケットアクセス制御(SEC Rule 15c3-5): Rule 15c3-5 では、マーケットアクセス(取引所または ATS へのアクセスを含む)を提供するすべてのブローカー・ディーラーに対し、マーケットアクセスに伴う財務上、規制上、その他のリスクを管理するために合理的に設計されたリスク管理制御と監督手順を確立し、文書化し、維持することが求められます。必須の制御には、事前設定された信用または資本のしきい値を超える注文の入力を防ぐこと、誤った注文の入力を防ぐこと(例:価格妥当性チェック、注文サイズ制限、重複注文の検出)、取引システムへのアクセスを許可された者に制限すること、適用されるすべての規制要件(例:空売り制限、取引停止)を遵守することが含まれます。制御はブローカー・ディーラーの直接かつ排他的な管理下に置く必要があり、顧客や他者に委任することはできません。ブローカー・ディーラーは、マーケットアクセス制御の有効性を定期的に(少なくとも年1回)レビューする必要があります。

マーケットアクセスの事前取引リスク制御: Rule 15c3-5 および取引所規則で求められる、または期待される具体的な制御には、注文価格の許容範囲(現在の市場価格から大きく離れた価格の注文を拒否する)、最大注文サイズ制限、銘柄ごとおよび合計のポジション制限と資本エクスポージャー制限、重複注文の検出、リスクしきい値を超えた場合に企業からのすべての注文フローを停止できるキルスイッチ、取引制限対象証券リスト(取引停止中、上場廃止済み、または取引制限対象の証券の取引を防ぐ)、空売りコンプライアンスチェックが含まれます。これらの制御は、レイテンシーへの影響を最小限に抑えつつ、リアルタイムで動作する必要があります。

実践例

エンドツーエンドのシナリオについては、references/examples.md にある3つの実践例を読み込んでください:(1)Rule 15c3-5 の統制を適用した、5つの株式取引所への FIX 接続の設計、(2)統合フィードとダイレクトフィードを用いた市場データインフラストラクチャの構築、(3)OMS、SOR、市場データシステムにまたがる取引停止への対応の実装。

よくある落とし穴

  • アプリケーションの再起動後に FIX シーケンス番号を永続化できず、シーケンス番号のリセットによって注文の重複送信や約定レポートの欠落が発生する
  • プライマリーとバックアップの FIX セッションに同じネットワーク経路を使用するため、単一のスイッチまたは通信事業者の障害で両方の接続が同時に停止する
  • ギャップリカバリー中に PossDupFlag を正しく処理しない — PossDup の約定レポートを新しい約定として処理すると、約定数が二重に計上される
  • 取引戦略がレイテンシーに敏感な場合に、NBBO を SIP だけに依存する — SIP はダイレクトフィードより数百マイクロ秒から数ミリ秒遅い
  • 注文ルーターで LULD 価格帯の更新を無視し、価格帯違反により取引所で注文が拒否される
  • すべての取引停止タイプを同じものとして扱う — 取引停止の種類によって、未約定注文、取引再開の仕組み、規制上の義務への影響は異なる
  • 最新かつテスト済みの休場日カレンダーを維持せず、システムが市場休場日に取引を試みたり、半日取引の早期終了を見逃したりする
  • 取引スタッフが迂回、上書き、無効化できるプリトレードリスク統制(Rule 15c3-5)を導入する — 統制はブローカーディーラーのリスク管理部門が排他的に管理しなければならない
  • フェイルオーバー手順を定期的にテストしない — 実際の障害時に機能しない未テストのバックアップ接続には、耐障害性がない
  • 内部システムでティッカーシンボルだけを識別子として使用する — ティッカーシンボルは変更や再利用があり、グローバルに一意ではないため、内部システムではシンボル体系のマッピングとともに、安定した識別子(CUSIP、ISIN、または内部 ID)を使用する必要がある
  • レイテンシー分析で取引所のタイムスタンプと受信タイムスタンプの違いを考慮しない — 2つの時計は同期していない可能性があり、片道レイテンシーの測定には時計の同期(例:PTP または GPS)が必要
  • FIX セッションの Logon を受信した時点で、取引所が注文を受け付ける準備ができていると思い込む — 多くの取引所では、マッチングエンジンが寄り前から取引開始へ移行したことを示す、別個の「取引セッション状態」メッセージがある

相互参照

  • order-lifecycle(trading-operations プラグイン):注文状態、注文タイプ、作成から約定または取消までの注文ライフサイクル — 取引所接続は、注文ライフサイクルイベントを伝送するトランスポート層です
  • trade-execution(trading-operations プラグイン):執行アルゴリズム、取引所の選択、スマート注文ルーティングは、このスキルで説明する接続および市場データインフラストラクチャに依存します
  • pre-trade-compliance(trading-operations プラグイン):プリトレードリスク統制(Rule 15c3-5)は市場アクセスに関する規制要件であり、取引所接続アーキテクチャに統合する必要があります
  • settlement-clearing(trading-operations プラグイン):約定後、取引所接続システムから清算・決済へと取引が流れます — 下流処理には正確な取引所識別子と約定識別子が不可欠です
  • operational-risk(trading-operations プラグイン):取引所接続の障害はオペレーショナルリスクの大きな要因であり、このスキルに含まれる耐障害性、フェイルオーバー、監視の実践はオペレーショナルリスク統制です
  • books-and-records(compliance プラグイン):取引所接続を通じて取得した注文データと約定データは、SEC Rules 17a-3 および 17a-4 に従って保持する必要があります。また、CAT の報告義務では、接続システムから包括的な監査証跡データを取得する必要があります

コメント