Forschungs- und Referenzkern
- 94 reale Instrumente
- 60 Oszillatoren
- 5.640 systematische Einzeltests
- synthetische Kontrollgruppe
- Tagesdaten 2009–2025
ENTWICKLUNG
Version 2 soll vorhandene Substanz überprüfen, erweitern und technisch belastbar machen.
Der Entwicklungsplan beginnt nicht mit neuen Funktionen, sondern mit einer kontrollierten Reproduktion des bestehenden Forschungsstands. Erst danach werden Intraday-Ausführung, Kosten, APS-Integration und zusätzliche Robustheitsprüfungen ergänzt. So bleibt nachvollziehbar, welcher Entwicklungsschritt welchen Effekt verursacht.
HEUTE
Was bereits vorhanden ist
Der Ausgangspunkt ist kein leeres Konzept. Vorhanden sind ein breit getesteter Excel-Referenzkern, die über viele Jahre entwickelte APS-Risikosteuerung, historische Simulationen und Vergleichspfade sowie eine umfangreiche fachliche Dokumentation. Nicht vorhanden ist heute eine vollständig integrierte, intraday-realistische Produktionsplattform.
Risiko- und Equity-Steuerung
- Entwicklungslinie seit 2013
- Stufen- und High-Watermark-Logik
- Warn- und Stopzustände
- taktische Regeln
- historische Simulationen und Vergleiche
Reproduzierbare Produktarchitektur
- unabhängiger Rechenkern
- Intraday-Ereignislogik
- Kosten und Slippage
- APS-Integration
- Vorwärts- und Belastungstests
PRÜFREIHENFOLGE
Die Reihenfolge ist wichtiger als eine möglichst schnelle Funktionsliste.
Jeder Schritt soll einen klaren Prüfgegenstand haben. Dadurch wird verhindert, dass mehrere Änderungen gleichzeitig eingeführt werden und anschließend nicht mehr erkennbar ist, welche davon ein Ergebnis verbessert oder verschlechtert hat.
P0
Referenzstand sichern
GrundlageDaten, Parameter, Rechenregeln und erwartete Ergebnisse werden als unveränderte Vergleichsbasis festgeschrieben.
P1
Datenqualität & Intraday-Daten
DatenImportwege, Vollständigkeit, Zeitstempel und Datenherkunft werden geprüft, bevor auf feineren Daten gerechnet wird.
P2
Version 1 unabhängig reproduzieren
ReproduktionDer bestehende Decision Core wird neu implementiert und Ergebnis für Ergebnis gegen den Referenzstand verglichen.
P3
Intraday-Ereignislogik
AusführungDie tatsächliche Reihenfolge von Kursmarken innerhalb eines Tages wird abgebildet, damit Ziel- und Stop-Ereignisse nicht aus Tagesdaten geschätzt werden müssen.
P4
Stops, Break-even, Trailing, Kosten
ÖkonomieRealistischere Schutz- und Ausführungsregeln sowie Kommissionen und Slippage werden separat ergänzt und gemessen.
P5
APS unter identischen Bedingungen integrieren
RisikoDer zusätzliche Beitrag der Risikoschicht wird gegen eine unveränderte Vergleichsvariante isoliert gemessen.
P6
Neue Daten & Walk-forward
RobustheitRegeln werden auf bislang nicht zur Entwicklung genutzten Daten und in fortlaufenden Vorwärtsfenstern geprüft.
P7
Produkt, API, Hilfe, Reporting
ProduktErst nach der fachlichen Stabilisierung werden Oberfläche, Schnittstellen, Hilfesystem und institutionelle Übergabeunterlagen vervollständigt.
WARUM INTRADAY?
Tagesdaten kennen Hoch und Tief – aber nicht zwingend deren Reihenfolge.
Wenn an einem Handelstag sowohl ein Kursziel als auch ein Stopbereich berührt werden, reicht die Tageskerze allein nicht aus, um sicher zu wissen, welches Ereignis zuerst eingetreten ist. Genau diese Reihenfolge kann darüber entscheiden, ob ein hypothetischer Trade als Gewinn oder Verlust gewertet wird.
Version 1
Strukturelle Entscheidungsvalidierung auf End-of-Day-Basis. Geeignet, um Konsistenz über Märkte und Analyseverfahren zu prüfen.
Version 2
Intraday-Daten lösen die Ereignisreihenfolge zeitlich auf. Stops, Ziele, Break-even und Trailing können dadurch realitätsnäher simuliert werden.
Ergebnis
Erst mit Ausführung, Kosten und Positionsgrößensteuerung entsteht eine belastbarere Aussage über den ökonomischen Verlauf.
NACH VERSION 2
Technische Validierung soll anschließend in reale Marktausführung überführt werden.
Backtests und Vorwärtsprüfungen beantworten andere Fragen als reale Orders. Deshalb ist nach einer ausreichend definierten Version-2-Ausbaustufe ein professionelles Handels- und Forschungsbüro als zusätzliche Beweisebene vorgesehen. Die Live-Phase beginnt bewusst erst nach der methodischen Revalidierung und wird nicht als Ersatz dafür behandelt.
Referenz & Reproduktion
Bestehende Logik sichern und unabhängig nachbilden.
Intraday & Ökonomie
Reihenfolge, Stops, Kosten, Slippage und APS isoliert prüfen.
Neue Daten
Out-of-Sample- und fortlaufende Vorwärtsprüfung.
Live-Validierung
Freigegebene Version mit realen Orders, Fills, Gebühren, Risiko- und Versionsprotokoll einsetzen.
Zusätzliche Evidenz, keine Abkürzung: Ein positiver Live-Zeitraum kann methodische Schwächen nicht rückwirkend heilen. Umgekehrt kann ein sauber validierter Backtest reale Ausführungsbedingungen nicht vollständig ersetzen. Beide Ebenen sollen deshalb getrennt dokumentiert und später gemeinsam bewertet werden.
ENTWICKLUNGSLINIE
Die heutige Architektur ist aus mehreren Entwicklungsstufen entstanden.
Die Zeitleiste unterscheidet zwischen Datenhistorie und belegten Entwicklungsschritten. Die Datenbasis reicht bis 2009 zurück; die nachweisbare APS-Systementwicklung beginnt mit dem Risikomanager-Prototyp von 2013.
2009–2025
Datenbasis
Historischer Datenzeitraum, auf dem der heutige Version-1-Referenzkern ausgewertet wurde.
2013
Risikomanager-Prototyp
Frühe Vorformen von High-Watermark-Trailing, Handelsfreigabe, Verlustserienstopp und hierarchischer Risikosteuerung sind dokumentiert.
2017–2018
APS wird integriert
Simulationen und Arbeitsmappen verbinden Stufen, High-Watermark-Systeme, Warnzustände, Drawdown-Auswertung und operative Steuerung.
2019
Publikation & Vergleichstests
Die APS wird in einer dreiteiligen TRADERS’-Coverstory öffentlich dokumentiert; aus demselben Zeitraum stammen mehrere Performancevergleiche.
2020
Portfolio-Ausbau
Die Entwicklung reicht bis zu einer zentralisierten 16-Instrument-Fassung mit Portfolio-Perspektive.
2026
Framework & Revalidierung
Research Core, Decision Core, Execution, APS und Dokumentation werden als getrennte Schichten neu geordnet und für eine reproduzierbare Version 2 vorbereitet.
KEINE VERSTECKTEN ZUSAGEN
Zeiträume und Technologien sind Planungsrahmen, keine Garantie.
Ein Entwicklungsprogramm hängt von Datenqualität, technischen Entscheidungen, Ressourcen, Lizenzen, Sicherheitsanforderungen und den Anforderungen eines möglichen Partners ab. Deshalb werden weder ein exaktes Fertigstellungsdatum noch ein bestimmter Software-Stack als unverrückbare Produkteigenschaft dargestellt.
Verbindlich ist die Prüfidee: erst Referenz sichern, dann reproduzieren, anschließend Erweiterungen einzeln messen und erst danach zur produktionsnahen Integration übergehen.
WEITER
Die technische Umsetzung folgt dieser Prüfarchitektur.
Fachbegriffe nachschlagen
Definitionen zu Profitfaktor, Intraday, Slippage, Walk-forward, High-Watermark und weiteren Begriffen finden Sie im Glossar.