Wissen
Sie haben eingereicht. Sie haben gewartet. Dann kam die Rückmeldungsdatei mit einem Regelcode, den Sie noch nie gesehen hatten, und ohne verständliche Erklärung, was er bedeutet. Dieser Artikel ordnet die Ablehnungscodes ihren Ursachen zu, auf Basis dessen, was die ESAs tatsächlich veröffentlicht haben, statt dessen, was im Netz vermutet wird.
KorrekturNeu geschrieben am 14. Juli 2026. Eine frühere Fassung dieses Artikels beschrieb das Register als Tabellen “B00” bis “B06”, was der Struktur des Registers nicht entspricht. Die tatsächliche Struktur besteht aus den 15 offiziellen Meldebögen B_01.01 bis B_99.01, festgelegt in der Durchführungsverordnung (EU) 2024/2956 der Kommission. Jene Fassung behauptete außerdem eine Validierungs-Engine mit “117 EBA-Regeln”, eine Tabelle mit Ablehnungshäufigkeiten, eine erfundene Namenskonvention für CSV-Dateien, die Behauptung, CSV-Dateien müssten im Wurzelverzeichnis des ZIP liegen, sowie ein durchgerechnetes Beispiel einer gescheiterten Einreichung eines Zahlungsinstituts. Nichts davon ließ sich belegen, und alles wurde entfernt. Jede Ablehnungsursache unten lässt sich nun auf den technischen Regulierungsstandard oder auf ein veröffentlichtes ESA-Dokument zurückführen, und mehrere der in der früheren Fassung genannten Ursachen führen nach den veröffentlichten Belegen der ESAs überhaupt zu keiner Ablehnung.
⚡ Kurzfassung
Die ESAs haben die häufigsten Fehler veröffentlicht, die sie beim Melden des Informationsregisters sehen, samt einer Spalte, ob der jeweilige Fehler zu einer Ablehnung führt. Sieben davon tun das: Verletzungen von Fremdschlüsseln (807), fehlende Primärschlüssel (805), Probleme mit Filing Indicators (808), Dateien außerhalb von DORA oder mit falscher Groß- und Kleinschreibung (720), eine entityID, die nicht zum Dateinamen passt (714), die Struktur der Berichtsdatei (103) und Header-Codes, die nicht in der Taxonomie stehen (801). Fünf häufige Fehler führen nicht zur Ablehnung, darunter fehlende Pflichtwerte und ein falscher LEI. Wenn Sie in einer Schleife aus Wiedereinreichungen feststecken, ist der schnellste Ausweg, die sieben ablehnenden Fehler zu beheben und zu verstehen, dass eine einzige nicht lesbare Datei eine Welle von Fremdschlüsselfehlern auslösen kann, die keine eigene Ursache haben.
Was bei einer Einreichung tatsächlich passiert
Ihre Einreichung ist ein Meldepaket. Die EBA beschreibt dessen Struktur in ihrer Anleitung zur Erstellung des Plain-CSV-Meldepakets für DORA. Das ZIP trägt den Namen des meldenden Subjekts, und darin liegen ein Ordner reports und ein Ordner META-INF. Der Ordner reports enthält report.json, parameters.csv, FilingIndicators.csv und je eine CSV-Datei pro Tabelle. META-INF enthält reportPackage.json.
Das Namensmuster des ZIP
ReportSubject.CON/.IND_Country_FrameworkCodeModuleVersion_Module_ReferenceDate_CreationTimestamp.zip
Das Beispiel der EBA selbst:
DUMMYLEI123456789012.CON_IT_DORA010100_DORA_2024-12-31_20240821141632000.zip
Das meldende Subjekt ist Ihr LEI. .CON oder .IND kennzeichnet eine konsolidierte oder eine individuelle Einreichung. Und der Parameter entityID in parameters.csv muss damit übereinstimmen: Tut er das nicht, melden die ESAs Fehler 714, und 714 führt zur Ablehnung.
Die Prüfungen laufen dann in Schichten ab. Die EBA beschreibt sie in einem Dokument mit dem vollständigen Titel eines Überblicks über die technischen Prüfungen, Validierungsregeln und fachlichen Prüfungen, die die EBA für die RoI-Meldung anwendet. Die technischen Prüfungen betreffen das Paket selbst: Ist es korrekt aufgebaut, stimmen die Dateinamen, ist die Kodierung UTF-8. Die Regeln des Datenpunktmodells betreffen die Tabellen: Stehen die Header-Codes in der Taxonomie, sind die Schlüsselspalten gefüllt, lösen sich die Fremdschlüssel auf. Die fachlichen Regeln betreffen den Inhalt: Existiert dieser LEI wirklich, gibt es diese EUID.
⚠️ Ein Vorbehalt, den die ESAs ihrem eigenen Dokument voranstellen
Die veröffentlichten Beobachtungen tragen einen ausdrücklichen Hinweis: Das Material spiegelt die Auslegung der Meldeinfrastruktur der ESAs wider, und “die Validierungsprüfungen und Rückmeldungen, die die zuständigen Behörden in ihren Meldelösungen für die Erhebung der Informationsregister von Finanzunternehmen umsetzen, können von den auf diesen Folien erläuterten abweichen”. Eingereicht wird beim Portal Ihrer nationalen Aufsichtsbehörde. Lesen Sie deren technische Vorgaben ergänzend zu diesem Text.
Die Fehler, die die ESAs tatsächlich sehen, und welche davon ablehnen
Im April 2025 veröffentlichten die ESAs eine Sammlung von Beobachtungen aus dem Test der Meldung des Informationsregisters, aktualisiert im Mai 2025, mit den häufigsten Fehlern nach Regelcode. Entscheidend ist: Die Liste enthält eine Spalte dazu, ob der jeweilige Fehler zu einer Ablehnung führt. Wir geben diese Zuordnung unten wieder, weil sie die Prioritäten umkehrt, mit denen die meisten Behebungspläne beginnen.
Diese Umkehrung wiegt schwerer, als es klingt. Behebungspläne starten fast immer bei den Daten, weil schlechte Daten wie das ernste Problem wirken und ein Dateiname trivial erscheint. Nach der Zuordnung der ESAs verhält es sich umgekehrt, und ein Team, das zwei Wochen lang Anbieterdatensätze bereinigt, bevor es einen Fehler in der Groß- und Kleinschreibung behebt, reicht erneut ein und wird aus demselben Grund erneut zurückgewiesen.
Diese Umkehrung wiegt schwerer, als es klingt. Behebungspläne starten fast immer bei den Daten, weil schlechte Daten wie das ernste Problem wirken und ein Dateiname trivial erscheint. Nach der Zuordnung der ESAs verhält es sich umgekehrt, und ein Team, das zwei Wochen lang Anbieterdatensätze bereinigt, bevor es einen Fehler in der Groß- und Kleinschreibung behebt, reicht erneut ein und wird aus demselben Grund erneut zurückgewiesen.
| Regelcode | Beschreibung | Führt zur Ablehnung |
|---|---|---|
| 807 | Fremdschlüsselbedingung verletzt | JA |
| 805 | Primärschlüssel fehlt | JA |
| 808 | Filing Indicators fehlen oder Groß- und Kleinschreibung ist falsch | JA |
| 720 | Dateien außerhalb von DORA gemeldet oder Groß- und Kleinschreibung ist falsch | JA |
| 714 | Parameter entityID passt nicht zum Dateinamen | JA |
| 103 | Struktur und Inhalt der Berichtsdatei | JA |
| 801 | Alle Header-Codes der Tabellen müssen in der Taxonomie stehen | JA |
| v8886_m, v8850_m, v8885_m, v8884_m, v8888_m, v88889_m | Pflichtwerte fehlen | NEIN |
| VR_71, VR_23, VR_12, VR_77 | Falscher LEI gemeldet | NEIN |
| 806 | Bei offenen Tabellen dürfen keine identischen Schlüsselwerte gemeldet werden | NEIN |
| VR_72 | EUID-Code wurde in BRIS nicht gefunden | NEIN |
| v8826_m | Gültigkeit der LEI-Maske | NEIN |
Lesen Sie diese Tabelle noch einmal. Fehlende Pflichtwerte führen zu keiner Ablehnung. Ein falscher LEI führt zu keiner Ablehnung. Eine ungültige LEI-Maske führt zu keiner Ablehnung. Eine EUID, die im Business Registers Interconnection System fehlt, führt zu keiner Ablehnung. Doppelte Schlüssel in offenen Tabellen führen zu keiner Ablehnung. Das sind alles echte Datenqualitätsprobleme, sie werden Ihnen alle zurückgemeldet, und Ihre zuständige Behörde kann das in ihrem eigenen Portal anders sehen. Nach der veröffentlichten Zuordnung der ESAs ist es jedoch nicht das, was Ihr Paket zurückwirft. Zurückgeworfen wird es durch die Struktur: Schlüssel, Referenzen, Dateinamen, Filing Indicators, Kodierung und Header.
807: Verletzungen von Fremdschlüsseln und die Kaskade dahinter
Die Verletzung eines Fremdschlüssels steht in der ersten Zeile der ESA-Tabelle und führt zur Ablehnung. Das Register ist relational: Die 15 in Artikel 5 des technischen Durchführungsstandards festgelegten Meldebögen verweisen über Kennungen aufeinander, die Sie selbst vergeben. Die wichtigste davon ist die Referenznummer der vertraglichen Vereinbarung. Artikel 5 und die Erläuterungen in Anhang I halten ausdrücklich fest, dass das Unternehmen für jede vertragliche Vereinbarung mit einem direkten IKT-Drittdienstleister “eine eindeutige ‘Referenznummer der vertraglichen Vereinbarung’ vergibt, um die vertragliche Vereinbarung selbst unmissverständlich zu identifizieren”.
Das durchgerechnete Beispiel der ESAs für einen 807-Fehler ist eine Referenznummer einer vertraglichen Vereinbarung, die in B_07.01, dem Meldebogen zu Bewertungen, auftaucht und in B_02.01, den allgemeinen Angaben zu vertraglichen Vereinbarungen, fehlt. Der Wert ist vorhanden. Er löst sich nur nicht auf.
Die Kaskade, vor der Sie niemand warnt
Hier liegt der Teil, der Teams in der Schleife aus Wiedereinreichungen hält, und er stammt direkt aus den Folien der ESAs. Wenn eine Tabelle überhaupt nicht integriert werden kann, scheitert jede Referenz auf diese Tabelle. Als Beispiele dafür, was eine Integration verhindert, nennen sie einen 801-Fehler, bei dem ein Header-Spaltencode in der Taxonomie fehlt, und einen 805-Fehler, bei dem eine Schlüsselspalte leer ist. Ihr Hinweis zur Folge: “Dann können viele Fremdschlüssel scheitern, und andere Tabellen verweisen auf die Tabelle, die nicht geladen werden konnte. Das ist erwartetes Verhalten, ein Datenbanksystem würde aus demselben Grund scheitern.”
Regel 809, ergänzt am 1. Mai 2025, existiert genau aus diesem Grund. Wenn eine CSV-Datei nicht geparst werden kann, weil die Spaltenzahl im Inhalt nicht zum Header passt, merken die ESAs an, es sei “sehr schwer für die Einreichenden zu verstehen, was der Grund für den 807 ist, wenn wir die Zieltabelle von vornherein nicht integrieren konnten”. 809 sagt es Ihnen daher jetzt direkt.
Die praktische Folge: Wenn Sie eine Rückmeldungsdatei mit fünfzig 807-Fehlern erhalten, beginnen Sie nicht damit, fünfzig Referenzen zu korrigieren. Suchen Sie zuerst nach einem 801, einem 805 oder einem 809. Eine einzige nicht lesbare oder nicht ladbare Tabelle kann beliebig viele nachgelagerte Fremdschlüsselfehler erzeugen, die keine eigene Ursache haben, und die Behebung des einen vorgelagerten Problems räumt sie alle ab.
Paketierung, Dateinamen und Filing Indicators
Vier der sieben ablehnenden Codes betreffen das Paket statt der Daten. Sie sind zugleich am günstigsten zu beheben, sobald man die Regeln kennt, und sie sind wenig intuitiv.
Hier zeigt sich das Melderegime von seiner ärgerlichsten und am schwersten zu rechtfertigenden Seite. Kleingeschriebene Dateinamen oder großgeschriebene Filing Indicators schützen keinen einzigen Verbraucher, und die Regeln erschließen sich vor allem durch das Lesen eines Foliensatzes. Die richtige Reaktion ist, sie einmal in dem Werkzeug zu hinterlegen, das Ihr Paket erzeugt, und danach nie wieder daran zu denken.
Hier zeigt sich das Melderegime von seiner ärgerlichsten und am schwersten zu rechtfertigenden Seite. Kleingeschriebene Dateinamen oder großgeschriebene Filing Indicators schützen keinen einzigen Verbraucher, und die Regeln erschließen sich vor allem durch das Lesen eines Foliensatzes. Die richtige Reaktion ist, sie einmal in dem Werkzeug zu hinterlegen, das Ihr Paket erzeugt, und danach nie wieder daran zu denken.
720: Dateinamen und Schreibweise
Tabellendateien müssen kleingeschrieben benannt sein, zum Beispiel b_01.01.csv. Die Folien der ESAs zeigen einen kleingeschriebenen Dateinamen als akzeptiert und einen großgeschriebenen als abgelehnt, ebenso einen zusätzlichen oder falschen Dateinamen als abgelehnt. Fehlende Dateien werden inzwischen akzeptiert, nach einer Lockerung von Regel 720, doch eine Datei, die nicht ins Paket gehört, wirft es weiterhin zurück.
808: Filing Indicators
Diese Regel erwischt alle, die vernünftigerweise davon ausgehen, dass sie es kenntlich machen sollten, wenn sie zu einem Meldebogen nichts zu melden haben. Die Regel sieht es anders. Alle DORA-Meldebögen werden erwartet. Meldebogen-IDs müssen in Großbuchstaben in FilingIndicators.csv stehen, also B_01.01 statt b_01.01, obwohl die CSV-Datei selbst kleingeschrieben benannt ist. Jede gemeldete Meldebogen-ID muss als wahr deklariert sein, wobei 1 als Wert für wahr zulässig ist. Ein Meldebogen darf leer gemeldet werden, wenn es nichts einzutragen gibt. Doch, in den Worten der ESAs: “gemeldete Meldebogen-IDs, die als falsch oder mit dem Wert 0 deklariert sind, werden mit dem Filing-Indicator-Fehler 808 abgelehnt”.
714: Die entityID muss zum Dateinamen passen
Der Parameter entityID in parameters.csv muss mit dem meldenden Subjekt im ZIP-Dateinamen übereinstimmen. Auch die Kopfzeile von parameters.csv muss stimmen: Regel 723, ergänzt am 1. Mai 2025, verlangt, dass der Header ausschließlich aus name und value in dieser Reihenfolge besteht, weil im XBRL-Standard der Name vor dem Wert steht.
103 und 306: Struktur und Kodierung
103 ist die Prüfung der Struktur der Berichtsdatei. 306 betrifft die Kodierung: Jede Datei im Paket muss UTF-8 sein. Diese Regel wurde am 1. Mai 2025 zu einer fehlschlagenden Regel gemacht, mit der Begründung, dass eine Datei ohne korrektes UTF-8 zu beschädigten Textdaten führt. UTF-8 mit Byte Order Mark wird akzeptiert.
⚠️ Zwei weit verbreitete Annahmen, die nicht zutreffen
Die Spaltenreihenfolge ist frei. Die ESAs stellen unmissverständlich fest, dass in einer Tabellen-CSV “Spaltennamen in beliebiger Reihenfolge stehen können”, und veröffentlichen ein gültiges Beispiel mit zwei vertauschten Spalten. Spaltennamen beachten Groß- und Kleinschreibung und stehen klein, und die Kopfzeile darf keine leere Zelle enthalten, ihre Reihenfolge ist jedoch frei.
Die CSV-Dateien liegen in Unterordnern. Das Meldepaket hat einen Ordner
Die CSV-Dateien liegen in Unterordnern. Das Meldepaket hat einen Ordner
reports und einen Ordner META-INF. Ein flaches Archiv aus CSV-Dateien entspricht der vom Portal erwarteten Struktur nicht.Datentypen: das Präfix eba_, über das alle stolpern
Die Paketierungsanleitung der EBA legt sieben Datentypregeln für die Spalten fest. Sie sind kurz und lohnen eine wörtliche Lektüre, denn die dritte ist die Quelle sehr vieler vermeidbarer Mühen.
Wenn Ihr Register in einer Tabellenkalkulation lebt, ist allein diese Regel ein Argument dafür, den Export zu skripten statt ihn von Hand zu pflegen. Menschen tippen Ländercodes so, wie Menschen sie lesen, und die Taxonomie will die Form mit Eigentümer-Präfix. Über tausende Zellen und eine ganze Meldesaison hinweg hält niemand diese Disziplin durch.
Wenn Ihr Register in einer Tabellenkalkulation lebt, ist allein diese Regel ein Argument dafür, den Export zu skripten statt ihn von Hand zu pflegen. Menschen tippen Ländercodes so, wie Menschen sie lesen, und die Taxonomie will die Form mit Eigentümer-Präfix. Über tausende Zellen und eine ganze Meldesaison hinweg hält niemand diese Disziplin durch.
| Typ | Was die Taxonomie verlangt |
|---|---|
| String (alphanumerisch) | Ein Zeichenkettenwert. Enthält er das Trennzeichen, also ein Komma, muss der Wert in doppelte Anführungszeichen gesetzt werden. |
| Datum | Muss im Format yyyy-mm-dd vorliegen. |
| Aufzählung (geschlossene Optionsliste) | Muss ein Wert aus der Auswahlliste des annotierten Meldebogens sein, mit dem Eigentümer-Präfix eba_. Das Beispiel der EBA ist eba_GA:AT für ein Land. Das ist die am häufigsten missverstandene Regel im gesamten Paket: Ein bloßes AT oder das Wort Austria entspricht dem Aufzählungswert, den die Taxonomie erwartet, nicht. |
| Boolean | Muss entweder true oder false sein, oder 1 oder 0. |
| Monetär | Muss in Einheiten angegeben werden, also weder in Tausend noch in Millionen. Das Beispiel der EBA ist 2540100.23. |
| Ganzzahl | Muss eine Ganzzahl sein. |
| Schlüsselspalten | Ist die Spalte ein Schlüssel, muss sie gefüllt sein. Eine leere Schlüsselspalte ist Regel 805, und 805 führt zur Ablehnung. |
Die Erläuterungen in Anhang I des technischen Durchführungsstandards beschreiben Länderfelder konzeptionell als ISO-3166-1-Alpha-2-Code und Währungsfelder als alphabetischen ISO-4217-Code. Das ist die Bedeutung des Feldes. Getippt wird in die CSV-Datei etwas anderes. Im Meldepaket trägt der Aufzählungswert das Eigentümer-Präfix, weshalb das durchgerechnete Beispiel der EBA für einen Länderwert eba_GA:AT statt AT lautet. Die Basiswährung in parameters.csv erscheint im Beispiel der EBA als iso4217:EUR. Wenn Ihr Export den menschenlesbaren Code schreibt, erkennt die Taxonomie ihn nicht.
LEI und EUID: echte Probleme, die zu keiner Ablehnung führen
Artikel 3 Absatz 5 des technischen Durchführungsstandards verpflichtet Finanzunternehmen, “eine gültige und aktive Rechtsträgerkennung (LEI) oder die Europäische Eindeutige Kennung ... (‘EUID’), und sofern verfügbar beide Kennungen, zu verwenden, um alle ihre IKT-Drittdienstleister zu identifizieren, die juristische Personen sind, mit Ausnahme von natürlichen Personen, die in geschäftlicher Eigenschaft handeln”. Artikel 3 Absatz 6 erweitert dieselbe Anforderung über den direkten Dienstleister auf die Unterauftragnehmer, die Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen tatsächlich tragen.
Beachten Sie die Worte “gültig und aktiv”. Ein strukturell korrekter LEI, der abgelaufen ist, ist kein aktiver. Die ESAs führen fachliche Validierungsregeln gegen eine zwischengespeicherte Kopie der GLEIF-Datenbank aus, ein falscher LEI wird also erkannt. Zurückgemeldet wird er unter Codes wie VR_71, VR_23, VR_12 und VR_77. Nach der veröffentlichten Zuordnung der ESAs führt er zu keiner Ablehnung, was kein Grund ist, ihn falsch zu lassen: Das Register muss zutreffend sein, und Artikel 3 Absatz 3 des technischen Durchführungsstandards verpflichtet Sie, es regelmäßig zu überprüfen und “festgestellte Fehler oder Unstimmigkeiten unverzüglich zu berichtigen”.
Die LEI-Maske, genau genommen
Die Regel, die die EBA anwendet, v8826_m, ist ein regulärer Ausdruck: ^[A-Z0-9]{18}[0-9]{2}$. Achtzehn Zeichen aus A bis Z oder 0 bis 9, gefolgt von zwei Ziffern. Zwanzig Zeichen insgesamt. Beachten Sie, dass die ersten achtzehn Buchstaben oder Ziffern sein dürfen. Beschreibungen des LEI, die auf alphabetischen Anfangszeichen bestehen, geben die tatsächlich geprüfte Maske also falsch wieder.
Die EUID ist eine eigene Kennung
Die EUID ist die Europäische Eindeutige Kennung aus dem Business Registers Interconnection System. VR_72 wird ausgelöst, wenn eine gemeldete EUID dort fehlt. Die ESAs nennen die vermeidbaren Ursachen: ein LEI, der als EUID gekennzeichnet ist, und eine gemeldete EUID, die dem EUID-Muster nicht folgt. Ihre zwei einfachen Prüfungen: Eine EUID sollte einen Punkt enthalten und mit dem zweistelligen ISO-Code eines EWR-Landes beginnen. In den aus dem Test veröffentlichten Zahlen war ein ungültiges EUID-Format mit weitem Abstand die größte Kategorie der EUID-Ergebnisse und übertraf sowohl die gefundenen als auch die nicht gefundenen Fälle deutlich.
Eine Konsequenz gehört ausgesprochen, weil sie aus dem technischen Durchführungsstandard folgt statt aus dem Validator: Dienstleister mit Sitz in Drittstaaten werden allein über einen LEI identifiziert, denn die EUID ist eine europäische Kennung. Einen EUID-förmigen Wert bei einem US-amerikanischen oder indischen Dienstleister einzutragen, funktioniert nicht.
Es besteht die Versuchung, diese Codes bis zum nächsten Jahr liegen zu lassen, sobald man weiß, dass sie zu keiner Ablehnung führen. Widerstehen Sie ihr. Kennungshygiene ist die günstigste Qualitätsarbeit im Register: Eine GLEIF-Abfrage bei der Erfassung dauert Sekunden, während die spätere Klärung, welcher Ihrer Dienstleister eine abgelaufene Kennung trägt, eine Arbeitswoche kostet.
Es besteht die Versuchung, diese Codes bis zum nächsten Jahr liegen zu lassen, sobald man weiß, dass sie zu keiner Ablehnung führen. Widerstehen Sie ihr. Kennungshygiene ist die günstigste Qualitätsarbeit im Register: Eine GLEIF-Abfrage bei der Erfassung dauert Sekunden, während die spätere Klärung, welcher Ihrer Dienstleister eine abgelaufene Kennung trägt, eine Arbeitswoche kostet.
Pflichtwerte und doppelte Schlüssel
Regeln zu Pflichtwerten haben die Form v8886_m und ähnlich und sind bedingte Aussagen im Datenpunktmodell. Das durchgerechnete Beispiel der ESAs besagt im Kern, dass für B_07.01 die Spalte c0080 verpflichtend ist, und sie zeigen zwei Arten des Scheiterns: Die Spalte fehlt vollständig in der Datei, oder die Spalte ist vorhanden und der Wert ist leer. Beides erzeugt denselben Code.
Regel 806 ist die Regel für doppelte Schlüssel: Bei offenen Tabellen dürfen keine identischen Schlüsselwerte gemeldet werden. Wer denselben Schlüssel zweimal meldet, bekommt ihn markiert. Beides führt nach der Zuordnung der ESAs zu keiner Ablehnung. Beides sind echte Mängel der Datenqualität. Artikel 3 Absatz 4 des technischen Durchführungsstandards legt die sechs Grundsätze fest, die Ihre Registerdaten erfüllen müssen: Richtigkeit, Vollständigkeit, Konsistenz, Integrität, Einheitlichkeit und Gültigkeit. Ein Register, das das Portal passiert und dabei diese Grundsätze verfehlt, hat nichts erreicht außer einer Empfangsbestätigung.
Eine strukturelle Regel, die leicht schiefgeht. Artikel 4 Absatz 2 des technischen Durchführungsstandards: “Finanzunternehmen füllen jedes Datenelement mit einem einzigen Wert aus. Ist für ein bestimmtes Datenelement mehr als ein Wert gültig, fügen Finanzunternehmen im entsprechenden Meldebogen für jeden gültigen Wert eine zusätzliche Zeile hinzu.” Zwei Länder, zwei Zeilen. Eine Zelle enthält genau ein Land.
Checkliste vor der Einreichung
Arbeiten Sie sie vor dem Einreichen ab. Sie fängt nicht alles ab und ersetzt das Regelwerk nicht, das Ihre nationale Aufsichtsbehörde tatsächlich anwendet, doch sie deckt die sieben ablehnenden Codes und die dahinterliegenden Strukturregeln ab.
Beim ersten Mal kostet das einen Nachmittag, danach Minuten, denn die meisten Punkte sind Eigenschaften Ihres Exportprozesses statt der Daten dieses Jahres. Genau diese Asymmetrie ist das ganze Argument dafür, die Pipeline zu reparieren statt das Paket.
Beim ersten Mal kostet das einen Nachmittag, danach Minuten, denn die meisten Punkte sind Eigenschaften Ihres Exportprozesses statt der Daten dieses Jahres. Genau diese Asymmetrie ist das ganze Argument dafür, die Pipeline zu reparieren statt das Paket.
Paket und Dateinamen
- Der ZIP-Name folgt dem Muster
ReportSubject.CON/.IND_Country_FrameworkCodeModuleVersion_Module_ReferenceDate_CreationTimestamp.zip, mit Ihrem LEI als meldendem Subjekt. - Die
entityIDinparameters.csvstimmt mit dem meldenden Subjekt im ZIP-Dateinamen überein. Eine Abweichung ist Regel 714, und 714 führt zur Ablehnung. - Tabellendateien sind kleingeschrieben benannt, zum Beispiel
b_01.01.csv. Die EBA-Folien zeigen einen großgeschriebenen Dateinamen, der unter Regel 720 abgelehnt wird. - Das Paket enthält den Ordner
reportsund den OrdnerMETA-INFmitreportPackage.json. Die CSV-Dateien liegen in diesen Ordnern statt lose im Wurzelverzeichnis des ZIP. - Im Paket liegen ausschließlich DORA-Dateien. Zusätzliche oder falsche Dateinamen werden unter 720 abgelehnt.
- Jede Datei ist UTF-8. Seit dem 1. Mai 2025 ist eine Datei ohne UTF-8 Regel 306 und schlägt fehl. UTF-8 mit BOM wird akzeptiert.
Filing Indicators
FilingIndicators.csvführt Meldebogen-IDs in Großbuchstaben auf, zum BeispielB_01.01.- Jede gemeldete Meldebogen-ID ist als
true(oder1) deklariert. Eine alsfalseoder0deklarierte Meldebogen-ID wird unter Regel 808 abgelehnt. - Ein Meldebogen ohne Inhalt wird als leere Tabelle mitgeliefert und dabei als wahr deklariert.
Schlüssel und Referenzen
- Jede Schlüsselspalte ist gefüllt. Ein leerer Schlüssel ist Regel 805 und führt zur Ablehnung.
- Jeder Fremdschlüssel löst sich auf. Das durchgerechnete Beispiel der EBA: Eine Referenznummer einer vertraglichen Vereinbarung, die in B_07.01 steht und in B_02.01 fehlt, scheitert mit 807.
- Kopfzeilen enthalten keine leeren Zellen und keine Spaltencodes, die in der Taxonomie fehlen. Beides ist Regel 801, und ein 801-Fehler in einer Tabelle kann eine Welle von 807-Fehlern in den Tabellen auslösen, die auf sie verweisen.
- Zeilen- und Kommazahl stimmen in jeder CSV-Datei mit dem Header überein. Ein Parsing-Fehler ist Regel 809 und erzeugt dieselbe nachgelagerte Kaskade.
Datentypen
- Datumsangaben liegen als
yyyy-mm-ddvor. - Jeder Aufzählungswert trägt das Eigentümer-Präfix
eba_. - Geldbeträge stehen in Einheiten statt in Tausend.
- Werte mit einem Komma sind in Anführungszeichen gesetzt.
Kennungen
- Jeder LEI passt zu der von der EBA angewendeten Maske:
^[A-Z0-9]{18}[0-9]{2}$, also 18 Zeichen aus A bis Z oder 0 bis 9, gefolgt von zwei Ziffern. - LEIs werden gegen GLEIF geprüft, denn die ESAs führen fachliche Regeln gegen eine zwischengespeicherte Kopie der GLEIF-Datenbank aus.
- EUIDs sind eigenständige Kennungen. Nach der Leitlinie der EBA enthält eine EUID einen Punkt und beginnt mit dem zweistelligen ISO-Code eines EWR-Landes.
Wann eine Ablehnung auf ein tieferes Problem hinweist
Wenn dieselben Fehler nach jeder Korrektur wiederkehren, liegt das Problem meist tiefer als in der Ausführung. Dann wird das Register in einem Werkzeug zusammengestellt, das seine Form nicht halten kann.
Eine oder zwei Ablehnungen bei einer ersten Meldung sind normal und unspektakulär, und niemand sollte darin ein Versagen des Teams sehen. Eine vierte und eine fünfte sagen etwas über den Prozess aus. Dann ist es sinnvoll, das Bearbeiten der Ausgabe einzustellen und dorthin zu schauen, wo die Daten liegen.
Eine oder zwei Ablehnungen bei einer ersten Meldung sind normal und unspektakulär, und niemand sollte darin ein Versagen des Teams sehen. Eine vierte und eine fünfte sagen etwas über den Prozess aus. Dann ist es sinnvoll, das Bearbeiten der Ausgabe einzustellen und dorthin zu schauen, wo die Daten liegen.
Das Register ist ein relationaler Datensatz. Die Referenznummer der vertraglichen Vereinbarung ist ein Schlüssel, auf den mehrere Meldebögen zeigen. Die Funktionskennung muss nach dem technischen Durchführungsstandard für jede Kombination aus LEI des Finanzunternehmens, zugelassener Tätigkeit und Funktion eindeutig sein, und der Standard liefert dafür ein durchgerechnetes Beispiel. Alle Dienstleister in einer IKT-Dienstleistungs-Lieferkette müssen dieselbe Referenznummer der vertraglichen Vereinbarung und dieselbe Art von IKT-Dienstleistungen tragen. Der Rang ist eine natürliche Zahl, stets 1 beim direkten Dienstleister und stets größer als 1 bei einem Unterauftragnehmer. Das sind Integritätsbedingungen. Eine Tabellenkalkulation erzwingt Integritätsbedingungen nicht, sie speichert Text.
| Was gelten muss | In einer Tabellenkalkulation | In einem System, das das Register modelliert |
|---|---|---|
| Jeder Fremdschlüssel löst sich auf | Von Hand geprüft, mit Suchformeln. Bricht stillschweigend, sobald eine Kennung in einem Tabellenblatt geändert wird und in den anderen nicht. | Die Referenz ist eine Beziehung zwischen Datensätzen und zeigt daher immer auf einen vorhandenen Datensatz. |
| Schlüsselspalten sind immer gefüllt | Eine leere Zelle bleibt unbemerkt möglich. | Ein Datensatz ohne seinen Schlüssel lässt sich nicht speichern. |
| Aufzählungswerte tragen das Präfix eba_ | Eine Auswahlliste schlägt Werte vor; freier Text überschreibt sie. | Nutzer wählen die fachsprachliche Bezeichnung; der Code wird beim Export gesetzt. |
| Fehler werden vor der Einreichung gefunden | Vom Portal gefunden, nach dem Versuch. | Von einem Validierungslauf über das Datenmodell gefunden, bevor das Paket gebaut wird. |
Genau das leistet das Registermodul von Venvera. Dienstleister, vertragliche Vereinbarungen, Unternehmen, Funktionen, Lieferketten und Bewertungen sind verknüpfte Datensätze statt Tabellenblätter. Nutzer arbeiten in Fachsprache, und die ESA-Codes werden bei der Erzeugung des Pakets gesetzt. Eine Vollständigkeitsansicht zeigt Validierungsprobleme, jeweils mit Meldebogen und Feld versehen und als Fehler oder Warnung markiert, bevor Sie exportieren. Der Export erzeugt das xBRL-CSV-Paket über alle 15 offiziellen Meldebögen, B_01.01 bis B_99.01, in der Tabellenstruktur des ITS (EU) 2024/2956. Dienstleister lassen sich aus der Dienstleistermaske heraus über die GLEIF-API nachschlagen, die den eingetragenen Rechtsnamen und den Registrierungsstatus zurückgibt, sodass ein abgelaufener LEI schon bei der Erfassung sichtbar wird statt erst in einer Rückmeldungsdatei.
Was wir nicht behaupten: dass dies eine Annahme garantiert. Das Regelwerk ist versioniert, die ESAs ändern es, Ihre nationale Aufsichtsbehörde führt womöglich eigene Prüfungen durch, und die ESAs sagen das selbst. Ein Datenmodell bewirkt, dass die ablehnende Fehlerklasse, die strukturelle, weitgehend von vornherein ausgeschlossen wird statt nachträglich geprüft.
Beenden Sie die Schleife aus Wiedereinreichungen.
Venvera hält das Informationsregister als relationales Modell, zeigt Validierungsprobleme mit Meldebogen und Feld an, bevor Sie exportieren, und baut das xBRL-CSV-Paket über alle 15 offiziellen Meldebögen.
Demo buchen →Häufig gestellte Fragen
Führen alle häufigen Fehler im Informationsregister zu einer Ablehnung?
Nein, und das ist die nützlichste Erkenntnis aus den veröffentlichten Beobachtungen der ESAs. Von den zwölf Fehlertypen, die die ESAs als am häufigsten auflisten, sind fünf als nicht ablehnend markiert: fehlende Pflichtwerte, falsch gemeldeter LEI, identische Schlüsselwerte in offenen Tabellen, EUID in BRIS nicht gefunden und Gültigkeit der LEI-Maske. Die sieben ablehnenden sind die Fremdschlüsselverletzung (807), der fehlende Primärschlüssel (805), Probleme mit Filing Indicators (808), Dateien außerhalb von DORA oder mit falscher Groß- und Kleinschreibung (720), eine entityID, die nicht zum Dateinamen passt (714), die Struktur der Berichtsdatei (103) und Header-Codes, die in der Taxonomie fehlen (801). Die ESAs weisen zudem darauf hin, dass die von den nationalen zuständigen Behörden in ihren eigenen Meldelösungen umgesetzten Prüfungen und Rückmeldungen von den dort beschriebenen abweichen können.
Was bedeuten die Regelcodes in der Rückmeldungsdatei?
Es sind die Kennungen der konkreten Validierungsregeln, die das Meldesystem angewendet hat. Die numerischen Codes im 100er-, 700er- und 800er-Bereich sind technische und strukturelle Prüfungen des Pakets. Codes der Form v8826_m sind Regeln des Datenpunktmodells, formuliert als Aussagen, v8826_m ist also die Regel, dass ein Wert zur LEI-Maske passen muss. Codes der Form VR_71 sind fachliche Validierungsregeln. Die EBA veröffentlicht das Regelwerk in ihren Validation Rules Packages, und ihr Foliensatz zu häufigen Problemen geht die verbreiteten Fälle mit durchgerechneten Beispielen durch.
Warum hat eine einzige defekte Datei dutzende Fremdschlüsselfehler erzeugt?
Weil die betroffene Tabelle nie geladen wurde. Die ESAs erklären, dass jede andere Tabelle, die auf eine nicht integrierbare Tabelle verweist, ihre Fremdschlüsselprüfungen ebenfalls mit 807 nicht besteht, etwa wenn ein Header-Spaltencode in der Taxonomie fehlt (801), eine Schlüsselspalte leer ist (805) oder die CSV-Datei sich nicht parsen lässt (809). Ihr eigener Hinweis dazu: Das sei erwartetes Verhalten, und ein Datenbanksystem würde aus demselben Grund scheitern. Verfolgen Sie daher zuerst die Fehler 801, 805 und 809: Ein großer Block von 807-Fehlern hat oft eine einzige vorgelagerte Ursache.
Darf ein leerer Meldebogen aus dem Paket weggelassen werden?
Nein. Nach Regel 808 werden alle DORA-Meldebögen erwartet, Meldebogen-IDs müssen in Großbuchstaben in FilingIndicators.csv stehen, und jede gemeldete Meldebogen-ID muss als wahr deklariert sein. Ein Meldebogen ohne Inhalt wird als leere Tabelle eingereicht und dabei als wahr deklariert. Es gibt zudem eine Untergrenze: Regel 724, eingeführt am 1. Mai 2025, existiert, weil ein Paket, in dem jede Datei leer ist, überhaupt keine Befunde erzeugt, und die ESAs weisen darauf hin, dass mindestens die B_01-Meldebögen auch von einem Unternehmen ohne externe Dienstleisterverträge zu melden sind.
Was gilt, wenn ein IKT-Dienstleister keinen LEI hat?
Der technische Durchführungsstandard verlangt für jeden IKT-Drittdienstleister, der eine juristische Person ist, einen gültigen und aktiven LEI oder die Europäische Eindeutige Kennung (EUID) und, sofern verfügbar, beide; ausgenommen sind natürliche Personen, die in geschäftlicher Eigenschaft handeln. Dienstleister mit Sitz in Drittstaaten werden allein über einen LEI identifiziert, weil die EUID eine europäische Kennung ist. Setzen Sie keinen Platzhalter in ein LEI-Feld und keinen LEI in ein EUID-Feld: Die ESAs führen einen als EUID gekennzeichneten LEI als eine der vermeidbaren Ursachen des Fehlers VR_72 auf, und in den von ihnen veröffentlichten Daten war ein ungültiges EUID-Format mit weitem Abstand die größte Kategorie der EUID-Probleme.
Primärquellen
- Durchführungsverordnung (EU) 2024/2956 der Kommission. Der technische Durchführungsstandard zu den Standardmeldebögen für das Informationsregister nach Artikel 28 Absatz 9 DORA. Artikel 1 definiert den direkten Dienstleister, die IKT-Dienstleistungs-Lieferkette und den Rang. Artikel 2 legt die Rangregel fest. Artikel 3 regelt die allgemeinen Anforderungen an die Meldebögen, die sechs Datenqualitätsgrundsätze sowie die Anforderung zu LEI und EUID. Artikel 4 regelt das Datenformat. Artikel 5 listet die 15 Meldebögen B_01.01 bis B_99.01 auf.
- ESAs, “Observations from reporting of RoI to the ESAs. Key common issues identified” (ursprünglich veröffentlicht am 16. April 2025, aktualisiert am 16. Mai 2025). Die Quelle für die Fehlercodetabelle, die Zuordnung zu Ablehnung oder keiner Ablehnung, die Fremdschlüsselkaskade, die Regel zu Filing Indicators, die LEI-Maske, die EUID-Leitlinie und die am 1. Mai 2025 ergänzten Regeln.
- EBA, “Preparing plain csv reporting package for DORA”. Die Quelle für das ZIP-Namensmuster, die Ordnerstruktur des Pakets, die Inhalte von report.json, parameters.csv und FilingIndicators.csv sowie die sieben Datentypregeln einschließlich des Eigentümer-Präfixes
eba_. - EBA Validation Rules Packages. Das veröffentlichte Regelwerk. Es ist versioniert, und die aktiven Regeln hängen von der jeweils geltenden Taxonomie- und Meldeframework-Version ab.
- EBA, “Frequently asked questions on reporting of the registers of information” (aktualisiert am 28. März 2025).
- EBA, “Preparations for reporting of DORA registers of information”. Die Übersichtsseite mit technischem Paket, Datenpunktmodell, Taxonomie und den obigen Dokumenten.
- Verordnung (EU) 2022/2554 (DORA), Artikel 28 Absatz 3, die Pflicht zur Führung des Registers, und Artikel 28 Absatz 9, das Mandat für die Meldebögen.
- Hintergrund: unser Leitfaden zu den 15 offiziellen Meldebögen und die dazugehörige Meldebogen-Referenz (CSV).
Dieser Artikel dient allein der Information und stellt keine Rechts- oder Aufsichtsberatung dar. Die Quellen wurden am 14. Juli 2026 geprüft. Die ESAs weisen darauf hin, dass die von nationalen zuständigen Behörden umgesetzten Validierungsprüfungen und Rückmeldungen von den veröffentlichten abweichen können und dass das Regelwerk versioniert ist. Klären Sie die Taxonomie-Version und die geltenden Regeln vor jeder Einreichung mit Ihrer nationalen Aufsichtsbehörde.
