Meinungsbeitrag
Ich lese gerade viel über Meldewesen-Plattformen, denn das Thema ist allgegenwärtig: Jeder hat eine, jeder braucht eine, jeder kauft eine. Aber wenn ich genauer hinschaue, merke ich: Die Frage, die gestellt wird, ist Welche Plattform? – nicht Welche Architektur?
Das ist ein Problem.
„Plattform“ ist ein Vermarktungsbegriff
Wolters Kluwer, Regnology – sie alle nennen ihr Produkt „Plattform“. Das ist legitim, aber der Begriff transportiert keine Architekturentscheidung. Er transportiert lediglich ein Leistungsversprechen, während das, was unter der Haube passiert, meistens unsichtbar bleibt:
- Wo liegt die Daten-Ownership – beim Kunden oder in der Plattform?
- Wie eng sind fachliche Logik und technische Implementierung gekoppelt?
- Was passiert, wenn BIRD/IReF die Anforderungen ändert – ist die Logik austauschbar oder einbetoniert?
- Wer versteht noch, was die Plattform eigentlich tut – der Anbieter, der Kunde, niemand?
Wenn ein Datenfehler auftritt, weiß oft niemand mehr, wo er entsteht. Nicht weil die Menschen inkompetent sind, sondern weil die Plattform eine Blackbox geworden ist.
Plattform vs. Architektur: Der Unterschied
| Plattform-Denken | Architektur-Denken |
|---|---|
| Wir brauchen eine Lösung | Wir brauchen ein Modell |
| Fokus: Features & Lizenzen | Fokus: Schichten, Übergänge, Ownership |
| Datenfluss ist Sache des Anbieters | Datenfluss ist dokumentiert & verstanden |
| Fehlersuche endet beim Support-Ticket | Fehlersuche beginnt im eigenen Haus |
| Abhängigkeit wächst mit jeder Version | Unabhängigkeit durch Verständnis |
| Wechsel = Projekt | Wechsel = kalkulierbar |
BIRD ist kein Datenbuch – BIRD ist Architektur
IReF/BIRD ist im Kern eine explizite Architekturentscheidung der EZB: Input Layer, Transformation Layer, Output Layer. Da definierte Attribute, klare Schichtgrenzen und nachvollziehbare Transformationslogik festgelegt sind, bietet BIRD genau das, was fehlt, wenn nur über Plattformen gesprochen wird: Transparenz über Datenflüsse, Verantwortung für Datenübergänge und Klarheit darüber, wo Logik sitzt und wer sie verantwortet.
Wer BIRD wirklich versteht, versteht Architektur. Und wer Architektur versteht, kann Plattformen beurteilen, steuern – und im Zweifelsfall wechseln.
Die provokante These
Banken, die nur Plattformen kaufen, ohne Architektur zu verstehen, geben Kontrolle ab – über ihre Daten, über ihre Prozesse und über ihre Fähigkeit, Fehler zu verstehen und zu beheben.
Das ist kein Vorwurf an die Anbieter, sondern ein Aufruf an die Fachbereiche. Architektur-Kompetenz gehört nicht nur in die IT, sondern auch in die Fachbereiche, die mit den Daten arbeiten, die Meldungen verantworten und die Qualität sichern. Im Meldewesen sind das wir.
Und noch eine schärfere Frage: Was, wenn die Daten gar nicht granular genug sind?
Eine Meldewesen-Plattform ist im Kern eine Maschine, die Daten in Meldepositionen transformiert. Wenn die Quelldaten nicht granularer werden, macht die Plattform dasselbe wie vorher – nur teurer und mit mehr Abhängigkeit.
Plattformen lösen keine Datenprobleme. Sie verarbeiten Daten.
IReF fordert explizit granularere Daten auf Einzelgeschäftsebene, da dies keine Softwareanforderung ist, sondern eine Datenanforderung. Die Entscheidung „wir kaufen eine neue Plattform für IReF“, ohne gleichzeitig die Datengranularität zu adressieren, ist deshalb im besten Fall unvollständig und im schlechtesten Fall eine teure Ablenkung.
Die Fragen, die vorher gestellt werden müssten:
- Welche Daten fehlen uns heute auf Einzelgeschäftsebene?
- Welche Quellsysteme liefern noch aggregiert statt granular?
- Wer ist verantwortlich für die Datenanreicherung – Meldewesen, IT, Rechnungswesen?
- Was muss sich in der Datenhaltung ändern, bevor eine neue Plattform Sinn ergibt?
Eine Plattform, die nicht-granulare Daten schneller verarbeitet, löst kein Problem. Sie beschleunigt es.
Was ich mir wünsche
- Mehr Gespräche über Datenflüsse – nicht nur über Features
- Mehr Fragen an Anbieter: Wie ist eure Transformationslogik dokumentiert?
- Mehr BIRD-Kompetenz in den Fachbereichen – nicht nur bei der IT
- Weniger Welche Plattform? – mehr Welche Architektur?
Eine gute Plattform und eine gute Architektur schließen sich zwar nicht aus, aber man braucht Architektur-Kompetenz, um eine Plattform beurteilen zu können – nicht andersherum.
Ausblick: Das Ende der Blackbox-Plattform?
Das Data Point Model (DPM) – das Metadatenmodell hinter CoRep, FinRep und den bisherigen EBA-Rahmenwerken – denkt vom Output her: Was muss gemeldet werden? BIRD hingegen denkt vom Input her: Welche Daten existieren, und wie werden sie transformiert?
Das ist ein fundamentaler Paradigmenwechsel, der eine logische Konsequenz für die Architektur hat. Da BIRD als gemeinsames Datenmodell dient, zeichnet sich langfristig eine Struktur ab, die einem Data Warehouse näher ist als einer klassischen Meldeplattform – Staging Layer, Core Layer, Reporting Layer – nur eben regulär. Transparent, schichtenbasiert, mit Datenhoheit beim Kunden.
Die Meldeplattform würde damit zur Ausgabeschicht, weil die Logik nicht mehr in ihr steckt, sondern darunter.
Transparente Schichten, austauschbare Ausgabeschicht, Datenhoheit beim Kunden – nicht trotz Regulierung, sondern durch sie.
Wer diesen Gedanken zu Ende denkt, landet bei Microservices, die sich an einer gemeinsamen Datenbasis bedienen, sodass jeder Melderahmen als eigenständiger Service fungiert – austauschbar, testbar, unabhängig. CoRep als Service, AnaCredit als Service, LCR als Service. Alle lesen aus derselben granularen, BIRD-konformen Datenbasis.
Änderung in IReF? Nur der IReF-Service wird angefasst, während alle anderen Rahmen unberührt bleiben. Neue Anforderung? Neuer Service – kein Plattform-Release.
Das ist kein Zukunftsroman, sondern der logische nächste Schritt aus dem, was BIRD architektonisch vorgibt. Dazu mehr in einem eigenen Artikel.
Wie seht ihr das? Habt ihr das Gefühl, dass Architektur-Fragen im Meldewesen zu kurz kommen – oder übertreibe ich? Ich freue mich auf die Diskussion, auch – und gerade – auf Widerspruch.
#Meldewesen #BIRD #IReF #Architektur #Datenqualität #DataGovernance #Bankenmeldewesen #RegulatoryDataScientist #Meinung
