Auf einen Blick
Warum KI im Banking erst mit einer gemeinsamen Datenbasis skaliert
Das Problem: Daten-Silos bremsen jede KI-Initiative im Banking
Fraud-Modelle sehen nur die Transaktion, AML läuft im Tages-Batch, und Risiko-Reports brauchen Tage, weil Marktdaten, Positionsdaten und Counterparty-Stammdaten aus drei bis fünf Systemen zusammengezogen werden müssen.
Keine gemeinsame Konten- und Personensicht
Ein Kunde kann mehrere Konten haben, ein Konto mehrere wirtschaftlich Berechtigte. Core Banking, Payments und KYC führen Identitäten getrennt, ohne konsolidierte Sicht auf Personen, Konten und Beteiligungsstrukturen.
Lösung
Eine konsolidierte Identitäts- und Kontenlogik über Personen, Konten, Geräte und Beneficial Owners verbindet alle Domänen auf gemeinsamen Schlüsseln.
Batch-Verarbeitung trifft Echtzeit-Anforderung
AML wird häufig im Tages-Batch geprüft, sodass Transaktionen erst Stunden später als verdächtig markiert werden, während Fraud-Scoring im Zahlungsfluss innerhalb weniger Dutzend Millisekunden entscheiden muss.
Lösung
Eine kontrollierte Feature-Schicht liefert Login-, Geräte- und Transaktionssignale in Echtzeit statt im nächtlichen Report.
BCBS 239 und MiFID II verlangen lückenlose Lineage
Regulatorisches Reporting läuft über eigene Datenmarts mit eigener Berechnungslogik, die mit dem Risikoreport nicht übereinstimmt. Audit-Trails sind unvollständig, weil Lineage zwischen Quellsystem und Reporting-Tabelle bricht.
Lösung
Unity Catalog liefert Berechtigungen, Klassifikationen und Lineage einmal zentral für Core-Banking-, Payments-, KYC- und Risikodaten.
Was unterscheidet Banking-Daten von anderen Branchendaten?
Vier Eigenschaften entscheiden, welche Architektur wirklich passt.
Quellen-Fragmentierung ist der Normalfall
Core Banking, Payments, Trading, KYC, CRM, Risiko- und Regulator-Reports laufen auf eigenen Datenmodellen mit eigenen Konto- und Kundenkennungen.
Regulatorik prägt die Architektur
BCBS 239, MiFID II, DSGVO und Bankgeheimnis gelten parallel. Eine Datenplattform im Banking ist von Anfang an Governance-Pflicht.
Identitäten über Konten, Personen und Beneficial Owners
Ein Kunde mit mehreren Konten, ein Konto mit mehreren wirtschaftlich Berechtigten. Fraud, AML und Risk brauchen eine konsolidierte Sicht.
Hochfrequenz und Latenz im Zahlungsverkehr
Kartenzahlungen, Instant Payments und Logins erzeugen Ereignisse im Millisekundenbereich. Klassische Tages-Batch-Architekturen treffen diese Anforderung nicht.
Datenbasis
Die Lösung: Eine gemeinsame Datenbasis für Fraud, AML und Risk
Was die Datenbasis enthalten muss
Use Cases auf einer Datenbasis
Fraud Detection
Karten-, Instant-Payments- und Login-Events werden mit Verhaltens- und Gerätedaten zu einem Risikoscore pro Transaktion kombiniert, unterhalb der 100-Millisekunden-Grenze, ohne ehrliche Kunden auszubremsen.
AML, KYC & Trade Surveillance
Transaktions-, Konto-, Identitäts- und Sanktionsdaten auf gemeinsamer Basis: Transaction Monitoring auf konsolidierten Mustern, Sanctions Screening und Beneficial-Ownership-Strukturen als Graph.
Credit & Market Risk
IFRS-9-ECL-Modelle, VaR-Berechnungen, FRTB-Sensitivitäten und Stress-Tests für Basel III greifen auf dieselbe Positions-, Markt- und Counterparty-Sicht zu statt auf eigene Extrakte.
Kunden, Vertrieb & Wealth
Konten, Transaktionen, Produkte und Online-Banking-Interaktionen liegen kontrolliert zusammen, Basis für Next Best Offer und Cross-Sell im Privat- und Firmenkundengeschäft.
Vom Tages-Batch zur Echtzeit-Erkennung
Vorher
Nachher
Fraud-Scoring
AML-Prüfung
Risiko-Reporting
Wirtschaftlicher Effekt
KI-Assistenten für Compliance, Fraud, Relationship Management und Audit
Fünf Einsatzfelder entstehen auf derselben Datenbasis.
Compliance-Assistenten für AML-Alerts
Transaktionshistorie, KYC-Profil und Sanktions-Treffer werden zusammengezogen und Investigations-Tickets nach Fallschwere priorisiert.
Fraud-Analyst-Assistenten mit voller Kontosicht
Fraud-Operations greifen kanalübergreifend auf Transaktionen, Login-Verhalten und Geräte-Historie zu, ohne zwischen mehreren Tools zu wechseln.
Relationship-Manager im Firmenkundengeschäft
Produkt-, Risiko- und Transaktionsdaten werden für die Vorbereitung von Kundenterminen kontextbezogen aggregiert.
Risk-Manager-Assistenten für Stress-Tests und ECL
Modellinputs, Szenarioparameter und Ergebnisse werden mit der aktuellen Positions- und Marktsicht abgeglichen.
Audit-Assistenten für Lineage und Modellfreigaben
Datenherkunft, Modellversionen und Freigabe-Schritte aus dem Model Risk Management werden auf derselben Datenbasis abgefragt.
Grenzen von KI im Banking
Auch eine gute Datenplattform ändert nichts daran, dass viele Probleme direkt in Core Banking, Compliance und Aufsicht entstehen.
Datenqualität im Core Banking bleibt der schwierigste Punkt
Dubletten, abweichende Adressformate, lückenhafte Beneficial-Ownership-Daten und uneinheitliche Produktkennungen verzerren jedes Modell, das darauf aufsetzt.
Latenz versus Genauigkeit im Fraud-Scoring
Echtzeit-Scoring auf Karten- und Instant-Payments-Strecken duldet nur wenige zehn Millisekunden. Komplexere Modelle überschreiten dieses Budget.
Regulatorische Modellfreigaben sind eigene Projekte
BaFin-, EBA- und interne Model-Risk-Vorgaben verlangen nachvollziehbare Modellentwicklung, unabhängige Validierung und dokumentierte Freigaben.
Datenschutz, DSGVO und Bankgeheimnis bleiben Pflicht
Berechtigungen auf Spalten- und Zeilenebene sind im Lakehouse machbar; die organisatorische Klärung, welche Rolle welche Daten sehen darf, ist es nicht.
Cloud-Souveränität und EU-AI-Act
Banken müssen Cloud-Strategien, Datenresidenz und Modell-Kategorisierung gegen den EU-AI-Act prüfen, bevor sie Hyperscaler-Architektur ausrollen.
Change-Management in Front Office und Compliance
Ohne Investigations-Prozesse, Schulungspläne und Eskalations-Workflows entsteht eine Plattform mit Modellen, aber ohne Effekt in Loss-Rate oder SAR-Output.
Databricks Premier Partner
Als einer der wenigen DACH-Partner mit Zertifizierungen auf Platform-, Data-Engineering- und ML-Level begleiten wir Financial-Services-Projekte von der Architektur bis zum produktiven Modell. Über 50 Projekte, 10+ Jahre Erfahrung.
Wann lohnt sich eine Lakehouse-Basis?
Mehr als fünf Kernsysteme über Core Banking, Payments, Trading und KYC liefern Daten für KI-Initiativen
Mehr als 10 Millionen Transaktionen pro Tag mit Instant Payments und Kartenzahlungen im Aufbau zu Echtzeit
Drei oder mehr parallele Risiko- oder KI-Initiativen integrieren immer wieder dieselben Quellen
Direkter BCBS-239-, MiFID-II- oder FRTB-Pflicht mit laufender SREP-Prüfung
Externe Prüfung läuft, und Lineage-Lücken zwischen Quellsystem und Report werden im Audit sichtbar
Dann ist jetzt der richtige Zeitpunkt
Fraud Detection ist meist der schnellste Einstieg, weil Loss-Rate und False-Positive-Rate direkt sichtbar werden. Die Datenbasis trägt danach AML, Regulatory Reporting und Risk-Modelle.
Termin vereinbarenGemeinsame Datenbasis für eure Banking-KI?
In einem ersten Gespräch klären wir, welcher Use Case den besten Einstieg bietet und welcher Umsetzungsweg zu eurer Systemlandschaft passt.
