Redaktionell geprüft: 22. Oktober 2026 · Rechtslage geprüft bis: 22. Oktober 2026. Zeitgebundene Aussagen sind datiert; angekündigte, aber noch nicht veröffentlichte Rechtsakte sind als solche gekennzeichnet.
Für wen: Banken (SI) Banken (LSI) Meldewesen-Dienstleister Die Beispiele stammen aus dem Bankenmeldewesen (AnaCredit, FINREP, COREP, VERA); die Kontrollfragen gelten für Versicherer ebenso.
KI rechnet die Meldung nicht – das ist unsere Beratungsposition, kein gesetzliches Verbot. Der Meldewert bleibt deterministisch, regelbasiert und reproduzierbar. KI arbeitet vorgelagert – bei der Datenqualität – und nachgelagert – bei Analyse, Erklärung und Kommentierung. Nicht in der Berechnungsstrecke. Alles auf dieser Seite folgt aus dieser roten Linie.
Wie sieht die Ausgangslage in Zahlen aus?
- Rund 20 % weniger Meldekosten seit 2021. Die Cost-of-Compliance-Studie der EBA vom Juni 2021 (Mandat aus Art. 430 Abs. 8 CRR) mündete in 25 Empfehlungen mit 15 bis 24 % Einsparpotenzial; im Bericht zur Effizienz des Rahmens von 2025 hält die EBA fest, dass die Meldekosten seither um rund 20 % gesunken sind. Die oft zitierte Milliardenzahl ist keine europäische Größe, sondern die weltweite Kostenschätzung eines Anbieters für eine große international tätige Bank.
- 88 Attribute. AnaCredit erfasst Kredit für Kredit 88 Kredit-, Kreditrisiko- und Rechnungslegungsattribute plus Identifikatoren, überwiegend monatlich, ab 25.000 Euro. Die EZB führt darauf Validierungs- und Plausibilitätsprüfungen durch – Letztere ausdrücklich, um Daten zu identifizieren, die wahrscheinlich falsch sind. Die Aufsicht arbeitet längst mit Wahrscheinlichkeiten, während intern binär geprüft wird.
- Viermal im Jahr korrigierte Regeln. Die EBA veröffentlicht quartalsweise Pakete, in denen Validierungsregeln deaktiviert werden, weil sie inhaltlich unrichtig sind oder IT-Probleme verursachen. Die gesamte Qualitätssicherung baut auf einem Regelwerk auf, das sein Urheber selbst regelmäßig korrigiert.
- Ein Basic Cube. Das Gemeinsame Meldewesen-Datenmodell leitet die Smart Cubes – BWG, DevG, EZB-Verordnungen, EBA-ITS – aus einem einheitlichen granularen Datenbestand ab. Das ist dem Rest Europas voraus und hat eine Konsequenz: Ein Fehler in einer Überleitungsregel erzeugt einen Smart Cube, der in sich vollständig schlüssig ist. Alle Prüfregeln grün. Und trotzdem falsch.
Welche blinden Flecken haben die Prüfregeln?
Gemeint sind die EBA-Validierungsregeln und die institutsinternen Prüfregeln, mit denen Meldungen vor der Übermittlung geprüft werden. Sie prüfen definierte fachliche und technische Beziehungen – und ausschließlich die, die jemand vorher als Regel formuliert hat. Die EZB selbst geht bei AnaCredit weiter: Ihre Plausibilitätsprüfungen vergleichen über mehrere Stichtage und gegen andere Datensätze. Intern bleiben aber drei systematische Lücken, die regelbasierte Kontrollen nicht schließen; statistische Verfahren und KI ergänzen sie, ersetzen sie nicht.
| Blind gegenüber … | Was die Regel nicht sieht | Beispiel |
|---|---|---|
| dem Ungesagten | Eine Regel existiert nur dort, wo jemand einen Fehler antizipiert hat. Der teuerste Meldefehler ist der, an den niemand gedacht hat. | Ein Feld liefert seit acht Monaten denselben technischen Vorbelegungswert, weil die Quellstrecke nie angebunden wurde. |
| der Zeit | Prüfregeln arbeiten stichtagsbezogen; sie sehen den Bestand, nicht seinen Verlauf. | Ein schleichender Anstieg von „Ausfallstatus unbekannt“ über sechs Perioden ist zu keinem Stichtag regelwidrig – und in Summe ein massives Qualitätsproblem. |
| dem Nachbarbericht | AnaCredit wird gegen AnaCredit-Regeln geprüft, FINREP gegen FINREP-Regeln. Die Inkonsistenz entsteht dazwischen. | Ein Portfolio steht in FINREP als nicht notleidend, während im granularen Bestand die Ausfallstatus derselben Schuldner gekippt sind. Beide Meldungen bestehen. |
Die Aufsicht arbeitet an genau diesen Lücken – und sagt es öffentlich. Die Banca d’Italia hat 2022 eine Methodik publiziert, mit der gestapelte Machine-Learning-Modelle Anomalien in AnaCredit durch Abgleich gegen Bilanzstatistik und FINREP finden (QEF Nr. 689); die EZB-Statistik führt Anomalieerkennung bei AnaCredit als eigenen Machine-Learning-Anwendungsfall. Für Österreich gilt: OeNB und FMA haben am 15. Dezember 2025 den Austausch mit Banken über konkrete KI-Anwendungen und die Evaluierung von KI in der Aufsicht zu Schwerpunkten 2026 erklärt. Belegt ist damit, dass ein Aufsichtsansatz in Entwicklung ist – nicht, dass OeNB oder FMA KI bereits in der Prüfung von Meldedaten einsetzen.
Wo kann KI im Meldewesen ansetzen?
An sechs Stellen, von der Cross-Report-Rekonziliation über Drift-Erkennung und stille Defaults bis zu Abweichungsnarrativen; KI liefert Kandidaten, keine Meldewerte.
| Ansatzpunkt | Was KI tut | Abgrenzung |
|---|---|---|
| Cross-Report-Rekonziliation | Lernt die normale Beziehung zwischen AnaCredit, FINREP und COREP und meldet, wenn sie bricht – ohne dass jemand die Beziehung als Formel hinterlegt hat. Der Banca-d’Italia-Ansatz, in die Bank hineingezogen. | Das Modell korrigiert nichts. Es erzeugt eine priorisierte Verdachtsliste mit Begründung. |
| Überleitungsstrecke Basic Cube → Smart Cube | Prüft nicht die Regel, sondern deren Wirkung: Verteilungsvergleich Basic Cube gegen Smart Cube, über Perioden, gegen Peers. Nach einem GMD-Versionswechsel wandern Deckungsstock-relevante Summen – auffällig erst als Strukturbruch. | Kein Eingriff in die Modellierung; das Standing Committee bleibt zuständig und bekommt den Hinweis früher. |
| Verteilungs- und Zeitreihen-Drift | Überwacht Verteilungen statt Einzelwerte: Anteil von Defaults, fehlende Optionalattribute, Bewertungsstichtage, Branchencodes, Rundungsmuster. | Ein Alarm ist eine Frage, keine Feststellung. |
| Stille Defaults | Konstanz- und Entropieanalyse über Zeit: Ein Attribut, das seit Monaten denselben Vorbelegungswert liefert, verletzt nie eine Regel – es meldet nur nichts. | Kaum Machine Learning nötig. Der schnellste Nachweis eines Nutzens, geeignet als Pilot. |
| Rückfragelisten-Triage | Clustering der OeNB-Fehler- und Rückfragelisten über Perioden: Welche Fehlerklassen wiederholen sich, an welcher Quellapplikation hängen sie? Aus Symptomkorrektur wird Ursachenanalyse. | Setzt voraus, dass die Rückmeldungen strukturiert archiviert werden – nicht in Postfächern. |
| Impact-Mapping und Abweichungsnarrative | Ein Sprachmodell liest Release Notes, GMD-Versionen, ITS und FAQ gegen das eigene Attributinventar und entwirft Quartalskommentierungen aus den Bewegungsdaten. | Es liest und formuliert. Es entscheidet nicht und rechnet nicht. |
Beleghafte Meldungen: Wie viele haben eine Basic-Cube-Überleitung?
Nur 3 von 13. Alles bisher Gesagte setzt granulare Daten voraus. Beleghafte Meldungen sind die Umkehrung: wenige Zahlen, jede das Ergebnis einer Aggregation oder manuellen Erhebung. Der VERA – Vermögens-, Erfolgs- und Risikoausweis nach § 74 Abs. 1 und 6 BWG – ist dafür das beste österreichische Beispiel. Er besteht unkonsolidiert aus dreizehn Meldungen; bei genau dreien verweist die OeNB auf Überleitungen aus dem Basic Cube (Geschäftsstrukturdaten, Gesicherte Einlagen, Private Wohnimmobilienfinanzierung). Bei den übrigen zehn fehlt dieser Verweis – Erfolgsausweis, Stille Reserven, Vergütungsmeldungen, Beschwerdeabwicklung, Funding Plans und Plandaten stammen aus Hauptbuch, Personalverwaltung, Beschwerdemanagement und Controlling. Wo eine dokumentierte Überleitung existiert, ist die Meldung von unten rekonstruierbar. Wo keine veröffentlichte Standardüberleitung existiert, muss das Institut Herkunft und Berechnung selbst dokumentieren – Hauptbuchbelege, kontrollierte Fachberechnungen und Freigaben sind dann die Nachweise, und sie fehlen häufiger, als die Fachbereiche annehmen. (Zählung nach den OeNB-Meldebestimmungen VERA unkonsolidiert, Stand 22. September 2025; vor Verwendung gegen die aktuellen Erhebungen prüfen.) Daraus folgen drei Klassen mit drei Prüfstrategien – Rekonstruktion, Zeitreihen- und Relationsanalyse, Historien- und Konsistenzanalyse – und vier Schritte, die keine KI voraussetzen: Lineage-Inventur, Kontrollintensität nach Klasse, Overrides protokollieren, Ausweisrichtlinien maschinell lesbar halten.
Die rote Linie: Warum gehört generative Berechnung nicht in die Meldestrecke?
Die Linie trennt drei Dinge: genehmigte fachliche Rechenregeln, die die Meldung erzeugen; validierte und versionierte Modelle, die in Risikomessung und Datenqualität eingesetzt werden; und unkontrollierte generative Berechnung, die in der Meldestrecke nichts verloren hat. Versionierte klassische Modelle sind reproduzierbar – der Punkt ist, dass sie Kandidaten liefern und keine Meldewerte.
- Reproduzierbarkeit. Eine Meldung muss Jahre später mit identischem Ergebnis nachvollzogen werden können. Ein Modell mit Drift, Retraining und Versionsständen kann das ohne strenge Versionskontrolle nicht garantieren.
- Prüfbarkeit. Interne Revision, Wirtschaftsprüfer und Vor-Ort-Prüfung müssen den Weg vom Einzelgeschäft zur Meldeposition nachvollziehen können. In einem Prozess mit dieser Verantwortungsdichte darf KI keine Black Box sein.
- Datenqualität. Gute KI auf schlechten Daten produziert selbstbewusst klingende Fehler – im Meldewesen die teuerste Fehlerart, weil sie durch jede Plausibilitätsprüfung geht.
KI ist im Meldewesen Detektor und Erklärer – nie Rechner.
Welches Regime gilt tatsächlich für Melde-KI?
Eine KI, die AnaCredit-Anomalien detektiert, ist kein Hochrisiko-System nach Anhang III der KI-Verordnung. Anhang III Nr. 5 erfasst im Finanzkontext nur die Kreditwürdigkeitsprüfung natürlicher Personen und die Risikobewertung in der Lebens- und Krankenversicherung. Die Einstufung ist gleichwohl je Anwendungsfall anhand der Zweckbestimmung zu dokumentieren. Die Schlussfolgerung „dann betrifft uns der AI Act nicht“ ist trotzdem falsch – aus drei Richtungen: Die Pflicht zu Maßnahmen für KI-Kompetenz nach Art. 4 gilt seit Februar 2025 (durch den Omnibus als Förderpflicht gefasst), die Transparenzpflichten nach Art. 50 greifen seit 2. August 2026, soweit ein Tatbestand erfüllt ist – etwa bei KI-Interaktion mit Personen oder KI-erzeugten Texten –, und die Sanktionsbefugnisse gelten seit demselben Datum. Der Digital Omnibus (VO (EU) 2026/1744, in Kraft seit 27. Juli 2026) hat die Hochrisiko-Pflichten für Anhang-III-Systeme auf den 2. Dezember 2027 verschoben – Institute mit Retail-Kreditscoring führen deshalb zwei Kalender: einen für die Melde-KI außerhalb von Anhang III, einen für das Kreditgeschäft innerhalb.
Wo der Druck tatsächlich herkommt: DORA ordnet KI dem IKT-Risikomanagement zu; nach Art. 5 Abs. 2 trägt die Geschäftsleitung die Gesamtverantwortung. Die BaFin-Orientierungshilfe vom Dezember 2025 – in Österreich nicht bindend, aber die derzeit ausführlichste deutschsprachige Auslegung – betont Betrieb und Stilllegung: unkontrollierte Deinstallation, veraltete Modellversionen und unzureichend gesicherte Trainingsdaten gelten als erhebliche IKT-Risiken. Und der EZB-Leitfaden zur Risikodatenaggregation verlangt die Anwendung der BCBS-239-Grundsätze auf sämtliche aufsichtsrechtlichen Meldungen – für bedeutende Institute unmittelbar, für österreichische LSI über den LSI-SREP und ab 2027 über EBA/GL/2026/06 als Prüfungsmaßstab.
Der Governance-Rahmen für KI im Meldewesen existiert im Kern bereits. Er heißt nicht AI Act, sondern DORA, RDARR und BCBS 239 – und die KI-Verordnung kommt für Einstufung, Transparenz und Kompetenz hinzu, ersetzt ihn aber nicht. Die Umkehrung ist die gute Nachricht: Wer RDARR ernsthaft umgesetzt hat – Datenqualitätskennzahlen, Lineage, dokumentierte Verantwortlichkeiten, Eskalationswege –, besitzt den überwiegenden Teil der Governance, die er für KI im Meldewesen braucht. Was fehlt, sind die Kontrollfragen des nächsten Abschnitts.
Was beantwortet das Datenglossar nicht?
Sechs Fragen, die ein vorhandener Datenqualitätsrahmen nicht beantwortet und die vor jedem produktiven Einsatz entschieden gehören – sie gehören zu Datenschutz, Bankgeheimnis, Modell-Governance und IKT-Risiko, nicht zur Datenarchitektur:
- Welche Daten dürfen an welches Modell? Meldedaten enthalten personenbezogene und bankgeheimnisrelevante Inhalte; Freigabe je Datenklasse und Modell, nicht pauschal.
- Wer genehmigt die Nutzung? Ein benannter Verantwortlicher je Anwendungsfall und Modelloutput; Inventar als IKT-Asset mit Exit- und Stilllegungspfad (DORA).
- Werden Eingaben zum Training verwendet? Vertraglich ausschließen oder technisch verhindern – bei externen Modellen die erste Frage.
- Welche Rechte hat ein Agent? Lesen, vorschlagen, schreiben: Schreibrechte in Meldestrecken sind nach unserer Position ausgeschlossen.
- Wie werden Modellwechsel, Fehlalarme und Prompt Injection behandelt? Versionierung, Fehlalarmquote als Kennzahl, Schutz gegen manipulierte Eingaben aus Dokumenten.
- Was passiert bei Ausfall? Die Meldung muss ohne das Modell termingerecht entstehen – sonst ist es Teil der Berechnungsstrecke.
Wie stuft man einen KI-Anwendungsfall in zehn Minuten ein?
Fünf Fragen zu einem konkreten KI-Anwendungsfall im eigenen Meldeprozess:
- Greift das System in die Berechnung der Meldeposition ein – ja oder nein?
- Werden personenbezogene Bonitätsentscheidungen (Anhang III Nr. 5 lit. b) oder – bei Versicherern – Risikobewertung und Preisbildung in der Lebens- und Krankenversicherung (lit. c) berührt – ja oder nein? (Anhang-III-Test)
- Ist das System als IKT-Asset inventarisiert, inklusive Exit- und Stilllegungspfad? (DORA)
- Ist die Wirkung auf die Datenqualität der Aufsichtsberichterstattung dokumentiert? (RDARR)
- Existiert ein benannter menschlicher Verantwortlicher für jedes Modelloutput? (alle drei)
Wohin entwickelt sich das Meldewesen?
Richtung Granularität. Das Integrated Reporting Framework der EZB konsolidiert die statistischen Meldeanforderungen der Euroraum-Banken; der Pilot ist für das zweite Quartal 2030 vorgesehen, der Meldebetrieb für 2031. Je granularer und besser abgestimmt die Datenbasis, desto verlässlicher lassen sich Modelle darauf anwenden. Für Österreich ist das eine bemerkenswerte Ausgangslage: Der Basic Cube ist strukturell genau das, worauf Europa 2031 zusteuert. Das ist ein Vorsprung – vorausgesetzt, er wird analytisch genutzt und nicht nur als Meldemaschine.
Alles, was aus Deutschland (BaFin) oder Italien (Banca d’Italia) stammt, ist hier Auslegungshilfe oder methodisches Vorbild – nie geltendes österreichisches Recht. EU-Verordnungen (KI-VO, DORA, AnaCredit-VO, CRR) gelten unmittelbar. Das GMD und die Aufsichtsschwerpunkte 2026 sind die genuin österreichischen Anker.
Häufige Fragen
Ist eine KI zur Datenqualitätsprüfung im Meldewesen ein Hochrisiko-System?
Nein. Anhang III Nr. 5 der KI-Verordnung erfasst im Finanzkontext nur die Kreditwürdigkeitsprüfung natürlicher Personen und die Risikobewertung in der Lebens- und Krankenversicherung. Datenqualitätsprüfung im Meldewesen fällt unter keinen der Tatbestände. Art. 4 (KI-Kompetenz) und Art. 50 (Transparenz) gelten dennoch.
Darf KI die Meldung berechnen?
Rechtlich ist das nicht verboten; aus unserer Sicht sollte sie es nicht – aus Reproduzierbarkeits- und Prüfbarkeitsgründen. Eine Meldung muss Jahre später identisch nachvollziehbar sein; ein Modell mit Drift und Retraining garantiert das ohne strenge Versionskontrolle nicht. KI gehört vor und hinter die Berechnungsstrecke.
Womit sollte ein Haus anfangen?
Mit den stillen Defaults: Eine Konstanz- und Entropieanalyse über Zeit braucht kaum Machine Learning, liefert den schnellsten messbaren Nutzen und macht sichtbar, was heute niemand prüft, weil keine Regel dafür existiert.
Welche Governance braucht eine Melde-KI?
Im Kern dieselbe wie RDARR: Datenqualitätskennzahlen, Lineage, dokumentierte Verantwortlichkeiten, Eskalationswege – angewandt auf den KI-Anwendungsfall, plus Inventarisierung als IKT-Asset nach DORA mit Exit- und Stilllegungspfad. Dazu kommen die dokumentierte Einstufung nach der KI-Verordnung, Datenschutz und Bankgeheimnis bei der Datenfreigabe, Versions- und Modellwechselkontrolle und die Absicherung externer Modelle.
