火曜日の10:07、当社のリサーチエージェントが、指数ETFに短期的な強気のセットアップを検出しました。シグナル自体はごく一般的なものでした。価格は20本バーの平均を上回り、実現ボラティリティは低下傾向にあり、翌セッションにはマクロ指標の発表が予定されていました。提案されたのは、満期までおよそ2週間のコールスプレッドでした。
バックテストでは有望でした。しかし、ペーパー取引では発注されませんでした。注文を比較すると、シグナルのタイムスタンプは一致し、原資産価格の差も数セント以内でした。違っていたのは契約です。バックテストは過去のオプションチェーンで最もよく見えた金曜満期を買っていましたが、ペーパー取引のプロセスは、その1週間後にあたる次の上場満期を選んでいました。
この差は、カレンダーの結合処理が原因でした。「満期までの日数」を日付の属性として扱い、目標日に最も近い満期の契約を選んでいたのです。過去データには、検証対象の日付より後に追加された週次満期が含まれていました。バックテストは、未来の契約を使っていましたが、それは一見すると無害な便宜的処理に見えていました。
最初に疑ったのはタイムゾーンの不具合でした。オプションの満期日では、特にこうした問題が起きやすいためです。市場の取引時間はニューヨークで終了し、取引所のタイムスタンプはUTCで保存されることがあり、日付をパイプラインで不用意に型変換すると、午前0時をまたいで日付がずれることがあります。確認したところ、タイムスタンプに問題はありませんでした。その契約は、あの火曜日の過去の銘柄ユニバースには存在していなかったのです。
ここから得た最初の教訓は、過去のオプションチェーンには時点ごとの上場銘柄ユニバースが必要だということです。契約の満期日は、その契約がいつ終了するかを示します。いつ上場したのか、いつ取引可能になったのか、あるいは当時のシステムが選択できたのかは分かりません。
そこで、判断時点で利用できた情報を基準に選択処理を組み直しました。候補となる各契約について、上場タイムスタンプが判断時点以前であること、鮮度のしきい値を超えて古くない有効な気配値があること、そして戦略が注文を出せる取引セッションであることを必須にしました。また、順位付けの前に候補一式を記録するようにしました。これが重要でした。以前のバックテストは勝者だけを保存していたため、条件を満たす契約を5つ比較したのか、それともまだ到来していないカレンダーからひそかに選んだのか、判断できなかったのです。
次に、スプレッドの価格算出に使われた気配値を調べました。バックテストでは、各レッグの最新気配値をそれぞれ独立に取得していました。コールの売気配は10:06:58、ショートコールの買気配は10:04:11のものでした。広めに設定されたデータポリシー上は、どちらも十分新しい気配値でしたが、その間に市場は動いていました。非同期の各レッグから算出したスプレッドのミッド価格は、実際には一度も存在しなかった市場を表すことがあります。
気配値のルールを変更し、両レッグのタイムスタンプが2秒以内に収まり、クロス状態やサイズゼロの市場でないことを必須にしました。その結果、利用可能な過去の観測数は減りましたが、残った価格はより信頼できるものになりました。同期した気配値がない場合は、古い価格で穴埋めせず、その候補を利用不可として扱いました。
次は順位付けのルールです。エージェントは、気配値上のスプレッドコストが最も低い満期を選んでいました。一見妥当に思えますが、スプレッドの気配値が古く、表示サイズが1枚しかない場合には問題になります。目的を明確にしました。最低限の気配値サイズ、鮮度、上場の各チェックを通過した契約の中から、定義されたリスク1単位あたりの期待ペイオフを最大化します。この例では、最も近い適格満期の2レッグ間の気配値幅は$0.42で、さらに先の満期では$0.31でした。安く見えたほうは、ショートレッグに表示されていたのが1枚だけでした。
| 候補 | その時点で満期は利用可能か? | 気配値の経過時間 | ショートレッグの表示サイズ | 判断 |
|---|---|---|---|---|
| 金曜の週次満期 | いいえ | 該当なし | 該当なし | 除外 |
| 翌週の金曜日 | はい | 1.4秒 | 18枚 | 適格 |
| 第3金曜日 | はい | 9.8秒 | 1枚 | 古く、流動性も薄いため除外 |
このルールで事例を再現しました。バックテストはペーパー取引と同じ満期を選び、他の契約を除外した理由も記録するようになりました。結果として、スプレッドのエントリー価格は当初の過去データ上の約定より$0.11不利になりました。これは戦略に価値がないという意味ではありません。以前のパフォーマンス数値には、ライブのプロセスでは再現できない取引選択が含まれていたということです。
ちょっとした厄介事もありました。取引所のシンボル表記の違いは、満期の不具合をデータ品質の問題のように見せることがあります。あるベンダーでは、週次コードと月次コードが1文字だけ異なっていました。私は今も監査ログに、生のシンボルと正規化した契約キーの両方を残しています。洗練された方法ではありませんが、整った結合結果を安易に信じずに済んでいます。
オプションのバックテストを構築するなら、各判断時点の候補一式を、各契約の上場状況、気配値のタイムスタンプとサイズ、除外理由とともに保存してください。そのうえで、契約選択をそのスナップショットから決まる関数にします。満期の選択も戦略の一部です。バックテストがペーパー取引では利用できなかった契約を参照できるなら、答えがすでに変わった後からシグナルの比較を始めることになります。
← 記事一覧


