Wissen Sie, inwieweit Ihre schriftlich fixierte Ordnung in diesem Moment verschiedene Regulatoriken (z.B. MaRisk oder DORA) erfüllt? Methoden der AI können diese Information ermitteln – kontinuierlich und in near-real-time, idealerweise übersichtlich per Dashboard dargestellt. Besonders im Banking Umfeld sind solche Implementierung häufig jedoch in weiter Ferne, da die Grundlagen, um solche Use Cases zu realisieren, noch nicht geschaffen sind. Diese Komplexität gilt es zu navigieren.

Aber fangen wir vorne an. Analytics und Artificial Intelligence bilden ein breites Spektrum an Methoden, um Informationen aus Daten zu extrahieren und somit datengetriebene Entscheidungen, Optimierungen und Automatisierungen zu ermöglichen. Manche dieser Methoden finden im Banking bereits seit Jahrzehnten Anwendung (z.B. statistische Modelle), manche haben noch weit mehr mediale Aufmerksamkeit als Banking-Anwendungen sie jemals haben werden (z.B. Large Language Models). Die Potentiale dieser Technologien für Produktvertrieb und ‑optimierung sowie Einsparungen im Backoffice und Einhaltung regulatorischer Anforderungen sind unbestritten. Die Realisierung dieser Methoden muss jedoch im Bankingumfeld im Spannungsfeld Organisation-Technik-Regulatorik stattfinden, welches – solange unbeachtet – zu ungemütlichen Scope-Einschränkungen oder Budget-Ausweitungen führen kann. Nicht selten kann die Erzeugung eines Trainings- und Testdatensatzes zu beachtlichen Abstimmungsaufwänden führen. Ob einem Kundenberater eine Information real-time gegeben werden kann, hängt häufig an der Performance der fragmentierten Datenlandschaft und Data-Pipelines. Diskutieren wir also, welche Rahmenbedingungen zu beachten sind, um eine nutzenbringende Implementierung zu ermöglichen und wie sie in der Planung berücksichtigt werden.

Zunächst einmal zu den Anwendungsfällen – warum machen wir das überhaupt?

Bevor wir zum Spannungsfeld selbst kommen, klären wir zunächst welche Bereiche des Bankings den größten Vorteil aus Analytics und/oder AI ziehen. Die folgende Liste ist nicht vollumfassend, deckt jedoch die typischen Bereiche ab:

•   Optimiertes Kundenerlebnis – die Analyse von Kundenverhalten zur Optimierung von Angebot und Interaktion. Beispielhafte Anwendungsfälle sind:

  •    Personalisierte Produktangebote/Nudging – z.B. Analyse von Transaktions- und Interaktionsverhalten zur Prognose von Produktinteresse. Sofern das Modell eine ausreichende Vorhersagegenauigkeit erreicht und der Grenzwert ausreichend hoch gesetzt wird, können für den Kunden relevante Angebote zum richtigen Zeitpunkt ausgespielt werden, ohne als störend empfunden zu werden.

  • Kundeninteraktion/Sprachinterfaces – seitdem generative Modelle eine entsprechende Qualität entwickelten, ist vor allem die Textgenerierung (vorerst weniger die Bildgenerierung) interessant für Banking-Anwendungen. Textbasierte Interaktion zwischen Kunde und Berater oder Kunde und Dokumenten kann nun 24/7 und annähernd menschlich gestaltet werden. Die benötigten Modelle (LLMs) waren zunächst nur proprietär verfügbar (z.B. GPT), doch sind zunehmend in vergleichbarer Qualität auch open-source verfügbar (z.B. Llama3.1)

• Regulatorik und Reporting – regulatorische Tätigkeiten stellen einen Kostenpunkt dar, der häufig ereignisgetrieben (z.B. Audit) zu hohen, teilweise vermeidbaren Kosten führt. Im Folgenden eine Reihe von Beispielen:

  • Compliance Screening – Die Ankündigung eines Audits impliziert häufig eine kurzfristige Analysephase gefolgt von einer unter hohem Druck stattfindenden Behebung von Findings. Dies führt zu kurzfristigem, teurem Beratungsaufwand sowie Behinderung operativer Tätigkeiten. Textbasierte Methoden der AI (z.B. LLMs) können in geeigneten Architekturen (z.B. RAGs) solche Analyseaufgaben teilweise automatisiert, teilweise im Tandem mit einem Compliance Mitarbeiter kontinuierlich und in near-real-time durchführen. Eine entsprechende Strukturierung der Compliance Dokumente ist eine notwendige Basis für ein solches System.

  • Compliance Loop Up – Ein wie oben beschriebenes System lässt nicht nur vollständige Screens auf der Compliance-Basis zu, sondern auch ereignisgetriebene Anfragen. Hierbei können beispielsweise Fragen zu Vollständigkeit oder spezifischer Adressierung von Punkten gestellt werden.

• Transaktionsanalyse – die Analyse von Transaktionen zur Identifikation von Auffälligkeiten und fraudulenten Mustern. Im Folgenden eine Reihe von Beispielen

  • Fraud Detection – Analyse einer Transaktionsreihe zur Identifikation von Betrugsmustern. Früher noch hauptsächlich Expert/Rule-based Systems, werden heutzutage modernere Methoden (z.B. Deep Learning) genutzt, um Betrugsmuster zu identifizieren bevor sie auftreten.

  • Geldwäschebekämpfung – Analog zum Fraud Detection Use Case als Mustererkennung in transaktionalen Daten.

  • Kreditrisiko – Die Vorhersage risikorelevanter KPIs, die sowohl aus regulatorischen Gründen als auch zur Kreditvergabe zu erheben sind. Jede Bank hat bereits ihr Set an Scoring-Modellen

• Operative Effizienz – die datengetriebene Automatisierung von operativen Prozessen spart Kosten und ermöglicht kontinuierlichen, sofortigen Service. Ein kurzer Auszug an Anwendungsfällen

  • (Teil-)automatisierte Kreditentscheidungen – keine Überraschungen hier. Auf Basis des Kredit-Scorings können Teile der Anträge (grün-Fälle) automatisch angenommen werden. Andere werden abgelehnt (rot-Fälle) und manche werden an einen Sachbearbeiter weitergeleitet (gelb-Fälle).

  • Robotic Process Automation – auch hier keine Überraschungen. Repetitive Prozesse werden mittels Software automatisch durchlaufen. Häufig ist es aber auch sinnvoll den Prozess zu vereinfachen, anstatt den aktuellen Prozess zu automatisieren.

• Kundenbindung – die Analyse von Kundendaten zur Vorhersage von Kundenverhalten um frühzeitig reagieren zu können. Typische Anwendungsfälle sind

  • Churn Analysis – Identifikation von Kunden, die einen Bankwechsel beabsichtigen, um die Kunden mit dedizierten Angeboten zum Bleiben zu bewegen. Dies führt zu einer Kostenersparnis, da Angebote zielgerichtet ausgespielt werden und teure Neukundenakquise eingespart wird.

  • Kundenengagement – Scoring des Kundenengagements und -Bereitschaft an Initiativen zu partizipieren. Eine identifizierte Kundengruppe kann mit passenden Produkten adressiert werden.

• Investment und Trading – um der Vollständigkeit Willen adressieren wir auch diesen Punkt. Es ist allerdings an dieser Stelle gesagt, dass die Kompetenz für diese Methoden klar in den Handelshäusern liegt, weshalb wir sie nicht weiter thematisieren.

Ziel ist die Implementierung der genannten Use Cases. Häufig muss jedoch besonders im Bankenumfeld festgestellt werden, dass beispielsweise Legacy Datenbanken (technisch), ungeklärte fachliche Verantwortlichkeiten (organisatorisch) oder Regulierung des Umgangs mit Datentypen (regulatorisch) eine ungeahnte Herausforderung für die Umsetzung darstellen.

Technologie – Wo und in welchem Zustand befinden sich meine Daten?

In Banken sind IT-Systeme oft historisch gewachsen. Diese Systeme sind oft monolithisch und nicht vollständig integriert, wobei Daten in isolierten Silos abgelegt werden. Geschäftsbereiche wie Kredit, Zahlungsverkehr oder Wertpapierhandel nutzen separate Systeme ohne nahtlose Integration. Die direkte technische Folge der Fragmentierung ist redundanter Datenbestand und eine komplexe Schnittstellenlandschaft.

Eine zumeist fragmentierte Datenlandschaft, in der beispielsweise Stamm-, Transaktions- und Risikopositionsdaten über separate Systeme verteilt sind, erschweren - wenn nicht verhindern - eine übergreifende Auswertung der Datenbasis. Manche der Systeme arbeiten Batch-basiert (z.B. Konsolidierung der Datengrundlage im täglichen Nachtlauf), sodass Echtzeitanalysen auf der Datenbasis ausgeschlossen werden. Gleiches gilt für hohe Latenzen der ETL-Prozesse aus den Legacy-Datenbanken in analytische Datenhaltungen, sodass Banken häufig nicht auf Echtzeitdaten Analysen fahren. Zudem gestaltet sich die Integration der Systeme in einer über Jahrzehnte gewachsenen Systemlandschaft technisch und fachlich komplex.

Der typische Lösungsansatz zur zentralen Konsolidierung und Harmonisierung der Daten ist der Aufbau einer analytischen Datenhaltung. Je nach Strukturierung und Typ der Daten stehen verschiedene Ansätze zur Auswahl, wobei modernere Ansätze (z.B. Data Lakehouse) nahezu alle Vorteile bieten. Auf dem Weg zur Echtzeitanalyse der Daten fällt die Wahl häufig auf Event-getriebene Architekturen (z.B. Eventstore oder Kafka) um Datenströme aus Legacy-Systemen abzugreifen und verfügbar zu machen. Je nach Anwendungsfall und Fähigkeiten der Datenbanken kann aber auch Batch-getrieben ein Datenabzug stattfinden. Je nach Fähigkeiten und Modularität der Systemlandschaft kann auch über Datenvirtualisierung nachgedacht werden, wobei Datenpunkte in ihren Quellsystemen verbleiben und nur zur Laufzeit abgefragt werden, um so verteilte Datenquellen zu verbinden und harmonisieren doch dabei auf vollständige, physische Migration zu verzichten. Der Einsatz technischer Hilfsmittel kann zudem die Organisation von Daten verbessern und nachvollziehbar machen. Frameworks wie Data Mesh oder eine Medallion Architektur organisieren die fachliche Aufbereitung der Daten und dokumentieren sie technisch um so langfristig den Wert und fachlichen Hintergrund der Daten zu sichern.

Der Teufel steckt jedoch wie häufig im Detail. Die Komplexität steckt in der Kombination und Integration der Legacy- und Ziellandschaft. Lösungen sind dabei häufig Einzelfallentscheidungen, wobei das Gesamtbild im Auge zu behalten ist.

Organisation – was und von wem sind meine Daten?

Nicht nur Daten sind fragmentiert, häufig ist es auch die Organisation. Kopfmonopole und ungeklärte fachliche Verantwortlichkeiten führen perspektivisch zu fehlendem fachlichen Hintergrundwissen und sinkender Datenqualität. Kurz gesagt, die Daten verlieren an Wertigkeit bis sie schließlich ihren Nutzen verlieren. Dieser Wertverlust ist schwer zu bewerten und wird häufig erst bemerkt, wenn es bereits geschehen ist.

Ansätze der Datenorganisation definieren Prozesse im Umgang mit Daten und adressieren damit einige der genannten Defizite, wobei wir im Folgenden eine Auswahl davon diskutieren. Eine Data Governance ist heutzutage in den meisten Unternehmen bereits etabliert (sogar regulatorisch gefordert nach BCBS 239). Sie besteht aus der Definition von Verantwortlichkeiten für bestimmte Daten sowie einer Organisationsstruktur, in der diese Verantwortlichkeiten harmonisiert und nachgehalten werden. Im Data Lifecycle Management wird der zeitliche Verlauf eines Datenpunktes durch die Organisation definiert. Es wird somit sichergestellt, dass kein Datensumpf entsteht, da auch der Zeitpunkt einer Löschung definiert ist. Es wird aber auch definiert, dass Daten zu einem bestimmten Zeitpunkt in einer bestimmten Form vorliegen, was häufig regulatorische Hintergründe hat. Die Nachvollziehbarkeit des Weges und der Transformation eines Datenpunktes durch das System wird im Rahmen der Data Lineage sichergestellt. Dafür werden technische Werkzeuge eingeführt und organisatorische Rahmenbedingungen geschaffen. Dies ist insbesondere dann interessant, wenn Quelldaten oder Datentransformationen sich als fehlerhaft herausstellen, da auch alle daraus resultierenden Datenpunkte nachzuvollziehen sind. Im Rahmen der Data Provenance kann die Herkunft und Historie von Daten nachvollzogen werden, womit die Integrität und Authentizität von Daten sichergestellt wird.

Bei der Einführung solcher Datenorganisation ist vor Allem auf die Einbettung in die übergreifende Organisation zu achten, da besonders gesetztere Strukturen (wie häufig in Banken zu finden) eine gewisse Widerstandsfähigkeit gegenüber Veränderungen zeigen. Eine erfolgreiche Umsetzung allerdings bettet Datenverarbeitung in tägliche Prozesse ein und bildet die Grundlage für eine Daten-getriebene Organisation.

Regulatorik – was darf ich tun mit den Daten?

Je schützenswerter Datenpunkte sind, desto höher sind Anforderungen im Umgang mit ihnen. Mit personenbezogenen und transaktionalen Datenpunkten bewegt sich das Bankenwesen damit im anspruchsvolleren Bereich der Anforderungen. Herausforderungen wie beispielsweise Data Retention im Kontext des Rechts auf Lösung von Daten (DSGVO) ist auch technisch zu definieren. Man steht vor der Herausforderung, regulatorische Compliance mit operativer Effizienz und technologischer Innovation zu harmonisieren. Die steigenden Anforderungen an Datenverarbeitung und -sicherheit erfordern kontinuierliche Anpassungen an neue gesetzliche Vorgaben sowie Investitionen in moderne IT-Infrastrukturen und Datenschutzmaßnahmen. Ein an dieser Stelle erwähnenswerter, vielversprechender Lösungsansatz ist eine effizientere Darstellung von Compliance Dokumenten in Form von Datenpunkten, deren strukturelle Abhängigkeiten technisch mit abgelegt wurden und somit effizientere Prozesse in Abfrage und Anwendung ermöglicht werden.

Doch nicht nur im Umgang mit den Daten, sondern auch im Umgang mit der Regulatorik selbst findet sich beachtliche Luft nach oben. Die Arbeit eines CISOs oder eines Compliance-Mitarbeiters ist geprägt durch textbasierte Analysen, die durch moderne Technologien (z.B. LLM Agents) unterstützt werden können. Im Rahmen eines SOLL-SOLL Abgleichs beispielsweise wird die aktuelle Fassung der im Unternehmen schriftlich fixierten Ordnung (sfO) auf Konsistenz zu sich selbst und gegenüber der regulatorischen Grundlage (z.B. DORA) geprüft. Eine hoch zeitintensive Aufgabe, die erstens Fachkräfte bindet, zweitens eine beachtliche Menge an Beratern beauftragt und drittens meist Event-getrieben, kurzfristig (z.B. angekündigter Audit anstatt kontinuierlich) stattfindet. Zum einen bedeutet dies punktuell einen beachtlichen finanziellen Aufwand und zum anderen ist damit zwischen den Events der aktuelle regulatorische Zustand nicht sicher bestimmt. Wodurch sich neben regulatorischer Unsicherheit auch Effizienzverluste im täglichen operativen Geschäft ergeben.

Eine strukturierte, zentrale Ablage (z.B. Graphen) der Compliance Dokumente zusammen mit modernen Methoden der Textverarbeitung (LLMs) in geeigneten Architekturen (RAG/Agents) mit inhärenter fachlicher Logik (Regelsystem und Workflows) kann diese Arbeit teilautomatisieren und nach Bedarf kontinuierlich ausführen. Die Fachkraft arbeitet im Verbund mit dem System und wird somit entlastet, hält kontinuierlich den Überblick und kann Aufwände besser verteilen.

Zusammenfassend - Wie wird die Datennutzung im Bankwesen umgesetzt?

Die diskutierten Analytics/AI Anwendungsfälle im Banking ermöglichen datengestützte Entscheidungen, Optimierungen und Automatisierungen und erschließen somit Potential der Kosteneinsparung und Serviceangebot für den Kunden aber auch die Bank selbst. Banken fehlt aber häufig die Bais, da ihre Datenhaltung und -verarbeitung, ihre Prozesse und regulatorischen Rahmenbedingungen die Komplexität der Umsetzung deutlich erhöhen. Die Herausforderungen des Spannungsfeldes Technologie-Organisation-Regulatorik gilt es zu navigieren. Es findet sich wieder in den Aspekten der Projekt-/Programmplanung (z.B. Business Case, Timeline), der Kommunikation (z.B. Gremien, Management Kommunikation) aber auch Komplexitätsreduktion (z.B. best Practices, Projektintegration). Sollten Sie an ähnliche Herausforderungen gestoßen sein, oder eine zweite Meinung brauchen, melden Sie sich gern.