Der Stichtag: 5. und 9. Oktober 2025

Es sind zwei Daten, die zusammenspielen. Am 5. Oktober 2025 tritt das EPC VoP-Scheme (Rulebook v1.0) operativ in Kraft und definiert das Verfahren und die technischen Spezifikationen für die Empfängernamensprüfung. Vier Tage später, am 9. Oktober 2025, greift die regulatorische Pflicht aus Artikel 5c der durch die EU Instant Payment Regulation (Verordnung (EU) 2024/886) (IPR) geänderten SEPA-Verordnung: Eurozone-PSPs müssen ab diesem Datum bei jeder Überweisung eine Verification of Payee anbieten, SCT und SCT Inst gleichermaßen. Es ist kein Pilotprojekt mehr, keine freiwillige Teilnahme, sondern regulatorisches Pflichtprogramm.

Die IPR verpflichtet alle Zahlungsdienstleister im EU- und EWR-Raum, sowohl als anfragende als auch als empfangende Seite VoP zu unterstützen, mit gestaffelten Fristen: Eurozone-PSPs ab 9. Oktober 2025, Nicht-Eurozone-PSPs ab 9. Juli 2027, Zahlungsinstitute und E-Geld-Institute mit eigenen Sonderfristen 2027.

Was sich ab dem Stichtag konkret ändert

Ab dem 9. Oktober 2025 muss jede Überweisung im SEPA-Raum, die ein Eurozone-PSP initiiert oder empfängt, mit einer Empfängernamensprüfung versehen werden. Das betrifft den gesamten Prozess:

Für den Requesting PSP (anfragende Seite)

  • Vor jeder Überweisung muss ein VoP-Request an den Responding PSP gesendet werden
  • Das Ergebnis (Match (MTCH), Close Match (CMTC), No Match (NMTC) oder Not Applicable (NOAP)) muss dem Nutzer angezeigt werden
  • Bei NMTC oder CMTC muss der Nutzer die Überweisung aktiv bestätigen oder abbrechen
  • Die Prüfung muss innerhalb der Maximum Execution Time abgeschlossen sein, definiert im VoP Scheme Rulebook (EPC)

Für den Responding PSP (empfangende Seite)

  • Ein VoP-API-Endpunkt muss bereitstehen, der Anfragen in Echtzeit per REST-API beantwortet
  • Der Namensvergleich muss gegen die Kontostammdaten erfolgen
  • Alle vier Ergebniscodes (MTCH, NMTC, CMTC, NOAP) müssen korrekt als HTTP 200 Response zurückgeliefert werden
  • Bei Fehlern: HTTP 4xx/5xx mit strukturierten Error Message Codes
  • Logging und Audit-Trails sind regulatorisch vorgeschrieben

Für den Endkunden

  • Bei jeder Überweisung erscheint eine zusätzliche Prüfung vor der Freigabe
  • Bei Namensabweichungen gibt es einen Warnhinweis mit der Möglichkeit, die Transaktion abzubrechen
  • Das Ziel: Schutz vor Überweisungsbetrug durch gefälschte IBANs oder manipulierte Rechnungen

Wer ist betroffen?

Die Verordnung gilt für alle Zahlungsdienstleister im EWR, die SEPA-Überweisungen verarbeiten. Das umfasst:

  • Banken und Sparkassen, sowohl Großbanken als auch Regionalinstitute
  • Zahlungsinstitute und E-Geld-Institute mit SEPA-Teilnahme (mit eigener Frist 2027)
  • FinTechs und Neobanken mit eigener Banklizenz oder als technischer Dienstleister
  • Genossenschaftsbanken und Bausparkassen mit Zahlungsverkehrsanbindung

Ausgenommen sind lediglich Institute, die überhaupt keine Überweisungen verarbeiten. In der Praxis betrifft VoP damit nahezu jeden Zahlungsdienstleister in Europa.

Technische Voraussetzungen zum Go-Live

Ein produktionsreifes VoP-System besteht aus mehreren Komponenten, die zum Stichtag fehlerfrei zusammenspielen müssen:

1. EPC Directory Service und Routing

VoP-Requests laufen nicht über die klassische Clearing-Infrastruktur (wie RT1 oder TARGET), sondern werden direkt zwischen den Zahlungsdienstleistern ausgetauscht. Die zentrale Komponente für das Routing ist der EPC Directory Service (EDS).

Der EDS ist ein täglich aktualisiertes Verzeichnis aller VoP-Teilnehmer im SEPA-Raum. Er wird vom EPC als JSON-, XML- oder CSV-Datei publiziert und enthält für jeden Teilnehmer:

  • Participant BIC (ISO 9362): Identifikation des Zahlungsdienstleisters
  • NANs (National Account Numbers): Die nationalen Kontonummernformate, für die der Teilnehmer zuständig ist
  • API-URI pro Account-Holding BIC: Der konkrete API-Endpunkt, an den VoP-Requests gesendet werden

Das Routing funktioniert in zwei Schritten: Aus der Empfänger-IBAN (ISO 13616) wird der Account-Holding BIC abgeleitet. Über den EDS-Cache wird der zugehörige API-Endpunkt ermittelt. Der VoP-Request geht dann direkt an diesen Endpunkt, ohne Umweg über ein Clearing-Netzwerk.

Jede EDS-Datei hat einen Effective Timestamp (typischerweise 02:00 UTC). Ab diesem Zeitpunkt gilt der neue Datensatz. Der vorherige bleibt bis dahin gültig. Das bedeutet: Das System muss mindestens den aktuellen und den nächsten Datensatz vorhalten, um den Wechsel zum Stichtag sauber zu vollziehen.

Für die Autorisierung eingehender VoP-Requests prüft die empfangende Seite anhand des EDS, ob der anfragende BIC ein registrierter Teilnehmer ist und ob die angefragte National Account Number (NAN) in dessen Zuständigkeitsbereich fällt. Ohne gültigen EDS-Eintrag wird der Request abgelehnt.

2. Name Matching Engine

Der Kern des Systems: ein Algorithmus, der den übermittelten Empfängernamen mit dem hinterlegten Kontoinhaber vergleicht. Die Herausforderungen sind erheblich:

  • Normalisierung: Umlaute, Titel, Rechtsformen, Sonderzeichen müssen vereinheitlicht werden
  • Phonetische Analyse: Kölner Phonetik oder Double Metaphone für klangähnliche Namen
  • Fuzzy Matching: Levenshtein-Distanz für Tippfehler und Schreibvarianten
  • Gemeinschaftskonten: Mehrere Inhaber pro IBAN erfordern Multi-Match-Logik

Die Schwellenwerte für Match vs. Close Match vs. No Match müssen kalibriert sein: zu streng produziert Fehlalarme, zu lax lässt Betrug durch.

3. VoP Inter-PSP API

Die Kommunikation zwischen den PSPs erfolgt über eine REST API, spezifiziert in den VoP Inter-PSP API Specifications (EPC103-24). Die API nutzt ISO 20022-Datentypen als Ressourcenelemente, es werden aber keine klassischen ISO 20022 XML-Nachrichten (wie acmt.040/041) ausgetauscht. Das System muss:

  • VoP-Requests per HTTP POST an den Responding PSP senden (Requesting-Seite)
  • Eingehende VoP-Requests entgegennehmen, validieren und Responses erzeugen (Responding-Seite)
  • Die drei Use Cases unterstützen: Name+IBAN, Identification Code+IBAN und Name+Additional Attribute+IBAN
  • Mutual TLS mit QWAC-Zertifikaten nach Richtlinie (EU) 2015/2366 (PSD2), profiliert in ETSI TS 119 495, für die Absicherung der Inter-PSP-Kommunikation implementieren

4. Latenz und Verfügbarkeit

Die EPC-Vorgabe von maximal 5 Sekunden End-to-End ist anspruchsvoll. Das schließt Netzwerklatenz, Routing, Name Matching und die Antwort ein. In der Praxis bedeutet das:

  • Die Name Matching Engine muss in unter 100 Millisekunden antworten
  • EDS-Daten im In-Memory-Cache: Die Routing-Informationen aus dem EPC Directory Service müssen für Sub-Millisekunden-Zugriff im Arbeitsspeicher liegen. Eine Datenbankabfrage pro Request ist zu langsam. In der Praxis bewährt sich eine Architektur mit Redis als Cache vor einer relationalen Datenbank als System of Record
  • Connection Pooling für ausgehende API-Aufrufe an die Endpunkte der Empfängerbanken
  • Fallback-Strategien für Timeouts müssen implementiert sein, sowohl für den EDS-Cache als auch für die externen API-Aufrufe
  • Die Verfügbarkeit muss 24/7 gewährleistet sein, Instant Payments kennen keine Geschäftszeiten

5. Monitoring und Compliance

  • Echtzeit-Monitoring der VoP-Erfolgsraten, Latenz und Fehlerquoten
  • Audit-Logging aller Requests und Responses mit Zeitstempel
  • Reporting an die zuständige Aufsichtsbehörde (BaFin in Deutschland)
  • Statistiken über Match-Raten zur Kalibrierung der Schwellenwerte

Herausforderungen in der Praxis

Datenqualität der Kontostammdaten

Das schwächste Glied der Kette ist oft nicht der Algorithmus, sondern die Datengrundlage. Viele Banken haben historisch gewachsene Kontostammdaten mit:

  • Inkonsistenten Schreibweisen (Groß-/Kleinschreibung, Umlaute vs. Umschreibung)
  • Veralteten Namen (Namensänderungen nach Heirat oder Scheidung)
  • Abkürzungen bei Firmennamen (“GmbH” vs. “Gesellschaft mit beschränkter Haftung”)
  • Fehlenden oder falschen Einträgen bei Gemeinschaftskonten

Ohne eine Bereinigung der Stammdaten wird die False-Positive-Rate unangenehm hoch: Kunden erhalten unnötige Warnungen, das Vertrauen in das System sinkt.

Multi-Scheme-Fähigkeit

VoP gilt aus IPR Artikel 5c ab Tag eins für SCT und SCT Inst gleichzeitig. Die Architektur muss beide Schemes parallel bedienen, mit unterschiedlichen Latenzanforderungen (SCT Inst: harte Sekundenfristen für Echtzeitüberweisungen; SCT: weniger zeitkritisch, aber typischerweise höheres Volumen) und einer gemeinsamen Inter-PSP-API.

Grenzüberschreitende Prüfungen

Innerhalb Deutschlands sind Routing und Namenskonventionen vergleichsweise einheitlich. Bei grenzüberschreitenden Überweisungen kommen hinzu:

  • Unterschiedliche Zeichensätze und Transliteration
  • Abweichende Namenskonventionen (Reihenfolge Vor-/Nachname, patronymische Namen)
  • Verschiedene Rechtsformen für Firmennamen
  • Latenz durch internationale Routing-Hops

Was passiert bei Nicht-Einhaltung?

Die IPR ist eine EU-Verordnung, keine Richtlinie, und gilt damit unmittelbar in allen Mitgliedstaaten. Eurozone-Zahlungsdienstleister, die ab dem 9. Oktober 2025 keine VoP-Prüfung anbieten, verstoßen gegen geltendes Recht. Die Konsequenzen:

  • Aufsichtsrechtliche Maßnahmen durch die nationale Aufsichtsbehörde
  • Bußgelder gemäß den nationalen Sanktionsrahmen
  • Haftungsrisiken gegenüber Kunden, die durch fehlende Prüfung geschädigt werden
  • Reputationsschaden in einem zunehmend sicherheitsbewussten Markt

Unsere VoP-Erfahrung

Wir kennen VoP von beiden Seiten. Beim Bank-Verlag haben wir ein VoP-System auf Basis der VoP-Komponente von msg for banking aufgebaut: von der EDS-Integration über Datenmigration und Security-Setup bis zur Anbindung an die bestehende Zahlungsverkehrsinfrastruktur.

Parallel dazu haben wir ein eigenes VoP-System entwickelt, dass als Whitelabel-Produkt zur Lizenzierung bereitsteht und in den folgenden Phasen aktiv weiterentwickelt wird. Es deckt den gesamten VoP-Prozess ab: EPC Directory Service, Name Matching Engine, Inter-PSP REST API und Echtzeit-Monitoring.

Die Erfahrung aus beiden Projekten fließt direkt in die technischen Einschätzungen dieses Artikels: Die Herausforderungen sind real, die Fristen knapp, aber mit der richtigen Architektur und sauberer Datengrundlage ist VoP technisch beherrschbar.

Fazit

Der Stichtag ist kein weiches Ziel. Wer VoP nicht rechtzeitig produktionsreif hat, verstößt gegen die IPR und riskiert aufsichtsrechtliche Konsequenzen. Die technischen Anforderungen (Name Matching, Latenz, Inter-PSP API, Mutual TLS, EDS-Routing, Monitoring) sind anspruchsvoll, aber lösbar. Der größte Hebel liegt in der Datenqualität: Ein perfekter Algorithmus nützt wenig, wenn die Kontostammdaten nicht stimmen.

Für alle, die tiefer einsteigen wollen: Unser Artikel Verification of Payee: was sich im Zahlungsverkehr ändert beschreibt die technischen Grundlagen im Detail. Die ISO 20022 Migration behandelt die Nachrichtenformate, die auch VoP zugrunde liegen.