BTCUSDT.BINANCE Perp 4H: Long-only-Trendfolge mit Taker-Kauf-/Verkaufs-Flow-Ungleichgewicht (3 Parameter, Order Flow + Trendbestätigung, ausschließlich tickaggregiertes Signal)

Long-only-Trendfolgestrategie für einen einzelnen Vermögenswert auf BTCUSDT.BINANCE Perpetual-Kontrakt unter Verwendung von 4H-Kerzen, wobei das Richtungssignal durch AGGREGATED TAKER ORDER FLOW (aus ergänzenden Daten von trade_ticks) bestimmt wird und nicht durch preisbasierte Indikatoren (die im Rahmen dieser Sitzung erschöpfend getestet wurden und laut Abbruchprotokoll empirisch größtenteils scheitern). Dies ist für das Factory-Portfolio eine tatsächlich NEW Mechanismusklasse — jede zuvor von mir geprüfte Strategie verwendet von OHLCV abgeleitete Signale (Preisniveaus, gleitende Durchschnitte, Renditen, Volatilität, Verhältnisse). Das Ungleichgewicht zwischen Taker-Käufen und Taker-Verkäufen ist INFORMATIONALLY DISTINCT vom Preis: Es misst, WHO Liquidität nimmt (aggressive Käufer gegenüber aggressiven Verkäufern), was die akademische Mikrostrukturliteratur (Easley-Kiefer-O'Hara PIN 1996, Easley-Lopez-de Prado-O'Hara VPIN 2012) als prädiktiv erwiesen hat, wo der Preis allein es nicht ist. Mechanismus: Bei jedem Schluss einer 4H-Kerze werden die Trade-Ticks der Kerze zu taker_buy_volume gegenüber taker_sell_volume aggregiert und das Ungleichgewicht berechnet: (Käufe - Verkäufe) / (Käufe + Verkäufe). LONG, wenn das Ungleichgewicht über 4H > +0.05 liegt (anhaltende Taker-Käufe) AND der Preis > 100-Kerzen-SMA ist (Trendbestätigung — der Flow muss mit dem Trend übereinstimmen). Ausstieg, wenn das Ungleichgewicht negativ wird OR der Preis unter SMA fällt. Order-Flow-Signale haben ein grundlegend anderes statistisches Profil als die gescheiterten Preismomentum-Signale: Sie beobachten direkt AGENT BEHAVIOR (welche Seite bereit ist, den Spread zu zahlen), statt INFERRING Agentenverhalten aus dem Preis abzuleiten (der die verzögerte Folge des Verhaltens ist). Nur 3 Parameter (deutlich unter der Obergrenze von 5 Parametern). Handelsfrequenz: ~40-80 Trades/Jahr über 6+ Jahre Binance-Trade-Tick-Daten → insgesamt 240-480 Trades → 16-32 OOS Trades pro Walk-Forward-Fenster, komfortabel über der Mindestgrenze von 5 Trades. Dies ist auch ein kritischer INFRASTRUCTURE TEST: Wenn trade_ticks-Daten korrekt in die Factory-Pipeline geladen werden, (die Datei data_specification.md führt sie unter catalog_data_types auf und das Flag subscribe_trade_ticks ist vorhanden), eröffnet dies eine völlig neue Mechanismusklasse für künftige Forschung. Falls das Laden scheitert (ähnlich der Finanzierungssatz-Lücke HL, die 9 Strategien blockierte), ist der Fehlschlag selbst aufschlussreich und macht ein lohnendes Infrastruktur-Ticket sichtbar, das eingereicht werden sollte.

Das Feedback verlangte eine DIAGNOSTIC, keine weitere Vermutung zum Schema. Ich habe data/supplementary/metrics/BTCUSDT/*.parquet direkt abgefragt: 334,643 Zeilen, Spalte taker_long_short_vol_ratio, Zeitstempel in ms; Zeilen pro Jahr 2023=12,096 / 2024=16,990 / 2025=14,688, und der Monat EVERY 2023-01..2025-12 enthält >=288 Zeilen (durchgehend, nur dünn besetzt im Vergleich zu den dichten 5-Minuten-2020-2022-Daten). Damit ist Prüfschritt (3) „Zeilen existieren nicht -> Ticket erstellen“ falsch, ebenso die Prämisse von Prüfschritt (2), dass ein Schemafehler im Loader vorliegt (mein Loader liest bereits genau diese Spalte und diesen Zeitstempelschlüssel). Die tatsächliche Ursache lag nachgelagert in meinem eigenen Code: die Veraltungsgrenze von 24h in _taker_imbalance. Ich habe dies offline anhand der echten Parquet-Datenablage überprüft, indem ich synthetische 4H-Balken über 2023-2025 gescannt habe: Die Grenze von 24h versieht nur 24.9% der Balken mit einem Taker-Signal (nach den Schwellen für Ungleichgewicht >0.05 und Preis >SMA sinkt dies auf die beobachtete Exponierung von ~2.79%), wohingegen eine Grenze von 14 Tagen 95.3% markiert — somit wird jedes Walk-forward-Fenster mit 3 Fenstern Trades enthalten. Die Funktion _taker_imbalance schreibt das nächste Verhältnis zum oder vor dem aktuellen Zeitpunkt bereits fort, wenn das zurückliegende 4h-Fenster leer ist; nur die Grenze verhinderte dies. Die Korrektur besteht daher aus einem einzigen Parameter (max_lag_hours=336), ohne ZERO Änderungen an Signal-, Ein-/Ausstiegs- oder Positionsgrößenlogik und ohne NO Preis-Proxy-Fallback. Dadurch bleibt der Order-Flow-Mechanismus erhalten und lässt sich endlich über den gesamten Backtestzeitraum testen. Hinweis für den Analysten: Die 2023-2025-Taker-Abdeckung ist tatsächlich dünner als 2020-2022 (~12% der 5-Minuten-Dichte), daher ist das fortgeschriebene Signal in diesen Jahren gröber; eine nachträgliche Ergänzung dichter 5-Minuten-Metriken für 2023-2025 würde die Genauigkeit verbessern, doch die Reihe ist von Monat zu Monat durchgehend genug, um das Walk-forward jetzt zu validieren.

Fehlgeschlagene deflated Sharpe mit extremer Overfitting-Wahrscheinlichkeit bei Versuch 1. DSR=0.3175 (vs. 0.95-Schwelle), is_significant=FALSE, wobei die optimierte Sharpe 1.9615 BELOW der 225-Trial-Expected-Max-Glücksschwelle von 2.3078 liegt, und — entscheidend — PBO=0.8664 (eine 87%-Wahrscheinlichkeit, dass die Parameterauswahl overfittet ist). Gemäß Framework ist ein niedriges DSR kombiniert mit einem sehr hohen PBO ein entscheidender Abbruch. Die Walk-Forward-Analyse bestätigt dies: is_overfitted=TRUE mit avg. IS 3.91, einbrechend auf avg. OOS 0.962, und OOS-Fenstern [2.76, 1.32, -1.19] (eines negativ). Das hohe probabilistic_sharpe (0.9964) ist die klassische PSR-vs.-DSR-Falle — es ignoriert die 225-Trial-Auswahl, die PBO/DSR bestrafen. Die echten positiven Aspekte (0-Sensitivitäts-Cliffs, positives sharpe_ci_low +0.4252, eine legitim bestandene Holdout-Ratio 1.213) messen lokale Stabilität und ein günstiges Forward-Fenster, nicht Signifikanz, und können ein 87% PBO bei ausgewählter Sharpe unterhalb der Glücksschwelle nicht aufheben. Nicht iterieren (Versuch 1 von 2, bereits Iteration 3): Die Sensitivität ist bereits sauber mit 0-Cliffs, daher hat der Sweep die stabile Region vollständig exploriert, doch OOS bricht weiterhin ein und PBO ist 0.87 — das Overfitting liegt in der Walk-Forward-SELECTION über 225 Trials, nicht in einem behebbaren Cliff, und mit nur 3 Kernparametern findet ein zweiter Best-of--225-Sweep dieselben overfitteten Konfigs wieder. Nicht revise_hypothesis: Taker-Flow-Imbalance ist ein Erprobungs-Mechanismus ohne promoted Sibling, das auf einem toten Target festsitzt, daher gibt es nichts Bewährtes, das auf ein neues Instrument umgelenkt werden könnte. Zusätzliche Vorsicht (keine bestätigte Ursache): Das ‚Order-Flow‘-Signal ist aus der spärlichen Metrik-taker_long_short_vol_ratio-Serie mit einem 14-tägigen Staleness-Carry-Forward abgeleitet statt aus rohen Trade-Ticks, sodass es während der 2023-2025-spärlichen Perioden ein einzelner Snapshot sein kann, der bis zu zwei Wochen fortgeschrieben wird — degradierend zu einem veralteten, informationsarmen Proxy, was die Prämisse ‚informationell distinkt vom Preis‘ untergräbt; kombiniert mit Long-only-BTC-Trend in einer bullisch geprägten 6-Jahres-Stichprobe (Basis-Alpha 0.02, benchmark_correlation 0.30) dürfte ein Großteil der Rendite Beta sein. FAILURE PATTERN: Ein genuin neuartiger Order-Flow-Mechanismus mit einem ungewöhnlich sauberen Profil (0-Sensitivitäts-Cliffs, positives CI-Low, ein bestandener Holdout) kann dennoch ein Best-of--225-Overfit sein — hier sind PBO 0.8664 mit DSR 0.32 und einer optimierten Sharpe (1.96) unterhalb der 2.31-Glücksschwelle, plus ein is_overfitted-Walk-Forward mit einem negativen OOS-Fenster, entscheidend. Ein sauberes Sensitivitäts-Grid und ein einzelnes günstiges Holdout-Fenster können eine Optimierung, deren Auswahl 87% wahrscheinlich overfittet ist, NOT retten; Neuartigkeit und lokale Stabilität sind keine statistische Signifikanz.

Nicht NOT optimieren — das Taker-Flow-Signal weist eine strukturelle 2023-2025-Datenlücke auf (Trades existieren nur in 2020-2022 und 2026; annual_returns überspringt 2023/2024/2025; exposure_pct 2.79%); ein Walk-forward mit 3 Fenstern würde daher ein ganzes Fenster mit null Daten durchlaufen, und der Order-Flow-Vorteil lässt sich nicht validieren. Die Änderung am Schema-Toleranz-Loader in Iteration 2 hat die Lücke nicht NOT geschlossen. Der nächste Schritt ist daher eine Diagnose, keine weitere Vermutung zum Schema: (1) Den Katalog/die ergänzende Datenablage direkt abfragen und bestätigen, ob `metrics` Taker-Kauf-/Verkaufsvolumen (oder taker_long_short_vol_ratio)-Zeilen für BTCUSDT 2023-01 bis 2025-12 PHYSICALLY EXIST vorhanden sind. Zeilenanzahl sowie tatsächliche Spaltennamen/Zeitstempelschlüssel für eine 2024-Stichprobe ausgeben. (2) Falls die Zeilen unter einem weiteren Schema existieren (Spalten- oder Zeitstempelschlüsselname, den der Loader weiterhin nicht erkennt), `_row_ratio`/`_row_ts`/`_load_taker_flow` so erweitern, dass sie diese lesen, und erneut ausführen; bestätigen, dass exposure_pct steigt und Trades 2023-2025 füllen. (3) Falls die Zeilen nicht NOT existieren (die Taker-Metrikreihe wurde für diese Jahre nie erfasst/nachträglich ergänzt), handelt es sich genau wie von der Hypothese erwartet um ein Infrastruktur-/Datenerfassungsproblem — der Strategiekode kann es nicht beheben. Daher ein Ticket zur Datenerfassung mehrjähriger Taker-Flow-Metriken erstellen und DO NOT diese Strategie erst dann erneut zur Optimierung einreichen, wenn die Daten den gesamten Backtestzeitraum abdecken. Eine Optimierung lohnt sich erst, wenn die Taker-Flow-Reihe 2020-2026 durchgehend abdeckt; der Mechanismus ist vielversprechend, derzeit aber nicht testbar.