Reinforcement Learning für Order-Execution.

Reinforcement Learning hat im Trading einen schweren Stand für reine Signal- Generierung. Für Order-Execution ist die Lage anders: Hier gibt es klare kurzfristige Rewards, eine wohldefinierte Episode und einen Markt, der auf Aktionen nachvollziehbar reagiert. Genau die Bedingungen, unter denen RL funktioniert.

Das Execution-Problem in einer Zeile.

Sie haben in den nächsten 60 Minuten 100 000 Aktien zu kaufen. Wenn Sie alles sofort über Market-Order schicken, drücken Sie den Preis nach oben — Market- Impact. Wenn Sie zu langsam handeln, läuft der Markt davon — Timing-Risiko. Klassisch löst das ein TWAP- oder VWAP-Algorithmus mit festen Slicing-Regeln. RL lernt aus Daten, wann diese Regeln verletzt werden sollten.

State, Action, Reward.

Die Modellierung als Markov-Decision-Process:

• State: verbleibendes Volumen, verbleibende Zeit, aktueller Bid-Ask-Spread, kurzfristige Order-Book-Imbalance, kurzfristige Vola, jüngste Mid-Price-Returns.
• Action: Anteil des Rest-Volumens, der im aktuellen Slice ausgeführt wird, sowie Wahl zwischen Market- und Limit-Order.
• Reward: negativer Implementation-Shortfall pro Step (Differenz zwischen Ausführungspreis und Arrival-Price, gewichtet mit dem ausgeführten Volumen).

Simulator: ohne ihn geht es nicht.

RL braucht Millionen Trajektorien. Echte Markt-Replays liefert kein Broker. Ein realistischer Order-Book-Simulator ist die anspruchsvollste Komponente des gesamten Setups. Mindestbestandteile:

• Historische Order-Book-Snapshots mit Bid-Ask-Tiefe.
• Modell für Market-Impact (z. B. Almgren-Chriss als Baseline).
• Modell für Fill-Wahrscheinlichkeit von Limit-Orders abhängig von Tiefe.
• Konsistente Latency-Annahmen.

import numpy as np

class ExecutionEnv:
    def __init__(self, lob_snapshots, total_shares, horizon_steps, impact=1e-4):
        self.lob = lob_snapshots
        self.total = total_shares
        self.H = horizon_steps
        self.impact = impact
        self.reset()

    def reset(self):
        self.t = 0
        self.remaining = self.total
        self.arrival_price = self.lob[0]["mid"]
        return self._state()

    def _state(self):
        s = self.lob[self.t]
        return np.array([
            self.remaining / self.total,
            (self.H - self.t) / self.H,
            s["spread"],
            s["imbalance"],
            s["vol_1m"],
        ], dtype=np.float32)

    def step(self, action):
        # action in [0, 1]: Anteil des Rest-Volumens dieses Steps
        qty = int(round(action * self.remaining))
        s = self.lob[self.t]
        # einfaches linear-impact-Modell
        slip = self.impact * qty
        fill_price = s["ask"] + slip
        cost = qty * (fill_price - self.arrival_price)
        self.remaining -= qty
        self.t += 1
        done = self.t >= self.H or self.remaining <= 0
        if done and self.remaining > 0:
            # Rest-Cleanup mit Penalty
            cost += self.remaining * (s["ask"] - self.arrival_price + 5 * slip)
            self.remaining = 0
        reward = -cost / self.total
        return self._state(), reward, done, {}

Algorithmus: PPO als robuster Default.

Proximal Policy Optimization ist im Execution-Kontext der pragmatische Default. Off-Policy-Algorithmen wie SAC funktionieren auch, sind aber empfindlicher gegen schlechte Simulator-Daten. Eine kleine Policy mit zwei Hidden-Layern à 64 Units reicht für die meisten Setups.

import torch
import torch.nn as nn

class ExecPolicy(nn.Module):
    def __init__(self, n_state=5, hidden=64):
        super().__init__()
        self.shared = nn.Sequential(
            nn.Linear(n_state, hidden), nn.Tanh(),
            nn.Linear(hidden, hidden), nn.Tanh(),
        )
        self.mu = nn.Linear(hidden, 1)
        self.log_std = nn.Parameter(torch.zeros(1))
        self.value = nn.Linear(hidden, 1)

    def forward(self, s):
        h = self.shared(s)
        mu = torch.sigmoid(self.mu(h)).squeeze(-1)
        std = self.log_std.exp().expand_as(mu)
        return mu, std, self.value(h).squeeze(-1)

Benchmarks: gegen wen treten Sie an?

Ein RL-Agent ist nichts wert, wenn er TWAP nicht schlägt. Definieren Sie vor dem Training klare Baselines:

• TWAP: gleichmäßig über die Zeit verteilt.
• VWAP: gewichtet nach historischem Volumen-Profil.
• POV (Percent of Volume): adaptiv am aktuellen Markt-Volumen.
• Almgren-Chriss-optimale Lösung als analytisches Optimum unter linearen Annahmen.

Ein gut trainierter Agent kann TWAP und VWAP im Mittel beim Implementation-Shortfall schlagen — wie deutlich, hängt von Volatilität, Liquidität und Order-Größe ab und muss gemessen werden.

Risiken und Realitäts-Check.

Der größte Fehler: zu sehr auf den Simulator vertrauen. Wenn der Impact-Schätzer zu mild ist, lernt der Agent, alles am Ende zu dumpen. Praktische Schutzmaßnahmen:

• Adversarial-Training mit pessimistischeren Impact-Annahmen.
• Hartes Cap auf maximale Aktion pro Step.
• Aufsichtsregel: wenn der Agent extrem aggressiv handelt, Fallback auf TWAP.
• Periodischer A/B-Test gegen die Baseline in der Live-Phase.

Wo RL noch nicht ankommt.

Für reine Signal-Generierung — also "soll ich long oder short gehen" — ist RL im Vergleich zu Supervised Learning meist unterlegen. Die Reward-Signale sind zu spärlich, das Sample-Efficiency-Problem zu groß. Execution ist die Domäne, in der RL aktuell den klarsten Mehrwert liefert. Wer hier startet, baut Erfahrung mit der Methodik, bevor er sie auf risikoreichere Probleme anwendet.

Stand: Mai 2026, überarbeitet Oktober 2026. Angaben zu Produkten, Preisen, Gesetzen und Fristen können sich seitdem geändert haben; maßgeblich sind die aktuellen Angaben der Anbieter und Behörden.

Sie wollen Ihre Execution mit RL verbessern oder zumindest sauber benchmarken? Unverbindlich anfragen — wir bauen Simulator, Agent und A/B-Setup so auf, dass Sie die Mehrwerte messen können. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.