Teil 1: Anforderungen und Komplexitätstreiber von Integrationsplattformen

Einleitung

Für viele moderne Unternehmen ist es essenziell, eine integrierte Sicht auf ihre Daten zu haben, da dies ihnen ermöglicht, schnell und effizient Veränderungen im Markt zu erkennen und ihr Geschäftsmodell entsprechend anzupassen. Dieses Ziel der integrierten Datensicht trifft besonders auf Banken und ihre (Daten-)Integrationsplattformen zu: Erstens sind Bankprodukte überwiegend digital, somit datenbasiert und gleichzeitig die Grundlage ihres Geschäftsmodells. Zweitens bestehen aufgrund regulatorischer Anforderungen besonders hohe und rechtlich bindende Ansprüche an die Transparenz, Dokumentation und Nachvollziehbarkeit ihrer Datenströme. Diese Anforderungen werden unter dem Begriff der Data Governance zusammengefasst, deren Zusicherung eine wesentliche Aufgabe vieler Integrationsplattformen in Banken darstellt. In diesem Artikel konzentrieren wir uns auf Anforderungen und Komplexitätstreiber für Integrationsplattformen, bei denen solche aufsichtsrechtlichen Vorgaben eine große Rolle spielen.

Als Integrationsplattform bezeichnen wir ein IT-System, dessen Ziel die (fachliche) Integration von Daten und das Bereitstellen dieser Daten für verschiedene Abnehmersysteme ist. Eine Integrationsplattform nimmt also Daten operativer Quellsysteme entgegen, bereitet diese entsprechend den Bedürfnissen des Unternehmens auf und stellt sie anderen Abnehmersystemen in einer integrierten, fachlich konsolidierten Sicht zur Verfügung. Typische Beispiele für analytische und nachgelagerte Abnehmersysteme sind Business Intelligence-, Reporting- und Machine Learning-Systeme. Integrationsplattformen stellen aber nicht nur analytische Daten zur Verfügung, sondern oft auch operative Daten zur Weiterverarbeitung und Aufbereitung.

Projekte zum Aufbau oder zur Erneuerung einer Integrationsplattform stellen Banken oft vor große technische, fachliche und organisatorische Herausforderungen. Eine Explosion der Kosten und Projektlaufzeiten bei gleichzeitig niedriger Lieferfrequenz und -qualität sind in diesem Umfeld üblich, insbesondere in Unternehmen ohne ausgeprägte Tech-Kultur. Dabei ist oft eine Ursache des Problems, dass ein für das konkrete Projekt unpassender architektureller Schnitt gewählt wird, der es unmöglich macht, das Projekt auch langfristig effizient und in kleinen Inkrementen zu liefern (entsprechend moderner Vorgehen wie Continuous Delivery oder Lean Software Development). Erschwert wird dieses Problem durch die folgenden bankentypischen Spezifika:

1. Fachliche Komplexität: Je nach Größe und Geschäftsmodell einer Bank ist die fachliche Komplexität der interagierenden Geschäftsobjekte (und auch die Vielschichtigkeit ihrer Integration) hoch bis sehr hoch. Das äußert sich in einer hohen Anzahl an unterschiedlichen Produkten auf Kredit- und Handelsseite und durch die komplexe Datenstruktur der einzelnen Produkte selbst. Dazu kommt, dass diese fachliche Komplexität vielen Entwicklern besonders fremd und für sie nur mühsam zu erarbeiten ist. Für eine transparente und korrekte Integration müssen also fachliche und technische Experten eng zusammenarbeiten. Dies stellt für viele Organisationen eine große Hürde dar.

2. Heterogenität: Banken besitzen oft eine heterogene IT-Landschaft aus einer Vielzahl unterschiedlicher Systeme, z.T. noch Host-basiert. Die Anzahl der IT-Systeme kann durchaus dreistellig sein. Dies gilt insbesondere für Banken, die schon einen Merger hinter sich haben und deren IT-Landschaft nicht vollständig konsolidiert wurde oder werden konnte. Oft sind zudem Details alter oder selbst angepasster Systeme nicht dokumentiert und sind nur noch wenigen Mitarbeitern bekannt. Daher müssen die Schnittstellen dieser Systeme erst explorativ „erforscht“ und dabei im Rahmen der Entwicklung der Integrationsplattform nachdokumentiert werden. In der Praxis entsprechen diese Schnittstellen oft komplett offengelegten Schemata relationaler Datenbanken, die es zu analysieren gilt. Der Aufwand hierfür ist leicht zu unterschätzen, gilt es doch oft diffizile Sonderfälle zu verstehen und adäquat abzubilden.

Folgende vereinfachte Grafik verdeutlich die Komplexität der Integrationslösung auf Basis der o.g. zwei Dimensionen:

In diesem zweiteiligen Artikel beantworten wir folgende Fragen:

Teil 1: Welche Anforderungen werden an eine Integrationsplattform im Kontext der Gesamtbanksteuerung (GBS) gestellt?

Teil 2: Aus welchen Alternativen kann ein architektureller Schnitt ausgewählt werden? Welche Vor- und Nachteile bieten sie und unter welchen Bedingungen sollte man welche wählen?

Im vorliegenden ersten Teil konzentrieren wir uns nun zunächst auf die fachlichen Anforderungen und zu erwartenden Komplexitätstreiber, mit denen man in einem solchen Projekt rechnen muss.

Anforderungen an eine GBS-Integrationsplattform

In Banken existieren auf (hoher Abstraktionsebene) große Gemeinsamkeiten, die durch übergreifende, regulatorische Anforderungen und die grundsätzlich ähnliche Organisation der Fachbereiche (nicht zuletzt basierend auf Anforderungen der MaRisk) und somit durch die der Datenabnehmer in der GBS getrieben sind. Im Detail jedoch stellt jede Bank, durch organisatorische und unternehmerische Eigenheiten bedingt, unterschiedliche Anforderungen an eine GBS-Integrationsplattform. Im Folgenden stellen wir die wichtigsten Vertreter solcher typischerweise auftretenden Anforderungen vor.

Die erste und wichtigste Anforderung an eine GBS-Integrationsplattform ist es, die benötigten Geschäftsobjekte aus den quellsystem-spezifischen Formaten auszulesen und fachlich zu integrieren. Das heißt, die Geschäftsobjekte in eine Form zu überführen, die von den fachlichen Mitarbeitern der Bank verstanden wird und korrekt und nachvollziehbar das Geschäft der Kunden abbildet. Zu diesem Zweck ist ein fachliches Modell zu entwickeln, das alle Geschäftsobjekte umfassend beschreibt. Es kann entweder unternehmensweit zentral definiert werden oder verteilt in Domänen mit getrennten Domänen-Modellen vorliegen. Dieses fachliche Modell (bzw. diese Modelle) ist der Dreh- und Angelpunkt der Integration.

Teil der Integrationsleistung ist neben der Definition des Modells auch die Überführung der Quelldaten in dieses Modell. Dabei sollte beachtet werden, dass dies typischerweise nicht nur Datenstrukturangleichungen beinhaltet, sondern oft auch ein Verschmelzen oder Trennen verschiedener Datensätze, etwa durch das Zusammenführen von in unterschiedlichen Quellsystemen geführten Kundenstammdaten. Dabei müssen gegebenenfalls Datensätze komplett neu aus den Quelldaten errechnet werden, wie es zum Beispiel oft zur Abbildung von Kundenverbünden nötig ist.

Weiterhin werden die fachlich integrierten Daten im (Quartals-) Abschlussprozess sukzessiv um weitere Informationen angereichert. Eine zentrale Rolle spielen dabei die aus den GBS-Funktionen – Finanzcontrolling (FiCo), Rechnungswesen (ReWe), Risikocontrolling (RiCo) und Meldewesen (MeWe) – an die Integrationsplattform (zurück-) gelieferten Finanzkennzahlen (bspw. Fair Value (FV), Loss-Given-Default (LGD), Propability of Default (PD)). Die Ermittlung dieser Kennzahlen stellt eigenständige, fachliche Funktionen dar, weshalb diese Kennzahlen i.d.R. von getrennten Systemen („Rechenkernen“) berechnet werden, um sie unabhängig ändern und austauschen zu können. Als Folge muss die Integrationsplattform in der Lage sein, diese Rechenkerne in ihren Produktionsprozess und damit auch in den Integrations- und Abschlussprozess der Bank einbinden zu können.

Letzter Schritt in der Verarbeitung einer Integrationsplattform ist die Bereitstellung der Daten an die jeweiligen verarbeitenden Systeme. Die im fachlichen Modell abgelegten Daten werden typischerweise über eine Export- oder Zugriffsschicht bereitgestellt. Dort kann zusätzlich individuelle fachliche und technische Logik wie Filter-, Selektionskriterien oder Transformationslogik verbaut sein, um spezifische fachliche sowie technische Anforderungen hinsichtlich der Abnehmer zu erfüllen. Typischerweise werden für diesen Zweck Anwendungen aus dem Bereich der Business Intelligence (BI) verwendet.

Die fachlichen Anforderungen an eine GBS-Integrationsplattform sind nicht nur durch Bank-eigene Bedürfnisse, sondern auch durch externe, regulatorische Vorgaben getrieben. Hierbei nimmt vor allem die vom Baseler Ausschuss für Bankaufsicht (Basel Committee on Banking Supervision – BCBS) veröffentlichte Richtlinie BCBS-239 eine wichtige Rolle ein. Diese legt u.a. fest, dass Risikodaten vollständig, aktuell, hochfrequent erzeugbar, genau und verlässlich sowie kurzfristig anpassbar sein müssen.

Weitere wesentliche, fachliche Anforderungen stammen von den zentralen GBS-Nutzern Finanzcontrolling, Rechnungswesen, Risikocontrolling und Meldewesen und werden im Nachfolgenden gegenübergestellt:

Die Unterschiede in den fachlichen Anforderungen der einzelnen Nutzergruppen führen dazu, dass häufig unterschiedliche Rechenkerne in den Fachbereichen zur Ermittlung spezifischer Kennzahlen existieren.

Zudem können fachliche Informationen, wie das Rating auf Kunden- oder Geschäftsebene, innerhalb der Bank nach unterschiedlichen Methodiken ermittelt werden. Ist dies z.B. für eine Kennzahl wie die “Probability of Default” der Fall, ist es entscheidend, die Daten so im Fachdatenmodell abzulegen, dass die fachlichen und methodischen Unterschiede jederzeit transparent bleiben. Nur so kann dem GBS-Abnehmer ermöglicht werden, die für seine Zwecke korrekten Daten anzufordern und so die Überleitbarkeit der Kennzahlen der einzelnen Banksteuerungsbereiche zu gewährleisten.

Aus den Anforderungen der GBS-Systeme leitet sich im Regelfall keine Notwendigkeit einer Real-Time Datenverarbeitung ab. Die zu beliefernden Systeme sind meist auf Batchlieferungen eingestellt, die nicht häufiger als täglich erwartet werden. Dies gilt selbst für Ad-Hoc-Anfragen und Analysen, die Daten in nicht-standardisierten Formaten oder Darstellungen benötigen. Sie funktionieren auch aus fachlicher Sicht meist problemlos mit Daten, die bereits einige Stunden alt, dafür aber konsistent sind.
Gleichzeitig beobachten wir allerdings immer häufiger, dass Daten aus der GBS auch für operative Systeme angefordert werden. Der hohe regulatorische Standard und die konsistente Darstellung macht diese Daten auch attraktiv für z.B. Kreditvergabeprozesse. Begibt man sich auf diesen Pfad, können schnell weitere Anforderungen zu Real-Time-Verarbeitungen entstehen und zu hohen Komplexitäten führen. Dies ist allerdings vorrangig ein technologisches und mikroarchitekturelles Problem. Auf der Ebene der Gesamtarchitektur werden wir es für diesen Artikel ausklammern.

Komplexitätstreiber in der Datenintegration der GBS

Neben den beschriebenen fachlichen Anforderungen wird die Komplexität einer Integrationslösung im GBS-Bereich durch eine weitere Reihe von Faktoren erhöht, die übergreifend für alle Teile der Plattform gelten. Einige begründen sich durch die zu Grunde liegende, fachliche Komplexität, andere beruhen auf der Einhaltung der BCBS-Regulatorik. Im Folgenden nennen wir die wichtigsten Vertreter dieser übergreifenden Komplexitätstreiber:

– Sicherstellung der Vollständigkeit: Für viele fachliche Anforderungen wird ein vollständiges Bild aller Geschäftsobjekte eines Typs (z.B. Geschäfte) benötigt. Dies erfordert oft, die Anlieferung aller Datensätze abzuwarten („Batch“-Betrieb) anstatt auf eingehende Änderungen sofort reagieren zu können.

– Korrekte Granularität: Die Daten müssen in der für die Nutzer notwendigen Granularität aufbereitet werden, z.B. die Bildung von Verbünden aus einzelnen Kunden oder die Aggregation bzw. das Splitting von Geschäften. Es ist Aufgabe des Datenhaushalts, einerseits die richtige Granularität zur Verfügung zu stellen und andererseits bei Granularitätsbrüchen eine saubere Überleitbarkeit herzustellen. Beispielsweise werden die Risk Weighted Assets (RWAs) für Derivate und Collaterals im Meldewesen für einen Kunden i.d.R. gegeneinander aufgerechnet und auf Ebene eines Rahmenvertrags zur Verfügung gestellt. Andere Nutzer interessieren sich jedoch auch für die einzelnen RWAs auf Geschäftsebene.

– Fachliche Transparenz und Konsistenz der Daten hinsichtlich der implementierten Transformationslogik: Für den Nutzer muss immer nachvollziehbar sein, wie erstellte Kennzahlen, aber auch integrierte Daten allgemein, auf Basis der Inputdaten ermittelt wurden. Mit BCBS-239 ist für Banken zudem explizit aufsichtsrechtlich gefordert, dass sie in der Lage sein müssen, die Herkunft und Berechnung ihrer meldungsrelevanten Kennzahlen jederzeit offenlegen zu können. Daher ist ein zentrales Ziel der Datenintegration eine entsprechende Data Lineage erstellen zu können, durch die die Verarbeitungskette der Daten von ihrer Quelle bis zu den errechneten Kennzahlen dargestellt werden kann. Benötigen mehrere Abnehmer dieselbe Kennzahl, ist darauf zu achten, beide mit exakt denselben Werten zu beliefern, d.h. es ist absolute fachliche Konsistenz gefordert. Weiterhin muss eine fachliche Definition integrierter Geschäftsobjekte inklusive aller Felder existieren. Typischerweise werden solche Definitionen über einen Data Catalog zur Verfügung gestellt, also ein zentrales Verzeichnis aller integrierten Objekt-Arten.

– Nachlauffähigkeit: Korrekturen von Geschäften, Geschäftspartnern etc. erfolgen teilweise erst nach Abschluss einer Stichtagsverarbeitung. Das kann es notwendig machen, einzelne Verarbeitungsschritte und Exporte nach Abschluss der eigentlichen Datenverarbeitung erneut zu prozessieren. Werden beispielsweise Kredite erst nachträglich für ein in der Vergangenheit liegendes Datum erfasst oder die Datenlieferung war fehlerhaft, ist eine nachträgliche Verarbeitung der Kreditinformationen an das ReWe notwendig, um abhängige Kennzahlen in der Bilanz korrekt auszuweisen. Der fachliche und technische Schnitt sollte es ermöglichen, einzelne Integrationsplattformkomponenten (für Geschäftsarten, Fachfunktionen, Exporte) unabhängig voneinander verarbeiten zu können, um den Nachlaufbedarf für die unterschiedlichen Abnehmer zu minimieren. Bspw. sollte die Änderung eines Kreditgeschäftes in der Regel keinen Nachlauf der Verarbeitung für Handelsgeschäfte erfordern.

– Historisierung: Die integrierten Daten müssen für einen vorgegebenen Zeitraum historisiert, d.h. versioniert und langfristig vorgehalten werden. Hierfür gibt es mehrere Gründe: Auf der einen Seite gibt es regulatorische Anforderungen, Geschäfte über einen bestimmten Zeitraum und in bestimmten Zeitscheiben (monatlich, vierteljährlich etc.) vorzuhalten. Auf der anderen Seite ist es z.B. aus FiCo-Sicht relevant, Daten über einen längeren Zeitraum zu historisieren (potenziell bis zu 5 Jahre), um Entwicklungen auf Portfolio- und Bankebene nachvollziehen sowie Prognosen treffen zu können. Dazu ist die Historisierung eine zwingende Vorbedingung für die Umsetzung der Nachlauffähigkeit (s.o.). Insbesondere ergibt sich daraus die Notwendigkeit, die Daten nicht nur anhand einer, sondern anhand mindestens zweier (Zeit-) Dimensionen unterscheiden zu können (Bankarbeitstag und Realzeit). So ist es möglich, trotz fachlicher Korrekturen vergangener Stichtage (i.d.R. Ultimos) die in verschiedenen Läufen errechneten Werte zu unterscheiden.

Zusammenfassung

Grundsätzlich konkurrieren im Banking zwei gegensätzliche Anforderungssichten um den idealen Architekturschnitt einer Integrationsplattform: zum einen der Schnitt nach den Produkten der Bank (also nach dem eigentlichen Geschäftsmodell der Bank) und zum anderen der Schnitt nach den vier GBS-Funktionen. Anders als bei anderen Unternehmen kommt bei Banken nicht automatisch der Produktsicht die höchste Bedeutung zu – vielmehr muss beiden Sichten Rechnung getragen werden, um aus Sicht der GBS eine konsistente Datenplattform zu schaffen, die gleichzeitig mit der Entwicklung des Geschäftsmodells der Bank Schritt halten kann. Diese Herausforderung wird ergänzt durch grundsätzliche fachliche Komplexitätstreiber im GBS-Umfeld und durch die hohen regulatorischen Anforderungen, denen Banken genügen müssen. Gemeinsam erhöhen sie den Aufwand und verkomplizieren den Aufbau einer Integrationsplattform für die GBS einer Bank maßgeblich. Diese Einflüsse berücksichtigen wir im zweiten und letzten Teil des Artikels hinsichtlich der Wahl des idealen Lösungsmusters für den architekturellen Schnitt von Integrationsplattformen.