So funktioniert eine AI-Personalisierungsplattform für Banken: Von Daten über Decisioning bis Ausspielung

Die ersten beiden Teile dieser Reihe behandelten Auswahlkriterien und Business Case einer AI-Personalisierungsplattform für Banken. Dieser Teil öffnet die technische Blackbox: Wie ist eine solche Plattform tatsächlich aufgebaut, damit aus Rohdaten in Millisekunden eine Ausspielung wird? Wer sich stattdessen für die Entscheidungslogik selbst interessiert — welche Faktoren eine Empfehlung bestimmen —, findet das im Artikel „Wie eine Next-Best-Action-Engine entscheidet".

Die kurze Antwort zuerst

Eine AI-Personalisierungsplattform für Banken besteht aus drei technischen Schichten: einer Datenschicht, die Rohdaten in Echtzeit einspeist, einer Feature- und Decisioning-Schicht, die Merkmale mit Latenzen im Millisekundenbereich bereitstellt, und einer Delivery-Schicht, die die Empfehlung an den jeweiligen Kanal ausliefert. Der entscheidende Architekturfehler, den es zu vermeiden gilt: Kein Schritt dieser Kette darf im Anfragepfad direkt auf ein Offline-Data-Warehouse zugreifen.

Warum das Warehouse aus dem Anfragepfad verschwinden muss

Der naheliegende, aber falsche Ansatz ist, Merkmale bei jeder Anfrage direkt aus dem analytischen Data Warehouse zu lesen. Das funktioniert für Reporting, aber nicht für Echtzeit-Personalisierung: Der direkte Zugriff auf ein Offline-Warehouse fügt pro Inference-Aufruf Hunderte Millisekunden hinzu und macht Echtzeit-Serving damit faktisch unmöglich (Redis-Dokumentation, „Redis feature store"). Die Lösung ist eine dedizierte Online-Feature-Schicht, die für genau diesen Lesepfad gebaut ist: Feature-Vektoren für Inference-Endpunkte unter 1 ms P99, Sub-Millisekunden-Lese- und Schreibzugriffe, Millionen Lesezugriffe pro Sekunde aus einem einzelnen Shard, mit horizontaler Skalierung darüber hinaus (Redis-Dokumentation).

Die drei Schichten im Detail

Datenschicht. Rohdaten aus Kernbanksystem, CRM und Kartenverarbeitung fließen über eine Event-Streaming-Schicht ein. Kafka als Referenztechnologie garantiert Exactly-once-Verarbeitung, strikte Reihenfolge innerhalb einer Topic-Partition, Entkopplung von Produzenten und Konsumenten sowie Weiterbetrieb ohne Datenverlust bei Serverausfall (Apache Kafka-Dokumentation). In der Produktionskonfiguration bedeutet das üblicherweise einen Replikationsfaktor von 3 — drei Kopien jedes Datensatzes —, während Partitionierung paralleles Lesen und Schreiben über viele Broker ermöglicht, wobei die Performance „effectively constant with respect to data size" bleibt (Apache Kafka-Dokumentation).

Feature- und Decisioning-Schicht. Hier entsteht der eigentliche Geschwindigkeitsvorteil. Ein HMGET-Befehl liefert die vom Modell benötigte Feature-Teilmenge in einem einzigen Round Trip; Features für Hunderte Entitäten lassen sich per Pipelining ebenfalls in einem Round Trip lesen (Redis-Dokumentation). Gemessene Werte zeigen, wie stark die Wahl der Server-Implementierung wirkt: Bei 25 Feature Views mit je 10 Features (250 Features insgesamt) liegt ein Java-Feature-Server bei p99 ≈ 1,3 ms über Redis, ein Python-Server dagegen bei ≈ 45 ms — bei Batch-Anfragen mit 100 Entitäten und 50 Features sind es 17 ms gegenüber 125 ms, also 5- bis 7-mal schneller (Feast, „Feast Benchmarks"). Als Durchsatz-Referenz derselben Messung: rund 5.000 Anfragen pro Sekunde bei 100 ms Timeout und 50 parallelen Clients, mit über 99,9 % Erfolgsquote (Feast Benchmarks).

Delivery-Schicht. Lokale State Stores beziehungsweise lokale Tabellen in der Stream-Verarbeitung reduzieren Verarbeitungslatenz und Last auf entfernte Datenbanken, weil nicht für jeden Datensatz ein Netzwerk-Lookup nötig ist (Confluent-Dokumentation, „Optimize Confluent Cloud Clients for Latency"). Von hier aus wird die fertige Empfehlung an den jeweiligen Kanal ausgeliefert — Online-Banking, App, E-Mail oder Filial-CRM.

Die Speicherwahl entscheidet über die Latenz

Nicht jeder Online-Store liefert dieselbe Geschwindigkeit, und der Unterschied ist erheblich. Bei einer Batch-Größe von 1 und 50 Features liegt Redis bei 8,4 ms gegenüber 465 ms bei GCP Datastore — ein Faktor von 10 bis 20 — und bei 15 ms gegenüber 129 ms bei DynamoDB; DynamoDB wird erst ab einer Batch-Größe von etwa 30 schneller als Redis (Feast Benchmarks). Diese Zahlen zeigen, warum die Wahl der Storage-Technologie eine Architekturentscheidung mit direkter Geschäftswirkung ist, nicht nur eine Infrastrukturdetail: Eine zu langsame Feature-Schicht limitiert, wie viele Entscheidungen pro Sekunde eine Bank überhaupt in Echtzeit treffen kann.

Als Managed-Alternative mit dokumentierten Service-Level-Objectives nennt Snowflakes Online Feature Store für die REST-Query-API p50 = 10 ms, p95 < 15 ms und p99 < 20 ms Serving-Latenz (Snowflake-Dokumentation, „Online feature store"). Snowflake nennt Fraud Detection, Empfehlungen und Personalisierung explizit als primäre Anwendungsfälle für diese Latenzklasse; Real-Time Feature Views werden dabei zum Zeitpunkt der Anfrage selbst berechnet (Snowflake-Dokumentation).

Frische ist eine Designentscheidung, kein Nebeneffekt

Eine Architektur muss festlegen, wie „frisch" ein Feature sein muss, bevor es unbrauchbar wird — und das unterscheidet sich je nach Feature-Typ deutlich. Übliche Praxis sind unterschiedliche Ablaufzeiten pro Feature-Typ: Streaming-Features etwa 5 Minuten, Batch-Features 24 Stunden, technisch umgesetzt über HEXPIRE/HTTL ab Redis 7.4+ (Redis-Dokumentation). Der Grund dafür ist ein bewusstes Fail-safe-Prinzip: Fällt eine Ingestion-Pipeline aus, sollen Features ablaufen, statt still veraltete Werte an das Modell weiterzugeben (Redis-Dokumentation). Im Snowflake-Setup liegt das Frische-Budget bei End-to-End-Freshness unter 2 Sekunden bei Stream-Ingestion; der Offline-zu-Online-Sync ist über target_lag von 10 Sekunden bis 8 Tagen konfigurierbar, wobei sich die effektive Verzögerung aus Refresh-Frequenz plus target_lag ergibt (Snowflake-Dokumentation).

Ein bekanntes Fehlerbild, das eine saubere Referenzarchitektur explizit vermeiden muss: Ein selbstgebauter Cache vor dem Warehouse senkt zwar die Latenz, erzeugt aber Training-Serving-Skew — die zur Inference-Zeit genutzten Features weichen von den beim Training verwendeten Features ab, und die Modellgenauigkeit sinkt unbemerkt (Redis-Dokumentation). Genau deshalb sollte die Feature-Schicht als eigenständige, konsistente Komponente designt werden, nicht als improvisierter Cache.

Der Latenz-Durchsatz-Trade-off in der Streaming-Schicht

Architekturentscheidungen in der Event-Streaming-Schicht wirken sich unmittelbar auf die End-to-End-Latenz aus. Eine höhere Partitionsanzahl erhöht zwar den Durchsatz, kann aber die End-to-End-Latenz erhöhen, weil die Replikation länger dauert, bis Nachrichten als „committed" gelten (Confluent-Dokumentation). Für niedrige Latenz kommen konkrete Tuning-Parameter zum Einsatz: linger.ms=0, compression.type=none und acks=1 auf Producer-Seite — Standard ist seit Kafka 3.0 acks=all —, sowie fetch.min.bytes=1 auf Consumer-Seite und TOPOLOGY_OPTIMIZATION=OPTIMIZE für Kafka Streams (Confluent-Dokumentation). In der Referenzarchitektur übernimmt üblicherweise Spark die nächtliche Batch-Materialisierung, während Flink oder Kafka Streams Echtzeit-Features per HSET mit eigenem Frischefenster in denselben Entity-Hash schreiben; Feast unterstützt Redis dafür als First-Class-Online-Store (Redis-Dokumentation).

Governance als Architekturkomponente, nicht als Nachtrag

Bei automatisierten Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung müssen menschliches Eingreifen, Darlegung des eigenen Standpunkts und Anfechtung der Entscheidung technisch sichergestellt sein (Art. 22 Abs. 3 DSGVO) — das bedeutet für die Architektur konkret: Audit-Trail, Reason Codes und ein Human-in-the-Loop-Pfad müssen von Anfang an als Komponenten mitgeplant werden, nicht nachträglich aufgesetzt (Art. 22 DSGVO). Für das Modell-Scoping gilt zusätzlich ein architektonisch relevanter Hinweis: Kreditwürdigkeitsbewertung und Credit Scoring gelten nach Anhang III Nr. 5(b) EU AI Act als Hochrisiko, während Systeme zur Aufdeckung von Finanzbetrug ausdrücklich ausgenommen sind (EU AI Act, Anhang III). Eine saubere Trennung dieser Modellklassen in separate Pipelines innerhalb derselben Architektur reduziert den Compliance-Aufwand spürbar, weil sich Hochrisiko-Anforderungen dann nicht automatisch auf alle Modelle der Plattform ausweiten.

Wie Acceleraid diese Architektur umsetzt

Die CDP & Data Governance von Acceleraid konsolidiert Daten in Echtzeit aus CRM, Kernbanksystem und Kartenverarbeitung als System of Record — mit Consent-Management, Lineage, PII-Schutz und deutschem Hosting nach GDPR-by-design (Platform). Darauf setzt die Prediction Engine & AI Framework auf, die Affinity-, Churn-, Propensity- und NBA-Scores erklärbar und auditierbar berechnet, während die CLM/CVM-Orchestrierung diese Scores mit Kontaktfrequenz-Limits und Kanalpräferenzen in Echtzeit an Online-Banking, App, E-Mail und Filial-CRM ausspielt (Banking). Die Plattform ist modell-agnostisch aufgebaut: Das zugrunde liegende KI-Modell lässt sich austauschen, ohne dass Wissen, Kontexte oder Konfigurationen der bestehenden Architektur verloren gehen — ein Architekturprinzip, das direkt mit über 3,5 Mrd. analysierten Transaktionen und mehr als 250 Enterprise-Deployments in der Praxis validiert ist (Platform).

Fazit

Eine belastbare Referenzarchitektur für Personalisierung im Banking trennt drei Schichten sauber: Datenerfassung über Event-Streaming, eine dedizierte Feature- und Decisioning-Schicht mit Latenzen im niedrigen zweistelligen Millisekundenbereich, und eine Delivery-Schicht ohne Live-Zugriff auf das analytische Warehouse. Die Wahl der Storage-Technologie, das Frische-Design pro Feature-Typ und die architektonische Verankerung von Governance-Anforderungen entscheiden dabei ebenso über den Erfolg wie die Modellqualität selbst. Wer diese drei Schichten nicht sauber trennt, wird über kurz oder lang entweder an Latenz, an Modellgenauigkeit oder an Nachweisbarkeit gegenüber der Aufsicht scheitern.

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.