← Alle Beiträge
03.09.2026 · 9 min

Warum LLM-Agents bei Wiener Mid-Caps den Spread falsch einschätzen

KI-Trader scheitern an illiquiden Nebenwerten: Warum Sprachmodelle die Spread-Dynamik an der Wiener Börse übersehen und wie hybride Mikrostruktur-Analyse Ihre Entscheidungen absichert.

Problem: Warum LLM-Agents bei Mid-Caps an der Wiener Börse den Spread falsch einschätzen

Sprachmodelle verarbeiten Text. Orderbücher sind keine Texte. Sie sind hochfrequente Zahlenströme mit strenger zeitlicher Ordnung. Genau dieser Unterschied führt dazu, dass LLM-Agents bei Nebenwerten an der Wiener Börse regelmäßig falsche Spread-Prognosen liefern.

Ein typisches Beispiel: Ein Mid-Cap wie Andritz, AT&S oder Mayr-Melnhof hat über weite Strecken des Handelstages ein dünnes Orderbuch. Auf der Kauf- und Verkaufsseite stehen nur wenige tausend Stück. Der Spread zwischen Geld- und Briefkurs schwankt stark, oft innerhalb von Sekunden. Ein LLM, das mit einer Zusammenfassung der letzten Minuten gefüttert wird, sieht einen Durchschnitt. Es erkennt nicht, dass sich die Liquidität schlagartig zurückziehen kann. Die Ausgabe klingt plausibel: „Der Spread liegt bei 12 Basispunkten, die Liquidität ist ausreichend." Aber diese Zahl ist geraten. Das Modell hat keinen direkten Zugriff auf das Live-Orderbuch und kann die zeitliche Abfolge der Änderungen nicht auswerten.

Hinzu kommt: LLMs sind anfällig für plausible, aber falsche Aussagen. Bei illiquiden Orderbüchern ist die Datenlage widersprüchlich. Einzelne große Orders rauschen wie Signale, sind aber oft nur taktische Platzierungen. Das Modell neigt dazu, aus diesen Ausreißern eine Geschichte zu konstruieren: „Ein großer Käufer tritt auf, der Spread wird sich verengen." In Wahrheit war es vielleicht eine Absicht, den Markt zu testen. Die statistische Basis fehlt.

Spoofing und Layering verschärfen das Problem. Manipulierte Orders werden platziert und wieder gelöscht. Für ein Sprachmodell, das nur Schnappschüsse sieht, entsteht der Eindruck von Nachfrage, die nie real war. Der Spread scheint sich zu verengen, obwohl echte Liquidität fehlt. Ein LLM kann diese Manipulation nicht als solche erkennen, weil es keine Order-Lifetime, keine Löschraten und keine Verteilung der Ordertypen auswertet. Es sieht nur eine Sequenz von Zahlen und Texten. Die Interpretation ist anfällig für Trugschlüsse.

Mein Punkt: Wer einen LLM-Agenten für die Orderbuch-Analyse bei Mid-Caps einsetzt, ohne die Rohdaten quantitativ vorzuverarbeiten, handelt mit einer Blackbox, deren Ausgabe nur scheinbar fundiert ist. Der Spread ist eine zentrale Kostenkomponente im Handel. Falsche Einschätzungen kosten direkt Geld.

Klassische Market-Microstructure-Modelle als Fundament: was bleibt unverzichtbar

Bevor man über Deep Learning spricht, sollte man die bewährten Werkzeuge der Marktmikrostruktur beherrschen. Für illiquide Nebenwerte an der Wiener Börse sind klassische Modelle oft die bessere Wahl.

Kyle’s Lambda misst die Preiswirkung einer Order. Je größer der Lambda-Wert, desto stärker bewegt eine Transaktion den Preis. Bei Mid-Caps ist Lambda typischerweise hoch. Ein LLM übersieht das leicht, weil es keine kontinuierliche Berechnung durchführt. Das Amihud-Maß setzt tägliche Rendite ins Verhältnis zum Handelsvolumen und erfasst so die Illiquidität über längere Zeiträume. Das Roll-Modell schätzt die implizite Geld-Brief-Spanne aus der Autokovarianz der Preisänderungen, selbst wenn keine direkten Orderbuchdaten vorliegen. Alle drei Kennzahlen sind einfach zu berechnen, benötigen wenig Daten und liefern robuste Signale für Liquiditätsengpässe.

Warum sind diese Modelle für die Wiener Börse relevanter als Deep-Learning-Ansätze wie DeepLOB? Weil DeepLOB auf großen, konsistenten Datensätzen trainiert wird. Die Wiener Börse hat für Mid-Caps schlicht nicht genug Handelshistorie mit ausreichender Frequenz. Ein Deep-Learning-Modell, das auf US-Large-Caps kalibriert ist, lernt Muster, die es in Wien nicht gibt. Die Folge ist Overfitting und schlechte Generalisierung. Klassische Modelle sind transparenter und liefern auch bei spärlicher Datenlage verlässliche Schätzungen.

Ein besonders robuster Prädiktor ist das Orderbuch-Ungleichgewicht, kurz OBI. Es setzt das Volumen auf der Kauf- und Verkaufsseite in Relation. Bei einem OBI von 60 zu 40 ist die Kaufseite stärker, was kurzfristig für fallende Spreads spricht. Dieser Indikator ist einfach, interpretierbar und reagiert sofort auf Manipulation: Spoofing-Orders erhöhen das nominelle Ungleichgewicht, verschwinden aber wieder. Wer OBI über Zeitfenster glättet und mit Löschraten kombiniert, erkennt manipulierte Buchsituationen. Ein LLM kann das nicht. Es kann nur Text darüber lesen, nicht die Rohverteilung sehen.

Mein Rat: Bevor Sie überhaupt einen LLM-Agenten einsetzen, bauen Sie ein quantitatives Fundament aus Kyle’s Lambda, Amihud-Maß, Roll-Modell und OBI. Diese Kennzahlen sollten bei jeder Orderbuch-Analyse als Referenz dienen. Das LLM bekommt sie als Kontext, nicht als Ersatz für eigene Prognosen.

LLM-Schwäche konkret: Token-Limits und Kontext-Verlust bei Echtzeit-Orderbüchern

Die technischen Grenzen von Sprachmodellen sind im Trading nicht nebensächlich. Sie bestimmen, was das Modell überhaupt wahrnehmen kann.

Ein typisches Mid-Cap-Orderbuch an der Wiener Börse erzeugt mehrere hundert Updates pro Minute. Jede Änderung an Preis oder Volumen ist ein Datenpunkt. Über einen Handelstag summiert sich das schnell auf hunderttausende Ereignisse. Ein LLM hat ein begrenztes Kontextfenster. Selbst bei den neuesten Modellen mit hunderttausenden Tokens entspricht das nur einem Bruchteil des gesamten Tick-Stroms. Man muss also aggregieren: auf Zeitfenster von Sekunden oder Minuten. Genau dabei gehen zeitliche Abhängigkeiten verloren. Ein Spread, der innerhalb von 30 Sekunden von 8 auf 25 Basispunkte springt und wieder zurückfällt, wird in einem 5-Minuten-Durchschnitt als 12 Basispunkte dargestellt. Das LLM sieht eine stabile Situation, die es nie gab.

Hinzu kommt ein zweites Problem: LLMs rechnen nicht zuverlässig. Wenn sie einen Spread schätzen sollen, greifen sie oft auf interne Muster aus dem Training zurück oder auf Zahlen, die im Kontext stehen. Bei dünnen Orderbüchern mit wenigen Trades gibt es kaum belastbare Referenzen. Das Modell erfindet dann plausible Werte. In Tests zeigen LLMs systematische Abweichungen bei der Berechnung einfacher Kennzahlen, wenn die Zahlen nicht als strukturierte Daten vorliegen. Ein bid-ask-Spread aus Tick-Daten im Format „10:00:00.123, Bid 42.50, Ask 42.58, BidVol 1200, AskVol 800" ist für ein Sprachmodell eine Textsequenz. Es muss die Zahl extrahieren, subtrahieren und interpretieren. Dabei passieren Flüchtigkeitsfehler, die bei quantitativen Modellen unmöglich sind.

Ein konkretes Fallbeispiel: AT&S vor der Veröffentlichung von Quartalszahlen. In den Tagen davor ziehen sich Market Maker zurück. Das Orderbuch wird dünner, die Spreads weiten sich auf das Doppelte. Ein LLM-Agent, der mit den letzten Handelsdaten gefüttert wird, erkennt den Trend nicht, weil er nur aggregierte Tageswerte sieht. Er prognostiziert einen normalen Spread von 15 Basispunkten. Tatsächlich liegt der Spread am Berichtstag bei 30 oder 40. Die Konsequenz: Der Trader kalkuliert die Transaktionskosten zu niedrig und nimmt eine Position ein, die bei Ausführung deutlich teurer wird. Das Problem ist nicht die Intelligenz des Modells, sondern die fehlende Verbindung zu Echtzeit-Mikrostruktur-Daten.

Hybrider Lösungsansatz: LLM als Analyse-Assistent, nicht als Vorhersagemodell

Aus meiner Sicht ist die Rolle von LLMs im Trading klar: Sie sollten erklären und zusammenfassen, nicht prognostizieren. Für Spread- und Liquiditätsprognosen gibt es bessere Werkzeuge.

Mein Vorgehen ist ein zweistufiger Aufbau. In der ersten Stufe laufen quantitative Modelle: klassische Mikrostruktur-Kennzahlen, optional ein DeepLOB-artiges Modell, wenn genügend Daten vorhanden sind, und einfache statistische Prädiktoren wie OBI über verschiedene Zeitfenster. Diese Modelle liefern Zahlen: aktueller Spread, erwartete Ausführungskosten, Liquiditätsrisiko-Score, Manipulationsindikator. Diese Zahlen sind überprüfbar und nachvollziehbar.

In der zweiten Stufe kommt das LLM dazu. Es bekommt die quantitativen Ergebnisse als strukturierten Kontext, zusammen mit Marktnachrichten, Unternehmensereignissen und regulatorischen Informationen. Seine Aufgabe: Handlungsempfehlungen in verständlicher Sprache formulieren. Beispiel: „Der OBI über die letzten 10 Minuten ist auf 0.32 gefallen und die Löschrate auf der Kaufseite ist doppelt so hoch wie üblich. Das deutet auf schwache Kaufunterstützung hin. Beim aktuellen Spread von 18 Basispunkten ist eine Limit-Order mit engerem Limit riskant." Das LLM erfindet nicht die Spread-Prognose. Es übersetzt die quantitativen Signale in eine klare Empfehlung.

Die Verschränkung sieht in der Praxis so aus: Ein Python-Stack bezieht Orderbuchdaten von der Wiener Börse oder Xetra über Bloomberg, Refinitiv oder direkte FIX-Feeds. Die Rohdaten werden normalisiert und in eine Zeitreihen-Datenbank geschrieben. Ein Microservice berechnet in Echtzeit die relevanten Kennzahlen. Diese Werte gehen in einen Kontext-Block, der an das LLM übergeben wird. Das LLM gibt eine textuelle Einschätzung aus, die der Trader sieht. Eine Rückkopplungsschleife ist nicht vorgesehen. So bleibt die quantitative Integrität erhalten, während das LLM die Kommunikation erleichtert.

Für Prop-Shops, die bereits DeepLOB-Modelle einsetzen, ist die Integration einfach: Das DeepLOB-Modell liefert eine Spread-Prognose. Das LLM erklärt, warum die Prognose von der klassischen Kennzahl abweicht, und formuliert Handlungsempfehlungen. So kombiniert man die Prognosekraft neuronaler Netze mit der Erklärbarkeit von Sprachmodellen.

Best Practices für Trader und Prop-Shops: So vermeiden Sie LLM-Fallstricke in Nebenwerten

Wenn Sie LLM-Agents in Ihrem Trading-Setup für illiquide Nebenwerte einsetzen wollen, gibt es klare Regeln, die ich aus der Beratungspraxis empfehle.

Erste Regel: Datenvorverarbeitung. Geben Sie niemals rohe Orderbuch-Ticks direkt an ein Sprachmodell. Normalisieren Sie die Daten in strukturierte Zeitreihen mit festen Intervallen. Reichern Sie jeden Zeitschritt mit Liquiditäts-Grundkennzahlen an: OBI, Amihud-Maß, gleitender Durchschnitt des Spreads, Anzahl der Trades, Löschrate auf beiden Seiten. Diese aggregierten Werte sind kompakt und enthalten die relevante Information. Das LLM bekommt ausschließlich diese aufbereiteten Daten, nicht den Roh-Feed. So vermeiden Sie Kontext-Überlastung und Rechenfehler.

Zweite Regel: Definieren Sie klare Grenzen für die LLM-Ausgabe. Das Sprachmodell darf nie ein Preis-Target oder eine Spread-Prognose als alleinige Quelle liefern. Seine Aufgabe ist die Erklärung und die Formulierung von Handlungsempfehlungen auf Basis der quantitativen Kennzahlen. Setzen Sie technische Schutzmechanismen: Das System zeigt dem Trader immer die zugrunde liegenden Zahlen an. Das LLM kann sie nicht überschreiben. So bleibt die Entscheidung beim Menschen, gestützt auf überprüfbare Daten.

Dritte Regel: Backtesting mit Zeitstempel-basierter Validierung. Ein klassischer Fehler ist der Look-ahead-Bias: Das Modell verwendet Informationen, die zum Zeitpunkt der Prognose noch nicht verfügbar waren. Bei LLM-Agents passiert das leicht, weil sie mit Zusammenfassungen trainiert sind und historische Muster einfließen lassen. Setzen Sie deshalb strikte Zeitstempel-Grenzen: Die Trainings- und Testdaten müssen exakt zu den Zeitpunkten geschnitten werden, an denen das Modell eine Prognose abgeben würde. Verwenden Sie Walk-forward-Validierung. Nur so erkennen Sie, ob das hybride System tatsächlich besser ist als eine einfache Kennzahl.

Häufiges Muster: Ein Prop-Shop baut einen LLM-Agenten, der aus Orderbuchdaten Handlungsempfehlungen generiert. Im Backtesting sieht es gut aus, weil der LLM unbeabsichtigt spätere Informationen verarbeitet hat. Live verliert das System Geld. Die Ursache ist fast immer Look-ahead-Bias. Deshalb sind Zeitstempel-basierte Tests unverzichtbar.

Vierte Regel: Kontrollieren Sie den Einfluss von News. LLMs sind stark in der Verarbeitung von Textnachrichten. Bei Nebenwerten kann eine einzelne Meldung den Spread explodieren lassen. Integrieren Sie News-Feeds kontrolliert: Geben Sie dem LLM nur Meldungen, die vor dem Prognosezeitpunkt veröffentlicht wurden. Und koppeln Sie die News-Verarbeitung an die quantitativen Signale. Eine Meldung allein ist kein Grund, eine Spread-Prognose zu ändern. Erst wenn OBI und Amihud-Maß die Meldung bestätigen, wird sie relevant.

Fünfte Regel: Setzen Sie klare Ausstiegskriterien für den LLM-Einsatz. Bei extrem illiquiden Titeln, an Tagen vor Bilanzen oder bei erhöhter Volatilität sollte das LLM gar keine Handlungsempfehlungen abgeben dürfen. Automatisieren Sie diese Sperrung über einen Liquiditätsscore. So verhindern Sie, dass das Modell in Situationen, in denen seine Erklärungen besonders unsicher sind, überhaupt aktiv wird.

Fazit & konkreter Handlungsplan

Hybride Systeme sind für das Mid-Cap-Trading an kleineren Börsenplätzen wie Wien der richtige Weg. Ein reines Sprachmodell scheitert an der Datenrealität. Ein rein quantitatives Modell ist schwer zu kommunizieren und verliert den Kontext. Die Kombination aus klassischen Mikrostruktur-Kennzahlen, optionalen Deep-Learning-Prognosen und einem LLM als Erklär-Assistenten liefert belastbare Entscheidungsgrundlagen.

Mein Drei-Tage-Umsetzungsplan für Ihr Team:

Tag 1: Daten-Normalisierung und Kennzahlen-Basis. Verbinden Sie Ihren Orderbuch-Feed mit einer Zeitreihen-Datenbank. Implementieren Sie OBI, Amihud-Maß, Roll-Modell und gleitende Spread-Mittelwerte. Diese Kennzahlen werden automatisiert berechnet und gespeichert. Sie sind die Grundlage für alles Weitere.

Tag 2: Klassische Prognose-Modelle testen. Bauen Sie ein einfaches Modell zur Spread-Prognose auf Basis der Kennzahlen aus Tag 1. Validieren Sie es mit Walk-forward-Backtesting. Ziel ist nicht Perfektion, sondern eine solide Baseline. Vergleichen Sie diese Baseline mit dem, was ein LLM ohne diese Kennzahlen prognostizieren würde. Sie sehen schnell, wer besser ist.

Tag 3: LLM-Assistenz integrieren. Koppeln Sie ein Sprachmodell an die berechneten Kennzahlen. Definieren Sie ein striktes Prompting-Schema, in dem das LLM nur auf Basis der bereitgestellten Zahlen Handlungsempfehlungen formulieren darf. Setzen Sie Schutzmechanismen für die Anzeige der Rohdaten. Testen Sie das System an historischen Daten mit Zeitstempel-basierter Validierung.

Wenn Sie dieses Setup für Ihre spezifischen Wiener Mid-Caps oder andere illiquide Titel individuell aufsetzen wollen, kontaktieren Sie mich. Ich helfe Ihnen, die Bausteine richtig zu montieren, damit Ihr LLM-Agent kein Blender wird, sondern ein nützlicher Assistent. Die Kombination aus quantitativer Strenge und sprachlicher Erklärung ist machbar. Sie erfordert nur die richtige Architektur.