こちらはインタラクティブブローカーズのAPI情報、Dmitry's TWS API FAQを日本語に訳したものです。元のウェブページの量が多すぎて閲覧しにくい＆元サイトを翻訳にかけるとPCが固まるため、備忘録用に章ごとに分けつつ、できる範囲で変な訳を修正して保存しています。
目次
- TWSアプリ関連
- プログラミング言語別コードサンプル
- 実装メモ
- よくあるエラーと修正方法
- ContractDetails、Index、注文方法（共通）（このページ）
- コンボ注文、ブラケット注文、株式・オプション・先物注文
- 約定照会、デモ口座とリアル口座、グラフ化
- データサブスクリプション
- スキャナ、基本仕様、過去データ制約、IBゲートウェイ
- FX関連、ポートフォリオ情報、その他
ContractDetails
[Q]contractDetails.liquidHoursとcontractDetails.tradingHoursの違いは何ですか?
2021 年 6 月 4 日に追加
ContractDetails.tradingHours は、商品が取引可能な時間を定義します。これらの時間は、商品が取引される取引所によって設定されます。 ContractDetails.liquidHours は IB によって定義されています。多くの商品 (すべてではありません!) について、この商品の取引が流動性がある場合に調査が行われました。ただし、IB がこれを定義するためにどのような基準を使用しているのかはわかりません。これらの流動的な時間外では、取引オプションは IB によって制限されます。例: 流動性のない時間帯にはスプレッドが大きくなる可能性があるため、MKT 注文は受け付けられません。 |
[Q] ContractDetails でリストを交換しますか？
このコードを使用して、将来のシンボルの交換リストを取得しようとしています。
契約契約;
Contract.symbol = "ES";
Contract.secType = "FUT";
client->reqContractDetails(reqId++, コントラクト);
次に、コールバックcontractDetails()でcontractDetails.validExchangesを出力すると、「GLOBEX,MIBSX」と表示されます。
この「MIBSX」とは何でしょうか？また、「CME」がリストされていないのはなぜですか (TWS に ES を追加しようとすると、GLOBEX と CME の両方が表示されます)。
ありがとう、
–趙
[A] rholowczak 著 (この スレッドから)
GLOBEX は CME の電子マーケットです: http://www.cmegroup.com/globex/
【Q】ContractDetailsのタイムゾーン仕様の変更はありますか？
現在、TWS API 契約の詳細のタイムゾーンはどうなっていますか? 明らかにタイムゾーン仕様の変更のせいで、今日起動時にすべてのアルゴリズムが台無しになってしまいました。私はカスタム辞書を使用して独自の IB タイムゾーン仕様から IANA タイムゾーンに変換し、タスク スケジューラの取引時間を取得し、共通の標準内で作業します。API の米国株は現在、「米国/東部」という名前のタイムゾーンにあります。それが来るのを見ていなかったので、それが標準仕様 (「America/New_York」になるため IANA ではありません) への歓迎すべき変更なのか、それとも推測する必要があるさらに別の独自形式への変更なのかわかりませんか? |
[ [A]オンラインで表示/返信 (#45898)
2020 年 12 月 3 日に追加
IBは最近フォーマットを変更したようです。 IANA 標準に準拠する機会を利用できなかったのは残念ですが、少なくともここに文書化されています。IANA 、レガシー、および 3 文字のコードが混在しているように見えます。 - また タイムゾーン ID は tz データベースからのもののようです: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones Python から pytz でそれらを処理できます: https://pypi.org/project/pytz/ |
OP: はい、確かに ID はデータベースにありますが、およそ半分は非推奨になっています。これらがデータベースから完全に削除されない限り、これは、以前 API で使用されていた文書化されていない不十分な ID の排除に向けた良い一歩であるように見えます。 |
【Q】ミンティックって間違ってますか？
株式記号 DGLY に対して reqContractDetails を実行すると、0.0001 の mintick が返されます。ただし、アクティブトレードでは0.01でしかトレードできません。TWS が mintick で伝えていることを信頼しているため、これによりコードが混乱します。何が問題になっているのか考えられますか?
[A] リチャード・L・キング著
2021 年 2 月 27 日に追加
各契約の詳細には、「有効な取引所」リスト内の各取引所に 1 つずつ、市場ルール ID のリストが含まれています。市場ルールは、最小ティックが価格によってどのように変化するかを正確に示します。マーケット ルールの詳細は、reqMarketRule() 関数から取得します。
たとえば、DGLY の場合、すべての取引所のマーケット ルールは同じで、ID は 557 です。API テスト プログラムで reqMarketRule(557) を呼び出すと、次の結果が返されます。
20200912 14:53:36.070 ==== マーケット ルールの開始 (marketRuleId=557) ==== ローエッジ=0、インクリメント=0.0001 ローエッジ=1、インクリメント=0.01 ==== マーケットルール終了 (marketRuleId=557) ====
これは、価格 >= 0 および < 1 の場合、最小ティック増分は 0.0001 であることを示しています。価格 >=1 の場合、0.01 です。
とても便利な仕組みです！
リチャード |
取引所 SMART、TSEJ、CHIXJ、および JPNNEXT に関連するルールは、837、789、837、および 942 です。これがそれらに対して返される内容です。
==== マーケットルールの開始 (marketRuleId=837) ==== ローエッジ=0、インクリメント=0.1 ローエッジ=5000、インクリメント=1 ローエッジ=100000、インクリメント=10 ==== マーケットルール終了 (marketRuleId=837) ====
==== マーケットルールの開始 (marketRuleId=789) ==== ローエッジ=0、インクリメント=1 ローエッジ=3000、インクリメント=5 ローエッジ=5000、インクリメント=10 ローエッジ=30000、インクリメント=50 ローエッジ=50000、インクリメント=100 ローエッジ=300000、インクリメント=500 ローエッジ=500000、インクリメント=1000 ローエッジ=3000000、インクリメント=5000 ローエッジ=5000000、インクリメント=10000 ローエッジ=30000000、インクリメント=50000 ローエッジ=50000000、インクリメント=100000 ==== マーケットルール終了 (marketRuleId=789) ====
==== マーケットルールの開始 (marketRuleId=942) ==== ローエッジ=0、インクリメント=0.1 ローエッジ=3000、インクリメント=0.5 ローエッジ=5000、インクリメント=1 ローエッジ=30000、インクリメント=5 ローエッジ=50000、インクリメント=10 ローエッジ=300000、インクリメント=50 ローエッジ=500000、増分=100 ==== マーケットルール終了 (marketRuleId=942) ====
終値は755だったので、ミンティックは
スマート0.1 セクション 1 チクジ 0.1 JPNNEXT 0.1
ルールの一部に誤りがあるとしても驚かないが、このメカニズムはかなり信頼できることがわかった。これが、あらゆる種類の異なるルールを持つ LSE の銘柄を理解する唯一の方法である。 。 |
インデックス
[Q] IBで利用可能なすべての指数のリストを取得する方法はありますか? (別名「製品リスト」)
[A] 投稿者: paul_blinn@hotmail.comオンラインで表示/返信 (#49151)
2022 年 4 月 19 日に追加
地域と取引所で検索してみてください。 製品リスト – インデックス – 北米 | インタラクティブ・ブローカーズ UK リミテッド |
注文方法（共通）
[Q] IB ではどのような注文タイプがサポートされていますか?
[A] 利用可能なすべての注文タイプについては、公式ドキュメントを参照してください。
http://interactivebrokers.github.io/tws-api/orders.html
[Q] 注文を送信しましたが、次に何をすればよいですか?
[A] by skunktrader2001
注文を送信すると、TWS は注文の処理 (PendingSubmit -> PreSubmit -> Submitted -> Filled) として 1 つ以上のorderStatus () およびopenOrder () コールバック メッセージを非同期に送信します。また、注文としてexecDetails () コールバックも送信します。埋める。何らかのデータ構造で各注文のコールバックからこれらの状態メッセージをキャプチャする必要があります。これにより、ループの各反復で約定/キャンセルなどがあったかどうかを確認できます。
————— こちらもリチャード・L・キング著 ———–
TWS のログに関係なく、独自のアプリは注文に関するすべてのイベントをログに記録する必要があります。つまり、placeOrder、cancelOrder、openOrder ( )、orderStatus ()、およびexecDetails () コールバックをログに記録します。そして、errMsg () イベントを必ずログに記録する必要があります。ログから注文の現在の状態を正確に判断できる必要があります。
[Q]市場前や市場後に株式を取引するにはどうすればよいですか?
IB Web サイトの [A]:市場前または市場後に株を取引するにはどうすればよいですか?
注: 最も重要なことは、成行注文または成行注文に変わるものを外部 RTH 注文の一部にすることはできません。 （上記リンク先のIBウェブサイトより引用） * 株式の場合、成行注文と逆指値注文 (トリガーされると成行注文になります) は、東部標準時間の 09:30 から 16:00 (ニセの通常取引時間セッション) までのみ有効です。市場前時間、通常取引時間、アフターマーケット時間を含むすべてのセッションで注文をアクティブにするには、指値または逆指値タイプの注文を使用し、「RTH 外部を許可」属性を追加する必要があります。同じ設定が Globex/ECBOT/Nymex Future 契約にも適用されます。Nybot はストップ注文を受け入れ、内部ですべての利用可能な時間に有効な「保護付きストップ」注文に変換します。Future コントラクトの RTH セッションの詳細は、コントラクトの説明ウィンドウに記載されています。 * 外国為替、OTCBB、およびピンクシート証券には、集中市場や主要取引所がないため、通常の取引時間の指定がありません。以前に適用されたデフォルトの RTH 制限に関係なく注文が実行されるため、トレーダーはセッションの初期および後期にこれらの商品を取引する際には注意する必要があります。 * IBKR プロ口座の通常取引時間外は、EST の 4:00 に始まり市場が開くまで続き、市場終了から EST の 20:00 まで再開されます。IBKR Lite 口座の通常取引時間外は 7:00 EST に始まり市場が開くまで続き、市場終了から再開して 20:00 EST まで続きます。どちらのアカウントタイプの通常の取引時間も東部標準時間の 9:30 ～ 16:00 です。 |
[Q] execDetails と orderStatus
[A] 投稿者: man910オンラインで表示/返信 (#46335)
2021 年 1 月 6 日に追加
orderStatus ではなく execDetails を監視する必要があります。いくつかの注文でエラーが発生したため、orderStatus を使用するとより良い情報が得られると考えましたが、呼び出されないことがよくありました。結局、注文の失敗に対するエラー コールバックで特定のコードを探す必要がありました。 IBApi.EWrapper.orderStatus に関する重要な注意事項 : |
[Q] 注文状況を照会するにはどうすればよいですか?
[A] ドミトリー著
基本的に注文状況を問い合わせる必要はありません。IBからお知らせします。IB の API ドキュメントを参照してください: orderStatus()
この fn は、注文のステータスが変更されるか、TWS に再接続した後に起動されるたびに (あなたではなく) API によって呼び出されます。
また、注文が部分的に約定した場合に orderStatus() イベントがどのように動作するかを示す次の例も参照してください。(更新 (2021 年 2 月): サンプルのリンクが壊れているため、Google キャッシュされたページから「次のサンプル」コンテンツを掘り出す必要がありました):
（引用）
部分的に約定した注文ステータス 次の例は、注文が部分的に実行されたときに orderStatus() (注文ステータス) がどのように動作するかを示しています。 部分的な実行例 XYZ 株を 1000 株注文します。1000株がすべて執行されるまでに4回の執行があった。最初の部分は 200 株で約定され、その後、第 2 部分は 200 株で約定されます。3番目の部分はさらに200株で執行され、最後の部分は400株で執行されます。
この例によると、orderStatus() アクティビティでは、API は次のようなステータス情報を継続的に受信します。
|
（引用終わり）
reqExecutions() でリクエストできるexecDetails()も参照してください。
——-
関連記事: Ewald による回答 ( https://groups.io/g /insync/からオンラインで表示/返信 (#189 )
探しているのは、openOrders (または詳細情報がある openTrades) およびポジション メソッドです。これらのメソッドははるかに高速であり、reqOpenOrders が古い情報を報告できるため、信頼性も高くなります。一般に、reqOpenOrders、reqPositions、または reqExecutions は使用しないことが最善です。代わりに、非リクエスト バリアントを使用してください。
[Q] アカウント内の過去の取引を取得したい
[A] by ds-avatarオンラインで表示/返信 (#49087)
2022 年 2 月 22 日に追加
TWS API では、現在の取引日の取引のみを取得できます。 次の 2 つのアプローチを使用できます。 1 つ目は、実行を要求することです (reqExecutions)。長所: これはよく知られており、広く使用されているようで、実行フィルター (取引された契約を含む) を使用できます。短所: フィルターを使用しても、クライアントが蓄積して照合する必要がある注文ごとに多数の部分約定を返す可能性があるため、依然としてかなり冗長になる可能性があります。 2 番目の方法は、完了した注文、つまり reqCompletedOrders を取得することです。長所: 注文ごとに簡潔な取引データを返します。短所: API リリースから少なくとも 2 年が経過しているにもかかわらず、文書化が不十分であり、各リクエストの後に完了した注文がすべて吐き出されるため、フィルタリングはクライアントが実行する必要があります。 1 日を超えて遡った取引の場合は、アカウント管理 Web サイトからレポートをダウンロードする必要があります (または電子メールで自動配信されるように設定する必要があります)。 – これもユルゲン・ライノルドによるものです。 昨年の同様のトピックで、Richard King は、最大 7 日間の実行レポートを取得できるようにする TWS の調整を指摘しました。ただし、これは IB ゲートウェイでは機能しません。TWS で、[ファイル] -> [新しいウィンドウ] -> [取引ログ] に移動し、プルダウンの [取引を表示] を [今日] からより長い期間に変更します。最大は「過去 7 日間」です。 |
[Q] API と非 API のクライアント ID を区別するにはどうすればよいですか?
[A] by Joshオンラインで表示/返信 (#41871)
2019 年 3 月 4 日に追加
IBKR モバイルなどの他のルートによって行われた注文や、TWS から手動で行われた注文には、常にクライアント ID = 0 が設定されます。API から行われた注文とは異なり、API からバインドされていない限り、API orderID も 0 になります。API 注文を区別したい場合は、接続時にクライアント ID を別の値に設定するか (API クライアントが非 API 注文を変更/キャンセルする必要がある場合を除く)、Order オブジェクトの orderRef フィールドを使用してそれらにラベルを付けることができます。弦。
更新 (2021 年 2 月): orderRef は「セッション」のみ存続しますが、permID (永久に存続) を使用することもできます。詳細については、この質問を参照してください: [Q] 戦略を識別するための順序フィールド? (clientID 対 orderRef 対 permID)
[Q] placeOrder API のどこに GTC を設定しますか?
[A] rwk2095 (ソース)により
これは IOrder オブジェクトの一部です。
timeInForce() を文字列として
有効な時間。有効な値は、DAY、GTC、IOC、GTD です。
http://www.interactivebrokers.com/php/apiUsersGuide/apiguide.htm
[Q] 「注文を更新する」VS「注文をキャンセルして作成する」？
[A]オンラインで見る
2021 年 2 月 24 日に追加
編集した方がよい: 1. 高速化 (2 つの操作ではなく 1 つの操作) 2.注文IDを保持します 3. 注文の追跡/分類に使用する場合は、OrderRef も保持します。 4. リンクされた注文 (OCA) がある場合は、それらをリンクしたままにします。親注文をキャンセルすると、依存する注文もすべてキャンセルされるため、すべて再作成する必要があります。 |
次の点にも注意してください。 「指示された」API オーダーの変更またはキャンセルには料金が発生します。SMART ルーティングされた注文はそうではありません。詳細については、次の質問を参照してください: [Q] 注文はどのくらいの頻度で変更できますか? |
[Q] 注文内容はどのくらいの頻度で変更できますか？
JRの[A]
2021 年 2 月 24 日に追加
「指示された」API オーダーの変更またはキャンセルには料金が発生します。SMART ルーティングされた注文はそうではありません。 ただし、約定するとクレジットが得られるため、実際に手数料を支払う必要があるのは、(キャンセルまたは変更された注文数 / 実行された注文数) の比率が 25 を超える場合のみです。 https://www.interactivebrokers.com/en/index.php?f=14718より 注文のキャンセル/変更
GTC などの有効期限が指定されている注文には、上記のスケジュールに従ってキャンセル料が課されます。 キャンセル・変更料金例はこちらをご覧ください。
ノート：
| ||||||||||||||||||||||||||||||||
[A2] Rob Terpilowski rterp99 著、yahoo.com
2016 年 2 月 18 日に追加
実際に取得している約定数に対して注文変更が多すぎる場合、IB はアカウントを凍結します。私は、受信した約定ごとに約 15 回以上の注文変更を行う MM 戦略を持っていました。IB は、実行後数時間以内に、この戦略を無効にしない場合、私のアカウントからの注文をすべて無効にするという通知を私に送ってきました。 1 回の実行につき 10 件以下の注文変更は許容されると言われました。
[Q] この口座では、関連口座内の同じ米国オプション契約の両側でオープンオーダー（コンボを含む）を持つことはできません。
[A] by Joshオンラインで表示/返信 (#43818)
2020 年 2 月 15 日に追加
注文を「非アクティブ」として IB サーバーに保持し、送信時ではなく後でサーバーによって考えられるすべてのエラーのみが検証されるようにすることに興味があるようですね。残念ながら、これが発生する唯一の状況は、ブラケット注文の一部である場合です。また、同じオプション契約の反対側に既存の注文があるなどの問題がある場合は、注文を取引所にすぐに送信できない条件が付いている場合でも、注文は直ちにチェックされ拒否されます。 注文が複雑で、ブラケット注文の一部にできない場合、唯一の可能性は、説明したように、ローカルマシン上に注文を保持することです。接続の安定性が気になる場合は、AWS などの専用の仮想サーバーを使用することもできます。または、戦略に適している場合は、ヘッジに同じ原資産に対して同様のオプションを使用することもできます。 |
[Q] 部分約定後に注文サイズを変更せずに注文の指値価格を変更するにはどうすればよいですか?
…注文の価格を変更するには、同じ注文 ID で異なる価格で注文しますが、他のすべては同じにします。しかし、部分約定の場合、変更された注文と数量が同じ場合はどうなるでしょうか?...
…..基本的に、すでに満たされた数量に応じて、その後の注文変更の数量を調整する必要がありますか? それとも、数量は常にこの注文全体の合計になりますか?...
Josh jb201448 の[A] はここにあります
2016 年 4 月 26 日に追加
こんにちは。
はい、注文数量は、すでに約定した契約を含む合計数量です。
したがって、100 株のうち 50 株が満杯で、残りの株数ではなく、残り 50 株の指値価格だけを変更したい場合は、lmtPrice を調整するだけで、totalQuantity 値は 100 のままになります。
-ジョシュ
[Q] 複数の注文完了ステータスの更新が届きます
[A1] vanx23@outlook.com より
「約定済み」注文ステータスは、同じ注文に対して複数回トリガーされる場合があります。
その一例は、IB のルーティング ロジックが、元の注文を短時間で実行される少量に分割することを決定した場合です。最終的に、注文は全体として約定されますが、約定された各サブパートの注文ステータスは「約定済み」となり、約定済みの金額が元の注文サイズとして表示されます。
満たされたサイズが元の注文サイズと一致する場合、はい、フラグを使用して、冗長な「満たされた」注文状態の処理を回避できます。
[A1] Ed news1000@edshome.net 作成
また、注文ステータス イベントが重複する可能性があることにも注意してください。これらは自分で検出する必要があります。
代わりに実行コールバックを使用する方が簡単な場合があります。重複はなく、さまざまな注文状態すべてではなく、実行に関するメッセージのみを取得します。
【質問】わかりました！注文が実行されました！しかし、約定価格はいくらだったのでしょうか？
[A] Vlad Palnik 著 ( このスレッドでは話題から外れました)
execDetails().execution.m_avgPrice を参照してください。
[Q] API と TWS の間のオーダー ID の不一致
TWS注文の属性に表示される注文IDが、APIのPlaceOrderコマンドから返される注文IDと異なる理由を誰かが説明してもらえますか? どうすればマッチングできるのでしょうか？
[A] by Joshオンラインで表示/返信 (#42922)
2019 年 9 月 14 日に追加
残念ながら、API オーダー ID は TWS 表示内では使用できず、監査証跡でのみ使用できます。「permId」は、注文後に TWS によって割り当てられる注文 ID であり、アカウント全体で一意になります。
注文にラベルを付けることに興味がある場合は、TWS に対応する列がある OrderRef フィールドを使用できます。
[Q] 私の注文が「無効な注文」ステータスになっているのはなぜですか?
[A] by Kurt (ソーススレッド)
まず、注文を *送信* するようにリクエストしたのに、次のように返された場合です。
非アクティブな場合は、おそらくエラー コールバックからの結果を無視していました。
おそらく、これは関連するエラーがなくても発生する可能性があります（それはわかりません）
IB付き）ですが、私は見ていません。
IB の注文状態と報告の扱いはほとんど文書化されていない。
時間の経過とともに、予告なく任意に変更されることなく、
ドキュメンテーション。
そうは言っても、「非アクティブ」には複数の意味がある可能性があります。
(1) 非アクティブとは、常に基本的に 1 つのことを意味します。つまり、順序が正しくないことです。
まだ活動中。これには、transmit false で「発注された」注文が含まれていました。
どの orderStatus メッセージが結果として使用されるか。そのような注文はもう生産されません
orderStatus メッセージ。IB がそれを変更すると、コードが壊れてしまいました。その結果、私は
送信で行われた注文を表すために独自の注文状態を作成する必要がありました
間違い。私はこの順序を認めるのが好きなので、これは理想的ではありません。
特定のフィールドが事前チェックされ、準備が整っている可能性が高い状態で (TWS によって) 受信されました
持ち帰り。現在の動作は信頼性のいくつかの側面を弱めます。
(2) Inactive は、送信された命令にも使用されていましたが、
拒否されましたが（フィールドが間違っているなど）、再利用可能です。つまり、修正できます。
送信を再試行してください。インタラクティブなアプリや自動化されたアプリに役立ちます。
インタラクティブなフォールバックを提供します。一部の注文拒否はまだ機能すると思います
この方法ですが、100%確実ではありません。
(3) 非アクティブは別の意味になる可能性があります: 注文が拒否され、
システムは（正当な理由もなく）修正して再送信することを許可していません。
注文 ID は無効になっているため、再利用できません。IB はこの新しい動作を導入しました
去年のある時期のこと。
少なくとも一部のケースでは、エラーに基づいて (2) と (3) を区別できます。
コード。
私のコードは現在、ケースに人工的な注文ステータス文字列「拒否」を使用しています
(3) エラー コード 201 が返された場合、その注文ステータスを設定します。 エラー 201
次のメッセージが生成されます。
「注文が拒否されました – 理由: ...」
インタラクティブ アプリのステータス「拒否」は、基本的にユーザーに拒否を指示します。
わざわざ注文を修正して再送信してください。(正しいことを許可すべきです
新しい注文 ID が自動的に生成されます。)
簡略化するために、orderId を無駄にして別の orderId を作成することをお勧めします。
1つ。IB が継続すれば、おそらく機能し続ける可能性が高くなります。
物事をめちゃくちゃにする。
いずれの場合でも、注文が非アクティブの場合はキャンセルする必要はありません。
特定のシナリオをより深く理解するには、次のことを試してください。
エラーを生成し、注文が TWS およびその他の方法で表示されるかどうか、またはどのように表示されるかを確認します。
エラー コールバックのコード。
-カート
【Q】注文を全てキャンセルしたいのですが？
[A] rholowczak 作成 (この スレッドから) (2015 年 7 月 16 日に追加)
「核オプション」はreqGlobalCancel()です
[Q] すべてのオープンオーダーをキャンセルし、すべてのポジションをクローズするにはどうすればよいですか?
[A] by Joshオンラインで表示/返信 (#40698) (2015 年 9 月 12 日に追加)
実際には、API から「すべてのポジションを決済する」関数は 1 つも存在しないことに注意してください。Position() または updatePortfolio() コールバックから現在のポジションのリストを受信し、決済注文を作成して発注する必要があります。すべての注文をキャンセルするための reqGlobalCancel 関数があります。
[Q] (TWS のように) オーダーを一時停止するにはどうすればよいですか?
[A] by Joshオンラインで表示/返信 (#39988)
2018 年 6 月 6 日に追加
残念ながら、API から注文を一時停止する方法はありません。キャンセルして再配置する必要があります。いずれにせよ、これは基本的に TWS が舞台裏で行うことです。
ジョシュ
【Q】注文履歴を取得するにはどうすればよいですか？
[A] by Joshオンラインで表示/返信 (#43808)
TWS (ソケット) API は最大 1 週間の取引履歴を提供します。IB ゲートウェイは当日のみです。それよりも前の履歴が必要な場合は、フレックス クエリ (ユーザー名/パスワードを必要としない) または CP API を使用できます。
[Q] すべての注文 (キャンセルされた注文、プログラムが実行されていないときに TWS 経由で手動で作成された注文を含む) を追跡するにはどうすればよいですか?
こんにちは、
私は手動とTWS API経由の両方で取引しています。
自分の取引をより良く分析するために、次の方法を探しています。
手動または API 経由でキャンセルした注文をリストします。
私の問題は、API に接続されたプログラムが実行されていないことです。
常になので、STP注文を時折手動でキャンセルするとき
API 接続されたプログラムによって記録されることはありません。
TWS からキャンセルされた注文情報をエクスポートする方法が見つかりませんでした。
理想的には、アカウント – トレードログ経由のような注文リストをエクスポートしたいと考えています。
TWS のメニューエントリー。
統合されたリストを取得する方法を知っている人はいますか?
期間内にキャンセルされた注文はすべて、手動でキャンセルされたことを意味します
注文が自動的にキャンセルされましたか？
先ほども述べたように、API 接続されたプログラムを介してそれらを制御するだけでは、
一日を通して散発的にしか開始されないためです。そうでない場合もあります
まったく（たとえば、手動で取引するだけの日など）。
事前にご協力いただき、誠にありがとうございます。
最高、
ヨーゼフ
[A] by Joshオンラインで表示/返信 (#39971)
2018 年 6 月 6 日に追加
ヨーゼフ、
注文履歴を受け取るには、監査証跡を確認することをお勧めします。ログ ファイルよりも解析が簡単で、注文のキャンセルが表示されるはずです。
-ジョシュ
——- ジョセフからの最新情報: ————
API に関して話が逸れてしまうのは承知ですが、私はこう思いました
同様の問題を抱えている人にとっては役立つかもしれません:
Josh 氏が寛大に指摘したように、監査データは次のようなこともできます。
という名前の別の XML ファイルにあります。
各平日の Mon.audit.xml など。
それらは簡単に解析でき、これができるという利点があります。
ファイルにアクセスするだけでスクリプトによって実行されます。したがって、開く必要はありません
TWS の監査メニューはあまり自動化できません (確かに
IBController の素晴らしい作成者はこれを自動化することさえできます)。
監査メニュー項目で実行されるのは、ファイル内のデータから HTML ファイルを作成することだけです。
xml ファイルは標準ブラウザに自動表示されます。
ファイルは、jts フォルダーの下の悪名高いフォルダーにあります。
一連の文字でアカウントを指定します。
これらはローリングベースで上書きされるため、cron ジョブを介して保存します。
理にかなっています。
再度、感謝します、
ヨーゼフ
【Q】複数の実行メッセージが届きました。
>>> 今朝試してみましたが、依然として複数の実行メッセージが表示されました。
>>> 単一の実行 – 場合によっては。場合によっては 1 つの実行メッセージだった
>>> 1 回の実行に対して。しかし、受け取った実行メッセージは注文よりも少なかったです
>>> ステータス (ステータス?)
>>>
>>> 複数の実行メッセージを受け取った人はいますか? それらが 2 倍になると、
>>> は 3 ～ 5 ミリ秒離れているようです。
[A] by Kurt (この スレッドを作成)
>> 「複数の」メッセージに関して何かが欠けている可能性がありますが、危険です。
>>推測します。
>>
>> 同じ execId を持つ 2 つの実行メッセージを取得してはなりません。あなたが持っている
>> 信頼性が必要な場合は、そのようなことを追跡してください。重複
>> メッセージは命令であっても実行であっても問題ないはずです。
>> 必要な情報を保持している限り。（まあ、話すことはできませんが、
>> Excel 内で可能なこと。)
>>
>> オブジェクトごとに状態を把握するのは面倒だと考える人もいます
>>彼らは懸念しています。しかし、そうしない場合の悩みは計り知れません。あなた
>> 実際には存在しない問題を作成します。IB は、
>> 追跡せずに使用しても信頼できる種類のシステム
>> 状態
>> 向こう側です。したがって、必要な情報を維持しないと、
>> その結果として得られる問題は、本質的にはあなたが作成した問題です。
>>
>> いつでも死刑執行をリクエストでき、その後さらに多くの報酬を得ることができます
>> 「重複」ですが、すでに受信したものは無視してください。私としては
>> 一部の人々は、見ているという理由で明示的に処刑を要求していることを思い出してください。
>> 実行メッセージがドロップされます。(これが両方の注文を追跡する理由です
>> と実行は、どちらかがドロップされる可能性があるためです。)
>>
>> -カート
> execID を記録していませんでした。それを見始めます。ありません
> 注文ステータスに対応する一意の識別子があるようですが、ありますか
> 一つ？
>
> 私はすべての状態を自分の側で監視し、情報の自分のコピーを保持しています。私
> 他の方法で試してみたら、とんでもないことになると想像してください。私はしません
> 両方の注文ステータスの更新を取得するまで、取引は終了したと考えてください。
> 'fill' *および* 正しいポジションを示すポートフォリオの更新。
>
> 処刑を受けるために呼び出しを送信したことはありません – 処刑は実行後に表示されるだけです
>それぞれの注文。
注文 ID フィールドは、注文を一意に識別するために必要なものを示します。
発注し、その結果のアクティビティをその注文に関連付けます。両方
orderStatus メッセージと openOrder メッセージが関係しており、少し問題があります。
私の記憶では、この 2 つの間の冗長性があったと思います。（思い出したのですが、彼らはいつも入ってきます）
ペアであり、常に特定の順序で並んでいます。)
全体的に良いアプローチをしているようですね。言及するつもりだった
ポートフォリオの更新はあったが、それには乗りたくなかった。😉
辞める必要がある場合は、約定をリクエストするか注文をオープンする必要がある場合があります。
ディスクに保存した状態に応じて、アプリを再起動します。または、あなたが望むかもしれません
実行または orderStatus メッセージが欠落していることがわかった場合に実行します。
ここにいる多くの人が実際に起こったことを報告しています。
-カート
[Q] 買い注文が約定したらすぐに売り注文を出す方法
こんにちは、みんな、
買い注文が約定したらすぐに売り注文を送信したいのですが、このロジックを一度に送信する方法はありますか、それとも売り注文を送信するために買い注文の約定を聞く必要がありますか?
助けていただければ幸いです…
ステフ
この スレッド の tdrtw による[A]
私自身はまだ調べていませんが、やりたいことに適したブラケットオーダーがあると思います。
あなたはエントリーがどのくらいの価格になるか、そしてエントリーが起こる前に最初のストップポイントを知っていると思います。エントリーオーダーにストップとなるブラケットオーダーを結び付けることができます。ブラケット注文は、エントリー注文が発行されるまで有効になりません。
わかったことをお知らせください。
乾杯、
ダミアン
[A2]エド
親/子の注文が必要です。親はあなたのエントリであり、子は
出口です。子注文では、ParentId をエントリ注文に設定します。
アーカイブ内で議論が行われる可能性があります。あれもこれも使ってみた
実際に動作します (API では必ずしも動作するとは限りません)。
[Q] 自分の逆指値注文が API メッセージからトリガーされたかどうかを確認するにはどうすればよいですか?
[A] Richard L King 著 (この スレッドで見つかりました)
逆指値注文がトリガーされると、orderStatus コールバックと openOrder コールバックを取得します。
API ドキュメントのさまざまなステータスの定義を読んで、どのステータスが適用されるかを確認する必要があります (事前送信済みから送信済みに変わると思いますが、それを確認する必要があります)。
注文に関しては、起こったすべてを完全に記録する必要があります。お金がかかっているものを見逃すわけにはいきません。これをやっていれば、質問する必要はなかったでしょう。
ストップ指値注文で最良の約定価格を得る方法については、あなた以上に知っている人はいないでしょう。それはおそらく、ポジションに入ろうとしているか、ポジションから抜け出そうとしているかによって異なります。
リチャード
- - - - - - - また - - - -
ジョー: リチャード、
あなたは正しいです。逆指値注文がトリガーされると、orderStatus は「PreSubmitted」を「Submitted」に変更します。これは私が見逃していたものです。情報ありがとうございました。
指値注文の執行問題では、通常は非常に悪い価格になる逆指値注文を使用する代わりに、損切り用の逆指値注文を設定しました。それで、最後の価格と私の指値注文価格を比較し続けるスレッドを作成するのは実用的なアプローチだと思いますか? 最後の価格が私の指値価格を超えた場合、実行される可能性のある新しい指値価格で指値注文を再送信します。私はこれに関してはかなり初心者なので、あなたの助けに感謝します。
最高、
ジョー
- - - - - - - そして最後に - - - -
あなたの提案は可能な方法の 1 つですが、変化の激しい市場では、
値動きを追いかけているのに、まったく掴めないことに気づくかもしれません。
そして、ストップを使用した場合よりもはるかに大きな損失を被ることになります
注文。API を通じて取得する価格は、
市場よりも簡単に 100 ミリ秒以上遅れる可能性があります。
修正された注文が取引所に届くまで、さらに 100 ミリ秒以上かかります。
別の可能性は、ストップリミットの指値価格を次のように設定することです。
最悪の価格でも受け入れる準備ができていますが、おそらく、
現在の市場が（売りの場合）よりも高い場合は、それよりも約定するのが良いでしょう。
自分の限度額を設定します (この場合、成行注文でも同様に機能します)。しかし
繰り返しますが、まったく満たされない可能性があります。
ストップロスの状況では、ポジションの外にいることが重要です。
取引所がネイティブのストップ注文を提供している場合、それが最善であるというのが私の見解です
オプション – その時点で利用可能な最高の価格が適用されます。あるかもしれない
マイクロ秒後にはより良い価格が利用可能になりますが、それは不可能です
それを予測します。
取引所がネイティブのストップ注文を提供していない場合、 IB には通常、
自動的に迅速な注文修正を行うシミュレートされた逆指値注文
あなたが説明した方法でのストップリミット注文 – しかし、それよりもはるかに効果的です
IB は取引所に非常に近いため、自分で行うことができます。
利益を削減するのではなく、収益性の高いポジションから抜け出そうとしている場合
損失を考えれば、創造性の余地はもっとあるかもしれません。あなたは、
最大の利益を引き出すためのリミットまたはリミット・イフ・タッチ注文、およびストップまたは
バックストップとしてのストップリミット注文: その後、両方を調整できます
定期的に、おそらくそれらを一緒に収束させますが、近づきすぎないでください。
(OCA グループに属している場合でも) 両方が実行される可能性があります。
可能性は無限であり、私はそれが存在することをほぼ保証します
このフォーラムには私とは異なる見解を持つ人もいるでしょう。ないよ
'正しい答え。
[Q] IBのトレーリングストップやその他のアドバンスト注文タイプを使用する必要がありますか?
トレーリングストップを送信するべきか、プログラムで価格を監視し、価格が特定のポイントに達したときにポジションを閉じる注文を送信するべきか、誰かコメントできますか?
[A1]ジェイソン・サップ 著
私の個人的な好みは、価格が特定のポイントに達したときに終了するのではなく、常に市場でストップ注文を行うことです（または少なくとも IB のバックオフィスでシミュレーション）。ATS がダウンしても、自分はまだ保護されていることがわかります。最後に、IB がサポートするトリガー メソッドの中には、正しくプログラムするのに少し時間がかかりますが、すでにそれが行われているため、これにも価値があります。
さて、そうは言っても、私は独自のトレイルを実装しましたが、依然として通常の IB ストップ注文を使用しています。アルゴリズムの指示に従って価格を変更するだけです。
ジェイソン
[A2] エド作 <賞@…>
私はその考えを支持します。
親/子機能を使用してエントリー順序、利益エグジットを指定します
そして同時に出口を止めます。私に地位がなくなるか、それとも
利益とストップのポジションを持つことになります。私のATSは「ダウン」しているはずです
(プログラムのクラッシュから電源障害や ISP 障害まで) 私はしません
悲惨な損失にさらされる可能性があります。
前述したように、価格で注文を投稿する必要はありません
あなたは最終的に意図しています。途中で調整することもできます（ただし、
発注された注文のすべての側面を変更できるわけではありません)。
私にとって、それは最終的に、
プログラミングをもう少し。いつものように、どのアプローチを選択するかはあなただけが決めることができます
特定のニーズに最適です。
[Q] 特定の時間に注文を約定させるにはどうすればよいですか?
[A]
jimshaw4585: 「時間が経っても大丈夫」と「時間までは大丈夫」を組み合わせて、狭いウィンドウを作成できます。
tdrtw:私は「成行売り、市場終了 1 分前に設定されたグッドアフタータイム」を使用して、ワンキャンセルオールにグループ化されたオープンポジションを他の手仕舞い注文とともに清算します。過去 4 年間、それは期待どおりに機能しました。
[Q] OCAの注文は？
[A] by Kurt (このスレッドから)
注文を OCA グループに入れない限り、注文は相互にキャンセルされません。それは
OCA (「One Cancels All」) グループの目的。
ocaGroup フィールドをどこにも設定していないようです。
必要に応じて ocaType を設定することも忘れないでください。
-カート
——————— でも、これも: —————————-
ブラケット注文を作成するとき（つまり、エントリー注文と関連する
ストップ注文やターゲット注文など）、OCA グループを設定する必要はありません。
TWS があなたのためにそれを行うため (つまり、parentId が設定されている注文は
自動的に OCA グループに配置されます)。確かに、OCAグループを設定した場合
TWS はそれを独自の値で上書きします。
ブルース、こうすれば (厳密に必要というわけではありませんが) ずっとわかりやすくなるでしょう。
注文ごとに新しい注文オブジェクトを作成しました。ストップ注文とターゲット注文の場合
parentId をエントリ順序の orderId に設定する必要があります。
リチャード・L・キング
todo: 手動 (Kurt による) と Richard による OCA の実際の例をいくつか挙げます。
親子罪状認否を利用する
oca グループが自動的に作成されます。
————————————— そしてリチャード・キングからの非常に重要なメッセージ ———————-
ここでは 2 つの異なることについて話しています。
ブラケット注文とは、 リンクされたストップロスを伴うエントリー注文のことです。
および/またはターゲットオーダー。TWS および IB サーバーはこれらを特別に扱います。
エントリー注文は取引所に発注されますが、ストップロス注文とターゲット注文は
エントリーオーダーが埋まるまで保留されます。そうなると、送信されます
交換所へ。
さらに、最後のオーダーを除くすべてにtransmit=falseを設定すると、
ブラケットの場合、TWS は、
一連の注文の準備が完了しました。
この利点は次のとおりです。
1. エントリー注文が約定しない場合、ストップロス注文とターゲット注文は
取引所に入れられることはありませんので、心配する必要はありません
実行中。
2.エントリー注文が即座に実行される状況を回避します（例:
成行注文または市場性のある指値注文)、次に接続または
ストップロス注文を送信する前にアプリケーションが中断され、
無防備な姿勢で。
3. エントリー注文をキャンセルすると、ストップロス注文とターゲット注文もキャンセルされます。
自動的にキャンセルされました。
あなたがやっているように見えるのは、単にOCAグループを作成しているだけです（
もちろん、OCA グループ名を指定する必要があります)。しかし、これではどちらも得られません
「特別な」ブラケット注文の利点。したがって、制限を使用する場合、または
ストップ（リミット）オーダーは入力できます。決して満たされることはないかもしれませんが、何もする必要はありません
他の注文の実行を妨げます（どの注文が実行されるかは、もちろん依存します）
エントリーオーダーのタイプに応じて）。
この特別な順序のグループを作成するには、parentId を設定するだけです。
子注文は親注文の orderId に変換されます。残りはすべて TWS が行います。
あなたのために。
エントリー注文の後にストップロス/ターゲット注文を追加することもできることに注意してください。
は、parentId を使用して (ただし実行前に) 配置されました。
ちなみに、念のため言っておきますが、最近は実際に確認していません。
TWS は、ブラケットの作成時に指定した OCA グループ名を上書きします。
この特別な方法で注文しますが、以前は確かにそうでした。重要なのは、あなたが
供給する必要はありません。
リチャード・L・キング
【Q】OCA注文は模擬注文ですか？
[A] by Joshオンラインで表示/返信 (#43747)
2020 年 2 月 7 日に追加
OCA グループは、取引所によってネイティブにサポートされていないシミュレートされた注文タイプです。OCA グループ内の注文は、約定する可能性が高いと判断されるまで IB サーバー上に保持され 、その後その注文が取引所に送信されます。したがって、実際には、OCA グループタグを含む注文を取引所ではなく IB サーバーに送信するだけです。ミリ秒間隔で配置されたグループ内の以前の注文がすでに約定している場合、同じグループ内の後の注文は拒否されることが予想されるため、これは予想される動作です。Order.ocaType フィールドを使用して、注文の部分約定をキャンセルするか、グループ内の他の注文を減らすかを選択できます。
[Q] MOC（Market on Close）注文とOCAグループ
[A] by ds-avatarオンラインで表示/返信 (#48315)
2021 年 12 月 18 日に追加
MOC オーダーは、unprotected-reduce モードで OCA グループに配置できます。これは、MOC 注文に関する私の経験の中で機能した単一モードです。ただし、クロージング注文はどの段階でも実際には減額されない可能性が高く、他の注文が完全に約定された場合にのみ完全にキャンセルされるという追加の注意事項があります。 |
[Q] コード: 201 – 注文が拒否されました – 理由: OCA グループの注文はすでに完了しています
[A] Richard L Kins、Josh、その他による (この スレッドから)
<長すぎてここにコピーできません。オンラインでご覧ください…>
【Q】注文が多すぎませんか？
[A] by rwk (この スレッドから)
頻繁ではありませんが、米国株でオーバーフィルを取得したことがあります。私の場合、キャンセル＆交換をしたときによく起こります。以前の投稿で述べたように、実行レポートが遅れることがあり、最近はそれが深刻な問題になっています。
あなたが説明している問題は、注文が1つだけあり、それを変更していないと仮定すると、紙の取引のバグのように聞こえます。
[rwk]
[Q] 空売り（SSHORT vs SELL）?
2015 年 4 月 27 日に追加
こんにちは、
私は紙の口座でデイトレードアルゴリズムをテストしており、「SELL」注文を発行するだけで正しく空売りすることができます。ただし、APIマニュアルには、注文は「BUY」「SELL」「SSHORT」のいずれかである必要があると記載されています。「SSHORT」という指定は空売りのためのものだと思っていました。ただし、紙のアカウントでその注文タイプを発行すると、API からエラーが発生します。紙口座に関する限り、空売りには「SELL」を使用すると問題ありません。私の質問は、空売りに「SELL」注文を使用することは、ライブ口座で正しく機能するかということです。それとも、ライブ口座での空売りの場合は、何らかの方法で「SSHORT」注文に戻らなければなりませんか? ありがとう。
ロイ
[A] ジェイソン・サップ著 (この スレッドから)
米国株の場合、SELL注文は問題なく機能します。もう4年くらいやってます。
ジェイソン
[Q] 注文が一部満たされたまま注文数量を変更したい。
こんにちは、みんな、
これはプログラミングの問題というよりも TWS の問題ですが、誰かが助けてくれれば大変助かります。
(たとえば) 10 枚の先物契約に対して指値注文が入力され、6 枚の契約が約定された後、実際に必要なのはそれだけだと判断した場合、実際に注文をキャンセルせずに、それを反映するように注文を変更するにはどうすればよいですか? 私の経験から言えば、6 を入力した後、数量フィールドを 6 に修正すると、10 まで入力され続けます。すでに約定した6よりも低い金額に注文を修正する場合も同様です。ただし、注文数量を (たとえば) 7 に変更すると、最終契約が履行されるだけで、ステータス ボックスに「履行済み」と表示されることがわかりました。
注文をキャンセルしたくない理由は、その注文が子注文が関連付けられたバスケットの一部であり、最初の注文が修正されずに実際にキャンセルされると、関連する子注文もキャンセルされるためです。ほしくない。
誰かが助けてくれれば、これで白髪は少し減るでしょう。
どうもありがとう、ジョン
[A] by Jsa Jsa
私は、親と子の順序を維持し、非常にうまく機能する方法を見つけました。将来誰かが同じ問題を抱えている場合に備えて。
解決策:元の親注文が 10 枚の契約を購入する予定で、注文が約定している間に (たとえば) 6 枚で十分であると判断された場合、元の親注文を関連する子ストップロス注文よりも数ティック下に移動し、親を変更します。わずか7契約まで注文可能。同時に、子注文の金額も (この場合) 6 に変更します。その後、子のストップ注文または利益確定注文が実行されると、元の親注文の残りの部分がキャンセルされます。
これを自動的に行うように注文入力システムを設定しましたが、それが TWS に指示することであり、私が言うように、それはうまく機能します。
[Q] APIから手数料を受け取るにはどうすればよいですか?
[A] ブラント・ハーン著
EWrapper の openOrder コールバックを見てください。渡される OrderState オブジェクトには m_commission と呼ばれるプロパティがあり、注文が約定されてから 1 秒または 2 (またはそれ以上) 後に手数料値が得られます。
(2018 年 3 月 29 日更新)
これは事実ですが、orderStatus が満たされることは保証されません。コミッション情報を受け取る信頼できる方法は、commissionReport 関数を監視することです。この関数には、取引直後とその後の reqExecutions に応じたコミッション情報が含まれます。すべての API クライアントからコミッション情報を受信するには、API クライアントをマスター クライアントとして設定する必要があります。
[Q] また、API から特定の日のコミッションの合計を確認したい場合はどうすればよいですか?
[A] ブラント・ハーン著
単一取引手数料からその情報を自分で収集する必要があります
【Q】現職取得日を確認するにはどうすればよいですか？
[A] by カート
TWS API経由では何も行われません。明細書をダウンロードする必要があります。
【Q】コントラクトの指定にconIdだけでも良いですか？
[A]
見る
http://www.interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc
つまり、バージョン 9.64 のリリース ノート:
「一意の契約識別子である conid を使用して、API から市場データをリクエストし、注文できるようになりました。以前は、conid は契約の詳細にのみ使用できました。」
これはあなたの質問の答えになりますか?
[Q] 注文したのが並んでるの！？
[A]フランク・ベル著
特別な知識はありませんが、IB のルーティングは区別されないと思います
顧客の間で。に基づいて満たされるはずだった注文ができませんでした。
それらが配置された時間。当然、そうなると私は不満を感じます。
SMART グループといくつかの電子メールをやり取りした後、たとえば次のようなことがわかりました。
ナスダックで休んでいる5時に5000xyzを買う注文、そしてそれが可能になる
ARCA で 100 を実行すると、5000 全部が ARCA にルーティングされます。
100 は氷山の一角を表します。もちろん、一度引き抜かれたら、
ナスダック、注文が返送された場合、または価格が優先された場合、注文は時間の優先順位を失います。
注文が返送される前に取引される可能性があります。どうか分かりません
これが最善の戦略です。あまり大量の注文には向かないと思います。あ
より良い戦略は、注文を分割し、一部を ARCA にルーティングし、
残りはナスダックに残します。しかし、それはSMARTに期待しすぎだと思います。
SMART が最初に注文をそのままにしておくという保証はないので、
ルート化されているため、自分が並んでいる場所がどこなのかを知る方法はありません。
[Q] DTシステムの購買力の最大使用量
[A]
- こんにちは
- DT システムのアカウント購入力がなくなる前に、他に何をするか
- より大きな電力自体を購入することを除いて、条件を確認する必要があります
- ゼロ？在庫がなくなる前に、次の注文拒否エラー メッセージが表示されました。
- 購買力。ご提案をお待ちしております。ありがとうございます。
- ID: 919 | エラーコード: 201 | エラー メッセージ: 注文は拒否されました – 理由: 注文は正しいです
- 受け入れられません。
- 希望のポジションを獲得するために
- ローン価値を含む資本 [95269.89 USD]
- 超えなければなりません
- 当初証拠金 [95902.93 USD]
- [このメッセージのテキスト以外の部分は削除されました]
- 返事
- カート・ビグラー
- 2010 年 8 月 16 日
- ソースを表示
- 私は電力を買うことについてはあまり考えていません。
- マージン。しかし、購買力は通常の購買力を反映していると私は信じています。
- 証拠金で購入できる証拠金有価証券（株式など）。だからそうは思わない
- より複雑なマージン状況にも非常によく当てはまります。
- オプション戦略。
- 株式を購入している場合は、単純な購買力の概念が考えられます。
- おそらく当てはまりますが、その場合、何が原因で問題が発生するかわかりません。
- 例外。しかし、それにもかかわらず、マージンを「完全に」理解する必要があります。それで
- レポート管理に進み、マージンレポートを作成することをお勧めします。
- それを完全に理解していることを確認してください。残念ながらこれで一日は終わりです
- レポートに記載されているため、デイトレードには役に立たない可能性があります。その場合、次のことが必要になる場合があります
- マージンの分析に役立つ TWS の機能を検討してください
- 状況をダイナミックに。私はこれらの機能についてあまり詳しくありません
- ただしこの点。
- -カート
- メッセージ履歴を表示する
- 返事
- ジェイソン・サップ
- 2010 年 8 月 16 日
- ソースを表示
- やあ、ウェイドンさん
- 私はかなり複雑なポジションサイジングアルゴリズムを使用していますが、口座資本の 0.25% (コミッシュと推定スリッページを含む) を超えるリスクを負わないという前提から始まります。日が経つにつれて購買力が枯渇し始めると、その後のポジションサイズを一定の割合で減らし始めます。購買力がますます枯渇するにつれて、0.1% に達するまで新しいポジションのサイズを減らし続けます。その時点で、私は次のポジションの購買力を減らすのをやめ、購買力が尽きるまで待ちます。このアルゴリズムを最適化するのに数年かかりましたが、非常にうまく機能しており、購買力が尽きるのは月に 1 回程度です。
- ジェイソン
- - オリジナルメッセージ -
- From: Weidong Ruan < wdruan@… >
- 送信日: 2010 年 8 月 16 日月曜日、午後 5 時 18 分
- 宛先: TWSAPI@yahoogroups.com
- 件名: [TWS API] DT システムの購買力の最大使用量
- こんにちは
- DT システムのアカウント購入力がなくなる前に、他に何をするか
- より大きな電力自体を購入することを除いて、条件を確認する必要があります
- ゼロ？在庫がなくなる前に、次の注文拒否エラー メッセージが表示されました。
- 購買力。ご提案をお待ちしております。ありがとうございます。
- ID: 919 | エラーコード: 201 | エラー メッセージ: 注文は拒否されました – 理由: 注文は正しいです
- 受け入れられません。
- 希望のポジションを獲得するために
- ローン価値を含む資本 [95269.89 USD]
- 超えなければなりません
- 当初証拠金 [95902.93 USD]
- [このメッセージのテキスト以外の部分は削除されました]
- [このメッセージのテキスト以外の部分は削除されました]
- 返事
- エレノサンドバル
- 2010 年 8 月 16 日
- ソースを表示
- アカウント データをサブスクライブすると、TWS から送信されるデータのフィールドは約 102 になります。それらの中には、「Indian Stock Haircut」や「lookAheadAvailableFunds」などの非常に珍しい名前が付いているものもあります。
- あなたの質問に役立つのは、「購買力」や「利用可能な資金」などのフィールドです。
- 私は先物取引をしているので、「InitialMarginReq」と「MaintMarginReq」にも興味があります。
- 私が取引する各契約について、私の API は、利用可能な資金から各契約の「クッション」と初期証拠金要件を差し引いたものを調べるため、たとえば東部標準時間の 9 時 30 分から 3 時 45 分の間に取引できる契約の数がわかります。
- EST 午後 3 時 45 分以降、IB はオーバーナイト証拠金要件に切り替わります。これは通常、日中要件の約 2 倍です。
- 株式とその証拠金要件についてはあまり役に立ちませんが、前述したように、約 102 のデータ フィールドがあるため、探している情報はそのうちの 1 つにあると思います。
- 幸運を、
- レノ
- メッセージ履歴を表示する
- 返事
- 維東
- 2010 年 8 月 16 日
- ソースを表示
- DT システムは株式専用で、午前 9 時 30 分から午後 2 時まで稼働します。
- システムは、アカウント データをサブスクライブした後、「BuyingPower」という名前の 102 フィールドのうちの 1 つを次のようにキャッチしました。
- if(key=="購買力")
- {
- m_BuyingPower = atof(val);
- }
- 買い注文を出す前に、システムは、m_BuyingPower から Shares*buyprice を引いた値が 5000 より大きいかどうかを確認します (常に 5000 ドルのスペースを残します)。そうであれば、注文に進み、m_BuyingPower から Shares*buyprice を差し引きます。それでもエラーが発生しますが、
- ID: 919 | エラーコード: 201 | エラー メッセージ: 注文は拒否されました – 理由: 注文は受け付けられません。
- 希望のポジションを獲得するために
- ローン価値を含む資本 [95269.89 USD]
- 超えなければなりません
- 当初証拠金 [95902.93 USD]
- このロジックに何か問題がありますか?
- どうもありがとう、
- メッセージ履歴を表示する
- 返事
- カート・ビグラー
- 2010 年 8 月 17 日
- ソースを表示
- 一定の前提条件を前提にすると、あなたのロジックは「うまくいきます」。
- しかし、本当の問題は、購買力がマージンとどのように関係するかということだと思います。
- あなたは購買力をチェックしたので大丈夫だと言いますが、IBは購買力があると言っています。
- マージンを確認しましたが、問題ありませんでした。つまり、私の表面的な観察では、あなたは
- と IB は同じ言語を話していません。なぜかは直接はわかりません（
- 株の購入）これは機能しませんが、一部の株は
- この場合、購買力の概念は適用されません。
- いずれにしても、IB が (EWL とベースに基づいて) 計算する方法で計算できれば、
- マージン) そうすれば、努力するよりも、必要な結果が得られるかもしれません。
- 次に、購買力が証拠金とどのように正確に関係するのか、またいつ利益が得られるのかを推測してください。
- 模型が壊れる。
- しかし、実際に取引している株式の一部が証拠金を得ることができない場合 (ペニー株?)、
- それを知る方法が必要になるでしょう。購買力の法則を活用してみてはいかがでしょうか
- 値幅の大きい株式には単純な利用可能な資金を使用し、値幅のない株式には利用可能な資金を使用します。
- 株。
- -カート
- メッセージ履歴を表示する
- 返事
- 魏東偉東
- メッセージ 7/7、2010 年 8 月 17 日
- ソースを表示
- カートさん、ありがとう。貴重なご意見をありがとうございました。
[Q] openOrder / orderStatus / execDetails のシーケンスは？
[A] by カート
- ロン・ヒンチリー
- メッセージ 1/2、2010 年 7 月 31 日
- ソースを表示
- openOrder() は常に orderStatus() または execDetails() コールバックの前に来ますか?
- openOrder() の「ステータス」は orderStatus() の「ステータス」と同じですか?
- [このメッセージのテキスト以外の部分は削除されました]
- 返事
- カート・ビグラー
- メッセージ 2/2、2010 年 7 月 31 日
- ソースを表示
- 2010 年 7 月 31 日午後 7 時 22 分、「Ron Hinchley」< grocthis@… > は次のように書きました。
- > openOrder() は常に orderStatus() または execDetails() コールバックの前に来ますか?
- >
- > openOrder()の「ステータス」はorderStatus()の「ステータス」と同じですか？
- 私の知っている限りでは文書化されていないので、これに依存すると、
- 残念だった。
- しかし、はい、それは私の経験ではすべて真実であり、openOrder と orderStatus を再確認します。私
- 現在、前のメッセージの注文ステータスを使用し、他のメッセージは無視します。
- 1つ。
- Re execDetails わかりません。それは独自のものを持った非常に独立した存在です
- 私が仮定を立てるとは想像もできないような信頼性のなさ
- 作る必要はなかった。たとえば、私は次のような問題に対処する準備ができています。
- 予期しない execDetails があり、同様に予期した execDetails がありません。それで
- たとえば、タイムアウトの後、おそらく実行をリクエストするでしょうが、
- まだそのコードを実行していません。
- の順序に依存しない方法で状態をモデル化しようとします。
- 実行メッセージと注文メッセージ。しかし、私は現在想定するつもりです
- openOrder メッセージと orderStatus メッセージのペア (私が発見したり聞いたりしない限り)
- 例外。
- -カート
[Q] 注文のペースは？
[A]
過去の実験で覚えているのは、TWS に命令を送信した場合です。
ソケットのソケットが早すぎると、TWS は意図的かその他の方法で終了しません。
注文を受け付けています。アプリケーションの処理とは関係がありませんでした。
タイミング。3 つの注文を遅延なくソケットに送信すると、次のようになります。
結局注文は消えてしまいます。これが変わったなら素晴らしいことですが、私は
現在の状況がどうなっているのか確認したいと思いました。
—
私が覚えていることと、ジョーのメッセージからすると、TWS にはいくつかの特徴があります。
注文がソケットに到着するのが早すぎる場合に問題が発生します。
—
確認応答までの時間を測定します。TWS「合成」注文の場合
サーバーによってエミュレートされているため、私の記憶では「送信保留中」ステータスが表示されます。
正しく。取引所に送られると「スミット」ステータスになります。通常は
少なくとも Globex のような高速取引所では、遅延は 100 未満になります。
ミリ秒。より一般的には 60 ～ 70 ミリ秒程度です。
了承。何度も測りましたが、多少の誤差はあります
ばらつきはありますが、これは適切に調整された場合に達成できる速度です
システム。
—
注文に関する私の試練や艱難の一部を共有する取り組みとして、
IB の注文処理には常に問題がありました (少なくとも初期の頃から)
2008 年から 2009 年後半まで)、親/子の配置に問題が発生しました。
単一の親注文が単一のセットとともに発注される注文
括弧で囲まれた子供たち。すべての注文が次々に行われた場合（何もせずに）、
間に一時停止してください)、問題は (ある時点で) 明らかになります。
昨年、私はこの問題についてしばらくの間 IB サポートチームと話し合いましたが、
彼らはそれを修正したり、確実に再現したりすることができませんでした。テストを書きました
私のアプリケーションと同じように注文を作成するプログラム (紙取引で)
アカウント）を立て続けに作成しましたが、まだ再現できませんでした。
問題。テストで問題を適切に再現できたことは一度もありません
シナリオ。
この問題はペーシング違反ではなく、停止によって現れました。
子注文は TWS および「T」送信ボタンを通じて完全にはコミットされませんでした。
TWSは押されていない状態のままでした。これは（もちろん）本当にひどいものでした。
私の立場は守られていなかった（そして実際に何度か火傷を負った）。終わった
すべての注文を分析してこのシナリオかどうかを検出するコードを大量に追加します。
実際に発生するため、アプリケーションはキャンセルして再作成できます。
適切に注文しますが、若干の遅れが発生するため (後述)、問題が発生します。
決して起こらない。
私は米国株をトレードしており、システムでは平均して約 13 ポジションをトレードしています。
日 (少ない日もありますが、同時に 40 を超える日もありました)
ポジション）。注文間の遅延を使用していない場合、問題は
およそ2、3日に1回症状が現れます が、私はまったくゼロを見つけました。
韻や理由。私のやり方ですが、これまで一度もやったことがありません
この手法 (9,000 以上の取引) で失敗するのは、親を作成することです。
注文、200 ミリ秒遅延してから子ブラケット注文を作成します
すぐに (もちろん、ブラケット内の最終ストップ注文は
1つはtransmit=trueです）。
ジェイソン・サップ
—
これが私の2セントです:
私が最初に取引用の API のコーディングを開始したとき、mimic-TWS 注文サーバーを構築しましたが、注文サーバーと API が同じ PC 上で実行されている場合、TCP ソケットを介した通信中に実際にいくつかのタイミングの問題があることがわかりました。
ハングアップせずに動作させるために、あちこちに時間遅延を設ける必要がありました。
ただし、2台のコンピューターを使用した場合は問題はありませんでした。
たとえば、TWS が PC-1 で実行され、API とチャート プログラムが PC-2 で実行されている場合、「バスケット」注文を行うと、異なるシンボルに対する複数の買い/売り注文が連続して発行されます。 、遅延なく、注文実行データとオープン注文データはすべて TWS から返され、すべてが正常に機能します。注文が失われることはありません。
ただし、同じシンボルに対してブラケット注文などの他の注文を同時に行うことはありません。また、新しい注文を行うときに同じ orderID を使用することもありません。私はまだ「そこ」にいません。
個別のコンピューターを使用して戦略をテストし、オペレーティング システムの制限を排除または軽減することをお勧めします。また、さまざまなシンボルの「バスケット」注文を発行してみて、機能するかどうかを確認してから、ブラケット注文などを実行してください。
幸運を、
レノ
—
はい、私もジェイソンとまったく同じ問題を経験していました。
親注文を送信し、最後に子ブラケット注文をいくつか送信します。
1 つはtransmit=trueに設定されています。私も1日に約10〜15回の取引を行っていました
注文間に 300 ミリ秒の遅延がなければ、多くの場合、一部の注文は
TWS に表示されますが、「T」送信ボタンは押されません。
API を通じて次のような応答も返されます。
ID ="" " の注文が見つかりません。
一貫して問題を再現できましたが、役に立ちませんでした。今日も
300 ミリ秒の遅延 まれにこの問題が発生することがあります。
–ロブ・テルピロウスキー
[Q] 提出した注文を変更するにはどうすればよいですか？
[A1] カート著
同じ Order 構造を使用して placeOrder を再度呼び出すだけです。もし
オーダー ID (およびクライアント ID) が同じであるため、
既存の注文。
–カート
[A2] カート著
注文構造 (または注文に必要なすべての情報) を保持するだけです。
再作成して)、同じ orderId で placeOrder を再度呼び出すと、次のようになります。
変更要求として解釈されます。すべてのフィールドを変更できるわけではありません。価格
通常、フィールドは変更でき、指値注文は成行に変更できます。私は
数量も変更できると思いますが、私は変更したことがありません。
注文の変更には通常、キャンセル料が発生することに注意してください。
ただし、その注文（または同じ日の別の注文）が最終的にあなたを執行する場合は、
キャンセル料に対する約定クレジットが得られる場合があります。しかし、契約は
実行クレジットは以前は素晴らしかったのですが、最後に見たものはほとんど価値がありませんでした。
キャンセル・変更手数料は取引所により異なります。一部の取引所では手数料がかかります
これらについては何もありませんが、指示された順序は一般的により高いものになります。
手数料（そして場合によっては実行力が低下する可能性もあります）。
-カート
[A3] btw12342001 による ブラケット順序の変更:
価格を変更して再送信することでブラケット注文のレッグを変更しても、なぜ機能しないのか疑問に思っていました。約定なしで価格を通じて取引されます。TWS には更新ボタンがあり、ログの注文ステータスが「事前送信済み」であることに気付きました。明らかに、重要なのは false だったものに対して send=true を設定することです。テストしたところ、これはうまくいきました。
当然のことかもしれませんが、しばらくの間、それが私を悩ませました。
[Q] エラー: 価格がこの契約の最低価格変動に準拠していません
[A] by エド
ES は 0.25 刻みで移動するため、ストップ価格は の倍数である必要があります。
0.25。たとえば、stop を 1092.60 に設定すると、次のようなエラーが発生します。
見てる。これは通常、ストップ価格が次のような結果である場合に発生します。
インジケーターの計算。契約ティック額への四捨五入は通常、
ソリューション。
- また -
[q] 簡単な質問ですが、emini の場合、ストップ価格は最小価格変動を確認する必要がありますか、それとも LMT 価格だけを確認する必要がありますか?
[a]価格のいずれかがティック サイズの正確な倍数ではない場合、ご注文は拒否されます。
[Q] reqOpenOrders がすべてのオープン注文を返さない場合があります。なんと?!
[A] https://groups.io/g/twsapi/topic/4044893#21013
[Q] reqExecutions 呼び出しを通じて以前に約定した注文を取得できません
[A] by カート
- やあ！
- reqExecutions 呼び出しを通じて以前に約定した注文を取得できません。日付文字列を m_time に入れて呼び出しに渡して、ExecutionFilter を試してみました。クライアント ID を「-1」に設定するなど、使用したパラメーターに関係なく、呼び出しは今日のフィルを返します。昨日のフィルを獲得するイベントはできませんでした。したがって、ここで何か間違ったことをしているのではないかと思います。
- reqExecutions() 呼び出しを使用して以前のフィルを取得することに成功した人はいるでしょうか? ExecutionFilter ではどのような値を使用すればよいですか?
- 前もって感謝します。
- 返事
- カート・ビグラー
- 2010 年 5 月 26 日
- ソースを表示
- reqExecutions はチェックインした日数によってフィルタリングされているようです
- API フィルターでの指定に関係なく、TWS の「取引」ウィンドウ。
- いずれにせよ、先週までに限定されると思います。
- ゲートウェイを使用している場合、指定する方法はないと思います。
- フィルターを使用すると、デフォルトが当日のみになると誰かが報告したと思います。
- その点でTWSに似ているなら、「今日」の日はあなたがいる日かもしれません。
- 始めました。前日から TWS を実行すると、何も得られないことがわかりました。
- 昨日のチェックを外して今日の取引にチェックを入れるまで約定情報が表示されます
- 窓。
- 詳細については、前回のアーカイブで確認できます。
- 数ヶ月。
- -カート
- メッセージ履歴を表示する
- 返事
- イベントトレーダー
- 2010 年 5 月 26 日
- ソースを表示
- こんにちは、カートさん
- 早速のお返事ありがとうございます。おっしゃるとおり、「取引」ページで「すべて」オプションを指定し、ページを開いたままにしておくと、フィルター パラメーターに関係なく、API を使用して「取引」ページ内のすべての取引を取得できます。TWS 取引ページは、そのページ内のすべての取引を API 呼び出しに渡すだけのようです。これは IB API 部分の不適切な設計です。
- フィルターがアカウント管理の flex ステートメントのように動作できることを期待していました。
- メッセージ履歴を表示する
- 返事
- カート・ビグラー
- メッセージ 4/4、2010 年 5 月 26 日
- ソースを表示
- ありがとう、取引ウィンドウを開いたままにしておく必要があることを忘れていました。
- たった今テストしました。TWSを一晩実行したままにし、その後
- 昨日の取引しか取得していないということは、おそらく私が取引を*去った*ことを意味します
- 窓が開いている。それ以外の場合は、おそらく (未定) 取引ウィンドウが
- たとえ前日に開始されたとしても、今日にチェックを入れた状態で常に開きます。
- はい、これは和解したい人にとって間違いなく深刻な問題です
- すべて。また、ダウンロード可能なステートメントはそうではありません（少なくとも使用されていません）
- to) API で使用されるのと同じ形式の実行 ID を使用します。
- 契約の説明に基づいて関連付けますが、これには少し時間がかかると思います
- プログラム的にはさらに面倒です。という問題にはアプローチしていない
- コンセプトとしてはシンプルであるべきなので、まだ和解していますが、これらの小さなことは
- 不具合があると面倒になります。
- -カート
[Q] 開始時間、終了時間、その他のオプションを指定して vwap 注文を送信するにはどうすればよいですか?
[A] by rfcd453
現在のドキュメントには記載されていないため、その方法は次のとおりです (Java)。
Contract m_contract = new Contract();
Order m_order = new Order();
Vector m_algoParams = new Vector();
TagValue m_tagvalue1 = new TagValue();
TagValue m_tagvalue2 = new TagValue();
TagValue m_tagvalue3 = new TagValue();
TagValue m_tagvalue4 = new TagValue();
TagValue m_tagvalue5 = new TagValue();
m_tagvalue1.m_tag = "maxPctVol";
m_tagvalue1.m_value = ".01";
m_tagvalue2.m_tag = "startTime";
m_tagvalue2.m_value = "14:00:00 EST";
m_tagvalue3.m_tag = "endTime";
m_tagvalue3.m_value = "14:30:00 EST";
m_tagvalue4.m_tag = "allowPastEndTime";
m_tagvalue4.m_value = "1";
m_tagvalue5.m_tag = "noTakeLiq";
m_tagvalue5.m_value = "1";
m_algoParams.add(m_tagvalue1);
m_algoParams.add(m_tagvalue2);
m_algoParams.add(m_tagvalue3);
m_algoParams.add(m_tagvalue4);
m_algoParams.add(m_tagvalue5);
m_contract.m_symbol = "AAPL";
m_contract.m_secType = "STK";
m_contract.m_exchange = "SMART";
m_contract.m_currency = "USD";
m_order.m_action = "SELL";
m_order.m_totalQuantity = 100;
m_order.m_orderType = "MKT";
m_order.m_algoStrategy = "Vwap";
m_order.m_algoParams = m_algoParams;
m_client.placeOrder(orderID, m_contract, m_order);’
[Q] 相対順序送信問題
[A] 基本的に答えはありませんでしたが、ポート (および相対順序の定義) は次のとおりです。
魏東偉東
2010 年 7 月 22 日
ソースを表示
こんにちは、
私のアプリケーションから送信された相対順序は TWS 上に存在しますが、送信しません。
TWS でこの注文に対して T をクリックすると、問題なく完了します。
成行注文、指値注文は私のアプリケーションでうまく機能します。何か問題があっても
次の機能? ご提案をお待ちしております。ありがとうございます。
void CClient2Dlg::placeRelativeOrder(CString symbol, int iOrderID, int
orderquantity)
{
Contract contract;
contract.conId = 1;
contract.symbol = symbol;
contract.exchange="SMART";
contract.secType = "STK";
contract.currency="USD";
Order order;
order.totalQuantity = orderquantity;
order.orderType = "REL";
order.action = "BUY";
order.lmtPrice = 0;
order.auxPrice = 0.01;
order.transmit = true;
m_pClient->placeOrder( iOrderID, contract, order);
}
（引用）
相対 (別名: プライマリに固定) 注文は、トレーダーが National Best Bid and Offer (NBBO) よりも積極的な価格を求める手段を提供します。トレーダーは、流動性プロバイダーとして機能し、現在の最良の入札およびオファーよりも積極的な入札およびオファーを行うことにより、注文を履行する確率を高めます。相場は市場の変動に応じて自動的に調整され、積極的な姿勢を維持します。買い注文の場合、入札額はより積極的なオフセットによって NBB に固定され、NBB が上昇すると入札額も上昇します。NBB が下がった場合、入札はさらに積極的になり実行されるため、調整はありません。販売の場合、オファーはより積極的なオフセットによって NBO に固定されており、NBO が下降すると、オファーも下降します。NBO が繰り上げた場合、オファーはより積極的に実行されるため、調整はありません。オフセットに加えて、絶対上限を定義することもできます。これは指値価格のように機能し、指定されたレベルを超えてまたは下回って注文が実行されるのを防ぎます。
パーセントオフセットを使用して相対注文を送信すると、オフセットと一致するだけでなく、適用されるティック増分にも準拠した注文価格を計算するよう当社に指示することになります。したがって、適切なティック増分に四捨五入された注文価格を計算します (たとえば、1.00 ドルを超える価格で取引される米国株のペニー)。買い注文は許容可能なティック増分に最も近い値に切り捨てられ、売り注文は切り上げられます。
（引用終わり）
【Q】ポストオンリー注文をAPIで送信するにはどうすればよいですか？
[A] by Joshオンラインで表示/返信 (#44951)
2020 年 7 月 28 日に追加
残念ながら、post-only 属性は TWS でのみ使用できます。
[Q] 価格管理アルゴポップアップの抑制方法
API 経由で注文を送信するたびに、TWS でポップアップが表示され、IB には価格管理アルゴリズムがあり、注文が取引所によってキャンセルされた場合に役立つことを行うことができます。ポップアップには、この注文またはその日のこのタイプのすべての注文に対して有効にするオプションがあります。毎朝ポップアップが表示されないように、API を通じてこの機能を有効にする方法はありますか? TWS API ドキュメント全体で「Price Management」を検索しましたが、それへの参照は見つかりませんでした。 |
[A] by Noreply.section@gmail.comオンラインで表示/返信 (#44163)
2020 年 10 月 3 日に追加
この状況に関連する可能性のあるブール値フィールド order.usePriceMgmtAlgo があります。 — alpha pmularien@gmail.com による更新 — このブール値フィールドは私にとっては役に立ちました。これがポップアップを防ぐ唯一の方法であることがわかりました。 |
[Q] 注文のレバレッジ量に関する情報はどこで入手できますか? 「Order」または「Execution」クラス内にプロパティ (レバレッジなど) が見つかりません。
[A] by Joshオンラインで表示/返信 (#44307)
2020 年 10 月 3 日に追加
アカウント値「Leverage-S」を通じてアカウントのレバレッジが報告されています。アカウントのレバレッジの変更は注文情報とともに報告されません。 — S (「レバレッジ-S 」の) は実際には「有価証券」を表します。IB ユニバーサル アカウントでは、証券セグメントとコモディティ セグメントのアカウント値は、TWS アカウント ウィンドウと API で別々にレポートされます。 |
[A2] by Adamオンラインで表示/返信 (#44315)
取引執行そのものでは、どのようなレバレッジを獲得したかを知ることはできません。以下のような可能性があります。 (1) 最良の方法: 取引する前に whatif 注文を送信すると、取引した場合に得られるレバレッジを計算できる十分な情報が (OrderState を通じて) 返されます。WhatIf を使用するには、API 9.76 以降が必要です (古いバージョンでは「後」データのみが提供され、競合状態が発生するためです。そのため、9.76 で修正されました)。1 株の whatif 注文を出し、InitMarginChange をボードのロット サイズで割って 1 株あたりのレバレッジ価格を取得します (複数の通貨で取引するため、それを通貨係数で割って、1 株あたりのレバレッジ価格を取得します)米ドル）。レバレッジは、現在の 1 株あたりの価格をレバレッジ価格で割ったものになります。私の目的には十分な速さです。 (2) 一度に 1 つの注文だけを送信する場合は、合計口座価値タイプ「InitMarginReq」を事前に保存し、その後と比較することで、事後の合計口座価値への影響を計算できると思いますが、取引を行うには、アカウント値の更新（取引が完全に実行されたことが確認された場合のみ）を「検索」し、更新が完了したらそれを読んだことを覚えておくために変数にマークを付ける必要があります（そうすることで、探し続けないでください）。ただし、前後の状態を読み取って計算しているときに、順序が異なるために実行が行われようとしていないことを認識できる必要があります。大量に取引する場合はこの方法ではできないので、上記の(1)を使用します。 (3) 静的なテーブルを使用して調べることもできますが、マージンの状況は日中に時々変化するため、常に正確であるとは限らないと言われています – したがって、それが目的に適さない場合は、 、それならやめてください。 |
[Q] 逆指値注文がいつ発動されたかを知るにはどうすればよいですか?
[A] by ds-avatar、Josh、Ricart Kingオンラインで表示/返信 (#44556)
2020 年 10 月 3 日に追加
注文がトリガーされた場合、送信済みステータス更新メッセージが生成されるはずだと思います。そのようなメッセージはなかったので、それがトリガーされなかったと信じたいと思います。市場条件が技術的に満たされていないため、ストップが非アクティブのままになる場合があります。これは Order.TriggerMethod フィールドの値に依存する可能性があり、特にトリガーメソッドがダブルチェックを使用している場合、ストップレベルを突破したように見える場合でも、流動性の低い株式で発生する可能性が高くなります。私の理解では、Order.TriggerMethod フィールドは IB 独自のルーティング (SMART) に対してのみ機能し、実際のトリガー条件は API ドキュメントの簡単な説明を超えてかなり複雑であるようです (TWS ユーザーで「条件付き注文の作成」というタイトルのページを探してください)一部のトリガーの追加の技術要件については、ガイドを参照してください)。 — 私は ds-avatar に同意します。「送信済み」ステータスが表示されない場合は、トリガー条件が満たされていません。
[child,trigger] が [trigger] に変わるという事実は、親注文が完全に約定されたことを単に反映しているため、子注文はもはや子ではありません。トリガー条件が満たされるのを待っている、事前に送信された注文にすぎません。
なぜトリガーが発動しなかったのかは全く別の問題です。IB になぜ起動しなかったのか尋ねてみる価値はあるかもしれません。
externalRth=[true] になっているのはわかりますが、タイムゾーンがわからないため、その時点で実際に RTH の外にいたかどうかはログからわかりません。もしそうなら、それが問題かもしれません。RTH の外でトリガーが起動しないという問題があったことを覚えていますが、これに関して断定的なことを言えるほどの自信はありません。
リチャード — 米国株の stp lmt や OCA グループ注文などの非ネイティブの注文タイプは、条件が満たされるまで IB サーバーに保持され、条件が満たされてから初めて取引所に送信されます。 したがって、非ネイティブの注文タイプの注文ステータスは、アクティブであっても「PreSubmitted」のままになります。 (PreSubmitted は TWS の青色の注文ステータス色に対応します) |
【Q】注文制限について
[A] by IB
2021 年 12 月 18 日に追加
TWS API v9.72+以降: 注文制限: TWS API の固有の制限である 1 秒あたり 50 メッセージは、TWS に送信される注文数が 1 秒あたり最大 50 であることを意味しますが、これ以上の API のみの制限はありません。ただし、Interactive Brokers は、IBKB の記事「注文効率の最適化に関する考慮事項」で詳しく説明されているように、ユーザーに注文効率率 (OER) を監視することを要求しています 。 OER = (注文送信 + 注文修正 + 注文キャンセル) / (約定注文 + 1) さらに、IB では、アカウントごと、サイドごと、契約ごとに最大 15 件のアクティブな注文が許可されることに注意してください。 |
[Q] 市場時間前と時間外に注文するにはどうすればよいですか?
[A] by Joshオンラインで表示/返信 (#46634)
2021 年 12 月 18 日に追加
API の「Outside Rth」設定は、通常の取引時間の前後の両方に適用されます。互換性がないため、TWS 設定で「Pre-Open session」フラグがオフになっていることを確認する必要があります。 |
0 件のコメント :
コメントを投稿