Das Framework trennt Forschung, Entscheidungslogik, Ausführung und Risikosteuerung voneinander. Dadurch bleibt erkennbar, welcher Teil des Systems eine Aussage erzeugt, welcher Teil sie in ein konkretes Handelsereignis übersetzt und welcher Teil anschließend das Risiko kontrolliert.
Die Trennung macht nicht nur sichtbar, wo eine Aussage entsteht, sondern auch, welches definierte Ergebnis jede Ebene an die nächste übergibt. So lässt sich ein Effekt fachlich der Schicht zuordnen, in der er tatsächlich entsteht.
Historische Markt- und Preisdaten, Datenqualität, Herkunft und später die genaue Intraday-Reihenfolge.
Kernbestandteile: OHLCV, Herkunft, Zeitstempel; Version 1 auf Tagesdaten, Version 2 mit Minuten-/Tickdaten.
Übergabe an Forschung: versionierter Datenzustand.
Einheitliche Tests über Märkte und Oszillatoren sowie synthetische Kontrollreihen zur Einordnung.
Kernbestandteile: 60 Oszillatoren, Pivotstruktur, Kontrollreihen und einheitliche Testregeln.
Übergabe an Decision Core: dokumentierter Testbefund.
Versionierte Regeln übersetzen Marktstruktur und Analysewerte in nachvollziehbare Entscheidungen.
Kernbestandteile: Richtung, Marktstruktur, Kontext, Filter und feste Regelversion.
Übergabe an Execution: regelbasierte Entscheidung bzw. Freigabe.
Einstieg, Ziel, Stop, Break-even, Trailing, Reihenfolge, Kosten und Slippage gehören in eine eigene Ebene.
Kernbestandteile: Entry, Ziel, Stop, Break-even, Trailing, Intraday-Reihenfolge, Kosten und Slippage.
Übergabe an APS: definierter Ausführungspfad.
Positionsgröße, Sicherung, Warnzustände, Deeskalation und kontrollierter Wiederanlauf eines Plans.
Kernbestandteile: Positionsgrößenstufen, High-Watermark-Sicherung, Warn-/Stopzustände und Neustartlogik.
Übergabe an Nachweis: Risikozustand und zulässiges Exposure.
Datenstand, Regeln, Testbedingungen, Versionshistorie und bekannte Grenzen bleiben mit den Ergebnissen verbunden.
Kernbestandteile: Versionen, Testbedingungen, Datenherkunft, Grenzen und nachvollziehbare Ergebniswege.
Ergebnis: prüfbarer Ergebnis- und Audit-Trail.
Der Decision Core beantwortet die regelbasierte Frage, welche Entscheidung aus den vorliegenden Daten und Regeln folgt. Ob sich diese Entscheidung unter realer Ausführung – nach Stops, Kosten und Slippage – wirtschaftlich trägt, ist eine andere Frage. Sie wird deshalb in einer eigenen Ebene geprüft.
Genau diese Trennung schützt vor einer häufigen Fehlinterpretation von Backtests: Eine hohe Trefferquote oder ein auffälliges Verhältnis von Gewinnern zu Verlierern ist noch keine Aussage über den monetären Profitfaktor oder eine real erzielbare Rendite.
Decision Core im Detail →Identische Daten und dieselbe Regelversion sollen identische Ergebnisse erzeugen. Änderungen werden nicht versteckt, sondern als eigene Version geprüft. KI kann bei Analyse, Dokumentation und Bedienung unterstützen; sie soll die Kernlogik nicht autonom verändern.
Der Decision Core ist die fachliche Ebene, in der aus Marktstruktur und Analysewerten eine konkrete, regelbasierte Entscheidung entsteht. Sein Ziel ist nicht, ein Ergebnis im Nachhinein zu optimieren. Stattdessen soll er eine zuvor definierte Logik so eindeutig abbilden, dass dieselben Daten und dieselbe Regelversion wieder zum selben Ergebnis führen.
Damit wird ein wichtiger Unterschied sichtbar: Entscheidungsqualität ist nicht dasselbe wie Handelsperformance. Erst die nachgelagerte Ausführung bestimmt, zu welchem Kurs ein Signal tatsächlich umgesetzt wird, wann ein Stop greift, wie sich Kosten auswirken und in welcher Reihenfolge Intraday-Marken erreicht wurden. Die Risikoschicht entscheidet wiederum, wie viel Kapital eingesetzt werden darf und wann ein laufender Plan reduziert oder beendet werden muss.
Version 1 bildet die strukturelle Entscheidung auf Tagesdaten ab. Version 2 soll zusätzlich den zeitlichen Ablauf innerhalb des Handelstags berücksichtigen. Genau dort entscheidet sich beispielsweise, ob Ziel oder Stop zuerst erreicht wurde und welche Kosten die theoretische Bewegung in der Praxis reduziert hätten.
Der Decision Core erzeugt eine regelbasierte Richtung bzw. Freigabe aus dem verfügbaren Daten- und Analysezustand.
Die Execution-Schicht legt Einstieg, Ziel, Stop, Break-even und Trailing fest und berücksichtigt die tatsächliche Reihenfolge der Kursbewegungen.
Erst nach Kosten, Slippage, Positionsgröße und Risikosteuerung entsteht eine Aussage über Gewinn, Verlust, Profitfaktor oder Drawdown.
Die Angriffsplan-Strategie ist eine eigenständige Risiko- und Money-Management-Logik. Sie wird auf eine bereits vorhandene Marktentscheidung aufgesetzt. Ihr Grundgedanke ist, profitable Phasen kontrolliert zu skalieren, erreichte Equity-Höchststände über Sicherungsmechanismen zu schützen und bei Verschlechterung nicht passiv weiterzuhandeln.
Exposure und Positionsgröße werden nicht beliebig erhöht, sondern über definierte Stufen und Freigabebedingungen gesteuert.
Der höchste bisher erreichte Planstand dient als dynamische Referenz. Ein Teil des Fortschritts soll dadurch gegen spätere Rückschläge geschützt werden.
Der verbleibende Risikopuffer wird in Zustände übersetzt, die von Information und Warnung bis zum verbindlichen Stopp reichen.
Ein umfangreiches Regelwerk legt fest, wie bei Stress, Verlustserien, reduzierter Reserve, Pausen und Wiederanlauf reagiert werden soll.
Die dokumentierte APS-Entwicklung reicht von einem Risikomanager-Prototyp aus dem Jahr 2013 über integrierte Arbeitsmappen und Simulationen 2017/2018 bis zu publizierten Vergleichstests 2019 und einer 16-Instrument-Portfoliofassung 2020. Diese Historie zeigt Entwicklungstiefe – ersetzt aber nicht die erneute, sauber isolierte Wirkungsprüfung in Version 2.
Das Ziel ist kein geschlossenes Monolith-System. Die fachlichen Schichten sollen klare Schnittstellen besitzen, damit ein institutioneller Nutzer vorhandene Daten-, Order- oder Reporting-Infrastruktur weiterverwenden kann. Die konkrete technische Umsetzung bleibt dabei eine Architekturentscheidung und ist nicht an einen einzelnen Software-Stack gebunden.
