Der Stichtag: 5. Oktober 2025

Am 5. Oktober 2025 tritt die Pflicht zur Empfängernamensprüfung im europäischen Zahlungsverkehr in Kraft. Verification of Payee (VoP) wird ab diesem Datum für alle Zahlungsdienstleister verbindlich, die SEPA Instant Credit Transfers anbieten. Es ist kein Pilotprojekt mehr, keine freiwillige Teilnahme — es ist regulatorisches Pflichtprogramm.

Die Grundlage bildet die EU Instant Payment Regulation (IPR), veröffentlicht als Verordnung (EU) 2024/886. Sie verpflichtet alle Zahlungsdienstleister im Europäischen Wirtschaftsraum (EWR), sowohl als anfragende als auch als empfangende Seite VoP zu unterstützen.

Was sich am 5. Oktober konkret ändert

Ab dem Stichtag muss jede Echtzeitüberweisung im SEPA-Raum 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
  • 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: 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 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 PSD2 (ETSI 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 zunächst für Instant Payments (SCT Inst). Die Ausweitung auf reguläre SEPA-Überweisungen (SCT) ist absehbar. Das System muss von Anfang an so gebaut werden, dass es beide Schemes bedienen kann, ohne grundlegende Architekturänderungen.

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 — sie gilt unmittelbar in allen Mitgliedstaaten. Zahlungsdienstleister, die am 5. 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 5. Oktober 2025 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.