Lebensereignis-Signale aus Transaktionsdaten

Das echte Ausmaß des Problems

Banken haben das Problem nicht, zu wenig über ihre Kunden zu wissen. Sie haben das Problem, das Richtige zum richtigen Zeitpunkt zu wissen.

Im Durchschnitt vergehen zwischen dem Auftreten eines Lebensereignisses — Umzug, Familienzuwachs, Jobwechsel, Beziehungsende, Erbschaft — und dem Zeitpunkt, an dem ein Institut aktiv wird, 6 bis 18 Monate. Zu dem Zeitpunkt ist der Wettbewerber oft längst am Tisch.

Eine umfassende Untersuchung an 760.438 Kunden eines großen europäischen Finanzinstituts (Buckmann et al., 2019, Decision Support Systems) zeigte: Transaktionsdaten liefern für zehn verschiedene Lebensereignisse Vorhersagegüten (AUC) zwischen 0,72 und 0,88 — das bedeutet, das Modell liegt bei vier von fünf Fällen korrekt. Die Erkennungsrate auf Basis reiner Kundenbefragungen oder demografischer Daten lag deutlich darunter.

Warum fließt diese Erkenntnis trotzdem so selten in den operativen Betrieb ein? Weil zwischen der technischen Machbarkeit und dem produktiven Einsatz erhebliche Voraussetzungen liegen — technisch, regulatorisch und organisatorisch. Diese Lücke ist das eigentliche Problem.

Was fehlt, ist kein schlaues Modell. Es fehlt die Infrastruktur, das Consent-Management und die organisatorische Bereitschaft, aus Signalen tatsächlich Handlungen zu machen — rechtzeitig, datenschutzkonform und ohne übergriffig zu wirken.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Laut Branchenberichten von Pega (2024) und Dataiku NBO-Kundenberichten: Zielgerichtete Ansprache auf Basis von Verhaltenssignalen erzielt 4–8× höhere Conversion als Broadcast-Kampagnen im Baufinanzierungssegment. Eigene Validierung via kontrolliertem A/B-Test empfohlen.

Die Tabelle zeigt: Das Hauptargument für dieses System ist nicht Kostensenkung, sondern Timing-Präzision. Ein Angebot, das trifft, kostet weniger als zehn Angebote, die nicht treffen.

Einschätzung auf einen Blick

Zeitersparnis — keine (1/5) Dieser Anwendungsfall spart niemandem Zeit. Er erhöht den Umsatz durch besseres Timing — das ist ein anderer Hebel. Vertriebsmitarbeitende führen dieselbe Anzahl Gespräche, nur mit besser qualifizierten Kontakten. Wer dieses System unter Effizienzgesichtspunkten rechtfertigen will, argumentiert am Kern vorbei.

Kosteneinsparung — begrenzt (2/5) Direkte Kosteneinsparung ist gering. Der Nutzen liegt im gesenkten Cost-per-Acquisition durch höhere Trefferquoten — das ist Effizienz, keine Einsparung. Kampagnenbudgets können kleiner werden, wenn Streuung reduziert wird. Unter den verglichenen Finanzanwendungsfällen wie AML-False-Positive-Reduktion oder automatisierter Risikoprüfung ist der direkte Kostenhebel hier deutlich geringer.

Schnelle Umsetzung — aufwendig (2/5) Das ist kein Wochenend-Projekt. Vollständige Transaktionshistorie auf einem zentralen Data Lake, sauber labelte historische Ereignisse für das Modelltraining, ein DSGVO-konformes Consent-Framework, und ein Data-Science-Team, das Modelle trainiert, validiert und im Betrieb hält — all das muss vor dem ersten produktiven Signal vorhanden sein. Realistischer Zeitplan: 12–18 Monate von Projektstart bis produktivem Betrieb.

ROI-Sicherheit — klar messbar (4/5) Anders als bei vielen anderen KI-Anwendungen in Banken lässt sich der Nutzen hier sauber isolieren: Ein A/B-Test mit einer Kontrollgruppe (ungesteuerter Massen-Kontakt) gegen eine Testgruppe (signal-basierte Ansprache) liefert nach einem Quartal belastbare Conversion-Deltas. Die Equa Bank erzielte mit einem Propensity-to-Buy-Modell eine Prognosegenauigkeit von 87 % AUC über fast 70 % ihres Kundenstamms — ein Maßstab, der valide ROI-Berechnungen ermöglicht.

Skalierbarkeit — maximal (5/5) Ein einmal trainiertes Modell läuft für den gesamten Kundenstamm gleichzeitig — ohne proportional steigenden Betriebsaufwand. 100.000 Kunden oder eine Million Kunden: die Infrastrukturkosten ändern sich kaum. Das macht diesen Ansatz zu einem der wenigen, bei denen die Einführung bei großen Instituten absolut mehr Sinn ergibt als bei kleinen.

Richtwerte — stark abhängig von Datenverfügbarkeit, Kundenstamm und vorhandener Data-Science-Kapazität.

Was das Modell konkret macht

Das System verarbeitet keine Echtzeit-Transaktionen einzeln. Es analysiert aggregierte Zahlungsstrommuster über Zeitfenster — typisch 3 bis 6 Monate rollierend — und sucht nach Mustern, die historisch vor bestimmten Lebensereignissen aufgetreten sind.

Konkrete Signalmuster für häufige Lebensereignisse:

Umzug: Neue Daueraufträge an einen vorher unbekannten Empfänger (Vermietung/Hausverwaltung), gleichzeitig Wegfall des bisherigen Dauermietauftrags, erhöhte Ausgaben bei Möbelketten oder Umzugsunternehmen in einem kurzen Zeitfenster.

Familienzuwachs: Neue Ausgabenkategorie Babyausstattung (Pampers, Rossmann, dm in erhöhter Frequenz), beginnende Kindergeldtransaktionen, gegebenenfalls sinkende Ausgaben in Restaurants/Bars, steigende Supermarktausgaben.

Jobwechsel: Eingehende Gehaltszahlung von einem neuen Absender (andere Arbeitgeber-IBAN), gegebenenfalls kurze Lücke in der Gehaltskette oder ein anderer Zahlungstermin.

Geldanlage-Bedarf nach Erbschaft: Ungewöhnlich hoher Einmalbetrag von einer Notar-IBAN oder einer anderen Privatperson, gefolgt von verändertem Ausgabeverhalten.

Das sind keine Gewissheiten — es sind Wahrscheinlichkeiten. Das Modell liefert für jeden Kunden einen Score für jedes Lebensereignis, nicht eine binäre Einstufung. Erst ab einem definierten Schwellenwert wird ein internes Signal ausgelöst — als Hinweis für den Vertrieb, nicht als automatische Aktion.

Wichtig: Machine Learning, kein Regelwerk

Der Unterschied zu einem regelbasierten System: Das Predictive Analytics-Modell lernt aus historischen Daten, welche Kombination von Signalen tatsächlich zu einem Ereignis geführt hat — nicht was intuitiv sinnvoll klingt. Einige der stärksten Signale sind kontraintuitiv und würden in einem Regelwerk nie auftauchen. Das ist der Grund, warum Modelle auf Transaktionsdaten regelbasierten Systemen in der Trefferquote überlegen sind.

Einwilligungs-Architektur: die KI-Frage ist die AGB-Frage

Dieser Anwendungsfall steht und fällt mit einer Frage, die keine Data-Science-Frage ist: Auf welcher rechtlichen Grundlage darf das Institut die Transaktionsdaten seiner Kunden für die Lebensereignis-Erkennung auswerten?

Das ist die wichtigste Entscheidung des gesamten Projekts — und sie muss vor der ersten Zeile Modellcode geklärt sein.

Art. 22 DSGVO: was greift hier, was nicht

Art. 22 DSGVO verbietet Entscheidungen, die ausschließlich auf automatisierter Verarbeitung beruhen und die betroffene Person rechtlich oder erheblich beeinträchtigen. Für reine Produktempfehlungen, die ein Berater menschlich bewertet und dann umsetzt, greift Art. 22 nicht direkt — es liegt keine automatisierte Entscheidung mit rechtlicher Wirkung vor.

Was aber greift: Das Profiling nach Art. 4 Nr. 4 DSGVO. Jede automatisierte Verarbeitung personenbezogener Daten, die dazu dient, persönliche Aspekte einer Person zu bewerten, ist Profiling — auch wenn die Entscheidung selbst ein Mensch trifft. Profiling braucht eine Rechtsgrundlage.

Mögliche Rechtsgrundlagen und ihre Tücken:

Berechtigtes Interesse (Art. 6 Abs. 1 lit. f DSGVO): Das ist die häufig gewählte Grundlage für Marketing-Profiling. Voraussetzung ist eine Interessenabwägung, die das Interesse des Instituts (Produktansprache) gegen das Schutzinteresse des Kunden (Autonomie, Überraschungseffekt) abwägt. Ergebnis: Eine solide Abwägung kann das berechtigte Interesse begründen — aber nur, wenn die Betroffenen transparent informiert werden (in der Datenschutzinformation) und ein Widerspruchsrecht aktiv ausgeübt werden kann.

Einwilligung (Art. 6 Abs. 1 lit. a DSGVO): Die sicherste, aber praktisch aufwändigste Grundlage. Kunden müssen aktiv und freiwillig zustimmen — ohne dass die Einwilligung an die Vertragserfüllung geknüpft ist. Das schränkt den Nutzerkreis erheblich ein.

Das EuGH-Urteil vom 7. Dezember 2023 (C-634/21): Der Europäische Gerichtshof hat im SCHUFA-Scoring-Urteil klargestellt, dass automatisiertes Scoring nach Art. 22 DSGVO verboten ist, wenn die nachfolgende Entscheidung (z. B. Kreditgewährung) maßgeblich auf dem Score beruht — auch wenn formal ein Mensch unterschreibt. Das betrifft hier nicht die Produktempfehlung selbst, aber es verschärft die Anforderungen an die Nachvollziehbarkeit jedes Scoring-Prozesses und die Informationspflichten. Wer Propensity-Scores für Kreditentscheidungen nutzt (nicht nur für Marketingansprache), ist direkt betroffen.

Was das für die Systemarchitektur bedeutet

Die regulatorisch sicherste Architektur für diesen Anwendungsfall sieht so aus:

1. Datenverarbeitung: Transaktionsdaten aggregiert und pseudonymisiert auf einem internen Data Lake — kein Zugriff für externe Anbieter ohne AVV
2. Modellbetrieb: On-Premise oder in einer nach DSGVO konformen EU-Cloud-Umgebung
3. Ergebnis: Internes Signal an den Berater, kein automatisierter Kontakt ohne menschliche Freigabe
4. Transparenz: Kunden werden in der Datenschutzinformation über die Nutzung von Transaktionsdaten für personalisierte Ansprache informiert, Widerspruchsrecht aktiv angeboten
5. Audit: Jede Entscheidung ist nachvollziehbar — welche Signale haben den Score erzeugt, wann wurde ein Berater informiert, welche Aktion folgte

Wer diese Architektur nicht vollständig implementiert, sollte das System nicht in Betrieb nehmen. Die regulatorischen Kosten einer nachträglichen Nachbesserung übersteigen die Initialkosten eines sauberen Setups bei weitem.

Konkrete Werkzeuge — was wann passt

Die Wahl des richtigen Tool-Stacks hängt von der vorhandenen Infrastruktur und der Institutsgröße ab.

Pega Customer Decision Hub — für Institute, die kanalübergreifendes Echtzeit-Decisioning brauchen Die umfassendste Lösung: Pega CDH analysiert Kundenverhalten, berechnet Next-Best-Action-Scores und orchestriert die Ansprache über alle Kanäle gleichzeitig — Online-Banking-Banner, Callcenter-Prompt und Filialberatungsempfehlung zeigen dieselbe Logik. Preis: Implementierungsbudget typisch 500.000–2.000.000 €. Realistisch für Banken mit 500.000+ Privatkunden und eigenem Data-Science-Team.

Databricks + Salesforce Financial Services Cloud — für den maßgeschneiderten Ansatz Für Institute, die eine vollständige Kontrolle über Modelle und Daten wollen: Databricks als ML-Plattform für Training und Inference der Propensity-Modelle, Salesforce Financial Services Cloud als CRM für die Beraterempfehlung. Aufwendiger zu bauen, aber maximale Anpassbarkeit und EU-Datenhaltung nativ möglich. Databricks-Kosten abhängig vom Compute-Volumen (ca. 0,40 USD/DBU-Stunde); Salesforce Financial Services Cloud ab ca. 225 USD/Nutzer/Monat.

Dataiku — für das Data-Science-Team, das schnell liefern will Dataiku ist eine No-Code/Low-Code-ML-Plattform, die es Data-Science-Teams ermöglicht, Propensity-Modelle schneller zu entwickeln als in reinem Python/Spark. Dataiku bietet eine vorkonfigurierte “Next Best Offer for Banking”-Lösung, die auf Transaktionsdaten aufbaut. Median-Preis: ca. 26.000 USD/Jahr für Einstieg (laut PriceLevel.com, 2024). EU-Hosting verfügbar.

Segment — nur als Data-Layer, nicht als Entscheidungssystem Segment eignet sich als CDP-Schicht, um Kundendaten aus verschiedenen Quellen zu einem einheitlichen Profil zusammenzuführen, bevor sie in ein ML-System fließen. Für die eigentliche Lebensereignis-Erkennung ist Segment kein geeignetes Tool — es fehlen die ML-Trainingsfähigkeiten. Sinnvoll als vorgelagerter Schritt in einem modularen Stack.

Keine Free-Tier-Option für produktive Systeme. Die Datenmengen und regulatorischen Anforderungen in diesem Anwendungsfall schließen Freemium-Tools als produktiven Kern aus. Proof-of-Concept-Experimente können mit Open-Source-Python (scikit-learn, XGBoost) auf einer Databricks Community Edition beginnen — aber nicht mit echten Kundendaten.

Datenschutz und Datenhaltung

Transaktionsdaten sind Zahlungsverkehrsdaten im Sinne der Zahlungsdiensterichtlinie PSD2 und gleichzeitig Daten nach Art. 4 Nr. 1 DSGVO. Jede Nutzung dieser Daten für Zwecke jenseits der Vertragserfüllung — also für Profiling und Produktansprache — erfordert eine eigene Rechtsgrundlage.

Auftragsverarbeitungsvertrag (AVV): Jeder externe Anbieter, der Zugriff auf Transaktionsdaten erhält, muss einen AVV nach Art. 28 DSGVO abschließen. Das gilt für Cloud-Anbieter, ML-Plattformen und CRM-Systeme. Bei US-Anbietern (AWS, Azure, Google Cloud) muss zusätzlich geprüft werden, ob der Drittlandstransfer über EU-Standardvertragsklauseln oder Adequacy-Entscheidungen abgesichert ist.

Pseudonymisierung als Mindeststandard: Transaktionsdaten sollten für das Modelltraining und die Inference pseudonymisiert werden — Kontonummern durch interne IDs ersetzt, externe IBANs gehasht. Das ist kein vollständiger Datenschutz, reduziert aber das Risiko bei einem Datenleck erheblich.

Datensparsamkeit: Das Modell braucht keine vollständigen Kontoinformationen — es braucht aggregierte Zahlungsstrommuster. Eine saubere Feature-Engineering-Pipeline stellt sicher, dass nur die statistisch relevanten Merkmale (Transaktionskategorien, Beträge, Frequenzen) ins Modell fließen, nicht vollständige Kontodaten.

Bankgeheimnis und § 25a KWG: Banken unterliegen dem Bankgeheimnis und den IT-Anforderungen nach § 25a KWG (MaRisk). Externe Dienstleister für KI-Systeme gelten als Auslagerungspartner und müssen die BaFin-Anforderungen an Auslagerungen erfüllen — inklusive Exit-Strategie und Revisionierbarkeit.

Was es kostet — realistisch gerechnet

Projektkosten (einmalig)

• Data Lake aufbauen / bereinigen (wenn nicht vorhanden): 100.000–400.000 €
• Datenwissenschaftliche Modellentwicklung (intern oder extern): 80.000–200.000 €
• Tool-Infrastruktur (ML-Plattform, Anbindung CRM): 60.000–150.000 € jährlich
• Rechtliche Prüfung, Datenschutz-Folgenabschätzung, Consent-Architektur: 20.000–40.000 €
• Gesamter Erstaufwand ohne Enterprise-Lösung wie Pega CDH: 260.000–790.000 €

Laufende Kosten (jährlich)

• ML-Plattform-Lizenz (z. B. Dataiku): ca. 26.000–60.000 USD/Jahr
• Cloud-Compute für Modell-Training und Inference: je nach Volumen 10.000–40.000 €/Jahr
• Modellpflege (Retraining, Validierung, Driftmonitoring): 1–2 Personen/Quartal intern

Wie du den Nutzen tatsächlich misst

Der einzig belastbare Nachweis ist ein kontrolliertes Experiment: Zwei zufällig ausgewählte Gruppen vergleichbarer Kunden mit erkanntem Signal — eine Gruppe erhält den proaktiven Kontakt, eine nicht. Der Vergleich der Abschlussraten nach 90 Tagen liefert den echten Conversion-Delta.

Ohne diesen A/B-Test bleibt der ROI eine Hochrechnung. Mit ihm: ein Messinstrument, das sich für jede Produktkategorie separat anwenden lässt und das Modell kontinuierlich validiert.

Vorsichtiges Basisszenario: Eine Bank mit 400.000 Privatkunden erkennt pro Quartal 8.000 Kunden mit Baufinanzierungssignal. Davon erhalten 4.000 eine proaktive Ansprache (A/B-Test), 4.000 sind Kontrollgruppe. Conversion-Rate Testgruppe: 4 %, Kontrollgruppe: 1 %. 120 zusätzliche Beratungsgespräche, davon 30 Abschlüsse bei durchschnittlich 200.000 € Kreditvolumen. Marge: 0,4 %. Jahresertrag aus dem Signal: ca. 240.000 € — bei einem Projektbudget, das sich in 2–3 Jahren amortisiert.

Typische Einstiegsfehler

1. Mit dem Modell anfangen, nicht mit der Rechtsfrage. Das häufigste Muster: Ein Data-Science-Team baut ein funktionierendes Modell — und dann stoppt das Projekt, weil die Rechtsabteilung feststellt, dass die Nutzung der Transaktionsdaten für Marketing-Profiling nicht durch die bestehenden Datenschutzinformationen gedeckt ist. Sechs Monate Arbeit liegen auf Eis. Lösung: Die Consent-Architektur und die Rechtsgrundlagenprüfung sind Phase 0 — bevor ein Modell trainiert wird.

2. Lebensereignisse mit Gewissheit gleichsetzen. Ein Modell-Score ist keine Diagnose. Wer einem Kunden ein Scheidungsanwalt-Telefonat und gleichzeitig einen “Starter Home”-Kredit anbietet, weil das System “Umzug” erkannt hat, riskiert nicht nur einen verlorenen Kunden, sondern einen öffentlichen Reputationsschaden. Die Kommunikation gegenüber dem Kunden darf nie das Signal nennen — sie adressiert den Bedarf (“Gibt es gerade Veränderungen in Ihrer Lebenssituation, bei denen wir helfen können?”), nicht die Schlussfolgerung.

3. Kein Retraining einplanen. Lebensereignismuster verschieben sich. Die Kategorie “Umzug” sieht nach dem Ende von Wohnungsnot und Preisexplosion in Ballungsräumen anders aus als in normalen Zeiten. Wer ein Modell trainiert und dann 18 Monate unverändert laufen lässt, beobachtet stille Modell-Degradation. Die Performance-Kennzahl (Conversion-Rate der Signal-Gruppe vs. Kontrollgruppe) ist der Frühwarnindikator — nicht die AUC-Metrik auf dem Trainings-Datensatz.

4. Fehlender menschlicher Checkpoint — das rechtliche und reputationale Risiko. Das System darf keine automatisierten Kontakte auslösen. Jedes Signal muss durch eine menschliche Freigabestufe laufen — sei es ein Berater, der entscheidet, ob er das Gespräch sucht, oder ein Marketing-Team, das die Kampagne freigibt. Automatisierter Kundenkontakt auf Basis von Transaktions-Profiling ohne explizite Einwilligung ist nicht nur datenschutzrechtlich riskant — er wirkt auf Kunden wie Überwachung.

Was mit der Einführung wirklich passiert — und was nicht

Die größte Illusion in diesem Projekt: “Wenn das Modell läuft, läuft der Vertrieb besser.”

In der Realität entsteht ein neues Problem: Der Vertrieb muss lernen, mit Signalen umzugehen. Ein Berater, der plötzlich jeden Montag eine Liste mit 40 “Umzugs-Kandidaten” erhält, ohne Training wie er das Gespräch einleitet, ohne klare Leitlinien was er sagen darf und was nicht — dieser Berater wird die Liste ignorieren. Das ist der häufigste Umsetzungsfehler.

Was tatsächlich gebraucht wird:

• Gesprächsleitfäden für jede Signalart: Wie leite ich ein Gespräch ein, das aus einem “Baufinanzierungssignal” entstand, ohne dem Kunden gegenüber das Wort “Transaktion” zu erwähnen?
• Klare Grenzen was gesagt werden darf: “Ich sehe, dass Sie gerade umziehen” ist nicht erlaubt, weil es demonstriert, dass die Bank Einkäufe bei Möbelketten auswertet. “Gibt es gerade Veränderungen, bei denen wir helfen können?” ist erlaubt.
• Feedback-Loop zurück ins System: Welche Signale haben zu Gesprächen geführt? Welche zu Abschlüssen? Welche zu verärgerten Kunden? Dieses Feedback verbessert die Modell-Schwellenwerte und die Signalqualität über Zeit.
• Widerspruchsrecht aktiv verwalten: Kunden, die dem Marketing-Profiling widersprochen haben, müssen aus der Signalliste herausgefiltert werden — automatisch und zuverlässig.

Der kulturelle Wandel — von reaktivem Massenmarketing zu signal-basiertem Einzelkontakt — braucht 12–24 Monate, bis er im Vertriebsalltag verankert ist.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Das ist doch übergriffig. Wollen wir wirklich die Einkäufe unserer Kunden auswerten?” Das ist der wichtigste Einwand — und er verdient eine ehrliche Antwort, keine Verkaufsantwort. Ja, das System nutzt Transaktionsdaten für Zwecke über die Vertragserfüllung hinaus. Ob das vertretbar ist, hängt davon ab, wie transparent die Bank kommuniziert, wie gut das Widerspruchsrecht umgesetzt wird, und wie die Ansprache gestaltet ist. Wer das System heimlich betreibt und Kunden mit präzisen Angeboten zu Ereignissen überrascht, die sie nicht für öffentlich halten, verliert Vertrauen. Wer es transparent betreibt und Kunden aktiv die Kontrolle gibt, kann legitim argumentieren.

„Wir haben zu wenige Datenpunkte für verlässliche Modelle.” Tatsächlich brauchen Lebensereignis-Modelle eine gewisse kritische Masse — eine europäische Studie hat 760.438 Kunden analysiert. Bei einem Institut mit 50.000 Privatkunden sind die Ereignishäufigkeiten pro Kategorie (Umzug, Familienzuwachs etc.) oft zu gering für belastbare Modelle. Das ist kein Problem der Methode, sondern eine echte Grenze der Einsatzmöglichkeit.

„Der Wettbewerb macht das schon lange.” Das stimmt für Direktbanken und FinTechs. Für Filialbanken und Genossenschaftsbanken ohne zentralen Data Lake ist die Aussage aber oft voreilig. Die Fähigkeit, Transaktionsdaten zentral zu aggregieren, sauber zu etikettieren und in Echtzeit auszuwerten, ist selbst bei großen Instituten oft 3–5 Jahre hinter dem Stand der Technologie. Wer das überspringt, kauft ein Modell ohne Fundament.

Woran du merkst, dass das zu dir passt

• Du betreibst ein Retail-Banking-Institut mit mind. 200.000 aktiven Privatkunden. Unterhalb dieser Grenze ist das Ereignisvolumen für die meisten Lebensereignisklassen zu gering für belastbare Modelle.
• Du hast eine zentrale Transaktionshistorie, entweder in einem Data Warehouse oder einem Data Lake, auf die ein Data-Science-Team Zugriff hat — oder kannst sie innerhalb der nächsten 6 Monate aufbauen.
• Dein Vertrieb kämpft mit hohen CPA-Kosten in der Baufinanzierung, Privatkredit- oder Wertpapieransprache — und hat die Ursache bereits in mangelndem Timing identifiziert, nicht in schlechten Produkten oder Preisen.
• Du hast einen Datenschutzbeauftragten, der aktiv in das Projekt eingebunden werden kann — das ist keine Formalität, sondern ein funktionaler Projektteilnehmer.

Wann es sich nicht lohnt — drei harte Ausschlusskriterien:

1. Weniger als 200.000 aktive Privatkunden. Bei geringerer Kundenbasis sind die Ereignishäufigkeiten zu gering für belastbare Modelle. Der Modellaufwand steht in keinem vernünftigen Verhältnis zum erzielbaren Effekt — investiere stattdessen in bessere Qualifizierung der Berater für direkte Bedarfsgespräche.

2. Kein zentraler Data Lake oder kein Plan, einen innerhalb von 12 Monaten aufzubauen. Lebensereignis-Modelle brauchen eine saubere, historische Transaktionshistorie von mindestens 24 Monaten pro Kunde. Wenn Transaktionsdaten fragmentiert in verschiedenen Systemen liegen und nicht konsolidiert verfügbar sind, ist das Infrastrukturprojekt die richtige Investition — nicht das KI-Projekt.

3. Kein internes Data-Science-Team oder langfristiger Zugang zu einem externen. Dieser Anwendungsfall erfordert dauerhaften Betrieb: Retraining, Driftmonitoring, A/B-Test-Auswertung, Schwellenwert-Kalibrierung. Wer das Modell einmal baut und dann sich selbst überlässt, hat nach 18 Monaten ein System, das still degradiert — und Signale erzeugt, die schlechter sind als eine Zufallsauswahl.

Das kannst du heute noch tun

Bevor das erste Modell trainiert wird, lässt sich mit einfachen Mitteln prüfen, ob die Signalidee überhaupt trägt. Nutze eine Stichprobe aus eurem Transaktionsdatensatz (pseudonymisiert, intern) und analysiere manuell 50–100 Kunden, von denen ihr wisst, dass sie in den letzten 12 Monaten eine Baufinanzierung abgeschlossen haben:

• Welche Transaktionsmuster tauchen 3–6 Monate vorher auf?
• Gibt es Kategorien, die auffällig häufiger erscheinen als bei einer zufälligen Kontrollgruppe?

Dieses manuelle “Signal-Audit” ist keine wissenschaftliche Validierung — aber ein schneller Hinweis, ob überhaupt ein Signal in euren Daten steckt. Wenn keine konsistenten Muster erkennbar sind, lohnt sich der Modellaufwand nicht.

Für den nächsten Schritt — die Abschätzung der Rechtsgrundlage — ist dieser Prompt ein Startpunkt für eine erste interne Diskussion:

Quellen & Methodik

• Transaktionsdaten und Lebensereignis-Prognose: Buckmann, Thorn et al., „Leveraging fine-grained transaction data for customer life event predictions”, Decision Support Systems, Elsevier (2019/2020, verfügbar unter ScienceDirect ISSN 0167-9236). Datenbasis: 760.438 Kunden eines großen europäischen Finanzinstituts, 10 Lebensereignisse, 12 Monats-Snapshots; AUC-Werte zwischen 0,72 und 0,88 je Lebensereignisklasse.
• Fallstudie Propensity-to-Buy, Equa Bank: Bigdataforbanking.com, „Propensity model in banking — Success story: Equa Bank” (2023). Modellgenauigkeit: 87 % AUC, wirksam über fast 70 % des Kundenstamms inkl. Neukunden und inaktiver Kunden.
• Dataiku Next Best Offer for Banking: Dataiku Knowledge Base (knowledge.dataiku.com, 2024). Medianpreis Dataiku: ca. 26.000 USD/Jahr laut PriceLevel.com (2024, primär Anbieter-unabhängige Käuferdaten).
• EuGH-Urteil C-634/21 (SCHUFA-Scoring): Europäischer Gerichtshof, Urteil vom 7. Dezember 2023. Automatisiertes Scoring ist nach Art. 22 DSGVO verboten, wenn nachfolgende Entscheidungen maßgeblich darauf beruhen. Fundstelle: curia.europa.eu, Rechtssache C-634/21.
• Art. 22 DSGVO / Profiling-Definition: Datenschutz-Grundverordnung in aktuell gültiger Fassung, Art. 4 Nr. 4, Art. 22, Art. 6 Abs. 1 lit. f.
• Pega CDH Implementierungsbudgets: Pega.com (2024), ergänzt durch Branchenberichte (Capterra, SoftwareAdvice) zu Projektgrößen. Keine öffentliche Preisliste.
• Target-Schwangerschaftsfall als Referenzbeispiel für Übergriffigkeitseffekte: Ursprünglich New York Times (Charles Duhigg, 2012), seither vielfach zitiert in Literatur zu algorithmic inference. Lehrbeispiel: Präzise Vorhersage + mangelnde Kommunikation = Vertrauensschaden.

Du willst wissen, ob deine Transaktionsdatenbasis für diesen Anwendungsfall reicht und welche Rechtsgrundlage für euer Institut die robusteste ist? Meld dich — das klären wir gemeinsam in einem kurzen Gespräch.