IBAN getestet, DEAN verstanden?
Warum der digitale Euro neue Teststrategien erfordert

Eine deutsche IBAN besteht aus 22 Stellen. Sie enthält das Länderkennzeichen „DE“, eine zweistellige Prüfziffer sowie eine nationale Kontokennung. Diese setzt sich in Deutschland aus der achtstelligen Bankleitzahl und der zehnstelligen Kontonummer zusammen. Damit enthält die deutsche IBAN Informationen, anhand derer sich das kontoführende Institut beziehungsweise dessen Bankleitzahl ableiten lässt.

Typische IBAN-Tests sind deshalb vergleichsweise klar strukturiert:

• Ist die Länge für das jeweilige Land korrekt?
• Ist der Ländercode zulässig?
• Sind an den vorgesehenen Positionen nur erlaubte Zeichen enthalten?
• Ist die Prüfziffer nach MOD 97-10 korrekt?
• Ist die enthaltene Bankleitzahl formal gültig?
• Kann die IBAN einem erreichbaren Zahlungsdienstleister zugeordnet werden?
• Werden Leerzeichen, Kleinbuchstaben und Formatierungszeichen korrekt behandelt?
• Werden fehlerhafte oder unvollständige Eingaben eindeutig abgelehnt?

Viele dieser Prüfungen können lokal, reproduzierbar und ohne Zugriff auf ein zentrales Kontenregister durchgeführt werden.

Nach dem aktuellen Entwurfsstand besteht die DEAN aus 18 alphanumerischen Zeichen. Vorgesehen sind das Präfix „EU“, zwei Prüfziffern nach ISO/IEC 7064 MOD 97-10, eine Indikatorziffer sowie eine 13-stellige Seriennummer. Die Indikatorziffer soll zwischen Privat- und Geschäftsnutzung unterscheiden.

Die optische Ähnlichkeit kann leicht zu einer falschen fachlichen Annahme führen. Das Präfix „EU“ ist kein klassisches Länderkennzeichen wie „DE“, „FR“ oder „NL“. Außerdem enthält die DEAN nach dem aktuellen Entwurf keine Kennung des Zahlungsdienstleisters. Aus der Zeichenfolge lässt sich somit nicht unmittelbar erkennen, welches Institut das zugehörige Digital-Euro-Konto betreut.

Die DEAN soll zentral durch die Digital Euro Service Platform erzeugt werden. Erst in einem weiteren Schritt wird die generierte Kennung dem anfragenden Zahlungsdienstleister und dem jeweiligen Digital-Euro-Konto zugeordnet. Damit wird die fachliche Gültigkeit nicht allein durch Format und Prüfziffer bestimmt. Entscheidend ist auch, ob die zentrale Zuordnung vorhanden, aktuell und für den jeweiligen Geschäftsvorfall zulässig ist.

Ein klassischer positiver IBAN-Test verwendet eine formal korrekte IBAN mit gültiger Prüfziffer. Anschließend wird geprüft, ob die Anwendung die Kontokennung akzeptiert. Für die DEAN ist dieser Test zu schwach. Eine gültige Prüfziffer beweist nur, dass die Zeichenfolge mathematisch konsistent ist. Sie beweist nicht, dass:

• die DEAN von der zentralen Plattform erzeugt wurde,
• die DEAN einem Digital-Euro-Konto zugeordnet ist,
• die DEAN aktiv ist,
• der richtige Zahlungsdienstleister zuständig ist,
• die Nutzung für den konkreten Geschäftsvorfall zulässig ist.

Mein Lösungsansatz

Ich würde die Testfälle konsequent in zwei Gruppen trennen:

Lokale Validierung

• Format
• Länge
• Präfix
• Zeichenvorrat
• Prüfziffer
• Indikator für Privat- oder Geschäftsnutzung

Zentrale fachliche Validierung

• Existenz der DEAN
• Status der DEAN
• Zuordnung zum Digital-Euro-Konto
• Zuordnung zum aktuellen Zahlungsdienstleister
• Zulässigkeit der Transaktion
• Erreichbarkeit der zentralen Dienste

Dadurch wird verhindert, dass ein Entwickler oder Tester „Prüfziffer gültig“ mit „Zahlung möglich“ gleichsetzt.

Bei einer deutschen IBAN kann eine Anwendung die enthaltene Bankleitzahl auswerten. Einige Zahlungsprozesse, Prüfverfahren und Testdatenwerkzeuge nutzen diese Information zur Ermittlung des Instituts.

Bei der DEAN ist eine solche Ableitung nach dem derzeitigen Entwurf nicht möglich. Der zuständige Zahlungsdienstleister muss über eine separate Zuordnung festgestellt werden.

Das erzeugt neue Fehlerbilder:

• Die DEAN ist gültig, aber die Zuordnung zum Zahlungsdienstleister fehlt.
• Die Zuordnung zeigt auf einen falschen Zahlungsdienstleister.
• Die lokale Anwendung arbeitet mit einem veralteten Zuordnungsstand.
• Zwei Systeme liefern widersprüchliche Zuständigkeitsinformationen.
• Der Routingdienst ist nicht erreichbar.
• Eine Antwort trifft verspätet oder doppelt ein.

Mein Lösungsansatz

Ich würde neben den fachlichen Positivtests gezielte Integrations- und Resilienztests einplanen:

• korrekte Zuordnung,
• fehlende Zuordnung,
• veraltete Zuordnung,
• widersprüchliche Zuordnung,
• Zeitüberschreitung,
• technische Nichtverfügbarkeit,
• doppelte Antwort,
• verspätete Antwort,
• Wiederholung nach einem Timeout.

Dabei müsste für jeden Fehlerfall definiert werden, ob die Transaktion abzulehnen, zurückzustellen oder kontrolliert zu wiederholen ist.

Da die DEAN keine Institutskennung enthält, könnte ein Wechsel des Zahlungsdienstleisters möglich sein, ohne dass sich die DEAN allein deshalb ändern muss. Gerade dieser Punkt muss jedoch gegen das jeweils gültige Regelwerk und die endgültigen Migrationsvorgaben getestet werden. Für Testmanager entsteht daraus eine neue Kategorie von Lebenszyklustests:

1. DEAN ist dem bisherigen Zahlungsdienstleister zugeordnet.
2. Ein Wechsel wird eingeleitet.
3. Die Zuständigkeit wird auf den neuen Zahlungsdienstleister übertragen.
4. Bereits begonnene Zahlungen werden korrekt verarbeitet.
5. Neue Zahlungen werden an den neuen Dienstleister geleitet.
6. Die Historie bleibt nachvollziehbar.
7. Es entstehen weder Doppelbuchungen noch unzulässige Ablehnungen.

Mein Lösungsansatz

Ich würde Migrationen nicht als administrativen Nebenvorgang behandeln, sondern als eigenen Ende-zu-Ende-Testbereich. Besonders wichtig wären zeitlich präzise Testfälle unmittelbar vor, während und nach dem Umschaltzeitpunkt.

Die DEAN soll nach jetzigem Stand eine Indikatorziffer enthalten, die zwischen Privat- und Geschäftsnutzung unterscheidet. Für Privatnutzer und Geschäftskunden können außerdem unterschiedliche Vergabe- und Nutzungsregeln gelten. Dadurch entstehen Testkombinationen, die über die reine Formatprüfung hinausgehen:

• Privatkunde mit zulässiger DEAN
• Geschäftskunde mit zulässiger DEAN
• Privatkunde mit einer als geschäftlich gekennzeichneten DEAN
• Geschäftskunde mit einer als privat gekennzeichneten DEAN
•Versuch einer unzulässigen weiteren Vergabe
• Zusammenführung oder Trennung von Kundenbeziehungen
• Wechsel des Kundentyps
• Änderungen während eines laufenden Zahlungsprozesses

Mein Lösungsansatz

Ich würde eine regelbasierte Entscheidungstabelle erstellen. Die Dimensionen wären mindestens Kundentyp, DEAN-Typ, Kontostatus, Zahlungsart, Kanal und Zahlungsdienstleister. Aus dieser Entscheidungstabelle lassen sich anschließend automatisierte Testfälle generieren.

Die DEAN ist Teil eines umfassenderen digitalen Euro-Ökosystems. Das geplante Regelwerk umfasst unter anderem Ende-zu-Ende-Abläufe, Benutzerverwaltung, Transaktionsmanagement, Schnittstellenstandards, Sicherheitsanforderungen sowie ein Zertifizierungs- und Testframework für die beteiligten Zahlungsdienstleister.

Damit reicht ein isolierter Komponententest der Bankanwendung nicht aus. Eine Zahlung kann lokal korrekt verarbeitet werden und trotzdem in der Kommunikation mit der zentralen Plattform scheitern.

Mein Lösungsansatz

Ich würde eine mehrstufige Testarchitektur einsetzen:

1. Unit-Tests für Format und Prüfziffer
2. Komponententests für DEAN-Verarbeitung und Fehlerbehandlung
3. Vertragstests für APIs und Nachrichtenformate
4. Integrationstests mit einem Simulator der zentralen Plattform
5. Ende-zu-Ende-Tests über mehrere Zahlungsdienstleister
6. Resilienztests mit Timeouts, Teilausfällen und Wiederanläufen
7. Zertifizierungs- und Abnahmetests gegen die jeweils gültige Referenzumgebung

Ein leistungsfähiger Simulator wäre dabei besonders wichtig. Der Simulator müsste nicht nur erfolgreiche Antworten liefern, sondern auch fachliche Ablehnungen, technische Fehler, verzögerte Antworten, doppelte Nachrichten und widersprüchliche Statusinformationen erzeugen können.

Bei einer IBAN können Testumgebungen häufig künstlich erzeugte, formal gültige Kontonummern verwenden. Bei der DEAN besteht die Gefahr, dass eine synthetisch erzeugte Kennung zufällig mit einer zentral vergebenen Kennung kollidiert oder von einer Anwendung fälschlich als realer Datensatz behandelt wird.

Hinzu kommt, dass die zentrale Zuordnung zwischen DEAN, Nutzerkonto und Zahlungsdienstleister besonders schützenswert ist. Das künftige Digital-Euro-Regelwerk soll hohe Anforderungen an Datenschutz, Sicherheit und eine harmonisierte Nutzung im gesamten Euroraum berücksichtigen.

Mein Lösungsansatz

Ich würde:

• reservierte Testnummernräume verwenden,
• Testdaten eindeutig als nicht produktiv kennzeichnen,
• produktive DEANs nicht in Entwicklungs- oder Abnahmesysteme kopieren,
• personenbezogene Zuordnungen pseudonymisieren,
• Zugriffe auf Testdaten protokollieren,
• Testdaten nach Abschluss kontrolliert löschen,
• Negativtests mit synthetischen, garantiert nicht vergebenen DEANs durchführen.

Die Reservierung geeigneter Testbereiche müsste verbindlich mit dem zentralen Betreiber abgestimmt werden. Freie Seriennummern sollten nicht eigenmächtig angenommen werden.

Testziel: Eine Privatperson überträgt digitale Euro an eine andere Privatperson.

Vorbedingungen:

• Beide DEANs wurden zentral vergeben.
• Beide Digital-Euro-Konten sind aktiv.
• Sender und Empfänger sind unterschiedlichen Zahlungsdienstleistern zugeordnet.
• Der Sender verfügt über ausreichendes Guthaben.
• Die beteiligten Schnittstellen und Auditfunktionen sind aktiv.

Testablauf:

1. Auftraggeber gibt die DEAN des Empfängers ein.
2. Die Anwendung prüft Format und Prüfziffer.
3. Das System ermittelt die zentrale Zuordnung.
4. Die Zahlung wird autorisiert.
5. Die zentrale Verarbeitung wird durchgeführt.
6. Sender und Empfänger erhalten einen eindeutigen Status.
7. Kontostände und Transaktionshistorien werden geprüft.
8. Audit- und Protokolldaten werden abgeglichen.

Erwartetes Ergebnis:

• Die Empfänger-DEAN wird korrekt erkannt.
• Die Zahlung wird genau einmal ausgeführt.
• Belastung und Gutschrift stimmen überein.
• Es tritt keine Doppelbuchung auf.
• Sender und Empfänger erhalten konsistente Statusmeldungen.
• Der gesamte Vorgang ist revisionssicher nachvollziehbar.

Anschließend sollte derselbe Ablauf mit ungültiger Prüfziffer, unbekannter DEAN, gesperrter DEAN, falschem Kundentyp, nicht erreichbarer Plattform, Timeout und wiederholtem Sendeversuch durchgeführt werden.