ARIA
by Mentronig
Prod · T2 v2026.Q2
RG
R. Glienke
AI Engineer
Bank

R2026.NOV

Reported
4CRs
4Kritisch
3Reports
21.04.2026Hochgeladen
2.34Kosten
draft
PDF exportieren

Relevanzmodell

Die Relevanzbewertung jedes Change Requests (CR) erfolgt nach einem gewichteten Punktemodell mit vier Kriterien:

KriteriumGewichtung
Kriterium 1 — Änderungen an Nachrichtenstruktur40 %
Kriterium 2 — Zahlungsabwicklung und Liquiditätssteuerung25 %
Kriterium 3 — Technische Umsetzung20 %
Kriterium 4 — Regulatorische Anforderungen15 %

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

ScoreKategorieBedeutung
4KritischSofortiger Handlungsbedarf, vollständige Analyse
3HochAktiv prüfen und planen
2MittelBeobachten, Auswirkungen prüfen
0–1Gering / Nicht relevantKompakter Hinweis, kein aktiver Handlungsbedarf

Besonderheit — Element-Removal-Override: Wenn ein CR die Entfernung eines bestehenden Feldes aus einer aktiv genutzten ISO 20022-Nachricht beinhaltet (z. B. aus pacs.008, camt.025), wird der Gesamtscore automatisch auf 4 (Kritisch) angehoben, unabhängig von der offiziellen Klassifikation des CR durch die EZB. Alte Nachrichten, die das entfernte Feld noch enthalten, werden nach dem T2-Go-Live abgelehnt.


CR-Übersicht

CR-NummerTitelScoreKategorieHauptgrundEmpfohlene Aktion
T2-0156-UDFSHVPS Plus UG2026 – Wartung RTGS-Nachrichten4KritischElement-Removal (BranchId, Postal Address), mehrere Pflichtfeld-Änderungen in pacs.008, pacs.009 u. a.Sofort starten
T2-0147-SYSISO-Wartungsrelease 2025 – T2-Nachrichten-Upgrade4KritischElement-Removal (StsCd aus camt.025), Versionssprünge bei 5 aktiv genutzten NachrichtentypenSofort starten
T2-0170-SYSISO-Wartungsrelease 2026 – T2-Nachrichten-Upgrade4KritischVersionsbruch ohne Übergangsphase bei 5 aktiv genutzten Nachrichten, EZB-PflichtSofort starten
T2-0135-SYSZusätzliche Routing-Konfigurationen in CRDM für NSP-Ausfälle2MittelKeine Nachrichtenformat-Änderung; CRDM-Stammdaten-Erweiterung; indirekte Auswirkung auf CLM/RTGSIm nächsten Sprint prüfen

Score 4 — Kritisch


T2-0156-UDFS: HVPS Plus UG2026 – Wartung RTGS-Nachrichten — Score 4 (Kritisch)

Was ändert sich?

HVPS Plus (High Value Payment System Plus) aktualisiert die Marktpraxis für T2-RTGS-Nachrichten zum Release R2026.NOV. Im Mittelpunkt stehen zwei Arten von Änderungen: Erstens werden Felder aus aktiv genutzten Nachrichten vollständig entfernt — konkret das Feld „BranchId" (Filialkennung) unter „CreditorAgent" (Empfängerinstitut) in den Kern-Zahlungsnachrichten pacs.008 (Customer Credit Transfer, Kundenzahlung) und pacs.009 (Financial Institution Credit Transfer, Interbanken-Zahlung), sowie alle unstrukturierten Adressfelder im Sinne der „Postal Address" (Postanschrift) über sechs Nachrichtentypen hinweg. Zweitens werden mehrere bisher optionale Felder zu Pflichtfeldern — darunter „Instructed Amount" (Beauftragter Betrag) in pacs.008/pacs.009, „Scheme Name" (Kennzeichnung des Zahlungsschemas) sowie „Town Name" (Ortsangabe) und „Country" (Land) in allen Adresskomponenten. Nachrichten, die nach dem Go-Live noch das Feld „BranchId" enthalten oder unstrukturierte Adresszeilen über zwei Instanzen hinaus nutzen, werden von T2 automatisch abgelehnt.

Betroffene Prozesse

  • Ausgehende Kundenzahlungen (Customer Credit Transfer) über pacs.008
  • Ausgehende Interbanken-Zahlungen (Financial Institution Credit Transfer) über pacs.009
  • Zahlungsrückgaben (Payment Return) über pacs.004
  • Zahlungsrecherche und -stornierung (Investigation und Cancellation) über camt.029 (Resolution of Investigation) und camt.056 (Payment Cancellation Request)
  • Kontoauszugs-Reporting über camt.053 (Bank to Customer Statement) und camt.054 (Bank to Customer Debit/Credit Notification)
  • Operative Erfassung von Zahlungen über Benutzeroberflächen (User-to-Application, kurz: U2A)

Erforderliche Anpassungen

  • Feld „BranchId" entfernen: Alle Zahlungsnachrichten (pacs.008, pacs.009), die aktuell das Feld „BranchId" unter „CreditorAgent" befüllen, müssen vor Go-Live angepasst werden — das Feld darf nach Go-Live nicht mehr befüllt oder gesendet werden
  • Adressfelder strukturieren: Unstrukturierte Adresszeilen („Address Line") müssen auf maximal zwei Instanzen reduziert werden; „Town Name" und „Country" müssen künftig immer befüllt sein — alle Zahlungsvorlagen und Erfassungsmasken in TPH (Travic Payment Hub) und U2A prüfen und anpassen
  • Pflichtfelder ergänzen: Felder „Instructed Amount", „Scheme Name" sowie „Town Name" und „Country" müssen in allen betroffenen Nachrichten künftig befüllt sein — Erfassungsmasken in TPH und U2A entsprechend anpassen und Validierungslogik aktualisieren
  • MyStandards-Profile aktualisieren: Die Marktpraxis-Profile im MyStandards-System müssen für alle betroffenen Nachrichtentypen (mindestens pacs.004, pacs.008, pacs.009, pacs.010, camt.029, camt.053, camt.054, camt.056) auf den HVPS Plus UG2026-Stand gebracht werden
  • Erfassungsmasken in U2A prüfen: Die drei Erfassungsmasken „New Customer Credit Transfer", „New Financial Institution Credit Transfer" und „New Payment Return" müssen auf die neuen Pflichtfelder und den Wegfall des Feldes „BranchId" angepasst werden

Bewertung nach Kriterien

  • Änderungen an Nachrichtenstruktur: 3 × 0,40 = 1,20 → Mehrere bestätigte Element-Removals (BranchId, unstrukturierte Postal Address) sowie Pflichtfeld-Änderungen in pacs.008, pacs.009, pacs.004, camt.029, camt.056 — alle aktiv genutzt; Element-Removal-Override greift
  • Zahlungsabwicklung und Liquiditätssteuerung: 3 × 0,25 = 0,75 → Kern-Zahlungsnachrichten pacs.008 und pacs.009 direkt betroffen; Settlement-Prozesse und Liquiditätssteuerung unmittelbar tangiert
  • Technische Umsetzung: 3 × 0,20 = 0,60 → Mehrere Systeme gleichzeitig betroffen (TPH, MyStandards, SWIFT Alliance Gateway, U2A, Reporting-DWH); umfangreiche Koordination mit PPI AG erforderlich
  • Regulatorische Anforderungen: 3 × 0,15 = 0,45 → HVPS Plus Wartungsrelease UG2026 mit verbindlicher Deadline R2026.NOV; kein Opt-out für RTGS-Direktteilnehmer

Gesamtscore: 4,00 → Kritisch

Nächste Schritte (BA)

  • Bestandsaufnahme aller aktuell genutzten Zahlungsnachrichten (pacs.008, pacs.009, pacs.004) auf Vorkommen des Feldes „BranchId" unter „CreditorAgent" — Priorisierung der betroffenen Zahlungsvorlagen und Stammdaten
  • Analyse aller unstrukturierten Adressfelder in bestehenden Zahlungsvorlagen und Stammdaten: Wo werden mehr als zwei „Address Line"-Einträge genutzt? Wo fehlen „Town Name" oder „Country"?
  • Abstimmung mit dem Fachbereich Zahlungsverkehr zur Anpassung der Erfassungsmasken in TPH und U2A (drei betroffene Masken)
  • MyStandards-Profile für alle betroffenen Nachrichtentypen zur Überarbeitung an das zuständige Team übergeben
  • Kunden müssen über Feldentfernung informiert werden — alte Nachrichten mit dem Feld „BranchId" unter „CreditorAgent" werden nach Go-Live R2026.NOV abgelehnt.
  • Implementierung und Tests müssen spätestens 4–6 Wochen vor Go-Live R2026.NOV abgeschlossen sein

T2-0147-SYS: ISO-Wartungsrelease 2025 – T2-Nachrichten-Upgrade — Score 4 (Kritisch)

Was ändert sich?

T2 hebt fünf Nachrichtentypen auf den Stand des ISO-Wartungsrelease 2025 (kurz: ISO MR 2025) an — mit verbindlicher Wirkung zum Release R2026.NOV. Konkret bedeutet dies: Das Feld „Status Code" (Statuskennzeichnung) wird aus der Quittungsnachricht camt.025 (Receipt, Quittung) vollständig entfernt und durch eine neue Struktur unter „Proprietary" (Eigenfeld) ersetzt — Nachrichten, die noch den alten „Status Code" enthalten, werden nach Go-Live von T2 abgelehnt. Gleichzeitig erhalten die Kontoauszugsnachrichten camt.053 (Bank to Customer Statement, Kontoauszug) und camt.054 (Bank to Customer Debit/Credit Notification, Buchungsbenachrichtigung), der Zahlungsstatus-Bericht pacs.002 (Payment Status Report) sowie die Interbanken-Zahlungsnachricht pacs.009 (Financial Institution Credit Transfer) neue Versionsnummern — die alten Versionen dieser Nachrichten werden nach Go-Live nicht mehr akzeptiert. Zusätzlich ändert sich das Muster für BIC-Identifikatoren in der Kopfnachricht head.001 (ICL-Nachricht), was alle Nachrichten betrifft, die über diese Schicht geroutet werden.

Betroffene Prozesse

  • Quittungsverarbeitung und Statusrückmeldungen (Receipt-Verarbeitung) über camt.025
  • Kontoauszugs-Reporting und Buchungsabgleich über camt.053 und camt.054
  • Überwachung von Zahlungsstatusberichten über pacs.002
  • Ausgehende Interbanken-Zahlungen über pacs.009
  • Liquiditätssteuerung im CLM (Common Liquidity Management) — CLM-Zahlungsaufträge und Abrechnungsprozesse direkt betroffen

Erforderliche Anpassungen

  • Feld „Status Code" in camt.025 anpassen: Bestehende Prozesse, die den „Status Code" aus Quittungsnachrichten auslesen, müssen auf das neue Feld unter „Proprietary" umgestellt werden — betrifft alle Systeme, die camt.025-Nachrichten verarbeiten (Kernbankensystem, Reporting-DWH)
  • Neue Nachrichtenversionen implementieren: camt.053 (V12 → V13), camt.054 (V12 → V13), pacs.002 (V14 → V15), pacs.009 (V11 → V12) müssen in TPH, MyStandards-Profilen und im SWIFT Alliance Gateway auf die neuen Versionen aktualisiert werden
  • BIC-Muster in head.001 prüfen: Alle Nachrichtenverbindungen, die das bisherige BIC-Muster nutzen, müssen auf das neue Muster (BICFIDec2014Identifier) umgestellt werden — Abstimmung mit dem Team für den SWIFT Alliance Gateway
  • Neues Feld „InstructionCopy" in camt.054 einplanen: Das neue Feld „InstructionCopy" (Auftragsabbild) ersetzt in der Nachricht camt.054 die bisherige Nutzung von „Supplementary Data" (Zusatzdaten) im T2-Wiederherstellungskontext — Anpassung der Feldmappings in TPH und im Reporting-DWH
  • MyStandards-Profile für alle fünf Nachrichtentypen aktualisieren und Staging-Prozess mit PPI AG koordinieren

Bewertung nach Kriterien

  • Änderungen an Nachrichtenstruktur: 3 × 0,40 = 1,20 → Element-Removal bestätigt: „Status Code" (StsCd) aus camt.025 entfernt — aktiv genutzte Nachricht; zusätzlich Versionssprünge bei vier weiteren aktiv genutzten Nachrichtentypen; Element-Removal-Override greift
  • Zahlungsabwicklung und Liquiditätssteuerung: 3 × 0,25 = 0,75 → RTGS- und CLM-Kern-Flows direkt betroffen; Settlement- und Liquiditätssteuerungsprozesse tangiert
  • Technische Umsetzung: 3 × 0,20 = 0,60 → Mehrere Systeme gleichzeitig betroffen (SWIFT Alliance Gateway, Reporting-DWH, TPH, MyStandards, Kernbankensystem); koordinierte Umsetzung über alle Systeme erforderlich
  • Regulatorische Anforderungen: 3 × 0,15 = 0,45 → ISO MR 2025 verpflichtend für alle RTGS/CLM-Teilnehmer; Aktivierungsfenster T2 R2026.NOV ist verbindlich; kein Opt-out

Gesamtscore: 4,00 → Kritisch

Nächste Schritte (BA)

  • Bestandsaufnahme aller Prozesse und Systeme, die camt.025-Quittungsnachrichten mit dem Feld „Status Code" verarbeiten — Übergabe an Technik zur Parser-Anpassung
  • Priorisierung der Nachrichtenversions-Upgrades: camt.053, camt.054, pacs.002, pacs.009 — Anforderungen an MyStandards und TPH dokumentieren
  • Fachliche Prüfung: Welche Prozesse nutzen „Supplementary Data" in camt.054 für den Wiederherstellungsprozess? Umstellung auf „InstructionCopy" abstimmen
  • Testplanung für alle fünf betroffenen Nachrichtentypen anstoßen (End-to-End gegen T2-Testsystem); Koordination mit PPI AG und ECB/T2-Arbeitsgruppe einplanen
  • Kunden müssen über Feldentfernung informiert werden — alte Nachrichten mit dem Feld „Status Code" (StsCd) in camt.025 werden nach Go-Live R2026.NOV abgelehnt.
  • Implementierung und Tests müssen spätestens 4–6 Wochen vor Go-Live R2026.NOV abgeschlossen sein

T2-0170-SYS: ISO-Wartungsrelease 2026 – T2-Nachrichten-Upgrade — Score 4 (Kritisch)

Was ändert sich?

T2 migriert sechs Nachrichtentypen auf den Stand des ISO-Wartungsrelease 2026 (kurz: ISO MR 2026) — ebenfalls zum verbindlichen Aktivierungsfenster R2026.NOV. Betroffen sind camt.029 (Resolution of Investigation, Antwort auf Zahlungsrecherche), camt.053 (Kontoauszug), camt.054 (Buchungsbenachrichtigung), camt.056 (Payment Cancellation Request, Stornierungsanfrage), pacs.002 (Zahlungsstatusbericht) und pacs.009 (Interbanken-Zahlung) — fünf davon werden von der Bank aktiv genutzt. Die neuen Versionen werden zwischen Betriebsende Freitag und Betriebsbeginn Samstag aktiviert; ab diesem Zeitpunkt werden ausschließlich die neuen Versionen akzeptiert. Es gibt keine Übergangsphase — eine Nachricht in einer alten Version wird nach Go-Live von T2 sofort abgelehnt. Die Umsetzung ist eng mit parallel laufenden Änderungsprozessen (T2-CR-147, T2-CR-153, T2-CR-172) koordiniert abzuwickeln, da die Bereitstellung der verbindlichen XSD-Schemas (Nachrichtenstrukturbeschreibungen) für alle abhängigen Änderungen gemeinsam erfolgt — der Zeitplan ist mit einem Lieferdatum am 28. Juli 2026 (neun Bankarbeitstage vor dem Aktivierungsdatum) sehr eng bemessen.

Betroffene Prozesse

  • Ausgehende Interbanken-Zahlungen (Financial Institution Credit Transfer) über pacs.009
  • Überwachung von Zahlungsstatusberichten über pacs.002
  • Kontoauszugs-Reporting und Buchungsabgleich über camt.053 und camt.054
  • Zahlungsrecherche und Investigation (Zahlungsrecherche / Klärung) über camt.029
  • Zahlungsstornierung über camt.056
  • Liquiditätssteuerung im CLM sowie Reporting über das Reporting-Datawarehouse (DWH)
  • Schnittstellen zu den Abwicklungssystemen ECONS (Liquiditätskonten-System) und BILL (Billing-System)

Erforderliche Anpassungen

  • Nachrichtenversionen für fünf aktiv genutzte Typen umstellen: camt.053, camt.054, camt.056, pacs.002, pacs.009 müssen vollständig auf die neuen XSD-Versionen migriert werden — betrifft TPH, MyStandards-Profile, SWIFT Alliance Gateway und Reporting-DWH
  • Schnittstellen ECONS und BILL prüfen: Die Schnittstellen zwischen CLM und den Systemen ECONS (Liquiditäts-/Konten-Clearing-System) sowie BILL (Abrechnungssystem) müssen auf die neuen Nachrichtenversionen umgestellt werden — fachliche Anforderungsdokumentation erstellen
  • Koordination mit parallelen Änderungen: Die Umsetzung muss synchron mit den Änderungsvorhaben T2-CR-147, T2-CR-153 und T2-CR-172 geplant werden, da die Schema-Lieferung gebündelt erfolgt
  • MyStandards-Profile für alle acht neuen Nachrichtenprofile (CLM und RTGS je separat) aktualisieren und Freigabeprozess mit PPI AG rechtzeitig einleiten
  • U2A-Erfassungsmasken prüfen: Laut Änderungsdokumentation ist zu prüfen, ob GUI-Masken angepasst werden müssen, um die Ausrichtung von Anwendungsschnittstelle (A2A) und Benutzeroberfläche (U2A) zu gewährleisten

Bewertung nach Kriterien

  • Änderungen an Nachrichtenstruktur: 3 × 0,40 = 1,20 → Harter Versionsbruch ohne Übergangsphase bei fünf aktiv genutzten Nachrichtentypen; alte Versionen werden nach Go-Live abgelehnt — funktional einem Breaking Change gleichzusetzen
  • Zahlungsabwicklung und Liquiditätssteuerung: 3 × 0,25 = 0,75 → Settlement-Kern-Nachrichten pacs.009 und pacs.002 sowie Liquiditätssteuerungs-Nachrichten camt.053/camt.054 direkt betroffen; RTGS- und CLM-Prozesse vollumfänglich tangiert
  • Technische Umsetzung: 3 × 0,20 = 0,60 → Mehrere Systeme (SWIFT Alliance Gateway, Reporting-DWH, ECONS-Schnittstelle, TPH, MyStandards) gleichzeitig betroffen; Binding-XSD-Deadline am 28. Juli 2026 ist extrem eng — hohes Koordinationsrisiko
  • Regulatorische Anforderungen: 3 × 0,15 = 0,45 → ISO MR 2026 verpflichtend; verbindliche EZB-Deadline, kein Opt-out; HVPS+-Compliance-Pflicht

Gesamtscore: 4,00 → Kritisch

Nächste Schritte (BA)

  • Sofortige Projektplanung zur koordinierten Umsetzung von T2-0170-SYS gemeinsam mit den abhängigen Änderungen T2-CR-147, T2-CR-153 und T2-CR-172 — ein gemeinsamer Umsetzungsplan ist zwingend
  • Fachliche Anforderungen für die fünf betroffenen Nachrichtentypen (camt.053, camt.054, camt.056, pacs.002, pacs.009) dokumentieren und an MyStandards- und TPH-Projektteam übergeben
  • Auswirkungen auf die Schnittstellen zu ECONS und BILL im CLM-Kontext analysieren und Anpassungsbedarf dokumentieren
  • Prüfung der U2A-Erfassungsmasken auf Anpassungsbedarf einplanen
  • Testplanung (End-to-End gegen T2-Testsystem) für alle acht betroffenen Nachrichtenprofile in CLM und RTGS starten — Binding-XSD-Lieferdatum 28. Juli 2026 als festen Meilenstein einplanen
  • Kunden müssen über den Versionsbruch informiert werden — alte Nachrichtenversionen (z. B. camt.053.001.13, pacs.009.001.12) werden nach Go-Live R2026.NOV ohne Übergangsphase abgelehnt.
  • Implementierung und Tests müssen spätestens 4–6 Wochen vor Go-Live R2026.NOV abgeschlossen sein

Score 2 — Beobachten

T2-0135-SYS: Zusätzliche Routing-Konfigurationen in CRDM für NSP-Ausfälle — Score 2 (Mittel)

Kurzfassung: Dieses CR erweitert das CRDM (Common Reference Data Management, gemeinsames Stammdaten-Management) um die Möglichkeit, pro Netzwerkdienstleistungsanbieter (NSP — Network Service Provider) und pro Verwendungstyp (Standard oder Bedingt) sowie pro Teilnehmer-BIC jeweils eine zweite Routing-Konfiguration zu hinterlegen. Diese Zweit-Konfiguration kann bei einem Ausfall des primären NSP als Primär-Routing aktiviert werden. Das Feld „Primary: YES/NO" (Primär: JA/NEIN) wird als neues Pflichtattribut auf bestehende Routing-Einträge ergänzt. Es werden keine ISO 20022-Zahlungsnachrichten (pacs, camt) geändert — TPH und MyStandards-Profile sind nicht betroffen.

Relevanz für die Bank: Banken, die zwei NSPs für ihren A2A-Betrieb (Anwendung-zu-Anwendung, maschinelle Schnittstellen) nutzen, müssen ihre Routing-Einträge in CRDM um die Sekundär-Konfiguration erweitern und einen Switchover-Prozess (Umschaltprozess bei NSP-Ausfall) definieren. Banken mit nur einem NSP sind von dieser Änderung nicht aktiv betroffen. CLM und RTGS werden nur passiv berührt, da sie die Routing-Daten aus CRDM empfangen. Die Änderung unterstützt die Anforderungen an die operative Resilienz (Business Continuity) nach den geltenden Aufsichtsstandards. Beachte: Die Intraday-Aktivierung der Sekundär-Konfiguration hängt vom separaten Änderungsvorhaben T2-0060 (Intraday-Propagation von Stammdaten) ab.

Empfehlung: Im nächsten Sprint prüfen, ob die Bank zwei NSPs für A2A-Dienste betreibt. Falls ja: CRDM-Stammdaten-Erweiterung und Switchover-Prozess definieren. Falls nein: Keine aktive Maßnahme erforderlich; Beobachtung im Rahmen der regulatorischen Resilienzvorgaben beibehalten.


Score 0–1 kompakt

Für dieses Release wurden keine CRs mit einem Relevanzscore von 0 oder 1 identifiziert. Alle analysierten CRs erreichen einen Score von mindestens 2 und sind in den obigen Abschnitten berücksichtigt.


Handlungsempfehlungen (Zusammenfassung)

Zuerst (Score 4 — Kritisch, Breaking Changes mit verbindlicher Deadline R2026.NOV)

Die drei kritischen CRs haben alle denselben Go-Live-Termin (T2 R2026.NOV) und müssen koordiniert umgesetzt werden. Die Implementierung und vollständige Tests müssen spätestens 4–6 Wochen vor Go-Live R2026.NOV abgeschlossen sein.

  1. T2-0156-UDFS — HVPS Plus UG2026: Sofortige Bestandsaufnahme aller Zahlungsnachrichten auf Nutzung des Feldes „BranchId" und unstrukturierter Adressfelder. MyStandards-Profile und TPH aktualisieren, U2A-Erfassungsmasken (drei Screens) anpassen. Kunden informieren: Nachrichten mit „BranchId" werden nach Go-Live abgelehnt.

  2. T2-0147-SYS — ISO MR 2025: Sofortige Bestandsaufnahme aller Prozesse, die camt.025 mit dem Feld „Status Code" verarbeiten. Versionsupgrade für camt.053, camt.054, pacs.002, pacs.009 in MyStandards und TPH einleiten. Kunden informieren: Nachrichten mit altem Feld „Status Code" (StsCd) in camt.025 werden nach Go-Live abgelehnt.

  3. T2-0170-SYS — ISO MR 2026: Koordinierten Projektplan mit T2-CR-147, T2-CR-153 und T2-CR-172 erstellen. Binding-XSD-Liefertermin 28. Juli 2026 als harten Projektmeilenstein sichern. Schnittstellen zu ECONS und BILL im CLM analysieren. Kunden informieren: Alte Nachrichtenversionen (z. B. camt.053.001.13) werden nach Go-Live ohne Übergangsphase abgelehnt.

Danach (Score 2 — Mittel, kein Breaking Change)

  1. T2-0135-SYS — CRDM-Routing für NSP-Ausfall: Im nächsten Sprint prüfen, ob die Bank zwei NSPs für A2A betreibt. Gegebenenfalls CRDM-Stammdaten erweitern und Switchover-Prozess definieren. Abhängigkeit zu T2-0060 (Intraday-Propagation) im Blick behalten.

Später

Keine weiteren CRs mit Score unterhalb von 2 in diesem Release identifiziert.