Verification of Payee, was sich im Zahlungsverkehr ändert

Das Problem: Betrug im Zahlungsverkehr

Überweisungsbetrug ist ein wachsendes Problem im europäischen Zahlungsverkehr. Social Engineering, gefälschte Rechnungen, manipulierte IBANs, die Methoden sind vielfältig, der Schaden erheblich. Die EU-Verordnung zur Instant Payment Regulation (IPR) schreibt deshalb ab Oktober 2025 eine Empfängernamensprüfung vor: Verification of Payee (VoP).

Das Prinzip ist einfach: Bevor eine Überweisung ausgeführt wird, prüft die Bank des Auftraggebers, ob der angegebene Empfängername zur Ziel-IBAN passt. Stimmt der Name nicht überein, erhält der Auftraggeber einen Warnhinweis. Klingt simpel, die technische Umsetzung ist es nicht.

Wie VoP funktioniert

Der VoP-Prozess folgt einem Request/Response-Pattern zwischen zwei Zahlungsdienstleistern (PSPs):

1. Initiierung, Der Auftraggeber gibt IBAN, Name und Betrag ein
2. VoP Request, Der Requesting PSP sendet eine Prüfanfrage per REST API an den Responding PSP
3. Name Matching, Der Responding PSP vergleicht den übermittelten Namen mit dem hinterlegten Kontoinhaber
4. VoP Response, Das Ergebnis wird als HTTP 200 zurückgemeldet: Match (MTCH), Close Match (CMTC), No Match (NMTC) oder Not Applicable (NOAP)
5. Nutzerinteraktion, Bei NMTC oder CMTC erhält der Auftraggeber einen Warnhinweis und kann die Überweisung bestätigen oder abbrechen

Die vier Ergebniscodes

Code	Ergebnis	Bedeutung	Aktion
MTCH	Match	Name stimmt überein	Überweisung wird fortgesetzt
CMTC	Close Match	Name ähnlich, aber nicht exakt	Warnung mit Vorschlag des korrekten Namens
NMTC	No Match	Name stimmt nicht überein	Warnung, Nutzer muss aktiv bestätigen
NOAP	Not Applicable	Prüfung nicht anwendbar	Hinweis, Überweisung kann fortgesetzt werden

Der EPC-Standard

Der European Payments Council (EPC) hat den VoP-Standard definiert: das EPC scheme “Verification of Payee” basierend auf dem SEPA-Regelwerk. Die Kommunikation zwischen 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 ausgetauscht.

API und Use Cases

Die VoP API unterstützt drei Use Cases:

• Name/IBAN Check, Empfängername und IBAN werden geprüft (natürliche und juristische Personen)
• Identification Code/IBAN Check, LEI oder Umsatzsteuer-ID und IBAN werden geprüft (juristische Personen)
• Name + Additional Attribute/IBAN Check, Zusätzliche Attribute (z.B. C007) für E-Geld-Institute

Anders als bei SEPA-Überweisungen laufen VoP-Requests nicht über die Clearing-Infrastruktur, sondern werden direkt zwischen den PSPs ausgetauscht. Die Absicherung erfolgt über Mutual TLS mit QWAC-Zertifikaten nach PSD2 (ETSI 119 495).

Das Routing erfolgt über den EPC Directory Service (EDS) — ein täglich aktualisiertes Verzeichnis aller VoP-Teilnehmer, das pro Account-Holding BIC den zugehörigen API-Endpunkt bereitstellt.

Name Matching, die technische Herausforderung

Der scheinbar einfache Vergleich zweier Namen ist der technisch anspruchsvollste Teil des Systems. In der Praxis gibt es zahlreiche Szenarien, die einen exakten String-Vergleich unmöglich machen:

• Umlaute und Sonderzeichen, “Müller” vs. “Mueller” vs. “MUELLER”
• Namenszusätze, “Dr. Max Mustermann” vs. “Max Mustermann”
• Firmenbezeichnungen, “rypox GmbH” vs. “Rypox Gesellschaft mit beschränkter Haftung”
• Reihenfolge, “Mustermann, Max” vs. “Max Mustermann”
• Transliteration, Nicht-lateinische Zeichen in lateinische Schrift
• Gemeinschaftskonten, Mehrere Kontoinhaber für eine IBAN

Matching-Algorithmus

Ein robuster Matching-Algorithmus kombiniert mehrere Techniken:

• Normalisierung, Lowercase, Entfernung von Sonderzeichen und Titeln, Standardisierung von Rechtsformen
• Phonetische Ähnlichkeit, Kölner Phonetik oder Double Metaphone für die Erkennung klangähnlicher Namen
• Edit-Distance, Levenshtein-Distanz als Maß für Tippfehler
• Token-basierter Vergleich, Aufteilung in Namensteile und Vergleich der einzelnen Tokens

Die Konfiguration der Schwellwerte ist entscheidend: Zu streng führt zu vielen False Negatives (No Match bei korrektem Empfänger), zu lax lässt betrügerische Überweisungen durch. Die EPC-Spezifikation gibt hier Empfehlungen, aber die konkrete Kalibrierung liegt beim jeweiligen PSP.

Integration in bestehende Systeme

VoP ist kein isoliertes System. Es muss in die bestehende Zahlungsverkehrsinfrastruktur integriert werden:

Requesting PSP (anfragende Seite)

• Integration in Online-Banking und Banking-Apps
• VoP-Prüfung vor Auftragserteilung
• Routing über den EDS: Aus der Empfänger-IBAN den Account-Holding BIC ableiten und den zugehörigen API-Endpunkt im EDS-Cache nachschlagen
• Darstellung der Ergebnisse im UI
• Handling von Timeouts (die Maximum Execution Time ist im VoP Scheme Rulebook definiert)

Responding PSP (empfangende Seite)

• Bereitstellung eines VoP-API-Endpunkts, registriert im EDS
• Autorisierung eingehender Requests: Prüfung, ob der anfragende BIC im EDS als Teilnehmer geführt wird und ob die angefragte National Account Number (NAN) in dessen Zuständigkeit liegt
• Zugriff auf Kontostammdaten für den Namensvergleich
• Name Matching Engine
• Logging und Audit für regulatorische Anforderungen

Latenzanforderungen

Die gesamte VoP-Prüfung, vom Request des Nutzers bis zur Anzeige des Ergebnisses, muss innerhalb weniger Sekunden erfolgen. Das hat direkte Auswirkungen auf die Architektur:

• Synchrone Verarbeitung für einzelne VoP-Requests
• EDS-Daten im In-Memory-Cache, Das EPC Directory wird täglich aktualisiert. Für Echtzeit-Lookups müssen BIC-zu-URI-Mappings und Teilnehmerlisten im Arbeitsspeicher liegen (z.B. in Redis), nicht bei jedem Request aus einer Datenbank gelesen werden
• Connection Pooling, Persistente HTTP-Verbindungen zu den API-Endpunkten der Empfängerbanken
• Monitoring, Latenz-Metriken pro VoP-Request und Verfügbarkeit der Endpunkte

Auswirkungen auf Banken und PSPs

VoP ist regulatorisch verpflichtend. Das bedeutet:

• Alle SEPA-Teilnehmer müssen VoP als Responding PSP unterstützen
• Alle PSPs, die Überweisungen initiieren, müssen VoP-Requests senden
• Instant Payments erfordern VoP ab Oktober 2025
• SCT (SEPA Credit Transfer) folgt in einer späteren Phase

Für Banken bedeutet das Investitionen in neue Systeme und die Anpassung bestehender Prozesse. Für Fintechs und Payment Service Provider eröffnen sich neue Möglichkeiten, als VoP-Anbieter oder als Integrator.

Fazit

Verification of Payee ist eine der bedeutendsten Veränderungen im europäischen Zahlungsverkehr der letzten Jahre. Technisch anspruchsvoll, regulatorisch getrieben und mit klaren Fristen versehen. Die Herausforderung liegt in der Kombination aus exaktem Name Matching, strikten Latenzanforderungen und der Integration in gewachsene Zahlungsverkehrsinfrastrukturen. Wer früh anfängt, hat den Vorteil, die Architektur sauber aufsetzen zu können, statt sie unter Zeitdruck zusammenzubauen.