+150 XP

Die Datenlandschaft einer Bank kartieren: Core, Kanäle und Bureaus

# Die Datenlandschaft einer Bank kartieren: Core, Kanäle und Bureaus

Ein Kunde ruft an und bestreitet eine Belastung von 47 $ vom letzten Dienstag. Wo liegt die „Wahrheit" zu dieser Transaktion? Nicht an einem Ort. Das Kartennetzwerk hat sie zuerst gesehen, das Kernbankensystem hat sie gebucht, die Mobile App hat sie angezeigt, und eine Fraud Engine hat sie gescort. Fünf Systeme, fünf Zeitstempel, fünf leicht unterschiedliche Versionen desselben Ereignisses.

Zu wissen, welches System für welche Frage maßgeblich ist, ist die nützlichste Fähigkeit in der Bankdatenarbeit. Diese Lektion kartiert die Landschaft, damit Sie jederzeit die Source of Record benennen können.

Das Kernbankensystem: das Ledger of Record

Das Kernbankensystem (oft nur „der Core") ist das Master-Ledger. Es hält Konten, Salden und die gebuchten Transaktionen, die Geld bewegen. Denken Sie daran als das Hauptbuch für jede Kundenbeziehung.

Zu den großen Cores im Jahr 2026 zählen FIS, Fiserv, Temenos und Jack Henry, dazu neuere cloud-native Anbieter wie Thought Machine und Mambu. Große Banken betreiben oft mehrere Cores, die nach Jahrzehnten von Fusionen zusammengeflickt sind. Deshalb kann ein einzelner Kunde als drei verschiedene IDs existieren.

Wofür der Core maßgeblich ist:

  • Gebuchte Salden (Tagesende, valutiert)
  • Kontoinhaberschaft und Status (offen, ruhend, geschlossen)
  • Das offizielle Transaktions-Ledger nach Settlement

Worin der Core NICHT gut ist: Echtzeitsichten. Cores laufen traditionell über Batch Processing, das heißt, Transaktionen werden gesammelt und in geplanten Läufen gebucht (oft über Nacht). Der Saldo im Core um 14 Uhr spiegelt also möglicherweise nicht den Kaffee wider, den Sie um 13:55 Uhr gekauft haben.

Entscheidende Unterscheidung für jeden Analysten: Buchungsdatum (wann der Core es erfasst hat) versus Transaktionsdatum (wann es passiert ist). Diese zu verwechseln, ruiniert Reconciliation und Fraud-Analyse.

Card Switches und Payment Rails: die Schicht des Geldes in Bewegung

Bevor eine Transaktion den Core erreicht, läuft sie durch Netzwerke.

Ein Card Switch ist das System, das Kartentransaktionen in Echtzeit routet und autorisiert. Wenn Sie eine Karte auflegen, prüft der Switch die Deckung, wendet Limits an und liefert in unter zwei Sekunden ein Approve oder Decline. Der Switch spricht mit den Netzwerken: Visa, Mastercard und in den USA das inländische Debit-Routing unter Regulation II (den Durbin-Amendment-Regeln zu Debit-Interchange und Netzwerkwahl).

Payment Rails sind die Leitungen, durch die Geld fließt. Die wichtigsten für 2026:

  • ACH (Automated Clearing House): Batch-Überweisungen von Bank zu Bank in den USA, Löhne und Rechnungen.
  • Fedwire und CHIPS: US-Wires mit hohen Beträgen.
  • FedNow und RTP: Instant Payments in den USA, Settlement in Sekunden, rund um die Uhr.
  • SEPA in der Eurozone und TARGET2 / T2 für Euro-Settlement hoher Beträge.
  • SWIFT: der Messaging-Standard für grenzüberschreitende Zahlungen.

Warum das für Daten wichtig ist: Autorisierungsdaten (vom Switch) und Settlement-Daten (von der Rail und dem Core) sind getrennte Datensätze mit getrennten Zeitstempeln. Eine Kartenautorisierung kann genehmigt werden und dann nie zum Settlement kommen. Wenn Sie Autorisierungen als Umsatz zählen, überschätzen Sie ihn.

Die Branche standardisiert Messaging auf ISO 20022, ein strukturiertes Format, das weit reichhaltigere Zahlungsdaten trägt (vollständige Remittance-Details, strukturierte Adressen) als Legacy-Formate. Für Datenteams ist das ein Geschenk: saubere, besser maschinenlesbare Zahlungsdatensätze. Das ISO 20022 resource centre bietet die Spezifikationen kostenlos.

Digitale Kanal-Logs: Verhalten, nicht Salden

Jeder Tap in der Mobile App und jeder Klick im Online-Banking erzeugt Kanal-Logs oder Event Streams. Das sind Clickstream-Daten: Login-Events, Page Views, Überweisungsversuche, fehlgeschlagene Logins, Device Fingerprints.

Kanaldaten beantworten Verhaltensfragen, die der Core nicht beantworten kann:

  • Wie viele Kunden haben das Wire-Transfer-Formular abgebrochen?
  • Von welchem Gerät kam der Login?
  • Hat der Kunde die Gebührenaufstellung angesehen, bevor er sich beschwert hat?

Diese Daten landen meist in einer Event-Pipeline (Kafka ist üblich) und dann in einem Data Lake oder Warehouse (Snowflake, Databricks, BigQuery). Sie sind hochvolumig, semi-strukturiert und haben oft keinen saubereren Kontoschlüssel, sodass der Join mit dem Core eine Identity-Resolution-Schicht braucht.

Kanal-Logs sind auch zentral für Fraud und Security. Ein Login von einem neuen Gerät in einem neuen Land, gefolgt von einer Änderung des Zahlungsempfängers und einer großen Überweisung, ist ein klassisches Account-Takeover-Muster, das nur in Kanaldaten sichtbar ist.

Credit Bureaus: die externe Sicht

Credit Bureaus halten Daten darüber, wie Verbraucher bei all ihren Kreditgebern Kredite aufnehmen und zurückzahlen. In den USA sind die Big Three Equifax, Experian und TransUnion. In Großbritannien sind es Experian, Equifax und wiederum TransUnion; andere europäische Märkte haben nationale Bureaus (zum Beispiel die SCHUFA in Deutschland).

Bureau-Daten sind extern und für eine Sache maßgeblich: das Kreditverhalten eines Kunden bei anderen Instituten. Sie speisen das Credit Scoring (die US-Modelle FICO und VantageScore greifen auf Bureau-Akten zu).

Zwei Datenrealitäten, die zu respektieren sind:

1. Bureaus sind nicht in Echtzeit. Kreditgeber melden typischerweise monatlich, eine Bureau-Akte kann dem tatsächlichen Verhalten also Wochen nachlaufen.

2. Bureau-Daten sind stark reguliert. In den USA regelt der Fair Credit Reporting Act (FCRA), durchgesetzt vom Consumer Financial Protection Bureau (CFPB) und der FTC, Richtigkeit, Widerspruchsrechte und den zulässigen Zweck. Sie können keinen Bureau-Report abrufen, ohne einen rechtmäßigen Grund zu haben. In der EU gelten GDPR und nationale Regeln.

Alles zusammen: die Karte der maßgeblichen Quellen

Die Kernfähigkeit: zu jeder Frage das System of Record benennen.

| Frage | Maßgebliche Quelle |

|---|---|

| Wie hoch ist der valutierte Saldo? | Kernbankensystem |

| Wurde diese Kartenzahlung autorisiert? | Card Switch |

| Wann wurde die Überweisung tatsächlich gesettelt? | Payment Rail (Fedwire/RTP/TARGET2) |

| Welches Gerät hat sich um 14:03 Uhr eingeloggt? | Kanal-Logs |

| Wie hoch ist die Gesamtverschuldung des Kunden extern? | Credit Bureau |

| Wem gehört dieses Konto rechtlich? | Kernbankensystem |

Wenn zwei Systeme widersprechen, sagt Ihnen diese Karte, welchem Sie für genau dieses Feld vertrauen. Das ist der ganze Kern von Data Lineage: einen Datenpunkt bis zu seinem Ursprungssystem zurückverfolgen.

Ein durchgerechnetes Reconciliation-Beispiel

Reconciliation ist der Vergleich zweier Datensätze, die übereinstimmen sollten. Hier der häufigste Fall: Kartenautorisierungen versus Core-Buchungen.

Angenommen für einen einzelnen Tag (illustrative Zahlen, keine echten Bankdaten):

  • Der Card Switch meldet 10.000 Autorisierungen über insgesamt 430.000 $
  • Der Core bucht 9.850 gesettelte Transaktionen über insgesamt 421.000 $

Die Lücke:

Auth count 10,000 - Posted count 9,850 = 150 unposted items
Auth value $430,000 - Posted value $421,000 = $9,000 unsettled
Settlement rate = 9,850 / 10,000 = 98.5%

Eine Same-Day-Settlement-Rate von 98,5 % ist normal: Manche Autorisierungen fallen weg (eine freigegebene Hotelreservierung, ein abgelehnter Capture, ein Händler, der nie gesettelt hat). Die Aufgabe ist, die 1,5 % zu erklären, nicht in Panik zu verfallen. Fiele die Rate plötzlich auf 90 %, signalisiert das einen Feed-Ausfall zwischen Switch und Core, also einen echten Datenqualitätsvorfall.

Wissenscheck

1. Ein Analyst untersucht eine bestrittene Belastung und stellt fest, dass die Mobile App, der Card Switch und das Kernbankensystem jeweils leicht unterschiedliche Details zur selben Transaktion melden. Welche Schlussfolgerung ist am treffendsten?

2. Ein Kunde kauft um 13:55 Uhr einen Kaffee und prüft um 14:00 Uhr seinen Saldo im Kernbankensystem, doch der Kauf erscheint nicht. Was erklärt das am besten?

3. Warum ist die Unterscheidung zwischen Buchungsdatum und Transaktionsdatum für einen Analysten bei Reconciliation oder Fraud-Analyse entscheidend?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten dazu, wofür das Kernbankensystem maßgeblich ist.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten, die erklären, warum ein einzelner Kunde innerhalb einer Bank unter mehreren verschiedenen IDs existieren kann.

Wählen Sie alle richtigen Antworten aus.

Datenqualität über die gesamte Landschaft

Jede Schicht scheitert auf ihre eigene Weise. Kennen Sie die typischen Defekte:

  • Core: doppelte Kunden-IDs nach Fusionen, veraltete Batch-Salden, die für Echtzeit gehalten werden.
  • Card Switch: Autorisierungen ohne passendes Settlement (Dangling Records).
  • Kanal-Logs: Events ohne auflösbaren Kontoschlüssel, Bot-Traffic, der Zahlen aufbläht.
  • Bureau: veraltete Akten, nicht passende Identitäten (Thin File oder unscharfe Namensabgleiche).

Eine praktische Datenqualitätsmetrik pro Feed ist Completeness: der Anteil der erwarteten Datensätze, der tatsächlich angekommen ist. Wenn der Core normalerweise etwa 500.000 tägliche Transaktionsdatensätze vom Switch erhält und eines Morgens 400.000 bekommt, liegt die Completeness bei 80 % und Sie haben einen defekten Feed, bevor sich irgendein Kunde beschwert.

Die BCBS 239-Prinzipien (ein Standard des Basler Ausschusses zur Aggregation von Risikodaten bei großen Banken) treiben genau diese Disziplin: Richtigkeit, Vollständigkeit und Aktualität mit klarer Lineage. Sie gelten für große Banken, aber ihre Checkliste ist überall gute Praxis.

Wo die Daten 2026 physisch liegen

Die meisten großen Banken fahren heute ein Hybridmodell: Cores und Zahlungssysteme on-premises oder in der Private Cloud (Latenz und Regulierung verlangen das), Kanal-Logs, Bureau-Extrakte und Analytics in einem Cloud-Lakehouse. Die Schicht der Customer Data Platform oder des Golden Record sitzt darüber und löst Identitäten über Cores hinweg auf, sodass aus „Jane Smith" in drei Systemen ein Kunde wird.

Dieser Golden Record ist selbst keine Source of Truth. Er ist eine zusammengefügte Sicht. Wenn Sie die maßgebliche Antwort brauchen, verfolgen Sie sie weiterhin zurück zum Ursprungssystem.

Die wichtigsten Punkte

  • Benennen Sie zu jeder Frage das System of Record. Salden liegen im Core, Autorisierungen im Switch, Settlement in der Rail, Verhalten in Kanal-Logs, externe Verschuldung im Bureau.
  • Zeitstempel sind nicht austauschbar. Transaktionsdatum, Buchungsdatum, Autorisierungszeit und Settlement-Zeit sind unterschiedliche Felder aus unterschiedlichen Systemen. Sie zu verwechseln, ruiniert die Reconciliation.
  • Reconciliation über Schichten hinweg. Eine Same-Day-Settlement-Rate von Auth zu Buchung um 98 % oder höher ist typisch; ein plötzlicher Einbruch signalisiert einen Datenfeed-Ausfall, kein Geschäftsereignis.
  • Bureau-Daten laufen nach und sind rechtlich gesperrt. Sie werden monatlich gemeldet und erfordern einen zulässigen Zweck nach FCRA (USA) oder GDPR (EU).
  • Der Golden Record ist eine zusammengefügte Sicht, nicht die Wahrheit. Für maßgebliche Antworten verfolgen Sie die Lineage immer bis zum Ursprungssystem zurück.