IBM hat wealthAPI in seiner globalen Product-Blog-Serie „Beyond the Blueprints“ als Fallstudie vorgestellt. Der Beitrag, den ich gemeinsam mit Chad Jennings vom IBM-Team verfasst habe, gibt erstmals einen detaillierten Einblick in die Datenarchitektur, die wir bei wealthAPI entwickelt haben, um fragmentierte Bank- und Brokerdaten in Echtzeit für KI-gestützte Finanzanalysen nutzbar zu machen.

Warum Datenpipelines im Wealth Management besonders anspruchsvoll sind

Finanzinstitute und Fintechs, die ihren Nutzer:innen eine kohärente Sicht auf Vermögen, Positionen und Performance in Echtzeit bieten wollen, stoßen schnell auf ein strukturelles Problem: Die Daten kommen aus dutzenden Quellen — Banken, Brokern, Krypto-Wallets — mit unterschiedlicher Standardisierung, unterschiedlicher Latenz und stark schwankendem Volumen. Klassische Advisory-Prozesse mit manueller Datenabstimmung und periodischen Reviews skalieren in diesem Umfeld nicht.

Dazu kommen regulatorische Anforderungen, die im Finanzbereich nicht verhandelbar sind: DORA-Konformität, BaFin-Regulierung, EU-Datenhaltungsvorgaben. Diese Rahmenbedingungen müssen von Anfang an in die Architektur eingebaut sein — nicht nachträglich.

Die Architektur: Workloads konsequent trennen

Der Kern unserer Lösung ist eine klare Trennung der Datenschichten nach Zugriffsmustern, Latenz und Struktur:

• Ereignisgesteuerte Ingestion: Eingehende Daten fließen über Google Pub/Sub als Message-Queue-Schicht. Das entkoppelt Produzenten von nachgelagerten Services und ermöglicht elastisches Buffering — mehrere Services können denselben Event-Stream konsumieren, ohne eng gekoppelt zu sein.
• Unstrukturierte Analysedaten: Google Cloud BigQuery dient als primärer Store für hochvolumige, oft unstrukturierte Betriebsdaten: Nutzungslogs, Fehler-Tracking, Qualitäts- und Bank-Response-Tracking. Hier ist schema-freies Ad-hoc-Querying über große Datensätze gefragt — BigQuery ist dafür das richtige Werkzeug.
• Strukturierte Hochleistungs-Workloads: Für strukturierte Daten, die hohen Lese- und Schreibdurchsatz erfordern, setzen wir IBM watsonx.data ein. Die Entscheidungsregel ist pragmatisch: Passt die Datenstruktur gut in SQL, bleibt sie in SQL. Ist sie unstrukturiert und voluminös ohne hohe Leseanforderung, kommt BigQuery zum Einsatz. Ist sie strukturiert und braucht exzellente Performance bei Skalierung, ist watsonx.data die Wahl.
• KI-fähige Anreicherung: Ein zentrales Differenzierungsmerkmal ist die Embedding-Generierung und Ähnlichkeitssuche in der Produktion. Daten gelangen über den Event-Stream in das System, ein Modell generiert Embeddings je nach Anwendungsfall, diese werden in watsonx.data gespeichert und ermöglichen Similarity Searches — etwa um verschiedene Anlageklassen vergleichbar zu machen, von Aktienkursen über Referenzdaten bis hin zu ETFs.

Das Ergebnis

Diese Architektur liefert messbare Ergebnisse: bis zu 80 % kürzere Antwortzeiten für Endnutzer:innen, reduzierte Write-Zeiten und besseres Collision-Handling unter Last. Das Entscheidende ist jedoch nicht die einzelne Kennzahl, sondern das Prinzip dahinter: eine stabile, regulatorisch konforme Datenbasis, die es erlaubt, neue KI-Modelle, neue Partnerintegrationen und neue Features einzubauen — ohne die Grundlage jedes Mal neu aufbauen zu müssen.

Wer Finanzplattformen für B2B-Partner und deren Endnutzer:innen baut, braucht genau diese Eigenschaft: Innovationsgeschwindigkeit ohne Stabilitätsverlust.

Weiterlesen

Den vollständigen Artikel gibt es auf dem IBM Product Blog: Building AI-ready financial intelligence pipelines with IBM watsonx.data and Google Cloud BigQuery