R2026.JUN

Reported

2CRs

3Hoch

3Reports

19.04.2026Hochgeladen

€ 0.31Kosten

draft

PDF exportieren

## Relevanzmodell

Die Bewertung jedes Change Requests (CR) erfolgt anhand von vier gewichteten Kriterien:

| Kriterium | Gewichtung |
|---|---|
| Kriterium 1 — Änderungen an Nachrichtenstruktur | 40 % |
| Kriterium 2 — Zahlungsabwicklung und Liquiditätssteuerung | 25 % |
| Kriterium 3 — Technische Umsetzung | 20 % |
| Kriterium 4 — Regulatorische Anforderungen | 15 % |

Jedes Kriterium wird mit 0–3 Punkten bewertet. Der gewichtete Gesamtscore bestimmt die Einstufung:

| Score | Kategorie | Handlungsempfehlung |
|---|---|---|
| 4 | Kritisch | Sofortige Umsetzung erforderlich |
| 3 | Aktiv prüfen | Planung und Analyse einleiten |
| 2 | Beobachten | Auswirkungen verfolgen |
| 0–1 | Nicht relevant | Kein Handlungsbedarf |

---

## CR-Übersicht

| CR-Nummer | Titel | Score | Kategorie | Hauptgrund | Empfohlene Aktion |
|---|---|---|---|---|---|
| T2-0132-SYS | Alignment of T2 Messages with ISO Maintenance Release 2020–2024 | 3 | Aktiv prüfen | 14 aktiv genutzte Nachrichtentypen von Versions-Upgrade betroffen; CLM- und RTGS-Core-Flows direkt betroffen | Analyse und Umsetzungsplanung sofort einleiten |
| T2-0115-UHB | U2A Statement of Account | 3 | Aktiv prüfen | Kontoauszugs-Download in RTGS-GUI und CLM-GUI wechselt von PDF auf XML; Reporting-DWH (Data Warehouse) muss umgestellt werden | Nachgelagerte Verarbeitungsprozesse auf XML umstellen |

---

## Score 3 — Aktiv prüfen

### T2-0132-SYS: Alignment of T2 Messages with ISO Maintenance Release 2020–2024 — Score 3 (Aktiv prüfen)

#### Was ändert sich?

Die Europäische Zentralbank migriert 26 T2-Nachrichtentypen auf die ISO 20022 Maintenance Releases 2020–2024, darunter Versionssprünge von bis zu vier Versionen — zum Beispiel wechselt der Kontoauszug camt.053 (Bank to Customer Statement) von Version 08 auf Version 12 und der Zahlungsstatus-Nachrichtentyp camt.029 (Resolution of Investigation, d. h. Rückmeldung zu Zahlungsrecherchen) von Version 09 auf Version 13. Die Strukturbank AG nutzt 14 der 26 betroffenen Nachrichtentypen aktiv, darunter pacs.008 (Customer Credit Transfer), pacs.009 (Financial Institution Credit Transfer), camt.050 (Liquiditätstransfer), camt.053 und camt.054 (Debit Credit Notification, d. h. Belastungs-/Gutschriftsbenachrichtigung). Alte Nachrichtenversionen werden nach dem Go-Live-Termin T2 R2026.JUN von der T2-Plattform vollständig abgelehnt — eine Umstellung ist daher für alle RTGS- und CLM-Teilnehmer verpflichtend. Zusätzlich ändert sich die interne Bezeichnung des Datentyps für BIC-Felder (BIC — Bank Identifier Code) sowie die Schreibweise einzelner Elementnamen (z. B. „Inter Bank Settlement Amount" wird zu „Interbank Settlement Amount"), was Anpassungen in Erfassungsmasken und Verarbeitungsregeln nach sich ziehen kann.

#### Betroffene Prozesse

- **RTGS-Settlement (Abwicklung von Großbetragszahlungen):** pacs.008 (Customer Credit Transfer) und pacs.009 (Financial Institution Credit Transfer) erfahren Versions-Upgrades — alle eingehenden und ausgehenden Zahlungsnachrichten müssen im neuen Versionsformat versendet werden.
- **CLM-Liquiditätssteuerung:** camt.050 (Liquiditätstransfer) und camt.025 (Rückmeldung zu Liquiditätstransfers) sind betroffen — Liquiditätsverschiebungen zwischen RTGS und CLM müssen im neuen Format erfolgen.
- **Kontoauszugs- und Benachrichtigungsverarbeitung:** camt.053 (Bank to Customer Statement) und camt.054 (Debit Credit Notification) erfahren Versionsprünge — Reconciliation (Abgleich) und Reporting-Prozesse im Reporting-DWH müssen auf die neuen Versionen umgestellt werden.
- **Zahlungsrecherche (Investigation):** camt.029 (Resolution of Investigation) und camt.056 (FI to FI Payment Cancellation Request) sind betroffen — Rückfragen und Stornierungsanfragen müssen im neuen Format abgewickelt werden.
- **Stammdatenverwaltung:** Änderungen am BIC-Datentyp wirken sich auf alle Nachrichten aus, in denen BIC-Felder vorkommen — das betrifft praktisch alle oben genannten Prozesse.

#### Erforderliche Anpassungen

- **SWIFT Alliance Gateway aktualisieren:** Der Gateway muss die neuen XSD-Schemaversionen aller 14 genutzten Nachrichtentypen kennen und validieren können; ggf. Profilaktualisierung beim Gateway-Betreiber einplanen.
- **MyStandards-Profile aktualisieren:** Für jeden der 14 betroffenen Nachrichtentypen müssen die MyStandards-Profile der Strukturbank AG auf die neuen Nachrichtenversionen aktualisiert werden (Staging- und Release-Prozess je Nachrichtentyp einplanen).
- **Reporting-DWH auf neue Schemaversionen umstellen:** Die ETL-Jobs (Extraktions-, Transformations- und Ladeprozesse) im Reporting-DWH, die camt.053, camt.054 und pacs.009 verarbeiten, müssen auf die neuen Versionen umgestellt werden.
- **Interne Verarbeitungsregeln und Erfassungsmasken prüfen:** Elementnamen-Änderungen (z. B. „Interbank Settlement Amount" statt „Inter Bank Settlement Amount") und BIC-Datentyp-Änderungen müssen in internen Validierungsregeln und ggf. in U2A-Masken (User-to-Application, d. h. GUI-Oberflächen für Sachbearbeiter) nachgezogen werden.
- **Koordination mit IT für Rollout in 4 Batches:** Die EZB liefert die neuen Nachrichtenspezifikationen in vier Lieferpaketen; die interne Umsetzungsplanung sollte diesen Batch-Zeitplan berücksichtigen.

#### Bewertung nach Kriterien

- **Änderungen an Nachrichtenstruktur:** 2 × 0,40 = 0,80 → Versions-Upgrades für 14 aktiv genutzte Nachrichtentypen; Feldnamen- und Datentypänderungen, jedoch kein Entfernen bestehender Felder bestätigt.
- **Zahlungsabwicklung und Liquiditätssteuerung:** 3 × 0,25 = 0,75 → Direkter Einfluss auf RTGS-Settlement (pacs.008/009) und CLM-Liquiditätssteuerung (camt.050/025).
- **Technische Umsetzung:** 3 × 0,20 = 0,60 → Multi-System-Anpassungsbedarf: SWIFT Alliance Gateway, MyStandards, Reporting-DWH, interne Parser; Rollout in 4 Batches mit erhöhtem Koordinationsaufwand.
- **Regulatorische Anforderungen:** 3 × 0,15 = 0,45 → Verpflichtende EZB-Pflichtmigration mit festem Termin T2 R2026.JUN; alte Nachrichtenversionen werden danach abgelehnt.

**Gesamtscore:** 2,60 → Aktiv prüfen (Score 3)

#### Nächste Schritte (BA)

- Bestandsaufnahme aller intern genutzten Nachrichten aus der Liste der 14 betroffenen Typen erstellen und je Nachrichtentyp den Anpassungsbedarf dokumentieren.
- Abstimmung mit IT und dem SWIFT Alliance Gateway-Betreiber zum Lieferplan der EZB (4 Batches) einleiten und interne Meilensteine ableiten.
- MyStandards-Profile für alle 14 Nachrichtentypen vorbereiten und Staging-Prozess rechtzeitig anstoßen — Abschluss mindestens 4–6 Wochen vor Go-Live T2 R2026.JUN.
- Prüfen, ob Elementnamen-Änderungen (z. B. „Interbank Settlement Amount") und BIC-Datentyp-Änderungen in internen Benutzerhandbüchern, Schulungsunterlagen oder U2A-Masken sichtbar sind und entsprechend angepasst werden müssen.
- Testplan für alle betroffenen Prozesse (Settlement, Liquiditätssteuerung, Reporting, Zahlungsrecherche) erstellen und mit Fachbereichen abstimmen.

---

### T2-0115-UHB: U2A Statement of Account — Score 3 (Aktiv prüfen)

#### Was ändert sich?

Das Download-Format für den Kontoauszug (Statement of Account) in den Benutzeroberflächen von RTGS und CLM wird grundlegend geändert: Das bisherige PDF-Format wird vollständig durch ein XML-Format ersetzt. Das neue XML-Format enthält die camt.053-Nachricht(en) (Bank to Customer Statement), eingebettet in ein übergeordnetes Strukturelement, und enthält keinen sogenannten Business Application Header (BAH — eine standardisierte Kopfinformation, die in regulären A2A-Zahlungsnachrichten mitgeliefert wird). Das PDF-Format steht nach dem Go-Live-Termin nicht mehr zur Verfügung — es gibt keine parallele Bereitstellung beider Formate. Bestehende Prozesse, die auf dem PDF-Download basieren, insbesondere im Reporting-DWH und in Archivierungsroutinen, müssen vollständig auf das neue XML-Format umgestellt werden.

#### Betroffene Prozesse

- **Kontoauszugsverarbeitung im Reporting-DWH:** Der automatisierte Import des heruntergeladenen Kontoauszugs in das Reporting-DWH muss von PDF-Parsing auf XML-Parsing umgestellt werden.
- **Archivierung:** Interne Archivierungsroutinen, die auf dem PDF-Dateiformat basieren (z. B. Dateinamen-Logik mit „.pdf"-Endung), müssen auf das neue „.xml"-Format angepasst werden.
- **Reconciliation (Kontenabgleich):** Abgleichsprozesse, die auf den aus der Benutzeroberfläche heruntergeladenen Kontoauszugsdaten aufbauen, müssen die neue XML-Struktur verarbeiten können.
- **Manuelle Kontoauszugsprüfung durch Sachbearbeiter:** Sachbearbeiter, die den Kontoauszug bisher als PDF geöffnet und geprüft haben, müssen auf das neue XML-Format umgestellt werden (geänderte Lesbarkeit, ggf. Schulungsbedarf).

#### Erforderliche Anpassungen

- **Reporting-DWH auf XML-Parsing umstellen:** Die Importprozesse im Reporting-DWH müssen das neue XML-Format mit dem übergeordneten Strukturelement verarbeiten können; das Fehlen des BAH muss in der Parsing-Logik berücksichtigt werden.
- **Archivierungsroutinen anpassen:** Dateinamen-Logik und Archivierungsregeln auf die neue „.xml"-Endung umstellen und sicherstellen, dass Archivierungssysteme XML-Dateien korrekt ablegen und abrufbar halten.
- **Reconciliation-Prozesse anpassen:** Fachbereichsseitig prüfen, ob Reconciliation-Tools den Kontoauszug direkt einlesen; ggf. Schnittstellen zwischen Kontoauszugs-Download und nachgelagerten Abgleichsystemen anpassen.
- **Sachbearbeiter informieren und schulen:** Kommunikation an alle Nutzer der RTGS-GUI und CLM-GUI, die den Kontoauszug manuell herunterladen, über das geänderte Dateiformat und die geänderte Dateistruktur.

#### Bewertung nach Kriterien

- **Änderungen an Nachrichtenstruktur:** 1 × 0,40 = 0,40 → Keine Änderung an der camt.053-Nachrichtenstruktur selbst; nur das Download-Container-Format (PDF→XML mit Strukturelement, ohne BAH) ändert sich.
- **Zahlungsabwicklung und Liquiditätssteuerung:** 2 × 0,25 = 0,50 → Kein direkter Einfluss auf Zahlungsabwicklung; jedoch sind Reconciliation-, Reporting- und Archivierungsprozesse (Reporting-DWH) betroffen.
- **Technische Umsetzung:** 2 × 0,20 = 0,40 → Reporting-DWH und Archivierungsroutinen müssen umgestellt werden; kein TPH (Travic Payment Hub) oder MyStandards-Update erforderlich.
- **Regulatorische Anforderungen:** 2 × 0,15 = 0,30 → Keine explizite EZB-Regulierungsvorschrift, aber als T2-Plattform-Breaking-Change faktisch verpflichtend für alle RTGS- und CLM-Teilnehmer.

**Gesamtscore:** 1,60 → Aktiv prüfen (Score 3)

#### Nächste Schritte (BA)

- Bestandsaufnahme aller internen Prozesse und Systeme, die den U2A-Kontoauszugs-Download aus RTGS-GUI und CLM-GUI verarbeiten (insbesondere Reporting-DWH, Archivierung, Reconciliation-Tools).
- Anforderungen an das neue XML-Format (Strukturelement ohne BAH) fachlich dokumentieren und an die zuständigen IT-Teams sowie das Reporting-DWH-Team weitergeben.
- Testplan für den XML-Import im Reporting-DWH sowie für die Archivierungsroutinen erstellen; Funktionstest des neuen Downloads in RTGS-GUI und CLM-GUI einplanen.
- Kommunikationsplan für betroffene Sachbearbeiter erstellen, die den Kontoauszug manuell nutzen.
- Umsetzung mindestens 4–6 Wochen vor dem T2 Go-Live-Termin abschließen.

---

## Score 0–1 kompakt

Für dieses Release (Release-ID 33) liegen keine CRs mit Score 0 oder 1 vor. Beide analysierten CRs erreichen Score 3 und sind im obigen Abschnitt vollständig ausgeführt.

---

## Handlungsempfehlungen (Zusammenfassung)

### Zuerst — Sofortiger Handlungsbedarf

| CR | Maßnahme | Frist |
|---|---|---|
| **T2-0132-SYS** | Bestandsaufnahme aller 14 betroffenen Nachrichtentypen durchführen; Umsetzungsplanung für MyStandards-Profile, SWIFT Alliance Gateway und Reporting-DWH einleiten; interne Meilensteine entlang der EZB-Batch-Lieferplanung festlegen | Sofort — Projektauftrag vor nächstem Sprint |
| **T2-0115-UHB** | Alle internen Prozesse und Systeme identifizieren, die den U2A-Kontoauszugs-Download verarbeiten (Reporting-DWH, Archivierung, Reconciliation); fachliche Anforderungen an das neue XML-Format dokumentieren | Sofort — parallel zu T2-0132-SYS |

### Danach — Mittelfristiger Handlungsbedarf

| CR | Maßnahme | Frist |
|---|---|---|
| **T2-0132-SYS** | MyStandards-Profile für alle 14 betroffenen Nachrichtentypen aktualisieren; ETL-Jobs im Reporting-DWH auf neue Schemaversionen umstellen; Elementnamen- und BIC-Datentyp-Änderungen in internen Regeln und U2A-Masken nachziehen | 4–8 Wochen nach Projektstart |
| **T2-0115-UHB** | Reporting-DWH und Archivierungsroutinen auf XML-Format umstellen; Reconciliation-Prozesse anpassen | 4–6 Wochen vor Go-Live |

### Später — Abschluss und Go-Live-Vorbereitung

| CR | Maßnahme | Frist |
|---|---|---|
| **T2-0132-SYS** | Vollständige Regressionstests aller betroffenen Prozesse (Settlement, Liquiditätssteuerung, Reporting, Zahlungsrecherche) auf T2-Testsystem durchführen; Signoff durch Fachbereich und IT einholen | Spätestens 4 Wochen vor T2 R2026.JUN Go-Live |
| **T2-0115-UHB** | Funktionstests des neuen XML-Downloads in RTGS-GUI und CLM-GUI abschließen; Sachbearbeiter informieren und schulen; Archivierungstests abschließen | Spätestens 4 Wochen vor Go-Live |

> **Hinweis Go-Live-Deadline:** T2 Releases erscheinen im Mai und November. Für T2 R2026.JUN gilt: Alle Implementierungen und Tests müssen mindestens **4–6 Wochen vor Go-Live** abgeschlossen sein. Bei Nicht-Einhaltung werden nach Go-Live alle Nachrichten in alten Versionen (T2-0132-SYS) sowie PDF-Downloads (T2-0115-UHB) von der T2-Plattform abgelehnt bzw. nicht mehr unterstützt — nachgelagerte Prozesse der Strukturbank AG wären ab diesem Zeitpunkt nicht mehr funktionsfähig.

Relevanzmodell

Die Bewertung jedes Change Requests (CR) erfolgt anhand von vier gewichteten Kriterien:

Kriterium	Gewichtung
Kriterium 1 — Änderungen an Nachrichtenstruktur	40 %
Kriterium 2 — Zahlungsabwicklung und Liquiditätssteuerung	25 %
Kriterium 3 — Technische Umsetzung	20 %
Kriterium 4 — Regulatorische Anforderungen	15 %

Jedes Kriterium wird mit 0–3 Punkten bewertet. Der gewichtete Gesamtscore bestimmt die Einstufung:

Score	Kategorie	Handlungsempfehlung
4	Kritisch	Sofortige Umsetzung erforderlich
3	Aktiv prüfen	Planung und Analyse einleiten
2	Beobachten	Auswirkungen verfolgen
0–1	Nicht relevant	Kein Handlungsbedarf

CR-Übersicht

CR-Nummer	Titel	Score	Kategorie	Hauptgrund	Empfohlene Aktion
T2-0132-SYS	Alignment of T2 Messages with ISO Maintenance Release 2020–2024	3	Aktiv prüfen	14 aktiv genutzte Nachrichtentypen von Versions-Upgrade betroffen; CLM- und RTGS-Core-Flows direkt betroffen	Analyse und Umsetzungsplanung sofort einleiten
T2-0115-UHB	U2A Statement of Account	3	Aktiv prüfen	Kontoauszugs-Download in RTGS-GUI und CLM-GUI wechselt von PDF auf XML; Reporting-DWH (Data Warehouse) muss umgestellt werden	Nachgelagerte Verarbeitungsprozesse auf XML umstellen

Score 3 — Aktiv prüfen

T2-0132-SYS: Alignment of T2 Messages with ISO Maintenance Release 2020–2024 — Score 3 (Aktiv prüfen)

Was ändert sich?

Betroffene Prozesse

RTGS-Settlement (Abwicklung von Großbetragszahlungen): pacs.008 (Customer Credit Transfer) und pacs.009 (Financial Institution Credit Transfer) erfahren Versions-Upgrades — alle eingehenden und ausgehenden Zahlungsnachrichten müssen im neuen Versionsformat versendet werden.
CLM-Liquiditätssteuerung: camt.050 (Liquiditätstransfer) und camt.025 (Rückmeldung zu Liquiditätstransfers) sind betroffen — Liquiditätsverschiebungen zwischen RTGS und CLM müssen im neuen Format erfolgen.
Kontoauszugs- und Benachrichtigungsverarbeitung: camt.053 (Bank to Customer Statement) und camt.054 (Debit Credit Notification) erfahren Versionsprünge — Reconciliation (Abgleich) und Reporting-Prozesse im Reporting-DWH müssen auf die neuen Versionen umgestellt werden.
Zahlungsrecherche (Investigation): camt.029 (Resolution of Investigation) und camt.056 (FI to FI Payment Cancellation Request) sind betroffen — Rückfragen und Stornierungsanfragen müssen im neuen Format abgewickelt werden.
Stammdatenverwaltung: Änderungen am BIC-Datentyp wirken sich auf alle Nachrichten aus, in denen BIC-Felder vorkommen — das betrifft praktisch alle oben genannten Prozesse.

Erforderliche Anpassungen

SWIFT Alliance Gateway aktualisieren: Der Gateway muss die neuen XSD-Schemaversionen aller 14 genutzten Nachrichtentypen kennen und validieren können; ggf. Profilaktualisierung beim Gateway-Betreiber einplanen.
MyStandards-Profile aktualisieren: Für jeden der 14 betroffenen Nachrichtentypen müssen die MyStandards-Profile der Strukturbank AG auf die neuen Nachrichtenversionen aktualisiert werden (Staging- und Release-Prozess je Nachrichtentyp einplanen).
Reporting-DWH auf neue Schemaversionen umstellen: Die ETL-Jobs (Extraktions-, Transformations- und Ladeprozesse) im Reporting-DWH, die camt.053, camt.054 und pacs.009 verarbeiten, müssen auf die neuen Versionen umgestellt werden.
Interne Verarbeitungsregeln und Erfassungsmasken prüfen: Elementnamen-Änderungen (z. B. „Interbank Settlement Amount" statt „Inter Bank Settlement Amount") und BIC-Datentyp-Änderungen müssen in internen Validierungsregeln und ggf. in U2A-Masken (User-to-Application, d. h. GUI-Oberflächen für Sachbearbeiter) nachgezogen werden.
Koordination mit IT für Rollout in 4 Batches: Die EZB liefert die neuen Nachrichtenspezifikationen in vier Lieferpaketen; die interne Umsetzungsplanung sollte diesen Batch-Zeitplan berücksichtigen.

Bewertung nach Kriterien

Änderungen an Nachrichtenstruktur: 2 × 0,40 = 0,80 → Versions-Upgrades für 14 aktiv genutzte Nachrichtentypen; Feldnamen- und Datentypänderungen, jedoch kein Entfernen bestehender Felder bestätigt.
Zahlungsabwicklung und Liquiditätssteuerung: 3 × 0,25 = 0,75 → Direkter Einfluss auf RTGS-Settlement (pacs.008/009) und CLM-Liquiditätssteuerung (camt.050/025).
Technische Umsetzung: 3 × 0,20 = 0,60 → Multi-System-Anpassungsbedarf: SWIFT Alliance Gateway, MyStandards, Reporting-DWH, interne Parser; Rollout in 4 Batches mit erhöhtem Koordinationsaufwand.
Regulatorische Anforderungen: 3 × 0,15 = 0,45 → Verpflichtende EZB-Pflichtmigration mit festem Termin T2 R2026.JUN; alte Nachrichtenversionen werden danach abgelehnt.

Gesamtscore: 2,60 → Aktiv prüfen (Score 3)

Nächste Schritte (BA)

Bestandsaufnahme aller intern genutzten Nachrichten aus der Liste der 14 betroffenen Typen erstellen und je Nachrichtentyp den Anpassungsbedarf dokumentieren.
Abstimmung mit IT und dem SWIFT Alliance Gateway-Betreiber zum Lieferplan der EZB (4 Batches) einleiten und interne Meilensteine ableiten.
MyStandards-Profile für alle 14 Nachrichtentypen vorbereiten und Staging-Prozess rechtzeitig anstoßen — Abschluss mindestens 4–6 Wochen vor Go-Live T2 R2026.JUN.
Prüfen, ob Elementnamen-Änderungen (z. B. „Interbank Settlement Amount") und BIC-Datentyp-Änderungen in internen Benutzerhandbüchern, Schulungsunterlagen oder U2A-Masken sichtbar sind und entsprechend angepasst werden müssen.
Testplan für alle betroffenen Prozesse (Settlement, Liquiditätssteuerung, Reporting, Zahlungsrecherche) erstellen und mit Fachbereichen abstimmen.

T2-0115-UHB: U2A Statement of Account — Score 3 (Aktiv prüfen)

Was ändert sich?

Betroffene Prozesse

Kontoauszugsverarbeitung im Reporting-DWH: Der automatisierte Import des heruntergeladenen Kontoauszugs in das Reporting-DWH muss von PDF-Parsing auf XML-Parsing umgestellt werden.
Archivierung: Interne Archivierungsroutinen, die auf dem PDF-Dateiformat basieren (z. B. Dateinamen-Logik mit „.pdf"-Endung), müssen auf das neue „.xml"-Format angepasst werden.
Reconciliation (Kontenabgleich): Abgleichsprozesse, die auf den aus der Benutzeroberfläche heruntergeladenen Kontoauszugsdaten aufbauen, müssen die neue XML-Struktur verarbeiten können.
Manuelle Kontoauszugsprüfung durch Sachbearbeiter: Sachbearbeiter, die den Kontoauszug bisher als PDF geöffnet und geprüft haben, müssen auf das neue XML-Format umgestellt werden (geänderte Lesbarkeit, ggf. Schulungsbedarf).

Erforderliche Anpassungen

Reporting-DWH auf XML-Parsing umstellen: Die Importprozesse im Reporting-DWH müssen das neue XML-Format mit dem übergeordneten Strukturelement verarbeiten können; das Fehlen des BAH muss in der Parsing-Logik berücksichtigt werden.
Archivierungsroutinen anpassen: Dateinamen-Logik und Archivierungsregeln auf die neue „.xml"-Endung umstellen und sicherstellen, dass Archivierungssysteme XML-Dateien korrekt ablegen und abrufbar halten.
Reconciliation-Prozesse anpassen: Fachbereichsseitig prüfen, ob Reconciliation-Tools den Kontoauszug direkt einlesen; ggf. Schnittstellen zwischen Kontoauszugs-Download und nachgelagerten Abgleichsystemen anpassen.
Sachbearbeiter informieren und schulen: Kommunikation an alle Nutzer der RTGS-GUI und CLM-GUI, die den Kontoauszug manuell herunterladen, über das geänderte Dateiformat und die geänderte Dateistruktur.

Bewertung nach Kriterien

Änderungen an Nachrichtenstruktur: 1 × 0,40 = 0,40 → Keine Änderung an der camt.053-Nachrichtenstruktur selbst; nur das Download-Container-Format (PDF→XML mit Strukturelement, ohne BAH) ändert sich.
Zahlungsabwicklung und Liquiditätssteuerung: 2 × 0,25 = 0,50 → Kein direkter Einfluss auf Zahlungsabwicklung; jedoch sind Reconciliation-, Reporting- und Archivierungsprozesse (Reporting-DWH) betroffen.
Technische Umsetzung: 2 × 0,20 = 0,40 → Reporting-DWH und Archivierungsroutinen müssen umgestellt werden; kein TPH (Travic Payment Hub) oder MyStandards-Update erforderlich.
Regulatorische Anforderungen: 2 × 0,15 = 0,30 → Keine explizite EZB-Regulierungsvorschrift, aber als T2-Plattform-Breaking-Change faktisch verpflichtend für alle RTGS- und CLM-Teilnehmer.

Gesamtscore: 1,60 → Aktiv prüfen (Score 3)

Nächste Schritte (BA)

Bestandsaufnahme aller internen Prozesse und Systeme, die den U2A-Kontoauszugs-Download aus RTGS-GUI und CLM-GUI verarbeiten (insbesondere Reporting-DWH, Archivierung, Reconciliation-Tools).
Anforderungen an das neue XML-Format (Strukturelement ohne BAH) fachlich dokumentieren und an die zuständigen IT-Teams sowie das Reporting-DWH-Team weitergeben.
Testplan für den XML-Import im Reporting-DWH sowie für die Archivierungsroutinen erstellen; Funktionstest des neuen Downloads in RTGS-GUI und CLM-GUI einplanen.
Kommunikationsplan für betroffene Sachbearbeiter erstellen, die den Kontoauszug manuell nutzen.
Umsetzung mindestens 4–6 Wochen vor dem T2 Go-Live-Termin abschließen.

Score 0–1 kompakt

Für dieses Release (Release-ID 33) liegen keine CRs mit Score 0 oder 1 vor. Beide analysierten CRs erreichen Score 3 und sind im obigen Abschnitt vollständig ausgeführt.

Handlungsempfehlungen (Zusammenfassung)

Zuerst — Sofortiger Handlungsbedarf

CR	Maßnahme	Frist
T2-0132-SYS	Bestandsaufnahme aller 14 betroffenen Nachrichtentypen durchführen; Umsetzungsplanung für MyStandards-Profile, SWIFT Alliance Gateway und Reporting-DWH einleiten; interne Meilensteine entlang der EZB-Batch-Lieferplanung festlegen	Sofort — Projektauftrag vor nächstem Sprint
T2-0115-UHB	Alle internen Prozesse und Systeme identifizieren, die den U2A-Kontoauszugs-Download verarbeiten (Reporting-DWH, Archivierung, Reconciliation); fachliche Anforderungen an das neue XML-Format dokumentieren	Sofort — parallel zu T2-0132-SYS

Danach — Mittelfristiger Handlungsbedarf

CR	Maßnahme	Frist
T2-0132-SYS	MyStandards-Profile für alle 14 betroffenen Nachrichtentypen aktualisieren; ETL-Jobs im Reporting-DWH auf neue Schemaversionen umstellen; Elementnamen- und BIC-Datentyp-Änderungen in internen Regeln und U2A-Masken nachziehen	4–8 Wochen nach Projektstart
T2-0115-UHB	Reporting-DWH und Archivierungsroutinen auf XML-Format umstellen; Reconciliation-Prozesse anpassen	4–6 Wochen vor Go-Live

Später — Abschluss und Go-Live-Vorbereitung

CR	Maßnahme	Frist
T2-0132-SYS	Vollständige Regressionstests aller betroffenen Prozesse (Settlement, Liquiditätssteuerung, Reporting, Zahlungsrecherche) auf T2-Testsystem durchführen; Signoff durch Fachbereich und IT einholen	Spätestens 4 Wochen vor T2 R2026.JUN Go-Live
T2-0115-UHB	Funktionstests des neuen XML-Downloads in RTGS-GUI und CLM-GUI abschließen; Sachbearbeiter informieren und schulen; Archivierungstests abschließen	Spätestens 4 Wochen vor Go-Live

Hinweis Go-Live-Deadline: T2 Releases erscheinen im Mai und November. Für T2 R2026.JUN gilt: Alle Implementierungen und Tests müssen mindestens 4–6 Wochen vor Go-Live abgeschlossen sein. Bei Nicht-Einhaltung werden nach Go-Live alle Nachrichten in alten Versionen (T2-0132-SYS) sowie PDF-Downloads (T2-0115-UHB) von der T2-Plattform abgelehnt bzw. nicht mehr unterstützt — nachgelagerte Prozesse der Strukturbank AG wären ab diesem Zeitpunkt nicht mehr funktionsfähig.