Risikokontrolle und Auftragslebenszyklus

Dieses Kapitel hilft Ihnen, zwei Dinge zu verstehen: warum Aufträge manchmal nicht ausgeführt werden und warum sie selbst nach erfolgreicher Ausführung manchmal als „teilweise abgeschlossen“ gelten. Der entscheidende Unterschied liegt zwischen Ablehnung von Aufträgen aufgrund von Risikokontrollen und Ablehnung von Gegenaufträgen – dies sind die häufigsten Fehlerquellen bei der Fehlerbehebung im Live-System.

Lieber Nutzer, „Kein Handel“ im simulierten Handel bedeutet nicht zwangsläufig, dass die Strategie kein Signal sendet. Es könnte sein, dass die lokale Risikokontrolle den Auftrag blockiert hat oder dass der simulierte Broker ihn nicht annimmt. Wir erklären diese beiden Möglichkeiten separat, damit Sie nicht fälschlicherweise annehmen, dass eine Ablehnung durch die Risikokontrolle bedeutet, dass der Broker nicht richtig funktioniert.

0. 适用场景

Sie können jetzt live gehen, aber Sie müssen genau ermitteln, was in den Fällen „nicht verkauft/abgelehnt/storniert“ passiert ist.
Sie möchten Benutzeroberflächeneingabeaufforderungen, Protokolle und den Bestellstatus zu einer gleichen nachvollziehbaren Kette verknüpfen.

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

Viele Nutzer gehen bei der ersten Begegnung mit abgelehnten Aufträgen davon aus, dass diese alle von Brokerfirmen abgelehnt werden. Bitte klären Sie dies in qteasy zunächst auf:

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

Im Live-Subsystem durchläuft ein Auftrag mehrere Phasen vom Strategiesignal bis zur finalen Ausführung: RiskManager (optional) → Lokale Auftragserstellung → Brokerverarbeitung → Ausführungsbericht. Die folgende Tabelle fasst drei mögliche Ergebnisse zusammen. Bei der Fehlersuche ordnen Sie zunächst die Kategorie der Spalte „Typ“ zu und klicken Sie dann auf „Zuerst prüfen, welcher Teil?“, um das entsprechende Protokoll zu öffnen.

Spaltenbedeutungen: Typ ist der Pfadname; Was Sie sehen werden ist die Schnittstellen-/Rückgabewertcharakteristik; Gibt es einen Datensatz in der Auftragstabelle? gibt an, ob eine neue Zeile zur lokalen Tabelle sys_op_trade_orders hinzugefügt wurde; Wo zuerst prüfen? ist der erste Hinweis für den Vorschlag.

Anleitung: Wenn die CLI „Auftrag aufgrund von Risikoregel abgelehnt“ anzeigt, wählen Sie die Zeile „Risikoablehnung“ und überprüfen Sie das „Risikoprotokoll“. Enthält die Auftragsliste den Eintrag „abgelehnt“ ohne Brokernummer, wählen Sie die Zeile „Gegenablehnung“.

Typ	Was wirst du sehen?	Ist ein Eintrag im Bestellformular vorhanden?	Wo soll ich zuerst suchen?
Auftragsablehnung aufgrund von Risikokontrollmaßnahmen	CLI-Ablehnungsgrund (Englisch): Das Ergebnis der Übermittlung ist leer `{}`	Keine neuen Zeilen	`risk_log`、`<RISK REJECTED>`
Abwicklung von abgelehnten Bestellungen am Schalter	Es gibt eine Auftragszeile mit dem Status „abgelehnt“, aber die Brokernummer ist leer.	haben	Bestellformular, Nachverfolgung
Bewerbung erfolgreich	Auf `submitted` usw. kann eine Transaktion folgen.	Ja, und es hat normalerweise eine `broker_order_id`.	Auftragstabelle, Handelsprotokoll

Die vollständige Vergleichstabelle finden Sie unter:doc:6-trader-snapshot-gate.

Der RiskManager fungiert vor der Auftragserteilung als Prüfgremium: Er prüft nacheinander die OrderIntent und den AccountSnapshot gemäß der von Ihnen erstellten Regelkette (Whitelist, Limit für Einzeltransaktionen, Transaktionszeitraum usw.). Wenn eine Regel fehlschlägt, generiert er eine RiskDecision – eine Ablehnung, begleitet von der englischen Begründung (reason) und der Regel-ID (rule_id).

Wird die Bestellung genehmigt, erstellt und überprüft qteasy sie und übermittelt sie an die Funktion submit_with_ack des Brokers, um zu prüfen, ob der Zähler sie annimmt.

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

Bevor Sie während des Live-Handels eine Order platzieren, falls Sie RiskManager für Trader konfiguriert haben:

Qteasy erstellt Konto-Snapshots basierend auf dem aktuellen Hauptbuch.
Den „zu platzierenden Auftrag“ zur Auswertung an die Regelkette übermitteln.
Ablehnung: Aufträge werden nicht in die Auftragstabelle geschrieben und der Auftrag wird nicht in die Broker-Warteschlange aufgenommen; englische Ablehnungen sind darauf zurückzuführen, dass sie in das Systemprotokoll und das risk_log geschrieben werden.
Genehmigung: Einreichungen wie bisher fortsetzen, ohne Risikokontrolle.

Wenn Sie RiskManager nicht angeben, wird die lokale Regelkette übersprungen, und der Prozess der Erstellung und Übermittlung der Bestellung wird direkt fortgesetzt – das Verhalten entspricht eher der alten Version.

2.1 Regelbeispiel (zum besseren Verständnis der Schwellenwerte)

RiskManager wertet die Regelkette aus, bevor ein Händler eine Order absendet – ähnlich wie beim Abhaken von Punkten auf einer Checkliste. Die folgende Tabelle listet gängige Regeltypen und die für den Benutzer sichtbaren Ergebnisse auf, um Ihnen das Verständnis von rule_id und Ablehnungsgründen zu erleichtern; es handelt sich jedoch nicht um eine vollständige Liste der integrierten Regeln (Regeln werden von Ihnen in Python zusammengestellt).

Bedeutung der einzelnen Spalten: Szenario bezieht sich auf den Geschäftskontext; Die von Ihnen festgelegten Regeln beziehen sich auf die Regelsemantik; Was wird passieren bezieht sich auf die Performance in der Live-Sitzung.

Anwendung: Vergleichen Sie den risk_log oder die rule_id (z. B. MAX_ORDER_QTY) im englischen Ablehnungsgrund der CLI, um ähnliche Szenarien zu finden, und passen Sie dann den Schwellenwert oder die Whitelist an.

Beispiel: Ablehnung aufgrund von MAX_ORDER_QTY → entsprechende Zeile „Einzeltransaktionsmenge“ → Anzahl der Delegierten reduzieren oder Regellimit erhöhen.

Szene	Die Regeln, die Sie festlegen	was geschieht
Whitelist	Nur `000001.SZ` ist zulässig.	Bestellung für `000300.SZ` aufgegeben → Abgelehnt, Protokoll zeigt an, dass sie nicht auf der Liste steht.
Anzahl der Transaktionen pro Transaktion	Maximal 500 Aktien	Anfrage zum Kauf von 501 Aktien → Abgelehnt; 500 Aktien und alles andere genehmigt → Fortgesetzt
Handelszeiten	Nur von 9:30 bis 11:30 Uhr und von 13:00 bis 15:00 Uhr	Bestellungen, die während der Mittagspause aufgegeben wurden → Abgelehnt
Tägliches Transaktionsvolumen	Tägliche Gesamtsumme + Diese Transaktion überschreitet das Limit	Abgelehnt; Nicht überschritten → Freigegeben

Vorgehensweise: Bevor Sie den Trader erstellen, konstruieren Sie RiskManager([Rule 1, Rule 2, ...]) in Python und übergeben Sie ihn. Andernfalls schließen Sie die lokale Regelkette. Weitere Informationen finden Sie in der Dokumentation 2-configuration-and-run und im zugehörigen Tutorial.

2.2 Beispiel für einen für den Benutzer sichtbaren englischen Ablehnungsgrund

Die CLI/TUI zeigt dann etwa Folgendes an:

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

Bedeutung: Die Risikokontrollregel MAX_ORDER_QTY weist darauf hin, dass die Bestellmenge das Limit überschritten hat. Bitte suchen Sie in risk_log. Prüfen Sie die Details.

3. 订单状态生命周期

Nach erfolgreicher Verarbeitung durchläuft die Bestellung die typischen Statusphasen im Live-System (die Sie in der CLI unter orders oder in den Protokollen einsehen können):

submitted → partial-filled → filled

Es ist auch möglich, dass:

submitted → canceled

Nach erfolgreicher Verarbeitung durchläuft die Order in der Live-Sitzung mehrere Status (einsehbar über die CLI-Befehlszeilenschnittstelle orders oder in den Protokollen). Diese Status beschreiben den Bearbeitungsfortschritt der Order beim Broker und unterscheiden sich von einer Ablehnung aufgrund von Risikokontrollen (bei der die Order nie übermittelt wurde). Die folgende Tabelle enthält die häufigsten Status; eine vollständige Auflistung hängt von der tatsächlichen Ausgabe zur Laufzeit ab.

Bedeutung der einzelnen Spalten: Status ist die englische Statusbezeichnung; Bedeutung ist die Bedeutung der Investition; Worauf Sie achten sollten sind die Prüfpunkte für Untersuchung oder Bestätigung.

Anwendung: Wenn Sie längere Zeit in einem bestimmten Zustand feststecken → überprüfen Sie die Zeile „Worauf sollten Sie sich konzentrieren“ → gehen Sie gegebenenfalls zum Skript D/E:doc:5-artifacts-and-troubleshooting.

Zustand	Bedeutung	Worauf sollten Sie achten?
`eingereicht` usw.	Die Bestellungen sind am Schalter eingegangen, aber noch nicht alle Transaktionen wurden abgeschlossen.	Besitzt es eine `broker_order_id`?
D. Langfristig teilweise gefüllt	Teilweise abgeschlossene Transaktionen, kumuliertes Volumen < Auftragsvolumen.	Steigt das kumulierte Handelsvolumen?
gefüllt	Das kumulierte Transaktionsvolumen erreichte das Auftragsvolumen	Wurden Ihre Wertpapierbestände und Bargeldguthaben aktualisiert?
abgesagt	Bestellung storniert	Endgültiger Zustand nach Börsenschluss oder manueller Auftragsstornierung
Oft abgelehnt	Verweigerung während der Bedienungsphase	Die Brokernummer ist in der Regel leer; dies ist keine Ablehnung eines Risikokontrollauftrags.

Ermittlungsansatz:

„Es wurden keine Einreichungen vorgenommen“ → Überprüfen Sie zunächst die Risikokontrolle und die Vorabprüfung (§1 Tabelle)
„Immer nur teilweise gefüllt“ → Prüfen Sie, ob die Transaktionsrückgaben kontinuierlich eintreffen (§4).

4. 分批成交与全部成交

Wird ein großer Auftrag in mehrere Transaktionen aufgeteilt, bleibt der Status zunächst auf teilweise ausgeführt, also „Nur ein Teil des Auftrags wurde ausgeführt“. Sobald das kumulierte Transaktionsvolumen die Zielmenge erreicht, aktualisiert Qteasy den Status auf ausgeführt. Sollte der Status teilweise ausgeführt über einen längeren Zeitraum angezeigt werden, vergleichen Sie bitte die Transaktionsdaten mit der Zielmenge. Manchmal bedeutet dies lediglich, dass die Marktbedingungen oder die Demo-Abgleichung den gesamten Auftrag noch nicht vollständig ausgeführt haben.

5. 收盘后未成交订单

Nach Börsenschluss verwendet qteasy die post_close-Aufgabe, um alle ausstehenden Aufträge für den Tag zu schließen.

**eingereicht / teilweise ausgeführt: Dies bedeutet, dass die Order an den Schalter übermittelt und der Restbetrag zum Handelsschluss abgehoben wurde. Der Endstatus ist **storniert (es können Stornierungsdatensätze vorliegen).
created: Dies ist ein lokaler Entwurf einer fehlgeschlagenen Order (z. B. aufgrund eines abgebrochenen Ordervorgangs oder eines Altproblems). Der Status wird zum Handelsschluss auf rejected gesetzt. Er darf nicht mit Intraday-Orderablehnungen verwechselt werden und sollte auch nicht in die Ergebnisse der Stornierungstransaktion aufgenommen werden.

Für Sie: Nach Börsenschluss überprüfen Sie bitte die post_close-Protokolle und die reconcile-Abstimmungsausgaben, um zu bestätigen, ob die in Bearbeitung befindlichen Aufträge gemäß den Regeln abgeschlossen wurden, ohne sich die internen API-Namen merken zu müssen.

6. 遇到异常时建议顺序

CLI/TUI Sofortige englische Eingabeaufforderungen (Notieren Sie sich zuerst die rule_id oder Ihre Bestellnummer)
risk_log: Existiert es? (Risikokontrollpfad)
Auftrags- und Transaktionsdatensätze: Statussequenz, ob broker_order_id zurückgeschrieben wird.

Einen systematischeren Entscheidungsbaum finden Sie in §3 von :doc:5-artifacts-and-troubleshooting.

7. 快速判定清单

Wurde diese Bestellung bereits übermittelt (ist sie in der Bestelltabelle oder in den Protokollen zu finden)?
Falls nicht eingereicht: Können Sie rule_id / reason in risk_log oder der Benutzeroberfläche finden?
Falls eingereicht: Liegen entsprechende Transaktionsergebnisse vor? Stimmt der Status mit dem Gesamtbetrag überein?
Werden die Arten von Auftragsablehnungen klar unterschieden: Risikokontrolle (Zeile ohne Auftrag) vs. Gegenstelle (abgelehnte Zeile)?

8. 相关跳转

Konfiguration und Ausführung: :doc:2-configuration-and-run
Handbuch zur Fehlerbehebung: :doc:5-artifacts-and-troubleshooting
Details zur Auftragsablehnung und Zugriffskontrolle: :doc:6-trader-snapshot-gate
CLI-Befehl: :doc:8-cli-trader-capability-matrix
Tutorial mit zwei Lösungswegen: tutorials/8-live-trade-risk-and-broker-walkthrough.md