Blogpost

Der neue pain.002-VoP-Status-Report und seine Auswirkungen auf die Sammlerverarbeitung

Mit der Einführung des neuen VoP-Status-Reports im Format pain.002.001.10 ergeben sich signifikante Neuerungen, die speziell für die Verification-of-Payee(VoP)-Prüfung und deren Integration in die Bulkverarbeitung relevant sind. Dieser Artikel beleuchtet die wichtigsten Änderungen und ihre Auswirkungen auf die Verarbeitung von Sammelaufträgen.

316
5 Minuten Lesezeit
Blogbeitrag GraphRAG

In dieser Collection enthalten:

Collection öffnen

Was ist der VoP-Status-Report?

Der VoP-Status-Report ist eine standardisierte ISO-20022-Nachricht im Format pain.002.001.101, die die Ergebnisse der VoP-Prüfung zurückgibt. Bei der VoP-Prüfung wird der Name und/oder der Identifikationscode in Kombination mit der IBAN des Zahlungsempfängers aus einer pain.001-Nachricht mit den beim kontoführenden Zahlungsdienstleister (ZDL) des Zahlungsempfängers hinterlegten Daten abgeglichen. Die Ergebnisse dieser Prüfung werden in Form von Statuscodes in einer entsprechenden Antwortdatei, dem VoP-Status-Report, zur Verfügung gestellt und ermöglichen so eine genaue Nachverfolgung sämtlicher Prüfergebnisse in einem Sammler.

Ein wesentlicher Unterschied zwischen Sammelaufträgen und Einzelprüfungen liegt in der Komplexität und der Geschwindigkeit der Verarbeitung. Bei Sammelaufträgen (pain.001) müssen die Ergebnisse vieler Transaktionen zuerst zur Prüfung vereinzelt und nach der Prüfung wieder gebündelt und aggregiert werden, was höhere Anforderungen sowohl an die Datenstruktur als auch an die Verarbeitungsgeschwindigkeit stellt.

Bei Einzelprüfungen entfällt die die Aufsplittung des Sammlers und die Konsolidierung des Ergebnisses.

Verfahren, über die im Zahlungsverkehr Sammler eingereicht werden, wie zum Beispiel EBICS oder FinTS, müssen in ihrer Verarbeitungslogik diesen neuen Standard berücksichtigen und sicherstellen, dass dem Kunden diese Informationen zu einzelnen Zahlungen eines Sammlers zugänglich gemacht werden können.

Die Unterschiede des neuen VoP-Status-Reports in der Version pain.002.001.10 zu seinen Vorgängern

1. Einführung spezifischer VoP-Status-Codes

Im Vergleich zu den bisherigen Informationen, die in einem Status-Report mitgegeben wurden, wird in der 10er-Version ein spezieller vierstelliger Status-Code für die Ergebnisse der Prüfung eingeführt. Diese neuen Status-Codes wurden speziell für VoP-Prüfungen definiert. Sie geben Auskunft über die Ergebnisse der Prüfung der Einzelzahlungen:

  • RCVC (Match): Volle Übereinstimmung zwischen Namen und IBAN.
  • RVMC (Close Match): Teilweise Übereinstimmung; der korrekte Name wird zurückgemeldet.
  • RVNM (No Match): Keine Übereinstimmung.
  • RVNA (Not Applicable): Prüfung nicht anwendbar.
  • PDNG (Pending): Zwischenstand, wenn das finale Ergebnis noch aussteht.

Diese Codes erlauben eine differenzierte Rückmeldung und erleichtern die Nachvollziehbarkeit der Ergebnisse jeder einzelnen Zahlung des Sammlers.

2. Gekürzte Struktur mit wenigen Pflichtfeldern

Gerade beim Thema Verarbeitungsgeschwindigkeit darf eine Rückmeldung nicht lange dauern und die Datenmenge sollte möglichst klein ausfallen. Aus diesem Grund wurde die Anzahl an Pflichtfeldern reduziert und nur wenige optionale Felder zugelassen. Für die VoP Prüfung nicht relevante Felder wie <InitiatingParty> oder <ForwardingAgent> werden nicht mehr verwendet. Zudem wird auch der Betrag <Amt> im Status nicht ausgewiesen.

3. Gruppenergebnisse und Zusammenfassung

Neben den Ergebnissen der IBAN Namens Prüfung in den Einzelsätzen gibt es in dem Report eine Zusammenfassung der Ergebnisse auf Group Header Ebene und auf Sammlerebene. Mit der Zusammenfassung der Ergebnisse auf Headerebene erlangt man einen schnellen Überblick über die Qualität des eingereichten Sammlers. So werden beispielsweise die Anzahl der Transaktionen pro VoP-Statuscode angegeben. Die so ermöglichte schnelle Auswertung von z. B. Sammelaufträgen mit einer großen Anzahl an Transaktionen lässt eine schnelle Entscheidung zur weiteren Verarbeitung der zugrundeliegenden pain.001 zu.

Sollte ein oben benannter Status in der Sammeldatei nicht vorkommen, wird dieser auf Headerebene auch nicht genannt.

4. Freitextelemente zur Weitergabe relevanter Informationen

Die Verwendung von Freitextfeldern wie <AddtlInf> macht es möglich, dem auftraggebenden Zahlungsauslöser Zusatzinformationen bereitzustellen, die für die korrekte Ausführung einer Zahlung bzw. Anpassung seiner Stammdaten notwendig sind.

Sollte die Prüfung eines Einzelsatzes ein „Close Match“ ergeben, so wird der Name des Kontoinhabers beim Empfängerinstitut in diesem Freitextelement zurückgemeldet.

Auch für den Fall des Statuscodes „Not Applicable“, wird das Element genutzt, um Erläuterungen zu den Gründen zu hinterlegen (z. B. fehlende Unterstützung der VoP-Prüfung oder seiner Elemente, falsche IBAN oder geschlossenes Konto).

Somit wurde die Struktur des bereits bekannten pain.002 nicht umfangreich angepasst, sondern es wurde versucht, die bestehenden Feldstrukturen für den Transport von Informationen zum Inhalt des Sammlers zu nutzen und an geeigneten Stellen einzukürzen, um die Datenmenge zu reduzieren.

Was bedeutet der pain002.001.10 VoP-Status-Report für die zukünftige Sammlerverarbeitung?

Die Anpassungen im VoP-Status-Report haben direkte Auswirkungen auf die Verarbeitung von Sammelaufträgen:

Bessere Übersicht durch Gruppenergebnisse

Die Gruppierung von Ergebnissen reduziert die Menge an Einzeldaten, die ausgewertet werden müssen. Durch die neuen Elemente im Gruppenergebnis wird eine bessere Übersicht über alle sich im pain befindlichen Statuscodes gegeben.

VoP-Status-Report, pain.002.001.10

Abbildung 1: Übersicht pain.002.001.10

  1. Bessere Nachvollziehbarkeit durch spezifische Status-Codes

Die neuen Status-Codes bieten detaillierte und klare Informationen über die Ergebnisse der VoP-Prüfung. Dadurch können Unstimmigkeiten schneller identifiziert und behoben werden.

  1. Optimierte Datenstruktur

Die minimalistische Struktur des Reports reduziert die Komplexität bei der Integration in bestehende Systeme. Gleichzeitig verringert sich die Datenlast, was die Verarbeitungsgeschwindigkeit erhöht. Des Weiteren wird die Vertraulichkeit erhöht, da Geldbeträge nicht angezeigt werden, zum Beispiel bei Gehaltszahlungen.

  1. Fehlerbehandlung

Durch Freitextelemente und detaillierte Statusmeldungen kann der Zahlungsauslöser adäquat auf Fehler reagieren, zum Beispiel durch Korrektur von Namen bei „Close Match“ oder Klärung von „Not-Applicable“-Fällen. Ebenfalls können Stammdaten inzum Beispiel einem ERP-System durch diese Rückmeldungen verbessert werden.

  1. Maschinenlesbarkeit

Die standardisierte Struktur des VoP-Status-Reports macht ihn vollständig maschinenlesbar, was entscheidende Vorteile bietet.

VoP-Status-Codes wie RCVC (Match) oder RVNM (No Match) ermöglichen es, Folgeaktionen automatisch auszulösen, etwa Benachrichtigungen oder Korrekturvorschläge.

Die Maschinenlesbarkeit des Reports trägt somit wesentlich zur Effizienzsteigerung und Prozessoptimierung bei und eröffnet neue Möglichkeiten für eine automatisierte und fehlerfreie Zahlungsabwicklung.

Auswirkungen auf Kundensysteme am Beispiel von EBICS

EBICS (Electronic Banking Internet Communication Standard):

  • Erweiterte Protokollunterstützung: Electronic-Banking-Systeme, die mittels EBICS kommunizieren, müssen angepasst werden, um die neuen pain.002.001.10-Nachrichten effizient zu interpretieren. Dies umfasst die Implementierung der spezifischen Statuscodes und die Verarbeitung von Gruppenergebnissen sowie dem Darstellen der verschiedenen Ergebnisse.
  • Kundenzugang: Banken müssen sicherstellen, dass Kunden die neuen Statusberichte über EBICS abrufen können. Dies erfordert Updates im Kundenportal und in den entsprechenden APIs.
  • Datenlast: Aufgrund der verpflichtenden Prüfung jedes Sammlers können sich Datenmengen erheblich erhöhen, was eine Erweiterung der Infrastruktur erfordern kann.

Fazit

Die Einführung von pain.002.001.10 markiert einen wichtigen Schritt hin zu mehr Effizienz und Transparenz in der Zahlungsabwicklung.

Für Unternehmen, die regelmäßig Sammelaufträge einreichen, bieten die neuen Funktionen erhebliche Vorteile:

  • Schnelle und transparente Kommunikation von Prüfergebnissen.
  • Verbesserte Fehlerbehandlung und Nachvollziehbarkeit.
  • Nachhaltige Verbesserung der Kundeneigenen Stammdaten.

Allerdings sind besonders die Hersteller der sammlerverarbeitenden Electronic-Banking Systeme nun gefordert, dem Kunde diese Vorteile zur Verfügung zu stellen und diese nahtlos zu integrieren.

Yannik Osterloh

Yannik Osterloh

hat einen Master in Wirtschaftsinformatik und unterstützt als Project Manager bei msg for banking Kunden bei der Einführung von Instant Payments.

Schreiben Sie einen Kommentar

Sie müssen sich anmelden, um einen Kommentar zu schreiben.