見出し画像

IB証券TWSのAPIドミトリーFAQ：コンボ注文、ブラケット注文、株式・オプション・先物注文

さーよん

こちらはIB証券（インタラクティブブローカーズ証券）のAPI情報で、公式以上に細かい点がカバーされているDmitry's TWS API FAQを日本語翻訳にかけつつ、わかりにくい部分をできる限り修正した上で魚拓保存しているものです。元のウェブページは量が多すぎて閲覧しにくく、元サイトを翻訳にかけるとPCが固まる上、最近アクセスが不安定になっているため、備忘録用に章ごとに分けて保存しています。


全体目次

  1. TWSアプリ関連

  2. プログラミング言語別コードサンプル

  3. 実装メモ

  4. よくあるエラーと修正方法

  5. ContractDetails、Index、注文方法（共通）

  6. コンボ注文、ブラケット注文、株式・オプション・先物注文（このページ）

  7. 約定照会、デモ口座とリアル口座、グラフ化

  8. データサブスクリプション

  9. スキャナ、基本仕様、過去データ制約、IBゲートウェイ

  10. FX関連、ポートフォリオ情報、その他

コンボ注文

コンボオーダー（ComboOrder）とは複数のコントラクトをまとめて注文する場合の注文方法で、ペアトレード（S&P500 ETFを買ってダウETFを売って鞘を取る）やオプションのスプレッド（ストラドルやストラングル）などを発注する場合に使われ、それぞれのコントラクトはレッグと呼ばれます。

さーよん注記

[Q] レッグの比率とは何ですか？

誰かコンボ注文（コンビネーションオーダー）のレッグの比率について説明してもらえますか？もしくはTWSのドキュメントがあれば教えてください。
コンボオーダーのレッグを組成するときに、この知識が必要ですか？

[A] 投稿者: Despair (#46818)
追加日：2021年3月27日

はい、コンボContractを作成する際には比率を指定する必要があります。

例えば、Amazonの株を1つ売るごとにFacebookの株を3つ買う、というSTK/STKコンボを作成したいとします。

STKとはアセットクラスが株（Stock）であることを指し、ContractクラスのSecTypeに使われる文字列になります。債券はBOND、先物（Futures）はFUT、オプションはOPT、先物オプションはFOPです。カバードコールの場合は原資産とオプションのSTK/OPTコンボとなります。

さーよん注記

その場合、Amazonをレッグ1に比率1で設定し、FBをレッグ2に比率3で設定する必要があります（シンボルは常にアルファベット順にペアリングされる必要があるため、FB/AMZNの順番では動作しません）。

また、比率は約分した状態で1/3と指定し、例えば2/6などとはしないようにします。数学的には同じですが、後者の形式は受け付けられません。

アイアンコンドルの場合、すべてのレッグの比率は1で、スプレッドは4つのオプションで構成され、1アイアンコンドルは各レッグが1オプションずつです。

オプションスプレッドのレッグの順番は問題になりません。

スプレッド契約の定義方法に関するドキュメントはこちらから確認できます：

[Q] コンビネーションオーダーにおいて、Order::lmtPriceフィールド（指値）をどのように設定すればよいですか？コンボオーダーの処理方法を教えてください。

[A] 追加日：2021年5月15日

Josh：Orderクラスでオーダー全体の価格を指定するだけで、各レッグの価格を個別に設定する必要はありません。

コンボ全体の指値は各レッグの指値の合計になります。例えば、1つのレッグを5ドルで購入し、別のレッグを3ドルで売りたい場合、コンボ全体の指値は5ドル－3ドル＝2ドルになります。

Francois G：
コンボオーダーの目的は、複数のレッグを単一のオーダーで処理することです。コンボオーダーが実行されると、すべてのレッグが同時に実行されます。

例えば、製品XとYの2つを扱うコンボを作成したいとします：

  • Xを6単位、25ドルで購入

  • Yを3単位、10ドルで売却

最初に、全てのレッグ数量のGCD（Greatest Common Divisor、最大公約数）を計算する必要があります。この場合、GCDは3です。

コンボは(+2X -1Y)として作成され、order.totalQuantityは3となります。これにより、流動性の低い市場でも一部分だけ約定させることができます。

[Q] 保証付きと保証無し（Non-Guaranteed）コンビネーション注文の理解

[A] 追加日: 2015年10月10日

Joshによる（#45588）

取引所にネイティブなオプションコンボは保証付きコンボです。また、任意の組み合わせのオプション、株式、その他の金融商品で構成される「保証無し」コンボもあります。保証無しコンボでは、全てのレッグが成立しない（小さな）リスクを買い手が負います。

— また —

保証付きコンボ注文がサポートされていない組み合わせの場合、保証無ししか選択肢できません。デフォルトでは、Non-Guaranteedタグが指定されない限りコンボは保証付きです。注文にレッグ数が多すぎる場合は単純に拒否されます。これはペーパーアカウントで簡単にテストできます。

— また —

任意の時点で無数の有効な保証付きコンボが可能なので、すべてをリストするのは簡単ではありません。ほとんどはよく知られたオプションコンボタイプ（ストラドル、ストラングル、バーティカルスプレッド、カレンダースプレッドなど）です。

TWSのストラテジービルダーツールは、利用可能な異なるコンボを示すのに便利です。また、保証付きコンボがサポートされていない場合、サーバーに問い合わせることでエラーが返されます。

[Q] 各レッグのconIdを知らずにオプションコンボレッグを作成する方法は？

オプションコンボレッグを作成するためには各レッグのconIdが必要ですが、これはオプションの満期日や行使価格に基づいてオプションチェーン全体からの検索が必要です。ただし、オプションチェーン全体の契約詳細をダウンロードするのは非常に遅いです。これをより速く行う方法はありますか？

[A] Richardによる（#44631）

追加日: 2021年2月8日

そんなに遅いですか？

私は別の目的で似たようなことをしています。特定の満期日で一定の初期行使価格を超えるすべてのストライクを取得したいので、それらをすべてダウンロードし、不要なものをフィルタリングします。

以下は、MSFTコールのログファイルの抜粋です。6月5日の満期に対する全てのコールを要求したのは、関連する初期行使価格が17:24:40.807に決定された直後です。契約の詳細は17:24:41.596には届き始め（行使価格が172.5未満のものは無視して記録されていません）、すべてが17:24:41.738までに返され、処理されました。処理には各項目の市場データスナップショットのリクエストと受信も含まれるので、短時間で完了しています。

これはそんなに悪くないと思います。1秒以内です。

すべての満期のすべてのストライクを要求しないように注意してください。それは本当に時間がかかります。すべての取引所のすべての満期に対してすべてのストライクを要求するのはさらに時間がかかります。

2020-06-03 17:24:40.807 MSFT@SMART/NASDAQ: initial strike price is: 172.5
2020-06-03 17:24:41.596 Contract: MSFT  200605C00175000@SMART; strike: 175; value: 920
2020-06-03 17:24:41.597 Contract: MSFT  200605C00182500@SMART; strike: 182.5; value: 243
2020-06-03 17:24:41.598 Contract: MSFT  200605C00185000@SMART; strike: 185; value: 106
2020-06-03 17:24:41.598 Contract: MSFT  200605C00187500@SMART; strike: 187.5; value: 35
2020-06-03 17:24:41.603 Contract: MSFT  200605C00205000@SMART; strike: 205; value: 1
2020-06-03 17:24:41.603 Contract: MSFT  200605C00190000@SMART; strike: 190; value: 11
2020-06-03 17:24:41.604 Contract: MSFT  200605C00202500@SMART; strike: 202.5; value: 1
2020-06-03 17:24:41.605 Contract: MSFT  200605C00200000@SMART; strike: 200; value: 1
2020-06-03 17:24:41.605 Contract: MSFT  200605C00210000@SMART; strike: 210; value: 1
2020-06-03 17:24:41.606 Contract: MSFT  200605C00180000@SMART; strike: 180; value: 445
2020-06-03 17:24:41.607 Contract: MSFT  200605C00172500@SMART; strike: 172.5; value: 1160
2020-06-03 17:24:41.607 Contract: MSFT  200605C00192500@SMART; strike: 192.5; value: 4
2020-06-03 17:24:41.608 Contract: MSFT  200605C00197500@SMART; strike: 197.5; value: 2
2020-06-03 17:24:41.608 Contract: MSFT  200605C00177500@SMART; strike: 177.5; value: 670
2020-06-03 17:24:41.609 Contract: MSFT  200605C00207500@SMART; strike: 207.5; value: 1
2020-06-03 17:24:41.609 Contract: MSFT  200605C00195000@SMART; strike: 195; value: 2
2020-06-03 17:24:41.610 Contract: MSFT  200605C00215000@SMART; strike: 215; value: 1
2020-06-03 17:24:41.738 Contract: MSFT  200605C00220000@SMART; strike: 220; value: 1
2020-06-03 17:24:41.738 Target contract: MSFT  200605C00175000@SMART; strike: 175; value: 920

Richard

Bracket注文

[Q] 「Bracket Order」とは何ですか？

[A] IBウェブサイトより：

ブラケット注文は、注文を2つの反対方向の注文で「囲む」ことで、損失を制限し利益を確保するために設計されています。買い注文は、上方の売りリミット注文と下方の売りストップ注文で囲まれます。売り注文は、上方の買いストップ注文と下方の買いリミット注文で囲まれます。

上方および下方のブラケット注文の数量は、元の注文の数量と一致します。デフォルトでは、ブラケット注文は現在の価格から1.0オフセットされています。このオフセット額は、特定の注文の注文行で変更することも、グローバル設定の「注文プリセット」機能を使用して、銘柄や契約、戦略のデフォルトレベルで修正することも可能です。

Bracket Orderの定義
エントリー（買い）注文とエグジット（売り）注文をセットにして発注できる

Bracket OrderのAPIドキュメント

[Q] Bracket Orderの子注文に許可される注文タイプの制限はありますか？

[A] Yair Altmanによる（#46372）

追加日：2021年1月4日

複数の子注文を添付する場合、IBは許可される子注文のパラメータの組み合わせに制限をかける場合があります。例えば、標準のBracket子注文にMOC（マーケット・オン・クロース）終了注文を追加すると、IBは子注文がOCAタイプ3（Reduce on fill without block）を持つことのみを許可し、OCAタイプ1（Cancel on fill with block）や2（Reduce on fill with block）は許可されません。追加のMOC子注文がない場合、OCAタイプ2や3も使用可能です。このような制限は特定のsecTypeや取引所に依存することがあります。

[Q] Bracket Orderの数量には上限がありますか？

[A] （#45913）

追加日：2020年12月3日

すべての子注文の数量は親注文の数量に固定されています。それを変更することはできません。

注文を変更する必要がある場合は、最後の利益確定とストップロス注文を親注文にリンクさせず、独立した注文にする必要があるかもしれません。これをTWSで実行できるかどうかは不明ですが、ポジションサイズを監視し、それに基づいて注文を送信するコードを作成する必要があるかもしれません。

— 補足 —

Bracket注文の場合、子注文の数量は親注文と同じでなければなりません。子注文の数量を親注文とは別に変更することはできません。

[Q] Bracket注文：売りとストップが互いにキャンセルされないのはなぜですか？

Rebecca：

JavaのIB APIを使用してBracket注文（買い、売りLMT、STP）を実行しようとしていますが、LMTとSTPが互いにキャンセルされません。

買い注文IDを親IDとしてLMTとSTP注文に設定しています。

何か問題があるでしょうか？

Order order = createOrder("BUY", 1, "MKT");
Contract buyContract = createContract("ES", "FUT", "GLOBEX", "USD","20100618",null,0.0);
eClientSocket.placeOrder(orderId++, buyContract, order);
lastOrderId = orderId;
          
Order order2 = createExOrder("SELL", 1, "STP", lastOrderId, 0.0, currentPrice-gain, false);
Order order3 = createExOrder("SELL", 1, "LMT", lastOrderId, currentPrice+loss, 0.0, true);
        
eClientSocket.placeOrder(this.orderId++, buyContract, order2);
eClientSocket.placeOrder(this.orderId++, buyContract, order3);

メソッドが以下のように設定されている場合：

protected Order createExOrder(String action, int quantity, String orderType, int parentId, double lmtPrice, double auxPrice, boolean transmit) {
        Order order = super.createOrder(action, quantity, orderType);
        order.m_parentId = parentId;
        order.m_lmtPrice = lmtPrice;
        order.m_auxPrice = auxPrice;
        order.m_transmit = transmit;
        return order;
}

protected Order createOrder(String action, int quantity, String orderType) {
        Order order = new Order();
        order.m_action = action;
        order.m_totalQuantity = quantity;
        order.m_orderType = orderType;
        // order.m_transmit = true;
        return order;
}

protected Contract createContract(String symbol, String securityType, String exchange, String currency) {
        return createContract(symbol, securityType, exchange, currency, null, null, 0.0);
}

protected Contract createContract(String symbol, String securityType, String exchange, String currency, String expiry, String right, double strike) {
        Contract contract = new Contract();
        contract.m_symbol = symbol;
        contract.m_secType = securityType;
        contract.m_exchange = exchange;
        contract.m_currency = currency;
        if (expiry != null) {
            contract.m_expiry = expiry;
        }
        if (strike != 0.0) {
            contract.m_strike = strike;
        }
        if (right != null) {
            contract.m_right = right;
        }
        return contract;
}

Rebecca

結果として、先物を購入し、2つのオープン注文（SELL LMT と SELL STP）が両方とも送信されたように見えました。

その後、STP注文が成立して実行されましたが、SELL LMT注文は自動的にキャンセルされませんでした。

何か間違っているのでしょうか？

助けていただけるとありがたいです。

レベッカ

[A1] Jiang Lingyu 2010年5月31日

LMT注文とSTP注文に同じグループ名を設定することができます。これによりOCO（One Cancels the Other）設定が行われます。

例としては次のようなものです：

order2.m_ocaGroup = "group1";
order3.m_ocaGroup = "group1";

役に立つといいのですが。

[レベッカ]

試してみましたが、効果がないように見えました。例を教えてもらえますか？

[A2] Richard King

ざっと見た感じ、最初のplaceOrderの呼び出しでorderIdが増加していることが問題だと思います。増加は現在の値がplaceOrderの引数として渡された後に発生するため、lastOrderIdがエントリー注文のIDより1多くなり、結果として子注文のparentIdが正しく設定されていません。

A1について、TWSはparentIdが設定された注文に対して自動的にOCAグループを割り当てます。よって、A1の例で指定したものは無視されます。（少なくとも以前はそうでした。最近のバージョンでテストしたわけではありませんが）

[レベッカ]

ありがとう、それで問題が解決しました。

APIの使い方を誤ったのかと調べていましたが、通常のプログラミングバグでした 🙂

別の問題もありました。

最後の注文であるLMTでtransmitをtrueに設定しても、STPが送信されませんでした。ブラケット注文では、最後の注文のtransmitがすべてに適用されるということは理解しています。

すべての注文に対してtransmitフラグをtrueに設定したら、うまくいきました。

[メモ1] scourt2000より

また、市場注文の場合、設定した2つのブランケット注文の価格から1ティックか2ティックずれることがあります。これはエントリー時に同時に送信されるためであり、とくに成行注文の場合です。指値を使用する場合、最悪の場合でも、変動の激しい市場では1ティックだけ良いエントリーが得られ、当初より狭いストップアウトになります。

私の場合、まず成行または指値注文を送信し、IBが報告するエントリー価格を確認してからブラケット注文を送信しています。

[メモ2]

ブラケットには、対応するOCA文字列が必要です。別のブランケットには異なる文字列が必要です。

[メモ3]

もう一度説明します。私のソフトウェアでは、ロングブラケット注文とショートブラケット注文を配置できます。たとえば、エントリー注文が両方とも成行の場合、どちらも配置され次第実行されます。したがって、IBアカウントの観点では、純ポジションはフラット（ノーポジション）になります。しかし、システムには2つのストップロス注文と2つのターゲット注文（2つの異なるOCAグループとして）が残り、該当する価格に達したときにそれぞれ反対側をキャンセルしながら実行されます。

これを試してうまくいかなかった場合、単に何か間違った操作をしただけです。うまくいかないと言われても、実際に機能する方法です！

リチャード

[A3] Ed（他のスレッドより）

最後の注文を除くすべての注文でTransmitをFalseに設定する必要があります。

親注文を最初に送信し、その後に子注文を送信します。最後の子注文でTransmitをTrueに設定すると、全体が送信されます。

— Edからの良いメモ —

何を達成しようとしているのかはわかりませんが、少なくとも次の2つのアイデアがあります：

  1. 標準の親子設定を使用し、親注文が実行された後に子注文の価格を調整する

  2. エントリー用の通常の注文を送信し、その後にエントリーが実行された後にリミット/ストップ注文用のOCAグループを使用する

[Q] ブラケット注文について：3つ以上の子注文は可能？孫注文は？エントリーとしてストップ注文を使用できるか？

私は初心者で、皆さんからアドバイスをいただけると嬉しいです。

APIリファレンスガイドで調べたところ、ブラケット注文には3つの注文（1つの親と2つの子注文）があることが分かりました。

エントリー注文（親）：成行または指値、transmit = false
ストップ注文（子1）：逆指値、transmit = false
リミット注文（子2）：指値、transmit = true

ストップ注文をエントリーとして使用することは可能ですか？

子注文を1つだけにすることは可能ですか？3番目の子注文やそれ以上の追加は可能ですか？

子1を親とする孫注文を追加することは可能ですか？

ありがとうございます。

[A1] Richard L King より

私のアドバイスとしては、こういった質問への答えを自分で探してみることです。

小さなテストアプリを作るのに必要なコードは多くありませんし、それを作成するのは良い練習になります。基本的なフレームワーク（接続、エラーログなど）を作っておけば、それをコピーして新しいテストアプリを数秒で試せるようになります。

または、IBが提供するサンプルアプリを使用して試してみることもできます。これで使い方を学ぶことを強くお勧めします。時間を節約し、正確な答えを得ることができるからです。ここに投稿すると、回答が遅れる可能性があり、提供された回答が正しい保証もありません。

それでも回答すると：

  • ストップ注文をエントリーとして使用できます。

  • 私の知る限り、子注文は任意の数を設定できます。最後に配置する注文以外のtransmitをfalseに設定してください。また、最初のブラケット注文（または単一注文）が配置された後に、子注文を追加することも可能です。

  • 子注文を親として使えるかはわかりませんが、できない理由はないと思います。

ただし、これを盲信せずに自分で試してみてください！

リチャード

[A2] orionn2 より

4つの質問全てに対する回答は「はい」です。ただし、問題を避けるために、ストップロスは最後にtransmit = trueで配置し、親とリミットをtransmit = falseで先に配置してください（これは、何らかのエラーでストップロス注文が配置・送信されなかった場合に備え、ストップロスなしでポジションを持つのを避けるためです。ストップロスが配置できない場合、他の注文も取引所に送信されません）。

[Q] ブラケット注文：エッジケース

ブラケット注文を使用している方（コード例についての質問を見かけました）、以下の質問に答えていただけますか？

  1. 親注文がリミット注文で一部だけ成立（部分約定）した場合、2つの子注文は有効になりますか？それとも親が完全に成立した場合のみですか？

  2. 2つの子注文はOCA（One Cancels the Other）として機能しますか？部分的な成立について、1つの子注文が部分的に成立した場合、IBはもう一方の数量を調整しますか？

  3. 親がキャンセルされた場合、IBは子を自動的にキャンセルしますか？親が部分的に成立してからキャンセルされた場合はどうなりますか？

私はリミットエントリー注文を使用しているため、部分的な成立が頻繁に発生しますが、ブラケット注文で全てのエッジケースに対応できるか疑問です。そうでなければ、自分で処理したいと思います。

Jian

[A] Christian Gross より

しばらくブラケットを使っていませんが、以下のように思います。間違いがあれば誰でも訂正してください。

  1. はい

  2. 状況によりますが、デフォルトでははい。ただし、OCAグループのプリセットを確認してください（株式を仮定しています）

  3. 子はキャンセルされます。キャンセル操作を行った場合です。ただし、例外があります。部分的に成立し、注文が成立した直後にキャンセルした場合、そのキャンセルは無視され、存在しない注文のエラーが返されます。

[Q] ブラケット注文：API経由での注文送信方法（まとめ）

2015年4月28日追加

[A] Richard L King より

APIを使用したブラケット注文の作成方法については、これまでに何度も議論されており、確かに可能です（しかも非常に簡単です）。

以下の手順で行います：

  1. エントリー注文を作成し、transmitをfalseに設定して注文を配置します。

  2. ストップロス注文を作成し、親IDをエントリー注文のIDに設定してtransmitをfalseに保持し、注文を配置します。

  3. リミット注文を作成し、親IDをエントリー注文のIDに設定してtransmitをtrueにして注文を配置します。

transmitの設定により、すべての注文が設定されるまでTWSからIBサーバーに送信されません。送信しないと、エントリー注文が成立する前にストップロスとリミット注文が送信される可能性があります。

ストップロス注文とリミット注文の両方が必要ではありません。両方がある場合、どちらの順番で作成しても問題ありません（ただし、エントリー注文は最初に作成して配置する必要があります）。

ストップロス注文とリミット注文にOCAグループを設定する必要はありません。TWSが自動的に処理し、設定を無視するためです。

ブラケットのメンバーは、他の注文と同様に個別に修正できます。

リチャード

[Q] ブラケット注文の価格変更方法は？

[A] Josh より

2017年5月10日追加

ブラケット注文の場合も通常とやり方は非常に似ています。変更したいブラケット内の注文IDに対して個別にplaceOrderを呼び出します。

株式注文

[Q] すべてのIDが0の時、これらの手動取引がopenOrdersに表示される際にどのように参照を保持できますか？

[A] by Josh (#40989)

2018年11月1日追加

Order Referenceフィールドを使用して注文に手動でラベルを付けることができます。例えば、TWS Classic Viewでタブを右クリックして設定を選択すると、そのタブで作成されたすべての注文にデフォルトで適用されるOrder Referenceフィールドを入力できます。この文字列はAPI内でOrder.OrderRefとしてアクセス可能です。

[Q] 「Order Inactive」とは実際にどういう意味ですか？

[A]

ES先物の注文を試みた際、openOrderとorderStatusから「Inactive」の通知を受け取り、エラーメッセージが表示され、注文が拒否されたとされました。しかし、「Cancelled」のステータスは表示されません。 拒否の理由は問題ではないですが、openOrderとorderStatusのみでは、注文が完全に拒否されたのか、何らかの理由で抑制されており、後で承認される可能性があるのかを判断できないというのは本当ですか？ PS: この質問をIBフォーラムにも投稿しましたが、回答がありません。

はい、「Order Rejected（注文却下）」というステータスは存在せず、「Order Inactive（注文非アクティブ）」が実際に何を意味するのかも正確にはわかりません。

ES Sep 2010の注文を十分なマージンなしで発行した際に、以下の時系列順で受信しました：

  • openOrder(...)でステータスInactive

  • orderStatus(...)でステータスInactive

  • error code 201(...)で注文却下

  • openOrder(...)でステータスInactive

  • orderStatus(...)でステータスInactive

注文はTWSにはハングせず、まったく表示されません。（なぜopenOrderとorderStatusが2回あるのでしょうか？）

これはF&Aシミュレーション・サブアカウントでテストしました。機関投資家用マルチアカウントはシミュレーションアカウントとして利用できないためです。

当面は、必須情報が不足している注文をプログラムが発行しないことを前提に、Inactiveステータスを返す注文は却下され実質的に存在しないものとして扱うことにします。

KurtとRichardの意見ありがとうございます。

Alexander

返信 Kurt Bigler 参考までに、私のコードを確認すると、以前始めた情報を補完できそうです。 2010年8月16日

Alexander 2010年8月22日 却下の理由は購買力不足でした。そして、同じorderIdで注文を再送信することは決してありません。常に新しいorderIdを使用しています。TWS上の赤い注文はいずれ消えるでしょう。

Richardが指摘したように、inactive状態の注文が後で自動的にアクティブになることはないということがわかって良かったので、却下として扱うことができます。

もし誰かがerror 201を伴わないinactiveステータスの注文を経験したことがあれば、教えていただきたいです。

Alexander

Kurt Bigler 2010年8月22日 私はerror 201なしでinactiveを経験しています。私の場合、「Cancelled」ではなく「Inactive」となりました。

201は具体的に「rejected（却下）」を意味します。「rejected」とは言っていない何らかのエラーや警告によってinactiveのままになった注文がありました（ただし、IBはこの種の動作を変更し続けていると思います）。transmit falseで送信したすべての注文は、以前は「Inactive」の注文ステータスメッセージを生成していたはずです。しかし、記憶が正しければ、そのような注文は現在では注文ステータスメッセージをまったく生成しないので、APIアプリのみが注文を認識しているこの状況のために、独自の注文ステータスコード「Local」を設定するようにアプリを再コーディングしました。

要するに、以前は「Inactive」はTWSで「Gray（グレー）」と表示される注文に対応していました。これには送信されなかった注文と（事実上）却下された注文が含まれていました。以前はこれらすべての場合（未送信を含む）で注文ステータスメッセージを受け取っていましたが、現在は一部のケースで受け取らなくなりました。これは少し厄介です。

なぜなら、TWSが未送信の注文を受信したというフィードバックが得られないからです。そのため、transmit=trueで再送信する場合、以前のように、すべての注文フィールドが事前にチェックされ、送信が成功するという感覚が事前に得られません。

この動作は最悪ですが、IBが生成するガラクタにうんざりしているので、以前のように激怒する代わりに、さらに諦めの境地に沈むだけです。

-Kurt

Alexander 2010年9月2日 IBのAPIサポートからの返信：

Alexander様、

ご指摘の通りです。注文が却下された場合、OrderStatusイベントは「Inactive」ステータスを表示し、Errorイベントは詳細な説明と共に却下メッセージを配信します。注文が正常に発注されたかどうかを判断するために、OrderStatusとErrorの両方のイベントを監視することを強くお勧めします。

敬具、 IB APIサポート

[Q] 指値注文が一定時間経過しても約定されない場合に、指値を成行注文にする方法はありますか？

一定時間後に未約定の指値注文をキャンセルして成行注文に変更する方法について質問があります。

これは1回のAPI呼び出しで可能でしょうか？それともコードで注文をキャンセルしてから成行注文として再送する必要があるのでしょうか？

[A1] 最初の指値注文で、以下の値を設定してください：

m_goodTillDate;  // 形式: 20060505 08:00:00 {タイムゾーン}

その後、TWSからキャンセルのコールバックを受け取ったら、新しい成行注文を出してください。

[A2] 時間制限が切れた後に、注文タイプをLMT（指値）からMKT（成行）に変更することもできるかもしれません。

[Q] order.m_account == null ?!

openOrderメソッドで注文を受け取る際に、order.m_accountフィールドがnullになる状況を経験した方はいますか？この問題によってサブアカウントごとの注文のフィルタリングができません。ご意見をお聞かせください。

[A]
C++では、このフィールドはデフォルトのOPEN_ORDER処理（バージョン9.67用）でデコードされているので、その点については問題ないはずです。

しかし、様々な理由で、独自の注文情報を保存/アーカイブすることが良いアイデアだと判断しました。あなたのケースでは、これによりorderIdによって入ってくるopenOrderメッセージを保存された注文情報と関連付けて、元のアカウントに結び付けることができます。

あなたのケースでそれが必要になるかどうかは分かりません。placeOrderをfalseにしてTWSに送信された注文はreqOpenOrderなどで報告されないため、APIアプリが独自の注文状態を保存せずに終了した場合に起動時に復元しないと、それらの注文への関連付けができなくなってしまうため上記の方法に行きつきました。

[A2]
私は2つの個人口座を持っていますが、アプリケーションが処理する各OpenOrderメッセージの'AccountID'フィールドが NULL や空になることは一度もありません。

[A3]
これは（当時の）最新のTWSバージョンのアドバイザーアカウント（個人口座ではない）で、自動的に注文を3つのサブアカウントに分割/配分される際に発生した事象です。

[Q] m_shortSaleSlotのフィールドについて？

[A] C++のコメントには以下のように書かれています：

"株式を保有している場合は1、貸株を利用する場合は2。Action="SSHORT"の場合のみ"

そして（文書で確認できませんが）SSHORTは機関投資家専用だと思います。それは理にかなっています。

これは、適用されない場合にフィールドをどのように設定すべきかを具体的に述べていません。TWS APIのこのような場合、フィールドのデフォルト初期化で使用する値を決定させます。shortSaleSlotはC++のコンストラクタによって0にデフォルト設定されています。そのため、適用されない場合はフィールドを設定せず、デフォルトが正しくなるはずです。

オプション注文

[Q] IBが使用しているオプションモデルのIV（インプライド・ボラティリティ）とは何ですか？

[A] 2021年1月25日追加

TWS APIのドキュメントを参照すると、低レベルの詳細を理解するのに常に役立ちます😉 https://interactivebrokers.github.io/tws-api/tick_types.html

基本的に、TWSには4種類のオプションのギリシャ数値+IVがあります：

  • 買い気配価格（Ask Price）で計算されたギリシャ数値（ティックID 10）

  • 売り気配価格（Bid Price）で計算されたギリシャ数値（ティックID 11）

  • 最終価格（Last Price）で計算されたギリシャ数値（ティックID 12）

  • モデル価格で計算されたギリシャ数値（ティックID 13）

モデルはデフォルトで仲値（??これについては100%確実ではありません）、ヒストリカル・ボラティリティ、その他の原資産情報とブラック・ショールズを使用します。独自のオプション価格モデルを作成するために変更することも可能です（https://www.interactivebrokers.com/en/index.php?f=14278 / https://www.interactivebrokers.com/php/whiteLabel/Interactive_Analytics/modelEditor/intro.htm）。

ただし、私はまだそれを行っていないので、TWS内で独自の価格算出式をモデル化したい場合のサポートはできません😉


[Q] 市場終了後にオプションの売り気配/買い気配価格とグリークスの値を取得するにはどうすればよいですか？

[A] Josh による回答（2021年12月18日追加）

市場が閉まった後に最後に利用可能なデータを受信するには、'frozen'（凍結）データに切り替える必要があります。

https://interactivebrokers.github.io/tws-api/market_data_type.html

reqMarketDataType(2)を使用してください。

[Q] オプションの日次出来高を取得するにはどうすればよいですか？

オプションには終値データがないので、私が考えついた最善の方法は、大きな時間枠（8時間など）のバーを取得し、それを使用して出来高があったかどうかを確認することでした。

[A] Josh による回答（2018年7月10日追加） その方法で問題ありません。他に方法はありません。

[Q] 株式貸借の利用可能性をモニターするには？

[A] Jack Jost による回答（2017年11月27日追加）

（https://ibkr.info/article/2024 からの引用）

株式貸借の可用性の監視

概要：

IBは、空売りを行う口座保有者が在庫レベルや借り入れコスト/リベートを監視するためのさまざまな方法を提供しています。利用可能な詳細レベル、カバーされる時間枠、および情報へのアクセス方法は各方法によって異なり、各方法の簡単な概要は以下の通りです。

公開ウェブサイト

関心のある関係者は、ユーザー名やパスワードなしで公開ウェブサイトから株式貸借データを照会できます。まず、こちらをクリックして、株式が上場されている国を選択してください。利用可能な銘柄数が1ページに合理的に表示できる範囲を超える場合、結果はシンボルごとにグループ化され、ハイパーリンクによりさらに詳細を確認できます。指定されたシンボルのクイック検索ボックスも提供されています。照会結果には、製品の説明、通貨、ならびに「可用性確認」というリンクが表示され、借りることができる株式の数量が表示されます。

[Q] 異常なシータ

TWS APIから非常に大きなシータが返されるのを見たことがある人はいますか？テスラの195コールオプションでシータが1.7976931348623157E+308と表示されました。これはTWSサーバー側のエラーに違いないですよね？なお、他のグリークスの値はすべて正常です。

[A] Kurtによる回答
それは未定義またはデータなしを意味する最大double値ではないでしょうか？とても見覚えのある数値で、このフォーラムの質問でも驚くほど頻繁に出てきます。Wikipediaによると：

7fef ffff ffff ffff16   = (1 + (1 – 2-52)) × 21023 
                    ≈ 1.7976931348623157 × 10308 (最大Double値)

IBは、データなしの場合に使用される値に関して一貫性がありません。-1が使われたり、-.99が使われたり、0が使われたり、「最大」値が使われたりします。

現在、私のアプリケーションでは、本日満期を迎える多くのTSLAコールオプションで未定義値が表示されています。私のコードは特殊な値を表示可能な形に変換します。他の満期日をいくつか確認しましたが、それらは正常な値を示しています。

IBの戦略では、計算が安定していない場合にグリークス値を未定義とします。シータの場合、満期日にこれが起こるのは驚くことではありません。

-Kurt — 追加情報 — Ding,

[以下はC++に関するコメントです]

問題の値はDBL_MAXです。これはコードで参照できる方法の1つで、IBもソケットインターフェース層のコード（例：EClientSocketBase::EncodeFieldMax）でこの方法で参照していますが、場合によっては

#define UNSET_DOUBLE DBL_MAX

も使用しています（例：EClientSocketBase::DecodeFieldMax、これは一貫性の欠如を示しています）。

APIがグリークス値についてDBL_MAXを返すのは全く異常ではありません。この値は常に発生し、APIからギリシャ数値を使用する場合はDBL_MAXをチェックする必要があります。私のコードを確認したところ、実際にDBL_MAXをチェックし、TWS APIの通常の方法で（値が利用できないことを意味する）解釈しています。tickOptionComputationコールバックの以下の引数についてDBL_MAXをチェックしています。

impliedVol（インプライド・ボラティリティ）
delta（デルタ）
gamma（ガンマ）
vega（ベガ）
theta（シータ）
optPrice（オプション価格）

TWSがまだ値を表示している場合でも、APIでこれらの値が発生する可能性があります。TWS は何かを表示することについてそれほど厳密ではない（有効か無効かにかかわらず）のに対し、IBは自動取引に使用される可能性がある場合に不安定な値をAPIに送信するリスクを避けたいのかもしれません。

思い返してみると、私の記憶では、グリークス値は常にオプショントレーダーに表示されます。間違っているかもしれませんが、列がまばらに空白になっているのを見たことがないように思います。一方で、私のAPIアプリでは、値が提供される他のグリークス値と混在して、空白のグリークス値の列を見るのが普通です（DBL_MAXの発生に基づく）。

私のコードは手数料や様々な注文フィールドについてもUNSET_DOUBLE（DBL_MAXと同じ値）をチェックしていることがわかります。この値（または整数の場合はUNSET_INTEGER = INT_MAX）は多くの場所で使用されています。

この値がほぼすべてのティック（気配値）フィールドで使用される可能性があるという印象を持っていましたが、現時点でそれを示す証拠は見つかりません。TICK_PRICE/tickPriceの場合、DECODE_FIELD_MAXではなくDECODE_FIELDが使用されます。DECODE_FIELD_MAXはOPEN_ORDERでのみ使用されているようです。DECODE_FIELD_MAXは、実際にはIBがソケット上でヌル文字列を送信し、それがDBL_MAXを意味するようにするためにのみ使用されます。DBL_MAXは常にソケット上で直接送信できます。グリークス値の場合、DECODE_FIELD_MAXではなくDECODE_FIELDが使用されているため、明らかにそのように行われています。

しかし、上記で述べた以外に、私のコードでDBL_MAXやUNSET_DOUBLEを特別扱いしている形跡は見当たりません。

-Kurt

[Q] APIクライアントは、TWSで手動で行われたオプションの権利行使をどのように検知すべきですか？

こんにちは、

APIクライアントは、TWSで手動で行われたオプションの権利行使をどのように検知すべきでしょうか？

APIクライアントはオープンオーダーイベントを受信しますが、困ったことに、そのオーダーイベントは常に論理的な「売り」ではなく「買い」となっています（オプションの権利行使はロングポジションでのみ可能です。私の考えでは、ロングポジションを閉じることは、買いよりも売りとして特徴付けた方が適切です）：

5;34;-279;283326534;DIA;OPT;20171020;231;C;100;SMART;USD;
DIA171020C00231000;DIA;BUY;100;LMT;0.0;0.0;DAY;;
U###;C;0;;0;1689659455;0;0;0;;1689659455.0/U###/100;
;;;;;;;;;0;;-1;0;;;;;;;0;0;0;;3;0;0;;0;0;;0;None;;0;;;;?;
0;0;;0;0;;;;;;0;0;0;;;;;0;;IB;0;0;;0;0;Inactive;
1.7976931348623157E308;1.7976931348623157E308;1.7976931348623157E308
;;;;;;0;0;0;None;1.7976931348623157E308;1.7976931348623157E308;
1.7976931348623157E308;1.7976931348623157E308;1.7976931348623157E308;
1.7976931348623157E308;0;;;;1.7976931348623157E308

オーダーイベントが売りであれば、TWSから受信する他のオーダーイベントと同じように簡単に処理できるはずです。

あるいは、オーダーイベントが何らかの形で権利行使として識別されれば、買いを売りに変換することができます。

しかし現状では、オーダーイベントが権利行使であることを示すものが何も見当たらず、受信するすべてのオーダーイベントで買いを売りに変換するわけにもいきません...

ありがとうございます！

Jimmy

[A] Joshによる回答：

直感的ではないことは同意します。しかし、オプションの権利行使指示は、orderStatusに対して常に注文サイド = "BUY"として表示されます。また、注文ステータスの動作も異なり、reqOpenOrderやreqAllOpenOrderを呼び出した後にorderStatusは返されず、警告メッセージのみが返されます。

権利行使リクエストは指値価格が'0'であることで識別できます。これはコンボ契約を含まない他の注文では不可能な値だからです。

Josh

[Q] オプションの利用可能な行使価格を見つける方法は?

[A] 次の質問と同じ回答になります:

[Q] 有効なオプションをすべて取得する方法(オプションチェーンをスクレイピングする)は?

[A] (Pythonを使用) Juergen juxeiier@gmail.com による 2021年3月20日追加 こんにちは、 オプションチェーンを(うまくいけば)簡単にスクレイピングできる小さなライブラリを作成しました。 このトピックはこちらで議論されています: https://groups.io/g/twsapi/message/46566 https://groups.io/g/twsapi/message/42241 https://groups.io/g/twsapi/topic/81356218 ソースコードとインストール方法はこちらにあります: https://github.com/juxeii/ibtools 使用方法は以下のように簡単です:

chain = ibt.getOptionContractsUpUntilDays(aapl, 60)

または

aapl=Stock(symbol='AAPL', exchange='SMART/AMEX')
chains = ibt.getOptionContractsUpUntilDays(aapl, 60)

私のサイトでは動作しますが、非常に新しいので、おそらくいくつかの欠点があります🙂 誰かがテストしてくれると嬉しいです。 よろしくお願いします、

Juergen

[A2] (Rubyを使用) Hartmut Bischoffによる 2021年3月20日追加 こんにちは、 ib-ruby (https://github.com/ib-ruby) には、atm、itm、otmのオプションチェーンを扱う機能があります。 ドキュメント:
https://ib-ruby.github.io/ib-doc/atm_options.html 実装:
https://github.com/ib-ruby/ib-extensions/blob/master/lib/ib/option-chain.rb あなたのプログラムを完成させるために、一度見てみる価値があるかもしれません。

[Q] オプションチェーン全体を取得する方法は?

[A] Kurt (このスレッドから)による

行使価格だけを取得する方法はありません。取得可能な全満期日にわたるすべての行使価格を取得するには、オプションチェーン全体をポーリングし、必要なものをメモして残りを捨てる必要があります。

これを行うには、あいまいなContract指定でreqContractDetailsを使用します。つまり、行使価格、満期日、権利のうち、ワイルドカードにしたいフィールドを単に設定しないだけです。そうすると、1回のリクエストから一連のcontractDetailsレスポンスが返ってきます。これはリクエストIDで追跡できます。そのリクエストIDに対してcontractDetailsEndメッセージが到着したら、チェーン全体を受信したことになります。

この方法で、満期日と権利("C"または"P")を指定して、その満期日と権利に対するすべての行使価格を取得することもできます。好きな組み合わせで可能です。しかし、満期日の独立したリストや行使価格の独立したリストはなく、組み合わせだけです。権利を未設定("")にすると、コールとプットの両方が取得できます。

最後にテストした時点では、日付を部分的にワイルドカード化することもできます。例えば、完全な日付コードを指定する代わりに、日付の先頭部分だけを指定したり、年だけ、または年と月だけ(例: "201201")を指定したりできます。これは週次満期が利用可能になった今では、あまり便利ではありません(私に言わせれば面倒です)。満期日が多すぎ、行使価格が多すぎます。 (そして誰か別の人がアービトラージで儲けることになります。) ああ、良き昔の日々。

-Kurt

[A2] このスレッドからのKurtの引用 試してみてください

conId=0 symbol="AAPL" secType="OPT"
expiry="20110415" strike=345 right="C" multiplier=""
exchange="SMART" primaryExchange="" currency="USD" localSymbol=""
includeExpired=0

または、

conId=0 symbol="AAPL" secType="OPT"
expiry="" strike=0 right="" multiplier=""
exchange="SMART" primaryExchange="" currency="USD"
localSymbol="AAPL 110416C00345000"
includeExpired=0

満期日のOSIシンボルと日付の2つの異なるバリアントに注意してください。

先物に関しては、ここの誰かが、localSymbolで契約を完全に指定すればシンボルを省略できると言っていましたが、OSIオプションでは試したことがありません。

ついでに、他にも遭遇するかもしれないことをいくつか教えましょう：

  • オプションチェーンは、reqContractDetailsを使用して要求します。その際、一部のフィールド（例：行使価格、権利、および/または満期日）を省略してワイルドカードとして機能させます。満期日や行使価格のリストだけを要求する方法はなく、一致する契約の完全なリストのみを取得できます。

  • 場合によっては、reqContractDetailsを通じてconIdを取得し、そのconIdを他のフィールドの代わりに使用してreqMarketDataやreqHistoricalData、そして特に重要なplaceOrderの契約を指定すると、より信頼性の高い結果が得られる可能性があります（特定の種類のエラーを回避できます）。これは過去ほど当てはまらないかもしれませんが、以前はplaceOrderが他のリクエストよりも厳格で、他のリクエストが受け入れる契約を拒否することがありました。おそらく、reqContractDetailsは他のリクエストよりも柔軟性があるのは、ワイルドカードの可能性があるためで、考えてみると（推測ですが）、一致するものが1つしかない場合でも適用される可能性があります。

-Kurt

[A3] dthayerによる

オプションデータを取得するために使用するコードのカット＆ペーストです。strike=0.0、expiry=0.0、right=""に設定すると、プットとコールの両方の全チェーンを取得できます。

Contract *C = new Contract();

C->symbol        = "KMB";
C->currency      = "USD";
C->secType       = "OPT";
C->expiry        = "20130621";    
C->strike        = 95.0;           // 0.0に定義するとオプションチェーン全体を取得
C->right         = "P";            // プットとコールの両方を取得する場合は空文字列（2つのダブルクォート）
C->exchange      = "SMART";
C->multiplier    = "";
C->primaryExchange = "";
C->localSymbol   = "";
C->includeExpired = 0;

m_pClient1->reqMktData(msgID, C, "233", false);  // false - ストリームを開始し、ティックタイプを取得
                                                 // TWS::contractDetailsでTWSからの応答を待つ

//m_pClient1->reqMktData(msgID, C, "", true);    // true - スナップショットを取得し、ティックタイプを指定しない

[A4] rholowczakによる

以下は、シンプルなJavaプログラムとIB Java APIを使用して、原資産株式のすべてのオプション（オプションチェーン）の契約詳細を取得する方法の簡単なチュートリアルです：コンソールアプリケーションでのInteractive Brokers Java APIのプログラミング - 契約詳細

PythonとRubyを使用した実装例については、以下を参照してください：[質問] すべての有効なオプションを取得する方法（オプションチェーンのスクレイピング）は？

[Q] なぜオプションチェーンデータが遅延する（時には1分まで）のですか？

[A] IBサポートによる：

2016年4月18日追加

残念ながら、これは設計上、サーバーに過度のストレスをかけないようにするためのペーシング制限です。オプションチェーンの契約詳細を要求する際、contractDetails()コールバックメソッドは追加のリクエストごとにバッファリングされます。以下はcontractDetailsのバッファリングの内訳例です。

例：

満期日 = 空白またはNULLの場合

Symbol = "IBKR";
secType = "OPT";
Expiry = "";
Exchange = "SMART";
Currency = "USD";

上記の例では、満期日がnullまたは空の文字列に割り当てられている場合、遅延は1分です。

満期日 = YYYY（例：2016）の場合

Symbol = "IBKR";
secType = "OPT";
Expiry = "2016";
Exchange = "SMART";
Currency = "USD";

上記の例では、満期日が年のみに割り当てられている場合、遅延は1分です。

満期日 = YYYYMM（例：201603）の場合

Symbol = "IBKR";
secType = "OPT";
Expiry = "201603";
Exchange = "SMART";
Currency = "USD";

上記の例では、満期日が年と月の形式（YYYYMM）に割り当てられている場合、遅延は5秒です。

満期日 = YYYYMMDD（例：20160318）の場合

Symbol = "IBKR";
secType = "OPT";
Expiry = "20160318";
Strike = "31";
Right = "C";
Multiplier = "100";
TradingClass = "IBKR";
Exchange = "SMART";
Currency = "USD";

上記の例では、満期日が年、月、日（YYYYMMDD）に割り当てられ、さらに行使価格、権利、乗数またはTradingClassが含まれている場合、遅延はありません。

ただし、これはフロントマンス（期近限月）のオプション契約に対してのみ機能し、最初の8つのリクエストに対してのみ有効です。フロントマンス以外を要求したり、8つ以上のリクエストを行う場合は、1分の遅延にデフォルトで戻ります。

— jb201448からの追加情報 —

ベータバージョンには新しい関数reqSecDefOptParams()があり、これによりオプションチェーンをより速く取得できるはずです。

-Josh

[Q] 空売りの際に借りた株式の配当金を支払う必要がありますか？

[A] Frank Bellによる

配当金の義務は、権利落ち日の前日の市場終了時に保有している場合にのみ発生します。これはスピンオフやその他のすべての企業イベントにも当てはまります。

[Q] どの株式が空売り可能で、どの株式が空売り不可能ですか？

[A] Jasonによる

IBで空売り可能な株式のリスト（すべての国）は、こちらで確認できます：
http://www.interactivebrokers.com/en/p.php?f=shortableStocks

空売り可能な米国株式の完全なリストは、こちらで確認できます：
http://www.interactivebrokers.com/en/trading/ViewShortableStocks.php?cntry=usa&tag=United States&ib_entity=llc&ln=

最後に、規制上の理由で空売り不可能な米国株式のリストは、こちらで確認できます：
http://www.interactivebrokers.com/en/trading/ViewShortableStocks.php?cntry=regSHO&tag=Reg SHO&ib_entity=llc&ln=
（ただし、このリストの一部の株式はIBを通じて空売り可能な場合があります）

[Q] 借りられない場合は？

[A] Frank Bellによる

借りられない注文のサイズを繰り返し減らすことができます。注文が成功するか、最小注文サイズに達するまで続けられます。また、オープンの空売り注文は、借りられなくなった時点で、提出済みから事前提出に変更される可能性があることに注意してください。

[Q] オプションの価格ステップを決定する方法は？

こんにちは、

一部のオプションは価格に隙間があります。例えば、価格ステップが5セントで、$1.02でオプションを購入する注文を出すと、注文は拒否されます。有効な価格は$1.00または$1.05になるからです。

プログラムで有効な価格を決定する方法はありますか？コードや公式（プログラミング言語は問いません）

よろしくお願いします

– JW

[A] Kurtによる

ContractDetailsクラスのminTickフィールドについて読んでください。

-Kurt

[Q] placeOrder() リクエストに対してセキュリティ定義が見つかりません

[A] [Q] エラーコード(200) リクエストに対してセキュリティ定義が見つかりませんをご覧ください。

[Q] イベントが時々重複して表示されます！

[A] IBのドキュメントより：

orderStatus() は重複メッセージを返す可能性があります。適切にフィルタリングしてください。

注文ステータスの重複を削除するには、残りの数量が変更されたメッセージのみを処理します。

[A2] Kurtによるコメント

この場合、重複するイベントに問題はないと思います。帯域幅の増加が気になる場合、それは注文ステータスのモデルを使用していない兆候かもしれません。モデルを最新のステータスで更新し、すべてのステータス変更をシステムが要求するように処理することが有益です。変更を検出するのは簡単で、重複ステータスが問題を引き起こす場合、それを解決するアルゴリズムの変更は容易です。これは良いプラクティスです。

[A3]

また、重複して送信されるのは注文ステータスイベントのみで、実行イベントは重複しない点も興味深いです。

[Q] 付随注文

[A]
エントリー注文には.transmit=0を、付随注文には.transmit=1を設定してください。

両方に.transmit=1を設定すると、TWSが付随注文を認識する前にエントリー注文が送信され、付随注文がTWSに到着する前に実行される可能性があり、エラーが発生します。

先物注文

[Q] 先物にSMARTを使用できますか？

[A] rwk2095

SMARTルーティングは先物には適用されません。取引所を指定する必要があり、追加手数料はかかりません。

[Q] 特定の先物のオプションを取得するために契約の詳細をリクエストする方法は？

紳士諸君、

特定の先物のContractとContractDetailsオブジェクトを取得し、reqContractDetailsメソッドを使用してその先物のオプションチェーンをリクエストしたいのですが、このリクエストのためにContractオブジェクトをどのように設定すれば良いかわかりません。Contractオブジェクトにはシンボルフィールド/メソッドしかないため、先物をそのフィールドにエンコードする必要があると思いますが、どうすればいいでしょうか？その先物のContract/ContractDetailsオブジェクトに直接シンボルを設定するためのフィールドはありますか？

Contract createContractForOptionsChainRequest(ContractDetails futureContractDetails) {
    Contract contract = new Contract();
    contract.secType("FOP");

    // Can I use any field from futureContractDetails to set the symbol?
    contract.symbol(???);
       
    // What else needs to be set?
    return contract;

}

満期/ストライク情報を取得する別の呼び出し（reqSecDefOptParams）があるのは知っていますが、それは使用したくありません。
 
reqContractDetails() がデータを返すのが遅い可能性があるのも理解していますが、それでも構いません。 

[A] Richard L Kingによる回答 (#49441)
 
2022年6月12日に追加
 
reqContractDetailsを使用してオプションチェーン全体を取得するには、以下のように設定したContractを使ってください：
 
Sectype="FOP" Symbol="ES" LastTradeDate="202206" Exchange="GLOBEX" Strike="0" Right="CALL"
 
これにより、2022年6月に満期を迎えるES先物オプションのコールコントラクトがすべて返されます。本日午前中には2300件返されました。標準コントラクトのみ取得するには、以下を追加してください：
 
TradingClass="ES"
 
これにより、リストが280件に絞り込まれます。
 
注：一部の先物（例：FTSE 100 Z先物）のオプションにはSectype="OPT"が必要です。理由は不明です。
 
Richard

[Q] 先物 – セキュリティ定義が見つかりませんエラー

[A] Richard L Kingによる回答
 
2021年12月18日に追加
 
ZFはGLOBEXではなく、ECBOT取引所です。
 
SMARTは先物には無効です。正しい取引所名をexchangeに使用し、primaryExchangeは設定しないでください。
 
3部構成のローカルシンボル形式では、最初の部分が4文字である必要があります（スペースで区切る）。

例：ZF{スペース}{スペース}{スペース}MAR{スペース}21
 
したがって、以下のようになります：

ZF   MAR 21 
F1U  MAR 21

同様にドイツDAX先物の場合：

FDAX MAR 21

[Q] ES先物のMOC注文を出せますか？

[A1] Rob Terpilowskiによる回答

私が知る限り、先物にはMOC注文は存在しません。

[A2] Frank Bellによる回答

ESはMOCに対応していません。16:14:58に有効になる市場注文を出しています。16:14:59でも良いと思いますが、IBに1秒の猶予を与えています。

Frank

[Q] 先物オプションデータをAPIで取得する方法

[A] souqmateより

IBの先物オプション(FOP)についての情報をまとめました。

  • 期限切れ契約のFOP履歴データは利用できません。

  • 週次（ウィークリー）オプションは常にヨーロピアン形式です。外国為替(AUD CAD CHF EUR JPY)、金利(ZT ZF ZN ZB)、指数(ES NQ SPX)で利用可能です。

  • FX（外国為替）：月次アメリカン/ヨーロピアンオプションあり：6A/XA 6B/XB 6C/XD 6E/XT 6J/XJ 6S/XS（実際にはXAはなし、IBのミス？）

  • NG：月次アメリカン/ヨーロピアンオプション用にON/LNEクラスあり（ただしLNEは流動性は4倍以上あるにもかかわらずフィードも履歴データもなし）

  • ES：週次(EW1 EW2 EW4)、月次(EW3の代わりにES)、月末(EW)オプションあり

  • NQ：週次(QN1 QN2 QN4)、月次(NQ)、月末(QNE)オプションあり

  • SPX(先物)：週次(EV1 EV2 EV4)、月次(SP)、月末(EV)オプションあり

  • ZC ZS（ZWは除く）：通常の月次(OZC OZS)と12月満期の原資産に対する月次(OCD OSD)、両方ともアメリカン形式

  • ユーロドルオプション(GE@Globex)：GE GE0 GE2 GE3 GE4 (Globex)、ED E0 E2 E3 E4 (CME)。週次なし、月次のみ。すべての原資産先物は同年(GE)または翌年(GE0 GE2 GE3 GE4)の（四半期）満期。すべてアメリカン形式。なぜGE0がGE1と呼ばれないのかは不明。
    GEの満期日は12月の場合、GE0...GE4と異なる場合がある（例：20131216と20131213）

  • minTickは満期によって異なる場合がある。例：20131011時点で、GEは201406で0.005、201403で0.0025

  • strikeIncrementは満期によって異なる場合がある。例：ZMは最初の満期は5刻み、2番目は10刻み

  • strikeIncrementはATM付近で小さく、離れると大きくなる場合がある：GFはATM付近で0.5、離れると1。EDはATM付近で0.125、離れると0.25

  • SI：実際のstrikeIncrementはATM付近で0.05だが、0.25のみが使用されているようだ

  • ZC ZL ZS ZW GF LE HE（ZMを除く）：ストライクに1/100の係数あり。APIのみで、TWSにはなし。IBは変更しない予定

  • NKD PA PL VIXについてはIBでFOPなし

  • localSymbolは標準化された構文がない。例：AUD@GLOBEXでは"6AZ3 P1075"、YM@ECBOTでは"C OYM SEP 14 11600"

reqMktDataまたはreqHistoricalDataのクエリで契約を指定する3つの方法：

—方法1—
symbol = GBP
secType = FOP
expiry = 20131108
strike = 1.55
right = P
tradingClass = 6B
exchange = GLOBEX

—方法2—
currency = USD
conId = 132707825
exchange = GLOBEX

—方法3—
localSymbol = 6BX3 P1550
secType = FOP
exchange = GLOBEX

これらはAPI 9.69以降（2013年7月以降）で動作します。tradingClassがContractDetailsからContractに移動されました。

API 9.68以前：最初の方法のみ動作。conIdの指定は冗長で、strike, expiry, rightは必須。そのためNG、外国為替、GEオプションについては、アメリカン/ヨーロピアン形式（外国為替、NG）やミッドカーブオプション（GE0 GE2 GE3 GE4）を区別するために、月次の履歴データを照会する際にlocalSymbolの指定が必要。conIdはここでも無用で、tradingClassとmarketNameも同様。

localSymbol構文：外国為替やGEでは末尾に常に4桁（"6SH4 P0950"や"GEV3 C0112"）、NGでは3桁か4桁（"ONX3 C900"か"ONX3 C1000"）。数字は外国為替とNGでは1000strike、JPYでは1e5strike。GEの場合、strike=99.875で"GEV3 C9987"、strike=101.125で"GEV3 C0112"となる。printf("%04d\n",100*strike %1e4)を使用。

ただしAPI 9.69以降は、区別にlocalSymbolの代わりにtradingClassやconIdを使用可能。

IBファイルの日次取引量はCMEボリュームの約半分。

残りはピットからと推測される。

[Q] フロントマンス（先物の期近月）を常に取得するにはどうすればよいですか？

includeExpired = Trueを使用して日付をチェックする方法もありますが、もっと堅牢な方法を探しています。第4週に満期を迎えると、"ERROR 1 200 No security definition has been found for the request"というメッセージが表示され、これを捕捉するコールバックもありません。

現在使用しているコード：

def subscribe(self):
    c = ibapi.contract.Contract()
    c.symbol = 'CL'
    c.secType = 'FUT'
    c.currency = 'USD'
    c.exchange = 'NYMEX'
    c.lastTradeDateOrContractMonth = "201706"
    reqId = self.getReqId()
    self._reqId2Contract[reqId] = c
    self.reqContractDetails(reqId, c)

includeExpired=Trueを使用して、満期切れでない契約にヒットするまで月をループする方法を採用しました。

先物満期のリスト全体を取得する方法があったと思いましたが、それはオプションチェーン用だったかもしれません。

[A1] souqmateより（2017年5月15日追加）

reqContractDetails()を以下のパラメータで実行すると：

symbol="CL" secType="FUT" exchange="NYMEX" currency="USD" includeExpired="1"

97件の契約が返され、そのうち24件が満期切れ（IBは2年分の先物データを保持し、その後破棄）。

フロントマンスが必要な場合は、includeExpiredを外し、返される73件の契約の中で最も若い契約を見つけます。ただし、これが最も取引の多い契約とは限りません。

独自のロール日カレンダーを持つことをお勧めします。

[A2] Nickより

取引目的（学術研究以外）の場合、ほとんどの取引活動は現在の契約が満期を迎える前に次の契約に移ります。これがsouqmateが言及しているロールオーバー日で、私も同意見です。

[A3] Markより

こんにちは、Jaredさん

IB APIは私も初心者なので、もっと良い方法があるかもしれませんが、私の解決策は満期日を自分で計算し、満期に応じて次の先物に切り替えることでした。

間違った先物をリクエストしても実害はないので、エラーを抑制してリクエストを分散できます。

よろしくお願いします。 Mark

[A4] J Gより

lastTradeDateOrContractMonthを指定しない場合、すべての先物契約の情報を受け取ります。

最終取引日だけでは十分な情報とならない場合があることに注意してください。現物引渡しのある特定の契約では、First Position Dateより前にポジションを解消する必要があります。詳細はこちらを参照 -> http://ibkb.interactivebrokers.com/node/992

[Q] 先物のロールオーバースケジュールについて

入手可能な先物の日次データでContinuous Contractを作成しようとしています。コードでは、オープンインタレストやボリュームではなく、特定の日付（例：第1通知日や満期前の特定日）に基づいて次の契約にロールオーバーする予定です。ただし、ロールオーバールールは先物契約によって異なるため、異なる先物のロールオーバースケジュールを入手できる場所を知りたいです。Googleやグループチャットのアーカイブで検索しましたが、答えを見つけることができませんでした。誰か教えていただけると幸いです。

よろしくお願いします。 Fatima

[A] souqmateより（以前のyahoo groupsで公開、現在はgroups.ioに移動）

以下は私のロールのカレンダールールです（人によって異なると思います）。

ロイターのRICを使用しているので、必要に応じてIBシンボルに変換してください。〇日にロールすると記載されている場合、新しい契約は〇日の朝から取引に使用されます。

満期日はreqContractDetailsの出力で見つけることができます。

がんばってください。
souqMate

STXE FDX FSMI FFI IFS IFX, only HMUZ months, roll on day of expiry:
FCE MFXI OMXS30 AEX, each month, roll on day of expiry:
ES NQ YM DM TFS RMF, only HMUZ, roll on Friday prior expiry (ie 5 days earlier – Thu for YM):
CL NG, all months, roll 1 day prior expiry day:
HO RB, all months, roll 8 days prior expiry day:
GC, only GJMQZ, roll on 3rd to last day prior expiry month (was 2nd prior IBprod):
SI HG, only HKNUZ, roll on 3rd to last day prior expiry month (was 2nd prior IBprod):
PL, only FJNV, roll on 3. to last day prior expiry month:
PA, only HMUZ, roll on 2. to last day of month prior expiry month:
FGBX FGBL FGBM FGBS NK JNI JNM YAP SXF, only HMUZ, roll 1 day prior expiry day:
ZB ZN ZF ZT, only HMUZ, roll on 2nd to last day prior expiry month
FSS FEI FES JEY ED BAX YBA, only HMUZ, roll on day after expiry and always use c2; eg H7 expires 20070321, so use M7 till 20070321 and use Z7 since 20070322.
FLG CGB, only HMUZ, roll on 3rd day prior end of month preceding expiry:
YTC YTT JGB, only HMUZ, roll on day of expiry:
IND, only GJMQVZ, roll on day of expiry:
CME agric (ZC ZW ZS ZL ZM LC FC LH): roll in last week of month prior expiry month;
ZC/C: HKNUZ, skip all U contracts (except U05 20050629-20050713);
ZW/W: HKNUZ, skip most U and many K contracts;
ZS/S: FHKNQUX, use only FHKNX except Q03 and U03 (instead of X03);
ZL/BO: FHKNQUVZ, use only FHKNZ (and Q till Q04);
ZM/SM: FHKNQUVZ, use only FHKNQZ (skip Q sometimes);
LC: GJMQVZ,
FC: FHJKQUVX, switch using RDTH volumes (discarded 3 U-contracts); can skip U contracts
LH: GJKMNQVZ; use only GJMNQVZ; switch using RDTH volumes; roll on 15.-25. of month prior expiry month.
ICE futures:
CC: HKNUZ; roll in 2. week of month prior expiry month;
KC: HKNUZ; roll in 3. week of month prior expiry month;
CT: HKNVZ but use only HKNZ; roll around 15. of month prior expiry month;
SB: HKNV, roll in 3. week of month prior expiry month;
LCO/CO: all 12m FGHJKMNQUVXZ; roll 2d prior expiry  (like CL which rolls 1d prior expiry);
CME forex: URO BP JY RP SF CD AD KRW MP DX, all HMUZ (but all 12m for KRW – on Kor Fut Exch); roll  1 day prior expiry; last trade at 9:16 a.m. (Chicago time) on the 2nd business day preceding the third Wednesday of the contract month (usually Monday);

[Q] 継続契約のオフセットの決定方法は？

[A]

もしかしたらこの議論で何か見落としているかもしれませんが、なぜ日々の価格が必要なのでしょうか？ロールオーバー日の前後で契約間の差額を決定し、その差額だけ前の契約の価格を調整すればいいのではないでしょうか？そして、次の契約が始まるときも同じプロセスで差額を計算し、すでに持っている値に加えるだけです。

例えば、（手元にデータがないので）：

  1. xxM9のロールオーバー日のRTHの最初の取引価格は27

  2. xxH9の同じ時刻の「最終」価格は24

  3. xxH9のすべての実際の価格に+3を適用します。

  4. xxH9のロールオーバー日のRTHの最初の取引価格は31

  5. xxZ8の同じ時刻の「最終」価格は32

  6. 計算すると、-1 + 3 = +2

  7. xxZ8のすべての実際の価格に+2を適用します。

  8. データを使い切るまで、これを無限に繰り返します。

ロールオーバー日のオープンを選んだのは恣意的なものです。単に、両限月の契約がかなり活発に取引されていると思われる時点を選んだだけです。正直に言うと、私はこれを試したことがありませんが、SchwagerやLeBeauのどちらかの本を読んだときにこのやり方を知りました。

dnm

[Q] 真の継続契約の履歴データ（先物）を作成するにはどうすればよいですか？ロール時に価格調整のバックプロパゲーションを行いますか？

Souqmateさん、

有益な情報をありがとうございます。ロール時に価格調整のバックプロパゲーションも行いますか？真の継続契約履歴データファイルを作成するには、株式の分割調整のように、各契約ロール時に過去の価格を調整する必要がありますよね？

[A] souqMateより（2016年8月19日追加）

はい、古い契約と新しい契約の間の決済価格（またはロール日前日の決済時間前の最終取引価格）の差を使用してロールします。これにより、戦略でのPnL計算用の連続したシリーズが得られます。

[Q] 先物：「First Position Date」とは？

[A] Malcolm Haylockより（2016年8月20日追加）

First Position Date: 最初のポジション日、または最初の清算日

  • クリアリング機構が、清算対象となる契約について、初めて意向受付およびアサインメント処理を開始する日付です。

Last Position Date: 最後のポジション日、または最後の清算日

  • クリアリング機構が、清算対象となる契約について、意向受付およびアサインメント処理を最後に受け付ける日付です。

多くの契約では、清算日はFirst Position Dateに依存します： http://ibkb.interactivebrokers.com/node/992

APIを通じてFirst Position Dayを取得する方法があれば、ロールオーバー戦略の作成がもっと簡単になるでしょう。

いいなと思ったら応援しよう！