Seit Oktober 2025 muss ein PSP im Euroraum, der eine Überweisung ausführt, zuerst prüfen, ob der vom Zahler angegebene Begünstigtenname zum Namen auf dem Konto hinter der IBAN passt. Das Verification-of-Payee-Scheme-Rulebook des EPC trat am 5. Oktober 2025 in Kraft, die rechtliche Pflicht unter der Instant Payments Regulation folgte am 9. Oktober 2025 für PSPs im Euroraum, während EU-PSPs außerhalb des Euroraums bis zum 9. Juli 2027 Zeit haben. Der Rollout war durch drei Beitrittswellen und eine Test- und Selbstzertifizierungsplattform des EPC abgefedert, aber die Betriebsrealität steht nun: ein Inter-PSP-API-Roundtrip, je Zahlung, vor der Autorisierung.
Die Regulierung liest sich wie ein simpler Verbraucherschutz. Das Engineering darunter ist alles andere als simpel, und die Unternehmen auf der Sendeseite von Sammelzahlungsdateien entdecken, dass VoP im Stillen ein Stammdatenprogramm ist, das ein Betrugskontroll-Abzeichen trägt.
Großbritannien hat dieses Experiment zuerst durchgeführt. Confirmation of Payee kam dort 2019 als heimische Marktinitiative, und die Lehre daraus ist zweischneidig: Der Namensabgleich reduziert fehlgeleitete und Scam-Zahlungen tatsächlich, und er erzeugt echte Reibung, wo Namen abgekürzt sind, Handelsnamen von juristischen Namen abweichen oder Kontodaten dem widersprechen, was der Zahler erwartet. Die EU-Version erbt beide Hälften, im Maßstab von sechsunddreißig Ländern, eingebettet in eine bindende Verordnung statt in eine Marktinfrastruktur.
Die Matching-Engine ist das Produkt
Die naive Lesart von VoP ist String-Gleichheit zwischen der Eingabe des Zahlers und dem Kontoinhaber-Datensatz. Kein Produktionssystem kann so arbeiten. “Muller GmbH” gegen “Müller Gesellschaft mit beschränkter Haftung”, “J. van der Berg” gegen “Johannes van der Berg”, ein transliterierter Name gegen seine Originalschrift: Der exakte Vergleich scheitert an all dem, und jeder falsche No-Match ist eine blockierte legitime Zahlung und ein Zahler, der lernt, den Warnungen zu misstrauen.
Die Matching-Schicht muss normalisieren, bevor sie vergleicht: Groß- und Kleinschreibung, Interpunktion, Leerzeichen, Diakritika, Rechtsform-Suffixe und ihre Abkürzungen, gebräuchliche Kurzformen von Vornamen und lokale Konventionen der Namensreihenfolge. Dann muss sie das Ergebnis in die Antwortsemantik des Schemes einordnen, Match, Close Match, No Match oder Unavailable, wobei das Close-Match-Band den beim Responder hinterlegten Begünstigtennamen mitführt, damit der Zahler sehen kann, was der Datensatz tatsächlich sagt.
Die Kalibrierung dieses Close-Match-Bandes ist der Ort, an dem Betrugs- und Konversionsergebnisse direkt gegeneinander stehen. Zu streng, und legitime Zahlungen scheitern oder laufen in die manuelle Prüfung, bis Nutzer gewohnheitsmäßig übersteuern. Zu locker, und der Lookalike-Namensbetrug, für dessen Abfangen das Scheme existiert, segelt als Close Match durch, den niemand liest. Diese Schwelle verdient dieselbe Behandlung wie jedes Risikomodell: gemessene False-Positive- und False-Negative-Raten, versionierte Änderungen und periodische Überprüfung gegen Override- und Betrugsergebnisse, kein einmaliger Anbieter-Default.
Interoperabilität fügt ein Problem zweiter Ordnung hinzu. Das Scheme läuft auf gemeinsamen EPC-API-Spezifikationen, und das EPC hat seine API Reference Toolbox und die Zertifizierungswerkzeuge genau gebaut, um Divergenz zu reduzieren, aber antwortende PSPs unterscheiden sich weiterhin in der Matching-Qualität. Derselbe Begünstigte kann bei einer Bank einen Match erzielen und bei einer anderen einen Close Match. Sender sollten diese Inkonsistenz erwarten und dafür instrumentieren, statt jeden Close Match als gleich bedeutsam zu behandeln.
Unternehmen: das Sammeldatei-Problem
Für Treasury- und AP-Teams existiert der Verbraucherfluss, eine Warnung auf einem Bildschirm und eine Entscheidung fortzufahren, nicht. Zahlungen verlassen das Haus über ERP-Batches, Host-to-Host-Kanäle, EBICS und SEPA-Dateien, Tausende Posten auf einmal. Machine-to-Machine-Verarbeitung der VoP-Ergebnisse ist die Anforderung, und die Verordnung erkennt das Missverhältnis an: Nicht-Verbraucher-Zahler dürfen auf den Service verzichten und dürfen wieder zurück optieren.
Dieser Waiver ist ein Policy-Instrument, und sein vernünftiger Einsatz ist Segmentierung statt pauschaler Abschaltung. Die Verifizierung bleibt verpflichtend, wo sich das Betrugsrisiko konzentriert: Erstbegünstigte, geänderte Bankverbindungen nach dem Lieferanten-Onboarding, hochwertige Überweisungen. Routinemäßige, hochvolumige Auszahlungen an langjährige Gegenparteien können unter Waiver laufen. Die exakte Mechanik für Sammeldateien, Verifizierung je Posten, Validierung vor der Einreichung oder nachgelagerter Exception-Workflow, ist eine Design-Entscheidung, die jedes Unternehmen mit seinen PSPs treffen muss; die Scheme-Dokumentation reicht kein kanonisches Muster, man behandelt es also als Architekturwahl mit Konsequenzen für Betrug, Konversion und Cut-off-Zeiten.
Die tiefere unternehmerische Exponierung ist Datenqualität. Ein Lieferant, dessen juristischer Name im ERP-Vendor-Master, im TMS und im lokalen System einer Tochtergesellschaft auf drei verschiedene Arten gespeichert ist, erzeugt Mismatches bei völlig legitimen Zahlungen. VoP auditiert die Begünstigten-Stammdaten faktisch bei jedem Lauf, in Produktion, mit Zahlungsverzögerungen als Fehlerbericht. Die Unternehmen, die vor Oktober 2025 in die Bereinigung des Vendor Masters investiert hatten, erlebten den Rollout als Nicht-Ereignis; die anderen machen die Bereinigung jetzt unter operativem Druck, was der teure Weg ist.
Was es gegen Betrug leistet, und was nicht
Die Ökonomie des Schemes zielt auf Authorised Push Payment Fraud und Rechnungsumleitung: Angriffe, die darauf beruhen, einen Zahler zu überreden, Geld unter einem plausiblen Namen an ein vom Angreifer kontrolliertes Konto zu senden. Den Namen vor der Ausführung gegen das Konto zu prüfen greift diese Abhängigkeit direkt an und verwandelt eine Betrugsklasse, die bisher bis zum Rückrufversuch unsichtbar war, in eine Warnung vor der Zahlung.
Ehrlichkeit über die Grenzen ist wichtig für alle, die die umgebenden Kontrollen entwerfen. VoP hilft nicht, wenn der Kriminelle ein Konto kontrolliert, dessen registrierter Name zur imitierten Identität passt, wenn der eigene Kanal eines legitimen Lieferanten kompromittiert ist und die “neuen” Kontodaten mit einem Namen kommen, der verifiziert, oder wenn ein Zahler die Warnung übersteuert, weil der Vorwand gut genug war. Social Engineering passt sich an; die Skripte coachen Opfer bereits durch das Wegklicken von Mismatch-Warnungen. Der Namensabgleich ist eine Schicht, und er wirkt am besten, wenn er die Schichten um ihn herum speist: verhaltensbasiertes Fraud Scoring auf der Zahlung selbst, Risikosignale zum Begünstigtenkonto und Kontrollen für Bankverbindungsänderungen im Lieferanten-Onboarding.
Der Betrieb: Telemetrie, Overrides und der Audit Trail
Behandeln Sie VoP-Antworten als operativen Datenstrom, nicht als Urteil je Zahlung, das man verwirft. Drei Praktiken trennen ein funktionierendes Deployment von einer Compliance-Checkbox.
- Alles loggen, wortgetreu. Anfrage, Antwort, zurückgegebener Name, wo vorhanden, die dem Nutzer gezeigte Meldung oder die vom Batch-Workflow angewandte Disposition, und jeder Override mit seinem Urheber. Dieses Protokoll ist es, was eine Betrugsermittlung, ein Haftungsstreit oder eine Aufsichtsbehörde verlangen wird.
- Den Antwortmix beobachten. Match-Quote je Gegenpartei, Close-Match-Cluster, Unavailable-Quoten je antwortendem PSP. Verschiebungen in diesen Verteilungen machen Stammdatenverfall, Änderungen an der Matching-Engine auf Responder-Seite und aufkommende Betrugsmuster früher sichtbar als Verlustdaten.
- Die Schleife in die Stammdaten schließen. Jeder aufgelöste Mismatch sollte mit einer Korrektur im System of Record enden, damit derselbe Lieferant im nächsten Zyklus nicht dieselbe Warnung auslöst. Der anzustrebende stationäre Zustand ist eine First-Attempt-Match-Quote, die hoch genug ist, dass die verbleibenden Warnungen selten sind, gelesen werden und ernst genommen werden, denn eine Warnung, die Nutzer zehnmal am Tag sehen, schützt niemanden.
Häufige Fragen
Sollte ein Unternehmen den Waiver nutzen und VoP für Sammelzahlungen abschalten?
Der pauschale Waiver ist die bequeme Antwort und die falsche. Der Waiver existiert, weil Prompts im Verbraucherstil nicht zu Batch-Flüssen passen, nicht weil das Risiko verschwindet. Das Muster, das wir empfehlen, ist Segmentierung: Verifizierung bleibt verpflichtend für Erstbegünstigte, geänderte Bankverbindungen und hochwertige oder risikoreiche Zahlungen, und wird nur für Routineauszahlungen an langjährige, zuvor verifizierte Gegenparteien ausgesetzt, mit dokumentierter und regelmäßig überprüfter Policy.
Wer haftet, wenn eine Close-Match-Warnung übersteuert wird und die Zahlung sich als Betrug herausstellt?
Unter dem Regime trägt ein Zahler, der nach einer Warnung fortfährt, in der Regel die Konsequenz, und genau deshalb verdient das Override-Handling Design-Aufmerksamkeit. Loggen Sie jede Antwort, die exakt angezeigte Meldung, wer übersteuert hat und mit welcher Begründung. Im Unternehmenskontext sollten Close-Match-Overrides bei neuen oder geänderten Begünstigten an einen zweiten Genehmiger laufen. Der Audit Trail ist zugleich das Betrugsermittlungsprotokoll und der Nachweis, dass die Kontrolle funktioniert hat.
Speisen die VoP-Antwortcodes etwas jenseits der Zahlungsentscheidung?
Das sollten sie. Ein No-Match bei einem langjährigen Lieferanten ist ein Stammdatendefekt, der an der Quelle behoben gehört. Ein Close-Match-Cluster gegen ein Begünstigtenkonto von mehreren Zahlern ist ein Betrugssignal, das eskaliert gehört. Wiederholte Unavailable-Antworten eines antwortenden PSP sind ein operatives Abhängigkeitsthema für die Gespräche mit der Bank. Als Telemetrie statt als Schranke behandelt, verbessern VoP-Ergebnisse Datenqualität, Betrugserkennung und Lieferantenmanagement.