Eine Wallet kann einen gültigen kryptografischen Nachweis erzeugen, während für die Bank noch Fragen offen sind: Auf welches Konto bezieht er sich? Was hat der Kunde bestätigt? Erfüllen die Nachweise die Authentifizierungsrichtlinie der Bank? Wer trägt die Verantwortung, wenn etwas schiefgeht?
Die SCARLET-Initiative des EPC rückt diese Akzeptanzfragen in den Mittelpunkt. Für Teams, die EUDI Wallets integrieren, besteht der nächste sinnvolle Schritt darin, diese Fragen anhand konkreter Tests zu prüfen.
Was der EPC angekündigt hat
Am 24. September 2026 hat der Vorstand des European Payments Council den Start von SCARLET beschlossen: dem Strong Customer Authentication Acceptance Rulebook and Liability Framework for EUDIW Transactions, einem Akzeptanzregelwerk und Haftungsrahmen für die starke Kundenauthentifizierung bei EUDIW-Transaktionen.
Der EPC plant geschäftliche und vertragliche Regeln, gemeinsame funktionale und betriebliche Regeln sowie technische Spezifikationen auf Grundlage des ARF, der TS12 und der Beiträge aus groß angelegten Pilotprojekten. Die Entwicklung erfolgt auf Einladung der Generaldirektionen CNECT und FISMA der Europäischen Kommission, in Zusammenarbeit mit der Kommission und der Europäischen Bankenaufsichtsbehörde sowie unter Einbindung einer Gruppe verschiedener Interessenträger.
Angekündigt sind eine öffentliche Konsultation im Sommer 2027 und die Veröffentlichung des ersten Regelwerks im Dezember 2027. Version 1.0 soll den bestehenden PSD2-Rahmen abdecken; eine spätere Version 1.1 soll ihn auf die PSR erweitern. Der Betrieb des Schemes ist nach einer Umsetzungsphase vorgesehen.
Dies sind Entwicklungspläne. Die Ankündigung enthält weder ein fertiges Regelwerk noch eine Zertifizierung einer bestimmten Implementierung. Siehe die EPC SCARLET announcement.
Warum Akzeptanz mehr als eine Signatur erfordert
Ein Kunde bestätigt beispielsweise eine Zahlung über 25 EUR an einen Händler. Die Bank erhält einen Nachweis mit gültiger Signatur. Das ist eine notwendige Prüfung, lässt aber mehrere Entscheidungen offen.
Die Bank muss das zur Signatur gehörende Credential dem vorgesehenen Kunden und der vorgesehenen Zahlungsquelle zuordnen. Sie muss feststellen, dass der bestätigte Betrag und Zahlungsempfänger mit dem Zahlungsauftrag übereinstimmen. Sie muss ihre Authentifizierungs- und Risikorichtlinien anwenden, die erneute Verwendung von Autorisierungen verhindern und mit unklaren Ausführungsergebnissen umgehen, ohne eine weitere Zahlung auszulösen.
Aus unserer Sicht sollte Interoperabilität entlang dieser gesamten Entscheidungskette bewertet werden. Eine erfolgreiche Präsentation liefert nützliche Nachweise; ihre Bedeutung hängt vom Kontext und den angewendeten Regeln ab.
Vier Ergebnisse, die getrennt bleiben sollten
In unserem vorgeschlagenen Versuch unterscheiden wir vier Ergebnisse:
- Nachweis verifiziert: Der ursprüngliche Nachweis hat die erforderlichen Prüfungen der Kryptografie, des Credentials und der Transaktionsbindung bestanden.
- Authentifizierungsrichtlinie erfüllt: Die verfügbaren Nachweise erfüllen die von der Bank gewählte Richtlinie.
- Autorisierung akzeptiert: Die Bank akzeptiert die Autorisierung des Kunden für den vorgesehenen Auftrag.
- Zahlung ausgeführt: Das Zahlungssystem meldet die Ausführung; Quelle und Status dieser Meldung sind ausgewiesen.
Diese Unterscheidungen sind bei Fehlern entscheidend. Auch bei einem gültigen kryptografischen Nachweis können erforderliche Authentifizierungsnachweise fehlen. Auf eine akzeptierte Autorisierung kann eine fehlgeschlagene Überweisung folgen. Nach einer Zeitüberschreitung kann unklar sein, ob die Zahlung ausgeführt wurde. Entwicklungs- und Betriebsteams müssen diese Unterschiede erhalten, anstatt sie zu einer einzigen Erfolgsmeldung zusammenzufassen.
Der tatsächliche Zahlungsempfänger muss derselbe bleiben
Der dem Kunden angezeigte Empfängername identifiziert für sich allein nicht das Konto, auf dem die Zahlung eingehen wird.
Für einen Pilotversuch schlagen wir eine authentifizierte Zuordnung zwischen dem bestätigten Zahlungsempfänger, dem erwarteten Händler und dem tatsächlichen Begünstigten vor. Diese Zuordnung gehört zum Autorisierungskontext und muss für die betreffende Autorisierung unverändert bleiben. Ändert ein Intermediär später das Zielkonto, muss das ausführende System den geänderten Auftrag zurückweisen.
Dies ist eine ausdrückliche Anforderung unseres Versuchs. Wir behaupten damit nicht, dass jeder ursprüngliche Nachweis bereits die Kennung des Empfängerkontos enthält. Für Implementierer stellt sich die Frage, welche signierten Felder und authentifizierten Zuordnungen diese Verbindung eindeutig herstellen.
Die ursprünglichen Nachweise erhalten
Wallet-Verfahren und browserbasierte Authentifizierung verwenden unterschiedliche Nachweisstrukturen. Die Verifizierung sollte diese Unterschiede berücksichtigen.
EWC RFC008 beschreibt die Bestätigung von Zahlungsdaten über OpenID4VP, eine Payment Wallet Attestation und Hashwerte der Transaktionsdaten in einem Key-Binding-JWT. In einem Ablauf mit drei Parteien müssen die Zahlungsdetails außerdem mit den vom Intermediär übermittelten Angaben abgeglichen werden.
Secure Payment Confirmation ermöglicht einen vom Browser gesteuerten Bestätigungsvorgang mit WebAuthn. Das Verifizierungsverfahren prüft neben dem Authentifizierungsnachweis auch die Zahlungsinformationen und die erwarteten Web-Ursprünge, die sogenannten Origins.
Ein gemeinsamer Akzeptanzversuch kann die Prüfpflichten dieser Verfahren vergleichen, ohne ihre Nachweise umzuwandeln oder neu zu signieren. Jeder Adapter sollte die ursprünglichen Artefakte erhalten und einem auf eine bestimmte Version festgelegten Profil des jeweiligen Verfahrens folgen. Gleiche Ergebnisbezeichnungen belegen kein gleiches Vertrauensniveau.
SPC dient in unserem Versuch als Vergleichsverfahren. Seine Einbeziehung bedeutet nicht, dass es vom SCARLET-Regelwerk erfasst wird.
Unser vorgeschlagener Beitrag
DLBR hat den Vorschlag Interoperable Payment Authorization Evidence Profile im Repository der W3C-Community EUDI-4-Payments eingereicht.
Der erste vorgeschlagene Versuch ist bewusst klein gehalten: eine Bank, eine SPC-Implementierung und ein Wallet-Team, mit einer sofortigen Zahlung, einer Währung und einem Begünstigten. Eine gemeinsame Testmatrix soll die Manipulation von Betrag und Empfänger, falsche Origins, abgelaufene Challenges, fehlende Authentifizierungsnachweise, Replay-Angriffe und eine doppelte Ausführung bei Wiederholungen oder beim Wechsel des Verfahrens abdecken.
Der Vorschlag untersucht außerdem, wie Nachweise nach Änderungen an Schlüsseln, Metadaten oder Richtlinien weiterhin überprüfbar bleiben können. Dafür sollen das jeweils gültige öffentliche Verifikationsmaterial und die ursprünglichen Artefakte unter kontrolliertem Zugriff aufbewahrt werden. Private Schlüssel und Authentifizierungsgeheimnisse bleiben vom Nachweisarchiv ausgeschlossen.
Wir möchten mit dieser Arbeit Implementierungserkenntnisse und wiederverwendbare Akzeptanztests liefern, die in die Entwicklung von SCARLET einfließen könnten. Es handelt sich um einen unabhängigen Diskussionsvorschlag. Damit sind weder eine Unterstützung durch EPC oder W3C noch ein vereinbarter Pilotversuch oder eine nachgewiesene Interoperabilität im Produktivbetrieb verbunden. Vertragliche Teilnahmevoraussetzungen und Haftungsfragen richten sich weiterhin nach dem geltenden Recht, den Verträgen und dem gewählten Scheme.
Was Teams jetzt vorbereiten können
Wir empfehlen, die Akzeptanzentscheidungen zu dokumentieren, die eine Integration bereits trifft: die Zuordnung von Credential und Konto, den Abgleich der bestätigten Transaktion, die Authentifizierungsnachweise, die Empfängerzuordnung und das Verhalten bei Wiederholungen. Anschließend lässt sich bestimmen, welche Prüfungen das gewählte Profil bereits abdeckt und welche von Bank- oder Scheme-Regeln abhängen.
Daraus entstehen konkrete Fragen für die Entwicklung und Konsultation des Regelwerks. Zugleich erhalten potenzielle Pilotpartner eine Grundlage, die sie gemeinsam prüfen und testen können.
Banken, Wallet-Teams und Zahlungsintegratoren können den Vorschlag und die Negativtestmatrix prüfen. Unsere Fragestellung ist praktisch: Können unterschiedliche ursprüngliche Nachweise eine klar definierte Akzeptanzentscheidung unterstützen und dabei Belege liefern, die alle verantwortlichen Parteien überprüfen können?