Verification of Payee: Sicher, schnell, verpflichtend – Die Chancen der Regulatorik und eine Antwort

In einer Zeit, in der alles schnelllebiger wird – von der Onlinebestellung, der Kommunikation bis hin zum Informationsaustausch –, läuft nun auch der Zahlungsverkehr auf Höchstgeschwindigkeit.

Mit der Einführung von Instant Payment wurde es dem europäischen Zahlungsverkehr ermöglicht, Zahlungen innerhalb von Sekunden von A nach B zu transferieren. Dies spart nicht nur Zeit, es macht den gesamten Zahlungsprozess auch effizienter. Allerdings kann dies bei Fehlern oder Betrugsversuchen zu Problemen führen, da die Transaktionen mit kurzen Umsetzungszeiträumen final sind und daher nicht rückgängig gemacht werden können.

Um diesen Problemen entgegenzuwirken, wurde der Verification- of-Payee(VoP)-Mechanismus entwickelt. Der Algorithmus überprüft die Identität des Empfängers einer Zahlung und stellt sicher, dass eine Transaktion bei der richtigen Person beziehungsweise Organisation ankommt. Dies ist insbesondere für Transaktionen relevant, bei denen der Absender den Empfänger nicht kennt oder ein Betrugsverdacht besteht.

Regulatorisch ist der Mechanismus in der Instant-Payments-Verordnung der EU verankert, die die Verification of Payee zum 5. Oktober 2025 für alle Finanzinstitute zur Pflicht werden lässt. Ab diesem Datum müssen Banken den Service rund um die Uhr über alle Kundenkanäle zur Verfügung stellen. Der Überprüfungsprozess darf hierbei maximal fünf Sekunden dauern, wobei eine Dauer von einer Sekunde angestrebt wird.

Traditionelle Banksysteme sind häufig nicht in der Lage, solche Verifizierungen in Echtzeit durchzuführen, da sie nicht 24/7 verfügbar sind oder über die notwendigen Rechenkapazitäten verfügen. Aus diesem Grund empfiehlt es sich, den VoP-Service außerhalb des Zahlungsverkehrs zu platzieren.

Umsetzung der Regulatorik – wieder einmal die klassische Make-or-Buy-Frage

Für die Finanzinstitute stellt sich neben der Platzierung des VoP-Services in ihrer Systemlandschaft nun vor allem die klassische Make-or-Buy-Frage: Die regulatorische Pflicht ab Oktober 2025 rückt näher, daher ist eine zeitnahe Entscheidung geboten. Entwickelt die Bank eine eigene Lösung oder entscheidet sie sich für eine Lösung «aus dem Regal»? Installiert die Bank die Lösung On-Premise oder wählt sie eine Software- as-a-Service-Distribution?

Eine mögliche Antwort bietet die von msg for banking in Kooperation mit dem Bank-Verlag angebotene Lösung BV VoP – powered by msg. Dieser Service, als SaaS-Lösung betrieben, bietet eine einfache All-in-One-Lösung, die das einschlägige Anforderungsspektrum der EU-Regulatorik abdeckt und verschiedenste (je nach Bedarf) Anbindungsmöglichkeiten bereithält.

Der Service agiert als ein sogenannter „Routing und Verification Mechanismus“ (RVM). Wie in Abbildung 1 ersichtlich, tritt hierbei der RVM als Vermittler zwischen dem Sender einer Anfrage (Request) und dem zu identifizierenden Zahlungsempfänger auf. Das bedeutet, dass der Service neben der Überprüfung des Empfängers auch das korrekte Routing der Anfrage übernimmt. Diese Routingfunktion sorgt dafür, dass auf Basis des sogenannten EDS (EPC-Directory-Services) alle Empfänger in den 36 SEPA-Ländern über eine Standardschnittstelle für eine Abfrage der Empfängerdaten erreichbar sind. Das EDS ist somit eine Art Telefonbuch, in dem jedes teilnehmende Institut mit seinen Erreichbarkeitsvariablen und an- gebotenen Services zu finden ist. Damit stellt der EDS-Service die Verbindung zu jedem Institut der Teilnehmerländer her.

Das Tool nimmt den eingehenden Request entgegen und prüft, ob die Bank des Empfängers entweder auch Teil unseres Services ist (in diesem Fall würde die Anfrage intern verarbeitet werden) oder ob die Anfrage (wie Abbildung 2 zeigt) an einen anderen, für diese Empfängerbank spezifischen RVM weitergeleitet werden muss.

Der Vorteil dieses Ansatzes ist, dass im Fall einer internen Verarbeitung (bei der die Empfängerbank auch an den Service angeschlossen ist) effektiv Geld und Zeit gespart wird, da keine externe Partei hinzugezogen werden muss, die eventuell Extrakosten veranschlagt. Hieraus lässt sich ein klassischer Netzwerkeffekt herstellen, denn je mehr Banken sich an den Service anbinden, desto günstiger wird es für alle.

Bei der Weiterleitung orientiert sich der Service anhand des vom EPC bereitgestellten Directory, in dem jede Bank mit ihrem RVM hinterlegt ist. Dieses Directory wird täglich aktualisiert und in den Service importiert.

Die IBAN-Namensprüfung und ihr Algorithmus

Das Herzstück der Anwendung bildet der Algorithmus zur IBAN-Namensprüfung. Der Algorithmus vergleicht jede eingehende Anfrage sowohl von extern (passiv) wie auch von einem angebundenen Institut (aktiv) mit den in den Stammdaten hinterlegten Datensätzen.

Um zu verstehen, wie der zentrale Algorithmus funktioniert, sodass er selbst bei schlechter Stammdatenlage ein verlässliches Ergebnis liefern kann, lohnt es sich, einen genaueren Blick auf ihn zu werfen.

Kernstück ist die phonetische Distanzmessung nach Levenshtein (Levenshtein-Distanz). Diese beschreibt die minimale Anzahl von Änderungen, die nötig sind, um aus der ersten Zeichenkette (Request) die zweite Zeichenkette (hinterlegter Name in den Stammdaten) zu generieren. Änderungsmodi sind dabei das Hinzufügen, Entfernen und Austauschen von Zeichen. Sie ist benannt nach dem russischen Mathematiker Vladimir Levenshtein (1935 bis 2017).

Eine Distanz von 0 ist somit ein eindeutiges Match. Dies bedeutet, dass der Name im Request (zum Beispiel Max Mustermann) mit dem Namen im Datensatz genau übereinstimmt. Eine Distanz von 1 ist gegeben, wenn eine Abweichung von einem Zeichen (zum Beispiel Ma Mustermann oder Max Lustermann) im Request angeliefert wurde.

Dieses einfache Beispiel zeigt sehr gut, wie viele Möglichkeiten der Abweichung es für ein und denselben Namen gibt. Doch was passiert, wenn der Name in einer falschen Reihenfolge angeliefert wird oder zum Beispiel noch der Zweitname hinzugefügt wurde (zum Beispiel Mustermann Max Frank)? Würde man hier nach der reinen Levenshtein-Distanz gehen, würde dies zu einem negativen Ergebnis (No Match) führen, da in den Stammdaten nur der Name (Max Mustermann) hinterlegt ist.

Um dieses Problem zu lösen, wurde der Algorithmus erweitert. Die Anfragen durchlaufen dabei zwei Prüfprozesse:

1. Zuerst wird der angelieferte Request anhand seiner IBAN in den Stammdaten gesucht und überprüft, ob der Name des Requests direkt zu dem in den Stammdaten hinterlegten Namen passt. Wenn dies zutrifft, wird hier das Ergebnis (Match) direkt zurückgeleitet.
2. Sollte dies nicht der Fall sein, performt der Algorithmus verschiedene Permutationen des Namens. Er ändert zum Beispiel die Reihenfolge der Namen oder löscht einzelne Namen, um möglichst genau – auch bei schlechter Datenlage der zur Verfügung stehenden Stammdaten – ein Close Match mit entsprechendem richtigen Namen aus der Datenbank zurückzuliefern. Diese Operation dauert, je nach Länge des Namens, maximal eine Sekunde.

Neben diesem Algorithmus stehen außerdem verschiedene GUIs (Graphical User Interface) zur Verfügung, in der zum Beispiel auch manuell Aliasse in unbegrenzter Anzahl für einen Datensatz erfasst werden können, um die Überprüfung noch genauer zu machen.

Die folgende Grafik zeigt am Beispiel Mobile Banking vier Möglichkeiten zur Rückmeldung in Bezug auf die durchgeführte Prüfung.

Für die Prüfung der Stammdaten in der Anwendung bietet unsere Lösung zwei Möglichkeiten, die durch die offene Gestaltung auch die Anbindung weiterer (Verbund-)Partner ermöglicht:

1. Das Importieren der Stammdaten über eine bereitgestellte API: Sie sorgt dafür, dass mithilfe von nachgelagerten Prozessen stets die aktuellen Stammdaten in den Service geladen werden. So kann nicht nur der initiale Upload performant gestaltet, sondern können auch Änderungen in den Stammdaten live in der Anwendung angepasst werden.
2. Eine Realtime-API, bei der die entsprechende IBAN, die durch den Request mitgeteilt wird, an die Datenbank der Empfängerbank gesendet wird. Diese sendet als Rückmeldung den bei der Empfängerbank hinterlegten Datensatz, woraufhin der oben beschriebene Algorithmus die IBAN- Namensprüfung durchführt.

Eine weitere Besonderheit ist, dass neben der (sich nach dem EPC-Standard richtenden und leicht anzubindenden) JSON-API-Schnittstelle für Einzelanfragen, die meist aus dem Retailbereich erwartet werden, auch eine Bulkschnittstelle angeboten wird, die vor allem für Corporate-Kunden interessant ist. Die Bulkschnittstelle ist in der Lage, eine Vielzahl von Anfragen in einer Batchdatei, zum Beispiel aus EBICS oder FinTS, zu verarbeiten. Der Service nimmt die Zahlungsverkehrsdatei pain.001 unverändert an, übernimmt im Service die Vereinzelung der Anfragen und stellt der Senderbank die entsprechenden Rückmeldungen im regulatorisch geforderten pain.002-Format an der Schnittstelle zum Download zur Verfügung. Von da übernimmt die Senderbank die Überführung in die Clearinginfrastruktur in Abstimmung mit dem sendenden Corporate.

Die Regulatorik als Chance: Value Added Services

Neben diesem Gesamtpaket bietet unsere Lösung den Banken auch die Möglichkeit, Value-Added-Services (VAS) wie Alarmsysteme und erweiterte Analysetools zu integrieren. Diese Dienste helfen, verdächtige Aktivitäten frühzeitig zu erkennen und schnell darauf zu reagieren. Das macht den Service zu einem wertvollen Werkzeug zur Optimierung des Fraud-/Risikomanagements und stärkt in der Folge auch die Kundenbeziehung durch das vermittelte Sicherheitsgefühl.

Im Detail können Banken beispielsweise erkennen, welche IBANs am häufigsten abgefragt werden und in welchen Fällen es die meisten Übereinstimmungen oder Abweichungen gibt. Durch anpassbares Alerting werden ungewöhnliche Aktivitäten erkannt und können von weiteren unbefugten Zugriffsversuchen ausgeschlossen werden. Die individuelle Konfiguration von zusätzlichen Identifikationsmerkmalen hilft dabei, die Zahl möglicher Close Matches und falscher No Matches zu reduzieren. In beiden Fällen wird der Kunde froh sein, sein Geld zu erhalten beziehungsweise es nicht erneut schicken zu müssen, weil ein Name in den Stammdaten des Empfängers nicht eindeutig hinterlegt ist. Das steigert die Kundenzufriedenheit und erhöht zudem die STP-Rate (Straight-Through-Processing-Rate) erheblich.

Durch die Möglichkeit, Geschäftsregeln individuell anzupassen, werden einzelne Bewertungskriterien zusätzlich gewichtet, und der Kunde kann so zum Beispiel lokale Kriterien besser berücksichtigen und dadurch ebenso die Durchlaufquote an die jeweiligen Gegebenheiten individuell anpassen.

Fazit: Verification of Payee ist gekommen, um zu bleiben

Verification of Payee (VoP) bietet eine wichtige und nachhaltige Antwort auf die Herausforderungen, die mit Instant Payments einhergehen – insbesondere hinsichtlich Betrugsprävention und möglicher Fehlüberweisungen. Durch die schnelle und verlässliche Überprüfung des Zahlungsempfängers wird sichergestellt, dass Transaktionen korrekt abgewickelt werden. Das ist besonders in Fällen von Betrugsverdacht oder Unsicherheit über den Empfänger entscheidend.

Unsere in Kooperation mit dem Bank-Verlag entwickelten Services bieten eine umfassende Lösung, die sowohl die EU-Regulatorik erfüllt als auch flexibel angepasst werden kann und zusätzliche Mehrwertdienste wie Alarmsysteme und Analysetools anbietet. Der effiziente und präzise Abgleich von Empfängerdaten, gestützt auf einen spezialisierten Algorithmus, optimiert den Zahlungsverkehrsablauf, spart Kosten und steigert die Sicherheit. Durch das Einbeziehen des stets aktuellen EPC-Directorys kann sichergestellt werden, dass das Weiterleiten von Anfragen sicher und einheitlich ist. So können Banken die neuen Instant-Payment-Vorschriften reibungslos umsetzen und ihre Ressourcen optimal nutzen.