order-lifecycle

注文のライフサイクル

基本概念

注文ステートマシン

注文ステートマシンは、あらゆる注文管理システムの中核となる抽象概念です。注文が取り得るすべての状態と、状態間で有効なすべての遷移を定義します。ステートマシンを適切に実装することで、不可能な遷移（キャンセル済み注文の約定など）を防ぎ、監査証跡の完全性を確保し、クライアント、取引相手、規制当局に注文状況を報告するための基盤を提供できます。

標準的な注文状態：

• New： 注文は内部で作成されていますが、まだ執行市場に送信されていません。注文入力と検証後、OMS における初期状態です。
• Pending New： 注文は執行市場に送信されていますが、まだ確認応答を受信していません。注文は送信中です。ネットワーク遅延や市場での処理時間により、送信から受理までの間に時間差が生じるため、この状態が存在します。
• Accepted（市場での New）： 執行市場は注文の受領を確認し、注文板に登録しました。FIX の ExecType=New / OrdStatus=New 確認応答を受信した状態です。
• Partially Filled： 注文は 1 回以上約定していますが、全数量の約定には至っていません。累計約定数量はゼロより大きく、注文数量未満です。
• Filled： 注文は全量が執行されました。累計約定数量は注文数量と等しくなります。これは終端状態です。
• Pending Cancel： 注文のキャンセル要求は送信されていますが、市場ではまだキャンセルが確認されていません。この間も元の注文が約定する可能性があり、これは重大な競合状態です。
• Canceled： 注文は市場によって正常にキャンセルされました。未約定数量は以後、執行対象ではありません。これは終端状態です。キャンセル前に部分約定している場合、注文は「部分約定後キャンセル」と表現されることがあります。約定分は有効で、残数量がキャンセルされます。
• Pending Replace： キャンセル／置換（変更）要求は送信されていますが、まだ確認されていません。Pending Cancel と同様、この間も約定が発生する可能性があります。
• Replaced： 元の注文は、パラメーター（価格、数量、その他のフィールド）を変更した新しい注文に置き換えられました。元の注文は Replaced（終端）に遷移し、変更後の条件で新しい注文が作成されます。FIX では、置換によって ClOrdID と OrigClOrdID でつながるチェーンが作成されます。
• Rejected： 執行市場が注文を拒否しました。一般的な拒否理由には、無効な銘柄コード、市場で許可されていない注文タイプ、許容範囲外の価格、権限不足、市場の休場などがあります。これは終端状態です。
• Expired： 注文の有効期間指定により、全量が約定する前に期限切れになりました。DAY 注文は市場の引け時に期限切れになり、GTD 注文は指定日に期限切れになります。これは終端状態です。
• Suspended： 通常は、証券の売買停止、サーキットブレーカーの発動、または規制上の取引停止により、市場が注文を一時的に停止しました。注文は注文板に残りますが、停止が解除されるまでマッチングの対象にはなりません。
• Done for Day： 注文は当日の取引ではこれ以上執行されませんが、翌取引日に再開される場合があります。これは、まだ全量が約定していない複数日有効の注文（GTC）に適用されます。

終端状態と非終端状態： 終端状態（Filled、Canceled、Replaced、Rejected、Expired）は注文のライフサイクルの終わりを示し、それ以上の遷移はできません。非終端状態（New、Pending New、Accepted、Partially Filled、Pending Cancel、Pending Replace、Suspended、Done for Day）は、ほかの状態に遷移する場合があります。ステートマシンは、終端状態からの遷移を一切許可しないという不変条件を強制する必要があります。

有効な状態遷移（代表例であり、網羅的ではありません）：

• New -> Pending New（取引所に注文を送信済み）
• Pending New -> Accepted（取引所が受け付けを確認）
• Pending New -> Rejected（取引所が拒否）
• Accepted -> Partially Filled（最初の一部約定）
• Accepted -> Filled（1回の約定で全数量が約定）
• Accepted -> Pending Cancel（取消リクエストを送信）
• Accepted -> Pending Replace（訂正リクエストを送信）
• Accepted -> Expired（有効期限の満了）
• Accepted -> Suspended（取引停止）
• Partially Filled -> Partially Filled（追加の一部約定）
• Partially Filled -> Filled（最終約定により注文が完了）
• Partially Filled -> Pending Cancel（残数量の取消）
• Partially Filled -> Pending Replace（残数量または価格の訂正）
• Pending Cancel -> Canceled（取消を確認）
• Pending Cancel -> Filled（取消処理の前に約定通知が到着 — 競合状態）
• Pending Cancel -> Partially Filled（取消処理中の一部約定）
• Pending Replace -> Replaced（訂正を確認し、新しい注文を作成）
• Pending Replace -> Filled（訂正処理の前に約定通知が到着）
• Pending Replace -> Partially Filled（訂正処理中の一部約定）
• Pending Replace -> Canceled（取引所が訂正ではなく取消を実行。約定後の数量不足が原因となる場合があります）
• Suspended -> Accepted（取引停止解除後、注文を再開）
• Suspended -> Expired（取引停止中に注文が期限切れ）
• Done for Day -> Accepted（翌取引日に注文を再開）
• Done for Day -> Expired（GTC の有効期限に到達）

状態の永続化と復旧： 注文の状態は、注文の送信元に確認応答を返したり、注文に対する何らかのアクションを実行したりする前に、永続的に保存する必要があります。通常はデータベースまたは先行書き込みログに保存します。クラッシュ後に OMS を再起動した場合、保存済みの状態と、復旧中に執行取引所から受信したメッセージを基に、すべての有効な注文の現在の状態を再構築できなければなりません。そのためには、冪等なメッセージ処理（約定通知の重複による約定数の二重計上を防止）と、取引所への注文状況照会による状態の照合が必要です。

注文タイプ

注文タイプは、注文が市場とどのようにやり取りするかを規定する執行指示です。

• 成行注文： 利用可能な最良価格で直ちに執行します（流動性の高い市場では）執行が保証されますが、価格は保証されません。緊急に執行する必要がある場合に適しています。リスク：変動の激しい市場や流動性の低い市場ではスリッページが発生し、執行価格が直近の提示価格と大きく異なる場合があります。
• 指値注文： 指定価格またはそれより有利な価格で執行します（買い注文は指値以下、売り注文は指値以上）。価格は保証されますが、執行は保証されません。執行の確実性より価格管理を重視する場合に適しています。リスク：市場価格が指値に達しない場合、注文が約定しないことがあります。一部約定により、残余ポジションが残る場合があります。
• 逆指値注文（ストップロス）： ストップ価格に達する（またはその価格を通過する）と、成行注文になります。既存ポジションの損失を抑えたり、利益を保護したりするために使用されます。リスク：発動後は成行注文として執行されるため、窓開けや変動の激しい市場では、ストップ価格より大幅に不利な価格で約定する場合があります。
• 逆指値付き指値注文： ストップ価格に達すると、成行注文ではなく指値注文になります。ストップ価格が注文を発動し、指値が執行価格を制御します。逆指値注文より価格を保護できます。リスク：市場価格が指値を飛び越えて窓開けした場合、注文が発動しても約定しないことがあります。
• トレーリングストップ： 市場が注文者に有利な方向へ動くと、ストップ価格が自動的に調整される逆指値注文です。ストップ価格は、市場価格の一定額または一定割合だけ下（売りの場合）または上（買いの場合）に設定されます。市場が有利な方向へ動くとストップ価格も追随し、市場がトレール幅分だけ反転するとストップが発動します。リスク：発動後のリスクは逆指値注文と同じです。また、通常の市場ノイズで発動しないよう、トレール幅を適切に調整する必要があります。
• 引け成行注文（MOC）： 大引けのオークション価格で執行します。ベンチマーク追随型の戦略や、取引終了時のポートフォリオ調整に使用されます。取引所はMOC注文の受付締切時刻を設けています（NYSE：東部時間午後3時50分）。リスク：価格を制御できず、大引けのオークション価格が変動することがあります。
• 引け指値注文（LOC）： 終値が指定した指値と同じか、より有利な場合に限り、大引けのオークション価格で執行します。終値を狙った執行で価格を保護できます。リスク：終値が指値を超えると、注文が約定しないことがあります。
• ペッグ注文： 注文価格を参照価格（通常はNBBOの仲値、最良買気配、または最良売気配）に連動させ、参照価格の動きに合わせて自動的に調整します。市場に受動的に追随するため、アルゴリズム取引や機関投資家の取引で使用されます。動作は取引所によって異なります。
• アイスバーグ注文（リザーブ注文）： 注文数量全体の一部のみを板に表示し、残りの数量（「リザーブ」数量）は非表示にします。表示数量が約定すると、リザーブ分から追加の株式が板に補充されます。注文全体の数量を隠して大口注文の市場インパクトを最小限に抑えるために使用されます。リスク：高度な取引参加者はアイスバーグ注文のパターンを検出できる場合があります。また、リザーブ注文に対応していない取引所もあります。

有効期間の指示

有効期間（TIF）の指示は、注文が自動的に取り消される、または期限切れになるまで有効な期間を指定します。

• DAY： 注文は当日の取引時間中のみ有効です。市場の引けまでに約定しなかった場合、取り消されます。ほとんどの取引所や注文管理システムで、デフォルトのTIFです。オーバーナイトリスク：DAY注文は翌日に持ち越されません。注文を維持する場合、アドバイザーは翌取引日に再送信する必要があります。
• GTC（Good Til Canceled）： 注文は、発注者が明示的に取り消すか、取引所が定めるGTCの最大有効期間（取引所によりますが、通常は暦日で60～90日）に達するまで有効です。GTC注文は市場の引け後も有効で、各取引日に再開されます。リスク：古いGTC注文は、現在の投資判断を反映しなくなった価格で約定する可能性があります。各社は、未決済のGTC注文を定期的に再評価するための注文レビュー手順を整備する必要があります。
• IOC（Immediate or Cancel）： 注文は直ちに、全量または一部を約定させる必要があります。直ちに約定しなかった部分は取り消されます。IOC注文が板に残ることはありません。受動的な注文を提示せず、現在利用可能な流動性と取引したい流動性獲得戦略に適しています。
• FOK（Fill or Kill）： 注文は直ちに全量約定するか、全量取り消される必要があります。一部約定は認められません。IOCよりも制約が厳しい指示です。リスクポジションを完全に相殺する必要があるヘッジ取引など、一部約定が許容されない場合に適しています。
• GTD（Good Til Date）： 注文は、指定日または取り消しまで有効です。GTCと同様に機能しますが、明確な有効期限が設定されます。特定のイベントや期限に紐づく注文に便利です。
• OPG（At the Open）： 注文は寄り付きオークションにのみ参加します。寄り付きの処理中に約定しなかった場合、取り消されます。始値を希望する執行ベンチマークとする場合に使用します。
• CLO（At the Close）： 注文は引けのオークションに参加します。機能的にはMOCと似ていますが、注文タイプではなく有効期間の指示として表されます。取引所によって実装は異なります。

市場の引け時の動作： DAY注文は取り消されます。GTC注文とGTD注文はDone for Dayに移行し、翌取引日に再開されます。IOC注文とFOK注文は、定義上、引け前に約定または取り消し済みとなります。MOC注文とLOC注文は引けのオークション中に執行されます。OMSは、期限切れとなったDAY注文に対する適切な取消確認の生成や、複数日にわたる注文の状態更新を含め、日次切り替え時に各TIFを正しく処理する必要があります。

オーバーナイト処理： Done for DayとなったGTC注文は、翌取引日に取引所へ再送信するか、再開する必要があります。GTC注文をネイティブに維持する取引所もあれば、OMSが毎朝再送信する必要がある取引所もあります。OMSは、再送信が必要なGTC注文を追跡し、日次開始ワークフローの一環として再送信処理を行う必要があります。

FIX プロトコルの基礎

Financial Information eXchange（FIX）プロトコルは、電子取引の通信における主要な標準です。取引所、ブローカー、または取引相手との連携や、それらを対象とするシステムの構築には、FIX の理解が不可欠です。

注文フローにおける FIX メッセージの種類：

• NewOrderSingle（MsgType=D）： 取引所に新しい注文を送信します。シンボル、売買サイド、数量、注文タイプ、価格、執行条件、有効期限、口座など、すべての注文パラメーターを含みます。
• ExecutionReport（MsgType=8）： 取引所からの主要な応答メッセージです。新規注文の確認（ExecType=New）、約定の報告（ExecType=Trade または ExecType=Fill）、一部約定の報告（残数量が 0 より大きい場合の ExecType=Trade）、取消の確認（ExecType=Canceled）、訂正の確認（ExecType=Replaced）、拒否の報告（ExecType=Rejected）、期限切れの報告（ExecType=Expired）に使用されます。ExecutionReport は FIX 注文フローで最も重要なメッセージであり、OMS のすべての状態遷移を駆動します。
• OrderCancelRequest（MsgType=F）： 以前に送信した注文の取消を要求します。OrigClOrdID（取り消す注文の ClOrdID）と、取消要求自体の新しい ClOrdID を含みます。
• OrderCancelReplaceRequest（MsgType=G）： 以前に送信した注文の変更（価格、数量、その他のパラメーター）を要求します。OrigClOrdID と新しい ClOrdID を含みます。取引所はこれを、元の注文の取消と、変更後の条件による新しい注文の受理として扱います。可能な場合は、これらをアトミックに処理します。
• OrderCancelReject（MsgType=9）： 取消要求または訂正要求を受理できない場合に、取引所が応答として送信します。よくある理由として、注文がすでに約定済みである、すでに取り消されている、または取消が許可されない状態（取引停止中の一時停止など）にあることが挙げられます。

主な FIX タグ： OMS の状態を左右するタグは、注文の識別と連鎖に使用する ClOrdID（11）／OrderID（37）／OrigClOrdID（41）、状態遷移に使用する OrdStatus（39）と ExecType（150）、約定の計上に使用する CumQty（14）／LeavesQty（151）／AvgPx（6）です。残数量を独自に算出するのではなく、取引所からの LeavesQty を信頼してください。一部約定や訂正の後では、両者の値が食い違うことがあります。

FIX セッション層とアプリケーション層： FIX は、セッション層（接続管理、ハートビート、シーケンス番号、ギャップリカバリー）とアプリケーション層（注文、約定、取消。このスキルの対象）の 2 層で動作します。セッション層の管理は取引所接続スキル（trading-operations）が担います。セッションが切断された場合は、アプリケーション層のメッセージ送信を再開する前に、そこで再接続とシーケンスの照合が必要です。

FIX のバージョン： FIX 4.2 は現在も広く導入されており、多くの取引所で基準となっています。FIX 4.4 では、複数レッグ注文や割り当てメッセージのサポート強化などの改善が加わりました。FIX 5.0 では FIXT トランスポート層（セッションプロトコルとアプリケーションプロトコルを分離）が導入され、市場データや取引後メッセージのサポートが追加されました。新しい取引所に接続する際は、どの FIX バージョンと、取引所がサポートするメッセージ拡張（あれば）を確認してください。

キャンセルおよび訂正のワークフロー

キャンセルおよび訂正のワークフローは、注文ライフサイクル管理の中でも特に運用上の影響が大きい部分です。これらの処理では、同時に発生する状態変更や競合状態、予期しない結果が生じる可能性があります。

キャンセルリクエストのフロー：

1. OMS は、キャンセル対象の注文の OrigClOrdID を参照し、キャンセルリクエストには新しい ClOrdID を割り当てて、OrderCancelRequest（MsgType=F）を取引所に送信します。
2. OMS で注文が Pending Cancel に遷移します。
3. 取引所は、キャンセルを確認する ExecutionReport（ExecType=Canceled、OrdStatus=Canceled）、またはキャンセルリクエストを拒否する OrderCancelReject（MsgType=9）のいずれかを返します。
4. キャンセルされた場合、注文は Canceled（終端状態）に遷移します。拒否された場合、注文は直前の状態（Accepted または Partially Filled）に戻ります。

訂正（変更）リクエストのフロー：

1. OMS は、OrigClOrdID を参照し、新しい価格、新しい数量、またはその両方を含む訂正後の注文パラメーターを指定して、新しい ClOrdID を割り当てた OrderCancelReplaceRequest（MsgType=G）を取引所に送信します。
2. 注文が Pending Replace に遷移します。
3. 取引所は、訂正を確認する ExecutionReport（ExecType=Replaced、OrdStatus=Replaced）、またはリクエストを拒否する OrderCancelReject のいずれかを返します。
4. 訂正された場合、元の注文は Replaced（終端状態）に遷移し、訂正後のパラメーターと新しい ClOrdID を持つ新しい注文が OMS に作成されます。拒否された場合、元の注文は直前の状態に戻ります。

競合状態 — キャンセルと約定： 最も重大な競合状態は、キャンセルリクエストと約定が処理中に交差する場合に発生します。OMS がキャンセルリクエストを送信した後、取引所が処理する前に注文が（全量または一部）約定することがあります。取引所は、約定の ExecutionReport に続いて OrderCancelReject を返す場合があります（注文が約定済みのためキャンセルできない場合）。または、約定とキャンセル確認の両方を返す場合もあります（部分約定のみで、残りの数量がキャンセルされた場合）。OMS は、あらゆるメッセージの順序に対応する必要があります。

• 約定が先に届き、その後に CancelReject が届く場合：注文は Filled です。キャンセルリクエストは無効になります。
• CancelReject が先に届き、その後に約定が届く場合：OMS は、約定を処理するまで Pending Cancel から直前の状態に戻してはいけません。順序が重要です。
• 部分約定とキャンセル確認の場合：キャンセルが有効になる前に注文の一部が約定しています。部分約定は有効で、残りの数量はキャンセルされます。

注文チェーン（ClOrdID と OrigClOrdID のリンク）： キャンセルまたは訂正のたびに、注文チェーンに新しいリンクが作成されます。元の注文の ClOrdID が A であるとします。訂正リクエストは OrigClOrdID=A を参照し、ClOrdID=B を割り当てます。その後の訂正では OrigClOrdID=B を参照し、ClOrdID=C を割り当てます。同じ論理注文に属するすべてのメッセージを正しく関連付けるために、OMS はこのチェーンを維持する必要があります。たとえば、誤った OrigClOrdID を参照するなどしてチェーンが途切れると、取引所がリクエストを拒否したり、さらに悪い場合には誤った注文をキャンセルまたは訂正したりする原因になります。

保留状態の管理： 注文が Pending Cancel または Pending Replace の間、OMS は同じ注文に対して追加のキャンセルまたは訂正リクエストを送信しないでください。キャンセル／訂正リクエストを同時に送信すると、取引所がどのリクエストを処理しているのかが曖昧になり、予期しない結果につながる可能性があります。保留中のリクエストが解決するまで、新たなキャンセルまたは訂正の意図をキューに入れてください。

注文の検証

注文の検証とは、注文を執行先の取引所に送信する前に実行する一連のチェックです。十分に検証することで、エラーを早期に検出し、取引所での注文拒否を防ぎ、リスク管理とコンプライアンス上の制約を確実に守ることができます。

送信前の検証（OMS レベル）：

• 購買力／証拠金のチェック： 注文をカバーするのに十分な現金または証拠金が口座にあることを確認します。買い注文では、利用可能な現金または購買力を確認します。空売り注文では、証拠金の利用可能額と株券の手当て要件（Reg SHO）を確認します。
• ポジション制限： 注文によって口座（または会社全体の集計）のポジションが、規制上の制限（オプションや先物に対して取引所が定めるポジション制限）または社内の制限（リスク管理上の制限）を超えないことを確認します。
• 取引制限リストの照合： 対象の証券が会社の取引制限リストに掲載されていないか確認します。取引制限対象の証券への注文は、厳格にブロックされます。この確認は、重要な未公開情報に基づく取引を防ぐための法的要件およびコンプライアンス要件です。
• 取引時間の検証： 注文が、取引所と証券に適した取引時間内に送信されていることを確認します。市場開場前および取引時間終了後の注文には、明示的な適格性が必要であり、対応する注文タイプが限定される場合があります（通常は指値注文）。
• 銘柄コードの検証： 証券識別子（ティッカー、CUSIP、ISIN、SEDOL）が有効で、対象の取引所で取引可能な有効銘柄に対応していることを確認します。
• 売買単位の検証： 注文数量が取引所の売買単位要件（ラウンドロット、端株、または混合ロット）に準拠していることを確認します。一部の取引所では、端株注文が拒否されたり、異なる方法でルーティングされたりします。
• 価格の妥当性： 指値注文では、指値が現在の市場価格から見て妥当な範囲内にあることを確認します。現在価格の10倍で買う注文は、誤りである可能性が高いです。設定可能なしきい値（例：指値は直近約定価格の10％以内でなければならない）を設けることで、誤入力を検出できます。
• 重複注文の検出： 同じ口座と証券に対して、同一またはほぼ同一の注文が最近送信されていないか確認します。重複注文は、二重入力のミスを示している可能性があります。

取引所レベルの検証： OMS による検証後も、取引所は独自のチェックを実施します。対象の取引所で銘柄コードが有効であること、注文タイプが取引所でサポートされていること、価格が取引所の価格帯制限（値幅制限）の範囲内であること、数量が取引所の最大注文数量以内であること、および参加者に必要な権限があることを確認します。取引所による注文拒否は、FIX の Reject または ExecType=Rejected を含む ExecutionReport と、その理由コードで通知されます。

注文拒否への対応とエラーコード： OMS または取引所が注文を拒否した場合、拒否理由を記録し、ログに残し、注文の発注者に伝える必要があります。FIX Tag 103（OrdRejReason）では、標準化された拒否コードが定められています。ブローカー／取引所の選択肢（0）、不明な銘柄コード（1）、取引所の休場（2）、注文が制限を超過（3）、入力期限超過（4）、不明な注文（5）、重複注文（6）などがあります。OMS は、取引所固有の拒否コードを、トレーダーやオペレーション担当者が対応できるエラーメッセージに対応付ける必要があります。

複数レッグ注文と条件付き注文

取引システムは、複数のレッグを含む注文や、条件付きの執行ロジックを伴う注文に対応する必要があります。

• OCO（One Cancels Other）： 2つの注文が連動しており、一方が約定（または一部約定）すると、もう一方が自動的にキャンセルされます。一般的な使用例は、既存ポジションを挟むように設定した利益確定の指値注文とストップロス注文です。一方が発動すると、もう一方は不要になります。OMS は両方の注文を監視し、一方が約定した際に、残る注文のキャンセルを開始する必要があります。
• ブラケット注文： エントリー注文、利益確定注文、ストップロス注文の3つから成る構造です。利益確定注文とストップロス注文は、エントリー注文の約定後にのみ発注され、OCO ペアを形成します。ブラケット注文には、OMS における条件付きロジックが必要です。子注文は親注文の状態に依存します。
• 条件付き注文： 指定した条件が満たされた場合にのみ有効になる注文です。たとえば、「S&P 500 が 4,000 を下回った場合、AAPL の買い指値注文を $150 で発注する」といった注文です。OMS は条件をリアルタイムで監視し、条件が成立した時点で注文を発注する必要があります。
• 注文リスト： 定義済みの執行戦略（リスト内の全注文を全量約定させる、順次執行する、または個別に執行するなど）に従って、まとめて発注される注文グループです。FIX は NewOrderList（MsgType=E）メッセージを通じて注文リストのメッセージングをサポートしています。
• 親子関係： 親注文の執行時に子注文が生成される、複雑な注文構造です。たとえば、10,000 株の親買い注文から、スマート注文ルーティング戦略の一環として、異なる取引所にルーティングされる複数の子注文が生成されることがあります。OMS は親注文と子注文の関係を追跡し、子注文の約定を集計して親注文のステータスを更新する必要があります。

注文監査証跡

規制要件により、すべての注文活動について包括的な監査証跡を保持することが義務付けられています。

統合監査証跡（CAT）： FINRA の OATS（Order Audit Trail System）に代わる CAT では、ブローカー・ディーラーおよびその他の特定の参加者に対し、NMS 証券および上場オプションのすべての注文について、詳細なライフサイクルイベントを報告することが求められます。報告対象のイベントには、注文の受信、注文の発生、注文のルーティング、注文の変更（キャンセル／置換）、注文の執行、注文のキャンセルが含まれます。CAT では注文発生時点で顧客を特定することが求められるため、規制当局はすべての取引所および仲介業者を通じて、注文の発生から執行またはキャンセルまでを追跡できます。

タイムスタンプの精度： CAT では、最低でもミリ秒単位の精度を持つタイムスタンプが求められます。また、多くの企業では、社内分析やコンプライアンスのために、マイクロ秒またはナノ秒単位の精度で記録しています。注文フローに関わるすべてのシステム間でクロックを同期させることが不可欠です。FINRA Rule 4590 では、クロックを指定された許容範囲内で同期させることが求められています（一般に、手動イベントでは1秒以内、電子イベントでは50ミリ秒以内）。OMS、FIX ゲートウェイ、執行取引所の間でタイムスタンプにずれがあると、解決が困難な監査証跡の不整合が生じる可能性があります。

注文イベントのログ記録： すべての状態遷移、送信したすべてのメッセージ、受信したすべてのメッセージについて、タイムスタンプ、メッセージの内容（または主要フィールド）、イベントを処理したシステムコンポーネントとともに記録する必要があります。ログは不変でなければならず、作成後にエントリーを変更または削除できないようにする必要があります。このイベントログは、規制報告、紛争解決、運用上のフォレンジックの基盤となります。

再構成機能： 規制当局は、特定の期間、証券、口座、またはトレーダーに関する注文活動の完全な再構成を求める場合があります。監査証跡は、単一注文の完全なライフサイクル、取引セッション中における特定の証券のすべての注文、特定のデスクまたは個人が発生させたすべての注文など、あらゆる粒度での再構成に対応する必要があります。再構成には、OMS の記録、FIX メッセージログ、執行取引所の報告、清算・決済記録を相互に関連付ける必要があります。

実例

エンドツーエンドのシナリオについては、references/examples.md にある3つの実例を読み込んでください。（1）ブローカー・ディーラーのOMS向けの注文ステートマシンの設計、（2）競合状態への対処を含むキャンセル／置換ワークフローの実装、（3）新しい執行市場へのFIX接続の統合（セッション層の詳細についてはexchange-connectivityを参照）。

よくある落とし穴

• 許可リスト（明示的に定義された遷移のみを許可する）ではなく、拒否リスト（特定の遷移をブロックする）としてステートマシンを実装すること。拒否リスト方式では、新たな無効遷移が検出されずに通過してしまいます
• キャンセルと約定の競合状態に対処できず、注文がPendingCancel状態のときに約定ExecutionReportが届くと約定が失われること
• 市場が置換を確認する前にClOrdIDを楽観的に更新し、その結果、後続のリクエストで市場が認識しないClOrdIDを参照してしまうこと
• 同じ注文に対するキャンセルと置換のリクエストを同時に許可し、市場で状態が曖昧になること
• インバウンドメッセージに応答したり処理したりする前に注文状態を永続化せず、システム再起動時に状態が失われること
• FIXシーケンス番号を軽視すること。ギャップフィル処理を省略したり、双方の合意なしにシーケンス番号をリセットしたりすると、メッセージが失われます
• ExecutionReportのLeavesQtyを無視して残数量を独自に計算し、部分約定や置換後に市場の認識と食い違うこと
• 定期的な見直しプロセスを設けずにGTC注文を実装し、投資仮説をもはや反映しない価格で古い指値注文が約定する可能性を生じさせること
• OMSで送信前の検証を行わず、取引所による拒否に頼って市場でのみ注文を検証すること。これにより拒否率と往復遅延が増加します
• すべての市場が同じようにFIXを実装していると想定すること。市場ごとに解釈の違い、カスタムタグ、固有のメッセージフロー動作があり、認証時に把握する必要があります
• 十分なタイムスタンプ精度や時刻同期なしで注文イベントを記録し、規制上求められる再構成要件を満たせない監査証跡を作成すること
• 冪等なメッセージ処理を実装せず、重複したExecutionReport（FIXセッションの復旧時によく発生します）によって約定が二重計上され、ポジション追跡が破損すること
• 終端状態の不変性を強制せず、アプリケーションのバグによって注文がFilled、Canceled、またはRejected状態から遷移してしまうこと

相互参照

• trade-execution（trading-operations プラグイン）：OMS を離れた後の注文執行方法を決定する執行アルゴリズム、取引場所の選択、スマート・オーダー・ルーティング、市場のミクロ構造。
• pre-trade-compliance（trading-operations プラグイン）：制限リストのスクリーニング、ポジション制限、注文検証ワークフローに組み込まれた規制上の制約など、注文の送信を制御するコンプライアンスチェック。
• post-trade-compliance（trading-operations プラグイン）：取引監視、最良執行分析、注文ライフサイクルデータを利用する例外報告など、執行後のコンプライアンス監視。
• settlement-clearing（trading-operations プラグイン）：注文執行後の後続プロセスです。取引照合、CCP または二者間ネッティングによる清算、証券と現金の決済を行い、注文ライフサイクルを完了します。
• order-management-advisor（advisory-practice プラグイン）：ここで定義する注文ライフサイクルの概念を基盤とした、ブロック取引、配分、モデル主導の取引、カストディアンへのルーティングなど、アドバイザー固有の注文管理。
• exchange-connectivity（trading-operations プラグイン）：FIX エンジンの設定、ネットワークアーキテクチャ、フェイルオーバー設計など、取引所や執行場所に接続するための技術インフラストラクチャ。
• books-and-records（compliance プラグイン）：注文ライフサイクル全体を通じて生成される注文票、約定記録、監査証跡データの保持を定める、SEC 規則 17a-3／17a-4 および規則 204-2 に基づく記録管理要件。