Integrationsmuster für Banken und Finanzdienstleister: Batch, API und die Schicht dazwischen

Von Einzelverbindungen zur Architektur

Im ersten Teil dieser Serie haben wir die Datenlücken zwischen Banken und externen Finanzdienstleistern analysiert: interne Silos, externe Brüche, fragmentierte Systemlandschaften. Das Problem ist klar. Die Frage ist: Wie sieht eine Lösung architektonisch aus?

Die Antwort ist nicht eine einzelne Schnittstelle. Es ist eine Integrationsschicht.

Was eine Integrationsschicht leistet

Eine Integrationsschicht ist kein Produkt, das man kauft und einschaltet. Sie ist ein architektonisches Konzept: eine dedizierte Ebene zwischen den beteiligten Systemen, die drei Aufgaben übernimmt.

Datennormalisierung: Verschiedene Systeme verwenden verschiedene Formate, Feldbezeichnungen und Datenmodelle für dieselben Informationen. Die Integrationsschicht übersetzt — sie stellt sicher, dass "Geburtsdatum" im Maklersystem und "BIRTH_DATE" im Kernbanksystem dasselbe Feld beschreiben und konsistent befüllt sind.

Orchestrierung: Nicht jede Information muss sofort übertragen werden. Manche Daten werden täglich im Batch synchronisiert, andere in Echtzeit. Die Integrationsschicht steuert, welche Daten wann und wie fließen.

Fehlerbehandlung: Wenn eine Übertragung fehlschlägt — weil ein System nicht erreichbar ist, ein Datensatz ungültig ist oder ein Timeout auftritt — muss das erkannt, protokolliert und behandelt werden. Ohne Integrationsschicht verschwinden Fehler in Logdateien, die niemand liest.

Drei Integrationsmuster in der Praxis

In der Praxis bewähren sich drei Grundmuster, die sich je nach Anforderung kombinieren lassen:

Muster 1: Batch-Verarbeitung

Das älteste und am weitesten verbreitete Muster. Daten werden in regelmäßigen Intervallen — täglich, stündlich, wöchentlich — gebündelt übertragen.

Wie es funktioniert: Ein System exportiert einen Datensatz (zum Beispiel alle geänderten Kundenstammdaten seit dem letzten Lauf). Die Integrationsschicht nimmt die Daten entgegen, prüft und normalisiert sie, und leitet sie an das Zielsystem weiter.

Stärken:

• Robust und erprobt — Batch-Verarbeitung ist seit Jahrzehnten Standard in der Bankenwelt

• Geringes Risiko bei der Einführung — bestehende Systeme müssen nicht umgebaut werden

• Gut handhabbar für große Datenmengen

Grenzen:

• Daten sind immer so alt wie das Batch-Intervall — bei täglicher Verarbeitung bis zu 24 Stunden verzögert

• Änderungen zwischen zwei Läufen können zu inkonsistenten Zuständen führen

• Fehlererkennung erfolgt zeitversetzt

Muster 2: API-basierte Echtzeit-Integration

Systeme kommunizieren direkt miteinander über definierte Schnittstellen (APIs). Eine Änderung in System A wird sofort an System B übermittelt.

Wie es funktioniert: Wenn ein Makler eine Adressänderung erfasst, sendet seine Software die Änderung über eine API an die Integrationsschicht. Diese prüft, normalisiert und leitet sie in Echtzeit an das Kernbanksystem weiter.

Stärken:

• Daten sind aktuell — keine Verzögerung durch Batch-Intervalle

• Fehler werden sofort erkannt und können sofort behandelt werden

• Ermöglicht interaktive Prozesse (zum Beispiel Bonitätsprüfung während des Beratungsgesprächs)

Grenzen:

• Höhere Komplexität in der Implementierung

• Abhängigkeit von der Verfügbarkeit aller beteiligten Systeme

• Erfordert stabile und performante Netzwerkverbindungen

Muster 3: Ereignisbasierte Integration

Eine Weiterentwicklung der API-Integration. Statt direkter Aufrufe publizieren Systeme Ereignisse ("Kunde hat Adresse geändert", "Neuer Vertrag angelegt"), die von interessierten Systemen abonniert und verarbeitet werden.

Wie es funktioniert: Das Maklersystem publiziert ein Ereignis. Die Integrationsschicht nimmt es entgegen und verteilt es an alle Systeme, die dieses Ereignis abonniert haben — Kernbanksystem, Compliance-System, CRM.

Stärken:

• Entkopplung: Sender und Empfänger müssen sich nicht kennen

• Skalierbar: Neue Systeme können angebunden werden, ohne bestehende Verbindungen zu ändern

• Ausfallsicher: Ereignisse können zwischengespeichert werden, wenn ein Zielsystem temporär nicht erreichbar ist

Grenzen:

• Konzeptionell anspruchsvoller — erfordert sauberes Ereignisdesign

• Reihenfolge und Konsistenz müssen explizit sichergestellt werden

• Monitoring und Nachvollziehbarkeit erfordern eigene Werkzeuge

Kein Entweder-Oder

In der Praxis setzen die meisten Integrationsarchitekturen auf eine Kombination dieser Muster. Stammdaten-Synchronisation läuft im Batch, weil sie robust und beherrschbar ist. Prozessrelevante Daten — Finanzierungsanfragen, Bonitätsprüfungen, Dokumentenanforderungen — laufen über APIs in Echtzeit. Ereignisbasierte Muster ergänzen dort, wo mehrere Systeme gleichzeitig informiert werden müssen.

Die Integrationsschicht macht diese Kombination möglich, weil sie die Komplexität bündelt. Ohne sie müsste jedes Quellsystem wissen, welches Zielsystem welches Muster erwartet. Mit ihr genügt es, die Daten einmal in die Schicht zu liefern — die Verteilung übernimmt die Architektur.

Die Rolle der Datennormalisierung

Ein Aspekt verdient besondere Betonung, weil er häufig unterschätzt wird: die Normalisierung.

Kernbanksysteme, Maklersoftware und Verbundpartnersysteme verwenden unterschiedliche Datenmodelle. Nicht nur unterschiedliche Feldnamen, sondern unterschiedliche Granularitäten, Schlüsselkonzepte und Aktualisierungslogiken.

Beispiel: In einem System ist "Kunde" eine natürliche Person. In einem anderen ist "Kunde" ein Haushalt. In einem dritten ist "Kunde" eine Vertragsbeziehung. Alle drei meinen denselben Menschen — aber ihre Datensätze lassen sich nicht 1:1 aufeinander abbilden.

Die Integrationsschicht muss diese Unterschiede kennen und überbrücken. Das erfordert ein gemeinsames Datenmodell (ein "kanonisches Modell"), das als Referenz dient. Jedes angebundene System wird auf dieses Modell gemappt. Das ist kein triviales Unterfangen — aber es ist die Voraussetzung dafür, dass Integration zuverlässig funktioniert.

Wie es weitergeht

Im dritten und letzten Teil dieser Serie geht es um den konkreten Weg: Wie kommt eine Bank von der Diagnose zur funktionierenden Integrationsarchitektur? Welche Schritte sind realistisch, welche Reihenfolge hat sich bewährt, und welche Erwartungen sind angemessen?

Nächster Schritt

Welche Integrationsmuster für Ihre Systemlandschaft sinnvoll sind, hängt von Ihren konkreten Systemen, Partnern und Prozessen ab. In einem unverbindlichen Erstgespräch können wir gemeinsam einschätzen, wo Sie stehen und welche Architekturansätze in Ihrem Kontext realistisch sind.

Erstgespräch vereinbaren ->