リスク管理と注文のライフサイクル

この章は、次の 2 つのことを理解するのに役立ちます。注文が時々「処理されない」理由。そしてなぜ、通過した後でも「部分的に完了」したままになることがあります。重要な違いは、リスク管理注文の拒否と反対注文の拒否です。これらは、ライブのトラブルシューティングで最も一般的な落とし穴です。

ユーザーの皆様、シミュレーション取引における「取引なし」は、必ずしも戦略がシグナルを送信していないことを意味するわけではありません。ローカルのリスク管理によってブロックされているか、模擬証券会社が注文を受け付けていない可能性があります。リスク管理の拒否が「証券会社が機能不全に陥っている」ことを意味すると誤解しないように、これら 2 つの経路を個別に説明します。

0. 适用场景

  • これでライブを実行できるようになりましたが、「売れ残り/拒否/キャンセル」の場合に何が起こったのかを正確に判断する必要があります。

  • インターフェイスのプロンプト、ログ、注文ステータスを 同じ 説明可能なチェーンにリンクしたいと考えています。

1. 核心概念：两条「拒单」路径

多くのユーザーは、初めて注文拒否に遭遇したとき、「すべて証券会社に拒否されたのではないか」と思い込んでしまいます。 qteasy では、まず次のことを明確にしてください。

                    ┌─ 风控拒单：复核台打回，委托单未入库、未递柜台
策略信号 → 订单意图 ─┤
                    └─ 柜台受理拒单：已入库，券商同步回复「不收」，status=rejected
                              ↓（若受理成功）
                         异步成交回报 → partial-filled → filled

ライブ サブシステムでは、注文は戦略シグナルから最終執行までいくつかの段階を経ます: RiskManager (オプション) → ローカル注文作成 → ブローカー処理 → 約定レポート。以下の表は、考えられる 3 つの結果をまとめたものです。トラブルシューティングを行う場合は、まずカテゴリを「タイプ」列と照合し、次に「最初にどの部分を確認する」をクリックして対応するログを開きます。

列の意味: Type はパス名です。 表示される内容 はインターフェイス/戻り値の特性です。 注文テーブルにレコードはありますか? は、ローカル sys_op_trade_orders に新しい行が追加されたかどうかを示します。 最初に確認する場所 は、提案の最初の証拠です。

使用方法: CLI に「リスク ルールによって注文が拒否されました」と表示されたら、「リスク拒否」行を選択し、「risk_log」を確認します。注文リストに「拒否」が含まれ、ブローカー番号がない場合は、「カウンター拒否」行を選択します。

タイプ

何が見えますか？

注文書に記録はありますか？

最初に検索する場所

リスク管理による注文拒否

CLI 拒否の理由 (英語)。送信結果は空です {}

改行なし

risk_log、<RISK REJECTED>

拒否された注文に対するカウンターサービス

status=rejected の注文明細行があり、ブローカー番号が空です。

持っている

オーダーフォーム、トレース

申請が成功しました

submitted などの後にトランザクションが続く場合があります。

はい、通常は broker_order_id が付いています。

注文テーブル、trade_log

完全な比較表については、doc:6-trader-snapshot-gateを参照してください。

RiskManager は注文前の レビュー パネルのように機能します。組み立てたルール チェーン (ホワイトリスト、単一トランザクション制限、トランザクション期間など) に従って OrderIntent と AccountSnapshot を順番にチェックします。いずれかのルールが失敗すると、英語の reason および rule_id を伴う拒否である RiskDecision が生成されます。

承認された場合、qteasy は注文の作成と検証を続行し、ブローカーの submit_with_ack 関数に送信して、カウンターがそれを受け入れるかどうかを確認します。

2. 风控如何工作（用户视角）

ライブ取引中に注文する前に、RiskManager を Trader に設定した場合:

  1. Qteasy は現在の台帳に基づいてアカウントのスナップショットを組み立てます

  2. 「配置する注文」を評価のためにルール チェーンに送信します。

  3. 拒否: 注文は注文テーブルに書き込まれず、注文は仲介キューにも入力されません。英語の拒否は、システム ログと risk_log に書き込まれるためです。

  4. 承認: リスク管理なしで、以前と同様に送信を続けます。

RiskManager を渡さない場合、ローカル ルール チェーンはスキップされ、注文の作成と送信のプロセスが直接続行されます。動作は古いバージョンに近くなります。

2.1 ルールの例 (しきい値を理解しやすくするため)

RiskManager は、Trader が注文を送信する前にルール チェーンを評価します (レビュー デスクのチェックリストの項目にチェックを入れるなど)。以下の表は、rule_id と拒否理由を理解するのに役立つ、一般的なルール タイプとユーザーに表示される結果を示しています。 組み込みルールの完全なリストではありません (ルールは Python で組み立てられます)。

各列の意味: シナリオ はビジネス コンテキストを指します。 設定したルール はルールのセマンティクスを指します。 何が起こるかは、ライブセッションでのパフォーマンスを指します。

使用方法: CLI の英語の拒否理由の risk_log または rule_id (例: MAX_ORDER_QTY) を比較して類似のシナリオを見つけ、しきい値またはホワイトリストを調整します。

例: MAX_ORDER_QTY による拒否 → 対応する「単一トランザクション数量」行 → 代理人の数を減らすか、ルールの制限を増やします。

シーン

あなたが設定したルール

何が起こるのですか

ホワイトリスト

000001.SZ のみが許可されます。

000300.SZ に対する注文 → 拒否、ログにはリストにないことが示されています。

トランザクションあたりのトランザクション数

最大500株

501 株の購入リクエスト → 拒否; 500 株およびその他のリクエストが承認されました → 続行

取引時間

9:30～11:30、13:00～15:00のみ

昼休み中の注文 → 拒否

一日の取引量

1日の累計＋今回の取引限度額超過

拒否されました;超過していない → リリース

アセンブリ方法: Trader を作成する前に、Python で RiskManager([Rule 1, Rule 2, ...]) を構築して渡します。それ以外の場合は、ローカル ルール チェーンを閉じます。詳細については、:doc:2-configuration-and-run とチュートリアルを参照してください。

2.2 ユーザーに表示される英語の拒否理由の例

CLI/TUI には次のように表示されます。

Order rejected by risk rule [MAX_ORDER_QTY]: order quantity exceeds limit

意味: リスク管理ルール MAX_ORDER_QTY は、数量が制限を超えたことを示します。 risk_logで検索してください。<リスク拒否> 詳細を確認してください。

3. 订单状态生命周期

処理が正常に完了すると、注文は Live で通常のステータスを経ます (CLI orders またはログで確認できます)。

submitted → partial-filled → filled

次のようなことも考えられます。

submitted → canceled

処理が成功すると、注文はライブ セッションでいくつかの ステータス を経ます (CLI orders またはログ経由で表示されます)。これらのステータスは、「証券会社側で注文が進行している状況」を示しており、リスク管理の拒否（注文が送信されなかった場合）とは異なります。以下の表は、最も一般的なステータスを示しています。完全な列挙は、実行時の実際の出力の影響を受けます。

各列の意味: ステータス は英語のステータス名です。 意味は投資セマンティクスです。 注意していただきたいは、調査や確認のチェックポイントです。

使用方法: 特定の状態が長時間続く場合 → 「注意すべき点」の行を確認 → 必要に応じて、スクリプト D/E:doc:5-artifacts-and-troubleshooting に移動します。

状態

意味

何に注意すべきですか?

submitted

カウンターは注文を受け取りましたが、すべての取引が完了していません。

broker_order_id はありますか?

partial-filled

部分的な取引が完了しました。累積数量 < 注文数量。

累計取引高は増加していますか？

filled

累計取引量が注文量に達しました

保有資産と現金残高は更新されましたか?

canceled

注文がキャンセルされました

マーケットクローズまたは手動注文キャンセル後の最終状態

Often rejected

窓口サービス段階での拒否

ブローカー番号は通常は空です。 これはリスク管理命令の拒否ではありません。

調査アプローチ:

  • 「提出物は提出されていません」 → まずリスク管理と提出前検証を確認してください（§1 表）

  • 「常に部分的に満たされている」 → 取引返品が継続的に到着しているかどうかを確認します (§4)

4. 分批成交与全部成交

大規模な注文が複数のトランザクションに分割される場合、ステータスは最初は「注文の一部のみが約定されました」など、部分約定済みのままになります。 累積トランザクション量が目標注文数量に達すると、Qteasy はステータスを 満たされました に更新します。 部分約定ステータスが長期間続く場合は、取引データと目標数量を比較してください。場合によっては、単に市況またはデモ マッチングによって注文全体がまだ約定されていないことを意味する場合もあります。

5. 收盘后未成交订单

市場が閉まった後、qteasy は post_close タスクを使用して、その日のすべての未決注文を閉じます。

  • **submitted / partial-filled: これは、注文がカウンターに提出され、残りの金額が終了時に引き落とされたことを示します。最終状態は **canceled (キャンセル取引記録が存在する可能性があります) です。

  • created: これは、失敗した注文のローカルドラフトとみなされます (注文プロセスの中断や従来の問題など)。取引終了時には rejected に設定されます。これを日中の注文拒否と混同したり、キャンセル取引結果に書き込んだりしないでください。

あなたへ: 市場が閉じた後、内部 API 名を覚えていなくても、post_close ログと reconcile 調整出力をチェックして、輸送中の注文がルールに従ってクローズされたかどうかを確認してください。

6. 遇到异常时建议顺序

  1. CLI/TUI インスタント英語プロンプト (最初に rule_id または注文番号をメモします)

  2. risk_log: 存在しますか?<リスク拒否> (リスク制御パス)

  3. 注文および取引記録: ステータス シーケンス、broker_order_id が書き戻されるかどうか。

より体系的な決定木については、:doc:5-artifacts-and-troubleshooting の §3 を参照してください。

7. 快速判定清单

  • この注文は送信プロセスに入っていますか (注文テーブルまたはログで見つけることができますか)?

  • 送信されていない場合: risk_log またはインターフェイスで rule_id / reason を見つけることができますか?

  • 送信された場合: 対応するトランザクション結果はありますか?ステータスは累計金額と一致していますか?

  • 注文拒否のタイプは明確に区別されていますか: リスク コントロール (注文のないライン) とカウンター (拒否されたライン)

8. 相关跳转

  • 設定と実行: :doc:2-configuration-and-run

  • トラブルシューティングマニュアル: :doc:5-artifacts-and-troubleshooting

  • 注文の拒否とアクセス制御の詳細: :doc:6-trader-snapshot-gate

  • CLI コマンド: :doc:8-cli-trader-capability-matrix

  • デュアルパスチュートリアル: tutorials/8-live-trade-risk-and-broker-walkthrough.md