Knight Capital はデプロイメントロールバックを市場管理の説明責任テストとした

概況

• Knight Capital の2012年8月1日の取引インシデントは、ソフトウェアデプロイメントの失敗が自動注文ルーティング環境内で意図しない動作を引き起こし、企業が活動を停止する前に深刻な損失を生み出したため、市場管理の説明責任テストとなった。
• 誰がソフトウェアデプロイメントの分離、休眠コードの削除、ロールアウト検証、取引システムのキルスイッチ、市場リスク監視、ロールバック権限、および損失が存続的になる前に自動市場システムを停止できることの証明を実際に管理していたのか？
• 説明責任の問題は、自動取引システムがリリース管理を市場リスク管理に変えることであり、欠陥のあるソフトウェアが数秒の実行を機関の破綻に変える可能性があることである。
• 投資家、カウンターパーティ、市場取引所、規制当局、エンジニア、リスク管理者、取引顧客は、ソフトウェア変更管理、キルスイッチ、市場監視が自動化された害の速度に一致するという証拠を必要としていた。
• この記事は、SEC 命令をhttps://www.sec.gov/files/litigation/admin/2013/34-70694.pdfを主要な公開執行記録として、Knight の SEC 提出会社声明をhttps://www.sec.gov/Archives/edgar/data/1060749/000119312512332176/d391111dex991.htmを即時の財務影響の会社証拠として、市場アクセス、Regulation SCI、FINRA、eCFR、NIST、および連邦準備制度の資料を記録にない私的事実の証明ではなく管理コンテキストとして扱う。

なぜこの事例がリスクと説明責任のファイルに含まれるのか

Knight Capital は、リスクと説明責任のファイルに含まれるべき事例です。なぜなら、このインシデントは、ソフトウェアデプロイメント、市場アクセス、自動リスク制限が1つの運用表面になると何が起こるかを示しているからです。多くの業界では、不適切なデプロイメントは障害、請求エラー、またはサービスのロールバックを引き起こす可能性があります。自動取引環境では、同じ障害モードが数ミリ秒以内に注文を公開市場に出し、人間のレビューよりも速くポジションを蓄積し、企業は技術、リスク、取引、法務、経営陣がシステムを直ちに停止する権限と証拠を持っているかどうかを決定せざるを得なくなります。

公開執行記録は異常に具体的です。SEC 行政命令は、Knight Capital Americas LLC の自動株式注文ルーティングシステムである SMARS において、2012年8月1日に重大なエラーが発生したことを説明しています。SEC のプレスリリースは、不十分な保護措置と市場アクセスルールの違反の疑いを明らかにしています。Knight 自身の SEC 提出の8月2日付声明は、会社が誤ったポジションを解消し、約4億4000万ドルの実現税前損失を被ったと報告しています。その後の Form 10-Q は、8月1日の損失とその後の資金調達について説明しています。

これらの文書は、この事例を通常のソフトウェア事後分析とは異なるものにしています。損害は1つの企業が損失を被っただけではありません。インシデントは公開証券市場での取引を混乱させ、ブローカー・ディーラーの市場アクセス管理に関与し、SEC が Rule 15c3-5 に基づいて初めて執行措置を取った事例となりました。このルールの採択リリースと小規模事業者向けコンプライアンスガイドは、市場アクセスを規制された管理表面として位置づけています。なぜなら、ブローカー・ディーラーの取引所または代替取引システムへのアクセスは、財務、規制、および市場の整合性リスクを生み出す可能性があるからです。

したがって、責任の問われる質問は実務的なものとなります。誰がソフトウェアデプロイメントの分離、休眠コードの削除、ロールアウト検証、取引システムのキルスイッチ、市場リスク監視、ロールバック権限、および損失が存続的になる前に自動市場システムを停止できることの証明を実際に管理していたのか？この質問は「ソフトウェアのバグ」や「アルゴリズム取引の失敗」と答えるだけでは不十分です。それらのラベルでは範囲が狭すぎます。この事例は、一連の管理、すなわち、コードが本番環境に移動する方法、古い機能が廃止される方法、新しい取引経路がテストされる方法、注文フローが監視される方法、リスク制限が実施される方法、アラートがエスカレーションされる方法、取引が停止される方法、そして企業が同じ失敗が再発しないことを証明する方法に関するものです。

また、この事例は、エンタープライズソフトウェア自動化と公開市場の信頼を結びつけるため、ここに含まれます。自動取引企業は民間企業ですが、公開市場インフラを通じて運営されています。システムが誤動作すると、取引所、カウンターパーティ、顧客、清算会社、規制当局、他の投資家は不確実性を吸収しなければならない可能性があります。リスクは内部の財務損失だけではありません。機械速度の実行と人間速度のガバナンスのミスマッチです。

公開記録は1行の悪いコードではなく、制御の連鎖を特定する

SEC 命令は中心的な証拠源です。なぜなら、インシデントを単なる偶発的なデプロイメントではなく、リスク管理統制と監視手順の失敗として説明しているからです。命令は、Knight がニューヨーク証券取引所のリテール流動性プログラムに関連する新しいコードをデプロイした一方で、休眠機能が環境に残っていたことを説明しています。レガシーフラグが古いコードと相互作用し、その結果生じた活動がシステム停止前に数百万件の誤った注文を生成した方法を説明しています。正確な内部ファイル、リポジトリ履歴、チャット記録、Runbook は公開されていません。しかし、公開命令は責任表面を特定するのに十分です。

最初の統制はデプロイメントの完全性です。すべての本番サーバーが一貫したコードを受け取ることに依存するリリースプロセスには、すべてのターゲットが更新され、検証され、調整されたという証拠が必要です。責任問題は、エンジニアが間違いを犯したかどうかだけではありません。組織が市場よりも早く部分的なロールアウトを検出できるデプロイメントシステムを設計したかどうかです。市場アクセス環境では、部分的なデプロイメントは無害な矛盾ではありません。同じ公開市場に対して異なるサーバーから異なるメッセージを送信する可能性があります。

2つ目の統制は休眠コードの削除です。ライブフラグを介してまだ到達可能な古い機能は、真に廃止されていません。それは潜在的な管理リスクとして残ります。新しいリリースがフラグやメッセージパスを再利用する場合、組織はどの古いコードがそのシグナルにまだ応答できるかを知らなければなりません。この教訓は Knight よりも広範です。ソフトウェアライフサイクルとロックインは、ベンダーの問題だけではありません。それらは、削除が不便であったり、文書化が不十分であったり、触るのがリスクがあったりするために古い内部ロジックが生き残る場合、企業内部にも現れます。休眠コードは、チームがもはや動作していないと信じているからこそ、負債となり得ます。