← Alle Insights
9 Min. Lesezeit · ML · April 2033

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

Mandanten 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 Mandanten-Setup verlässt.

Warum Daten-Sharing in der Praxis ausfällt.

Wer mit mehreren institutionellen Mandanten arbeitet, kennt den Effekt: jeder Mandant 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 Mandantengrenzen, 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 2027 die SPX-Mini-Crash-Tage 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 Mandanten-Kontext ist die Topologie ähnlich, nur sind die „Geräte" Mandanten- Infrastrukturen — eigene Maschinen oder isolierte Cloud-Tenants. Ich sehe die Trade- Daten nie. Ich sehe 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 im Mandanten-Setup fast immer der Fall ist).

Konkret: Flower für Mandanten-Aggregation.

Ich nutze in den seltenen FL-Setups, die ich begleitet habe, das Framework Flower. 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 Mandanten
    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 Mandant ein schlanker Wrapper um das lokale Trainings- Skript. Der Wrapper exponiert nur drei Methoden: get_parameters, fit, evaluate. Die Rohdaten bleiben auf der Mandanten-Maschine, 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:

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. Mandanten-Daten sind anders schief: Mandant A handelt nur US-Equities, Mandant B macht FX-Carry, Mandant 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:

In meiner Praxis war die letzte Variante die einzige, die produktiv tragfähig wurde. Embedding-Layer für Order-Book-Features föderiert, Down-Stream-Heads pro Mandant lokal.

Realistisch: wann lohnt FL überhaupt?

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

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.

Wo ich FL eingesetzt habe: zwei Mandanten-Setups mit harten BaFin-Trennvorgaben, beide mit Flower + Secure Aggregation, beide mit personalisierten Heads pro Mandant. Die globalen Embeddings haben in beiden Fällen die lokalen Modelle um etwa 10–15 % in Out-of-Sample-Sharpe verbessert — kein Wunder, aber genug, dass der Aufwand sich rechnete.

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.

Sie haben ein Multi-Mandanten-Setup mit harten Daten-Trennvorgaben? Erstgespräch buchen — ich bewerte ehrlich, ob FL der richtige Weg ist.