Ein Vertrag allein erklärt noch nicht, welche Funktion von einem Dienstleister abhängt. Dafür müssen Vertragsangaben, Anbieter, Leistung und Funktionsbewertung zusammenpassen. Das folgende T-NEX-Arbeitsbeispiel macht diese Verbindungen sichtbar und zeigt anschließend, wie Änderungen und Fehler behandelt werden können.
| Vertrag | Direkter Anbieter | Leistung | Funktion |
|---|---|---|---|
| V-001 | D-001: Beispielanbieter A | Anwendungsbetrieb Zahlungsverkehr | F-001: Zahlungsverkehr abwickeln |
| V-002 | D-002: Beispielanbieter B | Betrieb der Wiederanlaufumgebung | F-001: Zahlungsverkehr abwickeln |
| V-003 | D-003: Beispielanbieter C | Kollaborationsanwendung | F-002: Interne Zusammenarbeit organisieren |
Im Beispiel ist F-001 als kritisch oder wichtig bewertet. F-002 ist es aufgrund der angenommenen Abläufe und Ersatzwege nicht. Diese Einstufungen gehören zum erfundenen Fall. Sie lassen sich nicht pauschal auf Zahlungs- oder Kollaborationsdienste anderer Institute übertragen.
Beispielanbieter B hat einen direkten Vertrag V-002 mit dem Finanzunternehmen. Zugleich übernimmt er für Beispielanbieter A einen tragenden Betriebsanteil an V-001. In der Lieferkette zu V-001 steht D-002 deshalb auf Rang 2. In der Lieferkette zu V-002 steht derselbe Anbieter auf Rang 1.
| Vertragsbezug | Anbieter und Rang | Leistungsempfänger des Unterauftragnehmers |
|---|---|---|
| V-001 | D-001, Rang 1 | Kein vorgelagerter Anbieter in dieser Kette |
| V-001 | D-002, Rang 2 | D-001 |
| V-002 | D-002, Rang 1 | Kein vorgelagerter Anbieter in dieser Kette |
Die Rolle gehört zur Vertrags- und Leistungsbeziehung. Ein einziges Feld „Unterauftragnehmer: ja/nein“ am Anbieter würde diese beiden Konstellationen nicht sauber abbilden. Das Beispiel zeigt genau diese Beziehung; den Umfang einer realen Lieferkette muss das Institut gesondert bestimmen.
Für V-003 liefert der IT-Einkauf Vertragsbeginn, Vertragsende und Anbieterangaben. Die Funktionsverantwortung ergänzt den Bezug zu F-002 und die Bewertungsgrundlage. Die Registerkoordination führt beides zusammen. Erst damit lässt sich nachvollziehen, welche Leistung das Institut bezieht und wofür es sie verwendet.
Die erste Prüffrage lautet somit nicht nur „Ist die Zeile vollständig?“, sondern auch „Lässt sich dieser Wert aus dem richtigen Beleg für den richtigen Zeitpunkt herleiten?“. Die mitgelieferten Dateien erlauben genau diesen Abgleich.
Im Februar 2027 treten im Szenario zwei verschiedene Dinge auf. Der Vertrag V-001 wird verlängert. Außerdem fällt der schon zuvor vorhandene Erfassungsfehler in V-003 auf. Wer beides einfach in eine einzige Tabelle schreibt und den alten Stand ersetzt, verliert den Unterschied zwischen neuer Sachlage und falscher Erfassung.
Änderung: Der Nachtrag zu V-001 wird am 01.02.2027 wirksam. Er verlängert den Vertrag bis 31.12.2028. Der laufende Bestand erhält das neue Enddatum. Für den Stichtag 31.12.2026 bleibt das damals geltende Enddatum 31.12.2027 erhalten.
Berichtigung: Am 10.02.2027 wird festgestellt, dass V-003 schon im Vorjahr bis 30.09.2027 galt. Der 30.06.2027 war ein Übertragungsfehler. Deshalb werden der laufende Bestand und eine gesonderte berichtigte Fassung des Stichtagsbestands angepasst. Die ursprünglich erfasste Fassung bleibt zum Vergleich erhalten.
| Arbeitsstand | Ende V-001 | Ende V-003 |
|---|---|---|
| 31.12.2026, ursprünglich erfasst | 31.12.2027 | 30.06.2027, Erfassungsfehler |
| 01.02.2027, laufender Bestand nach Nachtrag | 31.12.2028 | 30.06.2027, noch nicht berichtigt |
| 31.12.2026, am 10.02.2027 berichtigt | 31.12.2027 | 30.09.2027 |
| 10.02.2027, laufender Bestand | 31.12.2028 | 30.09.2027 |
Das Änderungsjournal hält Wirksamkeitsdatum, Erfassungsdatum, alten Wert, neuen Wert und Beleg auseinander. Ob ein bereits eingereichtes Register erneut eingereicht werden muss und auf welchem Weg, richtet sich nach der aktuellen Aufsichtsanweisung und dem konkreten Rückmeldestatus. Diese Entscheidung nimmt das Arbeitsbeispiel nicht vorweg.
Für den dritten Teil enthält der Download einen absichtlich fehlerhaften Stand. Die folgende Rückmeldung stammt aus dem eigenen Python-Teilprüfer des Arbeitsbeispiels. Die Regelnummern T01 bis T08 sind eigene Bezeichnungen, keine EBA-Fehlercodes.
| Fehler | Was zu korrigieren ist | Zuständigkeit im Beispiel |
|---|---|---|
| D-002 kommt zweimal im Anbieterbestand vor | Dubletten anhand der Identität prüfen und den doppelten Beispielsatz entfernen. | Stammdatenpflege |
| V-003 verweist auf D-099 | Den Anbieterbezug mit BE-V003 abgleichen; richtig ist D-003. | IT-Einkauf |
| V-002 ist F-099 zugeordnet | Den Funktionsbezug mit BE-BIA001 abgleichen; richtig ist F-001. | Funktionsverantwortung |
| V-001 beginnt am 2026-13-01 | Das unzulässige Datum anhand des Vertrags auf 2026-01-01 korrigieren. | IT-Einkauf |
| D-002 ist sein eigener Leistungsempfänger | Die Kette zu V-001 mit BE-K001 abgleichen; Empfänger ist D-001. | IKT-Drittparteienmanagement |
Nach der Korrektur werden die Teilprüfungen auf einer neuen Fassung erneut ausgeführt. Der Download enthält beide Stände und die tatsächlichen Ergebnisse. Getrennte Ordner und Prüfsummen machen die Fassungen vergleichbar. Eine unveränderbare oder revisionssichere Archivierung ist damit nicht nachgewiesen.
Im zusätzlichen Gegenfall wird die Einstufung von F-001 von „ja“ auf „nein“ geändert. „Nein“ ist ein zulässiger Wert im Beispielschema. Auch der Quellenverweis auf BE-BIA001 ist vorhanden. Der Teilprüfer meldet deshalb keinen Fehler.
Die synthetische Funktionsbewertung sagt aber weiterhin, dass F-001 kritisch oder wichtig ist. Der Widerspruch wird erst beim fachlichen Abgleich sichtbar. Damit lässt sich an derselben kleinen Datenbasis zeigen, was technische Prüfungen leisten und wo eine begründete Entscheidung erforderlich bleibt.
Das Beispiel wurde mit einem eigenen, offen mitgelieferten Python-Teilprüfer ausgeführt. Es wurde kein vollständiges Meldepaket erzeugt, kein amtliches Regelpaket angewendet und keine Einreichung an eine Aufsicht vorgenommen.