Federated Learning: Modell-Training über mehrere Parteien ohne Daten-Sharing.

Institutionelle Marktteilnehmer teilen ihre Trade-Daten nicht. Aus guten Gründen — Compliance, Wettbewerb, interne Policies. Trotzdem entsteht beim gemeinsamen Modell-Training ein klarer statistischer Mehrwert. Federated Learning ist der Versuch, beides zu verbinden: ein gemeinsames Modell, ohne dass jemals ein einziger Datensatz das eigene Haus verlässt.

Warum Daten-Sharing in der Praxis ausfällt.

Wer mit mehreren institutionellen Kunden arbeitet, kennt den Effekt: jeder Kunde hat ein wertvolles eigenes Trade-Log, eigene Order-Patterns, eigene Slippage- Statistik. Auf dem gemeinsamen Pool ließen sich Modelle trainieren, die jeder einzelne niemals allein hinbekommen würde. Und trotzdem sagt jeder Compliance-Officer dasselbe: keine Roh-Daten nach außen, keine Aggregation über Unternehmensgrenzen, keine Cloud, kein Shared-Storage.

Diese Position ist nicht irrational. Die Daten enthalten Positionen, Strategie- Signaturen und Kunden-bezogene Informationen. Selbst eine sorgfältig anonymisierte Time-Series lässt sich oft rückverfolgen — wer an SPX-Mini-Crash-Tagen handelt, ist über sein Order-Pattern identifizierbar.

Was Federated Learning eigentlich tut.

Federated Learning wurde 2017 von einem Google-Team (McMahan et al.) für Tastatur- Vorhersagen auf Smartphones eingeführt. Die Idee: statt Daten an einen Server zu schicken, schickt der Server ein Modell an die Geräte. Jedes Gerät trainiert lokal auf seinen eigenen Daten und sendet nur die Modell-Updates (Gradienten oder aktualisierte Gewichte) zurück. Der Server aggregiert diese Updates und schickt ein neues Modell aus.

Im Trading-Kontext ist die Topologie ähnlich, nur sind die „Geräte“ die Infrastrukturen der einzelnen Teilnehmer — eigene Maschinen oder isolierte Cloud-Tenants. Der Koordinator sieht die Trade-Daten nie. Er sieht nur Gradienten.

FedAvg, FedProx, FedSGD: die drei Klassiker.

FedSGD ist die naive Variante: jeder Client berechnet einen Gradienten auf einem Batch und schickt ihn zurück. Der Server mittelt die Gradienten gewichtet nach Stichproben-Anzahl. Kommunikations-intensiv, weil jeder Schritt synchron läuft.

FedAvg ist der pragmatische Standard: jeder Client trainiert mehrere lokale Epochen (z. B. 5), schickt erst dann seine Gewichte. Der Server mittelt. Deutlich weniger Round-Trips, leicht schlechtere Konvergenz bei heterogenen Daten.

FedProx erweitert FedAvg um einen Proximal-Term, der lokale Updates an den letzten globalen Stand bindet. Hilft, wenn die Client-Daten stark unterschiedlich sind (was bei Trading-Daten verschiedener Häuser fast immer der Fall ist).

Konkret: Flower für die föderierte Aggregation.

Für FL-Setups ist das Framework Flower meine erste Wahl. Es ist agnostisch zur ML-Library (PyTorch, TF, sklearn), läuft auf eigener Infra und ist deutlich produktionsnäher als PySyft. Ein minimales Setup auf Server-Seite:

import flwr as fl
from flwr.server.strategy import FedProx

strategy = FedProx(
    fraction_fit=1.0,          # alle Clients pro Runde
    min_fit_clients=3,         # mindestens 3 Teilnehmer
    min_available_clients=3,
    proximal_mu=0.01,          # Proximal-Term gegen Drift
)

fl.server.start_server(
    server_address="0.0.0.0:8080",
    config=fl.server.ServerConfig(num_rounds=20),
    strategy=strategy,
)

Auf Client-Seite läuft pro Teilnehmer ein schlanker Wrapper um das lokale Trainings- Skript. Der Wrapper exponiert nur drei Methoden: get_parameters, fit, evaluate. Die Rohdaten bleiben auf der Maschine des Teilnehmers, der Server sieht ausschließlich Gewichts-Tensoren.

Privacy-Preserving Aggregation: das stille Feintuning.

FL allein ist noch nicht datenschutzdicht. Aus Gradienten kann ein technisch versierter Angreifer Trainingsdaten teilweise rekonstruieren (Gradient-Inversion- Attacks, seit ca. 2020 in der Literatur dokumentiert). Wer wirklich Schutz will, kombiniert FL mit zwei Techniken:

• Secure Aggregation (Bonawitz et al., 2017): Die Teilnehmer verschlüsseln ihre Updates so, dass nur die Summe entschlüsselbar ist. Der Server sieht nie einen Einzel-Gradienten.
• Differential Privacy: Jeder Teilnehmer addiert kalibriertes Rauschen auf seine Updates. Mathematisch garantierte Obergrenze, was über einzelne Datenpunkte überhaupt rekonstruierbar ist.

Beides hat Performance-Kosten — DP-Rauschen reduziert Modell-Qualität, Secure Aggregation erhöht Latenz. Aber in einer realen Compliance-Diskussion sind das die Schalter, die einen Datenschutzbeauftragten von „nein“ zu „möglich“ bewegen.

Wo es schwierig wird: heterogene Daten.

FL-Papers nutzen gern MNIST oder CIFAR mit künstlich auf Clients verteilten Daten. Echte Trading-Daten sind anders schief: Teilnehmer A handelt nur US-Equities, Teilnehmer B macht FX-Carry, Teilnehmer C ist ein Volatility-Fonds. Wenn jeder Client eine andere Verteilung sieht, divergieren lokale Modelle. Das globale Modell wird zur Mittelung inkompatibler Optima.

Pragmatische Ausgänge:

• Personalisierte FL (z. B. Per-FedAvg, pFedMe): jeder Teilnehmer fine-tuned das globale Modell lokal nach.
• Cluster-FL: Teilnehmer werden vorher in Cluster gruppiert; pro Cluster ein gemeinsames Modell.
• Nur Pre-Training föderiert: das Repräsentations-Lernen ist gemeinsam, die Strategie-Köpfe trainiert jeder lokal.

In der Praxis ist die letzte Variante oft die einzige, die produktiv tragfähig wird: Embedding-Layer für Order-Book-Features föderiert, Down-Stream-Heads pro Teilnehmer lokal.

Realistisch: wann lohnt FL überhaupt?

Federated Learning ist kein Standardwerkzeug für Trading-Setups. Es lohnt sich nur in einer ziemlich engen Konstellation:

• Mindestens 5 unabhängige Teilnehmer mit ähnlicher Asset-Klasse.
• Compliance-Beauftragte, die Daten-Sharing explizit ausgeschlossen haben.
• Genügend Daten-Volumen pro Teilnehmer, damit lokale Trainings überhaupt sinnvoll sind.
• Eine Modell-Klasse, die von gemeinsamem Lernen profitiert (typischerweise Deep-Modelle, weniger klassische Faktor-Modelle).

Für Privat-Trader: irrelevant. Für mittelständische Fonds: meist ein Compliance-Theater, das den Aufwand nicht trägt. Für regulierte Multi-Tenant-Setups (Asset-Manager mit getrennten Sub-Funds, Banken-Konsortien): in genau einer Kategorie sinnvoll, wenn die Alternative kein gemeinsames Modell wäre.

Meine Praxis.

Ich empfehle Federated Learning nur, wenn es eine konkrete Compliance-Anforderung gibt, die ein gemeinsames Modell-Training auf zentral aggregierten Daten verbietet. In allen anderen Fällen ist ein gut anonymisiertes Daten-Sharing technisch und organisatorisch deutlich einfacher.

Ein typisches Szenario, in dem FL trägt: mehrere Häuser mit harten regulatorischen Trennvorgaben, umgesetzt mit Flower + Secure Aggregation und personalisierten Heads pro Teilnehmer. Gemeinsame Embeddings können die lokalen Modelle dann out-of-sample spürbar verbessern — kein Wunder, aber unter Umständen genug, dass sich der Aufwand rechnet.

FL ist kein magischer Hebel. Es ist ein Werkzeug für eine sehr spezifische Klemme: man muss gemeinsam lernen, darf aber nicht gemeinsam sehen. Wer in dieser Klemme steckt, hat in Federated Learning eine seriöse Antwort. Wer nicht in der Klemme steckt, soll bei klassischem zentralen Training bleiben.

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 haben ein Multi-Tenant-Setup mit harten Daten-Trennvorgaben? Unverbindlich anfragen — ich bewerte ehrlich, ob FL der richtige Weg ist. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.