Der zweite Stichtag
Im Oktober 2025 wurde die Empfängerseite von Verification of Payee Pflicht: Jeder Zahlungsdienstleister musste einen VoP-Endpunkt bereitstellen, der auf Anfragen antwortet. Ab April 2026 kommt die andere Hälfte: Jeder PSP, der Überweisungen initiiert, muss vor jeder Zahlung eine VoP-Prüfung beim Responding PSP durchführen.
Die Empfängerseite war die Aufwärmübung. Die Senderseite ist der Hauptlauf.
Warum die Senderseite komplexer ist
Als Responding PSP muss man im Wesentlichen einen API-Endpunkt bereitstellen und auf eingehende Anfragen antworten. Das ist technisch überschaubar: Request entgegennehmen, Name Matching durchführen, Ergebnis zurückschicken.
Als Requesting PSP muss man dagegen den gesamten Ablauf orchestrieren — und das in Echtzeit, bevor der Kunde seine Überweisung abschickt. Konkret:
1. EDS-Integration für das Routing
Bevor ein VoP-Request gesendet werden kann, muss das System wissen, wohin er gehen soll. Das Routing läuft über den EPC Directory Service (EDS):
- Aus der Empfänger-IBAN den Account-Holding BIC ableiten
- Im EDS-Cache den zugehörigen API-Endpunkt nachschlagen
- Prüfen, ob der Responding PSP ein registrierter VoP-Teilnehmer ist
Der EDS wird täglich aktualisiert. Das System muss den aktuellen und den nächsten Datensatz vorhalten und den Wechsel zum Effective Timestamp (02:00 UTC) sauber vollziehen. In der Praxis heißt das: Eine lokale Kopie des EDS in einem In-Memory-Cache (Redis oder vergleichbar), die täglich idempotent aktualisiert wird.
Wer als Responding PSP angefangen hat, kennt den EDS vielleicht aus der Autorisierung eingehender Requests. Für die Senderseite wird er zum zentralen Routing-Verzeichnis — und die Anforderungen an Aktualität und Verfügbarkeit steigen.
2. VoP-Request erzeugen und senden
Der VoP-Request geht als HTTP POST direkt an den API-Endpunkt des Responding PSP. Die Absicherung erfolgt über Mutual TLS mit QWAC-Zertifikaten nach PSD2 (ETSI 119 495). Das bedeutet:
- Ein gültiges QWAC-Zertifikat muss beschafft und verwaltet werden
- Die TLS-Konfiguration muss Client-Zertifikate unterstützen
- Das Zertifikat muss regelmäßig erneuert werden (typischerweise jährlich)
- Die Gegenseite prüft das Zertifikat — ein abgelaufenes oder ungültiges Zertifikat führt zum sofortigen Reject
Wer noch nie mit Mutual TLS gearbeitet hat, unterschätzt den operativen Aufwand. Zertifikatsverwaltung, Monitoring der Ablaufdaten, Austausch bei Erneuerung — das ist kein Set-and-Forget.
3. Ergebnis verarbeiten und anzeigen
Der Responding PSP antwortet mit einem der vier Ergebniscodes:
| Code | Bedeutung | Aktion im UI |
|---|---|---|
| MTCH | Name stimmt überein | Überweisung kann fortgesetzt werden |
| CMTC | Name ähnlich | Warnung anzeigen, korrekten Namen vorschlagen, Bestätigung einholen |
| NMTC | Name stimmt nicht überein | Warnung anzeigen, Nutzer muss aktiv bestätigen oder abbrechen |
| NOAP | Prüfung nicht anwendbar | Hinweis anzeigen, Überweisung kann fortgesetzt werden |
Bei CMTC und NMTC muss der Nutzer eine bewusste Entscheidung treffen. Das heißt: Das Online-Banking, die Banking-App und alle anderen Kanäle, über die Überweisungen erfasst werden, müssen diese Ergebnisse darstellen können. Für jede einzelne Überweisung. In Echtzeit.
Das ist nicht nur ein Backend-Thema. Die UX muss stimmen: Klar formulierte Warnungen, keine Panikmache bei Close Match, aber deutliche Warnung bei No Match. Die EPC gibt Empfehlungen für die Darstellung, aber die konkrete Umsetzung liegt beim Institut.
4. Timeout- und Fehlerbehandlung
Was passiert, wenn der Responding PSP nicht antwortet? Oder zu langsam? Oder mit einem HTTP 5xx? Die VoP-Spezifikation definiert eine Maximum Execution Time. Wird sie überschritten, muss das System entscheiden: Überweisung ohne VoP-Prüfung zulassen? Oder blockieren?
Die regulatorische Antwort ist klar: Die Überweisung darf auch ohne erfolgreiche VoP-Prüfung durchgeführt werden — aber der Nutzer muss darüber informiert werden, dass die Prüfung nicht möglich war. In der Praxis braucht das eine eigene UI-Variante: „Die Empfängerprüfung konnte nicht durchgeführt werden. Möchten Sie die Überweisung trotzdem ausführen?”
Auch technische Fehler auf der eigenen Seite (EDS-Cache nicht aktuell, TLS-Handshake fehlgeschlagen, interner Timeout) müssen sauber behandelt werden. Das System darf nicht in einen Zustand geraten, in dem Überweisungen grundsätzlich blockiert werden, weil eine VoP-Komponente ausgefallen ist.
Integration in bestehende Systeme
Online-Banking
Die meisten Banken haben ihre Überweisungserfassung organisch weiterentwickelt. Ein neuer Prüfschritt vor der Auftragserteilung greift tief in den bestehenden Flow ein:
- Nutzer gibt IBAN und Betrag ein
- Neu: System sendet VoP-Request im Hintergrund
- Neu: Ergebnis wird angezeigt, Nutzer muss ggf. bestätigen
- Nutzer gibt TAN ein
- Überweisung wird ausgeführt
Schritt 2 und 3 müssen in den bestehenden Ablauf eingefügt werden — asynchron, ohne die Seite zu blockieren, und schnell genug, dass der Nutzer nicht ungeduldig wird. Bei einer schlechten Internetverbindung des Nutzers oder einem langsamen Responding PSP wird das zur UX-Herausforderung.
Batch-Verarbeitung
Firmenkundenüberweisungen laufen oft als Batch: Hunderte oder tausende Zahlungen in einer pain.001-Datei. Muss für jede einzelne Zahlung ein VoP-Request gesendet werden? Die Antwort ist ja — und das hat Implikationen für die Verarbeitungszeit.
Bei 1.000 Zahlungen und einer durchschnittlichen VoP-Response-Zeit von 2 Sekunden ergibt sich sequentiell eine Gesamtdauer von über 30 Minuten. Parallelisierung hilft, aber erzeugt Last auf den Responding PSPs. Rate Limiting auf der Gegenseite ist zu erwarten. Die Batch-Verarbeitung muss also intelligent sein: Parallelisierung mit Backpressure, Retry-Logik bei Timeouts, und eine saubere Zuordnung der Ergebnisse zu den einzelnen Zahlungen.
Mobile Banking
Banking-Apps haben eigene Herausforderungen: instabile Netzwerkverbindungen, kleinere Bildschirme für die Warnungsdarstellung, und Nutzer, die wenig Geduld für zusätzliche Prüfschritte haben. Die VoP-Integration muss sich nahtlos in den mobilen Überweisungsablauf einfügen, ohne ihn spürbar zu verlangsamen.
Was wir aus der Empfängerseite gelernt haben
Im Oktober 2025 haben wir beim Bank-Verlag die VoP-Empfängerseite aufgebaut. Einige Erkenntnisse, die direkt auf die Senderseite übertragbar sind:
EDS-Datenqualität
Der EDS ist gut gepflegt, aber nicht fehlerfrei. Gelegentlich fehlen API-URIs für einzelne BICs, oder die Zuordnung von NANs zu Teilnehmern ist nicht aktuell. Das System muss mit fehlenden oder inkonsistenten EDS-Daten umgehen können, ohne Überweisungen pauschal zu blockieren.
Latenz-Schwankungen
Die Response-Zeiten der Responding PSPs schwanken erheblich. Manche antworten in unter 100 Millisekunden, andere brauchen mehrere Sekunden. Die Maximum Execution Time im VoP Scheme Rulebook muss als harter Timeout implementiert werden — wer länger wartet, riskiert, dass der Nutzer die Geduld verliert.
Zertifikatsverwaltung
QWAC-Zertifikate haben eine begrenzte Laufzeit. Ein abgelaufenes Zertifikat bedeutet: Kein VoP mehr möglich. Monitoring der Ablaufdaten und rechtzeitiger Austausch sind Pflicht. Klingt banal, wird in der Praxis trotzdem vergessen.
Unser Ansatz
Wir haben VoP für beide Seiten gebaut. Beim Bank-Verlag die Empfängerseite auf Basis der msg-Komponente — von der EDS-Integration über Datenmigration und Security-Setup bis zur Produktionsanbindung. Parallel dazu unser eigenes VoP-System, das als Whitelabel-Produkt zur Lizenzierung bereitsteht und beide Seiten abdeckt: Requesting und Responding.
Die Senderseite ist die anspruchsvollere Hälfte. Wer die Architektur von Anfang an richtig aufsetzt — EDS-Caching, Mutual TLS, asynchrone Orchestrierung, saubere Fehlerbehandlung — hat ein System, das auch unter Last und bei Ausfällen einzelner Responding PSPs stabil bleibt.
Fazit
Der April 2026 ist in einem Monat. Wer die Senderseite noch nicht produktionsreif hat, wird es knapp. Die technischen Anforderungen gehen über die Empfängerseite hinaus: EDS-Routing, Mutual TLS, UI-Integration, Batch-Verarbeitung, Timeout-Handling. Jede einzelne Komponente ist machbar. Die Herausforderung liegt in der Orchestrierung — alles muss in Echtzeit zusammenspielen, bevor der Kunde auf „Überweisen” klickt.
Wer tiefer einsteigen will: VoP Go-Live Oktober 2025 beschreibt die Grundlagen, Verification of Payee die technischen Details des Protokolls.