Eine Datenklasse fasst Eingangsdaten gleicher Herkunft zusammen. Dazu gehören Preis, Referenzmarkt, Handelsvolumen, Positionierung, Terminstruktur und Fundamentaldaten. Konfluenz und Scoring hat gezeigt, dass mehrere Beobachtungen nur dann mehr wert sind als eine, wenn sie unabhängig sind, und dass drei Momentum-Indikatoren das nicht sind, weil sie dieselbe Rechenvorschrift verschieden glätten.
Die Herkunft der Daten ist daher bei der Beurteilung ihrer Unabhängigkeit zu berücksichtigen.
Sechs Herkünfte
Die übliche Einteilung – Trend, Momentum, Volumen, Volatilität – sortiert nach dem, was ein Indikator rechnet. Für die Unabhängigkeitsfrage ist die andere Sortierung die brauchbare: nach dem, woher seine Eingangsdaten kommen.
| Klasse | Inhalt | Woher |
|---|---|---|
| A – Preis | Eröffnung, Hoch, Tief, Schluss, Zeit | das gehandelte Instrument selbst |
| B – Referenzmarkt-Preis | dieselben Größen des zugrunde liegenden Marktes | Future, Aktie, Index |
| C – Echtes Handelsvolumen | Umsatz, relatives Volumen, VWAP, Volumenprofil | Referenzmarkt |
| D – Positionierung | Open Interest, seine Veränderung, Positionsberichte | Terminmarkt |
| E – Terminstruktur | Frontmonat gegen Folgemonate, Spreads | Futures-Kurve |
| F – Fundamentaldaten | instrumentspezifisch – Lager, Produktion, Makro | extern |
Welche davon es für ein bestimmtes Instrument überhaupt gibt, steht in Was in deinen Daten steckt. Hier geht es um die Folge daraus.
Zwei Stufen von Unabhängigkeit
Das Kapitel Konfluenz hat Preisstruktur und Preisdynamik als verschiedene Quellen aufgeführt. Nach der Einteilung oben sind beide Klasse A, was kein Widerspruch ist, sondern eine Verfeinerung. Es gibt zwei verschiedene Stufen:
Innerhalb einer Klasse trennen verschiedene Rechenarten durchaus etwas. Ein Strukturbruch und ein Momentumwert reagieren auf verschiedene Eigenschaften derselben Reihe, und sie können auseinanderlaufen. Drei Momentum-Oszillatoren können das nicht.
Zwischen Klassen ist die Trennung grundsätzlich. Kein Klasse-A-Indikator kann eine Klasse-C-Frage beantworten, egal wie er gerechnet ist. Die Information ist in den Eingangsdaten nicht enthalten.
Für die Zählung der Datenquellen gilt:
Sechs Indikatoren aus Klasse A sind eine Information, verschieden aufbereitet. Ein Klasse-A-Indikator und ein Klasse-D-Indikator sind zwei.
Mehrere Indikatoren auf derselben Kursreihe liefern unterschiedliche Auswertungen einer gemeinsamen Quelle. Ihre Übereinstimmung belegt deshalb noch keine unabhängige Bestätigung.
Der Nutzen der leeren Zeilen
Fehlende Klassen zeigen, welche Informationen eine Auswertung nicht berücksichtigen kann.
Ein Beispiel: Ein Terminkontrakt stellt Klasse D und E zur Verfügung – Open Interest und Terminstruktur –, die meist ungenutzt bleiben, weil die verbreiteten Werkzeugkästen auf Klasse A ausgelegt sind. Ein siebter Momentum-Indikator bringt dort nichts, was die ersten sechs nicht schon gesagt haben; ein Blick auf die Veränderung des Open Interest bringt eine Angabe, die im Preis nicht steht.
Umgekehrt erübrigt sich auf einem Instrument ohne echtes Volumen das Volumen-Indikatorenpaket. Nicht weil es schlecht wäre, sondern weil es dort auf einer Spalte rechnet, die etwas anderes zählt.
Der Datenvertrag
Die Angabe je Indikator, die daraus folgt: welche Klassen er braucht, welche optional sind, und was er ohne sie noch aussagt.
Das ist verwandt mit der Anwendbarkeits-Matrix und doch eine andere Frage. Die Matrix prüft die Serienform: Hat die Serie eine Volumenspalte? Der Datenvertrag benennt die Herkunft: Aus welchem Markt müsste diese Spalte kommen, damit der Indikator misst, was sein Name sagt?
Beide Angaben stammen aus derselben Deklaration – der Anforderungsangabe, die der Rechenkern je Indikator führt. Der Vertrag ist daraus abgeleitet und nicht zusätzlich aufgeschrieben; eine zweite Aufschreibung derselben Sache veraltete mit dem nächsten Registry-Eintrag.
| Datenklasse | Indikatoren | Woraus das folgt |
|---|---|---|
| A – Preis | 91 | alle; jede Rechnung der Registry setzt auf OHLC an |
| C – Echtes Handelsvolumen | 16 | needs_real_volume – die Rechnung verlangt Umsatz, keine Tick-Zahl |
| C mit Aggressorseite | 0 | needs_trade_direction – kein Registry-Indikator verlangt sie |
| B, D, E, F | 0 | Diese Klassen setzen eine zweite Eingangsreihe voraus — einen Referenzmarkt, Positionsdaten, eine Terminkurve, externe Kennzahlen. Die Registry nimmt eine Bar-Reihe entgegen und kann sie deshalb nicht verlangen. |
Abgeleitet aus applicability::data_requirementskestrel-chartkit 0.2.0+a6ae0ac
Die Übersicht zeigt folgende Einschränkungen:
Der weitaus größte Teil rechnet auf Klasse A allein. Das ist keine Schwäche, sondern die Bedingung dafür, dass diese Indikatoren auf jedem Instrument dasselbe messen. Ein Zusammenspiel aus fünf davon bleibt trotzdem eine Quelle.
Kein einziger Indikator verlangt die Aggressorseite – auch die kumulierte Volumendifferenz nicht. Ihre Fassung im Rechenkern schätzt die Richtung aus dem Verlauf der Bar, statt klassifizierte Einzelabschlüsse zu verlangen. Das ist eine verbreitete Näherung und benennt zugleich, was sie nicht ist: eine Messung. Eine Messung des tatsächlichen Deltas benötigt nach Handelsrichtung klassifizierte Abschlüsse. Diese Daten nimmt die hier verwendete Schnittstelle nicht entgegen.
Vier der sechs Klassen kommen überhaupt nicht vor. Referenzmarkt-Preis, Positionierung, Terminstruktur und Fundamentaldaten setzen eine zweite Eingangsreihe voraus; die Registry nimmt eine Bar-Reihe entgegen. Das ist keine Lücke der Ableitung, sondern eine Eigenschaft des Rechenkerns – und die Grenze, an der ein Zusammenspiel aus Indikatoren allein nicht weiterkommt.